#ubuntu-kernel 2005-07-18
<lamont__> ENOFABBIONE
<lamont__> fabbione: or are you here?
* lamont__ wonders how hard it might be to build a 2.6.12 kernel for ia64 using gcc-3.3
<lamont__> since the ones in the archive all seem to machine check
<fabbione> morning
<crimsun> morning
<chmj> fabbione: ping 
<zul> hey
<fabbione> hi zul
<zul> how goes it fabbione 
<fabbione> not too good.. but i am surviving
<fabbione> i didn't felt very well today
<fabbione> you? did you start at the new job?
<zul> yep am at work right now
<zul> alot of reading to do
<chmj> hey chuck 
<zul> hey chmj 
<zul> arrrrgh....my kingdom for grep -r 
<Mithrandir> just use grep -r?
<zul> solaris
<Mithrandir> build gnu coreutils, then
<Mithrandir> or use find -type f -print0 | xargs -0 grep $foo
<zul> its more fun to complain though ;)
<zul> jbailey: so are you coming to ols?
<jbailey> zul: Yup
<jbailey> zul: Are you going / is your new job downtown?
<lamont> fabbione: so how dependent is 2.6.12 on gcc-3.4, really?
<lamont> that is, if I forced it to use gcc-3.3, would it be a usable kernel?
<fabbione> lamont: yes it would... but i am pondering to switch to gcc-4.0 with this upload...
<fabbione> do you have a recent gcc-4.0 on hppa?
<lamont> no
<lamont> you see, first I need _X_
<fabbione> this/next... as soon as amd64 is unfucked
<lamont> so pls don't switch hppa to 4.0... 
<fabbione> well i am not going to upload today or tomorrow
<lamont> likewise, the ia64 kernels all machine check _very_ early... I'm suspecting something about 3.4
<fabbione> have been sick all day
<lamont> and any gcc-4.0 that is not at least current today is majorly b0rked on hppa. that much is known
<fabbione> check???
<fabbione> i am not sure i understand what you mean for ia64
<lamont> machine-check == HPMC (hppa land), hardware induced fatal error
<fabbione> ah ok
<lamont> --> kernel is tickling the hardware in ways that are not legal
<fabbione> ok i get it
<fabbione> hmmmmm
<lamont> ia64 literature calls them "MCA"s
<lamont> so I figured I'd build 2.6.12 kernel with 3.3 and see if that even booted.    Then comes binary-search fun.
<fabbione> well if that works for ia64 and hppa.. it's ok with me
<fabbione> lamont: if you could actually check how many pkgs still B-D on gcc-3.3
<fabbione> we can consider reverting the gcc-3.4 thing from the kernel completly
<fabbione> and stay with gcc-3.3 on all arches
<fabbione> i doubt we will manage to drop gcc-3.3 from breezy anyway
<fabbione> lamont: anyway i am heading off line
<fabbione> you have full power on the devel branch :)
<fabbione> so go ahead as you prefer
<lamont> fabbione: grep gcc-3.3 /var/lib/apt/lists/.._dists_breezy_main_source_Sources | wc -l
<lamont> 11
* lamont -> work
<JaneW> ogra: ping (2nd try)
<zul|working> fabbione: http://sourceforge.net/mailarchive/forum.php?thread_id=7717644&forum_id=38938
<zul|working> oh yay the cba is done
<dilinger> fabbione: what's ubuntu planning on doing if 2.6.13 is released within a week or two?
<jbailey> dilinger: Last I spoke to him, ignoring it.
<jbailey> We're passed UVF now.
<jbailey> past?
<jbailey> Hmm.
* jbailey hates the English language
<dilinger> aie, goddamned mosquitos
<dilinger> jbailey: heh, ok
<jbailey> UVF has passed. =)
<jbailey> There we go. =)
#ubuntu-kernel 2005-07-19
<lamont> jbailey: "we have passed" "we are past"
<jbailey> lamont: Thanks. =)
<jbailey> Some days I think that perhaps I should've done some english grammar school at some point.
<jbailey> It also frightens me that despite that I haven't I scored so well on the English portion of my GMAT.
<fabbione> morning
<fabbione> 33 097:23:14:59 ATM        Info       Wan0 6144 Kbps Down, 768 Kbps Up, 17 dB Margin
<fabbione> YAY
<jbailey> fabbione: Is that an upgrade to your connection?
<fabbione> yeps :)
* jbailey connects to trider for a test.
<fabbione> oh i am already abusing it with torrents.. but there is space :)
<jbailey> 150ms or so average.
<jbailey> Better by a factor of 3. =)
<fabbione> eheh
* jbailey goes to sleep
<fabbione> night jb
<zul> hey
<fabbione> hey zul
<zul> how goes it fabbione
<fabbione> zul: tired.. and ready to stop for today
<zul> were you sick yesterday?
<fabbione> yeah
<zul> oh that sucks
<jbailey> Colin asked yesterday about the idea of hotplugging 3c509 cards.
<jbailey> Anyone know if isa-pnp can be made to behave like PCI?
<jbailey> Like, with modalias or something equally trivial?
<chmj> fabbione, ping 
<zul> chmj: i think he might be taking a nap
<chmj> is he still sick ?
<zul> think so
<jbailey> It would also be like 11 hours into his working day by now.
<zul> only? :)
* lamont tries to remember which of the *fs thangs 2.6.13 was planning to drop
#ubuntu-kernel 2005-07-20
<fabbione> morning
<Mithrandir> hi fabio
<fabbione> hey Mith
<thom> hey dudes
<fabbione> hey thombot :)
<dilinger> hello everybody
<fabbione> yo dilinger 
<dilinger> (hi dr nick!)
<fabbione> dilinger: how is going the unified config manager?
<dilinger> it's going well
<fabbione> cool
<dilinger> i chose sleep over working on it last night, though
<dilinger> first decent amount of sleep i've gotten in like 3 days :)
<fabbione> ehhehe
<JaneW> dilinger: slacker!
<JaneW> *duck*
<dilinger> heh
* JaneW hides
* fabbione switches ClusterFilesystem to TESTED
<JaneW> no really I hope you had a good rest.
* JaneW *hugs* fabbione
<dilinger> JaneW: if i had a way to record the snoring of my roommate here, you'd understand fully why i have not been able to sleep ;p
<dilinger> fabbione: i don't know how you guys feel about ruby, but that's what i'm using for it.  if necessary, it can be ported to perl or something
<fabbione> JaneW: i could actually switch InstallerVolumeManagement too to Tested
<dilinger> or python
<fabbione> dilinger: does the tool run at build time? or does it run offline before upload?
<dilinger> offline before upload
<fabbione> than i don't care at all
<dilinger> although something will need to run at build time to generate the configs
<dilinger> from the individual pieces
<fabbione> until i don't have to add 203927 B-D i am ok even with tcl
<dilinger> but that's a simple cat, it can be put in the makefile
<fabbione> exactly :)
<dilinger> hrm, tcl, what a great idea
* dilinger starts rewriting 
<fabbione> ahahha
<JaneW> fabbione: 'Do it'!
<thom> POP THE TRUNK
<fabbione> JaneW: i will probably today or monday... i am packaging at least one GUI for it...
<fabbione> JaneW: just get something a bit more consistent
<fabbione> JaneW: we only the d-i side atm as per discussion with Kamion
<fabbione> (see one of the recent notes in it)
<Lathiat> Has ahtere been any attention to the dynamic_hz patch? (And whether its likely to be accepted, or is, are there problems?)
<fabbione> chmj: pong
<chmj> fabbione: can we have this driver included in the kernel http://bluetooth-alsa.sourceforge.net/
<chmj> fabbione: I have tested it on .12 successfully
<fabbione> chmj: is that for the bluetooth spec?
<chmj> fabbione: yes 
<fabbione> ok i will look at it soon
<fabbione> but i can't upload kernels for a while
<fabbione> amd64 is busted
<chmj> thanks 
<fabbione> and it will FTBFS
<chmj> ok, later will do 
<fabbione> i am going to wait max monday, otherwise i will temporary drop amd64
<fabbione> chmj: is there something that's not CVS out of that project?
<chmj> fabbione: http://sourceforge.net/project/showfiles.php?group_id=116589
<fabbione> chmj: did you use the 0.4 version?
<chmj> fabbione: the one from CVS, yes 
<fabbione> 0.4 != cvs
<fabbione> so i need a cvs checkout....
<chmj> fabbione: _and_ the one from CVS,  yes 
<fabbione> ah ok
<fabbione> which one do we need?
<chmj> fabbione: cvs checkout, its stable 
<fabbione> it looks pretty safe to include
<chmj> sweet 
<fabbione> chmj: driver is added
<fabbione> time to start the we
<chmj> cool, the we ?
<fabbione> week end
<chmj> oh right, enjoy :) 
<zul> someone had taken my nick...the bastard
<chmj> hehe, did you ghost them ?
<zul> of course...
<zul> wouldnt have it any other way..
<zul> brb
#ubuntu-kernel 2005-07-23
<Mithrandir> good morning
<fabbione> morning
<Mithrandir> getting up late, fabio? ;-)
<Mithrandir> bah, leaving for airport
<fabbione> Mithrandir: ehehe later :)
<chmj> morning 
<infinity> fabbione : Dude, why does linux-headers-2.6.12-3 have a versioned dependency on libc6?
<fabbione> infinity: because the headers contains a bunch of executable in script/
<fabbione> same reason why they are arch: any
<fabbione> and not arch: all
<infinity> Ugh.  Okay, the better question is "why are we shipping script/"?
<infinity> scripts, even.
<fabbione> because they are required for linking
<fabbione> at MODPOST stage 2
<fabbione> the same reason why ppc64 headers are borked
<infinity> Including the binaries?
<fabbione> yup...
<infinity> Cock.  That's retarded.
<fabbione> the binaries are little utilities very arch specific required for linking
<infinity> We should at least move scripts/ to the flavour-specific packages, then, and make the big linux-headers arch:all, no?
<fabbione> infinity: that's basically required...
<fabbione> to unfuck ppc64
<fabbione> but i need to review the overall build process
<fabbione> because the binaries are built once from another source dir :/
<fabbione> this system is sick
<fabbione> breezy+1 must be a royal cleanup
<fabbione> otherwise you can do it while i will be VAC
<fabbione> or start now? ;)
<infinity> If I do it, we'll end up with something much sicker. :)
<fabbione> ahaha
<infinity> Mostly because the current situation just looks SO EFFIN WRONG to me.
<fabbione> infinity: ideally we should switch to the new debian build system
<fabbione> but i don't have the time/power atm
<infinity> (This arose from a desire to install headers on hoary, which is impossible, for no sane reason other than upstream crack)
<infinity> Is Debian's new system nicer to work with?
<fabbione> why on earth do you want to do that?
<fabbione> infinity: i know they are working on a much cleaner build system similar to our but sane
<infinity> Because I'm running a stock breezy kernel on hoary on my laptop, because the hoary kernel suck monkey balls on my new hardware.
<fabbione> i had really no time to look at it yet
<infinity> (WiFi drops out constantly, machine crashes, my grandmother gets cancer, y'know.. the usual)
<fabbione> yeah yeah... time to change hw
<fabbione> the kernel is fine :)
<infinity> <laugh>
<infinity> I'm pretty sure it all comes down to the ipw2200 driver being in constant flux, and my 2915ABG being very poorly supported in hoary.
<infinity> No big deal.
<fabbione> yeah
<infinity> If this mystical new Debian kernel build system works, I'll be happy to investigate a switch.
<fabbione> infinity: it's in SVN
<fabbione> it looks easier.. or it sounds like..
<fabbione> but it's not stable
<infinity> dilinger : ping.
<fabbione> they are still fluxing around some stuff
<infinity> dilinger : Make me your bitch.
<infinity> Stable isn't such a big deal, as long as we can cut something useable for ourselves for breezy, and merge back in sync post-breezy.
<infinity> It's not like what we HAVE is any good either.
<fabbione> well it is.. they are still shifting pkgs name around :P
<fabbione> we know that our work
<fabbione> to a certain degree
<infinity> With enough massaging.
<fabbione> nah it doesn't need that much
<fabbione> we were not ready to do cross-compiling.. that's all
<fabbione> and these are bits and pieces that are coming while we grow
<fabbione> infinity: i think scripts is the only thing that is more arch specific than the headers
<fabbione> at least from a first check
<fabbione> the reason why linux-headers (generic) is not arch: all is because we can apply (and we do) arch specific patches
<fabbione> otherwise kernel and headers won't match
<fabbione> so in theory fixing scripts/ should be enough
<zul> hey
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> zul: no too bad.. going off line for a little nap now
<zul> cool...am at work
<zul> fabio im back as of tonight..
<dilinger> fabbione: hey, did you see my config tool thingy?
<dilinger> zul: you too..
<zul> dilinger: nope i havent been busy getting settled in with my new job
* dilinger twiddles his thumbs.  why oh why can't we have a fast host for svn.d.o?
<dilinger> http://svn.debian.org/wsvn/kernel/trunk/scripts/?rev=0&sc=0
<dilinger> initsplit for breaking up the configs, and split-config for managing them
<dilinger> try it out, find bugs, fix or report them ;)
<zul> ok cool...ill try it out tonight
<fabbione> hey dilinger 
<fabbione> no i had no time really..
<fabbione> i am fighting with a bunch of things all together
<dilinger> ok, well, when you get the chance..
<dilinger> i'm already finding it hugely useful
<fabbione> sure i will
<dilinger> changing config options across 5 different archs, some 20-something flavours :)
<fabbione> or better i must :)
<fabbione> YAY
<fabbione> finally i got to fix the ppc64 headers
<doko> l-k-h?
<fabbione> damn the header pkg is getting a mess
<fabbione> doko: nope.. the real kernel headers
<fabbione> doko: i just finished to build gcc 4.0.1 on sparc.. (test build)
<fabbione> i am will soon let you know about the ICE and the LINKING thing
<doko> any changes needed? I was going to make a new 4.0 upload today
<fabbione> doko: no changes.. but i will not be able to build it until cairo and gtk+2.0 are rebuilt
<fabbione> hi lamont
<fabbione> there was a leak of libXrender.la in some /usr/lib
<fabbione> that will make it FTBFS
<fabbione> doko: if you can give me something like 30 minutes to check a couple of things i would be really grateful
<doko> no problem, doing test builds on ppc and amd64 first
<fabbione> doko: ok
<lamont> morning fabbione
<fabbione> i would like to be able to give you some more info on the ICE (if still there) and that LINKING thing..
<fabbione> perhaps it's an easy fix (the latter at least)
<fabbione> YAY 
<fabbione> GO GCC!!!!!
<fabbione> doko: now it fails on the same package with a more interesting message
<fabbione> the 2 could be easily related tho..
* fabbione investigates
<fabbione> doko: is 4.0.1 more paranoid than 4.0.0 ??
<fabbione> first log:
<fabbione> util.c: In function 'timestamp':
<fabbione> util.c:29: warning: format '%06ld' expects type 'long int', but argument 4 has type '__suseconds_t'
<fabbione> second log:
<fabbione> util.c: In function 'timestamp':
<fabbione> util.c:24: error: storage size of 'tz' isn't known
<fabbione> util.c:29: warning: format '%06ld' expects type 'long int', but argument 4 has type '__suseconds_t'
<fabbione> util.c:24: warning: unused variable 'tz'
<fabbione> note that this is the same code
<fabbione> only change is gcc
<zul> meh..
<fabbione> libc6-dev: /usr/include/time.h
* fabbione blames the toolchain
<fabbione> bah it's even an used var
<fabbione>        The use of the timezone struct is obsolete; the  tz_dsttime  field  has  never
<fabbione> I CAN BLAME GTK!
<doko> fabbione: hmm, should that be %p instead?
<fabbione> there it is... _BSD_SOURCE is not defined
<fabbione> doko: no that's just a warning and i don't care
<fabbione> the failure there is due to -D_BSD_SOURCE not being there
<fabbione> = struct timezone has no size
<fabbione> JEEEE
<fabbione> doko: the point is that _BSD_SOURCE is not defined in the previous log
<fabbione> and it was passing this point
<fabbione>  /usr/lib/gcc/sparc-linux-gnu/4.0.1/../../../../lib/crt1.o:../sysdeps/sparc/sparc32/elf/start.S:60: multiple definition of `_PROCEDURE_LINKAGE_TABLE_'
<fabbione> no
<fabbione> it's not fixed
<fabbione> doko: what do you want me to check to get this fixed?
<fabbione> let's move to #toolchain
<doko> hmm, I don't know ...
#ubuntu-kernel 2005-07-24
<fabbione> morning
<Mithrandir> good morning
<fabbione> hey Mithrandir 
#ubuntu-kernel 2006-07-17
<zul> hey
<BenC> ho
<zul> how is it going?
<infinity> BenC: Why do I have a feeling that "disable the debconf stuff" in kernel-package completely disabled all useful configuration (like symlink updating, creating initrd, etc, etc)?
<infinity> BenC: The postinst on my 2.6.17-4 kernel is rather... Uhh... Light.
<infinity> Oh, nevermind, that one was done with the old kernel-package...
<infinity> This was produced by kernel-package version 9.001ubuntu17.
<infinity> So, here's hoping the 2.6.17-5 kernels are less broken.
<BenC> new kernel package is good
<BenC> and about 10 minutes from uploading new kernel
<zul> yay
<BenC> hopefully this will be the knot-1 kernel
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-5.13 uploaded, fixes lrm builds | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<BenC> infinity: 5.13 uploaded
<zul> is headers still broken
<zul> yeah...never mind me i been in dreamland again
<infinity> BenC: Thanks.  I'll babysit it and see if LRM works when it's done.
<BenC> I built it locally, so there's a %40 chance it will work :)
* Starting logfile irclogs/ubuntu-kernel.log
<kintaro> hi guys..i would like to know whats the use inetrd and sysmap..i tried compiling linux on manual before..what i did is compile then copy bzimage to /boot..and thats it then restart..not ubuntu distro....any idea..?
* Starting logfile irclogs/ubuntu-kernel.log
<kriebly> Hi there. Does anyone know when the linux-source-2.6.15 package will be patched for latest local exploit (http://www.frsirt.com/english/advisories/2006/2816)?
<doko> BenC: reparing to replace linux-kernel-headers 2.6.17-5.12 (using .../linux-kernel-headers_2.6.17-5.13_powerpc.deb) ...
<doko> Unpacking replacement linux-kernel-headers ...
<doko> dpkg: error processing /var/cache/apt/archives/linux-kernel-headers_2.6.17-5.13_powerpc.deb (--unpack):
<doko>  trying to overwrite `/usr/include/scsi/scsi.h', which is also in package libc6-dev
<doko> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<doko> ohh, infinity pasted that before ...
<fabbione> include/asm/byteorder.h:5:28: error: linux/compiler.h: No such file or directory
<fabbione> BenC: that's building git head (x86 server)
<fabbione> BenC: WARNING: drivers/pci/hotplug/ibmphp.o - Section mismatch: reference to .exit.text: from .smp_locks after '' (at offset 0xc)
<fabbione> TONS of those ones
<fabbione> are they harmless?
<fabbione> meh debconf kernel upgrading message grrr iiikkkkkk neeeee
<zul> heylo
<fabbione> BenC: for some reasons 1.7 lost the rhcs-modules- Provides
<fabbione> BenC: but i don't understand crap on how the new control thing works...
<BenC> fabbione: for linux-{image,headers} stuff, edit debian/config/flavours-control.stub
<BenC> fabbione: The linux/compiler.h thing is harmless, and so are the warnings about mismatches
<BenC> zul: ping
<fabbione> BenC: ok. the problem is that only certain images should provide rhcs-modules2
<fabbione> ah ok
<fabbione> never mind
<fabbione> i was right
<fabbione> i can't just edit that one
<fabbione> rhcs-modules2-1 is not provided by all images
<fabbione> so either we enable GFS/OCFS everywhere or we need to find another way
<BenC> what the provides line?
<BenC> and where is it enabled?
<BenC> that should be one of those things we automate somehow based on the kernel config
<zul> BenC: pong
<BenC> zul: #kernel-security on OFTC
<zul> im coming
<BenC> fabbione: as soon as you get something for me for rhcs, I am uploading 2.6.15-5.14
<fabbione> BenC: it was on Provides before on some images
<fabbione> BenC: i am about to push some changes but not the Provides thing
<BenC> do a pull, I just pushed some things to fix lkh
<BenC> rhcs-modules-2 or rhcs-modules2?
<fabbione> rhcs-modules2-1
<fabbione> BenC: i am theoretically done
<fabbione> all is pushed to my edgy branch on people
<fabbione> 2 things
<fabbione> - make sure it build everywhere because for this test-round i was focused only on i386
<fabbione> - gfs might export symbols and change the abi
<fabbione>   Changes by Fabio M. Di Nitto:
<fabbione>   * Update gfs2 to the latest git code.
<fabbione>   * Update dlmfs to the latest git code.
<fabbione>   * Readd gfs1 filesystem.
<fabbione>   * Cleanup gfs1/gfs2 headers.
<fabbione>   * Export all gfs1/gfs2/dlm headers to userland.
<fabbione> this is my changelog
<BenC> fabbione: hmm, I may have to skip those until I get lkh fixed
<BenC> I have the rhcs fix in
<fabbione> BenC: ok. they can wait
<fabbione> BenC: but please pull them in once knot-1 is done
<BenC> sure thing, thanks
<fabbione> thanks to you
<BenC> fabbione: damn you for already having a roomate in germany :P
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-5.14 uploaded, if this one's broke, you can deal with it :P | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<BenC> hmm...I think it's time I move the 12gauge pump action shotgun off my desk
<zul> grrr...reiserfs bad....
<BenC> want to borrow the shotgun? :)
<zul> yes please...
<jbailey> BenC: 2.6.17-5 works for me with atheros wireless.
<jbailey> Network manager in edgy happens to be broken, but iwconfig and dhclient do the right things.
<kriebly> Hi there. Do you folks know when the linux-source-2.6.15 package will be patched for latest local exploit (http://www.frsirt.com/english/advisories/2006/2816)?
<kriebly> (or if it will be patched)
<BenC> kriebly: It will be uploaded shortly
<BenC> how long it takes to get in the archive and available is up to security team
<kriebly> good to know. Thank you!
<kriebly> i justed wanted to find out, to see if I need to bug our developers to make some authentication utility compatible with the current kernel
<BenC> there is  a local workaround, made possible with some mount options
<kriebly> mounting /proc a certain way? would that break anything important?
<zul> BenC: why is there flavour specific linux-headers?
<BenC> zul: because the .config's are different
<zul> ah ok
<BenC> zul: they are created in such a way that only files that are different from linux-headers-2.6.1x-x are actually in the flavour specific packages
<zul> ok because im just working on the xen-headers right now
<fabbione> BenC: yeah i thought you did prefer to share with Adam and be able to smoke.. you know i did quit smoking 5 months ago
<BenC> zul: Are you handling breezy/hoary?
<fabbione> BenC: and ogra agreed not to smoke in the room
<BenC> fabbione: Ah, that's a good point
<zul> BenC: yes i will do the patch when i get home tonight
<BenC> zul: ok, thanks
* Starting logfile irclogs/ubuntu-kernel.log
<zul> midgets?
<fabbione> hmmmm
<BenC> rabid foxes
<BenC> we've killed two of them in the past week
* BenC does a "no ABI bump" dance for dapper
<zul> meh...need faster computer..
<zul> must...kill...wife
<zul> patch almost done for hoary
<fabbione> speaking of which
<fabbione> i should really upgrade my server to dapper
<BenC> I love being able to build linux-source for i386 in 30 minutes
<fabbione> but now.. stop
<fabbione> BenC: ehhehe that long? :P
<fabbione> time to play OutRun
* fabbione -> PS2
<BenC> 5 kernels in 30 minutes ain't so bad :)
<zul> it takes me a half hour to build one flavour 
<fabbione> zul: that's because you don't use ccache
<BenC> actually, he does I think
<mjg59> I don't have enough disk space for ccache
<fabbione> mjg59: disk space is cheap now
<zul> i use ccache
<mjg59> fabbione: Not in 1.8" form, it's not
<fabbione> zul: if you have ccache, just fork more.. export CONCURRENCY_LEVEL=16
<mjg59> I should set up an mdns distcc farm using the pile of laptops
<fabbione> 1.8" ????
<mjg59> Yeah
<fabbione> ccache+distcc = the rock
<BenC> yeah, put those laptops to good use
<fabbione> ok i am off
<fabbione> later
<BenC> later
<zul> installing domino is so mucho fun
<zul> later
#ubuntu-kernel 2006-07-18
<chuck> hey
<fabbione> hey BenC !
<fabbione> BenC: i just updated my edgy branch on people
<fabbione> it should build
<fabbione> at least it does on i386
<fabbione> lock_dlm in gfs2 and statfs for both gfs1 and gfs2 are broken but i am already speaking with upstream to get a fix
<BenC> ok
<fabbione> BenC: cheers mate
<fabbione> it is synced with whatever was in git 6 hours ago
<fabbione> so there should be no conflicts
<BenC> good deal, I'll sync it as soon as I get my kdump stuff tested
<BenC> interesting...for ppc64 I may be able to use a single kernel for kdump/kexec
<fabbione> nice
<BenC> dpkg-deb: building package `linux-image-2.6.17-kdump' in `../linux-image-2.6.17-kdump_2.6.17-5.15_amd64.deb'.
<BenC> sweet
<Mithrandir> BenC: you pung?
<BenC> Mithrandir: just letting you know that kernel+kernel-stuff is all good, but I suspect you know that by now :)
<Mithrandir> BenC: yeah, it's noticed.  Thanks, though
<zul> BenC: i be interested to know how you got the kdump built
<zul> or i could just see in git never mind ;)
#ubuntu-kernel 2006-07-19
<BenC> it uses some changes I made in kernel-package
<BenC> also will need newer kexec-tools, and a mod to grub to ignore -kdump files and add a "crashdump mode" altoption when a kdump kernel is installed
<BenC> cool, grub already ignores vmlinux files
<zul> i might make some changes to kernel-package eventually if we decide xen for edgy+1 and thats a big if
<BenC> this sucks, I can't seem to make the amd64 kernel jump into the kdump kernel
<kriebly> thanks for patching 2.6.15.7. By the way, CVE-2006-2935 also happened to get fixed in linux-source-2.6.15_2.6.15-26.44
<kriebly> sorry. I meant  linux-source-2.6.15_2.6.15-26.45 
<fabbione> morning
<fabbione> BenC: still around?
<BenC> yeah
<fabbione> did you already pull from me?
<fabbione> if not, don't worry, i have another few bits for you that i am build right now
<BenC> I did
<fabbione> ok no biggie :)
<fabbione> thanks
<BenC> pulled and pushed, so repull before pushing back to me
<fabbione> i will prepare the new stuff for when you wake up
<fabbione> yeps
<fabbione> already doing
<BenC> cool
<BenC> kdump is so not working
<BenC> at least not on amd64
<BenC> need to test i386
<fabbione> hopefully within the next few days i will get a fix for the dlm stuff
<fabbione> i should show you an OOPS
<fabbione> perhaps it's something in our kernel
<BenC> cool, kdump works on i386 at least
<fabbione> nice
<fabbione> BenC: you can pull from me if you want
<fabbione> the change is proc support for gfs
<zul> hey
<zul> hi
<fabbione> BenC: ping?
<fabbione> BenC: could you please pull from me again? I have a few small changes on the cluster stuff. Nothing too fancy
* fabbione should also test OCFS2 but will do tomorrow
<BenC> fabbione: ok
<zul> BenC: scarey...http://paste.ubuntu-nl.org/18361
<BenC> zul: nice
<zul> now i just have to get the xen usersace stuff built properly
<ogra_> BenC, [4294741.935000]  usb 2-1: new full speed USB device using ohci_hcd and address 2
<ogra_> [4294742.063000]  usb 2-1: not running at top speed; connect to a high speed hub
<ogra_> [4294742.339000]  Initializing USB Mass Storage driver...
<ogra_> with 2.6.15-23 
<BenC> so it's a problem on dapper too?
<ogra_> (it doesnt matter where i plug it in, even though it suggests to use a different port)
<ogra_> yeah
<ogra_> as i said before, if i unload ohci_hcd and ehci_hcd and then load ehci_hcd first, devices are recognized correctly (HD -> ehci, headset -> ohci)
<ogra_> so i was suspecting its the load order somehow ...
<BenC> usually the load order doesn't affect it though
<BenC> ehci can be loaded/unloaded at any time
<ogra_> hmm
<ogra_> then the direve itself might be buggy ... could it be realted to the fact that i have to use nolapic ?
<ogra_> *driver
<BenC> doubtful
<ogra_> hmm...
* ogra_ reboots back to sanity
<zul> great...the person in the cubicle across from me is talking about poison ivy in places where i dont want to know
<fabbione> BenC: when do you plan to do the next kernel upload?
<fabbione> BenC: i just realized that the redhat-cluster-suite is FTBFS without headers :)
<zul> later
<BenC> fabbione: Very soon
<BenC> well, after knot-1 actually
* _kylem snores from OLS.
<airlied> _kylem: you in the HAL talk?
<_kylem> nope.
<_kylem> the basement left room (B?)
<airlied> ah the open driver talk?
<_kylem> yeah.
<airlied> the hal talk in C is also very sleepy..
<_kylem> hch is being entertaining as always...
<_kylem> BenC, did we discover that non-modular scsi would boot on your a500?
<_kylem> airlied, amazingly my wireless seems to be more or less working
<airlied> _kylem: is the talk of any interest? I thought about going to that instead as it was along the lines of my talk..
<_kylem> airlied, it's basically ibm talking about how they helped adaptec deal with some problems.
<fabbione> BenC: ok great! just please make sure to have my last changes and we will all be very happy :)
<_kylem> it's not 'interesting' but it would be informative if you were an IHV.
<airlied> ah cool.. not so interesting then..
<_kylem> yeah. he's made a few references to your talk re: uncooperative vendors.
<BenC> _kylem: with defconfig, yes
<_kylem> BenC, ok.
<_kylem> if wireless keeps working, i'll try to bang on that in the next hour.
<BenC> _kylem: I went through and tried fiddling with some options that were s/y/n|m/ between the configs to see if I could nail it down
<_kylem> no luck?
<_kylem> :(
<BenC> only got through half the options (about 20 total) that were different
<BenC> then had to mess with getting a working kernel in for knot-1 over the weekend
<_kylem> ok.
<BenC> I should turn the a500 back on and let it suffer in the heat till I figure it out...maybe that'll persuade it :)
<BenC> "work or burn"
<_kylem> :)
<_kylem> aha. i was right.
* _kylem does a little dance.
<_kylem> brb.
<jwest-> hi
<jwest-> anyone awake
<jwest-> I'm using Ubuntu on vmware and when I tried to upgrade the kernel, gnome stopped working
<jwest-> does that mean i need to make a fresh install?
<crimsun> more than likely that means you need updated vmware modules
<crimsun> where does Ubuntu break in the boot process?
<jwest-> thought as much would need to update vmware
<jwest-> I'm not sure... I checked update for the new kernel, it downloaded, updated, and when I rebooted X was gone
<jwest-> Ubuntu even removed some of my old programs
#ubuntu-kernel 2006-07-20
<jwest-> maybe try this tommorrow
<jwest-> thanks though
<zul> hey
<kylem> benc. ok. i found the problem.
<kylem> but my wireless crapped out before i was able to mention it.
<zul> aiie....slow close
<kylem> fuck, and it is crapping out now.
<zul> i blame the westin
<zul> ...and i should be there tomorrow
<kylem> nice.
<kylem> BenC, would it help if i fed you parisc patches? i can probably pretty easily automatically populate a tree.
<BenC> _kylem: If I can git-pull them against 2.6.17.x, then yeayh
<BenC> or against a clone of the ubuntu git tree
<kylem> okie doke.
<BenC> so what's the problem?
<kylem> you pulled the async scsi scanning stuff from the parisc tree. unless scsi is built into the kernel (so it can be __init) it won't pause and wait for the async scan to complete.
<kylem> i'm genning a diff to revert that bit.
<kylem> otherwise there's a bit in cvs now that gives you a module to load.
<kylem> (it's designed to be the last thing the initramfs loads, and waits for scans to completE)
<BenC> oh really?
<BenC> that'd be interesting...Kamion would actually like it so he doesn't have to load ide_generic in weird ways
<BenC> but that doesn't solve the problem of our current config not even getting serial output
<BenC> s/serial/console/
<zul> BenC, when you get a sec can you check my kernel config and im not on crack or anything my initrd seems to be failing
<BenC> xen?
<zul> yep
<fabbione> morning guys
<zul> you are up early
<fabbione> yeah change of core hours
<fabbione> it's too warm during the day
<zul> ah
* fabbione still doesn't see the last changes merged "upstream" and looks in BenC direction with hope and smile :)
<BenC> fabbione: I have it pulled, just finishing some things up before a push
<fabbione> BenC: cool! thanks a lot dude
<fabbione> getting this redhat stuff sorted has been a real pain
<fabbione> but i am down to 4 patches from 13
<fabbione> all the other 9 have been absorbed upstream
* ..[topic/#ubuntu-kernel:irc.freenode.net] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-5.14 uploaded, if this one's broke, you can deal with it :P | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<pmjdebruijn> hi
<pmjdebruijn> how can I change the ubuntu-kernel configs through menu config?
<pmjdebruijn> I only see the old config stuff in on wiki
<zul> hi
<pmjdebruijn> http://paste.ubuntu-nl.org/18429
<pmjdebruijn> why does the dapper kernel break when compiled on Debian?
<bernard_> pmjdebruijn: i suspect it broke because acpi is not enabled
<pmjdebruijn> bernard_, yeah, right... but that should be considered a bug right?
<bernard_> yup. i guess ubuntu kernels are rarely compiled with acpi off. it should be a trivial fix though. if you look inside arch/i386/kernel/setup.c, the call to check_acpi_pci() just needs to move inside the #ifdef CONFIG_ACPI block.
<pmjdebruijn> hmm right
<pmjdebruijn> it's already surrounded by a #ifdef CONFIG_X86_IO_APIC
<bernard_> yes. it needs to go inside CONFIG_ACPI also.
<pmjdebruijn> bernard_, ok, will do
<pmjdebruijn> if my fix/patch works, where should I submit it, it seems asif launchpad doesn't accept kernel bugs
<zul> yes it does
<zul> look for linux-source-2.6.15
<zul> BenC: my kernel-package patch works
<pmjdebruijn> oh and how do I figure out which IO scheduler I'm using?
<pmjdebruijn> my dmesg doesn't clear that up
<makx> grep sched /var/log/dmesg
<makx> indicated by the (default) line
<pmjdebruijn> makx, I have no (default) line
<pmjdebruijn> that's my point
<maswan> pmjdebruijn: /sys/block/<device>/queue/scheduler
<pmjdebruijn> noop [anticipatory]  deadline cfq
<pmjdebruijn> right!
<pmjdebruijn> that's what I was afraid of... anticipatory is still default :(
<pmjdebruijn> I'm trying to backport the edgy kernel to dapper
<pmjdebruijn> and I'm getting this:
<pmjdebruijn> http://paste.ubuntu-nl.org/18437
<pmjdebruijn> I'm doing to this primarily to see whether there have been fixes to usb-mass-storage, because my usb-mp3-player doesn't work properly
<Keybuk> "His suggestion was to merge it into x86-64 as a sort of special case - making Andi Kleen its maintainer in the process. Andi showed a striking lack of enthusiasm for this idea."
<Keybuk> hahaha
<Keybuk> (on i386)
<thom> heh
<fabbione> BenC: http://librarian.launchpad.net/3501440/buildlog_ubuntu-edgy-sparc.ocfs2-tools_1.2.1-1ubuntu2_FAILEDTOBUILD.txt.gz
<fabbione> are headers still broken on sparc?
<Mithrandir> BenC: freeze is over now, so you're free to upload your kernel stuff.
<BenC> Mithrandir: thanks
<BenC> fabbione: shouldn't be
<fabbione> BenC: looks like we are still missing headers....
<makx> Keybuk: any conterargs if i kill of the prereqs stuff in initramfs-tools?
<Mithrandir> makx: uh?
<Keybuk> makx: I've always thought it was silly, as it wastes time on boot ... I always thought we should just assemble it in the right order at update-initramfs time
<Keybuk> *BUT* jbailey will point out the initramfs is supposed to be runtime assembled
<Keybuk> which is why you need the PREREQS
<makx> Keybuk: what about numerical order aka 05evms 10md 20lvm 90cryptsetup
<Keybuk> it's allegedly less flexible
<makx> prereqs has no easy way to be first or last
<Keybuk> I was actually mulling the idea of maybe replacing the initramfs init with upstart ... ;)
<makx> prereqs wasts boot time and hinders klibc only plan
<makx> what is upstart?
<zul> BenC: ill send you the patch tonight for kernel-package its a very small patch
<makx> also lots of script writer get-their.name-totally_wrong
<BenC> fabbione: Actually, it looks more like sparc headers are just broken
<fabbione> <fabbione> are headers still broken on sparc? <-
<fabbione> :)
<BenC> fabbione: the include for those headers should probably be wrapped in __KERNEL__
<BenC> actually, why is ocfs2 including page.h anyway?
<BenC> on all other arches, it is an empty file
<BenC> in lkh at least
<fabbione> BenC: no idea
<fabbione> it was building before
<makx> Keybuk: google doesn't give hints on upstart? -v 
<Keybuk> http://wiki.ubuntu.com/ReplacementInit
<Keybuk> makx: why do prereqs affect klibc-only?
<BenC> fabbione: I'd edit mount.ocfs2.h and remove the asm/page.h include
<fabbione> BenC: can you make sure that's the right thing to do?
<BenC> fabbione: nm, I see the problem...it'll be fixed in the next upload
<fabbione> ok
<fabbione> thanks
<BenC> that actually is the right thing, but I can work around it
<fabbione> well if it's the right thing i can do it
<makx> Keybuk: basename usage - thought to get rid of both as prereqs is flacky
<fabbione> i am just on the edge every day to leave stuff in proper order
<BenC> fabbione: it's the right thing, but I'm not sure it will work :)
<makx> Keybuk: btw thx for the doc
<fabbione> BenC: exactly :)
<Keybuk> makx: it's intended as our replacement for /sbin/init in the real root ... but for edgy+1 it may make some sense to start it in the initramfs instead <g>
<pmjdebruijn> anybody here a clue why this fails: http://paste.ubuntu-nl.org/18437
<fabbione> BenC: it looks like we will need to go and dig into GFS2/GFS failures. According to upstream it works for them and it fails with our kernel
<BenC> lamont: ping
<makx> Keybuk: there is an side issue not mentioned in this spec, usually when you upgrade a Debian box you find lots of devices running that weren't before
<Keybuk> makx: "devices running" ?
<makx> Keybuk: sorry to warm s/devices/services/
<pmjdebruijn> oh silly me, it's because of the extra tag
<Keybuk> makx: right, upgrade brings in new services ... ?
<BenC> well, it might bring in new devices too :)
<BenC> ipw3945 comes to mind
<makx> Keybuk: no postinst brings new service that wasn't running before upgrade
<Keybuk> BenC: if an upgrade to etch upgraded my atheros to an ipw3495 I'd be impressed
<Keybuk> makx: oh, right ... the way a postinst starts a service you explicitly stopped
<BenC> ah, I thought you meant general upgrades
<makx> Keybuk: yup
<pmjdebruijn> bernard_, thanks for the help, I posted it: https://launchpad.net/bugs/53533
<bernard_> pmjdebruijn: looks good! ta.
<makx> Keybuk: daemontools are not mentioned, they are the best for keeping services up atm
<Keybuk> makx: that goes nowhere near the use cases mentioned
<makx> Keybuk: matches Corey
<Keybuk> which is near the bottom, no?
<makx> second use case afais
<fabbione> Keybuk: any chance you can upload udev to fix libvolumeid today?
<Keybuk> fabbione: yes
<fabbione> Keybuk: thanks dude
<zul> makx: is there any changes to initramfs that debian did for xen?
<makx> run depmod if that wasn't run previously
<zul> ah ok
<zul> if anyone is interested the proceddings for ols is up http://www.linuxsymposium.org/2006/proceedings.php 
<makx> Keybuk: it would be cool if that init could snapshot like resume to disk some parts of the boot process :)
<Keybuk> makx: how do you mean?
<zul> wohoo..
<zul> xen_mem: Initialising balloon driver.
<makx> Keybuk: idea from aboves ols proceeding
<Keybuk> makx: -v please :p
<makx> see "Improving Linux Startup Time Using Software Resume"
<makx> this ols papers features the idea of snapshot booting
<mjg59> It's not a bad idea
<mjg59> Would need careful integration work, though
<makx> Keybuk: using shell parameter expansion instead of basename, works well. so leaving the prereqs for now.
<kriebly> my Dell Precision 470's  aren't happy with the kernel I compiled from linux-source-2.6.15_2.6.15-26.45 :(
<kriebly> need to do more troubleshooting...
<kriebly> i probably missed something simple
<kriebly> cd /join nethack
#ubuntu-kernel 2006-07-21
<kylem> BenC, feel free to git pull hera.kernel.org:/pub/scm/linux/kernel/git/kyle/ubuntu-hppa.git branch master.
<kylem> i've revvi've reverted the async scsi stuff which should help.
<Keybuk> BenC: around?
<zul> BenC: http://70.29.57.2/ubuntu/xen/xen-naming.patch it only touches the xen bits
<BenC> Keybuk: yeah
<BenC> zul: ok
<zul> sweeeet...ill upload a new one tomorrow
<BenC> zul: I'll upload kernel-package
<BenC> I need my changes in it
<zul> ok sounds good
<zul> im just rewriting the rules file so it uses kernel-package
<Keybuk> BenC: can we get linux/linkage.h back? :)
<Keybuk> http://librarian.launchpad.net/3507234/buildlog_ubuntu-edgy-i386.sysklogd_1.4.1-18ubuntu2_FAILEDTOBUILD.txt.gz
<fabbione> morning
<fabbione> BenC: ping?
<BenC> Keybuk: ok
<BenC> fabbione: hey
<fabbione> BenC: yo
<fabbione> BenC: do you feel like looking into the cluster stuff or is it too late for you?
<BenC> fabbione: sorry, too much going on for the past hour or so, and I'm beat
<fabbione> BenC: no problem.. 
<pmjdebruijn> http://paste.ubuntu-nl.org/18511
<pmjdebruijn> do I have to be root?
<fabbione> BenC: when you wake up can you please pull from my edgy branch?
<fabbione> BenC: i have 2/3 fixes for GFS and GFS2
<fabbione> we are only missing one from upstream now that i have no idea what to do about
<fabbione> and if you can manage to upload before you leave for holidays i can get the rh-c-s binaries to build too
<zul> hey
<zul> BenC: so when are you going to upload a new kernel-package?
<fabbione> i hope he is going to do everything today before he goes in holidays
<fabbione> otherwise sparc is borked for headers and so are other arches :)
<fabbione> and packages
<fabbione> and ...
<fabbione> a..
<fabbione> ..
<fabbione> .
<zul> when does his holidays start?
<fabbione> end of his friday i guess
<zul> oh..
<BenC> fabbione: actually, I'll be around till Sunday afternoon
<BenC> but I am planning on an upload tonight
<fabbione> BenC: well it's weekend :)
<zul> not it isnt :)
<BenC> kernel-package + grub + linux
<fabbione> BenC: btw the OOM killer doesn't work. i just found out by mistake
<BenC> not for me yet :)
<Keybuk> just trying to find some documentation on the suspend format
<Kamion> so, the swsusp format appears to be:
<Kamion> PAGE_SIZE with 10 bytes at the end reading "S1SUSPEND\0"
<Kamion> then a struct swsusp_info
<Keybuk> it replaces the entire swap partition?
<Kamion> think so, S1SUSPEND goes in the same place as SWAP-SPACE or SWAPSPACE2 AFAICT
<Kamion> see power/swsusp.c:mark_swapfiles
<Kamion> now, a struct swsusp_info is { struct new_utsname; u32; unsigned long; int; unsigned long; unsigned long }
<fabbione> BenC, Keybuk: well something is stored in md sb as i pasted on -devel
<Keybuk> fabbione: can we not have this conversation right now, please
<Kamion> the corresponding bit of a swap partition is { unsigned int version; unsigned int last_page; unsigned int nr_badpages; unsigned char uuid[16] ; char volume_name[16] ; ... }
<Keybuk> right
<Keybuk> the swap partition is at the start of the page
<Keybuk> uh
<Keybuk> swap partition header
<Keybuk> and the SWAPSPACE2 bit is at the end
<Kamion> the start of a swap partition is a char[1024]  to allow room for boot images
<Kamion> the SWAPSPACE2 is right at the end of that
<Keybuk> right
<Kamion> and the other fields like uuid and stuff immediately follow
<Keybuk> uh, no
<Keybuk> wrong
<Keybuk> the start of a swap partition is a char[1024] 
<Keybuk> THEN the header struct
<Keybuk> the SWAPSPACE2 is definitely at the very end of the page
<Keybuk> it reads 0+PAGE_SIZE_10
<Keybuk> 0+PAGE_SIZE-10
<Keybuk> even
<Kamion> oh, sorry, you're right
<Kamion> page size confusion on my part
<Keybuk> volumne_name appears to be the "label"
<Keybuk> and uuid is obviously the UUID
<Kamion> yes, it is
<Keybuk> (though mkswap doesn't have an option to set the UUID)
<Kamion> it generates it automatically
<Keybuk> right
<Keybuk> how come the installer didn't do that?  custom mkswap?
<Kamion> busybox mkswap, yes
<Kamion> I'm pulling the uuid changes into that
<Keybuk> d-i is more NIH than I am :)
<Kamion> :)
<thom> Keybuk: keep dreaming
<Keybuk> ok
<Keybuk> now the swsusp header goes at the END of the page too, by the looks of it
<fabbione> Keybuk: sure we can wait after stuff is broken and data lost.. no problem at all
<Keybuk> it has a reserved block on the front of PAGE_SIZE - 20 - sizeof(swp_entry_t)
<Keybuk> fabbione: dude, if you're not going to be helpful and go find out whether the RAID stuff actually does hardcode sd* names in the block somewhere, please be quiet
<fabbione> Keybuk: i told you before what is hardcoded. major and minors
<Kamion> he said on #ubuntu-devel that it hardcodes major numbers in the block
<Keybuk> fabbione: ok, then it's broken
<Kamion> still, it might be helpful to tackle one problem at a time
<Keybuk> and probably broken today, in fact
<Keybuk> explains a few bugs
<Keybuk> back to swap
<fabbione> Keybuk: well then the transition need to take that into account. You can't just break stuff like this
<Keybuk> fabbione: dude, it's already broken
<Keybuk> dapper won't guarantee ordering of multiple scsi devices
<Keybuk> neither did breezy
<Keybuk> this is us trying to FIX that
<fabbione> ok don't break my raid.. i don't care about others.
<zul> heh
<Keybuk> static struct swsusp_header {
<Keybuk>         char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)] ;
<Keybuk>         swp_entry_t image;
<Keybuk>         char    orig_sig[10] ;
<Keybuk>         char    sig[10] ;
<Keybuk> } __attribute__((packed, aligned(PAGE_SIZE))) swsusp_header;
<Keybuk> Kamion: ^ so it appears that the swsusp header contains a copy of the original swp_entry_t
<Keybuk> so a swsusp first page looks like "Blah blah blah ... swp_entry_t SWAPSPACE2 S1SUSPEND"
<Kamion> oh yes, good point, I hadn't got round to figuring out what orig_sig was
<Kamion> yeah
<BenC> ok, messing with swap on a running system turns out to be a bad idea
<Keybuk> I'm trying to find the resume code
<Keybuk> to see how it puts it back
<Kamion> BenC: how ba?
<Kamion> d
<BenC> Kamion: crash with a fsck bad
<Kamion> yum
<Keybuk> BenC: what did you do?
<Keybuk> Kamion: dunno about you, but I haven't found yet where it restores the original swap header
<mjg59> Kamion: swsusp_check
<mjg59> Oh, sorry, no, that's only in the failure case
<mjg59> No, wait, that's right
<mjg59>                if (!memcmp(SWSUSP_SIG, swsusp_header.sig, 10)) { memcpy(swsusp_header.sig, swsusp_header.orig_sig, 10); /* Reset swap signature now */ error = bio_write_page(0, &swsusp_header);
<mjg59> Grah, irssi hate
<Kamion> unintuitive naming, but right
<mjg59> The original signature is in the swsusp header, so it just copies it back
<Kamion> "Check for swsusp signature in the resume device <small>and munge it</small>"
<Keybuk> this is confusing me ... these two bits of code seem to put the swp_entry_t in different places
<Keybuk> oh, grr, swp_entry_t != swap_header
<Keybuk> right
<Keybuk> so swsusp does blat the header of the swap partition
<Keybuk> GO SWSUSP!
<Kamion> are you sure? it reads the existing contents first
<Keybuk> it does?
<Kamion> I think experimentation might be better than reading the code here
<Keybuk> tbh, I think we just need to test this
<Kamion>                 if ((error = bio_read_page(0, &swsusp_header)))
<Kamion>                         return error;
<Kamion>                 if (!memcmp(SWSUSP_SIG, swsusp_header.sig, 10)) {
<Keybuk> mjg59: care go guinea pig for us?  you're the one man in the universe whose laptop can suspend and resume <g>
<Kamion> can I suspend/resume in vmware, I wonder?
<mjg59> Wait, what's the problem you're working on here?
<BenC> Kamion: that was just "mkswap -L `uuidgen`", which probably isn't what we wan't anyway
<Keybuk> mjg59: finding swap devices by UUID
<Keybuk> in particular, making sure that the UUID in the swap partition isn't destroyed by suspending
<Kamion> BenC: oh you completely rewrote the swap then - that will have zeroed the existing contents and stuff
<Kamion> I was thinking more of just dd'ing in a UUID
<mjg59> Ah, right
<mjg59> Can't right now. Or even this weekend, really...
<Kamion> I'm doing a fresh install in vmware at the moment; if swsusp will work there then I'll try it
<BenC> Kamion: from what I remember, it works
<mjg59> There's no reason for swsusp to blat the uuid, so yeah, fixing it so it doesn't should be fine
<Kamion> mjg59: however, if it does in the current kernel, we're already screwed
<Kamion> since this is for dapper->edgy upgrades
<Kamion> we're pretty much stuck with whatever the dapper kernel does
<fabbione> well you can still mount / by uuid and write these info somewhere on the filesystem (for the swap) perhaps?
<fabbione> something like:
<fabbione> hash the last 4K of the swap
<fabbione> reboot
<fabbione> check for swap partitions
<fabbione> rehash to figure where the partition is gone
<fabbione> take action?
<mjg59> Oh, the risk that they'll upgrade then suspend and lose the uuid?
<fabbione> wouldn't that happen even booting on another linux distro that does mkswap at boot?
<Kamion> fabbione: yeah, sounds possible, but if we can do it all directly on upgrade then that's obviously better
<Kamion> fabbione: do those exist?
<fabbione> Kamion: i don't know.. i haven't used any distro != Debian || Ubuntu for the last 4 years
<mjg59> Sharing swap isn't a supported configuration, is it?
<Kamion> I don't think there's much we can do about that case
<mjg59> Given that we suspend into it
<fabbione> i think we could use partition roundings
<fabbione> there is always some space in between partitions
<Kamion> mjg59: there exist people who don't suspend to disk :-)
<Kamion> for them, it will work apart from this theoretical problem
<fabbione> we might be able to reuse it
<fabbione> like the block immediatly after the end of the swap
<fabbione> i doubt it's the start of the next partition (needs to be checked)
<Kamion> I'm much more comfortable sticking to the UUID if we can
<fabbione> if that space is really empty, we can make use of it
<Kamion> it's simpler and supported by existing tools
<Kamion> and the failure mode with swap is not as bad as the failure mode with other partitions
<mjg59> Kamion: Sure, but it's enabled by default. The supported install configuration is incompatible with shared swap.
<fabbione> Kamion: yes so am I but i am considering alternatives
<Kamion> if it fails, people don't have swap, big deal, they can fix it once they've booted
<Kamion> mjg59: only if you *actually suspend*
<Kamion> which desktop users will to a good first approximation never do
<Kamion> mjg59: yes, I agree that for laptop users it can't be supported
<Kamion> but we've never explicitly advertised it as unsupported either, and for desktop users it will always have worked well
<Keybuk> echo -n "LABEL" | dd conv=trunc of=SWAP obs=1 seek=1052
<Keybuk> for the adventurous :p
<Kamion> label, not uuid?
* Kamion would prefer uuid ...
* fabbione goes to help wife
<Keybuk> uuid is harder to encode for "testing whether one can mangle an active swap partition" purposes
<Keybuk> if you want to write the uuid, just write to 1036 instead
<mjg59> Kamion: I think if there's a feature that's enabled by default that will destroy data in certain configurations, either (a) that feature shouldn't be enabled or (b) that configuration shouldn't be supported
<Kamion> what does "be supported" mean though?
<mjg59> "If you do this and stuff breaks, it's your problem not ours"
<Kamion> in practice, since we've never advertised it as unsupported, it appears to mean "we will feel free to fuck your system without prior warning if you didn't realise you couldn't do that"
<Kamion> which is a bit harsh
<mjg59> Well, in this case the system fucking would be limited to your swap potentially vanishing
<Kamion> right, so it's not too bad - but I'm just very very uncomfortable with dismissing problems as "unsupported" when we never warned people about them
<mjg59> I think when we're faced with a choice of "effectively impossible" or "may irritate someone who ought to be smart enough to fix it", we're effectively obliged to choose the latter and document it
<mjg59> Doing impossible things is outside our remit, no matter how happy it may make users :)
<Kamion> right, just saying that the "and document it" is not optional, and ideally needs to be in-their-face during the upgrade
<Keybuk> uuidgen | perl -ne 's/-//g;print "%c",hex %1 while(/(..)/g)' | dd conv=notrunc of=/dev/hda5 obs=1 seek=1036
<Kamion> s/print/printf
<Keybuk> yes, sorry, mis-typed into IRC
<Kamion> and s/%1/\$1/
<Keybuk> that appears to survive a swapoff/swapon
<Keybuk> and it survives a reboot
<Keybuk> ok, so where we have an active (or inactive) swap partition without a UUID, we can modify it to include one without disturbing the running system
<Keybuk> that check should include an "is a swap partition" check, obviously
<Keybuk> that leaves us with
<Keybuk> - v0 swap partitions  (no UUID)
<Keybuk> - partitions with a resume image
<Keybuk> what do we do about those?
<mjg59> They haven't been supprted since 2.2, have they?
<mjg59> v0 swap partitions, that is
<Keybuk> dunno, the documentation just implies that they were the only version supposrted before 2.2
<Keybuk> right
<Keybuk> they're not supported ;)
<Keybuk> you can't swapon a v0 partition
<Keybuk> ok, so that just leaves us with partitions with a resume image
<Keybuk> (and just thought, how do we find the resume image? :p)
<mjg59> Is there space in the header for a UUID?
<mjg59> Ha. That's a fun one.
<Keybuk> mjg59: which header?
<mjg59> The swsusp header.
<Keybuk> if swsusp includes the original swap header, we could just give resume= the smarts to find that
<mjg59> We need to deal with the situation where resume fails and swsusp doesn't redo the header
<Keybuk> btw, any particular reason resume= is necessary?  couldn't one just iterate /proc/partitions and look for a S1SUSPEND partition?
<mjg59> No, because you might have multiple OSs installed
<Keybuk> does swsusp do that often?
<Keybuk> that'd leave them with dead swap anyway, no?
<mjg59> swap wouldn't necessarily be shared
<mjg59> If you don't mount filesystems between them, that's a prefectly reasonable configuration
<Keybuk> so the choice is what to do when we find them
<mjg59> Check whether they have the correct uuid and resume them?
<Keybuk> right, I mean at upgrade time
<Keybuk> someone upgrades from dapper to edgy, and we find that something listed in /etc/fstab as a swap partition to be mounted on boot is not active and contains a suspend image
<Keybuk> I guess this is easy, we write a UUID into the right bit of the image
<mjg59> They're fucked anyway, presumably?
<Keybuk> and adjust the resume= so whenever that does get resumed, it will work
<mjg59> Or do we support booting edgy with a dapper kernel?
<Keybuk> we don't "support" it
<Keybuk> I don't see any reason it wouldn't boot though
<mjg59> Ok
<Keybuk> dapper->edgy isn't that large a jump
<Keybuk> Kamion: do you concur?
<mjg59> dapper kernel won't write a uuid into the suspended image
<Keybuk> mjg59: ?
<mjg59> I don't quite understand the situation you're suggesting
<mjg59> They're on dapper. They upgrade to edgy. They suspend?
<mjg59> Also, we don't have a resume=
<mjg59> That information lives in the initramfs
<Keybuk> no
<Keybuk> they're on dapper
<Keybuk> they have a swap partition listed in /etc/fstab
<Keybuk> that swap partition is not active, and contains an S1SUSPEND image
<Keybuk> they upgrade to edgy
<Keybuk> during the upgrade, while still in dapper
<mjg59> Whose suspended image is it?
<mjg59> Does it belong to the dapper system?
<Keybuk> can we tell that?
<mjg59> I don't /think/ you can ever get into that situation
<BenC> if it's in /etc/fstab, IMO, it belongs to dapper
<Keybuk> mjg59: failed resume?
<mjg59> If it's a dapper image (a) it should have been mkswapped during resume, and (b) if it's resumed now it'll cause massive filesystem corruption
<BenC> Keybuk: if so, then the failure is too late for recovery
<Keybuk> mjg59: mkswapped during resume?
<mjg59> Keybuk: The failed resume, sorry
<Keybuk> do you mean "mkswap run" or do you mean "the original swap header restored" ?
<mjg59> Though it's possible that that bug never got fixed
<mjg59> Failed resume should result in the suspended image being turned back into swap
<Keybuk> right, but _NOT_ using mkswap, right?
<mjg59> We may use mkswap at the moment
<Keybuk> do you know where I can find that out?
<mjg59> Though I think the kernel actually fixes it
<mjg59> Actually, yes
<mjg59> swsusp_check will rewrite it
<Keybuk> ok, I can't find mkswap anywhere in the initramfs or boot scripts
<mjg59> So original swap header restored, I believe
<Keybuk> ok
<Keybuk> so we found a swap partition in /etc/fstab that contains a resume image
<Keybuk> what we do?
<BenC> mkswap
<mjg59> Yes
<BenC> once they boot ignoring that resume image, the resume image is useless
<mjg59> Allowing that image to be restored would be actively dangerous
<BenC> exactly
<Keybuk> ok, that's fine
<Keybuk> now, we do need to deal with resume=
<mjg59> We don't use resume=
<Keybuk> we don't?  how do we resume from hibernate?
<Keybuk> context change, btw
<Keybuk> we've upgraded the system, it's now running edgy
<Keybuk> they want to suspend and resume
<Keybuk> resume=/dev/hda5 ain't gonna work <g>
<mjg59> We have a RESUME= statement in /etc/initramfs-tools/conf.d/resume
<mjg59> Initramfs generates a major and minor from that and echoes them into /sys/power/resume
<Keybuk> right
<Keybuk> so we need to extend initramfs to support RESUME/resume=UUID=...
<Keybuk> and have it iterate /proc/partitions, look for a hibernate image on a swap partition with the given UUID
<mjg59> Please don't use "rescue=", that's a separate codepath
<Keybuk> eh?
<mjg59> Uh, "resume="
<mjg59> Mentioning it confuses the situation
<Keybuk> resume= looks like the same code path to me
<Keybuk> export resume=${RESUME}
<mjg59> Indirectly
<Keybuk>         resume=*)
<Keybuk>                 resume=${x#resume=}
<Keybuk>                 ;;
<Keybuk> RESUME is otherwise entirely unmentioned in the initramfs code
<mjg59> The traditional semantics for "resume=" is that it's parsed by the kernel
<Keybuk> is it still parsed by the kernel?
<mjg59> In our case, possibly not, but we never write any configuration that uses it
<Keybuk> right
<Keybuk> does RESUME=UUID=... sound insane?
<mjg59> No, that's fine
<mjg59> We change /etc/initramfs-tools/conf.d/resume
<mjg59> Ideally before and after point to the same partition
<mjg59> Then it just needs a small amount of work in initramfs-tools
<Keybuk> "before and after point" ?
<mjg59> The partition pointed at before the rewrite should be the same as the one pointed at afterwards
<Keybuk> right
<BenC> that's ideally what we're shooting for :)
<Keybuk> the difference is before it'd be /dev/?d?? but after would be UUID=...
<mjg59> Yes
<Keybuk> with the advantage that after, it'll work even if the disk jumped from hda5 to sdb5 :p
<BenC> you wouldn't want to just to /dev/disk/by-uuid/* ?
<BenC> less code
<mjg59> Keybuk: Not quite
<Keybuk> BenC: /dev/disk/by-uuid doesn't (yet) know about extracting a UUID from a suspended image
<BenC> actually, no code changes if you do that
<Keybuk> BenC: we use UUID=* elsewhere for consistency
<BenC> Keybul: it's different than a swap image?
<Keybuk> BenC: dunno yet
<Keybuk> still waiting for Kamion to come back from vmware
<mjg59> Keybuk: It won't handle that if the change happens over a suspend/resume cycle
<BenC> ok
<mjg59> But that's a massively pathological case, so
<Keybuk> mjg59: can the change happen over a suspend/resume cycle?
<mjg59> If they move disks around, yes
<mjg59> It'll deal fine with the drivers/ide -> libata conversion
<BenC> if they resumed before upgrade, changes are they did it from a dapper kernel
<Keybuk> uh, doesn't this change mean they *CAN* move disks around between a suspend and resume, and have everything just work?
<BenC> if they suspend again before rebooting to edgy, then that would break
<BenC> I think
<Keybuk> because things are mounted by UUID, the physical location or kernel-assigned name of the disk won't matter
<mjg59> Keybuk: No, because kernel restores with old hardware knowledge
<BenC> is there any way we can disable suspend functionality until they reboot after this change?
<mjg59> So you'll resume, and the kernel will think "/ is on the first disk connected to this controller" when in fact it's now on the second
<Keybuk> mjg59: have you had any cases of that so far?
<mjg59> Keybuk: Right now it won't even attempt to resume. With this change it'll attempt to resume and then blow up
<Keybuk> depends how much they changed
<Keybuk> tbh, I suspect this is a "WELL DON'T DO THAT THEN!"
<mjg59> You can't change hardware config and expect a resume to work
<mjg59> (sadly)
<Keybuk> though people could get heavily bitten if the resume boot is subtly different to the suspend boot
<Keybuk> ie. your raid controller takes an extra second to start up
<mjg59> There's a standard for a BIOS flag that gets set if the BIOS detects a changed config
<mjg59> We should probably check that
<Keybuk> so your scsi controller wins
<mjg59> Oh, that's fine
<Keybuk> but I suspect that's fine, actually
<Keybuk> because your "first disk in this controller" info is still valid
<mjg59> As long as the hardware is the same, enumeration order is unimportant
<Keybuk> right
<Keybuk> this is, in fact, only if you add new duplicate controllers of a given type
<mjg59> The entire running kernel state gets overwritten by the old one
<Keybuk> or swap the drives around on a particular controller
<mjg59> Or move PCI slots
<Keybuk> I guess
<Keybuk> but that's stupid
<mjg59> If the device ID changes, things explode
<Keybuk> I'm trying to make sure that sunspots can't break it
<mjg59> But PCI device enumeration isn't dependent on startup speed - disk enumeration order may be
<Keybuk> ie. udev loading modules in a different order
<BenC> I think changing hardware configuration in the middle of an upgrade should just be strictly forbidden :)
<mjg59> Keybuk: Anyway, I need to pack
<Keybuk> pack?
<Keybuk> for?
<mjg59> Keybuk: Are you coming up this evening, or will I see you tomorrow?
<Keybuk> I may be up this evening
<Keybuk> depends when David turns up
<mjg59> Ok
<mjg59> We're leaving in about an hour
<Keybuk> cool
<Keybuk> BenC: does vmware work on an amd64?
<BenC> does on mine
<Keybuk> ok, let me install it for testing too
<Keybuk> about time I did
<Keybuk> I'm bored of screwing up chroots <g>
<kylem> BenC, http://www.kernel.org/git/?p=linux/kernel/git/kyle/ubuntu-hppa.git;a=summary <- please look to make sure i cleaned up tulip properly. 
<BenC> kylem: ok
<Keybuk> BenC: right, if I modify vol_id as necessary to support extracting the UUID out of a swap partition containing a S1SUSPEND image ...
<BenC> kylem: btw, I think I narrowed a500 boot failure down to something with CONFIG_GSC being enabled
<Keybuk> (this is a patch upstream will accept with a "sick... but YES!")
<Keybuk> then we can treat UUID=* as an alias for /dev/disk/by-uuid/*
<Keybuk> and could do RESUME=LABEL=SWAP with the same code <g>
<kylem> BenC, ooh. neat.
<kylem> BenC, i'll be able to work sunday, still at OLS this week.
<kylem> sounds like it could be that CONFIG_GSC is trying to register a console first.
<BenC> which console should a500 be using, PDC, right?
<BenC> with GSC, it was using SERIAL_MUX or something like that
<Keybuk> ouch
<Keybuk> LILO!
* #ubuntu-kernel  [freenode-info]  why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup
* Keybuk wonders whether swapon -a can understand UUID= and LABEL=
<Keybuk> yes, it can
<Keybuk> I'm still unsure where the hell this migration code should go
<Keybuk> it may be true that udev is the right place for it :-/
<Keybuk> we almost need a sane-linux-system package
<Keybuk> that the kernel depends on
* #ubuntu-kernel  [freenode-info]  if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
<BenC> linux-image-kdump_2.6.17-5.15_amd64.deb
<BenC> yummy
<zul> sweet
* Starting logfile irclogs/ubuntu-kernel.log
<zul> BenC: thanks for the kernel-package upload
<BenC> np
<zul> now i can finish my rewrite
<Kamion> Keybuk: right, sorry, I was away for a while
<Kamion> I concur with the above plan, I think, as long as tests work
<Kamion> Keybuk: I have the partman-target change (it's tiny), but am holding off on it a while until I have new d-i with the fixed busybox mkswap
<Kamion> I'm writing out just "# /dev/hda1" or whatever above each UUID= line
<Keybuk> http://people.ubuntu.com/~scott/convert.txt
<Keybuk> Kamion: ^ could you take a read through that and check I'm not insane
<BenC> Keybuk: you don't want to make /dev/* be /dev/[hs] d[a-z] *?
<Kamion> Keybuk: will have to be tomorrow I think, sorry
<BenC> Keybul: there are some off block storage devices majors that might match, and you probably don't want to mess with them
<Kamion> there's stuff like /dev/scd0 which is shoved in by default
<Kamion> if you have a scsi cdrom during installation
<Kamion> anyway, guests, gone
<BenC> probably just /dev/[hs] d* would be good
<BenC> there's one other issue I'm not sure if it was covered
<BenC> the issue of a whole block device being used as a partition
<BenC> does by-uuid stuff actually list those?
<fabbione> Keybuk: i think you want to be careful about ocfs2|gfs|gfs2
<fabbione> it is a common misconception that they are network fs
<fabbione> they are indeed local fs
<fabbione> but they require net to do cluster operations
<fabbione> uhe
<fabbione> ops
<fabbione> skip "uhe"
<fabbione> :)
<fabbione> i have stuff like /dev/sdXY mounted as ocfs2/gfs2/gfs
<fabbione> or hda for the matter
<Keybuk> BenC: should do
<Keybuk> fabbione: we can work those out as we go ... safer not to migrate than migrate incorrectly
<fabbione> Keybuk: yes agreed. *IF* i am no father by monday we can try them together and see what's needed
<BenC> Keybuk: would something like "/dev/* matches, and vol_id says it has a UUID, then convert" be safe?
<Keybuk> BenC: that's what that script does, no?
<Keybuk> I figured that if vol_id thinks it has a uuid, it means we can mount using UUID=, so it's not going to break anything by converting it
<BenC> Keybuk: I meant without all the catches for fstypes and such
<Keybuk> BenC: possibly ... I didn't want to accidentally find the UUID of a CD in the drive, and hard-code that ;)
<Keybuk> all the tmpfs/network fs stuff is probably not necessary
<BenC> cd's are noauto, right?
<BenC> and so are fd's?
<Keybuk> actually ... let's change that -e to a -b
<Keybuk> and then just check for auto/noauto
<BenC> one last build/boot test, and the kernel is getting uploaded
<Keybuk> http://people.ubuntu.com/~scott/convert.txt
<Keybuk> ^ ok, so that doesn't check filesystem types
<Keybuk> instead it's converted if it's a _block device_ in /dev, it's not auto fstype or noauto options, and it has a uuid (or we can generate one)
<BenC> sweet
<BenC> there's one other issue....some people have already been bitten by hd->sd problems with AHCI drivers...
<BenC> if rootfs conversion fails, can it be cross-referenced with /proc/mounts and updated?
<Keybuk> how do you mean?
<BenC> the ahci drivers have caused some ppl to already get sdX instead of the hdX listed in /etc/fstab grub
<BenC> so if you check fstab and find /dev/hda1, and it doesn't exist (or worse, is pointing to something else like a CD on another IDE controller), then this gets messed up
<BenC> so far it's only causing a few ppl to get long boot times waiting for the rootfs
<BenC> and it's not something I can revert because then other people cannot boot at all (driver fails to attach to IDE controller)
<BenC> this is the whole ata_ahci and ide ahci driver problem
<Keybuk> if someone is messed up by this now, they can't be automatically converted
<Keybuk> because by definition, we don't know how their filesystems used to be arranged
<Keybuk> if /proc/mounts is right, it means the user has already gone through and fixed their fstab :p
<BenC> not true
<Keybuk> why not true?
<BenC> initramfs will find their /dev/sda1 and mount it as the rootfs
<Keybuk> no it won't
<BenC> even though /etc/fstab says /dev/hda1
<Keybuk> initramfs will be looking for their /dev/hda1
<Keybuk> so they'll get a PANIC
<BenC> from what I understand it will eventually mount the /dev/sda1
<Keybuk> it will eventually mount UUID=... after the conversion
<BenC> but there wont be a UUID= if fstab says /dev/hda1 when one doesn't exist
<Keybuk> if somebody in dapper is using an ahci, and runs this conversion during the upgrade to edgy, and then reboots ... all will be fine
<BenC> dapper is the problem though
<Keybuk> if dapper has /dev/sdX instead of /dev/hdX, their machine won't boot
<Keybuk> not without them manually changing their grub options and fstab to /dev/sdX
<Keybuk> initramfs doesn't magically try /dev/sda1 if /dev/hda1 doesn't work
<BenC> maybe I'm misunderstanding the problem I saw then
<BenC> could be the user eventually updated the needed files
<Keybuk> yeah
<Keybuk> I suspect you have a user failing to mention they already changed stuff in the bug report <g>
<Keybuk> we have a few situations in dapper where we would have liked to have had mount-by-uuid
<kylem> BenC, i think you found the bug.
<makx> Keybuk: your convert script doesn't take care of /dev/cciss and /dev/ida
<Keybuk> makx: that's deliberate ... do you know whether either of those have UUIDs? :)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-5.15 uploaded, Welcome our new kexec/kdump overlords | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
#ubuntu-kernel 2006-07-22
<zul> BenC, awake?
<ajmitch> hi zul 
<zul> hey ajmitch 
<BenC> zul: yeah
<zul> BenC: in my debian/build directory everytime i run make-kpkg build kernel-package wants to run minimal target, and i dont know why that is
<zul> i have the changelog control copyright and offical but it seems to be ignoring them
<zul> BenC: http://paste.ubuntu-nl.org/18565
<BenC> minimal target?
<zul> yeah
<zul> is there a way to override it?
<BenC> no idea
<BenC> did you copy linux-source-2.6.17 build?
<BenC> from what I can tell you should be able to copy that and ditch d-i stuff, and just have debian/config/{amd64,i386}/config{,.xen{u,0}}
<zul> i have like config.686 the like
<zul> i think i might have got it
<zul> xen is a subarch of x86 now
<zul> so the archmap is incorrect..so im just going to fiddle around with this a bit more
<BenC> update to latest debian/* stuff from linux-source
<BenC> I redid a lot of shit to accomodate the new kernel-package
<zul> like what?
<BenC> like the debian/config/archmap stuff
<BenC> and how it's used in the debian/rules file and in post-install
<zul> ah
<zul> well ill have at it first thing in the morning im going to bed...thanks for the help
<BenC> np, good night
<zul> good luck in the tournament if i dont talk to you
<BenC> thanks
<Tonio_> hi everyone
<Tonio_> I'm having a weird issue building kdebase today 
<Tonio_> here it is : /usr/include/linux/joystick.h:131: error: '__s64' does not name a type
<Tonio_> the same package did fail 2 days ago since riddell did his last upload on 07/20...
<Tonio_> ajmitch: okay let's report a launchpad bug since nobody will read this :)
<BenC> bah, stupid kdebase bug is not a bug in linux-kernel-headers
<jwest-> hi
<jwest-> ok hi again after a few hrs
<jwest-> :D
#ubuntu-kernel 2006-07-23
<johanbr> Do you guys know that the current Edgy toolchain doesn't build kernels from kernel.org?
<johanbr> Hi. Do you know that the Edgy toolchain currently does not build kernel.org kernels?
<zul> as in how?
<johanbr> The linking stage fails.
<zul> do you have an output?
<johanbr> This thread explains it: http://blog.gmane.org/gmane.linux.kernel/day=20060702 . Apparently it has something to do with the stack smashing protection.
<zul> oh yeah...just had -fno-stack-protector to your cflags
<johanbr> I haven't tried very much, but I did have that in my cflags, which is consistent with what the thread says. Apparently Kbuild needs patching.
<zul> well once launchpad is back please open a bug with full details
<johanbr> Alright, will do.
#ubuntu-kernel 2007-07-16
<login_> hello
<login_> I have been compiling kernel 2.6.22 and have run across a dilemna. My compiled kernel weighs in at about 400-500 mb while the ubuntu kernel weighs about 100-200 mb. How did you guys get the kernel to be so thin?While i was uncompressing the kernel i saw it uncompress folders such as sparc so is it possible that my kernel installed all architectures? if so , how can i make it only use 1386?
<mjg59> Disable CONFIG_KALLSYMS_ALL
<login_> thank you! i will try that when i recompile
<login_> how do i disable it? do i edit something in the menuconfig?
<mjg59> Yes
<login_> thank you. the name will be exactly like that right?
<login_> i am compiling right now but i cant find CONFIG_KALLSYMS_ALL in make xconfig window
<mjg59> It's under debug options
<login_> hmh i cant seem to find debug options. i feel very noobish to ask but could you give me a type of written map to where to find this option? like go togeneral setup and etc
<login_> or is there a way to do this i nthe command line
<login_> where i do disable CONFIG_KALLSYMS_ALL
<login_> ?
<yulin> Is there some good solution for promote the kernel compatibility about harddisk controller?
<mikmorg> Could someone assist me as to where the debian post/pre inst/rm scripts can be found for linux-image, linux-headers, and linux-source? I figured they would be somewhere in git://kernel.ubuntu.com/ubuntu/ubuntu-feisty.git, but I can't find them.
<crimsun> that's because make-kpkg (in the kernel-package binary package) handles it.
<mikmorg> crimsun: Do you know where I should send a patch to those files?
<mikmorg> crimsun: There is a problem with the kernel-img.conf parsing that needs to get fixed ASAP, hopefully before 16-30 comes out
<crimsun> mikmorg: file a bug against the kernel-package source package, and attach the diff(s).
<mikmorg> crimsun: I filed the patches against the files in /var/lib/dpkg/info/linux-*. I will change the target from linux-source to kernel-package. Thanks.
<kraut> moin
<zul> hey
<zul> BenC: ping
<zul> if your ae up
<BenC> zul: hey
<BenC> zul: Can you clean up your tree to remove the commit/revert?
<zul> sure
<BenC> should be able to branch from ubuntu-gutsy, and cherry pick the changes you want to keep
<BenC> zul: thanks...so what did you need?
<zul> that :)
<BenC> heh
<zul> ill clean it up tonight and request another pull
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-8.18 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/
<aquo> hey folks
<aquo> i have some question
<aquo> what is the status on https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214
<aquo> aquo@cayley:/etc$ iwconfig --version
<aquo> iwconfig  Wireless-Tools version 28
<aquo>           Compatible with Wireless Extension v11 to v20.
<aquo> Kernel    Currently compiled with Wireless Extension v21.
<aquo> who is the person responsible for this?
<zul> BenC: can you add to the kernel gitguide on the wiki on how to use cherrypick?
<BenC> zul: git-cherrypick <sha>
<zul> ah ok
<zul> hey pkl
<pkl__> hi zul
<aquo> BenC: can you tell me who is responsible for bug what is the status on https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214
<BenC> aquo: how about giving me a quick overview so I don't have to read the entire report, please?
<aquo> kernel is compiled with wrong Wireless Extension
<BenC> kernel is compiled with stock 2.6.22 wireless extensions
<BenC> it's the only way it can be compiled
<aquo> aquo@cayley:/etc$ iwconfig --version
<aquo> iwconfig  Wireless-Tools version 28
<aquo>           Compatible with Wireless Extension v11 to v20.
<aquo> Kernel    Currently compiled with Wireless Extension v21.
<aquo> ath0      Recommend Wireless Extension v13 or later,
<aquo>           Currently compiled with Wireless Extension v21.
<BenC> I don't see the problem there
<BenC> v20 wireless-tools works fine with v21 kernel extensions
<aquo> no, not everytime.
<BenC> then wireless-tools needs updating
<aquo> it is not possible to connect to hidden networks
<BenC> it's not like I can tell the kernel to be v20
<BenC> how can you be sure that v21 kernel extensions is what is causing that?
<BenC> these extensions are meant to be compatible in cases like this
<aquo> should be possible, the bug report states that people solved the problem by recompiling the kernel
<BenC> v20 wireless-tools just wont use the v21 extensions
<BenC> recompiling it how?
<aquo> not sure, changing the version of Wireless Extension v21
<BenC> I heard about this whole thing last week, and I'm just not convinced that v21/v20 compatibility is the problem
<BenC> aquo: if you just change a line in the kernel to say it's v20, then you are actually breaking things
<rtg> I think its more a problem with hidden SSID, not  WEXT versions.
<rtg> There is alot of FUD in that report.
<BenC> yeah, the version information is a red herring, IMO
<aquo> i don't think so, i would be interesting to see if it worked with the original kernel on the media ...
<aquo> 20-15
<BenC> aquo: you can't compare 2.6.20 vs. 2.6.22 just based on v20/v21 kernel extensions
<rtg> Yeah, there is too much change in the wireless subsystem.
<aquo> i am just comparing 20-15 and 20-16
<BenC> the bug could very well be somewhere else, or it could be in wireless-tools, and the fact that it breaks because it assuming something it shouldn't
<aquo> i am still on feisty
<rtg> aquo: Can you confirm it works if you enable broadcast SSID?
<BenC> aquo: ok, then I'm getting ever more conflicting info on this bug report
<aquo> yes, with broadcast it is working.
<rtg> aquo: I think that implies the WEXT versions are fine. There might be something between wpa_supplicant and network manager. 
<aquo> hoe, i think it is a major problem if i am not able to connect to hidden networks
<BenC> aquo: I read a little more of the report, and it seems that the wireless-tools maintainer is agreeing with your assumption that v20 tools is breaking with v21 extensions
<BenC> aquo: IMO, that clearly says that wireless-tools for v20 extensions is broken
<aquo> "Hi Julie, upgrading only wireless tools won't make difference, because the kernel is recompiled with Wireless Extension version that is not supported by Wireless Tools. This is a simple mismatch and the kernel team can easily solve this by recompiling the kernel. I already did that on my system and it works."
<BenC> aquo: I'd really like someone to tell me how to recompile the kernel with an older wext
<BenC> that bit of info seems to be clearly absent from the report
<aquo> don't know, but i will investigate.
<BenC> it's not like it's a switch, or a config options...it's basically backing down the entire tree, subsystem and drivers, to older code
<BenC> which we wont do
<aquo> but first i want to check the situation on the original release media ...
<BenC> so if newer wext tools fixes things, best bet is to find the patch that fixes this case
<aquo> want to check if normal feisty has matching versions
<BenC> we wont be making sweeping "downgrade wext" or "upgrade wireless-tools" changes in feisty, period
<BenC> aquo: I'd also appreciate if you could update this bug report with what we discussed, to keep everyone informed of the status
<aquo> ok
<BenC> aquo: thanks
<movi> i think i found a bug in the newest kernel in gutsy (and -7 too)
<movi> the thing is, im using a Celeron 2.6
<movi> and ksoftirqd/0 is using about 25-30% of the cpu all the time
<movi> someone pointed me to look and /proc/interrupts
<movi> and the thing is, timer only generates 62 interrupts, then stops
<movi> i tried booting with noapic and lapic
<movi> n
<movi> noapic and nolapic
<movi> and then the timer does generate interrupts, but the process eats up 35% of the cpu all the time
<movi> 2.6.20 (on 7.04) works perfectly
<kylem> while the timer "doesn't" generate interrupts, is "LOC" increasing?
<movi> yes
<movi> and lots it too
<kylem> then it's fine.
<kylem> LOC is the local APIC timer
<movi> why the cpu usage then ?
<movi> i tried disabling the usb controller and unloading the nvidia module - nothing
<login_> Hi guys. I recompiled kernel 2.6.22 on my ubuntu box and comparing to ubuntu's kernel , it is ismply 5 times larger! my deb file is 194 mb and when i isntall it , it is 500 mb. From synaptic , i see that the ubuntu kernel is about 75 mb . how can i make my 2.6.22 compiled kernel thinner?
<movi> i
<movi> i booted in single mode too to rule-out any rigue processes - nothing
<kylem> meh. i wouldn't worry about it.
<pmjdebruijn> login_, how did you 'compile it'
<pmjdebruijn> login_, anyway do you _need_ 2.6.22?
<login_> someone suggested do disable CONFIG_KALLSYMS_ALL ya , i am trying to make an ubuntu remaster
<login_> i compiled it by making it into  a deb package
<login_> from this tutorial
<login_> http://www.howtoforge.com/kernel_compilation_ubuntu
<movi> login_: is this addressed to me ?
<login_> to everyone that can help me
<login_> u asked me how to ocmpile it so ya
<login_> i made the kernel into  a eb package and the linux-image was 194 mb
<pmjdebruijn> login_, that's the quick 'n dirty way to do it
<movi> i didnt ;] 
<login_> o didnt see it :P
<pmjdebruijn> anyway it's weird that you get such large packages
<login_> could yo utell me wich is the long and not dirty way to do it?
<pmjdebruijn> it's on the wiki somewhere
* pmjdebruijn doesn't know exactly where
<login_> the ubuntu wiki?
<pmjdebruijn> yeag
<pmjdebruijn> yeah
<login_> ok i will search for it
<login_> man this is the largest ammount of people i have seen talking in this chat
<login_> i am amazed
<movi> so anyone know what should i do about my ksoftirqd problem ?
<movi> (except going back to 2.6.20 and ubuntu 7.04) ?
<aquo> BenC: https://bugs.launchpad.net/baltix/+source/knetworkmanager/+bug/50214/comments/38
<login_> is the kernel tutorial this one?https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28kernel%29. I am concerned that it told me to download the kernel source from the repos so it will be 2.6.20 rather then 2.6.22. Is it possible for me to replace that with the kernel 2.6.22 source . will it make a difference?
<login_> aww you guys dissapeared again :(
<login_> ill be waiting for you guys to reply :P
<login_> ?
<zul> BenC: I cleaned it up
<login_> anyoe have an anwser for my second question?
<login_> aynone?
<login_> have an anwser to my question
<login_> Could you guys tel lme what you did with kernel 2.6.22 to make it so light? my kernel com[pile comes to 193 mb
<login_> !
<infinity> login_: You've been asking this all day; this isn't a support channel.
<login_> i know but no one has really and trly anwsered. I am sorry if i am being a bother but i dont know where to go since in the ubuntu forums if you ask anyhting and it is hard it gets ignored
<BenC> login_: find /lib/modules/ -name \*.ko | xargs strip
<login_> i type that when i am compiling?
<login_> or do i isntall it and delete every .ko file that has xargs strip in it?
<login_> plz anwser this will be my last question :'(
<bdmurray> login_: you might find 'man strip' and 'man xargs' helpful
<login_> ok
<login_> i still dont get it .:(. O well. Does the gutsy kernel have any stamps on it saying it is an ubuntu kernel?
<mjg59> login_: The Ubuntu kernel build process strips the modules before putting them in a package. If you do it by hand (without using the full kernel build process) you need to do that yourself.
<login_> o so i run  find /lib/modules/ -name \*.ko | xargs strip while compiling
<mjg59> No, when installed
<mjg59> And I suspect you don't want to run strip without any arguments - that'll remove symbols needed for loading the modules
<mjg59> But this really isn't the place to ask
<mjg59> If you want to avoid it altogether, just disable CONFIG_KALLSYMS_ALL
<login_> i disabled that but it only went down a couple of kb
<login_> also , whe ni run the command it says this strip: Warning: '/lib/modules/2.6.22-custom/kernel/net/wanrouter' is not an ordinary file
<login_> Again i am really sorry for asking noob questions here
<mjg59> login_: Then don't?
<login_> ok :( . bye
<lamont> amitk said he was going to include jbailey's patch in -8.17, and yet it's still not in -8.18.... hrmpf
<lamont> BenC: what do I need to do to get that hppa patch in before tribe3 freeze?
<BenC> lamont: it will get in, we just didn't have the time to do it last week
<BenC> parts of the patch were actually wrong, but we'll get it munged up properly
<lamont> on the off chance that there are other issues, and because I still need to build debian-installer et al, it'd be nice if it hit the archive sooner rather than later....
<lamont> thanks
* lamont points BenC at the other window when he gets a chance
<bdmurray> I've started tagging bugs as kernel-oops BenC.  There are a few now.
<kylem> do we have real tags yet?
<kylem> or can people still tag anything however they want?
<bdmurray> We have standardised tags but people can still add whatever they want.
<bdmurray> The list of tags is at https://wiki.ubuntu.com/BugSquad/Tags
<lamont> BenC: I have  the various patches in my tree now, I'll send email to kernel-team tonight.  must run now.
<lamont> and I'll do a test build, too.
* lamont runs
#ubuntu-kernel 2007-07-17
<TheMuso> c
<TheMuso> ugh
* Starting logfile irclogs/ubuntu-kernel.log
<amitk_> lamont: ping
<amitk_> lamont: did 2.6.22-8 fix bug 123178 for you?
<kraut> moin
<Jaghound> latest gutsy (after apt dist-upgrade this morning) seems to have initramfs breakage
<Nafallo> Jaghound: what has that to do with the kernel then? :-)
<Jaghound> I got dropped to initramfs busybox, because directory /dev/disk/by-uuid does not exists
<Nafallo> Jaghound: -> #ubuntu-devel
<Jaghound> Nafallo: #kubuntu-devel people told me to come here :-)
<Jaghound> this is like a service desk, everybody trnasfers :-)
<Nafallo> hehe
<Jaghound> transfers 
<Jaghound> ok, I try the plain ubuntu folks then
<Nafallo> sounds like udev anyway, and that's not kernel.
<Jaghound> sure
<BenC> pkl__: 124194 is fix released as of the last kernel upload
<BenC> pkl__: it's actually a dupe of another bug, but I'd just mark it fix-released and move on
<BenC> doko: ping, re: bug 74691
<amitk_> benc: any plans to apply patch for custom DSDTs to gutsy?
<doko> BenC: no idea at first sight
<BenC> doko: I remember this in feisty, but it was fixed in the kernel...perhaps there's something that needs to be done in bfd to read the newer files right?
<zul> hello
<amitk_> benc: feel like applying the patch in bug 54621?
<BenC> amitk_: for some reason, I thought the patch was there, but if not we can definitely get an updated one in that applies for 2.6.22
<amitk_> benc: I will work on it
<doko> BenC: I'll look at upstream gdb sources, but probably at the end of the week; subscribed to the report
<BenC> doko: can I assign it to you in the meantime as well?
<doko> BenC: well, if you like ...
<BenC> doko: helps me to remember what's going on with it :)
<BenC> doko: thanks
<doko> hrm, gdb-6.7 didn't branch yet ...
<amitk_> benc: want a patch for 54621 on kernel-team?
<BenC> amitk_: I think 54621 looks good
<BenC> I'm doing an initramfs-tools upload real quick
<amitk_> benc: I meant - Do you want a patch or should I upload?
<zul> oh yeah can you pull in my crack as well
<BenC> amitk_: patch and push :)
<BenC> zul: is your crack cleaned up? :)
<zul> it is
<zul> no reverts no nothing..
<BenC> zul: Ok, can you resend the pull request and we'll get it in?
<zul> sure..
<zul> do i have to pull in the latest updates?
<BenC> amitk_: if you update status of bug to something other than confirmed (e.g. fix-committed or fix-released), please give it an importance level and assign to self
<amitk_> benc: ok
<BenC> amitk_: and for the ppl sub'd, it's usually a good idea to tack a little note saying "applied, will be in next kernel upload"
<BenC> amitk_: thanks
<zul> BenC: done
<amitk_> benc: I can't assign importance
<BenC> amitk_: hmm, that's not good
<amitk_> i was told only QA could do that?
<BenC> amitk_: we're going to get you added to QA :)
<BenC> the whole canonica-kernel-team should be distro-qa
<BenC> or ubuntu-qa I mean
<lamont> amitk_: 2.6.22-8.18 still has the issues.  My git repo on kernel.u.c has all the fixes that I need.
<lamont> you want a git-format-patch of them?
<amitk_> lamont: could you check out latest git tree and make sure everything needed is in there? If not, then please provide a tree to pull from or format-patch
<lamont> ok
<amitk_> I had to break up the patch because parts were already applied
<lamont> amitk_: and this was -8.18?
<BenC> amitk_, pkl__: Ok, no kernel upload today, so let's work toward the upload for post-tribe-3
<BenC> seems like we have some momentum, so no need to waste it :)
<amitk_> ok
<amitk_> lamont: no.. get the HEAD
<lamont> git fetch origin HEAD?
<amitk_> 'git pull' should do it if you had already rebased to -8.18
* lamont has been told to never do git pull, since it almost never does the right merge.
<lamont> git diff origin shows no differences between my tree and ubuntu-gutsy, so I'll give it a roll.
<lamont> BenC: assuming this builds, any chance of changing your mind about an upload today?
<amitk_> lamont: if you haven't rebased to the last kernel, git pull might very well fail
<amitk_> https://wiki.ubuntu.com/KernelGitGuide
<lamont> just did a 'git fetch origin; git rebase origin', all seems to be current there
<lamont> <keithp> Never use git pull.  use git fetch and an appropriate git merge command instead
<lamont> (actually, he asserts that git-pull will either go away or change semantics in 1.6)
<amitk_> everybody should be permitted their own threshold of laziness =)
* lamont pulls a fresh clone of ubuntu-gutsy just to be 100% sure which kernel he's talking about :-)
<lamont> amitk_: btw, looks like we split the patches the same way, since the rebase had no conflicts. :-)
<lamont> I do _love_ git.
<lamont> just wish I understood it better.
<lamont> otoh, a git-repack in ubuntu-gutsy from time to time would be nice.
<abogani_> BenC: I received an error from "fakeroot debian/rules custom-binary-rt" ...
<abogani_> /home/alessio/ubuntu-rt/ubuntu-gutsy/debian/build/custom-source-rt is not clean, please run 'make mrproper'
<abogani_> To my eyes this dir is ok... :-(
* lamont bbiab
<lamont> amitk_: missing one or two things... I'll make a tree for you
<amitk_> lamont: great
<lamont> looks like just one debian/control* change
<lamont> of course, trashing my git tree didn't help. :-(
<lamont> is building the kernel source just a matter of debian/rules insertchanges; dpkg-buildpackage -rfakeroot -S  ?
<amitk_> lamont: only the control.stub.in should be required, right? Everything else is autogenerated?
<lamont> ah, ok.
<lamont> if it's autogenerated, why is it committed instead of in .gitignore?
* lamont is just curious, mind you
<amitk_> good question. Perhaps nobody put it there? BenC?
* amitk_ is still learning the dark art of debian
* amitk_ is done for the day
<lamont> amitk_: so am I right on how to build the source package?
<BenC> lamont: no need to insert changes
<lamont> BenC: well, I was figuring on building -8.18hppa1 :-)
<lamont> so a good changelog never hurts.. :)
<BenC> lamont: we don't gitignore debian/changelog because we like to keep it in the tree...just insertchanges is what we do just before upload
<lamont> control and control.stub were the question
<lamont> that is, since control{,.stub} are generated from control.stub.in, shouldn't they be ignored?
<BenC> lamont: fakeroot debian/rules clean will generate those
<BenC> lamont: eh, hard for them not to exist at all in most cases
<BenC> so would have to answer lots of questions from git users
<lamont> right
<lamont> I guess that works
<lamont> BenC: any chance of getting you to ln ubuntu-gutsy.git to .git somewhere and saying 'git repack'?
<lamont> that would greatly speed up cloning head, I expect
<kylem> next person to screw up permissions on zinc is going to get a stab to the face.
<BenC> lamont: how are you cloning?
<lamont> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-gutsy.git ubuntu-gutsy
<BenC> git:// or ssh method should not be retrieving anything that isn't referenced anyway
<lamont> remote: Generating pack...
<lamont> remote: Done counting 507072 objects.
<lamont> remote: Deltifying 507072 objects.
<lamont> remote:  100% (507072/507072) done
<lamont> Indexing 507072 objects...
<lamont> remote: Total 507072, written 507072 (delta 399909), reused 492712 (delta 385643)
<lamont>  100% (507072/507072) done
<lamont> Resolving 399909 deltas...
<lamont>  100% (399909/399909) done
<lamont> Checking 22582 files out...
<lamont>  100% (22582/22582) done
<lamont> so it'll still take that small eternity of processing?
<lamont> admittedly, that's not precisely from ubuntu-gutsy..
<lamont> which was also slow
<BenC> lamont: repacked
<BenC> guess I should prune as well
<lamont> git fetch origin
<lamont> ...
<lamont> * refs/heads/origin: does not fast forward to branch 'master' of /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-gutsy;
<lamont> so how do I overcome that?
<BenC> lamont: there's info on KernelMaintenance wiki
* lamont slaps head on desk
<BenC> lamont: long document, basically you want to look for git-rebase information
<mkrufky> hi guys
<mkrufky> id like to know what *I* can do, in order to make it easy for you to take care of the missing firmware issues .... applies to feisty and gutsy, launchpad bugs #90723 and #99107
<mkrufky> 90723 deals with dvb-usb-bluebird-01.fw , which I released, and I am the author of the kernel module
<mkrufky> 99107 deals with the new, official cx2341x firmware, as released officially by Hauppauge Computer Works ...  Ubuntu is shipping the old, broken firmware, and the new kernel drivers were altered to no longer accept the old, buggy firmware that ubuntu ships... (ivtv, cx88-blackbird, and pvrusb2)
<BenC> mkrufky: for feisty, nominate the bugs for feisty, and we'll try to follow up, for gutsy, best bet is to apply to me via email for access to kernel.ubuntu.com so you can put changed into a clone of ubuntu-gutsy-lum that we can pull from
<mkrufky> these are kernel bugs that i originally filed against the 2.6.20 kernel for feisty, although they also apply to edgy and dapper... (only 90723 applies to dapper) ... these will also affect gutsy
<BenC> mkrufky: requesting an account requires login name and ssh pub key
<mkrufky> the bugs were originally filed against feisty, 2.6.20 ... somebody reclassed them to linux-source-2.6.22
<mkrufky> hmm, ok.. .i can do that
<BenC> do a "Also affects..." and add linux-source-2.6.20 back
<mkrufky> will do right now
<BenC> I can't guarantee they will make it in feisty (I know they wont for edgy)
<BenC> but we definitely want it done for gutsy
<BenC> for gutsy, aim it at linux-ubuntu-modules-2.6.22
<BenC> not linux-source-2.6.22
<mkrufky> ah.... thats the problem
<mkrufky> the linux-source should all be changed to linux-ubuntu-modules-  :-/
<mkrufky> ok, email sent to you, BenC
<BenC> mkrufky: will probably take a day or two to finish (I have to forward to admins)
<mkrufky> no rush ... thanks
<mkrufky> gosh.. .as i keep surfing the open bugs list, i keep running into more and more bugs that i've already dealt with upstream
<mkrufky> launchpad is more fun than bugzilla :-P
<lamont> amitk_: test build running of lamont/hppa-ia64.git, will advise
* Starting logfile irclogs/ubuntu-kernel.log
#ubuntu-kernel 2007-07-18
* lamont wonders what TZ is normal hours for amitk
* lamont grumbles and builds abi files for hppa.
* Starting logfile irclogs/ubuntu-kernel.log
(lamont/#ubuntu-kernel) hrm... maybe abi-check could be taught to look at the output of apt-cache show, and if there's no package of the  current abi number in the cache, then auto-ignore...
<manchicken> Does anybody know if Intel 3945 is OOTB supported?
<lamont> BenC: should the opportunity present itself, git://kernel.ubuntu.com/lamont/hppa-ia64.git (master) has everything that hppa needs, other than abi files (the right .ignore, or an abi bump, and there should be love).  The patches are all parisc specific.
<crimsun> manchicken: it is.
<manchicken> crimsun: Groovy.  I'm looking to find a nice OEM machine, and I'm really having a hard time deciding on a dell or a system76.  It'd be nice if there were more options...
<manchicken> I may just end up buying a compatible lappy and testing an ISO on it :)
* lamont prepares mail to kernel-team
<manchicken> crimsun: So those don't require anything fancy?  They're just free software drivers with binary firmware?
<crimsun> manchicken: I don't know offhand if you need to run Restricted Manager, but it is supported.
<manchicken> Do you know if that's on the Kubuntu ISO?
<manchicken> (Gosh, I should probably know this)
<JanC> Intel 3945 needs restricted-manager on 7.04
<JanC> and that's not in Kubuntu, but I guess installing the -restricted-modules package is enough
<JanC> (it was enough in 6.10)
<JanC> so, check whether that package is on the kubuntu iso  :)
<JanC> (I hope gutsy will have the new driver without that binary daemon)
<kraut> moin
<dholbach> hiya, can somebody of the kernel team take a look at bug 114793?
<dholbach> https://bugs.launchpad.net/ubuntu/+source/linux-wlan-ng/+bug/114793
<dholbach> same for bug 124855 - https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/124855
<fabbione> dholbach: checking the second one
<fabbione> oh feh...
<fabbione> there have been more changes since that merge
<fabbione> using LP for merges is not a good idea IMHO
<dholbach> well - we need to send people looking for sponsors somewhere
<fabbione> the debdiff looks sane to me
<fabbione> and it seems to be against the very latest initramfs in the archive
<dholbach> nice
<ivoks> there's a problem with ICH8M IDE controlers in gutsy
<ivoks> should support for it be added to ata_piix?
* lamont waves
* lamont commits abi files for hppa 8.18
<lamont> BenC: you up and about yet?
* lamont has a question on a completely different subject
<BenC> lamont: yeah
<BenC> zul: ping
<zul_> BenC: umm..yeah?
<zul_> do I want to know? :)
<BenC> zul: these patches in your git, are they addressing launchpad bugs?
<fabbione> zul_: hey dude.. xen-3.1 did fail on i386...
<zul_> BenC: no I went through the linux-usb list and pulled out interesting patches
<zul_> fabbione: ill look this morning
<fabbione> thanks
<BenC> zul: Ok, some of them I'm a little leery of
<zul_> BenC: like which?
<zul_> besides xen ;)
<BenC>     UBUNTU: USB: Support Blackberry Pearl with berry_change
<BenC>     UBUNTU: USB:  Don't resume root hub if their parent controller device is still sus
<BenC>     UBUNTU:  USB: fix oops in ftdi_sio
<zul_> ok thats fine with me no skin off my nose
<BenC> the blackberry one isn't so bad, but I tried a patch like that awhile back and it didn't work on my 8830 :)
<zul_> ah
<BenC> I'll cherry pick the device id ones, and the xen patch
<zul> ok thanks, ill try to address more launchpad bugs next time
<BenC> zul: np, definitely appreciate the effort
<zul> thanks
<zul> there is an update to the usb autosuspend blacklist as well ill try to find the commit
<BenC> zul: definitely want that one to make the sane/scanner folks happy
<BenC> zul: cherry picked and pushed, thanks
<zul> no probs
<BenC> rtg: bug #121415 sent your way
<BenC> zul: Heh, may use your ftdi patch after all: bug #121583
<zul> yay
<BenC> hmm, doesn't look like the same backtrace though
<BenC> kylem: did we get blacklist-from-command-line in initramfs-tools yet?
<rtg> BenC: While I'm thinking about it, I'm gonna delete the gutsy l-r-m git repo just so there is no confusion in the future.
<BenC> rtg: good deal
<kylem> not afaik.
<kylem> we don't have an initramfs-tools maintainer.
<BenC> sure we do, it's called ubuntu-kernel-team :)
<kylem> those losers are useless though.
<BenC> hehe
<BenC> kylem: is the nommconf by default patch in the set I sent you?
<kylem> yes.
<kylem> now that dapper is done, and my updates to lum are churning, i guess i can look at that.
<BenC> ok, I'll assign 124294 to you then
<Nafallo> kylem: my laptop is delayed. so won't be chasing you until 6th of August by the looks of things :-P
<kylem> Nafallo, ok. :P
<BenC> kylem: have you joined audio team?
<BenC> kylem: probably want to make sure crimsun passes the admin torch there too
<kylem> ubuntu-kernel-team is part of ubuntu-audio
<BenC> I think you have to be a direct member to get admin
<kylem> ah.
<abogani> BenC: Please don't forget this: https://lists.ubuntu.com/archives/kernel-team/2007-July/001581.html
<BenC> abogani: right, thanks
<BenC> abogani: done and pushed
<abogani> BenC: Thanks and sorry for this bothering (me).
<BenC> abogani: no bother at all
<abogani> BenC: Last two things: Are you already re-enabled prioprietary video drivers build for rt? It is possible add schedutils as Recommends field in rt kernel flavour package? Thanks
<BenC> abogani: should be able to do the recommends, and yes, lrm/lum are building for -rt now
<BenC> abogani: have you not tested linux-image-2.6.22-8-rt?
<abogani> BenC: Not in debian kernel package form at this moment i build Gutsy kernel in standard way (make) on my (feisty) laptop. Don't have a dedicated machine for Gutsy yet, sorry. I'm a poor stupid :-(
<BenC> abogani: best bet is to "fakeroot debian/rules custom-binary-rt" and install that package
<BenC> you'll get the same thing that the archive will build
<BenC> you'll also get the linux-headers for it
<abogani> good. i had fear to break something :-)
<abogani> BenC: Arghhhh i'm executing "fakeroot debian/rules custom-binary-rt" and now i have an error! 
<abogani> /home/alessio/ubuntu-rt/ubuntu-gutsy/debian/build/custom-source-rt is not clean, please run 'make mrproper'
<abogani> What want make?
<BenC> abogani: you have some cruft in your tree
<BenC> fakeroot debian/rules clean
<BenC> make mrproper
<BenC> then run "git-ls-files --others" and delete anything in the tree
<BenC> s/the tree/the tree that's not supposed to be there/
<BenC> err, mrproper, don't run
<BenC> will probably delete debian directory
<BenC> just do the ls-files, or somehow get a clean checkout
<abogani> Resolved, thanks.
<Nafallo> BenC: you guys want solutions to module options for specific soundcards added as bugs with output of lspci -vn for the card added as bugs, right? :-)
* lamont wonders why his scsi cd-r drive writes coasters
<lamont> update-initramfs: Generating /boot/initrd.img-2.6.22-8-hppa32                   
<lamont> find: /lib/firmware/2.6.22-8-hppa32: No such file or directory                  
<lamont> find: /lib/firmware/2.6.22-8-hppa32: No such file or directory                  
<lamont> find: /lib/firmware/2.6.22-8-hppa32: No such file or directory                  
<lamont> find: /lib/firmware/2.6.22-8-hppa32: No such file or directory                  
<lamont> find: /lib/firmware/2.6.22-8-hppa32: No such file or directory                  
<lamont> find: /lib/firmware/2.6.22-8-hppa32: No such file or directory                  
<lamont> should that find output be supressed??
<lamont> BenC: and it looks like I may have config changes for hppa too. :-(
<BenC> lamont: those you can ignore...I need to fix initramfs-tools not to show that when the firmware dir doesn't exist
<bdmurray> BenC: I ran across a bug about a CD drive eject button.  Is that kernel related?
<BenC> bdmurray: not likely, but it may be hotkey-setup related
<bdmurray> I meant the physical button on the front of the drive.
<bdmurray> If that wasn't clear.
<JanC> could be harware too  :)
<bdmurray> They seem to indicate that it worked in Feisty
<BenC> odd, if it worked in feisty, and not gutsy, it's definitely a bug
<BenC> bdmurray: best test, boot single-user into feisty kernel and gutsy kernel, and test the button
<bdmurray> BenC: duh - thanks
<BenC> bdmurray: np
#ubuntu-kernel 2007-07-19
<zul_> yay xen has made it into linus git
<BenC> zul_: just the paravirt bits, right?
<zul_> yep
<BenC> better than nothing
<zul_> yep now we get to see how other distros will handle it
<BenC> and get to let it simmer one release before we take it in gutsy+1
<zul_> yep
<IntuitiveNipple> Is there any updated Kernel-Build docs aside from the Kernel-Team Wiki, I'm not having much luck building the git ubuntu-feisty tree according to the instructions for Feisty  - "fakeroot debian/rules binary-debs" reports 'no rule to make target' trying to debug a suspend/resume issue on a fresh install of Feisty ?
<BenC> IntuitiveNipple: you did checkout the ubuntu-feisty.git from kernel.ubuntu.com, right?
<IntuitiveNipple> Yes Ben, and Gutsy too, to compare the differing build methods. So far, no joy. Been trying to find the 'binary-debs' target but not found it. Found 'binary' okay though :)
<BenC> just run binary then
<IntuitiveNipple> Whats the difference between them? I kind of assumed it was something significant :)
<BenC> more stuff gets built with binary
<BenC> better more than less
<IntuitiveNipple> ok... all I needed to do was enable CONFIG_USB_DEBUG to monitor any stray events during suspend/resume... turned into an 8-hour fight with the build system... strange really, prior to adopting this I was using the 'old make-kpkg' system and apt-get or kernel.org sources with no problems.
<BenC> IntuitiveNipple: you could just do apt-get install linux-source-2.6.20, then use the tarball in /usr/src with make-kpkg
<BenC> use /boot/config-2.6.20-*-generic
<IntuitiveNipple> yeah, I had been doing that... but I thought it was time to catch up with you guys! I did all the debugging/fixing of the intel hda sound bug that way
<crimsun> which HDA bug?
<BenC> crimsun: hey
<crimsun> BenC: 'lo
<IntuitiveNipple> dma buffer looping/crackling on resume 
<crimsun> which HDA codec?
<IntuitiveNipple> intel
<crimsun> no, codec.
<crimsun> Analog Devices?  Realtek?  Conexant?  Sigmatel?
<BenC> crimsun: could I get you to pass the admin flag on to kyle for ubuntu-audio?
<IntuitiveNipple> Sigmatel
<crimsun> TheMuso: please see above
<crimsun> BenC: I made TheMuso the admin of that group and just pinged him
<IntuitiveNipple> But, the bug *isn't* in the snd module, its in the kernel itself, but I put a work around in the Fiesty sn-hda-intel code because the kernel bug doesn't affect 2.6.22
<crimsun> BenC: he'll need to make that change; I'm no longer a member of that team.  The wiki page is easily edited, though.
<IntuitiveNipple> See the last few comments to https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/100114
<crimsun> IntuitiveNipple: err, that has nothing to do with snd.ko
<crimsun> that's all rolled into snd-hda-intel.ko 
<IntuitiveNipple> I didn't mention snd.ko 
<BenC> crimsun: When's your last day out in the public?
<crimsun> IntuitiveNipple: ok, so you meant something different by "the bug *isn't* in the snd module"
<crimsun> IntuitiveNipple: I interpret that to mean snd.ko, because you explicitly use the string "snd"
<IntuitiveNipple> 'snd' module as in the snd-hda-intel module I had just mentioned
<crimsun> BenC: between Sept and Oct; depends on $boss
<crimsun> IntuitiveNipple: sure
<IntuitiveNipple> anyhow, it was an issue with the botting of the 2nd CPU/core overwriting random PCI config reg space of the HDA device's TCSEL register, so we check its value on resume and correct it if its bad
<TheMuso> crimsun: Will do.
<BenC> crimsun: you will be missed :)
<zul> yeah sound is going to suck :)
<crimsun> IntuitiveNipple: did you send it upstream to alsa-devel@ ?  I haven't seen it.
<IntuitiveNipple> botting/booting!
<IntuitiveNipple> crimsum... no, didn't see the point seeing as the issue has gone from 2.6.22 (so far!)
<crimsun> IntuitiveNipple: ok
<TheMuso> Whats Kyle's LP name?
<zul> crap he is up
<crimsun> TheMuso: kylem
<TheMuso> crimsun: Thanks.
<kylem> no. kyle.
<crimsun> err
<IntuitiveNipple> There's nothing wrong with snd-hda-intel, just the kernel non-boot CPU resume being late, after PCI devices had been resumed
<crimsun> yeah, for some reason muscle memory defeated me
<crimsun> (I really did type kyle)
<crimsun> TheMuso: thanks.
<TheMuso> crimsun: np
<bdmurray> Are MacBook Pros Intel based?
<kylem> yes.
* TheMuso prods launchpad...
<bdmurray> cool, thanks
<TheMuso> kylem: Done.
<kylem> ok.
<zul> argh he doesnt sleep
<Philip5> i have a little question about the debian-rules that the linux-source-2.6.22_2.6.22-8.18 in gusty use. i would like to make a custom kernel using the debian rules. i have changed the flavours variable in i386.mk to custom, changed and setup a custom.config in debian/config/i386 and everything seam to build ok but after modules and stuff got built it breaks with a error like no rule to make custom
<Philip5> looks like it needs to be set some rule or variable for a make file for the custom too
<Philip5> does this make any sense?
<Philip5> have i missed to define custom somewhere?
<kraut> moin
<amitk_> lamont: I have now pushed all the changes into gutsy except for ABI since that will be done as part of the kernel release
<abogani> What is the best place for set schedutils into Recommends field for rt kernel flavour? linux-rt meta-package or linux-image-2.6.22-8-rt ?
<amitk_> I will defer that debian-specific question to cjwatson or benc
<abogani> amitk_: Could add -rt to gutsy-meta? Or prefer my diff of the debian/control.d/i386? :-)
<amitk_> abogani: I would prefer if you sent a properly formatted patch to kernel-team@lists.ubuntu.com
<abogani> amitk_: gutsy-meta.git don't have debian/commit-templates/patch git template. A simple diff is right?
<amitk_> abogani: simple diff with a sign-off line is good enough
<abogani> amitk_: Ok, Thanks.
<abogani> amitk_: How can test rt meta packages building?
<abogani> BenC: If i build rt kernel...
<abogani> grep "rt[1-9] " debian/binary-custom.d/rt/vars
<abogani> target="Ingo Molnar's full real time preemption patch (2.6.22.1-rt4)"
<abogani> dpkg -I ../linux-image-2.6.22-8-rt_2.6.22-8.19_i386.deb | grep "rt[1-9] "
<abogani> Ingo Molnar's full real time preemption patch (2.6.22.1-rt2)
<abogani> :-???
<abogani> I already checked debian/binary-custom.d/rt/diff and it is a true rt4 rt patch for Ubuntu..
<BenC> abogani: fakeroot debian/rules clean
<BenC> abogani: then rebuild
<abogani> BenC: I already do this two times... i'm cloning git repo again.
<abogani> BenC: Exactly: fakeroot debian/rules clean && make clean && make mrproper && git-checkout -f
<BenC> there's your problem
<BenC> run "fakeroot debian/rules clean" after git-checkout -f too
<BenC> the forced check out overwrites the updated control files
<IntuitiveNipple> BenC: sorry to be a bother (what you've just suggested may help me too) but the build of Feisty from git has now failed both using the 'new' and 'old' ways and I'm wondering if you'd take a quick look at the short log-file I've just captured from a ' fakeroot make-kpkg...' build and tell me if it is me or something in the git that could be the root of my issues?
<IntuitiveNipple> ( log is at http://paste.ubuntu-nl.org/30429/)
<BenC> IntuitiveNipple: I told you that you could only use the make-kpkg method by installing linux-source-2.6.22 package and building from the tarball, not using our git tree
<BenC> IntuitiveNipple: if you want to build from a git tree, use stock linux-2.6 tree from linus
<BenC> otherwise, you'll need to use the the right "fakeroot debian/rules binary-debs flavours=generic"
<IntuitiveNipple> BenC: Oh, I misunderstood then, sorry, I think the various instructions on the Wiki confused me
<IntuitiveNipple> BenC: yeah, that was the one I was trying from a virgin install from Feisty git and getting the unknown target 'binary-debs' report... I think I'll install from scratch and try again :)
<IntuitiveNipple> BenC: Thanks... a "git checkout -f", edit of debian/config/i386/config, "debian/rules updateconfigs" and now "fakeroot debian/rules binary-debs" is building - somehow I must have managed to mess up the checked-out version between checkout and build attempt. (I've also built the latest git 1.5.2 from source rather than using the 1.4.x from repo)
<BenC> IntuitiveNipple: if you ran make mrproper or anything like that, it'll break things most likely
<IntuitiveNipple> BenC: I must have, although, to my knowledge, the only kernel builds I'd been doing were in a separate install of the linux-source-2.6.20 I was using to build the snd-hda-intel and alsa core modules for debugging another issue
<IntuitiveNipple> Anyhow... I'm happy now... I can get back to focusing on debugging these suspend/resume issues!
<lamont> abogani: util-linux 2.13 will deliver schedutils as part of essential... no need to recommend it.
<lamont> amitk_: thanks.  I'm still dealing with the minor issue that hppa64 kernels don't boot.  If that causes an abi bump when I fix it, we'll just smash it into existance anyway, since it's clear that no one could possibly be running hppa64 and upgrading to the working one.
<amitk_> lamont: sounds good
<abogani> lamont: Good, thanks.
<BenC> lamont: we may want to force a rebuild for lum at least in that case, because the ones built against previous might not load against the new kernel
<lamont> BenC: if I change the hppa32 config in an abi-bumping manner, I'd want the abi change.  current state of hppa64 is that it's a lie: doesn't boot, so there is no abi to break
<BenC> lamont: but lum would be built against the non-booting kernel, and if the ABI really changed, then those modules wont load against the new kernel that does boot
<lamont> oh.  got it.
<lamont> so rebuild lum, rather than rebuilding the kernel for lum. :)  EPARSE
<BenC> :)
<BenC> not that there's much in lum that hppa would use, unless people are using unionfs/squashfs in some custom way
<lamont>  /build/buildd/linux-ubuntu-modules-2.6.22-2.6.22/debian/build/build-hppa32/media/ov511/ov511.c:269: error: 'VIDEO_PALETTE_GREY' undeclared here (not in a function)
<lamont> there's not anything in lum that people will use until we fix it. :-
<lamont> )
<lamont> is lum in git or somesuch somewhere?
<amitk_> git://git.kernel.org/ubuntu/ubuntu-gutsy-lum.git
<amitk_> oops... that should be kernel.ubuntu.com
<abogani> BenC: with a fresh Gutsy git cloned repo problem still persist... :-( 
<Philip5> hi again guys.... 
<Philip5> i think i paste my question again and hope someone is alive :)
<Philip5>  i have a little question about the debian-rules that the linux-source-2.6.22_2.6.22-8.18 in gusty use. i would like to make a custom kernel using the debian rules. i have changed the flavours variable in i386.mk to custom, changed and setup a custom.config in debian/config/i386 and everything seam to build ok but after modules and stuff got built it breaks with a error like no rule to make custom
<Philip5> looks like it needs to be set some rule or variable for a make file for the custom too
<Philip5> have i missed to define custom somewhere?
* lamont heads off to the office
<lamont> amitk_: I'm about 60 seconds from committing a works-but-sucks config for hppa64.  taht'd be nice for -8.19
<amitk_> lamont: i guess it depends on how bad it sucks ;)
<lamont> I turned off SMP
* lamont wonders what usage is for splitconfig.pl
<amitk_> it recreates the config into base and extras for all flavours of a particular arch
<amitk_> s/recreates/splits
<lamont> so what should I feed it?
<amitk_> you shouldn't have to. Instead do the following:
<lamont> http://people.ubuntu.com/~lamont/config.fullhppa64 is the full .config for hppa64....
* lamont needs to flee for a couple hours
<amitk_> cd debian/config/<arch>; for cfg in config.* do;
<lamont> so if it's quick, I can do it now.
<amitk_> cat config >> $cfg
<amitk_> done
<amitk_> rm config; debian/rules updateconfigs <--- this will split out the configs for you
<lamont> must run.  I'll do that when I'm back online
<bdmurray> So I've tagged a fair number of bugs as kernel-oops
<BenC> bdmurray: cool
<bdmurray> Some are filed against ndiswrapper but those are easily ignored.
<BenC> fyi, ndiswrapper bugs in gutsy should be against lum-2.6.22
* bdmurray sighs
<BenC> hehe
<bdmurray> but pre-gutsy they should be against ndiswrapper?
<cno1> need help patching the linux kernel... im following this guide, and i do not understand part 3... somebody please help! :-X
<cno1> the guide is here: http://www.pabr.org/sixlinux/sixlinux.en.html
<BenC> cno1: this isn't a general kernel help channel
<BenC> cno1: try #kernelnewbies
<cno1> thanx
<BenC> cno1: feisty on ps3 should work for bluetooth ps3 controllers
<BenC> save you a lot of patching
<cno1> thanx again...
<zul> BenC: ping
#ubuntu-kernel 2007-07-20
<zul> works fine Linux homer 2.6.22-8-xen #1 SMP Thu Jul 12 17:32:08 GMT 2007 i686 GNU/Linux
<lamont> /home/lamont/kernel/hppa-ia64/scripts/gcc-version.sh: line 11: hppa-linux-gcc: command not found
<lamont> sigh
<lamont> Running splitconfig.pl ... 
<lamont> debian/scripts/misc/oldconfig: line 73: /home/lamont/linux-source-2.6.22-2.6.22/debian/scripts/misc/splitconfig.pl: Permission denied
<lamont> updateconfigs target needs a chmod
<lamont> hrm... I'll probably wind up committing something before bed tonight, but I'm nowhere close to finished
<kraut> moin
<\sh> bug #127125 
<\sh> fabbione: you don't have hands on a x4500 from sun with full storage?
<fabbione> no
<fabbione> i don't get x86* junk here
<fabbione> sorry :)
<\sh> fabbione: well, my interest is just the storage ;)
<Nafallo> BenC: seems there are device-ids missing from the ralink drivers. want a bug about them?
<Nafallo> grep 3c03 * in ubuntu/wireless/rt2x00 should show binary match, right?
<Nafallo> BenC: never mind me. I checked git, and it's there.
* Starting logfile irclogs/ubuntu-kernel.log
<BenC> Nafallo: you can't grep for hex strings in a binary
<Nafallo> BenC: yea, I discovered that :-)
<Nafallo> BenC: a user complained a ralink-based usbthingie didn't work in feisty, so I git-cloned and the ids is there. I told him to file a bug.
<Nafallo> s/is/are/
<jovans> is there a kernel bugfix release soon for feisty?
<jovans> or can i use the current version kernel under gutsy?
<bdmurray> BenC: is there enough info in bug 123669 for you guys to work on it?
<BenC> bdmurray: could use full dmesg and lspci -vvn output
<BenC> bdmurray: narrow down the driver for us, since cable detection is driver dependent
<BenC> ...in some cases
<BenC> the fact that he's using hdc instead of scd0 means IDE, and I'd like to find out if switching to libata-pata would help him
<bdmurray> cool, I would have thought cable detection was generic
<BenC> there's generic ATA code, and some drivers have specific cable detection
#ubuntu-kernel 2007-07-21
<kraut> moin
#ubuntu-kernel 2007-07-22
<AnAnt> I have a problem, I got an HP dv6391 laptop, and ubuntu crashes when I boot the laptop
<AnAnt> so how do I report that problem ?
<kraut> moin
<IntuitiveNipple> I'm working on an ACPI suspend/debug issue. I've added conditional debug code to drivers/acpi/hardware/hwsleep.c. I want it to be compiled if DEBUG_RESUME is defined. Is there an easy way to add DEBUG_RESUME to the make CFLAGS, or can I simply do MAKEFLAGS=-DDEBUG_RESUME AUTOBUILD=1 fakeroot debian/rules ?
#ubuntu-kernel 2008-07-14
<Kano> hi, could somebody merge 2.6.26 final?
<Liou> How can I know what symbols were exported by the kernel
<Kano> usally when you see an error then they are not exported ;)
<Kano> hi BenC , did you see 2.6.26 final?
<BenC> No, I'm completely oblivious to what goes on in the kernel world
<Kano> then you know what i am waiting for already ;)
<BenC> then you know that I'm not rushing just for you :)
<Kano> well for all others too ;)
<emma> Good morning, I would like to bring a certain kernel specific problem to the attention of someone with the expertise to elevate it to prominence.
<emma> I myself have zero skills but I am friends with dozens of ubuntu users and many of them have begun to experience the same bug. Anecdotally I think it may be a problem that is making people migrate away from using Ubuntu.
<amitk> emma: is there a bug number?
<emma> Yes, I'll post it right now.
<emma> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/228624
<emma> People with this bug apparently can no longer use their optical drives which leaves them thinking Ubuntu is not a viable option for them. Usually they have a lot of regret for reaching that point, and they are concerned that this bug is unnoticed. 
<emma> I really appreciate you taking a look. Thanks so much.
<ln-> 12:36 < amitk> ln-: If you want JustWorks (TM), you have to either help during beta testing or get a s
<ln-> upport contract. It is unrealistic to expect that a distribution will hit all your target usecases.
<amitk> ln-: Testing early certainly helps. It is kinda hard to buy and test on all the hardware available out there :) On the other hand, sometimes it might be only a Ubuntu problem that needs to be looked into
<amitk> emma: all_generic_ide=1 seems tosolve the problem for many, have you tried that?
<emma> amitk: This isn't a problem that I personally have right now. But I will pass that along to the several people I know who have been talking about it.
<amitk> emma: it also helps to know if this worked on other distros for them
<emma> I will find out and report back to you.
<danutzu> hello
<danutzu> please 
<danutzu> help me
<ln-> please express yourself with fewer newlines.
<danutzu> my pidgin is closing when I'm joining the yahoo chat
<danutzu> pleaseeee!!!!!
<ln-> danutzu: what part of the kernel is responsible for yahoo chat, what do you think?
<danutzu> I donw know man
<danutzu> :|
<danutzu> just help me to make pidgin yahoo to work
<danutzu> please
<danutzu> when I right my yahoo id and password an then when I push the save button the yahoo pidgin doesn't login :| he close himself:|
<danutzu> please just tell me how do I make-it work
<mjg59> danutzu: #ubuntu is a better place to ask this
<danutzu> good
<danutzu> thx
<zbrown> amitk: hi :)
<amitk> zbrown: hi
<zbrown> I'm the person thats had issues with the dvd drive
<zbrown> well one of many
<amitk> ogasawara: hey, do you think 228624 should go onto the recommended list?
<ogasawara> amitk: I was going to put it on there but it's not technically tested against intrepid yet
<amitk> zbrown: ^ would you be bold enough to install the intrepid kernel?
<zbrown> I was going to test with intrepid yesterday but the installer hung up twice on me
<zbrown> amitk: on top of Gutsy?
<zbrown> or does it really matter what release it is?
<amitk> zbrown: on top of Gutsy isn't tested, but we're running the kernel on Hardy
<zbrown> well Hardy isn't on the laptop anymore
<Kano> BenC: is there a tag missing?
<amitk> zbrown: it can matter... udev, hal, etc.
<zbrown> amitk: would it work via installing Wubi?
<zbrown> I have a windows partition on here
<zbrown> I'm not willing to blow away gutsy and put hardy back on to test, its my only computer as I'm travelling for the summer
<zbrown> but if wubi would work
<amitk> zbrown: wubi install would work, install hardy and upgrade to a intrepid kernel
<zbrown> amitk: hmmm ok, I'll see wwhat I can do
<zbrown> amitk: hmmm is wubi going to fight with the standard grub boot loader?
<zbrown> or am I just going to go through two boot loaders?
<cking> zbrown: I believe it should be OK.
<zbrown> ok
<cking> zbrown: as long as you have enough space on your Windows NTFS partition it should be fairly straight forward
<zbrown> cking: I've got plenty it looks like
<zbrown> 40 gigs, with only 5 used
<cking> zbrown: Cool. I think 4-6 GB free is plenty
<zbrown> now if anl.gov would just be a faster mirror
<cking> :)
<zbrown> I dunno why it picks anl.gov over usc.edu
<zbrown> I'm in LA... usc.edu is maybe 10 miles from me lol
<zbrown> I'm not sure how far Google SMO is from usc
<ogasawara> zbrown: after you've tested care to post another comment to the bug report
<zbrown> sure
<zbrown> good thing this wasn't yeseterday :)
<zbrown> I was especially pissed yesterday
<amitk> zbrown: yesterday was sunday :)
<zbrown> indeed
<zbrown> ogasawara: whats your preferred method for me to upgrde the kernel?
<zbrown> upgrade the entire system or just go download the kernel?
<ogasawara> zbrown: I'd try just upgrading the kernel
<zbrown> ok
<zbrown> hmmm apparently medibuntu is down for once
<zbrown> curses
<zbrown> ogasawara: same problem
<zbrown> cking: and same problem
<zbrown> cking: ogasawara: I've updated the bug with my results from dmesg
<michi666> hi all, can anybody help my with usb driver programming?
<amitk> michi666: this isn't the right channel for it. You shoul d try kerneljanitor or kernelnewbies.org or usb-devel
<ajonat> Hi! when i do fakeroot debian/rules binary-modules-generic, i get that the target doesn't exist (binary-modules-generic).. what am I doing wrong? I'm compiling from hardy's git btw
<ajonat> I'm following the KernelMaintaince and Kernel/Compile guides
<ajonat> I've succesfully compiled binary-generic and binary-headers but binary-modules-generic doesn't seem to exist..
<amitk> ajonat: what arch do you have installed?
<Kano> ajonat: time debian/rules binary-debs flavours=generic
<Kano> well use fakeroot ;)
<ajonat> Kano, gonna try that :)
<ajonat> Kano, that builds the image, headers and modules?
<Kano> thats for lum
<Kano> time debian/rules binary-debs flavours=generic skipabi=true skipmodule=true
<Kano> time debian/rules binary-headers
<Kano> thats for the kernel
<ajonat> Kano, ok, thank you!
<Kano> i use the skip overrides because i dislike stops when it is basically done ;)
<ajonat> oh, and one more question? what does NOEXTRAS mean?
<ajonat> can't find it in the docs
<Kano> dont know what you mean,but to compile lum you have to install the kernel headers you compiled first
<zbrown> Any likelihood of you guys updating the Madwifi drivers in Hardy? The current ones are too old to support the Atheros 5212 chipset properly
<zbrown> can scan, but can't connect
<amitk> zbrown: file a bug and QA will consider it for the next SRU
<zbrown> amitk: hmmm ok, I think there's a big bug thats got several Ahteros chipsets listed as not working and wanting a madwifi update
<zbrown> amitk: should I file an individual one for atherose 5212?
<zbrown> I already posted to that bug saying that 5212 wasn't working either
<amitk> zbrown: adding to that is fine
<zbrown> amitk: ok, done then
<zbrown> amitk: 122703 <-- thast the bug number
<amitk> zbrown: it is unlikely to get fixed until madwifi.org releases a new version. It is hard to include directly from trunk while ensuring no regressions.
<zbrown> hmmm
<zbrown> amitk: thats doubtful to happen as they've mainly focused on ath5k which fails to build all together
<zbrown> on Hardy
<zbrown> or Gutsy
<zbrown> (atherose 5212 is also broken in Feisty and Gutsy)
<amitk> rtg: ^^^
<zbrown> I have Gutsy on the laptop now and had to build my own drivers
<zbrown> and a friend has the same laptop as I still running Feisty and he had to build madwifi himself as well
<zbrown> amitk: "ath5k is a relatively new and emerging driver and does not depend on the HAL. It is intended to replace MadWifi in the long run and exceed it feature-wise. ath5k is where most of our development resources are spent on now." <-- from the madwifi site
<zbrown> honestly something needs to change
<zbrown> otherwise you're killing about 5 or 6 releases of atheros chipsets since ath5k isn't in the kernel
<zbrown> and won't build with it
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-4.10 (based on 2.6.26 final) |  Latest news: Please test last-good-boot, now in intrepid (grub/module-init-tools) | Next meeting: July 22, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<pwnguin> http://kernelslacker.livejournal.com/127218.html dave jones SMASH
#ubuntu-kernel 2008-07-15
<Iulian> Good morning.
<soren> amitk: So.... Where can I see your lpia magic stuff?
<amitk> soren: clone ubuntu-intrepid-lpia from zinc
<soren> amitk: So... did you end up b-d'ing on linux-source?
<amitk> soren: no, it is a a complete kernel tree
<soren> Ah. Hm... Well, that probably is the easiest.
<soren> What I'd really like would be to be able to *maintain* it as a git tree, but have the source packages only contain the patches and then b-d on linux-source.
<amitk> soren: maintaining a set of patches in git is similar to what binary-custom.d did in Hardy kernels. We don't want that anymore. We want these patches applied now..
<amitk> besides, b-d'ing will get a different versionof source for different people, depending on when they build
<soren> amitk: Yes, that's true.
<soren> Well, ok. I'll grab your stuff and see what I can do with it. Thanks.
<amitk> soren: ping me for pointers to get your started. AUTO patches are generated in the script (debian/scripts/mis/rebase-intrepid), SAUCE are the legitimate patches for the flavour
<soren> "AUTO patches"?
<amitk> soren: :) you'll see
<soren> Hm... Alright :)
<infinity> amitk: *poke*
<infinity> amitk: The new linux-lpia source package... Does that have any new code (licensing-wise) compared to the hardy lpia kernels?
<infinity> amitk: Or can I just blindly accept it?
<amitk> infinity: no new code, it is the intrepid kernel with the debian/ dir replaced by lpia specific configs
<infinity> amitk: Kay, that's all I needed to kno.
<infinity> know*
<infinity> amitk: Accepting to universe for now, until someone tells us differently.
<amitk> infinity: thanks. I'll ask loic to take up promotion to main
<infinity> amitk: There aren't any non-free bits in that, are there...?
<amitk> infinity: nope. Only the firmware that we carry in the intrepid tree that are freely redistributable.
<infinity> amitk: Check.  Thanks.
<soren> amitk: Ok, I have the cloned tree now.. I want to have origin pointing at the ubuntu-intrepid tree, I imagine. Hm.. I've never done this rebasing business before.
<amitk> soren: no, you want origin pointing to your new tree, e.g. ubuntu-intrepid-virtual
<soren> Oh. Ok.
<amitk> the intrepid tree is just a branch
<soren> Ok, origin is now pointing at my git tree on zinc..
<amitk> soren: after you have cloned my tree, I suggest to modify it to suit virtual, then upload to zinc. 
<amitk> soren: this will be easier done on zinc itself
<soren> Oh. I followed the instructions on the wiki about how to set up your own tree, so I cloned yours and copied it to /srv/kernel.ubuntu.com/blah/blah.
<soren> I've not changed any code yet. At all.
<soren> Oh, you're building your own linux-libc-dev.
<amitk> soren: probably remained there during the cleanup
<amitk> soren, ok. Now that it is published on kernel.ubuntu, clone the tree from there. That will get origin set correctly
<zul> hello
<soren> amitk: Oh, I can get the origin set correctly manually. No worries.
<the_fafa> i had a broken 7.10 kernel upgrade from 14 to 15. it booted a broken kernel 15 and it did not put the right files to the /boot directory. just for information.. probably some of you know how to fix this.
<the_fafa> could someone explain this to me? i had a different filesystem while that error kernel was booted.. what was it? some live-cd leftover? i mean this is serious.. whats going on?
<soren> amitk: Wow, that's convenient. make mrproper nukes the debian/ directory even if you've spent 3-4 hours tweaking it and haven't committed any of it.
<soren> Oh, he's not here.
<the_fafa> soren, i know. mrproper also erases your .config :(
#ubuntu-kernel 2008-07-16
<s3a> does ubuntu 8.04's free software only mode have any proprietary drivers such as drivers for wireless cards in the kernel that are not open source?
<pwnguin> it sounds like it shouldn't
<pwnguin> i assume it works by not enabling -restricted or -multiverse
<pwnguin> and "evil" drivers should be in restricted
<s3a> pwnguin: lol im asking cuz both of my wireless cards work
<s3a> pwnguin: i hadnt expected that
<s3a> so wait the whole free software only mode is all about not enabling those 2 repositories??
<s3a> but there is no proprietary content to begin with in either ubuntu, right?
<s3a> by either ubuntu i mean the free and non free modes
<pwnguin> define proprietary
<pwnguin> nvidia drivers are closed source
<pwnguin> with a small wedge layer so they work, technically, and sometimes legally
<pwnguin> s3a: the free software mode is about making sure those repos are accurate
<pwnguin> i would have loved to have seen it become something like a project to both identify non free software and promote free alternatives, but that appears to have not been a priority
<s3a> ok so the ubuntu without the free software only mode has no proprietary software installed but has the repositories for proprietary stuff enabled..thats the only difference?
<pwnguin> what else is there?
<pwnguin> a different background?
<s3a> well, wireless cards drivers and i no video card drivers are free so i guess it is fully free
<s3a> i cant think of anything proprietary
<s3a> other
<s3a> than the
<s3a> artwork for firefox which doesnt matter since it doesnt get in the way of the freedoms and helps firefox keep its identity
<pwnguin> logos and trademarks are tricky
<pwnguin> but this is starting to have less to do with the kernel
<s3a> pwnguin: o ya lol but so ya the kernel is 100% free then?
<pwnguin> i assume so -- I haven't tried it
<pwnguin> what i do know is that gobuntu failed at its mission
<s3a> and wat do kernel upgrades do rely? it allows to see more hardware?
<s3a> pwnguin: ya cuz of gnewsense
<s3a> i tried to go there
<s3a> but they didnt have a 64 bit
<pwnguin> well, gobuntu was also created because of gnewsense
<s3a> i would use gnewsense if it had 64 bit
<s3a> ya but developpers dint want to develop it bcuz of repositories??! like wat kind of reason is that, u can have the proprietary stuff disabled by default
<pwnguin> i havent followed it closely, but i suspect gnewsense developers didn't want to rely on launchpad
<s3a> pwnguin: launchpad is proprietary?
<pwnguin> launchpad is owned by canonical and not all the source code is available
<s3a> o sh*t
<pwnguin> of course, it's also nowhere near stable, and I suspect one of their goals requires a stable abi
<s3a> y is canonical of all ppl being like that??
<pwnguin> api really
<s3a> wait wats abi and api
<pwnguin> in the context of web software, the meaning of urls in relationship to the data they access
<pwnguin> I suspect the goal of launchpad is to create a distributed bug tracker in the same way we have a distributed code tracker
<pwnguin> I believe ive read that once they're satisfied that launchpad is capable of tracking another instance of itself, they'll release the code
<pwnguin> i think they've released the code to rosetta or something as a goodwill gesture
<pwnguin> and like i said, it's still moving. they just redid the UI last week
<pwnguin> once you release the code, you'll have people who won't upgrade despite the code being "alpha"/"beta"; like a filesystem, you're doomed to worrying about it until the last user dissapears
<s3a> pwnguin: u kinda lost me but i have to eat breakfast now anyway
<soren> 20:59:09 < soren> amitk: Wow, that's convenient. make mrproper nukes the debian/ directory even if you've spent 3-4 hours tweaking it and haven't  committed any of it.
<alex_joni> soren: yeah, it's quite fun.. I've got bitten by it a couple times too
<amitk> soren: that was always the case :)
<amitk> it is a conflict between the in-kernel config system vs. debian
<soren> amitk: Ok. It doesn't help much that if there's cruft in the tree, make helpfully tells me that "hey, you should try running mrproper".
<soren> ...and so I did, and then the dear Mr. Proper ate 4 hours of my work.
 * soren is not a fan of Mr. Proper anymore.
<amitk> soren: you probably ran a 'make menuconfig' in the directory :)
<alex_joni> amitk: how do you generate the config file usually?
<amitk> alex_joni: tied up in a meeting that requires my attention. Catch me tomorrow please....
<alex_joni> amitk: sure, no hurry..
<soren> amitk: No, I think I acutally ran dpkg-buildpackage -b.
<soren> I never ran menuconfig
<gnomefreak> 2.6.16.4 broke uspash. 
<gnomefreak> oops 
<gnomefreak> 2.6.26.4
<maks_> ther is no uspash
<gnomefreak> there was 
<gnomefreak> prior to .4 update i had a uslash (are we dropping it? or is it just meant not to have one)?
<AlexCONRAD> hi, I just installed the 8.04.1 alternate xubuntu. It seems that I no longer seem to need to install an alternative driver from realtek to make my RTL8111C network card to work (r8168/r8169 modules)
<BenC> alex_joni: excellent
<alex_joni> BenC: meant AlexCONRAD?
<BenC> alex_joni: yeah, stupid nick completion :)
<stgraber> BenC: if you happen to have a second, can you fix bug 246222 ? it shouldn't take more than a minute to fix it in git so I can use my custom dsdt with the next kernel :) (not that I don't like the sound of my lappy fan going full speed all the time ...)
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246222 (as you don't have ubottu here)
<stgraber> BenC: thanks
<solarion> anyone around to help diagnose an eSATA problem?
<solarion> I gots tasty error messages!
<solarion> no takers?  It could be interesting
#ubuntu-kernel 2008-07-17
<elmargol> cat /proc/acpi/battery/BAT0/state present:                 no <- WTF did you mess arround with the power management?
<RainCT> Hi
<RainCT> Linux is all-mighty... After the last kernel update on Hardy my PC can speak... o_O
<RainCT> and I'm not joking ;)
<RainCT> (with espeak, of course)
<RainCT> well, now seriously... using the latest kernel the sound comes out of the PC box instead of the speakers (although crappled -does this word even exist? :)- for music, but espeak for example is quite clear)...
<RainCT> how can I fix this?
<BenC> RainCT: try blacklisting the pcsp driver
<RainCT> BenC: but then I won't have beeps. or you mean just for testing?
<kirkland> rtg: hey, can you turn on ISCSI_IBFT and ISCSI_IBFT_FIND in the Intrepid kernel configs?
<kirkland> rtg: this is a small part of bug #237460
<rtg> kirkland: done
#ubuntu-kernel 2008-07-18
<Kano> hi, why is the intrepid kernel for 686 only? a k6-2 would be working too when you use i586 or i586mmx
<sven-tek> Hello kernel developers. Is there a chance to enable CONFIG_HID_FF (Force Feedback support) and drivers? Until now it is not set, i guess its not enabled because its in experimental state. But from my point of view it should be safe enough. I posted a bug report for this feature request recently, but there was no feedback at all.
<mkrufky> Is Steve Langasek in here?
<rtg> mkrufky: he is in London right now, probably off drinking beer by now.
<mkrufky> thanks, rtg
<mkrufky> i found him in #ubuntu-devel
<mkrufky> what is the policy for driver submission for the intrepid kernel?
<mkrufky> i have 1 small patch against xc5000 (patch will be in 2.6.27 and it applies cleanly against intrepid 2.6.26)
<mkrufky> and i have to add the sms1xxx driver to intrepid as well.  sms1xxx will be included with 2.6.27
<mkrufky> the current sms1xxx has some additional trivial cleanups.  for now, doesnt really pay to backport those into hardy lum
<mkrufky> eh, i'll push them to my git tree and issue a pull request, but i'd like to know when is the deadline
<mkrufky> (i'd prefer to wait for the last minute, in case sms1xxx gets any additional fixes in the linux-next tree before actual merge to 2.6.27)
#ubuntu-kernel 2008-07-19
<Drk_Guy> How can i enable UDF support?
<Drk_Guy> Do i have to recompile=
<Drk_Guy> ?
<tallmtt> I am having issues compiling a kernel from git - I am now compiling a kernel with only make then make modules_install - is this way risky to my system?
<prahmod> can anyone tell me about the kernel in ubuntu
<prahmod> i am quite new to thsi topic but interested
<pwnguin> leann had a good discussion / posting during open week
<prahmod> ????
<pwnguin> prahmod: I'll see if i can find a link for you
<pwnguin> https://wiki.ubuntu.com/MeetingLogs/openweekhardy/UpstreamKernels
<prahmod> plzz man get me one.i am very much interested.but even plz u don't mind talking to me about it
<pwnguin> its more oriented towards the upstream kernel than what ubuntu ships
<prahmod> ok got that.do share some useful links 
<prahmod> so can we go slow.
<pwnguin> the wiki in the subject of this channel is also useful ;)
<prahmod> well i do understand kernel but what does the upstream kernel mean??
<pwnguin> Linus Torvalds writes the linux kernel, along with his army of volunteer kernel hackers
<pwnguin> they store and publish their work at kernel.org
<pwnguin> this work is basically patches migrating from one person to the next and so on until torvalds approves the work
<pwnguin> at which point it flows to places like ubuntu, debian, the public at large
<pwnguin> kernel.org is the "upstream project"
<pwnguin> sometimes ubuntu kernel developers apply patches that aren't in upstream, and that's one differnce
<pwnguin> the build process is also a bit different, since ubuntu kernels are built for a wide variety of people and purposes, while people building an upstream kernel usually know exactly what they want
<prahmod> ok.i am getting some idead
<prahmod> idea
<prahmod> and how do i get a kernel file at the kernel.org
<pwnguin> before we do that, let me ask you about technical proficienceis
<prahmod> ok
<pwnguin> how confident are you with UNIX and C programming?
<prahmod> go on
<prahmod> well i am quite perfect in c and c++
<prahmod> and i have also a good knowledge in vb and java.
<prahmod> talking to u truely i shifted to linux just a few week back
<prahmod> so i am trying to adjust man
<pwnguin> (I'm always a bit worried when people declare themselves perfectly knowledgable about a language, but for this it shall suffice)
<pwnguin> hmm
<prahmod> welll perfect means i have a quite good knowldge but not the whole sum
<pwnguin> heh, this is an odd definition, but im not here to quiz you
<prahmod> b frank man so lets get started
<prahmod> will you??
<pwnguin> im thinking;
<pwnguin> ok. so you're ok with programming but not quite ready to join in with the ubuntu kernel team's work
<pwnguin> http://kernelnewbies.org/ looks like a good site to learn more
<prahmod> no i don't mean that.well i am interested to join that group.but i think i should get prepared first
<pwnguin> indeed
<tallmtt> what is the harm in compiling a git kernel with "make && make modules_install" in ubuntu
<pwnguin> tallmtt: im thinking you might overwrite modules for a currently installed kernel
<tallmtt> That is what I'm worried about - I am getting errors using the make-kpkg (ubuntu way)
<pwnguin> tallmtt: did you see the link i pasted?
<tallmtt> kernelnewbies?
<pwnguin> openweekhardy
<tallmtt> pwnguin: going there now
<prahmod> pwnguin:can u give me some idea.from where should i get started so as to understand and able to write kernel in future
<pwnguin> well, I think a good first step is to be able to build and run a kernel
<pwnguin> theres a lot of configuration involved with the kernel, so its going to be a lot of reading
<Kano> if you know how to compile extra drivers ;)
<pwnguin> the next step is probably understanding how to use git to get source, diff source and get changelogs. then figuring out how the ubuntu kernel is built
<prahmod> compiling extra drivers? well till now i even don't know about compiling files in linux as i am a new user
<prahmod> can we go slowly
<pwnguin> prahmod: if you're not familiar with UNIX programming, your best bet is to write a hello world C project, then find GNU's hello world project
<pwnguin> and compare
<prahmod> how can i build a kernel and run it???
<pwnguin> prahmod: the kernel newbies website has that information
<pwnguin> http://kernelnewbies.org/KernelBuild
<tallmtt> pwnguin: Ok - I have been doing everything as is described but when typing "fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers" I get a lot of errors
<prahmod> so GNU is a compiler.is that?
<prahmod> got that link
<tallmtt> I am new to using git and only doing so because of a driver available from it for a wireless card
<pwnguin> tallmtt: pastebin some of the errors maybe?
<tallmtt> pwnguin: sure - http://pastebin.com/m41b2b0ac
<pwnguin> thats not good
<pwnguin> pastebin rt2x00dev
<pwnguin> or if you have a public gitweb that'd also work
<tallmtt> pwnguin: that is the driver I need also - the git is from rt2x00 for RaLink wireless cards
<prahmod> so should i dowload git-core???
<tallmtt> There is a public gitweb - hold on
<tallmtt> http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=summary
<tallmtt> Is that what you wanted?
<pwnguin> sure
<Kano> rt2800?
<pwnguin> so uh, thats a pretty busy git at the moment
<pwnguin> tallmtt: which commit do you have?
<tallmtt> pwdguin: I downloaded it yesterday
<pwnguin> there have been 8 patches since then
<tallmtt> Yeah - but the feature I need is already comitted and should be working
<pwnguin> except for the part where it isnt building
<tallmtt> :)
<prahmod> and later i need to download the git file.am i getting right???
<pwnguin> prahmod: #kernel-newbies on irc.oftc.net can help you a lot better than I can I think
<tallmtt> For background info: I have an rt61pci wireless card whose driver works in managed mode but i want master mode to use it as an AP
<pwnguin> tallmtt: so how did you piece this code together?
<pwnguin> just grabbed the whole thing from git?
<tallmtt> pwnguin: yes
<pwnguin> try updaing to the latest
<pwnguin> if that doesn't work, you probably want to take it upstream
<tallmtt> thanks
<pwnguin> did it work?
<tallmtt> no it didn't 
<tallmtt> pwnguin: thanks again for your help, I need to go right now - will try more later
<pwnguin> np
#ubuntu-kernel 2008-07-20
<F1l1p3> help
<F1l1p3> i just compiled the kernel
<F1l1p3> and i got a black screen after the boot
<F1l1p3> anyone??
<alex_joni> F1l1p3: does it finish booting?
<F1l1p3> yeah right before the login screen 
<F1l1p3> all get black
<F1l1p3> so i have to restart 
<F1l1p3> i get no msg just the screen got black
<alex_joni> F1l1p3: can you use Ctrl-Alt-F1 to get to a console?
<visik7> hi
<visik7> what's the command that you guys use to create the kernel package ? make-kpkg or dpkg-buildpackage ?
<F1l1p3> no i can`t use nothing
<F1l1p3> i got the sound that entered in the login screen
<F1l1p3> but it`s all black
<F1l1p3> and all it rest is me to restart the laptop
<alex_joni> if I build a new kernel (same ABI, almost no changes), would it be possible to use the old modules?
<visik7> alex_joni: just tring right now
<visik7> I'll tell you
<alex_joni> visik7: I use fakeroot debian/rules .. to build a kernel
<alex_joni> was wondering if anyone knows what gets tested for struct_module version matching
<visik7> I use this command
<visik7> CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic
<visik7> alex_joni: what are you patching ?
<alex_joni> visik7: rtai
<alex_joni> www.rtai.org
<visik7> I think it could broke the abi
<visik7> didn't it ?
<alex_joni> I already built a kernel which works, now I need to update it slightly
<alex_joni> and I wonder if all modules built for the old one still work with the new one
<alex_joni> vermagic from modules from both kernels look the same
<BenC> mjg59: ping
<BenC> alex_joni: if you have the old ABI in your build, it should check and tell you if anything changed (ABI check will fail)
<lamont> Jul 20 12:54:12 rover3 kernel: [  351.868666] /dev/vmmon[9916]: Task_Switch: Intel VT mode is in use by some other software
<lamont> how do I know what task I need to kill?
<lamont> interesting.  nuking the kvm package fixed it... I guess I'll have to figure out how to switch that with less of a crowbar
<alex_joni> BenC: it doesn't fail.. but loading an old module on the new kernel brings: [2214758.908354] rtapi: disagrees about version of symbol struct_module
<mjg59> BenC: Hi
<BenC> mjg59: Hey...this vt font saving patch we have, is it suitable to send upstream?
<BenC> alex_joni: if you are passing AUTOBUILD, the check isn't done
<BenC> alex_joni: and disagreement about struct_module means you have an ABI change, and you should use the new modules
<alex_joni> BenC: ok, thanks
<alex_joni> BenC: I used "DEB_BUILD_OPTIONS=parallel=2 NOEXTRAS=1 fakeroot debian/rules custom-binary-foo"
<BenC> oh, custom-binary does not get ABI checks
<alex_joni> aha, then that's probably the issue..
<alex_joni> there is an ABI bump, but I missed it ;)
<alex_joni> m'kay.. thanks for clearing it up
<BenC> mjg59: And the patch for "blank screen, only blinking cursor after console switch" patch...
<mjg59> BenC: It's a feature enhancement, but I don't see why not
<BenC> mjg59: on both counts?
<mjg59> BenC: The latter is a requirement for the former
<mjg59> BenC: Should probably be merged
<BenC> mjg59: ok, thanks
#ubuntu-kernel 2009-07-13
<billybigrigger_> Sarvatt, i don't know which webcam module you use...but things might be looking up for me, as i use the sonixj module....take a look here
<billybigrigger_> http://patchwork.kernel.org/patch/35294/
<billybigrigger_> hmmm seems even after a git pull those modules aren't touched
<billybigrigger_> -rw-r--r--  1 billybigrigger billybigrigger  71386 2009-07-11 15:45 sonixj.c
<billybigrigger_> :(
<Alocado> hello
<Alocado> i'm using karmic and have a problem booting the 2.6.31-* kernels, i get an error message like "ata1: illegal qc_active transition".. anybody who knows about this error?
<smb> Alocado, Not really much beyond the obvious (that it is from the disk subsystem) that it complains about some command ending in an unexpected way (probably should be active but is already inactive). I cannot say this helps, but it might be worth playing around with the libata options (e.g. libata.force=noncq). But if the problem persists, you should open a bug.
<Alocado> smb, ok, thank you
<Keybuk> morning
<Keybuk> just so you're aware, I don't think we've had any bug reports yet, but there's an inotify regression in 2.6.31
<rtg_> Keybuk, since an upgrade to Karmic my firewire disk mounts with the volume ID instead of /media/disk which it used to use. Is this expected?
<Keybuk> rtg_: /media/volume_id ?
<rtg_> Keybuk, /media/3fc0df0b-cf77-4f73-9b3f-fffd10f06147 (which looks like a volume ID)
<smb> rtg_, rather a uuid
<smb> ...if we say uuid to the numeric thingy and label to the textual one
<Keybuk> rtg_: that's a pitti bug
<maco> where do the CoD live?
<smb> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/
<maco> i cant figure out where to click on kernel.u.c to navigate there
<maco> smb, thanks
<smb> maco, np 
<maco> i386 fail to build today?
<smb> Hah, it even looks like the raw divide bug fix has made it upstream now. :)
<smb> maco, To me it looks like it has been build again
<maco> i only see amd64 builds
<rtg_> cjwatson, the bug that annoys me the most is when sshd hangs at the end of a transfer. Is that a known problem?
<JonDoe297> maco: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-07-13/ there?
<JonDoe297> oh, "current" one
<JonDoe297> sorry :)
<smb> Hm,though 13-07 should be current in my eyes...
<cjwatson> rtg_: I've never seen anything like that
<maco> oh...hmm that is a problem, isn't it?
<rtg_> cjwatson, it appears to be related to Karmic sshd. How would I debug it?
<smb> rtg_, The only thing close to it is ssh need much more time to complete. You think it is done but it isn't
<rtg_> smb, it appears that it never completes
<smb> maco, I try to look at it. It is
<cjwatson> rtg_: start sshd on a separate port with -ddd (will run it in the foreground, single instance, maximum verbosity); connect to it with ssh -vvv
<cjwatson> -p on both sides, obviously
<rtg_> cjwatson, ok. gimme a bit
<smb> rtg_, Do you know what usually links current in the mainline builds to the latest daily build? At least for today it is broken as it links to 2009-06-17 (one month in the past)
<rtg_> smb, dunno, I've not looked at it recently
<rtg_> cjwatson, Karmic '/usr/sbin/sshd -ddd -p 1027', Jaunty 'ssh -p 1027 -vvv 10.0.2.5', bails with an error message on the server 'No supported key exchange algorithms'.
<smb> maco, Ok, current fixed (at least for today)
<maco> thanks
<rtg_> cjwatson, nm, needed to start sshd as root
<cjwatson> I was just going to say that :-)
<rtg_> cjwatson, drat, it would work with debug enabled. I'll try starting the port 22 instance of sshd with -ddd enabled.
<rtg_> cjwatson, how annoying. I can't seem to get it to happen now. I'll continue to pursue it since it causes me a lot of problems with git updating and such.
<cjwatson> rtg_: wouldn't that be the sshd on kernel.ubuntu.com?
<cjwatson> or do you use git among local machines?
<rtg_> cjwatson, no, that works OK, I have an internal network of build machines that clone from a local repo
<cjwatson> I don't suppose any controlmaster stuff is going on?
<bjf> isn't there a wiki page for debugging sound problems?
<rtg_> nope, straightforward stuff. Used to work until I upgraded the git server to Karmic
<bjf> https://wiki.ubuntu.com/DebuggingSoundProblems
<bjf> anyone up for helping me debug a sound problem (lack of all sound is the problem, same on two systems)
<billybigrigger> after a git pull does make-kpkg clean up whatever i just pulled?
<billybigrigger> or can i run git pull && CONCURRENCY_LEVEL=3 time fakeroot make-kpkg --initrd -append-to-version=-billybigrigger-07.12 kernel_image kernel_headers kernel_source > make.log 2>&1
<rtg_> billybigrigger, you should be doing 'git fetch origin;git rebase origin' instead. 'git pull' does a merge and may do things you don't want
<billybigrigger> rtg_: ok thanks
<billybigrigger> billybigrigger@cabo:~/linux-2.6$ git fetch origin
<billybigrigger> billybigrigger@cabo:~/linux-2.6$ git rebase origin
<billybigrigger> drivers/char/vr41xx_giu.c: needs update
<billybigrigger> cannot rebase: you have unstaged changes
<rtg_> git checkout -f
<rtg_> git clean -f -d
<billybigrigger> fetch or rebase?
<billybigrigger> afterwards i mean
<rtg_> after checkout and clean, you can just rebase. you've already fetched.
<billybigrigger> Current branch master is up to date.
<billybigrigger> thats after rebase
<billybigrigger> so there's no changes?
<rtg_> billybigrigger, do a 'git log' and compare against the base repo.
<rtg_> or origin repo
<maco> are crack of the day built without kms support? and have any of you seen iwlagn go crazy on today's crack?
<Sarvatt> he has no local changes (outside of .config thats in .gitignore) and is just updating, why shouldnt he just pull?
<rtg_> maco, some of the wireless devs are complaining that iwl isn't working too well (across all models)
<maco> hm ok. ive got "cannot allocate SKB buffers" spamming in all my ttys from iwlagn
<maco> its also in top using quite a LOT of cpu
<rtg_> maco, dunno what the exact errors were. Perhaps you ought to drop a note to the wireless mailing list with a snippet from your log
<maco> wireless mailing list? link?
<rtg_> maco, linux-wireless@vger.kernel.org
<maco> thanks
<rtg_> maco, fyi, MAINTAINERS in the kernel tree generally has all that stuff
<maco> ok thank you
<xantian> Hello. my problem is Kernel 2.6.31* and compiling ... an know this ist devel staging .. who can help me?
<xantian> i can not compile nvidia latest driver and ralink rt2870sta from sources .. ah and xfi but xfi and ralink 'll support out of the box with blacklist 7 modules
<xantian> but i need nvidia driver
<xantian> google don't like me anymore
<xantian> :P
<xantian> thx i found solution
<shtylman> anyone willing to help me out with bug #398059
<ubot3> Malone bug 398059 in linux "system does not boot due to device-mapper error" [Undecided,Confirmed] https://launchpad.net/bugs/398059
#ubuntu-kernel 2009-07-14
<billybigrig> anyone know why i can't build the nvidia module?
<billybigrig> billybigrigger@cabo:~$ sudo dkms build -m nvidia -v 185.18.14 -k 2.6.31-rc2-billybigrigger-07.13
<billybigrig> Error! Bad return status for module build on kernel: 2.6.31-rc2-billybigrigger-07.13 (x86_64)
<billybigrig> *** Unable to determine the target kernel version. *** make: *** [select_makefile] Error 1
<billybigrig> no body can answer?
<jjohansen> smb: I have tested Jaunty on my machine now with suspend and hibernate kernel builds, no thermal problems.  But under 11.1 it goes into thermal shutdown
<apw> jjohansen, heh thanks for the testing there
<smb> jjohansen, that sounds good, yet unexpected. but thanks for testing :)
<Keybuk> apw: err, you didn't include the inotify patches I sent in the most recent kernel upload ?
<apw> Keybuk, hrm, tim actually put that upload together
<apw> ok tim said "i'll apply if they don't make it into -rc3" ... 
<apw> did you check if they made it in via mainline ...
<Keybuk> they aren't in mainline yet
<Keybuk> which is why I forwarded them
<apw> hrm
<apw> Keybuk, i'll look at them now
<apw> Keybuk, is there a bug for these regressions?
<Keybuk> apw: a bug?
<Keybuk> not in LP, I went directly to the upstream ;)
<apw> yeah a lp bug number?  if so i'll include it
<Keybuk> I can open a bug if you like
<apw> no need, just would use it if there
<apw> Keybuk, you need a test kernel for these?
<Keybuk> apw: no, just a release
<Keybuk> already tested Eric's patches for him
<apw> ok thanks
<apw> i think i am out of the country
<apw> in dublin.  need to confirm when i get back exactly
<Keybuk> ?
<apw> gah wrong channel
<apw> Keybuk, ok they are applied so they deffo make the next upload
<apw> will talk to tim about getting that to be soon
<Keybuk> apw: could we do an upload especially please
<Keybuk> without these patches, inotify is basically useless
<apw> i am sure we can, just want to touch with him to see if there is anything else urgent
<apw> will start preparing it
<tseliot> amitk: do you deal with input devices in the kernel?
<UnderSampled> hello
<UnderSampled> I get WARNING at /build/builddd/linux-2.6.28/kernal/smo.c:333 smo_function_mask+0x1d4/0x1e0()
<UnderSampled> Whenever I boot into 9.04, whether that mean into a live cd, the 'check disk for errors', or after upgrading 8.10 to 9.04 after a fresh install
<UnderSampled> oh, and the capslock and scrolllock keys blink at a constant rate
<UnderSampled> Any Ideas?
<amitk> tseliot: not specifically
<tseliot> amitk: I have a doubt on passing EVIOCGID to ioctl() and on using id[ID_VENDOR], id[ID_PRODUCT], id[ID_VERSION] to check the model of a touchpad
<tseliot> amitk: would it make sense to check id[ID_VERSION] to identify a specific model when id[ID_VENDOR] and id[ID_PRODUCT] are the same for all Synaptics touchpads?
<tseliot> note: I called ioctl(fd, EVIOCGID, id)
<tseliot> I would like to use it to add quirks to the synaptics driver
<rtg_> apw, by the way, there are 2 Karmic commits with an identical log message; 6325628641e58310d93acd8f0261a76752e38544 and 14b5433606289dbc5b6fd70ced11462f80e95003. How did the first one get there? It doesn't exist in Linus tree.
<apw> rtg_, i see the first one as a stable commit which we applied, and the second is a real upstream commit
<apw> i see that one in my linus tree too
<apw> i would guess it may have gotten reverted 
 * apw checks
<rtg_> apw, carried forward from Jaunty? It should have disappeared
<apw> yes, unless someone reverted the original upstreaming ... will check
<amitk> tseliot: I don't see drivers/input/mouse/synaptics.c having any ioctls
<apw> rtg, no by extreme bad luck it applied twice
<apw>         if (scan->channel_count == 0) {
<apw>                 IWL_DEBUG_SCAN(priv, "channel count %d\n", scan->channel_count);
<apw>                 goto done;
<apw>         }
<apw>         if (scan->channel_count == 0) {
<apw>                 IWL_DEBUG_SCAN("channel count %d\n", scan->channel_count);
<apw>                 goto done;
<apw>         }
<apw> looks benign
<apw> we can drop that one on the next rebase
 * apw reverts it in our tree
<rtg_> apw, it causes an error when IWL_DEBUGFS is defined.
<tseliot> amitk: I meant the Synaptics X driver. ID_VENDOR, ID_PRODUCT and ID_VERSION are defined in input.h though.
<apw> rtg_, yeah it looks like the number of params to IWL_DEBUG_SCAN has changed and its left behind
<apw> just revert it
<rtg_> apw, why not just rebase and drop the commit altogether? It'll avoid future conflicts
<apw> well i guess i should
<apw> yep, can do, after this upload?
<rtg_> might aswell do it now
<apw> ok
<UnderSampled> Could someone please help me trouble shoot>
<amitk> tseliot: you'll have to try it. But it seems like the model id is stored in the synaptics driver's private data structure
<tseliot> amitk: ok, thanks
<amitk> tseliot: http://lxr.linux.no/linux+v2.6.30/drivers/input/mouse/synaptics.c#L652
<amitk> and http://lxr.linux.no/linux+v2.6.30/drivers/input/mouse/synaptics.c#L167
<tseliot> amitk: it says "Encode touchpad model so that it can be used to set input device->id.version and be visible to userspace"
<mjg59> tseliot: What quirks do you want to add? Note that several cases where we'd like to add quirks (the Dell mini, for example) don't have any destinctive information in the vendor or ID fields
<tseliot> mjg59: I know how to prevent the cursor from jumping on the Dell Mini 10v: http://bugs.freedesktop.org/show_bug.cgi?id=21614
<ubot3> Freedesktop bug 21614 in Input/synaptics "Touchpad cursor jumps when two fingers are used" [Normal,New] 
<tseliot> mjg59: and since that code doesn't solve the problem on all touchpads I wanted to add a quirk for the Dell
<tseliot> and checking ID_VENDOR, ID_PRODUCT and ID_VERSION should be enough
<mjg59> tseliot: It's not
<mjg59> tseliot: You get identical values to the Eee
<mjg59> Sorry, not the Eee. Some Aspire Ones.
<tseliot> mjg59: you get identical ID_VENDOR and ID_PRODUCT because they are Synaptics but do you also get the same ID_VERSION?
<mjg59> Yes
<tseliot> oh
<tseliot> mjg59: so are you saying that quirks are not possible?
<mjg59> No, I'm just saying that you're concentrating on the wrong aspect of it
<tseliot> ok
<tseliot> any suggestions?
<mjg59> The ones that people are having problems with all appear to be Synaptics (as opposed to ALPS or Elantech) without two-finger detection
<mjg59> So you could possibly just key it off that?
<tseliot> mjg59: maybe. I need to check what my other Synaptics touchpads report.
<smb> mjg59, While you are around, might I abuse your time with another quirk question? In that case acpi_video...
<smb> I looked at a bug report where people had regressions with backlight control. From the acpi dump and the dmesg it looks clear that the problem is that the only acpi video device with _BCL defines a _ADR with a pci device id that does not exist. So with kernels before the check people got working backlight control (though it sounds strange) but with it they don't. 
<mjg59> What hardware is this?
<smb> mjg59, Are you aware of similar cases and how would be the chances for dmi quirks in that area? 
<smb> Acer 6920G
<mjg59> Does acer-wmi work?
<smb> no
<mjg59> Unfortunate
<mjg59> Got the bug number?
<smb> Pretty much. Yep, a sec
<smb> https://bugs.launchpad.net/bugs/333386
<ubot3> Malone bug 333386 in linux "Cannot change brightness with 2.6.27-11+ kernel" [Medium,Confirmed] 
<smb> mjg59, I would have tried with an external DSDT file but iasl explodes more or less when trying to recompile
<mjg59> Oh, ugh. It's one of those bugs where unrelated issues have appeared.
<smb> mjg59, Yeah, its sometimes hard to keep "my backlight does not work" outside
<mjg59> smb: I think the user's doing something wrong when trying to use acer-wmi
<smb> mjg59, But in the end I concentrated on the Acer and saw that _ADR for GFX0 is 0002000 while the video device seems to be 01.0
<mjg59> I can't see any way he can get permission denied if he's actually running as root, which makes me think he's doing sudo echo foo >brightness
<mjg59> Which won't work
<mjg59> Oh, I see, he did finally check that
<smb> mjg59, It was part of my learning curve to find out what regressed as well. 
<mjg59> Is he using the binary nvidia drivers?
<mjg59> If so, brightness control gets more complicated
<mjg59> Because they disable the SMI access that the legacy paths use
<mjg59> The smartdimmer pins may be hooked up
<smb> mjg59, I am not 100% sure. But as he says he has a working backlight when using the kernel just before we pulled the pci checking patch and there he had gfx0 I assume that case is good
<mjg59> It may have worked by accident
<smb> It seems at least some sort of accident as the acpi information is so incorrect. I can give him a recent kernel without the check to compare. But the question is how to move on
<mjg59> The machine will come in two forms - integrated Intel and discrete Nvidia
<mjg59> The same DSDT is used on both
<smb> The next kernel update will get that laptop back into that state (unless nouveau is better at controlling the backlight without acpi support)
<mjg59> The ACPI information appears to be for the Intel device, not the nvidia one
<mjg59> novueau will drive the backlight if the smartdimmer pins are hooked up
<mjg59> Assuming recent enough nouveau
<mjg59> But he's using the binary nvidia drivers
<smb> Somehow this accidental thing looks a bit like that T61(?) case 
<mjg59> Yes
<mjg59> The Radeon code on the T61 happens to work on the Intel hardware as well
<smb> The whole information obviously is for the wrong device but some way it works when being poked at
<mjg59> But the correct approach is to use the opregion code in recent i915
<mjg59> That's why the patch didn't get merged until the opregion stuff was added
<smb> So here is the other direction, the nvidia device seems to react on the intel defined device. The nvidia device in acpi does not define any backlight control, so the only reasonable way would be to have the nvidia driver doing something (if possible) or a bios update (guess unlikely).
<mjg59> Correct
<mjg59> Unless nvidia have a sideband brightness interface
<smb> Even worse as that laptop seems to come up with extremely dimmed backlight. :/
<mjg59> Which is possible, I haven't figured out what all of their ACPI methods do yet
<smb> Hm, a sideband brightness interface? Would that be visible in the acpi code? I am slowly digging my way into that area...
<mjg59> Uh.
<mjg59> I see a _BCL and _BQC in his DSDT for the nvidia device.
<mjg59> Under PEGP
<mjg59> And again under NVGA
<mjg59> One of those ought to be bound
<smb> mjg59, Arg, sorry. I believe the problem was _DOD _DOS
<mjg59> Those shouldn't be required for brightness changing
<mjg59> They're just the display switch hotkeys
<mjg59> Let me look at the kernel
<mjg59> Right, they're only under the Intel one
<smb> GFX0 is the only one defining thoise. and acpi_video check for them to decide this is a video device
<mjg59> Sigh.
<mjg59> Ok, acpi_video needs fixing not to have that requirement
<smb> o some other values which are not there
<mjg59> But I can see why it would make that assumption
<smb> I think it was three different set of methods. If any of those sets is there the check is good
<mjg59> Yeah, and this doesn't have any of them
<smb> But _DOD, _DOS was the only set present for any device
<smb> So GFX0 (the intel) is the only candidate for acpi_video
<mjg59> Yeah
<mjg59> But the spec doesn't actually require that
<mjg59> It should also check the children and see whether they have any backlight control methods
<smb> So basically backlight control gets somewhat independent of the video device itself (if that is formulated understandably)
<mjg59> /kind/ of
<mjg59> What's weird is that EVGA and NVGA both seem to have the same addresses
<mjg59> Oh, wait, I think I see a minimal patch
<smb> hasn't NVGA adr zero
<mjg59> So does EVGA
<mjg59> They're both children of PEGP
<smb> Oh, I see
<mjg59> ANyway
<smb> Hm, yeah and _DOD is there for several devices, only _DOS is there once
<mjg59> Does http://www.codon.org.uk/~mjg59/tmp/acpi_switch.diff fix it?
<smb> I'll create a kernel with it and we will see
<smb> I haven't got the hardware, so I need to put it into the bug report
<mjg59> As long as that gets it recognised it looks like it'll work - the code is identical
<mjg59> So I think I'll just submit that upstream anyway
<smb> mjg59, Thanks for now. Somehow I missed that _DOD is present for all devices and might be used as an alternative.
<mjg59> Ok
<mjg59> Let me know if it works
<mjg59> Note that it probably won't do anything for any T61 people
<smb> mjg59, Sure. Yeah, probably this setup is different. But for the time being we can fix those with acpi_backlight=vendor and thinkpad-acpi backlight=1
<mjg59> T61 should work fine upstream
<mjg59> You need the i915 opregion support code
<smb> Oh, likely yes. I was more referring to Jaunty which is missing that but has the check slipped in
<amitk> NOTICE: Upcoming Ubuntu Kernel Team Meeting - Tuesday, 14th of July - 17:00 UTC i.e. Today, in about an hour in #ubuntu-meeting
* amitk changed the topic of #ubuntu-kernel to: "Home: https://wiki.ubuntu.com/KernelTeam/ || Karmic Kernel Version: 2.6.31 || Ubuntu Kernel Team Meeting - Tuesday, 14th of July - 17:00 UTC"
<bjf> amitk, that's in 2 hours right?
<amitk> bjf: err, right.
<amitk> NOTICE: Upcoming Ubuntu Kernel Team Meeting - Tuesday, 14th of July - 17:00 UTC i.e. Today, in about 2 hours in #ubuntu-meeting
<amitk> :)
<UnderSampled> can someone help me with this?
<UnderSampled> http://yfrog.com/5fdumpij
<tseliot> mjg59: there must be a bug somewhere (in the kernel?) as the Synaptics driver (when testing BTN_TOOL_DOUBLETAP) reports that the touchpad of the Dell Mini 10v multi-finger detection but, as evtest shows, it's not true
<tseliot> s/multi-finger/has multi-finger/
<mjg59> tseliot: Can you put dmesg somewhere?
<UnderSampled> hello hggdh
<hggdh> UnderSampled: hello
<tseliot> mjg59: http://pastebin.ubuntu.com/218063/
<UnderSampled> I just tried the alternate install disk, but it does the same
<mjg59> tseliot: What kernel version are you looking at?
<tseliot> mjg59: Jaunty's i.e. 2.6.28-11-generic
<mjg59> Looks like it was fixed in .29
<UnderSampled> hggdh, you said that it hasn't shown all of the information. It freazes sometime during boot, usually either before anything is displayed or with the warning somewhere on the page
<hggdh> UnderSampled: have you looked at https://wiki.ubuntu.com/DebuggingKernelOops?
<UnderSampled>  no
<tseliot> mjg59: ok, thanks, I'll try with .29 then
<hggdh> UnderSampled: and, genrically, at https://wiki.ubuntu.com/DebuggingProcedures#Kernel
<UnderSampled> hggdh: just above the warning, it shows "Kernel panic - not sycing: fatal exception in interupt"
<UnderSampled> then it says"---------------[   cut here   ]----------------"
<tseliot> mjg59: do you happen to have a link to the exact commit?
<mjg59> e42b6646a8298fe06a33a0f68dab661335f5db6e
<tseliot> mjg59: thanks a lot. BTW the quirk works now with 2.6.29
<mjg59> Cool
<rtg_> Keybuk, linux 2.6.31-3.19 uploadedwith your fsnotify and inotify patches
<tseliot> smb: would it be possible to have that commit ^^ in Jaunty? The diff is very small: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/input/mouse/synaptics.c;h=865fc69e9bc39e8ef81b213722e572c95917fb0e;hp=d349c4a5e3e84488a4e812e33e6e547aac4d97e7;hb=e42b6646a8298fe06a33a0f68dab661335f5db6e;hpb=cec87e38e92cdfe86678ca2a5c29c38d05127601
<Keybuk> rtg_: thanks
<smb> tseliot, the patch itself looks sensible. I guess we need to get together a good reason for the impact to get a SRU
<rtg_> cjwatson, I've narrowed down the Karmic sshd annoyance to a relatively simple scenario. The first time after boot sshd fails to fully release a connection when the client is shutting down. If you stop/start /etc/init.d/ssh then all works fine thereafter. I'll see about instrumenting the initial invocation to get some debug.
<cjwatson> odd - ok
<Sarvatt> thanks TheMuso, will finally be able to install from a powerpc alternate cd again without starting from intrepid and upgrading all the way -- [Config] Enable CONFIG_BLK_DEV_IDECD on powerpc
<amitk> ********* 15 min warning for meeting ******************
<JFo> hi ogasawara 
<JFo> sorry I haven't been available for a bit
<JFo> I'm still finishing up moving my household
<JFo> :-/
<ogasawara> JFo: no worries
<JFo> I saw your e-mail, but I have yet to act upon it
<JFo> will do so this evening
<ogasawara> JFo: great, let me know if you have any questions
<JFo> I certainly will, thanks so much for the feedback
<JFo> <-trying to be a better bug triager :)
<Kano> hi apw , you added aufs again? i really thought i had to do it again myself. what did change your mind?
<amitk> Kano: vfs mounts still has several bugs that won't get fixed in 2.6.31
<Kano> funny, i am patching aufs2 since ages now on my own...
<Kano> fuse-unionfs was really slow as hell ;)
<Dinh> hello manjo?
<manjo> Dinh, hello sir
<manjo> Dinh, did u get my mail with the location of the kernel ? 
<Dinh> cool...i still can't build it...what was your build command?
<Dinh> yes, can you also put the zimage file there as well?
<manjo> Dinh, k will do
<Dinh> manjo: brb
<manjo> Dinh, done
<manjo> Dinh, I did a cross compile using the compiler from codesourcery... make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-  you need to have the cross gcc in ur path
<manjo> Dinh, http://www.codesourcery.com/sgpp/lite/arm/portal/release858
<manjo> Dinh, brb bio break :)
<Dinh> manjo: i did that cross_compile settting...let me try the zimage with the system.map file and look at the log_buf
<manjo> Dinh, k
<Dinh> manjo: kernel panic in mxc_timer_init()
<Dinh> let me try rebuiding again
<manjo> Dinh, where in mxc_timer_init() ? 
<manjo> we know that the kernel does not boot 
<manjo> Dinh, can you paste the panic message ? 
<Dinh> manjo: i have to do a memory dump...1 sec
<Dinh> manjo: Backtrace (mxc_timer_init+0x0/0x4c) from (mx51_babbage_timer_init+0x0/0x4) from (time_init+0x1c/0x24)
<manjo> Dinh, in one of my attempts to compile the kernel I got an error message ... include/linux/jiffies.h:257:31: error: division by zero in #if
<manjo> but it went away later when I used the config options i pointed you to
<Dinh> manjo:  here's my cross_compile path   /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- 
<Dinh> when do  a build:  >make ARCH=arm CROSS_COMPILE=${CROSS_COMPILE}
<Dinh> I get this error:  scripts/mod/modpost.c: In function `match': scripts/mod/modpost.c:699: parse error before `const' 
<manjo> did u use the config options like I suggested ? 
<Dinh> manjo [yes]
<manjo> Dinh, that is strange.. compiles for me 
<manjo> which cross compiler are you using ? from codesourcery ? 
<Dinh> manjo[anyways..the crash is coming from mx51_babbage_timer_init() in /arch/arm/mach-mx51/mx51_babbage.c
<Dinh> manjo [ the standard arm compile gcc compiler from Redhat]
<manjo> Dinh, so the crash must be in timer_clk = clk_get(NULL, clk_timer); in arch/arm/plat-mxc/time.c but i dont know why... 
<manjo> Dinh, my compiler is arm-none-linux-gnueabi-gcc-4.3.3
<manjo> Dinh, can you try the compiler from http://www.codesourcery.com/sgpp/lite/arm/portal/release858 ? 
<manjo> just get the tar package and untar it in ~/bin something like that .... 
<Dinh> manjo: yeah..let me work on that...i there's some changes in mxc_timer_init function in your tree that I'm not sure about, I'll email you what we have in ours...
<manjo> Dinh, ok sounds good 
<manjo> what is ur tree based on ? 
<manjo> kernel version ? 
<Dinh> manjo[2.6.28...but I'm not sure why you need these changes for a platform file][
<manjo> Dinh, note that the kernel you downloaded is 2.6.31 based
<manjo> Dinh, with patches from FS
<Dinh> manjo: yeah, i know...i'm not sure about the changes in low-level platform timer code
<manjo> Dinh, k
<Dinh> wait...i sent you the wrong stuff...the crash is in mxc_timer_init...i sent you code for mxc_clocks_init
<Dinh> manjo: i think i know why the crash is happening...
<manjo> Dinh, u rock!
<Dinh> if you look at /arch/arm/plat-mxc/time.c and the function mxc_timer_init(), I don't think timer_base is getting the correct memory address
<manjo> Dinh, I guessed that .... see my previous comment .. 
<manjo> Dinh, so do we know why address is bad ? 
<Dinh> manjo: how come there is a case for CONFIG_ARCH_MX5 ? only MX1, MX2 and MX3?
<Dinh> i mean no case for MX5?
<manjo> hmm right 
<manjo>  } else
<manjo>                 BUG();
<manjo> Dinh, that is your code correcct ? :) 
<Dinh> manjo: no, i just sent you our code
<manjo> Dinh, ok looking .. 
<manjo> Dinh, do you want me to rebuild and re-upload .. ? 
<Dinh> yeah sure..
<manjo> Dinh, rebuilding now 
<zetanuxi> how offten does a kernel completly disappear from grub? =/
<manjo> Dinh, some pieces missing still ...int i =3D 0, j =3D 0, reg;
<Dinh> manjo: downloading the new tool chain now
<manjo> error: invalid suffix "D" on integer constant
<Dinh> manjo: i made a mistake...put back your original version of mxc_clocks_init(), you don't need to change that...
<manjo> Dinh, heh
<zetanuxi> if a kernel option disappears from grub, do i need to do a clean install to restore it?
<manjo> Dinh, do we know why we dont have CONFIG_ARCH_MX5 in arch/arm/plat-mxc/time.c ? 
<Dinh> manjo: i have no idea
<manjo> u have that in ur tree ? 
<manjo> Dinh, in the .config CONFIG_ARCH_MX51=y
<manjo> so in mxc_timer_init() we will aways hit BUG(); in the CONFIG_ARCH_MX51 case... so it needs a similar entry  in that file 
<manjo> #ifdef CONFIG_ARCH_MX51
<manjo>                 timer_base = IO_ADDRESS(GPT1_BASE_ADDR);
<manjo>                 irq = MXC_INT_GPT;
<manjo> #endif
<Dinh> yep..in the past we used CONFIG_ARCH_MX1 , 2, 3...but we have changed to use more specific names...CONFIG_ARCH_MX51
<manjo> let me add that bit and build you a kernel 
<Dinh> and the TIMER_BASE define is defined in your board-mx51_babbage.h,   in our tree it was mxc_timer.h
<Dinh> in /plat-mxc/include/mach/
<manjo> hardware.h 84 #define cpu_is_mx51()
<Dinh> yeah, so add code to get the TIMER_BASE and it should be good to go
<manjo> building now 
<manjo> Dinh, called seng ? 
<Dinh> i haven't...i'll call hime now...i'm extracting the new build tools.
<manjo> Dinh, cool
<Dinh> email me his # again? the previous # didn't work
<manjo> k
<manjo> Dinh, you should get in ur sms
<Dinh> got it
<manjo> that is my google voice sms service 
<manjo> Dinh, can you try with the new kernel I uploaded to my ppl page ? 
<manjo> it better fscking boot :)
<Dinh> manjo: i wouldn't count on it...but we'll get past the timer crash...
<manjo> Dinh, yeah me too... I see CONFIG_ARCH is tons of places ... 
<Dinh> manjo: just tried the image in /try1 folder...still crashes
<manjo> Dinh, no
<manjo> not in try1
<manjo> that is the old stuff
<Dinh> oh ok...good
<Dinh> in the main folder?
<manjo> yes sir
<manjo> phewww
<Dinh> manjo: hmm...failure is still in mxc_timer_init
<Dinh> let me get my build going...
<manjo> same place  ? 
<Dinh> i think so
<manjo> k
<manjo> Dinh, ur mxc_timer_init() code looks a lot less simpler with no cases 
<Dinh> manjo: yes, because it gets the TIMER_BASE from the correct hw file...i'm not sure why you guys need those changes...
<manjo> k
<Dinh> manjo: ok, I'm finally building
<manjo> Dinh, cool ... 
<manjo> Dinh, you think you will be able to get the jtag home for tomorrow ? 
<manjo> my board should show up tomorrow at home 
<Dinh> yeah, i'll bring my whole setup home today...
<manjo> heh cool! 
<manjo> cant wait to see that jtag ... 
<Dinh> manjo F*** still getting an error:  
<Dinh> drivers/hwmon/isl29003.c: In function 'isl29003_i2c_remove': 
<manjo> Dinh, how about this ... you bring the setup home ... I can swing by later this evening with some thing to drink 
<Dinh> i'm going out to dinner..won't be back til 9 or so...
<Dinh> you can come by tomorrow morning
<manjo> ok I need to go to the hospital 
<manjo> tomorrow we can hash this out .. 
<Dinh> ok, i'll send out a quick status...
<manjo> 9am sounds ok ?
<manjo> Dinh, I should be up around 7am buzz me on this channel when you are ready tomorrow 
<manjo> Dinh, did u cd debian/config and then cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 > ../../.config ?
<manjo> if you do that you should not see that build failure 
<Dinh> yeah, i did that...i get a different error when i do that...let me start over
<Dinh> is cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 > ../../.config     1 whole command? or is it cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 > ../../.config, then cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 > ../../.config
<manjo> no one command
<manjo> you need to cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51  into your .config
<Dinh> ah ok...got it...i was doing it as 2 commands earlier...i think its working now
<manjo> ok
<Dinh> sure..come by tomorrow at 9...irish coffee?
<manjo> in the morning! 
<manjo> ok by me :) 
<manjo> I can bring some einstin bagel
<Dinh> nah..i got tons of bagels...
<Dinh> manjo: sweet..it finished building
<manjo> Dinh, cool... 
<manjo> Dinh, does it have the fix that I put in earlier ? 
<Dinh> not yet..set me a patch for what you put in
<manjo> ok
<manjo> Dinh, offing u a patch on irc 
<manjo> offering 
<Dinh> how do i accept it?
<manjo> Dinh, I emailed it to you as attachment 
<manjo> never mind the irc transfer
#ubuntu-kernel 2009-07-15
<manjo> Dinh, logging off and off the hospital ... see you tomorrow
<Dinh> ok..have a good one
<ikepanhc> hi cjwatson
<cjwatson> ikepanhc: can I help you?
<ikepanhc> Hi cjwatson
<ikepanhc> Please give me a minute
<ikepanhc> I am working on bug 360966
<ubot3> Malone bug 360966 in linux "bnx2x missing in initrd for install media" [Medium,In progress] https://launchpad.net/bugs/360966
<ikepanhc> And have some question about the installer
<ikepanhc> I checked for the udeb, we dont have that module
<ikepanhc> I think we could have the module after add to debian/d-i/modules/nic-module
<ikepanhc> is that ok?
<cjwatson> ikepanhc: yes, that's what Leann said and she's correct
<cjwatson> d-i does not rely on update-initramfs
<cjwatson> so looking at that is a red herring
<ikepanhc> Yes, I have tested it
<ikepanhc> but since jaunty has been release, shall we modify as Jaunty SRU?
<ikepanhc> I ask because we have the cdimage already
<cjwatson> well, you're correct that we won't be issuing updated CD images
<cjwatson> however, this bug does not affect CD images, only netboot installation
<cjwatson> s
<cjwatson> and we do update the initrds for those from time to time
<ikepanhc> so, it is necessary for a Jaunty SRC, since the netboot image will rebuild
<ikepanhc> s/SRC/SRU
<ikepanhc> and the final one, we still need to check the module dependence.
<ikepanhc> I notice that bnx2x depends on libcrc32
<ikepanhc> Is that correct?
<cjwatson> ikepanhc: I have no idea, that's your department
<cjwatson> kernel-wedge will refuse to build if things aren't right there ...
<ikepanhc> cjwatson: thanks. I think the dependence shall be cared
<ikepanhc> cjwatson: another question, how do we test for it if we have made the udeb?
<ikepanhc> eh
<ikepanhc> cjwatson_: another question, how do we test for it if we have made the udeb?
<cjwatson> 10:29 <ikepanhc> cjwatson: another question, how do we test for it if we have made the udeb?
<cjwatson> 10:29 <cjwatson> if libcrc32 is already in some other udeb, it may be necessary to arrange for there to be some common udeb that contains it that both nic-modules and the other one depend on
<cjwatson> 10:30 <cjwatson> test for what?
<cjwatson> 10:30 <cjwatson> you mean libcrc32c, BTW
<cjwatson> 10:30 <cjwatson> which is apparently already in crypto-modules
<cjwatson> so this is actually slightly complicated
<ikepanhc> cjwatson: I download the netboot.tar.gz. there is only a initrd.gz inside
<cjwatson> ikepanhc: testing: check whether bnx2x shows up in 'dpkg -c nic-modules...udeb' :-)
<cjwatson> what did you expect to be in netboot.tar.gz? :-)
<ikepanhc> ah? I have some misunderstanding?
<cjwatson> well, I guess you must do, what did you expect it to contain?
<ikepanhc> I saw kernel image and initrd in netboot.tar.gz
<cjwatson> netboot.tar.gz actually contains initrd.gz, a kernel image, and a bunch of pxelinux setup stuff
<cjwatson> its purpose is that it's a convenient thing you can untar onto a pxe server and boot from
<cjwatson> but that isn't really particularly relevant to this bug
<cjwatson> the simplest approach to cope with libcrc32c being in multiple udebs would be to edit debian/d-i/package-list to make nic-modules depend on crypto-modules
<ikepanhc> This is what I am thinking, seems a wrong thought, we will download .deb after booting the kernel in netboot.tar.gz?
<cjwatson> it's not particularly elegant, but it would do the job
<cjwatson> ikepanhc: um, no ...
<cjwatson> ok, this is a brief sketch of how d-i works
<cjwatson> the initrd is built up (when building the debian-installer source package) from a bunch of udebs
<cjwatson> including, relevantly, the udebs that are spat out as part of the kernel build process
<cjwatson> now, not all the udebs go into the initrd - only those that are needed to boot the installer
<cjwatson> the installer knows how to fetch more bits of itself at run-time, using a similar sort of approach to apt and dpkg, although it doesn't actually use apt or dpkg directly
<cjwatson> this is what's happening when you see it "Downloading installer components"
 * ikepanhc reading
<cjwatson> later on, after partitioning, the installer constructs the real installed system on disk, and at *that* point it downloads .debs
<cjwatson> but that's well after stuff like network configuration, for which it needs the appropriate modules to be available in udeb form
<cjwatson> if you want a full paper on the subject, which talks about a lot of stuff beyond what you actually need here, see http://d-i.alioth.debian.org/doc/talks/debconf6/paper/
<ikepanhc> cjwatson: thanks very much, reading it.
<ikepanhc> cjwatson: and bnx2x need to work with its firmware, so, we also need to copy the firmware image?
<cjwatson> yes
<cjwatson> same way as it's done for bnx2
<ikepanhc> Thanks, go to read the flow of installer :)
<cjwatson> is it OK to remove the old linux-backports-modules-2.6.30 source package from karmic now?
<cjwatson> we have 2.6.31 ...
<cjwatson> rtg_: oh, good morning. Is it OK to remove the old linux-backports-modules-2.6.30 source package from karmic now? We have 2.6.31 ...
<rtg_> cjwatson, definitely
<cjwatson> good-oh
<apw> smb, does your aspire wireless work ok on boot on karmic kernels ?
<smb> apw, yes
<smb> apw, The guy you see on skype right now uses it
<smb> apw, I assume you look at a bug. Which driver is being used?
<apw> bug #395565
<ubot3> Malone bug 395565 in linux "atheros wifi not working with kernel 2.6.31-1" [High,Incomplete] https://launchpad.net/bugs/395565
<apw> it atheros
<smb> apw, I use ath5k and believe there have been ath_pci before.
<apw> it seems like the key and the wireless enable itself are two rfkill things not one
<apw> tail /sys/class/rfkill/*/state
<apw> what does that say on yours
<smb> 1
<apw> same here
<apw> which means UNBLOCKED
<apw> those guys have two separate controls
<smb> I am not sure the real rfkill is detectable for the OS there
<smb> I usually get the effect of just timing out when I toggle the rfkill. It is all done in the hw itself
<apw> hrm ... its all a big complex 
<apw> network manager has lost the ability to know if rfkill is enabled
<apw> as the /sys files changes name with the new rfkill framework
<apw> hit the botton and do that tail and see if it goes to 0 or 2
<smb> I just did and it stays at 1 as I expected
<apw> thanks for testing
<smb> apw, I believe nm cannot do much there. To it it must look just as a loss of connection. And indeed it starts trying to connect and fails, wants the passphrase again... bla. After toggling again all is ok
<apw> smb, yeah you are simply different from these guys ... 
<smb> apw, Well if I look at it, those are all sorts of Acer. And we know there is acer-wmi doing soft-rfkill as well.
<smb> Only the Aspire One is excluded as it does not behave anyways
<apw> yeah via pcix hotplug, gah
<lool> Hey folks
<lool> is there a list of recommended/required kernel options for an Ubuntu userspace?
<lool> e.g. udev needs inotify to work
<apw> not that i know of no, when building kernels like mainline i use the ubuntu config as a seed
<rtg_> lool, 2.6.31-3 has some inotify regression patches
<lool> rtg_: What I'm asking is whether there's a place which documents which options MUST be turned on or SHOULD be turned on for an Ubuntu base install to boot and work decently?
<lool> apw: Okay, thanks
<rtg_> lool, oh, now that I couldn't tell you off the top of my head
<lool> It's ok; it would have been handy but I'll just fix stuff as I hear it's borkne
<rtg_> lool, is borkne French for broken?
<lool> rtg_: I usually typo brokne to make it clear that's it's borken
<rtg_> lool, I can't help but admire your technique :)
<rtg_> smb, you gonna create a Jaunty topic branch for the Freescale patch set?
<smb> rtg_, Yes
<smb> rtg_, Though not only limited to the freescale set
<rtg_> smb, an ARM specific topic branch then
<smb> rtg_, Right.
<smb> rtg_, Is there a specific reason you ask?
<rtg_> smb, just griding through the k-t list emails.
<rtg_> grinding, evenm
<smb> Ah, ok. I got a preview of it up at my jaunty git tree (branch arm)
<rtg_> smb, is it creating a new package name?
<smb> rtg_, No, not so far as I was told it would not get published by uploading it to the usual buildds
<rtg_> smb, its for OEM builds only?
<smb> rtg_, Something likely. The agreement was something like we currently do for the mainline builds would be sufficient. Not that I still feel completely confident this is the final decision
<smb> rtg_, Should we get different requirements the branch can be changed to name the package differently
<rtg_> smb, I think it should have a different package name from the beginning, just to ensure there is never any confusion
<smb> rtg_, Well, there is the same confusion potential with the netbook branch
<rtg_> smb, wherein we have a somewhat formal agreement with the OEM team that the LPIA branch will always be compiled on their buildds and stored on their archive. We have no such arrangement with the mobile team.
<smb> rtg_, Shouldn't we then rather come to an arrangement with the mobile team before going into changing the package name?
<smb> rtg_, It actually would make me feel better when we knew that they know how the usecase will be, to be honest
<rtg_> smb, given that they don't have their own archive or buildd infrastructure, I'd just as soon distinguish packages by adding 'ARM' or something to the package name. 
<smb> rtg_, The release adds an arm similar to what the netbook branch does
<rtg_> smb, thats hard for me to know since their is no topic branch in the main repo for me to look at.
<smb> When I spoke with ogra yesterday, his take was that they just need a known place where they will put resulting debs to integrate into images
<smb> rtg_, That can be solved: http://kernel.ubuntu.com/git?p=smb/ubuntu-jaunty.git;a=shortlog;h=refs/heads/arm :)
<apw> rtg_, also we use a different series name, so if it was uploaded to the main archive it would break (netbook tree)
<apw> Keybuk, when we were talking about module probes in initramfs, did we conclude they were effectivly sequential and blocking
<Keybuk> apw: not sure what you mean?
<smb> apw, Hm, the series name is not changed, yet. But it sounds like a good safety switch
<apw> when we were talkig about loading firmware in initramfs, the issue there was that the hung the modprobe
<apw> in the initramfs script which was loading the driver in question and it was hung cause no udev
<Keybuk> oh, right
<Keybuk> yeah udev waits to settle in the initramfs
<apw> right so if we load something in initramfs and its slow we block boot by the slowest oneb
<apw> one
<apw> so i think that may be what is making all these floppy missing boots slow
<apw> since you added the mod alias, fd is loading in the initramfs  and handing for 1 min
<apw> and holding boot thereby
<apw> i am suspecting if we just stop it getting onto the initramfs life might be ok
<Keybuk> that makes sense
<apw> thanks ... will have a look at that
<apw> Keybuk, we don't support root on floppy do we?
<Keybuk> nope
<Keybuk> can't see how that work work <g>
<Keybuk> iz a wafer thin root filesystem
<apw> just one sir?
<Keybuk> "Please insert Ubuntu disk 519,214"
<apw> Keybuk, any idea what decides that floppy would be in the initramfs
<Keybuk> it's probably hardcoded
<rtg_> apw, isn't there a module list somewhere
<rtg_> ?
<Keybuk> though it's not in the initramfs
<Keybuk> weird
<apw> yeah but i don't see floppy on it yet it is in  my initramfs
<Keybuk> I think we add everything from block
<apw> Keybuk, yep thats the one ... thanks
<manjo> amitk, apw we found that the clock sourece bits are not set right for mx51
<manjo> amitk, making some progress now 
<apw> that 'wait' should be made more like
<apw> for (x=0; foo != jiffies; x++)
<apw>  if (x == 100000)
<apw>     printk "STILL WAITING!!!!"
<amitk> manjo: in clock.c?
<manjo> yeah
<amitk> I wonder how that changed from the original code
<amitk> unless some parent clock changed
<manjo> so you need to set certain bits in the MX51 cpu if you need to get the clock working right
<manjo> the code is setting for mx3 and not for mx51
<manjo> now were are figuring out the bits that need to be set 
<manjo> so there is some missing code for mx51
<amitk> manjo: are you looking for cpu_clk? or one of the pll clocks?
<manjo> the bits that need to be set ... for the cpu_clk (GPT)
<manjo> pll is turned on for sure
<amitk> manjo, line 1426 in arch/arch/mach-mx51/clock.c ?
<manjo> arch/arm/plat-mxc/time.c ?
<manjo> ignore that ? 
<manjo> you will see code for 1 2 3 
<manjo> and not for 51
<amitk> manjo: arch/arm/plat-mxc/time.c is definitely incorrect. I am not sure why bjf added the #ifdef CANONICAL in timer_init there.
<amitk> bjf: morning. Can you comment on 785269a99fae2e6ffab65efaaaab2b6475867d6e
<bjf> amitk, just a sec ...
<amitk> manjo: bjf: Got to step out for a bit. Be back in 30-40 mins.
<pgraner> apw: I seem to have found a regression between Intrepid and Jaunty
<pgraner> smb: ^^^^^^^^^
<apw> only one?
<amitk> bjf: I don't see mxc_timer_init() #ifdef'ed CANONICAL in jaunty FWIW.
<pgraner> apw: I can't get past this one to get to anything else :-)
<apw> what you find
 * smb slaps apw
<bjf> amitk, the function signatures changed
<pgraner> apw: Dell Inspiron 2650 hangs on boot
<smb> But yeah, there seem to be a few
<pgraner> apw: if I drop back to the Intrepid kernel it boots fine
<smb> pgraner, How far do you get?
<pgraner> apw: booting in rescue mode http://people.ubuntu.com/~pgraner/IMG00160-20090715-1115.jpg
<pgraner> apw: it will sit there forever
<apw> got a dmesg from a working boot?
<pgraner> apw: I can get one
<smb> Probably best lets have a bug report to accumulat info
<pgraner> apw: didn't know if you wanted a bug or if you had seen this before
<pgraner> smb: bug inbound
<smb> pgraner, Ok, I can't recall something like that
<rtg_> pgraner, try booting with pci=noacpi?
<tseliot> smb: I've just filed an SRU about the patch for touchpads: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/399787
<ubot3> Malone bug 399787 in linux "The kernel shoud set BTN_TOOL_DOUBLETAP and BTN_TOOL_TRIPLETAP only if the touchpad supports them" [Undecided,New] 
<smb> pgraner, Could you also take a photo of the hang with normal boot but "quiet splash" replaced by debug?
<smb> tseliot, Can you post that request to the kernel-team mailing list?
<smb> tseliot, preferably with the patch attached
<pgraner> rtg_: worked with pci=noacpi
<tseliot> smb: sure
<bjf> manjo, yo!
<rtg_> pgraner, also try 2.6.31-3
<rtg_> without the noacpi option
<pgraner> rtg_: ok give me a few mins
<smb> tseliot, thanks. 
<pgraner> rtg_: I got caught by the you need to fsck since its been 28 boots with out one.... hell
<smb> rtg_, Unfortunately noacpi even helps in acpi unrelated cases *sigh*
<rtg_> and without splash you can't stop it
<rtg_> smb, indeed, but it is a clue. 
<smb> rtg_, sure
<tseliot> smb: ok, done. Thanks
<amitk> manjo: bjf: back
<bjf> amitk, the signature on mxc_timer_init changes between jaunty and karmic
<bjf> amitk, I chose to make that change rather than modify the FSL patches
<amitk> bjf: ack
<bjf> manjo, ping!
<manjo> yes
<bjf> manjo, fedex claims they delivered the HW
<manjo> I am at dinhs house right now ... my wife might have signed for it 
<bjf> manjo, "left at front door"
<manjo> I will walk over and take a look this afternon
<manjo> ok
<manjo> I will walk over there in 1hr
<manjo> thanks bjf 
<bjf> manjo, np
<manjo> who merged this cod ? 
<manjo> code ? 
<manjo> bjf, amitk take a look at arch/arm/plat-mxc/gpio.c
<manjo> you have 2 files on top of each other 
<manjo> duplicating every funtion in it 
<bjf> manjo, that's because the FSL one is so different from upstream, which one should be used?
<bjf> manjo, it would be our preference, to rip out the FSL version and just use the upstream version
<bjf> manjo, the problem I had with this was knowing if the imx51 depended on any side effects that were only in the FSL code
<bjf> manjo, what's your thinking w.r.t. that file?
<tseliot> smb, rtg_: thanks a lot :-)
<smb> tseliot, thanks for the preparational work :)
<pgraner> rtg_: 2.6.31-3 has the issue as well
<rtg_> pgraner, you said it was a Dell 2650?
<pgraner> rtg_: yep and older model
<pgraner> s/and/an/
<rtg_> I don't think I've ever seen one. Intel CPU, right?
<pgraner> rtg_: yep a celeron
<pgraner> rtg_: its just funny that it was working just fine with Intrepid and stopped with Jaunty
<rtg_> pgraner, I'm trying acpi.debug_level=ACPI_DEBUG, but its not recognized.
<pgraner> rtg_: I can give you access to this one if you want to poke around
<rtg_> pgraner, oh hell no. do I _look_ like I wanna debug ACPI stuff? Thats cking's specialty
<cking> ick
<rtg_> pgraner, ah, needs CONFIG_ACPI_DEBUG in order to get any output.
<rtg_> mjg59, any suggestion on how to approach a presumed ACPI problem for 2.6.28 and higher ? CONFIG_ACPI_DEBU is not defined, the machine boots with pci=noacpi. Its an Inspiron w/Celeron that wedges on boot.
 * cking is only really clued up on hardy kernels 
<rtg_> pgraner, 32 bit kernel? 
<rtg_> IIRC Celeron cannot do 64
<mjg59> rtg_: Where does it wedge?
<rtg_> mjg59, pgraner had a picture of it awhile ago. Pete?
<pgraner> rtg_: 32 bit
<pgraner> rtg_: http://people.ubuntu.com/~pgraner/IMG00160-20090715-1115.jpg
<pgraner> mjg59: ^^^^
<mjg59> Heh, ok
<mjg59> So everything later than .28 wedges there, and earlier stuff boots?
<rtg_> .28 and later (inclusive)
<rtg_> well, he's only tried .28 and .31-rc3
<mjg59> Nothing obvious springs to mind
<rtg_> mjg59, ok, I'm gonna build a kernel with ACPI_DEBUG and see if it sheds any light
<pgraner> rtg_, mjg59: I filed a bug on that issue LP 399844
<rtg_> pgraner, http://kernel.ubuntu.com/~rtg/linux-image-2.6.31-3-generic_2.6.31-3.19_i386.deb, use 'acpi.debug_layer=0x2 acpi.debug_level=0xffffffff' and see how far it gets.
<pgraner> rtg_: ok, so I used your kernel with the kernel params.... Hung, the only difference is there is one additional line on the console:  Clocksource tsc unstable (delta = -121312902 ns)
<rtg_> pgraner, ok, boot with 'hpet=disable'
<pgraner> rtg_: keeping the debug?
<rtg_> pgraner, I doubt if it makes a diff. try with and without.
<pgraner> rtg_: hung at the same spot with hpet=disable
<pgraner> rtg_: booting with hpet=disable acpi.debug_layer=0x2 acpi.debug_level=0xffffffff  removes the Clocksource tsc unstable line. Other than that it hangs at the same spot
<rtg_> pgraner, hmm, try different clock sources. perhaps clocksource=hpet or clocksource=pit
<pgraner> rtg_: ack
<pgraner> rtg_: no difference all hung in the same spot
<rtg_> pgraner, lemme research ACPI debug a bit more.
<rtg_> pgraner, try turning on all ACPI debug by using 'acpi.debug_layer=0xffffffff acpi.debug_level=0xffffffff'
<pgraner> rtg_: it looks like its stuck in a loop, does all that get written to dmesg?
<rtg_> pgraner, depends on if the root fs is mounted. otherwise it just goes to the console
<pgraner> rtg_: looks like its to the console
<pgraner> rtg_: you want a picture? It scrolls with the exact same message the only thing changing is the time stamp
<rtg_> spewing the same stuff constantly?
<pgraner> rtg_: yep
<rtg_> I guess see if you can get a phot
<rtg_> photo, even
<rtg_> Keybuk, you still around?
#ubuntu-kernel 2009-07-16
<shtylman> anyone able to look into bug #398059 yet? ... major problem imho
<ubot3> Malone bug 398059 in linux "system does not boot due to device-mapper error" [Undecided,Confirmed] https://launchpad.net/bugs/398059
<cafetiere> squeak
<dholbach> hola!
<dholbach> who'd be interested in talking a bit about kernel development at Ubuntu Developer Week?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some open slots
<cjwatson> I gather reintegrating iscsitarget is assigned to manjo; anyone know how far he's got with it?
<cjwatson> the iscsi userspace stuff is on my list for karmic and I'd quite like to have a target to test with :)
<smb> cjwatson, I believe he said the projects page code was rather unchanged and the server team had shown a general tendency/interest of getting this module done a dkms package. But I cannot remember any final status...
<smb> cafetiere, you? ^
<cafetiere> smb that is my memory also
 * cafetiere is unsure if its enabled or not as is
<cafetiere> cjwatson, will hastle him today to find out status for you
<cjwatson> thanks
<cjwatson> I tried the existing iscsitarget-source with module-assistant, but it failed to compile so apparently needs some update work
<smb> likely the removal of direct access to structs did not help. Yeah, we try to pry it of manjo later
<lool> Hey folks
<lool> Is there a tree from which I can build a mx51 .31 kernel?   :-)
<lool> Or even a binary kernel would probably be good enough for testing
<stewart> so, i don't know if this is actually a ubuntu kernel specific issue, but have only seen it on ubuntu. process listening to tcp port restarts (as part of that closes sockets). client program is trying to connect. listener has restarted and is in a loop trying to bind to the server port again, but client application has an open socket to the server port (even though the previous server has gone away) and netstat -t tcp -l -p shows
<stewart> : 
<stewart> tcp 0 0 *:12500 *:* LISTEN -
<stewart> tcp6 0 0 [::]:12500 [::]:* LISTEN -
<stewart> i.e. no process
<stewart> and client is stuck in poll()
<stewart> no idea what is going on. does anybody have an idea what could cause the above?
<hyperair> huh i've never seen anything of that sort before
<hyperair> you'd think that web servers would have an issue like this when restarting in ubuntu if this was reproducible, wouldn't you?
<stewart> hyperair: it's a pretty specialised case...
<stewart> after a bit more research....
<stewart> has been linux behaviour/bug since at least 2001
<stewart> not on solaris amazingly enough
<stewart> but also on osx
<stewart> but buggy poll/select on osx is nothing new
<rtg_> amitk, are those MX51 patches going into a Karmic topic branch? or master ?
<amitk> rtg_: they could be in a branch. It needs to be discussed.
<rtg_> amitk, why don't you start by creating a branch and pushing the MX51 patches there so they don't get lost or forgotten? We can always merger them back later.
<amitk> rtg_: I'm working on that. We just got it booting yesterday evening...
<apw> Keybuk, fyi i've done some testing on the latest karmic kernel, on aufs2 and it seems to work for me, updates and kernel compiles
<Keybuk> cool
<Keybuk> rtg_: you're having that "runlevel" bug yourself/
 * apw goes for a systems ... i may be a while
<apw> or not long at all!
<rtg_> Keybuk, yeah, whats the story on that?
<Keybuk> rtg_: I posted to the bug, I think it's apparmor looping over runlevel forever
<Keybuk> if you could fiddle with the script like I suggested, I'd like the strace output
<Keybuk> I just realised you'll need 2>&1 on that strace as well
<rtg_> Keybuk, ok, gimme a bit
<apw> Keybuk, would app armour not have to be enabled for that?
<apw> rtg_, did you enable apparmor ?
<Keybuk> apw: this looks like it's before it checks for that, it's in an infinite loop examining "runlevel" output
<Keybuk> I suspect I know what's wrong
<rtg_> apw, stock Karmic (upgrade from Jaunty)
<Keybuk> I just need strace output to prove it
<rtg_> Keybuk, would it run dhclient3-apparmor if I have a static IP address assignment?
<apw> anyone found a suspend or hibernate button on their karmic installs?
<Keybuk> rtg_: yes
<rtg_> apw, sudo grep "1" /sys/module/apparmor/parameters/enabled return 1. How did AA get enabled yet?
<apw> rtg i have that, and i also have this
<apw> [    0.004000] AppArmor: AppArmor disabled by boot time parameter
<apw> in dmesg, someone is lying
<rtg_> jjohansen, ^^^
<apw> ahh one hits shutdown from the system menu... and that offers you suspend
<rtg_> apw, one hits the power button and it just shuts down, no questions asked
<apw> nn mine i hit power and i get the same menu
<smb> which would be my expectation
<apw> though mine has reboot and shutdown greyed out
<apw> its probabally trigged by the power management preferences which have 'ask me' under 'when the power button is pressed'
<rtg_> apw, which is what I was futzing with.
<rtg_> Keybuk, I'm off to the server room to get your strace info. biab
<apw> rtg_, on my T30 the only message i see between grub and usplash is 'Loading please wait ...' which i believe is line 1 of the initramfs
<apw> so we may be off the hook :)
<rtg_> apw, yeah, I didn't think there were many boot time messages
<apw> i _think_ i saw one acpi one on my dell, will try and see if can capture those
<rtg_> Keybuk, it looks like it went through the loop at least once, but this appears to be exquisitely timing sensitive. I'll attach the updated dhclient3-apparmor as well as the strace output.
<Keybuk> great
<Keybuk> I suspect it is very timing sensitive
<rtg_> I wonder if AA has anything to do with my sshd issues?
<Keybuk> if you want to force the timing, add a "sleep 20" to the top of the start() function /etc/init.d/bootmisc.shg
<Keybuk> basically
<Keybuk> that apparmor script is calling runlevel to figure out the runlevel
<Keybuk> before /var/run/utmp is created
<Keybuk> so you get "File not found" :-)
<rtg_> it clearly doesn't take much. just adding '-v' to /sbin/ifup alters it enough that it boots
<Keybuk> if you make it a liiiitle big slower, you'll be lucky and /var/run/utmp will exist
<Keybuk> and whoever wrote that grep clearly doesn't understand runlevels anyway
<rtg_> well, this is a dual Nehalem, so theres a lot of shit going on at once
<Keybuk> yeah
<rtg_> Keybuk, bug updated
<Keybuk> thanks
<Keybuk> odd that the kernel affects it though
<Keybuk> maybe one of the kernels is just faster? :P
<rtg_> Keybuk, the previous kernel that this machines was using is 2.6.30 based, so did not have the AA patches.
<Keybuk> ahh
<Keybuk> so the script never ran? :)
<rtg_> Keybuk, likely not since 'grep -q "1" /sys/module/apparmor/parameters/enabled 2>/dev/null || exit 0' would have bailed
<Keybuk> ok
<Keybuk> and the reason this script worked in jaunty was because runlevel output random garbage when it couldn't read from utmp, rather than existing with an error like it was supposed to ;)
<Keybuk> though I can't see why that loop would ever work
<rtg_> so, fixing runlevel causes second order effects
<Keybuk> well, calling runlevel in rcS.d at all is utterly nonsense
<Keybuk> rcS.d is the sysinit phase
<Keybuk> there is *no* runlevel
<Keybuk> not even "S"
<rtg_> I'll have to take your word for that :)
<Keybuk> so any values returned by runlevel are generally nonsense
<Keybuk> iirc, runlevel will return "unknown"
<Keybuk> once /var/run/utmp exists, that is
<rtg_> Keybuk, what package should this bug be against? upstart doesn't seem appropriate.
<Keybuk> rtg_: I'll fix that up presently with a description
<Keybuk> open("/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<Keybuk> write(2, "runlevel: No such file or direct"..., 36runlevel: No such file or directory
<Keybuk> yeah
<Keybuk> the strace proves it quite nicely ;)
<rtg_> Keybuk, yep, saw that.
<Keybuk> though I should include a filename in that error, shouldn't I
<rtg_> Keybuk, next I'm gonna have to attack /sbin/ifup. It doesn't always get the route statements in /etc/network/interfaces 
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some open slots - how about something Kernel related? :-)
<rtg_> jjohansen, why does 'grep -q "1" /sys/module/apparmor/parameters/enabled' succeed on a 2.6.31-3 kernel? 
<jjohansen> rtg_: hrmm, was the machine booted with security=apparmor?
<rtg_> jjohansen, nope
<jjohansen> rtg_: it shouldn't be, I'll take a look
<rtg_> jjohansen, its part of the reason that we discovered https://bugs.edge.launchpad.net/ubuntu/+source/dhcp3/+bug/399954
<ubot3> Malone bug 399954 in dhcp3 "Karmic Boot hangs at "Configuring network interfaces"" [Medium,Triaged] 
<Dinh_FSL> manjo: good morning...
<manjo> Dinh_FSL, good morning sir 
<amitk> Dinh_FSL: manjo: morning!
<Dinh_FSL> amitk,manjo: still more debugging to do with the port, I am seeing after some period of time, it's hanging in synchronize_irq
<manjo> yep also usb support needs work right 
<manjo> are you planning on bringing that jtag home again on fri ? 
<manjo> I bet its the same kinda fix for sync_irq like the timer 
<manjo> probably missing mx51 bits
<amitk> great stuff last evening guys. Thanks.
<manjo> amitk, u not on the call ? 
<manjo> amitk, yeah lots of beer & wine helped 
<amitk> heheh
<amitk> umm... call?
<manjo> vnc
<amitk> oooh. skype
<Dinh_FSL> manjo: sure, i can bring jtag home tomorrow...keep going on this...
<manjo> yeah
<amitk> forgot all about it
<manjo> cool I can be there... I had too much fun yesterday
<manjo> amitk, so chiming in  ? 
<amitk> hold on.
<bjf> Dinh_FSL, do you know if the kernel you and manjo are working on right now will boot on a babbage 2.5 board?
<bjf> Dinh_FSL, or will there be additional kernel changes required?
<manjo> bjf, it boots on the board you gave me 
<bjf> manjo, that is a babbage 2 board, we will be getting babbage 2.5 next
<manjo> Dinh_FSL, did u have a 2.5 yesterday ? 
<manjo> I think he had the same board as me 
<Dinh_FSL> bjf: I tried the kernel on the 2.5 and wow!! It boots!!
<Dinh_FSL> hehe
<manjo> Dinh_FSL, dont forget to copy ubunt u install on my sd
<bjf> Dinh_FSL, that's sweet! good to know
<Dinh_FSL> manjo: yes sir, but you gave only gave me a 2GB card...it won't fit...i'll put it on 1 of my 4GB card for you
<manjo> sweet!
<dholbach> ok... only one slot left
<dholbach> who would like to talk about something Kernel related?
<dholbach> maybe "Becoming a Kernel hacker" where you show people what they can do to help you (or do your work for you :-))
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
<cjwatson> manjo: what's the story on iscsitarget in karmic at the moment? I'll be one of your users if you get it working, since I have a userspace spec for which that's the ideal test harness ...
<cjwatson> (just reading off some wiki page that said it was assigned to you and in progress)
<manjo> cjwatson, got pulled into doing some arm stuff so will look at it next 
 * cjwatson nods
<cjwatson> my deadline is alpha 4 so not super-urgent
<manjo> cjwatson, was planning on making it dkms
<cjwatson> fine by me, I don't much care exactly how it's done :)
<manjo> yeah the arm stuff need attention  for alpha3
<rtg_> cjwatson, wrt iscsitarget, the last discussion I had with the server folks is that we'll pull it out of the kernel. It'll be a DKMS package that is kept in sync with user space.
<cjwatson> that's fine, I just wanted to know if anyone had made progress on actually producing the package yet (e.g. PPA or whatever even if not in the distro)
<rtg_> I'll bug Dustinm
<rtg_> Dustin, even
<cjwatson> ok, cool
<cdowns> hello ?
<dinh_fsl> manjo, amitk: hi...
<manjo> dinh_fsl, hey
<manjo> you fixed it already ? 
<dinh_fsl> what is the plan with the current ubunt-fsl-2.6.31 tree?
<dinh_fsl> no, i haven't gotten a chance to fully debug it yet
<manjo> dinh_fsl, dont want to put words in amitk_ 's mouth ... but I think we need to massage it more and make it ready for upstream ... 
<manjo> dinh_fsl, same time tomorrow then ? 
<dinh_fsl> manjo: that's my thought too, just wanted to make sure...
<manjo> yep but we need it booting & running 1st 
<manjo> dinh_fsl, I could get you an official ans if you need it 
<dinh_fsl> manjo: that's what my manager and I are trying to figure out...
<manjo> dinh_fsl, let me see... 
<dinh_fsl> manjo: perhaps it may make more sense for you guys to massage it more, and if you hit another hurdle I can help again
<manjo> dinh_fsl, but we will need the jtag to see what is going on with the hang ... 
<manjo> can I get a loaner ? 
<dinh_fsl> a lauterbach?
<manjo> dinh_fsl, if you can spend one more day (tomorrow) to figure out that might just do it ... 
<manjo> yeah lauterbach + cables
<dinh_fsl> manjo: my answer is sure...i was planning to work from home tomorrow anyways...either on this or some other thing
<manjo> ok
<manjo> going fwd I think we wil see how to massage this code so that it looks better 
<manjo> clearly needs more work
<dinh_fsl> manjo: when's sushi?
<dinh_fsl> ;)
<manjo> dinh_fsl, let me call to find out 
<manjo> want to do it tonight ? 
<dinh_fsl> sure...
<dinh_fsl> let me know so that I can hold off the cooks at home
<manjo> ok in 10mts
<manjo> dinh_fsl, the chief is out of town this week .. so its going to be next week 
<dinh_fsl> manjo: ok...the cooks are back online
<manjo> :) 
<manjo> dinh_fsl, jack said the cheif had to go out of town... the other guys over there are junior 
<manjo> dinh_fsl, we want the sushi chief senior to prepare for us :) 
<dinh_fsl> manjo: ah I c...
<manjo> shit now I am hungry... all that salad for lunch is gone 
<dinh_fsl> manjo: outta here...see ya tomorrow morning...
<manjo> dinh_fsl, ok sir see you tomorrow
#ubuntu-kernel 2009-07-17
<billybigrigger_> anyone know a good place to learn some tips to compiling a kernel
<billybigrigger_> like what options i don't need or how to shrink my kernel and such?
<billybigrigger_> or any speed optimizations?
<billybigrigger_> or is it all pretty much learn it on your own and trial and error?
<jjohansen> well the kernel team knowledge base has a lot of useful info for dealing with Ubuntu kernels
<jjohansen> https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
<jjohansen> Dealing with upstream kernels is a little different, look at kernel.org
<jjohansen> and kernelnewbies.org
<jjohansen> billybigrigger_: there certainly is a bit of trail and error but there is a lot of good documentation
<jjohansen> As for speed optimizations, the is a matter of setting the configs for your situation
<jjohansen> eg.  If you don't need SMP you can get a little speed boost by turning it off.  But then your kernel will only work on with a single thread/core on newer cpus
<jjohansen> figuring out which config options you want is going to be the hardest part.
<jjohansen> You can compare what the different distros do, that will give you a feel for what is needed for generic style kernel.  And then you can start turning stuff off (well for the most part, you may turn a few things on)
<jjohansen> but if you are looking to speed up a generic kernel with some magic config it isn't going to happen.
<bullgard4> RFC2828 includes a definition of 'proxy server'. In two commentaries of this definition the term 'proxy' is used (not 'proxy server'). Does this use of 'proxy' mean a short-hand for 'proxy server' or what does proxy stands here for? 
<bullgard4> s/stands/stand/
<apw> cjwatson, iscsitarget -- would a test kernel be of use?  if so what arch?
<cjwatson> i386
<cjwatson> actually I can probably put together something for myself from the iscsitarget source package and svn ...
<cjwatson> I don't need to ship this, it's just for local use while testing
<apw> cjwatson, i've just pulled ours up to that svn you pointed to,
<apw> and was going to compile test it, so might as welll make you a kernel you can use to validate it
<cjwatson> ok - is it ABI-compatible with -3?
<cjwatson> ideally I'd just insmod something
<cjwatson> oh, -generic, btw
<apw> its wholey contained within its own dir, so i assume its compatible yes.
<apw> i will be making a whole kernel as part of the test
<apw> let me make just the .ko and you can try insmoding it
<apw> cjwatson, try: http://people.canonical.com/~apw//iscsitarget/
<cjwatson> insmod: error inserting 'iscsi_trgt.ko': -1 Invalid module format
<cjwatson> hmm
<cjwatson> iscsi_trgt.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
<cjwatson> Jul 17 12:30:05 sarantium kernel: [105134.078592] iscsi_trgt: no symbol version for module_layout
<cjwatson> does it need to be modposted or something?
<cjwatson> (er, please excuse me not really knowing what I'm talking about)
<apw> hrm ... oddness
<smb> apw, Did you compile the whole kernel or just the module?
<apw> i compiled just the module.
<apw> it did get modposted
<smb> maybe it also misses the whole modules versions
<apw> bah, i'll just build the whole thing
<smb> from the external symbols
<apw> its only computrons
<smb> And it keeps you warm :)
<cjwatson> I'll try updating the external package locally here
<apw> cjwatson, it would almost be preferable for you to test the real kernel
<cjwatson> well, FWIW the external module at least builds fine once updated, but I'm entirely happy to test the real kernel too
<cjwatson> of course I have to figure out how to use the userspace stuff ;-)
<apw> hehe 'instant expert' time again huh
<cjwatson> just add coffee
<apw> :)
<apw> cjwatson, i assume its you who i need to make sure is aware we reinstated aufs
<cjwatson> I saw the mail on ubuntu-installer@
<cjwatson> (and replied, actually)
<apw> hrm.  damned too much email
<cjwatson> oh, it's uploaded, cool - in that case current desktop images should actually already be using it
<cjwatson> I didn't change the default to unionfs-fuse, I just made it a fallback in case aufs was missing
<apw> very nice ... handy for ever more for sure, particulalrly for alpha-1 kernels
<apw> modules is the same name so we should be good
 * hyperair wonders if iwlagn takes up 100% cpu from time to time for anyone around here
<apw> not that i've seen on my kit.  i did have it blow its tx queue once since i hit 2.6.31-3
<dinh> amitk_ hi
<cjwatson> apw: Dave Morley reports that aufs is happily in use on today's live CD
<apw> cjwatson, most excellent thanks for the report
<rtg_> cjwatson, but is it 'quickly' in use? i.e., faster then FUSE?
<apw> i hammered the hell out of it before i committed it, but you do never know
<amitk_> dinh: hi
<amitk_> how do you do?
<dinh> amitk: good thanks...manoj mentioned you have some prior experience with lauterbach?
<amitk_> dinh: yes
<amitk_> on OMAP2/3 platforms
<dinh> i'm been able to debug with source level debuggin on our bsp, with your 2.6.31, my lauterbach script can't seem to be able to locate the source code after loading the .vmlinux file
<dinh> do i need to do a KBUILD_OUTPUT with your tree?
<amitk_> dinh: not sure. Are you using load.elf?
<dinh> yes...
 * amitk_ tries to dredge up his lauterbach .cmm files
<dinh> perhaps I can you send our .cmm file that we use to load?
<apw> amitk_, the armel config we have in karmic ... i note we have a lot of stuff 'off' for arm is there a reason that things are this way ... for example most of CRYPTO
<bjf> apw, the config in karmic isn't for imx51 it's for imx31
<amitk_> dinh: sure. send it over.
<bjf> apw, I don't think that config is any good (I don't know that anyone has actually looked at that config)
<amitk_> apw: the config is FOOBAR currently.
<apw> amitk_, so would it be sane for me to try and commonise some of those options then
<apw> on the assumption you are going to replace the armel config anyhow when the code is fixed
<amitk> apw: for arch-independent stuff, feel free to enable it all. That way when we add the imx51 config, we'll know what we forgot to turn on
<apw> thanks
<dinh> amitk: nevermind, i think i just figure it out...hold off on looking at the cmm file...
<amitk> ack
<dinh> amitk: hi amit
<manjo> yo amitk 
<amitk> dinh: hi
<amitk> yo manjo 
<dinh> amitk: what i'm seeing is that after some time, the system goes to turn off the display(ipu), it disables the IRQ for the IPU
<dinh> but it seems like all IRQs have been disabled because the command prompt is also not responding
<amitk> dinh: you mean at the login prompt?
<manjo> yeah
<amitk> dinh: could it be something simpler related to MXC_CONSOLE?
<dinh> amitk: hmm...can you explain more by MXC_CONSOLE?
<amitk> dinh: is CONFIG_SERIAL_MXC_CONSOLE=y ? and if so, is that code correct?
<amitk> perhaps a better question is, does lauterbach show that all IRQs are disabled? or are you guessing?
<Keybuk> random Q
<Keybuk> why doesn't broadcom wireless work in Karmic?
<Keybuk> how can I make it work?
<rtg_> Keybuk, its a dkms package
<Keybuk> rtg_: how do I install it?
<Keybuk> what's it called?  is it on the CD image? :)
<rtg_> bcm-source (i think), tseliot is the maintainer
<Keybuk> we got rid of lrm entirely right?
<rtg_> Keybuk, entirely, ling live lrm :)
<rtg_> jjohansen, can you update status on bug #359338
<ubot3> Malone bug 359338 in linux "apparmor paths are broken when using ecryptfs on jaunty" [High,Confirmed] https://launchpad.net/bugs/359338
<rtg_> Keybuk, bcmwl-kernel-source
<jjohansen> rtg: ack doing it right now
<dinh> amitk: the console code looks correct...from my lauterbach, i see that we try to disable the IPU_SYNC  irq(11), we call disable_irq(), then it get stuck in synchronize_irq
<dinh> in synchronize_irq, we're stuck in the loop that will not let us get out because it thinks we're in a critical section
<dinh> amitk:  while (desc->status & IRQ_INPROGRESS) 			cpu_relax();
<amitk> hmm
<dinh> amitk: i cleared the desc->status  IRQ_INPROGRESS bit and the login prompt is alive again
<amitk> dinh: so you suspect some irq handler is stuck?
<dinh> amitk: yes
<amitk> dinh: is the trigger always the IPU turn off display code?
<dinh> yes
<amitk> I guess IPU is trying to release the clocks and idle dynamically when it sees no user activity
<dinh> yes, the ipu will turn off after some period of inactivity
<amitk> dinh: you could try disabling that? Is it done through the suspend callbacks? I can see a call to mxc_pg_enable in the suspend callback of the ipu3 driver
<amitk> perhaps comment that out?
<dinh> amitk: i
<dinh> amitk: sorry..we look at it some more..but i'm pretty sure its ipu related code, because our system has been running for a long time now that the ipu is asleep
<bjf> manjo, ping
<amitk> dinh: drivers/mxc/ipu3/ipu_common.c:ipu_suspend() Trying commenting out the mxc_pg_enable in that if you feel like a quick test
<manjo> pong
<bjf> manjo, got time for a quick call (i'll call you)?
<manjo> bjf, can you we do it in 30mts or so ? 
<bjf> manjo, yes, let me know
<amitk> bjf: manjo: dinh: I've gotta run a few errands. It being Friday evening 6:30pm and all. Will be back later...
<manjo> amitk, we are in ipu_common .. making some mods
<manjo> amitk, cya soon
<amitk> manjo: cool
<manjo> bjf, you want to call ? 
<bjf> manjo, yes
<manjo> k can you call my cell ? 
<bjf> manjo, I think I have that number
<apw> jj so we still clone regression outstanding
<jjohansen> apw: yes
<apw> thanks
<MT-> I want to help, tell me how
 * MT- enjoys opening can-o-wormies on self w/ already busy schedule :)_
<manjo> MT-, you could take part in the ubuntu kernel bug day 
<manjo> and look at some of the kernel bugs 
<MT-> what day is that?
<manjo> I think the next one is Tue 21st
<manjo> MT-, let you point you to the wiki ... 
<manjo> MT-,  https://wiki.ubuntu.com/KernelTeam/BugDay/20090721
<MT-> manjo: sounds like fun
<manjo> MT-, http://qa.ubuntu.com/reports/ogasawara/kernel-buglist.html 
<MT-> wow
<manjo> MT-, ping ogasawara, will get you set up if you want  to contribute  
<MT-> ogasawara: remember me? I wanna be on the other side now :)
<MT-> manjo: thanks
<manjo> MT-, np
<MT-> manjo: I've been working on ubuntu-drupal stuff and 3/5 of the projects are basically done. Just little tweaks left abd probably bug reports. Two devs are working on the other 2 and I'll work on finishing those when they're done. After that I think I'll try to leave the project in the hands of the other devs and move on to kernel stuff and motu
<MT-> manjo: do kernel and motu merge well together?
<manjo> MT-, you have  to ask the motu guys ;) 
#ubuntu-kernel 2009-07-18
<andresmujica> have anyone noticed that the loadavg is 0.00 0.00 0.00 in Karmic all the time??
<Sarvatt> load average: 0.37, 0.16, 0.14
<andresmujica> uptime 
<andresmujica>  22:07:08 up  1:06,  5 users,  load average: 0.00, 0.00, 0.00
<andresmujica> after an hour...  karmic latest kernel... :/
<Sarvatt>  23:08:36 up 23:14,  2 users,  load average: 0.05, 0.02, 0.05
<Sarvatt> weird
<andresmujica> yup
<andresmujica> testing with daily mainline..
<mcasadevall> apw, SPARC configuration patches sent to the mailing list
<cjwatson> hmm, I see that loadavg 0 thing too, despite the system manifestly not being idle
<cjwatson> indeed if I run 'yes' in a terminal it stays pegged at 0 but top shows the terminal process at 97%
<Kano> hi apw 
<Kano> can someboy tell me why kdesu does not work with 2.6.31? It works with 2.6.30
<apw> Kano, not see that one
<apw> cjwatson, hrm ... i have that.  cannot be good for fairness in scheduling ... bugger ... is there a bug?
<Kano> it can not connect to su
<Kano> well u does not use su by default, but thats the problem which occours with kde 3.5
<Kano> just did a testinstall in vbox, the problem only exits with the new kernel
<Kano> maybe you find a way to test that with u too
<Kano> bbl
<MT-> ogasawara: hi
<thevarment> Hello fellow users.
<thevarment> I am new to linux/ubuntu and have a problem loading it on my dell as the only OS on the computer.
<thevarment> I get an "Unable to boot - please use a Kernal that is appropriate for your CPU" message. I was hoping someone here might to able to help me?
<mjg59> thevarment: You're trying to boot a 64-bit OS on a 32-bit system
<mjg59> You should download the 32-bit version
#ubuntu-kernel 2010-07-19
<cwillu> lamont, probably missing firmware
<cwillu> lamont, you should have relevant files in /lib/firmware
<lamont> cwillu: it works with the lucid kernel, just not with the maverick one
<cwillu> lamont, check the folder :p
<lamont> OTOH, the gobi chip dislikes the lucid kernel
<lamont> will do
<cwillu> lamont, iirc, firmware is placed in a kernel-version specific folder
<cwillu> although it doesn't have to be
<lamont> now if I only knew what file I was looking for
<cwillu> lamont, is there a firmware folder for the maverick kernel?
<cwillu> actually, I might expect a message in dmesg about not being able to find it if that's the issue;  should probably check for that
<lamont> it didn't look like it even found the device
<lamont> but bigger fish to fry this evening, I'll worry more about it in a few days
<miked595>  I'm running the i7-980x cpu. It should have 12 threads but cpuinfo only shows 8. http://pastebin.org/403849 not sure where to start. Running kernel 2.6.32-23-generic-pae #37-Ubuntu SMP Fri Jun 11 09:26:55 UTC 2010 i686 GNU/Linux
<cwillu> do we have a silly compile-time constant limit set I wonder?
<lamont> grep -c ^proc /proc/cpuinfo
<lamont> 16
<lamont> to be fair, that's a hardy machine
<lamont> but I can't see lucid _reducing_ such a limit
<cwillu> lamont, CONFIG_NR_CPUS=8
<cwillu> so, yes, the limit was reduced :p
<cwillu> lamont, looks like the 64 bit kernels use a higher limit
<cwillu> config-2.6.32-22-generic:CONFIG_NR_CPUS=64 vs 8
<cwillu> server kernel may or may not have a higher limit as well
<zykes-> cwillu: yes opposed to being a module.
 * cwillu_at_work scrolls up
<cwillu_at_work> oh, the loop module
<zykes-> yes, it makes using loop-aes a nightmare
<cwillu_at_work> having it built-in?
<cwillu_at_work> why?
<cwillu_at_work> I'm pretty sure that sort of thing is the reason it's built in
<cwillu_at_work> is loop-aes a replacement for loop?
<zykes-> yes
<zykes-> you replace the loop module with it
<cwillu_at_work> if so, you should consider the wisdom of using a module which overrides standard functionality in order to provide some specific (and incompatible) behaviour
<cwillu_at_work> having the module built-in means one doesn't have to do various insane things to allow the system to boot from an encrypted rootfs
<cwillu_at_work> (i.e., you can't load the module if it's on the rootfs, unless you put in it initramfs, which is fragile, and unrecoverable without alternate boot media if it breaks)
<TeTeT> when I place a custom kernel in a repo, e.g. linux-image-2.6.32-24-generic-pae, do I need to also add linux-image-generic-pae?
<abogani> TeTeT, It isn't mandatory but it is more simpler to type when a user install it.
<TeTeT> abogani: thanks
<ogasawara> RAOF: a while ago you sent us an email about discussing common bug tags for X and the kernel
<ogasawara> RAOF: is that something you'd still like to discuss?  And if so, we should all get together this week face to face.
<RAOF> Yeah, I would still like that.  When's good?
<ogasawara> RAOF: say 3pm-ish today?
<RAOF> I think that'll be good.
<RAOF> I'm booked with arm after lunch, but that shouldn't take too long.
<ogasawara> RAOF: what room will you be in?
<ogasawara> RAOF: or just come down to the kernel room
<RAOF> Yeah, that'll work.
<RAOF> I'll join you in the kernel room.
<RAOF> I know where that is :)
<ogasawara> RAOF: ack
<ogasawara> JFo, apw: ^^ just fyi
<JFo> sweet!
 * JFo slaps lag_ around
<JFo> :)
 * lag_ beats JFo with his rhythm stick!
<JFo> :-(
 * JFo does not feel the love
<lag_> JFo: <===3
<JFo> hahahahaha
<JFo> lag_ == nsfw
<JFo> ;)
<lag_> We're at work?
<JFo> hmmm. kind of
<lamont> cwillu: I just needed a 2.6.35-compatible bcmwl.  Now I have wireless and cell-connected-happiness, too.
<cwillu> \o/
<amitk> apw: Could you send Mathieu to the Linaro room to debug a IGEPv2 problem?
<cooloney> amitk: Mathieu is not in our kernel room now
<cooloney> amitk: if i see him, i will ask him come
<amitk> cooloney: thanks
<hyperair> does anyone know why there's this annoying "+" appearing at the end of my packages all the time?
<hyperair> and what's include/config/kernel.release? grep doesn't seem to show anything touching it, but that keeps getting created, with the + in the version
<ogasawara> akgraner: do you know how to lock down a wiki page so it can't be modified?
<komputes> I'm havin a problem with testing the mainline kernel. I have read https://wiki.ubuntu.com/KernelTeam/MainlineBuilds  and still have an issue.
<komputes> I need linux >2.6.33 for TRIM support, so I added ppa:kernel-ppa/ppa and tried to install linux-maverick, yet that package is not found.
<komputes> Separate issue - This bugs last comment http://launchpad.net/bugs/532451 suggests that there is a linux-backports-modules-2.6.32 package in lucid-proposed which corrects this issue. I am unable to find this package.
<ubot2> Launchpad bug 532451 in linux-firmware (Ubuntu Maverick) (and 5 other projects) "Intel WiMAX/WiFi Link 6050 series wireless does not work (affects: 18) (dups: 1) (heat: 120)" [High,Fix released]
 * abogani waves
<abogani> apw, Please don't forget me! ;-)
#ubuntu-kernel 2010-07-20
<ilmari> why is the kernel in lucid's -virtual package call itself -server?
<ilmari> s/is/does/
<ilmari> that had me _really_ confused when installing a new VM at at 03:00 this morning
<ilmari> ah, it's the same config, just with a subset of the modules
<repete> Can anyone point me to information on Bluetooth 3.0 support in Ubuntu?  From what I can determin Bluez supported it shortly after the spec was complete... but can't find much else.
<Keybuk> apw: being a -8 is actually more useful
<Keybuk> means I can install both :p
<Keybuk> thanks
<kamal> lag: hi, I'm looking for the source patch(es) you used to build http://people.canonical.com/~ljones/lp569882-lucid/ for bug 477106 -- where might I find it?
<ubot2> Launchpad bug 477106 in linux (Ubuntu) "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware (affects: 138) (dups: 24) (heat: 531)" [Medium,Confirmed] https://launchpad.net/bugs/477106
<lag> kamal: The code needs to be re-written
<kamal> well, I did find M. Levitsky "[PATCH v2] MMC: fix all hangs" at http://lkml.org/lkml/2010/6/11/266 which *almost* applies cleanly to Lucid -- and does seem to fix the hang.   Is your kernel there based on that patch?
 * abogani waves
<vanhoof> JFo: 
<vanhoof> sudo apt-add-repository ppa:canonical-dx-team/une
<vanhoof> sudo apt-get install unity
<JFo> coolness
 * JFo makes a note
<vanhoof> pgraner: fwiw http://unetbootin.sourceforge.net/
<lag> kamal: Sorry for the delay, I didn't realise you'd replied
<lag> kamal: http://kernel.ubuntu.com/git?p=lag/ubuntu-lucid.git;a=commit;h=6e57d188acafd42a64d3344717a5b7f3239d03d7
<kamal> lag: excellent -- exactly what I was looking for -- thanks!
<lag> kamal: No problem
<shtylman> is there a mailing list or something I can follow to know when a new kernel hits lucid?
<kees> shtylman: lucid-changes would work, though that will show you all packages, not just the kernel https://lists.ubuntu.com/mailman/listinfo/Lucid-changes
<shtylman> kees: better than nothing I suppose :/
<shtylman> thanks
<kees> np :)
<toabctl> hi 
<toabctl> i have a wacom bamboo touch cht 661 and there's module available on http://linuxwacom.sourceforge.net/, but the module is not intergrated in the ubuntu kernel
<toabctl> how can this be fixed?
<toabctl> i alread filled a bug report (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/527912 ) but i've done this for lucid and nothing happened.
<ubot2> Launchpad bug 527912 in xf86-input-wacom (Ubuntu Lucid) (and 3 other projects) "Wacom Bamboo CTH-661 not recognized (affects: 5) (heat: 36)" [Low,Invalid]
<chazn85> hey all, what is the tag used for needing kernel logs, i cant find it on the kernel triaging page
#ubuntu-kernel 2010-07-21
 * abogani waves
<RAOF> Heads up: we should pick up http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=944001201ca0196bcdb088129e5866a9f379d08c
<RAOF> I'll file a bug, too.
<ben72> hi! what am I doing wrong here? I want to assign a symlink (called cdisplay) to an USB device.. http://paste.ubuntu.com/467013/
<ben72> but I get a symlink like /dev/cdisplay -> snd/pcmC0D0c (and it seems it's random what it points to)
<lag> ben72: Try in #udev
<ben72> ok thanks lag
#ubuntu-kernel 2010-07-22
<looking4b> I have noticed that the kernel does some printk very early to print out the banner and version of the kernel. It does this before parsing the kernel command line which tells it which ttyS to use. How does the kernel figure out to which UART/Serial/Console port to send the output of printk at that stage? 
<looking4b> I am trying to get the kernel working on my embedded systems but I do not get any serial output from the kernel. When I debug it then I noticed that is calling printk but I do not see anything on my console (serial port)
<looking4b> can anybody help?
<looking4b> I am talking of the printks in start_kernel
<jjohansen> looking4b: those prints use earlyprintk
<jjohansen> you can set earlyprintk bootargs
<jjohansen> eg.
<jjohansen> earlyprintk=serial,ttyBF0,57600
<jjohansen> I would need to lookup how it determines which console to use by default
<looking4b> I think my kernel is using uart0 by default instead of using uart1 which is the one my hardware supports
<looking4b> I did compiled with a hard coded command line that has dev=ttyS1,115200
<looking4b> but I guess the kernel is crashing before it can use those settings
<looking4b> I do not even know if ttyS1 is really going to use uart1
<looking4b> there are 3 uarts in my system
<looking4b> I've been reading the source code but in some places they use dynamic function pointers to do stuff and I get lost then because I do not know to what function the pointer is pointing to
<looking4b> Another thing that I would like to know is how to make the System.map give me more details
<looking4b> right now it tells me a symbol and its address but I also want to know where that symbol is located
<looking4b> in which file.o the symbol was found
<looking4b> regularly gcc/ld will spit out a .map file with that information by default but I think System.map is being generating by parsing stuf from the .elf
<looking4b> I guess at that point finding where the symbol came from cannot be done since all the file.o have been combined
<jjohansen> looking4b: right, that info isn't available in standard .elf you need the debug information to do that kind of mapping
<jjohansen> if you know the address you can always map it back using gdb and the debug info
<jjohansen> I would have to go lookup how again as I haven't done it for a while
<looking4b> yeah, I do not know why the .map file that gcc/ld spits out is not used as system.map
<looking4b> it has much more info
<looking4b> I will have to research how to compile the kernel with debug info on
<jjohansen> are you using custom builds via make or the kernel build scripts
<looking4b> the truth is that I am using uCLinux with 2.6 kernel
<jjohansen> okay
<looking4b> but I thought it should be the same for any distro
<looking4b> I guess ubuntu patches the kernel with their own stuff but the basics are the same
<jjohansen> make  CONFIG_DEBUG_INFO=1
<jjohansen> that will turn on -g and -gdwarf-2 for the compiler
<looking4b> thanks
<looking4b> jjohansen: Adding a -Map=linux.map to the following line in the root Makefile did the trick
<looking4b> cmd_vmlinux__ ?= $(LD) -Map=linux.map $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
<looking4b> now I see things like 0x40020000                _start
<looking4b> .head.text     0x40020000       0xde arch/m68knommu/platform/coldfire/head.o
<looking4b> good to know in which file my entry point is
<looking4b> seems like my kernel does not get compressed
<looking4b> i think misc.c decompress the kernel
<jjohansen> looking4b: nice
<theRealSaint> dpkg-gencontrol: error: package linux-image-2.6.35-rc5-custom+ not in control info
<theRealSaint> am getting this error while compiling a vanilla kernel on ubuntu
<theRealSaint> any pointers?
<jjohansen> theRealSaint: how are you setting up the vanilla kernel for compile?
<theRealSaint> git download
<theRealSaint> am getting this error while compiling a vanilla kernel on ubuntu
<theRealSaint> fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers
<theRealSaint> jjohansen, these are the commands
<achiang> theRealSaint: can you do a grep LOCALVERSION .config
<theRealSaint> CONFIG_LOCALVERSION=""
<theRealSaint> auto is not set
<jjohansen> theRealSaint: hrmm I have never used make-kpkg to do vanilla builds
<jjohansen> I start with git pull of vanilla and either use plain kernel make, make install, make modules_install, update-initramfs, update-grub
<achiang> that's what i said earlier in #u-devel. ;)
<achiang> jjohansen: you forgot make firmware_install. :)
<jjohansen> or if I want a .deb, copy in the debian, and debian.master files from an ubuntu kernel
<jjohansen> ah yeah, well you know the basic steps
<jjohansen> and then I twiddle with configs maybe, and do
<jjohansen> skipabi=true fakeroot debian/rules binary-generic
<jjohansen> hrmm well actually I usually need to edit the version strings first, then do
<jjohansen> fakeroot debian/rules clean
<jjohansen> fakeroot debain/rules prepare-generic
<jjohansen> check config, and typing is right, maybe edit debian/change_log to add ~jj to the dpkg version
<jjohansen> the do
<jjohansen> fakeroot debian/rules binary-generic
<theRealSaint> hmm
<jjohansen> theRealSaint: https://wiki.ubuntu.com/Kernel/Dev/QuickBuildLocal
<jjohansen> covers the basics of how we build kernels
<jjohansen> basically all I do is transplant the debian bits from an ubuntu kernel into a vanilla kernel, and then do standard kernel build
<jjohansen> err standard ubuntu kernel build
<jk-> apt-get install iprint :)
<jdstrand> apw: hi! fyi only. I have an i7 running lucid that would not resume from suspend well
<jdstrand> apw: (usb wouldn't come up)
<jdstrand> apw: kees and I talked, and though his symptoms were totally different than mine, I decided to blacklist tpm
<jdstrand> apw: and lo and behold... it works fine
<jdstrand> apw: kees mentioned you had reports of i7 suspend issues, so I thought I'd pass that along. I'll let you know if anything changes on maverick for me
<lifeless> apw: jdstrand: I have suspend issues on i7 on mav
<lifeless> lucid base, maverick kernel, been insanely busy :(
<jdstrand> lifeless: you might try to do 'lsmod|grep tpm', then rmmod those prior to suspend and see if it works better
<lifeless> ok, will give that a shot
<jdstrand> lifeless: I've only done it a few times, but it has worked every time since then. prior to that, it never worked right
 * abogani waves
<abogani> apw, Do you have a chance to review -lowlatency kernel (and -realtime also) before of Alpha-3?
<vanhoof> sconklin: https://patchwork.kernel.org/patch/108727/
<diwic> abogani, out of interest, what differs the -lowlatency kernel from the -preempt kernel?
<diwic> I'm trying to understand the differences between the different attempts get lower latency...
<abogani> diwic, https://lists.ubuntu.com/archives/kernel-team/2010-February/008708.html
<vanhoof> sconklin: updated https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/561802
<ubot2> Launchpad bug 561802 in linux (Ubuntu Lucid) (and 1 other project) "[lucid] [i915] blank screen on Latitude E6410 (affects: 24) (heat: 171)" [Medium,In progress]
<nessita> hi there! can anyone give me a hand with a potential ACPI issue in my toshiba laptop?
<hazmat> does anyone know any details on the http://events.linuxfoundation.org/linuxcon2010/crawford the KSLM monitoring stuff? most i can find are some irc log messages, and an empty launchpad project 
#ubuntu-kernel 2010-07-23
<komputes> I was unable to install i386 RC5 mainline kernel on a system which currently uses a pae kernel (4GB+ RAM). Is anyone available to help with this issue? http://pastebin.ca/1907018
<looking4b> I am trying to find out which uart/serial driver my kernel build is using for my embedded system. How can I do this?
<looking4b> my map file tells me
<looking4b> 0x400b57a8 0x2fe26 drivers/built-in.o 0x400ca81c uart_console_write
<looking4b> but I do not know what built-in consist of
<looking4b> there is no built-in.c or anything like that
#ubuntu-kernel 2010-07-24
<achiang> built-in.o is a special object that consists of individual objects mushed together to form built-in.o
<achiang> looking4b: does your kernel boot up?
<looking4b> kinda
<looking4b> I cannot really tell passed a point
<looking4b> it might crash at a point but since I am running it blind I am not sure
<looking4b> I hooked up the debugger and I go through a lot of code and a lot of printk
<looking4b> but I see nothing on the console/serial port
<looking4b> I do have the serial driver turn on in the kernel config
<looking4b> and my BSP specifies my device
<looking4b> I am not troubleshooting why I am not getting any console output
<looking4b> I just cannot figure out which serial/uart driver the kernel is using
<looking4b> i think I found the driver for the coldfire
<looking4b> under /driver/serial/mcf.c
<looking4b> but it does not have the uart_console_write function in it
<persia> Anyone happen to know the URL for the wiki page about cross-compiling kernels?
<penguin42> hmm I seem to have a kernel build that's stalled with ld hung in stat->__xstat (libfakeroot)->send_get_state->send_get_fakem->semaphore_up->semop    seems odd; I'm guessing that's a libfakeroot bug
<looking4b> Does anybody know how to get the uart/serial port working for the m68knommu coldfire architecture?
<looking4b> I have been trying for days without success
<looking4b> it seems like things have been coded for ttyS0 to function as the console but I only have access to UART1 on my hardware which would be ttyS1
<looking4b> I do use a hardcoded kernel argument of console=ttyS1 but nothing works
<penguin42> looking4b: I assume you have the driver built into the kernel, have you got it booted at all? If so can you get a dmesg to see what it thinks that serial device is?
<ali1234> does ubuntu use modified module-init-tools?
#ubuntu-kernel 2010-07-25
<Iraqi> is there way to install Ubuntu on symbian OS 9 v3 or v5 ?? :)
<tim> hi, trying to compile 3.6.35-rc6, make-kpkg aborts with the error: dpkg-gencontrol: error: package linux-image-2.6.35-rc6+ not in control info ... any idea, why?
<miked595> I found that  /sys/devices/system/cpu/kernel_max shows 7. I have a cpu that provides 12 threads. Is it possible to update the kernel's max CPUs without recompiling it? uname -a = Linux sysops 2.6.32-23-generic-pae #37-Ubuntu SMP Fri Jun 11 09:26:55 UTC 2010 i686 GNU/Linux
<BenC> miked595: try the x86_64 kernel/system?
<BenC> miked595: or the -server I think
<BenC> miked595: and I'm not sure if it can override to a higher amount, but maybe maxcpus=12 on the kernel command line
<miked595> I am using the 32bit since I've had issues with 64bit supporting hardware properly. I an using the pae kernel since I would having issues with it seeing all of my 6GB of ram. now it does but I still only show 8 of the 12 threads, BenC
<BenC> miked595: try the -server kernel
<BenC> it has pae enabled as well
<miked595> i'll try that now
<BenC> miked595: or maxcpus=12 (I'm not sure if that works, but it's an easy thing to try)
<miked595> i was thinking it maybe easy just not familiar with the commands on how to do it. I didn't want to just edit /sys/devices/system/cpu/kernel_max without knowing
<BenC> miked595: at grub, edit the command line and add maxcpus=12 to the end, and then boot
<miked595> think i found it 
<miked595> ya 
<BenC> miked595: echo 12 | sudo tee /sys/devices/system/cpu/kernel_max
<BenC> that _might_ work too :)
<miked595> ya that didn't work lol plus I tried to edit it as root in vim just now and it seems to have been restored instantly
<miked595> gonna try just editing the grub line at boot to see if it works. brb
<BenC> "edit it in vim"
 * BenC chuckles a little
<DanaG> [    3.015786] RAMDISK: Couldn't find valid RAM disk image starting at 0.
<DanaG> [    3.031682] VFS: Cannot open root device "sda6" or unknown-block(0,0)
<DanaG> ARGH>
<DanaG> Why is AHCI not built-in on kernel-ppa?
<miked595> BenC: the maxcpus in grub didn't work. I also didn't see the server kernel i installed from apt
<miked595> http://pastebin.org/418035
<looking4b> Where can I change the compiler optimization for the kernel? I am debugging and I would like no optimization when my driver is compiled
<sebner> Hi, I reported a kernel? bug and was told to try with latest mainline kernel. Latest = latest stable or latest unstable? Reported on Lucid system
<johanbr> sebner, unstable is probably more interesting
<sebner> joaopinto: not so fun for a stable system though
<sebner> argh
<sebner> @ johanbr 
<sebner> joaopinto: sorry
<johanbr> sebner, well "unstable" is a bit of a misnomer, the 2.6.35-rcX kernels are pretty stable
<sebner> johanbr: heh :P
<sebner> johanbr: the kernel mainline repo has only 2.6.35-rc1~lucid, or should I install the -rc6~maverick kernel?
<johanbr> sebner, I'd be more inclined to try the maverick kernel, but then I'm a little scared of -rc1 kernels
<sebner> johanbr: k, thx
#ubuntu-kernel 2011-07-18
<apetrescu> I started a kernel build using:
<apetrescu> AUTOBUILD=1 fakeroot debian/rules binary-debs
<apetrescu> it's been going for four or five hours and I swear to God as the compilation targets scroll by I can swear I've seen some of these subtrees before
<apetrescu> Is there any known situation where it gets stuck in an infinite loop and keeps on recompiling the same things over and over again?
<apetrescu> It even got to the "LD    vmlinux" stage once
<apetrescu> And now it's back to compiling drivers/infiniband
<apetrescu> Which I'm almost certain was compiled about two hours ago
<lifeless> its building all the different flavours
<apetrescu> Oh, okay
<apetrescu> How many flavors are there? 3?
<apetrescu> Generic, xen, and rt?
<lifeless> dunno
<apetrescu> Damn, I should have told it just to do generic
<lifeless> binary-generic, for instance,w ould build one flavour
<apetrescu> At least that explains it
<apetrescu> Thanks a lot :)
<vish> hi, while git bisect I accidentally did $git bisect skip  , instead of $git bisect good , but then I tried to "fix" it by doing $git bisect < previous skipped commit> ,   so now the log looks like Â» http://paste.ubuntu.com/646220/ 
<vish> if you notice the last two bisects, they are the same commit# one is now marked skip and then as good.. is that correct or how do i fix it?
<vish> s/correct/OK
<ohsix> vish: you could start the bisect again with the valid outer commit id's instead of your original starting ones
<vish> ohsix: yea, I did consider that, but which way would that be?   just leave the new commit# as good and the old one as bad?
<vish> I had started with $ git bisect start Ubuntu-2.6.35-1.1 Ubuntu-2.6.34-5.14
<vish> i so just s/Ubuntu-2.6.35-1.1/6b2c676bf32be91f43215d5874c07c1becaba013   ?
<vish> so I*
<vish> err, wait the first one was bad!
<vish> s/Ubuntu-2.6.34-5.14/6b2c676bf32be91f43215d5874c07c1becaba013   ?
<ohsix> git bisect log shows all the decisions made; they alternate, between the last good and the most recent bad should be the inner set
<vish> the weird thing is I got only good bisects(until now).. o.0
<smb> vish, The output of git bisect log should be the sequence of commands needed to set you up. So if you put that into some text file and delete things after the point you want to start over with and then reset your tree to the start of the whole bisect, you can run that file and get where you want to be
<cking> morning folks
<vish> smb: yea i see it in the log.. so if I delete the second last 'skip' lines would it be OK? also when i $ git bisect reset
<vish> error: Untracked working tree file 'debian.master/NOTES' would be overwritten by merge.
<smb> cking, morning
 * vish could probably update the wiki with a lot more bisect info, (that is when i'm done) :D
<smb> vish, It should be ok for replay, yes. Sounds like for the reset you need to throw away generated files (git clean -d -x -f (warning gets rid of everything in the git directory not in git)
<smb> So the log better goes one dir level up to be persistently saved
<vish> k..
<smb> git checkout -f resets the files to what they are in the current HEAD
<smb> I often do both to get back to where I was before playing around
<vish> the git bisect help now makes better sense; thanks smb :)
<smb> vish, welcome :)
<vish> smb: looks like git reset went fine Â» http://paste.ubuntu.com/646288/  i'm only concerned about line 7 and ln 17,18  referring to the same KVM and commit# , is that right?
<vish> btw, after the git clean how do i make a new debian.master and debian ? or is it OK if I copy them back from a backup or from master?
<smb> vish, at least line 7 tells you where HEAD _was_ before. That could well be what you already had at a certain point...
<vish> yea..
<smb> The debian* dirs you should be able to copy from the release you are trying to bisect
<smb> Maybe a updateconfigs run would be good as well (to get the configs into a state where you get no questions)
<vish> k
 * ogasawara back in 20
 * jjohansen -> lunch
<dupondje> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2308
<ubot2> bugzilla.intellinuxwireless.org bug 2308 in RF-Kill "rfkill issue on Intel Centrino Advanced-N 6230" [Normal,New]
<dupondje> have we seen something simular ?
<vanhoof> dupondje: only thing that comes to mind recently is this: https://patchwork.kernel.org/patch/920262/
<dupondje> Oneiric kernel does have that commit yet ?
<dupondje> or not yet ?
<vanhoof> dupondje: looks like its in: 3.0-3.4 actually
<vanhoof> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/775281
<ubot2> Ubuntu bug 775281 in linux "[Dell Latitude 2120/Vostro 1015/1014] Turning off wi-fi with hotkey seems to permenantly disable wi-fi" [High,Fix committed]
<dupondje> The issue looks a bit different tho
<dupondje> Quite annoying issue imo
<dupondje> as it stops me from disabling bluetooth
<bdmurray> sconklin: you were asking about apport-package kernel bugs before - you might look in some of the log files for failures with update-initramfs and grub
<bdmurray> bug 810236 is a good example
<ubot2> Launchpad bug 810236 in linux "package linux-image-3.0.0-5-generic 3.0.0-5.6 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1" [Undecided,New] https://launchpad.net/bugs/810236
<manjo> sconklin, bjf, Ricoh 0xe823 card reader does not work for certain SD/MCC Cards, Bug# 773524, there are 2 patches, 1. is in stable 2. just submitted upstream and will be in 3.1 and has stable@ tag. But I would like to have them SRUed in Natty... I am thinking of SRU the 2nd patch as Sauce, any issues with doing that ?
<sconklin> manjo, don't ask me questions like this - read the SRU requirements, and if you think it's a viable patch, submit it as an SRU
<manjo> sconklin, :) ok 
#ubuntu-kernel 2011-07-19
<chrismsnz> Hi guys, I'm running 10.04 LTS on a group of servers and I'm having some trouble when it comes under high load
<chrismsnz> the system becomes unstable and will sometimes go into a state where it responds to basic network access (i.e. ping, accepting connection) but nothing further and for all intents and purposes is down/dead
<chrismsnz> I have a system in this state at the moment, and it's fairly easy to trigger the problem (it just takes a trip out to the colo to kick them in the pants when it happens).
<chrismsnz> How would I start collecting data to file this as a bug report?
<chrismsnz> is ubuntu-bug -p linux the best way to get underway?
<RAOF> chrismsnz: Yes, that's generally a good start.
<chrismsnz> so rebooting the server and running ubuntu-bug will pick up the old dmesg and everything?
<bryceh> chrismsnz, check dmesg for error messages
<bryceh> chrismsnz, no you have to run it while system is frozen
<bryceh> chrismsnz, if it is a gpu hang, you should also gather intel register dumps as well, although frankly it's unlikely gpu hang fixes will get done for lucid.  But who knows.
<bryceh> EOD, cya.
<chrismsnz> right
<chrismsnz> I actually had installed a newer kernel on this particular system to see if the problem was solved - but it was not
<chrismsnz> I will include in bug report, thanks guys
<smb> morning
<abogani> smb: morning
 * ppisati -> out for lunch
<RAOF> apw: Could I trouble you for a kernel build with the patch from bug #753994 ?
<ubot2> Launchpad bug 753994 in linux "[arrandale] Display is slanted when using 1360x768 resolution" [Medium,Confirmed] https://launchpad.net/bugs/753994
<apw> RAOF, sure
<apw> RAOF, for what series
<apw> RAOF, ok found it, assuming natty, will let you know when its done
<ohsix> herton: hi, i'm the guy on #793796, is this patch related to it? https://patchwork.kernel.org/patch/837692/ it's in the -11 package that just hit proposed; i won't have time to test it for a bit
<herton> ohsix: hi. yes, the patch is related, but it wasn't sufficient to fix your case. you need also the 0004 and 0005 patches from http://people.canonical.com/~herton/lp793796/r5/
<ohsix> ok, i read the one that was in r6 and that looked like the same, but percolated up
<herton> ohsix: upstream did another patch trying to not having to add a lot of tests for dead queues on elevator, it was the last kernel you tested, but it didn't work. I reported your test on upstream bug report, but there is no response yet
<ohsix> nod, saw that
<ohsix> just saw it in -11 and figured some wizard might have just bypassed it all :}
<herton> unfortunately no. still you shouldn't see the issues on -11 kernel as we kept reverted the patches that caused the problem for you, so you can use the new kernel
<ohsix> those are just reverts right? who committed the patches? shouldn't be too hard to get them to try unplugging a usb drive :]
<herton> yep, it just reverts the commit we found on bisect, plus also reverts the followup fixes to this first commit reverted
<herton> ohsix: the reverts are being tracked on bug 802986
<ubot2> Launchpad bug 802986 in linux "Revert upstream scsi run queue changes" [Undecided,In progress] https://launchpad.net/bugs/802986
<ohsix> hm, didn't know about that one, thanks
<ohsix> i'm surprised i haven't heard of a thread on the lkml about it or something
<herton> I think there was a thread only in linux-scsi, from where the patch in r6 you tested came from, and bug https://bugzilla.kernel.org/show_bug.cgi?id=38842 is in the regressions list that is frequently posted on lkml
<ubot2> bugzilla.kernel.org bug 38842 in Other "panic in elv_completed_request on safe remove usb hard drive" [High,Needinfo]
<ohsix> i hope people look at the lp bug for the simple reproduction steps, instead of getting the virtual machine image D:
<apw> RAOF, ok kernels build and published in the bug
<apw> smb, hey where do you get old isos from 
<smb> old isos of what exactly?
<apw> hardy for instance
<smb> http://release.ubuntu.com 
<apw> i happen to have other releases lying around
<smb> err
<smb> releases
<smb> apw, If course that only gives you latest point release and release for lts. if that is ok
<apw> yeah just something old enough :)
<smb> apw, could probably ship you gutsy... ;-P
<apw> smb, so very kind
<smb> apw, Heh, though you would be appreciating. Btw, where you want to install hw-wise. Usually hardy fails on NICs or wireless (if recent)
<apw> on a netbook, any chance ?
<smb> hm. could already be questionable as they always slam in latest stuff... it seems ok on the dell 1521 which has some broadcom... 
<smb> (not that you could call that recent)
<apw> smb, well i guess i'll give it a shot and see what happens
<smb> Yeah, you will notice quite early when the install complains about the network setup failed
<jwi> bugs related to -virtual kconfig: 720644, 769527, 771855, 794570, 761809, 658461 </braindump>
<apw> bug #720644 bug #769527 bug #771855 bug #794570 bug #761809 bug #658461
<ubot2> Launchpad bug 720644 in linux "linux-virtual kernel does not allow network configuration via kernel command line" [Undecided,Confirmed] https://launchpad.net/bugs/720644
<ubot2> Launchpad bug 769527 in linux "Missing rpcsec_gss_krb5 module" [Undecided,New] https://launchpad.net/bugs/769527
<ubot2> Launchpad bug 771855 in linux "reiserfs module missing in linux-image-virtual" [Undecided,New] https://launchpad.net/bugs/771855
<ubot2> Launchpad bug 794570 in linux "igbvf driver is missing from virtual-flavored kernel" [Medium,Triaged] https://launchpad.net/bugs/794570
<ubot2> Launchpad bug 761809 in linux "Quota modules are missing from the package" [Undecided,Incomplete] https://launchpad.net/bugs/761809
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<bjf> J
<apw> bjf thanks for the reminder
<bjf> apw, and this one only once :-)
<apw> its hard to remember its tue when its your first day of the week
<ogasawara> bjf: I liked the morning bug report
<ogasawara> bjf: sending it 50 times really made sure I looked at it :)
<bjf> ogasawara, heh
 * smb was already worried somebody sent a lot of patches...
<bjf> hey! we take our bugs seriously!
<ogasawara> smb: hehe, I had the same feeling for a second
 * ogasawara back in 20
<ogasawara> whoa, he put himself back to sleep.  lets see how long this lasts...
<apw> ogasawara, not long :)
<ogasawara> short lived indeed
 * ogasawara back in 20
<vanhoof> herton: heya
<herton> vanhoof: hi
<vanhoof> herton: quick q
<vanhoof> herton: bug 774947
<ubot2> Launchpad bug 774947 in linux "[Lenovo Edge 11 AMD] system locks up completely running the "stress" tool" [Medium,Fix released] https://launchpad.net/bugs/774947
<vanhoof> that fix came through 2.6.38 -stable, and landed in last weeks 2.6.38.10 kernel
<vanhoof> anything I need to do with it at this point? (just looking at the most recent update that was popped in there)
<herton> vanhoof: in fact it was applied by hand, doesn't have a buglink to a stable update tracking bug
<herton> let me check here if it was included in a stable update
<vanhoof> herton: ah ok, thought it was from the dialog in the bug
<apw> vanhoof, why have you closed the natty task for that bug ?  you say its cause 2.6.38-10 was released but that only contains 2.6.38.7
<vanhoof> apw: based on the testing that was done on -10, so I assumed this trickled down in 2.6.38.7
<apw> vanhoof, but you just said some 10 lines back that it was only in last weeks 38.10
<apw> which isn't in 38-10
<vanhoof> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/774947/comments/31
<ubot2> Ubuntu bug 774947 in linux "[Lenovo Edge 11 AMD] system locks up completely running the "stress" tool" [Medium,Fix committed]
<vanhoof> thats what I'm going with here
<vanhoof> if its in 2.6.38.8, I'll flip it back to fix commited
<apw> vanhoof, well if the fix is in that kernel then all is good, but thats the right reason to change the state to released
<vanhoof> looks like it was just those fixed on-top of -10
<herton> vanhoof: right, same fix came with 2.6.38.8, I'll update the bug there, you don't need to verify
<vanhoof> herton: cool, i flipped it back to fix commited then
 * vanhoof mis-interpreted the testing comment, and thought it was on the -proposed kernel
<apw> apw@dm$ git describe --contains 9ee653dce0efc6bad29f0d68b4ac74dbed093131
<apw> Ubuntu-2.6.38-11.47~159
<apw> as far as i can see the commit is not yet released, it is Fix Committed only
<vanhoof> right
<vanhoof> which I just set it back to
<apw> and as it is correcelyt marked
<apw> it should close itself when it releases
<vanhoof> apw: we get a few bugs where it's just waiting on some fix in -stable, like this one, didn't know if it would be automagically closed out
<vanhoof> in any event, we're good
<apw> vanhoof, no often it won't get picked up if its not known before we apply stable
<vanhoof> apw: yeah I assumed this was the case, and mis-interpreted the test results that were posted as 'fixed in -proposed' :)
<bjf> ##
<bjf> ## Kernel team meeting today @ 17:00 UTC
<bjf> ##
<cking> i'm still confused by bug 774947 - do we need to test or not? the commit is in the -proposed kernel right?
<ubot2> Launchpad bug 774947 in linux "[Lenovo Edge 11 AMD] system locks up completely running the "stress" tool" [Medium,Fix committed] https://launchpad.net/bugs/774947
<herton> cking: you don't need to test, yes the commit is on proposed
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
 * bjf -> dr. appt.
<kees> apw: none of the hardy linux CVE fixes show up in the tracker with a specific version...
<apw> kees, got an example
<kees> grep ^hardy_linux: CVE-2011-1170 CVE-2011-1171 CVE-2011-1172 CVE-2011-1173 CVE-2011-2534 CVE-2010-4649 CVE-2010-4073 CVE-2010-4238 CVE-2011-2484 CVE-2010-4165 CVE-2010-4249 CVE-2011-1010 CVE-2011-0711 CVE-2011-1090
<ubot2> kees: net/ipv4/netfilter/arp_tables.c in the IPv4 implementation in the Linux kernel before 2.6.39 does not place the expected '\0' character at the end of string data in the values of certain structure members, which allows local users to obtain potentially sensitive information from kernel memory by leveraging the CAP_NET_ADMIN capability to issue a crafted request, and then reading the argument to the resulting modprobe process. (http://
<ubot2> kees: net/ipv4/netfilter/ip_tables.c in the IPv4 implementation in the Linux kernel before 2.6.39 does not place the expected '\0' character at the end of string data in the values of certain structure members, which allows local users to obtain potentially sensitive information from kernel memory by leveraging the CAP_NET_ADMIN capability to issue a crafted request, and then reading the argument to the resulting modprobe process. (http://c
<ubot2> kees: net/ipv6/netfilter/ip6_tables.c in the IPv6 implementation in the Linux kernel before 2.6.39 does not place the expected '\0' character at the end of string data in the values of certain structure members, which allows local users to obtain potentially sensitive information from kernel memory by leveraging the CAP_NET_ADMIN capability to issue a crafted request, and then reading the argument to the resulting modprobe process. (http://
<ubot2> kees: The econet_sendmsg function in net/econet/af_econet.c in the Linux kernel before 2.6.39 on the x86_64 platform allows remote attackers to obtain potentially sensitive information from kernel stack memory by reading uninitialized data in the ah field of an Acorn Universal Networking (AUN) packet. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1173)
<kees> aaarggh
<ubot2> kees: Buffer overflow in the clusterip_proc_write function in net/ipv4/netfilter/ipt_CLUSTERIP.c in the Linux kernel before 2.6.39 might allow local users to cause a denial of service or have unspecified other impact via a crafted write operation, related to string data that lacks a terminating '\0' character. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2534)
<ubot2> kees: Integer overflow in the ib_uverbs_poll_cq function in drivers/infiniband/core/uverbs_cmd.c in the Linux kernel before 2.6.37 allows local users to cause a denial of service (memory corruption) or possibly have unspecified other impact via a large value of a certain structure member. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4649)
<ubot2> kees: The ipc subsystem in the Linux kernel before 2.6.37-rc1 does not initialize certain structures, which allows local users to obtain potentially sensitive information from kernel stack memory via vectors related to the (1) compat_sys_semctl, (2) compat_sys_msgctl, and (3) compat_sys_shmctl functions in ipc/compat.c; and the (4) compat_sys_mq_open and (5) compat_sys_mq_getsetattr functions in ipc/compat_mq.c. (http://cve.mitre.org/cgi-bi
<ubot2> kees: The vbd_create function in Xen 3.1.2, when the Linux kernel 2.6.18 on Red Hat Enterprise Linux (RHEL) 5 is used, allows guest OS users to cause a denial of service (host OS panic) via an attempted access to a virtual CD-ROM device through the blkback driver.  NOTE: some of these details are obtained from third party information. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4238)
<ubot2> kees: The add_del_listener function in kernel/taskstats.c in the Linux kernel 2.6.39.1 and earlier does not prevent multiple registrations of exit handlers, which allows local users to cause a denial of service (memory and CPU consumption), and bypass the OOM Killer, via a crafted application. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2484)
<ubot2> kees: The do_tcp_setsockopt function in net/ipv4/tcp.c in the Linux kernel before 2.6.37-rc2 does not properly restrict TCP_MAXSEG (aka MSS) values, which allows local users to cause a denial of service (OOPS) via a setsockopt call that specifies a small value, leading to a divide-by-zero error or incorrect use of a signed integer. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4165)
<ubot2> kees: The wait_for_unix_gc function in net/unix/garbage.c in the Linux kernel before 2.6.37-rc3-next-20101125 does not properly select times for garbage collection of inflight sockets, which allows local users to cause a denial of service (system hang) via crafted use of the socketpair and sendmsg system calls for SOCK_SEQPACKET sockets. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4249)
<ubot2> kees: Buffer overflow in the mac_partition function in fs/partitions/mac.c in the Linux kernel before 2.6.37.2 allows local users to cause a denial of service (panic) or possibly have unspecified other impact via a malformed Mac OS partition table. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1010)
<ubot2> kees: The xfs_fs_geometry function in fs/xfs/xfs_fsops.c in the Linux kernel before 2.6.38-rc6-git3 does not initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via an FSGEOMETRY_V1 ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0711)
<ubot2> kees: The __nfs4_proc_set_acl function in fs/nfs/nfs4proc.c in the Linux kernel before 2.6.38 stores NFSv4 ACL data in memory that is allocated by kmalloc but not properly freed, which allows local users to cause a denial of service (panic) via a crafted attempt to set an ACL. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1090)
<bliss> AAHHHHH
<kees> apw: anyway, all of those CVEs are just "pending" without versions
<apw> kees, hardy_linux: pending (2.6.24-29.92)
 * kees does an update....
<apw> apw@dm$ grep ^hardy_linux: active/CVE-2011-1170
<ubot2> apw: net/ipv4/netfilter/arp_tables.c in the IPv4 implementation in the Linux kernel before 2.6.39 does not place the expected '\0' character at the end of string data in the values of certain structure members, which allows local users to obtain potentially sensitive information from kernel memory by leveraging the CAP_NET_ADMIN capability to issue a crafted request, and then reading the argument to the resulting modprobe process. (http://c
<apw> pending without a version should mean Fix Commited but not uploaded yet
<bliss> kees: make sure that xfs fix comes with the fix to the regression it caused
<kees> apw: oh, ha-ha, we're out of sync with you. fixing, please ignore me...
 * bliss bows his head in shame
<apw> kees, np
<kees> bliss: do you have a pointer for it?
<bliss> i'll find the commit
<kees> bliss: do you mean CVE 2011-0711 ?
<ubot2> kees: The xfs_fs_geometry function in fs/xfs/xfs_fsops.c in the Linux kernel before 2.6.38-rc6-git3 does not initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via an FSGEOMETRY_V1 ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0711)
<kees> gah, I can't avoid the bot
<bliss> yes, that's the bug
<bliss> my fix was broken
<bliss> i content their code was broken and my fix revealed it, but that's an argument for another day
<bliss> contend*
<kees> bliss: heh. it's just a memset though?
<bliss> yeah
<bliss> but they cast a structure to a larger size in a function call
<bliss> so the memset caused an overflow
<kees> *ew*
<bliss> yes, i wrote the patch, but that was clearly their fault
<apw> that rings a bell, we may have gotten both but worth checking
<kees> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af24ee9ea8d532e16883251a6684dfa1be8eec29
<kees> bliss: yup, looks like we've got it.
<apw> those sha1s even look familiar
<apw> yeah we have both marked in the tracker as needed, so we are good
 * kees nods
<kees> hggdh: I have a question for you about q-r-t and updates... I want to add a test for something that hasn't been fixed yet. since we no longer fix CVEs in lock-step across all releases, I don't have a good way to avoid having the test fail. any thoughts on how to add a test that isn't a regression "yet"?
<hggdh> hum
<hggdh> the easy way out: let it fail -- I always verify the results 
<hggdh> another option, bit more involved -- set up a table of fixed releases (and versions) and compare against
<hggdh> kees: ^
<kees> hggdh: yeah, we're going to need this going forward, so probably the table is the best solution. I will ponder how to best implement it. thanks!
<hggdh> the only thing is this is probably going to explode, too many CVEs against too many different packages :-(
<kees> heh
<kees> hggdh: well, we have some of the data in the CVE tracker, so I'm just going to ponder how to avoid duplicating it.
<hggdh> if the cve tracker is API-accessible by anyone... 
<hggdh> we could just grab the data on run time. If not accessible, I am not sure it is a good idea
<kees> jhunt_: hello!
<jhunt_> kees: hi.
<kees> jhunt_: so, we were trying to figure out exactly what the changed behavior was so we could reproduce it.
<kees> jhunt_: without that, we were kind of stuff. we've been looking at another set of related changes, but I couldn't find fd/-specific stuf
<kees> *stuff
<jhunt_> well, to be clear, I'm not 100% sure what's happening yet. So, I'd really like to know what is expected behavior wrt a root process calling setuid and attempting to open /proc/self/fd/* directly.
<apw> i'd have expected /fd/ to continue to work, as you already have those fds open
 * kees nods
<kees> "self" should always be able to read its own fds I would imagine
<jhunt_> I've got a noddy test program that attempts this and on lucid, the process can only open /proc/self/fd/0 whereas on natty+oneiric, you can open /proc/self/fd/[012]. Any fd higher than 2 gives EPERM.
<jhunt_> apw: right. And I still think I might be going made, but the upstart session code that falls into this scenario *used* to work (on natty). however, I now cannot make the same code work on either natty or oneiric which made me think maybe a kernel or security change might be affecting things.
<jhunt_> s/made/mad :)
<jhunt_> (see, I'm mad me :)
<apw> jhunt_, perhaps you could send us the test code so we can look it over
<jhunt_> will do...
<apw> kees, this fix:     UBUNTU: SAUCE: proc: hide kernel addresses via %pK in /proc/<pid>/stack
<apw>     UBUNTU: SAUCE: proc: hide kernel addresses via %pK in /proc/<pid>/stack
<apw> kees, whats the gen with that
<kees> "gen" ?
<apw> kees, the history, the background?
<apw> it looks like a security related change, which we have from mainline in oneirc, backport from you in natty, but not in maverick
<kees> apw: right, so, it's an upstream improvement for continuing to lock down things that should be hidden with %pK
<kees> apw: it doesn't need backporting as far as I'm concerned. (i.e. I already backported it to natty which was the first the have %pK)
 * bliss cheers
<apw> kees, ah ok, fair enough, i'll drop teh K in the backport before that then
<jhunt_> apw, kees: code should with you now.
<kees> apw: I'm not sure what you mean?
<kees> jhunt_: thanks
<jhunt_> kees: np
<apw> kees, just trying to introduce a %pK too early is all
<kees> apw: ah-ha, okay
 * jjohansen -> lunch
<bjf> ogasawara, can you see if you can still get to the "site admin" page on voices.canonical.com? i'm not able to any more so no more blog postings for me
<ogasawara> bjf: lemme check, just a sec
<ogasawara> bjf: works for me, want me to post the meeting minutes?
<bjf> ogasawara, sure, i'll pastebin them 
<bjf> ogasawara, http://pastebin.ubuntu.com/647561/
<apw> bjf what error you get ?  internal server error?
<bjf> apw, You do not have sufficient permissions to access this page.
<apw> bjf odder and odder
<ogasawara> bjf: cool, posted
<bjf> ogasawara, thanks
<ogasawara> apw: weren't you getting some error as well?
<apw> bjf, nice ... i am still getting internal server error whenever i try
<apw> we'll run out of people who can soon
<bjf> apw, jjohansen is the community guy now, maybe only he can :-)
<apw> bjf he will be so pleased to hear that
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - July-26 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jjohansen> oh yeah so very pleased
<jhunt_> apw, kees: just seen http://bit.ly/nRONfB which suggests the problem I'm seeing cannot be entirely caused by the /proc/self/fd/ behaviour. I'll do some more debug tomorrow and keep you posted...
<kees> jhunt_: fwiw, even maverick shows this as a perm failure
<jhunt_> kees: ok, thx.
<sconklin> manjo: I'm sorry I snapped at you yesterday.  
<manjo> sconklin, hey no worries man
<manjo> sconklin, reason I asked you the Q was ... the patch is in 3.1... I was not sure if there was a scheme to get patches down before it hit stable (which might take a few weeks)
<manjo> sconklin, I will push thro sru process once it gets in the 3.1 tree, its got acks from most mainitaners now 
<sconklin> no, there's no scheme, and in general it's always better to just go ahead and get it out onto the mailing list instead of discussing it on IRC then having to rehash it in email
<manjo> right .. will do 
<sconklin> and I owe you a beer. Now, who wants to be snapped at next ;-)
<manjo> sconklin, :) no worries.. you don't 'owe' me... 
<hacksaw> I was just doing some maintenance, and therefore performing basic package updates on my 10.04 box. The explanation of why the kernel is being updated is "Bump ABI". Can anyone explain why I want to take my machine down as a result of this message? Does it mean something?
<apw> hacksaw, that sounds like a bug in the changlog generator for update-manager ... whats the version you are being offered
<hacksaw> 2.6.32.33.39
<bjf> tgardner, when do you want to get into the office?
<tgardner> bjf, I should be by 0800
<tgardner> be here*
<bjf> tgardner, sconklin is trying to setup a mumbe meeting, you see that?
<tgardner> bjf, yeah, but 0700 seems a bit early
<tgardner> bjf, speaking of mumble, I'd better make sure it works on my laptop. I've been having some problems.
<hacksaw> Okay, apw, I'm going to assume someone will look at the potential changelog bug, and make corrections in time.
<bjf> ogasawara, we are going to try to get into the office by 8:00 a.m., that work for you?
<ogasawara> bjf: I'll probably come in a little later then since Kai gets up around 8am.  be in likely by 9am.
<bjf> ogasawara, sounds good
#ubuntu-kernel 2011-07-20
<mwhudson> hi, the ubuntu-natty kernel tree doesn't seem to include the 2.6.38-10.46 abi stuff at the Ubuntu-2.6.38-10.46 tag
<mwhudson> is that to be expected?
<mwhudson> i'm very new to this sort of thing :)
<mwhudson> ah, it seems that the abi stuff gets added the commit *after* the tag
<mwhudson> (that makes some sense i guess)
 * apw waves
 * smb finishes scrollback and waves back
<apw> reading scrollback, how dedicated :)
<smb> Just because someone caused botty to spew out a lot of stuff and some of it hit the "bell of interest" ;)
<apw> smb, ahh yes the c-ve bell
<ppisati> apw: can you take a look at my ubuntu-oneiric ti-omap4-next branch? if it's ok, i'll pull req
 * ppisati -> out for lunch
<apw> ppisati, will try and look it over after i've sorted this lucid kernel issue
<Q-FUNK> It seems that the apport rules for reporting a kernel bug are excessively thight:  
<Q-FUNK> I was forced to reboot into an older kernel, because of a regression, all while leaving the current package pulled by linux-generic installed. now, apport refuses to let me file a bug using 'ubuntu-bug' because the currently running kernel is not the same as the latest.
<Q-FUNK> using 'ubuntu-bug linux' that is.
<ppisati> apw: k
<apw> Q-FUNK, yep its a pain in the backside
<Q-FUNK> apw: is there any way this could be fixed?
<apw> Q-FUNK, it cirtainly can be fixed
<Q-FUNK> I can understand apport complaining if there is no linux-generic installed at all, but refusing to let me file a bug just because I rebooted into an older kernel that is no longer in the repository seems excessive.
<apw> Q-FUNK, indeed seems excessive if that is the criteria
<apw> though the bug information will be poor if you cannot file it from the right kernel anynhow
<apw> as that will indicate the bug is in your old kernel which is false
<Q-FUNK> will it? or will the bug be filed against the current version of linux-generic that is installed?
<apw> all of the live information will be taken from teh running kernel
<apw> so it would be even worse as mixture
<Q-FUNK> right.  shouldn't there be a way to instead attach the dmesg from the previous boot with the buggy kernel, instead?
<apw> yeah there likely should, or a way to take all the infrmation offline or something
<Q-FUNK> that would work too.
<apw> Q-FUNK, what happens if you ask it to file a bug against the specific binary kernel package which is broken
<Q-FUNK> don't we already same the dmesg from the previous boot?
<Q-FUNK> Ã¶Ã¶... save
<apw> Q-FUNK, maybe so, not that i am aware of specificall, but maybe
<Q-FUNK> trying that. just a sec.
<Q-FUNK> yup. specifying the exact binary seems to work.
<apw> Q-FUNK, well thats something, not helpful particularly but ok ..
<Q-FUNK> well, at least the hardware data remains valid. :)
<apw> whats the regression and with which release
<Q-FUNK> since 2.6.39 there's frequent kernel paging failures that make the kernel oops.  it especially happens whenever running dpkg.
<Q-FUNK> it's a non-fatal oops, but I end up having to run 'dpkg -a --configure' and re-start 'apt-get upgrade' several times in a row to complete the upgrade.
<apw> so in lucid ?
<Q-FUNK> oneirc
<apw> well you must be unsual as i have 10 machines in that range and none have ever shown that kind of behaviour
<apw> you are saying if you run 2.6.39 it doesn't occur ?
<Q-FUNK> 2.6.38 works fine, but 2.6.39 and more recent have the symptoms.  with 2.6.39 it happened seldom, but with 3.0 it's nearly systematically when I do a daily package upgrade.
<apw> 32 or 64 bit ?
<Q-FUNK> 32-bit.  Geode LX
<apw> oh a geode, heh, bet its h/w specific
<Q-FUNK> not really
<apw> well its not occuring any any of my oneiric boxes
<apw> so its cirtainly not general
<Q-FUNK> however, this particular host has repeatedly shown to be a good trap for corner-case kernel bugs.
<apw> Q-FUNK, as you have a pair of good/bad you could see if the corresponding mainline kernels have the issue
<apw> and then use the -rc's to try and pare it down a bit
<Q-FUNK> tried that before, the last time I had a major regression on that host.  in the end, while we found out around which commit the regression took place, it never got investigated.
<apw> Q-FUNK, as you are the only one with the h/w i suspect unless you do it it'll stay broken
<Q-FUNK> I don't mind testing every -rc in the vanilla kernel folder to narrow it down to one specific release, but unless actions are taken beyond that point, it gets ridiculous.
<mjg59> geode is amazingly niche hardware, and lots of people seem enthusiastic about building businesses around it without actually being willing to put in the funding or effort for making sure that the software they depend on continues to work
<Q-FUNK> for instance, the ext4 inode destroying bug I encountered on the same host from kernel 2.6.31 to 2.6.35 was never properly investigated. it was just marked as fixed the day I announced that 2.6.36 apparently fixes it.
<apw> Q-FUNK, if we can figure out whats breaking you we'll try and fix it, but last time it basically appears to be a work around for broken cache coherency so ... its not easy to either find or fix
<Q-FUNK> apw: it could be. I'm still baffled as to how the bug occurred on that particular geode box and not on another one with a different bios.
<apw> Q-FUNK, isn't half of the geode instruction set implemented via SMI, at which point the BIOS is part of your processor from a semanatic point of view
<mjg59> apw: Not so much the instruction set. Just every time you think you're touching hardware.
<apw> mjg59, ahh ok, so its part of the h/w then even after its handed off ... just as bad
<Q-FUNK> IIRC the bios is mostly used to provide a traditional x86 abstraction (PCI bus, etc.) for a system that uses an entirely different bus architecture and there are various implementations of that abstraction layer.
<mjg59> Right, any PCI accesses get handled by non-free firmware
<mjg59> So who knows what it's doing?
<apw> Q-FUNK, right but if the code is running via SMI after the kernel takes over, any bug in it ... can break things ... if they don't clean up right
<Q-FUNK> free or non-free.  coreboot works quite well on those, at least for a few known configurations.
<mjg59> Anyone who knew anything about how it worked appears to have vanished in a set of freak accidents
<Q-FUNK> mostly in a set of random AMD attritions and OLPC changes of mind.
<apw> mjg59, not physcial accidents i hope
<mjg59> apw: Not to the best of my knowledeg
<Q-FUNK> AMD used to have an extremely knowledgeable and dedicated coder who handled Geode coding for the OLPC project.  he even won employee awards for his efforts.  then one day, after a particularly bad quarterly, he fell the victim of random attrition.
<mjg59> I suspect that if it weren't for OLPC, everyone would just have given up pretending to support Geode
<mjg59> It's cetainly the only reason we care
<mjg59> (And we don't for RHEL)
<apw> ahh ... shame i don't know anyone who has one
<Q-FUNK> that random attrition even left his immediate boss in usnly had to provide technical support and ongoing code development without his main guy.
<Q-FUNK> argh.  friggin kernel i/o stealing my keystrokes again
<Q-FUNK> that random attrition even left his immediate boss in total limbo, because he suddenly had to provide technical support and ongoing code updates without his main guy.
<Q-FUNK> I really hate how hard-disk access has the bad habit of momentarily halting the keyboard buffer.
<apw> Q-FUNK, never see that either, keys may be delayed for me but not lost
<apw> not that i want them delayed of course, but thats a separate gripe
<Q-FUNK> delayed would be acceptable.  half of the time, if the kernel starts swapping, I end up missing several words in the middle of a sentence.
<ohsix> you could try changing your io wait method
<apw> herton, we likely are going to have to shove a lucid kernel with a single fix in for the point release ... so hold off any lucid uploads to the PPA
<herton> apw: we were avoiding uploading anything because of the point release too, so that's ok
<apw> ok good stuff
<Q-FUNK> ohsix: the scheduling algorhythm, you mean?
<ohsix> Q-FUNK: nevermind, was thinking of something else
<apw> sconklin, i've pushed a temporary bracnh to lucid, master-point which is what i am proposing for the upload
<sconklin> apw: ok, sounds good
 * ogasawara back in 20
<apw> sconklin, ok the decision from the release team is that they want a kernel spun, could you check that branch for me as the stable check script just talks crap
<sconklin> heh, probably as soon as we finish the meeting
<climbe2> Problem!  If anyone is able to help.... running 10.04, recently upgraded to kernel 2.6.32-33, and can't boot up!!  See http://ubuntuforums.org/showthread.php?t=1807978 for my ongoing thread.  Any suggestions?!?!
<ogasawara> tgardner: heading in, see ya in 15
<tgardner> ogasawara, ack
 * herton -> lunch
<ppisati> mumble went belly up
<kees> apw: say, did you see my email about a funky CVE in the hardy update?
<apw> kees, not yet, which one
<kees> oh, sorry, not hardy. 2010-4175 in linux-lts-backport-maverick
<kees> the tracker shows "released 2.6.35-25.44~lucid1" but there is a changelog entry in 2.6.35-30.56~lucid1
<apw> kees, seems to be applied twice
<kees> ??
<apw>  git log --oneline origin/lts-backport-maverick  | grep 'rds: Integer overflow in RDS cmsg handling'
<kees> was it a no-change cherry-pick or something?
<apw> 9a3798f rds: Integer overflow in RDS cmsg handling, CVE-2010-4175
<ubot2> apw: Integer overflow in the rds_cmsg_rdma_args function (net/rds/rdma.c) in Linux kernel 2.6.35 allows local users to cause a denial of service (crash) and possibly trigger memory corruption via a crafted Reliable Datagram Sockets (RDS) request, a different vulnerability than CVE-2010-3865. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4175)
<apw> ae1d3ae rds: Integer overflow in RDS cmsg handling
<apw> git describe --contains ae1d3ae
<apw> Ubuntu-lts-2.6.35-25.44~33
<apw> git describe --contains 9a3798f
<apw> Ubuntu-lts-2.6.35-28.50~20
<apw> so thats where the version you mention come from.  from whats in the tree i'd expect my tools to take the first version number there
<apw> and i think thats what you are saying it did
<kees> yeah, that's certainly the correct approach, but I guess I'm wonder if we need to look closer -- how did it get applied twice (did that have a bad effect?)
<apw> kees, both commits seem to be complete
<apw> which should be impossible
<kees> right :P
<sconklin> apw: did you test build this?
<apw> sconklin, i built only generic on amd64/i386
<sconklin> I'm going to test build before I shove it to the PPA. Less time in the long run if it fails
<apw> sconklin, ack, thanks
<apw> kees, will investigate and let you know
<kees> apw: cool, thanks
<apw> i can only assume the first one got reverted somehow
<apw> just ... how i don't know
<sconklin> apw: does this require an ec2 respin?
<apw> sconklin, i would expect it might now you mention it, but i am confirming now with the release team
<herton> ppisati: yeah, mumble can't login anymore here
<sconklin> here either
<apw> kees, ok this actually is fixed in the earlier one as advertised.  however the relayout of the code since then makes it inobvious so someone has applied the same fix again to the containing routine in the second place
<apw> kees, so its doubly fixed essentially
<kees> apw: how strange, okay. thanks!
<apw> sconklin, ok the basic answer is no we don't need -ec2
<apw> kees, good spot though
<sconklin> ok
<apw> 17:49:02      Daviey | it's a nice to have.. but we are only currently seeing this with euca.                         â astraljava
<Daviey> \o/
<apw> Daviey, yep taking your name in vein
 * apw screams about mumble
 * jjohansen running an errand
<sconklin> apw: package uploaded, It'll take 24 hours to complete, since it includes ARM arch
<apw> sconklin, yeah
<apw> sconklin, one reason we need it in as soon as
<sconklin> apw: yep, and another reason that I did a test build (which completed OK)
<apw> sconklin, yep all sensible and right
<climbe2> Problem!  If anyone is able to help.... running 10.04, recently upgraded to kernel 2.6.32-33, and can't boot up!!  See http://ubuntuforums.org/showthread.php?t=1807978 for my ongoing thread.  Any suggestions?!?!
<apw> climbe2, does the previous kernel work
<apw> as in seelecting an older kernle from the grub menu
<tgardner> apw, mumble seems to have reincarnated
<climbe2> apw, no none will work anymore
<apw> climbe2, ok thats indeed odd if you took a kernle update and all your old kernels stop working too
<apw> which versions have you tried
<climbe2> perhaps it was not the upgrade.... I was recently using an SDHC card through my HP printer... two different USB storage devices...
<climbe2> all I know is that I can't boot up at all!
<apw> /dev/disk/by-uuid/e3df952c-d462-4292-bab6-4965da1d567c does not exist. Dropping to a shell. 
<apw> so that implies your disk does not have the lable that is expected
<apw> at the busy box you can get the dmesg output and see if any of your disks were found
<climbe2> ok, how do I do that?
<climbe2> I am also on a different computer right now, so I will have to hand type it
<apw> climbe2, 'dmesg | grep sd'
<apw> that command sequence might give you some clues
<apw> climbe2, you might also try 'blkid'
<apw> if that is available it might tell you waht disks it thinks it can see
<apw> /dev/sda5: UUID="cf503727-25f2-4ecd-b0f3-2b894523bcba" TYPE="ext4" 
<climbe2> I can only get to the grub command line
<climbe2> is there another command line I can use?>
<apw> mine has a line like that ... wihhc matches the UUID in the error ...
<apw> climbe2, your post has the busybox prompt in it ?
<apw> (initramfs) 
<apw> that one
<climbe2> I've been a few different places from back then...let me see
<climbe2> yes, I am there
<apw> does blkid produce any output
<apw> and does dmesg | grep sd
<climbe2> dmesg | grep sd produces hundreds of lines it seems....blkid produces my drives
<apw> ok, and does the UUID in the error line appear ?
<climbe2> blkid:  /dev/sda1, 2, 5, 6    /dev/sdab1
<apw> climbe2, is that the exact output it produced ?
<apw> i am expecting some UUID= segments
<apw> /dev/disk/by-uuid/e3df952c-d462-4292-bab6-4965da1d567c
<climbe2> there is an extra "\" in the error message than in the drive UUID
<apw> an extra ?
<apw> what ?
<climbe2> wait..let me see
<climbe2> in grub, i press 'e' to edit... it has /dev/disk/by-uuid/e3fd.....b\ab6-... instead of bab6
<apw> well you could try removing that \
<climbe2> rather, in the edit screen, 5th line down it says linux /boot/vmlinuz 2.6.32-33-generic root=UUID=e3fd.....b\ab6...
<apw> though i am supprised to get those full names in your grub conf
<climbe2> perhaps that is an end-of-line signal...?  it occurs on another line as well
<climbe2> when the line breaks to continue to the next
 * apw has to run
<climbe2> thanks for the help
<climbe2> i'll see what i can do
<pgraner> skaet, ping
<pgraner> skaet, we don't need to pull the kernel re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/788351
<ubot2> Ubuntu bug 788351 in linux "xfs ioctl XFS_IOC_FSGEOMETRY_V1 clobbers kernel stack" [Undecided,New]
<pgraner> skaet, the patch in question is in the current -proposed
<pgraner> skaet, no need to do anything
<skaet> pgraner,  thanks - was pinging around about it. 
<pgraner> skaet, next time just drop in here and ask
<skaet> pgraner, will do
<kees> apw: another "why is this 'released'?" question for 2011-0711. uct shows it as "released" for a kernel in -proposed (hardy)
 * jjohansen lunch
 * tgardner bounces tangerine for kernel update
<FireZen> !
#ubuntu-kernel 2011-07-21
 * smb yawns
<apw> kees, that is something your scripting is doing.  your team does something which changes it to released over and over
<apw> smb, moin
<smb> apw, moin moin
<apw> kees, then generally i change it back on th next autotriage run
<Daviey> apw: What is the current status with the lucid kernel?
<apw> lucid kernel is built in the PPA
 * smb wonders whether Daviey is personally affected
<apw> Daviey, https://launchpad.net/~canonical-kernel-team/+archive/ppa/+sourcepub/1825665/+listing-archive-extra
<apw> if you fancy doing a last test with the final binaries before they are copied out, it might make skeat happy
<Daviey> apw: That is all i hope to achieve in life.
<Daviey> apw: thanks
<mvo> hi,  I see odd upgrade issues in my kvm based automatic upgrade testing. after the upgrade to 3.0.0-5-generic in oneirc it won't find its root fs anymore. http://people.canonical.com/~mvo/tmp/Screenshot%20at%202011-07-21%2013:58:22.png <- screenshot of the kvm instance. the uuid displayed looks odd, all 00000 for the available paritions. with 2.6.28-8-generic (same image) it books just fine. any ideas where I should dig further?
<mvo> blkid /dev/sda1 on the system gives me the right uuid
<apw> mvo, but normally UUID mappings are done in initramfs so we'd not expect the kernel to be doing anything with them would we ?
<apw> mvo, and that error looks like the kernel erroring the mount ... not initramfs dropping to busybox
<apw> have you lost your initramfs for the new kerenl
<mvo> apw: thanks! I should have thought about this, let me investigate whats up with the initramfs
<mvo> apw: ha! here we go, grub is missing the initrd line, now I just need to figure out why. thanks for your help
<apw> mvo, heh good
<skaet> apw,  how is the lucid kernel with patch to fix bug 588861 coming along? 
<ubot2> Launchpad bug 588861 in linux ""pad block corrupted" error when trying to register an image with 2.6.34 kernel" [High,In progress] https://launchpad.net/bugs/588861
<apw> skaet, its all built, i 'handed' it to cjwatson and you in #ubuntu-release
 * apw wanders out for some air
<skaet> apw,  coolio.   Many thanks.  :)
 * smb suggests non-air tight windows to apw
 * ogasawara back in 20
<bjf> brendand_, if you have issues with stable kernels or any kinds of questions about them, it's best to ask them in this public channel
<brendand> we've got a system being tested with the proposed maverick kernel which blanks the display after about 2-3 minutes from booting
<brendand> we're sure it's not the screensaver
<brendand> but this is after doing a full dist-upgrade
<brendand> if we just update to the proposed kernel then it seems to work okay
<brendand> would it be worth updating both the kernel and xserver-xorg (and perhaps the graphics drivers where applicable)
<brendand> ?
<bjf> brendand, yes, i think that makes sense, to get to the interaction that is causing the problem
<skaet> apw,  have gone ahead and updated kernel tracking bug to indicate it was ready to be published,  and have now moved the kernel to -proposed.
<apw_> great
<hallyn> so with dkms packages, should dkms be doing anything to check whether the linux-headers package installed matches the kernel, at least, or, preferably whether both are the defaults?
<bjf> ogasawara, anytime your ready, ping me
<ogasawara> bjf: cool, gimme about 10 more min
<bjf> ogasawara, no rush, got plenty to do :-)
<tgardner> hallyn, DKMS typically _requiers_ the headers packages to match the kernel ABI
<tgardner> requires*
<hallyn> tgardner: hm, bc every lucid or maverick 'high' or 'critical' open-vm-dkms bug i just saw has them not matching
<tgardner> hallyn, well, we don't maintain DKMS, so I'm not all that familiar with it anymore
<hallyn> tgardner: ok, thanks.
<tgardner> hallyn, alberto milone has a lot of experience with it
<hallyn> if enough of these keep coming, i guess i'll look into it more
<ev> I've seen several people, mostly with MacBook Airs in Millbank that cannot reboot.  I've just come across a MacBook Pro that cannot either: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/814118
<ubot2> Ubuntu bug 814118 in linux "MacBookPro7,1 fails to reboot" [Undecided,Confirmed]
<ev> this is all in Natty
<ev> if you guys need any more information on those, do let me know.  I sit right by these.
<ogasawara> bjf: k, I'm ready whenever
<tgardner> bjf, your bot message has a mis-spelling: dianosing. bug #814118
<ubot2> Launchpad bug 814118 in linux "MacBookPro7,1 fails to reboot" [Undecided,Confirmed] https://launchpad.net/bugs/814118
<bjf> tgardner, will fix
<bjf> ogasawara, will be on my way soon
<ogasawara> bjf: ack
<smb> ev, I maybe missed it but has that ever worked in 10.04 or not? Anyway, you may try to put reboot=? (with ? alternatively being b, t, k, a, e or p) to the kernel cmndline and try rebooting then.
<smb> ev, and of course add any outcome to the bug report
<ev> smb: I don't know about 10.04 - I could add a 10.04 kernel to the system and try rebooting from that, if you think it would prove valuable
<ev> and I'll give the reboot= ones a go in a bit
<ev> just about to jump on a call
<smb> ev, Sorry my fault of not reading 11
<smb> ev, Whatever I said replace 10.04 with 11.04...
<ev> ah, so give old 11.04 kernels a go?
<ev> any one in particular?
<smb> ev, No I meant debug 11.04
<smb> ev, Or tell us whether 11.04 used to work
<ev> okay, will do
<smb> cking, I was not really sure we had that covered anywhere else, so I added reboot= to https://wiki.ubuntu.com/BIOSandUbuntu#Reboot_Methods (which I think you started)
<apw> sconklin1, can you check that shank-bot has done the right thing with the lucid update, its in -proposed
<sconklin1> shankbot is broken, I'm investigating
<apw> sconklin1, ooops :)
<sconklin1> I can manually push it, though
<skaet> sconklin, bjf, apw - can you join on a call in 10 minutes (info sent by google calendar) to discuss testing appropriate for the lucid kernel in -proposed?
<apw> ogasawara, we just uploaded yes? will you be uploading when 3.0 drops as well ?
<ogasawara> apw: yes and yes
<apw> trying to schedue adding overlayfs
<apw> so i guess it makes most sense to shove it in with 3.0
<apw> i'll get it applied shortly
<ogasawara> apw: ack
<ogasawara> apw: assuming 3.0 lands before end of next week, I'll likely just do one more upload next fri before Alpha3
<ogasawara> apw: we can squeeze one more in though if you wanted to get overlayfs in and tested
<ogasawara> apw: the builds go quicker now since we dropped versatile
<apw> ogasawara, i think we are expecting it 'today' as he was g+ing that it would have been out yesterday other than this error
<ogasawara> apw: yep, was just reading the LKML post
<bjf> sconklin, apw, my input: yes it should be tested, it should be a full testing pass
<skaet> https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/ChangeSummary/10.04.3
<cjwatson> reassigned bug 801610 to the kernel and marked it Confirmed, but then I remembered in the past that marking kernel bugs Confirmed without doing something else to them caused the kernel team to miss them; is that still true?
<ubot2> Launchpad bug 801610 in linux "Include enic & fnic drivers in ubuntu-installer" [High,Confirmed] https://launchpad.net/bugs/801610
<tgardner> cjwatson, I'll take care of it
<brendand_> apw - what's this lucid bug the proposed kernel is meant to fix?
<cjwatson> tgardner: thanks
 * ppisati -> gym
<ogasawara> heh, I like proxying through bjf's mumble
 * smb bets that this has a nasty meaning in the uk... :-P
<apw> ogasawara, heh thats soundinf pretty dodgy
<ogasawara> heh, for once I'm speechless
<smb> sconklin, Ok, lbm for lucid got uploaded to the ppa (and I pushed the tree)
<sconklin> smb: ack
<apw> brendand, the fix in that kernel is for eucalyptus
<apw> brendand, something to do with java not starting
<brendand> apw - don't have a # by any chance?
<apw> bug #588861
<ubot2> Launchpad bug 588861 in linux ""pad block corrupted" error when trying to register an image with 2.6.34 kernel" [High,In progress] https://launchpad.net/bugs/588861
<apw> brendand, ^^
<apw> tgardner, i see 2011-1020 applied to everything but natty/* is that intentional
 * jjohansen lunch
<tgardner> apw, just took a lunch break. I'll get natty applied shortly
<apw> tgardner, ahh thanks
#ubuntu-kernel 2011-07-22
 * smb shuffles in
 * apw waves to smb
 * smb waves back to apw
<apw> ogasawara, about ?
<apw> ogasawara, ok then ... i've fixed up the lack of attribution of the rebase to 3.0 and pushed on an abi bump so it'll build
<kees> apw: okay, so, the pending/released flipflop we have is due to running certain scripts on our end in the wrong order. basically we need to do gitscan, then usn-mismatch, then the usn-publication-sync. can you do a quick gitscan and I'll merge and sync correctly today?
<kees> if we do the usn-pub-sync first it thinks the usn db shows a given cve as being published and closes it.
<ogasawara> apw: cool, thanks for doing the rebase
<apw> ogasawara, i didn't re
<apw> ogasawara, i didn't rebase ... you did
<apw> kees, i think now that the 0711 has a version for it and its released i won't argue with the usn
<ogasawara> apw: hrm, I hadn't done the actual rebase to 3.0 final
<ogasawara> apw: I was gonna do it first thing this morning, eg now
<ogasawara> apw: maybe tgardner did it?
<kees> apw: true, but after making the usn-publisher not change versions, we ended up in a kind of goofy situation. perhaps I can further improve it to ignore versions greater than the USN's package version
<apw> the committer was you i thought ... and on rebase normally the committer becomes the rebase-er i thought
<apw> so ... likely was tim anyhow but its looking ok
<apw> ogasawara, i'd like to quickly test with overlayfs and push that in before it gets uploaded if that ok with you
<ogasawara> apw: works for me
<ogasawara> apw: I've got some more modular config review changes to push too
<apw> ogasawara, go ahead and push them whenever
<ogasawara> apw: pushed
<apw> ogasawara, i have built kernels with overlayfs in, if that boots in the livecd i'll push it and then test aufs
<ogasawara> cool
<apw> i have kernels with and without
 * apw shouts at his download link ... get on with it i need that CD image now
<apw> kees, ahh i see ... if the version doesn't match my version i will fix ti and move it pending
<apw> kees, but if its matching the version it would be, even if its only in -proposed then i won't touch it
<apw> as i actually can't tell and assume you do any pending -> something transitions
 * kees nods
<tgardner> ogasawara, does it seem like a good day to you for an upload ?
<ogasawara> tgardner: yep, just waiting for apw to finish up with testing some overlayfs patches he wants to shove on top
<ogasawara> tgardner: I assume it was you who did the 3.0 rebase?  if so, thanks!
<tgardner> ogasawara, cool. I pushed the rebase last night so I could try it out on emerald
<tgardner> ogasawara, bjf: headed into the office now. can't get in before 0700. biab.
<kees> fri kernel upload? brave! :)
<apw> kees, na not as much as you'd think as it takes days to build, and does't take effect till meta goes in
<apw> kees, so its actually a perfect day to upload
<kees> oh, yeah, i guess with an abi bump, that is perfect
<apw> yeah
<apw> kees, so we have a couple of cves outstanding against hardy, one of which at least is going to be a heap of mess required to backport anything close to something thats workable
<apw> whats our policy on that kind of thing, if we decide the risk is very great
<kees> which cve is it? if it's not a serious issue, we can choose to ignore it or work around it. it's a case-by-case thing.
<apw> kees, the one i am particularly unsure about is the epoll recursion one, which likely is a heap to fix, i've not yet tried but it feels like it may well be... so was interested in the process
<kees> i try to be risk adverse, which normally means fixing bugs, but if things are really ugly, not fixing is the safe plan
<apw> i'll let you know when i've tried and failed :)
<kees> heh
<ogasawara> tgardner: you rebuilding oneiric chroots on tyler?
<tgardner> ogasawara, yep
 * ogasawara goes to hammer on tangerine then
<tgardner> ogasawara, they were in an intermediate state, so I thought I'd just rip 'em out and start over
<ogasawara> tgardner: works for me
<tgardner> ogasawara, didn't think you were on tyler
<tgardner> yet
<ogasawara> tgardner: nope, only just noticed when I went to kick off a build
<ogasawara> wow, we're not in the list of top 5 packages for bugs reported against last week
<ogasawara> we must be losing our touch :)
<sconklin> ogasawara: I can 'fix' that
<ogasawara> heh :)
<sconklin> that's actually great to know. I've been worrying about the regressions we did have, but perhaps we're having fewer and tracking those better - so it seems worse than it is
 * ogasawara back in 20
<ppisati> tgardner: can you take a look at the omap4 build?
<ppisati> tgardner: i was told to disable the abi check since this was a handcrafted pkg
<ppisati> tgardner: but it seems it was checking there
<tgardner> ppisati, yeah, I'm in the middle of figuring it out, but got distracted. I'll get it re-uploaded sometime today.
<ppisati> tgardner: k
<cking> ogasawara, so is my S3 systemtap script broken for oneiric?
<ogasawara> cking: bug 754711 mentions it is, but i've not actually confirmed
<ubot2> Launchpad bug 754711 in linux "[Dell Studio XPS 1340] Doesn't enter suspend mode" [High,In progress] https://launchpad.net/bugs/754711
<cking> ogasawara, ok - I will look at that in the next 24 hours
<ogasawara> cking: no hurry, it can wait till next week
<ppisati> tgardner: i think it misses three files
<ppisati> tgardner: http://pastebin.ubuntu.com/650086/
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/809878
<ubot2> Ubuntu bug 809878 in linux "Wireless network & graphics card stop working after upgrade to 2.6.38-10" [Undecided,New]
<apw> Daviey, did we confirm it was the java update which was the problem in this case ?
<bdmurray> bjf: it looks like my kernel-driver- tagging of oops reports was incomplete as I only got those with EIP and not RIP
<Daviey> apw: We haven't identified what introduced it yet.
<apw> Daviey, ok cause i just heard people blaming it as if it was definatly it
<Daviey> apw: blaming "it"?
<Daviey> The two obvious candidates are either openjdk or kernel.
<apw> Daviey, blaming openjdk change for starting to tickle the existing kernel bug
<apw> Daviey, you were going to back that out to confirm i believe
<Daviey> apw: Who did you hear?
<apw> Daviey, kate just said "we would have caught the issue with openjdk ...."
<apw> and i wanted to confirm it was confirmed that it was the openjdk update which was the 'cause'
<Daviey> apw: Ah. you are sneeking on the call?
<apw> (obviously the kernel bug is real and is the root cause)
<apw> not sneaking i was invited
<Daviey> apw: Oh sure, didn't mean it like that.
<Daviey> apw: I'm not entirely sure it's worth the time investment to discover it.. although sucky.
<mfilipe> sforshee, aff, I don't understand that intel bug 
<mfilipe> it has 1+ year old and it is a very basic feature 
<mfilipe> and the Chris Wilson doesn't say nothing :(
<tgardner> ppisati, refetch HEAD for ti-omap4. I think it'll build now, but I'm still gonna upload to the c-k-t PPA first just to make sure.
<sforshee> mfilipe, which bug are you talking about?
<ogasawara> jjohansen: the talk you gave at ubuntu dev week about bisecting, did that get translated into a wiki by chance?
<ogasawara> jjohansen: no worries if not, just wanted to point someone at it for how to bisect.  I can always point them to the classroom logs.
<jjohansen> ogasawara: hrmm, no its on the todo
<mfilipe> sforshee, https://bugs.freedesktop.org/show_bug.cgi?id=38750
<ubot2> Freedesktop bug 38750 in DRM/Intel "[Arrandale] Intel Core i3 External Monitor Wavy Output" [Normal,New]
<jjohansen> ogasawara: logs are here https://wiki.ubuntu.com/MeetingLogs/devweek1107/KernelDebugging
<ogasawara> jjohansen: thanks
<sforshee> mfilipe, ah, that one :)
<sforshee> yeah, it's annoying, I think they understand what needs to be done but just haven't done it, not sure why
<mfilipe> sforshee, yep, he didn't say nothing yet and has MUCH people want the solution 
<apw> ogasawara, ok i've pushed up the overlayfs changes, they seems to build, and boot ok, and i am able to use CDs with overlayfs and aufs2 as their union soln.
<ogasawara> apw: awesome, I'll get it prepped for upload then
<apw> ogasawara, cool, thanks
<ogasawara> apw: did you want your SOB added to the overlayfs patches?  I've gotta mark some patches from the delta review as SAUCE anyways, so I could fix them up while I'm at it
<apw> ogasawara, ahh yes i meant to do that
<ogasawara> apw: ack, I'll add it and push
<apw> good spot thanks
 * bjf -> lunch
 * cking --> EOD
<adam_g> hey all.. anyone from the kernel team have any suggestions on how to handle Bug #799630 and its relatives? 
<ubot2> Launchpad bug 799630 in drbd8 "package drbd8-source 2:8.3.7-1ubuntu2.1 failed to install/upgrade: drbd8 kernel module failed to build" [Low,Incomplete] https://launchpad.net/bugs/799630
<sforshee> adam_g, why is there a dkms package for drbd at all? The driver has been in mainline for quite some time.
<adam_g> sforshee: it merged 2.6.33, so it was out-of-tree in lucid
<adam_g> anyone whos back ported a kernel will break its updates
<sforshee> adam_g, if you're using a backport kernel is the driver not included?
<adam_g> i believe there is a similar issue right now with the lirc IR drivers
<adam_g> sforshee: it is, but on updates the dkms module attempts to rebuild itself against the current kernel that includes drbd, so it fails
<sforshee> adam_g, I see. Some of the errors look like redefinitions of stuff already defined in the kernel, and I don't understand why drdb is defining them at all.
<sforshee> Some of the others look like changes to kernel functions
<sforshee> so to fix it someone would have to go to the trouble to make drbd understand the differences between the versions at compile time
<adam_g> right
<adam_g> thats the question. is that something we are interseted in doing to support back ported kernels? or is there packaging magick we can employ to avoid the issue all together?
<pgraner> cnd, ping
<cnd> pgraner, hey
<pgraner> cnd, remember at UDS you fixed a box for me with the Alps touchpad?
<pgraner> cnd, what did you do?
<pgraner> cnd, I think I found the machine but was going to confirm to see if you fix is there
<cnd> pgraner, IIRC I added an /etc/modprobe.d/ file to tell it to use a specific PS2 proto to talk to the device
<cnd> but I'm having trouble recalling the specific issue and why that solved it
<cnd> if you need info you'll have to refresh my memory more :)
<pgraner> cnd, it was the right click was actually a middle, and a a tap was right mouse click
<pgraner> cnd, or something like that
<pgraner> cnd, and you had to use the proto=bare
<cnd> ok
<pgraner> cnd, whats the easiest way to tell if its an alps?
<cnd> hmmm
<cnd> trying to remember
<cnd> it's serial/ps2 so it doesn't have a hid vendor/device id
<cnd> but there is some form of id
<pgraner> cnd, udevadm?
<cnd> I need to look in the kernel code
<sforshee> adam_g, I don't know the answer to those questions
<sforshee> cnd, I was looking at it the other day. It seems each particular driver just does some magic to try to figure out if it supports a given device
<sforshee> I didn't see any universal way to identify a vendor/model
<cnd> pgraner, the way the ps2 mouse module works is there's a core piece of code that calls out to all the loaded modules
<cnd> and each module tries to identify the device
<cnd> there's no standard way of identification
<cnd> each manufacturer has their own special ps2 query command to get the version
<cnd> and say it's a new device that linux doesn't know about, then it will just show up as a bare ps2 mouse I think
<cnd> so the only way to know for sure is to figure it out from the product specs
<cnd> and/or other people's bug reports :)
<cnd> for alps, chances are that if the trackpad isn't working right, then it's an alps :)
<sforshee> cnd, pgraner: If you can get the OEM Windows install on a system it can tell you what kind of device it is too
<pgraner> sforshee, cnd, all demsg tells me is that is: i8042: PNP: PS/2 Controller [PNP0303:KBC0,PNO0f13:MSA0] at 0x60,0x64 irq 1,12
<cnd> pgraner, if you take out the modprobe.d file so it doesn't lock to the bare proto, it might be recognized as alps
<cnd> comment out the modprobe.d file and then rmmod and modprobe psmouse
<pgraner> sforshee, cnd, found it: input: AlpsPS/2 ALPS GLidePoint as /devices/platform/i8042/serio1/input/input10
<pgraner> sforshee, its on my netbook :(
 * jjohansen lunch
<cnd> heh
 * tgardner --> EOW
 * herton --> eow
#ubuntu-kernel 2011-07-23
<kees> apw: the linux in lucid -proposed .. that fixes a regression? when was the regression introduced?
<daurnimator> how stable is 3.0rc7?
<ohsix> verily
<apw> kees, yes a regression introduced in v2.6.21, but only exposed by a java security update about 5 weeks back
<kees> .21?? hah, whoa
<apw> kees, a well old problem, odd that it was exposed all of a sudden ... 
<apw> kees, i am not aware of any security issue related to it, nor anything other than euca setup which tickles it... but i can't say i've looked very closly
<apw> kees, bah the update didn't go out anyhow after all that panicing last week over it
<kees> hm, I guess it shouldn't go to -security. ah well, I'll upfate the bug
<kees> sconklin: hm, I can't change security-signoff from "fix released" to "invalid" for LP 813507 
<ubot2> Launchpad bug 813507 in linux "linux: 2.6.32-33.71 -proposed tracker" [High,In progress] https://launchpad.net/bugs/813507
<sconklin> hrmph, let me look (and this doesn't mean I'm really here)
<sconklin> :-)
<sconklin> kees: what does it complain about?
<sconklin> and you're sure you're logged in, right? yesterday some of us got spontaneously logged out and it caused some confusion like this
<sconklin> I just changed it.
<kees> sconklin: I'm logged in, it literally gives me no options in the drop-down
<sconklin> It occurs to me that changing things from fix-released may be one of the special cases that launchpad requires some odd privs for
<kees> sconklin: am I missing some kind of permission?
<kees> yeah
<kees> sconklin: do you have the ability to flip it? I thought that bug fix was a security regression, but it's not, so it shouldn't go to -security
<sconklin> I can do it. There are some operations that are reserved for package uploaders.
<sconklin> I filpped it
<kees> okay, thanks :)
<sconklin> I just talked with Allison about permissions challenges like this, I'll ad this to the list
<sconklin> And we're in luck! The workflow bot apparently didn't run while it was set wrong :-)
<sconklin> it should run in about 4 mins and set that for release - I'll watch until that happens
<kees> heh, yeah :)
<sconklin> by the way, if this ever happens again, setting a tag of "verification-failed" on the bug is one sure way to stop anyone from publishing in any case, even if it's not exactly true. It's our big red button
<sconklin> hmm, it didn't change anything. oh, found a bug in the workflow bot. Ok, I guess I'm 'here'.
<sconklin> kees: ok, that's fixed, and it did the right thing. That package if ready for publishing. Thanks for flagging me on this
#ubuntu-kernel 2011-07-24
<hemin> Hi, I modified the kernel source.. and now I want to recompile the kernel.. so when i go to /usr/src/linux/kernel and do make it doesnt work.. it says "No rule to make target `FORCE', needed by `/config_data.gz'.  Stop." .. Do I have to recompile the whole kernel source again just to include a small change??? How can I do it faster?
<quentusrex_> Anyone have advice on how to track down the cause of high load on a fresh ubuntu server caused by ksoftirqd processes?
<quentusrex_> I have two servers with identical hardware, both freshly installed ubuntu 11.04 server 64 bit, fully updated and only one of them is having this problem.
<quentusrex_> After a wipe and reinstall the problem still exists, on the same server.  
<quentusrex_> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/815540
<ubot2> Ubuntu bug 815540 in linux "Server becomes unresponsive after spawning 16 ksoftirqd processes" [Undecided,New]
<quentusrex_> I am testing the pre-proposed kernel now on the machine. I will report back if that resolves the issue. Also, on the 2.6.38-10 kernel adding noapic to boot options does nothing.
<quentusrex_> in particular I'm testing: linux-image-2.6.38-11-server_2.6.38-11.47pre201107220904_amd64.deb
<quentusrex_> That version suffers from the same problem. 
#ubuntu-kernel 2012-07-16
<davmor2> guys I'm hitting an issue on install that I had before in precise.  I get the the screen Choose a Picture, the webcam is initiated and then locks up the system, this is a regression again over precise, however I'm not sure how I can help diagnose it for you
<virtx> hello
<virtx> is there a way to recompile *only* one module (ext2, in this case) using build directory in /lib/modules ?
<virtx> i just copied the ext2/ dir from kernel tree... how can i compile it?
<virtx> uhuh?
<caribou> smb: ping
<hggdh> ogra_: hi, a quick question -- are there no new images for quantal server omap4?
<ogra_> hggdh, preinstalled seems to fail atm, we are actually waiting for x86 server to switch to squashfs images and were planning to do that switch as well on arm
<ogra_> if you need to install headless use netinst 
<hggdh> ogra_: thank you sir
<jjohansen> ogasawara, bjf: I plan to be joining you guys wed, thurs
<bjf> jjohansen: ack, 
<ogasawara> bjf: ack.  just fyi, we'll only be around till around 1pm on wed.  we're doing a team activity wed afternoon.
<ogasawara> bah
<ogasawara> jjohansen: ^^
<jjohansen> ogasawara: oh, hrmm okay that will be fine. /me can't make the other days
<slangasek> apw: /etc/initramfs-tools/initramfs.conf
<slangasek> (fwiw)
<slangasek> apw, smb`: to test disabling plymouth, hack /usr/share/initramfs-tools/conf-hooks.d/cryptsetup
<bjf> arges: just updated the leap-second incident page
<infinity> bjf: I'm confused by bug #1020888 which has a "verification-done" tag, but the regression-testing task isn't done.
<ubot2> Launchpad bug 1020888 in linux-armadaxp "linux-armadaxp: 3.2.0-1605.8 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1020888
<infinity> bjf: Also, speaking of the verification-* tags, which you don't normally use in the kernel SRU workflow, it wouldn't hurt if you set verification-done when those tracking bugs land in the "promote-to-{updates,security}" state.
<infinity> bjf: (But, I'm going to twiddle our scripts to better interpret the kernel SRU bugs anyway)
<bjf> infinity, the bug looks correct. though we don't normally use the 'verification-needed' / 'verification-done' tags
<RAOF> Can I file a bug against linux that won't show up on any of your lists?
<RAOF> There's a drm limitation that is relevant to the system compositor; I'd like to file the bug and associate it with the blueprint, but I don't want it to bug you guys at all.
<bjf> RAOF, we are used to ignoring your bugs, a new one will not have a big impact
<RAOF> And I guess I'll add bot-stop-nagging to it, too.
<infinity> bjf: Yeah, I know you don't normally set the tag, I noticed cause it lit up green in our list. ;)
<bjf> infinity: heh, i just bugged vanhoof, he removed the tag
<infinity> (saw that too)
#ubuntu-kernel 2012-07-17
<bjf> jjohansen: you marked bug 1020888 as 'invalid' for security. this is rebased on the precise main branch. also, this release replaced a previous one in -proposed that didn't make it to -updates
<ubot2> Launchpad bug 1020888 in linux-armadaxp "linux-armadaxp: 3.2.0-1605.8 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1020888
<jjohansen> bjf: right we aren't doing USNs for armadaxp, currently they being "maintained" by OEM and the deal is that the security team isn't in general doing USNs for them
<jjohansen> bjf: so its likely you still need to do the CVE end of things, and I will just clear them through as invalid when I see them, at least until I am told to do otherwise
<jjohansen> s/they being/they are being/
<Vromoth> Hello?
<janimo> apw, seems the latest 3.5.0 rebase on rc7 does not have a tag in the repo
<janimo> Ubuntu-3.5.0-5.5 missing
<apw> janimo, i do not see it uploaded yet which would trigger tagging normally, so its not definatly 'done'
<apw> janimo, but i will check and find out why
<dcgen> Hi i am using a dell xps 14 and I wanted to know what version of the kernel which has the backlight fixed for xps should I use..
<ogra_> hmm, no ppisati ?
<janimo> apw, oh I thought the tag happens on commit not upload.thanks
<jamespage> how is the best person to direct ARM kernel requests to?
<rtg> jamespage, likely cooloney or ppisati
<cooloney> jonmasters: sorry, i just reboot my machine, what am i missing?
<rbasak> jamespage: ^^
<jamespage> rtg, thanks
<jamespage> cooloney, specifically I was trying to use the rbd module on omap4
<cooloney> jamespage: any failure when you are trying use rbd in omap4? which kernel are you using?
<jamespage> cooloney, kernel - Linux winehouse 3.4.0-204-omap4 #9-Ubuntu SMP PREEMPT Mon Jul 9 12:56:56 UTC 2012 armv7l armv7l armv7l GNU/Linux
<jamespage> cooloney, I get a 'FATAL: Module rbd not found.' when running modprobe rbd
<cooloney> jamespage: oh, yeah, i found for ti-omap4 we disable this 
<cooloney> debian.ti-omap4/config/config.common.ubuntu:# CONFIG_BLK_DEV_RBD is not set
<jamespage> cooloney, can we enabled it? I'm assuming its disabled for a reason...
<cooloney> jamespage: is this necessary for ceph or other stuff? i found it's built as module in our master branch
<jamespage> cooloney, yes - at the moment I can run a ceph server on omap4 - but I can access block devices...
<cooloney> ppisati: do you know why we disable CONFIG_BLK_DEV_RBD for ti-omap4?
<jamespage> cooloney, the same would apply to other ARM kernels - its specifically important for server targets
<cooloney> jamespage: cool, i will send out patch for this
<jamespage> cooloney, thanks v. much :-)
<cooloney> jamespage: thanks for pointing out, btw, running ceph on ARM is quite cool
<jamespage> cooloney, if we can get this module and openvswitch module enabled for ARM archs == fully functional openstack!
<jamespage> backed by ceph for scalable instance volume block storage - nice!
<jamespage> zul, ^^ FYI
<infinity> jamespage: the higbank config should match master pretty closely.  armadaxp might need a twiddle, since it was originally cargo-culted from ti-omap4, I think.
<infinity> jamespage: So, double-checking all the configs and filing bugs might be sane.
<infinity> jamespage: Doubly-so, if this should be fixed in the SRU kernels too.
<jamespage> infinity, where do I look at kernel configs?  I can do a cursory check
<infinity> jamespage: I'd just grab the actual debs and check /boot/config-* inside.  Easier than constructing it from the twisty maze of bits in debian.*/ in the source. ;)
<jamespage> infinity, ack - I'll take a look
<cooloney> jamespage: OPENVSWITCH should be enabled by apw in both ti-omap4 and master
<hggdh> kernel folks: armadaxp 3.2.0-1605.8-armadaxp does not have ip_tables.ko. Is this how it should be?
<pgraner> jsalisbury, did the web cam patch make it into a released kernel yet?
<bjf> hggdh: looking at it
<ogasawara> pgraner: it did and I uploaded to our PPA to build.  I'll copy it out to the release pocket when it's all done.
<janimo> hggdh, seems like in armadaxp ip_tables is built in not a module
<hggdh> janimo: perfect, thank you
<janimo> hggdh, is that a failure actually - I do not recall explicitly making it built in
<janimo> this may be the first time these tests are run on armadaxp
<hggdh> janimo: I believe so, I do not know of anybody else running these tests except me, the security team, and (of old) gruemaster
<janimo> hggdh, so is there a need for concern if it is built in?
<hggdh> janimo: no, not really, but the QRT must be adjusted for that
<janimo> hggdh, I should probably make it a module though to be in line with the other kernels
<hggdh> janimo: I agree 100%. So can we assume you are making these changes for the next build(s) -- precise and quantal?
<janimo> ikepanhc, cooloney unless you know something about it needing to be built-in
<janimo> hggdh, yes. For precise, and the same package will likely make it to quantal (copied)
<janimo> so no need to adjust the test either I guess
<hggdh> janimo: perfect, thank you much
<ikepanhc> janimo: none
<ikepanhc> janimo: I am ok with build-in or module
<janimo> hggdh, np thanks for testing this kernel thoroughly :)
<janimo> hggdh, any other tests that you know of before this can be decalred ok for -updates? just curious
<hggdh> janimo: I am marking the bug now fix-released, qa-testing-passed
<infinity> janimo: Have you checked if you're in line with other modules, compared to master?
<infinity> janimo: See, eg, discussions above about CONFIG_BLK_DEV_RBD in ti-omap4, no idea if that's enabled in armadaxp.
<janimo> infinity, no config checking done, I should probably do that to when enabling this change
<janimo> infinity, just copying over from mainline/highbank should do it or do I need a line by line review?
<infinity> janimo: Better answered by someone like apw or ogasawara (they do line-by-line reviews).
<infinity> janimo: But you can probably cheat a bit, given that master already has sane reviews, and you can likely cargo-cult a bit, and adjust for platform differences.
<janimo> alright
<janimo> will schedule this for next SRU.
<infinity> Well, FSVO "sane".  I vaguely recall a rather large amount of alcohol involved in the config review I participated in.
<janimo> or actually maybe ikepanhc will do it if we switch tasks (armada/highbank) for a while
<ikepanhc> janimo: yes, I am thinking on this
<apw> infinity, the alcohol is needed to avoid self termination
<hggdh> janimo: bug is ready for next stage
<ogasawara> janimo: we're sprinting this week and doing a config review, let us know if there is a particular config we need to examine
<janimo> infinity, is there anything you participate in that does not involve large amounts of alcohol?
<infinity> ogasawara: armadaxp/precise should probably look as close to master/precise as possible.
<janimo> hggdh, if next stage is taken care of by bjf's bot or some friendly admin I'm not touching it :)
<ogasawara> infinity: indeed, that's the goal
<infinity> ogasawara: No idea how off it is currently, but I'd guess "a bunch".
<ikepanhc> janimo: ok, I will do this these two weeks, let me pick up those "purple" items again
<hggdh> janimo: bjf's bot will do it
<infinity> hggdh: Still needs a regression-testing signoff, surely?
<hggdh> infinity: already done
<infinity> hggdh: Nu uh.
<hggdh> infinity: barf on hitting enter on the bug
<hggdh> check it now
<hggdh> bloody hell, barf again :-)
<infinity> Hahaha.
<infinity> Launchpad loves you. ;)
<infinity> Right, *now* the bot will DTRT.
<infinity> Or, I might pre-empt it and just take the release tasks.
<infinity> After I smoke.
<infinity> ogasawara: Waitaminute.  Back up.  Did you just imply that you're doing config reviews sober?
<ogasawara> infinity: no one said we were sober
<infinity> ogasawara: Phew.
<infinity> janimo: Released.
<janimo> infinity, \o/ thanks
<infinity> ogasawara: Say, while you guys are sprinting, want to take a vote about getting me added to the 2550(kernel_team) and 2616(kernel_cdev) UNIX groups for emergency use and random collaboration?
<rtg> infinity, I would prefer that you commit changes to your repository (perhaps on zinc) and email a pull request to the k-team list. I notice that you don't have a publicly visible directory on zinc. I can request that one be created for you.
<rtg> That would necessitate joining kernel_team, but not kernel_cdev.
<infinity> rtg: I'm sure that could be done.  It's been a while since I've had to do any emergency faffing, but it's irksome to then get hunted down by the "it's not in git" police. ;)
<infinity> rtg: And kernel_team would probably be enough for collaboration on other projects, yes (like, if we want to keep initramfs-tools on zinc)
<rtg> infinity, ok, I'll start an RT and get you a public directory.
<infinity> rtg: Danke.
#ubuntu-kernel 2012-07-18
<amitk> I'm testing out the quantal kernels on precise through the x-swat ppa. Are the binary drivers supposed to work after upgrading? I have a broken broadcom wireless that needs jockey intervention in precise.
<amitk> apw: smb` : whenever you guys come online ^^^
<hggdh> janimo: ping
<janimo> hggdh, pong
<hggdh> janimo: PM, if you do not mind
<ogra_> so how do i suppress the building of the tools packages, do_tools=fales is obviously ignored here 
<ogra_> *false
 * ogra_ curses
<bdmurray> smb`: You did a fair bit of work on kerneloops during quantal right?  bug 1026251
<ubot2> Launchpad bug 1026251 in kerneloops "kerneloops assert failure: *** glibc detected *** /usr/sbin/kerneloops: free(): invalid next size (normal): 0x099254a0 ***" [Medium,New] https://launchpad.net/bugs/1026251
<ogasawara> infinity: heya, so we've just tested building the quantal kernel in our canonical-kernel-team PPA (ie the same way we do for kernel SRU's)
<ogasawara> infinity: I've just used the `./copy-proposed-kernel quantal linux` and tweaked one line in the script so that it goes directly to the quantal release pocket rather than proposed
<ogasawara> infinity: ie the copy-proposed-kernels script from the ubuntu-archive-tools repo
<ogasawara> infinity: I'm curious if we will hit the same issue as SRU's kernels where the binaries will actually land in Universe rather than Main and need some help getting sorted
<infinity> ogasawara: Almost certainly will hit the same issue, yeah.
<ogasawara> infinity: ok, so my other question is that we actually expected this to land in the New queue and then ping you or an archive admin to approve it, but it appears it actually went straight on through
<ogasawara> infinity: and bypassed New queue processing
<ogasawara> infinity: is this ok? ie or should we not do this?
<infinity> ogasawara: Right, which is the same reason you have the issue in -proposed too.
<ogasawara> infinity: I have to admit I find it a bit scary
<infinity> ogasawara: binary NEW isn't taken into account on source+binary copies.
<infinity> ogasawara: Ultimately, it's probably not doing anyone any favours to use the PPA->development workflow, since we then need to wait for a publishing cycle and fix the overrides, where we could have done it in the NEW queue before accepting instead.
<infinity> ogasawara: One could (and rightfully should, and I think there's a bug about it) argue that copies with NEW binaries should land in NEW and actually be manglable, but that's certainly not the case right now.
<ogasawara> infinity: ok, will discuss with my team.  our thought is that we should be using the same process for the SRU and devel kernels, which is why we tried the build in our PPA for this latest upload.
<infinity> ogasawara: Also, what was this about script tweaking?  I see a kernel in -proposed...
<ogasawara> infinity: hrm, I thought I'd tweaked the copy-proposed-script to copy to the release pocket, but I'm staring at the script and my change isn't there
<infinity> Heh.
 * ogasawara must not have saved
<infinity> Well, no big deal.  It's better off in proposed anyway, if it's also broken WRT overrides. :P
<ogasawara> === modified file 'copy-proposed-kernel'
<ogasawara> --- copy-proposed-kernel	2012-06-27 03:17:01 +0000
<ogasawara> +++ copy-proposed-kernel	2012-07-18 19:05:42 +0000
<ogasawara> @@ -48,7 +48,7 @@
<ogasawara>  
<ogasawara>  ubuntu.getArchive(name='primary').copyPackage(from_archive=kernel_ppa,
<ogasawara>          include_binaries=True, source_name=pkg, to_series=release,
<ogasawara> -        to_pocket='proposed', version=version)
<infinity> Since it needs a publisher cycle or two to fix it, having the broken version released to -release would be unpleasant.
<ogasawara> +        to_pocket='Release', version=version)
<ogasawara>  
<ogasawara>  # TODO: adjust this script to use find-bin-overrides or rewrite
<ogasawara>  # find-bin-overrides to use lpapi and use it here.
<ogasawara> infinity: indeed
<ogasawara> infinity: so it's best it didn't do what I thought I did
<ogasawara> infinity: ok, so I'm going to relay all this to apw and rtg
<infinity> Anyhow.  Overriding and such now.  Will promote when it all looks sane.
<infinity> Using this workflow slows you down a tiny bit, but I'm not sure if that's something you care deeply about.
<infinity> And the option to upload directly is still there for emergencies.
<ogasawara> infinity: right, I don't think we deeply care
<ogasawara> infinity: anyways, will relay all this to apw and rtg
 * infinity nods.
<ogasawara> infinity: thanks again, we'll buy you a beer, but then drink it :)
<infinity> ogasawara: *glare*
<epikvision> for kernel testing, how do you know what hardware you have?
<epikvision> http://paste.ubuntu.com/1099090/
#ubuntu-kernel 2012-07-19
<LetoThe2nd> is https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide maybe outdated / incorrect?
<LetoThe2nd> the suggested git clone git://kernel.ubuntu.com/ubuntu/linux-2.6 just gives me "fatal: The remote end hung up unexpectedly"
<RAOF> Correct.
<LetoThe2nd> i guess it should be git://kernel.ubuntu.com/ubuntu/linux.git
<LetoThe2nd> judging from gitweb, right?
<RAOF> You want the bit directly above there, where it says you're after git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git
<LetoThe2nd> RAOF: nah, i picked it on purpose because of the referencing
<skaet> ogasawara, will the kernel uploaded yesterday (3.5.0-5.5) be the one we'll be sticking with for A3 or is there another planned drop?
<ogasawara> skaet: if upstream v3.5-rc8 lands, we'd like to upload it, but if not we'll likely stick with 3.5.0-5.5.  I currently don't have any critical bug fixes queued to warrant another upload at this time.
<skaet> ogasawara,  thanks.   
<bjf> utlemming, we need to have the discussion here
<apw> utlemming, yo ... 
<utlemming> howdy
<apw> bug #1026690
<ubot2> Launchpad bug 1026690 in linux-meta "3.0.0.-23.38-virtual kernel regression kills EC2 instances" [Critical,Confirmed] https://launchpad.net/bugs/1026690
<apw> smb, ^^
<smb> yo
<utlemming> The impact is that all 32-bit EC2 instances that consume that SRU are toast
<smb> I am trying to find out what taht kernel has in and whther its the latest
<utlemming> Instance-store users will lose all data, and EBS users will have a painful recovery
<bjf> utlemming: we are looking
<utlemming> bjf: thanks
<smb> utlemming, Was the last version working? (-23.37 I think)
<utlemming> smb: yes, that is the latest
<utlemming> smb: we didn't see problems before .38
<infinity> 22.36 was the previous.  23.37 was a dud.
<smb> Hm, actually would be one before because that one is a no-change uplaod
<smb> yeah
<smb> And that one only had one xen specific patch in which would filter some cpu feature bits...
<smb> Does not sound likely to be relevant there...
<smb> And the cmpxchg fix I thought of was in before that or with it
<smb> Ah
<smb> Think I may have found something, there was a fix for a fix in precise but does not seem to have made it to stable of 3.0
<smb> thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
<infinity> Should I violently pull that binary from -updates while you guys sort this out?
<utlemming> infinity: +1
<smb> bjf, herton If we could pick a77da6dcf81fb3346d3449a4925515343c9f18b9 from precise and do a rebuild?
<infinity> Removing packages:
<infinity> 	linux-image-3.0.0-23-virtual 3.0.0-23.38 in oneiric i386
<infinity> Comment: Broken SRU; blows up EC2 instances
<infinity> Remove [y|N]? 
<infinity> ^-- Should do?
<infinity> (It'll mean people get an error from apt on upgrade, but sure beats the alternative)
<utlemming> infinity: if there was a work around, I'd say leave it, but given that it kills the instance, leaving it is inviting user pain
 * infinity nods.
<utlemming> kernel team, do disagree about pulling it? 
<infinity> Too late if they do.
<utlemming> lol
<cking> bjf, http://bazaar.launchpad.net/~colin-king/ecryptfs/test-fixes/revision/705
<smb> herton, sorry 6e60d7d7667a47b1b8760a45d95547799f4df2c5
<utlemming> infinity: will that be reflected in the meta-data later? 
<infinity> utlemming: It'll drop out of the Packages file on the next mirror pulse.
<infinity> (And off disk)
<utlemming> infinity: great. I'm just thinking of how long before it propigates to the S3 mirrors.
<cking> tyhicks, i've got a couple of eCryptfs patches that fix up some issues we see on our automatic eCryptfs tests, can you pull or merge these sometime for us?
<apw> utlemming, #is maintain those i think ... perhaps they can expedite
<utlemming> apw: yup, I'll go over there and ask them
<infinity> IS can 403 files on the mirrors they own.  That said, by the time they finish that, this pulse might happen.
<infinity> (It'll happen in about 25m)
<bjf> skaet: do you have an incident report started ?
<apw> infinity, indeed.  and thankfully it is oneiric so there should be a much lower penetration
<skaet> "https://wiki.ubuntu.com/IncidentReports/2012-07-19-oneiric-kernel-regression-kills-EC2-instances
<skaet> bjf,  ^ just started.
<infinity> apw: Hopefully, yeah.
<infinity> bjf: If you guys can fast-track an SRU with just this fix, I'll be happy to help babysit it through the process.
<bjf> infinity: ack
<tyhicks> cking: Yeah, sorry I haven't been able to get to it yet. Looking now.
<infinity> Should be able to skip most everything except a "does it boot and, like, contain useful files" regression test, and obviously testing that it fixes the EC2 breakage.
<apw> utlemming, this issue has only been seen with O instances right ?
<infinity> bjf: And it might not be outlandish to suggest that "spin up an EC2 instance on $release and upgrade to the -proposed kernel" should be part of the standard QA process here. ;)
<bjf> gema, pgraner, ^
<pgraner> bjf, I thought we did that already as part of the SRU testing, I'm waiting on hggdh to confirm
<utlemming> apw: checking all the others now
<pgraner> bjf, and for some reason if we don't then we will 
<slangasek> (low priority, feel free to ignore me during the crisis) anyone know why we don't set CONFIG_EARLY_PRINTK_DBGP in our kernel configs?
<apw> slangasek, will look
<utlemming> apw: confirming the others now. 
<slangasek> apw: it happens that this would be handy for me at the moment while trying to debug UEFI boot failures at Plug Fest; but I have no idea if it would be sensible to enable it generally
<utlemming> apw: precise is unaffected with 3.2.0.26.28
<apw> slangasek, ok that sounds like something that might be safe to have on if the kit is missing, and it sunds like cking may have one.  is there a bug on this, i want to get cking to investigate
<bjf> utlemming, we believe we've identified the bad commit as well as the commit that fixes the issue
<slangasek> apw: haven't open a bug yet, I can do so
<bjf> utlemming, this problem seems to be unique to Oneiric kernels which only have the bad commit and not the fix
<tyhicks> cking: done - thanks!
<bjf> utlemming, we are working to verify all of that
<apw> slangasek, awsome, get me the number and i'll get it looked into.  efi not working in early boot is likley to be a high probabality in the next cycle or two
<utlemming> bjf: glad to hear. If you have a build of the fix, I'll test it too
<hggdh> pgraner, bjf: we fire off EC2 from the ./current/, not from $RELEASE
<bjf> hggdh: do we do any kernel upgrade testing ?
<hggdh> bjf: we fire off an existing ec2 image (from the current set), enable -proposed, and run a dist-upgrade; then reboot, and run the tests
<infinity> hggdh: On i386 as well?  This was i386-specific, so an amd64 test wouldn't have caught it.
<utlemming> hggh: we caught it here: https://jenkins.qa.ubuntu.com/view/ec2%20AMI%20Testing/view/Overview/job/oneiric-server-ec2-daily/
<utlemming> which tests the daily ec2 image builds
<smb> utlemming, Can you do quick verifications when I get you a test kernel build?
<utlemming> smb: yes...and gladly
<hggdh> infinity: on both i386 and amd64
<infinity> hggdh: Curious that this slipped through, then, given that it appears to be universally fatal. :/
<utlemming> hggdh: do you have logs of that test?
<hggdh> indeed
<smb> utlemming, ok, give me a couple of minutes. 
<infinity> hggdh: Can you re-do your test by hand before the mirrors pulse the kernel out of existence, and prove/show that the test worked for you?  It would be valuable to know how or why this slipped through the cracks.
<apw> infinity, +1
<hggdh> infinity, utlemming: I am re-running them, but I guess I already found the reason -- I mistakenly got a amd64 run in place of the i386
<hggdh> and I did get the bad kernel on the dist-upgrade
<apw> hggdh, sounds like we need a arch/kernelversion/machine confirmation test as the first test in every test set
<bjf> hggdh, if these were matrix tests, that might make it more difficult to have this case ?
<infinity> Not that we can test on all hardware (sadly), but at least being able to test Xen and KVM machines seems easy enough.
<hggdh> bjf: sort of. I certainly see the reason to have a coverage like in the current ec2 tests (which we do not have right now)
<hggdh> (meaning a mix of regions/types/etc)
<bjf> utlemming, should QA be running the ec2 tests that you found this issue with ?
<utlemming> bjf: well, how we found the issue was making sure that our daily builds work, not the package set
<utlemming> bjf: so if they have proposed covered, then I think not
<hggdh> utlemming: actually, yes (in this case), since you grab the current (daily) kernel, and it was updated already
<hggdh> but this is a post facto finding
<utlemming> hgggh: right
<bjf> pgraner: who on your team should i add to the incident report ?
<hggdh> bjf: I
<hggdh> infinity: the idea is to expand the kernel tests as much as possible (and we finally can test on both Intel and AMD)
<hggdh> for bare-metal, of course
<infinity> Oh, crap.  Does anyone use the lts-backports of these images?
<infinity> linux-image-3.0.0-23-virtual | 3.0.0-23.38~lucid1 | lucid-updates | amd64, i386
<infinity> linux-image-3.0.0-23-virtual | 3.0.0-23.38 | oneiric-updates | amd64
<infinity> ^--- I should probably remove the ~lucid one as well, eh? :P
<infinity> (And we should re-do that backport)
<hggdh> infinity: also -- I confirm the kernel barfs
<smb> utlemming, http://people.canonical.com/~smb/lp1026690/
<utlemming> smb: testing now
<infinity> hggdh: Good, good.
<infinity> smb / bjf: Confirm that there will be a new lts-backport fasktracked to go with the oneiric update?  (and I'll pull the mirror one)
<bjf> infinity: ack, will happen
<utlemming> smb: 
<utlemming> dpkg: dependency problems prevent configuration of linux-image-3.0.0-23-virtual:
<utlemming>  linux-image-3.0.0-23-virtual depends on wireless-crda; however:
<utlemming>   Package wireless-crda is not installed.
 * smb looks confused
<smb> I would have thought we never removed that dependency for O
<utlemming> smb: I'm not sure what happened there...I threw that instance away and tried again, and it now installed
<utlemming> with out that error
<utlemming> I'm rebooting now
<utlemming> smb: fix confirmed
<smb> utlemming, uname -a it showing the +102...?
<utlemming> smb: Linux ip-10-110-55-78 3.0.0-23-virtual #38+1026690v1 SMP Thu Jul 19 17:33:51 UTC 2012 i686 i686 i386 GNU/Linux
<smb> utlemming, Ok, looks good then
<utlemming> smb: boot log looks good too
<bjf> hggdh: can you test smb's kernel as well to see if this fixes the issue for you as well?
<hggdh> bjf: doing it now
<hggdh> smb: http://pastebin.ubuntu.com/1100576/
<hggdh> smb: duh, missed a file
<hggdh> smb: no, did not
<hggdh> :-)
<smb> hggdh, Not sure what you or utlemming do, the crda dependency should have been there all time
<hggdh> smb: this one is missing linux-headers
<smb> hggdh, a second, building the all headers
<smb> hggdh, ok, its there now
<hggdh> smb: thank you
<hggdh> smb, bjf, infinity: it does reboot ok, running the tests now (should take ~ 1 hour)
<infinity> We'll have to re-do all the testing again after we build the proper package.  Call me crazy, but "it boots properly" is probably enough to start the SRU PPA process?
<henrix> bjf: git://kernel.ubuntu.com/henrix/ubuntu-oneiric.git
<henrix> ups
<henrix> smb: ^
<infinity> bjf: And when that PPA upload lands, poke me, I'll make sure to score it through the roof on PPC to get it pushed through.
<smb> henrix, looking
<infinity> henrix: Or you. ;)
<bjf> infinity: we're on it
<henrix> infinity: ack, will do. 
<smb> henrix, looks ok. 
<henrix> smb: cool
<smb> infinity, With the last version made going away, will this upload need -v to include all the changes from before?
<smb> henrix, ^ 
<henrix> smb: uploaded pkgs into zinc:~henrix/for-signing
<infinity> smb: No.
<infinity> smb: -v is just for the .changes
<smb> infinity, That is what I tried to say. But we also decided that its probably not needed as the states of bugs and that all may already be right after the last upload
<infinity> (And no point in that, since we long ago accepted the previous version)
<infinity> This is a new bug, new version, new changelog, the -v would be pointless.
<infinity> (Not that it would hurt terribly, it would just try to re-close all the old bugs again)
<smb> infinity, Right, and agreed
<slangasek> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1026761
<ubot2> Ubuntu bug 1026761 in linux "Please enable CONFIG_EARLY_PRINTK_DBGP" [Undecided,New]
<smb> henrix, should be signed now
<henrix> infinity: i'm about to upload the oneiric kernel
<infinity> henrix: Kay.
<henrix> infinity: done!
<infinity> smb: Say, why are you "stephan-bader-canonical" instead of stealing ~smb?
<infinity> smb: (We could totally get that unused account renamed and given to you)
<infinity> stefan, even.
<smb> infinity, Just because someone created that name for me (and iirc smb is already taken by someone ) and when thinking of getting the smb removed and me taking it over (because that somebody did not use it for years) I was a bit afraid of lp messup when transferring ids
<smb> I read some pages about it and some said you may loose all your groups if it goes wrong
<smb> (not so much caring about any karma )
<smb> infinity, apw would certainly approve me changing given the amount of cursing I hear whenever he has to type the long thing 
<smb> ;)
<smb> cking, blktrace was the package
<cking> smb, thanks, I will look at that :-)
<infinity> smb: It all works except for published PPAs.  And I suspect you wouldn't care about losing PPAs and having to recreate them.
<ppisati> infinity: flash-kernel is broken
<infinity> ppisati: More broken than usual?
<smb> infinity, No, not really... Cannot even remember when I updated them last
<infinity> smb: Yeah, we should talk to webops and do a hostile takeover of ~smb for you, then.
<infinity> smb: The only other thing that would go wonky is work item tracking, but reclaiming all your work items wouldn't be rocket science.
<smb> infinity, Right, and if I would loose some work items... hm, actually sounds rather good... :)
<infinity> smb: Hahaha.
<ppisati> infinity: http://paste.ubuntu.com/1100710/
 * smb will think about it when he gets back
<ppisati> infinity: it doesn't honor any /boot/boot.script anymore
<infinity> ppisati: Special.  I can look at that later, perhaps, or you can bug Oli when he's up.
<ppisati> infinity: i'll open a bug and assign it to... you/Oli?
 * smb thinks its past GBT now...
<infinity> ppisati: Open it and assign it to Oli, but give me the bug# on IRC, and I'll see if I can find time to poke it before he does.
<ppisati> infinity: ack
<infinity> smb: That's missing an L.
<smb> infinity, Hm, or a D
<smb> infinity, Depending whether we think about the same thing
<infinity> smb: I was thinking LGBT.
<smb> infinity, Lovely German Beer Time? :)
<infinity> smb: Yeah, not quite. ;)
<smb> infinity, Heh, yeah I see the web disagrees with me... :)
<ppisati> bug 1026780
<ubot2> Launchpad bug 1026780 in flash-kernel "3.0~rc.4ubuntu4 doesn't honor bootargs from /boot/boot.script anymore" [Undecided,New] https://launchpad.net/bugs/1026780
<ppisati> infinity: ^
<ppisati> infinity: ah, and btw, omap4 server doesn't start any console after the first reboot
<ppisati> infinity: and since it's a server installation, with no X&c, it's useful as a heater in summer time
<hggdh> bjf, smb, infinity: tests passed except for seccomp
<bjf> hggdh: ack, thanks
<infinity> hggdh: Was the "except for seccomp" bit expected?
<hggdh> infinity: http://pastebin.ubuntu.com/1100755/
<hggdh> infinity: we have a known issue there; I do not know it if classifies as a regression
<infinity> Mmkay.
<hggdh> jjohansen: ^ 
<henrix> infinity: are you sure you didn't scored PPC build in the with wrong signal ('-' instead of a '+')? :)
<infinity> henrix: It's scored way up, it was just behind a 2h openldap build.
<infinity> henrix: The whole mess will take >5h after that anyway, so I figured it wasn't worth killing the openldap-in-progress over.
<henrix> infinity: yeah, np. just joking :)
<henrix> infinity: it always take *ages* anyway
<infinity> We're working on the whole "new PPC hardware" thing, which should solve some of your sadness there.
<bjf> infinity, what's the schedule for that comming online?
<infinity> bjf: It needs to be purchased still, so I dunno.  There was some delay on my end with research, but it's been handed off to pgraner now.
<infinity> (That is, I've said "hey, we should buy this" and washed my hands of it)
<bjf> infinity, ah, it's one of those "in 5 years ..." things :-)
<infinity> bjf: Not that it'll be a drastic improvement for the kernel use-case.  The pandas are still neck-and-neck with the current PPC hardware anyway.
<infinity> But it will definitely keep PPC from being backlogged anymore.
<infinity> Moving from 2-CPU 2GHz G5s to 6-core 3.7GHz POWER7s (well, if they buy what I asked) should give PPC breathing room for another decade.
<infinity> At least, if the last decade with the current hardware is anything to go by.
<infinity> (My god, we've been at this for a while...)
<skaet> bjf,  you willing to take point on the incident report?   I need to run some errands, and want to make sure we have explicit handoff ;)    Since you've been making most of the updates recently...
<jjohansen> hggdh: regression
<jjohansen> hggdh: test the previous kernel, IFF that has the same failure we can call it not a regression
<bjf> skaet: ack
<hggdh> jjohansen: running it
<skaet> thanks bjf
<hggdh> bjf: ^ 
<jjohansen> hggdh: then we can investigate why it hasn't been detected before
<bdmurray> smb: could you have a look at bug 1026251 regarding kerneloops?
<ubot2> Launchpad bug 1026251 in kerneloops "kerneloops assert failure: *** glibc detected *** /usr/sbin/kerneloops: free(): invalid next size (normal): 0x099254a0 ***" [Medium,Triaged] https://launchpad.net/bugs/1026251
<bjf> hggdh: ack
<hggdh> jjohansen, bjf: this seccomp error is present since the -17 kernel, so it is *NOT* a regression
<hggdh> jjohansen, bjf: only fails on m1.small on EC2, no record of failures on KVM or bare-metal
<jjohansen> hggdh: okay, we will have to investigate why further, but for now lets just say it isn't a regression
<bjf> infinity: ^ not a regression
<hggdh> jjohansen, bjf: I reproduced it on the -17 (taken from the official Ubuntu images on AWS); I am still looking for an earlier kernel; NOW -- the saved logs I have from the original -17 run DO NOT show this error
<infinity> bjf: shiny.
<bjf> hggdh, you have been testing oneiric i386 (non ec2) haven't you?
<hggdh> bjf: yes, as I said above, on KVM and bare-metal
<ppisati> apw: ogasawara: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759913
<ubot2> Ubuntu bug 759913 in linux "musb driver doesn't attach on omap3" [Medium,Fix released]
<hggdh> jjohansen, bjf: so it is starting to sound as something new in the test code
<hggdh> jjohansen, bjf: I found it on the original -12 test. So it was there, then vanished, then reappeared. But, again, the original -17 run does not have it, and my just-finihsed rerun of -17 shows it
<jjohansen> hggdh: okay thanks
<hggdh> I dimly remember talking with kees about it at the time
<jjohansen> hggdh: can you file a bug with the failure and boot logs etc, so we can use it to track this issue
<hggdh> jjohansen: against the QRT, right?
<ogasawara> ppisati: CONFIG_USB_SERIAL_SAFE_PADDED and CONFIG_USB_SISUSBVGA_CON are both =y only on omap4, care to investigate?
<jjohansen> hggdh: sure that works
<ogasawara> ppisati: it's set =n for all other flavors and arch's
<ogasawara> ppisati: and CONFIG_USB_USBNET
<ogasawara> ppisati: CONFIG_USB_INVENTRA_DMA=n on omap4, should it be =y?  its =y for omap3
<ogasawara> ppisati: and CONFIG_USB_MUSB_OMAP2PLUS needs investigation for omap3 and omap4
<ogasawara> ppisati: just fyi, this is what we're looking at -> http://kernel.ubuntu.com/~kernel-ppa/configs/quantal/reviews/Portland.html
<infinity> ogasawara: I can't be sure without deeper investigation, but CONFIG_USB_USBNET might be required for the hackish usb-boot "treat the device as a USB gadget" thing that some of these boards do.
<infinity> (Though, now that I think about it, I can't see why that would be)
<infinity> So maybe I'm just a victim of waking up grumpy and needing it to be beer o'clock.
<ogasawara> infinity: doing an entire day of config review is driving me to drink
<ppisati> nope
<ppisati> USBNET is dependency for SMSC95XX
<infinity> ogasawara: So, it's driving you to the status quo? ;)
<ppisati> USB_SISUSBVGA_CON is totally useless
<ppisati> it's about VGA/EGA framebuffer console
<infinity> Huh.  A USB ethernet driver including usb/usbnet.h seems like a bit of an oops to me, but there it is.
<infinity> Would take some effort to decouple it, as they use usbnet types.
<infinity> Still seems entirely wrong. :P
<ppisati> USB_SERIAL_SAFE_PADDED is the "USB Secure Encapsulated Driver - Padded", wtf?!?!
<ppisati> infinity: you can't have SMSC95XX without USBNET
<infinity> ppisati: I know, I can see that from reading the code.
<ppisati> iirc USBNET "includes" drivers/net/usb/core
<infinity> ppisati: I'm arguing that the driver is wrong, not the kernel config.
<ppisati> and all the drivers/usb/net requires it
<ppisati> so
<ppisati> infinity: you are a smart guy
<ppisati> :)
<infinity> Or, I'm not up to date on the new and terrifying ways that people have conflated "usbnet" and "USB network drivers", if you say that others do the same.
<infinity> s/network/NIC/
<infinity> Given that usbnet didn't used to have anything to do with NICs at all and was, in fact, all about networking without a NIC.
<infinity> Oh well.  Upstreams do silly things.  News at 11.
<ppisati> ogasawara: default USB_INVENTRA_DMA if USB_MUSB_OMAP2PLUS
<ppisati> ogasawara: and omap4plus_defconfig selects USB_MUSB_OMAP2PLUS
<ppisati> ogasawara: now i wonder why it's off on omap3...
<ppisati> ogasawara: wait
<herton> infinity, we talked this week here about not publishing packages to -updates/-security on late friday/weekend, jjohansen told us about lack of man power if there is any fallout on weekend (especially for security team). We agreed that publishing should not be done between 18:00UTC Fri - 21:00UTC Sun, and would like to have all archive admins to be aware of that
<infinity> herton: We tend to generally follow that rule for -updates anyway.
<infinity> herton: We've even codified it in our SRU team policy that the person on Friday duty (slangasek) doesn't do promotions, only accepts to -proposed.
<infinity> herton: Though, for kernels, I tend to do well over 90% of the AA/SRU stuff.
<apw> infinity, all we are doing is asking you not to work on a friday then :)
<herton> yes, nice, so I guess that's set for the kernel then. If anyone working on it doen't do on a Friday should be fine
<infinity> I'll try my hardest to ignore you guys on Fridays.
<infinity> The kernel we just rolled out will be an exception to that new rule. :P
<infinity> Cause it'll be friday in a few parts of the world (if not all of them) by the time we release it.
<infinity> And releasing it is the Right Thing To Do.
<infinity> (Once we get some smoketesting to endure the build didn't break in any fun ways)
<infinity> ensure, too.
<herton> yes, this last oneiric kernel is an exception, no problem on releasing tomorrow I think. I changed the bot to also not set the promote to -updates/-security tasks to confirmed through late Friday-Sunday, as we talked about it as well and decided to do it in addition
<ppisati> ogasawara: you were asking why USB_MUSB_OMAP2PLUS=y on omap3, right?
<ppisati> ogasawara: that's a dependency of USB_MUSB_HDRC and that's =y on omap3
<infinity> herton: +1 to the bot change, since I tend to not operate without its go-ahead.
<ppisati> ogasawara: IMO we can make USB_MUSB_HDRC=m on omap3 too (and that should turn USB_MUSB_OMAP2PLUS=m on omap3 too)
 * ppisati -> reboot
<jwi> ogasawara: x86_powernow_* are still not autoloadable? meh, I thought that was supposed to land in 3.5
<ogasawara> jwi: do you have a pointer to a discussion by chance?
 * ogasawara add a work item to investigate
<jwi> ogasawara: hm, 3.4 actually. fa8031aefec0cf7ea6c2387c93610d99d9659aa2 upstream
<jwi> there should be similar patches for other x86 cpu features - coretemp, microcode, crypto and stuff
<ogasawara> ppisati: USB_GPIO_VBUS one more to investigate
<ogasawara> ppisati: it's =y for omap3, =m for all other arch's and flavors
#ubuntu-kernel 2012-07-20
<ppisati> ogasawara: USB_GPIO_VBUS totally clueless, seems ok to =m
<jwi> ogasawara: hm, did you get my reply before you pinged out?
<ogasawara> jwi: yes thanks
<jwi> k
<skaet> ogasawara, bjf - backscroll is inconclusive, and there are no updates in the incident report.     What is the status with the kernel built yesterday?
<ogasawara> bjf: https://wiki.ubuntu.com/PrecisePangolin/12.04.1
<bdmurray> smb: perhaps I should upload kerneloops turning it off until we sort out the crashes?
<henrix> smb: can you take a look at my git lucid/lts-backport-oneiric and push it if OK?
<derwaffenss> Letâs put a stop to the subversive Judaics and any selfish slime allied with them.  WHITE AMERICA: Time for some serious house cleaning! http://incogman.net/
<smb> bdmurray, Err which realease was that? For Quantal I thought I had it turned it off by default
<smb> henrix, maybe
<bdmurray> smb: I turned it on when I was down there on Tuesday
<bdmurray> smb: after talking to jsalisbury
<henrix> smb: ok, if you're busy i can bug herton
<smb> henrix, I'll try to squeeze it in :)
<smb> bdmurray, Ah, missed that
<henrix> smb: ok, cool. thanks
<jsalisbury> smb, yeah, kerneloops is on for Quantal now, it will be on until just before release
<smb> bdmurray, Yeah, I was not sure it did work, but always got distracted before actually testing
<bdmurray> smb: okay, well it doesn't! ;-)
<smb> In theory it should pipe itnto apport
<bdmurray> right, there is a problem with just running the daemon though
<smb> bdmurray, Then we may turn it better off... Oh bugger... :-P
<jsalisbury> bdmurray, smb, I saw a kerneloops bug this morning, and it looks like apport had an issue: bug 1026936
<ubot2> Launchpad bug 1026936 in linux "BUG: Bad page map in process Xorg pte:5b840067 pmd:7f4cc067" [Medium,Incomplete] https://launchpad.net/bugs/1026936
<jsalisbury> message box:
<jsalisbury> This problem report is damaged and cannot be processed.
<jsalisbury> Error('Incorrect padding',)
<jsalisbury> three or four popup messages at once,
<bdmurray> smb: okay, I'll just turn it off for now
<smb> jsalisbury, Ok, so best turn it off... Hm, I wonder whether this is because I was told to drop some of the applet patches because we dont need the applet (which apparently we do do need)
<smb> bdmurray, Ok, yes. Thanks
<smb> jsalisbury, Probably you can assign the bug to me, so I will find it again when I try to
<jsalisbury> smb, ack
<bjf> utlemming: can you test the oneiric kernel that is in -proposed?
<utlemming> bjf: in progress now
<bjf> utlemming: many thanks
<ogasawara> arges: around?  we want to see that testing doc you posted
<slangasek> rtg, ogasawara: hey, question on this linux-hwe-generic thing
<slangasek> why is the backport release not in the package name?
<slangasek> we're going to have more than one of these in the precise archive over time, and they need to remain co-installable
<slangasek> (bug #1026831)
<ubot2> Launchpad bug 1026831 in debian-installer "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [Undecided,Invalid] https://launchpad.net/bugs/1026831
<ogasawara> slangasek: we intend for the hwe meta package to always point to the current point release kernel
<ogasawara> slangasek: there is an additional release specific meta package
<slangasek> that's problematic
<ogasawara> slangasek: the linux-hwe-generic will point to this
<ogasawara> slangasek: wiki.ubuntu.com/Kernel/Release/Rolling has our specific details
<slangasek> because if you're installing linux-hwe-generic, at the next point release, you get auto-switched to the next backport kernel
<slangasek> which is not supposed to happen
<ogasawara> slangasek: correct, which is what we intend
<slangasek> er, that's not what had been discussed / approved at UDS
<ogasawara> slangasek: hrm, that's not our recollection.  seems we have a disconnect.
<ogasawara> slangasek: what was your memory of the discussions, we don't auto roll forward?
<ogasawara> slangasek: how else would we roll forward for security for 5 years.  12.10 is only supported for the 18mo.
<slangasek> ogasawara: q, r, s backport kernels would be available under separate metapackage names in precise, and track the security updates for the respective releases
<slangasek> correc
<slangasek> t
<slangasek> but the point is that we were going to *only* roll forward from the q kernel to the t kernel once q itself is EOL for security
<bjf> https://wiki.ubuntu.com/Kernel/Release/Rolling
<slangasek> so that users who've installed 12.04.2 don't get a separate upstream kernel release every 6 months
<slangasek> which is what happens if you use a single name
<ogasawara> slangasek: I assumed this is practice/prototype for 14.04 when we do go for a rolling kernel policy
<utlemming> bjf, smb: tested and confirmed to work. 
<slangasek> ogasawara: that was not my understanding at all
<bjf> utlemming: can you add a comment to bug 1026730 ?
<ubot2> Launchpad bug 1026730 in linux "linux: 3.0.0-23.39 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1026730
<slangasek> this is the first time I've heard of a rolling kernel upgrade policy for 14.04
<ogasawara> slangasek: hrm, so you're view is the upgrade paths are Q->T, R->T, S->T right? and would those transitions happen when T releases or 3mo after T releases?
<slangasek> ogasawara: I don't remember if it was "when T releases" or "3 mo after"; it was discussed in the UDS session
<slangasek> but yes, that's what I was expecting to see as the upgrade path
<slangasek> which means keeping separate named metapackages for each backport channel
<ogasawara> slangasek: our reasoning for doing the rolling upgrade of Q->R->S->T was to minimize the maintenance burden
<slangasek> well
<slangasek> my understanding was that it was already agreed that the kernel team would take on that maintenance burden, as the cost of providing a suitable LTS experience :)
<slangasek> an upstream kernel upgrade every 6 months for anyone who needs any post-12.04 hardware enablement isn't very LTS-y
<ogasawara> slangasek: we're digging up our notes from UDS...
<slangasek> ok :)
<infinity> slangasek: They get "a new one every 6 months" anyway, just with an initial 18-month delay.
<infinity> slangasek: (With your proposed scheme)
<slangasek> infinity: not at all
<slangasek> infinity: they get "the one they installed", followed by "the one from the next LTS"
<infinity> slangasek: Oh, right.  Okay, fair enough.  But.  Well.  How is that better?
<slangasek> it's better because one kernel switch is better than more than one kernel switch :)
<infinity> (I'm not convinced on the "12.04.2 should ship with the backport kernel" plan, mind you, but that's unrelated)
<infinity> slangasek: It's one massive kernel switch, rather than smaller incremental ones.  Both suck, I guess.
<infinity> I do think that the whole foo-lts-backport-$release thing is madness, though.
<slangasek> in terms of administration cost, one massive kernel switch is clearly better
<slangasek> which is why the users have chosen the LTS in the first place :)
<infinity> slangasek: It might be better for upgrade scariness costs, yes.  I'd argue that the quality of support we (or anyone) can provide on a system with multiple shipping kernel versions is probably worse.
<infinity> (When you do a userspace SRU on lucid that's scary and wonky, do you test on lucid's kernel, plus all the backports?)
<infinity> And while we clearly need to be doing the backport thing to support new hardware, having several of them instead of the One True Backport Kernel does make things a bit of a nightmare.
<infinity> It does for end-users too, who find that they have 3 different kernels installed, based on when they installed their machines.
<henrix> smb: finally, pkg upload has completed!  it's on zinc
<smb> henrix, ok. looking
<infinity> slangasek: I really have no sense for what the average user finds good, sensible, or maintainable.  But I know I live in a bit of an all-or-nothing state where my ideal is "all my machines have the same kernel and never change, ever", but the next best thing is "they all upgrade together and have the same version at all times".  Having the possibility to have 3 or 4 versions in play based on when in the enablement cycle I jumped on board is awful, IM
<slangasek> infinity: well, in that case you still have the option to upgrade them all to the latest enablement kernel for consistency
<slangasek> but users shouldn't be forced to be an a 6-month kernel upgrade treadmill just because their hardware enablement missed 12.04 by 3 months
<ogasawara> slangasek: we're unable to find notes which definitively document the solution that was discussed but we clearly remember different results.  I think we're at a stand still atm.
<ogasawara> slangasek: am contemplating best way to move forward
<infinity> ogasawara: A linux-meta-lts-backport-latest that gave the rolling experience would allow users the choice between option A or B.
<infinity> ogasawara: That doesn't solve the headache that you guys have to support N kernel versions on the LTS, but if that support is effectively just backport-and-forget (has it been vaguely effortless for lucid?), then that may be a non-argument.
<apw> infinity, yeah and lts-hwe-falvour is your one there, we are going to have 'this lts backport' and the 'latest lts backport' meta packages
<apw> infinity, the argument is about which is default for a .N release
<rtg> infinity, linux-hwe-generic and linux-image-generic-lts-quantal are the 2 meta package names right now
<slangasek> ogasawara: maybe the X guys can break the tie... since the X stack and kernel need to be doing the same thing :)
<apw> slangasek, heh yeah
<ogasawara> slangasek: they definitely need to be brought into this discussion
<rtg> infinity, slangasek: this is the description of how meta packages are meant to behave based on my memory of UDS sessions (which I wrote the week after IIRC): https://wiki.ubuntu.com/Kernel/Release/Rolling
<slangasek> rtg: yes, everyone is pointing me at the wiki page; I'm saying that's not what I understood was being agreed to
<slangasek> I'm not saying you misremembered, I'm just saying that apparently not everyone in the sessions understood the same thing
<rtg> slangasek, clearly :)
<bjf> !vote!
<ubot2> Factoid 'vote!' not found
 * apw votes slangasek gets the first round in
<smb> henrix, its signed now
<henrix> smb: ack, thanks!
<infinity> apw: Was there a reason no one felt the proposed 14.04 plan wouldn't be appropriate for 12.04 too?
<infinity> apw: (If you recall)
<apw> infinity, that applied the same to the 'release' kernel as well, and i think people were scared of that
<apw> infinity, before people were used to a regular new kernel
<infinity> I can see how it's scary, but if it's scary now, it's scary in two years too.
<infinity> So, this needs to be hashed out sooner or later.
<apw> i see it as a slightly scarier combination, and 14.04 the same level of scary compared to this
<bjf> jjohansen: bug 1026853
<ubot2> Launchpad bug 1026853 in qa-regression-testing "test-kernel-security fails on seccomp on Oneiric AWS" [Undecided,New] https://launchpad.net/bugs/1026853
<jjohansen> bjf:  thanks
<jjohansen> infinity: because the 12.04 plan was announced before what is currently planned for 14.04, and maybe deals where made based on that
<arges> ogasawara, hi
<ogasawara> arges: heya, are you still on holiday?  If so, go away
<arges> ogasawara, no i'm back today! family left a day early
<ogasawara> arges: ah, I can see the doc now, thanks!
<arges> ogasawara, yup. no problem
<cking> apw, this is a fun elf article: http://timelessname.com/elfbin/
<ogasawara> rtg: https://wiki.ubuntu.com/X/Blueprints/LtsPointUpdatesForXorg
<ogasawara> rtg: look at their Questions section at the end
<infinity> cking: Haha.  Love the animated gif of jmps.
<rtg> ogasawara, hmm
<hggdh> smb: while testing the new oneiric kernel, I got a crash on m1.small: http://pastebin.ubuntu.com/1102330/
<hggdh> repeating the test did not result in a crash
<smb> hggdh, I think I saw this kind of failure somewhere before but I cannot remember exactly where. Does repeating the test involve starting another instance? (which I assume)
<smb> It would be good if there are complete dmesgs of fail or not fail (in order to see which xen version this was)
<jjohansen> yeah
<infinity> Could be hypervisor versions, or even underlying hardware.  Not all instances are created equal. :/
<jjohansen> smb, hggdh can't you just reboot the instance, instead of starting a new one so we are guaranteed the same Xen/machine
<smb> jjohansen, with manual attempts certainly. Though I would think from jenkins its probably always starting a fresh one
<smb> With all the "repeatability" 
<hggdh> smb, jjohansen
<hggdh> ; the instance was rebootged
<smb> Unfortunately ec2 is a bit "surprising" there
<hggdh> this is being run manually
 * jjohansen wasn't sure if this was from a jenkins or manual test
 * smb neither
<hggdh> jjohansen: I will rerun on the previous kernel
<hggdh> and this may explain the failure I got yesterday runniong the -17
<hggdh> jjohansen, smb just ran seccomp on -22, no errors
<hggdh> I am starting to think I am getting different xen versions
<smb> hggdh, As did I (get no errors) when running it yesterday. That one was something 3.4.3-kaos...
<jjohansen> hggdh: likely, what we need to do is multiple runs, and get the full boot log
<hggdh> the failing one (on -23.39 is [    0.000000] Xen version: 3.0.3-rc5-8.1.14.e
<hggdh> the one with no failure (on -22) is [    0.000000] Xen version: 3.4.3-2.6.18 (preserve-AD)
<hggdh> smb: isn't the 3.03 the one we had an issue some time ago?
<hggdh> how many bloody different versions does AWS run?
<bjf> hggdh: are you ready to sign off on the "incident" bug so we can get this oneiric kernel into -proposed? 
<smb> hggdh, Usually the older the more issues. There was one, and it might have been this one that had issues with installing java on 32bit t1.micro
<ogasawara> ppisati: can you add DRM_OMAP to your investigation list
<smb> hggdh, bjf Certainly this is not any regression (that much we already were ready to agree yesterday)
<smb> jjohansen, Note that the crash there is another path of setting cr4 (remember osxsave)?
<hggdh> I just ran another one under [    0.000000] Xen version: 3.4.3-2.6.18 (preserve-AD)
<jjohansen> smb: no, not at all /me sticks fingers in ears and shouts I'm not listening, I'm not listening
<smb> hggdh, aaaaand?
<hggdh> hum. Let me repeat, the instance seems to have vanished :-(
<jjohansen> sigh /me really dislikes dealing with all Xen version on ec2
<smb> hggdh, That does not exactly sound like a repeat
<hggdh> dammit. I have the feeling it was a 3.0.3-whatever, under -17. I will restart
<hggdh> smb: no, it does not. I never had an instance simply vanish in thin air
<hggdh> found it, it was just lurking. It is indeed a 3.0.3-rc5-8.1.14.f, on -17
<smb> hggdh, I have the same gp fault on another 3.0.3 I started and I certainly had no problems yesterday which ran on 3.4.3
<hggdh> smb: the other 3.0.3 above also died on an OOPS
<hggdh> smb: I agree this sounds like a bad Xen on AWS
<hggdh> apart from that, no errors on KVM, and bare-metal (except that all jobs on two specific machines failed, but this is due to a problem with the CDU
<hggdh> oh, perfect, now I have a thunderstorm over me
<hggdh> smb, jjohansen: do you agree this is most probably related to the 3.0.3-crappy Xen on AWS?
<jjohansen> hggdh: that does seem to be a possibility, but I a haven't seen enough data to be comfortable claiming such.  Basically I have seen one instance that we can definitively make the correlation.  I would like a lot more data than that
<smb> hggdh, Having seen it pass depending on host Xen version or not and even fail on older releases when not, this really does not sound like any regression
<bjf> this is *not* a regression. a bug has been filed, we need to add data to that but do we wan't to hold up on the release of this kernel?
<bjf> hggdh, jjohansen ^ ?
<hggdh> bjf: jjohansen is correct -- it seems not a regression, but I would like to try another one
 * hggdh is almost convinced
<jjohansen> hggdh, bjf: I am convinced it is not a regression we have sufficient data to show it happening on older releases.  The only thing I am unsure of is the correlation of all the failures to Xen version 3.0.3-crappy
<jjohansen> bjf: what is the bug number again
<bjf> jjohansen: bug 1026730
<ubot2> Launchpad bug 1026730 in linux "linux: 3.0.0-23.39 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1026730
<hggdh> jjohansen: running on 3.4.3-kaos-whatever
<smb> jjohansen, I agree that pinning badness to one exact version we will need to repeat the tests more often. There might be versions in between showing the same or different problems (or none)
<hggdh> so far we have at least 3 different versions involved... who knows how many are there?
<smb> $DEITY knows...
<smb> Still this should not let us delay getting rid of the other mess
<hggdh> OK. ran on 3.4.3-kaos_droplet (preserve-AD), -17 kernel, no issues
<hggdh> I vote to approve
<smb> +1
<jjohansen> +1
<hggdh> jjohansen: ?
<hggdh> heh
<bjf> hggdh: you can cast your vote by changing the task :-)
 * hggdh goes updating the task
<hggdh> jjohansen: there is a confirmed task there for you also
 * hggdh goes terminating all m1.small instances
<jjohansen> hggdh: yeah, its going to take a few minutes, I am running the scripts now
<bjf> jjohansen: i believe the bug is waiting on "security signoff'
<jjohansen> bjf: yes, I am working on it
<bjf> jjohansen: :-) thanks
<infinity> Oh, hah, I just mentioned that in another channel.
<infinity> La la la.
<infinity> I'd question why Amazon is using xen3 at all instead of xen4, but whatever. :/
<hggdh> not only xen3, but a really old on at that
<hggdh> s/ on/&e/
<jjohansen> hggdh, bjf, infinity: released
 * hggdh goes to cross all fingers and toes, just in case
<bjf> jjohansen: ack
<bjf> infiniti, it is in your hands
<bjf> infinity, the bot is not going to set the release tasks due to it being friday :-)
<henrix> bjf: and will it set the 'promote-to-proposed' task on the lts kernel tracking bug?
<hggdh> bjf: BTW, have you seen https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/ ? We are now listing the kernel version there; I think it is good enough, care to comment?
<bjf> hggdh: yes, that is very nice in the description. are these in the "dashboard" yet?
<herton> henrix, yes, nothing was changed related to the promote-to-proposed task
<henrix> herton: ack, thanks
<infinity> bjf: Haha, right.  On it.
<hggdh> bjf: I think so (based on gema's EOD in G+)
<infinity> bjf: Was the promote-to-security task a mistake there?  The previous -23.38 was only in -updates.
<infinity> bjf: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1020623 <-- No security task.
<ubot2> Ubuntu bug 1020623 in linux "linux: 3.0.0-23.38 -proposed tracker" [Undecided,Fix released]
<infinity> bjf: Doesn't seem to make sense for 23.39 to have one.
<henrix> infinity: there is a security task there as well, which was marked as invalid i believe.
<henrix> infinity: see comment #4
<herton> yes, the bot would set it to invalid, but as it doesn't run today the task stays as new
<infinity> henrix: I meant "there wasn't a valid one". :P
<infinity> herton: The bot really should be marking security (and signoff) tasks invalid long before it comes up.  Could have saved jjohansen some time too.
<infinity> (Though I'm not sure how the bot even knows, I would have thought it was a human task)
<herton> infinity, no, the bot doesn't go as far as that, I thought you meant about the task as being in new state
<bjf> infinity, jjohansen set the task
<infinity> herton: No, no.  I meant it should be invalid.
<jjohansen> infinity: we have scripts etc, to help determine if its invalid, but in the end it currently a human call
<herton> infinity, the bot sets it to invalid if jjohansen sets the security-signoff to invalid. But it sets this along with the promote-to-updates step
<jjohansen> infinity: so I ran my check, it reports it needs to be looked at, and another script reports it doesn't believe there are any CVEs, but I need to do the check and make the final call
<infinity> herton: Ahh, kay.  So, jjohansen also didn't set signoff to invalid, so I'll blame him. :)
<infinity> Oh, wait.  He did.  I'm blind.
<infinity> IGNORE ME.
<jjohansen> herton: I did set the security sign-off to invalid
 * infinity plays bot, and releases.
<jjohansen> herton: oh ignore I read that wrong
<henrix> infinity: since you're around... would you care to take a look at oneiric lts kernel? :)
<infinity> henrix: Needs a PPA copy?
<bjf> infinity: it just went into the upload queue
<henrix> infinity: yep. i know its friday, but its the same issue so... i guess we're having an exception here as well
<infinity> bjf: Alright.  Will accept and fix the override on the one binary if it breaks the same way.
<henrix> thanks
<infinity> jjohansen: If you want to pre-emtively security-invalidate https://bugs.launchpad.net/kernel-sru-workflow/promote-to-proposed/+bug/1026884 now, so we don't have to worry about it later? :)
<ubot2> Ubuntu bug 1026884 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-23.39~lucid1 -proposed tracker" [Medium,In progress]
<rtg> http://bytesmedia.co.uk/2012/07/17/richard-stallman-uefi/
<infinity> rtg: That's a terrifying combination of nouns.
<rtg> infinity, as you might have guess, he's not all that positive about UEFI
<infinity> rtg: s/UEFI/SecureBoot/
<infinity> rtg: And even then, probably only vendor restrictions on SB, I'd bet.
<rtg> infinity, right
 * infinity wishes people would stop conflating (u)efi and SB.
<rtg> I've conflated UEFI with SB 'cause its all I've thought about lately
<infinity> We have a "supporting UEFI" session at DebConf that was entirely dominated by SB prattle, which was useless.
<infinity> s/have/had/
<jjohansen> infinity: unfortunately microsoft is forcing the the conflation of UEFI SB and RB
<infinity> jjohansen: To be fair, I think it's mostly the free software world that's doing that, especially the people who don't seem to be aware that there have been EFI machines for years that they supported poorly (or failed to support entirely).
<infinity> jjohansen: So, now that the world is moving to UEFI wholesale, and it happens to coincide with the Win8 SB cutover, people are acting as though "supporting EFI" and "supporting SB" are the same task, when they're two very different beasts.
<infinity> (And those of us who supported EFI for years know this)
<jjohansen> infinity: previous efi did not conform to the SB specification and microsoft wasn't forcing its use for RB nor was it the root key authority
<infinity> jjohansen: Yes.  But that doesn't make A equal to B.
 * infinity shrugs.
<infinity> It's a pet peeve.
<jjohansen> infinity: agreed that EFI and SB are different but its because microsoft is forcing SB/RB that its a problem
<infinity> Not made better by, like I said, a one hour session of people talking about secureboot, as if that mattered when Debian doesn't even support EFI properly.
<infinity> jjohansen: SB/RB goes from annoying to downright hostile, but even without it, modern OSes need to support EFI, and most don't actually do it right.
<jjohansen> infinity: true, though /me can wish that EFI was never even conceived
<infinity> I do rather wish that Intel/HP had gone with OpenFirmware back when they decided to flirt with PC BIOS alternatives.
<infinity> The reinvention of the wheel was irksome.
<infinity> From a "firmware addon" developer POV, EFI is much more pleasant, though.  Maybe that was part of the motivation.
<jjohansen> infinity: heh if firmware addons are what you want what of coreboot
<infinity> jjohansen: coreboot is politically distasteful to a lot of people, I suspect.
<jjohansen> infinity: well yes :)
<jjohansen> infinity: but so is SB
<infinity> OF would have been a reasonably neutral choice, I thought.
<infinity> IBM, Sun, Apple, and many others had invested in it.
<jjohansen> it was the logical choice at the time
<infinity> But, too late now.
<jjohansen> yep
<ogasawara> ppisati: CONFIG_NLS_ISO8859_1 does this need to be =y on omap4 or can we flip it to =m
<ogasawara> ppisati: CONFIG__OMAP_IOVMM=n, should that be =m?
<ppisati> ogasawara: OMAP_IOVMM should be deprecated in modern kernels, is it =y or =m anywhere?
<ogasawara> ppisati: it's set =m on omap3
<ogasawara> ppisati: so we should turn it off yes?
#ubuntu-kernel 2013-07-15
<hashken> Hi, I am planning to create a custom Amazon image from Ubuntu Minimal CD.
<hashken> After going through a few forums, I am under the impression that the kernel needs to have certain modules compiled, so that it runs in Amzon EC2.
<hashken> Is the kernel in the Ubuntu Minimal CD, capable of runningin an Amazon EC2 instance?
<hashken> Is the regular Ubuntu kernel capable of running in an Amazon EC2 instance?
<smb> hashken, It varies depending on release. But in general all of them should. The only thing to check is whether xen-blkfront is built in or that the module is requested to be in the initrd.
<smb> hashken, If you pull in the linux-virtual meta-package that gives you the same kernel as in the cloud-images.
<hashken> thanks smb
 * apw yawns ...
<apw> it is very hot here
<RAOF> apw: How are the bees finding it?
<smb> They probably have been replaced by real-fire flies
<apw> if they have any sense they are in the cup, hiding from the sun
<apw> smb, turned into by the sun more like
<smb> apw, You should get rid of that sun thing completely.
<RAOF> The Daystar?
<smb> Just place a huge solar panel over the UK... above cloud level so they can enjoy their rain still
<apw> smb, good plan
 * apw hs being promised some rain over the next two days, thats something
<brendand> is this verification testing week for the -proposed kernels?
<smb> "14-Jul - 20-Jul   Bug verification." (from the email everyone gets)
<Guest46086> Can we get https://wiki.ubuntu.com/Kernel/LTSEnablementStack linked from https://wiki.ubuntu.com/Kernel/FAQ somewhere?
<rtg> I've rebased saucy against v3.10.1 and ready to push. are you still looking at those arm dtb patches ?
<rtg> apw, ^^
<apw> rtg, i have them applied here indeed, but push away and i'll sort it out
<rtg> are you gonna worry about 3.10 ? or just do it for 3.11 ?
<apw> i was assuming i'd apply them to both once i had build tested them on both
<apw> they seem sane if my chat with infinity is anytyhing to go by
<rtg> ok
<infinity> Oh dear.  I shouldn't be the yard stick for sanity.
<rtg> apw, saucy pushed. still testing armhf build, but I expect it to be OK
<apw> infinity, hey i am comparing to me
<apw> rtg, don't we have a per kernel directory already
<rtg> apw, for firmware in the kernel package
<apw> for firmware, could we perhaps drop the linux-firmware-lts contents into those as if they were part of the kernel
<rtg> but each one is ABI specific
<apw> bah
<rtg> apw, sounds like a sprint topic
<apw> yeah shove it in, a plan indeed
<apw> as we'll have infinity to poke too
<rtg> apw, lemme know when you've pushed those arm patches. everything else is ready to go.
<apw> rtg ack, just checking the udebs builds
<rtg> apw, pushed saucy unstable rebase onto v3.11-rc1
<apw> rtg, ack
<apw> not far behind, just rebased and doing final checks
<apw> missing some ?'s which i've added and fingers crossed
<jibel> ogasawara, apw, there is a first iteration of dkms testing ready for review http://10.98.0.1:8080/view/DKMS/view/All/
<jibel> It covers precise, precise+hwe kernels, saucy+proposed, saucy+prerelease ppa
<jibel> This a build/install test but I disabled modprobing for the moment.
<jibel> ogasawara, Could your team review the results, then we can schedule a call ?
<ogasawara> jibel: awesome, thanks!  yes, we'll review. lets go ahead and schedule a call on the calendar for later this week?
<jibel> ogasawara, this week is fine, I'll let you schedule it, your time will be mine.
<ogasawara> jibel: ack
<apw> rtg, ok i also need to fix linux-signed before you do your do on this one
<rtg> apw, no problem, am pursuing an __udivdi3 issue on unstable i386
<apw> rtg, ok saucy master-next is pushed, off to un-f*ck -signed
<rtg> apw, ack
<apw> rtg, ok i have pushed signed, but once you have linux in the pipe for upload i would like to do the update to ensure the update-versions is going to handle this situation, we have never had to test this before
<apw> (do the update for linux-signed)
<rtg> apw, If you want, then go ahead and package saucy master-next. I'm still messing with unstable.
<rtg> (and upload)
<apw> rtg ok will do
<apw> rtg, you did a rebase on this right ?
<rtg> yeah, to v3.10.1
<apw> i don't see it in the changelog
<rtg> apw, oh shit, forgot
<apw> did you miss it (then i can add it) or do i have the wrong brnach
<apw> if you missed it i can retrofit for you
<rtg> apw, yeah, go ahead and run insert-mainline-changes
<apw> will do
 * _bjf -> dr. appt.
<brendand> bjf - i noticed a couple of the kernels went to confirmed today, that doesn't imply a change in schedule does it?
<brendand> bjf, the raring and quantal backports kernels were the ones
<apw> brendand, those normally lag don't they, as in wait on their parent branches to build before being done (but i'll let bjf say for sure)
<brendand> apw, i would have expected then for the raring and quantal proposed kernels to be confirmed prior then, rather than the other way around
<psivaa> sbeattie: We are seeing https://jenkins.qa.ubuntu.com/view/All/job/sru_kernel-quantal_lts_hwe-generic_i386-intel_64-mga_g200ew/39/testReport/junit/autotest/ubuntu_qrt_apparmor/test_apparmor_py/ in regression testing.  
<psivaa> sbeattie: guess you are the one to talk to?
<apw> psivaa, if it is apparmor i expect jjohansen will be interested as well
<psivaa> apw: ack, thanks :)
<jjohansen> psivaa: thanks, this regression is known about and temporary
<jjohansen> psivaa: its due to work item scheduling
<apw> jjohansen, so we'll get some more bits in the mail :)
<jjohansen> apw: oh yes, there will be at least two more syncs
<apw> jjohansen, thanks
 * bjf -> back
<bjf> brendand, would be nice if you'd have stuck around :-(
<psivaa> jjohansen: ack, not sure what i should do with the workflow task, (fix-release with qa-testing-passed ?) 
<jjohansen> psivaa: err just a sec, this is the quantal backport?
<psivaa> jjohansen: yes
<jjohansen> psivaa: on i386?
<psivaa> jjohansen: yes, on amd64 hardware i think
<jjohansen> psivaa: sorry ignore what I said before, this just looks like a known bug. It is not. The quantal backport should be good here
<jjohansen> psivaa: okay, we will poke at it
<psivaa> jjohansen: ack, ill report a bug then
<jjohansen> sbeattie: we have a regression on the quantal backport to investigate
<sbeattie> jjohansen: looking at that output, it seems to be the tcp tests that failed?
<jjohansen> sbeattie: yep
<psivaa> jjohansen: sbeattie: reported bug #1201530 for the above failure. 
<ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,New] https://launchpad.net/bugs/1201530
<jjohansen> psivaa: okay, thanks
 * sbeattie is trying to reproduce the issue
<rtg> apw,  pushed Ubuntu-3.10.0-3.12 on to saucy master
<apw> rtg, how is it i keep forgetting to do that, spack
<rtg> apw, I didn't notice until I went to do the LTS version
 * rtg -> EOD
#ubuntu-kernel 2013-07-16
 * smb thinks ppisati just fell from his chair... or mumble died on some end
<apw> which is more reliable mumble or the chair
<apw> i suspect the chair by some margin
<apw> smb, moin
<smb> apw, Possibly. Though he did not react on the irc nudging either...
<smb> apw, moin. Man did we all fall out of bed this morning?
<RAOF> apw: How are the firebees today?
<apw> RAOF, they are going to be toasty again for sure
<psivaa> bjf: jjohansen: I'm planning to release the regression testing task for bug #1199285 based on your feedback to the bug #1201530 as to whether it's a real regression, if that's OK
<ubot2`> Launchpad bug 1199285 in Kernel SRU Workflow security-signoff "linux-lts-quantal: 3.5.0-37.58~precise1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1199285
<ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,New] https://launchpad.net/bugs/1201530
<jjohansen> psivaa: can you rerun the regression tests and see if it shows up in the QA env, we have had bugs in the past where they would only surface in a given env because of how the env is set up (eg. QA env setting the dump location)
<psivaa> jjohansen: not sure if i understand correctly, but this was run in QA env. Do you want me to see if it's occurring again?
<jjohansen> psivaa: yes please
<jjohansen> I am trying to determine whether its a repeatable failure in the QA env
<psivaa> jjohansen: ack, will do in a bit, i have started to run something else in that machine
<ppisati> brb
 * ppisati -> out for lunch
<arges> is there a meta-package for linux-source for linux-image-lts-quantal / raring? linux-source just installs the 3.2 kernel on my 12.04.2 install
<rtg> arges, I don't think there _is_ a linux-source package for the LTS kernels, is there ?
<psivaa> jjohansen: so, I could not see the failure when re-running the apparmor tests a few times. 
<Sarvatt> not seeing one in the lts-quantal packaging at least
<psivaa> i.e. could not reproduce bug 1201530
<ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,Incomplete] https://launchpad.net/bugs/1201530
<arges> rtg: well what i'm looking for is... i did a fresh 12.04.2 install.I want to have the 3.5 sources installed, which package do I need
<arges> instead of apt-get source linux-image-`uname -r`
<rtg> arges, I'm not sure you can.
<arges> is there a way to make a linux-sources-lts-quantal package to pull that in perhaps?
<rtg> arges, not without extending the LTS packaging to actually produce a linux-sources binary package.
<arges> ok. thanks
<psivaa> sbeattie: jjohansen: I am able to reproduce a security test failure issue though, bug #1201781 when testing linux-ti-omap4: 3.2.0-1435.46
<ubot2`> Launchpad bug 1201781 in ubuntu-kernel-tests "test_010_proc_maps fails on panda-es with 3.2.0-1435-omap4 #46" [Undecided,New] https://launchpad.net/bugs/1201781
<bjf> psivaa, i'm ok with you adding a note saying that you were not able to reproduce the failure and release the kernel from testing
<apw> psivaa, ok that signage issue should be gone in any new images made after 'now'
<bjf> brendand, per your question from yesterday, there has been no change in the schedule. When kernels are available for testing (marked as such via the tracking bug) is not based on the schedule but on when the associated bugs have been verified
<bjf> brendand, the point of the kernel-sru-announce mailing list is to send out notifications if / when there are changes to the schedule
<psivaa> bjf: ack
<psivaa> apw: ack, ill release the qa testing task  for the precise omap4 kernel as well
<brendand> bjf, should the backport kernels be considered verified before their parent kernels have been though? that's what was confusing
<psivaa> apw, ohh i assume you did not talk about bug #1201781?
<ubot2`> Launchpad bug 1201781 in ubuntu-kernel-tests "test_010_proc_maps fails on panda-es with 3.2.0-1435-omap4 #46" [Undecided,New] https://launchpad.net/bugs/1201781
<apw> brendand, they can be verified if all their branch specific bugs are complete, though they are subject to the parent branch passing as well
<bjf> brendand, it wasn't what i was expecting and in the future that's less likely to happen
<apw> psivaa, i am referring to bug #1201444
<ubot2`> Launchpad bug 1201444 in linux-signed (Ubuntu Raring) "linux and linux-signed may becomes skewed due to loose dependancy (was Secure boot signature verification of linux kernel is failing with today's images)" [Medium,Fix committed] https://launchpad.net/bugs/1201444
<psivaa> apw: ack, just realised it, thanks :)
<psivaa> bjf: Would like to know how to proceed with the precise omap4 kernel because the security test failure ^(1201781) is reproducible
<bjf> psivaa, looking
<bjf> psivaa, i don't see any comments from any of the security dudes. have you pointed them at it?
<psivaa> bjf: i did jjohansen and sbeattie , not sure if they are the only ones to point at :)
<bjf> psivaa, that's good enough. did they have anything to say about it?
<psivaa> bjf: not yet, waiting though. 
<psivaa> bjf: ok i must have rushed a bit, i'll wait 
<bjf> psivaa, ack. nothing i can really add then. i depend on them to let me know if it's the kernel or an issue with the test.
<psivaa> bjf: ack
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg> apw, any prgress on overlayfs ? I see that file_operations.readdir has morphed into file_operations.iterate with more complex semantics.
<ppisati> brb
<apw> rtg, i was just about to start looking at those, i had just pulled up my aufs tree to see if that was available
<rtg> apw, aufs changed his repository location, didn't he ?
<apw> yeah
<rtg> where to ?
<apw> rtg, working on that, cause i followed his last move, and now i don't have the latest still so something is amiss, give me a sec
<apw> rtg, seems he since has had sf.net shit itself on his repos and lose them, oh the joy
<rtg> apw, that doesn't say much for SF disk management
<apw> rtg in theory git://git.code.sf.net/p/aufs/aufs3-standalone is his latest ...
<apw> rtg, i suspect it was finger trouble as much as anything
<apw> rtg i will look at updating it and see
<rtg> apw, looks like he has a July 15 update
<apw> yeah i'll give it a tug and see
<apw> rtg, well it 
<apw> rtg, well it builds at least (aufs) standalone, so will see if it links to the kernel and test it
<apw> rtg, have you booted unstable at all ?
<bjf> that doesn't sound like a good question
<apw> heh, not looking good on one of my boxes for sure, on either of the ones i normally test
<apw> rtg, i am seeing hard hangs during boot on amd64 and panics with splash on i386
<rtg> apw, thats before aufs is in use ?
<apw> well before indeed, during early boot in both cases
<apw> for i386 i am seeing oopses in addrconf_notify out of what looks like a network address update
<apw> rtg, does it boot ok for you, i wonder if this is ipv6 related as they are temporary addresses it is changing
<apw> oh i feel a nice cider coming on
<rtg> apw, I haven't actually tried it since -rc1
<apw> rtg, so it could be bust anyhow ... ok
<rtg> apw, I'm working on booting the daily on a tunnel mountain UEFI system
<apw> heh what could possibly go wrong
<rtg> apw, well, it could completely wreck that system, for starters
<apw> rtg, there is only ext4 changes in linus' tree isnce -rc1
<rtg> apw, have you tried mainline -rc1 ?
<apw> </sarcasm>
<apw> rtg nope, will do so now
<jjohansen> psivaa: okay, thanks we may need to access a QA machine to narrow down why its failing. I will try again here first though
<jjohansen> psivaa: as for 1201781 that sounds like a race
<jjohansen> in the test
<psivaa> jjohansen: ack, i ran the test locally on a pandaboard though
<jjohansen> psivaa: for bug 1201530?
<ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,Incomplete] https://launchpad.net/bugs/1201530
<psivaa> jjohansen: no, that was run on a machine in the lab, sorry. it's the other 1201781 that i ran locally
<jjohansen> psivaa: okay, thanks
<psivaa> jjohansen: so if the race is in the test, what's the next step? 
<jjohansen> psivaa: as bjf said for 1201530 add a note that you where unable to reproduce the failure and release the kernel from testing
<jjohansen> for 1201781 if its the test, you add a note that the test has been confirmed to have a race and release the kernel from testing
<psivaa> jjohansen: i have released the testing task that was held up by bug  1201530
<ubot2`> Launchpad bug 1201530 in ubuntu-kernel-tests "Failure in apparmor tests with quantal lts-hwe 3.5.0-37.58~precise1-generic 3.5.7.16" [Undecided,Incomplete] https://launchpad.net/bugs/1201530
<jjohansen> psivaa: I am assuming 1201781 is a race but haven't looked into it yet
<jjohansen> psivaa: ack
<psivaa> jjohansen: ok, i'll wait for your verdict then?
<psivaa> re 1201781
<apw> rtg, ok i've arbitrarily pushed the aufs update to unstable, give it builds and unstable is a heap anyhow
<apw> i'll look at overlayfs in the morning
<rtg> apw, ack.
<rtg> apw, I'll work on figuring out the boot problem
<apw> sounds good to me, i fancy a beer in the garden
<rtg> apw, hmm, you said cider before, so which is it ?
<apw> beer can mean either in the context of a garden :)
 * smb is getting thirsty
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<apw> smb, it is night time where you are, you might not get one before closing
<smb> apw, My fridge is open 24/7
<smb> Well not literally
 * ppisati -> gym
 * rtg -> lunch
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 23rd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<infinity> zequence: You need to update your configs.
<infinity> apw: There's a magic thing for that, right?  updateconfigs or something?
<bjf> infinity, yes, fdr updateconfigs
<infinity> zequence: ^
<zequence> infinity: oh, something has changed?
<zequence> Where is updateconfigs and which configs does it update?
<zequence> Sorry to be so late with uploading the kernels, btw
 * apw isn't sure i'd expect you to need to updateconfigs on lowlatency cause it has only overlays
<apw> infinity, where is the failure
<rtg> apw, it looks like a sysctl is being written when 3.11-rc1 burns in. Is that what you saw ?
<infinity> apw: https://launchpad.net/~ubuntustudio-kernel/+archive/linux-lowlatency-sru/+build/4799579
<apw> rtg it was a config variable, being changed via procfs i think
<apw> rtg but very similar
<infinity> zequence: "debian/rules updateconfigs" is what bjf implied.
<rtg> apw,  right, I meant procfs
<apw> rtg, tmpaddr somethign in the stack
<apw> zequence, i don't expect updateconfigs to work on lowlatecy
<zequence> apw: ok
<apw> because of the way it works
<apw> zequence, i assume yours is pushed to the normal place
<zequence> apw: I've changed the repo now..
<apw> zequence, so i can test against it and tell you how to fix it yourself next time
<apw> and this is all quantal yes 
<zequence> quantal only so far
<zequence> https://github.com/ubuntustudio-kernel/ubuntu-quantal-lowlatency.git
<zequence> apw: ^
<apw> zequence, thanks, i'll sort out why this is happeneing and get you the info shotrly
<rtg> apw, addrconf_notify
<zequence> apw: Greatly appreciated
<apw> rtg, the self same one then
<apw> tmaddr is one up i think from teh eip there
<apw> anyhow, the same signature for sure
<rtg> apw, this is likely our fault: 'UBUNTU: SAUCE: (no-up) ipv6: make the net.ipv6.conf.all.use_tempaddr sysctl propagate to interface settings'
<apw> rtg, ooops
<rtg> addrconf_use_tempaddr() calls dev_tempaddr_change((struct inet6_dev *)table->extra1), but table->extra1 is NULL I think
<rtg> lemme have a look at 3.10
<apw> rtg, rip it out i say and if that fixes it send it back to the submitter
<rtg> apw, I'll rip it out to make certain that is indeed what is causing the crash.
<rtg> I think xnox write it
<nessita> hello! is this the proper channel to ask about what it looks a kernel bug in raring?
<nessita> bug is LP: #1201528
<ubot2`> Launchpad bug 1201528 in alsa-driver (Ubuntu) "[Realtek ALC889] - Audio Playback Unavailable" [Undecided,New] https://launchpad.net/bugs/1201528
<bjf> nessita, right channel. our sound expert is in the EU. he will probably see your bug tomorrow
<nessita> bjf, great, shall I do anything else about this?
<bjf> nessita, not at the moment. see if diwic takes a look at your bug. he's quite responsive.
<nessita> bjf, ack, will do, thanks
<rtg> apw, that appears to have been the problem.
<apw> rtg, ok good
<rtg> apw, I think I found the fix. am testing now
<rtg> building, rather. will test soon thereafter
<rtg> they were playing some games with void *, so the compiler could not detect the change.
<rtg> apw, fix made and pushed
<apw> rtg great
<xnox> rtg: me?! i am not the usual suspect for ubuntu:sauce: kernel patches.....
<xnox> =)
<rtg> xnox, wrong nick, sorry
<rtg> I was thinking of Mathieu Trudel-Lapierre
<apw> zequence, infinity, ok what is wrong here is that the tree wasn't clean enough; if you git clean -x -f d; fdr clean; fdr prepare-lowlatency; then you avoid the issue
<rtg> cyphermox is whom I should have mentioned.
<cyphermox_> yes?
<rtg> cyphermox_, just pushed a patch to saucy unstable to fix a SAUCE patch that you wrote.
<rtg> UBUNTU: SAUCE: (no-up) ipv6: make the net.ipv6.conf.all.use_tempaddr sysctl propagate to interface settings
<rtg> cyphermox_, no action required on your part
<cyphermox_> ok
<zequence> apw: I did the update from clean trees, so I don't think that was the issue, unless I screwed something up
<zequence> Ah, or did I really miss a step there - sorry if that is the case
<zequence> No, it was clean before I started
 * rtg -> EOD
<zequence> Can't be another faulty RAM issue?
<zequence> I'm building again to see
<zequence> infinity: new upload, so perhaps this one will work
<infinity> zequence: Definitely wasn't a faulty RAM issue, no, it was clearly fallout from the config change in master.
<apw> zequence, infinity, ok what is wrong here is that the tree wasn't clean enough; if you git clean -x -f d; fdr clean; fdr prepare-lowlatency; then you avoid the issue
<infinity> zequence: If that upload really was "no change", it'll fail all the same.
<zequence> apw: infinity: I'm definately sure that the tree was clean this time, but it should have been last time too, since I hadn't done any work previously. 
<infinity> zequence: Did you debdiff your old and new uploads before uploading to see if anything had changed?
<zequence> nope, let me do that
<infinity> And if it did, indeed, change, a changelog better than "no change" would have been nice. :P
<infinity> https://launchpadlibrarian.net/145114059/linux-lowlatency_3.5.0-37.38_3.5.0-37.39.diff.gz
<infinity> Definitely not "no change".
<apw> yeah i have fallen for this one before, it being prepared for another release even can trigger issues
<zequence> ah, maybe that is it
<zequence> it's the wrong version
<apw> infinity, you should find and fdr clean; fdr updateconfigs will just run if it is right
<infinity> You people and your "fdr"...
<infinity> I do sincerely hope that updateconfigs doesn't actually need (fake)root. :)
<hrw> hi
<hrw> does someone know why 3.10.2/saucy does not bring up cpu1-7 on my i7?
<zequence> apw: infinity: sorry, now I see it. I did miss to clean, so the debdiff showed the result of that then?
<hrw> I got something broken with grub so boot drops me to grub console. Loading kernel with "linux /boot/vmlinux-3.10.2" + "initrd /boot/initrd-3.10.1" + "boot" == only cpu0 booted and machine reboots few seconds later
<hrw> any ideas?
 * zequence really needs to script the maintenance procedure to avoid this kind of stuff
<infinity> zequence: If you want to knock that last revision out of git to remove the silly changelog entry and give me a clean 37.38, I can push it directly to the kernel PPA and bypass yours.
<infinity> zequence: (That is, the current state of the package looks good, you can just remove that changelog entry and move your tags)
<zequence> infinity: Sure. give me moment
<zequence> infinity: Ah, right. But you can just take the tag that was for the first build, no? And I just delete the last commit (and tag 37.39)
<infinity> Deleting commits doesn't work so well in git, does it?
<infinity> But you can revert it, sure.
<hrw> shit.
<infinity> Well, moving tags doesn't work so well either, but meh. :)
<hrw> looks like I have to dig in recycle bin to find ubuntu livecd and hope it will boot
<infinity> zequence: Where's the git for lowlatency?  I'll clone this and roll my own while you sort out what you want to do to it. :)
<zequence> infinity: https://github.com/ubuntustudio-kernel/ubuntu-quantal-lowlatency.git
<zequence> infinity: Why not just keep the commit as it is? It's just a line in the changelog after all
<zequence> or a few, I mean
<infinity> Because I'm anal about unprofessional looking changelogs.  But your call.
<infinity> If it were in main, I'd probably reject it outright, as the changelog is both uninformative and a lie. :)
<zequence> infinity: Should it have been: UBUNTU: Lowlatency-3.5.0-37.39?
<infinity> No, it should have not said "no change", when clearly there was a change, or the upload would have been unnecessary. :)
<infinity> But, the point of testing in PPAs is that we can undo these things, not keep piling on top, so meh.  Let's just undo it.
<infinity> (And learn a valuable lesson about local testbuilds before uploading)
<zequence> infinity: ok, sorry for the trouble. lesson learned
 * zequence is getting some more cores for his server next week so he doesn't need to do this stuff on his client machine
<infinity> zequence: Bah, I do it on my laptop. :)
<infinity> And I do linux-ppc on an 8-year-old machine...
<infinity> (Probably not a fair comparison, given how fast that machine was 8 years ago, but it's finally feeling it's age)
 * hrw starts to hate ubuntu^W kernel
<infinity> Oh god, cloning a kernel tree over hotel wireless is like shaving your junk with a cheese grater.
<infinity> hrw: Would you like me to mail you a livecd? :P
<hrw> infinity: 12.10 livecd just went to trashcan for not booting
<infinity> hrw: I'm not entirely sure how you expect a mismatched kernel and initrd to like each other.  Though, I'm not sure that's the root of whatever problem you're having either.
<hrw> infinity: that line was typo - I have kernel+initrd matching
<infinity> And I assume by "3.10.2", you mean "3.10.0-2"?
<hrw> infinity: ~latest saucy one
<infinity> Well, there's a -3 now, it might love you more.
<infinity> If you can boot...
<infinity> Surely, you still have the previous kernel?
<hrw> -3 was in proposed last time I saw
<hrw> infinity: no, I remove old kernels
<hrw> infinity: and 3.10.0-2 was running perfectly fine
<infinity> Tsk, tsk.
<infinity> Our autoremoval magic intentionally keeps at least one more around for this sort of thing.
<hrw> then oopsed/hang and after reboot I got to lain grub console and kernel is unable to smpboot
<infinity> If you boot with nosmp does it work?
<hrw> infinity: this time I end with unable to mount root
<hrw> how to tell which fslabel is root for kernel?
<hrw> uuid is too long to type ;d
<infinity> Is your grub config buggered and no longer sane?
<infinity> You can always use root=/dev/sda2 or whatever, like an old skooler.  UUID isn't required.
<hrw> "linux /boot/vmlinux-3.10.0-2 nosmp rescue single debug" (+ initrd + boot) == 'unable to mount root'
<hrw> sure, but I always forget which sdX my ssd is
<hrw> and list of all partitions is empty anyway ;(
<hrw> time to start bake own kernels like in old times...
<hrw> and have kernel which boots to hdd without any modules
<hrw> uf. booted
#ubuntu-kernel 2013-07-17
<ppisati> ~280 pkgs to upgrade
<ppisati> but X is still stuck
<smb> Unless it gets replaced by xXx
<ppisati> :)
<ppisati> lol
<ppisati> my indicator changed position
<ppisati> i've (from left right) volume, settings, calendar, skype, hph systray, multiload, printer, messaging and network
<ppisati> and after another reboot
<ppisati> my indicator are back to their position
 * apw yawns
<ppisati> 544 pkgs to be upgraded on my laptop
<ppisati> oh yeah...
<ppisati> and i just noticed that my weather indicator on my saucy laptop it's actually the 'old' weather indicator
<ppisati> that was not removed during my transition from Q to S
<apw> ppisati, yeah the weather inditcator is currnetly only in a PPA i think
<smb> the only one I seem to find is for China... 
 * ppisati wonders what's thw weather in China ATM...
 * smb is glad that software-center is such a well tested package...
 * apw finds it to be as well tested ... sigh ... bug filed
<apw> smb, the reboot button works at least
<smb> apw, Mostly not using that one as "sudo reboot" performs sooo much quicker on this doomsbro device
<apw> smb, that good huh (the h/w)
<apw> smb, when i say reboot works, i should mention that booting up doesn't work now
<apw> oh dear
<apw> oh that might be tims kernel
<smb> apw, Yeah, just accidentally bought it... unfortunately its not openly sold as poulsbro but just another gmaxxxx number
<apw> oh when did you get this one
<smb> When I thought I might fill in some mini-itx case with something I could use as a media-box...
<apw> oh no
<apw> you should have sent it back
<apw> and saved yourself some pain, or frankly open the bin and shove it in
<apw> unless it becomes a firewall or router with no screen
<smb> That might be its destination. Meanwhile I use it to remind me every day on how great of an idea it is to only support 3D and use llvm-pipe to make the cpu do the rendering... on an Atom... Beside there was no "I am stupid" tick-box on the return form. :-P
<apw> heh
<lifeless> smb: sadface, I have the same thing sort of problem with a media box I wanted to use.
<lifeless> smb: about to give my rpi a spin, if I can find it,w ith openelec
<smb> lifeless, Yeah, there is the unfortunate small gap between success and fail when buying Intel mini-itx boards with atom. Got one success and now this fail. But well, as said it may end up becoming some sort of server when I get too fed up
<lifeless> smb: I bough t mine 5 years or so ago as a few
<lifeless> s/few/f\/w/
<lifeless> smb: it has video acceleration - it was sold as a media box for pubs - no moving parts to get dust in them
<lifeless> smb: but XMBC wants opengl. WTF.
<smb> lifeless, Yeah, it is sold as that and if Intel would be more serious it could have video acceleration. But one has to be glad there is modeset support at all now. 
<lifeless> indeed
<apw> smb, so you can have plymouth during boot, wooo
<smb> apw, Yeah for that short period of time in between the gma500_gfx driver spewing out it not feeling happy. :)
<smb> (incorrect EDIDs and disabled pipes and such)
<infinity> zequence: Do I get new metas to go with those kernels?
<apw> smb, always the way
<tvoss_> hello
<tvoss_> do we have a perf build available for the touch images?
<infinity> tvoss_: There should be a linux-tools-$(uname -r) for all the touch kernels now, I believe.
<infinity> tvoss_: Pretty sure rtg fixed all that up.
<infinity> At least, I vaguely recall NEWing a lot of linux-tools packages in the last few months. :P
<tvoss_> infinity, cool :) so greyback just joined, he had problems installing perf
<greyback> infinity: hi!
<tvoss_> infinity, mind giving him a hand?
<infinity> I didn't know your question was a trap. :P
<infinity> greyback: What's up?
<infinity> Define "problems".
<tvoss_> infinity, ;)
 * tvoss_ notes beer_counter[infinity]++
<greyback> infinity: sorry! :) I want to run "perf" on a phablet image. So I install linux-tools, which I think pulled in linux-tools-3.10.0-2
<infinity> tvoss_: I think we're on to fine wine at this point.
<infinity> greyback: Yeah, don't do that.
<tvoss_> infinity, fair point :) red or white?
<greyback> infinity: but kernel of phablet image is 3.0.0-3.. so it won't match
<infinity> greyback: You want linux-tools-$(uname -r), the "linux-tools" metapackage is just for -generic.
<greyback> infinity: sure, but there's no linux-tools package matching the kernel on phablet image that I know of
<infinity> Hrm.  I *thought* rtg fixed all that.
 * infinity looks.
<greyback> infinity: maybe a PPA with it exists somewhere?
<infinity> Hah.  No, he just named them wrong.
<infinity> greyback: Which kernel is that?
<infinity> Maguro, I'm assuming, from your version.
<infinity> greyback: linux-maguro-tools-3.0.0-3
<infinity> greyback: And we'll yell at rtg for the broken naming scheme.
<infinity> apw: Or you can fix ^^
<greyback> infinity: yep that's it
<infinity> apw: That should so be linux-tools-3.0.0-3-maguro
<infinity> greyback: linux-maguro-tools is the metapackage that matches, also wrongly-named.
<infinity> apw: And the meta should be linux-tools-maguro, not linux-maguro-tools
<apw> it cirtainly should mate the linux-image one, and that is linux-image-generic ... so linux-tools-maguro sounds right
<greyback> infinity: magic, trying..
<apw> i'll have a peek at them
<infinity> apw: I suspect rtg got confused by the common packages using $stem-$src-$thing, while the flavour-specific ones should be $stem-$thing-$flavour
<apw> do we have a linux-tools-generic, we really shoudl
<apw> a full review would not go amis
 * apw adds it to his todo, but he is not going to be derailed from uploading this lowlatency
<infinity> apw: See linux-headers-3.0.0-3-maguro versus linux-maguro-headers-3.0.0-3 (correct), tools should match the scheme.  So linux-maguro-tools-common and linux-tools-3.0.0-3-maguro
<apw> (it has happened toooo many times)
<infinity> Or, at lease, some approximation thereof. :)
<infinity> s/lease/least/
<apw> makes sense... within the not making a lot of sense framekwork we live in
<infinity> apw: I'm not sure who to blame for the source/flavour confusion, but I imagine it's either you or rtg originally.
<infinity> apw: Since this comes from either lowlatency or ppc, or a combination of the two.
<apw> well the names with the prefix being linux-<version>-<flavour> regardless of source package, that comes from d-i's needs
<infinity> apw: But the sane rule of thumb would seem to be, if it's a source-common package, refer to the source, if it's flavour-specific, use the proper ABI-FLAVOUR, and done.
<apw> linux-image-*-generic linux-headers-*-generic etc is all 'd-i'
<apw> right and that should be the plan
<apw> i'll go through them later and see
 * infinity nods.
<infinity> I think I still need to push a patch to Ben to fix tools in PPC too.
<infinity> Not only has it been turned off all this time, but it still claims to build an arch:all common package, which confuses LP a tiny bit.
<apw> infinity, perhaps i can look at that once i have fixed up maguro et al, as they should be a good approved form by the time we get there
<greyback> infinity: linux-maguro-tools working perfectly, thank you for the help
<infinity> greyback: NP.
<tvoss_> infinity, red or white? :)
<infinity> tvoss_: A nice shiraz would make me happy right about now.  Perhaps a Penfolds Grange.
<tvoss_> infinity, noted down :)
<infinity> tvoss_: (Or a St Henri or Bin 28, if you're feeling cheap)
<tvoss_> infinity, do we have kernel symbols available for the touch images?
<infinity> Should do.
<infinity> tvoss_: For the kernel greyback was using, http://ddebs.ubuntu.com/pool/universe/l/linux-maguro/
<apw> rtg, fyi i booted up unstable and it works ok on i386, amd64 here is blamoming on one box at least
<apw> rtg, also aufs looks to be working on i386 at least
<rtg> really? I booted amd64 yesterday just fine. any idea where its croaking ?
<rtg> apw, and what is 'blamoming' ?
<rtg> exactly ?
<apw> rtg, blammo'ing implies exploding, though in this case it is seemingly hanging pretty early
<rtg> google ain't finding it
<rtg> apw, so, its like an aborted bloom ?
<apw> i am about to test a second amd64 machine to see if that is ok, one which is simpler than the original
<apw> no i think i have typo'd an m into it. blammo
<rtg> ah, now that parses
<apw> rtg, ok amd64 boots ok on this non-efi machine, so its likely machine or efi specific ... fun
<rtg> apw, great, I just f*%king love EFI problems
<apw> yeah so very easy to diagnose
<rtg> apw, bbiab
<apw> rtg, replied confirming applied
 * apw pops out
<rtg> apw, thatnkyou sir
<rtg> cking, have you ever messed with CONFIG_DYNAMIC_DEBUG ?
<cking> rtg, you're testing my memory on that one
<rtg> cking, I think its a newer feature. you might find it of interest
<cking> that's the pr-debug() stuff isn't it?, so yes, reckon so
<cking> it's been around sincd 2.6.30 hasn't it?
<rtg> cking, really ? I wonder why we haven't had it enabled.
<cking> http://cateee.net/lkddb/web-lkddb/DYNAMIC_DEBUG.html
<cking> 2% overhead?
<rtg> cking, only for the subsystems that use it. I wonder if anyone will notice ?
<cking> rtg, i meant 2% overhead in size, the execution overhead may be peanuts
<rtg> cking, size is no object :)
<rtg> we all have giant PCs
<cking> rtg, is it for phablets ;-)
<rtg> cking, well, I've only enabled it for the distro kernel
<cking> rtg, ok, then that's good then
 * cking reboots
<rtg> apw, so, you think the saucy daily ought to work for UEFI ?
<zequence> infinity: Yeah, let me get those. Got to be kind of late yesterday
<apw> rtg, saucy daily i would expect it to, whether it has been tested i dunno ... i can test it pretty easy
<rtg> apw, thats what I'm up to right now on a tiano core box
<apw> oh heh, then roughtly the same box as here
<apw> ls -l
<rtg> ppisati, linux-generic-lts-raring
<psivaa> jdstrand: thanks for the attempt for bug #1197484. the issue did not go away though, but /sbin/dhclient-script permission denied message has disappeared 
<ubot2`> Launchpad bug 1197484 in isc-dhcp (Ubuntu) "Connection requests to saucy server VMs from a hosts fail after fresh VM installs" [High,Fix released] https://launchpad.net/bugs/1197484
<jdstrand> yeah, I saw your new bug
<jdstrand> sorry it didn't work out
<psivaa> thanks for the attempt :) though, i understand reproducing is very tedious in that 
<rtg> apw, cking: how _does_ one get a tunnel mountain tiano core machine to boot from DVD  when fastboot mode is enabled.
<apw> rtg, i believe if fastboot is enabled you have to boot windows and turn it off don't you ?
<rtg> apw, we didn't ever develop a UI that runs from Linux ? 
<rtg> no wonder I hate this machine
<apw> rtg, i don't think so, cause to boot linux you need to have already turned it ogff i think
<apw> something dumb like that
<rtg> shit, I don't have windoze.
<apw> hmmm how did that happen
<apw> there may be a button you hold but no idea what it would be
<apw> cking might if he was here
<rtg> manjo happened....
<apw> and he might know too ... that manjo
<rtg> maybe _you_ shuold test the UEFI daily, and I'll go work on enabling armhf in LTS Raring.
<rtg> apw, ^^
<apw> rtg, ok, i did start it syncing some time back
<rtg> apw, I could upgrade mine, but if it doesn't work then I'm hosed
<apw> rtg np will do mine
<manjo> fastboot disables keyboard so there might be a way to get to bios 
<manjo> so last UDS we talked about setting env var that says boot to bios on next boot using a menu option at reboot
<manjo> <reboot> <shutdown> <boot bios>
<manjo> I brought this up several times at UDS 
<rtg> manjo, its kind of a foundation issue
<manjo> right 
<jdstrand> psivaa: do you have a way to test a package that is not in the archive?
<psivaa> jdstrand: i am doubtful since this appear to happen on the first boot when the installation finishes
<jdstrand> psivaa: are you able to stop the tests before the reboot?
<jdstrand> psivaa: or, do you see it after subsequent reboots?
<psivaa> jdstrand: i dont see that on the subsequent reboots
<psivaa> jdstrand: i could stop the tests after the reboots but the reboot will have happened then and if that's ok then i could try
<jdstrand> psivaa: what we want to do is modify the apparmor policy before it is applied in the next reboot
<psivaa> jdstrand: can that be done using preseed?
<jdstrand> and by next, I of course mean, 'first'
<ppisati> rtg: is linux-generic-lts-raring part of backports?
<jdstrand> psivaa: we can't modify policy in preseed no
<rtg> ppisati, no, should be precise main
<ppisati> rtg: uhm
<ppisati> ubuntu@c16:~$ apt-cache search linux-generic-lts-raring
<ppisati> ubuntu@c16:~$
<jdstrand> psivaa: if you can stop the machine before networking comes up, modify the policy, then resume boot, that would work
<rtg> ppisati, rtg@gomeisa:~$ rmadison linux-generic-lts-raring
<rtg> linux-generic-lts-raring | 3.8.0.23.22 | precise-security | amd64, i386
<rtg> linux-generic-lts-raring | 3.8.0.26.25 | precise-updates | amd64, i386
<rtg> linux-generic-lts-raring | 3.8.0.27.26 | precise-proposed | amd64, i386
<jdstrand> psivaa: another alternative is disabling appamor. are you able to adjust the kernel command line?
<ppisati> rtg: ah wait
<ppisati> rtg: amd64, i386
<rtg> ppisati, right now it is. I am working on producing an armhf version, so you can't test for awhile
<ppisati> rtg: ok
<psivaa> jdstrand:ok, i dont think so, i'm asking the utah dev team to see if that's possible. but i think i can pause the vm before modifying the apparmor policy
<rtg> I forgot the LTS was only x86
<psivaa> jdstrand: so it appears that we could modify the kernel command line args using preseeds. 
<jdstrand> psivaa: if you add this to the kernel command line: "apparmor=0" it should disable apparmor
<jdstrand> psivaa: you'll know it worked by running 'sudo aa-status' after rebooting
<psivaa> jdstrand: ok, thanks, ill try and report back how it goes
<bjf> ogasawara, can you verify bug 1196658 ?
<ubot2`> Launchpad bug 1196658 in linux (Ubuntu Raring) "Add support for Intel Avoton SoC" [Medium,In progress] https://launchpad.net/bugs/1196658
<bjf> smb, can you verify bug 1191726 ?
<ubot2`> Launchpad bug 1191726 in linux (Ubuntu Raring) "dm-snapshot should be in the installer environment" [Undecided,New] https://launchpad.net/bugs/1191726
<smb> bjf, probably as for previous kernels only up to that it is in the udeb
<smb> bjf, To that degree -> done
<bjf> smb, thanks
<infinity> zequence: Thanks.
<infinity> zequence: I'll double-check the lot and get things in proposed later tonight, if I don't get lost in a pub, tomorrow morning if I do. ;)
<zequence> infinity: Thanks. Hot days like these can really turn you into an alcoholic
<infinity> zequence: Yeah, it's pretty unpleasant out there.
<med_> jsalisbury, how long should it take for a raring kernel to go from -proposed into -updates?
<med_> ref: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1180419
<ubot2`> Ubuntu bug 1180419 in linux (Ubuntu Saucy) "Ringtail on Hyper-V causes BUG: scheduling while atomic" [High,Fix released]
<jsalisbury> med_, I believe it's about 3 weeks.  bjf may know for sure.
<med_> bjf ^
<med_> oh, okay
 * med_ thought it was 7 days...
<bjf> med_, approx. 3 weeks from start to finish. the ones in -proposed right now should hit -updates by friday of next week
<med_> bjf, danke.
<med_> jsalisbury, thanks
<jsalisbury> med_, np
 * rtg -> lunch
<arges> jsalisbury: hey should bug 1180419 be marked Fix Committed instead of Released ?
<ubot2`> Launchpad bug 1180419 in linux (Ubuntu Saucy) "Ringtail on Hyper-V causes BUG: scheduling while atomic" [High,Fix released] https://launchpad.net/bugs/1180419
<arges> not sure why somebody marked it released
<med_> tx arges.
<bjf> arges, yes, someone whas just being "helpful"
<arges> : )
<rtg> bjf, please have a look at the Raring LTS pull request. We should get that in the pipeline pretty soon. I also need to add armhf support to the meta package
<bjf> rtg, will do right away. is it worth respinning what we have in the pipeline?
<rtg> bjf, thats what the pull request does, e.g., I repackaged with a new version
<rtg> bjf, though I noticed the changelog could use a tweak to include the LP bug number
<rtg> and tracking number too I suppose
<bjf> rtg, ack'd
<rtg> bjf, you want it uploaded to the non-virt kernel PPA ?
<bjf> yup
<rtg> bjf, ok, I'll fix tha changelog first
<bjf> rtg, new tracking bug please, and we'll dupe the old one to this one
<rtg> yup
<Kano> hi, will the package always use 3.10.0 name or change the .0 to something higher?
<rtg> Kano, its gonna change to 3.11.0 sometime around -rc3
<Kano> but i mean when you rebase to 3.10.1 why do you keep the 0?
<rtg> the '0' in the package name is pretty much constant for packaging reasons
<Kano> also you still dont use .orig
<rtg> not yet
<rtg> we will when 3.11 is released
<Kano> at least the firmware is updated now
<rtg> for now...
<Kano> i had to do my own package update with uvd, but for 3.11 you need other files, are those in there already?
<rtg> Kano, I think linux-firmware is rebased against tip of the upstream repo (as of a few days ago)
<Kano> did the one who asked to make ahci as module ever provide a link to an updated driver?
<Kano> i would revert it until he shows his code
<Kano> now i always have to patch the kernel back
<Kano> because some users boot without initrd on uefi systems for max bootspeed
<Kano> btw. i would prefer nvidia/fglrx patches which are NOT activated via dkms, because you can adopt them more easy on debian packages when the kernel version checks are in the patch code and not in dkms.conf
<Kano> what is the option to disable _amd64.tar.gz?
<Kano> does 3.10.0-3.12 really compile??
<Kano> i really think there is a race condition
<bjf> jsalisbury, any progress on bug 1173423 ?
<ubot2`> Launchpad bug 1173423 in linux (Ubuntu) "Kernel fails to update EFI vars, rendering system unbootable [P8P67 PRO REV 3.1, BIOS 1904 08/15/2011]" [Critical,In progress] https://launchpad.net/bugs/1173423
<jsalisbury> bjf, I never did hear back from upstream.  Let me ping em again.
<bjf> mjg59, any thoughts on this bug? ^
<jsalisbury> bjf, even easier :-)
<bjf> jsalisbury, i've no clue what timezone he is in
<jsalisbury> bjf, I'll send email again, but also use [RESEND] in the subject.
<mjg59> bjf: Yeah, fixed by f8b8404337de4e2466e2e1139ea68b1f8295974f
<bjf> mjg59, thanks
<jsalisbury> mjg59, bjf, thanks.  I'll build a test kernel for the bug.
<bjf> jsalisbury, i think that is in the next 3.8 stable update
<bjf> jsalisbury, this is the efi patch we were discussing two weeks ago
<jsalisbury> bjf, great
<bjf> jsalisbury, we got possitive testing from cking so i think kamal has it all queued up
<jsalisbury> bjf, is it already in proposed?  
<bjf> jsalisbury, no, next proposed
<jsalisbury> bjf, cool.  I'll request testing of proposed instead of building a kernel
<bjf> jsalisbury, it will probably land in the master-next branch shortly
<jsalisbury> bjf, ok thanks.  
<jsalisbury> mjg59, I resent an earlier email.  I'll respond that you replied.  thanks again.
<kamal> bjf, jsalisbury, mjg59: I did apply that that UEFI fix f8b8404 to ubuntu-raring, but somehow missed it for 3.8.y-stable ...  I'll sort that out.
<jsalisbury> bjf, updated bug
<mjg59> kamal: Thanks!
<jsalisbury> kamal, thanks
<kamal> bjf, jsalisbury, mjg59: minor correction ...  I didn't actually apply that fix to ubuntu-raring either :-(.   I just *planned* to do so.   I'll do so.
<infinity> bjf: Argh.  Tim's lts-raring wasn't built against an orig.
<infinity> bjf: I wish we had a better way to notice that regression other than me whining.
<bjf> infinity, agreed
<infinity> bjf: Not that it's world ending for one upload to miss the orig, but it makes the diffs a lot harder to audit.
<med_> bjf, thanks for correcting status of 1180419. I was really confused (and had assumed Lemberger was part of the kernel team)
<med_> "Nicholas Lemberger is not an active member of any Launchpad teams."
<kamal> bjf, jsalisbury, mjg59: ok, the UEFI fix f8b8404 now really is queued up for 3.8.13.5 stable, which I will release on Monday.   we've decided that ubuntu-raring will just pick it up from there.
#ubuntu-kernel 2013-07-18
<ppisati> brb
 * apw realises he isn't on irc :) [sic]
<smb> apw, nor on mumble fwiw
<apw> no indeed ... up in the office
<psivaa> jdstrand: with apparmor disabled, bug #1202203 does not occur
<ubot2`> Launchpad bug 1202203 in isc-dhcp (Ubuntu) "Connection requests to saucy server VMs from a hosts fail after fresh preseeded VM installs" [Undecided,New] https://launchpad.net/bugs/1202203
<psivaa> updated the bug with this info
<jdstrand> psivaa: how many times did you try? iirc, it didn't always happen with apparmor enabled
<psivaa> jdstrand: i've run at least 10 times with apparmor disabled. i was also running in parallel with apparmor enabled and i saw the bug in a couple of attempts in that
<psivaa> out of 10 runs where apparmor disabled i did not see any
<rtg> cking, 3.11-rc1 is booting OK on a non-UEFI Lenovo x120e
<cking> guess it's a UEFI specific issue then
<rtg> no doubt
<arges> i see that CONFIG_BLK_DEV_RBD is in the precise common config, but it seems that 'modprobe rbd' doesn't work in the virtual flavor (tested on 3.2.0-49)
<rtg> arges, extras ?
<arges> rtg: ah
<arges> rtg: bingo. thanks
<ppisati> ubuntu@c16:~$ uname -a
<ppisati> Linux c16 3.8.0-27-generic #40~precise2-Ubuntu SMP Thu Jul 18 08:12:12 UTC 2013 armv7l armv7l armv7l GNU/Linux
<ppisati> ubuntu@c16:~$ lsb_release -a
<ppisati> No LSB modules are available.
<ppisati> Distributor ID: Ubuntu
<ppisati> Description:    Ubuntu 12.04.2 LTS
<ppisati> Release:        12.04
<ppisati> Codename:       precise
<ppisati> ubuntu@c16:~$
<ppisati> rtg-afk: ^
<rtg> ppisati, cool. I'll have a Saucy LTS 3.10 based kernel for you to try by about tomorrow.
<ppisati> rtg: ok
<rtg> ogasawara, apw: any objections to me uploading saucy ? there is an Azure fix that needs to get into the wild.
<ogasawara> rtg: no objections here
<infinity> rtg: apw and I have some saucy bits queued locally, but no harm in two back-to-back uploads.
<infinity> rtg: I imagine our bits won't go out until tomorrow.
<bjf> yum, saucy bits
<rtg> infinity, np
<infinity> rtg: Is yours an API bump?  (curious if I need to do a d-i upload tonight to match)
<infinity> s/API/ABI/
<infinity> I may have had some alcohol today.
<rtg> infinity, it is an ABI bumper
<infinity> rtg: Kay, I'll watch out for that then.  If ARM finishes before I sleep, I'll get a d-i in tonight.
<rtg> infinity, and I would think tomorrow morning is soon enough
<bjf> infinity, you don't remember if you have?
<infinity> bjf: I'm fairly certain.
<bjf> infinity, your not letting apw lead you astray are you?
<infinity> bjf: I could think of worse examples to follow.
 * rtg -> EOD
#ubuntu-kernel 2013-07-19
<bryce> sforshee, heya bug #1166442 has been fixed by a patch in linus' tree posted last week.  I stuck the patch on the bug report.  I've verified it on my samsung laptop backported to the 3.5 kernel; issue affects pretty much all recent samsung laptops I gather.
<ubot2`> Launchpad bug 1166442 in linux (Ubuntu Saucy) "Elantech clickpad/touchpad lacks multitouch features." [Low,Confirmed] https://launchpad.net/bugs/1166442
<ppisati> indicators today are in the correct position
<ppisati> but when i click on the volume one, nothing pops up
<ppisati> so i can't change the volume level
<smb> Youre lucky sw update worked
<ppisati> or any other audio-related thing
<ppisati> :(
<ppisati> actually NO indicators work today :(
 * ppisati -> reboot
 * apw yawns
 * smb waits on RAOF mentioning some sort of bees
 * apw realises he isn't on irc :) [sic] him away
<apw> wtf
<apw> that is like old ...
<apw> the bees have takne him away
<smb> giant bees
<cking> smb, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434
<ubot2`> Ubuntu bug 1065434 in linux (Ubuntu Raring) ""unregister_netdevice: waiting for lo to become free. Usage count = 1" after LXC container shutdown" [High,Fix released]
<smb> apw, and yous is not on mumble (again). Quick finish breakfast and get dressed before the doorbell rings
<smb> cking, Ah, thanks... now lets see
<cking> smb, I recall now it was a pain to test because it needed many multiple iterations before I found a way to reproduce it reliably
<smb> cking, Yeah, the new one mentions "after 6000 or so launches and teardowns..." 
<smb> bug 1196295
<ubot2`> Launchpad bug 1196295 in lxc (Ubuntu) "lxc-start enters uninterruptible sleep" [High,Confirmed] https://launchpad.net/bugs/1196295
<cking> urgh
<cking> hrm, very similar looking, but I do wonder if it's a different issue, I guess it may be, hard to tell
<smb> Feels a bit like something that happens after many iterations which then prevents proper cleanup... but really hard to tell
<cking> 6000+ iterations is a killer to bisect with
<smb> And even if you could in theory bisect, my experience with network changes is that they make ones life of bisecting even harder
<cking> double urgh
<apw> smb, or lots of them
<apw> smb, nope not expecting any builders today, thankfully
<smb> apw, The fun with the doorbell is that it does even ring when you are not *expecting* it to
<smb> :)
<smb> And yes, lots of changes and lots of dependencies between 
<apw> as long as they are bringing fun things for me, that is fine
<smb> Yeah, the bills they just put into the letter box (strangely)
 * smb is glad to see that the software-center maintains a consistent level of quality
<RAOF> Bumblebees!
<ppisati> brb
<apw> RAOF, swarms of uber-bumble-bees
 * ppisati -> out for lunch
<psivaa> jdstrand: thanks for the fix for bug 1202203, appears to solve the issue. 20+ runs did not see the bug with today's images. 
<ubot2`> Launchpad bug 1202203 in isc-dhcp (Ubuntu) "Connection requests to saucy server VMs from a hosts fail after fresh preseeded VM installs" [High,Fix released] https://launchpad.net/bugs/1202203
<nessita> hello. Is there anyone available to help me with a potential kernel sound bug? LP: #1201528
<ubot2`> Launchpad bug 1201528 in alsa-driver (Ubuntu) "[Realtek ALC889] - Audio Playback Unavailable" [Undecided,New] https://launchpad.net/bugs/1201528
<rtg> nessita, you might try restarting pulseaudio when it gets in that state, e.g., http://www.linuxplanet.com/linuxplanet/tutorials/7130/2
<nessita> rtg, yeah, but it does not solve it
<nessita> rtg, the sound gets "dead", and nothing fixes it but a restart
<rtg> nessita, the fact that audio output lasts for many minutes before stopping kind of indicates that its a pulse issue. diwic might be able to offer some thoughts.
<nessita> rtg, happy to provide any log that could be useful -- currently I can not do any meeting in this computer, all mumble/skype/hangouts will "break"
<nessita> rtg, I was suggested by the support team that this could be a buffering issue
<rtg> nessita, possibly, but I see no indication in your logs that its a kernel problem. without that there isn't much to go on.
<diwic> nessita, this is worth trying https://wiki.ubuntu.com/Audio/PositionReporting
<nessita> diwic, looking
<nessita> trying with "options snd-hda-intel position_fix=1" and rebooting, brb
<nessita> diwic, hello, I'm back, So, audio worked for a while and stopped working again. I think I noticed the following pattern:
<nessita> if I adjust volume levels using pavucontrol, it usually ork
<nessita> works*
<nessita> but if I use the control dialog below the sound icon in the indicator menu, it breaks immediatly
<diwic> nessita, hmm
<nessita> diwic, I alos note that the device for inout gets constantly reset to the S/PDIF option: I keep chooise the "regular" one (Front Microphone), but every time I close and open the volume control app, the input device is set to the S/PDIF one
<nessita> also*
<nessita> diwic, want me to try with "options snd-hda-intel position_fix=2" noe?
<nessita> now*
<nessita> puf, I'm typing pretty bad today
<diwic> nessita, what have you tried so far? both "position_fix=1", "position_fix=2" and "tsched=0" is worth a try
<diwic> (and a reboot between each one)
<nessita> diwic, right, so far only tried the first one, but I wanted to mention the "pattern" (audio does not break until I open the app in the sound indicator, and input device gets "reset")
<nessita> diwic, will try the other two
 * nessita reboots
<nessita> diwic, hello again! well, seems like position_fix=2 fixed it (well, at least I tried all I tried before and the audio playblack kept working)
<nessita> will comment on the bug
<diwic> nessita, all right, interesting
<nessita> diwic, FYI, the app below the sound indicator keeps "resetting" the input device to the S/PDIF one, but changing it to the Front microphone allows me to use the mic (otherwise mic does not work)
<diwic> nessita, you mean the gnome sound settings?
<nessita> diwic, the app title is "Sound", but I think is that, yes
<nessita> is the section under All settings -> Sound
<nessita> diwic, ping again, when you can. So, audio died, not sure when.
<nessita> diwic, any more ideas what can I try?
<diwic> nessita, well, the tsched=0 one. Remove the nonworking position_fix first
<nessita> diwic, ack, will do
<nessita> diwic, just to be sure, the line I have in /etc/pulse/default.pa is "load-module module-udev-detect use_ucm=0"
<nessita> (the wiki says "load-module module-udev-detect" without the use_ucm=0)
<diwic> nessita, you can keep the use_ucm=0 too, it doesn't matter much
<nessita> ack
<diwic> for your hardware
<nessita> ok, so, reverted options snd-hda-intel position_fix=2 and added the tsched=0, rebooting
<rtg> ppisati, can you install https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4806723 on calxeda as a test ?
<ppisati> rtg: i'll do
<nessita> diwic, so far working, will report back if audio playback stops working
<diwic> ok
<diwic> nessita, you're using standard stereo profile, right? Nothing surround related?
<nessita> diwic, standard stereo setup, and in particular nothing changed in my setup since precise (where audio worked with no glitches)
<nessita> diwic, not sure if it's worth noting that the "only" thing that breaks is audio playback, mic keeps working without issues (even if I can not hear anything)
<diwic> ok
<diwic> nessita, yeah, every time we try to improve the stack for some set of users, it's easy to break for another, as we don't have the ability to test > 1000 machines every time something is changed
<rtg> apw, overlayfs is the only thing standing between me and switching over to 3.11-rc2 in the archive. Is that readdir issue still on your todo list ?
<apw> rtg, yes on todays indeed
<rtg> or, are you gonna make _me_ learn it ?
<apw> heh no, i wouldn't do that
<rtg> prolly wouldn't hurt
<rtg> well, it would _hurt_ a lot, but I should learn it
<apw> rtg, next time
<ppisati> [   12.075144] RAMDISK: Couldn't find valid RAM disk image starting at 0.
<ppisati> [   12.082461] VFS: Cannot open root device "UUID=608a7f64-20e8-400f-97b0-fb34d06bf327" or unknown-block(0,0): error -6
<ppisati> [   12.092984] Please append a correct "root=" boot option; here are the available partitions:
<ppisati> rtg: ^
<ppisati> rtg: uhmm....
<rtg> ppisati, FIIK
<ppisati> rtg: that's weird
<ppisati> rtg: it's the same node as yesterday
<ppisati> rtg: so that UUID should be valid
<rtg> ppisati, missing device driver ? It _is_ a completely different kerenel version
<ppisati> rtg: well, there're two weird things:
<ppisati> 1) [    3.035132] RAMDISK: Couldn't find valid RAM disk image starting at 0.
<ppisati> 2) the uuid thing
<ppisati> actually 2 could be a consequence of 1
<rtg> ppisati, as I am totally distracted by some other issues, I'll leave this problem in your capable hands.
<rtg> :)
<ppisati> rtg: ack
<rtg> at least the tool chain seems functional
<apw> rtg, just pushed a rules change to master-next and unstable to make a new udeb for use in the seeds
<rtg> apw, did you catch the unstable rebase I pushed just a few minutes ago ?
<apw> yeah i fetched 10s before
<rtg> apw, cool
<apw> and when i pushed it was linear
<apw> infinity, i've commited that udeb change for saucy both ... for whenever we upload that
<infinity> apw: Feel the urge to push that to Ben's branch too?
<apw> infinity, will do in a bit indeed
<infinity> (If not, I'll talk to him about it $later)
<hallyn> apw: hey - have you used git-send-email through smtp.canonical.com recently?  I thought it used to work (with the expected obvious arguments) but i'ts failing me right now...  wondering if htere are any new tips and tricks
<apw> hallyn, i think i did it a couple of days ago, nothing different then that i know of
<hallyn> hm, ok.  actually maybe this is a bug in the saucy git-send-email.  it also won't honor --smtp-debug
<apw> hallyn, oh, no i have switched to gmail
<hallyn> just keeps telling me to use --smtp-debug :)
<hallyn> oh, right.
<hallyn> i've been thinking maybe i'll give in and do that.
<hallyn> though i figure they'll just disable imaps access soon now that jabber and rss are gone :)
<apw> i think we are paying for it, so they had better not
<hallyn> all right - thanks.  i guess i'll just send by hand and get on with actual work
<hallyn> ah - was specifying port 587 without thinking - should be 465 (or just unspecified)
<rtg> apw, infinity: so you're gonna use linux-udebs-generic in the debian installer ?
<apw> rtg, in the seeds
<apw> rtg, so a simple fix for overlayfs for the moment might be to revert the removal of readdir
<apw> and then we can work on the replacement or wait for it from upstream overlayfs if it is coming
<apw> anyhow i am working on it
<nessita> diwic, so, bad news. Audio playback no longer works. More info: as per the debugging I was first requested in the bug, I had set pulseaudio to autospawn = no, so I could gather more verbose logging (which is attached to the bug). Noticing that the latest attempt may have worked, I resetted that setting (ie, I removed the .pulse/client.conf) and restarted the computer. Now, opening more than one thing that access pulseaudio (mplay
<nessita> diwic, another debugging info is that now, mplayer can not play a video, it gets absolutely blocked 
<nessita> (ie, the first video frame appears and then nothing else happens)
<diwic> nessita, okay. I'm afraid I don't have time to help you right now, and I don't have any good ideas either.
<nessita> diwic, do you think that moving to saucy could fix this?
<diwic> nessita, you could also try https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS
<rtg> apw, is the removal atomic ? I thought it touched a bunch of file system drivers,
<diwic> nessita, that would be even better to try than saucy 
<apw> rtg, he added the new interface, moved everything over to the new one, and removed the old
<apw> so in theory we could revert the last bit and be ok for now, maybe
<apw> i'll have a play with it
<rtg> ok
<apw> ahh no he may have removed the infrastructure we use as welll ... hmmm well see
<nessita> diwic, will try that, thanks.
<nessita> diwic, shall I remove the "load-module module-udev-detect tsched=0" tweak?
<diwic> nessita, yes, remove it
<nessita> ack
<nessita> diwic, so, if you have more ideas what else could I try, I will appreciate those, since even after updating dkms my audio playback dies. I know you mentioned you can't help me debug now, but perhaps you can indicate another person that could help or guide me?
<nessita> I have pulseaudio set to be verbose (at system level), I keep getting these 3 lines in syslog:
<nessita> Jul 19 12:38:37  pulseaudio[2636]: last message repeated 10 times
<nessita> Jul 19 12:38:37 dali pulseaudio[2636]: [alsa-sink] ratelimit.c: 15 events suppressed
<nessita> Jul 19 12:38:37 dali pulseaudio[2636]: [alsa-sink] alsa-sink.c: Underrun!
<diwic> nessita, yeah, the "Underrun!" is unusual actually
<diwic> nessita, does it happen only with low latency - sound settings, mumble, skype etc, if you only use say some music player, does it still crash?
<nessita> diwic, I use sonata which is a GUI client for mpd, the music server. I never got those to work since I updated to raring
<ppisati> rtg: what's happended to linux-lts-raring - 3.8.0-27.40~precise2? i see there's a new one in the pipe (~precise3), any chance i can get the previous one?
<diwic> nessita, I wonder if the "Underrun!" is due to wrong position reports or system scheduling issues
<nessita> diwic, I even tried uninstalling those two (sonata and mpd), and using rhythmbox, but audio playback eventually dies no matter what
<rtg> ppisati, infinity re-uploaded to use an orig tarball. dunno if the original still exists.
<diwic> nessita, hmm, okay
<diwic> nessita, for further troubleshooting I guess you would need a special pulseaudio build with DEBUG_TIMING on 
<nessita> diwic, I'm not sure about "wrong position reports or system scheduling issues", I don't know what those mean :-)
<nessita> happy to try saucy this weekend, though I see pulseaudio version (mayor) has not changed
<diwic> nessita, we have PA 4.0 in a PPA, but I doubt that would make a difference
<diwic> nessita, https://launchpad.net/~ubuntu-audio-dev/+archive/pulse-testing <-- PA 4.0 is here, and you're welcome to test it, but I doubt it'll help 
<nessita> diwic, your doubts makes me doubtful :-)
<nessita> diwic, not sure if this helps, but is the output of pulseaudio log in syslog when I try to play a video (audio playback does not work and video speed is off, frames are shown too fast, something like 1.5x) https://pastebin.canonical.com/94733/
<nessita> without understanding the output that much, lines that call my attention are "Scheduling delay of 6.33ms, you might want to investigate this to improve latency..."
<nessita> "Have to rewind 65276 bytes on render memblockq"
<diwic> nessita, yeah, scheduling messages with >= 20 ms is not optimal, I saw you had one of those, but not enough to cause constant problems
<nessita> diwic, since you're busy, in order to stop interrrupting you, is there someone else I can ping for debugging further?
<diwic> nessita, not really...unfortunately
<nessita> diwic, would it be better if I ping you again next week? I kind of need audio to work (meetings and all)
<diwic> nessita, what time zone are you in?
<nessita> diwic, GMT-3 (is 1pm for me now(
<nessita> ))
<diwic> nessita, hmm, that sounds like Brazil or something
<nessita> diwic, yeah, Argentina
<diwic> nessita, anyway, yeah, try pinging me on Monday. You could try TheMuso too, but he's in Australia so I doubt you and him will find a time that works for you both
<nessita> diwic, will do, thanks for your time today
 * nessita reboots one more time
<diwic> nessita, yw
<nessita> diwic, one more interrupt (last one!). When rebooting the computer (first reboot since I installed the new dkms), computer will not shutdown, had to sysrq+b to have it rebooting. Error shown in screen was http://ubuntuone.com/5crDl5mdauSvTF0BjnQrQk
 * apw breaks out a beer
<apw> rtg-afk, t
<apw> rtg-afk, t
<apw> rtg-afk, this is going to take some porting me thinks, now do remember if aufs is working that will be used anyhow, so we don't need overlayfs per-se.  so you might upload it to the PPA so that the dkms people can start their grinding
<jsalisbury> apw, rtg-afk, do you think this one should be hot listed: bug 1202887
<ubot2`> Launchpad bug 1202887 in linux-manta (Ubuntu) "'binder: RLIMIT_NICE not set' when using binder from the ubuntu side" [Medium,New] https://launchpad.net/bugs/1202887
<ppisati> ubuntu@c16:~$ uname -a
<ppisati> Linux c16 3.10.0-4-generic #13~precise1-Ubuntu SMP Thu Jul 18 23:37:03 UTC 2013 armv7l armv7l armv7l GNU/Linux
<ppisati> ubuntu@c16:~$ lsb_release -a
<ppisati> No LSB modules are available.
<ppisati> Distributor ID: Ubuntu
<ppisati> Description:    Ubuntu 12.04.2 LTS
<ppisati> Release:        12.04
<ppisati> Codename:       precise
<ppisati> ubuntu@c16:~$
<ppisati> rtg-afk: ^
<ppisati> rtg-afk: the new vmlinuz was too big and was overwriting part of initrd (that resulted in garbage)
<ppisati> rtg-afk: shuffling the things around, made it boot
<ppisati> rtg-afk: but i still need to tweak it to make it automatic now
 * ppisati -> EOW
<rtg> jsalisbury, I'll have a look at bug #1202887. No need to hot list it.
<ubot2`> Launchpad bug 1202887 in linux-manta (Ubuntu) "'binder: RLIMIT_NICE not set' when using binder from the ubuntu side" [Medium,New] https://launchpad.net/bugs/1202887
<jsalisbury> rtg, thanks
<apw> jsalisbury, we should keep an eye yes
<rtg_> apw, do you understand that bug ? 'cause I'm not seeing the problem.
<rtg_> on the other hand, nice seems unreasonably complicated.
<rsalveti> rtg: apw: bug 1203173, in case you guys got a maguro as well
<ubot2`> Launchpad bug 1203173 in touch-preview-images "[maguro] broadcom dongle host driver sometimes fails to load the correct mac address" [Medium,Confirmed] https://launchpad.net/bugs/1203173
#ubuntu-kernel 2013-07-20
<dupondje> Known issues with latest kernel in Saucy ?
<dupondje> what the
<dupondje> Jul 20 22:08:19 laptop-jl kernel: [   38.945777] i915: Unknown parameter `i915_enable_rc6'
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203211
<dupondje> aha
<ubot2`> Ubuntu bug 1203211 in linux (Ubuntu) "Kernel 3.10.0-4 fails on graphical boot with i915 (MacBook Pro 8,2)" [Undecided,Confirmed]
<infinity> dupondje: If it's an Optimus system, can you confirm that it works fine if you disable discrete graphics entirely in the BIOS?
<infinity> dupondje: (Mine's an Optimus, but I disable the nvidia part normally, and I'm not seeing this bug, so I'm curious)
<dupondje> infinity: I have no bios option for that
<infinity> dupondje: Oh, nevermind that then.
<JanC> I don't think MacBooks have a BIOS  ;-)
<dupondje> JanC: its not only macbook affected
<dupondje> Dell XPS15 here
<JanC> right, but I think those have (U)EFI too, and not a (real) BIOS
<JanC> I forgot if Optimus has the outputs on the Intel or on the Nvidia part?
<dupondje> depends :)
<dupondje> HDMI is on nvidia
<dupondje> DisplayPort in Intel
<dupondje> heh :x
<JanC> and internal?
<dupondje> internal ?
<dupondje> internal screen is connected to both ofc
<JanC> that's not really "of course" AFAIK
<dupondje> why not ?
<dupondje> seems quite logic you can use both cards for you internal scren
<JanC> it might seem logic, but sometimes you need one to use the other
<JanC> but like I said, I don't remember the details about Optimus
<JanC> there are differences between multi-GPU laptop setups
<JanC> seems like Optimus always uses the Intel IGP to output to the internal screen
<dupondje> its strange -4 kernel broke down
<dupondje> as there are no relevant changes in it :s
<JanC> I wonder if the nvidia/nouveau drivers could do something wrong? (if they get loaded?)
<dupondje> no changes in nouveau neither
<dupondje> https://launchpadlibrarian.net/145284065/linux_3.10.0-3.12_3.10.0-4.13.diff.gz
<dupondje> not much changes :s
<JanC> there are changes to dependencies etc.
<JanC> mostly version stuff though
#ubuntu-kernel 2013-07-21
<dupondje> Sarvatt: added some debug info
<triniton> Please look at this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203586
<ubot2`> Ubuntu bug 1203586 in linux (Ubuntu) "Loading of bttv driver fails with kernel 3.10.0.4.13" [Undecided,New]
#ubuntu-kernel 2014-07-14
<apw> hallyn, ack
<apw> BLZbubba, as Sarvatt indicated they are built with do_extras_package=0 generally
<hallyn> anybody know of a clean way to have btrfs subvolume delete also delete all subvolumes which are under it?
<apw> hallyn, not me sadly
<hallyn> apw: drat, i guess i'l lhave eto walk the list of subvolumes and do strcmp :(
<apw> hallyn, i would not like to claim to know very much about btrfs, others in our team have usd it more
 * cking has no idea either
<BLZbubba> apw, Sarvatt: ok cool thanks, I'll give "do_extras_package=0" a try
<BLZbubba> i'd like to figure out why i can't insmod my packages into the pre-built kernel, but that isn't nearly as important if I can just run on the one I build
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 22nd, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
 * arges wonders why linux-image-3.13.0-30 amd64 ddebs didn't build...
<marrusl> Hello.  Has anyone seen reports of 3.13.0-31 or -32 causing problems with intel graphics and networking?
<marrusl> In my case it was on a laptop, but I'm still getting details.  also possibly worth noting: the report I have was a hwe 3.13 running on precise.
<apw> marrusl, i have not heard anything specific, file a bug against the package  "linux"
<marrusl> apw, yep.  collecting info. thanks
<arges> https://bugs.launchpad.net/ubuntu/+source/linux/?field.searchtext=3.13.0-31&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&fie
<arges> ld.has_no_package=
<arges> that's an ugly link
<arges> marrusl: ^^^ anyway nothing from my search
<marrusl> thanks arges.  i'll see what i can find out.
#ubuntu-kernel 2014-07-15
<llameadrpc> Is there a known incompatibility between the current Trusty kernel 3.13 and Radeon 3000?
<apw> llameadrpc (N,BFLT) not that we are aware of
<hallyn> sforshee: btw, i haven't sent any acks yet, but your fuse patchset looked good to me, thanks!  (will keep looking at it for a bit)
<sforshee> hallyn: sounds good, thanks
<zul> sforshee:  i saw that patchset how are you suppose to use it in a container?
<sforshee> zul: all I had to do was boot the host into a kernel with the patches and modify the apparmor rules to allow the fuse fs type, then it worked just like anywhere else
<zul> sforshee:  what apparmor rules do you need?
<sforshee> zul: I added "mount fstype=fuse" in /etc/apparmor.d/abstractions/lxc/container-base
<zul> sforshee:  ok cool thanks
<hallyn> sforshee: do you have that kernel built in a ppa?
<sforshee> hallyn: not in a ppa, just built locally
<hallyn> do you mind putting it in one?  (else i'll do it)
<sforshee> hallyn: I can, not sure if I'll get to it today though because I'm taking the afternoon off. If you want it today you might be better off doing it yourself.
<hallyn> sforshee: i'll do it - thanks.  have a good afternoon off :)
<hallyn> apw: i'm confused - was there not a 3.16 kernel in utopic-proposed before?  
<bjf> hallyn, looks like 3.16.0-3.8 is in -release and 3.16.0-4.9 is in -proposed
<hallyn> what on earth... then why am i only getting 3.15 today
<rsalveti> apw: can you apply both patches available at http://people.canonical.com/~rsalveti/epollwakeup/ for mako and flo?
<rsalveti> apw: upstream patches, to avoid different set of features when generating the apparmor features list
<rsalveti> they are already applied for goldfish and manta
#ubuntu-kernel 2014-07-16
<apb1963> kernel: [ 7155.242456] vlc[31923]: segfault at f5033fa4 ip 00cb6858 sp b74b3740 error 5 in l
<apb1963> ibc-2.15.so[c3f000+1a4000]
<apb1963> kernel: [   84.517364] conky[3377]: segfault at 0 ip 0108fc74 sp bfb3a3a8 error 4 in libc-2.
<apb1963> 15.so[f45000+1a4000]
<hallyn_> apw: hi - https://launchpadlibrarian.net/180036016/buildlog_ubuntu-utopic-amd64.linux_3.16.0-4.9fuse1_FAILEDTOBUILD.txt.gz   does that suggest to you that the builder ran out of space?
 * hallyn_ tries a rebuild in the hopes it was transient (which will destroy that log)
<apw> rsalveti, will look
<apw> rsalveti, ok both uploaded to the ckt ppa
<apw> rsalveti, and built in same
<rsalveti> apw: great, thanks so much
<hallyn> apw: rebuild works, so i guess ppa builder did in fact run out of space
<hallyn> zul: so we should have a fuse-in-usserns-enabled kernel in ppa:serge-hallyn/userns-natty
<apw> hallyn, ack
<zul> hallyn:  cool
<zul> hallyn:  im still wiring in nova bits so im not quite there yet
<hallyn> ok.  i'm goign to try myhand at devstack in just a bit.
<zul> hallyn:  ack
<zul> hallyn:  ill help you set it up
<hallyn> i was gonna try and just follow the directions in your email from a week or two ago
<hallyn> but i'm looking at ()*$%)($*% btrfs first
<hallyn> egads the btrfs_progs implementation of subvolume list is intimidating.  rbtrees and all
<rsalveti> rtg: apw: can you guys help investigating bug 1329374? blocks the x86 emulator for a few folks, but I'm unable to reproduce it
<ubot5> bug 1329374 in linux-goldfish (Ubuntu) "kernel panic pressing any key in terminal that spawned emulator" [Undecided,New] https://launchpad.net/bugs/1329374
<rsalveti> rtg: google also updated the main tree for goldfish, with quite a few changes (including stable changes), might be a good idea for us to rebase on top of that again
<rsalveti> https://android.googlesource.com/kernel/goldfish/+log/android-goldfish-3.4
<rsalveti> wonder if that helps fixing the gcc 4.6 dependency issue
<rtg> rsalveti, how about starting a bug and assigning me. I need to hop on a flight soon.
<rsalveti> rtg: sure
<rtg> rsalveti, thanks
<rtg> got soem other irons in the fire right now, so I'm likely to forget.
<hallyn> zul: best url for installing devstack?
<rsalveti> rtg: bug 1342783
<ubot5> bug 1342783 in linux-goldfish (Ubuntu) "Rebase kernel with latest from AOSP" [Undecided,New] https://launchpad.net/bugs/1342783
<rsalveti> rtg: should I assign bug 1329374 to you as well?
<ubot5> bug 1329374 in linux-goldfish (Ubuntu) "kernel panic pressing any key in terminal that spawned emulator" [Undecided,New] https://launchpad.net/bugs/1329374
<rtg> rsalveti, I'll do it.
<rsalveti> great, thanks
<zul> http://www.devstack.org
<Sarvatt> rsalveti, rtg: thats probably fixed by https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64325a3be08d364a62ee8f84b2cf86934bc2544a
<rsalveti> Sarvatt: cool
<Sarvatt> its in 3.4 stable so the update will grab it
<rsalveti> great
#ubuntu-kernel 2014-07-17
<ara> bjf, ping
<bjf> ara, yes?
<ara> bjf, hey, we have seen that the kernels have been released, but we were still testing
<ara> bjf, what happened?
<bjf> ara, critical CVE. we decided to appy it to what was currently in -proposed and release them all
<ara> bjf, when was the decision made? we would appreciate if you could ping us as soon as you make the decision
<bjf> ara, it was an embargoed CVE. we are not allowed to discuss it. they went to -updates and -security yesterday
<bjf> ara, i was just about to send out email
<ara> bjf, ok, thanks
<ubuntu1404usb32> I have just updated the kernel from 3.13.0-30 to 3.13.0-32 for Ubuntu 14.04 that has all "stable" updates.  As soon as I rebooted (several times) the two computer fans went from the average 1400 RPM to 1800 to 2000 RPM. I booted up a previously dd'd version of the same 14.04 configuration (backup) running kernel 3.13.0-30 without the kernel update and the fans went down to the average 1400...
<ubuntu1404usb32> ...RPM.  Any ideas on what may be happening? Intel Core i7 CPU 920@2.67 GHz X 8 64 bit 4 Gig RAM
<rtg> rsalveti, goldfish is ready in the CKT PPA
<rsalveti> rtg: cool, thanks
<ubuntu1404usb32> Update for "kernel 3.13.0.32 Fan RPMs greatly increased":  Rebooted with the 3.13.0-30 kernel and both fans reduced RMS to 1400 average or less, temperature indicators are now in normal range and no alarms. Previous to that, I reinstalled the 3.13.0-32 kernel and realized no change - Fan RPMs up, temperature indicators up, and several alarms.
<[1]rsa_sean> Anyone else seeing a "ALERT /dev/mapper/vg00-root does not exist" error on new netboot server installs
<[1]rsa_sean> We also have no way of interacting with ash because it does not recognise usb keyboards ...
<[1]rsa_sean> this is on 14.04 server installs
<[1]rsa_sean> same configuration worked 3 weeks ago, this week we are getting these errors
#ubuntu-kernel 2014-07-18
<apw> [1]rsa_sean [N,BFTL], not heard reports of that, cirtainly we should get a bug filed against "linux" at least
<apw> ubuntu1404usb32 [N,BFTL], not heard reports of that, a bug against "linux" would contain h/w info whihc may help
<stgraber> FYI i filed bug 1344049 for a cherry-pick of a netns/userns fix
<ubot5> bug 1344049 in linux (Ubuntu) "Please cherry-pick tc rule fix for userns" [Undecided,New] https://launchpad.net/bugs/1344049
<rtg> stgraber, working on it
<stgraber> rtg: great, thanks!
<rtg> stgraber, its not a clean cherry-pick, but the backport looks simple enough
<stgraber> oh, I guess something must have happened to linus' tree before net-next was merged then, because the commit as was pushed to net-next was applying cleanly on 3.13 (that's what I'm running here)
<stgraber> rtg: http://paste.ubuntu.com/7814633/
<rtg> stgraber, yeah, I'm looking at the patch. try the cherry-pick yourself.
<rtg> capable() morphed into netlink_capable()
<stgraber> ah yeah, apparently you need to replace ns_capable(userns, CAP_NET_ADMIN) by netlink_ns_capable(skb, userns, CAP_NET_ADMIN)
<stgraber> the source of the conflict is: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/sched/?id=5f013c9bc70214dcacd5fbed5a06c217d6ff9c59
<rtg> right. I'm just gonna do a simple backport so I don't have to deal with an upstream merge resolution
#ubuntu-kernel 2014-07-19
<Hauke> The UTS_UBUNTU_RELEASE_ABI define added in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1327619 causes problems with ubuntu mainline kernel 3.16.0-031600rc5-generic
<Hauke> on this kernel #define UTS_UBUNTU_RELEASE_ABI 031600rc5 will be added, which is not a number
<Hauke> as you do not do any modifications to the mainline kernel UTS_UBUNTU_RELEASE_ABI is not needed here and LINUX_VERSION_CODE should be enough
<apw> Hauke, could you file a bug on that for me, assign it to apw and let me know the number
<Hauke> apw: will do that
#ubuntu-kernel 2015-07-13
<cristian_c> jsalisbury: hi
<jsalisbury> cristian_c, hello
<jsalisbury> cristian_c, i should have some time to get back on your bug this week
<cristian_c> jsalisbury: exactly, what havenI to do, now?
<cristian_c> or you
<cristian_c> *I have to do
<jsalisbury> cristian_c, i'll review the bug again.  I recall we finished the bisect and identified the regression
<cristian_c> yes
<jsalisbury> cristian_c, i'll take a look and post an update
<cristian_c> ok
<jdstrand> sforshee: hey, re bug 1473560-- you said "I really though we had
<jdstrand> picked up the two commits above in vivid, so maybe they just got lost in
<jdstrand> the rebase."
<jdstrand> sforshee: it *does* work in vivid. it is wily that is the issue
<jdstrand> 4.0 and 4.1
<jdstrand> sforshee: by reading all of the comment, I think you maybe know that already? I just wanted to be extra sure
<sforshee> jdstrand: what I mean was that they got lost in the rebase from vivid to wily
<jdstrand> sforshee: ok. I thought that might be what you meant, but wanted to be doubly sure to save you time
<apw> lp: 1473560
<unixabg> apw: any updates on the overlayfs with casper?
<apw> unixabg, sorry not had a chance to look at it yet
<unixabg> apw: ok just checking in on it and I am willing to test things if need be. The code in casper is
<unixabg> a bit different that how I used to create what I call partial squashfs updates (psu) with 
<unixabg> http://live.debian.net/gitweb/?p=live-tools.git;a=blob_plain;f=bin/live-partial-squashfs-updates;hb=refs/heads/debian-next
<unixabg> wrt setup for overlay. As I recall I just created the ro lower list and overly liked that.
<unixabg> Just let me know if I can test something fo ryou on this matter.
<kees> rtg: say, you know anything about the ath10k driver? It looks like firmware for QCA6164 (and 74) is becoming a blocker for Linux on current generator of Lenovo laptops.
<kees> I tried reading up on the ath10k ML about what's needed to get it, but I rapidly got lost.
<rtg> kees, sforshee has been taking care of firmware lately
<kees> ah-ha! okay
<kees> sforshee: any thoughts on Bug 1436940? I'd love to help get it solved. I figure I've got reasonable chops looking at disassemblies, etc.
<rtg> kees, which is an oblique way of saying I haven't a clue :)
<kees> I'm just not sure what's really _missing_
<kees> rtg: heh, no worries! I don't either, really. :)
#ubuntu-kernel 2015-07-14
<alexlist> Hi folks...
<alexlist> Any chance we can get CONFIG_NETWORK_PHY_TIMESTAMPING enabled by default, e.g. in the -lowlatency kernel?
<infinity> alexlist: It's be a performance hit.
<infinity> alexlist: What's the argument for?
<alexlist> infinity: ok understood. That means I'll have to roll my own... I need precise timestamps in order to measure latency :)
<genkgo> jsalisbury: Just read your comments on the Microsoft backup problem
<genkgo> jsalisbury: do you know whether MIcrosoft has actually done some commits on this issue in the new kernel (4.1?)
<genkgo> jsalisbury: more specifically, are those commits newer than their commits in bug 1445195?
<ubot5> bug 1445195 in linux (Ubuntu Wily) "[Hyper-V] Kernel patches for storvsc" [High,Triaged] https://launchpad.net/bugs/1445195
<genkgo> jsalisbury: nonetheless, i am happy there is action on this topic :)
<tseliot> apw: hey
<apw> hiya
<tseliot> apw: have you read this: http://www.phoronix.com/scan.php?page=article&item=linux-42-of&num=2
<tseliot> apw: they seem to blame it on CONFIG_OF. The kernel panics here too
 * apw gets out his salt-shaker
<tseliot> :)
<tseliot> apw: would it be possible to disable CONFIG_OF in the mainline builds?
<tseliot> that would help our testing
<apw> tseliot, if they are on there likely they are coming from the unstable tree (ours)
<tseliot> apw: right, so, who do I have to bug to get that change into the unstable tree?
<apw> i can look at it
<tseliot> apw: thanks
<apw> i am sure he will be claiming to be the reason its fixed when it changes
<tseliot> :)
<tseliot> anybody can say whatever they want, it still doesn't change actual facts ;)
<apw> "For some reason, the Ubuntu vanilla kernel packages have started enabling CONFIG_OF", that'd be because it started being enablable for x86 when it wasn't before, and the mainline config generator is not precient
<tseliot> hmm... :)
<tseliot> apw: so, it was enabled by accident. Although I find the way he put it much more amusing
<apw> heh no not by accident, the option was expanded to new architectures (all) because "It is also desirable to expand the compile coverage of the DT code.", and the mainline builder defaults it on because it is on on the existing architectures
<tseliot> apw: oh, ok. So it's simply a bug in the code then?
<apw> tseliot, i'd not call that a bug
<apw> tseliot, i'd call that sensible behaviour, selecting the same abilities in as many arches as possible
<tseliot> a feature? :D
<apw> that it doesn't work on there is more of a problem
<tseliot> apw: no, I mean, the kernel panic
<apw> oh the panic, thats just broken indeed
<tseliot> that, to me, seems like a bug
<tseliot> I agree that the config system is sensible
<apw> yeah and it should be fixed and that it was found because they made it enable everywhere is helpful
<apw> i guess, do you have the panic ?
<tseliot> yes
<apw> could you file a bug against linux with it for me, so i can reference it in the "off" for x86
<tseliot> apw: shall I use ubuntu-bug after the panic or would a simple bug report be enough?
<apw> tseliot, as its not an official version it won't let you, a simple report with the panic stack will do me, 
<tseliot> oh, right
<tseliot> apw: BTW has asm/i387.h been dropped in 4.2?
<tseliot> I can see it in 4.0.0-4 but it's not there in 4.2rc2
<TJ-> tseliot: see commit df6b35f
<tseliot> TJ-: thanks a lot :)
<Odd_Bloke> bjf: Are you all moved off the PS4 argyle?  If so, I'll let IS know they can bring the environment down.
<bjf> Odd_Bloke, we think we are i think you should shut the old one down so we know for sure
<bjf> apw, ^
<apw> bjf, ack
<apw> bjf, as far as i know everything has been updated and i have just re-re-started the only persistent bit i have
<apw> bjf, and ... if it explodes we want to know indeed
<Odd_Bloke> Cool.
<bjf> Odd_Bloke, let us know when it's down/gone
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<jsalisbury> genkgo, There are no new commits that were specifically targeted this bug.  This new test kernel has all HV related commits currently in mainline.  It will confirm where or not an entirely new patch is needed to fix the bug.
<tseliot> apw: I've just filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1474447 . Unfortunately I don't see any data about the panic in kern.log. I will upload a screenshot
<ubot5> Ubuntu bug 1474447 in linux (Ubuntu) "Mainline kernel 4.2rc2 panics in Wily" [Undecided,Confirmed]
<apw> tseliot, thanks
<genkgo> jsalisbury: thanks, i will test it, but my guess is that this really needs a fix/commit by ms
<jsalisbury> genkgo, ack, that's what this will confirm.
<apw> tseliot, ok i've turned OF for x86 and marked it up against your bug
<apw> tseliot, so the new mainlines should have that off
<tseliot> apw: thanks a lot!
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 21st, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
<swair>  Why do the run queues have locks? Isn't the scheduler the only 'entity' which touches the run queue?
#ubuntu-kernel 2015-07-15
<DalekSec> apw: There's a typo in the linux-image-${version}-generic depends, linux-initramfs-tools â linux-initramfs-tool
<apw> DalekSec, hmm
<DalekSec> apw: Understandable mixup, considering the description and title of the bug have that same typo.
<DalekSec> However, check on a real Debian system and see that linux-image-3.16.0-4-686-pae, dracut, cryptsetup, etc, etc have it.
<apw> DalekSec, what was the bug number ?
<DalekSec> 1109029
<DalekSec> apw: Thanks for taking a look at the silly thing.
<apw> bah, well thats trash isn't it
<DalekSec> Pretty much, aye.  And if I were to nitpick, d/changelog has a typo, but that hardly matters. :P
<apw> these being  virtual packages and therefore not apt-cache able isn't helping any either
<DalekSec> No, that's pretty useless too.
<apw> and worse there even is a linux-initramfs-tools virtual package _as_well_ who provides that, damn you tools
<DalekSec> Whaaat? >_<
<apw> clearly whoever asked for it isn't testing either, if its taken 4 months for anyone to notice, sigh
<apw> N: Can't select versions from package 'linux-initramfs-tools' as it is purely virtual
<apw> N: Can't select versions from package 'linux-initramfs-tool' as it is purely virtual
<apw> not that it seems east to find out who is offering the former
<DalekSec> Well, to be fair it's pretty hard considering the troubles with plymouth and all.  In order to test again, I had to rebuild kbd, plymouth, console-setup, watershed, and a few more.
<DalekSec> Maybe just the kernel?
<apw> the kernel seems an odd thing to offer that
<apw> and i don't recall ours doing so
<DalekSec> lists/us.archive.ubuntu.com_ubuntu_dists_wily_main_binary-i386_Package seems to think just the kernel that depends on it.
<apw> as in the kenrle consuming it, is making it ?
<DalekSec> I'd believe so, http://packages.ubuntu.com/wily/linux-initramfs-tool vs http://packages.ubuntu.com/wily/linux-initramfs-tools ?
<DalekSec> (vs https://packages.debian.org/sid/linux-initramfs-tool )
<apw> bah, this bug needs fixing
<DalekSec> (Ah!  apparmor, that was the other one!)
<DalekSec> Got the description too, just to be clearer.
<apw> ok filed another bug to fix it in the kernel
<DalekSec> Great thanks, and sorry.
<apw> DalekSec, i assume you are testing in wily by now
<DalekSec> apw: Wily FDE, just to make it fun (or because I'm a masochist)
<apw> great, then that is applied to wily for the next upload
<infinity> apw: "N: Can't select versions from package 'linux-initramfs-tools' as it is purely virtual" is because the kernel depended on it, nothing provides it.
<infinity> apw: (A bit confusing, I know)
<apw> then again it also says that for linux-initramfs-tool which two things do provide
<infinity> apw: Right.
<apw> hopeless tools :/
<infinity> apw: The "pure virtual" message is just poorly worded.  It really means "some packages reference this name, but no package is called that".
<DalekSec> infinity: Can I bug you later about adding that alt dep? :P
<infinity> DalekSec: To...?
<DalekSec> infinity: Pinged sbea ttie about apparmor, but there's kbd too that should be an otherwise no-change.  While console-setup works, that actually has some initramfs config.
<infinity> DalekSec: To be perfectly honest, while I can go and add the alt dep here and there where it's needed, I also have zero urge to support such configurations.  Unlike Debian, Ubuntu isn't about "give people 100 choices and make sure they all work".
<DalekSec> Sure, understandable.  I'm just trying to get it to an installable state.
<apw> most of those would come to us for free if debian was fixed
<infinity> DalekSec: I get that.  I'm just saying that might be counter-productive.
<infinity> DalekSec: Cause then all of us have to field bug reports from people "trying dracut" and booting slightly differently.
<DalekSec> infinity: Yeah, thought of that.  It is a very valid concern.
<infinity> DalekSec: It's disingenuous to say "don't worry, this is a minor change that's zero effort", cause it *will* generate work.
<infinity> I'm reminded of the flood of bug reports we had on trusty and utopic with people booting with init=/lib/systemd/systemd
<infinity> Which were a royal pain to weed out.
<infinity> But at least that was a change we were planning to make.
<infinity> We have no intention of switching to dracut.
<DalekSec> infinity: FWIW, ubuntu-minimal still depends on initramfs-tools.
<ogra_> because it is an essential bit of any ubuntu system ? 
<infinity> DalekSec: You say that like people don't remove minimal when they want to play. :)
<DalekSec> ...I did not do that, nooo. :3
<DalekSec> ogra_: Right, but maybe I'm giving people too much credit by thinking they'll go "Hey, this sounds important, maybe I shouldn't."
<infinity> DalekSec: Anyhow, it's just something to consider.  Maybe adding something to apport to report on the provider of /usr/sbin/update-initramfs would be enough to bin any such bug reports as suspicious.
<ogra_> DalekSec, well, and you shouldnt :) 
<infinity> ogra_: Well, he's fully aware of what he's doing, so that's fine.
<ogra_> infinity, he ... yes :) 
<infinity> My concern is people who read a blog post, or are systemd fanboys who hear "dracut == systemd" and decide they have to switch to be hip and cool...
<infinity> Those people will generate a ton of noise.
<ogra_> "someone" isnt ... and should be alerted if ubuntu-minimal wants to be removed :) 
<infinity> I fear the day when everyone thinks they should switch from grub to gummiboot and file bugs on us after breaking that...
<DalekSec> Well, can one really say that?  I'm just rebuilding console-setup, dracut, watershed, kbd, plymouth, and apparmor (and yes, only installed to a VM so far, for sanity.)
<ogra_> lol, well, we will have switched x86 to uboot by then
<infinity> ogra_: Eh?
 * ogra_ grins
<infinity> ogra_: Not sure how uboot relates. :P
<ogra_> they would need to use ugummiboot then ;) 
<infinity> ogra_: You're aware that systemd pulled in gummiboot into their tree and is pushing it as the One True Bootloader to go with all their other One True Userspace bits.
<ogra_> insane
<infinity> Yeah.  If systemd was just an init system, I'd be much happier with them. :/
<DalekSec> ^ and it might actually be likeable as they could focus on fixing bugs more.
<ogra_> well, even widespread bootloaders still have tons of bugs ... its just one more potentially broken thing 
<DalekSec> But better to have more testing and integration than fringe and barely tested.
<infinity> Anyhow, back to work with me.
<DalekSec> Awwh, oh well. :P
<ogra_> well, i cant imagine a better tested bootloader on arm than uboot for example ... 
<ogra_> i know there are some grub ports for 32bit arm ... but nobody ever used them in a serious env 
<ogra_> whyy would i switch any of my devices to a new thing thats less tested and less established
<jdstrand> ogasawara, sforshee: fyi, 4.1.0-1.1~rc2-generic fixes bug #1473560 for me (and I commented in the bug). Thanks a lot! :)
<ubot5> bug 1473560 in linux (Ubuntu) "microphone regression on 4.1" [Medium,In progress] https://launchpad.net/bugs/1473560
<ogasawara> jdstrand: sweet, thanks for testing
<jdstrand> It was absolutely my pleasure. I like having working hardware :)
<ogasawara> sforshee: and thanks for the heavy lifting there
<sforshee> ogasawara: np, it was pretty easy once I found out there was already a fix upstream
<infinity> ogra_: Oh hey, you might know the answer to this.  Do we still attempt to support any devices with kernels older than 3.4?
<ogra_> not older i think 
<infinity> ogra_: Aurelien is pushing to bump the glibc MIN_VERSION to 3.2.0 in Debian, which I think is sane for us to follow suit on in Ubuntu, but I'm worried someone will whine about it breaking on an ancient Android kernel of doom.
<ogra_> but the phones have 3.4 kernels 
<ogra_> i think 3.2 should be fine ... 
<ogra_> for safety reasons you should ask john-mcalleele
<infinity> ogra_: We used to have some 3.0.0 device (original nexus7 maybe?), but perhaps everyone stopped caring?
<ogra_> that was the original galaxy nexus ... but thats dead
<apw> grouper or something
<ogra_> no, maguro i think 
<infinity> I vaguely recall removing that from the archive.
<infinity> I should double-check, though.
<ogra_> i think grouper was actually 3.2 ... ICBW though
<infinity> 3.1 maybe?
<infinity> It was something weird.
<infinity> Yeah, 3.1 .. And I removed it in vivid.  \o/
<infinity> And maguro has been gone since utopic.
<infinity> So, yay.
<ogra_> yeah
<arges> apw: how does debian.master/config/annotations work? I did an updateconfig after adding a config option and one of the enforced CONFIG options doesn't seem to want to be set. 
<arges> this is for ppc64el/powerpc64
<apw> define didn't want to be set, and which one
<arges> apw: CONFIG_PPC_POWERNV_RTAS doesn't get set to 'y' when adding a patch for OPAL_PRD MTD_POWERNV_FLASH
<arges> bug 1464560 fwiw
<ubot5> bug 1464560 in linux (Ubuntu) "Backport request: include PRD support for OpenPower kernels" [High,In progress] https://launchpad.net/bugs/1464560
<apw> what ENFORCED means is, when building the config for a build if that value does not match annotations fail the build
<apw> it doesn't make it set or anything
<apw> and doesn't make it set if the config is internally inconsistant
<arges> so i'm not seeing an error, it seems to complete just fine and then unset that CONFIG
<apw> so you set it =y by hand, and then fdr updateconfigs and it is now of ?
<apw> off?
<arges> apw: yea setting it manually and updateconfigs turn it back off
<apw> that is unrelated to the enfocer then, that is to do with the config not being compatible with it being on
<arges> apw: "powerpc/powernv: Remove powernv RTAS support" <-- this patch may be the reason : )
<apw> heh
<arges> apw: so if we have a patch that removes support should I update that file to not enforce that?
<arges> (hopefully i'm not breaking something in which that was enforvced in the first place)
<arges> apw: yea looks like it never worked in the first place. I'll just update the file and config.
#ubuntu-kernel 2015-07-17
<tammyt> linux idiot here, I have a server overseas that I can't seem to boot normally anymore. Ubuntu 14.04 LTS 64-bit. I was working on it last july 7th. went to check in on it yesturday and no relys to ICMP or SSH. I used the web portal to boot to a recovery kernel (other partition) and it looks like it died later that night I was working on it (july 8th). Last time stamps in /var/log are from that night,
<tammyt> even auth.log's last input was an hourly cron job. the directory /mnt/sda2/boot is empty... That's not normal... right?? Can anyone point me to a how to for re-creating the latest LTS kernel/grub/whatevers that need to be back in that directory?
<infinity> tammyt: Given that your root partition is sda2, are you sure you didn't have a boot partition at sda1?
<tammyt> making a pastebin
<tammyt> http://pastebin.com/mKBWTwVC
<tammyt> so if my boot partition is sda1, why would it suddenly stop working mid running? I litterally had this server spawned for me, logged in, made a new user, scoped out auth.log and saw all sorts of bots attempting connections, so I changed sshd to listen on a different port, took backup copies of some files (passwd, shadow, group), installed a few minor prgrams through apt-get (htop, tmux, iptraf, a few other small 
<tammyt> infinity: ^^
<tammyt> I'm just slowly getting angry over here, and it must be clouding my thinking
<tammyt> or I'm an idiot.
 * tammyt starts to turn green
<tammyt> I'm going to take a bath, if anyone is willing to commit some time to this charity case, that would be amazeballs.
<infinity> tammyt: Without a console log, "why it stopped working" may not be something you're going to get to the bottom of.
<infinity> tammyt: I was just responding to your "where did the contents of /boot go?" which, as you found, is on /dev/sda1 (and I assume it's mounted from /etc/fstab).
<tammyt> infinity: you are totaly right. fstab points to the uuid of sda1. would the next logical step be to troubleshoot grub?
<infinity> tammyt: Well, I don't even know what your issue is, so I don't know what you should troubleshoot.  You said it died.  You never said you tried to reboot it.
<infinity> tammyt: "It stopped working, so I booted to a recovery partition".
<tammyt> infinity: I did reboot (through the webadmin console (it's a button...)) but no response from the box in any fashion. when I set the boot mode to the recovery console, and then rebooted, that's when I was finally able to get in.
<tammyt> I rebooted a few times today even (normal boot) and there is still not a trace of anything logged in /var/liog
<infinity> tammyt: So, you have no console while it's trying to boot?
<tammyt> correct.
<infinity> tammyt: It might be fscking / and you're being impatient and rebooting in the middle of it. :P
<tammyt> it's a 1TB disk, and I let it go overnight...
<tammyt> my service provider doesn't support any sort of ILO or IPMI connections to old boxes like mine either....
<tammyt> mega bummer
<infinity> tammyt: That's going to make it rather difficult to know what's wrong. :/
<tammyt> Where do you think I should look next?
<thresh> hello, I think I've found an issue with the kernels shipped with Ubuntu 15.04 - I see data corruption under my qemu VM when doing http file transfers (hg clone).
<thresh> I've bisected the linus git to this commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e5a4b0bb803b39a36478451eae53a880d2663d5b
<thresh> Is there such a thing as a "minimal" ubuntu kernel configuration, suitable for running 15.04 stock install under KVM w/virtio?
<thresh> It would have been much faster for me to bisect it this way :)
<infinity> thresh: The "minimal" install is linux-virtual instead of linux-generic (doesn't install the massive -extra package with all the modules you don't need).
<infinity> thresh: But it's all from the same source, so that doesn't help bisection. :P
<infinity> thresh: Anyhow, can you please file a bug with "ubuntu-bug linux"?
#ubuntu-kernel 2016-07-18
<davmor2> hey guys since the last kernel update my headset jack on my device isn't registering the insertion of a new device is there any debugging I can do for that?
<Odd_Bloke> davmor2: I have, in the past, seen an issue on my Thinkpad T440p where having the jack plugged/unplugged _at boot_ affects whether plug detection works for the rest of that boot.  (Obviously this isn't particularly fine-grained debugging, but might be worth trying as a workaround. :)
<davmor2> Odd_Bloke: thanks dude I'll give that try
<apw> Odd_Bloke, that sounds "awsome" feature
<Odd_Bloke> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1508826
<ubot5> Launchpad bug 1508826 in alsa-driver (Ubuntu) "[20ANCTO1WW, Realtek ALC3232, Black Headphone Out, Left] No sound at all when headset plugged in" [Medium,Confirmed]
<Odd_Bloke> Looks like I still have the workaround in place, so who knows if it's actually been fixed. :p
<davmor2> Odd_Bloke: thanks for the hint that worked odd that it has only happened since the kernel upgrade on Friday though
<Odd_Bloke> davmor2: Are you on a T440p?
<davmor2> Odd_Bloke: nope xps13
<Odd_Bloke> davmor2: Are you sure that it only just started occurring?  (I didn't notice it for a while because I almost always power-cycled with either plugged/unplugged (whichever didn't cause the problem))
<davmor2> Odd_Bloke: sorry meeting, yeap only happened this morning and I'd rebooted with the headset in still no joy, rebooted with the headset disconnected and no it is working fine so no idea what was going on with it :)
<davmor2> works now is all I care about :)
<Odd_Bloke> :)
<davmor2> Odd_Bloke: miming at meetings just isn't as efficient no idea why ;)
<Odd_Bloke> ^_^
<gQuigs> how do I find out what's going to be in the next Ubuntu kernel, these days?
<gQuigs> http://kernel.ubuntu.com/sru/sru-report.html is blank, and the git web seems stale - http://kernel.ubuntu.com/git/
<gQuigs> I'm really just interested in the patches mentioned in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1568729  - but also want to know the right way to check in the future
<ubot5> Launchpad bug 1568729 in linux (Ubuntu Xenial) "divide error: 0000 [#1] SMP in task_numa_migrate - handle_mm_fault" [High,In progress]
<kamal> gQuigs, sru-report.html does appear to be broken (we'll look at that)
<kamal> gQuigs, the git repos at kernel.ubuntu.com aren't stale (but they are hard to navigate).  start here:  http://kernel.ubuntu.com/git/ubuntu/
<kamal> gQuigs, that said, kernel.ubuntu.com is now just a mirror of e.g. https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/ these days
<gQuigs> awesome, thanks
<gQuigs> the LP are much nicer to navigate (at least to me)
<gQuigs> does http://kernel.ubuntu.com/git/ server any purpose these days then?
<kamal> gQuigs, no, but we've only recently move the primary git repos over to LP, and we figure lots of things still reference the kernel.ubuntu.com URL's -- so we're not eager to kill it off too soon
<gQuigs> got it, that makes sense
#ubuntu-kernel 2016-07-19
<bhuey> hi
<bhuey> I'm trying to create a new kernel flavour and build nvidia drivers against it
<bhuey> I'm using the lowlatency flavour as an example. The packages build but the binary for dkms isn't wanting to load at runtime
<bhuey> I've enabled lock_stat and other instrumentation bits that I want for performance measurements
<bhuey> Was wondering if whether or not if I can do that or if the ABI has to be denoted as changed
#ubuntu-kernel 2016-07-20
<bhuey> hi
<bhuey> I had a question about package building and ABI
<bhuey> I'm enabling an option in a flavour I've created and trying to install a proprietary module
<bhuey> but building against it revsult in a runtime failure about the ABI being different
<apw> bhuey, the flavour being differnt should be enough, the combination of abi and flavour is the thing against which dkms builds
#ubuntu-kernel 2016-07-21
<bhuey> Is there a wiki on making a new flavour correctly ? I just copied the .generic file over and renamed it
<bhuey> Enabling a kernel option creates the problem with the module failing to load
<bhuey> I'm obviously missing something here but I don't know what it is
<mterry> Hello!  Who is involved with the Touch kernels?  I *think* it's missing ACL support and wanted to check in with someone about the config we use there
<apw> mterry, which kernels specificially ?
<mterry> apw, I guess I happen to be testing on the arale device.  So whatever kernel we ship there.  But I haven't done a survey of all our supported devices to test kernel configs.  Are the configs we use so device-specific?
<apw> mterry, yes, the kernels are mostly very different, and so there is a lot of manual work in that
<mterry> apw, OK.  Where could I go and look at the config we use to build one of these kernels with?
<apw> mterry, i'll find out and let you know
<xnox> why doesn't 9pnet_virtio module autoload upon trying to mount 9p virtio filesystem....?
<apw> xnox, dunno maete
<apw> maybe it cannot be detected
<xnox> it can be....
<apw> that combination of things is a bit wierd to put it mildly, a virtio filesystem
 * apw goes for supplies
<xnox> apw, oh, it's racy on boot
<xnox> somehow systemd tries to mount it before it's ready.... as post-boot i can restart .mount unit and it just works.
<Gnar> https://youtu.be/0yJn-5hpU94
<gQuigs> shouldn't regressions have a higher importance? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603719
<ubot5> Launchpad bug 1603719 in linux (Ubuntu) "[regression] NFS client: access problems after updating to kernel 4.4.0-31-generic" [Low,Confirmed]
<bhuey> hi
<apw> gQuigs, regressions are indeed of importance to us
<apw> gQuigs, that wasn't marked (correctly) as a regression, i've marked it up
<apw> jsalisbury, ^ that one needs to be on our list
<gQuigs> apw: thanks
 * bhuey reasks question
<bhuey> I created a flavor and I'm ahving problems loading the nvidia propreitary driver
 * gQuigs is bisecting now, but still on first kernel build (slow machine, via VPN)
<bhuey> Builds and installs ok but I don't know what how to get the module to load without complaining
<bhuey> Do I needd to do something in addition to just creating a new flavor file ?
<bhuey> and configuring the .config of those kernels ?
<bhuey> I did this to enable a kernel parameter for testing that isn't on in a normal Ubuntu kernel
<bhuey> but it seems to be causing ABI issues
<apw> bhuey, that sounds like a description of a debian kernel flavour
<apw> bhuey, but if it is building you are not throwing abi issues, that would prevent the build
<apw> bhuey, you would be better telling us what error you see when you try and insert the module
<bhuey> apw: yeah this is kind of baffling as I odn't much about kernel packaging
<bhuey> We're building it locally here and need the Nvidia drivers for CUDA development
<bhuey> Basically, we compile 4.4.8 for trusty
<bhuey> lowlatency kernel as well
<bhuey> the generic one works fine, same for lowlatency but I added a kernel option to enable lock stat and the nvidia module fails to load at runtime
<bhuey> compiles and installs with no complains
<bhuey> Have zero idea what's going on to push this forward
<bhuey> apw: thanks for any help btw
 * bhuey waits
<apw> bhuey, is there anything in dmesg at the point where you probe it in?
<jsalisbury> apw ack
<jsalisbury> gQuigs, are you going to be doing a bisect?  
<gQuigs> jsalisbury: in progress, but if anyone has a faster machine with this issue they might finish first
<gQuigs> still on the first kernel build
<jsalisbury> gQuigs, I have build servers that can build a kernel in 20 minutes or so.  If you send me the current bisect log, I can build the kernels for you and post a link to them in the bug?
<gQuigs> jsalisbury: sure thing - http://pastebin.ubuntu.com/20352223/
<gQuigs> it's just the first build so I assumed that rebuilding 4.4.0-28 and 4.4.0-31 wasn't needed
<jsalisbury> gQuigs, I'll build that kernel and post it in the bug. If you test it and post the results, I can then update the bisect and build the next one.
<gQuigs> jsalisbury: feel free to just ping me here, I'll be around
<gQuigs> thanks!
<jsalisbury> gQuigs, 
<jsalisbury> gQuigs, ack
<jsalisbury> gQuigs, Is the issue fixed in the upstream 4.4.15 kernel?  
<jsalisbury> gQuigs, if it is, it might be better for us to reverse bisect to find the commit that fixes things
<gQuigs> jsalisbury: yea  4.4.15 works fine, but keep in mind I haven't found an upstream kernel to have the issue to begin with
<gQuigs> err
<jsalisbury> gQuigs, ahh, ok.  Then it is probably due to a SAUCE commit.
<apw> gQuigs, have you tested the -proposed kernel, i _thought_ that had 4.4.15 applied
<jsalisbury> gQuigs, The xenail -proposed kernel alread has the 4.4.15 updates.  It might be worth a shot testing it while the bisect kernel builts.
<jsalisbury> heh, collision.
<gQuigs> will cancel my build and try that
<jsalisbury> gQuigs, great.  and my build is going
<gQuigs> 4.4.0-32-generic #51 in proposed has the issue as well
<jsalisbury> gQuigs, Ok, a bisect is the best route then.
<gQuigs> I'm guessing it's related to the series under - cgroupfs mounts can hang
<gQuigs> as the NFS failure says - [80914.821533] <-- nfs_xdev_mount() = -1Â 
<gQuigs> [80914.821535] nfs_do_submount: doneÂ 
<gQuigs> [80914.821536] <-- nfs_do_submount() = ffffffffffffffffÂ 
<gQuigs> [80914.821577] <-- nfs_d_automount(): error -1
<jsalisbury> gQuigs, First kernel is done building.  You can get it here:
<jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1603719/
<jsalisbury> gQuigs, apw There are only 6 SAUCE patches between 28.47 and 31.50: 
<jsalisbury> 9ef55b6 UBUNTU: SAUCE: drm: check for supported chipset before booting fbdev off the hw
<jsalisbury> 7b97729 UBUNTU: SAUCE: (noup) Update zfs to 0.6.5.6-0ubuntu10
<jsalisbury> 302cabb UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches
<jsalisbury> 765ab2f Revert "UBUNTU: SAUCE: cgroup: Use a new super block when mounting in a cgroup namespace"
<jsalisbury> 3988fb7 Revert "UBUNTU: SAUCE: kernfs: Do not match superblock in another user namespace when mounting"
<jsalisbury> f256722 Revert "UBUNTU: SAUCE: (namespace) mqueue: Super blocks must be owned by the user ns which owns the ipc ns"y
<jsalisbury> guess I should have pastbin'd that
<jsalisbury> http://paste.ubuntu.com/20356124/
<jsalisbury> gQuigs, apw three are reverts, so I'm going to assume they probably didn't cause the bug.  Could be: 
<jsalisbury> 302cabb UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches
<gQuigs> jsalisbury: that kernel has the issue; git bisect bad
<apw> jsalisbury, that is paired with the three reverts
<jsalisbury> apw, hmm
<apw> sforshee, ^
<jsalisbury> apw, maybe I should revert 302cabb and build a test kernel with those other three reverts reverted
<apw> jsalisbury, i'd say so
<jsalisbury> apw, sforshee crap, f256722 doesn't revert cleanly.
<apw> jsalisbury, which order are you reverting them, that the last one i assume
<jsalisbury> apw, yeah.  The last one reverted first.
<apw> jsalisbury, must be something on top needing revert first
<jsalisbury> apw, I'll see what other commits happened around it
<apw> prolly the other two namespace ones
<jsalisbury> apw, yeah, trying to find it now
<jsalisbury> apw, trying those two namespace ones
<jsalisbury> apw, there are 5 other namespace ones
<jsalisbury> apw: http://paste.ubuntu.com/20358102/
<jsalisbury> actually 6
<jsalisbury> apw, maybe I'll just revert the whole lot
<sforshee> jsalisbury, apw: "(namespace) vfs: Pass data, ns, and ns->userns to mount_ns" touches nfs, but I'm not seeing how it would cause that problem
<sforshee> I'd think if there was a problem it would happen at mount time
<gQuigs> sforshee: it is "mount" time, just submount time
<gQuigs> for example I can access /cfs/home,  but not not /cfs/share
<sforshee> gQuigs: but does that actually trigger a separate filesystem mount operation?
<gQuigs> see the NFS error I posted above (nfs_xdev_mount),  not sure what that translates to elsewhere
<gQuigs> but according to NFS, yes...
<jsalisbury> sforshee, gQuigs I'll build a quick test kernel with a5abdcb for a test
<jsalisbury> with a5abdcb reverted
<gQuigs> ah, that makes more sense :)
<jsalisbury> gQuigs, heh, I typed it then looked at another monitor :-)
<jsalisbury> gQuigs, should be ready in about 10 minutes
<gQuigs> awesome, thanks!
<sforshee> it does do some mount stuff, but I'm still not seeing how that's going to end up through the call path which now has a capability check on the net ns
<sforshee> I wonder if it has more to do with moving where sb->s_fs_info gets set
<bhuey> apw: not that I can tell. The Xorg logs shows that it's unable to load the device. I'll have to reboot back into that kernel if I want to find it in the logs
<bhuey> apw: should I do that ?
<jsalisbury> gQuigs, test kernel is ready.  Same location:
<jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1603719/
<sforshee> oh, I think it's sget
<sforshee> yeah, it almost certainly is. The internal mount doesn't use MS_KERNMOUNT, and now sget has a capability check if that isn't used
<gQuigs> sforshee: jsalisbury the reverted kernel still fails
<sforshee> gQuigs: that's what I'd expect if my suspicions are correct
<sforshee> I'm going to try to reproduce locally, shouldn't be difficult, then I can test my theory
<jsalisbury> gQuigs, sforshee ack
<gQuigs> going away for a bit, will test anything else when I get back later tonight
<gQuigs> thanks!
#ubuntu-kernel 2016-07-22
<sforshee> gQuigs: I just posted a test kernel to the bug that should fix the nfs problem
<gQuigs> sforshee: thanks! will test
<gQuigs> sforshee: that works, thanks!
 * gQuigs has trouble posting it to LP though... 
<sforshee> gQuigs: exellent
<sforshee> gQuigs: would you mind adding a comment to the bug stating that the kernel fixed the issue for you?
<gQuigs> sforshee: worked this time.  LP was timing out before
<sforshee> gQuigs: yeah I've been having that problem all week :-(
<apw> sforshee, is that only affecting xenial ?
<sforshee> apw: yes
<sforshee> I'll be sending the patch momentarily
<apw> sforshee, and how serious is it, what nfs features are affected
<sforshee> apw: it affects the situation where the client side tries to automatically mount an exported submount of another exported fs
<sforshee> if that makes sense, it's kind of hard to explain
<apw> yeah it makes snese, i have no feel for how common that is :/
<sforshee> apw: me neither. It does require a special option in the exports file
<gQuigs> my test box connects to an IBM AIX NFS server, not sure if that''s more common there (nor do I have an idea of how common that is)
<sforshee> apw: patch sent
#ubuntu-kernel 2016-07-23
<ogra_> uh, oh ... our kernel package points to /usr/share/common-licenses/GPL ... (which is a link to GPL-3 nowadays)
<ogra_> apw, ^^^
<ogra_> i guess debian/copyright could need some love across the board
<apw> ogra_, ack
<faginbagin> How to maintain a patched kernel?
<faginbagin> I just went thru the process of bisecting kernels, reporting a regression on launchpad and then reporting the regression to kernel.org.
<faginbagin> After a few days working with the developer, he was able to make a change that fixed the regression (from v4.2.8 btw).
<faginbagin> Now I would like to maintain a xenial (4.4.x) kernel with that patch. Is there a recommended process? Something like the way dkms is used to update nvidia modules when there's a kernel update?
<faginbagin> FWIW, here's the launchpad bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603230
<ubot5> Launchpad bug 1603230 in linux (Ubuntu) "acpi regression first bad commit 02b771b64b73226052d6e731a0987db3b47281e9" [Medium,Triaged]
<faginbagin> And here's the upstream bug report: https://bugzilla.kernel.org/show_bug.cgi?id=135691
<ubot5> bugzilla.kernel.org bug 135691 in EC "EC parallelism: parallel _Qxx evaluation problems" [Normal,Resolved: code_fix]
#ubuntu-kernel 2016-07-24
<mysticTot> Is it possible to prevent fork bomb by using kernel configuration option CONFIG_CGROUP_PIDS=y i.e,  PIDs controller
<mysticTot> ??
<stgraber> yes, you can limit the effect of a fork bomb with the pids cgroup
<mysticTot> thanks
<mysticTot> stgraber
<mysticTot> I'm hoping fork bomb would not hang my system now
#ubuntu-kernel 2017-07-17
<apw> spoonless[m]1, didn't we discuss that one to death ...
#ubuntu-kernel 2017-07-18
<PaulePanter> Hi. How do I get the latest Intel Microcode updates for Kaby Lake systems (Dell XPS 13 9360) on Ubuntu 16.04.2?
<PaulePanter> https://packages.ubuntu.com/search?keywords=intel-microcode
<PaulePanter> Only 3.20151106.1 is available.
<ogra_> PaulePanter, Bug #1700373
<ubot5> bug 1700373 in intel-microcode (Ubuntu Zesty) "intel-microcode is out of date, version 20170707 fixes errata on 6th and 7th generation platforms" [Undecided,Confirmed] https://launchpad.net/bugs/1700373
<PaulePanter> ogra_: Thank you.
<magicline> @tomreyn seems to work quite well
<magicline> software IO TLB [mem 0xc7f80000-0xcff80000] (128MB)
<JPelletier> Hi, I'm currently trying to build latest zesty Kernel to enable CONFIG_USB_SERIAL_CONSOLE but I can't find int in the Kernel Configuration
<JPelletier> Damn I was searching with a typo... found it
<JPelletier> When searching for: CONFIG_USB_SERIAL_CONSOLE I find "Prompt: USB Serial Console device support"  but it's not in the list ounder "USB Serial Converter support" what I'm missing?
<JPelletier> Anyone can help me enabling CONFIG_USB_SERIAL_CONSOLE ?
<LocutusOfBorg> apw, in artful-proposed you have the new vbox shiny kernel modules!
<apw> LocutusOfBorg, thanks ... sforshee ^ we need to resync those
<LocutusOfBorg> <3
<sforshee> LocutusOfBorg: yes thank you. I guess this one has fixes for 4.12?
<LocutusOfBorg> and 4.13
<apw> sweet
<LocutusOfBorg> Linux hosts / guests: Linux 4.12 fixes (bugs #16725, #16800)  Linux hosts / guests: Linux 4.13 fix (bug #16887) 
<ubot5> bug 16800 in linux-source-2.6.15 (Ubuntu) "please add reiser4" [Medium,Fix released] https://launchpad.net/bugs/16800
<ubot5> bug 16725 in linux-source-2.6.15 (Ubuntu) "snd-usb-audio causes system instability on boot, manual modprobe works fine" [Medium,Fix released] https://launchpad.net/bugs/16725
<ubot5> bug 16887 in xserver-xorg-video-intel (Ubuntu) "won't do lower modes on default laptop sync ranges [i855]" [Medium,Invalid] https://launchpad.net/bugs/16887
<LocutusOfBorg> not sure how much 4.13 will change the api, but meh
<LocutusOfBorg> it should be good until RC1
<sforshee> LocutusOfBorg: yeah, working on the rebase to 4.13-rc1 as we speak. Fyi, we will be trying to get 4.13 into artful quicker than 4.12, at the late -rc stage.
<LocutusOfBorg> nice!
<LocutusOfBorg> there is a big ongoing porting of such modules in the mainline kernel
<LocutusOfBorg> so, hopefully they will go upstream one day
<sforshee> that would be great
<chiluk> apw is the k-team meeting cancelled today?
<chiluk> can you make sure the http://fridge.ubuntu.com/calendars  is correct?
<apw> chiluk, we haven't had a meeting for a year i don't think
<apw> chiluk, noone ever attended other than us ...
<chiluk> hmm I was wondering about that.. 
<chiluk> apw.. well I'm interested in attending now..
<chiluk> apw which you may or may not care about.
<chiluk> apw either way the fridge calendar should get updated.
<apw> chiluk, well don't stand on ceremony, just come here and discuss whatever you care to, whenever
<apw> chiluk, yep, passing that baton to someone to resolve
<chiluk> yep thanks apw.. any thoughts on the intel-microcode upload?  Has the sru team earmarked anyone in particular to review it?  I'm expecting it will be rbasak.
<apw> chiluk, i have not heard anyone specific being in the frame no, it is a risky update and causes the fear in most of us
<chiluk> apw yeah.. I figured as much... apw if it makes you feel any better it appears as if most of the firmware stays constant for arches other than skylake and kabylake.
<chiluk> unless of course intel just decided not to bump the revision.
<rbasak> chiluk: I expect it'll be me. My SRU day is tomorrow.
<apw> chiluk, yeah one would hope
<chiluk> rbasak apw, the other thing I was curious about was if we would / should backport the skylake /kabylake graphics firmware blobs into linux-firmware... thoughts?
<chiluk> rbasak apw ... specifically https://01.org/linuxgraphics/downloads/firmware 
<chiluk> the two I think we should consider are the DMC and HUC as both should have power savings.
<apw> sforshee, ^
<chiluk> I wish I had a contact inside intel to confirm or get comment from about this.
<chiluk> the page is really not technically verbose so it's hard to tell what they're really doing.
<chiluk> alright off to food with me.
<sforshee> chiluk: backport to which release? Artful at least looks to be up to date
<rbasak> chiluk: I'm not sure. What would we gain from doing that?
<flocculant> jsalisbury: hi - on bug 1704470 you've asked me to test against v4.12 and pointed me to http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13-rc1/ - is 4.13-rc1 what you want me to test against?
<ubot5> bug 1704470 in linux (Ubuntu) "playback fails using alsa in mpd" [Medium,Incomplete] https://launchpad.net/bugs/1704470
<patrik> Hi guys, how do I best (easiest, quickest) go about building the 4.13-rc1 kernel + custom patch?
<jsalisbury> flocculant, yes it is.  Sorry 4.13-rc1 just came out and I didn't update my email template form 4.12 properly.  I'll fix that.
<patrik> I've tried the https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel guide but can't find a way to get 4.13-rc1 sources with that approach.
<jsalisbury> thanks for the heads up
<flocculant> jsalisbury: ok - cool, will grab and test that now (ish
<patrik> Can I just clone the vanilla source and copy the "debian" dir in there? I'm assuming it's not that easy.. :)
<jsalisbury> patrik, you could use the artful master-next branch, but it's not at 4.13 as of yet, still 4.12 based.
<patrik> jsalisbury, yeah I noticed that, thanks. Although I do need 4.13-rc1 since this patch is based off it and specific ACPI/PM changes. I've been asked by the dev to try it out on my hardware.
<patrik> https://bugzilla.kernel.org/show_bug.cgi?id=192591#c101
<ubot5> bugzilla.kernel.org bug 192591 in Hibernation/Suspend "Suspend to idle & ram issues on Dell XPS 13 9365" [Normal,Needinfo]
<jsalisbury> patrik, in the kteam-tools repository, there is a script called mainline-build-one.  It can be used to build the latest mainline kernel and it "Debianizes" it.
<jsalisbury> patrik, kteam-toosl is in this git repo:
<jsalisbury> git://git.launchpad.net/~canonical-kernel/+git/kteam-tools
<patrik> Oh cool, thanks a lot! So I just download the 4.13-rc1 tarball, that script, and run it and I'll end up with a nice .deb? :)
<jsalisbury> patrik, the script is in ~kteam-tools/mainline-build
<jsalisbury> patrik, if you need help building a kernel, you can open a Launchpad bug and I can try building it for you.
<patrik> That would be amazing, are we talking in upcoming minutes or days? :)
<jsalisbury> patrik, I could build it today.  Just open a bug and post the patch you need built into 4.13-rc1 and I'll build it, package it into a deb and post it for you.
<patrik> Oh great, on it!
<jsalisbury> patrik, just post the bug number here, in case I don't get to the new bug email timely
<patrik> https://bugs.launchpad.net/ubuntu/+source/linux/+filebug ?
<jsalisbury> patrik, you could use the web interface, or from a terminal run "ubuntu-bug linux"
<flocculant> jsalisbury: ok - updated that bug now, not convinced it's the kernel tbh (but I'm just a van driver ...) 
<patrik> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1705099
<ubot5> Ubuntu bug 1705099 in linux (Ubuntu) "Kernel 4.13-rc1 with custom patch for troubleshooting" [Undecided,New]
<jsalisbury> patrik, thanks, I'll build the kernel and post it in a bit.
<jsalisbury> flocculant, thanks for testing.  I'll review the bug.
<flocculant> jsalisbury: ok - thanks - I did mark a similar alsa bug as a dupe (reported it there when apport wouldn't let me report kernel, was using kernel from proposed)
<jsalisbury> flocculant, ok, thanks
<flocculant> didn't touch tags btw as now I'm not sure what the bug is in
<jsalisbury> patrik, There is a test kernel available at: http://kernel.ubuntu.com/~jsalisbury/lp1705099/
<patrik> jsalisbury, thanks I'll have a look
<patrik> switching to this machine so I can reboot :)
<patrik> jsalisbury, thanks a lot! kernel worked great and it even proved the feature!
<jsalisbury> patrik, great news
#ubuntu-kernel 2017-07-19
<magicline> the problem ist back after 2 days of runtime :( https://pastebin.com/3ebc0H95
<magicline> https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1705221
<ubot5> Ubuntu bug 1705221 in linux-hwe (Ubuntu) "ata_piix swiotlb buffer is full " [Undecided,New]
<seb128> hey there
<seb128> could someody tell me what's the status of the bug which is making java/libreoffice segfault on x86?
<apw> seb128, if that is related to the stackclash fixes then we may well have applied the changes for that in the kernels in -proposed for xenial at least
<seb128> apw, any idea when the buildds are likely to run that kernel? ;-)
<apw> seb128, hehe, not that i don't think i have any control over
<apw> seb128, or indeed know if they are running xenial now i think about it
<seb128> I don't either
<seb128> I just know that libreoffice is stucked in artful-proposed due to that issue 
<seb128> and holding others transitions
<apw> because its test suite won't pass ?
<apw> if so then we should just give it a pass as the one in -release won't pass either
<smb> I think its a build time test. The fixup patches for that are part of this cycle for all but xenial where we added them to the re-spin
<apw> yep
<smb> So if builders were running xenial they would be good sooner
<seb128> apw, as smb said the test are part of the package build and failing the build
<smb> Unfortunately those patches did only appeared upstream only  over the weekend, so there is not really much chance to speed this up
<apw> seb128, ok it seems we follow -updates within 24 hours in general, so we should get that "soon@
<apw> seb128, we are just waiting on some test results for the carried fixies i assume
<seb128> apw, great, thanks for checking/letting me know
<apw> seb128, np
<leitao> when compiling a new kernel on 16.04 I got the following error "needs unknown symbol .TOC. ". I remember there was an workaround for it, but I can't remember what was it. Any idea?
<leitao> apw, sforshee: Do you remember about this issue?
<sforshee> leitao: we have this patch for it - http://paste.ubuntu.com/25127546/
<apw> leitao, look for a revert revert revert patchon the hwe branch
<leitao> sforshee: apw: Is it at Zesty tree?
<sforshee> not on zesty, but on the hwe tree which is based on zesty yes
<leitao> sforshee: interesting. the hwe branch is based on zesty remote?
<sforshee> leitao: it's zesty + some extra patches, those patches get rebased on top of each new zesty release
<leitao> sforshee: right. how do I get it?
<leitao> I was using zesty-next at this moment, which seems clearly wrong.
<sforshee> leitao: it's in the xenial tree, the hwe branch
<leitao> ah ok, Thanks
<sforshee> there is no -next branch
<sforshee> leitao: and actually I gave you on old patch, the tree was out of date. This is the current one - http://paste.ubuntu.com/25127582/
<sforshee> you'll find it pretty close to the tip of the hwe branch
<leitao> excellent. Thank you!
<sforshee> np
#ubuntu-kernel 2017-07-20
<JPelletier> Hi, someone can help me investigate a boot hang issue?
<JPelletier> Trying to get more logs, don't know if it's possible / how
<apw> JPelletier, boot logs from what kind of setup, and how is it hanging
<apw> JPelletier, you might find you have more logs than you think if you sysrq and request a sync
<apw> JPelletier, and booting without splash and with debug sometimes gets you more information
<JPelletier> apw: I tried to boot with earlyprintk=efi and my system freeze right after [ 0.00000] bootconsole [earlyefi0] disabled
<JPelletier> apw: System freeze randomly on reboot, like once every 20-30 reboot when I'm using 2GB memory and once every 100 reboots or more when using 4GB memory
<apw> well that is where the bootconsole hands off to the kernle console and there is a period where no messages come out, they are buffered
<apw> frankly that is going to be a pig to figure out, if it happens so early you get no diagnostics
<apw> and is that uncommon
<JPelletier> Ok and is there a way to know why it's freezed? I have nothing in journalctl when the freeze occur
<JPelletier> Since changing my memory have an impact, any idea on what could be the cause? Ran memtest on both without issue
<apw> JPelletier, pretty much not from what you have, if you know of a kernle which does not have this issue for instance it might be findable via a bisect
<apw> or you might get somewhere adding debugging _if_ you can get some output out, but that is tricky if it is happening that early
<apw> or if you have one of those debug boards which give you hints as to status
<JPelletier> I tried with server 16.04.2 16.10 and 17.04, also tried Kernel 4.12.2 in 17.04 - Same issue
<JPelletier> No debug boards, don't know what this is?
<apw> int 80 board have digits on the you can set in boot, not that then
<JPelletier> I can recompile the kernel, it's easy, if it can help
<JPelletier> I tried to boot with earlyprintk=efi,keep but it really slow, like every line take 3-4 seconds to print
<JPelletier> BTW, it's on an Intel NUC6CAY
<apw> does that nuc have the remote serial interface thing built in? 
<apw> you might have more luck sending the console there if so
<JPelletier> Humm not sure what you talking about, is this Serial-over-LAN ?
<apw> yes that
<JPelletier> I'm trying to find, not sure since it's an entry model
<JPelletier> No  it's not supported, it's a feature of vPro and I don't have vPro
<banshi> hello all
<banshi> take a look please: http://paste.ubuntu.com/25134780/   How do I compile linux-headers* after that error?
<apw> that looks like a debian kernel package form perhaps ? 
<banshi> man, I'm real dummy in kernel/deb building
<banshi> just tried to do like https://www.cyberciti.biz/faq/debian-ubuntu-building-installing-a-custom-linux-kernel/
<banshi> apw, I'm building it on debian, yes
<magicline> cannot stat âREPORTING-BUGSâ the file is missing 
<magicline> https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
#ubuntu-kernel 2017-07-21
<magicline> https://usn.ubuntu.com/usn/usn-3361-1/
<magicline> nice 
#ubuntu-kernel 2017-07-22
<magicline> since the kernel update to 4.10 xorg randomly freezes and crashes on two machines
<magicline> https://pastebin.com/4Be6DHN7
<magicline> switching to the nvidia driver fixes that issue 
#ubuntu-kernel 2018-07-16
<apw> fragile, that i believe implies you are trying to clean that source on a newer series, ie the kernel source is not 18.04 kernel source
<apw> fragile, if you look at the later kernel sources they supply KW_DEFCONFIG_DIR=$(DEBIAN)/d-i
<SystemParadox> I'm having issues building a 3rd party module on 18.04. I believe there may be an issue with the linux-kernel-headers package or whatever is responsible for installing the build scripts in /lib/modules/[version]/build/
<SystemParadox> The module includes linux/module.h, which includes linux/list.h which includes linux/kernel.h which includes linux/linkage.h which tries to include asm/linkage.h but fails with "No such file or directory"
<SystemParadox> I can't find any clear information on how the asm directory is supposed to work. Is there supposed to be a symlink somewhere? Or should the build scripts in /lib/modules be adding it to the include path?
<SystemParadox> Hmm. gcc appears to be adding -I./arch/x86/include, and arch/x86/include/asm/linkage.h exists. So why does gcc say 'no such file or directory'?
<apw> SystemParadox, well those are used routinly for that to build the dkms packages we ship, so i would expect it to work
<apw> SystemParadox, are you sure you have installed the entire headers package for your kernel, there are two for a specific version/flavour
<SystemParadox> apw, I have linux-headers-4.15.0-23-generic and linux-headers-4.15.0-23, although I thought the latter was just a metapackage
<SystemParadox> oh now I'm really confused. I ran the failing gcc call with -v and it says: ignoring nonexistent directory "-I./arch/x86/include"
<SystemParadox> but it does exist!
<apw> you might try installing a dkms package at random, and if that builds you know the headers are complete
<SystemParadox> care to suggest one?
<SystemParadox> the file it's complaining about is there. I really don't understand why gcc is ignoring that folder
<apw> brcmwl is quite benign
<SystemParadox> that seemed to work fine
<apw> so that would imply that the manner in which you are envoking your local build is wrong in some way
<SystemParadox> I ran it with KBUILD_VERBOSE=1 to find out what commands it was actually running
<SystemParadox> it changes directory to /usr/src/linux-headers-4.15.0-23-generic and runs a gcc which includes -I./arch/x86/include
<SystemParadox> if I change to that directory and run the exact same gcc command, I get the same result
<SystemParadox> if I add '-v', it tells me it ignores './arch/x86/include' because it doesn't exist... except that it does!
<SystemParadox> apw, ok with some help from the gcc guys we realised there's a problem with the arguments
<SystemParadox> it's running "gcc -isystem   -I./arch/x86/include"
<SystemParadox> apparently -isystem takes an argument, which looks like it should be /usr/lib/gcc/x86_64-linux-gnu/7/include
<SystemParadox> at the moment it's trying to use "-I./arch/x86/include" as the argument (including the -I part!)
<SystemParadox> but I'm totally lost in the kernel build files. I can't find where those arguments are generated or where gcc is run
<SystemParadox> ok the issue arises at /usr/src/linux-headers-4.15.0-23/Makefile, which does NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC) -print-file-name=include)
<SystemParadox> CC appears to just be 'gcc'
<SystemParadox> gcc -print-file-name=include gives /usr/lib/gcc/x86_64-linux-gnu/7/include
<SystemParadox> but I guess it's not when this is running the first time? I don't know where to go with this now
<apw> SystemParadox, well there is clearly two spaces in the command line, so it is subbing in '' as that path which is not working
<SystemParadox> indeed
<apw> SystemParadox, from what i can it should be something like this:
<apw> Makefile:NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC) -print-file-name=include)
<SystemParadox> that's what I've got
<SystemParadox> shell-cached is some voodoo
<SystemParadox> I'm currently trying to work out if somehow the arguments passed from the module's own makefile are messing it up, although everything in the kernel build scripts seems to suggest it tries to reset everything to prevent this
<SystemParadox> oo this is odd - if I use make -C /lib/modules/4.15.0-23-generic/build it fails, but this is just a symlink to /usr/src/linux-headers-4.15.0-23-generic. If I use that directly, it works
<SystemParadox> aha! deleting .cache.mk has fixed it!
<SystemParadox> wish I'd taken a copy of it now to see what was wrong with it
#ubuntu-kernel 2018-07-17
<sforshee> LocutusOfBorg: the virtualbox dkms modules fail to build with the cosmic-proposed kernel, I've pointed to a fix on bug 1776671
<ubot5> bug 1776671 in virtualbox (Ubuntu) "virtualbox 5.2.12-dfsg-2 ADT test failure with linux 4.17.0-2.3" [Undecided,New] https://launchpad.net/bugs/1776671
<LocutusOfBorg> sforshee, did you look at virtualbox/proposed? :)
<sforshee> LocutusOfBorg: no I guess not
<sforshee> need to get some test results for that with 4.17
<LocutusOfBorg> thanks sforshee!
#ubuntu-kernel 2018-07-20
<uebera||> Is this the right place to ask whether/when the Canonical Livepatch Service will cover the Ubuntu 18.04 LTS (GA) kernels? https://www.ubuntu.com/server/livepatch (and the datasheet you can download) does not contain any details. (Which is a bit of a pity.)
#ubuntu-kernel 2018-07-21
<apw> uebera||: my understanding is it does but i will get that confirmed and the data sheet clarified if necessary
<uebera||> apw: Thanks! Could you also please clarify whether it is feasible for 16.04.x users to install a 18.04 GA kernel and enjoy both the benefits of a newer kernel and Livepatch? (This would allow us -- and IMHO a larger user group -- to have the same setup on both older/newer desktops/servers.)
#ubuntu-kernel 2018-07-22
<hendryx> hello?
<venturhano> question about my first bug report: should a bug with my touchpad be associated with the kernel?
<apw> venturhano: all depends on the symptoms, but it as good a place as any
<venturhano> ok thanks
#ubuntu-kernel 2019-07-15
<ronj> Hi! Quick notice that amd64/i386 mainline kernel builds are broken, see for example https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2.1/ . Thanks for the mainline builds, hope they're fixed soon :)
<Eickmeyer> Any opinions on bug 1787857?
<ubot5> bug 1787857 in linux (Ubuntu) "USB mouse cursor lags after random time of correct behaviour" [Undecided,Confirmed] https://launchpad.net/bugs/1787857
<TJ-> Eickmeyer: is the rtl_pci module sharing the same interupt as the USB controller? if so, when "Disabling IRQ #18" hits you'd expect some issues :) 
<Eickmeyer> TJ-: I don't know, this isn't my bug, and I don't experience the problems being described. It showed up as a bug filed directly against Ubuntu Studio nearly a year ago, and even after I moved it to the right package, it's received no attention.
<Eickmeyer> TJ-: That said, I have reason to believe it is definitely a hardware-specific issue.
<TJ-> Eickmeyer: in the case of user lassi, IRQ 21 is shared between USb OHCI and the GPU (nvkm)
<Eickmeyer> TJ-: So, this person has some hardware IRQ conflicts?
<TJ-> Eickmeyer: not sure; it could be an edge-case bug in the preempt code. Looking at the info in the bug logs the only thing that occurs to me is the CPU affinity of the IRQ handler... in the lassi case (where there a lot of logs) if I recall correctly /proc/interrupts shows IRQ 21 handled on CPU 2 only. If somehow an IRQ 21 is dispatched to another core... "no one cares" "unhandled interrupt"
<Eickmeyer> TJ-: Ok, not sure how to get this one out of my hair. Seems like it needs to be moved upstream to the Linux kernel if that's the case.
<richi235> Hi, If I would now open a SRU for this commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=503d90b30602a3295978e46d844ccc8167400fe6 , what are the changes it would be included in the linux-generic-18.04-hwe kernel released with 18.04.3 on August, 1st ? 
<connor_k> richi235: the last day for commits for the august 12th release is July 17, so the patch would need to be sent by this wednesday with SRU justification for it to be included in that release (source: https://kernel.ubuntu.com/)
<richi235> hmm, even that would not solve our problem because, if i get you correctly from august first to august 12th, all users using    linux-generic-18.04-hwe would nevertheless get 5.0.0-21.22~18.04.1 
<richi235> so 12 days with broken audio^^
<richi235> I guess we will ship a dkms with the module than
<richi235> but thanks for the info
<jackpot51> Hello, has anyone else experienced suspend/resume regressions on NVIDIA RTX 2000 series laptops with the 5.0.0-21 kernel?
<jackpot51> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836630
<ubot5> Ubuntu bug 1836630 in linux (Ubuntu) "System76 Oryx Pro (oryp5) with 5.0.0-21: Fail to resume from suspend" [Undecided,New]
#ubuntu-kernel 2019-07-17
<sub526> While building ubuntu-xenial kernel it failed for me with "debian/rules.d/4-checks.mk: recipe for target 'module-check-generic' failed", how to solve this error?
<sub526> Again just retried building the kernel by executing "fakeroot debian/rules binary-headers binary-generic binary-perarch" but this time got different error "mv: cannot move '/home/sa/ubuntu-xenial/debian/linux-modules-4.4.0-154-generic/lib/modules/4.4.0-154-generic/kernel' to '/home/sa/ubuntu-xenial/debian/linux-modules-extra-4.4.0-154-generic/lib/m
<sub526> odules/4.4.0-154-generic/kernel/kernel': Directory not empty
<sub526> debian/rules.d/2-binary-arch.mk:123: recipe for target 'install-generic' failed
<sub526> Any help is appreciated.
<jibel> hi, I just reported https://forum.snapcraft.io/t/cannot-launch-snaps-on-eoan-and-kernel-5-2/12341 which is apparently caused by kernel 5.2. Could someone help to bisect this?
<mvo> jibel: thanks for digging into the 5.2 squashfs mount issue! I wonder if its just snaps or any squashfs (or loop mount) that is broken? you could create a squashfs file with mksquashfs and try to mount it to double check (if you are on this already anyway, if not I can install 5.2 and see what happens)
<jibel> mvo, mounting a squashfs works fine. I tried with the squashfs of an iso
<jibel> mvo, I added a comment to the report. I seems that it tried to mount loop devices on already mounted loop devices
<jibel> in my case it attempts to mount vscode on loop21 but freemind is already mounted on it.
<jibel> so some snap squashfses are successfully mounted
<Chipaca> jibel: mvo: I suspect it's the attempt at doing all the mounts together at boot that trips it up
<ogra> are you sure it is kernel and not systemd's way to do the mounts ?
<Chipaca> ogra: rebooting into 5.0 makes the issue go away
<ogra> yeah, sure ... not saying it isnt triggered by the kernel ... 
<Chipaca> jibel: i.e. to repro without snapd, you'll need to do a lot of parallel mounts :-)
<ogra> but if manual mounting gives you properly numbered loop devices it smells more like systemd is messing it up
<Chipaca> a lot == 10? maybe more
<Chipaca> ogra: when doing a single mount there is no race between assigning a loop device and using it for the mount
<ogra> (using mount /dev/loop$(rand()) ;) ... )
<Chipaca> I'll stop for lunch, and then look at repro'ing this without snaps, in a vm
<Chipaca> jibel: is there a live image with 5.2 already?
<mvo> Chipaca, jibel aha, yes - a race a boot - that makes sense
<Chipaca> answering my question, yesterday's pending is 5.2, good enough for me
<Chipaca> (downloaded it because of a different issue :)
<jibel> Chipaca, http://cdimage.ubuntu.com/daily-live/pending/
<Chipaca> jibel: poncho!
<Chipaca> wait how does that work on the internet
 * Chipaca gives up and goes for lunch
<Laney> it'd be good to add an autopkgtest which would have caught this
<Laney> new kernels do trigger snapd's tests
<Laney> Chipaca: mvo: 
<Laney> dunno if you want to put that on your backlog or something
<Chipaca> Laney: tbh if this is a race, autopkgtest might be the worst place to hope to catch it
<Laney> worst?
<Chipaca> Laney: autopkgtest seems to run on a powerpc nubus mac emulating a 386sx running dosbox for the amd64 build, or something :-)
<Chipaca> i mean it's quite slow
<Chipaca> so timing issues there are different
<Laney> sounds like a good place to make race conditions happen to me
<Laney> it's the place where new kernels automatically trigger tests of your stuff
<Laney> and you get to block kernels from getting into the hands of users
<Chipaca> Laney: can autopkgtest be rebooted from a test?
<Laney> yes
<Chipaca> that is, can a test say "and now reboot plz"
<Chipaca> and then it carries on?
<Laney> you set a "marker" and then when it carries on you can check that variable
<Laney> https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst <- "Reboot during a test"
<Chipaca> this might be doable then
<Chipaca> need to figure out how to repro it first :)
<Laney> nod
<Chipaca> so, i need to have at least 42 snaps to reproduce the issue
<Chipaca> and then i get a broken mount where the assignment of the loopback device went bad
<Chipaca> jibel: #1836914
<Chipaca> mvo: ^
<jibel> bug 1836914
<ubot5> bug 1836914 in linux (Ubuntu) "Doing multiple squashfs ((and other loop?) mounts in parallel breaks" [Undecided,New] https://launchpad.net/bugs/1836914
<jibel> Chipaca, thank you
<Chipaca> made a note about it affecting 5.2 arch also
<Chipaca> now to figure out which upstream kernel to try :-)
<mvo> Chipaca: thank you!
<Chipaca> huh, the amd64 builds are failing
<LocutusOfBorg> hello guys... http://autopkgtest.ubuntu.com/packages/d/ddcci-driver-linux/eoan/s390x this is failing only on s390x, and of course it looks like because of the new kernel
<LocutusOfBorg> unfortunately this is an error that happens only on that architecture... how can I dump the make.log file without having an s390x machine=
<LocutusOfBorg> ?
<LocutusOfBorg> (it is regressed in release FWIW)
<LocutusOfBorg> we should really dump the log when dkms fails
#ubuntu-kernel 2019-07-18
<LocutusOfBorg> hello, wrt ddcci-driver-linux, I found the clue
<LocutusOfBorg> Makefile:228: 'SUBDIRS' will be removed after Linux 5.3
<LocutusOfBorg> Makefile:229: Please use 'M=' or 'KBUILD_EXTMOD' instead
<LocutusOfBorg> Makefile:230: ==========================================
<LocutusOfBorg> ERROR: "devm_backlight_device_register" [/var/lib/dkms/ddcci/0.3.2/build/ddcci-backlight/ddcci-backlight.ko] undefined!
<LocutusOfBorg> according to kernel build log backlight modules are not built in new kernel...
<LocutusOfBorg> sforshee, ^^
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837073
<ubot5> Ubuntu bug 1837073 in linux (Ubuntu) "linux 5.2.0-8.9 disabled backlight on s390x." [High,Confirmed]
<LocutusOfBorg>      - [Config] CONFIG_BACKLIGHT_CLASS_DEVICE=n on s390x
<LocutusOfBorg> this breaks dkms on s390x for that package... re-enable or hint the testsuite?
<sforshee> LocutusOfBorg: it's never actually worked for s390, the difference is that kbuild has changed to make the missing symbols an error instead of a warning
<sforshee> so likely this and other packages should be updated to skip the build when installed on s390
<sforshee> there are some others which depend on acpi which fail similarly
<LocutusOfBorg> sforshee, I assigned the bug to you... can you please make the package migrate then? :)
<LocutusOfBorg> at least if we hint, we can give the hint a comment with a bug number
<sforshee> ack, I cannot personally make it migrate but I will follow up on it
<LocutusOfBorg> apw might be the best person to hint...
<LocutusOfBorg> asked on release channel
<LocutusOfBorg> lets see
#ubuntu-kernel 2019-07-19
<qeole> Hello, I tried to send a patch set to the mailing list (<kernel-team@lists.ubuntu.com>) with git send-email, about one hour ago, and it does not show in the ML archives or in Patchwork (later emails do). Would anyone know if there is a way to check if (and why) the emails have been rejected by the server, please?
<qeole> (Do you have to be subscribed to the ML to be able to post? I hadn't subscribed with the address I used to post the patches)
<connor_k> qeole, I haven't tried sending an email to that list while unsubscribed. I once sent a patch to a mailing list I didn't subscribe to and I got an email back from the mail server saying that the email was being held until a moderator could check it because I wasn't a member of the list.
<connor_k> I wonder if something similar happens for this list
<qeole> connor_k: Thanks. Didn't receive any bounce, but ok. I subscribed with the email I use to post, I'll probably give it another try.
<tomreyn> since 5.2 (and 5.1.17+) kernel-ppa builds are broken for amd64 since over a week now (no blaming intended!), is there some place where work on making them build properly can be followed?
#ubuntu-kernel 2019-07-20
<JanC> technically it wouldn't be a âbounceâ, and some MLs don't send such held-for-moderation mails
<jeremy31> JanC: Some of the @lists.ubuntu.com do send awaiting moderator approval
<qeole> Ok, thanks for the info
#ubuntu-kernel 2020-07-13
<dsmythies> Any chance the Ubuntu mainline PPA kernel naming can be fixed? See also 2 weeks ago: https://irclogs.ubuntu.com/2020/06/29/%23ubuntu-kernel.html . For some reason the -rc designations have been dropped. They are important, so we can go backwards to help isolate issues.
<dsmythies> reference: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8-rc5/
<dsmythies> On the .deb files
#ubuntu-kernel 2020-07-14
<apw> dsmythies, it is on my list to look at
<apw> dsmythies, and perhaps even fixed
<dsmythies> apw: Thank you.
<apw> dsmythies, in theory all te 5.8-rcNs are rebuilt
<dsmythies> apw: yes, I noticed.
#ubuntu-kernel 2020-07-16
<ricotz> hi, dmesg requires root permissions now? (running 5.7.0-16.17-generic)
<sixwheeledbeast> you can set that in sysctl but no idea if that is default or related
<sixwheeledbeast> "sysctl kernel.dmesg_restrict" 
<sixwheeledbeast> if 0 it's not that
<ricotz> sixwheeledbeast, could be an intended upstream change
<ricotz> ppisati, hi, did you notice this? ^
<sixwheeledbeast> maybe? is it sysctl? I am not running 5.7
<ricotz> kernel.dmesg_restrict = 1
<sixwheeledbeast> hmm
<dsmythies> That dmesg now needs root persmissions appeared between mainline kernel 5.8-rc1 and 5.8-rc4 (I missed -rc2 and -rc3).
<dsmythies> I do no tunserstand the change, becuase the sameinformation is available in /var/log/kern.log.
<hggdh>  dsmythies: please see https://lists.ubuntu.com/archives/ubuntu-devel/2020-June/041063.html& LP bug
<dsmythies> hggdh: Thank you. I had not realized it was a kernel configuration change. I mainly work upstream in the linux-pm group, but steal the Ubuntu kernel configuration from the mainline kernels. In general I check for config differences, but missed this one.
<matti> The Linux Kernel Report live stream - https://linuxplumbers.lwn.net/b/LPC-kernel-report
#ubuntu-kernel 2020-07-17
<tsimonq2> Hey Kernel Team~
<tsimonq2> *Team!
<tsimonq2> I came across bug 1837886 in the sponsorship queue.
<ubot5> bug 1837886 in kpatch (Ubuntu Eoan) "kpatch 0.5.0-0ubuntu2 ADT test failure with linux 5.3.0-0.1" [Low,New] https://launchpad.net/bugs/1837886
<tsimonq2> Does anyone know if that still needs sponsorship?
<jeremy31> tsimonq2: doesn't the 5.3 kernel and Ubuntu 19.10 go EOL soon?
<tomreyn> !19.10
<ubot5> Ubuntu 19.10 (Eoan Ermine) was the 31st release of Ubuntu, support ended July 2020. See !eol and https://lists.ubuntu.com/archives/ubuntu-security-announce/2020-July/005494.html
<tomreyn> did already
<tsimonq2> jeremy31: What about Bionic?
<tsimonq2> (Thus the question.)
<jeremy31> tsimonq2: Is there an issue in Bionic or Focal?  I don't know
<tsimonq2> Me neither.
<tomreyn> kleber nominated it for bionic on 2019-12-19, and for eoan on 2020-02-24. so apprently it would seem to affect bionic?
<tomreyn> but indeed seth never stated what'S affected
<tsimonq2> Indeed.
#ubuntu-kernel 2020-07-19
<freemangordon> Hi guys, starting with kernel version 5.3.0-59.53 on ubuntu 18.04, my atheros wireless dongle stopped functioning - kernel oops, see https://pastebin.com/X5QNS3kZ. oops is on https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan/tree/drivers/net/wireless/ath/ath9k/htc_drv_init.c?h=master-next&id=30da5834ebc404b6bdb8cbcbea99bb5813e4dfcb#n945 . I bisected to https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan/comm
<freemangordon> Putting printk("%px", priv); to print that priv variable *fixes* the issue, so it seems to be gcc bug
<freemangordon> now, I am stuck, as I have no idea how am I supposed to report such kind of issue
<jeremy31> freemangordon: uninstall the iwlwifi backports
<freemangordon> jeremy31: already uninstalled
<jeremy31> freemangordon: have you rebooted since?
<freemangordon> jeremy31: come on, did you look at what I have posted ^^^? I did "git bisect" over ubuntu kernel tree...
<freemangordon> ofc I have rebooted, how am I supposed to "git bisect good/bad" without it
<jeremy31> freemangordon: I think the 5.3 kernel is EOL
<freemangordon> jeremy31: it is not the kernel, but gcc
<freemangordon> adding a simple printk() fixes the issue
<freemangordon> also, I don;t understand how is 5.3 EOL is if is part of LTS HWE
<freemangordon> *if it is
<jeremy31> freemangordon: 5.3 is only supported as long as Ubuntu 19.10
<freemangordon> ok, but again - this looks like gcc bug, not kernel
<freemangordon> and that gcc bug may as well affect other kernel versions
<jeremy31> freemangordon: I have a USB wifi with same ID and I used it during Ubuntu 20.04 install
<jeremy31> your next updates should include the 5.4 kernel
<freemangordon> are you sure? could you please share a source?
<freemangordon> also, if it is gcc bug, how moving to 5.4 will fix the issue?
<jeremy31> It might be later as linux-generic-hwe-18.04 still shows a 5.3 kernel
<freemangordon> exactly
<tomreyn> only on bionic, though
<jeremy31> https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack#Kernel.2FSupport-1.A18.04.x_Ubuntu_Kernel_Support
<freemangordon> so, you mean that on august there will be upgrade to 5.4?
<tomreyn> there is 5.4 already in proposed
<tomreyn> Package: linux-image-generic-hwe-18.04
<tomreyn> Version: 5.4.0.42.46~18.04.35
<tomreyn> Source: linux-meta-hwe-5.4
<tomreyn> and then there is -hwe-edge, too, if you want to live on the edge
<freemangordon> I don't (want to live on the edge), that's why I am on LTS
<freemangordon> this is a 'production' laptop
<tomreyn> yes, i should not have treated your report as a support request, since you're clearly trying to solve the root cause, sorry.
<freemangordon> tomreyn: ok, so your advice is to not waste time filling bug reports/sending patches and to live with my locally patched ath9k_htc.ko until there is a new kernel release?
<freemangordon> yes, I don;t really need support, but rather an advice on what to do with the issue investigation/results I have gathered so far :)
<tomreyn> my advice is: if you're trying to solve a bug, report a bug (after looking for duplicate reports), and provide the info needed to analyze the bug.
<jeremy31> I am online now with the same wifi and kernel 5.3.0-62
<freemangordon> jeremy31: so?
<tomreyn> by the way, your first message on this channel was cut off after "I bisected to"
<freemangordon> ah, sorry
<freemangordon> tomreyn: ...I bisected to https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan/commit/?h=master-next&id=04a29b0362f0ddaf6e8e489a1be5643362bc66ae, which doesn't make sense ...
<freemangordon> seems release/version change somehow broke it
 * tomreyn can't help with analyzing the bisect, not an ubuntu kernel developer / packager
<freemangordon> jeremy31: the fact that it works on your system doesn't mean I don;t have oops here every time I attach the dongle
<freemangordon> yeah, lets hope some of the ubuntu kernel devs appear, will try to raise a bug in the meanwhile
