#ubuntu-kernel 2005-04-04
<zul> hola
<zul> so much pain not good..
<lamont> whaddya do?
* lamont contemplates an early night
<zul> well i tore a tendon in my knee a couple of weeks ago and tonight i was playing indoor soccer
<zul> so right now my knee is kind of puffy
<zul> night..
<fabbione> mjg59: still aroung?
<fabbione> morning guys
<fabbione> mjg59: http://lkml.org/lkml/2004/12/17/187
<fabbione> mjg59: this patch has a possible 3com fix for suspend resume. i must know if it looks sane or not
<mjg59> fabbione: Just the 3com bit of it? It looks ok
<fabbione> mjg59: ok.. too bad it won't make for haory :(
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre31--2.6.10 | Get it or http://www.vijaygill.com/pics/stfu.gif | There are no kernel bugs.. only broken hardware | Kernel Team Meeting: see #ubuntu-meeting
<dilinger> fabbione: ping
<fabbione> dilinger: pong
<dilinger> http://lists.debian.org/debian-kernel/2005/03/msg00527.html
<dilinger> curious what your thoughts are on that
<dilinger> scroll to the end; the ABI stuff
<fabbione> reading now
<fabbione> >   5) we add support for the series patch handling support which is
<fabbione> >   superior to the ubuntu one.
<fabbione> this is true...
<fabbione> >   6) we add support for per-arch/subarch patchsets, which is needed for
<fabbione> >   replacing the current kernels.
<fabbione> so do we
<fabbione> at least per-arch
<fabbione> i don't like the idea of patches per subarch
<fabbione> already the patch per arch is stupid...
<fabbione> but we need to support it
<dilinger> ok, but.. that's not really what i'm interested in :)
<fabbione> subarch should be part of arch
<fabbione> yeah i am reading all of it :-)
<fabbione> hmm yes
<fabbione> i like the idea of building at install time, but that would bloat a bit
<fabbione> specially on Ubuntu where we don't ship gcc :-)
<fabbione> or install rather
<dilinger> when i wrote that, i wasn't really thinking about d-i
<dilinger> i'm not sure how that would be handled
<fabbione> d-i needs a rebuild at datacenter/buildd level
<dilinger> d-i could probably be special-cased
<fabbione> as well
<fabbione> i still need to sit down and think on the best way to handle it
<dilinger> have udebs generated using the old method, so you end up w/ udebs that contain third party kernel modules.. 
<dilinger> during install, grab the foo-source packages so that the next kernel upgrade doesn't forget to rebuild the modules?
<fabbione> but i think there should be some kind of /etc/kernel-modules-hooks.d/
<fabbione> that has a makefile or a bash script or whatever to install the thirdy part modules
<fabbione> also the option to check what is in /lib/modules/<kernel> that does not belong to the old package might give an idea
<dilinger> suck, almost 5:30am
<fabbione> eheh
* dilinger hopes to finish up this v280 business before 6am..
<fabbione> go back to work :-)
<dilinger> hehe.  i've got a deadline.  the guy who gave this to me is going to ask for a status update at a poker game tonight ;)
<fabbione> ehehe
<jbailey> lamont: Around?
<fabbione> bah
<fabbione> we need to get -31 out too
<fabbione> today
<fabbione> dilinger: ping?
<fabbione> dilinger: boot net ramdisk_size=32000 rootfstype=ext2 works perfectly here
<fabbione> (sparc netboot)
<fabbione> ok this is weird....
<fabbione> we have a stolen-from-head_ppc32--uninorth-agp-suspend.dpatch
<fabbione> that has been there since my grandma was born
<fabbione> and never applied
* fabbione sighs
<fabbione> dilinger: anyway sparc can't install because of sparc.u.c being freezed
<fabbione> hi zul
<zul> fabbione: hey...the 3com stuff is already for a while but a user says it doesnt work 
<fabbione> ok
* zul reads backlogs
<fabbione> -30 is up
<fabbione> i am preparing -31
<fabbione> there is an extra security fix
<zul> yeah saw that..the mirrors must hate you
<fabbione> and i am unfucking the uninorth-agp-sleep patch
<zul> did it fuck up?
<fabbione> well the patch was never applied to the source in the first place
<fabbione> there were 2 copies of them in debian/patches
<fabbione> none of them applied
<fabbione> and it FTBFS
<zul> heh...crap
<fabbione> because the patch is full of typos
<zul> doh...
<fabbione> anyway for -31 ia64/amd64 are go
<fabbione> ppc is building now
<zul> cool...
<fabbione> i386 is go
<lamont> jbailey: I replied to t-bone's email, if that's the question
* lamont is here for about another 2 minutes
<fabbione> lamont: "crunchy corn"?
<fabbione> for -31?
<lamont> fabbione: works for me
<zul> heh crunchy frog sounds better but its against the rules ;)
<fabbione> ok -31 will be up pretty soon
<fabbione> but i won't make the baz dance.. i need to go after
<jbailey> lamont: Yup,thx. =)
<fabbione> it is national holiday and i haven't spent 5 minutes with my wife
<zul> hah
<fabbione> hmm i forgot to give a release name to -30
<fabbione> any idea on the fly?
<fabbione> The "Fried Frogs" Release ?
<fabbione> or Fancy Frogs ?
<lamont> too french.
<lamont> :)
<fabbione> ok.. another one...
<lamont> oh. wait.  ENOTBONE
<fabbione> ehehehe
<zul> crunchy cream
<fabbione> no we have crunchy already
<lamont> already got crunchy corn 
<fabbione> Radioactive Rosbeaf ?
<lamont> fabbione: whirled peas?
<zul> yellow yams
<lamont> blue bacon?
<zul> blasted bacon
<lamont> atomic artichoke?
<fabbione> ahah
<zul> heh
<fabbione> atomic++
<lamont> burnt bacon?
<zul> ++
<lamont> atomic artichoke is bonnie's - I like it/
<zul> same
<lamont> anyway, running away
<fabbione> lamont: later
<zul> buh bye
* fabbione gets ready for upload
<zul> so much email so little time
<zul> no one in their right mind should be using dosfsck
<fabbione> no one in their right mind should have a vfat partition
<zul> stupid windows users
<fabbione> upload on the way
<zul> swwet
<fabbione> it's up
<zul> yay...go spend time with your wife now
<zul> or she will have your balls
<fabbione> i am waiting for the mails
<fabbione> she already has them :)
<zul> well then you arent missing much then
<fabbione> eehhehe
<fabbione> there they are
<fabbione> i am off
<zul> if we have any problems we wont call...yeah right :)
<zul> c ya
<fabbione> please remind lamont to do the baz dance
<zul> ok
<fabbione> otherwise there is no --pre32
<fabbione> cya
<zul> have a good weekend
<zul> lamont: baz dance
<lamont> /dev/sda1       /boot/efi       vfat    defaults,noauto         0       0
<lamont> stupid boot loaders
<zul> heh
* zul fires a gun at lamont's feet 
<zul> dance dance dance hah1
<lamont> does that mean that fabbione uplaoded -31?
<zul> heh
<lamont> bad fabbione - releaseing from --pre31
<zul> Subject: Accepted linux-source-2.6.10 2.6.10-31 (source)
<lamont> yeah yeah
<lamont> any selections for -32's name? or do we wait for content?
<lamont> interesting.
* ..[topic/#ubuntu-kernel:lamont] :  Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre32--2.6.10 | Get it or http://www.vijaygill.com/pics/stfu.gif | There are no kernel bugs.. only broken hardware | Kernel Team Meeting: see #ubuntu-meeting
<lamont> because _I_ did change it... dammit
<lamont> baz switch kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10
<lamont> baz merge kernel-team@ubuntu.com--2005/kernel-debian--pre31--2.6.10
<lamont> baz commit
<lamont> baz branch kernel-team@ubuntu.com--2005/kernel-debian--pre32--2.6.10
<lamont> is short dance
<lamont> GCC ICE on ppc... woot!
<lamont> feh
<lamont> SIGILL
<zul> heh sucker
<zul> for the universe kernels couldnt we just reysync with debian?
<lamont> which ones?
<zul> gimme a sec
<zul> linux-source 2.6.8
<zul> http://www.ubuntulinux.org/wiki/UniverseUnmetDeps
<lamont> zul: well, debian calls that kernel-source-2.6.8, so, um,no.
<zul> um...ok 
<lamont> and I think we specifically dropped that kernel from hoary with predjudice
<lamont> we maintain it for warty,  but no sense promising an extra 6 months when it's old...
<lamont> (dist release date + 18 months minimum)
<zul> ok...well its way before my time
<lamont> so one can expect to see 2.6.10 dropped from breezy, I expect.
<zul> true
<zul> bbl new furniture
<zul> its nice to have new furninture
<fabbione> re
<fabbione> lamont: why there are so many i386 build of -31?
<lamont> fabbione: don't ask.
<lamont> you'll note they're all duplicates
<lamont> I may clean them up sometime
<fabbione> i don't want to know than :-)
<fabbione> it's missing ia64...
<zul> i have achieved office fengi shui
<lamont> ia64 build takes 7+ hours, for starters.
<fabbione> ok
<zul> that was a pretty quick vacation fabbione 
<fabbione> zul: well i have to spend time with my wife
<fabbione> it doesn't mean i am leaving the house (or that i am allowed to do so :))
<zul> heh
<fabbione> but i think i am going to cook some food soon
<fabbione> i will pass by later
<lamont> Thu Mar 24 18:55:39 GMT 2005
<lamont> linux-source-2.6.10_2.6.10-31_20050324-1456 06:48:29 (8 entries, sigma 01:56:36)
* lamont notes that bonnie will be very happy to see -31
<dilinger> fabbione: hm, maybe 2.6.10 breaks it or something?  this is a sunfire 280
<jbailey> fabbione: jb@justBE.com reassigned 1440 to you.  It's not obvious why from the commit log since it's an "it's working" message.  Is there any reason you want this kept open?
<zul> does someone have amd64 and sata handy and they dma turned on their hard drives?
<zul> damn...im late...c ya later
<jbailey> mjg59: Funny that I came across your postings in a forum while looking for info on the suspend signatures in the swap file. =)
<mjg59> jbailey: Haha
<mjg59> To Nigel Cunningham?
<jbailey> mjg59: Yeah, starting at http://www.gossamer-threads.com/lists/linux/kernel/525303?page=last
<mjg59> Yeah, he's obsessed with doing it all in the kernel
<jbailey> Yeah, I wne tthrough his pages first before realising it wasn't the implmenetation in the kernel.
#ubuntu-kernel 2005-04-05
<zul> heylo
<fabbione> morning
<zul> hey
<zul> fabbione:  for #8189 have a look at http://marc.theaimsgroup.com/?l=linux-scsi&m=109638967308598&w=2
<zul> but it might break abi
<lamont> moo
<lamont> fabbione: are you using baz mv for the abi files, or add /delete?
<lamont> looks like baz mv, if I'm understanding the cryptic output from baz update
<zul> fabbione: uh never mind its alrady applied
<fabbione> hi guys
<fabbione> baz mv :-)
<zul> hey fabbione how is it going?
<fabbione> it's going finr thanks and you?
<zul> good...just enjoying a day off
<fabbione> some bugs have bounced to kernel-team
<zul> yeah noticed that
<zul> so uh i take it we are going to be using 2.6.11 for breezy/bender
<fabbione> nope
<fabbione> i am planning 2.6.12
<zul> ok
<fabbione> i don't think we should spend too much time on 2.6.11 for 2 reasons
<fabbione> 2.6.12 is already at RC stage
<fabbione> that means it will be out in final pretty soon
<zul> and....
<fabbione> 2.6.11 has a lot of security holes phone... sec.
<zul> k
<fabbione> sorry i was saying..
<fabbione> 2.6.11 has a lot of security holes that are fixed in 2.6.12 and we have as patches for 2.6.10
<fabbione> that means a lot of extra work in portforwarding the patches
<zul> sounds reasonable i was thinking about version numbering last night
<fabbione> i started looking into the XEN patch
<fabbione> and how to build the debs for it
<fabbione> at least the kernel side
<zul> i say let schweeb handle the user side
<fabbione> yes
<fabbione> userland is very simple
<fabbione> i could package it in half day probablu
<zul> for the kernel version stuff i was thinking something 2.6.12.abi.patchlevel
<fabbione> our plan is to drop the patch level completely
<fabbione> MEH
<fabbione> the abi
<zul> and use what?
<fabbione> nothing. s/abi//g
<fabbione> dilinger did a proposal on debian-kernel that sounds interesting
<zul> ok...then how are you going to keep track if they are using for example different acpi snapshots
<zul> ill have to see
<fabbione> we still track the package version
<fabbione> that cannot be removed
<fabbione> but we can kill the ABI
<zul> ok
<fabbione> we need to see how complex would be to manage without
<zul> do have a url for dilinger's proposal
<fabbione> it should be somewhere here in channel logs
<fabbione> from yesterday iirc
<zul> k
<zul> heh i wont be lazy and ill find it myself ;)
<zul> so you would have a base kernel-image and you would have the user compile the modules themselves ?
<zul> with module-assitant?
<fabbione> something like that, but using a new standard hook where to store the sources of the external modules
<fabbione> so that they can be compiled at postinst time
<fabbione> given that there is an ABI change
<zul> so what if they have a slow ass system?
<fabbione> nasty, eh?
<zul> yeah reminds me of gentoo kind of
<fabbione> well in all cases if they use thirdy part modules they will have to recompile them anyway
<fabbione> we can still do in such a way to ensure that the modules we provide are always in sync
<zul> true but what if the kernel-headers are mixed up, for example if someone who thinks they are know what they are doing but they dont messes up and files a bug report
<crimsun> hmm.  How about always triggering a recompile of l-r-m whenever a new linux-source is uploaded?  True, more space, but more transparent to the end-user
<crimsun> or is that precisely what we're trying to avoid?
<fabbione> zul: i am not sure i understand...
<fabbione> crimsun: we are avoiding 2 things here:
<fabbione> 1) random recompilation of l-r-m and thirdy part modules
<fabbione> 2) having to deal with ABI changes, since they are embedded in the package name
<fabbione> both of them are not easy
<zul> well lets say they have a vanilla kernel-headers installed and they have our kernel-headers installed and something messes up
<fabbione> zul: our kernel headers lands alwys in a predictable place.
<fabbione> if they fuck up the system is kinda of not our problem
<zul> ok...but what if the user puts it in the same place...
<fabbione> plus we can add sanity checks before performing operations
<zul> im just trying to play devio advocate here
<zul> true..
<fabbione> zul: sure.. i appreciate that :-)
<fabbione> that's why we need really brainstorm a lot face2face
<zul> no gentoo here ;)
<fabbione> it's really difficult to evaluate all the corner cases on IRC
<zul> yeah too bad i wont be at udu :)
<fabbione> we can also make it an option
<crimsun> fabbione: ok, I see regarding (1).  So that means we avoid automatically triggering a rebuild on the buildds whenever a new l-s is uploaded?
<fabbione> crimsun: there are a lot of implication in hiding an ABI change. l-r-m is really the last of our problems
<fabbione> since we have control of it
<crimsun> fabbione: right, gotcha
<fabbione> our problem is to find an efficent way to detect external modules (out of Ubuntu), and do in such a way that if there is an ABI change, print a big fat warning to the user in the first place
<fabbione> and provide an automatic system to manage recompilation of these modules on request
<fabbione> of course there would be the nice config file with: do_everything_for_me=[yes|no|ask] 
<zul> well why not have a list of base modules that we support like ipw2200, hostap, and then inform the users that they abi has changed we are going to break shit now
<zul> er...list of 3rd party modules
<fabbione> zul: i am not talking about 3dy part modules in our tree.
<fabbione> for example i compile the quickcam module myself
<zul> duh..oops
<fabbione> that is not part of either linux-source or l-r-m
<fabbione> how can i make it so that if i change the ABI i can tell the user: hey dude.. this module you compiled yourself will not load....
<fabbione> and so on...
<fabbione> +
<fabbione> hey dude: if you put the source in this dir
<fabbione> it will be recompiled automatically for you
<zul> sounds reasonable
<fabbione> we can't use a Xen kernel as our default kernel... yet
<fabbione> so that means that we to create 386-xen, 686-xen, k7-xen
<fabbione> SMP is not supported in 2.6.10
<fabbione> but it might in 2.6.11.. not sure yet
<zul> in linux-sources? cool
<fabbione> well, that's the idea
<fabbione> so that would add 6 more linux-images on i386
<fabbione> that will differ of one option
<fabbione> + we lose ACPI and CPUFREQ
<fabbione> still not supported by xen
<fabbione> ah and >4GB mem support.. but i don't know that many people using that much anyway
<fabbione> may i add a royal mess to build the package? ;)
<fabbione> since ARCH=xen :-)
<fabbione> that might attempt to create _xen.deb
<zul> ++
<zul> i think im going to go watch the incredibles ill be back later
<fabbione> have fun
<zul> i will
<fabbione> it's a nice movie
<fabbione> :-)
<zul> especillay the extras for the dvd
<fabbione> heheh
<zul> that was a good movie
#ubuntu-kernel 2005-04-06
<lamont> Min drive buffer fill was 38%
* lamont wipes his brow
<dilinger> overburn..
<dilinger> er, burnfree
<dilinger> that's the one
<lamont> well, was cd-rw, so not soo bad...
<Roey> oh
<Roey> hello
<Roey> this place exists?
<Roey> I see the usual suspects
<Roey> calc, crimsun
<Roey> <Roey> ok
<Roey> <Roey> so two issues:
<Roey> <Roey> 1) I try to boot, say, my own custom kernel with raid1 built in:
<Roey> <Roey> http://rafb.net/paste/results/2qaAZM82.html
<Roey> <calc> so on that one the problem is the device nodes aren't being created in /dev
<Roey> <Roey> hmm
<Roey> <Roey> 22:27:36 ~ ls /dev/md*
<Roey> <Roey> /dev/md0  /dev/md1  /dev/md2
<Roey> <Roey> but I hit ctrl-d twice and it boots up fine
<Roey> <Roey> mounts the stuff it needs, etc.
<Roey> there.
<zul> alright online mugshots
<Roey> oh? :)
<Roey> oh
<Roey> god damn it
<Roey> right I forgot...
<Roey> you need a patched cramfs to load initrd's for custom kernels.
<Roey> god damn it!
<Roey> and LILO doesn't work...
<Roey> oof
<crimsun> you love it.  Admit it, you love the pain.
* Roey bows his head 
<Roey> yes
<Roey> I admit it
<Roey> I could be content with Kubuntu
<Roey> but I admit it, I need to push the envelop
<Roey> *envelope
<Roey> actually
<Roey> I need to (1) get rid of that error on startup,
<Roey> and (2) install the latest nvidia drivers, 
<Roey> and (3) patch the kernel so that it properly supports nvidia.
<Roey> er
<Roey> nvidia and WACOM TABLETS.
<Roey> <megabyte405> Roey: got a dos boot disk?  Boot onto it, FDISK all partitions away, then at the prompt type "fdisk /mbr" no quotes.  Then try again.  Partition table might be weirded out
<Roey> is this guy legitimately helping??
<zul> oh hell im going to bed...night
<Roey> heh
<Roey> #ubuntu is /no/ help
<Roey> every
<Roey> **ever**.
<crimsun> Roey: your problem is rather advanced.  I doubt many people, if any, will be able to help you sort it.
<crimsun> Roey: maybe jasonbox?
<Roey> hmm
<Roey> dunno?
<Roey> at this point, fine
<Roey> I'll give in to grub
<Roey> and official Ubuntu kernels.
<Roey> I give up.
<Roey> I just want to know if I can compile my own kernel (following The Debian Way) and have it running.
<crimsun> I'm absolutely certain you can given you don't change anything
<Roey> like what?
<Roey> I want to apply the latest nvidia and wacom patches
<Roey> that's all
<crimsun> nvidia you'd do externally
<crimsun> so you don't need to recompile
<crimsun> wacom, don't know much about.  Got a url?
<Roey> http://linuxwacom.sourceforge.net/index.php/howto/debwacom
<crimsun> does the version in the Ubuntu kernel not work?
<Roey> nope
<Roey> see what happens is that:
<Roey> Xorg, if you load mousedev,
<Roey> steals control of the cursor/eraser/stylus devices from the kernel wacom driver.
<Roey> the patched wacom module detects when this happens
<Roey> and prevents it
<Roey> er
<Roey> or relinquishes control to Xorg
<Roey> instead of trying to manage it itself.
<Roey> s/it/them
<crimsun> ok, and this allows the cursor/eraser/stylus devices to work alongside the mouse and any other input devices?
<Roey> yes
<Roey> yes it does
<Roey> it explains it on the page
<crimsun> ok, and how critical would _you_ rate the fix?
<crimsun> be realistic.
<crimsun> cos I'm up to my neck in trying to fix universe packages (at the moment, the slew of pike7.* brokenness and two packages that require pike7.4)
<crimsun> but if it's a _critical_ fix, I'll look and try and generate a dpatch
<crimsun> nvidia's not an issue; you can use the latest drivers by either using Sid's nvidia-kernel-source or by invoking their installer
<Roey> crimsun:  I cannot use my tablet.
<Roey> crimsun:  it's not like nvidia where I *prefer* the newer driver but I can live with the current one.
<Roey> crimsun:  with the tablet it's like.. it just doesn't respond.
<Roey> crimsun:  wait a sec.. you're an ubuntu developer???
* Roey realizes only now...
<crimsun> ok, but you can live without your tablet, correct?  What I'm trying to determine is if it warrants a grave enough fix due your not being able to use any other input device in the X Window System
<crimsun> no, I'm not; I'm a universe maintainer; I just happen to be on the kernel team as well
<Roey> crimsun:  ah :)
<crimsun> in other words, if the current wacom code in the Hoary kernel prevents you from using your mouse and/or your keyboard in X.Org, then I think I can justifiably generate a patch to submit
<Roey> crimsun:  it's the other way around; the current wacom code in the Hoary kernel prevents me from using my tablet in xorg.
<crimsun> but your mouse still works?
<Roey> oh, sure.
<Roey> aye it does.
<Roey> it's an mx1000 mouse.
<Roey> http://seclists.org/lists/linux-kernel/2005/Mar/2151.html
<crimsun> ok.  Well, if your mouse still works, I wouldn't rate this issue release-critical, but I will go ahead and generate a dpatch, then build a standard Ubuntu kernel for you with the patch applied (will take ~2 hours)
<Roey> I'm having trouble with that, too
<Roey> oh, thank you so much Dan!
<Roey> jeez
<Roey> wow
<Roey> thanks :)
<Roey> crimsun:  do you know, btw,what's the status of konq-plugins package?
<crimsun> now whether it actually ends up in the kernel shipped with Hoary is not my call.
<crimsun> (I'll have to pass that buck to fabbione.)
<crimsun> No, unfortunately I do not know RE: konq-plugins
<crimsun> Roey: ok, I don't think the mx1000 issue is critical enough to warrant a patch this close to Hoary's release, but keep at it for Bendy
<crimsun> err
<crimsun> Breezy
<crimsun> too many 'b's and 'e's
<Roey> :)
<Roey> when is that, six months after hoary?
<crimsun> yes, 6 months from 6 April, 2005
<Roey> (isn't one goal of ubuntu to have regular release cycles (as opposed to Debian? :))
<Roey> ok
<crimsun> of course you will be able to track Breezy just as you do Sid
<crimsun> just as you're able to track Hoary now
<Roey> ok
<crimsun> hmm
<crimsun> Roey: have you tried wacom-kernel-source from universe?
<Roey> oh
<Roey> hmm
<Roey> neat!
<Roey> lemme see what the revision is on that.
<crimsun> 0.6.6-4 is what Hoary has
<Roey>   Candidate: 0.6.6-4
<crimsun> (Sid's only several revisions more recent, 0.6.6-7)
<Roey> linuxwacom-0.6.6.tar.bz2  -  2004-12-01  Build .ko locally and support kernel 2.6.10.
<Roey> so..
<Roey> that doesn't support 2.6.10
<crimsun> eh?
<Roey> version .6.6-4 does not 
<Roey> er
<Roey> I see it does.
<Roey> my bad!!!!!
<Roey> wow, daniel, you're awesome
<Roey> hmm.
<Roey> can you show me how to customize my kernel with this (including grabbing the kernel sources, etc.)?
<crimsun> what distro are you currently running?
<Roey> ubuntu + kubuntu package
<Roey> hoary.
<Roey> crimsun:  (I switched over)
<crimsun> sudo apt-get install build-essential linux-headers-$(uname -r) fakeroot wacom-kernel-source
<crimsun> let's shift this back to #ubuntu, if you don't mind
<Roey> sure, ok
<crimsun> thanks
<fabbione> morning everyone
<Roey> hey fabbione 
<Roey> you got a new customer
<crimsun> morning fabbione 
<fabbione> who ?
<crimsun> fabbione: (I think he's referring to himself)
<fabbione> ahhhh
* fabbione just woke up
<Roey> =)
<Roey> crimsun, see the #ubuntu stuff :)
<Roey> heloo00oo
<Roey> anyone here?
<Roey> :)
<calc> no
<Roey> ok
<Roey> calc: see this:
<Roey> I downloaded this wacom module for kernel 2.6.10 (ubuntu)
<Roey> and I enabled hid
<Roey> ("--enable-hid")
<Roey> and I get errors:
<Roey> http://rafb.net/paste/results/20pSrR22.html
<Roey> and I'm wondering where this error is -- in the module or the kernel.
<calc> <- is not here
<Roey> I need to be able to compile wacom's replacement hid
<Roey> ah
<Roey> ok
<Roey> fabbione:  see this:  http://rafb.net/paste/results/20pSrR22.html
<Roey> That's after I did: apt-get install build-essential linux-headers-$(uname -r) fakeroot wacom-kernel-source
<Roey> and then I went into /usr/src/modules/wacom,
<Roey> and edited 'rules' to --enable-hid in the 'kdist' stanza 
<Roey> then when I compiled it with this commmand:
<Roey> cd /usr/src/modules/wacom && fakeroot ./debian/rules kdist KVERS=$(uname -r) KSRC=/lib/modules/$(uname -r)/build/
<Roey> I get this output:
<Roey> http://rafb.net/paste/results/20pSrR22.html
<Roey> (the one I gave you above)
<fabbione> Roey: i don't want to sound unpolite, but this chan is to discuss the kernel development. General help should go to #ubuntu please.
<fabbione> at 15 days from release, i really don't have to see external modules.. sorry
<fabbione> + it's eastern :-)
* fabbione doesn't always nerd on holidays ;)
<Seveas> you don't?
<Seveas> shocking :)
<zul> hey
<jbailey> Heya Chuck
<zul> hey jbailey how is it going?
<jbailey> Good, a bit tired.  I've mostly shaken off the hang over.
<zul> heh
<jbailey> I'm teaching a course this evening and should probably prep for it.
<zul> you arent suppose to drink on good friday :)
<kylem> says who? doesn't say that in the bible...
<kylem> :P
<zul> hmm...wifey lied to me then 
<kylem> it's one of those pope-things.
<zul> ah ok
<kylem> afaik at least.
<Roey> hi
* dilinger finally gets around to subscribing kernel-team and kernel-bugs to gmane
#ubuntu-kernel 2005-04-07
<kylem> dilinger, thanks.
<mjg59> dsafdsafdsarewaoiufdsdsoiufdslk
<kylem> mr. garrett?
<mjg59> I have what seems to be a moderately critical ACPI patch sitting here
<mjg59> It seems that Windows enables GPEs before calling the _WAK method
<mjg59> And, uh, Linux currently doesn;t.
<kylem> hmm?
<mjg59> So if a _WAK method does anything that triggers an event, the event handler never gets called
<mjg59> And it all goes pear shaped
<kylem> yuck.
<mjg59> Jesus. It actually seems to fix it, too.
<schweeb> I was told I should talk to you guys about packages that have kernel dependencies in universe that won't build... such as user-mode-linux, which requires kernel-source-2.4.26
<schweeb> http://people.ubuntu.com/~lamont/buildLogs/Test/u/user-mode-linux/2.4.26-3um-1/user-mode-linux_2.4.26-3um-1_20050324-0640-i386-failed
<zul> mjg59: http://bugme.osdl.org/show_bug.cgi?id=4390 
<zul> then there is a whole thread about powersaving and usb devices on linux-usb-devel
<dilinger> as soon as someone sends somethign to kernel-team, the gmane newsgroup should get created
<dilinger> gmane.linux.ubuntu.devel.kernel.{bugs,general}
<fabbione> morning
<dilinger> evening
<fabbione> mjg59: thanks for the patch but that will be for breezy
<fabbione> no more patch for hoary
<fabbione> dilinger: what's up?
<dilinger> not much.  just thinking about sarge preparations
<fabbione> i started squashing xen into the kernel
<fabbione> the patch is not too bad, but it has some duplicate files = extremely annoying
<fabbione> + it needs me to  add the patch per subarch support
<fabbione> btw.. how do you handle the kernel-patch package, given that you have general patches, patches per arch, and patches per subarch?
<fabbione> do you create all of these patches?
<fabbione> or just the general ones?
<fabbione> because right now i create patches only per arch
<fabbione> i still do not generate per subarch diffs
<fabbione> i think that would give the same problem creating the patched kernel-source-2.6.X package...
<fabbione> hmmmm
<dilinger> sorry, roommate distracted me
<fabbione> no problem :)
<dilinger> i haven't had to deal w/ kernel-patch stuff for a while (w/ devmapper patches)
<dilinger> or are you talking about kernel-patch-debian?
<fabbione> that latter
<fabbione> given that you have the three levels of patches
<fabbione> which ones are reflected into kernel-patch-debian?
<dilinger> the stuff in kernel-patch-debian is just stuff from kernel-source
<dilinger> that's for all archs
<fabbione> so you lose per arch and per subarch bits
* dilinger tries to find a per-arch kernel-patch
<dilinger> ok, kernel-patch-2.6.8-hppa
<dilinger> that still does it the old way
<dilinger> that's a patch on top of kernel-patch-debian
<dilinger> most archs just commit patches directly to kernel-source, though
<dilinger> sparc, powerpc, i386, etc, all had their patches merged into k-s
<fabbione> ok, so we handle the per arch in a better way :-)
<fabbione> since for me it's a Package: any
<fabbione> and i create the diff per arch
<fabbione> hppa is part of it
<fabbione> what about subarches?
<fabbione> i know you support it
<dilinger> yea, see, the problem w/ doing per-arch patches is, you get other patches that conflict
<dilinger> i'm not aware of subarch patches
<fabbione> dilinger: yes, and that's why by (our internal) policy the per arch patches must be applied only after the general patches
<fabbione> and not mixed in the middle
<dilinger> i mean other patches
<dilinger> ie, kernel-patch-grsec, kernel-patch-devmapper, etc
<dilinger> they must apply to kernel-patch-debian
<fabbione> oh well, these are external patches anyway
<dilinger> but if you throw misc arch-specific patches in there, it gets messy.  might as well not bother packaging separate patches
<fabbione> yes i see, but i am talking about only kernel-source here
<fabbione> dilinger: that becomes kernel-patch-foo maintainer problem to get his patch properly integrated instead of maintaining externally
<fabbione> external patches = crap
<fabbione> imho
<dilinger> that's cause you integrate external patches :p
<dilinger> we try to do the opposite
<dilinger> if they're not upstream, and they're not in the process of being fed upstream, we don't want them in kernel-source (and per-arch kernel packages)
<fabbione> we both have valid points in that area
<dilinger> otherwise, it becomes a PITA to support
<fabbione> but using your approach, you correctly push the external patches responsability to the maintainer :-)
<dilinger> yep
<fabbione> so if you apply a persubarch/perarch patch
<dilinger> and that's why we want to make it as easy as possible for those maintainers
<fabbione> it's not your problem to let -grsec to apply
<dilinger> if they suddenly have to deal w/ making -grsec apply to not only kernel-patch-debian, but various other per-arch patches..
<dilinger> when i maintained kernel-patch-devmapper, hubert's application of a crippled dm patch was a constant source of hassle
<dilinger> 'cause what he applied was only useful for basic lvm stuff.  snapshotting, etc, didn't work
<dilinger> so i ended up having to have two patches in kernel-patch-devmapper; one for vanilla kernels, and one for debian kernels
<dilinger> that totally broke kernel-package, though
<dilinger> people had to apply and unapply patches manually.  it was a mess
<dilinger> so, having a canonical source for those patches to apply against is valuable
<fabbione> that's why i hate external patches :-)
<dilinger> thanks for the bluetooth thing, btw
<dilinger> did you ever find a fix for the BINDTODEVICE thing?
<fabbione> nope
<fabbione> i think there is none yet
<dilinger> i took a look at netdev-2.6, but didn't see any fixes.  i assume the problem is that the sk_dst_get stuff was returning the sk_dst_cache, which wasn't invalidated?
* dilinger looked at the code when i first got the email, but didn't feel like writing an app to see which codepath it actually went through
<fabbione> our patch finder is pitti for this stuff
* dilinger nods
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre32--2.6.10 playground: kernel-debian--experimental--2.6.10 | Get it or http://www.vijaygill.com/pics/stfu.gif | There are no kernelbugs.. only broken hardware | Kernel Team Meeting: see #ubuntu-meeting
<fabbione> i need to remember to put all my clocks one hour in front
<fabbione> this daylight saving shit is a royal pain
<dilinger> hrm
<dilinger> i'm gonna be on a plane then :(
<fabbione> um?
<fabbione> for the meeting?
<fabbione> do you remember if cp -al creates softlinks or hardlinks?
<dilinger> actually, no, i take that back.  i'm getting back to albany around 2pm.  so, i'll probably just be getting home
<dilinger> soft
<dilinger> iirc, of course ;)
<fabbione> yeah i need to check that to implement per subarch patching
<fabbione> it loks like hardlinks
<dilinger> yea
<dilinger> cp -as
<dilinger> that'll do softlinks
<fabbione> rock
<Roey> fabbione:  hi
<Roey> fabbione:  do you maintain kubuntu kernel stuff?
<Roey> I built the wacom-kernel-module 
<Roey> er
<Roey> enabled the replacement hid, mousedev, evdev, usbmouse drivers in the module's debian/rules
<Roey> but when I make a kubuntu package from the sources, it doesn't seem to contain these .ko's
<Roey> crimsun and I have been looking at this for the past 45 mins.
<Roey> this doesn't make -any- sense.
<Roey> this wacom linux kernel package seems to be missing key functionality
<crimsun> Roey: I haven't seen the build log from your last attempt
<Roey> http://rafb.net/paste/results/8narM137.html
<crimsun> Roey: err, that can't be your build log...
<Roey> ah
<Roey> right
<Roey> that's the dpkg -L listing of that package
<Roey> showing that only wacom.ko was installed.
<crimsun> right, but to troubleshoot, we'd need your build log
<Roey> http://rafb.net/paste/results/Dz7HbQ95.html
<Roey> crimsun:  http://rafb.net/paste/results/Dz7HbQ95.html
<fabbione> Roey: the kernel for ubuntu and kubuntu is the same
<fabbione> and i already gave you an answer yesterday about the driver
<Roey> "No need to build input.o for kernel 2.6" -- so input.ko is not built.
<Roey> fabbione:  did you?
<fabbione> <fabbione> Roey: i don't want to sound unpolite, but this chan is to discuss
<fabbione>            the kernel development. General help should go to #ubuntu please.
<fabbione> <fabbione> at 15 days from release, i really don't have to see external
<fabbione>            modules.. sorry
<fabbione> <fabbione> + it's eastern :-)
<Roey> I meant ubuntu
<Roey> not kubuntu
<fabbione> it's the same kernel
<Roey> kubuntu is just the kde libraries for ubuntu
<fabbione> there are no differences
<Roey> I know
<Roey> I know
<Roey> I'm talking about the ubuntu kernel.
<fabbione> <Roey> fabbione:  do you maintain kubuntu kernel stuff?
<Roey> *ubuntu* then
<Roey> sorry, my mistake
<fabbione> i was also answering to this one :-)
<crimsun> he's our team lead, roey.
<Roey> understood!
<Roey> fabbione:  so I'll move to #ubuntu then
<Roey> sorry
<fabbione> i hate Makefiles :-)
<bhna> usb 1-1: device descriptor read/64, error -71
<bhna>  sorry, dmsg after inserting an usb-stick. usb 1-1: device descriptor read/64, error -71
<fabbione> bhna: known bug. it's already reported on bugzilla.u.c
* fabbione -> breakfast
<bhna> fabbione: tnx ;-)
* lamont crawls into bed.  g'night
<fabbione> night lamont
<zul> morning
<crimsun> morning
<zul> gday
<zul> mmmm...ketchup
<Roey> hi
<Roey> anyone here?
#ubuntu-kernel 2005-04-08
<Roey> hi
<Roey> can I borrow anyone for fs driver help in #ubuntu, please?
<fabbione> +  Changes by Matthew Garrett:
<fabbione> +
<fabbione> +  * Make hardware sleep sequence more compliant to ACPI specifications:
<fabbione> +    - Add patch acpi_gpe_spec.dpatch.
<fabbione> +
<fabbione> mjg59: ^^
<fabbione> does it look ok?
<zul> gday
<fabbione> hey zul
<zul> hey fabbione good holiday?
<fabbione> zul: more or less.. a bit heavy 
<fabbione> had to do quite a lot of work in the house
<zul> cool..
<zul> hah hah :)
<zul> i still get today off
<fabbione> it was off today too
<fabbione> but i am working on the xen kernels
<fabbione> i have almost finished :)
<zul> ah how are they coming?
<zul> neat
<fabbione> they are building :-)
<zul> i was doing some kernel janitorial stuff this weekend
<zul> and playing with 2.6.12-rc1
<fabbione> neat
<fabbione> -32 is ready for upload
<fabbione> we need the usual round of buildd
<fabbione> but i will wait tomorrow to do it
<zul> more security updates?
<fabbione> yes
<zul> seesh
<fabbione> and an urgent acpi fix
<zul> oh?
<fabbione> it's something simple, but fixes a lot of "go to sleep" issues
<zul> cool
<fabbione> as soon as RC is out and -32 uploaded
<fabbione> we need to start focusing on breezy
<zul> already have ;)
<fabbione> yeah we need to put down a TODO list
<zul> i started a todo list on the wiki and i have a list of third party drivers ill put in the wiki as well
<fabbione> zul: it's in the debian/ dir too
<zul> is is? i didnt see it :)
<fabbione> external-drivers or something like that
<zul> ah ok
<fabbione> yeah i did start writing and updating it
<fabbione> there is stuff missing there
<fabbione> like the mppe driver
<zul> k ill update it as well
<fabbione> that i figured only a few days ago
<fabbione> we will need to split the tasks for the first 2/3 weeks
<zul> the 64bit ppp-mppe?
<fabbione> yeah that one.. 
<fabbione> but it's not 64bit clean
<zul> there were some patches i saw for ibm thinkpad notebooks as well i saw on lkml a while ago
<fabbione> yes
<fabbione> i saw them too
<fabbione> but we will not add it back until it is upstream
<fabbione> there were several problems with that patch
<zul> yeah i saw
<fabbione> so i had rather avoid another war of include/exclude
<zul> sure..
<fabbione> when it is upstream, we will include
<zul> put the todo list on the agenda for the meeting as well
<fabbione> yeah ... let's keep it in the aob
<zul> sure
<zul> hostap is not in the list?
<fabbione> probably yes
<fabbione> i would like to chase the list down first
<fabbione> and see what is the status of the actual drivers
<fabbione> i see 3 steps here
<fabbione> 1) clean
<fabbione> 2) forwardport to the new kernel
<fabbione> 3) add new drivers
<zul> heh...i think i figured out why gentoo can distribute win4lin http://www.digitalriver.com/dr/v2/ec_MAIN.Entry17c?CID=0&SID=40113&SP=10007&PN=5&PID=481292&DSP=&CUR=124&PGRP=0&CACHE_ID=0
<fabbione> brrrrr
<zul> loosers :)
<jbailey> I might have a bug that involves firmware loading on an amd64 (8224) - Is that generally expected to work?
<jbailey> (I don't have an amd64, so no exposure)
<zul> no amd64 here either..
<zul> fabbione: updated the external-drivers in my baz
<fabbione> zul: ok
<fabbione> jbailey: checking the bug, but i don't have amd64
<fabbione> jbailey: it would be more important imho to get udev fixed for firewire
<fabbione> mantiena was talkign about it on #u-d
<fabbione> i will look into the firware issue in a few sec.
<fabbione> i already had something like that for another driver
<jbailey> Yup.  I'm just going over my list of new bugs to see if they are things I actually have the skills to fix. =)
<fabbione> jbailey: the bug is still assigned to me
<fabbione> #3609
<jbailey> Oh?  Hmm.  Bugzilla was sending me emails about it, so I assumed it was assigned to me.
<fabbione> the changes to do are pretty simple
<fabbione> probably you are in CC
<zul> bbiab must clean the guinea pig cage
<fabbione> xen images are almost ready...
<fabbione> i am getting the abi files now
<jbailey> I should learn more about xen sometime.
<fabbione> jbailey: it is really neat
<fabbione> i have been playing with it the last week
<fabbione> basically it allows you to do hw partitioning
<fabbione> + other nice stuff
<fabbione> jbailey: i am pretty sure you are familiar with the concept of execution domain
<jbailey> Yeah.
<fabbione> each domain is like a real machine
<jbailey> We had large sparc setups at my last job.
<fabbione> but it's not
<fabbione> jbailey: exactly like the e10k
<fabbione> except that is done in software
<jbailey> These were sunfire racks, but yeah.
<fabbione> you run a master domain that boots the real machine and identify/access the hardware
<fabbione> and small subdomains
<fabbione> to which you assign hardware
<fabbione> that's basically what xen does
<fabbione> but it has some extra features
<fabbione> like the possiblity to migrate one domain to another host in the same lan
<jbailey> Does it do virtualisation for sharing resources like NICs and disks?
<jbailey> Oh nice. =)
<fabbione> from the master domain you export one or more block devices to each domain
<fabbione> it can also be nfs or whatever
<fabbione> more domains can share the same device
<jbailey> Cool, so it's not necessarily whole disk.
<fabbione> with the usual rw/ro limitations
<fabbione> not at all
<fabbione> you can export a partition or a lvm partition
<fabbione> one limitation that i need to check is how it handles the ram allocation
<fabbione> right now each domain has its own ram allocated
<fabbione> that makes it a bit less dynamic than UML
<fabbione> that can see the whole memory
<fabbione> but the domains can't interfere with each other
<fabbione> with xen, you assign N MB and the domain can see only that
<fabbione> so basically you are limited in that way
<jbailey> Still nice, though.
<jbailey> I can imagine some nice stuff being done with a SAN and a heavily SMP box for ISPs and whatnot.
<fabbione> actually SMP is not supported yet (as 2.6.10)
<fabbione> or at least it looks disabled as config option and it just does it
<fabbione> because it is mentioned everywhere that you can bind a specific domain to a certain CP
<fabbione> CPU
<fabbione> or keep it in loadsharing
<fabbione> btw the scheduler is highly tunable
<fabbione> i am off for dinner :-)
<fabbione> bbl
<jbailey> 'bye Fabio.  Thanks for the explanation. =)
<zul> c ya
* fabbione happely burps
<zul> heh i had mcdicks for lunch
<fabbione> ehehe
<fabbione> there we go... abi files generated!
<zul> cool...i just sent my first patches to kernel-janitors ml
#ubuntu-kernel 2005-04-09
<jbailey> Nice.  What does it do?
<zul> adds module_version to some network drivers
<zul> mmm....spiffy...System of a Down - Mezmerize - BYOB _Bring Your Own Bombs_.mp3
<fabbione> morning
<dilinger> good evening
<lamont> morning fabbione 
<fabbione> hey dilinger 
<fabbione> make_kpkg is shitting on me
<fabbione> dpkg-gencontrol: error: package linux-xen0-2.6.10-5-386-xen0 not in control info
<fabbione> why on earth does it change linux-image into linux-xen0
<lamont> hrm... so who should 8189 really be assigned to, rather than kernel-team, I wonder
<dilinger> uh
<dilinger> i have no idea, that's really odd
<dilinger> 'linux' is set via --stub, the image bit should be from kernel-package.. 
<dilinger> you built it w/ kernel_image?
<fabbione> dilinger: i used the same way we build the kenrels in ubuntu
<dilinger> i have no idea, i've never seen kernel-package do that
<dilinger> i need to get to bed, job interview tomorrow at 8:30 :(
<fabbione> dilinger: good night and good luck
<fabbione> lamont: 8189 is mostlikely our
<dilinger> thanks
<fabbione> usb-massstorage is teh sux
<lamont> fabbione: yeah, but we assign them to debzilla or to an individual
<lamont> rather than polluting kernel-team
<lamont> kernel-bugs already gets them (qa contact is cc'ed...)
<lamont> 99% sure.. :0)
<fabbione> right
* lamont sleeps
<fabbione> night lamont
<unifi> hey is anyone around?
<unifi> I am trying to figure out where my kernel is
<fabbione>  /boot
<unifi> ok thanks... then what is in /lib/modules?
<fabbione> the modules that the kernel or the user can load on demand
<zul> hey
<zul> bleah since when did ati do ide
<fabbione> hi zul
<zul> hey fabbione how is it going?
<fabbione> not too bad
<fabbione> i committed some stuff in experimental you want to look at :)
<zul> like what?
<fabbione> xen?
<zul> ah...where again?
<fabbione> see /topic
<zul> ah sweet!
<zul> i didnt see that just woke up ;)
<fabbione> it has been there for a few days now :)
<zul> heh it shows you how observant i am
<zul> whats the difference between xen0 and xenu
<fabbione> i still need to improve the descriptions and fix the header packages
<fabbione> but basically xen0 is the kernel the boots the machine
<fabbione> xenu is the one that boots the virtual machines
<zul> ah ok
<fabbione> i am still not sure if we are handling xen properly...
<fabbione> right now i consider it a special cased flavour of i386
<fabbione> but i think we will need to treat it as a separate arch
<fabbione> otherwise fixing the headers will be a royal mess
<zul> gotcha
<fabbione> zul: your updates to external drivers are bogus :)
<fabbione> that file matches what is in the kernel
<fabbione> not what is upstream
<zul> ah ok
<zul> well they should be in experimental then ;)
<fabbione> as soon as you update a driver, you update that file too
<fabbione> so you know what is in and what's not
<zul> ah got it
* fabbione sighs
<fabbione> build time for i386 is almost doubled
<zul> hah hah
* lamont looks at 212226, wonders if the kernel has changed any since that bug was filed...
* lamont thinks xen is a separate arch
<lamont> but we don't have a buildd for Architecture: xen
<lamont> so it probably has to build on i386
<fabbione> it can only build on i386 :)
<fabbione> atm
<fabbione> lamont: i have been puzzled about adding xen as arch/i386/*-xen* flavours
<fabbione> or add arch/xen-i386/$flavours
<fabbione> both cases have pro/cons at build time
<fabbione> right now i am just curious to get these test images out
<fabbione> we can always change the internal build at anytime
<lamont> right - either way involves abusing things a little bit
<lamont> actually, arch/i386/*-xen* (*.xen?) is probably the way to go, otherwise i386 needs to know how to build for 2 architectures, which is ugiler than having extra configs
<fabbione> well i was hoping in a xen-amd64 soon to be hounest
<fabbione> it alredy supportes x86_64 to certain degrees
<fabbione> lamont: there are still hacks around tbh
<lamont> right.  But either xen builds on 1 platform, or we have xen flavors of various platforms
<fabbione> like we need to build a special linux-headers package for Arch: "xen-i386"
<lamont> ah
<fabbione> eitherway it needs to be built :)
<fabbione> well i mean that the standard headers are not ok for xen
<fabbione> since include/asm-xen is missing in the standard ones
<lamont> so it sounds almost like there's a xen-i386 architecture, and i386 knows to build both i386 and xen-i386
<fabbione> exactly
<fabbione> if you want to look at it from a pure theoretical point of view
<fabbione> than the Arch is xen-i386
<fabbione> or even better: Arch: xen built on i386
<fabbione> but clearly we can handle as we want internally
<fabbione> we are not introducing a brand new source, just a patch on top of what already exists
<fabbione> it's almost like we do for hppa
<lamont> coolness
* lamont wonders when t-bone was coming back
<lamont> end of week?
<fabbione> i can't remember
<zul> ooh...i fucked up my palm
<fabbione> YAY
<fabbione> first full build of XEN packages
<fabbione> approx 4 hours
<zul> oi...thats alot
<fabbione> on i386 + distcc + ccache and -j 15
<fabbione> well probably ccache got outdated
<fabbione> or something
<zul> fabbione: motu team has been asking me about the kernels in universe since they are not installable anymore should be tell tem to sync with debian for only arches we support?
<fabbione> zul: they should be able to decide themself. either solutions work for me
<fabbione> and the xen kernels are not compiled properly
<zul> okie dokie
<fabbione> damn make_kpkg
<zul> hehe
<fabbione> they build, but they can't boot
<fabbione> file xen-linux-2.6.10-5-686-xen0 
<fabbione> xen-linux-2.6.10-5-686-xen0: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
<fabbione> tsk
<zul> hehe
<zul> ill tell them to sync 386,686,686-smp,k7,k8 any others?
<fabbione> powerpc? ia64? sparc?
<zul> oh yes...
<zul> not on my radar ;)
<fabbione> lamont: do you care about hppa?
<lamont> fabbione: sure
<lamont> or do you mean something specific?
<fabbione> lamont: sync from debian -> universe
<lamont> syncing what?
<lamont> 2.6.11?
<zul> 2.6.8
<lamont> 2.6.8 is ancient for hppa, unless kyle has been busy...
<kylem> i've not uploaded anything recently.
<zul> fabbione: sync debian's 2.4 stuff as well...i wouldnt think so because of initrd-tools and the like
<zul> because if i can recall jbailey said they havent been tested
<fabbione> whatever :)
<jbailey> zul: I'm guessing by now I would've heard some bitching if initrd-tools in Ubuntu was b0rked on 2.4
<zul> ok thats cool..
<lamont> the debian 2.6.8 kernel for hppa is the one with the "expect bug"
<lamont> so probably not a good idea to sync that one
<zul> later
#ubuntu-kernel 2005-04-10
<fabbione> morning guys
<lamont> there's also the question of why my vaio freequently has no batteries, according to acpi according to the kernel
<fabbione> lamont: i am sure mjg59 has an aswer to that
<lamont> probably
<fabbione> but i think it's a bit late for a fix
<lamont> yeah
<lamont> scary part is that I noticed it (figured I'd deleted a module or something), upgraded and rebooted, and it got better.  rebooted and it's back.
<lamont> nfc what's going on
<fabbione> weird
<fabbione> brb
<fabbione> re
<zul> hey
<zul> cool..http://kernelplanet.org/
<fabbione> hey
<zul> how is it gonig?
<fabbione> not too bad
<zul> giid...im stuck writing documenation
<fabbione> i should really spend time to add my blog somewhere
<fabbione> given that i can remember to actually blog :)
<zul> im not really into blogging
<zul> ill read them though
<fabbione> neither am i.. too much
<fabbione> interesting is the comment on memset
<fabbione> s/comment/blog/
<zul> yeah i found two in s390 scsi drivers in 2.6.12-rc1
<zul> i was thinking of patching the others that he found
<fabbione> not worth
<fabbione> we don't support s390
<zul> i know i was going to send it off to kj
<zul> i do have a life outside of ubuntu ;)
<fabbione> ehehe
<zul> heh...2.6.12-rc1-zul.patch
<zul> oh yah meeting today isnt there?
<fabbione> yeps
<zul> whee...im going to go try kubuntu
<zul> well thats ood..
<fabbione> let me tell ya
<fabbione> you need to select the session and switch it to KDE
<fabbione> otherwise you only get kdm and gnome
<zul> im running with kdm
<zul> how do i switch the session?
<fabbione> from kdm
<zul> ah ok...brb :)
<fabbione> ehhe
<zul> duh..
* fabbione laughs at 8396
<zul> everything is real big
<zul> fonts and stuff
<fabbione> zul: 8396 looks so much as pure crap
<zul> no info in the bug as well
<fabbione> clearly
<zul> lunch
<fabbione> hey guys
<fabbione> i need a name for -32
<fabbione> ah hell.. brb
<fabbione> re
<fabbione> hey T-Bone 
<fabbione> "Burning Biscuits"?
<fabbione> "Smelly sausages"?
<T-Bone> hey fabbione !
* T-Bone wonders what fabbione is talking about ;)
<fabbione> T-Bone: check the last changelogs in the kernel..
<fabbione> i am searching a name for -32
<T-Bone> ah ;)
<T-Bone> fabbione: well, if you could fix the concurrency stuff in modules btw... :)
<fabbione> "Radioactive Radish"
<fabbione> "Super Spinach"
<fabbione> T-Bone: ?
<T-Bone> fabbione: the mail i sent you before going on vacation
<fabbione> T-Bone: got no mails from you
<kylem> T-Bone, hmm, i see the same problem, i think
<fabbione> "Marvelous Marrow"
<fabbione> can anybody explain the problem to me?
<T-Bone> fabbione: Message-ID: <oN17ozdC.1111679287.0706720.varenet@localhost>
<T-Bone> To: Fabio Massimo Di Nitto <fabbione@ubuntu.com>
<T-Bone> Subject: kernel modules build
<T-Bone> Date: Thu, 24 Mar 2005 16:48:07 +0100
<fabbione> T-Bone: i don't have that mail....
<T-Bone> fabbione: now you have it (just forwarded again)
<fabbione> ah that's a bug in kernel package to maintain compatibility with 2.4
<fabbione> bug/feature
<fabbione> it depends how you want to see it
<T-Bone> err
<fabbione> but i think we are going to change that
<fabbione> T-Bone: on 2.6 it is enough to do make
<fabbione> and everything is built
<T-Bone> i don't understand how not compiling modules in a threaded way is a feature, nor how it preserves compat... :}
<fabbione> on 2.4 iirc you need to call make bzImage and make modules
<fabbione> therefor make modules is called twice
<T-Bone> right
<T-Bone> ah
<fabbione> but it's a mistake
<fabbione> easily fixable
<fabbione> -> breezy
<T-Bone> am i to understand that we really want our builders to spend time on kernels? :O)
<T-Bone> the patch frenzy, now the modules frenzy, gosh... ;}
<fabbione> T-Bone: if you really want to spend time on kernels just baz get the experimental branch and build on i386 :)
<T-Bone> err, no way ;)
<fabbione> so any suggestion for -32 release name?
<T-Bone> Terrible Tomato?
<fabbione> nah needs to be positive
<T-Bone> lol
<fabbione> Tripping Tomato :)
<T-Bone> LOL
<fabbione> as in "Tripping" when you are badly stoned :)
<T-Bone> yeah i got that :)
<fabbione> "Orgasmic Onion"
<fabbione> THERE!
<T-Bone> i love that one :)
<fabbione> which one?
<fabbione> i wrote a few tons :)
<T-Bone> the orgasmic one, of course ;)
<fabbione> lamont: what is your suggestion?
<lamont> hrm... kids aren't here to ask....
<T-Bone> lol
<T-Bone> kids don't read changelogs ;)
<fabbione> no.. but they can make good entries for it
<lamont> no, but they have really cool names, like atomic artichoke
<lamont> horny horse? nah
<T-Bone> lol
<fabbione> didn't we agree on vegetables for hoary?
<lamont> oh right, no meat
<T-Bone> hmm
<fabbione> we will need to find another category of food for breezy
<lamont> colorful carrot?
<lamont> bitchin' beet?
* lamont is rambling, not voting
* T-Bone votes for Orgasmic Onion ;)
<fabbione> i think the best 3 atm are:
<fabbione> "Orgasmic Onions"
<fabbione> "Tripping Tomatoes"
<fabbione> "Radioactive Radish"
<fabbione> "Super Spinach"
<fabbione> "Marvelous Marrow"
<T-Bone> that's 4
<T-Bone> 5
<fabbione> meh 5
<lamont> I like R and M bets
<lamont> best
* T-Bone would reduce the set to the first 3 which are (imho) very cool
* lamont votes radish
<lamont> afterall, the artichoke just blew up last release...
<fabbione> radish ++
<T-Bone> there you go then => Radish :)
<fabbione> actually.. -29 went out with meat
<fabbione> it was crispy chicken
<fabbione> anyway
<fabbione> Radish is
<lamont> nah - chickens are the vegitables of the animal world. :-)
<fabbione> ehheh
* T-Bone points lamont at some other window he's been consistently ignoring :)
<fabbione> i am releasing -32
<T-Bone> you are such a bad guy ;o)
<fabbione> i know :)
<T-Bone> =)
* fabbione starts the baz dance
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre33--2.6.10 playground: kernel-debian--experimental--2.6.10 | Get it orhttp://www.vijaygill.com/pics/stfu.gif | There are no kernel bugs.. only broken hardware | Kernel Team Meeting: see #ubuntu-meeting
<lamont> fabbione: does that mean that the RC bits are officially out?
<fabbione> pre33 is almost there :)
<lamont> s/RC/so-called RC
<fabbione> lamont: we can upload, so RC is closed
<lamont> ah, ok
<lamont> s/can upload/can upload after checking with god or his arch-angel/
<fabbione> lamont: well we have only one security fix for -32
<fabbione> and one ACPI mega urgent super grave fix
<lamont> right
<fabbione> pretty simple stuff
<fabbione> but yes, we need mdz clearance
<zul> hey T-Bone 
<T-Bone> hey zul 
<zul> how is it going
<T-Bone> quite fine. 5 days of ski did some good to me :)
<fabbione> -32 is on the way to jackass
<zul> good
<fabbione> that means that if we are lucky we will hit the next daily in 4 minutes
<fabbione> T-Bone: we have a kernel meeting this evening
<fabbione> at 20:00 UTC
<fabbione> just that you know
<T-Bone> fabbione: yeah i remember. thx for reminding me anyway :)
<T-Bone> fabbione: i'll be there
<fabbione> we lost the daily...
<zul> hmmm?
<fabbione> zul: nevermind.. it will just take 30 minutes more to see the kernel images on archive
<zul> ah] 
<fabbione> the -pre33 is ready
<fabbione> merging pre33 to experimental now...
<fabbione> let see how good is baz merge :)
<fabbione> ah nice bug
<lamont> hrm.. gues I better go to lunch if I have to be back online in 90 min
* fabbione fires up malone
<fabbione> lamont: the meeting is in 1:45
<lamont> yeah
<lamont> back in a while
<fabbione> sure
* fabbione -> food
<zul> frigging documentation
* T-Bone -> food
<zul> brb
<lamont> meeting in 14 minutes
<T-Gone> sigh, no time to watch an anime episode :}
<zul> slacker
<T-Bone> that's my surname :)
<T-Bone> s/sur/middle/
<zul> i know...
<zul> i was going to say something witty but i forgot
<T-Bone> HA HA HA HA
<T-Bone> your nastyness is eating your brain ;)
<zul> yes its called documenatation
<T-Bone> lol
<zul> spellchecker sucks
<fabbione> re
<zul> heyho
<fabbione> T-Slacker-Bone
<T-Bone> a bit long, but that's the idea ;)
<zul> that sounds dirty
<zul> brb
<fabbione> ehhe
<T-Bone> lamont: seen what i pasted elsewhere, btw?
<lamont> yeah
<T-Bone> ok
<zul> mmm....agua
<zul> i rather have caffine though
<lamont> so... ppc install... finished, reboots, hangs after telling me that it's loading the kernel...
<T-Bone> lamont: imac?
<lamont> iMac G3
<T-Bone> welcome to hell :)
<lamont> yes, with color
<T-Bone> =)
<T-Bone> i have a bondi blue imac
<T-Bone> i've never been able to install any linux distro on it
<T-Bone> and i fought hard
<zul> i blame t-bone
<lamont> T-Bone: warty installed just fine, thank you
<T-Bone> lamont: oh, then it's much better than what you claimed ;)
<lamont> then again this go round, the CD is throwing read errors...
<zul> right im going home...c ya around
<T-Bone> lamont: don't use vinyls to burn an iso ;)
<fabbione> lamont: i would try netboot :)
<lamont> T-Bone: made it clear through the install, this is on the first reboot
<lamont> fabbione: if I had a netboot image... must pester colin, or just go grab it.
<fabbione> anyway i need to crash
<fabbione> i am just way too tired
<fabbione> cya later
<lamont> later
<T-Bone> malloc: ../bash/unwind_prot.c:192: assertion botched
<T-Bone> malloc: block on free list clobbered
<T-Bone> Aborting...make: *** [configure-stamp]  Segmentation fault
<T-Bone> just *sweet*
<lamont> I've seen that..
<lamont> was either bash or glibc
<T-Bone> that's konserve, during autoconf
<lamont> you aren't being silly and running 2.6.8-SMP are you?
<T-Bone> i have an interesting evolution build failure as well. Looks like build-dep aren't restrictive enough, it fails on unsatisfied configure checks
<T-Bone> i am running 2.6.8.1 SMP, sure ;o)
<lamont> configure check failures are normal for many packages.
<T-Bone> as to me being silly, that's a matter for endless discussions ;o)
* lamont found that he got many fewer funky failures after going back to UP, declared 2.6.8.1 SMP to be unfit
<T-Bone> shit
<T-Bone> though it's true i had to retriger a few strangely failed packages
<lamont> interestingly, I notice that I'm now runing 2.6.10-4-hppa64
* lamont feels really brave, apt-get dist-upgrades his buildd real-root
<T-Bone> lamont: i did that without much issues
<lamont> yeah
<T-Bone> you'll see glibc updated ;)
<T-Bone> (if you use my archive, of course :)
<lamont> or mine
<T-Bone> tssks
<lamont> my archive tends to stay current, it's just very, um, partiall
<T-Bone> lol
<lamont> and since I'm already fetching source, building the .debs here keeps down my bandwidth abuse...
<T-Bone> well, mine should grow a bit faster, there's now two machines building
* lamont has an a500 and a b180...
<T-Bone> interestingly, one is running a 2.6.11 -pa kernel
<lamont> so, 1.1 machines. :-)
<T-Bone> lol
<T-Bone> i have a500 and l1000 both running smp
<T-Bone> and soon i'll have sweet beasts to back up (j6k)
<lamont> Linux b180.mmjgroup.com 2.6.10-3-hppa32 #1 Tue Feb 8 05:16:06 UTC 2005 parisc GNU/Linux
<lamont> Linux smallone 2.6.10-4-hppa64 #1 Sat Mar 12 04:41:16 UTC 2005 parisc64 GNU/Linux
<T-Bone> lamont: btw, did you ocmpletely drop my work on reducing the -pa patchset? :}
<lamont> patch files are there, I thought.
<lamont> they're there - just not used right now, because the 'slow as a dog' issues came in with the patch..
* T-Bone notices that atlas3 takes *ages* to build on the a500
<T-Bone> lamont: huhu
<lamont> 2.75 hours on sarti
<T-Bone> 2h45?
<T-Bone> or 3h+ ?
<lamont> 2:46 actually
* T-Bone notices the build is currently somewhere in the testsuite
<lamont> atlas3:                 02:46:44 (14 entries, sigma 00:32:28)
<lamont> so 3:15 wouldn't be surprising
<T-Bone> been building for 2h50
<T-Bone> lamont: btw, i'd welcome any stat script you'd hand over... :)
* lamont tries to remember what files he needs for netboot
<T-Bone> unfortunately i've never tried to netboot one of my ppc machines. I guess i'll ask you how to do that when the time comes ;)
<lamont> T-Bone: heh
#ubuntu-kernel 2006-04-03
<zul> heylo
<zul> heylo
#ubuntu-kernel 2006-04-04
<fabbione> dilinger: ping?
<dilinger> pong
<fabbione> yo
<fabbione> dilinger: multipath-tool question..
<dilinger> hiya
<dilinger> oh, i've never touched it
<fabbione> oh crap
<dilinger> sorry :)
<fabbione> dilinger: so the only person is waldi?
<dilinger> yea
<dilinger> i haven't really done anything w/ lvm2 since i gave the package to pjc
<fabbione> yeah
<fabbione> i will look at it with pjc
<dilinger> is he still working at sistina/redhat?
<fabbione> yes
<dilinger> cool
<fabbione> #linux-cluster here on freenode
<dilinger> i was gonna meet them (pjc, agk, and ejt) at one point, but i had a cold while they were in town
<fabbione> eheh
* lamont wonders what Lustre FS is, and if dapper's kernel has it...
<dilinger> lamont: lustre has been around for a while; the clusterfs people only recently started doing sane releases of it
<dilinger> some research group in sweden actually sent me their debian packaging for it, but i haven't had time to play w/ it
<lamont> dilinger: thanks
<dilinger> it splits apart metadata and data onto separate servers, and accesses each by objects
<dilinger> scales quite nicely
<dilinger> is there something like cg-admin-uncommit in just basic git?
#ubuntu-kernel 2006-04-05
<zul> heylo
<zul> where's BenC
<mjg59> Vacation this week, I think
<zul> ah ok..
<zul> so its a good reason to patch bomb him when it gets back ;)
<fabbione> mjg59: i upload wacom-tools that create the xorg driver too
<mjg59> fabbione: Cool, thanks
<fabbione> mjg59: it has the rotation patch as well.. you might want to fix init and udev rules
<mjg59> fabbione: Will do
<fabbione> great thanks
#ubuntu-kernel 2006-04-06
<Yagisan> G'day All. Upgrading from breezys amd64 kernel to dapper's as of 4 hours ago
<Yagisan> results in a non-bootable system. Last kernel message was
<Yagisan> PANIC Circular dependency - Exiting
<infinity> Yagisan: Can you "dpkg-reconfigure linux-image-(whatever it was)" and try again?
<infinity> Yagisan: Sounds like maybe your initramfs only got half updated (a bug I'll commit a fix for next week)
<Yagisan> infinity: I wish I could. but the old kernels don't boot either
<Yagisan> I'm waiting for a flight6 amd64 iso to download so I can chroot in
<Yagisan> hopefully
* Yagisan is loggin in via his firewall
<Yagisan> old kernels endlessly repeat "Segmentation fault"
<infinity> Ugh.  Fun.
<infinity> Well, when you manage to get an ISO and chroot in, let me know if that fixes it.
<infinity> This one's looming large on my radar for things I need to fix before we release and masses statr dist-upgrading (for obvious reasons)
<Yagisan> will do. 100MB to go, then to put a burner on the firewall.
* #ubuntu-kernel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
<Yagisan> infinity: you were right earlier about the initramfs not being correctly generated. I've managed to get the system to boot now, and am cleaning up other upgrade breakage. Thanks for your help.
<zul> heylo
<BenC> yo
<zul> hey BenC how is it going?
<BenC> not too bad
<BenC> trying to get all these patches together so I can release a new kernel
<zul> good vacaction?
<BenC> I might just skip all these new ones since current build is pretty good
<BenC> yeah, pretty decent, I pulled over $1500 playing cash games
<zul> i should have a couple of more patches for you next week as well
<zul> nice..
<BenC> too bad I didn't do well in the $600 tourney, or I'd actually made a profit
<zul> hehe..
<BenC> broke even, considering all my costs and the $900 profit from playing, so it wasn't a waste
<zul> atlantic city?
<zul> oh yeah, im quiting my job as well..
<zul> holy fake boobs batman
<zul> this 15 year old has bigger boobs than my feet..
<crimsun> BenC: sorry about the spam. The latest patch to add a 'Jack Sense' blacklist entry was created against the wrong git branch locally (missing a previous Jack Sense addition), so you'll have to hand-apply whenever you apply it.
<BenC> ok
<BenC> zul: nah, I went to foxwoods this time, there was a WPT tournament series
<zul> BenC: coolio
<fabbione> hey BenC !
<fabbione> BenC: can you please pull from me before you upload?
<fabbione> BenC:  i have a few important fixes.
<fabbione> BenC: there is also a patch from mjg59 to fix ACPI that we must get in for -20-
<fabbione> BenC: it fixes a few tons of regressions and makes the world happy again
<fabbione> BenC: expect soon an e1000 driver backport from .16
<fabbione> the one we have in .15 is crashorama on my |Viagara
<infinity> BenC / fabbione : You guys mind if I add myself to the LP kernel-team, since I do the LRM junk and whatnot?
<infinity> fabbione: The Niagara uses Intel ethernet?
<fabbione> infinity: sure you can add yourself.. or i can add you..
<fabbione> infinity: the T1000 comes with tg3, the t2000 with e1000
<fabbione> infinity: done
<infinity> Yeah, I can add myself to any team due to being an LP admin (still, argh), but I prefer to ask. :)
<fabbione> ehhehe
<infinity> Also, whacky on the Intel NIC in sparc box.  Never thought I'd see the day.
<fabbione> well they have no reason to develop their cards anylonger
<fabbione> they have a pci-x and pci-e in that box
<infinity> No, true, but they always seemed to pick weird vendors anyway (like all the godawful ALI chipsets on the SunFire stuff)
<fabbione> they still use ALI for the only ide cdrom
<fabbione> anyway food...
<infinity> Also, do either of you have ATI video hardware?  If so, I've been forwarded an offer to get in the fglrx beta program.
<fabbione> just arrived :)
<infinity> I'll sign up and test on my laptop, but if you guys want to be in on it and test crap, let me know.
<fabbione> i know davem does
<fabbione> i don't
<fabbione> you mean on sparc?
<infinity> I doubt they'll build fglrx on sparc.  I mean on i386/amd64
<fabbione> or just x86?
<fabbione> nah
<fabbione> i have no interest
<fabbione> thanks
<fabbione> later
<infinity> Kay.
<infinity> Later.
<infinity> BenC: Let me know if you want in on the fglrx beta program.  If so, I'll let ATI know.
* infinity heads to bed.
<BenC> infinity: Only ATI hw I have is PPC, so unless they have a PPC-linux beta, then no thanks :)
* cjb is all for people shunning ATI.
#ubuntu-kernel 2006-04-07
<fabbione> BenC: please pull me.. i have other fixes for you, including sparc stuff from davem and actually build linux-kernel-devel for real
<fabbione> BenC: the sparc fixes also make gdb working on threaded apps
<BenC> fabboine: ok
<fabbione> oh you are awake :)
<fabbione> BenC: sorry to pester you, did you get the ACPI fix from mjg59 ?
<fabbione> if not i have the patch here
<BenC> yeah, I have it
<BenC> was out of town Wed/Thu, so I'm a bit behind
<fabbione> yeah i know you were out :)
<fabbione> great
<fabbione> thanks a lot
<fabbione> did you have fun?
<BenC> yeah
<BenC> I missed my train to come back on Thu though, so I didn't really get in till Friday morning :)
<BenC> made some cash, played a tourney, was all good
<fabbione> eheh
<fabbione> you are addicted to miss trains :)
<BenC> no shit :)
<BenC> bad part is, the train there killed a guy, so I got hung up for about 5 hours while they cleaned that up
<fabbione> ah
<fabbione> suicide?
<fabbione> or mistake?
<BenC> not sure, it was on a part of the track where if he jumped off, he would have died at the bottom anyway, so he might have just been in the wrong place at the wrong time
<fabbione> ok
<BenC> was a creepy feeling after we found out that the crunching and bumping noise we just felt under the car was not rocks
<fabbione> i can imagine
<BenC> the conductor was like "That's what he gets for trespassing"
<BenC> I think death is a little strong for tresspassing :)
<fabbione> eheh
<kosnick> sorry to interupt i am a newbie and i would like to see the code from ubuntu, just curius. Is it possible to do that on my computer?
<crimsun> sure, but you're asking in the wrong channel.
<crimsun> please migrate to #ubuntu, and I'll assist you.
<kosnick> which one plz?
<kosnick> ok
<kosnick> thx
<mjg59> BenC: So, do we get lots of patch goodness this week/
#ubuntu-kernel 2006-04-08
<fabbione> BenC: i just pushed the e1000 fixes from .16 into my tree
<fabbione> they fix the driver hang i was experiencing here every 30 secs
<fabbione> BenC: ping?
<zul> heylo
<zul> BenC: the ipw3945 driver im working is partially working it just cant find the ieee80211 header files.
<BenC> fabbione: ok, I'll pull again
<fabbione> BenC: great thanks
<fabbione> BenC: i also have some issues about ioctl32
<fabbione> i am testing a patch right now, but i need you to review it
<fabbione> i think you are familiar with that problem since you use ioctl32 compat stuff in firewire too
<BenC> yeah, ioctl32 is pretty sticky stuff
<fabbione> BenC: well the point is that the entire redhat-cluster-suite seems to require that kind of love
<fabbione> i did try to stub them
<fabbione> some of them seems to work
<fabbione> other don't
<BenC> guessing some of them need real conversions
<fabbione> example:
<fabbione> #define SIOCCLUSTER_ISACTIVE          _IO( 'x', 0x0b)
<fabbione> HANDLE_IOCTL(SIOCCLUSTER_ISACTIVE, do_cluster_ioctl)
<fabbione> static int do_cluster_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
<fabbione> {
<fabbione>         return sys_ioctl(fd, cmd, (unsigned long)compat_ptr(arg));
<fabbione> }
<fabbione> this one seems to work just fine
<fabbione> #define SIOCCLUSTER_SET_NODENAME      _IOW('x', 0x0b1, char *)
<fabbione> HANDLE_IOCTL(SIOCCLUSTER_SET_NODENAME, do_cluster_ioctl)
<fabbione> this one gives me:
<fabbione> ioctl32(cman_tool:5880): Unknown cmd fd(3) cmd(800478b1){00} arg(ff8f37d8) on socket:[11451]    
<fabbione> but the cmd is there..
<fabbione> so i am a bit puzzled
<fabbione> BenC: http://people.ubuntu.com/~fabbione/cluster-ioctl32.diff this is what i have now
<BenC> are you sure oxb1 is right?
<BenC> 0x0b1 I mean
<BenC> well, I guess 0x0b1 was already in the code
<fabbione> i include directly cluster/cnxcman-socket.h
<fabbione> so i yes
<fabbione> so i think they are correct :)
<fabbione> given they work on all other arches :)
<fabbione> it's only sparc64 suffering of this problem
<fabbione> afair not even hppa was complaining
<fabbione> but i might be wrong
<fabbione> i need to go out for about 30 minutes
<BenC> I think I know why
<BenC> it's the char *
<fabbione> if you can give it a look or a fix, i will test it when i am back
<fabbione> ok i will read when i am back :)
<fabbione> thanks Ben
<BenC> you  may want to handle this differently
<BenC> is this operating on a device file with file_ops?
<fabbione> BenC: code here is cluster/* and fs/gfs*
<fabbione> i am not sure how i want to operate...
<fabbione> personally i don't even care... it needs to work :)
<BenC> yeah, it is
<BenC> look in cluster/cman/cnxman.c
<BenC> and then follow what was done in drivers/ieee1394/dv1394.c
<fabbione> i really need to go
<fabbione> i will look at it later
<BenC> the compat_ioctl entry 
<BenC> ok
<BenC> I think I did the same for one of the acpi drivers
<fabbione> note that these are socket operation
<fabbione> +s
<fabbione> there are also files_ops
<BenC> yeah, the file ops should handle it I believe
* cjb wonders what the chances of the Yi Yang fs events connector patch getting into dapper+1 are.
<fabbione> re
<fabbione> so BenC you suggest to remove that patch and go for what's in dv1394.c?
<BenC> yeah
<fabbione> i can try..
<fabbione> but see. there is no file_operations there
* fabbione scratches his head
<fabbione> static struct proto_ops cl_proto_ops = {
<fabbione>         .ioctl       = cl_ioctl,
<fabbione> }
<fabbione> cl_ioctl is the func that knows what userland is calling
<fabbione> userland is in redhat-cluster-suite source cman/cman_tools/join.c
<fabbione>     error = ioctl(cluster_sock, SIOCCLUSTER_ISACTIVE);
<fabbione> it's like SIOCCLUSTER_ISACTIVE is not exported to 32bit userland
<fabbione> but proto_ops doesn't have .compat_ioctl
<fabbione> (from include/...)
<BenC> hmm
<BenC> I'd have to take a closer look then
<fabbione> BenC: yeah.. i can't get in it
<fabbione> no more than what i showed to you
<zul_> wq
<zul_> damn it
* fabbione waves to zul
<zul_> hey fabbione how is it goinng?
<fabbione> okish
<zul_> thats good..
<fabbione> i just powered down the SAN
<fabbione> i was getting almost stupid from the noise
<zul_> thats why you wear earphones when you work..
<zul_> i went home for lunch..yippe skippe
<fabbione> it doesn't help
<fabbione> not when a 19" x 6ft racks is completely powered on 3 feet behind you
<zul_> meh...you need your own data center
<fabbione> did you see the last evolution in my office?
<fabbione> the desktop extender?
<zul_> nope i havent
<fabbione> http://people.ubuntu.com/~fabbione/office/second_layer2.jpg
<fabbione> http://people.ubuntu.com/~fabbione/office/second_layer.jpg
<zul_> lol...my wife would kill me
<fabbione> my wife did look at it for 10 seconds in religious silence...
<fabbione> then i looked her and told her: "Why i am so sure you don't like it?"
<fabbione> she answered: "If it wasn't for the fact that all this junk bring us food, i would have never married you"
<fabbione> so to say, she didn't like it
<zul_> lol
<fabbione> anyway.. food time
<fabbione> i am hungry
<zul_> ok i dont like the launchpad changing of descriptions
#ubuntu-kernel 2006-04-09
<zul> heylo
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-20.30 uploaded (Mondo) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<fabbione> BenC: great man!
<fabbione> BenC: finally we can have gdb working on sparc :)
<BenC> fabbione: cool
<fabbione> for threaded apps ;)
<mjg59> BenC: We should have an sdhci update after the weekend
<mjg59> The sdhci spec got publically released, so now it can be fixed up
<fabbione> mjg59: hey dude
<fabbione> mjg59: i did reassing the wacom-tools init script bug to you
<fabbione> could you be so kind to give it a shot?
<mjg59> fabbione: Yeah, I'll take a look soon
<fabbione> mjg59: rthanks a lot
<BenC> mjg59: ok
<BenC> yay, I see pnp devices again
<torkel> BenC: are you busy or do you have a couple of minutes to take a log at a bugreport that might be a kernel bug?
<torkel> I'm not sure if it is a bug in the openafs kernel module or the kernel and I don't have any PPC64 to test and try on :-(
<BenC> torkel: bug #?
<torkel> BenC: 37661
<torkel> it is in the config.log attachment
<BenC> torkel: it's the build's fault
<BenC> it's not using the right cflags
<torkel> ok
<BenC> it really needs to be getting CC and CFLAGS and such from the kernel build to alleviate this problem
<BenC> but as a quick patch, ppc64 should be using -m64
<BenC> the problem is default cc produces 32-bit code, and obviously for ppc64 you need 64-bit :)
<torkel> even om 64-bits machines? 
<BenC> userspace on ppc64 is still 32-bit so the default is correct
<BenC> ppc and ppc64 use the same userspace
<torkel> ah
<BenC> all of this should be invisible to the openafs build, which is why using the kernel build stuff would be best
<torkel> You mean module-assistant should be fixed?
<BenC> whatever produced that log needs to be fixed :)
<torkel> Looks like it is already filed in debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334392 :-)
<torkel> anyway thanks a lot
#ubuntu-kernel 2007-04-02
<zul> hey
<_ion> Hi
<glick> hi
<glick> hey is it hard to build the kernel in eclpise?
<glick> eclipse?
<glick> has anyone done any kernel dev with eclipse?
<glick> damn, kernel development on my main machine is dangerous isnt it
<superm1> BenC, did you get a chance to look over lirc patch i made this past week?
<glick> hey im tryin to config a vanilla kernel
<glick> its asking me at what physical address i want to load the kernel and i have no idea what i should put
<crimsun> superm1: he's EDT, which is -0400 UTC. It's currently 3:43 AM.
<superm1> crimsun, ah ok thx
<superm1> crimsun, which reminds me - i should get to bed (i'm CDT :) )
<glick> hey does anyone use eclipse for kernel dev?
<fabbione> glick: please stop asking every hour.. people lives in different TimeZones and it can take over 24 hours to get an answer here
<glick> fabbione, new people came in
<glick> i thought they might know
<crimsun> glick: well, the answer to your question is "yes". When I worked at IBM, quite a few people did (unsurprisingly). As for whether anyone present does, it's fairly unlikely.
<fabbione> most of the kernel developers are in the US and won't be around for the next 5/6 hours
<glick> you just use vim?
<fabbione> i personally do yes
<glick> but isnt that difficult if you need to cross check a symbol reference, or check the definition of a function or see what calls it?
<crimsun> no, you can use ctags.
<fabbione> matter of taste.. and i use grep...
<fabbione> really.. developing is a matter of taste
<fabbione> everybody has its own
<fabbione> there is no standard
<glick> so for someone new lookin to get grok the kernel should they look at vanilla or ubuntu kern?
<fabbione> glick: it depends what you are going to do
<fabbione> what do you plan to develop on the kernel?
<glick> drivers mainly at this point
<fabbione> new drivers or fixing bugs in existing ones?
<glick> yeah both
<fabbione> i would personally do it on vanilla because no matter how quickly we keep up with upstream, at some point in time our kernel is behind
<fabbione> and driver interfaces might change in the meantime
<fabbione> but nothing stops you to use both trees
<fabbione> develop a fix in vanilla and push the patch to the ubuntu kernel
<fabbione> it's fairly simple to do cherry picking with git
<fabbione> anyway.. brb
<glick> k
<pkl_> glick: couple of answers....  The kernel physical location should be 0.  I personally use vim and grep.
<pkl_> glick: unless you're working on drivers which Ubuntu has put into the driver (Ubuntu top-level directory), it doesn't really make much difference whether you're using the vanilla or Ubuntu version.  Ubuntu's kernel follows vanilla very closely.
<maks_> pkl_ following closesly with a huge stack of patches on top
<glick> pkl_, i thought < 16M was DMA pool?
<crimsun> maks_: we don't touch the scheduler or the network stack, really, for starters.
<crimsun> or the vm or many fses
<pkl_> most of of Ubuntu's changes are in driver code.  Very little core code is touched.  Doesn't need to be, the core code is generally very stable and well written.  It is the drivers which are a mess, and need to be patched :)
<maks_> plus adding oot mess :P
<pkl_> glick: I should have asked which arch you're using :) PPC kernel physical address 0x0.  x86 phys address 0x00100000.
<glick> x86
<pkl_> I tend to use PPC (PowerPC) when talking about kernels internals.
<pkl_> The x86 is the odd architecture, most architectures load at 0.  The x86 is 'special' because of BIOS and weird legacy restrictions (the 640KB -> 1MB hole).
<glick> you do your dev on ppc?
<pkl_> I used to (until last November).
<fabbione> hey pkl_ 
<fabbione> pkl_: how are your cluster testing going?
<glick> damn eclipse is slow
<glick> night
<pkl_> fabbione: badly, too much work, too little time :)
<fabbione> pkl_: what about tomorrow we setup an Oracle and one RH cluster together?
<fabbione> pkl_: so that i can kick you off the first step
<pkl_> fabbione: sounds good.  I'll see what else I've got to do on Tuesday.
<fabbione> pkl_: just make sure you have 2 feisty machines uptodate.. no matter if they are desktop or server installs..
<fabbione> then we figure it from there
<fabbione> (better if they are in the same LAN/subnet)
<shawarma> initramfs-tools is the kernel-team's "problem", no?
<maks_> shawarma : yes
<maks_> why what's up?
<shawarma> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/101844
<shawarma> It's easily reproducable. With a Feisty userland, run an Edgy kernel, run "update-initramfs -u" twice, and that's the last time you'll ever boot with that kernel.
<maks_> shawarma the bak file should only get updated if there is a boot inbetween
<shawarma> maks_: eh? the bak file is created by update-initramfs.
<maks_> yes but only once
<shawarma> per run of update-initramfs, yes.
<maks_> no
<maks_> shawarma can you attach please an sh -x update-initramfs -u run
<maks_> i have only debian boxes
<shawarma> maks_: Why would it not be updated with each run of update-initramfs?
<shawarma> maks_: I need a minute to fire up the machine again.
<maks_> shawarma look into backup_booted_initramfs
<maks_> if it does what you say there is a bug there
<maks_> shawarma: no hurry, but interested :)
<maks_> ah it does exchange it because you rebooted inbetween
<maks_> but it shouldn't do it now if you execute it 2x in a row
<maks_> please post also the second sh -x update-initramfs run
<shawarma> maks_: What exactly should stop it?
<maks_> it only mv ak overwrites the .bak if boot_initramfs is defined
<maks_> did you look at backup_booted_initramfs()?
<shawarma> briefly. I thought it ran backup_initramfs
<maks_> you want to checkout the section below "# keep booted initramfs"
<shawarma> maks_: The fact remains that I end up with a trunced initrd, and the attached fix fixes it.  My analysis of why it goes wrong may be off, though.
<maks_> shawarma np, please provide the further output
<shawarma> the output of the two runs are identical.
<maks_> sh -x update-initramfs
<maks_> upps of course with -u
<shawarma> Sure
<maks_> i'd really appreciate if you attached that to the bug report :)
<shawarma> Will od.
<shawarma> do, even.
<shawarma> done.
<maks_> shawarma hmm this is your hacked update-initramfs
<shawarma> No
<shawarma> oh, wait.
<maks_> shawarma it's ok i ack your patch
<shawarma> what the.. I dpkg -i the initramfs-tools in my apt cache and it's still my patched u-i..
<maks_> adding it to the debian repo atm and i'll remind BenC when he is around
<shawarma> Cool.
<shawarma> thanks.
<maks_> won't push it for etch updates as in debian nobody uses the minversion, so i never saw that
<maks_> thank you
<shawarma> Any time.
<shawarma> How do you work around udev's dependencies without it?
<shawarma> There. updated the bug with proper logs. Silly me.
<maks_> shawarma: we had no "real" udev upgrade now as sarge relied still on the hotplug scripts and currently i manage that by depending on newer udev simply
<maks_> (speaking for the debian side of udev upgrades)
<maks_> shawarm: please next time fix your patch to run diff -pruN initramfs-tools-0.85eubuntu8 initramfs-tools-0.85eubuntu9, then it can be easier applied from topdir i-t and -p is cool for showing modified functions, just as quick hint :)
<maks_> s/shawarm/shawarma/ uups ^^
<Nafallo> debdiff ftw
<shawarma> maks_: Er.. Ok. I've always just used debdiff. I'll keep it in mind.
<zul> BenC: ping
<BenC> zul: pong
<maks_> BenC i guess you have followed aboves backlog related to LP: #101844
<zul> BenC: I should have the openvz tonight
<BenC> maks_: no
<maks_> BenC: ok so in short i ack the patch in aboves report
<maks_> added the code to debian repo
<BenC> maks_: Ok, thanks
<jammcq> hey guys, i'm trying to track down a performance issue with a thin client. I'd like to build a kernel without debugging to see if that has any effect.  I've built several kernels using the Ubuntu wiki page, and i've had great success.  But if I try setting 'CONFIG_DEBUG_KERNEL=y' or '# CONFIG_DEBUG_KERNEL is not set', I get an error after about 40 minutes saying:   "module has gone missing: dccp_probe"
<jammcq> err, s/=y/=n/
<zul> happy joy joy
<mathrick> hi, why doesn't Feisty let me eject mounted CDs anymore? It was there in edgy, and disappeared in feisty
<mathrick> AFAIK, it was some kind of kernel patch (not surprisingly), so whatever happened to that?
<zul> BenC: ping is it ok if the openvz creates a linux-image.deb?
<newz2000> I want to try and help get my bugs fixed, how do I test the -14 kernel?
<newz2000> oh, there's a link to the wiki...
* newz2000 tries that first
<newz2000> ok, I give up... how do I try out the 2.6.20-14.22 kernel?
<Nafallo> oh. kewl
<Nafallo> 14 is out :-)
<newz2000> Nafallo: do you know where those are stored?
<Nafallo> oh, new ABI... so in the NEW-queue :-(
<Nafallo> should be a way to find them on launchpad though :-)
* newz2000 tries to suspend...
<Nafallo> https://launchpad.net/ubuntu/+source/linux-source-2.6.20/2.6.20-14.22
<Nafallo> then click on the corresponding buildlog for your architecture
<Nafallo> oh. still builds...
<Nafallo> anyway, if it's finished you just click the resulting binary -)
<maks_> how can i in list all initramfs-tools bug reports in launchpad?
<Mithrandir> maks_: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/
<newz2000> I've got two outstanding problems I'm eager to help fix... both work in past kernels
<maks_> Mithrandir thx
<newz2000> no sound --> works fine when I boot into 2.6.17 and can't suspend --> works fine in 2.6.20-12
<crimsun> "no sound" isn't quite helpful.
<newz2000> I've got a bug report, looking for it now
<newz2000> crimsun: #92171
<crimsun> bug 92171
<crimsun> oh, right, bot thing.
<newz2000> crimsun: a moment ago I booted into 2.6.17-10 and the sound worked great
<newz2000> now in 2.6.20 with every volume control full blast its a faint whisper
<newz2000> alsamixer has a "master" volume control but I can't change it... it has no bar graph, and the numbers stay at 00
<crimsun> yes, that's the ff10 change.
<crimsun> I'll just revert it for Feisty, and we'll live with whatever breaks for the newer laptops.
<crimsun> "it" -> addition of ALC66x/86xVD support, aka WildWets
<crimsun> WildWest, even.
<crimsun> the "no audio on resume" issue is known, and it won't be fixed for Feisty.
<newz2000> I think with the most recent edgy kernel that went away for me
<newz2000> crimsun: I don't suppose you're able to help at all with bug 96679 are you?
<newz2000> acpi related
<newz2000> it works great in -12, but not in -13
<crimsun> newz2000: not my realm, sorry.
<newz2000> ok. Is this the right place? Or does acpi stuff go to a different irc channel?
<crimsun> this is the right place.
<mjg59> So going back to -12 definitely results in it working?
<newz2000> mjg59: yes, tested a few minutes ago
<newz2000> in -11 I could only suspend once, after that shutting my laptop just locked the screen. But with -12 I could open and close as much as I wanted.
<newz2000> -13 results in a hard lock when I shut the lid
<newz2000> mjg59: if there's any info I can provide you, I have some time to test now
<mjg59> Weird. Nothing in the changelog that looks even vaguely relevant.
<mjg59> Can you try:
<mjg59> Going to a console, becoming root, and doing echo -n mem >/sys/power/state
<mjg59> And then letting me know what happens
<newz2000> mjg59: running that command caused my computer to suspend immediately. When I resumed, the screen didn't come back on. However, it appears the computer did a graceful shutdown when I hit the power button.
<newz2000> it sounded like my computer was working though
<mjg59> Ok. So that makes it sound like the kernel isn't too much of a problem.
<newz2000> do other things change when I boot into a different kernel with grub?
<mjg59> So, next thing - can you edit /etc/default/acpi-support
<mjg59> And change USE_DPMS to false
<mjg59> Then edit /etc/acpi/sleep.sh
<mjg59> And just above where it says DeviceConfig add a line saying
<mjg59> set -x
<mjg59> Then, again at a console as root, do /etc/acpi/sleep.sh force
<newz2000> ok, here it goes
<newz2000> mjg59: ok, that time the screen went to a blinking cursor in the top left, it never suspended. After a minute I hit Alt+F1 and got a console login. I hit Alt+F7 and then my computer appearded to freeze, I had to hold the power button in to shut down
<mjg59> newz2000: Ok. Can you do that again, do the alt+f1 thing, do dmesg >~/dmesg.out, ps aux >~/ps.out, sync, reboot and then put those files up somewhere?
<newz2000> sure
<newz2000> what was the command I ran before?
<newz2000> oh, found it
<newz2000> brb
<newz2000> mjg59: that time it worked fine
<mjg59> newz2000: Ok. Repeat until it breaks :)
<newz2000> ok
<newz2000_> mjg59: ok, that time it broke.
<mjg59> newz2000_: Excellent
<newz2000_> Alt+F1 switched me to a console, but I couldn't log in. My keyboard only allowed Alt+F1-AltF7. 
<newz2000_> Alt+F7 again froze the computer and I could do nothing
<mjg59> Ok. Edit /etc/acpi/suspend.d/75-console-switch.sh and comment out the "chvt 12" line
<mjg59> You're triggering the suspend from the console, not X, right?
<newz2000> no, I'm in x
<newz2000> should I try it from a console before I do this?
<mjg59> Yes, you have to do this from a console
<mjg59> But make that change first
<newz2000> ok
<mjg59> Basically, I want to know what the last few lines of output are
<newz2000> mjg59: ok, I thought I could tee the output of that, but apparently not...
<newz2000> near the end I got two alsa errors (command not found) then the last thing was a for loop... I think it was refering to for SCRIPT
<newz2000> amixer command not found twice
<newz2000> (amixer errors were followed by the for loop)
<newz2000> is that detailed enough? If not, I may be able to redirect stderr to stdout and try tee again
<mjg59> Can you boot without the "quiet" option and try again?
<mjg59> And also edit /etc/acpi/suspend.d/90-framebuffer-stop.sh and comment out everything in it
<newz2000> yep
<newz2000> finally, a graceful reboot. :-) brb.
<newz2000> mjg59: ok, I'm back
<mjg59> newz2000: Excellent
<mjg59> newz2000: Had a chance to test that?
<newz2000> mjg59: test what?
<newz2000> what was I supposed to do after I rebooted? I must have missed an instruction
<mjg59> 21:40 < mjg59> And also edit /etc/acpi/suspend.d/90-framebuffer-stop.sh and  comment out everything in it
<newz2000> yes, I did that too
<mjg59> Then, from a console, do /etc/acpi/sleep.sh force
<newz2000> oh, ok. just a min, will try
<newz2000> mjg59: got it. The last bits are:
<newz2000> ++ . /etc/acpi/suspend.d/85-alsa-state.sh
<newz2000> +++ '[' -x /etc/init.d/alsa-utils '] '
<newz2000> +++ /etc/init.d/alsa-utils stop
<newz2000>  * Shutting down ALSA...                                                        amixer: Invalid command!
<newz2000> amixer: Invalid command!
<newz2000>                                                                          [ OK ] 
<newz2000> ++ for SCRIPT in '/etc/acpi/suspend.d/*.sh'
<newz2000> ++ . /etc/acpi/suspend.d/90-framebuffer-stop.sh
<newz2000> + '[' x = xtrue '] '
<newz2000> + echo -n mem
<mjg59> And then it hangs?
<newz2000> yes
<newz2000> I can still Alt+F? but thats it
<mjg59> Ok. Now you get to go through each of the files in /etc/acpi/suspend.d and see which of them is breaking it...
<newz2000> and if I hit Alt+F7 I'm really stuck
<newz2000> :-)
<newz2000> so for each, should I just put a little echo statement to differentiate them? See which one is last
<mjg59> No, they're all running
<mjg59> Disable each of them in turn
<newz2000> whats the best way to disable, rename to *.sh~ or comment out the lines or something else?
<mjg59> Yeah, change the name so they don't end in .sh
<newz2000> ok
<newz2000> ok, trying again, brb I think. :-)
<newz2000> mjg59: that was easy... with all disabled, it still freezes. Just much sooner this time.
<mjg59> newz2000: But echo -n mem >/sys/power/state always works?
<newz2000> well, we tried it that one time adn it went ok (except I couldn't resume)
<mjg59> Yes
<mjg59> At this point, that should be basically all that the script is doing
<mjg59> Can you try it a few more times?
<newz2000> try echo -n mem >/sys/power/stat
<newz2000> ?
<newz2000> mjg59: btw, here's the output of /etc/acpi/sleep.sh force  http://people.ubuntu.com/~mnuzum/tmp/sleep.txt (with a.. .sh disabled)
<newz2000> trying echo -n...
<mjg59> newz2000: Looks like it's doing pretty much nothing other than the echo
<newz2000> mjg59: ok, echo -n mem didn't work... I got stuck at the console again with only Alt+F? working
<mjg59> Ok. So it's the kernel.
<mjg59> When you get to that point, can you do alt+sysrq+t and see what shows up?
<newz2000> sure, never done that before
<newz2000> mjg59: sorry for delay, fsck had to run. Alt +SysReq + t didn't show anything
<mjg59> Hm. Ok, all I can suggest is trying -14 when it hits the archive
<newz2000> ok. mjg59 any idea when thats coming?
<mjg59> Next few hours
<mjg59> It's uploaded, just needs to finish building and get through NEW
<newz2000> cool, that gives me something to look forward to
<newz2000> Guess I'll undo all our changes then
#ubuntu-kernel 2007-04-03
<crimsun> newz2000: if you're still present, I need /proc/asound/card0/codec* pastebinned/added to #92171
<newz2000> crimsun: you just caught me, sure thing
<newz2000> crimsun: there are no codec*
<newz2000> oh wait
<crimsun> there must be.
<newz2000> I forgot the ls at the beginning and tab completion was looking for executable files
<newz2000> crimsun: done
<newz2000> if you need more, let me know, I'll be back for just a little bit in 30 min, then again for longer in a few hours
<crimsun> ok, looking now.
<crimsun> I'll likely need you to test some kernel modules
<crimsun> newz2000: please ping me when you return, thanks.
<pradalover> I need some help
<pradalover> my sound isn't working
<newz2000> crimsun: I'm here, are you still around?
<crimsun> newz2000: hi
<crimsun> give me a sec to log in
<newz2000> crimsun: hey! sure
<crimsun> newz2000: can you try the following, please?  kill $(lsof -t /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*) ; sudo modprobe -r $(lsmod |grep ^snd |awk '{print $1}') && sudo modprobe snd-hda-intel model=auto
<newz2000> crimsun: do I need to save my work before I do this?
<crimsun> newz2000: it's a good idea, yes, but I don't anticipate it exploding
<newz2000> ok, two things hapened...
<newz2000> volume control applet died unexpectedly...
<crimsun> the mixer applet should pop up a notification bubble
<crimsun> right
<newz2000> FATAL: Error inserting snd (/lib/modules/2.6.20-13-generic/kernel/sound/core/snd.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<newz2000> WARNING: Error running install command for snd
<newz2000> WARNING: Error inserting snd_timer (/lib/modules/2.6.20-13-generic/kernel/sound/core/snd-timer.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<newz2000> FATAL: Error inserting snd (/lib/modules/2.6.20-13-generic/kernel/sound/core/snd.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<newz2000> WARNING: Error running install command for snd
<newz2000> WARNING: Error inserting snd_timer (/lib/modules/2.6.20-13-generic/kernel/sound/core/snd-timer.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<newz2000> FATAL: Error inserting snd_pcm (/lib/modules/2.6.20-13-generic/kernel/sound/core/snd-pcm.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<newz2000> WARNING: Error running install command for snd_pcm
<newz2000> WARNING: Error inserting snd_hda_codec (/lib/modules/2.6.20-13-generic/kernel/sound/pci/hda/snd-hda-codec.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<newz2000> FATAL: Error inserting snd_hda_intel (/lib/modules/2.6.20-13-generic/kernel/sound/pci/hda/snd-hda-intel.ko): Unknown symbol in module, or unknown parameter (see dmesg)
<crimsun> ah, blarg
<newz2000> wow, tht's a lot
<crimsun> kill $(lsof -t /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*) ; sudo modprobe -r $(lsmod |grep ^snd |awk '{print $1}') && sudo modprobe snd-hda-codec && sudo modprobe snd-hda-intel model=auto
<newz2000> lsof: status error on /dev/dsp*: No such file or directory
<newz2000> lsof: status error on /dev/audio*: No such file or directory
<newz2000> lsof: status error on /dev/mixer*: No such file or directory
<newz2000> lsof: status error on /dev/snd/*: No such file or directory
<newz2000> lsof 4.77
<newz2000>  latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
<newz2000>  latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
<newz2000>  latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
<newz2000>  usage: [-?abhlnNoOPRstUvVX]  [+|-c c]  [+|-d s]  [+D D]  [+|-f] 
<newz2000>  [-F [f] ]  [-g [s] ]  [-i [i] ]  [+|-L [l] ]  [+m [m] ]  [+|-M]  [-o [o] ] 
<newz2000>  [-p s]  [+|-r [t] ]  [-S [t] ]  [-T [t] ]  [-u s]  [+|-w]  [-x [fl] ]  [--]  [names] 
<newz2000> Use the ``-h'' option to get more help information.
<crimsun> yeah, that's ok.
<newz2000> kill: usage: kill [-s sigspec | -n signum | -sigspec]  pid | jobspec ... or kill -l [sigspec] 
<crimsun> it should still continue with modprobe -r
<crimsun> you can verify with:  lsmod |grep ^snd_hda_intel
<newz2000> yeah, I got a line returned from that
<newz2000> snd_hda_intel          21912  0 
<crimsun> great.
<crimsun> Is `aplay /usr/share/sounds/*up.wav' audible?  (It may not be; you may need to adjust the element levels using `alsamixer')
<newz2000> I got audible sound!
<crimsun> ok, how is the perceptive loudness?
<newz2000> ooh, more sounds
<crimsun> i.e., is it 2.6.20-8.14-"loud"?
<newz2000> Fortunately my laptop has a physical volume control. :-)
<crimsun> sorry, but I can't interpret whether that means the perceptive loudness regression is still present with model=auto
<newz2000> sorry, I thought you were making a joke... I think the sounds is excellent now
<crimsun> ok, then that's a fairly straightforward one-line revert. Thanks for confirming.
<newz2000> sweet
<crimsun> (Sorry it has taken so long; I've been swamped with work.)
<newz2000> no problem, I'lm glad to have a solution in the pipe line. Thought I might have to live with edgy for ever. :-)
<dac_> when online, after 10 mins. or so, the page freezes up, WHY?
<xipietotec> I have a bad bug related to updating kernel images in feisty I'm not sure how to resolve
<xipietotec> but 98911
<xipietotec> bug 98911
<xipietotec> pfft....okay https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/98911
<BenC> mjg59: ping
<mjg59> BenC: Hi
<gicmo> Any news on: bug 96480 ? Is there something missing?
<_ion> benc: How are you planning to implement the nvidia thing? I'm thinking something like this, but you probably have a better idea: have libgl1-mesa-glx, nvidia-glx etc. put libGL.so.1 etc. to /usr/lib/glx/mesa, /usr/lib/glx/nvidia-9631, /usr/lib/glx/nvidia-9755 and so on. Link /usr/lib/glx/default via /etc/alternatives to /usr/lib/glx/$foo and link /usr/lib/libGL.so.1 etc. to the equivalent files under /usr/lib/glx. Then have a program call ...
<_ion> ... update-alternatives appropriately based on connected hardware on bootup. The same program should link nvidia.ko to nvidia-$version.ko as well.
<_ion> benc: By the way, would it be helpful if i split the l-r-m debian/rules to debian/rules.d/{nvidia,fglrx,...} and have debian/rules include them? It seems to me that it would make things much easier to change.
<kkubasik> hey, is someone on top of the 2.6.20-14 bump for restricted-modules?
<_ion> benc: Online? :-)
<Ng> is there anything I can do to get useful information about why my r8169 powered NIC has stopped sending any traffic?
<Ng> not seen this before, so I don't want to bounce it or reboot if I can get something useful
<kylem> ethtool -S eth0
<Ng> kylem: ta. sadly that's hanging in an ioctl :/
<kylem> r8169 is an utter shit driver. :\
<Ng> kylem: heh, great!
<Ng> I'll dial up debugging for r8169 in case it happens again
<Ng> but I am distressed that my spendy new desktop has a realtek in it, despite using intel for seemingly everything else
<kylem> rmmod/modprobe might help it.
<Ng> kylem: or it might make it oops
<kylem> indeed.
<Ng> ah well, reboot and debugging it is :)
#ubuntu-kernel 2007-04-04
* Starting logfile irclogs/ubuntu-kernel.log
<fabbione> BenC: alive?
<Mithrandir> hm, is the rt2500 driver as braindead as it seems from bug 78037?
<Nafallo> Mithrandir: if my laptop hadn't been dead I would have tried. I can confirm that it doesn't work in NM though :-)
<Nafallo> Mithrandir: hej btw :-)
<Mithrandir> hiya
<AnAnt> I found out why I can't boot using -12 & -13 kernels
<AnAnt> in the grub menu, I used root=/dev/hda5, when I changed it to root=UUID=.... it worked
<AnAnt> but is that correct ?
<Lure> AnAnt: feisty has moved to new IDE subsystem where most of the disks are now /dev/sdXX
<Lure> AnAnt: this is why everything has moved to UUID= to ease the transition
<Lure> AnAnt: try changing to /dev/sda
<AnAnt> Lure: oh
<AnAnt> Lure: thanks a lot
<Lure> AnAnt: but UUID= is the only way to make it painless for future changes
<AnAnt> Lure: i see, I have another question
<AnAnt> Lure: does the kernel have effect on key combinations used in the virtual console ?
<AnAnt> Lure: there used to be a package (acon), it used to work in Edgy, now it doesn't work in Feisty
<AnAnt> Lure: I mean, it does load, but some key combinations don't work anymore
<AnAnt> Lure: for example leftCtrl+leftAlt+O used to show some menu, now it doesn't do that
<Lure> AnAnt: it can, as it does some mappings for laptop key support, but I am not the right person really
<AnAnt> Lure: ok, who's the right person to ask ?
<Lure> AnAnt: probably someone that works on that package (acon)...
<AnAnt> Lure: I'm the one working on it
<Lure> AnAnt: then diagnose the keycodes returned by kernel - see HotkeyResearch page in wiki
<Lure> AnAnt: not sure if this would help though
<AnAnt> Lure: but that's not a hotkey
<AnAnt> Lure: for example leftCtrl+leftAlt+O , is that a hotkey ?
<Lure> AnAnt: key combination actually - you shoud compare edgy to feisty and see where the difference is
<AnAnt> Lure: I see, that it gives several integers, not just one
<AnAnt> Lure: pressing leftCtrl+leftAlt gave: 0x38 0x1d, pressing O while those keys were down gave: 0x18 0x98, releasing all keys gave: 0x9d 0xb8
<Lure> compare to edgy
<AnAnt> ok
<AnAnt> Lure: ok, I found that there is a difference between Edgy & Feisty
<AnAnt> when keys in Edgy, I get 0x9d 0xb8
<AnAnt> while in Feisty it is: 0xb8 0x9d
<sacater> hi, i need someone to help me disable framebuffer, im told its part of the kernel
<mjg59> sacater: We only use framebuffers on architectures that require framebuffers
<mjg59> So either you don't have one, or you don't want to disable it
<sacater> hmm
<sacater> is there anyway i can find out if i have it
<sacater> a command?
<zul> hey BenC 
<BenC> yo zul
<zul> feeling better?
<_ion> benc: Hi. I asked a couple of questions on this channel yesterday. Did you notice them? :-)
<BenC> _ion: Yes :)
<BenC> _ion: There's no repo for lrm, but I do have everything from you and am integrating it
<_ion> benc: Yeah, but i might be able to do more. :-)
<zul> I just love it when you call the ICU and no one picks up
<fabbione> hey BenC 
<BenC> mjg59: ping, today's the last day for memstick
<kkubasik> hey, are there plans to package a placeholder restricted-modules-2.6.20-14 ?
<kkubasik> or should I roll my own?
<zul> I think they are in the middle of being worked on
<lamont> BenC: around/
<lamont> ?
<kkubasik> just wanted to check, -14 got installed to check a bug
<kkubasik> so no biggie, let me know if a hand is needed
<bdmurray> When is dmidecode needed for kernel bugs?
<bdmurray> Is it just power off issues?
<zul> no, it can be used to blacklist other things as well
<zul> keyboards, etc..
<salty-horse> is this channel logged?
<zul> ues
<zul> yes even
<salty-horse> ... zul, where are the archives? :)
<zul> people.ubuntulinux.org/~fabbione/irclogs
<salty-horse> thanks
<EtienneG> hey kylem
#ubuntu-kernel 2007-04-05
<TheMuso> c
<TheMuso> damn
<lamont> BenC: you still around, or did you go to sleep finally?
<glick> hi
<glick> how can i participate on the ubuntu kernel maintance/development?
<crimsun> https://wiki.ubuntu.com/KernelTeam/GettingInvolved
<glick> hey whats up with reiserfs4?
<glick> why didnt reiserfs4 get added to the kernel?
<glick> i think reiserfs is great
<crimsun> if you'll check the archives for this channel, you'll note that precise question has been raised numerous times. In essence, enabling an experimental fs isn't precisely prudent.
<glick> resiserfs3 isnt experimental though
<glick> ubuntu doesnt seem to support it on install
<crimsun> doesn't support it easily? have you loaded reiserfs?
<glick> crimsun, i mean on install, it doesnt give you the option to create a reiserfs
<glick> just ext3 and ext4
<crimsun> glick: for desktop(s), you mean? I've used alternate(s) for some time, and the option is there
<glick> hmm wasnt there for dapper
<crimsun> that's interesting, since there's a distinct ubiquity changelog entry for precisely that
<crimsun> (well, to be precise, it was still 'espresso' back then)
<glick> is ppc much easier to code for then x86?
<mjg59> In what context?
<mjg59> If you're writing C, then unless you're working on very low-level code it makes no difference at all
<glick> yeah i mean at the low level
<mjg59> Not really, no
<glick> you have a ton of registers
<mjg59> If you're managing registers by hand, you've generally done something wrong
<glick> can directly map all physical memory to the kernel's address space
<lamont> BenC: ping?
<BenC> lamont: pong
<jb-home> BenC: I think he was checking with you on the patch I sent last night.
<BenC> I got it, applying today
<jb-home> Nice, thanks!
<jb-home> Should I look for an upload today, or go get a life instead? =)
<jb-home> by which I mean go change a diaper.  bbias. =)
<BenC> jb-home: might not be one till the weekend
<jb-home> Cool, thanks.
<ogra> BenC, why are our default rsize/wsize values for nfs 131072 ? 
<ogra> that seems pretty high to me
<jb-home> ogra: Bah, why constrain yourself to ethernet packet sizes ;)
<zul> BenC: ping openvz crack being uploaded now
<BenC> ogra: if that's a kernel default, it's an upstream one...
<BenC> userspace may be setting it though
<ogra> well, i dont think thats sane ... 
<ogra> its what i see for my / mounts on a thin client
<jb-home> ogra: in practice, you shouldn't be using nfs on a lossy network anyway.
<jb-home> ogra: So you may as well have the window size high.
<mrec> BenC: do you use the v4l-dvb repository which is included in the kernel?
<mrec> there's an issue with unplugging a dvb usb device, it will crash the dvb framework if the filehandles are still open
<mrec> http://mcentral.de/hg/~mrec/v4l-dvb-stable/ (the last 3 patches fix that problem)
<mrec> it's a patch against the latest repository from linuxtv
<BenC> mrec: We're using stock 2.6.20 for that code
<BenC> mrec: Those patches look like they change the ABI...I'm not sure I can get them in for release
<mrec> BenC: they don't change the abi
<mrec> it has been tested by several people the feedback was positive
<AcidBurn> thought I would ask if bug 37784, has been fix, for real?
<AcidBurn> https://launchpad.net/bugs/37784
#ubuntu-kernel 2007-04-06
<sacater> this may be relevenet to ubuntu kernel, but is there anything i can do to increase boot speed
<abogani> Hi All, Why CONFIG_NETFILTER_XT_TARGET_CONNMARK option is not compiled as module in the kernel?
<abogani> CONFIG_NETFILTER_XT_MATCH_CONNMARK is compiled! 
<abogani> Wht TARGET isn't?
<rouzic> Hi everybody
<rouzic> i have a problem with a boot in Feisty
<rouzic> https://bugs.launchpad.net/ubuntu/+bug/103440
<salty-horse> hi. can someone from the kernel team please ask people to stop comment needlessly on this item please? https://bugs.launchpad.net/bugs/96430
<salty-horse> people should know if it's being worked on. most of the comments don't add much information
<sacater> salty-horse: im on it
<salty-horse> much appriciated
<salty-horse> appreciated - bah
<sacater> salty-horse: check it now
<sacater> rouzic: ill have a look for you :D
<salty-horse> great. hope it will quite things down. thanks again!
<rouzic> Hi sacater
<sacater> hi
<sacater> im looking at your boot troubles :D
<rouzic> Sacater: this failure I have it for 2 days, and it is very inconvinient
<sacater> rouzic: i had something similar once, but not on feisty
<sacater> it got fixed in an update
<sacater> but im still looking :D
<rouzic> I use a Macbook, and the failures related to the kernel
<sacater> rouzic: please run ifconfig eth0
<sacater> if that is the port you are using
<sacater> if its eth1, use eth1 :D
<rouzic> rouzic@kubuntu-es:~$ ifconfig eth0
<rouzic> eth0      Link encap:Ethernet  HWaddr 00:16:CB:CD:13:C0
<rouzic>           inet addr:192.168.1.107  Bcast:192.168.1.255  Mask:255.255.255.0
<rouzic>           inet6 addr: fe80::216:cbff:fecd:13c0/64 Scope:Link
<rouzic>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
<rouzic>           RX packets:17231 errors:0 dropped:0 overruns:0 frame:0
<rouzic>           TX packets:15915 errors:0 dropped:0 overruns:0 carrier:0
<rouzic>           collisions:182 txqueuelen:1000
<rouzic>           RX bytes:16460796 (15.6 MiB)  TX bytes:2118506 (2.0 MiB)
<rouzic>           Interrupt:17
<sacater> hmm
<sacater> looks fine
<sacater> local bound...
<sacater> SURE you IP is correct, 
<rouzic> yes
<sacater> are you at home, or a small business?
<rouzic> home
<sacater> or big :D
<sacater> ok
<sacater> hmm
<rouzic> in Microsoft :p xD
<rouzic> corporation :p
<sacater> are you on that laptop now?
<rouzic> yes
<sacater> hmm
<rouzic> connected
<sacater> hmm
<sacater> i have an idea
<sacater> try turning off the internet
<rouzic> sudo rm -fr / :p
<sacater> on the computer
<rouzic> Already I have done it
<sacater> disabe it
<sacater> oh
<sacater> turned off internet, and rebooted into a web-less enviroment?
<rouzic> The problem is that the net recognizes me well, but the configuration is late very much in the take-off of the system
<rouzic> Slow me same the take-off without Internet
<sacater> hmm
<sacater> i could recommend something...
<sacater> but im not the expert on it...
<sacater> and it MAY be faster at boot, but a manual command would be needed when you load up
<sacater> i could suggest MOVING your web start-up in init.d, and executing it manually, when the computer has finished loading up
<rouzic> oks :)
<sacater> whoa
<sacater> hold your horses
<sacater> init.d is dangerous place
<rouzic> sacater: But is it a failure of the kernel?
<sacater> i doubt it
<sacater> if everything else runs fine
<sacater> oh wait
<sacater> you dont need to risk your machine to find out
<sacater> just disable web with my command...
<sacater> then re-enable
<sacater> and see how long it takes to turn on
<sacater> come*
<rouzic> https://bugs.launchpad.net/ubuntu/+bug/103440 The problem him appears to many users
<sacater> ok
<sacater> rouzic: listen
<sacater> note this down on paper please...
<rouzic> oks
<sacater> as it will kill your web temporarily
<sacater> i make no guarentees either
<sacater> right, we arnt going to turn off a port
<sacater> we are going to kill your network daemon...
<sacater> then give it CPR
<rouzic> sacater: works correctly my web
<sacater> bring it back
<sacater> rouzic: you will be offline during this
<sacater> kk
<sacater> ready for the commands?
<rouzic> Sacater. have tried to reinstalling the packages avahi, network-manager
<sacater> that wont do it
<rouzic> yes
<sacater> it may be the daemon
<sacater> ok
<sacater> here
<sacater> we 
<sacater> go
<sacater> sudo /etc/init.d/networking
<sacater> whoops
<sacater> hold that
<sacater> yeah
<sacater> sudo /etc/init.d/networking stop
<sacater> that is a good command
<sacater> sudo /etc/init.d/networking start
<sacater> those 2
<sacater> in that order :D
<sacater> rouzic: k?
<rouzic> oks
<rouzic> wait
<sacater> see how long it takes to restart the web daemon
<sacater> rouzic: do it when you want
<sacater> i only want to see how long it takes to bring the web back
<sacater> rouzic: *poke*
<rouzic_> sacater: :)
<sacater> erm
<sacater> ok..
<sacater> you didnt kill your first irc
<sacater> hence the _ in your name
<sacater> rouzic_: how long did it take?
<rouzic_> :p
<rouzic_> yes
<rouzic_> wait
<rouzic_> copy&paste
<sacater> ok
<sacater> not sure anyone minds a tiny bit of spam
<sacater> :D
<rouzic_> http://paste.ubuntu-nl.org/14190/
<sacater> ok
<mjg59> Given that this has nothing to do with the kernel, would it be possible for you guys to discuss this elsewhere?
<rouzic_> The load of/etc/init.d/network has been very slow
<sacater> mjg59: good point, rouzic_ please join #sacater
<sacater> continue in my channel
<newz2000> Hi, just got -14... still having three problems. I'm happy to help diagnose or gather info if I can...
<newz2000> bug #53923 (sd card problem, worked in Edgy)
<newz2000> mjg59: bug ##96679 (suspend problem) is changed, works like it did in edgy (can suspend only once) but is a regression from -12, since it worked fine there
<newz2000> crimsun: bug #92171 (sound incredibly quiet) no change, but the workaround you gave me does work still
<newz2000> ping me if any extra details will be helpful on any of these
<mjg59> BenC: Softmac and network-manager don't seem especially enthusiastic to get along
<mjg59> BenC: (Aren't we supposed to have a wireless guy now?)
<BenC> mjg59: we do, but he's low level...this userspace stuff interaction is all new :)
<BenC> mjg59: do you mean the mac80211/nl80211 based drivers?
<mjg59> No, softmac
<mjg59> bcm43xx and zd1211rw both exhibit this
<mjg59> Haven't hit it with any other drivers
<mjg59> The card associates, n-m doesn't seem to notice
<mjg59> The issue may actually be in wpa_supplicant, but from the user viewpoint that's basically the same thing
<mjg59> (Though this is an open network, so...)
<rmjb_> hello, I need a little advice on fixing a bug in a package that depended on a module that's no longer in the kernel
<rmjb_> it's bug#102973
<rmjb_> https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/102973
<fabbione> rmjb_: you want to talk to people in #ubuntu-motu
<fabbione> the pacakge is in univers
<fabbione> +e
<kylem> er, it's a one line patch. ;-)
<fabbione> kylem: yeah i know.. 
<rmjb_> cool, I can just patch the source where it asks for raid45 to raid456 and everything will be peachy...
<rmjb_> just thought I should get someone from the kernel team's input
<kylem> yes.
<BenC> because a lot of our discussion revolves around some NDA stuff, it seems to have migrated to the canonical IRC channel
<BenC> much like that statement should have
* kylem blinks
<mjg59> rtg: why did you reject #94859?
<rtg> mjg59: A momemt while I refresh my memory...
<BenC> shitty...I installed a dual-boot ubuntu on a vista machine, and now it wont boot vista...just hangs and the lovely Microsoft progress bar
<rtg> BenC: Sucks to be you.
<mjg59> kylem: I'm testing Alan's new HPA patch now
<kylem> mjg59, thank you.
<BenC> not that I mind ditching windows, but I think this is a common test case with bad results
<rtg> mjg59: Maybe I was just cranky that day. I should have reassigned it to another group 'cause its not really a kernel bug. More of a configuration thing.
<mjg59> rtg: ?
<mjg59> rtg: The issue appeared to be that the device-id isn't listed in zd1211rw
<mjg59> That sounds pretty definitively like a kernel problem
<mjg59> zd1211-mac80211 has the device id, but we removed the modalias export
<rtg> mjg59: I guess I'd better reread this one for content.
<mjg59> So the choices would either be add it to zd1211rw (which seems to work), or add a selective set of modaliases for zd1211-mac80211 (that is, use it for devices that it claims to support but zd1211rw doesn't)
<BenC> mjg59: When you say "which seems to work", have it been tested? I didn't see that in the bug report
<mjg59> BenC: Based on the link he gives, yes
<BenC> Ah, so yeah, just add the ID's
<BenC> rtg: Probably best if you check the linux-2.6.git for zd1211rw updates for the device table
<BenC> might be more than this one
<BenC> looks like we'd still benefit from some of the aliases in zd1211rw-mac80211 being active
<BenC> Well, the list in 2.6 git matches the one in mac80211 version
<BenC> They seem to have removed 2 devices, and added 4
<mjg59> I'd go with that, then
<BenC> wondering about the ones that got removed
<rtg> Two questions: 1) How did zd1211rw register this adapter if it doesn't have the ID in its table?  2) Why don't we migrate toward the more modern (and wireless-dev supported) driver  zd1211rw-mac80211?
<rtg> Did 2.6.20-12 still have the ID in zd1211rw?
<mjg59> Because softmac works
<mjg59> mac80211, less so
<rtg> mlg59: It looks like 083a:4505 is OK to add to zd1211rw/zd_usb.c, but I'm still confused about how this driver got loaded in the first place.
<rtg> mlg59 --> mjg59
<BenC> rtg: he probably manually loaded it to show it wasn't working
<mjg59> kylem: Alan's new patch seems good
<mjg59> Except its debug spew is broken
<mjg59> Though that might actually be my debug spew
<rtg> BenC: there are several upstream ID additions, but I don't think we want to pull all the zd1211rw updates because of dependencies on wireless-dev stuff, right?
<kylem> mjg59, hmm?
<BenC> rtg: the driver in current git isn't using mac80211
<mjg59> kylem: Eh, whatever. Go with Alan's code.
<kylem> and not blacklist apple?
<kylem> it works with piix?
<BenC> rtg: but there are a lot of changes in the driver which may be needed for the other ID's, so yeah, leave them out
<mjg59> kylem: Works with piix, yeah
<mjg59> kylem: Some slightly worrying output, but that might be due to my tree being slightly weird. I'm looking into it, but it seems basically correct
<mjg59> By worrying, I mean "ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 16337840
<kylem> ok, i'll keep the ahci reprogramming then.
<mjg59> "
<kylem> i think that's your output?
<mjg59> Which, uh, isn't what I'd like it to do
<mjg59> I'll play some more
<kylem> thanks.
<mjg59> kylem: Oh, needs ata_ignore_hpa setting to 1
<kylem> mjg59, yes. although with your output that doesn't look happy.
<mjg59> Well, if we don't set it then we still have a broken kernel
<mjg59> kylem: Ok, boots, but clearly not right
<mjg59> I'll mail
<kylem> thanks.
<kylem> if you put the pci quirk thing to program to ahci, does it work?
<mjg59> Where's the latest version of your quirk?
<kylem> people.ubuntu.com/~kyle/apple-somethingorother.diff
<mjg59> Building
<kylem> thanks.
<mjg59> kylem: Ha. Fine with ahci.
<kylem> figures.
<kylem> sigh.
<mjg59> kylem: Mail sent
<kylem> thanks.
<mjg59> rtg: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/103768 is pretty significant
<mjg59> The only thing that springs to mind is that softmac must be sending association messages to userspace slightly differently to anything else
<Zennor> hej hej
<rtg> mjg59: I have a bcm43xx. Lemme give it a try in a bit. I'm still reading through upstream updates to see if its OK to add some of these other zd1211rw ID's.
<Zennor> maybe someone can look at bug #96639, cjwatson send me
<mjg59> Zennor: Do you have the logs for when it probed your CD drive?
<mjg59> (Not from when it's trying to mount the CD)
<mjg59> It could be marginal media that some drives will read but others won't
<mjg59> There's no hardware commonality between the two failing systems, as far as I can tell
<Zennor> well I can get them in the next few minutes if you wish
<mjg59> Ok
<Zennor> mfg59: what special log you want?
<cjwatson> the screenshot looks like it should be sis5513
<mjg59> cjwatson: Yeah, but it also fails on a via system
<mjg59> Zennor: There should be something mentioning the CD drive
<Zennor> in earlyer versions of ubuntu cddrive was at /dev/hdd and had nothing todo with sata drivers
<Zennor> I'm now uploading pics of syslog
<Zennor> hope you meant that
<DB42> what is the latest offical kernel ver for 6.06 ?
<BenC> DB42: whatever's in dapper-security
<DB42> which is..
<BenC> apt-cache search linux-image-2.6.15
<DB42> 2.6.15 ? k
<rtg> mjg59: with regard to bug #103768, I just removed/inserted a bcn43xx PCMCIA about a dozen times, 2.6.20-14, Linksys WAP54G, WPA/PSK. What is different about your setup?
<rtg> bcn43xx --> bcm43xx
<rtg> PCMCIA --> Cardbus
<mjg59> rtg: What do you mean by removed/inserted?
<mjg59> And what did you then do?
<rtg> modeprobe -r/modprobe and hard remove/insert.
<mjg59> Ok, because that's not the situation I was talking about...
<rtg> It appeared to associate the first time.
<mjg59> I click on the network-manager icon, select my network, it ponders for a minute (failing to have noticed that the card has associated) and then times out and tears down the interface
<mjg59> I'm on an open, unencrypted network
<rtg> OK, I'll futz around some more.
<sacater> how do i go about disabling the framebuffer on ubuntu kernel
<mjg59> How did you enable it?
<sacater> erm
<sacater> it comes enabled as default
<sacater> when installing
<BenC> sacater: no,  it doesn't
<sacater> ooh
<BenC> sacater: unless you're on something like powerpc where framebuffer is the only way to driver the display in console, then it isn't enabled by default
<sacater> hmm
<sacater> er hem, what if i added a request for its usage in the xorg config, and vlc wanted it
<BenC> then you're in the wrong channel :)
<sacater> what should i go to then?
<BenC> most likely you want #ubuntu
<gnomefreak> sacater: see -motu for fast simple answer
<sacater> and you for a question
<rtg> mjg59: I think I'm doing the same as you and I'm not seeing any problems. What kind of AP is 6bFair? Are there any differences from default setup values, especially in advanced wireless settings?
<mjg59> rtg: This is a clean installation. It's a Linksys WRT54GS running OpenWRT.
<mjg59> The card associates absolutely fine, but wpa_supplicant doesn't appear to notice (and hence n-m doesn't either)
<mjg59> While it's attempting to associate, if I click on the icon again and trigger another association, it works fine
<mjg59> Let me try this with another Broadcom machine
<mjg59> rtg: Ok, just booted a different machine and logged in. network-manager is displaying two grey circles, which means it hasn't associated.
<mjg59> Oh, wait, sorry - this has come up with the wrong driver. Let me deal with that first.
<mjg59> rtg: Ok. Completely different hardware to the one I used to report the bug.
<mjg59> rtg: Logged in, nm is showing grey circles.
<mjg59> rtg: iwconfig says that I'm associated
<mjg59> So it doesn't appear to be machine-specific
<mjg59> (One's a bcm4311, one's a bcm4318)
<rtg> mjg59: Neither does it appear to be adapter specific since you said it would happen w/zd1211rw
<mjg59> Right, but those are the only two softmac drivers
<mjg59> (As far as I know)
<rtg> mjg59: Well, I'm gonna have to dive into the soft MAC eventually. In the meantime, since this has an easy workaround, do you really think this deserves to be 'Critical' ? That is generally reserved for faults and exploits.
<rtg> BenC: I pushed the zd1211rw device ID changes.
<mjg59> rtg: It doesn't have any sort of user-discoverable workaround
<mjg59> From the user perspective, this hardware just isn't going to work
<kylem> has anyone used the "linux-source-$foo" binary package to build a kernel recently?
<kylem> kees was commenting that it was broken in edgy...
<johanbr> kylem: I did about two months ago, not sure if that counts as recently. That was soon after the 2.6.20 Feisty packages were released.
<kylem> johanbr, yeah, thanks.
<kylem> good to know it's fixed in feisty then.
<johanbr> I used make-kpkg, didn't try any of the other methods.
<kylem> ah, ok.
<stgraber> Anyone heard of problem using some new HP Pavillon with NForce chipset + NVidia gfx card. Seems to have a buggy bios (kernel recommend pnpbios=off), IRQ conflict (on irq7), ACPI (unknown symbol messages) and freeze once X started (~30s freeze every 5 minutes)
<stgraber> I don't have enough information to make a bug report yet as it's on one of my teachers' laptop
<stgraber> and he's to reinstall Vista to have to work during his holidays
<stgraber> but I'd like to have a way to fix it afterwards. I tried nearly all kernel parameters applying to such situation
<stgraber> acpi=off, acpi=ht, noapic, irqfixup, irqpull, pnpbios=off and nearly all mix of them
<stgraber> in the best case -> no a lot of kernel errors (mean pnpbios error no more displayed) but still the IRQ conflict and the freeze ...
<stgraber> I've a "dmesg" and "lspci -vvn" if someone want to have a look
<stgraber> but nothing more till the end of the holidays (ending the 23th)
<johanbr> stgraber: My (older) HP requires "noapic nolapic". Worth a try, I guess...
<stgraber> johanbr: what serie was it ?
<johanbr> stgraber: An nx6125, which I think is fairly different from the pavilions...
<stgraber> I've forgotten the nolapic one, I'll add it in the list of things to try next time I'll be in front of this laptop
<stgraber> It seems this BIOS is really buggy (phoenix one it seems) but the latest version doesn't fix anything :(
<_ion> I keep getting hilights, but it's the other Johan being talked to. :-)
<stgraber> _ion: sorry :(
<_ion> Haha, no need to be sorry.
<stgraber> Same thing with me on #canonical-sysadmins with another guy called Stephane :)
<_ion> :-)
#ubuntu-kernel 2007-04-07
<crimsun> newz2000: that changeset hasn't been merged yet
<crimsun> newz2000: that's why it's still marked "Fix Committed" instead of "Fix Released"
<crimsun> newz2000: furthermore, although the changesets I've been emailing to Ben have been trivial, they don't exactly fix critical regressions, so I don't know if they'll make it into Feisty.
<maks_> crimsun: is it a known trouble that after suspend of an intel ich6 audio controller the micro is no longer working?
<maks_> that is since 2.6.18 for sure until latest linus
<maks_> have seen it on a dell inspiron and on a ibm x41
<crimsun> maks_: audio on my x41-2527 works fine across suspends-to-* and resumes
<crimsun> maks_: I'm running the latest bios on the x41-2527
<maks_> ok that might make the diff
<crimsun> I can provide you with a diff that reverts the "aggressive power saving" commit for AC'97-based codecs
<maks_> no idea if it ever worked crimsun?
<maks_> didn't use the mic back then
<crimsun> it definitely worked on the system I mentioned above
<maks_> mine is not far off x41-2525
<maks_> shall i test boot 2.6.17 or older to test?
<maks_> have almost any kernel up to 2.6.14 installed
<crimsun> sure.
<crimsun> actually, CONFIG_SND_AC97_POWER_SAVE isn't even enabled, so it's definitely not the audio subsystem's fault
<crimsun> not to mention even when it is enabled, it defaults to "off" (although it can be enabled via sysfs)
<maks_> "(Fix) The LCD display may not turn on after the display off/on operation."
<maks_> i guess i do want latest bios crimsun :)
<rmjb> Hello, I'd like to get someone's input on a possible kernel bug: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97655
<rmjb> it's related to the dmraid package, to enable use of fakeraid arrays
<rmjb> I want to find out if the bug makes sense, i.e. is true, and if it is I guess dmraid is broken in feisty for raid5 arrays
<rmjb> if not then it can still be fixed since universe is not yet frozen
<rmjb> ... anyone here tonight?
<crimsun> only in rare circumstances, since many people will be observing the Good Friday holiday
<rmjb> I'm observing it too... by bug fixing :)
<crimsun> it's funny how regardless whether there's a holiday, people still expect us to fix bugs. :-)
<rmjb> I don't want it fixed... just some advice on it
<rmjb> should I email some list if no one is here?
<crimsun> I have no such configuration, so you'll need to get more details from the original reporter.
<crimsun> apparently he wants someone else to do the work, which is fine, but it likely won't happen for feisty.
<rmjb> I know, the kernel is frozen solid...
<rouzic> sacater: hi
<anikras> hello
<mrec> hi
<mrec> can anyone have a look at: http://mcentral.de/pipermail/em28xx/2007-April/000213.html
<anikras> howto i can have interface http://newbiedoc.sourceforge.net/system/kernel-pkg.html
<mrec> is there any special patch in that ubuntu kernel regarding sysfs?
<anikras> i have kernel 2.6.20
<mrec> the same works with a vanilla 2.6.20.6 kernel
<mrec> http://mcentral.de/pipermail/em28xx/2007-April/000220.html
<mrec> the problem seems to occure when calling request_firmware()
<sacater> rouzic: hi, 
<sacater> rouzic: check your email
<sacater> i translated into espanol using google translate
<rouzic> sacater: you speak spanish?
<sacater> rouzic: nope
<sacater> i only know 2 words
<sacater> uno momento
<rouzic> :)
<sacater> im better in french
<rouzic> uno is one
<rouzic> momento is momment
<sacater> yep
<sacater> i know!
<rouzic> :p
<sacater> je parle parfait francais pour a 
<sacater> poissons 
<sacater> i speak perfect french for a fish*
<sacater> :D
<rouzic> no :(
<rouzic> i don't speak frech
<sacater> meh
<rouzic> french*
<sacater> im looking at that video now
<sacater> rouzic: after reviewing you video, i have come to a conclusion
<sacater> i dosnt like your wifi
<sacater> it even complains in boot-up
<sacater> oh, and like the poster
<rouzic> sacater: Wanted! :p
<rouzic> Clippo :p
<sacater> yeh
<sacater> right
<sacater> simple what you have to do
<sacater> disable your wireless adaptors
* sacater adds video to his blog
<rouzic> :p
<rouzic> sacater: But already it is deactivated 
<sacater> oh
<sacater> thats pooey then
<sacater> rouzic: my blog dosnt support indexing, can you put that video on youtube for us
<rouzic> i don't have account in youtube
<rouzic> wait
<sacater> google videos?
<rouzic> sacater: youtube
<rouzic> sacater: i don't use youtube :(
<rouzic> What do you think about the problem of the sound and the earphones?
<crimsun> the what?
<rouzic> crimsun: http://rouzic.net/files/sacater.tar.gz
<rouzic> look this video ;)
<crimsun> I can't play video here
<crimsun> text files work best.
<stgraber> rouzic: I've also had this bug, it's quite easy to fix
<rouzic> stgraber: :p
<sacater> Who controls the nvidia-glx development
<sacater> ?
<stgraber> Simply a broken /etc/network/interfaces, at boot time the networking script try to ifup all the interfaces and then start dhclient on an interface without anything connected, that takes a while till the timeout make the system continue booting
<stgraber> cleaning the /etc/network/interfaces and removing everything but "lo" fix it
<rouzic> command
<rouzic> remove all?
<stgraber> stgraber@laptop:~/sacater$ cat /etc/network/interfaces 
<stgraber> auto lo
<stgraber> iface lo inet loopback
<stgraber> NetworkManager now takes care of the rest, so simply keep those two lines is enough
<rouzic> thanks stgraber
<stgraber> np
<rouzic> rebooting :)
<rouzic_ausente> stgraber: THANKS!!! :)
<stgraber> no problem :)
<rouzic> stgraber: i have a problem with a sound
<rouzic> wait a moment
<rouzic> stgraber: http://rouzic.net/?q=node/37
<rouzic> appears a red light where the earphones connect, and is not listened on 
<rouzic> having had the earphones put
<stgraber> Did you try updating bootcamp ? (I've just read from a website talking about this issue with Windows)
<stgraber> "I noted that the red light was also coming out when I used windows (bootcamp). I wasn't able to listen through my earphones, but after one of the bootcamp updates it was gone."
<rouzic> stgraber: Only it spends to me in the kernel 2.6.20-14, before he was using 2.6.20-9 and was working correctly
<stgraber> oh, I've maybe got a solution
<stgraber> check if you can mute something like IEC958
<stgraber> using alsamixer and the "m" key
<rouzic> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/94055
<rouzic> please, disabled the touchpad in the macbook :(
<hyper_ch> hiho, I'm trying to setup dm-crypt and LUKS following a guide for debian but I already fail at step 6 (which I think is related to step 2 - altering the kernel options). It says to enable a few things if they aren't already but I don't know how to do that. Can anyone help me on that issue? Here's the guide:  http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian
<hyper_ch> sorry, I just closed Kconversation :)
<hyper_ch> help :)
#ubuntu-kernel 2007-04-08
<sharms> is the ipw2200bg card currently supported in feisty?  I just booted, restricted manager said it was using driver ipw3894abg  but I didnt see a device, then when I rebooted the card stopped working, I think it may have flashed it with the wrong firmware?
<crimsun> err, what?
<crimsun> the ipw2200 certainly is supported via the ipw2200 driver
<sharms> right but for some reason feisty identified it as ipw3894abg
<crimsun> I'm not sure what you mean by "it may have flashed it with the wrong firmware", though
<sharms> if I do an ls pci it shows 2200bg
<crimsun> which module is loaded?
<sharms> not sure, I didnt know if we flash it with firmware like my old wireless card (prism54)
<crimsun> well, if by "flash" you mean "upload", then yes
<sharms> the first time it was ipw3945.ko, subsequent reboots (with bios error message) use ipw2200
<sharms> Its not a big deal for me hardware wise, but if it was somehow related that could be a big issue
<crimsun> that's a very odd issue (rather, I've not seen that happen before. PCI ID mismatch?)
<sharms> It may have been a bad card from the git-go, I just got it an hour ago
<sharms> I believe the first time it booted it identified itself was ipw3945 on the lspci
<sharms> but since reboot it said ipw2200
<sharms>  ipw3945: MAC is in deep sleep!
<sharms> ipw3945: Unable to int nic
<crimsun> I suppose you could use /usr/bin/update-pciids
<mjg59> ipw2200 and ipw3945 are very different cards
<sharms> well it no longer identifies as ipw3945
<sharms> it now identifies as ipw2200
<mjg59> Given that one is PCI and one is PCIE
<crimsun> yeah, that error really makes no sense to me
<sharms> but it is conflicting with other devices it says now 
<sharms> from the bios that is
<mjg59> lspci -n please
<sharms> the card is out right now, back to prism54 let me reboot
<mjg59> Nothing the drivers do can alter the card in a non-volatile way
<mjg59> If it's going in the same slot as a prism54, it's not an ipw3945
<sharms> mjg59: http://paste.ubuntu-nl.org/14502/
<mjg59> That's certainly an ipw2200
<mjg59> It's mini-pci, right?
<sharms> ya
<sharms> its in my laptop
<mjg59> So it can't possibly be ipw3945
<mjg59> That's only available in mini-pcie form
<sharms> right thats why I was worried maybe ipw3945 might have done something to it somehow
<mjg59> No
<sharms> ok so then I will just write this one off on bad hardware, I just wanted to run it by you guys 
<sharms> mjg59: doing some addition research (looks like you may have been involved in some of this), could it be that my bios may have a whitelist of cards and that could be causing the issue?
<sharms> mjg59: how dangerous would it be to use your whitelist bios modifier?
<sharms> ha just went for it will let you know
<mjg59> BenC: #96480 probably ought to be critical?
<BenC> mjg59: marked and milestone'd
<mjg59> Ta
<BenC> Interesting, latest vmware w6 seems to use vmx extensions on linux
<stgraber> hey BenC, about that, I wondered why I can't activate the paravirtualisation stuff with the latest version of VM W6 and a Core2 Duo with the VT ?
<BenC> paravirt only works on 32-bit
<BenC> and I'm running it enabled right now, so I know it works
<stgraber> strange, I'm using 2.6.20-14 on 32-bit
<BenC> You have to go to your virtual machine pref's, Other tab, Advanced, and check the box for paravirt
<BenC> it's not enabled in ws6 by default
<stgraber> yep, but I simply can't because it's grayed with the latest version of ws6
<BenC> what build do you have?
<stgraber> 42757
<BenC> e.x.p build-42757
<BenC> you have to power off the vm first
<stgraber> it's powered off
<BenC> talk to vmware
<BenC> Just checked on mine, and it let's me check/uncheck it as long as the vm is powered off, and I've setup for a 32-bit OS
<stgraber> hmm, seems to work with an all new VM and the same settings. I'll maybe have to report this to vmware ...
<finalbeta> I'm starting to fear Feisty could air with this bug https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/98782 , And that would render it unusable for me. Check out the latest attached dmesg. I hope I don't overstep any boundaries here, but the desperate... :p. It's 15 minutes now to boot, and the latest 2 kernels give errors about the CD drive also. Dapper and Feisty ran fine, and 2.6.20.9 and lower ran fine.
<mjg59> Does it boot at the normal speed if you disconnect the CD drive?
<finalbeta> Will try. 
<finalbeta> No, doesn't seem to change anything
<mjg59> But you no longer get the ata1.01 errors?
<finalbeta> Not yet, I'm waiting, it can take a while...
<finalbeta> It's just sitting there. (figuratively)
<finalbeta> Yep, no more errors, and after the initial stall, It boots much faster.
<finalbeta> Already at the login screen.
<mjg59> Ok. So it's pretty clearly linked to the unhappiness with the CD drive.
<finalbeta> definitely.
<mjg59> You're using an 80-wire cable, right?
<finalbeta> Ehm, It's a dell laptop. I have no idea what so ever.
<mjg59> Ah, ok. Interesting.
<finalbeta> I can't screw that part open also...
<mjg59> What model?
<finalbeta> Tried before, couldn't do it.
<finalbeta> Inspiron 8200
<mjg59> Ok.
<finalbeta> At least 5 years old.
<mjg59> Don't have anything with that chipset here
<mjg59> I'll have to leave that with Ben, then
<finalbeta> I'll add that removing the cd drive fixes it, and add a dmesg to the report when booting without CD drive.
<finalbeta> Thanks for helping me out. 
<_ion> benc: bzr branch http://johan.kiviniemi.name/software/bzr/hardware_connected/
<_ion> benc: Usage example: if modinfo -F alias nvidia-9755 | hardware_connected; then echo "nvidia-9755 compatible hardware is connected" ...
<_ion> benc: Assuming all nvidia drivers are moved to a single nvidia-glx package and alternatives are used instead of diverts, here are simplified preinst scripts that should remove *all* old diverts, without a need to list them manually. http://johan.kiviniemi.name/tmp/nvidia-glx-dev.preinst.in http://johan.kiviniemi.name/tmp/nvidia-glx.preinst.in
<_ion> s/diverts/divertions/g
<fabbione> _ion: you can't just remove diversions. diverts can be done by sysadmins too. you need to be careful there
<_ion> fabbione: It only removes diversions made specifically by nvidia-glx packages.
<fabbione> and what happens if you hit a custom one? how would you switch to use alternatives?
<fabbione> anyway.. it's S U N D A Y
<fabbione> and i should stop reading IRC
<fabbione> :)
<_ion> I haven't really given a lot of thought to special cases in this regard. I believe that when there are multiple nvidia modules installed and the system's supposed to automatically use the right one based on connected hardware, alternatives is the way to go.
<fabbione> ok an init script that sets the right links like /lib/modules../volatile
<fabbione> s/ok/or
<fabbione> given that you can actually change hw across reboot
<fabbione> providing a set of alternatives will make it complicated for normal users to switch between driver versions
<_ion> nvidia.ko isn't going to be linked using alternatives, but IMO libGL and nvidia_drv.so should.
<fabbione> not my call.. but i don't believe alternatives is the right solution
<_ion> benc: Any comments to the discussion above?
<zdzichuBG> hi
#ubuntu-kernel 2008-03-31
<kraut> moin
<abogani> cking: Ho Colin! Any news about bug #177895?
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895
<cking> abogani: When I applied your patch to the current kernel source I got a lot of patch errors. I believe I sent you an Email about this last week. Did you receive it?
<abogani> cking: Oh, Sorry Yes i received it!
 * abogani really need a coffee...
<cking> abogani: It seems that your kernel sources are out of sync with the current tree..
 * cking coffee - me too
<abogani> cking: I can give you one if you came here! ;)
<cking> abogani: The coffee could be cold by the time I arrive :-)
<abogani> ;)
<dade`> hi
<dade`> the https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177895 is fixed in 2.6.25-rc7 kernel
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] 
<dade`> rescheduling interrupts occurs much less frequently
<cking> ubotu: I will look at the 2.6.25-rc7 patches to see if we can patch the scheduler to fix this
<pwnguin> does ubotu recognize such language?
<cking> pwnguin: oops should have directed this to dade` 
<pwnguin> im just glad to discover that i wasnt the only one to notice that problem
<BenC> Good morning ppl
<cking> Hi BenC
<BenC> You guys probably noticed I didn't do an upload this weekend
<soren> tim did?
<BenC> Mostly because of time, but also because I didn't get the cpu1 suspend/resume issue fixed, but I am close to it
<BenC> No one did that I know of
<soren> rtg uploaded one last night.
<soren> 13.23.
<BenC> Damnit, I wasn't ready for one yet
<BenC> Oh well, just means we will have another
<BenC> Well, that's a given since everything non-x86 failed to builkd
<BenC> *build
<BenC> mjg59`: your vt font patch broke non-vga arch builds
<BenC> vt_ioctl.c:(.text+0x44864): undefined reference to `vga_con'
<mjg59`> BenC: Hm. The entire lot probably wants to be CONFIG_X86, then.
<rtg> BenC: hmm, no good deed goes unpunished.
<rtg> BenC, mjg59`: fixed vga_cons issue with CONFIG_VGA_CONSOLE
<BenC> rtg: Great, thanks
<BenC> rtg: I want to get the cpufreq fix in before next upload, and I think that should be all we need right now
<rtg> BenC: ok
<BenC> We should review the milestoned bugs tomorrow to make sure we aren't missing anything we want though
<rtg> BenC: I'll have the ABI stuff ready by then.
<rtg> I mean the ABI bits from the failed builds.
<BenC> rtg: Can you take a look at bug #200509
<BenC> rtg: I'm going to bring it up with Intel as well
<rtg> BenC: it ought to be fixed in LBM w/1.2.25
<BenC> rtg: Ok, want to fix up the bugs to point to lbm and add a blurb to that affect?
<rtg> BenC: Leann has already mentioned the fix in LBM.
<rtg> I'll change the project pointer
<BenC> mdomsch: hey
<tseliot> BenC: did you have a look at my patch? It won't take long, I promise
<BenC> tseliot: I'll check it shortly
<tseliot> thanks
<tseliot> BenC: here's the link (just in case): http://www.albertomilone.com/tseliot_patch.patch
<BenC> rtg: is ipw3945 supposed to be in hardy lum+lrm?
<rtg> BenC: no, ipw3945 should be completely excised.
<rtg> BenC: besides, the regulatory daemon is gone. the last release in which it appeared was Gutsy.
<BenC> rtg: there's still remnants of it around, like microcode and modprobe.d files (lum and lrm, in that order)
<rtg> BenC: ok, I'll cleanup.
<rtg> BenC: what do you think about http://kernel.ubuntu.com/git?p=abogani/ubuntu-hardy-rt.git;a=commit;h=2070509e4474bf29715fa049c13204a4a4025442 ? Its seems straightforward, but it does make changes at a fundamental level. Also, why didn't we see this problem with Gutsy?
<BenC> rtg: not sure...maybe certain config options have exacerbated the problem (nohz, etc)
<rtg> BenC: shall we try it? We have at least one more upload to back it out if it causes problems.
<BenC> rtg: Yeah, hanging machines is bad enough we should at least look into it. From the description, it sounds like only dmi listed machines will see code changes...any chance we can get a test by someone with that machine?
<rtg> BenC: I'll pursue it and get a test build out this afternoon.
<BenC> tseliot: +  * removing madwifi?
<BenC> tseliot: +  * changed to main?
<tseliot> BenC: my repository will provide only the nvidia and ati driver
<BenC> tseliot: ah, so this isn't for lrm proper...my mistake
<tseliot> BenC: as regards "main", I had to do that otherwise the packages wouldn't build in the PPA :-(
<BenC> tseliot: I can see that conflicting though, for the linux-restricted-modules-2.6.24-X-flav packages though
<BenC> tseliot: people will expect them to provide the same modules that ours provides
<tseliot> BenC: the only packages which I build are nvidia-glx, fglrx, etc. nothing that begins with linux-restricted-modules-*
<BenC> tseliot: ok, not so much of a problem in that case
<tseliot> it doesn't cause any problem with the official l-r-m here
<tseliot> BenC: using my PPA will avoid the problems related to local builds
<tseliot> BenC: as Envy used to do
<BenC> tseliot: all looks good then
<tseliot> BenC: great! can you send an email to Daniel and Michael saying that it's all ok? Otherwise I can do it myself
<BenC> tseliot: please pass on my ack, I don't have the email handy
<tseliot> BenC: ok. Thanks for your time :-)
<adinc> hello, there is an comment on bug  185470 that linux-backports modules 2.6.24 are available in order to solve the iwl3945 driver problem. can someone please tell me what backports modules differ from the normal ubuntu modules?
<adinc> ubuntu kernel modules
<BenC> adinc: it's for us to update modules without affecting people and risking regressions
<BenC> adinc: it's so people can opt-in
<BenC> ...to newer versions of a driver
<adinc> since there is a suggestion testing a newer module, i try to understand what changes if i use this package
<infinity> Any plans to fix the {ppc,sparc,hppa} configs for the vga_con undef ref breakage?
<BenC> infinity: done in git
<infinity> Yeah, I backscrolled after I asked.
<infinity> Thanks.
<BenC> infinity: good to see you'll be at UDS this time around
<infinity> So, while I'm asking "questions that have probably already been answered", is LBM/LUM/LRM/meta on the way (since things built fine on the supported arches), or are we waiting to fix the non-supported ones too?
<BenC> infinity: fixing first
<BenC> infinity: planned upload tomorrow after the kernel IRC meeting, when we'll review the milestoned bugs
<infinity> Kay.  This upload should fix the last of my "stuff doesn't quite work right on my new laptop" bugs, so I'm anxious to give it a seal of approval.
<rtg> infinity: you don't have to wait for the kernel team to produce the bits, you could do it in advance on your PPA.
<infinity> rtg: Well, yes, I could, but that involves taking time out from doing other things. ;)
<infinity> And, really, I could do it locally (which is way faster than the PPA machines), but again... "Other stuff".
 * infinity will just wait another day.
<rtg> infinity: np :)
#ubuntu-kernel 2008-04-01
<kraut> moin
<BenC> Good morning everyone
<cking> Morning BenC
<amitk_> BenC: any reason we might _not_ upload a new kernel today?
<BenC> amitk_: none that I know of
<soren> When do you intend to freeze?
<rtg> amitk_: gotta finish fixing this DMI IO_DELAY patch for xen before uploading.
<tjaalton> BenC: is the abi going to change? I've got some packaging fixes for lrm pending
<rtg> tjaalton: the ABI is -13
<tjaalton> rtg: right, but there won't be a -14 ?-)
<BenC> tjaalton: we will need a new lrm uploaded
<rtg> tjaalton: sorry, misunderstood. No, the ABI should remain at 13
<amitk_> rtg: no worries. I was just asking to make sure I don't have to do a separate upload for mobile.
<tjaalton> BenC: yeah, that's why I'm asking :)
<rtg> zul: you around?
<zul> rtg: perhaps yes :)
<rtg> zul: I'm adding some definitions to include/asm-x86/mach-xen/asm/io_32.h and io_64.h. Whats the best way to do that? Its for the IO_DELAY patch.
<zul> create a patch for it and add it to the list
<zul> or you could send it to me and I could do it for you
<rtg> zul: ok, gimme a bit to get it prepared.
<zul> sure
<zul> just ping me when you are ready
<rtg> zul: I committed to the main Hardy repo. I think xen is the only flavour that does not build. It fails early on with kernel/sysctl.c
<zul> hmm..ok
<zul> grrr..
<rtg> tjaalton: if you are going to upload lrm, how about updating madwifi to 0.9.4 first?
<tjaalton> rtg: sure
<rtg> tjaalton: thanks
<tjaalton> that'll probably fix bug 182489 too
<ubotu> Launchpad bug 182489 in linux-restricted-modules-2.6.24 "Atheros wireless (AR5006EG) not working on ASUS Eee PC" [High,Confirmed] https://launchpad.net/bugs/182489
<rtg> tjaalton: I couldn't tell if the update enables some of the newer Atheros chipsets. 
<tjaalton> oh right
<BenC> I think to fix the cpufreq loss on cpu1 for suspend/resume, I may just pull 2.6.25 for the next upload
<BenC> probably will be an ABI change
<cking> BenC>
<cking> ?
<rtg> cking: he's kidding.
<BenC> you hope :)
<cking> Opps: typos galore
<cking> BenC: 2.6.25 may also fix some of the scheduling interrupts issues.
<cking> BenC: April fool'd me?
 * BenC 1, cking 0
<cking> ...well done. 
<cking> ...I am v. gullible.
<BenC> hehe
<BenC> don't feel bad, I fooled my kids into thinking the school's power was out, and they could stay home today
<rtg> BenC: oh, how cruel!
<smb> BenC: cruel was word I was missing .:)
<soren> Hm.. I'm considering syncing our virtio stuff with what's currently in 2.6.25. The trouble is that there's no way to merge cleanly with linus, because what we have now came from a different VCS, got changed, and was then imported into linus's tree, so what we have does not correspond to anything that was ever in another git tree. How would you handle this?
<soren> (please ignore the question of "why" for now)
<BenC> soren: one big patch with a thorough list of changes in the commit log
<soren> I'm considering reverting all teh commits that brought us to where we are now and then cherry-picking from linus, but that looks butt ugly in the logs
<soren> BenC: Oh, really?
<soren> Hm..
<soren> Ok, that actually sounds somewhat manageable.
<BenC> post-hardy, we'll basically ditch all of those commits
<soren> Sure.
<soren> The changes aren't really very big, but the amount of commits rewinding and the fast-forwarding again made it look *huge*.
<BenC> See, we're a reasonable bunch :)
<soren> Sometimes, perhaps :)
<soren> I'd like a few days to test it.. When was the freeze again?
<BenC> Hmm, we are actually planning an upload this evening...and the chances of another upload before release is very slim
<BenC> but not impossible
<rtg> zul: how is the IO_DELAY patch coming for xen?
<zul> need to compile test it
<soren> BenC: So you all go on holiday starting tomorrow? :)
<rtg> zul: I have compile engines if you can give me the patch
<zul> sure gimme a sec...ill put it up somewhere
<rtg> soren: we're gone until after UDS :)
<zul> rtg: http://people.ubuntu.com/~chucks/0003-xen-io-delay-fix.patch
<rtg> zul: cool
<zul> rtg: hopefully that will fix it
<BenC> If not, maybe just add a 0000-revert-iodelay.patch for xen
<BenC> rtg: is -rt or -openvz experiencing problems with iodelay?
<BenC> I'd do the revert for them instantly if so
<rtg> BenC: nope
<BenC> ok
<rtg> xen fails because of the way they generate asm includes.
<BenC> gotcha
<rtg> BenC: or rather, include/asm/mach-xen/asm includes. Its kind of weird.
<zul> yeah that totally sucks...redhat is getting dom0 to work with paravirt-ops
* 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.24-12.22 | Latest news: 2.6.24 Release in Hardy | Next meeting: April 1, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<tjaalton> rtg: madwifi-0.9.4 builds fine
<rtg> tjaalton: cool. we should have an upload later today that fixes the sparc/powerpc/hppa FTBSs.
<tjaalton> rtg: ok, I don't have any further changes, the one that was assigned turned out to be invalid
<tjaalton> of course there'll be new nvidia/fglrx tomorrow..
<rtg> tjaalton: isn't that the way it always is :)
<tjaalton> rtg: yep, a pleasure to work with :) (making new tarballs, blech)
<abogani> rtg: Sorry for Xen break!
<BenC> Hey ppl
<rtg> abogani: np. zul fixed it right up.
<BenC> Running a little late on starting the meeting...
<smb> BenC: Hi
<cking> BenC: hiya
<amitk_> here
<BenC> Basically we are jumping right into this list: https://edge.launchpad.net/ubuntu/+milestone/ubuntu-8.04
<BenC> s/edge\.// for the non-beta-launchpad folks
<BenC> Bug #188226 is the first one
<ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,In progress] https://launchpad.net/bugs/188226
<BenC> Any comments on that? I'm sort of on the fence with it
<BenC> I'm open to enabling this for certain flavours too, as opposed to all flavours
<rtg> I thought the server folks would have som e interest in this.
<BenC> default in kernel Kconfig is USER_SCHED
<rtg> does CGROUPS _require_ a user space app to configure?
<BenC> No, you can configure it with echo if you want
<BenC> but the udev/userspace stuff makes it easier to automate
<rtg> these guys say you can simulate USER_SCHED usgin CGROUPS.
<BenC> Are the tools in universe?
<BenC> right, but that's a bit much to do right before RC, I think
<rtg> agreed.
<rtg> I'm not sure that 'High' is the appropriate priority.
<BenC> Maybe this should be in server flavours, and re-evaluate at UDS
<rtg> that is what I proposedto soren awhile ago.
<cking> The scheduler cannot be all things to all men all the time
<BenC> agreed
<BenC> soren: server flavours == -server in i386/amd64, and all of sparc/hppa/ia64
<BenC> s/soren/so/
<rtg> right.
<rtg> since I'm doing test build, I can take care of it.
<BenC> Great, thanks...please update the bug report with the decision too
<rtg> just doing so...
<BenC> Bug #200057
<ubotu> Launchpad bug 200057 in linux "HP / Compaq laptops crash with port 0x80 delay write" [High,In progress] https://launchpad.net/bugs/200057
<BenC> Tim, that's assigned to you...that's fixed with iodelay, right?
<rtg> yep - fix committed.,
<rtg> i have positive feedback that it solves a problem.
<BenC> Excellent
<BenC> Bug #187671
<ubotu> Launchpad bug 187671 in linux "sdhci module hangs Everex StepNote 2053T" [Medium,Triaged] https://launchpad.net/bugs/187671
<rtg> hopefully it won't introduce regressions.
<BenC> smb: That one's assigned to you...what's the status?
<smb> This is still being debugged on kernel bugzilla
<smb> There isn't something definitive, yet. Looks like certin inb operations lock up when done in series
<smb> but not always the same. Strange timing issue
<BenC> wonder if it's hardware
<rtg> smb: will the DMI IO_DELAY patch help?
<smb> I am not sure, there is a chence
<mjg59> rtg: I doubt it - unless it's doing inb_p, it doesn't cover that codepath
<rtg> mjg59: that was kind of what I was wondering.
<smb> no, not that i know of only normal inb, inw...
<smb> but I check against that
<smb> Using readb, readl, readw...
<BenC> smb: Unless you can come up with something definitive by the end of the week, we may have to just mark it -later
<BenC> And that's the last open bug on the list
<smb> BenC: ok
<smb> There is bug 134660
<ubotu> Launchpad bug 134660 in linux-ubuntu-modules-2.6.24 "Ralink rt2400 / rt2500 / rt2570 / rt61 / rt73 do not work out of the box in Gutsy/Hardy" [High,Confirmed] https://launchpad.net/bugs/134660
<BenC> it's not milestoned for ubuntu-8.04
<smb> I am currently building a test kernel we could try
<BenC> if it needs to be looked at, please make sure it is milestoned
<smb> BenC: Its on the milestone list
 * BenC missed it
<BenC> I see it now
<BenC> smb: Ok, just to recap what we discussed earlier, if testing shows that 2.6.25 rt2x00 code works for the reporter, we'll get it in
<smb> BenC: Right
<smb> If it doesn't I would mark it as -later 
<BenC> please make sure the bug is updated with that info so folks know what our intentions are
<smb> ok
<BenC> thanks
<BenC> Anything we missed, or that needs to be added to the milestone list?
<BenC> rtg: later I want to review the dell patches I have to make sure we aren't missing anything
<BenC> Alright, that's the end of the meeting then
<BenC> Thanks everyone
<rtg> BenC: ok. Mario complained about some missing ones yesterday, but I think I got 'em since.
<keescook> hola.  any general eta on l-u-m for -13?
<rtg> keescook: uploading a kernel tonight. lum/lrm/lbm too follow.
<rtg> I could do them earlier, but the last kernel upload FTBS on all but x86/x86_64
<keescook> rtg: sweet, okay.  I was testing -13 for my kvm and aa fixes, and noticed my sound was gone.  :P
<keescook> oh
<keescook> haha
<rtg> drat. setting CONFIG_CGROUPS is gonna cause an ABI bump.
#ubuntu-kernel 2008-04-02
<rtg> zul: I'm still having problems with xen x86. x86_64 build OK. The reason is that slow_down_io() in include/asm-x86/mach-xen/asm/io_32.h uses xen_io_delay() which is not correctly exported, or at least fails to link into vmlinuz.
<rtg> zul: ok, I fixed the xen 32 bit build with a gross hack on the xen patch files to have it call native_io_delay (like x86_64) instead of xen_io_delay. Feel free to send an update, but now it at least builds.
<jiraia> hi
<jiraia> someone knows how intercept syscall with kernel 2.6 ?
<cking> jiraia: hi, perhaps looking at how strace does it is worth a try 
<kraut> moin
<abogani> Bug #177895
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895
<BenC> Good morning folks
<rtg> tjaalton: did you notice I uploaded a -14 kernel ?
<tjaalton> rtg: yes, so lrm is ready to go?
<tjaalton> I've enabled ltmodem again, gentoo had a small patch to make it compile against .24
<rtg> tjaalton: well, the kernel built for all arches. I'll bug an archive admin to ACCEPT it.
<tjaalton> and, made nvidia-glx* to depend 'lrm-VER-generic | nvidia-kernel-VER' instead of just the latter, because it's against policy to depend only on a virtual package and it's possible to get a wrong flavor kernel on upgrade
<tjaalton> like I get a -386 every time, and that doesn't even boot
<rtg> tjaalton: looks like the kernel has already been accepted into the archive. I just misread the state.
<tjaalton> rtg: cool, I'll do a test build and upload
<rtg> tjaalton: did you add openvz? I'm working on lum/lbm.
<tjaalton> hmm nope
<rtg> tjaalton: I'm wondering why you get a -386 kernel? Something wrong with meta still?
<tjaalton> no it's just apt trying to figure out what package to get to fulfill the dependancy, and uses the first in alphabetical order
<tjaalton> see bug 188287
<ubotu> Launchpad bug 188287 in linux-restricted-modules-2.6.24 "dependencies installs -386 kernel which hangs on boot" [Undecided,In progress] https://launchpad.net/bugs/188287
<rtg> tjaalton: are you whom marked it 'In Progress' ? You should assign yourself to the bug if so.
<tjaalton> rtg: yep, done
<rtg> tjaalton: thanks
<tjaalton> rtg: is -openvz needed for lrm? there's no -virtual either
<tjaalton> and rightly so :)
<rtg> tjaalton: hmm, you are probably correct. Doesn't really make sense :)
<rtg> just like there is no xen version, right?
<tjaalton> xen is different, since you run dom0 on real hw
<tjaalton> but, it's not there.. hmm
<tjaalton> I know that it nvidia_new doesn't build for it, but
<tjaalton> -it
<tjaalton> hmm, there _is_ lrm for xen
<rtg> tjaalton: right, I forget about dom0 (cause I never use xen). But, I don't think openvz/virtual is needed for LRM.
<BenC> rtg, smb, amitk, cking: http://iso.qa.ubuntu.com/qatracker/subscriptions to track what ISO testing you will be expected to do
<BenC> rtg: virtual may need to be
<BenC> rtg: openevz maybe as well. A lot of the server tools (which can be used for dom0) are GUI
<BenC> rtg: *openvz ... anyway, if it compiles, might as well build it
<smb> BenC: Hm, I see the list but I am not sure I know how to interpret it...
<rtg> tjaalton: ^^
<cking> BenC: any instructions on what to do?
<tjaalton> BenC: is openvz comparable to xen in this regard? -virtual isn't :)
<BenC> tjaalton: yes
<BenC> tjaalton: actually, you are right, we don't need lrm for -virtual
<BenC> but openvz is bare-metal and virtualized, so needs it
<BenC> (like xen)
<tjaalton> ok, I'll add it
<tjaalton> openvz is for amd64/i386?
<rtg> tjaalton: yep
<tjaalton> ok, let's see if it builds..
<tjaalton> ..all the modules
<tjaalton> wow, it did
<tjaalton> hmh, the build failed on 32bit which I need to look at more closely later this evening..
<tjaalton> in 4h or so
<rtg> tjaalton: I've upload lum/lbm. I'll do met in awhile.
<rtg> s/met/meta/
<rtg> tjaalton: I stuck you on Bug #122703 in case the madwifi 0.9.4 update supports AR5008.
<ubotu> Launchpad bug 122703 in linux-restricted-modules-2.6.24 "Upgrade Atheros drivers to snapshot/trunk to support AR5008" [Low,In progress] https://launchpad.net/bugs/122703
<rtg> zul: did you review the xen fixes I hacked in yesterday?
<zul> rtg: sorry was on a call no I havent
<rtg> zul: please have a look and make sure I've have not totally screwed the pooch.
<rtg> zul: you should probably produce a better fix then what I've done.
<zul> yeah, looks ok to me
<blueyed> Does it make sense to provide virtualbox modules for Xen and OpenVZ kernels? IMHO yes, but I may be wrong. There are some for -virtual already.
<zul> blueyed: no it doesnt for xen 
<blueyed> zul: but you could run virtualbox inside of xen, can't you?
<zul> blueyed: maybe but if you are running xen then you want to run xen
<blueyed> zul: yes, I see. I don't say that it's a common use case, but I can see it. E.g. a bigiron server running Xen machines and virtualbox, too.
<zul> its overkill IMHO
<Solarion>  7285 solarion  20   0  220m  41m  15m D  100  4.1 163:07.83 totem              
<Solarion> cat /proc/7285/mem says "No such process"
<Solarion> how does this make any sense?
<BenC> Solarion: what doesn't make sense?
<Solarion> it's sleeping but eating 100% cpu
<Solarion> mem says no such process
<BenC> sounds like a kernel bug or similar
<Solarion> that would be why I'm here
<Solarion> I want it dead.  :)
<BenC> reboot
<Solarion> don't want to figure out the kernel bug with me?
<Solarion> I hate rebooting
<BenC> check dmesg
<BenC> but to get rid of it, you have to reboot
<Solarion> dmesg says nothing
<Solarion> ah, D is "disk sleep"
<BenC> I thought you knew that...the D is IO wait, basically
<Solarion> I didn't, but I'm figuring it out as I go along
<Solarion> the question is what is the kernel spinning on
<BenC> block device reads most likely (especially if it's playing as cdrom or something)
<BenC> cat /proc/7285/wchan
<Solarion> 0
<Solarion> what is wchan?
<BenC> hmm...wchan doesn't seem to be producing useful info anymore
<Solarion> io isn't budging
<Solarion> (watch cat io)
<BenC> wchan is the function where the process is sleeping in the kernel
<BenC> Solarion: well, not much info to go on...I'd say reboot is your only option at this point
<Solarion> I want to know what happened tho
<Solarion> so it doesn't happen again
<BenC> So far, there's no way to see that
<BenC> you could try "strace -p 7285", but I suspect strace will lock up as well
<Solarion> it does
<Solarion> can you reset the ulimits?
<BenC> ulimits have nothing to do with it
<Solarion> e.g. make max open files 1 or something ridiculous?
<Solarion> part of it is trying to figure out how to kill it creatively. :)
<BenC> you can't
<Solarion> rebooting has no panache
<BenC> you cannot kill a 'D' state process
<BenC> it's stuck, and you have no choice but to reboot
<Solarion> and there's no way of figuring out where it's stuck and why?
<BenC> I've exhausted the known ways of figuring that out
<Solarion> stupid horked thing
<Solarion> wonder what totem is doing with xulrunner
<Solarion> totem   7285 solarion   44u  sock        0,4           1464374 can't identify protocol
<Solarion> what is that (lsof output)?
<tjaalton> rtg: seems like it's not in 0.9.4
<rtg> tjaalton: bummer.. then new AR5008 users are screwed for now.
<tjaalton> rtg: yeah
<infinity> rtg: Is there a new LRM on the way..?
<rtg> tjaalton: ^^
<infinity> rtg: Updating -meta without updating LRM seems suboptimal. :)
<rtg> infinity: it shakes out eventually, doesn't it?
<infinity> rtg: Err, no...
<infinity> rtg: If you update meta first, kernels get upgraded without LRM.
<infinity> rtg: "linux-image-generic" gets upgraded, pulls in the new kernel, while "linux-generic" and "linux-restricted-modules-generic" get held back.
<infinity> rtg: So, boom, anyone not paying attention will reboot and have no network, video, whatever.
<rtg> infinity: my bad. I must not have any boxes using LRM or I would have noticed.
<infinity> rtg: Well, yes, it's my own fault for using evil binary blobs, but I suspect I'm not alone. ;)
<rtg> infinity: probably not.
<infinity> Anyhow, if LRM doesn't have a mess of pending changes, you could just do the ABI bump and upload to keep me happy. :)
<infinity> (If it does, you could still do the ABI bump, then followup with another upload later)
<tjaalton> infinity: I'm still figuring out why 32bit build fails now
<tjaalton> the -server flavour
<infinity> tjaalton: Oh, ick.
<infinity> tjaalton: Which module?
<tjaalton> nv.c:14:
<tjaalton> include/xen/interface/memory.h: At top level:
<tjaalton> include/xen/interface/memory.h:32: error: expected specifier-qualifier-list before 'GUEST_HANDLE'
<tjaalton> that's nv-new
<infinity> tjaalton: The most obvious question here is "why are we building nv stuff for -server at all?"
<infinity> I'm pretty sure I didn't back when I maintained it..
<rtg> infinity: a surprising number of folks run the -server flavor on their desktop
<tjaalton> infinity: because someone want's to use vast amounts of memory on a workstation
<infinity> rtg: Which is, I suppose, their problem, not ours. ;)
<infinity> tjaalton: Define "vast"...
<tjaalton> 16gig?
<rtg> infinity: oh, I think some of the use is legitimate. 
<infinity> See, 16GB doesn't sound that excessive to me anymore.
<infinity> What's the -generic kernel currently top out at?  (My laptop only has 4GB, which works fine, so I'm not sure)
<tjaalton> mine too has 4Gb
<tjaalton> GB even
<tjaalton> anyway, 64bit build works fine
<tjaalton> something has changed in the headers?
<infinity> I'd guess.
<infinity> Time to get to bisecting? :/
<tjaalton> well tbh it's not the latest headers it's using, but the first -13 upload
<tjaalton> I'll update the mirror
<rtg> tjaalton: the big change with server was CGROUPS, which seems to have fundamental effect on some low level macro. 
<tjaalton> oh, I'm still building -13 :P
<rtg> tjaalton: there were about a zillion ABI changes which is what forced the ABI update.
<rtg> tjaalton: you definitely need -14 headers.
<tjaalton> hah, time to bump the abi again
<tjaalton> yep..
<rtg> tjaalton: ok, I'm outta here for awhile. I'll check back in a few hours.
<tjaalton> rtg: ok, hopefully this works by then
<tjaalton> infinity: btw, check bug 188287 and the proposed solution (included in the lrm I'm testing). anything alarming you see?
<ubotu> Launchpad bug 188287 in linux-restricted-modules-2.6.24 "dependencies installs -386 kernel which hangs on boot" [Undecided,In progress] https://launchpad.net/bugs/188287
<tjaalton> hm, still no -14
<tjaalton> ..but now
<infinity> tjaalton: Well, "pure virtuals" violate policy, but in this case, it's hard to define a "preferred package", which is why it's always been this way...
<infinity> tjaalton: (For the record, this bug has existed for 3+ years)
<tjaalton> infinity: a tough one
<infinity> tjaalton: And only triggers during development cycles, generally, since we don't often update the nvidia drivers in released dists.
<infinity> (so, nvidia-kernel-$ver doesn't bump)
<tjaalton> infinity: but it does bump for dist-upgrades
<infinity> tjaalton: Yeah, true.  But the dist-upgrader can be taught to cope with that.
<infinity> tjaalton: And we don't technically support people doing raw apt-get dist-upgrades.
<infinity> (We support packages not being absolutely broken, but we don't support people blindly telling apt "yeah, your package selection looks sane, I totally want 3 new kernels, and a removed openoffice!")
<tjaalton> infinity: I've also seen it doing a fresh install by preseeding the package list with nvidia-glx on it, but it doesn't always do that
<infinity> tjaalton: Yeah, if you ask apt to install "nvidia-glx linux-generic", it will install "nvidia-glx, lrm-386, linux-generic", because of its brain-dead dep resolution policy.
<infinity> It goes for "fastest loop unrolling" rather than "path of least possible system change" (which, say, dselect does)
<infinity> tjaalton: The problem with the proposed solution is that it just shifts the bug to all the other kernel:nvidia combinations, while appearing to "fix" it for generic.
<infinity> tjaalton: Given our general preference for generic, that may be a win, just pointing out that it's no more correct. ;)
<tjaalton> infinity: anyway, I'll drop the change for now, since it needs further discussion
<infinity> tjaalton: Given that one can never guarantee a kernel interface is there (because, y'know, the user might not reboot before hitting Ctrl-Alt-Backspace and blowing up X), I've often wondered if dropping the dep entirely, or even just lowering it to a Recommends, might not be out of line.
<infinity> tjaalton: userspace:kernel dependencies are much harder to enforce than kernel:kernel or userspace:userspace, since we have no control over which grub option they select on boot.
<tjaalton> hmm.. true
<infinity> tjaalton: One will note that the fglrx packages have no such painful userspace:kernel dep.
<tjaalton> infinity: because there's only one version?
<infinity> tjaalton: No, the driver->kernel dep is OLD... Predates the multiple version thing.
<infinity> tjaalton: It's just inherited from the Debian nvidia packaging.
<tjaalton> oh
<infinity> tjaalton: The multiple version thing is a red herring, since the LRM packages provide all 3 kernel modules.
<tjaalton> yep
<infinity> tjaalton: But, yeah, in every release cycle, I see maybe one complaint about fglrx lacking a kernel dep, and dozens of complaints about the nvidia kernel dep being broken.
<infinity> tjaalton: Given that fantastic bit of statistical analysis, I'd say the fglrx situation is "less broken".
<tjaalton> infinity: hehe :)
<tjaalton> now it builds, the xen patch messed things up
<infinity> tjaalton: Is "it builds" code for "I'm uploading it"? :)
<tjaalton> infinity: you bet :)
<tjaalton> infinity: I dropped the nvidia-kernel* dependencies
<infinity> \o/
<tjaalton> ok, uploading..
#ubuntu-kernel 2008-04-03
<tjaalton> rtg: lrm is now uploaded, and I need some sleep :)
<infinity> tjaalton: Danke.
<kraut> moin
<munckfish> Hi, I hope this is on-topic enough - I'm updating kboot for ps3 (LP bug 146230). It comes bundled with it's own kernel source (2.6.24) ...
<ubotu> Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230
<munckfish> Could someone offer any advice on what I should do about "syncing" it with the Hardy kernel?
<munckfish> E.g. should I take a snapshot of the hardy kernel and include that within the ps3-kboot package? Or is there a more elegant solution?
<munckfish> Also how important is it that the kboot kernel and ubuntu kernel are the same?
<munckfish> thx
<phoenix_> Hi there, I reported a bug #199934, which is causing hardy to panic upon reboot in the raid device driver - and the bug is still 'undecided' and I just wanted to know what I can do, to get some attention to get it fixed for -release
<ubotu> Launchpad bug 199934 in linux-meta "Kernel Panic, in gdth (RAID) driver on reboot" [Undecided,New] https://launchpad.net/bugs/199934
<munckfish> cjwatson: have you got a moment to chat about ps3-kboot?
<cjwatson> munckfish: BenC will really be better for that, once he's around
<cjwatson> (he's US Eastern time)
<munckfish> cjwatson: ok thx I'll look out for him later. thx
<Whoopie> soren: Hi, I'd have a question about the virtual kernel package. When I use the vmxnet driver in the VM, I have to select "wired network" each time I log in. Is the driver lacking some features which NetworkManager needs?
<BenC> Good morning everyone
<amitk_> Morning BenC 
<rtg> amitk_: I see the wimax firmware disappeared.
<BenC> brb, testing my vzw evdo card
<BenC> sweet, evdo card works
<munckfish> BenC: Hi have you got a moment to talk about ps3-kboot?
<munckfish> I'm working on LP bug 146230
<ubotu> Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230
<BenC> munckfish: Sure
<munckfish> Great
<munckfish> basically I'm half way to getting it to compile
<munckfish> as is, from upstream
<munckfish> Now, it bundles kernel 2.6.24
<munckfish> What should I do about "syncing" it with the Hardy kernel?
<munckfish> Should I take a snapshot
<munckfish> of the hardy kernel source
<munckfish> and put that into the source tarball?
<munckfish> Or is there a more elegant solution?
<BenC> No
<BenC> just use what they have, stock
<munckfish> Aha, ok
<BenC> it's only used for first stage loader, it's not what the system uses to boot
<BenC> the end boot results will be out powerpc64-smp kernel
<BenC> *our
<munckfish> Ok great that makes things simpler :)
<munckfish> Right then, well I'll cont. working on it.
<munckfish> I have all evening Friday put aside
<munckfish> hopefully I'll have something to show next week
<munckfish> thanks
<rtg> BenC: so who do you have service with for your evdo card?
<BenC> rtg: verizon
<rtg> USB?
<BenC> rtg: it had to be activated via windows, but easy to setup after
<amitk_> when are you guys getting WiMAX rollouts?
<BenC> rtg: it's USB, but it's one of the dell provided cards that fits into the internal wwan slot
<rtg> BenC: I think I have one of those.
<BenC> pretty sure jose sent you one when he sent me one
<Whoopie> BenC: Hi, do you perhaps know why NetworkManager doesn't activate "wired network" with the vmxnet driver? After each login, I have to enable it.
<mjg59> It doesn't provide carrier detect?
<Whoopie> mjg59: aha, ok. I read something about it on http://blogs.gnome.org/dcbw/2008/02/18/hey-vmware-set_netdev_dev-wants-a-word-with-you/
<Whoopie> it seems that vmxnet supports carrier detection, but NetworkManager is not able to find it out.
<thoreauputic> mjg59: thanks for getting the ball rolling on bug 201591 - looks like all is well with 2.6.24-14 :)
<ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Medium,Fix released] https://launchpad.net/bugs/201591
<mjg59> thoreauputic: Excellent
<thoreauputic> finally! Now I can pursue my eccentric little no-X project with a hardy version
<thoreauputic> anyway, I thought I'd drop in and say thanks, because you took the trouble to start the process with your patch etc.
<mjg59> Yeah, it was my fault to begin with
<thoreauputic> really?
<thoreauputic> ah well - all's well that ends well and other conventional sentiments...
<thoreauputic> :)
<mjg59> Hm
<mjg59> acx111 just blew away my kernel
<dhaval> any clue where I will find Tim Gardener?
<rtg> dhaval: yes?
<dhaval> rtg, regarding BUG 188226
<ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,Fix released] https://launchpad.net/bugs/188226
<dhaval> CONFIG_FAIR_CGROUP_SCHED is arch independent
<rtg> dhaval: as far as I could tell, it is not supported on non x86/x86_64 arches (which I found a bit surprising)
<dhaval> rtg, it is arch independent. i have resolved fair_cgroup_sched bugs on ia64 and ppc
<rtg> I went through the menuconfig options manually, but no CGROUPS selection presented itself.
<dhaval> rtg, you need to have CONFIG_CGROUP on for that
<rtg> is the a prerequisite ?
<dhaval> it depends on that
<dhaval> well, how else would you do cgroup scheduling :)
<rtg> hmm, lemme recheck.
<rtg> I was in  a hurry at the time.
<dhaval> hmm. you had us a bit worried
<dhaval> rtg, i still suggest, keep cgroup_sched as default
<rtg> shit. you know thats gonna cause another ABI bump.
<dhaval> itwill save you a lot of bugs like that boinc one
<dhaval> rtg, hmm?
<rtg> its not a big deal, but does cause some process work for the archive admins.
<dhaval> ok. well i have been hollering for cgroup_sched for months now :)
<rtg> I have to point out that you are a small (but vocal) minority. I have not been able to extract an informed opinion from the server group.
<dhaval> trust me, it would make life a lot easier. you would have old behavior and if you wanted group scheduling, you just have to mount it
<dhaval> rtg, heh, i wrote part of that code :)
<rtg> as I pointed out in the LP report, its the addition of user space configuration that is causing me problems. Its more of a policy restriction given the development stage we are at. Hardy is about to release.
<dhaval> rtg, i have been hollering for months. i don't have any issues.
<dhaval> but you are going to get a number of "bugs" because people are not going to be aware of the changed behavior
<rtg> I'll get CGROUPS in the server image, but I'm not willing to mess with the desktop until we start Intrepid next month.
<rtg> Those who really care can run the server image on their desktop.
<dhaval> rtg, people are *NOT* going to be aware of the new scheduler behavior
<dhaval> they are going to find that they get 50% cpu and daemons get 50%
<dhaval> and nice can't help them there.
<dhaval> you will get bugs raised on that, and you will have to come up with workarounds.
<dhaval> the suggested solution is to shift to CGROUP_SCHED, which as I mention i have been suggesting for months now :)
<rtg> in all honesty, 99% of desktop users don't care. I'll point out the alternatives when I have to.
<dhaval> rtg, ok, i will let you be the judge on that. its your decision in the end..
<rtg> CGROUPS is definitely in the cards for Intrepid.
<dhaval> rtg, btw, could you mention that fair_cgroup_sched is arch independent on that thread, esp since that might come up on google searches and we don't want ubuntu bz to give wrong results
<rtg> yes - as part of updating the configs.
<dhaval> rtg, might I also suggest to try playing with the memory controller, which allows you to control memory.. :)
<rtg> i'll get it into the LP report.
<dhaval> rtg, thanks!
<rtg> dhaval: what about  CONFIG_CGROUP_NS and CONFIG_CPUSETS ?
<dhaval> rtg, cpusets will allow you create groups of CPUs/memory banks
<dhaval> you can then put tasks and set them to run only on those cpusets
<rtg> dhaval: so you recommend enabling those options as well?
<dhaval> ns is still a black hole for me.
<dhaval> rtg, ns, i suggest you get in touch with their developers.
<dhaval> i believe cpusets is quite stable.
<rtg> dhaval: you would be just as happy with just cpusets?
<dhaval> rtg, did not get the question
<rtg> dhaval: sorry, l meant would you be ok with only enabling CONFIG_CPUSETS ?
<rtg> do you actually use either option in practice?
<dhaval> rtg, i am not sure if desktop users would be interested in cpusets.
<dhaval> or ns proxy.
<dhaval> as a user, i don't use cpusets or ns
<rtg> dhaval: ok, since their use is optional I'll enable them as well.
<dhaval> i do use cgroup scheduling though when i want to control how my system is running as well as the memory controller to trap firefox/openioffice
<dhaval> rtg, this is for intrepid right?
<blueyed> Doesn't cpusets depend on cgroup?
<dhaval> blueyed, yep, all thesedepend on cgroup
<blueyed> dhaval: thanks for bringing this issue up again here.
<blueyed> rtg: I've been also pondering about this, since 2.6.24 hit Hardy..
<rtg> dhaval: I was going to enable cpusets and ns for Hardy server.
<dhaval> blueyed, i did not know about the existence of this channel, otherwise i would have been hollering here earlier
<blueyed> it's really a regression for users/desktops..
<dhaval> blueyed, well, we can agree to disagree :)
<dhaval> blueyed, i call it expected behavior
<dhaval> rtg, i just talked to upstream folks, they like the idea, it will get it wider coverage
<blueyed> dhaval: I'm for cgroups.. because it's the old behaviour, I mean.
<dhaval> rtg, thanks a lot for listening!
<dhaval> blueyed, yeah, i aree
<rtg> dhaval: the new kernel package should show up by morning (UTC-8)
<dhaval> rtg, thanks, i should set up hardy-rawhide or something like that on a virtual machine
<blueyed> rtg: with cgroups only for server, still?
<dhaval> blueyed, rtg i would still suggest desktop as well, but its your decision in the end, not mine
<rtg> dhaval, blueyed: its actually not _all_ my decision. the kernel team discussed the ramifications, and being a generally conservative bunch, decided to only enable CGROUPS for servers.
<dhaval> rtg, i wish they would have involved us in the discussion as well
<dhaval> we could have provided you with more information
<rtg> well, better late then never :)
<dhaval> being conservative, i would have suggested cgroup and not user
<blueyed> rtg: I've scammed the irclogs about this, and it seemed to just have been rushed over.
<dhaval> user is more dangerous, because of the "bugs" that will surely crop up as blueyed will confirm
<rtg> blueyed: it may well have been, being somewhat ignorant of the issue myself.
<blueyed> rtg: not fair.. I've been here before, there have been several bug reports it, etc..
<dhaval> rtg, fwiw, why don't you guys get upstream folks involved as well?
<blueyed> It has just been ignored and then "too late now..."..
<dhaval> blueyed, i agree..
<rtg> its a matter of volume. there are few of us, and literally thousands of bug reports.
<rtg> the stuff that gets my attention are hard failures.
<blueyed> rtg: you could have saved some time, by listening to this issue earlier.. ;) "upstream" (dhaval) came to us even..
<dhaval> rtg, hmm. that is where getting upstream more closely involved would help
<dhaval> rtg, fwiw, i don't use ubuntu and this experience made me feel like using ubuntu even lesser
<rtg> come on you guys, quit beating me up. I can on;y do so much.
<dhaval> rtg, sorry! not meant to beat you up.
<dhaval> but lesson to be learnt. do involve upstream
<dhaval> we all want linux to get better
<blueyed> rtg: sorry, we're not beating.. but finally somebody seems to listen, so..
<rtg> I'm working on it. like I said, I'll have a CGROUPS server release in the morning.
<dhaval> rtg, if you do hit scheduler bugs, do report it up, most of the folks are very responsive
<dhaval> rtg, fwiw, it holds for all subsystems
<rtg> will do
<dhaval> remember, we all want to make Linux better :)
<blueyed> rtg: thanks. Do you understand the issue for desktop users, too? Having processes in the background (cron, daemons, especially owned by root [because it gets 2000 by default in user_sched]) makes the foreground/user's tasks slow. IMHO it's even more important for the desktop then for the server.
<blueyed> rtg: can you please bring this up in the kernel-team again?
<dhaval> blueyed, thanks for putting it up so clearly, thta's what i have been trying to say
<dhaval> rtg, i have to agree with blueyed 
<rtg> blueyed: I'll raise the issue. I'll even post a PPA kernel for testing.
<dhaval> what is PPA?
<blueyed> rtg: great. I would have put one in my Personal Package Archive (PPA) anyway.
<rtg> dhaval: Personal Package Archive.
<dhaval> blueyed, thanks!
<dhaval> rtg, thanks!
<blueyed> (or installed -server), but all that won't help normal users.
<dhaval> blueyed, i would suggest custom sched-devel kernel :)
<blueyed> Thank you, dhaval. Also with bugging me about properly working around in boinc.. :)
<blueyed> sched-devel?
<dhaval> blueyed, that is the tree for the next kernel release. (currently aimed for 2.6.26)
<blueyed> dhaval: don't ask for too much.. ;)
<dhaval> blueyed, ah, np. (that part of the code i had written (and believe me, sysfs is a big pain to work with!), so all the hard work had to be seen in action :P )
<dhaval> rtg, blueyed are there any resources on how i can setup the ubuntu-devel branch?
<dhaval> let me just set it up in a virtual machine
<rtg> dhaval: there is some wiki info. lemme find it.
<rtg> https://wiki.ubuntu.com/KernelMaintenance
<dhaval> rtg, oh, i meant something similar to fedora's rawhide which is a daily build of how fedora looks?
<rtg> dhaval: not knowing how the rawhide stuff works, I'm not sure what to tell you. I have not enabled the daily kernel build stuff yet. Its on my list for Intrepid.
<rtg> there is agit repo.
<rtg> s/agit/a git/
<dhaval> rtg, oh ok, so what fedora does is that it builds the whole distro every night and you do a yum update to get updated fully. is there something similar for ubuntu?
<dhaval> if i can set that up, I can get you more feedback than I can do now
<rtg> dhaval: no, the distro is only built on demand, e.g., when a package update is uploaded.
<dhaval> hmm. ok.
<dhaval> right, that's similar to rawhide.
<dhaval> what i meant by rebuild was that you have a daily build. the updates are pushed out once aday
<rtg> the updates are pushed to the archive as soon as an archive admin pushes them, about once an hour.
<rtg> that is, after the build completes.
<dhaval> ok, so is there some documentation about that? i can't really find my way through the ubuntu wiki. Contribute brought me to a completely unexpected page :(
<rtg> dhaval: its all based on the debian way of doing things. Its such a deep topic I'm not sure where to tell you to start. I've only been doing it for just over a year.
<dhaval> rtg, oh. ok, proably another day then.
<dhaval> rtg, i won't be lurking about here, but feel free to let me know by email if I can help
<cradek> yay, my framebuffer console (radeon) works again with -14
<rtg> dhaval: ok. thanks for the pointers.
<dhaval> rtg, np. hope to see the cfs group scheduler in action and making people more happy with its responsiveness. btw, i've given a pointer to a daemon in the LP mail if you want to simulate user scheduling with cgroup_sched
<dhaval> rtg, i did have one more question
<rtg> dhaval: yes?
<dhaval> rtg, how does one get packages in ubuntu? i'm working on a userspace library for control groups known as libcg, (http://libcg.sf.net)
<dhaval> do you need sponsors and such stuff?
<rtg> dhaval: right, they are called MOTU sponsors.
<dhaval> if this is totally off topic, just point me to the right channel
<rtg> dhaval: is there an #ubuntu channel? Its likely a good place to start.
<dhaval> that seems like a user channel and /join #ubuntu-devel gave me * ubuntu-devel :That channel doesn't exist
<dhaval> hmm. i seemed to have made a stupid mistake
<dhaval> mised the #
<rtg> dhaval: if that doesn't work out, send an email to Daniel Holbach <dholbach@ubuntu.com>
<dhaval> rtg, thanks! i found #ubuntu-motu
<rtg> ok, I'm ducking out for a bit.
<dhaval> hmm. that channel seems awfully quiet
<dhaval> rtg, ok, thanks!
<blueyed> dhaval: just get the beta release (or daily live cd), install it and then you can upgrade from there, as the package get built/uploaded.
<dhaval> blueyed, link to the daily live cd?
<blueyed> dhaval: http://cdimage.ubuntu.com/daily-live/current/
<blueyed> (from google :p)
<dhaval> blueyed, thanks!
<dhaval> blueyed, too lazy, its too late here. i am supposed to be asleep about 2 hours back
<tjaalton> is lbm meant to be a staging area for proposed updates to lum?
<liquidhackz> irssi quit
<tjaalton> blueyed: you did the acpi-support update? I'm not sure if that's to blame, but the suspend hotkey doesn't work on my thinkpad anymore since some recent update
<num> hello, i've done an hardy upgrade, which downloaded a new kernel 2.6.24-14, when i now boot my notebook it hangs on every new boot on a different driver. once at the iwl3945 driver loading, once at the ricoh-mmc driver. may there be something i miss or isn't done automaticaly?
<Nafallo> num: I would try a memtest :-)
<num> a memtest?
<num> Nafallo: but a memtest that urly during boot?
<Nafallo> num: esc during the grub menu and choose memtest
<num> Nafallo: you suppose a damaged memory?
<Nafallo> that's one of the first things I check. sounds like some kind of hardware issue at least.
<num> i can't believe this, since i'm on this machine with the kernel version below, xx-12
<num> and no problems
 * Nafallo shrugs
<Nafallo> I just say what it sounds like to me. and never said that it was the actual issue.
<num> Nafallo: i thank you
<num> i appreciate any ideas, help
<Nafallo> :-)
<num> what i also saw was, that my wireless is a iwl3945, and kernel -12 shows the device as 3945ABG and the new kernel -14 shows it as 3945AB
<blueyed> tjaalton: I don't think it was acpi-support. There have been some generic hotkeys been reported lately.. do you have a bug report? What laptop do you have?
<Ng> is there intended to be another kernel build before release? or is 14 likely to be it barring any disasters?
<rtg> Ng: one more ABI bump tonight.
<rtg> I did n't get CGROUPS set correctly on all arches.
<Ng> erk
<Ng> oh well, I was probably going to have to maintain my own lum, I can do the same with the kernel. damn new hardware ;)
<rtg> the joys of open source?
<Ng> it cuts both ways, I've had all of the major hardware glitches worked out within a fairly short time of contacting upstream projects, but it's been harder to get the fine details locked down enough to push for inclusion
<Ng> and I can make easily enough make a PPA for people with the same hardware
<rtg> Ng: what hw do you have that we are not supporting?
<smb_tp> Ng: You solved your camera problem
<smb_tp> ?
<Ng> rtg: audio chipset and usb camera
<Ng> smb_tp: I think so, yeah
<Ng> well I didn't, upstream did :)
<smb_tp> Ng: I guess somewhere in this wretched find_control. Maybe you can give me the pointer. Or did you just get the latest driver?
<Ng> smb_tp: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/200990/comments/10
<ubotu> Launchpad bug 200990 in linux "[hardy] oops when running cheese on Thinkpad X300" [High,Triaged] 
<smb_tp> Ng: Just missed that by seconds, hmpf. ;-)
<Ng> hehe
<Ng> I've not tried applying it to hardy source yet, working with upstream tarballs is a lot quicker for building one tiny driver ;)
<smb_tp> Ng: yeah, but looks tiny enough to be ok and if that fixes your oops its one less on the bad list. rtg: would that be alright to push into lum?
<rtg> smb_tp: looks fine. It demonstrably fixes the issue?
<smb_tp> rtg: So says Ng but i can put that in and make a test module
<rtg> smoh, I missed that port. I trust Ng. (must be getting late)
<rtg> s/smoh/oh/
<smb_tp> rtg: It really is. :)
<Ng> if you can make a test module with our version of uvc I'd be very happy to test it since I've only tested it with the latest upstream svn. I could try building it myself, but it might take some time ;)
<rtg> smb_tp: make it so. I'll get it before I upload later this evening.
<smb_tp> rtg: I'll try my very best...
<Ng> thanks :)
<infinity> Ng: What did you do to earn this bizarre level of trust?
<infinity> Ng: Has rtg *seen* terminator?
<Ng> infinity: I'll have you know that more than one respected member of the distro team uses it! ;)
<infinity> Ng: Can you name them, or have they begged for anonymity? :)
<rtg> infinity: I trust him because he could delete all of my accounts. wait - is that a bad thing? I could go on vacation again.
<infinity> rtg: I can prevent you from ever building anything again; do my patches get similar treatment? :)
<rtg> infinity: only if you attach them to the LP report :) its so easy that way...
<infinity> rtg: That's so much more effort than just directly committing them.
<Ng> infinity: I might choose to protect them from association with the unfair treatment terminator gets, and the irony is that the haters all use gnome-terminal, which is hardly a paragon of quality ;)
<infinity> Ng: xterm's where it's at!
#ubuntu-kernel 2008-04-04
<smb_tp> rtg, Ng: done, and pushed
<Ng> :)
<smb_tp> Good time to go home ;-)
 * smb_tp leaves
<abogani> cking: Good morning Colin.
<abogani> cking: Do you have a minute for me?
<cking> Hi there...
<abogani> About Bug #177895...
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895
<abogani> First of all: Please discard all my previous patch.
<cking> ..yep.. the on going scheduler issue :-)
<abogani> Tonight after a long git-bisect session i think to have found a fix for it. 
 * abogani already have drank two coffe... :-)
<abogani> It isn't a very fix because it isn't remove the problem completely. Anyway it reduce the wrong behaviour a lot. To achieve the same behaviour of .25-rc8 are necessary 8 commits at least. These commits change heavily scheduler (a lot of LOC are touched). IMHO It isn't a viable way.
<cking> ... OK .. there definitely is a fix upstream but it's very entangled in a series of patches ...
<abogani> For this reason this night i have tested every commits to found the most adeguate commit (with a reduced number of changes). I'm sure that you are happy to know that the best one is an one-line patch! :-)
<cking> .. a one liner? !
<abogani> This mitigate a lot the problem on my laptop. Unfortunately i have only one pc (my laptop) so i can't do exhaustive tests! Could you check if that fix works on you pc also?
<cking> I would love to test this one.. 
<cking> .. in 64 bit and 32 bit x86 tests too!
<abogani> I'm sure that BenC don't accept it for Hardy release! ;)
<abogani> cking: How many pc have you?
<cking> ...we will have to see... no promises on how it gets into the hardy release..
<cking> I have 2 pc's, but I can run amd64 and 32 bit - with a duo core.
<cking> The good news is that I can exercise the core in such a way to manifest this bug
<cking> ..with a combination of amarok and other "interesting" apps :-)
<abogani> :-)
<abogani> cking: Ok! The commit is 33b0c4217dcd67b788318c3192a2912b530e4eef (Ingo Molnar)! Good test! Please let me know i hope that this night was good spent and thanks a lot! :-)
<cking> abogani: I tested the same bug against linus' kernel tree yesterday and the bug did not occur so intensely. I will test this one out..
<cking> Good work in tracking this down to one commit. I owe you a beer! 
<abogani> BenC promised me a Big Mac! Together a beer i have a good meal! :-)
<cking> abogani: I am sure we can do better than a Big Mac.. :)
<abogani> :-)
<cking> I will get this built in a couple of hours and try to thrash it over the next day or so to see how it performs.
<abogani> Ok. Thank you very much.
<cking> I think I'm the one who owes you the "thank you"
<ph8> Hey guys! Is there any way I can see the changelist for a kernel package (the ubuntu-xen kernel variant)?
<ph8> * changelog
<abogani> ph8: First open changelog file with less /usr/share/doc/linux-image-2.6.22-14-xen/changelog.Debian.gz (it isn't Xen specific) thus search for xen with /xen [ENTER]
<ph8> cheersÂ¬!
<ph8> I don't suppose anyone here works on Xen and fancies talking about the error when the whole system freezes when it starts swapping?
<ph8> i think it's related to/the actual cause of 'System Crashes on high I/O'
<ph8> which is all over the place
<abogani> ph8: Sorry i'm don't work with Xen at all so i don't know how works proceed.
<enseven> Hi! Are there any precompiled vmware tools kernel modules for Ubuntu 8.04Beta? Compiling vmware tools modules with the installer always fails. How do I install the tools?
<rtg> tjaalton: do you have time to roll the ABI for LRM and apply a patch from doko at http://people.ubuntu.com/~rtg/lrm.diff ? The ABI is -15.
<pwnguin> rtg: 404
<tjaalton> rtg: sure
<rtg> tjaalton: lemme get that path correct
<tjaalton> got it
<rtg> tjaalton: the patch?
<tjaalton> rtg: yep
<rtg> tjaalton: ok, thanks. I gotta leave for an hour or so. back in a bit.
<abogani> cking: I suppose that i have lost a beer! ;)
<cking> abogani: not at all - it was probably the best looking fix that I've seen so far for this problem.
<cking> it's just that when it came to the fine analysis it proved less useful in practice - but it's hard to tell until it's been thrashed out.
<abogani> Probably it required the other relative commits.
<mjg59> rtg: Do you know if the acx driver is actually working for anyone?
<tjaalton> doko: lrm.debdiff> there already is libnvidia-tls.so in /usr/lib, but you want to use the one in /usr/lib/tls in favour of that one?
<doko> tjaalton: yes, please read the debian report in the glibc task
<tjaalton> doko: got it
<smb> rtg: Do you have a minute or are you rather busy?
<rtg> smb: what up?
<smb> rtg: I need some help to decide how to proceed with the rt wireless driver
<rtg> smb: as in "should I bother?" 
<smb> rtg: Not quite. From test and some feedback from upstream (IvD) the driver in the kernel (even in linus) will not fix the problems
<rtg> smb: if its not fixed upstream, then what do you expect that we can do?
<smb> rtg: So the way to go would be lbm and the latest version from serial monkey (which is a linux-tree with "enhancements")
<rtg> smb: that is my opinion.
<smb> rtg: I had already started with something but this will somehow take longer since the driver requires its own mac80211 (much more advanced than kernel)
<mjg59> smb: If you're pulling drivers that need new mac80211, it might be an idea to look at the mac80211 port of acx
<rtg> smb: yeah, its similar in effort to what I did for iwlwifi in Gutsy (and ported to Hardy)
<smb> rtg: And that mac80211 in turn uses stuff from other wireless base modules that are more ahead than the current kernel as well
<mjg59> smb: I'm not sure if it would help, but trying to use my acx111 with either the code in lum or the latest non-mac80211 driver from upstream just oopses on me
<rtg> mjg59: are you having problems with acx?
<mjg59> rtg: Yeah, it's not working at all
<rtg> mjg59: is that modern hw that I can purchase?
<mjg59> rtg: I'm testing on x86_64, though
<mjg59> rtg: Not to the best of my knowledge
<rtg> mjg59: I take it the driver is running, but just not working. if I remeber correctly, that is using the kernel mac80211 stack.
<smb> rtg: To me it seems as something, that has to be very carefully ported, since there might be structs that are now different but go unnoticed when using newer headers with some older ones
<mjg59> rtg: No, it's not using mac80211
<rtg> smb: you have to fully isolate any mac80211'isms from the mainline kernel. the rest of the network stack should be OK.
<mjg59> rtg: On attempt to connect, the kernel oopses
<smb> rtg: Not only. I already found some stuff needing newer net/wireless 
<rtg> mjg59: well, at least that is easier to find then a mac80211 state transition problem.
<mjg59> Hrngh. Oops scrolls off the screen. Let me try that again.
<smb> rtg: There is a wireless-compat project but what they do is to put the whole bunch of wireless infrastructure modules into a moddir that overrides kernel
<rtg> smb: given the state of wireless in general, its possible that we will just have lousy support for rt. until I dig ito it myself, I can't really offer an informed opinion. I spent 3 days on the Gutsy iwlwifi stuff.
<smb> rtg: So that is not usable, too
<rtg> smb: I'm OK with overriding kernel components (if it works)
<smb> rtg: As long as this woulnd't affect other lbm wireless drivers. The iwlwifi uses unly its own mac80211. What it seems to come to is that maybe it can be put somehow into lbm but I don't see a chance for Hardy (as a milestone). Maybe later
<rtg> smb: yeah, it'll likely be later. What I meant by fully isolating the rt mac80211'isms is that you'll have to change the source code so that the public symbols do not clash with existing kernel/lum components.
<smb> rtg: Sure, I already spent some time on that and got to the point rt2x00 and mac20811 compiled but still had unresolved symbols from yet another module
<rtg> smb: a lot of unresolved symbols? You may be fairly close already. 
<smb> rtg: some from the wireless core, so maybe making a private version of that as well. Well. maybe I am not that far away. It just after spending 3 days on it and a bit on the prospect of being close to release that makes me feel worried
<rtg> smb: LBM isn't important for release. we can update it pretty much anytime.
<tjaalton> is LBM meant to be a staging area for proposed updates to LUM?
<rtg> tjaalton: not really. Its for backports and elective installs.
<rtg> tjaalton: some of the stuff that goes into it can be pretty ugly.
<rtg> tjaalton: its also less restrictive in terms of SRU policy.
<rtg> tjaalton: by the way, thanks for uploading LRM.
<tjaalton> the metapackage naming is different from the rest (no "l-b-m-generic" for instance)
<tjaalton> rtg: ok..
<tjaalton> and np
<smb> rtg: Right. Well it might be just too much worries. Its first release for me and i don't want to spend too much time on something that i probably shouldn't.. :-/
<rtg> smb: there are lots of folks using rt based adapters, so if you can get it working, then its worthwhile.
<rtg> smb: really, wireless support is probably one of Linux weakest areas.
<rtg> smb: its rapidly improving, but still needs work.
<smb> rtg: Including bluetooth
<smb> rtg: I agree and from the number of responses to the test kernel there are quite a few users to rt2x00
<smb> rtg: So I just try to get that working
<rtg> smb: its worth another day or two.
<smb> rtg: Ok. And thanks.
<rtg> tjaalton: I'm curious about your comment regarding linux-meta and lbm. Is it because there is a linux-backports-modules-hardy meta package? I did that in order to break the distribution upgrade path. LBM should not be automatically upgraded.
<tjaalton> rtg: yeah, I figured there was a reason for it ;)
<mkrufky> will the gutsy kernel continue to receive updates for the 2.6.24.y -stable kernel series, or should I send patches to kernel-team ?
<rtg> mkrufky: only updates that satisfy SRU policy, e.g., oops fixes, CVEs, etc.
<mkrufky> this patch fixes an old bugzilla, we pushed it into 2.6.25 but didn't realize that 2.6.24.y needed it until now
<mkrufky> i am waiting on one last sign-off before I send it to -stable
<mkrufky> it's a showstopper dvb-s diseqc bug
<rtg> mkrufky: sending it to the kernel-team mailing list is good. I'm close to doing a Gutsy update.
<mkrufky> ok, then ....  i will send it within the next few days (most likely today)
<mkrufky> i will cc kernel-team when i send it to -stable
<mkrufky> thanks :-)
<rtg> mkrufky: thats fine, I'll be at LFS until late next week, so won't get much done.
<mkrufky> no problem.... it's waited this long, another week will kill anybody :-)
<mkrufky> oops, i meant WONT kill anybody
<rtg> mkrufky: :)
<rtg> mkrufky: I have some NFS and CIFS changes queued as well.
<mkrufky> btw, after last night's hardy updates, HAL is broken on my machine, now ....   i know that this is the wrong place to report the issue, and im hoping somebody else will fix it by the time i get home :-) 
<mkrufky> but if not, i'll file a bug
<rtg> mkrufky: the major change was enabling CGROUPS in all of the non x86 flavours. everything else was quite minor.
<rtg> mkrufky: oh wait, you probably don't have that one yet.
<rtg> mkrufky: I have not upload -meta (waiting on LRM to finish)
<mkrufky> no idea... all i know is i get an error about HAL crashing, and my nic didnt work... maybe other things broke, too, but i just booted into 2.6.24-12 (rather than -14) and it was all fine again
<mkrufky> and i know not to expect perfection until it's actually released, so im not complaining :-)
<rtg> mkrufky: well, this is the right place to discuss those kinds of issues. After release is a bit late :)
<mkrufky> haha
<mkrufky> ok, in that case, I will come back here when im actually in front of that machine so that i can furnish any logs and / or debug info
<mkrufky> should be approx 7 hours from now
<mkrufky> ...or maybe tomorrow
<rtg> mkrufky: s'fine
<mkrufky> rtg: is there a way to prevent aptitude from removing old linux-headers-foo packages?  i am happy testing all new updates, but i want to retain the ability to boot into older kernels -and- be able to rebuild my kernel modules against it
<rtg> mkrufky: each package is NEW with every ABI bump. I wonder why it wants to remove them?
<rtg> each kernel package, that is.
<mkrufky> it doesnt remove the kernel packages 
<mkrufky> it removes the header packages
<rtg> I have linux-headers installed for the last 10 or so ABI bumps.
<mkrufky> id like my system to keep every release of the headers packages, since it DOES keep the kernel images
<mkrufky> hmm perhaps i am missing a setting somewhere
<rtg> mkrufky: perhaps autoremove or something like that? I don't use aptitude.
<mkrufky> ah, ok... its definately autoremove.  and i am happy for autoremove to do its thing, except for the kernel headers
<mkrufky> ok, then -- i will try some things and hopefully will solve that myself :-)
<elmo> gar
<elmo> this AACRAID bug is still present in hardy :-(
<elmo> it's a regression from feisty IIRC
<rtg> elmo: did we fix this once?
<elmo> I don't believe so
<elmo> this is https://bugs.launchpad.net/bugs/149071
<ubotu> Launchpad bug 149071 in linux-source-2.6.22 "-server kernel variant fails to boot on PowerEdge 2650 with AACRAID timeouts" [Undecided,Confirmed] 
<rtg> elmo: ok, lemme read it.
<elmo> oh
<elmo> I just read it myself
<elmo> it says 'upgrade the BIOS, kthx'
<elmo> which seems irritating considering the server works (and has worked for years with << gutsy)
<rtg> elmo: its worth a try.
<elmo> haha
<elmo> there's another work around
<elmo> ignore it for 30 mins, and it'll fix itself enough to recognise the drive, then exit the initramfs and the boot works
<rtg> elmo: seems kind of painful :)
<elmo> rtg: considering this was a dapper -> hardy upgrade and the only other kernel I have available is dapper... less painful than the alternative
<elmo> since I'm betting dapper kernel </3 hardy userland
<flea> i read regarding bug#110585 (dl360/cpqarray&sym53c8xx) to force sym53c8xx to not load was
<flea> sym53c8xx.blacklist=true
<flea> however this gives error and loads anyways
<flea> how is it proper to force unloading?
<flea> t.i.a
<AstralJava> Hey gang, just thought I'd pop in and say hi, also letting you guys know that I got hit with the bug #208247 on a fresh daily of Ubuntu Studio, with nvidia-glx-new for video driver.
<ubotu> Launchpad bug 208247 in linux-restricted-modules-2.6.24 "nvidia-glx-new crashes when using rt kernel" [Undecided,Incomplete] https://launchpad.net/bugs/208247
<AstralJava> Commented on that bug report also, so this is just a safety thumbs-up. :)
#ubuntu-kernel 2008-04-05
<blueyed> CONFIG_FAIR_CGROUP_SCHED is not set in 2.6.24-15-generic?!
<blueyed> From the changelog: "Enable CGROUPS for non x86/x86_64 arches, all flavours."?! (bug 188226)
<ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,Fix released] https://launchpad.net/bugs/188226
<tjaalton> blueyed: re: suspend hotkey; no, I haven't filed a bug yet, and it's a Thinkpad X61
<blueyed> tjaalton: is there anything in /var/log/acpid when you press the key?
<tjaalton> blueyed: yes
<tjaalton> [Sat Apr  5 02:14:04 2008] received event "ibm/hotkey HKEY 00000080 00001004"
<tjaalton> etc
<blueyed> can you pastebin it somewhere please?
<tjaalton> it does run /etc/acpi/sleepbtn.sh but nothing happens
<tjaalton> blueyed: http://pastebin.ubuntu.com/6486/
<blueyed> tjaalton: ..which calls acpi_fakekey. As said before, there are various reports about broken hotkeys, where the keycodes do not get caught anymore (e.g. from "xev")
<tjaalton> blueyed: ok, how to fix that ?-)
<blueyed> no idea, sorry.
<tjaalton> bah :)
<blueyed> might this be related to the kernel after all?
<tjaalton> I tried -11 and it was the same. Could try an older one too
<tjaalton> -8 is the oldest I have 
<blueyed> tjaalton: can you try an older acpi-support? But that shouldn't matter.. there was nothing changed recently in acpi_fakekey AFAIK.
 * blueyed wishes LP would search also in comments
<tjaalton> I have .106 and .108
<blueyed> tjaalton: .106 was my collection of fixes and regressions, please try .105, so that we can exclude acpi-support hopefully. https://edge.launchpad.net/ubuntu/hardy/+source/acpi-support
<tjaalton> blueyed: 105 didn't help, now I don't get anything on the acpid log
<tjaalton> I'll try to debug it later -
<tjaalton> >
<blueyed> tjaalton: that's probably due to the mask which has been extended for thinkpads.. so the current acpi-support is better.
<blueyed> tjaalton: seems to be a common problem: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=hotkey&orderby=-datecreated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<shekk> hi
<macd> were you using the ubuntu source, of vanilla kernel?
<macd> s/of/or
<shekk> make-kpkg -initrd --revision=ck2 kernel_image
<macd> the ubuntu kernel already has grsec provisions, you should be able to install gradm2 and start utilizing it 
<shekk> im getting undefined references to __stack_chk_fail from kernel/built-in.o
<shekk> on many different .c's
<shekk> really?
<shekk> lol
<shekk> jeez
<shekk> i like compiling a kernel though :(
<shekk> i miss compiling thigns
<macd> yeah, apt-get install gradm2, then it installs the grsec patches 
<shekk> thanks
<macd> Suggested packages:
<macd>   kernel-patch-grsecurity2
<macd> so I'd install that as well ;)
<shekk> heh
<shekk> that wasnt found
<macd> I guess I should've asked gutsy/hardy? and do you have all the repos enabled?
<shekk> gutsy
<shekk> repos?
<shekk> repository
<shekk> ?
<shekk> like apt-get update
<macd> yeah
<macd> !info kernel-patch-grsecurity2
<ubotu> Package kernel-patch-grsecurity2 does not exist in gutsy
<macd> !info gradm2
<ubotu> gradm2 (source: gradm2): Administration program for the grsecurity2 RBAC based ACL system. In component universe, is optional. Version 2.1.9-3 (gutsy), package size 91 kB, installed size 368 kB
<shekk> hm
<macd> install gradm2 and see if it doesnt complain, if it doesnt then that kernel-patch-grsecurity2 might be a dummy package
<shekk> it didnt cimplain
<shekk> i guess i need to reboot?
<shekk> will it automatically be applied to kernel?
<shekk> weird.
<macd> honestly, I dont know, I think the kernel may already be patched against it
<macd> so just using the gradm2 tool to make policy should just work
<shekk> its a kernel patch
<macd> I just tried it on gutsy server, made a policy, tested it, and got rejected, so I assume its patched already, as it worked as expected
<shekk> okay
<shekk> need to find some examples of good policies now
<shekk> still not working
<shekk> cant find /dev/grsec
<shekk> you gotta recompile kernel
<shekk> with patch ebfore you cna use the admin program ;)(
<blueyed> Does the openvz kernel work for anyone?
<blueyed> bug 210672
<ubotu> Launchpad bug 210672 in linux "linux-image-2.6.24-13-openvz refuses to boot" [Medium,Triaged] https://launchpad.net/bugs/210672
<sistpoty> anyone from the kernel team, who could share some insights on the FFe bug #185634 ?
<ubotu> Launchpad bug 185634 in ubuntu-meta "uvcvideo: iSight firmware loading does not work" [Medium,Confirmed] https://launchpad.net/bugs/185634
<mkrufky> rtg: ping  (or anybody else interested in the "failed to initialize HAL" bug I mentioned earlier starting with 2.6.24-14 (or -13) ) 
<mkrufky> brb
<mkrufky> i see the same problem as in bug 164416, and it only started when i updated from 2.6.24-12 to 2.6.24-14.  the issue is still present in 2.6.24-15, and when i boot into 2.6.24-12, it's fine
<ubotu> Launchpad bug 164416 in ubuntu "Internal Error failed to intialize HAL !  ??? what's " [Undecided,Incomplete] https://launchpad.net/bugs/164416
<mkrufky> (i also dont expect a response right now, but i'll come back at a more reasonable hour tomorrow)
<mkrufky> looks like it's the result of an oops... null pointer dereference
<mkrufky> i'll file a bug in launchpad
<mkrufky> 212100
<mkrufky> #212100
<mkrufky> i guess i need to say bug 212100 to make ubotu do its thing
<ubotu> Launchpad bug 212100 in linux "NULL pointer dereference caused by hald" [Undecided,New] https://launchpad.net/bugs/212100
<bullgard4> What means "comm" in the kernel message: "[79721.755165] Pid: 69, comm: kacpi_notify Not tainted 2.6.24-git9 #4"?
<pepie34> Hi, I use madwifi-svn cause i've got a AR5418 (the one find in macbook pro) which is not supported in the current restricted module
<pepie34> but since the 2.6.24-14 kernel update
<pepie34> I can not acces to AP
<pepie34> when booting on -12 it is still working with the same userland
<pepie34> (madwifi-svn correctly compiles and loads for -12 -14 and -15)
<erle-> i found out how to do kexec fast reboot with a single command
<erle-> in ubuntu hardy with default generic kernel
<IntuitiveNipple> Anyone know of a way to use make-kpkg with an out-of-tree build to speed up a git-bisect bug hunt?
<dhaval> rtg, what is up with bug 188226 ?
<ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,Triaged] https://launchpad.net/bugs/188226
#ubuntu-kernel 2008-04-06
<keir__> hello
<keir__> the latest Hardy kernel refuses to boot for me, failing on the audio drivers for my sound card
<aleehk82> which package should I report hibernation problems to?
<Ng> rtg: would https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/191388/comments/8 apply to the lbm iwl driver? I get a lot of messages like the one that seems to be intended to silence (see bug 211556)
<ubotu> Launchpad bug 191388 in linux-ubuntu-modules-2.6.24 "syslog is spammed with " wme:wme_qdiscop_enqueue ht_queue=4,queue=2 pool=0xF qdisc=ffff81007c4548c0" on hardy" [Medium,Confirmed] 
<ubotu> Launchpad bug 211556 in linux-backports-modules-2.6.24 "dmesg spam from updated iwl driver" [Undecided,New] https://launchpad.net/bugs/211556
<Ng> the regular driver is fine, I was just testing the lbm one to see if the LED stuff worked (it lights up, but doesn't blink on activity, but that's another bug for another day^Wrelease ;)
#ubuntu-kernel 2009-03-30
<vadi2> hi. sorry for being thick, but the script did not output any results when finished. am I supposed to fill them in manually?
<JanC> hm, there is no ext4 support in intrepid, right?
<JanC> apparently, there is...
<amitk> JanC: there is support in the installer, but not as defualt
<JanC> amitk: in intrepid?  (ext4 wasn't officially in the kernel before 2.6.28)
<JanC> not officially supported I mean (there was ext4dev)
<amitk> JanC: ohh. Sorry. Not in Intrepid
<amitk> except for ext4dev
<pwnguin> even then, i find it's kinda dicey
<JanC> there is a bug report against gparted in intrepid not supporting ext4...
<JanC> and the gparted version in intrepid doesn't support it, but the one in jaunty does
<JanC> but as ext4 isn't supported in intrepid, I don't really see the point of that bug  ;)
<amitk> I don't see us backporting ext4 to intrepid
<JanC> amitk: at least the -server kernel in 8.10 has -ext4dev enabled (didn't check with -desktop kernel)
<JanC> but that's not really the same as officially supported
<pwnguin> its dev
<pwnguin> not even the kernel officially supported that module ;)
<cwillu_clone> Can I draw anyone's attention to https://launchpad.net/bugs/330824
<ubot3> Malone bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Undecided,Confirmed] 
<Unggnu> hi all
<Unggnu> Because there isn't so much time until release I just wanted to point to Bug #350137 . Ath5k shipped with Jaunty seems to be really buggy. Crashes system, looses packets and so on. Backport module seems to work fine so I think it should be replaced.
<ubot3> Malone bug 350137 in linux "Jaunty ath5k freezes system and looses packets" [Undecided,New] https://launchpad.net/bugs/350137
<Unggnu> There also seem to be several similar bug reports.
<Ng> in relation to the suspend/resume testing, I have a thinkpad X40 at home which has generally done suspend/resume reliably since I've had it, but after upgrading it to jaunty it won't suspend. The various debugging guides seem to assume that suspend works and resume fails - what debugging can I do to figure out what's breaking it?
<Ng> it does a bit of disk activity, the blinking suspend light never starts, and then it locks the screen
<Unggnu> Ng: Do you have an Intel graphic card?
<Ng> Unggnu: yes
<Ng> it's an 855GM
<Unggnu> this might be the problem, at least for me
<Unggnu> 8xx are really bad supported in newer drivers afaik
<Unggnu> Ng: Do you have a standard xorg.conf?
<Ng> Unggnu: the machine is at home, but I would think so, it was re-installed with hardy and my gf uses it, so it's unlikely I'd have fiddled with that stuff
<Unggnu> Ng: You could try suspend with vesa to be sure I guess.
<Ng> I'll give it a go and get a bug filed I guess
<Unggnu> Ng: there are several already, search for 855 and intel.
<Unggnu> But of course only if they fit
<Kamping_Kaiser> bug #292381
<ubot3> Malone bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,In progress] https://launchpad.net/bugs/292381
<Kamping_Kaiser> aw. no bot :\
<Kamping_Kaiser> heh. snap.
<Kamping_Kaiser> apw, i was wondering if there was any news on that bug. cjwatson said a USN was going to be announced, but I certainly havent seen one (and the bug status remains the same)
<apw> hrm no i have lost track of that one a bit.  will bring it up today
<Kamping_Kaiser> thanks. 
<nacho> hi
<nacho>  since I've reinstalled the cpu freq applet starts with the processor on performance mode, do you know how to change it to ondemand mode? (I can change it in the applet but next time I reboot it goes to performance mode again)
<nacho> BTW this happens on jaunty 32 bits
<Kamping_Kaiser> perhaps try cpufreq-set
<NCommander> apw, I finally got around to testing your patches for the jax10 on real hardware; https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/280669
<ubot3> Malone bug 280669 in linux "DMA mode and driver jax10" [Low,Triaged] 
<apw> maxb, the lbm regressions with lbm_cfg80211_reg=EU etc, were you able to test on both jaunty and intrepid?
<smb_tp> apw, What where the base for both test packages? Will we probably have to retest Intrepid with the minimum fix applied there?
<apw> smb_tp, yeah we will.  hense hastling maxb about it as he has something to test with :)
<apw> i t
<apw> he tested the jaunty update which is basically the same as intrepid with my patch, but not i think on intrepid
<smb_tp> Ok, cool. Yeah I think it is best to leave compat-wireless at its current state with intrepid. While newer version give more support they tended to break stuff sometimes
<smb_tp> Especially since we now have different policies about crda
<apw> yep concur.  will prepare an lbm with the patch only for intrepif (lbm-2.6.27) and see if we can find a tester
<smb_tp> Thumbs up :)
<apw> smb_tp, one last aspire one rfkill test kernel for you if you have the time to test it
<apw> the upstream for the driver turned up in my bug :)  and asked for the final patch which this hopefully is
<smb_tp> apw, sure
<smb_tp> Yeah, I saw the mails
<smb_tp> :)
<apw> they are just uploading now, so about 5 mins at: http://people.ubuntu.com/~apw/lp319825-jaunty/
<smb_tp> LEt me fire up the aspire
<apw> smb_tp, uploaded
<smb_tp> apw, ok, downloaded
<smb_tp> Ok, wireless is there. Is it supposed to print something?
<apw> no it prints something if you have sw rfkill enabled, that lack of a messsage to that effect and working wireless is a good resule
<smb_tp> ok, sounds good
 * apw is starting to get the feeling that wireless is less reliable in jaunty -11 kernels than it was in -8
<apw> intel wireless
<Keybuk> rtg: so I'm confused again about this whole PAE thing
<rtg> Keybuk: how so?
<Keybuk> why can't it be compiled into our generic i386 kernel and enabled if the processor supports it?
<mjg59> Because that would involve somebody writing the code to support that
<Keybuk> it's just a code issue, right
<Keybuk> I heard tell that there was no way to do that
<Keybuk> but that appears to be false
<rtg> Keybuk: AFAIK its not a dynamic selection, e.g., its a statically compile option. I think PAE adds another level of page table complexity.
<mjg59> The code isn't conditional. You'd need something like the SMP/UP rewriting
<Keybuk> ok, so it's a Linux kernel limitation
<Keybuk> not a "there's no way to detect whether the processor supports PAE" issue
<Keybuk> since the processor clearly has a "pae" flag <g>
<rtg> Keybuk: pretty much
<mdz> apw: heads up on regression bug 350491
<ubot3> Malone bug 350491 in linux "hibernation should be disallowed from the desktop when the installed kernel does not match the running kernel" [High,Triaged] https://launchpad.net/bugs/350491
<apw> mdz, t
<apw> so we don't check any more then
<kees> mdz: is that a regression?
<mdz> kees: yes it is, we fixed that in feisty
<kees> ah, okay, I didn't realize that.
<mdz> kees: the kernel already touches a flag file when it's upgraded, we just stopped checking for it
<mdz> probably in getting rid of powermanagement-interface
 * kees nods
<mdz> should be easy enough to add back
<kees> mdz: should that be mile-stoned?
<mdz> kees: probably
<apw> yep its not a big job, just good to catch that its missing
<mdz> apw: bug 350609 may be another example of a WARNING which doesn't justify bug reports
<ubot3> Malone bug 350609 in linux "WARNING: at /build/buildd/linux-2.6.28/kernel/power/main.c:177 suspend_test_finish+0x7c/0x80()" [Undecided,New] https://launchpad.net/bugs/350609
<mdz> apw: I was wondering if we should simply exclude WARNINGs in the apport hook
<apw> mdz thats another which really should not be a warning at all
<apw> most warnings in the kernel real things to report in general
<mdz> I almost wrote it, then realized that because the oops text isn't very well delimited, I would need to duplicate a bunch of code from kerneloops
<apw> this one really is not a panic level issue, there is simply no category for it
<apw> a message noone reads, or something which explodes your world are the options
<mdz> apw: triaged accordingly
<apw> hrm.  perhaps it should be turned into something apport detects, but it also need to have a variable time for once its been seen and nothing can be done
<peerless> earthquake here
<peerless> How  to add a module in initramfs?
<IntuitiveNipple> peerless: add it to /etc/initramfs-tools/modules
<peerless> Where should I place the modules?
<IntuitiveNipple> It will find them from the existing installed modules via the depmod info
<peerless> I am just trying a test module built out of kernel
<peerless> Figuring out how to include that in initramfs
<peerless> copy_modules_dir 
<peerless> there is a function by that name..trying it
<maxb> apw: I do have a seldom-used intrepid partition on my Aspire One, I can make specific lbm tests on request
<raevol> do we know what kernel is going into karmic? sorry if this is the wrong place to ask
<maxb> I've no idea how final it is, but see the description at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=summary
<raevol> hmm ok, thanks maxb
<raevol> gotta run for now
#ubuntu-kernel 2009-03-31
<tjaalton> hmm, running the suspend test script on my thinkpad X61, but it fails to resume unless I hit the Fn key
<tjaalton> but it's nice that the screensaver seems to have crashed after the first cycle, so I don't have to enter my password every time
<tjaalton> :)
<smb_tp> Oh, _that_ was the reason. And I had the same effect but wasn't thinking about it being crashed. Just happy at not being in need for the pw each of the time.
<smb_tp> For the wakeup. One thing to try could be to increase the delay until wakeup. I tested one machine that needed close to the 20s. 
<tjaalton> actually, it didn't crash, but the script is wise enough to avoid it :)
<apw> tjaalton, indeed the first test is for dbus, after that we can go direct and avoid that annoyance
<apw> tjaalton, yeah how quickly does your machine get to suspend
<apw> if its > 20s then the wakeup occurs before the sleep
<apw> --sleep <delay> changes that i think
<tjaalton> it's pretty quick
<tjaalton> only a few seconds
<apw> not that then
<apw> so acpi wakeup is bust on your machine i guess
<tjaalton> happy to notice that updating mesa got rid of the "blinking cursor" hang
<tjaalton> yeah I'm reading the bugreport
<apw> tjaalton, whats the bug number?
<tjaalton> apw: bug 307090
<ubot3> Malone bug 307090 in linux "acpi wakeup doesn't work with HP tx2510us unless hpet is disabled" [Unknown,Confirmed] https://launchpad.net/bugs/307090
<apw> tjaalton, did hpet=disable help?
<tjaalton> haven't tried yet
<tjaalton> will try now
<tjaalton> heh
<tjaalton> trying to restart the screen just makes it jump from init 6 to init 2 again
<tjaalton> um
<tjaalton> s/screen/machine/
<tjaalton> apw: didn't seem to help
<makertoo> hello every body
<makertoo> i need some help please
<makertoo> with sound under ubuntu 8.10
<makertoo> when i hook up my headset , the sound is heard both with my headset and with the laptop sounders
<makertoo> any help?
<apw> thats normally a model quirk
 * apw searches for the how-to
<makertoo> where can i find the hou-to?i a newbee in linux world
<apw> makertoo, can't find it right now, which sound card you got?
<makertoo> ati
<apw> can you paste the output of: cat /proc/asound/cards
<apw> the guide i was thinking of is this one: https://wiki.ubuntu.com/DebuggingSoundProblems
<makertoo>  0 [Intel          ]: HDA-Intel - HDA Intel
<makertoo>                       HDA Intel at 0xd5200000 irq 22
<makertoo>  1 [HDMI           ]: HDA-Intel - HDA ATI HDMI
<makertoo>                       HDA ATI HDMI at 0xd0030000 irq 17
<apw> ok so its actually an intel sound thing
<makertoo> ok ^^
<apw> makertoo, what does cat /proc/asound/Intel/codec#* | grep Codec
<apw> produce
<makertoo> with the "#*" ?
<apw> yep
<makertoo> Codec: Realtek ALC262
<makertoo> Codec: Conexant ID 2c06
<tseliot> apw: any ideas as to why dmesg |grep elantech doesn't say anything and my touchpad is detected as ImPS/2 Logitech Wheel Mouse?
<tseliot> in jaunty
<mjg59> tseliot: Fixed in 2.6.29
<tseliot> mjg59: would it be trivial to backport? e.g. a simple patch for elantech.c
<mjg59> Yes, but it's for the ps2 driver itself rather than elantech
<tseliot> ah
<tseliot> mjg59: psmouse-base.c?
<mjg59> Oh, actually, not in .29
<mjg59> Commit 9ab7b25e6a30d2292bd6d4913b71c918ee1e21b4
<mjg59> It does end up being to elantech.c
<tseliot> mjg59: thanks
<tseliot> mjg59: I think we have it already in Jaunty though
<tseliot> mjg59, apw: aah, that's because the patch covers the case in which a logitech mouse is recognised as an elantech touchpad. In my case the touchpad is detected as a mouse
<mjg59> Ah, sorry
<mjg59> In that case it's because the elantech probe is failing
<mjg59> And the logitech probe succeeds
<tseliot> ok, a different bug then
<cody-somerville> depmod is failing to run with "Failed to run depmod" when attempting to upgrade to the latest kernel in jaunty
<NCommander> Anyone around to take a look at my lpia patch I sent to the list :-)?
#ubuntu-kernel 2009-04-01
<cavedon> hi all!
<cavedon>  I am testing jaunty beta, but I have an annoying regression:
<cavedon> when I reboot or halt, it stops at "will now halt" or "will now reboot" most of the times: any idea of how to debug that?
<cavedon> https://bugs.edge.launchpad.net/ubuntu/+bug/349778
<ubot3> Malone bug 349778 in ubuntu "[jaunty] Dell Inspiron 1525 sticks on "System will now halt", works with 2.6.29" [Undecided,New] 
<ogasawara> rtg: kees has got a patch for bug 350789 he'd like to see get in for jaunty final
<ubot3> Malone bug 350789 in linux "AppArmor Debug: Hook being called from interrupt context" [Medium,Triaged] https://launchpad.net/bugs/350789
<ogasawara> rtg: should he submit it to the kernel-team ml as well?
<rtg> ogasawara: I looked at this, but I'm not wild about it. it seems like a hack to cover for a poorly written blue tooth driver.
<ogasawara> kees: ^^
<amitk> lool: https://bugs.edge.launchpad.net/ubuntu/+source/linux/?field.searchtext=&orderby=-importance&field.tag=arm&search=Search
<amitk> lool: current status of arm bugs. Anything else you need fixed _urgently_? 
<NCommander> sconklin, I kicked the updated lpia configuration files to the list last night, which fixes d-i on ARM
<amitk> NCommander: lpia config fixed d-i on arm?
<NCommander> wow
<NCommander> I think my brain crapped out half way through that sentence
<NCommander> lpia config to fix d-i on lpia :-/
<amitk> hehe...
 * NCommander needs coffee .... lots of it
<sconklin> NCommander: I responded on list
<manjo> sconklin, try this http://meandubuntu.wordpress.com/2008/11/18/real-64-bit-flash-on-amd64/
<ChinoChano> hi guys,
<ChinoChano> one question: in kernel 2.6.28, is WideView WT-200U and WT-220U (pen) DVB-T USB2.0 support (Yakumo/Hama/Typhoon/Yuan) avail in this kernel?
<kees> rtg: jj said a similar thing when he saw the bug.  perhaps a small modification to leave the "BUG" report and to correctly handle the memory allocation method just to reduce possible instability?
<sconklin> Please use and update as needed - https://wiki.ubuntu.com/GitCheatSheet
<k-s> hi there, compiling custom kernel for macbook4.1
<k-s> all good, just need some info on how to get pretty package names
<k-s> today I'm doing nasty hack, just replace config and let it generate
<k-s> but generates as 2.6.28-11-GITHASH-generic
<k-s> I guess it would be better to have it as 2.6.28-11-macbook41 (flavor=macbook41)
<k-s> manjo mentioned to me I should update debian/changelog
<k-s> but do I need a git-tag with the name within parenthesis?
<manjo> you could change the 1st line on debian/changelog to something like ::: linux (2.6.28-10.33~lp326621manjo1) UNRELEASED; urgency=low
<k-s> did it already
<manjo> k
<k-s> but before generating, I would like to know what more do I need
<k-s> ie: why changing the config will lead to hash in the name? since I have debian/changelog it should use that top line, no?
<k-s> so I'm guessing it does some git<->changelog mapping somehow
<ChinoChano> guys, does the 2.6.28 have the support for WideView DVB pen usb receiver?
<ChinoChano>  WideView WT-200U and WT-220U (pen) DVB-T USB2.0
<manjo> k-s, apw might know more abt git<->changelog stuff
<k-s> manjo: ok, it's not possible to have '~' in tag name, so I suppose you don't do a tag and still have the package name correctly
<k-s> maybe it was like that because I had uncomitted git changes, let's see if it works now with changelog + git commit
<k-s> manjo: and thanks for your time, I know you're quite busy there
<manjo> apw, ^^^
<manjo> k-s, apw is the git guru 
<k-s> apw: hey :-)
<infinity> smb_tp: How long does the ltp suite take?
<apw> huh there is lots of info here, what was the question?
<k-s> apw: if you have some time, it's more related to debian/ubuntu packaging than anything else, from what I've read I need to create a custom "flavor" to live side by side with "generic"
<apw> wahts the difference between your new kernel and generic?
<k-s> apw: I want to have a custom macbook41 flavor, since I know all the hw it's there (except pluggable usb/firewire)
<smb_tp> infinity, depending on the hw pretty long. never measured it
<infinity> smb_tp: Minutes, hours, or days? :)
<smb_tp> infinity, hours
<infinity> Ow.
<k-s> apw: I'm using it for some time already, compiles really fast (so no trouble to maintain) and works better, no need for initramfs and thus boots fast
 * infinity kisses artigas goodbye for a bit.
<k-s> also I like to have my own kernels, it's an old habit
<apw> so you want to stop is our kernel updates eating your kernel?
<manjo> infinity, what was the question abt ltp ? 
<smb_tp> infinity, might be something in the size of 3hrs, but as said, I usually fired it up on a machine and looked back later
<smb_tp> manjo, how long it is running
<k-s> apw: no, just want to have a nice package name ;-)
<k-s> apw: I already disabled my kernel being replaced in config files, that's fine
<k-s> apw: but I'd like to have something better than 2.6.28-11-1c2a1a-generic
<apw> hrm, then i guess a flavour name is reasonable thats what a flavour is, a different config combination
<manjo> depends on how you run it also... ie if you have genload running in the background it might take longer
<manjo> genload will run if you run with system load options in runltp
<k-s> apw: yep, but I tried to have my own flavour and it didn't work, at least followed a wiki+blog and it did not work, maybe I missed something obvious since I was in a hurry, AFAIR it was related to some files it expected in debian/ not being there like old version symbols or so
<k-s> apw: also, what's annoying now is that it will always add -GITHASH to name, so I need to go there and update control{,.stub}
<apw> githash is addwhen when your tree is dirty
<k-s> apw: I just do git clean -fxd before running debian/rules
<apw> there is an optiion somewhere, _AUTO in the config which triggers the addition
<k-s> apw: which config? kernel or debian/*?
<apw> kernel config, in debian/configs/*
<k-s> apw: from debian/rules.d/2-binary-arch I see that it will forcely disable it
<k-s> ok, tried with git committed and changelog, still no luck
<k-s> my cmdline reads: ./debian/rules binary-generic AUTOBUILD=1 NOEXTRAS=1 CONCURRENCY_LEVEL=2 no_dumpfile=1 
<CarlFK1> how do I make this auto inc so that it shows up as a default for new data?    db.Field( 'seq', 'integer', ),
<CarlFK1> um.. that sounds weird...
<CarlFK1> woa.. wrong #chan
<lool> amitk: the FSL stuff is urgent, and is in your inbox
<amitk> lool: it is already *in*
<lool> amitk: (I couldn't tell since I got no update via email)
<lool> I pulled the git tree now and I see some
<infinity> smb_tp: Your kernel boots on artigas, userspace and dmesg seem happy, running ltp now to compare to the previous kernel.
<infinity> smb_tp: (I'm comparing to -51-, since that's what was installed... If you need a comparison against -53- so we're only isolating your changes, I can do that later)
<smb_tp> infinity, Err, I am a bit slow catching, by the numbers this sounds like hardy, which architecture is artigas?
<infinity> smb_tp: Dapper.  Even.  Sparc.  Testing your "omg, syscall tables completely rewritten" kernel.
<smb_tp> infinity, Ah, cool.
<smb_tp> Oh, yeah. For dapper its -53 and for hardy 24.52. That confused me 
<mathiaz> hi - how can I make sure that a certain changeset is the jaunty kernel?
<mathiaz> hi - how can I make sure that a certain changeset is *in* the jaunty kernel?
<mathiaz> I'm looking for changeset c073b2db006ba9370be1eecc36a1be1d9ce31310
<manjo> git log | grep 
<manjo> c073b2db006ba9370be1eecc36a1be1d9ce31310
<neuralis> hi, folks. with the desktop kernel turning non-preemptible, are there significant differences other than tick frequency and numa support between the desktop and server kernels?
<manjo> neuralis, http://www.ubuntu.com/products/whatisubuntu/serveredition/features/kernel
<neuralis> manjo: aha, neat. wasn't aware of that page. thanks!
<manjo> np
<liw> any kernel hackers knowledgeable about the SATA subsystem? #257790 is bothering me (I have four new SATA disks I'd like to use), and I'd be glad to help debugging this
<manjo> liw, does it work with jaunty ? 
<manjo> liw, have you tried the jaunty live cd to see if it works ? 
<liw> manjo, as I said in the bug, I've tried everything from gutsy onwards; gutsy works, nothing later does
<manjo> liw, can you try with kernel option iommu=soft ? 
<infinity> smb_tp: Still around?
<smb_tp> infinity, yep
<infinity> smb_tp: http://lucifer.0c3.net/~adconrad/ltp-results/
<smb_tp> infinity, looking quickly, it looks like no diff which sounds good
<infinity> smb_tp: 53 and 54 are identical.  From 51 to 53, there were changes, which I'm not sure were intentional.
<smb_tp> infinity, Have only been looking at the summary, so the overall was equal
<smb_tp> infinity, have to get it downloaded and look
<infinity> smb_tp: Still, given all the ridiculous mangling in your test kernel, the lack of regression from 53 to 54 is comforting. :)
<smb_tp> infinity, true enough :) Either there are not many dapper users or nobody really had bad experience with that other change
<infinity> smb_tp: Well, there were two fixes (pty and pwrite), and then the writev flip-flopping, I'd have to check to see what the test is actually doing to see if it's a regression, fix, or a wash.
<infinity> smb_tp: But it seems fine to me.
<smb_tp> kees, ^^^ I would be fine with it as -51 is quite some time ago
<infinity> smb_tp: In a day or two, we won't be running dapper/sparc in the DC anymore either (I've been in the process of ugrading all our sparc machines to hardy), so the point's somewhat moot to me.
<kees> smb_tp: yeah, I'm fine with the -51 to -53 regresssions -- no one else seemed to notice.  it's the -53 to -54 we need to study, and so far so good.
<infinity> kees: Like I said, the test output for 53 and 54 were identical on artigas, and it seemed pretty happy with the whole thing.
<kees> smb_tp: I'm happy with the LTP output we've seen.  shall I shove dapper into the build queue too?
<kees> infinity: yeah
<infinity> smb_tp: If any of the patches touched smp-specific bits, might want to make sure sparc64-smp is also in good shape, but it's a thumbs-up here for UP.
<kees> sbeattie: you said you had a single test regression on your ultra60?  is it smp?
<smb_tp> infinity, O am not aware of anything smp specific out of my head.
<sbeattie> kees: it is.
<kees> sbeattie: can you spin a few more tests on -53 and again on -54?
<sbeattie> I've reproduced the oops; running ltp *outside* of screen seems to trigger it; I ran my -53 test under screen, so I'm seeing if it reproduces there.
<sbeattie> kees: sure thing; like I said, it just takes a little while.
 * kees nods
<kees> ironically, oopsing on -53 is okay in this case.  :P
<sbeattie> kees: indeed! I'd do a happy dance if it oopsed on -53. :-/
<sbeattie> alas, it appears not to. :-(
<kees> oh.  dang
<infinity> sbeattie: And this is actually reliably reproducible in -54?
<smb_tp> There could be a chance this is related to "sparc: Fix mremap address range validation." as well
<rtg> smb_tp: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=blobdiff;f=drivers/bluetooth/btusb.c;h=d4ec9a98fb19a2cefccd4a0f71f22826dcd11fb6;hp=3b0545ba59f204301e1191dd27acc5e7816e4568;hb=1bb9aba826e75a31c719e5ef60ba616e53ae09bd;hpb=66f550e4f758fc8a0f78f35395d283d526dc9c37 has a compile error
<infinity> smb_tp: If you do any more work on that kernel and need a re-test on artigas, let me know.
<smb_tp> infinity, Ok, will do. Thanks
<dtchen> amitk: follow up on 351924 is appreciated
<sbeattie> bah; every time I think I have a grip on reproducing this oops, I then can't reproduce it.
<DaemonFC> has anyone pulled these?
<DaemonFC> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=395d73413c5656c6d7706ae91dcb441f9b7e3074
<dtchen> DaemonFC: you can check yourself in ubuntu-jaunty.git
<DaemonFC> I was asking Eric Sandeen about that cause I just crashed a few hours ago
<amitk> dtchen: will try to have it for you by tomorrow. Not near the machine currently
<DaemonFC> and lost some data that hadn't been committed
<dtchen> amitk: that's fine, thanks
<Kano> hi, i found a missing firmware for 2.6.28+ for a dvb-s2 card for hauppauge
<Kano> dvb-fe-cx24116.fw
<Kano> should i write to the list?
<Kano> or does somebody directly want to add it..
#ubuntu-kernel 2009-04-02
<Kano> well sent a mail, hopefully the file is added...
<mathiaz> what's the process to get a specific changeset (included in 2.6.29) to be included in the jaunty kernel?
<dtchen> mathiaz: request a pull; see the trailing vertical edge of https://wiki.ubuntu.com/KernelPatches
<dtchen> mathiaz: ("How we will take it")
<dtchen> mathiaz: see also https://lists.ubuntu.com/archives/kernel-team/2009-March/004942.html if you haven't already
<mathiaz> dtchen: great. thanks.
<Kamping_Kaiser> http://packages.ubuntu.com/search?keywords=linux-image-generic just noticed - hardy is the only release with the security/updates problem. (guess thats a good thing)
<BUGabundo> good morning
<BUGabundo> can I get help debuging sis191 kernel module?
<BUGabundo> subsystem 0802
<Kano> hi rtg ,did you read my mail about the missing dvb-s2 firmware
<Kano> rtg: dvb-fe-cx24116.fw
<Kano> it had instructions how to extract it
<Kano> + checksum to verify
<ogasawara> rtg: mathias has a cherrypick request - bug 353496
<ubot3> Malone bug 353496 in linux "hpilo: open/close fix - commit c073b2db006ba9370be1eecc36a1be1d9ce31310 - included in 2.6.29" [Medium,Triaged] https://launchpad.net/bugs/353496
<Leon_Nardella> I know this is not a support channel, but could somebody please point me at some wiki page on how I can inspect/debug/gather evidences on ext4 freezes in order to file a better bug report?
<manjo> Leon_Nardella, launchpad.net
<manjo> look at other ext4 bugs that are filed
<manjo> should give you an idea what the developers are looking for in a bug report
<Leon_Nardella> manjo: I already filed a bug, with ubuntu-bug's logs and  simple instructions on how I can reproduce it on my system.. I'm just looking for something more specific. Someone told to me to try kdb, but I think it's a little overwhelming for me.
<manjo> what is the bug number ? 
<manjo> I am not an ext4 expert but I can advice on your bug report
<Leon_Nardella> manjo: #353451
<Leon_Nardella> I was researching on other other packages' bugs and I'm beginning to think it is somehow linked to that ext4 data loss bugs.
<Leon_Nardella> If you read the comment, you'll see people actually having 2 problems. First was their system freezing with no apparent reason and then finding they lost data.
<manjo> Leon_Nardella, are you able to ping the machine when it freezes ? 
<Leon_Nardella> manjo: That's a good question. Haven't tried that.
<manjo> can you run top with 2sec updates and see which process is running when you see the freeze/hang ? 
<manjo> so run top his s and say .2
<manjo> s/his/hit
<Leon_Nardella> I'll try both things when I have access to my system again.
<Leon_Nardella> What I can tell you is that absolutely nothing shows up in /var/log when it freezes and I can't kill X ( yeah, I know about dontzap )
<manjo> I have ext4 on my laptop and I have experienced freezes when I over load the machine with a ton of IO load 
<manjo> but if might be useful to see if you kernel completely hung or if you desktop is frozen by pinging it 
<manjo> also find out what process is currently running 
<Leon_Nardella> manjo: Have you found a fix for your freezes?
<manjo> no like i said I am not an ext4 expert ... 
<manjo> but ext4 is under active dev so some unstable behaviour is expected 
<Leon_Nardella> Indeed.
<liw> I did some testing wrt #257790 and I can now get my disks to work. However, I don't know what I'm doing and the changes may break things for other people.
<amitk> dtchen: updated bug #351924 with alsa-info
<ubot3> Malone bug 351924 in pulseaudio "Sound stopped working after recent upgrade to Jaunty beta" [Undecided,Incomplete] https://launchpad.net/bugs/351924
<manjo> I think there is a bug in the audio playback.. even when I mute flash is able to play sound 
<manjo> I have 32bit flash runinng under the wrapper 
<manjo> on 64bit
#ubuntu-kernel 2009-04-03
<dtchen> amitk: thanks, looking
<dtchen> amitk: it looks like a dupe of 315971. note from your alsa-info.sh output that 'Front' is muted.
<dtchen> amitk: please test combinations of unmuting 'Front' and 'Surround'
<dtchen> amitk: i'll leave it unduped for now
<bluefoxicy> Has anyone noticed horrible, horrible performance in Jaunty, which is quickly and easily solved by switching to AS via elevator=as on the kernel command line?
<bluefoxicy> somebody broke CFQ :|  it worked fine in the last release
<pwnguin> which, kernel, speficially, is "the last release"?
<bluefoxicy> bluefox@icebox:~$ uname -a
<bluefoxicy> Linux icebox 2.6.28-11-generic #39-Ubuntu SMP Thu Apr 2 04:39:54 UTC 2009 x86_64 GNU/Linux
<bluefoxicy> /var/cache/apt/archives/linux-image-2.6.28-11-generic_2.6.28-11.39_amd64.deb
<bluefoxicy> pwnguin:  oh, last release?
<pwnguin> yes, as in not the current current ;)
<bluefoxicy> whatever 8.10 was running 3 days before Jaunty went Beta
<pwnguin> you removed it already?
<bluefoxicy> itgot removed automatically when I upgraded.  I wound up with 2.6.27 and 2.6.28 somehow
<pwnguin> it's probably still in dpkg
<bluefoxicy> I'm pretty sure 8.10 wasn't running 2.6.27
<pwnguin> it was at the very start
<bluefoxicy> really?
<pwnguin> i think so
<bluefoxicy> huh.  I thought they got through 2 or 3 releases between versions...
<bluefoxicy> either way, yeah, then I removed it.
<pwnguin> you probably still have some kernels around but not in grub?
<bluefoxicy> they're not in dpkg
<bluefoxicy> bluefox@icebox:~$ ls -l /boot/*.img*
<bluefoxicy> -rw-r--r-- 1 root root 7891804 2009-04-03 01:04 /boot/initrd.img-2.6.28-11-generic
<bluefoxicy> bluefox@icebox:~$ 
<pwnguin> well
<bluefoxicy> anyway i need a shower real quick
<pwnguin> how do you feel about git-bisect?
<bluefoxicy> #*$& where'd i put the timer
<bluefoxicy> what's git bisect
<bluefoxicy> oh there it is
<pwnguin> git bisect is a way to sort of binary search for things in the revision history
<bluefoxicy> I have 40 minutes before bread has to be pulled from oven so I'll bbiab.  Mind you this behavior's been around since I started using Jaunty, there wasn't a single minor kernel update that set it in play for me
<pwnguin> have you by chance done anything with ext4?
<pwnguin> i was watching ted t'so give a talk about ext4 and he mentioned something about ext4 being able to use ext3 filesystems, im not sure if that comes into play or what
<pwnguin> well, im gonna play some video games and sleep
<bluefoxicy> k
<bluefoxicy> yes I started on ext3 and changed fstype to ext4, which helped a bit
<bluefoxicy> it was worse on ext3, but ext3 has more real disk IO
<dholbach> hi guys
<dholbach> there's a few linux / git items on http://people.ubuntu.com/~dholbach/sponsoring/ - not sure if you're going to consider them, but could you take a look?
<tkamppeter> Any USB/kernel expert around? Can you have a look at bug 348316? Seems to be a low-level USB problem.
<ubot3> Malone bug 348316 in linux "Printer (HWModel Name) May Not Be Connected" [High,Incomplete] https://launchpad.net/bugs/348316
<Kano> hi rtg , could you update karmic to 2.6.29.1
<rtg> Kano: I will continue to follow Linus throughout the -rc series. There is no guarantee that Karmic will even compile until after I upload the first Karmic package.
<Kano> so 2.6.30-rc1 next? 
<tytso1> stupid question.   I'm at http://kernel.ubuntu.com/git.   Which is the official Ubuntu kernel git tree for Jaunty?
<ivoks> ubuntun-jaunty.git
<ivoks> one n too much
<tytso1> hmm, I don't see that on the list of repo's at kernel.ubuntu.com.  i'll try going there directly and see what I get.
<ivoks> so... ubuntu/ubuntu-jaunty.git
<tytso1> Oh, there it is, yeah, I found it.   Thanks!!
<ivoks> tytso1: https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
<tytso1> Thanks, I'm trying to work https://bugs.launchpad.net/ubuntu/+source/linux/+bug/330824
<nxvl> hi
<ubot3> Malone bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Undecided,Confirmed] 
<nxvl> my sound just died 2 days ago (in Jaunty)
<nxvl> and i've been following all the Debugging documents in the wiki
<nxvl> but nothing seems to be wron
<nxvl> wrong
<tytso1> ubot3: #330824 seems pretty serious.   I'm trying to work it, but some help from some canonical kernel devs would be appreciated.
<ubot3> tytso1: Error: I am only a bot, please don't think I'm intelligent :)
<tytso1> heh
<nxvl> i've an Intel Corporation 82801H card
<smb_tp> tytso1, Just scanned over the bug. Seems like we would have to get into contact with Ted about his latest comment
<smb_tp> tytso1, Err drad. Seems like its you
<tkamppeter> Any USB/kernel expert around? Can you have a look at bug 348316? Seems to be a low-level USB problem.
<ubot3> Malone bug 348316 in linux "Printer (HWModel Name) May Not Be Connected" [High,Incomplete] https://launchpad.net/bugs/348316
<sladen> was anything changed between -9 and -11 to make {u,e}hci_hcd nonmodular?
<sladen> have somebody claiming that they are built in
<sladen> hence they can't unload the
<sladen> grepping .config shows *=y  ... 
<dtchen> sladen: yes, it happened for 2.6.28-10.33
<manjo> sladen, I think its built in
<dtchen> sladen: LP: #296710 is the reference
 * sladen reads
<sladen> so now, when a module is misbehaving, how does one now force the drive/blacklist the other
<sladen> tdg: <whinge-mode> when making a module built-in (cf. *_hcd), please (pretty please), could you mention it in the changelog
<sladen> dtchen: ta for the bug #
<dtchen> sladen: i pulled it directly from the changelog
<sladen> dtchen: oh.  apologies due.  I'd been (thought) I'd been through the changelog twice
<sladen> ah, I'd grepped for  -E (built.in|USB|hcd)  ... which cunningly doesn't match
<tkamppeter> Any USB/kernel expert around? Can you have a look at bug 348316? Seems to be a low-level USB problem.
<ubot3> Malone bug 348316 in linux "Printer (HWModel Name) May Not Be Connected" [High,Incomplete] https://launchpad.net/bugs/348316
<mkrufky> im trying to build a LUM for lpia and its complaining about a missing version.h .......
<mkrufky> i know i have the linux-headers installed
<mkrufky> im a bit baffled .....  i bet this is a simple one that im forgetting
<maxb> A LUM for which distroseries?
<maxb> LUM is rolled into the main image packages now
<mkrufky> hardy
<mkrufky> i see the problem now -- there is no /lib/modules/`uname -r`/build symlink
#ubuntu-kernel 2009-04-04
<Leon_Nardella> Anyone working on the ex4 freezes in Jaunty? I'm using the latest mainline build from the kernel-ppa and it seems to be free of this bug.
 * Leon_Nardella forgot to mention this is that bug that manifests under heavy IO
<Kamping_Kaiser> Hi, could someone explain the difference between https://launchpad.net/ubuntu/+source/linux and http://packages.ubuntu.com/search?keywords=linux-image-generic (or http://packages.ubuntu.com/search?keywords=linux )
<Kamping_Kaiser> the LP link indicates that hardy-security and hardy-updates share the same kernel versions, but p.u.c has them marked as different versions still
<maxb> Kamping_Kaiser: In the LP link, you are looking at the "linux" source package. In the p.u.c link, you are looking at the "linux-meta" source package
<maxb> Yes, it's a little confusing that the "linux" binary package is built by the "linux-meta" source package, not the "linux" source package
<Kamping_Kaiser> maxb, ah. so on LP i need to be looking at 'linux-meta' instead?
<Kamping_Kaiser> I should probably move a bug report then, since it relates to the linux-meta packages not linux.
<maxb> Well, that depends which package you're actually interested in :-)
<Kamping_Kaiser> linux-image-386
<Kamping_Kaiser> 350 bugs against linux-meta. criky. not sure moving the bug in there is going to help it
<Kamping_Kaiser> How can I mark https://bugs.launchpad.net/bugs/342638 as affecting linux-meta not linux ?
<ubot3> Malone bug 342638 in linux "linux-image-{generic,386} in -security uninstallable without -updates repository." [Undecided,New] 
<erle-> did anyone try to build kernel 2.6.29.1 with make-kpkg?
<asac> is there a hackish way to force a different vendor/product id for a usb device (e.g. so i can test a driver with a new device without rebuilding the kernel)?
<Kamping_Kaiser> hex editor + kernel module? hackish enough? ;)
<asac> hehe
<asac> good idea
<asac> too bad ... cant find the id ;)
<asac> is there anything i can look for in the module to find the right spot?
<asac> its cdc_ether ;)
<erle-> are the "mainline" kernels patched?
<erle-> i thougt that are vanilla kernels
<asac> heh. i think i found it :)
<asac> now i am scared ;)
<anubhav> asac: why not just recompile the module with your vend id and prod id
<asac> anubhav: hmm. whats the best way to just build a module?
<anubhav> offcourse you will need sources
<asac> i dont have a built tree here ;)
<anubhav> you are building against the standard ubuntu kerenel?
<asac> anubhav: i want to do that because i this thing also has some drivers that are not in mainline
<asac> so yes
<asac> i want to build a patched cdc_ether.ko
<asac> against current jaunty
<asac> darn ... now i cannot get the raw file from kernel.ubuntu.com ... gives me a 0 bytes download
<asac> good now it worked
<erle-> shouldn't a vanilla kernel build with a config of the ubuntu mainline kernel? (same kernel version!!)
<asac> anubhav: so i have the patched module source ... what i can do now?
<amitk> erle-: mainline kernels are stock linus' trees with the ubuntu config
<erle-> amitk, i know
<erle-> but it doesn't build here ...
<erle-> Makefile:529: /usr/src/linux-source-2.6.29/arch/xen/Makefile: No such file or directory
<erle-> make[1]: *** No rule to make target `/usr/src/linux-source-2.6.29/arch/xen/Makefile'. Stop.
<erle-> make: *** [conf.vars] Error 2
<erle-> i have no idea, why
<erle-> i don't care about xen
<asac> amitk: do you have any clue? i need to just build a single kernel module file i have here 
<amitk> asac: cdc-ether is compiled in?
 * amitk checking
<asac> amitk: its a module ... i need to build it with more device ids
<amitk> aah
<asac> amitk: http://paste.ubuntu.com/144184/
<amitk> asac: yes, it can be done AFAIK. Just looking for the right /sys file to put that info in
<asac> the other idea was to use hexedit ;)
<asac> my first hope was that i can force a different vendor/product id on that device somehow
<asac> just to test
<amitk> asac: /sys/module/cdc_ether/drivers/usb:cdc_ether/new_id
<erle-> now i use the sourcecode from the mainline thing and the config from the mainline thing and it still does not build ...
<asac> amitk: what can i do with that?
<amitk> asac: still looking for the exact incantation
<erle-> does nobody have an idea?
<amitk> erle-: it doesn't always build and it is too early on a weekend for me to know why :)
<erle-> it says he cannot build xen or something
<erle-> but there is no xen in the source code which actually should have been built
<erle-> do you use make-kpkg to build?
<erle-> maybe it is the tool failing
<asac> ok so its a colon separated list
<asac> amitk: http://paste.ubuntu.com/144189/
<asac> thats what i found on google :)
<asac> now i have to find the values for everything  before vendor
<erle-> it build now
<erle-> but i had to mod the configuration manually ...
<asac> hmm ... not sure if its the same for usb though
<amitk> asac: do a 'modinfo cdc-ether'
<amitk> the format of the alias strings might work
<asac> looking
<amitk> it is a concatenated string
<amitk> v=vendor, p=productid, etc.
<asac> echo 'usb:v413cp8147d*dc*dsc*dp*ic02isc0Aip00*' > /sys/module/cdc_ether/drivers/usb\:cdc_ether/new_id
<asac> bash: echo: write error: Invalid argument
<asac> echo "0 0 ffffffff ffffffff 413c 8147" > /sys/module/cdc_ether/drivers/usb\:cdc_ether/new_id
<asac> amitk: that didnt complain
<asac> ;)
<amitk> asac: New PCI IDs may be added to a device driver pci_ids table at runtime
<amitk> as shown below:
<amitk> echo "vendor device subvendor subdevice class class_mask driver_data" > \
<amitk> /sys/bus/pci/drivers/{driver}/new_id
<amitk> All fields are passed in as hexadecimal values (no leading 0x).
<amitk> The vendor and device fields are mandatory, the others are optional. Users
<amitk> need pass only as many optional fields as necessary: o subvendor and subdevice fields default to PCI_ANY_ID (FFFFFFFF) o class and classmask fields default to 0 o driver_data defaults to 0UL.
<amitk> Note that driver_data must match the value used by any of the pci_device_id
<amitk> entries defined in the driver. This makes the driver_data field mandatory
<amitk> if all the pci_device_id entries have a non-zero driver_data value.
<amitk> asac: so usb should be the same
<asac> amitk: yeah ... but it didnt really do anything 
<asac> but i dont know what to expect
<asac> i hoped that it showed up in hal ;
<anubhavrocks> asac: but the string you echo'd is diffrent from what amitk said
<asac> yaeh
<anubhavrocks> you mean to say PCI and USB have diffrent conventions?
<asac> echo "413c 8147" > /sys/module/cdc_ether/drivers/usb\:cdc_ether/new_id
<asac> amitk: would you think that that triggers udev events automatically?
<anubhavrocks> asac: i think this should work
<amitk> asac: it should, if the driver can actually bind to that particular device
<asac> i am quite sure it would work as its the same device just rebranded for dell
<amitk> http://jk.ufisa.uninett.no/usb/
<amitk> asac: ^
<asac> hmm ... unplugging is difficult for me ;)
<asac> ok trying udev rule
<asac> any idea what zaurus driver does?
<asac> ok rebooting
<asac> no change
<asac> not sure whz zaurus is always loaded
<anubhavrocks> blacklist the driver if you don't want it to load
<asac> i did that
<anubhavrocks> your problem is that when you insert your device the zaurus module loads instead of cdc_ether?
<asac> not sure. could be ... i think my problem is that just the device/vendor id is not enough
<asac> wait a sec
<asac> http://paste.ubuntu.com/144215/
<anubhavrocks> checkk the output of lsusb and make sure you enter the correct Vid Pid 
<asac> i think i also need to tell new_id that its USB_CDC_SUBCLASS_MDLM,
<asac> anubhavrocks: well. those are correct ;)
<asac> i get complain about invalid mdlm descriptors in dmesg
<asac> so i think thats really the problem
<asac> 16:08 < amitk> echo "vendor device subvendor subdevice class class_mask driver_data" > \
<asac> how could i encode a subclass there?
<anubhavrocks> asac: lsusb -v 
<asac> so back to square oone ... how can i just build this bloody .c file ;)
<asac> anubhavrocks: the ids are right :2)
<asac> wait a sec
<anubhavrocks> to get the subclass etc
<asac> Bus 001 Device 003: ID 413c:8147 Dell Computer Corp. 
<asac> ah
<asac> ok
<asac> anubhavrocks: well. the problem is that i dont kinow how to encude subclass in the echo above ;)
<asac> anubhavrocks: http://paste.ubuntu.com/144220/
<asac> isnt there a bloody gcc command to make a .ko out of .c ?
<asac> ok so i guess i will go for hexedit option
<asac>  that worked!!
 * asac dances!!
<asac> amitk: thanks :) ... hexeidt was the right thing i needed
<asac> [ 1541.258987] usb0: register 'cdc_ether' at usb-0000:00:1d.7-6, CDC Ethernet Device, 02:80:37:ec:02:00
 * asac back to modemmanager hacking ;)
<pjwaffle> hi this is a little off topic but it is for kernel purposes... how do you create a apt repo? I need to know so I can setup a repository for testing git version of kernel
#ubuntu-kernel 2009-04-05
<gene2>  I hate asking this here, but I've searched and searched, asked on #ubuntu and got nowhere. I'm looking to find the source for linux-image-2.6.24-23-rt, when I get it using apt-get source linux-image-2.6.24-23-rt, I get the regular source with the Ubuntu patch but the preempt stuff is missing, because when I tr to load the config I have running it complains about a bunch of preempt variables not existing
<gene2> I'd like to rebuild this package but I just cannot locate the ubuntu patch for 2.6.24.7-rt21, the original one does not apply clean
<infinity> gene2: The -rt kernel is built from the "linux" source package.  Nothing particularly magical about it.
<infinity> gene2: https://edge.launchpad.net/ubuntu/hardy/+source/linux/2.6.24-23.48 would be the exact source package you're looking for.
<alex_joni> gene2: look under debian/ for the -rt flavour
<alex_joni> it should have the config file there
<Kamping_Kaiser> hi all, how long would https://launchpad.net/ubuntu/hardy/+source/linux-meta/2.6.24.24.26 sit in proposed before getting copied to -updates and -security?
<infinity> Kamping_Kaiser: It's not going to get moved until the new kernels from proposed move first...
<infinity> Kamping_Kaiser: (And that won't happen until all the bugs fixed in the proposed kernel have been tested with no negative feedback or regressions)
<Kamping_Kaiser> infinity, fair enough. guess it'll move some time late next year then ;)
<Leon_Nardella> Isn't the latest kernel .40?
<Kamping_Kaiser> Leon_Nardella, latest where? latest upstream is .29
<Leon_Nardella> In the topic.
<Leon_Nardella> 2.6.28-11.40
<Kamping_Kaiser> could be right. *hasnt looked8
#ubuntu-kernel 2010-04-05
<zbenjamin> hi all
<zbenjamin> i have a problem with the iwlagn driver + 03:00.0 Network controller: Intel Corporation PRO/Wireless 5300 AGN [Shiloh] Network Connection
<zbenjamin> i cannot connect to the AP
<zbenjamin> with WPA2
<zbenjamin> dmesg output http://pastebin.com/XqHTQArQ
<zbenjamin> anyone can help with this?
<manjo> zbenjamin, why do you think it is a kernel problem ? 
<zbenjamin> i think its related to the driver
<zbenjamin> also i got redirected here from #kubuntu
<zbenjamin> i know the password is ok, windows can connect fine
<manjo> zbenjamin, it could be a network manager issue
<zbenjamin> the same problem when i use wpa_supplicant without network-manager same problem with wcid
<zbenjamin> so i doubt its related to network manager
<manjo> zbenjamin, what version of Ubuntu are you using?
<manjo> karmic ?
<zbenjamin> karmic , kernel Linux version 2.6.31-20-generic (buildd@crested) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) )
<zbenjamin> 64bit
<manjo> zbenjamin, kde ? 
<zbenjamin> yes
<zbenjamin> but currently i try with wpa_supplicant directly
<zbenjamin> i could post wpa_supplicant output if that helps
<zbenjamin> oh can this be the problem? Could not configure driver to use managed mode
<zbenjamin> from wpa_supplicant
<manjo> zbenjamin, you should open a bug on this... but I know it is hard to do without working network :)
<cnd> zbenjamin: are you specifying the AP by mac address instead of SSID?
<cnd> if so, maybe try by ssid, since that's a more commonly used and tested scenario
<zbenjamin> no i use SSID
<zbenjamin> also the AP is not hidden
<cnd> zbenjamin: ok, I've just not seen "direct probe to AP" messages before
<cnd> zbenjamin: can you try another router to test?
<zbenjamin> cnd: yeah this is a new message after i installed the backports-modules package
<cnd> sometimes there are strange interactions between specific drivers and routers
<cnd> which backports-modules?
<zbenjamin> cnd: i tried with other routers and it works, i also have exactly the same hw router at home and it works without a problem 
<zbenjamin> sec
<cnd> zbenjamin: same security type too?
<zbenjamin> linux-backports-modules-karmic
<zbenjamin> yes
<zbenjamin> but the router is not broken, i can connect to it from win without a problem
<cnd> zbenjamin: maybe this router has old firmware?
<zbenjamin> you think that could be a problem?
<cnd> zbenjamin: you may want to try the linux-backports-modules-wireless package
<zbenjamin> argh 
<cnd> zbenjamin: fw could affect anything
<cnd> so yeah, I would ensure you are up to date on your router's fw
<zbenjamin> could not find linux-backports-modules-wireless
<zbenjamin> this one? linux-backports-modules-wireless-karmic-generic
<manjo> yes.
<zbenjamin> a reboot is enough?
<zbenjamin> or do i have to disable some drivers?
<manjo> reboot is fine 
<zbenjamin> ok bib
<zbenjamin> back
<zbenjamin> i get this in messages: [  230.810852] ADDRCONF(NETDEV_UP): wlan0: link is not ready
<zbenjamin> and this in dmesg [  241.940662] wlan0: deauthenticating from 00:1a:2a:1a:fe:0c by local choice (reason=3)
<zbenjamin> that is totally weird
<manjo> so you are not able to connect still ? 
<zbenjamin> no
<zbenjamin> never had so much problems before
<zbenjamin> whats that: 
<zbenjamin> wpa_driver_nl80211_set_key: alg=0 addr=0x470a3c key_idx=3 set_tx=0 seq_len=0 key_len=0
<zbenjamin> nl80211: set_key failed; err=-67
<manjo> did this work previously ? 
<zbenjamin> yes i was able to create connections to other APs 
<manjo> zbenjamin, I have a feeling this is network manager related 
<zbenjamin> it cannot, i start wpa_supplicant by hand
<zbenjamin> wpa_passphrase and stuff
<zbenjamin> that was the first thing i did, disable networkmanager
<zbenjamin> hm if i use -Dwext on wpa_supplicant it cannot find a AP at all
<zbenjamin> Try to find WPA-enabled AP
<zbenjamin> Try to find non-WPA AP
<zbenjamin> No suitable AP found.
<zbenjamin> sorry for the paste, i should use a pastebin 
<zbenjamin> manjo: any other ideas?
<manjo> zbenjamin, no. you should open a bug with all this info in it. 
<zbenjamin> :(
<salgado> cnd, load seems a bit high (load average: 2.04, 2.04, 1.92) but I can't find where that's coming from
<cnd> salgado: it's probabaly a process stuck in a loop
<cnd> bear with me a moment
<salgado> sure
<cnd> salgado: do the following:
<cnd> sudo sh -x "echo function > /sys/kernel/debug/tracing/current_tracer"
<cnd> sit for a few seconds
<cnd> then do:
<cnd> sudo sh -x "cat /sys/kernel/debug/tracing/trace > ~/trace"
<cnd> then "bzip2 ~/trace"
<salgado> sh: Can't open echo function > /sys/kernel/debug/tracing/current_tracer
<cnd> then upload ~/trace.bz2 to lp
<cnd> salgado: oops, I mean sh -c
<salgado> did that using sudo tee, though
<cnd> in both cases
<cnd> after you cat trace, you can turn off tracing by echoing "nop" to current_tracer
<salgado> ok, uploading
<salgado> cnd, http://launchpadlibrarian.net/43167185/trace.bz2
<cnd> salgado: how many cpus are in the system?
<salgado> cnd, one cpu, 2 cores
<cnd> salgado: I'm not sure why your load avg is high, but it doesn't look related to this bug
<cnd> the trace doesn't show anything hung in a loop or anything related to graphics
<salgado> cnd, it seems to be doing tons of interrupts (700/s) and even more context switches (1800/s)
<cnd> salgado: I'm looking into mutex debugging right now, which will help us debug the core issue
<salgado> ok
<salgado> cnd, I need to step out for a bit, but I'll check back in 10 minutes or so, in case there's anything else I can do to help
<cnd> salgado: probably nothing for a bit
<cnd> I'm still researching
<salgado> ok, cool
<zbenjamin> manjo: it works, now guess what i have done
<manjo> :) 
<manjo> reinstalled network manager ? 
<zbenjamin> NO removed the plug !!!! 
<zbenjamin> using the normal switch did not work
<zbenjamin> !
<zbenjamin> i had to remove the power plug, and now it magically works 
<zbenjamin> took me only 8 hours to find :)
<zbenjamin> manjo: strange that it worked for windows
<manjo> you mean reboot the router ? 
<manjo> or unplug the power cord from the laptop?
<zbenjamin> rebooting was not enough, i had to remove the power chord from the router
<zbenjamin> i used the power switch before
<zbenjamin> but that did not help
<manjo> that is a bit strange... 
<zbenjamin> yes indeed
<zbenjamin> well maybe the router does only some suspend to ram thing who knows
<zbenjamin> ok i try to reconnect now lets see if it still works
 * zbenjamin hopes
<zbenjamin> manjo: still works 
<manjo> zbenjamin, cheers! what router is that ? 
<zbenjamin> its a Speedport W700
<zbenjamin> you get those from the t-online provider
<zbenjamin> http://www.findix.com/data/adpix/picture_L/router-t-com-speedport-w-700-v-194121.jpg
<zbenjamin> manjo: but it still has to be a problem with the driver, as i said it worked on windows
<zbenjamin> or the windows driver is aware of wrong behaviour from the router
<zbenjamin> or more error tolerant
<cnd> zbenjamin: had you tried windows after linux wasn't working?
<zbenjamin> cnd: yep
<zbenjamin> cnd: worked without a problem
<cnd> zbenjamin: I don't know then, but consumer routers are fairly flaky
<cnd> it's always good to try rebooting them
<zbenjamin> yeah well i tried to reboot it, using the power switch, but only removing the power chord fixed it
<zbenjamin> anyway thx for help guys
<cnd> glad to see your issue got resolved :)
<salgado> cnd, is there any use in leaving the crashed laptop running or is it ok to restart it?
<cnd> salgado: you can restart it
<salgado> cool
<salgado> back in a bit
<cnd> hmmm... I'm getting errors on prepare-generic on the lucid sources, even after git clean -f -d, git reset --hard HEAD, and fdr clean
<cnd> apw, ogasawara any thoughts?
<ogasawara> cnd: hrm, what's the exact error?
<cnd> ogasawara: /home/cndougla/Canonical/ubuntu-lucid is not clean, please run 'make mrproper'
<jjohansen> cnd: run make mrproper and then do git checkout -f
<jjohansen> that happens with the kernel build system some times
<jjohansen> especially if you end up mixing fdr and regular kernel builds
<jjohansen> cnd: basically there are some files there that the build system is checking that git is ignoring so they don't show up in a git status
<cnd> jjohansen: ahhh, that makes sense
<jjohansen> the checkout -f will restore your debian directories etc that mrproper will destroy
<cnd> jjohansen: yep, it's working now, thanks!
<manjo> cnd it will be cool to doc that in the wiki 
<manjo> kernel mainintanence starter or so
<cnd> manjo: yeah, I'll add it to my task list
<salgado> cnd, any news about that bug?  or can you think of anything I could try as a workaround meanwhile?  (it's happened two more times in the last 30 minutes...)
<cnd> salgado: I'm building a debug kernel right now
<cnd> I'll probably have it ready for you within the hour
<cnd> I'll post in the bug when it's ready
<salgado> cool.  I just hope the bug doesn't go away when I install the debug kernel. :)
<cnd> heh, it shouldn't, but you never know :)
<cnd> it would be a really nasty bug if that were the case
<salgado> cnd, http://people.canonical.com/545039/ is a 404
<cnd> salgado: oops: http://people.canonical.com/~cndougla/545039
<salgado> that one works. :)
<salgado> cnd, I'm now on the karmic kernel, as the Lucid one wasn't allowing me to get any work done.  luckily it will crash quickly once I switch to the new kernel you built
<cnd> ok
 * salgado restarts
#ubuntu-kernel 2010-04-06
<amitk> apw: are we going to pull in 2.6.33.y updates into the OMAP branch? (I guess this is an smb question)
<apw> amitk, that would be the expectation, and why that branch is a huge maintenance burden ... its entiryly separate
 * amitk nods
<bjf> ##                                                                                           
<bjf> ## Kernel team meeting today @ 17:00 UTC                                                     
<bjf> ##                                                                                           
<ricotz> ogasawara, hello, i am using your ubuntu-m.git branch, i have a short question: are you going to synchronize it with every rc release?
<ogasawara> ricotz: yes
<ricotz> ogasawara, great, thank you
<ogasawara> ricotz: I've got it built and uploaded to my PPA as well if you're interested
<ricotz> ogasawara, i have packaged it myself, but a ppa is a lot easier, where can i find it?
<ogasawara> ricotz: https://edge.launchpad.net/~leannogasawara/+archive/ppa
<ricotz> thanks!
<crimsun> bjf: which symptom are you trying to address in #331589?
<crimsun> bjf: also, please bump debian/changelog for karmic's alsa-driver cod
<bjf> crimsun, will do the bump
<bjf> crimsun, i haven't completely groked the bug so i need to identify the issue with lucid, i've not experienced it myself
<bjf> crimsun, i was asked 5 minutes ago to take it on and i'm in the middle of an interview :-)
<crimsun> bjf: apw and I looked into the config issue a while back (~2 months ago IIRC); you may wish to ping him
<bjf> crimsun, he's the one that asked me to take it on :-), I'll talk with him
<apw> crimsun, as i remember it all circled back to not being that configuration option but a new bug, something appears to be wrong with the frequency calculation on a small number of codecs rather than a general 'it being enabled'
<apw> in the original issue, we had the high pithed beep on all hda's (i think), now we have a 'mains hum' on some systems, my dell 1537 for one
<apw> though i have it muted and don't get an issue per-see
<crimsun> that freq calc was supposed to be fixed by 369693dc9
<crimsun> (which is in ubuntu-lucid.git)
<crimsun> apw: what is "mains hum"?
<apw> 50hz sounding buzz.  the noise you hear also when touching the headphones plug on the housing when shoving it in
<apw> often at max volume in my experience
<apw> unmuting my HDA PC Beep seems to imply its still there
<apw> i have to switch to VT-1 to trigger it mind here
<apw> i hear on some machines it occurs during reboot etc 
<apw> though i've not seen that myself
<crimsun> oh, that
<apw> crimsun, having just tried it, its more harsh than mains hum, all breaky up and raspy
<crimsun> so, that's a very different issue from the original bug report
<crimsun> bjf: which is why I asked in the response which symptom you're chasing :-)
<apw> ahh so we have conflated bug report, so we should split it up and close the fixed bit :)
<Sarvatt> apw: does it go away if you disable the mic? 
<apw> Sarvatt, disable as in mute?
<apw> Sarvatt, and while i think about it, we need to get with bryce and work out what to do about these LID things
<Sarvatt> sound preferences - hardware - change to analog stereo instead of duplex, or mute yeah
<apw> Sarvatt, in that case ... nope unchanged by switching off input
<crimsun> it isn't a feedback loop; this latest symptom is related to the "shutup" code on powering down/rebooting
<apw> cking, that patch is now on the kernel-team list
<cking> ta
 * cking looks
<Sarvatt> apw: digging into it now, was taking a break and working on xserver and input stuff after the nonstop flood of dupe intel reports that week you were gone :)
<crimsun> jjohansen: that apparmor symptom can be worked around by disabling swap.
<crimsun> jjohansen: granted, may not be useful for actually finding the culprit(s)
<crimsun> ah, bah, just saw in -meeting
<jjohansen> crimsun: no, thanks its really good to here from another source
<johanbr> for the latest mainline kernel build of 2.6.34-rc3, linux-headers-2.6.34-020634rc3-generic depends on linux-headers-2.6.34-020634rc3
<johanbr> but the latter package seems not to have been built...
<apw> johanbr, that sounds incorrect
<johanbr> well, generally, linux-headers-*-generic depends on linux-headers-*, right?
<johanbr> so the problem seems to be that linux-headers-2.6.34-020634rc3 is missing
<crimsun> right, according to the buildlog, dh_builddeb -plinux-headers-2.6.34-020634rc3 isn't called
<manjo> kamalm, does that work the similerly  for brighness keys too ? 
<manjo> kamalm, I have samsung netbooks which have issues with brightness keys 
<kamalm> manjo: no, the brightness keys problem(s) seem to be a different problem altogether -- on my Dell Studio 1558, the brightness keys do seem to make it to ACPI fine but dmesg records that ACPI was "unable to adjust brightness" or something -- not the same "never releases the key" problem (for me at least)
<manjo> kamalm, yeah its the same for samsung as well
<apw> johanbr, indeed ... missing it is
<apw> crimsun, looks like we didn't do the indep pass ... hrmph
 * apw needs the bit of the log which is not preserved, so will have to rebuild it
<jjohansen> apw: ping question on potential Lucid patch that will partly address Bug #552225, and maybe Bug #549428
<ubot3> Malone bug 552225 in apparmor "system bogs down when apparmor is running" [Undecided,New] https://launchpad.net/bugs/552225
<ubot3> Malone bug 549428 in apparmor "Triggers permanent high i/o load after upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/549428
<jjohansen> basically, its an optimization patch that removes 1 set of cases where revalidation is done
<jjohansen> it is not what is going into the upstream side, as that is a much larger series of patches, which is just to risky to drop into Lucid
<apw> ok
<apw> if it fixes a known issue and you can handle the skew the different patch directions cause ... i am happy
<jjohansen> so is a patch that will only address some potential performance problems worth dropping in this late
<jjohansen> okay
<jjohansen> I'll run through testing it today and drop a patch or two
<gzmask> how long it takes to compile linux kernel 2.6?
<gzmask> on a quad core mac pro but in VBox?
<florianTS> Hi. I am the viafb maintainer in the linux kernel and just found this bugreport. I think I identified it as a bug that was present in 2.6.32 and fixed in 2.6.33. As I am not an Ubuntu user myself and additionally can't reproduce this on the hardware I have I am wondering how to solve this issue.
<florianTS> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539020
<ubot3> Malone bug 539020 in linux "Lucid Beta 1 installation CD gives blank screen and freezes" [Undecided,New] 
<ogasawara> florianTS: I can build the bug reporter a test kernel with the patch(es) you mention backported.
<apw> florianTS, hrm tricky
 * apw realises ogasawara is taking the words out of his mouth and shuts up :)
<ogasawara> florianTS: I'll post a comment to the bug once I've got something built
<florianTS> ogasawara: thanks I think this would help very much.
<jonmasters> Ubuntu bug 356317 - "MAke click-and-drag work for Macbook(Pro) 5,1+"
<ubot3> jonmasters: Error: Could not parse XML returned by Ubuntu: HTTP Error 404: Not Found
<jonmasters> did anyone attempt to get that upstream?
<bjf> florianTS, sorry if you got bounced around a bit this morning
<florianTS> bjf: No problem. At least this could now be a happy end for users, Ubuntu and viafb. That's far more pleasant than frequently querying VIA for some bits of documentation for about one month.
#ubuntu-kernel 2010-04-07
<Elv1313> Today'S ISO image does not boot
<Elv1313> it say: "BUG: soft lockup - CPU#0 stuck for 61s! [event 0:6]"
<Elv1313> I filled a bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/557351
<ubot3> Malone bug 557351 in linux "Ubuntu 10.04 does not boot" [Undecided,New] 
<apw> Elv1313, does not boot on what
<Elv1313> apw: see the bug report
<apw> Elv1313, pentium 4 is not terribly specific
<Elv1313> Unfortunatly, I can't be that much more specific, let me check
<apw> Elv1313, also which CD was it? is that the 32 bit live, 64 bit live, 32/64 alternate ?
<Elv1313> ht7961
<Elv1313> the 32bit live cd
<Elv1313> The exposed chip of the motherboard (southbridge) have ht7961 written on it.
<Elv1313> apw: lspci in 9.10 say SiS654 chipsset
<apw> ok if we 
<apw> ok if we have no name for the machine we really need some fuller information via apport-collect perhaps from the previous release
<apw> i have also put some first diagnostics steps in the bug
<Elv1313> apw: I submitted the apport-collect information (sudo apport-collect 557351). I can go in single user mode as the init script scrash before (upstart) init 1
<apw> Elv1313, in your trace ureadahead is running which is started as an upstart job i believe
<apw> Elv1313, you could try booting init=/bin/bash too
<Elv1313> it's all I can do, as it is one of my client computer, they pay me right now, so I can spend too much time
<apw> Elv1313, fine
<Elv1313> apw: I will try, but it is the last thing I will do
 * Elv1313 back in 1 hours
<apw> cking, hey if i have an m1330 overheating ... fans run slowly all the time ... in lucid the temp is more like 60c and in karmic 40 odd ... whats the best way to diagnose such a thing
<cking> apw, do the fans run faster in karmic?
<apw> i believe so ... pgraner has the machine
<apw> it seems that they don't react to heat, but heat is reported correctly
<cking> well, if fan control was purely a SMI based BIOS control, then we'd see no difference, so it's kinda an ACPI issue I suppose
<apw> gah i hate acpi ...
<cking> is this "straight out of the box" or has he installed some fan control guff?
<apw> fresh install at that level
 * cking consults the ACPI spec as this is unfamiliar ground
<BenC> Suggestion/request: See about building videobuf-dma-contig module forcefully
<cking> apw, is there /proc/acpi/fan/FAN/state on that machine?
<BenC> It's in 2.6.28 kernel, but since nothing uses it, it's not built in any ubuntu kernels after that
<BenC> but external modules tend to use it (like the one I'm writing)
<BenC> IOW, it exists in jaunty and before, but not after jaunty
<cking> apw, does it have an Nvidia 8400 GS inside it?
<apw> cking, its an all intel machien
<apw> cking, we may have a fix ... he is just testing
<cking> apw, that was quick. what's the fix?
<apw> may be the same fix as for my machine.  looking like with my kernel its happy
<cking> apw, is that the multi byte embedded controller fix?
<apw> cking, yeah
<cking> Apparently the CPU + GPU are close together on the XPS M1330, so it may be exercising the video can make things toasty
<apw> cking, yeah they have a rep for the gpu fans going too i think
<BenC> cking, apw: On the m1330 I had, the video toasted itself into not working anymore
<BenC> bad thermal handling for gpu is common on m1330
<apw> BenC, ouch
<cking> BenC, yeah, googling brings up loads of tales of woe. No supertuxkart on this machine then
<amitk-afk> new thermal paste?
<BenC> internet blogs suggest taking them apart and applying thermal paste in large quantities between the gpu and copper thermal duct
<cking> new machine more like
<BenC> but mine was way too gone by then to test the suggestions :)
<Elv1313> apw: I am in init=/bin/bash, now what? 
<apw> Elv1313, does dmesg contain the error you mentioned?
<Elv1313> apw: look clean up me
<apw> hrm
<Elv1313> apw: is there a way to start the boot process from here and recover the log
<Elv1313> (i am on a live-cd)
<apw> Elv1313, normally i then make a live usb stick as you can make it have persistant storage
<apw> if you exec upstart you should start normal boot
<Elv1313> I have no time to do that, I am working for a cononical parther compagnie (sysadmin shop), if this is not going to work we will look like idiots...
<dmarkey> hey, re: https://lists.ubuntu.com/archives/kernel-team/2010-April/009770.html can we include the xenfs module aswell?
<apw> Elv1313, well i can only do what i can do with the info i have
<apw> for an unknown machine something unknown is occuring ... its actully hard to recommend anything
<apw> with that information ... sorry but thats the realtity
<Elv1313> I know... I can't do much about it. exec upstart = upstart command not found
<apw> Elv1313, i guess its exec /sbin/init, but i suspect you'll end up in the same place
<apw> dmarkey, could you reply to the thread on that on the kernel team list and start the discussion there
<apw> lucky for you i've not applied the previous fix yet
<dmarkey> apw: understood
<Elv1313> apw: Yea, it frozen instantanly, I lost ability do to ctrl+C avec alt+F* too
<Elv1313> SReadAhead is nice in Moblin, but backporting it to ubuntu may not have been the greatest move ever (apparently)
<Elv1313> apw: can you change the status of the bug back to new? (as I added most of the missing info)
<apw> Elv1313, remind me of the number
<Elv1313> 557351
<apw> i have sadly looked at close to 50 today ...
<apw> bug #557351
<ubot3> Malone bug 557351 in linux "Ubuntu 10.04 does not boot" [Undecided,Incomplete] https://launchpad.net/bugs/557351
<Elv1313> new or confirmed
<dmarkey> apw: do i have time to test something first?
<apw> dmarkey, we are running tight to change anything
<apw> but if you want to test thats great
<dmarkey> well im pretty sure that without xenfs, the console isnt set up properly in /etc/init/* , but i need to confirm
<cnd> I'm bisecting an older kernel, but when I build I get this at the end:
<cnd> dpkg-deb - error: (upstream) version (`unknown') doesn't contain any digits
<apw> cnd, whats the version in the changelog ?
<cnd> apw, I just realized I wasn't running in a chroot
<cnd> maybe that's the cause?
<apw> hmmm maybe ... not totally convinced but its easy to test
<cnd> apw: not a chroot issue
<cnd> I find the Version: tag listed as "unknown" in debian/linux-image-2.6.32-10-generic/DEBIAN/control
<cnd> what sets that?
<ScarFreewill> ogasawara packed a kernel for me to test, its related with the radeon driver. my question is little offtopic as I'm seeking some help to test it propperly with saving as much bandwidth as possable
<ogasawara> ScarFreewill: I assume this is for bug 533784 ?
<ubot3> Malone bug 533784 in debian "[Radeon kernel module] drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream" [Unknown,Confirmed] https://launchpad.net/bugs/533784
<ScarFreewill> yes that's correct
<ogasawara> ScarFreewill: and you've already downloaded the test kernels I built?
<ScarFreewill> I'm busy copying mini.iso (6 Arpil) to my flashdrive so that I can just load x on there.
<ScarFreewill> I've got a spare old hdd that I can test with
<ScarFreewill> I'm just wonder if it's needed to load something like Fluxbox or if I can use plain x-server
<ogasawara> ScarFreewill: I think I'm a little confused as to what you're asking.  But basically whatever you can reproduce the issue on, I want you to retest in that same environment with the test kernel.
<ScarFreewill> ok I was also not sure if I needed to add the xorg-edgers ppa
<ScarFreewill> the only reason I'm using the mini image instead of alternate/dekstop is because I dont have enough bandwidth to download the full cd.
<ScarFreewill> building up from scratch will time more time, but thats not a problem for me
<dmarkey> apw: thats fine, the xenfs module isnt needed
<apw> dmarkey, so we are good with the patch which is being pushed yes
<dmarkey> yes, i manually included xen-netfront.ko and xen-blkfront.ko and the installer worked OK,
<dmarkey> i need to raise another bug in the installer however. i'll need to be fast
<ScarFreewill> ogasawara: sorry to bother again, I'm really new to this. Is there a ppa for those kernel debs that you packed or should I rather just use dpkg to install it?
<dvheumen> hi, are you guys also open for questions about disappearing partition "devices" in /dev? I've got a very strange problem during an Alternative installation that I can't put my finger on
<ogasawara> ScarFreewill: sorry, no ppa.  just use dpkg.
<RAOF> apw: Are you still around?  Can I push a patch to quirk off acceleration for nouveau on macbook pros and geforce 3's to you (once I've tested it does what I want, such as build ;))?
<jjohansen> RAOF: I think he is probably sleeping, but if you send it to kernel-team he should be back on in 8 - 9 hours
<RAOF> And I should have been able to build the damnable kernel in 8-9 hours too, so I'll be ready!
<RAOF> :)
<jjohansen> :)
#ubuntu-kernel 2010-04-08
<ScarFreewill> ogasawara I'm just curious about the timezone, you're in Canada right? Anyhow it seems to be working fullscreen in both the default kernel and the one I got from launchpad.
<ogasawara> ScarFreewill: so your issue is resolved with the latest 2.6.32-19.28 kernel (ie you don't need the patches I built into the test kernel)
<ogasawara> ScarFreewill: which bug do you fall under in https://bugs.edge.launchpad.net/ubuntu/+bug/533784/comments/14 ?
<ubot3> Malone bug 533784 in debian "[Radeon kernel module] drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream" [Unknown,Confirmed] 
<ScarFreewill> yeah both issues I had
<ogasawara> ScarFreewill: as my patches only resolve issue #2
<ScarFreewill> drmRadeonCmdBuffer: -12
<ogasawara> ScarFreewill: well, I guess it doesn't hurt to post a comment to the bug that you no longer experience the issue with the stock 2.6.32-19.28 kernel.
<ScarFreewill> yeah I will do that, just want to run one or two more tests to be really sure.
<ogasawara> ScarFreewill: sounds good.  thanks for testing.
<ScarFreewill> no problem, thanks for the help
<apw> RAOF, hi
<RAOF> apw: Good morning to you.
<apw> something something quirk something
<RAOF> Yeah.  A quirk for nouveau to disable acceleration on a couple of cards.
<apw> RAOF, did you send it yet?
<apw> i don't see it on my patch list yet
<RAOF> Not yet; I'll do so now.
<RAOF> By send it, you mean to kernel-team@, or attached to a bug lovingly tied with a ribbon with your name on it?
<apw> kernel-team@ is where they get into our patch tracker
<RAOF> Ok.  I'll wrap it up in a git-format-patch and bundle it off.
<apw> make sure it has the buglink: in it :)
<RAOF> It'll have two.
<cjwatson> hi, I don't have mail access right now, but could somebody apply http://paste.ubuntu.com/410932/ for lucid, assuming that we're going to include the xen-{blk,net}front udeb patch that smb sent to kernel-team@?
<cjwatson> that would let us build a netboot image more or less suitable for xen
<cjwatson> build-tested, seems to DTRT
<apw> cjwatson, looking
<apw> cjwatson, will sort that out ...
<cjwatson> thanks
<apw> sorry been reviewing 100 odd patches and not looking at irc
<dmarkey> apw: re: [PATCH 1/1] UBUNTU: d-i -- enable udebs for generic-pae, when/where would i be able to get my hands on an image/install initrd, to test?
<apw> dmarkey, heh ... you are quick ...
<apw> dmarkey, if a new kernle image is all you need i can get you one of those pretty easy
<apw> if you need real isos then they are hard to make and you'd have to wait for the kernel to go up
<dmarkey> all im looking for is a kernel and an _inatall_ initrd
<dmarkey> install*
<dmarkey> for netboot
<apw> dmarkey, not sure how one makes those special initrds
<apw> cjwatson, do you know if its easy to make the installer initrds separatly from the iso's ?
<amitk> 13:58 < ogra> well, on systems that dont use initramfs you dont want the package to forcefully create one
<dmarkey> i know the netboot initrd is slightly different for the server/iso one
<amitk> 13:59 < persia> Indeed.  kernel-img.conf should always be respected, and every type of installer should create it. 
<amitk> apw: ^^^ what ogra said about initramfs
<ogra> apw, was that changed in lucid ?
<ogra> usually "do_initrd = yes" in /etc/kernel-img.conf rules if update-initramfs is run or not
<apw> that file is used by the  postinst etc isn't it?  and none of that has changed
<ogra> and the live image doesnt have a kernel-img.conf so if i install a kernel .deb it shouldnt run update-initramfs 
<ogra> yeah, i think there is a piece in the postinst that checks kernel-img.conf
<ogra> some ugly perl cod iirc
<apw> i am not sure we do anything with do_initrd though
<apw> i actually cannot see any support for that variable doing anything, ever
<apw> it doesn't seem to be honored in hardy even
<ogra> weird
<amitk> is this the first time we're try images w/o initramfs?
<amitk> *trying
 * apw isn't sure we've been able to do normal boots really without one
<ogra> i'm sure i didnt have installing a kernel .deb ever running update initramfs if no kernel-img.conf existed
<apw> so i can see it wouldn't work quite easily
<apw> the kernel understands the variable, parses it etc, and uses it for exactly nothing all the way back to hardy at least
<ogra> amitk, we dont do images without initrd but we start to support systems without it or at least move towards that
<ogra> the OSG team has installs without initrd
<apw> perhaps /usr/sbin/update-initramfs is meant to understand it
<ogra> the images will always need one
<ogra> apw, well, but what calls update-initramfs at all now ?
<apw> the kernel post inst for one
<cjwatson> apw: I can do it
<ogra> a simple dpkg -i linux-image*.deb didnt exec update-initramfs in the past
<cjwatson> apw: only after I have the kernel bits though :)
<cjwatson> apw: honestly, it's easier for dmarkey to be patient for a day or two more ...
<apw> cjwatson, yeah i was thinking the same
<cjwatson> dmarkey: it isn't quite that simple, the installer initrd expects to be able to load further udebs from the archive, usually
<dmarkey> oh yes, which dont exist yet
<apw> ogra, i cannot see how that could be, we unconditioanlly call initramfs creation based on $initrd which is unconditionally YES
<ogra> weird
<apw> same in hardy
<cjwatson> https://wiki.ubuntu.com/FoundationsTeam/Grub2Efifb - results of discussions between Keybuk and me, if anyone would like to look over it from a kernel POV
<cjwatson> the "Notes from pre-BoF" section is the interesting bit
<dmarkey> cjwatson: but in userspace, the udebs can be the same as non-pae i386 archive
<cjwatson> dmarkey: doesn't matter
<cjwatson> dmarkey: not all the kernel udebs are built into the netboot initrd
<dmarkey> i see, so supplemental modules etc
<apw> cjwatson, there doesn't seem to be much there for kernel really ... just a 'new kernel'
<cjwatson> apw: and a config change, and the linked patch or similar
<apw> we are likely to have .35 maybe even .36 ...
<apw> the patch needs some love as it is being ripped to shreds in review
<mjg59> I'm really not clear on why this is preferable to vesafb
<apw> cjwatson, so this udeb change, do you want me to expedite an upload with that so it ends up in an image sooner?  though that might mean we do two not one upload before release ?
<apw> i guess efi is the way of the future?
<mjg59> apw: If you're using efi, you generally don't have vesa
<cjwatson> mjg59: it seems, frankly, a hell of a lot simpler
<cjwatson> mjg59: efifb drawing is not dependent on efi, it's just a badly-named simple linear framebuffer
<mjg59> cjwatson: Yeah, but so's vesafb
<cjwatson> which grub already knows how to program
<cjwatson> existing code > hypothetical code
<cjwatson> apw: no desperate rush, but I wouldn't want to be too squashed for time - is there an upload planned for shortly after beta-2?
<mjg59> Handoff between vesafb and kms is supposed to work
<apw> i was planning on just one more early next week i guess.  though i will be doing a pass to slurp up all the pending patches 'now' ... so i could push that too
<cjwatson> why should I bother changing grub to set up vesafb rather than efifb, is what I want to know
<cjwatson> what's the point
<mjg59> cjwatson: I don't understand
<mjg59> cjwatson: grub doesn't set anything up
<cjwatson> that is false.
<mjg59> It sets a mode
<mjg59> There's a defined mechanism for passing video mode information to the kernel
<cjwatson> and it feeds it into the screen_info structure and sets the word in the boot parameters that causes the kernel to use efifb
<cjwatson> if you use gfxpayload=keep that is
<cjwatson> this *all works right now*, aside from a tiny number of adjustments needed
<cjwatson> I see no benefit in redesigning it ...
<mjg59> If screen_info is populated, then loading vesafb should just work
<cjwatson> and so does loading efifb
<cjwatson> which seems a lot more lightweight
<mjg59> As long as it's set to VIDEO_TYPE_VLFB
<cjwatson> either way, we'd need to get fbcon to stop clearing the screen
<cjwatson> so I don't see the difference
<mjg59> Ok. As far as I can tell, the only distinction in functionality here is whether grub passes VIDEO_TYPE_EFI or VIDEO_TYPE_VLFB
<mjg59> If grub is passing VIDEO_TYPE_EFI when it's not using EFI, then it's buggy
<cjwatson> what I'm asking is why I should bother changing anything at all
<cjwatson> given that efifb appears to work perfectly well
<mjg59> Things will then potentially break if we ever start supporting the EFI virtual machine and using EFI for modesetting under the kernel
<cjwatson> is that at all likely?
<mjg59> Because the bootloader is lying to us about the hardwre capabilities
<mjg59> I worked on it for a while
<mjg59> But stopped when I found that no hardware I had supported the modesetting
<mjg59> I think that's starting to change now, though
<mjg59> I should actually check whether my current laptop does
<cjwatson> does vesafb still completely screw suspend/resume?
<cjwatson> or is that just a matter of vbe save/restore now?
<mjg59> Yes, but no more than efifb
<mjg59> You'll never get reliable suspend/resume without KMS
<mjg59> Oh, yeah
<mjg59> It's also worth noting that programming KMS from a vesa mode is basically untested
<cjwatson> well of course, I just don't want to completely fuck it beyond redemption
<cjwatson> well, except that several thousand people seem to have started using gfxpayload=keep in lucid against my recommendations
<mjg59> cjwatson: efifb and vesafb have identical properties from a suspend/resume point of view
<cjwatson> ok
<mjg59> And both are irrelevant if you've done kms handoff
<mjg59> So, really, I'd recommend getting grub to pass the correct argument and just using vesafb
<mjg59> It's really a bug that efifb doesn't check efi_enabled before binding
<cjwatson> I can probably manage to test that today
<cjwatson> Scott already has most of the pieces set up
<mjg59> But in either case, you're likely to hit some number of cases where novueau/radeon/intel fail to go from vesa mode->native
<mjg59> I know that some people have trouble if they boot with vga=, which is equivalent
<mjg59> It ought to work, but like I said, it's less well tested
<cjwatson> one possibility is to configure things this way only if KMS is there when you run update-grub
<cjwatson> oh, that *is* KMS sorry
<mjg59> Right
<mjg59> It's all something of a mess
<cjwatson> are those bugs typically moderately tractable?
<mjg59> Yeah, just generally not high priority
<Keybuk> right, efifb vs. vesafb is just which one the kernel happens to pick
<cjwatson> are there any references I could gather on what the problems tend to be?
<mjg59> Not that I can think of
<mjg59> Text mode on a given card is generally pretty standard
<Keybuk> fwiw, we have a reasonable number of people using grub's gfxpayload=keep now without problems
<mjg59> But vendors may fiddle with what a given vesa mode on a card actually is
<mjg59> Keybuk: Right, like I said, it *should* work
<cjwatson> I thought half the point of KMS was to reprogram from scratch
<mjg59> But there are some people for whom it doesn't
<Keybuk> mjg59: do you have bug reports for these?
<mjg59> cjwatson: Yeah, but graphics hardware is hard
<mjg59> Keybuk: I don't generally follow the graphcis bugtrackers - this is from people popping up on IRC
<mjg59> I mean, it's worth you going for it
<Keybuk> those people could be having issues with the buggy handover in .32 of course
<apw> cjwatson, what do we gain in going graphics in grub, if we are in a non-native mode and have to mode switch and get a flicker from that?
<mjg59> But it's "simpler" to not show a graphical bootloader at all, and just stay in VGA text until you load a native driver
<cjwatson> apw: smooth splash all the way from the bootloader, and slightly faster boot
<mjg59> The kernel will now avoid turning on the blinking text cursor if grub turns it off
<Keybuk> mjg59: the trouble is that that means 45s of a black screen with a flashing text cursor
<Keybuk> or even 45s of a plain black screen
<Keybuk> setting some kind of mode and a logo in grub covers that
<cjwatson> mjg59: is that recent?  I saw that broken fairly recently
<mjg59> Well, for most modern hardware, grub can't set the native resolution
<cjwatson> that may change
<cjwatson> phcoder has been vaguely seriously talking about importing KMS code into grub
<apw> yeah unless it can do native we may just get a new flicker
<cjwatson> I think he's insane, but it's entirely possible he can do it
 * apw hides from that
<mjg59> cjwatson: Right, but that avoids the problem differently - a lot of KMS modes are tiled rather than linear
<Keybuk> apw: this doesn't introduce any new flicker fwiw, just ensures that the time until the second one is colourful
<mjg59> So you can't use a trivial framebuffer anyway
<apw> Keybuk, and that i concur has to be better
<cjwatson> still, IMO not-black-screen is better than flicker-free
<cjwatson> err
<cjwatson> rearrange that until it makes sense
<mjg59> Heh
 * apw gets totally pissed off with the gdm theme which will not update to the latest ...
<apw> who do i hastle to find out how to change it
<Keybuk> it also means
<Keybuk> fwiw
<Keybuk> that we always have a relatively decent framebuffer
<Keybuk> even if everything fucks up
<Keybuk> which makes the failsafe X cleaner, since we can just always fall back to fbdev
<cjwatson> mjg59: interesting, I wonder what to do about that
<Keybuk> (which X does itself)
<mjg59> cjwatson: Hm. Actually, maybe we do attempt to ensure that you have a linear framebuffer, and then X changes over to tiled (without a modeset)
<mjg59> Not sure of that, though.
<apw> Keybuk, i meant to ask, is the reason plymouth has a kms driver per kernel kms driver ... because the framebuffer is non-linear, ie. tiled
<cjwatson> what I meant to say above is that I don't think it's vital that the mode in grub is always 100% absolutely guaranteed to be the same as the one we end up in
<cjwatson> it would be *nice*, but the world won't end if it's not
<mjg59> Keybuk: d9b263528e01bfbaf716b51f38606b3dfe5ac1e9
<Keybuk> apw: no, it's because the kernel sucks
<Keybuk> mjg59: neat
<apw> heh nice
<Keybuk> apw: Plymouth allocates its own buffers, and maps these to the individual heads of each card
<mjg59> Keybuk: There's some followup patches that then pass that to the vt layer
<Keybuk> so each output is in the correct native mode, etc.
<cjwatson> cursor> ok, that's good
<Keybuk> (rather than painting over fbcon)
<Keybuk> the API for doing that is different depending on which driver you're using
<Keybuk> intel has its own API (GEMish)
<Keybuk> nouveau has its own API (GEM on TTMish)
<Keybuk> radeon has its own API (TTMish)
<apw> heh yeah that debacle will run and run
<apw> i thought that nouveau and radeon were meant to share ... obviously not
<Keybuk> well
<Keybuk> the code is basically the same
<Keybuk> just s/nouveau/radeon/
<Keybuk> e.g. struct nouveau_bo becomes struct radeon_vo
<Keybuk> apw: I'm not sure whether Plymouth deals with tiled vs. linear
<mjg59> Well
<Keybuk> it looks like it mostly just uses memcpy() :p
<mjg59> We don't blank the screen when going to X
<mjg59> Which lets us fade from bootsplash to gdm
<mjg59> But I don't know what magic is involved there
<Keybuk> mjg59: actually, that one line of yours is FAR MORE COMPLICATED than you could ever possibly imagine
<mjg59> Keybuk: In grub? I'm shocked
<Keybuk> no, I mean in plymouth
<mjg59> Oh? Ha.
<Keybuk> keeping the frame buffer contents locked while we start X turned out to be very non-trivial
<mjg59> But clearly, if the framebuffer is linear and X is tiled, there's a lot of magic there
<cjwatson> so the problem with using vesafb is that we'd have to build it into the kernel
<Keybuk> I think the magic is at X's end ;)
<cjwatson> otherwise, no initramfs recovery
<mjg59> cjwatson: Upstream has never supported it being modular
<cjwatson> IIRC, in the past, building vesafb into the kernel was a recipe for awfulness
<cjwatson> does upstream support it being boot-time-configurable whether you use it?
<mjg59> It's always been a module just because of Debian's "Everything should be a module" crusade
<cjwatson> because having it be kernel-build-time-configurable depending on hardware clearly ain't gonna work here
<mjg59> cjwatson: Upstream will use it if screen_info has VIDEO_TYPE_VLFB
<mjg59> And won't use it otherwise
<cjwatson> ok
<mjg59> Same as efifb
<cjwatson> so, in that case, I think grub will use it if it's built-in
<cjwatson> it checks the boot parameters structure in the kernel image for that
<mjg59> ...
<cjwatson> I *think*, I'm not following all of that
<mjg59> grub needs to stop being fucking insane
<Keybuk> insmod sanity
<cjwatson> it does need to know whether the thing it tries to pass is actually going to work, surely
<mjg59> It's like KDE - the assumption seems to be that the rest of the ecosystem is hostile and must be worked around
<cjwatson> not really, grub is mostly fairly sane these days tbh
<cjwatson> certainly a fucklot easier to work with than it used to be
<mjg59> Rather than working on having a sane interface
<cjwatson> this is just a set of code paths few people use as yet, so it hasn't been polished much *shrug*
<cjwatson> but that's what we're trying to fix here
<Keybuk> well,
<Keybuk> I guess GRUB has to know what kind of things the kernel is going to expect
<Keybuk> that's probably how we're falling back to efifb right now
<Keybuk> GRUB sees that the kernel supports that, but not vesafb, so passes it in screen info
<Keybuk> if we built vesafb in as well, it'd pass vesafbishness in screen info instead
<Keybuk> (unless really using EFI)
<mjg59> Keybuk: Yeah, which is bogus
<Keybuk> of course, you could argue that GRUB should pass vesaishness regardless and penalise us for building the kernel ... incorrectly
<mjg59> Keybuk: If we ever fix efifb to only run on efi, grub suddenly tells the kernel not to reprogram text mode and everything breaks
<Keybuk> that's the kind of thing i'd do <g>
<mjg59> Of course, the fact that we have three places that program modes is insane
<mjg59> (grub, kernel setup code, native framebuffer)
<cjwatson> it's like a two-line patch to make grub always set up vesafb, so I really don't care, just need to put it all together
<apw> cking, which mini model you got?
<cking> hpmini1000 for the record
<cjwatson> http://paste.ubuntu.com/411117/ should be all that's needed to adjust grub
<cjwatson> bit more than two-line because I renamed _SIMPLE back while I was there
<Keybuk> apw: you know http://people.canonical.com/~apw/lp539730-lucid/ ?
<dmarkey> apw: i see you've applied that patch, so, does that mean these udebs are being built in daily?
<apw> Keybuk, hi 
<apw> dmarkey, it means that its applied to our tree only
<Keybuk> apw:  you know how you don't publish linux-source packages along side those?
<apw> thats not in the archive yet, and so not builting yet
<Keybuk> apw: I could sent you one of those Digital Economy Bill disconnection notices <g>
<apw> Keybuk, heh i give you the patches and everything :)
<apw> otherwise its a generic kernel and thats published already no?
<Keybuk> apw: strictly speaking, I gave you the patch :p
<apw> heh there is that too :)
<apw> i just can't face the extra 50mb of upload for something noone uses
<apw> rookery is already full up
<apw> luckily any disconnects will go to the DC :)
<apw> Keybuk, more importantly does that combination work ?
<Keybuk> I'm trying to purge xorg-edgers from the system
<Keybuk> this turns out to be HARD
<apw> Keybuk, heh thought i might hear you complaining about that
<dmarkey> apw: so i assume it has to pass some build tests, then what is the process, or is it published somewhere?
<apw> its in our git tree only at the moment, i am incrementally adding all of the outstanding bits we have at the moment on our list
<apw> i add a few ... build ... iterate
<apw> once its done then i'll boot test it locally and maybe publish that
<dmarkey> excellent, i assume its too late for beta2
<apw> probabally tommorrow am i am likely to upload the result so we have a few days to such on the fall out
<Keybuk> ok
<Keybuk> WFM
<apw> dmarkey, too late was last tuesday a week back
<apw> Keybuk, thanks
<dmarkey> i see
<apw> we freeze a week before a beta milestone
<dmarkey> ah well, i'll have it well tested before beta3/rc1
<akgraner> apw, thank you!! my computer is on at 48C now woot woot!!!
<akgraner> it's not frying me anymore!  this is a good thing
<apw> yeah mine too ... glad the same fix worked for yours
<akgraner> awesome!!
<akgraner> you all rock - when I grow up in open source I wanna be like the kernel team!! (well minus that pgraner  :-D  )
<JFo> :-/
<apw> akgraner, i am not sure i want to know what that menas :)
<JFo> bug 557611
<ubot3> Malone bug 557611 in linux "[KMS] please cherry-pick fix for Radeon RS4xx cards" [Undecided,New] https://launchpad.net/bugs/557611
<JFo> apw, have you seen that ^
<JFo> it is fresh <24hrs old
<apw> JFo, you can pretty much assume no to that question always
<JFo> :)
<apw> do i need to care about it?
<JFo> dunno
<JFo> it is in Linus' tree, but not in the branch for the next RC
<JFo> they are wanting a cherry pick (as you can see)
<JFo> just up to you
<JFo> but the issue and the patch have been confirmed
<JFo> just matters whether or not you want to cherry pick it
 * JFo is ambivalent ;-)
<JFo> brb
 * apw shakes the tree to see if he can find some reviewers for the myriad of patches on kernel-team
<apw> JFo, ok it seems to be a patch people claim to fix the issue.  i've got test kernels building
<JFo> apw, cool
<cnd> RAOF: you familiar with git send-email?
<cnd> it will make sending patches easier
<RAOF> cnd: I've found the git send-email documentation on the kernel wiki, but it doesn't seem to work properly for me.
<cnd> RAOF: what goes wrong?
<RAOF> No email gets to the list; I probably need to work out how to send it through an appropriate smtp server.
<lifeless> RAOF: do you have local mail sending setup ?
<RAOF> I've probably got postfix installed; ubuntu-dev-tools likes it.
<lifeless> I didn't say installed :P
<RAOF> That'd surely be a postfix bug, then.  There's no reason it shouldn't just work, is there?
#ubuntu-kernel 2010-04-09
<lifeless> god yes
<lifeless> but you can test
<lifeless> "echo 'foo' | mail -s test raof@example.com"
<sayao> how can i add a newer kernel repository on lucid? i need at least 2.6.33 for radeon hdmi audio to work
<drclue> All right friends romans and countrymen , I have an old piece of gear , an IDE drive caddy (as described in bug 518608)
<drclue> This caddy apparently returns a bogus inquiry value indicating a SCSI device.  At one time this device was supported I expect 
<drclue> that there was some sort of special device entry that remapped it back to ID (just a guess) and somewhere along the line this entry got retired or superseded. I could I guess hack my OS , but in my school bus out here in the middle of nowhere I have a dozen computer bricks and a few mid towers  and it would be a real time burner to make the hack and keep the hack
<ubot3> Malone bug 518608 in linux "unable to mount  ID 04ce:0002 ScanLogic Corp. SL11R-IDE IDE Bridge" [Undecided,New] https://launchpad.net/bugs/518608
<drclue> I am not in a HUGE hurry, as I did post tis bug back in February , but it would be nice to get at them old drives, as I have screen reader code for the blind I'm trying to open source (on an ancient IDE) and a few other things that I'm aiming to give away from some 30+ years of coding , but all that material is for now locked away
<drclue> Shit , all the brilliant people must live in some time zone not related to the USA (smart people would not live here if they had a choice) :)
<drclue> Dam , is it still dead in here?  I can but prey that bug 518608 can get some interest as otherwise I need to hack over a dozen machines to give them a special devices entry that used to exist in the distro
<ubot3> Malone bug 518608 in linux "unable to mount  ID 04ce:0002 ScanLogic Corp. SL11R-IDE IDE Bridge" [Undecided,New] https://launchpad.net/bugs/518608
<Laibsch> Hi, I reported bug 521967 and worked together with upstream to get a fix.  I've been successfully running this fix locally by recompiling the driver.  I'd like to know what it is I can do to make sure that patch finally hits linux-backport-modules?
<ubot3> Malone bug 521967 in linux "support for new atheros wifi chipset" [Unknown,Fix released] https://launchpad.net/bugs/521967
<jjohansen> Laibsch: send the patch to kernel-team@lists.ubuntu.com
<jjohansen> make sure to point to where it is upstream to show that it is coming from upstream
<Laibsch> thank you for your comment
<Laibsch> do you have experience with this process?
<Laibsch> I'm a bit unsure about it all since as far as I understand it, the result will not ship in the linux-image package but in the linux-backport-modules
<Laibsch> package
<Laibsch> I hope sending the patch only will be sufficient, I wouldn't be 100% sure about where to put the patch to create a debdiff
<jjohansen> Laibsch: send the patch so it can get reviewed and acked, without that it won't get in
<Laibsch> I'm not sure you understood my question
<jjohansen> then one of the devs who can commit to linux-backport-modules can pick it up
<Laibsch> there isn't just one single patch, for example, but it depends on the version, etc.
<Laibsch> I want to be sure I pick the right patch
<Laibsch> but I can't do that because I can't create a package myself
<jjohansen> ah, that gets more difficult
<Laibsch> because kernel packages in ubuntu have become somewhat opaque
<Laibsch> I generally do have no problem packaging stuff
<jjohansen> right
<Laibsch> But I don't really understand the kernel packages and the meta-packages anymore
<Laibsch> let me rephrase the question
<Laibsch> when I send in patch abc.diff, what will the devs receiving it do with it?  How can I recreate that process?
<jjohansen> ah, well review it, and then suck it into a git tree
<jjohansen> but I am haven't looked at backport modules, I know there is a little more to be done for those
<Laibsch> see, that is exactly the point
<Laibsch> it's not just "suck it into a git tree", it seems
<Laibsch> my understanding is that the linux-image package itself will not be updated past a certain point and we're well past that
<Laibsch> additions to add new drivers are then only made via linux-backport-modules
<Laibsch> so, I'd like to rehash my question
<Laibsch> Hi, I reported bug 521967 and worked together with upstream to get a fix.  I've been successfully running this fix locally by recompiling the driver.  I'd like to know what it is I can do to make sure that patch finally hits linux-backport-modules?
<ubot3> Malone bug 521967 in linux "support for new atheros wifi chipset" [Unknown,Fix released] https://launchpad.net/bugs/521967
<jjohansen> the kernel is frozen but it is still accepting bug fixes
<jjohansen> it will depend on the exactly what the changes are
<Laibsch> supposedly, http://kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2010-03/AR2427-2.6.32.y.patch are the necessary changes against 2.6.32
<Laibsch> but that's not what I've been using
<Laibsch> the changes are to add support for a so far unsupported wifi chip in a popular netbook
<jjohansen> ah, yeah that will have to go into backports I think
<jjohansen> though the patch is small enough it maybe could get sucked in, I would send it
<Laibsch> please listen
<Laibsch> I'm not even sure that patch actually applies correctly or does what it says it does
<Laibsch> so, I'd like to test this first
<Laibsch> Should make sense, no?
<jjohansen> Ah, okay.  I would build with the kernel first before ever trying to mess with backports
<Laibsch> but the kernel packages are special beasts, so I'm not sure how this should be done
<Laibsch> I'll have another look
<jjohansen> just a sec
<Laibsch> last time I tried to build a Ubuntu kernel with one additional patch, everything just blew up
<jjohansen> https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
<jjohansen> https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
<jjohansen> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<jjohansen> basically what you need to do is get the git tree
<jjohansen> KernelGitGuide covers that
<Laibsch> right now, just an innocent "pull-lp-source linux-image" already blows up
<Laibsch> OK
<Laibsch> I'm afraid that git will offer even more potential for complications
<jjohansen> right you are going to have use git
<Laibsch> I'll try the currently released package first
<jjohansen> though the amount of git needed is very minimal
<jjohansen> basically git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git 
<jjohansen> then you need to setup and install enough packages for fakeroot
<jjohansen> if you are building on lucid you don't need to actually setup a chroot environment
<jjohansen> once you have the kernel you can either use the debian build scripts (recommended) and it will spit out a deb or you can actually use straight up regular kernel build (make)
<jjohansen> for you the straight up build might be easier as you won't need to setup as much environment
<jjohansen> basically git clone the tree
<jjohansen> cd into ubuntu-lucid
<jjohansen> apply the patch
<jjohansen> copy /boot/config-2.6.32-xxx
<jjohansen> what ever your latest config is
<jjohansen> and do a make
<jjohansen> that kernel can be installed and tested without the deb
<jjohansen> it just not part of the package system
<jjohansen> other wise you will need to follow the KernelMaintanence and Starter links from the knowledge base to install the packages you need to build a kernel and get out a dpkg
<jjohansen> like you said it is a very different processes
<Laibsch> I'm quite familiar with git, that is not the issue.  But git will of course be more unstable than the released package.  Therefore I may hit problems there that I wouldn't in the released version.  That's what I meant.
<Laibsch> I'll have a look at the wiki, hoping it won't link to another 1000 or so pages to read before I get to compiling something.
<jjohansen> Laibsch: there are a lot of links but you only need a couple of them
<Laibsch> hehe
<Laibsch> that only helps if you know which ones are relevant
<Laibsch> let me have a look first
<jjohansen> maybe the gitguid and the Maintenance and MaintenanceStarter
<jjohansen> and if you want to use a chroot (optional) BuildKernelWithChroot
<Laibsch> https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
<Laibsch> that's probably what I want
<jjohansen> err no
<jjohansen> that page is a confusing mess
<jjohansen> what you do need to know is to use
<jjohansen> fakeroot debian/rules clean
<jjohansen> before building the kernel
<jjohansen> don't edit the debian.master file like it recommends for skipabi=true
<jjohansen> if you want to skip the abi checks just do
<jjohansen> skipabi=true fakeroot debian/rules binary-generic
<jjohansen> that will build the generic kernel flavour, no need to edit flavours etc.
<Laibsch> thank you for your continuted support
<Laibsch> I'm currently rebasing the git branch I had set up for this about a month ago
<Laibsch> let's see if this time around I'm more successful
<jjohansen> do you have anything on the branch you want to keep?
<jjohansen> if not git fetch ; git reset --hard origin/master
<jjohansen> will give you a clean tree set to the current head
<Laibsch> yes, thanks
<Laibsch> I'm quite familiar with git from another project
<Laibsch> git doesn't scare me at all
<Laibsch> bzr does ;-)
<jjohansen> :)
<Laibsch> I was afraid something like http://paste.debian.net/68112/ would happen
<Laibsch> Ubuntu seems to have patched main.c itself, I'd guess
<Laibsch> Unfortunately, I'm not skilled enough to rebase either of the patches
<jjohansen> what does the reject look like?
<Laibsch> I did --dry-run
<Laibsch> I don't think there is a reject file
<Laibsch> let me redo this
<Laibsch> patch is rather simple, maybe it's possible to rebase
<Laibsch> http://paste.debian.net/68113/ is the reject
<jjohansen> Laibsch: http://paste.debian.net/68114/
<jjohansen> ah crud nope, wrong tree
<jjohansen> give me a sec
<jjohansen> Laibsch: http://paste.debian.net/68116/
<Laibsch> thank you
<Laibsch> at least it applies cleanly
<Laibsch> let's try compilation now
 * apw looks agast at just how long a build took:
<apw> Finished 5 minutes ago (took 10 hours, 26 minutes, 22.0 seconds)
<Laibsch> jjohansen: I'm sorry, but again, all this doesn't work
<Laibsch> I've tried the Kernel for idiots page, the KernelMaintenance page and the KernelMaintenanceStarter page
<Laibsch> It seems there is always one step or two missing when following the instructions given there.
<Laibsch> re
<apw> amitk, are you aware of bug #542041?
<ubot3> Malone bug 542041 in linux-ti-omap "ext4 support broken on omap kernel" [Critical,Confirmed] https://launchpad.net/bugs/542041
<apw> Laibsch, jj is probabally sleeping
<Laibsch> I see
<Laibsch> Where can I find an idiot's guide to "compile your Ubuntu kernel from the Ubuntu git checkout"?
<apw> Laibsch, those are the simple guides
<Laibsch> I am tracking kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<amitk> apw: it was a one-off thing, I think. ogra have you seen this again?
<apw> it should be three or four simple steps
<Laibsch> apw: but it seems there are steps missing
<Laibsch> here is what I tried from a clean checkout
<ogra> amitk, well, i have no working image to actually install it yet, it was on a rootstock built image on an XM with your first shot XM kernel
<ogra> i'll update it once i can test installs
<amitk> ok, apw ^
<Laibsch> bash debian/scripts/misc/getabis 2.6.32 19.28
<ogra> it can easily be the fault of that XM kernel
<Laibsch> debian/rules startnewrelease
<Laibsch> the first seems to succeed (although nothing is downloaded)
<Laibsch> the second one already bombs out
<Laibsch> I tried to build the missing debian/control with "fakeroot debian/rules binary-generic", but that doesn't work, either
<Laibsch> That's my understanding of the steps to take (I tried a few other variations) but they fail
<Laibsch> https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter#Basic%20system%20setup suggests that I should just run "debuild -b" but that is equally wrong/outdated
<Laibsch> all these instructions seem to be missing the step that creates the files under debian for the following operations
<jjohansen> Laibsch: did you do fakeroot debian/rules clean
<jjohansen> first
<jjohansen> that will build up the debian dir
<Laibsch> I did that now
<mdz> apw: hi
<apw> mdz, hi
<Laibsch> I had been under the (apparently mistaken) assumption that fakeroot debian/rules binary-generic was the equivalent if one only wanted to build the generic target
<mdz> apw: I just discovered that you have a blog, and was wondering why it isn't on Planet Ubuntu yet :-)
<jjohansen> Laibsch: you should then only need to do fakeroot debian/rules binary-generic
<jjohansen> no start release or anything like that
<Laibsch> OK
<Laibsch> thanks
<apw> mdz, hrm, it isn't i am sure i asked someone to add that for me, back before i had the rights to do it
<apw> mdz, got a pointer to the instructions ... i'll go fix that
<mdz> apw: cool, thanks
<mdz> apw: if you could spread the word to your teammates to get themselves added as well, that would be great. people are missing out on some great content from the kernel team
<apw> mdz will do ... i suspect we've all thought the otehr was adding us while adding themselves or something silly
<amitk> mdz: it was a question of rights, AFAIK for most people.
<mdz> amitk: meaning some people are behind on becoming Ubuntu members?
<amitk> mdz: right..
<apw> yeah i though i added mine right at the start, while i was still doing all that stuff ... seems not
<amitk> apw: perhaps it would be easier if you subscribed the voices.canonical feed for the kernel team to planet.
<apw> amitk, might that double up some feeds if i did that
<apw> that sounds like it would need to be coordinated
<amitk> apw: a single feed subscribed to planet might make it easier in future to add other blogs to voices and make it available on planet.
<apw> amitk, perhaps we could sort that out release week
<amitk> yeah
<RAOF> apw: Good morning!  How easy is it for you to create a test kernel with a git commit cherrypicked on top?  If your kernel-team special sauce makes it easier, could I point you at bug #558657?  If you're busy, I'll prepare a test kernel myself.
<ubot3> Malone bug 558657 in linux "mouse usage causes Xorg CPU usage to spike, and mouse pointer becomes less responsive" [High,Incomplete] https://launchpad.net/bugs/558657
<apw> RAOF, pretty easy as i do it often
<RAOF> I'm not certain the referenced commit fixes the bug, but it'd be nice to check.  Thanks.
<apw> RAOF, where did that commit come from, its not an upstream linus commit
<apw> (for the patch description)
<RAOF> Ah, sorry.  nouveau/linux-2.6
<apw> RAOF, ok .. .building now, takes about an hour to get them built and uploaded, perhaps a little more
<RAOF> Thanks.  I'll be asleep by then; can you point Karl at the kernel when it's done?
<RAOF> Hm.  Interesting.  I see that radeon is flat out disabling MSI on all IGP chips now.  I seem to recall that we've recently done some radeon MSI quirking.
<Pici> poke, looks like this channel is set +q $~a  which is preventing unregistered users from talking here.  This probably isn't needed any longer as we're not getting those sort of spam attacks anymore.  
<amitk> apw: did we find out what happend to ops on this channel? (Pici's question)
<apw> amitk, nope didn't find out ... i think brad is one
<Pici> /msg chanserv access #ubuntu-kernel list     will tell you.  I didn't want to ping any of them specifically.
<apw> though whoever set that for us, and it was not one of us, really should have unset it when they took it off again gneerally
<Pici> apw: It was probably set during freenode's migration to ircd7.
<apw> no answer ... hrm
<amitk> Pici: I get nothing with that command
<apw> Pici, maybe ... noone told us we needed to undo it ... hrm
<apw> seems to work if you /query chanserv
<apw> stupid chanserv
<Pici> mode +R turned into +q $~a  during the migration.
<Pici> Anyway, /mode -q $~a   just needs to be set.
<apw> i'll try and find someone to sort it out
#ubuntu-kernel 2010-04-10
<MTecknology> Are there any issues with getting a generic (torvalds branch) kernel to work with 10.04?
<lifeless> shouldn't be - you can grab the autobuilt upstream kernels after all :)
<MTecknology> lifeless: I was just trying to figure out why when I use it it can't find my root partition. I musta screwed up. I checked lscpi -k and everything is set right there.
<MTecknology> lifeless: I was trying to mess around with 2.6.34-rc3
<MTecknology> I wish I had my generic .config I use with almost everything and it almost always works...
<MTecknology> lifeless: thanks- I just wanted to make sure there wasn't anything funky that might be messing me up
<joaopinto> hi
<joaopinto> does an hang where the sysrq does not respond usually means a kernel freeze ?
<KIAaze> yes, I think so. But I'm no kernel dev.
<KIAaze> http://www.av8n.com/computer/htm/kernel-lockup.htm
<KIAaze> I've been having such lockups when plugging in a USB stick: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/514485
<ubot3> Malone bug 514485 in linux "kernel lockup when plugging in USB stick" [Undecided,New] 
<KIAaze> switched to Gnome now and haven't been able to reproduce it yet.
<MTecknology> I'm lost. I use the exact same config as what's in the generic kernel, but i still get a kernel panic on boot and an error about not being able to find sda2 (root=/dev/sda2)
 * abogani waves
<abogani> I'm looking for sponsors: https://wiki.ubuntu.com/AlessioIgorBogani/linux-rtPPUApplication
<abogani> Thanks!
<hyperair> MTecknology: got initrd?
<MTecknology> hyperair: is that a kernel option that I'm not finding?
<abogani> MTecknology: No it is *mandatory* kernel installation step.
<MTecknology> abogani: I've been taking the easy route - make all modules_install install && update-grub2
<abogani> MTecknology: Not enough
<MTecknology> it has been for everything up until 10.04
<MTecknology> what changed?
<abogani> MTecknology: Some modules are modularized for improve speed at boot
<abogani> MTecknology: Could you see into /boot directory if you have the initrd.img-* file for you custom kernel?
<MTecknology> there isn't
<MTecknology> so I need to make the initrd.img* file
<abogani> MTecknology: I use this: mkinitramfs -o boot/initrd.img-$VERSION $VERSION
<MTecknology> Is there any way to see which modules are in the .img?
<MTecknology> abogani: Is there any way to see which modules are in the .img? Or anything that says which modules were put in there to decrease boot time?
<abogani> MTecknology: You should gunzip it and extract contents with cpio.
<hyperair> MTecknology: make-kpkg --initrd
<hyperair> i think there was something else you had to do
<hyperair> Sarvatt: ?
<abogani> hyperair: AFAIK make-kpkg isn't supported on Ubuntu.
<hyperair> it isn't?
 * hyperair has been using it all this time =\
<MTecknology> I thought initrd was just a collection of modules..
<hyperair> nah
<MTecknology> I was hoping I could just change things form =m to =y and not need to worry about initrd.img-*
<hyperair> initrd sets up things
<MTecknology> I guess not
<hyperair> including usplash in karmic
<hyperair> and udev
<abogani> hyperair is right.
<hyperair> there's a devfs option in the kernel you could use to avoid initrd though
<MTecknology> I don't see devfs in there - or does it have a different name?
<hyperair> i forgot
<hyperair> CONFIG_DEVTMPFS
<abogani> No CONFIG_BLK_DEV_INITRD
<hyperair> heh?
<hyperair> what's that?
<MTecknology> Prompt: Initial RAM filesystem and RAM disk (initramfs/initrd) support
<abogani> hyperair: Are you also in -motu?
<MTecknology> hyperair: instead of making you look it up :)
<hyperair> abogani: yes i am.
<hyperair> abogani: why?
<MTecknology> so if i disable those options it won't look for initrd?
<abogani> hyperair: I recall your suggestions about my doubts about packaging so I would want thanks to you again.
<hyperair> er i have no idea
<hyperair> O_o
 * hyperair doesn't remember..
<hyperair> but yw anyway =)
<abogani> MTecknology: Don't try it. You waste your time no one in Ubuntu have tested that way.
<MTecknology> abogani: I can try it and then somebody will have :P
<MTecknology> abogani: from looking at that - I could just cp initrd.img-2.6.32-19-generic initrd.img-2.6.34-rc3 - right?
 * hyperair facepalms
<hyperair> that won't work.
<MTecknology> hyperair: I'm sorry :( Don't hurt yourself over me
<MTecknology> hyperair: I'm just a novice noob that likes mucking with things that have no business being mucked with
<hyperair> heh
<hyperair> well just use the initrd
<hyperair> what are you trying to achieve by dropping it?
<MTecknology> nothing, I was just wondering if I could avoid making it by copying it
<hyperair> well, you know how kernel modules can't be used in another kernel?
<hyperair> initrds contain kernel modules, naturally they can't be used in another kernel
<hyperair> if you have no modules at all, then maybe it can be copied
<MTecknology> oh
<hyperair> but anyway initrd is basically a temporary root
<hyperair> that bootstraps everything and then moves to the real root
<MTecknology> what benefits are there in that?
<MTecknology> hyperair: I'm not trying to say it shouldn't be there - I'm jsut curious what it offers
<hyperair> MTecknology: well, for stuff like lvm and cryptostuff, the kernel cannot boot directly using those as some setup needs to be done in userspace.
<hyperair> MTecknology: also, i'm sure you know that you can't fsck a filesystem while it's mounted
<MTecknology> ya
<MTecknology> ok, that makes sense
<MTecknology> hyperair: so you could have your entire drive on one lvm volume and boot from it wtih initrd?
<hyperair> MTecknology: right. but you need /boot in ext4/ext3 or something supported by grub, for example
<hyperair> as long as the initrd can be supplied
<MTecknology> hyperair: cool
<MTecknology> hyperair: heh - I tried without initrd and the only issue with that /dev/mapper/cryptswap1 and lvm volumes won't mount, nee to run mount /home, mount /misc, etc. manually and there's no errors
<hyperair> heh, see? =p
<hyperair> MTecknology: besides, i think ubuntu's boot process is engineered around the fact that you have an initrd, so it might not work properly if you don't.
<MTecknology> hyperair: I wouldn't even use lvm if I didn't have to deal with having windows on the drive
<MTecknology> hyperair: nifty stuff
<joaopinto> sysrq not responding indicates a kernel hang ?
#ubuntu-kernel 2010-04-11
<Sarvatt> Keybuk: btw I saw you mention downgrading from xorg-edgers the other day, theres a package in there called ppa-purge that does it all for you since its such a pain in the butt
<owen1> https://lists.ubuntu.com/archives/kernel-team/2010-April/009826.html  i posted this issue with the touchpad, but no one replied.
<owen1> here are the bug reports: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/512192  
<ubot3> Malone bug 512192 in linux "Can't configure Elan tech touchpad on Dell Inspiron 11z, Asus K7I0C and maybe also Dell Mini 10 (not V), ASUS k40in, Asus U81A and ASUS UL80-VT." [Undecided,Confirmed] 
<owen1> and https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/123775?comments=all
<ubot3> Malone bug 123775 in linux "Elantech touchpad is incorrectly recogonised as a "ImPS/2 Logitech Wheel Mouse"" [Medium,In progress] 
<owen1> any ideas when will this issue be solved? i just upgraded to 10.4 and it's still a problem.
<owen1> is there a place i should post it as an issue with 10.4?
<frenkel> hi
<frenkel> there is a new release of wacom.ko that adds support for 5 bamboo tablets and some others
<frenkel> but its not in lucid I see
<frenkel> is it possible to get it in there before release? I know we're past freeze
<frenkel> but i think a lot of people will use these tablets, because they are cheap
<junmin> hello, is there any ubuntu kernel config file repository? ( i am not in a ubuntu box, but i need to check some ubuntu's kernel configuration ) thanks. 
 * abogani waves
<abogani> I'm looking for sponsors: https://wiki.ubuntu.com/AlessioIgorBogani/linux-rtPPUApplication
<abogani> Thanks!
<owen1> abogani: i read your page. good job man. what is a sponsor in that context?
<abogani> owen1: Someone could verify that my work was done well (attaching a comments at bottom of that page).
<owen1> abogani: oh. by looking at your code?
#ubuntu-kernel 2011-04-04
<fairuz> morning people
<fairuz> What does SW acknowledge means?
<fairuz> (to clear an interrupt)
<ohsix> its a bit the software handling the irq can set to tell the hw that it knows about the last one
<ohsix> usually to let the hw know its ok to discard something or move on
<fairuz> ohsix: so normally writing 1 to the acknowledge register will do the job right?
<ohsix> i dunno your circumstances, if that's what does it then yes
<fairuz> Actually I cleared the interrupt but it stills reenter the handler 
<fairuz> so obviously there is something else that i'm not clearing :D
<KNRO> can anyone take a look at this? http://ubuntuforums.org/showthread.php?t=650521
<KNRO> is it possible to use pbuilder to build packages for kernel modules?
<dns53> how do i get from a busybox console to a booting system?
<tgardner> ogasawara, looks like you're still on the hot seat for another week.
<ogasawara> tgardner: indeed, just saw the calendar
<smb> tgardner, ogasawara I had been even thinking that it might be one week after that
<tgardner> ogasawara, at least the beer in Budapest is cheap. approx 1.8USD per pint :)
 * tgardner --> ESXi install
 * ogasawara back in 20min
<mahmoh> does anyone know how to override the bios for kvm support with a kernel option?  kvm=enable?
<tgardner> mahmoh, you generally have to enable virtualization in the BIOS
<mahmoh> tgardner: I did but it's still reporting it's disabled in the bios, and I updated to the latest bios with the same results
<mahmoh> ah, I might have to disable trusted execution on my dell hardware it appears ...
<mjg59> mahmoh: If it's reporting that it's disabled by the BIOS then the BIOS has (a) not enabled support and (b) has locked the MSR
<mjg59> And yes, if trusted execution is enabled and you want to use kvm then you may need to boot in a trusted setup
<Krunch> you may also try to poke at the MSR manually http://timetobleed.com/enabling-bios-options-on-a-live-server-with-no-rebooting/
<mahmoh> there we go ... how much more confusing can they make it?
<mahmoh> mjg59: I'm guessing there's no kernel override then ;)  disabling the trusted execution worked (whew), so no problems anymore
<mahmoh> except with Dell'
<mahmoh> s bios that is
<mahmoh> mjg59: thx
<cking_> why doesn't that surprise me
<mahmoh> Krunch: now that looks like fun!
<mahmoh> cking_: ;)
<mahmoh> cking_: I was just thinking about you
<Krunch> mahmoh: don't try this at home (well, maybe better at home than on your production server)
<mahmoh> oops, I just took out EC2
<mahmoh> thx all
 * bjf -> dr. appt.
<ogasawara> pgraner: I see we don't have a specific kernel track for UDS, so I'm assuming we'll just throw our blueprints/sessions under the Foundations track?
 * tgardner --> back to the server room
<jjohansen> manjo`: ping
<manjo`> jjohansen, pong
<manjo`> sorry was out for lunch
<jjohansen> manjo`: so I installed 64bit natty on the x120e
<manjo`> jjohansen, and ..
<jjohansen> manjo`: I'm not sure where you want to go with the bug from hear,
<manjo`> so that means you are not seeing the bug ? 
<jjohansen> manjo`: basically the rtl driver needs to be removed during the install
<jjohansen> manjo`: no I saw it plenty
<jjohansen> manjo`: I updated Bug #744419
<ubot2> Launchpad bug 744419 in linux "[NATTY] [ Kernel oops installing natty @tty_write()" [Undecided,New] https://launchpad.net/bugs/744419
<manjo`> hmm... not sure how we can fix that for natty... probably have udev rules that removes it ? 
<manjo`> udev rules based on DMI info ? 
<tgardner-afk> manjo`, blacklist in /etc/modprobe.d ?
<manjo`> tgardner-afk, right or that ... 
<jjohansen> manjo`: could black list it for the install disk, I'm not sure you want to black list for after, it seems to be working (for some value of working)
 * manjo` writing to mmany udev rules these days 
<manjo`> jjohansen, also can you install cheese and see if you can record video... the camera is not recording video and showing a blank screen on that one 
<manjo`> jjohansen, what would the rtl driver cause this bug ? 
<jjohansen> manjo`: hrmm give me a sec, I have cheese installed in both 32 and 64 bit but I never tried grabbing video
<jjohansen> manjo`: I haven't chased it far enough to figure that out
<jjohansen> manjo`: it took me a lot just to get the stupid thing installed, that was my limit for the weekend
<manjo`> jjohansen, yeah natty is very busted on that x120e
<manjo`> jjohansen, also if you switch your bios to legacy only and don't look for UEFI you will have better results 
<jjohansen> manjo`: hrmm, I don't know about that, I haven't found it any worse than natty on any of my other machines, all of which have problems
<jjohansen> manjo`: also I just did a bios update on it this morning so we will see if that helps anything
<jjohansen> manjo`: yep cheese crashes trying to record video
<manjo`> jjohansen, it does the same on maverick too.. thanks for the confirmation 
<manjo`> jjohansen, this is with the latest bios update as well right ? 
<jjohansen> manjo`: yep
<jjohansen> manjo`: so cheese gets stuck in a polling loop on fd 3
<jjohansen> manjo`: which is returning EAGAIN
<manjo`> you think its a cheese bug ?
<jjohansen> manjo`: well there is definitely a cheese bug there, it shouldn't let a device returning EGAIN send it into an infinite polling loop but the device isn't responding to the request
<jjohansen> so at least 2 bugs
<kamal> ls
<kamal> tgardner: should there be an oneiric dchroot on tangerine?  (is an oneiric dchroot even possible at this point?)   I'm building the ubuntu-oneiric kernel in a natty chroot on tangerine now, fwiw.
<tgardner> kamal, not yet
 * kamal expects the natty chroot to work for ubuntu-oneiric anyway, so np
<kamal> confirmed: ubuntu-oneiric kernel builds okay in a natty dchroot
<ogasawara> kamal:  I've pushed the latest oneiric bits to zinc.  it should build successfully now on i386 and amd64.  about to boot test and then build test on armel.
<kamal> ogasawara: ok, thanks -- I'm about to try booting my amd64 oneiric kernel too
 * ogasawara crosses fingers for kamal
 * kamal readies the fire extinguisher ;-)
<sconklin> severe weather due here in the next 90 minutes - if I drop out that's why
 * bjf -> lunch
<kamal> ogasawara: fyi, my oneiric amd64 kernel seems to work fine (Dell Studio Core-i5 laptop with Intel graphics)
<ogasawara> kamal: cool, thanks for the feedback.  working here for me too.
 * tgardner --> server room (one more time)
<kamal> mjg59: got a moment to discuss intel_backlight in 2.6.39?
<mjg59> kamal: Sure
<kamal> hi Matthew ...
<kamal> it looks like most of your backlight work has landed in 2.6.39...  I do see "backlight: add backlight type" and the nv_backlight and radeon_backlight bits, but the intel_backlight patch itself ("i915: Add native backlight control") appears to be missing.
<kamal> do we know why that's the case?
<mjg59> We do not
<mjg59> I suspect it conflicted and Andrew dropped it
<mjg59> Let me try that again, then
<kamal> ah
<kamal> ok, I'll keep an eye on the repo (and intel-gfx?) for your retry...  and will try cramming your previous version in myself to test in the meantime.
<kamal> mjg59: I'm glad I asked!  ;-)  thanks for the info (and the patches, of course!)
<sforshee> mjg59, if you've got a minute, I was wondering about the fate of this patch: https://lkml.org/lkml/2011/1/19/331
<sforshee> the conversation seemed to die without a resolution
<mjg59> sforshee: I think I need to rewrite it from scratch
<mjg59> sforshee: I'm also worried about it breaking other systems
<mjg59> sforshee: But it's on my list - I was thinking about it today
<mjg59> It needs some infrastructural changes from ACPI to get the EC handle
<sforshee> mjg59, yeah, the driver does seem pretty ugly
<sforshee> that patch does get some systems working though
<mjg59> I was going to just rewrite toshiba_acpi completely at some stage
<mjg59> I guess I should do that on the plane tomorrow
<sforshee> mjg59, looking forward to seeing the results :-)
<sforshee> thanks for the update
<sconklin> power is intermittent here, will probably drop out here in a bit
<mjg59> sforshee: If you'd like to test http://fpaste.org/R8HI/ that would be great
<mjg59> sforshee: Wait, sorry, not you
<mjg59> kamal: If you'd like to test http://fpaste.org/R8HI/ that would be great
<mjg59> kamal: I've build-tested it, but nothing more
<kamal> mjg59: absolutely, I'll give it a spin right away
 * ogasawara back on later
<kamal> mjg59: wonderful!  that patch works just fine on top of ubuntu-oneiric (2.6.39-rc1-ish).
<kamal> mjg59: feel freel to add my Tested-by: Kamal Mostafa <kamal@canonical.com>
<mjg59> kamal: Excellent
<mjg59> manjo`: Does your X120e have the rtl wifi?
<mjg59> manjo`: If so, are you seeing stalls when it tries to request_firmware() on resume?
<manjo`> mjg59, looking ... 
<manjo`> mjg59, yes it has rtl8192ce ... and I don't see stalls
<mjg59> manjo`: Ok. Using rtlwifi, or using the realtek driver?
<manjo`> it resumes ok (I am on 10.10) 2.6.35-28 
<mjg59> Ah, the realtek one. Ok.
<mjg59> So rtlwifi is just buggy. I'll work on that.
<manjo`> yep I am not on rtlwifi
<manjo`> I am using the realtek driver 
<jjohansen> mjg59: yes the rtlwifi driver is very buggy, and yes I see stalls coming out of suspend sometimes, have also had coming out of suspend lock up
<mjg59> jjohansen: Yeah, I've just added it to the pm-utils unload/load blacklist for now
<jjohansen> mjg59: the rtl8192ce driver is also responsible for the 64 bit install failures
<mjg59> jjohansen: Ok, not something we've seen
<jjohansen> mjg59: hrmm, Bug #744419
<ubot2> Launchpad bug 744419 in linux "[NATTY] [ Kernel oops installing natty @tty_write()" [Undecided,New] https://launchpad.net/bugs/744419
<jjohansen> I had a lot of fun with that one over the weekend
<jjohansen> rebooting
#ubuntu-kernel 2011-04-05
<jjohansen1> JFo: ping
<JFo> jjohansen1, pong
<kristian-aalborg> hi all
<kristian-aalborg> I got uvesafb running, it sped up everything... but it seems a bit less stable now?
<kristian-aalborg> hi jjohansen1 
<Shred00> is there anything in particular that upstart needs in the kernel it runs with?
<Shred00> i built an upstream (kernel.org) kernel with the lucid .config but /sbin/init starts but doesn't do anything
<Shred00> initctl {list,version} return
<Shred00> initctl: Did not receive a reply.  Possible causes include: the remove application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
<fairuz> morning good people
<buhl> Does anyone know why the beta1 is sooo much heavier on my system? - It's using three times more RAM idling...
<fairuz> Hi, All processes executed from a bash script has the same affinity as the bash script right?
<ricotz> does somebody know if this commit is proposed for 2.6.38.x yet? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=243b422af9ea9af4ead07a8ad54c90d4f9b6081a
<diwic> ricotz, since it's cc:ed stable it's very likely to be in 2.6.38 sooner or later
<diwic> ricotz, if you want it sooner, write an email to the kernel-team@lists.ubuntu.com ML with a subject line starting with "UBUNTU: (pre-stable) Natty"
<diwic> ricotz, if you want it sooner in Ubuntu, i e
<ricotz> diwic, ok
<diwic> ....and explain why it's important
<ricotz> as the commit says - currently using aio is broken in natty
<bullgard4> '~$ uname -a; Linux T42 2.6.38-7-generic #39-Ubuntu SMP Fri Mar 25 19:38:02 UTC 2011 i686 i686 i386 GNU/Linux'. I have had at least 3 messages "panic occurred, switching back to text console". I could do nothing but restart the computer. I did not find this reflected in dmesg or syslog. How can I contrubute with a meaningful error report?
<Krunch> bullgard4: there should be a full panic message on the console at the time of the problem, that would be helpful
<Krunch> bullgard4: you can have it sent to another box over the network with something like netconsole
<bullgard4> What do you mean by "on the console"? I had available at that time only one virtual console. As I already wrote, I could not call any other program, not even "netconsole". 
<Krunch> bullgard4: netconsole is something you set up before the problem happens
<Krunch> bullgard4: the console as in /dev/console, by default it's the first virtual console but you can change that for the serial console for example
<bullgard4> Right. But I did not know beforehand that this would happen. Thus I did not set up netconsole.
<Krunch> bullgard4: yeah so there is nothing we can do about your past panic but you can set up your system to collect relevant data next time it happens
<bullgard4> Krunch: How should I set up this computer now in order to prepare it for collecting relevant data if a panic occurs next time?
<Krunch> i don't know much about ubuntu so i can't be very specific but look into netconsole and kdump
<bullgard4> hm
<bullgard4> To thorw two words into the room is a rather meager help.
<bullgard4> To throw two words into the room is a rather meager help.
<Krunch> https://wiki.ubuntu.com/Kernel/BugTriage/CollectingInformation
<Krunch> feel free to ignore me if you think i am not helpful
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
 * manjo pokes amitk 
<amitk> sup manjo? I got your email
<manjo> :) ok
<kees> Shred00: run initctl as root
<Shred00> kees: i am
<hggdh> jjohansen: I can run a standard KVM session on the maverick kernel
<hggdh> (in this case, a natty image install)
<JFo> hggdh, I think jjohansen is away sick today
<hggdh> JFo: ah, thanks
<JFo> my pleasure :)
 * smb wonders whether the above was a statement or question...
 * JFo adds a period.
<smb> JFo, Actually I meant the statement before. :)
<JFo> oh smb, you meant hggdh's :)
<JFo> heh
<smb> yup
<JFo> hggdh, were you asking if you could?
<hggdh> smb: this is relating to bug 746751
<ubot2> Launchpad bug 746751 in linux "kernel: [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 30)" [Critical,In progress] https://launchpad.net/bugs/746751
<hggdh> JFo, smb: no, I was stating that manually running KVM on a natty install running a Maverick kernel seems to work
<JFo> ah
<smb> hggdh, Not sure I *want* to know what is in there. Ah ok
<hggdh> this was a test jj asked me to run
<tgardner> ogasawara, I created a master-next branch in oneiric so I can start dribbling crap in your pristine kernel.
<ogasawara> tgardner: cool
<hggdh> smb: I fully understand ;-)
<ogasawara> tgardner: I'm still hammering out armel build failures
<tgardner> ogasawara, which is why I wanted to stay out of your way
<ogasawara> tgardner: anything else you want to shove into natty?  I'm gonna prep an upload for after our meeting.
<tgardner> ogasawara, nah, I cleaned out the list so I think its OK.
<bjf> ##
<bjf> ## Kernel team meeting in one hour
<bjf> ##
<vish> hi, I'm trying to test upstream kernel for Bug #733392 , but only able to find 2.6.35-rc1-lucid and cant see any 2.6.35-rc1-maverick, is that something I need to consider, or is 2.6.35-rc1-lucid OK too?
<ubot2> Launchpad bug 733392 in linux "[RV515] Kernel .35 onwards, Random X freezes while scrolling" [Medium,New] https://launchpad.net/bugs/733392
<ogra_> JFo, linux-ti-omap ?? are you meaning to say omap4 there ?
 * ogra_ doesnt want to interrupt the meeting, we dont have linux-ti-omap anymore
<JFo> linux-ti-omap is the package name I am looking at. Has that changed to omap4 package name?
<ogra_> in natty we dont have a linux-ti-omap source package anymore
<ogra_> we have a linux-ti-omap4 package since maverick 
<ogra_> and still have it
<ogra_> (just to make sure you actually look at the used packages :) )
<ogra_> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4 is what we care for in natty (for omap4), for omap we plainly use the linux package 
<JFo> tgardner, any thoughts on bug 721449 ?
<JFo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/721449
<JFo> no more ubottu eh?
<tgardner> JFo, I think there are a lot of folks whinging about 802.11n
<JFo> yeah, I suspect so, just wanted to fire something back on his list e-mail
<tgardner> JFo, lemme wrap up the work I'm doing on bug #719446 and I'll take a look
<JFo> ok, thank you sir
<JFo> <-lunch
 * tgardner --> lunch
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 (Kernel Freeze - April 14) || Ubuntu Kernel Team Meeting - April-12 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<tgardner> bjf, how about an ack for 'UBUNTU: SAUCE: add support for Lenovo tablet ID (0xE6)' so I can get it off the list?
<bjf> tgardner, looking
<bjf> tgardner, done
 * bjf[afk] -> lunch
<bryceh> JFo, heya
<bryceh> JFo, bug #686388 could really use some kernel team lovin' about now.  This seems to be at the root of a collection of gpu lockups the kernel is experiencing, and upstream has a couple patches that require testing before they're going to put them in.
<bryceh> JFo, I probably sound like  a broken record.  "This is the most important gpu lockup ever, and... patches!"
<JFo> heh
<JFo> no sweat
<bryceh> anyway, if you could bump the above bug up in the priority a bit, it could potentially help eliminate a bunch of the gpu lockup bugs
<JFo> ok, let me see what I can do
<bryceh> JFo, I think having a test kernel built of intel-drm-staging would be the right next action for the bug; then we can have users test that and give upstream feedback
<bryceh> (yes, upstream has yet another drm testing branch...)
<JFo> heh
<bryceh> http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=shortlog;h=refs/heads/drm-intel-staging
<tgardner> bryceh, would a PPA test kernel work for you?
<bryceh> tgardner, yep
<bryceh> tgardner, just something for reporters to load and test
<tgardner> bryceh, those 2 patches against natty, right?
<bryceh> tgardner, yes
<sforshee> tgardner, bryceh, I think there was some discussion on lkml about one of those patches possibly causing a regression, a third patch might also be needed
<sforshee> let me see if I can dig up the thread
<bryceh> sforshee, I gather one of the two patches fixes a regression that the other patch opens, so the two go together.  Thanks for doublechecking the thread.
<sforshee> bryceh, I found the thread, problem is reported here: http://thread.gmane.org/gmane.linux.kernel/1117365/focus=3491
<sforshee> but it looks like it was fixed by an update to the same patch, so it's probably okay
<bryceh> sforshee, ok cool
<JFo> stepping outside for a bit of a break. bbiab
<bryceh> yeah Intel has been a bit hit or miss with their patches this cycle.
 * jjohansen -> lunch
<bryceh> heh @ Linus' post in that thread
<tgardner> bryceh, I dribbled some comments in bug #686388 . I'm about EOD and have to run.
<bryceh> tgardner, great thanks
<tgardner> bryceh, I'll check later this evening to make sure its built OK
 * ogasawara back on later
#ubuntu-kernel 2011-04-06
<fairuz> Morning 
<diwic> hi! what's the magic git command to figure if a commit is in the master-next branch of ubuntu-natty (and thus will be in the Natty final kernel), or if I have to ask for it explicitly on the kernel-team ML?
<smb> diwic, You know you just can look at that branch? git log origin/master-next
<smb> (from a natty tree that is)
<diwic> smb, right, then I can pipe that to grep. Didn't think of that, thanks.
<smb> diwic, there would even be a --grep="bla" for git log
<RAOF> I believe there's even a âgit containsâ somewhere... let me se.
<smb> RAOF, You probably mean git describe --contains <sha1>
<RAOF> smb: I do indeed.
<smb> The downside there is that you need a sha1 on natty maybe still be able to be rebased makes it hard to know that
<smb> Actually master-next is never linear
<smoser> hey. i just opened bug 752352
<smoser> is this expected behavior ?
<smoser> it was not listed in the changelog.
<tim> hi. is it possible to build the linux-tools package with make-kpkg?
<smoser> smb, you know anything about bug 752352 ?
<smb>  smoser Could be a security feature... I remember kees was asking about some file permissions recently
<smoser> its not listed in changelog.
<smoser> and the files are publically available on launchpad or apt repository
<smoser> so just plain hiding their content isn't all that useful.
<smoser> ie, if i can't read it in /boot i can download the deb myself 
<smb> Well, I am the wrong person to argue about that. ;) But it makes it harder for automated attacks I guess.
<smb> See "UBUNTU: [Config] packaging: adjust perms on vmlinuz as well"
<smb> smoser, Is that a real problem. At least for starting instances one needs to be root anyway...
<smoser> not a problem for starting anything
<smoser> but caused my builds to break
<smoser> they assume that they can read contents of /boot 
<smoser> to copy the kernels out
<smoser> they can very easily be root to do that, the scripts just be root as little as they have to
<smb> smoser, Doh! 
<smb> smoser, The reasoning from the patch is that exploits could get the location of kernel addresses from there. I agree that they can have locations prepared per kernel versions...
<smoser> so that *is* intended behavior ?
<smb> smoser, It was a change that was requested by the security team, yes
<smoser> and, by design not listed in the changelog
<smoser> :-(
<smb> It should be in the changelog
<smb> It is at least referenced there in the file
<smb> linux (2.6.38-8.40) natty; ...
<smb> ...
<smb> * [Config] packaging: adjust perms on vmlinuz as well
<smb> I am ready to admit that this is not that obvious
<smoser> ah. sorry. i looked in the specific binary's config
<smoser> oh, and it is there also...  i just looked at the top entry
<smoser> sorry for the spam
<smb> no worries. There is a lot of text in the changelog at the end of a day
<smoser> thank you smb 
<arand> It seems that the latest -8 kernel makes update-grub not create the subvol=@ entry (for btrfs), are there any changes which could be related to that?
<aakshay> i have made small "hello" type driver.. now  i would like to start with desigining drivers for ubuntu. please suggest me how should i start?
<aakshay> sconklin, i have read the book you suggested me and tried the basic examples. now please suggest me to start development with community. :)
<fairuz> aakshay: which book? LDD?
<aakshay> fairuz, yes..
<aakshay> fairuz, it gave me the basic idea only.. how to go further ?... :)
<fairuz> aakshay: for me the book is complete :D So what did you managed to do until now
<fairuz> external module? 
<aakshay> fairuz, i  designed the basic initialization module.  
<fairuz> and what did you initialized?
<arand> Is there any http acces to the git repos of ubuntu by the way?
<aakshay> fairuz,  a simple function... :p
<aakshay> which displayed some info like " entering the module" 
<aakshay> fairuz, means very basic.. :D
<fairuz> aakshay: So have you tried to do some communication between user space and kernel space?
<aakshay> fairuz, nah.. not yet :(
<fairuz> aakshay: so i think you better try that first
<aakshay> should i go for that now?
<aakshay> ok :)
<fairuz> aakshay: http://www.freesoftwaremagazine.com/articles/drivers_linux?page=0%2C3
<fairuz> a good tutorial 
<fairuz> aakshay: http://www.freesoftwaremagazine.com/articles/drivers_linux?page=0%2C0 this is the first page
<aakshay> okiez.. i will do according to this tutorial
<aakshay> :)
<aakshay> okiez..
<aakshay> but to run these modules, do i need my own build kernel?.. ;p
<fairuz> this tutorial is for our of tree modules
<fairuz> it means you just need the kernel source to build it
<fairuz> no need to recompile your kernel 
<fairuz> *out
<fairuz> *out of tree
<aakshay> fairuz, ok but please tell me something. i am designing all these codes in the kernel directory of my normaly ubuntu i am using
<aakshay> i have not built any separate kernel
<fairuz> no problem with that
<aakshay> ok..
<fairuz> you compile a module for a specific kernel
<aakshay> fairuz, thankyou so much...
<fairuz> if you are compiling using your currrent kernel, then it will run only on the current kernel
<aakshay> okiez... but what specific kernel means here?  :-o
<fairuz> the kernel that you are using :D
<fairuz> type uname -r in your terminal to see which kernel you are using
<aakshay> fairuz, okiez... :p
<aakshay> fairuz, thanks a lot.. can you please tell me how long will it take to complete with this tutorial? :p
<fairuz> aakshay: 30 minutes ?
<fairuz> or less
<aakshay> ohhhh!!!! .... :D
<aakshay> fairuz, so let me try this to complete this in 30 minutes
<aakshay> :P
<fairuz> aakshay: ok, but you need more time to understand... dont just copy paste the code
<aakshay> fairuz, yes..  thanks a lot... :)
<fairuz> do page 1 to page 7 of the tutorial
<fairuz> aakshay: np
<aakshay> fairuz, okiez.. let me start noe itself
<aakshay> :P
<aakshay> *now
<arand> It seems that the latest -8 kernel makes update-grub not create the subvol=@ entry (for btrfs), are there any changes which could be related to that? Also, is there any git http access so one could clone the repos and have a look? (I'm badly firewalled).
<tgardner> arand, http://kernel.ubuntu.com/git
<arand> Hmm, I don't see any http links there, and using git clone http://kernel.ubuntu.com/ubuntu/ubuntu-natty.git fails...
<fairuz> arand: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
<arand> fairuz: I am firewalled and can't use the git:// protocol (unless I go through tor, at 60K/s ...).
<ogasawara> diwic: bug 732445, looks like you mention the patch has landed upstream in the takashi's sound-2.6 tree, did you want it applied as pre-stable to natty?
<diwic> ogasawara, let me see
<ogasawara> diwic: if so, care to just send a quick email to the list
<diwic> ogasawara, ok, I want it in
<diwic> ogasawara, I think it's already in
<diwic> ogasawara, it's just that since Takashi chose a different solution he took away my buglink in the process
<ogasawara> diwic: ok cool
<diwic> ogasawara, if git log origin/master-next --grep 584c0c4c359 says it's in, it's in, right?
<ogasawara> diwic: yep, it's in
<ogasawara> git describe --contains 24449f05b663f1984ee6ecdba5a0d2ff2a1e0462
<ogasawara> Ubuntu-2.6.38-8.40~661
 * ogasawara back in 20
<aakshay__> fairuz, am back. :)
<aakshay__> understood the coe
<aakshay__> *code
<fairuz> aakshay__: make it worked then?
<aakshay__> but while running , i am getting the error :(
<aakshay__> "error: expected declaration specifiers or â...â before âsizt_tâ
<aakshay__> "
<aakshay__> fairuz, :(
<fairuz> aakshay__: try to debug it :D it should give you the line number 
<aakshay__> fairuz, its taking ssize_t  as  'sizt_t' 
<aakshay__> yes its line 17 and 18
<fairuz> aakshay__: check your code. You do copy paste from the site or write it on your own?
<aakshay__> i took the same code but wrote myself.. 
<aakshay__> fairuz, so that i will learn :p
<fairuz> whats on line 16 to 18?
<aakshay__> please wait.. let me copy the code on pastebin.com
<aakshay__> :p
<aakshay__> fairuz, its "http://paste.ubuntu.com/590256/"
<fairuz> aakshay__: As i said before, take a good look at the code and you will find it
<fairuz> you miss spell something on line 17 and 18
<aakshay__> oops!! .. let me check.. ;p
<aakshay__> hehe.. :D.. such a silly mistake.. n took lot of time to get corrected.. :p.. thanks.. 
<aakshay__> let me compile again.. :)
<aakshay__> fairuz, yipii.. done!!
<aakshay__> :)
<fairuz> aakshay__: When it says error at line 17, don't look at line 40..  =)
<aakshay__> fairuz, :p... i looked at line 17 only.. :D... i was only lookin at ssize_t , not on required variable.. :D
<aakshay__> fairuz, its done.. :).. and i understood it well.. please tell me what i can do further?
<fairuz> aakshay__: you tried to insmod and rmmod your module? it worked?
<aakshay__> yes
<aakshay__> i removed the modules
<aakshay__> an checked them using the lsmod command
<aakshay__> :)
<aakshay__> *and
<fairuz> aakshay__: you tried to communicate with your module from user space?
<aakshay__> fairuz, dont know
<aakshay__> :p
<fairuz> aakshay__: so you dont completed the tutorial -.-"
<aakshay__> i entered the data. it was from the user space then its copied to kernel space to be accessed from /dev/memory
<aakshay__> :p
<aakshay__> fairuz,  is this was not the concept?.. :)
<aakshay__> fairuz, oh yes.. you are right.. the data in the tutorial is sent directly using the "echo" command 
<aakshay__> there is no use of functions "copy_from_user" and so
<aakshay__> :P
<aakshay__> fairuz, i have not done the "parallel port" part...
<aakshay__> fairuz, how can we make use of the functions "copy_from_user" and others ?
<tgardner> bryceh_, no joy on bug #686388
<aakshay__> fairuz, thanks for help.. :).. i have to leave. good bye.. . :)
<tgardner> smb, do you remember how to skip failing mounts at boot up? mountall is hanging 'cause /dev/md0p1 hasn't been enabled when /etc/fstab is read.
<smb> tgardner, typing s
<smb> though it might work only with splash
<tgardner> smb, k, I'll go try that.
<tgardner> smb, huh, it even tells you what to do, but you have to be able to see the console.
<smb> tgardner, Sort of makes sense as you are usually in front of it to type the letter
<smb> tgardner, This is where I start to like boards with integrated ipmi module. The only thing I have not yet got running is to get the java based graphical console over a tunnel when I am not in my home network. :)
<tgardner> smb, I suppose this emerald has that, but I'm just too lazy to get it working. I'll only have it for a limited time.
<smb> tgardner, Too true. It was relative simple here as it got its own lan port. The only annoying part is that it only runs with sun-java installed (he graphical console)
<JFo> <-lunch and a few errands
<JFo> bbiab
<bjf> ogasawara, these are probably already on your radar: http://people.canonical.com/~kernel/reports/regressions-proposed-report.html
<ogasawara> bjf: thanks, I'll browse through em to just make sure there's no kittens dieing
<tgardner> ogasawara, no pink kittens this time around? how about green?
<tgardner> or is that dyeing ?
<tgardner> I can never remember
<ogasawara> heh, I can never remember either
<tgardner> ogasawara, ooh! I fixed bug #747364. do I get brownie points ? I used the "Won't Fix" club.
<ogasawara> tgardner: heh, I'll buy ya a beer in budapest
<tgardner> ogasawara, big spender. it'll only cost you $1.80
<ogasawara> tgardner: diapers are expensive these days, it's all I can afford :)
<tgardner> ogasawara, go cloth
 * smb tries not to think too much about the term brownie points now
 * tgardner thinks smb is a sick puppie
<bjf> ogasawara, i don't know if "fixing a bug" by marking it "won't fix" constitutes a beer, but maybe a 1.80 beer
<tgardner> ogasawara, how are your oneiric armel build issues coming?
<ogasawara> tgardner: should be fixed, final build is just finishing up
<ogasawara> tgardner: I pushed the bits to the repo
<tgardner> ogasawara, cool
<ogasawara> tgardner: am about to rebase to 2.6.39-rc2
<tgardner> ogasawara, which will introduce a whole new raft of issues :)
<tgardner> ogasawara, don't forget to pick up master-next commits
<ogasawara> tgardner: ack
<kristian-aalborg> jjohansen: ping
<jjohansen> kristian-aalborg: pong
<kristian-aalborg> I've been thinking.... the install I tested my custum kernels on is kind of a mess since I have experimented a lot
<jjohansen> yeah that happens
<kristian-aalborg> fun times indeed... but it may be a factor in my kernels messing up
<kristian-aalborg> or anyway, that thought crossed my mind
<jjohansen> yes that is possible
<JFo> oh hey jjohansen, you pinged me the other night but I just missed you when I responded. Do you still need me?
<jjohansen> generally we try to build inside a chroot to keep the environment consistent
<jjohansen> JFo: hrmm, I can't remember why I pinged you, so you are in the clear :)
<JFo> oh good :-)
<jjohansen> JFo: hrmm maybe it was for a bug nomination
<JFo> could be
<JFo> if you remember it I am happy to fix it
<JFo> or rather approve it
<JFo> jjohansen, was it to add a linux(Ubuntu) task to this one? https://bugs.launchpad.net/linux/+bug/744419
<jjohansen> JFo: actually it was Bug #748656
 * JFo looks
<JFo> jjohansen, done
<jjohansen> JFo: so Bug #744419 is not kernel related, we traced it down to eucalyptus
<jjohansen> or at least that is the current working theory
<JFo> ah hah
<jjohansen> kvm runs fine, and this is failing when we put in the maverick kernel
<JFo> well, I added a kernel task just in case
<JFo> if it isn't needed it is an easy thing to close
<JFo> just don't want it to disappear
<jjohansen> so for the moment lets mark the linux task invalid, and we can change it back if needed
<JFo> ok
<jjohansen> JFo: arg no wait
 * jjohansen was looking at the wrong bug
<JFo> heh
<jjohansen> JFo: that one is linux, its the rtl8192ce driver, traced that one down on the weekend
<JFo> ah, I just read your comment
<jjohansen> it bugs 746751, that isn't the kernel
<jjohansen> we were chasing that on friday and the start of this week
 * jjohansen is getting confused by having too many bug tabs open in his browser
<JFo> I know the feeling :-(
<jjohansen> ogasawara: just a heads up on this one too, bugs 746751 appears not to be kernel related at this time serge is chasing the eucalyptus path
<ogasawara> jjohansen: cool, thanks
<jjohansen> ogasawara: did smb update you on bug 634487
<ogasawara> jjohansen: he mentioned it the other day and I've been following his comments to the bug
<jjohansen> ogasawara: okay, great
<bryceh_> tgardner, yeah, although upstream had alluded to known issues with macbooks.  I wish Intel were a large enough company to employ more than one engineer in their QA department.
<tgardner> bryceh_, thats the only feedback so far. is the macbook a regression?
<bryceh_> tgardner, upstreams exact words were "Those two patches have been reported by one user to have fixed the issue for
<bryceh_> him, but I need a few more testers since they seem to foul up a MacBook (but
<bryceh_> then there are more than one issue at play with MacBooks...)"
<bryceh_> so, I would interpret it to mean that yes it is a regression on macbooks
<tgardner> bryceh_, gah, what a mess.
<bryceh_> maybe if Intel can make some profits they can buy that guy a macbook to test
<bryceh_> tgardner, anyway I'm thinking maybe we wait until there's something actually posted to drm-next.  These one off patches seem sketchy too often.
<tgardner> bryceh_, ack
<kees> smoser: yeah, while the /boot perms obviously don't stop someone from just going and getting the deb themself, it does stop some "simple" attacks that will be dumbfounded by the lack of kernel symbols.
<kees> smoser: it's crude and effective for a certain set of attacks, and does nothing to stop others. I felt it was worth it; sorry about the breakage it caused you!
<smoser> i really don't think it woudl stop an attack
 * tgardner --> lunch
<smoser> i really can't imagine someone saying "oh bother, i can't read the kernel symbols for this kernel, i guess i wont' insert a root exploit today"
<smoser> "i'd have to do a 'wget' in order to do it, and thats really just too much work"
<kristian-aalborg> I'm going to install a backup kernel, I need linux-headers-xxx, linux-image-xxx... and anything more?
 * jjohansen -> lunch
 * ogasawara back on later
<kees> JFo: got a kernel regression for you... 731878
#ubuntu-kernel 2011-04-07
<JFo> thanks kees, you're like the uncle who always give fruitcake as a present. :-P
<JFo> ogasawara, are you still around?
<JFo> might want to have a look at that: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/731878
<JFo> looks nasty to me
<kees> JFo: haha :)
<jjohansen> back on later
<fairuz> morning
<smb> TeTeT, It would be good if we can get more info about the host system (what distro/release/kernel version) and possible special setup into the many interrupts/xen bug (if this has not mysteriously resolved itself...)
<smb> Oh and good morning by the way. :-P
<TeTeT> smb: it hasn't. I'll get you the info asap. Morning ;)
<smb> TeTeT, To bad... :) Oh and usually (at least in the CenOS installs I use) there are example configurations (including hvm) in /etc/xen. Those may help to find out which values could be changed and what the defaults are supposed to be.
<smb> cking, \o
<cking> smb, o/
<TeTeT> smb: customer attached the sosreport from the RHEL host, hope that has all the needed info
<smb> TeTeT, I will hope and see. Have you asked them about the mac addr and prossible acpi activation?
<TeTeT> smb: he saw your comment and said it should be all fine, but I will dig into that again
<smb> TeTeT, Ok thanks. The mac address was just to be sure. But acpi is definitely not good. If there is a dmesg of the dom0 in the data added I'll see whether this is there the same or not.
<Daviey> smb, Is someone looking at bug 731878 ?
<Daviey> ah, i see kees mentioned it to JFo last night.
<smb> Daviey, my crystal orb looks a bit hazy at the moment.
<smb> Daviey, I saw the mailing list thread but did not look myself. And as the bot seems to be MIA again it is not always clear from the scrollback what was discussed
<Daviey> smb, sorry for being vague.. unity crashed and i missed your response
<Daviey> smb, the scrollback looked like kees just raised it to JFo's attention
<Daviey> Another question.. Would someone on the kernel team mind commenting on the patch attached to bug 722185 please? :)
<Daviey> Also, bug 707003 (sorry for flooding you chaps)
<aakshay> while running driver (module), the kernel messages are not passing to /var/log/messages. please help
<ogra_> diwic, poke
<diwic> ogra_, peek
<ogra_> diwic, do you have an opinion about bug 746023 ? i see you discussed it on the pulse ML
<ogra_> hmm, no bugbot ?
<ogra_> https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023
<ogra_> indeed we would love to have that patchset in before release, but i dont know the code enough to judge the impact on other platforms than UCM based ones
<diwic> ogra_, in terms of stability and risk, I prefer not applying them...
<ogra_> do you think they could impact anything beyond UCM ?
<ogra_> (the only thing i see there is the udev changes)
<aakshay> fairuz, where the kernel messages are stored? 
<diwic> ogra_, so if we decide to apply them - have we tested them? How can we ensure stability of these patches?
<ogra_> diwic, do you think they would affect anything outside of UCM 
<ogra_> they have been tested by TI as i understand and only omap4 makes use of UCM atm
<ogra_> my worry is the impact on non UCM stuff that i cant really judge
<ogra_> (tested by TI indeed means tested on omap4 only)
<diwic> ogra_, as I understand it udev-detect would load module-alsa-jack-detect as well
<ogra_> right
<diwic> ogra_, so bring me up a little, what's the minimum we can apply this to if we have to?
<diwic> ogra_, I mean, can we ifdef the udev changes to the ARM image e g
<ogra_> ah, yeah, thats would be an option ... 
<ogra_> we could ifdef the world indeed ;)
<diwic> ogra_, w
<diwic> ogra_, how many images do we have and do we need this on all of them?
<ogra_> we wouldnt do that image based but arch based 
<ogra_> (since ifdef will only work at build time)
<ogra_> we currently sopport two arm subarches (omap and omap4) but linaro uses our packages for their images too and they have a lot more subarches
<fairuz> aakshay: dmesg | tail
<fairuz> or tail /var/log/messages
<aakshay> fairuz, thanks.. but can i take your minute please.. 
<fairuz> aakshay: I have a meeting soon, but just ask
<aakshay> fairuz, in the code i wrote yesterday, the module_init and exit are being called simultaneously.
<fairuz> aakshay: module_init is called when you do insmod
<aakshay> fairuz, the printk message is "<1>Inserting memory moduleRemoving the memory module
<aakshay> "
<ogra_> diwic, would you mind commenting on the bug ? i have to present it to the release team and possibly also ask TI for changes (before beta2)
<fairuz> while module_exit is called when you do rmmod
<diwic> ogra_, hmm
<aakshay> fairuz, yes but when i do insmod, this output is given "<1>Inserting memory moduleRemoving the memory module
<aakshay> "
<diwic> ogra_, what would you like me to write? 
<fairuz> aakshay: Check your code 
<ogra_> heh, your opinion on the possible impact if we apply them
<aakshay> fairuz, ok.. i am checking it. will back to you.. :p
<aakshay> thanks
<aakshay> :)
<ogra_> diwic, luke just asks for adding the right FFe's, i would like some statements about the code and possible impact
<diwic> ogra_, I talked to him this morning and he too was concerned about the size (as in the broader meaning of size) of the patches 
<diwic> ogra_, and I told him to ping you about it :-)
<ogra_> he didnt say that oj the bug nor in the ping he left for me on IRC
<ogra_> *on
<diwic> ogra_, do you have hardware you can test on?
<ogra_> "Could you please action bug 746023? A lot of these patches introduce new functionality, and IMO need an FFE. Thanks."
<ogra_> trhats what i had 
<ogra_> yes, the arm team as well as the linaro team have panda boatds
<ogra_> *boards
<ogra_> testing on the target platform isnt an issue (and i also tend to belive it works okayish if TI tells me they tested, my main concern is teh impact on non TI HW) 
<diwic> ogra_, so can you be specific about what we need to bring in? Comment #4 is contradictory to comment #5.
<ogra_> well TI wants all of them indeed, i dont know if we can get away with less
 * diwic would love to have an Ubuntu that works a little better than okayish :-/
<ogra_> okayish on the panda wrt sound would be much more than we released on maverick 
<ogra_> (due to the same issue btw, the TI alsa patches came to late)
<ogra_> in maverick there is no sound at all on omap4 in the release image and only partial fixes in maverick-updates
<ogra_> so having it working "okayish" on omap4 while not breaking the rest of the world is acceptable for me atm
<ogra_> the rest of the world bit is what i'm concerned about
<ogra_> and what i cant judge as a non asla guy
<ogra_> *alsa
<diwic> ogra_, the patches in the tarball are similar but not identical to those posted on the ML - that's why I ask which one is the one to apply
<ogra_> ah
<diwic> ogra_, they are overlapping
<ogra_> well, we would take the tarball ones 
<ogra_> i thought they are the same given alejandros comment
<smb> Daviey, Patch in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722185 looks ok imo but seems to need to get upstreamed properly.
<smb> Daviey, https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/707003 ppisati looks like being on that one
<Daviey> smb, thanks!
<Daviey> smb, would you mind commenting on the former please?
<smb> Daviey, about to do
<Daviey> I assumed you have pre-canned responses for situations like this :)
<Daviey> thanks
<smb> Daviey, Nah, that would be far to effective
<Daviey> smb, lol
<TeTeT> if I want to package a binary module, how do I best get it into the kernel's dependency tree - simply call depmod -a from postinst, or is there a better way?
<smb> TeTeT, The best way would be to have at least some parts that can be public, and then to make a dkms package. Well actually the best way would be not to have a binary only module to package...
<TeTeT> smb: problem is the vendor only distributes a binary module. Right now it is copied into /lib/modules. I at least want to package it, this motivates my question on how to best add it to the module dependencies. I completely agree with your assessment though
<smb> TeTeT, For depmod you probably want to use one of its options to limit it to the running kernel (or the one into which /lib/module path you install). That from a postinst should be ok. Good luck with the rabbit (abi) chase, though. But I guess you are aware of that joy
<TeTeT> smb: yeah, the customer won't install every Lucid kernel for sure
<smb> TeTeT, Its more a courtesy thing. depmod -a updates all the dependencies for all currently installed kernels. But your package would only add to one version, so one does not want to unnecessarily update stuff that has not changed.
<smb> TeTeT, Actually reading the man page again, I am wrong
<smb> TeTeT, So depmod -a is actually ok
<smb> if you install for the current kernel, otherwise depmod -a <version>
<TeTeT> smb: so it would be depmod -a <version>, as during install time most likely the kernel is not correct
<smb> TeTeT, Yes, sounds like the safer bet
<smb> tgardner, ogasawara I am likely #99 but just as a note that this is going round as a Natty regression https://bugs.launchpad.net/ubuntu/+source/linux/+bug/731878. Following the latest thread reference it does not seem to be resolved yet upstream.
<tgardner> smb, what do you mean you are #99 ?
<smb> tgardner, Assuming I am not the first one to tell you but #99 (iow people are already chasing you)
<smb> ITs just a random number that came to my mind
<tgardner> smb, oh, you are the 99'th person to hassle me about this. I get it.
<smb> tgardner, Yeah, sorry I guess my humor does not translate that well atm. Guess I need apw back to give me more training. :)
<tgardner> smb, we all miss him :)
<smb> After nearly two weeks in Scottland we'll have to find out whether *we* still understand him. :-P
<ogasawara> smb: yep thanks, it's top of my list to dig into this morning
<smb> ogasawara, Cool. :) As far as I understood the mail thread someone recently added to the bug upstreams answer seems to be a sort of: "WTF, what are you doing?"
<tgardner> ogasawara, re: bug #731878. perhaps we should produce a test kernel with c191a836a908d1dd6b40c503741f91b914de3348 reverted to make sure that is the root of the issue. the upstream discussion seems to have ground to a halt.
<ogasawara> tgardner: we must be on the same page, that's exactly what I'm doin right now
<tgardner> ogasawara, cool
<tgardner> ogasawara, you should assign someone the bug in order to let the world at large know we are paying attention.
<ogasawara> tgardner: I'll assign myself to it
<JFo> ogasawara, did you see my ping about bug 731878?
<ogasawara> JFo: yep, already posted a comment to the bug
<JFo> or whomever can look for that matter
<JFo> ok cool
<JFo> should have refreshed it :)
<JFo> and now that I read back a bit I see smb was discussing it... le sigh
<smb> JFo, So many things going on while one does not look.
<JFo> smb, true
<JFo> to many in some cases :)
<JFo> rather too*
<JFo> would someone mind taking a look at bug 712625?
<smb> Indeed. Sometimes I am scared to log back into irc. Too much info crushing down
<JFo> Dustin assigned it to me, but I missed it somehow
<JFo> smb, a description of my daily life
 * kirkland waves at JFo 
<JFo> that is why there are times when I just don't look at it
<JFo> hi kirkland :) sorry about neglecting this bug
<ogasawara> kirkland: do you by chance know between which two specific natty kernel versions the regression appeared?
<tseliot> smb: hi, do you know who I can ping about wifi driver issues?
<smb> tseliot, I usually try tgardner ... ;-P
<tseliot> smb: thanks
<ogasawara> kirkland: and I assume this still remains even with the latest 2.6.38-8.41 kernel?
<kirkland> ogasawara: let me check, i've been afraid to try for weeks and weeks
<kirkland> ogasawara: \o/  doesn't appear to still be valid
<kirkland> ogasawara: i'll mark fix-released
<ogasawara> kirkland: sweet
<bjf> ogasawara, good job, looks like you deserve a beer :-)
<ogasawara> woot!
<JFo> ogasawara, kirkland sorry I let that one sit for so long :-/ I should have seen it.
<ogasawara> tgardner: it's like you're reading my mind today
<tgardner> ogasawara, hmm, thats a bit disturbing, isn't it :)
<ogasawara> hehe
<tgardner> I assume you refer to reverting that socket patch?
<ogasawara> tgardner: yep
<ogasawara> tgardner: you wrote exactly what I was planning to do
<tgardner> ogasawara, good. at least I'm not out in left field.
<ogasawara> I might was well revert it in master-next for now, just so we don't forget
<tgardner> yep
<tgardner> bjf, what kind of BW do you get from zinc over your FIOS connection? I've tried 2 different providers, the best I'm getting on a clone is 200 KiB/s
<bjf> tgardner, how are you testing ?
<bjf> tgardner, i'll do the same here so you can compare
<tgardner> bjf, just doing a repo fetch
<bjf> tgardner 650728.93 bytes/sec   that was an rsync
<tgardner> bjf, that seems reasonable.
<tgardner> bjf, I'm using a GNet server with a 35 Mbps connection and am getting 100KB/s. Bresnan shows similar. Its starting to harsh my buzz.
<bjf> tgardner, heh, i can understand that
<JFo> <-lunch
<Sarvatt> tgardner: 1.36M/s on a server in NY with a 100mbps connection
<tgardner> Sarvatt, must be some common segment between Bresnan and 360Net thats causing the slowdown.
 * tgardner --> lunch
 * jjohansen1 -> lunch
<ogasawara> tgardner: bug 745947, are you planning to change CONFIG_FB_VESA back to =y for the server flavour? Or just release note it?  or wait and discuss with apw when he gets back?
<tgardner> ogasawara, cjwatson argues that its a debian-installer bug, so I put the ball back in his court
<ogasawara> tgardner: ok cool, then I'll leave it be
<tgardner> ogasawara, https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/745947/comments/29
<ogasawara> bah, foiled by not refreshing the bug
<tgardner> bjf, whats left before karmic  2.6.31-23.75 gets promoted to -updates ?
<bjf> tgardner, let me look
<bjf> tgardner, there is nothing from the cert./qa team about testing
<tgardner> bjf, are they gonna test either karmic or dapper?
<bjf> tgardner, yes, they have committed to testing all supported series
<bjf> tgardner, and they have done so the past couple of cycles
<tgardner> bjf, ok. I was just reviewing all the LP bugs I have open. many of them will close when these kernels get promoted.
<JFo> ogasawara, it is good to know that I wasn't the only one affected by that today :)
<ogasawara> JFo: just prepping for the release meeting tomorrow, how are your bug handling work items coming?
<JFo> not bad, but not as fast as I'd hoped
<ogasawara> JFo: still think you'll be able to close them out by release?
<JFo> should do, I don't see why not. The only thing that keeps hanging me is being distracted by crazy bugs, but that is my fault
#ubuntu-kernel 2011-04-08
<Sarvatt_> vanhoof: ping
<fairuz> morning
<tgardner> ogasawara, 'just say no' email sent
<ogasawara> tgardner: ack
<ogasawara> sforshee: bug 508516, care if I just mark that Won't Fix?
<sforshee> ogasawara: d'oh, I meant to do that bug guess I forgot. Please do.
<ogasawara> sforshee: cool, thanks.  just cleaning up some bugs on the release meeting agenda.
 * ogasawara back in 20
<jan_d> Hello! I am new to this channel... yesterday I installed & upgraded kubuntu-natty, and I am now running into this bug in a most severe way. As I was under the impression that this but had been fixed in 2.6.38 final, I am now wondering how it still happens in natty (with 2.6.38-8). this is the bug: http://www.mentby.com/Group/linux-kernel/mass-udp-flow-reboot-linux-with-realtek-rtl-8169-gigabit.html 
<jan_d> has anybody else noticed this?
<jjohansen> jan_d: the rrl8192 driver is not very stable, I have been suffering through it this week
<jjohansen> jan_d: I am not sure I would attribute the errors I am seeing to this specific bug
<jan_d> ok
<jan_d> I can undestand that
<jan_d> that bug report however details my problems, which is why I cited it
<jan_d> in 10.10 I had no such problem, ever
<jan_d> so Now I was wondering if I should go back to Maverick + Kubuntu-PPA, instead of testing Natty
<jan_d> which would be a pitty, but if there is no immediate (or short-term) solution, then I will have no choice
<jan_d> luckily, it's not a production machine
<jjohansen> jan_d: well that is going to depend on if you can live with the bug until it gets fixed
<jan_d> normal internet usage does not trigger a crash, but if I want to do image processing or mathematical processing, it's going to crash every 5min
<jjohansen> jan_d: if you need stability and you aren't getting it with natty and were with maverick then the choice seems obvious
<jan_d> yep
<jan_d> ok, so I take it that there is no already-existant solution
<jan_d> Would it make sense to file a bug with (k)ubuntu? Seems like upstream...
<jjohansen> jan_d: can you boot a maverick livecd/usbkey and double check which driver is being used
<jan_d> ic
<jan_d> you thing I should maybe try 8168 instead?
<jjohansen> jan_d: not atm, I haven't followed through on the bugs to closely yet, but I plan to, as I am experiencing them
<jjohansen> jan_d: hrmm maybe, and yes you should file a bug
<jan_d> ok, will do when I get home tonight. Thank you for now.
<fairuz> hey jjohansen: 
<jjohansen> hi fairuz
<fairuz> jjohansen: doing good?
<jjohansen> fairuz: heh, lets just say its been an interesting week.
<fairuz> jjohansen: good to hear that
<ogasawara> cooloney: bug 608312, looks like you had some patches to fix this, did they ever get pushed upstream?
<cooloney> ogasawara: oh, yeah, i posted that patch to upstream
<ogasawara> cooloney: did it get picked up?
<cooloney> ogasawara: i don't think so, not much review about that
<ogasawara> cooloney: so I assume we would need it for Natty?
<ogasawara> cooloney: if so, I'll leave it in your hands to get it tested and submitted to the kernel-team mailing list.
<cooloney> ogasawara: yeah, i will take care of that. 
<ogasawara> cooloney: awesome, thanks.
<tgardner> bjf, do you know if there a repo for the tests that Q/Q is running?
<tgardner> Q/A*
<bjf> tgardner, depends on which tests you are talking about, i know there is for the security tests, for the others I don't know 
<bjf> tgardner, i'm talking to them right now, you want me to ask?
<tgardner> bjf, I guess the security tests will do for now
<bjf> tgardner, one sec
<tgardner> bjf, no rush
<bjf> tgardner, not sure if that's all the regression tests, but i think the security is in there       bzr branch lp:qa-regression-testing
<tgardner> bjf, tahnks
 * tgardner has fat fingers this morning. must be all the snow....
<bjf> sconklin, ^ in case you needed that as well
<sconklin> bjf: thanks
<tgardner> launchpad timeouts suck
<kees> bjf: uhm, what the heck is going on? why did QA test 2.6.35-22.33 instead of 2.6.35-28.50 ?
<bjf> looking
<bjf> kees, nice catch, i missed that, i just asked, they tested the right kernel, https://wiki.ubuntu.com/QATeam/KernelSRU-maverick-2.6.35-28.50
<kees> bjf: well, I think it's still a kvm bug
<bjf> kees, you were not able to reproduce it, right ?
<kees> bjf: correct. also, in those new results, there are no aslr failures. they tested the wrong kernel before, afaict.
<kees> hggdh: https://wiki.ubuntu.com/QATeam/KernelSRU-maverick-2.6.35-28.50 shows no aslr failures.
<hggdh> kees: no, it does not. I tried multiple times, last one succeeded
<bjf> kees, i might buy that there is a kvm bug lurking in there, but looking at the commits that went into that release, it's difficult to see that it was caused by one of them
<bjf> kees, unless it was your commit :-)
<kees> bjf: I mean a kvm _host_ bug -- i.e. not the kernel.
<kees> bjf: we've seen evidence of all kinds of weird rare memory corruption when running under kvm.
<kees> bjf: it just happens that the aslr collision test is at about the same level of brutality to uncover such host bugs
<kees> bjf: here's an example of such a kvm host bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/694029
<bjf> kees, yes, sounds like something someone should look into
<kees> hggdh: how could that have been a typo, the kernel that was tested actually reported itself as -22.
 * tgardner --> lunch
<kees> hggdh: http://reports.qa.ubuntu.com/reports/kernel-sru/home/ubuntu/sru-kernel-test/maverick-2.6.35-22.33-server/kvm-amd64/qrt-kernel-aslr.txt
<hggdh> kees: a typo running the test, no upgrades were installed
<kees> bjf: anyway, I don't see any of these issues as needing to hold back the 2.6.35-28.50 kernel
<kees> hggdh: oooooh, okay
<kees> hggdh: well, in that regard, the test worked. :) -22 had that flaw. :)
<hggdh> kees: heh. At least something worked :-)
<kees> :)
<hggdh> BTW, updated kernel SRU tests tarball created & published
 * bjf -> lunch
<vanhoof> herton: heya
<vanhoof> herton: you still around
<herton> vanhoof: hi, yes
<vanhoof> herton: quick q on a bug you chimed in on
<vanhoof> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720949
<vanhoof> herton: just noticed this: https://bugzilla.kernel.org/show_bug.cgi?id=27402#c7
<vanhoof> herton: wondering if we should do the same in natty
<herton> vanhoof: I think is a sensible thing to do, as ath3k doesn't seems to handle it ok, and by reports should be working with btusb before
<vanhoof> herton: its awesome it made its way through -stable :D
<vanhoof> ogasawara: sounds like you're already putting together the final natty upload?
<ogasawara> vanhoof: I am, fixing up some build failures and then will get it packaged
<ogasawara> vanhoof: is there a last minute patch we need?
<vanhoof> its not end of the world, but does impact a number of machines destined for 11.04 cert
<vanhoof> I think it could be SRU'd
<slangasek> ogasawara: could you pull in the patch from bug #750585 as part of this upload?  Just got FFe approved today
<vanhoof> I just got a list of natty cert failures, oh about 3 hours ago ;)
<slangasek> it would be a big help for multiarch to have that in the archive
<ogasawara> vanhoof: if you can get a patch to the list in the next hour or so, I can probably squeeze it in.  otherwise we'll target for SRU.
<ogasawara> slangasek: care to send it to the kernel-team@lists.ubuntu.com just so we can get proper Ack's on it?  I'll be sure to pull it in before I upload.
<slangasek> ogasawara: hmm, strange process.. ok :)
<vanhoof> herton: do you know where gustavo might have submitted the revert? ... I'm not seeing it in linux-next
<herton> hmm no idea, let me check here
<herton> vanhoof: found it, it is on his tree at git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
<herton> http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=patch;h=8390679da56a903b916a5d86423fcc872814d99a
<vanhoof> herton: think its reasonable to pull in for natty since it breaks things?
<ogasawara> tgardner: I'm gonna disable rts_pstor staging driver on armel and powerpc, it's throwing me multiple build errors
<herton> vanhoof: yes, it's a small change for only these devices, and regression
<vanhoof> herton: mind sending it to k-t?  If you're tied up I can torture manjo :)
<herton> np, I can send
<vanhoof> herton: awesome, thank you
 * vanhoof loves the final day fire drill :)
<tgardner> ogasawara, ack
<tgardner> ogasawara, I'm handling the multi-arch patch
<ogasawara> tgardner: ack
<ogasawara> tgardner: I just pushed the rts_pstor config change to master-next
<tgardner> ogasawara, ok, pushed the multi-arch patch. I'll get a test build going on my emerald, but it looks pretty simple.
<ogasawara> tgardner: ack
<vanhoof> ogasawara: herton sent it along to k-t
<vanhoof> herton: i appreciate it :)
 * vanhoof makes mental beer note
<ogasawara> vanhoof: thanks, will review it
<tgardner> herton, is this from upstream, or from a maintainers repo?
<herton> tgardner: from one of bluetooth maintainers tree
<herton>  git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
<herton> I forgot to add that in the patch I sent to kernel-team ML
<tgardner> herton, vanhoof: so this patch effectively drops support for that part, right?
<vanhoof> tgardner: it drops support for that part, and fixes others as a result
<tgardner> vanhoof, so you'd consider it a regression fix?
<vanhoof> tgardner: from my point of view definately
<vanhoof> tgardner: we have machines needing 11.04 cert that are broken because of this
<tgardner> vanhoof, alright.
<vanhoof> and ive not seen any actual real work come through wanting that part
<vanhoof> tgardner: if its sketchy to you, we can wait for SRU
<vanhoof> but it seemed like a quick win to me
<vanhoof> tgardner: i got a laundry list of bugs mid-day today against 11.04 cert :\
<tgardner> vanhoof, right on time :)
<vanhoof> tgardner: yeah seriously :)
<tgardner> herton, do you think we'll need this oneiric, or will upstream solve the issue?
<herton> tgardner: I expect this to be pulled in for 2.6.39, so will end up automatically on oneiric I think
<tgardner> herton, ok, then I won't pick the patch for oneiric
<tgardner> vanhoof, applied and pushed
<vanhoof> tgardner: herton: thanks guys!
<vanhoof> i hear the beer is cheap in budapest :)
<tgardner> vanhoof, $1.80 per pint as near as I can tell
 * ogasawara pulls and kicks off new test builds
<vanhoof> tgardner: i think i'm up to at least a 100 bucks w/ you then ;)
<tgardner> vanhoof, of course the kernel team drinks for free with all the favours we've racked up.
<vanhoof> tgardner: i wonder if there is miller lite in budapest ;)
<tgardner> blech!
<elmo> tgardner: so, FWIW, LP are really working hard to eliminate the timeouts, you might want to ping lifeless next week, if you can tell him which pages are timing out, I suspect he'll fix them for you
<tgardner> elmo, its seemed transient
<tgardner> e.g., it happened on several pages within a few minute period, then all started working again.
<bjf> elmo, lots of timeouts for a number of us today
<bjf> elmo, not specific to individual pages, also on qastaging 
<elmo> did you guys happen to get OOPS numbers or remember any of the pages?
<elmo> (the particular pages + a rough time would probably allow them to find the OOPSes)
<tgardner> can't remember for sure, but I think it was the generic 'try again later'
<elmo> huh, ok
<tgardner> elmo, it was especially annoying because LP has been so well behaved lately. whatever you're doing seems to be the right thing despite this momentary outage.
<elmo> tgardner: oh, it's not me, all credit to lifeless and the LP team - but good to hear
<bjf> tgardner, https://bugs.launchpad.net/launchpad/+bugs?field.tag=timeout
<tgardner> bjf, whoa, lotta critical bugs there
<bjf> tgardner, looks like they are taking timeouts seriously 
<bryceh_> tgardner, yeah LP team policy is that all timeout bugs are handled as criticals
<bryceh_> tgardner, I find pretty much whenever I get one of those "try again later" pages, I copy the OOPS id into a bug report and send it in, and they take care of the rest
<bryceh_> tgardner, part of the grand scheme as I gather is that they're slowly ratcheting down the timeout duration in order to improve performance
<tgardner> bryceh_, I guess they are making progress. its the first timeout in awhile.
<kristian-aalborg> evening
<bryceh_> tgardner, yeah things are a lot better
<tgardner> ogasawara, EOD, I'm off to trudge through the snow. 
<ogasawara> tgardner: cool.  I'm about to bounce for a bit too, the suns actually out today.
<kristian-aalborg> I just ran strace and mpc update (because the latter halts"... I got "erestartnohand" (in caps), which seems to be a kernel error?!
<ogasawara> tgardner: not much else to do for the kernel.  just waiting for some builds to finish, then will upload over the weekend sometime.
<tgardner> ogasawara, we've about 5 inches since this morning. gonna make getting to the brewery a long walk
<tgardner> ogasawara, k, I'll keep watch as well.
<bryceh_> ogasawara, how's the little one?  Is he giving you better sleep finally?
<ogasawara> bryceh_: he's doing great!  well, not so great on the sleeping part though :)
<bryceh_> :-)
<ogasawara> bryceh_: still wakes up about every 2hrs
<bryceh_> yeah, something I'm not looking forward to for #2...
<hallyn> smb`: hi, re bug 747090,
<hallyn> smb`: wondering if i should be going to the kvm mailing list, or if you'd like to do it (or someone else from your team)
<hallyn> nm, mailing :)
#ubuntu-kernel 2011-04-09
<vanhoof> ogasawara: you still around?
<vanhoof> ogasawara: nothing kernel related :)
<bj0> i'm trying to make serio0 use the atkbd driver using /sys/bus/serio/devices/serio0/drvctl, but it's giving me "No such device"
<bj0> can i set it this way?
<bj0> found it
<ogasawara> vanhoof: lemme know if you need anything
<bullgard4>  /var/log.boot.log reports: "Starting mDNS/DNS-SD daemon" but System Monitor does not show such a daemon. How come?
<JanC> bullgard4: your question is off-topic here, but the name of the mDNS/DNS-SD daemon is avahi-daemon
<bullgard4> You say: "your question is off-topic here," Where is it on-topic?
<bullgard4> JanC: You say: "your question is off-topic here," Where is it on-topic?
<JanC> bullgard4: it would be on-topic in #ubuntu for example
<bullgard4> hm
<JanC> or on the forums
<JanC> or maybe in your locoteam channel/forum
<njin> hello, loking at Dmesg, does [ 17.240015]  mean 17 seconds.... or what, and if not how can i measure times?
<penguin42> there seem to be quite a few separate bugs that are netdev watchdog timeouts are they actually related bugs?
<njin> hello, to upgrade from Hardy is exact acconseil to use update-manager -d ?
<njin> hello, what can I suggest in bug 754192 ?
<njin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/754192
#ubuntu-kernel 2011-04-10
<Saamm> hello
<Saamm> there is this bug giving me problems Bug #756482
<Saamm> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/756482
#ubuntu-kernel 2012-04-02
 * ppisati -> reboot
<vaneet> Hi everyone.
<vaneet> I know a bit of linux and i am not an expert.
<vaneet> I have installed 11.10 ubuntu from CD
<vaneet> many times during the day, it crashes 
<vaneet> i read yesterday that desktop GUI issues are normally kernel issues.
<vaneet> can someone help please.
<vaneet> thank you in advance
<vaneet> anyone there
<vaneet> hi
<didrocks> hey apw! I normally get a kernel panic every 2 days (my disk is really slow and I'm under the impression that I trigger it when I do a lot of ios). This morning, I got 3 of them :( what should I provide to help your team debugging?
<apw> didrocks, do you get a stack trace from the crash, thats the most useful part
<didrocks> apw: never got a crash in /var/crash/ related to the kernel from what I can see
<apw> didrocks, so whats the symptoms when it 'crashes'
<didrocks> apw: the disk is spinning a lot due to a lot of io, then screen freezes and I see both caps lock and scroll lock flashing which is what tells there is a kernel panic, isn't it?
<apw> didrocks, yes usually flashing those is its last ditch attempt to tell you ... from their its worth doing the sysrq sync  as if syslog got the crash it may not hit the disk until you sync
<didrocks> apw: ok, will do the sysrq sync at my next (hopefully not too soon though ;)) crash
<didrocks> apw: will keep you posted
<apw> didrocks, which kernel is this running, assuming precise latest?  so do get a bug filed so we can track which versions it definatly occurs in
<apw> didrocks, i don't think i've seen any hard crashers this cycle on any of my kit thankfully, they are very hard to locate
<didrocks> apw: yeah, I got that for 2/3 weeks already, always updated to latest (and updated to latest again this morning)
<didrocks> apw: yeah, I really think I trigger it a lot as my HD is near EOL
<didrocks> so all my laptop is very slow due to this, so easier for me to trigger weird cases
<apw> didrocks, i asume its not old enough to have a serial port
<apw> why oh why did they take those off
<didrocks> apw: no, I would have played with minicom otherwise ;)
<apw> didrocks, sometimes a netconsole will get the crash, sometimes
<didrocks> interesting, not used to do that though ;) for most of my stack, it's either on a terminal or a tty if it's the window manager. Quite easier ;)
<apw> didrocks, fingers crossed the sync will get it
<didrocks> apw: I hope so as well. Will keep you in touch, thanks!
<apw> and let us know the bug number so we can get it to jo
<apw> joe
 * ppisati -> back in a bit
 * ppisati -> lunch
<cking> ditto
<ppisati> *burp*
<cking> satisfying lunch then ppisati?
<ppisati> well, good enough, thanks for asking :)
<smb> ppisati, Wanna mint? :)
<ppisati> smb: the meaning of life? :)
<smb`> ppisati, yep
<smb`> :)
<apw> b smb
<smb> b happy
<Teduardo> Anyone have any clue when 12.04 will be happily thrust upon us?
<smb> When it is released...? ;) https://wiki.ubuntu.com/
<Kano> hi, please add http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c9651e70ad0aa499814817cbf3cc1d0b806ed3a1
<Kano> if not already done
<ppisati> apw: https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReviewBeta2omap4 is it periodically autogenerated or you intervene manually?
<apw> ppisati, totally manual, need it updating ?
<ppisati> apw: not yet
<apw> Kano, that is already applied and uploaded, iirc we were in the loop in getting that fix identified
<Kano> fine
<Kano> i bisected it again ;)
<Kano> then i saw that there was already a fix
 * ogasawara back in 20
<ppisati> apw: when there's a dash it means it's not available there, right?
<apw> ppisati, yes right
<tgardner> cking, do you have a regression test for bug #885744 ? It needs Oneiric verification.
<ubot2> Launchpad bug 885744 in ecryptfs "pathconf() does not reflect reality" [High,In progress] https://launchpad.net/bugs/885744
<ogasawara> tgardner: I'm gonna rebase q to 3.4-rc1, just wanted to make sure you're not already doing so
<cking> tgardner, yep, I'm in the process of verifying these
<tgardner> ogasawara, nope, still grinding through my email backlog. thats what I get for taking the weekend off.
<tgardner> cking, thanks
<tgardner> cking, which reminds me, I should compare 2.6.32.y against our ecryptfs patches and send the deltas to stable
<jwi> apw: otoh, the aspm fix hasn't been applied to oneiric-proposed yet...
 * ppisati kicks another build and disappears for a bit in the mean tim
<ppisati> e
<tgardner> jwi, just emailed it for review at kernel-team@lists.ubuntu.com
<apw> tgardner, do we not need a second fix from cking on that one ^ ?
<tgardner> apw, nah, taht was just an override thingy. it wouldn't hurt, but its also not related
<cking> yep
 * apw looks confused
 * apw will let you duke it out on the mail thread
<tgardner> apw, you're takling about Oneiric "ASPM: Fix pcie devices with non-pcie children", right ?
<apw> tgardner, indeed
 * apw spits feathers at the launcher, get off my damn screen i am using it
<tgardner> apw, and I assume to 2nd patch to which refer is "UBUNTU: SAUCE: PCI: Allow pcie_aspm=force to work even when FADT indicates it is unsupported"
<apw> cking, is that the one i mean, i know there was a followup for it, which was related to regressions induced by the first patch
<apw> bah it wants to remove all my 32 bit support again ... not a good time to update
<apw> ppisati, did we resolved the issues that pushed us back for beta2 on arm?
<tgardner> sforshee, have you noticed suspend/resume issues on your MB Air ?
<sforshee> tgardner, I filed a bug about some touchpad problems after S3, but that's the only one I've seen recently
<tgardner> sforshee, yeah, I'm seeing mouse lockage
<tgardner> sforshee, I didn't notice it until recently 'cause I'd been using an external mouse
<sforshee> it just showed up recently
<sforshee> tgardner, bug 968845
<ubot2> Launchpad bug 968845 in xserver-xorg-input-synaptics "bcm5974 touchpad doesn't work after S3" [Undecided,Confirmed] https://launchpad.net/bugs/968845
<sforshee> if you suspend from the menu things are okay
<tgardner> sforshee, do you have time to bisect for it? is it a kernel issue ?
<sforshee> tgardner, I'm pretty sure it's not a kernel issue
<tgardner> ah, then not a kernel problem
<sforshee> tgardner, I subscribed cnd to the bug, hopefully he'll have some input
<cnd> sforshee, tgardner: no input :(
<cnd> I don't know what might have changed
<cnd> but there has been some work done to the bcm5974 and suspend stuff
<cnd> there might be upstream patches in 3.3 or 3.4 that fix it too
<sforshee> cnd, it seems like the touchpad still works fine, just that userland isn't doing anything with it
<sforshee> i'll check upstream for patches though
<cnd> sforshee, are you saying that evtest still works, for example, but no events are coming through X?
<sforshee> cnd, input events shows reasonable-looking events, and if I restart lightdm it starts working fine on the desktop
<cnd> sforshee, try using xinput test-xi2 to see if you get events from X
<sforshee> cnd, yes, I get events
<cnd> sforshee, so you get events, but the cursor doesn't move?
<sforshee> exactly
<cnd> sforshee, what kinds of events are you getting when you use one finger?
<cnd> touch or motion?
<sforshee> oh, sometimes I get right clicks too
<sforshee> cnd, I see RawTouch* events
<cnd> sforshee, ok, we don't care about raw events for now
<sforshee> that's all I'm seeing
<cnd> sforshee, what non-raw events do you see if you put two touches down?
<sforshee> cnd, none, just RawTouch stuff
<cnd> sforshee, and three touches?
<ppisati> apw: nope, since my panda's video out is still broken, waiting for the new one
<cnd> also, please pastebin the output of "xinput list-props bcm5974"
<ppisati> apw: i think it'll have to wait until after first SRU
<ppisati> apw: since thursday is KF
<sforshee> cnd, the same
<cnd> hmm
<cnd> sforshee, check for any errors in your Xorg.log
<sforshee> cnd, the only thing I find are some "unable to find touch point 0" messages
<cnd> hmm... that could be related
<cnd> sforshee, I seem to recall someone saying that on lid closure the trackpad sometimes emits touch events
<apw> ppisati, kernel freeze means we move to SRU mode, limiting updates without appropriate acking, its not impossible to get things in, and easier probabally than after release
<apw> ppisati, where is your replacement coming from?
<cnd> I don't know if it's a capacitive effect or merely your fingers are close to it when closing the lid
<cnd> I wonder if some evdev events are getting lost at suspend/resume time
<cnd> so a touch is stuck in the "open" state
<cnd> sforshee, it might be worthwhile to do a suspend/resume while recording events using evtest
<sforshee> cnd, here's something strange
<apw> we probabally reset the thing having powered it off for suspend
<cnd> and then seeing if there are any anomalies
<ppisati> apw: austria, but "upstream" didn't deliver any boards to them yet, it seems there's a shortage
<sforshee> I'm noticing that right now my one-finger touches are behaving like two-finger touches; i.e. they are causing scrolling
<cnd> sforshee, ahh yes!
<cnd> that's exactly what I was thinking might be happening
<apw> ppisati, and we don't have any you can test on anywhere we can either get you access to 'em or send one to you?
<cnd> sforshee, a touch is stuck in a state where X thinks it is active
<ppisati> apw: pgraner told me he was sending me a board this week
<cnd> sforshee, how reproducible is it?
<ppisati> apw: actuallyt i could try another rebase tomorrow, and shell it to someone on #arm
<sforshee> cnd, it happens 100% of the time if I suspend using the lid
<ppisati> apw: for testing
<apw> ppisati, well thats something, but we should hastle as the timeing is very poor
<apw> ppisati, yes use them and abuse them
<cnd> sforshee, ok, then do the evtest thing during a suspend/resume
<cnd> let's see if we catch any bad events
<sforshee> cnd, ack
<apw> cnd, i wonder if it sees its own lid :)
<cnd> apw, could be :)
<ppisati> apw: just to clarify, the TI stuff is up to date (no more pulling from them) we are slacking behind wrt to master
<pgraner> ppisati, I sent it to millbank and msm will be sending it down to you
<ppisati> pgraner: k, thanks
<apw> ppisati, ok its arrived in london and i'll be winging its way tommorrow
<sforshee> cnd, is it important that there be a suspend/resume, or just a lid close/open? Because the device is being grabbed when I'm on the desktop, so evtest can't get the events.
<ppisati> apw: cool
<cnd> sforshee, switch to a VT
<cnd> then run evtest
<cnd> oh, but then it doesn't suspend
<cnd> I see
<sforshee> yep :)
<cnd> sforshee, so you can use an Xorg.conf rule to tell X not to grab the device
<apw> cnd, we need a bpf for the events ...
<sforshee> I can do sleep 2; pm-suspend on the VT
<cnd> apw, bpf?
<apw> berkely packet filter, its whats uses to pick out ehternet frames, and i tink now usb and bt frames
<apw> and they were using it for something else mad the other day, now what was that
<apw> seccomp maybe it was
<sforshee> syscall filtering
<sforshee> yep
<apw> so it must be the right thing for event monitoring :)
<cnd> heh
<cnd> sforshee, there's a better way to do this
<cnd> but the faster/hackish way is:
<cnd> add 'Option "GrabEventDevice" "false"' to /usr/share/X11/xorg.conf.d/50-synaptics.conf
<cnd> inside the touchpad catchall block
<cnd> I don't think you'll see any issues when you have the option set
<cnd> I think it's there for a couple of very specific circumstances
<cnd> sforshee, once you've added it, you need to log out and back in
<cnd> then you should be able to evtest while in X
<apw> stopping people reading your keyboard while you are typing perhaps
<cnd> apw, no, that input class section is only for trackpads
<cnd> at one point I knew why we grabbed devices by default
<cnd> it papers over missing functionality needed in the X synaptics driver
<apw> i am glad to hear your brain has flushed that information
<apw> mine does it all the time
<cnd> heh
<sforshee> cnd, that seems to be working
<cnd> cool
<sforshee> cnd, http://pastebin.ubuntu.com/911740/
<cnd> sforshee, did all this occur just by closing the lid?
<apw> oh joy firefox, chromium, and libreoffice updates ...
<sforshee> cnd, i did wiggle my finger on the touchpad after resume
<cnd> sforshee, oh...
<cnd> sforshee, can you get a clean recording without any intentional touchpad interaction?
<sforshee> I can redo it without the wiggling
<cnd> thanks
<apw> cnd, though its reporting a 4 finger touch right?  and i assume he only did one
<apw> or he used his forhead
<sforshee> i always use my forhead, is that unusual?
<cnd> heh
<cnd> apw, good point
<cnd> sforshee, did you only use one finger?
<apw> but you do want a clean 'un
<sforshee> cnd, yep, one finger
<cnd> hmm... then my guess is the driver is screwed up too :)
<cnd> sforshee, btw, you can probably reset the state back to a good starting point by reloading the bcm5974 driver
 * tgardner relocates
<sforshee> cnd, non-wiggling evtest output: http://pastebin.ubuntu.com/911751/
<cnd> sforshee, really?
<cnd> there's a ton of stuff going on :)
<cnd> but it's masked by bad state too
<apw> Event: time 1333386946.147384, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 7630
<apw> Event: time 1333386946.147386, type 3 (EV_ABS), code 51 (ABS_MT_WIDTH_MINOR), value 6492
<sforshee> cnd, reloading bcm5974 did get pointer motion back, and compiz also crashed :)
<cnd> sforshee, can you do the same after reloading the driver?
<apw> waht the resolution of this thing ?
<cnd> fun...
<apw> thats a pretty big finger in most coordinate systems
<cnd> apw, look at the top of the printout
<cnd> it gives the axis max and min for each code
<cnd> it has a pretty high resolution :)
<apw> so those are outside the surface area then no ?
<sforshee> cnd, you want the evtest output again after reloading the driver?
<cnd> looks like it
<cnd> sforshee, yeah
<apw> as its saying 1280x800, and then saying you have a 7k wide finder
<apw> finger
<apw>       Max     2048
<apw> so that number can't be >2k ... ooops
<cnd> apw, or the driver writer had never seen a value higher than that
<cnd> the X and Y max and min for the magic trackpad are merely the highest and lowest values I could get
<cnd> we don't have specs for apple devices :(
<apw> ahh ok
<cnd> apw, but those numbers are *way* beyond the max
<cnd> so something seems wrong
<sforshee> cnd, http://pastebin.ubuntu.com/911758/
<cnd> apw, oh, I think I know what's going on with those numbers
<cnd> the width values are supposed to be scaled, as best as possible, to device units
<cnd> but often times the width values reported by the devices are in some random other unit
<cnd> so a scale factor is devised
<cnd> I would have rather seen evdev report the raw values from the device; that was a henrik decision
<cnd> sforshee, there's still a lot going on, but this is a good baseline
<cnd> so in the first packet there are two new touches
<cnd> in the second packet there appear to be three touches
<cnd> however, BTN_TOUCH is 0 and BTN_TOOL_TRIPLETAP is left at 0
<cnd> I don't understand what is going on there
<apw> cnd, could they be getting softer, cause the pressure is also 0
<apw> could this literally be the screen bouncing off the touchpad ?  does the machine have a touchscreen too?
<cnd> apw, could be, but the touches are still active
<cnd> apw, touchscreen would be a different evdev node, but this doesn't have a touchscreen anyways
<sforshee> apw, no touchscreen
<apw> i was more thinking is the screen made of something that acts like fingers, obviously gloved hands don't work etc
<cnd> it seems like the single touch events (BTN_TOUCH, BTN_TOOL_*) are not in sync with the mt events
<cnd> which is bad enough
<apw> cnd, i dee in the next packet we have 4 taps
<cnd> yeah
<sforshee> I do think there are magnets involved in the lid switch mechanism, which may be close to the touchpad
<cnd> sforshee, does the cursor still move?
<apw> then we move, drop to three touches (correctly), back to four, then lose the touch with them again
<cnd> after this particular recording
<cnd> because all the touches have ended
<sforshee> cnd, it does now because I reloaded bcm5974
<cnd> oh
<sforshee> but it didn't after I killed evtest
<cnd> hmmm
 * apw wonders if he has any magnest to wave at his touchpad
<cnd> heh
<apw> cking, you have magnets i bet ... do they affect touchpads to you know?
<cnd> sforshee, I would send a note to henrik, and cc linux-input, asking about this behavior
<cnd> I think others have seen it
<cnd> but I can't seem to find any emails
<cking> apw, I can find some... let me see what the kids have
<apw> oh i have a fridge magnet, let me try that
<cnd> sforshee, there seem to be two issues:
<apw> this machine has an ssd so i should keep the disk contents :)
<cnd> 1. the driver is not in sync between mt and st data
<cnd> 2. has anyone looked into this already, is there a fix or a workaround?
<cking> apw, so what do you want me to try then?
<apw> cking, does it affect your touchpad at all
<cking> here goes..
<apw> doesn't on mine (found a ladybird on the fridge)
<sforshee> apw, I'm failing to get a reaction from the touchpad using a magnet
<cking> apw, no, but my HDD is now wiped ;-)
<cnd> sforshee, try taking the screen of another laptop and hovering it over the trackpad?
 * cking saunters off, was on at 7am..
<cnd> maybe the LCD is doing it :)
<apw> cnd, you have a separate one of those don't you?
<cking> cnd, bet the speaker magnets in the LCD are affecting it
<apw> cking, well except they don't on yours at least
<cnd> apw, you mean a magic trackpad?
<cnd> I could try that
<apw> yeah that is likely similar device is it not
<apw> i guess the trackpads are metal whereas mine may not be, so it may have more effect there
<cnd> apw, ooo!
<apw> cnd, it does vomit for some time either side doesn't it
<apw> oooo ! ?
<cnd> I got stuff when waving my MT across the top of my macbook lid
<cnd> where the magnets are
<apw> there are serious magnets in there
<cking> http://www.gizmag.com/100-tesla-pulsed-magnet/21946/
<cking> 100 tesla magnet will do 
<apw> another apple special then, their own trackpad is affected by the magnets they use to close the box
<cnd> actually, it does it to the screen too
<cnd> so it may not be the magnets
<apw> cnd, i suspect thats not normal for other touchpad types
<sforshee> apw, cnd: I can get events by holding a macbook pro near the macbook air touchpad
<cnd> apw, hard to tell
<apw> sforshee, so if you shove two or three sheets of paper in the gap and close/open does it do that
<apw> we might be able to tell if its magnets (longer range) or plastic coating touching (short/zero) range
<sforshee> apw, yes, when the lid is very close to closing I start getting some events
<cnd> sforshee, I wonder if you add a resume hook to the driver to reset the state if it will fix things?
<sforshee> basically it seems to happen at the point where the lid tries to snap closed
<apw> cnd, should we not worry they could make 'valid' events and do something awful like close or move a window
<cnd> hmm... good point
<apw> like needing to disable the touchpad stream as soon as the lid event starts or something?
<cnd> yeah
<cnd> I don't know exactly how you would do that though...
<apw> sforshee, can we tell when the lid event occurs, ie does the machine suspend if you close it reallly really slowly
<apw> cnd, well OSX must be able to cope, so likely the lid event is in before the interferance starts
<apw> sforshee, as a test maybe you could do something like close the lid in glacial time
<apw> and see if it triggers before the events start
<cnd> apw, yeah, probably
<cnd> apw, but how could you code that up in a linux driver
<cnd> ?
<apw> you'd need to let the two kernel dirvers know about each other
<cnd> I don't know if there's some way the bcm5974 driver can listen for lid events
<apw> which is vileness extreme
<cnd> yes
<mjg59> Not trivially
<mjg59> You could add a notificaiton chain
<cnd> mjg59, ahh, should have pinged you earlier :)
<mjg59> Or you could push it out to userspace
<apw> yeah its bound to be a violation of about 20 layering
<cnd> mjg59, if you pushed it out to userspace you might have race conditions
<mjg59> Have a udev helper fire on the lid event and disable any USB input devices that are flagged as non-removable
<cnd> mjg59, how could you be sure the bcm5974 driver will get it in time?
<mjg59> cnd: It's going to be racy on a multi-threaded system in any case
<cnd> I'm not meaning issues between cores
<cnd> I mean issues in time
<apw> i think if it even does it of course, you would have to have the MT driver check before emitting any packet
<apw> which would mean looking at something global and shared in the kernel, which stinks
<cnd> like, the event reaches userspace, userspace processes it and turns the touchpad off in 100 ms
<cnd> but that's already too late
<cnd> I suppose my theory is that keeping things in kernel will reduce the time enough that it is more reliable
<apw> we'd need to confirm somehow the order of the events, is there anything we hear of in time even
 * cnd wonders how we haven't seen this before
<apw> http://askubuntu.com/questions/91534/disable-touchpad-while-the-lid-is-down
<apw> sforshee, you might be able to use that to get a hint as to whether the lid closes before the problem happens if you arn't to quick :)
<cnd> I bet because of behavior changes in X
<sforshee> so I'm pretty sure at this point it is the magnet, as I can hold a macbook pro close to the touchpad but not touching and get touchpad events
<cnd> apw, that will only turn off the device at the X level
<sforshee> I also know I can suspend the machine without completely closing the lid
<cnd> maybe that's good enough though
<cnd> sforshee, you can evtest both the bcm5974 and the lid switch devices
<cnd> and compare the timestamps
<apw> sforshee, when does the backlight go off relative to the problem occuring too
<cnd> see how close they get with fast lid closures
<ohsix> it can be emi too, though i dunno much of which would be near where the magnets are
<apw> sforshee, what cnd suggests makes the most sense.
<ohsix> my friend could make his macbook reboot by putting his phone next to his computer, they can be pretty sensitive :D
<apw> lets see if they are in any sort of sensible order
<sforshee> apw, it goes off earlier -- there seems to be something else in play for the lid event
<cnd> sforshee, what goes off earlier?
<sforshee> I can't make the machine suspend by holding the MBP closeby
<sforshee> cnd, the backlight
<cnd> oh
<apw> sforshee, isn't that triggered by the lid event ?
 * apw thinks we need the double evtest comparison
 * sforshee is getting it right now
 * cnd whipers
<cnd> whispers...
<cnd> I ruined it
<sforshee> the lid switch event happens first, by about 400 ms
<apw> ok so we at least have something to tell us when we need to ignore it
<cnd> sforshee, including when you try to close it as fast as possible without breaking it?
<apw> sforshee, i assume it unhappens after the flood stops too yes?
<sforshee> cnd, I was just about to say, let me try again closing the lid as quickly as possible
<ohsix> sforshee: was the input periodic or just fast/seemingly random
<cnd> ohsix, http://pastebin.ubuntu.com/911758/
<apw> ohsix, its a bunch of fat fingers reported all over the touchpad
<apw> cnd, this feels very familiar you know, is the matrix broken ?
<ohsix> interesting, it could be the lcd
<apw> ohsix, i think experimentation says its the lid in some sense, which bit isn't so interesting
<sforshee> rats, now I start getting touchpad events about 7 ms before the lid event
<cnd> ugh
<apw> sforshee, well ... remember we have to get them out into userspace
<apw> who puts the timestamps on them, the uspace daemon ?
<sforshee> apw, yes
<sforshee> but they're certainly very close
<cnd> apw, that doesn't even matter now
<cnd> the lid switch is occurring *after* the bad touches
<apw> cnd, where is the timestamp we see added
<ohsix> right but a magnet isn't going to capacitively couple with a touchpad, it may induce currents but only as it moves (no matter how strong it is)
<cnd> apw, hmm?
<cnd> I didn't understand the question
<apw> cnd, we have two streams of data with timestamps, who put the stamps on them, the kernel or the evtest app
<cnd> apw, the kernel
<sforshee> apw, 7 ms seems long enough that I doubt they're getting reordered anyway
<ohsix> some heuristics in the touchpad firmware are probably going bonkers because it's coupling with something in the display
<apw> ohsix, yep i think we know that ... what we don't know is how to stop it
<apw> given the lid is not going to change compisition
<ohsix> right :] it's just not a magnet
<ohsix> you may be able to control SSC or something in the lcd panel that could affect it tho
<apw> sforshee, it may be worth looking for reports of whining on osx about closing the lid and it being bad
<apw> (if you do it fast)
<cnd> btw, my MT sees touches even when the screen is off
<sforshee> ohsix, there seems to be a magnet in the lid that holds the lid down when it's closed
<cnd> so merely turning the screen off isn't a fix either
<sforshee> so when you close the lid it will be moving, period
<ohsix> cnd: what model is it?
<sforshee> macbook air 4,1
<cnd> ohsix, I was playing with a magic trackpad and a macbook 5,1 (I think)
<apw> cnd, yeah wasn't thinking we want to turn off the screen, i was thinking we want to disable the touchpad
<cnd> yeah, I was just throwing it out there
<cnd> in case anyone else thought about it :)
<apw> cnd, that link i posted is from something with MSI hotkeys, doing the same sort of thing
<cnd> apw, I missed the link
<cnd> oh, nm
<cnd> I got it
<apw> sforshee, so i assume if you turn off 'suspend when closed' we could get a trace then which would tell us if its the screen moving or it being closed at all is the issue
<sforshee> cnd, the root problem though is that userland is in a confused state though, right? so can we reset the userland state after s3?
<apw> sforshee, what if it quad clicks on something
<cnd> sforshee, maybe
<sforshee> apw, true
<apw> cnd, actually arn't the touches 'really really big' ?
<cnd> not all of them
<apw> cnd, and doesn't osx have "stop palms from doing bad things" support ?
<apw> maybe they get away with it cause of that
<sforshee> apw, cnd: actually I've noticed a few times that the dash is up after S3 when I'm sure it wasn't before, so that's probably caused by these events
<cnd> maybe
<cnd> heh
<apw> eeek
<apw> sforshee, so maybe try the thing they do in there and see if it helps any
<mjg59> Ok, easier way:
<mjg59> Have the X server tag all input devices as internal or external (or unknown)
<mjg59> The X server is single threaded, so can't race against itself
<mjg59> On lid close, stop listening to internal events
<ohsix> the magnets are pretty far away from the camera
<mjg59> Doesn't help in the case where the events are out of order, but...
<apw> mjg59, sounds logical, at least there it has only a 7ms window instead of 'all night' to get events
<cnd> mjg59, there's no real way for one X input module to listen to events from another
<ohsix> here's the stuff at the top of the frame http://guide-images.ifixit.net/igi/jcpGIlZE1LLllEoQ.medium http://guide-images.ifixit.net/igi/fGqAJCnKVgROdlkl.medium
<cnd> IIRC
<cnd> and part of the state that needs to be maintained is in the X synaptics module
<cnd> however, the X server could turn off an input driver
<ohsix> heh what mjg59 suggests is probably a good idea for all machines :D (if there's a reliable indication when the lid is working)
<cnd> mjg59, that still doesn't resolve the problem of fast lid closure
<cnd> where the lid event occurs after the bad touches
<apw> cnd, we actually can't program round bad h/w design
<apw> cnd, if you close it fast and it presses random shit, there is little we can do about it
<cnd> yeah
<apw> i know you don't want to hear an apple product has bad design, but ... i suspect it does
<sforshee> i literally slammed the lid, it will rarely be closed that fast
<cnd> sadly, I can't test this
<cnd> because my macbook won't suspend/resume properly
<cnd> ok, then maybe it will be good enough
<apw> sforshee, the joys of work owned test key :)
<apw> kit
 * sforshee goes to find some food
<ppisati> unity2d can finally enjoy the launcher on the second screen... @$#%@#@$@#...
<beata|lemur> I get an error message when I run the 'git rebase --onto origin/master origin/master@{1}' command listed on the kernel git guide wiki, section 'Maintaining local changes': 'fatal: Needed a single revision' 'invalid upstream origin/master@{1}'
<apw> ogasawara, that testing came in, postitive so am about to push those hyper-v patches
<ogasawara> apw: ack.  go ahead and push, I'll wait to rebase to 3.2.14 till after you've pushed.
<apw> ogasawara, ok done, thanks
<tgardner> ogasawara, how's the Q rebase going ?
<ogasawara> tgardner: just finishing it up and am about to test build
<Kano> apw: could you touch the missing include file maybe? even a 0 size file is enough to fix compilation issues
<Kano> did somebody else notice that kernel 3.3+ boots faster than 3.2?
<Kano> similar speed to 2.6.38 which was faster than .39+
<Kano> debian 3.2: 8s, mainline u config: 7s, since 3.3: 5s
<Kano> i boot wheezy btw ;)
 * tgardner -> EOD
 * ppisati -> reboot
<Kano> does anybody know why booting via efi is slower
<lesshaste> is there a workaround for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/884210 ?
<ubot2> Launchpad bug 884210 in linux "PCI/internal sound not working randomly, random hangs: "cannot set freq 16000 to ep 0x86" shown in syslog" [High,Confirmed]
<lesshaste> oh is there an easy way to test a more recent ubuntu kernel?
<lesshaste> I am on oneiric
<ayan> all: what determines which modules are loaded at boot time?  i notice /etc/modprobe.d/* but those files seem to determine what isn't loaded more than what is.
<Kano> udev
<Kano> lesshaste: which gfx card
<lesshaste> 01:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS 285] (rev a1)
<lesshaste> Kano, ^^
<Kano> nvidia binary used?
<lesshaste> I just switched to nouveau
<lesshaste> to see if it would help
<Kano> because you need hacks for newer kernels
<lesshaste> I still get  cannot set freq 16000 to ep 0x86
<lesshaste> I just want to be able to use the quickcam without it destroying my compute r:)
<ayan> Kano: i suspected udev might do it but -- for example -- i have psmouse loaded but i don't see it anywhere in any of the udev configuration files.
<Kano> alias:          serio:ty05pr*id*ex*
<Kano> alias:          serio:ty01pr*id*ex*
<Kano> you see with modinfo psmouse
<lesshaste> Kano, are there no kernels in backports?
<lesshaste> Kano, that I can use in 11.10
<Kano> i dont use ubuntu
<lesshaste> we are in #ubuntu-kernel!? :P_)
<Kano> KERNEL
<Kano> i recompile it or use mainline ones
#ubuntu-kernel 2012-04-03
<kengyu> ogasawara, hi, do you think will do 3.2.14 rebase before the kernel freeze?
<Sarvatt> kengyu: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=shortlog;h=refs/heads/master-next
<kengyu> Sarvatt, ahh, cool, already done!
<wrostek> Im having trouble with my Ubuntu Install, I was building kernels the ubuntu way, and then using dpkg -i <kernalname> to install and apt-get purge <kernelname> to remove..  Next day Ubuntu boots into lighted but freezes shortly after, no message in logs, can't ssh in.. its useless
<wrostek> Im having trouble with my Ubuntu Install, I was building kernels the ubuntu way, and then using dpkg -i <kernalname> to install and apt-get purge <kernelname> to remove..  Next day Ubuntu boots into lighted but freezes shortly after, no message in logs, can't ssh in.. its useless
<wrostek> Is there a way to repair the installation?
<RAOF> wrostek: There's always a livecd.
<RAOF> And what do you mean by âlightedâ?  If you can boot into recovery mode and not have it hang then you've got the opportunity to do basically everything.
<wrostek> RAOF what can I do? which package should I try to reinstall?
<wrostek> I booted into recovery mode, reinstalled the kernel, unity, lightedm,  not sure what else
<wrostek> I could reinstall
<RAOF> That kinda depends on what's breaking.  I'd start by just booting into the original Ubuntu kernel and seeing if that works.
<wrostek> It does not, it usually gets to the point of lighted login, or just before the login appears and stops, no hard drive light nothing.. its just dead
<wrostek> lightdm sorry
<wrostek> There is nothing in the log ( no errors ) so Im not sure what else I can try
<wrostek> Is there anyway to have ubuntu reinstall all packages or something?
<RAOF> You can run an âaptitude reinstall ~nâ, which will reinstall all packages.
<wrostek> do you think that would help?
<RAOF> No, not really.
<wrostek> Ok, is there a way to boot to console?  Maybe x is causing the problem, is there a way to test that?
<RAOF> Recovery mode boots to console.
<RAOF> But if you *are* booting the Ubuntu kernel which previously worked then I don't think the kernel is your problem.
<wrostek> But it doesn't load all the other services, maybe the problem is just in x
<wrostek> Yes, I think when I was removing old kernels something got removed with them
<RAOF> But X hasn't changed?
<wrostek> No, I havnt touched it
<RAOF> I'd just try installing ubuntu-desktop (and possibly âapt-get --fix-policy installâ to pull in any Recommends that have gone away).
<wrostek> thanks, let me try
<wrostek> fix policy installs all the recommended packages correct?
<RAOF> Yes.
<wrostek> HEY RAOF, thanks for your help, somehow that worked
<ppisati> moin
<apw> morning
<smb> morning
 * apw reboots to get the latest 'goodness' i may be sometime
 * ppisati -> reboot too
<infinity> apw: Around?
<infinity> apw: Opinions on picking up the patch in http://www.spinics.net/lists/raid/msg37775.html ?
<infinity> apw: Those ioctl printks are scary as all get out, until one researches them (which people shouldn't really be forced to do to prevent heart attacks)
<infinity> apw: Picking it up for precise, and dropping it for Q would be my vote, if upstream still wants the printks there to track userspace behaviour.  But it doesn't belong in a "production" (especially LTS) kernel, IMO, to whine at me every time mdadm does something harmless.
<apw> infinity, what you doing which triggers it, this on your ppc ?
<infinity> apw: No, on my amd64 server.  mdadm trips over this every time it does, well, anything.
<infinity> [3704718.535581] mdadm: sending ioctl 1261 to a partition!
<infinity> [3704718.535587] mdadm: sending ioctl 1261 to a partition!
<infinity> [3704726.247198] mdadm: sending ioctl 800c0910 to a partition!
<infinity> [3704726.247204] mdadm: sending ioctl 800c0910 to a partition!
<infinity> Etc.
<apw> infinity, then that fix isn't enough to fix it
<apw> as you have two ioctls there
<apw> and are they safe ?
<infinity> I see 7 in the patch.
<infinity> But I'm not sure what they all map to.
<infinity> Everywhere I look for the above, I get LKML hits saying "it's harmless reporting, ignore it", and the like.
<apw> ahh so there is, i should open my eyes
<infinity> But it sure doesn't LOOK harmless.
<infinity> Not to the casual observer.
<apw> infinity, sounds reasonable to me, i wonder if L has uploaded yesterday bulk updates
<infinity> Hence, I suspect, SUSE carrying the above patch for SLED.
<apw> got a reference to a clean patch is is that the only reference
<infinity> apw: One message up in the thread, lazypants? :)
<infinity> apw: Or do you mean a ref to a git tag or some such?  In which case, dunno, I have no idea where SUSE does their kernel work.
<apw> infinity, got a bug number ?
<ikepanhc> smb: could you please take a look at bug 940056
<ubot2> Launchpad bug 940056 in debian-installer "[public] armadaxp net installer fails to properly setup initrd for raid (md)" [High,New] https://launchpad.net/bugs/940056
<ikepanhc> smb: is that the same issue as bug 969248 ?
<ubot2> Launchpad bug 969248 in linux "d-i: dmraid4-5 module is missing from udebs" [Medium,Fix committed] https://launchpad.net/bugs/969248
<apw> ikepanhc, i don't think it would be ... dmraid-45 is a PC BIOS specific s/w raid configuration model i believe
<apw> ikepanhc, and if i am reading the bug right we fail to install mdadm tools which is not in the kernel at all: 
<apw> Note: raid devices may be detected after "sudo apt-get install mdadm && reboot"
<ikepanhc> apw: ok, thanks.
<ikepanhc>  I have little knowledge about netboot
<apw> ikepanhc, i beleive netboot is very similar to an ordinary alternate image
<ikepanhc> what I know is netboot will load Image and Initrd via tftp, because the d-i name is also incorrect in armadaxp kernel, so I just wonder if the root cause if dm-raid45.ko is not found - well, this is a wrong guess
 * ikepanhc is reading device mapper page, looks nothing with mdadm
<ikepanhc> s/with/about
<dileks> hi
<dileks> can everyone participate at the kernel-team meeting today?
<ogra_> its in a public channel ;)
<smb> ikepanhc, apw is right, if you are not using dmraid to set up a RAID that has been defined in BIOS it is not using dm-raid45
<smb> madmn would use raid456 or something other md modules. Note that mdadm is completely different from device-mapper
<smb> Also the bug seems to mix raid and dm-crypt... Are you setting up encrypted lvm or a RAID ?
<apw> smb, doesn lvm use dm underneath ?
<smb> lvm does but not md
<ikepanhc> I do not with the hardware..
 * ikepanhc review the bug again
<smb> And usually RAID is defined using md / mdadm
<smb> I see the log has a raid10
<smb> but I need to read more carefully from the beginning
 * ppisati -> lunch
<ikepanhc> ok, I see what confused me :( md v.s. dm
<smb> ikepanhc, This setup seems to include as much as it can for confusion
<smb> ext4, xfs, lvm, md
<ikepanhc> ok, so, for this bug, what I shall do is check the config and make sure the software raid is on and included in Image or Initrd
 * ikepanhc feels little chance that raid crash after reboot
<tgardner> jjohansen, henrix, ppisati, ayan: rebooting tangerine for kernel related update
<jjohansen> tgardner: ack
<henrix> tgardner: ack. logged out already
 * smb might have missed things (since 12:09UTC)
<apw> smb, forget to reset your router again ?
<smb> apw, I probably have to again :/
<smb> Once did but is seems to delevop a fancy to play dumb games around early afternoon
<apw> t'is when BT tend to do line work for me too, so i get dropped then sometimes
<smb> yeah, logs say I was disconnected about the time. Of course there is no reason code...
<tgardner> ogasawara, still struggling with the Q rebase to 3.4-rc1 ?
<ogasawara> tgardner: I am, hitting a few build failures that I'm getting cleaned up
<ogasawara> tgardner: am gonna get precise prepped and uploaded and then get back to hammering on q
<tgardner> ogasawara, good plan :)
 * ogasawara back in 20
<tgardner> ppisati, who in Q/A has panda HW ? Tobin ?
<jsalisbury> herton, bjf, some possible regressions in 3.0.0-18: bug 972033 and bug 972529
<ubot2> Launchpad bug 972033 in linux "After today incoming linux-image-3.0.0-18-generic upgrade cannot get my session working" [High,Confirmed] https://launchpad.net/bugs/972033
<ubot2> Launchpad bug 972529 in linux "3.0.0-18 "everything crashing" regression" [High,New] https://launchpad.net/bugs/972529
<bjf> jsalisbury: i've already added a comment to 972529
<jsalisbury> bjf, great, thanks.  
 * ppisati backs off for a bit
<jsalisbury> bjf, herton bug 972173 looks similar 
<ubot2> Launchpad bug 972173 in linux "Crash!" [High,Confirmed] https://launchpad.net/bugs/972173
<jsalisbury> henrix, ^^^ Should have included you in the SRU team list.
<henrix> jsalisbury: feel free to do it next time :)
<jsalisbury> henrix, will do
<tgardner> bjf, re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972529/comments/2 , the dmesg _is_ from a -17 kernel
<ubot2> Launchpad bug 972529 in linux "3.0.0-18 "everything crashing" regression" [High,New]
<bjf> tgardner: ack
<herton> wow everything on fire, not good. I used 3.0.0-18 on Oneiric (now already on master-next -19), didn't notice anything bad, but may be it's the applications I use, don't use KDE/opera like in reports
<henrix> my guess is that its related with PM + hda-intel driver
<herton> I suspect "epoll: limit paths" may have something to do with it, there is a later fix for it not on -18 (93dc6107a76daed81c07f50215fa6ae77691634f), could explain this type of breakage, just a hunch though
<henrix> oops, i was referring about the previous one, #968675
<ogasawara> commit 79cd378824107633c86ea4cbee1253b40c967537
<ogasawara> Author: Rick Jones <rick.jones2@hp.com>
<ogasawara> Date:   Mon Nov 7 13:29:27 2011 +0000
<ogasawara>     sweep the floors and convert some .get_drvinfo routines to strlcpy
<ogasawara>     
<ogasawara>     BugLink: http://bugs.launchpad.net/bugs/921793
<ogasawara>     
<ubot2> Launchpad bug 921793 in emulex "Update be2net driver in 12.04" [High,Confirmed]
<ogasawara>     Per the mention made by Ben Hutchings that strlcpy is now the preferred
<ogasawara>     string copy routine for a .get_drvinfo routine, do a bit of floor
<ogasawara>     sweeping and convert some of the as-yet unconverted ethernet drivers to
<ogasawara>     it.
<ogasawara>     
<ogasawara>     Signed-off-by: Rick Jones <rick.jones2@hp.com>
<ogasawara>     Signed-off-by: David S. Miller <davem@davemloft.net>
<ogasawara>     Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
<ogasawara> tgardner: am getting build failures on powerpc with the above commit
<ogasawara> tgardner: was that a clean cherry-pick from upstream or a backport?
<ogasawara> drivers/net/ethernet/marvell/mv643xx_eth.c: In function 'mv643xx_eth_get_drvinfo':
<ogasawara> drivers/net/ethernet/marvell/mv643xx_eth.c:1505:59: error: 'info' undeclared (first use in this function)
<ogasawara> drivers/net/ethernet/marvell/mv643xx_eth.c:1505:59: note: each undeclared identifier is reported only once for each function it appears in
<tgardner> ogasawara, clean. so just disbale it from power since I don't think it exists in real life.
<ogasawara> tgardner: it looks like it should be s/info/drvinfo/
<tgardner> ogasawara, I wonder if there is an upstream patch for it. perhaps nobody upstream actually builds it for powerpc
<tgardner> ogasawara, hmm, not seeing anything obvious
<ogasawara> tgardner: looks like an honest mistake based on other changes in that commit, I'll test out my fix and send it up
<tgardner> ogasawara, net: mv643xx_eth: fix build erro
<tgardner> 6f39da2c5eab64921f92a9ff4a48f3d14a8db24c
<ogasawara> ah, how did I miss that
 * ogasawara cherry-picks
<tgardner> ogasawara, super green ?
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> YIKES, the root disk is full on cranberry
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 10th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<salaria> Guess, I'm at right place. Anyone here?
<tjaalton> so.. i was planning to backport support for new wacom models to the precise kernel, but is 15 commits (11 from 3.3, 4 for intuos5 support not yet upstream) too much to shove in this late?
<tjaalton> make that 13
<apw> tjaalton, with kernel freeze already on us, and the last upload in progress, you'll need to be pretty persuasive
<tjaalton> apw: yeah, I'll stop :)
<apw> :)
<tjaalton> probably not sru'able either, so lbm then
<apw> lbm sounds viable ... though thats always a huge pain to maintain
<tjaalton> in what way? haven't touched that at all..
<apw> tjaalton, is this touchpads or something else ?
<tjaalton> tablets
<apw> tjaalton, they are jsut 'different'
<apw> ok so not mainstream things in a common sense
<tjaalton> nope
<ppisati> tgardner-lunch: last pull req for P/omap4 sent (config changes to reduce master skew)
<apw> cool, ogasawara is our lbm expert :
<apw> :)
<tjaalton> well, built-in touchscreens tend to use wacom too
 * ogasawara looks up
<tjaalton> ogasawara: so, if I wanted to provide some way to support 3rd gen bamboos and intuos5 tablets, would lbm make any sense or would a wacom dkms package be better?
<tjaalton> (the dkms package actually exists in some ppa)
<ogasawara> tjaalton: if the dkms package already exists and works, I'd just go that route
<tjaalton> ogasawara: ok, I'll probably test that and just tell people to use it if it works :)
<apw> problem solved :)
<tjaalton> less pain for everyone :)
<apw> presumably we can put it in universe still
<ogasawara> I'd assume so
<tjaalton> hmm, maybe. ppa's are easy to use though, and keep updated
<tjaalton> I'll ask the author what he feels about it
<apw> t
<apw> tgardner, 32 or 64
<tgardner> apw, 64
<apw> tgardner, thanks ... will get you some bits to test
<infinity> apw: I didn't file a bug for the ioctl printk spam, no.
<infinity> apw: Do you need one?
<apw> infinity, s'ok tgardner did the do
<infinity> Kay.
<apw> sh-keygen -f "/home/apw/.ssh/known_hosts" -R greenback.local
<apw> no, not that ... thats not helpful
<apw> http://bugs.launchpad.net/bugs/972355
<ubot2> Launchpad bug 972355 in linux "linux: Supress some ioctl warnings which are known benign" [Medium,Fix released]
<apw> infinity, ^^
 * apw takes it ogasawara has uploaded :)
<ogasawara> I have :)
<apw> infinity, if you could test that kernel does what you need when its built then we can backport it
<apw> ogasawara, you are the (wo)man
<infinity> apw: You mean I have to reboot my server?  *whine*
<infinity> apw: (Yeah, I'll test soon)
<ogasawara> tgardner: 3.4-rc1 rebase pushed to q (I folded in all the build fixes with the one exception of temporarily disabling overlayfs which I left at the tip of the tree)
<tgardner> ogasawara, cool
<apw> infinity, its a few days from building it its for ppc
 * ogasawara sync's the latest patches from precise to q
<infinity> apw: It's amd64.  Not *all* my hardware is PPC.
<apw> infinity, you say that now, its probablly emulating :)
<infinity> (Mostly because I don't want to mail a POWER machine to a co-lo facility, so I lease)
<apw> infinity, a plan indeed.  s'what i do too
<apw> tgardner, http://people.canonical.com/~apw/vt-handoff-grub-precise/ <-- using the kernel there, and applying grub-10_linux.diff to /etc/grub.d/10_linux, could you boot, SHIFT into the menu and change the set gfxpayload=$fooo to =text and then let it boot ... and tell me if its better then and also get me a dmesg
<tgardner> apw, 10-15 mins yet....
<apw> tgardner, faster, faster, more whips
<tgardner> apw, its that desktop seed. its over a 1000 packages now
<bjf> ogasawara: commit 203aa5260edca2ab1872ad8b08386d874f7132f3 may be the cause of a rash of problems on oneiric, precise has the same commit
<bjf> ogasawara: 93dc6107a76daed81c07f50215fa6ae77691634f seems to fix the problem
<tgardner> bjf, rtg@salmon:~/ubuntu/ubuntu-oneiric$ git log -p 203aa5260edca2ab1872ad8b08386d874f7132f3
<tgardner> fatal: bad object 203aa5260edca2ab1872ad8b08386d874f7132f3
<bjf> tgardner: precise 
<ogasawara> bjf: ack, is that fix going to come back down through stable?
<bjf> ogasawara: i don't see a cc stable on it
<ogasawara> bjf: is there a bug# for this?
<bjf> ogasawara: i'm tracking 6 that are possibly related to this
<ogasawara> bjf: need a precise test kernel?  I can whip one up for ya.
<bjf> bug 971746
<ubot2> Launchpad bug 971746 in linux "Kernel 3.0.0-18 - Unitiy does not start (Lifebook T4220)" [Medium,Confirmed] https://launchpad.net/bugs/971746
<bjf> ogasawara: ^
<ogasawara> bjf: thanks, looks like feedback is good there.  I assume henrix is going to push this through as an SRU
<bjf> yes
<ogasawara> bjf: if so, I can just pick the patch for Precise when he sends it to the list etc.
 * apw is a bit perplexed at the description of the fix ... if so why does it not break all installs
<apw> why just the lifebook ?
<bjf> apw, not sure but most(all) our reports are coming in for i386 kernels
<apw> bjf, its just such a generic fix that its amazing that if tis the cause of anything, and if it is how anything avoids tripping it
<apw> bjf, litterly one of those where when you find it its liek "how the heck did this ever work"
<bjf> apw, agreed
 * apw can hear booze being poured, thats mean
<herton> apw, the other similar reports we have, bjf was passing some of those: 972173 972033 972285 972529
<apw> herton, i don't doubt it real, whats amazing is its only a few machines given the fix
<apw> it should be _all_ machines running anything without it really
<herton> apw, indeed, this issue is weird, may be there is something else that makes especifically trigger on these machines, only common thing seems it happens on i386
<apw> signdness or something indeed
<tgardner> apw, still have to <ESC> to get the passphrase menu. zinc.canonical.com:/home/rtg/dmesg.txt
 * tgardner -> EOD
<rlaager> Can someone please re-open #570542? It has multiple comments confirming the bug is present in Maverick final, Oneiric, and Natty and #658461 has been marked as a duplicate of it.
<bryceh> ogasawara, ^^
#ubuntu-kernel 2012-04-04
 * apw yawns
<RAOF> apw: Good morning!
<apw> RAOF, evening !
<RAOF> apw: I've been prodded with a gfxpayload bug - bug #971204 - I thought this stuff had been pretty thouroughly bedded down by now?
<ubot2> Launchpad bug 971204 in linux "graphics fails with setgfxpayload=keep, AMD Radeon" [Medium,Incomplete] https://launchpad.net/bugs/971204
<apw> RAOF, yeah we did too, but they probabally only test initialisating from 'text mode', so some level of regressions are only going to be detected by us
<apw> RAOF, i have only ever debugged one of these with Intel, and the approach there was to get an intel register dump from the two initialisations ... so disable X, and then boot both ways and get a dump remotly via ssh.  that then showed a difference in setup that the upstream guys could see how to unpick correctly
<apw> RAOF, so actually it was 4 dumps, disabling DRM drivers as well, so both modes, dumps before and after drm initialises
<RAOF> Whee!
<apw> RAOF, can we do something similar for radeon registers ?
<RAOF> I think that'd be possible for radeon, yeah.
<apw> in intel cases it has always been an unpicking error, so we turn things off in such an order that we put the thing in a state which would be illegal during init and it locks up or goes mad or similar
<RAOF> I think radeon has a bunch more registers, but radeontool can dump them all.
<apw> yeah it cirtainly wasn't about comparing them by hand.  i was using diff -u on them, i was finding the broken case the pipes were going into error and never coming out
<apw> with that infor they said, doh if A is connected to Y and we try and switch the pipe order without first switching off Q ... and they fixed it
<apw> but it needed someone who knew the specs in their head
<apw> RAOF, also is it a 'new' card ?
<RAOF> Newish.
<apw> [ATI Radeon HD 6800 Series]
 * apw is a little supprised it has regrssed between the two, i've not seen that before (between O -> P)
<RAOF> Yah.
<apw> https://launchpadlibrarian.net/99888732/Screenshot%20from%202012-04-03%2022%3A38%3A09.png
<apw> RAOF, i assume htat is nothing todo with the original but there, but i have seen that recently-ish as well, the old there when you scroll, gone when you scroll some more
<RAOF> Urgh.
<RAOF> What driver?  radeon?
<apw> RAOF, na, all intel.  i've seen it only once, and i have upgraded X and kernel since i suspect, i'll worry if it becomes common :)
<RAOF> :)
<apw> RAOF, its one of those that happened when using SHIFT+PGUP in terminals
<diwic> apw, btw, are  you and the rest of the team  still having pulseaudio + mumble problems?
 * apw remembers the says when the fence locking was bad and it was every time :)
<RAOF> Aaah, fun times.
<apw> diwic, yeah some, tim nearly wrecked his monitor trying to get it working yestrday.  personally i have had a few good days recently
<apw> diwic, she is a tempremental beast
<diwic> apw, yeah, because I haven't even seen a launchpad bug for it, nowhere to ask you questions, get logs etc. Honestly, you don't look very eager to get it fixed...?
<apw> diwic, you don't expect us to behave like proper sensible citizens do you?  to do the things we'd ask you to do?
<apw> diwic, :)  i'll file a bug next time it happens to me and try and get a core or something off it before i kill it in the face
<diwic> apw, and we're closing in on Final Freeze, so if you want it fixed...
<apw> diwic, ubuntu-bug alsa ?
<diwic> apw, go for ubuntu-bug pulseaudio and then ping me to point me at it.
<apw> diwic, yeah i know, though as its broken we can still fix it, and frankly i'll be on whatever Q is called soon :/
<apw> diwic, ok will get the message out to people
<diwic> apw, bug fixes are in general carried on to the next release. :-)
<apw> smb`, yo ... mumble ?
<apw> diwic, heh fingers crossed ... we gonna get some spectacular new fun in pulse in Q
 * apw considers he probabally expects to know what Q is called by now
<apw> diwic, ahh crap i have pulse pending for update ... so i can't file a bug even if i want to
<apw> RAOF, do i want to know why i have a new x-server :)
<RAOF> apw: Only if you've got a touchscreen :)
<apw> wacom ?
<RAOF> Are you having problems single-clicking on stuff?
<RAOF> Because the new server should fix it.
<apw> RAOF, heh no i think that works ok :)
<apw> oh goody the keyboard bindings they changed last week ... are changing again
<apw> how could that possibly be confusing for m
<apw> me
<ppisati> moin
<smb> ciao
<ppisati> ciao Stefan! :)
<smb> ppisati, :)
 * smb needs coffee...
 * ppisati -> reboot
<janimo> are the kernel meta-packages also kept in git and source packages built from there?
<smb> yes
 * cking bailing out, feeling really unwell today
 * smb reboot
<apw> tseliot, manage to test that vthandoff combo ?
<apw> smb, bah after all that the bad link is indeed bad, but completely ireelivant, it should be simply removed
<smb> apw, saw the email
<smb> apw, btw, you may be pleased to hear I also have a system that can reproduce the nouveau need to press esc twice bug
<apw> smb, ahh that is excellent
<apw> then ... i will forward you and email with the testing bits
<smb> apw, sure. was sort of the plan. :)
<apw> smb in flight
<smb> apw, landed
<apw> smb, cool thanks
<apw> smb, so to expalin, this would still need a third fix for not selecting text when we know we cannot ever do it, but the key is if =text is selected then we should never enable handoff kernel side
<apw> smb, in the case of encrypted root there is no point and it should be forcing no-graphics always
<apw> currently it is assumed the selection will fail (no graphics mode selected as an error) and then be ok, but handoff is wacking some bad drivers i think
<smb> apw, I was wondering about (and also about to ask) what the $foo stands for (whithout having looked at the diff yet as its doewnloaded)
<apw> smb, that bit referes to editing your grub line at boot time, you know how it has set gfxpayload=$linux_gfx_payload or very similar, you change that to =text to disable handoff but let grub handle fiddling with the options to the kernel
<apw> smb, instead of the more normal needing to do =text _and_ remove vt.handoff 
<apw> smb, nice side effect of these patches is that we only need to change =text any time we want to disable handoff, so the instructions are simpler
<apw> smb, making any sense??
<smb> Ah ok... probably what would be there if grub defaults had console...
<apw> right, if we had correctly told it graphics don't work it would be already =text, so that line would do the right thing for us
<apw> but its stupidly trying to load the graphics drivers, when it can't open the disk to find them
<smb> Confusingly there once was a "text" as kernel/upstart argument...
<apw> smb, still is, as i found when i was testing :)
<apw> when X all broke and i was really confused, cause i was using $gfxpayload on the command line :)
<smb> Yes, there also is a message shortly visible about not being able to set graphics
<smb> heh
<apw> right and that'd go away if we'd corectly told it not to try that
<apw> so fix 3 will be to insert something something to stop it for encrypted disks
 * apw get tea
 * smb resists to obey
<smb> apw, OK, so with gfxpayload=text, I see the booting commandlist (in a smaller than normal 80x25 font), then the slpash which asks for the passphrase. connot set videomode is gone as expected
<apw> smb, so it does the right thing basically ?
<apw> and can you paste me the /proc/cmdline output
<smb> OOT_IMAGE=/vmlinuz-3.2.0-22-generic root=/dev/mapper/eddie-root ro quiet splash vt.handoff=7 vt.handoff_enable=text
 * henrix will be off for ~30mins
<smb> apw, Anything else I should try or look up?
<tseliot> apw: no, sorry, not yet, but I'll let you know
<apw> smb, i want to just confirm i've done it all right and if so we're good else i may have a second round
<apw> smb, so if it can stay in that shape for the min that'd be handy
<smb> apw, It can be left that stage. Just wanted to be sure you don't need anything else off it or done right now
<apw> no that confirmation is great
<tgardner> henrix, did you pin down that regression in Oneiric for sure? I'm thinking we likely need the same patch in Precise.
<tgardner> herton, did you pin down that regression in Oneiric for sure? I'm thinking we likely need the same patch in Precise.
<herton> tgardner, in one of the other bugs the reporter said the fix didn't work for him, so I'm not sure now if that patch fixes things. Is a good fix to have anyway
<tgardner> herton, do you trust the reporter  ?
<herton> tgardner, heh not sure, bug 972285 the guy just said it didn't work for him. I just installed a i386 oneiric here, will see if I reproduce
<ubot2> Launchpad bug 972285 in linux "segmentation fault when start on linux 3.0.0-18-generic" [Medium,Confirmed] https://launchpad.net/bugs/972285
<herton> tgardner, ok, I'm able to reproduce here, just installing -18 kernel. it's not the epoll issue, I'll have to investigate more (bisect etc.)
<tgardner> herton, do you suppose there is more then one regression ?
<herton> tgardner, may be, since in one of the bug reports someone said the epoll fix was ok (fixed his problem)
<tgardner> herton, or he just rebooted and the problem went away. I think on these kinds of issues the reporter needs to go back and forth a couple of times on the different kernels.
<herton> yeah, and the epoll thing shouldn't be causing this crashes, it makes more sense now
<herton> *these
<janimo> apw, do you keep kernel meta packages under git too?
<apw> janimo, yes
<henrix> herton: i built a kernel without the epoll patch, instead of adding the fix
<janimo> thanks
<henrix> herton: would you want to try that?
<apw> janimo, i think we are holding linux-meta right now in view of a possible regression, ogasawara is looking at it
<henrix> herton: there are more reporters on bug #972821 stating the previous kernel didn't fix the issue
<ubot2> Launchpad bug 972821 in linux "[oneiric-proposed] linux-image-3.0.0-18-generic makes apport-gtk and chromium-browser segfault on startup" [High,Confirmed] https://launchpad.net/bugs/972821
 * ogasawara just got in and is catching up on things
<janimo> apw, I was just wondering how useful having meta in VCS is given it is mostly changelog diffs among versions (at least with the simple kernel source I worked with)
<herton> henrix, sure, I can check, but I don't think it'll change anything, should be another issue, I'm investigating now that I reproduce here
<apw> janimo, it about it being the same, else one has to use bzr for meta and git for the kernel source and one tends to destroy things 
<henrix> herton: have you checked strace output?
<henrix> herton: take a look at https://lists.ubuntu.com/archives/ubuntu-users/2012-April/258939.html
<henrix> herton: one of the logs seems to point to epoll_wait()
<herton> henrix, strace stops on poll here as well like he says
<henrix> herton: interesting
<herton> but I'm not sure this is related to the problem
 * apw runs an errand
<dileks> http://nopaste.snit.ch/128636
<dileks> are those meta-generic packages not JIT? /me installed -22
<janimo> apw, and for meta packages the revision number needs to match the image package revision number it is supposed to depend on right?
<janimo> so not an upload count for the meta as the upload counts for the two packages can get out of sync
<apw> janimo, right the first bits have to match the version of the depa
<apw> depndant binaries, the uploads cycle as they wish
<dileks> I personally dont understand why you ubuntu kernel guys bump two versions at one time: for example for -22 its .35
<dileks> for -21 it was .34
<apw> dileks, ?
<janimo> dileks, I recently learned it is the upload count during a release cycle
<janimo> regardless of version, so version and upload count increase independently
<dileks> my first kernel was with precise-beta1: 3.2.0-17.27
<tgardner> janimo, we use the upload count as a minor version within an ABI series
<apw> and every upload has to have a different version number thats the debian law
<janimo> tgardner, right. Until a few days ago I though (and did so for ac100) the minor version is set to 1 on each ABI bump
<janimo> whereas I learned it is monotonically increasing across bumps
<tgardner> janactually, that works as well since its the ABI number that takes lexicographical precedence
<dileks> I manually installed... 3.2.0-20.33 and 3.2.0-21.34
<janimo> so I thought kernels use 3.2.0-1000.1 then 1000.2 then with the ABI bump 1001.1 again
<tgardner> janimo, there is nothing wrong with that
<janimo> tgardner, was told the policy is to have the last number reflect the absolute number of uploads, which is fine too, was just news to me :)
<tgardner> janimo, its not policy per se, its just the way we've been doing it.
<janimo> tgardner, so there is no ubuntu/canonical/oem wide policy? There should be imo to avoid confusion
<janimo> the two approaches seem both good enough
<apw> all kernels shold follow our lead as far as i know
<tgardner> janimo, the only policy is the debian version numbering rules
<janimo> ok
 * apw really makes it out the door
 * tgardner has to reboot for updates
<joumetal> hi. i bisected boot regression in mainline kernel 4a3d2d9bfb3b594b6e1f2b7eabfaf4e820a18c0e
<dileks> for me it seems to be +1 for both: 3.2.0-$prev1+1.$prev2+1. so why do you bump both versions? 3.2.0-20.1 would be enough. even -20 would be enough. I only want to understand for what both versions stand for.
<dileks> hmm, abi change
 * dileks sshs into his i386/sid system
<dileks> ii  linux-image-3.2.0-2-rt-686-pae       3.2.13-1                        Linux 3.2 for modern PCs, PREEMPT_RT
<dileks> hmm, upload count #. anyway :-)
<joumetal> is it better to report this upstream bug to launchpad an forward it or report it to kernel.org bugzilla?
<janimo> apw, do you use git-buildpackage or something else to build sources for the metapackages?
 * ppisati -> restart pulse, stuttering audio
<ogasawara> joumetal: if you've bisected the regression to an upstream commit, I'd report it upstream first.  you can then open a secondary report in launchpad track the upstream status.
<tgardner> janimo, are you looking at ubuntu-precise-meta.git ? Use 'make binary' or 'make source'
<joumetal> ogasawara: I report it. it's perf tools: Adjust make rules. What component, Other?
<ogasawara> joumetal: sure
<ogasawara> joumetal: the commit you referenced looks like it was included as of v3.4-rc1, you may just want to report it to LKML
<joumetal> ogasawara: should I cc someone based on this commit?
<ogasawara> joumetal: I suspect the patch author would be good
<joumetal> ogasawara: thanks
<tgardner> ogasawara, did you notice gcc was uploaded ?
<ogasawara> tgardner: I did
<tgardner> ogasawara, I don't think it'll impact us
<ogasawara> tgardner: hopefully not
<ogasawara> tgardner: might be cutting it close though, but I'm sure the release team will give approval
<ogasawara> tgardner: but I guess this gives us an opportunity to squeeze in any last minute fixes without having to jump through the SRU hoops
<tgardner> ogasawara, well, I think we've gotta wait until henrix and herton figure out this regression on oneiric as it may well impact precise
<ogasawara> tgardner: indeed
<ogasawara> skaet: just a heads up, gcc was just uploaded.  I'm hoping/assuming it should finish building in time for us to rebuild the kernel in time for freeze tomorrow.
<skaet> ogasawara,  thanks for the head's up.
<ogasawara> skaet: did we have a specific time of day kernel freeze would take affect?
<skaet> ogasawara, 2100 UTC 
<ogasawara> skaet: ack, thanks
<skaet> n/p
<bjf> ogasawara: not sure you saw the comment in the backtrace but someone was saying that bug 570542 has not been fully fixed though it is "Fix Released"
<ubot2> Launchpad bug 570542 in linux "linux-image-virtual does not include ahci module, prevents virtualbox from booting an Ubuntu guest" [Medium,Fix released] https://launchpad.net/bugs/570542
<ogasawara> bjf: was just looking at that.  it's fixed in precise since the module is built in.  I'll do the SRU for previous releases to include libahci
<bjf> ogasawara: mostly cared about Precise :-)
 * ogasawara back in 20
<ashif> hi
<ashif> im new here
<jsalisbury> bjf, henrix, herton A couple more regressions in 3.0.0-18: bug 973111 bug 973444
<ubot2> Launchpad bug 973111 in linux "System fails to boot after installing linux-image-3.0.0-18-generic" [High,Confirmed] https://launchpad.net/bugs/973111
<ubot2> Launchpad bug 973444 in linux "can't boot into kernel 3.0.0-18" [High,Confirmed] https://launchpad.net/bugs/973444
<bjf> jsalisbury: yup, we spotted those
<jsalisbury> bjf, cool, thanks.
<bjf> jsalisbury: np, keep em coming
<ashif> kernel programming ?
<apw> people say the darndest things
<herton> ok, the bisect to these general protection faults with chromium etc. points to commit "i387: do not preload FPU state at task switch time" on 3.0.0 stable
<herton> I tested precise i386 kernel, and precise doesn't show the issue I reproduce here with oneiric i386 from proposed
<herton> bjf, henrix ^
<tgardner> herton, that kind of makes sense.
<ohsix> do you know what they mean by preload in that message? from what i know of the fpu it's not familiar to me
<ohsix> also i don't think they mean restore, or they'd have said that
<herton> yeah, especially as we are seeing this only on i386
<bjf> herton, is there a subsiquent patch that 3.0 didn't get that 3.2 did ?
<herton> bjf, good question, may be we miss something on 3.0 indeed
<henrix> bjf: not that i could find it
<henrix> bjf: but still looking
<tgardner> herton, henrix: the i386 FPU patches were supposed to have address a bug that has existed for awhile, but were only recently uncovered. it could be that the backport isn't correct.
<tgardner> or is not needed
<herton> yes, the bisect point to the middle of the i387 series, mostly likely is a backport problem
<herton> *most
<tgardner> herton, how are you reproducing ? 'strace chromium-browser' ?
<herton> tgardner, just running chromium, I get segmentation faults after some browsing or in random places, sometimes even lightdm/gnome-session crash on login, before doing anything else
<herton> strace/gdb didn't help much
 * herton -> lunch
<tgardner> herton, I think my reproducer isn't reliable. my bisect ended on 'xhci: Fix oops caused by more USB2 ports than USB3 ports.'
<herton> tgardner, I think is a problem in backport of i387 changes, but as my bisect ended in the middle of i387 changes, it may not be a problem specific on that commit
<ogasawara> tgardner, herton: so I'm not going to wait on any patches to upload precise to rebuild against the new gcc upload.  I'm thinking we'll have another upload next week anyways (just under our SRU policy)
<tgardner> herton, I'll rewind to 'i387: re-introduce FPU state preloading at context switch time' and try that
<bjf> herton, lets get some test kernels built and spam those bugs for testing
<apw> tgardner, i wonder if you need CPUs which support like aesni or similar before you trigger the need
<tgardner> apw, possibly, though I was able to get it lock in poll() several times. perhaps a new bug ?
<apw> gawd
<apw> its all going to hell
<ogasawara> tgardner: you were testing on precise?  or oneiric?
<tgardner> ogasawara, oneiric
<henrix> fwiw, i wasn't able to reproduced on kvm, running oneiric i386
<tgardner> apw: model name	: Intel(R) Core(TM)2 Duo CPU     E6850  @ 3.00GHz
<apw> tgardner, that sounds like a proper cpu, so likely has most things
<tgardner> herton, immediate seg fault with the FPU patches. I'll try next without
<herton> back
<herton> tgardner, ok
<herton> bjf, yeah I'll put a kernel somewhere without the patch/patches, lets see
<tgardner> herton, much more stable without the FPU patches
<henrix> there are a few commits upstream related with fpu, but it would take same time to actually understand if they would solve the prob
<henrix> the commits are 7e16838, 80ab6f1 and cea20ca
<tgardner> I'm not convinced we ever had an FPU state problem in 3.0
<henrix> oh, and there is also a SAUCE on oneiric (but not on precise) that may mess things up: 775e6e802597c3f6c334cdaaf8df807dd28c6dd6
<tgardner> henrix, IIRC the NX emulation code doesn't change CPU FPU regsiters
<henrix> tgardner: maybe not, but it looks like it touches the same source code
<herton> tgardner, ok so here is a strange thing. Our commit 1d43fea348a44815c01c5fbd7cf3d29b7b13078d on ubuntu-oneiric, removes one hunk from ubuntu nx-emu changes
<herton> +       if (next_p->mm)
<herton> +               load_user_cs_desc(cpu, next_p->mm);
<henrix> herton: yep, i was looking at that one
<tgardner> so lets try a kernel without 775e6e802597c3f6c334cdaaf8df807dd28c6dd6 but with the FPU patches ?
<henrix> or with both, but with the FPU refactored to *not* remove the NX-emul code pointed out by herton...
<tgardner> henrix, right, we'll have to revert 775e6e802597c3f6c334cdaaf8df807dd28c6dd6, then reapply the FPU patches
<herton> yes, I think it's worth to look at, 3.0 stable doesn't remove that hunk as well, as they don't have it. That also may explain why upstream isn't having these issues, at least didn't found reports about it
<henrix> herton: do you want me to build the test kernel, or you're already on it?
<herton> I'm going to build here a stock -18 first just with the missing hunk added back again, if that fails then remove the patches
<henrix> herton: ack
<tgardner> herton, while thats building, have a look at precise to make sure we don't have the same problem.
<herton> tgardner, ack
<henrix> tgardner: precise does not seem to have the NX emul patch
<henrix> tgardner: ignore my last comment...
<henrix> tgardner: it does have it, and it keeps that code
<tgardner> henrix, I have vague memories of doing the precise backport.
<herton> yes, precise is ok, it still kept that nx-emu change
<tgardner> ogasawara, ^^
<ogasawara> tgardner: ack, thanks.  I'm just gonna prep a no-change upload.   gcc is still going to take the majority of the day to build.  so apw will upload in the morning if needed.
<tgardner> ogasawara, yeah, looks like the poll() thing might have been a red herring
<apw> ogasawara, sounds good
<ogasawara> apw: infinity scored up the gcc builds for me, so I'm hoping I might be able to upload before I go to bed tonight.
<ogasawara> apw: I'll email you if I do
<apw> ogasawara, i will simply check and see if there has been an upload, if not, i'll do it
<herton> tgardner, http://people.canonical.com/~herton/fpu_bug/ , if you want to test too, also put there the patch on top of -18 that I applied
<tgardner> herton, ack
<tgardner> herton, seems pretty good.
<herton> yeah, so far is going ok here as well
<tgardner> herton, damn, who'd of thunk setting the CS register was that important :)
<manjo> ogasawara, was seeing a bug where I have 4x4GB DIMs on a UEFI system and I was not able boot past grub, 3X4GB works, DIM in Channel A DIM1 causes boot to hang... bryceh told me there is some known fix for it ... you have any idea when we will get that fix ?
<ogasawara> manjo: hrm, no clue.  do you have any additional info, like a sha1 or commit message for the "fix"?
<manjo> ogasawara, no have not looked ... but bryceh was suggesting that there might be a known fix... thought I will ask before I dig
<ogasawara> manjo: you'll probably have dig as it's not ringing a bell here
<manjo> ok
<bryceh> manjo, sorry, bug 961482 was the one I ran into; it's already fixed
<ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Fix committed] https://launchpad.net/bugs/961482
<manjo> bryceh, np ... I am starting to dig into it now ... 
<manjo> bryceh, was worth a shot ... could have saved me some cycles
<manjo> :) 
 * tgardner -> EOD
<martinphone> hi
<martinphone> can you explain why the sudden change from current 3.0.0.18 to 3.2?
<martinphone> when 12.04 is released I mean
<martinphone> Where is 3.1?
<JanC> martinphone: Ubuntu releases happen every 6 months, while kernel releases happen about every 3 months
<martinphone> JanC, then why does my machine update to 3.0.0.18 and not to a 3.1 something?
<JanC> so the kernel got 2 new releases between 11.10 & 12.04
<martinphone> by today's date it should be a 3.1, shouldnt it?
<JanC> once released you don't get new kernel versions (although I'm pretty sure your 3.0 kernel has some bugfixes backported from 3.1)
<martinphone> janc, certainly not for the sake of stability: 3.0.0.18 6 segfaults in a row forced me to go back to 3.0.0.17, the one in use now
<martinphone> incidentally
<JanC> martinphone: I hope you filed a regression bug report about that then
<martinphone> If I nuke my machine and do a fresh 12.04 install, how many kernels will be installed? just 3.2? some previous ones I can use in case the last ones are unstable?
<martinphone> JanC, im pretty sure another user I coincided with, who had the same problem, did that
<JanC> if you do a 12.04 install, it will have the 3.2 kernel that is on the install media
<bjf> martinphone: have you filed a bug on the -18 segfaults, we have several reports of similar issues
<martinphone> bjf, no, should I?
<martinphone> if you already have several....
<bjf> martinphone: yes because your's may in fact be different
<martinphone> link please, I have never done this before
<bjf> martinphone: is yours an i386 install ?
<martinphone> yes
<JanC> and finding the reason is easier if you see what all those affected have in common
<bjf> martinphone: i have a kernel for you to try, one sec.
<martinphone> bjf, no need, really, Im waiting for the stable relsease of 3.2
<martinphone> then ill nuke
<martinphone> bjf, and 3.0.0.17 is stable
<bjf> martinphone: it would help if you could try: http://people.canonical.com/~herton/fpu_bug/
<JanC> martinphone: but by testing you can help fixing things for other people
<martinphone> me? testing?
<martinphone> my craptop is not the best option
<JanC> "crap" is the best to test on  ;)
<martinphone> lol
<martinphone> with my level of computing i wouldnt be an asset
<bjf> martinphone: it's the reason regressions happen though, lack of testing on a wide variety of HW
<JanC> martinphone: just test if bjf's kernel fixes your segfaults
<martinphone> ok, downloading 35.2mb
<JanC> if it does work for you and several others, they can release that as a fix
<martinphone> i suddenly feel important
<JanC> if it doesn't fix things, they can throw it away instead  ;)
<JanC> martinphone: testers *are* important  âº
<JanC> and "crowdsourcing" is how open source gets testers!
<martinphone> yeah, Im the man :)
<JanC> also, think about it as contributing back (or "paying" for Ubuntu/linux)
<bjf> martinphone: look at http://pad.lv/973637 and see if that's similar to what you are seeing
<martinphone> bjf, very similar: I can actually start chromium, but it , eventually, will segfault
<bjf> martinphone: if so, you can click on the "affects me" link
<bjf> martinphone: after testing, add a comment at the bottom if it helped or not
<martinphone> im only accepting cause in 3 weeks ill nuke this thing
<martinphone> brb
<martinphone> segfault
<martinphone> back int 3.0.0.17
<bjf> martinphone: thanks for testing
<martinphone> meh
<JanC> martinphone: don't "meh", even failed tests are important
<martinphone> if you say so...
<JanC> martinphone: they are sometimes more important than successful ones  âº
<martinphone> what do you use to insert those plain emoticons JanC Â¿
<martinphone> ?
<JanC> xchat has a feature that allows replacing text, so I let it replace ":)" with âº
<JanC> but that's off-topic here
<martinphone> offtopic, you mean you will kick me out if I keep asking about it?
<JanC> martinphone: I can't kick you out, but I just meant that we shouldn't keep discussing xchat/unicode features here (it's not kernel-related)
<JanC> so feel free to PM me or something (although it's 23h15 here, so I'll be off to bed probably ;) )
<martinphone> JanC, are you in windows?
<JanC> martinphone: if you mean MS Windows, no (I have no computers with that OS)
<JanC> anyway, off to bed...
<martinphone> JanC, in xchat they told me that the function you are using is only for windows
<martinphone> nite nite
<slangasek> ogasawara: bug #919281 is a packaging bug that it's rather important to have fixed for 12.04.0; can that be squeezed into the next upload?
<ubot2> Launchpad bug 919281 in linux "devmapper kernel modules missing from precise server cd" [Critical,Triaged] https://launchpad.net/bugs/919281
<atpa8a> hello
<atpa8a> filed the bug 972960...
<ubot2> Launchpad bug 972960 in linux "md fails during install [kernel BUG at /build/buildd/linux-3.2.0/drivers/md/md.c:6920!]" [High,Confirmed] https://launchpad.net/bugs/972960
<atpa8a> seems like it's what (as i understand it) is external metadata with one of my dmraid arrays
#ubuntu-kernel 2012-04-05
<beata|lemur> I suspect that disabling SMP support causes the Precise kernel to fail to build; I'm doing a verification (and a grocery run) before gathering details.
<beata|lemur> Okay, it is. Compiling a 3.2.0-21 kernel with SMP support disabled results in a build failure. Attempting to submit a bug report..fighting python. :(
<ogasawara> slangasek: I'll get that fixed. however, we weren't planning any additional uploads before kernel freeze tomorrow (we'd wait for gcc to finish building before uploading anyways), but I'm almost certain we'll have some last minute must fix patches needing to get uploaded (this being one of them) so I'll make sure it's included and makes the release.
<slangasek> ogasawara: ok, thanks
<slangasek> ogasawara: ETA ~3h for gcc, fwiw
 * smb mornings
<ppisati> moin
 * ppisati -> reboot
 * ppisati -> lunch
<tgardner> henrix, jsalisbury: rebooting tangerine for kernel update
<henrix> tgardner: ack
<jsalisbury> tgardner, ack
<martinphone> hi
<martinphone> any new 3.0.0.18 for testing?
<tgardner> martinphone, likely not until tomorrow
<tgardner> herton, ^^
<martinphone> tgardner, are you disregarding 3.0 versions now that you are going to release 3.2?
<herton> martinphone, can you give us dmesg of booted kernel from http://people.canonical.com/~herton/fpu_bug/
<tgardner> martinphone, of course not. Oneiric is supported for 18 months
<martinphone> herton, I already tried that one yesterday
<martinphone> segfault on chromium startup
<herton> martinphone, dmesg of that kernel please
<martinphone> herton, I dont know what a dmesg is
<martinphone> herton, terminal output?
<herton> martinphone, you boot that kernel, login, open a terminal, type "dmesg > output.txt", then go to pastebin.ubuntu.com and paste the contents of output.txt file
<martinphone> ok
<martinphone> brb then
<herton> probably we will respin oneiric today or tomorrow, there is another regression we have, different from the nx-emu crashes (bugs 973111, 973444)
<ubot2> Launchpad bug 973111 in linux "System fails to boot after installing linux-image-3.0.0-18-generic" [High,Confirmed] https://launchpad.net/bugs/973111
<ubot2> Launchpad bug 973444 in linux "can't boot into kernel 3.0.0-18" [High,Confirmed] https://launchpad.net/bugs/973444
<martinphone> http://paste.ubuntu.com/916052/
<martinphone> I dont need to execute that while chromium is loaded, do I?
<henrix> herton: ^
<henrix> herton: have you changed the sign of the fpu_bug kernel? or is it the same as the 3.0.0-18.31-generic?
<herton> martinphone, from the beginning of your dmesg, you booted from the wrong kernel, it's not the one from http://people.canonical.com/~herton/fpu_bug/
<martinphone> thats the only 3.0.0.18 I have
<herton> martinphone, how did you install the deb from the link above? you can do "sudo dpkg -i linux-image-3.0.0-18-generic_3.0.0-18.31_i386.deb" to install it from the terminal
<herton> it'll replace your current 3.0.0-18
<martinphone> herton, somebody here pasted that, I donwloaded the .deb and executed it from file manager
<herton> martinphone, try the sudo dpkg -i from a terminal and reboot
<martinphone> linux-image-3.0.0-18-generic_3.0.0-18.31_i386
<martinphone> dpkg: error: --install needs at least one package archive file argument
<herton> martinphone, what's exactly the command you used, you need the file on the same directory you downloaded the deb above
<martinphone> i understand
<martinphone> herton: the .deb is in the "downloads" directory. I have cd'ed to it and executed "sudo dpkg -i", i still get "dpkg: error: --install needs at least one package archive file argument"
<herton> martinphone, did you type "sudo dpkg -i linux-image-3.0.0-18-generic_3.0.0-18.31_i386.deb"
<tgardner> martinphone, "sudo dpkg -i linux-image-3.0.0-18-generic_3.0.0-18.31_i386.deb"
<martinphone> herton, please keep in mind that im a noob, please paste full commands
<martinphone> its working
<martinphone> brb
<tgardner> apw, grub2 1.99-21ubuntu2 doesn't fix the encrypted LVM issue on my test box
<martinphone> what about now? http://paste.ubuntu.com/916071/
<martinphone> herton, >
<herton> martinphone, yes that looks the right kernel, keep us posted if you see any issues
<martinphone> wait, so yesterday I didnt install it...
<jsalisbury> herton, bjf, henrix One more 3.0.0-18 regression: bug 974268
<ubot2> Launchpad bug 974268 in linux "multiple crashes after kernel update to 3.0.0-18" [High,Incomplete] https://launchpad.net/bugs/974268
 * ogasawara back in 20
<bjf> jsalisbury: ack
<tgardner> bjf, that one could easily be the FPU bug. needs logs
<bjf> tgardner: ack
<gema> jjohansen: regarding your bug
<jjohansen> gema: the new one?
<gema> jjohansen: bug 974404 is a duplicate of bug 966294
<ubot2> Launchpad bug 974404 in ubiquity "installation of precise beta2 always fails" [Undecided,New] https://launchpad.net/bugs/974404
<ubot2> Launchpad bug 966294 in gstreamer0.10 "Ubiquity loops forever from ubiquity_webcam_play" [High,Confirmed] https://launchpad.net/bugs/966294
<gema> jjohansen: not new
<jjohansen> gema: ah okay
<gema> jjohansen: removing the python script for the camera makes the install to work
<gema> or using alternate
 * jjohansen was monitoring to see if /me could trace it farther, but it seems to be more than that as I am getting hard locks
<gema> jjohansen: I went down the route of all that tracing during beta, you can see it in the bug
<jjohansen> gema: okay, I will give that a try
<gema> jjohansen: avoid OEM, that one is cursed until they remove the camera script or fix the problem
<jsalisbury> bjf, herton, henrix one more: bug 974421
<ubot2> Launchpad bug 974421 in linux "User applications randomly segfault" [High,Confirmed] https://launchpad.net/bugs/974421
<tgardner> jsalisbury, its an i386, so is a like duplicate of the FPU bug
<tgardner> likely*
<jsalisbury> tgardner, thanks, I'll mark it as such
 * ogasawara lunch
 * tgardner -> EOD
<martinphone> is the last 3.0.0.18 fully xubuntu compatible? parole (media player) just segfaulted 3 times. Opened from terminal is stable
<martinphone> another segfault
<martinphone> reverting to 3.0.0.17
<jsalisbury> martinphone, That is a good idea.  There is a known issue with 3.0.0-18 that causes similar issues to what you are seeing.
<martinphone> jsalisbury, will that be solved with tomorrow's re release?
<martinphone> I mean, chromium doesnt segfault anymore
<jsalisbury> martinphone, possibly
<jsalisbury> martinphone, have a look at bug 972821  There is a test kernel available.
<ubot2> Launchpad bug 972821 in linux "[oneiric-proposed] linux-image-3.0.0-18-generic makes apport-gtk and chromium-browser segfault on startup" [High,Confirmed] https://launchpad.net/bugs/972821
<herton> jsalisbury, he installed the test kernel this morning
<jsalisbury> herton, ah, ok.
<herton> oh he left
<herton> martinphone, probably you media player issue is a new problem, and may be not related to the kernel
<martinphone> herton, im back into 3.0.0.17 and parole doesnt segfaul anymore, coincidence?
<martinphone> segfault*
<sidd_mak>  which processor family to choose in make menuconfig while compiling kernel for my 32bit centrion processor T2050??
<ayan> Is there a recent Ubuntu/SystemTap guide?
<ayan> i installed a kernel along with debugging symbols but stap isn't able to resolve the names of any of the probe points i try.
<vanhoof> ayan: give ppetraki a ping
<vanhoof> ayan: think he has something written up somewhere
<ayan> vanhoof: i did.  he's /away.
<ayan> but i'll wait.
 * ayan calls it a day.
#ubuntu-kernel 2012-04-06
<_ruben> guys, do you have some doc describing how to create/build/maintain your own kernel flavour (i'm looking at creating -server variant which includes the scst patches (scst.sf.net))?
<vwj> hey guys I have a question about how to create a bug ticket against the latest precise kernel (linux-image-3.2.0-22-generic) which generates a oops during startup if the machine is used as a XEN host
<vwj> the problem has been confirmed on the kernel mailing list (http://www.spinics.net/lists/kernel/msg1321449.html) and if I intsall linux-image-3.2.13-030213-generic which is older then the current stock kernel the problem is not there
<vwj> note that the issue is introduced in kernel 3.2.14 which is possibly the base for the stock precise kernel
<ppisati> moin
 * ppisati -> back in ~10
<luc4> Hi! Anyone who noticed crashes of various applications with the last released kernel?
<luc4> Hi! Anyone who noticed crashes of various applications with the last released kernel?
<bjf> luc4, if you are talking about oneiric, then yes, we have a new kernel that is about to go into -proposed
<luc4> bjf: yes, oneiric 3.0.0-18. Everything is segfaulting with that. Now I switched back to 3.0.0-16 and it seems to be ok so far.
<bjf> luc4: ok, a new one should be available shortly
<luc4> bjf: thank you very much!
 * ppisati -> rush out for an errand, be right back
<ppetraki> vanhoof, ayan: got ayan's ping, answered him privately. My wiki is pretty good, could stand to be integrated into the public wiki/debugging section
<bjf> ppetraki: a link from somewhere in the wiki.ubuntu.com/Kernel briar patch would be good
<Amoz> ogasawara :)
<ogasawara> \o/
<jsalisbury> Amoz, o/
<ogasawara> jsalisbury: Amoz has informed me they are interested in helping with the kernel...I thought a good place to start is triage work to get a feel for the workflow etc.
<jsalisbury> Amoz, triage is a great place to start, and we can always use the help :-D
<Amoz> i always find it hard starting out triaging stuff though
<ogasawara> jsalisbury: I was hoping you could maybe help point him in the right direction to get started
<jsalisbury> ogasawara, sure thing.
<jsalisbury> Amoz, This is a great first place to start: https://wiki.ubuntu.com/Kernel/BugTriage
<jsalisbury> Amoz, There are some good pages there, but some may be out of date.
<ogasawara> Amoz: there is also pretty good info off of wiki.ubuntu.com/Kernel for development too if that interests you more...
<ogasawara> Amoz: or even testing is helpful, eg testing of -proposed kernels
<Amoz> ogasawara, that I can do!
<Amoz> I think I've read the kernel triaging stuff before
<Amoz> it still feels like a hard thing to do.. the triaging I mean
<Amoz> one can't learn to triage kernel bugs just by reading some docs, right?
<jsalisbury> Amoz, we're always here to help and answer questions.
<ppetraki> bjf, ayan, vanhoof: https://wiki.ubuntu.com/Kernel/Systemtap , lets have some fun :)
<Amoz> that will be a million of questions then jsalisbury 
<jsalisbury> Amoz, by testing, you may come across new bugs.  That can be a good start into triaging
<ogasawara> Amoz: there's a general process, but there are always deviations
<ogasawara> jsalisbury: +1 on that
<Amoz> yeah I need to start somewhere, I guess
<martinphone> any new 3.0.0.18 that doesnt segfault my xubuntu installation when I load parole (media player)?
<jsalisbury> Amoz, If you test and find a new bug, I can guide you through the triage process.  That will help you see the full process.
<Amoz> jsalisbury, that'd be great. so for testing proposed kernels on precise, I'll just change a source ?
<Amoz> in sources.lists
<jsalisbury> Amoz, There is a wiki on how to do it.  Let me find it.
<Amoz> I think I found it jsalisbury 
<jsalisbury> Amoz, cool
<Amoz> but it's applicable on precise as well?
<Amoz> even though it's in development phase
<jsalisbury> Amoz, well not really for precise, since the latest kernel is always similar to proposed for stable kernels
<jsalisbury> Amoz, just running the latest precise kernel, and applying updates regularly is a great way to test.
<Amoz> great
<jsalisbury> Amoz, I think there is a list of test cases on the QA wiki.  I'll take a look.
<jsalisbury> Amoz, here is a wiki if your looking for specific test cases to try while running the -proposed or latest development kernels:
<jsalisbury> Amoz, http://testcases.qa.ubuntu.com/
<Amoz> jsalisbury, my Asus u36sd doesn't hibernate/sleep because of some usb3 bug. Is it worth reporting? or is it the manufacturer's fault (driver etc.) ?
<jsalisbury> Amoz, absolutely 
<Amoz> jsalisbury, there's a fix documented here https://help.ubuntu.com/community/Asus_U36SD
<Amoz> jsalisbury, is that possible to get working OOTB?
<jsalisbury> Amoz, possibly.  The first thing to do would be to open a kernel bug.  We can then see if the bug also exists upstream.  If it does, we can open an upstream bug.  If the bug is fixed upstream, we can look at getting it pulled into Precise.
<jsalisbury> Amoz, The first step is to open a bug in launchpad
<Amoz> I'll check if it is
<dileks> hi
<Amoz> jsalisbury, is this where all kernel bugs are? v
<Amoz> https://bugs.launchpad.net/ubuntu/+source/linux
<dileks> drm/i915: suspend fbdev device around suspend/hibernate
<dileks> is that included in latest precise-kernel?
<jsalisbury> Amoz, yes that is all the open bugs
<dileks> http://thread.gmane.org/gmane.linux.kernel/1274203
<Amoz> jsalisbury, should I try to get a strace or something of the crash?
<jsalisbury> Amoz, the first step would be to open a new bug with: apport-collect linux
<jsalisbury> Amoz, That will collect a good amount of logs and debug information to get started.  Based off that, we can see what additional data is needed.
<Amoz> jsalisbury, I see. thanks :)
<jsalisbury> np
<Sarvatt> dileks: yep its in 3.2.0-22.35
<dileks> Sarvatt: OK, thanks. lemme check kernel here
<Amoz> jsalisbury, bug filed :)
<beata> Hm. I checked out Ubuntu-3.2.0-22.35 just a moment ago; it has debian.master/abi/3.2.0-21.34/
#ubuntu-kernel 2012-04-07
<Guest11589> hello
<Guest11589> Could someone please enable DVB_USB_AZ6007 for /~kernel-ppa/mainline/v3.4-rc1-precise
<Guest11589> I'd happily be advised on how to do that on my own, though.
<Guest11589> I guess something like loading like loading vanilla source (linux-3.4-rc1.tar.bz2), patching in 0001-base-packaging.patch, 0002-debian-changelog.patch, 0003-default-configs.patch, make oldconfig && make menuconfig
<Guest11589> finally make modules && make modules_install
<Guest11589> Did I miss something?
<martinphone> is 3.0.0.19 stable?
<Guest11589> Why don't have a stop at kernel.org?
<martinphone> no segfaults fo far with 0.19
<apw> beata, that is correct; the abi in the source tree is the abi for the previous version
<beata> apw: Thanks; that threw me when I saw it.
#ubuntu-kernel 2012-04-08
<doa> anyone ever compiled a kind of microkernel  called  l4ka?
<doa> http://www.l4ka.org/120.php
<doa> hi
#ubuntu-kernel 2013-04-01
<nooooo> hi
<nooooo> my laptop gets hot and loud in xubuntu but not in win
<nooooo> when i pull the electric cable off its getting cooler and more silent
<nooooo> how to use the battery-powered mode with the dc cable connected?
<zequence> nooooo: Sounds like at least the monitor gets dimmed when you pull the plug
<nooooo> uname -r 3.2.0-39-generic
<nooooo> :) 
<nooooo> no the monitor stays as it is
<nooooo> the fan is immediately slower, more silent and the whole laptop cooler
<nooooo> i was reading and trying a lot about bios bug, kernel versions ect
<nooooo> i think the easiest fix would be this dc cable in out thing
<nooooo> how to use the battery-powered settings for dc-powered too?
<zequence> I don't know what your battery powered settings are. This is more of a user question. You would probably have more luck on #ubuntu or #xubuntu
<zequence> at least, that's my best guess
<nooooo> zequence: ok thank you
<nooooo> u dont have any idea what to do else?
<zequence> Nope, sorry. I'm not that good with laptops
<nooooo> okidoki thanks anyway!
<nooooo> bye
 * henrix -> lunch
<rtg_> sforshee, your EFI_VARS_PSTORE patch got merged in 3.9-rc5
<ogasawara> rtg_: just fyi, I pushed a small cherry-pick from linux-next to raring master-next to add a haswell cpu id
<rtg_> ogasawara, hmm, I thought I remembered doing that last week.
<ogasawara> rtg_: hrm, it wasn't there when I looked.  maybe you forgot to push?
<rtg_> ogasawara, well, lemme look at the actual patch to see if it looks familiar
<rtg_> ogasawara, ok, I was dragging my feet on that one thinking it would soon get merged in 3.9.
<rtg_> sforshee, you're familiar with brcmsmac. perhaps you can advise jsalisbury re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1131914/comments/3
<ubot2`> Launchpad bug 1131914 in linux "[Regression] No wifi after suspend/resume" [Medium,In progress]
<sforshee> rtg_, ack, I'll take a look
<jsalisbury> rtg_, sforshee, thanks.  I pinged upstream and the patch author to get their feedback as well.
<sforshee> jsalisbury, we had to revert another commit related to bcm 4313iPA iirc
<jsalisbury> sforshee, ok
 * ogasawara back in 20
<sforshee> jsalisbury, you're sure it's that one and not b6fc28a158076ca2764edc9a6d1e1402f56e1c0c?
<sforshee> that's the one we've already reverted, and it's getting reverted upstream as well
<jsalisbury> sforshee, yeah, reverting it allowed wifi to work after a suspend/resume cycle.  The bug also occurs with v3.9-rc4. 
<jsalisbury> sforshee, I can try reverting b6fc28a158076ca2764edc9a6d1e1402f56e1c0c as a test, unless there is a kernel I can test where it already is reverted.
<sforshee> jsalisbury, Ubuntu-3.8.0-15.25 contains the revert
<sforshee> jsalisbury, the one you identified is mostly just rearranging code, but there is one small functional change that could be to blame
<jsalisbury> sforshee, I'm pretty sure the bug still happens on Ubuntu-3.8.0-15.25.  Let me give it a try.
<rtg_> jsalisbury, Linville just sent you an email on your revert request
<sforshee> rtg_, his question was the same as mine ;-)
<jsalisbury> rtg_, sforshee, ack.  I'm installing Ubuntu-3.8.0-15.25 now to see if it fixes the bug.  I'll also test 3.9-rc5.
<rtg_> jsalisbury, John says that revert is not yet in -rc5
<jsalisbury> rtg_, whoops, I didn't see that bold, hiightligted and under lined 'not' :-)
<rtg_> I thought not
<jsalisbury> rtg_, sforshee, I have a ton of test kernels on this machine that exhibits the bug, so I'm just doing a little clean up before testing.
<sforshee> jsalisbury, will you give me the contents of /sys/kernel/debug/brcmsmac/bcma0:0/hardware on that machine?
<jsalisbury> sforshee, sure
<jsalisbury_> sforshee, http://paste.ubuntu.com/5667582/
<jsalisbury> sforshee, installing Ubuntu-3.8.0-15.25 now, should know if it has the bug in about 5 minutes
<sforshee> jsalisbury, ack
<sforshee> jsalisbury, the commit your bisect identified looks like it should be a no-op for your wireless
<jsalisbury> sforshee, yeah, it looks like I reverted it against Ubuntu-3.8.0-15.25: linux-image-3.8.0-15-generic_3.8.0-15.25~lp1131914v1_amd64
<sforshee> heh
<jsalisbury> sforshee, so, I probably got the real fix, which is revering  b6fc28a15
<sforshee> sounds like it
<jsalisbury> perfect timing
<jsalisbury> sforshee, lol that is it.  The stock Ubuntu-3.8.0-15.25 kernel doesn't have the bug.  
<sforshee> jsalisbury, excellent. I love it when the bug is already fixed :-)
<jsalisbury> sforshee, rtg_, thanks for the help.  I'll respond to upstream and update the bug
<sforshee> jsalisbury, np
<rtg_> jsalisbury, please remember to annoy apw tomorrow about bug #1157952. He is most familiar with that driver, and I'd like to get it fixed before we go to press with 13.04
<ubot2`> Launchpad bug 1157952 in linux (Ubuntu Raring) "SCSI keysense errors on console with Raring (3.8 kernel) within Windows Azure" [High,In progress] https://launchpad.net/bugs/1157952
<jsalisbury> rtg_, will do
 * rtg_ -> lunch (whilst waiting for a phablet image to download and flash)
 * henrix -> EOD
<danjared> kamal: do you still have that XPS 13 handy?
<kamal> danjared: yes I do
 * ogra_ guesses thats something you dont give away quickly once you have your hands on it :)
<danjared> kamal: might you have a chance to look at this bug? https://bugs.launchpad.net/dell-sputnik/+bug/1162026
<ubot2`> Launchpad bug 1162026 in linux "backlight not adjustable after screen turns off and then back on" [Medium,Triaged]
<kamal> danjared: ok, yes, I see that problem also.  I've grabbed the bug, and will dig into it.
<danjared> kamal: thanks!
 * rtg_ -> EOD
<infinity> apw: Aaaaandyyy.  Are you going to sponsor zequence's SRU kernels?
<infinity> zequence: Assuming your current PPA kernels are entirely caught up with what's in proposed?
<zequence> infinity: I think they're allright, unless I'm missing something about the procedure. The bug automation was off this time
<infinity> zequence: Speaking of bugs, if someone finishes regression-testing https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1153652 I can release it, instead of just skipping it with your next upload.
<ubot2`> Launchpad bug 1153652 in kernel-sru-workflow "linux-lowlatency: 3.5.0-26.28 -proposed tracker" [Medium,In progress]
<zequence> infinity: booted and tested
#ubuntu-kernel 2013-04-02
<infinity> zequence: Danke.
<diwic> any feeling for 3.10 vs 3.11 for Ubuntu 13.10 ?
 * apw counts the hours till he has networking
 * smb hopes its a tock networking and not tick...
<apw> smb, heh ... me too
<aquarius> if my webcam has stopped working in latest raring, but was working in raring a week or two ago, which information do I need to attach to an LP bug to help narrow down the problem?
<ppisati> brb
<davmor2> aquarius: at a guess, ubuntu-bug linux, name/model of the webcam, roughly when it stopped working.
<davmor2> jsalisbury: morning,  Kernels installed 3.8.2 and 3.8.3 seemed to build efi bits but didn't work with secureboot, 3.8.4 didn't seem to create an efi entry.  I'm just checking the manifest of taday iso to see if it contains the new kernel version and updating the isos.  If it contains the new kernel I'll enable secureboot and see if works with the latest image.
 * henrix -> lunch
<aquarius> thanks davmor2. 
<aquarius> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1163268 filed about the webcam, anyway.
<ubot2`> Launchpad bug 1163268 in linux "Lenovo U300s webcam stopped working, somewhere around mid-March 2013" [Undecided,New]
<rtg_> jsalisbury, can you work with aquarius to find out when raring stopped working for him ?
<xnox> everytime I try to enable X.M.P. on my ram, I fail to boot =(
<xnox> (yet RAM, motherboard and cpu should all support it)
<rtg_> apw, have you had a look at bug #1157952 ?
<ubot2`> Launchpad bug 1157952 in linux (Ubuntu Raring) "SCSI keysense errors on console with Raring (3.8 kernel) within Windows Azure" [High,In progress] https://launchpad.net/bugs/1157952
<apw> rtg_, yep we are waiting on some input from utlemming, who has not reported on his testing
<apw> rtg_, i have poked him to let us know
<rtg_> apw, acl
<apw> rtg_, hopefully that patch is the nuts and we cna just apply it
<rtg_> apw, what about the side effects mentioned in comment 19 and 29 ?
<apw> rtg_, when ut is online i'll find out where we are at, this is a big mess
<rtg_> apw, ok. bbias.
<davmor2> jsalisbury: YAY!!!! My secureboot issue from last week with the new kernel build look like a thing of the past WooHoo!! Althought I'll just tripple check it before putting it in the bug report
<ogasawara> rtg_, apw: https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1155243
<ubot2`> Launchpad bug 1155243 in linux-armadaxp "Please remove linux-armadaxp and linux-meta-armadaxp from raring" [Undecided,New]
<ogasawara> rtg_, apw: that's just a matter of us not performing any additional uploads and pinging an archive admin to reap the existing package/binaries from the archive right?
<ogasawara> or am I missing anything else?
<rtg_> ogasawara, should be
<rtg_> ogasawara, it'll take an archive admin to do it. I think slangasek has the privs if we give the go ahead.
<ogasawara> rtg_: I'll notify Ike and respond to the bug
<apw> ogasawara, yeah thats my understanding
<davmor2> jsalisbury: Okay triple confirmed everything is running as nromal now with todays iso image.  I don't know what you want to do with the bug now
<rtg_> davmor2, what is the bug number ? I'll just mark it fix released
<davmor2> rtg_: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1161566
<ubot2`> Launchpad bug 1161566 in linux "Regression on enabling the system for secureboot" [High,Confirmed]
<hrw> hi
<hrw> drm_kms_helper: panic occurred, switching back to text console
<hrw> oops in ring_doorbell_for_acrive_rings+0xa8/0xd0
<hrw> 3.8.0-13/14/15/16 all OOPS
<diwic> any feeling for 3.10 vs 3.11 being used for Ubuntu 13.10 ?
<rtg_> diwic, I'm guessing 3.11
<rtg_> diwic, or, rather 3.10. I get a little dyslexic with version numbers.
<diwic> rtg_, ok, 3.10 merge window is not far away. Time to start thinking of what I want in there...
<rtg_> as always...
<hrw> btw - 3.9-rc5 from ~kernel-ppa are unusable
<diwic> rtg_, if this is also what's going to be used for 12.04.4 that means that the support for the next generation Intel ships (i e Broadwell) needs to be backported to 3.10, I suppose 
<hrw> can someone fix their kernel configs?
<apw> hrw, what is missing from the mainline builds ?
<hrw> apw: on my i7 I got lores framebuffer and no usb keyboard
<hrw> not able to login even to check what is going on
<apw> seems unlikley the usb config has changed much between raring and there, that it would be config
 * ogasawara back in 20
<ppisati> ogra_: ok so...
<ppisati> ogra_: i can get the ubuntu-nexus7 kernel to work on the phablet img
<ppisati> ogra_: except for the touchscreen
<ogra_> yay !
<ogra_> you rock
<ogra_> hmm
<ppisati> ogra_: do you have any idea where i should look for debug info?
<ogra_> logcat 
<ogra_> via adb
<ogra_> and it should still have dmesg indeed
<ppisati> ogra_: yeah it's there
<ppisati> ogra_: i see it picking up the elan driver
<ppisati> ogra_: fw, etcetc
<ppisati> ogra_: and initialization looks good
<ogra_> sounds about right
<ppisati> ogra_: but then it doesn't sense my finger
<ppisati> ogra_: display is working (time and date is updated)
<ogra_> you cant swipe the welcome screen to the left ?
<ppisati> ogra_: no
<ogra_> weird
<ppisati> adb works
<ppisati> wifi works
<ppisati> but withouth touch...
<ogra_> i wonder if thats has to do with arhmf vs armel 
<ogra_> the firmware is armel ... 
<ogra_> as the whole adnroid system is
<ppisati> ogra_: i think i compiled the phablet kernel with the armhf toolchain
<ppisati> ogra_: and iirc it was ok
<ppisati> ogra_: bt now i'm unsure...
<ogra_> it should be ok
<ogra_> usually the kernel is distinct enough
<ogra_> we have mixed like that in the past 
<ogra_> we also wont start building armel packages just for that :)
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> rtg_, aquarius, I posted some comments to  bug 1163268 to start the bisect process.
<ubot2`> Launchpad bug 1163268 in linux (Ubuntu) "Lenovo U300s webcam stopped working, somewhere around mid-March 2013" [Medium,Incomplete] https://launchpad.net/bugs/1163268
<aquarius> jsalisbury, thanks. I was worried you were going to say "hey, test a bunch of kernels when you don't really know what you're doing, Langridge" and indeed you have, but it is clearly the right thing to do, and I shall test :)
<jsalisbury> aquarius, :) thanks.  Once we know the first bad kernel version, we will have a bunch more kernels to test to identify the offending commit ;-)
<ppisati> ogra_: uhm no
<ppisati> ogra_: it works
<ogra_> heh
<ppisati> ogra_: it's really a config issue...
<ppisati> uffff
<ogra_> phew
<dobey> is http://kernel.ubuntu.com/git down for anyone else?
<rtg_> dobey, yeah, lemme hassle IS
<bjf> rtg_, i've been bugging them, 
<dobey> ah ok
<bjf> rtg_, not responsive
<dobey> i'm just trying to see if a couple patches are included in the raring kernel already
<bjf> dobey, do you have sha1 for them ?
<dobey> bjf: no, and i don't know if they've been committed upstream yet
<bjf> dobey, if you give me some pointers i can look in the git repo
<dobey> https://bugs.freedesktop.org/attachment.cgi?id=77018
<dobey> http://lists.freedesktop.org/archives/intel-gfx/2013-March/026247.html
<bjf> dobey, looking
<dobey> thanks
<dobey> suppose i could have just cloned and tried to patch
<bjf> dobey, it doesn't look like either of those are in raring at this time
<dobey> bjf: ok, thanks for looking. guess i'll see if i can't git clone, patch, and build a kernel to test them then. hopefully they apply cleanly :)
<dobey> is http://kernel.ubuntu.com/git/ubuntu/ubuntu-raring.git the right url?
<dobey> (to clone from)
<bjf> dobey, yes, though with the http issues we seem to be having right now that may be pretty slow
<rtg_> dobey, use git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
<dobey> yeah, that http url failed, and once the summary page actually loaded i saw the git url :)
<dobey> thanks
 * ppisati -> gym
<ppisati> later
<rtg_> ogra_, doko's rebuild test for raring failed on ti-omap4 which was synced from Quantal. Is it really necessary that I fix the build issue ? Can we drop this source package from raring ?
<ogra_> do you have a source package that builds ?
<ogra_> if so drop the other
<rtg_> ogra_, not for ti-omap4
<ogra_> but we need to have the source for the binary we ship in the archive 
<ogra_> (and if only for apt-get source)
<rtg_> ogra_, so what _are_ we shipping ? I mean, is there an installation image that depends on ti-omap4 ?
<ogra_> usually binaries that havent been built from an exosting source get removed by the archive admins
<ogra_> yeas, the desktop image does
<ogra_> talk to management if you want it dropped ...
<ogra_> i asked for dropping and then a decision was made to keep it with the old kernel version
<rtg_> ogra_, i.e. rick ? I really don't want to have to support ti-omap4
<ogra_> since we sent out too many of these boards to the community for dogfooding ... 
<ogra_> we wont "support" it
<ogra_> no security, no SRUs
<ogra_> but it needs to build once in raring to ship it and keep it in the archive
<rtg_> weill, I still have to put time into it in order to get it building again. I guess that is kind of support.
<ogra_> kind of, yes
<rtg_> I guess if the decision was made then I'd better just do it.
<ogra_> rtg_, looks to me like a "build_tools=false" is enough
<rtg_> ogra_, yeah, its simple enough fix
<ogra_> (and probably ripping the tools package out of the control file)
<ogra_> if people complain, send them my way 
<rtg_> or just send them away :)
<ogra_> that would be largely the same :)
 * ogra_ would just block his ears and sing lalala until they are done complaining :)
<rtg_> bjf, you'll never touch Quantal ti-omap4 again, right ?
<bjf> rtg, correct
<bjf> rtg, what are we running on buildds ?
<ogra_> good question
<ogra_> infinity, ^^^
<bjf> infinity, what ti-omap kernel are we using on buildds ?
<ogra_> what are the pandas using underneath 
<rtg_> bjf, ok, I'm gonna upload into raring with just a minor version bump (and the compile fix). we'll also _never_ touch ti-omap4 in raring either.
<rtg_> likely precise
<infinity> bjf: precise.
<ogra_> yeah
<bjf> rtg, ok, so all other ti-omap are dead to me
<rtg_> good
<infinity> rtg_: Wait, why are we uploading ti-omap4 to raring?
<bjf> ppisati, ^
<rtg_> infinity, rebuild failure from doko
<ogra_> infinity, to not have it in NBS
<infinity> rtg_: Ignore that FTBFS.
<infinity> rtg_: It's a direct copy from Q on purpose.
<ogra_> infinity, and NBS ?
<infinity> ogra_: What does NBS have to do with anything?
<rtg_> infinity, I'm good with that. would you care to comment on bug #1163443 ?
<ubot2`> Launchpad bug 1163443 in linux-ti-omap4 (Ubuntu Raring) "linux-ti-omap4 ftbfs in raring" [High,In progress] https://launchpad.net/bugs/1163443
<ogra_> dunno, i would expect doko to rip out the package 
<infinity> ogra_: It's built from source.
<ogra_> infinity, its a trivial fix (disabling tools)
<infinity> It's not built in raring, but that's fine.
<infinity> ogra_: I know, but the copy is a copy ON PURPOSE.
<ogra_> hmm
<infinity> Rebuilding it is counter-productive.
<ogra_> then i misunderstand NBS
<ogra_> i thought thats always for the current release
<infinity> NBS means binaries that don't match a source upload.  A copy of source+binaries can't be NBS. :P
<ogra_> ok
<ogra_> rtg_, take a walk ;)
<rtg_> ogra_, can do.
<ogra_> and dont listen to me :)
<infinity> rtg_: We were keeping it as copies intentionally, as R support is shorter than Q's, so there's no point building it in R at all.
<infinity> (And I intended to keep doing this post-release, as well)
<rtg_> infinity, bjf and I are really fine with that.
<infinity> rtg_: Bug closed wontfix and commented.
<rtg_> infinity, cool, thanks
<rtg_> sforshee, chroot: can't change root directory to '/data/ubuntu': Operation not permitted
<jsalisbury> ##
<jsalisbury> ## Kernel Meeting starting now
<jsalisbury> ##
<jsalisbury> ppisati, ping
 * rtg_ -> kernel
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 9th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<arges_> cking: hey. working on that build for bug 1157678, a bit crazy at the moment, but i'll own the bug for now
<ubot2`> Launchpad bug 1157678 in xserver-xorg-video-intel (Ubuntu) "unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,In progress] https://launchpad.net/bugs/1157678
<cking> arges, i'll keep my eye open and give it a spin when it's cooked
<AlanBell> hi all
<AlanBell> I have a laptop that has bug 1049466
<ubot2`> Launchpad bug 1049466 in linux (Ubuntu Quantal) "Need support of Ralink RT3290 wifi support" [Medium,Triaged] https://launchpad.net/bugs/1049466
<AlanBell> it just needs the rt3290.bin firmware file to be shipped, what do we have to do to make that happen?
 * rtg_ -> EOD
 * apw wanders off, to wait on bb heaven
<lborda> lborda asks: hi any idea why blacklisting usb_storage module does not work anymore in 12.04 ?
<lborda> bug bug: 1035739
<ubot2`> Launchpad bug 1035739 in module-init-tools (Ubuntu) "Blacklisting usb-storage is ignored." [Undecided,Confirmed] https://launchpad.net/bugs/1035739
#ubuntu-kernel 2013-04-03
<slangasek> infinity: so, I see that linux-ti-omap4 is in the list of rebuild failures for raring... related to the eglibc 2.17 -Wunused-result strictness.  Even if raring's -omap4 is just a copy, maybe we want to make it buildable?
<infinity> slangasek: http://pad.lv/1163443
<ubot2`> Launchpad bug 1163443 in linux-ti-omap4 "linux-ti-omap4 ftbfs in raring" [High,Won't fix]
<slangasek> heh
<infinity> slangasek: If we want to fix the quantal package to also be buildable in raring, that's fine, I suppose, but it's just creating work for people if we fork the packaging.
<slangasek> right, I'm not suggesting we fix it via raring
<infinity> Of course, the easy fix is to disable tools, which would be a regression in Q.
<infinity> We could fix it properly, but I'm not sure I actually care deeply.  Do you?
<slangasek> if I cared about it deeply I would fix it myself instead of trying to trick you into fixing it
<infinity> *smirk*
<infinity> I would rather someone had just given me the goahead to drop the ti-omap4/desktop images, thus allowing me to drop pvr-omap4 and the ti-omap4 kernel.
<infinity> (And we could do server/d-i with -generic)
<infinity> But I suppose it was a valid point that we don't (currently) have any other ARM desktop for people to play with.
<infinity> Would have been nice to make that Chromebook, perhaps.
<slangasek> s/nice/expensive/ given that we already have the pandae
<infinity> slangasek: True.  We'll need to pick a new proof-of-concept desktop platform at SOME point, though.
<infinity> Well, or, I suppose the unity-next convergence story might make it all moot, and the PoC can just be a few phone devices that we bless.
<slangasek> yes; I need to follow up with ogasawara and bryce on this, but the tentative plan is precisely that, carry over panda until such time as Ubuntu Touch is on its feet
<infinity> slangasek: Well, I didn't just mean Touch, but the converged desktop, so I can plug a phone into a monitor and test desktop applications on it in the same way I can on a Panda.
<slangasek> infinity: I'm not sure it's a good use of anyone's time to be testing desktop-only apps on Panda in the 13.10 timeframe; as far as I'm concerned, the purpose in testing the desktop on Panda between now and 13.10 is to make sure our infrastructure code doesn't bitrot between now and Unity Next getting on its feet
<infinity> slangasek: Sure, I agree on that score.
<ppisati> moin
<apw> ppisati, moin
<ppisati> apw: ciao
 * apw has an engineer on his way to bring him decent interwebs :)
<smb> apw, Is it the "cable guy"? :)
 * smb hopes the engineers will be in order
<apw> smb, it turns out the two guys are really one, its just the ordering system that thinks he is scitsophrenic (sp?)
 * smb will need to ask gnarl to explain that
<apw> yeah :)
<ppisati> brb
<brendand> henrix, are -generic and -generic-pae kernels still going to be released for Lucid or just -server kernels?
<henrix> brendand: good question :p i believe all the images will still be produced, but i may be wrong
<henrix> bjf: ^^
<ppisati> cking: http://paste.ubuntu.com/5673156/
<ppisati> cking: this was done on a nexus7
<ppisati> cking: but the procedure is the same
<cking> ppisati, cool, thanks
<ppisati> cking: i promise this afternoon i'll write up a decent wiki page about all the steps :P
<cking> heh, no stress
 * ppisati -> out for lunch
<apw> henrix, we normally keep updating all the kernels regardless
<henrix> apw: yeah, i believe there'll be no changes for the kernel team with the desktop EOL
<henrix> apw: thanks
<apw> indeed
<henrix> brendand: ^
<rtg_> apw, any progress on bug #1157952 ? It would be nice to have a fix before freeze.
<ubot2`> Launchpad bug 1157952 in linux (Ubuntu Raring) "SCSI keysense errors on console with Raring (3.8 kernel) within Windows Azure" [High,In progress] https://launchpad.net/bugs/1157952
<rtg_> henrix, whats the story on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1140716/comments/63 - are you reverting that patch from stable ?
<ubot2`> Launchpad bug 1140716 in linux "[regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed]
<henrix> rtg_: i'll need to review all the comments. i started following that bug but haven't been looking for a while
<henrix> rtg_: i'll take a look in a bit and eventually revert it. and ask upstream to revert it as well if necessary
<henrix> rtg_: thanks
<rtg_> henrix, can you chase it to ground soon? its bugging a lot of folks.
<rtg_> ack
<ppisati> ok, so here is a first crude transcipt on how to get, compile and flash a kernel for the nexus4/7
<ppisati> https://wiki.ubuntu.com/Kernel/Dev/AndroidKernel
<ppisati> i tested only the nexus7 side, cking is testing the nexus4 one :)
<cking> :-)
<rtg_> cking, an interesting patch on LKML: 'RAPL (Running Average Power Limit) driver'
 * cking looks
<cking> lots of MSR tweakables
<rtg_> cking, I didn't realize SNB has that kind of support
<cking> me neither, mind you I don't spend my life reading the Intel handbooks
<rtg_> nor I. I go skiing instead :)
 * ogra_ is curious if abootimg will just work on the nexus4 
<ogra_> it definitely has probs on my sansung galayx S2 here 
<cking> ogra_, I tried it with the existing kernel image and it didn't breakit
<ogra_> awesome
<ogra_> i guess the samsung code does some signing stuff or so then
<cking> who knows
<ogra_> i could :) if i bothered to look 
<rtg_> ppisati, nice wiki doc
<ppisati> anyone with wiki formatting style can contribute :)
<ogra_> update the kernel
<ogra_> aboot -u /dev/block/mmcblk0p2 -k mykernel
<ogra_> ppisati, ^^^ do you mean abootimg ?
<ppisati> ogra_: right
<ppisati> ogra_: fix it! :)
<ogra_> done
<diwic> jsalisbury, hi! Just a reminder that people are waiting for a test kernel in bug 1136110. I asked upstream too and they would like more bisection.
<ubot2`> Launchpad bug 1136110 in linux (Ubuntu) "USB Audio Codec choppy playback" [Medium,Confirmed] https://launchpad.net/bugs/1136110
<jsalisbury> diwic, ack.  I'll post the next kernel shortly
<diwic> jsalisbury, thanks for helping out! I should learn that bisection stuff some time.
<jsalisbury> diwic, np
 * ogasawara back in 20
<rtg_> jjohansen, why aren't the AA mount and network mediation patches upstream ? 'UBUNTU: SAUCE: AppArmor: basic networking rules' and 'UBUNTU: SAUCE: apparmor: Add the ability to mediate mount'
<henrix> rtg_: ok, i've took a closer look at bug #1140716 and looks like i'll be reverting it from 3.5 stable 
<ubot2`> Launchpad bug 1140716 in linux (Ubuntu Quantal) "[regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed] https://launchpad.net/bugs/1140716
<rtg_> henrix, good.
<henrix> rtg_: i'll just wait for a while until someone tests brad's kernel (with the patch reverted)
<henrix> rtg_: i'll go through the other upstream stable trees and see if they have this commit (i believe 3.2 has it, so debian should have this bug as well)
<bjf> henrix, did you see that i added test kernels?
<henrix> bjf: yes, i did.  i'll wait for someone to test it
<henrix> and revert the commit in for next release
<bjf> henrix, i guess i could actually READ what you typed into the channel
<bjf> doh!
<henrix> bjf: heh
 * ppisati wanders away for a bit...
<jjohansen> rtg_: because they have had a major rework, along with the rest of apparmor, you will see the beginning of the set going up for 3.10, and hopefully the rest for 3.11
<rtg_> jjohansen, ok, then I can note in the patch that they should get replaced for 13.10
<jsalisbury> rtg_, infinity It looks like 3.8.0.16.31 is the latest kernel version in the repositories, but the changlog indicates it should be Ubuntu-3.8.0-16.26.  see bug 1163296
<ubot2`> Launchpad bug 1163296 in linux (Ubuntu) "Version / Dependency Mismatch" [Medium,Confirmed] https://launchpad.net/bugs/1163296
<jjohansen> rtg_, apw: if you are curious I am keeping a raring version of the apparmor dev tree on zinc in my ubuntu-raring.git aa3.0 branch, it needs to be update it for some recent bug fixes that I am testing
<rtg_> jjohansen, I assume you're planning to drop those on me soon ? April 11 is freeze.
<jjohansen> rtg_: no, we decided we are not going to drop the new version of apparmor in to raring
<jjohansen> rtg_: we are shooting for 13.10, and as much upstream as possible
<rtg_> jjohansen, oh, I guess I misunderstood
<rtg_> ok, works for me
<jjohansen> rtg_: the tree pointer is just if you are curious to see what is going to becoming from upstream over the next few months. There really is no need to look at it
<rtg_> jsalisbury, that almost looks like a Launchpad issue. 
<rtg_> jjohansen, ack
<jsalisbury> rtg_, rmadison also reports 3.8.0.16.31 as the latest kernel version.  Not sure if rmadison pulls this infor from launchpad as well
<rtg_> jsalisbury, dunno, but I don't think its a kernel issue.
<jsalisbury> rtg_, ack
<apw> jsalisbury, rtg_, no that is just a person being confused by the difference in version numbers between the meta package and the main package
<jsalisbury> kamal, if you have a chance, can you take a look at bug 1163720  I can kick off a bisect but wanted to run it by you, in case its similar to something your already looking at.
<ubot2`> Launchpad bug 1163720 in linux (Ubuntu) "Brightness control broken on XPS13 with 3.8.0-16" [Medium,Confirmed] https://launchpad.net/bugs/1163720
<apw> jsalisbury, rtg_ 3.8.0.16.31 is the version number of linux-meta
<rtg_> apw, ah, didn't look close enough
<kamal> jsalisbury: curiously, I was just looking at that exact problem, and was about to file a bug for it
<kamal> jsalisbury: no bisect necessary -- I know exactly what's causing it
<jsalisbury> kamal, awesome, thanks!
<apw> rtg_, jsalisbury, i have commented in the bug.  invalid is correct
<Sarvatt> kamal: thats going to be http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-raring.git;a=commit;h=0e7a2fe01333f72c1cec1cd4d5293a62c770fa4f
<kamal> Sarvatt: yes, that's correct
<kamal> Sarvatt: "write backlight harder" was the bit that made it work for the XPS13 . . .  sigh.
<jsalisbury> apw, thanks
<rtg_> kamal, apw: be carefull with raring master-next as I'm doing lots of push + whilst annotating SAUCE patches.
<kamal> rtg_: this brightness regression has already landed in master (came from upstream)
<rtg_> kamal, stable ?
<apw> rtg_, ack, with my lack of internet don't expect me to be pushing over you
<kamal> it has been cc'd stable too, but it doesn't affect XPS 13 in stable since brightness control doesn't work until raring anyway (without my PPA)
<kamal> rtg_: wait, maybe not cc:'d stable -- I thought I saw that, but now I don't
 * rtg_ -> lunch
 * cking -> food
<bjf> sbeattie, anyone besides myself started running security QRT tests on touch image?
<sbeattie> bjf: not that I'm aware of.
<bjf> sbeattie, ack
 * sbeattie expects that being based on the android kernel, there's going to be things missing.
<bjf> sbeattie, kernel_panic and kernel_hardening just work. i'm looking at kernel_security to see what it's issues are
<sbeattie> kewl
<bjf> sbeattie, when i say they just work i mean the run and don't report any errors. i don't know if they are really doing anything :-P
<sbeattie> hehe
<bjf> sbeattie, anyone on your team have any of these mobile devices?
<sbeattie> bjf: yeah
<sbeattie> I do and ty hicks for sure, I can't remember if jj has one or not. 
<rtg_> kamal, is 'UBUNTU: SAUCE: Input: fix Cypress PS/2 Trackpad in Dell XPS12' gonna make it upstream ? I don't see it in linux-next.
<kamal> rtg_: I'll go figure out what happened to that
<kamal> rtg_: ok, it did actually land upstream already in 3.9-rc3, but the maintainer renamed the commit (for some reason I cannot fathom):
<kamal>    81bb5d3 Input: cypress_ps2 - fix trackpadi found in Dell XPS12
<rtg_> kamal, ok, thanks
<kamal> rtg_: do you want me to send a revert/replace request for that?
<rtg_> kamal, no, I've got it
<kamal> rtg_: thanks
<rtg_> kamal, the original SAUCE patch will simply disappear
<kamal> rtg_: perfect
 * rtg_ -> EOD
#ubuntu-kernel 2013-04-04
 * apw struggles on with crap internet, go bt go
 * jk- read that as "crab internet"
<smb> Its probably going as much sideways as that...
<smb> apw, Any estimate whether or when they fix the wiring madness?
<apw> jk-, you are upside down, so that is not supprising
<jk-> :D
<apw> smb, in theory the people to fix the broken draw arrived 40 minutes ago, fail
<smb> apw, professionals...
<apw> smb, and bt have magnanimously decided they can come back on the 13th to finish the job assuming the wire is in place
<apw> so no internet until then at least
 * apw burns some giffgaff data he has
<smb> doh! what a fail
<amitk> apw: I think this behaviour is part of charter of the Telecom Union of the World. I have yet to see a good Telecom company (though my Finnish one came close)
<apw> in this day and age i find it incredible the lead times one has on service.  virgin for instance i am waiting now 4 weeks for someone to come and see if we have a wire at the house, which btw we do i can see it sticking out of the ground and the one next to it goes to our neibour who has service
<apw> but till some minion comes to see if the cable they laid exists, they can't even tell me how long it would take to get someone to come and connect it
<apw> oh and they won't call me for 7-14 days
<apw> even call me, to tell me when they might be able to come
<apw> i feel a ranting blog post coming on
<ppisati> git fsck FTW! :)
<dholbach> hey
<dholbach> does anyone know if an Atheros AR9000 card (in a HP Probook 4545s) is somehow supported in Ubuntu? I'm looking at a friends laptop with 12.04 right now
<ovidiu-florin> hello world :d
<ovidiu-florin> when is the next kernel update planned for Precice?
<brendand> ovidiu-florin, by the end of this week
<ovidiu-florin> brendand: to what version?
<sforshee> ogra_, ppisati: do either of you know whether anyone's looked at using the sensors on the nexus 4 yet?
<ogra_> nope no idea
<sforshee> hmm. It looks like android is using a proprietary library
<psino> smb: do you know whether the patch mentioned in https://lkml.org/lkml/2013/3/21/518 will be applied to the planned precise kernel upgrade this week?
<smb> psino, yes no, as they still have not succeeded in pushing it upstream
<psino> ok, I've been on easter vacation so I haven't been able to pay attention to the progress
<smb> psino, There was another ping for it but since it has to go via x86 maintainers it seems to be a bit sluggish
<psino> what's the chance for having ubuntu include the patches before it's fixed upstream like fedora decided to do? :)
<smb> psino, if the problem is bad enough, there is a bug report and someone willing to do testing. Of course things upstream can happen relatively quickly and the effort might be in vain in the end.
<psino> do you know any of the x86 maintainers or a thread where there's some more information about the current state of the patches, so I can see how it is progressing / possibly have a little chat/email with the people who's going to merge it upstream?
<ogra_> sforshee, talk to tvoss ... i think he looked into it but not on  a kernel level
<ogra_> (not sure that was specifically on n4 though)
<sforshee> ogra_, thanks. I'm really just looking for where the knobs for powering various device on/off are, but in the n4 they don't seem to be in the kernel
<ogra_> right tvoss might know more ... i know he researched the general android sensor handling ... 
<smb> psino, Think this (http://lists.xen.org/archives/html/xen-devel/2013-03/msg01976.html) are the latest messages
<smb> psino, and hpa is one of them maintainers
<psino> smb: thanks, I'll possibly give him a small prod to check the status of the patches :)
<smb> psino, Well Boris did just yesterday. But one can always try. :)
<psino> probably doesn't hurt to let him know there's more people being affected by it :)
<psino> why would boris not want the patches to go into 3.9?
<smb> I think that does not mean he does not want them there. Its more that he fear they wont make it. Or maybe implying that they have not appeared because 3.9 needs to be finalized first
<ogasawara> rtg_, bjf, apw: just to confirm we're all in agreement, we're not going to provide an LBM package for Raring at this time.  correct?
<rtg_> ogasawara, I don't think we shold be providing LBM for any release other then LTS
<ogasawara> rtg_: I'm good with that
<rtg_> given the shorter life span of the interim releases and the amount of work required to maintain an LBM
<rtg_> ogasawara, you could drop in a cw-3.[78] into the precise LBM if you're tired of managing :)
<ogasawara> rtg_: I am, I'll put it on my todo list
<apw> ogasawara, works for me
<rtg_> apw, I'm down to about 40 SAUCE patches to review, so you can expect more carnage in raring master-next.
<rtg_> more, and frequent
<apw> rtg_, great
<rtg_> apw, just wanna be sure I don't push over something you've just pushed 'cause I'm not really checking very closely
<apw> rtg_, nope, i have been helping the builders cut my house to bits
<rtg_> apw, ugh, sounds painful
<apw> rtg_, bah you beat me to applying those patches
<rtg_> apw, email overlap
<amitk> rtg_: do you moonlight as the host of Radioparadise? :)
<rtg_> amitk, I havern't been a DJ in a long, long time.
<amitk> rtg_: damn, he sounds just like you
<rtg_> yeah, but they play all this mushy crap.
<rtg_> I'm a rock 'n roll dude
<amitk> rtg_: yeah, I tuned into them after ages while testing a new install for sound. I'm sure I'll grow up in a day or so.
<psivaa> bjf: reported bug 1164553 for the test failure on panda
<ubot2`> Launchpad bug 1164553 in linux (Ubuntu) "ubuntu_ecryptfs.lp-872905.sh.btrfs test fails to complete on panda ES with linux-ti-omap4: 3.5.0-222.33" [Undecided,New] https://launchpad.net/bugs/1164553
<bjf> ppisati, cking, ^
<cking> oh goody
<apw> rtg_, i don't think i can visualise you as a DJ
<rtg_> apw, I guess I was a different guy then :)
<ppisati> cking: is it the same one you made me test some weeks ago?
<cking> ppisati, I'm not sure (yet)
<apw> rtg_, i am struggling with that image :)
<rtg_> apw, we all evolve.
<apw> rtg_, even us dinosaurs ?
<rtg_> it happens slowly....
 * ppisati wanders away for a bit
<psivaa> cking: linux-lts-quantal-3.5.0 also has the same issue, 'WARNING: at /build/buildd/linux-lts-quantal-3.5.0/fs/btrfs/super.c:221 __btrfs_abort_transaction+0x99/0xb0 [btrfs]()'
<psivaa> cking: do you need a separate bug for that?
<bjf> psivaa, no, same issue there. see the comment cking added to the bug
<psivaa> bjf: ok, i see that now, thanks. I'm rerunning the tests again. But if it happens again, i'm not sure how to proceed, since the rest of the tests wont be run after this.
<cking> bjf, I suggest disabling this test for the moment, it is a corner case
<apw> rtg_, how is raring, i have a patch to push ... let me know when she is static enough for me to push
<apw> (rebase and push obviously)
<rtg_> apw, another hour ?
<apw> np
<rtg_> 18 patches left to review
<rtg_> apw, while you're waiting, perhaps you could take a stab at upstreaming 'UBUNTU: SAUCE: rds_ib_send() -- prevent local pings
<rtg_>  triggering BUG_ON()' ?
<bjf> psivaa, i'm sort of confused right now since it looks like that test is blacklisted
<bjf> psivaa, i'm still looking at it
<psivaa> bjf: ack, thanks
<psivaa> bjf: just to confirm that the test was running and was passing in the past, the latest good one being on 19/03
<rtg_> sforshee, did you ever try to upstream 'UBUNTU: SAUCE: dell-wmi: Demote unknown WMI event message to pr_debug' ?
<sforshee> rtg_, I did, but mjg59 didn't merge it or even respond
<rtg_> ack
<rtg_> sforshee, how did you remember that so quick? that was over a year ago
<sforshee> rtg_, I tried again within the past several months
<sforshee> the first time he was going to merge it but someone from dell said they'd post patches to handle the events soon
<sforshee> that never happened
<rtg_> sforshee, oh well, its a simple enough patch.
<rtg_> cking, do you think we still need 'UBUNTU: SAUCE: S3 early resume debug via keyboard LEDs' ?
<sforshee> rtg_, yeah. The problem was we kept getting bug reports from folks who saw the message in dmesg.
<cking> rtg_, I think we can bin that
<rtg_> cking, ack
<sforshee> rtg_, the more recent attempt was in December: http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/4065
<sconklin> sforshee: some patches of yours that we got from stable for 3.2 are triggering a build fail due to config changes. Do we need these in precise? It looks like it adds nothing unless we make a config change, which we're not likely to do:
<sconklin> 0156-efivars-Allow-disabling-use-as-a-pstore-backend.patch
<sconklin> 0157-efivars-Add-module-parameter-to-disable-use-as-a-pst.patch
<sconklin> 0158-efivars-Fix-check-for-CONFIG_EFI_VARS_PSTORE_DEFAULT.patch
<sforshee> sconklin, looking
<sconklin> thanks
<sforshee> sconklin, I'm curious what the build failures are, but I think we'll want to set CONFIG_EFI_VARS_PSTORE=n as we've done for raring
<sforshee> this was done in response to stgraber's lenovo getting bricked twice when pstore tried to write crash dumps to efivars
<sconklin> EFI Variable Support via sysfs (EFI_VARS) [Y/n/m/?] y
<sconklin>   Register efivars backend for pstore (EFI_VARS_PSTORE) [Y/n/?] (NEW) aborted!
<sconklin> Console input/output is redirected. Run 'make oldconfig' to update configuration.
<sconklin> sforshee: ^^
<sforshee> sconklin, so it fails simply because there's a new config option
<sconklin> What confused me was that the patch says it sets it, but it clearly didn't
<sconklin> I'll updateconfigs
<sforshee> sconklin, the other option is to enable that one and set the other option to make it disabled by default, then it can be enabled via the command line
<sforshee> but I think we should keep it off by default until upstream has figured out how to work around all the firmware bugs that cause machines to get bricked
<sconklin> sforshee: ack
<rtg_> ogasawara, which blueprint has the SAUCE patch review work item? LP is timing out so I'm having trouble searching.
<jsalisbury> rtg_, apw Is there a technical reason why the number of cpus is limited to 8 for the 32 bit arch?  I see CONFIG_NR_CPUS=8 in the config file.  A bug was opened for this: bug 1164122
<ubot2`> Launchpad bug 1164122 in linux (Ubuntu) "Ubuntu 12.10 32-bit only shows a maximum of 8 cores" [Medium,Incomplete] https://launchpad.net/bugs/1164122
<rtg_> jsalisbury, IIRC there was a memory cliff for 32 bit if you defined more then 8
<ogasawara> rtg_: https://blueprints.launchpad.net/ubuntu/+spec/hardware-r-kernel-delta-review
<ogasawara> rtg_: but really, you want the spec -> https://wiki.ubuntu.com/KernelTeam/Specs/RaringKernelDeltaReview
<jsalisbury> rtg_, ok thanks.  I'll see if I can find some details to post to the bug.
<rtg_> ogasawara, ok, I have looked at _every_ SAUCE patch over the last 2 days.
<ogasawara> rtg_: ah, so you really do just want the bp to close that sucker out then
<ogasawara> rtg_: I can do it for you, I've got it open here
<rtg_> ogasawara, what I really want is my name clear of all responsibilities :)
<ogasawara> rtg_: I'll make it so
<rtg_> ogasawara, :)
<rtg_> apw, raring master-next pushed. I'll return to my usual policy of _carefully_ checking before push +
<rtg_> now to rebuild unstable-3.9
<apw> rtg_, fix pushed to raring master-next, thanks
<rtg_> apw, ack
<jsalisbury> sforshee, I'm looking at bug 1155731, which appears to be related to a SAUCE patch or config file change.  Do you happen to have a  MacBook3,1 and a Apple bluetooth keyboard to see if you see this as well?
<ubot2`> Launchpad bug 1155731 in linux (Ubuntu) "Recurring kernel panic with khidp after resume from S3 on a MacBook3,1 with a connected bluetooth keyboard" [High,Incomplete] https://launchpad.net/bugs/1155731
<sforshee> jsalisbury, nope, I have neither
<jsalisbury> sforshee, ok, thanks
 * rtg_ -> lunch
 * rtg_ -> EOD
<dobey> anyone know how i can disable a specific PCI address from being used, rather than just blacklisting a module?
#ubuntu-kernel 2013-04-05
 * apw yawns ...
 * smb is reminded to get more coffee...
<apw> smb, a fine plan indeed
 * ppisati notes the keyboard in the nexus7 ubuntu image is much more usable than the phablet image counterpart
<ogra_> heh
<ogra_> you should say that in #ubuntu-touch so the right people see it 
<ppisati> ogra_: :)
<ppisati> ogra_: i just installed the nexus7 desktop img to the test yesterday's kernel
<ppisati> ogra_: and i just noticed how good the keyboard is there
<ppisati> ogra_: compared to the phablet one
<ogra_> is touch working without the patch ?
<ogra_> (on desktop)
<ppisati> ogra_: touch kernel you mean?
<ogra_> well, i mean the patch you discussed with jani 
<ogra_> would eb good if the same kernel worked on both 
<ppisati> ogra_: i'm testing it right now
<ppisati> ogra_: just finished to reinstall
<ogra_> ah, so touch still works even with that patch removed ?
<ogra_> (iirc we added an xorg.conf.d snippet that should fulfill the same purpose)
<ppisati> ogra_: the phablet/touch img had the touchscreen borked if that patch was present
<ogra_> right
<ppisati> ogra_: dunno about the dekstop img, since the patch landed there for this img
<ogra_> well, it would eb good to use the same kernel on both 
<ppisati> ogra_: besides, where's this snippet?
<ppisati> ogra_: right
<ogra_> somewhere in ubuntu-defaults-nexus7 iirc
<ppisati> ogra_: if i flash tthis morning img, do i get it?
 * ogra_ would have to look, but i have a vet appointment now, this will have to wait 
<ogra_> (if my GF ever manages to catch the cat)
<ppisati> ogra_: try with a net :)
<ogra_> haha
<ogra_> she's not a fish !
<ppisati> ogra_: cat or GF? :)
<ogra_> :P
 * ogra_ is back
 * apw tries to not imaging ogra_ with a fish for a g/f
 * ogra_ wont comment on that since this is a family friendly channel 
<apw> :)
<ev> hiya. Does anyone know if our copy of the android kernel does something to prevent core dumps? I can't seem to force one despite killing debuggerd, setting the core ulimit to unlimited, and setting the core pipe appropriately.
<ev> ppisati: ogra_ mentioned you might have an idea, having touched the config last :)
<ogra_> :)
<ppisati> ev: i know there was an option about core dump in the dekstop kernel (not in the android one), let me check
<ppisati> ev: cat /proc/sys/kernel/core_pattern
<ev> ppisati: neither "core", nor "/data/core.%e.%p", nor "|/path/to/apport" work
<ev> been through them all :)
<ev> and yes - I was in a writeable directory
<ev> (for "core" that is)
<ppisati> ev: and you tried with SIGABRT or gcore, right?
<ev> gcore? I was sending SIGSEGV.
<ev> SIGABRT also doesn't dump core. gcore on `sleep inf` works.
 * ogasawara  back in 20
 * smb -> eow
 * rtg_ -> lunch
 * henrix -> eod
<rtg_> apw, ogasawara: pushed raring master-next rebase on v3.8.6. build testing, will likely upload tomorrow.
<ogasawara> rtg_: ack
<infinity> psivaa: Did the regression testing on ti-omap4/quantal get stalled?  Seems to be the only SRU currently not ready to be released.
<infinity> psivaa: Oh, and linux-ec2/lucid, apparently.
<infinity> zequence: Your kernels for P/Q are in -proposed now (will be true on mirrors in an hour or so, I suspect), if you want to do some quick smoketesting over the weekend, I'll release them on Monday with all the others and you'll be caught up.  \o/
<bryce> sforshee, test patch on #1041790 could use a kernel I think
<sforshee> bryce, is this the patch you're referring to? https://bugs.freedesktop.org/attachment.cgi?id=77475
 * rtg_ -> EOD
<bryce> sforshee, that's the one
<bryce> sforshee, your call on what kernels worth building.  The issue appears to affect raring and quantal, and one precise user claims to see it (unverified so far)
<sforshee> bryce, ack. I'll kick off some builds.
<bryce> sforshee, this bug seems to be relatively widespread and severe (it's even hitting canonical employees a lot), so you might put this on a higher priority attention list for your team
<bryce> sforshee, sounds like Intel flipped on a performance improvement too soon.  So if we were to carry this patch there is a possible performance impact to it.  
<sforshee> bryce, I'm building raring and quantal to start, I'll follow up with precise if needed
<bryce> sounds good
#ubuntu-kernel 2013-04-06
<zequence> infinity: Thanks. I'll do that
<zequence> I'm trying to track down where this goes wrong in the source for linux-lowlatency Bug #1165259 
<ubot2`> Launchpad bug 1165259 in linux-meta-lowlatency (Ubuntu) "13.04 Beta1 -- symlink missing for Linux Headers /usr/src" [Undecided,New] https://launchpad.net/bugs/1165259
<zequence> If someone knows this stuff well, I wouldn't mind to get some pointers :)
#ubuntu-kernel 2013-04-07
<charliepurple1> Hey there, for bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1164788 I was asked to test an upstream kernel. I installed it and then my networking (including wired) disappeared, as if there just wasn't any hardware for it. It also affected USB stuff. is there a way to test it and also have network stuff running? 
<ubot2`> Launchpad bug 1164788 in linux "13.04 kernel panic: unable to handle kernel paging request at ffffffec" [High,Confirmed]
<maxb> charliepurple1: Just a guess - did you install both the linux-image and linux-image-extra packages for the upstream test kernel version?
<charliepurple1> Yes, I did. 
<maxb> Hm, no idea then
<charliepurple1> I'll give it another go. I'm on a new install now, so maybe it'll be different. 
<zequence> infinity: Kernels smoke tested. Also, not really related to kernels, but should I poke someone to get this SRU uploaded, or does that happen in due time? Bug #956438
<ubot2`> Launchpad bug 956438 in jackd2 (Ubuntu Quantal) "jackdbus crashes on stop" [Undecided,Fix committed] https://launchpad.net/bugs/956438
<zequence> If poking would help, I guess I'm poking you :)
#ubuntu-kernel 2014-03-31
<Kano> hi, do you want to build a 3.14 kernel soon?
<infinity> Kano: Like this one? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-trusty/
<Kano> well with aufs
<Kano> not mainline
<infinity> Then you want http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=shortlog;h=refs/heads/unstable
<Kano> i know, but its not tagged
<Kano> i currently build that
<Kano> i already updated ndiswrapper, fglrx, nvidia with rc8, the patches are simple, ndiswrapper you can get from debian
<smb> apw, So my ppa now contains the updated xen package. I think I will have to change the binary package that I use to add the grub config from utils-common to hypervisor since that at least triggers an update-grub run.
<apw> smb, sounds good, do you want me to test that or wait on this binary package move?
<smb> apw, Hm, maybe its better to wait for the move. 
<apw> smb, ack
<smoser> anyone interested in looking at this:
<smoser> http://paste.ubuntu.com/7184918/
<smoser> should i file a bug? 
<smoser> note the old kernel version
<rtg> smoser, wow, thats pretty old. can you repro it with the current kernel ?
<smoser> rtg, this is the only time i've ever seen that.
<smoser> so, probably not.
<smoser> but that doesn't mean anything :)
<rtg> well, probably not much we can do about it.
<smoser> mainly i just posted to see if it showed an obvious error.
<rtg> its not one I recognize
<apw> rtg, have pushed an update to master-next
<rtg> apw, ack
<smb> apw, Ok, ppa now has the more recent test version of xen
<apw> smb, thanks
<apw> smb, what do i undo in my setup to be "normal" for it to work
<apw> smb, as i currently have it mangled to make it use xen right ?
<smb> apw, If you have set some GRUB_DEFAULT != 0 and not booted manually into xen you could set that back to 0
<apw> smb, yeah that ...
<smb> apw, Bah, of course right after saying that, there is a "bug" in the message... its /etc/default/grub.d/xen.cfg to look into
<rtg> apw, pushed AA sync
<apw> rtg, ack
<rtg> apw, I'm gonna jigger HEAD to add a bug number (bug #1298611)
<ubot2> Launchpad bug 1298611 in libvirt (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [High,Triaged] https://launchpad.net/bugs/1298611
<apw> smb, those see to work mostly as i would expect thanks, modulo that error you self spotted
<apw> rtg, ack
<jdstrand> apw, rtg: did the release team ack it?
<rtg> jdstrand, they don't get to ack kernel patches
<smb> apw, Cool, I already updated the local source to keep me forgetting
<smb> from
<jdstrand> rtg: not even for feature?
<jdstrand> cause, infinity seemed to indicate they would
<rtg> jdstrand, besides, kernel freeze is not until Apr 3
<jdstrand> (and I've kept infinity in the loop all along)
<jdstrand> well, I don't mean to disrupt the process. just trying to do it by the book :)
<rtg> jdstrand, according to jjohansen these patches should be backward compatible with Precise user space.
<jdstrand> they are
<rtg> ok, then I'm fine with them
<jdstrand> extensive testing was performed by him and me for that configuration (and others). this is detailed in the bug
<jdstrand> wfm
<rtg> jdstrand, yup, I had a pretty good conversation with him about it last friday
<jdstrand> ack. the testing continued over the weekend with the code in the pull request
<apw> rtg, i think the only thing we care is if they are going to reject the whole feature us carrying the patches makes no sense
<rtg> apw, perhaps, but it does keep us closer to upstream, and should be benign for Precise user space.
<rtg> dannf, have you booted 3.13.0-20.42 on an x-gene SOC ?
<dannf> rtg: we booted the first -20, dont' remember the version
<rtg> I made a bunch of config changes, some of which may have affected arm64
<rtg> dannf, -20.41 should have been sufficient. -20.42 was just packaging
<dannf> rtg: ok. i'll double check just to be sure
<rtg> dannf, thanks
<rtg> ppisati, you should do the same for your Trusy armhf platforms
 * ppisati reads the backlog
<rtg> ppisati, just make sure the latest Trusty kernel works
<ppisati> rtg: i'll do
<apw> rtg, aa> fair enough i guess, as we should have the older support still and the kernel bits should understand the lack of userspace features
<apw> rtg, pushed a could of "shhhh" patches
<ppisati> rtg: doing another upload before freeze?
<rtg> ppisati, yup
<ppisati> rtg: i would like to squeeze a ptch in, if i can make upstream ack a problem i'm seeing
<rtg> apw, where did your "shhhh" patches go ?
<ppisati> rtg: ping me before the deadline
<apw> rtg, look to be there for me
<rtg> ppisati, wednesday is the last possible 
<rtg> day
<ppisati> rtg: ack
<rtg> apw, must have been a race. got 'em now
<rtg> apw, I'm wondering if we shouldn't set CONFIG_ZSWAP=n ? Especially for an LTS kernel. This feature is still considered experimental by upstream.
<rtg> perhaps turn it back on for 14.10
<apw> rtg, as long as that isn't the one we use for low memory systems in the installer
<apw> rtg, which i think is ZRAM
<apw> rtg, so the other question is when is it used, always if it is on, on
<apw> or does one have to trigger its use somehow
<rtg> apw, ZSWAP always on as far as I can tell
<rtg> is always*
<apw> rtg, hurm, difficult given we ave been using it such a lot then, but i can see turning it off ought to be safer
<rtg> apw, well, we do have a lot of bug reports about suspend/resume, and a number of other random page faults. seems like a possiblity (though I have _no_ hard information).
<apw> rtg, then wack it
<rtg> just going by the help text for the feature....
 * ppisati starts another kernel compilation and goes for a walk...
<vlad_starkov> QUESTION: Is it possible to disable udev on boot? (Ubuntu 14.04 Server 64bit)
 * antarus blinks
<antarus> in Ubuntu? why would you want to do that?
<vlad_starkov> antarus: My system does not boot even with Live USB. It hangs with CPU soft lockup errors
<vlad_starkov> antarus: I think the cause of this is in kernel modules load sequence 
<antarus> hrm interesting
<vlad_starkov> antarus: if you like I can pastebin console logs at boot
<antarus> sorry, I probably can't help you
 * antarus mostly lurks here
<vlad_starkov> antarus: OK
<antarus> I was mostly curious why you wanted udev off. The best idea I can think of is to somehow guess which module is causing hte problem and blacklist it somehow?
<antarus> not sure what the kernel command line arugments are for that
<vlad_starkov> antarus: this is whta I'm trying to do
<TJ-> vlad_starkov: I'm with you here, too
<vlad_starkov> TJ-: Oh nice
<vlad_starkov> TJ-: so, I think this is the last attempt to deal with my server
<vlad_starkov> TJ-: for now I disabled SATA and PATA. Trying to boot from USB. The same result :)
<TJ-> vlad_starkov: Did you get the memoserv note I left you Friday night?
<vlad_starkov> TJ-: Mmm I think I'm not
<TJ-> vlad_starkov: Check... I suspect it'll address issue
<vlad_starkov> TJ-: never did it before, could you guide me how to check memo
<TJ-> vlad_starkov: "/msg memoserv help"
<TJ-> vlad_starkov: The gist was, kernel option "elevator=deadline" ought to fix it
<vlad_starkov> elevator=deadline
<vlad_starkov> yep, just read it in memos)
<vlad_starkov> TJ-: let me try
<TJ-> vlad_starkov: I had to think hard to remember it!
<TJ-> vlad_starkov: Shall we switch back to #ubuntu-server, to avoid messing up the kernel team's history ?
<vlad_starkov> TJ-: sure!
<dannf> rtg: oh yeah, works fine
<rtg> dannf, cool
<infinity> BenC: So, unless we get that kernel in today, I think you missed this SRU cycle. :P
<rtg> sforshee, please have a look at bug #1300416 when you get a chance
<ubot2> Launchpad bug 1300416 in linux (Ubuntu) "Install of 14.04 fails with 3.13.0-20-generic kernel" [High,Confirmed] https://launchpad.net/bugs/1300416
<rtg> brcmsmac is involved
<darklight_> the latest kernel kinda broke the intel driver
<darklight_> multiple applications fail with  ../../../../../../../src/mesa/drivers/dri/i965/brw_reset.c:43: brw_get_graphics_reset_status: Assertion `brw->hw_ctx != ((void *)0)' failed.
<darklight_> happens with i915 too
<darklight_> I'm talking about 14.04
<RAOF> darklight_: What mesa are you running against?
<darklight_> RAOF: 10.1.0-1 stock 14.04 atm
<darklight_> I've seen a bug report for kwin online and here I have another application failing related to node-webkit
<RAOF> Huh. I thought that bug was introduced in a more recent mesa.
<RAOF> I've seen tjaalton talking about that with upstream.
 * RAOF sends out the Bat Signal
<darklight_> I tried with 3.19 and at least for my testcase things work fine
<darklight_> 3.20 breaks it
<darklight_> for reference it's the popcorn-app, it's not in the repository, but I think anything related to node-webkit should show the same isse
<darklight_> RAOF: I'm off to bed, if you need me to test something /msg me 
<RAOF> Ta.
<RAOF> Sleep wel!
<darklight_> thanks! hopefuly you'll fix this soon :)
#ubuntu-kernel 2014-04-01
<tjaalton> huh?
<tjaalton> RAOF: i don't recall seeing that before
<RAOF> tjaalton: Hm. I thought you were talking on #intel-gfx about some hardware context not being there?
<tjaalton> wwll bdw has bugs, but i bet this is with something older
<tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=75723 it seems
<ubot2> Freedesktop bug 75723 in Drivers/DRI/i915 "(regression since Linux 3.14?) brw_get_graphics_reset_status: Assertion `brw->hw_ctx != ((void *)0)' failed" [Normal,New]
<RAOF> Ah.
<tjaalton> love how it's been opened a month ago with zero interest
<ppisati> yo
<tjaalton> Â Âµâ
<smb> n'?
<tjaalton> cat
<tjaalton> explains all typos from me
<smb> heh :)
<smb> Luckily mine stays outside (unless I fail to prevent him) normally
<amitk> i read that as "micro tic" which is close to a router company "microtik" or a new way to wave on IRC ;)
<tjaalton> whatever works :)
 * apw yawns
<smb> apw, Caution there are giant bees approaching from Australia
<soren> smb: Yet he comes back?
<soren> smb: (re: The cat, not the bees)
<smb> soren, Ah, I was wondering. Yes, he does. Apart of being his can opener, he thinks he has to inspect all rooms from time to time
<soren> smb: Interesting.
<soren> smb: I just thought cats were smarter than that. If he wants to go out, but coming into your house means being prevented from going back out, I'd assume he'd not come back.
<soren> smb: That's the argument I use with my wife for letting our cat out whenever he wants. :)
<smb> soren, He is smart enough to actually make use of many people. So he isn't owned by anyone but gets treats everywhere
<smb> Its a shared cat
<soren> smb: Clever.
<erle-> how can i monitor actual cpu frequency (as opposed to nominal cpu steps, e.g. while running overclocked or using turbo mode)
<apw> erle-, sudo cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq has instantaneous levels
<erle-> apw, that one only tells me nominal states
<erle-> but i found the solution in the meanwhile
<erle-> from packe linux-tools the command turbostat
<apw> ok good
<ogra_> i thought you need to look at scaling_cur_freq for the realtime data 
<erle-> ogra_, both only display the steps of 800,1600,2400 and 3200
<erle-> ogra_, i run at 3712 (highest regular step) and 4176 (turbo)
<erle-> bios tells me
<erle-> i want to know whether linux uses the turbo
<erle-> (AMD turbo
<erle-> )
<erle-> does anybody here have experience with amd turbo core?
<erle-> i disabled 4 of 6 cores in bios and overclocked, because i want to run a hard single-threaded simulation
<erle-> turbo core requires half of cores to be idle
<erle-> do disabled cores count as idle?
<ogra_> is there a way to dynamically raise the ringbuffer size ? i try to debug some boot stuff, but by the time i can read dmesg or kern.log the buffer is already overwritten
<apw> ogra_, yeah there is a kernel parameter for that
<ogra_> remember which ?
<henrix> ogra_: kernel-parameters.txt talks about log_buf_len
<henrix> (never used it myself)
<apw> log_buf_len = bytes i think
<ogra_> henrix, thanks !
<ogra_> will try 
<rtg> ogra_, no spaces around the ' = '
<ogra_> yeah
<apw> rtg, there is habit for you
<cking> and it needs to be a power of 2 
<henrix> rtg: do you remember if chiluk was hitting this issue on T only?
<henrix> rtg: maybe i discarded these patches from 3.11 stable too early...
<henrix> although the backport could be non-trivial
<rtg> henrix, pretty sure it was on T
<henrix> rtg: ack
<rtg> henrix, I'm not sure those VFS patches would be right for 3.11
<henrix> rtg: yeah, i dropped them, but i admit i didn't tried too hard to understand the issues they solve... :-/
<rtg> henrix, it might just be the namespace mount point proliferation problem. I wonder if hallyn would know.
<hallyn> ?
<rtg> hallyn, these commits in 3.14:
<rtg> 38129a1 switch mnt_hash to hlist
<rtg>  0b1b901 don't bother with propagate_mnt() unless the target is shared
<rtg>  1d6a32a keep shadowed vfsmounts together
<rtg>  0818bf2 resizable namespace.c hashes
<rtg> do they help the performance of removing mount points ?
<hallyn> sorry i haven't seenthem
<hallyn> certainly 0b1b901 should
<apw> rtg, was that arges' bug perhaps
<hallyn> as should the first
<rtg> apw, I thought it was chiluk ?
<apw> oh maybe, perhaps i need a beer to remind me
<rtg> apw, whoa, it _is_ about that time.
<ogra_> way past 
<ogra_> *burp*
<hallyn> drat i'm in the wrong tz
 * hallyn swigs some coffee, wishing it were something else
<rtg> hallyn, could you have a look at those commits ? They are scheduled for 3.13 stable, but I might pull them earlier and get some testing on them.
<hallyn> rtg: meeting coming up, i'll look after that
<rtg> hallyn, thanks
<hallyn> np - ttyl
<arges> hallyn: apw : yea it was chiluk's bug
<chiluk`> rtg henriz   0818bf27c05b2   is the important one that should be included in all stable kernels.
<chiluk`> give me a sec to take a look..
<rtg> chiluk`, well, its not in Trusty
<chiluk`> although the move to hlist for m_hash is not necessary
<rtg> though it is marked for stable
<zequence> Not at all meaning to sound negative, and also, since I'm a fan of you know who, it's SRU up your ass time again!
<zequence> infinity: Any chance you'll be SRU'ing linux-lowlatency at next point release to a newer version? I've been meaning to try make that happen, but perhaps now I don't even need to?
<zequence> Just to clarify, was just quoting Metallica before.
<rtg> ogasawara, contrary to your meeting notes, I _do_ plan to upload once more before freeze, if for no other reason then to remove lttng in favor of the lttng-modules package.
<ogasawara> rtg: oh you do?  when do you think you'll do the upload?
<ogasawara> rtg: tomorrow?
<rtg> ogasawara, I guess it'll have to be tomorrow won't it. Thursday my time would be too late.
<ogasawara> rtg: ok cool, I'll see if I can squeeze in this patch I've been bisecting for
<ogasawara> rtg: just depends on how quickly I can get this testing feedback
<rtg> ogasawara, ack
<hallyn> chiluk: so why is 0818bf27c05b2 important?
<hallyn> it seems to me that commit 38129a1 is important as otherwise we risk infinite loops when racing withumounts (if the description is to be believed)
<hallyn> and commit 1d6a32a seems to be a prereq for that one
<chiluk> hallyn, so openstack neutron nodes keep the network processes in network namespaces and mount namespaces... unfortunately that means that for n network namespaces... there has to be n^2 entries in the mount_hashtable.
<hallyn> commit 0b1b901 seems unimportant - we only save a lock_mount_hash (and unlock), so unless we are seeing that as a hot path somewhere...
<chiluk> so for 4000 namespaces that means 1.6m entries in that hashtable.
<chiluk> which becomes a serious bottleneck, and can also lead to hangs and crashing
<hallyn> chiluk: ok andn so switching to hlist halves the size of that table?
<chiluk> hlist isn't as important as increasing the size of the hashtable itself.
<chiluk> but hlist would help as well.
<hallyn> i'd be curious to see how much kmem you save then with both  38129a1 and 0b1b901
<hallyn> uh, i mean and 0818bf2
<hallyn> chiluk: so you would agree that commit 0b1b901 seems unimportant?
<chiluk> well since they all are meant to improve the performance of the mount namespaces, I would think they are all important... some more than others.
<chiluk> 0818bf2 should go into all p+ kernels imho
<chiluk> 0818bf2 1d6a32 0b1b901 38129a13 should all go into trusty.
<chiluk> if they don't clean cherry-pick, I'll work on a backport.
<soren> chiluk: 4000 network namespaces? Is that a number you're making up or does someone claim to need anything even close to that?
<soren> chiluk: It just sounds a bit over the top to me. Even with a 64 CPU system with, say, 8 VM's per CPU, you'd need an average of 8 distinct networks per VM to reach that number.
<chiluk> soren... look at openstack .. and yes 4000 is only a small part for a decent sized cloud.
<chiluk> it's not the compute nodes that are the problem.
<soren> chiluk: Oh, right, the network nodes need to accommodate every single network.
<chiluk> soren it's the network gateways... mount/net namespaces are used to partition the network by the neutron nodes
<soren> chiluk: Gosh, yes, 4000 aren't going to get you anywhere then.
<chiluk> exactly
 * soren shakes his head at that horrible design
<chiluk> right now most people scale out their gateways
<chiluk> but some people have beefy gateways, and are pissed at the 3-4k limitation.
<soren> chiluk: Understandable.
<soren> chiluk: Yeah, I totally hadn't thought of the network nodes. It makes much more sense that way.
<chiluk> with these patches those people can take the current 4k hashtable and make it 512mb or more... and get much better performance on deletion..
<chiluk> which is usually where the problems started.
<chiluk> it used to be a 4k hashtable with 80k node linked lists... 
<soren> Oh, it doesn't remove the O(n^2) space complexity?
<soren> Oh, my.
<chiluk> it does not.
<soren> Yeah, that sounds like no fun at all.
<chiluk> the issue with O(n^2) comes from the lack of forsite in the unshare(CLONE_NEWNS) calls
<chiluk> and the fact that each new net namespace creates it's own mount...
<chiluk> for proc entries.
 * soren doesn't quite grok how that becomes an n^2 thing
<chiluk> each namespace creates a mount... each namespace duplicates all mounts for it's namespace.
<soren> Oh.
<chiluk> or at least creates duplicate entries in those tables for it'a namespace.
<hallyn> if you're doing network namespaces it's not strictly necessary to have fresh mounts ns in each netns
<infinity> zequence: You might need to rephrase your question.
<zequence> infinity: are you going to SRU the trusty kernel to precise later?
<bjf> zequence, if you are asking if there will be an lts-backport-trusty kernel for precise the answer is yes
<bjf> zequence, that is also why there will be a 12.04.5 release
<infinity> zequence: However, the answer to the question you were really asking (does linux-lts-trusty include lowlatency) is currently "no".
<infinity> And will probably remain no for that backport.
<infinity> But for 14.10 kernels backported to trusty, I think we should enable all flavours.
<zequence> infinity: Alright
<gabriell> Hello. I'm newbie to kernel development. I'm trying to load a module I wrote, but I'm getting the error "Invalid module format". Can anyone help me with this?
#ubuntu-kernel 2014-04-02
<apw> eno-gabriell
 * apw yawns theatrically
<smb> apw, You expect people to actually hang on after asking a question. ;-P
<apw> smb, this kvm patch, i don't think it does what i expected it to
<apw> smb, or indeed what the description implies.  if the issue is folding the bit in, why don't you fold the bit in just before calling kvm_resched(), and isn't not calling it bad
<smb> apw, why? it seems to at least from a practical experience
<smb> Not sure I parse the last part of the sencence
<smb> But I did not want to meddle around with the bits in the background. I think that at the place where kvm does the cond_resched there probably should not be anything preventing it... at least not in the config_preempt=n case
<apw> if (test_tsk_need_resched(current)) set_preempt_need_resched();
<apw> smb, that patch looks like what i would expect, if you have tested it i'll just commit it
<smb> apw, I thought "compile it - ship it" was the motto ;) No, got it tested on my 32bit install. At least was able to boot ok twice in kvm
<smb> while otherwise none is successful
<apw> smb, yeha as i recall when we talked "way back when" it was basically fatal on all boots
<apw> (without)
<smb> right
<smb> apw, note the buglink I forgot to add initially
<apw> smb, is this fixed in 3.14 etc and later, "some other way" ?
<smb> apw, Not to my knowledge but I was not testing a few weeks
<apw> ok
<apw> smb, i shall assueme you are owning that :)
<smb> apw, owning? I suppose need to try getting it solved for read. Yeah, probably
<apw> s/read/real/?  for unxious ?
<smb> apw, true
<mjeanson> rtg: Hi, I was wondering if you knew which version of the lttng modules was last pulled in trusty's kernel?
<rtg> mjeanson, it was an rc candidate for 2.4 IIRC
<rtg> the lttnk-modules package is more up to date
<mjeanson> I'm investigating a problem with the lttng-modules-dkms package
<rtg> lttng*
<mjeanson> the rc modules are identified as 2.4.0, so dkms won't install over those from the ubuntu kernel
<rtg> mjeanson, I've removed lttng from the kernel, so this next upload should fix your issues.
<mjeanson> and some modules don't have version tag, resulting in a non-working mix and match
<mjeanson> ok great
<apw> rtg, ... ooops
<apw>       MISS: lttng-tracer
<apw>       MISS: lttng-types
<apw>       read 2952 modules : new(0)  missing(42)
<rtg> apw, hmm, thought I did a test build. I'll get 'em
<apw> rtg, ack
<rtg> apw, ah, I hacked it out of the previous ABI
<apw> ahh startrewrelease nackered you
<rtg> apw, am gonna collapose it into the SNR and slam HEAD, OK ?
<apw> rtg, ack
<hallyn> rtg: hi, so still, months later, i can ssh into gomeisa but not tangerine.  
<hallyn> i get 'permission denied (publickey)...
<rtg> hallyn, hmm
<smoser> rtg, i think i pinged you earlier this week with just a pastebin stack trace
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301496
<ubot2> Launchpad bug 1301496 in linux (Ubuntu) "kernel crash: Unable to handle kernel paging request for data" [Undecided,New]
<smoser> it happened again. you can change title of bug to be more correct.
<rtg> smoser, try it with -20. I turned off ZSWAP
<smoser> Z as in compress?
<smoser> and swap as in swap ?
<smoser> $ free
<smoser>              total       used       free     shared    buffers     cached
<smoser> Mem:      16742464   12982528    3759936      26240     223872   11398080
<smoser> -/+ buffers/cache:    1360576   15381888
<smoser> Swap:            0          0          0
<rtg> smoser, yeah, it was still listed as an experimental feature.
<smoser> ie, there is no swap on the system.
<rtg> smoser, -20 also has a major stable update. does this happen every time ?
<smoser> no, not every time. we've seen this twice, and jcastro is working juju very hard.
<smoser> jcastro also informed me that juju stack traced
<smoser> and i can get that stack trace if useful.
<rtg> smoser, from  the current archive kernel please. This trace doesn't have much to go on.
<apw> smoser, so you got that with -19 and not the -8 this time ?
<smoser> apw, yes.
<rtg> not that that will change much.
<smoser> for the record, -19 was current as of 9 hours ago
<apw> isn't that saying that netns is closing there when it barfed ?
<smoser> (ie, its not like i was running something from 3 weeks ago)
<smoser> juju is running several lxc containers.
<rtg> smoser, we're not accusing you of being a lagard. I'm merely pointing out that -20 has a huge stable update in it.
<smoser> k. i'll try to get jcastro to do that.
<rtg> -21 actually
<smoser> bah. sorry. i thought i was only 1 behind.
<smoser> alright. htat system is up in 3.13.0-21-generic now.
<manjo> ppisati, around ? 
 * manjo thinks rtg was scared I would ping him next ... ? 
<manjo> rtg, got a quick question for you 
<rtg> manjo, hmm ?
<miseria> "que doloroso es amar y no porderlo decir, caminar y no saber donde ir, vivir y no saber donde morir" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 8th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<darklight_> RAOF, ping
<bladernr_> asked in #ubuntu-server and I'll ask here too...
<bladernr_> hey, how familar are any of you with tweaking kernel routing?
<bladernr_> there used to be a setting in /proc/sys/net/ maybe in ./ipv4 to force packets to ONLY go out and return via the interface they were supposed to
<bladernr_>  by default, it's possible to have packets go out eth1 and come in eth0 if both are on the same network
<bladernr_> <bladernr_> and it's been well over 5 years since I last tried this and I forgot the magic switch.
<apw> bladernr_, do those interfaces have the same ip?
<bladernr_> no, but they're on the same LAN (e.g. 10.0.0.123 and 10.0.0.128)
<apw> so that would be down to how arp responses occur then else each would only respond to its own
<apw> but no i cannot recall seeing the option you seek
<bladernr_> hrmmm.. ok.  I found the ip-sysctl docs so maybe something in that will help too...
<apw> there might be a kernel parameter (which may have a sysctl equiv) called arp_ignore 
<apw> oh it is documented in that very file
<apw> bladernr_, ^
<apw> bladernr_, i think arp_ignore of 2 is what you describe, maybe
<bladernr_> perhaps so... i was just starting to look at arp related things in the docs... you beat me to it.
<apw> net.ipv4.conf.all.arp_ignore = 0 
<apw> that one maybe
<bladernr_> thanks apb1963 I'll play around with that and see what happens
<bladernr_> err... I meant thanks apw... tab complete win
<apw> bladernr_, some of those .all. things copy to an interface when it is made, and need changeing per interface as well if the interface is established before it si changed
<hatch> hey guys, any idea of the kernel will be fixed so it will run on more than one cpu for the new mac haswell machines? 
<hatch> for 14.04
<bjf> hatch, do you really mean one cpu or one core?
<hatch> sorry one core :)
<hatch> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284085
<ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed]
<hatch> the title is a little missleading as it's also an issue on the MBP's
<bjf> hatch, because i'm running an 8 core haswell and it's banging on all of them
<hatch> misleading 
<hatch> oh really....
<bjf> hatch, it's not a macbook air though
<hatch> did you have to do anything special to make it work?
<bjf> sforshee, do you have a haswell macbook?
<hatch> the same issue for the macbook pros
<bjf> hatch, nope
<bjf> hatch, htop shows 16 cpus and a kernel build works them all
<hatch> hmm maybe I should try the latest kernel
<bjf> hatch, i'm running the latest kernel 3.13.0-21.43
<bjf> hatch, we are talking trusty right?
<hatch> yeah
<bjf> hatch, and was it working before and suddenly stopped?
<bjf> (after an upgrade)
<hatch> bjf I installed it, it booted, then on reboot it stopped at Node #0  CPUS #1
<bjf> hmmm
<hatch> basically I have the exact same issue on my MBP as outlined in that bug with the Air
<bjf> i have another haswell here, let me try that
<hatch> great thanks
<hatch> I'd be happy to provide any other information - I'd really like to get Trusty running on metal on this thing :)
<bjf> hatch, i'm installing from scratch, won't take long
<hatch> oh ok, well I sort of hope it doesn't work so that it's reproducible :D
<hatch> of course if it's a newer kernel than I have then that would also be good :)
<bjf> heh
<bjf> hatch, this is a dual core system with hyperthreading so htop shows it has 4 cpus. i see them all getting worked.
<hatch> hmm well then...
<hatch> is there some documentation on how I might upgrade the kernel? I can get to the grub loader but beyond that it hangs
<hatch> I could wipe the partition and start over too I suppose
<bjf> hatch, you should be able (from a terminal window) sudo apt-get update; sudo apt-get dist-upgrade
<hatch> bjf yeah I can't get that far
<hatch> :)
<bjf> hatch, so it won't even boot up for you?
<hatch> nope, hangs at the same place as in that bug report....identical
<hatch> there is an image in there to where it's hanging 
<Sargun> Any reason why CONFIG_IP_VS_IPV6 is disabled?
<hatch> bjf this is the picture supplied by the original bug reporter https://www.dropbox.com/s/behviox991o01o1/2014-02-23%2016.15.15.jpg
<bjf> jsalisbury, ^^ this seems like it should be on our hot list
<jsalisbury> bjf, ack, I'll add it.
<hatch> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284085
<ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed]
<hatch> there is the ticket again
<jsalisbury> hatch, I also just posted some comments in the bug report on testing older kernels or Ubuntu releases.
<hatch> oh ok awesome
<hatch> I'd be more than happy to help debug/test anything too as it sounds like you're not able to reproduce
<bjf> hatch, did this work with an earlier version of trusty or any saucy?
<jsalisbury> hatch, you can either download prior kernels and install them on your current install, or create a LiveCD with the prior Ubuntu releases.
<hatch> bjf honestly I haven't tried that - I could though
<hatch> I've just been running a vm on top for work
<bjf> hatch, that would help us identify if it a specific, recent commit or it's been broken forever
<hatch> alright tonight I'll give saucy a go, and the latest trusty
<hatch> thanks for the help
<jsalisbury> hatch, cool.  If we find it's a regression, we can then perform a bisect to identify what commit introduced it.
<hatch> awesome - we have a sprint coming up...I dont' want to take any OSX heat if I can avoid it :P
<jsalisbury> hatch, your boot dmesg seems to indicate that you have 8 cpus when you booted 3.13.0-8.28-generic: https://launchpadlibrarian.net/167437657/BootDmesg.txt
<jsalisbury> [    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:8 nr_node_ids:1
<jsalisbury> [    0.000000] PERCPU: Embedded 29 pages/cpu @ffff88026f200000 s86400 r8192 d24192 u262144
<jsalisbury> [    0.000000] pcpu-alloc: s86400 r8192 d24192 u262144 alloc=1*2097152
<jsalisbury> [    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
<hatch> jsalisbury I wasn't the original bug reporter, but my message was the same
<jsalisbury> hatch, ah, ok, so that isn't your system.
<hatch> no I have a MBP which hung on the same spot that was shown in the image linked in the bug
<hatch> sorry I thought that meant it was only reading a single core
<hatch> I really know nothing about the kernel :)
<jsalisbury> hatch, ok, so it hangs at that spot you posted in the picture?
<hatch> not my picture.....hangs in the same spot :)
<jsalisbury> hatch, ok.  It will still be good to know if this is a regression, which would allow us to bisect.
<hatch> yeah definitely
<hatch> I'll wipe the partition and try saucy, if that's successful then I'll try the latest trusty
<hatch> if neither work are there any logs or anything that would be beneficial? 
<jsalisbury> hatch, you could just try booting a LiveCD, which might be quicker.  It might also be good to just open a new kernel bug, which would give us all your logs.  It can then be marked as a duplicate.  You can open a new kernel bug by running this from a terminal:
<jsalisbury> hatch, ubuntu-bug linux
<jsalisbury> hatch, Basically to boot from a LiveCD, select "Try Ubuntu" install of Install Ubuntu.
<hatch> yeah ok - so that will run through all of the same stuff as running on metal?
<jsalisbury> hatch, yes, it will just boot off the flash drive instead of booting from your hard disk.
<hatch> oh ok - I assumed that it would be different for whatever reason so I didn't try
<jsalisbury> hatch, Anything you do while booted to the LiveCD wont be saved to your hard disk, but it will exercise the kernel and let us know if that kernel version has the bug or not.
<hatch> Yeah I knew it woudln't touch the disk but good to know that it'll run the same stuff in the kernel
<jsalisbury> hatch, just to confirm, you were able to install Trusty fine, but this bug happened once you rebooted?
<hatch> yeah I rebooted right away though
<jsalisbury> hatch, ok.  maybe run dmesg and save it if you are able to boot a liveCD.  Something like:
<jsalisbury> sudo dmesg > dmesg.out
<jsalisbury> Then copy that file off the system, so it can be reviewed
<hatch> ok can do
<hatch> I'm on the machine right now just finishing up some work so once I"m done I can give that stuff a go
<jsalisbury> hatch, if you are able to boot a LiveCD.  You can then install that kernel version onto your Trusty install and see if the bug goes away.  
<hatch> ahh good idea
<jsalisbury> that will confirm it's a regression or not.
<jsalisbury> hatch, cool.  I'm finishing up for the day, but I'll check with you first thing in the morning.  You can either update the bug report, or just send me email.
<hatch> sure will do thanks again for your help
<jsalisbury> np
#ubuntu-kernel 2014-04-03
 * smb waits for some theatrical moves from northerly directions
 * apw yawns very sensibly
<zequence> infinity: Is the precise 3.2 kernel no longer being SRUd?
<infinity> zequence: It is, it just didn't have any updates last cycle.  It has some this time.
<infinity> zequence: See launchpad.net/bugs/1300871
<zequence> infinity: ah, sorry. I missed it.
<apw_> cking: just lost some of my Internet or a vps or something
<cking> apw_, ack
<ogasawara> rtg, apw: pmcgowan is telling me his kernel is causing panics this morning.  it started yesterday.  he says it's networking related.  I'm having him snag a picture to throw in a bug report.
<ogasawara> rtg, apw: will also have him test on an older kernel to confirm it goes away
<rtg> ogasawara, brcm ?
<ogasawara> rtg: am grabbing his system info
 * apw wonders what release he is on
 * apw thought yesterdays update was pretty benign ?
<ogasawara> I've asked pmcgowan to jump in here
<pmcgowan_> ogasawara, the problem cannot be reported, this is not an official Ubuntu package
<apw> ?
<pmcgowan_> linux-image-3.13.0-20-generic
<apw> it really is
<ogasawara> that's a bit odd
<apw> what version is it .... dpkg -l linux-image-3.13.0-20-generic
<rtg> it should be 3.13.0-22.44
<pmcgowan_> its 3.13.0-20.42
<apw> so that was not yesterdays kernel, nor indeed the one before ?
<pmcgowan_> I would have been running it for days then
<apw> is -20.42 the good one, or the new bad one
<pmcgowan_> the one that panic'd
<apw> did you get a piccy, leann mentioned you were putting it in the bug, what was the # / link to the piccy
<pmcgowan_> no pic sorry, I had shut it down by then
<pmcgowan_> and ubuntu-bug wont let me report
<pmcgowan_> I can dist-upgrade and see if it occurs again, then properly record it
<pmcgowan_> apw, I dont have anything for you guys right now, so how about I get the newer kernel
<apw> works for me
<pmcgowan_> oops there it goes
<pmcgowan_> maybe its this bt device
<pmcgowan_> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301990
<ubot2> Launchpad bug 1301990 in linux (Ubuntu) "Samsung N9 Kernel panic" [Undecided,New]
<apw> pmcgowan_, that is still -20.42 btw
<pmcgowan_> apw, right it crashed before I got to upgrade
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301990/comments/3
<ubot2> Launchpad bug 1301990 in linux (Ubuntu) "Samsung N9 Kernel panic" [Undecided,New]
<pmcgowan_> apw, must be this bt trackpad, thats whats different
<Sarvatt> theres a patch on lkml and that bug for it if it didn't just start happening recently, should have been broken from 3.11 and up http://www.spinics.net/lists/linux-bluetooth/msg41725.html
<pmcgowan_> Sarvatt, I have not paired this device for months so I would not have seen it
<Sarvatt> ah https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1252874 too, sheesh
<ubot2> Launchpad bug 1252874 in linux (Ubuntu) "Kernel panic shortly after pairing Apple Magic Touchpad" [High,In progress]
<apw> Sarvatt, ok this would be fixed in 3.14-rc8 then ...
<apw> pmcgowan_, i'll pull that in if i can and let you have a test kernle, though i suspect it wont' make the release kerenl
<apw> but it owuld be eligable to sru anyhoo
<pmcgowan_> apw, ok cool
 * pmcgowan_ finds his paperclip
<bjf> rtg, hatch pinged us yesterday about bug #1284085 which seems bad. haswell macbooks (pro and air) not booting trusty
<ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed] https://launchpad.net/bugs/1284085
 * hatch waves
<rtg> bjf, does it work on yours ?
<hatch> I'll do the acpi dump tonight 
<bjf> rtg, yes but mine isn't haswell
<bjf> rtg, however, my haswell desktop and one other haswell system work just fine
<hatch> re the comment from sforshee, both of us in the bug are using rEFInd
<rtg> hmm, I've got a haswell desktop
<bjf> yes you do
<rtg> hatch, your workaround was to use something other then grub, right ?
<rtg> IIRC
<apw> rtg, bjf, ok i was involved in this many moons ago, one good thing is there is a work around "nr_cpus=1" or something
<hatch> rtg I've never been able to get it to boot
<sforshee> I've got a couple of haswell systems which are fine
<apw> so it can be fixed postumously
<hatch> I'll try the nr_cpus again because I think I was using it incorrectly
<apw> sforshee, i see you commented just an hour back or something
<bjf> sforshee, do you have a haswell macbook?
<sforshee> bjf: not a macbook
<hatch> but a single cpu is kind of.....not acceptable :)
<sforshee> but there's an upstream bugzilla that indicates that only csm boot is affected, native efi boots fine
<apw> hatch, yes but if there is a way to boot it a later update can be installed to fix it
<apw> if it cannot be booted at all we are in a hole
<apw> which is why the first thing we didi was find a way to boot it
<hatch> yeah - ok I'll try to boot it in about 30mins and see what happens
<sforshee> hatch: I looked at your dmesg and I'm pretty sure it was not an efi boot
<hatch> I just guessed where to put the nr_cpus in the list
<hatch> sforshee not my dmesg
<hatch> :)
<sforshee> okay, well the one on the bug then :-)
<hatch> haha, ok so is there a specific place the nr_cpus=1 should go?
<apw> hatch, on the kernel command line, so whereever you specifiy that 
<hatch> apw in grub I put it at the top of the command list and nothing happened
<apw> i asume you have grub installed, so yuoo can hold shift to talk to that
<apw> and put it where the otehr kernelly bits are
<apw> at the top, no, i think hte line starts "linux"
<sforshee> grep quiet /boot/grub/grub.cfg
<sforshee> er
<apw> yeah where quiet is in that output, on the same horizontal line as that
<hatch> ok thanks, after the calls this am I'll get on that 
<bjf> if he can't boot how is he going to make these changes?
<hatch> bjf I can get to grub
<hatch> so hopefully I can get nr_cpus to work
<bjf> hatch are you using the +mac iso ?
<hatch> bjf I tried both
<hatch> should I be?
<bjf> hatch, i have to use the +mac on mine, so that's the one i'd use
<hatch> ok sure
<bjf> hatch, remember mine is not haswell
<hatch> yeah, I read online somewhere that I shouldn't use the +mac for haswell...but so far the outcome has been the same
<bjf> hatch, are you using bootcamp, refit, something else ?
<hatch> I'm not sure what the difference is
<hatch> rEFInd
<sforshee> hatch: which install image did you use? The normal desktop one or the mac one?
<hatch> I tried both last night - I think the currently installed is the 13.10 from the public download page
<sforshee> hatch: oops, I see bjf already asked
<apw> hatch, when you are booted successfully could you find out which grub bits are installed 'dpkg -l | grep grub'
<rtg> bjf, sforshee - looks like another failure to boot on Apple: https://bugs.launchpad.net/bugs/1301590
<ubot2> Launchpad bug 1301590 in linux (Ubuntu) "System does not boot" [High,Confirmed]
<hatch> 13.10 runs surprisingly well on a single core
<hatch> adding the acpi, dmesg, and grub outputs to the ticket
<hatch> hope those help solve the problem :) anything else let me know and I can try it out https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284085
<ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed]
<hatch> sforshee so are you saying that I'm choosing the incorrect option in rEFInd after creating the livecd? There were three options, I just picked the one which actually made sense, the others were just paths to grub if I remember correctly
<hatch> this is the instructions followed for creating the bootable usb stick http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-mac-osx
<sforshee> hatch: so all that stuff in those instructions are completely unnecessary nowadays, at least for recent macs
<sforshee> you can just dd the image to the usb stick
<hatch> well then.... lol
<sforshee> and the option which is a path to grub is what you really want
<sforshee> we should probably still be able to boot the way you did it though, unless apple really screwed something up in the bios emulation
<hatch> entirely possible
<hatch> haha
<sforshee> but I don't recommend using bios emulation, sometimes they turn off features there
<hatch> and should I use the +mac image? I don't know what the difference is
<hatch> http://cdimage.ubuntu.com/daily-live/current/
<sforshee> I've been using the desktop image for at least a year now on macs without any problems
<hatch> ok sounds like a plan
<hatch> well I hope this was just me screwing this up all along
<sforshee> hatch: once you've booted efi though I'd like to get another acpi table dump to compare with the one under bios emulation
<hatch> you bet - I won't be able to do that until tonight though
<sforshee> because really assuming that Windows can boot under the Apple emulation, we should be able to also
<sforshee> but it's also curious that you can do it from the live image, which makes me wonder if grub is doing something to contribute to the problem
<hatch> yeah the liveimage boots just fine
<hatch> any grub related commands you'd like the output from?
<sforshee> not off the top of my head, I'm no grub guru
<hatch> I found it odd that rEFInd dumps me into grub after selecting the Ubuntu install.
<hatch> so maybe using the EFI install that will also be fixed
<sforshee> hatch: I believe displaying the grub prompt is the default whenever other OSes are detected
<sforshee> or the grub menu, rather
<hatch> ohh ok
<rtg> dannf, do we generate arm64 installation images somewhere ? I found some stuff here: http://cloud-images.ubuntu.com/trusty/current/
<dannf> rtg: http://ports.ubuntu.com/ubuntu-ports/dists/trusty/main/installer-arm64/current/images/generic/
<rtg> dannf, thanks
<the_fifteenth> Just wanted to let y'all know, there might be a bug
<the_fifteenth> Holding alt+sysrq and pressing r then j crashes the kernel. B won't even reboot
<the_fifteenth> J is supposed to do an emergency thaw by the way
<dannf> apw: LP: #1063895 - should i move that to fix-released ?
<ubot2> Launchpad bug 1063895 in linux (Ubuntu) "arm64 support to generate linux-source for crosstool bulds" [Medium,In progress] https://launchpad.net/bugs/1063895
#ubuntu-kernel 2014-04-04
<ra123445555> SIOCGIFHWADDR means
<ra123445555> ifconfig says my wifi interface is not available but if i give ifconfig -a then i am getting why so?
<apw> dannf, yeah that must be fixed i am sure, someone in there
<smb> apw, Go away! You are not supposed to be here
<cking> +1 ^^
<Kaloz> I should have waited for feedback on 14.04 :P
<Kaloz> sound sis gone, deja-dup-monitor is eating all resources, NM's gui greys out every option and manual configuration is gone
<infinity> Kaloz: apt-get update, dist-upgrade, and reboot.  Most of all of that was caused by a broken logind upload.
<infinity> Kaloz: You want systemd-services 204-5ubuntu17 or higher.
<Kaloz> infinity: thanks, I give it a shot :)
<apw> smb, cking, nothing to see here
<smb> apw, nope, that is why you should not bother to look. ;)
<apw> smb, heh like i would do that
<smb> apw, hope dies last :-P
 * apw is suitibly beaten, and wanders off for FUN
<smb> +1 to that
<Kaloz> infinity: thanks, worked. was reasing throught everything i915/alsa related, never would have thought it's systemd
<Kaloz> s/reasing/reading/
<infinity> Kaloz: Turns out that when logind crashes consistently and doesn't give you any XDG_*_DIR environment, the modern desktop world goes a bit sideways.
<brendand> if a system supports hybrid s3, is that a seperate state in /sys/power/state?
<brendand> or do we need to check somewhere else to see if it's supported
<brendand> is that 'freeze'?
<mjg59> brendand: What do you mean by hybrid s3?
<mjg59> If it's supported by the firmware then it doesn't (currently) appear in /sys/power/state
<mjg59> The other implementation I know of is in uswsusp
<brendand> http://en.wikipedia.org/wiki/Sleep_mode#Hybrid_sleep
<brendand> mjg59, i guess i'm talking about fw implementation
<mjg59> brendand: I think that's an article written by someone who doesn't understand the technology
<mjg59> But I think the answer is /sys/power/disk contains "suspend"
<brendand> mjg59, so what i mean is, what pm-suspend-hybrid does
<mjg59> brendand: Right, check whether /sys/power/disk contains "suspend"
<brendand> mjg59, it sure does
<mjg59> Then it's supported
<brendand_> mjg59, pm-suspend-hybrid kills my system, so i just wanted to check it's not related to hybrid s3 being unsupported
<mjg59> It ought to fail if it's unsupported
<mjg59> All it does is (effectively):
<mjg59> echo suspend >/sys/power/disk
<mjg59> ehco disk >/sys/power/state
<jsalisbury> rtg, apw, Should I ask paolo to take a look at bug 1302245 ?  It's an ARM config change request.
<ubot2> Launchpad bug 1302245 in linux (Ubuntu) "mmap_min_addr blocks armhf binary support on arm64" [Medium,Confirmed] https://launchpad.net/bugs/1302245
<bjf> jsalisbury, i don't think either of them are around today
<jsalisbury> bjf, ahh, right.  I'll send email then.  thanks
#ubuntu-kernel 2014-04-05
<rigo> hi
<rigo> is there a way to dunno.. "request" a driver to build in to the new kernel?
<JanC> rigo: you mean rebuild a driver that is not part of the kernel on kernel-upgrades?
<rigo> no, i guess not. i mean if i install the latest kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/ my new device is automatically recognised. so supported "out of box"
<rigo> so it would be wonderful to have the tevii S662 usb dvb-s2 driver in the next kernel release.
<JanC> if you want mainline kernel to support your device, you'll have to talk to the upstream kernel developers (and possibly also to the devices manufacturer(s))
<JanC> (maybe the Ubuntu kernel developers can help with that)
<JanC> rigo: actually, the manufacturer working with the upstream kernel project would probably be best, if they want to...
<rigo> it is a pain in the ... to install a driver.. :/
<rigo> in example the s471 card was not supported in the 3.4 but was in the 3.6. so i didnt had to wait a lot. maybe ill be lucky this time too
<JanC> if the manufacturer, or somebody working with them, is working on those drivers, it might work soon
#ubuntu-kernel 2014-04-06
<apw> JanC, yeah, that ... or only buy from h/w manufacturers who have drivers already, let their money do the talking
<ZeuZ> Hi, I've got a question regarding the kernel patches applied by Ubuntu. Is it ok for this to be asked? 
<Snowhog_> ZeuZ: 04/06/14 [08:59:21] * Topic for #ubuntu-kernel is " Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 8th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!"
<ZeuZ> Are kernel patches from the ubuntu team released somewhere as .patch files? 
<ZeuZ> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
<ZeuZ>  fails, with "access denied or repository not exported: /ubuntu/ubuntu-maverick.git" is it just me? 
<TJ-> ZeuZ: My remotes list has Lucid and Natty but no Maverick; not sure if that is because it isn't there, or just that I never wanted it
<TJ-> ZeuZ: I think you want this: http://kernel.ubuntu.com/git?p=ubuntu-archive/ubuntu-maverick.git;a=summary
<ZeuZ> TJ-, Thanks, I think I'll start by grabbing saucy wich is the last version that works with my hardware though
<TJ-> ZeuZ: The trick is, the EOL (end of life) releases move to 'ubuntu-archive', but most published Wiki pages don't mention that
#ubuntu-kernel 2015-03-30
<apw> cheater, i'd say that my experience with btrfs is that it is not production ready
<cheater> apw: ok.
<guite> Hi everyone, Iâm trying to compile the kernel driver âbtusbâ. I succesfully recompiled it by doing Â« make drivers/bluetooth/btusb.koÂ Â» but when I try to activate it with Â« insmod btusb.koÂ Â» I have the following error: Â«Â insmod: ERROR: could not insert module drivers/bluetooth/btusb.ko: Invalid module formatÂ Â»
<guite> the patch I applied is so tiny, I canât understand what can be wrong with it => https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/bluetooth?id=8f0c304c693c5a9759ed6ae50d07d4590dad5ae7
<mozmck> how do I build a linux-libc-dev package with the ubuntu build system?  I ran fakeroot debian/rules binary-indep, fakeroot debian/rules binary-perarch, and fakeroot debian/rules binary-my_custom_flavour, and it did not generate linux-libc-dev.
<apw> mozmck, a derivative does not.make it
<apw> mozmck, there can only be.one kernel in the archive which does because it is the one th compiler and libc build with
<mozmck> hmm, so what does that mean practically?  I need to compile the generic flavour?
<apw> mozmck, it means you shoulf use the lonux libc dev from the archive if you are using libc from the archive
<mozmck> ah, ok.  I assumed it needed to be the same version as the kernel
<mozmck> thanks
<apw> nope, its used by things which happen long before your kernel gets built
#ubuntu-kernel 2015-03-31
<ytrezq> Hello, any ideas for this : http://stackoverflow.com/q/29357563/2284570#comment46899862_29357563 ?
<apw> ytrezq (N,BTFL), if that was doable then the world would be a lovely place
<arges> /join #ubuntu-release
<apw> arges, having fun ?
<arges> apw: : ) maybe its me,but i'm blaming the keyboard
<apw> arges, works for me, i tend to blame unity, then the keyboard
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 7th, 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.
#ubuntu-kernel 2015-04-01
<kyugyi> .
<kyugyi> did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi> plz, send my qs to help limiting usa&israel aggression against others.
<kyugyi> .did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi> .
<kyugyi> did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi> plz, send my qs to help limiting usa&israel aggression against others.
<kyugyi> .did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi> plz, send my qs to help limiting usa&israel aggression against others.
<kyugyi> .
<kyugyi> did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi> plz, send my qs to help limiting usa&israel aggression against others.
<kyugyi> .did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi> plz, send my qs to help limiting usa&israel aggression against others.
<ytrezq> Hello, do you know how I can merge patches : http://stackoverflow.com/q/29357563/2284570#comment46899862_29357563 ?
<apw> ytrezq, there is no way to automatically merge patches which conflict
<apw> that is the definition of a conflict, that they cannot be automatically merged
<leitao> I have a question regarding kernel compilation in LTS and standard release. 
<leitao> If we move Ubuntu 15.10 on POWER8, i.e, mcpu=power8, will it affect 14.04.4 release? I.e, will 14.04.4 required POWER8 also?
<leitao> Looking at launchpad, it seems that both are compiled using different parameters, which means that 14.04.4 will continue to be POWER7 and 15.10 will be POWER8, even sharing the 'same kernel'.
<leitao> Am I correct here?
<infinity> leitao: The backport kernels are compiled on the target release, so if we're just talking about chaning compiler defaults, no, that won't change in trusty.
<leitao> infinity, makes sense
<infinity> leitao: If we change anything in the kernel build itself to target P8 as a minimum, then we'll want to undo that in the lts- branches.
<infinity> leitao: Assuming that supporting the LTS on P7 remains a goal.
<infinity> leitao: But that's another discussion.
<leitao> infinity, that is right. 14.04 will continue to be POWER7, that is a safe assumption
#ubuntu-kernel 2015-04-02
<taihsiang> henrix,  I am testing proposed kernels for certification this cycle. there is no lucid kernel update, isn't it? thanks.
<infinity> taihsiang: No lucid this cycle, no.  You can get the full overview here: http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
<taihsiang> infinity, thanks, got it.
<exebat> Hi all
<exebat> I have a problem with Ubuntu 14.04 USB devices not being available on boot until repluged
<exebat> What might I do to fix it ? It worked just fine on 12.04
<apw> exebat, the normal thing is to check for dmesg errors, if there are osme then there may be hope of figureing it out from those, so you'd file a bug against linux after the failed boot
<smoser> hey. random curious thing...
<apw> exebat, if there is no obvious clue then it becomes a hunt for when it stopped working, a bisect as it were, and for that we normally suggest again filing a bug against linux and somene can help talk you through the how of it
<smoser> is there any way to query "how long has hardware been up" or "when was hardware turned on".
<apw> exebat, either way a bug is needed, file using "ubuntu-bug linux"
<smoser> i'm aware of issues with clock changing, so that 'date' wouldnt be always relevant, but just curious.
<apw> isn't that uptime ?
<smoser> /proc/uptime tells me when kernel started running
<smoser> which is after bios + after grub + after grub loaded kernel and initramfs ..
<smoser> which is ages :)
<apw> efi does give you some information
<apw> if you have efi then systemd-analyse gives you some breakdown before kernel
<smoser> hm.
<apw> not that i have a clue how it gets that information
<apw> other than it is efi informaiton
<smoser> dont have thta on the 2 systems i'm looking at (which are not efi :)
<smoser> but that is really nice. i didn't know about that.
<shirgall> I was tihnking it was in dmidecode somewhere, but I didn't find it. :/
<smoser> yeah, well, dmi data is notterribly consistent in my experience
<shirgall> Aye
<smoser> but yeah, i kind of thought it might be there too
<shirgall> 'facter' tells a lot, but only the OS uptime.
<bjf> stgraber, i'm still getting the failure in lxc-test-apparmor. is that correct?
<bjf> stgraber, that's for vivid
<stgraber> bjf: yep
<stgraber> bjf: hallyn pushed a fix to cgmanager which unblocked lxcfs and some other test failures for LXC, but the apparmor testcase still hangs or fail, it's next up on the list
<bjf> stgraber, ok, thanks for the info
<studio_> hi
<studio_> anybody here?
#ubuntu-kernel 2015-04-03
<jerryt> We're running a Dell server with hardware raid.  When we do IO operations such as extracting a large tar file a kworker process pegs IO at 99% or so.  pref points to cpu_startup_entry 
<jerryt> Any ideas?
<JanC> jerryt: obvious question: is that real hardware RAID or fake hardware RAID which relies on the drivers/CPU to do the hard work? also: how large is the tar file compared to RAM?  and does it use compression and/or encryption?
#ubuntu-kernel 2015-04-04
<nusch> hello, could somebody explain what is ubuntu-way of putting proper modules in initramfs modules file ? I have messed up totally my setup , reinstalled grub, kernel, initramfs after deleting /etc/initramfs-tools and /usr/lib/initramfs-tools
<nusch> is there any script that will rebuild in or does installer(during luks, lvm config) modify intramfs file directly ?
<apw> nusch, update-initramfs from initrsmfs-tools makes the initramfs
<apw> and it copies in the config from root
<nusch> @apw I removed all content from /etc/initrafs-tools, reinstalled by apt-get and there is no /etc/initramfs-tools/initramfs.conf - is that file part of another package? Also about all  crypto modules - do I need which particular include in initramfs or is there any script that will populate those after reading partitions format ?
<infinity> nusch: Deleting conffiles is remembered by dpkg, they're not restored by default, as that would be overriding the sysadmin's changes.
<infinity> nusch: Reinstalling with "dpkg -i --force-confmiss foo.deb" will bring them back.
<DalekSec> Nice.
#ubuntu-kernel 2016-04-04
<genkgo> jsalisbury: great job on figuring out the last good and first bad kernel
<genkgo> now i am really wondering what the cause of the read-only problem is... especially because it could be non-storage related, right?
<leitao> any idea when the new 4.4.0-18 kernel will be released for 16.04?
<kamal> leitao, it won't be until next week at the earliest (-17 just landed in -proposed a few days ago, and -18 hasn't been constructed yet)
<leitao> kamal, hmm, so maybe I want -17.  If the bug is "fix commited", I understand that it is being considered in -17, correct?
<kamal> leitao, not necessarily --- there are a bunch of fixes committed on top of -17 too.  which bug or commit are you looking for?
<leitao> kamal, 1546439 
<kamal> leitao, that fix is not in -17, sorry  (I do see it in the Xenial repo -- it'll be in -18 when that gets constructed)
<kamal> e7f2f51 UBUNTU: SAUCE: block: partition: initialize percpuref before sending out KOBJ_ADD
<leitao> kamal, thanks
<leitao> kamal, now I understand how you guys manage it. You have a -next branch, and creates a commit for each release.. I just need to check if the commit is below or above a certain commits (as -17). 
<leitao> Thank you
<kamal> leitao, ah yes -- master-next is the thing to look at.  glad I could help.
<kamal> leitao, and yes, "Fix committed" specifically means, "we committed it to our master-next branch"
#ubuntu-kernel 2016-04-05
<pixel6692> Hello is there way to get/make/build linux-image-extra for 4.5 (15.10)? I need aufs module and I also need to use 4.5 because of my ethernet driver
<xnox> pixel6692, usually one can find ethernet driver as a dkms module on e.g. github and use that with 15.10 kernel.
<xnox> pixel6692, note that e.g. even 16.04 has 4.4 kernel, but with some backports
<pixel6692> I am currently running 4.5 from here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/ I just need aufs module
<pixel6692> that is typicaly in package linux-image-extra (which is not in this tree), I am trying to build it with this module now
<pixel6692> my ethernet driver was repaired in 4.5
<cryptohwlinuxhel> what function can I use from the kernel to copy a __user pointer to another __user pointer? can I just do memcpy?
<apw> cryptohwlinuxhel, it seems unintuitive to want to copy userspace to userspace (within the same process) in a system call, i beleieve you cannot use mempcy as the kernel handles faults for userspace addresses differently if you are in a call it expects to touch userspace
<cryptohwlinuxhel> yeah there is a flag I have to set to bypass what my driver does
<cryptohwlinuxhel> so the bypass is to simply do a memory copy from one _user pointer to another
<cryptohwlinuxhel> it cannot be done from outside the kernel since it is a driver
<cryptohwlinuxhel> also the kernel gives this flag a shared common memory that all processes can see
<cryptohwlinuxhel> so what can I use if I cannot use memcpy?
<cryptohwlinuxhel> I can always allocate local memory copyfromuser to my local buffer and then copytouser from my buffer but that is not efficient and I would like to avoid it
<apw> i am not sure there is one, but i have not looked, you will find copyfromuser etc are marked specially as copiers, so you could look at what other calls are the same
<cryptohwlinuxhel> what do you mean they are marked as copiers?
<cryptohwlinuxhel> http://lxr.free-electrons.com/source/arch/arm/include/asm/uaccess.h#L552
<cryptohwlinuxhel> I see no markings
<tych0> i'm trying to build a kernel from xenial's current master, and i'm getting, http://paste.ubuntu.com/15633017/
<tych0> any ideas?
<genkgo> jsalisbury: nice achievements again on the backup issue
<jsalisbury> genkgo, getting closer.  I may have to perform a bisect of the entire tree, which will take a few more days of testing
<pesari> hey, have you seen this with xenial-proposed 4.4.0-17 ? https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1564951
<ubot5`> Launchpad bug 1564951 in systemd (Ubuntu) "systemd-timesyncd: Failed to call clock_adjtime(): Invalid argument" [Undecided,Confirmed]
<genkgo> jsalisbury: i am really really wondering what it is
<genkgo> jsalisbury: probably nobody ever thought of
<genkgo> *something
<genkgo> and might fixes other things too
<jsalisbury> genkgo, Yeah, it isn't any of the hv commits or virtio commits between these two releases.  That's why sometimes a bisect is needed to identify the real offending commit.
<genkgo> jsalisbury: the virtio commits are also not the problem?
<jsalisbury> genkgo, no.  I built a test kernel with them all reverted and I still hit the bug in about an hour.
<genkgo> ok
<kamal> tych0, your problem there is (I think) that you're trying to build with just 'make' ...  to build an Ubuntu kernel, follow the "Building the kernel" instructions here:
<kamal> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<kamal> specifically:
<kamal> fakeroot debian/rules clean
<kamal> fakeroot debian/rules binary-generic
<tych0> kamal: ah, interesting, ok
<kamal> tych0, that ^^ will build security/apparmor/ just fine.    (whereas, with bare 'make', the thing you reported is indeed the first failure I get too).
<tych0> interesting; it used to work with make bindeb-pkg before that patch :)
<genkgo> jsalisbury: thanks, looking forward to the end result! you must tired of all these backups by now ;)
<tych0> although perhaps i was doing something horribly wrong
<jsalisbury> genkgo, heh, not tired yet.  It too much of a fun puzzle.  The wait while testing is the pain.
<genkgo> jsalisbury: hehe, alright. glad to hear you still got the spirit!
<kamal> tych0, hmmm.  well if it used to work (when exactly?) then it probably should still -- maybe we actually do have a new glitch to sort out.
<tych0> kamal: yeah, it used to work as of a few weeks ago with the xenial kernel's master
<tych0> let me look for the exact ref
<jsalisbury> genkgo, We'll get to the bottom of this. 
<tych0> kamal: f35781cd96795075436fde15abfc1b94bdffb99c
<kamal> tych0, yup, you've got a point there!
<tyhicks> tych0: looks like this would do it: https://paste.ubuntu.com/15634420/
 * tych0 builds
<tych0> tyhicks: but yeah, that looks suspicious :)
<tych0> tyhicks: yeah, that fixes it
<tyhicks> tych0: thanks - I'll send a patch to the kteam
<tych0> tyhicks: cool, thanks
<kamal> tych0, tyhicks: nice job ty-team!  ;-)  thanks
<tyhicks> heh :)
<tych0> i have to be useful every once in a while if i'm going to troll tyhicks' tab completion everywhere
<kamal> :-)
<tyhicks> jjohansen: ^ FYI so you know the reason for the patch that I'm about to send out
<jjohansen> I'm not sure why our builds didn't catch that
<tyhicks> me neither
<tyhicks> jjohansen: are you wanting to understand it more or should I go ahead and send out the patch?
<jjohansen> tyhicks: just send the patch
#ubuntu-kernel 2016-04-06
<yofel> FYI: lp 1566726
<ubot5`> Launchpad bug 1566726 in linux-lts-utopic (Ubuntu) "System freeze after update to 3.16.0-69-generic [NULL pointer reference in radeon_fence_ref]" [Undecided,New] https://launchpad.net/bugs/1566726
<infinity> That sounds ungood.
<infinity> jsalisbury: ^-- Care to escalate that a bit?
<apw> kamal, ^
<jsalisbury> infinity, thanks for the pointer on that bug.  yofel, I'll post a test kernel shortly.
<jsalisbury> apw, kamal, looks like the offending commit is already reverted in -next:
<jsalisbury> a907233 Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"
<jsalisbury> 72a5cff drm/radeon: hold reference to fences in radeon_sa_bo_new
 * jsalisbury is building a test kernel of -next for testing
<kamal> jsalisbury, ha!  yup, I was _just_ confirming exactly that with Luis.
<kamal> jsalisbury, that is indeed the fix, and yes, its already committed.   How about you build a test kernel (either of the top of utopic-next, or with just that revert applied), so we can get the bug submitters to verify it?
<jsalisbury> kamal, I have test kernel of the top of utopic-next building now.  I'll have it verified
<kamal> jsalisbury, very good, thanks
<jsalisbury> np
<kamal> jsalisbury, also fyi, I've determined that the problem should only affect 3.16 (so Utopic only, no other Ubuntu kernels)
<jsalisbury> great
<dschatzberg> hey all, I'm trying to test an upstream kernel (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc2-wily/), how do I apply the patches provided? Applying them naively doesn't seem to set the permissions right?
<genkgo> jsalisbury: exciting, coming really close now
<genkgo> where can i look that bad commit 5044635f00, is that a commit from linus?
<genkgo> i mean linus' repo linux on github
<jsalisbury> genkgo, yes, it's in Linus' tree.  That particular commit isn't the cause.  That was just the tip of the kernel tree for that test kernel build.
<genkgo> ok, i think i don't get what a bisect actually means
<genkgo> i will read upon that
<jsalisbury> genkgo, there is a wiki page that has some info: https://wiki.ubuntu.com/Kernel/KernelBisection
<genkgo> jsalisbury: wonderful, i will read that!
<genkgo> jsalisbury: ah, i get it, it just a fast way to pick a wrong commit
<genkgo> just like you did by picking the latest good and first bad version of the kernel
<genkgo> but only with those sha identifiers it's less obvious
#ubuntu-kernel 2016-04-07
<xnox> apw, https://api.launchpad.net/devel/ubuntu/precise/amd64/chroot_url
<xnox> e.g. points to the chroot, but i thought there was a downloadable url
<xnox> rtg, ^
<infinity> xnox: I usually just go to https://api.launchpad.net/devel/ubuntu/precise/amd64 so it's clickable. :P
<xnox> rright
<xnox> apw, rtg - colin says there is ./manage-chroot in lp:ubuntu-archive-tools that does the right thing
<smoser> hey kernel team. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566468
<ubot5`> Launchpad bug 1566468 in open-iscsi (Ubuntu) "systemd-modules-load.service: Failing due to missing module 'ib_iser'" [Medium,Confirmed]
<smoser> if you could move ib_iser to the linux-image from linux-image-extra, that would be nice.
<infinity> ogasawara: ^ pls to delegate.
<ogasawara> rtg: tag, you're it
<infinity> ogasawara: pls to delegate to someone who will get it right.
 * infinity ducks.
 * rtg admires the timely testing
<infinity> rtg: Don't we all. :(
<infinity> rtg: At least it's not release week, which is when I get most of *my* bugs.
<infinity> "Oh, we were developing an OS for the last 5.7 months, someone should have told me."
<lamont> jsalisbury: any update on bug 1543683 ?
<ubot5`> bug 1543683 in linux (Ubuntu Xenial) "Fails to detect (second) display" [Medium,In progress] https://launchpad.net/bugs/1543683
<jsalisbury> lamont, thanks for the reminder.  I pinged upstream regarding the new bug the patch introduced.  I have not heard back yet, so I'll ping them again.
<xnox> rtg, https://launchpadlibrarian.net/252160450/weightwatchers.patch
<xnox> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536245
<ubot5`> Launchpad bug 1536245 in linux (Ubuntu Xenial) "s390x kernel image needs weightwatchers" [Medium,Triaged]
<xnox> rtg, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536245
<ubot5`> Launchpad bug 1536245 in linux (Ubuntu Xenial) "s390x kernel image needs weightwatchers" [Medium,Triaged]
<xnox> apw, zfcpdump bug https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1565841
<ubot5`> Launchpad bug 1565841 in s390-tools (Ubuntu Y-series) "Provide zfcpdump-infrastructure with Ubuntu 16.04" [Undecided,New]
<infinity> xnox: Do bzImage kernels boot in all the scenarios we care about?
<kirkland> so I'm on an s390x system, running a 4.3 kernel
<kirkland> I'm surprised it's not 4.4
<kirkland> and no update to 4.4 is available
<kirkland> help?
<infinity> kirkland: apt-get install linux-image-virtual?
<kirkland> infinity: interesting;  apt upgrade isn't picking that up
<kirkland> ah, I'm running linux-image-4.3.0-2-generic
<infinity> kirkland: Because you have no meta installed.  I assume that image is ancient and before we had metas.
<kirkland> hmm
<kirkland> infinity: indeed, like 117 days of uptime :-)
<infinity> kirkland: Double-check that /etc/zipl.conf points to "vmlinuz" and "vmlinuz.old" (and matching initrds) before you go rebooting and find you can't.
<infinity> kirkland: Those old installs were a bit broken.
<kirkland> infinity: takes all the adventure out of it
<kirkland> infinity: http://paste.ubuntu.com/15677848/
<kirkland> infinity: does that look right?
<infinity> kirkland: http://paste.ubuntu.com/15677844/ <-- A sane zipl.conf from one of my buildd z/VMs.
<infinity> kirkland: Yours may also work, yeah.  You might want an "old" entry too, though that will only do you any good if you have a console.
<kirkland> infinity: cool, rebooting now
<xnox> infinity, apw kindly pointed out i should test it boots everywhere we care first. cause if they take it in now, there will be no time to unbreak it.
<xnox> infinity, i am pondering if I should post-pone that to the yummy yak & sru
<xnox> and hence .1 release
<xnox> however i will test all things we care about to be bootable (lpar, z/vm, z/kvm, ubuntu kvm, ubuntu kvm iso) both the initial install/load/ipl, and the subsequent installed system booting
#ubuntu-kernel 2016-04-08
<flexiondotorg> Morning.
<flexiondotorg> apw, You might remember I worked with you briefly way back on VirtualBox video device exclusions?
<flexiondotorg> apw, If you have a moment I'd like to draw your attention to a bug I am seeing lots of people starting to encounter now more a test 16.04.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1522922
<ubot5`> Launchpad bug 1522922 in xserver-xorg-video-intel (Ubuntu) "Screen flickering in Intel i915 driver" [High,Triaged]
<flexiondotorg> The opening post identifies 2 commits that can be reverted to resolve the issue.
<flexiondotorg> I have one computer I can reproduce the bug on and happy to help test.
<flexiondotorg> If this something you can assist with?
<fg__> zfsonlinux
<xnox> apw, infinity: tested bzimage kernels everywhere and they all boot. In practice I want this in, however it is not critical to be in .0 release, and I'm totally cool with SRUing this at some later point.
<xnox> however it would be nice to fix.
<kwik> Hey guys, can someone help me understand the output formats of ftrace?  
<kwik> I'd specifically like to know how to read the raw, hex or bin modes  
<kwik> I can't find a relationship between the output of said modes and the formats in events/.../format, neither the timestamp of the event
<lamont> do I care that my syslog is full of these?  (for a long time, I just sometimes get reminded of it..) http://paste.ubuntu.com/15688936/
<lamont> yesterday's top contributors to a 21MB syslog: awk '{print $5}' /var/log/syslog.1  |sed 's/\[.*\]//' | sort | uniq -c | sort -nr
<lamont>  193573 kernel:
<lamont>   11492 lldpd:
<lamont>    5746 snmpd:
<lamont>    1091 CRON:
<lamont> kernel was only 90.8% of the lines
<lamont> and, no, it would surprise me not at all to learn that something was spewing frames onto the wire that were faulty when I finally received them, in this network.
<ChunkzZ> right, nothing edited in grub, screen brightness full....battery says 4 hours...acpi_osi= in grub and screen brightness 0% 4 hours....
<ChunkzZ> what the hell is going on?
<mjg59> Why are you adding acpi_osi?
<ChunkzZ> to change my brightness
<ChunkzZ> it's the only work for to change my brightness mjg59 
<mjg59> ChunkzZ: Well, in the process you're potentially also disabling various power management features
<mjg59> What hardware is this?
<ChunkzZ> asus x501u
<ChunkzZ> I just want my brightness working :(
<ChunkzZ> mjg59, so what should I do?
<mjg59> Well, the best thing would be to figure out why your brightness control doesn't work
<mjg59> Unfortunately that's probably a somewhat hardware-specific issue
<mjg59> Outside that, it seems like all options are bad
<ChunkzZ> it changes if I add acpi_osi=
<ChunkzZ> but in a way it doesn't affect it
<ChunkzZ> weird
<ChunkzZ> suppose I'll have to go back to winblows :/
<ChunkzZ> I love linux too
<ChunkzZ> fuck sake!
#ubuntu-kernel 2016-04-09
<sacarde> hi
<sacarde> can you help me to find, in kernel source, instructions that build bzImage from:
<sacarde> vmnlinux + bootsect.o + setup.o + misc.o + piggy.o 
<sacarde> ?
<sacarde> is true?
<jonf> hi, I have been having problems with the fadvise âwillneedâ system call when using it with large files recently - it was no longer bringing in the entire file (assuming available buffer cache pages) any more, just the 1st 2MB of the file. I have tracked this down to a change in mainline ( commit 6d2be915e589 ), and the discussion around it implies that mainline will stay with this change, but redhat and oracle may patch their kerne
<jonf> is this something that Ubuntu would consider?
<adamsmd> Upstream patch [1] makes wireless work on the "Lenovo ideapad Y700", and path [2] makes it work on the "Lenovo ideapad Y700 Touch".  It looks like [1] was backported to the Ubuntu kernel for 16.04 but [2] was not.  Would it be possible to get [2] backported as well?
<adamsmd> [1] https://github.com/torvalds/linux/commit/edde316acb5f07c04abf09a92f59db5d2efd14e2
<adamsmd> [2] https://github.com/torvalds/linux/commit/4db9675d927a71faa66e5ab128d2390d6329750b
<adamsmd> (I am interested as I just got a "Lenovo ideapad Y700 Touch".)
#ubuntu-kernel 2017-04-03
<tseliot> ogasawara, apw, sforshee: I've just uploaded nvidia-340 in xenial-proposed with the refreshed patch
<tseliot> LP: #1677327
<ubot5> Launchpad bug 1677327 in nvidia-graphics-drivers-340 (Ubuntu Xenial) "dkms build fails with zesty hwe kernel [error: too few arguments to function âNV_GET_USER_PAGESâ]" [High,In progress] https://launchpad.net/bugs/1677327
<sforshee> tseliot: awesome, thanks!
<ogasawara> tseliot: sweet, thanks!
<tseliot> :)
<ivan> can someone please push the Ubuntu-4.4.0-72.93 tag to ubuntu-xenial.git, it's hard to track down commits by the commit subjects in the package changelog
<ivan> hurray I've found them in davem/net.git
<chatter29> hey guys
<chatter29> allah is doing
#ubuntu-kernel 2017-04-05
<elmo> cking: https://bugs.launchpad.net/maas/+bug/1680119 <-- FYI (in case I misrepresented you)
<ubot5> Ubuntu bug 1680119 in MAAS "maas should enable netconsole during commissioning" [Undecided,New]
<cking> elmo, that's ok with me
<hallyn> So I wonder.  does anyone actually regularly run LTP these days to check for regressions?
<hallyn> mainly wondering whether writing new tests for ltp is worthwhile or not
#ubuntu-kernel 2017-04-06
<ivan> why does https://insights.ubuntu.com/2017/04/05/ubuntu-on-aws-gets-serious-performance-boost-with-aws-tuned-kernel/ mention "Disabled CONFIG_NO_HZ_FULL to eliminate deadlocks on some instance types" when it's already N / unset in ubuntu-xenial.git:master?
<mvo> hey sforshee - apw send me your way. I was looking at the testsuite failure of snapd with the latest zesty kernel from proposed. we have some tests that excercise the seccomp filtering. it looks like with the kernel from -proposed we don't get messages like http://paste.ubuntu.com/24327651/ anymore in dmesg which makes the tests fail
<mvo> sforshee: let me know if I can do anything to help with that issue
<sforshee> mvo: yeah I've been looking, unfortunately the snapd tests have been broken for so long I can't tell when this first started happening :-(
<sforshee> mvo: do you know if this happens with the kernel in -release?
<sforshee> mvo: and what's the easiest way to reproduce the problem?
<mvo> sforshee: its fine with the kernel in release
<mvo> sforshee: its broken with the kernel in -proposed
<mvo> sforshee: easiest (for me, ymmv) is git clone https://github.com/snapcore/snapd ; cd snapd/cmd; ./autogen.sh; make check
<mvo> sforshee: let me know if that does not work for you, you may need to do "sudo apt build-dep snapd" first
<mvo> sforshee: but the C parts are light on dependencies so it may work without
<mvo> sforshee: there are three tests failing with the new kernel, they all do dmesg|tail -n1|grep "audit"
<sforshee> mvo: thanks, I'll see what I can find
<jdstrand> mvo: curious if ratelimiting is getting in the way
<jdstrand> mvo: note my (now ancient) mknod PR had a bunch of testsuite improvements in this area
<jdstrand> mvo: are we at a point where we can consider that PR (and the other seccomp arg filtering PRs) again?
<jdstrand> mvo: afaik, we still need this: https://github.com/snapcore/snapd/pull/2810
<mvo> jdstrand: re rate-limiting> I think not, I don't see any audit message at all in dmesg
<mvo> jdstrand: the mknod is close, we still need #3027 first but that one is close, it looks there there is agreement
<jdstrand> mvo: well, that could be a sympton. the kernel is funny like that sometimes
<jdstrand> mvo: ok, cool. I'll keep an eye on 3027. will that be the pr instead of 2810?
<mvo> jdstrand: yes, that is the new direction(the second new direction actually)
<mvo> jdstrand: but close finally :)
<jdstrand> mvo: great to hear :) thanks! :)
<ad-n770> do you have any estimated date on when the 4.10 kernel will land into Ubuntu 16.04 repositories as linux-image-generic-hwe-16.04-edge ?
<infinity> ad-n770: Two days ago.
<ad-n770> oh, it's there
<ad-n770> going to try it
<ad-n770> we had participated in the tracking and fixing of an issue affecting drm/radeon that causes a system lockup under certain loads
<ad-n770> the fix is at https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-4.9&id=03df14330dd6a6cfa91964131e001c1ca58a380f
<ad-n770> what should be the procedure to request it to be backported into Ubuntu 16.04 4.4 kernels ?
<tjaalton> clone ubuntu-xenial.git, backport the patch, send the patch to the list. and file a bug for it, reference it in the patch
<tjaalton> or, ask mrcooper to send it to stable@vger
<tjaalton> takes a bit longer to reach 4.4 though
<ad-n770> thanks
<ad-n770> tjaalton: could please be more specific in which list we should send the patch ?
<tjaalton> kernel-team@
<tjaalton> https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
<ad-n770> thanks
#ubuntu-kernel 2017-04-07
<sforshee> dmj_s76: there's a new linux-firmware in xenial-proposed which includes some iwlwifi updates. Thought you might want to give it a spin on some of your hw to check for problems.
<manjo> apw, Ubuntu-4.10.0-19.21 is final tag ? 
<manjo> arges, ^
<apw> n
<apw> manjo: as in the tag for the release pocket? yes
<manjo> apw, cool thanks 
<apw> manjo: there is no guarantee we will have no respins before release
<manjo> final freeze was yesterday âº 
<manjo> apw, but ack 
<manjo> it probably will be minor delta .. so not worried 
<apw> manjo: and if there are release critical bugs we can break that
<manjo> apw, ack.. thanks a ton.. you are up late âº 
<dmj_s76> sforshee: Just finished testing linux-firmware in proposed.  Everything seems to work fine.  If there are issues, they're in some corner case.
#ubuntu-kernel 2017-04-09
<pjf> Hey ubuntu-kernelers! I've noticed that ubuntu's mainline-crack isn't serving up all the branches it's supposed to. Any advice on where I should be reporting this? I've got a bug-report ready to go ( https://pastebin.com/14muv9Kz ) but reporting it against the kernel package doesn't seem right.
<trevorj> Hi all
<trevorj> I just asked this in #ubuntu, and I'd love some help with this :)
<trevorj> I'm trying to compile a custom kernel module for my Joule running Ubuntu. So, I'm really trying to get my grubby hands on some sweet source code.
<trevorj> (some bg info: Ubuntu released a "beta" release for the joule many months ago, but this contains a local deb of a
<trevorj> compiled kernel. The source debs seem unavailable and are not part of the beta images or any Ubuntu project repo.)
<trevorj> How can I build a kernel for this device? I filed a bug asking for it a month ago, but it hasn't even really been
<trevorj> triaged or assigned at this point :(
<trevorj> It's fine if it's not in a good state, but it's not in vcs and I'm pulling my hair out trying to fix these issues.
<apw> trevorj, i have put out some feelers for that
<trevorj> apw: Thanks a ton!
#ubuntu-kernel 2018-04-02
<s10gopal_> anyone online ?
<teward> s10gopal_: just ask your question and wait around for an answer.
<s10gopal_> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694926 is related to acpi ?
<ubot5> Debian bug 694926 in util-linux "hwclock --systohc at shutdown makes battery drain when laptop is off" [Important,Open]
<s10gopal_> teward, https://bugzilla.kernel.org/show_bug.cgi?id=198665 happens on kernel 4.13 onwards and dont occur on 4.12 , should i test sub version too ?
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
<s10gopal_> TJ- apw , please see
<s10gopal_> TJ-, ?
<dijuremo> Guys, I have another example, a DELL T5810, running the 4.4.0-116 kernel. It freezes with any BIOS past 1.13. I am lucky I have a copy of that BIOS saved, because the DELL site is only listing 1.32 and 1.40, both of which result in the machine immediately freezing when it reaches the GUI login window. That particular machine was running BIOS 1.20 and just by downgrading to 1.13 the machine no longer freezes.
<tomreyn> dijuremo: so you discovered what seems to be a firmware issue. you could try reporting it to the dell then.
<tomreyn> you say "another", was there another system with an identical, or a similar issue?
<TJ-> tomreyn: dijuremo has about 20 different systems now with this 'feature' - we've been working on trying to pin it down for several weeks
<tomreyn> oh, ok, ignore me then. good luck!
<TJ-> seems like a Dell BIOS upgrade that contains the intel microcode updates always seems to break with an ubuntu kernel that also contains the same microcode. It also seems to defy sanity :)
<tomreyn> sanity is for users of processors without ME or PSP, not us commoners.
<TJ-> well sanity in that if BIOS loads the microcode the kernel doesn't so the only explanation is some sublte interaction with the spectre patches, even when nospectre_v2 is in use
#ubuntu-kernel 2018-04-03
<s10gopal> apw, please see https://bugzilla.kernel.org/show_bug.cgi?id=198665 , how to disable "hwclock --systohc" during shutdown ?
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
<apw> i think he did it by stopping the clock update in "/etc/init.d/hwclock.sh" in the stop phase
<apw>                 if false && /sbin/hwclock --rtc=/dev/$HCTOSYS_DEVICE --systohc $HWCLOCKPARS $BADYEAR; then
<apw> ^ i am going to guess that the original script has that line without the initial false && in it
<s10gopal> apw, sorry i am unable to understand it
<s10gopal> cat: /etc/init.d/hwclock.sh: No such file or directory
<apw> s10gopal, hmm, i guess it would be in a systemd unit now, somewhere, sigh
<s10gopal> ubuntu 14.04 dont come with systemd
<apw> odd i have a hwclock.sh on my system so i am supprised you don't
<apw> s10gopal, likely it is /etc/init/hwclock-save.conf
<s10gopal> cat q
<s10gopal> apw, http://paste.ubuntu.com/p/GMP8PMKxFB/
<apw> s10gopal, looks likely from teh description and the commands it executes ... that that is what is writing back your clock
<apw> s10gopal, the test they want you to do is to comment out the bit which updates the clock, the hwclock line there, and then turn
<apw> s10gopal, off your laptop and see how bad the drain is then
<s10gopal> sorry i didnt got it
<s10gopal> apw, you think they will fix it ?
<apw> s10gopal, no they are asking you to test something to see if your bug is the same as another bug
<apw> s10gopal, to find that out they want you to stop the system from updating the clock, which is that line in the file
<s10gopal> the bug which zai posted is reported in 2012 and still it is not fixed
<s10gopal> apw, my problem dont occur upto kernel 4.12
<apw> s10gopal, right, as they decided if wriiting to your clock breaks your machine that that is not really an OS issue
<s10gopal> it starts from kernel 4.13
<apw> s10gopal, so likely this is not the saem problem
<apw> s10gopal, and doing what they ask will prove that and they can realise it is a new problem
<s10gopal> apw, #ubuntu-kernel user's can fix it too?
<s10gopal> apw, can you please guide me, how i can learn linux kernel and driver development ?
<apw> s10gopal, you should be able to comment out that line and do the test they want pretty easily
<apw> as for learnign kernel development you really want to get a book if you are starting from nothing
<s10gopal> which book ?
<s10gopal> is knowledge of digital electronics is also required ?
<apw> i had things like the linux device drivers from o'reilly, but that would be woefully out of date these days
<apw> i can't say i have needed a book for like 15 years, so i have no current suggestions
<s10gopal> and you know about electronics things too ?
<apw> i happen to, but i don't think it is necessary
<s10gopal> first i should read linux book ? 
<dijuremo> There was a typo, should had been DELL 5820, Sorry:      Guys, I have another example, a DELL T5820, running the 4.4.0-116 kernel. It freezes with any BIOS past 1.13. I am lucky I have a copy of that BIOS saved, because the DELL site is only listing 1.32 and 1.40, both of which result in the machine immediately freezing when it reaches the GUI login window. That particular machine was running BIOS 1.20 and just by downgrading to 1.13 the m
<dijuremo> tomreyn: Just as TJ-: explained it is very crazy, but seems like many DELL and Lenovo systems with their latest BIOS result in frozen machines, sometimes just on boot to the ligthdm GUI login screen, sometimes they freeze after login out after a first succesful log in.
<tomreyn> uuh, fun! not!
<tomreyn> dijuremo: your last but one message was cut off after: "That particular machine was running BIOS 1.20 and just by downgrading to 1.13 the m"
<apw> dijuremo, we have had reports of new bios carrying unwell microcode for the cpu
<tomreyn> (due to IRC line length limits=
<apw> dijuremo, have you tested with latest intel-microcode in teh archive ?
<apw> which would have released in teh last couple of days by the looks of it
<dijuremo> apw: By archive you mean the latest PPA repo for Intel-Microcode? We did and both the .deb and BIOS had the same Level.
<apw> dijuremo, i meant the one in -security "now"
<dijuremo> https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/14453957 from 20180313? We tried that microcode
<dijuremo> It matches the microcode in the latest BIOS'
<apw> dijuremo, that looks like the right one
<apw> and if you downgrade your bios and leave that microcode installed does it keep working or continue to break
<dijuremo> Yes, we tried downgrading BIOS with and without latest intel-microcode package. With the older BIOS the machine does not freeze with or without the microcode installed
<dijuremo> All of those tests were conducted on a DELL T3610.
<dijuremo> We have seen the behavior on both DELL T5810 and the new T5820 as well as Laptop 7480 and a Lenovo M93p
<dijuremo> It is easily reproducible. On a Machine with 16.04 either 4.4.0-1116 or 4.13.0 kernels if you install the latest BIOS then the machines freeze.
<dijuremo> Now I have a repo of old BIOS' for these machines, but DELL is no longer posting the very old BIOS' so for other people who cannot get the older BIOS' it will be end of game...
<apw> so is there an older kernel which works this bios or is the bios simply trash
<dijuremo> It is not just one BIOS.
<apw> it is all bioses since 1.13 right ?
<dijuremo> In the DELL T5820 it seems that way.
<apw> that all of them have the issue does not tell us whether the bios or kernl are at fault
<dijuremo> We had one machine on 1.20 which worked OK for a few days then started doing the constant freeze. We downgraded to 1.13 and it worked.
<apw> have you asked dell about it ?
<dijuremo> For the T3610 then you have to stay in BIOS A14 becuase the latest A16 freezes the machine.
<apw> likely whatever they make teh bios kits from is the same and has the saem fixes applied across the board
<dijuremo> Not yet, but as I stated, it is not DELL only. Lenovo M93p is the same issue.
<apw> with a total freeze it is hard to be sure if it is teh same issue, so we should take care
<apw> with making that as an assertion imo
<dijuremo> Also issue with DELL is they would not care likely, they sold the machines with windows, so when I say I am running Ubuntu they are going to say put windows and we will give you support...
<apw> often the way, though many of the machines are certified with ubuntu too
<dijuremo> You are right about the assumption, but it has been very repeatable that the BIOS downgrade fixes the issues. 
<dijuremo> ALso none of the nopti or nospectre_v2 kernel options have helped. And the problem freeze seems to be triggered much faster in GUI mode with Nvidia cards.
<apw> right, but that symptom that downgrading the bios works, would normally say "bios to blame"
<apw> them not caring is somewhat of an orthoganal issue
<apw> if we are to have any real hope of finding out what in the kerenl is tickling the broken bit of the bios
<apw> we would need to find a kernel which does not trigger the issue
<dijuremo> Some machines were working OK until the latest 4.4.0 and 4.13.0 releases... but I have not really tried gong that rabbit whole of trying 4.4.0-abc (older versions)
<apw> so we can find out what changed
<apw> dijuremo, it may also be worth testing the latest kernel which just promoted to -proposed
<dijuremo> Which latest? 4.13.0 the hwe-16.04?
<apw> iirc there is a new 4.4.0
<apw> a -119, you never know it might be the magic bullet
<dijuremo> Where would I find that one?
<apw> xenial-proposed
<JanC> seems like I got bitten by the new intel microcode as it comes with Ubuntu now...
<apw> bitten ?
<JanC> system hanging after first boot with that installed, but it works fine after an UEFI firmware update
<apw> that sounds a bit mad on first reading
<JanC> at least, I hope it works fine; it was hanging during boot every time and I can work now...
<apw> tyhicks, ^ food for thought on the "when to add hard depends on microcode" debate
<JanC> this motherboard: https://www.asus.com/Motherboards/H170M-PLUS/ with a Core i5-6600
<JanC> and Ubuntu 17.10
<JanC> "sig 0x000506e3, pf_mask 0x36, 2017-11-16, rev 0x00c2, size 99328"
<dijuremo> apw: I cannot seem to find the -119 update, it should be part of the same repo where I got the microcode from, right?
<apw> dijuremo, in the primary archive in the -proposed pocket
<dijuremo> https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
<dijuremo> Is that where it should be?
<apw> dijuremo, no in the primary archive, in the xenial-proposed pocket
<apw> $ rmadison -a source linux -s xenial,xenial-updates,xenial-security,xenial-proposed
<apw>  linux | 4.4.0-21.37   | xenial          | source
<apw>  linux | 4.4.0-116.140 | xenial-updates  | source
<apw>  linux | 4.4.0-116.140 | xenial-security | source
<apw>  linux | 4.4.0-119.143 | xenial-proposed | source
<dijuremo> So add to my sources.list:      deb http://us.archive.ubuntu.com/ubuntu/ xenial-proposed main restricted
<apw> or just download it from the pool
<apw> or indeed from the launchpad librarian
<apw> https://launchpad.net/ubuntu/+source/linux/4.4.0-119.143
<dijuremo> apw: got it now, updating...
<ricotz> apw, hi, did you see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1758856/comments/1
<ubot5> Ubuntu bug 1758856 in linux (Ubuntu Artful) "retpoline hints: primary infrastructure and initial hints" [Undecided,New]
<ricotz> Ubuntu-4.15.0-14.15 likely has the same issue
<apw> ricotz, no, but i also hit the issue myself this morning, and am already poking it
<dijuremo> Setting up linux-image-generic-hwe-16.04 (4.13.0.38.57  -> Was able to boot and log in to GUI, but on log off, machine froze. Numlock key no longer works, cannot ssh into it.
<ricotz> apw, alright
<dijuremo> Next test 4.4.0-119
<dijuremo> apw: So far seems like 4.4.0-119 is *the* magic bullet on the DELL T3610 with A19 BIOS. I was able to log in and log out twice, ran some Matlab and glxgears and no freezes so far, whereas 4.13.0.38.57 froze the machine after loging out the first time.
<dijuremo> # uname -r 
<dijuremo> 4.4.0-119-generic
<dijuremo> Using the microcode from 20180312
<dijuremo> ii Â intel-microcode Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 3.20180312.0~ubuntu16.04.1 Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â amd64 Â Â Â Â Â Â Â Processor microcode firmware for Intel CPUs
<dijuremo> cat /sys/devices/system/cpu/cpu0/microcode/version Â 
<dijuremo> 0x42c
<dijuremo> Ugh I cannot type today... *DELL T3610 with A16 BIOS*
<dijuremo> Running the torture test with prime95, keeping and eye on Temps on the machine as well.
<apw> dijuremo, well that is something, so that implies there is something between -116 and -119 which helps with this hang, so it is worth getting the lenovo tested too
<apw> dijuremo, and i do know we had a heap of stable updates applied in this new cycle
<dijuremo> I have another one, an Optiplex 7050 freezing on 4.4.0-116 so going to try 119 on that one.
<dijuremo> Will also try and find the Lenovot and test 119
<apw> dijuremo, so if the latest xenial-proposed hwe kerenl doesn't fix the issue for that bios level, we might need you 
<apw> dijuremo, to try some of the stable updates to see if we can narrow down where the fix is in the 4.4.x series so we can apply it to the later kerenls too
<apw> dijuremo, but first lets see if -119 is the universal panacea for the hangs on all your boxes
<apw> dijuremo, and do report the lot into your bug
<dijuremo> Sounds like a plan. 
<dijuremo> apw: Here is another finding. One system without BIOS update started freezing. It has several 4.4.0 kernels installed. It recently got the intel-microcode update from 20180312.
 * apw crawls into a corner and quietly dies
<dijuremo> Both the 4.4.0-112 and 4.4.0-116 kernels lead to a frozen machine right after lightdm starts. However, 4.4.0-109 does not freeze the machine once the GUI starts.
<dijuremo> On that machine, the intel-microcode package was installed on 3/30/2018 and then the user started to see the freezing.
<apw> dijuremo, 109 or 119 ?
<JanC> if there is no UEFI upgrade available, you should be able to boot into the recovery console from GRUB & remove the microcode from there
<tyhicks> apw: we've gotten quite a few reports of lockups (bug #1759920) with new BIOS or updated intel-microcode
<ubot5> bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed] https://launchpad.net/bugs/1759920
<tyhicks> apw: I haven't been able to reproduce it
<apw> tyhicks, it sounds like that there might be some relief in later 4.4 kernels at least, from whatever is tickling that
<apw> tyhicks, dijuremo is chasing it down in their bug
<tyhicks> apw, dijuremo: while debugging, this is an important detail to remember about how the intel-microcode package works: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1759920/comments/45
<ubot5> Ubuntu bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed]
<apw> tyhicks,  a good point indeed
<apw> and sensibly too from a regression perspective
<dijuremo> apw: I had an older 4.4.0-109 (one zero nine) available in the machine and with the latest microcode installed 3/31/2018 and the older BIOS 1.4.4 on the 7050 the machine would boot just fine without freezing, whereas the 4.4.0-112 and 4.4.0-116 would freeze the machine
<dijuremo> So it seems that instability starts on 4.4.0-112 when the latest microcode is present.
<dijuremo> I went ahead and installed 4.4.0-119 from the proposed release repo and it also worked well initially. This machine is an Optiplex 7050 which uses Intel Core i7 with built-in GPU. Since everything seemed to be OK so far, I added and Nvidia card, installed the Nvidia driver and now the machine freezes after lightdm starts even with 4.4.0-119
<tomreyn> sweet. dont use nvidia - problem solved!
<tomreyn> j/k
<dijuremo>  tyhicks: sounds good, will keep it in mind, though when we did all the prior testing, we were doing cat /sys/devices/system/cpu/cpu0/microcode/version which was in fact showing us the proper microcode versions.
<dijuremo> FYI, the T3610 machine is still running mprime solid, CPU temps hovering around 67C, with a maximum of 70C
<tomreyn> 4.4.0-112.135 sets CONFIG_KERNEL_NOBP=y according to http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.4.0-116.140/changelog
<tomreyn> BP = branch predeiction, https://patchwork.kernel.org/patch/10168887/
<tomreyn> umm, ignore, wrong architecture
<dijuremo> So for the DELL 7050 I am currently on BIOS Version: 1.8.2, the microcode is: 0x84 and I have the Intel microcode package installed 3.20180312.0~ubuntu16.04.1. Nvidia driver is also installed and version 384.111-0ubuntu0.16.04.1.   I can consistently freeze the machine with kernels 4.4.0-112 4.4.0-116 and 4.4.0-119 with the previous configuration. If I boot the kernel 4.4.0-109 the machine does *not* freeze.
<cking> apw, the 4.15.0-14-generic kernel in proposed is causing some dkms breakage, any ideas about this? https://launchpadlibrarian.net/363092142/DKMSBuildLog.txt
<cking> apw, i see the same thing for sysdig and other DKMS modules too
<apw> cking, yes, i know what that is
<apw> /bin/bash: ./debian/scripts/retpoline-extract-one: No such file or directory
<cking> yep
<apw> i know how to fix that, and will be doing so shortly
<cking> ok ta, perhaps it can be fixed against bug 1760876
<ubot5`> bug 1760876 in fwts (Ubuntu) "fwts-efi-runtime-dkms 18.03.00-0ubuntu1: fwts-efi-runtime-dkms kernel module failed to build" [Medium,In progress] https://launchpad.net/bugs/1760876
<apw> cking, sure
<cking> thanks!
<tyhicks> djinni: that makes sense because the 4.4.0-109 kernel didn't make use of the IBRS/IBPB features provided by the new microcode
<tyhicks> bah
<tyhicks> dijuremo: that makes sense because the 4.4.0-109 kernel didn't make use of the IBRS/IBPB features provided by the new microcode
<tyhicks> djinni: sorry for the invalid ping
<apw> tyhicks, 'yay'
<apw> that microcode is just a living disaster in all its forms
<tyhicks> apw: either the microcode for some processors is bad or we have a bad IBRS/IBPB patch in our 4.4 and 4.13 kernels
<apw> i guess that is entirely possible, though we have been using those kernels heavily in-house, but ...
<apw> then again i thought that the reporter had turned off those mitigations
<apw> i guess we will find out when the bug is updated
<apw> tyhicks, you might want to check that dijuremo has tested with the ibrs ibpb sysfs thingies disabled too
<apw> thoguh we should not be using ibrs if we have retpoline on, so its not likely to be that one
<tyhicks> dijuremo: it would be helpful if you could verify if this bug comment also works for you: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1759920/comments/55
<ubot5`> Ubuntu bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed]
<tyhicks> dijuremo: I think the best situation to test would be the 4.4.0-119 kernel, with updated microcode (0x84 for your Dell 7050), and seeing if you add noibpb to the kernel command line prevents the lockups
<tyhicks> dijuremo: if that doesn't work, do the same test but add "noibrs to the kernel command
<tyhicks> dijuremo: let me try that again without hitting enter too early... if that doesn't work, do the same test but add "noibrs noibpb" to the kernel command
<dijuremo> OK, here are the latest developments, without just yet trying noibpbp or noibrs noibpb:  The DELL 5820 came back for freezing. I have updated it to the latest BIOS, 1.4.0 Removed all kernels but 4.4.0-92 (Does not freeze), installed 4.4.0-109 (Does not freeze). Installed 4.4.0-119 and machine freezes. Next step, use -119 with noibpb....
<dijuremo> Both the DELL T5820 and the Optiplex 7050 work properly (no more immediate freezes when it gets to the GUI login screen) when I use 4.4.0-119 and the *noibpb* kernel option
<tyhicks> ok, very good to know
<dijuremo> So noibpb should work for both 4.4.0-119 and 4.13.0-38 right? How about 4.13.0-37?
<tyhicks> dijuremo: noibpb will be honored in all three of those kernels
<dijuremo> 4.13.0-38 tested on T5820 and no freeze with noibpb, 4.13.0-37 tested on Optiplex 7050 and no freeze with the same option.
<apw> tyhicks, ugg
<s10gopal> apw, can you please guide me how to do a git bisect run to find the first bad commit ?
<dijuremo> So for now by disabling ibpb we are making the systems vulnerable to some form of spectre, does this sound right?
<s10gopal> <derRichard> if it works on 4.12 but not on 4.13, it is a regression
<s10gopal> TJ-, can you please guide me ?
<TJ-> s10gopal: see https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_bisect_the_upstream_kernel.3F
<s10gopal> TJ-, should i test sub version between 4.12 and 4.13  too ?
<s10gopal> TJ-, i am unable to understand above guide , can you please explain it ?
<TJ-> s10gopal: identify the closest 2 versions where the lower works and the higher does not, then git bisect between those 2 versions and test it one 
<TJ-> s10gopal: Do you know what "bisect" means?
<s10gopal> TJ-, no
<s10gopal> TJ-, line which cut two things ?
<TJ-> s10gopal: it means 'split in two' ... let me give you an example
<apw> dijuremo: yes you are
<TJ-> s10gopal: let's assume we have an imaginary project with releases v1.0 (commit #1) through v1.5 (commit #20) with 20 commits between them. There's a regression somewhere between them - so the fastest way to find it is take the halfway point commit (#10), build the project, and test. If that test works then we know the problem must be higer than #10, so we halve again between #10 and #20 and build again
<TJ-> for #15, test. If it fails then we know he problem is between #10 and #15 so halve again and build #12 and test. If that works we know the issue is between #12 and #15 ... that process continues until you've only got 1 commit left, which is where the regression was introduced 
<s10gopal> TJ-, apply binary search?
<TJ-> s10gopal: correct, that's a bisect(ion)
<TJ-> using the 'git bisect' tool it does this for you, you just tell it whether the last build was GOOD or BAD and it figures out the next commit and checks it out ready for you to build
<s10gopal> can i manually do it by installing kernel build between 4.12 and 4.13 ?
<s10gopal> from http://kernel.ubuntu.com/~kernel-ppa/mainline/
<TJ-> s10gopal: no, you need to do it from a clone of the mainline source code git repository
<s10gopal> TJ-, can you please guide me how to build kernel from git source ?
<TJ-> s10gopal: it's an upstream issue so you work on the upstream repo. It's also much easier than trying to git-bisect Ubuntu kernels because they are rebased so there isn't a single linear history
<TJ-> s10gopal: read the guide I showed
<s10gopal> TJ-, which link should i use ? https://launchpad.net/ubuntu/lucid/+source/linux
<s10gopal> https://launchpad.net/ubuntu/maverick/+source/linux
<s10gopal> https://launchpad.net/ubuntu/natty/+source/linux
<s10gopal> https://launchpad.net/ubuntu/oneiric/+source/linux
<s10gopal> https://launchpad.net/ubuntu/precise/+source/linux
<s10gopal> https://launchpad.net/ubuntu/quantal/+source/linux
<s10gopal> https://launchpad.net/ubuntu/raring/+source/linux
<s10gopal> https://launchpad.net/ubuntu/saucy/+source/linux
<s10gopal> https://launchpad.net/ubuntu/trusty/+source/linux
<s10gopal> https://launchpad.net/ubuntu/utopic/+source/linux
<s10gopal> https://launchpad.net/ubuntu/vivid/+source/linux
<TJ-> s10gopal: none, use upstream mainline
<s10gopal> TJ-, this one ? http://kernel.ubuntu.com/~kernel-ppa/mainline/
<TJ-> s10gopal: "git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git" then "cd linux" and you're in the 'root' of the source tree
<s10gopal> TJ-, done
<s10gopal> now?
<s10gopal> TJ-, git bisect is going to check 4.12 to 4.16 right ? how i can modify to check only between 4.12 .. 4.13 ?
<TJ-> s10gopal: Use the versions that are applicable to you in place of those in the example on the Wiki
<s10gopal> TJ-,  git log --oneline 4.12..4.13 | wc
<s10gopal> TJ-, ambiguous argument '4.12..4.13': unknown revision or path not in the working tree.
<TJ-> s10gopal: so you checkout the last known good, as in 'git checkout v4.12' then do 'git bisect start' 'git bisect good v4.12' git bisect bad v4.13' ... that'll checkout at the 1/2 way commit, so then you build, install, and test.
<s10gopal> TJ-, how to build and install ?
<TJ-> s10gopal: I feel like this is way beyond you. It is documented in the Wiki. I don't have the time to be able to talk you through it.
<s10gopal> TJ-, thx a lot , can #ubuntu users help me ?
<TJ->  s10gopal it's beyond that kind of support, it's a very niche procedure for kernel devs 
<s10gopal> TJ-, anything like https://lwn.net/Articles/317154/ ?
<TJ-> s10gopal: no, running 'git bisect' is the easy bit. I'm referring to preparing to build by copying in an appropriate .config file, doing 'make silentoldconfig' then 'make bzImage' then having to copy that into /boot/vmlinuz-test, build an initrd.img 'update-initramfs -c -k test' and 'update-grub' then reboot test and repeat as required.
<s10gopal> sorry i didnt got it
<TJ-> s10gopal: that's my point, this is way beyond you.
<s10gopal> TJ-, what i can do ?
<TJ-> be patient! unless you can find an upstream kernel developer who wants to take it on it could take years to be addressed
<s10gopal> TJ-, can i test sub version ? it will make bisect process faster ?
#ubuntu-kernel 2018-04-04
<s10gopal> apw, ring ring
<s10gopal> apw, can you please tell me how to do git bijection and build kernel from source ?
<s10gopal> already did s10gopal: "git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git" then "cd linux" and you're in the 'root' of the source tree
<apw> s10gopal, that is not a simple thing to do, there is a wiki page with the details somewhere; or it might be better if we get someone to feed you built kernels to test
<apw> s10gopal, do you h
<s10gopal> and this too 'git checkout v4.12' then do 'git bisect start' 'git bisect good v4.12' git bisect bad v4.13'
<apw> s10gopal, do you have a 'good and bad' kernel pair
<s10gopal>  4.12 is good and 4.13 is bad
<apw> then you might want to test the 4.13-rc1 mainline build, as that is 'kind of' in the middle of those two
<apw> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13-rc1/
<apw> that is already pre-built and will save you a bit of time
<s10gopal> should i test all ?4.13rc*
<s10gopal> and what about 4.12.* line ?
<apw> well most of the change goes in in -rc1 so that is the nearest to the 'middle' in a bisection sense as we have built
<apw> if you are lucky that one will be good then it is worth testing the other -rc's too, -rc4 or whatever and hone in on it, but test -rc1 and see if that is good/bad
<s10gopal> what is all rc are bad ?
<apw> well if -rc1 is bad, then the issue is between 4.12 and 4.13-rc1 and that is the most likely outcome, but that is what we are trying to narrow in on
<s10gopal> apw, thx testing it , and after getting good and bad pair , this bug can be fixed or i have to wait for years ?
<apw> s10gopal, once the bisect is complete we will know the exact commit which introduced the issue, tehn it needs looking at, sometimes it is obvious sometimes it needs work upstream
<apw> so i cannot possibly answer your question
<s10gopal> thx , going to test rc , bye
<apw> at least there is hope, and it is within your control to move it along; consider how it would be with windows
<apw> dijuremo, there may be some movement on at least some of the hangs we have been seeing, i wonder if you could try out the kernels at the bottom of LP: #1759920
<ubot5`> Launchpad bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed] https://launchpad.net/bugs/1759920
<apw> see the last comment, it has the links to the kernels and hints what to collect
<apw> iirc you were seeing issues with both 4.4 and 4.13 kernels
<LocutusOfBorg> seriously kernel folks, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1760973
<dijuremo> apw: It's done -> https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1759920/comments/68
<ubot5`> Ubuntu bug 1760973 in linux (Ubuntu) "virtualbox-dkms 5.2.8-dfsg-5: virtualbox kernel module failed to build [Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel"]" [Critical,Confirmed]
<ubot5`> Ubuntu bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed]
<apw> LocutusOfBorg, what?  we broke the kernel in -proposed ?  is this no a crime ?
<apw> now
<apw> dijuremo, do i take it it worked from all that :)
<apw> sforshee, ^
<dijuremo> so far so good... But this is the T3610 that was stable for a long time yesterday without noibpb
<apw> dijuremo, well do let us know how you get on, the more the merrier testing wise
<dijuremo> The one where I was running prime95 on. I left it running and ran for many hours but today it was frozen with the *older* *unpatched* 4.13.0-38
<dijuremo> So this morning, force restarted it, applied the patches and now we will see... If I leave it running prime95 for a full day and does not crash, we have a winner...
<apw> tyhicks, ^
<dijuremo> apw: Do you guys plan to patch the 4.4.0 series as well to fix that one?
<dijuremo> apw: What would you be your best estimate on a release of both patched 4.4.0 and 4.13.0 to the main Ubuntu channels?
<apw> dijuremo, yes we would be planning on fixing any affected kerenls, it would most likley be in the next cycle, we might expedite this fix it depends
<apw> dijuremo, so about 3 weeks
<dijuremo> I guess I will try to hold in adding noibpb to my Ubuntu machines for now, only do it for those freezing, do not want to end up with all of them using nobipb and being vulnerable. Just do not have enough personnel and time for trying something that does config management, i.e. ansible, salt, etc... 
<s10gopal> apw, rc1 is also bad , which next to test ?
<apw> s10gopal, then the next is a real bisect from v4.12 to v4.13-rc1
<apw> s10gopal, which i might make sense for someone to generate the krenls fro you
<apw> jsalisbury, ^ if you have time perhaps you could help out ?
<s10gopal> should i test 4.12.14 too ?
<s10gopal> apw, 4.12.1 to 4.12.14
<jsalisbury> apw, ack
<s10gopal> !ping
<ubot5`> pong!
<jsalisbury> s10gopal, do you have a bug opened for this bisect?
<s10gopal> jsalisbury, https://bugzilla.kernel.org/show_bug.cgi?id=198665
<ubot5`> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
<s10gopal> jsalisbury, and this too https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646
<ubot5`> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,New]
<jsalisbury> s10gopal, I'll start a bisect between 4.12 and 4.13-rc1 and build a test kernel.  I'll post it to the bug shortly.
<s10gopal> jsalisbury, i am having ssd and core i5 , can you please teach me how to do it ? i will build it and test 
<jsalisbury> s10gopal, if you'd like to try, there is a wiki that explains it.  Let me grab the link
<s10gopal> jsalisbury, but i am unable to understand it
<jsalisbury> s10gopal, https://wiki.ubuntu.com/Kernel/KernelBisection
<s10gopal> jsalisbury, but i am unable to understand it
<jsalisbury> s10gopal, Ok, I'll build the test kernels for you to test then.
<s10gopal> jsalisbury, thx a lot
<s10gopal> jsalisbury, where you are going to post them ?
<jsalisbury> s10gopal, I"ll post a link in the bug and instructions.  It will be here when built: 
<jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1745646/
<s10gopal> jsalisbury, i need to install it by sudo dpkg -i linux-image-4.12.0-041200-generic_4.12.0-041200.201804041240_amd64.deb only ?
<xnox> s10gopal, use $ sudo apt install ./linux....deb
<xnox> s10gopal, note that './' is needed. If you have the full set of packages to install in a dir you can use $ sudo apt install ./*.deb
<s10gopal> i did cd Downloads
<xnox> s10gopal, that will tell you if you have all the right deps / if you forgor or missing any downloaded packages.
<s10gopal> then  sudo dpkg -i linux-image-4.12.0-041200-generic_4.12.0-041200.201804041240_amd64.deb
<xnox> it is no longer advisable to ever use dpkg -i interractively.... using apt with downloaded debs is better.
<s10gopal> xnox, can we install kernel by single file ? generally it is required to download 3 deb files
<xnox> s10gopal, why? generally, no....
<xnox> why would you want to install it by single file?
<xnox> it is not packaged like that... thus by not getting all the files, you will cause broken packages and broken dependencies on your system, preventing further installations of any packages if you force it
<s10gopal> xnox, i downloaded a kernel from http://kernel.ubuntu.com/~jsalisbury/lp1745646/
<xnox> using apt install ./path-to.deb ./path-to.other.deb -> saveguards you from breaking your system.
<xnox> s10gopal, if that installs fine using apt, it is fine.
<TJ-> xnox: is there any documentation on using 'apt' eith deb files? I don't see anything in 'man apt'
<jsalisbury> s10gopal, Just be sure to reboot after installing the new kernel and select it from the GRUB menu.
<s10gopal> TJ-, i did sudo dpkg -i linux-image-4.12.0-041200-generic_4.12.0-041200.201804041240_amd64.deb , any other command or file is required too or i should reboot now ?
<jsalisbury> s10gopal, after a reboot, run 'uname -a' to ensure you booted into it.
<xnox> TJ-, that would need ping to juliank, but he is not in this channel
 * xnox summons juliank
<s10gopal> ok thx
<s10gopal> rebooting
<juliank> xnox: you called
<juliank> :D
<xnox> <TJ-> xnox: is there any documentation on using 'apt' eith deb files? I don't see anything in 'man apt'
<xnox> juliank, ^
<xnox> s/eith/with/
<juliank> hmm
<juliank> maybe not
<TJ-> It would be nice to refer users to using apt that way
<xnox> juliank, i do recall our extensive discussion of specifying things with ./*.deb at all.
<juliank> yeah
<juliank> What works is apt --with-source <changes/deb/maybe dir, idk> names..., and apt install /absolute/path ./relative/path/with/dot/in/front
<s10gopal> Linux gopal-HP-Notebook 4.12.0-041200-generic #201804041240 SMP Wed Apr 4 12:44:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<juliank> --with-source is documented (it adds e.g. a .changes or .deb file to the cache like a normal package set)
<xnox> TJ-, yeah in general these days, after building things i only ever use $ sudo apt install ./*.deb -> e.g. when testing new builds of systemd, etc.
<xnox> causer there are tricky depends that dpkg -i cannot get right, if i forget a package, or list them out of order.
<juliank> but the other not
<juliank> Nice things for testing builds are
<TJ-> xnox: right - I could do with apt instead of dpkg -i in some of my scripts
<juliank> apt install --only-upgrade ../package_version_arch.changes
<juliank> or without --only-upgrade if you need to install new stuff
<s10gopal> TJ-, i am in jsalisbury kernel ?
<juliank> and/or --with-source changes and running upgrade or something
<juliank> I guess that makes a lot of sense
<juliank> apt upgrade --with-source ../<built changes file> 
 * TJ- pipes juliank into 'man-db'
<juliank> For with-source at least, you can also generate a Packages file and install from that
<mamarley> You can use APT to upgrade locally compiled packages by passing it only a changes file?  Where has this been all my life?
<xnox> I think juliank is overdue a blogpost on all the planets which just lists these commands and ends with
<xnox> .... "guess what all of the above do?! Your welcome!"
<jsalisbury> s10gopal, post the output of uname -a from a terminal and we will know.
<s10gopal> Linux gopal-HP-Notebook 4.12.0-041200-generic #201804041240 SMP Wed Apr 4 12:44:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<jsalisbury> s10gopal, great.  Now test for the bug. I'll build the next test kernel based on the results.
<jsalisbury> s10gopal, then will do the same over again about 10 or so times.
<juliank> xnox: I'd expect apt upgrade <path to changes> to do the wrong thing, BTEW
<s10gopal> jsalisbury, how much time i should turn off my laptop ? 
<jsalisbury> s10gopal, however long you did in the past to reproduce the bug.
<jsalisbury> s10gopal, we just want to know if this kernel exhibits the bug or not.
<juliank> mamarley: it's only been around for 2 years
<s10gopal> going to test it
<s10gopal> thx 
<TJ-> jsalisbury: you've going to love s10gopal :) Thanks for stepping in 
<xnox> juliank, but at King's Cross you can take pictures on the platform 9Â¾ 
<xnox> wrong channel
<xnox> oh wel
<jsalisbury> TJ-, anytime :-)
<TJ-> jsalisbury: did you see that s10gopal is suspecting the RTC sync on shutdown due to discovering an old Debian bug?
<jsalisbury> TJ-, I didn't.  That's what is great about a bisect.  No guessing needed :-D
<jsalisbury> TJ-, many times no thinking needed either, lol
<TJ-> jsalisbury: I  think it's an ACPI issue
<jsalisbury> TJ-, probably.  Once he tests a couple of kernels, the number of commits will come way down, so we may be able to just pick it out
<TJ-> Yes, I hope so. It's a hell of a one to test though, because the PC needs leaving shutdown for quite a few hours to be sure of the battery drain
<jsalisbury> TJ-, arg, well I imagine this bisect will take a while then.  I'll skim throught the commits between v4.12 and v4.13-rc1 and see if anything sticks out.
<TJ-> jsalisbury: I was going to prepare a script to generate all the kernels bisect would need to test ahead of time so he could just install them without waiting for bisect+build but he started 'clinging' to me so I had to back off
<jsalisbury> TJ-, so he's a "Klingon" ?
<jsalisbury> :)
<TJ-> jsalisbury: desperately wants a solution but has very little ability to read documentation/wiki and transpose into what the specific commands he needs are
<jsalisbury> TJ-, I'll help him along, he seems willing to test, so that's good.
 * TJ- nods
<dijuremo> A quick question about the changes to the kernel per Ubuntu bug 1759920, Will you guys pass the fix upstream to Debian? Were their kernels also affected similarly with ibpb freezes?
<ubot5`> Ubuntu bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed] https://launchpad.net/bugs/1759920
<Gargravarr> dijuremo: hi, i've been sent your way from #ubuntu-server about an intel-microcode issue, possibly related to bug 1759920
<ubot5`> bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed] https://launchpad.net/bugs/1759920
<Gargravarr> i have some Kaby Lake laptops which are displaying the same symptoms, which seems to be closely related to sssd
<tyhicks> dijuremo: the fix is already in the upstream linux kernel - we were using a slightly different patch that had came from a processor vendor
<tyhicks> Gargravarr: sssd is a good way to trigger it
<tyhicks> Gargravarr: if you have time, please follow the instructions in this comment: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1759920/comments/67
<ubot5`> Ubuntu bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed]
<Gargravarr> tyhicks: thanks for the link. is this known to affect 4.4 kernels as well? my laptop really does not like 4.13
<tyhicks> Gargravarr: it does affect 4.4 but I don't yet have a test kernel
<tyhicks> Gargravarr: keep an eye out as I'll have a 4.4 test kernel soon
<Gargravarr> thanks. i do have an affected laptop installed with 4.13 but i'm currently testing with the 4.4 one
<dijuremo> Gargravarr: All our machines had sssd, so probably why we were seeing them freeze consistently.
<Gargravarr> dijuremo: part of my job here has been migrating local users onto LDAP. dogfooding has meant i ran into the problem pretty frequently
<dijuremo> Gargravarr: I maintain RHEL 7.x and Ubuntu Linux desktops and laptops all tied with sssd to Active Directory...
<Gargravarr> you have my sympathy ;)
<dijuremo> Gargravarr: honestly has worked very well, had some issues related to DNS and very slow lookups of things, but working well now.
<Gargravarr> i built an OpenLDAP cluster from scratch
 * waveform is stupid enough to run an openldap cluster at home
<Gargravarr> that's now nice and stable, but trying to do this all open-source has been really quite painful
<waveform> (there are many raspberry pis ... that's my excuse)
<Gargravarr> waveform: i have more laptops than relatives :P the thought of running my own has crossed my mind
<Gargravarr> can't deny, AD does make building and maintaing a domain significantly easier
<dijuremo> Gargravarr: Dont want to hijack this channel talking about sssd, so PM me if you like. I did run openldap back in the beginning of the 2000s, but it was even more challenging, compiling and running Openldap on Solaris and authenticate against kerberos to get rid of NIS. Was a fun project. But do not want to deal with ldap, etc....
<Gargravarr> i now speak fluent LDIF...
<Gargravarr> tyhicks helpfully explained why this is a kernel issue in the other channel
<Gargravarr> and why sssd is particularly good at hitting it
<Gargravarr> tyhicks: okay, i've loaded this laptop up with your -38 kernel, here goes
<Gargravarr> tyhicks: no, it froze again, immediately after successful auth
<dijuremo> Gargravarr:  You have just gave me some news, I was not aware that sssd would trigger the freeze, but now it makes sense that more and more of my systems began to freeze. I thought originally it was related to running X and the Nvidia driver since I could sometimes log in, but the after log out the system would freeze restarting lightdm
<dijuremo> You have just *given* me some news....
<Gargravarr> we all English good on IRC :)
<dijuremo> Not a native english speaker, so I have an excuse, but try to make up for my mistakes when I see them ;)
<waveform> yeah, definitely not related to nvidia drivers (that came up a lot on the duplicate bugs, but I've only got AMD/intel graphics here and still experienced the lockup)
<tyhicks> Gargravarr: could you boot the same kernel but add "noibpb" to the kernel command line in grub (so that you can fully boot) and then paste the output that I requested here? https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1759920/comments/67
<ubot5`> Ubuntu bug 1759920 in linux (Ubuntu Artful) "intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)" [High,Confirmed]
 * Gargravarr is learning why netcat is such an invaluable tool
<Gargravarr> tyhicks: it booted successfully without the noibpb flag, what does that do?
<tyhicks> Gargravarr: disables the problematic code path
<tyhicks> (among other things)
<Gargravarr> right, that explains it, version signature confirms i've booted the wrong kernel :)
<tyhicks> woohoo! that's why I insisted on proof :)
<tyhicks> I'm pretty confident that the fix is right
<tyhicks> but I really do appreciate your testing
<tyhicks> so give it another go with the right kernel and keep your fingers crossed
<Gargravarr> indeed. wasn't sure if i booted the right kernel in the first place (or whether i already had -38 installed), but it's bloody hard to see on these XPS13's - ours have frikkin' 4k screens
<Gargravarr> tyhicks: so do you want me to boot -38 with or without that flag to test?
<Gargravarr> i'm guessing without
<tyhicks> Gargravarr: without
<Gargravarr> okay, so everything is matching your output on comment #67 so far
<Gargravarr> just fired up sssd
<Gargravarr> let's see what happens...
<Gargravarr> okay, it did an auth and failed on something else (my bad, quirk of our LDAP setup i think)
<Gargravarr> most importantly, it DIDN'T freeze
<tyhicks> nice!
<Gargravarr> yuh, script crashed before it set up the PAM profile, lemme install it...
<tyhicks> Gargravarr: please paste the output of those commands so that I can double check your machine state
<tyhicks> Gargravarr: either in the bug report or via paste.ubuntu.com
<Gargravarr> tyhicks: collecting it now
<tyhicks> thanks
<Gargravarr> halle-freaking-lujah, logged in to desktop successfully
<Gargravarr> your fix looks like the ticket
<tyhicks> :)
<Gargravarr> tyhicks: comment #72
<Gargravarr> does the CPU generation make much difference on how badly affected the machine is? i notice our Skylake desktops haven't run into it yet, but the one machine i've checked in depth doesn't have intel-microcode installed. can't say for sure if the others do
<Gargravarr> and all the ones that are affected are Kaby Lake
<tyhicks> Gargravarr: hmm, could you paste the output of 'sudo cat /sys/devices/system/cpu/cpu0/microcode/version' into this channel?
<tyhicks> Gargravarr: run that command on the machine that you left the bug comment about
<Gargravarr> okay, lemme start it back up
<tyhicks> as for CPU generation, I'm not sure... some of your machine may not have updated microcode
<Gargravarr> indeed. i thought it was part of my build script
<Gargravarr> oh feck. that was stupid.
<tyhicks> you may not have the latest microcode on the machine that you left the comment about
<Gargravarr> my LDAP setup here involves storing the ecryptfs recovery key for a user directly in LDAP against their profile
<Gargravarr> i seem to have neglected to make an exception for root...
<Gargravarr> tyhicks: 0x7c
<Gargravarr> for the XPS 13 running your -38 kernel
<Gargravarr> i7 7560U chip
<tyhicks> Gargravarr: what version of intel-microcode is installed?
<Gargravarr> ...it ain't
<Gargravarr> interesting. so i have (at some point) updated the BIOS (which includes microcode) to v2.5.0, released 18th Feb
<tyhicks> Gargravarr: and 'cat /proc/sys/kernel/ibpb_enabled' prints out '1'?
<Gargravarr> only i can't find that version on Dell's site any more
<Gargravarr> seems to have been entirely replaced by 2.5.1, which makes me think the .0 version is known broken
<tyhicks> I think you should have revision 0x84
<tyhicks> see https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf for better info than I can provide
<Gargravarr> okay. i'll push the firmware up to the latest version while i'm at it
<tyhicks> anyways, IBPB is available in your microcode so that's all that I needed to know
<tyhicks> I need to get heads-down on these backports now
<tyhicks> thanks again!
<Gargravarr> tyhicks: okay, so updating the system firmware has indeed pushed the microcode up to 0x84
<tyhicks> good deal
<Gargravarr> this is where it gets confusing, with the BIOS and userspace stuff overlapping :)
<Gargravarr> and it all meets in the kernel
<s10gopal> jsalisbury, it is bad
<jsalisbury> s10gopal, ack.  thanks for testing. I'll build the next kernel and post it shortly.
<Gargravarr> right, that's 3 hours past clocking-off time, time to go home :P
#ubuntu-kernel 2018-04-05
<s10gopal> jsalisbury, it is also bad
<s10gopal> jsalisbury, can you please teach me how to build kernel for test ?
<s10gopal> apw, ^
<apw> s10gopal, this page has the broad methods: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<apw> s10gopal, but it is differennt if you are building a mainline one, there you might well use make kpkg
<apw> s10gopal, but also unless you have a huge box, it takes many hours for a build
<apw> s10gopal, the one we build test kernels on has over 200 cores
<apw> s/cores/cpus
<TJ-> apw: that's more cores than an apple tree!
<s10gopal> i have core i5 6th gen and 128gb ssd , how much time it is going to take ?
<s10gopal> 2 physical core
<apw> i would be supprised if that is not in the range of 4-6 hours
<apw> that would count as "tiny" on the scale of a machine to build the kernel
<TJ-> s10gopal: I believe jsalisbury was planning on building the bisected kernel packages for you, you just need to report back in the LP bug report each time as to whether the last test was successful or not
<apw> which is why having j-salisbury help you
<apw> should be speeding things up
<s10gopal> i thought , if i build kernel myself i dont have to wait for him to come online
<TJ-> s10gopal: if you use the LP bug report to leave comments you don't need to wait for him either, he'll build a new package and comment in the bug with a link to the download location when it is ready
<apw> s10gopal, indeed you would not though i am not convinced you could get a kernel built before he comes online anyhow
<s10gopal> apw, everyone can access that super computer or just developers can ?
<apw> s10gopal, that is an internal system
<lorddoskias> compiling an upstream kernel with gcc-5 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 results in thread_union type being erased from the resulting kernel image. When i try compiling with gcc-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0 i thread_union is there? 
<apw> lorddoskias, erased in what sense ?
<lorddoskias> apw: in the sense that if i open the resulting vmlinux with gdb and write "ptype union thread_union" i get "no such type" 
<lorddoskias> and as a result the "crash" utility is not working correctly as well 
<apw> lorddoskias, that does sound like a bug (or limitation) in the older compiler
<lorddoskias> well the older compiler is whatever is shipped as lts for ubuntu 16.04.04
<lorddoskias> so in fact it is the supported compiler 
<lorddoskias> so the 5.4 has retpoline support enabled, whereas the 7.2.0 doesn't  - the 16.04 backport is from 2017
<apw> lorddoskias, indeed, debugging with older compilers might be hard, though i assume you can dump that thing out
<apw> as you do know the type it contains
<lorddoskias> well given that the oldest kernel supported by the upstream kernel is 4.8 i won't call 5.4 old 
<lorddoskias> true, there is gcc 8 release approaching but still 
<apw> it builds it just fine, right
<lorddoskias> build wise it's ok 
<apw> and you know which of those three things are in there, in your context
<apw> so you can just dump the address as which ever it is
<apw> i assume it is a lack of representation of unions, though i can find no direct evidence of that being improved in later compilers in a quick search
<lorddoskias> but ptype hpet_lock works. and hpet_lock is defined as: arch/x86/kernel/hpet.c:union hpet_lock {
<lorddoskias> ptype union ftrace_op_code_union also works 
<lorddoskias> so it's not being applied to all unions 
<apw> lorddoskias, from your 7.2 print of the type, does it contain anything other than stack, ie are the other optional fields in there
<apw> lorddoskias, i am wondering if it is because it is a union with only one member
<lorddoskias> let me rebuild and see 
<apw> as the others you list all definatly have more than one member
<apw> it is possible there is only one member, so the type is optimised away
<lorddoskias> i think this is an invalid optimisation, no ?
<lorddoskias> and in fact here we are talking about debug info 
<apw> depends how you look at it, the type is technically redundant if it only has one member, the inner type can be promoted
<apw> so if the optimiser did that, then there would be no references to the type in the emitted code
<lorddoskias> so how come the newer compiler with presumably more advanced optimisation logic omits this optimisation but the older one doesn't?
<apw> and so emitting the type would be a waste of space in the debug info
<lorddoskias> but if i specifically configured the kernel to produce debug info then presumably i don't care much about optimisations,esp of the debug info 
<lorddoskias> that sounds ludicrous 
<lorddoskias> type = union thread_union {
<lorddoskias>     struct task_struct task;
<lorddoskias>     unsigned long stack[2048];
<lorddoskias> }
<apw> so not that then
<lorddoskias> so you are not right, because there are 2 members
<apw> indeed
<apw> it was a theory, you tested it, it failed
<apw> that is the nature of theories
<lorddoskias> also i have : # CONFIG_DEBUG_INFO_REDUCED is not set
<lorddoskias> so the compiler should really be even more verbose
<apw> the compiler is still only going to include what it thinks it needs, and it is clearly wrong in this case
<apw> as many files include headers with lots of types, which you don't use
<apw> so including them all would be dumb, it obviously thinks it can remove that one, incorrectly
<lorddoskias> also i've been compiling kernels with older version of the LTS compiler 
<apw> but also in this case, you really have a clear way to dump this
<lorddoskias> ah, freenode, being free node 
<apw> but also in this case, you really have a clear way to dump this
<apw> so i don't see a huge amount of value in actually caring
<lorddoskias> apw: what do you mean by having clear way to dupm this
<lorddoskias> apw: the amount of value caring is the fact that crash, the utility which is used to debug kernel crashes 
<apw> by definition with a full union of this nature, you as dumper needs
<lorddoskias> relies on thread_union being defined in order for it to adjust internal offsets and be  able to dump stacks 
<apw> to know which of the N types it contains
<apw> so you can dump it yourself no?
<lorddoskias> what do you mean by dump it? you keep insisting on this?
<apw> it is either a thread_thing or it is the raw stack
<apw> why do you care this type exists or not
<apw> presumably to display the contents
<lorddoskias> the structure is needed so tthat programatically the stack size can be deduced 
<lorddoskias> because crash adjusts its internal stack size and is able to dump tasks stack?
<apw> the stack size is also defined by STACK_SIZE no ?
<apw> s/STACK_SIZE/THREAD_SIZE
<apw> and on all of the architectures we support stacks grown downwards
<lorddoskias> it is defined based on THREAD_SIZE / target arch size of ulong 
<apw> well it is defined as unsigned long foo[THREAD_SIZE/sizeof(long)] so it is exactly
<apw> THREAD_SIZE bytes long
<apw> on the presumption that none of the other things are bigger than that of course
<lorddoskias> huhz 
<lorddoskias> so you are going to try everything than admit that the compiler is broken and basically you (i mean ubuntu, not you personally ) are not interested in fixing this? 
<lorddoskias> is that your position?
<apw> no i am trying to help you get past this blocker to you
<apw> i am sure the compiler is broken, if the newer one does the right thigns on the same code
<apw> if you file a bug someone might be able to fix it, but the reality is
<lorddoskias> i can get past this blocker by hacking around crash but that's not the point, the point is that ubuntus LTS toolchain should be producing working debug info, no ?
<apw> that fixing the compiler contains risk
<apw> and doing that for something which only affects debugging information is going to 
<apw> be a non-obvious risk balance
<lorddoskias> what if i prove an earlier version of the LTS compiler worked, and that the current one is a regression ?
<lorddoskias> what then?
<apw> not that that is my call as a kernel engineer
<apw> then that is a more compelling case to fix it
<apw> but overall it would be a decision for the compiler maintainer not myself, so i wouldn't
<apw> read a whole heap into my oppinion.  updating compilers always makes me afraid
<apw> my only care was to see if i could help you get past it without needing to fix it
<apw> as that is not going to take 0 time
<apw> even if they don't won't fix the bug
<apw> lorddoskias, do either way file a bug against gcc-5, just don't expect it fixed in short order
<lorddoskias> apw: i have bitter experience with reporting bugs to ubuntu in that those bugs are rarely acted upon. for example 1605843 ...
<apw> LP: #1605843
<ubot5`> Launchpad bug 1605843 in linux (Ubuntu) "Kernel crashes from time to time when using ftrace " [Medium,Confirmed] https://launchpad.net/bugs/1605843
<lorddoskias> where i've provided asm dumps of what's wrong and even the commit that's supposed to fix it so it would have been a matter of cherry picking it up 
<apw> a fix which if i am reading history right was applied and released in 4.4.0-67.88
<lorddoskias> dunno, i switched to the . releases of the lts so i'm currently suing: 4.13.0-37-generic
<lorddoskias> so it works there, but at the time following multiple kernel releases the issue wasn't fixed
<apw> it did get fixed, about a year back, though the bug does not appear to have been referenced
<lorddoskias> it could have even been closed 
<apw> and i have done so, we have a very large volume of bugs, it is very easy to lose individual ones over time
<lorddoskias> so what's the suggested way to downgrade a package ?
<apw> i have tended to get them from the launchpad librarian and install them with dpkg
<apw> https://launchpad.net/ubuntu/+source/gcc-5/+publishinghistory
<lorddoskias> well apt-cache madison seems to be helpful
<apw> that only shows you versions in the pool i assume
<lorddoskias> huhz, but then this barfs about unmed dependencies huhz 
<dijuremo> apw: Arggg my coworker turned off the DELL T3610 where I was testing prime95 on the patched kernel 4.13.0-38.43+lp1759920 I am going to move it elsewhere and start again. As far as I can tell, he properly powered it off at around 3PM, so that means 8-ish hours without freezing.
<s10gopal> how to extract .config from kernel?
<apw> s10gopal, our configs are in /boot alongside the binary kernel
<s10gopal> thx
<s10gopal> !ping
<ubot5`> pong!
<s10gopal> how to fix it ? scripts/sign-file.c:25:30: fatal error: openssl/opensslv.h: No such file or directory
<s10gopal>  #include <openssl/opensslv.h>
<apw> you need to build with the build-dependencies for the kernel installed
<apw> normally you do that by building in a chroot with those installed into it
<s10gopal> apw, can you please explain it ?
<s10gopal> apw, i am using time make deb-pkg
<cascardo> s10gopal: man debuild
<bjf> s10gopal, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<s10gopal> thx
<s10gopal> i am at   CC [M]  drivers/media/pci/ivtv/ivtvfb.o.  how much time it will take to finish ?
<apw> s10gopal, it builds in parallle, so hard to say, when i do a build it takes about 10m but they are scrolling past fast enough to be hard to read
<s10gopal> how to fix ./scripts/package/builddeb: line 33: dpkg-gencontrol: command not found                     make[1]: *** [deb-pkg] Error 127   make: *** [deb-pkg] Error 2 ?
<cascardo> s10gopal: do you have dpkg-dev installed?
<cascardo> s10gopal: apt install build-essential ; apt-get build-dep linux
<s10gopal> cascardo, it was not , i need to do time make deb-pkg  again ?
<cascardo> s10gopal: if you are running make deb-pkg, you are doing it wrong to build an ubuntu kernel
<s10gopal> cascardo, how to do it?
<cascardo> if you want a deb package for a mainline kernel, then you might want to use make deb-pkg
<cascardo> s10gopal: did you read the documentation pointed at you?
<s10gopal> cascardo, yes , but not complete
<s10gopal> in place of make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom i should use make -j4 `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom to use all my 4 core ?
<s10gopal> cascardo, ^
<cascardo> s10gopal: what documentation did you get that from?
<cascardo> certainly not from https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<s10gopal> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild , it is easy i can understand them
<s10gopal> it is wrong?
<cascardo> it depends on what you want to achieve
<s10gopal> i want to find bad commit
<cascardo> s10gopal: from an ubuntu kernel or a mainline kernel?
<s10gopal> bisect v4.12 and v4.13-rc1
<cascardo> s10gopal: you only need to use make deb-pkg, then, if you want to install those kernels using deb packages
<s10gopal> mainline , http://kernel.ubuntu.com/~kernel-ppa/mainline/
<cascardo> but, yes, probably easier to just use make deb-pkg in that case
<s10gopal> i need to repeat the whole process again ?
<s10gopal> time make deb-pkg ? and again it is going to take 100 min or it will be faster this time ?
<cascardo> s10gopal: it's possible it's gonna just do the last steps, if you haven't run any clean command
<s10gopal> and how to find the kernel which i made ? 
<cascardo> should be in the top dir
<s10gopal> at $HOME ?
<TJ-> deb-pkg should put the .deb files in ../ (parent directory)
<TJ-> or if 'make bzImage' in ./arch/x86/boot/
<s10gopal> TJ-, a user on ##linux taught me how to build kernel from git , how i can find ##linux log ?
<TJ-> s10gopal: I have no idea, where di you put it?
<s10gopal> like #ubuntu logs are at http://irclogs.ubuntu.com/
<s10gopal> what is the difference between time make and make ?
<TJ-> s10gopal: oh, thought you meant you'd kept a log locally of the commands. I don't know if ##linux logs, I think it's up to you to do it locally
<s10gopal> thx
<s10gopal> jsalisbury, i have learned how to make kernel , i should test kernel build by you or i can build and test ?
<dijuremo> May I pick you brain kernel gurus? I am looking at some RHEL VMs, the hypervisor is patched and I manually updated the microcode to the 20180312 release, but the VM still shows as vulnerable. Does QUEMU, etc need to be patched as well for the vulnerability to be mitigated?
<apw> yes qemu needs to be updated to pass through the spec bits
<dijuremo> --> runs to open RH support case....
<dijuremo> LOL
<tyhicks> dijuremo: they may have patched everything but you might be using a model which doesn't support IBRS
<tyhicks> dijuremo: to see if such a model is available, you can run 'virsh cpu-models x86_64 | grep IBRS'
<tyhicks> (IBRS support comes as a separate, unique model so that live migration wasn't broken with the addition of IBRS support to the CPU model)
<tyhicks> (you can also use <cpu mode='host-passthrough'> in your domain xml if you don't plan on migrating VMs to another machine)
<dijuremo> # virsh -r cpu-models x86_64 | grep IBRS 
<dijuremo> Nehalem-IBRS 
<dijuremo> Westmere-IBRS 
<dijuremo> SandyBridge-IBRS 
<dijuremo> IvyBridge-IBRS 
<dijuremo> Haswell-noTSX-IBRS 
<dijuremo> Haswell-IBRS 
<dijuremo> Broadwell-noTSX-IBRS 
<dijuremo> Broadwell-IBRS 
<dijuremo> Skylake-Client-IBRS
<dijuremo> So it seems it does support them, but I am not quite sure to force their use.
<dijuremo> I do not manage the RHEV Manager machine and it is outdated, running 3.5 so that may be a problem. Perhaps they need to update that so that I can see Nehalem-IBRS since I only see the CPU types without -IBRS as available.
<dijuremo> I am a proxy for this question, a friend asks related to the ibpb hangups that you guys fixed with the 4.13.0-38.43+lp1759920 patches in the Ubuntu kernel:  which debian kernels have, or will have the fix, or maybe what to look for in the upstream kernel changelog?
<tyhicks> the problematic patch that was sent around during the spectre embargo is "x86/mm: Only set IBPB when the new thread cannot ptrace current thread"
<tyhicks> instead of using that patch, this upstream patch should be used:
<tyhicks> https://git.kernel.org/linus/18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7
<dijuremo> tyhicks: Any idea how I can find out what the latest microcode version should be for a specific CPU, Intel(R) Xeon(R) CPU E5530? I tried expanding the intel-ucode folder on one of my RHEL servers, but after reboot it is not using IBPB/IBRS. dmesg reports: microcode: CPU0 sig=0x106a5, pf=0x1, revision=0x19
<tyhicks> dijuremo: you'll find that info here: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf
<dijuremo> tyhicks: So I note there that they have the new microcode 0x1c but dmesg is reporting in this machine 0x19, likely old from the BIOS. Any idea where I may be able to find out how to force load the new microcode?
<dijuremo> Oh I think I know, I need to rebuilt initrd, right/
<dijuremo> Nope... no luck... still showing revision=0x19 after reboot.
<s10gopal> jsalisbury: can you please build a set of kernels so  i can test them without waiting for you to come online ?
<jsalisbury> s10gopal, The thing with a bisect is you need to know if the current test kernel is good or bad to determine which test kernel to build next.
<s10gopal> suppose we are at 10 so build a kernel for good and another for bad 
<s10gopal> at commit 5 and at commit 15
<s10gopal> jsalisbury: on my laptop it takes 3.5 hour to make kernel from source , how i can speed it up ?
<s10gopal> i am already using -j5
<s10gopal> -j4
<jsalisbury> s10gopal, I can build you the next two kernels.  We just have to be careful when testing and reporting test results.  It's easy to make a mistake.
<jsalisbury> s10gopal, you could get a faster computer ;-)
<jsalisbury> s10gopal, Seriously thought, if it takes that long, tuning isn't going to speed it up much faster
<s10gopal> i am having core i5 6200u , 12gb ram and 128gb ssd
<s10gopal> can you please teach me how to remove modules from kernel , then it will compile fast ?
<jsalisbury> s10gopal, You would need to edit config options.
<jsalisbury> s10gopal, figuring all that out would probably take more time than just doing the bisect
<s10gopal> jsalisbury: can i make kernel on remote machine ?
<jsalisbury> s10gopal, sure, if you have a remote machine.
<s10gopal> it is possible to rent one online ? and how much it is going to cost ?
<jsalisbury> s10gopal, That I have no idea.  You could get an Amazon or Google cloud image, but I really don't think that would be worth it.
<s10gopal> jsalisbury: it is good
<s10gopal> 4.12.0-041200-generic #201804051118
<jsalisbury> s10gopal, this bisect is going to tell us which commit introduced the regression.  We are then going to have to work with upstream to fix up that commit or revert it.
<jsalisbury> s10gopal, I can build the next kernel now
<s10gopal> jsalisbury: ok i will test it
<tyhicks> dijuremo: I just took a quick look and I suspect that Intel didn't fully update their slides
<tyhicks> dijuremo: all the 106A5 CPUIDs have been marked RED, indicating that they're not going to update the microcode, except for yours
<tyhicks> dijuremo: also, your processor isn't listed as receiving a microcode update in their release notes: https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File?product=873
<tyhicks> dijuremo: I suspect that they forgot to change your processor's row to RED in the slides :/
<tyhicks> the 106a5 microcode in their latest bundle matches what your kernel is reporting:
<tyhicks> $ iucode-tool -L microcode.dat  | grep -i 106a5
<tyhicks>   01/129: sig 0x000106a5, pf mask 0x03, 2013-06-21, rev 0x0019, size 10240
<dijuremo> Wow, that is so screwed up... How is one going to figure that out when the slides show yellow and also a firmware 0x1c  and their download page says This download is valid for the product(s) listed below. and includes IntelÂ® XeonÂ® Processor E5530 (8M Cache, 2.40 GHz, 5.86 GT/s IntelÂ® QPI)
<ntd> i have a few grievances with current 4.15, should be worked out before bionic rtm :)
<ntd> "rtm"
<aaa_> what is rtm?
<TJ-> Release To Manufacturing
<aaa_> ty
<aaa_> :)
<ntd> There are some confirmed and reproducible issues with current 4.15 that really should be ironed out before bionic release (potential userbase won't be able to boot)
<ntd> anyone i can talk to about it?
#ubuntu-kernel 2018-04-06
<s10gopal> jsalisbury, 4.12.0-041200-generic #201804051944 is bad
<ricotz> cascardo, hi, please push the hwe-edge branch of 4.15.0-15.16~16.04.1 
<s10gopal> can anyone please help me to setup google cloud to build kernel ?
<s10gopal> i am having 8 core
<juergh> s10gopal, wrong channel
<cascardo> ricotz: pushed
<cascardo> thanks for noticing
<s10gopal> jsalisbury, apw anyone online ?
<bjf> s10gopal, we've offered to build kernels for you, we've pointed you at wikis that tell you how to build them yourself, what more do you need?
<s10gopal> bjf, can you please teach me how to build a kernel on a vm , i chave learned how to build it on my local machine
<bjf> s10gopal, building on a vm is the same as a local machine
<s10gopal> how to copy .config to vm and how to download build kernel from vm ?
<bjf> s10gopal, you need someone to tell you how to copy files between 2 machines?
<s10gopal> i have never used ssh
<s10gopal> i know how cp command work
<bjf> s10gopal, man scp
<s10gopal> thx
<s10gopal> jsalisbury, it is good
<s10gopal> jsalisbury: can i use multimeter to check which laptop component is on after shutdown ?
<jsalisbury> s10gopal, I wouldn't reccomend that.  
<jsalisbury> s10gopal, that could be dangerous due to high voltages
<s10gopal> jsalisbury: i was searching about battery bug , and it happen on most of the laptop , but why no one on bugzilla is taking it seriously?
<jsalisbury> s10gopal, ?   Seems like the folks on this channel are taking is seriously
<s10gopal> yes they are
<s10gopal> jsalisbury: you are online for 3to 4 hours ?
#ubuntu-kernel 2018-04-07
<s10gopal> jsalisbury, 4.12.0-041200-generic #201804061744 is good.
<s10gopal> linux-firmware-image-4.12.0-rc7-custom_4.12.0-rc7-custom-1_amd64.deb   linux-headers-4.12.0-rc7-custom_4.12.0-rc7-custom-1_amd64.deb   linux-libc-dev_4.12.0-rc7-custom-1_amd64.deb     linux-image-4.12.0-rc7-custom_4.12.0-rc7-custom-1_amd64.deb , i need to install these 4 files to install kernel ?
<s10gopal> jsalisbury: apw TJ- only 40 revision are left , it can be manually checked or i need to test 5 more kernel ?
<s10gopal> anyone online ?
<s10gopal> jsalisbury: apw on git bisect i am on commit which is in v4.12-rc7 , it is correct ?
<s10gopal> i have installed linux kernel but i cant see it in grub , how to fix it ?'
#ubuntu-kernel 2018-04-08
<s10gopal> jsalisbury what i have to do after reaching end point ?
<s10gopal> jsalisbury: ?
<s10gopal> jsalisbury, last test 
<s10gopal> git bisect is almost finished , please take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646
<ubot5`> Ubuntu bug 1745646 in linux (Ubuntu Artful) "Battery drains when laptop is off (shutdown)" [Medium,In progress]
#ubuntu-kernel 2019-04-01
<psi29a> I'm tracking the following SRU Workflow ticket (https://bugs.launchpad.net/kernel-sru-workflow/+bug/1819715)
<ubot5`> Ubuntu bug 1819715 in Kernel SRU Workflow security-signoff "linux-hwe: 4.15.0-47.50~16.04.1 -proposed tracker" [Medium,In progress]
<psi29a> is there an ETA for when this will be released to security/update repo?  Another day, a few more... a week?
#ubuntu-kernel 2019-04-03
<_unreal_> hello
<apw> hello
<_unreal_> hello
<_unreal_> trying to compile an RTOS kernel
<_unreal_> I have this board https://www.armbian.com/tinkerboard/ using armbian, the compiling system is setup to only use ubuntu. https://docs.armbian.com/Developer-Guide_Build-Preparation/  this is the build script system.
<_unreal_> I'm not sure how to build the RTOS kernel....
<_unreal_> I have tried downloading the RT kernel patch but it fails to in clued during the compile setup process
#ubuntu-kernel 2019-04-04
<bladernr> Hey, I'm trying to compile the disco kernel from the git tree at 	https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/disco
<bladernr> but I'm getting a failure as something is trying to install a non-existant package (spl-dkms__all.deb) into the fakeroot.
<bladernr> I was following this: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<bladernr> it's been a while (a very long while) since I tried manually compiling a kernel, so likely i
<bladernr> likely I've done somethig wrong, but I can't, for the life of me figure out what that is.
<apw> bladernr, sounds like the zfs/spl versions are missing
<apw> bladernr, from debian/dkms-versions
<bladernr> apw, ahhh, thanks.  So I imagine that is because I'm trying to compile 5.0 on Xenial... 
<apw> bladernr, if you don't need zfs then you should be able to turn them off
<bladernr> apw, got it, thanks! that should get me unstuck.
