#ubuntu-kernel 2005-03-21
<lamont> so lets see.. do we want to have 00list-25.1* in the 26 upload?
<lamont> hrm.. actually, I don't see the atapi patch update either...
* lamont will pester fabbione tomorrow morning his time
<zul> hey
<zul> so what did i miss?
<lamont> you know, we could break up the kernel into a package that just builds the -doc and -source packages, and then others that just build-depend: -source, have nothing in them except maybe config files, and then do the build...  that'd let the buildd's spread the load of a new source tree out a bit...
* lamont waits to get pummeled
<zul> good idea but we arent redhat
<zul> or any rpm based distro
<zul> does debian do the same way?
<zul> ie how we build our kernel...oh this is channel is logged now isnt it?
<lamont> heh
<lamont> yeah, should be logged
<lamont> t-bone was doing it, I expect fabbione has picked that up and incorporated it into the wiki bound logs
<lamont> debian is heading to the same place we are, not sure who is further down the path yet.
<zul> it should have big black warning signs
<lamont> prior to the 2.6 package, it was actually a kernel-tree and kernel-patch-2.4.27-powerpc type world
<zul> eww
<zul> nighto
<jbailey> mdz: I made a bad on 1440 - It looks like scd0 *is* there.  I had windows open to both SATA machines.  I did the kernel upgrade on one and looked at the other afterwards.
<jbailey> mdz: ii  linux-image-2. 2.6.10-25.1    Linux kernel image for version 2.6.10 on PPr
<jbailey> iridium:/sys/block/sr0#
<jbailey> Sorry, obviously being in the rush to get out caught me. =(
<fabbione> lamont:
<fabbione> +# this is a hack for Ubuntu buildd's
<fabbione> +
<fabbione> +if [ -e /CurrentlyBuilding ] ; then
<fabbione> +       fork := $(cat /proc/cpuinfo | grep ^processor | wc -l)
<fabbione> +       fork := $(expr $fork \* 2)
<fabbione> +       export CONCURRENCY_LEVEL := $fork
<fabbione> +fi
<fabbione> +
<fabbione> somethinig like this in debian/rules
<fabbione> would speed up the kernel build N times
<lamont> fabbione: i386 is 4 way, amd64 2, ppc 1.
<lamont> ppc is the blocker
<fabbione> lamont: i did test on davis.. -j15 flies
<lamont> and the other 2 finish in about 2 hours..
<fabbione> still slow but clearly much better than -j1
<fabbione> specially if the code is ccached
<lamont> yeah - feel free to add the hack...
<fabbione> we can give it a shot for 26
<fabbione> and see how it goes
<fabbione> you get the delta for it, don't you?
<lamont> ??
<lamont> I get what?
<fabbione> delta in build time.. to see if we gain or we lose
<lamont> yes] 
<fabbione> cool
<lamont> last line of the build logs
<lamont> lrwxrwxrwx  1 root root 9 Mar 10 06:37 /usr/sbin/sendmail -> /bin/true
* lamont takes a large bo-staff to debootstrap
<fabbione> * committed kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10--patch-26
<fabbione> ok 25.2 is up
<fabbione> lamont: want to check if the changes to the umask are ok?
<lamont> find ~lamont/public_html/Archives ! -user lamont -perm -0200 ! -perm -020
<lamont> /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10/patch-26/++revision-lock
<lamont> /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10/patch-26/++revision-lock/+contents
* lamont grumbles
<fabbione> does sftp actually load .bash_profile?
<lamont> dunno
<fabbione> because that's where i changed the umask
* lamont sets it in .bash_profile and .bashrc
<fabbione> umask 002
<fabbione> also in .bashrc now
<fabbione> i can try to branch and see if that works
<lamont> well, if you go chmod g+w those two files, then _I_ can commit to mainline....
<fabbione> sure
<fabbione> done.. they are actually 2 dirs..
<fabbione> let me try to branch and see if sftp will load .bashrc
<fabbione> i can still fix the permissions on the fly
<fabbione> looks about right
<fabbione> * committed kernel-team@ubuntu.com--2005/kernel-debian--pre26--2.6.10--patch-7
<fabbione> lamont: all the syncs/merges should be ok now
<lamont> woot
<fabbione> lamont, mdz: would i be crossburned if i kill this patch madness for hoary?
<T-None> hey fabbione !
<fabbione> hi T-None 
<mdz> fabbione: not at all
<lamont> fabbione: I have yet to see what useful purpose it serves...
<T-None> well in my humble opinion i would praise you for doing so ;)
<lamont> which is to say, kill away
<T-None> lamont: lol
<mdz> it should be pretty easy to ensure that it doesn't regress
<fabbione> lamont: i am not 100% how make-kpkg will interact with linux-ubuntu-patches
<mdz> as long as it still builds and no patches are dropped, it is fine with me
<mdz> it should save minutes on the kernel build too :-P
<T-None> the only purpose i see is finding out which kernel rev introduced a borkage. Since we take care not to uplaod before builds (do we), it's obviously the last one :)
<fabbione> mdz: minutes? ages!
<T-None> hell yes
<fabbione> again.. we only build the kernel this way
<fabbione> but i am not 100% about the linux-ubuntu-patches
<fabbione> and it is used when building from linux-source package
* T-None will look at that later, already much too late at work, have to run
<T-None> see yall
* lamont tries to decide if 2.25GB of ram is overkill on a dual P3-1.2GHz machine
<Mithrandir> lamont: nah, it's just fine.
<fabbione> lamont: i just committed the CONCURRENCY_LEVEL to speed up the build on the kernel
<fabbione> on the buildd even
<fabbione> that should speed up to Ncpus * 2
<fabbione> if the code is ccached we could fork much more
<fabbione> but it is dangerous
<lamont> heh.. make that a 2-way P3-993MHz box.
<lamont> scrollkeepoer
<lamont> ECHAN
<fabbione> --- orig/rules
<fabbione> +++ mod/rules
<fabbione> @@ -55,8 +55,7 @@
<fabbione> 
<fabbione>  .PHONY:                monolith
<fabbione>  monolith:      stamp-monolith
<fabbione> -stamp-monolith:        stamp-monolith-prepare \
<fabbione> -       $(foreach revision,$(revisions),stamp-monolith-$(revision))
<fabbione> +stamp-monolith:        stamp-monolith-prepare stamp-monolith-$(revision)
<fabbione>         rm -rf $(DIFFDIR)
<fabbione>         touch $@
<fabbione> if you apply this patch to your debian/rules
<fabbione> only the last patch set will be applied
<fabbione> killing the patch madness
<fabbione> after that this make-substvar is called
<fabbione> and it fails
<fabbione> debian/make-substvars linux version.Debian debian/monolith/list > debian/substvars.safe
<fabbione> Line 1: patch patch-2.6.10-26 is not well-founded
<fabbione> Patch for 2.6.10-26 must be listed
<lamont> ah, so we need to create the input file that it wants, without bothering to actually apply the patches...
* lamont can work on that
<fabbione> kinda
<fabbione> ( cd /home/fabbione/linux-source-2.6.10-2.6.10/debian/diffdir; diff -Nur linux-source-2.6.10-2.6.10-25.2 linux-source-2.6.10-2.6.10-26 || true ) > debian/monolith/patch-2.6.10-26
<fabbione> FUCK
<fabbione> FUCK
<fabbione> FUCK
<fabbione> it uses incremental patches
<fabbione> uhuh
<fabbione> got it
<lamont> feh
* lamont sleeps
<fabbione> good night
<fabbione> bah
<fabbione> i found another bug
<fabbione> thanks god it affects only hppa atm
<fabbione> baz commit -s'Kill patch madness'
<zul> hey
<jbailey> Heya.  Waldi filed a bug against initrd-tools in Debian which propagated its way into Ubuntu.  Apparently on his systems /proc/scsi isn't populated, and on ours it is.   His claim is that 2.6.10 did away with that.  Have we tweaked it so that ours still has that info?
<zul> not sure maybe you should ask in -devel
<jbailey> Nah, I'll just pull the source and look.
<zul> or youo could do that
<jbailey> ## DP: Description: restore generic SCSI proc_info function in drivers/scsi/scsi_proc.c
<jbailey> That would probably be the one.
<zul> oh it was a kernel question...im not awake yet
<fabbione> hey
<zul> hey fabbione 
<jbailey> Heya Fabio =)
<jbailey> zul: *lol* =)
<zul> fricking palm
<fabbione> i am testing the new patch thingy
<fabbione> it seems to work fine
<zul> which patch thingy?
<fabbione> no more 192891821 patch/unpatch
<zul> ah good
<fabbione> zul: baz update?
<zul> ooh you fixed it so it doesnt patch/unpatch a billion times?
<fabbione> yup
<zul> sweet! 
<fabbione> there were several changes to do
<fabbione> + an important bug fix
<fabbione> hey smurfix 
<abelli_> ciao smurfix 
<fabbione> smurfix: what was the perfect command to verify the ABI compatibility?
<smurfix> fabbione: one sec
<fabbione> sure.. also 2 or 3
<smurfix> something along these lines ..:
<smurfix>  grep vmlinux Module.symvers.old_kernel |sort >/tmp/symvers.old
<smurfix> ditto new
<smurfix> comm -23 old new
<smurfix> must be empty
<smurfix> assuming you build with CONFIG_MODVERSIONS
<fabbione> where Module.symvers.old_kernel = Systemmap?
<fabbione> no
<smurfix> fabbione: no, the "Module.symvers" file that's generated by building the kernel
<fabbione> yes and we don't ship it
<smurfix> Let me check if you can extract that somehow
<fabbione> the idea is to automatically check the ABI with the previous kernel at build time
<fabbione> previous version
<fabbione> now we can also start shipping that file
<fabbione> it's not a tragedy
<fabbione> if we start shipping it in 26
<smurfix> fabbione: The kernel doesn't export that info any more because it now has a built-in relocator
<fabbione> from 27 we can add the check at build time
<smurfix> so you probably should start shipping it.
<fabbione> this would add a Build-
<fabbione> this would add a Build-Dep: on the most recent version of the kernel
<fabbione> or just on a linux-abi package
<fabbione> that can collect all the MOdule.*
<fabbione> what do you think?
<smurfix> Hmm, better do an abi package.
<fabbione> next upload needs to bless a new package anyway
<fabbione> so one more or one less won't change much
<smurfix> Would be nice to have that available for cross-compiling. You can put the .config files in there too.
<fabbione> smurfix: configfiles are in /boot with the images
<smurfix> fabbione: true. Doesn't hurt to also ship them in an -abi package, people like me who still habitually build their own kernels would like that. But, your call.
<fabbione> what scares me a bit is how to ensure that we always build against the $previousversion -abi
<fabbione> without having to control that manually
<fabbione> scenario:
<fabbione> upload -1
<fabbione> there is no previous -abi
<fabbione> so we skip the check
<fabbione> and it FTBFS on ppc
<fabbione> how do we upload -2 that will check the abi for all arches other than ppc?
<fabbione> the code needs to be very smart
<smurfix> fabbione: What are you going to do if/when the ABIs don't match?
<zul> take a large wooden hammer
<smurfix> fabbione: ... or do you decree that any -1 is an ABI change but -2+ isn't?
<fabbione> smurfix: FTBFS?
<smurfix> fabbione: Well, someties you do need to change the ABI :-/
<fabbione> smurfix: clearly the -1 is a new abi
<fabbione> yes of course you must change the ABI
<fabbione> but an ABI change require also a new control file
<fabbione> to reflect that change
<fabbione> for example
<fabbione> if i start doing heavy patching
<fabbione> or security patching to the kernel
<fabbione> running a build should be able to tell me if that change will introduce an ABI change
<smurfix> OK, so you check the old linux-abi package's version number, and skip the ABI check if it doesn't match what you're building
<smurfix> excluding the -X version of course
<fabbione> kinda yes
<fabbione> but if for example
<fabbione> we are building -1-2.6.10 ver 2.6.10-2
<fabbione> i want it to compaer with -1-2.6.10 ver 2.6.10-1
<fabbione> if the ABI does not match
<fabbione> i want it to FTBFS
<fabbione> so that i can prosuce a -2-2.6.10
<fabbione> that is the correct way
<fabbione> since there is an ABI change
<fabbione> i mean.. i know i could do all of this manually
<fabbione> but for N arches in N flavours
<fabbione> it's a royal pain
<smurfix> fabbione: sure, but I fail to see how that differs from what I've been saying
<fabbione> than probably i misunderstood you :-)
<fabbione> but ok
<smurfix> Let's say you create a linux-kernel-abi package
<fabbione> yes
<smurfix> some file in it contains the magic string "2.6.10-4"
<fabbione> it would need to contain the ABI version too
<fabbione> ok
<smurfix> I thought that is* the abi version
<fabbione> yeah i get you now
<fabbione> i was thinking in terms of 2.6.10-1 (starting from scratch)
<smurfix> Doesn't really matter, you'd get the magic string "2.6.9-5" or whatever
<fabbione> yup
<smurfix> different, so skip check.
<fabbione> right
<fabbione> that would solve all the problems
<smurfix> same when you FTBFS, the failed arch would keep its old l-k-a package which still has the old magic string in it.
<fabbione> it won't match the ABI and therefor skip the test
<fabbione> because hte next upload will have a different ABI
<fabbione> good idea
<smurfix> The only problem I see is how to build-dep on the latest l-k-a package
<smurfix> unless you just want to wing it ;-)
<smurfix> (probably not a good idea, now that I think about it)
<fabbione> well the first upload will create the package
<fabbione> from the second one we will build-dep on it
<fabbione> in case of troubles we can always remvoe the build-dep
<fabbione> and unroll the loop
<smurfix> Yeah, but if the second build installed the package from the first run on the autobuilder, but changes the ABI, then the third build may still see the first package if it happens not to be cleared out
<fabbione> that shouldn't be a problem
<smurfix> so a mistaked ABI change from 2->3 might be missed
<fabbione> the ABI is supposed to be the same between first, second and third
<smurfix> Umm, it's supposed to be the same from -2 to -3, but I wan't talking about that
<fabbione> oh you mean if there is an ABI change between -1 and -2
<fabbione> and we upload -3
<fabbione> and there can still be abi from -1 in the buildd
<fabbione> at that point the ABI check should be skipped
<fabbione> and it will due to the magic file
<fabbione> but yes.. that can actually skip a test that should be done
<smurfix> Exactly. I don't know how to guard against that other than asking the archives for the current version when you prepare the source package
<smurfix> Dunno whether you'd want to go that far.
<fabbione> well preparing the source package is still manual
<fabbione> and we can still hack on it
<smurfix> OK, then you need to remember never to forget to update the dependency when you prepare a new version. ;-)
<smurfix> or write a script that does it. Good enough I'd say.
<fabbione> smurfix: that is why we have a control.stub that we can mangle as we like :-)))))
<fabbione> smurfix: the next question would be.. are you for this challenge?
<fabbione> ;)
<smurfix> fabbione: gah  ;-)   I need to fix the keyboard chooser first
<fabbione> ehhehe
<fabbione> fair enough
<smurfix> fabbione: it needs a confirmation dialog
<fabbione> i think we can postpone this feature to hoary+1
<fabbione> even if it would make pitti's life 1029292 times simpler
<fabbione> also for us that will have to maintain this kernel for 18 months
<fabbione> last script to test the anti-patch-madness fix
<fabbione> s/to/for
<smurfix> fabbione: If for hoary, when would you need it?
<fabbione> within monday
<fabbione> but i guess i can try to work on it
<fabbione> i will have the weekend free!
<fabbione> YEAH YEAH
<fabbione> wife -> her sisterm
<fabbione> sister even
* lamont will be offline from sometime this weekend until sometime tuesday or so
<fabbione> lamont: don't worry
<fabbione> i won't upload very soon
<fabbione> not with these big changes
<fabbione> i am still testing some stuff
<lamont> fabbione: it means that you're baz bitch for a few days... :-)
<fabbione> i might get up -26 to get the ATAPI thingy in again
<fabbione> and the new idiotify patch
<fabbione> and the antipatchmadness
<fabbione> the ABI stuff can come later
<fabbione> ok confirmed 100%.. the patch madness is gone
<fabbione> all the scripts are working
* T-Bone reads 3 lines back and ^5s fabbione !
* T-Bone wonders if lamont is around and has some "good" news... (who knows ;o)
<zul> heh im almost always here
<zul> whoa...224 changes in the last day
<mdz> changes?
<zul> in linus bk tree
<lamont> busy boy
<zul> well with the g5 he must be :)
#ubuntu-kernel 2005-03-22
<jbailey> Is there a sane way to tell if NOEXEC is enabled or not on a given system?
<zul> hey
<lamont> hay
<zul> how now brown cow
<lamont> nah, hay is for horses
* lamont just fed, you see...
<zul> heh i just fed the guinea pig
<zul> so kind of same thing
<lamont> heh
<lamont> hrm.. I'm on  major lagtime today
<fabbione> morning
<fabbione> i guess nobody has been tracking the Debian kernel while i was away... right?
<dilinger> i have!
<dilinger> ;)
<fabbione> yeah i know you do :)
<fabbione> nobody did here
<fabbione> and i can see a few hunderd tons of SECURITY and other important bug fixes
<dilinger> i actually am about to release 2.6.10-6
<dilinger> i have an i386 image compiling
<fabbione> is there any abi breakage between debian 2.6.10-4 and -6?
<dilinger> there shouldn't be
<dilinger> i dropped the netfilter private frag queue stuff
<dilinger> there's an amd64 fix that touches a header file, but it's a static inline function, so it shouldn't break stuff
<dilinger> i'm also reenabling CONFIG_PREEMPT on i386, so as to avoid an ABINAME bump
<dilinger> no point fixing that stuff in 2.6.10, and having it rot in NEW while we do the same thing in 2.6.11
<fabbione> but that's in the kernel-image....
<dilinger> right
<dilinger> which you don't care about.  but i figured i'd mention for completeness
<fabbione> yes.. i am not going to munge too much around with configs at this point in time
<dilinger> i have a half written ruby script that does abi checking
<dilinger> wrote it in an airport
<dilinger> i should finish it tonight
<fabbione> yeah but we were considering build-time checks
<dilinger> right
<dilinger> bounty it, and i'll have it done in a day or two :)
<fabbione> in 99.9% of the cases we always pre-build on porting boxes
<dilinger> in something other than ruby
<fabbione> for bounties = mdz ;)
* dilinger pokes mdz
<fabbione> the point isn't ruby or python or shell script
<dilinger> well, if you're going to run it at build-time, it's an added build-dep
<fabbione> <mdz> sleep now
<fabbione> yes.. but that isn't an issue
<fabbione> just read all the irclogs :-)
<fabbione> i need to go for a few minutes.. mother nature is calling me badly
<dilinger> heh
<dilinger> i need to start this i386 build anyways
<fabbione> eheh
<fabbione> jbailey: CONFIG_LOGO=n on all arches
<fabbione> just committed
<fabbione> HMMM
<fabbione> there is something really unclear to me....
* fabbione needs to dig into this madness
<dilinger> fabbione: just checking vmlinux symbols doesn't work
<dilinger> modules ABI need to be checked as well
<fabbione> yeah i have been thinking about it...
<dilinger> modules'
<dilinger> my way is running nm on modules
<fabbione> and i had the same idea.. 
<dilinger> ie, nm /lib/modules/2.6.10/kernel/drivers/ide/ide-core.ko
<dilinger> 3b97ad98 A __crc_ide_undecoded_slave
<dilinger> 00007fa0 T ide_undecoded_slave
<dilinger> that's 0x3b97ad98      ide_undecoded_slave     drivers/ide/ide-core in Module.symvers
<dilinger> an abi checker needs to report any modules that are missing, and any changed symbols within modules
<fabbione> first 2 things to do after hoary:
<fabbione> - clean up the packing
<fabbione> - allign the configs
<fabbione> - abi checker if we cannot get it in hoary
<fabbione> IT IS PURE MADNESS!
<fabbione> we could have a kernel-config builder.. similar to kernel-wedge
<dilinger> how about
<dilinger> - synch packaging w/ debian
<dilinger> since i think we both want the same things; the only place we seem to differ is w/ ubuntu's d-i stuff right in the source package
<dilinger> differ in goals, that is
<fabbione> and a bunch of extra modules compiled in
<fabbione> but yes
<fabbione> we need a common source
<dilinger> yea, but that's not a packaging issue
<dilinger> it'd make everyone's life easier, i think
<fabbione> but we can't achive it until debian will not kill at least the kernel-source -> kernel-image madness
<fabbione> i fully agree
<dilinger> right
* fabbione is very close to send ia64 to hell
<fabbione> it's snowing
<fabbione> damn
<Mithrandir> slushing here.
<fabbione> the only thing that pisses me off about snow is that i need to go out and clean the road
<Mithrandir> it'll clean itself eventually.  Called summer.
<fabbione> Mithrandir: here by law we must clean it, because it's a private road
<Mithrandir> oh, ok
<fabbione> and if the postman falls 
<fabbione> it's my responsability
<fabbione> now.. it is fucking lame
<fabbione> because they could learn to fly
<fabbione> or eventually buy better snow shoes
<fabbione> but apparently they love to make easy things more complex via the useless
<fabbione> T-None: fix to the ia32 memcpy is done
<fabbione> -26 is going up
* fabbione starts the baz magic
<fabbione> <fabbione> T-None: fix to the ia32 memcpy is done
<jbailey> fabbione: Thanks!
<T-Bone> seen that, thx
<fabbione> jbailey: no problem
<fabbione> it took me fucking 4 hours to unfuck ia64 build
<T-Bone> unfuck?
<fabbione> well yes.
<Mithrandir> T-Bone: does the new ia32-libs in the archive make you happy?
<fabbione> the problem is that we were calling kernel-wedge || true
<fabbione> that was hiding some problems
<fabbione> and ia64 was one in the worst situation
<fabbione> with dup mods allover
<T-Bone> Mithrandir: haven't checked yet but they certainly will! We need to sync with kamion for the language support deps, as soon as you'll upload ooo :)
<T-Bone> fabbione: wasn't aware of that
<T-Bone> fabbione: nobody complained
<fabbione> T-Bone: yup.. i did paste here when you were around :-)))
<fabbione> and you said: "Uhuh?"
<fabbione> so i just went forward and fixed it 
<T-Bone> <fabbione> debian/ext3-modules-2.6.10-4-itanium-smp-di lib/modules/2.6.10-4-itanium-smp/kernel/fs/mbcache.ko
<T-Bone> <fabbione> debian/ext2-modules-2.6.10-4-itanium-smp-di lib/modules/2.6.10-4-itanium-smp/kernel/fs/mbcache.ko
<T-Bone> <fabbione> some modules are in more than one package
<fabbione> i tought you were busy somehow
<T-Bone> yesterday
<fabbione> yes that one
<Mithrandir> T-Bone: I would be very happy if you checked it out and closed the bugs if appropriate
<T-Bone> well given i get back from work at 1900 localtime on every week days except friday, I don't have much time to dig that kind of stuff
<T-Bone> Mithrandir: the only bug i know of is the ldd one, You fixed it, you close it? :)
<fabbione> that's why i went forward and fixed it
<T-Bone> which is cool
<Mithrandir> T-Bone: please verify it's fixed.
<T-Bone> besides, I don't have much insight on kernel build process
<T-Bone> Mithrandir: sure, hold on
<T-Bone> Mithrandir: give me 5mn to get something on fire for me to eat, i'm starving
<Mithrandir> sure
<Mithrandir> T-Bone: I hate to close bugs if I can't verify that they are fixed.
<T-Bone> well you can... :)
<T-Bone> what am i supposed to check? apt-get removing and install ia32-libs is enough?
<Mithrandir> also lib32gcc1
<Mithrandir> and that ooo works afterwards
<T-Bone> (btw, i dunno what you did with ssh yesterday but nc didn't like it. I have 12 process running and the same number of open connex between nekkid and my box :)
<T-Bone> pl
<T-Bone> err, 'ok'
<Mithrandir> just kill the nc prosesses
<T-Bone> done
* T-Bone curses french out-of-sync-mirror, edits sources.list
<T-Bone> ls /usr/bin/ld
<T-Bone> ld         ldd        ldd.amd64  lddlibc4
<T-Bone> root@Nekkid:/home/varenet/ooo # ls /usr/bin/ld
<T-Bone> root@Nekkid:/home/varenet/ooo # dpkg -S ldd.amd64
<T-Bone> diversion by ia32-libs from: /usr/bin/ldd
<T-Bone> diversion by ia32-libs to: /usr/bin/ldd.amd64
<T-Bone> *PLONK*
<T-Bone> the RTLDLIST is correct though
<T-Bone> only the naming looks wrong
<T-Bone> dunno if that's such a big problem
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | kernel-team@ubuntu.com--2005/kernel-debian--pre27--2.6.10
<fabbione> no log on people...
<fabbione> that's good.. 
<fabbione> it means that buildds didn't fail... YET
<T-Bone> Mithrandir: ooo works as a charm
<T-Bone> fabbione: wrt the m-l, i wasn't the one who set it up, i hope you're subscribed to it, it's used for bugreports actually.
<Mithrandir> T-Bone: great, thanks.
<T-Bone> Mithrandir: what do you think about the ldd.amd64 thingy?
<T-Bone> in my taste it should be corrected, but as long as it works...
<fabbione> T-Bone: i didn't want a ml from the beginning and i know you have no power to sub people
<T-Bone> ?
<fabbione> and now it is a very high traffic ml that nobody is going to read
<T-Bone> i didn't want bugreports to be sent to that m-l
<fabbione> since i get the same bug  messages in 3 inbox now
<T-Bone> i didn't push forward for that m-l
<fabbione> T-Bone: read above please.. i didn't say you did something anywhere
<fabbione> i know you did not create it
<fabbione> but you were one pushing for it
<T-Bone> i thought that if we were to have a decently sized team, it would be useful
<Mithrandir> T-Bone: I'm somewhat inclined to ignore it, or rather, I'm probably going to fix it for ia32-libs in Debian and we'll sync what they have.
<T-Bone> but I clearly stated (and the logs on that channel will show it) that having bugreports sent to it was a *bad idea*, since it would turn up the same shit as debian-kernel which I unsubscribed for that very reason
<fabbione> i agree to that :-)
<fabbione> we shoud remove the bugs from the list
<fabbione> i think lamont has to do it
<T-Bone> Mithrandir: ok. Maybe you want to add some README entry somewhere about that, so that confused users can see it before posting irrelevant bugreports
<fabbione> i am not sure even who did it in the beginning
<T-Bone> fabbione: i would more than thank you for doing that
<fabbione> i don't know it has been done in the beginning
<fabbione> so i am not sure HOW to revert it
* T-Bone doesn't know: went to bed one day, woke up the next and the m-l was there
<T-Bone> OTOH you can blame *me* for creating this channel :P
<Mithrandir> T-Bone: sure, but it's a 200-odd MB upload, so I try not to upload it too often.
<fabbione> i am off until the meeting
<fabbione> i need some relax
<fabbione> pleaase keep an eye on the build logs
<fabbione> and try to grep for -j to see if it has been set properly
<T-Bone> Mithrandir: heh roger that
<fabbione> we should have a huge build speed up with this upload
<T-Bone> Mithrandir: care to close the bug btw?
<mjg59> Ok, new HP laptops need the reboot=b paramater on boot to reboot
<mjg59> We can work round that with a DMI entry in reboot.c
<Mithrandir> T-Bone: done
<T-Bone> thx
<lamont> actually, removing bugs from the mailing list is a change in the default assignment in bz...
<T-Bone> hey lamont!
<T-Bone> issaishiburidane?! ;)
* T-Bone obfuscates the output a bit more not separating logical entities ;)
<zul> heylo
<T-Bone> heya
<zul> when is that meetinga again?
<T-Bone> in 3 hours
<zul> ok
<zul> dang thats when i have lunch
<T-Bone> heh
* T-Bone wanders off re-stringing his guitar
<zul> heh in theory i could test out ppc stuff with pearpc
<T-Bone> lol
<T-Bone> you *really* are a masochist, indeed :)
* T-Bone is done with the stringing
<zul> thats why i said in theory
<jbailey> What's a pearpc?
<zul> its a powerpc emulator
<jbailey> Cool.
<jbailey> Hmm, now that I'm on PPC I should track down an old MacOS emulator and some abandonware games.
<T-Bone> jbailey: tssks tssks, You should read /. There's been stories about PearPC and CherryOS ;)
<jbailey> There was one I really like to play.  CAn't for the life of me remember what it was called.
<T-Bone> Monkey Island?
<jbailey> T-Bone: I've managed to get my /. reading down to once every couple of days.
<T-Bone> jbailey: hehe ;)
<T-Bone> jbailey: syndicate. Much easier to read :)
<jbailey> No, it was a game where you wake up in a spaceship and you're the only one alive and the computer has lost most of its memory.
<T-Bone> huh
<jbailey> You have to help it reconstruct its memories in order to find out what happened.
<T-Bone> that rings something, but i can't tell what
<T-Bone> ;)
<zul> jbailey: roger wilco?
<zul> by sierra wasnt it?
* T-Bone spent endless nights on Monkey Island, the best adventure game ever ;)
<jbailey> zul: You're thinking space quest, I think.
<zul> yeah
<jbailey> zul: And I play that under dosemu occasionally. =)
<zul> ah sweet i found to play that game again i never completed it
<jbailey> On the other machine I have a nice abandonware site bookmarked.
<zul> the-underdogs.org
<T-Bone> jbailey: please hand over the URL :)
<jbailey> Huh, annoying.  my susv3 package in Debian isn't in multiverse.
<jbailey> T-Bone: The machines not on right now, I'll grab it when I stop for lunch.
<T-Bone> cool thx :)
<jbailey> T-Bone: It's a French Abandonware site, too. =)  
<jbailey> A bunch of the games are in French only.  Good practice for me.
<zul> anyone played nobunaga's ambition?
<T-Bone> jbailey: i think i've hit that one once, but i don't recall the name
<T-Bone> most of my bookmarks went away with my dead HD :P
<T-Bone> zul: doesn't ring a bell
* jbailey waits for susv3 to install.
<zul> its an awesome game you are shogun and you are trying to become emperor of japan
<T-Bone> lol
<lamont> T-Bone: hisashiburi da.
<zul> lamont: hey
<T-Bone> daijobu deska? :)
<lamont> t-bone: shindoi da
<lamont> morning zul
<T-Bone> heh ;)
<zul> yes you have entered the twiligh zone
<lamont> zul: we'll be operating in japanese today, ok? :-)
<T-Bone> lol
<lamont> tonycrackers, I should read my email about the dev meeting, eh?
<T-Bone> 'tonycrackers' ! LOL
<T-Bone> that one is a quote I'm probably the only one to understand, but it's rather *fun* 8)
<T-Bone> lamont: dooso
<zul> i might miss the first bit of the meeting
<T-Bone> same here
<zul> but you guys dont need me do you?
<T-Bone> same here
<T-Bone> ;)
<lamont> T-Bone: there's also narufrigginghodo
<T-Bone> LOL
<zul> i so much hate this program
* T-Bone wonders what trick elmo used to get a package in the archive under his name :)
<Mithrandir> T-Bone: which one?
<T-Bone> efibootmgr
<lamont> ] ??
<lamont> T-Bone: the person requesting the sync is the one that katie claims the mail is from
<T-Bone> [!!
<T-Bone> ah ok
<lamont> as for who _really_ did the upload: gpg: Good signature from "Ubuntu Archive Automatic Signing Key (Syncs) <ftpmaster@ubuntu.com>"
<T-Bone> hehe ;)
<T-Bone> at least i know that now mails get to me :)
<T-Bone> next try will be an actual upload
<T-Bone> Mithrandir: btw, let me know when you upload new ooo-amd64, so that I can edit the Wiki ;)
<Mithrandir> will do
<T-Bone> ta
<T-Bone> (i'll pester kamion for desktop-seed update at the same time :)
<fabbione> re
<fabbione> i guess the idiotify patch did invalidate the cache
<fabbione> otherwise the compiling time is totally bong
<fabbione> i just bought a webcam
<fabbione> if we don't have the driver for it.. well ... there -27...
<fabbione> ;)
<Mithrandir> fabbione: do we include random drivers found on around in the stock image?
<Mithrandir> if so, I'd like to have the spca5xxx driver in
<zul> oh hey fabbione 
<fabbione> Mithrandir: well not properly random.. but we include external drivers
<fabbione> and any pending issue will be hoary+1
* fabbione replaces his DVD burner
<fabbione> do we know if elmo blessed NEW?
<Mithrandir> he seems to have done NEW stuff this morning at least
<fabbione> yeah he did
<fabbione> #  linux-patch-ubuntu-2.6.10_2.6.10-26_powerpc.deb
<zul> gah...box at home is down
* T-Gone runs out, bbl
<fabbione> of course my camera isn't supported by our drivers :)
<zul> what kind of camera is it?
<fabbione> logitech
<zul> quickcam pro?
<fabbione> Bus 003 Device 004: ID 046d:08f5 Logitech, Inc. 
<fabbione> it's not claimed by any driver
<zul> i had a camera like that a while ago there were some drivers on sourceforge iirc
<fabbione> yeah
<fabbione> i am googling
<fabbione> Logitech Quickcam QC-USB driver for Linux
<Mithrandir> there was somebody rambling about it on -devel today or so
<fabbione> i am testing the driver right now
<fabbione> quickcam: QuickCam USB camera found (driver version QuickCam Messenger/Communicate USB $Date: 2004/12/30 10:00:00 $)
<zul> yay! we get to see fabbione ugly mug
<fabbione> well let see if it works :-)
<fabbione> quickcam [52.189162] : Quickcam snapshot button registered on usb-0000:00:1d.2-2/input0
<fabbione> wow
<fabbione> well it kinda works
<mdz> dilinger: ?
<Mithrandir> fabbioneTV? 
<zul> shaya said on -devel "kernel abi seems to have been broken again"
<fabbione> it didn't like the removal and insert in another usb port
<fabbione> but it works
<fabbione> zul: ?
<fabbione> zul: i did test the abi....
<zul> fabbione: shaya said it was broken but he might be on crack he has linux-restricted 2.6.10-3 and linux-source 2.6.10-4 installed
<fabbione> ah no no no
<fabbione> i can test again
<fabbione> gimme 2 minutes
<zul> k
<fabbione> Extracting templates from packages: 56%debconf: apt-extracttemplates failed: Bad
<fabbione> this is known.. right?
<zul> first time i seen it
<fabbione> hmmmmmm 
<fabbione> i guess it will have to wait after the meeting
<fabbione> or during
<zul> heh...shit happens
<zul> https://bugzilla.ubuntu.com/show_bug.cgi?id=7468 as well
<fabbione> that is NOT our fault
<zul> ok..
<zul> i need some lunch
<fabbione> the aBI seems ok
<zul> ok...bbiab
<zul> that was a good lunch
<zul> so that was it for kernel stuff?
<fabbione> bah
<fabbione> apparently
<zul> heh...that wasnt too bad
<fabbione> the QC driver doesn't init properly
<fabbione> it needs unload and load again
<fabbione> and it is OOPSorama in dmesg
<zul> so dont include it in -27
<fabbione> i was never going to do it!
<zul> sure sure :)
<fabbione> now.. time to get flumotion or any stream thing going
<fabbione> otherwise it's pointless
<zul> i might go see a movie tonight
* T-Bone asked mdz for an IA64 topic to the meeting schedule, to no end alas :P
<T-Bone> *sigh*
<T-Bone> fabbione: kernel stuff back on #u-meeting
<fabbione> thanks
<fabbione> T-Bone: can you keep an eye on the meeting?
<fabbione> i really must cook/eat something
<T-Bone> fabbione: heh. who's gonna cook me somethign? :)
<T-Bone> fabbione: ok i'll do
<fabbione> well if you are around
<fabbione> otherwise i think lamont is
<zul> im around kind of
<T-Bone> eeep eeeppp hppa eeep eep
<T-Bone> eeep eeeppp hppa eeep eep lamont
<T-Bone> (need to highlight else it's pointless :)
* lamont considers ignoring t-bone until after the meeting
<zul> wohoo!
<T-Bone> *G*
<T-Bone> fabbione: i'm off the meeting
<mjg59> Oh, this is crack
<mjg59> hal does an ioctl to check for carrier detect on this b44 device and the machine hangs
<fabbione> [video4linux @ 0x8271eb4] Fatal: grab device does not support suitable format
<fabbione> BAH
<fabbione> xawtv can see and use the device
<fabbione> both flumotion and ffmpeg go banana
<zul> mind if lower the serverity of 6303, user has a workaround which is working for him now
<zul> its the audigy sound card one
<zul> ooh another flakey keyboard bios bug
<zul> later
<zul> https://bugzilla.ubuntu.com/show_bug.cgi?id=6553
<mdz> http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/005482.html
<mdz> unintentional ABI change?
<zul> not that i know of...what version of l-r-m are they using?
<mdz> unknown, but the module path is /lib/modules/2.6.10-4-686-smp/kernel/drivers/video/nvidia.ko
<mdz> so it's one that claims the correct abi version
<zul> we got a problem like that today on -devel but fabbione diagnosed it as l-r-m mismatch
<zul> ill do a dist-upgrade and see
#ubuntu-kernel 2005-03-23
<zul> brb
<viper12> so....anyone awake in here?
<zul> chuck@homer:~$ sudo modprobe nvidia
<zul> Password:
<zul> FATAL: Error inserting nvidia (/lib/modules/2.6.10-4-686/kernel/drivers/video/nvidia.ko): Invalid module format
<zul> ah crap..
<viper12> ditto.
<zul> mdz: confirmed
<viper12> and the wifi broke as well.  Is there a problem with today's updates?
<viper12> really fragged the main box I use.
<zul> apparently there is
<viper12> changing xorg.conf to use the "nv" driver temp fixes the gui, but that's about it.
<viper12> my wifi isn't recognized any longer as well.
<zul> viper12: i realize that we are trying to figure out what went wrong
<viper12> not getting any response in the forums or the main ubuntu channel so I figured I'd drop by here.
<mdz> zul: can you open a bug so that I can refer people there when they ask about this problem?
<zul> mdz: sure
<mdz> if there isn't one already...
<viper12> someone mentioned that the restricted modules weren't bein' "luv'd"....is that what's happening?
<zul> nice background though ;)
<viper12> mdz=matt zimmerman? just curious. (you've been an 'education' in the forums to me....wanted to say thanks...if indeed dat' be you.)
<mdz> viper12: that's me, you're welcome
<lamont> is this -26 or -25?
<zul> 26
<viper12> yep
* lamont nominates the inotify patches
<zul> ya think?
* lamont is committed to out-of-town time for the weekend.
<lamont> starting in about 90 minutes
<zul> frig i dont have access to main
<lamont> ??
<lamont> oh, upload access?
<zul> yeah
<lamont> create a 00list-27* and pester mdz then, I guess.
<lamont> once the fix is done that is.
<zul> k
<lamont> I expect I will have a little bit of online time tomorrow around 1800UTCish, but not very much
<lamont> by that point fabbione will be back around and can do the upload, if it comes to that.
<viper12> just fyi, i'm not asking for tech help here, but am very curious as to probable cause for the issue. (testing 2 boxes and a laptop with latest hoary builds).
<lamont> viper12: if you can't load modules, it's because we broke it. :-(
<zul> mdz: i need to get dinner for my wife and then ill be back on this abi stuff
<lamont> zul: likewise, if mdz isn't around when -27 is ready, there should be _someone_ in #u-d with upload privs... :)
<viper12> lamont......figured that. lol.  good thing that main box has a wired connection as well.......heh heh.  any eta (no rush) on a push for fixes?  (no desire to 'back down' as connectivity via laptop still good.)
<lamont> there should be a -27 there sometime within 24 hours or so (takes forever to build)
<lamont> viper12: specifically, what zul has to do is figure out _which_ patch(es) broke the module abi compatibility, and remove them.
* zul smacks rml
<lamont> Then, we get to roll a new abi with the next kernel upload
<viper12> its all good.  they don't calling it "testing/unstable" etc., for nuthin'. :)
<zul> lamont
<lamont> si?
<zul> yay it kills the stamp-monolith stuff
<zul> ill just build a 686 kernel right now
<lamont> yes. that was the nice thing about fabbione's changes...
<lamont> that works
<lamont> viper12: I assume we're talking some x86 machine here, not ppc or amd64?
<viper12> as x86 as it gets.  stock IBM e-server.  p4 2.4gig
<zul> i only have a 1.8 celeron here so its going to take a while
<lamont> zul: if I were doing it, it'd be on my home machine too.
<viper12> the laptop (compaq x1000 widescreen) only has issues with video acceleration as far as I can tell at this point. (the ati mobility at least didn't break completely.)
<viper12> wifi on the eserver is with a netgear wg311, and that went poof. (guessing restricted mods).
<zul> viper12: what did you do for your xorg stuff so i can add it to the bug?
* lamont disappears for a few minutes
<viper12> to at least get the eserver "up" I just commented out the acceleration and nvidia specific lines, and changed the driver to "nv".  gnome came right up, but gl stuff will barf.
<viper12> (screensavers, games, etc.)
<zul> can you add that to 7485 please? thanks
<viper12> via bugzilla? (brain fartin' here.)
<zul> yes thanks
<viper12> be just a couple minutes. but sure.
<zul> ok...i need to go feed my wife
<viper12> :D
<viper12> I do have one question......what should uname -a be reporting after this update? (just ensuring that something didn't bork with the synaptic upgrade.)
<zul> 2.6.10-4-686 you can do a dpkg -l | grep linux
<viper12> zul, the info was just to make sure it wasn't s'posed to be 5-686 or somesuch.  I checked forums before updating, and didn't see any issues getting reported one way or 'nuther.  just me bein' paranoid. lol
<zul> k...bbiab
<mdz> zul: I'll be here for some hours yet
* lamont curses and bangs head on desk
<lamont> who's are favorite freenode op?
* mode/#ubuntu-kernel [+o lamont]  by Md
<lamont> there.  all better
<viper12> Just added the xorg.conf changes to get the nvidia card to at least bring up the gui.  Oh, I also commented out the acceleration stuff to ensure it would work.  (haven't tested it with acelleration enabled.)
<viper12> (that's to 7485's bug report.)
* lamont gives mdz/jdub op privs in this channel too
* mode/#ubuntu-kernel [-o lamont]  by lamont
* mode/#ubuntu-kernel [+o lamont]  by ChanServ
* mode/#ubuntu-kernel [-o lamont]  by lamont
<lamont> cool
<viper12> gonna try to leave acelleration enabled and see if it barfs.
<viper12> spell check needed for my constant misspelling of acceleration. lmao
<viper12> no difference.  just changing the driver from 'nvidia' to 'nv' is all that's needed to bring up gdm.  
<viper12> wondered when you'd pop over crimsun.  :)
<dilinger> where's kernel-team@ubuntu.com--2005 ?
<dilinger> anyone?  where can i get at the arch repository?
<lamont> dilinger: http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005
<lamont> at least for now...
<dilinger> thanks
<lamont> dilinger: and that's a baz archive,
<lamont> although that might only matter for commits - not sure
<dilinger> yea, definitely baz only
<dilinger> kernel-debian--pre27--2.6.10 is the recommended branch for development stuff?
<dilinger> or is there something more bleeding edge?
<lamont> mainline is where we merge to when we upload
<lamont> --pre27 is where we're committing changes prior to the upload
<lamont> zul is currently tracking down the modules-abi b0rkage introduced in -26, that fix will be -27.
<dilinger> ok, thanks
<lamont> then we'll have --pre28 to play on...
<lamont> alas, zul does not have commit access to the archive.
<lamont> so, with luck, he'll have a readable archive somewhere with the changes, but more likely, -27 will consist only of 'remove these patches from 00list-26 and call it 00list-27'
<lamont> which will then need to get reflected in baz.
* lamont will be back in a bit
<zul> dilinger: you are getting involved with us?
<dilinger> zul: now that i've got a working ubuntu machine, that is the intention
<zul> cool
<dilinger> also, gregkh and chrisw have been receptive to my patches for 2.6.x.y
<dilinger> so it's looking like -as won't be necessary after all
<zul> neet...welcome aboard
<dilinger> more free time for me :)
<crimsun> yeah, I was wondering if -as would morph into the .x.y :)
<zul>   CC [M]   drivers/net/wireless/adm8211/ieee80211.o
<dilinger> do you guys ever override revision in debian/rules?
<zul> i dont think so
* dilinger wonders if his code to get the previous revision is going to break if, for example, 25.3 is used as revision, but 26 exists
<dilinger> shouldn't matter, though, it's not sorted.  nm.
<lamont> dilinger: cool.
* lamont heads off for a weekend of fun with his 9 year-old.
<zul> c ya lamont
<lamont> should be back sometime on monday (dunno if first thing, or late in the day though...)
<lamont> zul: thanks for dealing with the abi mess, eh?
<zul> no probelm ill do the best that i can
<zul> gah...i so much hate iNOTify
<zul> did i mention i hate inotify?
<crimsun> I don't hate it as much now that I boot with "noinotify" ;-)
<zul> wanna trade? :)
<crimsun> heheh
<zul> later
<fabbione> hmmmm
<fabbione> wtf
<fabbione> how come the ABI didn't break with me?
<fabbione> i have 686 -4
<fabbione> and i have nvidia for not crying out loud
<fabbione> it's the first frigging test i do here
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | kernel-team@ubuntu.com--2005/kernel-debian--pre28--2.6.10
<zul> morning
<fabbione> hey zul
<zul> what fun that was last night ;)
<fabbione> uh?
<zul> the abi breakage
<fabbione> fuck nvidia and all the binary shit 
<zul> yep
<zul> i totally agree fuck them all
<fabbione> and force people to reboot after a kernel upgrade
<fabbione> all this mess it's only to avoid people to reboot
<fabbione> it is NOT worth the pain
<zul> so we are back to 0.18 i take it
<zul> oh yeah thanks for the patching unpactching stuff
<fabbione> no problem
<zul> its alot better now
<zul> alot more tolerable
<fabbione> oh yeah
<fabbione> guys i am going to commit some stuff to pre28
<fabbione> but i cannot commit all the patches
<fabbione> because i am not allowed to disclose them
<fabbione> not before the 16 at least
<fabbione> in the meanwhile i will be able to test them
<zul> uh ok
<zul> huh? why didnt baz get pre-0.28?
<fabbione> pre28
<mjg59> I'm going to have various patches to fix stuff on these HPs
<fabbione> mjg59: please send them asap
<fabbione> we start to have time issue now for testing
<mjg59> fabbione: Ok. First one will be easy, the others haven't been written now.
<fabbione> and it must be very good crack
<mjg59> One of them is Obviously Correct
* mjg59 wonders about '7490
<fabbione> hmmm
<fabbione> that's weird
<zul> ok...now to go squish bugs
<mjg59> fabbione: Last thing I see in the strace is the ioctl, and then the machine freezes
<mjg59> Doesn't seem to make any difference whether or not there's a cable plugged in
<mjg59> I should run mii-diag on it and see if it hangs
<fabbione> good idea
<zul> bonjour
<jbailey> hla, ca va?
<zul> ca ba bien et toi?
<jbailey> tres bien.  Je suis un peux fatiguer.  Je me suis couch a... 02h30?  qqc comme ca.  jblack m'enseignait baz.
<zul> heh, moi et aussi fatiguer, mais je prefere parlez en anglais parce que tout le monde parlez anglais
<zul> my french sucks
<zul> tabarnac
<zul> bbiab need breakfast
<zul> hey fabbione have you got the ksysall-race patch [PATCH]  Fix kallsyms/insmod/rmmod race
<fabbione> zul: not sure..
<fabbione> the tree is there... just get it ;)
<zul> yeah i konw...well im including it in my patch set you can do what you want with it :)
<fabbione> zul: but i don't even know where your patchset is!
<zul> im working on it
<dilinger> yay
<dilinger> http://www.acm.rpi.edu/~dilinger/ubuntu/abilog
<zul> sweet
<fabbione> re
<fabbione> interesting
<fabbione> so only that symbol changed?
<fabbione> and it did all that mess?
#ubuntu-kernel 2005-03-24
<dilinger> that was my personal test
<dilinger> i changed ppp_register_channel to return a long instead of an int
<fabbione> yes
<fabbione> ah ok
<dilinger> i also did another test where i added ppp_do_stuff, exported it, and the build warned me about it (but didn't fail)
<fabbione> morning
<Mithrandir> moo
<fabbione> hey Mith
<fabbione> Mithrandir: you have amd64 handy, right?
<Mithrandir> about 5m away, yes.
<fabbione> Mithrandir: mind to test mplayer on it?
<fabbione> i manage to build it yesterday for amd64
<fabbione> but i can't test it here
<Mithrandir> sure; URL?
<fabbione> it's in the archive
<fabbione> multiverse
<Mithrandir> checking now
<Mithrandir> any particular format or just $random_video?
<fabbione> whatever
<fabbione> i am not sure about codecs and stuff
<fabbione> just try to play something 
<fabbione> for me it's enought it doesn't crash
<Mithrandir> it depends on livavcodec2 which doesn't seem to be available
<Mithrandir> (or, do you want me to test mplayer-amd64 or mplayer?)
<fabbione> it depends on it?
<fabbione> how can it depends on it if just uses dh_shlib at build
<Mithrandir> sorry, I forgot to run update first
<Mithrandir> downloading now, ETA 6-ish minutes
<fabbione> eheh ok
<fabbione> no rush
<mjg59> Waa.
* mjg59 has to figure out why the IDE bus doesn't resume on the 6220
<mjg59> fabbione: Ok, mii-diag kills the machine in the same way
<mjg59> b44.c hasn't really been touched in months
<fabbione> hmmm
<fabbione> no idea really
<fabbione> mjg59:  7502 <- that's all your :-)
<mjg59> fabbione: He's running an ancient kernel. Tell him to upgrade.
<mjg59> Oh, no, hang on
<mjg59> Get him to try the latest 2.6.10 and get the dmesg from that
<zul> morning
<fabbione> zul!
<zul> hey fabbione whats up?
<fabbione> not much
<fabbione> merging more security bits
<fabbione> i have an endless pile to merge from debian
<zul> yah..
<fabbione> i have the feeling that one of this security thing is breaking the ABI
<fabbione> it's just taking too long to compile
<fabbione> = ccache is invalidated
<zul> are you going to be using dilingers abi stuff?
<fabbione> zul: yes.
<fabbione> i need to rebuild a -27 to be able to test it
<fabbione> but there is no hurry
<zul> good good
<fabbione> we can't upload the kernel as is before the 16th
<fabbione> i still cannot commit one of the patches
<zul> ok...brb i have to reboot
<fabbione> i need to get sex... iwnbb
* crimsun falls over laughing
<zul> thats good no abi brekage
<zul> fabbione: so you are heading out?
<fabbione> pretty soon yes
<fabbione> friends are coming for afternoon coffee/cake
<zul> k...because i need breakfast since i just got up
<zul> cool
<fabbione> ehhe
<fabbione> i will be back tomorrow
<fabbione> also wife is coming back later this afternoon
<zul> ok have fun then
<zul> where did she go?
<fabbione> and i am afraid she expects me to spend time with her
<fabbione> to her sister
<zul> lol
<fabbione> for the weekend
<fabbione> it was her niece bd
<zul> ah i see...i was at my parents in law last night so i wasnt around much
<crimsun> oh nice.
<crimsun> well have a good time!
<fabbione> parents in law = teh sux!
<zul> not mine
<fabbione> they are usually worst than an ABI breakage
<zul> my mother in law takes me to hockey games 
<fabbione> at least you can fix the ABI
<fabbione> ah that's rad
<zul> and my father in law is learning about linux at least
<fabbione> everytime i go to my in laws is a race for who eat more and they start speaking danish all the time
<fabbione> so i get bored to death
<zul> hmmm...maybe i should give him a live cd
<fabbione> maybe you should ubuntify him
<zul> heh...mine do that but its french
<zul> i should 
<mjg59> Ah!
<mjg59> The mii ioctl works if the interface is up, but hangs the machine if it's down.
<fabbione> hmmmm
<zul> i need to pee
<fabbione> mjg59: that should be easy to isolate.. i think
<fabbione> anyway i am off
<zul> c ya fabbione 
<zul> im off to run some errands and get breakfast
<mjg59> Actually, it works as long as the interface has been brought up at least once
<mjg59> Hm.
<zul> lol
<mjg59> If it's never been brought up, it hangs.
<mjg59> This ought to be easy enough, then...
<zul> i think going to blacklist some acpi bioses today when i get back
<zul> later
* mjg59 sorts the b44 issue
<smurfix> Rosetta bugs ("A system error occurred") go where?
<smurfix> EWRONGCHANNEL
<zul> not this channel
<mdz> smurfix: #rosetta, or malone
* dilinger laughs
<dilinger> <fabbione> at least you can fix the ABI
#ubuntu-kernel 2005-03-25
<zul> evening
<zul> cool...my crappy usb camera just works
<fabbione> morning
<fabbione> dilinger: testing the patch now :-)
<fabbione> ah he is not here
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | kernel-team@ubuntu.com--2005/kernel-debian--pre28--2.6.10 | check the new abichecker code and GET familiar with it.
<zul> morning
<fabbione> hey zul
<zul> hey fabbione how is it going?
<zul> oh how i hate windows media player
<jbailey> You don't have access to a better media player
<jbailey> ?
<zul> yeah but its windows that im on at work though as my main pc
<zul> if i run winamp the windows media player just starts at the same time
* zul kicks puter
<zul> *sigh* i dont think you need to put your full address in your wiki page ;)
<zul> http://www.ubuntulinux.org/wiki/DongCalmada
<jbailey> Ah, I was thinking winamp, but couldn't remember what it was called. =)
<zul> T-Bone disapeared?
<zul> i havent seen him all weekend
<jbailey> He may have for a bit.  He's really pissed.
<zul> oh?
<jbailey> He's been working his brains out to try and get ia64 into a release state for Hoary because he was told that if he met certain requirements it would be let in.
<jbailey> Basically without any further discussion during the dev meeting, he was told otherwise.
<zul> oh right
<jbailey> Clearly and publiclly.
<fabbione> zul: i am ok thanks. please see /t
<zul> fabbione: ok will do
<fabbione> jbailey: clearly and public the point is that if it wasn't for me pushing him to start testing ia64
<fabbione> nobody was going to do so
<fabbione> i don't have an ia64 myself and even tho i did take care of producing an ia64 kernel
<fabbione> so clearly he did ask for the buildd & co
<fabbione> and he expected us to do the rest
<fabbione> well that was not the original agreement
<fabbione> so he has nothing to be pissed
<jbailey> fabbione: As if emotions are clearly ruled by logic. =)
<jbailey> He simply had his heart set on it, and beleived that if he met a couple requirements, it would be accepted.  It didn't happen that way and he's angry about it.
<fabbione> well he didn't meet the requirement
<jbailey> Right.
<fabbione> so there is noone to blame
<fabbione> i was hoping to get sparc for hoary, but i can see it myself that it won't make
<fabbione> but that doesn't mean that i am pissed about it
<fabbione> i know that i have been doing a lot of work
<fabbione> and that it will all flow in bendy
<fabbione> (and note that i don't even have the buildds at the dc)
<fabbione> (so it took me ages more to get stuff in place)
<jbailey> Sure.  But we don't all react the same way to things.
<fabbione> to be hounest i think he is a bit too impulsive
<fabbione> but that's just my opinion
<fabbione> jbailey: but yes. i fully agree with you. we don't react all the same way
<jbailey> We need impulsive people in the world to suggest the things that us stodgy people would never otherwise consider. =)
<jbailey> But it probably sucks to be impulsive and to run against brick walls all the time. =)
<fabbione> jbailey: STFU! ARE YOU GOING TO CONSIDER THIS? :P
<zul> now now :)
<fabbione> just kidding ;)
<fabbione> zul: jb and i know each other
<fabbione> from DC3 and DC4
<zul> i know i was be kidding as well
<jbailey> zul: Don't worry.  There's nothing in the SC keeping Fabio and I from getting drunk and slugging it out in a bar at UDU. ;)
<fabbione> (tho he still needs to sign my gpg key)
<zul> jbailey: i would pay to see that ;)
<fabbione> jbailey: at UDU it will be the 3rd time we meet :-)
<zul> *sniff* im the outsider :)
<fabbione> jbailey: it's time for you to consider to sign my key ;)
<jbailey> fabbione: Yeah, I know.  I have to find that folder. =(
<fabbione> nah don't worry
<jbailey> fabbione: I left it too long, and have moved everything.  I'm not sure where it is.
<fabbione> let's do it at UDU
<fabbione> jbailey: also because since DC4 i have a new key too
<fabbione> for ubuntu/canonical
<jbailey> at UDU I'll probably have met people enough times that it'll be worth just playing along with the keysigning and dropping the occasional person out.
<jbailey> I think I'll actually know most people there.
<fabbione> jbailey: yeah
<fabbione> that's the easiest
<jbailey> I've been trying to decide whether to do that.
<jbailey> (a new key for Ubuntu/Canonical)
<fabbione> i did.
<fabbione> for one simple reason
<jbailey> I don't like the idea of putting work email addresses on my home keys.
<fabbione> i don't like to mix private/debian/work stuff
<fabbione> exaclty
<jbailey> That's why I use the imap server instead of having stuff forwarded to my home account, too.
<fabbione> we all remember when lamont had to revoke his hp uid
<zul> well not all 
<fabbione> i use an imap server at home for speed reasons, but separate folders/accounts
<fabbione> zul: there a huge shake in WOT
<fabbione> that was tracked by all the graphers around
<zul> ah ok
<fabbione> i think he lost something like 20 positions in the WOt in one shot
<fabbione> that is quite a lot
<jbailey> fabbione: Yeah, I just figured out the local synchronisation bits in evolution.
<jbailey> fabbione: I did it while working at the web caf last week so I could read my email at home.
<fabbione> tbh i would still be using pine but i wanted to try a GUI application and i landed with thunderbird
<fabbione> but i can switch anytime
<fabbione> since all the filtering is done on the server
<fabbione> i just have to resub to the different mailboxes
<jbailey> I started using evo when my wife switched from mutt (she had been using elm at her school)
<jbailey> She wanted a graphical interface, and I wanted to be able to answer her questions.
<zul> isnt that sweet 
<jbailey> zul: It's marriage-preserving ;)
<fabbione> eehhehe
<zul> mine doesnt work like that
<fabbione> humpf i have almost finished the sync with debian 2.6.10-5
<fabbione> and i still miss another release to check
<fabbione> but now we have the 31337 abi checker to help us
<zul> debian's hotplug is suppose to fix a bunch of firmware issues apparently
<fabbione> i am pretty sure it would need merge to be ported
<zul> oooh...are linux sys admin upgraded to hoary
<fabbione> ???
<zul> sorry our linux sys admin here at work upgraded to hoary
<fabbione> ah
<zul> still too early in the morning
<fabbione> you should have told them to wait a sec
<zul> too late
<fabbione> tomorrow we are going out with this big fat kernel
<zul> with all the security updates
<fabbione> yup
<fabbione> and a few tons of bug fixes
<fabbione> zul: btw.. your patches?
<zul> yep getting them ready now
<fabbione> i can't wait forever to get them
<fabbione> ok
* fabbione checks the abi
<zul> fabbione: http://zulinux.homelinux.net/ubuntu/kernel/2.6.10-28/
<fabbione> hmmmmmm
<fabbione> 6492 - no support for dell's version of sound blaster em101k
<fabbione> how bad is this one?
<fabbione> 55K of patch....
<fabbione> are you sure it works?
<fabbione> i remember the bk commit to head
<fabbione> and it was pretty intrusive on the emu10k1 too
<zul> havent tested it but it was pulled from bitkeeper and applies cleanly and compile cleanly
* fabbione sighs...
<zul> dont have to include it if you want but it works with 2.6.11 apparenly
<fabbione> did you pull only the emu10k1x patch or did you grab it from 2.6.11?
<fabbione> sory let me rephrase
<zul> only the emu101kx from bitkeeper
<fabbione> did you take that patch from the first commit or from 2.6.11 or from bk (like today)?
<fabbione> ok
<fabbione> hmmm
<fabbione> i need to check on that
<fabbione> i am not happy to add new drivers now
<fabbione> specially because none of us can test them
<zul> thats cool
<zul> http://linux.bkbits.net:8080/linux-2.5/gnupatch@41d9223fXVy6-SVqQ9fPagcX9jSi8Q
<zul> but the other patches should be ok?
<fabbione> did you check if there were any updates from the first commit?
<zul> havent been updated in 13weeks
<fabbione> so it has been stable since first commit...
<zul> afaik yes
<fabbione> can you please triple check?
<fabbione> i don't mind to add it
<fabbione> i know it compiles
<zul> yes i can do that when i get home tonight
<fabbione> we saw that in 2.6.11-pre
<fabbione> well i guess i can just check with bk here
<lamont> fabbione: from 13 to > 100 is not 20 positions...
<lamont> morning all
<zul> hey lamont
<fabbione> hey lamont 
<zul> but the other patches should be fine
<fabbione> lamont: well i couldn't really remember
<fabbione> keyboard-i8042 has a possible ABI change
<fabbione> anyway we need to bump the abi
<zul> bleah..when you bump the abi put the inotify 0.20 stuff back in
<lamont> fabbione: that was also about the time that they actually started paying attention to the revokations in the WoT graphs - I wasn't solely responsible for the dip
<lamont> zul: was it just inotify that was bad?
<zul> lamont: yep looks like it
<lamont> inotify sure seems to be shooting for most cursed status
<zul> by the time everything got compiled on saturday fabbione already uploaded a new kernel
<fabbione> http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.10-2.6.10/debian/patches/087-ext3_graceful_corruption_fixes.dpatch?op=file&rev=0&sc=0
<lamont> ouc
<lamont> h
<fabbione> this is the patch that breaks the ABI
<lamont> ah, ok
<fabbione> tell me if it is worth the troubles according to your opinion
<zul> er..no
<zul> fo inotify
<fabbione> zul: did you read the patch name or the entire changelog?
<zul> i was talking about inotify
<fabbione> ah ok
<fabbione> please guys look at that patch and give me your opinion
<fabbione> a yes here means changing the ABI
<fabbione> there might more patches that can do that
<zul> well how often does ext3 fail?
<fabbione> i am not sure yet
<fabbione> i only synced up to 2.6.10-5 in debian
<fabbione> zul: ENOCLUE
<fabbione> i really have no idea how often it can happen
<mjg59> fabbione: Did you get my b44 patch
<fabbione> mjg59: i read it in the mail yes..
<fabbione> mjg59: haven't check it 100% yet
<fabbione> mjg59: i have a pile of security updates under check right now.. sorry
<fabbione> it might be for -29
<mjg59> fabbione: No problem
<zul> ++
<fabbione> mjg59: what is your opinion on the above ext3 patch?
<fabbione> zul: ++ to what?
<zul> fabbione: i say go for it
<zul> belt and suspenders
<zul> bumping the abi anyways so go for it
<fabbione> hmmmm
<fabbione> why anyway?
<fabbione> this is the only patch atm that breaks the ABI
<fabbione> #   This is easily reproduced with a sample ext3 fs image containing an inode
<fabbione> #   whose direct and indirect blocks refer to a block bitmap block.  Allocating
<fabbione> #   new blocks and then deleting that inode will BUG() with:
<fabbione> #   
<fabbione> #   Assertion failure in journal_forget() at fs/jbd/transaction.c:1228:
<fabbione> #   "!jh->b_committed_data"
<fabbione> no
<fabbione> we can skip it
<fabbione> even if it is an annoying problem
<fabbione> it is not necessary to have
<fabbione> but let see lamont and mjg59 
<lamont> seems pretty innocuous
<mjg59> I think it's generally preferable to avoid corrupt filesystems breaking the kernel...
<mjg59> It's better to bump the ABI now than to find we need to again later on
<Mithrandir> mjg59: did you talk to Naima last night?
<Mithrandir> mjg59: she had some "interesting" experiences where she did a suspend, boot normally, use the box for a little, then boot with resume.
<fabbione> ok so we will go for it and break the ABI
<lamont> Mithrandir: that would be, um, interesting. to be sure
<lamont> fabbione: btw, you ROCK.
<mjg59> Mithrandir: Yeah, I talked to her about that.
<Mithrandir> lamont: yeah; think it should then say "lalala, you've booted in the meantime, I won't resume, lalala" or something.
<mjg59> The swapon script should check whether the swap partition has a suspend signature, and if so mkswap it
<fabbione> lamont: what i did NOT do this time to rock? ;)
<Mithrandir> mjg59: I think it should refuse to resume if you've booted in the meantime.
<mjg59> Mithrandir: How could it know?
<mjg59> We can't touch the filesystem at that point
<Mithrandir> you can touch the filesystem before suspending
<Mithrandir> and remove the file when booting normally
<mjg59> But we can't read from the filesystem
<Mithrandir> or something like that.
<Mithrandir> hm, that sucks.
<mjg59> If we mount the filesystem, the journal gets replayed
<Mithrandir> even r/o?
<mjg59> Yes
<Mithrandir> that sucks.
<mjg59> Indeed
<mjg59> mkswapping over the resume partition on boot fixes all but the most pathological cases
<Mithrandir> true enough
<lamont> fabbione: I finally got to my email and read your replies to pitti
<fabbione> lamont: ah eheheh
<fabbione> lamont: wait to do a baz update :-)
<mjg59> fabbione: The sooner the b44 patch can go in the better from the dealing with HP point of view, but feel free to leave it to -29 if it's a problem
<lamont> fabbione: you mean wait until I do? or that I should wait before I do?
<fabbione> mjg59: i think i can make it for -28 given that we will break the ABI
<fabbione> lamont: just wait a couple of more minutes
<mjg59> fabbione: Ok, thanks
<fabbione> mjg59: does it work for you?
<mjg59> fabbione: It stops the machine from freezing when HAL starts, yes
<mjg59> It means that mii ioctls won't do anything until the interface has been brought up
<fabbione> yes i see
<mjg59> I'm not sure if that's the best approach, but it works
<fabbione> it looks sane to me
<fabbione> if the iface is down .. no ioctl
<mjg59> It may mean that we don't get auto-interface up on cable plug in that chipset, but I don't think we support that anyway yet
<fabbione> no we don't
<fabbione> mjg59: queued
<fabbione> guys you can baz update now ;)
<fabbione> no ABI bump done at packaging level YET
<mjg59> fabbione: Rocking. Thanks.
<fabbione> no problem
<fabbione> upload will be tomorrow after 14:00 UTC
<zul> none of my stuff made it in?
<fabbione> zul: hell gimme a break
<fabbione> i am working on it
<fabbione> this is the work of the last 3 hours of merging
<zul> fabbione: heh sorry
<zul> sorry mybad
<fabbione> eheh
<fabbione> at least now we know 100% that the abi checker is working properly
<fabbione> who feel like preparing l-r-m for tomorrow?
<fabbione> actually we need to tell Kamion too
<zul> i need to get my baz archive setup eventually
<lamont> zul: any home machines have apache running on them?
<zul> yep
<lamont> because that's the simplest way to publish
<zul> its the same machine where i put my patches for you guys
<lamont> it can either be your actual repository (and you use an sftp:// url while we use http://), or it could be a mirror of your actual repository
<zul> ok...i did a little reading about it this weekend
<zul> it will probably be something like http://zulinux.homelinux.net/Archive or somthing im not sure yet
<fabbione> zul: anything is fine for us
<fabbione> sftp would require us to have access to your box
<fabbione> while with http we can just merge from you
<zul> its going to be http i dont trust you fabbione ;)
<fabbione> that's a good point to start from
<fabbione> considering i have kernel privileges on your machine :-)
<zul> yeah i want to sleep at night :)
<lamont> LOL
<Mithrandir> fabbione: you're assuming he runs _your_ kernel on his box.. he might be... running NetBSD! :P
<zul> and it might be chrooted
<fabbione> Mithrandir: i still have commit access to XORG CVS :-) 
<fabbione> shhh
<fabbione> zul: other than the emu10kx.. are the other patches from HEAD or did you grab them around?
<Mithrandir> zul: chroots won't help you if he has your kernel
<zul> fabbione: grabbed them around. the keyboard is from 2.6.10-ac9 
<fabbione> but i would have access to the main host even from a chroot that has proc mounted
<zul> the nforce one is from linux-usb ml and the via-oops is from head
<zul> fine ill just turn my box OFF then 
<fabbione> ok
<zul> bwaha...its alive! its alive!! sorry
<fabbione> ehehhe
<fabbione> zul: baz update :-()
<fabbione> your bits are merged
<fabbione> other than the emu10k1x
<fabbione> i want to look at it again
<fabbione> time to merge mjg59 
<zul> sweet
<fabbione>   Changes by Matthew Garrett:
<fabbione>   * b44 should not accept ioctls if the interface is down:
<fabbione>     - Add patch fix-b44.dpatch.
<fabbione>     (Closes: #7490)
<fabbione> mjg59: ok for you? or do you want me to change something else?
<zul> you can ask the guy who requested the em101kx to test it
<fabbione> zul: there won't be time for that
<fabbione> i can't release binary image before tomorrow
<zul> oh yes...time 
<fabbione> not even for testing
<mjg59> fabbione: No, that's fine
<fabbione> mjg59: ok
<lamont> fabbione: one more thing for -28...
<lamont>         kernel-wedge find-dups 2.6.10-4-hppa64
<lamont> find: lib: No such file or directory
<lamont> nfs-modules-2.6.10-4-hppa32-di will be empty
<fabbione> uh weird...
<lamont> hrm.. wonder how many more there were before you removed the || true
* fabbione checks
<fabbione> oh that's easy
<fabbione> nfs is compiled in on hppa
<fabbione> there are no modules
<lamont> nfs-modules... is the only one that says it'll be empty
<fabbione> yes
<fabbione> and it is empty
<fabbione> it's enough to remove nfs-modules.lnk
<fabbione> in debian/d-i/hppa/modules/hppa/
<fabbione> this is thanks to our super alligned configs
<fabbione> that 2 persons (one of which in this chan right now) should have analized for hoary
<fabbione> we don't make names
<fabbione> only surnamed
<fabbione> surnames
<fabbione> eh Short?
<fabbione> doesn't it ring a bell?
<zul> someone called my name?
<fabbione> eheheh
<lamont> fabbione: maybe he didn't analyze the bastard stepchildren
<fabbione> yeah
<lamont> the find: lib: No such file or directory is kind of interesting as well.. or is that normal?
<fabbione> it is normal
<fabbione> since debian/nfs-modules-<whatever>/lib isn't there at all
<fabbione> no modules -> no need to create the dir
<fabbione> applying patch fix-b44 to ./ ... failed.
<fabbione> doh!
<fabbione> ah yeah
<fabbione> mjg59: note for the next time: send me a dpatch :-)
<fabbione> baz commit -s'Merge mjg59' -- changelog patches/fix-b44.dpatch patches/00list-28
<fabbione> These files would be source but lack inventory ids (`baz add' perhaps?):
<fabbione> patches/stolen-from-head_ppp-no-dos.dpatch
<fabbione> M  changelog
<fabbione> make-changeset-files: file missing from ORIG tree (patches/fix-b44.dpatch)
<fabbione> what the hell is wrong with baz?
<fabbione> hey
<ddaa> hey
<fabbione> i am getting a really strange error with baz
<fabbione> baz commit -s'Merge mjg59' -- changelog patches/fix-b44.dpatch patches/00list-28
<fabbione> make-changeset-files: file missing from ORIG tree (patches/fix-b44.dpatch)
<fabbione> but the file has been added
<ddaa> you cannot do partial commit (yet) when the inventory was changed
<ddaa> hu... not right
<fabbione> i did partial commits before and it was working fine
<ddaa> you cannot do partial commit for new/removed/renamed files
<fabbione> ah
<fabbione> suckage
<fabbione> ok
<ddaa> That can be fixed.
<ddaa> The issue is that currently partial commit does not do inventory, so it cannot tell if the file is really new or just renamed.
<ddaa> probably it will be time to fix it when there will be a "baz edit" to make life livable with kernel-sized trees.
<ddaa> But i suggest you file a bug for the obscure error message.
<fabbione> ddaa: malone or bugzilla?
<ddaa> IIRC we are officially in malone again
<ddaa> mark's fault
<fabbione> ahhh
<fabbione> i don't want to know :-)
<fabbione> thanks ddaa.. that was it :-)
<ddaa> be my guest
<fabbione> lamont: hppa ftbfs is fixed
<fabbione> or it should be at least
<zul> lunch
<lamont> fabbione: thansk
<fabbione> no problem
<fabbione> lamont: do you still have -27 on your buildd?
<fabbione> or did you trash it?
<fabbione> well actually.. no
<fabbione> it's pointless
<fabbione> nevermind
<lamont> head build-hoary/chroot-hoary/build/buildd/linux-source-2.6.10-2.6.10/debian/changelog 
<lamont> linux-source-2.6.10 (2.6.10-27) hoary; urgency=low
<lamont> uh, yeah. :-)
<fabbione> i was going to ask you for the abi files, but we already know they will change
<fabbione> so it's useless :-)
<lamont> ah, ok
<fabbione> zul: the emu10k1x driver has been updated regularlly. and the last commit is from 4 days ago.
<fabbione> zul: just FYI.
<fabbione> i am going to see if it can be built
<lamont> fire call
<svenl> fabbione: hi you.
<fabbione> re
<fabbione> i was checking the code...
<fabbione> i don't really understand why you use arch_initcall() in the beginning
<fabbione> but i need to look trough all the code
<fabbione> just gimme a few secs.. i need .11 orig tar.gz
<fabbione> oh there is no orig in the archive...
<fabbione> humpf...
<fabbione> `linux-2.6.11.tar.gz' at 1826600 (3%) 76.9K/s eta:10m [Receiving data]   
<fabbione> svenl: getting there.. slowly :-)
<svenl> fabbione: well, code is not from me, at first it was to initialize the arch-specific part, which should not be in the drivers/net/mv643xx_eth.c driver (see other marvell patch)
<svenl> fabbione: i had some code doing OF device-tree probing in place which worked, but hch suggested doing pci_find_device instead.
<fabbione> svenl: ok.. let's see one thing at a time
<fabbione> this is a network driver right?
<svenl> fabbione: sure, a mips-and-ppc driver.
<fabbione> so in the first place i would move it to drivers/net/<where_appropriate> and do a proper Kconfig entry for it
<fabbione> because a network card is initialized much later than the arch specific code
<svenl> fabbione: Dale Fornsworth from montavista isolated all the arch independent code and moved them into arch/ppc|mips.
<svenl> fabbione: the only thing i am really doing is setting a couple of arch-specific info, like where the NB chip is mapped, and what interrupt to use, in the ad-hoc structure that the arch-indep driver then uses.
<fabbione> hmmmm
<fabbione> i think it is a bad idea because it will spread the code all over the place
<fabbione> but anyway
<svenl> fabbione: so my only problem is to detect the northbridge through its pci id, and then set the stuff with platform_add_devices.
<svenl> arch_initcall is called before the pci tree is filled, but there should be a way to have mv643xx_eth_add_pds executed later, after the pci tree has been filled.
<fabbione> arch_initcall is a synonimous for module_init() btw
<fabbione> #define arch_initcall(fn)               module_init(fn)
<fabbione> from include/linux/init.h
<fabbione> the problem is that pci code is initizialized as driver later in the boot process
<svenl> yep, guessed such as pci_devices was empty :/
<fabbione> hmmmmm
<zul> fabbione: cool moe d
<fabbione> i think you will also hit another problem.. PCI IRQ are assigned after PCI is initialized..
<fabbione> this is my best guess
<svenl> fabbione: this is no problem, as we only tell the arch-indep code which pci irq to use, and it is dicted by what the open-firmware initializes at a lower level though.
<svenl> fabbione: so, i understand you don't know either, and i should better wait for hch and ask him ? :)
<fabbione> svenl: well i am trying to help.. not knowing the arch doesn't make it easier
<svenl> fabbione: it was no critic.
<svenl> fabbione: actually, my only question is if there is a equivalent to arch_initcall that will happen after the pci initialization step.
<svenl> fabbione: but i will go ask other people later if i don't find it by myself.
<fabbione> svenl: i think you cannot call pci_find_device at all there
<fabbione> if do a couple grep in platform/
<fabbione> you will notice that the only driver that does it
<fabbione> is a mobo driver
<fabbione> chestnut.c
<svenl> fabbione: yep.
<fabbione> in a special call only that is used to fix a pci parameter if a cache is set in a certain way
<fabbione> so it basically happens after the mobo and pci are initialized
<svenl> fabbione: don't worry, i am going to ask hch as soon as he is back,
<fabbione> i think you really can't call it there
<fabbione> nah it's ok.. it's not like killing my time :-)
<svenl> fabbione: i am not sure, since the code is only linked in, and its only link to the call is rge arch_initcall.
<svenl> fabbione: so the code could be anywhere.
<fabbione> yes but i am more thinking in terms of code execution order
<svenl> fabbione: the other places the code is initialized is in arch/ppc/platforms/mv64360.c, but it is a mobo driver.
<fabbione> yes i saw that
<fabbione> i think it would thousand times easier to just move it drivers/net
<svenl> and same for mips, but those don't probe, they are configured at toplevel Kconfig.
<fabbione> when the pci bus is initialized
<svenl> fabbione: after Dale just removed all arch calls from there and it just got accepted upstream ? 
<fabbione> well he is not God you know :-)
<fabbione> if something cannot be done in platform/
<fabbione> ... you can guess what i mean
<mdz> fabbione: wow, how was the kernel build time reduced for powerpc?
<svenl> fabbione: yep, but he, hch, benh and Mark Greer told me that it was not a good idea. I guess benh is God where ppc/linux is concerned.
<mdz> fabbione: CONCURRENCY_LEVEL?
<svenl> fabbione: and to add to this the marvell is no pci device, it is not present in the pci tree.
<fabbione> svenl: ah hold on!
<fabbione> svenl: check the call to pci_:find_device in chestnut.c
<fabbione> it wants a dev structure as last parameter
<fabbione> not a NULL
<fabbione> mdz: yeps :-)
<fabbione> mdz: i set CONCURRENCY_LEVEL as Num of cpu * 2
<fabbione> mdz: i could go further since the code is ccached
<fabbione> pro = code ccached = tons of times faster
<fabbione> cons = no ccache = kill buildd for a little while
<mdz> I usually do num_cpu + 1
<mdz> did you do some tests?
<svenl> fabbione: nope.         n = from ? from->global_list.next : pci_devices.next;
<fabbione> mdz: yes. locally.
<svenl> it it is null, it will searcg at the root.
<fabbione> mdz: num_cpu * 2 is fine
<fabbione> svenl: yes. i didn't say it must be a filled struct..
<fabbione> but it might expect one there as parameter
<fabbione> tho i am not 100% sure..
<fabbione> but i would still try for the sake of it
<svenl> fabbione: ok, thanks.
<fabbione> sorry that i can't help more :(
<mdz> fabbione: do you use getconf to query the number of CPUs?
<svenl> fabbione: i think that i need to investigate with Dale and/or hch about this issue, and what their intention is.
<svenl> fabbione: no problem.
<fabbione> mdz: no. cat /proc/cpuinfo |grep ^processor 
<mdz> fabbione: getconf should be more portable across architectures
<fabbione> mdz: so is /proc/cpuinfo for our arches :-)
<mdz> and centralizes the code
<fabbione> i will check it tomorrow
<mdz> ok
<fabbione> it's 13 hours that i am here
<fabbione> and i am kinda tired
<fabbione> mdz: did you ever used getconf ?
<fabbione> i can't see anything that tells me how many processors there are in the system.. well i must be very tired
<mdz> fabbione: apt has used it forever
<mdz> for the same purpose
<mdz> getconf _NPROCESSORS_ONLN
<fabbione> usr/bin/getconf                                             base/libc6
<fabbione> interesting
<fabbione> fabbione@concordia:~ $ getconf _NPROCESSORS_ONLN
<fabbione> -bash: getconf: command not found
<fabbione> wow :-)
<fabbione> mdz: what does it returns on hiperthreaded proc?
<fabbione> 1 proc
<fabbione> or 2 (if the hyper is 2)
<fabbione> ?
<lamont> morning T-Bone 
<T-Bone> hey ladude!
<fabbione> hey T-Bone 
<T-Bone> konichiwa!
<T-Bone> ola fabbione
<fabbione> T-Bone: i did some syncing with Debian, including ia64 patches (up to 2.6.10-5)
<fabbione> i am going to parse 2.6.10-6 tomorrow morning
<T-Bone> cool
<fabbione> let me know if you need more stuff that what i took
<T-Bone> don't think so
<fabbione> we are going to bump the ABI
<fabbione> i didn't take all the debian patches
<fabbione> that's why i am asking
<fabbione> if you have time give it a check
<T-Bone> ia64 is mostly -ENOTMYPROBLEM lately
<fabbione> i did try to level to important fixes
<fabbione> dude.. i understand that it won't make it for hoary
<fabbione> but that's not a good reason to give up
<T-Bone> i have reasons
<fabbione> hoary kernel will be the base for bendy
<T-Bone> it's not only a problem of making for hoary or not
<fabbione> well it's not up to me to convince you or anything
<crimsun> fabbione: are we backporting from 2.6.11.3?
<fabbione> crimsun: we are porting whatever fix we can :-)
<crimsun> fabbione: or will that just end up being too much of a hassle?
<crimsun> fabbione: ok
<fabbione> crimsun
<fabbione> it depends what..
<zul> hey T-Bone 
<fabbione> i am not going to backport a new VM right now :-)
<fabbione> if that's what you are asking for
<fabbione> anyway
<fabbione> dinner is ready
<crimsun> fabbione: I'm looking at critical ones, like "sis900 kernel oops fix"
<fabbione> crimsun: go ahead and gimme a patch before tomorrow 12:00 UTC
<fabbione> crimsun: send it via email or send me the mail with a url
<fabbione> and i am off for the evening
<crimsun> fabbione: great, have a good one.
<fabbione> i am just too tired even to concentrate
* fabbione &
<T-Bone> fabbione: it's more a question of "not having reasons to continue"
<fabbione> T-Bone: bendy :-)
<T-Bone> have a nice evening anyway :)
<fabbione> it's the same here for sparc...
<fabbione> i have hard time to keep it up
<fabbione> but i still do it becuase i love sparc
<fabbione> it will make it for hoary+1 :-)
<zul> crimsun: heh i forgot to send fabio that patch
<T-Bone> trouble is i don't like ia64
<fabbione> even if i will have to buy a cluster myseld
<fabbione> cya
<svenl> fabbione: the response to my problem was late_initcall, seems the various initcall are called at various moments ot the init.
<zul> c ya fabbione 
<mdz> fabbione: please review the new kernel changes with me prior to upload
<mdz> fabbione: are you applying the release criteria to them?  currently we are only fixing high-impact bugs and simple, safe fixes
<zul> heh down to 19 majors for the kernel
<zul> later
#ubuntu-kernel 2005-03-26
<zul> evening
<zul> lamont_r whenever you are ready
<lamont_r> zul: can we do it in about 2 hours?
<lamont_r> or is that toolate?
<zul> sure no probelm
<zul> problem even
<lamont_r> ok.  need to run into town with the daughter for a bit
* lamont_r translocates to home again
* T-Bone contemplates this conversation, notes that quoted out of context, it could sound rather strange :)
<lamont_r> lol
<zul> perv
* lamont_r whacks t-bone
<T-Bone> even with context, it does look strange :)
<lamont_r> T-Bone: if you're nice, I'll put the Packages files on p.u.c... :-)
<T-Bone> LOL
<lamont_r> T-Bone: baz primer
<T-Bone> ok ok ok, I won't quote :)
<T-Bone> s/quote/fortune/ :)
<lamont_r> anyway, gotta run home, pick up kid, run to town.  back in a couple hours.
<T-Bone> see ya tomorrow then!
<zul> oh that sucks...debian dropping all but 4 arches?
<T-Bone> yeah
<T-Bone> they're nuts
<zul> i take people are pissed off right now
<T-Bone> that'd be a fair bet
<zul> maybe i should go read -devel :)
<T-Bone> i haven't even bothered, but would certainly welcome a short summary :)
<zul> bah...i dont have time...executive summary people are pissed
<zul> oooh...we are down to 18 major bugs for kernel stuff
<mdz> zul: they aren't dropping them
<mdz> zul: they are going to change the way that they are released
<mdz> yes, people are pissed off, but mostly because they are misinterpreting the announcement (as you seemed to ;-) )
<zul> mdz: i only saw it on slashdot i havent  dealt into it
<mdz> oh god
<mdz> just what Debian needs, slashdot misinformation
<zul> heh
<mdz> slashdot refuses to post our release announcements, and they publish this crap :-P
<zul> how come they refuse?
<mdz> I have no idea
<zul> thats retarded
<zul> someone should go beat some sense into them
<zul> la deh dah
<lamont> ah, cool.. I still have 15 minutes. :-)
* lamont goes to feed horses quickly
<zul> heh
<lamont> ok zul
<lamont> ready>
<lamont> >?
<lamont> stupid > key
<zul> yep
<lamont> ok...  things to decide.  lets assume that you're going to have the archive on the local machine, and then mirror it to the http archive
<zul> ok
<lamont> in my case, I chose to put the archives in /var/lib/arch - you'll want to pick a directory somewhere...
<lamont> baz make-archive /var/lib/arch/zulcss@gentoo.com--2005 (or whatever)
<lamont> that will create the zulcss@gentoo.com--2005 archive.
<lamont> baz register-archive http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005
<lamont> registers the upstream beast
<zul> k hold
<zul> on 
<zul> ok...made the arvhie
<zul> ok..lets go
<lamont> baz branch kernel--team@ubuntu.com--2005/kernel-debian--pre28--2.6.10 zulcss@gentoo.com--2005/kernel-debian--pre28--2.6.10
<lamont> creates a branch for you to work in.
<lamont> then, baz make-archive -m zulcss@gentoo.com--2005 sftp://<http machine>/~zul/public_html/Archives/zulcss@gentoo.com--2005
<zul>  baz branch kernel-team@ubuntu.com--2005/kernel-debian--pre28--2.6.10 zulcss@gmail.com--2005/kernel-debian--pret28-2.6.10
<zul> branch: invalid version name -- zulcss@gmail.com--2005/kernel-debian--pret28-2.6.10
<lamont> (I think...)
<lamont> pre28--2.6.10
<lamont> not pre28-2.6.10
<zul> oops
* lamont isn't sure about the mirror - let me check..
<zul> its running now
<lamont> make-archive -m syntax works.!  woot.
<zul> ok got that
<zul> zulinux.homelinux.net/Archive
<lamont> baz library-config --greedy --sparse /var/cache/arch/revisions  # create the revision library
<lamont> baz get kernel-team@ubuntu.com--2005/kernel-debian--pre28--2.6.10 debian
<lamont> will grab create the debian directory
<lamont> then (inside that directory), baz archive-mirror will push things to zulinux.homelinux.net/Archive
<lamont> uh, doh.
<zul> tla: indicated library is not on library path
<lamont> gotta go check something
<lamont> dpkg -l bazaar?
<zul> 1.2-2
<lamont> ok
<zul> im using ~/work/ubuntu/Archives as my arch repository
<lamont> we forgot to tell baz to keep listings current, so you get a second step until someone in #arch tells us how to automate it... :(
<zul> doh
<lamont> or we could be abusive...
<zul> abusive :)
<lamont> on zulinux, rm -rf Archive/zulcss@gmail.com--2005
<zul> done
<lamont> rm ~/.arch-params/=locations/zulcss@gmail.com--2005
<lamont> on your home machine
<zul> done
<lamont> ok. give me a minute to check on things...
<zul> k
<lamont> baz make-archive --listing -m ....
<lamont> and then baz archive-mirror
<zul> k gimme a sec
<zul> says archive already registered
<lamont> which machine did you rm ~/.arch-params on?
<lamont> ah, on your work machine:
<zul> local machine i did the sftp bit
<lamont> rm ~/.arch-params/\=locations/zulcss@gmail.com--2005-MIRROR
<lamont> uh, that 2nd rm needed to be on zulinux...
<lamont> so...
<zul> same machine
<lamont> ah, ok.
<lamont> that helps some...
<lamont> only not..
<lamont> if both are really the same machine, the best thing to do is just create the archive where http can get to it...
<lamont> since you can't have the archive and the mirror have the same name on the same machine, etc...
<zul> yeah that would be easier
<lamont> so best way is to just nuke the archive storage completely, and toss it from ~/.arch-params/=locations
<zul> done
<lamont> then either a symlink and the needed config, or store it under the web tree somewhere..
<lamont> so...
<lamont> baz make-archive --listing .../Archive/zulcss@gmail.com--2005
<lamont> you already have the other registered (unless you over-nuked...)
<zul> yeah over nuked
<lamont> so baz register-archive from above
<lamont> baz branch from above
<zul> doh..
<lamont> baz library-config from above
<lamont> then baz get from above
<lamont> then you're going to get into a love/hate relation ship with "baz lint" as you do things...
<lamont> baz add files that you add, etc.
<lamont> do you have a change to walk through?
<zul> gimme a sec...still going through the steps
<zul> my brain is slow today...more so than usual
<zul> still getting the same error on revision
<lamont> on revision?
<zul> revisions
<zul> chuck@homer:~$ baz library-config --greedy --sparse /var/cache/arch/revisions
<zul> tla: indicated library is not on library path
<zul>   dir /var/cache/arch/revisions
<lamont> ah, ok.
<lamont> what does baz my-revision-library say?
<zul> chuck@homer:~$ baz  my-revision-library
<zul> my-revision-library: no revision library path set
<zul> there isnt a /var/cache/arch directory
<lamont> yeah - I dumped my revision lib in /var/lib/arch/revisions...
<lamont> pick a directory
<lamont> baz my-revision-library <dir>
<lamont> it'll grow over time until you prune things out of it...
<zul> ok done
<lamont> then library-config
<lamont> adjusted as needed
<zul> im just doing the baz get
<lamont> ah, ok
<zul> so i did the baz get
<zul> and i have the two gz files in my Archive directory
<zul> so i should be done right?
<zul> thats cool
<lamont> yep
<lamont> actually, the branch created those files, I expect
<lamont> uh, did you say --listing with your make-archive?
<zul> so when pre29 comes out i have to do a baz branch kernel-team ya deh dah
<zul> ~/arch
<lamont> touch ..../Archive/zulcss@gmail.com--2005/=meta-info/http-blows
<lamont> url is http://zulinux.homelinux.net/Archive/zulcss@gmail.com--2005 ??
<zul> yep
<lamont> ok. is there a http-blows file there?
<zul> no
<lamont> touch it
<lamont> then say baz archive-fixup zulcss@gmail.com--2005
<zul> chuck@homer:~$ baz archive-fixup zulcss@gmail.com--2005
<zul> usage: baz archive-fixup [options] 
<lamont> s/fixup/fixup -A/
<zul> i c
<zul> done
<zul> http://localhost/Archive/zulcss@gmail.com--2005/kernel-debian--pre28--2.6.10/patch-1
<zul> so when pre29 comes out all i have to do is a baz branch?
<zul> right im falling asleep thanks for your help lamont
<lamont> yes
<lamont> baz abrowse zulcss@gmail.com--2005
<lamont> zulcss@gmail.com--2005
<lamont>   kernel-debian
<lamont>     kernel-debian--pre28
<lamont>       kernel-debian--pre28--2.6.10
<lamont>         base-0 .. patch-1
<lamont> woot
<fabbione> morning
<lamont> fabbione: getting kernel-bugs created... you want me to subscribe you?
<lamont> gonna move the bz target to there, instead of kernel-team, so we can have our mailing list back,
<lamont> fabbione: baz register-archive     http://zulinux.homelinux.net/Archive/zulcss@gmail.com--2005
<lamont> btw,
<fabbione> lamont: yes please
<lamont> s/,//
<fabbione> even if all bugs are assigned to me and i get them automatically 3 times
<lamont> heh.  I assume you want moderator access?
<fabbione> mdz: yes i am cherrypicking bug fixes from Debian right now
<fabbione> mdz: and syncing up to their 2.6.10-6
<mdz> fabbione: ok
<fabbione> what will be the list id for kernel-bugs?
<lamont> fabbione: we'll make the default bz target be kernel-bugs
<lamont> kernel-bugs@lists.ubuntu.com
<fabbione> mdz: please baz get from lamont archive on chinstrap.
<fabbione> mdz: so you can follow yourself
<mdz> fabbione: not right now; I am trying for <12 hours working today
<fabbione> mdz: sure..
<fabbione> let me put up a changelog for you
<fabbione> mdz: there are only bug fixes atm
<fabbione> no new features
<fabbione> http://people.ubuntu.com/~fabbione/changelog
<fabbione> there are more patches to come security, memory corruption and stack handler related
<fabbione> we might also fix a wishlist in this upload since the change is not introsive at all
<lamont> fabbione: is done.
<fabbione> the ml?
<fabbione> cool
<lamont> mdz: could you whack bz and reassign all the kernel bugs from kernel-team to kernel-bugs, and change the default target?
<lamont> fabbione: you're in the --pre28 tree, yes?
<mdz> lamont: do a search, click "change several bugs at once" in the search results
<fabbione> lamont: yes
<lamont> mdz: ok
<lamont> but the default assignment is still you, right mdz?
<mdz> lamont: default assignee for linux has been fabbione for ages
<fabbione> yeah
<fabbione> mdz: do you think it will be possible to get Kamion to create one sparc hoary CD after (and only AFTER) release?
<lamont> ah, even better
<fabbione> well if we can get kernel-bugs to get them assigned
<fabbione> i wouldn't mind
<lamont> fabbione: I got pretty far down the path of building my own on hppa... although it really needs some Kamion-love to be happy
<mdz> fabbione: probably, but it's entirely possible that it will require changes to packages in the archive to work (so it wouldn't be hoary anymore)
<fabbione> in that case i agree
<fabbione> but i think we have been careful enough not to need that
<fabbione> well let see
<lamont> fabbione: you'll almost certainly need d-i changes
<mdz> will sparc be caught up on building packages by release? ;-)
<fabbione> mdz: it's almost there for main
<fabbione> too bad it was dead for 15 days
<fabbione> that was really unlucky
<fabbione> and i have only one or two FTBFS to handle up till now
<fabbione> all the rest is going in
<fabbione> but clearly it will never make it for hoary
<fabbione> i am aware of that
<lamont> grumble. kernel-bugs@lists.ubuntu.com did not match anything
<lamont> do I need to create a login for him?
<fabbione> nmostlikely
<fabbione> s/^n//
<lamont> yeha
* lamont waits for his password
<fabbione> crimsun: i got the patch from zul for the sis oops
<fabbione> i am going to apply it in a few minutes
<crimsun> fabbione: great :-)
<fabbione> do you have the bug num handy?
<lamont> mdz: will new kernel bugs get kernel-bugs@lists.ubuntu.com as their qa contact then?
<crimsun> fabbione: from bugzilla? I don't think there is one (rather, I haven't found one), but a friend has experienced it.
<lamont> fabbione: of course, mass changing 79 bugs when we get 2 copies per (well, you 3)... sorry.....
<fabbione> lamont: only 79?
<fabbione> i have approx 130 assigned for kernel
<fabbione> ok i am not going to touch bz
<fabbione> to avoid mid-air collisions
<lamont> 74 bugs had kernel-team as their qa contact
<fabbione> probably we didn't catch all of them with qa contact
<fabbione> i will see after you change them
* lamont grumbles at cupsys
<lamont> fabbione: my change is done, just percolating, etc.
<fabbione> you didn't change to who the bugs are assigned, did you?
<lamont> no just qa contact
<lamont> unless, of course, I'm a loser... :-(
<fabbione> ok. should we reassign them to?
<lamont> we could, but some are assigned to you and some to zul, etc.
<fabbione> lamont: package linux
<fabbione> we can manually reassign the ones that this check will skip
<lamont> choices are to assign them to one person in charge of triage, or assign them to the list and take them as they're grabbed.
<fabbione> it makes it easier to have one and only one contact
* lamont does the search again
<fabbione> ok let's talk about it with zul later
<fabbione> because i really have heaps more than 79
<fabbione> zul: are you awake?
* lamont finds  166 more bugs, many of them resolved...
<lamont> don't think I'll change those
<fabbione> no skip the resolved...
<lamont> 74+98 == 172
<fabbione> just do a search with fabbione@ubuntu.com as assignee
<fabbione> and package linux
<eruin> copypaste myself?
<fabbione> yes please
<lamont> did a search for package=linux, qa != kernel-bugs, status == unconfirmed thru pendingupload
<eruin> I've had to compile my own kernel to set dma on for my standard ide hd/cd drives, and while doing so I noticed the ubuntu config had "CONFIG_IDEDMA_ONLYDISK=y"
<fabbione> get all the status
<fabbione> many are NEW and NEEDINFO
<lamont> that was there
<fabbione> eruin: yes. that is correct. enabling DMA on cdrom by default causes more troubles than the ones that it solves
<lamont> unconfirmed thru pendingupload includes new,assigned,reopened,needinfo,upstream
<fabbione> eruin: it is enough to use hdparm to enable dma on any device you want
<fabbione> there is no need to recompile
<lamont> but not resolved,verified,closed
<eruin> okay, then that's probably not what solved my issues
<eruin> the problem I had was that hdparm didn't allow me to set dma on
<fabbione> eruin: if it doesn't, perhpas your cdrom or chipset is blacklisted from DMA
<fabbione> because known to be broken or something
<eruin> I still haven't figured out how to get support for enabling dma on my via sata drives, but that's another thing
<eruin> any idea on where I can find info on that?
<fabbione> there is a blacklist somewhere....
<fabbione> in the source
<fabbione> i just can't remember where exactly
<eruin> I'll have a poke
<eruin> drivers/ide/ide-dma.c I bet
<fabbione> i think there is a blacklist.c or something
<fabbione> i really can't remember
* lamont falls bedwards
<fabbione> night lamont
<fabbione> cya later
<eruin> static const struct drive_list_entry drive_blacklist []  = {
<fabbione> looks like it
<fabbione> but that's the one for specific cdrom
<eruin> can't find any of my stuff in it though
<fabbione> iirc
<fabbione> there is another one for chipset too or at least....
<eruin> bah
<eruin> that blacklist blacklists known-to-work devices
<fabbione> if you know that they work, you should report them upstream
<fabbione> they are pretty responsive on that
<eruin> I wonder how they get on the list in the first place if they work
<fabbione> eruin: sometimes developer do not have the hardware
<fabbione> and they hack around with the specifications
<fabbione> that makes the driver work
<fabbione> but they can't test extra features
<eruin> ah
<fabbione> DMA can be really bad if set on broken hw
<fabbione> like data corruption
<fabbione> IDE hanging due to unneeded resets
<fabbione> so it is a much safer path to first blacklist it
<fabbione> and wait for reports that it works
<fabbione> than the other way around
<fabbione> i think we can all agree that "data corruption" = "really really bad"
<fabbione> compared to a minimum gain in performance
<eruin> yeah ;)
<eruin> well.. minimum
<fabbione> minimum is subjective :-)
<eruin> my computer pretty much hangs when I do major operations on my sata drive
<eruin> because I'm no longer able to use dma on it
<fabbione> only on cdrom
<eruin> gathering from what I've seen around the net, the via drivers only work well if compiled-in
<eruin> could that be true?
<fabbione> no
<fabbione> there is basically no difference in compiling in or having it as module
<eruin> hmm.. I've done so and now I can set dma on my ide hd
<fabbione> did you check the module parameters?
<eruin> nope
<fabbione> some of them can accept stuff like forcel33tdma=on
<eruin> :P
<fabbione> without the need of recompiling
<eruin> curses
<mdz> lamont: no, I'll need to change the default QA contact manually; please email me
<fabbione> mdz: unionfs... hmmmm
<fabbione> i think we should find something better than external projects
<fabbione> Al Viro is the right person to ping definetely
<gabaug> why don't modules that worked in 10-3 work in 10-4 (with the error "Invalid module format")?
<gabaug> sorry, hoary's linux-image-2.6.10-3-686 vs 10-4 that is
<fabbione> -3 and -4 identify an ABI change
<fabbione> that is perfectly normal and wanted
<gabaug> ok...is it possible to compile my modules for -4?
<fabbione> yes
<fabbione> the same way you did for -3
<gabaug> because I built one on a freshly installed hoary-preview-install with the -4 kernel running and headers installed and it gave me that error
<fabbione> probably you didn't install the correct kernel headers
<fabbione> also note that after preview
<fabbione> the kernel ABI was broken
<fabbione> so you might have built with a broken kernel
<gabaug> I have the kernel headers that the install cd provided...I have /usr/src/linux-headers-2.6.10-4[-386] 
<fabbione> gabaug: please update to the most recent kernels and rebuild the module
<gabaug> okay
<fabbione> be sure to have 2.6.10-27
<gabaug> woah...I'm confused, did we jump from -4 to -27 or did I just miss a lot of kernel updates?
<fabbione> no
<fabbione> -4 is the ABI in the package name
<eruin> I've found something interesting... http://lists.debian.org/debian-amd64/2004/10/msg00099.html
<fabbione> -27 is the debian version
<fabbione> or ubuntu version
<gabaug> fabbione: okay, thanks
<fabbione> mdz: can i extend the kernel bof list for UDU (since the page is "please do not modify")
<fabbione> ?
<svenl> fabbione: let's move here.
<svenl> fabbione: the powerpc-mv643xx-enet.dpatch patch just enables to build the mv643xx_eth module on MULTIPLATFORM_PPC, and removes all mips-embedded arch specific part of it, no ABI breakage visible there.
<fabbione> svenl: we have a (semi) automatic abi checker
<fabbione> so that one is checked at build time
<svenl> fabbione: the other patch detects if a marvell NB is present, and sets a couple of info (membase and irq to be used) for the driver to use.
<fabbione> yes i read the patches
<svenl> so i don't think there should be any ABI breakage involved.
<fabbione> but i still need to verify them and revert an old patch we have around
<fabbione> svenl: i promise.. as soon as i get -28 out of the way, your patches will be the first to go in and be tested.
<fabbione> http://people.ubuntu.com/~fabbione/changelog
<fabbione> svenl: ^
<fabbione> this is what i have in the boilerplate for today
<svenl> fabbione: you have an old marvell patch in ? The one from debian 2.6.10 ? 
<fabbione> svenl: i think it is from 2.6.9 that i portforwarded
<fabbione> but there is a patch there
<svenl> fabbione: ok. we can get ride of it, and replace it with this new one.
<fabbione> yes i know .. i did check that too
<fabbione> :-)
<svenl> more to this later, do your install and i will build a package locally with my proposed fix, ok ? 
<fabbione> svenl: i will upload my package around 14:00 UTC
<fabbione> after that i can do directly tests for you
<fabbione> so don't worry too much
<fabbione> i can even give you the images to test
<fabbione> that's not an issue :-)
<fabbione> but before 14:00 UTC with kernel up
<fabbione> it's no-no
<svenl> ok.
<svenl> i was just asking, not knowing the schedule. tomorrow is better for everyone involved.
<fabbione> yup.. no problem
<fabbione> build orgy started :-)
* fabbione -> shower -> food
<fabbione> later
<fabbione> woo woo woo
<fabbione> amd64/ia64 are go
<fabbione> i386 and ppc still compiling
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | kernel-team@ubuntu.com--2005/kernel-debian--pre28--2.6.10 | check the new abichecker code and GET familiar with it. | The award for the "turtle" moves to i386.
<fabbione> ppc is GO
<fabbione> and i386 is go
<zul> heylo
<fabbione> hey zul
<zul> hey fabbione how is it going?
<fabbione> very good
<fabbione> all arches are go
<zul> good good
<fabbione> i am ready to upload.. testing l-r-m now
<zul> sweet
<fabbione> but i still cannot commit one patch
<fabbione> but i will upload before that ;)
<zul> heh
<zul> you guys wanted to talk to me about something im reading the backlog
<fabbione> zul: yes...
<fabbione>   * Not all USB ports detected on nForce4 SLI chipset boards:
<fabbione>     - Add patch nforce4-usb-broken.dpatch.
<fabbione>     (Closes: #7241)
<fabbione> the bug is assigned to X?
<fabbione> and...
<fabbione>   * Add emu10k1x driver:
<fabbione>     - Add patch stolen-from-head_em10k1x-alsa.dpatch.
<fabbione>     - CONFIG_SND_EMU10K1X=m.
<fabbione> what bug does it fix?
<zul> gimme a sec
<fabbione> sure
<fabbione> 1
<fabbione> so?
<zul> shaddup
<zul> :)
<fabbione> ahhaha
<zul> nforce usb is suppose to be 7214
<fabbione> ah ok
<zul> the dell sound card is 6492
<fabbione> ok.. comming now
<zul> whats the thingy on bugs im reading in the backlog
<zul> qa contact is kernel-bugs now? ok..
<fabbione> yes
<fabbione> we were considering to reassing all the bugs to it
<zul> ah ok
<fabbione> and decide between us who gets what
<fabbione> it is easier to keep all the bugs together
<zul> well t-bone can do ppc
<zul> true
<fabbione> to see duplicates and stuff
<fabbione> and since we have the lists
<fabbione> we can coordinate there
<fabbione> or via irc
<fabbione> or whatever..
<zul> and you and i can divy out the i386 ones
<fabbione> just to avoid duplicate work
<zul> whatever..
<fabbione> exactly
<zul> but if you are working on a bug you should take ownership of it
<fabbione> yes
<fabbione> that is correct
<fabbione> or coordinate
<zul> or cordinate
<fabbione> brb... rebooting
<zul> k
<fabbione> well.. i missed cron.d for 62 seconds
<fabbione> that means 30 minutes delay ...
<fabbione> at least i had the extra time to test the kerne
<fabbione> zul: you can close the bugs if you want
<fabbione> kernel is uploaded
<zul> okie dokie
<fabbione> i am doing some baz magic to create the new branches and so on...
<zul> sweetness since i have baz setup now
<fabbione> i know..
<fabbione> i already registered your archive
<fabbione> so you sync.. merge
<zul> wohoo
<fabbione> and i can sync merge from you
<fabbione> 29329839283 times faster
<zul> yeah yeah
<zul> only if im up though
<fabbione> well that's up to you
<zul> yeah so there
<fabbione> not bad... 
<fabbione> 24K of changelog
<zul> heh...oh yeah got a question for you 
<zul> there are alot of win4lin users using ubuntu
<fabbione> yes
<zul> so why not include it in  linux-restricted after hoary is released
<fabbione> they can all die to hell in a painful and slow death
<fabbione> ops
<fabbione> i am not supposed to say so
<fabbione> i don't think we can
<zul> heh or not..
<fabbione> it depends a lot from the licence
<zul> ill look into it
<fabbione> ok
<zul> because there is getting alot of ubuntu users at work and they are all asking me about and i have to beat them off with a stick
<fabbione> zul: send them to me
<fabbione> i also want some fun killing the bugs
<zul> well since i am just a consultant i would like to keep my job
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | kernel-team@ubuntu.com--2005/kernel-debian--pre29--2.6.10 | check the new abichecker code and GET familiar with it.
* fabbione needs a smoke
<zul> bwahahaha  kernel-team@ubuntu.com--2005/kernel-debian--pre28--2.6.10 debian
<zul> doh..
<fabbione> ?
<zul> i have a local copy of pre29 now..
<fabbione> yeah i am preparing the basic stuff for -29
<fabbione> like changelog and abi files
<fabbione> otherwise you won't even be able to make clean
<fabbione> i need to implement a make target for it
<fabbione> but not for hoary
<fabbione> i am too lazy
<zul> heh
<fabbione> attempt to remove directory amd64/
<fabbione> hmmm
<fabbione> baz doesn't like removing directories?
<zul> dont know
<zul> i just started using it so im not the one to ask
<zul> or if you were asking rhetorically
<fabbione> no, it doesn't support it
<zul> crap im missing a } somewhere
<fabbione> committing the first -29 bits
<fabbione> for i386
<fabbione> at least you can start working
<zul> k
<fabbione> it still transmitting :-)
<fabbione> should be there now
<zul> so the abi stuff just goes a diff?
<fabbione> they are files in the source package
<fabbione> -28 contains -27 abi files
<fabbione> -29 contains -28 abi files
<zul> ah k
<fabbione> and so on
<fabbione> for hoary it is manual
<fabbione> we will work on it at UDU
<fabbione> to make it more transparent
<zul> heh i wont be there
<fabbione> because personally building the kernel N times only to check if it builds + a clean build after upload just to get the ABI is a PITA
<fabbione> zul: i know, but we will plan a strategy to have it done automatically
<fabbione> like buildd mailing abi files or something like that
<fabbione> we will see how to spec it
<zul> good good
<jbailey> fabbione: glibc grew some abi checking a year or so ago, and in the next major upload, we hope to have all the checking be there automatically and fail the build if something changes.
<fabbione> jbailey: we already fail if the ABI breaks
<fabbione> the problem is that abi files are created at build time
<fabbione> and since we do source only uploads
<fabbione> we need to find a nice way to get these files back 
<fabbione> to make them usefull
<fabbione> the checker is there
<fabbione> and it is pretty simple to use
<jbailey> Ah.  Include them in /usr/share/doc ?
<fabbione> jbailey: nah that's a bad approach
<fabbione> we did a long discussion about it
<fabbione> both with dilinger and mdz
<fabbione> and here on irc too
<fabbione> the point is that we must ensure that version -X+1 is always built using version -X of the abi files
<fabbione> so we must ensure that the latest packages are always available on the buildd
<fabbione> and we cannot achieve that with a strict Build-Dep
<jbailey> Oh good point.  You actually expect the ABI to change occasionally.
<fabbione> because if one arch FTBFS
<fabbione> there is no way to make it build again without disabling the abi checker
<fabbione> jbailey: yes. it happens, and sometimes is not predicted
<fabbione> specially when we pull big patches around
<fabbione> the kernel abi changes a lot of time
<fabbione> due to the fact that no user land uses it directly
<fabbione> (or if you want to put it that way...)
<fabbione> it is more free than a simple library
<fabbione> ;)
<fabbione> ok l-r-m uploaded
<lamont> fabbione: so where is this new abichecker?
<fabbione> in debian/rules?
<fabbione> it runs at build time
<fabbione> point is feeding it with the data
<fabbione> that's the only PITA atm
<fabbione> i already have abi files for i386/amd64/ia64
<fabbione> waiting ppc to finish on davis
<fabbione> for -29
<fabbione> or to be used with -29
<fabbione> lamont: can you plase kick back l-r-m for ppc?
<mdz> fabbione: yes, feel free to add to the list; I just don't want random people modifying it when they are not involved with development
<fabbione> mdz: ok
<jbailey> mdz: Looks like that sata bug isn't 1440 again, it's a different chipset, and works fine when ide-generic is loaded.  I'm going to hack hotplug now to do that.
<mdz> jbailey: thanks, I was just wondering whether we were dealing with more than one bug there
<mdz> jbailey: does that also aapply to the person who followed up to 1440?
<fabbione> izagtkbogz
<jbailey> mdz: Yeah.  thom has a sata_via too, so we've been testing it.
<jbailey> I haven't checked the 1440 follow up yet.
<fabbione> jbailey: can you test with -28?
<fabbione> there were some bug fixes for sata
<fabbione> perhaps it is something there....
<jbailey> Ah, hmm.  Let's ask thom in -devel.  He's got the machine.
<lamont> fabbione: will happen automatically, unless that package name is wrong...
<lamont> Rejected: xfree86-driver-fglrx-dev_4.3.0-8.8.25-0ubuntu7_amd64.deb: old version
<lamont> +(4.3.0-8.8.25-0ubuntu7) in hoary >= new version (4.3.0-8.8.25-0ubuntu7)
<lamont> +targeted at hoary.
<lamont> besides, you need to upload -8
<fabbione> eh?
<fabbione> ah fuck that shit
<lamont> -7 was rejected because the internal minor number wasn't bumped on amd64...
<fabbione> yeah
<fabbione> this time isn't my fault...
<lamont> heh
<fabbione> was that the only error?
<fabbione> or other minors have been complaining?
<fabbione> there.. it's on the way
<fabbione> this is so frigging sucky
<fabbione> i386 is still lagging....
<fabbione> i wonder if we did hit a buildd with the ccache
<fabbione> lamont: for the next kernel i will add gfs support
<fabbione> so you can share ccache over the different buildds of the same arch
<jbailey> <thom> with id-cd, ide-disk and ide-generic commented out, there's no change with 2.6.10-28
<fabbione> ok
* jbailey puts hotplug under the knife.
<lamont> fabbione: I _can_ do it today (nfs)... it's more a question of what the admins will allow, you see...
<fabbione> ehhe
<fabbione> ok.. all the abi files for -29 are committed
<fabbione> (for supported arches)
<fabbione> the others are empty
<fabbione> (sparc/hppa)
<fabbione> i am off
<lamont> fabbione: so I need to get you the results then?
<lamont> or rather, drop them in place...
<fabbione> lamont: can you coordinate with Kamion to upload linux-meta/d-i
<lamont> sure
<fabbione> lamont: yes. that is correct. you can just add them in the right place in debian/abi
<lamont> so lrm is all better?
<lamont> -8 uploaded and everything?
<fabbione> i did upload it with the minor bumps
<fabbione> i hope that is enough
<lamont> or does that need to be done still?
<fabbione> already done l-r-m
<lamont> cool
<fabbione> it should it the daily in 2 minutes
<lamont> ok.
* lamont is going to reboot to put in a new dvd-r drive.
<fabbione> cya tomorrow
<lamont> and shotgun this wireless mouse
<fabbione> i need to take care of wife
<lamont> back in a few myself
<fabbione> cya
<lamont> til tomorrow
<fabbione> bah first my wife sais that she does feel good..
<fabbione> now she is all around the kitchen..
<fabbione> go figure
<fabbione> females are worst than ABI change
<fabbione> because you can't unbreak it
* Mithrandir quotefiles
<lamont> fabbione: nothing here...
<fabbione> for the reason why i am still around ;)
<fabbione> i wasn't checking on you ;)
<lamont> heh
<lamont> still no clue what's up though...
<fabbione> is it still building or did it hang?
<lamont> i386?
<fabbione> yup
<lamont> fabbione: building documentation now
<fabbione> it took really long time
<fabbione> i will need to check the build log
<fabbione> it looks like it didn't fork at all
<fabbione> and ccache was empty
<fabbione> dinner is ready
<fabbione> i am off :-)
<lamont> ok
<T-Bone> heya lamont!
<lamont> fabbione: fwiw, the buildd in question has never build linux-source-2.6.10 :-(
<lamont> T-Bone: hiya
* T-Bone debootstraps p.u.c ;)
<lamont> T-Bone: for starters, add the debian db admin pkg
<lamont> pick up that buildd/sbuild
<T-Bone> done already :)
<lamont> get a good debootstrap
<lamont> copy hoary.buildd over from that archive :-)
<lamont> debootstrap build/chroot-hoary with hoary
<zul> fabbione: they can be unbroken, just nag nag nag
<zul> oh yeah there is a tech meeting today
<lamont> install -d -m0775 -obuildd build/chroot-hoary build/chroot-hoary/home/buildd build/chroot-hoary/build/buildd build/chroot-hoary/var/debbuild build/chroot-hoary/var/debbuild/srcdep-lock
<lamont> echo do_initrd = Yes > build/chroot-hoary/etc/kernel-img.conf
* T-Bone is currently looking for a machine (powered on) with hoary.buildd :)
<lamont> install -m644 /etc/fstab build/chroot-hoary/etc/fstab
<lamont> wget http://people.ubuntu.com/~lamont/hoary.buildd
<T-Bone> doh :)
<jbailey> Is it safe to assume that we're not really planning another kernel upload soon? =)
<T-Bone> cool
<lamont> for file in var/debbuild/avg-build-times var/debbuild/avg-build-space CurrentlyBuilding; do install -m0664 -obuildd -gbuildd /dev/null build/chroot-hoary/${file}; done
<lamont> create build/chroot-hoary/etc/apt/sources.list (with main restricted universe
<lamont> )
<lamont> create user and group entries for buildd in the chroot
<lamont> with a shadow entry
<lamont> mount proc, /dev/pts in chroot
* T-Bone damns lamont for being that verbose all of a sudden :^)
<lamont> create /etc/source-dependencies
<lamont> edit /usr/sbin/sbuild to make -dhoary not be fatal
<lamont> then we just have to deal with buildd.conf
<lamont> but one should be able to sbuild the poor thing.
<lamont> then, on your machine, create and sign a new gpg key - use that one to sign the .changes files.
<lamont> and we still need to figure out just exactly _where_ we're uploading too...
<lamont> s/too/to/
<T-Bone> debootstrap in progress
<lamont> but getting sbuild to run as the user buildd in ~buildd/build, with 'sbuild -dhoary ed_0.2-20' is the keyh
<T-Bone> (had to distupgrade the box first, hence the lag)
* lamont wanders off for a couple minutes, to feed his face
<T-Bone> hehe ok thx
<T-Bone> (alot :)
<zul> T-Bone: http://zulinux.homelinux.net/Archive
* T-Bone whistles and look the other way ;}
<mdz> are you guys going to update linux-meta?
<T-Bone> that's on the todo list as far as i can tell
<T-Bone> fabbione had plans for that
<mdz> fabbione: is there a waitcondition?
<lamont> mdz: going to update it yes, \
<lamont> waiting for i386 to finish hitting the archive
<lamont> which should have just happened
<lamont> mdz: is it ubuntu-meta, then d-i, or the other way?
<lamont> and should I be nice and do kubuntu-meta too?
* lamont grumbles.  linux-meta!=ubuntu-meta. :-)
<T-Bone> <lamont> create /etc/source-dependencies
<mdz> lamont: the order doesn't matter, so long as they're in sync when the CD builds happen
<T-Bone> lamont: means "touch"?
<lamont> T-Bone: yes
<lamont> right
<lamont> mdz
<lamont> T-Bone: and make /usr/*bin/update-sourcedeps? just exit 0
* T-Bone tries to recall what needs to be changed in /usr/bin/sbuild
<lamont> make it so -dhoary doesn't die.
(fabbione/#ubuntu-kernel) jbailey: please do..
<zul> later
* T-Bone is completely exhausted, calls it a night
<lamont> how do I disable ACPI PNP, I wonder?
<lamont> aha!
<lamont> pnpacpi=off
<zul> jambo
#ubuntu-kernel 2005-03-27
<zul> lamont: stop bombing my email!! :)
<lamont> zul: heh
<lamont> was last time, honest
<lamont> well, for this change, anyway
<lamont> there's only one bug left in bz that has kernel-team on it, and I'm not reopening taht bug just to change it
<zul> heh
<zul> lamont: back yet
<lamont> yeah
<zul> later
<fabbione> morning
<crimsun> morning, fabbione :-)
<lamont> fabbion3: when did you go all 3l1t3 on us?
<fabbion3> i need fabbione for the dpl debate
<fabbion3> going to switch back later :-)
<fabbion3> otherwise it's just ETOOMANYCHAN for one client
<lamont> ah, ok.
<lamont> you running?  or just want to be there?
<lamont> how many channels am I allowed?
* lamont is in 12 channels this server right now...
<fabbion3> no the problem is not the amount of allowed chans
<fabbion3> it's the way i like to use my client
<fabbion3> i don't like to hide windows
<fabbion3> so i keep all of them open at the same time
<lamont> fabbion3: may have some hppa changes for a near-future kernel...
<fabbion3> lamont: that's ok with me
<fabbion3> i don't have any issue with portability on hppa
<fabbion3> specially because the patches are isolated
<lamont> heh
<fabbion3> btw.. i just added the 00-list files for 29
<fabbion3> i must do the create_new_release: target in the make file
<fabbion3> it's just too many thing to do atm
<fabbion3> it's easy to forget them.
<lamont> yes, please
<lamont> so this abichecker... where does it live?
<fabbion3> lamont: in debian/rules inside the clean and build target
<fabbion3> + 2/3 things outside to export VARS like abinum
<fabbion3> debian/abi is the dir that does the trick
<lamont> ok... there's a target in debian/rules then that verifies things?
<lamont> and I'll need to generate hppa files for -28 or something?
<fabbion3> lamont: no target. it's just a direct thing in build target
<lamont> ok
<fabbion3> if you build for hppa, just add the ABI files to debian/abi/2.6.10-28/hppa/
<fabbion3> they are called with the same name as the config files
<fabbion3> otherwise
<fabbion3> since hppa is not official yet
<fabbion3> you can just echo 1 > debian/abi/2.6.10-28/hppa.ignore
<fabbion3> and the ABI check will be overridden
<fabbion3> don't make an empty file
<fabbion3> it won't survive to make clean
<fabbion3> svenl: i am building the ppc kernel with the eth changes right now
<svenl> it builds fine ? 
<svenl> fabbion3: did you add the mkvmlinuz support stuff too ?
<fabbion3> it's build..
<fabbion3> it still needs to finish the first flavour
<svenl> it compiles the arch/ppc part early on.
<fabbion3> svenl: i am compiling with -j15
<fabbion3> it won't take long
<fabbion3> too much scrolling on the screen to see it
<svenl> :)
<fabbion3> In file included from arch/ppc/platforms/mv643xx_eth_pegasos.c:18:
<fabbion3> include/linux/mv643xx.h:16:27: asm/addrspace.h: No such file or directory
<fabbion3> include/linux/mv643xx.h:17:25: asm/marvell.h: No such file or directory
<fabbion3> it fails
<fabbion3> this is 2.6.10
<fabbion3> are you sure you did add all the files?
<svenl> well, they where for 2.6.11, maybe the files in question got added to 2.6.11 after 2.6.10. Will check.
<svenl> or you can just grab them. 
<svenl> The problem is that my frech ubuntu install refused to boot, so i couldn't try the patches myself, but will backport them to the debian 2.6.10 kernel.
<svenl> fabbion3: mmm, something is wrong here.
<fabbion3> svenl: please just give me the complete patches
<fabbion3> you can build in a hoary chroot
<svenl> those are the mips includes.
<fabbion3> it's not difficult
<svenl> a patch against the debian 2.6.10 kernel should do just as well though, right ? 
<fabbion3> ubuntu 2.6.10 please
<svenl> ok.
<svenl> fabbion3: first i need to make an upstream patch though.
<fabbion3> that's fine by me
<svenl> fabbion3: what about mkvmlinuz support script ? 
<svenl> fabbion3: maybe you can try that in the meantime ? 
<fabbion3> if you have an http server somewhere you can just branch out from /t and i can merge from you
<fabbion3> svenl: yes gimme the patch and i will test it in the meanwhile
<svenl> fabbion3: you get the svn://svn.debian.org/svn/kernel/trunk/kernel/powerpc/kernel-patch-powerpc-2.6.10-2.6.10/debian/post-install
<svenl> and move it to kernel-tree/debian before calling make-kpkh kernel-image
<svenl> debian powerpc package does : 
<svenl>         cd debian; cp -p changelog control copyright post-install $(KSOURCE)/debian
<svenl> in configure, after having unpacked the kernel tree, but i bet you know best when to do it.
<svenl> it is a make-kpkg install hook.
<fabbion3> svenl: ok i will look at it, but i would really love to get simple patches to our tree to do stuff like that. it takes me a lot of time to check exactly what needs to be done and why.
<fabbion3> also are we sure that our make-kpkg is the same as in debian with the same support hooks and stuff?
<svenl> fabbion3: yep, as soon as i am able to install ubuntu, i will do it, right now it seems tzsetup-udeb broke since yesterday, see my message on #ubuntu-devel.
<fabbion3> svenl: just a suggestion, since we are in short of time due to release, can you just bootstrap a chroot to make the patches?
<fabbion3> you only need to manually install debootstrap from ubuntu
<svenl> fabbion3: and last i tried, debootstrapping a ubuntu partition, i failed horribly.
<fabbion3> create the chroot
<fabbion3> and reinstall the debian debootstrap
<fabbion3> i can help you with that..
<fabbion3> it's no issue
<svenl> ok will try.
<svenl> Damn, it now just gives me an empty blue screen for apt-configuration :/
<svenl> will relaunch the install while i prepare a debootstrap partition.
<fabbion3> do you have a dedicated partition or just a dir somewhere?
<fabbion3> iirc in both cases you need to mkdir /sys
<fabbion3> not on your system.. inside the chroot
<svenl> mmm, i am installing /sys, and i have just a dir.
<svenl> i mount /sys like i mounted /proc previously ?
<svenl> what is the debootstrap invocation ? 
<svenl> E: Failed getting release file http://ftp.debian.org/debian/dists/hoary/Release
<svenl> well, guess i have to provide for a mirror
<fabbion3> ehehe
<fabbion3> debootstrap hoary <chrootdir> http://archive.ubuntu.com/ubuntu
<svenl> if doing it in fakeroot enough, or do i need to be real root.
<fabbion3> sudo or real root
<fabbion3> you can't use fakeroot for that
<svenl> oh well.
<svenl> ok doing it with sudo.
<svenl> do i need to create the /sys before doing the debootstrap call ? 
<fabbion3> yes
<fabbion3> inside the chroot
<svenl> fabbion3: how can i do it inside the chroot before i finished debootstrap ? 
<fabbion3> svenl: you created a directory for the chroot, right?
<fabbion3> sudo mkdir <pathtothechroot>/sys
<fabbion3> that's more than enough
<fabbion3> it's just a simple dir
<fabbion3> but it needs to be done by root
<svenl> ok.
<svenl> what about /proc ?
<svenl> ok launched, let's hope it will be ok now.
<fabbion3> proc is handled by debootstrap
<fabbion3> no need to touch it
<svenl> ah ... i had it mounted already, i hope this will not cause problems ? 
<fabbion3> probably not
<svenl> Mmm, i really need to get a apt proxy going here, i wonder if i can configure my router to automatically redirect apt calls to it, but i don't think so.
<svenl> will take a while though, since i don't have 2.6.10 in my ccache, and have a slower machine than yours.
<fabbion3> svenl: 2 hints
<fabbion3> in debian/config/powerpc
<fabbion3> there are the configs for $flavour
<fabbion3> just leave one there that is known to use that card
<fabbion3> and in debian/rules
<fabbion3> there is a commented line CONCURRENCY_LEVEL
<fabbion3> even if your machine is UP
<fabbion3> set it to 4 or 8
<fabbion3> the kernel benefits a lot of that
<fabbion3> it will slow down your box for a little while
<svenl> i use 8, and i use both ccache, and a two machine distcc setup.
<fabbion3> svenl: good
<fabbion3> it will take much less to build
<svenl> yep.
<svenl> normal build is 1.5 hours though.
<T-None> morning svenl, fabbion3 
<svenl> hi T-None 
<svenl> mmm, making a backup of my chroot, just in case.
<fabbion3> hi T-None 
* T-None heads to work, will be back in ~9h
<T-None> have a nice day, fellows 8)
<svenl> T-None: you too.
<T-None> thx
<fabbione> cya leter
* T-None is gone
<fabbione> mdz: ping?
<mdz> fabbione: going to sleep shortly
<fabbione> mdz: i found a driver in the kernel that we forgot to update even before UVF
<fabbione> and i think the new version can fix a maj bug
<mdz> email about it, please, I'm crashing
<fabbione> sure
<fabbione> good night :-)
<svenl> chroot created.
<svenl> fabbione: can i build only the powerpc kernels, and not the full source stuff ? 
<fabbione> yes
<fabbione> just do a fakeroot make -f debian/rules build
<fabbione> it will leave the .deb files in debian/build
<fabbione> you still need to cleanup debian/config/powerpc if you want to remove flavours
<svenl> yep.
<svenl> debian's setup is somewhat nicer, since it has a file (debian/flavours) where you can just list the flavours you want to build.
<svenl> Ok, i have a upstream patch against 2.6.10, need to test it.
<fabbione> bah screw mppe
<fabbione> there is no new kernel driver
<fabbione> only a newer userland daemon
<svenl> hi kylem 
<kylem> hiya.
<fabbione> hey kylem 
<svenl> fabbione: i have a version of the patch against upstream for 2.6.10, do you want to test it ? Will take a while (read couple hours) for me.
* kylem figured he should be paying attention here too.
<kylem> :)
<fabbione> svenl: can you just please send one patch when you believe you are done, and i will test it?
<svenl> fabbione: it replaces the powerpc-mv643xx-enet.dpatch one.
<svenl> fabbione: ok.
<svenl> fabbione: ok to include the mkvmlinuz support too ? 
<svenl> fabbione: and to fill a proper bug report with it ? 
<mjg59> fabbione: What's the situation with pre-Hoary changes? Nothing now unless it's low-impact and verified to fix a bug?
<fabbione> there is no need for a bug.. just send me the patches :-)
<fabbione> mjg59: kinda
<svenl> fabbione: ok.
<fabbione> i need to go for 10 minutes...
<fabbione> brb
<mjg59> We've still got some machines with missing batteries, and there's an acpi patch that /may/ fix it
<mjg59> But I don't understand what it does, I don't have any of the affected hardware here, and, well...
<fabbione> mjg59: did you test the patch for possible regression?
<fabbione> i have one laptop here too to test it
<mjg59> fabbione: No, haven't done that yet
<fabbione> mjg59: ok, can you do it and send me the dpatch?
<mjg59> Sure. What sort of timescale are we looking at? I won't have a chance to look at this until tomorrow, probably
<fabbione> mjg59: well i am working on trying to fix some bugs
<fabbione> the big fat bastard went out yesterday
<fabbione> so we have a few days
<mjg59> Yeah. Thanks for the b44 fix
<fabbione> no problem
<fabbione> mjg59: you can also branch off from baz
<fabbione> and i can merge from you, if that makes thing easier
<fabbione> the archive is on people
<fabbione> http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | check the new abichecker code and GET familiar with it | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ | kernel-team@ubuntu.com--2005/kernel-debian--pre29--2.6.10
<mjg59> Then I'd have to figure out how to use baz!
<fabbione> mjg59: that'd be very easy for you ;)
<fabbione> svenl: the 2 new patches are the one you committed to svn?
<svenl> fabbione: indeed.
<fabbione> ok
<svenl> need to test first, will tell you once i did.
<fabbione> ok
<smurfix> fabbione: WRT #7633, dunno what else to try, fast USB works here and I seem to have the same USB hardware :-/
<zul> hey
<zul> heh...it looks like the canadians outnumber everyone here
<jbailey> Hmm, you, me, kyle...
<jbailey> I don't know where Daniel or Matthias is from.
<zul> do we want a doc in the wiki on how to get the baz stuff?
<kylem> :)
<jbailey> zul: Do you have a sec to look at the last couple of entries on 1440 with me?
<mjg59> fabbione: Ok, looks like the battery problem is down to the battery module not being loaded...
<jbailey> zul: Looks like we might have another live one.
<zul> jbailey: am at work but ill have a look
<zul> which one?
<jbailey> zul: don't worry about it.  I'm just looking for a sanity check before I reopen this one... again...  *cRy*
<zul> heh
<jbailey> Two two dmesg's.  User claims array-6 works.  dmesg seems to show ata_piix doing the right thing with the PATA CD Rom.  Nightly dmesg shows it not being picked up and ide-generic failing to grab it.
<jbailey> s/^Two/The/
<zul> ok...ill have a look in a little bit there is people coming in and out of my office ;)
<svenl> fabbione: i get this : 
<svenl> Use of uninitialized value in split at /usr/share/kernel-wedge/commands/gen-control line 36, <KVERS> line 3.
<svenl> Use of uninitialized value in split at /usr/share/kernel-wedge/commands/gen-control line 36, <KVERS> line 4.
<svenl> Use of uninitialized value in pattern match (m//) at /usr/share/kernel-wedge/commands/gen-control line 161.
<svenl> Use of uninitialized value in pattern match (m//) at /usr/share/kernel-wedge/commands/gen-control line 161.
<svenl> seems to build fine though afterward.
<fabbione> argh
<fabbione> i crashed
<fabbione> smurfix: ok. thanks a lot!
<fabbione> mjg59: hmmm is that loaded by laptop-mode or something?
<fabbione> svenl: these warnings are harmless
<mjg59> fabbione: No, it should be loaded by acpid
<fabbione> mjg59: ok, do we know why it doesn't load it?
<mjg59> Nope.
<mjg59> Can't reproduce it here.
<svenl> fabbione: seems so, harmless but annoying.
<fabbione> i know it's harmless. they have been there since ages
<fabbione> mjg59: what about just forcing it?
<mjg59> fabbione: If they add it to /etc/modules, it loads
<mjg59> So, uh.
<svenl> damn i forgot to remove marvel-pegasos-2 :/
<fabbione> lamont: sorry but -28 on hppa will fail
<lamont> woot
<lamont> why for?
<lamont> I'll create 28hppa1 locally (or maybe 29hppa1 by the time I get to it...), and then merge that back in
<zul> sweetness i can access my baz stuff from work as well
<fabbione> becasue the clean target is borked
<fabbione> and it checks for abi files that are not there
<fabbione> as well the build target does NOT check for the override
<fabbione> so basically i messed it up a bit
<lamont> np.  plan is to create the abi files with -28 and merge those for -29
<lamont> assuming I get time to mess with -28 before -29 happends
<lamont> or maybe kylem/t-bone will beat me to it...
<fabbione> that will need manual tricks to build
<fabbione> but it's ok
<lamont> fabbione: we need a README or something that says how to create new ABI files...  Or maybe that just wants to be a debian/rules target, for when we intentionally bump the abi?
<fabbione> lamont: the abi files are created at build time and the build rules already move them in the right place
<fabbione> from the build tree to debian/abi/$cur_version/$arch/$flavour
<fabbione> so basically you only need to collect them around the different buildd
<fabbione> i would much rather have a makenewrelease: target
<lamont> ah, ok.
<lamont> yes, definitely want a newrelease target
<fabbione> that will create everything that needs to be created
<fabbione> and check for what has been done and what is missing
<fabbione> i was supposed to do it today
<fabbione> but after lunch i layed in bed 5 minutes with my wife
<fabbione> and i woke up after 5 hours
<fabbione> new debian/rules should work with $arch.override
<lamont> sometimes your body makes you obey it...
<fabbione> tbh.. i didn't even try to make reistance...
<fabbione> resistance even
* fabbione -> coffee
<zul> that was weird
<zul> who added pmac_pmdisk?
<kylem> it went in through Pavel.
<kylem> and benh is upset.
<kylem> there were a couple mails on linux-kernel about it two days ago, i could dig them up if you'd like.
<zul> its making me upset now :)
<kylem> heh.
<zul> lunch
<mjg59> benh is unhappy from a this isn't clean enough yet point of view rather than a this doesn't work yet point of view (as I understand it)
<mjg59> It seems to work pretty well, so we're including it...
<kylem> from what i can tell, he's also unhappy from a "hey, somebody subverted due process, grr at them" standpoint, justifiably.
<fabbione> lamont: bumpabi: target is in place
<fabbione> note: run it only once. it doesn't backup
<fabbione> lamont, zul: what would you like the "prepare a new release" target should do ?
<fabbione> in details?
<lamont> fabbione: re: abibump.... heh
<lamont> new release: create 00list files
<lamont> and bump changelog
<fabbione> because even the clean target will fail if all the abi files aren't in place
<zul> what lamont said
<fabbione> yeah.. i have almost done
<fabbione> is that ok that the abi stuff is checked instead of created?
<fabbione> it would happen in seq anyway
<fabbione> first you "createthenewrelease"
<fabbione> and at the first time you run a make clean
<fabbione> it will check all the stuff
<zul> yeah it should be ok we could always change it later
<fabbione> yeah
<lamont> sounds good
<T-Bone> howdy buddies
<zul> hey T-Bone 
<T-Bone> oh, so there's been a settlement over "Breezy", heh? :)
<zul> hmm?
* T-Bone reads mail on u-announce
<zul> ah ok
<fabbione> <@bubba-> Ubuntu release,
<fabbione> <@bubba-> due in October 2005... It will be known as Ubuntu 5.10, the Breezy Badger!
<fabbione> <@bubba-> oh my god how gay
<fabbione> [snip a few tons of other comments] 
<T-Bone> huhu
* T-Bone has NFC what a badger is, so the name sounds just "windy" to him
* T-Bone looks up
<T-Bone> oh
<T-Bone> what a nice animal
<T-Bone> now the name sounds "smelly" to me 8)
* T-Bone ducks
<fabbione> i start to hate shell in makefiles
<fabbione> makenewlists:
<fabbione>         list="$(shell ls debian/patches/00list-$(revision)*)"; \
<fabbione>         for i in $$list; do \
<fabbione>           newname="$(shell echo '$$i' | sed -e 's/00list-$(revision)/00list-$(nextrev)/g')"; \
<fabbione>           echo $$i; \
<fabbione>           echo $$newname; \
<fabbione>         done
<fabbione> wth is wrong with newname= ?
<zul> has anyone seen the part in monty python's holy grail when they build alarge wooden rabbit and theire backup plan was a large wooden badger
<kylem> hehe.
<fabbione> http://www.badgerbadgerbadger.com/ <-
<fabbione> we can get this as boot logo :-)
<zul> lol!!!
<kylem> hmm, i think the mushroom should be the logo.
<fabbione> no that's impossible
* T-Bone doesn't have flash. These are those badger jumping around with humping theme music ? :)
<fabbione> we eat them 
<fabbione> no colored mushroom? no kernel...
<fabbione> http://www.saskschools.ca/~gregory/animals/images/bdgr2.jpg
<fabbione> this is cute
<T-Bone> stinky! 8)
<zul> T-Bone: no you are thinking skunks like pepe le peu
<zul> the french skunk ;)
<T-Bone> lol
<zul> fabbione: CONFIG_IDEDMA_ONLYDISK=y <-- shouldnt that be "n"?
<zul> might be a stupid question though
<fabbione> no
<fabbione> zul: read the backlog of the chan :-)
<fabbione> you set that to N
<fabbione> and you will get more dildos in your butt than goatse
<T-Bone> yummy
<T-Bone> care if i take pictures of that? :)
<zul> mmm...goats
<T-Bone> might be useful later for blackmailing 8)
<fabbione> T-Bone: no....
<fabbione> T-Bone: you know why nobody can blackmail me?
<fabbione> simply because everybody knows i am much worst than that
<fabbione> :)
<T-Bone> LOL
* T-Bone fortunes
<zul> and you have plenty of goats to be serviced
<fabbione> T-Bone: isn't easier for you to just wget the logs of this chan?
<fabbione> ok ladies
<fabbione> the new startnewrelease: target is in place
<fabbione> now.. any bug.. fix it
<fabbione> you have at least a baz branch :)
<T-Bone> fabbione: no. Because I'm doing some parsing and selection on what I actually fortune
<T-Bone> ;)
<fabbione> pitti will have to offer us a few liters of beer at UDU
<fabbione> we are making his life simpler on this kernel
<T-Bone> by disabling everything? :)
<Mithrandir> fabbione: I'm a bit scared about going to UDU.  I might survive, due to being drowned in beer.
<fabbione> i am not :-)
<fabbione> i wanna get a bath in beer
* T-Bone pesters lamont a little, wanders off for a short while
<T-Bone> berk
<lamont> fabbione: in -pre29?
<fabbione> lamont: yes
<T-Bone> oh, lamont is back! :)
<fabbione> everything is committed
<lamont> doh
* T-Bone cancel wandering
<T-Bone> +s
* lamont needs to take about a 30 min break
* T-Bone wanders off for 30mn then ;)
<T-Bone> (much better when we synchronize dude ;o)
* T-Bone ducks
<zul> pervs
<lamont> horses were mad at me, you see - bfast 4 hours late.. :0(
<zul> did they bite you?
<lamont> no - they just looked grumpy
<zul> ah...so its kind of like my wife when she is hungry :)
<zul> but she bites
* T-Bone is back
<T-Bone> lamont: dude? :)
<lamont> zul: heh
<lamont> T-Bone: evening
<T-Bone> lamont:  noon!
<lamont> note that hosting the archive is like the most trivial piece of the things that we need to do....
<T-Bone> hehe
<lamont> the infrastructure to deal with uploads is far more work
<T-Bone> no needs for uploads if it's self hosted, no?
<lamont> putting the archive on the buildd machine is kinda silly...
<lamont> since the buildd machine is, by very definition, compromised
<T-Bone> who said it'd be on the buildd machine?
<T-Bone> oh
<T-Bone> i guess i get your point
<lamont> so it'll be uploading to the archive machine, then, eh?
<T-Bone> you mean "it's far more work wherever the uploads go"?
<kylem> * tree version set kernel-team@ubuntu.com--2005/kernel-debian--pre29--2.6.10
<kylem> ok. figured that much out.
<kylem> :)
<T-Bone> lol
<jbailey> zul: Did you get a chance to look at the 1440 dmesg snippets?
<zul> jbailey: net yet..
<zul> i guess i could do it now :)
<lamont> T-Bone: yes
<lamont> kylem: heh.  now what?
<kylem> lamont, now i peruse, i suppose.
<lamont> you want something local to play with>
<zul> jbailey: comment #85?
<jbailey> zul: If you could that would be nice.  I'm mostly hoping that I missed something...
<kylem> lamont, i suspect the important bit is d-i
<lamont> kylem: yeah.  d-i makes life more interesting, to be sure.
<jbailey> zul: 84 and 85, yes.
<lamont> kylem: as I understand it, debian-installer_20041227ubuntu20 should be state-of-the-art for hppa d-i
<kylem> alrighty.
<lamont> build that, and you should get a bootable miniso... 
<kylem> argh. no netinst?
* T-Bone points lamont at some other window :)
<lamont> of course, the initrd is b0rked, so it's a pretty useless-but-bootable iso
<T-Bone> lol
<lamont> T-Bone: ah, scrolled off the right
<lamont> kylem: it builds a netbootiso as well
<kylem> ah, annoying. oh well. i should just slap a cdrom in the c3k, i need to do some debian d-i testing as well.
* T-Bone will have material to hack on pretty soon now ;)
<lamont> kylem: the initrd b0rkage is best summed up as 'nearly empty, needs modules'
<lamont> the question is, which modules...
<kylem> yah. that will need to be fixed in debian too, so it's probably what i'll look at first.
<zul> jbailey: on the first one there is an sr0 on the second there isnt which is weird
<jbailey> zul: Right, and I don't see the pata initialisation at all.
<zul> and it doesnt see the plexor eiter
<jbailey> I see ide-generic trying to grab the IDE CD down below with no success.
<jbailey> Kernel ide will actually not suck one day, right?
<zul> 2.6.11 i hear :)
<kylem> not before PATA dies, i hear. :)
<zul> you can try loading piix module im justy guessing ill have a look at it more tonight when i get home
<jbailey> kylem: So far it's not like SATA is having a raving success rating. =)
<zul> kylem: ex-oclug baord member right?
<jbailey> zul: But otherwise you concur that 1440 looks like it's alive and well again?
<kylem> zul, well, not ex... :)
<zul> jbailey: yeah on some cases 
<zul> kylem: heh
<kylem> zul, i'd like to be ex, but unfortunately not enough competent people were running.
<kylem> jbailey, lol.
<zul> kylem: you could always have pinteric as a board member
<kylem> please, no.
<zul> heheh...im so evil
<kylem> ah well. i'll let the people decide.
<kylem> lamont, do you guys have an installer channel?
<T-Bone> kylem: no
<kylem> ah, ok.
<T-Bone> kylem: the installer guru is Kamion on #u-devel
<jbailey> I'm on 5 #ubuntu- channels as it is.  Please don't make more. =)
<lamont> kylem: ubuntu-devel :-)
<kylem> yeah, i found it, unfortunately the 'team' stuff on the website and wiki is divergent. :)
<zul> jbailey: he isnt loading ata_piix in his initrd is he?
<jbailey> zul: I can't tell from this.  It looks like no, since there's usb stuff loaded first.
<jbailey> Hmm.  It would be interested to collect the output of lspci and lspci -n from all the ubuntu maintainers so that we could hit on them for hardware driver testing.
<Mithrandir> jbailey: scary. :)
<zul> isnt that what ogra is doing?
* Mithrandir runs off to dancing
<jbailey> Is he?  That would be lovely.
<jbailey> The past thing about the previous 2 SATA bits were that I had a box and thom had a box.
<jbailey> zul: Oh.  The second one is inside d-i.
<jbailey> zul: So that's what hotplug I guess things the drive is.
<zul> jbailey: ah ok
<jbailey> hmmhmm
<jbailey> I wonder if he just hasn't updated his kernel?
<jbailey> Why would the currently installed system from array 6 still work?
<jbailey> Both are on some form or 2.6.10-4
<zul> one probably had enable_atapi and enable_pata and the most recent kernels just ahave enable_atapi
<jbailey> Is there any sane way to get the top line in dmesg to give us the actual .deb version in it?
<zul> nope
<jbailey> Eh, truly?
<jbailey> No there must be.
<jbailey> It's showing us the gcc version is was built with, it must be possible in the build to generate some sort of -D line to gcc with the deb version in it to display.
<zul> actually i would have to check it might be in his kern.log
<jbailey> Well, for all that I could just ask him. =)
<jbailey> But it would be nice to have it just in the document already.
<jbailey> Far more useful to me than the version of gcc it was compiled with.  If I know the .deb version, I can figure out which gcc was in the archive at the time.
<zul> jbailey: uh there is actually dmesg -s500000
<zul> buffer size is 16392 by default
<jbailey> Hmm.
<jbailey> I guess I Can infer the kernel version from the date it was compiled.  Ugly, though.
<zul> chuck@oxdev:~/work/mmaker/final$ dmesg -s500000 | grep Linux
<zul> Linux version 2.6.10-5-686 (buildd@rothera) (gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)) #1 Tue Mar 15 15:16:01 UTC 2005
<zul> SELinux:  Disabled at boot.
<jbailey> Yes, that's the line that I'm looking at and which it had
<jbailey> Linux version 2.6.10-4-686-SMP (2.6.10-27) (buildd@....
<zul> oh yeah but it doesnt tell if it was -27 or else
<fabbione> what are you trying to achive?
<svenl> fabbione: mmm, we already have a line :         install debian/post-install $(srcdir)/debian
<T-Bone> fabbione: world domination
<svenl> in stamp-unpack.
<jbailey> fabbione: I have someone who shows signs of having #1440 again.  But it looks like his running system doesn't show it, just the installer.
<svenl> where does it come from ? And will it not fail if there is no debian/post-install ? 
<zul> peace and goodwill and a slick of bread with some butter 
<jbailey> fabbione: But I'm guessing at that since I can't reliably tell that he's *actually* using the same kernel in both cases.
* svenl would change that by a install debian/post-install-$(arch) $(srcdir)/debian/post-install instead
<jbailey> fabbione: Or, assuming he's not using the same kernel, what changes pertain to the exact rev he's using.
<fabbione> svenl: i dunno the origin of each single bit in that package
<fabbione> svenl: perhaps you want to support both post-install.${arch} with fall back to the default
<fabbione> jbailey: gotcha
<zul> jbailey: im pretty sure he isnt though
<fabbione> T-Bone: i already own all the ubuntu users... and most of the Debian ones.. i already achieved world domination a while ago...
<T-Bone> that can't be
<zul> yeah but debian cant be everything
<fabbione> T-Bone: as soon as Xorg 6.8.2 will be everywhere.. i will own everything
<T-Bone> fabbione: i don't recall you owning *me* ;o)
<jbailey> zul: Sure right, We see that in the way the ata_piix driver doesn't initialise the same in the two.  
* T-Bone looks back to make sure his butt is still his ;)
<fabbione> T-Bone: that's because you don't check all the changelogs of your software
<zul> im pretty sure that the first one is with the pata_enable and the second one isnt since we turned off pata because it was fucking people up
<T-Bone> lol
* T-Bone will let fabbione do the hard work and then will take over in a swift move 8)
<zul> you might want to see if he can either load it with ata_piix or just plain piix
<fabbione> T-Bone: at that time all my backdoor will rm -rf /
<T-Bone> lol
<fabbione> anyway
<fabbione> i need to go back to my wife
<T-Bone> hehe
<fabbione> it wasn't a really good day today
<fabbione> cya tomorrow
<T-Bone> heh
<T-Bone> cya dude
<zul> toodles
<jbailey> 'bye Fabio, may tomorrow be better.
<mdz> fabbione: good night
<zul> jbailey, now you made me loose track on what i was doing
<jbailey> zul: Sorry. =)
<jbailey> Actually, it looks like he might be using the same kernel between the two. =(
<jbailey> The "working" system has a build date of March 12.  That matches -27
<jbailey> His bug report time came on the 15th at 08:50.  -28 wasn't built until 22:!2
<svenl> fabbione: i think that debian/post-install doesn't exist yet, can you confirm that ? 
<svenl> fabbione: i don't believe that kernel-package can handle two post-install scripts.
<jbailey> OoOoOo, jordi mallach has one according to a Debian bug report.  Sweet.
<svenl> mmm, there seems already to be a post-install, maybe it should be modified in the powerpc case to call the powerpc specific one.
<svenl> mmm, i can also use debian/image.d instead.
<svenl> Maybe the main rule should be made to use debian/image.d/common and debian/image.d/powerpc instead.
<svenl> or something, instead of post-install.
<svenl> Any comment on that ? 
<zul> later folks
<mdz> is there a reason we don't build MEGARAID_NEWGEN?
<Mithrandir> I'm being told that the cds are lacking support for i2o controllers on at least amd64
<Mithrandir> would that be possible to fix?
<T-Bone> Mithrandir: if you consider it safe on amd64, i guess you can enable it in the amd64 configs, and test it thoroughly so that we make sure it doesn't break anything
<Mithrandir> T-Bone: I have boxes in production with the driver. :)
<T-Bone> as for the inclusion on a wider scale, I don't know what's the current merge policy
<Mithrandir> T-Bone: it's in the stock kernel so it's just a module to enable.
<T-Bone> well then, submit a patch to kernel-team@lists.ubuntu.com, or, better, branch from our baz archive and make your changes available somewhere
<T-Bone> you want to have fun with debian/configs/amd64 and debian/d-i/amd64, iirc
<T-Bone> see www.ubuntulinux.org/wiki/KernelTeamWork ;)
#ubuntu-kernel 2006-03-20
<max300> i need an ftp http ect password cracker for linux
<mroth> has anyone looked at Intel i945GM chipset support?  looks like a few one line patches to add the PCI ids and whatnot
<fbond> hello
<fbond> BenC, have a second to help out with integrating -rt21 with ubuntu's kernel?
<fbond> -386 works, but -686 locks at boot time
<fbond> it has to do with CONFIG_SMP
<fbond> i'm thinking ubuntu removed code from mainline that -rt21 needs
<fbond> anything come to mind?
<fbond> if you don't know, i may be stuck sorting through an 800,000 -line diff :)
<zul> die! die! die!
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: any idea how/why our pnp code went south?
<BenC> I believe it has something to do with that last acpi mondo patch
<mjg59> BenC: Yeah, it's acpipnp
<mjg59> There's a fix for it upstream, but I need to be able to isolate the patch
<BenC> ok
<pitti> Hi BenC 
<BenC> hey pitti
<pitti> BenC: do you need any further debugging info for that PnP breakage?
<BenC> mjg59 is aware of it, and is trying to isolate the patch from upstream to fix it
<pitti> ah, ok
<pitti> because there are some interesting mesages in dmesg
<pitti> alright, thanks
#ubuntu-kernel 2006-03-21
<mjg59> BenC: Hmm. When I end up rsyncing a huge pack file, should I be doing something else?
<infinity> Get more bandwidth?
<mjg59> Ah, it's just finished
<mjg59> fatal: Entry 'drivers/video/imacfb.c' would be overwritten by merge. Cannot merge.
<mjg59> Mm? How do I avoid that?
<fbond|away> well, at least git is ideologically superior to other RCS's
* chmj reads debian-kernel 
<Mithrandir> BenC: unionfs bug.  When casper does an mv /root/sbin/readahead-list /root/sbin/readahead-list.disabled, /sbin suddenly turns into mode 0700.
<zul> heylo
<Mithrandir> BenC: did you see my unionfs bug above?
<janimo> BenC: can you please revert the Radeon PCI id patch I suggested and it's in .17? While it makes 3D DRI work on said card it also sometimes causes X 99% cpu usage
<janimo> and sometmes locks on resume
<janimo> probbaly more that the ID pacth is needed (mesa,drm module) etc fixes which
<janimo> are too much for dapper
<janimo> sorry for not testing more thorougly before asking inclusion
<BenC> Mithrandir: yeah
<BenC> janimo: please send me an email so I don't forget
<janimo> BenC: ok, there are otther radeon IDs which seem to behave similarly and have bugs in malone.those may need to be reverted too 
<janimo> unless there's a way to blacklist them and not enable dri on them within X
<janimo> I'll send the mail
<Mithrandir> BenC: running Ubuntu kernels on auric and vore? :-P
<BenC> of course :)
<infinity> BenC: Seriously?
<infinity> BenC: Did neuro have a fit about that?
<Keybuk> Debian has run our Kernels for ages
<Keybuk> like, 2 years
<BenC> the sparc boxes were always running a custom kernel that I built
<BenC> so using an ubuntu kernel really isn't much different :)
<infinity> Fair enough.  The hppa buildds are in a similar boat.
<infinity> But that's more because lamont's only got time to focus on one kernel at a time.
<infinity> (Actually the m68k buildd mostly run custom kernels by me too... I often wonder how many of the SCC arch kernels in Debian can do much more than run the installer)
<BenC> I don't know what is all in the debian 2.6.15 sparc kernel, but all I know is that it's only a 9Meg image, and our sparc kernel is 14megs
<infinity> s/buildd/buildds/
<BenC> I'm a little leary of that
<infinity> BenC: Aren't you still, technically, a Debian sparc porter?  Perhaps you should look at their kernels and make them suck less?
<infinity> (And yes, I should do the same for Debian arches I care about, but I've always been a custom kernel guy on Debian...)
<infinity> Never ran a distribution kernel until I started running Ubuntu on my laptop.
<BenC> same here
<BenC> I always ran custom kernels till I became the ubuntu-kernel-guy :)
<zul> heylo
<BenC> I've been really disinterested in messing with debian stuff...I dropped my debian-sparc authorti a long time ago
<BenC> my notification icon is telling me to reboot, and I'm not one to argue with widgets, so brb
<mxpxpod> BenC: are you still using bcm43xx on your laptop?
<BenC> yeah
<mxpxpod> do you still coax it into 11mbs?
<mxpxpod> mb/s
<BenC> I've been using 24M for awhile
<BenC> haven't tried 54M again
<mxpxpod> how about network-manager?
<BenC> haven't tried that
<mxpxpod> ok
<zul> BenC: kyle did a presentation to my local lug on eficent use of git, ill put it up somewhere if you want
<janimo> zul, I'm interested in that too
<janimo> all the tutorials I read so far are scary
<janimo> if it were specifically written for the occasional ubuntu kernel contributor it would be even better
<crimsun> the link to the tutorial on kernel.org/git and wiki.u.c/KernelGitGuide are good starters
<crimsun> it's probably far easier if you set up a push server ; I have to use git-format-patch
<janimo> crimsun, I find the commands very low level
<janimo> I canot set upa push srever for bandwidth reasons
<janimo> I could not find simple recepies like : cherrypick patch from given repo
<janimo> those commit names are ugly. reminds me of tla frustrations of 2 years ago :)
<crimsun> janimo: have you tried any of cogito, StGIT, etc.?
<janimo> cogito I tried briefly
<janimo> stgit no
<janimo> crimsun, do you have 5 minutes now to tell me how you use git with alsa?
<crimsun> sure
<janimo> what I have now is git cloned ubuntu tree and ocasionally pull
<janimo> and beneath same working dir git bracnhes
<janimo> but from now on not much :)
<janimo> do you keep all branches under the same directory?
<crimsun> I generally don't worry about cwd at all
<janimo> and swicth with gt checkout
<crimsun> yep
<crimsun> git branch foo && git checkout foo
<janimo> git checkout -b foo
<janimo> :)
<janimo> how do you pick pacthes from upstream
<janimo> do you give the SHA ids?
<crimsun> oh, I can't do that for ALSA
<crimsun> for the HDA work in particular, I have to hand-merge
<janimo> :(
<janimo> is there some command line query on remote branches
<janimo> say I want to know diff between ubuntu tree and dri tree for file radeon_dri.c
<janimo> right now I go to gitweb on kernel.org
<janimo> that's kind of slow
<crimsun> hmm, why not just pull in the dri tree as a branch?
<janimo> hmm, I should try that . I was not sure how many upstream branches I can have locally
<janimo> I mean orig/masters
<janimo> but since they all should use the same objects underneath it may make sense
<janimo> ok so you do have alsa git pulled as a branch too?
<crimsun> no, but that would probably make a lot of sense, eh? :)
<janimo> :)
<janimo> related: I assume you test your patches by building the kernel
<janimo> how did you make it not take forever
<janimo> I touched config/i386/xx.config.disabled
<janimo> for all but one 
<janimo> but still seemed to build for hours and i had to stop
<crimsun> I just rm the ones I don't need
<janimo> last time I rm-d it did not make debs
<janimo> cannot remember the errors
<crimsun> oh, that's right, I remember why I don't have alsa git as a local branch
<janimo> so just rm, no need to touch makefiles or rules?
<crimsun> all devel work is done in cvs, and jaroslav pushes to git only occasionally
<janimo> same for dri
<janimo> so you actually take from cvs now?
<crimsun> it's just much faster for me to trawl cvsweb and apply what's necessary
<janimo> yeah
<crimsun> nope, I don't touch Makefiles or rules
<janimo> there must be a faster way that's why I think the tutorials are not telling us the whole story
<crimsun> perhaps zul has pointers :)
<janimo> yeah, I hope :)
<janimo> do you also use a smaller config that makeallconfig I assume?
<crimsun> nope, I use stock
<janimo> oh, doesn;t it take ages to build?
<crimsun> I have to make sure it at least builds on 686
<crimsun> oh yes, it takes a good long while
<janimo> you make debs with debuild or just plain make the kernel
<crimsun> debs
<janimo> debuild binary
<janimo> ?
<janimo> or full with clean and all that?
<crimsun> just binary
<janimo> thanks, I'll have to try the removal of config stuff
<janimo> althoug it seems the .disabled suffix is the one checked for
<TMM> hi all!
<TMM> to repost my question from both -devel and -server :
<TMM> what would me the chances of getting iscsi support into the -server kernel before dapper releases? slim? extremely small? near-zero? :) it pretty much doesn't touch any files, it just adds a couple
<TMM> I only today noticed it isn't in there, and, we (our company) wants to use more ubuntu, and it really should be there (r) I am working on packaging the userspace tools, and, I am using the suse sles9 patchesset as a basis, I can confirm that I am using these very same drivers in a couple of VERY large environments, and they have shown no sign of any breakage
<TMM> a seperate -source file in universe would be pretty bad imho, even under control of m-a
<TMM> I am willing to do any heavy-lifting that might be required btw
<TMM> I really need to go sleep now, if someone can help me, or wants more information or whatever please email me at hein-pieter.van.braam@ictivity.nl I basically know how to do the packaging, and have the equipment to test it all too. 
<TMM> thanks
<BenC> TMM: still around?
#ubuntu-kernel 2006-03-22
<zul> heylo
<makx> infinity: around?
<infinity> makx: Not really.  It's 3am, and I was supposed to be in bed ages ago. :)
<makx> ok, i'll send you mail.
<makx> checking if ubuntu is also affected by heavily guess yes..
<infinity> afftected by..?
<infinity> makx: ?
<makx> switched to boot
<makx> sorry you are not in #ubuntu-boot
<makx> 16:59 <makx> ok posting to the more relevant channel
<makx> 17:01 <makx> initramfs-tools gets minor wrong if you boot with root=341
<makx> 17:02 <makx> simple testcase on http://paste.debian.net/5276
<makx> 17:02 <makx> minor is the actual code, minorreal is what should be done
<makx> easy to fix just wanted to let you know.
<infinity> Ahh, cool.  I'm going to be doing some bugfixing next week, so I'll get that in, do some merging of other fixes from Debian, and fix up a bunch of longstanding bugs we both have.
<infinity> Should I add myself to Uploaders in the Debian package and just start uploading fixes there, or do you prefer to play release manager in Debian and have me push patches to you?
<makx> add yourself to the uploaders is fine with me.
<makx> i'll merge your stuff in my tree.
<makx> i tried to split up the long modules line in seperate files
<infinity> Kay.  Some of the fixes I need to do are pretty painful bugs, so I wanted to get them in both dists when I upload.
<makx> but the downside was a real longer initramfs generation
<infinity> Files with one module per line, filtered through "sort"?
<infinity> I can fix that so it's just as fast.
<makx> so i just aligned them to 80 chars inside hook-functions
<infinity> I'll fix that in my next upload.
* makx waits for your upload to mv /etc/mkinitramfs to /etc/initramfs-tools
<infinity> Yeah, that'll be a messy change, and one I may never do, just because it's messy.
<makx> well we never released with in debian ;)
<infinity> Besides, the binary /is/ mkinitramfs.  Who cares if it's not intuitively placed on the filesystem? :)
<infinity> Yeah, maybe I'll move it in Debian, let the bugs shake out, then merge the move in dapper+1 when I think it's safe. :)
<makx> no the binary is update-initramfs the ones othere should use
<infinity> No way I'm moving the conf directory this late in the game for dapper.
<makx> sure i waited for that :)
<infinity> makx: Well, that's true now.  We used to use mkinitramfs raw. :)
<infinity> We only started using update-initramfs in dapper.
<makx> ok, we only started since not long too
<makx> have a good sleep :)
<infinity> Danke.
<infinity> Later.
<dilinger> aw
* dilinger frowns at " and one I may never do"
<infinity> dilinger: Okay, okay.  I'll do it.
<doko> BenC: any news about the default for not spinning down the hard disks? at least in the server kernel
<BenC> doko: forgot about it
<BenC> I'll look into it over the weekend
<doko> thanks
<h36sa> hey guys, I'm looking to distupgrade to dapper from breezy, but right now I am running a modified kernel (just downloaded the image from somewhere) to fix the p4-clockmod workaround in breezy (my cpu is misdetected and is limited to 2ghz+.. not the best for a laptop). I'm wondering if the dapper kernel has this fixed or not
<overridden> helleuw
<overridden> is this the channel to report that every kernel above 2.6.12 freezes a random minutes after boot ?
<cjb> It might be, if one of the developers is around, but a full bug report would be even better.
<cjb> (If you also run another OS, you should try that to check it isn't your hardware that's failing/overheating/something.)
<overridden> Ok, but how do I get to some debug ingo ?
<overridden> *info
<overridden> because of the freeze, I dont get info
<cjb> If you fill out the bug report, someone will tell you what they need.
<overridden> ok
#ubuntu-kernel 2006-03-23
<mxpxpod> BenC: ping
#ubuntu-kernel 2006-03-24
<payrok> i noticed today that preemptible kernel was not enabled by default for the 2.6.12-10-i386 kernel.  I was just wondering what the reasoning might be behind that?  from what i understand i thought it would be a good thing...?
<payrok> anyone?
<payrok> i noticed today that preemptible kernel was not enabled by default for the 2.6.12-10-i386 kernel.  I was just wondering what the reasoning might be behind that?  from what i understand i thought it would be a good thing...?
<oops12> what actualy is the usage of preemtible kernel...?
<infinity> BenC: When do we get our next kernel upload?  I'm dying to put some testing to the ipw2200 version bump.
<BenC> infinity: guessing today
<makx> infinity my latest initramfs-tolls just got uploaded for todays d-install run, happy if you base your fixes on that.
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-19-28 uploaded (SiFu release) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-19.28 uploaded (SiFu release) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<mjg59> BenC: Two more patches for you
<mjg59> BenC: They shouldn't break ABI for anyone (there's a structure change, but since it only matters on IA32 and it couldn't possibly have worked before the change, nobody is using it)
<mjg59> Any chance that we could get a build of it in the near future? It's needed in order to make it possible to set up booting on the Macs
<fabbione> mjg59: he just uploaded this afteroon
<fabbione> afternoon
<mjg59> fabbione: Yeah, I know
<BenC> I'll get it out as quick as I can
<BenC> this week will be bug week for me, so it's a matter of how proficient that is  :)
<fabbione> hey BenC 
<BenC> hey fabio
<fabbione> Linksys or Netgear for a 24 port gigabit switch?
<fabbione> i can't efford Cisco.. too expensive :)
<mjg59> BenC: Heh. Ok.
<fabbione> http://www.linksys.com/servlet/Satellite?childpagename=US%2FLayout&packedargs=c%3DL_Product_C2%26cid%3D1115416901465&pagename=Linksys%2FCommon%2FVisitorWrapper
<fabbione> this one looks good
<fabbione> it does trunking too
<fabbione> mjg59: http://www.linksys.com/servlet/Satellite?c=L_Content_C1&childpagename=US%2FLayout&cid=1115416836002&pagename=Linksys%2FCommon%2FVisitorWrapper
<fabbione> ^^ ever seen that one
<fabbione> good night guys
<fabbione> cya tomorrow
<mjg59> fabbione: Yeah, it's nice
#ubuntu-kernel 2006-03-25
<infinity> BenC: ipw firmware version bump bit you and you're FTBFS.
<mjg59> BenC: If you need to reupload, any chance you can add that imacfb patch? :)
<mjg59> BenC: (But drop the efivars one)
<mjg59> Ooh, cool!
<mjg59> On that boot, my framebuffer came out as a tiny strip down the right-hand side of the screen...
<mjg59> Whoops. That's because it's cut off the trailing "2" from the width
<cjb> mjg59: Any idea who from Canonical is showing up at LinuxWorld in Boston?
<mjg59> Nope
<cjb> 'kay.
<mjg59> BenC: Did I send you the ipw3945 patch?
<infinity> BenC: Before uploading again, can you also apply the top two patches from http://ipw2200.sourceforge.net/#patches if you haven't already?
<infinity> BenC: I suspect the ipw2200 update will be pretty B-R-O-K-E-N without them. :)
<zul> sifu?
<fabbione> zul: must be the name of the pusher :)
<zul> ah...heh :)
<fabbione> s(n)if u?
<fabbione> BenC: davem had a couple of fixes for us.. if you need to reupload can you please pull from him?
<BenC> yeah, I'll be uploading in about 30 minutes
<fabbione> cool
<doko> BenC: does this upload include the hd-powerdown fix? ;-)
<BenC> no :)
<BenC> It's a bit complicated, but it will get done
<BenC> just want to make sure I don't break anything
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-19.29 uploaded (Stupid firmware) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<mjg59> BenC: Thanks for getting that patch in
<BenC> np
<mjg59> BenC: Need to sort out ipw3945 at some stage
<BenC> yeah, I'm hoping to have that in for next upload
<BenC> need to do the lrm parts aswell
<mjg59> Adam's happy enough with that, I think
<mxpxpod> mjg59: are you working on pmi?
<mjg59> On pmi? Not really.
<mjg59> Why?
<mxpxpod> mjg59: well, I just noticed they took the pbbuttonsd dependency out of it, which kind of messes some things up
<mxpxpod> like if you have the trackpad set to notap, when you come back from a sleep, it's back to tap
<mjg59> Oh, right. That needs to be special-cased.
<mjg59> Ideally in the kernel, but, well
<mxpxpod> and none of the pbbuttonsd scripts get called anymore either
<mjg59> No, they shouldn't
<mjg59> Some stuff needs fixing up to be generic, but pbbuttonsd is basically superceded now
<mxpxpod> ok
<mxpxpod> is ubuntu going to get a way to set powersave mode?
<mxpxpod> because I had that set up in my pbbuttonsd scripts
<mjg59> What precisely is powersave mode?
<mxpxpod> mjg59: I had it set up to use the powersave governor when my laptop was on battery
<mxpxpod> it extended the time of my battery about a half hour to an hour depending on what I was doing
<mjg59> mxpxpod: Uhm. But only by increasing the time it took to do anything, right?
<mxpxpod> not really
<mjg59> Our cpufreq setup will run the CPU at the lowest speed unless load increases
<mxpxpod> is powernowd still required?
<mjg59> Yes
<mxpxpod> and does cpufreq compliment that?
<mjg59> cpufreq is the kernel side of that
<mxpxpod> oh, another question... is gnome going to get the ability to set the brightness of a ppc machine?
<mxpxpod> lcd brightness, that is
<mjg59> That should already work with g-p-m
<mjg59> If it doesn't, then we need to fix hal
<mxpxpod> right, but if I use the brightness up/down buttons, I don't get a little dialog
<mjg59> Yeah, it would be good if we had that
<mxpxpod> because I think that's the last thing that relies on pbbuttonsd
<mjg59> Should be easy enough to add to g-p-m or gnome-settings-daemon
<mxpxpod> mjg59: I think it's actually patched out
<mjg59> It's just the dialog that's missing, the brightness changes happily?
<mxpxpod> yeah, the brightness changes thru pbbuttonsd
<mjg59> But we don't have pbbuttonsd now
<mxpxpod> it's still required by ubuntu-desktop
<mxpxpod> at least as of last night
<mjg59> Ah. Could you file a bug on that?
<mjg59> I'm fairly sure that's wrong
<mxpxpod> yeah, in a couple of hours...
<mxpxpod> mjg59: ok... also, when you come back from sleep, the sound is muted as well
<mxpxpod> mjg59: oh, and regarding powersave... it would be nice if g-p-m had a choice of whether to use full processor strength on battery or not
<mjg59> mxpxpod: I'm still not sure why that gives any real benefits
<mjg59> But yeah, I can sort of understand
<makx> hmm no new initramfs-tools on packages.u.c
* makx is curious about the serious bugs inifinity spoke about
<zul> so uh...when are we going to have 2.6.16 in dapper..:)
<fabbione> zul: i am not sure you want .16 in dapper
<fabbione> too much new stuff..
<fabbione> it will take at least .17 and .18 to stabilize
<zul> yeah i was just joking
<fabbione> yeah but i had the same idea :)
<fabbione> just uplaod .16 with .15 name
<BenC> sweet, ibm is going to include our three -server kernels in the ABAT system
<zul> abat?
<cjb> Dude, everyone knows about the Accelerated Badger and Tortoise system.
<BenC> Automated Build And Testing
<BenC> they'll test build our kernels, boot them and run some test suites (stress and LTP for now)
<BenC> hoping to get the results sent to kernel-team@l.u.c
* lamont thanks BenC for relieving him of the need to moderate kernel-{bugs,team}
<BenC> hehe, I didn't really want to take over moderation :)
<lamont> heh
<lamont> if you send me the passwd again, I'll moderate some more
<BenC> I don't know the password
<BenC> or did you send it to me?
<BenC> if so, I can take it over (no problem for me)
<lamont> the one I thought it was, it isn't...  so now I have to figure out what's going on...
<lamont> gimme some time
<BenC> ok
<lamont> sigh... firefox over ssh... I wish I knew how to remotely dump the saved passwords
<BenC> I forget how I did that the last time
<lamont> well, firing up firefox and clicking buttons works.. it just hurts
<lamont> BenC: do you know what address the mail will be coming from?
<BenC> *.ibm.com is all I know
<zul> hmmm...ok...apparently ubuntu has 25% of linux desktop market
<zul> according to this article
<zul> http://lxer.lxer.com/lxer/story/56437/index.html
<cjb> What does distrowatch say?
<zul> heh...i dont pay attention to distrowatch ;)
#ubuntu-kernel 2006-03-26
<kirkland> is there a such place where one can find a nightly (or regular) tarball of bcollins/ubuntu-2.6.git tree?
<kirkland> i see /topic, but those look a little out of date...
<crimsun> kirkland: I don't know offhand, but you can always just crontab a ``git pull''
<mjg59> BenC: When you updated the bcm code, you seemed to stomp over my patches...
<BenC> crap, I probably did
<mjg59> BenC: Should just reapply, with luck
<BenC> wish bcm had a 2.6.15 git tree :/
<BenC> yeah, I can probably re-base them in git
<mjg59> You're pulling from the 2.6.16 one and then merging back?
<BenC> your changes or bcm43xx in general?
<mjg59> bcm43xx in general
<BenC> nah, grabbing daily-snapshot tarball and just copying
<BenC> 2.6.16 would be hard to pull from
<crimsun> BenC: (just a minor, but s/David/Daniel/ in the changelog)
<BenC> ah, sorry :)
<crimsun> no biggie :)
<BenC> done
<crimsun> gracias
<mjg59> BenC: Ah, ok
<mjg59> BenC: If you could reapply my diff, that would be great
<lamont> BenC: isn't ide-generic still the module that acutally triggers ide subsystem initialization?
<Keybuk> BenC: ping
<BenC> lamont: no
<Keybuk> BenC: it appears I missed a discussion this afternoon
<makx> BenC: are you sure? (i mean considering isa)
<BenC_> ide works with ide-generic
<Keybuk> BenC_: so it appears I missed a discussion this afternoon?
<BenC_> Keybuk: appears so :)
<Keybuk> BenC_: which is a shame, because your conclusions were all wrong
* Keybuk wishes someone had phoned him
<Keybuk> anyway, am replying now via e-mail
<BenC_> I don't recall having any conclusions
<Keybuk> "wait 10s before loading ide-generic"
<BenC_> that's not a conclusion, that's a suggestion :)
<Keybuk> it's a decision, according to your e-mail
<Keybuk> <g>
<BenC_> based on Mith's argument
<Keybuk> it won't help a monkey's
<Keybuk> the kernel already has that "sleep 10" in the IDE init code
<Keybuk> which is in the module loading bit
<Keybuk> so blocks the return of modprobe
<BenC_> but if the module load is blocking, so are all other modules
<Keybuk> "all other modules" ?
<BenC_> I didn't know ide-generic had a sleep(10) i it
<Keybuk> ide-generic doesn't
<BenC_> or is this ide-core?
<Keybuk> every IDE driver does
<Keybuk> ide-core
<Keybuk> modprobe real-pci-driver
<Keybuk> consistently doesn't return until udev has the events
<BenC_> is this the "Probing later" thing?
<Keybuk> it can take a few seconds to return on most things
<Keybuk> I don't know what "probing later" is
<BenC_> are you sure you read Mith's arguments that promoted me suggesting that?
<BenC_> prompted
<BenC_> he statement was that the main reason we don't use UUID more widely is that it has some dependency on the bus type
<Keybuk> right
<Keybuk> and the sleep 10 won't change that
<Keybuk> it doesn't have a dependency on the bus type
<Keybuk> this is the bit where me being there would have helped
<BenC_> he stated differently
<Keybuk> ok, so here's how the initramfs bits work
<Keybuk> first we look at the ROOT= to detect the bus type
<Keybuk> either IDE or "everything else" (which are always scsi)
<BenC_> then it does have code that depends on ide or !ide
<mjg59> Keybuk: Eh? That's entirely untrue, as far as I can tell
<Keybuk> All the drivers under the scsi subsystem (which includes sata, usb, firewire) behave one way
<mjg59> Keybuk: I can't find any sign of a sleep(10) in the ide-generic load path
<Keybuk> the modprobe returns immediately, then at some point in the future the driver finds its devices
<Keybuk> mjg59: not a literal sleep(10); not ide-generic; the ide-core probes and binds for the REAL PCI DRIVERS before modprobe can return
<mjg59> Keybuk: How?
<Keybuk> mjg59: please let me finish first
<Keybuk> ok, so for scsi and friends; we have to iterate the bus, modprobe all the drivers, then sit back and wait for the devices to show up
<Keybuk> sit back and wait up to three minutes
<Keybuk> for especially slow scsi controllers (fabbione delights in owning these)
<Keybuk> so we do it with a simple while loop; while the root device hasn't shown up on disc, sleep another tenth of a second
<Keybuk> if it at the end of that loop, the root device still hasn't shown up, we give up
<BenC> ok, the ide portion is more important :)
<Keybuk> for dapper+1 I'd like to extend that to "wait forever", and have some pretty on screen message saying something along the lines of "if your root disk isn't plugged in, could you do that?"
<Keybuk> so that's scsi
<Keybuk> ide we do it differently, because the ide subsystem has different quirks
<Keybuk> the drivers behave the other way, the modprobe doesn't return until the driver has done the probe-and-bind
<Keybuk> there's no asynchronous component to them
<Keybuk> we also may have to load ide-generic on legacy ISA machines
<Keybuk> and in some cases with a root device on an ancient PCMCIA controller (which counts as "legacy ISA" in my mind)
<mjg59> Keybuk: I'm still not finding anywhere where the PCI IDE drivers differ from normal PCI drivers (where there is an asynchronous component)
<mjg59> Hm. PCMCIA ought to come under pcmcia_cs
<mjg59> Uh, ide_cs
<BenC> regular PCI IDE drivers use pci probing, and normal device layer callbacks
<makx> pcmcia bridges are not incl. in latest initramfs by default
<Keybuk> mjg59: critical path.  the ide core already knows what devices are available.  so there's no issuing of a probe command, and waiting for it to return.  it just iterates an already-in-memory structure and does the magic
<mjg59> There's a corner case where it's not actually PCMCIA, but an on-board IDE interface is connected via the PMCIA slot
<BenC> the difference is that IDE detects the drives at the same time it detects the controllers
<BenC> so Keybuk is correct in how it works
<Keybuk> right
<Keybuk> if you detect the controller, you also just detected the drives
<BenC> how do you decide to load ide-generic?
<Keybuk> scsi after detecting the controller you have to ask the controller nicely to go detect the drives and get back to you on that
<Keybuk> right
<Keybuk> so because of the way ide works in this regard, what we do is
<Keybuk> iterate each PCI device in order, and load the module for it, waiting for everything to settle in between
<mjg59> Keybuk: You load piix. That registers itself as an IDE driver, which in turn calls pci_register_driver. After pci_register_driver, the probe routine in piix (piix_init_one) is called. If that binds to something, it does ide_setup_pci_device (which actually allocates the interface)
<mjg59> Isn't that exactly the same as loading a network driver, except that pci_register_device is done in the IDE layer rather than in the module itself?
<Keybuk> mjg59: right, nothing there returns to userspace
<Keybuk> thanks for verifying that for us :)
<Keybuk> so we know after we've loaded the PCI drivers, if the root device still hasn't shown up, it isn't going to show up later
<Keybuk> so we load ide-generic as a last resort
<Keybuk> scsi looks like "load drivers; wait for root device to show up; abort after 3 minutes"
<Keybuk> ide looks like "load drivers sequentially; if root device hasn't shown up, load ide-generic"
<mjg59> So the original discussion appears to have been based on the false premise that we need to know whether the root device is on ide or not in order to only load ide-generic at the appropriate time?
<Keybuk> well, no
<BenC> no, it's correct
<Keybuk> we still need to know whether we may or may not need to load ide-generic
<BenC> the only incorrect info I got was the loading ide-generic was racy and could cause problems
<mjg59> Why not load scsi drivers first, then ide drivers (at this point based on PCI IDs), then unconditionally load ide-generic if there's still no rootfs?
<mjg59> Loading ide-generic isn't going to hurt in the case where the PCI driver has already bound the io-ports
<Keybuk> mjg59: because of FUCKING SATA
<mjg59> Keybuk: But you've already loaded the driver
<Keybuk> SATA as far as I'm concerned is a scsi driver
<BenC> mjg59: according to Mith, Fabio's crappy scsi controller breaks if you load ide-generic
<Keybuk> it behaves like scsi drivers
<Keybuk> most importantly, it returns from modprobe immediately, before performing the controller-specific initialisation
<Keybuk> so modprobe piix-sata will return straight away, and udev will get the devices some few seconds later
<Keybuk> on some older SATA controllers, on a busy system, this can be 10-15s
<BenC> Keybuk: ok, here's the problems I see....
<Keybuk> loading ide-generic at any point before the SATA SCSI driver has finished can sometimes "steal" the devices from it
<Keybuk> the solution wwould be to only load ide-generic after the three minutes are up
<Keybuk> which means everyone on ISA would have to wait 3 minutes before their machine started booting
<mjg59> Keybuk: ata_piix calls piix_init, which calls pci_module_init, which will then provide a probe method which registers the pors
<BenC> Keybuk: IMO, we should detect that ide-generic is needed at install, and make a note of it for initramfs to use :)
<mjg59> Keybuk: I'm still not seeing how this is different to the IDE case (though there may be something very simple I'm missing)
<BenC> or when initramfs is built, it could detect that
<Keybuk> mjg59: right, and then it returns to userspace, and libata later calls the probe method
<Keybuk> BenC: I agree.  We can look in /sys in the installer and see whether the driver is ide-generic or not;  if not, use UUID
<mjg59> Keybuk: Sorry, /which/ probe method?
<Keybuk> mjg59: I can't remember offhand; when I looked through the code (a few months ago) the SATA stuff was very much callback orientated
<Keybuk> and hooked into the SCSI bits of the kernel which are totally async
<BenC> mjg59: from what I can tell, scsi device probing happens in the scsiX kernel process and not in the module probe code path
<Keybuk> whereas IDE was all one obvious line of function call codes
<mjg59> BenC: What are you defining as "scsi device probing"?
<Keybuk> mjg59: "devices handled by the kernel scsi subsystem", which includes SATA ide drives
<BenC> where it probes for devices attached to the controller, as opposed to the controller itself
<mjg59> BenC: But by that time it's already registered the i/o ports, surely?
<Keybuk> mjg59: not always,no
<Keybuk> loading the controller driver doesn't guarantee anything other than you've opened the controller
<BenC> mjg59: i/o for the controller yes, but for the ports no
<Keybuk> at that point, you may be lucky enough for the ports to be registered, but not generally
<Keybuk> device probing on the controller happens later
<mjg59> pci_request_regions is done in ata_pci_init_one
<mjg59> Which is called directly from the ata_piix PCI probe routine
<Keybuk> mjg59: there's an easy way to test it btw
<Keybuk> boot with break=top
<mjg59> Keybuk: Well, if I had any SATA machines...
<Keybuk> modprobe -a piix-sata ide-generic
<mjg59> (That is, SATA machines with legacy i/o)
<Keybuk> about 7/10 times, your drives will be /dev/hda rather than /dev/sda
<Keybuk> or just trawl malone for the ~100 bugs about that
<mjg59> Keybuk: Right, I'm willing to believe that, but I still don't see any mechanism by which this can be true for sata but not for IDE
<Keybuk> one of them from mdz :)  his laptop loves to trigger that case
<mjg59> Uh. When did mdz get a new laptop?
<Keybuk> sorry, strike that; mdz had a different bug, I think
<mjg59> Yeah, he had ide-generic binding before piix
<Keybuk> yeah
<Keybuk> he doesn't have a sata laptop
<mjg59> (Which you've just been telling me is impossible, but :) )
<Keybuk> no we loaded ide-generic first in his case
<Keybuk> that was a clear-out bug :p
<Keybuk> mjg59: if you start with IDE from the top, you'll see that nothing returns to userspace until the drives are already probed for and bound
<Keybuk> mjg59: if you start with SCSI/SATA from the top, there are plenty of return to userspace b
<Keybuk> points before the drives are probed for
<mjg59> Keybuk: As far as I can tell, in both the IDE and sata cases, the io regions are requested in the call into the core layer that occurs at the end of the pci probe
<BenC> ok, from what I'm hearing, ide-generic should really be the corner case instead of ide in general
<Keybuk> I'm not sure about registering of i/o ports, I wasn't looking for that
<Keybuk> and I don't really understand that
<mjg59> Keybuk: It's the registration of i/o ports that's then /entire point/
<Keybuk> I was looking at pure "when does the kernel create sdXY and associate it with that driver"
<mjg59> If the i/o ports are registered, ide-generic won't bind. Otherwise, it will.
<Keybuk> but ide-generic does bind
<mjg59> Keybuk: Yes, but that's not the problem
<BenC> yeah, which driver grabs the ports from the kernel is the winner
<mjg59> So. How can that situation arise in the sata case, but not the ide one?
<BenC> but from what I can tell, there not only i/o per controller, but i/o per device
<mjg59> BenC: No
<mjg59> One i/o region per channel
<BenC> ok, one per primary and secondary
<Keybuk> I'm quite happy to change the initramfs code to look like:
<Keybuk> - load pci drivers
<Keybuk> - load ide-generic
<Keybuk> - wait for up to three minutes for the root device to show up
<Keybuk> - abort
<mjg59> Keybuk: Could you take a look at drivers/scsi/ata_piix.c and tell me where it enters userspace between loading and hitting line 4843 of libata-core?
<mjg59> I'm genuinely failing to get this
<Keybuk> I can't see where it gets to libata-core
<Keybuk> ah, sorry
<Keybuk> at the bottom
<Keybuk> right so piix_init calls pci_module_init calls piix_init_one calls ata_pci_init_one
<mjg59> Yes
<mjg59> Which is identical to the IDE case, as far as I can tell
<Keybuk> right
<Keybuk> and is this true for every single sata driver?
<Keybuk> if it's true that all the sata drivers reserve their regions in init, then I'm happy
<Keybuk> that may not have been true earlier, or we may have had a different bug
<mjg59> ahci seems to do it internally, but doesn't do legacy IDE anyway as far as I can tell
<Keybuk> and as long as reserving the regions guarantees ide-generic can't steal the devices
<BenC> that still doesn't help out issue where scsi in general is delayed device probing
<Keybuk> how does it effect that issue?
<mjg59> BenC: That's fine. Load all SCSI controllers, loda all PCI IDE, load ide-generic, wait up to three minutes (or whatever)
<BenC> sata behaving like ide doesn't help anything :)
<Keybuk> this wouldn't distinguish between SCSI and PCI IDE drivers
<Keybuk> can anyone recall off-hand how we avoid loading both the SATA and PATA driver for a controller?
<Keybuk> do we do that in the kernel?
<mjg59> They have different PCI IDs
<BenC> so basically, from my point of view is, load scsi, ide, ide-generic, loop for 3 minutes checking for device path and/or UUID
<mjg59> BenC: Yeah
<mjg59> Keybuk: We still need to deal with the case where ata_piix binds to the controller but can't drive it
<Keybuk> mjg59: we do?
<Keybuk> do we deal with that nw?
<mjg59> No
<mjg59> Which breaks several machines
<Keybuk> oh, well, if it's not a regression... :)
<Keybuk> was this what we talked briefly about in the DeathSprint?
<mjg59> It's not a regression, but it's been an open bug since before breezy
<mjg59> Think so
<mjg59> ahci and ata_piix share PCI IDs. We should always try to bind ahci first.
<Keybuk> can't remember what the decision was there though
<mjg59> Currently, the reverse happens
<Keybuk> right, and some cards work for ahci, some for ata_piix
<Keybuk> and you can't tell which?
<mjg59> ahci should always fail when it's not drivable by ahci
<mjg59> But ata_piix will sometimes bind even when it can't drive it
<Keybuk> why doesn't ata_piix do the same?
<Keybuk> that sounds like the bug to me
<mjg59> Broken BIOS
<Keybuk> they might have a second ide controller that needs ata_piix
<mjg59> Or, rather, the detection code in ata_piix assumes the BIOS is sensible
<mjg59> Keybuk: I can't see how
<mjg59> Keybuk: You can't get them on PCI cards
<mjg59> Though it would be more of a problem once ata_piix is needed for driving PATA devices
<mjg59> (So not a dapper issue)
<Keybuk> yeah, my inclination with anything involving two fighting modules is to fix the modules
<Keybuk> as there's always a corner case where you may HAVE to load both modules on a given machine
<mjg59> I'm not convinced it's possible to fix the module in this case
<Keybuk> we have similar examples today where people have OSS and ALSA sound cards in the same machine
<Keybuk> and have filed bugs saying that ALSA OSS emulation doesn't work
<mjg59> Right, but that's clearly a bug in alsa
<Keybuk> or there's one where they need both snd_bt87x and bt878 loaded; but snd_bt87x won't work if bttv (dep of bt878) has been loaded first, etc.
<BenC> yeah, that's a bttv bug, IMO
<Keybuk> I
<Keybuk> I do want to think about "blacklist-if" kind of thing for dapper+1
<mjg59> Keybuk: Ok. Almost all sata drivers call pci_request_regions themselves. The only one that doesn't is ata_piix, and that's the case we've already discussed
<mjg59> So if there's no race in ide, I can't see any race here
<Keybuk> hmm
<Keybuk> the only thing about modifying modprobe to selectively blacklist, or force a particular order, is it only works if one alias requests both modules
<Keybuk> it fails for when you have two devices which cause both modules to be loaded
<Keybuk> which again, leads me back to pointing at the driver itself and saying "iz module bug"
<mjg59> Well, I'm fairly convinced it's a BIOS bug
<Keybuk> we can't ship updates to those via APT though :p
<mjg59> Yeah, so the issue is whether we can work around it
<mjg59> Based on what you were saying earlier, just loading ahci first should be sufficient, right?
<mjg59> Because it should bind to the PCI device before you've had a chance to load ata_piix
<Keybuk> the problem is when ata_piix and ahci are loaded due to different devices
<Keybuk> no, it's a race condition :(
<mjg59> That's not going to be a problem in this specific case
<mjg59> Hang on. How is that a race condition and our earlier conversation wasn't?
<Keybuk> (on phone, will be more eloquent in a sec)
<mjg59> If there's a race between ahci and ata_piix being loaded, surely there's a race between piix and ide-generic?
<mjg59> (I'm ignoring the case of multiple PCI devices, because that doesn't apply in the problem case as far as I can tell)
<lamont> BenC: I could swear that was the case in 2.6.12 for ia64 (at least...)  ISTR uploading 3 times to get it right...
<Keybuk> mjg59: sorry, off phone now
<Keybuk> damned relationships are so hard work <g>
<Keybuk> race condition was with multiple devices, as we call modprobe at basically the same time
<Keybuk> we could do a modprobe patch to handle the case of both drivers being expanded from an alias for a single device
<Keybuk> would be trivial
<Keybuk> it builds a list of them, and just have a "force-order" config option or something
<Keybuk> sorting depmod output would be another option
<mjg59> Keybuk: Right. In the cases I've seen, there's only one device
<mjg59> So just having it load ahci first would be fine
<cjb> Has anyone seen problems with bluetooth on latest dapper?  I can boot 2.6.15-15, but 2.6.15-19 spawns gdm and then presumably tries to do something with hcid that never returns; I never get any gettys launched.
<cjb> If I hit ctrl+alt+del on the empty tty1, the shutdown gets to stopping hcid and then hangs there.
<lamont>  4) load ide-generic for legacy ISA systems
<lamont> hrm...
<mdz> cjb: try to confirm that hcid is in fact getting hung up, and then see if you can find out what's causing it
<lamont> what do we do on ia64 boxes?
<mdz> lamont: the same thing?
<lamont> if we loaded any ide modules, i think we have to load it.
<lamont> unless they fixed 2.6.15 to not do ide init (on ia64) in ide-generic...
<mdz> lamont: read that "for" as "for the benefit of" not "only for"
<lamont> ah, pok
<infinity> Indeed.
<lamont> s/p//
<infinity> ide-generic is still required for anyone with root on /dev/hd* ... More or less.
<infinity> So we load it last, after the rest of the world settles (or doesn't)
<lamont> ciik
<lamont> cool
<mdz> infinity: this seems to have been called into question during the discussions today, but we're still loading it at the end
* lamont slaps his keyboard
<infinity> mdz: Yeah, I've read the (heated) backscroll a bit while attempting to wake up. :)
<mjg59> lamont: That hasn't been the case for a while
<mjg59> lamont: legacy IDE init is done when ide-generic is loaded, but anything else will be driven by the appropriate PCI driver
<mjg59> Anyway, after discussing it with Scott, we've come to the conclusion that there are no races now
<lamont> mjg59: the issue I ran into was with an ide hard drive...
<mjg59> lamont: In the old days, you loaded PCI drivers and then had to load ide-generic in order to get the PCI drivers to bind
<mjg59> That was a bug, and it's been fixed
<lamont> 0000:a0:02.0 IDE interface: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0649 (rev 02)
<lamont> ah, ok.
<lamont> for old days == something including breezy's 2.6.12?
<mjg59> Probably, yeah
<lamont> ok
<mjg59> lamont: I don't seem to get ide-generic loaded at all now
#ubuntu-kernel 2007-03-19
<fabbione> BenC: did you get around to fix ia64 FTBFS for -12 ?
<BenC> fabbione: Yes, it wont be fixed for beta, but it will be fixed right after
<fabbione> BenC: is the fix in git already? (that's enough for me)
<BenC> fabbione: Not yet
<fabbione> i don't really care about beta.. i need the ia64 box for clustering..
<BenC> I can get it in when I get up in the morning
<fabbione> BenC: could you push it on the fly?
<fabbione> ok
<BenC> will be done in about 7-8 hours :)
<fabbione> yeah i understand
<fabbione> i was hoping to test the fixes today but i need ia64 to build
<fabbione> running asymmetric kernel code to test a fix is not sane :)
<fabbione> but ok.. i guess it will wait tomorrow
<TheMuso> c
<paran> hi. is there some reason that debugfs (CONFIG_DEBUG_FS) is not enabled in feistys kernel?
<paran> seems to be enabled in most other distributions (Debian etch, FC6, RHEL5, SUSE10)
<fabbione> paran: it was losf from edgy to feisty
<fabbione> i already re-enabled it in git
<fabbione> it will be on in the next kernel upload
<paran> fabbione: ah, that sounds good
<BenC> Kernel Team meeting in 10 minutes in #ubuntu-meeting for those interested, agenda is at https://wiki.ubuntu.com/KernelTeam/Meeting
<dholbach> pkl_, BenC: looks like bug 84359 is fixed
<BenC> dholbach: Excellent, thanks for retesting
<dholbach> np
<dholbach> it just took a while since my kvm died last week :)
<dholbach> do you want me to close the bug?
<dade_> does the feisty kernel support irq pnp ?
<pmjdebruijn> dade_, irq pnp of what?
<dade_> bios plug and play irq settings I guess
<pmjdebruijn> why shouldn't it?
<pmjdebruijn> dade_, do you have a particular issue?
<dade_> 'cause I'm using edgy and I have the irq 10 used from many peripherials
<dade_> it's a laptop
<dade_> and sound does not work at all
<pmjdebruijn> dade_, isn't the BIOS wrong?
<dade_>  10:     704996          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb3, ehci_hcd:usb4, ohci1394, yenta, yenta, radeon@pci:0000:01:00.0
<mjg59> The problem isn't going to be anything to do with the irq
<mjg59> That's perfectly normal
<dade_> the bios is a phoenix bios and does not allow me to change irqs or disable the irq pnp
<mjg59> NOTABUG
<dade_> sorry
<kylem> haha. holy fuck.
<kylem> what kind of computer is that?
<dade_> acer travelmate 800
<dade_> 803lmi
<kylem> is it newish?
<mjg59> It's not using APIC
<mjg59> Which presumably means the BIOS has disabled it
<kylem> mjg59, yeah.
<dade_> and what can i do
<mjg59> Nothing
<mjg59> It's not a bug
<kylem> dade_, try to update your BIOS?
<dade_> [17179569.184000]  Local APIC disabled by BIOS (or by default) -- you can enable it with "lapic"
<dade_> you're right
<dade_> should I try "lapic" ?
<kylem> well, it's disabled for good reason.
<mjg59> You can try, but *it's not a bug*
<mjg59> If your sound isn't working, it's for some other reason
<mjg59> PCI works fine with shared IRQs
<eeanm> I have vmplayer, does it include the script to compile the needed kernel modules?
<eeanm> They aren't packaged for Feisty
<Nafallo> eeanm: restricted
<eeanm> Nafallo: did they move from where they were in Edgy?
<eeanm> or you mean the script?
<eeanm> I have restricted added
<Nafallo> eeanm: I have no idea. I know there is a lot of vmware stuff in restricted. apt-cache search vmware
<eeanm> hmm maybe not
<eeanm> Nafallo: thanks :)
<Nafallo> no
<Nafallo> no problem even :-)
<bleinmono> will fiesty support weak modules?
<mjg59> What is a "weak module"?
<bleinmono> the one that doesn't require rebuilding once you update the kernel (as i understand it)
<mjg59> No
#ubuntu-kernel 2007-03-20
<fabbione> BenC: ping?
<BenC> fabbione: yo
<fabbione> BenC: hey man.. i think something on i386 kernels is broken badly
<BenC> fabbione: Can you describe?
<fabbione> trace -o /home/fabbione/foo.strace /bin/ls
<fabbione> umovestr: Input/output error
<fabbione> bin    dev   initrd      lib64       mirrors  proc  sbin  tmp  vmlinuz
<fabbione> boot   etc   initrd.img  lost+found  mnt      raid  srv   usr
<fabbione> cdrom  home  lib         media       opt      root  sys   var
<fabbione> make that a strace
<fabbione> i get a lot of errors (also confirmed by different people on #u-devel) like that umovestr
<fabbione> it seems to happen only i386
<BenC> is this the -12 kernel?
<fabbione> if you strace something bigger you might see also other errors like ptrace: Input/Output error
<fabbione> confirmed to be there from at least .20-9
<fabbione> but yes. i am specifically running .20-12
<BenC> hmm
<BenC> cool, I have -6 and -7 on this box, let me check those
<fabbione> ok
<BenC> fabbione: Same on -7
<fabbione> ok
<Keybuk> BenC: random question about the kernel, if you have time to answer it
<BenC> Keybuk: Sure
<Keybuk> disk write cache; does that get flushed on shutdown?
<Keybuk> specifically for IDE
<mjg59> Yes
<Keybuk> can you cite a reference in the source; I couldn't find out for definite where it happened
<mjg59> Unless you're seeing massive filesystem corruption, in which case the answer is probably no (but shouldb be yes)
<Keybuk> I can see it happens when you reboot, but not halt or poweroff
<Mithrandir> hm, maybe that's the reason why I've seen some ext3 corruption in the past.
<mjg59> Keybuk: Hm. In the poweroff case, I suspect that it's supposed to be done when the drive's powered down
<Keybuk> but I can't see anything that even powers down the drive :p
<mjg59> Keybuk: Just to clarify - do you mean drivers/ide or libata?
<BenC> fabbione: Same as far back as -6
<Keybuk> drivers/ide
<Keybuk> reason for asking:
<Keybuk> the sysvinit halt binary deliberately standbys IDE disks by iterating /proc/ide
<Keybuk> and the manpage claims this is because the Linux kernel doesn't
<mjg59> Hm. It's conceivable.
<Keybuk> this seems somewhat silly to me; and causes problems when you try and run halt on things like <hardware from Sony>s which don't have an IDE controller
<mjg59> (Go go stupid workarounds)
<Keybuk> I could believe that the manpage is way out of date
<Keybuk> or if not, and it's a simple patch, it'd seem sweeter to fix the kernel?
<mjg59> Yeah
<ivoks> mjg59: do we have any policy for 
<ivoks> mjg59: doh.. STOP_SERVICES in /etc/default/acpi-support
<mjg59> Yes. Don't add things to it.
<ivoks> ok :)
<kylem> Keybuk, are you complaining about what? sata/scsi?
<mjg59> kylem: drivers/ide
<kylem> ah.
<kylem> well. turn off your write cache. it's a bad idea anyway.
<Keybuk> kylem: is it off by default? :p
<kylem> it should be on most disks.
<kylem> unless hdd folks have gotten really ballsy in the last couple years.
<kylem> SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
<kylem> huh. poop.
<Keybuk>        The  -h  flag  puts  all  harddisks in standby mode just before halt or
<Keybuk>        poweroff. Right now this is only implemented for  IDE  drives.  A  side
<Keybuk>        effect  of putting the drive in standby mode is that the write cache on
<Keybuk>        the disk is flushed. This is important for IDE drives, since the kernel
<Keybuk>        doesnt flush the write-cache itself before poweroff.
<Keybuk> (is the sysvinit halt manpage reference)
<kylem> anyway, if you're using libata-pata, the scsi layer will send a SYNC CACHES command which should end up in libata and be issues properly to the drive.
<kylem> Keybuk, interesting.
<seb128> hi
<seb128> I'm trying to rebuild a feisty kernel with the 8390.c from edgy following the instructions on https://wiki.ubuntu.com/KernelCustomBuild
<seb128> I've apt-get install linux-source, copied the tar.bz2 somewhere, untar-ed it, copied the .c and now I'm running "AUTOBUILD=1 fakeroot debian/rules binary-debs" which doesn't work
<seb128> "make: *** No rule to make target `binary-debs'.  Stop."
<seb128> any idea of what I'm doing wrong? ;)
<abogani> seb128: That procedure works only with original git sources....
<seb128> abogani: the wiki page is not clear then ;)
<abogani> seb128: exactly :-)
<seb128> ok, using make-kpkg then ;)
<seb128> thank you
<abogani> seb128: Nothing
<Simira> does anyone know the bug number on "fan doesn't work after resume"? It's a kernel bug with hp laptops, that's reappeared. 
<BenC> Simira: It should be fixed in 2.6.20-12 kernels
<Simira> BenC: I just tested on daily
<Simira> BenC: and it doesn't work for me
<BenC> Does it have -12 kernel?
<Simira> yup
<BenC> I included all the mentioned patch sets to fix that, so if something else is needed, someone with that hw will have to work out what it is
<BenC> You've got about 3 weeks to do it :)
<Simira> I'll test again. We're two testing this spesific model, so we should manage to work it out
<BenC> Simira: If you need to find the bug, do an advanced search on linux-source-2.6.20 and include "Fix Released" bugs
<Simira> BenC: I'll do that. Thanks
<seb128> anything else I can try about bug #87078? 2.6.20 doesn't build with the 8390.c from 2.6.17
<seb128> and the "irqpoll" option makes the box freeze during desktop login
<abogani> seb128: If you use apt-get source linux-source-2.6.20 you can use "AUTOBUILD.... etc etc" as reported in the wiki page
<seb128> abogani: ok, thank you
<BenC> fabbione: FYI, I get the strace problem all the way back to -6
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: Hey, I want to enable the tifm_ms+memstick driver you sent me, but it's missing linux/memstick.h
<mjg59> BenC: Ok. I'll try to sort that.
<BenC> mjg59: Thanks
<fabbione> BenC: ok
<Lure> Simira: I am currently building kernel with additional patches that may fix fan & resume issues on hp laptops
<Lure> Simira: will document in bug what I find
<Lure> cd
<orangey> hey all!
<Lure> Simira: related bugs are 63123, 75398 & 74877
<orangey> Ben Collins has accepted a patch into the kernel that makes ide-acpi.c, however, it is not enabled in the kernel binaries
<orangey> Lure: I'm the dude who submitted the unified patch..
<orangey> Lure: I saw your comments.
<Lure> orangey: yep, one patch from your diff is missing, I have traced most fixes back in upstream git
<orangey> re config for kernel: what config do I play with to patch? I want to enable IDEACPI
<orangey> Lure: awesome.
<orangey> Lure: you're talking about 37?
<BenC> orangey: In feisty, it's enabled
<BenC> at least it should be
<Lure> BenC: is it possible to build generic without lowlatency (building with flavour=generic)?
<BenC> $ rgrep BLK_DEV_IDEACPI debian/config/debian/config/ia64/config:CONFIG_BLK_DEV_IDEACPI=y
<BenC> debian/config/i386/config:CONFIG_BLK_DEV_IDEACPI=y
<BenC> debian/config/amd64/config:CONFIG_BLK_DEV_IDEACPI=y
<Lure> BenC: it is enabled
<BenC> in dact, it is enabled
<BenC> fact
<BenC> Lure: rm -f debian/config/*/lowlatency
<orangey> BenC: ah. ok.
<Lure> BenC: thanks - will shorten my build by half ;-)
<orangey> BenC: it seems I don't have the most recent source, then. one moment.
<BenC> orangey: grep IDEACPI /boot/config-`uname -r`
<orangey> BenC: yep. there!
<BenC> orangey: Then you have nothing to worry about :)
<orangey> BenC: my bad. In that case, there is some other reason I can't figure out for why my system will no longer resume with this kernel.
<BenC> orangey: Please file a bug report on linux-source-2.6.20 with as much information as possible
<orangey> BenC: will do as soon as I have info : )
<BenC> like what kernel version suspend/resume worked with, what type of resume (mem/disk), etc.
<Lure> BenC: is there any way to override ABI check or do I need to bump ABI number on my local git clone?
<orangey> hmm..
<orangey> It seems my conflicting problems have hit..
<BenC> Lure: debian/rules .... skipabi=true
<BenC> Lure: See topic, all this info is under our wiki
<Lure> BenC: thanks for help and sorry for bothering you
<BenC> Lure: No problem at all, just figured there may be other things in the wiki that could help you
<Lure> BenC: it helped a lot (actually I was lurking when you had online session), it is just a lot to digest ;-)
<BenC> Lure: The stuff in KernelTeam/KnowledgeBase is probably most interesting for what you're doing
<BenC> custom kernel build bits
<orangey> alright.. time to reboot and retest. I think I have the issue figured out.
<orangey> Thank you Ben.
<orangey> Amazing work, btw.
<orangey> It's my first interaction at all with kernel stuff or patching, and you have made it pleasant via your patience.
<orangey> thank you.
<orangey> see y'all : )
<BenC> orangey: Np
<BenC> crimsun: ping
* Lure reboots to test kernel
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.19 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 359 Open, 0 Unconfirmed, 126 Unassigned
<Nafallo> nice
<orangey> hey all.
<orangey> back.
<orangey> Alright. I think I have a good idea of the problem. For whatever reason, it is ata_piix that stops my NC4200 from booting. It was noted that it had to be disabled for suspend / resume to work, however that leaves me victim of the ALERT! no /dev/by-uuid-whatever problem, where I can't boot..
<orangey> now..
<orangey> any ideas how I could try to track down the problem more than that?
<orangey> or must this work be done via bug tracking?
<orangey_> bah.. Just got disconnected, so repasting the message:
<orangey_> Alright. I think I have a good idea of the problem. For whatever reason, it is ata_piix that stops my NC4200 from booting. It was noted that it had to be disabled for suspend / resume to work, however that leaves me victim of the ALERT! no /dev/by-uuid-whatever problem, where I can't boot.. now.. any ideas how I could try to track down the problem more than that? or must this work be done via bug tracking?
<orangey_> rather, ata_piix stops the NC4200 from Resuming after suspend.
<crimsun> BenC: pong
<BenC> crimsun: Hey, just FYI, I'm assigning all sound/audio related bug to the ubuntu-audio group
<BenC> crimsun: In case you go wondering around for audio bugs filed on linux-source-2.6.20 :)
<crimsun> BenC: yep, according to the triaging practices
<BenC> crimsun: Ah, I forgot that I told you this already
<BenC> I'm burned out from bugs today, brain is failing me right now
<crimsun> heh, I hear ya
<Simira> Lure, BenC: we are two people who have tested the daily(-12) kernel twice, and the fans don't work. :(
<Lure> Simira: right, I am testing some more patches from upstream - first try did not help :-(
<BenC> Simira: If you can build kernels, then perhaps start looking into the patches geared that the type of laptop
<Simira> BenC: not really, but I might be able to get some competent guidance 
<Mithrandir> BenC: I could try git-bisecting on it.
<Mithrandir> (Simira is my wife)
<BenC> Mithrandir: I'm not sure there's a case of it ever working to bisect against, other than edgy...or do you have a known working feisty kernel?
<Mithrandir> BenC: -9 apparently worked.
<BenC> Ok, then a bisect would be greatly appreciated
<Whoopie> I have problems with running latest kernel in a vmware with the virtual cd-rom. As I can't see any obvious messages in dmesg, I disabled the cd-rom and now it works. Seems to be related to ata driver. Did anybody see the same behaviour?
<crimsun> there are certain known regressions from -10.17 and -11.18
<crimsun> without additional information, it's all hand-waving
<Whoopie> crimsun: but it worked with -11
<Whoopie> crimsun: I know that one need more information. i just thought I give it a try. ;)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.19 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 343 Open, 1 Unconfirmed, 64 Unassigned
<kylem> Benbot4000
<ivoks> crimsun: if you need any help with muting not working, i'm here :)
<crimsun> ivoks: I'm working through an alsa issue atm
<ivoks> that's why i say; i'm here to help as much as i can
<crimsun> I'm a poor multitasker; patience, please.
<ivoks> :)
#ubuntu-kernel 2007-03-21
<claydoh> BenC: referred to you by hobbsee re: bug 85488
<claydoh> what are the possible consequences of disabling 'USB selective suspend/resume and wakeup'?
<BenC> claydoh: Breaking suspend/resume and random other USB devices
<BenC> claydoh: It's a no-win situation...I have to break some usb host/dev setups in order to make suspend/resume work for a good portion of other people
<claydoh> as I thought, thanks
<BenC> claydoh: Fixing the drivers it the correct solution (to work with suspend/resume), but I don't have any of that hw, so it's hard for me to do, not to mention having the time
<claydoh> but as some (most) sane scanner backends do work it seems easier to take it to the broken backends' maintainers for fixes 
<BenC> claydoh: I've updated the bug report with what I just said to you
<mjg59> BenC: Isn't USB_SUSPEND about runtime suspend?
<BenC> mjg59: Ah right, not sure what I was thinking
<BenC> but it is still needed, because the signaling was required for some devices to work
<BenC> there's probably some bug references in dapper/edgy changelogs
<BenC> Been enabled since 2.6.15-24.41
<BenC> no bug reference, shitty
<mjg59> Strange that it seems to have worked on edgy
<BenC> question is why does it break sane scanning
<BenC> that too
* Starting logfile irclogs/ubuntu-kernel.log
<raf> goodmorning. i have compiled and installed 2.6.20.3 on feisty buntu this morning..and im unable to install the nvidia driver. i have all the neccesary programs installed gcc, kern. source. has anyone come across this problem?
<fabbione> BenC: hey dude
<BenC> fabbione: Hey
<fabbione> BenC: we got a patch to test to fix DLM in the kernel, but i need to be able to build ia64.. anything we can about it?
<fabbione> BenC: it would be really good to have it both in the kernel (the fix) and the workaround in userland)
<BenC> fabbione: Yeah, sorry it's taken so long, my i2k doesn't like to boot very often
<grazieno> hi people, can someone help me? https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-March/000553.html
<grazieno> I'm tryng to solve the bug 75935
<grazieno> Via VT6410 ide raid
<mjg59> See https://wiki.ubuntu.com/KernelTeam
<grazieno> mjg59: Did you speak to me?
<mjg59> Yes
<grazieno> ok, I'm looking
<fabbione> BenC: ok.. can you try again today please so that i can test that patch? i don't have another x86 to slam in the cluster and sparc is no go on RHCS
<BenC> fabbione: Will do
<fabbione> thanks
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.19 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 331 Open, 3 Unconfirmed, 23 Unassigned
<Keybuk> err
<Keybuk> so vmware-config.pl doesn't work on feisty
<Keybuk> I'm certain this is known by now :p so what's the workaround?
<fabbione> Keybuk: i build the modules manually and install them in /lib../misc/
<fabbione> depmod -a
<fabbione> modprobe them
<fabbione> run vmware-config again
<Keybuk> how do you build the modules?
<Keybuk> that's what's failing
<fabbione> you will need a one liner patch for vmmon
<fabbione> the sources are in /usr/lib/vmware/...
<fabbione> just untar them and run make
<fabbione> one of them will fail
<Keybuk> what's the patch?
<fabbione> just comment out the line where it fails (duplicate definition of something)
<fabbione> it's a .. _syscall1 IIRC
<Keybuk> I don't get a duplicate definition error, I get a expected declaration specifiers error
<fabbione> yeah that one.. 
<fabbione> i need to get off this office.. the Niagara is melting my head
<fabbione> -ETOONOISE
<crimsun> (http://icanthack.com/?p=53  , for instance; see the comments)
<Keybuk> commenting out that line seems to solve it, thanks
<Keybuk> then I get
<Keybuk> /tmp/vmware-config1/vmnet-only/userif.c:629: error: CHECKSUM_HW undeclared (first use in this function)
<crimsun> http://icanthack.com/wp-content/uploads/2007/01/vmnet.patch
<fabbione> uh?
<fabbione> what version of vmware are you installing?
<fabbione> i didn't get that one with 5.5.x
<fabbione> 5.5.3-34685
<Keybuk> 5.5.2
<BenC> Keybuk: check the patches in lrm for the modules there
<BenC> same stuff
* fabbione -> off now
<Keybuk> BenC: it never seems to want to use those modules though
<BenC> Keybuk: tar xf, patch, tar cf, let vmware-config do it's thing
<BenC> Keybuk: Patch the source, and let vmware-config.pl build from it
<BenC> Keybuk: Or get ws6 beta and it will build without problems
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.19 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 324 Open, 0 Unconfirmed, 0 Unassigned
<Mithrandir> \o/
<BenC> w00t
<BenC> "Assigned to me (64)"
<Nafallo> rock on!
<Mithrandir> BenC: can you tell me anything about the scope of the bug?  Is it as bad as I was afraid of on #-devel?
<BenC> Mithrandir: it's so bad we need it in beta
<Mithrandir> ok
<BenC> Mithrandir: but we already have a fix, and I am in the process of uploading the new tarball, and a test package for sladen to try
<Mithrandir> ok, goodie.
<BenC> I'll hold the tarball on rookery till he confirms the fix
<BenC> Mithrandir: it's non abi bump, I just patches 2.6.20-12.19
<BenC> my stuff in git is too big and untested right now to upload
<BenC> plus it's an abi bump
<Mithrandir> ok, so it's localised to just the IDE driver?
<BenC> it could affect a lot of things actually
<Mithrandir> ugh.
<BenC> but I think libata is the only thing using devres that we pulled in for last upload
<Mithrandir> do you have the diff somewhere?  Not that I know much of the kernel, but more eyes can't hurt.
<BenC> the bug was actually in lib/iomap.c
<BenC> the diff was pulled from an upstream fix for the bug
<BenC> I just cherry picked it, and it mentions the exact trace back we have
<Mithrandir> ok, that sounds good then.
<kylem> iz pretty critical fix
<BenC> <paste, sue me>
<BenC>     [PATCH]  pci_iomap_regions() error handling fix
<BenC> 
<BenC>     It appears that the pcim_iomap_regions() function doesn't get the error
<BenC>     handling right. It BUGs early at boot with a backtrace along the lines of:
<BenC> 
<BenC>     ahci_init
<BenC>     pci_register_driver
<BenC>     driver_register
<BenC>     [...] 
<BenC>     ahci_init_one
<BenC>     pcim_iomap_region
<BenC>     pcim_iounmap
<BenC> so it's dead on
<mjg59> Ooooooooooooooooh
<mjg59> It's the case where ahci tries to load, fails and then ata_piix takes over
<BenC> right
<mjg59> That makes sense
<mjg59> And would explain why it only seems to be hitting ICH6
<kylem> right
<kylem> in hindsight pulling in this devres stuff may not have been such a hot idea...
<Mithrandir> ok, so we get the fix confirmed for a couple of boxes, then upload, then roll isos then test.
<BenC> well, we needed some of the new libata drivers and libata-acpi fixes...was easier to pull 3 commits for devres than backport the stuff
<BenC> Mithrandir: sounds good
<BenC> test deb is almost done
<BenC> tarball is on rookery already
<kylem> BenC, 8-way not fast enough? :P
<BenC> hehe
<BenC> it's built, but kernel-package is just too stupid to not try to run the build 5 more times during the packaging process
<BenC> deb is heading to rookery
<crimsun> I can try, too (I'm affected)
<crimsun> s/can/would like to/
<BenC> http://people.ubuntu.com/~bcollins/kernels/bug-93648/linux-image-2.6.20-12-generic_2.6.20-12.20_i386.deb
<BenC> 8172368b874be9ed6777c818052e08a4  linux-image-2.6.20-12-generic_2.6.20-12.20_i386.deb
<crimsun> BenC: -12.20 confirmed working on my hardware.
<crimsun> thanks much
<BenC> crimsun: great, thanks
<\sh> BenC: where can I download your test package? I would like to test it on my t43
<BenC> BenC http://people.ubuntu.com/~bcollins/kernels/bug-93648/linux-image-2.6.20-12-generic_2.6.20-12.20_i386.deb
<BenC>  8172368b874be9ed6777c818052e08a4  linux-image-2.6.20-12-generic_2.6.20-12.20_i386.deb
<\sh> give me a few
<\sh> dpkg: Fehler beim Bearbeiten von linux-image-2.6.20-12-generic_2.6.20-12.20_i386.deb (--install):
<\sh>  nicht ganz gelesen in buffer_copy (Backend dpkg-deb whrend ./boot/vmlinuz-2.6.20-12-generic)
<\sh> Running postrm hook script /sbin/update-grub.
<\sh> You shouldn't call /sbin/update-grub. Please call /usr/sbin/update-grub instead!
<\sh> rebooting now
<BenC> ignore that, it's just older kernel-package on my build box
<BenC> or old stuff on your system :)
<\sh> BenC: works like a charme
<BenC> \sh: Thanks
<Nafallo> 3/3 :-)
<\sh> BenC: np :)
<Lure> BenC: re bug 63123> so you need the actual commit in acpi-test where the fix was pulled in/merged into linus tree?
<BenC> Lure: No, I need the commit SHA id from linux-2.6.git that I can use with git-cherry-pick
<Lure> BenC: I am still looking into polling issue - not sure if this is required or not
<BenC> Lure: One of them was ok, but it didn't pick cleanly, looks like it depends on other commits not listed
<dade`> BenC: 
<dade`> r u alive
<BenC> dade`: barely
<dade`> I'm using 2.6.20-12-generic
<dade`> and psmouse does not work
<Lure> BenC: ok, I have manually applied them here, will try git-cherry-pick and find you workable set
<BenC> Lure: Ok, please order them as well, so I get the right ones in dependency order
<BenC> Lure: Thanks
<Lure> BenC: ok, thank you
<dade`> cat /dev/input/eventN where N is the right one :P does not give output
<BenC> dade`: Does dmesg show anything interesting?
<dade`> I tried reloading the module and I get
<dade`> [  586.136000]  input: SynPS/2 Synaptics TouchPad as /class/input/input9
<dade`> [  586.336000]  psmouse.c: Failed to enable mouse on isa0060/serio1
<dade`> BenC: this--^
<BenC> dade`: Looks like it is failing to send a command to the ps2 device
<BenC> dade`: Does going back to -11 fix it?
<BenC> Nothing related to this changed between -11 and -12, so I'm a bit confused
<dade`> BenC: don't know if -11 worked.. I user edgy before
<dade`> used
<BenC> Does booting edgy kernel fix it?
<dade`> Should I try now ? :P
<BenC> sure :)
<dade`> ok.. wait -.- bbl
<BenC> crimsun: FYI, all your patches from last night/this morning, applied. Thanks
<bdmurray> BenC: Do you have a second?
<BenC> bdmurray: Sure
<bdmurray> it seems suspend and hibernate are confused on my laptop
<bdmurray> hibernate writes to swap and suspend goes into low power
<BenC> Sounds like a gnome-power-manager issue
<BenC> bdmurray: Does it do that when you write mem/disk to /sys/power/state ?
<bdmurray> I tried sudo pmi action and the behavior was the same
<BenC> oh way, no that's right
<BenC> suspend is low power, and hibernate is suspend2disk
<bdmurray> really? that seems backwards to me
<BenC> hibernate requires no power, suspend is low power sleep mode
<BenC> well, the naming is just a userspace convention...the kernel just knows suspen2mem and suspend2disk
<Mithrandir> bdmurray: hibernate is what bears do during winter.  Suspend is what you do when you delay something for a bit.  Makes lots of sense to me.
<BenC> userspace seems to call s2mem Suspend/Stand-by, and s2disk Hibernate
<dade`> ..
<bdmurray> Mithrandir: that might help me remember, thanks
<dade`> the edgy kernel does not boot anymore, is that right ?
<dade`> BenC: 
<BenC> dade`: Possible that it doesn't agree with feisty userspace
<BenC> dade`: Do you have a edgy livecd you can boot?
<dade`> heh, so I could try the -11, but you just told me that there is no difference in psmouse
<dade`> BenC: I don't but.. I always used the psmouse touchpad on edgy
<dade`> I'm sure it works
<BenC> dade`: I just need to alleviate any possibility that somehow the hw has gone bad...not likely but it has happened before
<BenC> I've chased a bug for 2 days just to have the person tell me the cable they used for a USB device was just too long :/
<psusi> lol
<dade`> it's a lappie, internal touchpad.. 15 hours ago I was using edgy and my sweet touchpad
<BenC> dade`: Well, it's an isolated problem. I've been through almost the entire bug list yesterday and I didn't see anyone else mentioning anything like this
<BenC> dade`: If you could try to test it under the edgy kernel somehow (just boot edgy kernel to initramfs, and check dmesg for the mouse mesg's)
<dade`> hm
<dade`> BenC: -11 has the same problem. I'm going to download an edgy live cd :(
<crimsun> BenC: thanks
<BenC> dade`: Ok
<pepsiman> Hi, I've upgraded to feisty and the cx88-dvb module isn't loaded at boot, it was in edgy.  Any idea why it has changed?  The other modules for this card are loaded correctly
#ubuntu-kernel 2007-03-22
<zul> hey
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.19 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 333 Open, 0 Unconfirmed, 0 Unassigned
* Starting logfile irclogs/ubuntu-kernel.log
<heno> bug 84964
<stgraber> ubugtu doesn't seem to be here 
<heno> seems to be a boot failure on ICH8 chipsets
<ivoks> stgraber: bug #84964
<ivoks> oh... it doesn't work :)
<stgraber> As I said ubugtu isn't here :)
<dade`> BenC: I'm sorry, it was not a kernel fault
<BenC> dade`: Ah :)
<BenC> dade`: What was it?
<dade`> are you sure you want to know ?
<BenC> yes, I'm eager to know :)
<dade`> BenC: this laptop has a fn+f7 key that toggles on and off the touchpad... I'd never seend souch thing before..
<dade`> the symbol is a SQUARE, I thought it was something to enable external monitor..
<dade`> feel free to laugh
<dade`> (at me)
<heno> bug 84964 is another possible boot problem with ICH8 and amd64
<heno> BenC: should we worry about that? ^
<BenC> dade`: I would laugh, but I've made such mistakes before :)
<BenC> heno: Checking
<BenC> heno: It's probably too late for beta, but I'll make it my priority for a post-beta-release fix
<heno> BenC: OK, it seems to affect less people than the previous one
<BenC> heno: I think this one has a mix of problems too, they just all have the same symptom
<BenC> AlinuxOS: Are you on the machine that is having the problem?
<AlinuxOS> BenC, nothing to discuss :) I see that bug exists...how can I help you ?
<AlinuxOS> BenC, yes.
<BenC> AlinuxOS: the bug doesn't have very useful information at the moment
<BenC> AlinuxOS: Can you pastebin the output of "lspci -vv"?
<AlinuxOS> BenC, and I'm simple transaltor...if I can contribute something I'm ready.
<AlinuxOS> ok
<AlinuxOS> BenC, just a moment.
<tritium> BenC: I experienced that bug until the fix you made yesterday for #93648.
<BenC> tritium: This one is different...the one I fixed yesterday only affects -12, the one I'm working on now has been around since -7
<tritium> BenC: okay
<BenC> tritium: But thanks for testing that fix
<tritium> BenC: thank _you_ for fixing it.
<BenC> unfortunately the two bugs appeared the same to most users, so there's some confusion in the bug report and I need more clarification
<AlinuxOS> BenC, which syntax do you prefer ?
<AlinuxOS> http://paste.ubuntu-nl.org/ ?
<BenC> AlinuxOS: Doesn't matter, that one is fine
<AlinuxOS> BenC, http://paste.ubuntu-nl.org/11496/ here you are.
<BenC> AlinuxOS: How are your disks connected, SATA/IDE?
<BenC> AlinuxOS: Any hw raid configurations?
<AlinuxOS> no raid, only SATA
<Lutin> hi
<AlinuxOS> BenC, 1 SATA HD only
<BenC> AlinuxOS: Ok, do you have a kernel that boots ok?
<AlinuxOS> yes I use in this moment: Linux brugherio 2.6.20-6-generic #2 SMP Wed Jan 31 20:53:39 UTC 2007 i686 GNU/Linux
<BenC> Lutin: Can you pastebin your "lcpci -vv" output?
<Lutin> ok
<tritium> BenC: if you need details on my hardware, to isolate the difference in the two bugs, let me know.  I have Thinkpad T43p with ICH6 and an SATA hd.
<BenC> AlinuxOS: Can you pastebin your dmesg output then please?
<AlinuxOS> BenC, Lutin has the same problem ?
<BenC> tritium: Ok, thanks
<AlinuxOS> BenC, just a moment.
<Lutin> AlinuxOS: yes
<BenC> AlinuxOS: yes, so this will help me see if there's some commonality
<AlinuxOS> BenC, http://paste.ubuntu-nl.org/11497/ dmesg output.
<Lutin> BenC: lspci -vv: http://pastebin.ca/406486
<BenC> Lutin: Ok, you're ICH8...what is your HD config, SATA/IDE, any hw raid config?
<Simira> Lure: what is your status on the hibernate problem? I believe #75398 is still not solved
<Lutin> BenC: 1 HDD sata2, no raid
<BenC> Lutin: Also, are you in ahci mode, or piix?
<Lutin> ahci
<BenC> Lutin: Have you tried changing to piix in bios to see if that helps?
<Lutin> yes, but it was hanging up as weel iirc. can't tell you if this was for the same reason though
<BenC> AlinuxOS: Is it possible for you to boot into a newer kernel, removing the "quiet splash" options from the kernel command line and get the last disk related output from the kernel?
<Simira> BenC: sorry for being extremely late with this, but the fan still doesn't restart with resume from hibernate on hp nw-models
<BenC> Simira: Yes, someone is looking into patches for that...waiting on them, since they have the hw and can rebuild kernels
<AlinuxOS> BenC, you mean to boot: Ubuntu, kernel 2.6.20-12-generic?
<Simira> BenC: ok, great. 
<BenC> AlinuxOS: yes
<BenC> AlinuxOS: In grub, you can edit the command line to remove those two options
<AlinuxOS> How ?: "get the last disk related output from the kernel?"
<BenC> AlinuxOS: Should be the last thing on the screen when it stops, but be sure to wait the full three minutes for busybox to show up
<AlinuxOS> title           Ubuntu, kernel 2.6.20-12-generic
<AlinuxOS> root            (hd0,2)
<AlinuxOS> kernel          /vmlinuz-2.6.20-12-generic root=UUID=634f3a3a-404c-47cf-aace-c5c8a056f452 ro 
<AlinuxOS> initrd          /initrd.img-2.6.20-12-generic
<AlinuxOS> quiet
<AlinuxOS> savedefault
<AlinuxOS> ok in this way ?
<BenC> AlinuxOS: A digital photo or hand written copy of the output would be good
<BenC> AlinuxOS: yes, that's good
<AlinuxOS> ok
<BenC> Lutin: Can you do the same, get me dmesg from current good boot, and reboot to the bad kernel to get the output?
<AlinuxOS> ups have no digital photo machine :(
<AlinuxOS> how many line should I write down ? :)
<AlinuxOS> lines
<AlinuxOS> BenC, ?
<BenC> AlinuxOS: Should be no more than 10, don't worry about the time stamps on the left side in braces (the "[0000003434.900] " stuff)
<AlinuxOS> BenC, ok.
<BenC> AlinuxOS: If you see an oops/bug, then the main portions are the first line saying why it oopsed/bug'd and the stack trace are important
<Lutin> BenC: ok. (note that bad and good and bad kernel are the same one here because it randomly boots, about once/15)
<BenC> Lutin: Oooh, you definitely have a different bug then, but one I want to help with, so let's continue
<Lutin> ok
<BenC> Lutin: Does -12 work for you?
<Lutin> randomly
<BenC> Ok, please use that one for testing if you can
<BenC> the actual code for drivers/ata/ changed a lot after -11, so it will keep the info consistent with current source
<Lutin> sometimes it hangs up while accessin gthe disks, sometimes while modprobing cx88* modules
<BenC> interesting...probably an oops occurs earlier than is causing the hang later on
<Lutin> BenC: do you need the dmesg when the boot is ok ?
<BenC> Lutin: yes, please
<Lutin> BenC: http://dunnewind.net/~lutin/dmesg
<BenC> Lutin: Do you actually have two of the same CD/DVD drives attached?
<Lutin> BenC: yes, 2 samsung sata dvd writers
<BenC> Lutin: Ok, this all looks good, can you get the info from the failed boot now?
<Lutin> BenC: I have some things currently building on that box, I'll reboot asap (~20min)
<BenC> Lutin: Ok, thanks
<Lutin> np
<ivoks> BenC: i've downloaded 20070322.2 and it has some ata_piix issues
<BenC> ivoks: is that kernel -12.20, or -12.19?
<AlinuxOS> BenC, http://alinuxos.no-ip.org/debug.jpg
<BenC> ivoks: cat /proc/version_signature should tell you
<ivoks> -12.20
<ivoks> i'm testing this in qemu
<ivoks> it worked before...
<ivoks> now it does not detect cdrom
<BenC> AlinuxOS: Great, there's a crash...but I can't see the important parts :)
<AlinuxOS> BenC, my termianl letters are so huge
<AlinuxOS> BenC, I use 1280x1024 resolution
<BenC> AlinuxOS: Can you add vga=771 to the kernel command line and see if that helps things
<ivoks> BenC: http://www.grad.hr/~ivoks/fail.jpg
<BenC> ivoks: Ah, I've seen that one in another bug
<fabbione> i see those too, but then it works for me
<BenC> ivoks: Is there a kernel version that works for you?
<BenC> ivoks: Is it just -12 that broke things?
<ivoks> BenC: i've tested only with -12
<ivoks> but... i've tested daily old couple of days
<ivoks> and it worked
<mjg59> That's pretty clearly something unrelated to this bug
<ivoks> i agree
<BenC> right, definitely not this one, just wondering where it regressed
<ivoks> i think i have old daily somewhere...
<ivoks> 2.6.20-9.16 works
<BenC> it's probably a -12 regression
<ivoks> i've just installed -12 on my laptop (ICH7), so i'll check it IRL soon :)
<ivoks> fwiw -11 works ok
<BenC> make sure it's -12.20 and not -12.19
<BenC> else you're sure to hit a bug
<ivoks> yes, it is
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.20 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 333 Open, 0 Unconfirmed, 0 Unassigned
<ivoks> ups...
<ivoks> i'm using  2.6.20-12.19-generic
<ivoks> and it works
<ivoks> brb
<BenC> didn't have time to tell him that id .19 works, then .20 surely will :)
<ivoks> both -12.19 and -12.20 work fine here :/
<ivoks> i've seen problems only with -12.20 on qemu
<BenC> ivoks: what about -12.19?
<AlinuxOS> BenC, refresh my url please.
<ivoks> i didn't try it in qemu :(
<BenC> should be the same
<BenC> AlinuxOS: Ok
<BenC> ivoks: What IDE controller does qemu emulate?
<BenC> AlinuxOS: oooh, you have a crash in ohci1394, interesting
<AlinuxOS> BenC, sorry for using Microsoft Wireless Desktop :)
<ivoks> Intel 82371SB PIIX3
<BenC> AlinuxOS: hey, we use what we can, no big deal
<AlinuxOS> BenC, right
<BenC> ivoks: Maybe we should revert that one back to piix instead of ata_piix
<ivoks> right... old daily used piix, not ata_piix
<ivoks> err... kernel :)
<BenC> maybe best to do that for everything < ICH6
<BenC> AlinuxOS: : echo "blacklist ohci1394" | sudo tee /etc/modprobe.d/ohci1394-blacklist
<BenC> AlinuxOS: sudo update-initramfs -u
<BenC> AlinuxOS: And reboot to see if works
<BenC> brb in 5, coffee+smoke
<AlinuxOS> BenC, don't smoke! :P
<ivoks> light one for me :)
<AlinuxOS> ok done now rebooting.
<AlinuxOS> BenC, http://alinuxos.no-ip.org/debug2.jpg
<AlinuxOS> after: echo "blacklist ohci1394" | sudo tee /etc/modprobe.d/ohci1394-blacklist
<AlinuxOS> and sudo update-initramfs -u  command.
<BenC> Ok, no more ohci1394 crash, but still no disk...hmm
<mjg59> So ata still isn't working
<AlinuxOS> mjg59, hello ;)
<AlinuxOS> mjg59, how are you ?
<BenC> AlinuxOS: ok, at this point when you get to busybox shell, can you do "lsmod | grep ata" and see if sata_nv is loaded?
<mjg59> Busy :)
<AlinuxOS> mjg59, understand you ! ;)
<AlinuxOS> BenC, ok.
<BenC> AlinuxOS: Also, "cat /proc/kmsg | grep ata" afterwards (this will hang the console, since the cat cannot be ^C'd)
<BenC> wish someone would fix busybox to get tty+job-control :/
<AlinuxOS> BenC, do you need screenshots ? (it's my mobile phone screens...are they enough?)
<BenC> AlinuxOS: Of the last command for kmsg, yes...your screen shots are perfect
<AlinuxOS> reboot
<BenC> cool, latest ieee1394 has host suspend/resume support
<BenC> might help some people
<Lutin> BenC: sorry, there's no way I can get a log
<Lutin> I can see the errors, but the kernel keep on booting an then freeze at some point, but I can't see the actual error
<BenC> Lutin: Do you remember any parts of the error?
<BenC> Lutin: or was it too fast?
<Lutin> BenC: something like modprobe abnormal termination, and then a stacktrace
<Mithrandir> Lutin: do you have a digital camera or a cellphone camera?
<Mithrandir> if so, taking a picture of the error would be useful.
<Lutin> Mithrandir: unfortunately no 
<BenC> Lutin: Most likely when it freezes, it's initramfs waiting for the rootfs. If you give it 3 minutes it will probably drop to a shell
<Lutin> BenC: it doesn't seem to freeze at a random point
<Lutin> it's whether when it loads the usb driver or when loading cx88-alsa. alaways one of those
<Lutin> always*
<BenC> Is that where it hangs or where it crashes?
<Lutin> where it hangs
<Lutin> can't see where it crashes :/
<mjg59> Lutin: Where it hangs is irrelevent. We need the stack trace
<BenC> Lutin: You can also try adding "break" to the kernel command line to stop in initramfs
<mjg59> Lutin: Try booting with break=top
<mjg59> Then do modprobe (whatever ata module)
<BenC> He's ata_piix
<BenC> ich7
<Lutin> ich8
<BenC> Oh wait, no, it's ahci in his config
<BenC> right, too many bug reports flying around my head right now
<Lutin> ok, so boot with break=top and modprobe what module ?
<mjg59> ahci
<mjg59> Or ata_piix, if ahci doens't bind
<Lutin> ok
<Lutin> brb
<AlinuxOS> BenC, lsmod in busybox mode is not available.
<AlinuxOS> BenC, http://alinuxos.no-ip.org/debug3.jpg
<AlinuxOS> that's my cat /proc/kmsg | grep ata output.
<Lutin> Ben, mjg59 : sorry, but my keyboard doesn't work with break=top
<Lutin> so, I can't provide any log / results
<AlinuxOS> BenC, you can see from screenshot that there is no lsmod.
<ivoks> BenC: bad day at work? :)
<mjg59> AlinuxOS: cat /proc/modules 
<AlinuxOS> mjg59, should I reboot again in busybox and remake a screenshot ?
<AlinuxOS> with that command ?
<AlinuxOS> BenC, mjg59 ping 
<BenC> AlinuxOS: Hold a sec, let me check this dmesg
<AlinuxOS> BenC, yes of course...sorry me :)
<BenC> AlinuxOS: I don't see any ata messages
<BenC> AlinuxOS: I suspect sata_nv isn't even loaded...can you "cat /proc/modules" and then try "modprobe sata_nv" ?
<AlinuxOS> BenC, when ? busybox or in current kernel?
<BenC> AlinuxOS: busybox
<AlinuxOS> BenC, ok :) so see you in some minutes :DDD
<AlinuxOS> today I have REBOOT day :)
<AlinuxOS> BenC, http://alinuxos.no-ip.org/catprocmodules .
<AlinuxOS> after modprobe sata_nv :
<AlinuxOS> http://alinuxos.no-ip.org/modprobesata_nv
<BenC> AlinuxOS: Second one gave "403 Forbidden"
<BenC> got it now
<AlinuxOS> http://alinuxos.no-ip.org/modprobesata_nv
<BenC> I just noticed something
<AlinuxOS> but afterwards there boot process dosn't continue.
<BenC> ohci_hcd, ehci_hcd and generic are all in "Loading" state
<AlinuxOS> libata version 2.20 loaded.
<BenC> I'm pretty sure that means they didn't complete module_init()
* Starting logfile irclogs/ubuntu-kernel.log
(AlinuxOS/#ubuntu-kernel) XXX ?
<BenC> so do "cat /proc/kmsg | grep ide"
<BenC> and again with "cat /proc/kmsg | grep usb"
<AlinuxOS> BenC, oops the problem is that I should go in some minutes. It's my last try :) I can continue tomorrow, cause tonight I'm not at home :(
<AlinuxOS> BenC, is ti problem for you ?
<BenC> AlinuxOS: No, I appreciate whatever time you can devote, sorry if this is taking up some of your day
<BenC> AlinuxOS: Feel free to leave whenever you need to
<AlinuxOS> BenC, It's not a problem for me to dedicate even some hours for Ubuntu and Community :) I'm Ubuntero man :D
<AlinuxOS> BenC, so if I can help, I'm happy with it.
<AlinuxOS> BenC, ooops I must leave right now. I'll recontact you with wheese command outputs... 
<BenC> Oooh, I bet I know what can fix this
<BenC> aww yeah
* BenC finds the bug
<mjg59> Mm?
<BenC> ide/pci/generic.c
<mjg59> Oh - is it still binding to jmicron?
<BenC> I've ifdef'd out some stuff in generic_pci_tbl[]  without also doing it in the generic_chipsets[]  table
<mjg59> Ah...
<BenC> yeah, but without a generic_chipsets[]  entry
<BenC> I'll remove the jmicron and sync the two tables
<BenC> this explains a shit load of bug reports
<BenC> Ok, so generic_chipsets table doesn't need to change, but the jmicron entries need to go
<BenC> AlinuxOS had sata_nv, but also a jmicron
<fabbione> BenC: i won't be able to test root on qlogic controllers.. sorry they have sent PCI-X only when i did ask for PCI/PCI-X compatible controllers
<fabbione> and i don't have x86 with pure PCI-X
<fabbione> or PCI-E for the matter
<BenC> Lutin did too
<fabbione> but i can tell you that PCI-E and X works great on sparc :)
<BenC> cool :)
<fabbione> i could actually force an install with root on sun using them
<fabbione> BenC: dm-multipath is the rock
<fabbione> i can see the SCSI traffic being multiplexed across 4 controllers to the SAN
<fabbione> one controller dies? who cares :)
<fabbione> it just gets removed from the balacing
<fabbione> balancing even
* fabbione ponders in root on multipath device spec
<BenC> fabbione: How much of this clustering hw can you provide for pkl, or will you still be needing it?
<fabbione> BenC: none. pkl only needs to do basic packaging and basic testing.
<fabbione> i will still do stress testing on it
<BenC> Ok
<pkl_> if lack of hw on my behalf does cause problems, I'm sure it can be dealt with if/when it happens...
<fabbione> pkl_: if it happens that you need hw, i will make sure you can have access to mine as temporary solution
<fabbione> it's enough you don't use my bw to download porn or take it from disks :P
<fabbione> pkl_: otherwise i am not jalous of the hw itself
<fabbione> and the machines are all scratch boxes (module the one you use to jump in the pvt lan)
<fabbione> BenC: in what package do we distribute the qlaxxx firmware in dapper?
<fabbione> (if we do)
<BenC> in the linux-image packages
<BenC> initramfs is supposed to include them in the initrd too
<fabbione> BenC: i have checked linux-image from -security but it doesn't have the qla*_fw.bin
<fabbione> on dapper the lack of fw is fatal to the driver
<fabbione> on feisty no.. it attempts to use the one from the controller rom
<fabbione> dpkg -c linux-image-2.6.15-28-386_2.6.15-28.51_i386.deb | grep firmware |grep ql | wc -l
<fabbione> 0
<\sh> wow...the latest feisty kernel is not crashing anymore when you remove an pcmcia card , great work :) thx guys :)
<BenC> On dapper we should be using the internal fw
<BenC> fabbione: On dapper the firmware is built-in to the driver
<BenC> \sh: Cool
<fabbione> BenC: it fails to init without the external one...
<fabbione> well i will check again once i have some more time
<BenC> at least I thought it did, could be wrong
<\sh> btw...is anyone working still with a modem connection? (analog)
<\sh> with the nozomi driver and this umts card, I have problems to redial..when the connection is not setup properly, another try to dial out (via wvdial) doesn't work..could be also a bug in wvdial
<fabbione> BenC: i will double check on sparc as soon as i can but hppa did fail miserably with dapper
<fabbione> BenC: well without the fw.. with the fw is good 
* fabbione &
<roland_d> hi, can anyone help me rebuild a kernel package for feisty?
<roland_d> I got the linux-source package, untarred the source, and tried "AUTOBUILD=1 fakeroot debian/rules binary-debs"
<roland_d> but that fails with "make: *** No rule to make target `binary-debs'.  Stop."
<roland_d> and indeed, "grep -r binary-debs debian/" doesn't find anything in the kernel source
<BenC> roland_d: those instructions require the source out of the git tree
<BenC> roland_d: or "apt-get source linux-source-2.6.20"
<BenC> which is different than the linux-source-2.6.20 package itself
<BenC> fabbione: ia64 should build for you now
<fabbione> BenC: cool thanks
<fabbione> if it works i will push a few patches for GFS2/DLM and we will declare it "enough" for feisty
<fabbione> anyway i am heading to bed
<roland_d> BenC: OK, thanks.  Should I do the apt-get source, or should I be using the linux-source package?
<fabbione> BenC: do you know if .20 can boot on hppa (with dapper build environment)?
<roland_d> BenC: I'm just trying to follow KernelCustomBuild from the wiki
* fabbione heads to sleep
* kylem waves to roland_d.
<BenC> fabbione: doubtful
<BenC> roland_d: You need to apt-get source it, or git-clone it
<BenC> fabbione: So far ia64 is building for me
#ubuntu-kernel 2007-03-23
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.20 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 329 Open, 0 Unconfirmed, 0 Unassigned
<elcasey> hey, what's the status on the JMicron fix? Mid-next week?
<BenC> will be uploaded Sat
<BenC> give 24-48 hours for turn around on builds and archive process
<BenC> I'd say by Monday for sure
<elcasey> oh nice
<elcasey> my current edgy install has just gotten so weird it's time to kill it, and I'd like to go with feisty now if it'll boot
<elcasey> it's supporting ralink wifi now, or still not worked out?
<BenC> should be working
<BenC> which chip?
<elcasey> final question - i know it'll support compiz "out of the box" with supported drivers...will those also run beryl?
<elcasey> rt61
<BenC> rt61 should work
<BenC> if you can run compiz, you should be able to run beryl
<elcasey> excellent!
<BenC> beryl can be a little more intensive on the gpu though
<elcasey> seems the latest kernel will fix basically every linux issue i was having
<BenC> so you may not be able to run it as well
<BenC> glad to hear it
<elcasey> well, i have a 7950GT, but I had serious driver issues in my latests install
<elcasey> i'm actually running beryl on my intel 915 right now, which runs great, surprisingly. I've never tried compiz, i just may check it out.
<elcasey> what version is monday's kernel going to be? 2.6.20-15?
<BenC> -13
<elcasey> guess I got ahead of myself :P
<elcasey> thanks very much, BenC
<BenC> np
<tritium> BenC: atheros support wasn't touched in your latest fix for 2.6.20-12.20, right?  I can't even load ath_pci.  I get "Unknown symbol ath_hal_" errors.
<tritium> I have an AR5212
<BenC> are you sure you didn't disable it somehow with restricted-manager?
<tritium> I'll double check, but I highly doubt that.
<tritium> I run it, and it simply states my hardware doesn't need any restricted drivers.
<tritium> And "sudo restricted-manager" returns "modinfo: could not find module ath_hal" (among others)
<BenC> sudo /etc/init.d/linux-restricted-modules-common start
<BenC> sudo depmod -a
<BenC> sudo modprobe ath_pci
<BenC> see if that does anything
<tritium> BenC: that did it.
<tritium> Thank you.
<BenC> np
<tritium> I should say the module now loads, but network-manager still doesn't work with it.
<tritium> Is wireless with atheros AR5212 known not to work with 2.6.20?
<BenC> tritium: -13 kernel upload has a new atheros driver, so probably wait for that
<tritium> BenC: great info.  Thanks.
<fabbione> ah cool
<fabbione> abi change
<fabbione> that's exactly what i was looking for :)
<fabbione> because also gfs2/dlm will change api ;)
<tritium> BenC: you already uploaded it?
<BenC> tritium: No, should be available by Monday
<tritium> Great.  Thanks!
<fabbione> BenC: can it wait at least your morning for upload? i want to finish to test these fixes
<BenC> fabbione: Not uploading till Saturday (post beta)
<fabbione> BenC: ok perfect
<fabbione> shouldn't take me more than kernel build time + userland local rebuild and a couple of reboots to test
<Nafallo> hi! is there any way I can stop the race where I have two controllers, one SCSI and one using libata, and can never know which disks are sdb and which are sdf?
<Nafallo> right now sdf and sdg are my RAID1 / :-P
<fabbione> Nafallo: no you can't. that's why we mount by UUID
<fabbione> and what kind of problem is that anyway?
<fabbione> RAID doesn't need to know what devices are involved anyway
<fabbione> not to build the array at least
<fabbione> it uses the md superblock information to assemble it
<fabbione> so it doesn't matter how the devices are named
<fabbione> BenC, kylem:
<fabbione> Checking module listings...
<fabbione> Modules have gone missing:
<fabbione> uvcvideo
<fabbione> Will not continue!
<fabbione> make: *** [build]  Error 1
<fabbione> this is latest git
<Nafallo> well, when I tried to restart newly upgraded feisty I got dropped into initramfs after it couldn't assemble /dev/md2 :-P
<fabbione> Nafallo: that's not a kernel issue anyway.. talk to iwj and check mdadm bug list
<Nafallo> so right now I've booted into one of the root-mirrors by plain luck :-P
<Nafallo> oki
<fabbione> the race is there rather than the kernel
<Nafallo> ah, right :-)
<moparisthebest> does anyone know anything about the TCP congestion control plugins?
<moparisthebest> for example, how they work, and/or how one would go about writing a new one?
<Nafallo> fabbione: wait a moment... are we supposed to mount RAID1 as UUID now aswell?
<fabbione> Nafallo: the filesystem on top of the raid.. yes.. if it has a uuid
<fabbione> but the problem is that mdadm is not assembling the raid
<fabbione> that's slightly different
<fabbione> a raid has also a raid UUID
<fabbione> that's not the same as the filesystem UUID on top
<fabbione> don't get confused because they are 2 different thigns
<Nafallo> yea, most likely cause it haven't loaded anything to get harddrives at that point :-)
<Nafallo> so what should I have for root= on the kernel cmdline?
<ivoks> BenC: good news: rmmoding ata_piix during installation fixes issue with older Intel IDE controlers...
<varka> hi
<fabbione> BenC: you were partially right about the qla firmware.. the problem is that there is no firmware for qla24xx
<fabbione> BenC: but the others seem to build from the kernel. tho i think it would be best to just update them 
<fabbione> or at least add the qla24xx
<fabbione> BenC: ok. i am all good with DLM and GFS2. i didn't push any update because one of them introduces a regression rather than helping 
<fabbione> BenC: so upload at will
<Nafallo> hi! does anyone know about a bug where /dev/sdb is created but not /dev/sdb? ? :-/
<Nafallo> ehrm
<Nafallo> -EWRONGCHAN
<Nafallo> hmm
<Nafallo> my 120GB PATA100 disks say they doesn't support smart anymore
<Nafallo> should I hate libata now? :-)
<mvo> hello! did the edgy->feisty kernel changes include a change in the device for cdroms? it looks like /dev/hdc (edgy) changed to /dev/scd0
<mvo> (feisty)
<Mithrandir> mvo: quite possibly.
<Nafallo> yes :-)
<Nafallo> for libata stuff it should have atleast
<mvo> so we need a upgrade strategy
<Nafallo> oh?
<Nafallo> /dev/cdrom isn't the default in fstab?
<mvo> on my test-install its /dev/hdc in /etc/fstab (fresh edgy install)
<Nafallo> ouch :-)
<mjg59> mvo: It should be /dev/cdrom
<mjg59> Are you sure you haven't changed that by hand?
<mvo> mjg59: yes. I did a fresh install for the upgrade testing
<mvo> (fresh edgy install that is)
<mjg59> Hm. Fun.
<mvo> I also have a "/dev/          /media/floppy0" line 
<bdmurray> my laptop has a sd/ms-pro/mmc/xd reader and when I insert an xD card in it the kernel doesn't report it
<bdmurray> How could I track that down or get some more useful information?
<mjg59> It's not supported
<bdmurray> well, that makes it easy.  Is that true for all devices like that?
<mjg59> The only xd readers we support are ones that connect via USB
<bdmurray> Oh, so the one in my desktop is connected via USB.  So if future bugs come in about on board xd media readers they should be rejected?
<mjg59> No, it's a valid bug
<mjg59> It's just not one that's going to be fixed in the near future
<bdmurray> Is there a "master" bug for those then?  One that all dupes should go to?
<Nafallo> hmm
* Nafallo goes to pastebin :-)
<Nafallo> http://paste.ubuntu-nl.org/11752/
<Nafallo> what does that mean? :-)
<mjg59> Nafallo: Context?
<Nafallo> ata7.01 (sde) failed in the RAID5-array :-/
<Nafallo> and that paste is from dmesg
<Nafallo> should I be worried? :-)
<mjg59> What kernel?
<mjg59> And does this always happen?
<Nafallo> latest feisty
<Nafallo> 2.6.20-12-server
<Nafallo> no idea. the disk is new to me. plugged it in yesterday :-)
<mjg59> See if the same happens with older kernels
<mjg59> Then file a bug
<Nafallo> I'm doing a cat /dev/zero > /dev/sde now and will try to add it to the array again. we'll see what happens :-)
<Nafallo> okey, thanks :-)
<Nafallo> mjg59: hehe. I get it numerous times while doing the lowlevel format... PIO0 _can't_ be a good sign ;-)
<Nafallo> mjg59: might aswell be broken hardware though. SMART seems not ported for libata yet.
<Nafallo> baah
<Nafallo> [25195.000000]  Buffer I/O error on device sde, logical block 423072
<Nafallo> [25195.010000]  lost page write due to I/O error on sde
<Nafallo> broken hardware, right?
<mjg59> Sounds like it
<mjg59> But try it on a different port
<Nafallo> the other ports have drives connected, but sure, I could swap some of them :-)
<Nafallo> ehrm, launchpad doesn't have older kernels?
<mjg59> Correct
<Nafallo> how irritating :-P
<Nafallo> then I can't test older kernels
<Mithrandir> it does, it's just well-hidden
<Mithrandir> find the previous version, find the build for the architecture you're interested in, and download the "resulting binaries"
<Nafallo> ah, kewl :-)
<Nafallo> thanks Mithrandir :-)
#ubuntu-kernel 2007-03-24
<mjg59> BenC: The sd_stop_on_shutdown patch doesn't actually do anything unless the default is changed
<orangey> hey all!
<orangey> quick question. When I type 'mount' in 2.6.20-12.20, does it show /dev/by-uuid?
<orangey> mine shows
<orangey> /dev/hda1 on / type ext3
<BenC> mjg59: right, I don't want it enabled by default
<mjg59> Ok
<orangey> Hmm.. Alright. after some experimentation, I have concluded that I need ide_disk to work for me to successfully suspend / restore.
<orangey> with ata_piix being blacklisted.
<mjg59> What hardware?
<orangey> However, how can I force ide_disk to get me a /dev/hda1?
<orangey> mjg59: ICH6; HP NC4200 laptop.
<mjg59> Right
<mjg59> So it's the lack of ACPI support
<orangey> mjg59: I think it's bug 78779
<orangey> mjg59: not exactly.
<mjg59> Yes, exactly
<orangey> This is a common HP / IDE problem.
<mjg59> It's the lack of ACPI support for PATA devices
<orangey> it seems that the drive is not re-initialized by the ATA driver
<mjg59> Because of the lack of ACPI support
<orangey> ok.
<mjg59> (I wrote this code for drivers/ide)
<orangey> regardless, in 2.6.20-11 with some patches, it works.
<orangey> but with -12, it no longer works.
<mjg59> Yeah. I'll get to it.
<orangey> and the only similarity I can figure is that my ide_disk is working in -11, but doesn't seem to do anything in -12..
<mjg59> I've got a 6220 which has the same issue
<orangey> mjg59: : )
<mjg59> Using the drivers/ide code isn't a fix
<orangey> mjg59: All I'm saying is that I am in no way able to get -12 to work, where I was able to get -11.
<orangey> mjg59: so, bottom line, I should stop pursuing this bug and use my custom kernel until there's a fix?
<mjg59> Probably the best bet
<mjg59> With luck I'll get to it this week
<orangey> mjg59: awesome. Alright, thank you.
<orangey> In that case, the next thing on my todo list is sleep : )
<orangey> nightie!
<fabbione> morning
<AlinuxOS> hello BenC 
<AlinuxOS> Here it is my "cat /proc/kmsg | grep ide"  commands output: http://alinuxos.no-ip.org/grepide.jpg
<raffytaffy> is this english speaking chan?
<raffytaffy> i was gonna ask if anyone here has used ketchup to auto patch ?
<Whoopie> BenC: Hi, why did you add vbox kernel modules 1.3.2 and not the latest 1.3.8? Just curious.
<raffytaffy> does nobody talk in here
<BenC> Whoopie: probably because I grabbed the wrong tarball...someone pointed me to 1.3.2
<Whoopie> BenC: ok
<Whoopie> BenC: regarding the linux-phc patch, I use it to fix the high pitch noise on battery with my thinkpad. I just undervolt it a little bit and it works fine.
<BenC> Whoopie: I only included the cpu tables for speedstep-centrino to do cpufreq things, I didn't include the voltage twiddling because of things I read from lkml
<BenC> Whoopie: it opens the door for people to actually break their hw permanently, and I can't take responsibility for that
<thotz> fabbione: https://launchpad.net/ubuntu/+bug/7091 : is this fixed in edgy/ feisty? You said "I might for dapper+1."
<Whoopie> BenC: the question is if you're really responsible for what users do with the provided kernel.
<BenC> Whoopie: absolutely
<BenC> Whoopie: if you give someone a loaded gun that is known to backfire and kill the person shooting it, you are responsible for the person you gave it to killing themselves
<raffytaffy> i had to resort to turning ipv6 off in etc list
<Whoopie> BenC: difficult topic, I see.
<Whoopie> BenC: another question: would it be possible to include the hdaps_protect patch to support head parking on thinkpads? http://whoopie.gmxhome.de/linux/patches/2.6.20/03-disk-protect-for-2.6.20.patch
<raffytaffy> has anyone here used ketchup to patch kernels?
<fabbione> thotz: leave that bug alone. There are reasons why it's not closed
<bluffer_> BenC i some how clicking randomly on all those network related appliances got network to be detected (i can google from this box in vpc ) would you like to tell me why it is working now ? 
<BenC> bluffer_: refresh my memory about the issue?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-13.21 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 352 Open, 6 Unconfirmed, 6 Unassigned
#ubuntu-kernel 2007-03-25
<glick> hi
<glick> hey can anyone recommend some good reading to start cutting my teeth on kernel development?
<crimsun> kernelnewbies.org should still be around.
<glick> so linux device drivers and understanding the linux kernel is probably the two most important books to read
<cyclopse> hi i use kubuntu 6.06 LTS can somebody help me? 
<cyclopse> where r the kernel headers located
<cyclopse> ?
<crimsun> linux-headers-$(uname -r)
<crimsun> please use 
<crimsun> #ubuntu for general support questions
<cyclopse> k
<raffytaffy> i relized i can change the xchat.conf entery and i fixed my menu issue hehe
<bluffer_> BenC i was bugging you some days ago about network card not being detected by ubuntu dapper on vpc 
<bluffer_> and i changed the eth0 config via system->admin->network-tools to  DHCP after this i can surf the net but smb doesnt show my windows Domain pcs :(
<bluffer_> with DHCP ican wget ,syanptic and sudo aptget install some package from net works etc etc only \\pc14 \\pc12 etc are not visible :( neitehr does smbtree shows any resu
<doko> how do I build just one flavour without building the others?
<fabbione> doko: check debian/rules, you can specify flavour or FLAVOUR.. can't remember offhands
<fabbione> doko: or move away the configs you don't want from debian/config/$arch
<fabbione> and use binary-debs target
<Mithrandir> doko: https://wiki.ubuntu.com/KernelMaintenance#head-898bc4657c398ebb0d3d70597997cb9956d9b2c9
<doko> ok, thanks. now I have to find out why an addition to debian/config/powerpc/sp3 is unseen ...
<doko> Mithrandir: did look at it, but that didn't answer my question
<Mithrandir> doko: uh, then you meant to ask another question than you did.
<raffytaffy> has paravirtualization been added rescently?
<fabbione> doko: be careful to what you add to the configs.. i suggest you do this...
<fabbione> export LC_ALL=C
<fabbione> cd debian/config/$arch
<fabbione> remove the option you want to change in all config.*
<doko> fabbione: just an additional driver
<fabbione> fakeroot make -f debian/rules updateconfigs
<fabbione> it will prompt you for the question
<doko> ahh, ok
<fabbione> if it doesn't it means something else is required to enable it
<fabbione> it won't ask for questions already answered
<TheMuso> c
<Whoopie> mjg59: hi, hdaps inverting for xy-, x- or y-axis is missing in feisty kernel. and also tp_smapi. both are in edgy. Shall I open a bugreport?
<mjg59> Whoopie: Please do, yes
<Nafallo> mjg59: my disk works again after a reboot. I have no idea what happened with the bugger :-)
<Whoopie> mjg59: already reported, didn't see: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/33950
<Nafallo> https://beta.launchpad.net/ubuntu/+bug/95921
<Nafallo> where is the problem? :-)
<mjg59> Possibly in the cable detection code
<Nafallo> doesn't it look like it's actually using UDMA100 and hdparm is just busted with the new-world-order? :-)
<Nafallo> dooh. missed the last two lines :-P
<Nafallo> nm me today ;-)
<Nafallo> hehe
<Nafallo> baah
* Nafallo gets the new kernel :-P
<fabbione> BenC: #96058 <- suckage
<PhinnFort> what is the lowlatency kernel?
<JoseStefan> BenC, here?
<PhinnFort> is it realtime-ish for sound editing and the like, or soft realtime, for desktops?
<crimsun> PhinnFort: identical to -generic save preempt is enabled and hz is 1000
<PhinnFort> ah, ok
<PhinnFort> no preempt big kernel lock, and the like?
<crimsun> PhinnFort: it's nowhere close to realtime, but yes, it's more suitable for audio and video work. The use case is UbuntuStudio.
<PhinnFort> plain preempt?
<JoseStefan> i think bug 84964 is still alive :(
<crimsun> PhinnFort: the former. Full preemption within the scope of 2.6.20.
<PhinnFort> how many of con-kolivas patches does .20 include?
<JoseStefan> How can i provide boot text for a daily-live, without the use of a digital camera (or a lot of typing) ?
<PhinnFort> *do you know...
<benh> heya folks !
<crimsun> PhinnFort: none.
<mjg59> Hi Ben
<benh> is the feisty kernel based on 2.6.20 "bare" or 2.6.20.2 ?
<crimsun> PhinnFort: (unless they were merged into 2.6.20)
<crimsun> benh: .3, at least
<benh> ah ok
<PhinnFort> crimsun: that was what i was trying to ask;)
<benh> so the ilog2 bug has been properly reverted...
<benh> good
<benh> Revert "[PATCH]  LOG2: Alter get_order() so that it can make use of ilog2() on a constant"
<PhinnFort> i know his scheduler is scheduled to be included soon
<PhinnFort> though
<benh> without that, random mem corruption on ppc ... no fun :-) should be all right in .3
<benh> another questing while there...
<benh> why 2 separate CDs for PS3 vs. other powerpc ?
<crimsun> a benc question (I don't know offhand, sorry)
<mjg59> benh: http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commit;h=25239266d554a0442eb676044f03de9d43364c42
<JoseStefan> I can't boot feisty, because of jmicron bug, Is there anyway to dump the boot text on to a usbkey, while i'm at the "busy box"
<mjg59> So yeah, it's certainly been reverted
<mjg59> JoseStefan: Wait for the next daily
<benh> I suppose I really need to get a 0.1 of my ps3 gfx bootloader out
<benh> so you guys can get some nice icons in your config file to show up on it :-)
<crimsun> mjg59: let me know if sound works on your mac* now
<mjg59> crimsun: Oh, good question
<crimsun> (at your convenience, of course)
<benh> there should be no need for separate CDs... unless something is fuckd up with kboot
<JoseStefan> mjg59, i understand this daily has the kernel that is supposed to fix the problem, so maybe if i could provide more info, it would be useful
* benh will install & test ubuntu/ps3 today or tomorrow
<crimsun> JoseStefan: err, -13 just rolled into the archive today, so I'm pretty sure the current daily _doesn't_ have it
<PhinnFort> woohoo, ck has it's own wiki now: http://ck.wikia.com/wiki/Main_Page
<JoseStefan> crimsun, anyway of knowing of what kernel is on the disk, by looking at the disk tree, or opening files on the CD ?
* benh 's laptop update to feisty almost fully d/l ... cross fingers
<crimsun> JoseStefan: uname -r  in a shell is sufficient
<BenC> benh: No room for otheros.bld and ps3 kernel+initrd on normal ppc CD
<JoseStefan> crimsun, if it's running, i mean without booting it (live-cd)
<benh> BenC: wow, it's -that- cramped ?
<benh> BenC: what kernel do you use ? once it's finally properly merged, it should be a single image for all ppc64 including ps3, but we aren't quite there yet
<crimsun> JoseStefan: http://cdimage.ubuntu.com/daily/current/source/feisty-src-1.list
<crimsun> JoseStefan: in fact, according to that, the current daily has it
<JoseStefan> crimsun, does this apply to daily-live as well?
<crimsun> JoseStefan: no
<mjg59> crimsun: Ok, that's got it, but I needed to manually unmute the "speaker" channel
<mjg59> (Which wasn't displayed by default)
<crimsun> note that http://cdimage.ubuntu.com/daily-live/current/feisty-desktop-i386.list still lists 12.20
<crimsun> ^ JoseStefan 
<crimsun> mjg59: ok, thanks
<JoseStefan> crimsun, thanks was looking for a /source subdir :o
<mjg59> crimsun: That is, I have separate speaker and headphone options, and no master control
<crimsun> mjg59: is your /proc/asound/card0/codec* in a bug report? [I think it is, but $toomanybugs] 
<mjg59> crimsun: Eh, not sure
<JoseStefan> crimsun, ok, now i've learned how to find out what kernel is on a daily-live without going for the surprise element :D
<crimsun> JoseStefan: if you're really itching for feisty, just use the current daily
<mjg59> Hm. -13 seems to have lost the ability to reboot my mbp.
<benh> hrm... they powerpc feisty CDs aren't in the main location... not mirrored :-(
<PhinnFort> is there any reason not to use noatime in fstab on a normal desktop system?
<JoseStefan> crimsun, i'm trying to help fix this jmicron issue, since it's been there for a while ;)
<crimsun> benh: http://cdimage.ubuntu.com/ports/releases/7.04/beta/
<crimsun> (or http://cdimage.ubuntu.com/ports/daily/current/ if you want more current)
<benh> crimsun: yeah, found that, but not mirrored herre... thanks anyway
<benh> (.au is slow when not mirrored)
<mjg59> crimsun: Any idea why gnome-volume-applet claims to be altering PCM, but is in fact altering front?
<crimsun> benh: http://se.archive.ubuntu.com/mirror/cdimage.ubuntu.com/ports/releases/7.04/beta/
<benh> crimsun: not on au.archive.
<crimsun> ah
<benh> well. ... let me dbl check
<crimsun> mjg59: err, no idea about g-v-a
<benh> yeah, not there
<crimsun> I should stop using pA momentarily to check that. Will see what I can whip up tonight.
<benh> same with planetmirror and optus
<benh> mirrors don't get "ports"
<JoseStefan> ok, thanks for everything, i'll wait until next daily
#ubuntu-kernel 2008-03-17
<kraut> moin
<alex_joni> moin
<MiHu> Hi. Anybody from the kernel team already awake?
<MiHu> 8-)
<asac> hmm ... iwl3945 driver somehow claims to not support scan_capa. is that correct or did we miss a patch for that driver somewhere?
<asac> (well from what i can tell it supports scan_capa)
<MiHu>  A few days ago I reported bug #201197. On 2007-05-17, Ben Collins removed my driver called "MXB" from the list of modules to be build. I think there was a misunderstanding which of my drivers supports which kind of hardware. Is anybody willing to discuss this issue with me now?
<ubotu> Launchpad bug 201197 in linux-ubuntu-modules-2.6.22 "Driver for "Multimedia eXtension Board" (MXB) missing" [Undecided,New] https://launchpad.net/bugs/201197
<BenC> Good morning ppl
<MiHu> BenC == Ben Collins?
<BenC> yes
<MiHu> Great. Hi. Can you please have a look at bug #201197 I filed a few days ago?
<ubotu> Launchpad bug 201197 in linux-ubuntu-modules-2.6.22 "Driver for "Multimedia eXtension Board" (MXB) missing" [Undecided,New] https://launchpad.net/bugs/201197
<BenC> MiHu: reading...
<BenC> MiHu: Ok, sounds reasonable, I'll look into getting it reverted
<MiHu> BenC, One problem is that some of the saa7146 devices don't have proper subsystem/subvendor ids. So I think they need to be blacklisted against autoloading first. Otherwise it can happen that one of the drivers (for example hexium_orion) captures somebody elses TV card, depending which modules gets loaded first. I think the only sane way is to let the user load the appropriate moduel manually.
<BenC> MiHu: since you seem to know a lot about this, can you add proper suggestions to the bug report?
<BenC> I'd be guessing
<MiHu> BenC: No problem, since I'm the author of most of these drivers I should know. 8-) It's just that I did not receive any feedback so far, so I did not know if somebody was looking into this.
<MiHu> benc: Is module blacklisting done via /etc/modprobe.d/blacklist? If so, do you know the people from the module-init-tools package?
<alex_joni> where can I find instructions for building a lum package for a custom kernel?
<MiHu> benc: I did some experiments. I installed the linux sources, enabled the MXB in the .config, build mxb.ko, copied it to the right place, depmod -a, then reboot. The card is recognised and everything works as expected. 
<MiHu> BenC: I'll add this to the bug report. It would be great if that card would be supported with the next update again.
<MiHu> BenC: Perhaps you can assign this bug report to yourself or somebody else. Do you need a patch for the .config? Please tell me if anything is missing.
<BenC> MiHu: great, thanks for testing...just include the correct config option for us to change
<MiHu> BenC: I updated the description for bug 201197. Is there already a new release planned for the kernel package?
<ubotu> Launchpad bug 201197 in linux-ubuntu-modules-2.6.22 "Driver for "Multimedia eXtension Board" (MXB) missing" [Undecided,New] https://launchpad.net/bugs/201197
<BenC> MiHu: Not planned, but we'll have to see how things go after the beta
<MiHu> BenC: Ok. This is not critical, only a handful of users are using this card and they are all lazy updaters. Just like me...
<MiHu> BenC: I played around with launchpad, hopefully the bug is now assigned to you.
<asac> hmm ... any idea if rtg will be here today?
<alex_joni> where could I find some instructions how to build a lum package for a modified kernel?
#ubuntu-kernel 2008-03-18
<alex_joni> I notice that the headers deb created for a x86 32-bit kernel, has a bustem symlink in it: include/asm points to asm-i386
<alex_joni> any ideas what I should check?
<kraut> moin
<abogani> chuck_: Seem to me that this commit (in mainline)  87d034f3139b5f0d93df2ba58f37d6f2c2c7eeb6  should be added in Hardy.
<pwnguin> so is the kernel team the best place to ask about initramfs-tools scripts?
<abogani> It is possible but unlikely.
<pwnguin> what on earth is the resume script waiting five seconds for?
<abogani> I suggest you to ask on #ubuntu-devel.
<pwnguin> ok then
<pwnguin> is the ML a better place to watch for kernel work? this place always seems so dead
<tonfa> hi, I'm running gutsy and while debugging something with vanilla .25-rc6 I get dbus errors when logging in in gdm
<tonfa> is this some known issue ?
<tonfa> (the error is something like "could not connect to /tmp/dbusXXXX")
<abogani> tonfa: Yes
<tonfa> do you have some pointer ? (is it in launchpad ?)
<abogani> Bug #146946
<ubotu> Launchpad bug 146946 in gnome-control-center "[gutsy] Gnome settings daemon randomly does not work" [Medium,Incomplete] https://launchpad.net/bugs/146946
<tonfa> ok, thanks
<tonfa> I'll try restarting next time I boot this kernel
<tonfa> that's weird that it (almost) always happens with .25-rc6 and never with gutsy's kernel
<pwnguin> timing issues are like that
<tonfa> yup, I'm reading the bug report
<tonfa> thanks a lot for the pointer :)
<BenC> tjaalton: any idea why lrm is not loading nvidia-legacy for me at boot, when I should be (and have always been) using nvidia-new
<BenC> in fact, I have nvidia-glx-new package installed
<Ng> would it be reasonable to target bug 197929 for beta?
<ubotu> Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Medium,Triaged] https://launchpad.net/bugs/197929
<Ng> (also affects X300)
<abogani> zul: Seem to me that this commit (in mainline)  87d034f3139b5f0d93df2ba58f37d6f2c2c7eeb6 about Xen should be added in Hardy.
<zul> abogani: gitweb url? 
<BenC> Ng: we can give it a try
<abogani> zul: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=34f10fc9886450c2e8a336f7022805c4a73e10f1
<zul> abogani: thanks
<abogani> zul: Hope this helps.
<zul> abogani: we dont use paravirt xen for hardy :)
<zul> abogani: for ibex probably :)
<abogani> zul: Opsssss :-)
<abogani> zul: What is virt tech supported by Ubuntu Server Team? KVM?
<zul> kvm
<Ng> BenC: I'm not sure what the patch was supposed to do, but it's definitely breaking backlight on my laptop, I booted -10 and the backlight works
<BenC> Ng: hmm, ok
<BenC> tjaalton: oops, I mean it's not loading nvidia-new for me, it's loading nvidia-legacy instead
<amitk> BenC: are we still uploading for Beta?
<mjg59> #147087 is kind of silly
<BenC> bug #147087
 * BenC kicks ubotu
<BenC> bug #147087
<ubotu> Launchpad bug 147087 in linux "No sound on Aluminium iMac with PCI ID 8086:284b" [Medium,Confirmed] https://launchpad.net/bugs/147087
<johanbr> Is there any chance the one-line patch from bug #39414 could be applied? Without this patch, many people won't be able to use bluetooth headsets.
<ubotu> Launchpad bug 39414 in linux-source-2.6.15 "syslog is flooded with messages after connecting bluetooth usb dongle" [High,Fix released] https://launchpad.net/bugs/39414
<abogani> UBUNTU: custom/rt: Disable toshiba_acpi, since it isn't compatible :-?
<BenC> cking, amitk: ping
<cking> hi
<amitk> ping
<BenC> Ok, welcome to the kernel team IRC meeting
<BenC> For those that don't know, meeting information is available here: https://wiki.ubuntu.com/KernelTeam/Meeting
<BenC> Since we are closing in on release, and are under kernel freeze, we are going to keep this short so everyone can get back to work
<BenC> cking: Can you start off with your status and current focus
<cking> Yep.  Been looking a various kernel bugs, ranging from the trivial patch to the more perplexing.
<cking> For example, usplash messing up vgacon driver colors and causing blanking not to work for all colors in the palette. 
<BenC> cking: ok...you said earlier that you were also moving on to looking after the boot loader for intrepid?
<cking> Yep. I'm getting familiar with the isolinux, grub and so forth.
<BenC> Good, be glad to see what we can do with grub2 (if anything) for intrepid
<BenC> cking: thanks
<BenC> amitk: on to you...
<cking> OK. 
<amitk> been testing out some hardware for the ubuntu Mobile project
<amitk> integrating drivers for them too
<amitk> I hope to push out a preliminary Intrepid tree with all the sauce patches next week
<BenC> amitk: for ume or kernel in general?
<BenC> the intrepid tree that is
<amitk> kernel in general - we will move the lpia out of the normal kernel tree though
<amitk> as agreed at the kernel sprint
<BenC> amitk: excellent...are you working on that tree in tandem, or will that come later?
<BenC> the lpia tree
<amitk> BenC: tandem. The lpia tree will follow the main kernel tree closely, only have different checkpoints for uploading than the kernel tree.
<amitk> s/checkpoints/schedule
<BenC> amitk: Are you removing most of the (unneeded) sauce patches for lpia? e.g. I wouldn't think it would need DSDT-from-initramfs loading
<amitk> BenC: true, those don't need to be in the lpia tree.
<BenC> amitk: ok, great...anything else of note?
<amitk> that's it from me.. thanks
<BenC> amitk: thanks
<jay> amitk: How will this affect my integration of moblin patches to the hardy-ume?
<amitk> jay: it won't. Hardy tree will continue to be maintained as-is, with you and I doing special uploads to the mobile PPA
<jay> amitk:ok
<amitk> Intrepid's new kernel is not yet chalked out in the current Ubuntu Mobile plans
<BenC> Good thing about the planned separation is that moblin could potentially use an entirely different kernel version in intrepid than we are for mainline
<BenC> IOW, it could use 2.6.25 instead of our planned 2.6.26, so it can remain at a stable ABI for much longer during the development cycle
<BenC> but that's a discussion for UDS
<amitk> BenC: very true. This will be discussed at UDS
<BenC> Ok, moving on to bugs for hardy
<BenC> The kernel team has discussed some basic guidelines for patches/fixes going into the kernel between now and release...
<BenC> For starters, the current kernel in the archive is what is planned for beta, barring any major regressions showing up (which I see as unlikely)
<mjg59> BenC: Where?
<BenC> mjg59: where what?
<mjg59> Where was it discussed?
<BenC> mjg59: on our phone call just before this meeting...and I'm about to outline those guidelines now
<mjg59> Phone call?
<BenC> Yes, we have a conference call once a week just before the IRC meeting
<BenC> mostly to discuss NDA issues that can't be discussed here
<mjg59> Uh.
<mjg59> But also to discuss bug policies?
<BenC> These policies aren't any different than what we've had in past releases
<BenC> just noting them now to make sure everyone understands them
<mjg59> If you're defining the kernel team as the set of people employed by Canonical, I think you're missing the point
<BenC> Just the bar for a patch getting in now after kernel freeze is very high...and that needs to be pointed out
<BenC> mjg59: I misspoke...we didn't "define" these policies on the call, we simply reviewed the ones we already have in place
<BenC> mjg59: we discussed how they were different than the normal policies during the heavy development cycle
<BenC> IOW, we are in kernel freeze, and only have one more planned upload
<mjg59> No, the kernel team didn't. The subset of the kernel team involved in this phone call did.
<BenC> I don't see it as a problem to let my employees know what these policies are, especially considering most of them are new
<BenC> I also don't think I have to do it in public
<BenC> especially since the same policies will be discussed in public
<BenC> and especially since they haven't changed, they are just being reiterated at a time when they are pertinent
<mjg59> No, that's not the point I'm mkaing
<BenC> I don't really see a valid point, to be honest
<mjg59> You're saying that the kernel team discussed this. That's only true if the kernel team is the set of people who work for Canonical.
<BenC> Excuse me then, the Canonical Kernel Team discussed this
<mjg59> Which was not my understanding of how development worked.
<BenC> and now I am discussed it with the Ubuntu Kernel Team
<BenC> *discussing
<mjg59> Ok
<BenC> mjg59: is that clarification better?
<mjg59> Yes
<BenC> Good, so let's move on...
<BenC> The basic points of our current bug policy is that we will mainly focus on bugs that prevent users from booting/installing Ubuntu
<BenC> Bugs that fall into this category are mainly graphics and storage related, but generally covers networking as well
<BenC> Other bugs will either be deferred to 8.04.1 point release, or for 8.10, depending on the bug
<BenC> Exceptions to this can occur, but are not likely...basis for exceptions will be the estimated number of people affected by the bug, and the complexity of the fix (IOW, the trivial fixes with least chances of regression may be considered)
<BenC> We only have one more _planned_ kernel upload, as per the kernel release schedule (linked to a google cal from KernelTeam wiki)
<BenC> And just for clarification, these policies, and the kernel release schedule itself were discussed at prior UDS's with community members
<BenC> Are there any questions concerning this policy?
<abogani> No.
<BenC> Great...so now I'll just see if anyone has other items they would like discussed at this point...
<BenC> No takers? :)
<BenC> Ok, thanks everyone
<BenC> Meeting adjourned
<amitk> thanks
<cking> ta
<alex_joni> BenC: can I bug you for a couple of minutes? or should I rather wait till things settle down after beta?
<BenC> alex_joni: depends on the nature of your bugging :)
<alex_joni> asking for some pointers building a custom-flavoured kernel (along with headers, lum, lrm), and some other pointers on tracking a possible bug in make-kpkg
<BenC> alex_joni: re: custom kernels/lum/lrm: Check wiki.ubuntu.com...we don't condone it though
<BenC> alex_joni: re: kernel-package (make-kpkg), you're on your own, we don't use it or support it :)
<BenC> alex_joni: best bet is to talk to the maintainer of that package
<alex_joni> BenC: I started looking at the debian/rules way of building things
<alex_joni> and I think the problem persists
<BenC> alex_joni: that's preferred
<alex_joni> basicly the generated headers deb contains a broken asm link (points to asm-i386, not asm-x86)
<alex_joni> but it might be because of a bad incantation to debian/rules 
<alex_joni> re: wiki.ubuntu.com, I understand.. already read most of the relevant thigngs, but it's not quite as accurate as I hoped
<alex_joni> re: custom flavour: can't help it, we're using ubuntu as a base for machine control, so we need an ADEOS/IPIPE patch in the kernel
<abogani> alex_joni: Can't you use -rt for that?
<alex_joni> abogani: not at the moment
<alex_joni> -rt needs to get way better for that
<alex_joni> atm we're using 5-10 usec interrupts, -rt is a couple magnitudes worse
<alex_joni> -rt is fine for servo controlling motors with custom hardware, but not for the cheap parport control
<alex_joni> abogani: however -rt is getting way better, so I hope one day we can fully switch over
<zul> .26 for ibex?
<_stijn_> hey
<jepler> I want to build and distribute a custom kernel flavor (rtai) and be sure that I fulfill my GPL duties to distribute complete, corresponding source code.  The page https://help.ubuntu.com/community/Kernel/Compile didn't answer my questions about how to build a linux-source package or a debian source package.  What method should I use?
<johanbr> Is there any chance the one-line patch from bug #39414 could be applied? Without this patch, many people won't be able to use bluetooth headsets.
<ubotu> Launchpad bug 39414 in linux-source-2.6.15 "syslog is flooded with messages after connecting bluetooth usb dongle" [High,Fix released] https://launchpad.net/bugs/39414
<johanbr> The patch disables eSCO, but that's a relatively minor loss compared to not being able to use your headset at all.
<tjaalton> BenC__: right, I think there's a bug report about it
<BenC__> tjaalton: are you working on it? Seems important for beta
<BenC__> brb
#ubuntu-kernel 2008-03-19
<tjaalton> BenC: not at the moment, since it  doesn't seem to be a widespread problem. maybe the bug is in jockey if it installed -legacy for you
<shenki> BenC: are you able to take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/200057
<Lunks> Where should I go to kernel .config support?
<Lunks> As it's obviously not here. :>
<kraut> moin
<pbne04> hey, im running ubuntu with a 2.6.17 kernel and I need kernel version 2.6.11 as secondary boot..but how do I do this? I tried following guides on how to compile kernels but I always end up with errors
<Lunks> Where should I go to kernel .config support?
<Lunks> As it's obviously not here. :>
<amitk> Lunks: --> #ubuntu or #ubuntu+1
<Lunks> amitk: ah, too bad.
* abogani changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-12.22 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 25, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<abogani> dkms sounds very interesting...
#ubuntu-kernel 2008-03-20
<kraut> moin
<Jeeves_> Hello all
<Jeeves_> Any here who can enlighten me about Hardy, the tg3 driver and a Sunfire T1000 (sparc)?
<BenC> Good morning people
<zul> hey BenC 
<alex_joni> hello :)
<alex_joni> is there a git tree for lrm ?
<BenC> alex_joni: No
<alex_joni> BenC: ok, thanks. any pointers how it's handled?
<BenC> alex_joni: Like normal packages
<BenC> apt-get source ...
<alex_joni> just apt-get source, update locally, repush ?
<BenC> Yeah
<alex_joni> yeah, ok.. thanks
<alex_joni> BenC: I managed building kernel packages the "ubuntu" way (using apt-get source and debian/rules)
<alex_joni> BenC: how do I create a new source package with all my changes?
<alex_joni> I'm surely overlooking something, but can't find any info in the wiki or the source itself..
<BenC> dpkg-buildpackage -rfakeroot -S
<BenC> alex_joni: what's the new source package for?
<alex_joni> people that want to replicate my work mainly (so GPL compliance)
<jepler> BenC: the kernel packages alex_joni and I are working on have the "adeos ipipe" patch added.  Our application uses rtai for realtime control.
<BenC> jepler: sounds interesting
<jepler> the infrastructure to help us make custom kernels seems to be improving with each ubuntu release (we've done 5.10, 6.06, and want to jump to 7.04 next), so thanks to all of you for that
<jepler> er, I mean 8.04  of course
<alex_joni> BenC: otoh, we understand this is an infrastructure that maybe a handfull of people use, so having in detail docs is not feasible.. right?
<BenC> alex_joni: the docs are pretty complete, but it does assume basic knowledge of debian packaging and policies (which is documented elsewhere)
<BenC> alex_joni: and it is also geared toward our maint of the package, as opposed to others reusing it for arbitrary things (which we can't easily document)
<jepler> alex_joni: and after all, https://help.ubuntu.com/community/Kernel/Compile is a page we have no excuse for not improving
 * alex_joni gets shut up :)
<BenC> :)
<alex_joni> BenC: were you referring to other docs besides what can be found online (help.ubuntu, wiki.ubuntu, etc) and in /usr/share/doc for the various components?
<BenC> alex_joni: the main document that we support is the kernel maint document on wiki.ubuntu.com
<BenC> all others (for custom compiles) are mainly community created/supported pages
<BenC> The community ones may not always do the right thing, but I think they come close
<BenC> alex_joni: I created the original custom compile wiki page, but it has been modified heavily since then
<alex_joni> BenC: ok, thanks.. I'll read them again later
<BenC> alex_joni: I would strongly suggest, for your purposes, that you create your kernel as a custom flavour (instead of just a modified -generic), since it will alleviate any clashes...not sure if you are already doing that, but it's worth noting
<alex_joni> yeah, that's what we ended up doing
<BenC> excellent
<alex_joni> added another custom flavour, and built packages accordingly
<alex_joni> had a bit of a struggle with lum, but I think jepler managed to convince it to work
<jepler> I haven't *tested* anything from lum or lrm yet
<jepler> but they did build
<BenC> generally if they build, they will work
<amitk_> jepler: alex_joni : May I take this opportunity to pimp the KernelMaintenanceStarter page from https://wiki.ubuntu.com/KernelTeam/KnowledgeBase?action=show
<amitk_> it is meant as a quick start guide for newer members of the kernel team (they wrote it!) to wet their feet
<alex_joni> amitk_: thanks for the link
<erle-> hi, the hardy kernel won't boot on my machine
<jepler> what is a good version number scheme to use when building our rtai custom flavour?  I chose 2.6.24-12.22linuxcnc1 somewhat arbitrarily (linuxcnc.org is the homepage of our project).  we'll only distrbute linux-image-rtai and linux-headers-rtai from it, so binary package conflicts with official kernels are not expected..
<cradek> hi folks.  is there anything else I can do to help with this recent regression in the framebuffer drivers?  I filed this bug report:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/204319
<ubotu> Launchpad bug 204319 in linux "radeonfb regression: disappearing fonts upon VT switch" [Undecided,New] 
<cradek> I have since figured out that it probably affects more than radeonfb; I added a comment stating that.
<blueyed> bug 188226
<ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,In progress] https://launchpad.net/bugs/188226
#ubuntu-kernel 2008-03-21
<pwnguin> From Powertop: 42.5% (258.6)      <kernel IPI> : Rescheduling interrupts 
<pwnguin> that seems like a lot
<abogani> Good Morning!
<stgraber> hi guys, I got a new lappy and my fan start running a bit too early from my point of view, so I tried to modify the trip_points (it's an ACPI controled fan) with this command but it doesn't seem to work :
<stgraber> root@castiana:/proc/acpi/thermal_zone/TZ0# echo 256:0:100:85:75:65:55:35 > trip_points 
<stgraber> bash: echo: write error: Input/output error
<stgraber> that's on hardy 2.6.24-12-generic and amd64, according to the various docs I read this command should work ...
<stgraber> any idea ?
<erle-> hi
<erle-> where does ubuntu store information about installed kernels?
<erle-> update-initramfs wants to update the ramfs for kernels which do not exist
<erle-> and fails in that task of course
<erle-> but because of that i can not run apt
<maks_> ls /var/lib/initramfs/
<cradek> update-initramfs is a script.  a quick glance at it shows that it looks in /var/lib/initramfs-tools
<maks_> what is the error code erle- 
<alex_joni> any updates on bug #204319 ?
<ubotu> Launchpad bug 204319 in linux "radeonfb regression: disappearing fonts upon VT switch" [Undecided,New] https://launchpad.net/bugs/204319
<erle-> maks_, it works now oO
<cradek> alex_joni: #204319 is still marked new/undecided
<cradek> I wonder if all the framebuffer consoles are broken, or just aty and radeon
<cradek> bug #201591 and bug #204319 are similar.  I added comments to both but I hesitate to mark one of them as a duplicate.
<ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Undecided,Confirmed] https://launchpad.net/bugs/201591
<ubotu> Launchpad bug 204319 in linux "radeonfb regression: disappearing fonts upon VT switch" [Undecided,New] https://launchpad.net/bugs/204319
<arcticpenguin380> what scheduler does gutsy use?
<maks_> could someone update gitweb on kernel.u.c
<defendguin> how is hardy beta kernel wise?
#ubuntu-kernel 2008-03-22
<bullgard4> What programs do call /usr/lib/pm-utils/functions?
<mjg59> pm-utils
<bullgard4> pm-utils is no program. pm-utils is a DEB program package.
<mjg59> It's a suite of programs
<bullgard4> Thank you.
<alex_joni> mjg59: any ideas about bug #204319 ?
<ubotu> Launchpad bug 204319 in linux "radeonfb regression: disappearing fonts upon VT switch" [Medium,Triaged] https://launchpad.net/bugs/204319
<mjg59> alex_joni: Not off-hand - I don't have any hardware to test it
<alex_joni> mjg59: cradek in here reported it, and has access to hardware. let him know if there's anything else he could do to test 
<mjg59> Sure
<Nafallo> anyone know if the eee's wifi is supported in hardy?
<cradek> alex_joni: I should have tried vesafb too.  It may also be broken.
<Nafallo> that would be bug #182489 fwiw
<ubotu> Launchpad bug 182489 in linux-restricted-modules-2.6.24 "Atheros wireless (AR5006EG) not working on ASUS Eee PC" [High,Confirmed] https://launchpad.net/bugs/182489
<Kyashan8> hi all
<rick_> I'm having trouble with booting the Hardy LiveCD, I think it might be a bug
<rick_> The initramfs fails to unpack
<rick_> Any ideas on what I could do to track down the problem?
<Nafallo> rick_: check the cd / burn at a lower speed
<rick_> Nafallo: I tried it on someone else's computer and it worked OK
<rick_> Nafallo: This was my second attempt at burning a CD.  4x
<Nafallo> hmm
<Nafallo> reading other cds fine?
<rick_> Nafallo: Think so.  It mounts OK on a running system.  And I've never had any problems with the drive.  
<Nafallo> oki. dunno then.
<rick_> Nafallo: I'll retry at 1x and see if that fixes anything, but I'm kinda doubtful
<Nafallo> I doubt it as well
<Nafallo> if you want to waste time and a CD ;-)
<rick_> I'm gonna go afk for a bit.  Before I do though, could you point me to some information on how I can get a debug kernel source to the one on the CD?
<rick_> **identical to the one on the CD
<johanbr> rick_: If you want to install, try the alernate cd. Or try booting with "noapic nolapic irqpoll" as kernel parametsrs.
#ubuntu-kernel 2008-03-23
<rick_> johanbr: Thanks.  I'll try that.  
<Method> i'm trying to add a patch to the kernel package but can't figure out how the kernel package works, how do i get a real source package rather than the linux_meta package?
<thoreauputic> Re: Bug 129910  Yes, I know it is supposedly fixed... Could some kind kernel developer try booting with vga=xxx then attempt to switch from tty1 to any other tty ? Seriously. It might no longer be a kernel problem, and I'm probably off-topic, so apologies. Whatever it is , it isn't fixed (yet)
<ubotu> Launchpad bug 129910 in linux "Blank ttys when using vesafb (vga=xxx)" [Medium,Fix released] https://launchpad.net/bugs/129910
<thoreauputic> Tested repeatedly both on live Beta hardy CD and using an install without X. Bug comments also indicate the problem exists on a beta server install.
<mjg59> thoreauputic: No, that sounds like an entirely different bug
<thoreauputic> mjg59: I have reported a bug against console-setup - do you think that might be it?
<mjg59> No, it's the kernel
<thoreauputic> ah
<mjg59> It's just not bug 129910
<ubotu> Launchpad bug 129910 in linux "Blank ttys when using vesafb (vga=xxx)" [Medium,Fix released] https://launchpad.net/bugs/129910
<thoreauputic> OK
<thoreauputic> well, typing "setupcon" blindly resores the tty
<thoreauputic> *restores
<mjg59> Yes, the font is getting lost
<thoreauputic> aha
<thoreauputic> so this is known ?
<mjg59> It's been seen on other framebuffers
<mjg59> I wasn't sure it hit vesafb
<thoreauputic> it does
<thoreauputic> It's a show stopper for me as I am trying to make an up-to-date live CD without X
<thoreauputic> it would also be a problem for server admins I imagine
<thoreauputic> mjg59: Since this is an LTS relase, I would think it would be nice to fix it before April :)
<thoreauputic> ..if possible
<mjg59> Yeah
<thoreauputic> Lots of unhappy noisy commentators, including me ;)
<mjg59> Well, it's still not bug 129910
<ubotu> Launchpad bug 129910 in linux "Blank ttys when using vesafb (vga=xxx)" [Medium,Fix released] https://launchpad.net/bugs/129910
<thoreauputic> right
<mjg59> It'll be 201591
<thoreauputic> looking
<thoreauputic> yeah that looks more like it
<kraut> moin
<thoreauputic> mjg59: do you think I should confirm that with vesafb ? Looks like there is at least awareness of the issue
<mjg59> Sure
<mjg59> And feel free to mark the radeonfb one a dupe of it
<thoreauputic> OK I'll append a brief "Confirmed using vesafb"
<thoreauputic> mjg59: thanks, done. Hope the fix happens soon :)
<cradek> mjg59: bug 204319 has a patch, was triaged and assigned, was the one that got marked duplicate.  Does this affect the assignment?  I see the remaining one is unassigned and "undecided".  I don't care what number it is, but I worked hard to narrow down the breakage to that commit, and I don't want that information to be lost.  Should I also add it to the remaining bug 201591?
<ubotu> Launchpad bug 204319 in linux "radeonfb regression: disappearing fonts upon VT switch (dup-of: 201591)" [Medium,Triaged] https://launchpad.net/bugs/204319
<ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Undecided,Confirmed] https://launchpad.net/bugs/201591
<mjg59> cradek: It doesn't have a patch
<cradek> true I misspoke.  It does say which 10 line commit broke the framebuffers though.  the remaining bug 201591 does not have that very useful information
<ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Undecided,Confirmed] https://launchpad.net/bugs/201591
<mjg59> cradek: I'm working on it now
<cradek> thank you
<mjg59> Ah, I think I see the problem
<mjg59> Possible
<cradek> I wish the commit message had said which X drivers required this fix -- hard to check it without knowing that
<cradek> it's trivial to just fix the consoles [by removing this commit]
<mjg59> No, that breaks other stuff
<cradek> yes I understand that
<mjg59> It fixes that specific aspect of the consoles, and breaks another :)
<mjg59> cradek: Ok, think I've fixed it
<cradek> mjg59: thanks! I will be able to test it tomorrow US daytime
#ubuntu-kernel 2009-03-16
<rtg> all ext4 crack-heads follow Ted ==> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/175
<ubot3> Malone bug 317781 in linux "Ext4 data loss" [High,Fix released] 
<dandel> rtg, you there?
<dandel> i need to find out what i am supposed to do to set... CONFIG_ACPI_DEBUG and does this require a kernel compile?
<rtg> dandel: I expect it will
<dandel> ack.
<dandel> now what do i ened to install to compile 2.6.29rc8 or 2.6.29rc7?
 * dandel is following the maintainers instructions but doesn't like kernel compiles.
<rtg> dandel: build-essential fakeroot, etc. See https://wiki.ubuntu.com/KernelMaintenance
<dandel> hmm
<dandel> makedumpfile is missing
<dandel> oh... hardy is incomplete lol
<dandel> ok... got kernel source and whatnot installed, now what?
<rtg> dandel: if you use 'debuild -b' then all build assumptions are checked. It'll tell you whats missing
<rtg> of course, you must first install devscripts
<dandel> how do i get that?
<rtg> the usual way, 'apt-get install devscripts'
<dandel> already got it
<dandel> all i want to do is rebuild the acpi module with debug options.
<rtg> dandel: you can build a binary deb for just the flavour you want, 'fakeroot debian/rules build-debs flavours=generic'. Other then that, there aren't many short cuts
<rtg> build-debs ==> binary-debs
<dandel> going to take 5 or 6 min to get the extracted src
<dandel> oh wait, it finished already lol
<dandel> debian/rules not found.
<lool> amitk: w0Ã t
<lool> that was a woot, but mistype, anyway
<lool> amitk: NEON can cause babbage to deadlock due to hw bugs
<lool> amitk: Could you please turn CONFIG_NEON off in imx51?
<lool> amitk: This will be fixed in hardware updates; we don't know when we'll get them, but since we target the babbage development for now and the release anyway, we shouldn't take the risk; I don't think we'll get the new hardware soonish and others might run into it
<lool> amitk: This is recommended by Dave Martin from ARM
<lool> rtg: ^ You might be interested as well
<rtg> lool: your 'Add HWCAP_NEON to the ARM hwcap.h file' won't work worth a hoot if you disable CONFIG_NEON
<lool> rtg: Crap
<lool> lskdgkjlqzhkgl hlq
<lool> rtg: That makes sense; but it's kind of a stupid situation
<rtg> lool: its all protected with '#ifdef CONFIG_NEON'
<lool> rtg: Yes, I didn't think of that
<lool> rtg: I've asked dave_m to join here; he requested both changes which are contradictory
<rtg> lool: I'll let you and amitk duke it out.
<lool> rtg: Thanks
 * amitk would like to take this opportunity to reiterate - We shouldn't apply crack in such a hurry w/o testing
 * rtg feels like he's been bitch slapped :)
<dandel> hmm... where do i find the ubuntu upstream git repo for 2.6.29rc8
<rtg> dandel: there isn't one. apw has a mainline build script that synthesizes a debian build from the upstream kernel git repo
<apw> dandel, yep, in essence we rip the source tree out of our reposity and graft in the offical tree from linus' repo
<apw> so the official source for the kernel is his code at that level
<apw> we then push our kernel configuration in and build packages from it
<apw> there are source packages for the trees in there
<dandel> blah... i like binary build... a maintainer asked me to set a param and i don't want to build the whole kernel to do it.
<dandel> apw, look at this... http://bugzilla.kernel.org/show_bug.cgi?id=12873 
<ubot3> bugzilla.kernel.org bug 12873 in Config-Interrupts "ACPI_IRQ not set" [Normal,Needinfo] 
<dandel> if i could figure how to set config_acpi_debug without having to build the whole kernel it'd be great.
<apw> dandel, thats a pretty core so i think you'd have to rebuild most things to set that anyhow
<apw> have you checked if it is set already?
<dandel> it's not
<dandel> not in the one that's in mainline tree
<apw> hrm, no its not in  our standard configs, so it'd not be
<dandel> 2.6.29-020629rc8-generic does not have that option set.
<mjg59> dandel: You can't
<mjg59> dandel: acpi is an integral part of the kernel. Enabling debug will force most of the kernel to be rebuilt.
<apw> you are pretty much forced to rebuild
<dandel> ><;
<dandel> can i get a acpi debug enabled build then?
<apw> i take it it has to be 2.6.29-rc7
<dandel> 2.6.29rc8 has same dmesg output
<dandel> i don't think it'll matter as long as i get the log up and point to which version of kernel it is.
<apw> dandel, i take it you are not keen to build one
<dandel> i haven't done it before, and last few times i royally screwed up the machine doing it.
<apw> hrm
<dandel> kernel builds take up a lot of space, and i don't have that to spare.
 * apw has a look
<dandel> last i checked, it takes about 5 to 6gb to build the kernel.
<apw> i'd say about 1gb, but not tiny
<apw> whats your platform?  32bit 64 bit?
<dandel> 32
 * rtg gloats about his 4 spindle 2TB build server
<dandel> with the dmesg of... 2.6.29-020629rc8-generic ... should of been obvious.
<dandel> i believe the 64 bit version has a version of somethin like... 2.6.29-020629rc8-amd64
<apw> nope: 2.6.28-8-generic
<apw> and i can shave 50% off by asking
<lool> dave_m_: Hey
<lool> amitk: Dave Martin == dave_m_ above
<lool> amitk: it's not crap and it's useful
<lool> rtg: ^
<dandel> apw, at least i knew enough to check where the bugs where, which is better than 90% of people who just install to run programs.
<apw> indeed
<lool> amitk, rtg: At least at the source level, we can rebuild the pristine jaunty kernel when new hardware comes out
<apw> dandel, is there an ubuntu bug for this?
<lool> amitk, rtg: Now, according to dave_m_, the NEON code used by the kernel itself wont trigger the hang
<dandel> yes
<apw> wahts the #, can tie the kerenls to that
<lool> amitk, rtg: So it should be safe to keep it enabled IIUC; problematic NEON code triggering the hang is in ffmpeg and in pixman, so in userpsace
<dandel> bug # 338701
<dave_m_> lool: I would need to double-check that.
<lool> amitk, rtg: CONFIG_NEON or not doesn't change the fact that these could deadlock the platform
<rtg> lool: works for me
<lool> dave_m_: please do
<apw> bug #338701
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
<dandel> it has a sister bug namely bug #294323
<ubot3> Malone bug 294323 in linux "Special Function keys broken after upgrade ( Toshiba Satilite P305D, 2.6.27 kernel) (dup-of: 261318)" [Undecided,New] https://launchpad.net/bugs/294323
<ubot3> Malone bug 261318 in linux "Regression: new Toshiba Laptop Support (tlsup) driver breaks Toshiba hotkeys; input device does not support 'kbd' input handler" [High,Fix released] https://launchpad.net/bugs/261318
<lool> rtg, amitk: So what dave_m_ was also proposing is to check with FSL how we can identify the problematic boards; would you be ok to merge a patch disabling/enabling NEON based on the baord?
<lool> rtg, amitk: The hwcaps changes and the NEON disablement are really orthogonal; it's just unfortunate that the only *hardware* that we have is broken; would we have working hardware (which we'll likely have later), or another supported NEON platform (e.g. beagleboard), we wouldn't face this contradictory situation
<dandel> although, that bug got semi-fixed, but the suspend/shutdown, power plug status and battery updates where all messed up
<lool> rtg, amitk: I think if we get confirmation that NEON in the kernel works, we don't need to do anything to the config and you can just ignore my request to disable it; I'm sorry I only learnt later today that NEON was causing deadlocks on iMX51
<rtg> lool: you and amitk work it out. I'll already been smacked once today.
<lool> dave_m_: In all cases, kernel patch or not, I think it's useful to recognize problematic hardware so that we can at least assist people coming with random hangs
<dave_m_> Apologies, it was me not realising that iMX51 is the only official target with NEON support at present.
<lool> rtg: I'm sorry about that :-(
<lool> rtg: Didn't know about the hardware issues earlier today, this is news to me
<dave_m_> Just running a kernel with NEON support built in doesn't cause problems. So maybe we can split the discussion into kernel and userspace.
<dandel> apw, mind walking me through building just enough of the kernel to boot up to the console for a dmesg report?
<lool> dave_m_: So we don't need to disable CONFIG_NEON?
<apw> dandel, i was just working on a build for you now
<dandel> oh, thanks :D
<dave_m_> CONFIG_NEON by itself is not a problem.  It's only if some app tries to use NEON that the problems can occur.
<JayFo> pgraner, finally here now. stupid restricted network
<JayFo> I'll tell you later
<pgraner> JayFo: lol, glad to have ya
<JayFo> :)
<JayFo> thanks
<dandel> hmm... actually, i wonder how severe my bug really is... lol. (besides knocking out the power management on my laptop)
<dandel> i had to debate between 2.6.24 and 2.6.27+ because 2.6.27 had proper cpu throttling on my laptop.
<dandel> oh, how should i report bugs with the ubuntu hybernate, because the windows based installer and such for ubuntu leads to unusable hybernate.
<apw> all bugs should go into launchpad
<dandel> if i hybernate i get a long long dmesg log due to the fact it's trying to fit 3gb of ram in to a 1gb swap.
<dandel> it's an installer bug from what i can tell.
<apw> in what sense?  that it should have made a bigger swap?
<dandel> it should let me do a custom partition table for starters
<apw> sounds like an installer bug yes
<dandel> 8.04.2 autoconfigured everything.
<dandel> and thus i couldn't even tell it that the swap needed to be at least 3gb
<dandel> 8.10 is the same, as for 9.0x i couldn't even get the windows based installer to even run.
<apw> both of those sound like they need reporting
<dandel> if i knew which part of the launchpad to put i would of
<dandel> anyways, i had to blacklist the ath5k driver due to the fact it can't even work right ><; doesn't detect my wap which is less than 3 feet away.
<amitk> lool: rtg: I still stick by my initial statement. It shouldn't have gone in, in the first place. There are several people who have the board that could test it (even in my absence). cooloney is in the China TZ and could've helped. The reason I am bitching is that it causes extra work. Apply-upload-test-explode-revert-upload isn't my ideal workflow.
<lool> amitk: What does?  The NEON hwcap?
<amitk> lool: yeah
<lool> amitk: Why so?
<cooloney> amitk, lool sorry i'm not get the whole story
<dandel> hmm... i assume kernel panics are critical bugs right? ( i have a friend which on one of the newer kernels gets panics every 5 min on his laptop.
<amitk> lool: because of all the discussion that has been going on. Instead, the patch could've been emailed, tested and only then applied.
<lool> amitk: I currently need it to demonstrate NEON support in ffmpeg in jaunty; yes, it's a new feature
<lool> amitk: The patch is ok
<lool> amitk: It's not wrong in any case
<amitk> lool: you claimed it was
<lool> No
<amitk> 17:01 < lool> amitk: NEON can cause babbage to deadlock due to hw bugs                                                                                                         gnomefreak    
<amitk> 17:01 < lool> amitk: Could you please turn CONFIG_NEON off in imx51?     
<lool> amitk: That's unrelated to the patch I sent
<lool> amitk: The patch I sent is to enable NEON 
<lool> *hwcaps*
<lool> Not CONFIG_NEON
<lool> amitk: CONFIG_NEON is currently turned on already
<lool> amitk: I think you're mixing the two, they are completely orthogonal
<gnomefreak> what did i do?
<lool> amitk: Does this clarify?
<lool> amitk: I logically need NEON support in all software bits, but the hardware is broken; all NEON support around is correct, and even the binary kernel is ok if you get a new babbage board which doesn't deadlock in some code present in ffmpeg and pixman
<dave_m_> lool: Is it reasonable to enable the infrastructure for NEON support (CONFIG_NEON, HWCAP_NEON and optionally ld.so hwcap support), but to avoid software which uses NEON for this release? It still feels valuable, because people can develop against the infrastructure when suitable platforms are available.
<amitk> lool: perhaps I was mixing them up. In which case apologies.
<lool> amitk: No problem, I do agree with you that the hurry was a bad idea, but it's close to beta and I wanted to meet our goals, even if the technical changes are understood only so late   :-/
<lool> amitk: I feel bad to have put everybody on the nerves about this; I'll do my best to make everything as smooth as possible; concerning NEON we don't need any other change in the tree now; the patches which rtg merged this morning were correct and useful
<lool> No need to change CONFIG_NEON either, that part was wrong from me
<rtg> lool: s'ok, I had not gotten around to it yet anyway
<amitk> lool: ack
<lool> rtg: Do keep your hwcaps changes though  ;-)
<rtg> lool: both patches are in the repo
<lool> rtg: Saw them, that's great, thanks a lot
<dandel> apw, how's the build going along?
<apw> its building now, i had some tooling issues, not tried to build a mainline kernel locally since they were automated and i've broken it along the line
<dandel> oh fun.
<apw> dandel, the kernels images you needed should be uplaoded in a couple of minutes, link in the bug
<dandel> apw, ok, i'll get em in about in about 15 min, just to make sure they are completed.
<apw> they are done my end
<dandel> k
<dandel> i'll put up the log asap.
<dandel> just haft to wait for initramfs.
<dandel> libc 2.6 vs libc 2.7 lol... nice little complain lol.
<Keybuk> rtg: around?
<rtg> Keybuk: I'm a square
<Keybuk> a square will do fine
<Keybuk> need an opinion on bug #296710
<ubot3> Malone bug 296710 in linux "warning: ehci_hcd loaded AFTER uhci_hcd and ohci_hcd" [Undecided,Confirmed] https://launchpad.net/bugs/296710
<Keybuk> I've been doing some investigation, and it turns out that the three drivers have no overlapping modules aliases
<Keybuk> in fact, they each export exactly one
<Keybuk> ehci_hcd  pci:v*d*sv*sd*bc0Csc03i20*
<Keybuk> ohci_hcd  pci:v*d*sv*sd*bc0Csc03i10*
<Keybuk> uhci_hcd  pci:v*d*sv*sd*bc0Csc03i00*
<rtg> right, which is one of twe reason I've been confused why link order makes any difference
<rtg> or load order
<Keybuk> now, because they don't overlap - there's nothing we can do in userspace
<Keybuk> modules.order won't help
<dandel> apw, no log change.
<Keybuk> if we find the USB-1 hub first, [uo]hci_hcd will be loaded before ehci_hcd
<apw> dandel, you should have a .config with it in /boot
<Keybuk> and that can happen if the laptop has a USB-1 hub, and someone plugs in a USB-2 pccard
<apw> can you confirm the entry is in there
<Keybuk> but I don't understand why there's a warning in the kernel anyway?
<rtg> Keybuk: can we modprobe it in initramfs ?
<Keybuk> if the modaliases don't overlap
<Keybuk> then why does it matter?
<Keybuk> rtg: if that's the kind of fix we need, build it into the kernel!
<rtg> Keybuk: lemme look at the code.
<Keybuk> k,
<Keybuk> bbiab tea
<dandel> it is set
<dandel> but, config_acpi_debug_func_trace is not
<dandel> i'll put the log on the main kernel.
<apw> i thought they only asked for the former
<apw> but yep stuff it up and see waht they ask for 
<apw> next
<dandel> done, and should i place it on the launchpad too?
<dandel> apw, i think your on intrepid :)
<apw> dandel, yeah put it on there too may as well, helps keep us informed
<apw> dandel, why so?
<dandel> laptop is set to hardy
<apw> i built those images in an intrepid chroot, but the machine was running jaunty
<dandel> it's got a long string of error due to that ><;
<dandel> however, that's long after the irq is disabled.
<apw> dandel, odd
<dandel> here's the log... http://launchpadlibrarian.net/23949351/dmesg_2.6.29-020629rc8-generic.log
<dandel> line by line dump as follows... [    2.524473] Pid: 1, comm: swapper Not tainted 2.6.29-020629rc8-generic #1
<dandel> that's where it starts... i won't past much more since it's over 15 lines.
<dandel> it ignores my dsdt in the bios
<dandel> however, that's not new.
<apw> [    0.000000] Unknown boot option `acpi_debug.layer=0x44': ignoring
<apw> [    0.000000] Unknown boot option `acpi_debug.level=0x08000004': ignoring
<apw> doesn't look like the debug is turned on in that boot to me
<dandel> i set the parameters :D
<dandel> pfft
<dandel> i found it
<dandel> he should of said... acpi.debug_level
<apw> dandel, yep, just about to say the very same
<dandel> yay... now the spam begins.
<dandel> ev_gpe_detect
<dandel> and ev_fixed_event_detect are large parts
<dandel> 80 seconds of spam b4 it got done
<rtg> Keybuk: I wonder what the downside would be to build in ehci? I can't see a hardware reason for the warning, just vague warning in google articles that bad things could happen, or that existing USB 1.0 devices will get disconnected when a 2.0 device is inserted.
 * dandel adds new log shortly.
<IntuitiveNipple> rtg: I was able to reproduce that on a PC here at one time. Would it help if I figured out which one so we can work on an effected system?
<rtg> IntuitiveNipple: can you remember how you did it? Insert USB 1.0 device, then a 2.0 HUB ?
<dandel> uhh... apw... log is too long
<dandel> it cut out huge parts of it
<apw> heh nice
<IntuitiveNipple> rtg: I *think* it was just the 'default' boot-up ... I didn't *know* there was a problem until an external USB2 hub with 160G USB2 drive began behaving slowly... then the slowness 'went away' so I never really confirmed the issue 
<dandel> [  190.652052]    evgpe-0444 [00] ev_gpe_detect         : Read GPE Register at GPE18: Status=01, Enable=80 to [  214.452038]    evgpe-0444 [00] ev_gpe_detect         : Read GPE Register at GPE18: Status=01, Enable=80
<dandel> that takes 1.1k lines
<rtg> IntuitiveNipple: so, its likely you either have a 1.0 hub built in to the laptop, or only have 1.0 devices connected initially.
<dandel> hmm.
<IntuitiveNipple> dandel: apw: FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4)   ... not necessarily related but...
<IntuitiveNipple> rtg: Yes, it has both USB1 and USB2 hubs... USB1 seem to be used for the internal USB devices
<dandel> hmm.... i better copy the source file in /var
<IntuitiveNipple> rtg: (four lspci lines follow)
<IntuitiveNipple> 00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 02)
<IntuitiveNipple> 00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 02)
<IntuitiveNipple> 00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 02)
<IntuitiveNipple> 00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 02)
<IntuitiveNipple> 00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 02)
<rtg> IntuitiveNipple: hmm, so it _did_ load the ehci driver, but just not in the right order. correct?
<IntuitiveNipple> rtg: actually, yes, I think this is affected... I've just checked /etc/initramfs-tools/modules and found:
<IntuitiveNipple> ehci_hcd
<IntuitiveNipple> uhci_hcd
<rtg> IntuitiveNipple: well, thats what fixed it
<IntuitiveNipple> So, I must have thought I needed to fix it. I have dinner now but afterwards I'll change that and do some tests for you
<dandel> eww... corrupted low memory is in the log
<rtg> IntuitiveNipple: I'll build a test kernel with ehci built in
<IntuitiveNipple> rtg: I can do that here. I'll get back to you later when I've had time to play
<rtg> IntuitiveNipple: I think it already is built in.
<rtg> oh, nm
<IntuitiveNipple> modinfo ehci_hcd
<IntuitiveNipple> filename:       /lib/modules/2.6.28-9-generic/kernel/drivers/usb/host/ehci-hcd.ko
<rtg> right, I was looking at ARM configs
<IntuitiveNipple> gotta go - dinner cooling :D
<dandel> apw, i got it... but compressing it takes first step
<dandel> which is more useful... syslog messages or kern.log
<Keybuk> rtg: yeah the warning confuses me
<Keybuk> maybe it's to do with how the kernel decides it's a USB 2.x hub?
<Keybuk> if you have a USB 2.x hub with only USB 1.x devices plugged in, does it look like a USB 1.x hub ?
<Keybuk> so ohci/uhci would claim it
<rtg> Keybuk: AFAIK
<Keybuk> whereas the ehci_hcd driver knows better?
<Keybuk> that sounds rather shaky though
<Keybuk> and almost like they shouldn't have three drivers ;)
<dandel> apw, want to look through em?
<rtg> Keybuk: on the other hand, it diesn't make sense that a 1.0 device would cause uhci to load. he driver thats loaded is, after all, based on PCI ID.
<IntuitiveNipple> right... back. Will rebuild initrd without the module load-order
<Keybuk> rtg: indeed
<mjg59> Load order is important
<rtg> IntuitiveNipple: mighty quick dinner :)
<Keybuk> mjg59: but *why* is it important? :)
<Keybuk> that's what we're trying to understand
<mjg59> If uhci loads before ehci then it'll chirp 1.0 at the device
<mjg59> Then when ehci loads the device will already be bound
<Keybuk> mjg59: but given uhci has no device table overlap with ehci - why does uhci even try?
<IntuitiveNipple> rtg: fast eater :D
<mjg59> Keybuk: I don't understand
<Keybuk> surely it should dismiss the pci device because it has the wrong pci ids
<mjg59> Keybuk: No
<Keybuk>  ehci_hcd  pci:v*d*sv*sd*bc0Csc03i20*
<Keybuk>  ohci_hcd  pci:v*d*sv*sd*bc0Csc03i10*
<Keybuk>  uhci_hcd  pci:v*d*sv*sd*bc0Csc03i00*
<mjg59> Keybuk: ehci doesn't support USB 1 at all
<mjg59> Keybuk: You have to have uhci or ohci fallback
<Keybuk> doesn't support USB 1 hubs or USB 1 devices on USB 2 hubs?
<mjg59> Things get complicated with 1 devices on 2 hus
<mjg59> At that point I think you're supposed to speak 1 in 2 framing
<Keybuk> what I don't get is why, when you load uchi_hcd, it does anything to the PCI device that it doesn't claim
<Keybuk> surely it should ignore it (just like it doesn't try and speak USB 1 to your sound card :p)
<mjg59> Which is loading first? uhci or ehci?
<Keybuk> let's say you have a machine
<Keybuk> it has two PCI devices
<Keybuk> one of which is a USB 2.x hub (i20)
<Keybuk> the other is a USB 1.x hub (i00)
<mjg59> No, don't use the word hub here
<Keybuk> what's the right word?
<mjg59> host
<Keybuk> ok
<Keybuk> so we have in slot 1 a USB 1.x host (i00)
<Keybuk> and in slot 2 a USB 2.x host (i20)
<Keybuk> we'll probably load uchi_hcd first
<mjg59> Right
<Keybuk> because of the ...i00* match
<mjg59> At that point the USB ports will be powered up
<Keybuk> why does that module claim the device in slot 2 ?
<mjg59> It doesn't
<mjg59> ehci will also be loaded
<mjg59> But
<mjg59> When uhci binds, it'll power up the ports
<Keybuk> ehci will only be loaded because there's a USB 2.x host as well
<mjg59> The USB device at the other end will then send a chirp
<Keybuk> the ports of which host?
<mjg59> They're the same prots
<Keybuk> or are you saying those two hosts share a single hub?
<mjg59> As I said, the word "hub" is not meaningful here
<Keybuk> sorry, single port (or set of ports)
<mjg59> But yes, the two hosts share the same physical ports
<Keybuk> ahhh
<Keybuk> so the two PCI devices do not map 1:1 to the ports on the back
<mjg59> The USB device will then chirp and only get a USB 1 device
<Keybuk> the ports on the back are shared by both PCI devices
<mjg59> s/device/response/
<Keybuk> one of which is for a USB 1.x legacy driver and legacy OS
<Keybuk> the other is for a USB 2.x OS ?
<mjg59> ehci will then load, but will not reenumerate the devices
<mjg59> Because they're already bound to uhci
<Keybuk> what happens if you load ehci, and you have only USB 1.x hosts?
<mjg59> They don't work
<Keybuk> but then if you load uhci ?
<Keybuk> do they work then?
<mjg59> Yes
<Keybuk> neat, thanks for the explanation
<Keybuk> so building in ehci would solve the issue ;)
<mjg59> They'll chirp, ehci will refuse to talk to them and then uhci will reenumerate them
<rtg> mjg59: so, it seems that the real solution is to build them both into the kernel, making sure ehci is linked first, right?
<Keybuk> rtg: ehci is first in the link order
<Keybuk> though it's tempting to leave uhci and ohci as modules since they're "less common"
<mjg59> Yeah, for a reason
<dandel> apw, the log is up, however, i had to compress it with gz so it would be a manage-able download.
<mjg59> Keybuk: Built-in USB peripherals like fingerpritn readers are often USB 1
<Keybuk> mjg59: the link order doesn't pass down to userspace though, since though it's in modules.order, we never probe an alias that expands to both modules
<Keybuk> mjg59: ahh, interesting
<mjg59> Because it's cheaper to produce
<rtg> Keybuk: plenty of old mice that are 1.0
<Keybuk> hmm
<Keybuk> it only matters for the host though?
<Keybuk> ehci can talk to a 1.x mouse on a port served by 2.x host?
<mjg59> Keybuk: No
<Keybuk> no?
<Keybuk> ahh
<mjg59> ehci can't speak USB 1 wire protocol
<Keybuk> so to support a 1.x mouse, you have to have a 1.x host?
<mjg59> Yes
<Keybuk> got it
<mjg59> Or plug it into a 2.0 hub which is plugged into a 2.0 host
<mjg59> The hub does the reframing in that case
<Keybuk> right, the 2.0 hub has a 1.0 host in it, and knows how to transmit that
<JanC> 1.1 works on a 2.0 host, 1.0 doesn't work on 2.0 host, I think?
<rtg> uhci takes over when a 1.0 peripheral is inserted (I think)
<Keybuk> hmm
<Keybuk> when you insert a new device
<Keybuk> if you have both ehci and uhci loaded
<Keybuk> how do they determine which one wins?
<mjg59> There's some magic in that case
<mjg59> But ehci always wins
<Keybuk> and that magic doesn't work on first init unless ehci is loaded first?
<Keybuk> I guess you have to know to switch the magic on ;)
<mjg59> I believe that once ehci has loaded, the root hub is then willing to respond to the 2.0 chirp
<mjg59> It's handled at a level below the OS
<Keybuk> ah, ok
<rtg> Keybuk: building these modules into the kernel is essentially the same as the initramfs solution.
<Keybuk> rtg: yes, except it works when you don't have an initramfs ;)
<rtg> correct
<mjg59> The strongest argument for building ohci and uhci in is so you have a working keyboard
<mjg59> Since they're basically always USB 1.x
<Keybuk> mjg59: yes, I was thinking about that ;)
<IntutiveNipple-S> The test PC has just booted... will post the dmesg to the bug report
<mjg59> Keybuk: This is also a case where suspend/resume ordering is important - if you resume the 1.x host before the 2.0 one, all your dual-speed devices fall back to 1.x
<Keybuk> ah, interesting
<Keybuk> it definitely sounds like just building these in is the right solution
<Keybuk> I can't think of any con of doing so
<mjg59> The only reason this currently works is that ehci always come after uhci in the PCI tree, and we resume devices backwards...
<rtg> mjg59: are there no OHCI controllers on 64 bit platforms?
<mjg59> rtg: You can get them on PCI cards
<apw> Keybuk, i thought someone said they needed to blacklist them for something?
<Keybuk> apw: only reason I can think of would be power?
<apw> how will you guarentee init order in these two?
<Keybuk> apw: kernel link order
<apw> i think that might have been the reason given thinking on it
<apw> that you can guarentte it with a probe/probe sequence and not by building in
<apw> if we can now do that then we win
<Keybuk> ?
<Keybuk> I didn't understand that
<mjg59> apw: It's guaranteed that drivers will be intialised in the order that they're linked into the kernel
<mjg59> As long as ehci binds first, you won't have a problem
<mjg59> Of course, xhci will have to link before ehci
<apw> Keybuk, i think my memory that undefined init order was a reason given to me to not build them in
<apw> it sounds like we are relying on and assuming link order as init order so
<Keybuk> apw: the init order in the kernel is very very definitely defined ;)
<apw> building them in sounds liek its a win
<mdz> what is the maximum amount of physical RAM supported by the 32-bit -generic kernel?
<apw> 4GB
<apw> but there is no guarentee you can put 4GB in any one machine
<Keybuk> mjg59: xhci replaces ehci though, right?  I remember reading that it's supposed to be compatible with 2.0 up
<apw> and see it with a 32 bit kernel
<mjg59> Keybuk: Oh, maybe
<apw> some machines place it elsewhere to avoid making io holes in it
<mjg59> Keybuk: But if it's compatible you'll need to build xhci in so that ehci can't bind to it
<mdz> apw: hmm
<Keybuk> mjg59: right, but this makes sense too
<Keybuk> otherwise you then have to remember to load x-before-h-except-after-o-unless-using-e
<apw> it is common for 4 gb machines to place memory at 0, 1, 2 and 4 gb
<mjg59> It's guaranteed that you *can't* get 4GB on 32-bit without PAE
<apw> and you would only see the first three with a non-pae kernel, ie with out 32 bikernels
<mjg59> Since PCI has to go somewhere
<apw> mjg59, its guarenteed you won't get 100% of the 4GB yes, but some may surround the io space
<mdz> would it be fair to say that it does NOT support 4GB or more?
<mjg59> Keybuk: It's starting to sound like a rap star
<rtg> mdz: absolutely correct
<mdz> s/fair/accurate/
<Keybuk> mjg59: MChci!
<apw> close enough for a release note style statement yes
<Keybuk> it would certainly be more accurate to say that "x86 supports machines of less than 4GB of memory" than "x86 supports machines of up to 4GB of memory"
<mjg59> A PAE kernel obviously gives you support for more, limited by your chipset
<Keybuk> but PAE kills kittens, apparently
<IntutiveNipple-S> Keybuk: can we blacklist a driver in initrd ?
<rtg> mjg59: presumably, on those machines you couldn't stuff more then 4GB
<Keybuk> IntutiveNipple-S: yes, same was as you do after - just run update-initramfs
<mjg59> rtg: 945 only has 32 bits of data lines on the memory controller, for instance
<IntutiveNipple-S> Keybuk, so it's enough to add to /etc/modprobe.d/blacklist ?
<Keybuk> rtg: the problem aiui is that once you enable PAE, you cease supporting chipsets without it
<mjg59> But even with PAE, you can't get the full 4GB
<mjg59> Keybuk: Chips, not chipsets
<Keybuk> IntutiveNipple-S: and run update-initramfs, yes
<IntutiveNipple-S> Keybuk, OK, going to add ehci_hcd to the blacklist to see if the physical external ports are shared by the controllers
<mjg59> You can run a PAE kernel on a core 2 with a 945, even though it's only got 4GB of address space
<rtg> Keybuk: I'm thinking abuot a new PAE flavour for Karmic, and drop 32 bit server
<Keybuk> rtg: I'd make PAE the default and have a -crusty flavour - but that's me, always forward never looking back at the people crying in my wake ;)
<rtg> can't make it the default. too many non-PAE CPUs out there. VIA for example.
<IntutiveNipple-S> we need a way to 'stop' external HDDs on USB ... when it is unplugged I can hear the emergency retract
<Keybuk> IntutiveNipple-S: eject them
<Keybuk> eject /dev/sdN
<IntutiveNipple-S> I tried that ... didn't help. Will re-investigate when I get time
<IntutiveNipple-S> OK, the other machine has decided to do an fsck... twiddles thumbs
<rtg> IntutiveNipple-S: its time for ext4 :)
<IntutiveNipple-S> rtg, most of the volumes on it are ext4... I suspect this one might have remained ext3 for backwards compatibility with Hardy though
<IntutiveNipple-S> There's 11 volumes mounted on it, that helps cut down on boot delays from one big fsck
<rtg> IntutiveNipple-S: sounds like a hell of  a big server
<IntutiveNipple-S> laptop
<IntutiveNipple-S> I just split all the logical work areas into separate LVMs
<rtg> or, just a big drive with lots 'o volumes
<IntutiveNipple-S> so, /home then /home/all then /home/all/Project /home/all/SourceCode /home/tj/ and so forth
<IntutiveNipple-S> music, videos, etc., on separate LVMs too#
<IntutiveNipple-S> right the laptop has started. Confirmed ehci_hcd isn't loaded
<rtg> I just built a server with 4 500Gb disks using raid 0 and ext4. Its significantly faster then a single spindle.
<Keybuk> heh
<IntutiveNipple-S> Yeah, I've got a dell with PERC and RAID-5 in the garage, and a soft md raid-5 with 5 disks in another dev machine. makes a hell of a difference
<mjg59> It also turns out that fsck is much faster if you can run as many threads as you have spindles
<IntutiveNipple-S> USB1 transfer is happening via port 1
<IntutiveNipple-S> just need to check which host is in use
<Keybuk> mjg59: something we're vaguely working on now that fsck is moving into util-linux-ng is to have a mount daemon in there that handles the fsck and mount stuff based on either udev or dbus
<mjg59> There's threaded patches for ext3 fsck. And probably ext4.
<Keybuk> indeed
<Keybuk> though then you need a flag point where you know that /dev is full
<mjg59> And SGI implemented it for xfs at some point (their Final Solution)
<IntutiveNipple-S> Is there an easy way with /sys/ to show the USB host and target path to show which device is connected via which port on which host?
<IntutiveNipple-S> I've been digging but can't find a clear way to show the linkage
<Keybuk> $ for DEVICE in /sys/bus/usb/devices/*; do readlink $DEVICE; done
<Keybuk> the PCI id part of the path will change
<IntutiveNipple-S> beautiful, thanks. I was trying something similar but starting from /sys/block/ (to show the disk-to-usb relationship)
<IntutiveNipple-S> If i can get something similar from the block/ path it will make it easy to show which host/port the device in port 1 is on for all permutations of the drivers
<IntutiveNipple-S> I've got "readlink /sys/block/sdb/device" == "../../../7:0:0:0" but not been able to get the clear path shown like your code does
<Keybuk> just do a readlink on /sys/block/sdX itself
<Keybuk> $ for DEVICE in /sys/block/*; do readlink $DEVICE; done
<IntutiveNipple-S> got it! I'd gone one directory too far :)
<IntutiveNipple-S> readlink /sys/block/sdb
<Keybuk> ;)
<IntutiveNipple-S> I was working inside the sdb/ directory off the device link
<IntutiveNipple-S> ended up with lots of relative stuff, not realising the sdb/ has symlinked me someplace else in /sys/ already
<Keybuk> that works too
<Keybuk> it'll just take you higher up in the same tree
<IntutiveNipple-S> this is what i wanted... one line shows the linkage now
<Keybuk> /sys/block/sda will point at something like /sys/devices/BUS/DEVICE/SCSI HOST/SCSI TARGET/SCSI ID/block/sda
<Keybuk> /sys/block/sda/device will point at the physical device
<Keybuk> which is obviously the SCSI ID
<Keybuk> /sys/block/sda will point at something like /sys/devices/BUS/DEVICE/SCSI HOST/SCSI TARGET/SCSI ID
<Keybuk> err
<Keybuk> /sys/block/sda/device will point at something like /sys/devices/BUS/DEVICE/SCSI HOST/SCSI TARGET/SCSI ID
<Keybuk> the device symlinks are entirely needless these days
<Keybuk> since if they point at anything other than an ancestor in the tree (.. or ../.. usually) they're bogus
<IntutiveNipple-S> I know what we could do with. A patch to ehci_hcd reporting the number of ports it is handling, like uhci_hcd reports
<IntutiveNipple-S> lol... been slapping the bluetooth mouse because it stopped working... then realised I'd just rmmod uhci_hcd... and the BT module is on an internal USB1 port :D#
<IntutiveNipple-S> matters just got worse! when using the touchpad, the mouse cursor gets stuck on X screen 1 if it ventures there, which it now has, but another bug in Xserver means all apps started from screen 1 end up on screen 0 so got no terminal to reload uhch_hcd  ... going home!
<IntutiveNipple-S> ssh saves the day :)
<ernstp> I keep getting timeout exceptions from the ata subsystem in Jaunty, never happened on Intrepid
<ivoks> has anyone reported problems with latest hardy kernel on sparc machines?
<ernstp> could it be a kernel bug or will everyone blame my hardware?
<ernstp> http://paste.ubuntu.com/132196/
<ernstp> happens with different bios settings, different sata ports
<ivoks> did you check out smart?
<ernstp> only my ext4 root filesystem during big dist-upgrades, but that's probably because it's such a heavy load
<ernstp> ivoks: no errors ever
<IntuitiveNipple> ernstp: that doesn't look great. Can you post a bug report and attach the system's /var/log/dmesg and /var/log/kern.log containing the error messages?
<ernstp> IntuitiveNipple: yeah, I decided to give a bugreport a shot
<ernstp> IntuitiveNipple: only got dmesg though, bit tricky with the logs with the read-only filesystem :-(
<IntuitiveNipple> hmmm, that bad? how about using netconsole or a serial console to capture the error log?
<ernstp> I have other filesystems so I have done dmesg > /file
<ernstp> so I've got that
<IntuitiveNipple> sometimes dmesg doesn't contain the error reports... but if it does, then we don't need kern.log
<ernstp> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/343919
<ubot3> Malone bug 343919 in linux "[jaunty] ata timeout exception with data loss" [Undecided,New] 
<ernstp> right :-)
<IntuitiveNipple> Does it only affect the one drive? The Samsung SP2504C ?
<ernstp> IntuitiveNipple: yeah, and only that filesystem
<IntuitiveNipple> Do you have smartd installed?
<IntuitiveNipple> as in smartmontools
<ernstp> I did a smartctl --all on the disk, no errors ever
<ernstp> IntuitiveNipple: but I'll install that
<ernstp> IntuitiveNipple: oh, I did have it installed
<IntuitiveNipple> yeah, I just saw an article about it causing the issue, but that was some time ago now
<ernstp> IntuitiveNipple: yikes, it can do that kind of stuff... ?
<ernstp> IntuitiveNipple: well I'll uninstall it then, see if it happens again
<IntuitiveNipple> can you paste this report to the bug? lspci -nn
<ernstp> IntuitiveNipple: write ernstp: so I see when you write ;-)
<ernstp> IntuitiveNipple: http://paste.ubuntu.com/132216/
<ernstp> IntuitiveNipple: gonna try running with the mainline kernel 2.6.28.7 for a while
<ernstp> IntuitiveNipple: see if it still happens
<IntuitiveNipple> Don't worry, it will :)
<IntuitiveNipple> Stick with the Ubuntu kernel so we can debug it.
<ernstp> IntuitiveNipple: kk
<ernstp> IntuitiveNipple: this looks similar.. https://bugs.launchpad.net/ubuntu/+bug/315572
<ubot3> Malone bug 315572 in ubuntu "alert! /dev/disk/by-uuid/be80cf42-e6f2-466c-bb73-7d664956a334 does not exist" [Undecided,New] 
<ernstp> ok, gotta sleep now, cya
#ubuntu-kernel 2009-03-17
<dandel> apw, my logs complained about a few issues with memory, so i am running memtest86 on it... 4 passes so far and no errors yet.
<CarlFK> ... error while loading shared libraries: libgif.so.4: cannot open shared object file: No such file
<CarlFK> carl@dv67:~/src/pdf417_enc.4.4$ locate libgif.so.4 
<CarlFK> /usr/lib/libgif.so.4
<CarlFK> what little bit of magic do I need to hook that up?
<CarlFK> oh crap - sorry, wrong chan
<jcastro> hi, I am trying to determine if bug 289356 is the same as this bug: http://bugzilla.kernel.org/show_bug.cgi?id=12110
<ubot3> Malone bug 289356 in linux "ath9k causes system lockup" [Undecided,Confirmed] https://launchpad.net/bugs/289356
<ubot3> bugzilla.kernel.org bug 12110 in Wireless "ath9k causes computer to hang after long data transmissions" [Normal,Closed: code_fix] 
<rtg> jcastro: try LBM ? Its about as current as it gets
<jcastro> I don't actually have the problem, I am checking for someone, but I can recommend that
<dandel> apw, they asked for the log messages again lol. ( and it's already up there )
<rtg> jcastro: LBM is where the bulk of the upstream bug fixes are appearing. I'm only backporting or cherry picking critical stuff into mainline Jaunty
<jcastro> rtg: how far back do you go? I am trying to find if those fixes from kernel.org would be in say, intrepid
<jcastro> rtg: actually, if there is a page that shows me how to dig that up so I can learn how that would  be great, I don't mind doing the digging
<rtg> jcastro: hang on a sec, I'll find the changelog for Intrepid LBM
<rtg> jcastro: https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27 , compat-wireless updated as of March 4.
<jcastro> ok cool, I will recommend that then, thanks!
<rtg> jcastro: there is a bug report associated with LBM, so let smb_tp know if tehre are issues.
<jcastro> nod
<jcastro> rtg: ok so just so I understand it, at some point in the cycle you just start putting driver updates in LBM as opposed to the kernel we ship?
<rtg> jcastro: yep, the wireless updates tend to be inter-related
<jcastro> rtg: ok so then, if someone is having wireless problems then they should probably try lbm before reporting a bug.
<rtg> jcastro: that is what I'd _like_ them to do, but most folks don't know about LBM
<jcastro> yeah, I usually don't need anything in LBM so I haven't been following it
<jcastro> I'll bring it up to jono, perhaps there is something we can in the community to spread the word
<IntuitiveNipple> Can anyone tell me in what circumstances a network device can be active (IFF_UP) and in-use *but* its IFF_RUNNING flag is not set? Also, is it a valid state or a bug not to have IFF_RUNNING when IFF_ACTIVE *and* the interface is actually working? bug #335507
<ubot3> Malone bug 335507 in netspeed "netspeed applet will not measure wired" [Undecided,New] https://launchpad.net/bugs/335507
<rtg> IntuitiveNipple: IIRC those flags are set by the network layer. Its likely a bug for the driver to mucking about with those bits.
<IntuitiveNipple> apparently not. Just found an email about it on the linux-netdev mailing list in January from Marcel Holtmann caught out by the same thing. Apparently, now, it only is there to indicate userspace configured the interface
<rtg> huh, I haven't delved into the guts of a net driver recently.
<IntuitiveNipple> I know... it's one of those "it changed two years ago and no-one announced it" things
<IntuitiveNipple> http://kerneltrap.org/mailarchive/linux-netdev/2009/1/27/4827604/thread
<IntuitiveNipple> rtg: maybe you can save me some more head-ache. git. My local jaunty repo --references my local linux-2.6 repo. In the linux-2.6 repo are several remote references to track pre-mainline patches (e.g. x86-tip, linux-pci). In the jaunty repo I can "git show" a commit from any of the remotes, but I have so far not figured out how I can show *which* remote the commit is in - in other words, I need to identify which remote the commit is fro
<IntuitiveNipple> m. I've tried all manner of git-show and lower-level plumbing but so far not found a way to do it. Any ideas?
<rtg> IntuitiveNipple: ah, you might have to consult with my git expert apw. I've encountered the same issue occasionally.
<IntuitiveNipple> lol yeah... I burned a few fuses trying to figure it out last night :)
<rtg> IntuitiveNipple: I generaly get so many unused objects that I have to prune now and then
<IntuitiveNipple> My reason is just so when I cherry-pick I can give a reference as to where the h**l it came from :)
<apw> IntuitiveNipple, so you have a commit and want to know the head that its part of?
<IntuitiveNipple> apw: I'd like to see the remote name with icing on, yeah :)
<IntuitiveNipple> I figure being once-removed via the --reference linkage might make that difficult
<apw> IntuitiveNipple, git name-rev <sha1> tells you if the remote is in your current tree
<apw> if its --reference, then there is no way to know as the remotes don't exists in this repo
<IntuitiveNipple> hmmph
<apw> but the reference is local, so you can just cd there and run the same command right
<rtg> I usually 'git fetch' without adding a remote, so there is no way to know.
<apw> yeah thats cirtainly annoying
<apw> as remotes are basically zero cost i usually add one
<rtg> typically though, I'm applying a patch immediately, so its easy to remember the reference and put it in the commit log
<IntuitiveNipple> I don't want to add the same remote to several repos, that was the original plan, so one fetch on linux-2.6 is for all
<IntuitiveNipple> git name-rev a682604
<IntuitiveNipple> a682604 undefined
<apw> very linus of you
<apw> IntuitiveNipple, that was in the linus-2.6 tree?
<IntuitiveNipple> apw: no, the unbuntu-jaunty tree
<IntuitiveNipple> git name-rev a682604
<IntuitiveNipple> a682604 remotes/x86-tip/auto-sched-next~1^2~1
<apw> apw@dm$ git name-rev a682604
<apw> a682604 tags/v2.6.29-rc7~5^2
<apw> though it looks to be integrated into linus' tree now
<IntuitiveNipple> yeah, things move on. It's the general principle that would help me a lot.
<apw> what does git name-rev --all a6... say
<apw> oh miss understood
<IntuitiveNipple> The scenario is, I'm chasing some bug report, see some mailing-list mention of a patch that may help, search the repo for a commit that matches the patch, and try it. If it works, it'd be nice to be able to generate the patch (git format patch ...) and include the originating remote
<IntuitiveNipple> apw: git name-rev -all a... says "error: Specify either a list, or --all, not both!"
<apw> bah, useless
<apw> i assume its shown the nearest tip to the reference
<IntuitiveNipple> yeah, -all is an or with commit id
<rtg> IntuitiveNipple: If I'm cherry-picking, I always use the '-x' option. If its not frmo Linus tree, then I also add the git URL in the commit log.
<IntuitiveNipple> rtg: Yeah, I do that too. This is just a nice way for me to check where a patch came from. I'm juggling about 20 different bugs a day, so I flick between them based on inspiration or research, so when I finally find a patch that fixes something, I may have forgotten the context. It'd be nice to have one simple command to tell me :)
<apw> name-rev is about as close as it gets
<apw> it is possible to script round git merge-base to get all places its a member of
<IntuitiveNipple> apw: Yeah... I'll have to figure out a way to patch that to handle remotes
<apw> well its not remotes, its alternates
<IntuitiveNipple> or rather, references
<IntuitiveNipple> yes
<apw> though it printing out a reference which isn't available here is a bit strange
<IntuitiveNipple> From a user perspective it ought to be an option of git describe
<apw> so it'd never want to be normal behaviour
<apw> git describe is the opposite in some senses
<apw> its which tag is older than this commit
<apw> git name-rev is which tag head is newer than this thing
<IntuitiveNipple> or newer (--contains)
<apw> ahh yes, so name-rev must be being deprecated
<dandel> 0o
<IntuitiveNipple> ok, found a workable solution :)
<IntuitiveNipple> GIT_DIR=../linux-2.6/.git git name-rev a682604
<IntuitiveNipple> a682604 remotes/x86-tip/auto-sched-next~1^2~1
<IntuitiveNipple> Can script that nicely
<apw> IntuitiveNipple,  there is a path to the other stoer in .git/objects/info/alternate
<apw> or similar, you might use that in your script
<IntuitiveNipple> apw: Yes, that is what I'm doing... actually it has got quite sophisticated... It takes the pwd and <.git/objects/info/alternate and isolates the common path then builds a relative path from pwd to the alternate and inserts that into GIT_DIR
<apw> IntuitiveNipple, that seems overkill if the absolute path is there and is good
<IntuitiveNipple> apw: no, because I want it to work from any repo with any alternate
<apw> right, but i mean the absolute path is as good as a relative one
<apw> so why do you need to common prefix munch it?
<apw> apw@dm$ GIT_DIR=`cat .git/objects/info/alternates`/.. git name-rev a682604
<apw> a682604 tags/v2.6.29-rc7~5^2
<apw> why is that not always sufficient?
<IntuitiveNipple> I'm doing some other stuff with the scripts that is based on relative path portability, that's all.
<apw> ok
<IntuitiveNipple> I always try to generalise my scripts to cope with unanticipated future usage
<maxb> Hi, the lbm source builds an empty headers deb and an empty udeb. Is there a reason, or would a patch to stop building those be useful?
<rtg> maxb: Jaunty? its likely a hold-over from Hardy
<maxb> ah. Are they being retained in case of future need, do you suppose?
<rtg> maxb: well, I didn't do it with malice aforethought, but it _does_ seem like a good idea.
<rtg> in any case, it causes no harm
<maxb> Pointless things annoy me. Having ascertained that they are not actually pointless, I am happy :-)
<rtg> on second thought, it shouldn't even be building a udeb.
<rtg> its not seeded by the installer AFAIK
 * Nafallo wonders what happened with USB in Jaunty
<NCommander> Nafallo, ?
<Nafallo> it seems to default to USB1.1 or something? even for USB2 devices :-/
<Nafallo> at least my backup here is /dead slow/
<Nafallo> also copying data from my hardware RAID1 USB2 enclosure was ~600K/s at best.
<Nafallo> no idea how to debug this issue though
<JanC> uhm, I think that after an earlier boot into recovery mode a system restart shouldn't start recovery mode again...
<JanC> I guess this is because kexec gets handed the same boot parameters again...
<IntuitiveNipple> Nafallo: It's a general kernel problem. We've just published a resolution for it
<IntuitiveNipple> JanC: Yes... catches me out too :p
<JanC> wouldn't it be possible to do a complete reboot in case the "current" boot is based on a "recovery" option in grub?
<IntuitiveNipple> I think it is something the scripts should detect and handle. I think a check for 'single' in /proc/cmdline would do it
<Nafallo> IntuitiveNipple: awesome. ta :-)
<IntuitiveNipple> Nafallo: There's a workaround involving adding the USB modules in the correct order to the initrd, until the new kernel is in the archives https://bugs.edge.launchpad.net/linux/+bug/296710
<ubot3> Malone bug 296710 in linux "warning: ehci_hcd loaded AFTER uhci_hcd and ohci_hcd" [Medium,Fix released] 
#ubuntu-kernel 2009-03-18
<mjg59> Where's the LPIA LUM tree for hardy?
<mjg59> Ah, got it
<Kano> hi, could somebody add aufs to 2.6.29 branch?
<Kano> would be nice to have as squashfs is integrated to build a live image with it
<Chenkai1> Hi, i am new to Linux module programming and my first hello_world.ko under Ubuntu 8.04 didn't seem to work.  Following the guide at http://ubuntuforums.org/showthread.php?t=800251, the compilation seems fine but no output from console nor /var/log/messages.  Any one could help me?  thanks:)
<TheMuso> Kano: If you read Tim's email from the kernel team list, you will note that some ubuntu drivers have been disabled, aufs is likely one of those. I suggest if you want it ASAP, you help in getting it fixed/updated.
<Kano> i did not read a mail,but i see the git log
<maco> TheMuso: the git repo Tim's mail pointed to has 2.6.29-rc8. does that mean karmic = 2.6.29? or is 29/30 undecided at the moment?
<TheMuso> Kano: I think the final version is undecided
 * maco assumes that was at me
<maco> ok
<TheMuso> Kano: oops sorry
<TheMuso> maco: yeah misread
<dtchen> last sentence in "Kernel Version" at http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html
<Kano> bye
<cooloney> smb_tp, i switch here for a question about git clone
<smb_tp> sure
<cooloney> how can i git clone all the branches of a remote git tree
<cooloney> not just one master branch
<smb_tp> You normally do somewhat
<smb_tp> if you do a "git branch -a" you would see them
<smb_tp> you then can create one with "git branch <localname> origin/<name>"
<cooloney> ok
<cooloney> then git pull origin name
<cooloney> right
<smb_tp> then "git checkout <localname>" or probably "git checkout -b <localname> origin/<originname>"
<smb_tp> which would save you one step
<smb_tp> you don't need to pull. When you clone you get all the objects
<smb_tp> It just does not create the local branchnames
<cooloney> ok, i fully understand
<cooloney> ikepanhc, you may try on you side 
<ikepanhc> oh, got it
<cooloney> i will try it on my side. actually, this problem frustrate me a lot
<cooloney> smb_tp, actually this is a little bit difficult to understand, we assume _clone_ means copy everything
<cooloney> and git branch, git checkout should be ok default
<smb_tp> well, I think of it as git clone makes a complete copy of the repository objects, plus it conveniently checks out the origin/master as master
<smb_tp> and makes a local branch for it as well
<smb_tp> apw, Can you describe that better?
<apw> thats pretty accurate
<cooloney> git just does not do create a local branch from origin/<branch>, only master
<smb_tp> AFAIK, yes
<cooloney> ok, i see
<apw> the master thing is a convienience
<apw> you can and do checkout other branches from a remote
<apw> clone checks out the HEAD branch from the remote, which is normally master
<apw> and it does that because a repo with no branch checked out is confusing
<smb_tp> iirc, you run into that situation when you create an empty remote and then push things over. before you checkout anything it looks just empty
<apw> right
<apw> git clone is equivalent to
<apw> mkdir foo; cd foo; git init; git remote add origin <url>;  git fetch origin; git checkout -b master origin
<IntuitiveNipple> brain-boost-needed: I'm *sure* we recently had a bug where there are random delays during boot for which I found/saw a new upstream patch that reworked the RCU 'idle' scheduling during boot. Trying to find it now I've drawn a blank. Does it ring a bell with anyone else?
<IntuitiveNipple> Ha, thank-you Mr Invisible Man, that worked... found it... bug #254668
<ubot3> Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] https://launchpad.net/bugs/254668
<smb_tp> IntuitiveNipple, yeah that was one of them
<IntuitiveNipple> I've got another bug that might be the same one, but it's been trailing on an Nvidia MCP67 issue
<smb_tp> I see you found bug 272247 as well
<ubot3> Malone bug 272247 in linux "System freezes during boot, unless I hold a key down" [High,Fix released] https://launchpad.net/bugs/272247
<IntuitiveNipple> Yes, I'm seeing quite a few issues with MCP67 so thought it might be good to disambiguate them
<IntuitiveNipple> There's some sign of AHCI data-loss with the MCP67 but only on Ubuntu... haven't found any noise upstream along the same lines so far.
<smb_tp> Yes, there seemed to be a few on HP / amd machines. But also a few between the lines with intel cpu's
<smb_tp> there is also bug 217849
<ubot3> Malone bug 217849 in linux "Hardy 64-bit beta and nightly alternate installation stalls" [Critical,Incomplete] https://launchpad.net/bugs/217849
<smb_tp> which is slightly different
<smb_tp> For some it helped only to go for clocksource=jiffies
<smb_tp> Other needed to get around acpi irq routing
<IntuitiveNipple> Yeah, I remember that one. I was wondering out loud if it had to do with the bounce-buffering
<smb_tp> right. i remember now
<IntuitiveNipple> The upstream commentary on the RCU scheduled idle during boot patch looks like it covers a lot of bug reports
<smb_tp> Generally it seemed like loosing irqs or going into a sleep state without a correct trigger to wake
<IntuitiveNipple> do you know if anyone here has tried backporting the RCU patch? If not, I'll give it a go?
<smb_tp> Not to my knowledge
<IntuitiveNipple> OK. I'll see what it takes
<smb_tp> Ok, cool
<IntuitiveNipple> Seeing as it could wipe a fair few niggles out
<smb_tp> Fixing that would sure make a lot difference
<IntuitiveNipple> It'll need some munging to make it apply... I'll do some poking
<IntuitiveNipple> Hmmm... this RCU patch. One of the conflicts is a file that doesn't yet exist in Jaunty but does in linux-2.6, and is amended It adds an inline function declaration. What would be the procedure for including its contents? 
<smb_tp> IntuitiveNipple, if the change introducing the file/inline is just a moving around of files mostly, then probably pull the patch that created it
<smb_tp> Otherwise we probably just want the inline...
<IntuitiveNipple> Unfortunately, it's based ona major rework of the entire RCU code... since Jaunty RCU moved to a tree-based system. I'm carrying on but not sure the back-port will be possible in the end
<IntuitiveNipple> I'll let that one stand for now and sort out all the content-conflicts... if those can be done, then I'll have to revisit this
<smb_tp> Ok, thanks.
<apw> maco, hey ... how is your asus acpi driver going
<maco> apw: backburnered. trying not to fail my compilers class.
<apw> heheh, always the way
<rtg> always a good plan
<maco> which...er...right...i should probably get back to yacc
<apw> did that use to work on intrepid
<maco> no, those keys never worked
<apw> ok cool.  so its not a regression at least
<maco> well i never ran intrepid on here. but they didnt work in hardy
<_ruben> probably offtopic .. but does anyone have any clue wrt to the WARNINGS shown here: http://paste.ubuntu.com/132986/ .. those symbols are part of another (same 3rd party) kmod
<rtg> _ruben: do you have that kernel installed (I assume you do), e.g., lib/modules/2.6.27-11 ?
<_ruben> rtg: yes
<_ruben> (its within a pbuilder chroot btw)
<_ruben> i think on an earlier attempt i "fixed" it taking the Module.symvers file from the scst.ko along with its header files, but DKMS doesnt give me such a file (at first sight atleast)
<rtg> _ruben: right, these are benign warning because no modules.dep exists for these symbols at MODPOST time (Ithink()
<_ruben> rtg: i get similar errors when i modprobe iscsi-scst.ko
<rtg> _ruben: so, you're saying its not working and the warnings are not benign?
<_ruben> http://paste.ubuntu.com/132991/ .. thats when i modprobe them 
<rtg> _ruben: you must be missing  one of the files in the link or compile. find out where scst_single_seq_open exists and make sure its getting compiled.
<_ruben> toghether with: 
<_ruben> # modprobe iscsi-scst
<_ruben> FATAL: Error inserting iscsi_scst (/lib/modules/2.6.27-11-server/updates/dkms/iscsi-scst.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<_ruben> rtg: its within scst.ko iirc .. let me double-check
<IntuitiveNipple> Has "scst" been built and installed against the same kernel version? It looks as if its symbols aren't present.
<_ruben> rtg: strings shows scst_single_seq_open is present within scst.ko .. is there some tool to show whats being exported from a certain kmod
<_ruben> IntuitiveNipple: yes .. both built using dkms against 2.6.27-11-server
<rtg> _ruben: make sure its in an EXPORT_SYMBOL macro in the source
<_ruben> rtg: let me check that
<_ruben> src/scst_proc.c:EXPORT_SYMBOL(scst_single_seq_open);
<rtg> _ruben: hmm, can you build it by hand using " make -C /lib/modules/2.6.27-11/build M=`pwd` " ?
<IntuitiveNipple> Does this show them? grep -in scst_register /lib/modules/2.6.27-1/modules.symbols 
<IntuitiveNipple> oops typo!
<IntuitiveNipple> Does this show them? grep -in scst_register /lib/modules/2.6.27-11/modules.symbols 
<rtg> IntuitiveNipple: I think that symbol is part of the module that he's building.
<_ruben> # grep -in scst_register /lib/modules/2.6.27-11-server/modules.symbols 
<_ruben> 621:alias symbol:__scst_register_virtual_dev_driver scst
<_ruben> 1423:alias symbol:__scst_register_target_template scst
<_ruben> 2298:alias symbol:__scst_register_dev_driver scst
<_ruben> 2673:alias symbol:scst_register_session scst
<_ruben> 3297:alias symbol:scst_register scst
<_ruben> 4694:alias symbol:scst_register_virtual_device scst
<IntuitiveNipple> No, it's part of scst not isci-scst
<rtg> IntuitiveNipple: ah, missed that
<IntuitiveNipple> OK, so, the build process isn't 'seeing' them via DKMS
<_ruben> IntuitiveNipple: sounds about right, yeah
<_ruben> it isnt dkms specific though, m-a has the same
<IntuitiveNipple> Is there a custom Makefile for that module?
<_ruben> just got a reply from upstream:
<_ruben> 1. If you don't have SCST core's Module.symvers, you will see complains 
<_ruben> on the MODPOST build stage. As you can notice, the Module.symvers is 
<_ruben> installed during SCST core installation in /usr/local/include/scst 
<_ruben> together with other SCST headers.
<_ruben> 2. Since iscsi-scst.ko depends on scst.ko, you must have the correct 
<_ruben> version of scst.ko installed, when you trying to load iscsi-scst.ko. 
<_ruben> "Correct" means built with the same SCST headers for the same kernel as 
<_ruben> iscsi-scst.ko.
<IntuitiveNipple> ha!
<rtg> that would definitely explain it
<_ruben> so i gotta convince DKMS to take care of the symvers file i guess?
<IntuitiveNipple> we knew the what but not the why
<IntuitiveNipple> In src/scst/Makefile the install: target does "install -m 644 Modules.symvers $(INSTALL_DIR_H)"
<_ruben> correct, but dkms doesnt call make install i think?
<rtg> apw: are you done with checkbox then?
<apw> checkbox is done as far as i can tell
<apw> i am waiting for the publisher to download it
<rtg> apw: ah, that reminds me to check on our new ABI kernel
<rtg> kewl, someone has already NEWed it
<rtg> apw: when you build checkbox on your PPA, do you only get i386 ?
<IntuitiveNipple> smb_tp: Good news. The RCU back-port looks to be good. The Tree RCU fragments aren't required since there is no Tree RCU until 2.6.29.
<smb_tp> Sounds cool. If you drop the patch to the mailing list I'll see to get a kernel build
<_ruben> hmm .. perhaps a POST_BUILD= entry in DKMS can be used
<apw> rtg yeah, its all 'all' code, all python
<IntuitiveNipple> smb_tp: Will do. I'm doing a build and install test on it first
<rtg> apw: hmm, I'm just not used to seeing packages only appearing in one ARCH
<smb_tp> IntuitiveNipple, Ok
<apw> yeah when its an all it does that
<apw> its that mad all == any one and any means all of them
<rtg> doesn't seem ortogonal
<rtg> orthogonal, even
<apw> its completely mind bending
<apw> in better news the script is in the package and seems to work
<rtg> apw: good, that was really my only goal.
<apw> indeed, just running a real life test
<soren> rtg: "archictecture: all" packages only get built on i386, but are published in all architectures.
<rtg> soren: just one of those funny inconsistencies in the archive
<soren> Ah, apw already pointed that out.
<apw> really it should have been all -> indep and any -> all
<IntuitiveNipple> 16-core Itanium 2 system for Â£999 ... is it worth it as a build server?
<elmo> 16 cores for 1K?
<elmo> that sounds like it's off the back of a lorry
<elmo> and not in a good way :-P
<rtg> IntuitiveNipple: and what do you do with ia64 anyway?
<IntuitiveNipple> elmo: Yeah, I was wondering the same thing myself! I'd just looked at another for Â£24.5k :)
<IntuitiveNipple> rtg: To play with, of course!
<rtg> expensive toy
<elmo> itanium's are only 2 cores per socket, right now, AFAICR?
<IntuitiveNipple> all the best toys are :)
<elmo> if so, that's an 8-socket machine.  which would make it *very* expensive to run, and likely *very* noisy too
<IntuitiveNipple> 2 cores, 2 hyperthreads
<IntuitiveNipple> elmo: It'd be banished to the garage like the PowerEdges
<elmo> ah, well, if you have somewhere for it.  I dunno, my experience with Itanium's is with older machines
<elmo> but unlessimproved vastly, the only thing going for that box would be the 16-wayness.  because core to core, a decent Xeon or even Opteron will outclass an Itanium like nobody's business
<IntuitiveNipple> I was looking for one with VT support
<elmo> s/unlessimproved/unless they've improved/ (woo, typing on a loaded box)
<IntuitiveNipple> Yeah... same here... It'd make a great buildd for the kernels
<IntuitiveNipple> But, that price... and 'cash only' makes me think... oh well *sigh* too good to be true
<_ruben> grr .. gotta love being pulled into a meeting unexpectedly .. back to my scst/dkms endeavour :p
<IntuitiveNipple> is there a make rule to easily build/install the /boot/vmcoreinfo* files from a quick-build ?
<maco> rtg: around?
<rtg> maco: in 20 mins or so. on conf call right now
<maco> ok
<rtg> saw you k-t list email
<rtg> your*
<maco> ah ok then nvm
<IntuitiveNipple> ok, got it: KVER=2.6.28.8; sudo makedumpfile -g /boot/vmcoreinfo-$KVER -x ../builds/vmlinux
<ernstp> IntuitiveNipple: still haven't seen the bug with an ext3 filesystem.. will leave it running overnight today
<ernstp> IntuitiveNipple: if you remember, the MCP67/achi bug
<IntuitiveNipple> which bug is that? I loose track :)
<IntuitiveNipple> oh, yeah.... I'm actually looking at some patches for that issue atm
<ernstp> IntuitiveNipple: cool
<ernstp> IntuitiveNipple: had dpkg running on Intrepid userland on ext with 2.6.28 from the mainline archive for an hour, nothing happened
<ernstp> IntuitiveNipple: ext3 that is
<ernstp> IntuitiveNipple: Jaunty userland, 2.6.28-10 and ex4: 5 minutes dpkg and boom
<ernstp> IntuitiveNipple: if you want some info from the system after it's happened I can probably recreate it pretty quickly
<IntuitiveNipple> Could it really be an ext4 issue? I can't think how the file-system could cause that in the controller... but anything's possible
<rtg> ernstp: cat /proc/version_signature, some ext4 patches were applied in -10.32
<ernstp> IntuitiveNipple: well ext4 has much better performance I guess, bigger writes with delayed allocation, so maybe something... ? :-)
<ernstp> rtg: got 10.32
<IntuitiveNipple> rtg: bug #343919
<ubot3> Malone bug 343919 in linux "Nvidia MCP67 AHCI ata timeout exception with data loss" [Medium,In progress] https://launchpad.net/bugs/343919
<ernstp> rtg: but it should really be an "ahci" driver issue and not ext4 related
<rtg> ernstp: ah, I just saw ext4 in the recent scroll-back
<IntuitiveNipple> what bothers me is each error on whichever kernel is during ext4 journal work: "ext4_journal_start_sb: Detected aborted journal"
<ernstp> but I've only ever seen it on ext4 so far
<IntuitiveNipple> I've noted it on the bug... another avenue to examine
<ernstp> but as I said, I'll leave dpkg running on an ext3 filesystem during the night today
<ernstp> while true; do dpkg -i wesnoth*; done
<ernstp> IntuitiveNipple: Ted Ts'o can take a look at it :-)
<Kano> hi rtg , could you fix the aufs module first? thats needed to try the 2.6.29 kernel in live mode
<rtg> Kano: Karmic is a background task, so I'll get to it eventually. I've still got to get Jaunty released.
<Kano> well, there are systems which do not like 2.6.28
<Kano> one asrock x58 board has some issues
<Kano> therefore i want to check with 2.6.29
<rtg> Kano: use the mainline build on http://kernel.ubuntu.com/~kernel-ppa
<Kano> rtg: i need aufs!
<rtg> then you're gonna have to do it yourself
<Kano> squashfs is in the kernel now
<mjg59> cking: Wow. That hpmini driver is special.
 * cking nods
<cking> ..ultimately a generic solution for ICH7 chipsets should be looked at for saving power on the wake alarm
<mjg59> cking: Why not just have the kernel call acpi_disable_event(ACPI_EVENT_RTC) if there's no alarm set?
<Keybuk> kees: if we move over here, we can say rtg a lot and he'll fix it
<cking> mjg59: the driver turns off the power to the wake alarm mechanism - it's more of a low level ICH7 tweak to save power.
 * Keybuk wonders what happens if you say it three times
<Keybuk> rtg
<Keybuk> rtg
<Keybuk> rtg
<Keybuk> :p
<cking> and ping too
<mjg59> cking: It looks like it's just writing to the PM registers, which is what acpi_disable_event does
<cking> ..is this dependant on the BIOS doing things right?
<mjg59> No
<kees> Keybuk: you weren't standing in front of a mirror when you said it
 * cking goes to look at acpi_disable_event more deeply
<rtg> you guys quite hassling me. I'm packing boxes.
<maco> wow, the combination of Keybuk highlighting, cking adding ping, and mjg59 saying 'PM' made mjg59's sentence confusing
<Keybuk> rtg: are you going somewhere? :p
<rtg> no, sending computers to germany and Mississippi
<kees> Keybuk: oh the irony: config SECURITY_DEFAULT_MMAP_MIN_ADDR ... default 0
<Keybuk> kees: well, yes
<rtg> Keybuk: why are you bugging me? is SECURITY_DEFAULT_MMAP_MIN_ADDR the reason?
<Keybuk> rtg: for your scrollback pleasure
<Keybuk> it is
<Keybuk> arch/x86/configs/i386_defconfig:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
<Keybuk> vs.
<Keybuk> debian/config/i386/config:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
<rtg> Keybuk: ok, gimme 10 minutes or so, I've got a pickup deadline
<Keybuk> vs.
<Keybuk> /etc/sysctl.d/10-process-security.conf:vm.mmap_min_addr = 65536
<Keybuk> ie. if we didn't override the config option back to zero in our kernel config, and used the x86 arch default, we wouldn't have to override it back to 64k in userspace via sysctl
<kees> rtg: however, it seems that ARM needs to be 32768.
<kees> according to the Kconfig help text, anyway
<kees> ia64, ppc64, x86: 65536, all others: 32768
<kees> where x86 means x86 and x86_64
<rtg> kees: I though that used to be 0. it certainly was in Intrepid
<rtg> thought*
<kees> rtg: right, upstream changed the defaults.
<rtg> oh, you want it set to 64k?
<rtg> ok, can do.
<kees> rtg: yeah.  it looks like it isn't set as a default for other archs in the kernel.
<Keybuk> rtg: just left at whatever the arch default is I guess
<Keybuk> do we not inherit from arch/*/configs/*_defconfig ?
<rtg> Keybuk: not really, unless we start from scratch
<kees> rtg: so, flipping it to 64k (x86, ppc, ia64) and 32k (others) is the way to go
<rtg> is there an LP?
<kees> Keybuk: it seems that some archs don't have a default yet upstream
<ogra> rtg, can you please set CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=32768 for ARM (higher values dont work on arm)
<rtg> ogra: can do :)
<ogra> thanks a lot :)
<rtg> ogra: why is it that not all of the ARM flavours have this option?
<ogra> up to now we have set it from /etc/sysctl.d/10-process-security.conf so it sisnt matter at all
<ogra> *sisnt
<ogra> gah
<ogra> didnt
<ogra> upstream now uses CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536 ...
<ogra> but that breaks on arm
<ogra> the help of SECURITY_DEFAULT_MMAP_MIN_ADDR says "On arm and other archs it should not be higher than 32768."
<rtg> kees: did you say you had started an LP bug on CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR ?
<ogra> and i just verified that setting vm.mmap_min_addr = 32768 works fine (while 65536 breaks in intresting ways)
<kees> rtg: I will open one.
<rtg> kkesits not really necessary, just wanted to be sure to get the LP# in the commit if it existed
<kees> ogra: yeah, I was discussing the fixes here with rtg before you joined
<ogra> ah, k
<rtg> kees: ^^ (can't type today)
<kees> rtg: right, I'd like it so I can follow it with procps changes to address it.
<rtg> np
<ernstp> IntuitiveNipple: 1 hour no problem with 2.6.29-020629rc8-generic, ext4, jaunty. don't think 1 hour is enough though
<Kano> rtg: you can remove the squashfs part in ubuntu dir on 2.6.29
<Kano> it is inside the kernel
<kees> rtg: bug #344955
<ubot3> Malone bug 344955 in linux "CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR needs to be set" [High,In progress] https://launchpad.net/bugs/344955
<IntuitiveNipple> ernstp: If it doesn't fail then we'll have to hunt the commit(s) that fix it
<ernstp> IntuitiveNipple: lol, just because I wrote that it failed!
<kees> rtg: once that's in a published kernel, I will fix procps.  :)
<ernstp> IntuitiveNipple: same message as usual
<ernstp> reboot :-)
<ogra> kees, i would call it "high" or even critical for procps ... it breaks ARM completely atm
<ogra> (i.e. prevents us from building functional images)
<kees> ogra: right, though it will be fixed very soon in the right place.
 * ogra hopes so, i need to start building images for imx51 asap
<ogra> *before* the beta freeze
<kees> ogra: are there any arm-specific packages?  You could put a 12-arm-mmap-min.conf into /etc/sysctl.d/ that sets it to 32k until the kernel is fixed?
<ogra> sadly there arent ... 
<ogra> but i'll try to hack around it in an image build script 
<kees> ogra: there isn't anything easy in the build script, I can try to teach procps about the arm-specific stuff.  I'd rather wait just to avoid needing to clean up conf files, etc.
<ogra> yeah
<ogra> well, since i'm about to write the build script ther *will* be :)
<ogra> if i want it 
<ogra> we dont have the script i'm talking about yet (i wanted to write it today, but the bug was in my way)
<amitk> rtg: are you on the SECURITY fix for the day?
<amitk> or do you want me to look at it?
<ogra> wow, he's fast
<ogra> 16min from reported to fix committed status for 344955 :)
<amitk> hehe...
<rtg> ogra: I have this amazing hoover that builds _really_ fast
<kees> rtg: is that the one you were replacing the mainboard in last week?
<ogra> heh
<amitk> ogra: I'll push the rest of the changes to imx51 before I got to bed. Then badger rtg for an upload ;)
<cking> mjg59: yep - I've familiarised myself with the ACPI code now.  A generic solution is that acpi_disable_event(ACPI_EVENT_RTC) before hibernate if the wake alarm is not set
<ogra> yay
<rtg> kees: yep, then I added 4 spindles for raid0
 * kees drools
<ogra> amitk, btw, my USB NIC works fine now ... 
<ogra> makes the babbage a breeze
<amitk> ogra: it better! The imx51 is a bloated beast right now 
<ogra> but works fine :)
<ogra> i shall try my ton of different USB devices the next days 
<mjg59> cking: Yes, that sounds sensible
<mjg59> cking: Probably for S3 as well as S4
 * cking nods. It will save several mAh in hibernate that's for sure
 * cking investigates cmos_suspend() et al
<mjg59> cking: I think you mean several mA :)
<cking> yep. 
 * cking wonders why this is not done already
<rtg> amitk: so, you're gonna drop some ARM patches on me?
<amitk> rtg: where are you uploading?
<amitk> rtg: *when
<rtg> amitk: anytime you're ready. end of my day is in about 90 mins, but I can do it later tonight as well
<amitk> rtg: then let's not rush it. I've had a long few days. I'll finish up the configs _and_ look at d-i tomorrow morning ready for you to upload when you start.
<rtg> amitk: in that event I'll upload anyway so kees can get his procps security fix out of the way
<amitk> rtg: then let me just push the imx51 config changes. I'll fix d-i later
<amitk> gimme 30mins
<rtg> k
<lime_> hi
<lime_> how i can let ubuntu 32 bit see 4G ram?
<ubot3> lime_: Error: Could not parse XML returned by Ubuntu: not well-formed (invalid token): line 338, column 84
<rtg> lime_: install the -server kernel
<lime_> i did that but still not seen !
<rtg> lime_: depending on your chipset, you may only see a bit more then 3Gb
<lime_> in the Bios it show 4G , it is dell laptop xps m1210 
<rtg> apw: your 'hotkey quirks for various Zepto Znote and Fujitsu' would be easier to cherry pick into Karmic if you pushed it to Jaunty
<apw> hrm
<rtg> apw: also, I have to admit I didn't read you original email correctly.
<rtg> lime_: the other alternative is to run the 64 bit kernel and user space.
<apw> rtg that commit should be on the jaunty repo, its the third commit against my origin/master -- baad507a2aca0f997f01f964e03f79c4ec622cf4
<rtg> huh, sure is. I searched for the log message in the email and didn't see it.
<rtg> apw: sorry for the noise. go back to your beers.
<amitk> rtg: cross compile for entire armel will take ~1hr45m. Are you going to do it in any case?
<rtg> amitk: yep
<rtg> takes about 10 mins
<amitk> rtg: then I won't. You'll have to fix abi issues if any for the other flavours. I am marking imx51 as ignore
<rtg> amitk: np
<apw> rtg beers i wish
<rtg> apw: what, you run out?
<apw> yeah have to go buy some before i can start, how fair is that
<rtg> apw: so, what should I do with the EC2 pile from Chuck?
<apw> there are some integration issues i believe just in terms of whether we need a branch or not for this thing
<apw> i was going to review them properly tommorrow am and report back
<apw> overall the look reasonable, just these niggles on how we get them into our tree without breaking it
<amitk> rtg: patch pushed.
<amitk> bradF: yes. How can I help you?
<bradF> i have aufs building now (that's the good news)
<bradF> amitk: i have aufs building now (that's the good news)
<bradF> amitk: will need to do some fencing in unionfs to support the old api
<bradF> amitk: ixp4xx doesn't enable AA but does use NFS so there would need to be fencing done there (the bad news)
<bradF> amitk: still want to proceed?
<bradF> amitk: larger issue is that any fs which is enabled for either ixp4xx or imx51 will probably need fencing done
<lime_> from here I can enable HIGH_MEM option?
<rtg> lime_: which will force PAE
<amitk> bradF: that sounds like a much larger project
<amitk> bradF: do you mean to say that we've applied apparmor patches to our kernel in such a way that it is very hard to turn off AA now?
<bradF> amitk: yes
<amitk> rtg: ^ perhaps something to keep in mind if you haven't already applied AA for Karmic
<rtg> amitk: AA was one of the first commits that I dropped
<lime_> rtg, yes how ?
<amitk> \o/
<amitk> we really should not be this tightly coupled to AA. Who knows if we want to move to SELinux someday
<sbeattie> Eh? you're only tightly coupled to the vfs hook changes. selinux (kernel portion) works now.
<amitk> rtg: its your call for Jaunty. Should bradF continue decoupling it? It seems the AA _might_ work after all
<amitk> sbeattie: not being able to compile the kernel without AA is very tight coupling IMO
<sbeattie> amitk: with AA disabled or without the AA patches?
<amitk> sbeattie: not necessarily a problem of AA perse, but the way the patches are applied
<rtg> amitk: well, I never was in favor of disabling AA. Have you found the source of your AA crash?
<bradF> amitk: should I start looking at that the oops that started this? don't know what progress I'll make but I can start.
<amitk> rtg: no, we haven't found the reason for the oops. But I think the MMAP_MIN_ADDR might have something to do with it
<rtg> that would be nice if it really is the case.
<bradF> amitk: interesting!
<sbeattie> hrm, the oops backtrace I saw was on the kernel trying to execve /sbin/init, long before the MMAP_MIN_ADDR stuff gets applied.
<amitk> bradF: fixing the oops is still a worthwile goal. That will allow us to enable AA for all arm flavours
<bradF> amitk: so, I should stop further work on the AA changes and concentrate on the oops?
<rtg> bradF: I suggest you put everything you've done to date on  a branch in case we have to come back.
<bradF> rtg: can do
<amitk> bradF: yes
<bradF> amitk: works for me
<amitk> AA upstream would still be interested in that problem being fixed. It seems like it is the first time someone's run AA on ARM arch
<rtg> bradF: do you get serial console? It may be one of those printk until you find it bugs.
<amitk> amitk &
<bradF> rtg: yes to serial console
<rtg> bradF: ok, rinse and repeat :)
<ernstp> IntuitiveNipple: 5 hours constant dpkg on ext3 with a 2.6.28 kernel, nothing
<IntuitiveNipple> ernstp: poor ext4 :( looks like the finger is pointed its way although I still don't see how the file-system can be implicated, unless it provokes some sequence of events that the particular controller/disk combination doesn't like
<ernstp> IntuitiveNipple: yeah, it's really wierd...
<ernstp> IntuitiveNipple: userland shouldn't matter right?
<IntuitiveNipple> if it's an indirect linkage, anything could cause it
<rtg> I'm pounding my ext4 file system.
<ernstp> IntuitiveNipple: so I've got the exact same mainline kernel build of 2.6.28.7 installed on a Jaunty partition with ext4 and an Intrepid partition with ext3
<IntuitiveNipple> maybe the way ext4 tries to line up accesses in your case is significant.
<ernstp> IntuitiveNipple: the very same kernel. nothing on ext3, happens on ext4
<ernstp> sounds fun to debug
<ernstp> one difference is more /etc/sysfs.conf
<ernstp> devices/system/cpu/cpu0/cpufreq/scaling_governor=performance
<IntuitiveNipple> rtg: off hand do you know who's responsible for the nvidia DKMS package scripts? Is it 'kernel-team' or someone else?
<ernstp> I'll enable that on the other and leave it running tonight
<rtg> Alberto Milone, can't think of his nick
<IntuitiveNipple> OK, thanks
<IntuitiveNipple> I just found the default DKMS doesn't work against a manually installed kernel, took me a while to figure out how to sort it out, would be nice if it could work for both packaged and manual installs
<rtg> IntuitiveNipple: gimme a sec to track him down.
<rtg> IntuitiveNipple: alberto.milone@canonical.com, tseliot is his nick
<IntuitiveNipple> It's okay, I'll email him
<IntuitiveNipple> yeah, that's the one :)
<Kano> IntuitiveNipple: usally it does when you boot a new kernel
<IntuitiveNipple> Kano: It can't in this case, that's the thing, since one of the include files it uses in a build-test app isn't where it is expected
<IntuitiveNipple> with a manual install the out-of-tree build dir is linked from ./build and the source is ./source
<IntuitiveNipple> I had to play with reversing SYSSRC and adding SYSOUT to dkms.conf to figure it out
<Kano> well they are expected at the standard postition
<IntuitiveNipple> The Linux kernel modules_install and the Ubuntu linux-headers do different things... it would be nice if the DKMS package can cope with both
<Kano> was this link /lib/modules/$(uname -r)/build correctly set?
<IntuitiveNipple> ./build/ links to the out-of-tree build directory, which doesn't contain linux/utsname.h (that's in ./source/include/)
<IntuitiveNipple> I'll figure out a munge tomorrow, now I have it working 
<Kano> here it is in include/linux/utsname.h
<Kano> not in your linux version?
<Kano> well it is in the ubuntu packages at that place at least ;)
<Kano> even in 2.6.29
<IntuitiveNipple> For packaged headers it's in ./build/include/linux/ but for out-of-tree kernel builds installed using the kernel's own make modules_install it's in ./source/include/linux/
<Kano> so will test my aufs hack
<marijus> will there be 2.6.29-rc kernels with kms support build for the mainline kernel ppa? 
<erle-> are the virtualbox kernel modules packaged with the "restricted modules"?
<TheMuso> erle-: no. What version of Ubuntu are you using?
<erle-> 8.10
<TheMuso> I think for 8.10 the virtualbox modules are built using dkms, but don't hold me to that.
<erle-> i removed the restricted modules a few days ago
<erle-> and now i see that there is no more vbox module
<erle-> i think it is packaged there
<erle-> and i think that has to be fixed!
<TheMuso> Well I could be wrong, but I didn't think it was.
<erle-> TheMuso, can you please look up?
<erle-> i cannot because the package is not installed
<TheMuso> Alright, one second.
<TheMuso> erle-: you want virtualbox-ose-source
<erle-> TheMuso, i don't think so
<erle-> there is a precompiled kernel module shipped
<erle-> why should i build my own?
<erle-> the source is nice for people with custom kernels
<IntuitiveNipple> erle: "This package provides the binaries for the Open Source Edition of
<IntuitiveNipple>  VirtualBox. The virtualbox-ose-source package is also required in order to
<IntuitiveNipple>  compile the kernel modules needed for virtualbox-ose"
<TheMuso> erle- In that case, I don't know. I suggest you ask in #ubuntu-motu since there you will find the people who maintain it.
<erle-> hm
<erle-> i know that it worked before without custom module building
<erle-> now i am confused
<erle-> i will investigate and inform you
<erle-> sorry, my fault, everything fine again
<erle-> he seems to compile the modules from source on demand
<erle-> thank you for your support and sorry :)
<TheMuso> erle-: thats ok, it can be confusing if you don't know where the modules come from.
<erle-> yeah, its just because i removed the one module package and thought that's the reason
<TheMuso> yep
#ubuntu-kernel 2009-03-19
<maxb> Booting intrepid-proposed's kernel, I get the boot hanging at: udevd-event[2606]: run_program: '/sbin/modprobe' abnormal exit
<maxb> Can anyone point me at any relevant debugging options that might help deterimine why?
<maxb> thanks
<anubhav> you can boot the kernel with "debug" parameter.That will provide you with more info.You can use grub to add parameter to the kernel command line
<smb_tp> I wonder whether changing udev debugging level in the conf and recreating the initrd for the new kernel from an older one also brings more ingo. Sounds like some module could not get loaded and after it hangs maybe an important one. Also removing quiet from the grub line might be a good idea
<maxb> smb_tp: sounds good, /etc/udev/udev.conf, udev_log="debug" ?
<smb_tp> maxb, That can give a lot of output. If that is too much maybe "info". Maybe going from the kernel options via info to debug...
<maxb> On an unrelated note, having tagged an lbm bug regression-proposed, is there anything else I should be doing also?
<smb_tp> Can you quickly point to it? Then I have a look
<maxb> bug 337929
<ubot3> Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Undecided,New] https://launchpad.net/bugs/337929
<maxb> eek, yeah that's a lot of udev spew. /me tries info
<smb_tp> maxb, The bug seems to be complete afaics. If there are questions we surely will ask
<maxb> ok, just checking I wasn't supposed to report potential regressions in proposed anywhere special
<smb_tp> Just in the sense of "we have to get this fixed before it moves to updates". It might pop up on certain screens to have a look at
<maxb> oh, guh
<maxb> my modprobe error was the ath5k BUG-ing :-)
<smb_tp> eh, so likely related to the bug
<apw> smb_tp, thats odd ... i would expect ieeee80211_regdome to simply cause the module to fail to load ... we have a bug on that too
<smb_tp> I would be thinking that if the module causes an oops, then strange things can happen to the modprobe as well...
<apw> modprobe may well hang for ever, and no more modprobes be possible
<smb_tp> and that is what seems to happen
<apw> it sounds a lot like the kernel and lbm there are out of sync in terms of the config options for REGULATORY domain
<apw> the variable that those ieee80211_regdom= things point to is no longer there in our latest kernels
<apw> as we have CRDA enabled instead
<smb_tp> It could be. Though for intrepid this should behave the old way (and certainly not oops)
<apw> yeah it should.  but just check it not the same package
<smb_tp> yeah. I thought both were updated to the same compat-wireless master ...
<smb_tp> but i have to check
<smb_tp> I see. Intrepid should be at 2009-03-04, Jaunty at 2009-03-17
<smb_tp> maxb, the dmesg on the bug is for Jaunty it seems. Could you add one for Intrepid as well?
<maxb> sure
<maxb> err
<maxb> On intrepid the failure mode somehow manages to be different such that it doesn't end up in /var/log/ there :-/
<maxb> this may be a bit more difficult
<maxb> here I go rebooting, let's try it again
<Keybuk> amitk: your change is good
<Keybuk> I think I asked Ben to do that years ago
<Keybuk> but he bitched :p
<Keybuk> it means I can eliminate a tiny bit of the udev init script as well
<amitk> Keybuk: I tripped across it while going over the entire config for the babbage
<amitk> Keybuk: though I don't this the actual impact is measurable
<Keybuk> it's just nicer
<amitk> s/this/the
<amitk> yes
<amitk> Keybuk: could you please ack it then?
<Keybuk> amitk: I've replied with a Signed-off-by line of my own
<amitk> thanks
<cking> Any idea why CONFIG_RTC_DRV_CMOS is disabled for Hardy and enabled for Intrepid + Jaunty? It appears to been disabled in linux-source-2.6.22 (2.6.22-6.13) gutsy
<cking> ..perhaps I need a time machine to figure out the rationale behind the decision
<cking> smb_tp: ^^ wrt CONFIG_RTC_DRV_CMOS in Hardy?
<apw> cking, ok can you tell me what might trigger the grub error: Error 13: Invalid or unsupported executable format
<cking> have you moved from ext3 to ext4?
<apw> yes, but not recently
<apw> do i need to reinstall grub or something?
<apw> though i can boot an older kernel
<cking> When in the boot process is it occuring? Any other messages?
<apw> very first thing after it says its booting an image
<apw> as if the actual binary was corrupt
<cking> OK - sounds like the kernel image is corrupt
<cking> especially if you can boot older kernels
<apw> and yet the md5sum is the same on my boxes
<apw> and the other is booted from it
<apw> apw@chloe:/boot$ md5sum vmlinuz-2.6.28-11-generic
<apw> 6dfd6e870419d93a37c27341940316e7  vmlinuz-2.6.28-11-generic
<apw> apw@lana:/boot$ md5sum vmlinuz-2.6.28-11-generic
<apw> 6dfd6e870419d93a37c27341940316e7  vmlinuz-2.6.28-11-generic
<apw> apw@lana:/boot$ cat /proc/version
<apw> Linux version 2.6.28-11-generic (buildd@yellow) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #35-Ubuntu SMP Wed Mar 18 21:55:34 UTC 2009
<cking> grub has a block map command  that allows one to get a block map of the image. It may be worth checking grubs idea of the block map for this file compared to the reality
<apw> ok how do i get that in OS and grub
<cking> this is the fun bit. In Linux there is a ioctl() FIBMAP or something like that to get a block map of a file... hold on..
<cking> I will Email you the source to my fibmap dumper tool
<apw> nice
<apw> cking, ohhh blocklist in grub is unhappy
<apw> Error 24: Attempt to access block outside partition!
<cking> owch
<cking> ext4?
<apw> yes sir
<apw> its even printing extents :)
<apw> i assume thats <nnnn>+8 means
<cking> This is good and bad. Good that we have somebody who can send me an image I can work on :-) bad that it's screwed
<cking> Can you dd up the boot partition so I can look at it?
<apw> its my entire disk :(
<apw> (hd0,0)1546320+8.32+8,4096+8,402255872+8,4096+8,2792+8,402280448+4
<apw> that looks utterly corrupted to me
<cking> urgghh.
<apw> if its an extent list, it has the same extent twice doesn't it?
<cking> not sure
<cking> where's ted?
<apw> i think i'll boot a recovery cd and fsck it before i do anything else
<smb_tp> apw, could it be it got a wrong kernel, like a 64bit on a 32bit machine or somethin?
<apw> don't think so, it should boot the kernel then and fail at userspace
<cking> I'd dd the image to backup then fsck it
<smb_tp> cking, wrt to the config option: so it has been disabled before intrepid and enabled starting with it and later?
<apw> cking, no point in backing it up
<apw> its all recoverable from the other machine
<cking> Ah. fsck will be fast, that's for sure 
<apw> its had early ext4 on it so it could be corrupt
<cking> smb_tp: it appears to be disabled pre-hardy and re-enabled post hardy.
<apw> from there, so its probabally not pejorative of the current kernel even if its broken
<cking> apw: I agree
<smb_tp> apw, eek, should have read the whole backlog then
<cking> smb_tp, lemme see.. I had the change log somewhere...
<apw> yeah ext4 ate my /boot
<smb_tp> missed the blocklist is unhappy
<apw> yeah its well sick
<apw> ted is hiding from us
<cking> ext4 as boot. You're living dangerously
<apw> heh, you promised me it was working :)
<cking> ..yeah, but I did not promise it was 100% reliable :-)
<cking> ..what's it on?
<apw> its an intel shv
<cking> shv? eh?
<apw> its a intel quad core thing
<cking> owch.
<apw> well it was, its a heap at the mo :)
<cking> and it went wrong on the reboot?
<apw> nice our rescue disk doen't have fsck on it
<apw> well ... it fails to boot from the new kernel
<apw> i suspect the upgrade broke it
<apw> as in doing the upgrade
<smb_tp> apw, I think fdisk in the rescue disk might be a good proposal
<cking> smb_tp: hardy debian/changelog: linux-source-2.6.22 (2.6.22-6.13) gutsy; urgency=low ... build/config: Disable CONFIG_RTC_DRV_CMOS
<apw> nope not one of those either
<apw> this alternate disk is USELESS
<cking> ..remove disk and fsck on another box?
<smb_tp> apw, would a live cd work?
<apw> trying now
<smb_tp> cking, I have to look into that a bit. Reasons do not come to my mind immediatly
<apw> cking, i am a s/w engineeer
<cking> heh
<apw> i expect to be able to fix this from outside the box!
<apw> though i have screwdrivers on standby
<cking> surely using a screwdriver is software engineering?
<apw> heh, only h/w engineering when you need a hammer?
<cking> or solder
<apw> fsck says 'clean', is there a 'look do it properly' option?
<smb_tp> -f
<apw> taking more time at leas
<apw> cking, so how is fsck fast in ext4?  waht do they do different?
<smb_tp> iirc they can mark regions they have not touched, so those can be skipped
<cking> apw: http://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/
<cking> faster "due to the elimination of indirect blocks and the uninit_bg feature reducing the amount of disk reads necessary in e2fsckâs pass 1"
<cking> so now you know :-)
<apw> ok so its fsck'd ok
<apw> and thinking about it the md5sum of the file was fine too
<cking> fingers crossed
<apw> so i am suspect fo grub
<cking> How big was /boot?
<cking> ..oh yeah. the whole disk for / wasn't it?
<apw> yep massive
<cking> Can you run the fibmap prog and workout which blocks are used by the kernel image. Maybe we can dd up just some of this disk image to see why grub is bawking
<apw> 306M blocks
<cking> bit to big to fit on a DVD then :-(
<apw> heh yeah
<cking> I will compare and contrast the grub 0.97 + ext4 support with grub 2 and see if anything make sense
<cking> apw: I wonder if one could create an USB bootable drive and install grub 2 on this and see if this can read the kernel off the hard disk.
<cking> ..me goes to try this
<apw> cking, i guess its possible, i'd have no idea how
<apw> cking, the blocklist from fibmap bears no relation to that from grub
<apw> i'd susgest its overflowwing
<cking> mmm.. could be. How about comparing older kernels to see if grub vs fibmap marry up just for a sanity check
<apw> the working kernel seems pretty similar in location
<cking> and no major weirdness in the fibmap wrt sequential blocks etc
<apw> it looks like its in two extents to me
<apw> assuming there is no limits on actual extents
<rtg> amitk: I guess you noticed the ARM kernel didn't build? I think the Kconfig for drivers/cpufreq has problems, but it looks like you must build in the performance governor.
<amitk> rtg: it doesn't like the cpufreq driver built as a module
<rtg> amitk: right, I found that out last night, but when I quickly looked at your last push, I thought you had done the same
<amitk> rtg: and regarding hitting your shitlist looks like you didn't get my last message
<amitk> 21:34 < amitk> rtg: had to force push to jaunty. Found a typo in my patch (im51 -> imx51)
<cking> apw: can you send me the fibmap of a good kernel and the badone
<amitk> rtg: so I deserved it :-/
<rtg> amitk: hmm, sure didn't. I get so many flashes from this IRC client some days that I miss things.
<apw> cking, sure ...
<amitk> rtg: I've got the build issues fixed. Just testing with ogra regarding AA and aufs issues. Then I'll fix d-i for imx51
<rtg> amitk: ok
<cking> I'm looking at making a bootable USB image with grub2.. 
<apw> cking, on its way
<apw> i blocklisted a good kernel and its two extents
<cking> apw, that's good. thanks
<apw> i can keep this pretty much indefinatly if its a help
<apw> cking, i note that grub is reporting block number *8 the fibmap
<apw> but they are pretty similar
<apw> 402243640
<apw> 17F9C038
<apw> 50281984*8
<apw> 17F9F000
<apw> first is the one which works
<cking> apw: one could inform grub of the block map (from the map from fibmap) by hand and see if this boots - http://www.gnu.org/software/grub/manual/grub.html#Block-list-syntax
<apw> hmmm
<cking> bit of a pain I know
<Kano> hi, is there a karmic repo already? as you need new squashfs-tools from cvs
<Kano> squashfs 4.0 from 2.6.29 is not compatible with old squashfs 3
<apw> Kano, repo as in the full archive?
<apw> there is no karmic archive yet, and won't be till jaunty is released
<apw> cking, ok i have converted the fib lists, and get the same as grub for the X8
<apw> booting the X11 block lists gives Error 24: Attempt to access blocj outside partition
<apw> also do you have any clue as to what this format even means?
<apw> (hd0,0)1546320+8.32+8,4096+8,402255872+8,4096+8,2792+8,402280448+4
<apw> note the first bit has two +'s
<apw> it should look like: 402255872+4096,402280448,2792
<apw> it should look like: 402255872+4096,402280448+2792
<apw> the grub manual you pointed me to doesn't even mention two +'s as an option: 1546320+8.32+8
<apw> oh perhaps that was me ...
<apw> bah it was, i forgot i hand transcribed it
<Kano> well you can not use new squashfs-tools with jaunty when you don't update squashfs to 4.0
<Kano> would be basically no problem however
<Kano> as you have to do that for karmic too
<cking> apw, it's baffling. I need to look at the source
<apw> Kano, ok so there is a userspace kernel depenancy there
<apw> which will be sorted out in karmic when it opens
<Kano> i sent the aufs compile fix to the list, i booted it already live *g*
<apw> yep saw that, thanks for the patch, i am sure it'll be showing up soon enough in our tree
<apw> cking, yeah is most perplexing for sure
<cking> apw, especially the 8.32 part
<Kano> i looked at zen sources but only fixed the compile issues. maybe a new aufs snapshot would be good too
<apw> cking, i note that there is a 4096 in there which is the _size_ i am expecting
<apw> its almost as if its using smaller sizes for the extents on that one
<apw> ie less bits for the pointers
<cking> apw, did you try booting specifying the kernel with the block list of  402255872+4096,402280448+2792?
<apw> yeah
<apw> cking, yeah that produced the block out of partition error
<cking> OK - lemme build grub2 with some debug in the ext fs handler.
<apw> what will you send me, usb image to boot?
<cking> ..yep - working on this. It's a little tangled but doable
<apw> something to have on a stick me thinks
<cking> indeed
<apw> rtg, under intrepid a fair number of people are going to have ended up with the ieee80211_regdom=FOO thing set in their module options, when they upgrade to Jaunty those will be preserved and prevent the module loading
<apw> is there a something we can do to remove them, or perhaps we could make those options valid but ignored in jaunty
<rtg> apw: so, the module won't load because that is no longer a valid option?
<apw> yeah as its not a valid option we lose the module completely
<rtg> apw: we should certainly release note it.
<apw> IntuitiveNipple has reported it on Jaunty upgrades which we could probabally ignore as they are all knowledgable people, but those on Intrepid are likley to be less aware
<apw> ahh good point.  should have thought of that
<rtg> apw: my thinking is that this is something outside of our normal install, so anyone who does something like that, e.g., adds a module option, is also gonna have to be smart enough to figure out the borkage on an upgrade.
<apw> thats also a fair point.  they know they put it in
<smb_tp> apw, Did you have time to check whether the option always causes an oops or just a load fail as expected
<rtg> besides, its not like the wireless subsystem hasn't already had some turbulence 
<apw> not tried that yet.  will do so once i am upgraded on here
<apw> which i would have done, if my build box wasn't in a heap over ext4
<rtg> smb_tp: an oops is a bit more serious
<smb_tp> bug 337929
<ubot3> Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Undecided,New] https://launchpad.net/bugs/337929
<smb_tp> I just had not time to look furhter into that
<smb_tp> Was reported to happen for intrepid after the latest maste 2009-03-03(?) update as well
<rtg> smb_tp: I'm not to keen on the VIA sata patch for Hardy. what do you think?
<smb_tp> rtg, not in that form anyways. too much thrown into a single patch
<smb_tp> and I don't like the two libata changes
<smb_tp> I fail to understand what they are about
<rtg> smb_tp: my thoughts exactly. this falls under the heading of new hardware enablement, so I'm inclined to reject it for Hardy.
<smb_tp> I wanted to give them a chance to come with better patches. I'll write something up later
<rtg> amitk: I've rebuilt ARM with the correct CPU freq settings. shall I push or have you already commited to your local repo?
<amitk> rtg: I have it my local repo along with some other changes
<rtg> amitk: ok. you should push at least that fix so the repo builds ARM
<rtg> amitk: that and the /sbin/hotplug fix as well
<amitk> rtg: I need to make sure imx51 works well since I might not get another upload before beta.
<rtg> amitk: it would sure be nice if what is committed to the core repo actually builds.
<rtg> if you aren't comfortable with the CPU freq commit, then revert it.
<amitk> rtg: naaah. the cpufreq part is fixed. I want to make sure the AA/aufs parts have the correct settings. ogra's testing them out right now.
<rtg> smb_tp: you gonna teach ikepanhc how to use 'git request-pull' next ? (seeing as how you are his mentor)
<smb_tp> rtg, We started this morning send-mail for the acks and later request-pull for the patch
<ikepanhc> rtg: I miss something in the patch?
<rtg> ikepanhc: I haven't checked it yet, but I was just wondering where smb_tp was headed with your continuing education. (perhaps I'm just annoying him as well)
<smb_tp> rtg, You mean as in "will do" or "am already doing" ;-)
<rtg> smb_tp: annoying you? I assume I'm doing that already.
<smb_tp> rtg, Not too much :)
<ikepanhc> oh, I ask some this morning. but I am not fully understand the output of git-request-pull
<smb_tp> rtg, Really apw an me spoke with ikepanhc this morning and agreed that for review the git-send-email is good and later if you ack it for Jaunty he will post the request-pull for you
<smb_tp> ikepanhc, Ok, how may we help?
<mdz> I get two kerneloops popups on every resume
<mdz> I think this is due to https://bugs.edge.launchpad.net/ubuntu/+source/kerneloops/+bug/330606
<ubot3> Malone bug 330606 in kerneloops "WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume" [Undecided,New] 
<mdz> i.e. WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume  [edit]
<mdz> [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] 
<mdz> [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] OkCancel
<mdz> eek
<mdz> I meant: WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume
<ikepanhc> smb_tp: Let me take a look at the output again
<mdz> I think WARNING: triggers kerneloops
<rtg> mdz: apw suspected that in an email to me yesterday
<rtg> because the resume is too slow
<mdz> this one's killer because it happens twice on every single resume
<apw> hrmmm.  i had not considered it might trigger that.
<rtg> apw: I'm don't think a WARNIG should trigger the oops scavenger
<apw> that fix has not hit upstream and they implemented it slightly differently
<rtg> apw: what fix is that?
<apw> that really shouldn't imho, but i will look at the upstream version of the patch
<apw> rtg the fix which this warning is part of
<apw> they took it and accepted it, but then mushed it a bit later in the process
<apw> and the warning was removed i think
<apw> mdz i will pick that up and see what is what
<rtg> apw: ok, I guess we need to pull that in, 'cause its gonna annoy a lot of folks otherwise.
<apw> yeah for sure.  i suspect we need to check if kernel oops is being overly strong as well
<Keybuk> rtg: I don't suppose the hotplug change could sneak in with the next kernel upload?
<rtg> Keybuk: _if_ you can get amitk to push his changes, I'd be happy to accept it.
<amitk> rtg: do you have a train to catch?
<amitk> :)
<rtg> amitk: this is my day to annoy _everyone_
<amitk> I'll push it with the babbage changes
<mdz> apw: thanks
<ikepanhc> smb_tp: I use the command to show the summary of change: "git-request-pull origin/HEAD ."
<ikepanhc> Is that right?
<smb_tp> ikepanhc, not quite. there should be your remote repository somewhere...
<ikepanhc> you mean the url? give it git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git?
<rtg> ikepanhc: something like this: 'git request-pull <SHA1> git://kernel.ubuntu.com/rtg/ubuntu-jaunty'
<ikepanhc> point to your git tree, so that you will know the summary between our tree?
<smb_tp> ikepanhc, the <sha> is the id of what was the head before you added something
<rtg> ikepanhc: hmm, I'll be more literal. Use 'git request-pull <SHA1> git://kernel.ubuntu.com/ikepanhc/ike-jaunty.git' where <sha1> is the commit ID that you want me to start pulling from. Its _usually_ HEAD after you've rebased.
<ikepanhc> got it, it means the output will tell you where to pulling, and the summary of it
<ikepanhc> am I right?
<rtg> ikepanhc: correct
<ikepanhc> let me take a try
<smb_tp> rtg, with HEAD you probably mean origin/HEAD ...
<rtg> smb_tp: perhaps, I've not used request-pull much myself because I'm typically the consumer. I thought the SHA1 was usually the commit ID of where you differences begin, e.g., the patches that you want pulled.
<smb_tp> rtg, right. and imo origin/HEAD is what you pulled last and HEAD is your local head with your own changes
<rtg> smb_tp: that makes perfect sense.
<smb_tp> Plus it can be nicely automated with a wrapper script :)
<ikepanhc> smb_tp: I got a warn: No branch of git://kernel.ubuntu.com/rtg/ubuntu-jaunty is at: 6afb87c: UBUNTU: SAUCE: Fixing symbol name in HECI module
<smb_tp> ikepanhc, have you pushed to you repo before?
<ikepanhc> smb_tp: not yet, I shall push to my repo at zinc first?
<smb_tp> yes
<ikepanhc> smb_tp: I have to go home now, its pretty late in Taiwan, otherwise no bus can take
<smb_tp> ikepanhc, sure
<smb_tp> off you go
<ikepanhc> see you later
<mdz> apw: yay, your script is in checkbox in jaunty now
<apw> mdz yeah got it through in the end!
<apw> and i've even tested it
<mdz> apw: that'll save folks a step or two in testing
<mdz> apw: will checkbox walk the user through the test as well soon?
<rtg> amitk: forgot to mention that I did the newrelease thing, just copied the ARM ABI bits, etc.
<amitk> rtg: ok, will git pull again to test
<amitk> bradF: btw, I looked at your aufs changes to get it to compile w/o AA. They look sane to be, where sane = doing what has been done to all filesystems when AA patch was applied.
<amitk> s/be/me
<bradF> amitk: good, now I or someone needs to test them to see if they will actually work
<rtg> bradF: where they is?
<bradF> rtg: probably me, i'm working on getting things setup so that I can build a babbage image
<rtg> bradF: 'they' being the AA patches.
<bradF> rtg: I made the changes available to amitk in case he or one of the mobile guys wanted to give them a try before I got to it
<rtg> bradF: there is a reason we have public git repos
<bradF> rtg: and that is where my changes are
<amitk> bradF: Compile-test and send the patch to kernel-team ML to see if someone recoils in horror looking at it.
<amitk> then point them to what has been done to the other fs'es :)
<bradF> amitk: it compiles
<amitk> _then_ lets make sure it still works on booting with aufs
<rtg> bradF: and so they are. I'm just a cranky bastard this morning.
<bradF> amitk, rtg: will get the changes emailed out today
<amitk> rtg: we know
<bradF> rtg: I am sloooooow to learn sometimes, but I try :)
<rtg> bradF: what is this? humor from mr stoicism? I'm just shocked.
<bradF> rtg: you should deal with my business partners every day, it can be a bit trying
<rtg> bradF: I suggest you get rid of the '#ifdef CONFIG_VSERVER' clauses altogether. That config option is totally meaningless as it does not exists anywhere but in that source file.
<rtg> looks like hereditary forward porting cruft
<bradF> rtg: right
<rtg> bradF: it would simplify that patch a bit
<amitk> rtg: so what happens if one of the modules (cbc in crypto) that is expected by d-i as a module is compiled-in. Does d-i complain?
<rtg> amitk: yep, add a '?' so that its optional
<rtg> amitk: the case where adding '?' isn't sufficient is when _all_ of the modules for that d-i are compiled into the kernel. Then you have to get more creative 'cause kernel-wedge bitches that the udeb will be empty.
<amitk> rtg: that's where you exclude the udeb for that flavour?
<rtg> amitk: the creative part? sometimes I just drop the whole udeb.
<rtg> zul: what does the comment in this commit mean? http://kernel.ubuntu.com/git?p=chucks/ubuntu-ec2-jaunty.git;a=commit;h=c9e42c176084bfc18bede682332842a89d14c79d
<kirkland> rtg: zul: xvd is what's used if the block device is virtio
<rtg> the part about "This should not be included in the main ubuntu kernel." bothers me
<kirkland> rtg: yeah, i agree
<rtg> kirkland: and the patch changes the dev name to "sd", is that really what you want?
<kirkland> rtg: i wouldn't think so
<Ng> udev?
<kirkland> rtg: if you're using virtio, you expect the device to be xvd*
<kirkland> rtg: i have no context for what zul is trying to accomplish here
<rtg> kirkland: looks like an ec2 instance
<kirkland> rtg: i'm just interjecting that xvd* is sometimes used/expected
<rtg> kirkland: zul's explanation on the k-t list was a bit terse (to put it mildly)
<Ng> could a udev/rules.d file in some ec2 package (ec2-init?) not make appropriate symlinks?
<rtg> Ng: possibly. I'm still trying to grok the impact of his patch set on the distro kernel.
<Ng> (where "make appropriate symlinks" means "do any applicable udev magic up to and including renaming the devices". seems cleaner than a kernel patch, but I am probably lacking context)
<rtg> Ng: if its a boot-essential device, then it will likely require some initramfs magic. can you do that with ec2 images?
<Ng> you can with eucalyptus, but I've not used ec2 extensively enough to need to try
<zul> rtg: looking
<zul> rtg: basically ec2 uses an older version of xen which doesnt use virtio devices so if this patch is included in the main ubuntu kernel then it will break existing xen setups for jaunty
<rtg> zul: is there any way to decide that dynamically?
<zul> rtg: not that I know of, the ec2 kernel might have to be treated like a seperate tree like lpia
<rtg_> oops
<ivoks> sorry to interrupt, but i'm interested; is kernel aware of duplicate IPs on the same network?
<rtg_> zul: ec2 might be a separate flavour. LPIA is an arch
<zul> rtg_: maybe something like an ifdef for that case then?
<rtg_> zul: lemme think about it.
<zul> rtg_: k
<rtg_> zul: other then that, this patch set is sufficient to create an ec2 capable xen client?
<rtg_> it seems quite minimal
<zul> rtg_: yep i was using it the other day and building images based on it right now
<rtg_> cool
<zul> better than the xensource patchset ;)
<rtg> zul: what effect will some of these other config changes have on existing xen DomU clients?
<rtg> CONFIG_XEN_BALLOON is dynamic mem allocation for the VM, right
<rtg> ?
<zul> yes
<rtg> thats the one that might have an effect
<zul> its something existing ubuntu xen users want for jaunty not for ec2 though
<zul> the vmlinuz patch is very important though
<rtg> zul: in that case, it deserves its own commit so we can track it against whatever LP bug is open on it.
<zul> heh ill open a bug about it then :)
<rtg> zul: the vmlinuz target appears to be the core of the patch set. How is it used? Does it get copied to the linux-image package?
<zul> yes it does
<rtg> so we end up with both bzImage as well as vmlinuz.
<zul> the versions of xen that amazon is using doesnt understand the bzImage format more modern versions of xen does
<rtg> how about existing implementations? will they continue to use bzimage?
<zul> i think well the default in the rules.d/*.mk defaults to bzImage
<zul> existing implementations do use bzimage
<zul> rtg: if you require it https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/345486
<ubot3> Malone bug 345486 in linux "Please add ec2 support." [Undecided,New] 
<rtg> zul: if we made DEV_NAME in drivers/block/xen-blkfront.c a module or boot command line parameter, would you be able to launch an ec2 instance with that override?
<zul> a module yes not a boot command line parameter
<mdz> manjo: you're looking at kerneloops?
<manjo> mdz, yes
<mdz> manjo: I was just looking at it myself
<mdz> here's a hint as to why it's not working
<mdz> (gdb) print submit_pipe
<mdz> $1 = 0x1c73360 "/usr/share/apport/kernel_oops\n"
<rtg> zul: the other LP report I wanted was for XEN_BALOON
<mdz> note the last character of the string
<manjo> mdz, tying to get with kenvandine to get some testing info
<manjo> mdz, do you have any notes/scribble from your testing ? 
<manjo> mdz, that might help me ?
<mdz> manjo: ./kerneloops --nodaemon --file test/i386-bug-on.txt
<mdz> manjo: did you see what I pasted above?
<mdz> the config file parser is broken
<manjo> mdz, ah yes ... you were few steps ahead of where I was 
<zul> rtg: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/345490
<ubot3> Malone bug 345490 in linux "Please disable XEN_BALLOON and XEN_SAVE_RESUME for ec2" [Undecided,New] 
<rtg> zul: I thought XEN_BALLOON was important for non-ec2 instances also?
<zul> it is, its not important for ec2
<rtg> zul: well then, the bug subject seems a bit disingenuous
<zul> disigenuous?
<mdz> manjo: I have a patch
<manjo> mdz, cool let me try it 
<manjo> mdz, lp# ? 
<mdz> manjo: bug 344813, attaching the patch now
<ubot3> Malone bug 344813 in kerneloops "No apport report generated for kernel oops" [Medium,Triaged] https://launchpad.net/bugs/344813
<mdz> manjo: patch is there now
<mdz> seems to work OK with the patch, though it's a lot of dialogs
<manjo> mdz, got it .. I am upgrading jaunty (almost done) and  I will apply/test and report back
<amitk> rtg: changes for mx51 build tested and pushed
<amitk> rtg: could you fire up you hoover for the entire arch?
<rtg> amitk: yo 'da man
 * amitk -> dinner
<Blinkiz> rtg, Hi there. I have a question. This ext4 problem, zero-byte-file issue, do you think the patches for this will be back ported to jaunty when they are released? I have read something about it being fixed in 2.6.30.
<rtg> Blinkiz: there are 3 patches currently in Jaunty that revert some ext4 behaviors to that of ext3. Ted has blogged about it extensively (as well as commented in Launchpad).
<Blinkiz> rtg, Have tried to find this "ted", but I can't. Can you point me in the right direction?
* abogani changed the topic of #ubuntu-kernel to: "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-11.35 based on 2.6.28.8 final"
<rtg> amitk: your arm stuff built ok, as did the other arches
<amitk> rtg: no d-i explosions?
<rtg> amitk: debuild -b
 * amitk seems to have finally grokked d-i
<rtg> long live kernel-wedge
<apw> kirkland, t
<apw> this raid thing, its a software raid failure right
<apw> what i really need to do is isolate the string of md style commands that are exectured thre
<apw> to build the raid, then to build it again degraded
<manjo> mdz, do u have a build env to build kerneloops ? 
<mdz> manjo: yes, don't you? ;-)
<kirkland> apw: correct
<kirkland> apw: that magic is in initramfs-tools package
<mdz> manjo: I just built it on my jaunty system for test purposes
<Ng> what would cause the kernel to refuse to rm a file on a local partition, with an error about a stale nfs handle?
<Ng> weird, moved the file (it was a uuid thing in ~/.pulse/) out of the way so the gnome session could actually start and was then able to rm it
<apw> kirkland, ok thanks
<kirkland> apw: found it?  let me know if you need a specific pointer
<apw> kirkland, so you are booting from one disk plain in the error case
<IntuitiveNipple> Any ideas why with two identical notebooks with identical installations, both connecting to the same 802.11g AP, one would select region ZZE (Europe) and the other region ZZJ (Japan) ?
<kirkland> apw: yeah
<anubhav> different firmwares?
<IntuitiveNipple> anubhav: Identical in every way
<kirkland> apw: i could probably upload a kvm image that demonstrates the problem, if you like
<kirkland> apw: might take a while, but would be ready by your tomorrow
<apw> never tried to use kvm here, probabally take longer than debugging it
<apw> where are the raid tools.  damn package names
<IntuitiveNipple> mdadm
<anubhav> IntuitiveNipple: cfg80211 selcts the region?
<IntuitiveNipple> anubhav: That's correct, via the CRDA
<anubhav> IntuitiveNipple: let me check the code,maybe there's some hint 
<IntuitiveNipple> anubhav: Don't worry about it, I'll get around to it eventually. I was just hoping someone may know off the top of their head
<anubhav> :)
<apw> kirkland, do you have a full dmesg of the failed boot available?
<kirkland> apw: i don't
<apw> is it possible to get?
<apw> md says interesting things when its putting things together
<kirkland> apw: hmm, not terribly easily
<apw> if they fail etc
<apw> there is no serial on qemu?
<kirkland> apw: it'll be easiest if i just upload the disk image to p.u.c
<apw> kirkland, where did this work before jaunty?
<kirkland> apw: hardy, intrepid
<kirkland> apw: and like a champ...  i tested it a thousand times during the intrepid cycle
<apw> bah its huge numbers of commits either way to working
<kirkland> apw: i can't tell you if this ever worked in jaunty
<kirkland> apw: i don't remember it ever working
<kirkland> apw: though, i worked on this almost full time in the intrepid cycle
<kirkland> apw: and just happened to test it once in jaunty, realized that it regressed, and said wtf
<apw> kirkland, one thing worth trying is trying to use the intrepid mdadm tools
<apw> is that something you can test
<dtchen> TheMuso: i think we ought to consider post-release SRU for http://kernel.ubuntu.com/git?p=dtchen/ubuntu-jaunty.git;a=commitdiff;h=fbcaa0c6f18b41482caa41ceb6b7875c7dbaaeef
<TheMuso> dtchen: ok
<Kano> rtg: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commitdiff;h=85568da345d4348f33c69043c9bc4e78ad819706
<Kano> rtg: you know that you need that for 2.6.29 too?
<Kano> rtg: maybe 2.6.30 will have it
<rtg> Kano: I am assuming 2.6.30 _will_ have it.
<Kano> but not 2.6.29
<rtg> nope, but I don't much care about 2.6.29. its a transitional version for Karmic
<Kano> well i have got dkms updates for drm,but it would be nice if it would work out of the box
<rtg> I expect those drm fixes will land early in the merge .30 merge window
<Kano> maybe
#ubuntu-kernel 2009-03-20
<apw> smb_tp, your aspire is that 32 bit or 64 ibt?
<apw> and indeed can it be 64 bit?  i suspect not?
<smb_tp> hm good question. lemme look
<apw> its lm in the cpu flags i think which says 64 bit capable
<smb_tp> apw, is 32bit
<apw> and only?
<smb_tp> I see no capable, but neither do I on a 64bit capable
<apw> i'll assume these are 32 bit only, saves me some build time
<apw> and as you are my likely test kernel consumer it makes sense to make what you need :)
<smb_tp> hehe, yeah
<apw> smb_tp, could you have a boot of the kernels here:
<apw> http://people.ubuntu.com/~apw/lp319825-jaunty/
<apw> this should produce some debug in your dmesg every second
<apw> and try toggling the rfkill button as well
<nightwish> sorry, we have to perform emergency maintenance on this host so it will go down now. i hope we'll be back within the next 10 minutes
<smb_tp> apw, your kernel installed msg every second: status<S> state<0>
<smb_tp> wiggeling the killswitch seem like no effect
<smb_tp> No wireless
<apw> and no change to the data reported ?
<smb_tp> no change visible
<apw> hrm
<apw> does the kill switch do anything visible, toggle leds etc?
<apw> smb_tp, ^^
<smb_tp> just playing. no leds
<smb_tp> last change on unload status<F>
<smb_tp> using killswitch then
<smb_tp> wlan1 direct probe timed out
<smb_tp> and wiggeling again
<smb_tp> ap is found again
<smb_tp> but no led indicator
<apw> so in summary all APW: lines have S 0 on them except the one on unload
<smb_tp> correct
<apw> that is officially poor
<smb_tp> or not exactly correct. First one hat status S state 1
<smb_tp> but that was set
<smb_tp> the last one with status F was also a set
<smb_tp> all other msgs were update
<apw> ok makes sense
<apw> smb_tp, whats you machine lshal | grep machine say
<smb_tp> system.kernel.machine = 'i386' (string)
<smb_tp> err
<smb_tp> i686
<apw>  lshal | grep system.hardware
<apw> smb_tp, ^^
<smb_tp> peace, my multitasking is not as good
<apw> heheh
<smb_tp> primary_video.product = 10158 (0x27aw)
<smb_tp> primary_video.vendor = 32902 (0x8086)
<smb_tp> product = A0A110
<smb_tp> vendor Acer
<smb_tp> version 1
<smb_tp> and a serial and uuid I am too lazy to type
<apw> so product is _just_ A0A110
<smb_tp> yes
<apw> smb_tp, would it be reasonable to say that your kill switch works fine without the acer-wmi loaded
<smb_tp> yes, I would say so
<apw> i am wondering if basically we don't need rfkill support on some machines
<apw> and perhaps we need a quirk for that in here
<smb_tp> sounds like an option. the wmi support seems do be more hindering that supporting
<apw> yeah, will spin some more debug and see what we can find out
<smb_tp> ok, sure. waiting for next kernel :)
<apw> this meeting thing is pretty soon isn't it
<smb_tp> yeah, right
<smb_tp> too soon to have final results but we are on it
<Kano> hi, why is the aufs compile fix for 2.6.29 not in git?
<amitk> bradF: did you see junjiro's comments to your aufs patch?
<bradF> amitk: yes, I haven't looked at his patches yet
<bradF> amitk: i've been concentrating on getting my own kernel on the babbage board so I can start bugshooting that oops
<cooloney> bradF, have you boot up your own kernel on babbage?
<bradF> cooloney: no, am close, fighting with minicom right now
<cooloney> bradF, cool. do you know how to replace the kernel on SD card?
<bradF> cooloney: I believe so, I've looked at the wiki page https://arm.wiki.canonical.com/Home/Freescale/Babbage
<amitk> bradF: you can also use 'screen /dev/USBDEV 115200' 
<cooloney> bradF, thx
<bradF> amitk: screen is new to me, i've used minicom in the past
<bradF> amitk: how do you do a file transfer in screen?
<amitk> bradF: no, I just use the sb/sx binaries
<amitk> bradF: but minicom works too
<bradF> amitk: If I understand you, you use screen to break into redboot
<amitk> I use screen a lot to keep sessions available through remote login
<bradF> amitk: then get out of screen and start the ymodem download
<bradF> amitk: then get back into screen to copy the image to the SD card
<bradF> amitk: is that the steps you follow?
<amitk> bradF: umm, no. Ctrl-A :exec <sb cmdline>
<bradF> amitk: will give that a try
<cooloney> amitk, bradF is it possible to load kernel to babbage in redboot via ethernet tftp?
<bradF> cooloney: I think that should be possible, I was just using serial because that is know to work
<amitk> cooloney: lool might know about it. The ethernet driver is pretty crappy
<bradF> amitk: the redboot ethernet driver is crappy?
<lool> bradF: mcasadevall told us today how it works
<mcasadevall> No, works fine.
<lool> mcasadevall says that it will only work if it gets IP via bootp
<amitk> bradF: ohh... I wasn't thinking. The mx51 ethernet driver is crappy
<lool> or if it's set in config
<mcasadevall> Or manually config with fconfig
 * mcasadevall notes its the kernel driver which is a pile of $#@! in 28
<cooloney> great
<bradF> i thought I'd used tftp on a previous project but it was a while ago
<bradF> that was with redboot
<amitk> if you do use it, please add it to the wiki
<amitk> would be a lot faster than serial
<bradF> amitk: will do
 * mcasadevall does use it
<cooloney> thanks guys, i might try it this weekend.
<cooloney> i have to go to sleep, have a nice weekend guys. -:))
<bradF> cooloney: bye, maybe see you this weekend, will look for you
<amitk> cooloney: have a good weekend
<ernstp> IntuitiveNipple: any new thought on bug #343919 ? :-)
<ubot3> Malone bug 343919 in linux "Nvidia MCP67 AHCI ata timeout exception with data loss" [Medium,In progress] https://launchpad.net/bugs/343919
<IntuitiveNipple> No, not had chance to look at it, got several other issues to investigate currently.
<bradF> amitk: still around?
<hallyn> hmm, i'm surprised - ubuntu-jaunty.git has no btrfs?
#ubuntu-kernel 2009-03-21
<Kamping_Kaiser> Will Ubuntu be issuing a USN about the same issues as DSA 1749-1 ? If yes, would that be a chance to fix bug 342638
<ubot3> Malone bug 342638 in linux "linux-image-{generic,386} in -security uninstallable without -updates repository." [Undecided,New] https://launchpad.net/bugs/342638
<Kamping_Kaiser> eep. bot
<Kamping_Kaiser> i'm told "that bug" is blocked by bug 292381 , hence i ask
<ubot3> Malone bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,In progress] https://launchpad.net/bugs/292381
* abogani changed the topic of #ubuntu-kernel to: "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-11.36 based on 2.6.28.8 final"
<kees> Kamping_Kaiser: gcc in hardy should already be fixed.
<Wesselaar> hi
<Wesselaar> will there also be a new kernel for hardy soon?
<fransman> Wesselaar: a i386 and amd64 version?
<Wesselaar> i386
<Wesselaar> i see a kernel update at 8 april on the wiki, but it doesnt give much info
<fransman> what version do you have
<Wesselaar> 8.04
<Wesselaar> you mean the kernel?
<fransman> the kernel version true ...
<Wesselaar> i forgot the command to see that in console, i think its 2.6.24????
<fransman> # uname -a
<Wesselaar>  2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11 UTC 2009 i686 GNU/Linux
<Wesselaar> im looking for the info to see if i can stay with ubuntu or switch to mandriva, because my atheros card doesnt work that well, and it does on mandriva, i think it has to do something with the kernel i guess
<fransman> why don't you upgrade to 8.10 ?
<fransman> or to 9.04?
<Wesselaar> because in 8.10 my card also doesnt work quiet well
<Wesselaar> i dont know about 9.04
<Wesselaar> 9.04 also doenst , i tried the beta a few weeks ago , i rmember
<Wesselaar> so i hoped for a new kernel ...
<fransman> in 9.04 it's kernel-image-2.6.28-10
<JanC> fransman: -11 actually
<Wesselaar> i guess thats the same as mandriva 2009 uses ..., hmmm
<Wesselaar> wished ive never bought this laptop :-)
<fransman> JanC: isn't that the debian-installer?
<JanC> fransman: I installed 2.6.28-11 not so long ago  ;)
<fransman> I am running a PowerPC so I can not check!
<JanC> installed it around 16h .be/.nl time
<fransman> got still vmlinux-2.6.28-4-powerpc
<JanC> anyway, it might be useful for Wesselaar to check if mandriva uses another driver (or driver version) or if they add some module parameters or such
<Wesselaar> hmmm, im not that smart i guess :-)
<Wesselaar> im just a computer-user, not a wizzkid :-)
<Wesselaar> but i like ubuntu and dont want to change but i guess its the only way to get this crappy laptop working right
<JanC> well, is there a bug report about this?
<JanC> you might also want to include the info about mandriva (e.g. what kernel version you have there)
<Wesselaar> i will check it, need to restart with the live cd, will be back here then
<Wesselaar> thanks for the info so far
<fransman> #lspci and #lsmod is your friend!
<Wesselaar> tnx
<maxb> The current intrepid-proposed lbm appears not to be in git
<dtchen> maxb: meaning the abi bump?
<maxb> at least, yes
<dtchen> according to the changelog, at least, it seems to otherwise be present in ubuntu/ubuntu-intrepid-lbm.git
<Kamping_Kaiser> kees, hm, I didnt see the update come in. I'll have another look, probably pebkac here.
#ubuntu-kernel 2009-03-22
<ghostcube> hi peoples
<ghostcube> what has changed from 8.04 gspca modules to 8.10 modules i have a problem in supporting an guy changed to 8.10 now the logitech chipp isnt working 
<ghostcube> http://paste.ubuntu.com/135593/  dmesg 
#ubuntu-kernel 2010-03-22
<salty-horse> using iotop on lucid I get: "CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %" -- was the flag removed recently?
<salty-horse> found it in here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/493156
<ubot3> Malone bug 493156 in linux "Please enable CONFIG_TASK_DELAY_ACCT" [Wishlist,Won't fix] 
<salty-horse> hi BenC
<geoff918> Can anyone answer this question?:  http://ubuntuforums.org/showthread.php?p=9006250&posted=1#post9006250
<mtx_init> what is the symbol table device names are encoded in?  im a bit confused.
<psurbhi> chrisccoulson, ping
<chrisccoulson> psurbhi, hi
<psurbhi> i am looking at the bug 539467 on LP
<ubot3> Malone bug 539467 in linux "Frequent ATA errors and disk corruption" [Undecided,Triaged] https://launchpad.net/bugs/539467
<psurbhi> had a questione
<psurbhi> * question
<psurbhi> ..
<psurbhi> the description you have posted seems to be a part of a dmesg
<chrisccoulson> it is
<psurbhi> do you have that dmesg?
<psurbhi> containing the error messages?
<chrisccoulson> not the whole dmesg, i only copied the section with the errors from it
<chrisccoulson> unfortunately, it doesn't save to disk ;)
<psurbhi> aaha
<psurbhi> sure.. !
<chrisccoulson> so i just pastebin'd the errors before rebooting
<chrisccoulson> i can grab the whole dmseg when it happens again though
<psurbhi> ya.. cool.. can you get more than the error messages too? just to know something that happens before it
<chrisccoulson> yeah, no problem
<psurbhi> ya..that will be very helpful :) so i will comment as such on the bug as of now, ok :)
<chrisccoulson> thanks
<psurbhi> chrisccoulson, also one more question
<psurbhi> you did not see this bug before 2.6.32.16? which means 2.6.32-15 worked fine for you?
<chrisccoulson> psurbhi, i'm not too sure. the laptop is quite new, but i started seeing it as soon as i upgraded to lucid
<psurbhi> ok
<psurbhi> thanks!
<chrisccoulson> psurbhi, the first lucid kernel i ran on this was 2.6.32-10
<chrisccoulson> (i've still got them all on here)
<psurbhi> cool..so did that work? or did that too give you the errors?
<chrisccoulson> IIRC, that gave the errors too
<chrisccoulson> i can try that again later though
<psurbhi> ok..thats helpful
<psurbhi> great
<JFo> Keybuk, who all does the nouveau development? I'd like to get someone to look over bug 539655 if possible. Unless you are still thinking it is an X issue even with Stefan's logs
<ubot3> Malone bug 539655 in linux "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini" [Medium,Triaged] https://launchpad.net/bugs/539655
<Keybuk> JFo: #nouveau is a good place to start
<Keybuk> as I said, I think it's probably a nouveau issue
<JFo> k
<JFo> anone in particular I should ping? :)
<JFo> err anyone*
<JFo> nm
<JFo> <-brain is slow this morning
<JFo> thanks Keybuk 
<Keybuk> JFo: you has a reply already
<JFo> yep :)
<Kano> hi apw , why was 
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commitdiff;h=99380e40c725fbb737e1fbf30c9c54e4c6285455
<Kano> done?
<Kano> also the description is somehow wrong, woulnt it be RE-modularise SATA disk controllers
<amitk> interesting, my headphones are plugged in and the sound is coming out of my speakers
<JFo> nice
<JFo> I wonder if that was what was happening to me earlier when you guys were getting the echo
<amitk> worth checking out
<psusi> there seems to be something very wrong with pipe()s... tar -cf - | dd of=/dev/null is more than an order of magnitude slower than tar -cf - > /dev/null.. having dd use a larger block size does not help, and the system is not cpu bound.
<Sarvatt> smb: do you actually have anything hooked up to the TV-1 on your geforce 6800?
<smb> Sarvatt, No, its just a single VGA connected
<smb> Sarvatt, Were would I see whether the driver thinks there is something connected?
<Sarvatt> in your dmesg there it's showing a load on TV-1, I was wondering because fedora is disabling tv-out http://cvs.fedoraproject.org/viewvc/F-12/kernel/drm-nouveau-tvout-disable.patch?view=markup
<smb> Sarvatt, Hm. tv-output stuff. Have I seen something lately...? Gosh, to many things passing by
<smb> Hm, this one on .33 stable... But it was for another system. "drm/i915: Use a dmi quirk to skip a broken SDVO TV output."
<quentusrex> My search has finally led me here.
<quentusrex> https://bugs.launchpad.net/linux/+bug/347711
<ubot3> Malone bug 347711 in linux "Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on Jaunty" [Unknown,In progress] 
<quentusrex> Can someone help me debug a kernel network driver problem?
<quentusrex> I have found the r8168 and the r8169 network drivers to be unstable under heavy load on my system and can reproduce the issue within 15 minutes. 
<quentusrex> My problem is I don't know what info is needed to truly track down the issue
<johanbr> quentusrex, it's a known problem, with plenty of reports
<johanbr> I don't think there's much you can do, apart from waiting for the kernel devs to solve it
<quentusrex> alright, is there a 'main' ticket for it?
<johanbr> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472057 might be the same issue
<ubot3> Malone bug 472057 in linux "NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out" [Undecided,Confirmed] 
<johanbr> maybe one of them should be marked as duplicate of the other
<quentusrex> johanbr, I've been trying to find an upstream report
<quentusrex> I have found things that sound similiar, but not exact.
<johanbr> http://bugzilla.kernel.org/show_bug.cgi?id=12411 ?
<ubot3> bugzilla.kernel.org bug 12411 in Network "2.6.28: BUG in r8169" [Normal,Assigned] 
<quentusrex> johanbr, does this look the same: http://paste.ubuntu.com/399465/
<quentusrex> it does to me, but I'm not familiar with kernel call traces
<quentusrex> that is the output as soon as the network connection fails
<johanbr> doesn't look exactly the same
<johanbr> but having some of the earlier output would help
<johanbr> i.e, before line 1
<quentusrex> just above that was the end of the last networking crash
<quentusrex> I'm going to reboot the server and copy the whole syslog output
<quentusrex> and, how do I remove the r8168 driver and put the r8169 back into service?
<quentusrex> just: rmmod r8168; modprobe r8169 
<quentusrex> ?
<johanbr> quentusrex, yep
<quentusrex> johanbr, how do I tell which driver is actually being used for a network interface?
<johanbr> I guess lsmod should tell you
<quentusrex> it says 0 for the in use by column
<johanbr> or "dmesg |tail" just after loading, to see if it actually binds to the interface
<quentusrex> lshw just said it.
<quentusrex> is that reliable for this?
<johanbr> should be
<mwhudson> hi
<mwhudson> i'm still being affected by this bug in lucid: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/377598
<ubot3> Malone bug 377598 in linux "[i945gm] Video corruption when disabling internal monitor" [High,Confirmed] 
<mwhudson> and i'm wondering if i should be surprised by this or not
<mwhudson> the linked freedesktop.org bug suggests it was fixed in the kernel a fair while ago
<cnd> anyone know if there's an interface for karmic-proposed like packages.ubuntu.com?
<cnd> actually, I'll ask at #ubuntu-devel
<quentusrex> Is there a way to test newer ubuntu Karmic kernels? in such a way that can be rolled back?
<quentusrex> I would like to test the newer kernels to see if the bug is fixed(on a karmic sandbox)
<quentusrex> but be able to remove the newer kernels if they all fail. So I can go back to stock kernel.
<tormod> quentusrex, if you install a kernel with another version (not just the last ubuntu-version number) it will be installed side by side with the others and you can choose in the grub menu
<quentusrex> thanks tormod is there a ppa for these?
<tormod> quentusrex, which kernels are you looking for?
<quentusrex> I am running Linux therabbit 2.6.31-20-server #58-Ubuntu SMP Fri Mar 12 05:40:05 UTC 2010 x86_64 GNU/Linux
<quentusrex> I would like to test something more recent to see if the problem has been fixed.
<quentusrex> tormod, I have no issues running the 'latest' kernel to test it
<quentusrex> or testing other kernels more recent than the stock one I am using now
<tormod> quentusrex, for a start you can install the latest lucid kernel, just get it from the main repo
<tormod> then you can test later upstream kernels from the "kernel mainline ppa"
<quentusrex> tormod, is there an apt repo for mainline kernels?
<tormod> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
<mrec> hi, is there anyone who can commit a patch to the lucid kernel?
<mrec> https://bugs.launchpad.net/ubuntu/+source/tvtime/+bug/544527
<ubot3> Malone bug 544527 in tvtime "usbfs is bugged with >2.6.32.9 and <=2.6.33 (breaks VMWare, Qemu, sane scanners, ...)" [Undecided,New] 
<mrec> I think I will set our devices to Bulk in order to work around that bug :/
<mrec> there are around 700 devices out there in the field which are affected by this bug
<quentusrex> tormod, that doesn't have an apt repo
<quentusrex> so it won't allow for apt-get update; apt-get install X
<quentusrex> I can install it from here, but I would prefer the other direction since I cache apt repos and I am able to test multiple machines this way.
<tormod> quentusrex, no I am afraid the kernel-ppa is not a real PPA :)
<quentusrex> tormod, is there any talk about creating a real ppa for it?
<quentusrex> I think it would help get kernel testing done :)
<tormod> quentusrex, maybe you can use a script which sucks down from http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ ...
<quentusrex> is there an upstream irc channel?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543314 => can somebody check this plz ? :)
<ubot3> Malone bug 543314 in linux "Frequently used NIC (Marvell Technology Group Ltd. Device 4381) not supported" [Undecided,Confirmed] 
<quentusrex> 2.6.34-999 interesting... :)
<quentusrex> tormod, the mainline kernel doesn't have the kvm modules does it?
<tormod> quentusrex, I don't know, but the config file should tell
<quentusrex> tormod, thanks for the help. It does, but it isn't compatible. In this case I can't just upgrade the kernel.
<quentusrex> tormod, is it recommended to test the realtek driver directly?
<tormod> quentusrex, I don't know much about kvm etc
<quentusrex> tormod, I had a test environment setup that could crash it in a few minutes with a kvm torrent server running
#ubuntu-kernel 2010-03-23
<pabelanger> howdy!  I'm looking for any tutorials on having a custom kernel within Launchpad PPA?  Move of the actually packaging, I was hoping to maintain my over version for some embedded hardware
<milli> is there any chance of getting commit 68f194e0 pulled into 2.6.32 before rc ?
<RAOF> What does it do?  What bug does it fix?
<milli> 8 line patch to support isight cameras on latest Macbook Pro's in uvcvideo driver
<milli> some cameras report 0x00 in one field, others 0xaa, but both are YUV2 cameras
<RAOF> It's still possible to get patches into the kernel; file a bug (and for bonus points, attach a proper kernel-team formatted patch).
<milli> RAOF: k, ty
<crimsun> pabelanger: the kernel team has decent documentation there; see kernel.ubuntu.com
<Sarvatt> smb: are you around by any chance? It looks like we dropped a patch we really need during the 2.6.33 drm merge
<Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=7b56712ff524ee55e38afaee3954d125f56a6070
<Sarvatt> https://launchpad.net/bugs/535640 all of those are because thats gone in -16, was fixed in -15 when that was added
<ubot3> Malone bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed] 
<Sarvatt> apw told me to bug you while he's on vacation :)
<jjohansen> Sarvatt: smb should be on in about 2 hours
<mrec> BenC: Hi
<mrec> BenC: can you have a look at https://bugs.launchpad.net/ubuntu/+source/tvtime/+bug/544527 please?
<ubot3> Malone bug 544527 in tvtime "usbfs is bugged with >2.6.32.9 and <=2.6.33 (breaks VMWare, Qemu, sane scanners, ...)" [Undecided,Confirmed] 
<mrec> I wonder who to contact that this issue will be resolved asap :/
<lool> amitk: Hey, I see apw is on leave, do you know who cares for linux-ti-omap in lucid in the mean time?
<lool> amitk: First upload built, but was held in NEW (and still is?!), second upload failed to build
<lool> (I have the d-i changes to publish netboot images ready and would like to test them  ;-)
<amitk> lool: I'm just pushing a fix for the FTBFS
<amitk> lool: and I care for omap in lucid
<smb> amitk, Oh, when you are around. Can you give your blessings to the changes lool posted?
<ogra> lool, first upload didnt boot so there was no point in wasting admin time on it, second one boots and amitk is shaking out bugs found in the testkernel atm
<smb> lool, amitk Where does that armel/versatile patchset belong anyways? (which branch?)
<amitk> smb: master
<smb> amitk, arm patches on master?
<amitk> smb: will push the d-i change for netboot (who uses it?) and also include the ubuntu drivers directory for ti-omap for ogra
<ogra> amitk, netboot will be our fallback image if everything else goes wrong (its the easiest to create image)
<amitk> smb: versatile is all upstream, so we just create a kernel for it out of master
<smb> amitk, Ah, ok
<amitk> smb: infact, can you handle that patch from Loic? I'll ack it.
<amitk> smb: the first one is just a revert I think
<smb> amitk, And for the netboot change and whatever else needs to be in ti-omap, please put pull requests on kt ml
<smb> amitk, I'll review them as well, then I can pull it in. I just won't immediately upload a kernel on the master
<smb> for that I think of kernel-ppa
<amitk> smb: ack
<lool> (Sorry had to disappear for a while)
<lool> amitk: omap maintenance > noted; thanks
<lool> smb: I'd love if you could upload whatever amitk pushes to fix the FTBFS so that we can clear new and push at least one d-i image out this week  :-)
<smb> lool, I just wait for all things that should go in to be on the mailing-list
<lool> smb: As amitk explained, my patches are for master and are just config tweaks; versatile is a single patch on top of mainline IIRC (setting it to armv7 instead of its CPU) and a flavour + config
<smb> lool, Just trying to understand #2. Why is that changing config.common.ubuntu ?
<lool> smb: The versatile changes are to revert a previous chanve, but it's not a "revert" because the commit with the change updated another config *and* config changes probably are best not reverted but recomputed across configs
<lool> the second versatile change is an arm-specific config update because the defconfig value made no sense and was harmful
<lool> smb: See my followup: CONFIG_CMDLINE is disabled on x86 because it depends on CMDLINE_BOOL which is unset on x86
<lool> (in our config at least)
<lool> There's no CMDLINE_BOOL on arm, so CONFIG_CMDLINE is always enabled, but the value made no sense
<smb> Hm, ok. Understand. So that never took effect for x86
<lool> Yup
<ogra> amitk, oh, one think thats essential to get a live image booting on the beagle revC is also compcache, can you make sure thats enabled ? 
<ogra> *thing
<amitk> ogra: enabled
<ogra> merci :)
 * ogra is still not sure what to do about the requirement for an omapfb cmdline option
<ogra> if anyone has an idea for that, any suggestion is appreciated 
<ogra> apparently the drive has no builtin default so the cmdline option is needed ... imho it would be good to have a default like 1024x768 and only use the cmdline option to override so we dont forcefully need an entry all the time
<ogra> *driver
<ogra> amitk, do you think something like the above would be possible without much hacking ? 
<amitk> ogra: will need some thinking, postponing for later... :)
<ogra> how late :)
<amitk> i need to get you a kernel with aufs first
<ogra> (it surely doesnt need to be in the current one)
<ogra> but having some sane default for release would rock 
<amitk> smb: there have been changes in 2.6.33 that make it hard for aufs to compile anymore.
<amitk> basically, we'll need to make some in-kernel symbols non-static
<amitk> http://ftp.riken.go.jp/pub/pub/Linux/gentoo/sys-fs/aufs2/files/aufs2-base-33.patch
<amitk> ogra: ^^
<amitk> This isn't a GPL vs. non-GPL war, but more like upstream fs devel
<amitk> I wonder if we should stick to unionfs for ti-omap
<smb> amitk, If that works and needs less changes. I guess its late to make quick porting efforts
<amitk> smb: the patch or unionfs?
<Keybuk> it's a shame that Val's writable overlays patches are going so slowly
<smb> amitk, Well the patch to get aufs compiling. Ok, we are not so restricted in what we take into that branch, but as ogra was wanting things fast it seems the most simple and workable solution should be preferred
<amitk> smb: AFAIK, unionfs is a drop-in replacement, it just works (TM) by using the kernel cmdline union=unionfs (or something close enough)
<amitk> Keybuk: if it isn't ready for the next cycle we might want to go back to unionfs
<Keybuk> wasn't there a huge reason we switched away from unionfs in the first place?
<amitk> apparently there have been several stability fixes since
<amitk> no qualitative opinion though, it is for foundations to decide
<smb> amitk, I have not been looking there as much as Andy did but I thought the were some issues why we did not change away from aufs2. Probably the same thinking line as Keybuk. In the end someone else needs to decide what they want / need in there.
<JohnFlux> Hey all
<JohnFlux> The rt3070sta driver needs a small change to support my hardware
<jjohansen> early 2.x line of unionfs was a mess and had all kinds of bugs, that made a last minute revert to unionfs 1.4 necessary (I think this was on hardy)
<JohnFlux> how do I get such a change put in?
<jjohansen> JohnFlux: send an email with the patch to kernel-team@lists.ubuntu.com
<jjohansen> after that the switch to aufs2 was made, aufs stagnated for a while and unionfs has gotten better.  I don't know which is currently best
<JohnFlux> jjohansen: thanks
<amitk> ogra: so what do you want to do for union?
<ogra> i need to do some testing, i think casper still supports union, but its a lot slower than aufs
<ogra> and union requires additional hacks to the cmdline 
<ogra> to make casper use it
<amitk> ogra: I can add the aufs patch for now, so you can get something going, let's discuss it later this week.
<ogra> ok
<smoser> hey all. could I get someone kernel-team or otherwise capable to take a read of bug 458201 ?
<ubot3> Malone bug 458201 in qemu-kvm "kernel stacktrace on volume detach in kvm guest" [Low,Confirmed] https://launchpad.net/bugs/458201
<smoser> the final comment there has a dmesg that might mean something.
<smoser> (this should probably be moved to kernel, not qemu-kvm, if you agree, then go ahead and do so)
<JohnFlux> jjohansen: how do I get the kernel source, include staging, that will be used for lucid?
<JohnFlux> jjohansen: is there a git repository?
<jjohansen> JohnFlux: https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
<rackerhacker> jjohansen: have time for a quick /msg?
<jjohansen> rackerhacker: sure
<pabelanger> morning
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<amitk> smb: Can you have a look at our Makefile and tell me if this line makes sense
<amitk> LINUXINCLUDE    += -Iubuntu/include $(if $(KBUILD_SRC),-I$(srctree)/ubuntu/include)
<amitk> smb: top-level makefile
<smb> amitk, That is the way it is right now, right?
<amitk> smb: right
<amitk> smb: I'm wondering if the same include is there twice
<smb> It seems makeing sense. Well the first is the source and the second is the source in the O= dir
<smb> or the other way round
<amitk> smb: you're right! I was missing the O= angle
 * smb looks for a volunteer for a (I think) well triaged bug with upstream and maybe stable potential. But probably it needs some discussion.
<bdmurray> cnd: there is an interesting comment in bug 516772, number 8, that works for me
<ubot3> Malone bug 516772 in linux "HP Touchsmart tm2 brightness level not changing" [Low,In progress] https://launchpad.net/bugs/516772
<amitk> smb: ti-omap pull request sent to list
<smb> amitk, ok, lets see
<bjf> ##
<bjf> ## Kernel team meeting in 15 minutes
<bjf> ##
<amitk> smb: got a chance to look at omap?
<smb> amitk, Got a chance to read kernel-team mailing list? :)
 * amitk doesn't see the reply yet, kicks his cron job
<JFo> heh
<smb> Funny, usually its the other way round. I see my replies last
<amitk> smb: I'll reorder the commits and fix the commit messages
<smb> amitk, But basically I would reorder one commit and change the comment on another. Otherwise it seems ok. Hopefully the ubuntu gets dropped on future M rebases
<smb> amitk, I can do that just her, if you say ok with me
<smb> here I mean
<amitk> smb: ok, if you want, I already fixed and pushed it to my tree
<amitk> so you can just do a new pull
<smb> I can do, but I usually export and import them (to add acks and signed-offs)... *shrug* But I can pull it again 
<amitk> smb: do you think you'll be able to do an upload today?
<smb> amitk, I will pull that in, then do a quick cross compile test and then upload, so it should be there soon
<amitk> smb: Besten Dank!
<smb> amitk, Keine Ursache
 * ogra hugs smb 
<amitk> smb: I suggest a complete build so we catch any other failures
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<smb> amitk, btw. Have any of these reported as a bug
<smb> ogra, ^
<amitk> smb: no
<ogra> smb, nope
<smb> k
<Keybuk> apw: you know how you build efifb into the kernel, but don't build fbcon in, just sayin' ;P
<smb> Keybuk, You would need to should loud this week to make him hear you. :)
<smb> shout I mean
<Keybuk> on holiday is he? despicable!
<Keybuk> :p
<smb> Keybuk, He is indeed. Trying not to break anything while standing on two waxed pieces of wood
<Keybuk> he's doomed
<Keybuk> not for the skiing
<Keybuk> but he'll say something drunk in the bar after
<Keybuk> a husband will object, there will be a fight
<smb> Especially in _that_ country. :-P
<Keybuk> smb: so, #2, the same question ;-)
<smb> Keybuk, Why we don't build it fbcon?
<Keybuk> yeah
<smb> Because we missed it I'd guess
<Keybuk> it's always been a module, obviously
<Keybuk> at least on x86
<Keybuk> I think we probably do build it in on platforms that have never had VGA
<smb> Hm, maybe. And the question would be whether some could have side-effects when built in. Like "stealing" ressources
<Keybuk> OTOH, the side-effect of not building it in means that EFI has no console ;-)
<Keybuk> at least not until relatively late in the boot when userspace loads it
<MTecknology> what's the drm33 kernel for?
<smb> MTecknology, Is that in some package name
<amitk> Keybuk: should disks be owned by root:root or root:disk?
<MTecknology> smb: git version
<smb> MTecknology, We have drm from 2.6.33
<MTecknology> what's that mean?
<smb> MTecknology, That it is a 2.6.32 based kernel with everything in drivers/gpu/drm and include/drm from 2.6.33
<Keybuk> amitk: root:disk usually
<MTecknology> smb: oh.. thanks
<smb> Keybuk, It (fbcon) seems to be loaded on all my systems, too. So it might be worth thinking on that. 
<Keybuk> smb: it is loaded by userspace
<Keybuk> as I said
<MTecknology> smb: I just didn't ever remember seeing a .xx-drmxx.x version on the kernel, maybe just didn't notice it
<smb> MTecknology, No that got added recently, so it is clear which versions are in. As we will be picking stable updates from 2.6.32.y and 33.y
<smb> Well and the drm backport was just started with -16 iirc
<smb> Keybuk, Right, just arguing to myself about any "dangers" of building it in
<Keybuk> smb: lucid+1 btw
<Keybuk> but vaguely thinking
<Keybuk> if we build in fbcon
<Keybuk> then we can set the graphics mode in grub to something sensible (ie. last used mode in X)
<Keybuk> and tell grub to tell the kernel all about the mode
<Keybuk> which makes the kernel use efifb
<Keybuk> (fbcon being built in means you have a console straight away, so no "black screen during boot issue")
<smb> and hopefully have something in kms that would honor that too
<Keybuk> right, nouveau kms got fixed recently to handover properly
<Keybuk> intel kms hands over already
<Keybuk> so when the real kms driver loads, it hands over the framebuffer and fbcon to them
<Keybuk> (and adjusts the mode to a better one if needs be)
<Keybuk> then X comes up
<Keybuk> ...
<Keybuk> this means we always have a framebuffer (yay pretty)
<Keybuk> ideally only ever have one mode set (grub)
<smb> and locks ... err didn't say that aloud
<Keybuk> and the X fallback case is nice too (X falls back to fbdev, no need for VESA)
<smb> but yeah. sound like a neat boot 
 * smb still looks at the five star steady screen
<smb> Keybuk, Btw, when I look at that with ftrace it seems both plymouth and X do more grabs than release.
<Keybuk> heh
<Sarvatt> smb: sorry to bug you but did you get my message earlier about the patch that got lost with the drm merge?
<Sarvatt> we're getting a huge number of bug reports on intel that are all because that commit was dropped in 2.6.32-16
<Sarvatt> <Sarvatt> [00:26:28] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=7b56712ff524ee55e38afaee3954d125f56a6070
<Sarvatt> <Sarvatt> [00:27:06] https://launchpad.net/bugs/535640 all of those are because thats gone in -16, was fixed in -15 when that was added
<ubot3> Malone bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed] 
<ali1234> does the karmic default kernel have kgdb enabled?
#ubuntu-kernel 2010-03-24
<MTecknology> What's changed from 9.10 to 10.04 that would negatively impact iwlagn?
<soren> The kernel.
<soren> I'm just saying.
<MTecknology> soren: :P
<MTecknology> soren: I get to be on the sucky side of bug 544254
<ubot3> Malone bug 544254 in linux "iwlagn (i4965AGN) continually drops and reconnects to access point " [Undecided,Confirmed] https://launchpad.net/bugs/544254
<MTecknology> soren: I was just wondering if anybody knew off the top of their head what may have decided to break it
<MTecknology> found something on lkml...
<MTecknology> http://lkml.org/lkml/2010/1/16/126 - close but not quite
<soren> MTecknology: A friendly word of advice: You're not going to make any friends with that kind of rhetoric.
<MTecknology> soren: hm?
<soren> MTecknology: The whole "decided to break it" nonsense.
<MTecknology> soren: something's making it not work. I'm not smart enough to figure out where the iwlagn driver might have changed. I didn't see anything bad about saying that
<soren> MTecknology: When I get that sort of attitude from someone, I'm likely to ignore them. I'm just saying.
<MTecknology> soren: I didn't know there was attitude in that
<soren> MTecknology: I'm not speaking on behalf of the kernel team. As I said: Just a friendly piece of advice.
<MTecknology> how would you phrase it?
<soren> In a way that doesn't imply that someone is out to get you and has purposely broken things just to make your life suck.
<MTecknology> soren: we must be reading two different lines
<MTecknology> bugs happens, things break, it's the way of life. sometimes you can do one thing that fixes things for thousands of users; but it'll break things for two other users.
<soren> I understand the nature of bugs.
<MTecknology> soren: so why is what i said bad?
<soren> MTecknology: I'm just saying that implying that people have gone out of their way to wilfully break things is not going to get you better feedback, that's all.
<MTecknology> I never implied that
<MTecknology> "I was just wondering if anybody knew off the top of their head what may have decided to break it"
<MTecknology> ^ I asked about a change breaking it
<MTecknology> whatever, if that's the way you see it........
<MTecknology> I'll just try to go through the bug report...
<soren> "decided to break it" in my book more than implies that a conscious decision was made to break something.
<soren> Anyhow, this is silly. I'm not speaking on behalf of the kernel team. Heck, they might even enjoy that sort of rhetoric. I'm just saying how I'd react, that's all.
<soren> And with those words, I'll wander off and do vaguely useful things.
<lifeless> soren: OTOH what doesn't imply a person :P
<MTecknology> hurry for uploading 14.6MB
<MTecknology> any ideas when we'll have linux-backports-modules-wireless-2.6.32-17-generic available?
<soren> lifeless: fair
<JohnFlux> Hey all
<JohnFlux> which is the kernel for lucid-lynx ?
<JohnFlux> I'm following the instructions on https://wiki.ubuntu.com/KernelTeam/GitKernelBuild   but I'm not sure which kernel is going to be used for lucid
<smb> git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<JohnFlux> smb: do I need to clone git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git    as well ?
<JohnFlux> smb: get both?
<smb> JohnFlux, If you do more than one kernel it helps. Though its not mandatory
<smb> Its just that you can use the linux-2.6.git tree as --reference
<JohnFlux> smb: hmm, i'm getting horribly confused by these instructions then
<smb> which saves you disk space for copies
<smb> linux-2.6 is a copy of Linus upstream tree
<JohnFlux> the link I gave says I need to have both, and use an 'overlay'
<JohnFlux> smb
<JohnFlux> smb: 
<smb> overlay?
<JohnFlux> smb: that what it says
<smb> JohnFlux, Let me have a look
<JohnFlux> smb: I'm not too sure either, other than guessing from the name
<JohnFlux> smb: so, once I have that ubuntu-lucid.git   cloned, how do I build it?   Where do I get the .config for it from?
<smb> JohnFlux, That git tree contains the config and all
<JohnFlux> smb: do I need to copy the config to .config  or something though?
<MTecknology> If I'm having a problem in the new kernel and using the backports fixes that issue. How can I apply the backport headers to a custom kernel?
<JohnFlux> smb: how do I build?
<smb> You should have either a build chroot if lucid is not installed on the machine
<JohnFlux> smb: I've just upgraded to lucid
<JohnFlux> smb: so I should have everything that I need
<smb> fakeroot debian/rules binary-generic
<smb> That builds only a generic kernel
<MTecknology> I always do 'make all modules_install install' for a local system; long ugly command for a pretty deb
<JohnFlux> smb: will it include staging?
<smb> The package will land in the dir above
<smb> It will include the same drivers as our builds
<smb> So all of staging that is enabled normally
<JohnFlux> smb: okay good.  Basically I'm trying to get my hardware to work - it needs a minor change
<JohnFlux> smb: when I make the change, how can i rebuild but give the package a different name?
<JohnFlux> so that I can try different changes
<smb> JohnFlux, you edit the debian-master/changelog
<smb> The first line contains the version number
<smb> You can add something like +myversion1
<MTecknology> This is what I use for the pretty deb   AUTOBUILD=1 CONCURRENCY_LEVEL=${CONCURRENCY_LEVEL:-3} ionice -c 3 schedtool -D -e make-kpkg --initrd --rootcmd=fakeroot --append-to-version=-hyper${KERNELREV:-1} kernel_{headers,image}
<smb> Just beware of '-' in the version number
<JohnFlux> how can I build with make -j 4   or so
<JohnFlux> to speed up the compile?
<smb> MTecknology, That looks pretty much overdone for a simple build
<smb> JohnFlux, Usually it uses -j<nr of cpus>
<JohnFlux> smb: right, I have 4 cores
<smb> JohnFlux, If you want to override this you set CONCURRENCY_LEVEL=x
<JohnFlux> smb: oh, it does by default?
<JohnFlux> cool
<smb> JohnFlux, yep
<MTecknology> I built a gentoo system once with -j instead of -j# .... very very bad idea - bad things happen :P
<JohnFlux> yes, top is confirming that I have about 3 or 4 cc1's at any one time
<JohnFlux> thanks
<JohnFlux> smb: binary-generic  is what I want? :)
<JohnFlux> smb: I'm after the default kernel for i386
<JohnFlux> or 686 or whatever it's called
<smb> JohnFlux, The default kernel there depends on amount of RAM. For more than 4GB you might want binary-generic-pae
<smb> but otherwise its binary-generic
<JohnFlux> smb: hmm, I've never had much luck with pae in the past
<JohnFlux> never boots for me - I'll leave that for now
<smb> JohnFlux, Depends on cpu as well. There are some via c7 which just don't have pae capability
<smb> If cat /proc/cpuinfo does not have pae in flags it will fail
<MTecknology> So.. backports are upstream changes that may break for some users but backported because they fix things for other users?
<smb> MTecknology, If you speak about linux-backports-modules (the package), yes. 
<MTecknology> smb: yup, i was - thanks :)
<ngregory> anyone got time to give me a few pointers on solving a kernel panic issue i've got?
<MTecknology> ngregory: ya, pastebin anything you can see so some smart person here can point you in the right direction
<ngregory> i raised a launchpad bug - but unfortunately its not getting much (i guess everyone is pretty busy) . last stack track from a mainline kernel http://launchpadlibrarian.net/41648154/panic5-2.3.33.txt
<ngregory> ideally want to know its its xfs / lack of memory or some random scheduler bug
<JohnFlux> smb:  dh_testdir: cannot read debian/control: No such file or directory
<JohnFlux> smb:  it aborted with that error
<smb> JohnFlux, Ah, fakeroot debian/rules clean 
<smb> JohnFlux, You need to run clean once to generate some files
<JohnFlux>  /bin/bash: kernel-wedge: command not found
<smb> JohnFlux, sudo apt-get install kernel-wedge
<JohnFlux> smb: shall I add that as a prerequisite to the wiki?
<smb> JohnFlux, Would make sense. There might be more. I think you would get a list by running dpkg-buildpackage -D ...
<smb> JohnFlux, On the other hand most of the wiki seems to address building a standard Linux tree from upstream with a config close to the one used for ubuntu builds
<JohnFlux> smb: indeed, I think I'm following the wrong guide
<smb> JohnFlux, maybe this contains parts that would help you better https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
<pmatulis> what would prevent a module from loading automatically whereas the same module can be loaded manually with modprobe?  on 8.04 server i have such a situation with a 10 Gb NetXen/HP card (NC522SFP).
<mrec> hi, how can someone get a patch into the ubuntu lucid kernel?
<JFo> mrec, send an e-mail with the patch info to kernel-team@lists.ubuntu.com
<mrec> thanks, hopefully someone will pick it up
<MTecknology> JFo: git format-patch <- just fyi
<JFo> MTecknology, I don't deal in the patching, just the bugs
<JFo> :)
<MTecknology> s/JFo/mrec/
<mrec> MTecknology: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7152b592593b9d48b33f8997b1dfd6df9143f7ec
<mrec> this one you mean?
<MTecknology> mrec: what about it?
<mrec> you wrote git format-patch
<mrec> there you can pick it :)
<MTecknology> I'm too tired to follow :P
<MTecknology> time to reboot into a new kernel - hopefully this one doesn't carry the same bug
<ali1234> huh, that bug could be the cause of my deadlock
<MTecknology> ali1234: my issue is wifi
<ali1234> i have an issue with wifi too
<ali1234> separate issue tho, i think
<ali1234> i'm currently more bothered about the fact that the kernel is deadlocking when using gadgetfs
<MTecknology> ali1234: wlagn locking up or really slow?
<ali1234> my wireless issue is random memory corruption
<MTecknology> oh
<ali1234> it does not lock up or go slow, it just corrupts packets silently
<MTecknology> interesting
<ali1234> if i turn on debugging i get "poison overwritten" errors
<ali1234> anyway, i sent that one to ath5k developers
<MTecknology> ali1234: g'luck
<MTecknology> hrm - time for me to run
<manjo> JFo, do u recall ? do we have a ton of bugs where HPmini does not boot when splash enanbled ?
<manjo> JFo, I just get a screen that says Glib-Warning getpuuid_r() failed to do unknown user id (0)
<manjo> and can't switch console 
<JFo> no idea
<manjo> ok
<NCommander> I'm having issues with uio on a dove kernel, and I'm not getting any useful debug messages
<NCommander> anyone around to help with debugg?
<NCommander> ^ing
<cnd> NCommander: is it dove specific?
<cnd> or arm specific?
<cnd> (I'm guessing so, and I can't help if that's the case...)
<NCommander> cnd: dove, but I think I have an idea
<NCommander> uio modules don't seem to work as modules
<RAOF> Ok.  We need a way to ensure that vga16fb does *not* bind when there's a perfectly good kms driver loading that's just about to claim fb0.
<cnd> RAOF: I was interested in tackling that too
<cnd> what needs to be done?
<cnd> I don't know much about this area
<RAOF> I'm not entirely sure.  Possibly vga16fb could be taught about vgaarb?
<cnd> what's vgaarb?
<RAOF> vga arbitration.
<RAOF> I claim thee, VGA card!
 * cnd goes to lxr for research
<RAOF> I'm by no means an expert here, either.
<cnd> http://lxr.linux.no/linux+v2.6.33/Documentation/vgaarbiter.txt
<RAOF> But nouveau devs are paranoid about vga16fb messing with their state (even though I've seen no bad effects with vga16fb binding fb1), and in rare cases it seems that vga16fb claims fb0 before novueau has fully initialised, resulting in tears.
<RAOF> Hm.  Maybe vgaarb is not what I meant.
<cnd> RAOF, yeah, vgaarb doesn't look quite right here
<cnd> RAOF: do you know what the difference is between vag16fb and vesafb?
<RAOF> No, I don't.
<RAOF> Anything I said would be based simply from educated-guessing on the module names.
<cnd> I'm guessing vga16fb is for really old stuff, vesafb for slightly newer
<RAOF> vesa is a newer (but still old) video interface.  It's kinda vga+
<cnd> yeah
<RAOF> I'd guess that the big difference between vga16fb and vesafb is that vesafb would be doing some modesetting.
<cnd> RAOF: doing some research I found bug 530451
<ubot3> Malone bug 530451 in linux-backports-modules-2.6.32 "Nouveau interacts badly with vga16fb - blank screen before X" [High,Fix released] https://launchpad.net/bugs/530451
<cnd> it seems to say that as long as the correct driver is above vga16fb in modules.order, things should be fine
<cnd> is that not the case?
<Sarvatt> vga16fb on fb1 when you have a KMS fb on fb0 also makes lshw completely screw up the screen
<RAOF> Right.
<cnd> ahhh
<RAOF> cnd: I thought that was the case, and in all *my* testing it was, but there are a couple of bugs where vga16fb still seems to claim fb0
<cnd> so we need to prevent vga16fb from doing anything
<RAOF> Yeah.
<Sarvatt> it shouldn't claim fb0 anymore ever if theres a KMS driver being loaded, have you seen any reports that it was that aren't lbm-nouveau related RAOF? it still loads and screws things up on fb1 though all the time
<RAOF> Sarvatt: bug #546359 seems to have vga16fb claim fb0 without lbm-nouveau.  That's a dual-gpu case, so is somewhat of a corner case.
<ubot3> Malone bug 546359 in xserver-xorg-video-nouveau "nouveau does not work with nVidia G94 [Quadro FX 1800]" [Undecided,New] https://launchpad.net/bugs/546359
<RAOF> That said, there are going to be quite a large number of dual-gpu laptops running Lucid.
<Sarvatt> well, it would if say intel radeon or nouveau loaded *before* the agp module causing it to fail which is a pretty nasty problem some people are hitting
<Sarvatt> hmm yeah thats worth looking into and definitely multi-gpu specific
#ubuntu-kernel 2010-03-25
<cnd> RAOF: Sarvatt: there's some code here that I think we could duplicate for our purposes somewhat: http://lxr.linux.no/linux+v2.6.33/drivers/video/fbmem.c#L1509
<cnd> it seems to destroy framebuffers that are already registered if a superseding one is found
<cnd> what we need is a fb priority
<cnd> where vga16fb = 0, vesafb = 10, intel, nouveau, radeon = 20
<cnd> and we need to kick off lower prio framebuffers and prevent lower prio framebuffers from being added on after higher prio fbs
<cnd> does that make sense?
<RAOF> I think that's overcomplicated.  Our proper kms drivers are already loading first, and claiming devices.  I think this could be fixed more simply by vga16fb actually checking whether it can claim a device.
<RAOF> I'm just not familiar enough with kernel internals to work out how to do that.
<cnd> RAOF: see, that makes sense, except why did the dual gpu case have vga16fb grab the fb first?
<cnd> so I'm thinking that there's a race condition in the loading of the modules
<RAOF> Yeah, that's possible to.
<cnd> the vga16fb module may be loaded second, but it registers first
<RAOF> But claiming the fb != claiming the device.
<cnd> RAOF: I'm not sure I follow
<RAOF> I'm fairly sure that one problem is that vga16fb doesn't actually claim any hardware; it just grabs a pointer to the VGA memory and goes nuts writing in it.
<RAOF> When it loads fast enough to get fb0, that results in the poor kms driver having all sorts of card state overwritten, because things actually write to fb0.
<RAOF> When it loads and claims fb1, that's not such an issue; nothing's trying to output on fb1, so vga16fb doesn't scribble over interesting state.
<RAOF> s/claims fb1/gets assigned fb1/
<cnd> RAOF: still, we don't want it at all, cause if someone does try to access fb1 it'll mess things up, right?
<RAOF> Right; I think that's what lshw is triggering.
<Sarvatt> seems like something in the logic deciding which device to use and by the time its set up both enough to be ready to allocate fb's to them vga16fb already loaded, yeah
<cnd> so that's where I think we need a fb priority
<cnd> so that we can kick off vga16fb when nouveau comes after, or prevent vga16fb if nouveau comes first
<RAOF> So, if vga16fb actually tried to claim a VGA device, in the sense of âlet me scribble on this device iff no other driver thinks it can scribble on itâ, then we'd be ok.  vga16fb would fail to load, because the kms driver has already claimed the hw.
<cnd> RAOF: is your comment in reference to the priority implementation, or some other mechanism
<RAOF> Some other mechanism.  I *know* drivers have the ability to claim hardware, because nouveau prevents nvidia from loading because nouveau's claimed the hardware.
<cnd> RAOF: yes, but the problem here is: what if vga16fb claims the hw first?
<cnd> it would prevent other drivers from working
<Sarvatt> I think other framebuffer drivers actually have code to not screw up KMS and vga16fb just wasnt updated too
 * cnd goes back to lxr
<Sarvatt> like efifb will hand off control over to a KMS driver right
<Sarvatt> in 2.6.33 at least, not lucid's kernel
<Sarvatt> yeah - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4410f3910947dcea8672280b3adecd53cec4e85e and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=89f3f2199084a160a3a45fa6d9af235696321758
<RAOF> cnd: Yes, in that case vga16fb would prevent other drivers from working.  I think we're safe there because modules.order should ensure the kms driver starts loading first, and I think they claim hardware early.
<cnd> Sarvatt: AHHH! they use that exact block of code I found
<cnd> info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
<cnd> the FBINFO_MISC_FIRMWARE says "destroy me if another fb registers the same space"
 * RAOF stands corrected.
<cnd> so basically it's a binary priority like I suggested
<cnd> so this looks fairly simple
<cnd> just port the changes to vga16fb
<cnd> I'll take a look at it
<RAOF> Great!  Thanks.
<Sarvatt> thanks for looking at it cnd, I'm swamped at the moment and can't mess with it
<RAOF> cnd: Do you have a bug # about vga16fb in mind?  I'm wandering through the -intel bugs, and I think I've found some duplicates of that behaviour (multi gpu, vga16fb incorrectly claims fb0).
<cnd> RAOF: no
<cnd> I just tried a test kernel, but it didn't work :(
<RAOF> :(
<cnd> gotta figure out what went wrong
<cnd> RAOF: actually, I think it would work
<RAOF> If only...?
<cnd> the current logic unregisters a fb if a better one comes along
<cnd> but it doesn't prevent vga16fb from registering after a hw fb
<cnd> so I've fixed up vga16fb, but I need to fix up the register_framebuffer logic
<RAOF> You didn't make any change to fbmem.c? (Which seems to be where the registration happens)
<cnd> RAOF: the change I made for the kernel I just tested was to enable handoff in vga16fb
<cnd> now I'm changing fbmem
<RAOF> Ah, right.
<RAOF> I've moved bug #518387 over to linux for the vga16fb framebuffer fixes.  There's also bug #527369 with very different symptoms and almost certainly the same cause.
<ubot3> Malone bug 518387 in linux "vga16fb sometimes claims fb0 before kms driver, a causing blank screen on boot" [High,Confirmed] https://launchpad.net/bugs/518387
<ubot3> Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369
<cnd> RAOF: thanks
<cnd> kengyu: around?
<cnd> I see you've taken bug 527369
<ubot3> Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369
<cnd> I'm working on a couple patches to fix it
<cnd> hopefully I'll have some results in a bit
<cnd> if you haven't done much, feel free to reassign it to me
<cnd> kengyu: RAOF: going down for testing. if you don't see me back in a few mins I hosed my laptop and won't bother with it till tomorrow :)
<RAOF> :)
<RAOF> That looks promising :)
<cnd> well, mostly cause it still didn't work right...
<cnd> I still got me /dev/fb1
<cnd> I'll have to do some printk debugging tomorrow
<cnd> I'll post any updates in the bugs (hopefully in the form of a test kernel)
<RAOF> Huzzah!
<bryceh> JFo, btw I'm bumping some bugs over from radeon that needs quirk fixes in the drm, probably easy bugs.  Search for 'pll' in the linux bug list and they'll show up
<bryceh> JFo, I don't think the bug reports are dupes, they are just different hardware that all need the same quirk or whatever
<bryceh> JFo, they're all RV530/RV515 systems
<crimsun> JFo: is there a tag to be used when a patch fixing a bug is CCed to stable@k.o?
<crimsun> JFo: e.g., bug 502226
<ubot3> Malone bug 502226 in linux "Audio Stops, video speeds up" [Undecided,Triaged] https://launchpad.net/bugs/502226
<crimsun> JFo: to clarify, these are external patches lacking BugLink links in the git commit msg
<JohnFlux> Hey all
<JohnFlux> I made a change locally to ubuntu-lucid/drivers/staging/rt2870
<JohnFlux> can I recompile just that driver and load it ?
<JohnFlux> so far I've been using debian/rules  to recompile and install, which is kinda slow for each small change
<bigon> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/545585 << are you aware of this bug ?
<smb> JohnFlux, You might carefully use "make O=./debian/builds/build-generic" (or whatever flavour you are compiling) if you did not clean up after the last full build
<ubot3> Malone bug 545585 in linux "lucid iwlagn  free more than tfds_in_queue" [Undecided,Confirmed] 
<smb> bigon, No
<bigon> it's spamming dmesg a lot
<smb> bigon, Actually not from the header. But I know there seem to be problems with dropping the connection
<bigon> smb: let me se if I get connexion drop
<smb> bigon, At least the bug report you mention says something about drops. But the other reports seem to be either less or worse impacted. And without the message about tdfs_in_queue
<amitk> cooloney: ericm_: it seems like the VFP patch from Imre that you included isn't yet ack'ed by Russell
<amitk> bug 507503
<ubot3> Malone bug 507503 in linux-mvl-dove "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes" [High,Fix released] https://launchpad.net/bugs/507503
<amitk> specifically, he noted some problems with the patches
<smb> bigon, Ah, ok. Finally went through the whole report. Seems the message itself might be a different issue. But I try to get a test kernel prepared for the proposed patch
<bigon> smb: great
<JohnFlux> smb: cd
<JohnFlux> smb: /home/johnflux/ubuntu-lucid is not clean, please run 'make mrproper'
<smb> JohnFlux, you are now in $HOMe
<JohnFlux> :)
<JohnFlux> smb: it says that when I do the make  command that you said
<smb> with O= (careful never do mrproper)
<JohnFlux> smb: yes, with the O=
<JohnFlux> smb: I assumed you meant /build/ instead of /builds/
<JohnFlux> ~/ubuntu-lucid (master)$ make O=./debian/build/build-generic
<JohnFlux> I'm doing that
<smb> As I tried to get the dirs from my memory likely
<smb> maybe that needs a C= too... give me a sec
<smb> JohnFlux, Hm, it seems to work for me. Potentially you could use $(pwd) instead of . (thought that should not change much).
<JohnFlux> smb: I'm just doing "make modules" instead.  Any reason to not do it the old fashioned way?
<amitk> JohnFlux: if you're getting the 'make mrproper' message, you've probably run make in the ubuntu kernel directory without the O=
<smb> JohnFlux, But I think, when you did call make once wrong without O= it can spoil things. If you call make modules you do that
<smb> amitk, I was thinking that
<amitk> best to save your changes as a commit, reset the git tree and reapply the commit again
<JohnFlux> hmm
<smb> JohnFlux, You could recover by mv'ing debian one level up. Then call make mrpropoer and then mv debian back
<smb> JohnFlux, builds with O= and without don't mix well
<JohnFlux> I could just use 'make modules'  instead right?
<JohnFlux> and not bother with the debian packages?
<amitk> yeah
<smb> Then you use a different configuration, get different function checksums and your module won't laod
<smb> amitk, no
<amitk> but assuming you copy the .config correctly
<JohnFlux> I copied /boot/config-blah 
<smb> amitk, You need the right symversions
<JohnFlux> I think it was the right .config
<JohnFlux> and I built the kernel with AUTOBUILD=1    wasn't that to do with checksums or something?
<amitk> smb: aah right, I thought he was just test compiling. The compiled modules won't work on the ubuntu kernel for shit
<smb> And the symversions are only created by a full build, after that you could use that for incrementals
<smb> JohnFlux, I'd run a full build once, then use "make O=$(pwd)/debian/build/build-generic modules
<smb> for the incrementals
<JohnFlux> do I need to prepend AUTOBUILD=1   to that?
<smb> JohnFlux, AUTOBUILD is a herring rouge with lucid
<smb> I don't think it has any effect
<smb> JohnFlux, You just need a "fakeroot debian/rules binary-generic" run once
<amitk> ...after resetting the tree
<smb> amitk, right. After doing a make modules in there
<JohnFlux> okay thanks - I'll give that a try
<JFo> crimsun, sounds good, I'll look at them today
<JFo> I don't know of a tag that we could use on them
<JFo> rather bryceh :)
<JFo> <-still half asleep
<JFo> bryceh, I see 9 bugs. That sound about right?
<JohnFlux> I. AM. BRILLIANT!
<JohnFlux> smb: okay, so I got my hardware working with a one line change
<JohnFlux> smb: just a simple case of adding the USB_DEVICE to the code
<JohnFlux> smb: any chance I can just ask someone here to add the change?
<JohnFlux> It would be great if this works out of the box for 10.04
<smb> The preferred way would be to send it upstream. But for a start send it for discussion to kernel-team@list.ubuntu.com. It also helps to have a bug report open to refer to.
<JohnFlux> yep, there's an open bug report about it
<JohnFlux> smb: okay I wrote up my summary on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441990
<ubot3> Malone bug 441990 in linux "Buffalo WLI-UC-GN 802.11n USB-WiFi adapter non functional" [Undecided,Confirmed] 
<smb> JohnFlux, Cool, thanks. If you either attach your patch there and/or send it with a reference to the bug to the mailing list to indicate there is a simple fix for that. Makes it a bit simpler to not loose things
<JohnFlux> smb: done
<JohnFlux> smb: I mean, I've sent an email to the mailing list
<JohnFlux> hmm the email bounced
<smb> JohnFlux, Ok, thanks. :)
<smb> Hm, did I give the wrong address
<JohnFlux> no, I've subscribed etc
<JohnFlux> smb: should I create a proper git format-patch  for it?  It's so small it didn't seem worth it
<JohnFlux> smb: did my email send correctly ?
<JohnFlux> smb: "Trivial patch for supporting.."
<smb> JohnFlux, Yep, its there
<JohnFlux> okay good
<JohnFlux> smb: so, should I send this 'upstream' as well?
<JohnFlux> smb: does the email contain sufficient info?
<smb> JohnFlux, For start its enough info. You should send it upstream. But then it needs a proper patch and go to the right people. Also I would add a CC: stable@kernel.org in the section where you put your signed-off-by
<smb> Give me a sec, lets see who should get it
<JohnFlux> smb: reading the TODO file in the directory, it says to not bother the kernel people
<smb> Oh, staging, then Greg
<JohnFlux> smb: okay done - I've forward the email to him
<smb> Err, he probably wants proper format
<smb> Even for such small thing
<JohnFlux> hmm
<smb> He can afford to be lazy :)
<JohnFlux> I guess, but it's such a pain to get git to send via gmail
<JohnFlux> I can never remember how to get send-imap working
<JohnFlux> :-)
<smb> JohnFlux, I could forward it in your name and put your credentials into it
<JohnFlux> that would be good thanks :)
<JohnFlux> could you put both lines in
<JohnFlux> both the changes that I suggest
<smb> JohnFlux, Yep, either that or make two small patches of it. Do you have the other hw as well?
<JohnFlux> nope
<JohnFlux> but I gave a link where several users say it works for them
<smb> Ah ok. Guess that should be enough
<JFo> crimsun, we can use patched-upstream if you think that is descriptive enough
<cnd> smb: there's some bugs where the vga16fb poorly interacts with other framebuffers
<cnd> there's some logic to kick off generic framebuffers if a hw-specific fb comes along
<cnd> but that logic is based on the aperture location overlapping between the generic fb and the hw fb
<cnd> it seems that vga16fb, with its hardcoded aperture location, does not overlap with hw-specific fb aperture locations
<cnd> I'm thinking of modifying the code that kicks a generic framebuffer off to do the same to vga16fb any time a new fb comes along
<cnd> do you have any insight or thoughts?
<smb> Ok, so that does not work. I don't know off my memory whether we build in vga16fb or not. I had the feeling its  module but loadded by early userspace
<cnd> smb, we build it as a module
<cnd> there's two problems
<cnd> 1: there's a race condition where in dual gpu nvidia systems vga16fb somehow gets /dev/fb0 even though its loaded after nouveau
<cnd> 2: even if nouveau gets /dev/fb0 and vga16fb claims /dev/fb1, if you run lshw as root it does something to /dev/fb1 that screws up the vt
<cnd> so ideally we want vga16fb to be usable if there's no other fb available, but we want to kill it if there is
<cnd> and really, any fb is better than vga16fb, so it makes sense to me to kill it if any other fb comes along
<cnd> even vesafb
<smb> cnd, That might be something to discuss with Keybuk. He knows the plumbing layer bringing up the fbs and stuff like that
<cnd> smb, I think we're below the plumbing layer though
<cnd> basically, I think we need to decide whether this approach is reasonable, because vga16fb is unmaintained upstream
<cnd> I'll send out an e-mail to linux-kernel
<cnd> but we may need to decide this ourselves
<smb> And I am probably not so much help there. Yes, that might be a better idea. Though you probably want also to be sure there is nohing hard loading vga16fb
<smb> For whatever reason. And understand that reason
<cnd> smb, what do you mean by "hard loading"
<smb> modprobe vga16fb
<Keybuk> cnd: what kind of timescale are you thinking?
<Keybuk> smb: nothing should do that, we load vga16fb by alias
<cnd> Keybuk: what do you mean by that?
<Keybuk> cnd: for the modifications you're talking about to vga16fb
<smb> Keybuk, Ok, just wanted us to be sure
<Keybuk> it sounds like the kind of project that would take longer than we have left before kernel freeze?
<cnd> Keybuk: well, the modifications aren't very much, so I can have a patch ready by end of today
<cnd> we're talking about 10 lines of code max
<cnd> but I defer to you and smb as to whether that's still acceptable
<Keybuk> but the "kick the generic framebuffer out" code in our current kernel is broken, right?
<Keybuk> it works in .34
<Keybuk> but not in .32
<cnd> Keybuk: it seems to be all there to me
<Keybuk> it isn't
<Keybuk> breaks nouveau iirc
<smb> cnd, Keybuk Well to me this sounds like it should not be hasted then
<cnd> Keybuk: are you referring to vga16fb?
<Keybuk> ok
<Keybuk> let me back up a second
<smb> cnd, Is blacklisting vga16fb a workaround?
<Keybuk> smb: NO!
<Keybuk> would it help if I explained for a moment why we're doing things the way we are right now
<cnd> smb, we can't blacklist otherwise we can't fallback to vga16fb if its the only thing that works
<Keybuk> and how we'd prefer to do them if we could
<cnd> Keybuk: sure
<Keybuk> ok
<smb> yeah
<Keybuk> so in general we want a framebuffer for our console
<Keybuk> it means we're always using fbcon
<Keybuk> it means our x86 story is the same as our ports story
<Keybuk> and it means we can do things like always fallback to the X fbdev driver if we can't find a better one
<Keybuk> but we can't quite do that today
<Keybuk> so what we do today
<Keybuk> KMS drivers include a framebuffer - so when we auto-load them by alias - we get a framebuffer (win!)
<Keybuk> non-KMS drivers don't by default - so we arranged for vga16fb (most basic fb that works) to also be alias loaded
<Keybuk> but alias loaded *after* anything else first like nouveau, radeon, intel, etc.
<Keybuk> since vga16fb is just a framebuffer to the VGA, it doesn't bind to hardware like those do
<Keybuk> but that has never seemed to be a problem
<Keybuk> you just end up with an fb1 that would draw using the VGA if you reset the video mode back to a VGA mode
<Keybuk> (and the KMS drivers have it in native modes, so you never see it)
<Keybuk> so this works well enough
<Keybuk> we have a framebuffer
<Keybuk> (fb0 is either native or vga16fb)
<Keybuk> so we have fbcon
<Keybuk> and vga16fb is good enough for plymouth
<Keybuk> but isn't good enough for X
<Keybuk> -- 
<cnd> Keybuk: the problem is there's a race condition we've seen where vga16fb will still get /dev/fb0 (bug 518387)
<Keybuk> how we'd LIKE to do it:
<ubot3> Malone bug 518387 in linux "vga16fb sometimes claims fb0 before kms driver, a causing blank screen on boot" [High,Confirmed] https://launchpad.net/bugs/518387
<Keybuk> cnd: why would it cause a blank screen?
<cnd> Keybuk: sorry, thought you were done, continue
<Keybuk> if fb0 is vga16fb, that should imply that vga16fb is also what the fbcon is bound to
<Keybuk> and it's what plymouth will draw to
<cnd> Keybuk: probably some interaction between nouveau and vga16fb
<Keybuk> so vga16fb winning should mean you lack KMS but not lack anything on screen
<Keybuk> ok
<Keybuk> so...
<Keybuk> what we'd PREFER to have been doing
<Keybuk> grub can set video modes via VBE, and can payload those into the kernel so the kernel knows a video mode has been set
<Keybuk> if that happens, the kernel uses the "efifb" built into it
<Keybuk> (since EFI's "the video mode is set" code is apparently so similar to VBE, it works with BIOS+VBE :p)
<Keybuk> so we'd boot with efifb
<Keybuk> this fails right now because fbcon is a module for some reason
<Keybuk> if fbcon were built-in (like it is on arm, ports, etc.) then we would win
<Keybuk> but with it as a module, if you have a boot failure before the module is loaded, you never see anything on screen after grub
<Keybuk> so, we'd like GRUB to set the video mode, payload it into the kernel, kernel uses efifb from its own init, with a built-in fbcon
<Keybuk> so we have a true colour framebuffer from the get go on all of our platforms
<Keybuk> but then the real KMS driver loads
<Keybuk> and that needs to kick out and transition the console from efifb to i915/nouveau/radeon/etc.
<Keybuk> some of that code is in our kernel
<Keybuk> but there are "it didn't work, make it work" bug fixes in .33 and .34
<pmatulis> on hardy, is there any chance of adding support for a HP 10 Gb network card (HP NC522SFP; http://is.gd/aYF2r) ?
<Keybuk> I suspect that's the same hand-off code you're talking about for vga16fb
<pmatulis> module (netxen_nic) is in hardy but it doesn't work
<cnd> Keybuk: so efifb would be kicked out with the code we have in the kernel, bug vga16fb can't be kicked out like that
<Keybuk> cnd: efifb is not kicked out reliably with the code we have in the kernel *now*
<cnd> Keybuk: either way, we still have the issue that vga16fb can't be kicked out using that framework (I think)
<cnd> because the vga16fb aperture is a hardcoded 64K block of physical memory
<Keybuk> right
<cnd> but the vga16fb aperture is different than what's used by the hw fbs
<Keybuk> yes
<Keybuk> vga16fb is a wildly different type of framebuffer
<cnd> so the vga16fb uses 0xA0000-0xB0000, but that never overlaps the nouveau fb at 0x80000000-<blah>
<Keybuk> if you were talking to fb0 before, you'd be in planar mode
<Keybuk> and most likely doing raw VGA16 opcodes
<Keybuk> to suddenly have that switched to being a KMS-driven true-colour packed pixel fb would not work so well <g>
<Keybuk> https://bugzilla.kernel.org/show_bug.cgi?id=15151
<ubot3> bugzilla.kernel.org bug 15151 in Video(DRI - non Intel) "Black screen after loading nouveau module" [Normal,Closed: code_fix] 
<cnd> yeah, so basically efifb, with that fix, can be kicked off
<Keybuk> yeah
<cnd> but vga16fb can't be kicked off because its aperture will never overlap with hw-specific fb apertures
<Keybuk> though then we'd have to test things like what if grub had the wrong resolution, how do we deal with resolution changes in plymouth, X, etc.
<Keybuk> but once we solve that, and we have efifb => native fb (or just efifb all the way) then we have a great story
<cnd> so my thought was: if there's ever another fb loaded, kick off vga16fb
<Keybuk> there's always a framebuffer on x86, always a fbcon, X can always fallback to fbdev
<Keybuk> we only ever do one more switch at grub, we can have grub paint purple ubuntu logos so there's no black screen during boot
<Keybuk> cnd: but how do you kick it off?
<Keybuk> and more to the point, how do you deal with the fact that userspace may have started using the vga16fb fb0?
<cnd> Keybuk: in the same code that kicks off other generic fbs, just do it without checking the aperture overlap for vga16fb
<Keybuk> cnd: but that isn't the same
<Keybuk> that's my point
<Keybuk> the "other code" works by handing over fb0
<Keybuk> so fb0 never vanishes
<Keybuk> just between instructions, the driver that's dealing with it can change
<Keybuk> one minute you're drawing to efifb, the next you're drawing to nouveau
<Keybuk> but you never know
<Keybuk> (modulo resolution changes, etc. see above)
<Keybuk> but you can't hand over fb0 from vga16fb to nouveau
<Keybuk> as you pointed out, the aperture is wrong
<Keybuk> the size of that aperture is wrong
<Keybuk> the resolution is almost certainly wrong
<cnd> Keybuk: This is the diff that does the hand off: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4410f3910947dcea8672280b3adecd53cec4e85e;hp=b586640141ab5f4ab3b194419bc2c0f039e91dbc#patch3
<Keybuk> and vga16fb is a planar framebuffer, not a packed pixel framebuffer! :D
<Keybuk> so the code you use to write it is completely different!
<cnd> there's nothing complex there, you just unregister the generic one and register the hw one in its place
<cnd> I don't see why you can't just do the same for vga16fb, the only difference is you wouldn't check the aperture bounds first
<Keybuk> because it'd crash any app talking to that framebuffer?
<cnd> oh wait, I see what you're saying now
<cnd> it's all because the aperture wouldn't be consistent across the transition
<Keybuk> right
<Keybuk> from a kernel POV that patch is almost certainly a good idea
<Keybuk> but from a userspace POV, it won't work at all
<cnd> yeah
<Keybuk> I see fb0 turn up, it's vga16fb
<Keybuk> so I mmap the VGA aperture, and I start drawing on it
<Keybuk> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/plymouth/lucid/annotate/head:/src/plugins/renderers/vga16fb/vga.h#L43
<Keybuk> that's example code from Plymouth that deals with vga16fb
<Keybuk> see how it's actually talking directly to the VGA? :p
<Keybuk> if you rip that frame-buffer out, and replace it with a packed pixel one, plymouth will just crash and burn
<Keybuk> and so would X if that was running
<Keybuk> etc.
<cnd> Keybuk: so what do we do if we see that Ubuntu is failing on all nvidia dual gpu systems like in the bug?
<Keybuk> the reason that aperture check is there in the hand-off code (aiui) is precisely because efifb/vesafb and nouveau/etc. *are* compatible
<Keybuk> if you had fb0 mapped from efifb, you have the same address mapped as nouveau would map
<Keybuk> so you can carry on regardless
<cnd> yeah
<Keybuk> cnd: well, I'd actually investigate why the nouveau module isn't creating the framebuffer first
<Keybuk> that seems a bit odd
<Keybuk> we already wait for nouveau init to return before trying vga16fb
<JFo> cnd, bug 539878 was the one I meant to show you the other day when I was pinging you on LVDS stuff.
<Keybuk> if nouveau init guaranteed it had made its framebuffer before returning, vga16fb would be always fb1
<ubot3> Malone bug 539878 in linux "nouveau out of sync LVDS (basically card not supported)" [High,Triaged] https://launchpad.net/bugs/539878
<JFo> sorry for the oversight
<cnd> Keybuk: my guess (I could be wrong), is that the probe is asynchronous to the init
<cnd> so nouveau inits and registers itself as the module, as does vga16fb
<cnd> before nouveau_probe is called
<Keybuk> cnd: yes
<cnd> maybe you can add a spinlock or some such so the init doesn't return until the probe finishes, but that sounds messy
<Keybuk> fwiw, it doesn't sound like the other drivers are async init
<Keybuk> and it doesn't sound like nouveau is in the single-card case?
<Keybuk> is it the single-card with dual-gpu case?
<Keybuk> or the dual-cards?
<cnd> not sure
<Keybuk> because I have a thought
<Keybuk> about dual-cards
<Keybuk> bear with me a sec:
<Keybuk> dual-cards have, err, dual cards
<Keybuk> the first card is a PCI graphics card, the second is a PCI graphics card
<Keybuk> what might happen is:
<Keybuk> PCI announces first card
<Keybuk> we modprobe nouveau
<Keybuk> nouveau doesn't pick it up (nothing plugged in maybe?)
<Keybuk> we modprobe vga16fb
<Keybuk> vga16fb takes fb0
<Keybuk> PCI announces second card
<Keybuk> nouveau picks it up, takes fb1
<cnd> Keybuk: sounds plausible, though I'm not sure how that could be fixed...
<Keybuk> right :-/
<Keybuk> it's a bugger
<Keybuk> I do actually have dual nvidia cards here, so I can test :p
<Keybuk> (and nouveau didn't work for me - this may be why)
<cnd> Keybuk: now that I actually look at the bug some more, they don't even have nouveau loaded
<cnd> so no wonder things didn't work...
<cnd> oh wait, it's an intel bug
<cnd> hrm...
<smb> Keybuk, cnd, So I guess this is in good hands between the two of you. At least I understand why we don't want to get rid of vga16fb and that kicking off is not a good idea. 
<cnd> Keybuk: doesn't seem like we have useful data for that bug yet, the only data we have is pre 2.6.32-16 when we switched to .33 drm
<cnd> Keybuk: the one thing we could do is forbid vga16fb from loading if there's already a fb
<cnd> apparently, if you run lshw as root on a vt, it does something to vga16fb even if it's /dev/fb1 and causes issues (bug 527369)
<ubot3> Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369
<Keybuk> possibly
<zul> csurbhi: ping any progress on #276472?
<Keybuk> cnd: the other obvious fix
<Keybuk> vga16fb is loaded by alias
<Keybuk> on load, it could check whether the device is one of those supported by nouveau, i915 and radeon, and simply return without enabling
<Keybuk> actually
<Keybuk> that would mean no splash for the nvidix-glx crowd
<cnd> Keybuk: that's fine for ubuntu, but not in general, cause what if the modules aren't available?
<Keybuk> in which case - don't ship vga16fb anyway
<Keybuk> which is a "clear with sabdfl" issue
<JohnFlux> smb: your email didn't have any sort of attachment
<JohnFlux> smb: was it supposed to?
<smb> JohnFlux, no, there were two other mails send as threaded mails
<smb> [PATCH 1/2] Staging: rt2870: Add USB ID for Buffalo Airstation	NFinitiWLI-UC-GN
<smb> [PATCH 2/2] Staging: rt2870: Add USB ID for Ralink 2070L
<JohnFlux> oh I see.  git fixed that behave to add them as replies
<JohnFlux> hmm, maybe not in a release version of git though
<JohnFlux> *released
<JohnFlux> s/behave/behaviour/
<smb> JohnFlux, It seems to work. Though Thunderbird is often no so cooperative when they seem to arrive in the wrong order to it
<JohnFlux> smb: gmail doesn't handle it at all
<JohnFlux> smb: Anyway, upgrade git when the next release comes out :-)
<JohnFlux> smb: and thanks
<smb> JohnFlux, Heh, ok. Np, I try to get it into next upload (path 1) as sort of pre-stable. The other one I really would love to see some confirmation first
<JohnFlux> can you post your .deb  somewhere?  And i'll ask people to try them directly?
<JohnFlux> people are more likely to click on .deb than spend a whole day to compile and patch manually
<smb> JohnFlux, Yes that was the plan. I will upload it to some place and add the pointer to the bug
<JohnFlux> thanks
<cnd> Keybuk: any chance we can skip to efifb still :)
<Keybuk> cnd: not enough time to test all the permutations
<cnd> there doesn't appear to be any locking when you register a fb, so I don't even see how we can reasonably do checks for vga16fb after hw fb
<Keybuk> right now we have an issue with a simple story => "have this bug? blacklist vga16fb"
<Keybuk> we'd be swapping it for a can that we haven't opened yet, and may contain worms
<cnd> yeah
<cnd> and for the lshw issue, I think we just need to fix lshw so it doesn't do whatever it's doing to the vga16fb framebuffer
<Keybuk> right
<cnd> smb: I'm getting somewhat lost in lxr, do you know if driver probe functions are called serially in all cases?
<cnd> cking, amitk: ^?
<cking> cnd, sorry, no idea on that
<smb> cnd, IIRC probing can be parallelized. And you have some helpers to wait for certain groups. 
<cnd> I'm wondering how register_framebuffer gets away without any locking...
<smb> cnd, apw / csurbhi have been looking into loading the ramdisk in parallel. There would be a patch for that in Lucid. Maybe that helps
<cnd> smb, I'll take a look
<cnd> hmmm, can't find anyting in git log
<amitk> cnd: probing is parallelized as smb said
<cnd> amitk: would you have any idea how register_framebuffer (called from probe functions) gets away without have any locking?
<smb> If there is only one of its kind...
<cnd> my guess is that most people don't have multiple framebuffers enabled
<smb> Could be
<cnd> but we'll have two in our kernel (hw and vga16 fbs)
<cnd> smb: module loading is serialized, and we know that vga16fb is a module. What do you think of an ubuntu sauce patch just for lucid that keeps the vga16fb from registering if there's another fb already registerd
<cnd> It could fail to work properly if vga16fb were compiled in statically, but it would fix bug 527369 in lucid, and we're likely to move to efifb for M per Keybuk
<ubot3> Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369
<smb> cnd, I am a bit undecided atm. Or not sure to be able to think of all implications.
<cnd> smb: if it makes you feel any better it would be a one-line patch :)
<smb> cnd, If you think you can do a patch quite quickly, maybe do that and we discuss it on the ml
<cnd> k, already got the patch built, just need to test
<smb> Even those can have drastic effects. :)
<cnd> yeah
<smb> I wonder whether there could be a case where another fb is loaded but would not be usable but vga16fb would
<cnd> smb: if that were the case, we'd probably have bigger issues, cause I assume everything in user space is trying to use /dev/fb0
<cnd> Keybuk, any thoughts ^^?
<Keybuk> everything is trying to use fb0
<Keybuk> but I don't think you patch will help
<Keybuk> you say that vga16fb is claiming fb0 and that is the problem
<Keybuk> if it's claiming fb0, then that means that no other framebuffer is registered at that time
<Keybuk> so your patch is a no-op
<Keybuk> all your patch would do is stop fb1 appearing as vga16fb when we already have a framebuffer
<cnd> Keybuk: I'm trying to solve a different problem
<cnd> where vga16fb is /dev/fb1
<cnd> no one should be using it
<cnd> but if you run sudo lshw, it opens it
<cnd> and corrupts the hw framebuffer
<cnd> so my change would prevent vga16fb from registering /dev/fb1
<Keybuk> ok
<Keybuk> that sounds reasonable to me
<cnd> ok, I'm going down to test, be back in a few (hopefully)
<mjg59> Hm
<mjg59> This sounds like a failure in resource allocation
<mjg59> (an unsurprising one, but still)
<mjg59> vga16fb should really be going through the vga arbiter
<mjg59> Which should claim the resources
<mjg59> And then refuse to let vga16fb bind if another driver is already there
<cnd> mjg59: looks like I was rebooting while you were typing
<cnd> what did I miss?
<mjg59> 16:38 < mjg59> Hm
<mjg59> 16:38 < mjg59> This sounds like a failure in resource allocation
<mjg59> 16:39 < mjg59> (an unsurprising one, but still)
<mjg59> 16:39 < mjg59> vga16fb should really be going through the vga arbiter
<cnd> smb: Keybuk: patch worked, vga16fb failed to load
<pabelanger> Afternoon.
<cnd> mjg59: the issue is that vga16 has a hard coded aperture location (64K at 0xA0000) that is separate from where the modern aperture locations are
<mjg59> cnd: That's what the vga arbiter is for
<cnd> ahhh
<cnd> I looked at vgaarb last night, but it didn't seem related
<pabelanger> If I have distcc setup, and used the 'fakeroot debian/rules binary-...' script, would I have to do anything special to make it use distcc? Or would environment variables be enough
<cnd> mjg59: still, even if it should be using vgaarb, that would require a rewrite of vga16fb, right?
<mjg59> cnd: Yeah
<mjg59> Which isn't high on my list of requirements :)
<cnd> understandably so :)
<cnd> mjg59: we'll be pushing to move away from vga16fb for M anyways, if I understood Keybuk right
<cnd> so a quick and dirty hack for Lucid may be the best option given the Lucid timeframe
<Keybuk> bearing in mind of course that the pushing to move away is to something we figured out only last week :p
<mjg59> Ha. What?
<Keybuk> abusing efifb ;)
<mjg59> There's no real functional difference between efifb and vesafb
<mjg59> You end up with the same suspend/resume issues
<mjg59> That's why we went with vga16fb rather than vesafb
<mjg59> (way, way back in the day)
<Keybuk> ah right, that's interesting to knpw
<mjg59> Both just give you access to an unaccelerated linear framebuffer
<Keybuk> the suspend/resume issue being "can't reset the mode"?
<mjg59> The only difference is how you got that - with efifb you've got a mode set by the bootloader, with vesafb you've got a mode set by the kernel on entry
<mjg59> efifb has no way of resetting a mode on resume
<mjg59> You could potentially reset a vesa mode, but that depends on being lucky in vbios implementation
<Keybuk> how does efifb reset the mode when you VT switch out of X?
<mjg59> It doesn't
<Keybuk> (or vesafb for that matter)
<mjg59> X is responsible for reprogramming the original mode
<Keybuk> ahh, right, I know this
<mjg59> The advantage of vga16fb is that if you hit the hardware before it's initialised, you tend to just get your port io timing out
<mjg59> Whereas with vesa, you're writing to a region of memory that may now be used by the card for something else entirely
<Keybuk> right, because it can move across a suspend/resume
<mjg59> Yeah, you have no idea what state the card is in on resume
<mjg59> With vesafb, you can freeze the framebuffer before suspend, try reprogramming it with vbetool on resume and then unfreeze it
<mjg59> But with efifb, you don't know what mode you were in to start with...
<mjg59> (Note that the freeze/reprogram/resume thing helps but does not fix this issue)
<Keybuk> yeah
<Keybuk> it almost becomes easier to declare that we don't support suspend/resume if you install nvidia-glx
<Keybuk> and remove the menu options <g>
<mjg59> nvidia will typically manage suspend/resume itself, as long as it's entirely in control of modesetting
<mjg59> Which means no console framebuffer with the exception of vga16fb
<bryceh> JFo, sounds right
<bryceh> JFo, I think we've been tagging them needs_pll_quirk or some such
<JFo> bryceh, yeah, I see the descriptions with that in
<bdrung^2> what's the status of the lucid kernel regarding SSDs? Is TRIM supported in ext4?
<pmatulis> lastlog -clear
<pmatulis> will there be another point release of 8.04 ?
<smb> Just for the (public) record: not one I am currently aware of. The last I know was beginning of this year
<crimsun> manjo: for bug 548371, your mic switches are muted again. Did you uncheck the sound preferences and untick (unmute) the mic in the Input tab?
<ubot3> Malone bug 548371 in pulseaudio "[LUCID] Samsung N310 External microphone unable to record sound." [Undecided,New] https://launchpad.net/bugs/548371
<manjo> crimsun, yes I did 
<manjo> crimsun, I even increased the input to 1/2 way 
<crimsun> manjo: can you rerun http://www.alsa-project.org/alsa-info.sh, please?
<manjo> crimsun, yes can do ... give me 10mts to reboot that netbook again 
<crimsun> to conference, will check back
<manjo> crimsun, uploaded info you asked for 
<RAOF> Argh!  Die, vga16fb, die!
<RAOF> I don't suppose we can flip around our vga16fb system?  Currently we have a patch adding an alias so that vga16fb bind to any VGA device - could we instead make drivers that won't provide kms manually add vga16fb?
<RAOF> Man, that was broken English.
#ubuntu-kernel 2010-03-26
<Sarvatt> is it a known issue that theres no linux-backports-modules for 2.6.32-17 in the archives yet?
<MTecknology> Sarvatt: it's in the pocket
<MTecknology> so.. it shoulda been there already
<JohnFlux> woohoo!  Suspend works now on my machine :-)
<JohnFlux>  It didn't work in 9.10  but does in 10.04
<JohnFlux> I love you guys! :)
<JohnFlux> Why do drivers released by companies have such poor quality?
<johanbr> if you're talking about closed-source drivers, it seems like the authors often have a less than perfect understanding of how to interface with the kernel properly
<JohnFlux> even GPL'ed drivers
<JohnFlux> The released ralink driver doesn't compile because they removed MODULE_LICENSE("GPL") at the last moment
<JohnFlux> it contains a serious flaw that lets root the system remotely
<johanbr> oh that... yes, ralink is a mess
<JohnFlux> It spams the syslog with the message "#"  once for every packet!!
<JohnFlux> The email addy bounces
<JohnFlux> but I've seen this mess elsewhere
<JohnFlux> I worked for a company writing video drivers for SGX
<JohnFlux> people keep pushing us to release the code for the driver..  but there's a good reason we don't show anyone it.. :-D
<johanbr> right :)
<johanbr> I think opensource encourages good programming practices
<JohnFlux> we used RCS, and actually sent customer patches as a Word document!
<JohnFlux> with instructions to copy and paste the text, then manually fix the smart quotes..
<johanbr> yikes :)
<JohnFlux> when I left, last year, they were planning to upgrade to CVS
<JohnFlux> they still haven't though :-D
<johanbr> maybe they got rid of the Word patches at least :)
<JohnFlux> no, I tried to at least automate the process..  but no luck
<syn-ack> Seriously, *word*?
<syn-ack> man, I could understand something like notepad or wordpad but *word*?!!? /me shudders
<crimsun> bjf: patch for #303789 sent to stable and upstream
<amitk> smb: the d-i patch, shouldn't it say modularise instead of de-modularise?
<smb> amitk, Yes Andy should have known better. Thats how those patches are now in the repo. I won't rewrite history
 * amitk doubts andy's english skills, he's english after all 
<smb> (and actually we all failed to spot it in looking at the patches. /me included)
<smb> amitk, MY language skill get bad in any language given the time of day is late enough. ;-P
<amitk> there has to be a better way to create our d-i modules files automagically - comparing config file changes to d-i changes is painful
<amitk> smb: do you know if PATA_SIS == module(pata_sl82c105.ko)?
<amitk> I guess I can look at the Kconfig help text
<smb> amitk, I created the list from the modules I found on my build system.
<smb> There are a few that are different between amd64 and i386 but I hope this catches all
<amitk> smb: some discrepancies
<amitk> PATA_SIS is enabled in the config, but not in d-i
<smb> Ok, I should add that then
<amitk> In Sata:
<smb> amitk, Hm, pata_sis? I only see sata_sis.ko
<amitk> smb: I see a PATA_SIS enabled in debian.master/config/config.common.ubuntu
<amitk> sata looks good
<smb> amitk, For some reason the PATA_SIS ends up being built in...
<smb> amitk, Need to check the lower config files
<amitk> smb: you're right, I missed the =y, so yes it is built in
<amitk> so according to config, the d-i is correct.
<smb> amitk, Though I wonder whether this should also becom =m
<amitk> whether or not PATA_SIS should be built-in or not is a separate story
<smb> yeah
<smb> I make a sticky-note for apw
<smb> amitk, I just want that d-i change out and in today as this breaks a good deal of things
<amitk> smb: ack away
<smb> amitk, Many thanks
<JohnFlux_> smb: Hey man
<smb> JohnFlux_, mornin
<JohnFlux_> smb: I'm going to ask a very stupid question..  what does "Fix Committed" mean ? :-)
<JohnFlux_> smb: This means it's now a patch in the ubuntu kernel, right?  But not yet accepted by the staging drivers guys upstream?
<smb> JohnFlux_, :) That I put the patch into our git tree. When it gets uploaded and released it will become fix released
<smb> The status has nothing to do with upstream. Just internal workflow
<JohnFlux_> smb: got ya.  We added 0x0411, 0x015D     but I'm seeing the occasional post about the same thing also being   0x0411, 014F
<JohnFlux_> smb: e.g.  http://forums.ncix.com/forums/index.php?mode=showthread&msg_id=2026623&threadid=2026623&forum=105&product_id=37959&msgcount=0&overclockid=0
<smb> JohnFlux_, I plan to do an upload late today. So it should become available latest next week. For some things I need other people to do it, so it can get delayed.
<JohnFlux_> smb: Should I update  https://help.ubuntu.com/community/HardwareSupportComponentsWirelessNetworkCardsBuffalo   to change the status to working?
<smb> JohnFlux_, If there are other IDs, those should get filed as separate bugs. Nothing worse that one bug with plenty of different "oh and this ID too"
<smb> JohnFlux_, Maybe wait for the official kernel to be available for that
<smb> Just being paranoid. ;-)
<JohnFlux_> smb: hum, it seems easier to just add them now and see if we get bug reports about them
<smb> JohnFlux_, And again, the official kernel will not contain the ID for that ralink 2070L
<JohnFlux_> official ubuntu kernel, or official linus's kernel?
<JohnFlux_> oh right, the 2070
<JohnFlux_> Hopefully I can get someone else to confirm it works in time
<JohnFlux_> but..   what's the harm?
<JohnFlux_> we know that this is the driver that should be used
<JohnFlux_> we know that it _should_ work
<JohnFlux_> and we know that without the change, it certaintly won't work
<JohnFlux_> so what's the harm in just adding it?
<smb> JohnFlux_, Exactly _should_. I like to be _certain_
<JohnFlux_> smb: I can be _certain_ that it won't work without it
<JohnFlux_> smb: how's that for certain? :P
<smb> JohnFlux_, Not enough to convince me. :-P
<JohnFlux_> smb: I don't really get why not :P  Seems a very obvious choice between "certaintly won't work" and "probably should work"
<smb> JohnFlux_, But I won't carry a patch that _might_ work. If it _does_ work it should go upstream, but I won't bother Greg with something that maybe works
<JohnFlux_> okay
<amitk> JohnFlux_: we don't carry "probably works" patches. They has to be verification that it works.
<JohnFlux_> is there a way to force a driver to work anyway for a given usb id?
<smb> JohnFlux_, I think there is a bind file in sysfs for each driver, which you can echo IDs into...
<amitk> JohnFlux_: http://lwn.net/Articles/143397/
<amitk> JohnFlux_: apologies, that was for driver binding, this one is for adding a new ID: http://www.ha19.no/usb/
<smb> amitk, Good find. I just was about to mention new_id
<JohnFlux_> very interesting
<JohnFlux_> smb: http://ubuntuforums.org/showthread.php?p=9030092#post9030092   someone said that your kernel doesn't boot for them?
<JohnFlux_> smb: they mentioned that they have an eepc though
<JohnFlux_> 'mounted root fs can not mount /dev/pts and something else cant mount rootfs'
<JohnFlux_> Does this error mean anything to anyone ?
<smb> It seems to be unable to find or mount the root file system and another virtual fs. Why is hard to say. Have you tried the kernel I made?
<smb> Probably not as you had a working kernel before
<JohnFlux_> smb: sorry, this is what someone else said
<JohnFlux_> smb: I haven't actually tried your kernel :-)
<JohnFlux_> smb: I pasted that error from that link I just gave
<smb> But the information is not very detailed. Could be something gone wrong installing. Could be something in the build. But its just the usual build with two more patches
<smb> I have seen that. But its hard to tell more
<JohnFlux_> smb: might be something related to the EEPC ?
<smb> I would doubt it. If they had been running Ubuntu before...
<cnd> how do you delete a chroot after you don't need it anymore?
 * cnd doesn't need lucid chroot now that I'm running lucid
<smb> cnd, You could rm -rf and remove the entry from the config. But I would still keep it as its a better controlled environment
<cnd> smb, good point, but not good enough when I need to conserve space :)
<cnd> since I do most of my kernel builds on emerald.mills anyways
<cnd> well, all my builds really
<smb> cnd, How can one be so tight on space. I hardly was able to by a laptop hardrive below 250G nowadays. :-P
<smb> cnd, But as said. You can edit /etc/schroot/schroot.conf and remove the lucid entry
<smb> and then just remove the directory where you installed the chroot
<pmatulis> are there recent kernels (PPA) i can try on 8.04? there is "Using newer kernels on LTS releases" in LP but it says the project is "closed"
<smb> cnd, Just make double sure, that nothing has bind mounted /home somewhere in it
<cnd> smb: macbook has 120GB, ~80 is used by os x (which I don't really use anymore, but need to keep around), and I have the rest split between main partition and test partition
<cnd> smb: good call
<smb> pmatulis, I don't think so.
<ogasawara> manjo: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/507148 - will you be able to test the upstream patches?
<ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] 
<smb> manjo, Have you tested with the -17 kernel on that?
<Keybuk> so tempted to do a companion blog to cking's blog of awesome
<Keybuk> "system calls and C library functions you didn't know about"
<Keybuk> today I found statfs()
<cking> Keybuk, I only blog about obscure stuff so I can google search it later :-)
<Keybuk> cking: and as a result, your blog is one of the most useful ones in the known universe ;-)
<cking> you're too kind
<Keybuk> more particularly, I know this trick
<Keybuk> stat("/") => info
<Keybuk> stat("/dev") => dev_info
<Keybuk> if info.st_dev != dev_info.st_dev:
<Keybuk>   then dev is mounted
<cnd> smb, so about that acpi patch that upstream isn't biting on, I still think it should go into lucid
<Keybuk> better trick, just statfs("/dev") :-)
<cnd> smb: http://patchwork.ozlabs.org/patch/47164/
<smb> cnd, I think I remember the one about the warning level for those resource conflicts
<cnd> smb: yep
<smb> cnd, Hasn't mjg59 acked that sort of? No I guess just said it would be ok
<cnd> smb: right, he just seemed to agree in principle at the time
<cnd> but I'd be happy to have mjg59 ack it (wink wink)
<cnd> :)
<smb> cnd, If nothing happens, we might go and take it as a sauce patch for now. But I guess I will leave that to the time apw gets back
<cnd> smb: ok, just want to make sure it's not left until it becomes too late for inclusion
<smb> cnd, No its still clearly visible on our list 
<cnd> I'm just new to the process, so I figure it's better to be safe than sorry
<cking> Keybuk, that's a trick worth documenting
<cnd> amitk: what was your methodology for determining which power saving features to put into powersave-policy?
<cnd> I'm curious if there's anything else that didn't do much for you, but maybe works well for others?
<cnd> overall though, I'm not seeing a huge difference in power consumption with the extra policy scripts
<amitk> cnd: the first step was just to make laptop-model-tools redundant. There are a few more script in laptop mode tools that were very hacking and/or too intrusive
<amitk> s/hacking/hackish
<cnd> amitk: so we've basically taken everything from laptop-mode-tools that seems reasonable?
<amitk> cnd, yes IMO. I'll send you an email listing why I didn't pick the others.
<cnd> amitk: thanks
<ogasawara> JFo: can you add bug 532374 and bug 548513 to our list for monday
<ubot3> Malone bug 532374 in linux "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend" [Critical,Confirmed] https://launchpad.net/bugs/532374
<ubot3> Malone bug 548513 in linux "Firewire disks not working under 10.04" [Critical,Confirmed] https://launchpad.net/bugs/548513
<JFo> ogasawara, will do
<smb> cking, Isn't that your pet area nowadays? ^
<JFo> ogasawara, done
<ogasawara> JFo: thanks. robbiew asked that we get them on our radar.
<JFo> no problem
<cking> smb, yes jerone asked me to eyeball that when I was on vacation. It's on my ever growing list
<JFo> and I just made the list huge
<JFo> Kernel Regression Bug Day schedule announced in e-mail
<smb> cking, I wonder whether we might be allowed to volunteer you to have a look after that
<cking> please do
<smb> JFo, ^
<JFo> ok, for the bug call on Monday?
<pgraner> cnd: you want to save power? Turn of the bling, doing that on my netbook saved almost 2watts
<cnd> pgraner: bling?
<JFo> smb, that for the firewire one?
<pgraner> cnd: bling == compiz
<smb> JFo, If its on that list cking would have the best insight I think (no the i7)
<pgraner> cnd: putting the gpu into 2d mode makes a big difference
<cnd> pgraner: I have a feeling people would get upset if we started flipping compiz on and off every time you plug in and out of ac
 * cking notes that disabling video and ssh'ing in helps save power too :-)
<pgraner> cnd: yea since now it tends to gather you desktops onto one
<pgraner> cking: you're so damn old school
<pgraner> cking: X for me is nothing more than a VT arranging utility
<cnd> pgraner: do you know how to disable compiz and 3d on demand?
<cking> pgraner, I'm happy with a serial console ;-)
<cnd> I'd like to try it personally just to see how effective it is
<pgraner> cnd: nope, talk to bryceh 
<pgraner> cnd: or one of the desktop guys
<JFo> smb, ok
<cnd> compiz for netbook edition seems overkill if I can get 2W back
<cnd> since it only uses 10W right now anyways
<cking> http://smackerelofopinion.blogspot.com/2009/11/improving-battery-life-on-hp-mini.html is my powersaving hack
<cnd> and it should help with flash
<cking> and also: http://smackerelofopinion.blogspot.com/2009/06/reducing-wifi-beacon-interval-to-save.html
<pgraner> cnd: if your running compiz you can use: metacity --replace  & compiz --replace to switch between them
<pgraner> cnd: I'm supposing you want to test it in the scripts?
<cnd> pgraner: nope, just running metacity
<cnd> pgraner: no, just for personal usage
<cnd> and documenation
<pgraner> cnd: well thats how you switch inbetween them
<cnd> ok
<crimsun> amitk: / cnd: hmm, I see (using cnd's pm-utils-powersave-policy 0.4~powersave2) that powerdown is now enabled for all hda when on battery -- that annoying pop will return for non-IDT/Sigmatel codecs
<crimsun> that was the reason for the earlier check for the idt module
<cnd> crimsun: yeah, Keybuk mentioned it, and I forgot to remove the script in powersave2
<crimsun> ah ,ok
<cnd> crimsun: unless there's some easy way to check for good codecs in the script?
<cnd> though in that case, it should just be on all the time
<crimsun> cnd: yes, in the original, I check for the existence of the module dir in /sys
<cnd> and besides, this is targetted at M, at which point the popping should be sorted out for all the codecs right?
<crimsun> sec, will pull the diff
<crimsun> cnd: ah, so it's not for Lucid?
<cnd> crimsun: no, it's too late for Lucid
<crimsun> ah, then that's no big deal :-)
<crimsun> cnd: yeah, just a simple [ -e $CODEC -a -w $PD ] currently (where $CODEC is /sys/module/snd_hda_codec_idt)
<cnd> crimsun: so in M, the popping will be fixed for all codecs?
<crimsun> cnd: kernel version-dependent, but yes
<cnd> crimsun: what do you mean?
<crimsun> cnd: well, there's the assumption that 2.6.32-2.6.34 won't be chosen
<cnd> crimsun: ok?
<crimsun> cnd: so with a sufficiently new kernel, then yes, those symptoms are fixed
<cnd> how new are we talking? .34 isn't out yet
<cnd> is there some patch waiting in the wings for the .35 merge window?
<crimsun> yes, I have updates for the conexant and realtek ones
<crimsun> there were a number of realtek ids added since 2.6.32
<cnd> ok
<cnd> even if M is based on .34, we'd likely take a look at the patches anyways
<cnd> especially if it's just a matter of ids at that point
<crimsun> ok
<cnd> amitk: what about laptop_mode itself?
<cnd> doesn't laptop-mode-tools enable that? pm-powersave doesn't yet
<marga> Hi!  I'm a Debian person (user, developer, etc), but I'm trying to help an Ubuntu user, that has a 32bit user space Ubuntu installation, with a 64bit processor.  In Debian we have an -amd64 flavor, for 64 bits processors with the i386 userspace.  By looking at the Ubuntu flavors for i386, the one that is 64bits -apparently- is -server... What is special about -server? Can it be used by a 64bit desktop?
<amitk> cnd: yeah, that should be enabled too
<cnd> amitk: I reread the spec, and laptop_mode shouldn't be enabled by default per Ted T'so due to interactions with ext4
<cnd> so we look good there
<cnd> amitk: thanks for the writeup!
<cnd> helps explain many questions I had
<nosse1> Hi. I'm trying to build a kernel for an ARM target. Where can I find a "standard" set of kernel config which represents what ubuntu requires from the kernel?
<manjo> ogasawara, on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/507148 building and testing the kernel on jdstrand's laptop 
<ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] 
<ogasawara> manjo: cool, thanks
<manjo> ogasawara, was busy with several audio bugs ... so results will be after lunch ... 
<ogasawara> manjo: k thanks, just mainly wanted to know the status for the release meeting
<manjo> ogasawara, ah ok... 
<crimsun> manjo: for #548371, your Mic Boosts are still set at zero
<crimsun> (...unless you're just pasting outdated alsa-info output?)
<manjo> crimsun, no the last one I posted was with  ubuntu audio dev ppa 
<crimsun> manjo: I mean that you're running the script when the capture is not occurring
<crimsun> same for #528719, BTW
<manjo> hmmm so what is that amixer option to boost it ? 
<manjo> crimsun, ^  ?
<crimsun> manjo: (sorry, I'm at a conference currently) for which bug?
<manjo> should I do amixer set 'Capture',1 cap
<crimsun> manjo: for #528719, it's amixer set 'Mic Boost' 100%,100%
<manjo> ok
<crimsun> similar for #548371 but you also need 'Front Mic Boost'
<manjo> crimsun, after the boost I still get white noise 
<manjo> crimsun, I hear my voice very very faintly.
<crimsun> manjo: for which hw?
<manjo> acer
<manjo> #528719
<manjo> crimsun, on the aspire1 
<manjo> Simple mixer control 'Mic Boost',0
<manjo>   Capabilities: volume penum
<manjo>   Playback channels: Front Left - Front Right
<manjo>   Capture channels: Front Left - Front Right
<manjo>   Limits: 0 - 3
<manjo>   Front Left: 3 [100%]
<manjo>   Front Right: 0 [0%]
<manjo> how do I boost  Front Right: 0 [0%] to 100% ? 
<crimsun> manjo: err, did you use the syntax above?
<manjo> yes
<crimsun> huh. Well, just 100%
<manjo> ok that made both 100%
<crimsun> bah, bug in amixer :-(
<manjo> ok tried after setting that.... and again .. white noise with faint recording of the sound 
<manjo> crimsun, btw the bug is only when using external mic, and does not occur with built in mic 
<manjo> crimsun, I have used 2 diff mics to make sure its not the mic hw
<crimsun> manjo: ok, please update the bug reports, respectively. I'm having a difficult time tracking irc and conference simultaneously, sorry
<manjo> crimsun, no problem! will update
<crimsun> I should have a free stretch in two hours
<cnd> bryceh: I'm looking at bug 544741
<ubot3> Malone bug 544741 in linux "[X700] KMS, amd64: Kernel panic while trying to launch system > preferences > appearance" [High,Triaged] https://launchpad.net/bugs/544741
<cnd> I saw your email about edid quirks
<cnd> actually, let me read the email once again, and I'll get back to you
<mozmck> How do I create a new flavour of the lucid kernel?
#ubuntu-kernel 2010-03-27
<mozmck> how does one compile the lucid git kernel?
<mozmck> in the karmic tree I could do this: skipabi=true skipmodule=true fdr binary-generic
<mozmck> but that doesn't work on the lucid tree
<crimsun> mozmck: have you followed the wiki?
<crimsun> bah.
<crimsun> Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
<crimsun> Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1
<crimsun> that makes me a sad panda
<mozmck> crimsun: wiki where?  I've looked at several places
<crimsun> wiki.ubuntu.com/KernelTeam/KernelMaintenance
<mozmck> I can't figure out how to compile one flavour.  if I do debian/rules binary it looks like it will compile all flavours
<mozmck> here's what it says there "fakeroot debian/rules binary-generic"
<mozmck> that's what I'm doing and it says there's no rule for that target
<crimsun> I presume you've looked through debian.master/config/ ?
<mozmck> yes.  I made a new flavour, but I've also tried just compiling the generic flavour with out changes
<mozmck> hmm, just tried again with binary-generic and it's working...
<mozmck> ok, I ran debian/scripts/misc/kernelconfig editconfig and didn't save any changes.  then fdr clean and fdr binary-generic and it tells me "No rule to make target"
<mozmck> at the end of running kernelconfig it gave me 8 of these errors:
<mozmck> ./debian/scripts/misc/kernelconfig: line 150: /home/moses/Projects/kernel/ubuntu-lucid//scripts/misc/../config-check: No such file or directory
<mozmck> could that be the problem?
<crimsun> debian/scripts/config-check
<mozmck> it's there and executable
<mozmck> is it possible the kernelconfig script is broken?
<crimsun> possibly, but I'm not looking closely. Slew of bugs on my plate.
<mozmck> ok, thanks.
<Sarvatt> cnd: the two lines removed by the DPMS load detect fix exist in the current ubuntu-lucid source
<Sarvatt> lines 3666 and 3775 in drivers/gpu/drm/i915/intel_display.c
<Sarvatt> which is why I said the patch mistakenly got dropped somewhere along the line, it is not upstream yet even in 2.6.34
<Sarvatt> thats in reference to http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=7b56712ff524ee55e38afaee3954d125f56a6070 
<jono> hey folks
<jono> is the 	linux-image-2.6.34-020634rc1-generic_2.6.34-020634rc1_i386.deb package known to boot?
<jono> I installed it to test if a a bug still exists and it would not boot
<mrec> hope that won't happen with the latest git build here
<jono> going to test againbrb
<mozmck> anyone know why running kernelconfig editconfig with the lucid git breaks my build?
<Sarvatt> the 2.6.34-rc1 mainline kernel doesn't boot here either
 * Sarvatt tries the latest daily, havent tried in a few weeks
<jono> hey
<jono> just tried the .34 mainline and no luck
<mrec> mainline or git?
<johanbr> for that matter, why do the latest daily builds have a -karmic suffix?
<Sarvatt> the latest 2.6.34 mainline daily still fails to boot here, spits out a trace as soon as it starts and seems to be timer init related
<Sarvatt> i'm guessing the ones with -karmic are using the karmic config and the -lucid ones are using lucid's, and there hasnt been any lucid ones recently. they were all using karmic's config before
<Sarvatt> correction: there haven't been *any* lucid ones, the one there failed to build because it was trying to use apparmor
<jono> mrec, mainline
<jono> is there an actual PPA for the kernel?
<marga> I asked this yesterday, but got no-reply.  I'm interested in a -generic-64bits kernel for the i386 arch (similar to -amd64 in the i386 arch in Debian).  I've seen that there is a -server flavor, which is only 64bits, but it's supposed to be "server oriented".  What does "server oriented" mean?
<mrec> my git kernel is still compiling..
<Sarvatt> marga: ubuntu doesn't support a 64 bit kernel with 32 bit userspace at all as far as I know unlike debian, the server flavour doesn't exist for 32 bit and is just a transitional package to push people to one of the generic-pae kernels if they had it installed in 32 bit from an old release
<Sarvatt> i could be mistaken though
<mrec> you should be wrong
<mrec> skype works without any problem here
<mrec> and skype is 32bit
<mrec> file /usr/bin/skype
<mrec> /usr/bin/skype: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
<Sarvatt> i'm referring to using explicitly installing a 64 bit kernel in a 32 bit release
<mrec> ah
<mrec> well I tried using a 64bit kernel with 32bit environment it worked too
<mrec> (I upgraded my system from a 32bit ubuntu to a 64bit ubuntu that way with some fiddling around with chroot and moving the root files)
<mrec> didn't have usb nor cd for a 64bit install cd back then
<Sarvatt> yeah you can get it working somewhat but a lot of things will be broken like dkms and its not something thats supported. http://www.ubuntu.com/products/whatisubuntu/serveredition/features/kernel has some description of whats different in -server over -generic
<mozmck> anyone know why running kernelconfig editconfig makes it so running fakeroot debian/rules binary-generic (or any other flavour) says "No rule for target"?
<mozmck> on lucid git
<marga> Sarvatt: is there a rationale behind that?
#ubuntu-kernel 2010-03-28
<mozmck> ok, I found the problem with the kernelconfig script.  line 30: bindir="`pwd`/${DROOT}/scripts/misc"
<mozmck> but DROOT is not set
<mozmck> so I added: DROOT=debian to debian/debian.env and kernelconfig now works
<Q-FUNK> apw: hi!  any suggestion for bug #241307 ?
<ubot3> Malone bug 241307 in linux "[Geode SC] [DBE60] kernels >= 2.6.22 fail to boot [A20 interrupt]" [High,In progress] https://launchpad.net/bugs/241307
<psusi> I have a fairly reproducible kernel hang while unmounting.  this time while the unmount was hung, I tried sysrq-s to sync and the whole system hung for a few minutes.... got a sysrq-t during this time... what else should I try to do to find out more about the problem and report it?
<psusi> ahh, looks like it's already reported as bug #543617
<ubot3> Malone bug 543617 in linux "very slow filesystem I/O" [Undecided,Confirmed] https://launchpad.net/bugs/543617
#ubuntu-kernel 2011-03-21
<fairuz> Hi, I got this when booting a linux kernel, http://pastebin.com/W7YyBM2n .. any idea?
<jjohansen> fairuz: what does your grub entry look like
<fairuz> jjohansen: I use uboot actually
<fairuz> jjohansen: you need something like this? console=ttyO2,115200n8 mem=456M@0x80000000 mem=512M@0xA0000000  root=/dev/mmcblk0p2 rw rootdelay=2 init=/init vram="10M"  omapfb.vram="0:4M"
<jjohansen> fairuz: ah did you get a typo in /dev/mmcblk0p2 maybe?
 * jjohansen has very little experience with current arm
<jjohansen> uboot etc
<jjohansen> hrmm no, I see it mounted okay
<fairuz> jjohansen: the /dev/mmcblk0p2 is correct
<jjohansen> yeah
<fairuz> jjohansen: it's just somehow can't start init?
<jjohansen> sorry no ideas, here.  Though I expect I will have some better ideas in a week
 * jjohansen has an arm box coming this week
<fairuz> jjohansen: cool
<jjohansen> fairuz: which os?
<fairuz> jjohansen: android
<fairuz> jjohansen: froyo
<jjohansen> maybe /sbin/init?
<fairuz> jjohansen: i'll try that
<fairuz> jjohansen: I don't think so since the init executable is in /
<jjohansen> fairuz: okay, well it was worth a shot, my next suggestion was mounting somewhere else and checking the init was in /
<fairuz> jjohansen: btw, what init will do exactly? because i see there are the init exec, and also some .rc files such as init.rc, init_omap4430.rc etc
<fairuz> these files are useful to init?
<jjohansen> fairuz: I assume so
<jjohansen> :)
<jjohansen> fairuz: it really depends on the init system
<jjohansen> basically the kernel will exec init and then init can do what it wants
<jjohansen> traditionally that is controlled /etc/init and .rc files etc
<jjohansen> init will exec processes to take care of the rest of boot
 * jjohansen has never played with android, so /me is not sure what their boot sequence is like
<jjohansen> does the /init file has exec permissions?
<fairuz> jjohansen: yes
<jjohansen> what does file init report?
<fairuz> jjohansen: sorry but I dont get what you mean. You mean the init log file or something like that?
<jjohansen> no, run the file command on the init binary
<jjohansen> eg.
<jjohansen> > file init
<jjohansen> init: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
<fairuz> jjohansen: I have some other problems. Will get to you later. Btw, thanks for the help, really appreciate it.
<jjohansen> fairuz: np, I hope you get it working, /me is interested as I expect to be having similar fun
<fairuz> jjohansen: what arm platform you will be getting btw?
<jjohansen> efika mx
<fairuz> jjohansen: nice
<fairuz> I got 2.6.38-00366-g65e01eb when i do uname -r. Is it weird or normal? :D
<fairuz> Maybe I compile it wrong?
<fairuz> I installed linux-headers-2.6.38-1204 but why it doesnt appear in /lib/modules/ ? 
<jk-> fairuz: the -headers package doesn't provide any modules; what are you looking to find in /lib/modules?
<fairuz> jk-: the headers file 
<jj-afk> fairuz: linux-headers only installs into /usr/src/
<fairuz> jj-afk: ok, my bad ty
<jk-> fairuz: the headers will be in /usr/src/linux-headers-$version/
<jk-> (there should be a symlink from /lib/modules/$version/build though)
<jk-> fairuz: for future reference, `dpkg -L <package>` will list the files installed by a package
<fairuz> jk-: Ah ok, thats will be useful
<fairuz> I got Kernel Configuration is invalid error when compiling module using my new 2.3.38 kernel
<fairuz> Hi, I got error: unknown field 'ioctl' specified in initializer when compiling a module on 2.6.38
<fairuz> It compiles OK on 2.6.35
<fairuz> Hmm they stop supporting ioctl in the file_operations?
<fairuz> I found the solution in the git log, have to change ioctl to unlocked_ioctl :D
<ogasawara> I'm doing one final upload of the natty kernel before beta due to the new compiler, any last minute patches we need? (as long as they're not ABI bumpers)
<tgardner> ogasawara, how about the CONFIG_NR_CPUS patch thats still on the mailing list?
<tgardner> bug #737124
<ubot2> Launchpad bug 737124 in linux "Support workstations with greater than 64 cores" [Medium,In progress] https://launchpad.net/bugs/737124
 * ogasawara looks for it
<tgardner> ogasawara,  CONFIG_NR_CPUS appears to be an ABI bumper
<ogasawara> tgardner: just out of curiosity, did that CONFIG_NR_CPUS patch accidentally get dropped along the way?  Looking at bug 706058, it looks like it was previously applied?
<ubot2> Launchpad bug 706058 in linux "amd64 x86-64 boot fails with more then 64 CPUs" [Undecided,Fix released] https://launchpad.net/bugs/706058
<tgardner> ogasawara, I think it was -server only
<apw> yeah it was only server we applied it for
 * apw isn't here
<tgardner> ogasawara, rather, it was only applied to -server
<ogasawara> tgardner: hrm, was hoping to not have an ABI bumper.  Can it wait till post beta?
<tgardner> ogasawara, yep, I thingk so
<ogasawara> tgardner: ack, I'll shove it on master-next then and just do a no-change upload of the kernel for the new compiler
<tgardner> ogasawara, fire away
 * ogasawara slaps forehead.  pulled the trigger too soon with the upload.
<ogasawara> I should actually wait for the compiler to finish building for the other aches, sigh
<mterry> What's the most useful way to report a kernel panic?  I don't see anything in /var/crash, and I don't get an apport prompt
<Krunch> mterry: do you have the full oops message?
<mterry> Krunch, I didn't write it down from the screen, no...  Is it written on my disk anywhere?
<cnd> anyone know where to submit patches for latencytop?
<Krunch> mterry: it might be in the kernel logs (/var/log/kern.log on Debian, not sure for Ubunut) if you are lucky but probably not
<Krunch> mterry: without the oops message or the vmcore, there is probably not enough to write a bug report
<cnd> actually, it looks kinda dead...
<Krunch> mterry: look into netconsole to send the oops message (and all the console messages) to a remote system
<soren> mterry: I usually take a photo with my phone and attach it to a bug report.
<Krunch> and depending on the oops message, that might not be enough either
<mterry> soren, good idea
<mterry> Krunch, k, thanks.  (/var/log/kern.log is also there in Ubuntu, btw)
<fairuz> Hi, if I do sudo dpkg --unpack file.deb, where the unpacked files will go?
<sforshee> fairuz, I believe they go to the same locations as if you installed the package
<bjf> fairuz, dpkg --extract unpacks them in the current folder
<fairuz> sforshee: I found them in /boot 
<fairuz> bjf: ok ty
<diwic> cnd, hmm, isn't latencytop maintained by the Redhat Realtime group (or whatever they call themselves)?
<cnd> diwic, maybe, but they have no info about that on their website
<cnd> I have no clue who is the maintainer or how to contact them...
<cnd> no changes to their git tree in 17 months either...
<fairuz> When I do sudo flash-kernel, I got cannot find default kernel in /vmlinuz or /boot/vmlinuz ..... I got 3 different vmlinuz in my /boot
<diwic> cnd, hmm, actually it says Intel Open Source Group on the homepage...
<diwic> cnd, so I'm correcting myself, the Redhat people probably does the hard realtime stuff rather than this
<diwic> cnd, from the git tree looks like arjan@linux.intel.com and benh@kernel.crashing.org have several commits in there, so start by emailing them directly and ask where to submit patches? 
<cnd> diwic, probably, but I'm just doing patch piloting
<cnd> and the patch fixes a type in the man page
<cnd> so I'm reluctant to put too much effort into it :)
<diwic> cnd, ah, ok. Well, just send it to those two people and see what happens :-)
<tgardner> ogasawara, I rebased Natty master-next against master and added the CONFIG_NR_CPUS=256 patch (after a bump ABI)
<ogasawara> tgardner: ack, thanks
<tgardner> ogasawara, I worked on a set of build scripts while in London a couple of weeks ago that I haven't really advertised much. You might want to give 'em a  spin. kteam-tools/buildscripts/ukb-make*
<ogasawara> tgardner: cool, I'll take a peek
<ogasawara> tgardner: ukb-make works well for me
<tgardner> ogasawara, cool. the only issue I've noted so far is an inelegant error when the armel chroot isn't supported,. like on Lucid amd64 hosts.
<tgardner> actually, natty armel schroots on Lucid build hosts
<sconklin> ogasawara: welcome back!
<ogasawara> sconklin: thank :)
<ogasawara> thanks even
<lil_pete> hey guys do you happen to know why my usb-bus doesnt detect devices if i plug them in after (!) booting? they work perfectly well when plugged in before booting... :-(
 * tgardner --> lunch
<cking> kentb, that vida is now en-route back to Dell
<cking> cough
<kentb> cking, thanks :)
<xuru> howdy, I'm trying to build a kernel with a few changed options (CONFIG_SYSFS_DEPRECATED=y, etc), and I keep running into an error when I build it.  Here is the commands I used and the output:  http://paste.pocoo.org/show/357263/
<xuru> when I do the make mrproper, it seems to blow away the debian directory
<jjohansen> xuru: yes you will need to mv the debian and debain.master directory out of the source directory when you run mrproper and then you can mv them back
<xuru> ok
<xuru> any idea what's causing this in the first place?
<xuru> seems to be pretty strait forward following https://help.ubuntu.com/community/Kernel/Compile
<jjohansen> xuru: I can't remember but it does show up occasionally, especially if you poke the kernel build system without specifying it should dump thing in the debian/build directory
<xuru> ok, I'll try doing the make mrproper and copying those files back
<xuru> interesting...  I did a 'make mrproper' and then copied the debian* directories back, then did a build (forgetting to copy my .config back) and it's building fine
<xuru> so it must be one of the two options I set that are causing the build error
<xuru> I'll try adding in each one at a time and see
<sforshee> xuru, it's probably the presence of the .config file that's causing the error
<sforshee> there's a section on the page you linked to about how to change config options
<xuru> oh?  must have missed that
<sforshee> xuru, it's a little hidden, it's under "Modify the source for your needs"
<xuru> ok, I thought that was just if you were making a special non-generic kernel
<xuru> so x86_64 == ia64 or amd64?
<jjohansen> amd64
<xuru> k, thanks
<xuru> is there a way to point make menuconfig to that config file?
<xuru> nevermind, I can use the load alternate configuration option right?
<xuru> is debian.master/config/config.common.ubuntu read in first?  and then debian.master/config/amd64/config.common.amd64?
<ogasawara> bjf, sconklin:  I think an incorrect version of a CVE patch I sent to the ml was applied to hardy master-next, care if I just fix it up?
<ogasawara> bjf, sconklin: it's for "econet: Fix crash in aun_incoming(). CVE-2010-4342"
<ubot2> ogasawara: The aun_incoming function in net/econet/af_econet.c in the Linux kernel before 2.6.37-rc6, when Econet is enabled, allows remote attackers to cause a denial of service (NULL pointer dereference and OOPS) by sending an Acorn Universal Networking (AUN) packet over UDP. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4342)
<bjf> ogasawara, go for it, that's what "master-next" is all about and we have started a new cycle
<bjf> ogasawara, so we won't look at master-next until next week some tim
<bjf> ogasawara, s/tim/time/
<ogasawara> bjf: cool
<tgardner> ogasawara, whats wrong with it?
<ogasawara> tgardner: struct dst_entry *dst = skb_dst(skb);
<ogasawara> tgardner: skb_dst() isn't defined in Hardy
<tgardner> ogasawara, doh! I bet I used the Karmic patch.
<tgardner> bjf, sconklin, shall I upload the Lucid/Maverick LBM packages with the new compat-wireless 2.6.38 support ?
<bjf> tgardner, i think that's ok with me
<sconklin> I can't think of a reason not to
 * bjf -> lunch
<kirkland> tgardner: is there a known reason why my CPU's load never goes below 1.00 on natty?
<kirkland> tgardner: system is totally idle
<kirkland> tgardner: but the lowest /proc/loadavg ever says is 1.00
<kirkland> tgardner: model name      : Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
<tgardner> kirkland, none that I know of. lemme check,
<tgardner> kirkland, here is a dual CPU: 13:49:41 up 1 day, 19:52,  1 user,  load average: 0.00, 0.01, 0.05
<kirkland> tgardner: hrm
<kirkland> kees: when you were here, you pointed me toward something that might have to do with my load-never-goes-below-1.00 problem...  I can't remember what it was, though
<kirkland> kees: aha, found it in my log
<kirkland> tgardner: ah, i see:
<kirkland> $ ps auwwx | grep " D "
<kirkland> root       701  0.0  0.0      0     0 ?        D    09:07   0:01 [ips-monitor]
<kirkland> tgardner: what is ips-monitor?
<tgardner> kirkland, intel power save (I think)
<kirkland> tgardner: https://lkml.org/lkml/2011/3/19/37
<tgardner> intelligent power sharing
<kirkland> tgardner: https://lkml.org/lkml/2011/3/21/237
<kirkland> tgardner: so it is "phantom" load, as suspected
<kirkland> tgardner: still, annoying;  looks like Intel is looking for a fix
<tgardner> kirkland, yep. 
<kristian-aalborg> hi all, has anyone gotten apmd working?
 * ogasawara back on later
<Specialist> hi all! quick question: whch target do i need to build for an ubuntu kernel using debian/rules to get the linux-headers*_all.deb (binary-generic does not produce that deb)?
<jjohansen> Specialist: do fakeroot debian/rules binary-headers binary-generic 
<Specialist> jjohansen: thanks!
#ubuntu-kernel 2011-03-22
<DavidReza> Hi everybody, I need some help. I have installed several kernels (because of updates and so) and whenever I try to load Ubuntu with those kernels, I always get te screen as if I had pressed Ctrl+Alt+F1, so I can see all the outputs of the instructions being executed until I see some kind of error saying: nohup: ignoring input and appending output to `nohup.out'. After that, my laptop just seems like if it was in standby
<DavidReza> and I can never use the recent kernels. I always got to enter with the 2.6.25 kernel
<ohsix> that sounds like the X server isn't starting, could be drivers or user configuration or just plain broken stuff
<ohsix> if you're using an X driver that's had UMS removed and you're disabling KMS on the kernel commandline that can happen too
<DavidReza> ohsix, as I don't think it can be something about my configuration, because I can use this other 2.6.25 kernel, don't you think?
<DavidReza> about this UMS thing removed and disabling KMS, I don't really know what you are tlaking about =/
<ohsix> video driver features change between kernel versions
<DavidReza> Look, here's the thing. Since I wanted to install Ubuntu by first time. My display gone black. I tried several times to install Ubuntu, until I found that the DVD was working, but my display wasn't. I used an external display, installed Ubuntu, and installed the nVidia private drivers. That way I could enter Ubuntu in my own display. I could never use the nouveau drivers, and yesterday I was told about how to make nouveau work on my laptop. Th
<DavidReza> ere is a guide I'm following, and I need this 2.6.38rc8 kernel. I have already installed it. But I couldnt enter with thtat kernel. BUT because I was having some problems with my nVidia drivers, I decided to open a virtual TTY (Ctrl+Alt+F2) and reinstalled my nVidia drivers. I just reboot and I could finally enter with this new kernel! What I want to really know, is what is this happening?
<DavidReza> why is this happening*
<ohsix> nouveau should be blacklisted if it doesn't work on your device, then plain vesa would be used and you still get a display; if you install the nvidia drivers manually it's all up in the air, you should use the packaged version or (assuming it actually boots without the nvidia stuff around on a clean install) jockey, which will offer to do it for you on first boot
<DavidReza> Actually nouveau WAS blacklisted
<ohsix> then vesa should have at least given you something :\
<ohsix> do you have an /etc/X11/xorg.conf?
<DavidReza> yeah, but I assume it will have information about nVidia
<ohsix> if so, paste its contents to paste.ubuntu.org, or try and summarize its contents
<DavidReza> by the way, what did you mean with jockey?
<ohsix> right, afaik; most of the automatic magic (including picking vesa as the lowest common denominator) depends on certain sections not being defined in xorg.conf
<DavidReza> http://paste.pocoo.org/show/357486/
<ohsix> the "Additional Drivers" applet in system -> administration, it's name is jockey, and if there are drivers available from a 3rd party for a device, it will show up in your notification area telling you about it on first boot with something like "Additional drivers for your hardware are available"
<DavidReza> oh, I get it.. yes, I was told there was a privative driver from nVidia, I also tried that one, but didn't work
<ohsix> ok, that config would constrain that busid to only that driver, so nv, nouveau or vesa wouldn't work automatically with it present
<DavidReza> ok, let me see if Im getting this...
<DavidReza> when I install a new Kernel, it expects to use vesa, nouveau or nv, and since I have my xorg.conf with nvidia, it fails?
<ohsix> the kernel doesn't expect anything, but since yuo're not using the distro packages for the nvidia drivers it isn't rebuilt automatically for new kernels, so when you switch the kernel side of the nvidia driver isn't present
<ohsix> you could uninstall the nvidia blob, rm the xorg.conf, install the distro package and it should work for kernel version changes
<DavidReza> sorry, english is not my native language, what you mean with "install the distro package" ? Which package?
<DavidReza> Actually that's what I wanted. Install the nouveau driver and make it work. That's why I need this kernel. I just wanted to know why this happened
<ohsix> one moment
<DavidReza> you alaready told me the answer, hehe
<ohsix> you shouldn't have to install nouveau; if it can work it will work with no xorg.conf present iirc
<DavidReza> What will work with no xorg.conf? The kernels? 
<ohsix> picking the appropriate driver automatically, so X starts with at least one of them
<DavidReza> ohh
<DavidReza> but I assume it won't use the nvidia one..right?
<DavidReza> and nouveau is blacklisted, so it will use vesa
<ohsix> it could, i don't know; i don't have an nvidia card in anything with ubuntu on it, if you currently have a working display, just start the "Additional Drivers" applet and tell it to install the nvidia drivers
<DavidReza> even when I have installed manually the drivers from nvidia.com?
<ohsix> sure, it will just overwrite them
<DavidReza> ok
<DavidReza> I'm gonna try that
<ohsix> with basically the same driver, but one that is known by the package manager, and will rebuild kernel parts when a new kernel is installed; thus be expected to work
<DavidReza> I will also remove nouveau from the blacklist
<DavidReza> oh.. so this will work when I install new kernel versions?
<DavidReza> not now?
<ohsix> if the blacklist isn't something you added you should probably leave it alone; the things that come with the distro know what devices it's safe to run them on
<ohsix> it should rebuild it for all your kernels when you install it; i just meant in the future, when another kernel is installed
<DavidReza> the thing is that nouveua got blacklisted when I installed the nVidia drivers mannually
<ohsix> i see, then it should probably be removed; but if you use jockey it will be using the nvidia drivers, if you want to try nouveau; you'll need to uninstall the manually installed drivers, the xorg.conf and whatever blacklists it added
<DavidReza> ok
<DavidReza> if I want to try the additional drivers, you told me they will remove the nvidia drvers I installed, but.. should I remove the xorg.conf?
<ohsix> yes, remove xorg.conf
<DavidReza> ok
<DavidReza> I really appreciate you help
<DavidReza> uhm,.. I got another question
<DavidReza> Why is this nohup message appearing? I realized that when I'm inside Ubuntu, and pressing Ctrl+Alt+F1, it takes mee to the black screen with the messages at the beginning and the last line is the same one
<DavidReza> nohup : ignoring input and appending output to `nohup.out'
<ohsix> those are messages from the boot scripts, i don't know of any package in particular that uses nohup, so i can't point directly to what it is
<DavidReza> I got confused because that means this error is always in there, even when I could enter in the X server
<ohsix> nohup just detaches the ran program from the terminal so it isn't killed when the terminal is closed, if you could find the nohup.out file, it'll contain program output messages and you might be able to infer what is doing it
<DavidReza> yeha, I already know that
<DavidReza> the file contains like 1 million (It never finishes loading)
<DavidReza> with the instruction cat /sys/class/backlight/acpi/sony/brigthness
<DavidReza> and saying the file couldn't been founded
<DavidReza> I DO know that has relation with the fact the brightness doesn't work
<ohsix> ah, i can't say much about that
<DavidReza> ok, thank you anyway, I learned something else today
<DavidReza> thank you very much ohsix 
<DavidReza> I'm gonna try few things with the drivers and the kernel
<michael_lf> Hi, folks, I want to install Fjalar(which is under Valgrind) into my Unbuntu 10.10(with glibc version 2.12.x), but the tools  only support glibc(2.0~2.10), then I donot know how to solve this? anyone who can provide an help?
<DavidReza> see you
<serious__sam> hey guys when will kernel 2.6.37 with scheduler patch will be available on ubuntu?
<fairuz> Hi, morning. Can't we do 2 kernel compilation in parallel? It seems to me just one compilation progress and the other freezes until the other one finishes.
<jjohansen> fairuz: sure you can compile 2 kernels in parallel
<fairuz> jjohansen: it's my PC then 
<jjohansen> fairuz: the ubuntu kernel build scripts do take advantage of machine parallelism by default
<jjohansen> ie. fakeroot debian/rules binary-generic will launch make -j N_CPUs
<fairuz> jjohansen: I'm using a remote cross compilator, maybe it slows things a bit
<jjohansen> so what you are seeing is probably the build scripts already taking advantage of your system resources
<jjohansen> yes
<fairuz> jjohansen: all kernel sources are in /usr/src?
<jjohansen> fairuz: if you install the kernel-source and linux-headers packages that is where they are placed
<jjohansen> if you get the sources via git then, its where ever you put your git tree
<fairuz> jjohansen: understood. But yesterday I tried to use a function defined in one of the kernel files (cache-l2x0.c) to be exact, but during compilation it says the function is undefined. What should I do to be able to use the functions?
<fairuz> I use this command make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -C ../kernel-seb M=$(PWD) modules .... where ../kernel-seb is a clone of a git tree
<fairuz> Anything special to make it work?
<jjohansen> fairuz: so your building a module, is the function exported?
<fairuz> jjohansen: Sorry, how should I know if it's exported?
<fairuz> jjohansen: in the header file, there is no prototype of the functions. So I just do extern thefunction() in my module. 
<jjohansen> fairuz: for a symbol to be usable by modules that aren't built into the kernel they must be exported using the EXPORT_SYMBOL or EXPORT_SYMBOL_GPL macros
<jjohansen> extern is not enough
<fairuz> jjohansen: ok. So in the cache-l2x0.c file, I should see something like EXPORT_SYMBOL thefunction() if the function is exported?
<jjohansen> right, eg. EXPORT_SYMBOL(posix_unblock_lock);
<fairuz> jjohansen: If that's not the case, is there any way to use the function? Do I need to build the module into the kernel?
<jjohansen> fairuz: you either need to build it into the kernel, patch the kernel to export the function, or find an indirect way to invoke what you want
<fairuz> Or can I just hack the file and export the function myself, then rebuild the kernel? 
<jjohansen> yep
<fairuz> jjohansen: ok, as I thought.
<fairuz> jjohansen: hmm.. old kernel source can't be downloaded on launchpad? https://launchpad.net/~tiomap-dev/+archive/trunk/+buildjob/2114099
<lifeless> not from ppas
<lifeless> too much churn, too much disk
<jjohansen> fairuz: if you want the old source use the git tree
<jjohansen> you can checkout arbitrary points after a kernel release
<jjohansen> before the kernel release, rebasing against upstream is used so you may not be able to replicate alpha and beta release kernels
<fairuz> jjohansen: ok, i have to find the omap4 git tree first :D
<jjohansen> fairuz: https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide?action=show&redirect=KernelTeam%2FKernelGitGuide
<fairuz> .35 is maverick?
<jjohansen> fairuz: in the natty tree its the ti-omap4 branch
<fairuz> jjohansen: ok thanks!
<jjohansen> fairuz: looks to be the same in the maverick tree
<fairuz> jjohansen: differences between natty and maverick? kernel version?
<jjohansen> fairuz: maverick is 2.6.35 based kernel for a release distro, natty 2.6.38 based kernel for release that is about to go into beta
<fairuz> jjohansen: ok
<jjohansen> fairuz: with that said the omap4 topic branch may differ more than the rest of the kernel
<jjohansen> it actually may even be based on another kernel version, /me is not sure of its current state
<jjohansen> I know at least one of our arm branches was based on a different kernel version than the rest of the distro
<fairuz> jjohansen: Right now, I'm using .35 on my board and it works well. I will try to compile and see if it boots well too or not
<jjohansen> fairuz: yeah omap seems to be fairly well supported, TI has been fairly good about pushing patches upstream
<fairuz> jjohansen: I tried .38, but it's kinda weird. Sometime it boots sometime it not. 
<jjohansen> fairuz: well .38 just got released so if you tried before that then you were using an RC which tend to be buggy, /me expects we will get a .38.1 or .38.2 before natty is released, with even more bug fixes
<jjohansen> but if .35 is working for you there is no reason to move to .38 unless there is a specific feature you need that .35 lacks
<fairuz> jjohansen: in fact there is. Things like Perf tool on ARM is not fully supported in .35
<fairuz> jjohansen: since I tried .38 and it's not very stable. I just thought to patch .35
<fairuz> at least I know .35 works
<jjohansen> fairuz: ah, then I would try .35 make sure your build is working etc, and then try on .38
<jjohansen> basically I think you want to stick with a known working kernel but it doesn't hurt to try .38, from time to time to see if its stablized for you
<fairuz> jjohansen: yes
<fairuz> jjohansen: I cloned about four .38 tree before coming to that conclusion too :D
<fairuz> linaro tree, official tree, TI internal tree etc
<jjohansen> fairuz: ah, which board?  Panda? /me thought that was supposed to be fairly stable
<fairuz> jjohansen: yes panda. It's fairly stable but sometimes it does give me some problems (doesn't boot, sometimes giving kernel messages in the serial port etc)
<fairuz> jjohansen: Maybe it's me who don't do things right. 
<jjohansen> fairuz: hrmmm, well maybe but I doubt it, there has been a lot of churn in the kernel
<fairuz> jjohansen: i cloned maverick tree but I dont found any omap4-ti branch
<fairuz> jjohansen: I can just build it on master branch?
<jjohansen> fairuz: you need to clone the branch locally too
<fairuz> jjohansen: oh git clone does not take all the branches>
<fairuz> ?
<jjohansen> git checkout --track -b ti-omap4 origin/ti-omap4
<jjohansen> use that in your git tree
<jjohansen> it will create a local ti-omap4 branch that tracks the remote origin ti-omap4 branch
<fairuz> jjohansen: ok 
<jjohansen> if you use git remote show origin, it will list off which branches are remote, or tracked
<jjohansen> oh and when you are building make sure you are in the correct branch
<jjohansen> git branch
<jjohansen> will tell you if you are on the ti-omap4 branch
<fairuz> jjohansen: ok cool. ty
<jjohansen> and git checkout <branch name> will let you switch branches
<fairuz> jjohansen: i'll try to compile now
<fairuz> jjohansen: for each branch, they can have different tag if I do git tag, or it's the same
<jjohansen> fairuz: err sort of, tags are just names for sha-1 hashes
<fairuz> jjohansen: do I have to pull tags for ti-omap4 branch? 
<jjohansen> fairuz: no
<fairuz> jjohansen: ok
<fairuz> Can I specify the kernel name before compilation so I will not get something like 2.6.35.3-00029-gc0381cb?
<fairuz> Since I already have the headers for 2.6.35-980-omap4, I would like my newly compiled kernel to have the same name
<fairuz> Can I specify the kernel name before compilation so I will not get something like 2.6.35.3-00029-gc0381cb? Since I already have the headers for 2.6.35-980-omap4, I would like my newly compiled kernel to have the same name
<guampa> hello people, quick q regarding make-kpkg
<guampa> after a couple runs it started appending some kind of serial at the end of the kernel and debs names
<guampa> its not the --append-to-version string i added, (it adds it too before the serial)
<guampa> i end up with some rather cumbersome naming for the kernel and packages, how can i disable it or find some info about it?
<fairuz> guampa: Are you searching to rename the Kernel name? me too =(
<guampa> asking now in #debian, wish me luck!
<fairuz> guampa: if you have some answers, care to share it here :D
<guampa> no luck :(
<guampa> my uname -r and debs are all 2.6.38-customstring-06603-g10effcb
<guampa> i cleaned, cleaned with debian/rules, even re-branched
<fairuz> guampa: same here :(
<fairuz> guampa: Btw, I'm recompiling my kernel
<guampa> yeah i'm about to fire it again
<guampa> had working my ati with kms and all and now it started to stuck at initialization, so i'm in the quest too on what was that i touched
<fairuz> guampa: I'm trying to hard coded the KERNELRELEASE to the Makefile. We will see what happens :D
<guampa> lol, i'm trying something that if works, i'll smashing my head repeatedly with a frying pan
<guampa> i wasnt running "make-kpá¸±g clean" after each new "make xconfig" (!)
 * ogasawara back in 20min
<jj-afk> back on later
 * smb takes over
<jj-afk> smb: glad to see you made it, make that later + 1 hour :)
<JFo> smb, any idea if we plan to add this for natty? http://www.phoronix.com/scan.php?page=news_item&px=OTA5MA
<JFo> tgardner is off today or I would pester him :-)
<smb> JFo, Let me see what the heck it is. :)
<JFo> k :)
<JFo> ralink open wifi driver
<smb> JFo, I usually forget about schedule, but given that we are about a month away from release I would suspect we are either over or shortly before feature freeze. I'd suspect rather over
<JFo> I thought that
<smb> So I would not hold my breath to have it in the release and kernel package. Depedning how it goes it could be something that is in the lbm
<jj-afk> smb, JFo: FF is thursday
 * jj-afk really goes now
<JFo> ah, thanks jj-afk 
<JFo> smb, no, I suspect not if it isn't on our radar
<jj-afk> err, no its not thursday, beta freeze is, FF is way passed, that was like 3 weeks ago
<smb> jj-afk, really has not gone then
<JFo> apparently not :-P
<smb> but thanks anyway
 * jj-afk smacked head walking away
<smb> That would be what I expeckt
<JFo> same here
<JFo> I thought we were past it, but my brain is foggy
<smb> JFo, same here
<JFo> thanks smb and jj-afk 
<smb> So I don't think this is specifically on our rader
<smb> I believe there have been rumors of them maybe doing something
<JFo> ok
<smb> If there is anything in upstream for 2.6.39, then we just will get it as compat-wireless in lbm
<JFo> that makes sense
 * smb is amazed how much mail one can get in between yesterday evening and today...
<JFo> oh yeah, my mail from the weekend and yesterday was crazy
<ogasawara> pgraner: are you a moderator for the kernel-team mailing list?
<smb> Luckily its a lot of duplicates here.
<ogasawara> pgraner: there's some patches Henrik Rydberg sent, but apparently they're being held up since he's not a subscriber to the mailing list
<ogasawara> pgraner: I'd normally hassle tgardner but he's away
<smb> ogasawara, Same with apw but I believe pgraner should be admin too...
<ogasawara> smb: yah, I didn't want to bug apw either :)
<smb> ogasawara, Likely quite hard. He is busily preparing "other things" :)
<pgraner> ogasawara, yep one sec
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<smb> ogasawara, Knowing your speed, do you want (or are already) to apply the patches I just acked, or should I do it? :)
<ogasawara> smb: I can do it.  prolly easier since I've already got em in my trees.
<smb> ogasawara, True enough. Though taking the email an am it is not too badly. But I wanted to avoid being the rabbit discovering the hedgehog is already there. :) Go for it.
<Specialist> hi all... i am currently trying to isolate an ugly suspend/resume kernel bug and am using git bisect to figure out the problematic commit. unfortunately, git bisect picked a revision for me, which does not compile at all. any advice?
<Specialist> ah, just found git bisect skip...
<Specialist> that should hopefully do the trick
<fairuz> Hi, I just change from .35 kernel to .38 kernel. I tried to compile a personal module that works in .35, but in .38 when I try to insmod the module, it gives Invalid module format error.
<smb> fairuz, Did you re-compile the module against .38?
<fairuz> yes
<smb> You would need the right (abi) headers as well. Usually dmesg shows a bit more
<smb> like "disagrees about version or so"
<fairuz> smb: you are correct. Wait i take the output from dmseg
<fairuz> smb: http://pastebin.com/AiAhUr4a
<fairuz> smb: I already installed the headers for 2.6.38-1204-omap4
<smb> fairuz, Hm..I triy to get the difference it complains about...
<smb> fairuz, I am not sure, but one seems to have modversions and one has not...
<fairuz> smb: it's weird since both is pratically similar
<smb> Could it be you compiled one as part of a complete kernel build
<fairuz> smb: anyway to check this modversion?
<smb> fairuz, modinfo with the full path to your module (if it is not in /lib/modules)
<smb> fairuz, Is the module you are building a seperate standalone module or did you make it part of the kernel tree
<smb> ?
<fairuz> smb: standalone
<fairuz> smb: this is modinfo http://pastebin.com/vXXcc14X
<smb> fairuz, So usually if you install the kernel headers package, you should get a Module.symvers in /usr/src/linux-headers-.... Maybe that is not there for some reason
<fairuz> smb: wait i check on that
<smb> fairuz, likely when you look at modinfo of any other module it would have modversion in the string...
<fairuz> smb: I do have Module.symvers in /usr/src/linux-headers-2.6.38-1204-omap4
<smb> fairuz, Hm, though it sounds to me like for some reason, when you compiled your module, it did not find the other module versions. The compile should issue a warning about that but then goes on without. Just that normal modprobe will refuse to load then.
<smb> fairuz, I would propose to do the compile again and check the output for something like this (or maybe it magically works this time)
<bjf> ##
<bjf> ## Kernel team meeting in 30 minutes
<bjf> ##
<JFo> <-food
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-29 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<kristian-aalborg> gentlemen
<kristian-aalborg> or, gentlepersons... I have licked my wounds and is about to try once more 
<kristian-aalborg> jjohansen, kamal hi
<jjohansen> kristian-aalborg: hi
<jjohansen> back for another beating I see :)
 * kristian-aalborg is using the google
<kristian-aalborg> yeah, back for more
<kristian-aalborg> I'm thinking I'm not the first luser to need a few tries
<kamal> kristian-aalborg: as I remember it, you did actually get to the point of a successful build and install right?   good first step for sure.   and yes, I certainly needed a "few" tries before getting the procedure right (or was it a few *hundred*?  ;-)
 * bjf -> lunch
<kristian-aalborg> kamal: tbh, I've dabbled with it before... but newer made a working non-vanilla kernel
<kristian-aalborg> I accidently borked an installation once, though... then I could copy files over when they were needed
<kristian-aalborg> it was really, really fast
<kristian-aalborg> sudo update-initramfs -ck module-name-for-new-kernel
<kristian-aalborg> this is worth a try, I think
<jjohansen> kristian-aalborg: yeah, there was a case or two where that wasn't working right
<jjohansen> at least out of the build scripts
 * jjohansen does that all the time with incremental manual builds where I am skipping the whole packaging system
<kristian-aalborg> it's a fairly simple thing to do
 * kristian-aalborg crosses fingers
<kristian-aalborg> no... sends the computer straight to reboot still
<kristian-aalborg> jjohansen: btw, the "sanity check" worked fine
<jjohansen> kristian-aalborg: well I expected it would but its nice to confirm that it did
<kristian-aalborg> yup
<kristian-aalborg> nah, enough for today
<kristian-aalborg> what I did was I did the "make" stuff until it exited, then I did it again with the no modules flags
<kristian-aalborg> I think I'll try turning that flag on before I do anything the next time, but it won't be today
<kristian-aalborg> ;)
 * ogasawara back on in a bit
<njin> hello bug 739774 system clock is halted but process time go on, can it be a linux issue?
<ubot2> Launchpad bug 739774 in casper "live session from usb key take very long to start (40 min.)" [Undecided,New] https://launchpad.net/bugs/739774
<Specialist> that's probably a beginner's question, but where can i exclude a module from being built when building a kernel using make-kpkg? .config seems to be re-generated during each build...
<DrDetroit> hello
<DrDetroit> I have been having problems with my Ubuntu 10,04 LTS running extreamly slow since my last two updates
<DrDetroit> My previous 2 updates were 2.6.32-30-generic and 2.6.32-29-generic both exhibited the same strange slow behaviour, but I have regressed to 2.6.32-28-generic and have had no reduction in performance.
<herton> Specialist, you must change the config files at debian.master/config directory
<DrDetroit> I have tried top itop and ps aux to try and isolate the issue, but nothing stands out as eating up[ my cpu or memeory
<DrDetroit> Can anyone point me in the right direction to troubleshoot this issue?
<herton> Specialist, in case you're using an ubuntu tree
<Specialist> herton: I don't have such a directory as I am building a vanilla kernel to isolate the root cause of a bug (using git bisect)
<Specialist> unfortunately, the vanilla git tree does not build for each commit, so i'd like to exclude the (unrelated) module, which breaks the build
<herton> Specialist, in this case I believe editing .config and running make oldconfig should do it then
<Specialist> herton: that sounds like it would do the trick (using make-kpkg --config oldconfig), thanks!
<Specialist> hm, unfortunately, it does not. the config is overwritten again on build (putting back the default)
<sforshee> Specialist, I haven't used make-kpkg, but from my reading of the man page that doesn't sound like how it should behave
<sforshee> perhaps another module is selecting the module you're trying to disable ?
<Specialist> ack, but even make oldconfig selects it...
<Specialist> sforshee: is there an easy way to find out?
<sforshee> if another module is selecting it then make oldconfig is going to re-enable it
<sforshee> what's the module you're trying to disable ?
<Specialist> it's CONFIG_TI_ST, which is broken in some early 2.6.36 versions (and does not link correctly)
<Specialist> ERROR: "st_get_plat_device" [drivers/staging/ti-st/st_drv.ko] undefined!
<herton> for CONFIG_TI_ST, probably you have to disable CONFIG_ST_BT also, doing a quick check here
<herton> ST_BT selects TI_ST
<sforshee> yes, that's what I see as well
<sforshee> Specialist, in this case you'd want to grep through all files named Kconfig* for a line matching 'select TI_ST'
<Specialist> herton: thanks, disabling ST_BT did the trick
<DrDetroit> I have been having problems with my Ubuntu 10,04 LTS running extreamly slow since my last two kernel updates
<DrDetroit> My previous 2 updates were 2.6.32-30-generic and 2.6.32-29-generic both exhibited the same strange slow behaviour, but I have regressed to 2.6.32-28-generic and have had no reduction in performance.
<DrDetroit> I have tried top itop and ps aux to try and isolate the issue, but nothing stands out as eating up[ my cpu or memeory
<DrDetroit> Can anyone point me in the right direction to troubleshoot this issue?
<Specialist> DrDetroit: you could try to identify the git commit, which causes the slowdown (not sure how many commits happened from -28 to -29)
<DrDetroit> I am not a programmer or anything like that so I am not sure how to do that
<DrDetroit> I am just an ordinary user
<DrDetroit> I am just stuck
<DrDetroit> since it works fine on 28 generic but not on 29 or 30 its hard to think its a hardware issue
<DrDetroit> i hate to be stuck on 28 forever
<DrDetroit> but i will make sure my grub always keeps the 28 kernel 
<DrDetroit> i have tried to find the problem in the forums but have had little luck
<DrDetroit> How would i identify the git commit?
<sforshee> DrDetroit, usually you'd do a git bisect, but that could be a little much for a non-developer
<sforshee> if you feel up to it, there are instructions at https://wiki.ubuntu.com/Kernel/KernelBisection
<sforshee> otherwise you probably just ought to open a bug in launchpad
<DrDetroit> i hate to open a bug
<DrDetroit> hehe
<DrDetroit> that KernelBisection looks intimidating
<DrDetroit> maybe i will go loolk at launchpad
<DrDetroit> i have never used it either
<sforshee> DrDetroit, if you file a bug against the kernel it's best to do it by running 'ubuntu-bug linux'
<sforshee> that will add a lot of information about your hardware to the bug report automatically
<DrDetroit> do i run that locally or when i get to launhpad
<sforshee> locally, just run it from a terminal on the affected machine
<DrDetroit> ah
<DrDetroit> I figured that if it were a bug, then i would not be the first to have the problem
<sforshee> you can search launchpad first to see if anyone else has reported the same thing
<DrDetroit> ah
<DrDetroit> ubuntu-bug Linux comes back package Linux does not exist
<sforshee> try lower-case l
<DrDetroit> hehe i did
<DrDetroit> thank you 
<sforshee> np
<DrDetroit> i actually dont know if it is a kernel issue
<sconklin> DrDetroit: so this is a problem that you can easily tell if it were fixed, right?
<DrDetroit> absolutey
<DrDetroit> iI have regressed to 2.6.32-28-generic and have had no reduction in performance.
<DrDetroit> I hate to run the later kernels to file the report since it runs so slow
<DrDetroit> hopefully i can explain the issue in the report
<DrDetroit> if the problem exists it will manifest itself usually within 10 min or so
<sconklin> DrDetroit: ok, file a bug and we can do the bisection for you and give you kernels to test. Please be sure to make a comment in the bug listing the latest known kernel that does not have the problem, and the earliest known one that does. 
<DrDetroit> will do
<DrDetroit> iI have regressed to 2.6.32-28-generic and have had no reduction in performance, both the 29 and 30 kernels exhibit really poor performance
<sconklin> This is my favorite type of bug -  we have a reproducer and a willing tester!
<DrDetroit> hehe
<DrDetroit> the testiong phase looks prettyintimidating
<DrDetroit> guess i have to create a launcpad account first
<sconklin> nah, we'll just point you to new kernels to test and you answer yes/no whether they have the problem. It might take 5-8 tests, depending on the number of changes between the known good and bad
<jjohansen> DrDetroit: you didn't run perm iotest did you?
<DrDetroit> no
<DrDetroit> i did run iotop
<DrDetroit> i mean itop
<DrDetroit> i just thought something was hogging my cpu or memory
<DrDetroit> that is usually the issue when machines slow down
<DrDetroit> i just cant figure out what it is
<jjohansen> hrmm, I'll look into that, I had report of a performance regression on the weekend when perf io test where run, that I started looking at, the symptom of absolutely painful performance sounds the same
<jjohansen> DrDetroit: in the case on the weekend, the machine was idle but io through put completely died
<jjohansen> not saying it is the same, and I couldn't reproduce but it does sound similar
<jjohansen> sconklin: the report I had came from the upstream kernel, it was in #apparmor user thought it was AA related but we managed to get that turned off and the regression remained
<sconklin> jjohansen: No proven connection yet, but lucid recently had a pile of scheduler changes go in from upstream stable. I'm looking now to see which version they dropped in
<jjohansen> sconklin: yeah, I'm not sure there was a connection just similar symptoms
<DrDetroit> ok does this help?
<DrDetroit> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/740549
<ubot2> Launchpad bug 740549 in linux "Ubuntu 10.04LTS runs slow after kernel updates" [Undecided,New]
<DrDetroit> i hate to have to continue to run an old kernel
<DrDetroit> and forgo updates
<sconklin> DrDetroit: that's great, thanks
<DrDetroit> i hope its clear the 28 kernel works but 29 and 30 dont work for me
<sconklin> yes, got that
<DrDetroit> ok cool
<DrDetroit> i will hang out here for a day or two just in case you want me to do something
<DrDetroit> i am usually available if i know someone wants me
<DrDetroit> otherwise i end up going outside to enjoy the sun
<DrDetroit> hehe
<DrDetroit> its been wacky weird weather here lately, way to nice for march
<sconklin> you should get email if we update the bug
<DrDetroit> oh ok cool
<sconklin> it's beautiful where I am in North AL
<DrDetroit> i have never filed one before
<DrDetroit> so i dont know what to expect
<sconklin> DrDetroit: nothing left for you to do on this today. Thanks for the report!
<DrDetroit> ok thank you very much for the help
<DrDetroit> is it ok to hang out anyways?
<DrDetroit> i might learn something
<DrDetroit> also i can load up the 29 or 30 kernels and do the same reports if you need me to
<jjohansen> DrDetroit: yeah, we don't mind people hanging out, feel free to drop in any time
<DrDetroit> thanks
<sconklin> yeah, what he said ;-)
<jjohansen> gah, efika messed up their kernel versions
<sconklin> jjohansen, DrDetroit - the big scheduler changes went in back at 2.6.32-25, so that's probably not related
<jjohansen> sconklin: hrmm, no
<jjohansen> we'll just have to bisect it, we have a willing victim^W tester
<sconklin> and DrDetroit, there's no need to submit bug reports for each of the failing kernels. You've already noted the version numbers, which is enough
<DrDetroit> sorry, it was my first bug report
<DrDetroit> its the only bug i have reported
<DrDetroit> only the one report
<jjohansen> DrDetroit: no reporting all the information you can is good
<DrDetroit> the only thing i can think of to add is to fire up the other kernels and put the info into the original bug report if possible
<DrDetroit> but i guess i can wait to do that until you guys need the info
<DrDetroit> maybe you dont need it at all
<DrDetroit> hehe
<jjohansen> DrDetroit: in the future one bug report is nice, but we appreciate you going through and filing what you have, perhaps we just need to be clearer in or instructions
<DrDetroit> i could have been usiing one of the failing kernels but it is so slow 
<sconklin> jjohansen: he hadn't already submitted them, he only asked if he should
<DrDetroit> sorry
<jjohansen> DrDetroit: generally that is what we do, we will ask you in the report to say run apport-collect <bug#>
<jjohansen> sconklin: even better, I missed that
<jjohansen> DrDetroit: asking is good :)
<jjohansen> DrDetroit: so basically if we want more info on a bug we will ask for it and tell you what you need to do to attach it
<sconklin> jjohansen: I'm almost outta here. if you start a bisection then put the git tree somewhere public so we can continue.
<sconklin> jjohansen: There are only about 55 commits between 28 and 29
<jjohansen> sconklin: how public? zinc, tangerine?
<DrDetroit> ok i will await any further instructions
<DrDetroit> thank you both for helping me
<sconklin> jjohansen: either. I usually just put things like that in a branch of my personal repo on zinc
<jjohansen> DrDetroit: I am going to start a bisect we will have a kernel for you to test in say an hour
<DrDetroit> ok i will try and be around
<jjohansen> sconklin: okay, will do I'll not it in the bug
<DrDetroit> i have evening chores to do
<sconklin> jjohansen: Ubuntu-2.6.32-28.56..Ubuntu-2.6.32-29.57
<sconklin> Those are probably the tags you want
<jjohansen> sconklin: thanks
<DrDetroit> hehe it's so much fun to use a computer when it's working properly
<jjohansen> DrDetroit: don't worry we will break it soon :)
<DrDetroit> haha
<DrDetroit> you will have to give me pretty good instructions since i have never done something like this before
<DrDetroit> and I would hope to not loose my working kernel
<jjohansen> DrDetroit: don't worry you won't loose your working kernel
<DrDetroit> its not a big deal
<DrDetroit> this is just my personal fun machine
#ubuntu-kernel 2011-03-23
<DrDetroit> well there is something i didnt notice before
<DrDetroit> in the 28 kernel, even if my load goes above 100 its still peppy and responsive, not sluggish at all
<DrDetroit> my load average is now 1.63
<DrDetroit> still pretty peppy
<DrDetroit> so i dont know if this will help, but
<DrDetroit> when running the 29 or 30 kernels it would bog down and the load would rocket with just 2 terminal windows open
<DrDetroit> in the 28 kernel, it took me openingup 10 apps to get the load to 1.60 and even then it was peppy
<DrDetroit> you could tell it was under some load but performed decently 
<psusi> when building my own kernels for testing, they are quite large.  what do you have to do to have the debug symbols stripped to cut the size down to a reasonable level?
<jjohansen1> psusi: they are stripped if you go through the regular ubuntu build processes
<jjohansen1> DrDetroit: kernel.ubuntu.com/~jj/linux-image-2.6.32-29-generic_2.6.32-29.57~lp740549_i386.deb
<jjohansen1> download that
<jjohansen1> and install it with dpkg -i linux-image-2.6.32-29-generic_2.6.32-29.57~lp740549_i386.deb
<jjohansen1> then you can reboot, hold down left shift key to select it from the grub menu
<jjohansen1> and let me know how it performs
<psusi> jjohansen1, I'm just doing the old make ; make install way from my git tree
<DrDetroit> ok let me copy those instructions down 
<DrDetroit> ok got it downloaded
<DrDetroit> will try installing it now
<DrDetroit> ok it says it installed
<DrDetroit> when i choose it , will i be choosing 2.6.32.29-generic?
<DrDetroit> or is it the longer name
<DrDetroit> 2.6.32-29-generic_2.6.32-29.57~lp740549_i386.deb
<DrDetroit> jjohansen1: will i be choosing 1.6.32-29-generic or 2.6.32-29-generic_2.6.32-29.57~lp740549_i386.deb
<DrDetroit> ok its all set to reboot
<DrDetroit> I guess I will just find out when i see the menu
<DrDetroit> hehe
<DrDetroit> back shortly with a report
<DrDetroit> jjohansen1: ok i am rebooted
<DrDetroit> will give this a test run
<DrDetroit> so far i have seen a 2.10 load but still works ok
<DrDetroit> my update manager says there is a kernel update of 2.6.32-29 i will ignore that one
<DrDetroit> so far so good
<DrDetroit> i will let it run for a bit on its own
<jjohansen1> yeah the versioning stuff is a bit weird
<jjohansen1> I'll assume it is good and start building the next one
<DrDetroit> i think its ok
<DrDetroit> i will activate my other screensaver 
<DrDetroit> i can usually see it slow down then
<DrDetroit> i am not sure how many of these i can do tonite
<DrDetroit> I am an old man and fall asleep easily
<DrDetroit> hehe
<DrDetroit> ok got hypertorus on a 10 min screensaver
<DrDetroit> turned it to 3min
<DrDetroit> that should give us a excellent idea
<jjohansen1> DrDetroit: np, we can stop when ever you want, though there are only 4 or 5 left
<DrDetroit> i will try and do them if i can stay awake
<jjohansen1> I'll try to make sure they coming as fast as possible
<DrDetroit> its ok
<DrDetroit> take the time you need
<DrDetroit> and I am not your only concern i bet
<DrDetroit> dont forget family and work etc
<jjohansen1> DrDetroit: no, but its fairly easy to kick off a new build, and then let it run while I do something else
<DrDetroit> I copied and pasted your instructions, it worked very well, thanks
<jjohansen1> also as we zero in most of the kernel will already be built and the incremental compiles can go fast
<DrDetroit> I am 60, but i still enjoy computers
 * DrDetroit chuckles
<jjohansen1> case in point, new kernel up same place, same instructions :)
<jjohansen1> hehe, well may dad is 70 and he enjoys them too
<jjohansen1> DrDetroit: just in case you missed ^
<DrDetroit> same name?
<jjohansen1> yep, it will install right over the old one
<DrDetroit> ok getting it now
<jjohansen1> I could bump the name if you want, but this leaves less mess for you to uninstall
<DrDetroit> i think its cool that yhour dad likes computers
<DrDetroit> downloading now
<DrDetroit> and installing
<DrDetroit> and rebooting
<DrDetroit> back shortly
<bjf> ogasawara, around?
<jjohansen1> bjf: unlikely she started pretty early today
<bjf> jjohansen1, that's what i figured but i thought i'd check anyway
<DrDetroit> jjohansen1: ok got it running
<jjohansen1> \o/
<DrDetroit> I think, if its ok with you, I will run this for awhile
<jjohansen1> sure
<DrDetroit> I know that sometimes when I rebooted the machine, it took a bit for the problem to appear
<DrDetroit> but I will remain logged in here
<jjohansen1> sounds good
<DrDetroit> maybe we could continue tomorrow?
<DrDetroit> I can be here in the morning, or whatever time you are here
<DrDetroit> even later on this evening
<jjohansen1> DrDetroit: sure what ever time you want to be around
<DrDetroit> I live in Arkansas so am on Cental time
<DrDetroit> brb
<jjohansen1> DrDetroit: heh, well I am west coast but run real weird schedules so I am around just about any time, and if I am not around I can hand off to sconklin
<DrDetroit> ok all set up
<DrDetroit> will let this run for a bit 
<DrDetroit> i want to make sure i run all the stuff i would normally run during a session
<DrDetroit> Linux bashful 2.6.32-29-generic #57 SMP Wed Mar 23 00:51:49 UTC 2011 i686 GNU/Linux
<DrDetroit> [bobp@bashful:]$ w
<DrDetroit>  21:35:00 up 2 min,  2 users,  load average: 1.60, 0.73, 0.28
<DrDetroit> perky though
<DrDetroit> jjohansen: I think this one is ok
<jjohansen> DrDetroit: okay, I'll kick the next one off, should be ready in 10 min or less
<DrDetroit> ok
<DrDetroit> i can do one more
<jjohansen> DrDetroit: same place, same instructions
<DrDetroit> ok
<DrDetroit> thanks
<DrDetroit> i hope we find it 
 * DrDetroit chuckles
<DrDetroit> what happens if we don't?
<DrDetroit> oh and i have a stupid question 
<jjohansen> well then, we retry to make sure we didn't make a mistake :)
<jjohansen> but we will find it
<DrDetroit> I notice that on the chat box title it save kernel version 2.6.38 mine is not that currnet, but i thought i had the most current for my dist
<DrDetroit> and installing the next one
<jjohansen> hrmm, I am not familiar with chat box, you could run uname -a from a shell and see what it says
<DrDetroit> i meant at the top of my chat screen it says
<DrDetroit> Natty Kernel Version 2.6.38
<DrDetroit> i was just curious since i thought the one i had was the current kernel version
<DrDetroit> ok finished installing
<DrDetroit> back after  the reboot
<DrDetroit> and back
<DrDetroit> will let this one run for a bit
<jjohansen> DrDetroit: can you run uname -a in a terminal
<DrDetroit> sure
<DrDetroit> Linux bashful 2.6.32-29-generic #57 SMP Wed Mar 23 00:51:49 UTC 2011 i686 GNU/Linux
<DrDetroit> load average: 1.60, 0.97, 0.42
<DrDetroit> currently 1.60
<jjohansen> okay that looks good
<DrDetroit> but perky
<DrDetroit> not really doggy
<DrDetroit> lets let this one run for  a bit
<DrDetroit> this one might be it
<DrDetroit> let me watch it for awhile
<DrDetroit> jjohansen i thnk this one is ok
<jjohansen> DrDetroit: okay I will kick off the next one
<DrDetroit> ok i will probbly download it but not test it till tomorrow if that is ok
<DrDetroit> i am starting to fade into the sunset
<jjohansen> DrDetroit: perfectly fine, any idea when you will be on tomorrow?
<DrDetroit> what times are you here?
<jjohansen> like I said its all over the place, I expect I won't be on much longer tonight but will be on by 5 or 6 tomorrow
<DrDetroit> i will try and catch you in the early am
<jjohansen> DrDetroit: okay, same place, same instructions when ever you can get to it
<DrDetroit> ok on my way
<DrDetroit> i will report back tomorrow morning
<DrDetroit> early
<jjohansen> sounds good
<DrDetroit> night and thank you very much
<jjohansen> good night
<MTecknology> So... Why will my display manager not work if CONFIG_PRINTK is disabled?
<MTecknology> That doesn't really make sense to me..
<kristian-aalborg> hi all
<fairuz1> hi
<fairuz> Hi, Can I force a release version for a compiled kernel?
<fairuz> hi jjohansen
<jjohansen> fairuz: hi
<fairuz> jjohansen: I already has a question for today :D
<jjohansen> hehe :)
<fairuz> Can I force a release version for a compiled kernel? Because when I compiled the kernel, the uname -r is something like 2.6.35-980-aaa123ccc. And there are some modules that are not loaded because of this ( i see the messages during the boot )
<fairuz> jjohansen: I see that they took the release from kernel.release file, but how is this file is generated and from where
<amitk> fairuz: search for the EXTRAVERSION config symbol in Kconfig
<amitk> fairuz: the ubuntu kernel build scripts overwrite it
<jjohansen> fairuz: the release version is generated, the place you can easily tweak is debian/changelog
<fairuz> amitk: Ah, I thought it's EXTRAVERSION in the Makefile
<jjohansen> at the top of debian/changelog you get something like
<jjohansen> linux (2.6.36-1.7) natty; urgency=low
<jjohansen> you can manipulate the release pocket (natty)
<jjohansen> and the numbers when I do custom builds I usually add ~jj or ~lp#####
<jjohansen> the will just show up in the package numbering eg. (2.6.36-1.7~jj)
<jjohansen> if you use a - it will break the scripts
<fairuz> jjohansen: ok
<jjohansen> now if you start changing the 1.7 you may need to pass extra parameters to your kernel build
<jjohansen> like skipabi=true skipmodules=true
<jjohansen> which do checks against the abi (numbers you just changed)
<jjohansen> you can of course update the contents of debian.master/abi instead
<jjohansen> of and one more thing, debian/changelog is copied from debian.master/changelog when you do fakeroot debian/rules clean
<jjohansen> so you can make the change in debian.master/changelog if you want it to stick around
<fairuz> jjohansen: emm I never use fakeroot command :-/. Until now I just do the classic make
<jjohansen> fairuz: ah, so let me change the instructions a bit :)
<fairuz> jjohansen: :D
<jjohansen> fakeroot debian/rules  (I alias this to fdr) is the traditional way of building an ubuntu kernel package
<jjohansen> fdr clean sets up for the environment
<jjohansen> fdr prepare-<type>
<jjohansen> setups the build (called by binary- if it hasn't been done)
<jjohansen> fdr binary-<type> builds the kernel, and package it up into a linux-image.XXXX.deb
<fairuz> jjohansen: ah ok
<jjohansen> of course you don't need to do this if you are just building a kernel
<jjohansen> fairuz: I can point you at a wiki page if you are interested
<fairuz> jjohansen: sure
<fairuz> jjohansen: it will be good to discover that
<jjohansen> fairuz: first up generic jump off page ubuntu kernel team uses https://wiki.ubuntu.com/Kernel/Dev
<jjohansen> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<jjohansen> is the specific page
<jjohansen> lots of useful information in those pages
<jjohansen> anyways, ubuntu uses the CONFIG_VERSION_SIGNATURE entry in the .config
<jjohansen> eg.
<jjohansen> CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.36-1.7-virtual 2.6.36
<jjohansen> this gets cons together by the build scripts from the debian/changelog and some vars
<fairuz> jjohansen: ok
<jjohansen> if you are just doing make you can set that and just build
 * jjohansen likes straightup make for incremental development, as there is no package to build/reinstall
<jjohansen> its quick to just make ; make install
<fairuz> jjohansen: ok. On my compiled kernel. uname -r gives me something like serial number. Does it came from debian/changelog too?
<fairuz> jjohansen: v2.6.38-366-g65e01eb to be exact
<fairuz> jjohansen: sorry mistake.. this one 2.6.38-00366-g65e01eb
<jjohansen> fairuz: well that one is strange to me, your build arm aren't you
<fairuz> jjohansen:  yes
<jjohansen> okay, I actually haven't done an arm lately so I am not sure I will have to dig a little bit
<fairuz> jjohansen: I just clone the git tree, then prepare the .config, then just do make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage
 * jjohansen needs to learn anyways as I got my affika mx today and it needs a new kernel :)
<fairuz> jjohansen: cool :D
<fairuz> jjohansen: and since the kernel release is like that, when it boots, there are errors like /lib/modules/2.6.38-00366-g65e01eb/xxx/xxx/xxx cannot be found etc
<jjohansen> did you do a make modules_install?
<aakshay> what is the concept of designing the multiprocessor for executing a single program?.. please help..:)
<jjohansen> update the initramfs -uk 2.6.38-00366-g65e01eb
<jjohansen> aakshay: not sure I understand the question?
<fairuz> jjohansen: no. Never heard of module_install before
<jjohansen> fairuz: make that modules_install
<jjohansen> s on the modules
<jjohansen> after doing a make install, I always do a make modules_install
<fairuz> jjohansen: Before or after the actual compilation?
<jjohansen> it will copy all the modules into /lib/modules/XXXX
<jjohansen> after
<fairuz> ok
<jjohansen> make ; make install ; make modules_install
<jjohansen> sudo update-initramfs -ck or -uk
<jjohansen> then update-grub on x86
<fairuz> jjohansen: If I cross compile, is it the same?
<fairuz> jjohansen: or I have to compile on the arm board ( which I think will take forever ) 
<jjohansen> fairuz: I assume so, as long as all the targets are set right
<jjohansen> fairuz: the make builds the modules, make modules_install just copies
<fairuz> jjohansen: wait there is something I dont quite understand. You said that it will copy to /lib/modules/xxxx
<jjohansen> well install to, yes
<fairuz> jjohansen: but that is my filesystem on the board ?
<jjohansen> right
<jjohansen> you need to get the modules in location some how
<jjohansen> how do you install the kernel to /boot?
<fairuz> i just scp it to the board
<fairuz> since both machines are on network
<fairuz> jjohansen: not the right way to do it i suppose?
<aakshay> jjohansen: thanks for considertaion.. i would like to design the multirocessor system to chek the memory acces(using array as memory).. so can u please guide me how to code?
<jjohansen> ah then you are going to have to do something similar for the modules
<fairuz> jjohansen: ah ok
<jjohansen> fairuz: no it works, make install is just a convenience that copies to the standard location and has a little bit of extra magic baked in
<fairuz> jjohansen: then i just copy from this standard location to my board's filesystem?
<jjohansen> as long as you build with your compile target separate from the source directory you should be able to just scp your built modules
<jjohansen> yeah
<jjohansen> fairuz: look in the Makefile for modules_install
<jjohansen> its a pretty simple target
<fairuz> jjohansen: i saw it yes
<jjohansen> aakshay: hrmm, I'm not sure I under stand what you trying to do still.  Are you trying to emulate a multiprocessor system running multiple threads accessing memory at the same time?
<jjohansen> aakshay: our right a multi-threaded program that is running in parallel on a multi-processor system?  And what do you mean by check memory access
<aakshay> jjohansen: yes I want to emulate a multiprocessor system running multiple threads accessing memory at same time.
<aakshay> jjohansen: so please tell how to implement it?
<fairuz> jjohansen: let me resume what I have to do as it's not yet very clear. http://pastebin.com/ncccv0vb
<jjohansen> aakshay: well that sounds like an assignment :)  The basics are to emulate an instruction per processor, and each processor will do a memory lookup on the array, your code will have to deal with the processor specifics about the emulated memory cycle if you want to be accurate with how smp system deal with memory accesses, collisions, etc
<jjohansen> aakshay: I really don't have enough info even to say much beyond that, and being what looks like a home work assignment I am hesitant to say to much beyond general hints
<jjohansen> fairuz: no
<kristian-aalborg> kamal: which was the command you suggested after fdr binary-generic?
<jjohansen> kristian-aalborg: binary-headers ?
<jjohansen> fairuz: you would only run make modules_install if the build was on the machine you are installing on
<kristian-aalborg> ah, found it... binary-headers
<fairuz> jjohansen: ok that make sense 
<jjohansen> fairuz: so make config ; make ; cp uImage to boot partition ; cp modules to boards file system
<jjohansen> @cp -f $(objtree)/modules.order $(MODLIB)
<jjohansen> @cp -f $(objtree)/modules.builtin $(MODLIB)
<kristian-aalborg> this time, I turned on skipmodule=true before doing anything, and it finished in the first try
<jjohansen> that is from the modules_install target, it copying from the build tree to the target fs
<jjohansen> kristian-aalborg: \o/
<kristian-aalborg> I hope it will make a difference...
<fairuz> jjohansen: ok
<jjohansen> fairuz: modules_install also can do firmware stuff but we will deal with that later if needed
<aakshay> jjohansen: yes. its an assignment.. :P... i am trying to code this but not finding the right sources to start with? :(
<kristian-aalborg> the proper way to remove kernels installed with dpkg -i is dpkg -r, correct?
<jjohansen> aakshay: think of each cpu as a thread, running simultaneously.  You can emulate this by stepping each cpus instruction pointer one instruction at the same time.  Running the instruction, and potentially not commiting results of the instruction.  That will all depend on the architecture characteristics you are trying to emulate.  I don't even have enough info to tell you more
<jjohansen> kristian-aalborg: that or --purge
<aakshay> jjohansen: thanks for the help. :)..  one more thing what is the use of "%*s" in " fscanf(fd, "%*s%d", &num_of_regions);" ?
<jjohansen> aakshay: %* surpresses the match string s matches a non-whitespace string of chars
<jjohansen> %d matches numbers, and stores it in &num_of_regions
<jjohansen> aakshay: do man fscanf (or google it)
<aakshay> jjohansen: googling it.. :)
<kristian-aalborg> it *still* just reboots :(
<kristian-aalborg> is there a kind sould who'd try building my .config?
<kristian-aalborg> or have a look at it... it should be fairly basic
<jjohansen> kristian-aalborg: I can look at your config, but if its building for you I doubt that building it else where will reveal much except a successful build
<jjohansen> kristian-aalborg: so you aren't even dropping to an initramfs just going straight to reboot
<kristian-aalborg> yes
<kristian-aalborg> the screen just goes black, then the machine reboots
<jjohansen> kristian-aalborg: can you remind me what type of machine
<kristian-aalborg> a ThinkPad 770, of course :)
<jjohansen> kristian-aalborg: grub, grub2?
<kristian-aalborg> grub2
<kristian-aalborg> and lucid
<jjohansen> kristian-aalborg: if you hold down the left shift key after the bios screen does the grub boot menu come up
<kristian-aalborg> http://pastebin.com/dGuzdH9N
<kristian-aalborg> I have 10 seconds of grub by default
<jjohansen> kristian-aalborg: okay, so we at least know its getting to grub
<kristian-aalborg> yes, but when I choose the kernel the described mishap takes place
<jjohansen> kristian-aalborg: is your cpu a pentium-mmx?
<kristian-aalborg> yes
<jjohansen> kristian-aalborg: do you have a working .config to diff against?
<kristian-aalborg> not apart from the one from git
<kristian-aalborg> http://www.thinkwiki.org/wiki/Category:770 <--- the box in question
 * smb has not read the full scrollback but wonders whether pae might be involved. Or our processor settings...
<jjohansen> kristian-aalborg: so you don't have kernel that boots on the machine or you don't have the config for the kernel?
<kristian-aalborg> ah, sorry, I mistunderstood what you meant
<jjohansen> smb: yeah that is what I am trying to figure
<kristian-aalborg> * misunderstood
<kristian-aalborg> yes, I have the generic kernel on it, from a regular update - it boots fine
<jjohansen> kristian-aalborg: okay, so the -generic i386 works, got it
<kristian-aalborg> what I did was make oldconfig then a few tweaks with make menuconfig - then cp to the machine that I build on
<jjohansen> kristian-aalborg: do you update the initramfs?
<smb> jjohansen, Hm wait. make oldconfig? on what?
<jjohansen> smb: good question
<kristian-aalborg> make oldconfig on the 770 then move it to a newer machine
<smb> What I am wondering is that if you use the debian/rules process, it will create a new config under debian/build/... 
<kristian-aalborg> smb: I copied .config after that, per jjohansen's instructions
<smb> Ah ok. Did miss those instuction parts
<kristian-aalborg> this was a few days ago
<jjohansen> smb: it was a few days ago
<smb> heh ok
<kristian-aalborg> Rome wasn't built in a day :)
<smb> Note, that if you want to tweak a config, you may also run "fakeroot debian/rules editconfigs" It might be that older releases do not have the y/n questions for each flavour but one can ctrl-c after the config that was of interest
<jjohansen> kristian-aalborg: these configs are significantly different
<kristian-aalborg> which configs?
<jjohansen> yours and the -generic kernel
<kristian-aalborg> hurm..
<kristian-aalborg> anything "risky"?
 * kristian-aalborg has to go to work shortly
<jjohansen> kristian-aalborg: different enough all bets are off
<kristian-aalborg> hmmm
<jjohansen> kristian-aalborg: can you redo your config changes using fakeroot debian/rules editconfigs
<jjohansen> that will call make menuconfig, and then save off your changes
<kristian-aalborg> I'll give it a shot, but it will be later
<kristian-aalborg> however, changing .config is what it's all about...?
<jjohansen> kristian-aalborg: sorry, something didn't take right when building your config
<jjohansen> kristian-aalborg: right, but you want to work from a know working config and then tweak it to what you want, its much easier that way
<kristian-aalborg> I *think* I apt-got the source on the 770 - the machine I build on got it by git
<kristian-aalborg> make oldconfig it not sure-fire to work?
<jjohansen> kristian-aalborg: shouldn't matter
<jjohansen> kristian-aalborg: no it isn't
<jjohansen> especially in this case
<kristian-aalborg> ah, that might be it
<kristian-aalborg> it's also fairly new, I think
<kristian-aalborg> so - next step: build a generic kernel, move and test - then tweak
<kristian-aalborg> perhaps compare to the config from makeconfig
<jjohansen> kristian-aalborg: you don't need to build the generic kernel
<kristian-aalborg> jjohansen: did you try building it?
<jjohansen> kristian-aalborg: no
<kristian-aalborg> k
<jjohansen> kristian-aalborg: fakeroot debian/rules clean
<jjohansen> kristian-aalborg: fakeroot debian/rules editconfigs
<kristian-aalborg> jjohansen: I have some slavery to do :(
<jjohansen> this will edit your build configs
<kristian-aalborg> see you guys later - I feel like there's some kind of progress
<jjohansen> then fakeroot debian/rule binary-generic
<jjohansen> or what ever build target you were using
<kristian-aalborg> work > geekery, unfortunately
<jjohansen> yeah
<kristian-aalborg> see ya
 * smb thinks jjohansen also has something important to do :)
<jjohansen> smb: really what could that be ;)
<smb> jjohansen, Weeell, there are many sheep to be counted. :-P
<jjohansen> smb: oh shoot, yet another thing that needs to be done.  Let me guess this is a rather high priority task :)
<jjohansen> smb: how often do you build on zinc?
<smb> jjohansen, that goes near nill
<smb> jjohansen, The mainline builds used to be done there though
<jjohansen> smb: okay, thats what I thought. /me was trying to figure out how to make a bisect public without doing the builds there, /me just ended up using tangerine and making the debs public
<smb> jjohansen, Yep, much quicker that way
<fairuz> jjohansen: sorry to ask again but what the files that should I transfer to /lib/modules of the arm board after I cross compile the kernel?
<jjohansen> fairuz: the actual list varies based on the build, modules_install does
<jjohansen>         @cp -f $(objtree)/modules.order $(MODLIB)/
<jjohansen>         @cp -f $(objtree)/modules.builtin $(MODLIB)/
<jjohansen>   and then some magic to get the list of .kos to copy
<jjohansen> fairuz: have you ever used sshfs
<fairuz> jjohansen: nope -(
<jjohansen> fairuz: it allows you to mount a remote machine over ssh, so you can do things like make install and make modules_install to the remote machine
<fairuz> jjohansen: right now the kernel boots but when i tried to insmod an external module, it gives me invalid module format error. So it must be because of /lib/modules files right?
<jjohansen> sadly its been a while since I used it so I don't remember the details
<jjohansen> fairuz: likely, we are getting to the level I would have to fiddle with things to see what is happening
<jjohansen> manually installing modules isn't something I have had to do for a long time
<jjohansen> fairuz: I would google sshfs and take a look at using that
<jjohansen> its probably been 6 months since I've used it for kernel installs but it worked well for me
<fairuz> jjohansen: ok. it's different from normal ssh?
<jjohansen> fairuz: its fuse module that leverages normal ssh
<jjohansen> it makes the remote machine show up as a mount on the local machine, so you can treat it like a local disk
<jjohansen> then you can set your make install target and install to your remote machine
<fairuz> jjohansen: ok
<jjohansen> sorry I am not more specific, right now I just have to resort to google to find out how to use it again, but I remember it working well for me
<jjohansen> IIRC I did it from the target machine to the build machine, so the build machine mounted as a directory on the target,
<jjohansen> I cd into the build machine directory on the target machine
<jjohansen> and ran make, make modules_install, so the remotely built kernel installed to the local (target machine)
<jjohansen> that way I didn't even need to specify make variables to set where the target should be installed
<fairuz> jjohansen: ah ok
<fairuz> jjohansen: i just did the opposite
<fairuz> :D
<jjohansen> :)
<fairuz> jjohansen: but if I do make like that, it will use which compiler? target machine or build machine?
<jjohansen> fairuz: do your make on the build machine like normal, after you have built, mount the build machine from the target, and then do make install, make modules_install
<fairuz> jjohansen: aha, i got the idea
<jjohansen> it will use the targets make but everything is already built, so its just running the scripts, copying files etc
<fairuz> jjohansen: i'll try that after lunch :D thanks a lot for the help
<jjohansen> fairuz: np, hope it works for you
<DrDetroit> and rebooting to test out last nights download
<DrDetroit> ok will let this one run for a bit
<jjohansen> DrDetroit: sounds good, let me know when your ready for the next one
<DrDetroit> will do, just woke up, so have to think about coffee (maybe w/irish cream) and feeding the felions
<DrDetroit> hehe
<DrDetroit> jjohansen: I think this one is ok
<jjohansen> DrDetroit: alright, I'll get the next one building
<DrDetroit> btw if you need someone to do this kind of thing for other reasons, I don't mind being a guinie pig
<jjohansen> DrDetroit: hehe, we like guinie pigs :)
<DrDetroit> hehe i used to be a beta tester for lucent technologies
<DrDetroit> we tested their max3000 and the maxTNT
<DrDetroit> when I owned and ran the rural isp here
<jjohansen> DrDetroit: same place kernel.ubuntu.com/~jj/linux-image-2.6.32-29-generic_2.6.32-29.57~lp740549_i386.deb
<jjohansen> same install
<DrDetroit> ok
<DrDetroit> 1:01,  2 users,  load average: 2.17, 1.39, 1.09
<DrDetroit> even with that, its not mushy or slow to respond
<DrDetroit> maybe just a tad, but thats because i was dl'ing
<jjohansen> well lets give it a few minutes
<DrDetroit> nod
<DrDetroit> i am just installing the new one now
<DrDetroit> that was with the old one
<DrDetroit> while i was downloading
<jjohansen> ah, okay
<DrDetroit> back in a min, rebooting 
<DrDetroit> and back
<DrDetroit> will let this one run for a bit
<hggdh> Q: on Hardy, the package linux-image for Xen should update /boot/grub/menu.lst, correct?
<fairuz> jjohansen: Before doing install_modules, should i backup the /lib/modules folder? because I dont want to ruin a working setup
<jjohansen> fairuz: you don't need to if the kernel being installed has a different version, it will create its own directory, so you can multiple kernels installed
<fairuz> jjohansen: yes but in my case they have the same name 
<fairuz> jjohansen: i can just rename the old one right?
<jjohansen> fairuz: hrmm, that is problematic, you can rename the old one but you might not be able to boot then
<jjohansen> that is boot into the old one
<fairuz> jjohansen: so i should recompile with different name?
<jjohansen> fairuz: that would be best, you can do an incremental compile
<jjohansen> remove the debian/stamps/stamps-build-XXXX file
<fairuz> jjohansen: what's that file for?
<jjohansen> change the name and then do fakeroot debian/rule binary-XXXX
<jjohansen> the build scripts use it for time stamps of which stages completed
<jjohansen> remove the build stamp and it will rebuild the kernel
<jjohansen> but if you still have all the .o around from a previous build, make will only compile the parts that have changed
<fairuz> fakeroot debian/rule binary-uImage is the same as make uImage?
<jjohansen> it makes for a fast kernel compule
<jjohansen> fairuz: doh I keep forgetting you are using arm
<jjohansen> fairuz: no, you don't need to remove the stamp file, you shouldn't have it for the way you are building
<fairuz> jjohansen: i have a debian and also debian.ti-omap4 folder in my source folder
<jjohansen> just change the name and use make uImage
<fairuz> jjohansen: ok. sounds easier :D
<jjohansen> fairuz: right but aren't using them to do the build are you?
<jjohansen> fairuz: you aren't making a .deb that you then install with dpkg
<fairuz> jjohansen: nope
<jjohansen> so just use make
<fairuz> jjohansen: I just need the kernel image
<fairuz> jjohansen: ok
<fairuz> jjohansen: Should I do this module_install systematically each time I compile the kernel or just in certain case?
<jjohansen> fairuz: depends, if you make a change that could affect the modules yes, update an include etc.  other wise as long as the abi doesn't change there should be no need
<fairuz> jjohansen: ok. btw, received your arm box yet?
<jjohansen> fairuz: yep it came yesterday, updated it to natty but I haven't had time to really do anything with it yet
<DrDetroit> jjohansen: I am going to run to town soon to do some errands, I will let the current kernel run for the time I am gone, if that is ok with you
<DrDetroit> if it does not mess up, then we can move on when i get back
<jjohansen> DrDetroit: sounds good
<DrDetroit> thanks
<jj-afk> back on in a couple hours
 * DrDetroit nods
<hggdh> kernel team -- I need to know if the hardy xen package should update /boot/grub/menu.lst; if it should, the -proposed does not do it
<smb> hggdh, Now I see it...
<fairuz> When I do make modules_install, it gives permission error, same with sudo make modules_install. Should I install it to another writable folder first then move them to /lob/modules?
<fairuz> *lib
<ogasawara> tgardner: so which build box are you doing armel test builds for natty since tangerine doesn't have the natty-armel chroot?
<tgardner> ogasawara, you can use urbana which is running Natty, and has a functional armel schroot for natty. Otherwise, I'm just cross compiling.
<ogra_> do i smell an omap4 upload for today ? :)
<tgardner> ogra_, shortly
<ogra_> awesome !!
<tgardner> ogasawara, you can also upload to the c-k-t PPA, but the builds take awhile.
<tgardner> ogra: I'm still not able to get a functional armel qemu schroot on a Lucid host. It does work on a Natty host. Any thoughts ?
<ogra_> do you use a backported version of qemu-linaro on lucid ?
<tgardner> ogra_, as far as I know. I've got -backports enabled
<ogra_> i dont think its in backports, the linaro gusy have their packages in a ppq
<ogra_> *ppa
<ogra_> but there should be a lucid version, i'd try if that works better
<tgardner> ogra: I've haven't looked in a couple of weeks, so I'll try again. 
<DrDetroit> and back
 * ogasawara back in 20min
<JFo> sconklin, I'm loving the pictures :)
<smb> JFo, You got pictures of sconklin? :-P
<JFo> smb, I've seen some
<JFo> ooold ones :)
<sconklin> JFo, there are more you'll never see ;-)
<JFo> :-(
 * JFo is sad now
<smb> Ohh, the kind of that mothers usually take out at the most inappropriate times? :D
<JFo> smb, hah! not quite that old :p
<sconklin> I've been starting to scan the film that I shot in the 70's and 80s
<sconklin> JFo: I've probably still only even glanced at about 5% of my files
<JFo> I can only imagine
<JFo> I agree with the sentiment that you should start back taking more, though.
<JFo> great stuff
<sconklin> it's kinda sad. Some of the happy young folks in those photos are now broken down addicts. Or not around
<JFo> the unfortunate story of life
<sconklin> When I get more I'll put them in sets on flickr or picasa or something. Until then, Facebook is a fun way to get reactions to them
<sconklin> I found another box of various band photos last night, need to go through those
<JFo> strolling down amnesia lane as a friend would say. :-)
<sconklin> I find a lot of things I forgot about, and can't find the ones I am specifically looking for. That's the way, isn't it . . .
<JFo> unfortunately :-/
<DrDetroit> ok i guess i can go out and mow the lawn or something while I wait for jjohansen to return
<DrD_away> pretty sad to be mowin in March
 * DrD_away shakes his head
<fairuz> Hi, when the modules.dep are generated? because when I do modules_install, it's not there.
<fairuz> Hi, can we generate a header folder from a source?
<fairuz> (kernel source)
<kristian-aalborg> hi again
<DrD_away> jjohansen: I am ready again when you are
<jjohansen> DrDetroit: how did the last kernel work out
<DrDetroit> it seems to be ok
<DrDetroit> i am using it now
<DrDetroit> jjohansen: it seems to be ok
<DrDetroit> i am using it now
<jjohansen> DrDetroit: hehe, yeah sorry, next kernel is ready :) same place
<DrDetroit> no probelm
<DrDetroit> no hurry
<DrDetroit> I am glad your back cause my lawnmower started right up, so if you were not here, I would have to mow
<DrDetroit> hehe
<jjohansen> DrDetroit: well we can't have that
<tgardner> ogasawara, did you see that there has been another gcc upload? You should ask doko if there is any code generation impact wrt the kernel.
<ogasawara> tgardner: argh, that'll screw us for beta freeze if we have to perform another kernel upload
<tgardner> ogasawara, well, the gcc upload has an enormous changelog. I can't tell what impact it might have.
<GrueMaster> ppisati: ping.  You will need to retest bug 732700 as I haven't come across this issue before.  Other than that, the 216/416 kernel looks good to me for dove.
<ubot2> Launchpad bug 732700 in linux-mvl-dove "apparmor_parser triggers a kernel panic" [Undecided,Fix committed] https://launchpad.net/bugs/732700
<kristian-aalborg> http://ubuntuforums.org/forumdisplay.php?f=332 <--- I changed the scope of my little project :)
<ppisati> GrueMaster: pong
<ppisati> GrueMaster: actually that problem triggered using, for example, a maverick kernel on a lucid userbase
<ppisati> GrueMaster: but yeah, i can confirm it has been fixed
<ppisati> mpoirier: ping
<mpoirier> ppisati: pong
<ppisati> mpoirier: do you have any OMAP3 board?
<mpoirier> ppisati: not that belongs to the company no.
<ppisati> mpoirier: uhm k
<ppisati> mpoirier: because i'm looking for a OMAP3 board
<ppisati> mpoirier: to cleanup lucid/ti-omap
<bjf> ppisati, i had several beagle board flavours, i think they got shipped to either eric or brian
<GrueMaster> ppisati: What on lucid needs cleaning up?  It wasn't a fully supported release iirc.
<ppisati> bjf: i'll ask them, thanks
<ppisati> GrueMaster: it seems my duty here is to cleanup all the arm-related bits, so... :)
<tgardner> ppisati, its likely easier to just buy one rather then have it shipped from Asia
<kristian-aalborg> jjohansen: ping
<jjohansen> kristian-aalborg: pong
<GrueMaster> ppisati: Do you have specific bugs you are looking at?
<kristian-aalborg> see how I just went open source ;)
<ppisati> GrueMaster: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap
<ppisati> GrueMaster: as many as i can
<ppisati> GrueMaster: i'm ping-pong-ing with saeed about mvl-dove, i'm one step closer to get audio working
<ppisati> GrueMaster: let's see...
<GrueMaster> cool.
<ppisati> GrueMaster: in the mean time, i'm trying to be productive on another front
<jjohansen> kristian-aalborg: which thread?
<ppisati> GrueMaster: but my XM doesn't collaborate...
<ppisati> GrueMaster: from time to time, it spontaneously reboot
<ppisati> GrueMaster: eth doesn't work anymore
<GrueMaster> As to the lucid omap issues, I can see if they are reproducable.  You need a Beagleboard C4 for those.
<ppisati> GrueMaster: etcetc
<ppisati> btw, ti-omap4 in maverick, there're some CVEs open
<ppisati> but it says "no rebase on master"
<ppisati> so, do i cherry-pick the fix from master an apply locally?
<tgardner> ppisati, yep
<GrueMaster> I don't think they were pulled into a kernel update for omap4.
<ppisati> tgardner: goocd
<jjohansen> kristian-aalborg: never mind found it
<GrueMaster> ppisati: Since I am the QA guy for the canonical-arm team, if you need something verified before you attempt to dive in, just let me know.  I have all of the supported platforms online and all of the images for testing.
<ppisati> GrueMaster: ok
<GrueMaster> We can work together to clean up the cruft.
<ppisati> GrueMaster: perfect
<ppisati> GrueMaster: but let me first find a beagle C4
<ogasawara> <slangasek> ogasawara: I thought the issue was the kernel had a naive check for compiler version number that prevented out-of-tree modules from rebuilding after *every* gcc rev, whether or not there are code changes?
<ogasawara> tgardner: ^^, is that correct?
 * ogasawara is not familiar enough to know
<tgardner> ogasawara, I think thats right. Lemme figure it out. apw could tell me off the top of his head.
<ppisati> bjf: you mean, ericm and bdmurray, right?
<kristian-aalborg> hurm, looking at /boot/config - I thought the distro kernel was just downloaded and installed, not individual?
<bjf> ppisati, i meant ericm and cooloney
<ppisati> bjf: k
<tgardner> ogasawara, gcc versioning changed from 4.5.2-6ubuntu5 to 4.5.2-7ubuntu1, so I think we're OK
<tgardner> ogasawara, on the other hand, why did you have to do a no-change rebuild last Friday? Only the minor version changed.
<ogasawara> tgardner: my understanding from what slangasek said is that any gcc revision forces us to re-upload.
<ogasawara> tgardner: he noted "the whole problem we have with needing kernel rebuilds after gcc updates is that having the kernel check for the things that actually matter at build-time was too hard so there's a compiler version 'fingerprint' check instead"
<kristian-aalborg> if the latter is correct, I need to move my /boot/config from the old machine before editing it?
<tgardner> ogasawara, and the fingerprint includes then _whole_ version?
<ogasawara> tgardner: that's what I'm guessing.
<ogasawara> tgardner: I'm adding this as a discussion point at UDS
<tgardner> ogasawara, well then, that seems to indicate yet another upload.
<ogasawara> tgardner: indeed.  I've already given skaet a heads up we'll be violating the beta freeze
<cody-somerville> I'm trying to figure out why when you detach a loop device sometimes it'll error out reporting device or resource busy. I have a script that can reproduce it about 60-70% of the time. Adding a command that doesn't write to the loop device makes it much less likely to happen. I thought the issue might be that the kernel still has things to write buffered and that a sync would fix the issue. However, after running the script 11
<cody-somerville> 86 times it failed.
<tgardner> ogasawara, we don't have any external modules right now in Natty that we care about. Everything else should be DKMS.
<tgardner> I wonder if the DKMS rebuild check looks at the finger porint, or just the kernel ABI. likely the latter.
<tgardner> cody-somerville, do you have to reboot in order to fix it ?
<cody-somerville> tgardner, no. I can losetup -d immediately.
<tgardner> cody-somerville, well, thats not a lock imbalance then.
<cody-somerville> tgardner, It appears there is some sort of race condition or something after writing to a loop device.
<tgardner> cody-somerville, have you talked to Surbhi? She's done some work on mountall races recently.
<cody-somerville> I have not.
<tgardner> cody-somerville, given that losetup -d cleans up the issue, it sound a bit like an app space race.
<cody-somerville> tgardner, I was thinking the issue was maybe lo_refcnt being > 1 when loop_clr_fd is called.
<cody-somerville> tgardner, ie. kernel is trying to write out buffer but due to thread/lock contention its slightly delayed.
<tgardner> cody-somerville, can you tell who still has  file open on the loop device by using fuser?
<tgardner> has a file*
<cody-somerville> tgardner, I haven't been able to get fuser to show anything. I've tried running fuser before losetup -d, right after losetup -d when it fails, etc. and it never shows anything.
<cody-somerville> tgardner, I'm pretty sure it isn't a user space process accessing the loop device.
<tgardner> cody-somerville, how about repeating 'losetup -d' until it succeeds? (seems like it should block until the underlying device is done)
<cody-somerville> tgardner, I was thinking of patching losetup to do that, yea. If I can't fix the underlying problem, I'll have to keep retrying losetup -d as you suggest.
<tgardner> cody-somerville, how emailing your script and I'll see if I can repro ?
<cody-somerville> tgardner, Is pastebin okay?
<tgardner> sure
<cody-somerville> tgardner, http://pastebin.ubuntu.com/584410/
<cody-somerville> tgardner, comment out all the sync commands if you want to reproduce easily.
<tgardner> cody-somerville, ok, gimme awhile.
<cody-somerville> tgardner, FYI, I wrote the script initially to test a bug in parted (hence all the calls to fdisk -l), <g>
<cody-somerville> You'll need to run the script as root naturally.
<DrDetroit> jjohansen: looks like this one is ok also
<jjohansen> DrDetroit: okay 1 more kernel
<DrDetroit> pooh, what happens if it doesn't fail?
<DrDetroit> maybe we have inadvertenly fixed my problem
<DrDetroit> i guess i can always run the 30 for awhile to see if what ails me is gone
<jjohansen> hrmm, well looking at the commit, it can't be the problem
<DrDetroit> i am not smart enough to know
<jjohansen> DrDetroit: can you retry the known bad kernel and see if you can replicate the problem
<DrDetroit> that is what i meant by running the 30 kernel
<DrDetroit> that is where i first noticed the issue
<jjohansen> right
<DrDetroit> well i am ready to try the last one on this run i guess
<DrDetroit> jjohansen: i am ready for the last kernel when you are
<DrDetroit> jjohansen: if that passes then i will run the 30 kernel for awhile
<jjohansen> DrDetroit: it will pass, its a book keeping commit only changing changelogs, etc
<DrDetroit> jjohansen: then i will reboot to the next kerne;
<DrDetroit> thank you for all your help, i will continue to be logged in here as i run the other kernel
<jjohansen> I am rechecking the bisect range, maybe I got the wrong tag
<kristian-aalborg> DrDetroit: I'm surprised anyone remembers that forgettable movie ;)
<DrDetroit> hehe
<DrDetroit> it has been my "game" name for many years now
<DrDetroit> I started using it as a MUD charater name back in 98
<kristian-aalborg> the funny thing is, Ackroyd would end up being in much more embrassing things later
<DrDetroit> hehe
<DrDetroit> when your selling yourself, apparently the only issue is price
 * DrDetroit chuckles
<kristian-aalborg> Dragnet is cool, though
<DrDetroit> brb, rebooting
<DrDetroit> jjohansen: I am rebooted and will let this one run while I do lunch and afternoon chores
<DrDetroit> I will watch it to see if the problem reappears
<jjohansen> DrDetroit: sounds good
<DrDetroit> thank you for helping me
<cody-somerville> How can I trace a kernel thread?
<kristian-aalborg> aha!
<kristian-aalborg> the vanilla build of the kernel killed my 770 also, thanks to whoever suggested trying it
<kristian-aalborg> I cp'd the working config over, now I need to tweak and build
 * bjf -> lunch
 * kristian-aalborg builds; eats yogurt...
 * jjohansen -> lunch
<kristian-aalborg> anybody got a nice script for building? fdr this, fdr that...
<kristian-aalborg> jfk this, gwb that...
<bjf> kristian-aalborg, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<kristian-aalborg> I think I'll make a script of that
<kristian-aalborg> jjohansen: good news, building from the copied config seems not to halt
<jjohansen> kristian-aalborg: good to hear
<kristian-aalborg> yup... if everything goes well, I'll be using that as my base
<kristian-aalborg> tiny script: http://pastebin.com/sUVB3baF ... comments welcome
<DrD_away> jjohansen: I have left it run for 3.5 hrs while outside and the performance has degraded
<DrDetroit> up  3:49,  2 users,  load average: 1.36, 1.44, 1.39
<jjohansen> DrDetroit: okay, I think we are going to bisect a slightly different range this time
<DrDetroit> can i wait a bit
<DrDetroit> jjohansen: I have to do evening chores
<DrDetroit> jjohansen: this was the 30 kernel 
<jjohansen> DrDetroit: np, I'll set something up and when your ready I'll have a kernel waiting for you
<DrDetroit> ok
<DrDetroit> jjohansen: may I ask a question?
<DrDetroit> jjohansen: Are we going to do the 29 again? or are we going to do the 30?
<DrDetroit> jjohansen: I am also wondering if I should let the 29 kernel we just finished run for a few hours like i did this one
<jjohansen> well I was thinking .28 - .30, which would cover everything, and we let them run longer
<jjohansen> so yeah
<DrDetroit> let me go ahead and before we start, let me run the one we just finished for a couple hours
<DrDetroit> maybe we can start on this this evening or morning
<DrDetroit> jjohansen: brb gonna reboot back to the 29 we just finished 
<DrDetroit> jjohansen: ok back on the 29 kernel we just finished
<DrDetroit> I will let it run for a couple hours
<DrDetroit> and see what happens
<jjohansen> yeah, sounds like a plan
<DrDetroit> too weird
<DrDetroit> jjohansen: I know yhou have better things to do that hold my hand, but I sure do appreciate it
<jjohansen> DrDetroit: its no problem, you are doing most of the work, I'm just cranking up the bisect as needed.  Your performance bug is a pretty serious regression and your not the only one who has reported seeing the behavior so it would be nice to track it down :)
<DrDetroit> jjohansen: it's nice to know I am not the only one, and I will be glad take whatever time we need to figure it out
<kristian-aalborg> DrDetroit: are you sure you used the correct commands?
<kristian-aalborg> I just waited an hour for nothing because of a typo....
<DrDetroit> kristian-aalborg: I am just testing out kernels that jjohansen is providing to me
<DrDetroit> jjohansen: back on the 28 kernel, will run it for a couple hours
<DrDetroit> the 29 was starting to slow down
<DrDetroit> I will report back after this one runs for awhile
<jjohansen> DrDetroit: I though .28 is the one you were running that was good and you have been running that one for hours already
<jjohansen> ie. it was in general use until .29 without problems
<DrDetroit> no i was running the 29 
<DrDetroit> first i ran the 30,  then the 29 and i just rebooted to the 28
<DrDetroit> and so far as i can tell atm the 28 is good, but i thought i would run it again for an hour or so while i do evening chores
<DrDetroit> I can go back and run the 29 again for a while
<DrDetroit> i dont mean to confuse you
<DrDetroit> I just wanted to double check that 28 was good
<DrDetroit> Once I get back from chores, I will run the 29 again that we just finished
<jjohansen> DrDetroit: okay thanks no worries, far better to take our time and make sure we got the right results this time
#ubuntu-kernel 2011-03-24
<kristian-aalborg> after building a (hopefully) working config, can I just "make menuconfig" and then Roosevelt stuff again?
<jjohansen> generally yes
<kristian-aalborg> cool
<kristian-aalborg> I guess that building kernels is a fairly good way to get the building process straight
<jjohansen> hehe, yeah its a great way :)
<kristian-aalborg> I might put a tutorial together... not on an expert level, obviously... but just how to get things running a bit better
<kristian-aalborg> will this building method work on any debian-derived distro?
<DrDetroit> jjohansen: here is the result of my test
<DrDetroit> 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC 2011 i686 GNU/Linux
<DrDetroit> 1:40,  2 users,  load average: 0.42, 1.03, 1.27
<DrDetroit> but its getting pretty poor performance
<DrDetroit> I thought 28 was good
<DrDetroit> I sure don't know what to think or do anymore
<DrDetroit> i guess i will go back to 27 i think i still have that on my menu
<DrDetroit> Do you know how long folks have been reporting this issue?
<jjohansen> DrDetroit: I had a user on the weekend reporting a similar issue but we didn't track it down
<jjohansen> DrDetroit: I am not even sure it is the same problem, but the symptoms are similar
<DrDetroit> jjohansen:  I am sort of unsure on how to proceed
<jjohansen> DrDetroit: lets give -27 a good run and see if you see problems there
<DrDetroit> jjohansen:  Ok I will do that
<jjohansen> DrDetroit: from last night bisects I would say we weren't giving the problem enough time to surface
<DrDetroit> I have been running that rotating torus screensaver
<DrDetroit> I can tell when things slow down after awhile
<jjohansen> DrDetroit: there is also the possibility the problem stems from something else that was updated at the same time as the kernel
<DrDetroit> it ls almost like an old fashioned windows memory leak
<DrDetroit> I have been running xchat, a terminal window, 3 instances olf mudlet (a mud client) and firefox
<jjohansen> yes, except in the one I was chasing on the weekend there was plenty of free memory
<jjohansen> we should check that when you see the slow down
<DrDetroit> ok
<jjohansen> DrDetroit: also we should try killing running processes one by one and see if that clears up the problem
<DrDetroit> Mem:    444440k total,   331720k used,   112720k free,    17080k buffers
<DrDetroit> Swap:  1299448k total,        0k used,  1299448k free,   151360k cached
<DrDetroit> that is current with only xchat and a terminal window running
<jjohansen> DrDetroit: so yeah good atm, and if we see the slow down check again
<DrDetroit> jjohansen: its slow now
<jjohansen> before we were just doing a bisect hunt for a kernel regression, this time we will be much more thorough
<DrDetroit> jjohansen: with those stats
<jjohansen> ah
<jjohansen> what does top report
<DrDetroit> that was top
<DrDetroit> 950 root      20   0  111m  39m 8692 S  5.8  9.1  25:24.79 Xorg               
<DrDetroit>  1708 bobp      20   0  2548 1192  904 R  2.6  0.3   0:00.44 top                
<DrDetroit>  1533 bobp      20   0 46296  12m 9724 S  1.3  3.0   0:32.65 gnome-terminal     
<DrDetroit>   223 root      20   0     0    0    0 S  0.3  0.0   0:05.54 usb-storage        
<DrDetroit>  1267 root      20   0  3612 1216 1036 S  0.3  0.3   0:05.28 hald-addon-stor    
<DrDetroit>  1396 root      20   0  5180  968  688 S  0.3  0.2   0:08.67 udisks-daemon      
<DrDetroit>  1581 bobp      20   0 49604  19m  12m S  0.3  4.5   1:35.80 xchat-gnome        
<DrDetroit> that is the maddening part
<jjohansen> okay and the load figures
<DrDetroit> nothing really shows up hogging cpu or memory
<jjohansen> okay
<DrDetroit> Cpu(s):  7.2%us,  3.6%sy,  0.0%ni, 89.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
<DrDetroit> thats from top 
<DrDetroit> its crappy poor at 90 percent idle
<DrDetroit> jjohansen: let me proppse this
<DrDetroit> I will reboot and go back to 27 but before i do that, i will double check my hardware to make sure it is all working properly including memory
<DrDetroit> i think it is
<DrDetroit> but i can double check
<DrDetroit> then i will boot back to 27 and run that for a while
<DrDetroit> I can report back later this evening or tomorrow early
<jjohansen> well yes that is worth doing, which kernel are you running /me thought you were on .27
<DrDetroit> whichever you prefer
<DrDetroit> currently this is 28 which i thought was good
<jjohansen> okay, well lets run a few commands first
<jjohansen> do
<jjohansen> sar 1 100
<DrDetroit> jjohansen:apparetnly its not installed
<DrDetroit> i will install it hold on
<jjohansen> sudo apt-get install sysstat
<DrDetroit> its running
<DrDetroit> it looks like it is repeating the same stuff, is that what you wanted
<jjohansen> yes, look at the iowait column
<jjohansen> what kind of figures are you seeing
<DrDetroit> Average:        all     37.54      7.69     11.41      0.28      0.00     43.08
<DrDetroit> the are all 0.00
<DrDetroit> i tanke that back i see one 7 a couple 6's and a couple 1's but the majority are 0.00
<jjohansen> alright so we aren't seeing io backup causing the slow down
<jjohansen> not a big deal, a few low numbers isn't going to be a problem
<DrDetroit> the average is .28
<DrDetroit> i did run itop but i really didnt understand what it was telling me
<jjohansen> if we where getting high numbers with high idle, it would indicate that processes are spending all their time blocked on io
<kristian-aalborg> will subsequent builds be significantly faster?
<jjohansen> kristian-aalborg: they can be, it depends on what make determines needs to be rebuilt, based off Makefile dependencies and time stamps
<jjohansen> so if you change a header file that gets included everywhere, everything needs to be rebuilt
 * kristian-aalborg screams!
<jjohansen> change a small section of a .c file and likely only 1 file gets rebuilt
<kristian-aalborg> it *still* does not work :(
<jjohansen> kristian-aalborg: are you doing make clean?
<kristian-aalborg> still goes straight to reboot
<kristian-aalborg> no, fdr clean
<jjohansen> ah fdr clean will clean out the old build
<kristian-aalborg> no no... I start out with fdr clean, then cp over the config file
<jjohansen> if you want to do an incremental build with the build system do rm debian/stamps/stamps-build-XXXX
<jjohansen> kristian-aalborg: right, 1 clean is needed, after which clean can be skipped if you want to do incremental builds
<kristian-aalborg> I thought I was going to want that, but not before my kernel works :/
<jjohansen> however depending on your config changes you may need to do a clean
<kristian-aalborg> jjohansen: obviously, something is still very wrong with the .debs I produce
<jjohansen> I am not sure how well the dependencies between the config file and the rest of the build system are tracked
<jjohansen> kristian-aalborg: :(
<jjohansen> DrDetroit: can you try running vmstat
<DrDetroit> sure
<DrDetroit> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
<DrDetroit>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
<DrDetroit>  1  0      0  77948  27512 172400    0    0    31     6  318 1975 46 10 44  1
<kristian-aalborg> build system is Lubuntu 10.4, box to use kernel on is Ubuntu 10.4... should be the same
<jjohansen> DrDetroit: what processes are running
<jjohansen> kristian-aalborg: what problems are you seeing with your .debs?
<DrDetroit> three terminal windows, xchat
<DrDetroit> and i just closed 1 terminal window
<kristian-aalborg> the debs look fine, I md5summed them too before install
<DrDetroit> of course there is the stuff on my panel
<kristian-aalborg> well, one of them... 
<DrDetroit> time date, sound etc
<jjohansen> DrDetroit: try this log out of your X session and log back in, let see if reset a session, restarting the panels etc, has an effect
<kristian-aalborg> jjohansen: it's what happens when I try to boot the kernel that I installed from those debs that things get weird :/
<DrDetroit> ok
<jjohansen> kristian-aalborg: still rebooting?
<DrDetroit> brb
<kristian-aalborg> jjohansen: yes
<jjohansen> kristian-aalborg: and you are just changing the config, no other patches right?
<kristian-aalborg> I did sudo dpkg -i linux-* this time, would be the same I reckon
<kristian-aalborg> yes, I use the config that's in /boot on the old box
<jjohansen> kristian-aalborg: can you send me the config, I will compare and try building a lucid kernel for you
<kristian-aalborg> http://pastebin.com/LUM4xbu9 this is what I get when I diff the two files
<jjohansen> kristian-aalborg: diff your config and the lucid config?
<DrDetroit> jjohansen: it is significently worse
<DrDetroit> and my desktop has changed themes
<DrDetroit> hehe
<kristian-aalborg> sorry for being unclear
<jjohansen> DrDetroit: interesting, want to look at top and sar output again
<DrDetroit> sure
<kristian-aalborg> this is the diff between the config from the working config and the non-working one - sent from the old machine
<DrDetroit> jjohansen: here is top
<DrDetroit> Tasks: 140 total,   1 running, 139 sleeping,   0 stopped,   0 zombie
<DrDetroit> Cpu(s): 21.9%us,  9.4%sy, 24.1%ni, 43.8%id,  0.6%wa,  0.1%hi,  0.0%si,  0.0%st
<DrDetroit> Mem:    444440k total,   385744k used,    58696k free,    29016k buffers
<DrDetroit> Swap:  1299448k total,        0k used,  1299448k free,   194280k cached
<jjohansen> kristian-aalborg: thats it? one not having cgroups shouldn't make any difference
<jjohansen> DrDetroit: and sar
<DrDetroit> Average:        all     29.36      0.00      7.80      0.44      0.00     62.41
<DrDetroit> iowaits ave .44
<kristian-aalborg> yes, it is weird
<jjohansen> alright
<DrDetroit> top was with sar running
<jjohansen> kristian-aalborg: can you send me the working config
<kristian-aalborg> http://pastebin.com/XZjV4Fup
<kristian-aalborg> here :)
<DrDetroit> jjohansen: we can continue this tomorrow if you would like to work with others tonite
<jjohansen> DrDetroit: its fine, we can keep going if you want
<kristian-aalborg> I should get some sleep... 3AM here... 
<DrDetroit> hehe
<kristian-aalborg> jjohansen: we could continue later, unless you're already building?
<jjohansen> kristian-aalborg: yeah I kicked it off, but we can continue later it will take a bit to build
<kristian-aalborg> depends on what "a bit" is on your system - on mine, it's usually hours ;)
<jjohansen> kristian-aalborg: say 20-30min
<kristian-aalborg> I think the smart thing for me is going to bed then
<kristian-aalborg> 30 mins of building
<DrDetroit> sleep....sleep....sleep
 * DrDetroit giggles
<jjohansen> hehe
<kristian-aalborg> then spending either one hour trying to figure out what went wrong or the rest of the night tweaking ;)
<kristian-aalborg> jjohansen: I'll catch up later, just remember not to delete the files ;)
<jjohansen> kristian-aalborg: :)
<jjohansen> DrDetroit: alright give the -27 kernel a spin
<kristian-aalborg> see ya, and thanks for helping out
<DrDetroit> jjohansen: ok will do
<DrDetroit> back later on
<DrDetroit> with a report
<DrDetroit> jjohansen: ok on 27 will let it run for a few hours with hypertorus screensaver running
<DrDetroit> I have my normal apps open and running also
<jjohansen> DrDetroit: okay I'll check back in a few hours
<fairuz> Hi morning
<jjohansen> morning
<fairuz> jjohansen: can i start with my questions? :D
<jjohansen> sure
<fairuz> jjohansen: about /usr/src/linux-headers-xxxxxxx, I need one for each kernel i compile?
<fairuz> jjohansen: because i see files in /lib/modules/xxxxxxxx/build point to the headers folder
<jjohansen> fairuz: define need, they are good to have but the headers aren't "needed" to run the kernel
<fairuz> jjohansen: yes, i mean for compiling external module
<fairuz> jjohansen: for external module, i need all of those right?
<jjohansen> yes, the headers are needed for compiling external modules
<fairuz> jjohansen: and i suppose there are make install_headers to create this folder?
<fairuz> :D
<jjohansen> fairuz: the target is actually headers_install
<jjohansen> fairuz: or maybe headers_install_all
<fairuz> jjohansen: I think I already tried that, but no idea where the files go after it finishes
<jjohansen> for the work I've done I've never needed to do it, but yeah its there
<fairuz> jjohansen: I compile the kernel with custom name and it boots ok
<fairuz> jjohansen: just there is no display right now, which I think it's normal because I'm not installing the modules yet
<jjohansen> fairuz: sounds about right
<fairuz> jjohansen: i just get the plain console. I will try now to use sshfs to install the modules. I tried it yesterday but got some problems
<fairuz> jjohansen: something about permissions
<jjohansen> fairuz: hrmm, I think I might know what you hit, give me a minute to find it
<jjohansen> fairuz: http://blog.sumostyle.net/robg/2006/08/07/some-useful-sshfs-options/
<fairuz> jjohansen: ok i'll take a look at it
<jjohansen> you may need allow_root or allow_other, I can't remember which
<jjohansen> I think I did the mount as my regular user and I had to use allow_root, to get the install to work
<fairuz> jjohansen: i'll try that
<fairuz> jjohansen: have to reboot with my working kernel first :D
<fairuz> jjohansen: it's not a simple thing this whole kernel thing. To get it booted is one thing. To get it works with all the modules is other thing.
<jjohansen> yeah it can be a pain, there are reasons to like monolithic kernels
<fairuz> jjohansen: so you do sshfs without sudo ?
<jjohansen> fairuz: that I can't remember, the remote install I was doing where a while ago
<jjohansen> I know I did sudo make install ; sudo make modules_install
<fairuz> jjohansen: ok. 
<jjohansen> but I think the fuse mount was probably done as a user
<jjohansen> I know I did the compile as just a plain user
<fairuz> jjohansen: it dont let me to use -o, I need to edit /etc/fuse.conf
<jjohansen> fairuz: yeah, I think I had to do that too
<jjohansen> getting it setup was a bit of a pain
<jjohansen> but it worked well once I had it
<fairuz> jjohansen: one thing i find it weird, before it asking the remote password. It asks for my password 3 times. Each time.
<jjohansen> hrmm, I don't remember it doing that, but its possible, /me needs to go back and try doing a remote install like this again some time
<fairuz> jjohansen: it's installing the modules now :D
<fairuz> jjohansen:  I use sudo sshfs -o allow_other,default_permissions <host> <mountpoint>
<jjohansen> yeah that sounds like it should work
<DrDetroit> and good morning to all
<fairuz> jjohansen: i only have around 400Mb left on the SD, hope it's enough
<fairuz> DrDetroit: morning
<jjohansen> morning DrDetroit
<DrDetroit> jjohansen: I have run the 27 kernel since falling asleep last night
<DrDetroit> it seems ok , have not seen any issues yet
<jjohansen> hrmm okay
<DrDetroit> let me open up a few more apps and see what happens
<fairuz> jjohansen: It finishes :D
<jjohansen> :)
<fairuz> jjohansen: but I think I should change the symlink for build and source
<fairuz> jjohansen: right now it points to the mounpoint
<jjohansen> hehe, yeah that might be an idea
<fairuz> jjohansen: maybe I should change it directly to my source folder in the build machine?
<fairuz> jjohansen: since it's accessible by network
<jjohansen> fairuz: that should work
<fairuz> jjohansen: i will be happy if this works :D
<fairuz> jjohansen: hmm still no luck. I got FATAL: Could not load /lib/modules/2.6.35-980-omap4-fairuz/modules.dep: No such file or directory
<fairuz> jjohansen: but the file is there!
<jjohansen> fairuz: try running depmod -ae
<fairuz> WARNING: -e needs -E or -F
<fairuz> FATAL: Could not open /lib/modules/2.6.35-980-omap4-fairuz/modules.dep.temp for writing: Permission denied
<jjohansen> fairuz: sudo depmod -a
<fairuz> jjohansen: ok done. what it does?
<fairuz> jjohansen: i reboot now?
<jjohansen> depmod - program to generate modules.dep and map files.
<jjohansen> sure give it a try
<kristian-aalborg> jjohansen: hi again
<jjohansen> morning kristian-aalborg
<DrDetroit> morning kristian-aalborg
<kristian-aalborg> morning
<kristian-aalborg> what time is it where you people live?
<jjohansen> 02:34
<fairuz> >:o
<DrDetroit> 4:34
<jjohansen> kristian-aalborg: kernel.ubuntu.com/~jj/linux-image-2.6.32-31-generic_2.6.32-31.60~kristian_i386.deb 
<kristian-aalborg> ah, east and west coast I suppose
<kristian-aalborg> jjohansen: thanks
<DrDetroit> central here, I live n the Ozark mountains of Arkansas
<kristian-aalborg> I have a load of wires all over the place atm, it will be a moment before I can download anything
<fairuz> jjohansen: still got FATAL: Could not load /lib/modules/2.6.35-980-omap4-fairuz/modules.dep: No such file or directory
<jjohansen> fairuz: hrmm, is /lib mounted, at this point?
<fairuz> jjohansen: I have no idea of this
<jjohansen> fairuz: how is the filesystem layed out are you using an initramfs/initrd is /lib in the root filesystem
<fairuz> jjohansen: I have no idea about initramfs, but now when it finishes botting, i can go in /lib yes
<jjohansen> what does mount show
<fairuz> jjohansen: oh there is not /lib
<fairuz> proc on /proc type proc (rw)
<fairuz> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
<fairuz> none on /sys type sysfs (rw,noexec,nosuid,nodev)
<fairuz> none on /sys/kernel/debug type debugfs (rw)
<fairuz> none on /sys/kernel/security type securityfs (rw)
<fairuz> none on /dev type devtmpfs (rw,mode=0755)
<fairuz> none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
<fairuz> none on /dev/shm type tmpfs (rw,nosuid,nodev)
<fairuz> none on /var/run type tmpfs (rw,nosuid,mode=0755)
<fairuz> none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
<fairuz> jjohansen: hmm ... but why with other kenel, it loads ok
<jjohansen> fairuz: hrmm I not sure
<fairuz> jjohansen: wait i go restart all machines and retry
<DrDetroit> well now, that was strange, my screensaver went off, but returned back to the regular screen
<fairuz> jjohansen: is this something to do with initrd?
<fairuz> jjohansen: at boot, i load uImage and also uInitrd
<jjohansen> fairuz: yep, what files are in /boot/
<jjohansen> DrDetroit: its not unheard of for the screen saver to have odd bugs
<DrDetroit> hehe, i know, its a computer, it's all smoke and magic to me
<jjohansen> if you can replicate it is worth filing a bug over
<fairuz> jjohansen: there are some vmlinuz files, system.map files, initrd.img-xxxxx
<DrDetroit> naw
<jjohansen> fairuz: so you need to make an initrd
<fairuz> jjohansen: there are files for my old kernel, no files for my new kernel
<fairuz> jjohansen: ah ok.. any help to do that?
<jjohansen> fairuz: no files at all or no initrd
<fairuz> jjohansen: what this thing do? it's ubuntu thing or kernel thing?
<jjohansen> fairuz: hrmmm well sort of both
<jjohansen> the kernel doesn't need one but one is often used for flexibility
<jjohansen> ubuntu uses one
<fairuz> jjohansen: i have for example initrd.img-2.6.35-980-omap4 but no initrd.img-2.6.35-980-omap4-fairuz
<jjohansen> fairuz: I am going to assume its an initramfs
<fairuz> and also i have vmlinuz-2.6.35-980-omap4 but no vmlinuz-2.6.35-980-omap4-fairuz
<fairuz> jjohansen: same thing applies for System.map and abi files
<jjohansen> sudo update-initramfs -ck 2.6.35-980-omap4-fairuz
<fairuz> jjohansen: ok
<jjohansen> fairuz: hrmm, do you do a make install?
<jjohansen> fairuz: or did you just copy the vmlinuz
<fairuz> jjohansen: nope, just make xxx_defconfig and make uImage
<fairuz> jjohansen: then i just copy the uImage
<jjohansen> fairuz: generally make install will copy those as well as the kernel
<jjohansen> you could use the same sshfs trick to do make install as make modules install
<jjohansen> fairuz: also update-initramfs isn't the only way to make a ramdisk but it is the way ubuntu uses, I am not up to date on other methods
<fairuz> jjohansen: i have now initrd.img for my kernel
<fairuz> jjohansen: it still not working. i will try the make install now
<jjohansen> fairuz: make install and then remake the ramdisk
<jjohansen> fairuz: instead of -ck use -uk
<fairuz> jjohansen: actually it generate the initrd but it gives this grep: /boot/config-2.6.35-980-omap4-fairuz: No such file or directory
<fairuz> i should copy my config to /boot folder first?
<fairuz> or make install will do that
<jjohansen> hrmm, configs shouldn't be needed but system.map and abi I believe are
<jjohansen> fairuz: but if its complaining about the config missing if make install doesn't put it there copy it yourself
<fairuz> jjohansen: ok understood
<fairuz> jjohansen: sudo install will not recompile the kernel i suppose?
<jjohansen> fairuz: sudo make install should not recompile the kernel
<jjohansen> well at least as long as you haven't changed any timestamps
<fairuz> jjohansen: if both machines have different time? :D
<fairuz> jjohansen: because right now i'm seeing a lot of CC
<fairuz> jjohansen: which i think it's in the process of the compiling
<jjohansen> fairuz: its the files time stamps that should be important, I'm not sure why you would be seeing lots of CC
<jjohansen> which is indeed compiling
<fairuz> jjohansen: well i will let it compile then ( which will take forever since it's compiling on the target machine )
<fairuz> jjohansen: So if I understand well, I should do make install that will install necessary files to /boot
<jjohansen> fairuz: it should
<fairuz> jjohansen: and this file is used during the boot i suppose?
<jjohansen> fairuz: or for setting up the module dependencies, building the initramfs (which is used during boot)
 * jj-afk is going to be off for a bit
<DrDetroit> jj-afk: up  8:16,  2 users,  load average: 0.58, 0.79, 0.74
<fairuz> jj-afk: ok thanks for your help
<DrDetroit> just for info purposes i think 27 is ok
<DrDetroit> see you later
<jj-afk> DrDetroit: okay, 27 looks okay but not 28, I'll build a kernel for you to test, while I am a way
<DrDetroit> thanks, see you later on today
<jj-afk> DrDetroit: I am give me 20 min, and I'll have the kernel for you
<jj-afk> DrDetroit: kernel.ubuntu.com/~jj/linux-image-2.6.32-28-generic_2.6.32-28.50~lp740549.13417a_i386.deb
<jj-afk> these ones are going to be slightly different in that I am tagging them with part of the commit sha
<jj-afk> so if you don't want all the test kernels installed at the same time, then you will need to dpkg -r the package when done testing with it and moving on
<fairuz> jj-afk: there?
<DrDetroit> jj=afk: so if i understand correctly, I should 1) download the package 2) install it the same way we did the others with dpkg -i <packagename>
<DrDetroit> then once I am done testing do a dpkg -r <packagename> before moving on to the next one
<DrDetroit> jj-afk: so if i understand correctly, I should 1) download the package 2) install it the same way we did the others with dpkg -i <packagename>
<DrDetroit> then once I am done testing do a dpkg -r <packagename> before moving on to the next one
<DrDetroit> jj-afk: downloaded and testing first kernel
<DrDetroit> l
<tgardner> ogasawara, are you planning to rebase natty master-next for 2.6.38.1 today?
<ogasawara> tgardner: yep, was gonna do it right after I finish up this Maverick to Natty config delta review
<tgardner> ogasawara, cool
<ppisati> ogasawara: lp#737073 - why did you mark it invalid for lucid/maverick? the description says it affects kernels before 2.6.37
<ogasawara> bug 737073
<ubot2> Launchpad bug 737073 in linux "CVE-2010-4527" [Medium,Fix committed] https://launchpad.net/bugs/737073
<ogasawara> ppisati: I want to recall that it's because the patch is already in maverick/lucid via stable updates, but I'll have to double check
<tgardner> ogasawara, if so, shouldn't it be 'fix released' ?
<ppisati> ogasawara: ah ok
<ppisati> ppisati: i didn't check the tree before asking, ok
<ogasawara> tgardner: yah, I suppose it could be marked Fix Released rather than Invalid
<tgardner> ogasawara, that more closely matches the CVE tracker state, doesn't it?
<ogasawara> tgardner: the CVE tracker state is marked as not-affected so I guess it just depends how we want to interpret it
<tgardner> ogasawara, well, the security team has been dinging us for not noticing when stable updates fix a CVE, even though its not noted in the upstream commit log.
<ogasawara> tgardner: ah, in that case Fix Released is probably a better status to use
 * ogasawara back in 20min
<ppisati> bug 736394
<ubot2> Launchpad bug 736394 in linux-source-2.6.15 "CVE-2010-4342" [Medium,In progress] https://launchpad.net/bugs/736394
<ppisati> i nominated it for maverick
<ppisati> can anyone pass the nomination?
<tgardner> ppisati, LP keeps timing out
<smb> tgardner, ppisati Did it (was closer)
<ogasawara> https://launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
<ogasawara> ^^ anyone else get an error if they try to edit the whiteboard?
<tgardner> ogasawara, I just changed your name in the Whiteboard
<ogasawara> tgardner: cool, thanks
<tgardner> ogasawara, maybe your LP privs are eroding.
<sconklin> tgardner: so the ABI problems with the packages were not the root cause of the FTBFS? (just trying to stay current)
<tgardner> sconklin, I can't say for sure since LUM had the same issues, and is in the dependency chain.
<sconklin> ok
<tgardner> sconklin, thats gotta get fixed first before I can tell if its the root of the HPPA FTBS. its just about gotta be that 'cause nothing else has changed.
<sconklin> tgardner: yeah, and it makes sense that it could be the cause
<tgardner>  sconklin: so, in order to avoid this ever happening again, I'm ripping out all generated files from dapper/hardy and subsidiary packages.
<sconklin> tgardner: great! Brad and I had the "OMG how many other packages could have this problem" conversation last night, but you got there first
<sconklin> Even more scary is that potentially it could have happened and not resulted in a build failure
<tgardner> sconklin, it likely is an indicator of how many folks aren't using Hardy LUM 'cause I don't think the modules would load, bot nobody has complained.
<smb> tgardner, Was Hardy also still carrying the abi number asclear text or was it just re-creating those depending files?
<sconklin> Brad and I have also talked about trying to get download stats for dapper and hardy, I'm curious how many consumers they have, and I think the stats are available now
<smb> tgardner, I usually would notice when booting the test laptop. But it is more something like "hm, it is very silent on boot"
<tgardner> smb, Hardy LUM/LBM had debian/control committed in the repo, which makes it easy to _not_ correctly generate the ABI info.
<tgardner> Hardy LRM as well
<fairuz> how to generate vmlinuz kernel file? I just have uImage, zimage and compressed/vmlinux. Thanks
<smb> tgardner, Ah yes, I was unsure whether Hardy also still have the abi number in the rules file instead of using the number from the changelog
<smb> That is what caught me when doing dapper lrm
<tgardner> smb, dapper is worse. you _have_ to run the bumpabi target in order to get the udeb stuff henerated correctly.
<smb> tgardner, Even worse that is the kernel package only. There is no bumpabi target in lrm
<tgardner> smb, right, but we only have to live with that for a couple of months more
<smb> That is the hope one can hold on. :)
<tgardner> ogasawara, there is no '-' in your LP name. I see you've corrected it already in https://launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
<ogasawara> tgardner: yep, no -
<bjf> GrueMaster, have you signed off on the mvl-dove kernels now in -proposed ?
<GrueMaster> I have tested the 216/416 kernels, yes.  I had noted that in the release tracking bug.
<GrueMaster> or one of the bugs.
<bjf> GrueMaster, i'm looking at what I think is the tracking bug, can you point me at the one you added a comment to? I'll also hunt for it.
<GrueMaster> Well, looking at http://kernel.ubuntu.com/~kernel-ppa/reports/sru-report.html I see 4 proposed tracker bugs listed under linux-mvl-dove.  I'm not sure at this point as there were 3 kernels in proposed at one point.
<bjf> GrueMaster, ok, thanks, we are working on the "tracking bug" issue
<GrueMaster> The only bug I cannot verify is bug 732700.
<ubot2> Launchpad bug 732700 in linux-mvl-dove "apparmor_parser triggers a kernel panic" [Undecided,Fix committed] https://launchpad.net/bugs/732700
<DrDetroit> l
<GrueMaster> But I believe ppisati was going to test it (since he filed it).
<ppisati> GrueMaster: did it, and it's ok
<ppisati> GrueMaster: i mean, it doesn't happer anymore
<ppisati> *happen
<GrueMaster> right.
<GrueMaster> cool
<GrueMaster> bjf: I just added my test notes to tracking bug 734950
<ubot2> Launchpad bug 734950 in linux-mvl-dove "linux: 2.6.32-31.60 / linux-ec2 2.6.32-315.28 -proposed tracker" [Undecided,Fix committed] https://launchpad.net/bugs/734950
<GrueMaster> Although it doesn't list the specific kernel versions for dove.
<DrDetroit> jjohansen: been running the 1st kernel for about 3hrs now, no problems yet
<DrDetroit> i forgot how to remove my away status, hehe
<jjohansen> DrDetroit: okay, I kick off the next one
<tayal> i am willing to build a kernel.. can i do this in my maverick if it will have no harm?
<jjohansen> DrDetroit: kernel.ubuntu.com/~jj/linux-image-2.6.32-28-generic_2.6.32-28.50~lp740549.4636a8_i386.deb
<jjohansen> tayal: you can build your own kernel if you want https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<bjf> tayal, yes you can
<bjf> tayal, is there a reason you want to build your own kernel ?
<aakshay> jjohansen: hey.. :) thanks.. 
<aakshay> bjf,
<aakshay> bjf: hi. :).. yes
<aakshay> i am learning device driver design
<aakshay> bjf,: so need to hav kernel builded to run my modules
<aakshay> bjf: but i am confused exactly how to build the kernel? How to start? :(
<bjf> aakshay, see the url that jjohansen just posted ^^
<tayal> bjf: are these the only steps? 
<bjf> tayal, yes, that all you need to get a kernel built and installed
<tayal> bjf: what is the meaning of Root of Kernel Source?
<bjf> tayal, the topmost directory in the kernel source tree
<tayal> bjf: ok.. i am downloading the source. thanks for the help. :)
<bjf> tayal, np
<tayal> jjohansen: thanks :)
<DrDetroit> jjohansen: dl now, to remove the one I just tested it is dpkg -r linux-image-2.6.32-28-generic?
<jjohansen> DrDetroit: dpkg -r linux-image-2.6.32-28-generic_2.6.32-28.50~lp740549.13417a_i386.deb
<jjohansen> ah, stupid paste
<DrDetroit> jjohansen: dpkg: you must specify packages by their own names, not by quoting the names of the files they come in
<jjohansen> DrDetroit: yes, sorry I was looking up what the exact package was that you installed and ended up pasting that in
<DrDetroit> it removed it when i did  -r linux-image-2.6.32-28-generic?
<DrDetroit> i am ok
<jjohansen> yeah
<DrDetroit> installing now
<DrDetroit> ok ready to test it for a couple hours
<DrDetroit> back shortly
<DrDetroit> and back
<DrDetroit> jjohansen: will give this one a few hours at least 
<jjohansen> DrDetroit: yep
<DrDetroit> I guess that means I will have to go mow the yard
 * DrDetroit pouts
<DrDetroit> l
<herton> ogasawara: bug 735640 can be marked as fixed in changelog with latest 2.6.38.1 update in natty
<ubot2> Launchpad bug 735640 in linux "Request support for Ortek PKB1700 wireless kb" [Undecided,In progress] https://launchpad.net/bugs/735640
<herton> and may be someone should nominate it for natty? I don't know
<ogasawara> herton: cool, I'll add it
<herton> also bug 735450 should be fixed, but no reporter confirmed it the testing kernel I uploaded
<ubot2> Launchpad bug 735450 in linux "BUG: unable to handle kernel NULL pointer dereference at 000001e4" [Undecided,Incomplete] https://launchpad.net/bugs/735450
<herton> s/confirmed it/confirmed
<ogasawara> herton: yah, I suspect they filed it and then forgot about it.  I'll just add it so it gets closed.  They can always reopen it if necessary.
<herton> ok, thanks
<cnd> ogasawara, do you know if the canonical hwe or platform services guys read the ubuntu-kernel mailing list?
<cnd> I want to send something that will reach everyone, but specifically them
<cnd> the kernel-team mail list is pretty verbose now...
<ogasawara> cnd: hrm, hard to say.  I'd say they probably don't follow it very closely.
<cnd> ok
<cnd> I'll probably send two emails then
<cnd> I don't like to add private list CC's to a public email
<ogasawara> cnd: makes sense
 * tgardner --> lunch
<vanhoof> cnd: we read it :)
<vanhoof> cnd: just fwd if you'd like
<cnd> vanhoof, ok
<sconklin> jjohansen: what's the status of the performance regression that you were bisecting? Just curious . . .
<jjohansen> sconklin: haven't found it yet, turns out it show up in the entire range we bisected, the is -28 wasn't good
<jjohansen> sconklin: so we have expanded the range and each bisect is being tested for the 3-4 hours necessary for the problem to surface
<sconklin> jjohansen: so the possibility exists that it really is from the scheduler updates
<jjohansen> sconklin: yeah
<sconklin> jjohansen: could you please keep the bug updated and point to the bisection branch so we can tag-team this?
<jjohansen> sconklin: sure
<sconklin> thanks. I'm curious to see what this one is and why it takes hours to show up
<jjohansen> sconklin: me too
<sconklin> DrDetroit: is it possible for you to provide a very detailed set of steps for how to reproduce the issue and tell when it happens? Ideally we could get it added as a unit test for QA
<bjf> sconklin, jjohansen, DrDetroit, it would be nice if we could duplicate the problem as well
<jjohansen> bjf: yep, I have started trying to do that, on actual hardware vs vm
 * jjohansen -> lunch
<DrDetroit> sconklin bjf jjohansen: sorry i was outside mowin. I am not sure how to tell you to duplicate it
<DrDetroit> I just run my normal stuff and after awhile the machine just turns to mush, but nothing really shows up in top or ps aux
<DrDetroit> it might be 20 min, it might be several hours
<DrDetroit> but I don't mind doing this, since I have plenty of extra time on my hands
<sconklin> DrDetroit: one more tool, it may not show anything, but you can try latencytop
<DrDetroit> let me try that
<DrDetroit> installing
<jjohansen> DrDetroit: right, but we can't be sure whether a bisect is good for several hours, its easy when its bad
<jjohansen> sconklin: yeah thats another good one to use, I have been asking for vmstat, sar, top, and a few other things
<DrDetroit> ok how do i read this
<DrDetroit> let me copy the global here so you guys can see it
<DrDetroit> 'fudge it wont let me copy
<DrDetroit> well scheduler seems to have the most pecentage
<DrDetroit> 36-40%
<DrDetroit> when i have it set on global one of the items i see is jbd2/sdb1-8, I never heard of that
<DrDetroit> its at 46%
<skaet> DFo, ogasawara - based on scans so far (it changes every minute after all..  :P ) only new high/critical bug I've found to add to kernel's list this week is Bug:634487
<skaet> the searching/scanning will continue though this afternoon.... ;)
<skaet> rest of the bugs are already on the list from last week.
<ogasawara> skaet: cool, thanks
<ogasawara> bug 634487
<ubot2> Launchpad bug 634487 in linux "t1.micro instance hangs when installing java" [High,Confirmed] https://launchpad.net/bugs/634487
<DrDetroit> sconklin: latencytop installed and running
<DrDetroit> what should I look for?
<sconklin> heh, it's not helpful to say "anything that looks unusual", is it.
<DrDetroit> well
<DrDetroit> scheduler stays above 35%
<sconklin> Just see if anything jumps to the top when the system starts going south
<DrDetroit> ok
<sconklin> Also look for any of the latency numbers in the "maximum" column which get really huge
<DrDetroit> oh
<DrDetroit> how big is huge?
<DrDetroit> kswapd0 is 97
<tgardner> bjf, wtf does a version look like as an option to create-stable-tracker ?
<bjf> tgardner, it's just a string which will be used in the title, and description so for example: 2.6.32.35+drm33.15
<tgardner> bjf, so in theory it could be anything?
<bjf> tgardner, yes, i don't check it for any kind of "correct-ness"
<tgardner> hmm, it keeps blowing up. create-stable-tracker --version 2.6.32.35:
<tgardner> version: 2.6.32.35
<tgardner> Traceback (most recent call last):
<tgardner>   File "/usr3/ubuntu/kteam-tools/stable/create-stable-tracker", line 228, in <module>
<tgardner>     app.main()
<tgardner>   File "/usr3/ubuntu/kteam-tools/stable/create-stable-tracker", line 144, in main
<tgardner>     raise AppError("The version (%s) is not a recognized version string." % (self.cfg['version']))
<tgardner> __main__.AppError
<JFo> thanks skaet 
<tgardner> r
<JFo> aparently I have been running around all day set to away :-/
<bjf> tgardner, --version=2.6.32.35  though i expect it to behave better than that
<tgardner> bjf, that was the next thing I tried: create-stable-tracker --version=2.6.32.35
<tgardner> version: 2.6.32.35
<tgardner> Traceback (most recent call last):
<tgardner>   File "/usr3/ubuntu/kteam-tools/stable/create-stable-tracker", line 228, in <module>
<tgardner>     app.main()
<tgardner>   File "/usr3/ubuntu/kteam-tools/stable/create-stable-tracker", line 144, in main
<tgardner>     raise AppError("The version (%s) is not a recognized version string." % (self.cfg['version']))
<tgardner> __main__.AppError
<tgardner> bjf, these error messages lead me to believe that there  is a required format.
<bjf> tgardner, looking
<bjf> tgardner, interesting, it checks against the debian version, one sec
<bjf> tgardner, i'm debugging it
<ogasawara> skaet: hrmph, it looks like the gcc armel build was restarted for some reason which is going to delay our no-change kernel upload from today until tomorrow.  The kernel then won't finish being built until Saturday now.
<bjf> tgardner, pull it and see if that works better, it's just a string now
<DrDetroit> jjohansen: Been running this one for just over 4hrs, downloaded a ubuntu server instal cd, did some browsing etc, it seems ok for now
<jjohansen> DrDetroit: okay, I'll kick off the next one
<tgardner> bjf, seems to have worked.
<bjf> tgardner, double check the bug for content
<tgardner> bjf, bug #742056
<ubot2> Launchpad bug 742056 in linux "Lucid update to v2.6.32.35.15 stable release" [Undecided,New] https://launchpad.net/bugs/742056
<bjf> tgardner, looking
<bjf> tgardner, did you have to do anything or did the script do all that for you ?
<tgardner> bjf, so, you don't target any other kernels? we should do this for every variant?
<tgardner> bjf, the script did it all
<bjf> tgardner, you mean fsl-imx51 and mvl-dove and ec2 for Lucid ?
<tgardner> bjf, yes
<bjf> tgardner, ok, sconklin and i were just going over our todo list and i'll get that on it
 * ogasawara back on later
<jjohansen> DrDetroit: kernel.ubuntu.com/~jj/linux-headers-2.6.32-28-generic_2.6.32-28.50~lp740549.8d6842_i386.deb
<DrDetroit> jjohansen: on my way
<DrDetroit> jjohansen: that didnt take 1 sec to download
<DrDetroit> is that coorect>?
<jjohansen> hrmm let me check
<DrDetroit> that one says linux headers
<jjohansen> DrDetroit: ha no, I gave you the header name not the image
<DrDetroit> ok
<tgardner> bjf, pushed lucid Linux 2.6.32.35, seems to build OK. did you empty out pre-proposed so that it'll build in the morning?
<DrDetroit> let me delete that one then
<jjohansen> kernel.ubuntu.com/~jj/linux-image-2.6.32-28-generic_2.6.32-28.50~lp740549.8d6842_i386.deb
<bjf> tgardner, no
<bjf> tgardner, i can handle that if you want
<tgardner> bjf, um, not sure what you mean. I just pushed the stable updates to Lucid master-next.
<tgardner> oh, you mean about emptying the PPA
<bjf> yes
<tgardner> yeah, it needs doing.
<tgardner> go ahead
<bjf> tgardner, i've deleted the email can you forward
<bjf> tgardner, and i'll take if from there
<tgardner> bjf, so have I. just delete all packages that have been superseded. I'll check back in a few hours.
<bjf> tgardner, what's the url to pre-proposed ?
<tgardner> https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<bjf> tgardner, thanks
<tgardner> bjf: 6.8 GiB (84.65%) of 8.0 GiB
<tgardner> I'm outta here for the day.
<sbeattie> bjf: ask on #soyuz on i.c.c to make that ppa larger, if you need.
<bjf> sbeattie, thanks
<DrDetroit> back in a few
<DrDetroit> and back
<DrDetroit> jjohansen: do you know about how many we will have to do this round?
<jjohansen> DrDetroit: I think it was 4 more
<DrDetroit> ok cool, just curious
<jjohansen> DrDetroit: yep 4
<DrDetroit> no problemo
<DrDetroit> just trying to understand ubuntu-server 10.04 LTS while I am waiting
<skaet> ogasawara, arm is a mess right now from the builds, so somehow not feeling surprised to hear it.  :P   thanks for the head's up.
<kristian-aalborg> hey jjohansen 
<jjohansen> hi kristian-aalborg
<kristian-aalborg> thanks a lot for building that kernel, I've not tested yet though
<kristian-aalborg> I have a kernel-burnout today ;)
<kristian-aalborg> how did compiling it go? anything fishy?
<jjohansen> kristian-aalborg: np, hrmm I don't remember anything fishy I should try it again to be sure
<jjohansen> :)
<kristian-aalborg> nah, we'll know when I try to boot it
<kristian-aalborg> but, only one file?
<jjohansen> kristian-aalborg: what were you looking for?  There are a few other pacakges related to it like headers, but they aren't needed to test if the kernel boots
<kristian-aalborg> I thought at least two files were needed, image + headers
<DrDetroit> jjohansen: I am going to take a break for a bit, I should be back before you log off for the night
<jjohansen> DrD_away: that shouldn't be a problem, as I don't usually log off until after you wake up :)
<DrD_away> haha
<DrD_away> thats cause i am old
 * DrD_away chuckles
<jjohansen> kristian-aalborg: no the headers aren't needed, at least for straight boot testing, now if you want to build certain things like external modules, or actually many applications they are needed
<jjohansen> DrD_away: nah, its because you are sane and value a good nights sleep
<kristian-aalborg> jjohansen: ah, okay
<kristian-aalborg> can I have the link again?
<kristian_> jjohansen, sorry, box died
<jjohansen> kristian_: kernel.ubuntu.com/~jj/linux-image-2.6.32-31-generic_2.6.32-31.60~kristian_i386.deb
<kristian_> thanks
#ubuntu-kernel 2011-03-25
<kristian_> md5sum please?
<ohsix> you're going to break your keyboard pasting that thing that much
<kristian_> ohsix: huh?
<ohsix> kristian_: jjohansen has pasted that url like 100 times :D
<kristian_> 42e784beb5ad478a68dc0a41fb4c7b39
<kristian_> ohsix, no, exactly two times
<ohsix> i see, i guess they were mostly different
<jjohansen> ohsix: not quite, I have pasted similar urls, the base is the same but the name of the deb is slightly different
<kristian_> ohsix, believe me, there is a limited market for this .deb ;)
<DrDetroit> jjohansen: back, up 6 1/2 hrs with no problems, i am currently playing music via rythembox
<jjohansen> DrDetroit: okay, kicking off the next kernel
<DrDetroit> this will probably be the last one for me tonite
<DrDetroit> i will most likely let it run till morning
<DrDetroit> sorry i fell asleep watching Arkansas PBS, they had The Cate Brothers Band on tonite, really great stuff
<jjohansen> DrDetroit: no need to apologize, I am just happy you are so willing to test
<DrDetroit> I don't mind at all
<DrDetroit> after all the stuff the linux community has given me over the years, it is the least i can do
<DrDetroit> hehe I have to check George's Majestic Lounge's happy our schedule to see if the Cate Brothers are playing there soon
<DrDetroit> brb
<jjohansen> DrDetroit: kernel.ubuntu.com/~jj/linux-image-2.6.32-28-generic_2.6.32-28.50~lp740549.db8219_i386.deb
<DrDetroit> on my way
<DrDetroit> rebooting back in a min
<fairuz> hi, morning
<jjohansen> morning
<fairuz> jjohansen: it never succeed doing make install on the board with it recompiling all the files =(
<fairuz> jjohansen: but now it boots and i have /lib/modules/mykernel
<jjohansen> fairuz: rebuild it on the build machine
<jjohansen> fairuz: ?
<fairuz> jjohansen: yesterday, i do flash-kernel and apparently it create a new initrd
<fairuz> jjohansen: on the boot partition
<jjohansen> fairuz: ah, interesting
<fairuz> jjohansen: so right now it boots without errors, but still not display
<fairuz> jjohansen: but thats not a problem
<jjohansen> what is the problem now
<fairuz> jjohansen: the problem is that it dont want to compile my external module
<jjohansen> what errors is it giving?
<fairuz> jjohansen: when I do module_install, it create a symlink build that points to my mounted build machine..so before compiling I have to mount build machine using sshfs. Then when i try to copile it gives me a few lines of scripts/basic/fixdep : 1: cannot create P : permission denied
<fairuz> ELF not found
<fairuz> and some wirds symbols, all with not found errors
<fairuz> *weird
<fairuz> jjohansen: symbols problem?
<jjohansen> fairuz: I don't know
<fairuz> jjohansen: ok
<fairuz> jjohansen: btw, how to generate the linux-headers-xxxxxxxxxxx folder?
<fairuz> jjohansen: headers_install don't do the job
<jjohansen> fairuz: make headers_install_all
<jjohansen> I think, its not a step I usually do for the type of building and testing I do
<fairuz> jjohansen: ok, I understand. You already helped me a lot
<tayal> while building the lernel, root bradcasted the system shutdown command.. :(  then the system booted again.. is the building process completed?
<tayal> the three debfiles are also not created.. only one 
<tayal> alis created "all.deb"
<tayal> *that is
<jjohansen> tayal: it sounds like it didn't finish
<tayal> jjohansen: yes.. as i find now this commad "sudo apt-get build-dep linux-image-$(uname -r)" is not successfull 
<tayal> showing the error "E: Could not open file /var/lib/apt/lists/ppa.launchpad.net_lernid-devs_lernid-releases_ubuntu_dists_maverick_main_source_Sources - open (2: No such file or directory)"
<tayal> jjohansen: so may be the fakeroot command is not successfull
<tayal> :(
<jk-> tayal: `sudo apt-get update` first
<tayal> jjohansen: ok
<tayal> running... 
<tayal> jjohansen: done..
<tayal> what to do next? :)
<jjohansen> tayal: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<tayal> jjohansen: i am using this tutorial only
<tayal> but the command "sudo apt-get build-dep linux-image-$(uname -r)" is not successfull
<tayal> jjohansen: its showing error "E: Could not open file /var/lib/apt/lists/ppa.launchpad.net_lernid-devs_lernid-releases_ubuntu_dists_maverick_main_source_Sources - open (2: No such file or directory)"
<tayal> jjohansen: how can i correct it.. dont find anything on google also :(
<jk-> tayal: the 'apt-get update' didn't fix that?
<tayal> jk-: no :(
<tayal> still showing the same error
<jjohansen> tayal: what does uname -r report
<jk-> did the 'update' give you any errors?
 * jk- heads out
<tayal> jjohansen: it gives "2.6.35-23-generic"
<tayal> jk-: it gave an error as "used old files  for the new...."
<jjohansen> tayal: and sudo apt-get update doesn't give any errors?
<tayal> i run it again .. so waiitng to complete
<tayal> command is still not completed.. 
<tayal> jjohansen: jk- : this is teh error "E: Some index files failed to download, they have been ignored, or old ones used instead. "
<tayal> *the
<tayal> jk-, jjohansen : here is the complete commad process "http://paste.ubuntu.com/585277/"
<jjohansen> tayal: I'm not sure why some of those are failing, I'll have a closer look in a bit
<tayal> jjohansen: thanks.. i am waiting... :)
<jjohansen> tayal: are you behind a proxy?
<tayal> jjohansen: no.. 
<tayal> jjohansen: yes actually.. it is set in firefox.. 
<jjohansen> tayal: I meant an apt proxy
<tayal> jjohansen: i am not sure.. 
<tayal> how can i check this?
<jjohansen> if a proxy gets out of sync you can get weird errors like this
<jjohansen> then likely not
<tayal> jjohansen: how can i chech it now? 
<tayal> :(
<jjohansen> tayal: check /etc/apt/apt.conf.d/01apt-cacher-ng-proxy
<tayal> jjohansen: let me check
<jjohansen> its not the only way but the one I know/use
<tayal> jjohansen: there is no file named  "01apt-cacher-ng-proxy" in the directory
<jjohansen> tayal: any other files that mention proxy or cache
<jjohansen> it really doesn't sound like you are using a proxy
<tayal> jjohansen: may be.. i think i am not using any proxy.. 
<tayal> and there is no such file
<tayal> all files are "00trustcdrom  05aptitude      20archive              70debconf 01autoremove  10periodic      20dbus                 99synaptic 01ubuntu      15update-stamp  50unattended-upgrades  99update-notifier "
<tayal> jjohansen: its not able to acess the archive links
<jjohansen> yeah, I am looking and some of these sources don't seem to exist
<jjohansen> did you upgrade your box, and how?
<tayal> jjohansen: yeah
<tayal> i updated things today only using the update manager
<tayal> jjohansen: and the updates dint complted beacuse it wasnt able to acces the archive links
<jjohansen> tayal: hrmm, I would say wait and try again in a bit
<jjohansen> actual try ping in.archive.ubuntu.com
<jjohansen> and host -v in.archive.ubuntu.com
<tayal> jjohansen: ok
<tayal> jjohansen: its pinging "64 bytes from 37.snat-111-91-91.hns.net.in (111.91.91.37): icmp_req=20 ttl=56 time=53.1 ms"
<jjohansen> okay, you are seeing it at least
<tayal> jjohansen: second is also working
<tayal> "host -v in.archive.ubuntu.com"
<jjohansen> my http: requests to it are responding really slow right now
<tayal> yes.. :(
<jjohansen> tayal: you can try sudo apt-get update again but my bet is it will time out again
<tayal> jjohansen: let me try and see :D
<jjohansen> but I will say my first try completely failed so getting anything is an improvement
<tayal> jjohansen: its all ignored and all
<tayal> no connectivity agagin
<tayal> :(
<jjohansen> tayal: okay, well its definitely slow and that might be the problem
<tayal> jjohansen: yes.. then i will try later.. and the backup is also gonna over.. i will ping you if i will hav any problem
<tayal> :)
<jjohansen> tayal: the other option is trying another archive
<tayal> jjohansen: ok.. let me try kubuntu
<jjohansen> eg. I am using us.archive.ubuntu.com
<tayal> ok.. let me try this
 * jjohansen reboots
<tayal> jjohansen: its pinnging  "64 bytes from caryopsis.canonical.com (91.189.92.169): icmp_req=5 ttl=50 time=208 ms "
<jjohansen> tayal: did you change your sources.list
<tayal> jjohansen: no
<tayal> its d same
<jjohansen> tayal: what is pinging caryopsis.canonical.com
<tayal> jjohansen: when i was pinging "us.archive.ubuntu.com"
<tayal> it give this "caryopsis.canonical.com"
<tayal> jjohansen: i am so sorry. but battery is gonna over
<tayal> :(
<tayal> i am sorry
<jjohansen> tayal: ah okay, us.archive.ubuntu.com will cycle through a few different hosts
<tayal> jjohansen: yes.. and this in  imine
<tayal> jjohansen: but i need to leave now :(
<jjohansen> okay, bye
<tayal> thankyou so much.. i will be back 
<tayal> :)
<tayal> bye
<tayal> jjohansen: :)
<DrDetroit> Good morning to all
<amitk> smb`: already know about this? http://pastebin.ubuntu.com/585307/
<amitk> smb`: lucid server here...
<DrDetroit> jjohansen: I think this one is good it ran all night, if you want to prepare a new one before you hit the rack I will dl it
<jjohansen> DrDetroit: okay kicking off the next one
<DrDetroit> gonna be stormy here, I might have to shut down for awhile today if the lightening gets bad
<jjohansen> amitk: no I don't think we knew that one
<amitk> jjohansen: anything I can do to help debug?
<jjohansen> amitk: hehe, well you could find the bug :)
<jjohansen> amitk: I'll take a look at it and see whats up, it shouldn't be hard to track down
<amitk> jjohansen: i found it. /boot is out of space
<jjohansen> ah, well then it might have been hard to track down  :)
<jjohansen> really should give a better message than the when it runs out of space
<jjohansen> DrDetroit: kernel.ubuntu.com/~jj/linux-image-2.6.32-28-generic_2.6.32-28.50~lp740549.f17140_i386.deb
<amitk> jjohansen: it did, earlier in the log (that I didn't look at). update-initramfs failed (http://pastebin.ubuntu.com/585313/)
<jjohansen> amitk: ah so it did :)
<amitk> jjohansen: I had kernel since -14 installed
<DrDetroit> on my way
<jjohansen> ouch
<DrDetroit> rebooting
<DrDetroit> and back
<DrDetroit> JJohansen: back, I know you tend to get some sleep soon so I will see you later on with a report
<DrDetroit> opps
<DrDetroit> jjohansen: back, I know you tend to get some sleep soon so I will see you later on with a report
<jjohansen> DrDetroit: no I'll be around a while yet
<jjohansen> DrDetroit: but let it run for a while :)
<DrDetroit> ok
<DrDetroit> storm's a brewin
<DrDetroit> hehe
<kristian-aalborg> okay jjohansen - let's fire up that baby
<jjohansen> kristian-aalborg: crossing fingers
<kristian-aalborg> interesting... your .deb seems bigger than anything i build
<kristian-aalborg> hurm, not really
<kristian-aalborg> the one I got from make oldconfig is 7 mb... I suppose I could get about that small, then
<jjohansen> kristian-aalborg: its possible I messed up the config
<kristian-aalborg> how?
<kristian-aalborg> confusing it with another one?
<jjohansen> kristian-aalborg: maybe I messed up copying it in, not sure, I'll take a look and see
 * kristian-aalborg reboots
<kristian-aalborg> we'll find out soon ;)
<DrDetroit> jjohansen: ok this is the first mess up I have seen
<kristian-aalborg> jjohansen: hey, it boots!
<DrDetroit> jjohansen: i have tried to start up rythembox to play some music, it shows that it is running, but it does not show up on my desktp
<kristian-aalborg> awesome
<jjohansen> DrDetroit: really, I was starting to worry, lets see what sar, vmstat, latencytop etc say
<DrDetroit> ok
<DrDetroit> root@bashful:~# vmstat
<DrDetroit> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
<DrDetroit>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
<DrDetroit>  2  0  43992  39736  38732 126952    5   13   190    86  343 3269 46  9 40  5
<jjohansen> DrDetroit: can we paste this information into the bug report
<DrDetroit> jjohansen: is that something I have to do?
<DrDetroit> I can't figure out how to copy latencytop 
<jjohansen> DrDetroit: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/740549
<ubot2> Launchpad bug 740549 in linux "Ubuntu 10.04LTS runs slow after kernel updates" [High,Confirmed]
<jjohansen> I am going to put and entry in for which kernel bisect is failing, and then I would like you to put some entries in for output from sar, vmstat, latencytop, and a few others
<DrDetroit> ok except that i cant figure out how to copy paste from latencytop
<jjohansen> DrDetroit: yeah that one is a pain
<jjohansen> DrDetroit: we can try falling back to a screenshot for that one
<DrDetroit> jjohansen: its strange because i did play rythembox in the previous bisect
<DrDetroit> yeah, i can probably do that one
<jjohansen> DrDetroit: well we are bug hunting
<DrDetroit> the results of sar 1-100
<DrDetroit> Average:        all     10.97      0.00      4.04      0.63      0.00     84.36
<DrDetroit> 07:15:21 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
<jjohansen> DrDetroit: can you do copy the output into the bug instead of pasting here
<DrDetroit> sure sorry
<jjohansen> that will help has others can look at it
<DrDetroit> jjohansen: i have top, vmstat, sar 1 100 average, and top there, besides latencytop which i will do a screen capture, is there anything else you want in it 
<jjohansen> DrDetroit: cat /proc/interrupts
<DrDetroit> jjohansen: ok got that...anything else before i do the screen capture?
<DrDetroit> and its still pretty perky, no real mushy feeling, just the program doesnt display
<jjohansen> DrDetroit: iostat -x 1
<jjohansen> DrDetroit: oh its perky, I thought it was showing the slow down :(
<jjohansen> program not displaying could be a different bug
<DrDetroit> its the first time i have ever seen that happen
<jjohansen> right, well lets add a note to the bug about the failure seen here, I don't want to call it a bad bisect if we aren't seeing the slowdown
<jjohansen> but we can still use the information to compare against
<DrDetroit> no problem, anything else before I post?
<DrDetroit> hehe maybe i will try and open other stuff
<DrDetroit> jjohansen: all posted
<jjohansen> DrDetroit: please do
<DrDetroit> jjohansen: after killing the rythmbox pid several times and restarting it, if finally works. all other apps work without problems
<jjohansen> DrDetroit: okay, keep testing this one for a while more then, my guess is that rythmbox failing to start is a different bug
<DrDetroit> nod, i stopped it normally then restarted it and it failed again
<jjohansen> any message in the logs?
<DrDetroit> let me look
<DrDetroit> jjohansen: not sure what I should be looking for, but this is the last entry in messages
<DrDetroit> Mar 25 07:41:07 bashful pulseaudio[1374]: ratelimit.c: 1 events suppressed
<DrDetroit> (END) 
<jjohansen> DrDetroit: I'm not sure what we are looking for either just failures that might be related, and that seems like it could be
<DrDetroit> jjohansen: Mar 25 07:38:48 bashful kernel: [ 5468.553104] __ratelimit: 18 callbacks suppressed
<DrDetroit> Mar 25 07:38:48 bashful kernel: [ 5468.553113] soffice.bin[2252]: segfault at 149f5e9 ip 0149f5e9 sp b3d8b1a0 error 4 in libX11.so.6.3.0[1541000+119000]
<jjohansen> DrDetroit: hrmm, another crash interesting
<DrDetroit> I thought that was when i opened and closed open office word
<DrDetroit> i was testing what would open, they all did except rythmbox
<DrDetroit> jjohansen: thats about all i can see
<DrDetroit> jjohansen: Rythmbox no longer shows up on my desktop as normal, but I have found it sitting as an icon in my top panel
<DrDetroit> if i click on it i can then display it
<jjohansen> it was just "minimized"
<DrDetroit> it starts out up there now
<DrDetroit> let me see if i can get it back to normal
<DrDetroit> sorry 
<DrDetroit> it has never behaved like that before, so i was not looking in the panel
<DrDetroit> ok well
<DrDetroit> jjohansen: i apologize, i have never seen it behave like that
<jjohansen> DrDetroit: np, it happens I've been confused by similar things
<DrDetroit> jjohansen: i guess we should remove my last comments eh?
<DrDetroit> from the bug report?
<Mamontin> Hi all
<Mamontin>  If I have a processor with "SMT (Hyperthreading) scheduler support" do I need to "Multi-core scheduler support" and Symmetric multi-processing support?
<jjohansen> Mamontin: define need.  The answer is no because you can select them separately in the config
<ppisati> bjf: bug 723945
<ubot2> Launchpad bug 723945 in linux "CVE-2010-4258" [Undecided,Fix committed] https://launchpad.net/bugs/723945
<ppisati> bjf: you marked dapper and hardy as "fix committed" but i didn't find the fix there
 * ogasawara back in 20min
<sforshee> cnd, got a sec?
<cnd> sforshee, heh, depends how long that sec is
<sforshee> cnd, I'm having a discussion on lkml trying to determine what key code to send for a funny button on an eeepc convertable netbook/tablet
<sforshee> you know anyone who is a good candidate to make suggestions?
<cnd> well, you could ask dmitry torokhov, the input maintainer
<cnd> peter hutterer is the main X input maintainer too
<cnd> he may be of help
<sforshee> yeah, I was thinking someone on the userspace side who might know better how the keys are actually being used
<cnd> if it's keyboard like keys
<cnd> then daniel stone may know some stuff too
<sforshee> Asus made this button bring up some touch screen interface on short press and rotate the screen on long press
<sforshee> so it's not a normal keyboard button
<sconklin> tgardner: what's the status of the hppa build investigation?
<cnd> sforshee, that sounds odd...
<sforshee> cnd, it is, very odd
<tgardner> sconklin, lamont is creating a new chroot thats only -release/-security. my theory is that something environmental changed since -28 won't even build correctly now.
<sconklin> tgardner: thanks
<tgardner> sconklin, this has been an enormous pain in the ass. you get to fix the next one :)
<sconklin> tgardner: well, I started on this one, and then asked you for a little advice . . . 
<sconklin> ;)
<tgardner> sconklin, yeah well, you probably have better things you should be doing...
<bjf> skaet, is there a clear message of how long lts-backport-maverick will be supported (or any other lts-backport for that matter)
<skaet> bjf,  see my note for the test windows available.    we can figure a schedule based on that.
<sconklin> skaet: sorry I'm not parsing that
<skaet> note I sent to the sru mailing list.  hosting other meeting now
<skaet> sconklin, bjf - will follow up with you in early afternoon.   
 * bjf -> errand
<tgardner> skaet, who approves uploads during the natty freeze? linux-ti-omap4 is stuck in the queue (and doesn't really affect the beta freeze)
<JFo> <- lunch
 * tgardner --> lunch
<aakshay> jjohansen, hey.. :) still apt is not accessing the archives. :(
<jjohansen> aakshay: try a different archive, in.archive seem if you get better ping times
<aakshay> can i try urs ? may give better result :)
<aakshay> jjohansen,  us.archive is givin "64 bytes from prat.canonical.com (91.189.88.45): icmp_req=1 ttl=52 time=248 ms
<aakshay> "
<aakshay> jjohansen,  and here is may apt/sources.list "http://paste.ubuntu.com/585520/"
<jjohansen> aakshay: anything wrong with the ping times you are getting, its better than what I was getting for in.archive
<jjohansen> you will need to update your apt/sources.list  just replace in. with us.
<aakshay> jjohansen, ok in the begibing?
<aakshay> *begining
<aakshay> jjohansen, ok.. changing everywhere
<aakshay> jjohansen, but for "in.archive.." i have ping as "64 bytes from 37.snat-111-91-91.hns.net.in (111.91.91.37): icmp_req=8 ttl=56 time=51.3 ms"
<aakshay> so i think its better than us.archive?
<sconklin> I''m looking at create-release-tracker and neo-create-release-tracker. I only see one change in the git log to create-release-tracker since neo- was split out on Mar 15th
<jjohansen> aakshay: it might be for you but it doesn't seem to be responding, give the us.archive a try, if it doesn't work its easy to change back
<sconklin> That's the addition of qastaging
<aakshay> jjohansen, ok.. let me do this.. :)
<aakshay> jjohansen, its working now!!!!!!... but lets see that no error will generate after apt-get update :)
<fairuz> :D
<aakshay> :)
<fairuz> jjohansen: my setup is working now. thanks to you
<jjohansen> fairuz: nice, I am glad to hear it is working
<fairuz> jjohansen: hey you online until now. Not sleeping?
<aakshay> jjohansen, err.. again showed the same error :(... "E: Some index files failed to download, they have been ignored, or old ones used instead.
<aakshay> "
<jjohansen> fairuz: uhm, no its been a long thursday
<tgardner> sconklin, to whom are you addressing your comments?
<sconklin> tgardner: that was in the wrong window, I'm coming up to speed on some of brad's code
<jjohansen> aakshay: okay, can you paste bin the results
<aakshay> jjohansen, sure.. :(
<sconklin> it was sort of random without any context ;)
<tgardner> sconklin, actually, I kind of understood it after reading your todo list
<sconklin> heh, the wonders of an open process ;)
<aakshay> jjohansen, please check "http://paste.ubuntu.com/585553/"
<aakshay> jjohansen, what you observed now? any error?
<jjohansen> aakshay: sorry haven't gotten to it yet
<aakshay> jjohansen, np... :).. please suggest  me which channel i go to get it corrected?
<jjohansen> aakshay: try #ubuntu
<tgardner> aakshay, lernid-devs doesn't have a maverick repository. there is only karmic and lucid.
<aakshay> jjohansen, thanks :)
<jjohansen> aakshay: oh missed that one, when I was looking at your in.archive failures last night
<aakshay> tgardner, ok.. but i am building maverick kernel in lucid
<aakshay> tgardner, so do i need to add something? or so? basically i  am novice..
<tgardner> aakshay, if you're a novice, then methinks you should learn the fundamentals first.
<aakshay> tgardner, yes.. so for that i am learning to build the kernel. or there is something other i should start with? please suggest
<jjohansen> aakshay: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<tgardner> start simple
<jjohansen> that has all you need, if you follow that you should be able to build a kernel
<jjohansen> get through that first
<fairuz> can't agree more with jjohansen
<aakshay> jjohansen, i am building the kernel using this only.. but stucked at the same command
<aakshay> :(
<aakshay> tgardner, what are the simple things? like?  please suggest
<tgardner> aakshay, as jjohansen suggested, build a kernel, then install it.
<jjohansen> aakshay: remove the lernid tools ppa from your sources
<jjohansen> then sudo apt-get update again
<aakshay> tgardner, ok.. this is  what i am doing.. :D.. but stucked :(
<aakshay> jjohansen, did. but getting the same error.. :(
<aakshay> jjohansen, again got the same error
<aakshay> :(
<fairuz> aakshay: it stucked on what line now?
<jjohansen> aakshay: W: Failed to fetch http://ppa.launchpad.net/lernid-devs/lernid-releases/ubuntu/dists/maverick/main/source/Sources.gz  404  Not Found
<jjohansen> W: Failed to fetch http://ppa.launchpad.net/lernid-devs/lernid-releases/ubuntu/dists/maverick/main/binary-i386/Packages.gz  404  Not Found
<jjohansen> that sure looks like you still are pulling lernid
<aakshay> fairuz, same output "http://paste.ubuntu.com/585553/"
<jjohansen> can you pastebin your /etc/apt/source.list again
<aakshay> jjohansen, yes.. please wait.. :)
<jjohansen> aakshay: add how about running this   grep -l lernid /etc/apt/sources.list.d/*
<aakshay> jjohansen, here is the sources.list "http://paste.ubuntu.com/585573/"
<aakshay> jjohansen, let me run this command 
<aakshay> jjohansen, showed this output "/etc/apt/sources.list.d/lernid-devs-lernid-releases-maverick.list
<aakshay> /etc/apt/sources.list.d/lernid-devs-lernid-releases-maverick.list.save
<aakshay> "
<jjohansen> aakshay: open that file and add a # to the front of any line containing lernid
<jjohansen> that should comment it out, save it and then try apt-get update again
<aakshay> jjohansen, ok.. yes
<aakshay> jjohansen, u r great!!!!... it worked.... o/
<aakshay> thankyou so much
<aakshay> :)
<aakshay> ;)
<aakshay> yiipieee...!!!!! now apt-get update completed with no error
<aakshay> :)
<aakshay> tgardner, fairuz : thankyou so much :)
<jjohansen> aakshay: make sure to do an upgrade again.  either sudo apt-get dist-upgrade, or through the update manager to make sure your packages are in a consistent state
<jjohansen> having a partial upgrade around can be problematic
<aakshay> jjohansen, okay....  :)
<DrDetroit> jjohansen: ready for the next one i think
<jjohansen> DrDetroit: so that one is good
 * tgardner --> beer thirty
<DrDetroit> jjohansen: been running it for 9hrs not problems
<jjohansen> DrDetroit: okay, I'll kick off the next one
<kristian-aalborg> jjohansen: any clue why your version worked and mine did not?
<bryceh> pgraner, I understand you're having some multimonitor woes?
<kristian_> hi again
<kristian_> stupid old box, keeps quitting on me
<bjf> JFo, still around ? was it regression-potential that we were doing away with ?
<JFo> yessir
<JFo> to both
<bjf> thanks
<JFo> we assume a bug naturally has regression potential
<JFo> my pleasure
 * bjf -> break
<DrDetroit> jjohansen: are we done for the weekend?
<jjohansen> DrDetroit: 
<jjohansen> DrDetroit: if you want to be
<DrDetroit> jjohansen: No, I just thought yhou were gone for the weekend, I was waiting on the next one
<jjohansen> otherwise I just need a minute more for your kernel
<DrDetroit> no problem
<DrDetroit> there is no hurry
<DrDetroit> I apologize 
<jjohansen> No not gone, just got distract by other items
<jjohansen> thanks for pinging otherwise I would have forgotten until too late
<DrDetroit> no problem at all i understand perfectly, I fixed a leaky eve and put a new wax ring on my toilet while waiting
<jjohansen> DrDetroit: kernel.ubuntu.com/~jj/linux-image-2.6.32-28-generic_2.6.32-28.50~lp740549.04023f6_i386.deb
<jjohansen> hehe, well I least least you weren't sitting around waiting :)
<DrDetroit> I double checked quite often though
<DrDetroit> just to be sure
<DrDetroit> when I am home, I am not too far from my computers, it'st the only thing I am decent at
<DrDetroit> reboot
<DrDetroit> jjohansen: i have received a number of security updates and other stuff, I figure I should not do those until we are finished with our work. Is that correct?
<jjohansen> DrDetroit: yeah its best not to change what is in your system when hunting for bugs
<DrDetroit> ok will get back to you later on, I assuem that at some point you will be gone for the weekend
#ubuntu-kernel 2011-03-26
<jjohansen> DrDetroit: actually I will be around some at nights over the weekend, when around we can continue
<pgraner> bryceh, yea, I'll file a bug and give you the no via email
<fairuz> morning
<jjohansen> morning
<fairuz> jjohansen: still not sleeping jjohansen? 
<jjohansen> fairuz: never
<jjohansen> actually I had about a 3 hour nap today
<jjohansen> I will sleep tonight, just not yet.
<fairuz> jjohansen: still hunting bugs?
<fairuz> jjohansen: or whatever you do
<jjohansen> fairuz: well I should be but at the moment, I am writing some email, and updating my little arm box
<jjohansen> I don't know that I have any patch work left in me for the day
<DrDetroit> quiet this morning
<jjohansen> DrDetroit: it is indeed
<DrDetroit> hehe
<DrDetroit> just watching the sever thunderstorms
<DrDetroit> when you live in tornado alley, it pays to get up when the noaa radio goes off
<DrDetroit> thinking about putting my shoes on, just in case
<DrDetroit> btw this one seems ok also
<DrDetroit> jjohansen: btw this one seems ok also, if you want to make another one I will try and get it before the storm takes me off line
<jjohansen> DrDetroit: ugh, scary storms, I'll kick off the next one
<jjohansen> DrDetroit: kernel.ubuntu.com/~jj/linux-image-2.6.32-28-generic_2.6.32-28.56~lp740549.21697d_i386.deb
<DrDetroit> jjohansen: on my way
<DrDetroit> jjohansen: am gonna head over to walmart, will install this once I get back
<DrDetroit> rebooting
<Specialist> i'm having some difficulties with git bisect to identify the kernel change that introduced suspend freezes for my pc
<Specialist> i told git bisect that the last working version was v2.6.35
<Specialist> and a known buggy version v2.6.36
<Specialist> now, git bisect ended up pointing out some changes in 2.6.35-rc5+ as the culprit, which does not make any sense (as it is older than 2.6.35)
<Specialist> the complete bisect log is available at: https://bugzilla.kernel.org/show_bug.cgi?id=31562
<ubot2> bugzilla.kernel.org bug 31562 in Hibernation/Suspend "Suspend to RAM (S3) sporadically hangs" [Normal,Reopened]
<Specialist> any ideas why this may have happened?
<kristian-aalborg> jjohansen: http://pastebin.com/ihmpZFvD <-- diff between the kernel you built and the one I'm running
<jjohansen> kristian-aalborg: ? I was sure I used the config you gave me.  I didn't make an changes to it
<jjohansen> kristian-aalborg: give me the exact config and I will rebuild with it
<kristian-aalborg> to clarify, I have two configs in /boot
<kristian-aalborg> I guess these are things that happened to the kernel in the meantime?
<jjohansen> kristian-aalborg: quite likely, give me the config you want and I'll run through it again, it is possible those items are being set as the defaults
<kristian-aalborg> http://pastebin.com/pQM4JQYh
<kristian-aalborg> I think it's the same ones I got with the git version
<jjohansen> kristian-aalborg: so rebuilt and yes it looks like those config items are being set
<kristian-aalborg> yup
<kristian-aalborg> what's the md5sum?
<jjohansen> kristian-aalborg: of the dpk?
<jjohansen> kristian-aalborg: 005bb40d9ce3f0291ffc3ff40791c076
<jjohansen> I just rebuilt it
<kristian-aalborg> hurm
<kristian-aalborg> the one I installed ended in b39
<jjohansen> kristian-aalborg: hrmm, well it is possible there are changes
<kristian-aalborg> it's more than likely
<kristian-aalborg> you can't do much to a file and have the same md5sum ;)
<jjohansen> well I reeditted the changelog for the name, and it was built from a new checkout so, its likely there were a few bug fixes added.  Sorry I didn't keep the commit hash for the orther tree I built
<DrDetroit> jjohansen: I have run this one for about 8hrs with no problems
<DrDetroit> well pooh, my vsftpd doesnt work with these test kernels
<kristian-aalborg> jjohansen: let's look into this tommorow or so
<kristian-aalborg> *tomorrow
<jjohansen> DrDetroit: weird, it should
<jjohansen> kristian-aalborg: sounds good, tomorrow then
<jjohansen> DrDetroit: I will make you a new kernel but it will be an hour or two
<kristian-aalborg> no promises - this is wearing me out ;)
<kristian-aalborg> I'll just try to catch you when I feel like giving it a go :)
<jjohansen> kristian-aalborg: sure, that makes sense
<DrDetroit> jjohabsen: no problem, just trying to figure out firewalls on ubuntu server 10.04
<DrDetroit> jjohansen: no problem, just trying to figure out firewalls on ubuntu server 10.04
#ubuntu-kernel 2011-03-27
<jjohansen> DrDetroit: so we don't have a kernel.  Once again the final commit that bisect returns is a house keeping commit that just patches the changelog
<DrDetroit> ok
<DrDetroit> jjohansen: i think my game plan should now be to return to the 30 kernel since we have not found anything yet
<jjohansen> it should be -28 kernel again, I am going to build and have you test with it
<DrDetroit> ;ok
<DrDetroit> jjohansen: ok, i was going to try and duplicate the issue in the 30 kernel and then file a bug report on it
<jjohansen> DrDetroit: sure return to 30 and see if how it behavies
<jjohansen> right
<jjohansen> give 30 a shot first
<DrDetroit> that will save you time in having to do this stuff for me and get no results
<DrDetroit> i dont like seeing  you waste your time on me
 * jjohansen is not sure why we can't seem to find this with bisecting
<DrDetroit> i do appreciate the awesome help
<jjohansen> DrDetroit: heh, I don't consider bug hunting a waste of time
<DrDetroit> if i do duplicate it, and file a report, can you delete my old report so we dont have two there
<jjohansen> DrDetroit: well I can mark it invalid or link the two
<DrDetroit> jjohansen: well, I have watched you work you butt off here this past week, I think I will do this tomorrow. I think you should take the rest of the weekend off
<DrDetroit> jjohansen: even superman slept
<jjohansen> DrDetroit: oh I have slept, I just give the impression of not sleeping, most of my sleep gets broken up into naps
<jjohansen> so instead of sleeping for the night, its a couple hour nap here and there
<DrDetroit> ;oh
<jjohansen> but yeah last week was a long week
<DrDetroit> i worked like that 24x7 for 7 years...finally couldn't do it anymore
<DrDetroit> i will do the 30 thing later on tonite and tomorrow and will keep you informed. I will hang out here. I have learned a lot working with y ou
<jjohansen> yeah, it can wear you down if you are doing it all the time
<jjohansen> alright, looking forward to hearing how it works out for you
<DrDetroit> thank  you
<DrDetroit> i might even try compiling my own kernel (on a test machine)
<jjohansen> hehe, its np, and you are welcome :)
<jjohansen> and compiling your own kernel sounds like a great idea.  Do you want the link to the how to
<DrDetroit> i have been trying to get ubuntu server up and running properly while doing this
<DrDetroit> sure
<jjohansen> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<jjohansen> with a larger set of howtos/info https://wiki.ubuntu.com/Kernel/Dev
<DrDetroit> thanks got them bookmarked
<DrDetroit> looks interesting
<fairuz> DrDetroit:so will try to compile a kernel then?
<DrDetroit> fairuz: probably will do it as a learning experience. I toasted a hd the other day running debian so I will probably try it when i rebuild the machine
<jjohansen> DrDetroit: so 30 seems to be working for you
<DrDetroit> jjohansen: havent rebooted yet, fell asleep
<DrDetroit> I will do that now since I am awake
<jjohansen> ah, okay.  Figured I'd ask
<DrDetroit> rebooting
<DrDetroit> ok will see how this goes now
<DrDetroit> ;jjohansen: ok on the 30 kernel, I still get the update manager with updates, plus it wants to update my 29 kernel
<DrDetroit> which we already bisected
<jjohansen> yeah, well we may have to go through that again, we either missed something or its a heisenbug or some such
<DrDetroit> do  you think i should wait on the updates then?
<DrDetroit> we didnt let the 29 run as long as the 28 tests
<DrDetroit> anways, I will wait on those updates
<jjohansen> DrDetroit: hrmm well I don't know at this point it may be worth just doing the update, as if we bisect its going to have to cross through stuff we did last time
<jjohansen> so its probably worth having the most up to date stuff at this point
<DrDetroit> ok
<DrDetroit> will start the update manager again
<DrDetroit> jjohansen: 1725 root      30  10 84464  66m 4684 R 84.8 15.2   0:55.37 update-apt-xapi          
<DrDetroit> this was still running after I shut down update manager
<DrDetroit> ok it stopped 
#ubuntu-kernel 2012-03-19
 * smb Rebooting
<ppisati> pulseaudio refuses to collaborate this morning
<ppisati> or maybe is mumble
 * smb hates these "experienced and internal problem" messages. So not saying anything
<ppisati> uh
<ppisati> and i hatre my usb mic not working
<smb> ppisati, Do you have levels in the sound indicator?
<ppisati> smb: levels?
<smb> ppisati, Some movement on the level-meter
<smb> if you go to input and your mic
<ppisati> if i raise the sensitivity, yes
<ppisati> it's alive
<smb> Ok, so its either tuned too low or mumble needs the restart, killpulse, twidle setting dance we all love so much
<ppisati> cool
<ppisati> just killed pulseaudio
<ppisati> and now i've lost sound for every app
<ppisati> and i can't even close skype
<ppisati> it's stuck in a limbo
<smb> ppisati, sounds like another reboot another lucky draw
 * ppisati -> back in 10mins
 * ppisati scratches his head
<ppisati> perf is part of linux-base and linux-tools-common
<Daviey> smb: Hey, are you around?
<Daviey> smb: I'd like to raise bug 898127 as crucial, it seems to be present just by showing extreme IO.
<ubot2`> Launchpad bug 898127 in linux "system hangs and errors at /build/buildd/linux-3.2.0/arch/x86/kernel/apic/ipi.c:113 default_send_IPI_mask_logical+0xdc/0xf0()" [Medium,Confirmed] https://launchpad.net/bugs/898127
<Daviey> I believe it's that bug anyway...
<Daviey> I believe i can get you access to hardware where you can see it.
<apw> Daviey, i think you just missed him popping to lunch
<Daviey> apw: Oh :(
<apw> ppisati, yeah linux-base is on my todo for today to sort that out, its a debian sync
<ppisati> apw: well, actually there's even a skew between kernel version and perf version
<ppisati> apw: dunno if it's the same
<ppisati> apw: http://paste.ubuntu.com/890466/\
<ppisati> and 'perf top' shows nothing
<apw> ppisati, where did you get your 1409 build ?
<ppisati> apw: ti-omap4, latest kernel
<apw> built where
<ppisati> got it from dist-upgrade
<apw> armel or hf ?
<ppisati> armhf
<apw> dpkg -S /usr/bin/perf says what
<ppisati> linux-tools-common
<ppisati> flag@panda:~$ dpkg -S /usr/bin/perf
<ppisati> linux-tools-common: /usr/bin/perf
<apw> ppisati, try installing linux-tools instead
<ppisati> it's there iirc
<apw> linux-ti-omap4-tools-3.2.0-1409
<ppisati> ah
<ppisati> uhm
<apw> is the binary package, but i'd expect the linux-tools to bring it in
<ppisati> nope
<ppisati> linux-tools brought in linux-tools-3.2.0-19
<ppisati> let me double check
<apw> oh hmmm ... yeah
<apw> maybe there isn't a linux-tools for ti-omap4
<apw> it would have to have a different name anyhow
<ppisati> k
 * ppisati goes researching the solution
<apw> actually isn't there a linux-tools-omap4 or something
<apw> i remmber us having to have a differnet name, and realising we should have had a flavour specific tools name even though it would have been a noop on x86
<apw> as if you have multiple source packages the linux-tools have to differ in name
<ppisati> so, linux-tools tries to install linux-tools-3.2.0-19
<apw> yep, thats x86 or 'from master' speciific
<ppisati> ah
<ppisati> linux-tools-omap4
<apw> is there a linux-tools-omap4, thats the right one
<apw> and there is a 'bug' that we don't have linux-tools-generic etc to match it
<ppisati> anyway, linux-tools-omap4 imported the right one: linux-ti-omap4-tools-3.2.0-1409
<apw> ok good... will add to my todo to look at that
<ppisati> but perf still doesn't work
<ppisati> nice
<ppisati> i've a new toy
<ppisati> thanks
<apw> heh whats it do
<ppisati> nothing
<ppisati> PerfTop:       0 irqs/sec  kernel:-nan%  exact:  nan% [1000Hz cycles],  (all, 2 CPUs)
<ppisati> mute
<ppisati> silent
<apw> hrm, thats a worry, config perhaps ?
<ppisati> probably
<ppisati> i'm over it
 * ppisati -> out for lunch
<apw> smb, i've talked to Daviey about his issue, its actually a different bug
<smb> apw, Hm, a different bug than what? (/me back now)
<apw> the one daivy was making you look at
<Daviey> Yes, sorry - i suck.
<smb> Ah ok, so anything I still should look at or are we waiting for him to file information
<gema> hi guys, couldn't find this in the normal debug symbols apt source: linux-image-3.2.0-17-generic-dbgsym , could someone help there? 
<apw> gema, may have expired as that is an old kernel
 * smb wonders whether the bug he was referring to is offlining cpus as of poewnap
<gema> apw: it is the beta1 kernel
<apw> yes that was the one he was referring to, but the machine is ooming
<smb> otherwise ddebs.archive.ubuntu.com I think
<apw> gema, yep but we have -19 in the archive now
<apw> so if -17 was >14 days ago then it may have gone
<smb> apw, or was it just ddebs.ubuntu.com
<smb> Its a pita that any variation exists but some are not good
<gema> apw: so you recommend updating ? the problem appeared when rebooting after an alternate install on a production machine, we cannot really afford to reinstall to reproduce.. :/
<apw> i'd not recommend running a production box on beta1 thats for sure, we're nearly a month on from there
<gema> apw: I know, I convinced my other half to use beta 1 for his purposes, because it does what he needs, and we bumped on 3 defects during the install/reboot
<gema> apw: so we are trying to raise the kernel one, but without the symbols we only have a picture of the crash
<apw> gema, so if you can let me see the picture i might recognise it
<apw> not sure i would ever install an old snap of precise tho. given we make CD daily
<gema> apw: our daily images are not half as tested as beta 1
<gema> apw: take my word on that one
<apw> i was under the impression our testing was daily and automated, but hey
<apw> but as all the machines i care about are running the crap in the archive right now, and seem good, that'd be my recommendation if you are using P
<apw> otherwise i'd say O or L was a better plan
<gema> apw: ack
<gema> apw: there is a lot of manual and varied community hw testing that happens during Beta
<gema> that doesn't happen daily
<gema> nor automated
<gema> we are on a road there, but not there yet
<gema> apw: sent you that email
<apw> gema, so this is an EFI machine ?
<gema> aye
<gema> apw: fwiw, grub was screwed when we tried to reboot, that's another of the problems
<smb> apw, we can hear you
<apw> gema, ok this is looking like an EFI triggered bug, is this machine an EFI bios?
<apw> if it is we might not expect L to work either on it, but O probabally can, we think
<gema> apw: it is an EFI but it emulates the normal bios behaviour
<gema> apw: the machine is quite happy after that reboot 
<apw> hmmm for those efi routines to be being used, that implies its in EFI mode i think ... cking <<
<cking> yep definitely in EFI
<gema> apw: by L you mean P ? 
<apw> gema, no i mean L, if tis an EFI mode bios then it probabally won't run L in native EFI mode
<apw> and i suspect its in that mode from the panic
<gema> apw: not sure what the kernel was using at that particular moment, but the normal bios behaviour was there too, as the machine runs DragonFly with no problems, and that wouldn't happen if it was in EFI mode
<mjg59> Most EFI systems will EFI boot if the media supports it, and fall back to BIOS automatically if it doesn't
<mjg59> The Ubuntu install media includes EFI support
<mjg59> So if you tried to boot Dragonfly it'd fall back to BIOS, but if you tried to boot Ubuntu it'd be in EFI
<gema> mjg59: ack, understood
<cking> gema, efI_pstore_write() is failing for you - but w/o seeing the top of the oops it's impossible to say way efi_call5() fails
<gema> cking: ack, alex is willing to debug it if he finds / can get the debug symbols
<cking> gema, yep, with a bug filed please 
<gema> cking: not a problem, can you get us the symbols for beta1 kernel?
<cking> gema, I will build you one
<gema> cking: thanks a million
<tgardner> cking, can you change to tangerine? gomeisa is getting relocated.
<cking> tgardner, ack
<tgardner> ogasawara, gomeisa will be down for a bit for relocation
<ogasawara> tgardner: ack
<ogasawara> tgardner: where's it relocating to?
<tgardner> ogasawara, new rack and network switch (I think)
<tgardner> tangerine will follow in a bit
<gema> cking: tracking this problem on Bug #959286 
<ubot2`> Launchpad bug 959286 in linux "EFI related kernel panic on reboot from alternate installer " [Undecided,New] https://launchpad.net/bugs/959286
<gema> cking: bwalex will be adding his findings there
<cking> gema, thanks
<apw> cking, how long will your build be ... on tang
<cking> apw, which one, I'm futzing around doing several
<apw> cking, how long will you be using tangerine, we want to take ti down for its move, gome is back
<cking> I'll log off now
<cking> done
<smb> apw, 
<smb> apw, I am using tangerine right now, too
<cking> apw, how long will it be offline for?
<apw> cking, about as long as gomeisa i assume, 10s of minutes
<apw> smb, how long :)
<smb> apw, till now
<smb> :)
 * smb got his kernels off
<apw> everyone happy ?
<apw> smb, cking, got waht you need off her
<cking> apw, I was going to pull off a .ddeb, so it's going to take an insane length of time, so just go ahead
<smb> apw, I am good
<apw> cking, it is
<apw> cking, remember you can scp it to zinc
<tgardner> cking, or even gomeisa
 * ogasawara back in 20
<cking> ok - done
<henrix> diwic, Sarvatt: ping
<diwic> henrix, hi
<henrix> diwic: hi! would you be able to help me with bug #956479 ?
<ubot2`> Launchpad bug 956479 in linux "no analog audio output after HDMI display standby with kernel 3.0.0-17.30" [Medium,Confirmed] https://launchpad.net/bugs/956479
<henrix> diwic: it looks like a regression
<henrix> diwic: could you please take a look at it, before i ping lkml (and others)?
<diwic> henrix, so the issue is just that hdmi becomes auto-selected when it previously wasn't, not that anything stops working permanently?
<mdeslaur> cking: are you aware of bug 952556? could it be related to the power savings work you've done?
<ubot2`> Launchpad bug 952556 in ubuntu-meta "[Precise] [Hardware-killer] HD restarts every few seconds" [High,Confirmed] https://launchpad.net/bugs/952556
<cking> mdeslaur, lemme look
<henrix> diwic: yes, that was my understanding. everything seems to work fine
<mdeslaur> cking: could you hand that off to someone appropriate if you're not the right person...the bug does look important
<henrix> diwic: i reverted one of the patches that came from stable, and the problem seems to be solved
<diwic> henrix, so the issue is probably that from the audio driver, it looks like the monitor was unplugged and replugged
<diwic> henrix, and in fact, today I'm working on not switching to HDMI for 12.04
<henrix> diwic: ok, so you believe the issue is at the audio driver
<diwic> henrix, so it should hopefully be resolved for 12.04. Anyway, to confirm this theory, you can try commenting out "load-module module-switch-on-port-available" in /etc/pulse/default.pa
<diwic> henrix, naah, it's probably in the video driver, it shouldn't tell us the monitor is not connected I guess, but at the same time, that's not easy to know
<henrix> diwic: hmm... ok, i can ask the reporter to try to comment that and see what we get
<diwic> henrix, aha, I thought you were the reporter, sorry
<henrix> diwic: ah, no. sorry, should have made that clear :)
<henrix> diwic: thanks for you hints. i'll try to investigate this a little bit more
<diwic> henrix, well, so this seems to have made it into 3.3
<diwic> so this commit is not in precise, correct?
<henrix> diwic: i haven't check that, but it should be
<henrix> diwic: it is reported against oneiric
<bjf> henrix, diwic, yes, that commit is in precise
<diwic> bjf, thanks
<henrix> yeah, it just. just checked as well
<diwic> henrix, so I care mostly about 12.04, in which case this would be resolved by the Pulseaudio patch I'm writing today
<diwic> henrix, for 11.10; well, dunno if it's causing a lot of problems, revert it
<henrix> diwic: well, not sure about reverting it. we would need to know what problems it would cause
<diwic> henrix, as for reporting bugs upstream; it could be worth having the discussion I guess, but it might backfire on us loading the module-switch-on-port-available in the first place
<diwic> henrix, which is related to the jack detection stuff I've been doing.
<henrix> diwic: ah, ok.
<henrix> diwic: would that pulse patch be backported into oneiric?
<henrix> diwic: or there are no plans for that?
<diwic> henrix, so question is if this actually a bug fix or rather a change in behaviour
<cking> mdeslaur, thanks for the heads-up on that bug, I'm on to it right now
<mdeslaur> cking: cool, thanks!
<henrix> diwic: yeah, i understand what you mean
<diwic> henrix, I'm not currently planning to backport it, but I don't know...I'm okay with backporting it myself if there is demand for it.
<diwic> henrix, but that PulseAudio change is also a change in behaviour more than a bug fix
<henrix> henrix: ack
<diwic> henrix, maybe I should ask Wu about what this patch actually resolves?
<henrix> diwic: that patch came in from upstream stable. i would need to spend some time looking at the stack in order to actually understand the changes introduced
<diwic> henrix, I tend to like the patch.
<diwic> henrix, at least judging from the commit text.
<henrix> diwic: well, yeah... but i am unable to measure the consequences just looking at it :)
<diwic> henrix, it's just a little stupid that we can't tell the difference between a monitor being plugged in, and being returned from standby.
<henrix> diwic: so, you already helped me a lot by explaining that this is more a change in the behaviour
<henrix> diwic: so, i'll take a better look at the whole thing and try to have some conclusion about all this
<diwic> henrix, ok
<henrix> diwic: and thanks!
<dholbach> hiya
<dholbach> can anyone reply to https://twitter.com/#!/MttCastelli/statuses/181737540187987968 maybe?
<tgardner> dholbach, besides the fact that he's running a 3.3 kernel (Precise is 3.2), the Nvidia DKMS driver is owned by OEM.
<dholbach> sure, I wasn't trying to make this your problem - just wondering if anyone had a reply for the guy
<tgardner> dholbach, I don't think any of us tweet
<tgardner> dholbach, feel free to paraphrase my response
<dholbach> I'll see if I can find anyone at OEM who knows what's going on - thanks
<tgardner> dholbach, contact tseliot
<dholbach> yep
<dholbach> according to http://www.nvnews.net/vbulletin/showthread.php?p=2536982 "This issue got fixed and available in next 295 driver."
<dholbach> I'll mention that to Alberto too
<apw> dholbach, mainline kernels are not even supported, plus there is a known issue that binary modules do not work with them ...
<Sarvatt> dholbach: it's not compatible with the 3.3 kernels yet, its a really common occurance. the next update we do in precise should be :)
 * cking --> in deep thought mode
<brendand> bjf, bryceh - we have one certification system that can't start x with the new -proposed kernel
<bjf> brendand: what's the bug # ?
<brendand> bjf, bryceh - the tester is telling me that it seems not be related to the kernel itself entirely though
<brendand> bjf - being raised right now, i'll get you it asap
<brendand> bjf, bryceh - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/959494
<ubot2`> Launchpad bug 959494 in xorg "[HP Probook 6550b] Fails to start graphical environment" [Undecided,New]
<brendand> bjf, but booting with the -updates kernel also doesn't work
<bjf> brendand: well, unfortunately, that makes it _not_ a regression (at least not a regression for this kernel)
<brendand> is this an argument for including other packages in the kernel SRU cadence?
<brendand> like x for example?
<bjf> brendand, i don't think so. i think it's a case for better regression testing of other packages.
<brendand> bjf - that's sort of what i was trying to say, maybe they don't need to follow the same cadence, but the same process
<bjf> brendand, yes, i agree that other packages should follow a similar process
<bryceh> brendand, how has he determined it not to be related to the kernel?
<bryceh> brendand, if it's an X issue we'll have to see the Xorg.0.log
<brendand> bryceh, by booting into the -updates kernel. isn't that good enough?
<brendand> bryceh, it's just an intel chipset too so i'm wondering what other packages could be involved in the regression
<bryceh> brendand, very little has changed in X on lucid, so I was just asking if he had any better evidence
<brendand> bryceh, yeah. i always remember you telling me that
<bryceh> brendand, typically this class of issue is most commonly caused by an error in the xorg.conf, but can also happen if an X driver got uninstalled, or was broken for some reason
<brendand> bryceh, well - we have a very strictly controlled install process so user error is unlikely to occur
<apw> bryceh, yo ... did you manage to do any further testing on that edid patch?  i'd want to be commiting things like that right after beta if we're going to have it, as kernel freeze is RSN
<bryceh> in any case, generally an error will get written to Xorg.0.log or gdm.log in this type of failure.
<brendand> bryceh, so perhaps one of those things happened, but it would most likely have been one of the updates that did it
<brendand> bryceh, so far we:
<brendand> installed (PxE)
<bjf> brendand: we need the log files
<bryceh> apw, heya, yep top of the todo list
<bjf> brendand: that bryceh has asked for
<bryceh> apw, last week was a bit crazy with people needing stuff looked into
<apw> bryceh, ahh cool ... /me wonders if that needs any shining ... i should look
<apw> bryceh, they are like that people, always wanting things ... good job i am a robot instead
<bryceh> apw, I should turn robot too!
<bryceh> brendand, also the dpkg.log might be useful in tracking down which packages had gotten updates.  Surprised that isn't already included in your apport hook.
<brendand> bjf, i know you do - he's just stepped out for lunch though
<bjf> brendand: ok, i think further discussion can wait until we see the log
<tgardner> ogasawara, I have 3.2.12 prepped. shall I push it ?
<ogasawara> tgardner: yes please
<tgardner> ogasawara, still doing build tests, but I think it'll be OK. pushed...
<tgardner> or rather, pushing....
<ogasawara> tgardner: is it an ABI bumper?
<ogasawara> tgardner: we could squeeze in an upload before beta-2 freeze this thurs
<tgardner> ogasawara, dunno yet
<tgardner> ogasawara, gimme 10 mins
<apw> tgardner, ogasawara, infinity has confirmed that a UP build of the same commit as your last upload boots ok, the smp only powerpc build does not on his H/W
<apw> smb, do your menus appear ok now, or do you still get the partial versions ?
<apw> smb, as that bug got closed fixed, adn i can't recall when i last noticed them
<ogasawara> apw: hrm, so that would contradict our beliefs that smp should work on non-smp hw
<smb> apw, No, that seemed to have been fixed around when they closed it
<apw> ogasawara, for one machine at least yes
<apw> not sure if that warrent backing it out for beta and some more investigation
<apw> there is almost no obvious difference between the configs for the two other than the CPU count
<ogasawara> apw: I'd lean towards backing it out until we find a fix.  tgardner thoughts?
<tgardner> ogasawara, nak from me. lets find out if there is more then 1 machine like it left in the world. I'm tired of supporting antiques.
<tgardner> ogasawara, no ABI bump on amd64
<ogasawara> tgardner: ack, I'll prep an upload
<ogasawara> tgardner: tgardner: for powerpc, I'll ship with non-smp removed for Beta-2 to see if we can flush out any other broken systems.  but I think if we can't find a solution for infinity and others (if any), we may have to reinstate it based on the same argument against dropping generic i386.  We'll give them at least another 5yrs with the LTS, but drop it in Q.
<tgardner> ogasawara, you're gonna make me cry.
<tgardner> ogasawara, back in a sec. I'm boot testing 3.2.12
 * henrix will be out for ~20 mins
<ogasawara> tgardner-lunch: I have an idea baking to make both parties happy for powerpc, mumble when you get back
<jjohansen> ogasawara: when is the last kernel upload?
<ogasawara> jjohansen: I'll probably squeeze one in today, but then that will be it until after Beta-2 (assuming no kitten killers)
<ogasawara> jjohansen: we'll probably be able to squeeze in 1 or 2 more uploads in between Beta-2 and Kernel Freeze (Thurs Apr 5)
<jjohansen> ogasawara: okay, /me doesn't have anything that would affect todays upload
<jjohansen> ogasawara: thanks. I will work on getting a rebase request based on the 3.4 version of apparmor together for you post Beta-2
<ogasawara> jjohansen: cool, if I could ask you try to get them to us before the end of March, that would be ideal.  As I hope to upload our final kernel Mon Apr 2.
<jjohansen> ogasawara: yep that should work, just have to wait for linus to suck in the security-next tree
<ogasawara> jjohansen: ack
 * apw goes for supplies ...
<SaveTheRb0tz> Hi. I've just noticed that I can't build 3.2 precise kernel in lucid chroot without porting new dpkg >= 1.16.0 and dpkg-dev (for new dpkg-architecture -qDEB_HOST_MULTIARCH).. Is there some workarounds or fixes planned?
 * apw goes fine beer
<tgardner> SaveTheRb0tz, we've not put any effort into supporting that configuration. build in a Preicse schroot, or on a Precise host.
<apw> SaveTheRb0tz, i am supprised they don't build ... we build mainline builds in lucid chroots with precise packaging
 * ogasawara lunch
 * tgardner -> EOD
 * cking --> EOD too
<cking> :-( my ThinkPad is dead
<vanhoof> cking: the x220?
<cking> yep
<cking> did "reset BIOS settings to default, F10 save", reboot, completely bricked
<cking> uttter pants
<vanhoof> cking: :\
<vanhoof> cking: under a year old?
 * vanhoof assumes so
<vanhoof> they came out about this time last year
<vanhoof> they were really easy to work w/ when my lcd went bad
<vanhoof> fixed it in ~3 days
<cking> vanhoof, yep, 3 months old
<cking> if that
<cking> tomorrow's problem
<SaveTheRb0tz> apw: from my little research lucid's dpkg doesn't know anything about multiarch... So it's pretty strange that you somehow got it built on lucid.
<bryceh> apw, the edid write thing tests out well on my hardware.  is there a chance of it being included in precise?
 * cking gives up for the day
<infinity> ogasawara: That was the most formal email anyone has ever written to me when our previous conversation involved discussing *censored* and *censored* over beer. :P
<mjg59> infinity: There's something about you that encourages people to treat you like a gentleman
<infinity> mjg59: Everyone but you?
<pbuckley> lol
#ubuntu-kernel 2012-03-20
<tupi> hello kernel experts
<tupi> running debian on HP all-in-one omni 200 PC, had problem and it has been identified and apparently solved, but i can't find that the solution has been integrated in debian yet
<tupi> here is the link i am refering to: https://bugs.freedesktop.org/attachment.cgi?id=56796
<tupi> actually this link probably informs better: https://bugs.freedesktop.org/show_bug.cgi?id=43171
<ubot2`> Freedesktop bug 43171 in DRM/Intel "[ILK] LVDS attached to !mobile left unlit" [Normal,Resolved: fixed]
<tupi> well, i have just tried and downloaded the source of even the experimental 3.3 kernel [debian] and the solution is still not included
<tupi> i have just tried and downloaded the source of even the experimental 3.3 kernel [debian] and the solution is still not included
<tupi> the guy [Daniel Wolff] said he created debs packages, but i can't access the repository
<tupi> probably was temporary ...: http://www.rapido.net.br/debs_hpomni200/
<tupi> anyway, any one has an idea how I could try to solve my problem ? 
<psusi> where does update-initramfs -u get its idea of what kernel version to update?  it keeps trying to update for 3.2.0-rc3+, which I no longer have installed
<psusi> ( nor am currently running )
<infinity> psusi: /var/lib/initramfs-tools/
<dupondje> Weird, every time on startup my wifi is disabled by rfkill: [   26.182093] iwlwifi 0000:03:00.0: RF_KILL bit toggled to disable radio.
<dupondje> is that a bug in Precise ? :s
<apw> yay ... 140 updates
<smb> apw, And it seems still working. :)
<apw> they only just started installing so we shall see
<smb> apw, Already booted into it
<apw> smb ahh ok :)
<apw> libreoffice is a huge pig
<apw> smb, remind me to remove virtualbox too .. its rebuilding for every one of my 20 installed kerneles
<apw> smb, and to remove all the 'spare' kernels i have
<smb> apw, Maybe removing some of those 20 may be a good idea too
<smb> apw, agree
<smb> apw, You wanna my script
<apw> smb, /me wanna your script
<smb> apw, will be on chinstrap in a sec
<apw> ta
<smb> cleanup-kernels
<smb> apw, Its written in a way to emmit command line to be piped into another shell
<apw> smb, heh thats what i was about to change it to do, until i discovered thats what it did :)
<smb> apw, I like to verify its sanity each time i run it
<apw> Traceback (most recent call last):
<apw>   File "/home/apw/brief/bin/cleanup-kernels", line 67, in <module>
<apw>     kernel_list.sort(cmp=cmp_kver)
<apw>   File "/home/apw/brief/bin/cleanup-kernels", line 52, in cmp_kver
<apw>     if int(v1[n]) < int(v2[n]):
<apw> IndexError: list index out of range
<smb> apw, O dear, could be one version that worked for now... I think I had fixed that somewhere
 * apw debugs
<smb> apw, Think it was just some specail kernel 
<smb> like -pae
<smb> which tends to mess up the logic to decide which is version
<apw> ['3', '0', '0']
<apw> possibly that one
<smb> would look ok for a version...
<apw> smb, all the others are 4 digits
<apw> ['3', '0', '0', '15']
<smb> ah ok
<smb> you have -pae there?
<apw> smb, no, though i can also see that this would get that wrong too
<apw> un  linux-image-3.0                                       <none>                                                (no description available)
<apw> i think its that one
<smb> apw, weird cause it starts by looking at vmlinux-* in /boot
<apw> a test kernel way back when we were testing the different lengths for the name
<apw> vmlinuz-3.0-0-generic
<apw> an invalid package in the real scheme
<smb> hm, hows a vmlinux file there when the package is un installed?
<apw> who can say with dpkg
<smb> ok, yeah and with the vmlinux file being different/wrong... bah
<apw> smb, i can purge that one anyhow
<smb> apw, Right, I bet dpkg -S will fail to find its source too
<apw> smb, un is unpacked no errors ... and i can't purge it either
 * smb tries to hide
<apw> smb, actually no its, unknown not
<apw> which is even less helpful
<smb> ahm, yes
<smb> dpkg --forget
<smb> (not that that exyists)
<apw> ok time to reboot and see if i make it
<brendand> i've a system that has 8Gb of RAM installed (2x2GB + 1 4GB) and it's running -pae, but only 4GB are showing in MemTotal
<brendand> this is on Oneiric
 * cking --> on the phone with Lenovo :-/
<cking> hoping his x220i will be fixed someday 
<brendand> could this be a kernel issue or should i look for something else first? dmidecode shows all the memory
<brendand> the CPU is an i5
<cking> brendand, is this new kit, or has it just started failing?
<brendand> cking - well, we've only just introduced a test to actually check this so it's hard to tell. the system is just over a year old
<brendand> cking - is there something in dmidecode that could indicate a cell is 'unusable' or suchlike?
<brendand> cking, i see what this is now. it's a test script deficiency (obviously)
<brendand> cking, the 4GB 'Memory' device is a ROM chip
<brendand> cking, i guess the script should only look for 'SIMM' and 'DIMM' form factor devices...
<cking> brendand, you are trusting DMI data to be correct?!
<brendand> cking, i wouldn't say 'trust'
<brendand> cking, i am of course treating all these 'problems' with a large pinch of suspicion
<cking> ;-)  Well, for memory layout maybe /sys/firmware/memmap is more helpful
<brendand> cking, how to parse that though?
<cking> brendand, http://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
<brendand> cking, and that's more accurate than meminfo, or dmi? (i.e. which one would it replace?)
<cking> what's meminfo?
<cking> brendand, it depends on what you want to test, do you believe what the firmware is telling you (e.g. BIOS e820 memory info) or DMI tables (which could be lying) or both, or the kernel got it wrong
<brendand> cking, i would believe that at the very least dmi is not fabricating non-existent memory chips 
 * brendand please god let that assumption be true!
<cking> brendand, cking's first rule of computing: assuming nothing
<cking> oops, I meant: "assume nothing"
 * brendand 's first rule of testing "trust but verify"
<cking> brendand, that's where you're going wrong, trust nothing, it's always broken or lies to you
<brendand> cking, we'd never get any testing done then :)
<brendand> cking, what i'm saying is that i know there's a potential for false positives here , but we can try and iron out most of them and deal with the cases where we're being flat out lied to individually
<brendand> it's no good to just say 'i refuse to test this because the data i have could be unreliable'
<brendand> cking, on to another case. i also have a system which has a single 2GB DIMM and MemTotal is only mentioning about 1.5GB of that. I've heard graphics cards can take some of the RAM as video memory. is there a way to find out if this is the case?
<brendand> and if so, how much has been taken
<brendand> ?
<lamont> Mar 20 05:28:21 wfg-gw kernel: [36992.811181] nf_ct_sip: dropping packetIN=eth0 OUT= MAC=00:0e:0c:5c:1c:78:00:0c:85:be:5a:85:08:00 SRC=192.168.133.192 DST=192.168.133.1 LEN=588 TOS=0x10 PREC=0x40 TTL=64 ID=27042 PROTO=UDP SPT=53122 DPT=5060 LEN=568 
<lamont> make it stop screaming (3.2.0-19 still doesn't like cisco sip phones)
<dupondje> Weird, every time on startup my wifi is disabled by rfkill: [   26.182093] iwlwifi 0000:03:00.0: RF_KILL bit toggled to disable radio. Thats a bug or something known ?
 * apw lunches
<Teduardo> Howdy, any chance that we'll see support for Broadcom 5720 QP put into the 10.04 LTS?
<smb> lamont, Would that not be something that ufw needs to be teached? I believe that it is not the kernel as is but the firewall logging policy that produces those.
 * apw is now tired
<smb> Just now :)
<smb> apw, From swimming after lunch or a lot of lunch?
 * ogasawara back in 20
<apw> smb, from swimming
<smb> apw, Well done. At least something that feels like an achievement
<smb> ogasawara, Looks like you are preparing to tie up another upload. Is it possible to delay that, still? Just got some feedback from cjwatson about the d-i change and he'd prefer some additional change
<apw> smb, d-i change ?
<smb> apw, I just submitted one this morning to include the dm-multipath module. But it would be more consistent with debian installer otehrwise to have that (and dm-round-robin) in a multipath udeb instead of the md
<apw> smb, ahh ... yeah
<apw> ogasawara, the good thing is the test builds likelly don't test those anyhow, so no need to redo them
<apw>     Block: use a freezable workqueue for disk-event polling
<apw>     
<apw>     commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 upstream.
<apw> smb, ^^ i wonder if that could be the sd_revalidate issue
<apw>     block: fix __blkdev_get and add_disk race condition
<apw> smb
<apw> smb, actually that one ^^ claims to fix it explicitly
<smb> apw, The description does not sound like the change I looked at before
<apw> smb, and a second claiming to fix it :)
<apw>     block: Fix NULL pointer dereference in sd_revalidate_disk
<apw> one of 'em must fix it for P at least
<smb> apw, I beleive that was the one
<smb> And yes, I think those went into some stable
<apw> all of them, thats where i am seeing them in the .12 rebase
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<infinity> apw: Before I go and change all the seeds and installer bits and such...
<apw> infinity, yep ?
<infinity> apw: Wouldn't it make more sense to just make the -powerpc package be the SMP kernel (and make linux-image-powerpc-smp depend on that), much as we've done for all the other arches that no longer have -smp flavours?
<apw> erm i don't recall us dropping one before
<apw> so that'd be before my time
<infinity> It would be, yes.
<apw> ogasawara, ??
<apw> ^^
<apw> bah
<infinity> But -generic used to be a UP kernel.
<infinity> Well, I'm not sure it used to be called generic.
<infinity> Was probably -i386 or something.
<infinity> But you get the idea.
<ogasawara> I changed linux-meta such that linux-image-powerpc actually points to the powerpc-smp kernel
<infinity> We don't explicitly mention -smp anywhere where SMP is the only option.
<infinity> ogasawara: I know, I was arguing that maybe it should go the other way. :)
<apw> i guess the installer doesn't use the meta at all
<infinity> (And this is the same amount of work for me anyway, cause the argument would go further to say that -powerpc64-smp should just be -powerpc64)
<infinity> apw: We sort of do and sort of don't.  It's complicated. :P
<infinity> Anyhow, I'm prepared (and in fact, halfway done) to do the s/powerpc/powerpc-smp/ stuff all over, was just a point of note that we don't have "-smp" kernels on arches that are SMP by default.
<infinity> Which is pretty much all of them now.
<infinity> Anyhow, I don't want to create extra busy work for you guys.  If you're happy with the current state of things, I'll fix up the installer bits and call it done.
<infinity> (And maybe propose a patch next cycle to rename the kernels :P)
<ogasawara> infinity: I've no strong opinion either way, so lets just leave it as is for now and fix it up in Q
<apw> ogasawara, yeah or cirtainly after B2 i recon
 * infinity nods.
<infinity> It's not a strong opinion here, just noting that it's inconsistent naming. :)
<infinity> I'll worry about it later.
<infinity> Oh, have you guys merged the patch from jk/benh?
<ogasawara> infinity: so it's just your ocd kicking in
<infinity> It fixes my G3. \o/
<infinity> ogasawara: If I didn't have my OCD, I'd have nothing.
<ogasawara> infinity: I've applied it, and plan to upload shortly
<infinity> ogasawara: No rush on the uploading, I seem to be the only person complaining.  Just wanted to make sure it was merged.  Thanks. :)
<Daviey> ogasawara: Sorry for not replying to your mail.. i will tackle tboot today.. it required some work, which i haven't had the capacity to do in the last week.
<Daviey> smb: I'd like to raise bug 960311 in the meeting btw.
<ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [Undecided,New] https://launchpad.net/bugs/960311
<ogasawara> Daviey: no worries, thanks!
<smb> Daviey, Ok, I may or may not have had time to look at it before
<Daviey> smb: right.. thought i'd try and give you some heads up.. sorry it's not much
<smb> Daviey, I don't think I'd expect much for something just filed 5 minutes ago
<Daviey> smb: heh
<jwi> smb: while you're playing with dm-multipath - there's also bug 598251
<ubot2`> Launchpad bug 598251 in linux "kernel-image-$version-$flavor-di should provide 'multipath-modules'" [Low,Triaged] https://launchpad.net/bugs/598251
<smb> jwi, If you just look at the kernel-team mailing list...
<smb> ogasawara, Oh well, maybe you want to reference that bug number too in case you apply it
<ogasawara> smb: I'll amend the commit message
<jwi> smb: ah, great! :)
<smb> jwi, It just happened to be brought to my attention by cjwatson a little earlier... Just not that there was another bug report already...
<smb> coincidence... :)
<lamont> smb: that particular message is a printk in the kernel where it looks a the packet a goes "tracking hard, let's just complain about it"
<smb> lamont, Well, fw rules complain via messages looking like kernel ones... There did not seem to be something like that text in the kernel conntrack source...
<apw> bug 922906
<ubot2`> Launchpad bug 922906 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c" [Medium,In progress] https://launchpad.net/bugs/922906
<lamont> smb: in this case, it's from net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c line 120
<lamont> the trick is to grep for nf_ct_%s
<smb> Hm; I was looking for "dropping packet" but maybe I mistyped in a hurry or missed it in the output
<lamont> smb: in other news, upgrading the firewall here to 3.2.0-19 seems to have fixed the occasional issue with not forwarding traffic for some sites
<apw>  /b msm
<smb> -EOMUCHSPACE
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Mar 27th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<cking> jsalisbury, if it's not too much trouble, can you run that test shortly so I can examine the output and write an Email to my favour laptop provider... ;-)
<jsalisbury> cking, I'll do it right now :-)
<cking> ta! :-)
<jsalisbury> cking, Do you want me to run another test to cause an overheat, or do you just need the output from intel-thermdump?
<jsalisbury> cking, log on its way
<smb> lamont, At least something. Hm, it looks like the place you found passes info to a function that uses a per protocol registered logger handler which somehow seems to be leading back to some ipt target called LOG. Not claiming to understand the whole concept here but I get the nagging feeling that this then comes back to be printed only if reaching a certain iptables rule...
<cking> jsalisbury, sorry, i missed your comment. just the intel-thermdump output is fine - I want to see how the MSRs are configured
<jsalisbury> cking, cool, you should have it in email.
<smb> lamont, So maybe an addition in /etc/ufw/after.rules that jumps to ufw-skip-to-policy-input would help you to silence things...
<cking> jsalisbury, thanks, yep, it's poorly configured. how lame is that?
<jsalisbury> cking, That's with the latest BIOS update too.
<lamont> smb: except that I want the traffic to be accepted, truth be told
<cking> jsalisbury, doubly lame then
<jsalisbury> cking, heh
<lamont> 28283   17M ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060
<jsalisbury> cking, can those settings be modified, or can it only be changed in the BIOS?
<cking> jsalisbury, I'm sure there is some room for tweaking
 * cking grabs some food, back later
<lamont> smb: and interestingly, putting that rule at the head of the INPUT chain does nothing.
<cking> jsalisbury, how old is that machine?
<smb> lamont, Oh ok. Was not clear on that. IIRC, wasn't the some problem about some id and the port not being what the helper expected (and which is probably some standard)
<lamont> also, ufw is not usable on this machine, unless it's managed to grow support for forwarding rules
<jsalisbury> cking, About a year and a half old.
<jsalisbury> cking, I purchased it in November/2010
<lamont> smb: sorry about that.  this is a plain ol cisco 7940 phone talking to the asterisk server, which hasn't moved to its own machine yet, so it still lives on the box that does routing for the network as well
<lamont> amusingly, the phone wokr
<jdstrand> it does not have cli support. it continues to have the same support as is documented in ufw-framework (ie /etc/ufw/*rules)
<lamont> works
<lamont> smb: and I suspect that this is actually a case of the kernel saying "sip hard. lets go shopping"
<smb> lamont, it could be that the rule to accept gets "overruled" by conntrack later. But I am far from understanding that whole stuff. And for what I said about the id and port. I just vaguely remember when you were talking about this and then thought at a later point in time you mention something like "doh <something< != port... Which led me to believe you found the reason why it gets dropped.
<lamont> hrm
<smb> Last time I scanned over that conntrack module it seemed like several places change the destination from accept to reject but that does not really help to differentiate between the things happening. 
<lamont> the source port is incrementing, but that's just the phone having fits
<lamont> 11:42:32.373739 IP 192.168.133.192.50815 > 192.168.133.1.5060: SIP, length: 561
<lamont> 11:42:34.784066 IP 192.168.133.192.50816 > 192.168.133.1.5060: SIP, length: 561
<lamont> 11:42:36.373627 IP 192.168.133.192.50817 > 192.168.133.1.5060: SIP, length: 561
<lamont> 11:42:38.783707 IP 192.168.133.192.50818 > 192.168.133.1.5060: SIP, length: 561
<lamont> and so on
<lamont> should be completely valid traffic
<lamont> OTOH, I can see where it would maybe not match ESTABLISHED,RELATED
<lamont> smb: I suspect that it's conntrack remembering the packet for when the response comes through, only not.
<lamont> 12 hours, 20000 lines of log, times 2 files
<smb> lamont, It must be something in the SIP protocol part since it is the sip conntrack helper dropping the packet. Just not sure how to find out what the heck it does not like... :/
<smb> lamont, Would that machine complaining be ok running a debug kernel that adds printk's to whatever place sets the destination to drop? Or rather try to get a wireshark log from some offending packages to try walking through the code. Any way I suppose there should be a bug report to handle any progress. Maybe there is already and I just forgot
<lamont> smb: I would be happy to run such a kernekl
<lamont> at least long enough to have it spew
<lamont> I have a capture of phone traffic from thatphone if you want to walk the code while the kernel builds...
<lamont> generic-pae/i386
<lamont> ISTR filin a bug, let me go look
<lamont> bug 960126
<ubot2`> Launchpad bug 960126 in linux "kern.log full of nf_ct_sip complaints" [Medium,Incomplete] https://launchpad.net/bugs/960126
<lamont> smb: and no, I don't really feel like collecting all the logs in the world for the bug
<lamont> the tcpdump trace file is probably more relevant
<smb> Ok, thanks, I will try to get some kernel. Though it will need a bit of time. Its not only to compile a kernel. I have to add printks in a way they are hopefully meaningful. Plus this side of the world reaches its late end of the day. If the plan works there should only be the syslog telling something
<lamont> smb: cool
<lamont> just holler whenever
<smb> lamont, sure. will do
<lamont> smb: and if you want a packet capture along with the syslog lines, just holler.  I have an unending supply
<smb> lamont, Hm, if it is not too troublesome to get, something I can load into wireshark for inspection would maybe be even better... 
<smb> I am looking at the code anyway to add the printks , so I can as well compare what is in the package while doing so
<lamont> smb: sure.  let me get you a small file.
<cking> jsalisbury, I'm not sure I've got the latest dmidecode output from your updated machine, do you mind sending it to me? Thanks
<lamont> smb: bug updated with the syslog and pcapture
<smb> lamont, Ok, great. Thanks
<lamont> smb: fwiw, tcpdump -s 3000 -w ~/192.pcap host 192.168.133.192
<lamont> afk lunch
<jsalisbury> cking, will do
<jsalisbury> cking, any particular options you want?
<cking> jsalisbury, just "sudo dmidecode" 
<jsalisbury> cking, on its way
<cking> cheers
<henrix> jsalisbury: ping
<jsalisbury> henrix, pong
<henrix> jsalisbury: hi! i just found an old lkml thread that may finally solve bug #922906
<ubot2`> Launchpad bug 922906 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c" [Medium,In progress] https://launchpad.net/bugs/922906
<henrix> jsalisbury: here's the link: http://marc.info/?t=130806561400010&r=1&w=2
<henrix> jsalisbury: i ping'ed the thread, and eric replied stating that the patch has been stalled
<henrix> jsalisbury: he'll try to push it asap
<henrix> actually... it's not on lkml, but on fsdevel
<jsalisbury> henrix, awesome, thanks for getting an update!
<henrix> jsalisbury: no prob. i guess this issue has been around for *too* long :)
<jsalisbury> henrix, I'll keep an eye out for the patch on lkml 
<henrix> jsalisbury: cool
<jsalisbury> henrix, thanks for finding that thread
<henrix> jsalisbury: yeah, that was a though one... specially because lkml was not on CC
<jsalisbury> henrix, yeah, that makes it tricky 
<jsalisbury> henrix, I posted the link to that thread in the bug
<henrix> following lkml is already difficult, following everything else around... is impossible!
<henrix> thanks
#ubuntu-kernel 2012-03-21
<rsalveti> cooloney: can you check bug 960770?
<ubot2`> Launchpad bug 960770 in dkms "Packages requiring dkms at Pandaboard (omap 4) will also pull linux-headers-generic because current dkms dependencies" [Medium,New] https://launchpad.net/bugs/960770
<cooloney> rsalveti: cool, let me take a look
<rsalveti> cooloney: thanks :-)
<rsalveti> cooloney: also, perf is currently broken on omap4
<rsalveti> if you want to take a look on that :-)
<cooloney> rsalveti: i remember i fixed linux-tools package for ti-omap4 before, but haven't try it for a long time
 * apw yawns
 * smb waves
<cking> yawn too
<_ruben> +3
<dholbach> hiya
<dholbach> can anyone comment on http://fridge.ubuntu.com/2012/02/23/ubuntu-12-04-development-update-15/comment-page-1/#comment-4633?
<apw> they are asking about a patch in a comment on a blog post and expecting that to get to the right people ?
<diwic> apw, obviously it seems to succeed? :-)
<apw> just making me grumpy
<smb> +1
<diwic> we've all been newbies
<apw> smb, are you able to sync the stable queue ?
<smb> apw, not this morning apparently
<apw> bah that makes a cogent answer hard to make, i want to know if his patch is in there
<smb> apw, give me a sec
<smb> apw, I only found a mail in the archive discussing the addition of the stable cc, but not yet the announcement to have it queued
<apw> smb, ok ... thanks ... now ... why can't i pull this thing ... kernel.org OI
<smb> apw, Linus tree still works...
<smb> But neither linux-stable nor linux-stable-queue do
<apw> ok both work for me, but linus is zippy and stable is clears swimming in treacle
<apw> there was a suggestion that linus might get its own backend server for security separation
<smb> apw, Hm, and it does not look like the patch has cc: stable added
<apw> thats something, as you say its not in there yet
<smb> apw, Well as they seem to have "forgot" the cc: stable... not sure it will
<smb> Man, kernel.org really is unpredictable right now
<apw> smb, perhaps one of the servers in the rotation is sick or something
<smb> apw, Or rebooting. When you first asked I got the connection reset, now a fetch just is stuck forever as it seems
<smb> Wow, 5minutes later it succeeds...
<apw> that is officially not rapid
<smb> spring tiredness ...
<smb> moco time...
<apw> dholbach, http://fridge.ubuntu.com/2012/02/23/ubuntu-12-04-development-update-15/comment-page-1/#comment-4642 have replied
<dholbach> apw, thanks a bunch - pushed it through the queue
 * apw reboots to get new shineies
<cking> apw, crash n burn
<Daviey> brendand: hey.. so bug 960311 .. you are seeing it on every release?
<ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [High,Incomplete] https://launchpad.net/bugs/960311
<brendand> Daviey, so far i tried with Oneiric and Precise (beta1 kernel)
<Daviey> brendand: Did this hardware never work.. or has something changed on the server?
<brendand> Daviey, the hardware worked last on monday
<brendand> Daviey, i *suspect* a firmware upgrade was done, but i still didn't get a confirmation from the lab engineer
<Daviey> brendand: has anything changed in the hardware since then.. bios flash?
<Daviey> ah
<Daviey> brendand: How soon can you get confirmation ?
 * cking wonders if a data base of firmware versions per machine is being kept so one can look this up easily
<Daviey> cking: a validation one, or by those looking after servers?
<Daviey> I always thought, bios flashing was only done if you encounter issues with the current bios.. I learnt recently that people seem to be doing as a matter of course.
<brendand> cking, would be a good idea...
<brendand> Daviey, another thing is this:
<brendand> failed dmesg:
<cking> brendand, because BIOS is firmware and firmware changes effectively make the machine behave differently, so it *should* be tracked
<Daviey> (smb, are you following this?)
<brendand> eth0: no IPv6 routers present
<brendand> earlier log, no fail
<brendand> that message doesn't appear
<Daviey> brendand: no, that is fine.. it just means it's an IPv4 only network
<smb> Daviey, No I am drinking coffee.. :-P
<Daviey> smb: And you didn't make one for the rest of us?!
<brendand> Daviey - but that wasn't there before?
<brendand> Daviey, with the same image so nothing different software side
<brendand> just one day and the lack of that message
<brendand> and there have *definitely* been lab config changes
<brendand> that i know for sure
<cking> apw, we can hear you but you can't seem to hear us
<Daviey> brendand: I think this bug is blocked on knowing what has changed.
<smb> Daviey, yes, I hope my comment there was clear enough. 
<apw> diwic, just had to kill pulseaudio again to get output to work in mumble
<apw> after a fresh reboot ... it seemed to lose its mind when i asked the mic to change from one channel to another
<apw> diwic, and after that output no longer worked
<smb> Daviey, Since the message in the dmesg points to firmware and there has actually been a bios/fw update, I really would rahter expect a hw failure
<brendand> Daviey, email sent to lab engineer. cc'd you and smb
<diwic> apw, could you *not* kill pulseaudio the next time it happens, so the faulty state could be examined better?
<apw> diwic, sure
<apw> i was in a hurry to get on mumble today
<diwic> apw, unless you have pulseaudio already on verbose log mode in syslog?
<brendand> smb - bear in mind this is not a black and white case of the card never working. it still works to allow the system to pxe install and is accesible for a few minutes after boot
<apw> diwic, not on tnis machine indeed
<brendand> smb - you'll notice those errors come several minutes after boot
<diwic> apw, ok.
<smb> brendand, I would bear that in mind if that was written down in the bug report
<brendand> smb - i can state that explicitly, of course. dmesg already says pretty much the same thing
<smb> brendand, It does not tell you about pxe boot explicitely and it only shows me a message right after setting up interrupts for it about a fw issue. It won't tell anything about the bios update or anything else. And that wasn't in the initial report either. 
<brendand> smb - i don't know if there was a bios update, that's the problem
<amitk> jk-: common clock is finally going in, congratulations and thanks for starting the effort!
<smb> brendand, Well, what I am trying to say is that even the possibility of it mentioned is something that should be in the report. Or whether this is a machine that used to work or... context is important. We do not own working crystal balls
<brendand> smb - i know. i am adding details as i obtain them. sorry for not mentioning the pxe install in the first instance. the other things i have just been finding out today, or have yet to find out
<brendand> smb - btw, can you tell me what the current development kernel version is? to make sure i get the right one
<smb> brendand, Just feeling that the order of things is a bit out of order. First to gather info , then mark the bug critical would be better than the other way round. ;)
 * ppisati -> brb
<smb> For 3.2 I think we uploaded yesterday...
<apw> smb, sitting in the new queue now across the board
<smb> ok so 3.2.0-19.30 is latest as of now
<brendand> smb - well, *i* didn't set the importance :) anyway, i'm focusing right now on completing the picture according to all the requests so hopefully all the info will be there soon
<jk-> amitk: woooot :)
<amitk> jk-: those 6-7 patches have taken 2 years I think :)
<apw> amitk, thats pretty quick :/
<amitk> apw: if you see the thread, there are still arguments (after the maintainer accepting them) to mark them EXPERIMENTAL
<amitk> it's been a saga
<apw> heh ... never ends does it
<amitk> even the popcorn went stale a long time ago
<apw> unopened popcorn would have gone off by now
<amitk> jk-: beers on me if you decide to make the trip to Hong Kong
<apw> ppisati, do your panda boards boot on the precise images ?
<apw> ppisati, i have reports that they do not, and wondering if you are seeing issues
<ppisati> apw: last time i tried yes, they worked
<ppisati> apw: any particular image or just the last one?
<apw> the compainant is implying that they have not worked for some time, so if you have booted someting in the last week that is interesting, is that !XM, XM or both you have done?
<apw> oh that is beagle isn't it
<apw> ppisati, ^^
<ppisati> yep
<ppisati> uhm
<ppisati> i think i tested it last week
<ppisati> iirc
<ppisati> i mean, omap3 (beagle, beagle xm)
<ppisati> while i use panda eveyday
<ppisati> so, is it beagle or panda? omap3 or omap4?
<apw> its panda i am told, so panda you tested in the last 24 hours and it works
<ppisati> definitely
<ppisati> i'm using latest kernel i released
<ppisati> but i'm downloading latest preinstalled image just to see
<apw> ppisati, let me know ... thanks
<apw> ppisati, he has a 'rev 1A pandaboard' is that older than yours, do you have one?
<ppisati> apw: same here, rev A1
<apw> A1 or 1A
<ppisati> sticker on the back of my board says rev A1
<ppisati> did he use the daily preinstalled image?
<apw> yep checking if his is 1A or he typo'd it
<apw> ok its A1
<apw> ppisati, if it works for you, could you also paste the URL for the working image you used
<ppisati> yep
<ppisati> dd takes ages...
<apw> sd cards are soooo fast
<ppisati> apw: works here, i'm in the installer
<ppisati> apw: let me finish the installation
<apw> ppisati, thanks
<ppisati> ah
<ppisati> a new installer! :)
<ppisati> we can choose a pic now
<ppisati> or even take one
<apw> shiney, yeah i think i saw that somewhere, i like the burning match
<ppisati> http://cdimage.ubuntu.com/daily-preinstalled/current/precise-preinstalled-desktop-armhf+omap4.img.gz
<ppisati> zcat Downloads/precise-preinstalled-desktop-armhf+omap4.img.gz | sudo dd of=/dev/sdc bs=4M
<ppisati> put the resulting sd card in the panda sd slot,  power the board and follow the installation procedure
<ppisati> apw: ^^
<ppisati> of course, 'of=/dev/sdc' is system dependent (i don't want to wipe his system)
<apw> yep :)
<Daviey> ppisati: yes you do :)
<apw> tgardner, can you hear us ?
<tgardner> fu576`3ing pulse
<ericm|ubuntu> diwic, are you still on mumble? I seems to be dropped and not succeeded in connecting so far
<diwic> ericm|ubuntu, meeting has ended, sorry
<ericm|ubuntu> diwic, due to connection problem?
<diwic> ericm|ubuntu, we figured you were about to say something evil about the government and they proactively cut you off
<ericm|ubuntu> diwic, yeah I was about to
<ericm|ubuntu> diwic, but how does the great firewall predicts that?
<diwic> ericm|ubuntu, it is very intelligent
<diwic> ericm|ubuntu, the meeting ended when the few of us who were there had said what we were supposed to say
<ericm|ubuntu> diwic, really impressed by the party's cutting edge technology
<ericm|ubuntu> diwic, the rest just cannot get on again?
<ericm|ubuntu> diwic, just want to make sure it's not happening to me _only_
<diwic> ericm|ubuntu, only you and a16g had connection problems, for the others it was fine I believe
<ericm|ubuntu> diwic, sounds like a connection problem behind the great firewall
<apw> glxinfo -l | grep GL_MAX_TEXTURE_SIZE
<tgardner> apw, GL_MAX_TEXTURE_SIZE = 8192
<ppisati> a new kernel is baking, in the mean time i'm out for a bit
<tgardner> ppisati, have you seen bug #961133 ?
<ubot2`> Launchpad bug 961133 in linux "Ubuntu Desktop ARM Images do not boot on my Pandaboard" [Undecided,Incomplete] https://launchpad.net/bugs/961133
<tgardner> ogasawara, gomeisa arm* chroots appear to be working again.
<ogasawara> tgardner: cool, what changed?
<tgardner> qemu-static AFAICT
<tgardner> looks like I still need to twiddle with armhf, nut armel is working
<tgardner> *but
<ppisati> tgardner: i think that's what apw told me earlier this morning
<tgardner> ppisati, ok
<ppisati> tgardner: i tested today's image and it's working ok on my panda
<ppisati> btw
<tgardner> ppisati, I noticed he's got an A1
<ppisati> at least on tangerine, armhf chroot kind-of work
<tgardner> would that make a difference ?
<ppisati> tgardner: yes and no, but i got an A1 too and it's working
 * cking reboots
<tgardner> ogasawara, I'm dribbling ABI bumper cruft into precise master-next
<ogasawara> tgardner: ack
<tgardner> ogasawara, so no need to startnewrelease, etc
<vanhoof> anyone know if it's possible to create a config idential to what I see in /boot/config-3.2.0-1409-omap4 from git?  Been playing w/ fdr genconfigs/genportconfigs as well as splitconfigs.pl but I must be doing something wrong, I always end up with a common omap config
<tgardner> vanhoof, our config algorithm is a many to one relationship, so its hard to go backwards
<ogasawara> vanhoof: which branch are you in?
<vanhoof> ogasawara: the wrong one :)
<vanhoof> ogasawara: ikepanhc got me hooked up
<ikepanhc> :)
<vanhoof> after a checkout of the right branch, i'm all set after fdr clean..genconfigs
<cking> rtg, you may also like to try http://www.piware.de/2012/02/power-usage-report-find-power-drain-causes/
<apw> ppisati, are there jumpers on your A1, if so perhaps you could enumerate your settings
<apw> (in that bug(
 * ogasawara back in 20
<apw> vanhoof, and yes fdr clean; fdr genconfigs would be the approved way to get the configs out
<ppisati> sometimes i don't understand git rebase...
<ppisati> apw: panda is jumperless
<apw> ppisati, git rebase> why whats it done
<apw> ppisati, panda> ahh ok, then not that then
<ppisati> vanhoof: export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-; fakeroot debian/rules clean prepare-omap4
<ppisati> vanhoof: in ti-omap4 branch (git checkout ti-omap4 from an ubuntu-precise git tree)
<ppisati> apw: well, it's reapplying patches i din't expect should be reapplied
<apw> ppisati, you rebasing against a rebased tree?
<ppisati> apw: yes
<ppisati> apw: P/omap4 on P/master
<apw> ppisati, and are you telling it where your base is ?
<ogra_> my panda jumps if i hit the table really hard
<apw> as it cannot find the bottom of the rebase correctly in that situation
<ppisati> apw: good point, but i never had to
<ppisati> apw: ok wait
<kees> okay, I have a git tree based on 3.3, and I've got the precise tree. is there a sane way to pull a chunk of patches off the top of the 3.3 tree onto the precise tree without doing per-commit cherry-picks?
<apw> ppisati, yeah and it'll probabally work mostly as long as there arn't any commits dropped in the original master
<ogasawara> kees: you can cherry-pick a range of commits now
<ppisati> apw: let's say you are in topic branch created from master
<kees> ogasawara: oh! that's much better
<apw> but the most reliable way is to use the rebase --onto origin/master-next old-master
<apw> form of re
<ppisati> apw: git co topic; git rebase master
<apw> rebase
<ogasawara> kees: I know!  just found that out a week or so ago.
<ppisati> apw: and it almost immediately complain about a clashing commit
<apw> ppisati, that is valid _if_ master is not a rebased branch
<apw> ppisati, as in P it still is you need to use: git rebase --onto master oldmaster
<apw> where oldmaster is where you last were rebased to, or the commit before your first one
<ppisati> apw: you go look at your actual tree just to notice that is different from master (while i expect the first thing it does is to kind of format-patch the pile of patches not present in master, git reset --hard origin/master and then apply all of the patches one by one)
<apw> git cannot work out the correct base point in your case till P releases, then we stop rebasing master and life is fine
<ppisati> fine, i'll do
<apw> and that is what it does, but it does it by working out where the previous common commit is between the old and new branches, and using that base to lift all the patches
<apw> as wehave rebased too the common merge point is back on mainline somwhere and so you try and pick up the whole of leanns stuff too, fail
<ppisati> so according to merge-base i should be in Linux-3.2.9 but i'm not there either
<ppisati> yep, i figured that out
<apw> what does merge-base say
<ppisati> Linux-3.2.9
<ppisati> so it picks all the stuff from there on (almost)
<ppisati> ok
<apw> yep, it can detect some identicle commits are the same and drop them
<apw> but its not very easy and tends to go pop
<ppisati> i got it while talking
<ppisati> the funny thing is that we had these apparmor commit before
<apw> anyhow if your base is a rebase tree then --onto is the only sane way to use it
<ppisati> these where dropped
<ppisati> later reapplied (last kernel)
<ppisati> ah, nevermind
<apw> ppisati, we are dropping and readding apparmor en-toto so that the patches can be updated to match upstream exactly to make maintenance of the result easier
<ppisati> right
<GrueMaster> ppisati: Just fyi, I have been seeing strange lockups on the pandaES with the desktop image.  I'm trying to capture some log output, but so far unsuccessful.   System has to sit for a long while (this particular try has run since Monday evening).
<GrueMaster> Other community members have seen it also on #ubuntu-arm.
<ppisati> GrueMaster: are you using the sgx driver?
<ppisati> GrueMaster: if yes, try to uninstall it
<GrueMaster> No.  Desktop image from 20120319.  No updates, fresh image.
<ppisati> k
<GrueMaster> I do not see it on server, which leads me to believe it may be kernel/Xorg related.  I saw something similar during Natty(?) where the system would lose the monitor during sleep and hang as a result, but it would at least spew stuff in the log.  This is a hard lock (solid LED instead of heartbeat).
<GrueMaster> I enabled serial console on this image in the hopes of capturing something, but I don't have anything on the serial console post Upstart.
<ppisati> that reminds me i should expense an ES board
<ogra_> ++
<ppisati> ogra_: you, stop bumpinmg your board! :)
<ogra_> hehe
<GrueMaster> ppisati: Rebooted and looking for residue in the logs.  I am seeing a lot of spamming (every ~1.5 sec) from the kernel: ti_hdmi_4xxx_detect: by detect line: 1 (1 == connected)
<ogra_> i have that too here 
<ogra_> doesnt kill the board for me though
<GrueMaster> Yea, I see it on all systems, including the headless ones.
<ppisati> GrueMaster: i'll kill it in the next update
<GrueMaster> k, thanks.
<apw> ogasawara, so that EDID patch ... you might want to hold fire on reading it right now ... seems upstream now has a different way ... BAH ... i find out 30s after I sent it
<ogasawara> apw: ack
<smb> lamont, Ok, just updated the bug with test kernel location. Now hopefully you see some magic "Dropped by" messages in dmesg ...
<tgardner> apw, too late. I've already been polluted.
<sforshee> tgardner, ogasawara: the apple-gmux driver that's landing upstream has a couple of changes from what we're carrying in precise. I'd like to update precise -- would you prefer patches on top of our sauce patch or replacing it with the patches headed upstream?
<ogasawara> sforshee: I prefer to replace with what's heading upstream
<sforshee> ogasawara, ack
<lamont> smb: I'll upgrade later today and see what we see
<smb> lamont, ack
 * ppisati -> disappear for a bit
<vindex> hi
<vindex> has anybody used perf successfully on ubuntu?
<vindex> im having trouble getting a custom vanilla kernel compiled with perf properly working
<vindex> 3.2.10
<vindex> (vm guest)
<apw> vindex, yes i have used basic perf on ubuntu kernels
<vindex> apw: im experiencing a "vmlinux symtab| mismatch, and after stracing the process it never opens a vmlinux image, only kallsyms
<vindex> the kernel has proper perf support compiled in, dbg symbols and other stuff
<vindex> (im doing kernel development)
<apw> hmm never seens that, though we 
<apw> we build perf with the kernel when we build it
<apw> as it is in theory build differently based on the kernel
<vindex> well, ive done make oldconfig, all/modules/bzimage, modules instal, install, boot
<vindex> and then cd tools/perf make
<vindex> yes, it uses kernel sources / headers directly so it is influenced
<apw> then that sounds reasonable faximily of what our packaging does, so i'd not expect issues indeed
<tgardner> vindex, is what you're doing work on a stock Ubuntu kernel ?
<vindex> thats why im quite pissed at this stage to have issues
<apw> other than saying it seems to work ok without our packages, i am not sure what the issue is
<vindex> tgardner: it is applicable, but i like to work on git vanilla srcs first
<vindex> since i develop for the kernel, not ubuntu. ubuntu is the platform i use for development, and the patches i work on apply fine to ubuntu kernels
<vindex> but it is far from being the only audience i target
<apw> vindex, yep ... but no we've not seen that
<vindex> vmlinux symtab matches kallsyms: failed
<vindex> thats the error, nothing obvious when i try to see what might fail
<vindex> all open() calls seem successful
<vindex> how is linux-image-tools built for each kernel?
<apw> vindex basically the way you indicate, and they seem to work here
<vindex> i mean how could i replicate the pkg from vanilla sources? it doesnt seem like a make-kpkg target
<vindex> where does perf read the vmlinux file from normally?
<apw> /boot i assume as thats the only one in place
<apw> the master branches in our git repos represent the raw source we use, building that package drops the linux-tools package
<vindex> is there any backport/testing pkg for 3.2?
<vindex> perhaps i could use linux-tools from those
<apw> there are 3.2.12 ish based kernels in the archive for precise
<apw> we only build tools in the official ubuntu builds
<vindex> seems like at least the ubuntu perf exec looks for vmlinux in /boot
<vindex> vanilla doesnt
<vindex> weird.
<ogasawara> bjf: I'm looking at http://people.canonical.com/~kernel/reports/_precise-open-bugs_.html and am just curious how it determines which bugs to put on there?
<ogasawara> bjf: more specifically I guess I'm curious how bug 936552 is still managing to show up there
<ubot2`> Launchpad bug 936552 in xserver-xorg-input-synaptics "MacBookAir 4,1 trackpad does not work with evdev/multitouch driver" [Medium,Confirmed] https://launchpad.net/bugs/936552
<ogasawara> bjf: is it the kernel-da-key tag?
<bjf> looking
<bjf> ogasawara: it shouldn't be, i'll look into it
<ogasawara> bjf: ack
<kees> ogasawara: karblewy, pull request for seccomp delivered!
<ogasawara> kees: thanks!
<kees> it's huuuuge :)
<ogasawara> kees: sounds ominous
<kees>  39 files changed, 1660 insertions(+), 74 deletions(-)
<kees> it's relatively isolated, as it turns out, but it's still big.
<kees> anyway, the Chrome security team was really hoping they could see it in beta 2, so I cranked it out today. Upstream seems pretty settled on everything, so I figure the day before beta 2 freeze is about as late as I can stand. :)
<apw> kees, i susect you have missed the boat, as the kernel takes 2 days to get done
<kees> apw: noooo
<kees> apw: that sucks -- the freeze is tomorrow! :P
 * tgardner -> EOD
<kees> ogasawara: so, is it likely that seccomp will see beta 2?
<ogasawara> kees: what time is freeze tomorrow?
<kees> ogasawara: I have no idea :P
 * kees asks in #u-release
<ogasawara> kees: I'm going to assume it's an ABI bumper in which case I'm not sure we could make the freeze deadline
<ogasawara> kees: so we likely would need to get a freeze exception
<ogasawara> kees: which probably wouldn't be too painful if we give them a heads up
<kees> ogasawara: 2100 UTC
 * ogasawara checks what time it is now
<kees> 20:45 UTC, so just over 24 hrs from now
<ogasawara> commit 8e8079f9e951ef1921b0de648568ea4b10c38d8b
<ogasawara> Author: Andy Lutomirski <luto@amacapital.net>
<ogasawara> Date:   Mon Jan 30 08:17:26 2012 -0800
<ogasawara>     UBUNTU: SAUCE: SECCOMP: Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
<ogasawara>     
<ogasawara>     With this set, a lot of dangerous operations (chroot, unshare, etc)
<ogasawara>     become a lot less dangerous because there is no possibility of
<ogasawara>     subverting privileged binaries.
<ogasawara>     
<ogasawara>     This patch completely breaks apparmor.  Someone who understands (and
<ogasawara>     uses) apparmor should fix it or at least give me a hint.
<ogasawara> kees: ^^ "This patch completely break apparmor" has me concerned
<ogasawara> kees: breaks apparmor how?
<ogasawara> kees: ha, disregard
<ogasawara> kees: I'm now seeing the next patch :)
<kees> ogasawara: heh, yes :)
<pbuckley> anyone have a good link for the differences between ubuntu's 11.10 kernel (3.0) and the 12.04 kernel (3.2)?
<ohsix> kernelnewbies has most of the interesting stuff in the release notes
<pbuckley> cool thanks
<ohsix> beyond that, git log :>
<pbuckley> heh.. that seems like a like of commits to go thru.. just trying to justify building our next project on 12.04 vs 11.10 thats going to ship in like 6 months
<pbuckley> +alot
<ohsix> linus has a release message that has interesting stuff in it too, but kernelnewbies is the meat
<pbuckley> hrmm i only see 3.3
 * pbuckley digs around some more
<pbuckley> http://kernelnewbies.org/Linux_3.2
<pbuckley> \o/
<ogasawara> kees: getting build failures on arm
<ogasawara> kees: kernel/seccomp.c:27:25: fatal error: asm/syscall.h: No such file or directory compilation terminated.
 * kees shakes a fist
<ogasawara> kees: I gotta drop off for a bit, I'll check back in a bit
<kees> okay
<kees> ogasawara: I don't have an ARM build environment :(
 * Daviey passes kees a qemu-system-arm.
<kees> ogasawara: can you wrap the #include line with #ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER block maybe?
<kees> Daviey: if only it were that easy! :)
<Daviey> kees: i'd love to know how long cpu virt takes to build an arm kernel :)
 * kees cries
<Daviey> kees: ScottK was given two arm 'server' boxes to setup for community access.. he's had them over a year, ask them how access is progressing. :)
<kees> actually, it turns out I've already set up for qemu-arm, I just need to override the mirror and mk-sbuild will DTRT
<ogra_> Daviey, they were slow ones and still havent finished their boot :P
<Daviey> ogra_: I blame the canonical arm team for the slow booting :P
<ogra_> haha, you never booted an ac100 with a recent image, did you ?
<ogra_> (boots faster than any x86 SSD based machine i have around)
<ogra_> (though indeed ac100 is a community effort, cant credit the ubuntu arm team for it ;) )
<kees> mk-sbuild --arch=armel precise --debootstrap-mirror=""
<kees> wheee
<apw> kees, can't you cross compile, thats what most of us do to confirm compilability
<jjohansen> apw: for the apparmor rebase should I do a whole sale drop in of 3.4 aa as a single patch, or cherry pick the 20 or so upstream patches
<bandit5432> what channel should i be in to talk about the latest mainline release?
<pbuckley> oh yay.. that numa stuff made it into 3.1
<bandit5432> any have any regressions with 3.3 from rc7 and optical drives?
<bandit5432> kernel v3.3-precise does not recognize my ide optical drives any thoughts? v3.3-rc7-precise works fine
<ogasawara> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
<ogasawara> index 8af235b..d22ef26 100644
<ogasawara> --- a/kernel/seccomp.c
<ogasawara> +++ b/kernel/seccomp.c
<ogasawara> @@ -24,7 +24,9 @@
<ogasawara>  #include <linux/slab.h>
<ogasawara>  #include <linux/uaccess.h>
<ogasawara> +#ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
<ogasawara>  #include <asm/syscall.h>
<ogasawara> +#endif
<ogasawara> kees: ^^ seems to fix it
<ogasawara> kees: I'm just gonna squash it with "UBUNTU: SAUCE: SECCOMP: seccomp: add system call filtering using BPF"
<c_smith> hey, I encountered something strange, and fixed it after quite a while, but it pertains to the kernel, as it kept either dumping a crash log to my screen, or throwing me a Kernel Panic, the situation was that I had all 3 of my RAM slots in my desktop filled with a 1 GB PC-3200 RAM stick each, and kept getting said crash dumps and kernel panics.
<bandit5432> did you test the ram?
<c_smith> Yes, I did, once with each ram stick inserted one at a time and then again with all 3, memtest86 reported no errors.
<c_smith> and I ran all 9 tests with Memtest86.
<bandit5432> how did you fix it?
<c_smith> removed one stick.
<ohsix> did you check your motherboard documentation, some of them aren't expected to be stable with the ram slots filled in different ways
<bandit5432> do you have a bad ram slot
<ohsix> eg. they need to go in as pairs or the like
<c_smith> sadly, I don't have the documentation, the desktop was given to me.
<bandit5432> you can download the docs from the manufacture 
<ohsix> some chipsets don't even terminate the other banks when there's one piece of memory in a pair of slots :P
<c_smith> and it might be the slot, no clue. I got the desktop only recently.
<c_smith> hmmm, that might be handy, I'll look at the manufacturer.
<c_smith> ofc, I have no clue as to even the model for the mainboard.
<c_smith> would it say on the mainboard?
<bandit5432> yes
<c_smith> cool, I'll get to that info,
<c_smith> thanks for the tip. :)
<bandit5432> and if its a hp dell etc look up the model #
<c_smith> it's a Gigabyte mainboard, that much I know from the BIOS.
<bandit5432> gigabytes are easy to look up
<bandit5432> look to the left of the first ram slot
<c_smith> thanks
<bandit5432> np
<c_smith> and I am curious, how outdated would PC-3200 RAM be?
<c_smith> not that it's essential, just a curiousity.
<ohsix> ram doesn't usually go out of date, it goes in the bin with the computer :P
<ohsix> but we're to ddr3 now
<c_smith> ok
<c_smith> yay for tiny text..... having a tough time finding it.... >.<
<c_smith> ok, think I found it.
<c_smith> yep, found it, would have helped to have the flash light ready from the start,
<c_smith> so, it looks like the max supported RAM is what I had, 3GB via 3 DIMM slots.
<c_smith> so, mightn't it be the slot even if Memtest86 reported no errors with all 3 slots being occupied?
<bandit5432> it could be anything what kernel are you running with it breaks?
<c_smith> the latest one in the Oneiric updates, but it also happened with the second latest.
<c_smith> let me plug it in to get you the latest one that the desktop is running
<bandit5432> search for kernel panics and the kernel ## and see what causes them I had a bad powersupply that caused kernel panics so it could be a lot of things
<jMCg> How do I get this string 'lib/x86_64-linux-gnu' from debian build tools?
<c_smith> kk
<c_smith> what do I search in?
<bandit5432> google
<c_smith> kk.
<bandit5432> uname -r to get the kernel version
<bandit5432> in a terminal
<c_smith> the kernel version is 3.0.0-16-generic. uname ftw! :)
<c_smith> meh, not finding anything useful...... only an Atheros panic that was fixed in 3.0.0-16
#ubuntu-kernel 2012-03-22
<c_smith> is there a log I could pull up that might help me?
<kees> ogasawara: oh good, thank you! my ARM environment is ... slow :)
<bandit5432> you can open log manager
<c_smith> kk
<c_smith> gah, I am having no luck finding anything.
<bandit5432> then try running it with the 2 sticks and see if you have errors or crashes if it crashes look in the logs and see what the log said before the crash
<c_smith> I haven't had a crash at all with 2 sticks. and it only started when the 3 stick was properly inserted (it wasn't in to where it would recognize it before, due to me not having messed with RAM before)
<bandit5432> i would say its a ram or slot issue and go from there
<c_smith> well, most of this PC is going to be replaced in the future, it's several years old, so not surprising.
<c_smith> thanks for the help. :)
<bandit5432> no problem
<jcastro> jsalisbury, I think you got it dude
<jcastro> this one works
<jcastro> it's only been since you posted it but with the last kernel by now it'd be hosed.
<jcastro> I'll leave it running overnight though
<ogasawara> kees: kernel uploaded, I'll keep an eye on it and rev lbm and meta when it's ready, we should hopefully have enough time to make it before freeze
<bandit3453> i need some help running git bisect any one around that can coach me?
<bandit3453> is any one running the 3.3 kernel with ide optical drives and can check and see if they work?
<bandit3453> cat /var/log/dmesg | egrep '(CD|DVD)'
<infinity> apw, ogasawara: linux-ti-omap4 through NEW, if someone wants to to give me a new meta for that.
<AceLan> bjf: hihi, should I attach logs for the bug if I only want to send a patch? # ex. bug 961880 and bug 961879
<ubot2`> Launchpad bug 961880 in linux "[ET2012] Press Fn+F7 could not turn on/off display" [Undecided,Incomplete] https://launchpad.net/bugs/961880
<ubot2`> Launchpad bug 961879 in linux "[ET2012I+ATI] Brightness control doesn't work." [Undecided,Incomplete] https://launchpad.net/bugs/961879
 * cking yawns
<smb> cking, What threw you out of bed?
<cking> the sunshine did
 * cking --> re-installs after breaking his box :-/
<apw> infinity, ack
<smb> apw, morning
<jk-> hey smb & apw
<smb> jk-, heya
<smb> apw, Btw, this is a morning to closely read what apt is about to do
<apw> smb, is that why cking's machine is dead ?
<smb> apw, yup
<smb> Think some of unity decided to part ways ...
<smb> I stopped after reading it wanted to remove bzr... Ok, not bzr's best friend but I need it anyways from time to time
<apw> infinity, all done
<smb> cking, We can hear
<smb> cking, yes
<smb> you need to be killing pulseaudio harder... :-P
<cking> i can't hear anyone in mumble though :-/
<smb> cking, We stopped saying anything after you "ignored" us a few times... :)
<cking> heh, that was a forced ignored caused by a re-install ;-)
<smb> cking, I know, just let us know if you want us to say something again
<smb> cking, yes we cna
<smb> can
<smb> cking, and I sayd something
<smb> you still cannot hear
<smb> ppisati, can hear me
<cking> bah
<ppisati> "yes i can!"
<smb> cking, still no luck for you
<cking> nope - /me applies hammer to pulseaudio
<apw> smb, so did you get 'deleting everything' or is it ok now, mine loooooks ok ?
<smb> apw, No, not everything. It was just 4 to be deleted
<apw> Calculating upgrade... Done
<apw> The following packages will be upgraded:
<smb> But I did upgrade instead of dist-upfrade then
<apw> nothing to be deleted for me
<smb> The following packages will be REMOVED
<smb>   gnome-shell gnome-tweak-tool
<smb> 30 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
<ppisati> mine is ok
<smb> The count is going down... 
<ppisati> 165pkgs dist-upgraded
<infinity> apw: lbm and linux-meta should be good to go too.
<apw> infinity, thanks
<infinity> apw: Seed already changed, we can rev d-i as soon as you get that meta in. ;)
<infinity> s/Seed/Seeds/
<apw> infinity, ack
<apw> if my machine would respond to the 'q' i sent it a while back i might make some progress ... sigh
<apw> infinity, lbm in the pipe/b #kitchen
<apw> bah
<infinity> apw: Do me a favour and upload -meta in ~13 minutes (ie: after :04)
<infinity> apw: I'll make sure they both get in together.
<apw> infinity, is that safe with lbm not yet built ?
<infinity> apw: It'll be built by then. :P
<apw> infinity, ack will do :)  i was going to be watching it and uploading as soon as done
<ppisati> guys, how do i check what a package "Provides" via apt-*?
<ppisati> i know i can check debian/control for a given src package
<ppisati> but what about a binary package?
<smb> ppisati, would apt-cache show <package> contain something?
<ppisati> nope
<ppisati> i already tried that
<ppisati> flag@panda:~$ apt-cache show linux-headers-omap4 | grep -i provide
<ppisati> flag@panda:~$
<ppisati> but debian/control of the kernel packages has the Provides line
<smb> ppisati, that sounds like the meta package for the headers...
<ppisati> yep
<ppisati> the point is that linux-heades-omap4 doesn't "Provide" linux-headers
<smb> Well it like does not
<smb> It only depends on the binary package
<smb> which provides the headers...
<ppisati> i think i lost you here :)
<smb> apt-cache show linux-headers-generic
<smb> Depends: linux-headers-3.2.0-19-generic
<ppisati> ok
<smb> apt-cache show linux-headers-3.2.0-19-generic
<smb> Provides: linux-headers, linux-headers-3.0
<ppisati> ah
<ppisati> so it's a problem in the *omap4 pkgs
<ppisati> since they don't have any Provides:
<ppisati> no wait, they do
<ppisati> ok, now i see what you mean
<ppisati> i was querying meta instead of the real pkg
<smb> Right, apart from here where the meta seems to spew out its purely virtual
<smb> but that could just be my setup missing the right pools
<ppisati> ok, seems linux-ti-omap4-headers never provided linux-headers
<ppisati> and since dkms depends on linux-headers it fetched linux-headers (that in turn fetched linux-headers-generic)
<smb> ppisati, Hm, I never looked at what comes out of it but looking at debian.ti-omap/control.d/flavour-control.stub there seems to be a Provides in there...
<smb> Probably needing overhaul... 
<smb> Provides: SRCPKGNAME-headers, SRCPKGNAME-headers-2.6
<smb> ppisati, ^ Isn't ti-omap at least 3.0?
<ppisati> since O yes :)
<smb> apw, Likewise, does not seem to cause issues but would not the headers for 3.2 provide linux-headers-3.2 not 3.0?
<apw> smb, i think actually they should provide linux-headers-3 under the previous scheme
 * apw will think about it
<ppisati> yep, that's what generic does
<smb> apw, Ah ok, yeah sounds better as well... just the way it is now feels confusing, now that I actually look at it
<apw> yeah i think its broketed, but i can't remember if there is any consumers of the thing anyhow
<smb> I am pretty sure there is not, otherwise there would be people all over us by now
<ppisati> oh i see
<ppisati> debian.ti-omap4/control.stub.in:
<ppisati> Provides: SRCPKGNAME-headers
<ppisati> and SRCPKGNAME = linux-ti-omap4
<brendand> apw - did you get to check out our list of cert blockers this week?
<apw> brenden i have had some feed back, i will look at the responses next and send something out
<ericm_> tgardner, ping
<ericm_> tgardner, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/714862
<ubot2`> Launchpad bug 714862 in linux "Atheros AR3011 cannot be turned up/is not recognized." [High,In progress]
<ericm_> tgardner, would like to hear from your feedback
<tgardner> ericm_, looking...
<ericm_> tgardner, so Atheros provided a firmware for this issue - and patch has been submitted (not accepted yet)
<ericm_> tgardner, this firmware will fix many similar issues on LP
<ericm_> tgardner, yet the problem is - the fix changes the firmware which is shared among several other devices
<tgardner> ericm_, have you regression tested other devices ?
<ericm_> tgardner, I can verify that the firmware works for this DW1702, VID/PID being 0x0cf3:3002
<ericm_> tgardner, nope - that's the card I have _only_
<ericm_> tgardner, however - contact from Atheros said they've verifed this firmware on other chips as well
<tgardner> ericm_, well, we can always try it to see what breaks. sounds likle we ought to be OK
<ericm_> tgardner, and by googling a bit - I believe this firmware will also fix the other devices
<ericm_> tgardner, yeah that's what I'm thinking of
<ericm_> tgardner, so will be good if I post the patch now?
<tgardner> ericm_, it goes into linux-firmware, right ?
<ericm_> tgardner, yes - or you can pick it directly from http://comments.gmane.org/gmane.linux.kernel/1262485
<tgardner> ericm_, how about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/714862/comments/44 ?
<ubot2`> Launchpad bug 714862 in linux "Atheros AR3011 cannot be turned up/is not recognized." [High,In progress]
<ericm_> tgardner, if we do something to make sure this applies _only_ to the device I verified, the kernel source will have to be changed
<ericm_> tgardner, that would be the one
<ericm_> tgardner, let me know the md5sum when you downloaded it
<ericm_> tgardner, so I can confirm with my working version
<tgardner> ericm_, if we do as you suggest (change the kernel), then none of the other devices get any goodness from this new firmware. If atheros _says_ it should work, then lets go with their opinion.
<ericm_> tgardner, that's what I think, I share your great idea, I'm more than pleased :-)
<ericm> tgardner, also I've sent out the patch just in case, whichever works for you easier
<tgardner> ericm, Uploading linux-firmware_1.73.dsc: done.
<ericm> tgardner, cool - I'll test it once it lands in -propose
<ericm> tgardner, it will first go into -propose right?
<ericm> tgardner, nah - this is precise, sorry
<tgardner> ericm, not for precise. the archive is still under development
<cooloney> ppisati: any clue about that headers package issue in ti-omap4, i got ping from rsalveti about this. and i think we copied that to our armadaxp configure.
<ppisati> cooloney: just the a patch to ukml
<ppisati> *sent
<rsalveti> ppisati: cooloney: great, thanks
<rsalveti> let me check
<ogasawara> apw: thanks for uploading lbm and meta
<apw> ogasawara, i think i thought you were off today, and you are welcome
<ogasawara> apw: I am, but woke up to make sure those were done
 * ogasawara goes back to sleeping in
<apw> heh ... GOOD :)
 * ppisati -> lunch
<apw> ogasawara, i asume there is no release meeting this week
<ogasawara> apw: there is, but I've already got the email prepped and ready to send out
<ogasawara> apw: and I was planning to sit in on the meeting
<apw> ogasawara, you are worse than me
<tgardner> ogasawara, its 0530 where you are. go back to bed.
<ogasawara> tgardner: habit I guess, I didn't even have the alarm set and still woke up
<tgardner> ogasawara, its sucks, doesn't it :)
<ogasawara> tgardner: there's a nice layer of snow outside my window, maybe it's a sign to hit the mountain today
<tgardner> ogasawara, I had a great day Tuesday. 19" new
<ogasawara> kees: kernel + lbm + meta all finished with plenty of time before the freeze
<ogasawara> later dudes
 * jsalisbury is jealous hearing about all this snow, when it's been 80F all week!  We normally should have snow :-(
<cooloney> ppisati, rsalveti thanks, i will take care of this for linux-armadaxp
<smb> jsalisbury, They talk about outside. ;-P Ok, only got 668 here but it feels warm enough...
 * smb mean 68
<jsalisbury> smb, :-)  I actually enjoy the warm weather, but we didn't get any snow this year except the freak Haloween storm.  Oh well.
<smb> I believe we did not get much snow either imo. Still a bit ugly as it swings between 66-70 during the day and 34 at night.
<ppisati> jsalisbury: 20C here, and probably this weekend i'll hit the beach, you wanna come? :)
<jsalisbury> ppisati, sounds a little cold for swimming still :-)
<ppisati> jsalisbury: well, but you can still enjoy the sea breeze, sunbath, etcetc :)
<jsalisbury> ppisati, absolutly :-D  
<smb> ppisati, Though if he really has 80F this beats your 20C ;)
<jsalisbury> smb, ppisati, very odd for this time of year.  It should only be ~40F
 * ppisati has problem with the Imperial <-> Metric conversion
<ppisati> :)
<smb> ppisati, Ask Mr. Google
<ppisati> ~27C, holy crap
<smb> jsalisbury, This really sounds quite wrong. Even with our lower temperatures I am quite suspicious it just wants to go back freezing as soon as you don't look
<jsalisbury> smb, yeah, it's going to here, just in time for the weekend :-/
<smb> Tease and freeze... bloody weather gods and theirs sense of humor... ;)
<jsalisbury> cking, I installed the debug kernel: linux-image-3.2.0-19-generic-dbgsym  I rebooted and didn't see that kernel listed in grub, only linux-image-3.2.0-19-generic
<diwic> jsalisbury, dbgsym packages are not special kernels AFAIK, they just provide additional info when you're running the current kernel.
<jsalisbury> diwic, cool, thanks.  So as long as I'm running the same kernel version, it will pick up the debug symbols
<diwic> yep, that's my understanding of it
<jsalisbury> diwic, great, thanks.
<diwic> that's the way it works with other dbgsym packages
<cking> diwic, thanks for answering ;-) I was not looking at this channel
<phatphoton> Hi all, I have a problem with my bluetooth autodisconnecting after auth for a mouse. I have an hcidump to help, could anybody help me on that feild?
<jjohansen> tgardner, ogasawara: do you want the apparmor pull request based off of the security-next tree, or would you like to wait for linus to pull it into his tree
<tgardner> jjohansen, I'd prefer from Linus' tree
<tgardner> I thought it had already been merged ?
<jjohansen> tgardner: hrmm, not last I checked, james sent the request, but I didn't see it in this mornings pull
 * jjohansen repulls
<tgardner> jjohansen, the email I forwarded _was_ the merge commit (I think)
<jjohansen> tgardner: hrmm, /me is rechecking maybe I did the wrong branch
<jjohansen> tgardner: hrmmm, okay it is there. I'll rework the pull request to linus.  You want me to do a straight up rebase dropping the sauce patches, or do you want the reverts, and you can do the rebase
<tgardner> jjohansen, send the reverts and I'll take care of the cleanup
<jjohansen> tgardner: ack
<cking> mjg59, "pcie_aspm=force" seems to have regressed - it seems that in cases where the FADT declares the system doesn't support PCIe ASPM and force is used we now get ASPM disabled whereas before at least some were enabled (depending on the original firmware settings)
<tgardner> cking, is this in reference to Bug #961482
<ubot2`> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed] https://launchpad.net/bugs/961482
<cking> tgardner, nope, more like: http://ubuntuforums.org/showthread.php?t=1865577&page=130#post11771228
<mjg59> cking: force is enabling ASPM even though we shouldn't be touching it. The FADT then asks us to clear the state.
<mjg59> So I guess I can see that. I'd expect you to be able to change it via the policy setting afterwards, though?
<cking> mjg59, urm, what do you mean by policy setting?
<mjg59> powersave, performance and so on
<cking> ah, I suspect so, I've not got any H/W to try this on, but it's worth giving that a spin - makes sense
<cking> mjg59, so basically, this isn't a regression, the outcome is now that the kernel is doing what the firmware is telling it to do :-/
<mjg59> It's a change in behaviour
<mjg59> We could argue over whether it's a regression or not
<cking> I suppose it depends on what the semantics of "force" really mean
<cking> mjg59, perhaps there should be an extra pcie_aspm flag to forcefully override the FADT's suggestion to clear the state - since there are (many) occasions where the firmware gets this wrong. bah, BIOS vendors
<lamont> smb: [   74.247504] Dropped by process_register_request@1251
<lamont> very consistently
<mjg59> cking: Ok, I guess pcie_clear_aspm could just have an if (aspm_force); return added to it
<cking> mjg59, i.e.
<cking> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
<cking> index 24f049e..4af8371 100644
<cking> --- a/drivers/pci/pcie/aspm.c
<cking> +++ b/drivers/pci/pcie/aspm.c
<cking> @@ -783,6 +783,8 @@ void pcie_clear_aspm(struct pci_bus *bus)
<cking>  {
<cking>         struct pci_dev *child;
<cking>  
<cking> +       if (aspm_force)
<cking> +               return;
<cking>         /*
<cking>          * Clear any ASPM setup that the firmware has carried out on this bus
<cking>          */
<cking> I tried this earlier with a user who was seeing this issue and they reckon'd it didn't help, which is not what I expected
<mjg59> cking: Yeah
<smb> lamont, Ok, that narrows down things quite a bit (and for me the range of code I need to understand). Still a bit fuzzy (not as straight forward as one would hope) but I think I can work on that. 
<lamont> smb: any need for me to keep the test kernel, or can I roll forward to the now-current -20?
<lamont> smb: it's also quite possible that I have misconfigured the phone into doing something stupidly abusive
<mjg59> cking: Hm. Yeah, ok, it's not clear_aspm that's hte problem.
<cking> mjg59, ..the fact this didn't apparently work made me wonder if I was missing something stupid
<smb> lamont, You can roll on. If I needed more it would be a new kernel anyway.
<mjg59> But I don't see what is, in that case
<mjg59> The only time the FADT matters is if we got _OSC control
 * cking nods
<mjg59> I guess I could do with dmesg for the machine in question
<smb> lamont, I hope to be able to tell you about that (misconfiguration or what else) at some point
<cking> mjg59, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/962038/+attachment/2915461/+files/BootDmesg.txt
<ubot2`> Launchpad bug 962038 in linux "ASPM doesn't work completely on Asus Zenbook (regression from 3.1)" [Medium,In progress]
<brendand> smb - i have an interesting find on bug 960311
<ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [High,Incomplete] https://launchpad.net/bugs/960311
<brendand> smb - if i reboot the system then the problem never occurs, it only happens on first boot...
<cking> mjg59, which clearly has the FADT disabling PCIe ASPM
<mjg59> cking: Yeah, so it must be going through the clear path
<mjg59> cking: So I'd expect the return patch to work
<tgardner> ppisati, which dkms package is having problems building on a ti-omap4 system ?
<smb> brendand, Hm, ok. That somehow open up the possibilities about how long this problem exists. If the machine got only rebooted most of the time it could actually have been around for a while
<tgardner> smb, firmware issue ?
<lamont> 124 second boot times suck
<brendand> smb - i think we will just update the firmware and if the problem still exists we'll have to take it from there
<smb> tgardner, Probably. At least the kernel message points there. 
<cking> mjg59, I'll double check with the user - I can't comprehend why its not working, I was falling back to the "maybe I missed something obvious" mode
<smb> brendand, Ok. Just for safety: this is the only machine of that make and model in the lab? There is no twin?
<tgardner> smb, hmm, I was thinking it was a bnx2x, but its tg3
<brendand> smb - no. we might have something with the same nic though. i'll have a look
<smb> tgardner, Right, and somehow it seems to be able to handle the pxeboot xfer but a few minutes after it is brought up it seems to vanish. There seemed some life sign of the second interface after that. Which I also noted in the bug. Not sure that is really alive and its only the first one on the bus
<brendand> smb - yeah, seems like a common one
<brendand> smb - second nic is a different make (intel)
<smb> brendand, I believe to have seen two tg3 instances
<bjf> ppisati: there are cross build instructions on: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<smb> tg3 0000:01:00.0: eth0: Tigon3 [partno(BCM95722) rev a200] (PCI Express) MAC address 00:26:b9:53:cb:71
<smb> tg3 0000:02:00.0: eth1: Tigon3 [partno(BCM95722) rev a200] (PCI Express) MAC address 00:26:b9:53:cb:72
<bjf> ppisati: if yours are more complete, i'd suggest just adding a pointer on that page to your writeup
<brendand> smb, can the same component have two ports?
<smb> brendand, rather two instances (the pci bus address is different too)
<smb> but motherboards can have two builtin NICS
<tgardner> brendand, the bug report needs an 'apport-collect 960311' so we can see exactly what is installed.
<tgardner> ppisati, never mind. I'm reading the bug report.
<henrix> tgardner: brendand: could this tg3 issue be related with bug #961239 ?
<ubot2`> Launchpad bug 961239 in linux "Broadcom NIC (tg3) not working with DMA errors" [Medium,Incomplete] https://launchpad.net/bugs/961239
<henrix> in this bug, there are also 2 tg3 cards + 1 usb
<brendand> tgardner, is there a problem with apport-collect on servers?
<cking> mjg59, user has verified it worked - they didn't test it correctly, I will pop that patch out today once I've unwound my TODO list
<tgardner> brendand, heck if I know
<brendand> things just hanging...
<mjg59> cking: Great, thanks
<ppisati> bjf: i'll add a pointer there too
<tgardner> brendand, well, at least get the output of 'lspci -vvnn' attached.
<bjf> ppisati: remove the duplication on that page as well
<ppisati> bjf: which duplication?
<bjf> ppisati: on the page i pointed you at. if you add a pointer to your new wiki page, remove the duplication on "BuildYourOwnKernel" dealing with the info on your new page
<ppisati> k
<brendand> tgardner, lspci is attached now
<cking> bah, why does git garbage collection bite me when I least want it to
<ppisati> tgardner: actually all the releases are affected by this problem
<ppisati> tgardner: since no linux-headers pkg in the ARM case prvided linux-headers
<tgardner> ppisati, I'm still trying to wrap my head around what Provides: means in this case.
<ppisati> tgardner: i think it says 'we fulfill linux-headers' meta package
<jjohansen> tgardner, apw: are we still build aufs for precise?
<tgardner> jjohansen, yep
<jjohansen> tgardner: okay, it has a conflict with the umode_t that 3.4 apparmor pulls in, I can either patch aufs, or the apparmor patches
<tgardner> jjohansen, fix aufs. I'd rather AA was a close to upstream as possible
<jjohansen> tgardner: okay
<apw> jjohansen, right if aufs is wrong we should fix that, indeed if you get me a patch you think fixes it i'll check and see if aufs has it and we might update
<jjohansen> apw: patch is in the pull-request I just sent, the failure is introduced by a patch that is pulled in as part of the 3.4 apparmor rebase.  aufs isn't wrong its just al viro changed the parameters to security_path_chmod a little bit
<apw> jjohansen, sounds good
<tgardner> apw, you gonna handle jjohansen's AA pull request?
<kees> ogasawara: woohoo! thanks :)
<bandit5432> any one having optical drive problems with 3.3?
<apw> tgardner-lunch, yep will do
<bjf> jjohansen: you going to uds?
<jjohansen> bjf: yep
<jjohansen> bjf: /me needs to book yet, just trying to get beta2 tasks out of the way first
<bjf> jjohansen: ack, i have you down for roomie
<jjohansen> bjf: sounds good
 * apw bails for the pub
<cking> jsalisbury, thanks for your testing - got me the data I required.
<jsalisbury> cking, no problem.  Anytime ;-)
 * cking -> EOD
<jwi> jsalisbury: for bug 961482, have a look at 'PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled'; https://lkml.org/lkml/2012/3/19/232
<ubot2`> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed] https://launchpad.net/bugs/961482
<jsalisbury> jwi, thanks! I'll take a look
<jsalisbury> jwi, hmm, interesting.
<jsalisbury> jwi, I'll built a test kernel with that commit reverted
 * tgardner is EOD
<skaet> apw, ogasawara - https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-boot is slated for beta-2,  is it done?
<hggdh> msg sconklin there still?
<sconklin> hggdh: yes
<hggdh> heh
<hggdh> sconklin: when you ran cobbler-ubuntu-import did you restart cobbler?
<sconklin> no
<hggdh> hum. I ran it on ours, and the TFTP directory was again permission-hosed
<sconklin> well, yes I did, but I was able to bootstrap a system before I did. restarted it later for another reason
<hggdh> OK, good enough -- it worked on the bootstrap. Weird
<sconklin> hggdh: that's odd, I was able to build a system immediately after the import
<hggdh> extremely odd
<hggdh> sconklin: are you using the sytem's TFTP server, or Cobbler's?
<sconklin> hggdh: I don't know, I didn;t install it
<hggdh> oh, this is in magners. I will check
<hggdh> darn! also using tftpd-hda
#ubuntu-kernel 2012-03-23
<cking> yawn
 * smb agrees to yawn
<cking> smb, hrm, has mumble died again
<smb> cking, Somewhere. Not sure here or there
<smb> At least you seemed to have gone silent all of a sudden
<cking> ugh, let me kick it on my end
<smb> But taht could be me or you
<cking> or both ;-)
<smb> true :)
<smb> Now we have to wait for a third person to join
<cking> i'm getting connection refused now
<cking> ah, now back in
<apw> smb, is it safe to update today?
<smb> apw, No idea, I decided (oh well just not did) against it
<apw> ahh well, will give it a go, this is supposed to be B2 after all
<smb> its friday, what can possibly go wrong...
<apw> indeed
<apw> another shiney kernel yay
 * cking updated and it works fine 
<apw> cking, then there is hope
<apw> get any new unity features today ?  pretty sure we are expecting some
<smb> apw, So sad we don't have new kernel features every Friday... :-P
<apw> i claim landing them weds so that everything every
<apw> body lands on a thursday is out of date, is better
<apw> .quit
<ppisati> apw: actually the stuff tim pushed covered only tools/
<apw> ppisati, yeah indeed.  those patches i do not recognise
<apw> ppisati, though they are as invasive as an invasive thing on invasive juice
<ppisati> :)
<ppisati> you mean the two i posted on people?
<apw> ppisati, yes
<apw> ppisati, it affects the kernel build rather than the packaging, so it is more invasive
<ppisati> apw: well, but it seems they do what they advertise
<ppisati> apw: the real problem is that i can't reproduce the breakage in chroot anymore
<apw> ppisati, those wern't the ones which tiggered the breakage, they were all changes to the packaging
<ppisati> apw: they were, the secondo one was reverted in O by Tim due to breakage
<ppisati> apw: 9b1520dfc90d3c7f6b21773600a1d48ed85cb336
<ppisati> apw: "Breaks cross compile in Oneiric x86 chroots."
<apw> hmm and are they the same now
<ppisati> apw: had to do some modifications to the first one to make it apply
<ppisati> apw: but the funny thing is that, if i revert the revert in O
<ppisati> apw: kernel builds fine
<ppisati> door bell, brb
<apw> ppisati, odd indeed.  perhaps the chroots are better now
<apw> we did use to use external compilers for this, outside the chroots from code saucery, and now we have proper packages from linaro ... so 
<apw> ppisati, and i note we left in the intrusive part ... so it can't have been tooo annoying else we'd have noticed
<apw> so ... perhaps its time to consider wacking them back on, and let us find out again if its broken
<ppisati> i'm able to cross compile in a P/amd64 chroot, armhf fails (but that's a qemu issue)
 * ppisati -> lunch
 * apw wanders to lunch
<tgardner> cking, re: '[PATCH] ACPI, APEI, fix ERST table size checking' - have you noticed cases where those 2 tables are now different sizes, e.g., with UEFI ?
<cking> tgardner, not that I know of
<cking> tgardner, but I need to double check now that you've made me wonder
<cking> but it is more to do with I need to check ACPI 5
<tgardner> cking, its definitely a righteous fix
<cking> but it should make no difference since those structs are the same size
<cking> aka we got lucky it worked
<tgardner> indeed
<cking> tgardner, no difference in ACPI 5 either (which is kinda expected)
 * cking gets on the phone to whine about his dead laptop, wish me luck
<josepht> cking: good luck indeed :)
<cking> like being lost in a twisty maze w/o a map
 * apw cannot believe how warm it is here
 * smb sweats it
 * ppisati notes the weather indicator crashed
<smb> Probably never tested to display more than 19Â°C...
<ppisati> could be
<ppisati> btw, how one is supposed to restart a crashed indicator?
<ppisati> just relaunch it?
<smb> be a good citizen a report a bug?
<ppisati> 21C btw
<smb> 25C! ok... I think the sun reached the sensor...
<ppisati> :)
<smb> actually not but it might be a bit sheltered out there on the balcony
<ogasawara> smb: has anyone approached you about some LVM and MD memory leak issue?
<smb> ogasawara, nope
<smb> Well you, now sort of
<ogasawara> smb: hrm, sabdfl pinged me about and said Daviey had the details so was wondering if he may have pinged you
<ogasawara> smb: I'm just trying to figure out what the actual issue is
<tgardner> ogasawara, apw mentioned that he was running a 32 bit kernel on a platform with gobs of RAM
<smb> tgardner, Oh maybe thats all the same
<tgardner> and having issues because his 6 core CPU didn't support all of the CPUs
<apw> ogasawara, yes Daviey tallked to me
<apw> ogasawara, i am thinking about it, should be getting access to the box shortly
<ogasawara> apw: ack.  is there a bug filed?
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/962992
<ubot2`> Launchpad bug 962992 in linux "OOM when using a large amount of RAM, on i386/smp, when high disk IO" [Undecided,Confirmed]
<apw> basically the machine is way over spec to work well with 32bit
<apw> i am about to writ eit up and put it in the bug
<ogasawara> apw: ok thanks
<ogasawara> whoa, 32 gigs of ram?!
 * smb already had erased that from his head (that it initially talked about lvm/md)
<apw> ogasawara, 42
<ogasawara> whoa++
<apw> yeah, no way i would expect that machine to work on 32bit, but the failure more is catasrophic
<apw> so i am thinking we'll do something to mitigate it like drop the end of ram or something
<cking> the e820 table is eye-popping on that bug
<smb> cking, Yeah I think that makes the problem even worse on machines that are able to handle that much ram... or its something else
<smb> but on my server board the lowmem is not even enough to run memtest
<smb> (a huge chunk taken away by bios tables)
<cking> BIOS-e820: 0000000100000000 - 0000000c40000000 (usable) - that's something you don't see everyday
<apw> tgardner, hmm that isci.ko thing, if its isci.ko then that is a real scsi disk controller, and that is not in d-i
<apw> apw@dm$ find /lib/modules/`uname -r` -name isci.ko
<apw> /lib/modules/3.2.0-20-generic/kernel/drivers/scsi/isci/isci.ko
<apw> apw@dm$ git grep isci.ko -- debian.master/d-i
<apw> apw@dm$ 
<tgardner> apw, agreed, but its not a HW driver
<apw> tgardner, i think isci is a h/w driver:
<apw>         tristate "Intel(R) C600 Series Chipset SAS Controller"
<apw>           This driver supports the 6Gb/s SAS capabilities of the storage
<tgardner> apw, hmm, maybe you're right. drivers/scsi/isci/init.c
<tgardner> it is doing a PCI register
<apw> yeah i think its some new thing, that they have (stupidly) named very similarly to many other utterly different things
<tgardner> apw, ok< i had a patch to add it to d-i. I'll ppush it shortly.
<tgardner> I might as well add the firmware to the linux-firmware udeb at the same time
<apw> yeah... bound to need the firmware ...
<bryceh> -20 failed to boot for me just now; want a bug report or is this already known?
<tgardner> bryceh, ASPM ?
<tgardner> jsalisbury, ^^
<jsalisbury> bryceh, know issue: bug 961482
<ubot2`> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed] https://launchpad.net/bugs/961482
<jsalisbury> bryceh, There is a test kernel in the bug, or you may be able to boot with: pcie_aspm=force
<Sarvatt> bryceh: oh you skipped -19?
<bryceh> Sarvatt, yeah this is my main desktop so I don't update it as often as the rest of my hw
<bryceh> jsalisbury, thanks that could  be it.  I have several other systems all running 19 happily (and being upgraded to 20 now), so guessing the desktop is unusual in some way.
<lamont> smb: any updates?
<smb> lamont, Err, no. Our chat ended in a way that led me to assume you wanted to check on the phone config ... So I did not do anything on it, yet
<smb> lamont, If you want another debug kernel, please type "yes" <enter> now. ;)
<lamont> ah.  I dug into it some and concluded that it's quite possible that the fine folks at cisco are compliant and that the registration may not come from 5060
<bryceh> rebooting to test kernel, brb
<lamont> that is, registering is one thing, where to send the reply is found in the UDP headers
<lamont> yes
<lamont> :-p
<smb> lamont, :) Ok, well I agree that you can register from another port. But then you should not state otherwise in the headers
<smb> lamont, Given that it is past b-o-c, I'll get back to it on Monday
<lamont> smb: I was meaning that one might actually register using a separate socket (and hence source address) than the socket that one has open to receive SIP traffic
<lamont> but dunno
<lamont> the biggest challenge is that nearly everyone uses 7640s with a cisco controller, rather than asterisk, as the SIP provider
<lamont> making google not really my friend when it comes to finding answers
<smb> lamont, Its hard to say. Just gathered from the difference between working and non-working example and the rought hinting about some expectation handling on addresses goes wrong
<cking> rats, the ethernet cable popped out of the socket 95% the way through a 1 hour test and I lost my data capture from my multimeter. 
<apw> cking, that sucks
 * apw thinks its time to go and enjoy some british fare ... curry and beer
<apw> laters
<arges> apw, have a good one
<smoser> smb, you're on friday night?
<smb> smoser, not really but the computer is while I am enyoing tv and a bit of wine. :)
<smoser> smb, well, after you've had another glass of wine, you can have some fun looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/963420
<ubot2`> Launchpad bug 963420 in linux "https download performance significantly worse in precise than lucid" [Undecided,New]
<tgardner> smoser, cjwatson just uploaded a new ssl that (I think) takes advantage of HW encryption support. I wonder if that'll make a difference.
<tgardner> the other difference between lucid and precise is that the HW encryption routines are built-in in precise.
<smoser> tgardner, but you wouldn't think that was there in lucid.
<tgardner> well, these are virtual instances, right ?
<smoser> ie, precise shouldnt need that to catch up
<smoser> (yes, lots could be going on i dont know about)
<smoser> but i can't seem to make precise win
<tgardner> actually, I don't know for sure. I'm just thinking with my fingers.
<smoser> yeah, i probalby missed the your intent above.
<smoser> but the key thing is... i just can't seem to get precise faster than lucid with https
<smoser> across multiple instances across multiple days... lucid always wins.
<smoser> but with http... they both hit ~ 80M/s even.
<tgardner> smoser, well, I'd be curious to know what crypto modules are loaded. that seems to be the root of the problem, right ?
<smoser> and, i noted in the bug... on EC2, they seem similar.
<smoser> i have no idea, tgardner 
<smoser> you're welcome to my instances if you'd like
<smoser> to poke around.
<smoser> ive got to run her ein a minute though
<tgardner> smoser, as do I. when you get a chance just drop it in the bug report
<smoser> you have canonistack creds ?
<smoser> just launch some instances
<smoser> i got to run, so monday probably for me.
<tgardner> maybe this weekend...
 * tgardner -> EOD
#ubuntu-kernel 2012-03-24
<bullgard4> [Ubuntu 11.10 GNOME Shell 3.2.2.1] Super key > Applications > System tools > Power statistics > Prozessor > Wake-up processes lists 2 types of wakeup processes: i.) Symbol is a rhombus, ii.) Symbol is a gear. What is the name of these two types?
<smoser> smb`, tgardner just fyi, put some new comments in bug 963420.
<ubot2`> Launchpad bug 963420 in wget "https download performance significantly worse in precise than lucid" [Medium,Confirmed] https://launchpad.net/bugs/963420
<smoser> my kernel assesment was probably wrong.
<tgardner> smoser, cool, thanks for the note.
#ubuntu-kernel 2012-03-25
<jdstrand> jjohansen: fyi, I assigned bug 963685 for investigation as a potential kernel hardening patch (I'm guessing for Q)
<ubot2> Launchpad bug 963685 in linux "Please consider backporting killable request_module() patchset" [Undecided,Triaged] https://launchpad.net/bugs/963685
<tgardner> jdstrand, I plucked 'em for precise
 * kees â¥ tetsuo
<scientes> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-precise/
<scientes> do you guys have the config files?
<scientes> so i dont have to download the whole thing to build from git 
<JanC> scientes: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-precise/0003-default-configs.patch might be useful?
<scientes> nah, i just realized that they just use oldconfig  =y
<scientes> hmm, guess not, the udl driver isn't here
<scientes> in the gdaily git build
<scientes> DisplayLink (DRM_UDL) [N/m/?] (NEW) *
<scientes> that should be built
<scientes> but i dont see it after downloading that
<scientes> what do i file to get that built?
<scientes> its not building cause it can only be done as a module
#ubuntu-kernel 2013-03-18
<ppisati> moin
 * apw waves ...
<ppisati> apw: moin
<smb> moin
<apw> ppisati, moin
<ppisati> brb
<czajkowski> would anyone be able to share any light on why I do an update on Raring, it's breaking my virtual Box so I have to kick it each time via http://pastebin.ubuntu.com/5624797/
<smb> czajkowski, It looks like whatever vboxdrv does, it has broken or got out of sync with DKMS. Maybe if you re-create the initrd you get around it for now, but likely the next kernel update with a newer abi number breaks it again.
<czajkowski> smb: yup as soon as update the setup each time I cna get the virtual box up and running, just kinda annoying 
<czajkowski> as I left it wrking on Friday, do an update this morning and it's broken 
<smb> Primarily it should be dkms that re-compiles the kernel modules because that is triggered automatically when a new kernel is installed and also should update the initrd. So when dkms got broken in some way the experience won't be nice. But I do not use virtualbox that much, so I don't know the latest status there or how any scripts have changed.
<czajkowski> smb: cheers
<tjaalton> hey, we need 20afbda209d708 from upstream to fix a regression with the i915 driver on stable series
<tjaalton> bug 1156310 and friends
<ubot2> Launchpad bug 1156310 in xserver-xorg-video-intel (Ubuntu) "xrandr detects too many displays" [Undecided,Confirmed] https://launchpad.net/bugs/1156310
<lool> happy to test a kernel for LP #1156310
<ubot2> Launchpad bug 1156310 in xserver-xorg-video-intel (Ubuntu) "xrandr detects too many displays" [High,Confirmed] https://launchpad.net/bugs/1156310
<tjaalton> I could build one
<lool> happy if you do  :-)
<lool> I have a workaround
<lool> just trying to speed up the inclusion of the speed in any way I can
<tjaalton> huh, doesn't apply as-is
<apw> tjaalton, isn't that one in stable now ?
<tjaalton> apw: let me check
<tjaalton> apw: I don't see it there?
<apw> tjaalton, i thought it saw it in 3.8.3 ... hmm
<tjaalton> no that's 52d7eceda which then needs this additional commit or gen4 is busted :)
 * ogasawara back in 20
<tjaalton> lool: ok, kernel built and available at http://people.canonical.com/~tjaalton/lool
<tjaalton> hope you have amd64 installed
<tjaalton> can't reproduce the problem on my old laptop
<tjaalton> lool: new link http://people.canonical.com/~tjaalton/lp1156310
<rsalveti> ogasawara: guess we need to mark https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-phablet-kernel-maintenance to a series
<rsalveti> the work would land for s-series, so I guess it should be fine to target to that
<rsalveti> and let the milestone to the one it's already assigned
<ogasawara> rsalveti: ack, will do
<rsalveti> things are kind of under discussion atm, as the series x milestone usage is still not clear for the touch based work items
<rsalveti> but guess that for it to show at status it needs at least a valid series
<rsalveti> ogasawara: cool, thanks
<rtg_> tjaalton, re: bug #1156310. Daniel Vetter is suggesting to revert a couple of 3.8.3 stable patches. Are they the root of lool's problems ?
<ubot2> Launchpad bug 1156310 in xserver-xorg-video-intel (Ubuntu) "xrandr detects too many displays" [Undecided,Incomplete] https://launchpad.net/bugs/1156310
<rtg_> tjaalton, https://lkml.org/lkml/2013/3/18/180
<lool> tjaalton: just grabbed installed your kernels will reboot in a minute
<lool> unless you tell me otherwise  :)
<tjaalton> yeah reverting makes sense
<rtg_> tjaalton, ok, I'll push that out and upload today.
<tjaalton> there's also 202adf4b9f5957 to fix bug 1135668
<ubot2> Launchpad bug 1135668 in xserver-xorg-video-intel (Ubuntu) "Intel graphics fails when bringing monitor out of sleep" [Undecided,In progress] https://launchpad.net/bugs/1135668
<rtg_> tjaalton, is that a different bug ?
<tjaalton> yes
<tjaalton> just wondering if you could add that there :)
<rtg_> tjaalton, I mean, is that bug the result of these 2 patches ?
<tjaalton> no, older, fixed in 3.9rc now
<tjaalton> feel free to add it after the revert & upload
<tjaalton> no rush
<rtg_> tjaalton, ack
<tjaalton> another one, 21ad833075801a7 should fix bug 1116587
<ubot2> Launchpad bug 1116587 in linux (Ubuntu) "Lenovo T400: With external monitor the system is rarely working for more than 10 minutes" [Undecided,In progress] https://launchpad.net/bugs/1116587
<rtg_> tjaalton, you're just full of patches today :)
<tjaalton> nah, just sick of my todo-list :)
<tjaalton> as it looks we're doing raring these became a bit more important
<rtg_> it certainly does look like we're doing raring
<tjaalton> right..
<lool> tjaalton: Your kernel fixes the bug for me
<lool> tjaalton: xrandr output now correct and lightdm showing up in native res again
<lool> rtg_: ^
<rtg_> lool, ack
<tjaalton> lool: thanks for testing, but we'll revert the patches anyway
<lool> tjaalton: BTW system crashed this morning with Ubuntu -13; seemed to be possibly related to graphics
<lool> as in, system hung after some heavy browser rendering
<lool> didn't happen in months
<tjaalton> could be the same
<tjaalton> try to break it with the updated kernel
<rtg_> tjaalton, any other goodies on your todo list  ?
<tjaalton> heh, not yet
<tjaalton> I'll ask ickle
<rtg_> jsalisbury, I think bug #1156548 is likely a duplicate of bug #1156310 (which appears to cause multiple issues)
<ubot2> Launchpad bug 1156548 in linux (Ubuntu) "With Kernel 3.8.0-13 Intel GPU/screen size not recognized, works correctly with old 3.8.0-12" [Critical,Incomplete] https://launchpad.net/bugs/1156548
<ubot2> Launchpad bug 1156310 in linux (Ubuntu Raring) "xrandr detects too many displays" [Medium,Fix committed] https://launchpad.net/bugs/1156310
<jsalisbury> rtg_, ack.  I'll request the test kernel in bug 1156310 to be testing in 1156548
<ubot2> Launchpad bug 1156310 in linux (Ubuntu Raring) "xrandr detects too many displays" [Medium,Fix committed] https://launchpad.net/bugs/1156310
<jsalisbury> rtg_, thanks
<rtg_> jsalisbury, how about building raring master-next (HEAD==874b4285c51a2a77486f0556d513fee52a2587db) and have bug reporters test that ?
<jsalisbury> rtg_, even better.  I'll do that.
<jsalisbury> rtg_, I forget, which repo has the master-next branch?  It doesn't seem to be in git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
<rtg_> jsalisbury, 'git branch -a'
<jsalisbury> rtg_, I only see:
<jsalisbury> jsalisbury@gomeisa:~/bugs/lp1156548/ubuntu-raring$ git branch -a
<jsalisbury> * master
<jsalisbury>   remotes/origin/HEAD -> origin/master
<jsalisbury>   remotes/origin/master
<infinity> ikepanhc: Do I get an upload for https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1153649 ?
<ubot2> Launchpad bug 1153649 in linux-armadaxp "linux-armadaxp: <version to be filled> -proposed tracker" [Medium,In progress]
<rtg_> jsalisbury, re-fetch, e.g., git fetch git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
<infinity> zequence / apw: lowlatency for quantal is behind too.
<jsalisbury> rtg_, Still don't see it.  Let me try on tangerine
<apw> infinity, hmmm that might be my fault i guess
<apw> infinity, or has it been rev'd
<apw> in the last few days
<infinity> apw: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1153652
<ubot2> Launchpad bug 1153652 in kernel-sru-workflow "linux-lowlatency: 3.5.0-26.27 -proposed tracker" [Medium,In progress]
<infinity> apw: That's not been a few days, no... But the bug's stalled on prepare-package.  I assume it never landed in the PPA?
<ikepanhc> infinity: no, I dont think we shall upload it before we find out the root cause for regression descript in bug 1133586
<ubot2> Launchpad bug 1133586 in linux-armadaxp (Ubuntu Quantal) "linux-armadaxp: 3.5.0-1610.14 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1133586
<apw> infinity, ok will poke 
<jsalisbury> rtg_, hmm.  I clone my tree with: git clone --reference /usr3/ubuntu/ubuntu-raring.git/ /usr3/ubuntu/ubuntu-raring.git/ ubuntu-raring  
<ikepanhc> infinity: find out the update https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1133586/comments/14
<infinity> ikepanhc: That looks like bad hardware, not a regression.
<ubot2> Launchpad bug 1133586 in linux-armadaxp "linux-armadaxp: 3.5.0-1610.14 -proposed tracker" [Medium,In progress]
<jsalisbury> rtg_, maybe I need to clone a different way
<rtg_> jsalisbury, yeah, wrong origin
<ikepanhc> infinity: yes, agree, will upload soon
<rtg_> jsalisbury, git clone --reference /usr3/ubuntu/ubuntu-raring.git git://kernel.ubuntu.com/ubuntu/ubuntu-rearing.git
<jsalisbury> rtg_, great.  thanks!
<rtg_> except you gatta spell it right
<jsalisbury> heh
<zequence> apw: Seems like I forgot to update the bug description after updating the package. It's in ppa:ubuntustudio-kernel/linux-lowlatency-sru
<jsalisbury> rtg_, that did the trick.  thanks!
<rtg_> jsalisbury, np
<apw> zequence, thanks will check
<infinity> jjohansen: Any progress on 1145234?
<jjohansen> infinity: progress yes I think so, but I'm not done with it
<jjohansen> infinity: the backport was good, unfortunately, its some of the logic in between that is missing
<infinity> jjohansen: Mmkay.  Well, I guess I don't have to feel bad that your security update is being held up by your bug. ;)
<jjohansen> yeah no one to blame but me
 * rtg_ -> lunch
 * rtg_ -> EOD
#ubuntu-kernel 2013-03-19
<ppisati> moin
<apw> moin
 * ppisati needs a reboot
<ppisati> brb
 * cking waves to apw
 * apw waves generally ...
<apw> hi cking 
<smb> hi apw
<apw> smb, yo
<ppisati> apw: can yo point me to the script you use for the config review?
<ppisati> apw: i lnow you told me in the past, but i keep forgetting... :P
<apw> ppisati, sure, let me check it is all committed as it is first, as i have been mangling it
<ppisati> apw: k
<apw> ppisati, what you going to review anything fun
<apw> which reminds me i have some n7 shit to do ... sigh
<ppisati> apw: the multiplatform kernel
<apw> ahh ... fun then
<ppisati> apw: and i've another arch *almost* pending entrance... sigh...
<apw> ppisati, into the multi-arch, or as a flavour
<ppisati> apw: in multi arch
<ppisati> apw: but i still miss some patches && an official ack
<ppisati> brb
<gerardo> buenos dias
<gerardo> alguien que hable espaÃ±ol
<gerardo> necesito soporte para instalar tarjeta wifi en pc canaima 3.1
 * ogasawara back in 20
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
 * rtg -> back in 10
<jsalisbury> ##    
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
 * ppisati goes out for a bit
<apw> heh one blinks and ... it is gone
<cking> blinkin' quick
<rtg> apw, get you Inet issues sorted ?
<apw> rtg, i have half way relaible internet, it is _not_ quick, that comes in a couple of weeks
<apw> rtg, i am on 1/4 what i normally am, rather than the 8x i have ordered
<apw> but hey ... at least i can work, not sure mumble will do the trick
<apw> plus i have yet to find my mic :)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 26th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<rtg> apw, its large and has the word 'Blue' on it
 * rtg -> lunch
 * rtg -> EOD
#ubuntu-kernel 2013-03-20
<ppisati> moin
 * apw struggles on with pants internet
 * apw struggles on with pants internet
 * smb struggles with pant sleepiness
<RAOF> Better than pantsless internet!
<smb> RAOF, As long as I don't have to see that. :-)
<cking> smb 96433f6ee49032d7a8bda76de2b05cfde2914354
 * cking offers apw some of his spare internet connection capacity
<apw> RAOF, i would settle for using it pantless if it went faster
<ppisati> brb
 * henrix reboots
<jpds> Hey, can someone tell me if linux-image-lts-quantal / so stops being updated for precise after the next LTS is released?
<apw> jpds, i believe that is the plan, people there will be updated to the TT kernel on PP and can stay there
<jpds> apw: So there'll be a linux-image-lts-t kernel for precise?
<apw> jpds, that is my understanding indeed, that we offer an 14.04 kernel as the hwe kernel on 12.04, and the other lts kernels will roll to that one
<jpds> apw: What about people on precise, that want to enable hardware that's enabled... after T?
<apw> jpds, they need to be on T
<BenC> rtg, apw: You're going to want commit 829a337c48b835c322e625e390b0bb07769e913b from my ppc tree
<BenC> UBUNTU: SAUCE: 8250: Wrap ACPI calls with ifdefs for non-ACPI systems
<BenC> All the commits you cherry picked trashed that driver for anything non-x86
<BenC> infinity: Fixed linux-ppc is waiting to build
<rtg> BenC, I had some trouble getting that to build on armhf (so I turned off 8250 for armhf IIRC). Have you sent that patch upstream yet ?
<BenC> rtg: No, I'm hoping the person that keeps cherry picking for stable kernels will do it for me eventually :)
<rtg> I guess it fell off my todo list.
<rtg> BenC, see 053fac36b1d9f76adde96a2f731965aaab3c632b in Linus repo. I'll see about getting that fixed in Raring
 * henrix -> lunch
<apw> rtg, thanks
<rtg> apw, uh, for what ?
<apw> handling BenC's issue
<rtg> ah, no problem
<BenC> rtg: that fix does itâ¦I'll disappear my commit from ppc branch next time I sync to ubuntu/master
<rtg> build testing armhf right now
<apw> rtg, just pushed a bit more fixing for the linaro -> nexus7 rename
<rtg> apw, oh, did I push that without testing ? I got distracted I think before it was finished
<tjaalton> hum, ideas why i915.ko built from a dkms package is not loaded on haswell, but i915_hsw.ko
<apw> rtg no i think what you pushed would build fine, it is reconfiguration and the like which needed more tweaks
<rtg> apw, cool, thanks.
<rtg> tjaalton, PCI IDs ?
<apw> tjaalton, well i think it would load both and whichever binds get sit ?
<apw> gets the device
<tjaalton> hmm right
<apw> tjaalton, also where is i915_hsw.ko, is that in updates/ or just in the normal place
<tjaalton> normal place
<apw> and the dkms where is that, updates ?
<tjaalton> yeah I see in dmesg that it's probably trying to load both
<tjaalton> yep
<apw> as i think i expect updates to be loaded first, but probe is async i think
<tjaalton> lspci shows i915 being used, but lsmod shows i915_hsw
<tjaalton> so I think lspci lies
<apw> so ... perhaps the dkms package should include an /etc/modprobe.d/stop-haswell.conf which blacklists i915_hsw.ko
<tjaalton> yep
<tjaalton> probably the cleanest way out of this
<apw> but that is a bit pants
<tjaalton> :)
<tjaalton> rtg: the dkms version supports all, _hsw only haswell. so the dkms package works for !HSW. anyway, blacklist it is then
<rtg> tjaalton, ack. Is this going to be your preferred solution for Haswell platforms ?
<tjaalton> rtg: until i915_hsw is rebased, but the dkms is needed right now
<rtg> tjaalton, so you're still gonna send a pull request for quantal eventually ?
<tjaalton> yeah I hope so :)
<rtg> k
<tjaalton> been fighting fires so didn't get to it yet
<rtg> tjaalton, my kid fights fires in the summer. it pays pretty well.
<tjaalton> hehe
<seiflotfy> guys
<seiflotfy> centrino 6300 on raring has a big issue with disconnecting then becoming unavailable
 * ogasawara back in 20
<jsalisbury> bjf, fyi, bug bots are broken again on cranberry due to an upgrade :-/
<bjf> jsalisbury, that's special
<ogra_> ppisati, so the plan is to leave the panda desktops as is and dont touch thzem at all
<ppisati> ogra_: then i'll sync up R/omap4 wrt to Q/omap4
<ppisati> rtg: ^
<rtg> ppisati, ack
<ogra_> yep
<ogra_> and then let it rot :)
<rtg> ppisati, ogra_: if omap4 is now only for the builders, then why bother with an omap4 in Raring ?
<ogra_> rtg, we want the community to still have builder options ... and (worse) still want to have them for dogfooding desktop stuff on arm
<ogra_> i would have gone with server images from mainline kernels ... 
<rtg> ogra_, can we still do that with the device tree kernel in raring ? I'd still like to rename it to something more generic.
<ppisati> ogra_: +1
<ppisati> rtg: doing it now
<ppisati> rtg: s/omap/multiarm/g
<ogra_> rtg, i dont care what you guys do as long as pvr still works for desktop 
<ogra_> well, s/i/they/ (whoever) :)
<rtg> ogra_, can you find the bit of build magic for the N4 kernel ? there has to be a bit more to it then just using arch/arm/configs/mako_defconfig
<ogra_> i have never built any official phablet image ... only ported to my own devices and they definitely use a cm_*_defconfig 
<ogra_> but i dont see a cm_mako_defconfig in the tree
<rtg> cm_x2xx_defconfig  cm_x300_defconfig
<ogra_> yep i see them
<ogra_> kernel/lge/mako/AndroidKernel.mk ...
<rtg> ogra_, looking at the git repo implies that mako_defconfig is in use 'cause that where some config options have been changed for the phablet image
<ogra_> did you try running a fresh repo sync ?
 * ogra_ doesnt really see where KERNEL_DEFCONFIG gets defined
<ogra_> aha device/lge/mako/BoardConfig.mk
<ogra_> yeah its mako_defconfig, you are right
<ogra_> rtg, so i suspect you have to mimic whatever kernel/lge/mako/AndroidKernel.mk does to get a proper config 
<ogra_> there seems to be a bunch of perl touching it 
<rtg> ogra_, that lge directory does not exist in git://phablet.ubuntu.com/CyanogenMod/lge-kernel-mako.git
<ogra_> weird, must be something repo does merge then
<ogra_> likely from CyanogenMod/android_device_lge_mako
<ogra_> thats whats defined in the top level manifest.xml here 
<ogra_> http://paste.ubuntu.com/5631532/
<ogra_> thats the AndroidKernel.mk in my tree
<rtg> ogra_, cool, thanks
<ogra_> line 14 and 15 look like they touch it 
<rtg> apw, git://kernel.ubuntu.com/ubuntu/ubuntu-nexus4.git - can you give me a hand and tell me why  config-check wants to run debian.master/config/enforce ? The N7 script is identical, yet I don't have that failure.
<rtg> apw, oh, well actually now I _do_ have the same failure. its part of your patch 'UBUNTU: [packaging] Rename from linaro to nexus7 -- part 2'
 * rtg -> lunch
<ppisati> rtg: could you refrain from touching R/master-next abi today?
 * ppisati -> workout
<ppisati> later
<cking> bah, ESTA and visas. what a pain
<ogra_> and visas ?
<ogra_> do you need both in the UK ?
<rtg> ppisati, why just the abi ?
 * henrix -> EOD
 * rtg -> EOD
<jbaron> q: i'm trying to build a kernel out of the git tree, and have noticed that a number of the firmware files are dropped - 
<jbaron> is there an easy way to figure out what I need to pull in from linux-firmware?
#ubuntu-kernel 2013-03-21
<ppisati> moin
<psino> Is there any fix equivalent to https://bugzilla.redhat.com/show_bug.cgi?id=914737 in the pipeline (or even already implemented?) for ubuntu?
<ubot2> bugzilla.redhat.com bug 914737 in kernel "Fedora 18 on EC2 kernel panic due to cgroups" [Unspecified,On_qa]
<smb> psino, When I look at the discussion on Xen-devel about the resulting patch it seems that at least the initial version got turned down. So right now that would mean no. Until there is an upstream fix for it and marked for stable.
<apw> one assumes the 'final' version once available will make it to us via that route
<smb> apw, Probably needs a reminder as that discussion was about a month ago...
<apw> smb, yeah probabally ... have fun :)
<psino> hmm. I heard there were at least one other patch proposed as a fix. if I recall correctly, it was turned down at least partly because it caused a minor performance regression on bare metal, but maybe other things as well.
<psino> so I assume if I'm being hit pretty badly by that bug right now, the suggested route is to build my own kernel with that patch or a similar one and see if it works for me until an official version comes out?
<smb> psino, Or even better try to make it working mostly with upstream changes and as soon as all parts are there make sure they go to upstream-stable. Probably also create a new lp bug for it since the one that is referenced in the redhat bugzilla seems closeed
 * smb just pinged Konrad as well to find out in parallel
<smb> psino, Are you still around?
<psino> smb: yes, on and off :)
<smb> psino, It sounds like upstream is waiting on someone to confirm that two patches will solve the issue you asked about. So I think either if you open a launchpad bug report and let me know, I could provide test kernels and we then can let them know. Or you could build your own and tell them directly
<psino> where do I find the two patches? its probably better if it can be fixed upstream, as it will benefit more people. does it take long from patches being applied upstream to new official ubuntu kernel builds are available?
<smb> psino, Oh, the feedback would go upstream in both cases. The main thread about it starts at: https://lkml.org/lkml/2013/2/28/568 one reply mentions the other part
<smb> After it goes upstream (with cc stable) it depends a bit. Our kernels are updated in about a three weekly cycle.
<psino> smb: ok, I'll have a look at the thread when I get some free time. thanks for your help so far :)
<smb> psino, np :)
<infinity> apw: Yo, vars.generic is uncleverly x86-specific.  Is there any point to abstracting to the point where one loses flexibility?
<apw> infinity, sorry ?
<apw> infinity, oh i see if we wanted to have an arm generic as well you mean
<infinity> apw: Yeah.
<infinity> apw: I think I've sort of sorted it with Paolo.
<infinity> apw: By arch-specifying all those bootloader deps.
<infinity> (ie: grub [i386 amd64 x32], flash-kernel [armhf arm64])
<infinity> Untested, but if that's being substituted into a master control file, then parsed by dpkg-gencontrol at build time, it should DTRT.
<apw> yeah i guess we have no choice other than to do that
<apw> as (i assume) we cannot have two Package: linux-image-generic stanzas with different arches 
<infinity> Definitely not.
<apw> infinity, vile, but ...
<infinity> Well, that's how debian/control and dpkg-gencontrol work.  Not all THAT vile, except that it sort of defeats the purpose of the vars.foo abstraction. :P
<infinity> Maybe that would be saner if it was extended to var.foo.$arch and pulled the right one based on DEB_HOST_ARCH
<infinity> Then the descriptions could actually change and such.
<apw> yeah that would be the other way, but then the control on the source would be 'wronger' than it is now
<apw> not that it is very right
<apw> right now
<infinity> Yeah, it's pretty wrong regardless.
<jbaron> hi - how do i figure out the dependency of a specific kernel on the linux-firmware package?
<jpds> jbaron: $ apt-cache rdepends linux-firmware
<jbaron> hmmm...there no dependency listed there on linux-generic
<jbaron> i think its really the other way around that I'm looking
<jbaron> for
<jbaron> i can do:
<jbaron> s linux-generic 
<jbaron> linux-generic
<jbaron>   Depends: linux-image-generic
<jbaron> sorry:
<jbaron> $ apt-cache depends linux-generic 
<jbaron> linux-generic
<jbaron>   Depends: linux-image-generic
<jbaron> $ apt-cache depends linux-image-generic
<jbaron> linux-image-generic
<jbaron>   Depends: linux-image-2.6.32-45-generic
<jbaron>   Depends: linux-firmware
<jbaron> and i think see that linux-generic depends on 'linux-firmware'
<jbaron> but i don't see a specific version ?
<jpds> jbaron: Does it need a specific version?
<jbaron> i would think so
<jbaron> maybe not - i'm not sure 
<jbaron> if the drivers update in the kernel - they'll need specific firmware versions
<infinity> jbaron: We don't force versions, no.
<infinity> jbaron: firmware is more tightly coupled with hardware than drivers.
<infinity> jbaron: Is there a specific problem you're trying to solve here, or just a curiosity?
<jbaron> yeah - i'm trying to re-build the ubuntu kernel out of the git tree
<jbaron> and i'm trying to figure out which firmware to include
<jbaron> since the firmware is dropped from the git tree
<infinity> apt-get install linux-firmware?
<infinity> Like, I'm not sure what you mean here. :P
<jbaron> right - but i want to make sure it matches up with the kernel I'm building
<infinity> They don't "match".
<jbaron> the drivers do request specific firmware files
<infinity> If you want the newest, get the linux-firmware from raring.
<jbaron> request_firmware()
<infinity> https://launchpad.net/ubuntu/+source/linux-firmware/1.104
<infinity> It's maintained outside the kernel tree.
<jbaron> if you look at the request_firmware() call in the kernel it asks for specific firmware files:
<jbaron> ie "BCM2033-FW.bin"
<jbaron> so maybe the linux-firmware pkg for a release keeps all the old ones ? 
<jbaron> (in the case the driver is updated)
<infinity> Yes, I'm aware of what request_firmware does.  I'm saying that there is no "matching" firmware for any specific kernel.  We ship the latest, according to what we need, and what bugs get filed to include new things.
<infinity> Some from linux-firmware.git, some from elsewhere occasionally.
<bjf> jbaron, which kernel tree are you building ?
<jbaron> quantal - I guess if i include all the firmware from linux-firmare i'll be safe
<bjf> jbaron, do you have quantal installed and you are just building your own quantal kernel?
<jbaron> yes
<bjf> jbaron, if so, you probably don't need to worry about firmware, build your kernel and try running it
<bjf> jbaron, the worse that can happen is that not everything works and you just boot up the previous kernel via grub
<jbaron> ok, thanks
<infinity> jbaron: I'm still not sure why you think you need to "include" firmware at all?
<infinity> jbaron: If you're on quantal and you have linux-firmware installed, you have the firmware.  You don't need it AGAIN in your kernel build.
<bjf> jbaron, if you don't mind me asking, why are you building your own kernel? just for the experience or for a particular issue?
<jbaron> ok, thanks guys, I was just trying to better understand how firmware updates work
<bryce> jsalisbury, #1156077 has a kernel patch from upstream that needs tested/integrated
<apw> bug #1156077
<ubot2> Launchpad bug 1156077 in linux (Ubuntu Raring) "Black screen when booting after a fresh install on chromebook" [High,In progress] https://launchpad.net/bugs/1156077
<jsalisbury> bryce, ack
#ubuntu-kernel 2013-03-22
<ppisati> moin
<mitya57> hi all, while trying to fix bug 1157421 I noticed that blktap-dkms depends on linux-headers-generic, which on 12.04.2 pulls in 3.2.x headers, not 3.5 headers
<ubot2> Launchpad bug 1157421 in blktap-dkms (Ubuntu Precise) "blktap-dkms version in 12.04.2 is not compatible with the 12.04.2 kernel" [High,Triaged] https://launchpad.net/bugs/1157421
<mitya57> my question is: what should I do if I want to make my package build against 3.5 headers?
<mitya57> I probably even want it to be 3.5 for those with kernel 3.5 and 3.2 for others
<amitk> smb: apw: is there a meta package I can install to get the latest mainline kernels from the mainline PPA? Or is it always a manual process?
<amitk> nouveau is horribly broken in 3.8
<amitk> and nvidia binary drivers too
<smb> amitk, afaik always manual
<amitk> smb: is it done on purpose? or did s
<amitk> oops
<amitk> smb: or was it just lack of time to do this?
<smb> amitk, No I suppose it is deliberate
<smb> amitk, Those are for testing not for constant use
<amitk> smb: -rc2 / -rc3 not fit for constant use?!!! You must be joking...
<amitk> ;)
<smb> amitk, you know I am never joking :-P
<smb> amitk, Would be good to find things to unbreak nouveau at least in the raring kernel
<AceLan> mitya57: man dkms and read BUILD_EXCLUSIVE_KERNEL=
<mitya57> AceLan: it would *build* against the exclusive kernel, I wondered what should I do with dependencies (which should be installed before building)
<mitya57> anyway jamespage sais that that dependency was not actually needed
<mitya57> *says
<amitk> smb: it must be some interaction between the latest unity and nouveau that breaks it, atleast on my desktop (bug 1154431)
<ubot2> Launchpad bug 1154431 in unity (Ubuntu) "Unity doesn't start up" [Undecided,Confirmed] https://launchpad.net/bugs/1154431
<smb> amitk, That isn't by chance some dual-monitor setup? Just asking because I had some hilarious effects with that on a laptop with ati graphics.
<smb> Otherwise maybe RAOF is interested (if he is not asleep by now)
<amitk> smb: I dare not even plugin my second monitor at this point. First X wouldn't start (at all), then unity wouldn't, now it crashes whenever I hit the windows key to bring up the dash (?)
<smb> quality...
<amitk> smb: to be fair, progress has been made, so i hope to have a useable desktop by release
 * cking grabs a screwdriver..
<smb> amitk, Yeah, there is always that hope. Just seems that there is quite a lot to cover. apw had a lot of fun with some older i915, I had the (older) ati fun and the cirrus gfx used by VMs by default has issues as well.
<ogra_> amitk, its all fine, we will ship a piece of duct tape along with the images so you can lock your win key  to not do that
<amitk> ogra_: :) Add Alt+Tab and the browser to that blacklist.
<ogra_> yeah, no prob :)
<ogra_> with ubuntu touch we have our own browser anyway now 
<amitk> ogra_: we do?
<ogra_> yep
<ogra_> the great thing is it cant do tabs ... one websire is enough for everyone !
<ogra_> *website
<amitk> ogra_: lol
<ogra_> so much less confusion when surfing :)
<ogra_> and indeed no bookmarks either, finally something that trains your brain
<amitk> we have been getting to lazy, that's true
<amitk> *too
<amitk> bjf: your bot confirmed the bug I filed, have you seen this elsewhere? I've just posted a link to the 3.9 tree that might fix bug 1158689
<ubot2> Launchpad bug 1158689 in linux (Ubuntu) "nouveau and nvidia binary drivers are broken for GeForce 8400 GS" [Undecided,Confirmed] https://launchpad.net/bugs/1158689
<apw> amitk, no no meta they arn't in a repo after all
<amitk> apw: ack, makes sense (not in a repo). Would be handy though, to allow users to upgrade to the latest crack automatically to find if their problems are fixed (so they can report back when it is fixed)
<ppisati> apw: when you're awake and fuly operational
<ppisati> apw: i've a quest for you
<apw> ppisati, a guest ?
<ppisati> apw: a quest
<ppisati> apw: have you ever played to D&D?
<ogra_> with guests ?
<ppisati> ogra_: maybe :)
<ppisati> ogra_: not necessarily
<apw> ppisati, d&d a long long time ago
<ppisati> apw: just kidding
<ppisati> apw: well, it's debian packaging question
<ppisati> apw: basically, i just noticed that renaming 'omap' to 'generic'
<apw> ppisati, yep
<ppisati> apw: one of the side effect was that a lot of modules are not part of linux-image anymore
<apw> ahh yesh they are in in linux-image-extra
<ppisati> apw: but are moved to 
<ppisati> apw: right
<ppisati> apw: do you exctly know where i should put my hands to fix it?
<apw> ppisati, i am not sure as things are you can, generic is either split or it is not
<apw> that may be or may not be a problem
<apw> we could just ignore it and make the meta for arm -generic the same so it pulls in both
<ppisati> apw: uhm ok
<ppisati> apw: but in that case i want to do some adjustment first
<ppisati> apw: like moving some 'vital' modules to -image
<apw> ppisati, yeah that would be sensible indeed, the split is to allow virtual to be smaller
<apw> ppisati, and it depends if we will ever have an arm virtual
<ppisati> apw: and, besides, image-extra fails to install for some yet unknown reason
<ppisati> apw: i mean, if it's easy to put a check like 'apply this split rule on if arch != armhf'
<ppisati> apw: then i would like to do it
<apw> ppisati, when i have fixed this cve issue henrix has me looking at i'll see how easy it is to do just that
<ppisati> apw: ok, thanks
<apw> ppisati, yep
 * ppisati back in 20
<brendand_> henrix, is the lucid kernel in -proposed the last one coming through before end of desktop support?
<henrix> brendand_: i don't think so. i believe we'll have another one - there's a regression being worked out at the moment
<apw> henrix, ok the matrix is updated, i think that looks better
<henrix> apw: yep, it does! cool!
<apw> henrix, a heap of raring went to released, which is a good sign
<henrix> apw: yeah, i've seen that. uff... finally this is sorted out :)
<apw> henrix, we only add versions so very rarely that i always forget
<henrix> apw: and soon we'll be *removing* 2 versions ;)
<apw> henrix, yeah looking forward to losing those
<apw> henrix, are you going to review and push the latest autotriage or shall i
<henrix> apw: hmm... push? isn't the push done automagically?
<apw> henrix, the autotriager pulls in our stuff and merges their stuff and produces a result, we still have to pull that down review it and push it to where security pulls if we are happy
<apw> henrix, someone must be doing that for the thing to be getting to security though
<apw> so we maybe missunderstanding each other
<henrix> apw: mumble?
<apw> henrix, can't from here, not enough bandwidth
<apw> henrix, bjf, sconklin, FYI the linux-overlay file is now in the security repo as active/10autotriage.linux
<apw> (i didn't chose the name :))
<apw> choose
<ppisati> bjf: i'm doing the topic branches rebases right now
<apw> henrix, what was this latest respin ?
<henrix> apw: yep, unless something urgent comes up, this was the last respin
<apw> henrix, which series
<henrix> apw: Hardy and Oneiric
<henrix> apw: from the kt meeting minutes: "Note: This is the week the last Hardy and Oneiric kernels may be built." :)
<apw> ahh ok this is a normal spin
<henrix> apw: ups, i messed up your question with your pm :)
<apw> yeah was asking about the ppisati rebases, to know if i was expecting any lowlatency ones
<apw> if it is a normal 3 weekly batch this time, then i guess yes :)
<henrix> yep
 * henrix -> lunch
<stefanct> can someone please give me some up to date pointers to the state of the -realtime kernel? all i find is outdated information referencing bogani's PPA
<zequence> stefanct: There's no realtime kernel since 9.10
<zequence> stefanct: linux-lowlatency has taken its place, which is not a realtime kernel
<stefanct> that's the history of the official repositories only(?) but apparently there were some efforts by bogani regarding 12.04?
<stefanct> but essentially... if i want a -rt or -realtime (i.e. ubuntu flavoured or vanilla kernel + rt patches (whatever is left of them/not upstream yet)), i'll have to grab the patch and build it myself, right?
<stefanct> -lowlatency does not improve my use case AFAICS
<stefanct> my problem is that clock_nanosleep with TIMER_ABSTIME sleeps way too long
<stefanct> 		clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &sync_ts, NULL);
<stefanct> 		clock_gettime(CLOCK_MONOTONIC, &ts);
<zequence> stefanct: There was no effort on getting the -rt in. At least no real one
<stefanct> for a sync_ts.tv_nsec of 0
<stefanct> results in 00:01:07.000011587
<stefanct> i.e. constantly >10us "too late"
<stefanct> it never comes even close
<stefanct> and that is with cpu shielding, SCHED_RR etc on an idle machine
<zequence> I think Bogani kept the door open for that, but no one else was interested at the time. There's a small chance the we in the Ubuntu Studio team might be interested in reintroducing it
<stefanct> np, i have to patch my kernel anyway for my project
<stefanct> i just need to find out if the -rt patch would help me at all and that would have been easier with a binary
<stefanct> need to run now, bbl
<zequence> stefanct: Debian has a -rt kernel
<zequence> debian wheezy
<stefanct> ok, will look into that, thx
<ppisati> bjf: the multiple closure in q/master is giving me (actually kteam-tools/maintscripts/verify-release-ready)
<ppisati> bjf: i'll have to mangle a bit the syntax
<ppisati> bjf: uhm no
<ppisati> bjf: during the 'unique release tracking bug'
<ppisati> bjf: verify-release-ready tries to parse the last section of debian.master/changelog
<ppisati> bjf: and since it can't find the Release Tracking Bugs there
<ppisati> bjf: check fails
<bjf> ppisati, after you rebase, don't you go into the changelog and add the correct tracking bug information?
<ppisati> bjf: yes i do
<ppisati> bjf: but it tries to compare my tracking bug
<ppisati> bjf: with the one found in master
<ppisati> bjf: but since last section in master doesn't contain one
<tjaalton> heads-up, bug 140716 is a regression on precise and quantal kernels
<ubot2> Launchpad bug 140716 in skktools (Ubuntu) "[Sync request] Sync skktools (1.2+0.20061004-3) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/140716
<tjaalton> uh
<ppisati> bjf: it fails
<tjaalton> bug 1140716
<ubot2> Launchpad bug 1140716 in linux (Ubuntu Raring) "[regression] 3.5.0-26-generic GPU hangs" [Critical,Confirmed] https://launchpad.net/bugs/1140716
<tjaalton> seems to hit sandybridge machines
<bjf> ppisati, ok, don't sweat it. if you are happy with your rebase and it builds well pull it in and look at what verify-release-ready is having trouble with
<ppisati> bjf: ok, just wnated to prevent an error in the SRU pipeline later
<bjf> ppisati, thanks for the heads-up, sconklin will deal with it :-)
<ppisati> bjf: ok :)
<sconklin> What bus?
<bjf> jsalisbury, you want to do some bisecting of kernels to find the issue with ^ that tjaalton just mentioned
<bjf> infinity, the regression found in lucid kernel 2.6.32-46.105 was actually introduced in 2.6.32-45.104 how do you feel about pushing .105 into -updates ?
<infinity> bjf: Doesn't hurt my feelings terribly, if jjohansen is cool with it too.
<infinity> bjf: if so, just update the bug to lie about passing regression testing and let the bot do its thing.
<bjf> infinity, ack
<rtg> apw, can you have a look at raring master-next tip and tell me why the CONFIG_USB_EHCI_HCD_PLATFORM and CONFIG_USB_EHCI_HCD_PLATFORM enforcement rules are failing ?
 * rtg -> back in a bit
<jsalisbury> bjf, yes, I'll do a bisect for that bug
<bjf> jsalisbury, thanks
<josepht> the red/green are reversed
<josepht> red for up, green for down
<bjf> jjohansen, ?
<ppisati> rtg: http://paste.ubuntu.com/5637397/
<apw> rtg, yep
<rtg> apw, nevermind, ppisatisuggested a fix
<apw> ok
<rtg> apw, just pushed 3.8.4 rebase plus omap4->generic. off to do some build and boot testing.
<apw> rtg, great
<apw> rtg, i think the do_extras_package twiddle is probabally 'the wrong thing' we should probabally be cleverer (it is still the right thing for right now) maybe we can brainstorm when we are together
<rtg> apw, I actually did it 2 ways. first I thought that we shuold just hard code the logic in the generic debian rules, but then I remembered that Xen is forthcoming for armhf.
<apw> yeah, i suspect that logic should be more like 'list per flavour/arch of inclusion lists' or something
<rtg> apw, maybe what we ought to do is revisit the extras package and 'generic' name dependency.
<apw> anyhow, that is a beer discussion, and whats there is purfectly servicable to get us past here
<apw> rtg, right ... i think it is a 'put the contents of this list in this package name for this arch/flavour' thing we need
<apw> so extras goes away as a thing and becomes a parameterisation of the new thing
<apw> i'll have a thing and bring a propsal to our meet
<rtg> get it on the agenda
<rtg> (so we look busy) 
<bjf> if it isn't written down, it didn't happen
<apw> rtg will do
<apw> rtg, bjf, done
 * ppisati -> gym -> EOW
<jjohansen> infinity, bjf: I am fine with pushing 2.6.32-46.105 into updates
<infinity> jjohansen: Good, cause I did so about 3 minutes ago.
<jjohansen> hehe
 * rtg -> lunch
<rtg> henrix, is this the result of a stable patch? https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4392085/+files/buildlog_ubuntu-lucid-ia64.linux_2.6.32-46.106_FAILEDTOBUILD.txt.gz
<henrix> rtg: yes
<henrix> rtg: https://lkml.org/lkml/2013/3/20/553
<rtg> henrix, it likely affects PPC
<rtg> as well
<henrix> rtg: no, i don't think it does. let me check...
<bjf> sconklin, i guess i'm ok with doing a revert, and pulling in the new patch
<bjf> sconklin, after it's reviewed on the mailing list
<henrix> rtg: mips, blackfin, ia64, parisc and tile
<henrix> (from the discussion in lkml)
<rtg> henrix, right, mips was the upstream complaint
<henrix> here's ben's proposed patch: https://lkml.org/lkml/2013/3/20/712
<henrix> but i'm not sure if that's the solution that will be adopted by stable
<sconklin> bjf: it's a fast respin for lucid, there are no dependent or derivative packages
<bjf> sconklin, henrix, then i think we just revert and wait for it to come through stable
<henrix> bjf: yeah, that's my preferrence too
<henrix> bjf: i've seen this prob earlier today and forgot it could affect us. didn't remember we supported ia64 for lucid :p
<bjf> sconklin, so let's go with a revert
<sconklin> I'll just count this as two acks and apply it?
<bjf> rtg, ^ work for you?
<rtg> bjf, its a simple patch
<rtg> so, yes I'm OK with it
<sconklin> I'll let someone else pull and have a look at master-next before I wrap it up
<bjf> rtg, you are ok with the revert?
<rtg> bjf, or we could just apply the proposed upstream patch, its just an ifdef for various arches
<sconklin> ok, next question. One CVE patch hit master-next since I spun it, I plan to include that while I'm respinning
<sconklin> everyone ok with that also?
<bjf> sconklin, yes with the additional CVE patch
<rtg> CVE patches are special :)
<kamal> lalalalalala
<bjf> sconklin, i agree with rtg now, lets just take the upstream patch for the busted CVE patch
<kamal> QA ... Friday-style!
<kamal> ;-)
<rtg> kamal, racing up on beer time. things get decided quickly.
 * kamal gets out of the way
<bjf> sconklin, let's run it accross the mailing list but i think you got two acks
<bjf> sconklin, so just plow on ahead with it
<sconklin> ack, that makes it a lot less pressure
<sconklin> mail the patch
<henrix> bjf: rtg: please note the comment in ben's patch: "we can use one of the attached (untested) patches..."
<rtg> henrix, yeah, but its pretty obvious.
<bjf> henrix, i guess we'll be testing it :-)
<rtg> its actually a compile time check
<henrix> rtg: bjf: ack, i'm ok with that then :)
<apw> heh ... cve fun indeed
<henrix> apw: its been a *long* day :)
<apw> heh seems so indeed
<sconklin> long week. I started monday by breaking half the world
<sconklin> who's mailing the patch?
<henrix> sconklin: i can do that
<rtg> sconklin, I thought henrix ...
<henrix> but actually you need 2 patches
<henrix> give me 1 min to prep it
<sconklin> ok, I just didn't want all of us to assume someone else was handling it :-)
<henrix> ok, i've just sent the patches to the mailing list
<henrix> note that i haven't build tested them
<rtg> henrix, I'll handle 'em
<henrix> rtg: ack, thanks
 * henrix will call it a day before someone finds another broken cve
<bjf> quick, run away
<henrix> heh :)
<apw> jsalisbury, on bug #1157952 ... it might make sense to make a raring kernel for him with that applied to test ... i would be unsure if they can boot non-ubuntu kernels easily in that environment
<ubot2> Launchpad bug 1157952 in linux (Ubuntu) "SCSI keysense errors on console with Raring (3.8 kernel) within Windows Azure" [High,Incomplete] https://launchpad.net/bugs/1157952
<rtg> bjf, sconklin: pushed lucid master-next if you'd like to start packaging
<sconklin> rtg: on it
<henrix> rtg: btw, these 2 patches should be aplied to all the other series, /me thinks (i haven't tried to apply them)
<rtg> henrix, depends on if we have the affected arches. I don't think we do after lucid
<henrix> rtg: otoh we may wait for the stable updates, as we're not breaking builds on them
<henrix> rtg: true, i don't think so as well
<rtg> henrix, then lets just wait on stable
<henrix> rtg: ack
 * henrix -> EOD (again)
<jsalisbury> apw, ack
<arges> hey. when i run 'fdr genconfig', why do I not see the virtual flavor configs? is this a separate command?
<rtg> arges, virt is generated from generic using inclusion lists.
<rtg> depends on the release. some are a bit different
<arges> rtg: yea I noticed 3.2 has the config.flavor.virtual, while Q/R don't have this. I assume Q/R use inclusion lists
<rtg> arges, yes IIRC
<arges> rtg: so there is there a mechanism to get a config file by using genconfigs... or should I just boot a kernel and the config from there
<rtg> arges, for virt ?
<arges> rtg: yup
<rtg> fdr clean prepare-virtual ?
<arges> rtg:  i dont seem to have that target in my raring tree
<rtg> arges, ok, for raring the config is the same as generic.
<rtg> fdr clean prepare-generic
<arges> hmm, dont' see to have that one either
<arges> rtg: i'll look it up later. for now getting this from a VM will work
<rtg> arges, ok, its working for me
<arges> hmm
<kamal> ~/src/linux/ubuntu-raring$ fakeroot debian/rules prepare-generic     <--- works for me too
<arges> i'm in master-next
<arges> not sure if that matters
<arges> rtg: ahh in master it works. not master-next
<rtg> shouldn't
<rtg> it works in master-next as wekk
<rtg> well*
<arges> probably something i did
<rtg> apw, still around ? please review ubuntu-raring-meta 'UBUNTU: Rename omap to generic'
<rtg> oh, 7:30 in the UK. apw should be off quaffing a Friday beer.
 * rtg -> EOW
#ubuntu-kernel 2013-03-23
<melkor> With the 3.7 kernel line my microphone works fine. With the 3.8 kernel line my microphone doesn't work.
<melkor> Hmm, this issue appears to have come up in an arch discussion too.
#ubuntu-kernel 2013-03-24
<infinity> apw, ogasawara: Can one of you commit and tag this revision: http://launchpadlibrarian.net/135069108/linux-meta_3.8.0.14.28_3.8.0.14.29.diff.gz
<AlexzAK> Hi, everybody! I have problems with video hardware on Ubuntu 12.10. I using it on Sony VAIO SVE1711V1RB laptop. It has AMD Radeon HD 7650M video driver. Both open source and proprietary (including beta version) drivers show artifacts. Please say me what to do! I wish provide any assistance with that issues
<AlexzAK> Is there are some "Ubuntu hardware" team? Or who is responsible for hardware support?
<AlexzAK> Is there are anybody who can provide some help with AMD Radeon HD 7650M video driver?
#ubuntu-kernel 2014-03-17
 * apw yawns
 * smb readies the Shreddies
<rtg> dannf, can you get the arm64 branch tested this morning ? I'd like to get that pile merged and uploaded.
<jtn> Hello. I gather 3.14 is unlikely to make Trusty. Unfortunately, driver support for Wacom's current range of graphics tablets debuts in 3.14 (I believe). Is there any chance of sneaking the driver into Trusty somehow? -- should I raise a bug? I have hand-rolled a DKMS package of the upstream linux-wacom 0.20 driver for Precise [sic], which suggests it should be straightforward to integrate. I understand if it's too late for Trusty though (I can alw
<rtg> jtn, just the 7 wacom patches ? from 3.13 to 3.14-rc7 ?
<rtg> git log --pretty=oneline  v3.13..HEAD -- drivers/input/tablet/wacom* drivers/hid/hid-wacom.c drivers/input/touchscreen/wacom*
<jtn> rtg: hang on, I'll see if I recognise those
 * jtn refreshes his kernel git... grind grind grind...
<rtg> jtn, they all apply cleanly
<rtg> gb
<jtn> rtg: the log messages look about right (especially b5fd2a3e looks like what I'm interested in)
<rtg> jtn, ok, gimme a bit to study them and make sure they look good for back porting
<jtn> rtg: OK, thanks. (FYI, I can certainly test a new installer image against Intuos hardware, not sure about anything less packaged.)
<jtn> rtg, (the diff looks about like what I expected too)
<ogra_> apw, could it be that the latest touch kernels are missing the ureadahed patches again ? i dont see it started in http://people.canonical.com/~ogra/touch-bootcharts/ 
<rtg> ogra_, are you sure mako ever had it ?
<ogra_> rtg, yep, i opened a bug for it and that one got fixed
<jtn> (afk)
<ogra_> Bug 1194127
<ubot2> Launchpad bug 1194127 in linux-manta (Ubuntu Saucy) "ureadahead does not work in current linux-maguro/linux-mako/linux-manta" [High,Fix released] https://launchpad.net/bugs/1194127
<rtg> ogra_, that patch is still in the mako kernel: 'UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib()'
<ogra_> ok
<rtg> Ubuntu-mako-3.4.0-4.22
<ogra_> right
<ogra_> hmm
<ogra_> then i wonder why it doesnt run 
<rtg> yama ?
<rtg> ogra_, how about this :
<rtg> 811bb1b343784ead1d31109e62e13b55fe9ccc18 security: allow Yama to be unconditionally stacked
<rtg> 83595aa667e65243780e4d453b3c4ee561fb0d82 Yama: higher restrictions should block PTRACE_TRACEME
<rtg> 15b979177a2f77598f0d62c9f1202ec11e0b649c Yama: add additional ptrace scopes
<rtg> the PTRACE patch looks like a likely candidate
 * ogra_ googles yama and finds weird stuff
<rtg> we could ask jjohansen
<ogra_> its either a death god or a yoga thing :P
<ogra_> or a restaurant in NY :P
<rtg> yet another mandatory authenticator (I think)
<ogra_> ah
<ogra_> yeah, adding kernel to the search helps slightly :) 
<ogra_> rtg, another thing, could we default to performance governor on all touch kernels ? android forces ondemand later anyway and it might speed up the boot a bit 
<rtg> ogra_, start a bug for it please. assign me or apw so we don't lose it in the noise
<ogra_> ok
<rtg> jtn, wacom patches pushed
<rtg> ogra_, can you build a kernel with CONFIG_SECURITY_YAMA=n to see if it affects ureadahead ?
<ogra_> will try, yeah
<apw> ogra_, let us know the bug # for that performance thing
<apw> ogra_, though, if we have the waiting for battery thing, we need to be careful it changes the governor before waiting
<ogra_> apw, well, we might set it from userspace so we can check for low battery before forcing performance ... 
<rtg> apw, they may be reconsidering....
<ogra_> still discussiong it 
<apw> heh ... htat
<rsalveti> ogra_: yeah, I believe we should boot->check battery->enable performance->android->enable ondemand
<jtn> rtg: excellent, thank you very much!
<rsalveti> so we don't need to change the default in the kernel side
<rsalveti> that would also affect recovery afaik
<rtg> rsalveti, ack
<ogra_> yep
 * apw likes plans with no work in them :)
<rtg> apw, I think will still have to deal with YAMA breaking ureadahead
<apw> if it is that indeed, but would that not break on all including amd64 ?
<rtg> hard to say
<dannf> rtg: you bet
<rtg> ogra_ is gonna test it
<apw> rtg, the patch is on our master-next branch right?
<rtg> apw, no - I asked him to build with YAMA=n
<rtg> oh, you mean the ptrace patch ?
<apw> yeah i mean the ptrace patch
<rtg> UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib() (for v3.7+)
<apw> right that is the hooks, but we have the yama patch you are suspicious of too, so if we have that combo and the ureadahead produces packs, i don't think it can be those
<apw> rtg, i cirtainly have packs from the last few days when i upgraded, so it works in that combo
<apw> i wonder if they are even starting it :)
<rtg> apw, dunno, I was pushing off the legwork on ogra_ :)
<apw> yeah works for me, suspect it is not that patch though :)
<rtg> dannf, I just slammed HEAD on that branch with a final packaging build fix for amd64.
<rtg> am test building it now
<dannf> i've got an arm64 build going
<rtg> dannf, it'll likely fail 'cause of missing modules (phy-core)
<rtg> dannf, do you cross compile ?
<dannf> no, native
<rtg> its _way_ faster, isn't it ?
<jtn> rtg: Wacom> btw, let me know if there's any testing I can usefully do (I'll check out the final beta at end of March in any case)
<dannf> ccache ftw
<rtg> jtn, Wednesday's daily ought to have the right kernel.
<rtg> dannf, I've found that ccache spends moretime computing the hash and reading the object then it took to just compile the file.
<rtg> at least on tangerine and gomeisa
<dannf> rtg: built fine, other than the missing phy-core. sata/net both work, as does reboot driver
<rtg> dannf, qemu/kvm ?
<dannf> rtg: on deck
<dannf> rtg: successfully booted an ubuntu trusty guest
<dannf> looks good to me
<rtg> dannf, ok. are you happy with the patch set then ?
<rtg> your RTC driver works ?
<dannf> oh, yeah - need to check rtc
<rtg> dannf, also, I don't think I have an answer regarding the absence of the PCIe enablement patches.
<dannf> yep, +1 on the patch set
<dannf> rtc works, systortc kernel support works
<dannf> yeah, we'll need to talk more about pci. i'm going to pull in the latest changes into my tree today for testing. another option is the -oldpci patches which are far less intensive, but not a general solution like what's going upstream
<rtg> dannf, what is the affect of _not_ having the PCIe patches ?
<dannf> rtg: but i think we can assume it will be needed by users for networking purposes - people that don't use xgene-enet
<rtg> dannf, I'm not sure I care about that. they'll have to wait for 14.04.2
<trem> hi all
<trem> hi apw, are you available few minutes ? I'll be pleased to talk with you
<apw> hi
<trem> apw: may we talk in private (of course, if you have some free time)
<trem> ?
<infinity> BenC: SRU kernel nag.
<infinity> zequence: Ditto.
<ParkerR> I'm using the raring desktop image on my Nexus 7 (updated to Trusty) For about 12 hours now I've been trying to compile a kernel AND keep it at or under 8MB so it will fit in the boot partition. I have gotten it down to 8.82422 MB. Can somebody take a look and maybe provide some tips on how I can get this to fit? 
<ParkerR> http://paste.ubuntu.com/7108652/
<ParkerR> "Flashing kernel and initramfs to /dev/mmcblk0p2... /dev/mmcblk0p2: updated is too big for the Boot Image (9252864 vs 8388608 bytes)"
<ParkerR> Or if that config would even work... the killer is that I want the Tegra DRm module and it HAS to be built in and not as a loadable module
<ParkerR> *DRM
<hallyn> apw: stgraber: aufs, feh - bug 1293549
<ubot2> Launchpad bug 1293549 in juju-core "Filesystem mount from lxc template causes filesystem permission breakages" [Critical,Triaged] https://launchpad.net/bugs/1293549
<infinity> hallyn: Well, that certainly shouldn't change the permissions on the underlying dir, as that's immutable.
<infinity> hallyn: But copying up, changing permissions, and using that copy would seem sane.
<hallyn> infinity: right..
<hallyn> overlayfs allows it fwiw
<infinity> hallyn: So, the same copy-up mechanism that happens on a contents change just needs to trigger on a permissions change, shouldn't be too hard to hunt that down.
<infinity> Using overlayfs as a benchmark for how union filesystems should behave is probably not the best idea.
<hallyn> actually cop-up happened, but chown did not
<hallyn> infinity: same for aufs :)
<infinity> But in this case, I agree that "rm && mkdir && chown" should behave the same as "chown" from the user POV.
<infinity> And from the code POV, that would be a copy-up in the latter case, to emulate what the former is doing.
<hallyn> i need to do a new post on the woes of every option for snapshotted clones
<infinity> Well, copy-up and chown, obviously. :P
<hallyn> there is no good one
<infinity> I still find LVM snapshots to be the least crack-ridden.
<infinity> They're just also, unfortunately, the hardest to set up.
<hallyn> yeah the only downside for me for those is that i have to pre-allocate size
<infinity> Right.
<hallyn> i'm actually all set up for them, but for doing package builds i don't want to have to spend that much space per snapshot
<hallyn> of course it's not really taking up the space...
<hallyn> still may do that
<hallyn> (gotta rewrite it all this week)
<infinity> For local package builds, I use aufs backed on tmpfs.
<stgraber> lvm also doesn't get you updates to the underlay which happen after you create the overlay right?
<ParkerR> Any idea on how I could wrangle that under 8MB?
<stgraber> (not that you usually care for that specific feature)
<infinity> stgraber: Right, LVM is an actual snapshot, so no weird union "look, new files from nowhere!" behaviour.
<stgraber> I really need to give btrfs another try since it'd give me the same thing as LVM snapshots but doing it at the fs layer instead, so no size limitation and a bit more flexibility
<hallyn> regular lvm also is limited to depth of 1
<infinity> And, indeed, btrfs should also provide the same level of awesome, but I still don't trust it further than I can throw an s/390 mainframe.
<hallyn> stgraber: fsync is now much faster than in 3.2, but still not quite fast enough for me
<hallyn> infinity: it hasn't failed me in months of using it for all my containers.  just horrible fsync.
<hallyn> all my tests and package builds have been using btrfs snapshots
<hallyn> dafuq - init-generate coredump in my aufs delta0 directory
<stgraber> hallyn: yeah, my last try was 3.2 and that was dreadful (and getting much worse over time), I need to check whether it'd be reasonable to use for my LXC containers and maybe for my home partition. My laptop's rootfs I intend to keep on ext4 for quite a while still (though having upgrade rollback would be kinda neat)
<infinity> hallyn: Well, I look forward to a day where it can maybe become a sane default.  Being able to code high level distro features on top (like restore points^W^Wupgrade rollback) would be great.
<hallyn> haha yeah, i'm using a 100G lvm partition for btrfs containers, mounted at /opt/lxc.  rootfs?  no way :)
<hallyn> we've been looking forward to that since at least 2009 :)
<infinity> btrfs on lvm?  How meta.
<stgraber> infinity: I actually never had or directly heard of actual dataloss with btrfs, the usual problem is performance and lack of tooling. The alternative is zfs-on-linux but I'm not too sure which I prefer... zfs is supposed to be a lot more stable, but it's a mostly unsupported dkms module with crazy license issues. btrfs is mainline but not really production ready...
<hallyn> stgraber: no, i used to lose all data the moment i did a subvolume clone
<hallyn> up to like a year ago
<infinity> stgraber: I'm not hugely concerned about the ZFS license issues, I'm very concerned that I don't think anyone actually abuses it on Linux much.
<infinity> stgraber: And saying "well, it works great on Solaris" doesn't mean a bunch.
<hallyn> get that Tamas guy in here :)  he keeps yelling me about zfs
<stgraber> infinity: I know a bunch of HPC people using ZFS on Linux in production for a couple of years now (with crazy pools doing an insance amount of iops)
<infinity> stgraber: Potentially comforting.
<hallyn> stgraber: the kernel module, not fuse i assume?
<infinity> I still suspect btrfs is the way forward for Linux.
<infinity> Eventually.
<stgraber> hallyn: right, the kernel module
<infinity> If I hear that Tso has given up the fight for the One True Filesystem and started lending his expertise and time to btrfs, that would maybe sway me.
<mjg59> infinity: In which direction? :p
<stgraber> the other problem with zfs is that 32bit support isn't really a priority, so everyone uses it on 64bit. I kind of like all my machines to use the same setup, and I'm not sure I want to be beta testing zfs on 32bit :)
<infinity> mjg59: Yes.
 * infinity discovers that the best way to melt an accidentally-frozen 1.5L block of tomato juice is to add 375mL of 
<infinity> ... vodka, and declares today a success.
<xnox> infinity: it must be spring in canada.
<infinity> xnox: Well, yes, and because it's Canada, it's clamato juice, not tomato juice, but no one else knows what that is, so I translated.
<hallyn> xnox: say, are you what one might call a current maintainer on libnih?
<hallyn> ("muhahaha")
<xnox> hallyn: perhaps.
<hallyn> xnox: i'm trying to figure out why multiple threads, each opening and using their own separate nih-dbus connection, occasionally seem to get memory corruptoin or segvs
<hallyn> every time the backtrace is different...
<hallyn> i.e. http://paste.ubuntu.com/7111193/ is a few of the backtraces
<hallyn> (source is at git://github.com/cgmanager/cgmanager file tests/cgm-concurrent.c)
<hallyn> my first question is: am i doing something obviously wrong in how i'm opening the conection in that file?
<hallyn> near as i can tell, libdbus should at this point be reasonably thread-safe (since 2011)
<xnox> libnih is not thread safe, unless threading compile time option is enabled (i think)
<xnox> and we don't enable that by default, let me check.
<xnox> but your test-case seems reasonable.
<hallyn> we don't?  d'oh!
<hallyn> all i see in configure.ac is a call to NIH_C_THREAD whatever tht means
<xnox> hallyn: yeah, "threads are evil" is the general mantra and "upstart doesn't need them" apart from like starting to do async spawn et al.
<xnox> see m4/libnih.m4
<xnox>         AS_HELP_STRING([--enable-threading],
<xnox>                        [Enable support for multi-threading]),
<xnox> hallyn: recompile libnih with that enabled, install and see if that helps.
<xnox> we can provide it as a separate package/library i guess...
<hallyn> do we disable that for performance reasons?
<hallyn> i mean, just bc it's enabled in libnih wouldn't mean upstart has to use threads :)
<xnox> hallyn: no idea. True that. I see that in mainc and error.c it does reference things with __thread for e.g. context_stacks and exit_status /loops.
<xnox> hallyn: recompile libnih and see if that helps your test-case at all.
<hallyn> xnox: thanks!  i'll do that and proceed from there (talk to jodh and yourself i guess)
<miseria> "un maniatico destruye lo que el mecanico  no puede arreglar, como ejemplo tenemos el calentamiento global" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-03-18
<hallyn> xnox: sadly, that didn't actually help
<xnox> hallyn: =/ oh well.
<xnox> hallyn: i can try to dig into it, but deffinatly not tonight.
<hallyn> now really i expected it to make it worse (since noone is using it :)
<hallyn> xnox: np, it's late there - ttyl
<hallyn> thanks! gn
<ParkerR> Or as another alternative... is the kernel in the new builds managed by a deb file?
<ParkerR> *new touch builds
<apw> ParkerR, the kernel is built in a .deb yes though typically upgrades in touch images are not done directly
<ogra_> the kernel deb is only used by the android package 
<ogra_> (which generates boot.img and system.img (the latter has the modules))
<ogra_> just on a sidenote, forcing performance from initrd on boot on mako gains exactly nothing :(
<apw> ogra_, worth a try
<ogra_> yeah
<ogra_> it actually takes a few milliseconds longer with performance ... i guess thats due to the echoing "performance" into sysfs
<ogra_> AHA !
<ogra_> root@ubuntu-phablet:/# ls -l /var/lib/ureadahead/debugfs/
<ogra_> total 0
<ogra_> root@ubuntu-phablet:/# mount | grep debugfs                              
<ogra_> none on /sys/kernel/debug type debugfs (rw,relatime)
<ogra_> so i guess thats why ureadahead doesnt work anymore
<apw> aha?
<ogra_> well, ureadahead reads from /var/lib/ureadahead/debugfs/
<ogra_> doesnt it ?
<apw> isn't that normal?  doesn't ureadahead mount it temporarily on its own mointpoint during its run and unmount it after?
<ogra_> hmm
<apw> as it may need it before it is mounted by the system
<ogra_> hmm
<apw> ogra_, so actually it uses /sys if it is mounted, else it mounts its own
<ogra_> ah, k 
<apw> ogra_, is there a bug for this ?
<ogra_> nope, still researching 
<ogra_> funnily it seems ot have profiled something at some point 
<ogra_> *to
<ogra_> but it is never executed on boot after that 
<apw> is the packs directory writable ?
<apw> or ... the place that the "reprofile" marker is stored
<ogra_> yes
<ogra_> i see packs that have been generated on first boot 
<ogra_> http://paste.ubuntu.com/7113774/
<ogra_> even specoific ones for the container 
<apw> have you tried just running it to see if it works?
<ogra_> it doesnt 
<ogra_> root@ubuntu-phablet:/# start ureadahead
<ogra_> ureadahead stop/waiting
<ogra_> callong "ureadahead --daemon" directly immediately returns ... i dont see it in the processlist
<apw> ogra_, and without --daemon and with --verbose ?
<ogra_> looks ok http://paste.ubuntu.com/7113819/
<apw> ogra_, ok so you don't see it because it only takes 0.02s to do the readahead, as this is flash it is not that supprising
<ogra_> it would still show up in a bootchart 
<ogra_> (it used to)
<apw> so that implies it is not starting, which says the start condition is wrong
<apw> i assume we ahve a mountall job still ?
<apw> ogra_, ^
<ogra_> yep
<ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-243.png
<zequence> infinity: No update to the precise kernel?
<apw> ogra_, there is a level at which things get collapsed when they are tooo short
<ogra_> hmm
<apw> which you can turn off when generating hte graph
<ogra_> ah, there is a HZ= setting 
 * ogra_ sets it from 25 to 50Hz
<ogra_> so that gets me a lot more small processes listed (and makes the tgz of the bootchart twice as big) ... but still no trace of ureadahead ... 
<ogra_> now i wonder ... 
<apw> ogra_, could still be tooo small to see i be reconing
<ogra_> yes, the point is that the interesting pack files arent the default pack 
<ogra_> (see my ls output of /var/lib/ureadahead above) 
<apw> arn't those loaded by the other job?
<ogra_> and these mountpoinnts arent handled by mountall 
<ogra_> but before in the initrd
<ogra_> i.e. they are already mounted when mountall starts 
<apw> ok then they won't get loaded anyhow
<ogra_> start on mounted DEVICE=[/UL]* MOUNTPOINT=/?*
<apw> see /etc/init/ureadahead-other.conf which loads them based on the mount announcements
<apw> so i suspect you want your own job which runs ureadahead against the special mounts
<ogra_> so the question is, does mountall emit "mounted" for already mounted devices in fstab
<ogra_> jodh, do you know ?^^^
<apw> i would doubt it, you can look at the emitted events right?
<ogra_> i think we dropped "initrcl events" at some point 
<apw> "The  mounted event is generated by the mountall(8) daemon after it has mounted a filesystem."
<apw> i read that as for things it has mounted itself only
<ogra_> bah, k 
<ogra_> so i need something that loops through fstab and calls ureadahead for each mountpoint regardless
<ogra_> and starts on startup or so 
<apw> you know your special ones right?
<apw> they are always the same phone wise ?
<ogra_> well, i guess we want everything but rootfs
<ogra_> no, but fstab is assembled by initrd on boot 
<ogra_> (on every boot)
<ogra_> bah, and now i killed my remote device :(
<jodh> ogra_: yep, apw is correct.
 * ogra_ tries ureadahead-other with a hardcoded value for MOUNTPOINT ... but that doesnt seem to work either  
<apw> ?
<apw> what did you put in there
<apw> ogra_, ^
<ogra_> /android/system
<ogra_> my main concern is to get the container up faster (since most of the other bits have to wait for it)
<ogra_> i made the ureadahead-other job start on "starting mountall" and replaced the $MOUNTPOINT in the exec line with the path 
<ogra_> i was assuming this should just work 
<ogra_> but i neither see it in the bootchart nor do i notice any speedup ... 
<apw> perhaps boot it --debug on the kernle command line to see if it runs
<jodh> ogra_: try adding '--force-trace'
<jodh> ogra_: also, what's in /var/log/upstart/ureadahead-other.log ?
<ogra_> jodh, but that will create a new pack ... i have the packs from first boot already
<ogra_> i just want it to make use of them :) 
<jodh> ogra_: on those new mountpoints?
<ogra_> i emptied the log a few boots ago (before i started hacking the job) and there is now nothing in it 
<ogra_> root@ubuntu-phablet:/# ls /var/lib/ureadahead/android*
<ogra_> /var/lib/ureadahead/android.firmware.pack
<ogra_> /var/lib/ureadahead/android.persist.pack
<ogra_> /var/lib/ureadahead/android.system.pack
<ogra_> so there is one pack for /android/system ... if i read that correctly 
<jodh> ogra_: ok, have you added --verbose atleast then to get some output?
<ogra_> not yet 
<ogra_> will do that now
 * ogra_ reboots with --verbose
<ogra_> root@ubuntu-phablet:/# cat /var/log/upstart/ureadahead-other.log 
<ogra_> nothing ...
 * ogra_ moves the start condition to "started mountall"
<ogra_> still no log 
<ogra_> aha
<ogra_> manually starting it produces something in the log
<ogra_> http://paste.ubuntu.com/7114261/
<ogra_> smells like mountall is never emitting "started" or so 
 * ogra_ moves to "start on startup" 
<ogra_> lets see
<ogra_> funny, nothing new in the log
<jodh> ogra_: is ureadahead-other.log empty or non-existent?
<jodh> ogra_: try running "sudo initctl notify-disk-writeable" and check the log again
<ogra_> it was empty (because i did "echo > ... " ) ... 
<ogra_> it got conent when i manually started the job 
<jodh> ogra_: that's cheating :)
<ogra_> ok, got it 
<ogra_> "start on filesystem" works 
<ogra_> now it writes to the log on every boot
 * ogra_ dropes the --verbose and creates a bootchart 
<ogra_> *drops
<ogra_> i dont get why "start on startup" didnt work though 
<apw> maybe you don't have the ureadahead daemon availabe then
<apw> and it would want to write to teh ro filessytems anyhow
<ogra_> nope
<ogra_> the filesystem is assembled from initrd
<ogra_> it is fully set up before we even get to the rootfs
<ogra_> with all writable bits 
<ogra_> and now i see ureadahead in my bootchart \o/
<ogra_> finally
<ogra_> but it doesnt speed up anything :(
<ogra_> ah, no, it gains me .5 sec 
<ogra_> lxc-start runs half a sec earlier now
<ogra_> what a great gain for half a day of work :P
<apw> ogra_, thats pretty good :)
<ogra_> well, lets see, i guess i can write a loop script that processes all packs (apart from the default one)
<ogra_> that might in the end get me 2sec then :P
<apw> yeah it might
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<mdeslaur> cking: so is thermald a dependency of something? what pulls it in? should I install it?
<cking> mdeslaur, just install it
<mdeslaur> cking: is something going to install it by default on our images?
<cking> for t+1 we will make it a dependency on the kernel
<cking> but for now it's an opt-in
<cking> it still is a "maturing" daemon
<mdeslaur> cking: ok, thanks!
<apw> hallyn, ok this is occuring because you have to have read/execute access to all layers in a directory "sandwich" to read the directory
<apw> hallyn, i am trying to figure out if this is an oversite of a deliberate decision
<hallyn> apw: yeah it seemed possible to be on purpose, but i couldn't find where in the code itw as doing it
<apw> hallyn, you are hitting the opendir behaviour there, where it opens each dir in each layer and merges the contents to make the virtual dir you see
<apw> so if you make the bottom directory rx the you can see in there as well
<apw> and i asusme the under in your scenario is empty as well
<apw> hallyn, and the permissions check is specifically checking all layers, it is not an accident
<apw> hallyn, it has a little loop for when we are talking about a read from a directory
<apw> hallyn, i assume this comes from using an unmodified directory image as a lower level here ?
<hallyn> apw: it may nto be an accident, but is it worthwhile?
<hallyn> yes
<hallyn> overlayfs doesn't do it...
<apw> overlayfs is much less mature, so that tells me little about which is right
<apw> what is it stopping you doing
<hallyn> apw: juju creates a clone of a stock ubuntu image, then wants to chown ubuntu: /etc/ssl/private
<hallyn> apw: thinking sensibly about the behavior, I really think aufs is the one in the wrong
<apw> i think you need to justify that
<hallyn> sure,
<hallyn> to do the chown you have to be root in the first place,
<hallyn> you can't end up corrupting the underlyign fs, you can only 'leak' data through the upper fs,
<hallyn> but since you're root, you *could* just as well do it to the underlying fs.  there is no reasonable case i can think of where you werne't meant to 'leak' the data in the file you're chowning
<infinity> zequence: Nope.
<apw> hallyn, ok that needs some thinking about and upstream discussion i am sure, i'll see if i can fix it as a basis or that discussion
<hallyn> apw: ok, thanks.  i'll watch for the thread.
<hallyn> apw: if upstream nacks it, then i guess we'll just have to issue a warning somewhere in lxc
<hallyn> (or drop aufs from lxc clone support - stgraber :)
<infinity> hallyn: Well, juju could hack around the issue with 'cp -a /etc/ssl/private /etc/ssl/private.new && rm -r /etc/ssl/private && mv /etc/ssl/private.new /etc/ssl/private'
<infinity> With a chown in there somewhere.
<infinity> Not that that's ideal, but would get you over the hump for now.
<hallyn> infinity: for that particular case, yeah.  but if we're goign to suggest that aufs is usable for lxc clones, that's not sufficient
<hallyn> like i say every backing store has its deficiencies for clones, but that's just not usable
<infinity> hallyn: Not usable is a bit extreme.  How often does one actually try to do that (traverse a directory they can't read)?
<infinity> Is that chown happening in an unprivileged container, or outside?
<infinity> (ie: do you have real root?)
<infinity> If you have real root, I agree that the behaviour seems entirely wrong.
<infinity> If you don't, I'm not sure how you're reading it at all, seems like a different bug being leveraged. :P
<hallyn> infinity: i don't think real root matters.
<hallyn> if i create a rootfs,
<hallyn> then create an aufs clone container from that unprivileged, it shoudl be the same situation
<hallyn> uid 100000 (my root) chowns a dir to uid 1001000,
<hallyn> but uid 1001000 can't read it despite owning it
<hallyn> maybe instead of not suable i should have said not supportable :)
<hallyn> (as in we'll get tons of weird bug reports)
<infinity> I'm struggling to even find a 750 directory in my schroots to experiment with. :P
<infinity> Ahh, hello /var/cache/ldconfig
<infinity> Okay, yeahp, has nothing to do with containers at all, that's what I wanted to make sure of.
<infinity> (trusty-amd64)adconrad@cthulhu:/var/cache$ ls -al | grep ldconfig
<infinity> drwx------  2 adconrad adconrad   60 Mar 18 10:25 ldconfig
<infinity> (trusty-amd64)adconrad@cthulhu:/var/cache$ ls ldconfig/
<infinity> ls: cannot open directory ldconfig/: Permission denied
<infinity> That seems fundamentally broken to me.
<hallyn> the only way it would be needed is if aufs wrongly allowed non-root to chown the dir
<hallyn> or, does aufs support some fancy uid translation gorp?  /me checks
<hallyn> not sure waht the 'different uid/gid/permission' in mount.aufs manpage is referring to
<apw> most of the docs are in janglish
<jsalisbury> ##
<jsalisbury> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
<jsalisbury> ##
 * ppisati -> chest press
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 25th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<UserError> Why is the Lustre FS in staging?
<UserError> It can be used from userspace and none of the desktop or notebook users will ever use it. You have a greater chance of someone using the tdfx support.
<ogra_> why do you ask downstream ? 
<ogra_> thats a question for the people that decided to put it in stagint (the linux kernel ML for example)
<UserError> Ubuntu has made additions and subtractions
<UserError> Don't play that game.
<UserError> This is pure bullshit bloat for something that should be in userspace on non-niche distros
<apw> UserError, why are we worrying about 1.3M ?
<UserError> 10MB
<UserError> for a feature no-one will ever use and will also be in VM kernels by default
<apw> i can only find one module, which is 1.3M, and why would it be in VMs
<UserError> according to the latest staging on 3.13.5
<UserError> it is nearing 10MB on 64bit
<UserError> which is the only one worth using since 32bit still targets i686
<UserError> apw, Ubuntu stated the reason it wasn't including that vpadu stuff was because of ISO size
<UserError> So i started figuring out that the reasoning was bullshit
<UserError> By going through every single file that was useless. Now i'm on the kernel.
<UserError> Way to keep PandaBoard and Tegra shit in an x86 FS
<UserError> and exynos in the kernel
<apw> so build your own kernel with what you want in it
<apw> not that the size of them in the filesystem tells you waht they are on the iso
<UserError> Ignore the bloat behind the curtain until you make your own curtain
<UserError> Nevermind that Exynos = ARM
<apw> it is a trade off between the greatest usability against the effort to work out what is completely unusable
<UserError> It isn't usability if it is impossible to use
<UserError> Please, please use an x86 kernel on a exynos SoC
<apw> if the config system says something is usable, turning it on is therefore the default position, if the thing is actually configurable but useless would require individual items to be investigated
<apw> so i am sure we have a number of things turned on which cannot be used, due to the lack of correct dependancies
<UserError> ARM =/= X86
<UserError> what is the problem
<UserError> Nothing is going to change that
<apw> you are not hearing me, i am telling you how one ends up in this position
<apw> you may have found a clear case indeed and if someone files a bug for it, we may indeed turn it off
<apw> i am saying that these cases are not clear wthout investigation
<UserError> Ok fine, FS wise, off the top of my head
<UserError> alsa package
<UserError> kernel wise, hw arch exynos
<UserError> Also some TI stuff in there i have the path to somewhere
<apw> yep and if someone has the configuration options and the justificaiton, and puts them in a bug
<apw> there is a high probability it will get looked at and turned off
<UserError> Right but the flaw is the fact that it could've been added from the beginning when the same SoC is powering the phones of the people who should know better
<apw> when every kernel update has hundreds of new options one has to have a default position
<apw> and that is to turn on things which the config system says are applicable to an arch
<apw> and if we have 100 engineers looking at the config then it would likely be perfect
<UserError> you could literally just use grep on the config with the major arm licensee models
<apw> i could go and save space on a machine whiich on average doesn't care
<apw> or i could go and work on some new feature we need
<apw> which is it
<UserError> right, which is going to harm the idea of ubuntu touch and other modile ideas
<apw> nope they have non-generic kernels which are much much smaller
<UserError> when you are having that many writes on every security update
<UserError> every hyrbid device with similar nand/emmc to a phone
<UserError> all those writes
<apw> and touch devices have a minimal config, so this does not apply
<UserError> all the VMs and appliance containers
<UserError> you assume they are minimal, i beg to differ
<apw> and the VMs do not have the entier kernel installed
<apw> there is a split, between the core bits needed on a virtual system, and the rest
<UserError> you're right, they only have joystick nonsense by default
<UserError> and sound
<apw> i am sure they have some bits they should not indeed, but they are less than a third of the size of the full ones
<apw> and if you have some concrete config changes you thing are viable, feel free to propose them
<apw> along with a testing plan
<UserError> The thing is that this has a commutative impact
<UserError> what is the launchpad for this
<apw> i asume you are asking what package to file bugs against, that would be 'linux'
<apw> but "your package is crap" isn't going to get much attention, concrete changes would likely
<UserError> pretty much removal
<UserError> the package is crap
<UserError> i went through every file on sunday
<apw> what is vpadu
<UserError> vdpau*
<UserError> http://www.phoronix.com/scan.php?page=news_item&px=MTYwNzU
<UserError> "too big"
<UserError> yet the kernel can grow by tens of MB in a day
<UserError> yet panda and tegra can just chill in alsa never to be used ever by anyone
<apw> frankly though i may even agree that we have a lot of bloat, your attitude is getting to me
 * ogra_ wonders if UserError is like that in real life too 
<apw> i dunno, i am nicer on irc than in real life in general
<ogra_> heh
<apw> to which i am sure you can attest :)
<ogra_> well, when i meet you in person you are usually drunk already :P 
<apw> i tend to mellow after enough of that
<ogra_> (but i'm usually in the same state) 
<UserError> Is there any plan to make the 32bit kernel or X11 / toolkit / MIR visual packages useful by targeting anything other than the PentiumPro platform with zero optimizations for hardware that actually fits the ram and CPU minimums? 
<infinity> UserError: Why would we build a 32-bit kernel that doesn't run on 32-bit hardware?
<infinity> (Hint, you can install the amd64 kernel with a 32-bit userspace, if that's what you're after)
<UserError> i686 with a single chipset that supports a theoretical minimum on one hand is insanity 
<UserError> not what i am talking about
<UserError> If the recommended minimum for many packages is 800-1Ghz, and only one i686 era CPU can meet those marks on a quad setup that threads horribly...
<UserError> Intel even proved that the major reason 64bit was faster was optimizations
<infinity> Err, they did?  Neat trick.
<UserError> yeh, they did
<UserError> in 2012
<infinity> The major reason x86_64 is faster is lack of register pressure.
<UserError> http://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints
<UserError> cough
<infinity> For some things like string functions, optimisation can make a huge difference, but you get that regardless.
<infinity> Because IFUNC is a beautiful thing.
<mjg59> UserError: That page appears to contain nothing to support your assertion
<UserError> People are holding back performance on 32bit because of a single chipset
<apw> indeed it seems to support the contention that increased registers is a ke factor
<UserError> mjg, the gain difference with the same CPU
<apw> key
<UserError> because of initial targeting of SSE2 vs nothing
<UserError> i686 is nothing
<UserError> In a few months it will be the birthday of the MMX instruction set.
<UserError> Still lacking, since 1997 http://download.intel.com/support/processors/pentiummmx/sb/24318504.pdf
<infinity> zequence: You happy with the kernels in your PPA?
<infinity> zequence: Nevermind, they look good to me, copying.
<UserError> submitted the exynos and lustre paths
<UserError> on to the nitty gritty
<infinity> UserError: Is all this really fallout from one article quoting one guy as to why he's not shipping and supporting a mesa driver?
<UserError> No
<infinity> Sure sounded like it.
<UserError> I'm just removing the excuse of the diff as icing on the cake. I actually am super anal about bloat
<UserError> but their words did get plenty of my side-eye
#ubuntu-kernel 2014-03-19
<alphacrypt> hey, trying 3.11.0.19 kubuntu and get a crash with message like that https://bbs.archlinux.org/viewtopic.php?pid=1340786#p1340786
<apw> alphacrypt, does it cause issues or just informational
<alphacrypt> it get stucks at boot
<cking> smb, bug 1292674
<ubot2> Launchpad bug 1292674 in virt-manager (Ubuntu) "virt-manager.py is being exec'd every second when running virt-manager" [Undecided,New] https://launchpad.net/bugs/1292674
<smb> cking, looking
<alphacrypt> apw ideas?
<jarkko> -
<tseliot> apw: please make sure that LP: #1292563 is fixed, it's a nasty issue
<ubot2> Launchpad bug 1292563 in linux (Ubuntu Saucy) "nvidia driver fails to initialize on Haswell without upstream kernel patch" [High,Triaged] https://launchpad.net/bugs/1292563
<apw> tseliot, ack
<tseliot> thanks
<apw> tseliot, that is already fixed in trusty at least
<tseliot> apw: yep, but oem projects currently based on 12.04.4 will fail
<apw> tseliot, have you tested that this fix actually works as claimed ?  if so you could submit it directly
<tseliot> apw: not really, I don't have access to a haswell system with optimus. I do trust Aaron from NVIDIA though ;)
<tseliot> (he developed most of the code to use optimus)
<apw> yeah, hmmm, well thats not going to get it through SRU, i'll shove some test bits his way
<tseliot> apw: sounds good to me, thanks
<miseria> "estoy solo en mi balcon, el viento acaricia mi rostro pero se lleva mi alma a bailar con las hojas secas que pasan y pasan" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<trippeh> In case you guys is going to work / is working on 3.14, it breaks pam in lxc. have to boot with audit=0.
<trippeh> https://www.redhat.com/archives/linux-audit/2014-February/msg00087.html
<apw> trippeh, thanks for the warning, i suspect we will skip 3.14 alltogether by the time the archive opens for U
<apw> so we will likely be ok
<k0fee> what channel do i go to for help with ubuntu 11 since it's eol
<k0fee> need to find a working repo
<k0fee> thanx
<infinity> k0fee: #ubuntu
<apw> k0fee, 11? what release was that
<infinity> apw: I assume he means either 11.04 or 11.10
<apw> is that like natty?
<infinity> k0fee: Anyhow, old releases live at http://old-releases.ubuntu.com/ubuntu/ ... Any support beyond that, you might find from #ubuntu, or you might be on your own, but this is definitely not the place to ask. :P
<k0fee> yes
<k0fee> i've been googling for over a day on this, just love natty, know it's old but love "her" ;)
<k0fee> want to put couple regular apps on it from the repo 
<k0fee> ok i'll leave have a good one
<jtn> rtg/whoever: re the Wacom Intuos driver update you pushed for me a couple of days ago with today's xubuntu daily cdimage (containing kernel 3.13.0-18.38), and confirm that it now just works out of the box. Thanks again.
<jtn> Er, that's garbled. What I mean is, I tried today's xubuntu daily and it worked.
<apw> jtn, what was the bug number, it is best to feed that back in the bug as well
<jtn> apw: I'm not aware that there was ever a bug. I just came on here and asked. I believe that resulted in a set of cherry-picks such as this one: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=637c04c4e1c8a9d1f1dce9c61bcf58ee3dc73297
#ubuntu-kernel 2014-03-20
<arrith> the kernel freeze is coming up and i would like to help fix Bug #1287966: "DisplayLink USB Graphics not supported by Ubuntu Kernel" before it passes, or find out that it's no longer a bug. the bug link is: https://bugs.launchpad.net/ubuntu/+source/linux-lts-saucy/+bug/1287966 (and a related blog post: http://plugable.com/2014/03/06/displaylink-usb-2-0-graphics-adapters-on-linux-2014-edition ).
<ubot2> Launchpad bug 1287966 in linux-lts-saucy (Ubuntu) "DisplayLink USB Graphics not supported by Ubuntu Kernel" [Undecided,Confirmed]
<arrith> would it be better to post about investigation into that on a bug, on the ubuntu kernel mailing list, here in the irc channel, or somewhere else?
<jtn> apw: would it be useful to add my Wacom success report to bug 1293725, or is that for your own use?
<ubot2> Launchpad bug 1293725 in linux (Ubuntu Trusty) "linux: 3.13.0-18.38 -proposed tracker" [Medium,Fix released] https://launchpad.net/bugs/1293725
<bjf> jtn, that's just for internal tracking
<jtn> OK. Well, it doesn't much matter, since it all works and no-one need do anything. Just wanted to share the \o/
<stag019> what are the odds that ubuntu 14.04 gets linux kernel 3.14 over 3.13?
<antarus> I'm not on kernel team, but my impression was that the odds were 'none'
<stag019> news articles from mid february keep mentioning they've been toying with 3.14
<antarus> yeah they have weekly kernel meetings, I wonder if they publish minutes
 * antarus only pays a brief sort of attention
<antarus> https://wiki.ubuntu.com/KernelTeam/Meeting
<antarus> maybe check there?
<stag019> was just reading that as you mentioned it :P
<stag019> The 3.13.0-15.35 Trusty kernel is available in the archive. This is bssed on the v3.13.5 upstream stable update. Our unstable branch has also been rebased to track the latest v3.14-rc5 release. 
<stag019> from 3/3
<antarus> other than that, hide out here and eventually someone will wake up and answer for real ;)
<stag019> im pretty sure it would have to be out of rc before the kernel freeze on april 3rd, but if that happens i wonder how much time theyd need to test it
<UserError> Trying to get all the ARM bloat removed before then
<ppisati> yo
<apw> stag019, none, the kernel will be 3.13 based, unstable is just our branch for the next release
<stag019> thats a shame; is there any way any small patches from 3.14 could be backported in time for 14.04? particularly since it's a long term release
<apw> stag019, you have to pick something, and for an lts we are always more conservative.  there are lots of fixes being backported, mostly via stable upstream
<stag019> where would i be able to check if the particular fix i had in mind has already been backported and if it isnt, where could i suggest it?
<apw> you could look in our git repo, or you could tell me the sha1 of that fix upstream
<apw> if it isn't you would need to file a bug, and put the details in there, and tell us the bug #
<apw> stag019, ^
<stag019> okay yeah i just checked it it's still bugged; where would i file a bug report?
<stag019> https://launchpad.net/ubuntu/+source/linux
<stag019> there?
<apw> stag019, yes, and include the sha1 of the fix, and once it is filed let us know here the bug#
<stag019> submitted: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1295032
<ubot2> Launchpad bug 1295032 in linux (Ubuntu) "3840x2160 fails with 30Hz with HDMI" [Undecided,New]
<apw> tseliot, if you have any contact with the nvidia tester for that thing you refered to me for saucy, you might poke them else it will languish
<tseliot> apw: I'll send him an email, thanks
<tseliot> apw: ok, email sent. Hopefully we'll get feedback soon
<apw> stag019, test kernels in the bug
<apw> "there are test kernels in the bug" rather than "TEST NOW"
<henrix> rtg: did you received any feedback from Dan on the ioat patches backport?
<henrix> rtg: they definitely seem to be stable material
<henrix> rtg: but i was holding queuing them for 3.5 stable to see if he replies to your email
<rtg> henrix, nope
<henrix> rtg: ok, cool. i'll wait a few more days
<rtg> but I agree, they do seem like stable material.
 * henrix can't hold them for too long as next 3.5 release will be the last one ;)
<rtg> henrix, I've been able to test the ioat driver on real HW. I don't know for sure that code gets used, but it doesn't seem to have broken anything.
<henrix> rtg: and the feedback on the bug report seems to be positive as well
<henrix> rtg: i'll probably just reply to your email adding some more pression on the author :)
<rtg> henrix, I forgot to look if my tester posted some results.
<henrix> rtg: he did
<rtg> henrix, what is that bug number ? 
 * apw imagines henrix putting the reported in a "pression" a cafetiere/french press
<henrix> rtg: bug #1291113
<ubot2> Launchpad bug 1291113 in linux (Ubuntu Quantal) "Intel igb driver infinite loop in ksoftirqd, uses 100% of cpu 0" [Undecided,In progress] https://launchpad.net/bugs/1291113
<rtg> henrix, based on his test feedback I'm gonna propose those patches for SRU
<henrix> rtg: ack
<henrix> apw: i guess i meant 'pressure'...? :)
<apw> henrix, probabally, the the vision you gave me was much nicer
<henrix> :)
<caribou> anyone of you having problems with Mumble's Push To Talk (PTT). Can't seem to get it to work anymore
<caribou> I know if OT here, but many people here use Mumble
<apw> caribou, is working for me on T
<caribou> apw: yeah, working for many others I checked with, but thanks for checking
<rtg> sforshee, do you have the iwlwifi bits in a branch somewhere ?
<sforshee> rtg: no but I can push them real quick
<rtg> sforshee, thanks
<sforshee> rtg: git://kernel.ubuntu.com/sforshee/ubuntu-trusty.git iwlwifi-fw-dump
<rtg> sforshee, /home/rtg/ukb/trusty/armhf/master-next/ubuntu-trusty/drivers/net/wireless/iwlwifi/mvm/debugfs.c: In function 'iwl_dbgfs_fw_error_dump_release':
<rtg> /home/rtg/ukb/trusty/armhf/master-next/ubuntu-trusty/drivers/net/wireless/iwlwifi/mvm/debugfs.c:180:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
<rtg>   vfree(file->private_data);
<rtg> sforshee, Its probably safe to just disable iwlwifi for armhf
<infinity> rtg: In theory, iwlwifi could run on armhf fine, if you find an armhf device with a minipci header.
<infinity> rtg: (ie: fixing the bug would be better, but disabling it probably won't bite us anytime soon)
<rtg> infinity, it won't run for shit if the kernel doesn't compile, but that is a different problem. I'm looking into it.
<smoser> hey.
<smoser> http://paste.ubuntu.com/7126278/
<smoser> i think that errored because the package installation says that my cpu is not right for this deb.
<smoser> but i do not care about that.
<smoser> is there a way to make it not fail ?
<infinity> rtg: I do think we need to do an audit of all the PCI/USB/etc devices that are disabled on ARM kernels and sort out why, as we're probbaly only a generation away from ARM machines that people will want to hang random devices off of.  But I'd agree that "just disable the silly thing" is the easiest way out right now, if finding the midding prototype proves to cross some arch/* boundaries or something equally intractable.
<infinity> s/midding/missing/
<rtg> infinity, vfree _should_ exist for armhf. I'll figure it out.
<infinity> smoser: What's that's saying is that you don't have /proc mounted.  Why?
<infinity> smoser: Expecting any package installation to work without all the right virtual fielsystems mounted is a crapshoot.
<jtn> rtg: (Just FYI, I tested a Trusty daily cdimage with the Wacom Intuos fix you pushed, and my tablet Just Worked. Thanks again.)
<smoser> infinity, i can mount /proc. but thats not what it says is the error.
<infinity> smoser: It does if you read up.
<infinity> smoser: As in, the line immediately above the one you're talking about.
<smoser> no. it comlains it can't find proc. 
<infinity> ... which is how it's checking the CPU caps.
<smoser> suppose I *did* hav proc, and it did not find pae
<smoser> i dont want it to fail then
<smoser> i dont care if it can't run.
<infinity> I can only assume this is mostly hypothetical, as I doubt you're doing this on a system without PAE.
<infinity> Especially since it's amd64.
<smoser> whether or not that is the caes, isnt' it generally bad packaging to fail the install ?
<smoser> because the thing wont run.
<infinity> smoser: No.  The preinst is there intentionally to stop you from shooting yourself in the foot on upgrade.
<infinity> I suppose they could add an "IDONTCAREABOUTPAE" environment check or something, but in your case, mounting /proc will fix your issue, which you should be doing anyway.
<infinity> And the number of people who would legitimately need IDONTCAREABOUTPAE would be vanishingly tiny.
<infinity> Since the usecase here for you is "building images to run on another system", and the odds of someone running an image builder on a PPro from 1996 seem slim.
<smoser> for this specific case, yes.
<infinity> The only other legit case I can think of is that batch of PentiumMs that had PAE but didn't advertise it.
<infinity> And I think there's a kernel hack for that.  Not sure if we carry it.  But the preinst could perhaps check for that model/stepping and not scream.
<infinity> (It's a bit icky, though, as not every CPU in that class had PAE, just some subset)
<smoser> i really dont care about the specifics. i thikn its generally wrong to fail thepackag install.
<smoser> apt-get install webcam-software
<smoser> E: you do not have webcam plugged in. sorry.
<infinity> smoser: It's genuinely not wrong in a case like this.  preinst checks to stop you from hosing your system are rare, but an entirely appropriate use of preinst.
<infinity> smoser: "You don't have a webcam" is entirely different from "after you do this upgrade, rebooting your system WON'T WORK".
<smoser> its really not that different.
<infinity> If it's any small consolation, we can drop that check in 14.10
<smoser> because that isn't the case
<infinity> smoser: That's absolutely the case.  On upgrade from precise to trusty, if you have a non-pae machine with linux-generic installed, you'll get a linux-generic that doesn't boot on your computer.  Refusing the upgrade is better than breaking the computer.
<smoser> "after you do this upgrade, rebooting your system WON'T WORK... until you pick the old kernel that is still perfectly happiliy installed there (and may even be a newer version than this one to grub)"
<infinity> Yes, because every user knows how to enter grub and ask for a different kernel.
<infinity> (And the old kernel will definitely not be earlier in the list, we reverse sort on version for a reason...)
<smoser> i didn't upgrade
<smoser> i installed a package
<smoser> the package had no context as to whether or not it would be booted.
<infinity> Yeahp.
<smoser> anyway.
<smoser> thanks for arguing. 
<infinity> You didn't upgrade.  But the kernel ABI changes meaning every kernel is a new package means it's pretty hard to detect upgrade versus install.
<sforshee> rtg: I doubt anyone uses intel wireless with arm, though surely vfree exists for arm. Probably just an include which is needed.
<sforshee> rtg: I'll look into it in a few minutes, attending to another fire drill right now
<infinity> sforshee: Yeah, I doubt anyone uses it currently either, but they could.  There are ARM devices with PCI busses, and some with minipci, so it's possible, just not likely.
<infinity> (But I've run e1000 NICs on powerpc, for instance, so assuming "Intel" == "x86", is usually a bad assumption)
<hallyn> apw: do you know if the kernel in canonical-kernel-team ppa for precise would have http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commitdiff;h=bdb820eab084eb94fc098fe7154deb0a5a8a75b6 ?
<hallyn> i mean...  i assume not.  if not, can i do something to kick off a ne wbuild?
<apw> hallyn, are you asking if the P kernel has that ?
<sforshee> rtg: #include <linux/vmalloc.h>
<hallyn> apw: no, the kernel in the canonical-kernel-team ppa
<hallyn> no, that's quite old isn't it.
<apw> but in the 3.2.0-* versions ?
<hallyn> no, 3.13
<apw> we have about 5 kernels in P
<apw> so you are asking if the lts-backport-trusty has it?
<hallyn> actually i should have just gotten a newer kernel from stgraber's ppa - i'm going to reboot and see
<hallyn> yeah i guess that was my q:)
<apw> what version is it
<hallyn> 3.13.0-8-generic #28~precise1-Ubuntu SMP Tue Feb 11 18:53:36 .  so obviously not.
<UserError> eol meta is the best from that ppa
<hallyn> rebooting, biam
<UserError> i think they are on 18
<apw> m == month seemingly
<apw> hallyn (not), it is -18 in the PPA as is the associated meta, so no idea why you have -8, and -17 had the commit you wanted in it
<infinity> apw: If hally ever comes back, teach him how to use --contains.
 * infinity was JUST going to mention that it was in -17...
<apw> no idea where he got his -8 from even
<infinity> apw: I assume from the PPA long ago, and then never upgraded. :P
<apw> hallyn, it is -18 in the PPA as is the associated meta, so no idea why you have -8, and -17 had the commit you wanted in it
<phillw> Hi, I've successfully made (with a lot of help) a non-pae kernel for 14.04 community respin. I generate the .deb files using 'make deb-pkg' but it seems a PPA cannot import ready made .deb files. Could someone please give me a link so that I can add and maintain the kernel during 14.04.
<cristian_c> Hi
<cristian_c> I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
<ubot2> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
<cristian_c> I've to open an upstream bug report
<cristian_c> there is this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
<cristian_c> I've read it, but I've got some doubts:
<cristian_c> for example: Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
<cristian_c> What kernel does it refer to, exactly?
<apw> the latest linus' kernel, we build upstream kernels for that, but you know that cause we said that last time 
<cristian_c> ok
<cristian_c> apw, this:  http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<cristian_c> apw, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc7-trusty/ ?
<cristian_c> apw, And then: While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
<cristian_c> How can I find the commit?
<cristian_c> Any ideas?
<phillw> hi folks. I've had my question answered, to use 'debuild -S -sd' which was what I thought I needed :)
<cristian__c> Has anyone answered to me?
<cristian__c> uhm
<rtg> dannf, so, all of your x-gene crack is merged into master-next. please give it a spin.
<dannf> rtg: awesome
#ubuntu-kernel 2014-03-21
<phillw> hi, is there a guru about?
<phillw> the new kernel for non-pae is finishing off building... That means I have .deb I need a bit of help to get it into ppa
<phillw> I also need a bit of help to name the kernel, as the source code is 3.13.0 and I pull in 3.13.0-18 from Â /boot/config-3.13Â  on my VM that hosts the latest desktop
<infinity> phillw: I'd imagine renaming it the same as apw's kernel in https://launchpad.net/~apw/+archive/nonpae/+packages would make sense.
<infinity> (Or, just basing on his packaging)
<Sarvatt> apw: nice, thanks for doing that ppa
<phillw> infinity: rather than duplicate things, is apw happy to keep the 3.13 kernel updated for non-pae? I understand that 3.13 is not a lts kernel from linux kernel https://kernel.org/category/releases.html
<phillw> infinity: I'm in my usual confused state :)
<Sarvatt> phillw: 3.13 is a lts kernel, ubuntu kernel team is maintaining the stable releases of it but due to drama they wont list it on that site :P
<infinity> phillw: 3.13 is going to be a Canonical-maintained LTS kernel for 14.04
<phillw> infinity:  The VM is building .deb files which I'm used to. did you use 'Â debuildÂ -SÂ -sa' to get your build into your ppa?
<infinity> (But I have no idea if Andy intends to keep rebasing that kernel, or if it was just a proof of concept, you'd have to ask him about it)
<Sarvatt> yup
<Sarvatt> just have to make sure to fakeroot debian/rules clean before updating the changelog and using debuild -S -sa to make it work in the ppa
<Sarvatt> the kernel build system is weird
<phillw> Sarvatt: it is a minor rebuild... https://wiki.ubuntu.com/phillw/non-pae Needless to say, I've had a heck of a lot help on this. the next step is to have it in ppa so any flavours that base off *buntu can get updates.
<phillw> the actual .deb files are already generated
<phillw> Sarvatt: why does http://packages.ubuntu.com/trusty/linux-source-3.13.0 have .13 release when the system is .18 ?
<phillw> Hi, anyone used to building kernels on their local machines?
<phillw> infinity: sorry to ping, but are you still about?
<ppisati> yo
<miseria> "blanca es mi piel, negro es mi cabello, llevo en mi carazon toda la generacion y un rechazo a la discriminacion" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<UserError> ppisati , thank you for accepting the arm bloat issues as legitimate 
<ppisati> UserError: ???
<UserError> on launchpad, in the x86 kernel
<ppisati> UserError: lp bug?
<UserError> yes
<ppisati> UserError: which one?
<UserError> all of them
<ppisati> sorry, i don't get it
<UserError> For example the exynos drivers, i.MX Freescale AHCI, etc (to be removed)
<cristian_c> Hi
<cristian_c> I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
<ubot2> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
<cristian_c> I've to open an upstream bug report. There is this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
<cristian_c> I've read it, but I've got some doubts:
<cristian_c> for example: While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
<cristian_c> Any ideas?
<tseliot> apw: Aaron replied in the bug report
<tseliot> cristian_c: that's for when you need to file a bug report against the upstream kernel
<tseliot> in that case, upstream developers will only be interested in the upstream kernel, not in the ubuntu specific release (where we apply our own patches)
<cristian_c> tseliot, ok, but what commit have I to specify?
<tseliot> cristian_c: maybe check the "COMMIT" file for your kernel? For example here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc7-trusty/
<cristian_c> tseliot, ok, is it right?
<tseliot> cristian_c: it depends on the kernel you downloaded for testing
<cristian_c> tseliot, summarizing: I try the 3.14-rc7 kernel and I specify the v3.14-rc7 and I note the v3.14-rc7 commit in the upstream bug report. Is it right?
<tseliot> cristian_c: yes, that would be the tag. That's correct
<cristian_c> tseliot, ok
<cristian_c> thanks :)
<tseliot> np
<cristian_c> then, I use the content of the COMMIT file in the directory of the upstream kernel I try
<cristian_c> ok
 * tseliot nods
<cristian_c> :-)
<speakman> Hi folks. have you experienced any problems with netconsole? I'm running it as a module atm, but although all parameters are setup correctly there is nothing being sent from the host.
<speakman> It's actually Debian kernel 3.2.0-4-amd64 but I guess you've probably heard if there is any problems with netconsole.
<Whoopie> Hi, you enable CONFIG_ARPD for saucy kernels. Any chance to get also enabled in raring kernels? It was mentioned here (https://lists.ubuntu.com/archives/kernel-team/2013-August/032046.html) that it could be considered.
<apw> Whoopie, rtg's response there implied that if noone whined about it we could consider it, as saucy went out with it enabled i assume it might be possible.  that said raring is likely going off support already isn't it?
<Whoopie> apw: even for the backported kernels to precise?
<Whoopie> rtg: I just asked the following question: Hi, you enable CONFIG_ARPD for saucy kernels. Any chance to get also enabled in raring kernels? It was mentioned here (https://lists.ubuntu.com/archives/kernel-team/2013-August/032046.html) that it could be considered.
<rtg> Whoopie, Thiswill only have an impact on Raring LTS kernels in Precise. Is that what you are using ?
<Whoopie> rtg: yes
<rtg> Whoopie, do you have a bug started ?
<Whoopie> rtg: no
<Whoopie> rtg: should I open one?
<rtg> yup
<Whoopie> all right
<apw> there are something like 3-4m life in that kernel
<rtg> apw, the Raring LTS is supported until the end of Precise, isn't it ?
<apw> rtg, until 14.04 is backported then the other lts kernels end
<apw> at around 14.04.1 timeframe was my understanding
<Whoopie> apw: 3-4m is a lot, and some may stay with that kernel and won't upgrade.
<apw> 3-4 is a fair time, though people who need the feature presumably arn't using that kernel for the other 10m or so it has existed
<Whoopie> nevertheless, opened a bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1295666
<ubot2> Launchpad bug 1295666 in linux (Ubuntu) "Please enable CONFIG_ARPD in Raring LTS kernels for Precise" [Undecided,New]
<apw> rtg, btw i have been running -19 on my kit here ok so far
<rtg> apw, I'm gonna start testing on a few platforms this morning. if it  looks good I'll upload in a few hours. Does that work for you ?
<apw> rtg, ack, am spreading the love round here right now
<rtg> dannf, install your x-gene with http://kernel.ubuntu.com/~rtg/3.13.0-19.39/. There is still time to fix issues before I upload.
<apw> rtg, both xen and kvm seem to work on this kernel too ...
<apw> smb, regraded to your -release versons of xen and things are basically working modulo the known issues
<smb> apw, ack, I am right now starting to look into those
<rtg> apw, cool. I checked out the KVM patches myself as well.
<rtg> apw, perhaps I should just upload and be done with it. it appears to be working on all of my kit.
<apw> rtg, i well it doesnt seem to regress at least
<rtg> apw, We can always pickup any x-gene patches from dannf in the next upload, which will likely be Mon/Tues.
<apw> yeah
<apw> rtg, the next stable is going to be a heap and no mistake 
<rtg> apw, how many ?
<apw> rtg, 149 so far
<rtg> egads
<dannf> rtg: installing..
<dannf> rtg: so far so good
<rtg> dannf, thats good news 'cause I've already uploaded :)
<rtg> though we'll have at least 2 more before freeze
<dannf> ack
<dannf> thx!
<dannf> rtg: one small typo - ./modules/sata-modules:ahxi_xgene ? (x/ahxi/ahci/)
<dannf> rtg: want me to submit a patch, or is that good 'nuff?
<rtg> dannf, dang. I can fix it.
<rtg> dannf, patch pushed
<dannf> ta
<unicodestring111> I updated my kernel as instructed by the update manager , now some websites are not opening , IT IS NOT MY ISP FAULT - THE SAME ISP 'S SAME CONNECTION ON WINDOWS RUNS THE WEBSITE FINE - TE WEB PAGES WERE OPENING BEFORE AS WELL
<apw> unicodestring111, reboot into an older kernl and see if it goes away
<apw> unicodestring111, if it goes away then it was the kernel update, if not it is something else, say something else that came in the same batch of updates
<dannf> rtg: and i see you were just copying what i typed, sorry -  my bad.
<rtg> dannf, np
<ParkerR> If I am wanting to backup the boot parttiion of my nexus 7 (/dev/mmcblk0p2) can I just dd it to a file? From everything I have seen it should be 8MB but when I dd it to a file it's 8.4MB. I am wanting a backup that I am able to flash with fastboot
<ParkerR> Ok nvm. Just tested flashing it with flashboot and it worked. I figured if anything messed up I could just redo it. Glad that I didnt have to :D
<miseria> "blanca es mi piel, negro es mi cabello, llevo en mi carazon toda la generacion y un rechazo a la discriminacion" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-03-22
<phillw> Hi folks, why does this occur ?
<phillw> ali@amjjawad:~/src$ sudo apt-get source linux-image-$(uname -r)
<phillw> Reading package lists... Done
<phillw> Building dependency tree       
<phillw> Reading state information... Done
<phillw> Picking 'linux-upstream' as source package instead of 'linux-image-3.13.5'
<phillw> E: Unable to find a source package for linux-upstream
<infinity> phillw: Because there is no source package corresponding to the kernel you're running?
<infinity> phillw: If "uname -r" is reporting 3.13.5, that's not an Ubuntu kernel, I'm not sure how you expect apt to magically find the source to a kernel it didn't install.
<phillw> infinity: I tried ali@amjjawad:~/src$ sudo apt-get source linux-image-linux 3.13.0-18.38
<phillw> Reading package lists... Done
<phillw> Building dependency tree       
<phillw> Reading state information... Done
<phillw> E: Unable to find a source package for linux-image-linux
<phillw> ]
<infinity> Pretty sure you can figure out what's wrong with your second example without my help.
<phillw> which is what I need, but the VM is a server install and not a DE. This has bitten me on the bum before :)
<phillw> infinity: I'm taking the easy(ish) route of installing DE lubuntu and then using terminal access to it do work.... Does that sound logical?
<infinity> phillw: Pretty sure this is entirely the wrong channel to ask for basic apt-get and packaging help.
<infinity> And what terminal you use is completely irrelevant.
<phillw> infinity: the server kernel is 
<phillw>  uname -a
<phillw> Linux amjjawad 3.13.5 #1 SMP Wed Mar 5 23:17:34 GMT 2014 i686 i686 i686 GNU/Linux
<phillw> ali@amjjawad:~/src$ 
<phillw> which is not the -18 release
<phillw> the server kernel seems totally out of step with the DE one. 
<infinity> phillw: Look, I'm not trying to be a jerk here, but if you can't sort out the basics of which kernel a computer is running, and how to make "apt-get source" go, do you really think you're the best man to maintain a fork of the Ubuntu kernel for 5 years?
<phillw> infinity: I've been a tester for 5 years... if ubuntu cannot keep their kernels in sync during testing, how do you expect anyone to actually commit the time to for a kernel for 6 years, when you've already been tild it is not an lts kernel?
<infinity> Did any of that sentence make sense?
<infinity> We keep our kernels in sync, but we don't magically keep them in sync with what you have installed.  The archive marches forward.
<infinity> As for "not an lts kernel", pretty sure our support commitment for 5 years tells a different story.
<phillw> ubuntu kernel team are on their own with 3.13 
<infinity> They know.
<phillw> indeed,, and I can build .deb from it. What seems to be the issue is that I offered to make the non-pae kernel available to others and would update it within about 48 hours. The best way to do that was to make it available by PPA. It looks less and less likely that I will get the help to make that happen.
<phillw> the simple fact that server kernel is <> to desktop kernel is already a major snag.
<phillw> I've dedicated a VM and ipV4 as a build machine... seems little help coming back :(
<phillw> * end rant*
<infinity> phillw: The kernel *running* on the build host has no bearing on the kernel you're BUILDING.
<phillw> infinity: it does if you follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel :P
<phillw> apt-get source linux-image-$(uname -r)
<JanC> that's for rebuilding the current kernel with different options, I guess
<infinity> phillw: That wiki page assumes a little bit of intelligence, and the ability to rewrite "linux-image-(uname -r)" as "linux-image-[TheOneIReallyWant]"
<JanC> you want the latest available kernel
<infinity> phillw: If all you're doing is blindly following instructions, I don't think anyone should ever run the output of your kernel builds.
<phillw> infinity: and I tried 3.13.0-18-generic
<infinity> phillw: Furthermore, there's more to making a *different* kernel flavour than just grabbing the source and recompiling.
<phillw> indeed there is. but build the kernel I can do for non-pae.... It was not originally planned for me to offer a non-pae kernel for other teams that deal with old computers, but I seem to have been roped into it.
<infinity> So, get unroped.
<infinity> Who "roped" you into it?  The only person I've seen talking about you doing this is you.
<phillw> I was not on the tech-board when they dropped non-pae
<phillw> lubuntu support older machines. I'll just stay with keeping an non-pae kernel for other teams... Arguing and fighting sucked all my energey out the las time... No wonder bodhi-zazen left and moved to ferdora... you are too busy to help - no new people being encouraged.. hence the end of ubuntu beginners team... No apprentices? ... it will die.
<infinity> phillw: This is the ubuntu-kernel channel, not the ubuntu-beginners channel.  Just saying.
<phillw> infinity: there is no ubuntu-beginners channel.. there is also NO way for people to be mentored and learn. This will mean that ubuntu will die of old age as there is no system in place to bring 'new blood' in... Not my call, just a major mess up. 
<phillw> I beg, nag people I knew for assistance and document up everything that they tell me. you complain as to the instructions I was given by the founder of ubuntu-beginners-team who is now fedora person. He provided me with instructions the make .deb files for a non-pae kernel. what he does not have time for is get a decent set of instructions to add the source to make the files when you are telling to ignore http://packaging.ubuntu.com/html/getting-
<infinity> phillw: I've mentored a lot of people, but I also expect a base level of reading comprehension and problem solving skills.  If you copy and paste EVERY ERROR MESSAGE YOU SEE and expect someone else to solve it for you, you're not cut out for this.
<phillw> infinity: the error message was 'are you in source area'... I've asked what extra do I need? ... with no dis-respect, I have looked up and offered up what I thought would be correct... 
<phillw> if my checking is not suffifient... c'est la vie. I've done the research I can do.... 
<JanC> phillw: you got a typo in your attempt to get the latest Ubuntu kernel, and infinity is saying you should be able to see that from the error message yourself
<JanC> eh
<stag019> apw: new comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1295032
<ubot2> Launchpad bug 1295032 in linux (Ubuntu) "3840x2160 fails with 30Hz with HDMI" [Medium,Triaged]
<apw> stag019, nope, i just checked that that kernel has the commit you indicated fixed the issue applied
<stag019> that's odd, could i have done anything wrong on my part?
<apw> stag019, well it just means that the fix indicated is not sufficient to fix the issue on its own and we have no information as to what else is needed
#ubuntu-kernel 2014-03-23
<nusch> hello, do you have any reciepe how to recompile ubuntu kernel with custom patches and sign with own UEFI keys ?
<jarkko> where can i contact about ralink wifi usb stick that spams the dmesg with timeout errros?
<jarkko> 2882.914044] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 2 in queue  similar lines
<cristian_c> Hi
<cristian_c> I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
<ubot2> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
<cristian_c> I've to open an upstream bug report. There is this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
<cristian_c> I've read it, but I've got some doubts yet:
<cristian_c> for example: [7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant):  While booted into the newest upstream mainline kernel only, execute the following via a terminal, and paste the results
<cristian_c> what information from /proc can I add to the upstream bug report?
<cristian_c> and then: [X.] Other notes, patches, fixes, workarounds:  Please provide a link to your Launchpad bug report. 
<cristian_c> What exactly can I do about this specific point?
<cristian_c> Any ideas?
<jarkko> cristian_c:  ##kernel channel
<cristian_c> jarkko, ?
<cristian_c> about first or second question?
<jarkko> cristian_c: i think they can help you forward
<cristian_c> about first or second question?
<cristian_c> Has anyone got any ideas about the questions?
<infinity> BenC: *pester, annoy*
#ubuntu-kernel 2015-03-16
<apw> bcowan (N,BFTL), well filing bugs against the ubuntu linux package would be a good start, as upstream is also borked for some will mean that may need reporting upstream too
#ubuntu-kernel 2015-03-17
<alkisg> Hi, I have an i5 PC that half of the times doesn't see the usb devices at all, doesn't even power them up. Ubuntu 12.04 32bit with the lts-trusty kernel.
<alkisg> Should I try with some newer kernel?
<apw> alkisg, sounds like you should file a bug against the kernel, and we can suggest kerenls to try indeed
<alkisg> I have the pc here at the support office, so today I'm able to try sthings, while later on I'll have to send it back and it'll be difficult to provide more feedback at the bug report...
<alkisg> ...so while I understand that a bug report is the proper thing to do, in this case IRC might help more than a launchpad bug... and of course I can file it for reference if I find a workaround...
<alkisg> Is there any usb-related modprobe/rmmod that I can do?
<alkisg> To try to reload the usb devices?
<apw> alkisg, well file the bug so we have somewhere to ram logs etc
<apw> alkisg, and i'd say we want a dmesg and lsusb at a minimum from the broken state
<apw> alkisg, so like file a bug from the machine with it "ok" and then get it into the bust state and get the dmesg and lsusb and attach those
<smb> While irc may work quicker for you it is not helping in coming up with advice. Not working half of the time is rather vague and obscure. Generally you could try to figure out whether when not working the usb controllers can be initialized by checking dmesg for usb messages.
<apw> alkisg, so we can see the difference
<alkisg> I'm at the broken state now, please give me a moment to explore...
<alkisg> Thank you btw
<apw> alkisg, and then i would recommend trying a v3.19.1 kernel from the mainline archive to see if this is fixed in mainline "near tip"
<alkisg> Gotcha
<apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
<apw> and if that is relaible we can look at finding out when it got fixed
<alkisg> echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
<alkisg> echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind
<alkisg> ==> allowed me to make the keyboard and mouse work without reboot
<alkisg> I'll test first to see how reproducible it is here (the user reported half of the times, just want to check if it is indeed frequently reproducible...)
<smb> which shows one missing piece of information is that we are talking about usb3 ports... are there still usb2 ports available. You could try to see whether devices connected there are more reliable
<smb> alkisg, ^
<apw> alkisg, right, so what we really care about is why it failed the first time ... as it clearly can connect both "working" and "broken"
<apw> and that would be visible per
<apw> perhaps in the differnce in a good and bad dmesg
<alkisg> None of the ports give power to the mouse
<alkisg> (collecting more info, patience please and thanks again for the help...)
<infinity> zequence: Want to get smoketesty on your kernels so they're ready to go when the rest are?
<alkisg> At the broken state: # lsusb -v > lsusb
<alkisg> Couldn't open device, some information will be missing
<alkisg> Couldn't get configuration descriptor 0, some information will be missing
<alkisg> After entering the two "echo" commands, lsusb -v no longer complains
<alkisg> Installing a newer kernel...
<alkisg> It didn't happen with 4 rc4 in 4 tries... I'll try more tomorrow, thank you guys
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<crshman> Hey Guys, not sure who to notify or if this is the right place, but it looks like the drm-intel-nightly builds stop going through aroudn 3/11
<crshman> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/BUILD.LOG
<apw> crshman, yep ... looking at it right now as it happens
<crshman> ok cool, just wanted to bring it up so it gets some eyes
<crshman> I follow that build very closely for intel fixes :)
<apw> not that close if it has been broke since the 11th :)
<crshman> :P
<crshman> I upgrade with that kernel once a week
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 24th, 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.
<apw> crshman, ok i think those builds are repairing self now, and should be done in the next hours
<crshman> @apw awesome thanks!
#ubuntu-kernel 2015-03-18
<AfterDarkness> hello i have a question: i want to apply pf patch and update my kernel to 3.19, how can i do that while ensuring the amd drivers still work? 
<AfterDarkness> when i upgraded the kernel i had to purge fglrx in tty as my disktop will not load
<ppisati> kees: i'm a bit confused about ARM_KERNMEM_PERMS (and DEBUG_RODATA) vs DEBUG_SET_MODULE_RONX
<ppisati> kees: if i read it correctly, they do the same thing (make all sections but text NX and RO)
<ppisati> kees: but the second seem to be geared towards modules only (IOW it seems to to the same dinamically on module loading etc)
<ppisati> kees: are these options complementary? can i turn on all of the or ARM_KERNMEM_PERMS (and DEBUG_RODATA) suffice to cover all the cases?
<ppisati> kees: and, last question, what happens when some legit code try to patch a text section? (e.g. JUMPLABELs)? does it handle that case too?
<Zhenech> Heya, there is a bug in a DKMS package for Vivid: https://bugs.launchpad.net/ubuntu/+source/sysdig/+bug/1419402 - I proposed a patch, how do we get from there?
<ubot5> Ubuntu bug 1419402 in sysdig (Ubuntu) "sysdig-dkms 0.1.87-1: sysdig kernel module failed to build" [High,Confirmed]
<apw> Zhenech, is that already uploaded to debian ?
<Zhenech> apw, debian has no problem, as debian does not ship .19 in jessie
<Zhenech> .19 is in experimental, and sysdig is fixed there too
<Zhenech> (debian bug for experimental is linked in lp)
<apw> bah, rmadison is hating me for debian
<apw> Zhenech, ok, using the right machine it works much better
<Zhenech> become a DD and use dak on some debian.org host ;-)
<apw> heh .. one day indeed
<apw> Zhenech, anyhow, first step is bringing it to my attention
<apw> Zhenech, and i'll have a look
<Zhenech> check :)
<Zhenech> I hoped subscribing kernel team would be good enough
<apw> Zhenech, we get a heck of a lot of bugs subbed to us, it is easy to miss them, cirtianly coming here gets our attentoin
<Odd_Bloke> bjf: I'm seeing a kernel test failure (when running in GCE): http://paste.ubuntu.com/10622256/  Is that an actual problem?
<bjf> Odd_Bloke, which series?
<Odd_Bloke> bjf: trusty.
<bjf> Odd_Bloke, i'm not seeing that particular error with my testing. sbeattie ^ ?
 * sbeattie looks
<sbeattie> yeah, that's a problem if true. I've not seen it in my testing, either.
<sbeattie> Odd_Bloke: can you verify that wine and qemu-kvm-extras-static are not installed?
<Odd_Bloke> Checking.
<Odd_Bloke> Neither is installed at instance spin-up, let me wait for the test script to finish and I'll check then as well.
<sbeattie> Does GCE run our kernel or google special sauce?
 * sbeattie hasn't looked at GCE before.
<Odd_Bloke> Our kernel, I believe.
<Odd_Bloke> Neither installed after the test has run.
<Odd_Bloke> sbeattie: You should be able to get to ubuntu@130.211.100.128, if you want to have a poke around.
<sbeattie> Odd_Bloke: this looks to be the culprit:
<sbeattie>  /etc/sysctl.d/99-gce.conf:# randomizes addresses of mmap base, heap, stack and VDSO page
<sbeattie>  /etc/sysctl.d/99-gce.conf:vm.mmap_min_addr = 0
<apw> isn't that below the minimum we allow ?
<sbeattie> kees: do you know why GCE would be doing that?
<Odd_Bloke> This is following the recommendation at https://cloud.google.com/compute/docs/tutorials/building-images#kernelbuild
<Odd_Bloke> Which has "CONFIG_DEFAULT_MMAP_MIN_ADDR=65536" and 'echo "vm.mmap_min_addr = 0" > /etc/sysctl.d/mmap_min_addr.conf' as equivalent recommendations.
<Odd_Bloke> Or maybe not equivalent, I don't know enough about sysctl to make that statement.
<Odd_Bloke> Would it make sense for that 0 to be a typo?
<sbeattie> I would hope it's a typo. They're definitely not equivalent.
<Odd_Bloke> OK, I'll run it past someone at Google to try and work out what they mean.
<sbeattie> Or at least, if not a typo, an insufficient explanation of how to disable it for the very few applications that break because it's set to non-zero.
<sbeattie> Odd_Bloke: I'm logged out of your instance.
<Odd_Bloke> sbeattie: Ack; thanks for taking a look.
<sbeattie> Odd_Bloke: sure thing, thanks for raising the issue.
<Odd_Bloke> sbeattie: Have filed an internal issue for it, and subscribed you; should be fixed soon.
<sbeattie> Odd_Bloke: thanks!
<kees> sbeattie: omg, wtf! no, it should NOT be doing that!
<kees> sbeattie: where is that sysctl coming from? did google build that?
<sbeattie> kees: I think the thing to get fixed is the MMAP_MIN_ADDR section in https://cloud.google.com/compute/docs/tutorials/building-images#kernelbuild
<mterry> Hello!  I'm trying to boot an Ubuntu Snappy image off a thumb drive.  I seem to be getting some kernel panic and a reboot during boot.  How do I dig deeper / work around it?
<mterry> I can't clearly see the panic because it reboots...
<mterry> And there isn't a grub menu so I can modify kernel parameters
<mterry> Though I can edit the thumb drive manually, I'm less familiar with that bit
<apw> mterry, hmmm well i'd suggest taking pictures, and depending on the board does it have one of those header serial ports 
<apw> either of those might get you the panic and a clue
<apw> what are you booting it on as well ?
<mterry> apw, I'm just trying to boot on my laptop
<apw> hmmm
<mterry> apw, I can't take a picture, because the screen disappears so quickly
<mterry> I suppose I could take a movie and take a frame
<apw> a video might get it if you are lucky
<apw> deperate times and all that
 * mterry tries out Ubuntu Touch's video capability
<apw> have you asked in #snappy in case someone else is seeing it ?
<mterry> apw, I sent quick email to the snappy list, no replies yet
<mterry> apw, I don't think this is commonly done yet in snappy world?  I think most people just use beagleboards or kvm
<apw> mterry, right that would be my expectation too  ... so i am not supprised its not perfect
<mterry> apw, asked on #snappy in case I get lucky.  Meanwhile will try to get a pic
<mterry> apw, thanks for help so far!  :)
<mterry> apw, https://chinstrap.canonical.com/~mterry/snappy-panic.png  -- snappy-devel just said "Aren't we using just the generic kernel pkg on x86? If so, you are missing all the modules from the generic-extra pkg, thus my bet is on a missing module"
<mterry> Does that panic look like that makes sense?  If so, I guess my next step is wondering how to get snappy to let me install those modules
<apw> so that looks like systemd exited
<mterry> apw, yeah, says "attempted to kill init"
<infinity> mterry: That's failing to pivot out of the initrd.
 * mterry is super unfamiliar with debugging systemd
<infinity> mterry: systemd isn't even in play yet.
<mterry> ok
<ppisati> mterry: mount the img, download the linux-image-extra pkg corresponding to the kernel used in that img
<ppisati> mterry: and install it
<infinity> mterry: Where's the image you're booting?
<ppisati> mterry: IOW, boot into ubuntu, plug the usb stick, chroot in it, install the pkg, etc
<infinity> Also, how on earth is that taking 3 seconds to get out of the initrd?  What evil is snappy perpetrating?
<mterry> ppisati, well installing on snappy via apt, even using /usr/bin/apt directly, has been unsuccessful for me.  read-only mounts and such.  I guess I can just remount them all rw
<ppisati> mterry: yep, and apt is a symlink but you can find the original apt in /usr/local
<mterry> infinity, http://cdimage.ubuntu.com/ubuntu-core/preview/ubuntu-core-alpha-02_amd64-virt.img is a qcow2 file that I'm booting 
<mterry> ppisati, I think you have that reveresd
<mterry> infinity, I can't speak to the evils of snappy yet ;)
 * ppisati just bought an xps 13
<ppisati> lovely
<mterry> ppisati, they are good laptops besides this oddity!  :)  I also tried booting on another Dell I have here, same result
<ppisati> mterry: ping lool, i know he did some work for snappy and real x86 hw
<infinity> mterry: Right, so that boots fine in kvm.  I'm sure it's failing to find your USB controller due to the fact that someone decided linux-image-virtual was good enough.
<infinity> mterry: s/linux-image-virtual/linux-image-generic/ in the build scripts would likely make it happy for you.
<infinity> Though the -virt in the filename sort if implies it's not meant for real hardware.
<infinity> The tarball builds have the full kernel in them.
<infinity> I'm guessing this "preview" is old?
<mterry> infinity, maybe?  It's still the one the snappy site recommends
<infinity> Well, it's 3.18.0-9, so it's not new.
<mterry> infinity, maybe I need to find out how to build my own new preview then, with -generic.  Thanks for the pointers!
<infinity> mterry: FWIW, snappy switched from -virtual to -generic on Jan 28, and that kernel is from Jan 12.
<infinity> mterry: So, the image is just old and predates the fix.
<infinity> mterry: Sort out how to get someone to make a fresh one, and you'll likely be set (or find instructions on how to turn the daily tarball into a bootable image)
 * mterry hugs infinity for his detective work
<apw> infinity, nice thanks
<kees> sbeattie: yikes
<kees> sbeattie: I'll get them to fix that.
<kees> sbeattie: who did the sysctl file in the ubuntu image? was that someone else reading the "documentation" or was that generated by someone in google?
<sbeattie> Odd_Bloke: do you know the answer to kees' question?
<kees> sbeattie: fire started, docs should be changing shortly, and when cansecwest is over, existing images will likely get reviewed.
<sbeattie> kees: w00t, thanks!
#ubuntu-kernel 2015-03-19
<Odd_Bloke> sbeattie: kees: We (CPC) put the sysctl file together, using the documentation from Google.
<Odd_Bloke> sbeattie: kees: We've just shipped new GCE images which fix the problem. :)
<kees> Odd_Bloke: ok, cool, thanks. sorry the docs were wrong! they should be fixed soon.
<Odd_Bloke> kees: No worries. :)
<jcastro> Hi everyone, I had a guy email me about this bug asking if there are plans to backport it to the HWE kernel in 14.04.2, what do I do?: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1390223
<ubot5> Ubuntu bug 1390223 in linux (Ubuntu Utopic) "Apparmor related regression on access to unix sockets on a candidate 3.16 backport kernel" [Medium,Confirmed]
<jcastro> I am assuming if I just nominated it for trusty without asking first might be bad
<infinity> jcastro: It already has a utopic task, that's all it needs.
<infinity> jcastro: If it's fixed in utopic, it's fixed automatically in lts-u.
<jcastro> oh I see
<jcastro> that makes sense
<mozmck> I'm trying to build packages for 3.18.9 with the rt5 patch - using the debian and debian.master from the vivid kernel at 3.18.7  I'm making progress, but I get several errors in locktorture.c about implicit declarations of functions: _raw_write_lock, _raw_write_unlock, etc
<mozmck> Is it possible that is due to some config issue?
<mozmck> Hmm, probably not clear, this is the vanilla 3.18.9 kernel with the preempt-rt patch
<euhthe> Hi
<irssi_> Does ubuntu offer custom kernels?
<irssi_> Does ubuntu offer custom kernels?
#ubuntu-kernel 2015-03-20
<Dan> Need help installing/configuring kernel-source so driver modules will build for conexant usb modem. My thread is here (not spam) http://ubuntuforums.org/showthread.php?t=2270054
<Dan> If that is seen after i leave please reply to post, been trying to install these drivers for about 8 days now. Quite frustrated
<Dan> More extensive thread on other forum http://www.linuxquestions.org/questions/ubuntu-63/compiling-kernel-source-build-modules-in-ubuntu-14-04-a-4175536945/
<Dan> Replies and help are appreciated
<apw> Dan, the source for the kernel has changed, moving the version.h file somewhere else (into the uapi directory)
<apw> Dan, the driver is clearly not been updated to match in the recent past, and needs to be
<Dan> Where is the uapi directory?
<Dan> Thanks for reply
<Dan> So i just move version.h into uapi directory and it should build?
<Dan> Also yes, the drivers havent been maintained since i think 9.10
<apw> i doubt that very much, if the code is writeen for the kernel since before uapi existed the chances of it workign with the new kernel is very low at best
<apw> version.h is already in the uapi directory (under that build link) the driver expects it not to be
<apw> but the uapi split isn't exactly new, so you are in uncharted territory
<Dan> Could you reccomend me a distro that would support any of these? http://www.linuxant.com/drivers/dgc/downloads.php
<Dan> Only reason im on 14.04 is because help was refused if i was running an EOTL release
<Dan> I only need gnome-ppp so as long as it supports that but with a old enough kernel to install/build my drivers that's fine
<apw> Dan, i find it supprising they arn't supported out of the box these days, they are anchient
<Dan> I got version 1.01 out of the box lol and wouldnt even install
<Dan> 1.13.0 installs but i have the module build issue
<apw> i mean without any extra drivers, most of these things get core support over time
<apw> though that page tells you what distros support the drivers, the last ones it lists are so old one normally assumes
<apw> the driver has made it into mainline
<Dan> So my best bet it to try 9.10?
<apw> if the system doesn't work it out of the box, i'd say you are in a hole
<apw> as the vendor clearly does not support their own h/w any more
<Dan> I installed the generic dgcmodem-1.13.0.deb ill try the distro specific packages
<Dan> Thanks for your help, at least i dont have to figure out the kernel-source
<Dan> But just to verify, installing the kernel source would do nothing, yes?
<mozmck> I'm running the following to build some custom kernel packages:  fakeroot debian/rules binary-indep; fakeroot debian/rules binary-perarch; and then fakeroot debian/rules binary-<custom flavour>
<mozmck> Is this the right way to do this?  It is not building a linux-firmware package - should it?
<mozmck> oh, and linux-libc-dev is not being built either, but I don't know if it should be.
<infinity> mozmck: linux-firmware is built by the linux-firmware source package.
<mozmck> oh, I'm using skipabi=true skipmodule=true - is that still necessary?  I had to do that when I built a custom ubuntu kernel for 10.04
<infinity> mozmck: It's still necessary if you don't plan to track your ABI changes appropriately.
<infinity> apw: The mind boggles that someone would apparently waste a week trying to make a 10 year old piece of hardware work that he could have replaced for 15 bucks.
<mozmck> ok, thanks.
<lifeless> infinity: ... that was the case 10 years ago too :)
<infinity> lifeless: Yeah, true.
<infinity> lifeless: But I get the motivation to make new kit go.  And if you're a hacker, I get the challenge of making old kit go.  But as a volue proposition, if you've gotten a decade out of your 15 dollar softmodem, it's time to find a bin for it.
<infinity> s/volue/value/
 * infinity side-eyes his fingers.
<lifeless> Aye.
<lifeless> But its his precious.
<lifeless> Or maybe he has 10000 of them in retail stores all over the place.
<infinity> Heh.
<mozmck> if I want to build i386 packages on my amd64 machine, how would I do that?
<lifeless> easiest way is probably a i686 lxc container
<mozmck> I made a flavour for amd64 and i386, but only the amd64 flavour built
<lifeless> lxc-create -t ubuntu -n fred -- -a i686 
<infinity> Or just a chroot.
<lifeless> personally find it more fiddly to manage cross-arch stuff in chroots, but sure, whatever :)
<infinity> mozmck: Many ways to skin that proverbial cat, but the basic essence is that you want an i386 userspace.  So a chroot or lxc or a VM (in order from light to heavy).
<mozmck> ok, I've heard of pbuilder but not used it, I'll do some reading.
<infinity> lifeless: Well, your lxc-create call is creating an i386 chroot. :P
<mozmck> ok, thanks.
<infinity> lifeless: How you enter it defines if it's a chroot or a container.
<infinity> mozmck: pbuilder is the devil's tool.  sbuild is the way and the light.
<mozmck> can I easily use 8 cores in a chroot?
<mozmck> heh, ok!
<infinity> mozmck: A chroot changes nothing about your system.  It's just a directory with another root filesystem in it.
<lifeless> infinity: yes indeed :)
<mozmck> ah, ok.
<lifeless> you should be able to use multi-arch in principle too
<infinity> You can, yes.  And for a kernel, that's not a terrible option, since the build-deps are light.
<mozmck> multi-arch?
<infinity> mozmck: The man makes a fair point.  It could be as simple as taking your dpkg-buildpackage command and adding "-ai386" to the command line. :P
<lifeless> can one do apt-get build-dep linux-kernel/i386? 
<lifeless> I forgets
<mozmck> hmm, ok.  I'm using debian/rules binary-...  
<infinity> lifeless: I think apt also uses the -aarch syntax for that, but I don't recall.
<mozmck> I presume that calls dpkg-buildpackage somewhere?
<infinity> mozmck: Ahh, no.  Other way around, dpkg-buildpackage calls debian/rules.
<infinity> mozmck: But if you're happier doing the manual fiddling instead of building the whole shebang, just build a quick chroot (or, as lifeless says, an lxc container), and build in there.
<infinity> lxc might be simpler, just cause it automates the fiddly bind mount bits and whatnot.
<mozmck> oh, well I haven't used that then I guess.  fakeroot debian/rules binary-<indep|perarch|flavour> is what I've been using.
<mozmck> maybe I should be using dpkg-buildpackage.  I only want one flavour though - my custom (PREEMPT-RT) one.
<gshmu> I want test the latest upstream kernel, so I install the last kernel, but I can't longin in new kernel at tty7. anyone can tell me how to build the linux-image-extra-000.deb package?
<mozmck> I would like to know that as well!
<gshmu> mozmck: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1432459
<ubot5> Ubuntu bug 1432459 in linux (Ubuntu) "USB 3.0 automount after "Power off driver/safely remove"" [Low,Incomplete]
<gshmu> Can you help me to build the linux-image-extra-4.000.deb ?   I'm just build this package: linux-firmware-image-4.0.0-rc1-gshmu_4.0.0-rc1-gshmu-1_amd64.deb linux-headers-4.0.0-rc1-gshmu_4.0.0 rc1-gshmu-1_amd64.deb linux-image-4.0.0-rc1-gshmu_4.0.0-rc1-gshmu-1_amd64.deb linux-image-4.0.0-rc1-gshmu-dbg_4.0.0-rc1-gshmu-1_amd64.deb linux-libc-dev_4.0.0-rc1-gshmu-1_amd64.deb
<zequence> infinity: Sorry, haven't been in for a few days. Both kernels tested now.
<apw> gshmu, there is no linux-image-extra for mainline builds, they build with the split disabled so all modules should be in the linux-image package
<stub> Anyone have some kernel boot parameters that might get some useful debug information for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1434136 ?
<ubot5> Ubuntu bug 1434136 in linux (Ubuntu) "HP Pavilion 13-b208tu fails to boot with F.26 bios, PSOD" [Undecided,Confirmed]
<gshmu> apw: How to build it by my self?
<apw> gshmu, you don't need it because all of its content are instead in linux-image
<gshmu> apw: I can't login in tty7
<apw> we do not split the package for mainline builds because it adds no value and can fail because of upstream changed
<apw> gshmu, unsure, sounds likely that you are seeing a graphics hang from your bug discription, and those sort of things are pretty common in a -rc kernel, particularly as it happens after you are able to type username and password at lightdm
<apw> gshmu, i would say as you are looking to see if a usb issue is resolved, that you try a v3.19.x kernel from there, as they tend to be more stable
<gshmu> apw: thanks you 
<mozmck> apw: how does the build system know that a mainline kernel is being used so it does not split out the *extra package?
<apw> mozmck, the mainline builder specified it wants no split
<mozmck> apw: ok, so I copied the debian and debian.master from vivid at the next commit after the 3.18.7 tag into a mainline 3.18.9 kernel.  I do not get the extra package, or the linux-libc-dev package.  should I be getting the latter?  I'm running debian/rules with binary-indep, binary-perarch, and binary-<myflavor> to build packages.
<apw> mozmck, not sure, the config for the flavour contains the split info, so if you called it something other than generic likely not
<apw> you can also tell from the size of the linux-image, if it is huge then it is not split
<mozmck> apw: hmm, ok.  I called preemptrt, and the linux-image package is 54 MB, so I guess it is not split
<mozmck> thanks.
<apw> mozmck, yes the inclusion list is generic specific so you should avoid it
<BeagleBug_97> Is it possible to install rt-preempt patch on BeagleBoard xM kernel running Ubuntu 14.04?
<lamont> who knows precise iptables better than anyone should?
 * lamont has very specific quesitons about conntracking in the 3.13.0 kernel (oops, s/precise/trusty/) and would prefer not to go read that much source
<apw> lamont, i'd guess that without reading only jay might know any detailed questions, though i'd say ask anyhow
<lamont> lets say I was being crazy and trying to move firewalling to another machine by doing this:  (1) insert the new machine in between the old machine and the outside link from same.  (2) turn on conntracking, but allow all traffic through the new-firewall-to-be, (3) at some point trade rules and make the new machine the active and statefully firewalling machine, and the old one becomes "let it all
<lamont> through" (4) remove the old machine
<lamont> would that even work?
<lamont> what tcp sessions would not be stored in the new machine's conntrack? (does that only get written when new connections form, or does it care?)
 * lamont doesn't want to rebuild his test lab, either
<apw> so i would have expected that to have worked as you hope, that as long at the new machine is there long enough that it would pick up the connections, and indeed if you put it
<apw> inside, so it only sees the valid ocnnections i _think_ it will intuite the ones which are already existing
<apw> so i think i am saying it should be between the old and inside, else it will have established things where it ought to reject maybe
<lamont> ah, good point
<lamont> yeah, inside then
<lamont> I may just see if I can test this out for sure
<apw> cirtinaly it has estalished detection for existing connections when it starts watching too
<lamont> next question: HTF do I see the conntrack table in a 3.13 kernel?
<lamont> the pre-trusty way went away (conntrack in /proc/sys/(
<apw> crontrack-tools perhaps
<apw> it might be conntrack -L
<apw> lamont, conntrack -L seems to do what i think you want
<lamont> packagte is conntrack
<lamont> cool
<apw> yeha i've been doing a lot of cron stuff today, so i keep misstyping
<lamont> and the 8-tuple is (src/dst IP/port side A, src/dst IP/port side B), yes?
<lamont> actually, established/related requires the full SYN/SYN+ACK/ACK handshake to complete for TCP stuff , yes?
<apw> right the two flow directions
<apw> i believe there is some recovery for lost entries that could trigger when someone is clearly communicating
<apw> but i'd not like to claim to how
<lamont> heh
<lamont> I'm thnking of the "new guy on the outside" case (since the firewall filters both directions) - if all it saw was the SYN (and old guy then dropped the packet), I would like to think that ESTABLISHED wouldn't make it when that finally got turned on...
<lamont> obviously, the sequence would be: turn on firewalling on the new guy, then turn it off on the old guy
<apw> lamont, that does sound believeable, so yes likely it works either way
#ubuntu-kernel 2015-03-21
<BeagleBug_97> Hi, is there any guide on installing a real-time patch on Ubuntu 14.04 kernel running on BeagleBoard xM?
<BeagleBug_97> I found this one : https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
<BeagleBug_97> But how do I leverage the rt features for an ARM processor?
<yossarianuk> hi - not sure who i spoke to in here weeks ago
<yossarianuk> I was asking about the OSS snd modules in the kernel (the fact that Ubuntu removes them completely) and that I am unable to play some old games unless i recompile the kernel
<yossarianuk> I created a bug report - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1434842
<ubot5> Ubuntu bug 1434842 in linux (Ubuntu) "Due to lack of OSS kernel modules, have to recompile the kernel to enable sound in old games - aoss/padsp do not work" [Undecided,New]
<yossarianuk> cheers
<infinity> yossarianuk: It's a situation where no one can really win, unfortunately.
<infinity> yossarianuk: IIRC, compiling OSS (even as modules) leaves some scaffolding in the kernel that makes it misbehave slightly on modern systems.
<yossarianuk> infinity: but surely if the modules are disabled by default it won't hurt ?  other distros (like most of them) have them in the kernel but disabled by default
<infinity> yossarianuk: So, the userspace shims entirely fail to work in some cases, but maybe these cases involved having one or two things compiled in.  We can certainly look at it again.
<infinity> apw: Can we investigate if it's possible to build OSS *entirely* as modules with no taint on vmlinuz and then just blacklist them all?
<yossarianuk> cool - its one issue I have with ubuntu... Debian (wheezy) opensuse , Fedora and Arch do have access to the module...
<infinity> yossarianuk: No promises or anything.  But looking through the last few times it was disabled, accidentally enabled, and disabled again, there were always a few =y bits.  If it's possible for the whole thing to be =m, *and* that influences vmlinux in no way, then I don't see the harm.
<infinity> apw: ^
<yossarianuk> infinity: thank you very much !
<yossarianuk> infinity: any effort is welcomed....
<apw> infinity, indeed
<apw> infinity, i guess with our new blacklist generator we could do that to them
<yossarianuk> well thanks for whoever looks into this - i'm going to test kubuntu 15.04 - will file bug reports if i find any
#ubuntu-kernel 2015-03-22
<jhenke> hi, are there any known issues with detecteing already plugged USB devices on boot?
<jhenke> I filed a bug about it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1435028
<ubot5> Ubuntu bug 1435028 in linux (Ubuntu) "Kernel does not detect already connected USB devices on boot" [Undecided,New]
<Nash_> hi. i need to install a real-time kernel patch(preempt-rt?) on BeagleBoard running Ubuntu Trusty 14.04. Current kernel :v3.19.2-armv7-x3. Any pointers is greatly appreciated.
#ubuntu-kernel 2016-03-21
<tjaalton> huh, not even 14.04.1 server image works
<tjaalton> tried on another machine too, same thing
<tjaalton> no kbd
<tjaalton> that one has ps2 ports too, and at least the installer isn't hung
<tjaalton> dmesg shows that the usb device is attached, but doesn't work
<tjaalton> smb: I see you've worked on a similar issue in the past, looks like usb keyboards can't be used with server installer and I've verified it with trusty, wily & xenial, on two different machines (legacy/hp microserver, uefi/intel sdp)
<tjaalton> desktop installer works fine
<tjaalton> guess noone tests real hw anymore :P
<smb> tjaalton, well also if you do preseed-ed net installs its no issue either. Do you at least have some more details about what combination of usb host / device this is?
<smb> Cause the initial problem should be fixed (which was a missing hid driver for usb2)
<tjaalton> smb: gen8 microserver, certified with precise :)
<tjaalton> though the intel sdp is skylake, so the usb controller might not be supported on trusty, although the installer does boot from it..
<smb> tjaalton, That is a lot of information that is not helpful. :-P
<tjaalton> http://www.ubuntu.com/certification/hardware/201306-13791/
<tjaalton> better? :)
<tjaalton> debian jessie b2 installs fine fwiw
<smb> tjaalton, Maybe. Just generally this seems to be an issue that a certain part of the usb drivers is not compiled into the kernel. But then there can be any combination of usb-1-2-3 on either side
<tjaalton> ok, what do you want? I can get info from the intel machine more easily as it has a ps2 port that works
<tjaalton> but the machine needs to be booted with it attached to work, it seems
<tjaalton> ps2 kbd i mean
<smb> tjaalton, thats at least something... You said desktop install is ok. So if you  can open a new bug about this. I think ubuntu-bug linux will gather lsusb and lsmod. So any info that helps to figure out what driver chain is running when it works
<smb> tjaalton, Yeah, I would not think ps2 is made for hotplug... or was made
<tjaalton> I've opened bug 1559692
<ubot5> bug 1559692 in linux (Ubuntu) "server image has no keyboard, desktop image works" [Undecided,Incomplete] https://launchpad.net/bugs/1559692
<tjaalton> but it has no logs yet
<tjaalton> so if I boot working xenial on it and attach logs from it, that would be enough?
<smb> tjaalton, if xenial is the target that you want to get fixed. Because upstream sometimes renames modules. In the end it could be required to open multiple reports (at least per hw). But I would probably start with one thing and then decide after we figured that one
<tjaalton> i just want to get the machine installed so I can put my data on it :)
<tjaalton> but yeah xenial is the main target
<smb> tjaalton, So I added the question to the bug report as well. Basically the desktop installer has access to all modules while the server (d-i) installer needs proper declaration of what is an input module. 
<tjaalton> i'm on the server installer with working network and ssh client, dmesg/lspci/lsusb collected
<tjaalton> is that helpful?
<smb> tjaalton, not that much as in that case the module likely is missing as otherwise you would have a keyboard
<tjaalton> ok
<smb> tjaalton, So not sure why but in the bug report you say 14.04 desktop is working. Is a 16.04 desktop working, too or not working as the server installer?
<tjaalton> both desktop images work
<smb> ah ok, so that is at least a better comparison than 16.04 server against 14.04 desktop. At least it can rule out it not being supported by the kernel in general as both 16.04 server and desktop use the same kernel then.
<tjaalton> did a quick sanity test with 12.04.2 where it indeed works
<tjaalton> smb: one thing I noticed is that input-modules doesn't have hid-lenovo
<tjaalton> i have a usb thinkpad kbd which happens to be the only usb keyboard I have. precise installer had only hid-generic loaded though
<tjaalton> and usbhid of course
<smb> tjaalton, Hm. Might be that at some point there was special support ... I don't know from the top of my head whether that would automatically mean the generic driver will ignore it
<apw> when we add a special driver we disable the generic one explicitly iirc
<smb> Ah ok, that then might explain it
<smb> apw, and morning
<tjaalton> so, make sure all the special ones get added in input-modules?
<apw> smb, moin
<smb> That would be a result... and I can imagine that is easily forgotten
<apw> tjaalton, that might well be a sane position to take, though it is early and i have not had my second cup of tea
<tjaalton> :)
<smb> apw, Maybe hwe should remind is if they require us to add new fancy keyboard drivers... :-P
<apw> heh ... i am liking that
<apw> tjaalton, does your keyboard have a trackpoint ?
<tjaalton> apw: yep
<tjaalton> (love it)
<apw> ok i suspect that is the reason the driver was added then
<smb> The problem is that not every hid driver is a keyboard... I think there is something like hid-joystick as well. Fancy but useless for a server install
<tjaalton> right, special keyboards then :)
<smb> tjaalton, So I guess you used the same keyboard in both (machine) cases. So likely we go and add hid-lenovo as a first step which you can then verify when things hit the image
<tjaalton> smb: yeah
<apw> tjaalton, now how to test that that is sufficient.  are you able to get that driver on and loaded to confirm that is sufficient in the d-i installer
<smb> hm... might be possible to do that on the one that has ps2
<tjaalton> by rebuilding the installer I guess
<smb> tjaalton, could you not attach ps2 on that one server (plus usb), then load the hid module using the ps2 keyboard and check whether that makes the usb one working?
<tjaalton> not attach ps2? means I have no kbd
<smb> apw, though... do modules that are not in any d-i udeb be available in the d-i installer at all
<tjaalton> don't think so
<smb> tjaalton, no, I mean attach both
<tjaalton> ah
<apw> no, but they are available on any normal install for putting on a usb stick etc
<apw> so not impossible
<apw> tjaalton, i wonder if you could test this in VM, by passing that device to it
<tjaalton> just needs copying to the right place and modprobe?
<apw> or just copying in, and remove readd keyboard
<apw> smb, can we do usb passthru to vms, i feel we can
<smb> apw, in theory
<tjaalton> problem is that my main desktop has the same kbd :)
<tjaalton> same model
<smb> It would be possible to attach two... thought highly confusing as well
<smb> tjaalton,  but yeah I think have ps2+usb attached on server boot, do basic net setup with ps2, copy hid-lenovo (same kernel version) from some other place and insmod it. Then try usb (maybe with a unlug + replug)
<tjaalton> smb: yep, that did the trick
<tjaalton> didn't need to replug even
<smb> tjaalton, ok cool. Yeah that was more just in case. :) So can you please add us that info to the bug report? We are forgetful about stuff only on irc
<tjaalton> sure :)
<tjaalton> smb: updated, marked as triaged
<smb> tjaalton, ack thanks
<caribou> apw: xnox: any reason why the linux-crashdump metapackage is gone AWOL on s390x ?
<apw> caribou, that would be my fault i am sure
<apw> caribou, can you file me a bug pls, and i will wack it
<caribou> apw: sure
<apw> i would imagine it is less awol and more "never existed", a lot of those packages have hand manage lists on them
<caribou> apw: lp: #1560015
<ubot5> Launchpad bug 1560015 in linux (Ubuntu) "linux-crashdump meta-package is missing on s390x architecture" [Undecided,New] https://launchpad.net/bugs/1560015
<caribou> apw: no, I used it two weeks ago afaik
<apw> caribou, ... really ?
<caribou> apw: think so but I'd have to check xnox's instance
<caribou> apw: let me check
<apw> caribou, not as far as i can see ...
<apw> not since vivid !
<caribou> apw: true;
<apw> caribou, is there any architecture we build for which does not support crashdump ?
<caribou> apw: arm64
<caribou> apw: kexec support is still under dev there
<apw> caribou, ok, so the list should be "all arches - arm64" then after i am done fixing it
<caribou> apw: yep
<apw> caribou, which it is not if i just add s390x ... _sigh_
<apw> caribou, fix-committed ...
<caribou> apw: thanks!
<apw> caribou, likely the next upload is when beta freeze lift
 * ogasawara waves to ben_r 
 * ben_r waves back :)
<ben_r> Good morning :)
<apw> ben_r, yo ... you should have said hello
<ben_r> That also, however, I am sure it is morning there ;)
<apw> ben_r, i am sure it is not :)
<ben_r> apw: fair enough :)
<lamont> jsalisbury: updated that bug for you.  what I missed in the update is that if 4.4.0-9+fix is good, then we have a new bug and should vacate 1543683 :)
<jsalisbury> lamont, I'll build you the kernel with the new fix and without 237ed86c reverted.  Maybe it is an interaction between the two, that would make it easier to fix.
<lamont> verily
<lamont> jsalisbury: in other news, if you have the wherewithall to bring me up to speed on taking $RANDOMCOMMIT and turning that kernel tree into a built kernel, I'd be able to do all the bisecting myself
<lamont> when I bisect to somewhere with no debian/ directory, I get lost...
<jsalisbury> lamont, I use the 'mainline-build-one' script from kteam-tools: git://kernel.ubuntu.com/ubuntu/kteam-tools.git
<lamont> jsalisbury: PERFECT!
<jsalisbury> lamont, it does the checkout of debian and debian.master
<lamont> it was one of those "I KNOW THERE'S A SCRIPT somewhere!!"
<lamont> kind of things
<jsalisbury> lamont, its in : ~kteam-tools/mainline-build
<lamont> ta.  I'll let you build this next kernel, and then I'll update with answers and run with it
 * lamont will be distracted by $REALJOB for a bit this morning
<jsalisbury> lamont, :-)
<lamont> jsalisbury: oh hey, and what is this magic commit hash that we're calling "the fix", just for my clarity
<lamont> as in, what do I need to cherrypick onto the bisect branch each test?
<jsalisbury> lamont, gotcha, one second
 * lamont will catch scrollback in a bit
<jsalisbury> lamont, this is the SHA1 in mainline:
<jsalisbury> lamont, this is the SHA1 in mainline:
<jsalisbury> 8d409cb drm/i915: Fix hpd live status bits for g4x
<jsalisbury> lamont, this is the SHA1 in Xenial:
<jsalisbury> 7a5c500 drm/i915: Fix hpd live status bits for g4x
<lamont> ta
<lamont> jsalisbury: we have a WINNER.... bug updated.
<lamont> and since it's not bisecting, I'm going to let you provide me with a kernel that does what you think we need next.
<lamont> s/bisecting/a matter for bisecting/
<jsalisbury> lamont, ack, thanks for testing.  I'll build you another kernel shortly.
<lamont> I'm about to bail, will test in the morning.
#ubuntu-kernel 2016-03-22
<alkisg> apw, good morning, a new kernel was made available for xenial but it still had CONFIG_IP_PNP=y, when will the change land, in the next update? Is a new kernel without it available anywhere for me to test with?
<apw> alkisg, yes, a kernel takes days to make it through testing, that was the previous one
<alkisg> apw, can I participate in testing?
<apw> we are in hold because of the beta-freeze kernel wise, so the next one will be more like eow
<alkisg> Thank you apw :)
<apw> i could make a test kernel wheni wake up
<alkisg> No no I don't want to waste more of your time with that
<alkisg> I'll just wait for when it's available and report then
<ricotz> alkisg, hi, what is the current state of ltsp in xenial?
<alkisg> Hi ricotz, it's in a working state, but I've pushed some more upstream fixes and I'll do a microrelease in debian with e.g. 10 days and syncpackage it to xenial
<alkisg> *within
<ricotz> alkisg, great! :) I assume the problems due kernel layout changes are resolved for clients?
<alkisg> ricotz, with "layout changes" you mean the CONFIG_IP_PNP=y change? I didn't get my hands on any newer ubuntu kernels without that, so I wasn't able to test
<ricotz> do you have plans for trusty backports to support lts-kernels >= 3.19?
<ricotz> alkisg, ah, I meant things like overlayfs changes
<alkisg> I don't have enough ubuntu commit rights to do a backport, and it's rather painful to seperate all the bug fixes from the rest of the upstream commits,
<alkisg> so I'm just pushing newer LTSP versions for 12.04, 14.04 etc to the Greek schools PPA
<ricotz> alkisg, I see, I will keep an eye on that PPA!
<alkisg> It's very well tested, thousands of schools are using it
<ricotz> alkisg, thanks!
<apw> isn't ltsp the thing that makes up edubuntu, well i guess we should call the ex-edubuntu
<apw> alkisg, ^
<alkisg> LTSP was a big part of edubuntu, but the soul of edubuntu was to be a community of people that cared about using ubuntu in education, reporting issues with educational packages or mainting them etc
<alkisg> LTSP is still being used quite a lot, e.g. map of half of the Greek schools using Ubuntu+LTSP: http://www.ltsp.org/stories/widget-map/?location=Greece
<alkisg> The other big part of edubuntu was that it was using the gnome-flashback session, I've just sent a mail to the gnome-flashback mailing list to ask if anyone's interested in co-maintaining it or releasing a gnome-flashback-based flavor of ubuntu
<alkisg> (gnome-flashback performs much better in old hardware or ltsp thin clients - while ltsp fat clients work fine with unity as well)
<apw> alkisg, http://people.canonical.com/~apw/lp1259861-xenial/
<alkisg> :) Thanks a lot apw!
<alkisg> apw, that kernel doesn't have the 10 sec timeout issue, all is well, client booted in 12 secs :)
<apw> alkisg, ta, please add that info to the bug, the fix is committed already
<alkisg> OK
<alkisg> Done
<pesari> I guess this is asked frequently but since I couldn't find an answer:  Will Xenial have kpatch live patching?
<cyphermox> ogasawara: who can I talk to about validating modules for Secure Boot in the kernel?
<ogasawara> cyphermox: I think apw would be your man
<cyphermox> ok, thanks!
<apw> cyphermox, hi
<cyphermox> hey!
<cyphermox> so I'm thinking we're at the point where we have the necessary tooling in userland to support not loading unsigned modules in the kernel, unless things are explicitly "disabling" secureboot, either because it's disabled outright in the BIOS, or because shim has its validation disabled
<cyphermox> actually, wait a second, I think we're still missing something *sigh*
 * apw listens
<cyphermox> >.<
<cyphermox> so, how does the kernel currently check signing of the modules?
<rtg> cyphermox, there is no enforcement, it just complains. there is a config that we need to enable to do enforcement.
<cyphermox> right, but do you know where the verification gets done?
<rtg> cyphermox, in the kernel at insmod time
<cyphermox> I want to verify that it would do the right thing if validation is disabled in shim
<rtg> cyphermox, I don't think it will without a patch. 
<cyphermox> right
<cyphermox> where's that code?
<rtg> kernel/module.c and kernel/module-signing.c I think
<apw> i think we need to ask shim and i don't think we have a way to do that right now
<apw> i beleive we have the shim callbacks because they are in the boot-sevices space right ?
<apw> at least until we junk those
<rtg> apw, isn't that what we talked about with slangasek awhile back ? A MOKMAN variable that the kernel queries to determine if we're really in secure boot mode ?
<apw> rtg, indeed, its possible it has hit mainline when we weren't looking of course
<apw> i can't say i've been keeping track
<rtg> nor have I
<rtg> cyphermox might have some idea
<apw> cyphermox, are you hoping to do this for 16.04 
<apw> ?
<rtg> apw, I think the goal is to turn on module signing enforcement for 16.04
<rtg> they are cutting it kinda close
<apw> rtg, fine?  we are i beta freeze, fine is some weeks back
<apw> we have like 4 weeks, like 3 uploads
<rtg> I was somewhat tongue in cheek
<cyphermox> apw: I was, yes
<cyphermox> it would be MokSBState I think
<cyphermox> I'll look in a but
<cyphermox> *bit
<rtg> cyphermox, is that already in the shim ?
<cyphermox> rtg: yeah, that's already in shim
<rtg> cyphermox, ok, so _all_ you need is a config patch and a patch to read that variable ?
<rtg> which controls implementation of signed module enforcement
<cyphermox> I guess?
<cyphermox> I would have to look at the code, and I will in a minute
<rtg> cyphermox, (and a bunch of testing)
<cristian_c> jsalisbury: hello
 * apw butts out and leaves rtg to it
<slangasek> cyphermox: is MokSBState the boot services variable or the one mokmanager uses to control it from userspace?
<cyphermox> it's the boot services variable
<slangasek> ok
<slangasek> so yes, that's the one the kernel should honor
<cyphermox> mokutil sets MokSB, which MokManager reads and sets MokSBState , etc.
<slangasek> assuming the kernel is able to access it
<cyphermox> right
<gpiccoli> hello, sorry to bother you! I have a question regarding memory management in kernel. More specifically, I wanna know how the value min_free_kbytes is set by default
<gpiccoli> Seems to me it's related to the total amount of RAM, like a percentage
<gpiccoli> Is it platform specific?
<gpiccoli> Thanks in advance for attention
<gpiccoli> I might have found the function that is generating this value: set_recommended_min_free_kbytes
<gpiccoli> the name says it all hehehe
<apw> gpiccoli, i beleive it is a percentage but on a sliding scale with larger ram and an upper bound througn into the mix
<gpiccoli> yes apw, you're right
<gpiccoli> in fact, another function provides the default value: int __meminit init_per_zone_wmark_min
<gpiccoli> the algorithm is pretty well explained there
<cyphermox> rtg: ogasawara: you know that the module verification stuff needs to happen on every release right?  so multiple SRUs
<cyphermox> slangasek: ^
<rtg> cyphermox, do you men for releases prior to xenial ?
<rtg> mean*
<cyphermox> yes
<apw> cyphermox, on every release ?  why so ?
<cyphermox> I mean for *all* releases
<slangasek> apw: because this is a flag day for our SecureBoot policy and we can't be signing new kernels for old releases with the new signing key
<cyphermox> because we'll eventually change the signing key and the will affect all releases and we need only the new policy (signed everything) to apply
<slangasek> basically, until we are able to update the module verification policy on all supported releases, there is no point in us rotating signing keys for this
<apw> do we have the infrastructure for this back in P ?
<slangasek> which means anyone can always downgrade security of the signature checking by booting an old bootloader, or an old kernel, or
<apw> slangasek, i assume the rule is you have to turn off secure boot to use dkms in the first stab
<slangasek> correct
<slangasek> "Turn off" via Mok
<apw> slangasek, and presumably we have to confirm like kexec is disabled at least when SB is enabled 
<slangasek> apw: I seem to recall we discussed that was a requirement, yes
<cyphermox> slangasek: I pointed apw at some patches
<genkgo> jsalisbury: see you were posting in the vss backup thread
<genkgo> thought to join here, maybe you have more questions
<genkgo> also just replied with answers to question you had
<jsalisbury> genkgo, I'll review your reply now.  I can easily reproduce the bug and it's been going on for way too long, so it has to be figured out.
<genkgo> jsalisbury: hehe, tell me about it
<jsalisbury> genkgo, one way to work around the bug is to shut down the VM and then back it up, but that isn't easily done in the real world.
<genkgo> jsalisbury: yeah, i read something about offline backups, but cannot do, unfortunately
<genkgo> jsalisbury: what i don't get is the microsoft attitude
<genkgo> i mean, i get that linux is not their top priority
<jsalisbury> genkgo, yeah, I have no control over that, sorry.  I'll dig in the best I can, but some bits I don't have.
<jsalisbury> genkgo, That's why I asked about all the different versions of the different pieces 
<genkgo> jsalisbury: if there is anything i can do, please let me know
<jsalisbury> genkgo, I sure will.  I'm going to focus on this specific bug for a bit and try to figure it out.  
<genkgo> jsalisbury: but regarding the different versions, trash1-z did mention something Redhat was hit too
<genkgo> https://social.technet.microsoft.com/Forums/office/en-US/cfe15e32-bfbc-47e0-8d2b-382a1293b9aa/vss-issues-with-centos-66-x64?forum=linuxintegrationservices
<genkgo> but maybe that is different
<genkgo> because there is nothing on read-only in there
<genkgo> that is more related to sudden restarts
<jsalisbury> genkgo, What is puzzling to me is CentOS based on the 3.10 kernel does not hit the bug, but 12.04, based on the 3.2 kernel hits it.
<genkgo> jsalisbury: yeah, but it could also be our i/o
<genkgo> however, the original poster on the microsoft forums, also noticed that cent os was not crashing
<jsalisbury> genkgo, right.  It does take heavy I/O while a backup is in progress to hit it.
<jsalisbury> genkgo, I think I'm going to get the CentOS release you have and try to reproduce the bug.  If I cannot, I know where to dig.
<genkgo> jsalisbury: right, but the starter of this thread https://social.technet.microsoft.com/Forums/windowsserver/en-US/8807f61c-565e-45bc-abc4-af09abf59de2/ubuntu-14042-lts-generation-2-scsi-errors-on-vss-based-backups and he is also saying "We also have some CentOS based guests running without issues from what we've seen."
<genkgo> jsalisbury: alright, hopefully we can get some results
<genkgo> jsalisbury: regarding our difference in i/o, our ubuntu machines are webservers and our cent os machine is exim + dovecot
<jsalisbury> genkgo, I imagine web servers are mostly read only.  
<jsalisbury> genkgo, The script I wrote to reproduce the bug is a mix of I/O, but very heavy.
 * jsalisbury is hoping I don't destroy my disk :-)
<genkgo> jsalisbury: yes, that is what i am thinking, but there are some cronjobs and workers running in there, so there are jobs to do. but honouslty, that is way lower than your script
<genkgo> hehe
<jsalisbury> genkgo, Yeah, the script puts the disk at 100% of it's capability.  I pray I don't smell smoke.  I'm going to go head down on this one to wrap it up.
<genkgo> alright, good luck!
<jsalisbury> genkgo, Is it CentOS 7 you are running or another version?
<genkgo> jsalisbury: CentOS 7
<jsalisbury> genkgo, great, thanks
<cristian_c> jsalisbury: hello, again
<jsalisbury> cristian_c, hey, I submitted a patch upstream, but have not gotten a response, I'll do a resend if I don't hear anything in a day
<cristian_c> oh, thanks
<cristian_c> :)
<cristian_c> jsalisbury: a question: usually, what is the average time upstream guys reply to a submission?
<jsalisbury> cristian_c, np.  I'll let you know as soon as I get feedback.  I have no reason to think the patch wouldn't be accepted.  It's just slow sometimes.  I'll SRU it to Ubuntu as soon as it's accepted into mainline.
<cristian_c> (days/week/months)
<cristian_c> jsalisbury: ok
<jsalisbury> cristian_c, usually days, but if I don't hear back in a week I resend the request
<cristian_c> ok, thanks
<jsalisbury> anytime
#ubuntu-kernel 2016-03-23
<fg__> Not sure whether to ask here or in -devel, but where can I find the repo for the zfs-linux packaging branch? The source package just references the upstream zfs/zol tag for the source code, but I can't find a link for the xenial packaging branch..
<fg__> ( launchpad only shows one for wily[-proposed].. )
<apw> cking, ^
<cking> fg__, you require zfsutils-linux, probably easiest if just apt-get source for that
<fg__> cking: I know how to ge the zfs source package - I'd like to know if there is a (public) repository where the packaging stuff is developed
<fg__> like this for the kernel: git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
<cking> fg__, not quite yet, I've got a repo, but it's out of date and needs some love for the packaging side
<fg__> the zfs source package contains a gbp.conf which refers to a xenial branch, so I assume there is a git repository somewhere (but it might be ubuntu internal only?)
<fg__> ah okay
<fg__> will it be on launchpad or in the pkg-zfs repo from zol?
<cking> fg__, i'm waiting for 0.6.5.6 to land (hopefully in the next 24+ hours), then I'll get it all sorted out, cf: git://kernel.ubuntu.com/cking/pkg-zfs.git
<cking> that's the debian packaging (out of date) and that's used on the pristine zfs tarballs when they get released
<fg__> cool, thanks :)
<cking> note, that git repo may change, it still is work-in-progress
<fg__> I'll check it out, currently I'm using the master/debian/jessie one from zfsonlinux/pkg-zfs, but it's woefully out of date so I had to cherry-pick a lot of the more recent upstream changes
<apw> cking, we prolly should push that to ~ubuntu-kernel or something ... 
<fg__> we are evaluating switching to ubuntu's zfs packaging since we are also preparing to switch to xenial's 4.4 kernel
<cking> apw, yep, once I've got it sorted for 0.6.5.6
<apw> cking, i'll work with you to get that mirrored as well
<cking> fg__, if you look at the xenial kernel source, you will find debian/scripts/misc/update-zfs.sh which is used to sync the src
<fg__> cking: yeah, I already saw that.. but that is just for syncing the module sources from the dkms binary package, not for building/packaging the zfs user space stuff.
<fg__> seems a bit cumbersome btw, that means you have to build the zfs packages and publish them to the archive before syncing the module source code and rebuilding the kernel?
<cking> fg__, that script sync's the zfs and spl, so yes, no user space stuff
<fg__> but I think I am set for now, thanks for your help
<apw> fg__, we we can sync it from any build, so in principle we cna build it in a PPA
<fg__> when the repo URL is final, will it be included in the .dsc for zfs-linux? then apt-get source would also spit out a warning with the correct repo information
<cking> and that's what I do for test builds so I can ensure it all works
<fg__> ah okay, missed that. makes sense :)
<fg__> I know it's a bit early to ping, but I reported https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1560869 earlier - would you be interested in backporting the async zvol minor operations patch from upstream? I have a backport/cherry-pick for the three relevant patches on top of 0.6.5.4 that seems to work fine afaict
<ubot5> Launchpad bug 1560869 in linux (Ubuntu) "Concurrent zfs create and rename operations can lock a zpool completely" [Undecided,Incomplete]
<fg__> the triggering setup is a bit artificial, but if you create and/or rename zvols in an automated fashion you're bound to run into it sooner or later
<genkgo> jsalisbury: any success with backup on centos 7 with hyper v?
<jsalisbury> genko, I haven't gotten around to test yet, but I plan on it today.  
<genkgo> jsalisbury: alright, was wondering, maybe there was something i could do to help
<jsalisbury> genkgo, nothing yet, but I should know more soon
<genkgo> aight, i'll join this channel more frequently to see if there is something i can do
<genkgo> jsalisbury: how is the backup doing?
<jsalisbury> genkgo, I have the reproduce script running now against CentOS.  It's been running for a couple of hours now without hitting the bug.  It sometimes takes up to 9 hours to trigger the bug, so it may take a little while.
<jsalisbury> genkgo, I'm going to let it run overnight
<genkgo> jsalisbury: thanks, i am really wondering if centos will be hitting the issue too. I hope not, because then we must be able to solve things!
<lluki> hi
<lluki> is there any chance that this bugfix (fix for some recent thinkpad touchpad issues) will be applied on the 16.04 kernel? https://bugzilla.kernel.org/show_bug.cgi?id=114321
<ubot5> bugzilla.kernel.org bug 114321 in Input Devices "Lenovo T460s reports incorrect release events" [High,New]
<lluki> nevermind, i created a bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1561198
<ubot5> Launchpad bug 1561198 in linux (Ubuntu) "trackpad keys not working properly on Lenovo Thinkpad T460s" [Undecided,New]
<xnox> caribou, re:coredump package, yeah file direct with kernel team / apw to sort out and publish.
<apw> caribou: say what now?
#ubuntu-kernel 2016-03-24
<genkgo> jsalisbury: by any chance had a crashing centos 7? or is still up and running? :)
<caribou> xnox: apw: not sure what you're talking about
<apw> caribou, i was saying the same, that i have no idea what anyone is talking about here :)
<caribou> apw: maybe xnox was talking about the linux-crashdump meta-package; dunno
<apw> maybe, didn't we fix that already ?
<apw> at least if he means s390x ?
<caribou> apw: yes, but after the freeze so it is queued
<apw> caribou, ahh ok, then its in hand and will be in the upload tommorrow i assume
<tseliot> apw: hey, I'm a little confused, as I can't find any of the drm drivers in the initramfs of my kernel on trusty. Any ideas? (I did lsinitramfs /boot/initrd.img-3.13.0-77-generic | grep drm)
<jsalisbury> genkgo, The CentOS VM hasn't crashed yet.  I'm going to let it run for just a few more hours.  MS recommended different versions of LIS, so my next steps are to try those different versions and also compare the 3.10 bits to newer kernels that hit the bug.
<genkgo> jsalisbury: alright, wonderful, at least it is good to know that the centos machine probably does not have the bug, so we have a starting point
<jsalisbury> genkgo, indeed.  I've always been able to reproduce the bug within 9 hours and I'm now at about 15 hours
<caribou> smb: anything special to do to get 3270 access from Ubuntu ? I'm trying with x3270 but the telnet connection doesn't establish
<smb> caribou, not really
<apw> tseliot, we don't normally put them in the initrd unless you need splash before root
<apw> which you only need to encrypted root
<apw> we only wait for the root device to appear then mount it and pivot before splashing
<apw> tjaalton, that i915_bpo failure ... did you notice it is return an error code of 0, which would imply no error
<apw> tjaalton, also as this is a load time failure, this should occur before you even know this is a skl or whatever, so how it can fail on one and not the other is beyond me
<apw> tjaalton, well unless your /boot/vmlinux is somehow out of sync with your kernel modules
<fg__> cking: I'm out for today, but I did some quick tests and bug 1560869 does not trigger here anymore with a manually built 0.6.5.6 (based on debian/jessie/0.6.5.2-2 and vanilla upstream). Will test xenial packages as soon as they are available.
<ubot5> bug 1560869 in zfs-linux (Ubuntu) "Concurrent zfs create and rename operations can lock a zpool completely" [High,In progress] https://launchpad.net/bugs/1560869
<cking> fg__, that's good to hear, the 0.6.5.6 passed all my regression tests overnight so we're happy with it so far
<cmagina> what is the best way to propose a clean cherry-pick from upstream to xenial?
<apw> cmagina, cherry-pick it to the tip of the tree you intend it to be applied and then format-patch it out and mail it in
<apw> make sure you -sx when you cherry-pick it
<apw> cmagina, though we'd prefer a bug to explain why at this stag
<apw> e
<cmagina> apw: fair enough, thanks, will do
<apw> cmagina, by that i mean a bug files _as_well_ as sending it in and referecned in the patch
<apw> see the buglink: s in the tree
<cmagina> yup, i understand
<apw> (i was being my usual british unclear self)
<cmagina> :)
<xnox> caribou, apw - yes linux-crashdump meta-package. i assume you have it all in hand, i'm just replying to my old pings =)
<apw> xnox, yes, its sitting on the tip of -meta for -16
<apw> rtg, make sure you update meta for that ...
<xnox> .... after beta-2 please, i don't want to test a respin =/
<apw> rtg, yeah i mean its in the core repo, so you should have it in for next time, for the -16
<tjaalton> apw: yeah the kbl install could be just messed up somehow, will check when i get back home (sunday)
<rtg> apw, ack
#ubuntu-kernel 2016-03-25
<ejat> The following packages were automatically installed and are no longer required:
<ejat>   linux-signed-image-generic
<ejat> Use 'sudo apt autoremove' to remove them.
<ejat> The following packages will be REMOVED:
<ejat>   linux-signed-generic
<ejat> The following NEW packages will be installed:
<ejat>   linux-headers-4.4.0-16 linux-headers-4.4.0-16-generic linux-image-4.4.0-16-generic linux-image-extra-4.4.0-16-generic linux-tools-4.4.0-16
<ejat>   linux-tools-4.4.0-16-generic
<ejat> The following packages will be upgraded:
<ejat>   linux-generic linux-headers-generic linux-image-generic linux-tools-virtual
<ejat> 4 upgraded, 6 newly installed, 1 to remove and 0 not upgraded.
<ejat> Need to get 69.0 MB of archives.
<ejat> After this operation, 297 MB of additional disk space will be used.
<ejat> Do you want to continue? [Y/n]
<ejat> should i proceed ? 
<infinity> ejat: No.
<infinity> ejat: You also shouldn't run -proposed.
<infinity> ejat: Specifically to avoid such things.
<ejat> :(
<ejat> is there a way to undo?
#ubuntu-kernel 2017-03-20
<jtaylor> have there been scheduler changes in recent kernel updates?
<jtaylor> I have schedule and sched_clock show up at 25% in all of my profiles
<jtaylor> that wasn't the case a few weeks ago
<jamieiles> Hi folks, the Ubuntu-3.13.0-113.160 tag isn't present in ubuntu-trusty.git, looks like it should be b5fea3e677cf9b2f85237eed1a6c56191384342d
<apw> jamieiles, hmmm, looking
<jamieiles> apw: I see the tag now, thanks
<apw> jamieiles, great ...
<tseliot> apw, rtg: are we going to get a backport of this commit in xenial? It looks trivial, and I think it would make sense to have it: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=08b259631b5a1d912af4832847b5642f377d9101
<rtg> tseliot, is it relevant for a 4.4 kernel ? The commit says 4.9
<tseliot> rtg: the CPU is supported by 4.4, but then it crashes after a while, as reported here: https://www.servethehome.com/amd-ryzen-with-ubuntu-here-is-what-you-have-to-do-to-fix-constant-crashes/
<rtg> tseliot, their fix is to run a 4.10 kernel.
<rtg> tseliot, we'll have a 4.10 based hwe-edge kernel in Xenial fairly soon
<tseliot> rtg: right, but they mention the actual commit (with a link): "There have been numerous reports of SMT issues and it is aÂ known fixÂ that got rolled out in the Linux 4.10 and 4.11 kernels as we mentioned in ourÂ release piece.Â "
<tseliot> rtg: when would that be?
<rtg> tseliot, I hope to get it into proposed today. working with apw on that
<tseliot> rtg: ok, cool
<dmj_s76> sforshee: I'll test out the -22 ucode when I get a chance
<sforshee> dmj_s76: thanks!
<dmj_s76> sforshee: I tested on one machine with an 8260 and it seems the new -22 ucode doesn't have the same problem.  There could be regressions elsewhere, but at least on the machine I tested things were working fine.
#ubuntu-kernel 2017-03-21
<smb> caribou, Do you have any kdump dump of a current 4.8 kernel to compare whether crash can load that one? I am beginning to suspect that the VM dumps may have issues with RANDOMIZE_MEMORY (though there is some change in the code that looks to be adding support for that).
<caribou> smb: that's what I tested yesterday on a Zesty VM with a 4.10 kernel ( debian/sid's crash) : it loads the vmcore produced after the panic in the VM but not the "virsh dump" one
<smb> caribou, Ah, sorry did not grok that then. Hm, would it be possible to put that dump somewhere I can pull it from. Then I could be lazy and not produce one on my own
<caribou> smb: sure
<smb> Could be something that virsh and xen-utils need to add to the elf info. Which maybe is already somewhere upstream but usually simpler to find once one knows what to look for
<jackpot51> Is it possible to get linux-firmware 1.161.1 into 16.04?
<apw> sforshee, ^
<sforshee> jackpot51: we can't take the package wholesale, but if there's something specific you need we can likely get it into the xenial package
<jackpot51> Yes, the intel wireless firmware for the 8265 from the 1.161.1 package is needed in 16.04
<sforshee> jackpot51: we had it in at one point, but it was causing regressions with some hardware configurations, see bug #1647826
<ubot5> bug 1647826 in linux-firmware (Ubuntu Yakkety) "intel 8260 doesn't work with linux kernel 4.8 when using ucode version 22" [High,Fix released] https://launchpad.net/bugs/1647826
<jackpot51> It has been updated so the 8260 now works
<sforshee> jackpot51: yeah, was just about to mention the new version
<jackpot51> So, are we good to try the new version in 16.04?
<sforshee> can you file a bug?
<sforshee> dmj_s76: when you tested the new iwlwifi firmware, was that with xenial?
<jackpot51> Sure
<jackpot51> Is this good: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1674748 ?
<ubot5> Ubuntu bug 1674748 in linux-firmware (Ubuntu) "Intel 8265 does not work with 16.04 linux-firmware 1.157.8" [Undecided,New]
<dmj_s76> sforshee: I believe so, I copied just the -22 into /lib/firmware and wifi still worked after reboot and suspend.
<dmj_s76> Yeah, firmware for the 8265 in xenial would be good!
<sforshee> I'll get it taken care of
<jackpot51> sforshee: Thanks!
#ubuntu-kernel 2017-03-22
<slangasek> apw, bjf: a lot of autopkgtest failures recently for linux/ppc64el in zesty; are we going to be getting back to green sometime soon?
<bjf> slangasek, please bring that up tomorrow with sforshee and rtg
<bjf> slangasek, actually, the tests look pretty good to me. the one real failure i'm seeing is with the kernel selftests. it looks like upstream hasn't built it on that platform
<slangasek> bjf: so could the testsuite itself detect that, so that we don't have to dig into the logs each time to know whether the failure is ignorable?
<sforshee> slangasek, bjf: the ppc selftests failure on ppc64el is because some of the tests don't build with pie enabled. We have a fix comitted, but since the tests run based on the zesty master branch it won't pass until the current kernel is released and master gets updated.
<apw> sforshee, is that zesty master ?
<apw> sforshee, if so you could probabally just shove it out as we care a lot less that that one rebases (which it likely won't anyhow) before release day
<sforshee> apw: yeah I suppose. I was wondering though if the tests shouldn't be checking out the tag for the kernel under test.
<apw> sforshee, these are the kernel self-tests right ?
<sforshee> apw: yes
<elmo> hey, I just rolled to 4.10! \o/
<apw> heh
<apw> elmo, and you are able to login to tell me so, so something must work
<rtg> apw, sforshee - will defaulting to consoleblank=0 in Zesty have any deleterious side effects that you can think of ? See https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017/comments/14
<ubot5> Ubuntu bug 869017 in kbd (Ubuntu) "Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)" [Medium,Triaged]
<sforshee> rtg: nothing comes to mind. My guess is that comment is right, that it was probably set up that way to avoid burn-in on CRTs which isn't as much of a concern nowadays
<rtg> sforshee, I'm sure it'll piss off someone though :)
<sforshee> rtg: no doubt
<snoerd> hey, since #ubuntu-boot seems to be abandoned, I'll try my luck here. Does anybody here have any experience with nfs-boot and overlayroot?
<apw> snoerd, i personally do not but there are people who who likely have played with that kind of thing
<apw> snoerd, but i would also suggest as people are on wildly different timezones, that
<apw> snoerd, you ask your question so people don't tell you they know and leave
<snoerd> apw: thanks, good point. My issue is plain and simple: booting over nfs works ( root dir passed as kernel parameter), as soon as I enable overlayroot, it hangs after successfully enabling overlayroot. It just prints "done" and that's been it
<snoerd> here's a screenshot: https://postimg.org/image/x14ljvolr/
<apw> snoerd, have you tried a "break=bottom" to get a shell at that point and have a look around ?
<apw> snoerd, look at dmesg that kind of thing
<snoerd> ahh, didn't know that parameter yet, thx. normally I'm poking around in userspace. gimme a sec
<apw> it actually is a userspace implemented thing, by initramfs-tools, but goes on the kernel command line for giggles
<snoerd> apw, sorry, was on the phone. If I use that parameter, I do in fact get a busybox shell at the end. however I cannot see something suspicous. only strange thing is that my nfs share is mounted in /root
<apw> snoerd, and is the overlay mounted yet ?
 * apw though bottom was after root was mounted
<apw> ie literally the next thing was chroot into it
<snoerd> doesn't look like it
<snoerd> i can actually chroot into /root, but I get an "inappropriate ioctl for device" error from bash
<snoerd> but it still works
<snoerd> hm
<snoerd> but no overlay
<snoerd> ls
<snoerd> damn :)
<apw> snoerd, oh that is before bottom, breaks=init instead
<apw> break=init
<snoerd> ahh, thanks. I'll try that
<snoerd> yeah, now I get the overlayroot. 
<apw> now at least you can see if it is working at all
<snoerd> ahh, i guess there is something severly broken. I just get a scrambled stack trace when I try to chroot into it
<snoerd> also, i can read in the overlay, but not write
<snoerd> after a bit of trying a got a readable version of the stacktrace. it happend when I tried to chroot into the overlay. maybe it is of help https://postimg.org/image/kjr8gav3r/
<snored> if somebody has a followup on the bug i've posted: I've joined this channel with my regular nick 'jules' 
<apw> jules, hey ... did you put a simple how to reproduce this in your bug ?  i assume it is pretty easy
<apw> jules, if so then i recon that that one can be bisected in a VM or something
<apw> jules, also what was the bug # ??
<jules> apw: I haven't reported it yet. reproducing it should be fairly straight forward, but you have to have a working PXE environment, which is a bit of a hazzle to set up.
<apw> jules, well if you are able to test kernels for it, we likely can supply them
<jules> apw: that should be no big deal. I'm writing the bug report now
<jules> apw: filed as bug #1675086 
<ubot5> bug 1675086 in linux (Ubuntu) "Kernel Bug when using nfsroot + overlayroot at the same time" [Undecided,New] https://launchpad.net/bugs/1675086
#ubuntu-kernel 2017-03-23
<fgvsg7w84> infinity
<fgvsg7w84> has canonical dropped employees?
<infinity> No one has ever left Canonical in 13 years; we're magic.
<fgvsg7w84> the magicians
<fgvsg7w84> I've seen them with my own eyes.
<fgvsg7w84> get that euro target
<fgvsg7w84> infinity: how many times has your magician broke into my home?
<fgvsg7w84> infinity: ex.: Your message wasn't delivered to rainct@ubuntu.com because the address couldn't be found. Check for typos or unnecessary spaces and try again.
<infinity> fgvsg7w84: I'd suggest talking to him about it, not asking random people on IRC.
<fgvsg7w84> asking the home invader?
#ubuntu-kernel 2017-03-24
<cyphermox> ogasawara: hi; did the security team review and OK linux-aws for main yet?
<cyphermox> (I'm doing the MIR review)
<ogasawara> cyphermox: I know we were discussing with them about it moving to Main, but I don't know if they have actually done the review.
<ogasawara> tyhicks: ^^
<ogasawara> I'm hopeful that the review should be relatively straight forward since it's based on the stock xenial distro kernel
<cyphermox> right
<tyhicks> ogasawara, cyphermox: hey - we haven't done a review yet
<tyhicks> ogasawara, cyphermox: like you mentioned, we're not going to do any sort of in depth review
<cyphermox> tyhicks: I'm not looking for an in-depth review necessarily, but at least acknowledgement that this is ok as a MIR
<cyphermox> rubber-stamping if that's what you want to do is fine by me, as long as somebody has looked at the bug
<cyphermox> https://bugs.launchpad.net/ubuntu/+source/linux-aws/+bug/1672850
<ubot5> Ubuntu bug 1672850 in linux-aws (Ubuntu) "[MIR] linux-aws" [Undecided,New]
<tyhicks> cyphermox: it is ok as a MIR - we have full confidence in the kernel team more than capably supporting the package
<cyphermox> :)
<tyhicks> ack from security
<cyphermox> ogasawara: so all that is missing is a team subscriber I think, for linux-aws bugs
<ogasawara> cyphermox: oh, that should be ~canonical-kernel-team, I can get that done
<apw> ogasawara, actually i don't think we use that one for that, there is another one
<ogasawara> apw: ah, ok, /me waits
<apw> i am sure slangasek added them to the right one last time, now what am i thinking of
<apw> ogasawara, i think it is ~kernel-packages
<apw> ogasawara, which you are a member of :)
<apw> ogasawara, yeah that is the one ... it is intended to stop us getting deluged with spam
<ogasawara> apw: hrm, I do not see ~kernel-packages listed as an option for me to select in the drop down of teams I administer to subscribe to linux-aws
<apw> oh you have to 
<apw> be an admin do you, asses
<apw> bdmurray, hey ... kernel-packages, that is the launchpad group for package "we" support right?  but we cannot use it as only an admin can subscribe it
<cyphermox> ahah oops.
<apw> (and that is you if that isn't clear :))
<apw> yeah, derp.  likely ~leannogasawara at least should be that
<leitao> rtg, Can you check if my emails to kernel-team were moderated again?
<leitao> I sent them from the subscribed email this time
<leitao> I do not see them at https://lists.ubuntu.com/archives/kernel-team/2017-March/thread.html
<rtg> leitao, you mean this set ? https://lists.ubuntu.com/archives/kernel-team/2017-March/083147.html
<leitao> rtg, yes. Thanks!
<rtg> leitao, they came throug unmoderated
<leitao> weird, but this set does not show up at https://lists.ubuntu.com/archives/kernel-team/2017-March/thread.html
<rtg> through*
<leitao> rtg, nm
<apw> leitao, does for me ... next to last thread
<leitao> i need more coffee
<rtg> refresh ?
<leitao> rtg, I was looking at the top of the page.
<leitao> we are good, sorry for the noise
<apw> heh, i was about to say the page is in a counter-intuitive order
<leitao> apw, yes, All the archives I read are sorted reversely 
<ogasawara> cyphermox: ok, ~kernel-packages is now subscribed
<ogasawara> thanks to apw
<ogasawara> bdmurray: nothing to do here now
<apw> ogasawara, heh it was him who clued me in, so thanks go to him
<bdmurray> ogasawara: sheesh, way to just dismiss me
<ogasawara> :)
<bdmurray> ogasawara: I'm glad I'm not on your team
<ogasawara> bdmurray: well, I don't want you injuring yourself even more, not after that nasty fall off the cliff
<bdmurray> lol
<leitao> rtg, I found an easy way to cherry pick those patches for #1675806. It is not a clean way, tho
<leitao> reverting ba46da7c1cc57d83f6af66bfe8f10516151c7923 and applying the KVM patchset, and then reapplying it (ba46da7c1cc57d83f6af66bfe8f10516151c7923)
<leitao> This solve most of the problems.
<leitao> anyway, I will try to create a clean tree next week.
#ubuntu-kernel 2017-03-26
<wryt> infinity: what is your apparent speed?
<wryt> do you think by em=mc2 or :
<wryt> L
<wryt> infinity: the speed of infinity is important if you mean an neverending story
<wryt> hence you have the saying from eternity to eternity, which not vanishing means twain neverending stories
<wryt> the spead of infinity matters so as not to have it dissolved
<wryt> you may have an apparent mean speed to give to MYSELF
<wryt> reletive so I can correct it
<chriswells> so much for t mobile and the nsa
#ubuntu-kernel 2018-03-19
<tsimonq2> Hm, bug 1635597 might need some looking at.
<ubot5`> bug 1635597 in makedumpfile (Ubuntu Trusty) "Ubuntu:talclp1: Kdump failed with multipath disk" [High,Confirmed] https://launchpad.net/bugs/1635597
<tsimonq2> The SRU wasn't marked as fine but someone commented saying it was.
<frickler> jsalisbury: smb: maybe I'm misunderstanding something, but it would be a shame if the bug didn't get fixed just because nobody can test it with Artful https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1748408
<ubot5`> Ubuntu bug 1748408 in linux (Ubuntu) "Servers going OOM after updating kernel from 4.10 to 4.13" [High,In progress]
<smb> frickler, The text is a template that not always covers the real case. But the HWE 4.13 kernel is derived from the artful kernel. So if you can do a verification in Xenial with the 4.13 HWE kernel, that is fine. 
<smb> frickler, there is a new HWE kernel in proposed as well (4.13.0-38.43~16.04.1). So mentioning that verification was done on that version.
<frickler> smb: oh, thanks for the pointer. I can test that, but it will take maybe more than 5 days. is that a hard timeout and the patch would get delayed to another kernel release if it is not met?
<smb> frickler, the time limit given is deliberately challenging. But at some point we will have to look at things which have not been verified and decide how much risk they pose. And if there is something that appears scary there still needs to be time to drop things and build new kernels. And all that within the 3 week cadence, so there is not too much time to wait.
<frickler> smb: o.k., thx for explaining, I'll see what I can come up with
<sforshee> sbeattie, tyhicks: the kernel_symbols_missing qrt test is failing for a different reason now, the /sys/module/foo/sections/.text files have mode 0400 since commit 277642dcca765a1955d4c753a5a315ff7f2eb09d
<sforshee> (this is with bionic if you didn't guess that already)
<sbeattie> sforshee: oh hrm, okay
<dijuremo> We seem to be observing a pattern on machines with the latest hew-16.04 kernel which froze when they have the latest BIOS from Vendors like DELL and Lenovo. These machines also seem to have NVIDIA cards installed, but I am not quite sure if the NVIDIA driver is part of the issue. Are there known issues around this?
<dijuremo> Rolling back the BIOS (pre-meltdown and spectre INTEL patches) fixes the freezing immediatley.
<dijuremo> Problem is that now some systems come with the latest BIOS' and forbid you from downgrading to earlier versions, so we effectively end up with a machine that cannot run Ubuntu.
<TJ-> dijuremo: were you reporting this about a week ago? We had the same issue we tracked to the same cause.
<TJ-> dijuremo: didn't go any further with regard to the kernel patches because the BIOS was rolled back. The investigation we did then seemed to show that BIOS microcode that Dell provided was the January one from Intel that had the known bugs in and was supposed to be withdrawn; and presumably should now the superseded by the late Feb Intel re-release
<dijuremo> We are seeing the problems with the latest February BIOS'
<dijuremo> We have seen them in some laptops and T5820 workstations
<dijuremo> The laptops were the 7480 line. One came with the old BIOS, one with the new. The laptop with new BIOS refuses to downgrade. States downgrading is *Blocked*
<dijuremo> The Lenovo machine is the M93p also using the latest February published BIOs.
<dijuremo> Seems like there is now a newer March 15 BIOS for the Latitude 7480, so I will have to give that a try.
<TJ-> Ahh, last week it was a server. I recommended an email be sent to one of the kernel dev's to forward to the Dell team responsible for the microcode upgrades
<dijuremo> In the laptop case, we did not even have discrete GPU, and the laptop would freeze after the GUI login would show up with 4.13.x Our solution on that one, since we could not downgrade the BIOS, was to go down to the 4.4.x series kernel
<dijuremo> So we had the laptop with older firmware running 4.13.x kernel no problems and the laptop with newer firmware running 4.4.x kernel and told the end user to *not* upgrade to 4.13.x or his machine will no longer work.
<TJ-> There are kernel command-line options you know? "nopti" and "nospectre_v2"
<dijuremo> TJ: Good info, will have to try again the next time I see the problem to find out if those help
#ubuntu-kernel 2018-03-21
<anon^_^> question regarding this ticket
<anon^_^> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1750937
<ubot5`> Ubuntu bug 1750937 in gcc-4.8 (Ubuntu) "4.4.0-116 Kernel update on 2/21 breaks Nvidia drivers (on 14.04 and 16.04) due to outdated gcc-4.8" [Undecided,Fix released]
<anon^_^> not sure it's fixed
<anon^_^> updated to 3.13.0-143-lowlatency
<anon^_^> Mar 21 00:30:32 ****** kernel: [   35.102961] nvidia: version magic '3.13.0-143-lowlatency SMP preempt mod_unload modversions ' should be '3.13.0-143-lowlatency SMP preempt mod_unload modversions retpoline '
<anon^_^> nvidia driver fails to load
<anon^_^> problem appeared on kernel update
<anon^_^> also discussed here
<anon^_^> https://devtalk.nvidia.com/default/topic/1030325/nvidia-driver-installation-v387-26-on-ubuntu-16-04/
<anon^_^> the described fix there doesn't seem to fix the issue
<anon^_^> gcc defaulted to gcc 5
<anon^_^> switched gcc with update-alternatives to 4:4.8.2-1ubuntu6
<anon^_^> testing
<anon^_^> also had to update dkms manually
<anon^_^> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1750937/comments/30
<ubot5`> Ubuntu bug 1750937 in gcc-4.8 (Ubuntu) "4.4.0-116 Kernel update on 2/21 breaks Nvidia drivers (on 14.04 and 16.04) due to outdated gcc-4.8" [Undecided,Fix released]
<anon^_^> well, that didn't go well
<anon^_^> it does seem there is an issue with Trusty 14.04 and recent retpoline changes
<anon^_^> nvidia driver module is unloaded in 3.13.0-143-lowlatency
<anon^_^> modinfo nvidia-384 -k 3.13.0-143-lowlatency
<anon^_^> vermagic:       3.13.0-143-lowlatency SMP preempt mod_unload modversions 
<anon^_^> no retpoline flag
<anon^_^> kern.log
<anon^_^> Mar 21 02:11:55 ****** kernel: [   60.800613] nvidia: version magic '3.13.0-143-lowlatency SMP preempt mod_unload modversions ' should be '3.13.0-143-lowlatency SMP preempt mod_unload modversions retpoline '
<anon^_^> that's after reverting to gcc 4:4.8.2-1ubuntu6
<anon^_^> the re-install of 3.13.0-143-lowlatency, reboot, followed by reinstall of nvidia-384
<anon^_^> ^then
<anon^_^> nobody around?
<anon^_^> until this is fixed by the kernel team, nvidia drivers are broken, unless a user manually edits vermagic.h
<anon^_^> # /usr/src/linux-headers-3.13.0-143/include/linux/vermagic.h
 * anon^_^ sighs
<anon^_^> after editing vermagic.sh using instructions here
<anon^_^> https://devtalk.nvidia.com/default/topic/1030325/nvidia-driver-installation-v387-26-on-ubuntu-16-04/
<anon^_^> -#ifdef RETPOLINE
<anon^_^> +/* #ifdef RETPOLINE */
<anon^_^> +#if 1
<anon^_^> then dkms for nvidia driver was removed and re-installed
<anon^_^> sudo dkms remove nvidia-384/384.111 -k 3.13.0-143-lowlatency
<anon^_^> sudo dkms install nvidia-384/384.111 -k 3.13.0-143-lowlatency
<anon^_^> modinfo nvidia-384 -k 3.13.0-143-lowlatency
<anon^_^> vermagic:       3.13.0-143-lowlatency SMP preempt mod_unload modversions retpoline 
<anon^_^> now retpoline shows up, which should permit kernel to load nvidia driver again
<anon^_^> hopefully the kernel team fixes this the right way. Most users won't be able to fix this themselves
<apw> tseliot, ^
<tseliot> dijuremo: I don't think I have seen that problem. Have you filed a bug report about it?
<juergh> tseliot, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1750937
<ubot5`> Ubuntu bug 1750937 in gcc-4.8 (Ubuntu) "4.4.0-116 Kernel update on 2/21 breaks Nvidia drivers (on 14.04 and 16.04) due to outdated gcc-4.8" [Undecided,Fix released]
<juergh> seems like a race between the kernel and gcc updates.
<tseliot> juergh: oh, nothing I can do about it, I suppose
<anon^_^> apw, juergh it's not fixed
<anon^_^> sorry, going through channel log now
<anon^_^> i had to remove latest kernel update, nvidia drivers, re-install, *then* manually edit vermagic.h in the kernel source
<anon^_^> and then manually remove and re-install nvidia-384 entry in dkms
<anon^_^> reproducible even now
#ubuntu-kernel 2018-03-22
<JoshX> Hi! I have multiple ubuntu 14.04.5LTS systems running on the same hardware with the same kernel producing the same kernel crashes..
<JoshX> crashlogs are here: https://pastebin.com/xnGmtLNg and https://pastebin.com/0vQX9fKz for example
<JoshX> kernels are  Linux pc7-1428 4.4.0-116-generic #140~14.04.1-Ubuntu SMP Fri Feb 16 09:25:20 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<JoshX> on all systems
<JoshX> every time this happens, the machine is under medium IO load, low memory load
<JoshX> and after the crash behaves very eratic.. random crashing processes, reboot and shutdown fail
<JoshX> so far we've had this on 9 systems running identical hardware and software
<JoshX> doing mainly writing ffmpeg -> h264 stream -> pipeline -> to JPG frames to disk (disks are connected via USB in a mirror MD0)
<TJ-> JoshX: looks like it could be due to fragmented memory allocations 
<JoshX> TJ-: is this something I can do anything about?
<JoshX> we're running stock 14.04.5LTS with no exciting software on average hardware
<JoshX> Intel(R) Core(TM) i7-5550U CPU @ 2.00GHz CPU With 16Gb DDR3L ram
<TJ-> JoshX: I'm only guessing, but if the processes are requesting many smaller allocations (I infer due to the strack trace showing compaction_alloc) it's posisble that eventually the kernel cannot create a block large enough for a request
<JoshX> I understand, but am i running out of memory or out of large enough fragments?
<TJ-> you'll notice the strack trace passes through do_huge_pmd_anonymous, try_to_compact_pages etc
<TJ-> so I suspect fragmentation has ended up in a situation where even compaction cannot handle things (possibly there's a bug there that ought not to be as well)
<TJ-> I think there are some kernel 'knobs' you can twiddle to influence these things (sysctl)
<JoshX> perhaps I can add a PPA and try a upstream/newer/beta kernel?
<JoshX> of enable something to produce more/better logging?
<JoshX> the crashes are so random I have yet to reproduce them at will
<TJ-> JoshX: do they happen after the systems have been working for some time ?
<JoshX> well these 2 systems crashed after 200k sec and 400k sec if i see the logs
<JoshX> so 2.5 and 4 days or so
<JoshX> not too long
<TJ-> JoshX: if those processes are fragmenting memory that's about what I'd expect - I wouldn't expect this immediately after boot
<JoshX> but we're running some nodejs processes, rabbitmq, ffmpeg
<JoshX> and ionotify on file close events
<JoshX> on ~40 files / sec
<JoshX> so we're handeling tons of IO events on file closes to move files to the right place
<JoshX> and we're queuing stuff in rabbitmq.. 
<JoshX> could be erlang/rabbitmq messing things up
<JoshX> could be nodejs
<JoshX> but the end result is always the same, an unstable machine that is pingable and accessible via ssh
<JoshX> but which does not work anymore.. (so monitoring this sucks since all seems normal)
<JoshX> can i perform a command on these machines to see how bad fragmentation is at this moment?
<JoshX> so I could log things over time and keep a graph or something to see if the problem is slowly getting worse?
<TJ-> JoshX: try "echo m > /proc/sysrq-trigger"
<TJ-> JoshX: then check dmesg
<JoshX> https://pastebin.com/Xu6130pW
<TJ-> JoshX: oh, forget that, we have buddy now! "cat /proc/buddyinfo"
<JoshX> root@pc7-1428:/var/log# cat /proc/buddyinfo
<JoshX> Node 0, zone      DMA      1      1      1      0      2      1      1      0      1      1      3
<JoshX> Node 0, zone    DMA32    325    115     59     36     10      8     50     44     26      0      0
<JoshX> Node 0, zone   Normal     20     22      4     12      5      3    101     84     44      0      0
<JoshX> 'erm..'
<JoshX> is this good? bad? :)
<TJ-> the numbers are blocks of 4KiB, 8KiB, 16KiB....
<TJ-> you might to read the docs in ./Documentation/ directory of the kernel source for the detail of that
<JoshX> I have a system in stress test now thats reporting higher numbers
<JoshX> root@pc7-1422:~# cat /proc/buddyinfo
<JoshX> Node 0, zone      DMA      1      1      1      0      2      1      1      0      1      1      3
<JoshX> Node 0, zone    DMA32    283     94     18     16      7     10     10     38     39      2      0
<JoshX> Node 0, zone   Normal    209   3879     31      9     11     19     23      7      4     10      1
<JoshX> and the memory info from dmesg: https://pastebin.com/q6iZC3Sk
<TJ-> you might try adjusting the memory overcommit settings
<JoshX> how might I do that?
<apw> it seems unreasonable for it to panic like that there
#ubuntu-kernel 2019-03-18
<FurretUber> Hi, I found a memory leak on i915 on the kernel 5.0.0-7 and 5.0.0-8 from Disco Dingo. It seems similar to another i915 leak where it leaks when Vulkan applications are used
<tjaalton> FurretUber: please file it upstream
<tjaalton> so we'll get a fix via the stable branch, maybe
<kubkde> hey there fellers. i'm interested in rebuilding my kernel to include f2fs modules. is this the correct channel or should i be using a support channel instead?
<kubkde> i should be cloning the git repo from kernel.ubuntu.com, correct? I've seen others use apt to pull
<kubkde> So do I really have to download the whole thing? 
<kubkde> I didn't expect to download 800+ MB to add a couple modules lol
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-xenial/+bug/1820526 is a bit of a problem
<ubot5> Ubuntu bug 1820526 in linux-meta-lts-xenial (Ubuntu) "linux-signed-generic-lts-xenial 4.4.0-143 depends on linux-generic instead of linux-generic-lts-xenial" [Critical,Confirmed]
<arighi>  /q tru
<klebers> apw, ^ our linux-meta-lts-xenial is producing a linux-signed-generic-lts-xenial that depends on linux-generic instead of linux-generic-lts-xenial
<kubkde> How can I load f2fs modules into a kernel to compile?
<chiluk> @apw @cking ... Here's my last few months of work rolled up into an e-mail.  https://lkml.org/lkml/2019/3/18/706
<kubkde> And in a broader sense, is the page linked in the topic up to date? 
<chiluk> afaik I've seen 512ac99 accepted on some of the linux-stable trees.  I'm not sure who's doing stable maintenance any more, but you might want to watch out on this one.
<cking> chiluk, this is excellent analysis; thanks for the heads up on this
<cking> ..be interesting to see what upstream says about it
<chiluk> Yeah I figured you guys might want a heads up...
<chiluk> especially with the stable submissions... and performance is hard kind of issues.
<kubkde> is https://wiki.ubuntu.com/Kernel/ well rounded enough to learn from? 
<chiluk> You can definitely learn from it.
<chiluk> what are you trying to accomplish kubkde? 
<chiluk> you might want to try with the Documentation directory in the linux kernel source...
<kubkde> chiluk, thanks for replying. I want to rebuild a kernel to include f2fs so I don't have to use dracut or initramfs. And also see if what I could accomplish/make 'better' from compiling my own.
<chiluk> You are unlikely to make much if anything "better" imho.. but you definitely can turn on the flag..
<chiluk> and yes that documentation is the best place to go for compiling Ubuntu kernels with the Ubuntu specific patches 
<chiluk> so you don't break anything.
<kubkde> chiluk, I'll take a look at the documentation direction right now, thanks. Would I be applying the patches after I've done my modifications? Also, what do people generally modify kernels to do? I saw one called 'XanMod' and it looked...the same?
<kubkde> Christ this is thick.
<chiluk> People who generally modify kernels are the same who don't know what they are doing...
<chiluk> in general the only time you should modify kernel sources is if you are fixing something that is broken, and directly fixing c code
<chiluk> or you need to do something specific like enable a module that is not enabled.
<kubkde> How long have you been developing? I don't mind the reading but I'm afraid I might end up forgetting to go to work.
<kubkde> I see
<chiluk> kubkde..  in your case.. .I just checked and CONFIG_F2FS_FS=m is already set in the 4.15 ubuntu kernels
<chiluk> you may simply need to modprobe f2fs to get things functioning.
<kubkde> :O
<chiluk> really you are unlikely to see any performance differences from building a custom kernel..
<chiluk> sometimes even turning on architecture specific optimizations for your specific cpu end up in regressing performance.
<kubkde> How do you check that? And doing modprobe f2fs doesn't work. I'll try to pull up the specific errors I got in regards to f2fs 
<chiluk> but I'd love to hear how that goes.
<chiluk> kubkde ... you need to "sudo modprobe f2fs"
<kubkde> chiluk, that's definitely what I figured. What I plan to do is strip it down to be hardware specific 
<chiluk> that's the thing though.
<kubkde> Of course...sudo modprobe f2fs. I chrooted into the install after it was done, too
<chiluk> so much is built as modules now that nothing is loaded that doesn't need to be there.
<kubkde> Interesting
<chiluk> the other problem is that so much of the kernel is integer logic that the differences between architectures are almost negligible as all of the fancy architecture specific bits  *(aes, simd, sse, etc) don't really apply to the kernel.
<chiluk> kubkde... good luck though.. I'd love to hear if you make something faster.. You definitely can make the memory footprint smaller.  but ram is cheap these days.
<kubkde> chiluk, I've got so many questions but I don't want to be that pita looking to be spoonfed haha. Reducing memory would be huge for me since my VMs keep eating it all up. 
<kubkde> Of the encyclopedia of that documentation folder, which one do you think would be best to start with? 
<chiluk> you should look at the cloud kernels instead
<kubkde> cloud kernels?
<kubkde> woah wtf
<chiluk> sorry apt install linux-image-virtual
<chiluk> those are minimal kernels that only support cloud architectures ..
<chiluk> i.e. xen, kvm, .. not sure if others are supported... maybe vbox..
<chiluk> kubkde... did I make your day?
<kubkde> chiluk, you sure did :p
<chiluk> kubkde... as for learning kernel internals/adminning I'd start with Documentation/admin-guide... 
<chiluk> if you only care about ubuntu kernels the wiki you linked is probably best.
<chiluk> but it assumes you know a lot of the stuff in the Documentation folder.
<kubkde> Thanks, I really appreciate all the info you've given me. I run most VMs locally but even the idea of cloud kernels. Still wtf'ing lol. 
<kubkde> I see, that's somewhat ironic
<chiluk> 'tsall good ... those are not well publicized.... glad to be of service..
<chiluk> kubkde just to be explicit the virtual kernels are supposed to be run in the guests not the host.
<kubkde> I'm going to stick with Ubuntu so I don't get sidetracked. Ideally once I get good, I'm going to check out cloud kernels since it'd be useful on a resume and for my own media servers lol. 
<kubkde> Sure that makes sense, thanks for the clarification
<kubkde> It feels like once someone knows how to write a kernel a whole other world of possibility is unlocked 
<kubkde> understands a kernel* rather than how to write one
<kubkde> Alright....I can't believe you actually read through this chiluk 
<chiluk> kubkde: to be truthful, I only check this once every month or so, and usually it's just to harass my canonical friends about cool stuff I'm working on... so you got REALLY lucky.
<kubkde> :o
<kubkde> :O
<kubkde> holy sh*t lol
<chiluk> yeah..
<kubkde> I didn't even recognize
<kubkde> Lol
<chiluk> usually this channel is kind of one of those things where you ask, and then wait a day and see if someone responds.
<chiluk> usually someone does.
<kubkde> Then I got really really lucky
<kubkde> You've got my gratitude chiluk :)
<chiluk> although if you are just learning ... start with the admin-guide... have fun building a custom kernel.. see if you find any performance improvements... *(I have a feeling you won't)... there's a lot to learn.
<kubkde> What's the general timeframe I should be expecting to have a full understanding?
<kubkde> And sorry to bug because I'm sure you're busy, but I couldn't find any documentation on a module named (I think) libcrc32c
<chiluk> kubkde... never... Linus does not claim to have a full understanding.  As for your module, probably start with modinfo libcrc32c .. then you might have to go to the source.
<chiluk> fortunately modules are usually a pretty good place to start learning kernel programming as they tend to be more self-contained than other parts of the code base...
<chiluk> another thing to do is actually read a book... I can recommend "linux kernel development" by robert love
<chiluk> but may expects that you already know a bunch of os fundamentals
<kubkde> Ah that would be an issue
<chiluk> cool I'm out kubkde... good luck.. I've done my good dead for the month.
<kubkde> Turns out I just need to build and install crc32c to run dracut -f --add-drivers f2fs successfully
<kubkde> And yeah for sure
<kubkde> Thanks for all the tips! 
<kubkde> Today's my lucky day lol
<kubkde> Take care chiluk, see you in a month
<wxl> hey folks. i seem to be having a problem building upstream virtualbox kernel modules in xenial/4.4.0-143 but the bug seems to be related to 4.4.169 and on. this is true in all of the version they have available from 5.0-6.0. and yet the ubuntu version (5.1) works fine. seems related to a api change https://bugzilla.kernel.org/show_bug.cgi?id=202365 but i'm confused as to how being on an older kernel 
<wxl> i'm still having this problem. any insight?
<ubot5> bugzilla.kernel.org bug 202365 in Other "broked nvidia and vbox drivers" [Normal,New]
<chiluk> kubkde dract is a fedora initramfs builder.. you are probably going to want update-initramfs instead ..
<kubkde> chiluk, right, but the f2fs module either still wasn't loading or something else wasn't working. I tried modprobe f2fs and added it in /etc/initramfs-tools/modules. I do know that all the crc* modules have to be loaded from reading Fedora/Arch forums. Grub's current git (2.03~) has f2fs but it fails make-check. Dracut actually worked once...but once. So the plan is to rebuild a kernel to have all those modules in 
<kubkde> it...although after reading that kernels are mostly full of modules I don't know if compiling my own would be a solution to having f2fs as my root partition
<kubkde> btw chiluk if you're still around is there anything you think is exciting that's coming up in the new kernels or that could be added? And I know Dracut is for Fedora, but does that mean I'm more than likely to just break more things when I could be using initramfs-tools lol
<chiluk> ^^ it could break things you are unaware of.
<FurretUber> Earlier today I found a memory leak on i915 on kernel 5.0. It was asked to report on upstream. I did the bisect but where should I report it? 
<FurretUber> As this is fixed on 5.1-rc1, for FreeDesktop bugzilla it would be considered already fixed
<tomreyn> FurretUber: https://www.kernel.org/ states that 5.0(.2) is a stable branch, and the latest. i think FDO would still care having it fixed in the 5.0 branch.
#ubuntu-kernel 2019-03-19
<FurretUber> From my last experiences, only the fix lands on drm-tip it would be considered fixed there. The last resort would be the kernel Bugzilla, but it's are for maintainers to see bugs reported there
<tinoco> .
<RSpliet> It looks like Ubuntu kernel 4.4.0-143-generic is API incompatible with earlier versions from the 4.4.0 branch. Compared against 4.4.0-142, in include/linux/mm.h the get_user_pages() method has had the "force" boolean flag removed.
<RSpliet> Is this a violation of Ubuntu policy worth reporting (as it breaks out-of-tree module build), or should such changes be expected?
<RSpliet> Oh here's the offender: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/mm.h?h=v4.4.176&id=8e50b8b07f462ab4b91bc1491b1c91bd75e4ad40
<apw> RSpliet, that ABI change was a necessary change for a security fix.  the known out of tree drivers were corrected, but obviously unknown ones we cannot remediate
<sorinello> Hello. Anyone knows how well Ubuntu supports BTRFS ? I maybe someone knows. I found some articles f rom 2015-2016 NOT recommending BTRFS yet
<RSpliet> apw: thanks for the response. If this is "know breakage" I'll leave it with that. I personally rely on an older version of NVIDIAs graphics driver for (reverse engineering) reasons. I suspect very few other people have a compelling reason to rely on older drivers.
<RSpliet> And I managed to work around the issue for myself
#ubuntu-kernel 2019-03-20
<mathieu__> Hi, I am looking for a suggestion on how to best report a kernel bug. I tried $ ubuntu-bug linux but this appears to collect information using dmesg since the last boot. I have logs from the previous buggy boot and I wonder what I should do with them. 
<apw> mathieu__, you can file a bug with www.launchpad.net/ubuntu/+source/linux/+filebug and attach the files by hand
<mathieu__> apw, ok, will do
<sorinello> Hello. Anyone knows how well Ubuntu supports BTRFS ? I maybe someone knows. I found some articles f rom 2015-2016 NOT recommending BTRFS yet
<chiluk> It supports btrfs as well as the kernel on which it was forked supports it.
<chiluk> the article you are referencing is probably more a statement on the stability/reliability of the filesystem..
<chiluk> of which I have not heard very many good things..
<chiluk> basically btrfs is the least stable of the common filesystems.
<chiluk>  #eatsyourdata
<chiluk> I'm sure cking has more opions on that.
