#ubuntu-kernel 2006-02-13
<zul> heylo
<fabbione> BenC: when you wake up, please pull from my repo on people.
<fabbione> fixes: one of the CVE from pitti and bubbalwz's regression on megaraid
<fabbione> for now..
<fabbione> i am working on getting also an update for the redhat cluster suite
<fabbione> and ocfs2
<fabbione> BenC: i am almost done with the redhat-cluster-suite.. 
<fabbione> if you want to wait to pull, i will push quite soon
<fabbione> up to you
<zul> heylo
<fabbione> hi zul
<zul> how is it going?
<fabbione> as usual
<zul> fun fun..
<fabbione> BenC: ok i have done a full push.. add redhat cluster updates to the list
<zul> i think his wife ate him..
<zul> i love it when stupid vendors make my life easier
<zul> mmmm....reverse engineer..
<bryanf> BenC: ping
<bryanf> BenC: what bluetooth mouse do you have?
#ubuntu-kernel 2006-02-14
<fabbione> hey BenC 
<fabbione> BenC: i have a bunch of updates to push to git
<fabbione> if you can kindly wait to pull from me, it will spare you another pull in a few hours
<BenC> ok, I probably wont pull till I get back up in the morning :)
<fabbione> perfect
<BenC> hey fabbione, has your powerbook ever booted where capslock and numlock were reverted?
<fabbione> hmm i never noticed that
<fabbione> i don't use any of them
<BenC> last time I rebooted (even in macosx) they were on to start
<BenC> it was weird
<fabbione> oh..
<fabbione> no, never seen
<fabbione> i need to check with the latest kernel tho
<fabbione> it's a bit i don't update the toy
<BenC> well, the lights were on, but they weren't enabled
<fabbione> nope.. never seen
<BenC> shouldn't be kernel related, since macosx was affected too
<BenC> I fear hardware issues :)
<fabbione> possibly
<fabbione> we can verify the OF versions..
<fabbione> i just don't know how
<BenC> something in /proc/device-tree
<fabbione> ok i will look at it later
<fabbione> wife is using it atm
<BenC> I'm hoping terra/ibm will do that deal again soon, my wife wants one for herself :)
<BenC> but that means I'll get the G5 for building/testing
<fabbione> ehehe
<fabbione> BenC: ok i am done with the redhat cluster suite
<fabbione> you can pull anytime
<BenC> ok, thanks
<sn9> any more test builds of snd-powermac.ko?
<BenC> not yet, but I will be getting to it this coming week
<Mithrandir> BenC: prod?
<BenC> Mithrandir: ?
<Mithrandir> BenC: have you done anything which could have made /dev/null turn up as c 0 259 in the latest kernels?
<Mithrandir> (the static /dev/null)
<Mithrandir> (when it's on squashfs)
<BenC> heh, no, pretty sure I haven't :)
<sn9> sounds like a stray udev rule to me
<BenC> unless something in squashfs did it
<Mithrandir> sn9: static dev.
<zul> heylo
<Mithrandir> BenC: same image looks fine with an older kernel.
<Mithrandir> I see it on both i386 and amd64
<sn9> i can check ppc
<sn9> a quick ls -l showed 1,3
<Mithrandir> BenC: if you pull down http://cdimage.ubuntu.com/livecd-base/current/i386.squashfs and look at it, you'll see that /dev/null is c 0 259
<Mithrandir> sn9: how did you check?
<BenC> what do you mean "static dev"?
<Mithrandir> if you mount that image somewhere and look in /dev
<sn9> i did ls -l
<BenC> Mithrandir: but what created that file?
<Mithrandir> : tfheen@thosu /tmp > sudo mount -o loop amd64.squashfs /mnt -t squashfs
<Mithrandir> : tfheen@thosu /tmp > ls -l /mnt/dev/null
<Mithrandir> crw-rw-rw- 1 root root 0, 259 2006-02-03 05:53 /mnt/dev/null
<Mithrandir> BenC: mksquashfs.
<Mithrandir> this worked with -14 but not -15
<sn9> oh. i looked at -14
<BenC> Mithrandir: no, what created /dev/null in the dir where you used mksquashfs
<Mithrandir> BenC: debootstrap/makedev.
<BenC> from what I can tell, mksquashfs is like mkisofs, it doesn't create files
<sn9> you had said "latest kernels" so i thought -14 would be included
<Mithrandir> BenC: it's done on the buildds, which run .12
<Mithrandir>   * Updated squashfs to latest CVS.
<Mithrandir> I wonder if that can be blamed
<BenC> Mithrandir: so maybe debootstrap is at fault?
<BenC> Mithrandir: is /dev/null ok in the root where deboostrap creates?
<BenC> so if you mount the squashfs under -14, it /dev/null correct?
<BenC> if the kernel module is at fault, then the image should be fine, and would work with -14, but not -15
<sn9> maybe the version of mksquashfs used isn't in sync with the squashfs in the kernel
<Mithrandir> BenC: correct.
<Mithrandir> sn9: shouldn't matter.
<BenC> Mithrandir: so you verified that this image works correctly with -14?
<Mithrandir> BenC: yes.
<Mithrandir> BenC: or at least, /dev/null isn't on crack
<BenC> Mithrandir: actually it could matter if they made some whacked change in the filesystem
<Mithrandir> well, they do actually version the file systems, so if so it'd still be a bug in the kernel module
<sn9> just because it shouldn't doesn't mean it doesn't
<Mithrandir> it supports 1.0, 2.0 and 2.1, IIRC.
<BenC> ok, I'm booted into -14 on my powerbook, but I have -15 installed
<BenC> I'll check into this
<Mithrandir> coolie, thanks.
<BenC> Mithrandir: no, there was compatibility options in the kernel module that I wasn't sure about
<BenC> it's possible that I didn't enable/disable one like I should
<BenC> is this holding up cd's?
* Mithrandir does a git pull to look at shiny stuff
<Mithrandir> yes.
<BenC> I'll make it a priority for today then
<Mithrandir> thanks
<BenC> np
<fabbione> hey Ben
<BenC> how long will you be around?
<BenC> hey fabbione
<zul> oh hey BenC..
<BenC> hey zul
<Mithrandir> BenC: I?  An hour more or so.
<BenC> I've been spending the past few days out in my barn working on oopses and breezy->dapper regeressions...will be nice to work inside again :)
<fabbione> hi zul
<BenC> Mithrandir: probably wont be fixed before you leave, but by tomorrow for you :)
<fabbione> BenC: you are good to pull from me
<Mithrandir> BenC: thanks
<fabbione> BenC: tho it might add a symbol, but don't break the ABI
<BenC> fabbione: ok, because I'll want to do a quick upload for this squashfs problem with the ABI bump
<BenC> I might just skip the pull to be safe, and do it after the upload
<fabbione> BenC: if you plan to bump the ABI, it would be good to check OCFS2 and import bug fixes
<fabbione> i didn't get that far
<fabbione> the pull is safe..
<fabbione> but up to you
<fabbione> just don't wait long, there is also that security fix in it
<BenC> ok
<BenC> rebooting to -15, squashfs looked good under -14
<BenC> Mithrandir: fixed
<BenC> uploading soon
<BenC> I would strongly suggest that you update squashfs tools from CVS
<Mithrandir> oh, why?  We're in UVF.
<BenC> it's not a requirement, just a strong suggestion :)
<BenC> the new code isn't being used if you use the v2 tools
<BenC> not sure what benefits the new code holds, but it may fix some problems
<BenC> maybe you can test with both and see if it helps/hurts? especially on ppc where we have oopses
<Mithrandir> I still don't have a workable ppc. :-)
<zul> later
<mdz> BenC: speaking of unionfs powerpc oopses, I've sent you an email regarding some potential assistance there
<mdz> BenC: ack?
<BenC> mdz: ok
<BenC> mdz: what's the subject of the email, I don't see it
<mdz> Subject: [jeremy@au1.ibm.com: Re: Thanks - and guest access card] 
<BenC> heh, I might have deleted that as spam considering the subject, can you resend?
<mdz> sent again
<BenC> thanks
<_ace> !help
<_ace> hi
<_ace> have some questions about make-kpkg
<_ace> specifically how to change the name of the kernel
<_ace> and later also questions about build-kernelpackage
<BenC> what do you mean "name"?
<_ace> I made a kernel with make-kpkg and the deb is named kernel-image-2.6.11_2.6.11-0.2_i386.deb
<_ace> (I know, it's old, I have reasons though)
<BenC> so what name would you like it to be?
<sn9> probably linux-image
<_ace> Something like kernel-image-2.6.11-w4l-686-smp-megaraid.deb
<_ace> sn9
<_ace> linux or kernel, there's a whole stoy behind that! want me to tell ya ?
<BenC> --append_to_version=-w4l-686-smp-megaraid
<BenC> for s/kernel/linux/ do --stem=linux
<_ace> ah
<_ace> that's 'stem' about thank you.
<BenC> not sure where stem came from, but we set it to linux
<_ace> will the append-version get rid of the '_2.6.11-0.2_i386' part 
<BenC> I think the head is that it can be --stem=bsd at some point
<BenC> the 2.6.11-0.2 part is the version
<BenC> or revision to be more exact
<BenC> all of this is covered in make-kpkg(1)
<BenC> and you wont be able to get rid of the _i386 part, that's a dpkg-deb thing, you don't want to mess with it
<BenC> in your first example, linux-image-2.6.11 is the package name, 2.6.11-0.2 is the version+revision, and i386 is the architecture
<_ace> okay Ill play with that a bit more
<_ace> for reference, just chek http://www.suares.an/?page_id=28
<BenC> if you change the package name (--append_to_version), it will change the package name and the version+revision
<_ace> it also explains the reason I went for the 2.6.11 kernel
<_ace> However, in a wiki i read that you can do apt-get source linux-2.6.8.1
<_ace> but that gives an error
<_ace> you can only do that for 2.6.12
<_ace> why is that not possible for 2.6.11 ? 
<_ace> also, the only place I found the 2.6.11 kernel with debian patches
<_ace> is http://security.ubuntu.com/ubuntu/pool/universe/l/linux-source-2.6.11/
<_ace> there are three files (orig, diff and dsc) and I can finally (after some days of toying around
<_ace> )
<_ace> make a kernel from that.
<sn9> it all depends on your sources.list
<BenC> because we never shipped a 2.6.11 kernel
<_ace> BenC: aha ! thx for the clarification!
<BenC> it was a development package, not really supported
<_ace> now this kernel that I found
<_ace> which *version* is that
<_ace> 2.6.11.7 ?
<_ace> or some even older one ?
<BenC> no idea to be honest, It was before my time here :)
<BenC> probably older
<_ace> heh
<_ace> thought so
<_ace> You know the whole problem would be away
<_ace> if win4lin had had a patch for 2.6.12 that *does* include smp support
<_ace> but that is not the case
<_ace> that cost me a lot of time
<_ace> win4lin distributes generic kernels
<_ace> with 2.6.8.1 
<BenC> the 2.6.11 patch doesn't apply to 2.6.12?
<_ace> and it doesn't boot on my machine since it misses the megaraid
<_ace> drivers..
<_ace> eh.. 
<_ace> i haven't tried
<BenC> and if not, have you tried manually fixing the failed hunks of diff?
<BenC> you should try
<_ace> but i figured why they publish a patch for 2.6.12 that has no smp support
<BenC> just because they say 2.6.11, doesn't mean it wont work with 2.6.12
<_ace> if it were that easy...
<_ace> guess i should try that...
<BenC> probably because the 2.6.11 patch applied cleanly to 2.6.12? :)
<_ace> would be very strange
<BenC> I'd give it a go, if you get a couple of .rej's you can clean them up by hand usually
<_ace> http://www.win4lin.com/component/option,com_remository/Itemid,76/func,select/id,4/
<_ace> they *do* have a patch, if the 2.6.11 worked, why make a 2.6.12 patch with no smp support ?
<_ace> 2.6.13 doesn't have smp support
<_ace> en at 2.6.14.3 suddenly it's back
* _ace mind boggles...
<BenC> just making suggestions, I've no idea what might or might not happen with it
<_ace> good idea though, I might try that.
<_ace> still, in the end I want a *real* ubuntu kernel
<_ace> so now I learned about dpatch
<_ace> heh
<_ace> and build-kernelpackage (or whatever that command is called) failed miserably with the 2.6.11
<_ace> stuff and now I know why :-(
<_ace> I'll go off and try some stuff now... brb...
<_ace> thanks so far...
<bubbalwz> BenC: any idea when the kernel update will be out that'll fix megaraid?
<bubbalwz> i thikn fabbione had the changes
<BenC> I pulled his changes for dapper earlier
<bubbalwz> ok, so nothing for breezy?
<bubbalwz> i tested a kernel he sent me ... 2.6.12-10-686.26
<bubbalwz> on breezy
<bubbalwz> just wonderinf if that would make it into a security update
<_ace> whatr's wrong with the megaraid ?
<fabbione> bubbalwz: i am uploading to breezy now or tomorrow.
<fabbione> bubbalwz: the fix is there
<fabbione> bubbalwz: ok 2.6.12-10.27 is up
<fabbione> it will take a day or probably 2 to be in the archive
<fabbione> with that version you should be fine
<fabbione> linux-source-2.6.12 (2.6.12-10.27) breezy-security; urgency=low
<fabbione>   Changed by Fabio M. Di Nitto:
<fabbione>   * Fix regression from hoary kernel in megaraid scsi driver:
<fabbione>     In the breezy kernel a split up of the megaraid and megaraid_m* driver was
<fabbione>     done to be able to support all controllers. During the split one pci
<fabbione>     subvendor ID was lost due to removal of PCI_ANY catch all.
<fabbione>     Thanks to Brian (bubba) Wilson for spotting the issue and testing the fix.
<fabbione>     Update drivers-scsi-megaraid_splitup.dpatch with the missing ID.
<fabbione>   * [SECURITY] : Fix extra dst release when ip_options_echo fails:
<fabbione>     - Add patch CVE-2006-0454.dpatch.
<fabbione>  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Wed, 08 Feb 2006 10:41:12 +0100
#ubuntu-kernel 2006-02-15
<fabbione> BenC: please pull from me again when you can. I have an endianess fix for gfs
<jbailey> BenC: ping?
<BenC> jbailey: pong
<BenC> fabbione: will do
<fabbione> hey Ben
<jbailey> BenC: Since -15.20, I seem to be getting much more frequent kernel crashes on ppc64-smp.
<jbailey> (on an actual smp system)
<jbailey> The last two mornings I've come back to the machine powered off, and it powered itself off mid evening yesterday.
<BenC> odd, nothing really changed that should affect that
<jbailey> I think this is diferent than the X crashes that I Was seeing, where I could often just ssh in and kill X and start again.
<fabbione> hmmm
<jbailey> Although I'd occasionally get crashes before that would lock the machine solid.
<fabbione> i wonder if it is a heating problem
<fabbione> i recall benh fixing something in that direction
<BenC> that's one possibility, there was a recent therm change
<jbailey> I would've expected something in the logs in that case.
<fabbione> with the exact same kind of description
<fabbione> jbailey: it depends..
<fabbione> what kind of thermal module are you using?
<jbailey> therm_pm72
<BenC> jbailey: if hw shutsdown without telling linux, it wouldn't
<fabbione> it might need something like verbose=1 to print more
<jbailey> BenC: Oh right, not an event saying "please shutdown, I'm too hot"
<BenC> right
<BenC> hw could just say, "oh fuck the OS, we're taking drastic measures"
<jbailey> Unfortunately, I don't have a serial port on this, so I'm not sure what I can do.
<jbailey> I should get around to implementing the kdump stuff at some point.
<fabbione> jbailey: what about looking at the module parameters?
<jbailey> fabbione: I haven't tweaked anything that I know of.  What do you suggest?
<BenC> yeah, enable verbose and see if there's some hint at this theory being correct
<BenC> rmmod therm_pm75
<BenC> modprobe therm_pm72 verbose=1
<fabbione> start removing your porn anime desktop and put a gay pic of Ben.. it might get less hot in that case
<jbailey> root@starshine:~# modprobe therm_pm72 verbose=1
<jbailey> FATAL: Error inserting therm_pm72 (/lib/modules/2.6.15-15-powerpc64-smp/kernel/drivers/macintosh/therm_pm72.ko): Unknown symbol in module, or unknown parameter (see dmesg)
* jbailey checks dmesg
<BenC> odd, that's one of my canned bug report suggestions, I'll send you the link :)
<jbailey> Yup, just doesn't know verbose.
<jbailey> fabbione: I could do up a picture of Ben and some tenticle pr0n.  'cause you know tenticle pr0n is *always* hot.
<BenC> fabbione switched to the goats.cx website for his desktop and that worked
<fabbione> ahha
<BenC> but his icons keep going missing
<fabbione> jbailey: read the comments at the top of therm_pm72.c
<fabbione> ahhahahaha
<jbailey> Hmm, I hadn't seen that suggestion before when searching, but I was mostly seaching for "ppc"
<jbailey> BenC: Swallowed up? =)
<BenC> hehe, into anal obscurity
<fabbione>  *        - Add things like /sbin/overtemp for non-critical
<fabbione>  *          overtemp conditions so userland can take some policy
<fabbione>  *          decisions, like slewing down CPUs
<fabbione> (from the TODO)
<jbailey> fabbione: While you're in there, can you look up what the verbose parameter is, please?
<fabbione> there are no module parameters at all
<fabbione>                 if (rc > 0) {
<fabbione>                         state->adc_config = buf[0] ;
<fabbione>                         DBG("ADC config reg: %02x\n", state->adc_config);
<fabbione>                         /* Disable shutdown mode */
<fabbione>                         state->adc_config &= 0xfe;
<fabbione> HMMMMMMM
<fabbione> jbailey: the best would be to compile it with -DDEBUG
<jbailey> Bah, the ongoing X problems don't help.  *cRy*
<fabbione> jbailey: compile just that module with debug
<fabbione> that will add some more verbose output
<fabbione> it's a try
<jbailey> 'kay.  I'll fire that up over lunch.
<jbailey> In the meantime, I'm going to keep it from loading radeon.ko and see if that helps the X problems at all.
* jbailey reboots for this.
<jbailey> Wow, I've made it to 2h of uptime.
<jbailey> Maybe it's truly just the DRI stuff with X that's killing it.
<BenC> must be something specific to ppc64 or your chipset, because I'm using radeon on my pb without problems
<jbailey> Right, but you said you weren't actually using it much.
<jbailey> Although in the last day or so it's been failing after I've stopped using it - but I've been logged in each time.
<jbailey> So it could've been screensavers or whatnot.
<BenC> on my pb I use it all day long
<jbailey> Hmm
<jbailey> I'd have to ask benh, I guess.
<jbailey> Hmm, I'm going to try removing the XAA hack that Fabio had me do before and see if it's the same or worse.
<jbailey> Nope, still need the         Option          "XaaNoOffscreenPixmaps"
<fabbione> Log for failed build of linux-source-2.6.15_2.6.15-15.21 (dist=dapper)
<fabbione> Missing /build/sparcbuildd/linux-source-2.6.15-2.6.15/debian/abi/2.6.15-15.20/sparc/sparc64 file.
<fabbione> BenC: is it known?
<BenC> yeah, I never got a 2.6.15-15.20 build for sparc (nor a 14.19 for that matter)
<fabbione> oh right
<fabbione> they  are built
<fabbione> we can't upload them
<fabbione> i keep building even if we can't upload, to catch FTBFS
<fabbione> the buildds will catch up pretty fast
<fabbione> BenC: echo 1 > debian/abi/ignore.sparc or sparc.ignore should do
<fabbione> that will allow you to "rebootstrap" the abi files later on
<BenC> ah, ok
<fabbione> basically it will disable the abi checker on the specific arch
<BenC> I already know it builds, but I deleted the build, so didn't have the file
<fabbione> no problem
<makx> fabbione: could you please bounce me your new megaraid patch?
<BenC> makx: all his patch does is let some cards get detected
<BenC> it doesn't fix any sort of bugs
<makx> BenC: that sounds not so bad, as we carry the same old version ;)
<BenC> it was a bug we introduced though, so unless you copied our changes, it wont really affect you
<BenC> the source is on archive.ubuntu.com though
<jbailey> BenC: Machine died over my lunch break.  Killing dri wasn't enough for that, I guess.
<BenC> died as in locked up, or died as in shut itself down again?
<jbailey> shut itself down.
<jbailey> I haven't had any X lockups since killing dri.
<BenC> weirdness
<BenC> I've got my G5 running and I'm doing a dist-upgrade (it's still running -13)
<BenC> I'll see if I can induce something
<jbailey> Is it bad that I'm hoping you have the same problem? =)
<BenC> I'm hoping I do, so I guess it's ok :)
<BenC> I have a nice java game and some GL programs lined up to run
<BenC> GL has the nice effect of pushing CPU, graphics and memory all at once
<BenC> and java is just a plain resource hog
<jbailey> =)
<jbailey> I haven't actually had it shut itself off in front of me yet.
<jbailey> So I don't know what leads up to it.
<mxpxpod> jbailey: a watched computer never shuts off ;)
<jbailey> mxpxpod: Sure.. I'll use that to explain to my wife why I never get up from this thing.
<mxpxpod> there ya go
<mxpxpod> seems valid to me
<BenC> it's odd, my G5 is 1.5ghz/1GB-ram, and my laptop with 1.6ghz/512MB-ram seems a lot quicker
<BenC> sound on the G5 is a little choppy too
<chuck> heylo
<zul> BenC: i was thinking of adding the qemu kernel module this weekend if there is a mol module
<BenC> as long as the code is free and doesn't require any non-free stuff to load the module
<zul> ok..
<zul> blah...we arent allowed to redristbute it
<zul> later
#ubuntu-kernel 2006-02-16
<zul> heylo
<zul> BenC: ping
<HiddenWolf> Can anyone help me figure out what is exactly the problem on bug 29789?
<HiddenWolf> Perhaps I can find a fix myself, if I get a clue what to look for.
<HiddenWolf> BenC: ping
<HiddenWolf> BenC: got a minute to help a user with figuring out a bug?
<BenC> what bug?
<chuck> heylo
<HiddenWolf> BenC: https://launchpad.net/malone/bugs/29789
<HiddenWolf> BenC: wondering what to look for so I can google for patches and/or work around it.
<HiddenWolf> Watching winter olympics opening without sound wasn't nearly as much fun.
<BenC> probably best to check the alsa bugzilla
<BenC> also, see if they can do a test build of alsa-cvs
<HiddenWolf> is it alsa?
<BenC> the sound is usually alsa
<HiddenWolf> Usually when this happens with alsa-upgrades it's a mixer. but those where actually left intact this time.
<BenC> maybe there is an update for the bttv audio driver
<HiddenWolf> Hm, ok.
<chuck> BenC: are you going to pull in 2.6.15.4?
<BenC> zul: thanks for reminding me, just pulled it
<zul> no probs that takes care of some of my patches :)
#ubuntu-kernel 2006-02-17
<peterz> 2.6.15-15.21 686 fails to boot UML guests
<BenC> peterz: should be fixed in -15.22
<yvesC> hi, ubuntu-kernel people. I have just upgraded my (ed)ubuntu ppc box to dapper, and i have clock problem. Is that a known problem ?
<BenC> depends on what you mean by "clock problem"
<yvesC> hwclock does not know any way to acess rtc. Even if i modprobe genrtc, date stay to 1974.
<yvesC> And some programs seems look date strangely. sudo says "timestamps in the future", even if i set date manually with "date". screensaver are always running... and some others problem like that.
<BenC> so hwclock isn't working?
<yvesC> hwclock  isn't working, yes
<BenC> what sort of ppc is this?
<yvesC> smp G4 :  bi 867 (windtunnel)
<yvesC> machine         : PowerMac3,6
<yvesC> motherboard     : PowerMac3,6 MacRISC2 MacRISC Power Macintosh
<yvesC> detected as     : 129 (PowerMac G4 Windtunnel)
<yvesC> pmac flags      : 00000010
<yvesC> L2 cache        : 256K unified
<yvesC> memory          : 1280MB
<yvesC> pmac-generation : NewWorld
#ubuntu-kernel 2006-02-18
<zul> heylo
<TheMuso> c
<zul> heylo
<zul> canadian health care system sucks
<zul> i have a possible broken foot and the clinic i went to on thursday wont have the results back for 7 to 10 business days
<BenC> you have to wait that long before they get the results of the xray?
<zul> yeah...
<zul> one of the best in the world my ass..
<fabbione> holy cow
<fabbione> xray's result are like.. IMMEDIATE
<BenC> I've never heard of anyone leaving the office without their xray results in hand
<fabbione> GO ZUL!
<BenC> zul: maybe you need a better clinic that doesn't have to send them out ofr processing?
<fabbione> sucks to be you
<fabbione> it's about time to move to a more civilized country.. like Brazil
<fabbione> or somewhere in the middle east
<zul> heheh...or denmark
<peterz> good hospitals there afaik
<zul> no its just more civilized ;)
<BenC> At least now I know what happens when the batteries go dead in my bluetooth mouse
<BenC> pointer shoots to the top right of the screen and goes wacky
<peterz> BenC: btw, what caused UML do go crazy on me? last time I saw something like that the posix timers where a goner
<BenC> userspace memory address mapping
<BenC> will be fixed in the next kernel
<peterz> yes you said, haven't sen it hit the repo yet though
<BenC> if I already said that to you, why ask about it again? :)
<peterz> you said it would be fixed, not what caused it ;-)
<chmj>  /quit later 
* #ubuntu-kernel  [freenode-info]  channel flooding and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<zul> isnt it convient that when you want to get a bug-report from a user they throw their laptops off the table
<cjb> That's a clever way to avoid having to use launchpad.
<BenC> hehe
<cjb> Morning BenC.  :)
<BenC> good morning
<cjb> Or, uh, perhaps morning.  Where do you live, again?
<BenC> well, it's 12:22pm here
<BenC> so close enough
<cjb> Ah.  Same timezone as me, then,  Are you covered in snow too?
<BenC> I wish
<BenC> we got a light snow fall all day, but no accumulation
#ubuntu-kernel 2006-02-19
<mxpxpod> BenC: ping
<marcreichelt> hi there
<marcreichelt> my ubuntu kernel seems to have problems with acpi - nearly every time when my laptop is under heavy use (e.g. reading big files from my external usb disk or burning a cd) it just hangs up with a kernel panic
<marcreichelt> a shot of the screen can be found here: http://www.marcreichelt.de/misc/kernelpanic.jpg
<marcreichelt> I tried to deactivate all modules containing the word "acpi", but this didn't fix the problem
<marcreichelt> I also tried to deactivate acpi on boot, with "acpi=off" as kernel parameter
<marcreichelt> the result was that the system frozed after approx. 30 seconds after boot time
<marcreichelt> do you have any ideas? is this a bug in the ubuntu kernel? what can I do?
<mjg59> marc_learning: "acpi_processor_idle" just means that the system wasn't doing anything at the time
<mjg59> But you can check by unloading the "processor" module
<marcreichelt> back again
<marcreichelt> hmm
<marcreichelt> processor depends on speedstep_centrino, and I can't unload that one, because it is in use
<marcreichelt> but it doesn't say by which module it is used
<Mithrandir> it's probably used by powernowd or something similar.
<infinity> No, you can't unload centrino.  mjg59 and I ran into that a week or two ago.  It's thpethul.
<infinity> The only way I could "unload" it was to not load it in the first place.
<marcreichelt> k
<marcreichelt> how can I deactivate it on boot?
<marcreichelt> so that "processor" and speedstep_centrino aren't started at boot time?
<infinity> Blacklist them in modprobe.
<marcreichelt> Mithrandir, I killed powernowd
<infinity> Alternately, move the files somewhere else so you're sure nothing can load them. :)
<marcreichelt> moment...
<marcreichelt> brb
<marcreichelt> ok, I created the file /etc/hotplug/blacklist.d/asuslaptop-problems and wrote the line "processor" into it
<marcreichelt> is this correct?
<marcreichelt> I think it should be
<marcreichelt> well, I'm going to reboot now
<marcreichelt> see you in a few minutes
<marcreichelt> hello again
<marcreichelt> my module "processor" is still running
<marcreichelt> even a line in /etc/hotplug/blacklist did not work
<marcreichelt> you still mean that it would be good to rename the module?
<marcreichelt> k, I renamed the processor module
<marcreichelt> brb
<marcreichelt> hi again
<marcreichelt> he still loads the module "processor" - but I renamed processor.ko to processor.ko.old... :-/
<marcreichelt> maybe I have to create a new initrd?
<marcreichelt> or kernel?
<marcreichelt> or is there another way to fix my problem?
<marcreichelt> I would hack myself into the kernel to solve this problem if I would have the time to
<marcreichelt> the problem seems to be in processor.c
<marcreichelt> :-(
<marcreichelt> brr
<marcreichelt> again a kernel panic
<makx> what ubuntu version are you using
<makx> blacklists should be under /etc/modprobe.d
<marcreichelt> Breezy
<marcreichelt> Kernel: 2.6.12-10-386
<makx> yes put it there
<marcreichelt> moment
<marcreichelt> makx, how should the blacklist look like?
<marcreichelt> just a file containing the line "processor"?
<marcreichelt> ?
<makx> blacklist evbug
<makx> for example
<marcreichelt> k
<marcreichelt> for me it is blacklist processor, then
<marcreichelt> ok, brb
<marcreichelt> no, it didn't work
<marcreichelt> he is still loading the module "processor"
<marcreichelt> is there a kernel version which does not contain this bug?
<zul> heylo
<BenC> marcreichelt: dpkg-reconfigure linux-image-`uname -r`
<BenC> that will generate a new initramfs
<mxpxpod> BenC: have you had any problems lately with your ae?
<BenC> none
<BenC> other than the weird eth0_clashed thing, but that's not particular to ae
<mxpxpod> BenC: check this out... someone in my apartment installed a wireless router with authentication on the same channel as mine and my ae gets a ton of DEAUTH messages from it
<mxpxpod> this causes klogd to go crazy and take up like 10% cpu
<BenC> hmm, sounds like softmac actually
<mxpxpod> if I switch to another channel, I don't get it
<mxpxpod> oh, really?
<BenC> maybe I need to turn down the verbosity
<BenC> the messages I think come from softmac
<mxpxpod> yeah, dmesg is full of DEAUTH's
<mxpxpod> it's quite frustrating... so I switched channels
<BenC> actually, it's right from ieee80211.ko
<lamont> BenC: can you easily tell me when the last update of the hppa patch in 2.6.15 happened?  (was -13 built with the hppa patchset, or without, to be specific...)
<BenC> I've never applied an hppa patchset per se
<BenC> I merely got what was there to work
<BenC> lamont: so it's 99% stock 2.6.15 code for hppa, with just one backport for a compat syscall I can't recall off hand
<lamont> BenC: please consider merging the following patches (minimum) from ftp://ftp.parisc-linux.org/patches
<lamont> diff-2.6.12-rc3-tulip_21142_phyinit, diff-2.6.3-tulip, diff-2.6.6-tulip_stop_rxtx, diff-tulip_phy_reset-03
<lamont> all 4 are in akpm's tree
<lamont> those patches make tulip work on modern hardware...  bug exists on hppa as well as some i386 platforms
<marcreichelt> BenC: just leave the processor blacklisted and generate a new initramfs?
<fs> what's the current status of the megaraid newgen/legacy patch? 
<fs> never mind, found it: it's merged upstream.
<lamont> BenC: I'll start working through the hppa patchset to see what makes sense for us to include
<lamont> as in, what's low-risk and/or hppa specific
<marcreichelt> ok, I give up
<marcreichelt> the module 'processor' is still running
<marcreichelt> maybe I'm just too stupid for this :-/
<BenC> marcreichelt: rm -f the module
<marcreichelt> hmm
<marcreichelt> or better mv module module.bak?
<marcreichelt> ok
<marcreichelt> root@tux:/lib/modules/2.6.12-10-386/kernel/drivers/acpi # mv processor.ko processor.ko.bak
<marcreichelt> now I do dpkg-reconfigure linux-image-`uname -r`
<marcreichelt> hmm
<marcreichelt> root@tux:/lib/modules/2.6.12-10-386/kernel/drivers/acpi # dpkg-reconfigure linux-image-`uname -r`
<marcreichelt> Not touching initrd symlinks since we are being reinstalled (2.6.12-10.26)
<marcreichelt> Not updating image symbolic links since we are being updated (2.6.12-10.26)
<marcreichelt> it seems that he didn't noticed anything
<marcreichelt> I have to go
<marcreichelt> see you
#ubuntu-kernel 2007-02-12
<markedwards> anyone around who can comment on the status of the sky2 hang bug?
<fabbione> morning
<Eruantalon> fabbione: night
<zul> hey
<pkl_> hey ho...
<BenC> booger
<BenC> looks like we'll need a legacy fglrx package for older cards that aren't suported anymore :/
<zul> sucky
<pkl_> it'll be nice if I knew what that meant.... fglrx == ?
<zul> ati
<BenC> proprietary ATI drive
<BenC> r
<pkl_> ah, OK.
<BenC> the newer one we put in feisty dropped support for a few cards
<mjg59> BenC: Do we have any indication from ATI that they'll be providing security support for the older drivers?
<BenC> mjg59: none, which is my concern...doesn't the old driver still contain some root bug?
<mjg59> If they're not going to do security support, we shouldn't ship it
<mjg59> But we should probably try to get an authoritative answer from them first
<kylem> morning.
<mjg59> kylem: So I've got one of those new Atheros cards
<kylem> hot. get to work. :)
<mjg59> Checking MacOS, they've got an entirely different driver for them
<mjg59> When compared to the old ones
<mjg59> Still seems to have a hal, though
<mjg59> And still some references to 5212 in it
<kylem> hmm.
<mjg59> kylem: Tell you what, you get r500 going and I'll beat on the wireless
<mjg59> Seem fair?
<kylem> heh. i don't have any r500, so the inverse is probably easier for me. ;-)
<mjg59> Tch.
<mjg59> Ok, we'll do it your way
<mjg59> You've got a building dadwifi tree, get to it :)
<kylem> heh.
<zul> argh....use...an...atctachment
<BenC> mjg59: PM trace is adding a lot of shit to dmesg :)
<mjg59> BenC: Yeah, those printks can probably be disabled
<BenC> mjg59: the "Adding info for..." ones?
<mjg59> Yeah
<mjg59> And "Removing info for..."
<BenC> done
<zul> *grumble*
#ubuntu-kernel 2007-02-13
<mjg59> BenC: I've sent you a patch that makes appleir work better
<mjg59> Like, at all
<BenC> hehe, sounds like a winner
<TheMuso> c
<TheMuso> ~/
<TheMuso> bah
<crimsun> BenC: set 1 of 3 of Realtek HDA patches emailed to you
<BenC> crimsun: Thanks
<rotarychainsaw> I hate to ask this in here, please don't kill me, but...
<rotarychainsaw> Is there something wrong with the Edgy kernels? I have been having some trouble with an old nvidia card and in my search around the web it seems that all the other people sharing my problem are on edgy as well.
<rotarychainsaw> NVRM xid : xxxxxx blah blah blah, in the kernel log and a hard lock. Just wondering if this has ever been brought up? Thanks.
<fabbione> ubuntu-xen-desktop - Xen software for running on servers.
<fabbione> zul: ^^^
<fabbione> what about a sane description?
<eeos> hi there. I think there is something broken in yesterday's update (2.6.10-11). some modules do not compile anymore. did anyone notice the same thing?
<raphink> hi there
<raphink> anybody aware of a kernel panic on amd64 dapper with 2.6.15-28.51 (newest security upgrade) ?
<raphink> infinity, BenC, fabbione, lamont ?
<ivoks> where does it panic?
<fabbione> raphink: i don't run dapper on amd64.. so no idea
<raphink> ivoks: uncompressing / I think
<raphink> can't check, I just helped my mom fix that by moving back to 2.6.15-27
<raphink> and I didn't see the trace myself
<raphink> kernel panic with a security upgrade in LTS is pretty bad :(
<ivoks> i have one amd64
<infinity> That sounds more like the initramfs wasn't generated, or can't be found.
<ivoks> i agree with infinity 
<ivoks> this isn't kernel issue
<ivoks> (directly)
<raphink> hmmm
<raphink> indeed there's no init
<raphink> no initrd for this kernel
<raphink> sorry, my fault :(
<raphink>  /boot was full, so the initrd was not written :-(
* raphink apologizes
<Nafallo> infinity: hi! glad to see you're back :-)
<infinity> Was I ever gone?
<infinity> A man avoids IRC for a couple of months, and everyone thinks he's dead...
<Nafallo> hehe
<Nafallo> something like that ;-)
<kylem> morning.
<pures> hiya, I'm running Ubuntu Dapper(6.10) and installed the 2.6.20 kernel, and am getting a bug in my libata.ko module when loading sata_sil.ko for my sata drive.  I'm actually running the latest patch version hoping that would fix it, anyone know anything about this? 
<pures> wrong channel?
<zul> hey
<Nafallo> hi zul 
<zul> BenC: i was just reading the roadmap and about reading the third party packages how is that going to work?
<BenC> zul: ubuntu/* would be moved into a separate package
<BenC> I wish launchpad supported triggers so you could force the rebuild of other packages from one upload
<zul> BenC: ok..so in theory Xen could be a seperate package and depend on linux-meta?
<zul> in theory of course
<BenC> linux-meta would depend on it, you mean?
<zul> yeah..
<zul> scarey as it is
<eeos_> is it possible to install kernel 2.6.20 on 6.10? how?
<eeos_> sorry 6.10 as in kubuntu 6.10
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-8.14 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules.
<mower> wtf sort of SSI is this? @include hdr.html@
<mower> its coming up on this webapp, without actually executing it
#ubuntu-kernel 2007-02-14
<zelrik>  hello 
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: You seem to be the right guy to talk to about usplash_write :)
<BenC> mjg59: I have a script that is using INPUTENTER, and the second call doesn't seem to wait for an enter key...any ideas?
<mjg59> I didn't write that code, I'm afraid
<BenC> Ah, then the manpage is misleading
<BenC> or maybe you're the author of the manpage
<mjg59> Oh, I wrote the rest of it
<mjg59> Just not the input stuff
<BenC> ah
<mdz> BenC__: I'm sure I"ve asked this before, but I don't remember...can I use either of the sets of prebuilt vmware modules with VMWare workstation?  if so, which one?  if not, what's my alternative?
<lifeless> its the same modules for both workstation and server no ?
<BenC__> mdz: Either -player or -server should work with workstation
<mdz> BenC: I have the server modules installed, but can't get workstation to run
<BenC> mdz: It's not simple getting it to use them though
<mdz> vmware-config.pl tries to build the modules and fails (they don't compile)
<BenC> mdz: is this workstation 5 or beta6?
<mdz> BenC: 5
<mdz> is it easier with 6?
<BenC> mdz: No, but I have beta6 tarballs that build
<BenC> you can probably snag the tarballs in lrm and put them in /usr/local/lib/vmware/modules/source/
<mdz> I only have a license for 5
<mdz> maybe it's time to try kvm
<BenC> grep vmx /proc/cpuinfo
<BenC> if that doesn't show anything you might as well use qemu
<mdz> it doesn't (this is an amd64)
<BenC> Oh, I forget what the amd64 flag is
<mdz> open /dev/kvm: No such file or directory
<mdz> Could not initialize KVM, will disable KVM support
<BenC> but "modprobe kvm-amd" should only work if you support it
<BenC> you have to load the module manually
<BenC> and you'll need to add yourself to the kvm group to access /dev/kvm
<mdz> doesn't load, oh well
<BenC> qemu works pretty well
<BenC> not sure what you are using it for, but I used it for some install/kernel testing
<BenC> usplash seems to be just dieing when I use INPUTENTER
<BenC> mjg59: is there an easy way to test usplash from command line?
<mjg59> BenC: Easiest is to ssh in
<BenC> confirmed...using any sort of input junk just fucks usplash all up
<BenC> if it doesn't crash immediate, it will shortly after
<mjg59> BenC: Probably some buffer overrun in there
<mjg59> BenC: Tried valgrinding it?
<BenC> not yet
<pkl_> mdz: BenC: the am64 VT flag is svm ...
<BenC> mjg59: valgrind doesn't show anything useful
<BenC> I think it might just be the fifo getting closed
<BenC> mjg59: Found it...close(fifo_outfd) gets called when fifo_outfd isn't initialized to anything know
<BenC> betting it's closing random fd's
<mjg59> BenC: Oh, urgh.
<mjg59> BenC: It's in bzr - feel free to commit a fix :)
<TheMuso> c
<BenC> lol
<BenC> char inputbuf[PIPE_BUF] ;
<BenC> free(inputbuf);
<mjg59> Oops.
<BenC> This thing is whacked...usplash_write "INPUTENTER ..." doesn't block, but usplash does until it gets input
<kylem> heh.
<BenC> the broken part is that the outfifo doesn't get anything when INPUTENTER is used
<BenC> yay, it's working
<BenC> three bugs in one function
<BenC> mjg59: Got the bzr url for usplash?
<mjg59> Not to hand
<mjg59> It's on Launchpad
<BenC> sweet, the fixes give me working usplash stuff for driver-updates
<mjg59> Win
<fabbione> BenC: still around?
<mdz> BenC: it's in ~ubuntu-core-dev I believe
<pwnguin> BenC: toshiba-acpi appears to be fixed now
<BenC> pwnguin: excellent, thanks for checking it
<pwnguin> BenC: ive also noted this on launchpad.
<pwnguin> (and removed it from my laptop testing page)
<zul> BenC: quintela the redhat guy is having a hell of a time port Xen to 2.6.20 fyi
<zul> later
<nemro> erm
<_MMA_> BenC: Can you still use the -lowlatency kernels in Edgy?
* _MMA_ doesnt know if things have changed.
<BenC> _MMA_: Current kernels have problems with older hal
<_MMA_> :(
<BenC> you can use it, but some things stop working (like inserted a CD or usb-storage drive wont auto-mount)
<_MMA_> Ok. Ill let them know.
<_MMA_> I have someone who wants to try it.
<BenC> you could pull in the newer hal with the rest of the deps that feisty kernel needs
<_MMA_> Thanx.
<_MMA_> Ok.
<BenC> hal, udev, module-init-tools, initramfs-tools
<BenC> that should cover it
<_MMA_> It should just do it right? As a depend?
<_MMA_> The update.
<BenC> kernel doesn't depend on too many things like it's supposed to
<_MMA_> Well it mess with a Edgy kernel?
<BenC> I can conflict with older hal, but then it might cause older hal to get removed, so I don't do it
<_MMA_> If they go back that is.
<BenC> not sure
<_MMA_> Ok.
<BenC> actually it does a little
<BenC> initramfs-tools wont generate initrd's for edgy kernels
<_MMA_> hmm...
<BenC> I should probably fix that, so that might not be true for feisty release
<_MMA_> Ok. I have a guinea pig but this might deter them.
<lifeless> isn't there a DRI ABI incompatability across edgy <-> feisty ?
#ubuntu-kernel 2007-02-15
<ivoks> anyone around? :)
<zul> heylo
<alehke> hi
<Keybuk> would anyone admit to knowing much about inotify?
<st3> we reported a critical bug about bcm43xx here: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/85404
<st3> we are receiving a lot of bug reports from ubuntu users, please fix it asap
<st3> thank you
<BenC> st3: for one, ogra was getting bcm43xx crashes and/or poor performance
<st3> what does poor performance mean?
<BenC> damnit, and ogra just left
<BenC> poor performance means if he was more than 10 feet from the AP, he lost connection
<st3> note that 4311 and 4318 are partially supported
<BenC> I think that performance issues are mostly 4318 related
<st3> there are big issues with interferences and power transmission
<BenC> but the oopses are an issue regardless
<BenC> he has an AMD64 laptop with 1G ram
<BenC> and I thought that might be related, but didn't have time to debug his system
<st3> ah yes, there are some experimental patches by larry finger
<BenC> give me a few minutes to pull up some bug reports
<st3> you should have included that ones, instead
<BenC> wth is that bug report unchangeable by me?
<st3> i don't know, the bug was filed by michael
<st3> (link: ftp://lwfinger.dynalias.org/patches)
<BenC> oh, viewstatus
<st3> (e.g. ftp://lwfinger.dynalias.org/patches/patch_2.6.20_for_DMA_over_1GB)
<BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/77280
<BenC> that's an unload bug
<BenC> ogra's oops happened at random times during usage
<st3> it's softmac related
<st3> by the way, did you have him check /proc/interrupts?
<BenC> the oops totally locked his box, so checking anything was impossible
<BenC> If I remember right, the oops was in interrupt
<st3> even with netconsole?
<st3> is linux-source-2.6.20 (Ubuntu) a vanilla kernel?
<BenC> netconsole doesn't bring the box out of a total lockup :)
<BenC> it's mostly vanilla
<st3> any patches related to softmac?
<BenC> none
<st3> he should enable full debugging output for both softmac and bcm43xx, and paste some more lines from dmesg right before the oops
<st3> ogra, BenC was telling me about your oops
<ogra> right, i didnt have it since some time ..
<st3> i think you should enable full debugging output for both softmac and bcm43xx, then post a bug report to bcm43xx-dev@lists.berlios.de
<ogra> but with the recent kernel i have it complaining about my firmware being to old
<st3> with the ubuntu kernel, you mean?
<ogra> indeed
<st3> that's completely broken
<st3> it uses a very old version of -d80211 branch
<ogra> i only use ubuntu kernels, i dont have the time for kernel compiling :)
<ogra> well, then BenC should update that :)
<st3> we received a lot of bug reports from ubuntu users for that kernel version
<st3> anyway, could you try to enable debugging options in the kernel?
<ogra> dunno, BenC do we have a debug kernel ? 
<BenC> ogra: There's only small amounts of debug enabled, like softlockup
<ogra> shouldnt we have a dbg image for tests ? 
<ogra> with everything thats possible switched on ? 
<st3> you could just recompile those modules, btw
<ogra> (and a big warning note indeed)
<BenC> ogra: Sure, if we want to double the amount of time and diskspace required to do it
<BenC> e.g. i386 is already 5 kernels.....doing 10 would be really slow
<ogra> indeed
<zul> shazbut
<ogra> well, i'm back to 2.6.20-5-generic, since -8 doesnt work at all ... -5 was completely stable, i havent seen any oopses with it
<st3> what does it mean translated to vanilla naming scheme?
<st3> so you didn't get that oops with the kernel you call -5, right?
<ogra> thats the package version ...
<ogra> right, i dot get them with the older version
<st3> which i can assume is plain 2.6.20, no git snapshot, right?
<ogra> i know BenC added some fixes during the oslo sprint so these might be the ones fixing it for me
<st3> isn't there a changelog or something like that?
<ogra> they must have appeared between -3 and -5 ....
<BenC> st3: in git, debian/changelog
<ogra> i think there is even a git tree
<st3> is there a gitweb setup somewhere?
<st3> (sorry, but i never used ubuntu, i'm not used to this)
<st3> ah ok found it
<st3> well, i can't find any related commit in git
<st3> if you want to help, please send bug reports with debugging info to bcm43xx-dev@lists.berlios.de and stating exactly what kernel are you using, thank you
<st3> bye
<BenC> st3: Our git is available from kernel.org
<st3> i saw it
<st3> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=summary isn't it?
#ubuntu-kernel 2007-02-16
<fabbione> BenC: still around?
<fabbione> or kylem..
<fabbione> BenC: FYI i did push gfs1 update to the repo on rookery as described on the wiki.. i think it's ok.. if it's not fix the wiki :P
<fabbione> have fun dude
<BenC> fabbione: Thanks
<shashi_sa>  Hi All , i have few ubuntu boxes , sometimes disk failes in our servers, at that time , if we look at log  files , we observe scsi id's , like sd08:12 . My questions , where i can find a map file which conatins mapping of scsi ids corresponds to which partition/disk ?
<BenC> shashi_sa: Generally you go by info in /proc/scsi/
<BenC> shashi_sa: There should be a mapping for the bus/target/lun in there
<shashi_sa> K
<mjg59> 08:12 looks like major/minor
<BenC> If you have more than one bus, then it can be a little ambiguous, but hopefully your scsi bus's don't contain the exact same devices in that case :)
<mjg59> shashi_sa: If you ls -l /dev/sda1, it'll be 08:01
<mjg59> Other partitions should have similar numbering
<kylem> it's complicated...
<shashi_sa> I know about this , but scsi files mention only  bus/target/lun information , but the message i am getting are like sd08:17 sd08:12
<mjg59> shashi_sa: Check the major and minor numbers on the device nodes
<shashi_sa> K
<BenC> shashi_sa: Also, dmesg on boot should show the bus/target/lun during the probe, and show the /dev/sdXX to go with it, which should help you map them
<shashi_sa> brw-rw----    1 root     disk       8,   1 Mar 19  2002 /dev/sda1
<mjg59> shashi_sa: So sda1 is 08:01
<mjg59> shashi_sa: Now you get to check which is 08:12
<kylem> 08:12 is always going to be sda12...
<mjg59> kylem: Where does sdb start?
<kylem> 08:16
<kylem> it's maj:16*n
<mjg59> Ah, right. I couldn't remember how many partitions we supported on scsi
<kylem> there's a lot of scsi majors, but the first 16 disks are all on 8.
<shashi_sa> No , if i am getting errors like sd08:17 sd08:12 , but i don't partitions only upto 6 . sdb6 is my last partition
<shashi_sa> I don't have 12 or 16 partitions in my disk , i have only 6 partitions on each and evry disk
<shashi_sa> K , are you guys saying "if it is sd08:<16 , then it is first hard disk , and if it is sd08:>=16 , then it is second disk" ?
<kylem> /proc/scsi/scsi should tell you what you need. are these sata or pata disks?
<shashi_sa> Attached devices:
<shashi_sa> Host: scsi0 Channel: 00 Id: 00 Lun: 00
<shashi_sa>   Vendor: SEAGATE  Model: ST336607LC       Rev: 6D01
<shashi_sa>   Type:   Direct-Access                    ANSI SCSI revision: 03
<shashi_sa> scsi disks 
<shashi_sa> But looks like /proc/partitions file contains all information what i am looking for
<kylem> ah. ok.
<shashi_sa> But still i am not understanding , i got 35k errors on sd08:12 , but i don't have 12 partitions on my disk , even /proc/partitions file don't contains 8 12 word , so still i am not understanding sd08:12 refres to which disk/partition ?
<zul> time for chilli
<Nafallo> time for wine (no, not software. I'm on x86_64.)
#ubuntu-kernel 2007-02-17
<zul> lovely...the xen paravirt-ops exports 67 symbols to modules
<kylem> abi ftw.
<westymatt> Hey I am a bit of a kernel newb
<westymatt> got a question though
<westymatt> What does the ubuntu kernel dev team do vs the kernel maintainers?
<westymatt> not to open a can of worms or anything
<crimsun> have you read the URL in the topic/
#ubuntu-kernel 2007-02-18
<st3> mjg59, BenC, you may want to include in the ubuntu kernel my latest patch (see linux-wireless list)
<BenC> st3: Is there a URL? I'm not on linux-wireless
<st3> it makes bcm4309 working (we have some ubuntu users which report us bugs about this)
<st3> just a moment
<st3> no i can't find an archive (it's a quite new mailing list, hosted on vger)
<st3> http://nopaste.com/p/gK/c <- here's the patch
<st3> (tabs broken, obviously)
<BenC> st3: Thanks
<st3> do you want me to forward it to you via email?
<BenC> Nah, I can extrapolate from that
<st3> ok
<st3> it's signed-off-by me (Stefano Brivio <stefano.brivio@polimi.it>) and Larry
<st3> it should be included in 2.6.21 or in -stable right now
<mjg59> st3: Thanks!
<st3> np =)
<blizz> hi there
<blizz> i saw in several forums/mailinglists that quite a bunch of people had problems with the new bcm43xx driverbase in the 2.6.20-8 kernel (which also came with herd 4)
<blizz> some people retrieved newer drivers from the openwrt page and extracted 4.x firmwares using fwcutter 006. sadly, the only thing which worked then was simple stuff like scanning for other wireless networks. association with a wep/wpa encrypted network never seemed to work
<blizz> same happened here, even a hardlock occured one time when unloading the bcm43xx module
<blizz> so, is softmac going to be back anytime soon? :P
<st3> yes, we (the bcm43xx devs) advised BenC and mjg59 that d80211 isn't suitable for production system
<st3> and they will revert back to softmac
<blizz> st3, thanks for the info :-)
<blizz> any hint when this is going to happen?
<st3> i guess when the next kernel package is released
<st3> dunno, ask them, i don't use ubuntu
<blizz> okay
<blizz> BenC || mjg59, any idea when softmac will be back? or when 2.6.20-9 will be out? ;-)
<BenC> blizz: Today
<BenC> well, it will get uploaded today
<BenC> build+publish may take 12-24 hours
<blizz> <borat>very niice</borat>, thanks for the info
<mjg59> Why has someone just filled my inbox with mails telling people that their bugs don't contain enough information when they do?
<JanC> ask someone?  :)
<lifeless> mjg59: bughelper I think
#ubuntu-kernel 2008-02-11
<kraut> moin
<Fujitsu> .win 26
<Fujitsu> Oops.
<eradicus> hi why can't make menuconfig work? curses.h file not found even if it's installed properly...what could be the prob?
<abogani> eradicus: Are you already installed libncurses5-dev ?
<eradicus> abogani: yeah, it's working now. thanks ;)
<abogani> eradicus: You are welcome.
<Kano> hi rtg , did you see 2.6.24.1 + patch against latest root exploit?
<Kano> err .2 i mean
<Kano> has the fix
<rtg> Kano: kees is working on it.
<Kano> you only need .2
<amitk> Kano: Merging 2.6.24.2 soon
<mateusz> Hi, Is ubuntu kernel patched with hdaps_protect ?
<amitk> mateusz: is that part of tp_smapi?
<mateusz> amitk: no
<amitk> mateusz: then file a bug, mark it as wishlist and describe why it should be in Ubuntu
<mateusz> amitk: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/139881
<ubotu> Launchpad bug 139881 in linux-source-2.6.22 "hdaps_protect patch to enable disk head parking on thinkpads" [Wishlist,Won't fix] 
<mateusz> the bug is already there
<Kano> rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/97655
<ubotu> Launchpad bug 97655 in linux-source-2.6.20 "dmraid45 target please" [Wishlist,Won't fix] 
<Kano> rtg: what about that patch
<amitk> mateusz: it has been rejected for Ubuntu hardy, please read Ben Collins' comment
<mateusz> ok.. then can someone provide patch for Ubuntu users that applies on ubuntu kernel?
<amitk> mateusz: you should comment on the bug or ask the original patch submitter to do that.
<mateusz> amitk: patch submitter is debian user.. and patch doesnt applay on 2.4.22 ubuntu kernel
<amitk> mateusz: unfortunately, we can't help you here. It isn't a patch that is supported by the kernel-team.
<Kano> rtg: btw. there will be an updated aufs for 2.6.24 soon
<Kano> but i think you have enough to do for now *g*
<Kano> bbl
<mateusz> amitk: well someone said that tp_smapi will be in ubuntu.. and hdapsd hdaps-utils are already in gutsy.. they're useless without hdaps_protect
<laga> mateusz: that discussion already is in the ticket
<_MMA_> Maybe I'm out of the loop but where is BenC?
<mateusz> laga: but why you're willing to put tp_smapi in ubuntu kernel and also saying me that hdaps_protect is not your team job ? 
<laga> mateusz: i'm not part of the kernel team
<mateusz> laga: hdapsd + tp_smapi + hdaps_protect is needed for this to work
<mateusz> but someone said tp_smapi will be next week in ubuntu kernel
<mateusz> it wont work either without hdaps_protect
<mateusz> amitk: ?
 * laga must have gotten something mixed up then
<smb> mateusz: I added the tp_smapi drivers to lum. With hdaps_protect you mean the hdaps driver from tp_smapi or another one?
<amitk> mateusz: smb here is looking at the integration of tp_smapi. One of the reasons to integrate it was for finer grained battery charging control.
<mateusz> smb: I think about  queue freeze support for ATA
<mateusz> smb: aka hdaps_protect
<mateusz> something diffrent than hdaps driver and tp_smapi
<mateusz> amitk: ok I understand...
<mateusz> amitk: istead of acpi ?
<smb> mateusz: I have a quick look at the bug you mentioned, to get myself updated
<amitk> right
<smb> mateusz: No, additionally
<smb> mateusz: I just looked at the hdaps_protect patch, and I must agree with ben. It touches quite a lot different places (especially ll_rw_blk.c) to simply include it. The tp_smapi and the hdaps driver there can just be added to lum without them beeing active.
<mateusz> smb: Zhenech says, that patch for 2.6.24 sometimes doesnt work.. system breaks.. but for some RC its fine...
<smb> mateusz: For patches like that it is better to have them at least in the -mm tree and then moving to mainline.
<amitk> mateusz: have you talked to patch author on why the patch is not upstrea>
<amitk> *upstream?
<mateusz> amitk: no I dont know the author
<amitk> rtg: smb: 2.6.24.2 pushed to git. I'll try out smb's new tools for test builds late tonite
<amitk> you are welcome to test build in the meanwhile. I am out for a few hours
<macd> I dont see a bug filed on LP regarding vmsplice vuln for ubuntu, only some other projects, is this being worked currently?
<macd> nvm, I see it as another tagged release.
<rtg> macd: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/190587
<ubotu> Launchpad bug 190587 in linux-source-2.6.22 "Local root exploit in kernel 2.6.17 - 2.6.24 (vmsplice)" [High,In progress] 
<macd> thx, I saw it under 190587 also ;)
<macd> the fixes under that bug in GIT both worked for me in solving root/DoS
<Kano> amitk: apm_32 missing (tested server target)
<amitk> Kano: what is apm_32?
<mjg59> The apm module got renamed apm_32 in .24 by accident
<mjg59> It was going to be changed back, but I don't know if that's happened in stable
<Kano> amitk: you never seem to compile your kernel ;)
<amitk> mjg59: it was fixed in 2.6.24.1
<amitk> Kano: we do, but not on your schedules :)
<salty-horse> will the recently discovered user->root exploit be patched soon? should I worry?
<rtg> salty-horse: it will be upload later this afternoon.
<rtg> s/upload/uploaded/
<salty-horse> If all services/ports are closed, and I don't run unknown binaries, should I be safe?
<rtg> salty-horse: Given that its an exploit that has existed since 2.6.17, you ought to be OK for the next few hours.
<salty-horse> yeah, but I thought it was "in the wild" only recently :D
<rtg> well, its certainly becoming more well known in the last few days.
<JanC> salty-horse: you can always kick untrusted local users off your machines  ;-)
<salty-horse> I'll have to rig some alarm system first :)
<Kano> rtg: ok is maybe wrong as the exploit is new. can be dangerous for multiuser systems
<Kano> rtg: btw. ath5k would work, i just dont know how to add it because of the build-deps
<kraut> is this vmsplice issue fixed in 2.6.22-14-server?
<amitk> kraut: there will be an upload later today AFAIK
<ln-> what will it break?
#ubuntu-kernel 2008-02-12
<lamont> rtg: does the -j16 make it go faster?
<kraut> amitk: thanks for the info
<kraut> did anyone of you verified http://www.linux.it/~md/software/novmsplice.tgz?
<kraut> it's an workaround against this vmsplice issue. that's a c-code where you could compile your own kernel-module.
<kraut> it should disable vmsplice
<kraut> moin
<alex_joni> kraut: I thought there's a fix in 2.6.24.2 ?
* abogani changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-7.11 | Latest news: 2.6.24 Release in Hardy | Next meeting: Feb 12, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<abogani> rtg, amitk: Hi Tim, Hi Amit! Please don't forget to enable ati closed driver (fglrx) in -rt l-r-m. Thanks.
<tjaalton> abogani: does it build?
<amitk> abogani: why was it disabled?
<abogani> tjaalton: When i submit the patch it compile fine.
<amitk> abogani: also the meeting is at 1700 UTC, wiki has been corrected...
<tjaalton> abogani: ok, cool
<abogani> amitk: Thank you! I have corrected the topic in this room.
<amitk> great
<abogani> tjaalton: Let me re-check build of l-r-m...
<abogani> amitk: Could i add a topic for today meeting (as Open Discussion)?
<amitk> abogani: go ahead
<abogani> amitk: Should i add it to wiki page?
<amitk> abogani: yes
<abogani> amitk: Ok, Thanks.
<abogani> Done
<abogani> tjaalton: Compilation test in progress...
<tjaalton> there's also a request to enable nvidia/fglrx for -server
<abogani> for server?
<abogani> server + GUI? shudder...
<tjaalton> the server kernel is useful in some situations
<tjaalton> in a workstation
<tjaalton> bug 153011
<ubotu> Launchpad bug 153011 in linux-restricted-modules-2.6.24 "no nvidia-glx or fglrx for server kernels" [Medium,Triaged] https://launchpad.net/bugs/153011
<abogani> tjaalton: Compilation test successfully. Patch still good.
<abogani> amitk: Could you enable in debian/rules the fglrx driver for l-r-m, please?
<amitk> abogani: was your patch already integrated?
<abogani> Yes!
<amitk> ok, I'll see that it is done
<abogani> You can find it at ati/patches/1-rt-compat-symbols.diff in source package.
<abogani> Ok, Thanks!
<jdahlin_> It seems that hardy kernels takes a lot longer to startup than gutsy ones
<jdahlin_> the part 'looking for new hardware', took 1-2 seconds on gutsy but on hardy it's easily 20 seconds
<amitk> jdahlin_: is there a bug about this?
<jdahlin_> amitk, I tried to search on hardy/linux without finding anything
<jdahlin_> what's the right product/source package to search on?
<amitk> product=ubuntu, package=linux
<amitk> jdahlin_: file a bug please
<amitk> tjaalton: have you verified that fglrx and nvidia compiles for server flavour?
<tjaalton> amitk: no I haven't
<amitk> tjaalton: rtg says it wouldn't compile due to some dependencies. He'll take a stab at it today
<tjaalton> amitk: oh cool
<Kano> hi rtg , are you interested in a webcam driver patch for lum?
<rtg> Kano: email it to the kernel team mailling list.
<alejalej> hello kernel people
<alejalej> am running Hardy
<alejalej> very happy with the kernel change
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic/source/lum-stk11xx.patch
<alejalej> no need to noapic no more, etc
<Kano> if you like to look
<alejalej> but I have some problems with suspend/hibernate... and specially resume
<alejalej> do I need to file a bug first=
<alejalej> or could you guys point me to some interesting alternative....
<alejalej> did someone flood me out?
<Kano> rtg: for amd64: error in debian control line 78: duplicate Conflicts
<Kano> when compiling generic
<rtg> Kano: hmm, I saw that on my PPA build this morning, but haven't been able to get back to it.
<Kano> for the linux-libc-dev 
<rtg> I wonder why that just started showing up.
<Kano> well i tried to compile it on amd64 siiiiiiiiiiiiiiiiid
<rtg> looks like dpkg was upgraded and caught a long standing syntax error.
<amitk> rtg: did unifying 75 and 78 fix it?
<rtg> amitk: don't know yet. it takes a bit.
<Kano> ubuntu/media/stk11xx/stk11xx.ko
<Kano> at least my patches compiles the module ;)
<amitk> Kano: you have to send an email to kernel-team@lists.ubuntu.com explaining _what_ the patch does.
<Kano> it adds just this
<Kano> svn co http://syntekdriver.svn.sourceforge.net/svnroot/syntekdriver/trunk/driver stk11xx
<rtg> Kano: the purpose of the email list is 1) wider distribution for comments, and 2) time elasticity. Not everyone has the time to camp on IRC to find out what is going on.
<Kano> well you are online and you have acess to git ;)
<Kano> it is a very easy module, em8300 i still have to do...
<Kano> or you if you like ;)
<amitk> BenC just postponed the IRC meeting by 15mins...
<rtg> ogasawara: when you regen your hardy-buglist page, could you put a date in the title?
<ogasawara> rtg: sure, np
<rtg> 'tanks
<king_> ogasawara: how often is it updated? Is it a manual update?
<ogasawara> king_:  updated every hour via cron job on rookery
<BenC> I see everyone else is alive
<BenC> smb: ping
<ogasawara> king_: and the list is maintained in a bzr tree which gets pulled on rookery
<smb> Ben: yup
<BenC> good deal
<BenC> Ok, The weekly Kernel Team meeting is now in session...agenda, as usual, is at: https://wiki.ubuntu.com/KernelTeam/Meeting
<BenC> Let's run down the team, see what's going on
<BenC> amitk: You're up first, how's things?
<amitk> doing ok
<amitk> A bunch of mobile updates for graphics drivers, dma, etc. coming up next week
<BenC> amitk: going into hardy kernel?
<amitk> I won't have a lot of time to do bug fixing this week
<amitk> BenC: yes
<BenC> Ok
<BenC> amitk: This is all for lpia, I assume
<amitk> yes. Everything going in is restricted to LPIA
<amitk> it won't affect other flavours
<BenC> good, so no need to worry much about code freezes for the rest of the dist
<maks_> BenC: can i please remind you on an initramfs-tools sync
<BenC> maks_: best thing is to email me, if you could please
<BenC> my inbox acts as a todo list :)
<rtg> also copy kernel-team mailing list.
<maks_> which email BenC ?
<BenC> bcollins@ubuntu.com, kernel-team@lists.ubuntu.com
<maks_> cool
<BenC> amitk: Thanks
<BenC> rtg: How's the kernel looking right now for next milestone?
<rtg> amitk is packaging the -8 ABI, which is based on 2.6.24.2
<rtg> there are a couple pof critical crashes that I need to look at as soon as its uploaded.
<rtg> would also like to review some of the wireless issues.
<rtg> otherwise, I think its looking OK
<amitk> -8 will include the fixes for the vmsplice CVEs
<rtg> yep
<BenC> This will be the Alpha 5 kernel, right?
<rtg> oh, and there are some possible IDE issues.
<BenC> what happened there?
<rtg> yes - it should be the A5 kernel.
<rtg> Ng complained that his laptop wnet fropm sda back to hda.
<BenC> you mean issues like regressions caused by the -8 kernel, or things that were already there?
<rtg> someting in the -7 kernel.
<BenC> Did someone dork around with the via IDE/PATA driver?
<rtg> there is one commit that enables more IDE devices. perhaps that one?
<BenC> yeah, sounds like it
<rtg> I'll get you to reveiew it with me later.
<BenC> we don't want to enable IDE drivers where we already have a libata-pata one
<rtg> you are the expert there.
<amitk> BenC: can initramfs enforce an order in which modules are tried?
<BenC> Need to watch out when we mess with that sort of config change...could really screw up someone's system
<amitk> ata_piix before ide_disk, for example?
<BenC> amitk: only by blacklisting
<amitk> BenC: unfortunate
 * BenC pimps the udev device/driver binding paradigm, and moves on
<BenC> rtg: Ok, thanks
<BenC> smb: how's things coming along for you?
<smb> So far, I work on several bugs. Most of them currently require more input or looking into them
<smb> Did the tp_smapi addittion to lum last week
<BenC> smb: Since you are a few weeks into things now, how are you finding the work flow and documentation?
<smb> Generally, there are a few bugs in the crried forward section that have fixes either only in the -mm tree or not ready yet. Is it ok to leave them triaged there or can we park them
<smb> Well, as most of us, I find Leann's buglist most usefult. 
<BenC> smb: if there's no chance of us fixing them, then marking them WontFix is proper
<BenC> smb: it will get it out of limbo so we can move on to more important things
<ogasawara> smb:  if you want to keep an eye on them, feel free to reassign to canonical-qa and I'll track them
<rtg> smb: if there isn't an upstream fix by now, then its unlikely to happen in timew.
<smb> ogasawara: Yes, I guess we did that for one and I keep an eye on the upstream report
<BenC> The only time that isn't the case is where it's a critical bug/regression that we should put some effort into
<rtg> like an oops.
<BenC> well, and oops that isn't in something like netatalk :)
<rtg> right. an oops in something interesting.
<BenC> smb: Alright, thanks
<BenC> king_: And fresh from your first week with us, how are things coming along?
<king_> Ok thanks - I believe I'm up to speed .. with help I've got some code now into the repository!
<king_> I've been looking at several bugs...
<king_> Some look a bit more open ended than others.
<king_> I've put a patch in for the macbook 3.1 track pad
<king_> And I've been trying to understand why  the /proc/acpi/alarm is missing for the x86_64 
<BenC> That reminds me, we should probably revert back to sending patches to kernel-team for double-ack before commit like we used to
<king_> I need to know how to this then.
<BenC> This predates both you and smb, so I'll give it a quick once over
<king_> Ok.
<maks_> baah kernel-team is a subscriber list
<smb> ok
<king_> ok.
<BenC> Any patches that we commit (this pertains mostly to the kernel), would be sent to kernel-team@lists.ubuntu.com
<BenC> before they are committed
<BenC> at least two people on the team have to ACK the patch before it can be committed...assuming a kernel team person submits the patch, that means one ACK from a team member
<smb> or pushed. we could commit locally to get a git-format-patch version
<king_> This would be a good way of catching any dubious commits by newbies :-)
<BenC> yeah, it's all about checks and balances :)
<rtg> except its not a democracy.
 * BenC puts on the iron fist
<BenC> seriously, I'm more inclined to just put in my 2 cents where needed and let you guys make the final decision
<king_> I'd appreciate it.. if it does not slow down workflow..
<BenC> it seemed to work well before, but we stopped doing it since we only had 3 of us on the team, which did slow things down
<BenC> with 5 of us, the ACK turn around should be quick, especially if you ping everyone when it's important
<rtg> I try to stay on top of kernel-team submissions.
<BenC> king_: ok, thanks
<BenC> Moving on to QA bug list
<BenC> I haven't had a chance to look at it today...is there anything serious going on there?
<rtg> Bug #189224 is interesting
<ubotu> Launchpad bug 189224 in linux "sunrpc causes kernel oopses on 2.6.24-5-generic" [High,Triaged] https://launchpad.net/bugs/189224
<BenC> The carried forward section is still growing
<smb> Which might be  cpuidle
<ogasawara> also mathiaz reported Bug #185303
<ubotu> Launchpad bug 185303 in linux "Kernel Oops - unable to handle kernel paging request - Hardy server i386 alpha3/alpha4 install on HP Proliant ML350 fails" [High,Triaged] https://launchpad.net/bugs/185303
<BenC> And there's still a lot unassigned bugs
<Kano> rtg: btw. sent a mail...
<smb> For example https://bugs.launchpad.net/ubuntu/+bug/152187 is something  that is assigned to qa and the fix wont happen too soon
<ubotu> Launchpad bug 152187 in linux "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Unknown,In progress] 
<rtg> I should have a bit more time to work on bugs. The CVE flurry seems to have settled.
<ogasawara> smb: I can move the qa assigned bugs off the list and track them separately
<BenC> 189224 looks pretty damn serious
<rtg> Benyup
<smb> ogasawara: I think that would be good. Since this issue has to wait for the upstream fix
<rtg> BenC: yup, even.
<BenC> rtg: 185303 appears very similar to a vendor issue we had
<rtg> its got some interesting wrinkles. amd64 works, i386 doesn't
<BenC> bios related
<BenC> although that one was fixed by a bios update...so maybe we need to track the actual problem
<BenC> it's a regression either way
<rtg> I think Mathiaz has checked for BIOS updates. I'll confirm.
<rtg> He showed me this one at sprint.
<BenC> Let's make a point to get this carried over list knocked out some how
<BenC> those two bugs mentioned should get some priority (especially the cpuidle one)
<smb> Ok, I try to dig further there
<rtg> smb: get him a 2.6.24.2 based kernel.
<BenC> the pci bios seems like it should be easy to debug
<rtg> except for the fact that it chunders inside the BIOS.
<smb> rtg: right. I read something related that vanished later
<BenC> Alright...
<BenC> abogani: ping
<abogani> BenC: pong
<abogani> Ok the thing is off-topic in this moment but I prefer clarify this point in time for next release.
<abogani> Is it possibility to ship -rt kernel flavour in main in hardy+1?
<abogani> There isn't CVE or Secunia advisory. It have the same local exploit of the -generic one.
<abogani> Obviously i don't want merge -rt code into main git tree but is sufficient maintain it to a separate patchset (as usual) and release it through main repos.
<abogani> Noteworthy is that 2.6.25 will merge other fundamental pieces from -rt patchset via Molnar's git tree (http://kerneltrap.org/node/15345).
<abogani> Thus why we can't raise -rt to main? what i can do to achieve this goal (for hardy+1)?
<BenC> abogani: this is something we'll need to discuss in detail at UDS
<BenC> abogani: are you on the sponsored list?
<abogani> Mhhh sponsored list? I don't know nothing about it... Thus I suppose no. 
<BenC> abogani: email me some notes and I'll see if we can work some way for you to be at either FOSSCamp or UDS to plead your case in person :)
<abogani> BenC: Ok. Thanks a lot.
<BenC> at the very least, creating a blueprint on launchpad targetted for hardy+1 is a great start
<abogani> specifically for main inclusion?
<BenC> yeah
<abogani> Ok. 
<BenC> Ok, that ends the actual agenda
<BenC> Any open items for discussion?
<BenC> I'll take that as a no, and call the meeting to a close
<BenC> Thanks every one!
<tjaalton> well, there are some DRM changes in 2.6.25-rc1 that would be nice to have, like ba8bbcf6ff4650712f64c0ef61139c73898e2165
<tjaalton> it might fix bug 189260
<ubotu> Launchpad bug 189260 in xserver-xorg-video-intel "Backlight doesn't turn on after resume" [Medium,Confirmed] https://launchpad.net/bugs/189260
<tjaalton> at least upstream thinks so :)
<tjaalton> amitk: if you are doing l-r-m as well, let me know before you upload.. I'll toss you with a diff to fix bug 190347
<ubotu> Launchpad bug 190347 in linux-restricted-modules-2.6.24 "Bad entry in menu" [Low,In progress] https://launchpad.net/bugs/190347
<rtg> tjaalton: email it to kernel-team. I'll probably be doing the upload later today.
<tjaalton> rtg: oh today already.. ok
<rtg> tjaalton: actually, lrm probably won't get uploaded until tomorrow given the ABI bump.
<tjaalton> rtg: cool, more time for me ;)
<tseliot> tjaalton: maybe your diff can include my patch as well ;)
<tseliot> shameless plug
<tseliot> :-P
<tjaalton> tseliot: hehe
<tjaalton> actually, I'm having second thoughts about including the desktop file for nvidia-settings, since it's not a tool for a casual user, and could do more damage than good
<tjaalton> or at least don't show it by default
<Kano> hi, ist ubuntu.com down?
<Kano> hmm now it seems to work again
<Kano> rtg: did you see the mail in the ml?
<rtg> yes
<Kano> and where is your commit
<rtg> busy
<Kano> when there is a more complicated makefile with serveal flags, how to convert these?
<Kano> rtg: do you test the kernel on amd64?
<Kano> rtg: do you know that standard debian kernels have FB_VESA=y and FRAMEBUFFER_CONSOLE=y?
<mjg59> Kano: That doesn't make it a sensible thing to do
<Kano> sure without i dont get a framebuffer on amd64
<Kano> never with a ubuntu live cd
<mjg59> Sure you do
<mjg59> But you'll never get one by default
<Kano> dont know whats differnet with i386, but that problem is mainly amd64 there
<Kano> also usplash only works with 32 bit
<mjg59> usplash works fine with most 64 bit hardware
<Kano> well my destiny is to have the none working examples
<mjg59> I'm working on it, but it's not a kernel issue
<Kano> do you own a system where it does not work
<mjg59> No, but I know what needs to be done before it can be fixed
<Kano> so what
<mjg59> ?
<Kano> tell me what you think the problem is
<mjg59> The x86 emulation is bugged in some way
<Kano> in usplash?
<mjg59> Yes
<mjg59> Well, in libx86
<Kano> interesting that it works on some systems...
<mjg59> Depends on the video BIOS
<Kano> usually static vesafb is working everywhere...
<mjg59> We can't use vesafb by default
<Kano> vga=0 would disable it
<mjg59> The default would have to be disabled
<Kano> at least enabling is then easy
<mjg59> It will already be handled properly
<Kano> i really doubt that
<tjaalton> mjg59: the buglist for xserver-xorg-video-nv has many potential testers for you ;)
<mjg59> Kano: Check /usr/share/initramfs-tools/scripts/init-top/framebuffer
<mjg59> tjaalton: Why on earth are they filed against the X driver?
<Kano> mjg59: why dont you make fbcon static, it is modprobed anyway?
<mjg59> Kano: So it's not loaded if the user doesn't ask for it
<Kano> also the splash check is suboptimal
<mjg59> ?
<tjaalton> mjg59: lack of better knowledge perhaps
<Kano> when you use splashy you have a splash option,but you need vesafb
<Kano>         splash*)
<Kano>                 FB="vga16fb";
<mjg59> Which version are you looking at?
<mjg59> That's not in the current code
<Kano> etch
<mjg59> Well, blame Debian
<Kano> well will fetch u initramfs
<Kano> the modprobe does not work
<Kano> on my system
<Kano> definitely not
<mjg59> Working out why would be helpful
<mjg59> Since it works here
<Kano> well i can not send you my gfx card
<mjg59> If the modprobe is failing, the graphics card is irrelevant
<Kano> well sid + ubuntu are similar in that file btw
 * mjg59 shrugs
<Kano> just that u does not check for while read fbno desc; do if [ $(($fbno < 32)) ]; then before mknod /dev/fb${fbno} c 29 ${fbno}
<Kano> and u uses -Qb
<Kano> option to modprobe
<Kano> interestingly i can use onboard vga too and get the same problem...
<Kano> http://www.gigabyte.co.nz/Products/Motherboard/Products_Overview.aspx?ProductID=2535
<Kano> this board
<Kano> mjg59: the thing is: after boot vesafb is never loaded, only fbcon
#ubuntu-kernel 2008-02-13
<Kano> mjg59: does the modprobe in initramfs look after blacklists because vesafb is blacklisted in module-init-tools
<Kano> and it writes that is not loaded
<thotypous> hi
<thotypous> hi caetano Tonho maskd :)
<caetano> hlw
<Tonho> thotypous: you dont will do this sugestion
<thotypous> hey guys, I would like to ask if ubuntu would support a change from ALSA to OSS4 from 4tech-tech in it's official kernel
<Tonho> is stupid :~ likes theses users
<thotypous> Tonho, hey, please more respect
<Tonho> why, alioth is here o.O
<mjg59> thotypous: No
<caetano> mjg59, why?
<thotypous> OSS is far more easy to develop than ALSA, and is portable (every UNIX uses OSS)
<mjg59> Because it would be an unnecessary divergence away from the direction everyone else is going
<thotypous> we thin that if ubuntu changed to OSS4, everyone else would rethink using ALSA
<thotypous> we think*
<mjg59> thotypous: I really doubt that
<rtg> OSS is on the deprecation track.
<mjg59> rtg: The existing in-kernel code, yes
<thotypous> but not OSS4
<mjg59> OSS has been maintained outside the kernel and is being picked up by Open Solaris
<mjg59> (Which I don't think is an especially compelling argument, given relative market share)
<caetano> and the new OSS suports a good alsa emulation
<caetano> the oss emulation from alsa is very poor
<thotypous> the guys at dracolinux recently adopted OSS4 besides ALSA, so the slackware users should support it
<thotypous> ubuntu support would result easily in debian support
<mjg59> No
<thotypous> slackware support -> arch support
<mjg59> Debian make their own decisions
<thotypous> arch support -> gentoo support
<thotypous> and going on
<soren> I'm wondering what the problem you're trying to solve is?
<mjg59> Once OSS4 is upstream, then there's a chance Ubuntu will adopt it
<mjg59> But while it's out of tree, no. Sorry.
<Kano> you can easyly install the deb from oss4
<Kano> no problem at all, alsa is blacklisted then
<Tonho> thotypous: o.O wtf you want this? any special problem?
<caetano> is very hard to work with sound in unix actually
<thotypous> yes
<caetano> you've to program to unix, to linux and to windows
<caetano> all unixes uses oss, but linux
<thotypous> yes, that's the point
<caetano> the new oss4 is, I guess, very good, and full stuff
<mjg59> All Unixes other than Linux are irrelevant as far as the desktop is concerned
<mjg59> Other than MacOS. Which doesn't use OSS.
<Pimentel-ES> as far as the desktop is concerned i believe linux IS irrelevant...
<thotypous> but portability, simplicity and API homogeneity is always important 
<mjg59> thotypous: And having us diverging from the rest of the Linux market would do nothing to improve API homogeneity. You're kidding yourself if you think Red Hat or Suse will ship OSS without it being in the upstream kernel.
<thotypous> I think Linus would be influenced by a Ubuntu decision
<mjg59> No. Really, no.
<thotypous> what about it if Mark Shuttleworth supported this decision?
<mjg59> Mark is one member of the technical board
<mjg59> (I'm another)
<mjg59> Right now, I wouldn't support this decision
<thotypous> so you can help us :D
<thotypous> in the technical board
<mjg59> So you'd have to convince the other two
<lifeless> and convince mjg59 too; he doesn't sound convinced.
<thotypous> ah, but now we know who to convince :D
<lifeless> and FWIW I haven't seen anything convincing in this discussion
<thotypous> mjg59, what do you think it needs to OSS for becoming mainstream again?
<mjg59> For a start, it needs alsa emulation that works - http://www.4front-tech.com/forum/viewtopic.php?t=2434 suggests that that really isn't the case at the moment
<mjg59> Then you need to convince Linus to accept it back into the kernel, and to do that you'll have to demonstrate that it's significantly better than alsa in ways that aren't easy to fix
<thotypous> hmmm thanks for the hints :)
<JanC> <Pimentel-ES> as far as the desktop is concerned i believe linux IS irrelevant...
<JanC> actually, linux (total) officially has 1.5% market share on the Belgian desktop market  ;)
<JanC> (or had, almost a year ago)
<Pimentel-ES> :)
<JanC> and Mac OS X dis have 1.8% of the market
<JanC> s/dis/did/
<JanC> so linux is/was very close to the most-used unix-like OS...
<JanC> and at that time, Vista did have 3.3% market share, and Ubuntu did have 0.3% market share...
<JanC> this report was compiled from research conducted in March & April 2007 (so almost 1 year ago)
<Kano> rtg: how about adding my patch to lum?
<kraut> moin
<maks_> BenC: did you get my initramfs-tools mail?
<Lure> can some kernel developer review (and possibly approve) proposed blacklisting of garmin_gps, see bug 114565
<ubotu> Launchpad bug 114565 in module-init-tools "native Garmin-USB no longer working" [Medium,Triaged] https://launchpad.net/bugs/114565
<Kano> hi rtg 
<Kano> rtg: when do you want to commit my patch?
<tjaalton> amitk, rtg: http://users.tkk.fi/~tjaalton/dpkg/lrm.diff
<tjaalton> obviously the version number is wrong
<rtg> You gotta love this: "Note : The syntek USB 2.0 video camera driver for DC-1125 ans STK-1135 is currently being developed on Linux. This driver can do damages. Use this driver only if you know what you are doing."
<rtg> what damages could a web cam do other then oops ?
<Kano> hi rtg 
<rtg> Kano: I'm working on it.
<Kano> well what is wrong with the patch?
<rtg> Kano: nothing as far as I know.
<Kano> did you look at dmraid45 too?
<rtg> not yet
<rtg> Kano: in fact, it slipped my mind because it didn't come through the kernel-team mailing list for general comment.
<Kano> when i have got a makefile that creates 3 modules
<Kano> MODULES := adv717x.o bt865.o em8300.o
<Kano> do i just the same and write obj-m +=?
<rtg> Kano: yep. But if you plan to submit these for inclusion in lum, I want one patch per driver.
<Kano> thats really a bad idea...
<Kano> it is one driver with 3 submodules
<rtg> Kano: then that appears to satisfy my criteria. 
<Kano> well i just would use internal header instead of global
<Kano> as patch
<Kano> but it needs firmware the em8300 driver
<mjg59> Do we have permission to distribute that firmware?
<mjg59> Hm. It seems to be in the em8300 package.
<Kano> dont know, there are 2 ways, internal or external
<mjg59> We go with external
<mjg59> The firmware loader is there for a reason
<Kano> or just as external package the driver, it is a bit uncommon
<Kano> 0.16.4 would work
<Kano> but it is needed for vdr
<Kano> when you want to use it as external device
<Kano> thats nice because then you can use vdr over tv+remote control and do something else with the pc
<Kano> the simple fix would be: fetch new em8300 package from sid (there is 0.16.4)
<Kano> interestingly this is one module for inclusion in linux-modules-contrib-2.6...
<zul> do we have like a kernel of the day thing yet?
<rtg> zul: it almost works, but I haven't turn it on for regular builds. I still need to mess with lum.
<zul> im just looking for -8 so I can update the drbd stuff
<rtg> zul: -8 has some FTBS issues cause by dpkg that I'm working on.
<rtg> x86 and x86_64 built OK.
<zul> just need x86 :)
<Kano> zul: this is easy.just run 2 scripts ;)
<rtg> uh, I better check that for sure. 
<rtg> zul: yes, x86* _did_ build. No lum/lrm/lbm etc yet.
<zul> just need the headers so I can do a test build locally shouldnt I?
<Kano> lum does build too
<rtg> zul: that ought to work.
<zul> rtg: thanks..
<rtg> tjaalton: I'll pick up the lrm changes as soon as I figure out the kernel FTBS on sparc/ia64/hppa.
<tjaalton> rtg: ok, thanks!
<tjaalton> nvidia-settings mess should be sorted now, finally..
<tjaalton> how do I check the module dependencies of a module?
<rtg> tjaalton: you mean in modules.dep?
<tjaalton> rtg: well, nvidia.ko, but I guess 'depmod nvidia.ko' or similar should work?
<tjaalton> just to check if it depends on some other module, but.. wouldn't that violate GPL?
<rtg> tjaalton: as long as its in the /lib/moduels/`uname -r` directory, it'll get sorted correctly.
<tjaalton> I'm aware of that ;)
<tjaalton> this is for envyNG
<tjaalton> the patch uses insmod, and that fails unless all the dependancies are already loaded
<tjaalton> ah right, I'll grep the modules.dep :)
<rtg> tjaalton: oh, you didn't say that. Why wouldn't the patch use modprobe?
<tjaalton> because it uses a special path
<tjaalton> nvidia_legacy.ko doesn't depend on any other modules, but nvidia.ko and _new.ko depend on i2c-core.ko
<_MMA_> Hi guys. Alessio brought to my attention the desire to pull -rt into main. I have no objection. I just wonder if there's any foreseeable benefit?
<rtg> tjaalton: hmm, there doesn't appear to be a way to specify a modprobe search order unless you use a modprobe.conf.
<tjaalton> rtg: right.. but it seems that loading i2c-core before the driver is enough
<tjaalton> so it's not a huge problem
<rtg> _MMA_: uh, I think that was deferred to hardy+1 pending mainline inclusion of the -rt patchset.
<_MMA_> Oh sure, I just wonder to what end? What's the point? :)
<rtg> tjaalton: so you just hardwire that in the patch? I mean 'modprobe i2c-core' just before the insmod.
<tjaalton> tseliot: hey, we were discussing your patch. It seems that insmod would fail unless i2c-core is loaded before loading the driver
<tjaalton> rtg: right
<rtg> _MMA_: if the -rt patchset were upstream, then its a lot less work for maintainers. 
<_MMA_> No no. "Main" as in our "main" repo.
<_MMA_> Why does it matter if its in Main or Universe?
<rtg> _MMA_: well, it doesn't matter to me. I'm a kernel guy :)
<tseliot> tjaalton: I talked to mdomsch about this
<tseliot> and my patch shouldn't be necessary since the module is installed in /lib/modules/2.6.24-5-generic/updates/dkms
<tseliot> which should have higher priority
<tjaalton> tseliot: oh
<tseliot> tjaalton: I'm trying to see if the problem is the fact that we use nvidia_new, legacy, etc.
<tseliot> otherwise it's module-init's fault
<_MMA_> rtg: Sure. I'm just chattin' here. Being in Universe now doesn't really lower its barrier to contribution and moving to Main wouldn't change that. We can build disks from Universe for Ubuntu Studio now. Also just because its in Main doesn't mean its Canonical supported.  Just wondering the point of the move is all.
<tjaalton> ok, so we'll put the patch on hold for now
<tseliot> tjaalton: I'll let you know if I manage to solve the problem myself
<tjaalton> tseliot: ok
<tseliot> see you later
<rtg> _MMA_: for that you'll have to consult someone politically wiser then myself in the ways of Debian.
<_MMA_> :P
 * _MMA_ shoulda went to the meeting yesterday.
<rtg> tjaalton: so, you gonna rip out the envy-dkms part of that patch?
<rtg> of the lrm patch. I mean.
<tjaalton> rtg: sure, a sec
<rtg> tjaalton: no rush. I'm still working on kernel FTBS issues.
<tjaalton> rtg: ok, done
<tjaalton> same url
<rtg> tjaalton: please email it to kernel-team also, so I don't lose it.
<tjaalton> I sent an email there already, but I'm not on the list so it's queued
<tjaalton> that was for the earlier patch, but the url is there
<rtg> tjaalton: I know the list admin :)
<tjaalton> hehe
<tjaalton> so it seems to be there now
<tseliot> tjaalton: I've just sent the new (ridiculously small patch)
<tseliot> together with a ridiculously long email :-P
<rtg> mjg59: what do you know about asus-laptop v.s. asus_acpi ? https://bugs.edge.launchpad.net/ubuntu/+bug/184721 contends that asus_acpi  should be blacklisted, though I see no signs that the kernel is deprecating this driver.
<ubotu> Launchpad bug 184721 in module-init-tools "linux-source-2.6.22-2.6.22 ships with deprecated asus_acpi.ko" [Medium,Triaged] 
<mjg59> I'm under the impression that asus_laptop is the way forward
<rtg> Ought I add it to lum then?
<mjg59> Probably, yeah
<mjg59> Though isn't it in-kernel already?
<rtg> ok
<mjg59> That might just be .25
<rtg> no, only asus_acpi as far as I can tell. Would it be someplace other then acpi?
<mjg59> Yes
<mjg59> misc
<rtg> ah, indeed.
<jayc> amitk: I'm trying to get the linux-2.6.24-lpia kernel source package and I could not find it. where (deb-src URL) can I find it?
<rtg> jayc: which ABI version do you want?
<rtg> you can also pull it from git.
<jayc> rtg: I'm looking for ABI -7
<jayc> rtg: I would like to get the orig.tgz file so that I could upload the source to ubuntu-mobile
<rtg> jayc: one sec...
<rtg> jayc: 'dget http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.24-7.12.dsc'
<jayc> rtg:So I can get the orig.tgz from there?
<rtg> dget will pull all of the files required to build. Until we have an official release candidate, I have not generated an orig.tar.gz.
<rtg> the diffs are just too large, and therefore largely useless.
<jayc> rtg:So then I will upload the entire hardy-ume kernel source to ubuntu-mobile PPA then. Thanks
<rtg> jayc: yep. just do a 'dput *.changes' and it will figure it out.
<jayc> rtg: got it :-)
<rtg> jayc: there is a script in Hardy kernel that shows how to prepare a PPA upload: debian/scripts/misc/ppa-cron-job
<rtg> its part of the daily kernel build infrastructure.
<rtg> (which I have yet to turn on)
<jayc> rtg:how can I use it, I don't upload to ppa regularly? you suggets me to just take a look at the script and see if it helps me?
<rtg> jayc: yeah, its informational only.
<jayc> ok
<amitk> heya jayc, I see rtg has already helped you out
<jayc> amitk: yes
<rtg> amitk: slacker, ya been napping ?
<amitk> rtg: it's called "keeping the significant-other engaged'
<rtg> amitk: ah, she who must be obeyed :)
<Kano> btw. did you see the new ati 8-02 driver
<Kano> has aiglx support for xserver 1.4
<rtg> Kano: that is tjaalton's domain
<Kano> i dont use lrm but you should fix compiz detection
<Kano> and let fglrx work
<Kano> after adding it..
<tjaalton> rtg: you can include it :)
<tjaalton> changing the tarball is painful, btw
<tjaalton> since there are changes outside the debian-directory
<rtg> tjaalton: oh, feel free to do it :) I'm kind of buried.
<tjaalton> hehe
<tjaalton> rtg: ok, I'll see what I can do
<rtg> with feature freeze approaching, I'm trying to get some last minute stuff done.
<tjaalton> Kano: fglrx is already whitelisted
<Kano> tjaalton: in the standard package or via fglrx override?
<Kano> i mean when you add it to lrm, the 8-02
<Kano> for hardy
<tjaalton> Kano: the compiz wrapper
<tjaalton> WHITELIST="nvidia intel ati radeon i810 fglrx"
<Kano> ok
<tjaalton> but it doesn't seem to work that well, at least not for everyone
<tjaalton> so hopefully this version is better in that regard
<Kano> well best add Option          "XAANoOffscreenPixmaps" 
<mjg59> Kano: Nghno.
<Kano> do what you like, i dont need lrm ;)
<mjg59> If you want to disable a large chunk of 2D acceleration, sure
<mjg59> But it's not terribly sensible in general
<mjg59> We've got code in the X server that effectively does that dynamically
<Kano> but thats even faster when you disable it
<mjg59> At the cost of increasing CPU usage, perhaps
<mjg59> But that's very machine dependent
<tjaalton> right, that option is not needed
<tjaalton> ati webpage still shows the old driver
<tjaalton> ah, updated now
<blueyed> rtg: Thanks for looking into bug 188226, I've commented there - after/while reading some kernel documentation.
<ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [Wishlist,In progress] https://launchpad.net/bugs/188226
<rtg> blueyed: I'm waiting for some feed back from the server team as well. I think its probably too late to implement any userland support for this. Feature freeze is tomorrow.
<Kano> rtg: did you see errors like http://www.linuxforums.org/forum/peripherals-hardware/53991-harddrive-errors.html
<Kano> for your current kernel?
<Kano> this happens for some users
<Kano> also dma is off for my dvd drive (nforce3 chipset)
<Kano> this is not the case when you use pata_nv instead
<blueyed> rtg: yeah, too bad.. would be quite simple though and only changing the config would be also better.
<blueyed> I've tried to get feedback on this for quite some time (since 2.6.24 entered hardy)...
<tjaalton> rtg: when were you planning to do the linux-meta bump? I could update lrm in ~8h
<lamont> scsi_mod: value -6917529019036584304 out of IMM22 range
<lamont> FATAL: Error inserting scsi_mod (/lib/modules/2.6.15-51-mckinley/kernel/drivers/scsi/scsi_mod.ko): Invalid module format
 * lamont grumbles at he dapper kernel;
#ubuntu-kernel 2008-02-14
<blueyed> Is there a chance to include virtualbox-ose-modules in linux-ubuntu-modules or something similar, so it gets rebuild for new kernels more automatically?
<amitk> blueyed: unlikely, tomorrow is feature freeze for hardy. But there are exceptions for legitimate cases... So write email to kernel-team@lists.ubuntu.com explaining what needs to be done and why. Providing a patch that already works with Ubuntu gets bonus points.
<blueyed> amitk: what should the patch target? linux-ubuntu-modules? Please note, that virtualbox-ose-modules is already around, but needs to be uploaded for new kernels always separately.
<Hammer89> anyone have any idea what's causing this error? http://paste.ubuntu-nl.org/55947/
<Hammer89> (I was referred from the #ubuntu channel to ask on here)
<Hammer89> only modifications I've made were some recent updates from synaptic... which included kernel updates
<tjaalton> rtg: do you have any changes to lrm other than the ones by me and tseliot?
<tjaalton> rtg: ok, I'll prepare the lrm but won't upload until ack'ed
<kraut> moin
<Kano> hi rtg , do you want to add dmraid45?
<Kano> #97655
<abogani> Bug #97655
<ubotu> Launchpad bug 97655 in linux-source-2.6.20 "dmraid45 target please" [Wishlist,Won't fix] https://launchpad.net/bugs/97655
<kraut> this vmsplice issue is fixed in the vanilla kerne 2.6.24-2, not in -1, correct?
<tjaalton> right
<kraut> tjaalton: thanks
<rtg> tjaalton: I don't have anything for lrm, though I might take a stab at producing a -server version later on. (next week)
<tjaalton> rtg: I'm trying to do that now, if it's ok
<rtg> tjaalton: that works for me :)
<rtg> its not like I lack for things to do.
<tjaalton> rtg: hehe, ok. it should be easy
<tjaalton> whee, lrm-server built
<tjaalton> fritz and ltmodem have been disabled for some time now, but ltmodem seems to build fine
<rtg> tjaalton: I'll be uploading a -8 kernel this morning that fixes the compile issues with sparc/hppa/ia64.
<tjaalton> rtg: you'd have the lrm ready by then?
<tjaalton> +like
<rtg> tjaalton: I assumed you were doing a -8 release for lrm, right?
<natvie> hi
<tjaalton> rtg: sure, but how much do I have time left?-)
<natvie> i have this weird issue with ram.. i have an old pc with me, its a pentium550mhz intel i810 mothermotherboard and it had 128 mb sdram. so recently i thought of upgrading it to 512mb ram. so i bought this 256mb X 2 sticks as my motherboard have only two slots and support upto 512 mb. its all 133 mhz. ie same speed.now the problem is ..when i put this 512 mb ram.. my booting time takes almost 20 minutes.. so i checked it with only 256 mb in the slot.. th
<natvie> en it took almost 7-8 mins.. but with my old 128mb ram it usedto take only less than 2 mins...i.e as i increase the ram the system is getting slower
<rtg> tjaalton: even if you upload now it ought to DEPWAIT on the arches that have yet to build.
<rtg> tjaalton: I guess my point is, I don't think we need to coordinate on when you upload since there is already a -8 kernel in the archive.
<natvie> can anyone help me
<tjaalton> rtg: ok, cool. I hope to be ready soon
<rtg> natvie: have you run the memtest ?
 * ogra has a really funny bug here ...
<natvie> yes.. idi run the mem test.. evrything is fine
<rtg> ogra: how amused will I be?
<natvie> one more  thing.. i have got dual boot.. and 512 is working perfectly with my windows XP
<ogra> since the beginning of hardy i noticed that my music playback didnt keep a constant speed (sounding like you play with the reel on a tape)
<natvie> i use ubuntu 6.06. as i'm new in linux..
<ogra> i was looking for bugs in mp3 playback and even in rhythmbox ....
<rtg> ogra: I think listening to that would make me ill :)
<ogra> today i had to stopwatch something ... 
<ogra> intrestingly that showed me that not my playback but my system constantly seems to change speed
<natvie> rtg:i tried 512mb and 128mb seprately on suse9.1, gnu/linux, ubuntu 5.10 etc.. in all the above i did fresh installations.. but in all the above ..i'm having trounle with this ram upgrade
<tjaalton> rtg: btw, now that we have open-vm-tools, aren't the ones in lrm redundant?
<tjaalton> they are not even built
<rtg> tjaalton: likely, contact soren. He just updated the lum version.
<ogra> (i never noticed that before, but the "wait" cursor rotates according to teh music speed as well)
<rtg> ogra: could it be a problem with the codec device and/or driver?
<natvie> rtg: wat could possibly be the problem
<ogra> rtg, unlikely and i wonder how that should influence my cursor 
<ogra> its also not constantly there
<soren> tjaalton: No.
<rtg> ogra: well, if interrupts were not getting serviced. something like that. arethere any complaints in syslog?
<smb> ogra: is that the same machine that has this oopses and sometimes some clock issues
<ogra> only happens at times, very unpredictable but lasts for a while then
<tjaalton> soren: ok, thanks
<ogra> smb, nope, other one
<soren> tjaalton: The ones in lrm are the ones you need on the host side. The ones in lum are the ones you can benefit from in the guest.
<smb> ogra: ah. ok. just came to my mind :)
<tjaalton> soren: ok, they haven't been built since feisty though :)
<natvie> wat can i do abt he ram
<soren> tjaalton: *shrug*
<ogra> rtg, hmm, nothing in syslog it seems
<tjaalton> soren: not to mention that they are old, but maybe I'll just leave them be for the time being :)
<rtg> ogra: what kind of platform?
<soren> tjaalton: I forget why they were added to begin with.. I wasn't involved in that stuff back then.
<ogra> ogra@ceron:~$ cat /proc/cpuinfo |grep model
<ogra> model		: 4
<ogra> model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
<ogra> model		: 4
<ogra> model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
<ogra> dual core pentium
<rtg> ogra: looks identical to mine.
<soren> Actual dual core or hyperthreading?
<ogra> play some internet radio during the next days while working ;)
<rtg> soren: hyperthreaded.
<tjaalton> soren: seems that the kernel modules are now in partner repo
<rtg> ogra: I play local tunes quite often. The only time I notice drop out is under heavy disk activity.
<ogra> hmm, i rarely play local tunes ...
<ogra> i'll switch to local for the day tomorrow, so i can see if it shows up there as well
<ogra> its really significant sometimes ... like you hold back the tape, lest loose and it rushes past the head quickly it really behaves very analogue :)
<ogra> s/lest/let/
<rtg> ogra: see if you can correlate that behavior with other activity, such as wireless or wired network activity, background disk indexing, etc.
<rtg> maybe screen updates?
<ogra> well, its an ltsp server so it doesnt have or drive any screen
<rtg> ogra: so, lots of network activity, then?
<ogra> well, not really, i usually only run a single terminal on it ... 
<rtg> but your audio is coming over the network, right?
<ogra> right
<ogra> through pulse
<rtg> any change that the stream is being affected somewhere else?
<ogra> emulating an alsa device in the user session ... 
<rtg> s/change/chance/
<ogra> well, the line between server and client is a direct connection ... my payload goes over the other networks here in the house
<ogra> all ist does is serving one terminal over 100Mbit ... if i do tests i usually run up to ten terminals on that network piece without any saturation issues
<ogra> additionally i would expect audio to get choppy rather than changing speed if the net is involved
<rtg> ogra: I agree.
<rtg> ogra: I also know that if this bugs the shit out of you, you're capable of figuring it out :) 
<ogra> right
<rtg> I don't havbe a quick anser.
<ogra> its not overly important and i wasnt after pushing anyone to fix it :)
<ogra> as i stated initially ... funny bug :)
<amitk_> ogra: could you check if frequency scaling is involved?
<ogra> amitk, i did alreaady seems not :/
<ogra> (that was actually the first thing i checked after searching in the audio stack)
<amitk> ogra: install latencytop and keep it running it through these apparent slow downs
<ogra> but i suspect there is a clocking issue *somewhere* 
<ogra> cool, thanksi didnt know about that tool 
<amitk> recently released
<ogra> ah, thats why apt doesnt find it :)
<ogra> where do i get it ?
<amitk> latencytop.org i believe
<ogra> uuuh
<ogra> does our kernel have the required patch ? 
<rtg> tjaalton: see http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=983c3899ef3f44ec0e65f23cf6fd8571a8bc4d5b . You'll need to do this for lrm.
<amitk> unfortunately, no. But I'm thinking if we should...
<ogra> yeah
<ogra> t least during development we should
<ogra> seems like a helpful monitoring tool 
<rtg> amitk: its gotta happen today.
<tjaalton> rtg: needed for lrm too?
<amitk> rtg: ogra: there is an overhead with tracking anything.
<ogra> amitk, i dont mind having some overhead during the development cycle ... you can remove it for the release
<rtg> tjaalton: the new dpkg-buildpackage passes options to all build. kernel stuff just won't work unless you unexport LDFLAGS (in particular)
<amitk> rtg: would enabling it now and disabling it in some Beta be acceptable?
<rtg> amitk: how about ifdef'ing it? ogra can build his own kernels.
<amitk> rtg: it is #ifdef'ed. You need to enable CONFIG_LATENCYTOP
<ogra> (that doesnt mean he wants to :P )
<rtg> even better, a sysfs entry to enable it dynamically?
<ogra> yeah
<ogra> that sounds handy
<tjaalton> rtg: gotcha
<rtg> amitk: it would be easy enough to peridically produce a CONFIG_LATENCYTOP enabled kernel in a PPA.
<amitk> rtg: yup, let me see how current the patch is. I'll get back to you
<rtg> amitk: np. we can add it later  since its not an active feature (by default)
<soren> How far are we from a new linux-meta?
<rtg> soren: as soon as I verify the kernel FTBS are fixed. probaly later this afternoon.
<soren> rtg: When is "afternoon"? I forget your $TZ.
<rtg> its 0900 here. so, another 3-4 hours?
<soren> Awesome.
<amitk> rtg: you already wrapping up -8.14?
<rtg> amitk: test building as we speak.
<rtg> making damn sure I didn't break ABI
<amitk> rtg: so I can commit to git?
<rtg> yep, but don't start a new release just yet.
<rtg> just in case.
<amitk> rtg: this is the latencytop patch
<rtg> ok
<tjaalton> rtg: hmm, the new lrm will end up in NEW because of adding -server
<rtg> tjaalton: thats OK. almost every kernel does as well.
<tjaalton> ah, ok
<rtg> tjaalton: besides, I know the archive admins.
<tjaalton> :)
<tjaalton> rtg: phew, lrm is now uploading
<rtg> bombs away... kernel in a bit. I want to make _really_ sure I've solved the dpkg-buildpackage FTBS carnage.
<Kano> rtg: do you know this driver: http://www.ralinktech.com.tw/data/drivers/2007_1220_RT2870_Linux_STA_v1.2.1.0.tar.bz2
<Kano> it fails to build with 2.6.24
<rtg> Kano: why am I responsible for that?
<Kano> well it is a wlan driver
<Kano> and you could add it if you get it compiled
<Kano> i am sure there will be more users for that driver
<rtg> Kano: its likely it'll have to go into the lbm package (if anywhere)
<Kano> whats lbm?
<rtg> linux-backports-modules
<Kano> replacement for lum?
<rtg> its in addition to lum
<Kano> ah
<Kano> whats teh difference
<rtg> in the past its how I upgraded ALSA with impacting users who choose _not_ to install lbm
<rtg> s/with/without/
<rtg> lbm modules take precedence over lum and kernel.
<rtg> e.g., they are first in the depmod search order.
<Kano> but is completely empty now?
<rtg> it is empty for Hardy. Look at Gutsy for an example.
<mjg59> Hm. -7 boots *very* slowly on one of my test boxes, until / gets mounted
<mjg59> Then it seems to speed up
<mjg59> Caps lock takes ages to respond, so it seems to be somewhere in the kernel
<rtg> mjg59: I've noticed that on at least one as well. I'm hoping -8 (without the generic IDE driver) will help.
<rtg> mjg59: -8.14 that is.
<mjg59> Hm. Yeah, generic has ended up binding. 
<mjg59> Wait, no.
<Kano> rtg: how about using pata_nv for nvidia?
<inuka_desk> amitk, Jay toled me that you guys were having issues with the driver....?
<rtg> mjg59: I backed all the IDE changes out: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=351cc10d3c1c2ab09773b24994389d7533c832dd
<amitk> inuka_desk: it was an ABI and versioning confusion in the mobile PPA
<amitk> should be solved soon
<mjg59> rtg: Right, if the legacy drivers are enabled they need to be blacklisted by default
<inuka_desk> amitk, oh ok just checking...
<rtg> Kano: CONFIG_SATA_NV=m in all configs except virtual.
<Kano> rtg: but i have got hda
<Kano> i mean PATA_NV
<Kano> the other nv driver disables dma for my dvd drive
<amitk> mjg59: rtg: Wouldn't it be nicer to have a way to explicitly enforce an order in which modules are tried: ata_piix -> ide_generic 
<rtg> pata_amd.c: Nvidia SATA devices are claimed by sata-nv.c
<mjg59> amitk: There's only really one order that makes sense
<Kano> i will compile the kernel without old ide drives but it is really annoying when you try the generic one
<rtg> amitk: some thing in itiramfs ?
<rtg> s/itiramfs/initramfs/
<mjg59> amitk: There's only really one order that makes sense (native,acpi,pci-generic,generic)
<mjg59> The problem is that there's two different native drivers provided
<mjg59> Either will work, but libata is basically always preferred
<amitk> rtg: yeah... apparently fedora does something like this in the mkinitrd script
<amitk> s/the/their
<mjg59> The sensible thing is just not to include the legacy ones in the initramfs when a libata driver is shipped
<amitk> mjg59: but sometimes (admittedly very rarely now) the libata driver doesn't work
<mjg59> amitk: Right, so in that case we should ship the legacy one and blacklist the libata one :)
<mjg59> You'll never want both in the initramfs
<mjg59> Unless one trips bugs on some hardware and the other trips bugs on different hardware, in which case we should probably just trim the PCI IDs
<Kano> no good idea when you want to use em with a different config
<mjg59> Kano: ?
<Kano> well when you want to do a kernel without legacy ide drivers
<mjg59> I still don't understand what you're saying
<Kano> which ids do you want to remove?
<mjg59> Any overlapping IDs when we need to provide both in the initramfs
<Kano> then remove the legacy ids
<mjg59> Well, obviously
<Kano> also pata_amd i would prefer (it is not pata_nv)
<mjg59> amitk: It would probably be helpful to write something to scan through the modules and flag any cases where we have multiple modules supporting the same IDs
<amitk> mjg59: sure
<Kano> mjg59: thats easy
<Kano> just usw awk on modules.pcimap
<mjg59> amitk: Then we can add appropriate blacklist entries or remove IDs as necessary
<tjaalton> rtg: crap, lrm failed to build on i386, nv-new for -server
<Kano> tjaalton: do you want a patch
<Kano> or do you want to seek for it alone ;)
<Kano> i fixed that weeks ago *g*
<tjaalton> Kano: you have one?
<Kano> i reused the fedora one
<Kano> accept dcc
<Kano> whats up
<tjaalton> url please
<tjaalton> or pastebin
<Kano> extracted from source.rpm
<tjaalton> which package?
<Kano> http://rpmfind.net/linux/RPM/mandriva/devel/cooker/x86_64/media/non-free/release/dkms-nvidia-current-169.09-1mdv2008.1.x86_64.html
<Kano> nvidia-2.6.24-xen.patch
<Kano> is what you need
<Kano> already included in http://kanotix.com/files/install-nvidia-debian.sh
<Kano> tjaalton: i think it was before from fedora, but just seek for the name, very easy to find
<tjaalton> Kano: ok thanks
<Kano> that script installs nvidia with a patched standard installer and has that patch also integrated in case of xen found
<tseliot> Kano: doesn't this line work any more?
<tseliot> export IGNORE_XEN_PRESENCE=1
<Kano> it works but for 2.6.24 you need an extra patch
<Kano> i told you the name, gave you link to rpm with that, even a script with it...
<tseliot> ok, thanks
<tseliot> I asked since DKMS + export IGNORE_XEN_PRESENCE=1 works well on Hardy
<Kano> it can not be for xen
<Kano> that deb has
<Kano> err rpm
<Kano> PATCH[0]="nvidia-2.6.24-xen.patch"
<Kano> PATCH_MATCH[0]="^2.6.2[4-9]"
<Kano> do you see that
<Kano> in the dkms.conf
 * tseliot nods
<tseliot> you're right
<tseliot> It looks like I'll have to modify Envy
<Kano> you write envy?
<tseliot> Yes, I did
<Kano> well i wanted to adopt that for my script too
<Kano> maybe i add dkms support,seems to be easy
<tseliot> yes, it's quite easy to do
<Kano> only that dkms file
<tseliot> I did it
<Kano> i never use envy ;)
<tseliot> well, I haven't released EnvyNG yet
<tseliot> ;)
<Kano> my scripts have been out years before envy and work still
<tseliot> EnvyNG (Next Generation) will use DKMS
<tseliot> yes, I know :-)
<Kano> will change the fglrx script to dkms , thats easy, for nvidia it is a bit tricky
<tseliot> not that tricky ;)
<Kano> well maybe i put it in a package like fglrx
<tseliot> maybe you can have a look at EnvyNG when it's finished
<tseliot> that is to say very soon
<Kano> maybe, but i prefer "own" solutions *g*
<tseliot> there's only one solution as regards dkms.conf :-P
<Kano> you can reuse the mandrake one too
<tseliot> I tried but DKMS refused to install the module
<Kano> so upload yours
<tseliot> sure, I would like to include the patch you gave me first
<Kano> i can think of the 2 lines
<Kano> thats not the problem
<Kano> nvidia, 169.09, 2.6.24-7-generic, i686: built
<Kano> that worked btw...
<tseliot> with Mandriva's dkms?
<tseliot> with Mandriva's dkms.conf ?
<Kano> i only changed ver to 169.09
<tseliot> really? Then it means that I had tried some older version of the package
<Kano> i used the one i gave you
<tseliot> I remember that the package built but when I tried to install it, DKMS failed
<tseliot> have you tried to install the packages?
<Kano> maybe it needs the makefile for other kernels too
<tseliot> have you tried the packages yourself?
<Kano> the package now
<Kano> no
<Kano> i only extracted a few things
<tseliot> ah, ok
<Kano> but in theory i could try that too...
<tseliot> it shouldn't break anything
<tseliot> if it's only the part with DKMS
<Kano> hmm when i copy it completely i get bad exit status 2
<Kano> musst diff it
<Kano> -mcmodel=kernel -mno-red-zone
<Kano> and removed xenchat
<tseliot> does this depend on your specific system configuration?
<Kano> well i fetched the x86_64 rpm ;)
<Kano> you need a 64 bit system
<tseliot> aah
<Kano> well basically only 2 files are different to 32 bit
<Kano> Module.symvers + nv-kernel.o
<Kano> then it works
<tseliot> I see
<Kano> i just dont understand why
<Kano> DEST_MODULE_LOCATION[0]="/kernel/drivers/char/drm"
<Kano> this is used
<Kano> usually it is in
<Kano> kernel/drivers/video/
<Kano> do you get this?
<tseliot> let me check
<Kano> which is stupid
<tseliot> it should be
<tseliot> /kernel/drivers/video/nvidia
<Kano> as when you uninstall the module an older module will be copied to the new location
<tseliot> it works well with that
<Kano> sure, maybe mandrake specific
<tseliot> I don't use Mandriva
<tseliot> therefore, yes it might be mandriva specific
<Kano> interestingly fglrx uses the drm location for dkms.conf
<Kano> but misc when you use m-a...
<Kano> (edgy target)
<Kano> dont know what the installer uses
<tseliot> true, but I don't know why fglrx requires that line...
<Kano> i dont think that you require it, maybe you just use it for both
<tseliot> currently I use a customised dkms.conf for NVIDIA while I leave the ATI installer the burden to build the packages for me
<Kano> why is it impossible to use remove before using build?
<Kano> dkms remove $(dkms status|awk '/^nvidia/{print "-m "$1" -v "$2}'|sed 's/,//g'|uniq) --all
<Kano> that only works after build but not directly after add...
<Kano> stupid or not...
<Kano> rm -rf /var/lib/dkms/nvidia/
<Kano> maybe thats faster...
<Kano> as final cleanup
<Kano> dkms remove $(dkms status 2>/dev/null|awk '/^nvidia/{print "-m "$1" -v "$2}'|sed 's/,//g;s/:$//'|uniq) --all 2>/dev/null
<Kano> this works... forgot that :
<Kano> tseliot: what do you think about creating the dir, adding it, mkdeb --source-only and then just install the deb?
<tseliot> I don't understand your question
<Kano> how do you package it
<tseliot> I use the packaging scripts of the lrm
<ntolia> Hi. I am tryiing to compile a Xen kernel using the linux-source package in 7.10. However, simply copying the config file from the linux-xen image and running make oldconfig doesn't seem to work. Any suggestions / instructions on how to build it?
<tseliot> so that I get 3 packages
<Kano> ok
<Kano> well to integrate into my script i will first use another way
<tseliot> sorry but I have no experience whatsoever with Xen kernels (yet)
<tseliot> Back to what I was saying, I generate 3 packages:
<tseliot> nvidia-glx{new,legacy}, nvidia-glx{new,legacy}-dev, nvidia-kernel-source
<tseliot> where nvidia-kernel-source contains the dkms part
<Kano> well my script works a bit differnt
<Kano> it has a -v option to specify the driver or it chooses automatically the best driver for th card
<Kano> so it is more generic
<tseliot> Envy can do that for me
<tseliot> so that I can build whatever the user wants
<tseliot> or whatever autodetection decides
<Kano> nv autodetect is really simple... fglrx you need to update everytime
<tseliot> I keep id lists for both drivers
<Kano> i use whitelist for fglrx and blacklist for nv
<tseliot> I keep the ids in python dictionaries. Each driver flavour has its own dict
<Kano> there are always different ways
<tseliot> yep
<Kano> i do not understand python, i use bash
<Kano> or better: dash
<Kano> as the script is pure posix
<tseliot> I use Python because it's just too easy to use
<tseliot> and I can use both GTK and QT4 with it
<tseliot> and of course I know Python better than bash
<tseliot> it's a matter of taste
<tseliot> btw, envy was originally written in bash
<Caesar> re: #183928, is the intention only to carry the Centrino branded and certified version of iwlwifi at the expense of the various improvements in the later versions?
<Caesar> (particularly talking about Hardy here)
<alex_joni> bug #183928
<ubotu> Launchpad bug 183928 in linux-ubuntu-modules-2.6.24 "update iwlwifi to latest version" [Medium,Won't fix] https://launchpad.net/bugs/183928
<rtg> Caesar: for now. its possible that if there are compelling reasons I might do an lbm version.
<Caesar> rtg: how would you like to be compelled? :-)
<rtg> There would have to be a number of failure cases. At any rate, I'm not going to get to it for a few weeks.
<Caesar> serge: you have failure cases, right?
<serge> Versions like 1.2.23 is being used by Fedora 8 so could be considered well tested 
<serge> on WPA enterprise roaming from one access point to another we get packet loss, I have bug reports from people saying that their connection drops 
<serge> drops out from time to time
<serge> also my logs are full of TKIP decrypt failed for RX
<serge> etc
<serge> I don't think the users look at their logs so have not had any reports 
<Caesar> rtg: can we make this easier for you? Provide a patch?
<rtg> sure, but do it for linux-backports-modules
<serge> Fro Hardy ? 
<rtg> yep.
<Caesar> rtg: why backports?
<rtg> because its an elective install. lum and the kernel are required.
<tjaalton> rtg: I hope the latest lrm builds on i386, since I need to get some sleep :)
<tjaalton> lpia is the only one that has finished building
<tjaalton> so far
#ubuntu-kernel 2008-02-15
<tjaalton> whoa, i386 built \o/
<mjg59> tjaalton: \o/
<tjaalton> what the.. why is the lpia* lrm's versioned -7-lpia*
<tjaalton> grrrr
<tjaalton> I don't remember having to touch the rules too
<tjaalton> why the hell did I miss that
<tjaalton> dpkg-parsechangelog | grep ^Version | sed 's/.*-//;s/\..*//'
<tjaalton> that would get the abiver from the version string, like I thought it would do :)
<tjaalton> rtg: sorry for the delay, hopefully it's ok now
<herman> hey! The autor of aufs is juliank?
<kraut> moin
<Kano> hi rtg 
<Kano> just saw an interesting commit for the kernel. do you work on dmraid45?
<Kano> also please update aufs when you update the rest
<Kano> tjaalton: MAKE[0]="make SYSSRC=\${kernel_source_dir} module IGNORE_XEN_PRESENCE=1"
<Kano> is that YOUR big trick ;)
<Kano> very simple to find that on your own
<tjaalton> ?
<Kano> i mean for dkms
<tjaalton> I haven't played with dkms at all
<Kano> hmm then it was somebody else with a similar nick
<tjaalton> tseliot
<Kano> exactly
<Kano> but it really seems pretty interesting that dkms
<Kano> btw. dkms in ubuntu has en error
<Kano> the uninstall trigger can not work
<Kano> wrong parsed
<tjaalton> Kano: you mean the lrm package?
<Kano> arch=`echo "$line" | awk '{print $4}' | sed 's/:$//'`
<Kano> no the debian/kernel_prerm.d_dkms
<Kano> : not ,
<tjaalton> ok
<tjaalton> phew..
<Kano> i think nobody REALLY tested remove
<Kano> btw. why is only uninstall and not remove triggered?
<Kano> do you think somebody installs it again
<Kano> http://kanotix.com/files/thorhammer/updates/dkms/
<Kano> that works now
<Kano> rtg: http://article.gmane.org/gmane.linux.alsa.devel/51536
<Kano> did you see this
<tseliot> tjaalton: why did you remove this lines from the debian/rules of the lrm?
<tseliot> export DH_COMPAT=4
<Kano> tseliot: did you find the uninstall error in dkms
<tjaalton> tseliot: I did?
<tseliot> tjaalton: either you or someone else
<tseliot> di
<tseliot> did
<tseliot> Kano: uninstall error?
<Kano> well try to delete a kernel
<Kano> then uninstall should be triggered
<Kano> but instead you get an error
<Kano> because of a stupid typo...
<Kano> maybe you could even trigger remove, not only uninstall
<Kano> http://kanotix.com/files/thorhammer/updates/dkms/
<Kano> fixed version there
<Kano> or check /etc/kernel/prerm.d/dkms
<tseliot> so the problem affects DKMS itself, doesn't it?
<Kano> only the debian packageing
<Kano> it is in the debian dir
<Kano> : not , in arch line
<Kano> is the fix
<tseliot> did you file a bugreport about this?
<Kano> nope
<tjaalton> tseliot: that's not exported in gutsy either, and first time I touched lrm was in November ;)
<Kano> i uploaded it to my repository, that is faster *g*
<Kano> also this is -5 not -4 directly form dell's website
<tseliot> tjaalton: ok, maybe the problem affects only the packaging scripts I use for Envy. I just wanted to make sure that it didn't break the lrm
<tseliot> Kano: I would like the get the fix into hardy
<mdomsch> Kano, what's my typo?
<tjaalton> tseliot: k
 * mdomsch is upstream for DMKS
<mdomsch> DKMS
<tseliot> tjaalton: thanks for your prompt reply, as usual ;)
<Kano> mdomsch: arch=`echo "$line" | awk '{print $4}' | sed 's/:$//'`
<Kano> not
<Kano> sed 's/:$//'`
<Kano> sed 's/,$//'`
<Kano> i mean
<tjaalton> tseliot: well, I wanted to be sure about it
<Kano> mdomsch: how about using remove instead of uninstall in that file?
<tseliot> tjaalton: why do the nvidia packages suggest nvidia-settings when there's no nvidia-settings in the repos?
<tjaalton> tseliot: it's in NEW
<tjaalton> hmm, actually it should be accepted
<mdomsch> Kano, it should be uninstall; we don't want to nuke the driver for any other kernels present
<Kano> mdomsch: it would not nuke it
<Kano> but it keeps the binary
<mdomsch> ok, I see the bug, fixed now in my tree
<tseliot> tjaalton: aah, as I removed nvidia-settings from Envy's packaging scripts as well. Ok, I'll wait for the package to be approved.
<mdomsch> ah, we're specifying kernel and arch
<mdomsch> ok, remove it is.
<tjaalton> tseliot: binaries are built, but needs a push
<tjaalton> same for the lrm btw
<tseliot> tjaalton: ok, I'll just make sure that EnvyNG installs that package instead of building its own nvidia-settings
<Kano> remove is definitely cleaner
<tjaalton> tseliot: yeah, I think it's wise to use the one that has sources
<tseliot> Kano: I gave you credit for reporting the problem (and the solution) about xen kernels in Envy's changelog :-)
<tseliot> thanks again
<Kano> tjaalton: did you see that new thing in 171.05 called nvidia-smi?
<Kano> i dont know what to do with it but it is there...
<Kano> works only with 171.05
 * tseliot reboots and tries the new DKMS patch with a xen kernel
<tjaalton> Kano: what is it?
<Kano> no idea
<tjaalton> that release is for some professional setup
<Kano> well it works too for others ;)
<tjaalton> yes, but no changes for them
<Kano> well i like to try all ;)
<mdomsch> Kano, I"ll fix this up and let superm1 help me get it uploaded
<Kano> fine
<tjaalton> oh crap, moving libglx turned out to be a bad ide
<tjaalton> +a
<tseliot> tjaalton: I was about to report it
<Kano> mdomsch: did you test what happens when you execute remove and it is the last entry
<tjaalton> I can't understand why it doesn't load it from the right path when you have nvidia
<mdomsch> Kano, not yet
<Kano> mdomsch: in that case you can only use uninstall or is there an option to leave the source?
<mdomsch> Kano, no such option at present
<mdomsch> hence uninstall; with remove at uninstall of the package with the source
<Kano> well maybe tell upstream to add this option
<Kano> somethink like --keep-source or so
<tseliot> tjaalton: this line makes a dead symlink:
<tseliot> usr/lib/xorg/modules/libglx.so.@@VERSION@@ usr/lib/xorg/modules/libglx.so
<mdomsch> that's going to mess up packages with prebuilt binaries in them
<mdomsch> I'm going to leave it as uninstall
<tseliot> tjaalton: in nvidia-glx.links.in
<Kano> mdomsch: i like that feature to create debs
<mdomsch> yeah
<tjaalton> tseliot: oh
<Kano> for my new nvidia script i basically write the conf file, add it, then create deb and install the deb
<Kano> then the module is compiled and you could even uninstall nvidia-dkms..
<Kano> when you dont need it, pretty funny
<tseliot> tjaalton: there's a broken link in /usr/lib/xorg/modules/ . Ok, let's fix it.
<tjaalton> tseliot: yeah, thanks for spotting *headdesk*
<tjaalton> moving it made it work, I'll upload a new version ASAP
<tseliot> tjaalton: great
 * tseliot tries the new fix in EnvyNG
<tjaalton> uploaded
<tjaalton> luckily the binaries were not published yet
<Kano> rtg: can you change the lum package that it compiles without disabling d-i als when debian/d-i/kernel-versions is empty
<Kano> i bacially only compile a custom flavour without d-i modules
<rtg> Kano: patches will be considered
<Kano> rules.d/2-binary-arch.mk:#binary-arch: binary-debs binary-udebs
<Kano> rules.d/2-binary-arch.mk:binary-arch: binary-debs
<Kano> thats a stupid hack
<Kano> better would be when binary-udebs would not break when the file is empty
<rtg> Kano: the kernel has something like that, the disable_d_i flag for flavours that don't have any d-i bits.
<Kano> rtg: well i modify both packages usually to compile only the kanotix flavour
<rtg> Kano: send a lum patch to the kernel-team mailing list that works for both of us and I'll consider it. In the meantime, I've got my hands full with some other issues.
<Kano> rtg: could you update aufs in the meantime ;)
<rtg> zul: xen doesn't build with the -9 kernel. (nor does -rt)
<zul> rtg: ill take a look
<rtg> zul: I also just dropped a note to the kernel-team ml.
<zul> rtg: where did it fail?
<rtg> zul: somewhere in the compile phase.
<zul> oh...ok....
<zul> rtg: fixed locally
<rtg> beam me up scotty
<zul> can I just send you the patch?
<zul> ie put it somewhere you can get it
<rtg> zul: yes - just announce a git pull. 
<zul> ok...
<j4k4> hi folks
<tseliot> tjaalton: why doesn't fglrx-kernel-source contain 7.1.0 in its version while the other fglrx packages do?
<tseliot> if it's not an error I'll make Envy compliant with this as well
<tjaalton> tseliot: I'm not sure..
<tseliot> tjaalton: having a consistent version scheme in the fglrx driver would be of help
<tseliot> would it be possible to make its version as it was before?
<tjaalton> what do you mean "as it was before"? it's been like that for some time (releaseversion+kernelversion)
<tseliot> something like 1:7.1.0-8-02+2.6.24.7- etc.
<tseliot> like xorg-driver-fglrx
<tseliot> which means xorgversion+releaseversion+kernelversion
<tjaalton> imho the xorgversion part should be dropped instead
<tseliot> tjaalton: ok, but can it be dropped for all the fglrx packages?
<tjaalton> maybe some time
<infinity> It was, historically, part of the complete version.
<tseliot> tjaalton: this is causing problems with Envy :-/
<infinity> When we switched from Xorg 7.0 to Xorg 7.1, but the fglrx version didn't bump.
<tseliot> infinity: would a change break anything?
<infinity> There had to be a way to bump the version of the package, despite the fglrx version not changing.
<infinity> tseliot: fglrx had two modules shipped (one for 7.0, one for 7.1), and when we changed the packages to use the 7.1 version, the binaries needed a new version.
<tseliot> yes, I know
<tseliot> but now it seems to be no longer the case
<infinity> This is all, perhaps, "historical" now, though I imagine the exact same thing happening again with a new Xorg ABI change some day.
<tseliot> infinity: I see your point, however all I'm asking is consistency between all the fglrx packages
<tjaalton> right, it's not long ago when they didn't know what version to use (8.41x -> 7.01 -> 8.42? -> 8-01 ..)
<tseliot> having all either with or without the Xversion
<infinity> I'm not sure how it looks these days, but fglrx-source used to ship both Xorg ABI drivers in it, hence why it didn't include the Xorg version.
<tseliot> tjaalton: yes, ATI adopted the same version scheme as their Windows Catalyst driver
<infinity> Granted, I haven't touched lrm for a couple of years (thank god), so I'm not sure how much of my hackish packaging lives on...
<tjaalton> infinity: :)
<tseliot> hehehe
<tjaalton> tseliot: the driver itself still thinks its 8.4xxx
<tseliot> tjaalton: yes, if you extract the installer you get something like 8.45
<tseliot> but the "official" version is 8-02
<tseliot> at least this is (more or less) what they told me in the mailing list of ATI
<tseliot> as I'm a beta tester
<tseliot> I'll make EnvyNG's package compliant with Ubuntu's version scheme then... *sigh*
<tjaalton> tseliot: I think the cleanup is best left after hardy
<tjaalton> +to be 
<tseliot> tjaalton: no problem, I'm hacking on ATI's packaging scripts now
<tseliot> I'll make sure it's all compatible with Ubuntu
 * j4k3b makes a launchpad page
#ubuntu-kernel 2008-02-16
<Kano> tseliot: did you use the kernel 2.6.23+ hack for avm drivers?
<tseliot> Kano: I don't use avm drivers
<Kano> tjaalton you?
<Kano> tjaalton: do you use the objcopy hack for avm?
<Kano> tjaalton: similar to: http://aur.archlinux.org/packages/fwlanusb/fwlanusb/PKGBUILD#
<Kano> tjaalton: needed for all
<tjaalton> nope
<tjaalton> meaning I don't use avm
<Kano> didnt you package it?
<Kano> without nothing will work
<Kano> so apply it
<tjaalton> no I didn't
<Kano> but you changed 2 avm bugs
<Kano> TimoAaltonen 
<Kano> but you dont know anything about avm?
<tjaalton> sigh
<tjaalton> the bug about pci_register_driver is fixed in hardy
<tjaalton> what's the other one?
<Kano> Bug 128301
<ubotu> Launchpad bug 128301 in linux-restricted-modules-2.6.24 "2 usefull missing avm drivers fcpcmcia and fcusb2" [Undecided,New] https://launchpad.net/bugs/128301
<tjaalton> that's not closed
<tjaalton> I just moved it forward
<fdasfsad> hi guys
<fdasfsad> can anyone tell me where I can get the em28xx alternative driver from mrec
<fdasfsad> seems like mcentral.de is down
<eradicus> why am I getting  error: linux/module.h: No such file or directory
<eradicus> i'm trying to compile a kernel module, i have the kernel sources & header in /usr/src/
<fdasfsad> do you?
<fdasfsad> does /usr/src/linux point to the kernel source folder?
<eradicus> fdasfsad, yes
<eradicus> linux -> linux-source-2.6.22
<fdasfsad> you're trying to compile a kernel module outside the kernel?
<eradicus> yes, so later i can insmod it...
<fdasfsad> well then check if there is some absolute definition for linux/module.h or check the makefile - maybe it points to a wrong folder for includes
<eradicus> what do you mean by absolute definition?
<fdasfsad> like #include "linux/module.h"
<eradicus> nope i'm using <>
<fdasfsad> ok
<fdasfsad> then check the Makefile
<eradicus> not using makefile yet... i'm trying to compile the basic module, i.e. hello world.
<eradicus> #define MODULE
<eradicus> #include <linux/module.h>
<eradicus> the first two lines ^
<eradicus> then i have init_module() and clean_module()
<fdasfsad> then what options do you pass to gcc?
<eradicus> -c 
<eradicus> any other options needed aside from the above stated?
<eradicus> sorry newbie here 
<eradicus> fdasfsad, what could be wrong? i have recompiled the source before diving into module writing.
<eradicus> anyone who can help me...
<anakron> hail
<anakron> someone there?
<anakron> im looking for kernel developer
<JanC> I'm not a kernel developer, so not sure if I can still help you?
<anakron> i only wanna report a kernel panic
<anakron> that i found in last upgrade
<anakron> when i do dist-upgrade, kernel 2.6.28-8 wasnt added to grub, so when i restart i cant choose it
<anakron> then i update grub,and reboot i choose 2.6.24-8
<anakron> was kernel 2.6.24-8 sorry
<anakron> i choose it but kernel panic appears
<anakron> so i try to use 2.6.24-7 but Desktop was unable to use, so, in terminal, i built dependencies of mount and then kernel 2.6.24-8 was configured 
<anakron> now im using kernel 2.6.24-8 without any problem
<anakron> :) thats what the problem
<anakron> the upgrade was a problem cause dont built dependencies
<JanC> ah, you're testing hardy
<anakron> yes
<anakron> :d
<anakron> :D
<JanC> best you can do is file a bug report I guess
<JanC> if nobody else already did
<anakron> but
<anakron> i dont know where i can find that log messages
<JanC> I guess they will tell you if they need them  ;)
<tjaalton> I don't understand the problem..
<anakron> xD
<tjaalton> what does "built dependencies" mean?
<anakron> which is the log file where boots messages are wrote
<anakron> foir example, /var/log/syslog
<anakron> but i dont found my kernelpanic
<tjaalton> that's irrelevant
<tjaalton> something went wrong with your update
<tjaalton> what did you do to fix it?
<anakron> build dep of mount
<tjaalton> sorry, I don't follow
<crimsun_> "kernel panic"?  e.g., the initramfs not being rebuilt?
#ubuntu-kernel 2008-02-17
<dballester> hi to all, i know that's off-topic, but i've severe problems and I hope that anyone can give me some starting point
<dballester> I've lost a lvm/ext3 partition info ( and overwrotten metadata ). In fact, I must carve. By now i wanna know a way to know the physical begining of a file in ext3, to practice with dd and header/footer of this file. I want to try to acquire info about file header/footer of typo files in a good ext3 filesystem, once i'll have a list of this, apply them in the lost disc with scalpel/foremost 
<dballester> Any tip on how to know the position of a file inside an ext3 filesystem ( no inode info, the real offset from the begining ) TIA
<dballester> By now i'm reading about dumpfs, file, etc...
 * lamont grumbles about https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/192559
<ubotu> Launchpad bug 192559 in linux-ubuntu-modules-2.6.24 "alsa update breaks kernel ABI" [Critical,New] 
<lamont> I CAN HAZ SOUND NAO PLS?
<benje_> hello
<benje_> is it normal that failed with a z-com prism54usb [   47.178742] ieee80211_init: failed to initialize WME (err=-17) line 380 http://paste.ubuntu-nl.org/56404/
<benje_> is it depending the p54usb or the card , or ieee80211 only ?
<benje_> the z-com is 0cde:0008
#ubuntu-kernel 2009-02-09
<tritium> Hello.  If I have a request for the inclusion of firmware, shall I subscribe the ubuntu kernel team to the bug, or email the mailing list?
<tritium> Specifically, I'm referring to bug 321076
<ubot3> Malone bug 321076 in linux-firmware "Hauppauge WinTV-HVR-1800 Firmware not included" [Undecided,New] https://launchpad.net/bugs/321076
<tritium> Mail to list bounced, so I've assigned the bug to the kernel team.  Thanks!
<rtg> zul: how are  the xen bits coming for Jaunty?
<zul> not good
<zul> alot of changes that are still confusing me ill let you know
<rtg> zul: np.
<Kano> hi rtg , did you look at the webcam module
<rtg> Kano: not yet, I'm just back home.
<Kano> rtg: the patches in my mail need to be applied in the correct order
<Kano> you need all 3
<rtg> Kano: you need to follow the patch submission instructions.
<Kano> those are links to gentoo only
<Kano> do you want it as direct patch against ubuntu?
<rtg> Kano: yes - I want you to do all the work :)
<Kano> well should be no problem i already made a dkms package, then i should manage do do that too
<Kano> i would do a patch for em8300 too,but the tested did not appear yet
<Kano> but all you need to do was to apply 3 patches in a row...
<Kano> could you fix snd-bt-sco?
<Kano> all 3 patches apply without any error btw...
<henrik-hw0> rtg: do you have a minute?
<rtg> henrik-hw0: topic ?
<henrik-hw0> rtg: ralink wifi drivers and your opinion.
<rtg> I don't have enough experience with ralink to offer an opinion. I thuink there are some OEM drivers, but they are of poor  code quality IIRC
<henrik-hw0> rtg: i see upstream has included rt2860 and rt2870 drivers in staging. i've packaged the manufacturer drivers for REVU but it may be smarter to just enable compilation of them in the ubuntu linux kernel package.
<rtg> henrik-hw0: they've been enabled in the staging directory for Jaunty for the last several uploads.
<henrik-hw0> i inspected the binary usb nic package, no binary drivers found...
<rtg> but those are realtek, not ralink
<henrik-hw0> rtg: in any case, do you think it makes sense to have packages for the rt28xx chipsets in Jaunty? if they are already in the kernel package?
<rtg> henrik-hw0: I'm not I understand your question. The drivers in drivers/net/wireless/rt2x00 do not conflict with drivers/staging/rt28[67]0
<henrik-hw0> rtg: the rt2x00 drivers do not support the RT2860 and RT2870 series chipsets.
<rtg> henrik-hw0: those chipsets are supported by drivers/staging/rt28[67]0
<henrik-hw0> rtg: yes, they are. i made 2 DEB packages with the RT2860 and RT2870 drivers and submitted them to REVU. that was before said drivers was included in staging. my question is: should i still bother with getting those packages into Jaunty before feature-feeze or should i ask that they be nuked?
<rtg> henrik-hw0: I'd say nuke your packages since I assume the stuff upstream is getting some love. I'll resync staging before release, so we ought to have the latest rt28[67]0 driver sources.
<henrik-hw0> rtg: thank you very much.
<rtg> henrik-hw0: np, sorry abot the confusion
<nikolam> hi is there a way to use ext4 on hardy as additional file system.
<nikolam> I need it to read jaunty test install on other partition
<rtg> nikolam: no support for ext4 in the Hardy kernel.
<nikolam> rtg, but to compile additional module, won`t work?
<rtg> nikolam: you can try it, but it was pretty new in 2.6.24
<nikolam> interested only in reading
<tjaalton> rtg: 14d200c5e5bd19219d930b is now in linus' tree
<tjaalton> to fix bug 320813
<ubot3> Malone bug 320813 in xserver-xorg-video-intel "[drm] compiz animations cause temporary freezes with vblank" [Unknown,Confirmed] https://launchpad.net/bugs/320813
<rtg> tjaalton: I was reading that bug report. neither tester though it fixed the problem.
<rtg> s/though/thought/
<tjaalton> well I've tested it and worked for me
<rtg> tjaalton: k
<tjaalton> maybe they have g45 chips, which means they also need 9880b7a527ffbb52f65
<Kano> rtg: http://kanotix.com/files/kernel/unused-patches/2.6.28-ubuntu-qc-usb-messenger.patch.bz2
<Kano> happy with this patch?
<rtg> Kano: I'm not the only one that has to be happy with it, so resend to the mailing list.
<Kano> rtg: got mail?
<Kano> btw. i updated that patch to incl. BOM file
<rtg> Kano: what is the difference between qc-usb and qc-usb-messenger ?
<Kano> you disabled qc-usb because it is inside the kernel, it is for other ids, qc-usb-messenger is of course a mod of the first one
<Kano> look into the launchpad error
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/209901
<ubot3> Malone bug 209901 in linux "webcam Logitech QuickCam Messenger  ID 046d:08f6 is not reconized" [Medium,Fix released] 
<Kano> there was never a fix released btw ;)
<debfx> rtg: could you please have a look at bug 312554 - an upstream change has been reverted in jaunty, so now it doesn't boot anymore on asus p5q mainboards
<ubot3> Malone bug 312554 in linux "Regression: bug: int 14 cr2... booting 2.6.28 in jaunty fails on ASUS P5q and maybe others" [Undecided,Confirmed] https://launchpad.net/bugs/312554
<Kano> rtg: qc-usb is not qc-usb-messenger!
<Kano> qc-usb is now the quickcam inside the kernel
<Kano> thats a driver just for 4 usb ids
<Kano> http://home.mag.cx/messenger/
<Kano> which id added the patch, exactly fixing that launchpad error
<Kano> if you named it qc-usb before but disalbed it,it is not my fault
<Kano> from the BOM file it must be a differnet driver anyway
<Kano> maybe it would be possible to patch another driver
<Kano> and add some extra ids
<Kano> rtg: maybe disable one usb id as it is used by another driver
<Kano> quickcam_messenger
<Kano> or try to add some more ids to that one...
#ubuntu-kernel 2009-02-10
<syldeb35> does someone know Bug #316405
<ubot3> Malone bug 316405 in linux "Kernel OOPS during initialization SAA7134 jaunty kernel 2.6.28-4.generic" [Undecided,New] https://launchpad.net/bugs/316405
<JesperHansen> Is this the right channel to ask about broken/missing frequency scaling?
<Kano> rtg: could you update ndiswrapper to 1.54?
<johanbr> JesperHansen: sure
<JesperHansen> ok, I have a eeePC 900 with this readout http://pastebin.mozilla.org/620365
<JesperHansen> only prob. is it stays at 900 MHz after I replaced the default eeePC linux distro with a xubuntu
<JesperHansen> I am looking at the eeepc-acpi-scripts package, but
<JesperHansen> its setting some impossible requirements
<JesperHansen> Its wants to remove acpi-support, powermanagement-interface, ubuntu-desktop, xubuntu-desktop
<JesperHansen> this is also thrown: http://pastebin.mozilla.org/620369
<johanbr> It doesn't seem to support standard SpeedStep.
<johanbr> You might need a custom kernel module.
<johanbr> And for the second error, looks like you're mixing repos from different sources.
<JesperHansen> yea, I am considering what I am missing though, since the kernel I am running right now is a custom build. Neither this nor ubuntu's supported it (is a 2.6.28 kernel on 9.04)
<IntuitiveNipple> JesperHansen: What does this report: for node in /sys/devices/system/cpu/cpu0/cpufreq/*; do if [ -f $node ]; then echo "$node $(cat $node)"; fi; done
<JesperHansen> no, wait 8.10 with a few packages from 9.04 to make it happy
<JesperHansen> IntuitiveNipple: nothing, /sys/devices/system/cpu/cpu0/cpufreq/ doesn't exist either.
<IntuitiveNipple> well that's a big clue then :D
 * JesperHansen doesn't get the clue :P
<IntuitiveNipple> can you show the relevant settings from the .config the kernel was built with? (egrep 'FREQ|IDLE|GOV' .config)
<IntuitiveNipple> JesperHansen: if that node doesn't exist there's no frequency-scaling governer installed, hence why it stays at 900Mhz
<JesperHansen> just gotta figure out which of the two folders I compiled to the current kernel
<IntuitiveNipple> did you set a custom version signature?
<JesperHansen> http://pastebin.mozilla.org/620377 here
<IntuitiveNipple> OK, can't see anything wrong there
<johanbr> The processor in the eee doesn't support standard speedstep, so frequency scaling is not going work.
<JesperHansen> johanbr: any ideas on how getting it to work?
<johanbr> You may want to try these kernels: http://www.array.org/ubuntu/
<JesperHansen> There's a package called eeepc-applet that things like in /proc/eee/.., but does nothing really. 
<IntuitiveNipple> JesperHansen: http://kerneltrap.org/index.php?q=mailarchive/linux-kernel/2008/11/23/4311824/thread
<JesperHansen> johanbr: possible to see those patches in 2.6.28?
<JesperHansen> IntuitiveNipple: thanks, looking it through
<johanbr> No idea. I'm not a kernel developer.
<JesperHansen> weird, http://www.array.org/ubuntu/status.html?model=eeepc-900 lists that a module called asus_eee is in 2.6.27-7generic, but I cant see it
<JesperHansen> well, thanks anyways. I'll look into it :)
<JesperHansen> How long should git clone git://git.array.org/array/ubuntu-intrepid.git take? Its super duper slow on a eeePC
<IntuitiveNipple> The transfer off a full kernel tree is about 350M
<JesperHansen> Trying to compile a 2.6.28 kernel with the eeepc modules on that page
<JesperHansen> Will be back with a report on it in... 7-8 hours when its complete :P
<dholbach> hello my Kernel friends :)
<JesperHansen> what do you think we are, modules :)?
<dholbach> did anybody complain already that they just get a black screen when usplash is done with the new kernel (intel graphics, Lenovo X61s)?
<dholbach> did anybody complain already that they just get a black screen when usplash is done with the new kernel (intel graphics, Lenovo X61s)?
<apw> dholbach, which kernel?
<apw> not heard anything from anyone as yet
<dholbach> 2.6.28-7.20
<dholbach> with 2.6.28-6.17 it's all good
<apw> poop.  nothing of the sort reported
<dholbach> I'll try again in a bit and see if anything changed
<apw> i assume the machine is up?
<apw> can you flip to other VT's
<dholbach> let me do another update and see if anything fixed it
<dholbach> apw: no
<apw> is X server running ... etc
<apw> so machine was proper dead.  hmmm
<dholbach> apw: all black, if I logged in (though I couldn't see anything) the hd was doing some work
<apw> ok ... so machine is up in some sense.  be good to get openssh-server up and installed
<apw> sounds a lot like backlight is off, which is bad
<dholbach> let me try again
 * dholbach does an upgrade first
<dholbach> brb
<dholbach> apw: same happening now - I'm logged in via SSH
<apw> worth trying to turn on the screen
<apw> something like xset dpms force off
<apw> then ... on
<apw> also worth attaching to X and seeing what if anything it is doing
<apw> if its in an EAGAIN loop from select/ioctl, then check the FD thats on (it may be DRI)
<dholbach> erm
<dholbach> if I do that, it turns off the screen on the machine I'm logging in from?
<dholbach> (used ssh -X because of  xset:  unable to open display "" )
<dholbach> /var/log/Xorg.20.log:(EE) [drm] Could not set DRM device bus ID.
<dholbach> /var/log/Xorg.20.log:(EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI.
<dholbach> /var/log/Xorg.20.log:(EE) No input driver/identifier specified (ignoring)
<dholbach> /var/log/Xorg.20.log:(EE) config/hal: NewInputDeviceRequest failed
<dholbach> ^ is that something I should worry about?
<dholbach> apw: ^
<apw> dholbach, use DISPLAY=:0 xset ...
<dholbach> ah
<apw> isn't that .20 your ssh one?  ie the fake one for -X
<apw> as in your DISPLAY is :20.0 or something over ssh _X
<apw> -X
<dholbach> daniel@miyazaki:~$  DISPLAY=:0 xset dpms force off
<dholbach> No protocol specified
<dholbach> xset:  unable to open display ":0"
<dholbach> daniel@miyazaki:~$ 
<apw> oddness
<apw> try :0.0
<apw> though i would expect it to mean the same
<dholbach> same happening
<apw> ok, then lets ocnfirm which log the X server is using
<apw> fd 2 for it should be connected to the right log
<apw> so ls -l /proc/<pid>/fd/2 should tell us that
<apw> also what intel h/w do you have, my laptop here is intel
 * apw goes download the kernel
<dholbach> apw: you were right .20. was irrelevant - it was an old one
<dholbach> sorry for confusion there
<dholbach> apw: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<apw> whats the right log say, and what was it called?
<dholbach> [    0.003639] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
<dholbach> [    0.201686] (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
<dholbach> [    0.909985] (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a
<dholbach> [    0.910021] (WW) intel(0): PP_STATUS before: on, ready, sequencing idle
<dholbach> [    0.910041] (WW) intel(0): PP_STATUS after: on, ready, sequencing on
<dholbach> [    0.910070] (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00000206 to 0x00000246
<dholbach> [    0.910113] (WW) intel(0): PIPEBSTAT before: status: VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
<dholbach> [    0.910175] (WW) intel(0): PIPEBSTAT after: status: VSYNC_INT_STATUS LBLC_EVENT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
<dholbach> [    0.941704] (WW) intel(0): DRI2 requires UXA
<dholbach> no errors at all
<apw> ie what was its name
<dholbach> /var/log/Xorg.0.log
<apw> so it really should be :0
<dholbach> blindly logging in on tty1 and typing 'xset dpms force off' does not seem to do much
<apw> dholbach, and force on?
<apw> can you tell if you have backlight?
<apw> also if you think you are in and have a terminal
<apw> echo "$DISPLAY">/tmp/FOO
<apw> and see which terminal you are really on,
<dholbach> apw: it creates /tmp/FOO for the blindly-logged-in user, but it's empty
<dholbach> force on doesn't do anything either
 * apw blinks
<apw> what variables does env >/tmp/FOO show
<apw> are there any GNOME ones in there?
<apw> and indeed what does 'tty >/tmp/FOO' say
<dholbach> apw: http://paste.ubuntu.com/116426/
<dholbach> not sure there's anything exciting there
<apw> and tty?
 * apw bets its ttyN
<apw> i think you are not logged in under X there
<apw> i think you are in on the VT-1 console login (TERM=linux)
<dholbach> apw: ah yes, sorry
<dholbach> I should have said that
<dholbach> I can blindly log into gnome and try to xset something there
<apw> its $DISPLAY off the gnome thats interesting
<apw> and xset there of course
<apw> the $DISPLAY will tell us where we should talk to on ssh
<dholbach> apw: from the SSH session I can xset now
<dholbach> excuser-moi
<dholbach> when I "off", the screen flickers shortly and goes from black to even-more black for a sec :)
<dholbach> nothing in X log, syslog or .xsession-errors though
<apw> so backlight is likely on then
<apw> as it got blacker when turned off
<apw> and X is working cause you can type
<apw> what does xrandr say in ssh
<dholbach> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024
<dholbach> VGA disconnected (normal left inverted right x axis y axis)
<dholbach> LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x 185mm
<dholbach>    1024x768       50.0 +   85.0     75.0     70.1     60.0*    40.0  
<dholbach>    832x624        74.6  
<dholbach>    800x600        85.1     72.2     75.0     60.3     56.2  
<dholbach>    640x480        85.0     72.8     75.0     59.9  
<dholbach>    720x400        85.0  
<dholbach>    640x400        85.1  
<dholbach>    640x350        85.1  
<apw> is it that low res?  a t60?
<dholbach> X61s
<apw> oh baby one
<dholbach> 1024x768 is correct
<dholbach> yeah :)
<apw> i think kirkland has one of those too, must get him to try also
<apw> now dri was enabled wasn't it
<apw> so lets try turning that off
<apw> Option "NoDri"
<apw> in the device section of xorg.conf, eliminate the kernel
<apw> which we believe it is
<dholbach> apw: no dice :-/
<dholbach> apw: the strange thing is, I don't see a tty either
<dholbach> when I stop gdm I still don't see anything
<apw> very very strange
<apw> if you disable GDM, fix the init script to prevent it starting X ?
<dholbach> I could try booting with nosplash or however it's called
<dholbach> I'll try gdm first
<apw> its odd for sure
<dholbach> apw: the same, even without gdm running on start
 * dholbach tries booting without usplash
<apw> good plan indeed
<dholbach> how do I regenerate all initramfs-es? could it be something with those that's broken?
 * dholbach has no clue whatsoever :)
<tjaalton> just edit the grub cmdline
<tjaalton> remove 'splash'
<apw> yeah to turn that off is easy
<dholbach> tjaalton: yep, just did it - let's see what happens
<dholbach> I see boot messages! :-)
<dholbach> I see GDM!
<apw> if you reinstall the kernel package it will rebuild those
<tjaalton> there you go :)
<apw> so uspash is buggering something, hmm
<mjg59> Are you in a KMS world for Intel yet?
<tjaalton> no..
<mjg59> Ok, so usplash will still be using vesa
<tjaalton> so jaunty should be the last release with usplash
<apw> tjaalton, what will we do instead?
<mjg59> It ought to be falling back to text mode
<tjaalton> apw: plymouth
<mjg59> I mean, it ought to be switching back to text mode on exit
<mjg59> dholbach: If you switch back to a text console and run usplash by hand, does it exit cleanly and give you a console again?
<tjaalton> apw: it was discussed at UDS, but since KMS is still immature, it didn't make any sense to have it for jaunty
<tjaalton> besides it needs .29 and only supports intel atm
<dholbach> mjg59: no, leaves me in a black world again :-/
<tjaalton> dholbach: hmm, maybe if you regenerate the -6 initramfs.. it might get broken too
<tjaalton> usplash was updated recently
<dholbach> mjg59: exit code is 0
<tjaalton> blame kees :)
<dholbach> tjaalton: just regenerated the intramfseseses
<mjg59> dholbach: Yeah, sounds like usplash is failing to restore textmode in that case
<tjaalton> dholbach: have you tried the working kernel since?
<mjg59> dholbach: Does typing blind vbetool vgamode 3 work?
<dholbach> tjaalton: hang on, trying with the new initramfs
<tjaalton> competing questions :)
<dholbach> no, that doesn't make it work
 * dholbach tries mjg59's suggestion next :)
<tjaalton> dholbach: so, the kernel version that used to work is now broken as well?
<tjaalton> I'm quite sure it's the changes to usplash that broke it
<dholbach> mjg59: it gives me the tty back and says "function not supported" :)
<dholbach> tjaalton: hang on, I'll try rebooting into 2.6.28-6.17
<tjaalton> dholbach: did you regenerate the initramfs for it?
<dholbach> tjaalton: yes, for both
<tjaalton> ok
 * dholbach gets more tea in the meantime
<dholbach> ... if only booting was faster! ;-)
<tjaalton> sucky bios vendors ftl
<dholbach> tjaalton: yay... now both kernels don't work with "splash" :-)
<tjaalton> dholbach: touchÃ©
<tjaalton> so bug kees :)
<mjg59> dholbach: When the screen is black?
<dholbach> mjg59: right after usplash it's flickering a bit, but stays black - or what is your questions?
<dholbach> question
<mjg59> dholbach: You run usplash, it turns the screen black. You then do vbetool vgamode 3 - what happens?
<dholbach> mjg59: it gives me the tty back and says "Function not supported"
<mjg59> dholbach: So it makes the screen turn back on?
<dholbach> mjg59: yeah
<mjg59> If so, it's a usplash bug - it should be doing exactly the same thing
<dholbach> thanks a bunch mjg59
<dholbach> mjg59: I passed the message on to kees
<dholbach> thanks mjg59, tjaalton, apw - the world definitely needs more people like you :)
<tjaalton> dholbach: heh
<Ng> smb_tp: hey
<smb_tp> Ng, Hi
<Ng> smb_tp: did the sparc fix we were discussing the other day with fabbio make it into the archive yet? :)
<Ng> istr it was heading for -proposed?
<smb_tp> Ng, Into -proposed, yes
<Ng> aha, excellent
 * Ng goes hunting
<Ng> linux-image-2.6.24-23-sparc64_2.6.24-23.49_sparc.deb ?
<smb_tp> Ng, this should be the right version
<Ng> smb_tp: great, thanks
<smb_tp> Np
<Keybuk> smb_tp: could you join #ubuntu-meeting ?
<pgraner> sconklin: book the tix... arrive Thurs AM (or Wed PM your choice), leave Fri PM. Stay near the Airport
<pgraner> sconklin: also book a rental car
<pgraner> -EWRONGCHANNEL
<maco> when a patch that ubuntu has committed stops being needed because it's accepted upsteam, is it automatically removed by you guys, or do you need to be told it's been added upstream?
<smb_tp> maco, We will normally detect this as long as the upstream version is not completely different. In that case a hint is always appreciated.
<maco> ok
<dholbach> hiya
<dholbach> what is our answer to people with a broadcom 4312 card in intrepid?
<rtg> dholbach: LRM works, though its a blob
<dholbach> rtg: ok.. I'll check out what's happening here
<dholbach> rtg: seems it's not stock ubuntu and it wasn't there - thanks again
<rtg> dholbach: what do you mean its not stock ubuntu? linux-restricted-modules contains the broadcom device driver.
<dholbach> rtg: it's an Ubuntu derivative who ship their own lrm-eeepc-something
<dholbach> rtg: it's called "easy-peasy"
<dholbach> ha
<rtg> oh, ok
<CarlFK> how do I disable cpu scaling? 
<Kano> hi rtg , i mailed you about qc-usb, i fixed the compile error but could not test it yet, but as it worked maybe before it should do too. i only added the new driver because i tested that first and it was working well.
<IntuitiveNipple> Do we have a plan to fix the ehci/uhci load order bug # 296710 that causes USB2 (480mbs) devices to run at USB1 speed (11mbps) ? I just got stung by this copying a 23G file-system image from an external USB drive, wondering why it was taking so long. (dd reported 7.9MB/s instead of the usual 29MB/s)
#ubuntu-kernel 2009-02-11
<maco> discussing kernel bugs goes in the "kernel development discussion" category, right?
<soren> Usually.
<maco> so how should i go about debugging an issue with a hotkey that apparently is kernel-level because input_events and acpi_listen both say nothing's going on when i press the key?
<mnemo> there is something weird happening with the kernel source package... I get this --> http://rafb.net/p/hSVkME70.html
<mnemo> but some other people are not getting that problem
<mnemo> (im using "main server" in apt software sources config)
<TheMuso> mnemo: You are better off fetching the linux source either from git, or with linux=2.6.28-7.20 for example.
<mnemo> but the git might contain some patches that are not in my binary right? because I assume a new package is generated automatically every time someting is commited to the git tree?
<mnemo> TheMuso: what you mean exactly when you say "use linux=2.6.28-7.20" ??
<TheMuso> mnemo: You use the source package name linux, and you are giving an exact version number, so apt-get doesn't get confused and look up the first partial match it finds.
<TheMuso> mnemo: I don't know how the kernel team do PPA uploads, but what is in git now may not be in the binaries that are in the archive.
<TheMuso> More to the point, I don't know how often they upload to PPAs etc.
<mnemo> ok, makes sense
<mnemo> but what would be the full apt-get command line for doing the linux=2.6.28-7.20 trick?
<TheMuso> apt-get source linux=2.6.28-7.20 as of the latest upload from the kernel team in the archive.
<mnemo> how did you find that number? I mean if I want to do this again later on
<TheMuso> mnemo: Best place to check is launchpad, http://launchpad.net/ubuntu/+source/linux
<mnemo> ok thanks
<TheMuso> You're welcome.
 * TheMuso sighs. Ok, that should be the final ports upload for now, and should get us binaries on most if not all ports architectures.
<TheMuso> All arches would be nice, but there may yet be unknown FTBF issues on ia64, sparc, or hppa.
<persia> I'm working on the Jaunty LPIA alternate CD, and have run into issues with not being able to load the CD-ROM driver after first boot under KVM.  It was suggested that this may be a missing kernel module in the udebs, but I'm not seeing much variance in the set of modules built between the regular kernel and the lpia kernel in the debian/d-i/modules directory.  Could someone help me track down this issue, or redirect me to the appropriate foru
<persia> m?
<johan> What can I do to get a vmlinux file for my standard ubuntu kernel?
<johan> Do I have to rebuild the kernel and extract that file from the source tree? Or is there a way to extract a vmlinux out of a vmlinuz?
<soren> johan: It's just a gzipped vmlinux, I believe.
<johan> soren: google tells me there are no known tools to extract it
<soren> gzip?
<johan> I'd guess that the symbols are also stripped
<rtg> johan: there are still enough symbols to load modules.
<johan> rtg: yes, but not enough to get useful information out of oprofile
<rtg> other then the exported public symbols, then yes you are correct
<johan> there used to be linux-image-debug kernels just for that, but appears they're not updated any longer
<rtg> johan: IIRC, Hardy is the last release that produced debug kernels
<johan> rtg: is there a reason they can't be built and put on ddeb.ubuntu.com for instance?
<rtg> I think we determined that it was a lot of build/space overhead for little benefit. no one seemed to be using them.
<johan> it's pretty useful to have them for tools like systemtap/oprofile
<Keybuk> nyargh!
<Keybuk> the kernel's silly fd interfaces never cease to annoy me
<Keybuk> they're implemented as streams, yet don't behave like streams
<Keybuk> you can't just read part of the data into a buffer, it returns -EINVAL if the buffer is too small for the struct
<Keybuk> but you can over-read multiple structs in one read
<Keybuk> should so be a msgbuf instead
<Kano> hi rtg 
<rtg> Kano: you're on my todo list for tomorrow
 * laga blinks
<Kano> thats a tiny patch against the driver you already have, i tested it as external compile hack, it compiled
<Kano> but the user with the webcam did not appear, all i can say it compiled
<rtg> Kano: if it doesn't fix anything, then why bother
<Kano> it fixes the compilation,the tiny patch i gave you in the last mail
<Kano> i guess it could work
<Kano> it was always the same abi change
<Kano> so i guess the patch is correct
#ubuntu-kernel 2009-02-12
<praveen_> i want to know abt trace flag and i need some pointers\
<lesshaste> hi
<lesshaste> I am trying to produce some debugging info for kernel panics I get the whole time
<lesshaste> is this the right way to run kexec?
<lesshaste> sudo kexec -p /boot/vmlinuz-2.6.27-11-generic --initrd /boot/initrd.img-2.6.27-11-generic --append="root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23 ro
<lesshaste> no one in?
<lesshaste> it seems the root= option is wrong for some reason
<lesshaste> I get
<lesshaste> Cannot open `--append=root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23': No such file or directory
<mnemo> you got an unmatched " in there
<lesshaste> mnemo, yes sorry.. sudo kexec -p /boot/vmlinuz-2.6.27-11-generic --initrd /boot/initrd.img-2.6.27-11-generic --append="root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23"
<lesshaste> gives
<lesshaste> Cannot open `--append=root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23': No such file or directory
<lesshaste> mnemo, so I must just have it completely wrong
<lesshaste> hi Wellark 
<mnemo> so you have one kernel that gives you panic and one that works?
<lesshaste> mnemo, no.. I have one that panics every day or so
<lesshaste> mnemo, I don't have one that obviously doesn't panic
<mnemo> usually you do "kexec -l kern_img"
<lesshaste> mnemo, right.. did you see my attempt at the command line above?#
<mnemo> yeah thats the thing, you dont have any -l  ??
<lesshaste> mnemo, no I am using -p
<lesshaste> mnemo, but check out
<lesshaste> http://www.mjmwired.net/kernel/Documentation/kdump/kdump.txt
<lesshaste> the instructions are to do
<lesshaste>   kexec -p <dump-capture-kernel-bzImage> --initrd=<initrd-for-dump-capture-kernel> --append="root=<root-dev> <arch-specific-options>"
<lesshaste> so my line is sudo kexec -p /boot/vmlinuz-2.6.27-11-generic --initrd /boot/initrd.img-2.6.27-11-generic --append="root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23"
<lesshaste> clearly I have the root= part completely wrong
<lesshaste> but I don't understand as that is what I have in menu.lst for grub
<lesshaste> and cat /proc/cmdline gives me  cat /proc/cmdline 
<lesshaste> root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23 ro quiet splash crashkernel=64M@16M
<mnemo> I think the --append part is fine... I think you forgot some other part so that its assuming that "--appendBLAH" is the filename
<mnemo> but check out "man kexec"
<mnemo> it says "kexec -l img" but for -p it doesnt say "kexec -p img" it just says "kexec -p"
<lesshaste> mnemo, sudo kexec -l /boot/vmlinuz-2.6.27-11-generic --initrd /boot/initrd.img-2.6.27-11-generic --append="root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23"
<lesshaste> Cannot open `--append=root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23': No such file or directory
<mnemo> i dunno, I have never used of kexec before so im really the wrong person to ask :) :)
<lesshaste> it doesn't make any differnce
<lesshaste> I have the syntax wrong
<mnemo> lesshaste: jaunty will have automatic ops crash reporting at least
<mnemo> but I guess that's a long time to wait just to report it ;o
<lesshaste> mnemo, you see in the man page it says " Passing  the  exact  contents  of
<lesshaste>        /proc/cmdline into command-line-options is the  safest  way  to  ensure
<lesshaste>        that correct values are passed to the rebooting kernel.
<lesshaste> "
<lesshaste> so I have
<lesshaste>  sudo kexec -l /boot/vmlinuz-2.6.27-11-generic --initrd /boot/initrd.img-2.6.27-11-generic --append="root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23 ro quiet splash crashkernel=64M@16M"
<lesshaste> and that is wrong apparently!
<lesshaste> grrr!
<mnemo> try --command-line=BLAH instead of --append=BLAH then?
<IntuitiveNipple> Are you missing "--args-linux" before --append ?
<lool> TheMuso: Hey, I checked the build failures of linux-ports on various arches; it seems we want to enable makedumpfile on more arches: kexec-tools is needed first on armel lp #323634, I don't know about hppa, powerpc and amd64 needs the bdep to be updated from makedumpfile [i386] to makedumpfile [!armel]
<lool> and I don't know about ia64
<lesshaste> IntuitiveNipple, it's not in the compressed kernel version at http://www.mjmwired.net/kernel/Documentation/kdump/kdump.txt
<TheMuso> lool: makedumpfile is only available for i386 powerpc ia64 and lpia, ports does not build any armel kernels.
<TheMuso> lool: ia64 makedumpfile fails, same with powerpc
<TheMuso> lool: haven't investigated why, just want them to build for now.
<lesshaste> IntuitiveNipple, ok this is just weird
<lesshaste> sudo kexec -l /boot/vmlinuz-2.6.27-11-generic --initrd /boot/initrd.img-2.6.27-11-generic --args-linux --append="root=UUID=7d9f52a6-3632-41cc-aa41-67534f3cdd23 ro quiet splash crashkernel=64M@16M"
<lesshaste> Cannot open `--args-linux': No such file or directory
<lesshaste> hi Lure 
<mnemo> lesshaste: you should use "--initrd=BLAH" instead of "--initrd BLAH"
<lesshaste> gaaaaaah!
<TheMuso> lool: again we don't build amd64 kernels with ports
<lesshaste> thanks :))
<mnemo> np :)
<lool> TheMuso: Ok
<lesshaste> blimey that took a long time
<lool> TheMuso: I had in mind that you could probably keep a very similar bdep as the main kernel which should reflect arches where makedumpfile should theoritically be available and only disable it in the rules, but it's fine like that; thanks
<lool> TheMuso: Also, I was curious whether you plan to move the tree to ubuntu/ like the other in-archive trees?  or is this reserved to a special team?
<TheMuso> lool: ubuntu/ is only for the kernel team afaik, I don't have access to it. In addition, the kernel team don't want very much to do with ports, so I don't know what will be happening about where the official prts tree will end up.
<TheMuso> So I am keeping it under my own namespace currently.
<lool> TheMuso: Is there a way to share access to this tree to others (I think NCommander also contributed to the git tree?!?)
<TheMuso> lool: unless everyone has ubuntu/ access, the easiest way is to create one's own tree, and ask me to merge/pull changes I guess. I know NCommander has done ports work before, but that was for intrepid/early jaunty, and ports is now maintained somewhat differently (how the lpia kernel was maintained before it was included into mainline jaunty).
<lool> TheMuso: Understood
<TheMuso> lool: If things work out with me maintaining ports in my own time, and if others want to help work on ports, there may be grounds to making a team that has access to something like ubuntu-ports or something similar.
<lesshaste> how do ubuntu kernel people normally try to diagnose kernel panics?
<lesshaste> hi Lure 
<lesshaste> hi abogani 
<rtg> amitk: where are you on the config file hierarchy changes and the ARM config file updates?
<rtg> I thought I'd take a stab at getting LPIA into the Jaunty archive today.
<amitk> rtg: Almost done
<amitk> rtg: 10 mins to finish build testing
<rtg> amitk: no rush, I've plenty of other minutia to keep me busy
<amitk> rtg: it is an abi bumper
<amitk> i guess it will be for lpia in any case
<rtg> amitk: I had planned on bumping ABI anyway 'cause I want to tuurn on CRDA
<IntuitiveNipple> rtg: possible regression in Intrepid (ath5k); you might want to cast an eye over it: bug #327237
<ubot3> Malone bug 327237 in linux "Kernel 2.6.27-11 in 8.10 has no WiFi support" [Undecided,New] https://launchpad.net/bugs/327237
<amitk> rtg: changes compiled successsfully and pushed out to git
<rtg> IntuitiveNipple: contact smb_tp as he is responsible for maintenance and regressions.
<rtg> amitk: thanks
<IntuitiveNipple> okay
<smb_tp> IntuitiveNipple, I look at it
<IntuitiveNipple> smb_tp: thanks.
<maxb> Hmm... madwifi and ath5k both loaded in that intrepid bug - is that badness?
<rtg> yep - madwifi borks the hardware. there is a pending bug fix which includes blacklisting madwifi
<smb_tp> rtg, So was madwifi not there before?
<rtg> it ought to have been, but its kind of racy.
<maxb> The wifi%d line looks a bit odd too - %d not being interpolated?
<IntuitiveNipple> maxb: yeah, and that is generated by ath9k :p
<IntuitiveNipple> (drivers/net/wireless/ath9k/core.c:1127)
<maxb> The pending fix leaves things jockey-able, right? I have some hardware which works with madwifi but not ath5k
<amitk> rtg: are you looking at https://bugs.edge.launchpad.net/ubuntu/+source/ixp4xx-microcode/+bug/328188 
<ubot3> Malone bug 328188 in ixp4xx-microcode "please include firmware from ixp4xx-microcode in the linux-firmware package for armel" [Undecided,New] 
<rtg> amitk: not yet. you wanna do it?
<amitk> rtg: not sure what needs doing...
<rtg> amitk: ok, I'll get to it as I think I'm assigned the bug
<amitk> just add the firmware to the jaunty/firmware directory?
<amitk> rtg: ^
<rtg> and make sure the license/copyright stuff gets added to the package
 * amitk looks at how the firmware udeb is created
<smb_tp> IntuitiveNipple, Actually the message comes from lrm:ubuntu-restricted/madwifi/ath/if_ath.c:446
<IntuitiveNipple> smb_tp: really? oh, duplicates then! I thought it seemed strange every module trying to grab it :)
<smb_tp> They are quite similar. :)
<IntuitiveNipple> My brain's mush... didn't go to bed last night so only just functioning right now 
<rtg> smb_tp: uh, the bug I was thinking about is https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/208137, but its the same solution for madwifi v.s. ath5k.
<ubot3> Malone bug 208137 in module-init-tools "Add vt8623fb to blacklisted framebuffer drivers" [Medium,In progress] 
<rtg> In fact, shouldn't jockey handle this?
<smb_tp> rtg, So, the solution would be to blacklist madwifi and jockey should handle/load it if required?
<rtg> smb_tp: actually, if they just ran jockey it ought to do the right thing.
<tjaalton> any idea why the qla2xxx driver takes one minute to initialize?
<tjaalton> on jaunty
<tjaalton> the default rootdelay is 30 seconds, so unless I change it the boot fails
<tjaalton> this is a blade server with a dual-HBA adapter
<tjaalton> -adapter
<tjaalton> [   62.940070] qla2xxx 0000:13:00.0: Firmware image unavailable.
<tjaalton> maybe that has something to do with it?
<rtg> tjaalton: but it eventually works?
<tjaalton> yes
<rtg> tjaalton: well, start a bug report and attach dmesg. maybe we can eyeball it from the driver source
<tjaalton> rtg: yeah, started already
<rtg> tjaalton: I've got a server that is totally wedging, it looks like igb. It started yesterday after a BIOS update and perhaps an update to the latest Jaunty -7 kernel.
<rtg> I should try nomsi
<tjaalton> rtg: this has happened since I started testing multipath-booting (late december)
<rtg> tjaalton: ah, nothing really new then. have you bugged upstream?
<tjaalton> rtg: haven't had time yet, fixed multipath-tools first so it actually boots up without manual intervention
<rtg> biab, have to get close to my server in another room
<tjaalton> it could be that the slow initialization is normal in this case, since there are so many paths to the device (8)
<tjaalton> rtg: filed bug 328550
<ubot3> Malone bug 328550 in linux "qla2xxx takes ~one minute to initialize per device" [Undecided,New] https://launchpad.net/bugs/328550
<tjaalton> wtf? apt-getting the source for linux-image-2.6.28-7-generic fetches the meta-package
<mnemo> i told you yesterday timo :)
<tjaalton> mnemo: yes, maybe our mirror was the one that was outdated :)
<tjaalton> since I couldn't reproduce it then
<mnemo> hehe yea
<mnemo> anyway I worked around it with:
<mnemo> apt-get source linux=2.6.28-7.20
<tjaalton> thanks
<tjaalton> rtg: do you know the contact point for qla2xxx upstream?
<rtg> tjaalton: doesn't appear to be in the MAINTAINERS file. You might try sending an email to James Bottomley
<tjaalton> rtg: actually, Andrew Vasquez looks like a better match :)
<tjaalton> rtg: ok, got a reply already. they'd like it not to complain about the firmware :)
<tjaalton> but I'm not sure if the initramfs has it or not
<tjaalton> update-initramfs complains as well
<smb_tp> tjaalton, Actually I would suspect that getting linux-meta as the source for linux-image-2.6.28-7-generic is sort of the right thing
<tjaalton> smb_tp: but that only happens as of a few days ago
<tjaalton> or yesterday
<tjaalton> the docs still suggest to do that when trying out patches
<tjaalton> anyway, the qla2xxx still complains even if I copy the firmware in /l/f/2.6.28-7-server
<smb_tp> Which is rather strange. That linux-image-2.6.28-7-generic is a meta-package itself and the source of that is linux-meta
<tjaalton> no it isn't :)
<tjaalton> but maybe it's the new apt that does this
<tjaalton> the source of the image is 'linux', and the source for it is 'linux-meta'
<tjaalton> so the resolver is different now
<smb_tp> tjaalton, Hrm, yeah. You are so right. It just sounded like the linux-restricted-modules trap I fall into so often
<tjaalton> hehe
<tjaalton> sigh, the qla2xxx driver still complains even if I copy the fw to /l/f
<tjaalton> bbl
<Kano> rtg: http://kanotix.com/files/kernel/unused-patches/2.6.28-ubuntu-qc-usb-compile-fix.patch
<Kano> dont forget this one
<Kano> a x-fi driver would be interesting too
<Keybuk> ok
<Keybuk> something is definitely, absolutely, officially wrong with I/O in 2.6.28
<Kano> whats your problem?
<Keybuk> Kano: every single bootchart shows almost continuous IO, with one core continually in I/O wait, and no process claiming it
<Keybuk> not limited to any particular machine either
<Kano> ah
<Kano> and 2.6.27 or .29 rc is different?
<Keybuk> the intrepid kernel does not show it
<rtg> Keybuk: can you try the server kernel? Its got a different I/O sched setting, e.g., deadline 
<Keybuk> sure
<elmo> or just boot with elevator=deadline
<tjaalton> rtg: any idea why the qla2xxx driver still complains about the missing firmware even if I copy it to /lib/firmware (and repack the initramfs)?
<rtg> elmo: well, there are some other differences as well, like the time slice quanta
<elmo> rtg: ah, ok
<rtg> tjaalton: not off the top of my head. are you sure the name is right?
<tjaalton> rtg: checking
<tjaalton> rtg: yep, correct name
<rtg> tjaalton: uh, gimme a bit. I'm in the middle of horking in 2.6.28.5
<tjaalton> rtg: sure
<Keybuk> rtg: mad I/O still shows up with -server
<rtg> hmm, that sucks.
<rtg> q:q!
<rohan> https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting --> the script provided here for stress testing suspend/resume is meant to be run on which distribution?
<rohan> or is it distro agnostic?
<rtg> apw:  ^^
<apw> rohan, it mostly relies on pm-suspend existing.  it has one gnome specific test which uses dbus to initiate a suspend for a more complete test
<apw> but that test not working is not fatal, and occurs on kde
<rohan> apw: ok, so i can use it on kubuntu 8.04?
<apw> the failure reporting to launchpad only occurs on the latest jaunty installs and is tied into apport
<apw> i have run it on 8.04, it will not report back to launchpad automatically on failure there, but still is expected to work
<apw> if it does not contact me and i'll see what i can do to make it so do
<rohan> ok, thanks
<apw> np
<rtg> tjaalton: can you build a kernel? strip the DEBUG2 macro from line 2711 of drivers/scsi/qla2xxx/qla_os.c
<tjaalton> rtg: sure, and it shouldn't take long since the beast has eight cores
<rtg> tjaalton: it looks like that _has_ to be the failure point.
<rtg> tjaalton: you could also modprobe it with ql2xextended_error_logging=1
<rtg> use break=top to catch it in initramfs
<tjaalton> rtg: if it was set to use the serial port for console, I could. I'll try building the kernel first
<rtg> k
<tjaalton> hmm, so remove those two lines?
<rtg> tjaalton: no, unwrap the DEBUG2 macro so that it prints something
<tjaalton> oh, heh
<tjaalton> let's see
<rtg> this is in the qla2x00_request_firmware() function, just to make sure we're looking at the same sources.
<tjaalton> yep
<tjaalton> rtg: [   63.010090] scsi(0): Failed to load firmware image (ql2400_fw.bin).
<tjaalton> rtg: note that the image is not normally on the initrd at all
<tjaalton> ..and actually I didn't remember to copy it manually either
<rtg> tjaalton: doh! that might have something to do with it. I wonder if there is an option to build it in. lemme check
<tjaalton> update-initramfs complains about the firmwares
<tjaalton> W: Possible missing firmware /lib/firmware/2.6.28-7-server/ql2500_fw.bin for module qla2xxx
<tjaalton> etc
<rtg> tjaalton: thats cause it should be /lib/firmware/ql2500_fw.bin
<tjaalton> rtg: that's where they actually are
<tjaalton> I'll repack the initrd with the firmware in /l/f
<tjaalton> and according to dmesg it really is waiting one minute for the firmware
<tjaalton> rtg: same error message with the firmware in /lib/firmware
<rtg> tjaalton: ok, I'll dig deeper, but its gonna have to wait until tomorrow.
<tjaalton> rtg: take your time :)
<tjaalton> rtg: qlogic guy says that redhat has a similar problem related to udev, and he'll get back to me later
<tjaalton> rtg: got a reply; "This is an issue with the initrd (initramfs) infrastructure not supporting the request_firmware() interface."
<tjaalton> "Basically, the 60 second lag time is the request_firmware() call timing out due to udev being unable to satisfy the call to load firmware"
<rtg> tjaalton: seems like we ought to be able to get initramfs to do the right thing.
#ubuntu-kernel 2009-02-13
<bullgard4> [Symmetrical Multiprocessing, SMP]: Is there a tool that shows if an application program uses both processors on a particular two-processor SMP machine?
<lifeless> bullgard4: do you mean 'does it have threads' ?
<bullgard4> lifeless: No. I imagine that an application may either be processed by only one processor or by both.
<stgraber> no, if your application has a single process it can't be using two CPUs
<lifeless> stgraber: it can get scheduled to both, just not concurrently :P
<stgraber> lifeless: right :)
<lifeless> bullgard4: your question is essentially ill-defined in kernel terms, heck, even application isn't that well defined (I know single apps that have 10's of different images with 100's of processes active concurrently)
<lifeless> bullgard4: I'm sure you are asking this as part of answering some larger issue/project - perhaps some context about that will help us answer you 
<bullgard4> May be referring to a more specific case will help me better to understand. Does pbzip2 load the two processor kernels while gzip, bzip2 do load only one?
<lifeless> bullgard4: pbzip2 is probably threaded, so the kernel can schedule it onto multiple CPU's at once
<lifeless> gzip and bzip2 are single threaded and can only be scheduled on a single cpu at a time
<bullgard4> lifeless, stgraber: Thank you very much for your help. 
<Kano> hi, why does 2.6.28-8 depend on wireless-crda which is only in universe?
<Kano> remove that depend please...
<ivoks> is there a change hardy's latest kernel was compiled with an older version of gcc that we have in repository?
<ivoks> which would make building kernel modules impossible?
<persia> ivoks, Older version, no.  Older revision, yes.  It was built with the gcc that was available at the time it was built.
<ivoks> persia: i'm aware of that...
<ivoks> but, we can't build kernel modules if kernel doesn't get rebuild
<ivoks> gcc in hardy is 4.2.4
<ivoks> it was updates couple of months ago
<ivoks> yet, the kernel is compiled with 4.2.3
<persia> Hrm?
 * persia looks
<Kano> depends, you can even build the kernel with gcc 4.1.1 and then compile modules with 4.3
<Kano> just not the other way around
<persia> ivoks, Which arch?
<ivoks> persia: i386
<Kano> but then the linux-headers are not installable
<persia> ivoks, For some reason I can't find the build log for 23.48, apparently in part because it's a security update.  Sorry not to be able to help.
<ivoks> persia: right, that was security update
<ivoks> persia: bug 292381
<ubot3> Malone bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,Triaged] https://launchpad.net/bugs/292381
<persia> ivoks, It may well have been built against 4.2.3 then, as I believe -security only has 4.2.3 and -updates has 4.2.4.  
<persia> ivoks, Trick being that for people only tracking -security, I think 4.2.3 is correct.
<ivoks> i understand that
<ivoks> that's a gcc bug
<ivoks> gcc should never get version change during release
<persia> Or at least never get any sort of ABI change.
<persia> The version string isn't the important part.
<ivoks> well
<ivoks> i just did more digging
<ivoks> kernel's 64bit buildd doesn't have gcc 4.2.4
<ivoks> while 32bit buildd does
<persia> ivoks, Found it: http://launchpadlibrarian.net/21747228/buildlog_ubuntu-hardy-i386.linux_2.6.24-23.48_FULLYBUILT.txt.gz shows gcc-4.2_4.2.3-2ubuntu7 : it's entirely due to skew between -updates and -security.
<persia> Either needs two different kernels (one for -updates and one for -security) or to not have impactful variation.
<ivoks> correct
<lukehasnoname> I would be interested in someone could solve this problem:
<lukehasnoname> http://www.nabble.com/Yaird-throws-error-about-bad-sr0-device-link-td21449825.html
<lukehasnoname> I know it's not Ubuntu-kernel related, but perhaps it's a slow morning for someone who wants to help me out
<soren> Why use yaird? What does it do that mkinitramfs doesn't?
<lukehasnoname> >_> I'm using a video tutorial which stated using that tool. I'm not familiar with kernel building.
<lukehasnoname> I googled the error I was getting and found that ml archive
<alex_joni> lukehasnoname: googling I found some people having to update to a newer yaird version (with erros similar to yours), but I would do as soren suggest.. use mkinitramfs
<lukehasnoname> I'll try it later. I've been awake 24 hours in studying for tests and finishing up a project proposal
<lukehasnoname> thanks 
<ivoks> hi... are there any plans to support more than 8 cpus in hardy?
<rtg> ivoks: debian/config/amd64/config.server:CONFIG_NR_CPUS=64
<ivoks> ah, right
<ivoks> so, only i386 supports 8
<rtg> correct
<ivoks> thanks
<persia> rtg, WIth the lpia kernel merge, does linux-lpia now have the same modules and udebs as i386/amd64 or are there significant differences?
<rtg> persia: udebs should be pretty close, but I'm not sure about all of the modules. The configs came over intact, so that likely hasn't changed.
<persia> Thanks.  I'm thinking some bugs I was thinking of filing may have become obsolete, but I'll retest, and maybe file.
<rtg> persia: who is the archive admin today? I need to get wireless-crda promoted to main
<persia> rtg, You already have an approved MIR?
<rtg> yep, hang on.
<persia> https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days says nobody is the offical archive-admin on Fridays.
<rtg> persia: which is why I asked
<rtg> https://bugs.launchpad.net/ubuntu/+bug/325801
<ubot3> Malone bug 325801 in ubuntu "Main inclusion request: wireless-crda" [Undecided,In progress] 
<persia> So just beg in #u-d and any of the team might be able to help (including the few who don't have days).
<persia> Theoretically anyone in https://launchpad.net/~ubuntu-archive/+members ought to be able to do it.
<rtg> persia: thanks, I'll see whom I can annoy.
<rtg> actually, I thought you were on that list.
<persia> No.  I signed up for enough of those "it sounded like a good idea at the time, but it's a bunch of work" things already :)
<rtg> I hear yuo :)
<Kano> rtg: you forgot my patch, you only need to apply it then you get a quickcam.ko as you still have it enabled in the config
<rtg> I did not forget, I just didn't do it yet.
<Kano> also i had to revert one config
<Kano> as you depend on something now which is only in jaunty universe
<Kano> wireless-crda is not even in main...
<Kano> of course i used =y
<Kano> and removed that depend
<BUGabundo> hi
<BUGabundo> is any kernel dev awake around here?
<BUGabundo> if it wasn't to much trouble
<BUGabundo> could some one take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/329254
<ubot3> Malone bug 329254 in linux "kernel: [  341.030356] Pid: 0, comm: swapper Tainted: P        W  2.6.28-7-generic #20-Ubuntu" [Undecided,New] 
#ubuntu-kernel 2009-02-14
<lamont> EDAC MC0: CE page 0x838dd, offset 0x0, grain 4096, syndrome 0x20, row 2, channel 0, label "": e7xxx CE
<lamont> wassat mean?
<IntuitiveNipple> RAM ECC error
<IntuitiveNipple> "CE" means "corrected error"
<domas> hello!!! http://p.defau.lt/?ILkL1opB2Tcs4iaRCW50pQ <-- do high Slab/SUnreclaim values mean I have memory leak in kernel somewhere?
<domas> (slabinfo shows lots of generic kmallocs)
<domas> oh, I know what causes that
<domas> I switched locking from futex to fcntl()
#ubuntu-kernel 2009-02-15
<silv3r_m001> hi there
<silv3r_m001> which file contains the definition of  GdkAppLaunchContext
<silv3r_m001> or which header file contains it declaration
<TheMuso> silv3r_m001: Unless you are referring to the kernel's GTK configuration interface, I don't think the Linux kernel has GTK code in it.
<Ng> is it known that 2.6.27-11 has a thinkpad brightness control regression?
<Ng> I'm just tidying up some duplicate bugs atm and I'm wondering if there's a particular one I should dupe them to
<Ng> ah, bug 311716
<ubot3> Malone bug 311716 in linux "The slider brightness Applet has value inverted after the last update (2.6.27-11)" [Medium,Fix released] https://launchpad.net/bugs/311716
<Ng> hmm, except that bug released an older kernel than I have now.
#ubuntu-kernel 2010-02-15
<|MA|> hi all
<|MA|> I have a kernel buil related issue
<|MA|> http://paste.ubuntu.com/376717/
<|MA|> any thoughts how i can fix it ?
<smb> Install ncurses-dev
<|MA|> libncurses5-dev is already the newest version.
<|MA|> 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
<ghostcube> smb: i send him here cause i didnt know how to help any firther :)
<ghostcube> further even
<smb> Maybe some other headers it does not complain about... 
<smb> Like complete build-essentials...
<|MA|> E: Couldn't find package build-essentials
<smb> Err, sorry without s at the end
<smb> build-essential
<|MA|> build-essential is already the newest version.
<|MA|> 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
<|MA|> I did even build the kernel 2 days back
<smb> Is your pastebin output all that gets out? Tried "make V=1 menuconfig"
<|MA|> running that too ... Linux manu-04 2.6.31.6-ma3 #1 SMP Sat Feb 13 14:16:22 GST 2010 x86_64 GNU/Linux
<|MA|> since yesterday, it is behaving thus
<smb> Is /usr/include/ncurses.h still there?
<|MA|> ok, here it is: http://paste.ubuntu.com/376736/
<|MA|> http://paste.ubuntu.com/376737/
<|MA|> It is there, yes
<smb> For me that would be a link (which could be broken) but to get the real error you might temporarily edit linux-source-2.6.31/scripts/kconfig/lxdialog/check-lxdialog.sh
<smb> and remove the 2>/dev/null in that line $cc -xc - -o $tmp 2>/dev/null <<'EOF'
<|MA|> I will temporarily comment it out
<smb> The line itselfs must be there
<|MA|> http://paste.ubuntu.com/376741/
<smb> Sounds like you did the wrong thing to the script
<|MA|> only the 2> ... ?
<|MA|> let me try again
<smb> check() {
<smb>         # $cc -xc - -o $tmp 2>/dev/null <<'EOF'
<smb>         $cc -xc - -o $tmp <<'EOF'
<smb> or like that
<|MA|> wow, it comes up again.. let me but paste you the output
<|MA|> http://paste.ubuntu.com/376742/
<|MA|> thanks
<smb> Hm, not really what we wanted
<smb> In theory this should just let the error messages go past
<|MA|> but it now works at least
<smb> Can you do a make clean and then a make with V=1 again?
<|MA|> sure, moment
<|MA|> here it is: http://paste.ubuntu.com/376746/
<|MA|> this is with the commented out stuff in the kernel build script
<smb> Hm, now your lines between check() and the include might be interesting. But one other thing, I saw you do a sudo. Might it be you just have a permissions problem? Like written the directory as root?
<|MA|> not a permissions problem. Was doing everything with sudo
<|MA|> except for the one in between
<smb> Ok (though feels a bit dangerous to me, but then not the problem). Can you paste me your lines of the check script then? Should only be three or four so the channel is ok
<|MA|> here it is : http://paste.ubuntu.com/376750/
<smb> Its quite weird, the change only should make the error messages from the check script go to stderr instead of being suppressed. And the check itself looks at the error code from the call, which should be unaffected. So between before and after it still should fail the same.
<|MA|> but now it works for me
<smb> Does changing the cc line into "$cc -xc - -o $tmp 2>/tmp/check.log <<'EOF'" make a difference?
<|MA|> you mean reverting back ?
<smb> Partially. Instead of writing to /dev/null write to /tmp/check.log
<smb> Which brings up a weird thought. What does 'ls -la /dev/null' produce?
<|MA|> manu@manu-04:/usr/src/linux-source-2.6.31$ ls -la /dev/null
<|MA|> crw-rw-rw- 1 root root 1, 3 2010-02-15 00:13 /dev/null
<smb> Ok, nothing wrong with that
<|MA|> ok, works as well, with the changed script
<smb> I bet, if you change it back to how it was, it works as well
<|MA|> nothing in /tmp/check.log though
<smb> And actually, when I look at your initial posting:
<smb> manu@manu-04:/usr/src/linux-source-2.6.31$ make menuconfig
<smb> ^ no sudo there
<|MA|> uh
<|MA|> dang
<smb> :)
<|MA|> but :
<|MA|> changed back
<|MA|> http://paste.ubuntu.com/376756/
<|MA|> same old thing
<|MA|> should i change it back to /tmp/foobar ?
<|MA|> eargh .... /me goes nuts
<smb> Seems like a very odd thing that writing to /dev/null would fail while other tings work
<|MA|> I am out of my wits end
<smb> And its probably something not too many try out as root. Most are to paranoid to have the compile run as root
<|MA|> my machine is a devel machine, where i err .. work on some drivers ... I am not too paranoid ... There were much more things to be paranoid such as HDD's getting fscked etc etc
<|MA|> -were +are
<|MA|> If i could get this thing up at the earliest i could get back to my work on some shiny new drivers ..
<|MA|> :)
<smb> True. And I usually have the tree not that way, so I would not notice oddness. I can try out to have it that way. One thing in general, have you ever tried to get the sources with "apt-get source linux-image-2.6.31-x-generic"? That way you also have the debian build environment with it and the default configs...
<smb> I'll try whether having the tree as root shows the same problems here
<|MA|> that's what I did initially, but I had to tweak some settings such as MSI-X and some others
<|MA|> as well as some more kernel hacks
<|MA|> that would be great. Thanks a lot
<|MA|> at least I am able to get back to get it up at least
<|MA|> Other than that, I am  a bit annoyed with the nvidia post install script as well. kernel install failed earlier, then i had to remove the nvidia-common package
<|MA|> which helped me to get the kernel installed
<|MA|> so many new hassles introduced ... wasting a lot of precious time
<smb> Yes, I'd probably use the /tmp/foo variant. You could base on apt-get source version for your work and make tweaks to debian.master/config 
<|MA|> also applications such as acroread doesn't work. You know: evince and such applications do not open all the PDF file formats, that's to add to the yuck's
<smb> Not sure what the problem with the post install is. But usually most things are set to work with the .debs produced by compiling the debian way.
<|MA|> all these made me pull out my hair a lot, it took me 2 days to get the system up, as opposed to a few hours as of earlier versions
<smb> And acroread, well... Seems to work for me, which is likely not much help
<|MA|> well anyway, I got to get it going with a virtual host machine and used acrobat reader there. No other alternative ...
<|MA|> since some of the document would open there alone, due to security reasons
<smb> security reasons? So a make menuconfig works for me here. Could it be you got some security framework active that might be over restrictive?
<|MA|> by security reasons, I mean protected documents from some people that i receive. Those documents seem to open only with acroread and hence.
<smb> ahh ok, misunderstanding there, then
<|MA|> some nastiness in those docs. They are sometimes password protected; then you can't copy/paste etc
<|MA|> so regular pdf readers don't handle all those stuff
<|MA|> and hence the document in some cases don't open up, or look like some Martian languages, like fully clobbered up
<|MA|> in short, if you seriously use PDF docs, acroread is in some case unavoidable
<smb> Had something like this. But in my case evince was able but acroread wasn't (due to fonts). But in generall acroread works on this system
<|MA|> unless other apps catch up
<smb> As well as I cannot reproduce your strange problem with the compile.
<|MA|> I have been going through real weirdness. Don't just remind me of it
<|MA|> and that too, when you just want to get something moving really fast
<smb> Unfortunately that happens usually whenever you want something done fast... :/
<|MA|> true: murphy is there to strike at will
<smb> One thing you could check is apparmour_status. Not really expecting something there, but...
<|MA|> I had disabled apparmour completely
<|MA|> not wanting to have such stuff on a development machine
<|MA|> i would more or less term it as an open frame machine ... ;-)
<|MA|> where i can swap the hardware, cards in really fast
<smb> Well, that should be possible with or without apparmor. :) But at least without it it cannot be any reason for strangeness
<|MA|> yup :)
<smb> Just for a test. When you are root. Can you do a echo bla >/dev/null?
<|MA|> sec
<|MA|> yes, i can 
<|MA|> manu@manu-04:~$ sudo echo blahblah >/dev/null
<|MA|> [sudo] password for manu:
<|MA|> manu@manu-04:~$
<smb> No, do the sudo -i before
<smb> That way null is opened as the user
<|MA|> yup
<|MA|> root@manu-04:~# echo blahblah >/dev/null
<|MA|> root@manu-04:~#
<smb> Then I must admit, I cannot really help as I have no clue what might be wrong, sorry.
<|MA|> but anyway, you have been a big help. At least I can get going on it
<|MA|> thanks again
<smb> Yeah, at least some workaround. Though it feels like "quick backup all your work, this machine is odd"...
<|MA|> I have all my work, except for the kernel builds on a completely separate hdd
<|MA|> even in case something causes a freeze and fscks my /
<smb> Ok, very reasonable for a development box. :)
<crimsun> ooh, exmap is fixed
#ubuntu-kernel 2010-02-16
<tjaalton> how to correctly rebuild the mainline kernel package? I'd try some nfs4 fixes on top of .33rc7
<tjaalton> oh there's rc8 too.. will check if they are already applied
<tjaalton> hmm no
<amitk> tjaalton: the scripts are in the kteam-tool.git repo on kernel.ubuntu.com
<amitk> apw might be able to help with details
<tjaalton> amitk: thanks, I'll have a look
<kermiac> hi, I'm looking through the info on the wiki for the kernel hugday. I understand that if the battery drains whilst suspended a crash report will be generated & these bugs can be set to invalid. Is there a standard reponse that should be used?
<apw> kermiac, hrm.  there might be some text you could use on the suspend/resume debugging page
<apw> as that i think is one of the things to ask
 * apw looks embarressed
<kermiac> yes, that's the first place I looked :)
<kermiac> I was just in the process of trying to put something together, but any help would be appreciated
<apw> yeah it does seem to be missing
<apw> if you want to post your suggestion here, then we can clean it up and get it in the wiki for next time :)
<kermiac> so far I came up with
<kermiac> Thank you for taking the time to report this bug and helping to make Ubuntu better. I am closing this bug report as this is expected behaviour when the battery drains whilst suspended. Please see https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Is%20this%20really%20a%20failure? for more information.
<kermiac> but that's still very rough
<kermiac> any suggestions for improving that?
<apw> I would change the sense round, so you give the reason first
<apw> (first and last sentence are fine as they are)
<apw> This report seems to indicate that your battery drained while the machine was suspended.  In this case a false bug report is generated, we are therefore closing this bug Invald.
<apw> something like that perhaps?
<kermiac> yes, that sounds good. perhaps we should merge the 2 so that the OP can still refer to the wiki?
<kermiac> or do you simply mean to replace the middle sentence with that?
<kermiac> Thank you for taking the time to report this bug and helping to make Ubuntu better. This report seems to indicate that your battery drained while the machine was suspended.  In this case a false bug report is generated, we are therefore closing this bug Invald.  Please see https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Is%20this%20really%20a%20failure? for more information.
<kermiac> I think that is good. I wasn't happy the middle part of my original text
<kermiac> ty for your help apw :)
<apw> yeah jus the middle sentence
<kermiac> if you're happy with that response, may I suggest we add that to the wiki for other triagers to use in the upcoming hugday?
<apw> looks good in the final form
<apw> kermiac, i am happy with that.  i suggest putting it in as a blockquote in the wiki page at the end of that section
<kermiac> apw: ok, will do. thanks again for your help :)
<Kano> hi apw 
<Kano> is it possible to backport sky2 from 2.6.33
<apw> nominally i am resistant to backports of anything we don't need, just for supportability ... is there a big gain from that?
<Kano> there are new laptops out with mavell 0x4381 id
<Kano> like samsung R780
<Kano> i tried to compile .33 but that kernel just rebooted...
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<Damascene> hello
<Damascene> any one can help with the function keys are not working again on Lucid?
<Damascene> It was almost fixed in Karmic but it's back on Lucid
<Damascene> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/232170
<ubot3> Malone bug 232170 in linux "EeePC Volume and Wireless Hotkeys Do Not Function Out-Of-The-Box with Ubuntu (8.04 Hardy LTS, Intrepid Alpha 1)" [Medium,Fix released] 
<Damascene> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/518007
<ubot3> Malone bug 518007 in linux "Asus Eee Function Keys (Hotkeys) are not working with Lucid 10.04" [Undecided,New] 
<bdmurray> mjg59: should hp-wmi be auto loaded on an HP Touchsmart TM2?  Additionally, I'm receiving an "Unknown key pressed - 2169" message in dmesg.
<mjg59> bdmurray: What kernel version?
<bdmurray> mjg59: 2.6.32-13-generic for Ubuntu
<mjg59> I'd expect it to be, assuming that it binds
<bdmurray> Hmm, okay well it didn't autoload and after loading it I get the unknown key pressed message for a "rotate screen" button
<mjg59> As far as the unknown key message, can you open a bug on bugzilla.kernel.org, assign it to mjg59-kernel@srcf.ucam.org and include the output of acpidump?
<mjg59> Ah, hang on
<mjg59> That's probably all I need
<mjg59> Ok. Can you pastebin the contents of /sys/class/wmi ?
<mjg59> Also, nnngh.
<mjg59> Three different definitions of rotate screen.
<bdmurray> there is no /sys/class/wmi, oh right hmm
<mjg59> Bizarre. I thought that patch went into .33.
<bdmurray> I'm on .32
<mjg59> Sorry, .32
<bdmurray> so what can I give you?
<mjg59> Well, autoloading won't work without the code to enable autoloading
<mjg59> Which seems to be in .33 but, presumably, not .32
<mjg59> Now I just need to figure out which key to assign that button to
<manjo> akgraner, ping 
<akgraner> manjo, pong
<manjo> akgraner, I am trying to locate a member of your loco who helped us in Atlanta .. he is a big guy with tattoos
<manjo> akgraner, he was in dallas UDS as well
<akgraner> manjo, ahh that itnet7 he's in the FL Loco  - looks like he is online now 
<akgraner> manjo, I just pinged him...  I'll send him your way if ya want..
<manjo> akgraner, thanks a ton 
<akgraner> manjo, just asked him to pop in here and ping you when he gets a chance - he's in the LoCo Council meeting right now..
<itnet7> manjo: need something?
<Kano> hi, which target builds libc header now
<JFo> itnet7, did manjo get back with you?
<manjo> JFo, yes
<JFo> excellent :-)
<itnet7> Thanks JFo !
<JFo> np itnet7 :)
<akgraner> manjo, ping
<manjo> akgraner, pong
<akgraner> manjo, see PM :-)
#ubuntu-kernel 2010-02-17
<apw> rtg, smb, in our udeb configuration is there any good reason that we don't have all modules as 'foo ?' we already are checking they don't go away without us noticing in the module-check ... so all it seems to be able to do is inflict pain on us
<smb> apw, Never much thought about that
<smb> They are just there
<manjo> bjf, regarding scale testing ... we should mod the wiki... you want me to go first and update the wiki ? 
<apw> yeah ... just trying to get armel-versatile to generate them and finding i need a lot of ?'s adding
<apw> and really cannot understand why given we have module loss checks elsewhere what we gain by not just adding ? to them all in all cases thoughout
<apw> (for d-i only of course)
<manjo> bjf, I will update it with the testing info 1st and you can go with the couch db setup next ? 
<smb> apw, Maybe those checks have been there before module checks and then stayed
<bjf> manjo, I'm really not all that hung up on the wiki for the testing as that seems to be mostly focused on how to setup the environment for us and not pointed at users
<apw> smb, yeah i am thinking that is likely the case
<manjo> apw, thanks I keep forgetting 
<bjf> manjo, though it needs to be documented, it can come later
<manjo> bjf, needs to happen before scale so that we can have a laptop setup with the wiki for people to follow
<manjo> anyone have any thoughts on this ? 
<bjf> manjo, I have a laptop with it all setup
<apw> manjo, depends if 'we' are going to be there and taking it with us?  in that case just the user instructions seem needed
<manjo> bjf, ok I will update the wiki then... and then test the netbooks I have here... if you could update the couch DB info that will be great
<bjf> manjo, don't let me hold you back from documenting it, it's just not my highest priority
<manjo> bjf, the tests seem to be fine when i ran it yesterday, I am just curious about the results transfer, I have not tried that, if it works for you and JFo then I am not that worried, althjough I would like to test that as well 
<JFo> I haven't looked at results transfer
<JFo> just making sure the images and tests work
<manjo> I just unboxed 3 netbooks and a fitpc2 and I would like to use those to do the testing etc 
<bjf> manjo, I can walk you through the transfer if it doesn't "just work"
<manjo> ok
<bjf> JFo, I was thinking about these bugs that we try to close and then someone just reopens them
<bjf> JFo, is it possible to mark them as "private"
<JFo> hmmmm, that is both a good question and an idea
<JFo> let me think upon it for a bit
<manjo> JFo, bjf, I get "There was an error creating the child process from terminal" 
<JFo> you need to chmod +x the tests_starter script
<JFo> I got that earlier
<bjf> manjo, are you testing with one partition or with two?
<manjo> tow
<manjo> two
<manjo> so on the 2nd partition I put kernel-qa
<bjf> when you copied the kernel-qa tree onto the second partition did you get all the permissions and ownerships right?
<manjo> hmmmm I thinkI did let me check again 
<bjf> this usually means that, as JFo mentioned, the kernel-qa/tests_starter script is not executable
<manjo> checking now 
<manjo> I think I forgot to chmod test_starter... 
<manjo> let me try booting this one 
<manjo> I just changed it 
<bjf> manjo, did you look at the list of packages that I am uninstalling? I pasted it yesterday in #scale
<manjo> bjf, yes
<manjo> bjf, I get the same error 
<bjf> manjo, then from a terminal window, run the "tests_first_stage" by hand and see what it complains about
<manjo> looks like I don't have perms to /ukt 
<bjf> I don't understand why you are the only one that runs into that problem
<manjo> when I run test_first_stage I get "lnL creating symbolic link ... " files exists
<manjo> then opens a window
<manjo> and I get that error 
<bjf> manjo, yesterday you were going to fix the "tests_first_stage" script if it needed to set permissions and then send it to me, I didn't get anything from you 
<manjo> I know what the problem is 
<bjf> manjo, what is it?
<manjo> 1. permission missing for /ukt 2nd test_starter under kernel-qa is not executable
<manjo> I will send you patch for missing perms 
<manjo> or you can quickly add it to the script 
<JFo> bjf, the only badness I see about making a bug like the ones mentioned above private would be the duplicates that would be created by the same people who keep reopening the bugs.
<manjo> chmod +rwx /ukt 
<bjf> manjo, I'd still like to know why only you have this issue
<bjf> manjo, when the script makes the /ukt mount point on my system it has the correct permissions. i don't understand why yours doesn't
<JFo> same here
<manjo> bjf, impressive :)
<bjf> manjo, what is?
<manjo> bjf, I just ran the tests on the HP mini and  they passed
<manjo> bjf, you need to pick up the new version of kernel-qa and I will send you a patch for change in perms
<bjf> manjo, what changed with kernel-qa
<bjf> manjo, why when I or JFo create the ukt directory in / is it created with the correct permissions and yours not?
<bjf> manjo, I'd like to get the tests_first_stage that you've modified and that works for you
<manjo> bjf, yes I can't find my USB stick... do you have a copy of that file you can mail it ot me ? 
<bjf> if [ ! -e "/ukt" ]; then
<bjf>     sudo mkdir /ukt
<bjf>     sudo chmod +rwx /ukt
<bjf> fi
<manjo> bjf, looks like its not in the git tree either so its a file private to you 
<manjo> yep
<manjo> that works
<pgraner> bjf, manjo: you can save a 2x commands by doing: sudo mkdir -m 755 /ukt
<bjf> pgraner, ack
 * manjo thinks pgraner is *amazing*... 
 * manjo says or that is what csurbi would have said
<manjo> pgraner, do we have a switch in the box that you gave JFo to ship ? 
<manjo> bjf, JFo, pgraner we will also need some network cables
<JFo> manjo, I am way ahead of you
<bjf> manjo, since the box went out yesterday it's a little late to think of that
<bjf> manjo, however, JFo, did think of it and has taken care of it
<manjo> JFo, you the man
<JFo> I know :)
 * manjo puffs on 98 connecticut shade 
<manjo> bjf, are you rolling the final image today ? 
<manjo> with all the latest changes ? 
<bjf> manjo, yes, it was already rolled until your perms change
<bjf> manjo, I'm uploading it now
<manjo> and the modified kernal-qa ? 
<bjf> yes, and the modified kernel-qa
<manjo> I checked in a small change this morning 
<manjo> cool
<manjo> let me know when the upload is done I will suck it down and test it on all 4 netbooks here 
<manjo> bjf, ^
<bjf> manjo,ack
<manjo> bjf, JFo I think we will put on a great show ... 
<manjo> JFo, are you going to populate the usb sticks ? 
<JFo> done
<manjo> ?
<JFo> already done, but I have to redo them due to this new change
<manjo> ah
<manjo> bjf, oops dude I just realized something wrong 
<manjo> have you rolled the image already ? 
<JFo> he is uploading
<bjf> manjo, make it quick
<manjo> I was looking at the results and we are missing one thing 
 * JFo chokes manjo for bjf ;)
<JFo> heh
<bjf> please spell it out for me
<manjo> we need to collect dmesg after we are done running the tests 
<manjo> we collect it before 
<manjo> and we also need to collect log files after 
<manjo> bjf, give me 10mts I will push that change through
<manjo> bjf, do you agree ? 
<bjf> manjo, do it, and test it, and let me know when it's ready
<manjo> bjf, ack... sorry ..it will be really bad if we did not collect that info
<manjo> bjf, I am collecting dmesg after suspend resume, video tests, what other tets do you think we should collect?
<bjf> manjo, i'm fine with those
<manjo> ok
<manjo> then I will test it and push it in the next 20mts 
<bjf> manjo, i've got to run to the store, wife is sick, will be back in a bit (30 min. max)
<bjf> manjo, I'm back are your changes ready?
<bjf> manjo, I need to crank that iso out, are your changes ready?
<manjo> yep pushing now 
<manjo> bjf, done 
<manjo> I tested it as well on my 10v
<manjo> phew!
<manjo> that would have been baaaad 
<manjo> so we are collecting dmesg 1. after the system boots, 2. after suspend/resume, video, graphics tests 3. after all the tests are run
<manjo> we are collecing system logs before & after all the tests are run
<manjo> XXX.log.before xxx.log.after 
<manjo> bjf, ^ 
<manjo> JFo, ^
<bjf> manjo, ack
<manjo> coo
<manjo> l
<JFo> ok
<manjo> JFo, bjf, please review my changes as well
<JFo> where are we collecting them to?
<manjo> JFo, to results/qa-logs & results/ubuntu-logs/ 
<JFo> ok, and how do we separate these results out by individual machine?
<JFo> are we going to need to copy them off each time?
<JFo> or will that be automatic?
<manjo> in qa-log after each test in suspend/resume, video, graphics is exed you will see $TEST.dmesg
<JFo> right
<manjo> JFo, dmidecode will give us that 
<JFo> but say 5 people use a USB key
<manjo> JFo, dmidecode will have system info
<bjf> JFo, it's covered, each run goes into a different directory
<JFo> bjf, cool
<manjo> yep and its by uuid
<JFo> that was what I was needing
<manjo> so its uniq
 * manjo pleads someone to say I am good :)
<manjo> bjf, I am going to work on the wiki now 
<bjf> manjo, JFo, uploading new iso
<manjo> bjf, ack going to zinc ? please post the link
<bjf> manjo, it's there, same place as all the others
<manjo> called the same ? 
<bjf> yup
<manjo> ok thanks 
<JFo> pulling the ISO now
<manjo> JFo, my link is damn slow so taking a a while 
<manjo> JFo, https://wiki.ubuntu.com/KernelTeam/KernelCompatibilityTesting updated the wiki 
<JFo> cool
<manjo> pgraner, ^
<pgraner> manjo: I added a table of contents
<pgraner> manjo: the only thing I see missing is where to get the image?
<manjo> pgraner, right, bjf is doing the image 
<manjo> and he will add the part on couchdb etc 
<manjo> pgraner, I added info on testsuite & pxe boot 
<pgraner> manjo: cool
<manjo> pgraner, not sure if you were around, we are collecting dmesg after some of the key tests like suspend/resume, video capture, graphics tests, and also complete log files before & after all tests 
<manjo> and also we collect apport data when tests fail 
<pgraner> manjo: cool
<crimsun> manjo: are there plans to roll in the newer compat-wireless or linux-alsa-driver-modules for those test images?
<crimsun> manjo: i.e., if any of the sound tests fail, unload ^snd* and load the newer l-a-d-m ones, and offer to retest
#ubuntu-kernel 2010-02-18
<manjo> crimsun, you are more than welcome to write :)
<manjo> crimsun, git clone git://kernel.ubuntu.com/manjo/kernel-qa.git kernel-qa
<manjo> crimsun, and send patches 
<crimsun> manjo: ok, I'll try and look at that this weekend
<manjo> cool
<manjo> crimsun, its all in shell
<manjo> and adding a test is pretty easy
<manjo> write your shell script that outputs no noise, wrap it up in the test harness and submit the patch 
<manjo> crimsun, look at the suspend/resume or graphics test 
<crimsun> manjo: thanks for the pointers
<manjo> crimsun, :)
<smoser> jjohansen, that issue hasn't cleared itself up. the one with bad dependencies in karmic
<smoser> bug 520015
<ubot3> Malone bug 520015 in linux-meta-ec2 "bad dependencies on karmic linux-ec2, linux-image-ec2" [Undecided,New] https://launchpad.net/bugs/520015
<jjohansen> smoser: okay, I'll hit up apw and smb when they come online tonight and we will get it sorted out
<smoser> i shoudl verify for sure that the recreate is still valid
<smoser> but the issue that my builds were having due to it is still present.
<smoser> karmic builds end up with 2 -ec2 and 2 -virtual kernels
<Wellark> hi! how long does it take for 2.6.31.20 to get from karmic-proposed to main?
<apw> Wellark, presumably you mean from -proposed to -updates?
<smb> Wellark, As its a big change at least two weeks. And the more feedback there is on the specific bugs the better
<apw> Wellark, it cannot move until the various bugs it fixes have been tested and verified by the reporters
<apw> you can of course just add -proposed to your sources and get it anyhow?
<mozmck> is the karmic kernel really just 2.6.31 with some patches or is it 2.6.31.12 with some patches?
<mozmck> or something in between?
<smb> Its 2.6.31.7 or .9 with some patches. Depending whether you look on -updates or -proposed
<mozmck> how does one tell?  I've got the git tree and have looked in the changelog, but I just see tags like 2.6.31-xx.xx
<smb> The git tree itself is now at 2.6.31.12 when you take master. Simplest thing to look is Makefile 
<smb> EXTRAVERSION is the stable version included
<mozmck> oh, duh!  should have thought of that.
<mozmck> When I was trying to find out a while back I was looking at the package from the repository.
<hallyn> i notice that lucid doesn't have CGROUP_DEVICE enabled in the kernel
<hallyn> is there some particular place i should go to request that that be turned on (for whatever release it's feasible for, be that lucid or the next one)?
<cking> apw, ^^
 * apw groans
<apw> why can't everyone ask for the CGROUP things all at once?
<cnd> smb, when you pull from -stable, do you pull all the commits, or do you sometimes leave some out?
<smb> apw, That should have been in the stuff you added lately...
<apw> hallyn, yeah that seems to be on already
<apw> debian.master/config/config.common.ubuntu:CONFIG_CGROUP_DEVICE=y
<apw> hallyn, normally the place to ask is here informally and  though is kernel-team email list formally
<smb> cnd, Normally all (until 3 month after release (of a series like Karmic). After that only critical stuff. Though on LTS it will be always everything. Just very very few exceptions. I think once I decided that the upstream change was too much risking regression without need
<apw> cking, can you check if your outputs are muted in alsamixer ... all mine were
<hallyn> apw: hmm, i just installed a lucid image this morning and it didn't have it - recon' i have to update?  
<apw> headphone and speaker channels on MM
<cking> apw, checking...
<cnd> smb, ok
<apw> thats from the config for lucid
<hallyn> apw: ok, thanks
<hallyn> (upgrading right now)
 * hallyn makes a note of the path debian.master/config/config.common.ubuntu for future ref
<cking> apw, I just needed to pull in some more updates that came in over the past hour or so - audio now OK
 * cking checks skype + BT
<cnd> apw, smb, I did more research and found that the card for bug 505808 is actually an r690 part, which is hit directly by the other of the two commits I was looking at
<ubot3> Malone bug 505808 in linux "Can't boot with last linux kernels from 2.6.32.10 to 2.6.32.12" [Medium,In progress] https://launchpad.net/bugs/505808
<smb> cnd, err sorry I am a bit lost
<cnd> smb, don't worry
<cnd> just an aha moment for me
<smb> aha
<smb> ;)
<apw> cnd cool ...
<hallyn> apw: hmm, after an upgrade i still dont' have CGROUP_DEVICES - i see it shouldve gone in dec 3, is that recent enough to not have made it into updates?
<hallyn> (or is it being masked by some other file - i don't know how configs are generated)
 * apw is confused, we have no -updates in lucid
<apw> CONFIG_CGROUP_DEVICE=y
<apw> in my insgtalled config
<apw> hallyn, how are you checking if it is available
<hallyn> $(*&R%(*$&
<hallyn> wrong install cd
<hallyn> so sorry...
<apw> [    0.013607] Initializing cgroup subsys devices
<hallyn> yeah, apparently i installed karmic.
<apw> for karmic the changes are not yet in any pocket, they are still out for review
<apw> now what the heck that does for me is another question
<hallyn> which?
<smb> They will be uploaded but that is not before this proposed is done
<hallyn> all right, sorry about that, guys, i'm off to install the right *$&(*%& cd.
<apw> lol
<smoser> jjohansen, ping
<smoser> i just did a 'apt-get --purge remove linux-image-2.6.31-302-ec2' and get an error: 
<smoser> dpkg: warning: while removing linux-image-2.6.31-302-ec2, directory '/lib/modules/2.6.31-302-ec2' not empty so not removed.
<smoser> I'm guessing this is something that is not a problem with the other kernel packages (i did not see similar error for -virtual and removed it)
<matti> Not really and error ;] Unless you expect this to be deleted as well.
<smoser> well, the content in it is 
<smoser> $ ls /lib/modules/2.6.31-302-ec2
<smoser> modules.alias.bin  modules.dep.bin  modules.symbols.bin
<smoser> so no, not an error, but those were definitely generated by the package and should be removed with it (and I believe are removed in other linux-image packages)
<matti> ;]
<ogasawara> smoser: I think a fix recently was committed for that issue, can't remember the bug number off the top of my head though
<smoser> ogasawara, ok. this was on karmic, and obviously of an older package (-304 is now in -updates)
<ogasawara> smoser: did -304 resolve the update issue you reported?
<smoser> hmm.. no. just checked.
<smoser> $ dpkg-query --show linux-image-2.6.31-304-ec2
<smoser> linux-image-2.6.31-304-ec2	2.6.31-304.10
<smoser> that demonstrates the issue
<smoser> ogasawara, ^^ do you want me to open a bug ?
<ogasawara> smoser: yes please, and let me know the bug #.  we can get it on our weekly bug list we'll review on monday
<bryceh> apw, sconklin, drm discussion on #dri-devel if you're around.  airlied thinks option #2 is the only sensible one to consider
<cnd> sconklin, by backporting .33, you're talking about the entirety of .33 drm, not just nouveau, ati, and intel?
<sconklin> cnd: that would remain to be seen. Based on what I know now, I think intel and radeon for sure, and I'll defer to the nouveau experts
<sconklin> And the X people will handle their part.
<cnd> sconklin, I just wonder if there aren't skew issues if we're backporting parts of .33 drm but not all of .33 drm
<sconklin> For the rest, I think it makes sense to take it all, unless we run into some strange dependencies on recent kernel features
<cnd> yeah
<tjaalton> best to pull it all in
<sconklin> I think we should try to take it all
<cnd> agreed
<cnd> I thoguht .33 was required for nouveau as well, anyways
<tjaalton> yes
<sconklin> it's the piecemeal nature of the current backporting situation that makes it risky and painful - we want to minimize that
<cnd> for lucid, are we targetting nouveau ddx or 3d as well?
<sconklin> and Lucid kernel would then be able to support Wayland, which some people are interested in
<tjaalton> the effort done on lbm would not be lost though, since that can be used for pulling proposed patches and letting people test those
<tjaalton> cnd: no 3d
<tjaalton> that'd need mesa 7.89
<tjaalton> 7.8*
<tjaalton> or maybe the classic dri for the old chips, dunno
<cnd> tjaalton, so I assume that's probably for lucid+1?
<sconklin> all this needs to be run by apw of course
<tjaalton> cnd: yes. though fedora has it I don't think they want bugreports from us :)
<tjaalton> at least that's the current upstream policy about nouveau 3d
<cnd> ok
<bryceh> cnd: we may put it in a ppa or something
<bryceh> cnd, seems like a perfect thing to provide in xorg-edgers for example
<cnd> bryceh, I might actually be interested in helping with that
<bryceh> cnd, cool
<cnd> I only need up to compiz support, so based on phoronix's tests I'm guessing that would be mature enough to play around with in a ppa for lucid
<tjaalton> sure
<cnd> oh wait, I'm getting ahead of myself...
<bryceh> cnd, are you experienced with packaging?  touch base with the other xorg-edgers fellows on ubuntu-x
<cnd> nouveau doesn't support 9400m yet
<cnd> or at least not when I last tried
<bryceh> cnd, particularly RAOF and sarvatt
<cnd> bryceh, I've got my own ppa for rinputd, my side project I've been working on
<cnd> so I've got a bit of experience
<bryceh> cnd, excellent
<cnd> but I'm not sure if I'd be the best to work on it if I can't even get nouveau ddx working :)
<sconklin> bryceh: I'll make a response to the current "Status of kernel X drivers" thread and cover what we just discussed.
<bryceh> sconklin, great
<bryceh> sconklin, yeah I think this will simplify a lot of different things (packaging, testing, bug upstreaming)
<bryceh> sconklin, and having lbm for .34 stuff will address the concern that upstream will stop focusing on .33 after a time
<RAOF> As long as .34 lbm does not contain nouveau, or we revert the API break it would introduce.
<sconklin> bryceh: yes. and honestly, spending effort backporting .33 makes more sense than wading into a pile of backports for individual features
<tjaalton> RAOF: why not include it from the start?
<cnd> hmmm... I see someone else with exact same hw as me got nouveau to work 4 days after me
<RAOF> tjaalton: If we're ok with pulling from drm-next (or the nouveau tree itself; I'm not sure if that's been pushed to drm-next yet) and upgrade to libdrm 2.4.18, that'd be fine.
<cnd> maybe it'll work now
<RAOF> tjaalton: It *would* make cherry picking fixes easier.
<tjaalton> RAOF: we'll be backporting from there anyway, so sooner or later some nouveau fix will need that commit
<tjaalton> or need backporting
<tjaalton> uh
<tjaalton> I mean, more work to backport
<bryceh> ahh cnd == chase douglas
<cnd> yep!
<cnd> we shook hands in portland
<bryceh> cnd, ok sorry for my lame question about if you knew packaging ;-)
<cnd> well, it's not really that lame
<cnd> I didn't know packaging until a few months ago :)
<RAOF> tjaalton: Yeah.  It wouldn't be too long before we ran into something that touched that commit.
<bryceh> cnd, :-)
<cnd> bryceh, I've been doing rpm packaging at IBM for a few years though
<RAOF> cnd: Sarvatt has, or had, a build of mesa in xorg-edgers which built the nv3x+ nouveau gallium component and the classic mesa driver for older cards.
<cnd> so just a shift in process :)
<bryceh> RAOF, I've got libdrm 2.4.18 on my todo list to merge either with or without the API change
<tjaalton> bbl, testing if blade runner on 1080p looks ok with the optoma :P
 * RAOF wonders if the slightly odd X behaviour he's seeing is because he's got both drm.ko and lbm_drm.ko loaded.
<cnd> RAOF, so does that mean just boot into lucid, install Sarvatt's packages, and there *could* be 3d support?
<cnd> or is something else needed?
<RAOF> cnd: Just that.  Install, boot, run.
<cnd> bryceh, looks like your suggestion has already been done :)
<RAOF> cnd: Last time I tried nv4x gallium had broken, both from the packages and from git.  nv5x gallium seems to be the new sweet-spot :(
<cnd> hmmm... what do I have again?
<RAOF> Geforce 8 or newer?  nv5x.
<RAOF> 6/7 - nv4x
<cnd> geforce 9400m
<cnd> so that sounds good
<RAOF> In your swankypants shiny macbook, yes.
<cnd> I'll probably try that later on
<cnd> heh :)
<RAOF> While everyone's here, we also need to work out where the hook for installing nouveau.ko in the initramfs.
<RAOF> Ahem.  Should go.
 * bryceh lunching
<RAOF> Unless nouveau's going to end up in drivers/gpu/drm, we'll need an initramfs hook to pull it onto the initramfs so nvidia users get the same KMS experience as everyone else.  And to prevent vga16fb loading, and messing everything up.
#ubuntu-kernel 2010-02-19
<smoser> ogasawara, just opened 524180
<ogasawara> smoser: thanks
<iD_J> help =[
<apw> ?
<tgardner> apw, have had any time to re-look at the qcm-msm branch?
<apw> bah no ... will re-fetch it now, as i have as many builds running as my tiny mind can keep track as it is
<tgardner> apw, you needed one more ball in the air.
<apw> yeah
<ogasawara> JFo: when you have a moment, can you add 524180 to monday's bug list.  just want to make sure it's on the radar.
<JFo> I can indeed :)
<JFo> it has been added ogasawara 
<ogasawara> JFo: awesome thanks.  I'm hoping to send a patch today but in case I don't I didn't want to forget.
<JFo> cool
<apw> bug #524180
<ubot3> Malone bug 524180 in linux-ec2 "removal of linux-image package leaves /lib/modules/`uname -r`" [Medium,Triaged] https://launchpad.net/bugs/524180
<apw> ogasawara, which release is that issue in
<ogasawara> apw: karmic ec2 
<apw> ok cool, then it needs fixing, in lucid it'll get fixed by the update to master
<ogasawara> apw: I don't think it's an issue for lucid
<apw> yeah makes sense
<apw> so we should get the nom on that accepted ... which i can't do arrrg
<apw> and get the lucid one close
<ogasawara> apw: yah, I lost my magic to nominate also
<ogasawara> JFo: can you approve the karmic nomination in 524180
<apw> i bloody can upload it, so i should be able to
<apw> ARRRG I HATE LP
<ogasawara> JFo: I think you have the magic permissions now
<JFo> ogasawara, I can
<apw> if he doesn't i think tim is the only one who can
<smb> apw, You cannot anymore?
<apw> cjwat-son changed it so you and i had linux on our names, so we cna do it there
<JFo> done ogasawara 
<ogasawara> thanks
<apw> the package set shit to do it for other packages does not seem to be fixed still
<smb> Ah 
<JFo> my pleasure
<apw> as i cannot do lnux-ec2 though i can upload it
<smb> apw, So much for the lp bug to get fixed soon
<apw> yeah 'this week' half a cycle ago
#ubuntu-kernel 2010-02-20
<Sarvatt> hmm, if I build mmc/SD modules into the kernel and enable unsafe resume I'm able to suspend but with 2.6.32-rc2+ kernels using the ubuntu config (or just the lucid kernels) it hangs when I try to suspend if i've ever mounted the SD (even if i unmount it first)
<lool> So for some reason, cpio gzipped initramfs doesn't work on versatile; it works on other armel flavors because they have CONFIG_CRAMFS=y, but i386/amd64 don't have CONFIG_CRAMFS=y and they still work
<lool> It seems armel doesn't support initramfs, but I don't understand why
<lool> [    1.801487] Trying to unpack rootfs image as initramfs...
<lool> [    1.807606] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
<lool> apw: Hey, perhaps you have an idea on the above?  I wonder why initramfs doesn't work with versatile, perhaps we should bump the ramdisk size to something larger and use CONFIG_CRAMFS=y instead of =m in the mean time?
<lool> I'm not sure why initramfs doesn't work   :-(
<syn-ack> Hey, what would I use to manipulate the NX bit or is it enabled by default?
#ubuntu-kernel 2010-02-21
<malev> hi, is there a list of common answers about bug's reporting but for the kernel?
<matti> ;]
<philsf> can someone please help me debug a problem in my usb stack? I can't mount or use any USB device. This is what appears in kern.log when I plug a pendrive (that works on other ubuntu boxes)  http://pastebin.com/f489fcdd0 . This is a karmic up to date netbook, and it used to work 
<philsf> should I just report a bug? I'd hope this would be some trivial misconfiguration I'm missing
<crimsun> philsf: could be hw or driver; it tends to be more the former
<philsf> crimsun, it works if I boot an image (say, the nbr install image) from the pendrive, and it works in windows
<philsf> also, the pen drive works in other ubuntu boxes
<philsf> crimsun, it stopped working after a large update - this was it IIRC http://pastebin.com/f13834c7a
<philsf> it was working the day before, and I tried to use the pen drive just after the update, and it didn't work anymore. I'm clueless
#ubuntu-kernel 2011-02-14
 * apw yawns
 * smb crawls out of the first bath in new email.
<apw> smb, heh fun
<smallfoot-> im using ubuntu 10.10 "maverick", does the 2.6.38-999 kernel from the kernel-ppa work?
<ogra> apw, around ?
<ogra> did you drop linux-headers-2.6.32-410-dove from the archive (my images fail to build not finding that package, if you removed it the meta needs to go too)
<smb> ogra, apw had to leave for some plumbing emergency. It will be a bit till he is back
<ogra> smb, hmm, do you know anything about the dove kernels by chance ?
<tgardner> ogra, didn't GrueMaster test both of the recent dove uploads?
<smb> ogra, I have not followed closely. tgardner did you do stuff there by chance? Otherwise I can try to check on the status
<ogra> tgardner, there shouldnt be any dove uploads in natty
<tgardner> ogra, true. in fact I've requested that dove be removed from the archive for natty
<ogra> tgardner, the point is that apparently the dove headers are gone from the archive 
<ogra> tgardner, but the meta seems to be still there
<tgardner> ogra, ok, I'll see that the meta gets removed as well
<ogra> all header metas get installed during image builds on arm and the unwanted onse get removed at the end 
<ogra> so one broken meta breaks all images 
<tgardner> that seems an odd way of doing things. however, there is a bug open to remove the kernels, so I'll just add the meta package to it
<tgardner> back in a a sec...
<ogra> its a "bug/feature" of the seed management
<ogra> tasks and seeds dont understand subarches, thesy can only operate on toplevel (i.e. armel but not armel+omap)
<smb> tgardner, cking Maybe you are better at remembering things than me. I just stumbled indirectly over those acpi_skip_timer_override quirks that manjo had been  submitted for Maverick. Were those not intended to go upstream?
<yodog> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<yodog> !ops
<yodog> !join #xubuntu
<ubot2> Factoid 'join #xubuntu' not found
<yodog> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<yodog> !ops
<cking> smb, dunno - were they upstream worthy?
<mjg59> smb: The ones for the Lenovos? The problem got root-caused.
<smb> mjg59, Ah, yes. Those I guess
<yodog> !opsnigga nigga 
<ubot2> Factoid 'opsnigga nigga' not found
<yodog> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<tsimpson> eh..
<smb> mjg59, Now, sorry for possibly being dense. Does 'root-caused' mean solved better or something else?
<tsimpson> though he has a dynamic IP, so probably won't last long
<mjg59> smb: The problem turned out to be that the apic timer was marked with the wrong polarity
<smb> mjg59, Ahhhh, that ring s a bell
<mjg59> smb: So the initial interrupt got missed. The skip_timer_override quirk just resulted in it being tied to a pin with the right polarity, so it worked
<mjg59> smb: But checking the polarity is a more generic fix than just hardcoding some model names, so that's what upstream went with
<smb> So we actually should get that fix in then we should be able to revert the other quirks from Maverick
<mjg59> Right, though it may be a bit more intrusive?
<smb> That could be (have to check for the other patch). Just looked at someone asking for yet another model added to the quirks, so the question is what is the lesser evil
<mjg59> Ah, ok
<cking> mjg59, is the wrong polarity marked on APIC timers a configuration bug in the firmware?
<mjg59> cking: Yeah, though my recollection is that Windows never uses this configuration
<mjg59> So it'd be easy to miss
<cking> but easy to test for?
<mjg59> cking: There's some details in the thread on lkml
<cking> ok - me will look
 * tgardner detects another test for fwts in the making
<cking> yep - when I get time.
<cking> another "your firmware is broken.. it should be fixed, but the kernel works around it" kind of report.
<loftwyr> I have a USB3 dock that would not work until I changed CONFIG_USB_GADGET_VBUS_DRAW to 500 from the minimum of 2.  Is there a need for it to be 2 or can that be changed for future kernels?
<loftwyr> I'm using Natty
<tgardner> loftwyr, seems that 2 is the kconfig default. I assume its a safe choice.
<loftwyr> Safe, perhaps, but can it be changed without a problem?  
<tgardner> loftwyr, not without some advice from the upstream developers. They likely chose 2 for a reason.
<loftwyr> Where would the best place be to ask them?
<tgardner> seems like there ought to be a sysfs interface for changing it
<tgardner> loftwyr, from the MAINTAINERS file:
<tgardner> USB GADGET/PERIPHERAL SUBSYSTEM
<tgardner> M:      David Brownell <dbrownell@users.sourceforge.net>
<tgardner> L:      linux-usb@vger.kernel.org
<tgardner> W:      http://www.linux-usb.org/gadget
<loftwyr> I'll send him a note.  Thanks!
<smb> mjg59, If I look at the right thread, this ended with "I will submit a patch asap". Jan-28. Maybe that is long enough to carefully ask what time frame this translates into. :)
<sforshee> loftwyr, tgardner: I only caught the last half of the conversation, is this about vbus power usage?
<tgardner> sforshee, yeah, gadget current limits
<mjg59> smb: Ha :)
<loftwyr> and the default in the kernel
<sforshee> loftwyr, tgardner: the spec allows drawing up to 500 mA, I've always been curious why the default is 2
<sforshee> I've always used 500 mA in projects I've worked on
<loftwyr> That's what I want to find out, is it 2 for a reason or is that a legacy setting?
<sforshee> yeah, I don't know the answer to that
<sforshee> if you find out I'd be interested to hear :)
<tgardner> sforshee, you've worked on known HW, though, right? The x86 world is quite that stable.
<tgardner> isn't*
<sforshee> tgardner, I _think_ that is the value that gets reported upstream (to the hub or the host)
<sforshee> so you need to know what you're hardware's actually going to try and draw so you can report the correct value
<sforshee> how many x86 devices are used as usb gadgets anyway?
<sforshee> you're right though, seems like there should be a sysfs interface
<loftwyr> Well, my Vantec dock wouldn't work until I upped the minimum gadget draw so I'm assuming that it doesn't report it's needs enough or uses the wrong interface.  
<loftwyr> I can't seem to find a sysfs setting but I'm still looking
<sforshee> loftwyr, yeah, the hub might cut you off if you're trying to draw more than you report you will
<loftwyr> As it's a USB3 device, it may be reporting something strange that the subsystem doesn't recognize
<sforshee> loftwyr, I don't know about USB3, but USB2 was backwards-compatable
<sforshee> devices had to identify as USB2, and if they didn't they would fall back to USB1
<sforshee> I'd suspect USB3 is the same
<loftwyr> It does if the USB3 hub has a USB2 into it.  It all falls to USB2.  It's reporting as USB3 though according to the logs, just doesn't work using the kernel defaults (writes don't get written, etc.)
<sforshee> and it all works if you change the vbus draw?
<loftwyr> Yep.  The drivers (JMicron) were already enabled as modules so I assume it's just a power draw issue
<sforshee> my initial guess is that the hub is suspending the device because it's drawing more power than what it said it will draw
<loftwyr> Likely true. That would make sense that when I set the default higher, it doesn't cut it off.
<sforshee> hitting up David Brownell will probably get you the best answers about it though
<loftwyr> I've sent off the question, I'll let you all know the answer if/when I get it.
<tgardner> ogra, natty linux-meta-mvl-dove is gone
<ogra> tgardner, awesome, thanks
<JFo> smb, mind having a look at a bug?
<JFo> :)
<smb> JFo, Not if I only have to *look* at it. :)
<JFo> heh
<smb> But I guess you want some comment too
<JFo> only if you see that one is needed
<JFo> bug 711544
<ubot2> JFo: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/711544)
<smb> Doh! :)
<JFo> ah right, private :-/
<JFo> sorry about that
<JFo> but that is the bug number
<smb> But I should be able to look
<JFo> yes
<smb> JFo, Yup
 * smb looks
<JFo> thanks amb :-)
<JFo> sigh*
<JFo> I fail today
<JFo> smb that is
 * apw returns ... but he has to have a shower
<smb> sounds ugly
<JFo> indeed
 * JFo uses a stick to slide the soap toward apw
 * tgardner imagines apw smeared with sewage
<JFo> :-{
<apw> tgardner, i didn't need to imagine
<tgardner> apw, I suspected as much
<apw> i think i need a strong dring
<apw> drink
<sforshee> apw, i don't know, looks like your speech is already slurred
<apw> heheh
<apw> JFo, our key list seems to be empty ?
<JFo> !
 * JFo looks
<apw> JFo, its a newish thing cause they were there this morning
<JFo> apw, I am running some tests
<JFo> taking a while... apparently there is some lag on the line
<apw> bjf yep
<JFo> well, the buglists are generating, so the problem isn't there
<JFo> I'm doing a run by hand to see if I get any errors
<JFo> but there is nothing so far
<JFo> and the list for yesterday is populated
<JFo> so it has worked over the weekend
<JFo> as shown here http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team-archive/kernel-buglist-by-team-2011-02-13.html
<apw> JFo, as i say it was working this morning for me, so approx 4-5 hours ago
<JFo> odd that
<apw> Can't look up definition in another url (https://api.launchpad.net/1.0/#bug)
<apw> i get that from the second phase
<JFo> sigh*
<apw> JFo, any idea what it means?
<JFo> not at all
 * sforshee -> reboot
<sconklin> JFo: From launchpad updates: API scripts talking to the edge cluster are broken with a NotImplementedError. We are investigating to resolve the issue quickly
<JFo> apw, one sec... otp
<JFo> sconklin, yeah, been trying to figure out WTF
<JFo> sconklin, here is the latest: <leonardr> apw, JFo: the breakage was a mistake that's being fixed. edge will continue to work, but you should stop using it or one day this will happen for real
<JFo> sconklin, :-/
<apw> tgardner, i'll have a go at scrubbing lbm for upload for natty 
<tgardner> apw, dkms'ing some of those packages is an interesting approach. about the only thing that might not work for are some of the OEM platforms.
<apw> yeah they do throw the old spanner in the works
<apw> i wonder if we could use dkms to make them somehow ... like using it to produce static binaries
<tgardner> yeah, if we could drop LBM altogether. what a time saver.
<apw> tgardner, yeah there must be a way, i think it would make a good 'OO' project
<tgardner> indeed. perhaps we should float the idea at UDS ?
<apw> as i think we can make a wrapper round them to 'freeze' them on a buildd for those systems which are too slow to really dkms
<apw> tgardner,ea
<apw> tgardner, yeah concur
<loftwyr> Just circling round from this morning.  I sent an e-mail to linux-usb about the USB vbus draw and got this reply: http://ubuntuforums.org/showpost.php?p=10458053&postcount=7.  It seems I have to poke Vantec
<ohsix> lbm?
<tgardner> loftwyr, perhaps you should convince them to implement a sysfs interface for controlling draw.
<apw> linux-backport-modules
<apw> linux-backports-modules
<ohsix> ah
<loftwyr> That's an interesting idea tgardner, I'll ask about it.
<tgardner> loftwyr, or failing that, a module parameter.
<tgardner> Kconfig options are so static.
<apw> they are so last year
<tgardner> loftwyr, there may well already be a module param. I just haven't looked.
<loftwyr> Let's see what they say.
<loftwyr> A sysfs would be so much better as you could tune it on the fly andget the setting that most works
<JFo> wow, just had some really odd sound inticator flashiness... not the good kind
<loftwyr> Getting a fast reply from the USB-linux group (Felix Balbi to be precise).  He says no to an out of kernel control to avoid people melting their USB by setting the draw too high.  "Generally we don't mess too much with things related to power
<loftwyr> consumption, it's quite a mess to lie to the USB host and things can go bad easily. Hope it helps."
 * tgardner --> lunch
<JFo> <-lunch
<tgardner> bjf, did you or sconklin-lunch write anything down in the wiki about how master-next is to be used?
<bjf> tgardner, i don't think so but i've got to look
<tgardner> bjf, the wonderful search facilities returned no match on master-next
<tgardner> jjohansen, when you get a moment, please review "Lucid/Maverick SRU, NFS: fix the return value of nfs_file_fsync()" on the k-t list
 * jjohansen -> lunch
 * sforshee -> reboot
<jjohansen> anyone else noticed problems with gitk lately?
<apw> jjohansen, what you seeing?
<jjohansen> it keeps failing to provide diffs of commits, it will do a few and then it just stops
<jjohansen> restart it and click on the commit it failed on before and it works, but a few more and it fails again
<apw> how many approx ?
<jjohansen> seems to be approx 3-4
<jjohansen> it isn't always the same for me
<apw> just looked at the top 30 or so without issue, on my natty tree
<jjohansen> apw: okay thanks
<apw> jjohansen, that was on a natty box
<apw> jjohansen, OH i did limit history .. gitk HEAD ^v2.6.36
<apw> could you be runnign out of memory for 'all' history
<jjohansen> apw: well maybe but I haven't ulimited it and I seem to have more than a gig free
<jjohansen> I'll mess around with it a bit more
<apw> tends to kill my machine completely
<jjohansen> yeah pruning it down does help
<bjf> apw, bug #677021
<ubot2> Launchpad bug 677021 in linux "Maverick: 2.6.35-23.40 -proposed tracker" [Medium,Fix committed] https://launchpad.net/bugs/677021
<apw> bjf ?
<apw> bjf, oh interesting
<bjf> apw, was that what you were thinking ?
<apw> bjf, that looks like what pete was suggesting ... didn't know you could do that
<bjf> apw, it's using some LP terms/ideas in ways they are not intended, but i think it would work
<apw> i assume that the 'phases' are series ?
<bjf> apw, yes
<bjf> apw, so each phase/series could be independently assigned and it's status changed
<bjf> apw, they could also be worked on in parallel (if possible)
<apw> bjf, could you have used packages witin 'kernel workflow' for the phases too?
<bjf> apw, not sure, bug maybe
<apw> i ask cause this way they can't apply to the in the same way to ubuntu series
<apw> and wonder if that might be something we might want
<bjf> apw, not sure i'm tracking why you'd want to do them as packages
<apw> bjf, i am assuming that you can only have one set of series for a project
<apw> so if for example we wanted to have one bug for 'this round of uploads'
<apw> then we'd want 'upload-it' to have series for each series we have live
<apw> so i was just musing if we used packages in your new project to represent the
<apw> phases, we could also have a task in each phase for each series (maverieck, lucid etc)
<apw> musing is we were backing self into a corner by using series for phases if it can be either
<apw> bjf, ^^
<bjf> apw, every uploaded package get's it's own tracking bug
<apw> yeah it does currently so it currently makes no difference indeed
<apw> just wondering if we might want to both at some point
<bjf> apw, nothing cast in stone at this point, it's just an experiment for now
<apw> yeah assumed so, just a thought nothing more, wondering wondering
<apw> bjf, i can see that working either way pretty well
 * sforshee -> reboot
#ubuntu-kernel 2011-02-15
 * apw yawns
<smb> morning
<jjohansen> morning
<apw> morning
<AlanBell> morning all
<AlanBell> I am investigating some clock drift issues in KVM guests, Ubuntu 10.04.1 server host, Ubuntu 10.10 server guest
<AlanBell> the host does support the constant_tsc cpu flag
<AlanBell> I can't confirm that the guests are using it, dmesg | egrep "(tsc|TSC)" returns nothing
<AlanBell> expired bug 444531 may be relevant/similar
<ubot2> Launchpad bug 444531 in kvm "Guest kernel can't read TSC frequency from the hypervisor" [Medium,Expired] https://launchpad.net/bugs/444531
 * apw notes the bug has expired
<AlanBell> it has, also relates to Karmic, but it is the closest I could find
<AlanBell> /sys/devices/system/clocksource/clocksource0/available_clocksource does contain "tsc hpet acpi_pm"
<herton> apw: kernel-buglist-by-team.html still unavailable correct?
 * apw has to run and supervise a plumber, will have my lappy with me
<apw> herton, seems so indeed ...
<apw> JFo, the key bugs list is MIA
<tgardner> apw, are there mumble issues today?
<smb> tgardner, I seem to be logged in
<smb> still
<tgardner> it hates me
<smb> It hates all of us... just differently
<herton> tgardner, there was someone complaining to IS today about not being able to connect
<herton> but I'm logged in ok too here
<tgardner> sometimes there are single sign-on issues
<apw> tgardner, i haven't had trouble, but not been paying much attention
<tgardner> what will I do if I can't talk to my homies all day?
<smb> Be very productive. *slap*
 * apw pokes JFo 
 * JFo grumbles
<JFo> :)
<JFo> morning apw
<JFo> apw, finally had to change it back to EDGE
<JFo> running now
<apw_> ok sounds odd bit ...
<JFo> well, I suspect the other may be caused by version issues maybe, but I am not sure.
<JFo> I did everything they said to do and it continued to fail
<apw_> hrm  ... odd indeed
<JFo> could still be something I was doing wrong
<JFo> in fact, that is most likely it
<JFo> at any rate...
<JFo> apw, it is up now
<JFo> apologies for the delay
<tgardner> bjf[afk], sconklin: when do the verification-needed tags get applied?
<sconklin> tgardner: brad and I will do that today. We apply them after they are copied to -proposed. No real automation for that yet aside of a script that helps
<tgardner> sconklin, ah, thanks.
<tgardner> just going through my bug spew after moving stuff to -proposed
<sconklin> tgardner: I'm just about all spun up here again after a multi-hour power outage
<tgardner> sconklin, hmm, sucks to be you. you've had some exceptionally bad weather this winter.
<sconklin> tgardner: two months of terrible weather, and the power goes out after three beautiful days with temps in the 60s. Go figure
<tgardner> maybe some drunk dufus smacked a power pole
<apw> heh ... so very believeable
<pmatulis> what can we say about a process that causes /proc/vmallocinfo to grow without bounds?
<hernil> Hello people! I have a kernel-related bug as described here: http://ubuntuforums.org/showthread.php?p=10458430#post10458 Any tips? 
<bullgard> JFo: I get a kernel error message similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495674&trim=no . What package should I associate my error report in Launchpad to?" (My question has not been answered in #ubuntu-bugs for > 8 hours.)
<ubot2> Debian bug 495674 in alsa-utils "[udev] Driver 'pcspkr' is already registered, aborting..." [Minor,Open]
 * JFo looks
<JFo> bullgard, I would say udev as I seem to recall that we have a specific package for those
<bullgard> JFo: Thank you very much for your help. I appreciate that.
<JFo> bullgard, my pleasure
<JFo> let me know if you encounter issues
<hallyn> so are pulls from Linus' tree generally done on fridays, or is that in my head?
<JFo> hallyn, do you mean for mainline kernels?
<JFo> or something else?
<hallyn> yeah
<hallyn> for ubuntu-natty
<tgardner> hallyn, generally when we see something interesting, like a bug fix or an rc candidate
<JFo> I think we pull them whenever we have an RC
<JFo> what tgardner said
<tgardner> hallyn, do you have something in mind?
<hallyn> my patch is affected by a patch by cdub which isn't yet in ubuntu-natty.  I'll just do it against linux-2.6 for now then, thanks
<hallyn> well, i don't care about his patch per se, i just don't want to re-rebase and then re-re-rebase to push to lkml :)
<tgardner> hallyn, we often rebase against an intermediate tip
<hernil> How can I add Nattys main repo to my maverick install to test Natty kernel? 
<tgardner> hernil, use https://launchpad.net/~kernel-ppa/+archive/ppa
<hallyn> the one pinching me is 47970b1b2aa64464bc0a9543e86361a622ae7c03 from last thursday.  
<tgardner> hallyn, that got reverted
<hallyn> oh?
<tgardner> hallyn, yep, but we have not uploaded a kernel with that revert in it yet
<hallyn> actually 6037b715d6fab139742c3df8851db4c823081561
<tgardner> see f00eaeea7a42b5ea327e9ce8839cb0b53d3bdb4e
<hallyn> haha
<hallyn> but, that only reverts the user
<tgardner> is that not sufficient for you?
<hallyn> It's the addition of struct cred arg to security_capable() that's chafing me
<hallyn> and that was not reverted
<tgardner> ok, thats a different problem. you gonna make a patch for Linus ?
<hallyn> No, I don't think they intend to revert that.  Rather probably find a different way to use it
<hallyn> So my problem is just that I also add an argument to some of the same functions, so patches clash.  I was just trying to decide whether to wait for an ubuntu-natty tree update rather than have two patchsets
<tgardner> well, it would only take me a few minutes to run a rebase.
<hallyn> duh.  i'll just cherrypick that patch for my ubuntu-natty tree
<tgardner> that works too
<hallyn> tgardner: if it was something you were going to do soon anyway, sure - but I can cp it
<hallyn> I'm still too stressed from the drive to drop off the kids
<tgardner> :) ok, gimme a few minutes.
 * hallyn isn't a commute kinda guy
<hallyn> great, thanks
<tgardner> hallyn, actually, it looks like apw has already rebased against tip.
<tgardner> UBUNTU: rebase to 795abaf1e4e188c4171e3cd3dbb11a9fcacaf505
<hernil> tgardner, thanks. And then what package do I install? :-) 
<hallyn> tgardner: hm, I had just fetched an hour ago, let me check
<tgardner> hernil, use one of the meta packages in linux-meta-lts-backport-natty, likely -generic
<tgardner> hernil, 'sudo apt-get install linux-image-generic-lts-backport-natty'
<hallyn> <shrug>  not seeing it here - refetching
<hernil> tgardner, I think I'm unable to update the package list because of some problem with a ppa. Just keep getting this message: W: GPG error: http://ppa.launchpad.net maverick Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4B6DCB2258043CFF
<hernil> W: GPG error: http://ppa.launchpad.net maverick Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 10975893E549B1AC
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<tgardner> hernil, its just a warning that you can ignore. otherwise, see /Read about installing' in the PPA page.
<hernil> tgardner, I've added the ppa and done a sudo apt-get update, but can't find the package name you gave me =/ 
<tgardner> hernil, 'sudo apt-get install linux-image-generic-lts-backport-natty' doesn't work?
<hernil> tgardner, nope. E: Unable to locate package linux-image-generic-lts-backport-natty
<tgardner> hernil, how did you add the PPA source? a new file under /etc/apt/sources.d ?
<tgardner> /etc/apt/sources.list.d
<hernil> tgardner, No, I used 'sudo add-apt-repository ppa:kernel-ppa/ppa'
<tgardner> hernil, then it likely gave you the wrong pocket, e.g., maverick instead of lucid
<hernil> tgardner, How do I fix that? I'm currently on a Maverick system. 
<tgardner> hernil, you'll have to edit /etc/apt/sources.list
<hernil> tgardner, The ppa you gave doesn't seem to have a maverick "version". In the technical details this is what it says: deb http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu lucid main  deb-src http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu lucid main 
<tgardner> hernil, no, it'll have a lucid version. its the same source code but uses the lucid tools to compile the kernel. it ought to be fine.
<tgardner> hernil, what graphics chipset are you using? I remembered that X might not work for you in some cases with the backport.
<hernil> tgardner, there we go. Added them manually and it worked. I'll install 'linux-image-generic-lts-backport-natty'
<tgardner> its primarily intended for server enablement work
<hernil> tgarnder, I'm using a Dell laptop (Inspiron D531) nothing fancy. If I install this I will still have my current kernel in GRUB so I can boot en remove the new one if it doesn't work? 
<tgardner> hernil, yep.
<hernil> Then I'll just go for it. My problem is trouble with my new SSDs performance with the current kernel. 
<hallyn> tgardner: I'm still not seeing any commit past Wed Feb 9
<hernil> tgardner, will this give me the headers too? 
<tgardner> hernil, not unless you also install the headers package
<hernil> tgardner, do I need them? 
<hernil> tgardner, for now I just 'sudo apt-get install linux-image-generic-lts-backport-natty' 'ed
<tgardner> hallyn, are you using master-next ?
<hallyn> no
<tgardner> hernil, you shouldn't need the headers package.
<hallyn> tgardner: neat.  thanks
<hernil> tgardner, then I'll be right back. Rebooting to test! 
<tgardner> hallyn, thats where the most recent bits live.
<pmatulis> what kernel are we getting with 10.04.2 ?
<tgardner> pmatulis, 2.6.32 ?
<hernil> tgardner, I got to boot, but it didn't really solve my problem. Could we continue with PMs?  
<smb> tgardner, I was inclined to say the same. Guess he wants to know which subversion. sconklin may know
<pmatulis> tgardner: k, right.  but there will be option to install with lts backport
<tgardner> hernil, no PMs on a public forum. besides, I'm not sure I can help you with your SSD performance issues anyways. its kind of subject to the work load.
<tgardner> pmatulis, on the DVD
<pmatulis> smb: yes, the subversion
<sconklin> pmatulis: 2.6.32-28.55, same as is in updates now
<pmatulis> sconklin: ok
<tgardner> pmatulis, dunno, you'll have to ask skaet what ultimately ended up in the release
<hernil> tgardner, Okey :-) Is the kernel I tested now different from yesterdays natty daily-build? 
<pmatulis> smb: i'm asking b/c i thought it might help with what i'm seeing.  .32 is giving me oom trouble with vsftpd stress test while lts-backport .35 is very fine
<tgardner> hernil, no, the pre-proposed natty kernel is the absolute bleeding edge. the backport tends to lag by a week or more.
 * smb is not sure he want to know what vsftp is
<hernil> tgardner, Okey. So if I wait for a week or so and update my system as normal I'd get the kernel I tested yesterday? 
<pmatulis> smb: it's a very popular ftp daemon which is in main
<tgardner> hernil, its not deterministic, but yes, it'll eventually catch up
<pmatulis> smb: /proc/vmallocinfo fills up until oom invoked (500 lines) but .35 test will never show more than 2 lines
<smb> pmatulis, Oh, that was that very secure ftpd stuff. Hm, 
<pmatulis> smb: will open bug but i thought i might ask in here first
<hernil> tgardner, Ok. Do you know if the bug I'm experiencing is official and fixed? Should I report somewhere? 
<pmatulis> smb: why would vmallocinfo be so different in .35?
<apw> pmatulis, you say it fills up, what does it fill up with
<apw> mine has 169 on my laptop when quiet
<pmatulis> apw: i will need to redo the test to get that
<apw> each line give you a hint as to whome is to blame for the mapping
<tgardner> hernil, what bug? I'm not sure a slow device constitutes a bug. there is a large performance range difference between the various manufacturers.
<pmatulis> apw: ok but no weird that just a different kernel will make things better?  can it sill be the application at fault?
<apw> pmatulis, there would be some 60k changesets between the two kernels, so anything is possible
<hernil> tgardner, I guess it's a bug when the drive has expected performance in lucid and then goes down to normal HDD-speed with maverick? 
<apw> JFo, about ?
<bjf> ##
<bjf> ## Kernel team meeting in 15 minutes
<bjf> ##
<tgardner> hernil, perhaps, but its an issue that'll have to be solved by the upstream developers.
<JFo> apw, yessir
<apw> JFo, have all of the regression-potentials on our key bugs list been reviewed now?
<JFo> there shouldn't be any regression-potential
<hernil> tgardner, I see, but how do I make them aware of the problem? Could you point me in the right direction? :-) 
<JFo> I still need to remove all regression-potential tags
<JFo> as that is a deprecated tag now
<JFo> wait, do you mean regression-proposed apw ?
<apw> yes, i keep saying that wrong, yes i mean proposed
<JFo> I believe they should be.
 * JFo goes to look
<tgardner> hernil, you can send an email to LKML, but don't be surprised if you don't get a response. Do your homework on SSDs. There are some performance tricks that involve partition alignment depending on the device, etc.
<hernil> tgardner, I'm in no way knowledga 
<JFo> looks like there is only one in our list, but it is the wrong status
<apw> there are two next to each other n the top table alone ?
 * JFo looks again
<hernil> tgardner, * I'm in no way knowledgeable when it comes to SSDs but I've done som research the last couple of days. Alignment was one of the things I got confirmed was all right :-)  
<JFo> ah, I needed to refresh :)
<tgardner> hernil, well then, you've surpassed my knowledge
<apw> JFo, and i dee 5 at least in the incomplete table
<cking> I think the alignment should be automatically set to a fairly optimal state by the installer
<JFo> well, the one that just appeared is brand new
<JFo> as of an hour ago
<JFo> the only ones I see are in incomplete without response
<JFo> are those the ones you are referring to?
<apw> 717970	Undecided	New			After sleep, key presses get lost and trackpad is jittery		regression-proposed	
<apw> 719393	Undecided	New			package linux-image-2.6.35-27-generic (not installed) failed to install/upgrade: corrupted filesystem tarfile - corrupted package archive		regression-proposed	
<JFo> right, the second one is brand new
<apw> JFo, and yes there are indeed a number under incomplete.  but we need to know they are -proposed truly
<JFo> ah right, 
<hernil> tgardner, thank's for all your help! I'll continue poking around and see if i get somewhere :-) 
<apw> cause they should _all_ offiically be blockers to a -proposed to -updates shift
<JFo> I agree
<apw> and therefore they should be of interest to sconklin and bjf
<JFo> sorry, my mind was somewhere else
<apw> and they need to be uptodate to be any use what so ever
<apw> JFo, hey ... there are regression-proposed bugs on natty ... they should be regression-release
<JFo> ? 
<apw> JFo, and you are not hearing us on mumble
<JFo> gah
<JFo> one sec...
<JFo> <-food
 * tgardner --> lugging servers around
<apw> bryceh, hey about ?
<apw> bryceh, bug #716811 ... 
<ubot2> Launchpad bug 716811 in nfs-utils "[SandyBridge] kernel BUG at /build/buildd/linux-2.6.38/fs/nfsd/nfs4state.c:3132!" [Undecided,New] https://launchpad.net/bugs/716811
<apw> did you have any idea which fix was relevant here?  i read the email list, and pulled the branches that tagahashi tested which seemed to get a change on 11th and yet the branch only goes up to the 6th
<bryceh> apw, no, I had some trouble pulling his tree.  I ended up just switching off nfsv4; has been stable for me since then.
<apw> bryceh, ok ... bah
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - February-22 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<JFo> gah, burned my tongue at lunch :-(
<kamal> ... but will this make JFo any less loud?   hmmm.   ;-)
<JFo> doubtful ;)
<JFo> hey kamal,how is the newest DJ doing?
<JFo> rather kamal,
<JFo> my typing is horrible on a good day
<kamal> JFo: oh she's doing fine -- still enjoying fooling with the DJ gear
<bode> hi people, I own a sony vaio vccw with nvidiagt230. I always get a black screen on boot with maverick kernel 2.6.35, but we I tried natty alpha1 kernel 2.6.37 the problem finally was solved, now with natty alpha2 adn kernel 2.6.38 the problem is returnet (no more black screen, but on the screen remains the GRUB image, while the system is booted (i checked it on an external monitor))
<JFo> kamal, excellent! :)
<bode> i want to know if this problem is well known, thanks! 
<janimo> apw, is the decision to remove versatile from natty made?
<apw> janimo, /me is unaware of any significant progress on that 
<janimo> apw, any discussion needed or blocked on something?
<ogra> fyi i just removed imx51 from the seeds
<apw> janimo, i thought there was testing going on, and i've not seen the outcome
<apw> perhaps ogra knows as the testing was in his team i think
<janimo> apw, ah, testing of qemu and omap?
<apw> yep
<ogra> janimo, yeah
<ogra> we need to make sure the vm still runs
<janimo> well, omap3 linaro images boot in qemu-linaro
<jjohansen> bode: there are a number of video/display bugs but I am unsure if yours is the same as existing ones.  File a bug and then with all the appropriate information etc, it can be determined whether its a duplicate
<apw> janimo, yep, and those arn't our images sadly
<ogra> janimo, rootstock will need changes first
<janimo> ogra, what changes does rootstock need?
<janimo> I was hooing the package naming made that unnecessary
<ogra> it looks for the versatile kernel from netboot atm
<rsalveti> janimo: just to get the omap3 kernel
<janimo> the qmeu-linary bin package names I mean
<rsalveti> I can help on that
<apw> bode, nope i am not aware of that symptom set, please file a bug on the -3.30 kernel (if its still there)
<ogra> should be only a few lines
<ogra> and a testrun with both modes (root and non root)
<bode> apw: ok, i'll file a bug  (what do you mean with  -3.30 kernel (if its still there)??)
<apw> i mean testing the latest natty kerenl, and filing the bug if the issue is still there
<bode> i tried also today with the daily-live image
<bode> and the bug was there
 * tgardner --> lunch
<tgardner> pgraner, you've gone deaf
<sforshee> apw, bug 717189
<ubot2> Launchpad bug 717189 in linux "thinkpad t410 freezes reproducibly upon resume from suspend" [Medium,In progress] https://launchpad.net/bugs/717189
<apw> apw@agent57:~$ sysctl -a | grep kstack
<apw> error: permission denied on key 'kernel.cad_pid'
<apw> kernel.kstack_depth_to_print = 24
<Guest83863> apw: bug filed! 
<Guest83863> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/719571
<ubot2> Ubuntu bug 719571 in xorg "Natty Alpha2 monitor doesn't work, SonyVaio VPCCW1, NVIDIA GT230M" [Undecided,New]
<lamont`> apw: around?
<apw> lamont, sup
 * jjohansen -> lunch
<lamont> apw: -> /query
<tgardner> pgraner, so, I'm shucking and jiving with my USB audio headset. no crashes yet using just Banshee.
<pgraner> tgardner, try mumble
<tgardner> pgraner, working on it
<bode> apw: can you check if the information on the bug are usefull or if something else is needed?
<tgardner> bode, I think apw is done for the day. he's in the UK
<bode> ops.. i'm in italy, i always forget about the time!
#ubuntu-kernel 2011-02-16
<apw> pgraner, looks like there might be a resume fix for i915 coming through
<apw> pgraner, do you have ironlake ?
<LLStarks> ogasawara, this bug was inappropriately closed as a duplicate: bug 238208
<ubot2> Launchpad bug 238208 in linux "Need MemoryStick driver Ricoh R5C592 (part of R5C832/822chipset) (dup-of: 111089)" [Wishlist,Confirmed] https://launchpad.net/bugs/238208
<ubot2> Launchpad bug 111089 in linux "Ricoh R5C822 - MMC cards not detected in built-in memory card reader" [Medium,Fix released] https://launchpad.net/bugs/111089
<LLStarks> there is no r592 driver for ubuntu
<LLStarks> gotta install manually with this: http://gitorious.org/ricoh-kernel
<herton> apw, ok besides LP#713769, also LP#716811 should be fixed as well on rebase to rc5
<herton> LP#716811 should be fixed by commit acfdf5c
<rsalveti> herton: please point bugs as bug 713769 instead of LP#713769 at the irc
<ubot2> Launchpad bug 713769 in linux "natty, invalid opcode: 0000 [#1] SMP" [High,Fix released] https://launchpad.net/bugs/713769
<rsalveti> then we get the bug description and link
<herton> ok
<tgardner> sforshee, https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<tgardner> apw, rtg@emerald:~$ cat /proc/version_signature 
<tgardner> Ubuntu 2.6.38-4.31-server 2.6.38-rc5
<apw> tgardner, very nice ... let me know how stress fairs :)
<tgardner> apw, its approaching 300
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+patches?start=0&batch=75
<JFo> apw, smb etc bug 720095
<ubot2> Launchpad bug 720095 in linux "vsftpd causes memory leak in Lucid" [Undecided,New] https://launchpad.net/bugs/720095
<smb> apw, In case you did not hear. The guess was sounding plausible but it is in since 2.6.32-13.18
<JFo> <- lunch
 * tgardner --> lunch
<GrueMaster> tgardner: I'm seeing an issue with the marvel-dove kernel updates for Lucid & Maverick (same kernel I believe).  On both systems, the console is severely corrupted.
<GrueMaster> I'm remarking bug 712610 as verification-failed and adding a screenshot & comment.
<ubot2> Launchpad bug 712610 in linux-mvl-dove "linux-mvl-dove:2.6.32-214.30 -proposed tracker" [Undecided,Fix committed] https://launchpad.net/bugs/712610
<tgardner> GrueMaster, I replied in the bug.
<GrueMaster> tgardner: I added my reply.  From what I can see, the latest pull is breaking, and the previous kernel in Maverick seems to be the most recent working kernel.  It is 2.6.32-410.27.
<GrueMaster> I don't know of any kernels beyond that and I have all kernels for maverick on my image.
<tgardner> GrueMaster, ok, I'll start producing some bisected kernels, but it won't be until tomorrow.
<GrueMaster> NP.  I have plenty of other kernel updates to test recently.  :P
<GrueMaster> BTW:  Will there be a marvel kernel update for Karmic?  If not, don't bother.  I just haven't seen one.
<GrueMaster> I don't think anyone really used that image anyways.
<tgardner> GrueMaster, I'll probably only do CVEs for Karmic, no stable updates. It falls outside the support window after 11.04 is released.
<GrueMaster> If there is anything that needs testing, I will need to know as I currently do not have a system setup for it.  I don't even have a karmic image.
<tgardner> GrueMaster, well, then. I won't worry about it too much.
<GrueMaster> k
 * jjohansen -> lunch
<tgardner> smb, did you compile test 'bluetooth: Fix missing NULL check, CVE-2010-4242' on Dapper ?
<ubot2> tgardner: The hci_uart_tty_open function in the HCI UART driver (drivers/bluetooth/hci_ldisc.c) in the Linux kernel 2.6.36, and possibly other versions, does not verify whether the tty has a write operation, which allows local users to cause a denial of service (NULL pointer dereference) via vectors related to the Bluetooth driver. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4242)
<akgraner> apw don't hate me but guess what is happening again...I'll see what information I can get you.  I applied some updates this morning (not sure if that's important or not) and now my machine is topping 80C and it shuts off :-(  
<apw> akgraner, still on maverick ?
<akgraner> yep
<akgraner> apw, I'm to nervous to switch to natty when I only have one computer...
<apw> akgraner, indeed ... can we have a new bug, so i can mark it as a regression
<apw> akgraner, do you have -proposed enabled or just -updates?
<apw> akgraner, include the previous kernel version which is known to be good for comparison
<akgraner> -updates
<akgraner> ok I'll file a new bug and start the testing process :-)
<bjf> apw, akgraner could try -proposed, there were a bunch of stable upstream patches in it, don't know if any were related
<apw> yeah feel free to install just the kernel from -proposed rather than enabling everything
 * bjf crosses his fingers
<apw> indeed
<akgraner> bjf,apw cool I don't mind trying different kernels it's sorta fun these days :-)  apw has taught me well..
<apw> though her issue therefore is regression-updates which is bad
<apw> akgraner, abused you enough :)
<akgraner> apw - I'll get you a bug and some more information by in the morning - thank you!
<sconklin> in the meantime, cook a sandwich on it
 * apw will leave you in sconklin's capable hands :)
<apw> sconklin, sounds like a regression-update
<sconklin> apw: noted
<sconklin> apw: I've cleared ten bugs off the list so far
<apw> sconklin, good going
<apw> i'd say thats plenty for one day ... its only officially 4 hours
<sconklin> well, I'm into one more and then I think I'm done.
<sconklin> unless it's really ugly then I'll punt it
<sconklin> ;)
<apw> 6 closed ... nice
<sconklin> apw: heh, the last comment in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/49052 is actually a question for you
<ubot2> Ubuntu bug 49052 in linux "no hfs+ journal write support by default (gets mounted as read only)" [Undecided,Confirmed]
<apw> for me ?  heh
<sconklin> but I suspect I can answer it as easily
<apw> yeah MAINTAINERS is your friend
<apw> thanks for cleaning up after me
<sconklin> which mailing list do patch pilot reports get sent to?
<sconklin> nm, u-devel
<apw> sconklin, dunno, don't do them myself
<herton> apw, for next natty kernel it may be good to rebase again, there was a new fix for the fix of BUG_ON in path lookup
<herton> commit 3abb17e
<apw> oh can't those people do anything right?
<herton> hehe
<apw> i have all the test builds for the next upload about done
<apw> this would make me mad
<apw> herton, i think i'll just cherry that one fix
<apw> and go with that
<herton> yeah, should be fine
<herton> I tested without that fix in two machines and didn't experience problems, but some people can have, like reported on LKML
<apw> yeah as i have not yet pushed, i may as well restart my cycle, only an 1.5hrs wasted
<apw> herton, thanks for the heads up, that was timely
<alex_> Hi guys , I am looking for a little bit of help
<alex_> I bought an atsc card , and I didnot manage to use corectly em28xx kernel module
<alex_> anyone could help me to make it work ?
<alex_> Here is my lsusb output
<alex_> Bus 002 Device 003: ID eb1a:2875 eMPIA Technology, Inc.  
#ubuntu-kernel 2011-02-17
<htorque> hello everyone! i'm facing a significant boot time regression with the 2.6.38 kernels: http://img.xrmb2.net/images/274432.png (hybrid laptop) - is this something known?
<apw> htorque, nope that isn't known
<apw> htorque, are those two graphs with the identicle userspace ?
<apw> htorque, although plymouthd is fingered, it is a process which simply waits
<htorque> apw, yes, identical userspace on all four
<htorque> apw, i'd like to open a bug report on this, but i don't know for which component - linux (upstream?), plymouth?
<apw> htorque, indeed tricky, as plymouth is likely just blamed cause it waits for the display to appear i am inclined not to blame it without seeing the rest of the images
<apw> can i see the whole boot charts in each of the two you pasted before
<apw> 37-12 against 38-1
<apw> i think it was
<htorque> sure, wait a sec (38-3 it is)
<htorque> apw, intel: http://img.xrmb2.net/images/100556.png vs. http://img.xrmb2.net/images/217302.png - nvidia: http://img.xrmb2.net/images/306234.png vs. http://img.xrmb2.net/images/502469.png
<apw> htorque, there doesn't seem to be anything specific occuring in the two slow images in userspace.  the only apparent oddity is there is a kworker running for most of the 'gap' period on both image ... i am suspicious it is related but it is very hard to tell from these
<apw> kworker/3:0 in the intel case and kworker/1:0 is shown slightly coloured for about 8 or so seconds
<apw> unsure what the colour represents as there is nothing in the top graph then
<apw> htorque, is there anything in the dmesg of the slow version?  can i see a dmesg off the intel one for the boot
<htorque> the light red should be unint. sleep, but i'm not sure - it's definitely not i/o
<apw> htm
<htorque> apw, http://paste.ubuntu.com/568091/
<apw> htorque, this was -3.30 yes ?
<htorque> -38.3.17
<apw> it is 3.30 ... ok
<htorque> ah, sorry, checked the wrong package :)
<htorque> apw, i have to leave for ~2h, will stay on though
<TeTeT> is linux-crashdump broken on Natty? I try to force a kernel crash dump (customer interest), following https://wiki.ubuntu.com/Kernel/CrashdumpRecipe but I don't get a crash image in /var/crash
<TeTeT> kernel in use is 2.6.38-3-generic, linux-crashdump is 2.6.38.3.17
<smb> There seems to be some brokeness in every release
<smb> (and not enought time to play around with it to get it fixed)
 * smb thinks its broken at least in Lucid as well
<TeTeT> smb: any hints on how to get this fixed?
<smb> TeTeT, Since we rarely use it its not that high on our list. Would need someone to sit down and look at it and frankly we got enough other things that we have to look at. :/
<apw> TeTeT, i'd say mostly we arn't aware which releases it does and does not work, this implies it is not a heavily used feature (no one screaming for it) and thus not a high propority
<TeTeT> smb+apw: ok, the query was motivated by a customer's employee that attended a linux debugging class last week, so it's not a high prio either - btw the class was run on opensuse, there the crashdump stuff seems to work
<TeTeT> smb: thanks for the detailed instructions on bug 539467, will give it a try right away
<ubot2> Launchpad bug 539467 in linux "SATA link power management causes disk errors and corruption" [Medium,Confirmed] https://launchpad.net/bugs/539467
<smb> TeTeT, ok thanks
<TREllis> I have a case where a certified system has suspend broken in Lucid, there is a SUSPEND_MODULES workaround and the bug ()522998 is set to won't fix for Lucid
<TREllis> what are the options?
<htorque> apw, that kworker process is indeed in state D (i made pybootchartgui paint unint. sleep in a different color) - is there any way i can find out what it's doing? profile it somehow?
<tgardner> cking, AceLan_: need to bounce tangerine for SSL security update
<cking> ok
<cking> tgardner, I'm off
<tgardner> cking, I know :)
<cking> I just like filling this channel with pointless information ;-)
<apw> cking, but what are you off, your food ?
<apw> htorque, tricky as it doesn't continue after boot hrm
<tgardner> smb, are you pushing maverick meta?
<tgardner> nm, just saw the email
<smb> tgardner, Look into your latest copy of the inbox. :)
<smb> tgardner, Just did not get to it before the break
<apw> htorque, i have profiled a couple of my systems (intel) with the 37-12 and 38-3 kernels and cannot see any difference, cirtainly not that kworkerd lit up
<apw> tgardner, any idea which timezone jbarnes is in?
<tgardner> apwhe lives in pdx 
<apw> tgardner, thought he might
<tgardner> apw: damn tab completion
<tgardner> apw: or at least, I think he works at Jones Farm last I knew
<apw> heh, normally for me it pings someone unrelated
<apw> at least you didn't do that :)
<tgardner> apw: well, if I didn't have to stare at my keyboard whilst typing...
<apw> tgardner, those pesky keys, they tend to move around i find
<tgardner> mmm, snarky
<htorque> apw, just compiled -rc5 (with ubuntu .config) and got some oopses at the time when plymouthd stops in those charts - they point to this bug https://bugzilla.kernel.org/show_bug.cgi?id=26232
<ubot2> bugzilla.kernel.org bug 26232 in Console/Framebuffers "Multiple framebuffer oops and sysfs attribute deadlock" [Normal,New]
<htorque> weird thing, i see no such messages with the ubuntu kernels
<htorque> could this be the problem (i'm currently re-compiling using those two patches)?
<apw> htorque, yep without the fixes we have for open/close of framebuffers you will hit all kinds of races
<apw> we get to framebuffer opens much earlier than most distros
<apw> i have fixes which i need to push up
<apw> htorque, there is a -4 kernel building in the archive you could test
<htorque> apw, ok, so that isn't the problem then (stopping the kernel build :-))
<htorque> apw, yeah will try
<apw> htorque, nope, those are just fookages in mainline, clear bugs
<htorque> apw, no luck, same with -4
<apw> htorque, ok... file a bug pls with the latest diagrams attached
<htorque> at LP?
<apw> sure
<htorque> ok, will do, thanks!
<apw> file it against linux for the time being as kworkerd is the most suspicious thing on there
<apw> plus you are only chanign the kernel to get behaviour
<apw> htorque, please include the info that there are intel and nvidia machines
<htorque> actually it's the same machine with both gpus (hybrid)
<apw> htorque, oh, not a mac is it .?
<htorque> no, it's a thinkpad t510
<htorque> (they can boot with either gpu while the other one is really switched off - unlike some other hybrid laptops from acer, sony, etc.)
<htorque> apw, do you think it's worth it doing kernel bisecting?
<apw> htorque, probabally the only way
<htorque> apw, never done this with ubuntu kernel sources - is ubuntu/ubuntu-natty.git the right one?
<apw> htorque, yeah but you will find it hard to bisect cause of the ubuntu delta
<apw> can you remind me, this issue appears in -1 yes ?
<apw> and can you see the kworker slowness on the mainline boot
<apw> even though it oopses ?
<apw> as its easier to bisect at that level
<htorque> yes, started with -1 and yes, even with the oops i see the kworker thing
<htorque> *rc1
<apw> htorque, ok then i have the infrastucture to do bisect builds between 2.6.37 and 2.6.38-rc1
<apw> htorque, wahts the bug number
<htorque> not done yet
<apw> so run ubuntu-bug linux when running -5
<apw> and get me the bug number
<apw> and i'll get building you a bisect kernel
<htorque> -5? or -4?
<htorque> apw, i have a small kernel config for this machine which builds in ~15 minutes, if i see the bug with it i could certainly do it locally without a pain
<apw> htorque, ok then thats fine
<apw> -4 sorry missed
<apw> htorque, if you can do it in 15mins then it makes most sense for you to do it
<htorque> apw, bug report will need some time as apport complains about -4 not being a genuine ubuntu package
 * apw SHOUTS AT LAUNCHPAD
<apw> launchpad get the hell out of my way and let me do my job
<sforshee> I could use some advice debugging a hang on resume with a toshiba netbook with an Atom N450. The machine hangs for 5 minutes on resume (exactly how long it takes for the lower 32 bits of the hpet to wrap on this machine). The hang happens when executing the acpi WAK method. Booting with "nohz=off highres=off" makes the hang go away, and one difference is that the hpet is put in periodic mode instead of oneshot mode during r
<sforshee> esume. Booting with hpet=disable doesn't fix the hang during resume, in fact machine never resumes. But performance is much better with hpet=disable or nohz=off. Any suggestions?
<cking> sforshee, what model is it?
<sforshee> cking, nb 305
<cking> sforshee, does "nohz=off highres=off noapic" work?
<cking> oops, you said it does.
<sforshee> cking, "nohz=off highres=off", I probably haven't tried with all three
<cking> sforshee, try "irqpoll" instead of "noapic" too
<mjg59> Probably the same hpet polarity thing
<sforshee> cking, ack
<cking> sounds like it
<sforshee> mjg59, that's a strong possibility, although the workaround that worked on the AMD-based machines doesn't work here
<sforshee> the workaround being acpi_skip_timer_override
<smb> That could be if the interrupt the timer then ends up on has the wrong polarity set too
<sforshee> did a proper workaround for the hpet polarity issue ever turn up?
<smb> not that I saw one
<smb> And Andreas seems either to ignore me or being on vacation
<mjg59> Although it's an Intel chipset rather than an AMD one
<mjg59> So...
<smb> (one could suspect Toshiba may be do it wrong even on Intel) but a fix for that unlikely will come from Andreas for sure
<sforshee> in general things just seem to be bad on this machine when the hpet is on oneshot mode, in periodic mode things seem much better
<tgardner> sconklin, bjf: I uploaded linux-meta for lucid/maverick for bug #720139
<ubot2> Launchpad bug 720139 in linux-meta "Kernel meta packages are built for wrong architectures." [Undecided,Fix committed] https://launchpad.net/bugs/720139
<sconklin> tgardner: we should replace the one in proposed, right?
<bjf> tgardner, once they've built do you want us to coordinate with pitti or will you ?
<tgardner> sconklin, I uploaded straight to the archive and bypassed the c-k-t PPA
<tgardner> it should just go through the normal channels
<sconklin> I thought everything had to go through the ppa so it is built against -security packages. Although for meta I don't think there could be a conflict
<tgardner> sconklin, linux-meta has no dependencies so I think we're OK
<cking> mjg59, so is this polarity setting wrong because it's mis-configured in the MP configuration table? Or am I way off here?
<mjg59> I'd guess
<mjg59> Or wherever we get the default polarities from on APIC systems
 * cking gets reading the MP spec...
<cking> Nothing is trivial in this domain
<sforshee> cking, mjg59, there is an override in the MP configuration table for the toshiba
<sforshee> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
<sforshee> [    0.000000] Int: type 0, pol 1, trig 1, bus 00, IRQ 00, APIC ID 2, APIC INT 02
<sforshee> I'm preparing a test build to override what's in the MP table, any guesses what triggering I should use?
<cking> sforshee, well, its a 50/50 guess isn't it?
<sforshee> cking, well, if polarity is the only problem
<sforshee> there's also edge vs. level
<sforshee> one option can be eliminated right away, though :)
<sforshee> i'm starting with only changing polarity
<jamespage> I'm hoping someone on channel can clear up some confusion re kernel names for ubuntu server
<jamespage> So (and this is all for lucid) for the minimal virtual install the linux-image-virtual package gets installed
<jamespage> this is nice and small (thats all OK) but uname -r returns a -server kernel name - is this correct?  the current ISO test case says it should return -virtual
<tgardner> jamespage, for Lucid the virtual package was distilled from server binaries
<tgardner> so, there is no -virtual kernel per se
<jamespage> excellent :-); hggdh  - can we get the test case updated for next time?
<jamespage> tgardner: has this changed in maverick or natty?
<tgardner> jamespage, note that maverick and subsequent releases _will_ have a -vertual kernel
<jamespage> tgardner: thanks for clearing that up for us
<hggdh> jamespage: I will update the test with a caveat on lucid
<jamespage> hggdh: marvellous!
<hggdh> OK, another question. the i386 ISO (at least on Lucid, probably valid onwards) defaults to always installing -pae. Is this correct?
<tgardner> hggdh, The ISO boots the non-pae kernel IIRC, then detects the platform capabilities and installs accordingly IIRC. cjwatson or ev could probably answer deep installer questions like taht.
<hggdh> tgardner: thank you
<cking> sforshee-lunch, once you get some insight, please let me know via email. meanwhile I think I should dig into seeing if we can make this testable from fwts
 * tgardner --> lunch
<JFo> <- headed to lunch
<cking> everyone is making me feel hungry
<apw> cking, its your dinner time, go away and don't come back
<cking> yessir!
<apw> i am watching
<cking> and...
<sforshee> cking, will do, so far I've tested edge-low triggering with no luck, moving on to level triggering now
<cking> sforshee, ta
<Darxus> "make install" doesn't work (doesn't update grub) in Maverick, right?  It looks like it does in Natty?
<tgardner> Darxus, yep, I fixed the package for natty
<Darxus> tgardner: Nice, thanks.
<tgardner> Darxus, you can fix maverick by just copying /sbin/installkernel from Natty
<Darxus> tgardner: Yeah, looks like the only significant difference is the run-parts line?
<Darxus> Any chance of that getting into Maverick?
<tgardner> Darxus, IIRC
<tgardner> Darxus, unlikely, since its really a developer tool.
<Darxus> Okay, thanks.
<GrueMaster> tgardner: On bug 720189, I don't believe marvel (or any ubuntu supported platforms) use it.  It looks like the Amiga serial port driver.
<ubot2> Launchpad bug 720189 in linux-lts-backport-maverick "CVE-2010-4076" [Undecided,In progress] https://launchpad.net/bugs/720189
<GrueMaster> (and marvel kernel is on 2.6.32).
<tgardner> GrueMaster, the CVE description is a bit misleading. the patch actually cleans up a generic TTY vulnerability.
<GrueMaster> Ah.  Because the bug was against amiserial.c.  That's how I was confused.
<tgardner> GrueMaster, I'm still considering what to do with mvl-dove regression. I'm considering just backing out stable updates and just do CVEs (which is all that were are contractually obligated for)
<GrueMaster> That would be my suggestion.
<GrueMaster> Especially considering they are doing hardware changes that we can't follow.
<tgardner> GrueMaster, cool. I'll get started...
 * jjohansen -> lunch
<htorque> apw, git bisect suggests http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=commit;h=23d69b09b78c4876e134f104a3814c30747c53f1 - does this make any sense? (i'll re-compile the enclosing commits to confirm)
<skaet_> rtg,  can someone have a quick look at  https://launchpad.net/bugs/720865
<ubot2> Ubuntu bug 720865 in linux "kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" [Undecided,New]
<skaet_> tgardner, ^^
<tgardner> skaet_, ack
<skaet_> thanks!
<apw> htorque, it seems to be a merge, i am supprised it would tell you it was that one
<apw> though i am not supprised if one of the commits that was merged is the culprit
<apw> normally though i would expect it to try and select which of the merged commits is at fault
<htorque> apw, yeah, unfortunately git-bisect stopped at that point. anyways, that's what i'm planning to do after i double checked it's the right one.
<apw> yeah i guess start with the 'right hand side of the merge as a 'bad' and probabally pick something old as good :)
<GrueMaster> tgardner: Out of curiosity, I am currently subscribed to linux-mrvl-dove, which has generated a recent spat of CVE spam.  I assume you are running a script to push these?  If so, you may want to modify it to automatically exclude natty for dove, as it is not supported at this time.
<tgardner> GrueMaster, you're assuming launchpad has that flexibility. besides, I'm having  to do the whole damn thing by hand.
<GrueMaster> Oh, oops.  :P
<GrueMaster> Wasn't trying to nit pick.  Just thought it was semi-automated.  No problems.
<tgardner> GrueMaster, just uploaded Lucid mvl-dove to https://launchpad.net/~canonical-kernel-team/+archive/ppa, so see if you can install it tomorrow (assuming it builds OK)
<GrueMaster> Will do.
<GrueMaster> Will it be the same package for Maverick (assuming since they are the same code base)?
<tgardner> GrueMaster, yep, identical code base, different compiler
<GrueMaster> So, with all these recent patches for dove kernels, is anyone updating linux-image-imx51 (karmic, lucid), linux-image-omap (lucid, maverick) or linux-image-omap4 (maverick, natty)?
#ubuntu-kernel 2011-02-18
<Whinis> My custom kernel spits out a wierd mountall and plymouth error
<Whinis> could not connect to upstart: could not open socket: address family not supported by protocol
 * apw yawns
 * smb is beyond thatzzzzz
 * amitk throws resistors into apw's gaping mouth
<amitk> that's all I had lying around :)
<smb> amitk, Amazing what kind of stuff _you_ have lying around. :)
<apw> its a while since i had any of those 
<apw> or indeed a use for the
<apw> them
<amitk> heh
<apw> > #ifdef BTN_TRIGGER_HAPPY
 * apw reminises ... how did you get that past them
 * smb just proposed...
<smb> ... and apparently there was no better name for the need of more than 40 buttons on a joystick
 * apw smiles about the name
<apw> smb, oh while i remember ... did that email go out abuot the SATA ALPM ?
<soren> apw: Would you guys object terribly to including the netfilter ipset patch in the kernel?
<apw> soren, which one is that, got a pointer ?  and in which kernel?
<soren> apw: Natty (and onwards, possibly).
 * soren finds link
<soren> http://ipset.netfilter.org/
<apw> is it going upsteream?
<apw> and what does it do, why do we need it
<soren> It's a more efficient way to apply an iptables filter to a (large) set of IP's.
<soren> Instead of having a rule per IP, you have a rule pointing to the ip set.
<soren> The ip sets are implemented using more efficient data types.
<soren> Like a hash or whatnot.
<soren> So instead of having to traverse through hundreds of individual iptables rules, you just have one with a very efficient lookup.
<apw> mostly out acceptance of that kind of thing depend on it being something which is on its way upstream, that it is not intrusive and is well maintained; and there is someone asking for it
<soren> It's not intrusive at all. It can build completely out-of-tree.
<apw> so i wonder if a dkms package might be more appropriate ...
<soren> I'm not sure if it's on its way upstream. I tried asking upstream at some point, but never got a response. It's actively maintained, though.
<soren> DKMS is certainly possible.
<apw> but the normal first step is to propose the thing o
<apw> on kernel-team@, preferablly including the patch
<soren> Sure.
<apw> hows it all going ?  obviously got a lot of machines if you need that :)
<soren> I was just trying to float the idea to gauge whether I should bother at all :)
<apw> even if we say no, at least noone else needs to ask the reasons if we have them in public
<soren> Indeed.
<soren> I try to avoid hardware. It's nice and quiet in my office without server fans drilling into my ears.
<soren> :)
<smb> tgardner, Rhetorical question: the last time you did an ABI bump in Hardy was longer time ago, wasn't it?
<tgardner> smb, um, I think I pushed one recently. lemme check
<smb> tgardner, Yep, that is the one you broke. :)
<tgardner> smb, what do you mean?
<apw> smb, is hardy the one we still ahve the result files checked in?
 * smb reminds tgardner that Hardy has all this generated files checked into the tree still
<smb> yep,
<smb> I got things here, will fix it up
<apw> at least we have -next rebase allowed ness now
<tgardner> smb, I've been building hardy, so I thought it was correct. what did I miss?
<smb> Yeah, 
<apw> tgardner, the issue is if you clean it works just fine
<smb> tgardner,  Oh just those control control.stub and d-i stuff
<apw> but if you just make it can leave the unchanged files ... all depends on dates
<tgardner> frick
<smb> Just give me a second and next is good
<apw> JFo, shall we dance on the balcony
<JFo> sure
<smb> tgardner, done
<tgardner> smb, pulled
<tgardner> smb, did I get dapper right?
<smb> tgardner, Not build tested yet. That will be next
<smb> tgardner, It looks right though
<tgardner> will wonders never cease ?
<JFo> you're just that good tgardner :)
<bjf> smb, new version checked in and pushed, give it a try
<bjf> smb, if i can get it working for you, i figure it will work for the others as well :-)
<smb> tgardner, Would you want the honors? I am done with my CVE this week... :-P
<tgardner> smb, I'll try it with the next one.
<bjf> smb, if you use the "--staging" flag, you can use the same cve number and it will create the bug on the staging server
<smb> bjf, Right, true. Ok, a sec
<smb> bjf, lpltk.service.LaunchpadServiceError
<bjf> smb, ok, let me do some real debugging and not just some hacking
<smb> bjf, Ok, it seems the error comes from reset in lpltk so it could be just lp being broken
<smb> Oh wait that _is_ the default isn't it. :)
<bjf> smb, the staging server is: "Code Update In Progress", took me a bit to run that down
<smb> bjf, Ph well, so broken by default was true. Thanks for digging into that
<tgardner> GrueMaster, Lucid linux-mvl-dove is built at https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages. Please test it. thanks.
<GrueMaster> Already loaded.  Just getting ready to head to the basement to verify console screen output.  Thanks.
<apw> yay interlock is working
 * JFo goes to check on the updates on his natty netbook. brb
<GrueMaster> tgardner: Still not right.  Same console screen corruption.
<tgardner> GrueMaster, hmm, you're _really_ sure the previous kernel doesn't exhibit this issue? I wonder if I rebuilt the previous version using current Lucid toolchain etc if it would also have the console problem.
<GrueMaster> I just rebooted and reverified (lots of stairs were involved).
<GrueMaster> The working kernel for lucid on dove is 2.6.32-209.25
<GrueMaster> I wonder if there is something that needs to be done for plymouth?
<tgardner> GrueMaster, well shit, 2.6.32-209.25 isn't exactly the previous kernel. there are at least 4 versions after that. I wonder which one broke the console?
<GrueMaster> The only one that apt-cache shows in between 209 and 214 is 211.  I was never notified of it, but I can install and test it.
<tgardner> GrueMaster, do you have 210.26, 211.27,  212,28,  or 213.29 ? I can rebuild them if not.
<GrueMaster> linux-image-2.6.32-211-dove_2.6.32-211.27_armel.deb is the one being pulled from archive.
<tgardner> GrueMaster, probably 'cause they never got promoted. Are you pulling from -proposed?
<GrueMaster> Let me see if it passes or fails, then we can go from there.
<GrueMaster> Yes I am.  But my system is in the basement in a rack cabinet now, and unless I am notified of updates, I don't test them.
<tgardner> GrueMaster, does _anyone_ else have this HW? Someone in the community?
<GrueMaster> I think the only other hw I know of is OEM, but it is not marvel test platform.  They have an OEM system.
<tgardner> I'm wondering why I'm spending time on it otherwise
<GrueMaster> I haven't heard of any dove based systems in the wild yet.
<GrueMaster> heh, same here.  :P
<tgardner> lemme chat up David.
<GrueMaster> (which is also why I recommend ignoring karmic).
<tgardner> karmic is already abandoned
<tgardner> for mvl-doce that is
<GrueMaster> yea!
<tgardner> dove*
<GrueMaster> That saves me a LOT of headache.  I don't have an image atm.  Not even a mirrored copy to boot with.  I would have to start from scratch.
<GrueMaster> Ok, relocated to basement.  linux-image-2.6.32-211-dove_2.6.32-211.27_armel.deb is running with no console corruption.
<GrueMaster> tgardner: I'll setup my panda systems to do builds and test the kernels in between pass & fail (unless I can find them on lp).
<GrueMaster> I can build faster than the buildds.
<tgardner> GrueMaster, I can cross-compile or use qemu to build in just a few minutes.
<GrueMaster> Wel, that would be even faster then.  :P
<tgardner> GrueMaster, I'm emailing David to verify we even need to do this.
<GrueMaster> He's in #arm is you want to ping him directly.
<tgardner> GrueMaster, I can't type that fast, so I'll just annoy him with email
<GrueMaster> heh
<JFo> k, gonna try to grab some lunch on time today for a change. :-)
<JFo> bbiab
<GrueMaster> tgardner: Looks like 2.6.212 also fails.  That narrows it down.  I got it here:  https://launchpad.net/ubuntu/+source/linux-mvl-dove/2.6.32-212.28/+buildjob/2064004
<htorque_> apw, hi, just had some time for bug 721389 i cloned the branch that got merged (which definitely is the first bad commit in linus' tree) and it doesn't show the problem
<ubot2> Launchpad bug 721389 in linux "Boot time regression 2.6.38" [Undecided,New] https://launchpad.net/bugs/721389
<htorque_> should i now incrementally test all 33 commits that were part of that merge on linus' tree (after the last good commit)?
<apw> htorque_, you should be able to bisect the branch too
<apw> but yes
<htorque_> apw, the last commit of that branch is good, so i don't know what to bisect for
<apw> ?
<apw> oh hrm
<apw> wibble
<apw> so an interaction between the two, does the commit itself have any diff ?
<apw> could it be a merge error
<apw> htorque_, ok what prolly would do next
<apw> then as the branch is fine, but the merge of it is not
<apw> is to checkout the commit before the merge, then cherry-pick all of the 33 onto the top, not merge them
<apw> and then test that, if it fails, you can then bisect over that
<htorque_> apw: thanks, will do :-)
<jj-afk> back in a bit
<tgardner> bjf, Traceback (most recent call last):
<tgardner>   File "./create-cve-tracker", line 219, in <module>
<tgardner>     app.main()
<tgardner>   File "./create-cve-tracker", line 167, in main
<tgardner>     bug = self.lp.create_bug(project='ubuntu', package='linux', title=title, description=description, tags=tags)
<tgardner> TypeError: create_bug() got an unexpected keyword argument 'tags'
<htorque> apw: if i haven't screwed up: after applying all the patches the resulting kernel doesn't show the bug
<apw> wibble
 * tgardner --> lunch
<blag> im trying to build the ubuntu maverick kernel from git, but it keeps telling me to run "make mrproper", which blows out the debian/ directory, which means the command "fakeroot debian/rules binary-generic" from https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel fails.  how do I build a .deb file of the ubuntu kernel by just using make?
<jjohansen> blag: you have something messed up, this happens occasionally
<jjohansen> if you are in the git tree this trick usually works
<jjohansen> run make mrproper and then do a git checkout -f
<jjohansen> it will restore the debian directory, and you should be able to build
<blag> jjohansen: looks like it worked, thanks!
 * jjohansen -> lunch
<sforshee> blag, I usually use 'git clean -xfd' in that situation, which seems a little easier and also won't blow away local changes
<blag> sforshee: ill have to try that
<sconklin> sforshee, blag: git clean -dxf will delete untracked files, unless I'm mistaken
<sconklin> so try it in a place you don't care about ;)
<sforshee> sconklin, isn't that the point?
<sforshee> it's no worse than 'make mrproper' as was suggested before
<sconklin> sorry I misread "local changes"
<sforshee> yeah, if you have new files they will be blown away, that's a good clarification to throw in
<sconklin> http://twitter.com/#!/ubuntustatus
<sconklin> ^^ don't upgrade Natty rigth now
<JFo> ugh
<tgardner> sforshee, I use a sledge hammer to make sure my trees are clean. This works across all versions of git:
<tgardner> git checkout -f
<tgardner> git clean -f -d
<tgardner> git ls-files --others --directory |xargs rm -rf
<tgardner> rm -rf .git/rebase*
<sforshee> tgardner, that's certainly thorough :)
<janimo> which package sets up the 'Restart Needed' notification after certain kernel upgrades?
<tgardner> janimo, ask in #ubuntu-devel 'cause I can't remember.
<janimo> tgardner, ah so it is not part of the kernel packaging then? Not one of your dpkg hooks?
<tgardner> janimo, I'm sure its a hook somewhere in the packaging, I just can't remember where.
<tgardner> bjf[afk], the nominations fix works for me
<vanhoof> quick question hopefully :)
<vanhoof> right now if you file a kernel bug, it lands under 'linux', which is the latest release, natty
<JFo> famous last words vanhoof 
<JFo> true
<vanhoof> sub tasks can be opened against prior releases ... maverick, lucid, etc
<JFo> yep
<vanhoof> now say something doesnt get fixed in natty (linux) at this point in time
<JFo> you can open a Natty task now as well
<vanhoof> after the natty release, would those tasks be moved to a sub task of natty, and the original task migrated to the 'o' release?
<JFo> and the main task will show "Status tracked in Natty"
<JFo> no, you would need to add it
<vanhoof> ah ok
<JFo> it would be nice to have that
<JFo> :-)
<vanhoof> heh
<vanhoof> im just looking at historical data for bugs we've got fixed, sometimes things get filed under linux (applied in natty), and then fix released
<vanhoof> i'm wondering if i go back in time, will i be able to find those by searching under natty
<JFo> no
<vanhoof> sounds like if i want that data i need to have natty tasks opened as well
<JFo> I wish, but no
<JFo> yep, that would be the best way
<JFo> best== easiest
<vanhoof> cool, thanks JFo :)
<JFo> my pleasure vanhoof :)
 * tgardner has pretty much had his fill of CVE tedium
<tgardner> bjf, so, are you considering adding all of the relevant linux package names to create-cve-tracker ?
<bjf> yes, it's on my todo list
<bjf> tgardner, ^
<tgardner> bjf, cool. see you Tuesday.
#ubuntu-kernel 2011-02-19
<Guest40084> http://ubuntuforums.org/showthread.php?t=1592062  .. Could someone explain me post #8?
<dupondje> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9f4283f49f0a96a64c5a45fe56f0f8c942885eef we need this asap :)
<dupondje> somebody from the kernel team alive ?
<ledbettj> any clue why a mini pcie card would not be identified during boot, but only if a rescan is forced via /sys/bus/pci/rescan ?
#ubuntu-kernel 2011-02-20
<blag> im trying to get a patch ready for both upstream inclusion and the ubuntu kernel devs for ubuntu-maverick, but checkpatch.pl keep complaining that my patch is unsigned.  how do i sign my patch (creating with git diff)?
<blag> *created
<blag> i have a patch for the current ubuntu maverick kernel.  should i upstream it directly to the linux kernel devs, or should i upstream it to the ubuntu kernel devs, or both?
<blag> nevermind, i just took a look at the linux kernel upstream, and theyve already fixed it.  :-)
<penguin42> it might be worth keeping an eye out for other cases of bug 721996
<ubot2> Launchpad bug 721996 in linux "CMOS crc error on next boot" [Undecided,New] https://launchpad.net/bugs/721996
<penguin42> seems to have started for him in 2.6.38-1
<EntropyReduction> Hello.  I think I may have a kernel bug on Maverick kernels post-2.6.35-22.  Reported it at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/719446.  Dave Gilbert as sent out the default request for a test on latest development release of Ubuntu, and the latest upstream kernel.  But he also suggests that at least doing the former has a change of trashing my existing installation, which...
<ubot2> Launchpad bug 719446 in linux "systematic freezes on any kernel version post 2.6.35-22 " [Undecided,New]
<EntropyReduction> ...I'm not very excited about doing.  
<EntropyReduction> How dangerous is it to try a development release of Ubuntu?  How about trying latest upstream kernel?  I know these may be "how long is piece of string" questions, but forgive a ubuntu newbie...
<penguin42> EntropyReduction: Well, it's difficult to say, but make sure you 1) have a backup 2) Know how to undo it
<penguin42> EntropyReduction: You could hit some corruption bug that nuked the whole install - but it's unlikely
<EntropyReduction> That's the problem: I don't yet have a way of backing up my partitions yet; on my "to learn how to do" list but not there yet
<penguin42> EntropyReduction: Trying a development kernel it should be easy to switch back to using the normal kernel (it'll just be in the grub menu); trying a development release is not really recoverable if it breaks
<penguin42> EntropyReduction: OK, stop what  you're doing - NOW - and get yourself a way of doing backups of your most important data
<penguin42> EntropyReduction: Backups are good!
<EntropyReduction> I got spara empty space n my laptop hard disk; I could install dev release into a new partition, assuming installer would be smart enough to just update existing grub stuff.  That feasible -- and safe?
<penguin42> no, installers go wrong and can nuke other partitions - rare but it happens
<penguin42> (but still safer than just upgrading)
<EntropyReduction> Oh I got data backup, that's not a problem; in fact this laptop is secondary to my main machines (all windoz), so don't even carry up to date copies of my data.  What I'd rather not have to do is wade through all the ubuntu stuff again.  It's fun to install VirtualBox for the first time, I didn;t mind rebuilding my VMs for the third time, but a fifth time would get boring.  Not to mention...
<EntropyReduction> ...nautilus scripts, etc etc etc
<penguin42> EntropyReduction: OK, so installing a deve kernel is _unlikely_ to destroy anything and is easy to switch back from
<penguin42> EntropyReduction: Upgrading to a development release can be a bit of a killer if it doesn't like your machine or it's currently broken, although installing in a seaprate partition is _normally_ ok
<EntropyReduction> ok, I think I'll go for dev kernel.  
<EntropyReduction> I was directed here to find the right one:
<EntropyReduction> https://wiki.ubuntu.com/KernelMainlineBuilds
<EntropyReduction> which rather confused me.  But looks like maybe what I want is
<EntropyReduction> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
<EntropyReduction> ?
<penguin42> EntropyReduction: Are you Alan Campbell of bug 719446?
<ubot2> Launchpad bug 719446 in linux "systematic freezes on any kernel version post 2.6.35-22 " [Undecided,New] https://launchpad.net/bugs/719446
<EntropyReduction> yup
<penguin42> EntropyReduction: Dave Gilbert - hi
<penguin42> EntropyReduction: So yeh, use the package from that ppa - that should let you try the latest kernel on maverick
<penguin42> EntropyReduction: And it'll just add another entropy into grub, so make sure you know how to get into grub to choose your kernel and you can easily flip back to the normal kernel
<EntropyReduction> Oh, hi: so penguin42 == Dave Gilbert?
 * penguin42 nods
<EntropyReduction> Yeah, got that, and have grub configured to default to 2.6.35-22 (although I notice when a new kernel version comes in I gotta remember to reconfigure it) -- but yeah, I'm on top (??) of that
<penguin42> if you add a new kernel version it should land in the grub menu
<EntropyReduction> OKay, many thanks for hand-holding.  Back to you next week after I've had a go, and will also try to capture console output and forward that as well.
<penguin42> good luck
<EntropyReduction> Re grub: yeah, new kernel goes in at top of menu, but somehow the pointer that remembers which grub alternative is the default gets thrown off by one, and I have to remember to reset it (I haven;t got down to level of editing grub config file, I use Startup Manager.
<EntropyReduction> anyway, many thanks
#ubuntu-kernel 2012-02-13
<apw> lamont, perhaps throw it over to lvm, as it sounds like it could be more helpful in that situation
<smb> apw, morning
<apw> smb, moin ... yawn
 * apw watches another 100 or so packages upgrade
<smb> at least (as far as it was doing yesterday evening) it would not remove some
<apw> yeah for the first time in days, so i thought i'd grab an update or two
 * smb tries to remember what useful things he did last week
<apw> i just wish my drive was faster
<jk-> morning, *.eu
<apw> Fontconfig error: "/etc/fonts/conf.d/65-nonlatin.conf", line 169: not well-formed (invalid token)
<apw> that doesn't sound great
<apw> jk-, yo, hows life
<jk-> only if you're not latin
<smb> jk-, Good whatever suits you best other side of world
<jk-> apw: yeah, pretty good :) yourself?
<apw> yeah assuming i have fonts after my next reboot, life will be grand
<smb> apw, Oh fun it still (or again) has something to complain when trying the desktop task
<smb> gwibber... do I really need that?
<apw> na, just makes lots of osds
<smb> doesn't sounds like you would want it either
<smb> Bah, seems still something missing to get that laptop into a graphical state...
 * apw goes for a reboot
<jwi> sforshee: got an eye on bug 925350 ? they bisected it down to a patch from the refclk series that fixed VGA on ironlake. (although *that* patch smells like the reporter has i915.lvds_use_ssc on his command line and it's now breaking things ...)
<ubot2`> Launchpad bug 925350 in linux "Display problem (thin fading white vertical lines) after kernel upgrade to 3.0.0.15, no login window" [Undecided,Confirmed] https://launchpad.net/bugs/925350
<ogasawara> apw: didn't you have some additional patches you were wanting to throw onto precise master-next?  Or am I misremembering...
<apw> ogasawara, i threw on (or should have) a patch for d-i for hyper-v
<apw> ogasawara, i have another one which i think is working (for hyper-v drive selection) which i am still waiting on confirmation for
<apw> ogasawara, unfortuanatly they need all the other fixes for initramfs-tools etc in order to be able to test
<ogasawara> apw: ah ok.
<apw> they are normally arround about now so will see if they ahve said 'owt
<ogasawara> apw: I'll wait and start prepping an upload in a few hours.  no big hurry, but I would like to get something out the door by EOD.
<apw> ogasawara, if they arn't done don't wait as i have no idea when they will be ready
<ogasawara> apw: ack
 * apw wanders out on an errand
<Kurdistan> hi if my laptop freezes when I transfer files between laptopt-phone by a bluetooth usb can it be kernel related?
<Kurdistan> Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
<Kurdistan> I am using Kubuntu 11.10
<ohsix> not related to your problem, but there are a lot of counterfeit bluetooth things that call themselves cambridge silicon radio dongles
<Kurdistan> ohsix, you wanted more info?
<ohsix> merely putting it out there as another possible option to look into
 * ogasawara back in 20
<ohsix> i don't know how to check if they are legitimate, but i have one and it works; i'm presuming it isn't a fake
<Kurdistan> ohsix, sorry did not understand. what exactly do you wanted info?
<Kurdistan> hci0    00:1F:81:00:02:50
<Kurdistan>  <<---- good?
<Kurdistan> http://paste.ubuntu.com/840525/  <<--- dmesg output
 * ppisati -> reboot
<hallyn> jjohansen: is the fix for bug 925024 meant to be pushed soon?
<ubot2`> Launchpad bug 925024 in lxc "apparmor makes it impossible to install postgresql-common on Precise" [High,Confirmed] https://launchpad.net/bugs/925024
<hallyn> or is that going to be rolled in with the apparmor mounts support?
<hallyn> (just wondering when to look for it)
<jjohansen> hallyn: hrmm I was going to do a single pull request with all the patches in the next day or two but I can do a pull request of that today if you want
<hallyn> jjohansen: no, no hurry - thanks
<jjohansen> hallyn: also I did see a response friday on my mount rules question
<hallyn> ?
<jjohansen> hallyn: it was regarding granularity of option matching, the hold up has been in the compiler corrupting the permission sets, its uh turned out to be ugly to fix.  I have reverted to a smaller set of mount, remount, bind, move, umount and pivotroot,
<jjohansen> with the ability to still specify device mount point etc
<jjohansen> eg mount /dev/foo -> /mnt,
<jjohansen> hallyn: the question was how important is being able to match against options for this release
<hallyn> ok
<jjohansen> eg.  mount options=(rw, upperdir=/tmp/upper, lowerdir=/) overlayfs -> /mnt
 * jjohansen should have a ppa of the limited permissions up today (I just installed and am testing) and will keep working on the options fix, but is it worth considering a FFe for
<tgardner> bjf, your mumble is not working
<bjf> tgardner: yes, i'm trying to fix it :-)
<tgardner> bjf, just didn't know if you could hear
<bjf> tgardner: yes, i hear you quite qell
<bjf> well even
<hallyn> jjohansen: from my end, to decide whether it's worth an FFE will require sitting back down and looking over whether the other can meet our requirements for the normal case
<hallyn> (i.e. / read-only remount, devpts mounts, proc mount restrictions, /sys mount restrictions)
<hallyn> i suspect the answer will be yes, but not certain
<hallyn> jjohansen: could stand to sit down over mumble/phone with you and looking over wiki.ubutnu.com/LxcSecurity
<jjohansen> hallyn: sure, can we do that in an hour or two, /me has a meeting in 8 min
<hallyn> ok
<tgardner> herton, hardy master-next HEAD should be e250e13cbf96a9f7556580219074a56f67a06831
<herton> tgardner, built fine, no issues
<tgardner> herton, ack
 * tgardner -> lunch
<Kano> apw: not that i need that kernel, but 2.6.37.6x build is broken
<Kano> 2.6.27.6x of course...
<jsalisbury> bug 836250 may be fixed in kernel 3.0.0.16 \o/
<ubot2`> Launchpad bug 836250 in linux "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [Medium,In progress] https://launchpad.net/bugs/836250
<tgardner> ogasawara, do you want I should push 3.2.6 onto master-next ?
<ogasawara> tgardner: sure, was just about to rebase and squeeze it into the upload.
<Kano> tgardner: how about adding aufs3+ndiswrapper
<ogasawara> tgardner: so if you've got it, push it and I'll wrap it up
<tgardner> ogasawara, what is Ubuntu-3.2.0-16.25? I thought thats what you were gonna upload ?
<ogasawara> tgardner: it is, but I've only got it shoved to master-next.  so I'm just gonna re-do it to include 3.2.6
<tgardner> ogasawara, why don't you go ahead and do the rebase (it was straightforward). that way you'll know what you've got.
<ogasawara> tgardner: ack
<tgardner> ogasawara, should probably get it on apw's list to update aufs again. I'll look at ndiswrapper
<ogasawara> tgardner: ack
<Kano> tgardner: http://kanotix.acritox.com/files/kernel/kanotix-kernel-acritox.bash
<Kano> tgardner: there you find TESTED updates the way you could 1:1 use it for aufs3 + ndiswrapper
<tgardner> ogasawara, I'll get gomeisa updated with the new compiler version
<ogasawara> tgardner: sweet, thanks
<Kano> tgardner: can you add aufs+ndiswrapper then? we even created an iso image to test aufs
<tgardner> Kano, I'm getting ndiswrapper, but I'm gonna let apw do aufs. he's got some special sauce that he runs. it'll get done in the next day or so
<Kano> acritox did the same as u usually did
<tgardner> ogasawara, git://kernel.ubuntu.com/rtg/ubuntu-precise.git master-next has the (untested, uncompiled) ndiswrapper update. 
<ogasawara> tgardner: ack
<Kano> if you did all that you found in the script then it should work
<ogasawara> tgardner: will probably look to get it in for the next upload
<Kano> btw. your ndiswrapper u package needs a little fix as well in order to work with 3.0 to 3.4 kernel
<tgardner> ogasawara, no problem. I've gotta blast off on some errands, so I'll pick up where I left off in teh AM.
<Kano> when you want to use -ma or -mi option
<ogasawara> tgardner: and by "next upload" I mean the upload after today's, eg most likely the end of the week.
<Kano> then it thinks you dont use 2.6 kerenl
<Kano> as it only checks for the 2nd number
<tgardner> Kano, you mean ndiswrapper-utils-1.9 ?
<Kano> yes
<Kano> in o+p
<Kano> http://paste.debian.net/156157/
<Kano> thats my simple hack
<BenC> Kano: shouldn't that be || instead of | ?
<Kano> it works
<BenC> It's incorrect
<BenC> I'm doubting you really wanted to bit-wise OR the result of two boolean tests
<Kano> no, but it does not change the result ;)
<BenC> True, but I figured you wanted to look as correct as the result :)
<Kano> feel free to use || in your package
 * tgardner reboots tangerine for kernel update
#ubuntu-kernel 2012-02-14
 * apw yawns
 * smb pats apw
 * apw wags his tail
 * smb did not want that much info... :-P
 * ppisati -> reboot
 * ppisati -> back in ~10
<Fudge> hi how can i find out which module is responsible for sound with Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40)
<apw> Fudge, does lspci -nnvv tell you?
<apw> but if its HDA it'll be that the intel hda driver with a code specific to the card
<apw> Fudge, and then if so aplay --list-devices may help
<apw> card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
<apw> for exmaple for me i get that
<Fudge> apw  strange, at the bottom of the card in the first -nnvv you said, i get Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel
<Fudge> card 0: SB [HDA ATI SB], device 1: ALC889 Digital [ALC889 Digital]
<apw> so thats the one then
<Fudge> its a pretty new gigabyte amd board, the sound is pretty shocking seemlingly
<Fudge> to track down sound probs would it be something like, the module, alsa, pulse im not sure where to start
<apw> Fudge, what are the symptoms 
<Fudge> when it boots the sound is very crackly
<Fudge> not like the standard sometimes record static you used to hear on a album
<Fudge> like a big round record ...
<apw> diwic, what is that option to ignore the hda pointer thingy 
<Fudge> this actually echos several times for everything playing, if i get another stream going under a different user like root and make espeak say something, it clears up
<diwic> apw, looking for https://wiki.ubuntu.com/Audio/PositionReporting ?
<diwic> apw, not sure if that's what you mean with "pointer thingy"
<apw> diwic, yep thats the one ... thanks
<apw> Fudge, that is a good place to start
<diwic> A good place to start is https://wiki.ubuntu.com/DebuggingSoundProblems .
<apw> diwic, thanks
<apw> Fudge, have at it, and let us know... do file a bug
<diwic> but yeah, for crackling sound PositionReporting is one thing to try
<Fudge> diwic  yes thank you, apw  I will try now
<diwic> Fudge, what ubuntu release?
<Fudge> current alpha2
<diwic> oh
<diwic> haven't heard of any crackling stuff for 12.04; and we fixed ATI around natty I think
<Fudge> ok the first fix1 made the audio come good in about five seconds
<Fudge> the second fix2 made it not cracle but my sound was breaking up
<Fudge> which sux when i rely on text to speech lol, i now jsut tried the udev mod and it didnt appear to make a lot of difference
<ppisati> tgardner: refrain from uploading P/omap4, i want to rebase it on top of latest master today
<tgardner> ppisati, no problem. hadn't quite gotten to the email bucket yet
<ppisati> k
 * ppisati -> lunch
<Fudge> apw  ubuntu-bug audio just asks if i would like to bug about a pulse crash, which i think may have been my fault anyway
 * tgardner bounces gomeisa for kernel update
<apw> tgardner, man we are getting a lot of those these days
<tgardner> apw, what? kernel updates?
<apw> tgardner, yep
<tgardner> apw, it took my mirror almost 8 hours to sync yesterday
<apw> tgardner, oh i wonder, could they have sync'd only to -security by accident
<apw> tgardner, so you were waiting on that poor puppy
<tgardner> apw, dang, looks like gomeisa didn't boot again
<apw> tgardner, ogasawara, meant to ask ... do either of you have non-native build runes for powerpc at all ?
<tgardner> apw, not me
<ppisati> apw: something along the line - export $(dpkg-architecture -apowerpc); export CROSS_COMPILE=powerpc-linux-gnueabi-; fakeroot debian/rules clean binary-$ppc?
<ppisati> apw: bear in mind that i guessed some values
<apw> ppisati, do we have cross compilers installed somewhere ?
<ogasawara> apw: sorry, I don't have any non native build runes either
<apw> ogasawara, and how many hours does one build take there ?  one flavour ?
<tgardner> ogasawara, gomeisa is hosed. gonna take me a bit to restore the runes for looking at the remote console. what a pain in the ass.
<ogasawara> apw: 2-3hrs?
<ogasawara> tgardner: ugh, hosed after an update?
<apw> tgardner, i have been investigating why the chroot build stuff doesn't honour the http_proxy etc parameters one might offer it ... seems that we have two places the environ gets trashed, one at the first sudo and the other at the individual schroot commands ... any objection to me adding options to let those through?
<tgardner> ogasawara, I suspect its like last time, the initrd didn't get rebuilt correctly
<apw> ogasawara, it wouldn't be the first time that it died cause update didn't take right rather than the update itself
<apw> what he said
<apw> ogasawara, when you build test, do you just do one flavour or the lot ?
<ogasawara> apw: I usually just do one
<ogasawara> apw: I'm too impatient to do the whole lot
<apw> has anyone tried using the qemu style thing like we do for a real arm build ?
<apw> (for power builds)
<tgardner> apw, I've no preference. whatever makes it work properly.
<ogasawara> apw: I haven't
<tgardner> apw, I did awhile back. qemu didn't work very well
<apw> tgardner, i can't think of any good reason its not safe, given we pass that script in the tree anyhow so there is no security in it
 * apw sighs ... its like arm all over again, without the working builds
<tgardner> apw, well, since I don't know what you're intending, I have no objection :)
<apw> tgardner, i am intending to add -E to the sudo incantion in the scripts, and a -p to the schroot ... which will pass the environ across allowing apt to use the proxy one has in your enviroment
<tgardner> apw, on tangerine and gomeisa ? I didn't think we had a proxy
<apw> tgardner, this lets you use the squid-deb-proxy style proxies to install new chroots
<apw> tgardner, there not at the moment, though in your new world order having one on the gateway would maek sense
<apw> tgardner, and we should consider getting something cheap for that box, to keep gomeisa as a real machine
<tgardner> apw, I've got a nice AMD server thats not worth much as a builder
<apw> tgardner, but here i want to use the scripts at home and while i could get them to work with apt-cahcher-ng (it has some magic to support that use case) i can't with squid, unless i can use http_proxy
<apw> to get them installed, then i can add a proxy command inside and all is good
<apw> tgardner, if you run these scripts again they just build the missing ones right ?
<tgardner> apw, yep, shuold
<tgardner> apw, you're talking about the stuff under kteam-tools/chroot right ?
<apw> tgardner, indeed.  i want to have the exact same stuff and not have to fight them every time
<apw> tgardner, that and i just changed proxies for convienience
<tgardner> apw, ok, commit the changes and I'll test on my end
<apw> tgardner, am just seeing if i can easily add the required proxy config inside the chroot if it is specified outside, if so that will rock
<ppisati> apw: dunno, never messed with ppc
<ppisati> apw: how about the debian/embedian one?
<ppisati> apw: http://psas.pdx.edu/DebianCrossCompilerHowto/#index1h1
<apw> ppisati, that might work, will put that on my list to poke
<apw> 2.5 hours is excruciating
<ppisati> apw: i'm testing right now
<ppisati> apw: P kernel?
<apw> ppisati, yeah thats the one i want to be able to build and test
<ppisati> apw: it's compiling
<apw> ppisati, interesting, let me know how long it takes
<ppisati> apw: first install the embedian cross compiler
<ppisati> apw: then
<ppisati> apw: export $(dpkg-architecture -apowerpc);
<ppisati> apw: export CROSS_COMPILE=powerpc-linux-gnu-
<ppisati> fakeroot debian/rules clean binary-powerpc
<apw> ppisati, and where do i get the embedian cross comp ?
<ppisati> http://psas.pdx.edu/DebianCrossCompilerHowto/#index1h1
<apw> doh
<ppisati> they are still at 4.4 btw
<apw> ppisati, still interesting for a quick build
<apw> thanks, will play with those and see if they at least make a kernel for me
<apw> bjf, did you upgrade your hed in the end ?
<apw> bjf, i think you said you had no problems didn't you with a live-cd ?
<ppisati> apw: ~25min on my Q6600@2.4ghz and Raptor WD@10krpm
<ppisati> apw: linux-image-3.2.0-16-powerpc_3.2.0-16.25_powerpc.deb
<apw> ppisati, pretty impressive indeed, thanks
<apw> infinity, 
<apw> bugger
 * ogasawara back in 20
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ppisati> brb
<scott-work> can someone (maybe apw ) review the lowlatency kernel in REVU?  http://revu.ubuntuwire.com/p/linux-lowlatency
<scott-work> if someone here were also a MOTU and can advocate it, well then, that would exceedingly awesome as well :)
<herton> ppisati, what do you mean with POLA?
<ppisati> herton: Principle Of Least Astonishment
<ppisati> herton: don't make any changes that could break someone else work
<herton> ppisati, ok, wasn't sure of what the acronym stands for, first time I see it I think :)
<apw> smb, fyi i have pushed a fix onto the top of the chroot build scripts that let you use an exported http_proxy variable
<apw> smb, export http_proxy=http://name-of-squid-host:8000/
<apw> smb, and that will use the proxy for the initial installation of the chroot, and also insert that proxy configuration into the inside of the chroot as well so its configured for good
<smb> apw, Ah ok. Should have a look at taht
<apw> smb, and ... if you have them and change your proxy, rerunning the command will update the internal config
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Feb 14th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<smb> apw, Ah, so it would have actually used http_proxy for the initial deboostrap
<smb> apw, Oh, ok one had to preserve the environment, too
<tgardner> apw, looks good
<apw> smb, yeah you need the -E to get the http_proxy through to the dbootstrap, then i insert the proxy config for every more
<smb> nice
<apw> sforshee, fyi there are three .sh scripts with msmtp which give you a queue and queue runner abstraction.  seem to work here for me
<sforshee> cool, I'll check that out
<apw> sforshee, i just modded the enqueue to always swan the queue runner so it either sends them immediatly, or they get queued
<apw> seems to work as i would hope
<apw> as its some made up celebration today, i am calling it a day ... see you all on the morrow
<herton> ppisati_, the fsl-imx51 branch is missing your email on the closing commit (the changelog you close with you name/email current date)
<ppisati_> herton: the changelog has tim's email because he started the relase
<ppisati_> *release
<herton> ppisati_, yep, but you should update it on the closing commit]
<ppisati_> herton: ok, hold on
<ppisati_> herton: updated
<herton> ppisati_, thanks, looking
<herton> ppisati_, everything good, pushed
<ogasawara> rtg_: I notice there is an ndiswrapper dkms package in main -> https://launchpad.net/ubuntu/+source/ndiswrapper so do we even need to carry this in the kernel?
<rtg_> ogasawara, indeed? I'd be happy to drop it from the kernel.
<rtg_> ogasawara, there seems to be 2 source packages
<rtg_> but the dkms version is current
<rtg_> ogasawara, yeah, I'm happy to drop it.
<ogasawara> rtg_: it was already disabled in the Makefile, so it shouldn't have any affect if we just yank it.
<ogasawara> rtg_: I'll rip it out and push
<rtg_> ogasawara, well, that makes it really easy :)
<rtg_> ogasawara, squash it out of existence
<tgardner> ogasawara, gomeisa is back online
<ogasawara> tgardner: sweet
<broder> hey, has anybody looked at bug #898003? it's been sitting in the sponsorship queue for over 2 months now
<ubot2`> Launchpad bug 898003 in linux "usbip source is maintained in kernel tree now" [Low,Confirmed] https://launchpad.net/bugs/898003
<broder> i'm wondering whether or not it would be plausible to incorporate the usbip userspace pieces into the kernel package build (there's a client, a server, and a library), or whether we should keep snapshotting the source from the kernel into a separate source package
<tgardner> broder, looking
<tgardner> broder, this is still a staging driver. while we have a mechanism for building and distributing applications from the kernel source tree, I'm not sure I wanna bother with a staging driver.
<broder> tgardner: ok. that's reasonable. it doesn't seem like it's going through a whole lot of churn anyway
<broder> i'll work on updating the separate package
<tgardner> broder, maybe we can pick it up when it gets promoted to mainline
 * tgardner is EOD
#ubuntu-kernel 2012-02-15
<ohsix> hm where do i ask to get the debootsrtap backport for natty bumped again
 * apw yawns
<smb> morning
<apw> morning
 * apw notes that all the slowness he was seeing was nm-applet, which was 1.7g and growing
<smb> o_O
<apw> yeah major memory leak and no mistake
<apw> oh and that was 1.7g resident, about 8gb virtual before i zappd it
<smb> Awesome. That must help to get rid off those older machines.. :-P
<smb> Had a kvm install yesterday and that felt much more unstable than real hw (or xen the last time I looked). Lots of those sorry compiz just shit itself
<smb> (not only compiz but nautilus, flippy and whatnot)
 * smb cannot remember all the names
<cooloney> apw and smb, morning, long time no talk, men
<apw> smb, who is this cooloney fellow anyhow
<smb> apw, Dunno, feels somehow it rings a bell
<cooloney> come on, 
<smb> cooloney, It's foggy, like looking through a lot of glass bottoms... :-P
 * cooloney waves at apw and smb with splendid smile
 * smb waves back at cooloney 
<cooloney> smb: how's going, man
<smb> cooloney, Same as always, just different. :) Had a bit of a cold lately but now its getting warmer. 
<smb> Err
<smb> I mean cold as in outside cold not me being ill
 * smb needs to wake his brain
<apw> heh yeah, now apw has the other cold to confuse matters
<cos^> hi, i submitted a small patch to kernel yesterday to lkml+other lists. how long it normally takes for a patch to be added to git repo and should i just wait for it?
 * cooloney feels cold
<ppisati> apw: when you have time, can you bump linux-ti-omap4-meta? thanks
<bkerensa> Are any Kernel Team folks awake? :)
<bkerensa> I'm hoping to improve the description for linux-tools and resolve #593107 and was wondering if the Kernel had some feedback as to a better description... The only tool I know of in that is perf 
<infinity> ppisati: I think he may have done it a minute or two before you asked. ;)
<apw> ppisati, already done
<apw> bug #593107b
<ubot2`> Launchpad bug 593107 in linux "Package description for linux-tools-* needs improvement" [Medium,In progress] https://launchpad.net/bugs/593107
<apw> bug #593107
<smb> bkerensa, At least for precise it is also x86_energy_perf_policy and turbostat
<apw> bkerensa, the intent is that it will get more tools as we go
<apw> as smb points out we already have some more
<bkerensa> apw: Would it be ok to improve upon the description?
<apw> bkerensa, yes, its not very good indeed.  erm, we do need to keep its generic nature
<apw> bkerensa, the intent is for it to contain those tools which are shipped with the upstream kernel and where more than version is installed at once
<apw> bkerensa, "Kernel specific tools such as perf which are tied closly to the kernel version for version NNNN on ARCH" perhaps
<apw> the DESC not being updated is also wrong
<bkerensa> apw: Indeed
<bkerensa> updating it now and will submit a patch
<apw> bkerensa, sounds good, let us know when thats done
<bkerensa> apw: How do I add reference for Arch and Versions in control desc?
<apw> bkerensa, well i am confused, i would expect DESC to be the right thing and to be filled in
<apw> bkerensa, so leave that bit and i'll figure that out separatly now
<bkerensa> apw: k
<apw> bkerensa, from the bug it looks like any description update should be mirrored into the meta package which is in a different git repo
<bkerensa> apw: Kernel specific tools such as perf, turbostat and 
<bkerensa> x86_energy_perf_policy which are tied closely to the kernel version 3.2.0 
<bkerensa> on x86/x86_64.
<bkerensa> how does that sound?
<apw> bkerensa, thats fine, though leave the on part as on DESC as that should get put in
<bkerensa> k
<apw> bkerensa, am looking at why that doesn't work
<cos^> is there a generic kernel channel on freenode?
<apw> cos^, as in non-ubuntu kernel stuff?  i don't think i know of one, they tend to be more specific to a subsystem like intel graphics or whatever
<ppisati> brb
<cos^> apw: ok, thanks. i'll try to find something
<apw> cos^, so patches to lkml take between 0 and 7 days to be noticed normally, after that it depend on whether they liked it etc
<apw> cos^, then they will be likely merged into a maintainers tree, and more than likely merged up in the next merge window if they represent new functionality or a low priority fix.  if they are urgent they may go in immediatly
<cos^> what would be the best way to get my patch to next ubuntu kernel? attach patch to bug report?
<apw> cos^, well if its a clear bug fix, then you would mark it for stable, or submit it to stable (upstream stable) and we would then get it it from there in the natural course of taking stalbe
<apw> cos^, if its urgent or affecting a wide range of people then you could also send it to kernel-team@lists.ubuntu.com making sure it has a reference to the bug which it fixes and we can review it
<apw> cos^, though don't be offended if someone on the team then tells you that we would prefer to wait for it to come from stable
<cos^> apw: it's this http://www.spinics.net/lists/linux-input/msg19380.html
<apw> cos^, cirtainly we prefer to have a commit upstream in linus' tree so we know its not going to be rejected before we take things
<cos^> not urgent, but shouldn't break anything
<apw> cos^, that is cirtainly low impact and a device enablement only so ... you have more chance than average of getting it applied earlier
<cos^> vs https://bugs.launchpad.net/ubuntu/+source/linux/+bug/500834
<ubot2`> Launchpad bug 500834 in linux "CH joysticks not working" [Undecided,Confirmed]
<bkerensa> apw: I passed the patch for review 
<apw> bkerensa, are you submitting your patch to the bug or to the mailing list ?
<bkerensa> apw: I submitted it to the bug but pinged mailing list so kernel team can review as necessary 
<Ezim> hi now I have tried everything but it seems this issue is kernel related. it gives me kernel panic. when I use my bluetooth usb for transfering files between laptop-phone.
<apw> Ezim, if you get a kernel panic, then there is a kernel bug almost cirtainly, some instances of bad config can legitimatly cause a panic, but not commonly
<apw> Ezim, so get the panic filed as a bug
<Ezim> apw, how?
<apw> how do you know you are getting kernel panic?
<apw> either its in a log, or on your screen
<Ezim> apw, putting my blueotooth usb to laptop and try transfering files
<apw> so either file a bug and add the log snippet that has the panic, or a photo of the panic screen
<Ezim> apw, were can I find the log?
<apw> you may see the panic in /var/log/syslog
<apw> but you are saying you see a panic, so you must be seeeing it somewhere
<Ezim> apw, my laptop screen got freezed and turn to black with white error message
<Ezim> that most be kernel panic?
<bkerensa> Ezim: What was the specific error message?
<apw> depends what the error message says
<apw> and if its a panic, then an image of that screen is what you want to attach
<Ezim> bkerensa, sorry I do not remenber to be honest a lot of text
<Ezim> I can pastebin the things I have in /var/log/syslog
<Ezim> would that help anything?
<Ezim> all the kernel in (k)ubuntu 11.10 have this issue.
<apw> if there is a panic in there likely yes
<Ezim> the older (k)ubuntu release I did not have this problem
<Ezim> apw, there is nothing in syslog about kernel panic
<apw> then the information only appears on that black and white screen you mentioned
<Ezim> but there is bluez error in syslog
<Ezim> apw, I can give information about my bluetooth usb
<apw> if you are getting a kernel panic on the screen when the freeze occurs, that is the information we would need to see to have a hope of finding the issue.  bluez is userspace
<Ezim> which kernel I am running
<Ezim> if that is for any help
<apw> if you have tested the latest official kernel and its still broken, then the panic is the only thing we are likely to be able to use to help
<Ezim> apw, :( my phone camera is really bad but if I get kernel panic again I will take screenshot.
<apw> and you need to get a bug filed, ubuntu-bug linux
<Ezim> no I am to scare to try
<Ezim> apw, so I do not need to filed a bug report to launchpad
<bkerensa> Ezim: I assure you ubuntu-bug will not bite :)
<Ezim> #ubuntu-bug works also?
<bkerensa> Ezim: It will gather info and open a bug report in launchpad
 * apw is hoping we have language barrier issues here
<apw> are you too scared to try filing a bug, or to try reproducing the issue, or trying the latest official kernel
<bkerensa> Ezim: No you would need to run the command from terminal it is not a channel
<Ezim> bkerensa, doing it now
<Ezim> what should I pick?
<apw> Description-en: Linux kernel image for version 3.2.0 on x86/x86_64
<apw>  This package contains the Linux kernel image for version 3.2.0 on
<apw>  x86/x86_64.
<Ezim> should I pick External or internal storage device
<Ezim> or other problem?
 * ppisati -> out for lunch
<bkerensa> apw: hmm?
<apw> bkerensa, that is for smb, talking about the arch name and how its dumb
<bkerensa> oh :D
<Ezim> what should I pick? :)
<apw> debian.master/control.d/vars.generic:desc="x86/x86_64"
<apw> debian.master/control.d/vars.generic-pae:desc="x86"
<apw> debian.master/control.d/vars.omap:desc="TI OMAP3-based systems"
<apw> debian.master/control.d/vars.powerpc:desc="32-bit PowerPC"
<apw> debian.master/control.d/vars.powerpc-smp:desc="32-bit PowerPC SMP"
<apw> debian.master/control.d/vars.powerpc64-smp:desc="64-bit PowerPC SMP"
<apw> debian.master/control.d/vars.virtual:desc="x86/x86_64"
<Ezim> :) okey that does not help me at all
<apw> Ezim, i am having more than one conversation, this one is with sm
<apw> smb
<Ezim> apw, np.
<Ezim> I think its best if I file a bug report for it in launchpad or compile myself new kernel:)
<apw> smb, vv
<smb> apw, ^^
<apw> Description: Linux kernel tools for version 3.2.0-16
<apw>  This package provides the architecture dependant parts for kernel
<apw>  version locked tools for version 3.2.0-16 on 64 bit x86.
<apw> ...
<smb> apw, Looks much better to me
<smb> apw, Is it rather too much or would "kernel version" instead of just version make sense?
<apw> Description: Linux kernel image for version 3.2.0 on 64 bit x86 SMP
<apw>  This package contains the Linux kernel image for version 3.2.0 on
<apw>  64 bit x86 SMP.
<apw> smb, that one is the linux-image one
<apw> the tools i notice are not using the same version either
<smb> Hm, yep one with abi reference and one without
<smb> maybe removing the "for" makes sense?
<smb> So "Linux kernel image version 3.2.0-16 on 64 bit x86"... Not sure about smp either
<smb> cause it is the same for UP or SMP and just toggles
<k-rAd-> i would like to install 
<k-rAd-> !info linux-image precise
<k-rAd-> the latest pangolin kernel on oneiric
<k-rAd-> linux-image (source: linux-meta): Generic Linux kernel image.. In component main, is optional. Version 3.2.0.16.16 (precise), package size 1 kB, installed size 30 kB (Only available for i386 amd64 all armel armhf powerpc)
<k-rAd-> i have a usb 3.0 drive that is off/on.  
<k-rAd-> turns off then on
<k-rAd-> on crontab
<smb> bryceh, tjaalton Not sure whom to ask specifically, just wondering whether you have a feeling about gui stablility on kvm/cirrus 3D (surprised that is possible actually). 2D displays better but seems generally to have more applications (nautilus/bamfd or so) crashing
<tjaalton> smb: unity should not run on it
<tjaalton> there's a bug open aboutit
<smb> tjaalton, Ok, well it does run... sort of. Just not very displayative...
<tjaalton> the new swrast driver has a different identifier string, so the current blacklist doesn't work
<tjaalton> well, it's just buggy :)
<tjaalton> but not that useful yet anyway
<smb> Heh, I "see" :)
<smb> Ah, so at least people are aware. Unfortunately it is the default gfx for kvm and you are just taken into 3d if you are not careful
<tjaalton> i don't know why it's not fixed yet
<tjaalton> filed two weeks ago
<smb> Probably depends on the right people actually noticing it and not having worse problems to look after... 
<apw> !info udev-common
<apw> !info libudev0
<apw> bot not useful error
 * tgardner reboots tangerine for kernel update
<apw> bkerensa, to take this patch i need to commit it to our git tree, and for that it needs to be signed off, can i take it you are happy for it to be 'Signed-off-by: ' the email address in the changelog ?
<bkerensa> apw: Surely :)
<apw> bkerensa, this is a linux-meta update, is are you doing the linux update as well ?
<bkerensa> apw: I can do that as well yes :)
<apw> bkerensa, ok let me know when its on the bug, and i'll poke it
<bkerensa> I will ping you when I have that one complete but there is not a open bug for it
<apw> i am fixing the DESC issue as well
<apw> bkerensa, actually there is no bug for the linux-meta issue, or this one is miss targetted, but ... i'll add a task for linux-meta to the same bug
<apw> bkerensa, ok done, i've assigned both to you
<bkerensa> apw: Ok whats the package for the one that still needs work so I can get the right source?
<apw> linux
<bkerensa> k
<bkerensa> apw: Ok I have updated #593107 with the second patch for "linux" so now you have both :)
<apw> bkerensa, ok thanks
<apw> bkerensa, thanks will look at them now
<apw> bkerensa, thanks for contributing
<bkerensa> apw: No problem... Hopefully bigger things in the future :P
<apw> bkerensa,  we typically take patches after review on the mailing list, the description of the formatting rules etc for patches are here: https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
<apw> bkerensa, though in this case i've got these ones covered
<bkerensa> apw: excellent
<bkerensa> apw: and the signed off byline just means you take over the changes in changelog?
<apw> Signed-off-by: means that you are saying the work is yours, and is yours to give to the project, that it is compatible with the licence of the project too
<apw> if that makes sense
<apw> ppisati, the el in armel is that "emulated float"
<bkerensa> apw: Ahh surely thats fine :)
<ppisati> apw: ARM E(ABI) L(ittle)
<ppisati> apw: ad EABI stands for Embedded Abstract Binary Interface
<apw> ppisati, oh ok, from a consumers point of view that is mostly useless, is it the soft float option if hf is hard ?
<ppisati> yep
<soren> Hey. Since yesterday's kernel update, my laptop (Thinkpad X220) fails to suspend properly. I was hoping I could use git bisect to my way to the culprit, but I'm having a bit of trouble.
<scott-work> is there any chance of someone review the lowlatency kernel in REVU?  http://revu.ubuntuwire.com/p/linux-lowlatency
<scott-work> we need just one more advocate before tomorrow (i believe)
<soren> I wanted to build the kernel with "debian/rules binary-generic", but since the build system gets rebased on top, i can't really do that.
<soren> What's the trick to using git-bisect to track down a bug?
<tgardner> apw, git://kernel.ubuntu.com/rtg/ubuntu-precise.git hv
<ogasawara> soren: so I'm assuming this is precise that you're running?  and that the latest 3.2.0-16.25 kernel is giving you suspend issues, and 3.2.0-15.24 is working as expected?
<soren> ogasawara: That's exactly right.
<soren> ogasawara: I can't git bisect my way to find the culprit, because for most of the points in between the two commits, there build system isn't there.
<ogasawara> soren: ack.  so give this a quick test if you can -> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2.6-precise/
<soren> ogasawara: Cool. Onit.
<soren> On it, even.
<ogasawara> soren: the mainline builds will at least help a little here
<soren> ogasawara: I'm on hotel internet, so it'll be a little bit before I'm done downloading. :-/
<ogasawara> soren: ack
<ogasawara> soren: about the bisect, jj gave an dev week talk a while ago and touched on the issues you mention doing a bisect -> https://wiki.ubuntu.com/MeetingLogs/devweek1107/KernelDebugging
<soren> ogasawara: Cool. Thanks.
<apw> /bin/sh: 1: arm-linux-gnueabi-objdump: not found
 * ogasawara back in 20
<tgardner> apw, looks like my hv branch build correctly now
<apw> tgardner, ok cool thakns
<vanhoof> soren: x220 here w/ 3.2.0-16, s3 working quite well
<soren> vanhoof: Fascinating.
<soren> vanhoof: For a whlie I suspected it to be a userspace problem, but reverting to -15 seemed to solve it, so I ruled that out. Perhaps that was premature.
<soren> vanhoof: I suspected userspace because it would fail to suspend, but when I did a "shutdown -h now" afterwards, it'd suspend. When I resumed it, it shut down.
<soren> ...so it was like some process was preventing it from suspending, but shutdown caused that to be killed, so it could proceed with the suspend... and when it resumed from suspend, it continued with the shutdown.
<vanhoof> soren: yeah quite odd
<soren> ...but again: Reverting to a -15 kernel, the problem seemed to disappear.
<vanhoof> soren: fwiw I did a dist-upgrade last evening as soon as i saw -16 hit the archive
<vanhoof> been using the x220 all morning
<vanhoof> I am running with no swap, and just /boot, /rootfs, /tmpfs, no swap fwiw
<vanhoof> and ssd
<vanhoof> but other than that it's an i7 x220
<soren> This is an i5 one.
<soren> Sandybridge.
<vanhoof> soren: what bios are you on?
<vanhoof> soren: i'm still on 1.17
<vanhoof> i believe 1.24 is the latest
<soren> vanhoof: BIOS Revision: 1.26
<soren> Firmware Revision: 1.19
<vanhoof> soren: yeah really sounds like $some_process is wedged and stoping the s3, you attached to any remote mounts? ... i had similar issues when my NAS went offline once
<soren> vanhoof: Nope.
<apw> -do_common_headers_indep = false
<apw> tgardner, this hv branch seems to have an ndiswrapper update at the bottom
<apw> as in unmerged with ogasawara's tree
<ogasawara> apw: I've yanked ndiswrapper
<apw> ogasawara, ahh bad ?
<ogasawara> apw: I saw no need to carry it since there is a dkms package for it
<apw> oh as in gone, great
<tgardner> apw, yeah, I rebased against master-next before I started on hv
<tgardner> apw, whoops, maybe I didn't
 * apw re-drops it from his copy
<ogasawara> apw: yah, just drop it from what you have
<apw> pick 5756c31 NLS: improve UTF8 -> UTF16 string conversion routine
<apw> tgardner, i assume thats foundational ?
<tgardner> apw, looks like it. its alos reasonably well isolated
<tgardner> apw, well, not really. that should have been 2 patches.
<apw> 68 patches and counting, deep joy
<tgardner> scott-work, I updated the comments at http://revu.ubuntuwire.com/p/linux-lowlatency
<scott-work> thank you tgardner :)
<tgardner> apw, dpkg -S objdump
<tgardner> binutils-arm-linux-gnueabi: /usr/arm-linux-gnueabi/bin/objdump
<apw> tgardner, ok i am being a tard, and trying to cross the wrong way round ... tool failure
<tgardner> apw, there is an easy solution to that. gahab
<tkamppeter> Any chance that anyone could fix bug 900802 for Precise, that we would have USB tethering support for the iPhone in the LTS. The fix (patch attached) is trivial, only add the ID of the iPhone 4S.
<ubot2`> Launchpad bug 900802 in ipheth "PATCH: Got the USB tethering of the iPhone 4S working" [Undecided,Fix released] https://launchpad.net/bugs/900802
<mjg59> tkamppeter: Has that been sent upstream?
<apw> bkerensa, ok i've looked at your patches, unfortuanatly the first line is a separate short description and cannot be wrapped the way you have.  i have spun an alternative patch to improve these and will push those out shortly
<tgardner> tkamppeter, was just going to ask the same question. your patch looks fine.
<tkamppeter> mjg59, tgardner, I did not send it upstream by myself, but this is absolutely trivial, only one line with the phone's ID added.
<mjg59> tkamppeter: If you don't send it upstream then anyone running an upstream kernel doesn't get the feature and the patch has to be maintained until someone else does it
<tgardner> tkamppeter, mjg59 - I'll take care of it
<tkamppeter> tgardner, any chance that Precise will ship with USB tethering support for the iPhone 4S?
<tgardner> tkamppeter, yes
<mjg59> tgardner: Thanks!
<tkamppeter> tgardner, thanks, looking forward to have my iPhone 4S USB-tethering out of the box with Precise.
<tgardner> tkamppeter, which email address would you prefer for the Signed-off-by ?
<tkamppeter> tgardner, till dot kamppeter at gmail dot com
<tgardner> tkamppeter, can do
<albrigha> tkamppeter, hey Till!
<tkamppeter> albrigha, hi
<albrigha> tkamppeter, long time no talk to!
<albrigha> tkamppeter, I was on HPLIP for years and years :)
<tkamppeter> hi, I remember you, and what are you doing now.
<albrigha> tkamppeter, just started on the Ubuntu QA team!
<tkamppeter> albrigha, yes in QA you test and report bugs, if it's HPLIP you can directly attach the patches to fix the bugs.
<albrigha> tkamppeter, nah i don't do hplip any more I'm afraid. :) working on ubuntu overall. but i'm sure some hplip at some point. anyway, I just wanted to say hi there :)
<tkamppeter> albrigha, then welcome in the club and have great work with us. Will we meet on the UDSes?
<albrigha> tkamppeter, yep! looking forward to it
<tkamppeter> albrigha, and if you want to meet me on IRC, I am usually not in the #ubuntu-kernel channel but in #ubuntu-desktop and #ubuntu-devel.
 * apw shifts to another machine ... and a more comfortable location
 * tgardner -> must have food
<tgardner> apw, looks like your hv bits are working.
 * tgardner -> EOD
<bjf> ogasawara: still around ?
#ubuntu-kernel 2012-02-16
<ogasawara> bjf: yo
<matti> http://www.ustream.tv/channel/live-iss-stream -- technology is so great. A live stream from above the Planet.
<matti> Ahh. :)
<pbuckley> nice
<matti> If somebody would suggest to me back in 1999 that in 2012 I will be watching I live stream from the orbit of our planet.
<matti> I would have rather mixed feelings.
<matti> And look at it now...
<matti> [ Although, still not flying cars ;d ]
<ScottL> apw,  TheMuso has made some changes to the lowlatency kernel, picking up on comments:  git://kernel.ubuntu.com/themuso/ubuntu-precise-lowlatency.git
<bjf> ogasawara: sort of figured it out, thanks though
 * apw yawns
 * smb crawls out of a pile of emails
 * apw crawls out from under a pile of leaking nm-applet
<apw> i am going to have to start killing it before i suspend, the machine is almost unrecoverable when its out of control
<aBound> Hello all, is there anyway I can find out a few release notes for a Ubuntu kernel release?
<apw> there are release notes for each main release which contain any issues for the kernel
<apw> https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes
<apw> for instance
<apw> aBound, ^^
<aBound> apw, Thankies I been trying to find that for quite a while.
<smb> apw, nm-applet sounds fun. but how does it get worse on suspend? Or just worser than before because it has to rescan?
<apw> worse cause the machine dumps all of its ram on the floor when it suspends
<aBound> apw, There's no kernel release notes for Alpha's are there?
<apw> and swaps like a complete swine
<apw> aBound, there are release notes for the latest one i believe
<apw> they get reused for the next one and become the final release notes
<aBound> apw, Awesome. :P
<aBound> Always good to know what's been fixed.
<apw> aBound, i found those by searching for 'ubuntu precise alpha 2 release notes' in google
<apw> https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Alpha2
<aBound> Thankies again. :)
<apw> smb, ok now sound settings is crashing when i select an input source ... wtgf
 * apw reboots
<apw> diwic, i have sound setting dieing in a heap every time i select an external sound source, known?
<diwic> apw, what does "external sound source" mean?
<apw> diwic, going to the inputs setting and selecting my external usb mic as input
<apw> (or trying to as i don't believe its changing it)
<apw> diwic, today is the first time i have had _two_ input sources for my external mic
<apw> i now have an iec958-stereo-input and Microphone
<diwic> apw, oh :-/
<apw> up till today i have only had Microphone
<apw> this is hampering my use of mumble to say the least
<diwic> and that's for the usb mic I suppose
<apw> yes my blue snowball
<apw> not that i can upgrade any further right now as it wants to ... guess ... go on ...
<apw> remove half my machine again
<diwic> apw, well, as an immediate workaround, install the pavucontrol package and select input through there
<apw> diwic, ok that shows just one input for it
<diwic> ignore the iec958 and use Microphone only.
<diwic> ronoc's been seeing the duplicate iec958 stuff some times as well
<apw> diwic, ok how does one actually select the input source with this thing ?
<diwic> apw, easiest is, while recording in mumble, go to the recording tab. It'll show Mumble and a dropdown to select current input
<apw> ahh
<apw> diwic, yeah that seems to work
<diwic> apw, btw, this might store an application <=> input connection in a database.
<apw> diwic, would this be 'gnome-control-center' crashing ?
<diwic> apw, yes. And assign it to Conor Curran
<apw> diwic, as it it might use the mic i selected by default for that app ?
<apw> then i can't file a bug as its out of date, and i can't update it.  f*ck this archive ... "always installable all cycle" my ass
<aBound> Goody goody sounds like 12.04 will be a nice release. :P
<brendand> apw - you can use pacmd
<apw> brendand, thanks
<brendand> apw - list-sinks/sources, set-default-sink/source
<apw> nice
 * ppisati -> out for lunch
 * apw pops to the pool
<tgardner> cking, 3 ecryptfs patches have been queued for 2.6.32.y stable; Ban ecryptfs over ecryptfs, eCryptfs: Remove mmap from directory operations, and Add mount option to check uid of device being mounted = expect uid, CVE-2011-1833
<ubot2`> tgardner: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1833)
<cking> tgardner, many thanks
<Ezim> so now I have reported 2 kernel bug.
<Ezim> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/933387
<ubot2`> Launchpad bug 933387 in linux "Bluetooth usb problem in Kubuntu 11.10! Kernel related? " [Undecided,Confirmed]
<Ezim> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/933443
<ubot2`> Launchpad bug 933443 in linux "Problem after installing cpufrequtils! Kubuntu 11.10" [Undecided,Confirmed]
 * apw fails to see why the second of those is kernel related
<apw> cking, when you did your governer tests, you said you tested a userspace one, which one was that ?
<cking> apw,  cpufreqd
<cking> et al
<apw> and cpufreqd was worse right, badly so ?
<cking> it could not beat the default, and it made some less than optimal choices on some scenarios. Also, I suspect it added some extra overhead
<apw> got a link to the testing there ?
<apw> then i can shove it in this bug and dump it on cpufreqd :)
<cking> apw, http://zinc.canonical.com/~cking/power-benchmarking/cpu-governor/
<apw> cking, is the results.txt URL there likely to be persistant ?  so i can put it in a bug ?
<cking> apw, they should be persistent enough
<cking> I won't be removing them in a hurry
<apw> cking, yay, great writeup, saved me wodsmithing anything, excellent
<cking> apw, that was my aim - collate, analyse, report
<smb> copy
<apw> when will this archive be installable fully again
<smb> apw, May
<apw> 2013 ?
<cking> heh
<apw> ogasawara, am final build testing the HV update and will the push it in
<ogasawara> apw: ack
<apw> ogasawara, seems that this combination works well for them and is performant, the v3.2 hv drivers just crap out after a few seconds and lose the drives, not hot
 * ogasawara back in 20
<apw> ogasawara, tgardner-afk, ok Hyper-V combo pushed, deviations.txt included
<ogasawara> apw: thanks
<apw> ogasawara, just realised that i am still waiting on the initramfs-tools update to go in, check back with me before this gets uploaded, we may need to hold the flipper if its not gone.  am asking for it to be sponsored nwo
<ogasawara> apw: will do
<apw> ogasawara, the initramfs-tools bits just went up so i think by the time any builds you do make the archive they will be done
<ogasawara> apw: cool.  I was thinking of uploading tomorrow.  I want to get this rc6 thing sorted first as if we are going to flip that on by default I want to have it in the beta-1 kernel upload for maximum testing exposure.
<apw> ogasawara, sound plan indeed
<apw> ogasawara, persuade that cking to do you a call for testing :)
<ogasawara> apw: am going to ping eugeni about it and also Sarvatt mentioned having some feedback as well
<cking> if anything needs testing by community I'm happy to blog about it
<ogasawara> cking: I'll for sure solicit your input for the cft.  what I'm thinking is that we'll want to craft a blurb about it in the Beta-1 release notes and reference a wiki set up with all the info and to capture any test results
<cking> ogasawara, so we should capture the results in a wiki, it depends on what we want to exercise really with rc6
<ogasawara> cking: is there a simple test we can have users run to compute their overall power savings?
<ogasawara> cking: and obviously I'm interested in any regressions should they arise
<cking> ogasawara, yep, lemme write up some notes on this and I'll send them to you
<ogasawara> cking: perfect, thanks!
<sforshee> apw, http://pastebin.ubuntu.com/844550/
<cking> ogasawara - instructions in you inbox 
<ogasawara> cking: thanks
<kees> tgardner-afk: I mis-spoke, you can't only use upstream since it lacks link protections. I sent email with a pointer to a repo to pull from.
<orated> I'm finding delay in boot time and these are the bootcharts for last two booting - http://imagebin.org/199031 http://imagebin.org/199035 . I'm not too much concerned about boot time but can anyone explain me what exactly is consuming time and how can I fix it?
<tgardner> kees, ack
<scott-work> tgardner: TheMuso made the changes you requested i believe for the lowlatency kernel : http://revu.ubuntuwire.com/p/linux-lowlatency
<scott-work> tgardner: would you be a person who could check the kernel package and advocate on REVU?  we still just one advocate
<tgardner> scottI'll have a look in a bit
<tgardner> scott-work, ^^
<scott-work> tgardner: thank you very, very much :)
<tgardner> kees, jjohansen: have a look at the last 5 commits on precise master-next now.
<tgardner> for yama, that is
<jjohansen> tgardner: will do
 * apw isn't convinces that disk separation hasn't regressed.  i just had my music stop when i was doing a git reset --hard HEAD
<bkerensa> apw: Thanks btw for reviewing.... I actually had thought about the description being split and it was a oversight on my part
<apw> bkerensa, no worries, the changes are applied to precise now already
<apw> bkerensa, and if you'd not looked it'd have not gotten done
<bkerensa> apw: Good thing there are some of us who commit time to bitesize :)
<apw> yep, thanks for that
 * apw wants his next song, now please
<apw> no i mean now, really
<apw> if its not tooooo much trouble
 * cking thinks apw needs a beer
<apw> cking, if i wasn't starting to feel ill i might well
<cking> apw, time to stop working then methinks
 * tgardner -> lunch
 * cking -> EOD
<kees> tgardner: the commits look good -- the only thing I'd note is that "drop after 3.3" for the last 2 isn't correct.
<tgardner> kees, yeah, I figured we'll catch those when we start the Q series.
<apw> clap4ham
<tgardner> apw, password ?
<apw> yeah unity failure
<apw> luckily just a screen lock password
<apw> about the 5th time its been in here too, one reason i don't change it
<apw> as it'll just be in here again next week
<tgardner> kees, ok, I updated the commit subject and removed '(drop after 3.3)' for those 2 commits
<Sarvatt> heh i've had to make sure to log in with with the mouse instead of pressing enter ever since we switched to lightdm for that same reason
<apw> its awful and no mistake
<apw> they clearly don't have screen locks on their machines
<ogasawara>  /me lunch
<ogasawara> lets try that again
 * ogasawara lunch
<kees> tgardner: I'm still trying to get the link protections into the VFS directly, but it's a very very long path :P
<tgardner> kees, no problem. I've been watching your struggles upstream
<kees> I've eased back on pressure lately because I'm trying to not distract from drewry's seccomp_bpf stuff :P
<tgardner> kees, speaking of which, I don't think precise has any seccomp patches
<kees> tgardner: it doesn't and that's basically going to be the way it is unless things settle really quickly upstream.
<tgardner> kees, ok, just wanted to be sure you knew about it
<kees> tgardner: the old API never had any users, and the new API isn't confirmed really.
<kees> tgardner: I wish the timing was better. maybe it could get SRUed, I'm not sure yet.
<tgardner> kees, possibly, it is fairly separate from everythign else, and is easily tested.
<GrueMaster> sconklin: Question on the power meter.  For measuring a system that has multiple power feeds, would it be better to measure AC power consumption?  I have the meter setup now on a panda inline with the 5v power, but I need to test a PC and server.  Those have multiple DC inputs.
<kees> tgardner: the risk currently is that it does merge itself with the network BPF code now, so it's becoming less and less isolated. That's great for code size and runtime hit, but more scary for backporting.
<tgardner> kees, ah. well, perhaps those that are real concerned about seccomp can run an LTS backport kernel when they are released
<ohsix> GrueMaster: measuring them one at a time would be more useful than measuring the AC
<ohsix> unless you want to know the wall plug consumption, which can vary in efficiency
<sconklin> GrueMaster: the problem with measuring the AC side is that you also measure all the power supply losses, and anything else that's connected like disk drives, etc
<GrueMaster> I was going to eliminate as many hardware differences as possible by using the same drives, ps, etc.  Only change would be motherboard attached.
<GrueMaster> But I understand.
<GrueMaster> Just a real pita with only one meter.
<sconklin> You may still find that the changes you want to measure are lost in the noise if you do that. 
<sconklin> i.e. CPU consumption changes may only amount to a range that's the least significant couple of bits in the meter
<GrueMaster> True, but I think the goal here is system level.  It is fairly straight forward now, but when we get into blades, it will be much harder I would think.
<ohsix> it's more work, but you can sum them in the end
<ohsix> i want a 32 channel data logger so i can log everything, mouahouah
<tgardner> 9999 %CPU is not a number you see everyday.
 * tgardner -> EOD
<scott-work_> doh, i wanted to tell tgardner thank you again, i'll catch him manana
#ubuntu-kernel 2012-02-17
<maks> are there plans to add drm+1 for 3.2 again?
<maks> thinking of various improvement with mesa 8.0 
<smb> maks, Not as far as I know. 
 * apw yawns
<maks> smb: I see, hmpf bad news for rc6 param.
<apw> maks, how so ?
<Fudge> I am trying to find out if speakup is also in the ubuntu server kernls
<smb> IMO rc6 is indipendant of moving to a completely new drm
<smb> Fudge, Likelyhood should be there as those are the same kernels for precise
<apw> Fudge, as far as i know they are modules which are enabled
<Fudge> thank you very much, server installs dont actually load a desktop for install, its a text installer?
<Fudge> as far as I know that is
<smb> Fudge, It is the same text installer like alternates. But you asked about the kernel
<Fudge> yep, thanx loads
<maks> smb: well it is a great battery life improvement and afaik still needed some fixes after 3.2 (even not turned on by default in 3.3 :|)
<apw> maks, right and we have an ongoing effort to get those fixes working and enabled in precise
<smb> maks, I know. And there is some testing going on about that. But one does not want to pull a whole new drm for that. ;)
<maks> cool, been watching with a bit of distance due to personal thesis constraints.
<maks> that is cool news, hope that we can coordinate that with debian again too.
<maks> (now that 3.2 is official there too)
<apw> we are likely to have the same kernel base version so that the patches ought to be as applicable there if we get them working and applied
<apw> of course that relies on patches which appeared in the last two days being perfect and covering all the cases
<apw> which isn't very likely really
<maks> right they need to settle a bit didn't knew they were that fresh.
<apw> they have only just figured out what they want to do, whether that is valid, and whether the patches do that are both in doubt at the moment
<jjohansen> apw: so I am not pushing the AA patches today, I hit a kitten killer with the rebase and missed feature freeze so the plan is to do some more testing and push early next week
<smb> poor animals
<jjohansen> smb: indeed, /me is now living in fear of peta or alf finding out
<smb> jjohansen, Alf should not be a problem as long as you got ketchup and fries... ;)
<jjohansen> anyway /me is going to bed for at least a couple of hours
<smb> jjohansen, That sounds like a very sensible plan. :) G'night!
<jjohansen> smb: hehe, I forgot about him
<jjohansen> g'night smb
 * cking reboots
 * ppisati -> lunch
<apw> bjf i take it you saw all teh shankbot moaning about universe etc
<tgardner> apw, pitti has already responded
<apw> tgardner, thanks
<ogasawara> apw, tgardner: I'm gonna start prepping the upload.  Do you guys have anything else that needs to go in?
<apw> ogasawara, nothing thats ready no
<tgardner> ogasawara, serge has a bug report about headers not being right, but I don't think it should be an upload stopper.
<apw> tgardner, got a reference to that ?
<tgardner> I guess it causes some lxc build issues. I'll have to back and look. One of my unity crashes happened before I wrote it down.
<apw> tgardner, if you find it ... pass it over
<tgardner> apw, I'm pretty its assigned to hallyn
<tgardner> not that launchpad can do that search without timing out
<apw> tgardner, indeed
<tgardner> apw, but it will be a bug against linux or linux-meta
<bjf> apw, just sitting down, sigh
 * apw hopes for linux-meta
<ogasawara> bug 933045
<ubot2`> Launchpad bug 933045 in linux "headers incompatible with eglibc" [Medium,Triaged] https://launchpad.net/bugs/933045
<tgardner> ogasawara, thats the one
<apw> bjf, didn't we have an arsenal script to pick up new linux-meta bugs and shove them to linux
<apw> bjf, seems to have stopped working me thinks
<apw> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bugs?orderby=-id&start=0
<tgardner> yeah, was just gonna ask jsalisbury about that
<apw> jsalisbury, we have a bunch of bugs on linux-meta ... often they are real linux bugs and we should be checking them and pulling them over
<apw> jsalisbury, i thought we had a script which did it for New ones (real ones had to be moved Confirmed and shoved back)
<apw> but ... otherwise we need to keep an eye on it
<bjf> apw, i i'll look into it. not sure we run that all the time, but can't remember
<apw> bjf, we did when i ran them, when they moved to jfo things got less clear
<apw> bjf, it is quite likely we don't get enough to care if jo just keeps an eye on them
<apw> bjf we can hear you
<jsalisbury> tgardner, apw, yeah, I've been manually moving bugs to the linux package when they are marked as linux-meta by mistake.
<jsalisbury> apw, thanks for that link.  I'll review all of them.
<tgardner> jsalisbury, well, there are 20+ new linux-meta bugs tat look like they should be linux
<bjf> jsalisbury, we do have a script to find them all and move them, i'll get with you in a bit about it
<jsalisbury> bjf, great, thanks.  
 * ogasawara back in 20
<tgardner> sforshee, has your MB Air stopped suspending when you close the lid ? pm-suspend works OK.
<sforshee> tgardner, yes. I found the problem, see bug 933710
<ubot2`> Launchpad bug 933710 in gnome-desktop3 "MacBook Air 4,1 does not suspend when lid closed" [Undecided,New] https://launchpad.net/bugs/933710
<tgardner> ah, user space
<sforshee> yeah, now gsd doesn't suspend if it thinks you have an external monitor attached
<sforshee> but it's treating eDP as an external monitor
<tgardner> sforshee, so, this is a recent change to gsd, right ?
<sforshee> must have been within the last week or so, but I didn't check
<tgardner> and likely impacts a number of laptops ?
<sforshee> anything using eDP
<sforshee> and intel graphics at least
<tgardner> sforshee, ok, I'll put some whammy on the bug (like its release critical, etc)
<sforshee> tgardner, thanks
<tgardner> sforshee, change the description to be more generic as this impacts more then just Macs
<sforshee> tgardner, done
<tgardner> sforshee, good catch by the way.
<sforshee> tgardner, that was really bugging me. I use that machine a lot, and I hate having to use the menu to suspend it
<tgardner> sforshee, have you played with the clickpad support from chase ?
<sforshee> tgardner, I didn't realize there was new clickpad support available
<sforshee> how do I get it?
<tgardner> ah, it came on the desk top list. I'll forward it to you
<sforshee> tgardner, thanks. I've been looking forward to getting better clickpad support
<tgardner> sforshee, i got it on the 11th. I guess I should have looked at the recipient list
<sforshee> cnd, do you know why 52965cc "Input: bcm5974 - set BUTTONPAD property" hasn't been submitted for precise?
<tgardner> sforshee, it applies cleanly. shall I just push it ?
<sforshee> tgardner, up to you. I'm building a kernel now to test it.
<tgardner> sforshee, ok, lemme know
 * smb thinks this week has been going on for long enough...
<smb> CU next one
<tgardner> ogra_, is there a page somewhere that describes how to create a Lucid ARM rootfs ? I'm messing around with a dreamplug and their default debian rootfs is kind of crufty.
<ogra_> tgardner, dreamplug is armv6
<ogra_> wont run ubunt
<ogra_> u
<tgardner> ogra_, it should run Lucid, right ?
<ogra_> karmic would run
<tgardner> ogra_, hmm, well maybe I'll stick with Lenny. the update from their distribution to Lenny 6.0.4 didn't go well.
<tgardner> maybe I should just start with a Lenny rootfs
<tgardner> ogra_, I thought we didn't abandon v6 until after Lucid
<ogra_> other way round
<ogra_> jaunty was v5, karmic was v6
<ogra_> lucid v7 
<tgardner> ogra_, dang, thats not very handy.
<ogra_> not my choice
<tgardner> ogra_, does debian keep an armv6 rootfs tarballed somewhere, or do I have to debootstrap it ?
<ogra_> i think you need to debootstrap 
<tgardner> ok, thanks
<cnd> sforshee, because I haven't had a chance yet :)
<tgardner> cnd, its a clean cherry pick. any reason not to ?
<cnd> tgardner, no, I literally haven't had time yet
<cnd> I sent it a few days ago
<cnd> and I've been in transit to the gtk hackfest and other feature freeze stuff
<tgardner> cnd, just pushed it, so its in precise
<cnd> tgardner, thanks :)
<cnd> the other reason I was waiting was there are three other patches
<cnd> one for hid-magicmouse
<tgardner> ogasawara, added some cruft on to your tree
<cnd> and two for synaptics
<cnd> but one of them I'm not sure of yet
<ogasawara> tgardner: ack
<cnd> so I want to get some feedback first
<tgardner> cnd, are those upstream ?
<cnd> tgardner, not yet, as far as I am aware
<cnd> I didn't even know bcm5974 was upstream yet
<tgardner> ok, we can get 'em later
<sforshee> cnd, I tried your clickpad stuff on the macbook air, and when I've depressed the clickpad with one finger, each time I place a second finger on the surface the cursor jumps. Is that a known problem?
<sforshee> cnd, the pointer jumps rather
<cnd> sforshee, it shouldn't...
<cnd> sforshee, you enabled clickpad mode, right?
<cnd> and you don't have the bottom area masked off?
<sforshee> cnd, I updated from the ppa and ran both of the scripts you sent
<sforshee> that's all
<cnd> sforshee, can you pastebin the output of "xinput listprops <device>"?
<cnd> you can get the device from running xinput
 * cnd has to leave though... :(
<sforshee> okay
<sforshee> basically it's working, except for the jumpy cursor
<cnd> sforshee, please file a bug against xserver-xorg-input-synaptics
<cnd> with a tag of "clickpad"
<sforshee> cnd, ack
<cnd> and attach your xinput list-prop output
<cnd> and assign it to me
<cnd> thanks1
<cnd> !
<tgardner> sforshee, https://bugs.launchpad.net/ubuntu/+filebug
 * tgardner -> lunch
 * sforshee -> also lunches
<DBO> apw, I know you're upset, Im just genuinely trying to help
<DBO> apw, can you just confirm if you are still getting the stuck super keys after upgrading and restarting your session
<DBO> I need to know if I should put a freeze on trunk
<apw> DBO not upset, just demotiviated from bothering to report issues
<apw> as three of my team have tried today and got various handy handles added to them
<apw> when all they wanted to do was tell you somethign was really brokted
<DBO> Im sorry your team has been given the run-around, thats really not appropriate
<apw> s'ok we'll just file bugs from now on and leave it at that
<DBO> the stuck super keys though, can you please answer that
<DBO> its quite important to me
<apw> DBO, erm what was the question ?
<DBO> if you press super+num
<DBO> does your launcher get stuck
<DBO> as if the super key is still pressed
<apw> DBO no that one seems fixed, but i have seen two cases of the numbers getting stuck on without the associated loss of ability to work on the desktop that it had before -0ubuntu4
<apw> so there is something new in there.  i'll try and get a piccy of it
<DBO> you have seen the numbers stuck without continuing to hold the super key?
<apw> yep, twice since i updated to -0ubuntu4, which would have been perhaps 3.5 hours ago
<apw> they just stayed on until i moved to a differnt viewport thingy (the thing on the lay
<apw> c
<apw> launcher with 4 tiles
<DBO> does your launcher autohide?
<apw> DBO yep normally, and when the get stuck it does not hide either
 * cking reboots
<DBO> apw, I know Im asking a dumb question, you did restart your session after upgrading compiz yes?
<apw> DBO, i did a lightdm restart cause my compiz died when i tried to compiz --replace it
<DBO> okay
<DBO> if you find a reproducible or semi-reproducible way to cause the issue
<DBO> please let me know immediately
<apw> DBO, yep will do, am playing with various emulations of my workflow to see if i can, but no luck right now
<DBO> apw, once again, sorry about the disrespectful way you were treated, its not cool, I'll be looking into this race condition today with my team
<apw> i'll let you know if we manage to repro any of them
<DBO> apw, while Im here
<DBO> who can I talk to about learning how to make my multi-touch keys work?
<DBO> erm, multi-media keys
<DBO> some of them are not even reported by the kernel, so things like udev keymaps dont help
<tgardner> sforshee, ^^
<apw> DBO there is a wiki guide on how to work out where the issue is
<apw> https://wiki.ubuntu.com/Hotkeys/Troubleshooting
<apw> though i an not sure how up to date the info is these days
<apw> DBO cirtainly we should try and work out if the keys are being emitted from the kernel or not
<apw> normally they either come out of one of your input channels, which you can find with input-events <n>
<apw> or via acpi which acpi_listen thingy will show you if there are events there
<DBO> apw, they come out neither acpi_listen nor from xev (with gnome-settings-daemon killed)
<DBO> apw, I went through this from the X side with RAOF one time
<DBO> and his conclusion was the kernel was not emitting anything when I press the keys
<apw> DBO, what machine is this btw
<DBO> apw, evtest either
<apw> DBO, there is a command input-events, and a sibling command lsinputs.  the next thing to try is getting those installed
<apw> and then use lsinputs to get a list of all your input streams
<DBO> apw, actually its an external keyboard
<DBO> logitech wave
<apw> then for each of them use input-events 0, then input-events 1 etc
<apw> and while each is running hit the key and see if it comes out
<DBO> can do
<apw> if so then we'd want to see what came out, so do file a bug with all the things you have tried
<apw> and get the bug number to jsalisbury
<DBO> apw, if I unplug the wireless receiver
<DBO> apw, then I plug it in
<DBO> and see the diff in the inputs
<DBO> would it be safe to only test those inputs?
<DBO> (it creates 2 inputs, one for the mouse, one for the keyboard, but some of the MM keys show up on neither)
<apw> DBO hmm, well in theory yes, though i have seen some internal devices emit them on the internal keyboard for instance
<apw> i woudl think for this one, its mostlikely the new ones
<apw> and i would start with those, as if something is emitted its as likely to be
<apw> there as anywhere
<DBO> yeah they dont emit on those
<DBO> I'll go through them all
<sforshee> DBO, about your multimedia keys, is this on a laptop?
<DBO> sforshee, it is a laptop
<DBO> but on an external keyboard
<DBO> I dock the laptop
<DBO> apw, sforshee, none of the inputs emit an event when I press the button
<sforshee> DBO, what model of keyboard?
<DBO> sforshee, brand new Logitech Wave
<DBO> I gotta go for about 10 or 15, Im sorry
 * apw calls it a day
 * cking does a clean install, wish me luck
<DBO> sforshee, back, anything i can do to help make this work? :)
<sforshee> DBO, how were you checking for scancodes?
<DBO> sforshee, evtest
<sforshee> DBO, it's not always the case that drivers report the scancode when they don't have a keycode to go with it, unfortunately
<sforshee> do you know what driver is handling the keyboard? usbhid maybe?
<DBO> usbhid
<DBO> and hid_logitech_dj are loaded
<DBO> sforshee, ^^ :)
<sforshee> DBO, what's the output of 'lsusb | grep 046d' ?
<DBO> Bus 003 Device 002: ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX
<DBO> Bus 003 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
<DBO> the quickcam is a webcam I have sitting on the external monitor
<DBO> sforshee, I did hack my udev rules at one point to make it match the Unifying Receiver
<DBO> since the current wave rules dont look for that
<DBO> but that didn't fix it
<sforshee> you mean to load a keymap?
<DBO> yes
<sforshee> DBO, anything in dmesg when you press those keys?
<DBO> no
<ohsix> sforshee: can i piggyback on this and get some assistance with my touchpad disable key later? :]
<sforshee> DBO, I haven't worked with hid devices before so I'll have to do some digging. Probably best to file a bug and assign it to me.
<DBO> sforshee, Im willing to do some hacking of my own
<DBO> sforshee, if you point me in a direction and say go
<DBO> I really just would like a brief lay of the land
<sforshee> DBO, well drivers/hid/hid-logitech-dh.c is the driver matching your USB id
<sforshee> that's where I'll start
<sforshee> I need to survey the landscape though, and if you file the bug with 'ubuntu-bug linux' I'll have the hw information readily available
<DBO> okie dokie
<DBO> I'll do that :)
<sforshee> ohsix, I'd say the same to you. If you file the bug I won't have to keep asking questions about your hw :)
<ohsix> well i filed a bug already, nobody had any pointers or troubleshooting steps when i kept flogging it either, let me dig it up
<ohsix> sforshee: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/739922 i've since changed my motherboard so the having ran .37 isn't important now, if it ever was
<ubot2`> Launchpad bug 739922 in xserver-xorg-input-synaptics "touchpad disable key does not work (acts as if no key was pressed, no event in xev)" [Undecided,Expired]
<ohsix> i don't know if that was even the right place to report it, but nobody pointed me elsewhere, shrug
<ohsix> i did go through the troubleshooting guides that i could find on the wiki but none were very relavant or revealing
<sforshee> ohsix, did you try https://wiki.ubuntu.com/Hotkeys/Troubleshooting ?
<ohsix> yes, but i can go through it again
<ohsix> iirc the conclusion i came up with is that the event device showed the presses, but xev didn't (like x changed its input selection criteria)
<sforshee> okay, go through it again and post what you find on the bug. It may just need a keymap.
<ohsix> should i reopen it or just post a new one? and against synaptics again or something else?
<sforshee> synaptics is definitely wrong, but reopen it and post what you find and we'll figure out what package is correct
<ohsix> okie dokie, thanks
<ohsix> i'm still on natty, i can try oneiric sometime next week though
<sforshee> ohsix, okay, even testing a live CD should be enough
<DBO> sforshee, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/934480
<ubot2`> Launchpad bug 934480 in linux "Logitech Wave keyboard multi-media keys don't all work" [Undecided,New]
<DBO> I tried to add everything I could about it
<ohsix> that's what it will be :]
<DBO> and now its assigned to you sforshee :)
<sforshee> DBO, ack. I'll look at it as soon as I can manage.
<sforshee> ohsix, there's two devices you're keypress could be coming from. One is name "HP WMI hotkeys" and the other "AT Translated Set 2 keyboard"
<sforshee> be sure to check both
<ohsix> will do, i do recall it coming on a different device than the AT one, but not which
<ohsix> bbiab, nose running]
 * tgardner -> EOD
<ohsix> sforshee: hm it's different now getting this on _deactivation_ twice, and nothing on activation, still going through article: keycode 146 = (keysym 0xff6a, Help), state = 0x10
<sforshee> ohsix, sending press and release events on button release isn't unusual for hotkeys
<ohsix> it's the same message twice, wouldn't the keycode or the flags be different?
<ohsix> it's weird it used to work ages ago, i didn't see if there was a keymap for it back then though
<sforshee> I'm not sure what everything in your output represents -- what are you using to see the events ?
<ohsix> oh, just the first step in that wiki article, killing g-s-d and the xev oneliner
<ohsix> i'll just carry on :]
<cking> yay, unity3d now working - clean install and nuking ~/.gconf/apps/compiz* fixed it
#ubuntu-kernel 2012-02-18
<orated> Hello! I often see line like - 'iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 1' repeating in vt during which the wireless disconnects and then connects back. dmesg | tail - http://paste.ubuntu.com/846902/ . What exactly is causing disconnection and how can I fix it? Laptop uses - Intel Advanced-N6230 (2x2 agn + Bluetooth) whereas wireless router supports all b/g/n
<ohsix> dunno what "load = 1" may mean, but i think tid means transmitter id, and aggregation has to do with mimo, if you could disable that it might be more reliable
<ohsix> there's also a #linux-wireless channel where you can get some direct advice
<orated> What is mimo?
<ohsix> multi input, multi output; basically multiple antennas
<orated> Sure, I'll try that. BTW is there a way to confirm if N standard is conflicting?
<ohsix> probably with sufficient knowledge, something don't have :]
<orated> No, thank you. I'll try what you suggested
<ohsix> most vendors had version numbers on things, maybe you can find a compatibility matrix
<orated> ah, that went above my head ;)
<orated> Hey ohsix, are you still there?
<OnurSenture> hi guys, i'm searching the location of getpid system call implementation in the kernel but could not manage to find. can somebody help me? :)
<orated> Hello! Anyone got suggestions to dig the cause of weird troughs and peaks here- http://imagebin.org/199583 - its only causing cpu fan to rev up & down periodically ...?
<orated> The first is memory readings and other is temperature based on lm-sensors
<ohsix> what is the period on that graph?
<ohsix> (chances are it's that graph ;])
<orated> Yes, graph with 0.5s period
<orated> It is annoying to find fan to function that way even in absolute idle
<ohsix> well there is perf top, latencytop and a bunch of other not-top top like tools that can give you some visibility into it
<ohsix> i've got a notebook that does exactly that, except it's the bios & the video card doing it; you might be able to adjust the thermal zones so it comes on a little later and knocks off those tops
<orated> What is the package name for perf top? 
<ohsix> linux-tools
<orated> How come  BIOS was? I'm trying to adjust the thermal zones.. I read that fancontrol, sensors-detect and pwmconfig can help to do so but there is nothing I could find which can give me fan rpm
<orated> How would you adjust thermal zones?
<ohsix> there are knobs in /sys/devices/virtual/thermal, and a .txt in the kernel tree (in Documentation/ somewhere) that describes them
<orated> ' .txt in the kernel tree (in Documentation' - you mean the one listing all the linux options, like those one can pass through grub?
<ohsix> http://lxr.linux.no/#linux+v3.2.6/Documentation/thermal/sysfs-api.txt
<orated> Great!
<orated> I'm not sure about changes to make under /sys/devices/virtual/thermal .. could you guide me on that?
<orated> I see colling_device and thermal_zone there
<ohsix> sforshee: can you amend the article? https://wiki.ubuntu.com/Hotkeys/Troubleshooting (README.keymap.txt has been README.keymap.txt.gz for a while)
<ohsix> sforshee: wouldn't it be funny if they stopped working because g-s-d removed the bindings for enable and disable, and just have toggle? :D
<ohsix> sforshee: yea if i map them to toggle instead of enable/disable they work, and a bunch of other keymaps included with the udev version on natty are broken/obsolete in the same way
<jwi> ohsix: reminds me of http://lists.freedesktop.org/archives/xorg/2010-November/051727.html :)
<ohsix> hey that looks like a useful reference, thanks
<ohsix> similar timeframe to my frustration too
<ohsix> arghh that explains why they all still exist in a udev keymap too
<ohsix> bbl, thanks again
#ubuntu-kernel 2013-02-11
<ppisati> moin
<smb> morning
 * apw yawns
<ppisati> brb
<henrix> apw: hi! could you please help me with the linux-overlay file?  I added some locals there last friday and i still can't see the updates on the matrix
<henrix> apw: CVEs 2013-0216 and 2013-0231 should have been updated already. 2013-0217 has been added a few minutes ago.
<apw> henrix, sure
<henrix> apw: cool, thanks. this is not urgent, of course ;)
<apw> CVE-2013-0216 has no break-fix: information ?
<henrix> apw: no, they all have a patch: section only
<apw> retired/CVE-2012-0055: break-fix: 549ffd5a07c9098a6a1c7a82e7fd731a132fc1a0 local-2012-0055
<henrix> gah! so that's it
<apw> so there is an example how you might represent a 'local' fix
<apw> obviously the first sha1 can be '-' as well
<henrix> apw: yep, got it. sorry to bother with this ;)
<henrix> thanks a lot
<apw> henrix, np, it is not really your fault, it is an esoteric thing which i have never correctly documented
<apw> henrix, also .. you would need those to be different
<apw>  :title('UBUNTU: SAUCE: netback: correct netbk_tx_err to handle wrap around.', ['local-2013-0216'])
<apw>  :title('UBUNTU: SAUCE: xen/netback: shutdown the ring if it contains garbage.', ['local-2013-0216'])
<ogra_> heh
<apw> henrix, so they likely should be like 'local-2013-0216-1' and -2
 * ogra_ read nethack
<apw> ogra_, heh :)
<apw> now that would be something to have in the kernel, a complete nethack on the console
<henrix> apw: ah, the 'local-...' thing has to be different. ok, makes sense. any convention for that naming?
<apw> henrix, same for both the recent ones you added
<ogra_> "finally steam included in the kernel, just modprobe your favorite game !"
<apw> henrix, local-<cvenumber>[-<patch number>] i suppose
<henrix> apw: ack, thanks
<apw> henrix, but ... as long as it starts local- i think you can do what you want
<henrix> cool
<apw> henrix, i really should get with security and move that file into their repo, it makes little sense for it to be separated
<henrix> apw: yeah, it would make sense to keep it in the same place.
<infinity> henrix: I see all the fsnotify changes have made a comeback in this SRU round.  Are we sure the backport is complete this time? :)
<henrix> infinity: i hope so :)
<henrix> infinity: we did a lot of testing and couldn't reproduce any of the issues we've seen before. so, confidence is high
<henrix> (famous last words, i know...)
<infinity> henrix: Fingers crossed, then.  I ask because I'll need to install the current SRUs on sagari to validate my two bugs for you guys, and I'd prefer not to be installing something crap. :P
<infinity> henrix: But I guess I can install, verify the two bugs, and roll back.
<infinity> Well, not that you'll lose any sleep if I don't verify the HVC console bug.
<henrix> infinity: heh, right. i've been running these kernels myself (Q and P) and haven't seen any issue.
<infinity> But the tg3 one is actually a pretty awful bug that's not PPC-specific.
<henrix> infinity: i may not lose my sleep, but i'll be ping'ing you soon if you don't verify them :)
<infinity> henrix: Yeah, maybe I should say "*I* wouldn't lose any sleep if I lied about verifying the console bug, but the tg3 one is dreadfully important".
<henrix> heh, ok. i don't need to know that, do i?
<infinity> Well, if I verify the important one, I'll be doing the other at the same time, so disregard any claims of lying. ;)
<infinity> Sadly, I no longer have direct access to the hardware, so I'll have to puppet GSA through it all.
<apw> henrix, to be absolutly correct, for linux-lowlatency tracking bugs i need to 1) get the title version right, and 2) switch upload-to-ppa to InProgress once all packages are in the PPA and building
<henrix> apw: if that was a question, the answer is 'yes' :)
<apw> henrix, heh yeah it was, i was wondering how it knows whether i need a meta or not, and am assuming thats why i move it InProgress  after upload not before
<henrix> apw: for derivative kernels, the bot doesn't know if a -meta is required or not (i.e., you need to manually set the task if there's an abi bump)
<henrix> herton: ^^
<henrix> herton: not sure if there's some specificity for the lowlatency kernels...
<apw> herton, henrix, see i am confused again :)
<herton> apw, just get the title version right, upload-to-ppa can be set to fix released. But with the right version the bot should move tasks without problem now, it just ignores upload-to-ppa for now
<apw> herton, and it will handle -meta without my brain
<herton> apw, correct
<henrix> interesting...
<apw> sweet, and upload-to-ppa i can do waht i like with, ie Inprogress it when i start making them
<henrix> i know that for -ec2 kernels it didnt handle the -meta...
<apw> Fixreleased now cause i have uploaded it and it is building
<herton> henrix, if it didn't handled it's a bug, I have to check
<apw> herton, https://bugs.launchpad.net/kernel-sru-workflow/upload-to-ppa/+bug/1117449 and https://bugs.launchpad.net/kernel-sru-workflow/upload-to-ppa/+bug/1118282
<ubot2> Ubuntu bug 1117449 in linux-lowlatency (Ubuntu) "linux-lowlatency: 3.2.0-38.38 -proposed tracker" [Medium,In progress]
<ubot2> Ubuntu bug 1118282 in linux-lowlatency (Ubuntu) "linux-lowlatency: 3.5.0-24.23 -proposed tracker" [Medium,In progress]
<dhanasekaran> Hi Guys, Where i can find kernel release notice please guide me
<apw> herton, in theory those are 'minimum andy input' done on them.  i will watch them to see what sb does to them
<herton> apw, ack
<apw> herton, i wonder if henrix fixed the title on his to the right version
<herton> apw, probably yes, I'll take a look to see what happened
<henrix> herton: about the -ec2, the bot creates the -meta task but if there's not ABI bump, then i need to manually set to to 'invalid'
<herton> henrix, actually I placed a code in the bot that should in theory set it to invalid too
<apw> herton, ok sb just did something to the bugs, it just slamed the prepare-package to in progress and by the changelog preparer .. nice, will watch the meta now which was behind it timewise
<henrix> herton: hmm, ok. i'll pay attention to that next time. thanks
<herton> apw, yep, seems sb is doing things as supposed, meta I'll follow on it too
<zequence> apw: Uploading to PPA. Is that meant for the Ubuntu Studio kernel team to do later?
<zequence> Or, could we not do that?
<zequence> To our own PPA, that is
<apw> zequence, currently they are coming through the main kernel team PPA, so currently you cannot do
<dhanasekaran> Hi Guys, Where i can find kernel release notice please guide me
<zequence> dhanasekaran: Is this what you need? https://lists.ubuntu.com/#Package+Upload+and+Automatic+Notification+Lists
<zequence> dhanasekaran: You could add a filter to your mail for excluding anything else but kernels
<dhanasekaran> zequence: thanks, i will do
<herton> henrix, is  linux-ec2 - 2.6.32-350.59  the current one for this cycle?
<herton> henrix, nevermind, now I saw it's from January
<henrix> herton: its bug #1119764
<ubot2> Launchpad bug 1119764 in linux-ec2 (Ubuntu) "linux-ec2: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1119764
<henrix> version hasn't been set yet
<zequence> dhanasekaran: You can also subscribe to this. You'll get notified whenever a new release is being prepared https://launchpad.net/ubuntu/+source/linux
<herton> henrix, so it's not prepared yet correct? The sb behaviour I'm talking should only happen since last week, when I commited the changes
<henrix> herton: ah, ok. so that's why i haven't seen that yet :)
<dhanasekaran> zequence: I Believe it's very hard, to find release notice. for newbies
<zequence> dhanasekaran: Released kernels will of course appear when you do apt-get update, so in that sense, I don't agree. And I'm a mere newbie myself, you could say. If you subscribe to the LP bug, you can add a filter for it right there. Mail filtering is more or less required when subscribing to high volume mail lists, which is hard to avoid in this case :)
<dhanasekaran> zequence: I got change log from /usr/share/doc/linux-image-3.2.0-37-generic# ls -ltr   
<dhanasekaran> total 28
<dhanasekaran> -rw-r--r-- 1 root root  1292 Jan 24 10:28 copyright
<dhanasekaran> -rw-r--r-- 1 root root 23414 Jan 24 11:11 changelog.Debian.gz
<zequence> dhanasekaran: Ah, so you were looking for the changelog? 
<dhanasekaran> zequence: changelog release notice look like same are difference ?
<zequence> dhanasekaran: I misunderstood you. I thought you wanted to be noticed of releases
 * rtg__ works on Raring -rc7 rebase
<zequence> apw: I take it you are working out the procedure and I'm not required to do anything for the bug report as I was assigned to Prepare-package?
<dhanasekaran> zequence: I requirement is I have two different version of kernel installed in my server. But I want know what the specific changes done and modified newer version of kernel.
<apw> zequence, indeed, we have added some tooling to make those just work
<apw> you are getting assigned to the ones you did as they complete rather than you having to care
<apw> herton, so .. is sb hourly ?
<herton> apw, I belive it's on a 15min cron run, brad runs it
<herton> *believe
<apw> herton, ok, well i'll give it a while, but if so i think it has ignored my -meta, its not expecting the version to be the smae form is it
<herton> apw, no, it just checks the abi part
<herton> apw, let me run manually here
 * apw idly wonders how it maps emails to launchpad ids
<zequence> dhanasekaran: You could use aptitude too. aptitude changelog <package>
<herton> apw, it checks the launchpad ids with launchpad api, each upload has a property saying who created the package
<herton> apw, running manually it seems did the right thing
<apw> herton, ahh i see
<apw> herton, odd ... lack of patience on my side then ?
<herton> apw, perhaps bjf set the bot to run in intervals greater than 15 min, I thought it was each quarter of an hour but perhaps is more
<zequence> There's also apt-listchanges. It shows the changelog when doing an upgrade
<zequence> dhanasekaran: ^
<apw> herton, *shrug* ... if it works for you i guess it works :)
<dhanasekaran> zequence: my question release notice and change log same? or different?
<apw> dhanasekaran, i would not expect them to be the same, for me release notes tell you what has changed which you need to worry about, changelog tells you everything changed
<herton> apw, yep, looks fine and I commited things hehe, will keep a look if something doesn't go as planned
<zequence> dhanasekaran: English is not my native language, and I often mix up terms, but I usually say changelog. I misunderstood your sentence for something like: to be notified fo changes, like when a new release is out.
<zequence> Or, rather, to be notified of a new release
<apw> herton, does (can) shankbot handle the 'non series' kernel specific thingy ?
<apw> herton, like linux-lowlatency (Ubunt) when we are targetting quantal
<herton> apw, you mean linux-lowlatency uploaded to development series used in quantal?
<apw> https://bugs.launchpad.net/kernel-sru-workflow/upload-to-ppa/+bug/1118282
<ubot2> Ubuntu bug 1118282 in linux-lowlatency (Ubuntu) "linux-lowlatency: 3.5.0-24.23 -proposed tracker" [Medium,In progress]
<apw> herton, there are two linux-lowlatency tasks there, one for raring and one for quantal
<apw> the raring one is just an artifact of the bot not accepting the nominations
<apw> once the nomination is accepted, the non-nomination is invalid
<herton> apw, ah ok, it just ignores the development tasks. But I could make the bot or create-release-tracker to set it to invalid
<apw> herton, maybe after it has been nominated ... dunno, not sure
<herton> apw, yes, there are two cases, if who is creating the tracking bug has permissions or not to nominate (upload rights in fact). probably I'll have to do something also in the bot to automatically fix this
<apw> herton, though in theory the bot runner currenlty does
<herton> apw, yep
 * herton -> lunch
<timblechmann> hi, after building a 3.8-rc kernel, i cannot build the dkms modules: it complains with: ERROR (dkms apport): kernel package linux-headers-3.8.0-rc7 is not supported
<timblechmann> is this a known problem and is there any workaround?
<timblechmann> (same message with virtualbox and nvidia dkms drivers)
<rtg__> timblechmann, you're a little ahead of the process. give it a day until the -rc7 kernel is in the archive.
<timblechmann> rtg__: i have a custom configuration, similar to the -low-latency kernels, but with some tweaks ... so in a way i prefer to build myself (have been doing this with make-kpkg for some time)
<infinity> timblechmann: If you're building yourself, you also need to install the headers yourself, so dkms can find them.
<zequence> timblechmann: Just out of interest. What are you using your kernel for, and how does it differ from -lowlatency?
<rtg__> apw, ogasawara: pushed -rc7 rebase. haven't tagged it yet since I wanna make sure the perf tool builds for all 3 arches.
<ogasawara> rtg__: ack
<apw> rtg__, thanks
<timblechmann> infinity: linux-headers-3.8.0-rc7 *is* installed
<timblechmann> that's why i'm here
<timblechmann> usually installing image/header and dkms works out of the box ... but with 3.8 it seems to fail for some reason
<timblechmann> zequence: don't remember the details ... but i have a configuration which i sometimes use with -rt kernels ...
<infinity> timblechmann: Is there an error above that one?  That's only supposed to trigger if the build failed.
<infinity> timblechmann: That's apport saying it won't report a bug because that package isn't a distro package.  But it needs to have had a reason to want to report a bug in the first place.
<infinity> rtg__: \o/ perf.
<zequence> timblechmann: If you think there is something that would be good to improve for the -lowlatency config, let me know. I'm the kernel guy for Ubuntu Studio atm
<rtg__> infinity, I noticed you promoted libaudit-dev
<infinity> rtg__: Yeah, I poked Leann and Andy about it, I would have poked you, but you insensitively log off IRC every night so I can't abuse you. :)
<rtg__> infinity, indeed :)
<zequence> timblechmann: I've been meaning to do some testing, to see if we could imrpove performance in different ways, so any good info about that would be helpful
<timblechmann> zequence: will need to double-check
<timblechmann> infinity: the error message of the nvidia-current module is something along the lines that i cannot determine the kernel version
<infinity> timblechmann: Kay, that's the real failure, the apport message is a red herring.
<ppisati> brb
<timblechmann> infinity: regarding virtualbox: it cannot find generated/bounds.h
<timblechmann> ... which is in /usr/src/linux-headers-3.8.0-rc7/include/generated/bounds.h
<infinity> timblechmann: Kay, both of those seem like a potential issue on your end, mind you, not dkms.
<timblechmann> infinity: so ... it works out of the box with earlier kernels, but with 3.8 it stops working ... any idea, why?
<infinity> timblechmann: Well, it works with our 3.8 packages too, AFAIK.  So, no idea why your headers seem to be unfindable.  Missing a build symlink?
<infinity> timblechmann: As in /lib/modules/3.8.0-rc7/build -> /usr/src/linux-headers-3.8.0-rc7
<timblechmann> infinity: /lib/modules/3.8.0-rc7/build -> /media/hd3btr/sources/linux-3
<timblechmann> which is the location of my source tree
<timblechmann> (at the correct git revision)
<infinity> timblechmann: You just said it was /usr/src/linux-headers-3.8.0-rc7 :P
<infinity> timblechmann: source tree != installed post-build headers.
<timblechmann> infinity: i'm not hacking the kernel every day ... but afaict, dkms does a preparation-step to generate the headers
<timblechmann> infinity: again ... that has been the case for the last years and it worked fine
<infinity> dkms doesn't generate headers, it just looks where you tell it to.
<infinity> Now, there may be a curious bug in make-kpkg, if your build symlink is wrong, but I don't think we've updated it in ages, have we?
<timblechmann> infinity: ah 
<timblechmann> dkms does `make prepare-all'
<timblechmann> which is not a make target
<timblechmann> infinity: or rather: the dkms installer for the nvidia module does a `make clean' and `make prepare-all' step
<infinity> win 37
<smb> tseliot, I bet you are aware of that already but I was not so pleased to see fglrx-updates in Precise render my media pc unusable (due to AMDs weird support policy)
<dhanasekaran> Hi Guys, what are patches applied to the current kernel 
<dhanasekaran> [RFC,3/3] x86,smp: auto tune spinlock backoff delay factor I want to know the patch applied or not
<tseliot> smb: err... was your card dropped?
<smb> tseliot, Yeah, one of those unfortunate onboard chips they moved into "legacy"
<dhanasekaran> auto tune spinlock backoff delay factor? It's support ubuntu kernel
<tseliot> smb: sorry about that. AMD don't have proper release notes for their driver releases...
<smb> tseliot, Just that the previous version worked and the update removed it was, slightly unexpected. ;) For now I moved back to fglrx (release)
<tseliot> smb: that's probably your best bet. Eventually you'll have to move to radeon though
<dhanasekaran> Guys we have spinlock issue in our ubuntu kernel auto tune spinlock backoff delay factor I want to know the particular patch applied or not https://patchwork.kernel.org/patch/1904881/
<ogra_> yeah, who needs acceleration on a media PC anyway
<rtg__> apw, ogasawara: raring 3.8.0-6.11 tagged, pushed, and uploaded
<smb> tseliot, Yeah, since the legacy driver lags behind in supported X and kernels...
<tseliot> smb: yes, exactly my point
<smb> ogra_, For better energy management maybe. :)
<ogra_> pfft ... its not like you play movies or games on it .... errr :)
<apw> rtg__, thanks
<smb> ogra_, naaah :-P
<smb> tseliot, btw, there is sort of a bug about that which has reached a hellish heat. ;) bug 1058040
<ubot2> Launchpad bug 1058040 in fglrx-installer (Ubuntu) "fglrx-installer not working with AMD Radeon/Mobility Radeon HD 2000-4000 cards in Quantal" [Wishlist,Triaged] https://launchpad.net/bugs/1058040
<apw> dhanasekaran, that patch does not appear to be applied even to linus' tree, so it is doubtful we have it
<tseliot> smb: my hands are tied. The legacy driver doesn't support Quantal's xserver ABI
<smb> tseliot, I realized that when looking at that during the weekend. Just found the heat number amusing... :)
<apw> dhanasekaran, though it really isn't going to affect small machines by my reading, where small is pretty big in 'our' world
<tseliot> smb: I'll add a comment to the bug report...
<dhanasekaran> apw: We have 32 core machine, we have issue with spinlock issue
<dhanasekaran> apw: How to apply with ubuntu kernel
<dhanasekaran> apw: I have go with vanilla kernel? with ubuntu base 
<dhanasekaran> apw: please guide me.. How to resolve this..
<infinity> dhanasekaran: It's not in the vanilla kernel, that was his point.
<apw> dhanasekaran, i am supprised you would be seeing any sort of issues with that small a system but, if you want to test the patch you would have to apply them and build your own kernel as they are not yet in even linus' master tree so none of the trees we maintain would have the relaevant patch for testing
<ogra_> https://help.ubuntu.com/community/Kernel/Compile
<apw> dhanasekaran, he does imply that the thing is a tunable, so there may be existing tunables in your kernel which may allow you to confirm this is the fix for your issue before you go to the effort
<dhanasekaran> apw: please look https://patchwork.kernel.org/patch/1904881/
<stgraber> sforshee: hey, what's the status of bug 1098216? wasn't that supposed to make it to the Ubuntu kernel weeks ago? :)
<ubot2> Launchpad bug 1098216 in linux (Ubuntu) "Regression in brightness control on Lenovo Thinkpad x230" [Medium,Triaged] https://launchpad.net/bugs/1098216
<sforshee> stgraber, I got distracted by other stuff, and also spent a little time looking to see if there was a more generic way to quirk for this since we're up to 6 models now
<stgraber> sforshee: oh, I see some activity in the upstream bug, right
<sforshee> yeah
<sforshee> I'm trying to get the new models tested
<sforshee> sorry for the slow progress
<mainerror> Hello there.
<apw> dhanasekaran, i did look, that patch isn't in any kernel yet it is still only a "for discussion" patch
<apw> dhanasekaran, no vanilla kernle has this patch therefore runing those will not help you
<sforshee> stgraber, I'm going to shoot the patch upstream today to see if anyone has any better suggestions, I'll be sure to send it for raring sometime this week
<stgraber> sforshee: no problem, I'm using the cmdline argument here, just wanted to make sure it wasn't blocked on something and was still going to make it in our kernel soon :)
<mainerror> Is there any ETA on the integration of RC6 in Raring?
<dhanasekaran> apw: thanks for you clarification. How to resolve my spin lock issue kill my server machine..
<infinity> mainerror: rc6 is already in raring.
<mainerror> Whoa! Really?
<mainerror> :)
<infinity> mainerror: If you meant rc7, rtg just merged it, and is working out some final kinks.
<apw> dhanasekaran, i have no idea what your issue even is, if you think this patch might resolve your issue, you could try adding this patch yourself and building a kernel for comparison
<apw> infinity, unless he means the other rc6 the graphics one
<mainerror> rc6 is just fine for me. I own a Samsung Series 9 notebook and the samsung-laptop drivers were a blocker for me.
<mainerror> Great news then. Thanks!
<apw> mainerror, is this the brickage laptop?
<mainerror> Yea.
<apw> is it in bios or efi mode ?  as the issue only occurs in efi
<mainerror> I'm aware, yea.
<mainerror> In EFI.
<apw> the safest thing to do is switch to bios
<apw> not that the issue is actually linux there at all
<apw> but actually a bug in the efi bios
<mainerror> It is a bug in the BIOS yea.
<mainerror> I know that in rc6 samsung-laptop has just been blacklisted which temporarily fixes the brickage when booting in EFI mode.
<infinity> In theory, mind you, the current version of samsung-laptop no longer tickles the bug.
<mainerror> Oh?
<infinity> (or, as you say, doesn't load in EFI mode)
<infinity> (which doesn't tickle the bug)
<mainerror> Ah yea.
<apw> i think you are referring to the same work-around in both cases
<infinity> But... With a bug like that, I'm with Andy.  Just run in BIOS mode.
<apw> though you can do the same thing in windows it seems too
<infinity> Yeah, Matthew wrote the Windows PoC as a way to wake people up to it not being a "Linux problem".
<infinity> It's trivial to do from any OS, really.
<mainerror> Then there's this other strange issue. Apparently those notebooks are a thermal mess. Watching two or three YouTube videos or doing other graphic intensive stuff will trigger a kernel panic.
<mainerror> I wasn't able to pin it down completely yet.
<mainerror> I believe it is a thermal problem of some sort.
<infinity> It could just be a dead fan.
<mainerror> The odd thing is that it doesn't happen on Windows 8 (default OS on that thing).
<apw> mainerror, well ... it really can
<apw> mainerror, you can kill your box in windows in about 10s
<apw> windows just gets lucky, and ... well it would as they tested that before releaseing it
<dhanasekaran> apw: check third fix it's look like spinlock solution  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=39923134885759405e64cb9491a273a2bcd356ed
<mainerror> I was able to take a picture when a kernel panic occurred though. http://ubuntuone.com/0OzMcDHB5mIyKHpCmdIFe1
<apw> dhanasekaran, that looks like a completely different patch which avoids some lockups
<apw> dhanasekaran, and it applies to arm cpus, is your 32cpu job arm based?
<dhanasekaran> apw: no Intel cpu.. wrong search for me.
<chadbyoung> boot process is hanging - please take a look it you have a minute. http://pastebin.com/1HviMyHR
<chadbyoung> using an Odroid-pc board and trying to boot Ubuntu on a SATA disk
 * ppisati -> gym 
<infinity> rtg__: Why the NO_LIBPYTHON for perf?  Is the feature useless?  The build-dep certainly wouldn't hurt?
<rtg__> infinity, its a wrapper around the perf call.  I didn't think adding yet another build dependency was really necessary. tools/perf/python/twatch.py is the only thing that requires it.
<rtg__> I think
<rtg__> maybe I'm all wet.
<infinity> tperf just looks like PoC code to talk to the perf python module.
<infinity> Which I assume is C, and in the parent directory?
<infinity> Maybe?
<rtg__> not sure, still checking
<infinity> script/python
<infinity> Has a bunch of scripts, and a C module.
<infinity> There's a perl module too, do we build that?
<rtg__> I think the only binary that gets packaged is perf itself.
<rtg__> looks like there has been some changes since the last major kernel version.
<infinity> This stuff all so desperately wants to not be in the kernel source.
<infinity> We should be building a proper python module package, a proper perl module package, all the cute GUI crap, etc.
<infinity> But that has no business in a kernel build.
<rtg__> infinity, agreed. so NO_LIBPYTHON prevents some python support libraries from getting built.
 * rtg__ -> lunch
 * ppisati -> dinner
<penguin42> I just moved bug 1114673 to triaged; reporter confirmed it still happens on upstream - should I dupe bug 1070256 back to it?
<ubot2> Launchpad bug 1114673 in linux (Ubuntu) "mount.cifs occasionally causes GPF error/kernel panic when mounting at boot [crypto_larval_kill+0x2b/0x90]" [High,Triaged] https://launchpad.net/bugs/1114673
<ubot2> Launchpad bug 1070256 in linux (Ubuntu) "mount.cifs occasionally causes GPF error/kernel panic when mounting at boot [crypto_larval_kill+0x2b/0x90]" [High,Confirmed] https://launchpad.net/bugs/1070256
<penguin42> (1114673 was originally a dupe of 1070256 but the reporter of 1114673 was actually responsive and provided logs and tried upstream on his bug)
<apw> that doesn't seem wholy unreasonable
<penguin42> done
<penguin42> the other one I'm not sure what to do with is bug 1093217  they've got a boot hang that appeared on 3.2.0.30 - they've tried a bisect but either something odd is happening or they've gone down a weird path
<ubot2> Launchpad bug 1093217 in linux (Ubuntu) "Ubuntu 12.04 10-20min boot delay (From 3.2.0.29->3.2.0.30) [Lenovo IdeaPad Z580]" [High,Incomplete] https://launchpad.net/bugs/1093217
<Kano> hi, what was the dl url for the 3.8-6 kernel?
<ohsix> man you seriously can't figure anything out :[
<Kano> it is not in main yet
 * rtg__ -> EOD
#ubuntu-kernel 2013-02-12
<ppisati> moin
<smb> morning
 * apw yawns
<melkor> Hello, I am trying to build a driver and I get an implicit function declaration error for __netdev_printk
<melkor> I think this function has been removed from the 3.7 kernel and I'm curious if it has been replaced or changed.
<melkor> Deleted the function call and the driver compiles fine. It sucks that the driver hasn't found its way into the kernel. It is the ethernet driver for newer atheros cards.
<ppisati> brb
<dhanasekaran> Hi Guys, How to find one particular  process how many open files are there, any way to identify?
<melkor> dhanasekaran: seems like this might not be the correct channel for that question. Did you mean #ubuntu?
<dhanasekaran> melkor: it's process related right?  process  guys talk to libc. The kernel must know the list of open files right.
<melkor> dhanasekaran: I'm not arguing with you I'm just offering you a suggestion that might improve your chances of getting help.
<dhanasekaran> melkor: thnaks.
<rtg> smb, rebooting gomeisa for _something_, but can't remember what.
<smb> rtg, ok, I am off
<dhanasekaran> apw: yesterday I asked one question, How to find particular path, available or not? You said no available in Linux tree. I agree. I want to know how to find it. It's helpful my further searches please guide me, I already download code from github
<apw> dhanasekaran, from what i could see that patch was only on the mailing list, i think your link was to patchworks
<apw> dhanasekaran, though it was also 3/3, ie the third one of a set and likely no use on its own
<dhanasekaran> can i find patch history from gitk
<apw> if a patch is only on the mailing list, then it is not in git, therefore not in gitk
<smb> rtg, did the something turn out to be a pain?
<rtg> smb, gomeisa not back ?
<smb> rtg, sort of... just not letting me in
<rtg> crud, better go check
<rtg> smb, gomeisa is back
<smb> rtg, thanks
<rtg> this smatch run is taking forever
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> rtg, so you can't hear me, eh?
<rtg> jsalisbury, nope
<jsalisbury> rtg, whoops, I was wondering why it was so quiet :-)
<rtg> jsalisbury, still no sound
<jsalisbury> rtg, ok, let me see what broke
<rtg> jsalisbury, you are screwed today
<jsalisbury> rtg, yup.  I'll try to figure out what happened after the IRC meeting.
<tjaalton> 'ubuntu-bug linux' fails on raring, claims -5-generic is 3rd party, known?
<ohsix> check aptitude and see if it's in the obsolete or locally created packages section, if it isn't, i dunno :]
<tjaalton> ohsix: indeed, -6 is out :)
<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 February 19th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati goes for some sweating - later...
<apw> henrix, ok ... looks right now
<henrix> apw: \o/
<henrix> apw: any other thing i missed there?
<apw> nope, the ' thing was the primary problem, then the raring things were simply sha1s coming available later
<henrix> apw: ah, ok. thanks a lot for your help
<jsalisbury> bjf, henrix, herton bug 1119809 is a regression in 3.2.0-38.59 that is affecting allot of people.  The issue doesn't happen in 3.2.0-37.58
<ubot2> Launchpad bug 1119809 in linux (Ubuntu) "Desktop login freeze with kernel 3.2.0-38.59" [Medium,Confirmed] https://launchpad.net/bugs/1119809
<bjf> jsalisbury, ack
<jsalisbury> bjf, I haven't started a bisect for it yet, but I can do so
<henrix> jsalisbury: looking, thanks
 * rtg -> lunch
<herton> jsalisbury, it seems I'm able to reproduce here, I'm starting a bisect here
<jsalisbury> herton, cool, thanks!
<bjf> slangasek, we loaned you a mac. i thought it was so something would be fixed so we didn't have to produce +mac isos. i just noticed we are still producing them so i'm assuming you have not finished that work?
<slangasek> bjf: correct, I have not :/
<slangasek> you need the macs back?
<bjf> slangasek, nope, all good, just making sure we were not building +mac isos unnecessarily
<slangasek> sadly no
 * henrix -> EOD
 * rtg -> EOD
<sforshee> stgraber, can you try out the kernel at http://people.canonical.com/~sforshee/lp1098216/linux-3.8.0-6.11~lp1098216v201302121943/ on your x230?
<sforshee> this is a different approach to the backlight problem
<stgraber> sforshee: yep, will do
<sforshee> stgraber, thanks. Be sure you don't boot with acpi_osi="!Windows 2012".
<stgraber> sforshee: oh, I see, you're doing it the Windows way then ;) set all the values in the array from the current one to the one we actually want
<sforshee> stgraber, yep. That's what I was asked to do when I tried to get the quirks upstream.
<sforshee> stgraber, what you'll probably see is that it mostly works, but in one or two spots the brightness won't actually change when you adjust it through the desktop
<sforshee> g-s-d divides the range up into 20 steps but there are only 16 valid values
<stgraber> I rarely use the GUI tool, I usually just use the hotkeys which give you 8 levels IIRC
<stgraber> you only get the 20 if you go through the control center I believe
<sforshee> hmm, okay. Those must be generating backlight events rather than keypresses then.
<sforshee> stgraber, please try it both ways, I'd like to know the results
<sforshee> stgraber, also try directly writing the value in /sys/class/backlight/acpi_video0/brightness back into that file. That's an edge case I want to be sure gets tested.
<stgraber> ok
<stgraber> my laptop should be available for testing in a few minutes, finishing a couple of upstart and network-manager builds now ;)
<sforshee> stgraber, at your leisure ;-)
<stgraber> sforshee: bad news for you, doesn't work
<stgraber> sforshee: using the hotkeys in X (which are caught by g-s-d), I can't change the brightness level, it gets stuck at maximum
<stgraber> looking at the value of brightness, I can bring it down to 95 as the lowest value (actual_brightness remains at 100)
<sforshee> stgraber, drat
<stgraber> sforshee: going through the full gnome-control-center applet works though
<sforshee> hmm, okay
<sforshee> stgraber, when you say you can bring brightness down to 95, how are you doing that?
<sforshee> (note that reading actual_brightness is going to reset brightness to the actual value your firmware thinks the value is, which is the last valid value written)
<stgraber> fn+F8 which shows me the notify-osd brightness stuff. The slider appears as slightly less than maximum but there's no actual change in screen brightness
<stgraber> sforshee: I've been tracing gnome-settings-daemon a bit here and looking at the dbus calls, when going through gnome-control-center only SetPercentage calls are emited
<stgraber> when using the hotkeys, I see a GetPercentage call and a StepDown call instead
<stgraber> so depending what file GetPercentage is reading, this may explain why it gets stuck
<sforshee> stgraber, run acpi_listen and press your hotkeys and tell me what output you get
<stgraber> F8 is: video LCD0 00000087 00000000
<stgraber> F9 is: video LCD0 00000086 00000000
<sforshee> that's what I thought
<sforshee> so acpi_video handles those events internally to adjust the brightness
<sforshee> unfortunately when it does that it's calling _BQC to ask the firmware what it thinks the brightness is
<sforshee> so it's always getting the last value that actually applied
<stgraber> so it that explains why it's trying to set the same value over and over again without any actual result
<stgraber> s/it//
<sforshee> yeah, it always tries to get the next larger or smaller value, but when it writes that to the firmware the value just gets discarded
<sforshee> the next time it asks it just gets the same thing it got the previous time
<sforshee> stupid firmware
<sforshee> so the question then is does acpi_video really need to ask, or can it just use the cached value it already has
<stgraber> do we have firmware that messes with the value by itself? if not, then cached should be safe
<stgraber> (thinking of some of those machines with ambient light sensors, not sure whether it's just exposed to the OS or if the actual brightness change is done by the firmware)
<sforshee> I don't know, the code is way more careful than I'd think it needs to be
<sforshee> it doesn't even assume that the value it got from the firmware is one of the values the firmware said is valid
<sforshee> stgraber, even if I fix this bug your hotkeys are going to work terribly. They're going to cycle you through 100 brightness values, most of which do nothing.
<stgraber> great...
<sforshee> anyway I've got a patch to fix it already, so I'll spin a build to verify that I understand the problem correctly. Then I'll go back to the upstream folks and describe the problems with the solution they're asking for.
<PatrikOlsson> Hey guys, I want to add data from a test I did for the PowerManagementALPM. How can I add this to the wiki?
<sforshee> stgraber, http://people.canonical.com/~sforshee/lp1098216/linux-3.8.0-6.11~lp1098216v201302122215/
<sforshee> let me know if that gets the hotkeys working, even if it is suboptimal
<stgraber> sforshee: ok. I'll get you some results tomorrow. I'm on 3G for the rest of the day so I'll avoid any massive download :)
<sforshee> stgraber, np
<stgraber> sforshee: hey, looks like your kernel bricked my machine...
<stgraber> sforshee: or rather, it apparently failed to suspend, when I noticed it was rather hot already and had a nice kernel panic on the screen. Since it won't boot at all, not getting anything from the firmware
#ubuntu-kernel 2013-02-13
<PatrikOlsson> I'm going to bed now, I would really appreciate if someone would spend two seconds looking at the question!
<PatrikOlsson> I just want to contribute
<stgraber> sforshee: so, it looks like my laptop is a brick... I tried pulling the battery, memory, hdd, ... nothing helped
<PatrikOlsson> nvm, good night
<stgraber> sforshee: but it reminded me of the Samsung UEFI issue, I believe it's the first time I get a real panic on that machine
<stgraber> sforshee: and my understanding is that we dump the panic to nvram now with new kernels
<stgraber> sforshee: could it be that doing this somehow breaks Lenovo laptops?
<stgraber> mjg59: ^ (thinkpad x230, 3.8 kernel on UEFI, kernel panic, won't show me anything since)
<ppisati> moin
<smb> ppisati, again ... bah! ;-P
<ppisati> smb: what? :)
<smb> ppisati, morning
 * apw yawns
<xnox> I see some references that "[PATCH] block: replace __getblk_slow misfix by grow_dev_page fix" made it all the way back to oneiric. Can somebody check if that patch is in precise generic kernels and up as well?
 * xnox is struggling to find commit id
<apw> ommit 7e9433b5394fd935dd6ea01dff601f23300aff83
<apw> Author: Hugh Dickins <hughd@google.com>
<apw> Date:   Thu Aug 23 12:17:36 2012 +0200
<apw>     block: replace __getblk_slow misfix by grow_dev_page fix
<apw>     
<apw>     BugLink: http://bugs.launchpad.net/bugs/1049899
<apw>     
<ubot2> Ubuntu bug 1049899 in linux (Ubuntu Precise) "Precise update to 3.2.29 stable release" [Medium,Fix released]
<apw>     commit 676ce6d5ca3098339c028d44fe0427d1566a4d2d upstream.
<apw> xnox, that is from precises
<xnox> apw: awesome, thanks.
<apw> xnox, and that was in Ubuntu-3.2.0-32.51
<cking> apw, http://www.x.org/wiki/IntelGraphicsDriver
<henrix> apw: unless you're already on it, i'll apply herton's i915 patch into master-next so that i can start the respin
<apw> henrix, you go ahead
<henrix> apw: ack
<apw> henrix, so we are respinning for it ?
<henrix> apw: well, that's a nasty regression and its affecting lots of people it seems
<apw> henrix, i cannot deny your logic
<henrix> heh
<apw> i was leaning that way myself
<apw> henrix, as this is the P kerenl it isn't on the P point release CDs in fact is it
<henrix> apw: no, this kernel won't be the one on the .2
<apw> henrix, great, no panic then
<henrix> apw: anyway, i'm going to prep everything, do all the testing etc, and leave it to brad to take the final decision ;)
<apw> henrix, an even better plan :)
<ogra_> apw, rtg, there is a new android release for nexus7 ... (not sure if it has a new kernel or wheer the source is though)
<rtg> ogra_, I can look.
<ogra_> it seems to add some stability acccording to the tests ... though i'm not sure if there is anything kernel related 
<rtg> ogra_, when was the update released ? I don't remember having to update my unit recently .
<ogra_> beginning of the week, but not released in all countries yet
<ogra_> (i would have assumed the US being the first one though)
<rtg> yeah
<rtg> ogra_, there don't appear to be any kernel updates in the google repo
<ogra_> well, it is supposed to have some BT fixes 
<ogra_> not sure if thats in userspace or kernel though
<rtg> maybe they don't push them right away
<ogra_> if google would only allow me to search in english ...
<ogra_> sigh
<apw> ogra_, add something like ?hl=en to the end of the google URL
<ogra_> (there used to be a "only english results" button for non natives ... )
<ogra_> oh, thanks !
<apw> it is something like that
<jpds> apw: That only changes the interface language.
<apw> jpds, hmmm i guess ogra_ can let us know :)
<ogra_> hmm ?
<ogra_> oh, i get english results now mixed with some few german ones
<ogra_> (didnt attach it to the end but edited it in the url)
<jpds> ogra_: Genau.
<ogra_> hmm, https://developers.google.com/android/nexus/images doesnt have a 4.2.2 image yet
<ogra_> so i guess you are right, they will roll out the ota ones first 
<herton> apw, there is someone reporting a mismerge on an overlayfs patch on quantal, bug 1122094
<ubot2> Launchpad bug 1122094 in linux (Ubuntu) "[patch] fix improper merge with overlayfs." [Medium,Confirmed] https://launchpad.net/bugs/1122094
<apw> herton, ok thanks
<apw> herton, it does look wrongo, quite how we ever get away with it, i am unsure
<herton> apw, yes, henrix and I also took a quick look and seems wrong, perhaps we got away as it most affects the error path in nameidata_to_filp, error returned probably is uncommon
<apw> yep
<shadeslayer> hi, after installing fglrx I get : http://paste.kde.org/670244/
<shadeslayer> any advice?
<apw> shadeslayer, never seen that before, it looks on the face of it to be a bug in modprobe
<shadeslayer> apw: I see bug reports on LP about this 
<shadeslayer> bug 1073062
<ubot2> Launchpad bug 1073062 in kmod (Ubuntu) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Undecided,Confirmed] https://launchpad.net/bugs/1073062
<shadeslayer> http://paste.kde.org/670292/
<shadeslayer> full log ^
<apw> i would regenerate the initramsfs again and see if it works
<apw> update-initramfs -u
<shadeslayer> apw: nope, same issue
<apw> tseliot, ^^ seen anything like this in your testing?
<tseliot> apw: yes but only when the module can't build against the kernel
<apw> tseliot, thanks
<shadeslayer> tseliot: well ... as I can see, the module does build
<shadeslayer> or maybe I'm reading it wrong?
<apw> shadeslayer, what does 'grep off /etc/modprobe.d/*' say
<shadeslayer> http://paste.ubuntu.com/1644200/
<apw> /etc/modprobe.d/fglrx.conf:alias radeon off
<apw> /etc/modprobe.d/fglrx.conf:alias lbm-radeon off
<tseliot> shadeslayer: also the output of "dkms status" might help
<shadeslayer> http://paste.ubuntu.com/1644202/
<apw> ok according to the debian bug it is those (added by fgrlx) which kill kmod
<tseliot> apw: how?
<apw> tseliot, it is broken
<apw> tseliot, it does not understand off
<apw> (seemingly)
<tseliot> apw: that would be a major issue
<apw> and one i would have thought someone would a
<apw> have noticed before now, given we have been using kmod for all of raring i think
<tseliot> right
<tseliot> maybe I should update my testing box again...
<apw> shadeslayer, ok for now i would try converting those two 'off's to be blacklist <foo> and see if you can build an initrd ok
<apw> shadeslayer, i will look into this in a bit
<shadeslayer> apw: ack
<shadeslayer> works :)
<apw> shadeslayer, i am unsure if that is enough to prevent it loading on reboot, it _should_ be
 * ogasawara back in 20
<BenC>  /srv/ubuntu/linux-ppc-3.8.0/ubuntu/alx/alx_main.c:239:2: error: implicit declaration of function âvzallocâ [-Werror=implicit-function-declaration]
<BenC> rtg: This compiled for you guys everywhere else?
<rtg> BenC, nope. in fact we disabled it for PPC, as should you
<rtg> BenC, PPC in Quantal I mean
<BenC> Ah, ok, I'll disable it
<BenC> rtg: Seems like an easy fix though (add some #include's)
<rtg> BenC, upstream is git://github.com/erikarn/alx.git. perhaps you could send 'em a patch.
<rtg> so far this device only exists on x86'en platforms
<BenC> I mightâ¦pretty low on my priority
<kamal> BenC, rtg: I'll take care of that (fixing and submitting patch to alx upstream) if you like.    now to find a PPC build machine . . .
<BenC> kamal: send me the patch, and I'll test it
<BenC> kamal: I can send you the full error log if you want
<kamal> BenC: sure: kamal@canonical.com
<BenC> kamal: Ok, give me a bit to get back to that point after this upload
<kamal> BenC: no rush, I've got plenty of stuff to break in the meantime
<kamal> on that note ...
<kamal> rtg: do you remember that day when I broke everybody's backlight?
<rtg> quite thirstily :)
<kamal> oh.   dang.
<kamal> well anyway ...    that was a fun day, right?   wanna do that again?
<rtg> only if I know there is free beer in it for me.
<kamal> there's a small i915 patch (really, very small -- couldn't hurt a fly its so cute) that is pending in drm-intel-fixes-nightly ...   I'm not sure whether it'll make it in before 3.9.
<kamal> so . . .   can I have it in raring pretty please?
<apw> kamal, if you want a patch you know where to send it ... :)
<rtg> submitted on the k-team list yet ?
<kamal> apw: hush, I'm just trying to warm rtg up first
<kamal> I'll be submitting it to k-team shortly.   yes, I agree in advance to whatever beer ransom you deem appropriate.
<apw> herton, on that overlayfs thing, i have posted test kernels for him, as he can tickle the issue
<rtg> ogra_, is the N7 image from today broken ? I can see Plymouth doing its thing, then the display goes dark. Plugging into the serial console works but I can't login since I have yet to setup a user.
<ogra_> rtg, hmm, there are issues, but nothing that should prevent you from installing
<rtg> ogra_, I've done it twice. would battery charge have any impact ? Mine might have been pretty low
<herton> apw, ack thanks
<ogra_> battery has surely some impact , i have seen the writing of images fail before due to it 
<ogra_> but you got beyond that step, it sounds more like ubiquity being evil to you or so
<rtg> well, I'll let it charge for an hour then try again
<rtg> apw, ogasawara: any patches pending for raring ? I'm thinking I'll upload in order to get kamal's backlight fix out there.
<apw> rtg, nothing i can think of
<ogasawara> rtg: nothing here
<rtg> ok then
 * rtg -> lunch
<plars> bjf, rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1124415
<ubot2> Ubuntu bug 1124415 in linux (Ubuntu) "Network installation fails with ahci" [Undecided,New]
<rtg> plars, ack
 * bjf[afk] -> lunch
<sforshee> stgraber, I just noticed the messages from you in my backscroll, yikes
<marvin24> dumb question: how to disable certain arch from kernel builds?
<stgraber> sforshee: yeah... waiting for Lenovo to come replace the system board...
<stgraber> sforshee: so that kernel test will have to wait a few days ;)
<sforshee> my first suspicion would be that trying to store the panic messages triggered some firmware bug
<stgraber> yeah. I don't think it's the first panic I had on that machine since I moved to the 3.8 kernel, but it can certainly depend on the size of the dump or maybe what's already in nvram
<sforshee> do you happen to remember any details about where the panic happened?
<sforshee> unfortunately there seem to be a lot of uefi bugs that are triggered by writing to nvram
<stgraber> sforshee: sadly my memory isn't that good and the laptop was overheating so I didn't wait long before removing the battery to get it to cool. The only thing I remember was that it wasn't bluetooth related (I had a couple of those lately so that's I remember quickly going through the stack looking for bluetooth stuff and not seeing any)
<stgraber> sforshee: do we have some kind of boot flag to turn off that feature (writing to nvram on panic)? because I don't want to end up bricking my replacement laptop ;)
<sforshee> stgraber, okay. Just wondering whether it was related to my changes or not.
<sforshee> not sure...
<sforshee> and that's assuming that writing the panic to nvram was the cause
<sforshee> I have a hard time believing that anything I changed could brick a machine though
<stgraber> sadly as I want it fixed ASAP, I doubt this machine will end in the hands of anyone who actually knows what they are doing, so it's very unlikely we'll ever get to see a dump of the nvram or any kind of firmware debug data...
<jsalisbury> rtg, bug 1124373 sounds like there may be an issue with the linux-firmware package in the preicse repository
<ubot2> Launchpad bug 1124373 in linux-firmware (Ubuntu) "linux-firmware unexpected EOF in archive" [Undecided,New] https://launchpad.net/bugs/1124373
<sforshee> stgraber, we can certainly disable writing the dump to nvram by disabling CONFIG_PSTORE, still not sure if there's some command-line option we can use
<jsalisbury> rtg, I'll try to confirm the issue, but just wanted to give you a heads up.
<stgraber> sforshee: it'd be unfortunate that we'd have to do that because the feature is kind of cool and useful... it sucks that we can't really check to be sure that it's indeed the problem...
<stgraber> sforshee: well, I guess we could get similar certification machines and trigger panics in a loop (with panic=1 so the machine reboots), wait a day or so and see if we get any bricked ones... :)
<sforshee> stgraber, that's an option
<rtg> jsalisbury, I just pulled from the archive and unpacked OK.
<rtg> wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.79.1_all.deb
<sforshee> stgraber, I'm pretty sure I heard some talk of tests involving filling up nvram, maybe that was wrt fwts
<jsalisbury> rtg, Thanks for confirming it's ok.  I'll follow up on the bug.  His apt db is probably corrupt.
<stgraber> sforshee: I know mjg59 wrote some tool on Windows that fills a bunch of nvram variables to trigger the samsung brick issue. I guess we could have something like that in fwts and maybe something that simulates what the kernel does on panic (if simply filling the nvram doesn't essentially do the same thing)
<rtg> jsalisbury, just added https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1124373/comments/5
<ubot2> Ubuntu bug 1124373 in linux-firmware (Ubuntu) "linux-firmware unexpected EOF in archive" [High,Triaged]
<jsalisbury> rtg, great, thanks
<ohsix> wasn't it tracked down to samsung using fake menu labels to do internal things? and when a proper user came by, it fell apart
<mjg59> No, that's unrelated
<ohsix> ok :>
<mjg59> I'd look into that, except this Samsung is dead
<ohsix> what were the nvram-y things related to?
<mjg59> The nvram-y things
<stgraber> mjg59: you don't have some Lenovo around by any chance to see if you can reproduce what happened on my laptop yesterday? ;)
<ohsix> so nothing in particular
<mjg59> stgraber: I've been running UEFI on Lenovos for about two years
<mjg59> stgraber: They're what I wrote the EFI pstore code on
<mjg59> stgraber: So I'm not immediately convinced that this is the problem
<stgraber> mjg59: ok, so hopefully it was an unrelated issue that bricked my laptop yesterday after a kernel panic (x230)
<mjg59> I'd hope so
<mjg59> I mean, it could have been a kernel panic caused by bad hardware
<mjg59> But yeah it's a concern
<mjg59> I guess I can try filling the storage on this and see if it still boots
<mjg59> I think I've got on-site...
<stgraber> I'd been using it for UEFI/SB testing since September or so (got it right after Plumbers), I had a few panics but the fatal one was yesterday after testing a brightness fix from sforshee (3.8)
<stgraber> so if it's the panic that triggered it, it must be a pretty specific bug (depending on the size of the dump or similar) and so will be a real pain to reproduce (especially as I don't have some magic way of getting the content of the nvram from the bricked unit)
<stgraber> anyway, I'm glad I paid extra for quick warranty service on this one (and that I have a Lenovo service center a block away from here)
 * rtg -> EOD
 * ogasawara lunch
#ubuntu-kernel 2013-02-14
<smb> g'morning
<smb> apw, If you wanna listen you have to take off the deafners
<apw> smb, heh indeed
<zequence> apw: precise lowlatency is ready to be pulled
<apw> zequence, again, already, sigh :)
<apw> zequence, one think you could be doing when you add the tracking bug to your changelog is changing the version number in the title of the bug, this is used by the bot which tracks things
<apw> zequence, i have changed bug #1124517 for this upload so you can see the form it expects
<ubot2> Launchpad bug 1124517 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1124517
<apw> or ... bug #1124517
<apw> oh being smart are we ubot ... th
<apw> that would be a first
<zequence> apw: Alright. I'll do that from now on then
<apw> zequence, thanks :)
<apw> oh look i can verify your tag, most excellent
 * henrix -> lunch
<rtg> ogra_, no joy on getting a graphical display to show up on my freshly installed (and fully charged) Nexus 7
<ogra_> hmpf
<rtg> ogra_, shall I go back to 12.10 and then upgrade ?
<ogra_> rtg, but you see a console or is it plain black ?
<ogra_> no
<rtg> ogra_, plain black after plymouth quits
<ogra_> 12.10 isnt upgrade safe, it was a demo and is full of hacks
 * ogra_ scratches head
<rtg> I can see the console by hitting the volume button
<rtg> until X takes over
<ogra_> i know tjaalton installed today 
<ogra_> he had issues, but with fastboot when copying the image, but X seems to have worked fine for him
<ogra_> (enough to test a bugfix for the xserver)
<rtg> As far as I can tell I had no fastboot issues
<ogra_> rtg, from whern is that image ? we had some buildd issues the last days
<rtg> ogra_, yesterday I think
<ogra_> hmm, that should be fine 
<rtg> it downloaded a giant chunk of something
<ogra_> it ?
<rtg> the GUI N7 installer
<rtg> maybe I should try it by hand from the CLI
<ogra_> ah, never used it (fastboot is so easy that i really dont need a gui to replace 3 commands)
<ogra_> i see that there was a .1 build yesterday
<rtg> ogra_, well, lemme give that a whirl.
<ogra_> not sure why 
<ogra_> try todays image too 
<rtg> yep
<ogra_> might be that you used 20130212 instead of 12.1 and there is likely a reason it was manually rebuilt (i guess by infinity)
<rtg> ogra_, this one ? http://cdimage.ubuntu.com/daily-preinstalled/current/raring-preinstalled-desktop-armhf+nexus7.img.gz
<ogra_> yeah, thats the 0213 image
<rtg> ogra_, still no joy with CLI method. I re-installed the android factory image just to be sure I didn't have a HW problem.
<ogra_> and the cli install went fine (on the PC side) ? no errors or anything ?
<rtg> yep
<ogra_> hmm
<ogra_> i dont get wht the same image worked for tjaalton without issues
<rtg> this is one of the units that I got from Canonical, via pgraner IIRC
<ogra_> *why
<rtg> did tjaalton do a complete image install ?
<ogra_> well, they only differ in MMC size (and some have 3G) 
<ogra_> so it shouldnt have any impact on the functional side
<ogra_> i think he did, yeah
<rtg> you wouldn't think it would affect the display
<ogra_> right
<ogra_> how long did you leave it with the dark screen ?
<rtg> minutes and minutes
<ogra_> oem-config can take quite a while to start up
<ogra_> yeah, shouldnt take minutes
<ogra_> well, let me wipe my device and do an install myself, we'll see 
<rtg> k
<ogra_> actually, hmm
<ogra_> rtg, you see the splash before the installer runs ? 
<ogra_> there shouldnt be any splash
 * ogra_ reboots after flashing
<rtg> ogra_, um, not sure what you mean. I see plymouth doing its thing after reboot.
<ogra_> oh, so your installl finished and you did run through oem-config 
 * ogra_ thought it dies before 
<rtg> I assume oem-config is where you get to add your login info ?
<ogasawara> rtg, ogra_ : I was seeing the same issue as rtg attempting to install the images from 20130212 and  20130213 (ie black screen after plymouth, then nothing).  I however specifically just tried the 20130212.1 and it's working here (at least I'm going through oem-config).
<ogra_> rtg, exactly
<rtg> ogra_, its not getting that far. black screen after plymouth
<ogra_> mine is still extracting the tarball here ... *twiddle*
<ogra_> rtg, right, there should be no plymouth at that point
<ogra_> lets see what mine does
<rtg> ogasawara, where did you get 20130212.1 ?
<ogasawara> rtg: http://cdimage.ubuntu.com/daily-preinstalled/20130212.1/
<ogra_> replace /current in the url 
<rtg> ogasawara, hmm, I'm pretty sure I _didn't_ get that one.
<ogra_> current always links to the last ... but we usually keep the images of the last three days 
<rtg> right, both images are within 60 seconds of being the same date
<ogra_> then most likely one of tehm is broken
<rtg> then I'll try .1
 * ogra_ sees the splash
<ogra_> and a black screen :?
<ogra_> :/
<rtg> at least I'm not special :)
 * ogra_ logs in via serial ... luckily we have that on by default
<rtg> what is the default login/passwd for serial ?
<ogra_> bah, indeed, that wont work without oem-config being run
<rtg> that was my experience
 * ogra_ gets a keyboard then
<ogra_> its a bit fiddly, but you can modify the bootimg file's kernel commandline and add break=bottom so you can chroot and add a user
<rtg> ogra_, I couldn't get a console to come up either using a keyboard and ctrl-alt-F1
<ogra_> yeah, once X is started consoles dont work ... drawback of the binary driver
<rtg> ah, bummer
<ogra_> but working from initrd works 
<ogra_> i definitely blame oem-config/ubiquity here 
<ogra_> hmm, resetting doesnt even get me to plymouth
<ogra_> oh, it does, just took a while
<ogra_> i guess ureadahead does its forst profiling
<ogra_> *first
 * ogra_ curses
<rtg> ogra_, I get the oem setup screen with 20130212.1 but can't see any input from the virtual keyboard
<rtg> ogasawara, did you have that problem ?
<ogra_> rtg, reboot, known bug
<rtg> ogra_, using the power button ?
<ogra_> its a race with compiz it seems
<ogra_> yeah
<ogasawara> rtg: I did see the same, so plugged in a usb keyboard
<ogra_> it should work after a reboot ... started to happen when the installer was switched from metacity to compiz
<rtg> ogasawara, USB keyboard didn't work either
<ogasawara> rtg: I did flip back and forth from the previous language selection page
 * rtg does some cursing himself.
<ogra_> onboard doesnt work for you on the second boot ?
<rtg> nope
<ogra_> weird
<rtg> booting again
<ogra_> seems to work for everyone else 
<rtg> I hate being special
<bjf> rtg, i had issues with the virtual kbd. took a few install retries to get it to work
<tjaalton> yeah the yesterdays image worked fine for me, background image of the setup tool was broken but otherwise fine
<rtg> ok, virtual keyboard works this time
<ogra_> great
<ogra_> i plan to track that down next week
<ogra_> though its a race, wont be easy to find 
<ogra_> i dont get hwy 0213 doesnt work at all though
 * ogra_ blames the kernel :P
<rtg> ogra_, huh, I don't think that changed :)
<ogra_> details 
<rtg> ogra_, lightgdm doesn't support the virtual keyboard at the login ?
<ogra_> rtg, its hidden in the top bar 
 * ogasawara back in 20
<rtg> ogra_, ok, found it. the icon is so dang small that I can hardly hit it with my fat 'ol finger. the first time up the keyboard contents were completely scrambled.
<ogra_> yeah, its on my todo to have it shown by default 
<ogra_> the corruption is the binary driver, all i can do here is hope for nvidia fixes
<ogra_> aha !
<ogra_> there is a /tmp/.X0-lock file in the image 
<ogra_> which prevents X from starting 
<ogra_> (on 0213)
<tjaalton> heh
<ogra_> i wonder how that got there 
<ogra_> and if it actually fixes it to remove it
 * ogra_ reboots
<ogra_> gah, doesnt help
<ogra_> hmpf
<ogra_> inbetween we have a 20130214 image
 * ogra_ downloads
<apw> rtg, i find the keyboard is shown automatically in portrait mode in lightdm but not in landscape
<rtg> apw, huh, I guess I didn't hold my head just right :)
<apw> heh
<ogra_> use mirrors
<ogra_> :)
<sforshee> stgraber, when you get your x230 fixed don't bother testing the last build I supplied. I'm working on something a little different, should be done before too much longer.
 * rtg preps raring for upload (again)
<avoine> hello, who is the person I should contact if I want to help testing the new arm multiplatform kernel?
<rtg> avoine, you'll want to talk to Paolo (ppisati), but he's out for the day.
<avoine> ok
<avoine> rtg:  thanks
<rtg> ogasawara, all uploaded
<ogasawara> rtg: ack, thanks
<rtg> sforshee, jsalisbury: need to reboot gomeisa for kernel update.
<sforshee> rtg, I'm good, I just had an idle ssh session
<apw> rtg is that done yet ?
<rtg> apw, you mean is gomeisa done rebooting ?
<apw> yeah i was building and just noted this conv.  and wondered if i was at risk or not
<apw> rtg, build will be one in about 2m
<rtg> on tangerine ?
<jcastro> hey does https://wiki.ubuntu.com/Kernel/Release/Rolling still reflect reality? I'd like to blog about the HWE stack for server users with the pending point release and I'd like to make sure my facts are straight.
<apw> on gomeisa
<rtg> apw, how do you get your stuff to run in stealth mode ? I checked to make sure nothing was running.
<apw> rtg heh, perhaps i use your account
<apw> rtg, anyhow done and off
<rtg> jcastro, check with ogasawara
<rtg> apw, gomeisa is back from reboot
<ogasawara> jcastro: otp, gimme a bit
<rtg> are you sure you were doing something ?
<apw> rtg, definatly
<jcastro> ogasawara: no worries, I'm just looking for whatever the master doc for HWE for LTS users is.
<sforshee> stgraber, new build at http://people.canonical.com/~sforshee/lp1098216/linux-3.8.0-6.12~lp1098216v201302141715/ whenever you're ready to test it (if you're not gun shy after last time)
<rtg> apw, so I use 'who', 'ps ax', and 'top' to see if anything is going on. is that sufficient ?
<apw> rtg yep, i think i started it after you checked, and it is a cross build of n7 so its 3m or something
<rtg> ok, well now I'm gonna reboot tangerine. jjohansen
<jjohansen> rtg: go ahead
<sforshee> stgraber, there's some new stuff that should help with the hotkeys. Please try it normally and also passing video.brightness_switch_enabled=1.
<ogasawara> jcastro: so I think the wiki you want is actually https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<jcastro> ogasawara: aw perfect, that's exactly what I need. 
<rtg> tangerine is back
 * rtg -> lunch
 * apw decides that having fixed his network issues he probabally has had enough
<unkle_george> So.. What's going to happen if I insmod foo.ko and foo was already built into my running kernel?
<mjg59> EEXIST
<unkle_george> oooh, ok. Good. thx
 * rtg -> EOD
#ubuntu-kernel 2013-02-15
<aPpYe> hi.  I am going through a mini cd install.  can someone point me to some documentation explaining the differences between all these selections in the kernel selection?
<alkisg> Regarding the LTS Hardware Enablement stack. (1) linux-image-generic-lts-quantal is PAE-only, and there's no "non-PAE" version available, right?
<alkisg> But (2) it's possible to install 12.04.2 and then install linux-image-generic, correct?
<alkisg> If so, my next question is, (3) what should one do to avoid xorg incompatibilities when he does that?
<alkisg> We've been shipping a customized version of the 12.04 and 12.04.1 ubuntu CDs with gnome-fallback preinstalled for 400+ Greek schools, and we're wondering how to handle the hardware enablement stack with 12.04.2...
<alkisg> Ouch, xserver-xorg-lts-quantal Replaces: xserver-xorg
<alkisg> So it's impossible to have both -pae and non-pae kernels with LTSP clients with the new stack, as they'll need different xorg versions
<alkisg> One would have to maintain 2 separate chroots for that... :-/
 * alkisg hopes that if some schools have to install the non-pae version, it'll will work with the new xorg stack...
<RAOF> alkisg: It will *probably* work; possibly with the exception of plymouth.
<alkisg> RAOF: as long as it doesn't halt the boot process, we don't mind at all
<alkisg> Thanks, /me installs the new stack to test all that...
<RAOF> We won't have tested new X stack + non-pae kernel, but upstream theoretically cares that it runs on arbitrary kernels.
<alkisg> That's nice; at least if we test + report incompatibilities, we'll stand a chance of getting them fixed
 * alkisg reboots to check
<work_alkisg> Apart from virtualbox-dkms crashing "Error! Bad return status for module build on kernel: 3.5.0-23-generic", everything else seems to work fine...
<alkisg> Ah, and our "purge old kernels" script gets confused and tries to remove "linux-image-3.2.0-37-generic" because it thinks "linux-image-3.5.0-23-generic" is a newer version of the same flavor, while it's internally -pae instead
<ppisati> moin
<smb> moin
<smb> ppisati, risen from the near-dead already? :)
<ppisati> smb: yep, i'm ok
<smb> ppisati, Thats what they all say  :)
<ppisati> smb: i bit of sore throat but i can handle it :P
<smb> apw, (no)
<henrix> apw: gbp-pq
<henrix> in git-buildpackage
<apw> apw to commit a patch you use dpkg-source --commit ... now it is in the logs
<caribou> smb: what are we up to wrt the linux-crashdump metapackage change to kdump-tools ?
<caribou> smb: both kdump-tools & makedumpfile 1.5.1 are now in Raring archives
<smb> caribou, I think in the end people wait for you to tell them all is main to apply the patch I sent (and by tell I mean on the thread in the kt-ml)
<caribou> smb: looks like a chicken & egg thing : kdump-tools will not make it to main unless a package in main depends on it
<smb> caribou, Ok, well, if that is made clear... 
<smb> apw, would you apply the change if that is made clear. Should be a quick resolution as soon as she complains
<smb> (or Tim (though he is not getting in today), or Leann)
<apw> if the resolution is that it is supportable in main (wahtever is moving), then i would happily the patch to make it happen
<caribou> apw: kdump-tools is moving. It's part of the makedumpfile source package which is already in main
<apw> smb, remind me of the patch title and i'll poke it
<smb> apw, [raring-meta] Update linux-crashdump dependencies
<apw> smb, ta
<apw> smb, is there a bug open for this issue?  i have the deeling there is?
<apw> s/d/f
<smb> apw, don think specifically... a blueprint there is .... maybe caribou has more memory
<apw> don't need one, but if there is one i would reference it in this commit
<caribou> apw: I don't think there's a bug open for it, only a blueprint as smb indicated
<apw> ack thanks
<caribou> apw: I can create one if we want to track it
<apw> no if it is not going back for SRU then we don't care
<caribou> apw: smb: I don't think we'll want to bring that into Precise
<smb> no
<apw> smb, you want this uploaded 'now' ?
<smb> apw, no strong preference... or with the next time we would do it... Though then we could be surprised by it getting stuck for a bit...
<apw> yeah i think it is safer to shove it in now when things are clean and see what happens
<apw> gives us a few days to fix it before leann is on her next rebase
 * smb nods and walks back to the kitchen
<apw> smb, ok your bits are in -release
 * smb hopes not
<henrix> infinity: hi! any news on the bugs verification?
<apw> smb, i would have thought you would have welcomed some -release
<smb> apw, not sure I really want that for my bits...
<apw> smb, blame britney she did it to you
<smb> ...
<xnox> apw: i have a fague recollection that you possibly tried "ubiquity LVM install" and it "did nothing". I just checked raring-ubuntu-desktop and it does lvm install correctly. Was there something special about your lvm test? (e.g. were you testing a flavour?!)
<xnox> s/fague/vague/
<ogra_> fague is a nice word too though
<ogra_> :)
<infinity> henrix: Not yet.  Wrong timezone for people to get sagari happy in Boston.
<henrix> infinity: ack
<smb> xnox, I think I sat in the same room when we tried. What we did was basically selecting lvm install but then trying to manually partition. And there we could not set partitions to be lvm pvs. Nor get any assemble VGs screen to show.
<smb> iirc that was normal desktop image
<xnox> smb: true, manual partitions doesn't have LVM yet. I have some code, but it would be very d-i style LVM partitiong which can be confusing.
<xnox> only automatic install can do lvm in the desktop image so far.
<smb> Yeah, so our usecase would still fail. :) Tried him to have his disk partitioned into two vgs... foolish of me. ;)
 * ppisati disappears for ~20mins
<xnox> smb: *sigh* I do have lvm on top of full disk encryption, and then later a shrunk and split that to create an unencrypted lvm vg
<xnox> (for vm/schroot/scratch partitions)
<smb> xnox, Heh, yeah. Well in the end we just went for a non-lvm root and swap partition and left another one unused for later. Beside its probably something that only people use that use the server install anyway. :)
 * xnox totally uses lvm and multi-partition and stuff
<xnox> no surprise I added ubiquity support =)
<xnox> there are requests for better mdadm support from $enterprise as well
 * ogasawara back in 20
<czajkowski> aloha - having a lot of trouble with https://launchpad.net/bugs/1011623  any idea of any work around, or an eta on it being fixed. 
<ubot2> Ubuntu bug 1011623 in linux (Ubuntu) "8086:0091 Unstable wifi connection when connect to 802.11n AP with iwlwifi driver" [Medium,Confirmed]
<bjf> sforshee, ^ this seems like a common bug for iwlwifi. i don't have any of that here right now
<sforshee> bjf, I've got some but nothing running the precise kernel. I can give it a try here in a little bit.
<sforshee> bjf, is this a regression?
<bjf> sforshee, from the bug, it doesn't seem like it. seems like this has been a problem always
<sforshee> oh, I see the comment that it's still a problem in quantal/raring
<sforshee> though in raring there was a problem that has a fix, not sure if it's trickled down to us yet though
<czajkowski> sforshee: ah good to know 
<czajkowski> I thought if I upgraded to raring it might be better
<czajkowski> but just as bad as it was on quantal 
<sforshee> bjf, czajkowski: so for a while we know that some people have had problems with 802.11n and iwlwifi, but it'
<sforshee> but it's very dependent on the particular machine and the environment
<sforshee> I've never been able to reproduce it with what I have, nor have the developers at Intel
<czajkowski> sforshee: not sure it was happening on the cisco AP router but definately happens on UniFi AP
<sforshee> czajkowski, I've been sitting next to people having problems on their machines while on my machine it's fine
<czajkowski> sforshee: yeah don't be telling me this :)
<czajkowski> causes me no end of grief when I go over to my other halfs place and spend half an hour or more trying to get on the network to do work 
<sforshee> bjf, czajkowski: the 3.8.0-6.11 raring kernel has the fix for the regression that was in 3.8
<sforshee> oh that regression was in 3.7 too
<bjf> ok, so the currently released raring kernel would have that fix
<sforshee> yeah, but that's fixing a regression from 3.7 so it doesn't help precise/quantal, and may not actually fix czajkowski's problems at all
<sforshee> it fixed problems I was seeing though
<bjf> ack
<antarus> we basically turn N off on precise
<antarus> because it works poorly
<antarus> I have an internal bug to 'figure out how to make it work, because N is awesome'
<antarus> but its pretty low priority ;p
<antarus> czajkowski: you say the quantal kernel fared no better in your case?
<sforshee> so in reality there's likely more than one issue that's causing people's problems with n
<sforshee> one aspect of the problem seems to be noisy environments though
<czajkowski> 3.8.0-6-generic #13-Ubuntu SMP Thu Feb 14 17:22:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<sforshee> we get a lot more reports of iwlwifi problems from enterprises and people at confereneces
<sforshee> *conferences
<czajkowski> is what I'm currently on 
<sforshee> okay, that should have the fix for the 3.7 regression
<czajkowski> great
<czajkowski> but I'm still havng issues
<czajkowski> so must be something else
<bjf> czajkowski, so it's all fixed, have a good day
<bjf> heh
<czajkowski> the other alternative is to get the other half to turn off N but then I've to listen to him whinge he cant use it 
<czajkowski> *sigh*
<sforshee> czajkowski, are you in an environment with lot's of people using wifi or lots of APs around?
<antarus> sforshee: well I mean people want to use N on the google bus, and let me tell you, the google bus network sucks, terribly
<czajkowski> sforshee: nope - house, only me here. nobody else 
<sforshee> okay, so maybe something related to your AP then
<czajkowski> sforshee: will look into that, but no isues on iOS or fedora just ubuntu :/
<sforshee> czajkowski, yeah, not saying the AP is at fault, just that maybe something it does exposes some iwlwifi bug or something like that
<czajkowski> nods
<czajkowski> is there any more info I could get that would help debug it ?
<czajkowski> for you guys 
<sforshee> czajkowski, so you get the same sorts of messages as the original reporter on LP#1011623?
<apw> bug #1011623
<ubot2> Launchpad bug 1011623 in linux (Ubuntu) "8086:0091 Unstable wifi connection when connect to 802.11n AP with iwlwifi driver" [Medium,Confirmed] https://launchpad.net/bugs/1011623
<apw> czajkowski, does N work for you if you rmmod/modprobe ?  until next suspend or wifi off event ?
<czajkowski> I've never seen an error message, it conects and hangs..
<czajkowski> apw: yup 
<czajkowski> exactly 
<czajkowski> once I learnt that my life was alot smoother 
<apw> czajkowski, then your issue doesn't sound liek the one in that bug to me, that sounds like it breaks in the middle
<czajkowski> :/
<sforshee> czajkowski, then please file a new bug by running 'ubuntu-bug linux' after you've been experiencing those problems and assign it to me
<czajkowski> sforshee: will do and thanks for the help folks 
<sforshee> czajkowski, probably we should focus on raring to start because it's easiest to get upstream to pay attention to the latest kernel version
<czajkowski> sforshee: lemmie go and reboot and not start wifi and see if it works
<czajkowski> knowing my luck I'll have no issues 
<sforshee> heh
<czajkowski> perfect 
<czajkowski> typical 
 * ppisati -> gym
<xnox> apw: can an overlayfs be rebased from one base image onto another, with a goal of reducing amount of space used, since content on the new base matches content in overlayfs better.
<apw> xnox, rebased by like unmounting it and mounting it over something else ?
<xnox> apw: well kind of, apart from I need to a de-dup. Eg. base-1: /blob1 base-2:/blob1.1, and overlayfs: rm /blob1; wget http://example.net/blob1.1
<xnox> apw: such that when overlay is moved from base-1 to base-2, it now should be empty and not store the copy of blob1.1 (identical and present on the new base)
<xnox> or does it do this already? via lazy compare and discard
<xnox> one may want to ignore modification/creation timestamps etc.
<apw> it does none of the things you are hoping for
<apw> xnox, ^^
 * ogasawara lunch
#ubuntu-kernel 2013-02-16
<drocsid> I would like to know where I can find the driver mentioned here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1119837
<ubot2> Ubuntu bug 1119837 in linux (Ubuntu) " Integrate the new Bitland Card Reader Driver " [Undecided,Incomplete]
<drocsid> it mentions 'staging' is there a staging repository where I may find it?
#ubuntu-kernel 2013-02-17
<sacarde> hi
<sacarde> this parameter: recovery and nomodeset ... are specific for ubuntu kernel?
<sacarde> where can I fund documentation about that ?
#ubuntu-kernel 2014-02-10
<ppisati> yo
<apw> yogeut
<ppisati> yogurt!
<apw> that indeed
<smb> May the Schwartz be with you
<apw> heh
<smb> Hm... schwarz == German for black... black --> coffee 
 * smb has a cup
<apw> tea for me
 * apw reboots to test some kernels
<apw> hmmmm, oddneess
<ppisati> bloody hdmi codec... #$@#%%^...
<ogra_> use VGA then 
<rtg> apw, have you followed this lowlatency issue in trusty at all ?
<apw> rtg, yeah am following jsalisbury's work loosly
<apw> and indeed i am running one of those on here right now, so i know its not 100% borked
<apw> i did have one bad boot, the first one, which might indicate a timeing race, instigated by the ureadahead cache
<apw> jsalisbury, it looked like your bug "turning off PREEMPT" made the world ok, but ... 
<apw> i struggle to believe it is that borken given i am up and running it now
<apw> jsalisbury, does your machine hang with it or only testers ?
 * apw found first boot was bad, i booted with debug instead of splash and it came up, and then subsequent boots seem to work
<apw> it also dies just when the framebuffer would be initialising, so i am wondering if we are seeing some of 'smb's issue in here
<apw> $ cat /proc/version_signature 
<apw> Ubuntu 3.13.0-8.27-lowlatency 3.13.2
<smb> apw, would you happen to have you udev log (to see which of the manyfold fbs your boot gets)?
<apw> smb, coming up
<smb> apw, no rush :)
<apw> smb, $ cat /proc/version_signature 
<apw> Ubuntu 3.13.0-8.27-lowlatency 3.13.2
<apw> dammit
<smb> hehehe
<apw> smb, http://paste.ubuntu.com/6909166/
<smb> ok efi-framebuffer... that should be handled by what we added to the rules...
<apw> yeah it should
 * apw goes for a couple of boots to confirm
<smb> apw, heck how many times does this cover...?
<smb> Meh forget it... browser changed to tell me that it wrapped in slightly darker gay on top of light gray
<apw> ok i've done 10 boots, 5 with pack and 5 without, onto this -lowlatency kernel (-8) and no issues
<apw> i wonder if the .2 update fixed things, jsalisbury we should get them to retest
<smb> apw, Might have been something else then. Otherwise it would be independant of the kernel more or less
<smb> (except for with or without simplefb)
<jsalisbury> apw, ack.  I'll ask for testing
<apw> jsalisbury, have you tried this thing, did it work for yo?
<jsalisbury> apw, I've been running the lowlatency kernel on a few machines and have not had any issues.
<apw> damn, so "specific" to something, arse
<jsalisbury> apw, yeah, It may be load related, but my "normal" use has not reproduced it.  
<psivaa> I am trying to findout a package that broke dialer app tests on mako and see http://pastebin.ubuntu.com/6909262/ every time the test fails. i could not find the package that's causing this. 
<apw> boot is pretty loady, but the bug is "doesn't boot" isn't it
<psivaa> do you see any clue in that?
<psivaa> apw: jsalisbury: if you could ^ :)
<jsalisbury> apw, Yeah, one bug reporter can't even boot.
<apw> jsalisbury, has that one tried to "remove quiet splash and add debug"
<apw> psivaa, nothing jumps out no, i dont recall us changing anything in the rt area, best to check if they are there in the older good tests; they may well be
<jsalisbury> apw, yea, I did ask for that, but we didn't seem to get it.  I'll request again.
<apw> jsalisbury, great, thanks.  do you have a feel for "how many" people are not working, obviously we have "two" works for us
<jsalisbury> apw, only three that I know of
<apw> zequence, have you tried booting the trusty lowlatency kernel on anything?  1) does it work we have some people who think not, and 2) does it do what it is meant to :)
<apw> jsalisbury, maybe we need to get some of our collegues to add to the testing pool
<zequence> apw: It booted for me, but haven't yet looked more closely at it
<psivaa> apw: ack, the messages rt messages are present in the logs only when the tests are failing which happen only with new images. but i'll try to find an old install to see if they are logged. thx. 
<apw> jsalisbury, ok so that is at least 3 all
<zequence> Let me do that now..
<apw> zequence, thanks
<apw> psivaa, try and get the kernle versions on those good and bad ones
<psivaa> apw: ack
<jsalisbury> apw, two of the bug reporters, state they get lockups.  One of the bug reporters is unable to boot at all.  I requested testing of 3.13.2 and ask for more info from the guy that can't boot.
<apw> jsalisbury, YATM
<smb> yet another tragic moment?
<jsalisbury> yet another terrible monkey?
<apw> you are the man
<apw> sheesh
<jsalisbury> haha
<smb> -ETOOMANYFLAS :-P
<soren> Hey peeps. I'm running Precise on some HP servers. They have a P420i controller managing a bunch of disks. When trying to configure them for our needs we ran into problems and have been in touch with HP support. When they couldn't give us useful answers themselves, they said to ask Canonical for "the right drivers".
<soren> Am I right to assume that the right drivers are whatever is shipped by default in Ubuntu?
<soren> Or are there special drivers for HP smart array controllers that I have to ask for?
<soren> Note: I'm not expecting this to be the case, but I promised to ask.
<apw> soren, classically hardware enablement has been via the lts-hwe kernels so that might be what they are meaning
<soren> You mean the backported drivers from q, r and s?
<soren> s/drivers/kernel packages/
<apw> yeah, /me asks about as well
<soren> I think what they are meaning is "we have no idea, so we're just passing the buck"
<apw> heh ... 
<soren> I wish I were being snarky.
<apw> soren, what failure modes are you seeing
<soren> apw: Not failures. We just want only a few disks to be RAIDed and the rest to be exposed as individual drivers.
<soren> *drives.
<soren> And that doesn't seem supported.
<apw> so 'hardware' raid for a few and the rest jbod, that doens't sound like something the OS would control indeed
<apw> soren, i'll see what i can find out, and let you know if i find anything exciting
<soren> Nope. The driver ignores all the ones that don't have a RAID configuration.
<soren> apw: Cool. I appreciate it.
<xnox> soren: hp, also on some servers ships with driver-injection-disk, a what appears as a usb-drive with precompiled binary kernel modules for a given ubuntu kernels
<xnox> soren: (not dkms based)
<xnox> soren: so depending what you are after, you might need those...
<soren> xnox: I guess it's possible.
<xnox> chiluk: ^ are you familiar with raid / HP + missing kernel drivers.
<xnox> soren: i didn't see HP servers personally, but chiluk might have dealt with those.
<chiluk> soren... typically you have to define a jbod array for each disk in your raid firmware.
<chiluk> otherwise the controller will reserve the disks as spares for future use.
<zequence> apw: Coudln't boot with a nvidia driver
<zequence> apw: Going to try with the free one later
<chiluk> soren it sounds like you have the correct drivers installed, as you are able to see the drives you have in a raid configuration. ... Now you just need to define a jbod for each disk you want visible to the OS, in a 1 jbod for 1 disk scheme
<soren> chiluk: Is there an actual JBOD setting? My ops guys suggested they could set up a RAID-0 for each drive and that was about it.
<chiluk> soren, most controllers have a jbod option, for expressly this purpose.
<soren> chiluk: That's great info. thanks.
<chiluk> soren... this is not a software raid card right?
<chiluk> soren... it has ram, and a controller, and possibly battery backup right?
<soren> chiluk: No, it's an HP P420i. It's pretty pricey and supposed quite good.
<soren> *supposedly
<chiluk> soren... then yeah you need to define jbods for each disk you want exposed to the OS.
<chiluk> soren... keep in mind you may want to leave one as a hot-spare in case of failure in the raid itself.
<chiluk> soren... also I don't have any explicit experience with the HP p420i, but that's how every other hardware raid device I've ever played with operates.
<chiluk> and I played with quite a few.
<chiluk> soren if that doesn't work, look into installing the linux-generic-lts-saucy package
<soren> chiluk: How do you fiddle with the config on these things? Some sort of BIOS-like thing or a userspace utility after boot?
<chiluk> soren... let me know how you fare, and more importantly if I was right... I do like being right.
<chiluk> soren... you can usually configure the drives via a bios configuration utility.
<soren> chiluk: I need to be pretty specific with my ops guys. If I just say "look for the JBOD setting in the config tool", they'll be all like "which config tool?".
<chiluk> soren...  Sometimes, if you're lucky, you can get a userspace utility.
<chiluk> soren... I almost guarantee you that there is a bios level configuration utility.. So I'd start there.
<chiluk> once your ops guys have it set up and accessible, then you can contact HP for the userspace utility.
<chiluk> soren ... most of these hardware raid cards are just rebranded LSI megaraid cards, and they have a java utility that is relatively functional...
<soren> chiluk: I'm looking at screenshots from ACU which seems like some sort of user space utility. It shows the following options: "RAID 0", "RAID 0+1", "RAID 5" and "RAID 6".
<soren> I guess with hardware raid, RAID 0 is the same as JBOD, isn't it?
<chiluk> yeah.
<chiluk> raid 0 with one drive is essentially a jbod..
<soren> With software RAID, you add a superblock and probably go through devmapper in the kernel, but that doesn't really apply with hw raid, I suppose.
<soren> Sorry, gotta run.
<soren> chiluk: Thanks for your help.
<chiluk> soren let me know how it goes.
<hvn2> Hi, I got redirected here, but not sure if anyone here can help me. I have patched, configured and cross-compiled a vanilla kernel using make-kpkg for Ubuntu12.04 xenomai/armhf/omap and on the target dpkg tells me that although it is an armhf kernel, it is not an omap kernel. Is there anything special I should do for omap ?
<pkern> apw: Where was the kexec fix for precise/lts-backport-saucy pushed to? Because I don't see an update to that branch in ubuntu-precise.git.
<rtg> pkern, it won't ripple down until mainline saucy isuploaded
<bjf> brendand, will you be testing SRU kernels this week?
<pkern> rtg: Oh I see. Thanks. :)
<brendand> bjf, yeah should be in progress now
<bjf> brendand, thanks
<brendand> bjf, i guess there is no raring -proposed kernel being published as it's EOL?
<bjf> brendand, correct, there *is* a lts-hwe-raring still though
<brendand> bjf, yep got that one
<pkern> So I guess that's what confused me. That the raring one was updated as next in the precise repo.
<zequence> apw: Wasn't able too boot on saucy, using this one PC (nvidia, if that makes a difference). Worked fine on a trusty install, another machinge
<henrix> smb: cking: re. your replies to ktml, i suppose you're suggesting i should *not* take those pstate commits. is this correct?
<bjf> infinity, do we have a release schedule that shows the Trusty point release dates?
<smb> henrix, Actually cking replied too
<smb> Basically the driver seems to be disabled
<rtg> smb, pstate is disabled by default in the Ubuntu kernel, but not upstream stable
<henrix> yeah, i understand that -- i thought only on a stable prespective. so, the saucy kernel could keep that disabled
<smb> rtg, Ah
<smb> henrix, If it is enabled upstream then I think it only improves things (though it is a kind of add support for thing which you can decide on taking or not)
<cking> indeed
<henrix> smb: cking: yep, and looking at the patch it seems to meet the usual stable requirments. that's why i had it already queued even before seeing the ktml email (it had been requested already in the stable mailing list)
<henrix> of course the request on ktml was for it to be included on S and R, which is a different story... :)
<cking> henrix, yup 
<henrix> cool, thanks
<smb> henrix, So you would be ok. For anyone using the upstream kernel they have to get things right
<smb> I mean to have the user-space side or not
<cking> with the latter, 'cos we've turned it off, if it was included in S and R it won't make a jot of difference for user's who left it off by default
<henrix> ok, got it. thanks for the clarifications.  i'll just keep it on 3.11 (and probably kamal will pick it for 3.8 as well)
<kamal> I haven't looked at the commits yet, but yes, my intention is to pick them up for 3.8-stable
<infinity> bjf: Not yet.  I can whip something up later today, after I've had an "argh, I'm sick, but also need to be at work" nap-battle with a cold this morning.
<bjf> infinity, no rush. just with the discussion of 12.04.5 and how it lines up with 14.04.x i thought it would be helpful
<hallyn> hm.  3.11 kernel on precise, kvm-in-kvm hung taking up 200% cpu.  no msgs in dmesg though.  finally killed it.  shoulda gdb'd i guess, i'll see if it happens again
<hallyn> hm, crashed at the exact same place
<hallyn> s/crashed/hung/
<hallyn> holy cow nested kvm is just b0rked
<hallyn> trusty guest works just fine.
<hallyn> smb: ^ not sure where to go with this :)  do you have any precise host you can try to reproduce on?
<bjf> jsalisbury, i pushed your quantal update
<jsalisbury> bjf, cool, thanks
<jsalisbury> bjf, It looks like Precise has the latest upstream commits, so 3.11.10.4 is next up for Saucy when it's released.
<bjf> jsalisbury, ack
<kamal> henrix, cking, smb:  correction to my statement above.  I will _not_ be applying those intel_pstate commits to 3.8-stable, because 3.8 doesn't even include the intel_pstate driver.
<apw> heh
<smb> hallyn, I probably can find something but right now still trying to figure out i386 hang (non-nested). Nested has been a bit of a mess with 3.11 though I had the feeling more when using as host. But maybe the stack of P-S-something also suffers
<hallyn> smb: that's jodh's hang?
<smb> hallyn, Hm, no I think jamespage reported that one
<hallyn> smb: ok, so should I be filing a kernel bug, or is that basically a waste of time?
<hallyn> smb: jodh showed me a bug (which i then reproduced) with i386 kvm (non-nested actually) on trusty hanging.  non-nsted -  nm, not same :)
<smb> hallyn, The i386 not even able to run anyguest reliably. The nested bug basically would be jodh 's
<hallyn> all right well maybe i'll try a trusty kernel on precise.  i do need nesting to work
<smb> The i386 seems something new with 3.12/3.13. The nested borkage seems to involve kernels between 3.9 .. 3.13 
 * hallyn shakes his head
<smb> hallyn, yeah, sforshee seemed at least unable to reporoduce with 3,13 
<hallyn> smb: do you know offhand where i'd find the best trusty backport kernel for precise?
<smb> hallyn, Optionally use an amd cpu, those had at least no nested issues... :-P
<smb> hallyn, I would just go to the archive and download the latest trusty debs...
<hallyn> oh, linux-lts-trusty in canonical-ekrnel-team
<hallyn> hm.
<hallyn> smb: heh, i can't just switch to amd, this is my fast remote box that i do all my testing on :)
<hallyn> i fear trusty kernel debs on precise will hit some precise shortcomign in postinst or something...
<hallyn> It IS NOT RECOMMENDED that you subscribe to this PPA.   <- you guys can be scary
<smb> hallyn, Too bad. :) Unfortunately upstream implemented that feature (nested page tables) in so many steps there is no real hope for a backport
<hallyn> smb: funny thing though, a trusty guest on my precise host (with saucy kernel) works just fine
<smb> hallyn, Well just don't blame us if things horribly go wrong :)
<hallyn> only saucy guest hangs
<hallyn> "I've got backups"
<apw> hallyn, hehe if you go quiet for a long time, we'll know you are availing yourself of them :)
<hallyn> surely subscribing to the ppa which will get updates would be safer than taking the debs and never getting an update, right?
<hallyn> apw: yup, my irc client is on that box too
<smb> hallyn, Apparently there is a lot of fun of how things are mixed. shadow on nested or nested on shadow or shadow on shadow ...
<hallyn> smb: oh ffs, fine, i'll test on ec2 :)
<smb> heh, sure we got different problems there ... :-P
<smb> Not even sure whether ec2 would allow accelerated nested
<hallyn> smb: oh i don't care about that.
<hallyn> i'm just tryign to get the libvirt qrt to complete.
<smb> ah...
<hallyn> but it keeps hanging the first-level kvm guest
<smb> hallyn, I probably should have a look on that
<smb> hallyn, So if you got time, file a bug and subscribe me and sforshee 
<smb> just that we won't forget
<hallyn> smb: ok
<hallyn> smb: opened bug 1278531
<ubot2> Launchpad bug 1278531 in linux (Ubuntu) "nested kvm on saucy kernel hangs" [Undecided,New] https://launchpad.net/bugs/1278531
<smb> hallyn, ok thanks. might be some variant of the known bug bug at least I would like to be sure
<apw> rtg, that cve you applied (CVE-2014-1874) did you apply it to lucid ?
<rtg> apw, I have now. ooops.
<rtg> forgot to push
<apw> rtg, heh great thanks, my ocd was whining about the orange square
<hallyn> apw: hi, any thoughts on the possibility of unprivileged overlayfs in trusty/
<apw> hallyn, i am not entirly against it, have you discussed it upstream?
<apw> hallyn, i did get an early take from security, who at least didn't throw their hands in the air
<hallyn> no, not at all.  Who would be upstream, sinc eoverlayfs is not upstream?
<hallyn> I could ping Eric for his opinion,
<apw> oh good point, hrm, i am a pint in so i'll think about your email tomororw
<hallyn> and cc: lkml just for giggles
<apw> yeah we should do that indeed
<hallyn> ok, I'll do that now so we have that info tomorrow (maybe)
<hallyn> apw: thanks, drink up :)
 * smb hopes apw _drinks_ a pint and _is_ not one
<hallyn> email sent
<ogasawara> infinity: I'm probably going crazy, but I swear I thought we had daily netboot images for trusty?  But I am failing to find them...
<ogasawara> infinity: do you have a pointer by chance?
<infinity> ogasawara: Same place as all netboot images? :)
<ogasawara> infinity: ah, I just had to hand edit then for trusty
<rtg> http://cdimage.ubuntu.com/netboot/ ? 
<infinity> ogasawara: http://cdimage.ubuntu.com/netboot/trusty/
<bjf> ogasawara, http://archive.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/current/images/netboot/
<ogasawara> infinity: yep, got it.  it wasn't listed by default
<ogasawara> thanks dudes
<infinity> Yeah, we don't add it to the parent until release, generally.
<infinity> Though, I guess I could add a section for the development release there, with big flashing lights and Geocities-style under construction GIFs.
<antarus> stgraber: hey, were you the fellow working on secureboot?
#ubuntu-kernel 2014-02-11
<ppisati> moin
<zequence> apw: I did in deed have trouble booting -lowlatency on one of my PCs. Going to try some more this evening.
<apw> zequence, ok thanks
<apw> ppisati, moin
<apw> (if you can call this un-loved hour morning)
 * smb looks amazed at the blazing brightness outside his window
<smb> apw, If it isn't morning its lunchtime already
<apw> smb, i can work with that :)
<smb> apw, Heh, it better is not. Otherwise there is another morning gone without much progress
<apw> smb, but think what a lot you can fit in in the afternoon ...
<apw> henrix, hey .. i am doing a real dirty on the kernel cve tree, so please don't push it to our output tree
<apw> henrix, you can add thnigs and push them, just ignore the output :)
<henrix> apw: ack :)
<lag> cking: So close ... :)
<cking> lag, i obviously need more coffee
<cking> normally I get it right first time :-/
<lag> cking: Submit one more time and I'll added to my -fixes branch - should be in by -rc3
<cking> lag, which mailing list do I need to send it to so I don't screw it up
<cking> is there an arm specific one?
<lag> cking: I usually do; `git show {sha1|HEAD} | ./scripts/get_maintainer.pl` and paste in the maintainers and the lists
<lag> cking: There isn't, but LKML is always a must
<cking> oh, bummer, I missed the the lkml one 'cos I can't cut n paste, doh
<lag> cking: What do you mean?
<cking> i mean I'm being stupid today
<lag> cking: :)
<cking> overly lagged
<cking> lag, btw, I'm still trying to get that Amiga video out working, I need to spend some dosh on a correct video convertor
<lag> cking: The original one, or one you've written?
<lag> cking: I had the original one working on my normal TV
<lag> cking: Is your TV digital only?
<cking> lag, I don't have a TV, so I am trying to get it to work on a bog standard monitor using nefarious tricks
<apw> henrix, ok things are back to normal, you can 'trust' the autotriager's branch again
<henrix> apw: great, thanks
<lag> cking: Ah, that'll explain it then - as long as you're having fun with it still :)
<cking> oh yeah, much appreciated to have this great bit of kit to tinker with :-)
<apw> henrix, ok ... i would like to 'break' the tracker again, are we in a safe place for that ?
<henrix> apw: yep, haven't been touching it for a while 
<apw> henrix, ta
<henrix> apw: is it safe for me to edit the cvetracker?
<apw> henrix, should be indeed
<henrix> apw: cool, thanks
<apw> i'm about to get a heap of unretires so we can do some analysis
<apw> so let me know when you are done
<apw> henrix, ^
<henrix> apw: ok, go ahead. i'm still working on a cve, so it may take a while before i push anything
<apw> henrix, :), this is likely to just explode :)
<henrix> apw: heh.  anyway, i'll ping you later when i actually need to push something
<henrix> so, feel free to explode the world :)
<apw> henrix, thanks ... it is going to be a while running i suspect
<henrix> ack
<smb> apw, bugger, so at least only backporting those changes was not sufficient to resolve the hang. next round I am adding the folding back directly to that kvm loop
<apw> smb, bah, well the little if is a good measure of the issue
<smb> yeah
<henrix> apw: just fyi, looks like i don't need to touch cvetracker afterall
<apw> henrix, handy 
 * rtg just completely messed up a linux-firmware upload
<apw> rtg, ooops, how so
<rtg> apw, forgot to re-fetch before rebasing, then force pushed.
<rtg> the archive hates me now
<apw> rtg, oh crap
<rtg> hmm, I'll get on top of it in a bit
<apw> rtg, does a git log -g origin/master (or whattever) have anything useful in it
<apw> rtg, and if you have the "commits" which it listed when you pushed on your buffer
<apw> rtg, like "XXXX...YYYY" which is said when you pushed, thne that XXXX will still be in the repo on zinc
<apw> and on zinc you cna branch   git branch FOO XXXX
<apw> and then fetch XXX and recover it
<rtg> apw, grandmother,... eggs, .... :)
<apw> habit :)
<smb> apw, Oh well, neither approach was an improvement. Actually even the first backport made it happen a lot quicker... I am pretty sure we know the kind of breakage ... just not exactly the remedy... Have to fuzz around with it more
<apw> smb, odd indeed
<apw> smb, i guess there must be an irq in there at least
<smb> apw, Yeah, trying the BUG path next
<bjf> ppisati, can you verify bug 1258174 ?
<ubot2`> Launchpad bug 1258174 in linux (Ubuntu Saucy) "wl12xx borked after one up/down cycle" [Medium,Confirmed] https://launchpad.net/bugs/1258174
<ppisati> bjf: yep
<bjf> jsalisbury, is bug 1254091 something you can verify or pester the bug reporter to do so ?
<ubot2`> Launchpad bug 1254091 in linux (Ubuntu Saucy) "intel_pstate no_turbo patch from upstream" [Medium,In progress] https://launchpad.net/bugs/1254091
<smb> apw, argh, got fooled by #define hell again. I was using preempt_fold_need_resched() in my first attempt, which looked to be exactly the if and set I wanted... Unfortunately only if CONFIG_PREEMPT is set. Otherwise its doing nothing (which may be an error that Peter still is doing). Now that I spelled it out and added a BUG_ON(preempt_count) in that loop it is actually running
<jsalisbury> bjf, I don't think I can verify, so I'll ping the bug reporter.
<bjf> jsalisbury, thanks
<jsalisbury> bjf, I just emailed him directly
<bjf> plars, the btrfs failure i see on other systems occasionally
<plars> I'm looking at https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1267469 and got 3 failures on the regression tests. I think all these line up with some known issues from the past, but if someone has an opinion on them, please let me know
<ubot2`> Launchpad bug 1267469 in Kernel SRU Workflow "linux-ti-omap4: 3.2.0-1443.62 -proposed tracker" [Medium,In progress]
<plars> bjf: maybe just a too-aggressive timeout?
<bjf> plars, the kernel-security.py issue is something the security team needs to look at. i've seen this showing up on other series and systems. i know there have been changes to that test
<bjf> plars, the 3rd one security should look at as well
<bjf> jjohansen, sbeattie ^
<rtg> bjf, doesn't this look like a test script bug ? http://kernel.ubuntu.com/testing/test-results/kili__3.13.0-8.27__2014-02-08_18-48-00/xfstests/results/xfstests.btrfs/debug/xfstests.btrfs.DEBUG.html
<rtg> I've run into the same issue when making BTRFS file systems
<bjf> rtg, yes though i thought i'd fixed that particular issue long ago
<bjf> rtg, and i don't think i see it all the time which is also odd
<rtg> hmm
<rtg> I think the failure is BTRFS specific.
<rtg> other file systems don't seem to care
<rtg> at least, that has been my experience
<bjf> rtg, it is. it's when i do the initial btrfs filesystem creation. if there is already a filessytem on the drive the mkfs wants a -f (but only for btrfs)
<rtg> bjf, why not do '-f' for all ?
<bjf> rtg, or it's that all the other mkfs tools will take a -f but btrfs doesn't
<bjf> rtg, it's a flag only mkfs.btrfs recognizes (i just looked)
<rtg> bjf, what a PITA
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC in the #ubuntu-meeting channel.
<jsalisbury> ##
<sbeattie> bjf: where's the omap4 git tree?
<bjf> sbeattie, that's in the ti-omap4 branch of the precise repo
<jsalisbury> smb, If you have a chance, can you review bug 1278531 ?  I'm not sure if it's related to the other kvm bugs you're already looking it.
<ubot2`> Launchpad bug 1278531 in linux (Ubuntu) "nested kvm on saucy kernel hangs" [Medium,Confirmed] https://launchpad.net/bugs/1278531
<jsalisbury> s/it/at/
<smb> jsalisbury, Yeah, its the bug I asked hallyn to open yesterday
<smb> It is sort of on my todo
<jsalisbury> smb, cool, thanks
<rtg> apw, did you ever get a response from #security about unprivileged overlayfs mounts ?
<apw> rtg, yeah they seemed fairly happy it would not be a problem, but reserved the right to nix it later
<rtg> apw, shall I just apply it then ?
<apw> i think serge started an upstream discussion too, i wonder what happened there
<rtg> hallyn, ^^
<bjf> rtg, i may have fixed that btrfs test issue. if you see it again let me know
<rtg> bjf, ack
<smb> apw, Bah, of course ... I was missing another fixup :/  215393bc1fab3d61a5a296838bdffce22f27ffda
<hallyn> apw: did you not get eric's reply?
<hallyn> he suggests looking through viro's reviews for ideas where overlayfs may be a security risk.  though i'd say again those will be no less valid if only root can mount it
<hallyn> but i haven't had a chance to look
<apw> hallyn, yeah, that
<hallyn> apw: which? :)  have you ever read through viro's review of overlayfs in the past?
<apw> some of them indeed, not recently
<smb> hallyn, while you are here... is there a server-team meeting today?
<smb> Nm, I think they are wondering the same on #ubuntu-server
<hallyn> smb: yeah.  i think most of the team is still recovering from capetown
<stgraber> ah good, I was just about to start nagging again about userns overlayfs but I see hallyn beat me to it ;)
<hallyn> stgraber: d'oh did i not cc: you on that email yesterday?
<stgraber> hallyn: I think you did, or Eric did, anyway I got it
<stgraber> though it doesn't really give us a clear go ahead or no way (as was expected) so we still need someone to make the call one way or another
<hallyn> some of it felt a touch patronizing, but whatever :)
<stgraber> and once that's done I can start looking at the implications for LXC
<stgraber> I'm starting to think about what to do with arkose as it's horribly broken at the moment. In an ideal world I'd have it be entirely unprivileged but I need overlayfs for that, though I may end up just canning the whole thing for 14.04 and get it out of the archive (got too much to do by release and that one is low prio)
<apw> henrix, i assume you have stopped 3.8 stable now ?
<henrix> apw: nop, 3.8 is still maintained until Aug by kamal
<bjf> ah! so we can blame kamal
<henrix> apw: 3.5 will EOL next month
<rtg> hallyn, stgraber: I'm gonna apply it for now. lets see what shakes out.
<apw> that slacker
 * ppisati stares at the number of fixes that we accumulated in S...
 * kamal ducks
<bjf> apw, so maybe it's just lagging a little
<apw> yeah, perhaps indeed
<stgraber> rtg: thanks. I'll grab the kernel as soon as it's done building (or just do a local build, depending on when I'm done with something else) and then will look at what needs to happen on the LXC side.
<stgraber> hallyn: given the above, I'll postpone beta5 until we have unsupported snapshot and ephemeral upstream, can hopefully happen later today/tomorrow.
<hallyn> stgraber: sigh, i guess i'll postponed seccomp again then
<hallyn> stgraber: but in any case i need to go track down viro's overlayfs review <cringe>
<rtg> apw, am gonna upload this so the lxc folks can mess around. do you have anything else on tap ?
<apw> rtg, nope go for it
<rtg> apw, ack
<stgraber> hallyn: in theory we just need to change the geteuid() checks in the API to only trigger when !overlayfs and !dir. start-ephemeral will be a bit more fun but I'll take care of that one (may end up rebasing on clone() in the process)
<apw> kamal, so it sounds like lts-raring might be lagging v3.8 stable ?
<kamal> so it looks to me like lts-backport-raring is quite a bit behind my 3.8-stable repo
<apw> jinx
<kamal> lts-backport-raring is at 3.8.13.14, but I've released up to 3.8.13.17   (and .18 is in -review now)
<ppisati> bjf: done
<kamal> and my 3.8-stable does contain the fix for CVE-2014-1438
<kamal> ... as of 3.8.13.15
<hallyn> stgraber: yes that sufficed for my testing that it would work :)  but i want to make sure it's done as cleanly as possible
<hallyn> rtg: thanks!
<kamal> (correction: that one was fixed in 3.8.13.16)
<kamal> similarly, CVE-2013-7263 is fixed in 3.8.13.15
<apw> arges, http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
<kamal> apw, bjf: why is lts-backport-raring so far behind?
<bjf> kamal, looking. however, remember that this cycle has dragged on and on
<apw> bjf, yeah i don't think anyone is really to blame this cycle the point release and the emergency kernels and the quick saucy respin for the point release, has just thrown a massive spanner in the works
<bjf> kamal, it will catch up in the upcoming cycle
<arges> smb:  bug 1273386
<ubot2`> Launchpad bug 1273386 in neutron "Neutron namespace metadata proxy triggers kernel crash on Ubuntu 12.04/3.2 kernel" [Critical,Triaged] https://launchpad.net/bugs/1273386
<rtg> ppisati, can you have a look at the Lucid patch on the kteam list from henrix ? My arm assembler skills are remedial at best.
 * apw likes that idea
<ppisati> rtg: i'll do
<rtg> thanks
<henrix> ppisati: sorry :)
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC in the #ubuntu-meeting channel.
<jsalisbury> ##
<ppisati> henrix: quick question - why are we backporting code for an arch that we don't support anymore for that kernel/release?
<ppisati> henrix: in L we had ealy omap code, mvl-dove (and i probably have the only board left around) and imx51, and all of them are EOL now
<henrix> ppisati: good question.  i thought we were still supporting it...
<ppisati> henrix: in P yes, in L no
<ppisati> IIRC
<ppisati> bjf: ^?
<ppisati> at least, i don't rebase anymore omap/dove for that release
<rtg> oh, does that mean I can NAK it ?
<apw> henrix, should it come out that we are not doing it you ought to be able to move that ignored (arch not present) and the triager ought to leave it alone (ought to)
<henrix> ppisati: i can see we still build armel on the ppa
<bjf> ppisati, i know we support it for P (because someone gets nasty when i mention it) but i agree that we are out of support for it in L
<apw> henrix, does that build linux-image, or does it only build linux-libc-dev
<henrix> apw: linux-image
<henrix> apw: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/5417031
<henrix> (just an example)
<apw> oh that is only versatile ... ugg
<apw> that is the board simulator ... noone is running that in production
<apw> and if they are ... please no
<rtg> apw, henrix: so I think its safe to _not_ apply that patch, right ? especially given sforshee's analysis.
<henrix> rtg: well, if we *really* don't support armel anymore, then yeah, its safe.  anyone knows where can we confirm this?
<rtg> henrix, all of the arm flavours were only supported for 18 months
<rtg> from Lucid I mean
<henrix> ack
<hallyn> apw: do you happen to know if http://lkml.org/lkml/2013/3/12/385  (v16) was the latest overlayfs requeset for inclusion?  :)
<henrix> apw: i'm pushing cvetracker with the 'ignored' on lucid
<hallyn> stgraber: http://lkml.org/lkml/2013/3/13/524   (top paragraph :
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 18th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> henrix, ack, i'll watch it to see if it does anything to it
<henrix> apw: it did, the cve is now gone :)
<apw> henrix, that means it did't switch it back at least :)
<henrix> heh, true
<hallyn> apw: of course the btrfs subvolume snapshot ioctl would seem as innocuous as an overlayfs mount :)  but i'll hold off on pursuing that :)
<apw> hallyn, no comment :)
<hallyn> stgraber: ok so it's not as ideal as i'd thought - the unpriv user canont delete existing entries
<hallyn> presumably because he can't created trusted.8 xattrs?
<hallyn> yeah  Feb 11 20:34:15 ubuntu kernel: [ 6002.515500] overlayfs: ERROR - failed to whiteout 'boot.log'
<apw> cannot create things in the upper layer, why so ?  you can put xattrs on your own files can't you ?
<apw> and they would always be in the upper layer?
<stgraber> hallyn: that could be a problem :)
<cristian_c> Hello, I've submitted a bug report (regarding a kernel bug) on launchpad almost two years ago
<cristian_c> recently, the bug status has been set to Triaged and I was told to read this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel. I've read it but I've got some doubts yet. A dev has told me to contact the kernel team for preparing a faultless upstream report
<cristian_c> the first question: 1) Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
<cristian_c> I've tested the 3.14-rc1 kernel too, what have I to do?
<cristian_c> second question: 2) While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
<jsalisbury> cristian_c, did the 3.14-rc1 kernel also exhibit the bug?
<hallyn> stgraber: yeah, now Viro does want to get rid of the xattr-based whiteouts;  i'm not sure whether that will happen and whether it would be cherrypicked into trusty at some point
<cristian_c> jsalisbury, the 3.14-rc1 has confirmed the regression, compared to other kernel tried
<hallyn> stgraber: if not, then perhaps we should drop this pursuit :(
<cristian_c> this is not the original bug anymore
<jsalisbury> cristian_c, Ok, just to confirm this is bug 972604 ?  If so, I'll review the bug and post an update.
<ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged] https://launchpad.net/bugs/972604
<jsalisbury> cristian_c, it may want to open an upstream report.
<cristian_c> jsalisbury, in the report is suggested that (opening an upstream report)
<jsalisbury> cristian_c, I think that is a good next step, since you tested the mainline kernel.
<sbeattie> bjf: in whatever script you're using to import QRT, can you record what commit revision you've grabbed, and emit it as part of the QRT run?
<cristian_c> jsalisbury, ok, and regarding the second question?
<bjf> sbeattie, yes. if you look in the tar file there is a scripts/bzr.log.  and yes, i'm aware that i screwed the pooch again on updating the tests.
<bjf> sbeattie, i'll rework my scripts so that doesn't happen again
<sbeattie> bjf: okay, thanks.
<bjf> sbeattie, very sorry
<cristian_c> jsalisbury, exactly, what have I to do, regarding the second question?
<cristian_c> ok I've seen
<cristian_c> tags:	 added: needs-bisect
<stgraber> hallyn: so speaking of overlayfs using xattr to store file removals, why can't the user do that? are they using one of the restricted attr categories?
<hallyn> stgraber: from fs/xattr.c:           * The trusted.* namespace can only be accessed by privileged users.
<hallyn> stgraber: so we would need to make that targeted (inode_capable(ionde, CAP_SYS_ADMIN)) to allow it
<hallyn> now i think that should be ok...
<zequence> apw: I'm fairly sure my problem with linux-lowlatency on trusty is a particular wifi driver. It's a d-link usb device (going to check which one). Without it, the kernel boots fine. As soon as I plug it in, the kernel freezes and I have to use the reset button to restart the computer.
<JokesOnYou77> Hi all.  I'm interested in looking at the ubuntu kernel and I was wondering if anyone here has a recommendation for the most readable kernel version (ubuntu or pure linux), best comments best flow organization, to start getting familiar with the kernel?
<zequence> apw: -generic is not having the same problem
<stgraber> hallyn: that or use the user.* namespace which doesn't come with the CAP_SYS_ADMIN restriction. Though yours would be cleaner (if there's no downside to it)
<zequence> apw: The driver is rt73usb. Going to do a bug report
<hallyn> stgraber: i think we need the cap_sys_admin restriction (targeted at least) for sanity
<hallyn> i'm not sure.  hm.
<stgraber> hallyn: well, if you're not allowed to write to the file you won't be able to set the attr, if you are allowed to write to it, then you can remove it and so probably should be allowed to write to the attr
<stgraber> or am I missing something?
<hallyn> stgraber: yes, teh point of a trusted attr is that the user cant' write it even if he owns the file
<zequence> JokesOnYou77: You mean, getting familiar with the code?
<stgraber> hallyn: right, so the problem with using user.* is that a user could manually change the attr to un-remove the file, possibly exposing data that was otherwise hidden to them by the overlay?
<JokesOnYou77> zequence, the code and the kernel itself.  I have no prior experience in kernel development so I thought I'd look at an early, simpler, version to try and get a feel for it.
<hallyn> stgraber: yeah i'm not sure.
<hallyn> I'm hoping apw has thought all this through :)
<zequence> JokesOnYou77: I don't code the kernel myself, but I would probably start with one aspect of it. Like, making your own kernel modules, or something like that.
<zequence> JokesOnYou77: Or, learning how to debug it, using the tools it has. And maybe learning how they are coded
<JokesOnYou77> zequence, ok.  I'm looking at http://kernelnewbies.org/ now, I'll take a look at your suggestions.  Thanks
<zequence> JokesOnYou77: Nice. I might have a look at that too :)
<miseria> "la esclavitud la reemplazo un pobre salario minimo, el jornalero es victima de explotacion y tirania de la oligarquia" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-02-12
<ppisati> moin moin
<apw> moin
<ppisati> i love the smell of kernel compilation in the morning...
<zequence> Smells like...
<smb> burning copper
<apw> heh ...that's a good description
<apw> smb, so what are you reproducing this on, is this your amd box ?
<apw> smb, i wonder if i should be trying to repro it on my kit, to see if there is a type of kit link
<smb> apw, One... its the dell 1521
<smb> But in bug 1268906 jodh has seen it on an i7
<ubot2`> Launchpad bug 1268906 in qemu-kvm (Ubuntu) "cpu soft lockup running kvm" [Medium,Confirmed] https://launchpad.net/bugs/1268906
<apw> ok so that is intel and amd showing it?
<apw> you should let peter know the extent of the h/w you have seen it on
<smb> apw, IF only you would read mail
<hvn2> question: if I cross-compile a patched vanilla kernel using make-kpkg, ending up with a linux-image and linux-header, and I install it using dpkg, will Ubuntu treat it as an Ubuntu kernel or does it take more to be treated as such ? 
<hvn2> my problem is that I've tried for 6 times now, and each time I get the message that it won't be written into flash
<apw> hvn2, what is the message you get
<apw> smb, i have read email, once is enough, ever
<smb> apw, Sometimes people do reply... :) So, yeah I did already let him know that
<apw> smb, and _that_ one i am not even copied on!
<jarkko_> what should i do i get multiple of these on dmesg
<jarkko_> 7659.777995] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 0 in queue 2
<jarkko_> its known issue
<smb> apw, Hm, I thought I did a reply all to his...
<hvn2> apw: the exact message is that "kernel <..> does not match your subarchitecture omap, therefore not writing it into flash." Of course I configured the kernel for omap.
<smb> apw, So no, you are not on that, but the initial email you were not either
<apw> smb, indeed and the search page on lkml does not auto update!
<apw> so ner
<smb> apw, stupid them then :)
<apw> smb, i note you are starting this with very little memory, i presume that is what is triggering the need to ipi a lot
<smb> apw, Would it not do the opposite since the host is under less pressure?
<smb> apw, Note that it is the qemu task on the host that runs into this
<smb> hvn2, what does "file <kernel file>" say about that
<apw> smb, but it is the internel need for one cputhread in the guest to wake the other that triggers the need to add the TIF_ flag in the first place, so i would guess anything which makes CPU to CPU comms in the guest more comon would tickle this issue more
<smb> apw, I don't think so. In some cases the softlockup happened even when still running isolinux or the bios which inside the guest is not SMP
<hvn2> smb, that says "Debian binary package (format 2.0)"
<smb> hvn2, That would be a deb package and not the kernel which I assume the flashing is right to refuse
<hvn2> no, on the target I did "file" on the kernel I cross-compiled
<ppisati> hvn2: so you have a .deb package, right?
<ppisati> hvn2: my guess is that, the vmlinuz file and initrd were installed successfully, you can check it looking inside /boot for those two fiels
<ppisati> *files
<ppisati> hvn2: what is failing is flash-kernel, you are hitting the same bug as this one: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/721147
<ubot2`> Launchpad bug 721147 in flash-kernel (Ubuntu Natty) "flash-kernel subarch check fails with Linaro OMAP kernels" [Undecided,Fix committed]
<ppisati> hvn2: after vmlinux and initrd are installed, there's a trigger to turn them into uImage and uInitrd files that uboot can understand
<ppisati> hvn2: problem is, every board/arch is different, is tretaed differently and thus therte's a specific piece of code that deals with it
<ppisati> hvn2: in your case when flash-kernel is invoked it doesn't understand for which arch/board your kernel was compiled for, and thus doesn't know how to handle it
<ppisati> hvn2: anyhow
<ppisati> hvn2: you just said that's a patched kernel, did you manually try to boot it?
<ppisati> hvn2: does it work?
<hvn2> ppisati: on x86 it installed and works perfectly, on this board it's given this message each time. Also, last time I tried to boot from the first attempt, it booted into the standard kernel. Since then I didn't boot since I got this message.
<ppisati> hvn2: read the lp bug that i mentioned above, you are hitting the same problem
<ppisati> hvn2: installing a kernel on an arm board it's (usually) a two step process
<ppisati> hvn2: 1) tou install it (and create initrd) in /boot
<ppisati> hvn2: 2) those files are converted in uImage/uInitrd files and copied somewhere
<ppisati> hvn2: your package installation is failing point 2
<ppisati> hvn2: because flash-kernel doesn't know how to handle your package
<hvn2> ppisati: ah ok..right now, I'm reinstalling my latest kernel version and will check on the uImage and uInitrd. Then will try to boot into it
<hvn2> ppisati: I just check /boot, and the only files that have been created from this latest install are initramfs and initrd.img. From yesterdays attempt are System.map and vmlinuz. The fat32 partition does not contain new uImage or uInitrd.
<hvn2> ppisati: So I guess I have to manually do step 2
<hvn2> ppisati: yes, that my problem is clearly according to that bug
<hvn2> ppisati: I just found this for Karmic: mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d ./vmlinuz-* ./uImage . Does this handle uInitrd as well ?
<ppisati> hvn2: as the command says, it creates only uImage
<ppisati> hvn2: if i would you, i would put some echo in flash-kernel and the reinstall an ubuntu kernel on that board
<ppisati> hvn2: this way you can see what's going on
<cking> apw, did you get my email wrt thermad
<cking> ?
<hvn2> ppisati: ok ty. I will check.
<apw> cking, yep saw it
<apw> cking, i thin you are on the money, lets get it synced over
<apw> cking, i assume we want -7 yes ?
<cking> apw, yep 
<caribou> Is our signed kernel that boots in secure mode a totally separate kernel or some thing that sits on top of the regular one ?
<apw> caribou, it is exactly the same kernel, bit for bit, with a teensy signature attached
 * caribou is just trying to confirm that our signed kernel has kexec disabled
<apw> caribou, though it exercises different code during early boot if booted signed from efi
<caribou> apw: ah, ok, hence the ./usr/lib/linux/vmlinuz-3.11.0-15-generic.efi.signature in the package
<apw> caribou, kexec is enabled
<caribou> apw: ah ok, thought it was not
<apw> caribou, it is arguable if you have module signing enforced it should be, but it is not
<apw> caribou, we did however just add the commit below
<apw> commit 70a96bd309fc4ff7d07792057cda1ad89e647388
<apw> Author: Kees Cook <keescook@chromium.org>
<apw> Date:   Thu Jan 23 15:55:59 2014 -0800
<apw>     kexec: add sysctl to disable kexec_load
<apw>     
<apw> which allows you to permenantly diable it on boot, this lets you load a crash kernle and then stop it being changed
<caribou> apw: yeah, I remember asking about this one recently
<caribou> apw: thanks for the info
<apw> henrix, about to blow the autotriager into bits again
<henrix> apw: ack
<cking> apw, i may have to do one more thermald upload as I've just been given a some patches to make it work with systemd
<apw> cking, thats fine, we can sync again, if -7 is worth having now
<cking> well -8 won't add much for us, , so -7 is fine for the mo, but I will get -8 up sometime today once I've sanity checked it
<apw> cking, ok that is sync'd, built, and pending publication
<cking> ta
<cking> apw, the next step I guess is to make it install on our kernel for x86 systems
<apw> yeah i guess we make it an install dependancy of the kernel on x86, does it make sense anywhere else ?
<cking> apw, nope, just for x86 
<apw> ok, so we will trigger a component missmatch, so we need an MIR filing for that to get considered for inclusion
<zequence> apw: So, I was able to narrow down one clue to linux-lowlatency not booting - as it seems to freeze because of at least one type of wifi driver. I was thinking of doing more testing, and thinking since the diff is so small, it should be easy to narrow it down even more. 
<zequence> apw: So, I thought to try rebuild the kernel without the threadirqs parameter
<zequence> But, maybe you guys already have an idea about what it could be?
<apw> zequence, so joe has built kernels with preempt off, and you can test the thread thing by turning it off on the command line
<zequence> apw: Right
<zequence> Ok. Will do some testing this evening
<apw> liase with jsaulisbury as he has all the kernels et
<apw> etc
<zequence> apw: Alright
<rtg> cking, have you written a main inclusion request for thermald ?
<cking> rtg, nope, how does one go about that?
<rtg> cking, um, I have to figure it out every time 'cause I don't do it that often.
<cking> https://wiki.ubuntu.com/MainInclusionProcess i guess
<rtg> cking, that looks right
<caribou> what value of /proc/meminfo would be good candidate to evaluate the memory available when booted in the kexec crash dump environment ?
<caribou> I was thinking of MemTotal & MemFree
<apw> caribou, yep, those are the ones i would start with
<caribou> apw: ok, thanks. I'm hoping to define a set of scripts that can be easily replayed. If I get good results, I'll write a blog post about it
<jsalisbury> bjf, want me to apply the 3.11.10.4 updates to Saucy master-next ?
<bjf> jsalisbury, yup, go for it
<jsalisbury> bjf, cool.  I'll push them to my git repo on zinc again and send a pointer
<jsalisbury> bjf, also, there was an update from the bug report on bug 1254091 but he didn't update the tags
<ubot2`> Launchpad bug 1254091 in linux (Ubuntu Saucy) "intel_pstate no_turbo patch from upstream" [Medium,In progress] https://launchpad.net/bugs/1254091
<hvn2> question: after installation of a custom built kernel and rebooting, the tracking data shows the kernel image has bad data crc. How can I check beforehand if this is the case ?
<jsalisbury> henrix, I was cross checking the v3.11.10.4 patches I'll be applying to Saucy with your emails for 3.11.10.4 -stable review.  
<jsalisbury> henrix, It seems this one is not in v3.11.10.4:
<jsalisbury> [PATCH 3.11 233/233] ftrace: Have function graph only trace based on global_ops filters
<jsalisbury> henrix, was that dropped?
<lag> cking: Hey Colin
<cking> lag, yup
<jsalisbury> henrix, ahh, I think this explains it: http://www.spinics.net/lists/stable/msg34983.html
<lag> cking: Just to let you know, there's been a slight change of plan
<lag> cking: As your patch turned into a code clarity patch, rather than a BUG, I'm going to push it though -next instead of -fixes
<cking> lag, ok, sure, that makes sense
<lag> cking: As your patch turned into a code clarity patch, rather than a BUG, I'm going to push it though -next instead of -fixes
<lag> Whoops, wrong window to do (up + return)
<henrix> jsalisbury: yep, it has been dropped (as you've already found out :) )
<jsalisbury> henrix, great, thanks.  Just wanted to confirm :-)
<sforshee> smb: do you know if it's possible to run xen in a kvm guest?
<smb> sforshee, not done that but with nested enabled on host ... theoretically
<sforshee> smb: just looking for a way to run xen without sacrificing a physical machine
<plars> bjf: psivaa and I are still seeing this test_010_proc_maps failures, at least on non-precise runs. Was there anything specific about the fix for that to precise?
<smb> sforshee, Its not so much sacrificing... you still can boot normally after..
<smb> I  just would fear an unknown amount of "nobody  tried that before" when trying to run inside a kvm VM
<bjf> plars, can you look in the ubuntu_qrt_kernel_security.tar.bz2 tar file and see what the latest revno reported in the bzr.log file in that tar file is?
<bjf> plars, it should be this: http://paste.ubuntu.com/6920824/
<plars> bjf: ah, that's not the results file
<plars> bjf: I was looking in the wrong thing, I don't know if I have that after the run, but I could wait for one running right now to finish and see what it has
<bjf> plars, you should be able to look in your git repo
<plars> bjf: ok, at least in our tree that seems correct
<bjf> plars, i'll add code to the tests so that shows up in the output results
<bjf> sbeattie, it sounds like CI is still seeing issues with the security test. it looks like they are now running the latest version. i'll add code to the tests so they report what version they are running
<hallyn> apw: hi, did i scare you away with the user.overlay.* idea for overlayfs? :)
<apw> hallyn, i thought you decided you could make a big mess with that, removingwhiteouts
<hallyn> apw: I don't undestand, but I think the answer is no (i didn't decide that ,that is :)
<hallyn> apw: to remove a whiteout, the user would have to find the file on the writeable layer
<jsalisbury> henrix, I noticed there may be a change missing in 3.11.10.4, which came in with patch: 
<jsalisbury> [PATCH 3.11 148/233] mmc: sdhci-pci: Fix BYT sd card getting stuck in runtime suspend
<jsalisbury> henrix: The sdhci_intel_mrst_hc1_hc2 struct is missing the addition of  .own_cd_for_runtime_pm = true,
<henrix> jsalisbury: checking...
<henrix> jsalisbury: ah, i see what you mean
<henrix> jsalisbury: so, that structure is actually on a different place in 3.11
<henrix> jsalisbury: it is defined in drivers/mmc/host/sdhci-pci.c instead of rivers/mmc/host/sdhci-pci.h
<henrix> jsalisbury: so, the change is still there, but in a different place
<henrix> jsalisbury: does this makes sense to you?
<jsalisbury> henrix, hmm, I don't see the change in that file.  
<jsalisbury> henrix, I see that you backported that struct into drivers/mmc/host/sdhci-pci.c, which I'll have to move back to drivers/mmc/host/sdhci-pci.h for Saucy, heh
<henrix> jsalisbury: you're talking about commit d097d786191a4cd882d622479a742a90605004c6 (in the stable tree), right?
<jsalisbury> henrix, I see the struct defined in drivers/mmc/host/sdhci-pci.c, but it seems to me missing the addition of own_cd_for_runtime_pm = true
<jsalisbury> static const struct sdhci_pci_fixes sdhci_intel_mrst_hc1_hc2 = {
<jsalisbury>         .quirks         = SDHCI_QUIRK_BROKEN_ADMA | SDHCI_QUIRK_NO_HISPD_BIT,
<jsalisbury>         .probe          = mrst_hc_probe,
<jsalisbury> };
<henrix> hmmm....
<jsalisbury> henrix, hmm, maybe a later commit dropped it?  
<henrix> jsalisbury: ok, so 2 sdhci_pci_fixes struct instances are modified: sdhci_intel_mfd_sd and sdhci_intel_byt_sdio. correct?
<hallyn> oh no.  is lvm in trusty supposed to be working?
<henrix> actually, sdhci_intel_mfd_sd and sdhci_intel_mfd_sdio
<henrix> gah! i'm confused :)
<jsalisbury> henrix, for that commit, should be three:
<jsalisbury> sdhci_pci_fixes, sdhci_intel_mrst_hc1_hc2 and sdhci_intel_byt_sdio
<jsalisbury> wait
<henrix> jsalisbury: sdhci_intel_mrst_hc1_hc2?
<hallyn> lvcreate/lvremove on trusty kernel on precise host is taking a long time;  acting like it is trying to dd all 50G (creating a snapshot) and not killable
<henrix> jsalisbury: i'm looking at the original commit (77a0122e0838663795651aa0beb2325156f98c09) and it this is not modified
<hallyn> looks like udev rules are causing a hang
<henrix> jsalisbury: ah, maybe you're looking at the '@@ -225,6 +225,7 @@ static const struct sdhci_pci_fixes sdhci_intel_mrst_hc1_hc2 = {' line?
<jsalisbury> henrix, sorry, let me check again. 
<hallyn> this rings a bell.
<jsalisbury> henrix, yes, I think that is what I'm doing
<jsalisbury> henrix, yeah, sorry to have caused the confusion.  I was looking at the wrong struct in the diff
<henrix> jsalisbury: uff!  :)
<hallyn> i bet slangasek remembers this...
<henrix> jsalisbury: anyway, thanks for reviewing.  these sort of mistakes have happen in the past, so...
<hallyn> maybe udev changelog will jog my memory
<jsalisbury> henrix, that commit failed when applying to saucy.  It was due to the move of structs to the header file like you say.  mainline moved some structs to the header file, your 3.11.10.4 moves them back, then Saucy moves them back out.
<jsalisbury> henrix, thanks for reviewing and helping un-cross my eyes, heh
<henrix> jsalisbury: heh.. anyway, its odd saucy has the struct in a different place. i guess a SAUCE patch (probably cherry-picked from 3.12+) has done that
<jsalisbury> henrix, yes, a SAUCE patch, cherry-picked from 3.14-rc1: 
<jsalisbury> https://lists.ubuntu.com/archives/kernel-team/2014-January/038073.html
<henrix> ah, ok.  that would explain it :)
<hallyn> hm, was transient.  will wait till it happens again to open a new bug i guess
<slangasek> hallyn: lvcreate/remove being slow doesn't ring a bell to me; there've been issues with udev rules in the past, but I think those were all resolved for precise
<hallyn> slangasek: hm, thanks.  I remember the udev rule thing having to do with watershed;  but don't recall the details or what we fixed.
<hallyn> I guess somehow I ended up having 'lvcreate' race with a udev rule for the lvm lock.  <shrug>  This is a trusty kernel on precise host, btw.
<hallyn> i'll file a bug if/when it happens again
<jsalisbury> bjf, sconklin, I finished applying the 3.11.10.4 updates to Saucy.  However, I'm getting an abi check error, when performing a test build:  
<jsalisbury> https://pastebin.canonical.com/104737/
<sconklin> looking
<bjf> jsalisbury, is there a "start new release" after the previous release and before your changes?
<jsalisbury> bjf, checking
<sconklin> yeah, what he said
<hvn2> question: how can I verify beforehand if a new uImage has a wrong crc ?
<jsalisbury> bjf, sconklin It does'nt look like there was a "Start new release".  The last one was before Ubuntu-3.11.0-17.31.  Here is the tip of the saucy tree I used:
<jsalisbury> https://pastebin.canonical.com/104739/
<sconklin> jsalisbury: right.
<bjf> jsalisbury, ok, run maint-start-new-release in that tree then rebase that down to just after the commit for the last release
<jsalisbury> sconklin, bjf, ok, got it.  Thanks!
<sconklin> That's something you didn't know to look for. There should always be a start-new-release right after a release on master-next, but you have to wait to do it until the packages are built.
<sconklin> sometimes some patches get applied to master-next in that window, and you have to go back and reorder things in master-next to 'insert' a start new release commit
<jsalisbury> sconklin, I knew to look for it when turning the crank, but not while applying stable updates
<sconklin> ack, ok
<jsalisbury> sconklin, now I know :-D
<bjf> jsalisbury, it's all about bumping the abi
<jsalisbury> bjf, abi == "aggravating binary interface"
<jsalisbury> :-)
<jsalisbury> bjf, sconklin, Hmm, do I need to do the 'start new release' before applying the stable updates?  It does'nt seem like it.
<bjf> jsalisbury, no
<jsalisbury> bjf, I'm getting an error doing the rebase.  I'll see if I can figure it out
<sconklin> hey joe, would you like for me to put the startnewrelease on and rebase that so you have a clean tree with the right ABI files to apply the upstream?
<sconklin> jsalisbury: ^^
<jsalisbury> sconklin, I don't think so.  I'll see if I can get it to work.  It will help me learn :-)  I'll ask you to do it if I can't get it to work.
<sconklin> cool, that's probably the right answer
<jsalisbury> sconklin, I'm going to grab some lunch, then start it from scratch to help memorize the steps.  I'll let you know if I get hung up.
<sconklin> ok, np
<jsalisbury> sconklin, thanks for the help!
<bjf> sbeattie, did you see the earlier comment about the security test failing still?
<sbeattie> bjf: I did not, sorry.
<bjf> sbeattie, np
<bjf> sbeattie, looks like we are now running the latest tests
<bjf> sbeattie, plars has a test run he just recently did on saucy and it failed
<sbeattie> bjf: got a pointer to the failure? I can never navigate the forest of jenkins servers you guys have
<bjf> plars, ^
<plars> sbeattie: https://jenkins.qa.ubuntu.com/job/sru_kernel-saucy-virtual_amd64-kvm-virtual/93/
<plars> sbeattie: on the plus side, it does seem to be working ok on precise
<sbeattie> plars: this looks like the same issue: either the QRT script is out of date, or else /usr/share/doc/linux-image-3.11.0-17-generic/changelog.Debian.gz doesn't contain a reference to CVE-2013-2929
<plars> sbeattie: bjf just made some changes to have it show which rev of the qrt tests its running, I need to update our copy and rerun, but given that it's pulling from the same source that our precise tests are pulling from (which now work) I think we have an updated qrt now
<sbeattie> well, it's the same failure, where a test is succeeding where it wasn't expected to, and the reason it's not expecting it to is because the kernel version is between a specific range and the test can't find that CVE number in the kernel's changelog.
<sbeattie> plars: ohhhhh. the changelog gets reset each go around. Okay, I'm just going to assume that CVE-2013-2929's been fixed everywhere.
<plars> sbeattie: I'm not sure I follow
<plars> sbeattie: this is something you are scanning for in that changelog with qrt?
<sbeattie> yes, I was changing the expectation of the test based on whether the kernel was claiming it had been fixed.
<sbeattie> I'm ripping that out now, and will expect the test to pass.
<sbeattie> plars, bjf: rev 2119 of QRT should cause things not to fail anymore.
<sbeattie> plars: the saucy kernel should not be blocked on that test-kernel-security failure, if you don't want to re-run tests.
<plars> sbeattie: ok, that's all that's failing on it so I'll mark it good then
<plars> bjf: any further thoughts on the btrfs test at https://bugs.launchpad.net/kernel-sru-workflow/regression-testing/+bug/1267469? Given that the proc maps thing is resolved and the config_debug_rodata is a known issue, I think we can mark that one good as long as you are comfortable that the btrfs test failure was just a timing thing?
<ubot2`> Launchpad bug 1267469 in Kernel SRU Workflow regression-testing "linux-ti-omap4: 3.2.0-1443.62 -proposed tracker" [Medium,In progress]
<miseria> "la verdadera felicidad de un ser humano, se logra cuando deja de ser esclavo, de la avaricia y la codicia" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-02-13
<bjf> plars, i'm fine with the btrfs failure
<ppisati> moin
<apw> moin
<smb> true
<apw> (moin_p) ?
<smb> apw, null pointer dereference ... mornings are pointless ... mwhuah
<apw> smb, hehe ... i thought you were talkling lisp at me ..
<smb> apw, not really. the only fact about lisp I know for sure is that one has to embrace many braces
<apw> perhaps enbrace to be fuly lisp
<zequence_> apw: I've confirmed that it's threadirqs that causes the freeze on both -lowlatency and -generic
<zequence_> with the driver rt73usb, at least
<zequence_> apw: So, best to remove that config for now :)
<apw> zequence, ok, we can do that for the next upload
<apw> zequence, got a bug number you are working to, which i can link the config change so we remeber to review it again and turn it back on
<zequence> apw: bug 1279081
<ubot2`> Launchpad bug 1279081 in linux (Ubuntu) "linux-lowlatency freezes when rt73usb is loaded" [High,Confirmed] https://launchpad.net/bugs/1279081
<rtg> apw, I wonder if this affects our LTS Trusty build: '[PATCH v2] compiler/gcc4: make quirk for asm_volatile_goto unconditional'
<matanya> hello, regarding https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705 the bug was introuduced in one of 95 commits i guess
<ubot2`> Launchpad bug 1276705 in linux (Ubuntu) "Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)" [High,Confirmed]
<matanya> i guess i can help sort it out, any one intersted ?
<rtg> matanya, jsalisbury can help you bisect it when he comes online
<matanya> rtg: when would that be roughly?
<rtg> matanya, in the next hour or two
<matanya> thanks rtg 
<apw> zequence, ok turned off for the next upload, you'll want to test manually tunring it on to see if the stable .3 fixes it 
<rtg> matanya, it looks like jsalisbury is already working on that bug.
<matanya> ok, great, i won't bother :)
<rtg> matanya, though it might be to your advantage to start a new bug, describe the last known working version, and provide quick turn around on test kernels.
<matanya> i'll see if i can be of a help here. thank you
<zequence> apw: Alright
<rtg> jsalisbury, prolly ought to get bug #1276705 on our top 10 until you can get it bisected.
<ubot2`> Launchpad bug 1276705 in linux (Ubuntu) "Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)" [High,Confirmed] https://launchpad.net/bugs/1276705
<jsalisbury> rtg, sure thing.  I'll add it.
<matanya> jsalisbury: do you want my help sorting that one out?
<matanya> jsalisbury: http://dpaste.com/1614107/
<jsalisbury> matanya, can you provide some details on your issue?  Do you have a bug ID?  
<matanya> the one mentioned above
<jsalisbury> matanya, ah, ok.  I have a test kernel building now.  I'm going to post it to the bug shortly.  It would be great if you could test it.
<matanya> ok, thanks
<_bt> hello, does the latest trusty kernel have this patch? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=227ae10f17a5f2fd1307b7e582b603ef7bbb7e97
<_bt> im not sure how to check
<_bt> currently, trusty daily is giving this bug our of the box on my hardware: https://bugs.freedesktop.org/show_bug.cgi?id=74927
<ubot2`> Freedesktop bug 74927 in DRM/Radeon "Screen corruption on Ubuntu 14.04, Kernel 3.13 with Radeon R7 240 (OLAND PRO)" [Normal,New]
<rtg> _bt, yup
<rtg> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=summary
<apw> rtg, ok i think i have the cloud tools cleaned up as 'cloud-tools', i've pushed that to the repos so you have have a look over it
<rtg> apw, ack
<rtg> apw, I assume you've added this to -meta ?
<_bt> hi rtg
<_bt> looks like it made it into 3.13.0-8.28
<_bt> and i am running 3.13.0-8.27
<_bt> lol
<apw> rtg, yes both linux and linux-meta
<_bt> brb
<_bt> testing
<rtg> apw, I know I'm being a complete pain in the ass, but I _hate_ that commit subject and body. This is really about splitting out "Could only" tools into a separate package. As such, I would prefer that Hyper-V get little or no mention (other then maybe a small footnote at the end).
<rtg> "Cloud Only"*
<apw> rtg, you going to fix it or you want me to?
<rtg> I'm happy to re-write it :)
<apw> rtg, feel free :)
<rtg> apw, ok, pushed. check out what I've written
<apw> rtg looks fine
<rtg> hallyn, re: bug #1279041 - what is the kernel fix to which you refer ? I can't figure out why ip_local_reserved_ports would be treated different then any other file in that /proc directory.
<ubot2`> Launchpad bug 1279041 in lxc (Ubuntu) "/proc/sys/net/ipv4/ip_local_reserved_ports not writable because of apparmor" [Medium,Confirmed] https://launchpad.net/bugs/1279041
<xnox> who is responsible for creating /dev/md directory?
<rtg> smb, ^^
<smb> I would say udev rules
<hallyn> rtg: ip_local_reserved_ports needs to be namespaced
<apw> xnox, that'd be udev everything in there is its responsibility
<apw> xnox, though likely in response to finding something to put in it
<rtg> hallyn, but then why doesn't everything else in that directory need to be name spaced in order to be visible ?
<smb> Guessing its some /dev/md? appearing
<xnox> apw: hm. what if udev couldn't have known about them at the time?
<hallyn> rtg: eh, it's kinda ugly and hard to follow
<rtg> yeah, I kinf of get that :)
<rtg> kind*
<hallyn> rtg: some things are namespced;  some are host-wide and should not be namespaced;  some are not yet namespaced
<xnox> apw: smb: in the installer - udev fires and is gone, then mdadm kernel modules are loaded, then "mdadm" pretends to find /dev/md/Volume2 which doesn't exist... =)
<xnox> let me assemble it and check what happens.
<hallyn> rtg: I've not had time to do a full survey.  I'll try to do that if I can get the overlayfs thing working (which so far I can't)
<rtg> hallyn, ok, I'll leave you to it
<apw> xnox, well ... is /dev devtmpfs in the nistaller setup?
<xnox> apw: smb: odd, so it did assemble and create /dev/md/imsm0 but /proc/mdstat is out of date it has the array but not the "container" (intel fakeraid entry)
<apw> why is udev not left running by the way
<xnox> apw: oh it is running.
<hallyn> rtg: thanks :)
<xnox> apw: but there was no mdadm nor modules loaded when the drives first appeared...
<smb> xnox, /proc should be closest to what the kernel thinks it has
<apw> right its not really sensible to say it is out of date
<apw> it is a direct representation of what is in the kernel
<xnox> apw: smb: so mdadm did start the container, but mdmon was not autostarted and /proc/mdstat is clearly missing an entry =(
<rtg> xnox, do you have an entry in /etc/mdadm/mdadm.conf ?
<xnox> rtg: ofcourse not, this is in the installer.
<smb> In theory it should not be necessary to have one but in practice it can make odd differences
<rtg> it certainly does on reboot
<smb> xnox, is that a raid5 setup?
<xnox> smb: raid1
<smb> Wondering whether it needs a md device for the container of this setup...
<apw> might that not appear in dm instead ?
<smb> But I guess you saw it when not in the installer
<xnox> smb: apw: so mdadm --auto-detect (after kernel modules were installed) and then assembling helped
<xnox> and how i have two arrays in /proc/mdstat =)
<xnox> and it went into resync.
<xnox> let's see if i can reboot and repeat everything....
<smb> rtg, In theory nowadays everything should just be assembeld by the devices appearing... I n practice I found at some point in the past at least that kernel/userspace started to have differenct options of device names in that case
<rtg> smb, yeah, which is why I always write the config to that conf file
<smb> Yeah, its the safe way... for some reason
<xnox> retoaded: /etc/mdadm/mdadm.conf if there isn't one, one is generated for the initramfs. and even if initramfs is without one, one would be generated inside initramfs and then attempt to assemble everything.
<smb> I wanted to investigate but ... *sigh*
<rtg> grumble. the apparmor userspace/kernel mismatches are annoying.
<apw> rtg, test booting your kernels on precise userspace ?
<rtg> yup
<rtg> can't start a container
<rtg> just gonna grub apparmor=0
<apw> smb, can you remember what options were bad for luks
<smb> apw, errrrrr no (I think)
<smb> apw, Bad in what way ?
<xnox> apw: xts is the good one, aes is the flaky one.
<xnox> (IV vector that is)
#ubuntu-kernel 2014-02-14
<apw> ogra_, this syslog vomit, which kernel is this
<ogra_> uh, ask jdstrand, i think it is mako
<ogra_> root@ubuntu-phablet:/# tail -1 /var/log/syslog
<ogra_> Feb 14 12:47:09 ubuntu-phablet kernel: [53723.068756] adjust_soc: ibat_ua = 0, vbat_uv = 4326558, soc = 100, batt_temp=290
<ogra_> yep, looks like mako 
<apw> you can tell it is mako from that line ?
<ogra_> seems to write that every 20sec here for me 
<ogra_> no, i can tell by following the cable that goes from my laptop to the device ;) 
<ogra_> thats actually my output above 
<apw> oh heh
<ogra_> it wrote this line 5 times since we speak (i have a tail -f running)
 * ogra_ takes a look at maguro
<apw> ogra_, so that is device specific i suspect
<ogra_> same thing on maguro
<ogra_> Feb 14 12:49:33 ubuntu-phablet kernel: [ 4449.108245] max17040 4-0036: online = 1 vcell = 3767500 soc = 29 status = 1 health = 1 temp = 250 charger status = 0
<ogra_> Feb 14 12:50:24 ubuntu-phablet kernel: [ 4499.191436] max17040 4-0036: online = 1 vcell = 3852500 soc = 29 status = 1 health = 1 temp = 260 charger status = 0
<apw> yeah but a totally different mesage
<ogra_> even on a shorter cycle 
<apw> sigh, these people are full of crap
<ogra_> as i told you :) 
 * apw does wonder why we have syslog running though on such small disks
<ogra_> android drivers ... 
<ogra_> apw, we plan to restrict it 
<apw> i assume they don't which is why they get away with it
<ogra_> currently we need it for debugging indeed
<ogra_> enduser devices will have limits set for logging 
<apw> ogra_, which is maguro, the galaxy nexus ?
<ogra_> (and logrotate throw away logs instead of keeping them compressed)
<ogra_> yeah
<apw> i thought that one was dead a buried
<ogra_> here is manta:
<ogra_> Feb 14 12:53:42 ubuntu-phablet kernel: [  488.998610] battery: l=100 v=4275 c=-123 temp=29.7 h=1 st=1 
<ogra_> same thing 
<ogra_> (N10)
<ogra_> manta does it once a minute ... less frequent than the others
<ogra_> apw, maguro will be dead and buried soon (once we default to a 4.4 base) but isnt until then
<ogra_> (not sure you need to care for it though) 
<ogra_> (i wouldnt :P )
<ogra_> my fo (N7 2013) is sadly out of battery ... but i bet it does the same too 
<ogra_> *flo
<apw> ogra_, could yu find out what the message is in that one, when it has charged :)
<apw> and i can get some bits uploaded to the ppa for these
<ogra_> yep, just charging 
<apw> ogra_, though first i'll get you a test kernel with it moved to pr_debug and make sure they don't ned up in the logs still
<ogra_> i'll add excerpts for all the devices we care about to the bug 
<apw> ogra_, thanks
<rsalveti> ogra_: apw: they are really verbose, even more when you try to suspend it
<rsalveti> which happens like a lot when you use it as a phone :-)
<ogra_> rsalveti, right, we need to get rid of that 
<rsalveti> well, I think it's expected from the kernel perspective to have such logs
<rsalveti> as it's very useful for debug
<rsalveti> we just shouldn't store them
<rsalveti> or at least put a small limit 
<ogra_> rsalveti, well, if we out a small limit in you will only see these messages in your syslog
<ogra_> i dont think we want charger status reported every 20sec 
<ogra_> (no matter if the device is on or not)
<rsalveti> well, then do you really want to patch every kernel we had to remove those messages?
<ogra_> rsalveti, in the long term we will i fear 
<ogra_> or skip kernel logging at all and rely on the ringbuffer 
<rsalveti> logs are usually a good thing (that's why android is so verbose), we just shouldn't store them
<ogra_> but that will then only have the battery/charger messages
<ogra_> yes, but that means using the rigbuffer (dmesg)
<ogra_> *ring
<rsalveti> that's fine, at least it's still useful if you're debugging
<rsalveti> if we remove the messages, it'll just be harder to debug issues
<ogra_> well, i still dont think every 20sec a battery ping is relevant to debugging 
<ogra_> i agree that ril messages might be ... but for that we have the radio logcat log ... 
<apw> ogra_, http://people.canonical.com/~apw/mako-trusty/ is that message moved to debug, be interested if that makes it not end up in the logs
<apw> rsalveti, how goes testing those yama kernels
<ogra_> apw, no mako for testing here 
<rsalveti> apw: testing all the kernels as we speak
<ogra_> (thats my main phone ... i dont do tests on it ... company needs to supply me one :P )
 * apw calls this whole thing stupid
<apw> people who have kit need to have all of the supported kit or not bother
<apw> else we are just wasting peoples time
<ogra_> rsalveti, thanks !
<ogra_> apw, well, i have flo, maguro an manta ... the mako is my private one and i dont want to have to set up calendar and my accounts multiple times a week (or have to install the click packages i use on a daily basis)
 * smb wants a sushi now
<rtg> apw, remember to upload to the c-k-t PPA per bjf request
<apw> rtg ack
<apw> rtg, fire in the hole
<rsalveti> apw: rtg: missing a new kernel release for manta
<rsalveti> after you updated the tree with the yama changes
<rsalveti> that would still be ppa-only (as it's on top of 4.4.2), but just noticed it's not there yet
<rtg> rsalveti, k, lemme figure out what happened. I think apw was doing that at the time.
<rtg> rsalveti, looks like we (likely me) didn't finish packaging and uploading. I'll git 'er done here in a bit.
<rsalveti> rtg: great, thanks
<rtg> rsalveti, linux-manta_3.4.0-5.21 uploaded to the c-k-t PPA
<rsalveti> rtg: awesome, thanks
<hallyn> apw: hi, any comments on the overlayfs unprivileged whiteout patch?  (stgraber will be poking me soon about it I'm sure :)
<chiluk> what kernel trace tool produces output like this ?
<chiluk> ip-21638 [020] .N.. 37431.042253: lg_global_unlock <-do_umount
<chiluk> ip-21638 [020] .N.. 37431.042265: lg_global_lock <-release_mounts
#ubuntu-kernel 2014-02-15
<apw> smb, ^ that is ftrace i belive
<apw> chiluk, ^
<chiluk> gracias apw
<Rapid2214> Hi, anyone available to help me with a kernel oops trace? (ocfs2_buffer_uptodate)
<apw> Rapid2214, pointer to the trace would be helpeful
<BjoernC> hiho
<apw> ?
<Rapid2214> apw http://pastebin.com/8Kex3Bvp thanks
#ubuntu-kernel 2015-02-09
<hyperair> hi. has anyone seen the 3.18 kernel hang bug?
<hyperair> the one that wedges everything and disables everything except alt+sysrq+b
 * hyperair thinks it's the same as the hpet bug
<apw> hyperair, not seen any particular mention of that no
<hyperair> damn
<hyperair> it keeps hitting me, and for some reason nobody else sees it
 * hyperair sighs
<apw> hyperair, does it happen with the v3.19 in the CKT PPA?  as that will be our kernel shortly anyhow
<hyperair> apw: dunno, i just compiled my 3.19 kernel. haven't rebooted yet
<cristian_c> hello
<cristian_c> apw, Have you read the paste?
<apw> cristian_c, i have no indication in my backscroll that you told me where it was after you said you'd do it; but i have been travelling
<cristian_c> apw, http://pastebin.com/TVmxXzUZ
<apw> cristian_c, that looks comprehensive to me
<cristian_c> ok
<cristian_c> apw, ok, also, I've to open an upstream report for a regression
<cristian_c> related to this bug
<cristian_c> in total, two reports
<cristian_c> I must collect info in kernel format for an upstream bug report
<cristian_c> the upstream bug report should be about a regression
<cristian_c> How can I locate the specific commit, exactly?
<cristian_c> Any ideas?
<apw> cristian_c, the specific commit which introduced the regression ?
<cristian_c> apw, yes
<cristian_c> correct
<cristian_c> I think they request the exact kernel version
<apw> the exact kernel version is easier, you would use the mainline builds to narrow in on it, in a bisection style
<cristian_c> apw, ok, so have I to try many kernel until I find the nearest previous version and the nearest next version?
<cristian_c> to the kernel version has introduced the regression
<apw> cristian_c, right exactly that, but you do it in divide-and-conquor manner, so
<cristian_c> ok
<apw> say you know it worked in 3.2 and not 3.16 you'd pick like 3.9 first and then you have gotten rid of half either result
<apw> cristian_c, i would use the prebuilt test kernels in the ubuntu mainline archive, so you don't have to make any
<cristian_c> 3.8.0 is not affected by the regresssion
<cristian_c> apw, can I use the prebuilt kernels even if I've to report in the upstrem?
<cristian_c> *to the
<cristian_c> to locate the regression version
<cristian_c> apw, usually I download the kernel version from mainline kernel archive
<cristian_c> http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
<cristian_c> and I always install three packages: headers, headers-generic, linux-image
<apw> cristian_c, yes, those kernels are mainline code exactly, there is no ubuntu patches on those
<cristian_c> ok, usually I install the mainline .deb packages
<cristian_c> for the prebuilt is the same , I think
<cristian_c> *prebuilt kernels
<apw> i believe we are talking about the same ones yes, those are suitible for a bisect, and for reporting exact versions to upstream
<apw> as they are unmodified upstream code, built on ubuntu for debugging
<cristian_c> apw, anyway, I've to identifying the mantainer
<cristian_c> If the bug is not in USB, the first step in reporting a bug upstream is to find the maintainer of the driver for the bug from the MAINTAINERS list. Here are some typical scenarios and suggested mailing list and procedures: 
<cristian_c> in the first case
<cristian_c> If this is a regression, CC the submitter of the regression commit. 
<cristian_c> in the second case
<cristian_c> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS
<apw> if you can find the before and after mainline commit, we can ask joe to do a proper bisect for you to get the actual commit for it
<cristian_c> I'll try
<sarnex> hi guys, i noticed the automatic DEB build of the 3.19 kernel on kernel.ubuntu.org failed, is this a known issue?
<apw> sarnex, failed how so ?
<sarnex> apw: 	BUILD.LOG.amd64 and BUILD.LOG.i386 say "Access not authroized" and there are no debs in the filder
<sarnex> apw:  see here http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/
<apw> sarnex, thanks, sorting
<sarnex> apw: awesome thanks
#ubuntu-kernel 2015-02-10
<cyphermox> apw: hey; I see you're assigned to bug 1383851 on the kernel side and you did some debugging for this already -- did you get any plymouth logs?
<ubot5> bug 1383851 in plymouth (Ubuntu) "Cannot enter LVM encryption password in qemu with -vga std" [Medium,Confirmed] https://launchpad.net/bugs/1383851
<cyphermox> I'm debugging a "similar" issue in plymouth that I fortunately get on my system; found that https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=abd69c55dd8f1f71b33b8c6165217f4329db8f25 might help since plymouth reports it gets some values as 0 from the libdrm when they really shouldn't be at 0
<cyphermox> I'm building a kernel with that commit right now to see whether it helps
<apw> cyphermox, iirc the issue i was seeing was that plymouth was deciding the console was not a human one, so it did not need to connect the keyboard part to it
<apw> cyphermox, so it was working but it was sure noone was out there to talk to
<cyphermox> well, I'll no soon, running a new install with VGA and crypto right now
<apw> great.  thanks
<cyphermox> well, it just worked
<apw> working is good ...
<ogra_> ... vacation is better
<apw> ogra_, arf :)
<ogra_> :)
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<davmor2> ogra_: I don't know I'm glad to be back at work for the rest ;)
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<apw> o/
<ppisati> o\ <- scratching my head
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 17th, 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-02-11
<tseliot> apw: I'm uploading nvidia 340 and 346 (and their -updates flavours). They all have patches to support linux 3.19 but they will need somebody to approve them when they end up in NEW
<cristian_c> tseliot, apw I've found the regression commit
<cristian_c> a strange thing happens
<cristian_c> 3.13.0rc1 is not affected from regression
<cristian_c> 3.13.0rc2 breaks all
<cristian_c> wifi button is not working anymore
<cristian_c> and strange events happen
<cristian_c> same situation with 3.13.0rc3
<cristian_c> in 3.13.0rc5 the regression appears
<cristian_c> tseliot, apw I've looked at the CHANGES files
<cristian_c> and i've found:
<cristian_c>       hp-wmi: detect "2009 BIOS or later" flag by WMI 0x0d for wireless cmd
<cristian_c> for rc2
<cristian_c> and:
<cristian_c>       drivers: phy: Fix memory leak
<cristian_c> for rc5
<tseliot> cristian_c: sorry but I'm not a kernel engineer. You definitely want somebody from the kernel team
<cristian_c> tseliot, can I ask info for the report, anyway?
<cristian_c> I've to report to kernel mantainers
<brightkn1> Gardener around
<brightkn1> ?
<apw> jsalisbury, ^^ that looks like somethign we could do a bisect for to confirm the commit at issue in 3.13-rc5
<apw> brightknight314, as in Tim ?  he likely is not
<cristian_c> apw, I've found the regression commit, anyway
<cristian_c> :)
<cristian_c> trying various mainline kernels
<apw> How do you know it is the ones you have picked out ?
<brightknight314> Yes Tim.
<brightknight314> apw: the update server is broke, secure this machine.
<cristian_c> apw, I've not understood very well (I don't know if you are talking with me)
<brightknight314> I don't like when remote admins abandon work.
<brightknight314> Leave a bunch of sockets hanging open.
<apw> cristian_c, you say you tested -rc4 and -rc5 and then jump to a specific commit as at issue in that range, and i am wondering why that one is the one you picked
<brightknight314> Leaves a bunch of sockets hanging open.
<brightknight314> apw: ssh in and install the updates
<apw> brightknight314, ok Tim isn't likely to be about
<cristian_c> apw, rc4 is not present in mainline (rc4 contains only the alldeb package)
<brightknight314> The machine admin bailed.
<cristian_c> apw, anyway the commit is an hypothesis
<brightknight314> apw: Why is Tim unlikely to be about?
<cristian_c> apw, for commit, I mean the COMMIT file
<cristian_c> :)
<cristian_c> apw, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc2-trusty/COMMIT
<apw> cristian_c, right ... and jsalisbury is a wizard at doing bisects to a specific change in the range, and can help do the last bit for you
<cristian_c> apw, ok
<tjaalton> sigh, 3.18 is quite eager on disk cache.. 10GB used for it and apps failing because of OOM
<apw> tjaalton, try v3.19 in the CKT PPA
<tjaalton> yeah I've got it installed, just need to reboot.. hope it helps
<apw> brightknight314, he just isn't likely to be here at the moment
<apw> brightknight314, and i don't think other than that i understand your question
<brightknight314> Does apw do kernel hacking?
<apw> many of the people here are experience in kernel topics
<brightknight314> plug in
<brightknight314> apw: hurry up
<jsalisbury> apw, cristian_c I'd be happy to help with a bisect
<cristian_c> jsalisbury, ok
<jsalisbury> cristian_c, is there a bug open ?
<cristian_c> jsalisbury, on launchpad, yes
<cristian_c> jsalisbury, but today I've found the kernel version that breaks all
<cristian_c> and the beginning version of the regression
<apw> cristian_c, it just makes jsalisbury life easier if he has the lp# to work against, keeps them straight when doing mroe than one
<cristian_c> but I've to do tow reports
<jsalisbury> cristian_c, great.  The bug is helpful to keep track of where we are in the bisect.
<cristian_c> one for the original bug and one for the regression
<cristian_c> ok, I post the lp url
<jsalisbury> cristian_c, ok, I've probably already commented on it, but don't remember :-)
<brightknight314> apw: plug in
<cristian_c> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
<ubot5> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
<cristian_c> jsalisbury, but I've to report upstream
<cristian_c> jsalisbury, I've already prepared the information collected in kernel.org format, for the original bug
<jsalisbury> cristian_c, ok.  if you can post the last kernel version that did not have the bug, and the first that does, I can start a bisect
<jsalisbury> cristian_c, a bisect will tell us the exact commit that is causing it
<cristian_c> and today I've found the kernel beginning with the regression
<jsalisbury> cristian_c, and it's usually good to test the lastest mainline kernel, just to see if the bug was already fixed.  Then we can find the commit that fixes it
<cristian_c> jsalisbury, the original bug has always been
<cristian_c> jsalisbury, no, the original bug has never not been fixed
<cristian_c> original bug exists from many years
<jsalisbury> cristian_c, ok, but you now know that last 'good' kernel and the first 'bad' one?
<cristian_c> jsalisbury, for the original bug doesn't exist a last good
<cristian_c> jsalisbury, for the regression I can say it
<cristian_c> 3.13.0rc1 not affected
<cristian_c> 3.13.0rc5 affected
<cristian_c> 3.13.rc2 and 3.13rc3 broken
<cristian_c> *3.13.0rc5 and further
<cristian_c> *3.13.0rc1 and previous
<jsalisbury> cristian_c, broken, meaning they have the bug too, or they have another bug and you can't test them?
<cristian_c> jsalisbury, today, I've found that rc2 and rc3 have strange behavours
<cristian_c> the wifi connection doesn't work anymore if I press the wifi button
<cristian_c> but this issue is limited to these two releases
<jsalisbury> cristian_c, are you able to tell if rc2 and rc3 exhibit bug 972604 ?  Where the wireless led does not switch colors ?
<ubot5> bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged] https://launchpad.net/bugs/972604
<cristian_c> 3.13..0rc1 and previous are affected from the original bug
<cristian_c> 3.13.0rc5 and further are affected from original bug + regression
<cristian_c> jsalisbury, rc2 and rc3 are unusable for this test
<cristian_c> because they break other things
<jsalisbury> cristian_c, do you have a bug number for the 'original' bug ?
<cristian_c> as the wifi connection itslef
<cristian_c> *itself
<cristian_c> jsalisbury, I've reported both in that launchpad report
<cristian_c> jsalisbury, regression is reported in the #21 comment
<cristian_c> at the same page
<cristian_c> jsalisbury, that launchpad report was created for the original bug
<cristian_c> while I was testing the new kernels, I've found the regression
<cristian_c> comment #21
<jsalisbury> cristian_c, ok, so you are seeing a new regression as of 3.13.0-031300rc5, but it sounds like this version is also exhibiting the 'original' bug ?
<cristian_c> yes
<cristian_c> exactly
<cristian_c> so, I was told to open two upstream reports
<cristian_c> instead only one
<cristian_c> one for the original, the other for the regression
<jsalisbury> cristian_c, and version 3.13.0rc1 also has the 'original' bug?  
<cristian_c> yes
<cristian_c> jsalisbury, all the kernel versions are affected by the original bug
<cristian_c> I' tried also 2.6.x
<cristian_c> for test
<jsalisbury> cristian_c, ok, so it sounds like we would not be able to bisect, since the original bug always happened.  Can you give this kernel a test:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/
<cristian_c> jsalisbury, comment #6
<cristian_c> *26
<cristian_c> jsalisbury, I've tried the 3.19 rc6
<cristian_c> and I've collected the information in kernel format for 3.19 rc6
<cristian_c> as described in the ubuntu wiki page
<jsalisbury> cristian_c, ahh, ok and that was to report the bug upstream?
<cristian_c> jsalisbury, I was told to report the bug upstream
<cristian_c> jsalisbury, but I've to execute the step 2
<cristian_c> Second step: E-mail the maintainer mailinglist with Kernel.org format
<cristian_c> jsalisbury, I've to find the maintainer mailing list for the original bug
<cristian_c> Not graphics card driver bug
<apw> cristian_c, it would be helpful to know exactly which fix broke things for you, which is what a bisect will do
<jsalisbury> cristian_c, you have not been able to find the maintainers email address ?
<cristian_c> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS
<cristian_c> apw, ah, ok
<apw> cristian_c, as the maintainer will change depending on wherre the fix was
<cristian_c> jsalisbury, apw I'd be happy to know how to do it
<cristian_c> apw, ok
<cristian_c> apw, so, i've to find the fix
<cristian_c> for the regression
<jsalisbury> cristian_c, ok, I think we can bisect for the 'second' issue
<cristian_c> apw, but for the origjnal bug, what have I to do?
<jsalisbury> cristian_c, the 'original' bug will be difficult to track down, since we don't know when it started(It sounds like it always existed).  But bisecting the second issue, might tell us which files were changed that caused the regression.  That will then tell us who the maintainer is
<cristian_c> apw, for the regression, I've found some interesting lines in CHANGES files (rc2 and rc5) but they are hypothesis
<cristian_c> jsalisbury, ok
<cristian_c> jsalisbury, for the original bug, I think it always existed too
<jsalisbury> cristian_c, Can you test the 3.19 'final' kernel to see if the second issue still happens:
<jsalisbury> cristian_c, it is available here:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/
<cristian_c> jsalisbury, ok, I test it, anyway it will surely happen :P
<jsalisbury> cristian_c, if it does still happen, we can bisect the earlier 3.13 kernels.  If it is fixed, we can then "Reverse" bisect to find what fixes it.
<cristian_c> I download it immediately
<jsalisbury> cristian_c, great thanks.  If it still has the bug, I'll start a bisect and build some test kernels
<cristian_c> ok
<brightknight314> When is Tim around?
<jsalisbury> cristian_c, we can focus on the second issue, which is a regression.  Finding what commit caused the second regression, may provide some insights into the original issue.
<cristian_c> jsalisbury, probably the regression is a fix for the rc2 and rc3 issues
<brightknight314> Is Tim around?
<apw> brightknight314, there is no likelyhood of tim being around
<brightknight314> Did Tim pass on?
<apw> brightknight314, waiting for him is not going to be a profitable use of your time, if you have a question then ask it
<cristian_c> jsalisbury, ok, download is finished, now I install the three packages
<jsalisbury> cristian_c, great.  you should only need this one: 
<jsalisbury> linux-image-3.19.0-031900-generic_3.19.0-031900.201502091451_amd64.deb
<jsalisbury> cristian_c, oh, what you have 32 bit
<jsalisbury> cristian_c, this one then:
<jsalisbury> 	linux-image-3.19.0-031900-generic_3.19.0-031900.201502091451_i386.deb
<cristian_c> jsalisbury, mmm, I'm installing also the headers
<cristian_c> jsalisbury, ok, installed, I'm rebooting
<cristian_c> now, I test the regression
<cristian_c> jsalisbury, 3.19 stable similar issues as 3.13rc2 and 3.13rc3
<cristian_c> I try to reboot in a previous version
<jsalisbury> cristian_c, ok, thanks for testing.  Similar issues, meaning it has the regression, or other problems that cause you not to be able to tell?
<cristian_c> jsalisbury, I'm trying again the last kernels installed
<jsalisbury> cristian_c, ok
<cristian_c> JanC, I can tell more
<brightknight314> apw: When was Tim last seen?
<cristian_c> jsalisbury, I can tell more: I notice that in 3.19rc6 and 3.19 stable now, and also in 3.13.0rc2 and rc3, I see in rfkill list the lack of hp-wifi interface
<cristian_c> jsalisbury, but there is only phy0
<cristian_c> jsalisbury, if for example immeditely after login I type: dmesg | tail in a terminal, I get a (back)trace
<cristian_c> simlar to a crash/kernel panic / etc...
<cristian_c> now, i try again with 3.19 stable
<jsalisbury> cristian_c, and 3.13-rc1 does not exhibit this?
<cristian_c> jsalisbury, 3.13.0rc2 and 3.13.0rc3 have also only phy0 in rfkill list output
<cristian_c> jsalisbury, I know that rc1 has got phy0 and hp-wifi interfaces, but I boot now in rc1 also
<jsalisbury> cristian_c, great, we may now be getting somewhere :-)
<cristian_c> jsalisbury, ok, tried now, 3.19 the same as 3.19rc6, trace with ioctl  lines
<cristian_c> and phy0 only
<cristian_c> now, I try again with 3.13.0rc1
<jsalisbury> great
<cristian_c> jsalisbury, ok, 3.13.rc1 tried now
<cristian_c> jsalisbury, dmesg | tail does not show trace
<cristian_c> and there are both hp-wifi and phy0 interfaces in rfkill list output
<jsalisbury> cristian_c, great, so I think we should bisect between 3.13-rc1 and 3.13-rc2.  I'll start the bisect and build the first test kernel.
<cristian_c> jsalisbury, now, I test again the original bug and the regression in rc1
<cristian_c> jsalisbury, ok
<cristian_c> jsalisbury, ok, 3.13.0rc1 original bug only, no regressions
<cristian_c> now I try again 3.13.0rc5
<jsalisbury> cristian_c, ok.  I started a bisect and I have the first test kernel building.  We'll have to test about 7 kernels to get to the commit that caused the regression.  
<jsalisbury> cristian_c, the steps will be:
<jsalisbury> 1. Test first kernel.
<jsalisbury> 2. Feed test result back into the bisect(Whether it has the regression or not).
<jsalisbury> 3. Build the next test kernel.
<jsalisbury> 4. Test again.
<jsalisbury> 5. Feed result back into bisect again.
<jsalisbury> etc
<jsalisbury> cristian_c, I'll update the bug with each test result, and a link to the current test kernel.
<cristian_c> uhm
<cristian_c> jsalisbury, ok, I've tried now with 3.13.0rc5
<cristian_c> jsalisbury, hpwifi interface not present in rfkill list output, but no trace in dmesg | tail
<cristian_c> jsalisbury, original bug exists and also regression exists, as expected
<cristian_c> jsalisbury, anyway, about your steps:
<cristian_c> jsalisbury, 'd like to know exactly how to execute these steps
<cristian_c> :)
<jsalisbury> cristian_c, basically, I'll build a test kernel and post a link where it can be downloaded from.  You can download it and test to see if it has the regression / and is missing hpwifi.  Then let me know the test results and I'll build the next kernel.
<jsalisbury> cristian_c, and repeat this for about 7 test kernels.  In the end, we should know the exact commit that caused the regression.  Then decide what to do based on what the commit does.
<jsalisbury> cristian_c, ok, I finished building the first test kernel and posted a link to it in the bug report.
<cristian_c> jsalisbury, ok, i've understood
<cristian_c> jsalisbury, ok
<cristian_c> I've found the comment
<cristian_c> I download the test kernel, now
<jsalisbury> ok
<cristian_c> I'm downloading, I think I can test it immediately
<cristian_c> jsalisbury, i'm installing that , but you've told 'Feed test result back into the bisect'
<cristian_c> = let you know the results
<jsalisbury> cristian_c, correct.  I'll tell the bisect the results, and it will tell me which kernel to build next.
<cristian_c> ok
<cristian_c> jsalisbury, I don't know if I can tell the results here
<cristian_c> I've tried the first kernel: similar behaviout as 3.13.0rc2
<cristian_c> only phy0 in rfkill list, no trace in dmesg | tail
<cristian_c> original bug + regression
<cristian_c> jsalisbury, but, as in rc2, no signs in network manager applet or rfkill list if I press the switch button
<jsalisbury> cristian_c, ok, I would say that one is bad, since only phy0 is listed.  I'll build the next kernel.
<cristian_c> jsalisbury, ok, one question: have I to report the next results in launchpad?
<cristian_c> *the bug page
<jsalisbury> cristian_c, It would be helpful, so we can keep track of which kernels were good and which ones were bad.  That's where I'll post the next test kernels too, so if one of us is not on IRC we can continue progress.
<cristian_c> jsalisbury, ok, I'll expect the next kernel, and then I'll post the results on that launchpad page
<cristian_c> jsalisbury, thanks for the the spent time
<jsalisbury> cristian_c, no problem.  thanks for your help too
<cristian_c> I'm learning
<jsalisbury> cristian_c, and doing quite well at it :-)
<cristian_c> in future, it will more simple for me
<cristian_c> ok, thanks again
 * jdstrand hugs arges (bug 1292234)
<ubot5> bug 1292234 in linux (Ubuntu) "qcow2 image corruption on non-extent filesystems (ext3)" [High,Fix released] https://launchpad.net/bugs/1292234
<arges> jdstrand: that was a fun bug. : )
<jdstrand> heh, yeah :)
<w-flo> hi, are there regular android goldfish -> ubuntu goldfish kernel syncs / rebases? I hit a kernel panic in the ubuntu emulator that is probably fixed upstream
<w-flo> If anyone reads my question and wants to answer, I'll read the irclogs.ubuntu.com tomorrow, but you can also comment on my bug report at bug 1420366
<ubot5> bug 1420366 in linux-goldfish (Ubuntu) "kernel null pointer dereference after setsockopt(â¦IP_ADD_MEMBERSHIPâ¦)" [Undecided,New] https://launchpad.net/bugs/1420366
<mdeck> I'm having a problem installing kernel 3.18.7 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.7-vivid/
<mdeck> reading files list for package 'linux-headers-3.18.3-031803': Input/output error
<mdeck> not sure if it's something on my end or in the package
<tmpRAOF> mdeck: Likely your end.
<mdeck> alrighty i'll start with a reboot and go from there.
<mdeck> reboot did the trick.  weirdness. thanks.
#ubuntu-kernel 2015-02-12
<infinity> zequence: http://launchpad.net/bugs/1420562 <-- It's that time again.
<ubot5> Launchpad bug 1420562 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<zequence> infinity: Ah, time to bring out the git then.
<Free99> Hey all, I think your experimental kernel is crashing on resume from sleep but at random
<Free99> 3.19.0-rc7-generic on a 14.04 system
<cyphermox> jsalisbury: apw: hey; I've updated bug 1359689; seems like it could be a drm bug in the kernel rather than an issue with plymouth -- if I use 3.19 rc1, things appear to work properly.
<ubot5> bug 1359689 in plymouth (Ubuntu) "cryptsetup password prompt not shown" [Critical,Triaged] https://launchpad.net/bugs/1359689
<tjaalton> oh goodie, 3.19 doesn't take all my ram as disk cache like 3.18 did
<jsalisbury> cyphermox, thanks for the update.  We may be able to do a "Reverse" bisect to find the commit that fixes this.
<jsalisbury> cyphermox, ahh, I see you already found a commit that should help.  I'll build a test kernel with that commit and ask others affected to test.
<hallyn> apw: hey.  not sure whether you have time to care... cpuset.cpus works fine in vivid.  but in the mainline kernel builds it does not
<hallyn> upstream introduced cpuset.effective_cpus, whose calculation appears to be bogus
<hallyn> so that when you set cpuset.cpus to 1 , it doesn't confine you to cpu 1, as evidenced among other ways by 'grep -i cpu /proc/self/status'
<hallyn> (i can try taking it to lkml, but wasn't sure if this was something you'd be interested in)
<cyphermox> jsalisbury: I mentioned the commit because I tried to build my own kernel with it, but there's more required than just that commit
<cyphermox> looks like there may be other things from drm-next than landed along with it for the atomic thing
<jsalisbury> cyphermox, ok, thanks.  I'll do some research.
#ubuntu-kernel 2015-02-13
<hallyn> sforshee: is there some ppa particularly suited to building a mainline kernel with http://lkml.org/lkml/2015/2/12/735 added in?  Or is it better to just build by hand?
 * hallyn starts a build
<tjaalton> meh, looks like 3.19 takes disk cache just as much as 3.18 and doesn't free it. wonder if it has anything to do with btrfs
<tjaalton> it doesn't go below 9GB after some uptime
<apw> does drop_caches free it
<tjaalton> nope
<JEEBsv> has anyone else noticed that since 14.10 (3.16) bootableness with 1st gen macbooks has gone way down?
<JEEBsv> as far as I can see I get http://up-cat.net/p/ab549095 every time I successfully am able to get booted, and I guess that is happening during the failures, too
<JEEBsv> as I test the mainline builds as well, 3.18 series is similar, and 3.19 I haven't gotten to boot at all
<JEEBsv> in order to make sure it's not just a fluke with my hardware, if anyone else has a 1st gen (2006) intel macbook, I'd be happy to hear results...
<JEEBsv> I only have one of these things, so I can't exactly do such testing :/
#ubuntu-kernel 2016-02-16
<sobczyk> hi does the efistub loader verify initrd image too?
<apw> sobczyk, the initrd is not signed, any more than the root disk is
<ogra_> and with the concept of regulary rebuilding it on upgrades signing it with a secure archive key is somewhat impossible 
<sobczyk> ogra_: I want to swap all uefi keys for mine and use luks with TPM
<sobczyk> so allwing for unsecure initrd is a risk
<ogra_> well, happy scripting then :) 
<sobczyk> scripting is easi, if you know where to look, I don't know if to use efistub or grub-efi
<ogra_> i guess you want a hook or something in hook-functions then
<ogra_> (not sure though, they might run to early, perhaps you actually need to hack update-initramfs itself)
<sobczyk> ogra_: that's what I'll probably do, I'll need to modify more of the system anyway
<sobczyk> but first I need to know if noone modified the initrd
<ogra_> check /var/lib/initramfs-tools/ ... there are md5 sums 
<apw> sobczyk, that doesn't really work, you need to know noone has modified any of the tools in the initrd
<apw> sobczyk, which we do often when we sru a component package
<sobczyk> apw: uefi checks grub, grub checks kernel and initrd, but I'll need to check if it's doable
<sobczyk> apw: another approach is to merge initrd into kernel, and sign that binary
<apw> sobczyk, i presume you will need to somehow sign the initrd, right either making your own kernle with it included, or simply signing the initrd and checking that in the grub loader
<sobczyk> but I don't know if it's possible with precompiled binary vmlinux, or requires custom compiled kernel
<apw> sobczyk, but ... you need to be able to rebuild the initrd from the tools on the system, and validating those, is hard at best
<apw> sobczyk, to build it into the kernel you need to rebuild it from scratch
<sobczyk> apw: the root image will be prebuild, and non-modifiable, so it's not an issue
<apw> sobczyk, then i'd say just sign the initrd in there, and work out how to verify it in grub2
<apw> as that can check the kernel against the kek, i assume if you have your own key in the kek, you are golden
<sobczyk> apw: yes, that seems to be the easiest approach, I just need to read grub docs how to check other files than the kernel
<apw> sobczyk, though if the disk is verifyably read-only i am not sure i know why you care to
<sobczyk> it'll be luks encrypted with keys in TPM
<sobczyk> I need to be sure noone can boot unverified software to extract the keys
<apw> so presumably that also means you need to verify the grub configuration somehow too
<apw> as that and the kernel et al are (i assume) in an unecrypted /boot somewhere
<sobczyk> grub can embed config file
<apw> embed it it what though ?
<sobczyk> apw: "grub-mkimage -c" so the initial config can check all other files
<sobczyk> I'm guessing though, I've never modified grub to such an extent
<apw> sobczyk, oh i see, embed the entire config and sign the whole, ok
<lamont> jsalisbury: if it makes life easier, you can remind me of the process (script) for building arbitrary kernels (which I'd like to know the current state of anyway), and I can just run with the bisect here and save you the pain
<jsalisbury> lamont, there is a wiki, but I can start building you more kernels today:
<jsalisbury> https://wiki.ubuntu.com/Kernel/KernelBisection
<jsalisbury> lamont, the next kernel should be ready in about 20 minutes
<lamont> jsalisbury: cool. https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel would be the actual challenge I was facing... I suspect I'll let you keep building them, since my build time would be closer to 45-60 min per kernel, and I expect that we both have other commitments this evening anyway
<lamont> jsalisbury: pls holler when it's ready for me
<jsalisbury> lamont, Posted next test kernel in bug report.
<lamont> \o/
<mjg59> sobczyk: Measure the TPM and you don't have to worry about signing it
<mjg59> The EFI stub loader doesn't support that, though
<mjg59> (and nor does upstream grub)
#ubuntu-kernel 2016-02-17
<tseliot> apw, rtg: hey, which branch shall I use to have code included in 16.04? master-next?
<apw> tseliot, you should base pull-requests on master-next yes
<tseliot> apw: ok, thanks
<apw> tseliot, i don't suppose i want to know what this vomit it, but if it is what i expect then we'll want a bug for it please to tie the gazillion commits together
<tseliot> apw: it's all (upstreamed) open source code for amdgpu, and yes, I can file a bug report about it
<apw> tseliot, that'd be lovely, put the buglink in all the commits please too,
<tseliot> apw: sure
<manjo> rtg, apw looks like the patches to support http://is.gd/0GhbMU are in 4.1/4.2 any idea if we have this feature in xenial ? 
<apw> manjo, i have not, i'd refer you to slangasek or whoever is working it
<manjo> yeah 
<manjo> I will check with slangasek 
<niluje> is there a way to set isolcpus without rebooting and change the cmdline?
<niluje> I need to exclude several cores from the scheduler
<apw> it depends what that actually does, does it unplug them or just ignore them
<niluje> apw: was that for me?
<apw> niluje, yes
<niluje> I want to ignore them
<niluje> I have a DPDK application that calls setaffinity to use four cores
<niluje> I dont want something else to run on these cores
<apw> niluje, anyhow the only thing that appears to update that is the early kernel parmeter, so i suspect not
<niluje> :(
<niluje> thanks a lot apw 
<hallyn> apw: sforshee; so cgroup namespaces are now in linux-next.  Do I nee dto do anything to request them going into xenial kernel?  (I assume so...)  just an email to ubuntu kernel list?
<apw> hallyn and they need to be in before tomorrow, so dont wait
<hallyn> apw: don't wait with what?
<hallyn> email to kernel list?
<hallyn> or something else?  Pull request?
<hallyn> (i guess i used the wrong list last week and earlier this week)
<arges> hallyn: kernel-team@lists.ubuntu.com
<hallyn> arges: thanks, just sent it there
<arges> hallyn: it may help to have a pull-request of a tree where the specific patches are applied on top of hte xenial tree
<arges> or just [PATCH] emails ifs its short and they cleanly git am on xenial
<hallyn> arges: ...  yeah, xenial is already pretty out of date so a pr may be worthwhile
<hallyn> grumble
<hallyn> i wonder whether my kernel.ubuntu.com git acct access is still valid - haven't used it since it migrated i dont' think
<arges> hallyn: i see a /home/serge on that machine
<hallyn> http://kernel.ubuntu.com/git/?ofs=500  should really provide a [from-to] range under each # at the bottom of the page :)
 * hallyn shuts up before someone drafts him to web hack
<hallyn> arges: last touched 3 years ago :)
<lamont> jsalisbury: next rock, pls?
<jsalisbury> lamont, ack, I'll let you knwo when the next one is ready
<lamont> ta
<lamont> jsalisbury: bad.  next ?
<jsalisbury> lamont, ack
<jsalisbury> lamont, next kernel is ready
<lamont> jsalisbury: should I be concerned that it's 4.2.0rc8 when the last known good was 4.3.0-7?
<jsalisbury> lamont, no, the naming is kind of weird.  The last kernel was bad, so this build is now back in time
<lamont> np
<lamont> it just means that Ihave to actually interrupt the boot process and pick one
<jsalisbury> lamont, the bisect bounces around allot, especially when there are merges
<lamont> ah
<lamont> jsalisbury: good kernel.  next?
<jsalisbury> lamont, great, I'll start the next build
<lamont> jsalisbury: and not that we care, but one monitor is screaming about "Out of Range"
<lamont> h 48.2KHz V 44.3Hz
<lamont> (yes the one that disappears in the bad kernels)
<lamont> there is just something satisfying about: sudo apt-get purge linux-image-$(uname -r) && reboot
#ubuntu-kernel 2016-02-18
<lamont> jsalisbury: fail
<lamont> andbug updated, afk for a while
<who_me> hello. is there a known issue with kernel 4.4 that it automounts volumes without them being mentioned in fstab? The system also shows ntfs volumes as mounted but they are not
<who_me> I've seen this using both the Xenial ISOs and by compiling the kernel using the patches in the mainline ppa
<apw> who_me, that would not be expected i don't think, mount decisions are almost exclusivly driven by userspace
<apw> who_me, where do they get mounted on?
<apw> the kernel would know about the volumes as it discovers them, but it has no idea where they are meant
<apw> to be mounted, so its not clear to me how it could be responsible
<who_me> ah heck, I never checked where the mount points were. will be right to report on that. brb. reboot. will also get a dmesg to pastebin it.
<who_me> alright, I'm on 4.4 now
<who_me> apw, they get mounted in /media/my_user_name/random_directory_name
<apw> who_me, that is gvfs that decides to do that, which is a part of the login session
<apw> thats the thing which mounts usb sticks and the like
<who_me> yes but this does not happen with anything earlier than 4.4
<apw> though i have not noticed it doing that spectacularly more than it did before
<apw> so i guess we need to find out what type of volumes it is finding now it did not before
<who_me> with the 4.3 series and earlier it mounts volumes when I click on them in the file manager
<apw> so, could you file a bug aginst the kernel "ubuntu-bug linux" 
<apw> and record that info, with some clear examples of the volumes it is now mounting it did not before
<apw> and perhaps include the output of blkid for those in 4.3 and 4.4
<apw> who_me, what sort of physical volumes are they ?
<apw> it is probabally something like the volumes are reporting themselves removable now
<apw> so gnome thing thinks they are sticks you rammed in, and mounts them without checking
<who_me> ummm they are on internal SATA SSD and HDDs
<who_me> apw, this is blkid shows: http://pastebin.com/bHTUwgpf
<who_me> in Disks they do indeed appear as removable drives...
<who_me> so weird
<apw> try this but sub in one of the drives that got mounted that you didn't expect: cat /sys/class/block/sda/removable
<who_me> returns "1"
<who_me> for some reason the kernelthinks they're removable?
<who_me> even my main drive shows up as removable
<who_me> so sda, sdb, sdc, sdd, sde and sdf show up as removable
<who_me> so yea, ubuntu bug respectfully invites me to report this upstream... oh well... will do
<apw> who_me, they may well be removable ... what are they connected to
<who_me> to internal SATA connectors on the mainboard
<apw> who_me, which kernel version is this
<who_me> 4.4.2 but also had this happen with 4.4.0
<smb> might be that ahci with hotswap support
<apw> right, it may be "true" in a literal sense
<apw> on 4.4.0-2.16 my sata drive is not removable
<who_me> at least it did not disable the read/write caches... as far as I can tell
<smb> apw, well don't nail me on this but at least on some boxes I think one could twiddle something in BIOS/UEFI to say a port is hotswap enabled or not
<who_me> [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
<who_me> smb, the UEFI on this mobo has such a setting, yes
<who_me> going to see whether it's on or off and flip it to off if that's the case then
<who_me> but I think gvfs should still not automount this stuff
<smb> who_me, so in theory if you say yes there the disk is potentially removable 
<who_me> anyway, brbr
<who_me> right, that solved it for most of my drives
<who_me> the one connected to the Marvell controlled port still shows up as removable
<who_me> but it's still weird, why would it do this now. No previous kernel caused this in the past :/
<smb> might be a "fix" even (to support now to read what the controller thinks it can handle)
<who_me> the problem is that I can only enable or disable the Marvell controller and set its mode like AHCI, IDE or RAID. And I also would not turn off the hotswap on that because I have an eSATA disk drive which I use on and off to store things long term
<apw> who_me, it sounds like it needs some thought, 1) to know why the kernel now is saying they are removable, and 2) to think about if this has a knock on effect for gvfs
<apw> who_me, did you file a bug in the end ?  if so what was the $
<apw> #
<who_me> I did, kernel bug #112681 on the kernel bugzilla
<ubot5> bug 112681 in kdelibs (Ubuntu) "[apport] kdeinit crashed with SIGSEGV" [Undecided,Invalid] https://launchpad.net/bugs/112681
<who_me> https://bugzilla.kernel.org/show_bug.cgi?id=112681
<ubot5> bugzilla.kernel.org bug 112681 in Other "kernel marks internal drives as being removable" [Normal,New]
<who_me> udev rule took care of the drive connected to Marvell controller...
<zkanda> Hello, anyone here can help me debug my sound card issue? I hear static noise for Ubuntu while this is not present in windows.
<Madkiss> apw: Are you there? We're getting back to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1505948 once again
<ubot5> Launchpad bug 1505948 in linux (Ubuntu Wily) "Memory arena corruption with FUSE (was Memory allocation failure crashes kernel hard, presumably related to FUSE)" [High,Confirmed]
<bjf> hallyn, can you verify LP: #1539349 for wily
<ubot5> Launchpad bug 1539349 in linux (Ubuntu Wily) "sleep from invalid context in aa_move_mount" [Undecided,Fix committed] https://launchpad.net/bugs/1539349
<hallyn> bjf: ok
<lamont> jsalisbury: ready for another kernel, though I expect it;ll be 5 or 6 hours before I can test it
<jsalisbury> lamont, good timing, I'm building it now.  I'll post it to the bug when it's ready
<lamont> jsalisbury: the lxc where I do 99% of my testing for the actual core-work is on the machine that I have to reboot each time to test this, so it's frequently blocked by EBUSY_PRIMARY_WORKSURFACE
<jsalisbury> lamont, gotcha
<rtg_> kamal, this bug fix might be suitable for stable for all our kernels: https://bugs.launchpad.net/bugs/1547207
<ubot5> Error: Could not gather data from Launchpad for bug #1547207 (https://launchpad.net/bugs/1547207). The error has been logged
<rtg_> bug #1547207
<kamal> rtg_, already applied to all of our stable kernels :-)
<kamal> rtg_, ... and pending in all of the Ubuntu master-next branches
<rtg_> kamal, cool
<rtg_> kamal, I don't see it pending in precise master-next
<kamal> rtg_, you're right -- I'll see if it applies
<rtg_> kamal, it does, I was just about to email out the patch
<kamal> rtg_, in that case, I'll ack it
<kamal> rtg_, you marked the bug "Fix Released" for T, V, W, and X, but its actually only "Fix Committed" for all of those (except X? i dunno)
<rtg_> kamal, I guess they'll be fix released soon enough
 * kamal looks the other way ;-)
<rtg_> kamal, good move
<rtg_> kamal, what about utopic ?
<kamal> rtg_, yeah, just looking at that
<kamal> rtg_, its "Fix Committed" in trusty/lts-backport-utopic-next
<rtg_> good
<kamal> 555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
<kamal> 555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
<kamal> 555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
<kamal> 555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
<kamal> 55555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
<arges> kamal: did a cat jump on your laptop?
<lamont> jsalisbury: fail, updating the bug
<kamal> whoa
<kamal> but now everyone knows my password!  ;-)
#ubuntu-kernel 2016-02-19
<smb> infinity, Holy grep it's crap! I mean the other way round (my build failures of Xen seem to be caused by grep in the sbuild environment deciding in the middle of a file to switch from text to binary mode)
<apw> smb, in the middle of a file ?
<smb> apw, yep
<smb> well not middle but after around 43 lines
<apw> smb, could you just switch to grep --text, or something 
<smb> apw, as a work around, yes
<apw> oh its "text" is it, like utf8 or something, sigh
<jdstrand> rtg: hey, curious, looking at the 4.4.0-7.22 changelog, I see 'rebase to v4.4.2' and 'Miscellaneous upstream changes'. does the latter include all of the changes that went into 4.4.2 over 4.4.1?
<jdstrand> rtg: talking about the upstream changes
<jdstrand> I've got an external displayport issue that I've been meaning to report that downgrading to 4.3 fixes
<jdstrand> so I keep looking at 4.4 kernel changes. I don'
<jdstrand> t see anything related to this, so curious if the list of upstream changes is complete
<jdstrand> (it is something I've always wondered about)
<rtg> jdstrand, The patches included in v4.4.2 are not listed in the changelog. That seems like an oversight.
<rtg> is that what you are asking ?
<jdstrand> I was asking about all the upstream changes whenever you rebase, in this base, 4.4.1 to 4.4.2, but more just generally
<jdstrand> s/this base/this case/
<rtg> jdstrand, during the dev cycle the changes introduced by a rebase are not listed, though they are easy ebough to find (if you know what you're doing)
<jdstrand> or more simply, can I rely on Ubuntu's changelog to list all changes from one release to the next, upstream and Ubuntu, or just the Ubuntu changes
<jdstrand> ok, that's fine
<jdstrand> I imagine the changelog would be rather long
<rtg> jdstrand, post dev, all commits are applied on top (modulo CVE rebases)
<rtg> so they'll all get listed in the changelog
<jdstrand> cool, thanks
<jdstrand> all that is going through my mind is "So your saying there's hope" :)
<rtg> jdstrand, for a display issue ? don't get too wound up :)
<rtg> jdstrand, if you have a bisectable range, then you could work with jsalisbury
 * jdstrand nods
<jdstrand> I wanted to try the next one from you guys before reporting
<jdstrand> I can say for sure that wily's kernel doesn't have this bug
<rtg> jdstrand, that bodes well for bisectability
<jdstrand> I was then going to (re)try the earliest 4.4 kernel in the archive, then report
<rtg> jsalisbury is a wizard
<jdstrand> yeah
<rtg> jdstrand, plus, I'm about to be on vacation :)
<jdstrand> this bug is rather annoying-- the screen just goes blank for 1 second or 2, then comes back, at totally random times, but only on the external monitor
<jdstrand> never seen anything quite like it
<jdstrand> rtg: nice! enjoy :)
<rtg> jdstrand, Intel I assume ?
<jdstrand> yes
<jdstrand> it seems like the it goes blank at all the wrong times too. almost like its sentient
<rtg> jdstrand, I've got Intel on my laptop connected to HDMI 4K monitor. its got some quirks but overall seems to work OK
<jdstrand> I may have not gotten inough sleep last night :P
<jdstrand> rtg: yeah, this is displayport (mini) 4K
<rtg> has it started to talk to you ? maybe you _shoud_ sleep.
<rtg> should*
<jdstrand> rtg: like you said, some quirks, mostly ok. The biggest quirk is hotplugging the monitor
<jdstrand> (other than this bug)
<rtg> jdstrand, I have to turn mine completely off once in awhile after resume from suspend. that is about the worst of the quirks
<jdstrand> but a dialog comes up that says it couldn't xrandr or something (and the display is all stretched out), but if I tap 'Enter' to dismiss the dialog, it rights itself
<jdstrand> rtg: yes, I used to see that more, but see it less often now
<jdstrand> it does this whole dance when hotplugging-- the laptop and the display flash, the monitor goes blank, it comes back, it might do it again, etc
 * jdstrand shrugs
<jdstrand> I'll file a bug for that another day
<rtg> jdstrand, slacker. I'm sure jsalisbury would love to have you test about a dozen kernels :)
<jdstrand> hey, well, that never worked right so...
<jdstrand> actually, the not being able to randr might've worked on wily...
<jdstrand> anyhoo, another day. I want to get this odd blanking bug reported
<lamont> jsalisbury: good kernel!  next rock?  (bug updated)
<jsalisbury> lamont, I'll build it now
<lamont> ta
<jdstrand> jsalisbury (fyi, rtg and ogasawara_): the external monitor screen blinking bug is bug #1547619
<ubot5> bug 1547619 in linux (Ubuntu) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Undecided,New] https://launchpad.net/bugs/1547619
<jsalisbury> jdstrand, ok, thanks.  we'll probably have to bisect it.  Are you able to test some kernels?
<jdstrand> jsalisbury: yes. will they be Ubuntu kernels? (ie, with apparmor compat, etc)
<jsalisbury> jdstrand, sure I can build Ubuntu kernels instead of upstream ones.  I'll post an update to the bug.
<jdstrand> jsalisbury: thanks! :)
<jsalisbury> jdstrand, Can you first test 4.4.0-1.15 to see if we can narrow the bisect window.  I post a link to it in the bug.
<jdstrand> jsalisbury: sure
<jsalisbury> jdstrand, thanks.  Then I'll start the bisect and post a test kernel.
<jdstrand> hmm, I do have secure boot enabled... I guess I'll need to fiddle with my configuration
<jdstrand> oh now, it'll fallback
<jdstrand> jsalisbury: fyi, I'm in 4.4.0-1.15-generic. it hasn't happened yet, but that doesn't mean anything. I'll report back in the bug
<jsalisbury> jdstrand, thanks
<jdstrand> jsalisbury: hah
<jdstrand> jsalisbury: the *moment* I started to do real work in a terminal, it happened
<jdstrand> I swear this thing is here to annoy the *&%^ out of me
<jsalisbury> jdstrand, thanks for testing.  I'll start the bisect with that being the first bad kernel
<jdstrand> jsalisbury: thank you for helping resolve this. I can't tell you how annoying this bug is
<jsalisbury> jdstrand, np.  
<jdstrand> I mean it isn't data loss or anything, but it really takes you out of the moment
<jsalisbury> jdstrand, I'm sure it does
#ubuntu-kernel 2016-02-20
<lamont> jsalisbury: bug updated, with a screwball request that would best be started this weekend :D
<lamont> jsalisbury: my gut tells me that d2e08c0 is likely good, and that of the bunch, 237ed86 is likely our culprit...
<lamont> though if d2e08c0 is bad, it's likely the one we want
#ubuntu-kernel 2016-02-21
<DalekSec> https://bugs.debian.org/815480 so someone might want to merge from Debian, then bump the version.  (Debian has had changes: http://metadata.ftp-master.debian.org/changelogs/main/c/cryptsetup/unstable_changelog )
<ubot5> Debian bug 815480 in src:cryptsetup "cryptsetup: versions before 1.7.1 incompatible with latest batch of Linux kernels (mainline and stable)" [Important,Open]
<phillw> LocutusOfBorg: a fellow Borg!!!!!
<LocutusOfBorg> phillw, Lower your shields and surrender your ships. We will add your biological and technological distinctiveness to our own. Your culture will adapt to service us
<LocutusOfBorg> resistance is futile.
<phillw> your move (apologies guys)
 * LocutusOfBorg gonna sleep(8*60*60)
<manjo> apw, logging off to get some beer .. are we good ? 
<manjo> apw, thanks a ton for your help 
#ubuntu-kernel 2017-02-13
<rtg> tseliot, how are you coming long on the nVidia drivers for the v4.10 kernel ? I see that we're still having ADT build failures.
<tseliot> rtg: I am looking at the changes in the CPU hotplug code, and I'm a bit confused, as, apparently, I have to use the cpuhp_setup_state() function but I'm not sure about the first two arguments
<tseliot> the first one is from an enum
<tseliot> the second is a string
<tseliot> following this pattern subsys/xxx/yyy:state
<tseliot> the last two arguments are clear to me
<tseliot> I'm not sure whether the first argument should be CPUHP_AP_ONLINE_DYN or CPUHP_HP_ONLINE, or something else.
<rtg> tseliot, you've exceeded my knowledge in that area
<tseliot> rtg: well, it's the first time I read the code too. I'll looking for examples within the kernel, and I'll experiment a bit. I'll let you know when this is done
<rtg> tseliot, thanks, we're close to promoting a v4.10 kernel to proposed. I'd really like the nVidia drivers to at least build
<tseliot> rtg: working, in addition to building, would be a nice plus ;)
<rtg> indeed
<tseliot> documentation FTW! https://static.lwn.net/kerneldoc/core-api/cpu_hotplug.html
 * tseliot has an idea or two on how to do it
<ricotz> rtg, hi, seems new intel i915 guc firmware is still missing
<rtg> sforshee, ^^
#ubuntu-kernel 2017-02-14
<sforshee> ricotz: can you tell me which firmware is missing, and from what release? There's some firmware that i915 asks for that Intel hasn't ever released.
<zyga> hey, when is the next release of the kernel into xenial
<zyga> (next SRU)
<ricotz> sforshee, afaics they are available here https://01.org/linuxgraphics/downloads/firmware bxt_guc_ver8_7.bin and kbl_guc_ver9_14.bin
 * sforshee wonders why intel hasn't pushed those files to linux-firmware
<sforshee> ricotz: so I see that y and z kernels will use those files. I'm going to ask the i915 developers about them, whether they haven't pushed them out to linux-firmware because they aren't stable or something like that.
<sforshee> I note that even the firmware download page says that it's okay to ignore the "Possible missing firmware ..." messages :-P
<ricotz> sforshee, ok
<ricotz> sforshee, and HuC is missing completely ;)
<sforshee> ricotz: the fact that the driver asks for them but intel doesn't ship them has become very common and very annoying
<zyga> jdstrand: hey, I saw your comments on mount helpers
<zyga> jdstrand: I think I we didn't understand each other earlier
<zyga> jdstrand: I replied to the first comment there, please have a look and if you can let's discuss this quickly here
<zyga> jdstrand: recall that all of this stuff is currently done manually in each if (!mount) { die( .... ) } code and it does provide invaluable insight into what is going on when things fail; if you are worried about string formatting (which at this stage I'm not worried about as we went through a lot of effort to make it safe to use) then we need to think about a debug and testing story: how would this 
<zyga> work? two instances of snap-confine (both setuid root?)
<zyga> jdstrand: it feels like a lot of work for unclear value to me
<jdstrand> zyga: we can talk here, but not sure why we are here :)
<zyga> ohhh
<zyga> sorry, wrong channel
<zyga> ;D
<rtg> tseliot, how is nVidia looking ?
<tseliot> rtg: I'm working on it right now. It's a fix/build/fix/etc. process, I hope to have something working soon
<rtg> tseliot, cool, thanks
<tseliot> rtg: I have a patch for 375 that builds. If that also works, I'll try to apply the changes to the legacy drivers tomorrow.
<rtg> tseliot, ack
<nzoueidi> Hello guys, I am taking a look on Ubuntu kernel's bug related topics and I found this : https://bugs.launchpad.net/ecryptfs/+bug/432785
<ubot5> Ubuntu bug 432785 in ecryptfs-utils (Ubuntu) "add support to ecryptfs-setup-swap for keyed hibernation" [Wishlist,Won't fix]
<nzoueidi> If it is possible is there any clear explanations why the bug won't fix.. 
#ubuntu-kernel 2017-02-15
<lorddoskias> hello when i dump blocked tasks via sysrq (echo w> /proc/sysrq-trigger) my output is dominated by schedstats and this overruns the kmsg buffer and i cannot see the blocked stasks, how can i disable this? 
<lorddoskias> i'm using 4.4.0-62-generic kernel 
<tseliot> rtg: my patch works, in addition to building. I am going to update all the drivers today
<rtg> tseliot, great, I'll get that 4.10 kernel promoted to -proposed
<tseliot> rtg: I can't test CPU_HOTPLUG with my hardware though
<rtg> tseliot, well, I guess we'll have to rely on community
<tseliot> rtg: fair enough, it's a bit of a corner case anyway
<osc_khoj> My system is crashed...Who can help me please? http://paste.ubuntu.com/24000622/
<osc_khoj> now I run "crash" now...
<osc_khoj> It;s openstack hypervisor ..and 5 machines are crashed in parallel 
<apw> osc_khoj, that is reporting that the kernel was hit with an unexpected NMI and got upset
<osc_khoj> awp : but hp enginner said there are no log in ilo.
<osc_khoj> A Non-Maskable Interrupt (NMI) is a hardware interrupt that cannot be ignored by the processor.  These types of interrupts are usually reserved for very important tasks and  to report hardware errors to the processor. The Operating system does not have much of a role in NMI handling,  it primarily reports what the hardware throws.  The kernel is able to interpret the reason for some NMIs.  The normal behaviour is to log it an
<osc_khoj> I searched the google..but, I need some clue to solve the problem.thanks.apw
<apw> osc_khoj, as that text says, the kernel doesn't normally have anything to do with them, they come from the platform
<apw> osc_khoj, i would tend to expect that to be a hardware problem if it occured on my machine.  i would likely reboot as normal and worry about it if it recurs
<apw> (on my own kit, you obviously need to decide for your platform)
<osc_khoj> Is there any command to find the clue in crash?    HW : HP BL460c G9 - OS : ubuntu 14.04 (3.16.0-30-generic #40~14.04.1-Ubuntu) - SW : openstack Juno version
<osc_khoj> after crashed, I update kernel to 3.16.0-77..because there are no debug tool...in 3.16.0-30.
<osc_khoj> but, same issue occured..
<apw> osc_khoj, on the same CPU do you know ?
<apw> osc_khoj, that crash is pretty thin on information if all it is showing is that one processor in NMI
<osc_khoj> apw,  many machine occured the crash.
<osc_khoj> we have 20 openstack compute node...5 machines crashed about 1 month...
<osc_khoj> I run some command if you want, apw, now
<apw> osc_khoj, hmmm. 3.16 that was a utopic kernel, so we don't have anything newer on that stream to try, it being far beyond EOL
<apw> osc_khoj, it must have any number of guest to host security issues
<apw> i would try a kernel from a supprted release on there as the first step, to see if that stops the issue
<osc_khoj> It's very difficult to update the kernel because it;s openstack compute node..
<infinity> Install kernel, migrate guests off, reboot, repeat?
<apw> osc_khoj, really, don't you just migrate them to another node reboot it, and migrate them back ?
<osc_khoj> hmm,after update the kenrel, I can run live-migrate and can test...It don;t need to com back.
<osc_khoj> but we want to know the core issue...by analyze the crash dump.
<osc_khoj> Is there no info in crash? ^^
<apw> osc_khoj, maybe, likely not, it looks and sounds like the h/w is trying to tell you something and the kernel has no idea how to handle it and exploding
<apw> osc_khoj, that is the kind of thing we see new drivers for, handling new forms of EDAC information coming up from the hardware
<osc_khoj> Thanks apw, I will update the kernel and retest h/w....
<niluje> I can't kill -9 a process running in a docker container (tried both from the host and from the container). ps status is R. Any idea?
<green_> hi
<green_> I am looking for good instructions for recompiling 4.8.0-28-generic kernel. I need to edit a file, recompile. I'd need that specific kernel as it works with sound on a new machine
<green_> I haven't compiled kernels before so beginner type instructions would be useful and the location of source for download
<apw> green_, there should be information in the kernel team wiki
<apw> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel perhaps
<WeiJunLi>  https://bpaste.net/show/1b11450f5e8e - 'make mrproper' cleans everything including delete debian/rules which is needed for compilation
<apw> WeiJunLi, yes, it has no understanding of the debian bits
<WeiJunLi> apw: what that means exactly
<WeiJunLi> what should i do
<apw> running make mrproper does not work correctly in an ubuntu kernel, but it should not be needed
<ogra_> to clean up: fakeroot debian/rules clean
<WeiJunLi> I have done that.
<WeiJunLi> and then fakeroot debian/rules editconfigs
<WeiJunLi> and for last that one in the paste
<WeiJunLi> which productes that Error
<WeiJunLi> produces*
<apw> WeiJunLi, rmdir include/config
<WeiJunLi> apw: I dont have any file named config inside include folder
<WeiJunLi> I do have one .config which in the root of the source tree
<WeiJunLi> which is the kernel .config itself
<apw> i find that when it produces that error rmdir include/config sorts that out
<WeiJunLi> 'no such file or directory'
<green_> apw: ok thanks. If I recompile would the resulting kernel be exactly the same as the one I am using exceept for the changes I make?
<WeiJunLi> apw: anything else?
<apw> WeiJunLi, it is possible the .config would also confuse things
<apw> WeiJunLi, you don't normally use a .config in the top level with debian packaging
<WeiJunLi> I just noticed now that I have a bunch of .deb files on /home/
<WeiJunLi> not sure if I should go forward or just delete them
<WeiJunLi> apw fakeroot debian/rules editconfigs 
<WeiJunLi> I'm loading a .config
<WeiJunLi> not sure what's wrong.
<apw> i am not sure what you are askingme
<WeiJunLi> where should the .config be then
<WeiJunLi> if not in the top level
<apw> in debian/configs is where our configs are
<WeiJunLi> ok so I should move the .config there
<WeiJunLi> and what commands to do next
<apw> if you are trying to make an ubuntu compatible kernel it is more normal
<apw> to add the changes you need to make to the debian/configs/.../config.flavour.<flavourname> file
<apw> and then run fakeroot debian/rules updateconfigs
<apw> replacing the .config wholesale is not a normal thing to do
<apw> but if you really think you have to dropping it in as that leaf config and running the same command may help
<WeiJunLi> apw: I'm used with the basic method, make; make modules; sudo make modules_install; make install
<WeiJunLi> everytime i say I do that way, the feedback is to use the debian way with fakeroot
<WeiJunLi> but in fact in kernel # nobody do that wya.
<apw> you use whatever method works for you
<WeiJunLi> apw: Im trying fakeroot because last time i compiled one, guess was missing the filesystem '/' since when the kernel booted i was getting into the busybox initramfs shell
<apw> or your config doesn't contain something that the ubuntu runtime initramfs requires
<WeiJunLi> apw: if i show you my .config can you try to spot something wrong?
<apw> WeiJunLi, it is far to complex to just look over the config
<apw> WeiJunLi, you would want to compare the generated config, with the config you intend
<apw> WeiJunLi, you can generate configs using "fakeroot debian/rules genconfigs" ... they will be generated in CONFIGS/*
#ubuntu-kernel 2017-02-16
<WeiJunLi> There's a way to fix "Alert! /dev/sda1 does not exist. Dropping to shell" busybox initramfs?
<mystictot>  where to find kernel public key and private key in distro kernel?
<tai271828_> jsalisbury bjf   I found a potential kernel regression, and please refer to LP: #1665280 for more details.
<ubot5> Launchpad bug 1665280 in linux-raspi2 (Ubuntu) "Boot into emergency mode on RPi2 with proposed kernel 4.4.0-1043.50 after system update" [Undecided,New] https://launchpad.net/bugs/1665280
<green_> when running this command apt-get source linux-image-$(uname -r) do I need to replace anything or can I run it as is.
<green_> I got this "E: You must put some 'source' URIs in your sources.list"
<green_> I am running mint
<sforshee> green_: you need to uncomment the deb-src lines in /etc/apt/sources.list, the run "apt-get update"
<green_> why apt-get update?
<green_> Is this meant to get source for current kernel? apt-get source linux-image-$(uname -r)
<sforshee> green_: "apt-get update" updates your indexes for the changes to sources.list, after that your "apt-get source" command should work
<green_> ok. I got this: Release amd64 20161213 xenial Release' does not have a Release file.
<green_> N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use
<green_> E: Failed to fetch cdrom://Linux Mint 18.1 _Serena_ - Release amd64 20161213/dists/xenial/contrib/binary-amd64/Packages  Please use apt-cdrom to make this CD-ROM recognized by APT. apt-get update cannot be used to add new CD-ROMs
<green_> sforshee: The whole output http://dpaste.com/2BDBVZW  Do you think it's fine.
<apw> green_, that sounds like you enabled the src lines for the CD and not the archive
<green_> apw: there was only one line in the file deb cdrom:[Linux Mint 18.1 _Serena_ - Release amd64 20161213]/ xenial contrib main non-free
<green_> which folder did it go to? Do I need to delete or do anythingf?
<apw> green_, then that is not the source line for the archive, is there other files in apt.conf.d
<rtg> dannf, you are likely to know the answer to this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1239109/comments/6
<ubot5> Ubuntu bug 1239109 in linux (Ubuntu) "aarch64 clock_gettime with CLOCK_REALTIME_COARSE or CLOCK_MONOTONIC_COARSE fails with SIGBUS or SIGSEGV" [Medium,Confirmed]
<rtg> if so, please comment in the bug
<green_> 00: aptitude cdrom mint recommends trustcdrom  01 autoremove autoremove-kernels vendor-ubuntu 20dbus 70debconf
<green_> do I need to to do anything about running apt-get update
<green_> there is an offical-package-repositories.list
<dannf> rtg: i don't now about that one, but could test if there's a test case
<green_> sources.list.d folder
<rtg> dannf, its a 4 year old bug. I'd think it would have been fixed by now
<green_> with this line # Do not edit this file manually, use Software Sources instead.
#ubuntu-kernel 2017-02-17
<nzoueidi> Hello, is there any newbie bugs related to the kernel? something I need to start of with
<green_> apw: any ideas on the situation
<apw> green_, i have no scrollback, so i have no idea as to what we are talking about
<green_> apw: The whole output http://dpaste.com/2BDBVZW  Do you think it's fine.
<green_> <apw> green_, that sounds like you enabled the src lines for the CD and not the archive
<green_> apw: I was trying to recompile kernel and run the command 
<green_> apw: using instructions here https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<green_> apw: apt-get source linux-image-$(uname -r)   
<green_> apw: I wanted to recompile the same kernel I am  using and edit regd.c file in source
<apw> it is the ones with archive.ubuntu.com that you want to add/uncomment deb-src lines for for that to work
<apw> not the deb-src related to the non-existant cdrom
<green_> That line was not in the source file. There is only one line in the file 
<green_> you then asked me to check whether there are other files
<apw> likely, if apt is finding our ubuntu repositories they must be listed somewhere
<apw> likely in /etc/apt/sources.list.d/*
<green_> I am running mint 18.1. there is /etc/apt/sources.list.d/official-package-repositories.list
<green_> That file has this line # Do not edit this file manually, use Software Sources instead.
<apw> you could do that then
<green_> all other lines are uncommented. None have deb-src; they all begin with deb and then an URL e.g. deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
<apw> likely software source will add them if you enable sources
<green_> What would I do specifically in software sources?
<apw> green_, i think there is a 'source code' tickable, but i don't use it often
<green_> there is "enable source code repositories"
<apw> that sounds like the sort of ting
<green_> and then update cache?
<green_> apw: Thanks. that worked I think
<ogra_> apw, this is mint ... donnt expect something like "software sources" to work as in ubuntu ;) (or anything else for that matter)
<apw> it is all a guessing game that is for sure
<green_> ogra_: So it appears I downloaded the source for 4.8.0 and updates for 4.8.0-34.36 but I am running -28 specifically because it works with sound
<green_> ogra_: the idea was to enable chan 13 on the sound card by editing regd.c on this exact kernel which work correctly with the sound on a new kaby lake machine
<green_> In update manager, the -28 is listed as the first available. Would that mean that 4.8.0 source that I downloaded is -28 or could it be some other version
<apw> -28 who knows, that isn't anything recent
<green_> Is there any way to check in some file? Is this statement correct for mint also For example to obtain the source for the currently running kernel you can use the command:
<green_>     apt-get source linux-image-$(uname -r)
<ogra_> doesnt mint have its own kernel package ? that would likely not be called linux-image-*
<green_> does "currently running kernel" mean the specific ver (-28) that I am running or just 4.8.0 without any specific version.
<ogra_> aha ... http://packages.linuxmint.com/pool/main/l/linux-kernel/ 
<ogra_> so they call it linux-kernel-
<apw> cat /proc/version_signature
<apw> or it is unrelated and all bets are off
<green_> I am not really sure. I was pointed to Ubuntu when I asked about kernels. That list at  http://packages.linuxmint.com/pool/main/l/linux-kernel/  ends at 4.4 while currently the latest are 4.8
<apw> green_: I know little to nothing about how mint selects it's kernels
<apw> but the apt-get incantation gives you source for what you are running ...
<green_> I got this with the cat command Ubuntu 4.8.0-28.30~16.04.1-generic 4.8.6
<green_> apw: so I don't need to check if the source is the same version as what I am running. I could just try to recompile and use those instructions
<green_> apw: for ubuntu
<apw> that is some achient version, but if the .DSC you have matches you are good
<green_> apw: I guess I could wait for 4.10 and try it instead since I am already recompiling. I am not sure what .DSC is
<green_> apw: or how I would check it matches
<apw> the versions is in the filename.
<green_> apw: You mean this linux-hwe-edge_4.8.0.orig
<green_> apw:  of the downloades source?
<apw> there is one ending .dsc
<green_> apw: aha. actually no, it's 34.36 with .dsc and I am running 28.  I also see this dpkg-source: warning: failed to verify signature on ./linux-hwe-edge_4.8.0-34.36~16.04.1.dsc
<apw> then this is not the one you want
<green_> apw: 3 files were downloaded: linux-hwe-edge_4.8.0.orig, linux-hwe-edge_4.8.0-34.36~16.04.1 and linux-hwe-edge_4.8.0-34.36~16.04.1.dsc
<green_> I think 36 did not work correctly with the sound, while 34 I did not try
<apw> well the command you are meant to run, should get the one you are running and no other
<green_> apw: ok so what do you think happened. I did run that exact command. Is it possible that the orig file is what I am running and the 34.36 are updates?
<apw> what was the command you ran
<green_> apt-get source linux-image-$(uname -r) pasted from https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<apw> and what does "uname -r" say
<green_> 4.8.0-28-generic
<green_> 4.8.0-28-generic is  aslo in mint update manager as "active"
<apw> so run that in a new clean directory, and pastebin the output
<green_> I am running it. I see this line Picking 'linux-hwe-edge' as source package instead of 'linux-image-4.8.0-28-generic'
<apw> the source package for linux-image-* can be different, linux, liux-lts-*, linux-hwe, etc etc
<green_> is there a keyboard shortcut to select all text in terminal
<green_> http://dpaste.com/2JXCHTY
<apw> oh it is getting the latest version of the kernel on the assumption you are running the latest
<apw> apt-get source linux-image-$(uname -r)/$(uname -r)
<apw> green_, ^ does that get a different version ?
<green_> should I run this apt-get source linux-image-$(uname -r)/$(uname -r)
<apw> might work, you never knwo
<apw> i can't trivially test it here, though if it goes wrong it will get the same wrong one it did before
<green_> ok. I'll try it. I guess I could also update the kernel to 34 and see if it works with the hardware. I believe I tested 36 but not 34; I don'[t remember. But 34.36 is also confusing
<green_> What's the difference between the 2 commands
<apw> apt-get source linux-image-$(uname -r)
<apw> apt-get source linux-image-$(uname -r)/$(uname -r)
<apw> in theory i am requesting a specific version, no idea if it works, it would for a binary
<green_> apw: Reading package lists... Done
<green_> Picking 'linux-hwe-edge' as source package instead of 'linux-image-4.8.0-28-generic'
<green_> E: Unable to find a source package for linux-hwe-edge
<apw> bah
<green_> What about 34.36 What does that mean exactly. If I look at update manager I see 2 different ones: 34 and 36
<green_>  4.8.0-34.36~16.04.1 (dsc)
<apw> that is the what we call the ABI number
<green_> apw: If I click on changelogs in update manager I see both 34 and 36 described as _4.8.0-36.36~16.04.1/changelog was not found on this server.
<green_> apw: Actually no. 34 is 34.36
<green_> I could try updating the kernel to 34 (34.36); If it works with the sound hardware I could conceivably recompile that kernel.
<green_> apw: Why doesn't the command download what I am running and downloads a later kernel with that assumption. 
<apw> it defines an upload variant within the 4.8.0 series and increments over time
<apw> green_, it seems to assume you would only want to edit the latest code and move forward
<apw> green_, how about this "dget -d https://launchpad.net/ubuntu/+archive/primary/+files/linux-hwe-edge_4.8.0-28.30~16.04.1.dsc"
<apw> green_, i have gone to the source publication history for that package and found the specific .dsc for that version
<lamont> is it possible that a Core2 Q8400 would be better served by not using zram swap?  This machine is generally swapped to death everytime I go away for a while and come back
<ogra_> i cant really imagine a scenario where zram wouldnt be a good idea (unless you only have 128M on a 200MHz single core or so)
<ogra_> but easy to test i guess ... just remove the zram stuff and see 
#ubuntu-kernel 2017-02-18
<nzoueidi> o/ 
<nzoueidi> Out of curiosity, is the kernel of Ubuntu follows the code style of the linux kernel itself? 
<apw> nzoueidi, yep
<nzoueidi> Alright, thank you apw :)
<nzoueidi> I am interested in the mm sub-system in the Ubuntu kernel, do you have/know any bugs there (for newcomers)? 
<nzoueidi> I can't see any todo.txt there.
<apw> nzoueidi, those kinds of bugs are all in the upstream bugzilla
<nzoueidi> ah I see thanks :)
<apw> but that is one of the hardest things to start with, you might consider trying something simpler and work up
<nzoueidi> It would be much appreciated if you have examples/references :)
#ubuntu-kernel 2017-02-19
<_ami_> why does ubuntu kernel not use device tree? 
<_ami_> for x64 arch.
#ubuntu-kernel 2018-02-12
<sdeziel> while testing the retpoline enabled kernel ( linux-image-4.4.0-113-generic ) from xenial-proposed, I found a regression LP: #1748671 which I'd like to be fixed before this kernel hits -updates
<ubot5> Launchpad bug 1748671 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 0000000000000009" [Undecided,Confirmed] https://launchpad.net/bugs/1748671
<sdeziel> oh, I just noticed linux-image-4.4.0-115-generic in -proposed, I'll see if it helps with the above bug
<apw> sdeziel, do you know the last version that was not trivially reproduciblw
<sdeziel> apw: 4.4.0-112.135 didn't have the issue
<sdeziel> apw: it's what I had to roll back to
<sdeziel> apw: 4.4.0-115.139 is also affected
<apw> sdeziel, is that triggered by ipv6 in ipv4
<sdeziel> apw: I don't know as the artful container tries to get both. I'll try to disable one and will report back. Unfortunately, the affected machine is this very laptop :(
<sdeziel> apw: I just re-read an you said "ipv6 in ipv4" which I'm not using. Did you mean ipv6 OR ipv4 like I understood the first time?
<apw> sdeziel, i had gotten the impression there was ipv6 in there
<apw> sdeziel, this is 100% reproducible for you i believe right?
<sdeziel> apw: yes, I'm assigning both v4 and v6 natively
<sdeziel> yes, 100%
<apw> sdeziel, as there is only one change in 112->113 for that sort fo thing, which has one fix since
<apw> sdeziel, though that fix claims to be hyperthetical ... so ... hmmm
<apw> sdeziel, so ... if you can test them I will throw both those options up for you
<sdeziel> apw: sure, I'm here to test stuff :)
<apw> sdeziel, amd64 ?
<sdeziel> apw: yes
<sdeziel> apw: "net: ipv4: fix for a race condition in raw_sendmsg" ?
<apw> right ... whcih is also where your stack strace is in
<apw> sdeziel, ^ will have something to test in about 20m
<sdeziel> apw: awesome thanks
<sdeziel> apw: I don't want to cloud the picture but I also hit LP: #1748513 with a similar looking trace to my untrained eye. It's on a different machine and not easily reproducible but maybe they both are related?
<ubot5> Launchpad bug 1748513 in linux (Ubuntu) "BUG: unable to handle kernel paging request at 00007f29ec101010" [Undecided,Confirmed] https://launchpad.net/bugs/1748513
<apw> sdeziel, ok i think we may have found an issue here which would explain the issue ... so could you test: http://people.canonical.com/~apw/lp1748671/fix-not-xenial/
<sdeziel> apw: sure, give me a couple of minutes
<apw> sdeziel, and don't forget the linux-image-extra
<sdeziel> apw: no I won't :)
<sdeziel> apw: I'm missing linux-signed-image-4.4.0-115-generic (https://paste.ubuntu.com/=wFyMVxCK2G/). Not sure if it matters
<sdeziel> rebooting
<apw> sdeziel, yeah i didn't make one, i can't make one with a signature that you could boot anyhow
<sdeziel> apw: the test kernel fixed the problem
<sdeziel> thanks a lot!
<apw> sdeziel, ok great, will get that applied
<sdeziel> apw: any idea if that could also fix LP: #1748513?
<ubot5> Launchpad bug 1748513 in linux (Ubuntu) "BUG: unable to handle kernel paging request at 00007f29ec101010" [Undecided,Confirmed] https://launchpad.net/bugs/1748513
<FjodorAE> Was looking forward to vboxguest module with 4.16, yet config patch seems to suggest it isn't set (config based on 4.15) - is someone aware, or where should I file a report?
<apw> FjodorAE, file a bug against the package linux for now, and let me know the bug number
<FjodorAE> apw: Thank you - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749015
<ubot5> Ubuntu bug 1749015 in linux (Ubuntu) "4.16 - VBOXGUEST not built" [Undecided,New]
#ubuntu-kernel 2018-02-13
<demahum> I am looking forward to understand Ubuntu Kernel updates. For the beginning, if I do apt update followed by apt upgrade, and if the kernel update is available, I will get it that way, correct?
<apw> apt update then apt upgrade i believe yes will get you any availble kernel updates
<apw> assuming you have the appropriate meta package installed (which you should by default)
<apw> demahum, ^
<demahum> apw: awesome
<demahum> now..
<demahum> there is this: https://wiki.ubuntu.com/Kernel/Support
<demahum> the kernel release schedule
<apw> yes
<demahum> and in my case, I have 16.04.3 LTS
<demahum> and my current kernel is 4.4.0-112
<demahum> I am talking desktop, but it's the same on my server
<apw> you installed from 16.04.3 media ?
<demahum> apw: yes yes, everything standard and default
<demahum> now...
<apw> servers tend to keep the GA kernel (4.4.0-* in the case of 16.04)
<apw> i ask about the media you used because if you installed from 16.04 or 16.04.1 media and upgraded
<apw> you would have 16.04.3 in the sense that is what lsb_release thingy would say
<apw> but you would have a differnt kernel selected than if you used 16.04.3 media
<apw> for the install
<demahum> apw: what can happen (aside from manual kernel installation) that my 16.04. jumps from 4.4.0-* to e.g. 4.12.*?
<apw> if you had installed from 16.04.2 or later you would have had the linux-hwe kernel selected
<apw> and that kernel jumps from 4.8 -> 4.10 -> 4.13 as it is following the hardware-enablement branch
<demahum> apw: Awesome!
<demahum> apw: you gave me enough information so I can read on now. Big thanks!
<apw> so i assume if your desktop is following 4.4 it was installed from older media
<demahum> apw: after I read these... if something is unclear, I'll come back
<apw> and has 'linux-generic' meta package installed, which keeps your GA kernel up to date
<demahum> apw: yeah, probably that's the case
<apw> a machine which has the later stuff on it would have linux-generic-hwe-16.04 installed which keeps the linux-hwe kernel up to date
<demahum> apw: perfect, thanks!
#ubuntu-kernel 2018-02-14
<ricotz> hello, 
<ricotz> oops, is there an ETA for the xenial hwe-edge kernel update of 4.15?
<klebers> ricotz, hi. xenial/linux-hwe-edge will probably be updated to 4.15 in -updates when Bionic is released, which is scheduled for the end of April
<ricotz> klebers, hi, thanks, I was more aiming for the updated git-tree or even a kernel ppa build
<klebers> ricotz, oh, I see. So in that case I am not aware for now of the development schedule
<ricotz> klebers, I see, thanks
<apw> ricotz, we would normally be starting to think about one right now, "as the point release has gone out"
<apw> but our schedule is all in the crapper
<ricotz> apw, I see, you mean your schedule melted ;)
#ubuntu-kernel 2018-02-15
<dupondje> Hi All! There doesnt happen to be daily linux-firmware builds somewhere?
<apw> dupondje, don't think so no, what are you looking for
<dupondje> apw: well I need to run drm-tip kernel because otherwise my docking station is crashing my system :) Now when installing it I notice "W: Possible missing firmware /lib/firmware/i915/cnl_dmc_ver1_07.bin for module i915
<dupondje> guess its better to have recent firmware next to a recent kernel :)
<dupondje> but guess i'll have to build my own :)
<apw> well if you have the file you can just drop it in the directory
<apw> you don't need a package
<dupondje> ah, the lazy solution is maby easier :D
<jmux> Hi. I have a pending Xenial 4.4 SRU since ~2 weeks (https://lists.ubuntu.com/archives/kernel-team/2018-February/089892.html).
<jmux> I've read the SRU suspend mail, so I'm wondering, when new patches will be picked up.
<jmux> It would be nice to have a proposed kernel to test in three weeks, as we're going to run our final tests with the new HW:
<jmux> I still can patch the kernel myself, but would really like to avoid it, as this means patching all security updates.
<jmux> Now that the other patches for the HW are accepted upstream, I'll open some new SRUs, but these aren't critical, as I can easier fix them via DKMS updates.
<smb> jmux, There is a long list of things to be picked up once the 16.04.4 point release is done. But with the recent history of emergencies I would not dare to give any specific dates.
<walac> Hi, this might be a stupid question, but I am trying to create a custom linux-image-4.4.0-1014.14-aws package, but debian tools like debuild look for files under debian/ directory, wherein this package they are in debian.aws. How could I create a clean source package in this case?
<smb> walac, have you tried running "debian/rules clean" once before running the build?
<walac> smb: yep, just after asking the question here I figure it out with dpkg-source... typical
<jmux> smb: I just saw a lot of stuff was applied, but mostly fixes, not a feature backport. I was just wondering what was going on.
<jmux> smb: I'll plan my patching in two weeks and if a proposed kernel is available I'll use it, otherwise patch myself.
 * jmux has read the normal SRU cyccle is ~ a month, but since the cycles were suspended indefinitly - so be it
<bjf> jmux, we've been doing almost weekly kernel updates with the latest meltdown/spectre fixes. because of how quickly they have been coming we've not wanted to put
<bjf> jmux, much more in that just those to lessen the chance of regression
<bjf> jmux, March 1 is the new release date for the point release. we hope to start regular SRU cadences again once that's out the door
<jmux> bjf: I'm aware and not complaining. I just have my fixed dates for the new HW. And I can patch the stuff myself. I'll adapt my TODO lists and at some future point switch to the Ubuntu kernel again.
<jmux> bjf: I already have additional patches for the HDA, cifs, i915, fujitsu-latptop keycode support, but sinse all these are modules, I simply build DKMS packages.
<jmux> bjf: but the rfkill module is compiled in, so there is no other way then to patch the kernel
 * jmux ... and now that 4.15 is in bionic, I'll have to test and eventually port some of it, as some of these patches were just accepted upstream
<Fjodor> Just popped in and saw jmux mention 4.15 being in Bionic - not sure if there is a separate channel for DKMS packages, but if someone needs a patch for broadcom-sta, I cooked one up in the beginning of the 4.15rc-cycle, if someone needs it. Not super-easy, but also not overly hard, so no prob if someone else have come up with something better
<walac> could anyone tell me why my build failed? https://launchpadlibrarian.net/357156677/buildlog_ubuntu-trusty-amd64.linux-aws_4.4.0-1014.14taskcluster_BUILDING.txt.gz
<apw> walac: the error 8s at the bottom, you didn't create the previous abi
<walac> apw: I didn't get (kernel building newbie here)
<walac> :)
<walac> apw: ah, ok, google is a friend, got it now :)
#ubuntu-kernel 2018-02-17
<irgendwer4711> how to compile a meltdown/spectre secure kernel? I took config of 4.4.0-112-generic and compiled myself. this kernel is not like the stock kernel 4.4.0-112-generic. why?
<smeso> what you mean by "not like"?
<smeso> are you sure you got the right sources and the right config files?
<irgendwer4711> I took the latest source
<smeso> how?
<irgendwer4711> apt get: 4.4.0.112.118 
<tomreyn> $ apt get: 4.4.0.112.118 
<tomreyn> E: Invalid operation get:
<tomreyn> i doubt that's the command oyu ran
<irgendwer4711> funny
<irgendwer4711> linux-source_4.4.0.112.118_all.deb
<tomreyn> that's the file name of a package. did you create this yourself, did you download it (where)? what did you do with it? what happened and what did you expect to happen instead?
<tomreyn> without more context, it will be impossible to assist you
<irgendwer4711> its a ubuntu package
<irgendwer4711> its the stock kernel sources fÃ¼r Ubuntu lts 16.04
<smeso> I'll assume that you installer it via `apt-get install linux-source`, then what did you do?
<smeso> s/installer/installed/
<Nafallo> perhaps https://help.ubuntu.com/community/Kernel/Compile will help
<Nafallo> not sure if that's updated, but otherwise check out the kernel-team's pages on help and the wiki.
<irgendwer4711> smeso: compiled it with stock config config-4.4.0-112-generic
<tomreyn> https://packages.ubuntu.com/xenial/linux-source is a meta package, does not contain kernel sources
<smeso> irgendwer4711: we need details
<irgendwer4711> which details? you dont know how to compile a kernel???
<smeso> I do, but apparently you don't
<smeso> we need details to understand what you missed
<irgendwer4711> sure I do.
<smeso> OK
<smeso> so what's the problem?
<irgendwer4711> the spectre/meltdown protection is missing
<smeso> *if* that's true it means that you did something wrong
<irgendwer4711> only Page Table Isolation  is active
<irgendwer4711> I did this: /spectre-meltdown-checker.sh --kernel /usr/src/linux-source-4.4.0/linux-source-4.4.0/arch/x86/boot/bzImage --config /usr/src/linux-source-4.4.0/linux-source-4.4.0/.config --map /usr/src/linux-source-4.4.0/linux-source-4.4.0/System.map
<smeso> I doubt that can have PTI on a 4.4.0
<Nafallo> https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown â updated information about this, updated last Friday
<irgendwer4711> so I should have protection for all 3 variants....
<smeso> no
<smeso> (assuming that you are on x86_64)
<irgendwer4711> you didnt read the status table?
<Nafallo> all mitigations haven't landed upstreams yet, have they? we still need new microcode updates.
<irgendwer4711> I have an amd cpu
<smeso> irgendwer4711: Did you?
<Nafallo> but I believe what can be done for the kernel has been done :-)
<smeso> so why you care about meltdown?
<irgendwer4711> I summed it up
<irgendwer4711> and I told, that PTI is active
<smeso> and you are wrong again
<smeso> there is no PTI in 4.4.0
<smeso> KAISER != PTI
<irgendwer4711> * Kernel supports Page Table Isolation (PTI):  YES
<smeso> I give up
<irgendwer4711> read the table!
<irgendwer4711> 4.4   M=Y
<smeso> 4.4 has KAISER, which is a (not so good) mitigation for metldown
<smeso> PTI is only on newer kernels
<irgendwer4711> smeso: nevermind, I have an AMD CPU
<irgendwer4711> my model is not vulnerable
<irgendwer4711> so now I need something against Spectre 1 and 2
<smeso> for 2 you have to wait a working microcode update
<smeso> 1 should be there already
<irgendwer4711> script said for stock kernel: Kernel is compiled with IBRS/IBPB support
<Nafallo> irgendwer4711: read the USN for your kernel listed on the link I sent you. especially the bottom part :-)
<irgendwer4711> which part?
<Nafallo> irgendwer4711: the one that mentions IBRS/IBPB waiting for microcode...
<irgendwer4711> I know that part.
<irgendwer4711> I cant check this yet, because I am running a different kernel.
<irgendwer4711> BUT my compiled kernel is missing "Kernel is compiled with IBRS/IBPB support" and the stock one has support!
#ubuntu-kernel 2020-02-10
<ohcanada> hello. question related to kernel 5.4 and nvidia-340 support. i have some old quadro 170M and g210 machines which currently use nvidia-340 on bionic-hwe, kernel 5.3. will nvidia-340 continue to be supported on 20.04, after nvidia said they will no longer support 340 driver? if this is the wrong place, where do i ask? thanks
<apw> ohcanada: I think the oldest I have seen is -390 in our newer releases
<apw> which I thought was the legacy branch for older hardware support
<ohcanada> right. well i'm seeing https://packages.ubuntu.com/focal/nvidia-340
<ohcanada> i guess the question is, will this vanish by the time april comes along?
<mamarley> ohcanada: I think #ubuntu-x might be a better place to ask this.  I'm pretty sure there was a discussion about nvidia-340 in Focal there a few days ago.
<ohcanada> mamarley: ok nice. i'll go ask there
#ubuntu-kernel 2020-02-11
<ryuo> I submitted a Ubuntu bug for a rather simple issue and haven't heard anything yet. Any ideas when someone will respond? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1862498
<ubot5> Ubuntu bug 1862498 in linux (Ubuntu) "Nuvision NES11 needs silead touchscreen quirks" [Undecided,Confirmed]
<tjaalton> ryuo: you should send the patch upstream
<ryuo> tjaalton: normally i would but i've been blown off before. last time i got more results by using an indirect channel.
<tjaalton> so you're kinda asking others to do the work?
<ryuo> to an extent, i guess. i already did a lot of the work devising my patch.
<tjaalton> yeah but it would have to go upstream
<ryuo> i know, but i'm a nobody. i would likely just get ignored like i have before.
<ryuo> sigh.
<tjaalton> so you've sent the patch to linux-input@vger.kernel.org?
<ryuo> tjaalton: not this time  but last time i had a patch
<ryuo> tjaalton: sent.
<tjaalton> good
<ryuo> though i expect to be summarily ignored like before.
<tjaalton> properly git formatted?
<ryuo> should be. i used git send-email
<tjaalton> ok
<apw> ryuo: add that info a link to the upstream submission to the bug
<apw> makes it easier to find
<FragginRight> i seem to be missing the dvb kernel headers on my 16.04 machine. how might i get them installed? i've been searching for a while now
<FragginRight> my google fu seems to be failing me :)
<cezary_zukowski> Does the newest (Out-of-memory) OOM killer supports cgroups?
<cezary_zukowski> Hi :)
<apw> i thought that oom was related to memory cgroups when in use; but one should really test it
<cezary_zukowski> Okay, thanks.
<nerdykid> Hi!  I need to have dkms copy a firmware file along with the compiled kernel module automatically.  My /usr/src/tn40xx-003/dkms.conf: https://pastebin.com/1VvuWYNf    I need dkms to copy /usr/src/tn40xx-003/x3310fw_0_3_4_0_9445.hdr to the same directory as the compiled .ko module.  Anyone know how to do this?
<apw> nerdykid (N,BFTL), if the dkms package is packaged up in a .deb you do it in that .deb context.  here is an example worked though in our wiki https://wiki.ubuntu.com/kengyu/dh_dkms
<chiluk> anyone else having issues with screen brightness on the 5.4 kernel+focal?
<apw> chiluk, not me
<chiluk> apw intel graphics?
<apw> chiluk, yep
<sforshee> me neither, and yes intel graphics
<chiluk> I'm completely unclear what software stack is involved in making that happen.
<sforshee> I don't think it's consistent, depends on the model
<chiluk> it was working afair until moving to the 5.4... that being said a bunch of other things probably changed at the same time as well.
<chiluk> also good to see you guys are still kicking.
<sforshee> chiluk: look at /sys/class/backlight, should point you to your driver I think
<sforshee> not dead yet ;-)
<chiluk> yep intel_backlight
<sforshee> mine too
<tyhicks> chiluk, sforshee: I'm having screen brightness issues - reported in bug #1861521
<ubot5> bug 1861521 in linux-signed-5.4 (Ubuntu) "[FOCAL][REGRESSION] HP EliteBook 840 G5 screen brightness cannot be controlled" [Medium,Confirmed] https://launchpad.net/bugs/1861521
<tyhicks> I'm hoping to spend some time on that bug in the next couple days
<tyhicks> intel_backlight for me, too
<chiluk> hey hey .. another old name..
<tyhicks> hey chiluk :)
<chiluk> although I'm ona dell over here.
<tyhicks> chiluk: any chance you have a screen with a built-in privacy filter?
<tyhicks> the hp_wmi warnings I pasted into the bug are likely not related so we still could be seeing the same issue
<chiluk> I do not but it is a touch screen.
<sforshee> I have a dell and a lenovo which are both working with intel_backlight
<chiluk> I'm on a inspiron 5540 which is a i9-9880H generation.
<chiluk> could be a generational thing.
<chiluk> sforshee I'm calling your shit old.
<chiluk> ;)
<chiluk> tyhicks how new is that?
<tyhicks> $ glxinfo | grep Device Device: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)  (0x5917)
<tyhicks> bah
<tyhicks> bad paste
<sforshee> my dell is old, xps 13 with an i5-5200U
<sforshee> but my lenovo is brand spanking new, i7-10510U
<tyhicks> chiluk: glxinfo shows "Device: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)  (0x5917)"
<chiluk> t$ glxinfo | grep Device
<chiluk>     Device: Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)  (0x3e9b)
<tyhicks> so I'm gen9 according to https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Gen9
<sforshee> Device: Mesa DRI Intel(R) UHD Graphics (Comet Lake 3x8 GT2)  (0x9b41)
<tyhicks> same gen9 for chiluk 
<sforshee> so maybe a gen 9 thing, I've got gen 10
<tyhicks> I've got another gen9 I can test with, too
<chiluk> I'm going to quick check that the 5.3. kernel works 
<chiluk> Yep 5.3 works.  Looks like a 5.4 regression.
<tyhicks> my other gen9 works fine under 5.4.0-12-generic
<tyhicks> Device: Mesa DRI Intel(R) HD Graphics 515 (Skylake GT2)  (0x191e)
<tyhicks> it is also an HP
<chiluk> nope ... that's a skylake carry-over gpu it looks like.
<chiluk> probably gen 7 or 8 gpu..
<tyhicks> skylake is gen9 gpu
<tyhicks> the CPU is m5-6Y54
<tyhicks> it is in that Gen9 table on wikipedia and there are a lot of references out there that say skylakes are the first gen9 gpu
<chiluk> nope shares core bits with hd 530
<chiluk> check code name column on wikipedia.
<chiluk> it's a different sku than the hd 6xx we have
<tyhicks> I'm not arguing that
<tyhicks> I'm arguing that it is still a gen9
<chiluk> I'm saying that it's older ... 
<tyhicks> I'm actively working on another i915 bug, using that laptop, and am 100% sure that changes I make to gen9_init_indirectctx_bb() have an effect
<chiluk> I bet sforshee 's 10510u has a newer gpu than either of us.
<tyhicks> you're going to have to say something other than "nope" to convince me that it isn't a gen9 gpu :)
<chiluk> well you know more than me at this point.. 
<sforshee> yeah I guess it's actually a gen 11
<chiluk> I  just started looking at this ..
<tyhicks> well intel's mapping from model numbers to generations is confusing so I would take your word if I haven't been screwing with this other bug all day
<tjaalton> skl, kbl, cfl, cml are all gen9
<tjaalton> gpu
<tjaalton> icl is gen11
<tjaalton> gen10 (cnl, cannon lake) never really took off
<chiluk> yeah ... you can't map based on cpu model number or even age..
<tjaalton> cml and icl both have cpu models named after 10xxx
<tjaalton> which is even more confusing
<chiluk> sforshee should 1861521 be against linux-signed or linux-generic?  seems like linux-signed would only be used for secure boot issues.
<sforshee> chiluk: yes not signed, the source package will be linux-5.4
<tyhicks> sforshee: that's the source package that was ubuntu-bug picked for me
<sforshee> tyhicks: good deal, thanks for letting me know
<tyhicks> now that I think about it, I think I saw a bug report for that
<tyhicks> no, it was related but different - bug #1861446
<ubot5> bug 1861446 in apport (Ubuntu Focal) "on focal 'ubuntu-bug linux' doesn't automatically collect kernel artifacts" [High,In progress] https://launchpad.net/bugs/1861446
<sforshee> tyhicks: huh, I wonder what mechanism is deciding that 'ubuntu-bug linux' should map to linux-signed-5.4
<tyhicks> sforshee: I'm not sure - I was surprised that it mapped to anything *-5.4 so I figured it was intentional and correct
<apw> sforshee, i think it is the other way, it is using uname -r to find the linux-image-<foo> package and mapping that to linux-signed-5.4 via apt-cache
<sforshee> apw: ok, that sounds believable
<tyhicks> so that means that https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bugs?field.status:list=NEW is receiving reports but perhaps not being monitored
<tyhicks> some others in https://bugs.launchpad.net/ubuntu/+source/linux-signed-5.4/+bugs?field.status:list=NEW as well
<apw> sforshee, somewhere we have a bot which moves things to linux etc
<aberrant> hi all
<aberrant> can someone please give me some guidance around clock sources? I'm seeing extremely high drift with my eoan setup, clocksource is tsc. What recommendations do you all have?
<aberrant> my options are tsc hpet acpi_pm 
<apw> hmm, not sure i've seen anything like that; have you tried switching to hpet 
<aberrant> I haven't yet
<aberrant> my drift according to chrony is over 830 ppm
<aberrant> that seems... really high.
<aberrant> it's causing ntpd to fail, since the max drift is 500ppm
<apw> tsc drift is often seen when an older kernel is run on very new kit which has new c-states for instance
<aberrant> hpet is giving me 6ppm
<aberrant> I'm not running an old kernel, though
<aberrant> I'm running a custom one based on 5.0.x
<aberrant> on an AMD 3400G
<aberrant> but yeah, my guess is it's idle or c-states that's causing the tsc problem. Even though hpet is less efficient, I'll switch to using it.
<aberrant> ok, rebooting to check if this works. Thanks.
<chiluk> aberrant not sure if this is related..https://www.tomshardware.com/reviews/amd-ryzen-clock-bug-benchmark-scores,6312.html
<chiluk> looks like ryzen had some clock bugs in general.
<aberrant> perhaps, but I'm not OCing
<aberrant> brb though - rebooting to make sure hpet is now default
<aberrant_> ok, that worked
<aberrant> hpet is the better option for keeping drift low.
<aberrant> not sure whether the tsc drift is report-worthy, but I wouldn't even know what to put in the report.
#ubuntu-kernel 2020-02-12
<aberrant> confirmed: ntp.drift is now -6 instead of +500
<aberrant> well, that was amusing.
<aberrant> I have now thoroughly confused myself with bridging.
<apw> aberrant, heh bridging fun
<hggdh-msft> mhcerri: BTW, thank you for your quick work 
<mhcerri> hi, hggdh-msft. no problem. let me know if you find any other issues
#ubuntu-kernel 2020-02-13
<ricotz> arighi, hi :), are there going to be further kernel 5.5 builds for focal?
<arighi> ricotz, hi, you mean the unstable kernel in focal?
<arighi> ricotz, I'm currently rebasing unstable to 5.6-rc1
<ricotz> arighi, yes, the bootstrap ppa builds
<ricotz> arighi, I see, so no 5.5.3 based build?
<arighi> ricotz, oh ok, bootstrap ppa is moving to 5.6
<arighi> ricotz, right, no 5.5.3 build for now
<ricotz> arighi, is focal officially moving to 5.5?
<tjaalton> ricotz: no
<ricotz> tjaalton, arighi, alrighty, thanks!
<arighi> ricotz, focal will stick with 5.4 for now
<arighi> tjaalton, thanks :)
<ricotz> arighi, looking forward to the 5.6 build :)
#ubuntu-kernel 2020-02-14
<apw> zx2c4, you would prefer to have the latest wireguard dkms in our older series i assume yes; given your compatibility model
<zx2c4> apw: always always always have the latest
<zx2c4> Unless you provide a really compelling reason, i wont give any support to older versions
<zx2c4> So while we're before freeze, just always bunp
<zx2c4> Bump
<zx2c4> apw: DalekSec https://lists.zx2c4.com/pipermail/wireguard/2020-February/005013.html
<zx2c4> (has the fixes i pushed out for 5.6-rc2)
<apw> zx2c4, the description of that implies we should not be expecting to see it packaged as yet
<zx2c4> apw: i have no idea what you could possibly be referring to or what you even mean
<zx2c4> but just for the avoidance of doubt, go by this statement: everytime there's a new signed tarball available on https://git.zx2c4.com/wireguard-linux-compat/refs/ the wireguard-dkms package should be bumped everyplace that you can possibly bump it
<apw> Please note that until Linux 5.6 is released, this snapshot is a
<apw> snapshot rather than a secure final release.
<apw> that text says "don't put me in a distro"
<zx2c4> apw: that is a toned down version of the text that has been in every set of release notes for the last 4 years
<zx2c4> we're at v0 until 5.6 is cut. then it's v1. until then, we're releasing new snapshots with all the fixes from the various rcs from 5.6
<zx2c4> i have no plans to skimp on maintenance of the linux-compat stuff -- important to keep parity for as long as possible
<apw> zx2c4, huh, the debian package we are using is 1.x
<apw> oh that is the wireguard tools i presume
<zx2c4> Yea the tools got v1'd a while ago
<zx2c4> https://github.com/google/syzkaller/commit/c5ed587f4af5e639f7373d8ebf10ac049cb9c71b
<zx2c4> Been doing some nice fuzzing
<apw> the split being in one series and not anohter is confusing me
<zx2c4> Different packages, different versions
<apw> yep, but what i was used to was one version to rule them all
<zx2c4> Ah yea, we got rid of the monolithic repo a while ago. I sent 4 emails about that and followed up with you a few times. But you never responded until i finally tracked you down here, remember? Makes sense its confusing still because you never "lived through" the transition like the rest of the packagers
<zx2c4> But indeed thats the situation - compat repo will be v0 until 5.6. Tools repo is v1
<zx2c4> Right now there's a new compat release every rc 
<zx2c4> Thatll probably slow down to every mainline release after 5.6
<zx2c4> Unless security etc
<zx2c4> Also after focal freezes, if there is security stuff, ill be sure to let you know in here
<apw> zx2c4, yeah i am aware, i just managed to ignore the knowledge when looking at rmadision output
<apw> zx2c4, if it is serious you can come to me privatly too
<zx2c4> idunno
<zx2c4> ive full disclosured so many security vulns
<zx2c4> seems like it'd be a weird twist of irony of i started getting secretive about my own stuff :-P
<apw> zx2c4, heh, as you will
<zx2c4> s/"disclosured"/disclosed
<zx2c4> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d114b9fe78c8d6fc6e70808c2092aa307c36dc8e like putting exploit code in commit messages...
<zx2c4> the most coordinated of coordinated disclosure :D
#ubuntu-kernel 2020-02-15
<DalekSec> zx2c4: I wanted to wait until the Debian upload so we can get the new reload stuff.
<zx2c4> DalekSec: yea id like that too
<zx2c4> Has dkg finished that?
<DalekSec> zx2c4: https://salsa.debian.org/debian/wireguard-linux-compat/commits/debian/master shows nothing, don't see any merge requests either.
<DalekSec> Hah, Debian #951157 sure is useful. :P
<ubot5> Debian bug 951157 in wireguard-dkms "wireguard-dkms: DKMS make.log for wireguard-0.0.20200205 for kernel 5.3.9-sunxi (armv7l)" [Serious,Open] http://bugs.debian.org/951157
<zx2c4> DalekSec: issue is with his kernel headers package
<zx2c4> The included tools were compiled for the wrong platform
<zx2c4> Or not included at all
<DalekSec> I figured, but man that bug body is pretty poorly done. >_<
<zx2c4> Thats a dkms thing and not a wg thing
<zx2c4> Yea...
<DalekSec> Geez, between this and the guy from the other day that had a 5.5 kernel on Ubuntu compiled with gcc9 or something..Stick with distro kernels. >_<
<zx2c4> DalekSec: dunno, distro kernels are pretty out of date often so i dont assign too much blame there
<zx2c4> speaking of which, wanna do the debian bump for dkg?
<zx2c4> or did you want to wait for him to [someday] fix the broken module reload behavior?
<DalekSec> I'd be waiting on the module reload stuff, yeah.
