#ubuntu-kernel 2006-01-16
<zul> heylo
* ..[topic/#ubuntu-kernel:irc.freenode.net] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-11.16 uploading (The "Real 2.6.15" release, AKA The "If-Anything-Breaks-Its-Our-problem-Now" Release)
* #ubuntu-kernel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<zul> heylo
<fabbione> hi zul
<fabbione> BenC: ping?
<BenC> hey
<fabbione> yo
<BenC> responding to pitti now
<fabbione> BenC: yes i saw the mail and answered
<fabbione> i am going to take off for a week
<fabbione> so i can't do it
<BenC> ok
<BenC> dapper is pretty squared away except for one
<fabbione> yeah
<fabbione> but it's a good idea to always double check
<fabbione> it won't the be first time that something pass unseen
<mjg59> BenC: Intel 3945 drivers should be appearing at some point, but probably not until end of Feb/beginning of March
<fabbione> or that something that's supposed to be vulnerable is not
<BenC> fabbione: I checked dapper source tree for the ones that are supposed to affect it, and the code is patched
<BenC> also, the last one that affects hoary/warty may be irrelevant, since it only applies to numa configurations
<fabbione> BenC: we still want the source to be patched tho
<fabbione> we don't know if somebody is using our sources on NUMA
<fabbione> even if i seriously doubt it
<dilinger> BenC: so the dapper kernel is pretty much finalized?  time for me to start playing around w/ it on machines for testing purposes?
<BenC> dilinger: finalized isn't a good word
<BenC> it's stable though
<dilinger> ok
<BenC> and you should have been testing it all along :)
<dilinger> i'll give it a week ro two, then
<dilinger> heh.  well, the machines i have to test with, some i would rather not have to recover
<BenC> fabbione: oh, I found out that the -server kernel crash is caused by alt-smp...if I disable that, it boots fine...trying to find the cause now
<dilinger> like my laptop
<fabbione> BenC: ah cool
<BenC> so far no one has reported that dapper totally broke their system
<BenC> dilinger: I suggest trying a livecd boot, and if that works, upgrade
<dilinger> well, i was just going to try the kernel and a few other packages, w/ a breezy system
<dilinger> i don't really want to upgrade completely to dapper
<dilinger> not until i become a developer and can actually fix broken stuff.. filing bugs that sit in the BTS isn't all that fun
<fabbione> dilinger: you will pull in too much
<fabbione> better you become a developer and fast :)
<dilinger> i have a server running breezy w/ a dapper rc(4?) kernel, plus dapper udev
<BenC> fabbione: oh, and I found out that alt-smp wasn't completely enabled on x86_64
<fabbione> BenC: is that why my k8 dies on heavy load?
<BenC> the lock's were getting nop'd, but the complex smp (spin_lock's) weren't getting nop'd
<BenC> is it up and smp?
<BenC> up or smp I mean
<fabbione> it's up, but it just slows down hell of a lot
<fabbione> it takes a bit and resurrect again
<fabbione> swap usage is impressive
<BenC> could be
<fabbione> and i am blaming the kernel for that
<fabbione> since .12 works fine :)
<BenC> you would :P
<fabbione> ahhah
<fabbione> BenC: we might be soon able to blame gnome :)
<fabbione> http://blogs.gnome.org/view/cneumair/2006/01/10/0
<fabbione> there
<fabbione> see
<fabbione> data loss? i blame gnome!
<fabbione> reiserfs4 not working? i blame gnome!
<fabbione> WE CAN BLAME GNOME!
<fabbione> that's the best part :P
<crimsun> BenC: any particular reason we don't enable CONFIG_USB_SUSPEND?
<mjg59> crimsun: Because we don't use it anywhere
<crimsun> mjg59: ok, I've just read a hint that the ehci-hcd errors post-resume (after a suspend) may be tied to it
<mjg59> crimsun: Right now we unload and reload the modules
<crimsun> mjg59: it only rears its head post-resume after a suspend, though
<crimsun> post-resume after a hibernate doesn't exhibit the problem at all
<crimsun> (mm, post/after redundancy)
<crimsun> will debug further after lecture
<BenC> fabbione: I think I have the -server crash fixed, testing in a minute
<fabbione> BenC: cool!
<fabbione> BenC: i need to push some cluster changes tomorrow. i would love to have them with the next kernel
<zul> heylo
<fabbione> hey zul
<zul> hey fabbione how is it going?
<fabbione> zul: as usual
<zul> fun fun
<BenC> fabbione: -server crash is fixed
<fabbione> BenC: rocking
<BenC> which may also fix crashes in amd64 and 686/k7
<fabbione> fabbione BenC: i need to push some cluster changes tomorrow. i would love to have them with the next kernel
<fabbione> * BenC has quit (Read error: 104 (Connection reset by peer))
<fabbione> not sure you got that
<fabbione> -4 to conf call
<BenC> ok, the sooner the better
<BenC> I was ready to do a build/upload, but I can hold off till tomorrow
<fabbione> tomorrow i can do it.. i am waiting them to commit to their CVS 3/4 of our patches
<fabbione> so we can drop them 
<fabbione> specially there is a gfs fix we want in .15 due to some changes upstream
<zul> BenC: did you have a look at my patches?
<BenC> (conference call, brb)
<zul> okie dokie
<Zomb> hi
<Zomb> do recent linux-image packages still suggest lilo?
<zul> grub is more commonly used
<zul> and the default
<infinity> (base)adconrad@cthulhu:~$ apt-cache show linux-image-2.6.15-11-686 | grep ^Suggests
<infinity> Suggests: lilo (>= 19.1) | grub, fdutils, linux-doc-2.6.15 | linux-source-2.6.15
<infinity> Yes, they still suggest it, as they always have.
<makx> well that can change :)
<makx> once we don't loose *all* energy in firmware discussions
<dilinger> this firmware thing is going to be a disaster...
* dilinger  intends to ignore the entire thing
<zul> hmmm..?
<dilinger> zul: nothing..
<makx> it is already a disaster dilinger
<tomukas> hi everyone, i have a wlan-problem with ipw2200 and syslog is saying: Radio Frequency Kill Switch is On, which means that it can't work at all... any ideas?
<zul> so uh we have to use malone now?
<mjg59> tomukas: Is there a physical switch on your laptop?
<tomukas> yes
<tomukas> mjg59: there is one... and there is activity in syslog after having switched it
<mjg59> tomukas: Right. If it's in the correct position, then things should work
<tomukas> mjg59: probably it's not... it seems that there is not yet a support for that wlan-device yet... but which command should this switch run?
<zul> uh yes there is support for ipw2200
<mjg59> The switch shouldn't run any command. It just disables or enables the radio.
<tomukas> yes - but that doesnt work :-\
<tomukas> kthxbye, guys... have to reboot
* lamont wonders what all he needs to install from dapper to run the dapper 2.6.15 kernel
<mdz> BenC: ping
#ubuntu-kernel 2006-01-17
<fabbione> BenC: please pull from my repo on people: changes are only redhat-cluster-suite related.
<BenC> fabbione: ok
<fabbione> BenC: thanks
<fabbione> BenC: ping?
<zul> heylo
<BenC> fabbione: pong
<fabbione> BenC: yo
<fabbione> BenC: is there any reason why ia64 has no OCFS2?
<fabbione> also.. for i386/amd64 it should probably move to -server only
<fabbione> it doesn't make much sense to have it in desktop :)
<fabbione> BenC: note that OCFS2 pulls in CONFIGFS
<fabbione> so they need to move together
<fabbione> i did try to play with the config script but it did mess up here
<fabbione> so i wasn't sure how to make it properly
<fabbione> well.. other than with vi
<BenC> fabbione: I'll enable it for ia64 (not sure why it isn't), and get things moved to just -server on i386 and amd64
<BenC> OCFS2 needs to move, what about cluster aswell?
<fabbione> BenC: you rock!
<fabbione> cluster too
<fabbione> cluster moves together with GFS
<fabbione> as it is now, for me it's more important to get a coherent config where i can install one kernel on each arch and get GFS and OCFS2
<fabbione> we can sort them at the sprint in details
<BenC> ok, so all desktop kernels (in i386 and amd64 where we have server kernels) should have GFS, CLUSTER and OCFS2 disabled
<BenC> is CONFIGFS needed in desktop after that?
<BenC> it may end up being needed by a thirdparty module, so maybe just leave it there
<fabbione> as it is now, the only client for CONFIGFS is OCFS2
<fabbione> i think what you suggest make sense afterall
<BenC> ok, done
<BenC> btw, benh sent me a patch to support dual-core G5's and iMac G5 with isight
<BenC> backported from 2.6.16-git
<fabbione> ah cool
<fabbione> Mark will like that :)
<zul> whats the url for live cds again
<fabbione> cdimage.u.c/
<zul> thanks i knew it was something like that it just escaped me ofr  a minute
<BenC> is it hoary -> warty -> breezy, or warty -> hoary -> breezy?
<fabbione> the latter
<BenC> ok, thanks
<fabbione> warty -> hoary -> breezy
<fabbione> whorey -> (w)horey -> 
<BenC> starting dapper test builds, and working on security for those three while it's going
<BenC> hehe
<fabbione> ehhe
<fabbione> BenC: i have the old breezy binutils in my ~ on chinstrap
<fabbione> i hope i can manage to do to test kernels tomorrow
<fabbione> otherwise it will be when i am back
<BenC> bcollins@grayson:~$ build-start-all
<BenC> green: build started
<BenC> emucade: build started
<BenC> zachery: build started
<BenC> frag: build started
<BenC> hippo: build started
* BenC loves his build scripts
<fabbione> nice
<fabbione> isn't missing one?
<fabbione> 6 arches...
<BenC> I don't have amd64, and I haven't setup  ronne yet
<fabbione> ah ok
<BenC> those are ppc, i386, sparc64, ia64, hppa, in that order
<fabbione> i think you should push i386 to ronne, ppc to davis and ia64 to halley
<BenC> sparc64 always finishes first :)
<fabbione> and keep only sparc64 and hppa
<fabbione> speaking of zachery..it did crash on me twice building OOo2
<BenC> I build them locally, since I also test boot them when I'm done, and doing 80-100 megs download after it's finished doesn't play well with my satellite FAP crap
<fabbione> hmm right
<fabbione> but on the other side we should publish these images at some point
<BenC> all of them builds pretty quick, except i386
<zul> BenC: ooh share the script..
<BenC> these are going to be 2.6.15-12, so they'll get published within a day :)
<fabbione> ehhe
<BenC> zul: it's just a couple of shell scripts, really simple
<BenC> starts a screened build on each machine
<BenC> I can tar them up at some point
<zul> yeah but i want to incorporate yours with mine..;)
<fabbione> zul: let's do the other way
<fabbione> give us your
<fabbione> and we will integrate into ours :)
<zul> sure
<BenC> build-{prep,start,status,stop,watch,attach}{,-all}
<BenC> that's all of them
<BenC> I can do "build-prep green" to clean the build, and push git, and build-watch just tails, build-attach attaches to the screen session
<BenC> watch,attach don't have a -all obviously
<BenC> build-prep also checkes for local changes that I might have done on the build system
<BenC> keeps me from losing fixes :)
<fabbione> ehhe
<zul> right now i have 2 scripts..
<BenC> none of mine are any longer than 10 lines, but I do have a do_build script on each machine so that it will set the right concurrency and stuff (still less than 10 lines)
<zul> first one reads a config file to pull from and the second scripts does the build, rips out the arches that i dont want
<fabbione> later guys
<BenC> later fabio
<fabbione> BenC: meh i forgot to add stuff to debian/changelog
<fabbione> do you want to do that for me?
<fabbione> it's just the update for the redhat cluster suite
<fabbione> to 20060112 CVS
<fabbione> nothing fancy
<fabbione> gotta run to school
* fabbione &
<BenC> ok
<fabbione> cheers mate
<BenC> fabbione: ping
<Seveas> --- Topic for #ubuntu-kernel is Ubuntu kernel development discussion ONLY
<Seveas> is a question about the kernels used on Ubuntu, which is not directly related to kernel development OK too?
<Mithrandir> Seveas: don't ask to ask
<Seveas> Mithrandir, hehe, y'never know how strict they are in here
<Seveas> ok, here's the deal: somewhere between 2.6.10 and 2.6.12 mmap changed and now returns 'random' addresses (ie cat /proc/self/maps is always the same in 2.6.10 and always different in 2.6.12). Can someone point me to where this change is documented? 
<Seveas> It severely ruins my graduation project and the things I've been working on during the last 15 months
<zul> you can probably do a git bisect but dont ask me how to do one
<dilinger> http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.12-rc1
<dilinger> i assume what you're looking for is "mmap rand"
<Seveas> dilinger, yes, thank you!
<dilinger> np
<Seveas> will prelink also make sure ld.so is always in the same location in memory?
<dilinger> the comment seems to imply that prelinked binaries will not have randomized mmap base addresses
<dilinger> however, the ADDR_NO_RANDOMIZE thing is probably what you'd want if you're looking to disable it
<Seveas> then I would have to prelink ld.so itself
<Seveas> hmm, then I'll have to look up what personalities are
<dilinger> are you seeing ld.so at random addresses?
<Seveas> yes
<Seveas> and my application kind-of depends on the fact that that does not happen
<dilinger> i'm not sure if you can PRELINK ld.so, but i guess it couldn't hurt to try
<Seveas> hmm, how do personalities work in debian/ubuntu? apt-file search setarch returns only something completely unrelated
* ds discovers that /proc/acpi/button/lid/LID/state says "closed" when the lid is open
<zul> ds: which laptop?
<ds> EMachines M5312
<ds> zul: do you happen to know if this is a kernel bug, or just a ACPI stupidity that needs to be worked around?
<zul> i dont get the same with my laptop you might want to open a bug..
<zul> or just acpi stupidity
<dilinger> Seveas: *shrug* :)
<cjb> ds: The kernel doesn't keep an exhaustive list of ACPI weirdnesses.  I'd say it's unlikely to be a kernel bug, but go ahead and file it.
<mjg59> ds: Windows doesn't use that information, so some machines just lie
<cjb> Coo, it doesn't?  "Let me guess, it handles lid closing in the video driver."
<mjg59> Oh, it picks up the lid events, but yeah - the video driver is responsible for what happens next
<Seveas> hmm
<Seveas> kinux-kernel-headers is at 2.6.11 on breezy
<mjg59> linux-kernel-headers
<Seveas> yes :)
<Seveas> but it's still weird that it's at 2.6.11
<Seveas> <dilinger> however, the ADDR_NO_RANDOMIZE thing is probably what you'd want if you're looking to disable it <-- yes, that worked perfectly!
<Seveas> dilinger, muchos gracias, you just saved my graduation project :)
<zul> dilinger: arent you special ;)
<Seveas> more importantly: you saved me having to run my experiments on a crappy old red hat cluster with linux 2.4.1, Now I can continue at the spiffy new sarge HPC cluster :)
<Seveas> saved me from*
<dilinger> hehe
<dilinger> one of these days, i should get myself one of those college degree thingies
<zul> you can probably buy one 
<Seveas> I have several offers in my mailbox if you're interested ;)
<Seveas> they come included with fake rolex and penis enlargements 
* BenC is glad no on ever asks him if he has a degree
<dilinger> BenC: my current employer was pretty surpised that i didn't have a BS
<dilinger> but that didn't stop them from hiring me
<BenC> the only time I was ever asked about it was a guy from Sun that I sent my resume to about 4 years ago
<BenC> he actually called me, to tell me that I was wasting my time with "all this open source stuff", that I should switch to applications development instead of embedded/kernel work, and that he pretty much wouldn't hire me, even at a measly $24k/year (when I was making way more than that already), and that I better go get a degree from a major college (not just a degree, but an ivey league degree), else I was doomed to be a loser
<dilinger> i'm planning on going back to school soon, but it won't be for CS
<dilinger> i'm going to do it for the right reasons this time: girls.
<mjg59> dilinger: An excellent plan
<BenC> and I'm not kidding about any of that, it's exactly how he put it
<mjg59> BenC: Aw GROUP HUG
<dilinger> going to school thinking i'd get an education was a huge letdown
<BenC> dilinger: that's my only regret about not going to college :)
<dilinger> BenC: i would've hung up on him if he started telling me that
<BenC> mjg59: see, open source is good...I have a support group :)
<mjg59> PhDs are great in that respect
<dilinger> "stop wasting my time.  *click*"
<mjg59> Actualy, it might just be mine
<BenC> you have a PhD?
<mjg59> It's my day job
<BenC> now PhD's are something to brag about
<mjg59> I'll be finished in about a year with a bit of luck
<mjg59> But it means I get to be old and mature and have a larger disposable income while surrounded by undergrads
<BenC> most CS BS degree holders that I met outside of open source, are just a joke
<mjg59> Oh, I'm doing genetics, not CS
<BenC> mjg59: undergrads :)
<BenC> genetics, that's an interesting departure from ACPI :)
<mjg59> I find ACPI an interestig departure from genetics
<mjg59> It makes more sense than fruitflies do
<BenC> lol
<BenC> what is your thesis on?
<mjg59> No matter how much crack somebody was on when they designed a specification, it makes more sense than real life does
<mjg59> Computational locating of RNA elements involved in gene localisation
<dilinger> mjg59: at my prior job, i had to do a lot of interviews.  people w/ CS degrees were a dime a dozen, and in most cases weren't worth hiring.  there were also people w/out degrees, but w/ more real world experience, that seemed a lot more valuable
<dilinger> er, s/mjg59/BenC/
<BenC> dilinger: one good thing about open source, you don't need to ask for paper to find out if someone is clueful, just search google
<dilinger> BenC: i need to do something about my blog coming up as the first entry when you search for my name :)
* cjb has a CS degree, which was valuable only to the extent that understanding Unix is about three years worth of a full-time job, and it gave me the time to do that.
<kozz> I have tried to run mkvmlinuz with the 2.6.15 kernel, but there seems to be some files missing
<BenC> heh, my old DPL candidacy letter comes up when you search mine name...I'm embarrased to see it anymore :)
<kozz> for 2.6.12 they lie in /usr/lib/linux-image-2.6.12-10-powerpc
<kozz> some object files
<BenC> kozz: yeah, the build process didn't include them anymore, but I didn't think we had any oldworld users (since we didn't even support oldworld install)
<kozz> BenC: it's for Pegasos
<BenC> is pegasos CONFIG_PPC_MAPLE?
<kozz> no, CHRP
<mjg59> Pegasos is CONFIG_PPC_CRACK
<BenC> ah, good, MAPLE is going away
<mjg59> But yeah, it's basically CHRP
<BenC> kozz: sorry, I'm having a hard time keeping non-standard (e.g. non-powermac) support because of all the ARCH=powerpc changes in the kernel
<kozz> mjg59: basically?
<BenC> but anyone with such a system is more than welcome to send me patches to get the build to do the right thing
<mjg59> kozz: Some of the interrupt setup stuff seemed a bit funny
<kozz> BenC: I see, I have tried to create them but hasn't managed to do it
<mjg59> It never booted with the stock kernel CHRP support
<kozz> stock kernel CHRP? it has always worked to boot the zImage.chrp kernel out of the box before
<mjg59> kozz: With kernel.org source?
<kozz> yes
<mjg59> Uhm.
<kozz> supported since 2.6.11
<mjg59> Right
<mjg59> Sorry, I meant "Never used to boot"
<mjg59> It needed some specific patches because some of the setup code is different
<kozz> yes I know
<kozz> but that is not the case anymore ;)
<mjg59> Right
<mjg59> But it always seemed "mostly CHRP" rather than "CHRP"
<kozz> right, I don't know
<kozz> hmm, now BenC left
<kozz> but how did it work before to create all those files, for the 2.6.12 kernel I mean
<fabbione> BenC: pong
<BenC> fabbione: nm
<fabbione> BenC: ok :)
<BenC> I have breezy/hoary/warty ready, just waiting on the last CVE from pitti
<fabbione> BenC: ok cool
<BenC> green: building
<BenC>     building: powerpc-smp(modules)
<BenC>     unbuilt : powerpc
<BenC>     unbuilt : powerpc64-smp
<BenC> emucade: building
<BenC>     building: server-bigiron(modules)
<BenC>     unbuilt : server k7 686 386
<BenC>     unbuilt :
<BenC> zachery: idle
<BenC> frag: idle
<BenC> hippo: idle
* BenC builds his scripts out to be a little more robust
<fabbione> nice
<BenC> first unbuilt should be built, but no matter
<fabbione> oh i see
<hile> I just filed a trivial bug for 2.6.15-x kernels, #22351 
<hile> just wanted to ask if there is any reason _not_ set number of UARTs from 4 to 8 (see bug for details)
<makx> you don't want to spam the user with useless tty's
<makx> post 2.6.15 it's a boot variable
<hile> already with current builds, or later? ok, I'll close the bug then
<hile> thanks anyway ;)
#ubuntu-kernel 2006-01-18
<hile> hmpf, as you said it's _post_ 2.6.15, so actually not working in dapper yet
<hile> well, whatever
<lucasd> what version of gcc will be used to compile the kernel in Dapper?
<crimsun_> Linux version 2.6.15-11-686 (buildd@vernadsky) (gcc version 4.0.3 20051204 (prerelease) (Ubuntu 4.0.2-5ubuntu2)) #1 SMP PREEMPT Wed Jan 4 06:48:37 UTC 2006
<lucasd> crimsun, thanks a lot!! ;-)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-12.17 uploading (I have no clever code name)
<infinity> No clever code name?  Suck.
<fabbione> morning
<fabbione> eheh
<crimsun> it'd be awesome if CONFIG_9P_FS were modularised, too, but I won't cry if I have to build it manually.
* infinity uploads LRM.
<fabbione> BenC: thanks for fixing the Kconfig entry.. it totally went out of my mind
<Kamion> anyone doing a linux-meta upload for 2.6.15-12, or shall I roll one?
<Kamion> oh, sod it - done and ready to go as soon as l-r-m hits NEW
<Kamion> l-r-m/i386 that is; amd64/powerpc are through
<Kamion> uploaded
<BenC> thanks
<BenC> fucking right
<BenC> 12 hours connected to IRC without a reconnect :)
* BenC declares bcm43xx stable
<mjg59> Hurrah
<mjg59> BenC: nsc-ircc seems to have a problem. When it registers as a pnp device, it seems to register its io ports. It then attempts to do so again in nsc_ircc_open and fails
<BenC> yeah, I've noticed that
<BenC> been on my todo list
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-12.17 uploaded (I have no clever code name)
<fabbione> hey BenC 
<fabbione> can you please pull from me again?
<BenC> sure thing
<fabbione> i did fix the Provides: rhcs-modules-*
<fabbione> to actually provide it only for the flavours that have them :)
<BenC> ah, good plan :)
<fabbione> i was thinking to do the same for ocfs2
<fabbione> but i didn't decide yet
<fabbione> we can do that later on
<zul> heylo
<zul> fuck fuck fuck
<BenC> fuck?
<zul> stupid code..
<zul> BenC: you didnt merge my stuff yet?
<BenC> not yet
<zul> aiieeee..
<BenC> zul: where did you get the fix for timer_irq_works?
<BenC> the fast clock for ATI+nforce mobo's
<zul> lkml
<BenC> from the bug report, I don't see that they confirmed the fix
<zul> yeah it doesnt..and i think there is a patch out that removes the pin option as well i dont think it got merged yet
<BenC> then what does the patch fix? :)
<zul> it was a test actually..it might fix some other users system
<BenC> do you have a link to the thread where this patch was introduced
<zul> yeah let me check
<zul> i think i have it booked mark on my home pc ill check when i get home tonight
<BenC> ok
<zul> they cant have switches noooooo......bastards!!
* zul must vent
<zul> BenC: http://lkml.org/lkml/2006/1/4/156
<BenC> zul: ok, patch looks good
<BenC> zul: merged
<crimsun> BenC: thanks for merging the ipw2200 patch
<mdz> BenC: is the comment in #8586 accurate, regarding swsusp and highmem?
<BenC> mdz: not sure
<BenC> let me check on it real quick
<BenC> mdz: sounds kind of screwy to me though
<mdz> BenC: yeah, didn't we switch the default 386 kernel to highmem in breezy?
<BenC> mdz: to me it sounds like that there is probably a driver that doesn't work well with highmem, more than swsusp not doing so
<mdz> and swsusp didn't suddenly break for everyone
<BenC> CONFIG_HIGHMEM4G is enabled on 386 kernel
<BenC> I don't think that it's highmem enabled, but if they have highmem actually being used (> ~890Megs)
<BenC> which isn't likely on a laptop :)
<BenC> how did bugzilla get a comment that wasn't merged to the malone bug?
<GoRoDeK> hi, how to obtain a list of changes/settings between the kernel revisions made for ubuntu?
#ubuntu-kernel 2006-01-19
<zooted> hello, is anyone active here?
<zooted> I am trying to patch the 2.6.12 ubuntu kernel source with Rick van Rein's BadRam patch and can't figure out how to get the ubuntu-patches applied to the source.
<zooted> Any tips?
<BenC> there's a howto on the wiki I think
<zooted> BenC:  The howto does not address the patch issue and I'm not clear on whether the 2.6.12 source package is already patched or not.  I can shove the BadRam code into the source tree, it is just that I am not sure if all the security patches are already in place.
<vbhanu> to implement a filesystem where should one start from....some guides.....i know the concepts i want some guide which would take me through the code...as to how to basically implement in terms of code
<BenC> vbhanu: best docs are existing code, try some of  the simpler filesystems like cramfs
<vbhanu> BenC : thanks
<doko_> fabbione: after changing /boot/grub/device.map, the grub/menu file still uses the old 'root' parameter. what do I need to change else?
<crimsun> doko_: what about the kopt= line in /boot/grub/menu.lst?
<crimsun> and did you update-grub afterward?
<doko_> crimsun: I did run install-grub
<doko_> s/install-grub/grub-install/
<doko_> hmm, and it does insert again the string vga=0x384, which doesn't work for me, and should be disabled ...
<plasma> infinity BenC anyone there?
<plasma> i've got a problem with loading ipw2200 on my dell latitude d610
<fabbione> doko_: grub-install is only to install the MBR
<fabbione> you need to use update-grub 
<fabbione> but first you need to edit menu.lst to match your new setup
* BenC is waking up
<plasma> hi BenC 
<BenC> hello
<plasma> BenC: so, can you help me with that? when i boot the systems, i have an interface "ng" for the wlan. but then it crashes and the interface and the ipw2200 module are gone
<infinity> I'm not sure if BenC even has an ipw2200.  I'll probably have to help you out with it, but tomorrow... (It's 3am here in Melbourne)
<infinity> BenC: Also, have you already done a git pull to ipw2200 1.0.10, to grab their bugfixes? :/
<plasma> ok, good point *g* here in germany it's 5pm ;)
<crimsun> infinity: he's already merged it. I sent it.
<infinity> plasma: I have some family dinner business tomorrow, but I'll be around in around 15 hours (ish), if you want to do some debugging then.
<infinity> plasma: Otherwise, it'll have to wait until Monday, when I'm "on the clock" again.
* infinity heads to bed for now.
<plasma> ok, bye
<crimsun> plasma: are you running Dapper's 2.6.15-12.17?
<BenC> BenC: yes
<plasma> crimsun: no, i'm running breezy's 2.6.12-9-386
<crimsun> plasma: ah
<infinity> Oh.
<infinity> If it's Breezy's kernel, I'll let Ben handle it.
<infinity> :)
<plasma> ok *g*
<infinity> (Cause, y'know, it Works For Me(tm))
<Mithrandir> BenC: current dapper, amd64, dualcore goes boom when I ifup an skge interface.
<Mithrandir> BenC: hard lock
<BenC> can you try a sysrq?
<Mithrandir> BenC: actually, it kills X(!)
<Mithrandir> or at least keyboard input in X.
<Mithrandir> seems to work fine from the console
<BenC> weird
<BenC> maybe it's dbus?
<BenC> brb
<doko_> fabbione: that doesn't work. saved the old menu.lst, then did an update-grub:
<doko_> --- menu.lst.old        2006-01-14 14:47:21.000000000 +0100
<doko_> +++ menu.lst    2006-01-14 18:37:11.000000000 +0100
<doko_> @@ -102,33 +102,33 @@
<doko_>  ## ## End Default Options ##
<doko_>  title          Ubuntu, kernel 2.6.15-12-amd64-server
<doko_> -root           (hd0,0)
<doko_> -kernel         /boot/vmlinuz-2.6.15-12-amd64-server root=/dev/sda1 ro quiet splash
<doko_> +root           (hd1,0)
<doko_> +kernel         /boot/vmlinuz-2.6.15-12-amd64-server root=/dev/sda1 ro vga=0x384 quiet splash
<doko_>  initrd         /boot/initrd.img-2.6.15-12-amd64-server
<doko_>  savedefault
<doko_>  boot
<doko_> where does it get these old values from?
<doko_> and: is there a way to change the order of hard disks? in the BIOS boot order it's 3ware-controller / sata controller / ata controller.
<doko_> BenC: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01300.html
<zul> heylo
<kozz> hmm, guys I need some help... can't really understand the layout of the 2.6.15 kernel
<kozz> seems to be a lof of differences from the vanilla 2.6.15 kernel from kernel.org
<kozz> an ordinary kernel creates a zImage.chrp file but the ubuntu kernel do not
<kozz> while the 2.6.12 ubuntu kernel did
<kozz> the menus in in menuconfig about chrp also seems to be different, how to I create a ordinary chrp kernel?
<kozz> btw, where can I find the patches? there is not directory debian/patches
#ubuntu-kernel 2006-01-20
<zul> hey...how do you close a bug in launchpad?
<jag_fsf> evening, all.
<jag_fsf> anybody have any success/desire to help me compile a kernel module against the breezy kernel?
<jag_fsf> i'm trying to get the poldhu wireless driver working...
<jag_fsf> and i have to say i'm having quite limited success...
<jag_fsf> oh wait, wrong channel.
<jag_fsf> sorry.
<kozz> hmm, didn't get any answer the other day about chrp and 2.6.15, but can you please at least tell me where the patches for 2.6.15 are located? can't find them
<BenC> kozz: apt-get install linux-source-2.6.15
<BenC> kozz: or better yet, read the topic and get the git repo
#ubuntu-kernel 2006-01-21
<tkup> how do you create a /proc/sys entry in a kernel module. proc_register(&proc_root, &my_proc_entry) creates one in /proc
<mjg59> BenC: prism54usb is supposed to be moving to softmac
<mjg59> BenC: So if we can get that in, it would be great
<mjg59> Oh, and prism54softmac seems to drive full prism54 hardware as well
<BenC> ah, nice
<mjg59> Possibly best to contact Jean-Baptiste to find out what's going on there
<mjg59> There's almost no publically available information
<mjg59> BenC: Checking Jean Tourrilhes's list, it looks like we have every currently available wireless driver (with the possible exception of the prism54usb stuff)
<mjg59> Oh, and the Realtek stuff
<mjg59> (Which you pulled because it was broken)
<mjg59> Nngh. The Realtek stuff is still some weird other ieee80211 stack derived thing
<BenC> great, latest bcm43xx driver seems to be using stuff that isn't available in softmac/ieee80211
<mjg59> You're pulling the git tree for that now?
<mjg59> (They moved away from mercurial)
<BenC> oh, did they?
<mjg59> Yeah
<mjg59> Might explain it :)
<BenC> yeah, definitely
<BenC> thanks
<BenC> gonna have to go with their daily snapshots...they are following linus tree now
<mjg59> Nnngh. The rtl8180 stuff /still/ looks like pain
<mjg59> Would probably be easy to port to softmac
<mjg59> Gah, fuck, yes.
<mjg59> It conflicts with the in-kernel stuff
<mjg59> Stupid, stupid thing
<mjg59> BenC: Still around?
<BenC> yeah
<BenC> just updated bcm43xx/softmac drivers on pb to test it
<BenC> seems to be ok, but still only stable at 11M
<mjg59> BenC: I've figured out a way to deal with rtl8180
<mjg59> But I'm not sure you're going to like it
<mjg59> Grab the newstack and their custom ieee80211 code
<mjg59> Then (and this is the tricky bit)
<BenC> sed?
<mjg59> sed -i s/ieee80211/rtl_ieee80211/g *.c *.h
<mjg59> Indeed
<mjg59> It seems to work - their 80211 stack is entirely independent from the kernel one
<BenC> well, I could just remove all the EXPORT_SYMBOLS and compile the ieee80211 stack into the module
<mjg59> Nnf. Yeah, I guess.
<mjg59> I'm not sure if that's any cleaner.
<mjg59> Fucking insane.
<BenC> so how hacked up is their ieee80211 stack?
<mjg59> Not /very/, but it's based on a fairly ancient checkout
<BenC> softmac has some hacking in the stock ieee80211 stack now
<BenC> but it doesn't appear to break things
<mjg59> Nowadays it should just be ported to softmac instead, but that's going to take a little while to look at the driver
<mjg59> BenC: Actually, keeping it modular is probably more sensible
<mjg59> That way we can get the 8187 (USB) driver as well
<BenC> true
<mjg59> Now all we need is an Inprocomm driver
<mjg59> BenC: Hmm, no. prism54usb still seems to need its own madwifi-based stack.
<kozz> BenC: and then in the directory debian/patches? the thing is that that directory do not exist
<BenC> kozz: that's because there are no patches, everything is applied in the tree
<kozz> right, can I find them somewhere?
<BenC> sure, download linux-2.6.15.1.tar.bz2 and diff it
<BenC> there are no seperate patches
<BenC> it's all in the tree
<kozz> seems like a strange solution, but ok, thanks
<mjg59> BenC: Another one for you - http://www.saillard.org/linux/mrv8k/files/
<mjg59> (Marvell lala driver, seems to be used on some Asus boards)
<zul> heylo
<zul> heylo...again
<Mithrandir> BenC: *sigh*, my nvidia problem seems to have gone away, magically. :-/
<BenC> sweet :)
<Mithrandir> I'll see if I can make it come back somehow.
* lamont asks for objections prior to uploading klibc_1.1.16-1ubuntu1
<lamont> hrm.. first a word from our sponsors
<BenC> lamont: do builds logs for *-security still go to your buildLogs url?
<lamont> BenC: no
<lamont> never have
<BenC> where can I find them?
<lamont> ask me or infinity nicely
<lamont> the issue is that the -security builds are (generally) embargoed fixes
<lamont> hence we don't publish them
<BenC> just need to watch linux-source-2.6.{8,10,12} builds I just uploaded
<lamont> well, watching never works anyway... - the log only shows up once the build is finished...
<lamont> but I can certainly take a gander for you
<BenC> well, that's what I meant :)
<BenC> probably too soon to see anything
<BenC> unless they failed really early
<zul> BenC: i have some new crack for you
<zul> ill put it in my tree tonight
<BenC> ok
<zul> just the rt2600 dirver and other bits
<lamont> module ipv6 relocation of symbol in6_dev_finish_destroy is out of range (0x3ffeff7c in 17 bits)
<lamont> ew
<lamont> hppa report: 2.6.15-12.17 + klibc_1.1.16-1ubuntu1 booted.
<lamont> BenC: does the ipv6 module get built with a massive (or series of) ld -r commands?
<BenC> not sure
<lamont> if so, that would explain the problem.
<lamont> (binutils borkage for hppa)
<BenC> is klibc working for ia64 yet?
<lamont> BenC: that's the next test...
<lamont> dist-upgrading my ia64 box to dapper is going to work,right???
<zul> hehe..
<lamont> hrm... ia64 runs elilo at upgrade time, but asks the user (outside of debconf) whether or not to run it.. --> bug
<BenC> lamont: elilo needs to be run for update-initramfs too, which is something that doesn't happen right now (probably doesn't for lilo either)
<lamont> BenC: it's more that it needs to not ask.
<BenC> yeah
<BenC> yaboot doesn't ask, it just does
<BenC> same with grub
#ubuntu-kernel 2006-01-22
<zul> heylo
<psusi> why can I never get the latest snapshot patches to apply to the latest stable release from kernel.org?
<crimsun> 15-git12 to 15.1 ?
<psusi> yea
<crimsun> well, no doubt 15-git12 already has the backported parts in 15.1
<psusi> well what did they diff against to get the 15-git12 patch?  that's what I should be applying it to
<crimsun> 15
<psusi> how annoying.... you'd think if they only provide the latest snapshot as a diff, it would be a diff against the latest stable
<crimsun> it used to be listed as usch
<zul> BenC: new crack for you
<psusi> thank god... finally got all the patches on... now hopefully it compiles this time
<mjg59> BenC: Can we grab http://sourceforge.net/projects/acpi4asus/ ?
<zul> helo
<chmj> hey zul 
<zul> BenC: did you do a pull yet?
<Abecedarian> Hello.  By any chance could somebody here answer a few questions on booting and the linux kernel, particularly as it relates to having a linux kernel loads modules and executse the linuxrc?
<Abecedarian> Okay, I guess that I
<Abecedarian> Okay, I guess that I'll assume that this is the wrong place to ask about booting and the kernel's ability to run a linuxrc script.  If anybody with the proper expertise comes back and reads that, *please* message me.
<crimsun> Abecedarian: ...linuxrc?
<Abecedarian> Yeah.
<Abecedarian> I've read that it is a script that a kernel can run immediately after loading.
<Abecedarian> So if you stick the kernel on a bootable cd with the proper linuxrc script, it might be able to run the linuxrc script which tells it to load modules/drivers, scan for usb devices, and then change root over to them.
<Abecedarian> The two guides that I've been using are http://www-128.ibm.com/developerworks/linux/library/l-fireboot.html and http://www.neowin.net/forum/lofiversion/index.php/t269145.html ...
<zul> you might want to check the linux from scratch site
<Abecedarian> http://www.linuxfromscratch.org/ ...  Thanks!
<Abecedarian> zul:  Thank you very much for your advice!
<Abecedarian> Is there any Ubuntu-specific documentation that are a must-read?
<crimsun> you probably want to keep current with udev
<crimsun> cf. Scott's post to ubuntu-devel-announce regarding hardwareactivation and udev [replacing hotplug] 
<Abecedarian> ?
<crimsun> regarding scanning for devices, etc.
#ubuntu-kernel 2007-01-15
<zul_> yay its uploading
<Mithrandir> zul_: yo, about your xen-source upload.  Can you make it as a patch application against the kernel in feisty?
<tepsipakki> I still can't see a new kernel in dapper-proposed _or_ in the queue?
<zul_> Mithrandir: hmm?
<Mithrandir> zul_: we'd like to avoid having more copies of the linux kernel in the archive than what we need.
<zul_> Mithrandir: i know but its non-trivial right now
<Mithrandir> zul_: so if xen-source could just ship the diffs and build-depend on linux-source-$rightver, that ought to work.
<zul_> Mithrandir: ill give it a shot
<Mithrandir> zul_: thanks.  You need to pull linux-source-2.6.19 from lp since I removed it (probably by mistake).  We really, really, really want to make sure that xen uses the same kver as the regular one for feisty+1.
<zul_> ok ill do that for .2
<Mithrandir> thanks.
<Mithrandir> I see that porting it to .20 might not be feasible for feisty, tho
<zul_> yeah porting to 2.6.19 was a pain for the redhat guys
<cjwatson> ok, so I can see why bug 73955 happens for vgacon; vgacon sets the font immediately without regard for whether the vc is visible
<cjwatson> (and doesn't keep it around otherwise, so there's no way to set the font properly for a non-current vc
<cjwatson> )
<cjwatson> I entirely can't see why it happens for fbcon
<Rroet> o/
<Rroet> hi guys, I have an issue with my new hp desktop and the ubuntu live cd's.. I can't seem to find a way to boot it without kernel panics.
<Rroet> It seems to give messages about the APIC_init_uniprocessor ..
<zul_> meh...winter storms are so much fun
<zul> Mithrandir: what did i have to add to xen-3.0 to make it sane?
<zul> libvncviewer?
<Mithrandir> zul: huh?
<Mithrandir> ECONTEXT. :-)
<zul> Mithrandir: you mentioned something about libvncviewer had to be promoted for xen i dont remember now
<Mithrandir> yes, I think I mentioned that like two months ago
<zul> yeah ill write the report tonight then
<Mithrandir> xen-3.0 build-deps on libvncserver-dev
<Mithrandir> and libvncserver isn't in main
<Mithrandir> so xen can't build
<zul> meh..
<zul> btw can you kick xen-source out of the new queue as well?
<Mithrandir> I prefer not to work at 22 in the evening, so not now.
<zul> sorry didnt realize the time no problem
<Mithrandir> I can do so tomorrow, but I'd like you to register a spec about making the source package not insane for feisty+1.
<zul> sure
<zul> the building on 2.6.20 we talked about this morning?
<Mithrandir> yes, or generally just making xen a package build-depending on the correct linux-source-$ver package
<zul> sure..
<zul> right...going home...later
<johanbr> I've been trying out different kernels to find an ACPI bug and I noticed that the Edgy kernel doesn't boot anymore on Feisty. Is this known/intentional/the way it's supposed to be?
#ubuntu-kernel 2007-01-16
<BenC> "...this document refers to domains as abstract isolated environments in the platform to which a subset of host physical memory is allocated."
<BenC> I love reading tech speak to my friends, just to see the look on their face
<BenC> Keeps them from asking me the same question all the time.."What are you reading?"
<Nafallo> haha
<zul> BenC: virt?
<BenC> VT-d
<BenC> IO virtualization from Intel
<BenC> pretty cool stuff, let's you put a devices IO into a domain so that only the driver, or the guest system can access it...sort of like jail for devices
<BenC> that way the device cannot scribble DMA all over memory, and guest systems can have direct access to devices on the host without worrying about compromising the host
<BenC> So you can insert a network card, and SATA card, and have it assigned directly to the virtual machine
<zul> neet
<Nafallo> sounds kewl :-)
<lifeless> BenC: ping
<BenC> lifeless: yo
<lifeless> think I'm running into the multiply-mounted squashfs bug in 2.6.10-17 here with ubuntu-on-tap
<lifeless> wondering what the workaround on the livecd was so I can reproduce it
<BenC> The workaround was to not do it
<BenC> the fix is in edgy-security
<lifeless> ok,so I'm using the livecd squashfs as-is, I presume that means I have the fix...
<BenC> are you getting a zlib oops from the kernel?
<lifeless> yes
<BenC> you have the workaround on the current edgy live-cd
<lifeless> the stock 6.10 iso ?
<BenC> should be, yes
<BenC> the workaround was to copy directly from the squasfs root mount, as opposed to mounting temp and copying from there
<lifeless> righto, so that should still be in place
<lifeless> let me see
<BenC> best person to ask is cjwatson, he does ubiquity and did the workaround
<lifeless> now you say that there is a fix - you mean kernel fix yes? - in edgy-security ?
<BenC> right, the kernel in edgy-security has a fixed squashfs
<BenC> there was talk of an edgy point-release to pull it and other things in, but I've no idea if that will happen
<lifeless> ah-ha, I dont have security on my master machine
<kinema> Is there a list of patches that have been applied to the various "official" Ubuntu kernels?  I looked on the wiki but wasn't able to find anything
<lifeless> I'll install that kernel and generate a initrd and see.
<lifeless> thanks!
<BenC> kinema: It's all in the git repo via revision history
<kinema> hmm... that's a pretty obious one is it?  now i feel kind of stupid.
<kinema> BenC: Have you had any luck getting the liveCD to boot in KVM?  I saw you making inquires on the KVM list recently.
<BenC> kinema: I'm not sure I'm qualified to do the real-mode 32-bit changes needed for it
<lifeless> BenC: whats the fixed kernel-version ?
<kinema> Understandable... that's some pretty gritty work.
<BenC> lifeless: Can't recall
<kinema> Does anyone know if it's possible to patch a kernel with the d80211/devicescape code using just the headers or if a from the ground up custom kernel is required.
<mjg59> There's a one-line patch needed to the main kernel
<kinema> mjg59: for d80211?  I thought all the code was in the wireless-dev tree still.
<kinema> mjg59: what one-line patch?
<kinema> what kernel is feisty herd 2 running?
<crimsun> kinema: 2.6.20-rc3
<crimsun> or rc4, don't remember immediately, but it has many, many patches
<Nafallo> rc4 I think
<kinema> if it's heavily patched I think I'll just download linus' rc5 and patch it myself.
<kinema> ugh.... gitweb is slow!
<kinema> painfully slow
<lifeless> BenC: sweet, thank you, its good
<BenC> lifeless: good deal
<lifeless> BenC: around ?
<fabbione> lifeless: he just went to sleep
<\sh> hmmm...why is UTS_RELEASE not set anymore in /usr/include/linux/version.h ?
<BenC> \sh: It's in linux/utsrelease.h
<BenC> \sh: If you are needing it for userspace, use the libc call to get it, if you need it for a kernel module, use utsname()->release
<jes-o-mat> hi
<jes-o-mat> kylem, BenC: I'd like to retest #37452 but till now it's quite unclear to which git you have uploaded your patch. http://kernel.org/git/ states that both of your dapper-updates repos haven't been updated since weeks?
<BenC> jes-o-mat: Use dapper-proposed repo to get the built kernel
<kylem> er, oops, did i forget to push? :\
<kylem> i did, terribly sorry.
<jes-o-mat> BenC: is there also a proposed update for the u-i somewhere?
<BenC> u-i?
<jes-o-mat> ubuntu-installer =)
<jes-o-mat> . o O (just named it like that because of d-i ;)
<BenC> the installer doesn't get rebuilt in -proposed, but you can surely rebuild it using the debs/udebs in -proposed
<jes-o-mat> but will there be some officially supported install medias available?
<jes-o-mat> so to say 6.06.2?
<BenC> https://wiki.ubuntu.com/KernelUpdates
<BenC> that explains how fixes in -proposed get to stable
<BenC> basically, it needs testing before it gets into a stable kernel, and then it's left in the hands of the release team as to whether or not a point release occurs for new CD's
<Mithrandir> BenC: s/release team/stable release team/ :-)
<kylem> BenC, http://www.reghardware.co.uk/2007/01/15/intel_robson_pcie_approval/
<jes-o-mat> BenC: where shall test-reports being send to? reply to #37452
<BenC> kylem: I wonder if the linux community has even pondered how to make use of that
<BenC> jes-o-mat: To the bug report is the best place
<kylem> BenC, i am... :)
<BenC> kylem: Storing your pr0n passwords is not a legitimate use :P
<kylem> jes-o-mat, if you could cc me privately as well, it would be good. my bugmail folder is pretty large.
<kylem> BenC, no... suspend to disk.
<BenC> Using it for /boot would be nice too
<BenC> wonder if the BIOS provides compatibility for accessing it like a normal drive
<kylem> jes-o-mat, i picked the patches to backport out of one report there, if they didn't help, i can pretty quickly have a new kernel out for you to test, but if it requires me finishing going through bugs then it will take longer. :)
<jes-o-mat> the x4100 are currently blocked by some collegues, but I expect that I can reinstall them tomorrow
<kylem> ok.
<jes-o-mat> but it's quite unhandy, because I need to install to a single disk from CD, install kernel from proposed and then assemble the RAID to verify
<jes-o-mat> kylem: that is just waiting for your changes: http://boschman.de/gallery/v/bjoern/tec/sun-x4100/dsc00077.jpg.html :-)
<zul> argh...i guess i know what im going to be doing this weekend...thanks pitti
<zul> Mithrandir: ping
<Mithrandir> zul: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<jes-o-mat> Mithrandir: The Answer to The Ultimate Question Of Life, the Universe and Everything
<jes-o-mat> hm it does not seem to be an infobot :)
<zul> umm...no
<Mithrandir> jes-o-mat: no, I'm not an infobot.
<jes-o-mat> Mithrandir: I just thought that because of your generic answer style :)
<Mithrandir> oh, it's a script, sure.
<jes-o-mat> Mithrandir: ping
<Mithrandir> jes-o-mat: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<jes-o-mat> I see
<jes-o-mat> hehe
<zul> ah man im not going to get any work done tonight american idol is on tonight
<jes-o-mat> BenC: Unfortunatelly I do not find any linux-image on dapper-proposed?
<BenC> either it failed to build, or an archive person hasn't processed it yet
<jes-o-mat> where to check for that?
<tepsipakki> it isn't in the queue
<tepsipakki> 15:49 < kylem> er, oops, did i forget to push? :\
<tepsipakki> 15:51 < kylem> i did, terribly sorry.
<kylem> i uploaded
<kylem> i didn't push the tree to korg.
<tepsipakki> oh, sorry
<kylem> lol, np
<tepsipakki> -proposed ones don't show up in the build queue :)
<tepsipakki> or -security, for that matter
<tepsipakki> anyway, the images are not in archive.u.c?
<jes-o-mat> kylem: where did you upload your changes?
<zul> the kernel.org hg tree sucks..
<BenC> That's just dandy
<BenC> vbox requires you to disable NMI watchdog on the host
<kylem> eep.
<Keybuk> random thought ... is it possible to re-exec a crashed process based purely on the memory map of the process?
<kylem> Keybuk, how do you mean?
<kylem> Keybuk, like, program fully terminates, dumps core. then some time x later you want to rerun it? or immediately re-execute it on crash?
#ubuntu-kernel 2007-01-17
<fabbione> morning
* Starting logfile irclogs/ubuntu-kernel.log
<jes-o-mat> kylem: your changes made it into git - thnx
<jes-o-mat> now I'm just wondering how to compile your tree
<jes-o-mat> a lot of files are missing in the debian/ directory
<jes-o-mat> BenC: maybe you know some points that will get me further?
<\sh> which script generates the initrd for the linux-image package in postinstall? I don't see it in debian/* of linux-source-*, could be that I'm blind ;)
<Mithrandir> kernel-package
<\sh> yes...I see it now ;) make-kpkg generates postinst
<cjwatson> BenC: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/76341 is quite a nasty issue. Do you think you/kyle could have a look at it with the lkml reference I gave?
<BenC> cjwatson: sure
<BenC> cjwatson: Ah, I talked to Keybuk about this, and I'm not sure we've concluded whether it was a udev or a kernel bug
<BenC> the kernel code hasn't changed
<cjwatson> the lkml thread seemed to reckon that it was a kernel bug due to MODALIAS=i82365
<cjwatson> but I couldn't find anything outside that thread
<cjwatson> I tried to work around it in udev rules, but haven't succeeded yet
<jes-o-mat> BenC: no idea regarding my problem?
<BenC> jes-o-mat: The URL in the topic has a link to compiling custom kernels
<zul> hey
<jes-o-mat> BenC: yes and I was using the commands as written
<BenC> jes-o-mat: Without some context, I can't give you any more info
<jes-o-mat> but there are a lot files missing in kylem's git tree
<BenC> Like what files
<jes-o-mat> basic things like copyright e.g.
<BenC> what git tree are you using?
<jes-o-mat> I have taken some of them from the linux-source package, but now I got to a point where the build scripts needs some debian/d-i/shared/firmware/* files which are not present
<jes-o-mat> ubuntu-dapper-updates.git
<jes-o-mat> from kyle
<BenC> on kernel.org?
<jes-o-mat> yes
<jes-o-mat> http://www.kernel.org/git/linux/kernel/git/kyle/ubuntu-dapper-updates.git
<jes-o-mat> I fetched it as supposed via rsync
<BenC> I get 404 on that url
<jes-o-mat> Generating......
<jes-o-mat> http://www.kernel.org/git/?p=linux/kernel/git/kyle/ubuntu-dapper-updates.git;a=summary
<jes-o-mat> sorry
<jes-o-mat> mixed up http and rsync url's a bit
<BenC> http://www.kernel.org/git/?p=linux/kernel/git/kyle/ubuntu-dapper-updates.git;a=tree;f=debian;h=1690c1d0bf1d38ebd708df29599ae4195871d490;hb=HEAD
<BenC> shows the copyright file, and others
<BenC> must be your lock tree
<BenC> s/lock/local/
<jes-o-mat> I used the following to fetch the tree:  git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/kyle/ubuntu-dapper-updates.git ubuntu-dapper-updates
<BenC> All I know is, the tree on kernel.org is fine...not sure why yours is having problems
<BenC> git-checkout -f
<BenC> see if that helps
<jes-o-mat> ini get a lot of "unable to read sha1 file of ..."
<jes-o-mat> maybe the argument "ubuntu-dapper-updates
<jes-o-mat> " is false
<jes-o-mat> I just guessed it
<jes-o-mat> cuase the wiki is only talking about linux-2.6
<jes-o-mat> oh
<jes-o-mat> that's for the local directory :)
<BenC> jes-o-mat: my guess is that git isn't following the alternative objects to my tree
<BenC> jes-o-mat: Best bet is to clone my tree, then pull from kyle's
<kylem> it probably doesn't if you use rsync.
<kylem> use git://
<BenC> jes-o-mat: Telling me about the missing sha1 messages would have been helpful before :)
<jes-o-mat> BenC, kylem: I'll try using git://
<jes-o-mat> BenC: the list was *very* long :)
<kylem> jes-o-mat, my repository shares objects with ben's so that it doesn't take a long time to mirror. the downside is you need to use a git-aware protocol for fetching it.
<jes-o-mat> kylem: is the host still rsync.kernel.org?
<jes-o-mat> or is there some git.k.o host?
<kylem> it's the same pair of machines either way
<kylem> a CNAME by any other name would resolve as sweet.
<tepsipakki> kylem: I see the upload to dapper-proposed as rejected?
<jes-o-mat> sweet CNAME ... I need to remember that :)
<kylem> tepsipakki, one of them was rejected, there were two.
<tepsipakki> kylem: should it be built by now and available on a.u.c?
<kylem> tepsipakki, i'd have thought so, i'm new to this whole game though so i'm not really sure what the process is once i upoad.
<tepsipakki> kylem: I've searched the dapper queues and I can see only the rejected one :)
<kylem> possibly one of the archive folks needs to be cattle proded.
<tepsipakki> heh
<jes-o-mat> *grml* git:// is blocked by firewall
<Mithrandir> jes-o-mat: ssh -D 1234 wherever, then use tsocks on localhost:1234
<Mithrandir> ssh -D is like the best invention since the internet.
<jes-o-mat> Mithrandir: great! didn't knew the -D flag - I always had used -L or -R
<kylem> Mithrandir, hah.
<zul> i thought slice bread was a pretty good invention myself
<Mithrandir> sliced bread is a _horrible_ invention.
<zul> i disagree
<kylem> i hate sliced bread.
<kylem> i much prefer carving out a quadrant of a nice big loaf of pumpernickle
<thom> i am lazy. all dutch bread is horrific, so it makes no odds to me
<jes-o-mat> hrhr
<Mithrandir> thom: make it yourself and you can have it however you want.
<thom> Mithrandir: see my leading sentence
<Mithrandir> thom: bread making machine.
<Mithrandir> pour ingredients, set timer, wake up to a fresh loaf of bread.
<thom> had one, hardly ever used it
<zul> heh if i cook something there is a pretty good chance that it will implode or explode
<jes-o-mat> kylem: seem that the changes does not solve #37452 :/
<jes-o-mat> everything compiled well but after creating the hw-raid the kernel cannot access sda
<kylem> well, someone who actually has the hw will have to hunt down the changeset which fixes it. i can't test it.
<cjwatson> BenC: did /proc/cpuinfo change on i386/amd64 recently (.20) for multiprocessor machines? I see why bug 79109 is happening, but apparently it didn't happen with Herd 1 and the relevant code in base-installer hasn't changed at all
<BenC> bug #79109
<BenC> cjwatson: It's possible, what portion is it using?
<BenC> cjwatson: diff'ing the cpuinfo from my 2.6.20 coreduo and 2.6.17 core2duo doesn't show anything changing other than values of the cpu itself
<BenC> I can try a boot into 2.6.20 for the core2duo and see about same cpu changes
<BenC> cjwatson: The only thing I see different is that in 2.6.20 it recognizes the difference between physical cpu's and cores
<BenC> so on .17 it would show physical_id={0,1} and core_id=0 for the two, and on .20 it shows physical_id=0 and core_id={0,1}
<cjwatson> BenC: it's grepping for 'cpu family' lines, and forgot to do head -n1
<cjwatson> BenC: if older kernels had only one cpu family line, but current ones have two (which current ones do), then that would explain it
<BenC> I show two lines in both
<BenC> so that didn't change
<BenC> does it use siblings?
<BenC> or "cpu cores"?
<cjwatson>         FAMILY=`grep '^cpu family' "$CPUINFO" | cut -d: -f2`
<cjwatson>         case "$VENDOR" in
<cjwatson>                 " AuthenticAMD"*)
<cjwatson>                         case "$FAMILY" in
<cjwatson>                                 " 6"|" 15")     echo k7 ;;
<cjwatson> just that sort of thing
<cjwatson> dunno, maybe it was always broken - I was just curious
<cjwatson> oh, unless vendor_id changed similarly - it greps for that too
<cjwatson> nothing else, not siblings or cpu cores
<BenC> still shows GenuineIntel
<BenC> On i386 and amd64 there shouldn't any of this anyway
<BenC> it should always install -generic
<cjwatson> -generic is built for 586, so it's needed for 486 systems
<cjwatson> most of the code is inherited, but still
<BenC> true, -386 is the side case
<cjwatson> on amd64, in practice it makes no difference - it installs -generic regardless
<cjwatson> it's not vendor_id contents I'm thinking about, but whether it appears once or twice
<jes-o-mat> kylem: I just digged into the source and the suggested patchset from Cedric Schieli did not made it into your git
<BenC> it appears twice on .17 and .20
<cjwatson> anyhow, I have a fix now
<cjwatson> ok, thanks
<BenC> cjwatson: Do you want my cpuinfo's for reference?
<BenC> cjwatson: emailed, can't hurt to have it
<cjwatson> sure, thanks
<cjwatson> BenC: ah, fjp pointed me in the direction of the answer - between Herd 1 and 2, we switched the installer from 386 to generic, and 386 doesn't have SMP alt so the second core didn't show up in cpuinfo
<kylem> jes-o-mat, which kernel image do you need?
<jes-o-mat> kylem: -server
<kylem> amd64 or i386?
<jes-o-mat> i386 (for now)
<kylem> alright
<BenC> cjwatson: The d-i installer, or the livecd installer?
<BenC> I thought the installer for the alt CD was going to remain 386
<cjwatson> for edgy, it did, but I elected to change that for feisty and just retain the netboot install as 386
<cjwatson> I think I mentioned that possibility in mail to you pre-edgy
<cjwatson> it simplifies the desktop seed rather a lot, because we can just slam linux-headers-generic in there and not worry about which installer is in use
<BenC> so the bug was always there, it just never showed up because the -386 installer didn't see the extra cpu's?
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2006-December/023036.html
<cjwatson> right
<cjwatson> I should probably have CCed you on that mail about the installer change
<BenC> well, the cpu checking is still pretty moot, because if they boot the live or alt cd's, they don't need -386 anyway
<BenC> but it certainly can't hurt to have it, since the end result is the same :)
<cjwatson> that's true, but the same code is used for the netboot installer where it might conceivably matter
<cjwatson> I realise it's all a tiny corner case - I just prefer fixing mostly-working code over removing it :)
<Red_Herring|ugh> yo
<Red_Herring|ugh> anyone around?
<Red_Herring|ugh> guess not.
<Red_Herring|ugh> anyways ill ramble on about my problems
<Red_Herring|ugh> so i got an edgy amd64 kubuntu install
<Red_Herring|ugh> and one day
<Red_Herring|ugh> i boot up
<Red_Herring|ugh> and get a kernel panic
<Red_Herring|ugh> the "Aiee, killing interrupt handler!" kind
<Red_Herring|ugh> so i boot from livecd
<Red_Herring|ugh> chroot in
<Red_Herring|ugh> recompile the kernel
<Red_Herring|ugh> and boot again
<Red_Herring|ugh> and it complains about missing modules
<Red_Herring|ugh> so
<Red_Herring|ugh> im runnin a livecd now
<Red_Herring|ugh> chrooted into the thing
<Red_Herring|ugh> and am wondering
<Red_Herring|ugh> whats the best solution
<Red_Herring|ugh> i'd really hate to install
<ivoks> make modules_install ?
<Red_Herring|ugh> ?
<ivoks> but this is development channel, not support
<Red_Herring|ugh> ok
<Red_Herring|ugh> but can you at least tell me how to diagnose it?
<Red_Herring|ugh> ... thanks
#ubuntu-kernel 2007-01-18
<Nafallo> zZzZ
<forbin117> Hi, I have a question about saa7134 support, and wether I need to compile a new kernel to get it or not?
<jes-o-mat> kylem: the backported patch from Cedric Schieli does not work for my machine :/
<Mithrandir> zul: xen-source ftbfs on i386
<zul> Mithrandir: already have a fix 
<Nafallo> zul_: I don't think xen-image-2.6.19-1-generic-amd64 is for "Pentium Pro/Celeron/Pentium II/Pentium III/Pentium 4 machines" to be honest :-)
<Nafallo> morning BenC :-)
<BenC> good morning
<zul_> Nafallo: i know will be fixed in the next upload
<jes-o-mat> kylem: any news on the kernel image?
<kylem> ... i told you, i have no idea what patch will fix it, you're going to have to experiment. i can't just take a whole new driver for -security...
<kylem> i can guess and respin you one this afternoon if you'd like... but it would be more helpful if it can be narrowed down.
<jes-o-mat> kylem: I'm gonna try to work out some things first
<jes-o-mat> kylem: using the suggested patches from Cedric Schieli I get the following rejects: http://jesusch.de/~jesusch/tmp/rejects/
<jes-o-mat> I think his work was based on an earlier version, that did not include your changes you made on the repo ~6 days ago
<jes-o-mat> hi olifante :)
<fabbione> kylem: ping?
<kylem> fabbione, yo
<kylem> fabbione, sorry, was eating lunch
<fabbione> kylem: no problem.. can you please investigate why once again .20 the hpt366 module is missing from sparc udebs?
<kylem> in a bit, sure.
<fabbione> and can you make sure is there again by the next upload?
<kylem> no, ben would only be able to say that.
<fabbione> i could just upload it...
<fabbione> bu then it would go async with git
<zul> whee...going to hockey game tonight
<kylem> fabbione, ok. i'll push it to our shared git repository and ping ben.
<fabbione> kylem: thanks..
<kylem> will turn up in ide-modules
<fabbione> danke
<kylem> fabbione, it would be helpful to have someone run automated diffs of /lib/modules between all 5 arches
<fabbione> kylem: script it.. there are mirrors of archive on roockery or chinstrap
<fabbione> i used to do that at my time
<kylem> heh. i have enough work to do atm.
<lifeless> hmm, no benC
<kylem> lifeless, he's travelling atm.
<lifeless> ah
<kylem> lifeless, (to london for the osdl wireless summit)
<lifeless> so remember that ipsets discussion at the start of the week ?
<kylem> yes.
<lifeless> turns out that it isn't able to be built fully externally without lots of gymnastics
<lifeless> it needs an iptables rebuild with a makefile option changed, and a new kernel header installed
<kylem> eh?
* lifeless rewinds
<kylem> i don't see why needing a kernel header installed means it needs patching... sounds like they aren't trying hard enough. ;P
<lifeless> hmm
<lifeless> perhaps I'm using the wrong terms :)
<lifeless> to get ipsets working you need to:
<lifeless> build the module [can do trivially with kernel headers installed] 
<lifeless> install the modules extra kernel header 
<lifeless> patch the iptables deb source trivially and rebuild
<kylem> oh.
<kylem> ok. my bad, i thought you meant we needed to patch the kernel.
<lifeless> FSVO patch. We do need to install an extra header into the space the kernel headers go
<lifeless> anyhow, this means that ipsets will need its own copy of iptables built differently, unless we make ipsets be on by default
<kylem> couple choices...
<kylem> could build iptables in ipsets and divert it...
<kylem> or could just make it the default as you said.
<lifeless> so I'm here to whine and plead for ipsets to be the default :)
<kylem> i dunno if i agree with that, not that my voice is really worth much.
<Mithrandir> what's ipsets?  Like iptables, only rewritten?
<lifeless> Mithrandir: its an iptables extension for handling very large or very dynamic groups of ip addresses
<lifeless> kylem: well as one of the 2 kernel dudes, your voice counts heaps
<lifeless> kylem: so if you say 'build another iptables binary and divery' -> will do so
<kylem> not really...
<kylem> my problem with it is, it seems to have been written a long time ago... and still not merged.
<kylem> so clearly either something is wrong with it... or... something..
<lifeless> kylem: ok, I'll get Jerub to ask around about that aspect
<lifeless> Mithrandir: with ipsets you create a match on set inclusion/exclusion, then add and remove ips from the set
<kylem> lifeless, otoh it doesn't seem like it could make a big impact, my concerns are mostly from the maintainability/security aspect.
<lifeless> thats fine, I'll ask. I have to run now, thanks for the chat
<kylem> ok. cheers.
<[g2] > is there much kernel development on the 2.17 (edgy) kernel or is it mostly Feisty (2.6.20) ?
* [g2]  wonders about creating an update for the ivtv modules for edgy
<crimsun> [g2] : no.
<crimsun> (for the former, that is. For the latter, yes.)
#ubuntu-kernel 2007-01-19
<bronson> I tried to build the kernel under pbuilder (thanks to kernel-wedge, I can no longer build 2.6.17 on Feisty)...  Apparently it uses /tmp/buildd heavily
<bronson> Ran out of space on /tmp and the build died.
<bronson> Has anyone worked around this?
<Nafallo> bronson: /tmp/buildd in the chroot is not /tmp outside...
<Nafallo> bronson: /var/cache/pbuilder/builds/$PID or something like that
<Nafallo> might be build actually ;-)
<bronson> Nafallo: good point.
<bronson> Still investigating /tmp...  but I also see a whole bunch of "warning: no utmp entry available and LOGNAME not defined; using uid of process"
<bronson> This is harmless, yes?
<bronson> Google shows it appearing in a ton of build logs, but nobody really talks about it.
<Nafallo> yes
<bronson> DOH -- it was building in /var even though I thought I told it not to.
<ekb-2> anyone know if the kernel config that is in /boot is the same one that is used to make the kernel and initrd that are on the live cd in the <cdrom>/casper dir?
<Nafallo> should be
<ekb-2> is there anything special that should be done to create the same initrd file?
<ekb-2> i am modify in cd iso to boot my own kernel for the live install, and I want to make sure everything is as close to stock as I can make it.
<kylem> morning all.
<kylem> doh, wrong window.
<zul> hey kylem 
<kylem> how was the hockey game?
<zul> it was good my voice is hoarse
<zul> hey BenC how was the flight?
<jbailey> kylem: Hey - is iSCSI supported on Dapper?  I seem a module for it in Edgy, but I don't know if there are userspace daemons and such that need to go along with it.
<kylem> jbailey, i don't think so, but let me check
<jbailey> Thanks
<kylem> we have the module built in dapper, but no userspace component.
<jbailey> But it does need one?
<kylem> i suspect so
<kylem>          To compile this driver as a module, choose M here: the
<kylem>          module will be called iscsi_tcp.
<kylem>          The userspace component needed to initialize the driver, documentation,
<kylem>          and sample configuration files can be found here:
<kylem>          http://linux-iscsi.sf.net
<kylem> :P
<fabbione> jbailey: userland just landed in debian 
<fabbione> and it should be ok with kernels < .18
<fabbione> anyway.. back to family life..
<fabbione> it's weekend
<jbailey> fabbione: Do you know what it's called?  We should probalby request a sync for it for universe at least.
<kylem> open-iscsi
<fabbione> yes but be aware that the pkgs is not complete
<fabbione> jbailey: you want to talk to fs here on freenode or waldi
<fabbione> they maintain the pkgs and fs and I did talk quickly about it a couple of days back
<fabbione> family time!
* fabbione &
<jbailey> fabbione: Aren't you the Ubuntu Server Manager? ;)
<zul> wowo...xensource made the great leep forward they updated their sparse-tree to 2.6.17
<maks_> the in kernel stuff kvm looks nicer
<Nafallo> maks_: google says XEN is better for compiling :-)
<maks_> compiling what?
<Nafallo> whatever :-)
<Nafallo> lame and a kernel 2.6.19 on the review ;-)
<maks_> kvm with paravirt patch?
* Nafallo tries to find the link instead
<Nafallo> maks_: http://www.phoronix.com/scan.php?page=article&item=623&num=1
<maks_> seems already old
<Nafallo> :-P
<zul> Nafallo: which means i might be able to update the kernel in dapper now
<zul> er i mean dapper
<zul> gah...edgy
<Nafallo> zul: oh. something that even works on amd64? :-)
<zul> yeah
<Nafallo> nice :-)
<Nafallo> zul: oh! 32-bit host with 64-bit guest should work on full virt, right? :-)
<Nafallo> zul: if you don't know I'll test when there are working XEN-stuff in edgy :-)
<bronson_> error: linux/compiler.h: No such file or directory    <-- this is harmless, yes?  I'm building latest Edgy 2.6.17 on amd64.
<many> heya. ive some oddity with feisty/fglrx.  a modprobe is just hanging forever and iam seeking clues on whats wrong
<many> ``modprobe --ignore-install -Qb fglrx'' is in ``D''isk IO state
#ubuntu-kernel 2007-01-20
<Mithrandir> zul: your xen-3.0 upload FTBFS..
<baba-andrea_> hi all
<oktyabr> anyone here got -lowlatency to work with a default herd2 install?
<crimsun> yes - it boots, functions amiably, doesn't explode for my use cases. YMMV.
#ubuntu-kernel 2008-01-14
<Kano> hi, did anyone try to write as user on a hd partition with vfat (not usb media as long as you are in the floppy group)?
<Kano> the problem is, even when umask allows you writing, the timestamp will be always the current date.
<Kano> when you do the same as root the timestamp is correct
<Kano> losing the timestamp is a major problem
<Kano> rsync would copy always the same file
<Kano> also youdont know when you really created it..
 * _MMA_ thanks whomever for the restricted modules in Hardy. Any ETA on the metas? (linux-rt and such)
<_MMA_> *-rt restricted modules
<rtg> _MMA_: working on it....
<_MMA_> rtg: Thanx a bunch. I'm still not sure of Alessios situation. His emails have been sparse. I know he's had HW issues. Last bit of work he did was on a borrowed machine.
<rtg> _MMA_: well, rt at least appears to build. dunno about if it actually works.
<henrix> rtg: it is working for me ;)
<henrix> rtg: but never actually fully tested it...
<_MMA_> Looks to be working here also. Im about to reboot to test the restricted modules.
<henrix> didn't tried those...
<_MMA_> rtg: Looks like the restricted -rt modules work. Im gonna test a little more with a game or something,
 * _MMA_ also notices nvidia-settings app comes up in a 50x25px window or so. Odd.
<Keybuk> 16:17:29.425 [I] osspec.c:230: SEQNUM=3387, ACTION=add, SUBSYSTEM=block, DEVPATH=/sys/block/mmcblk0, DEVNAME=/dev/mmcblk0, IFINDEX=0
<Keybuk> 16:17:29.428 [I] osspec.c:230: SEQNUM=3392, ACTION=add, SUBSYSTEM=mmc, DEVPATH=/sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.2/mmc_host/mmc0/mmc0:f318, DEVNAME=, IFINDEX=0
<Keybuk> aren't those the wrong way around? :-)
<Keybuk> (happens when mmc_block is already loaded)
<\sh> guys, behaviour of bug #180157 disappeared...now it's back to normal since the last kernel update
<ubotu> Launchpad bug 180157 in linux "XFS root filesystem - install fails with "noexec or nodev" error" [Undecided,Incomplete] https://launchpad.net/bugs/180157
<tjaalton> mjg59: what do you think of SHMConfig option for synaptics? some people want us to turn it on by default
<tjaalton> from what I know it's possibly a security risk, but needed for gsynaptics
<mjg59> tjaalton: No.
<mjg59> tjaalton: It's an unacceptable security issue
<mjg59> That's why I reimplemented the more useful bits of the functionality
<mjg59> I'm planning on doing this properly in a way that can go upstream
<tjaalton> ah right, cool
#ubuntu-kernel 2008-01-15
<TheMuso> c
<TheMuso> ugh wrong tab
<asac> http://paste.ubuntu.com/3571/ <- "update of the scan
<asac> capability patch"
<asac> do we have that as well?
<aantipop> is there a reason for linux-generic pointing to 2.6.24-3 and not to -4 ?
<Mithrandir> aantipop: yes, we change it by hand when we want to push people to a new revision.  (And I uploaded that change about 30 minutes ago)
<aantipop> thanks for the info
<bdmurray> BenC: ping
<BenC> bdmurray: hey
<bdmurray> BenC: A bit ago I noticed there are 2 kernel teams in Launchpad and I wanted to get them consolidated.  I submitted a question about it - https://answers.edge.launchpad.net/launchpad/+question/12069 - and it seems like we are at a point where it can be done
<BenC> bdmurray: problem is, kernel-team is created automatically by launchpad when we upload packages...I tried to resolve this awhile back, but I gave up trying to keep it that way
<BenC> bdmurray: it comes from the fact that our email address is kernel-team@lists.ubuntu.com, but we don't want to use this as the team email for ubuntu-kernel-team, since it means all bug traffic will go there
<bdmurray> BenC: Okay, that makes a bit of sense.  Can mailman filter e-mail based on the headers though - like the assignee?
<BenC> bdmurray: not sure
<BenC> bdmurray: what I need, and I think I asked for this from lp folks, is to be able to have a team email address (mailing list), but still have all team related emails sent to team members instead of the mailing list
<voraistos> hi. my question not exactly kernel dev related, but maybe someone here can tell me what drivers are being used by the default ubuntu kernel for broadcom wifi cards ?
<bdmurray> BenC: Okay, its been quite a while since I asked that question, but I think my concern was finding packages (and their bugs) maintained by the kernel team.  As both teams have packages.
<voraistos> the kernel is 2.6.22 and i cant remember if the new versions of the drivers are being used or what.
<voraistos> bcm43xx b43, b43legacy
<BenC> voraistos: bcm43xx
<voraistos> ok thank you
<voraistos> this sucks though :(
<BenC> using bcm43xx sucks in many ways
<BenC> and I mean the hardware, not the driver
<voraistos> well, it cant load the firmware, so the hardware doesnt work much :(
<BenC> voraistos: in reality, the best way to use broadcom 43xx wireless is with ndiswrapper
<BenC> voraistos: download the firmware then
<voraistos> oh
<voraistos> but i did
<voraistos> i think i will do it all manually
<voraistos> is the firmware located in /lib/firmware or was it patched so it goes somewhere else ?
<BenC> voraistos: install bcm43xx-fwcutter package...it handles everything
<voraistos> i know
<voraistos> i just paid a visit to /lib/fimware
<voraistos> it seems it installed the wrong one
<BenC> Ok, I can't answer that problem
<voraistos> probably a bug in the software that does things automatically
<BenC> complain to broadcom for not supporting linux drivers :)
<voraistos> but i do :P
<voraistos> they just dont care !
<BenC> or use ndiswrapper, or keeping mucking around with manual firmware install
<voraistos> those $%^&**&^%
<BenC> voraistos: then support intel wireless...they rock and deserve your purchase
<voraistos> i was thinking about geting an atheros
<voraistos> however my sis bought a laptop with an atheros card and i took me ages to get support for it
<voraistos> the drivers didnt exist at first, then only an unstable incomplete one existed
<voraistos> i used to have an intel one, but its not compatible with my new laptop
<voraistos> ill fill in a bug report on whatever the automatic firmware installer is called, if bug there is.
<BenC> voraistos: bcm43xx-fwcutter is unsupported (universe), and has border-line legal issues, so I wouldn't expect much
<voraistos> is it a good idea to install a recent vanilla kernel on ubuntu? or will i loose functionality ? the splash screen is not a functionality btw.
<BenC> voraistos: it's not a good idea, no
<BenC> voraistos: because then we wont answer any of your questions, and we can't even guess what will happen
<voraistos> is there a documentation page on what modifications are made to the kernel ?
<BenC> voraistos: not a concise document, no, just the changelog, and the git history
<voraistos> ok
<voraistos> thank you BenC
<voraistos> as you stated before, getting a real driver -with still a damn firmware- to at least handle hardware decryption would be best i think
<voraistos> thank you again fro your help
<reynaldo> hi BenC 
<reynaldo> happy new year!
<reynaldo> :P
<ph8> Hi all - i'm running the xen version of 2.6.22-14(-xen) and i'm having a massive problem with realtek NICs - the mac address shows up as FE:FF:FF:FF:FF:FF:FF
<ph8> which means that bridging (and hence virtual machine hosting) doesn't work!
<ph8> has anyone got any idea how i can fix this? I know there's a bug report in but it seems a bit stagnant
#ubuntu-kernel 2008-01-16
<kraut> moin
<misc--> hi. I need to download a vanila kernel and patch it so I can run a virtual server on it. If I downoad then patch then copy my old .config and do a make oldconfig on it then compile etc, does that mean I'll still have the same ubuntu features as I had before such as my wireless and sound working, or does the ubuntu kernel contain specifc extra modules/patches and such?
<laga> misc--: i'm not sure about the kernel itself, however, there's a linux-ubuntu-modules package which contains additional drivers
<misc--> ohhh right ok then
<laga> and the linux-restricted-modules-package
<misc--> I wonder if I can get them to somehow work with the new kernel. I did try this a few days ago and did what I said above, copied my .config from my ubuntu kernel to the vanila sources and recompiled. No errors, but I lost my wireless and sound, so something went wrong...
<laga> can't you just patch the ubuntu kernel
<laga> it should be possible to recompile l-u-m easily at least
<misc--> no I had already tried that but there are all these missing hunks when I patch
<laga> l-r-m was a bit of a nightmare last time i tried it, but that might have changed in the meantime
<misc--> right ok then. So I actually have to recompile l-u-m and l-r-m
<laga> depending on where your missing modules are :)
<misc--> alright no probs, thanks for that, will look into it.
<laga> if you can't rebuild them for whatever reason, there might even be separate packages for the modules you need. i suggest you search the ubuntu wiki as well, i'm not an expert :)
<misc--> ok, shall do, thanks =)
<Kano> hi, could someone update to rc8?
<asac> hi
<asac> 11:00 < asac> http://paste.ubuntu.com/3571/ <- "update of the scan
<asac> 11:00 < asac> capability patch"
<asac> 11:00 < asac> do we have that as well?
<Kano> did somebody try vfat lately?
<Mithrandir> yes, works fine.
<Kano> vfat?
<Kano> as user?
<Kano> not usb
<Kano> i dont think so
<Mithrandir> why would USB matter there?
<Kano> because of the rights
<mjg59> asac: Do you have n-m 0.7 packages anywhere?
<Kano> when you use umask=000 basically a normal use can write 
<Mithrandir> doesn't sound like a kernel issue since it works fine as root.
<Kano> but: timestamps are only written as root or maybe when you are in floppy group and you use usb as you have got full write access in that case
<Kano> every other filesystem works correct
<asac> mjg59: currently working on that ... thus i found that comment and wondered if we have that kernel patch :)
<mjg59> asac: Heh. As far as I know, no.
<mjg59> I suspect it's backported from the wireless tree, rather than from 2.6.24
<mjg59> But you should be able to pull it from RH CVS and check
<asac> hmm ... ok. we should probably keep in mind to look into that at some point.
<Kano> just copy something to it, time will be always current time as long as you are not root
<Kano> rsync will copy it over and over again that way..
<Kano> even ntfs-3g works fine
<Kano> Mithrandir: do you have got the same effect on your system?
<Mithrandir> Kano: unsure, and I don't have time to test, sorry.
<Kano> Mithrandir: 
<Kano> touch -d 2008-01-01 testfile
<Kano> kano@Kanotix:/media/sdb5$ ls -l testfile
<Kano> -rwxrwxrwx 1 root root 0 2008-01-16 15:17 testfile
<Kano> thats the shortest test
<Kano> as root
<Kano> -rwxrwxrwx 1 root root 0 2008-01-01 00:00 testfile
<Kano> thats the diffence
<Kano> a user can not change timestamp/would use current time if you create new files
<Kano>  /dev/sdb5 on /media/sdb5 type vfat (rw,umask=000,shortname=mixed,quiet,utf8)
<doko> BenC_, lamont: I assume the hppa kernel build can now use gcc-4.2 for hppa. what about ia64 and powerpc?
<lamont> doko: #parisc would know best on hppa kernel
<BenC_> doko: hppa and ia64 are getting ftbfs because of section conflicts when we use gcc-4.2
<BenC> doko: oops, I mean ppc and ia64
<doko> BenC: is this seen with 4.3/snapshot as well?
<BenC> doko: not sure
<BenC> doko: this was just seen with default gcc on hardy builds
<doko> BenC: asking because the kernel is the last package in main b-d on 4.1, 4.3 would be an alternative if that works
<BenC> doko: I'm a little reluctant...but maybe we can try it next week at the sprint
<doko> ok
<ceekay> hi all.. i have a .deb of the intel ixgbe driver that i put together (because it's not available in feisty which i'm using)... i have an ixgbe-<version>-source.deb now, but i want to make a platform-dependent binary .deb so that i can put it on machines that don't have build tools... what tool should i be using for this?
<crimsun> ceekay: dpkg-buildpackage is canonical.  There are various packaging frameworks to make it easier: quilt, cdbs, and so forth.  Have you asked in #ubuntu-motu?
#ubuntu-kernel 2008-01-17
<Kano> hi, does somebody like to update the hardy kernel to rc8?
<kraut> moin
<Kano> hi, anybody awake?
<Kano> rc8 still not merged...
<Kano> debian/rules binary-debs flavours=generic skip_abi=true
<Kano> just tried this but abi check still failed - i only added a patch
<Kano> how can it fail when the check should be skipped?
<pitti> hi
<pitti> if two packages ship the same kernel module (say, linux-image and linux-backports-modules), how can l-b-m make sure that the module that it ships will be prefered? i. e. how does modprobe define the search order?
<laga> keep in mind that i don't really know what i'm talking about: can't you add a diversion?
<rtg> pitti: depmod looks in /lib/modules/`uname -r`/updates first.
<rtg> pitti: s/updates/ubuntu/
<pitti> rtg: ah, that's an Ubuntu specific hack?
<rtg> pitti: pretty much.
<pitti> rtg: someone else in the linux foundation driver-backports workgroup just brought it up
<pitti> rtg: ok, thanks
<_MMA_> rtg: I'd ask Alessio but he's not around. Any ETA on the -rt metas?
<rtg> _MMA_: oh, forgot. I've got it staged. just needs to be uploaded.
<_MMA_> Ahh... Ok. Once those are up my disks will build. :P
 * infinity scratches his head at:
<infinity> Brian Murray (brian-murray) tried to claim the Launchpad
<infinity> team named Ubuntu Kernel Team (kernel-team) (which is
<infinity> associated with kernel-team@lists.ubuntu.com).
<infinity> To finish claiming that team, making Brian Murray (brian-murray)
<infinity> its owner, just follow the link below.
<rtg> infinity: you can ignore that. I should not have released it either.
<infinity> And yet, you did. :)
<rtg> infinity: well now I know better.
<infinity> And knowing is half the battle.
<infinity> This does open a nice DOS I'd never noticed before, though.
<rtg> infinity: that occured to me as well.
<infinity> It only takes one click from a list subscriber in a list-owned team to lose ownership of the team.
<rtg> _MMA_: linux-meta with -rt dependencies is uploaded.
<_MMA_> rtg: Thanx a ton.
<majikins> hello - pls can someone help me with a raid1 setup
<smb> _MMA_: Hi, I was looking at a bug about using auditctl for the generic kernels. Basically this requires CONFIG_AUDITSYSCALL to be set. Would it make sense if I enable that for -rt as well?
<majikins> I've set it up via a youtube demonstration howto - testing now and if either disk is disconnected, box loads but not fully
<_MMA_> smb: abogani or one of the other kernel heads would be best to ask. I'm mostly management. :P
<smb> _MMA_: Oh, well. :) Since abogani is not here. Who else would those be. I havn't been around too long. ;-)
<_MMA_> Filing a bug would be sure he looks at it.
<smb> _MMA_: Alright then. Thanks
<_MMA_> -rt is really a "community" kernel and is handled by abogani with great help from guys in here.
<laga> i wonder why the ia_file member was removed from iattr.
<laga> breaks aufs compilation for me
<laga> ah, i think i found something
#ubuntu-kernel 2008-01-18
<Kano> hi, could somebody tell me why: debian/rules binary-debs flavours=generic skip_abi=true
<Kano> stops do to abi changes?
<Kano> (one additional patch was added)
<Kano> shouldn't skip_abi ignore it?
<Kano> or is it now skipabi instead?
<Kano>       read 2091 modules : new(6)  missing(2)
<Kano> EE: Missing modules (start begging for mercy)
<Kano> make: *** [module-check-generic] Fehler 1
<Kano> who to bypass this?
<Toma-> Is there any possibility in making rtl8187 and rtl818x compile with the next kernel update? 
<Kano> 87 is there in lum
<Kano> err in 2.6.24 itself
<Toma-> its in the source, sure
<Toma-> ahh
<Toma-> sorry, i meant rtl8180 and rtl818x
<Toma-> the source is there, but theyre both disabled in the makefile
<ObsidianX> hey folks, how do i use the debug kernel?
<ObsidianX> i want to get debugging output from some of the kernel modules
<Kano> hi,iwl is disabled now but i dont see those drivers in lum yet
<kraut> moin
<majikins> hi - can someone help me understand software raid1 pls?
<majikins> hi can someone help me understand software raid1 pls?
<amitk> majikins: this is not the right forum for that. Try Google. There are some good tutorials.
<majikins> i've followed some tutorials to the letter but my system does not work as they say
<majikins> but thanks - is there any irc channel you can suggest?
<ivoks> #ubuntu
<amitk> #ubuntu, #evms
<majikins> thank you - tried #ubuntu and will try #evms
<majikins> cheers!
<Kano> hi, when will lum get the 2 disabled iwl modules?
<Kano> if you like doing fun stuff you could update your lrm package to ati 8-01 ;)
<rtg> amitk: I suppose we ought to. otherwise madwifi isn't gonna work too well.
<amitk> rtg: should I pull it into LRM then?
<rtg> amitk: that where it lives, buts its a binary blob, so there is lots of pain associated with it.
<amitk> *sigh* i know
<LightHammer> hi guys, a question. I want to build a vanilla kernel for my 7.04, but where can i get the ubuntu kernel-patches? 
<Kano> shouldn bcm43xx be disabled or at least pci ids removed becuase the ssb module has the same pciids
<Kano> to be used with b43 / b43legacy
#ubuntu-kernel 2008-01-19
<Kano> same for prism54 as p54pci has same ids
<Kano> remove those from prism54
<Kano> very unlikely that a card will work when 2 drivers are loaded
<mjg59> Why?
<mjg59> Two drivers can't claim the same card
<Kano> they do
<Kano> in both cases
<mjg59> No. They don't.
<Kano> of course
<mjg59> Really. They don't.
<Kano> then buy glasses
<mjg59> No. It is impossible for two drivers to claim the same PCI device.
<mjg59> The kernel doesn't allow it
<mjg59> pci_enable_device() will fail
<Kano> so which driver do you think will udev load
<Kano> i would say the wrong one
<mjg59> It's arbitrary
<mjg59> It depends on the order of the inodes in /lib/modules
<Kano> funny
<Kano> why not make it deterministic by removing pciids like you did for ipw3945
<mjg59> That's a perfectly reasonable request
<Kano> my card only works with p54pci so remove it from prism54
<mjg59> There are some cards with that PCI ID that work better with prism54
<Kano> also i would say that b43 - loaded via ssb should be used now and pciids removed from bcm43xx
<mjg59> I'd agree
<Kano> softmac are more common today
<Kano> and p54pci supports those
<Kano> as far as i know did prism54 not even support wpa
<mjg59> Thanks, Kano
<Kano> prism54 is really outdated
<Kano> also i build the new 5 kernel without those ipw39/49 drivers. but it dont see em in lum yet
<amitk> Have you considered sending in a patch to remove the pciids? To kernel-team@lists.ubuntu.com and LKML...
<Kano> thats something i can not do
<amitk> Because?
<Kano> i do not write kernel patches, the max is that i seek for code to make a driver work with a new kernel
<Kano> therefore i did not announce my own variant of the dmraid45 patch for 2.6.24, but i would suggest to use it as soon as one official one appears like i did not the 2.6.22 kernel - you find still my message in your list
<amitk> Then you might be better served writing email to the above email address with the pciids you want removed and your reasons. Putting it on IRC on a Friday night is a hard way get this fixed.
<Kano> all?
<Kano> as they are the same
<Kano> i think it is easy enough to verify this with modinfo
<amitk> Put it in email so it does not get lost
<Kano> http://www.nabble.com/please-add-dm-raid45-2.6.22.1-20070724.patch.bz2-p13426286.html
<Kano> that was my mail last time
<Kano> there is no final 2.6.24 out therefore no offical patch for it yet
<Kano> but thats a needed one
<Kano> otherwise only kanotix will be able to use raid5
<Kano> as i patch that always
<amitk> Thanks, Kano
<tjaalton> amitk: hey, are you working on lrm?
<amitk> tjaalton: sure
<Kano> amitk: additional to that patch you need updated dmraid
<Kano> but i can provide you that too, thats not the problem
<tjaalton> amitk: I sent an email to the list earlier this week (forgot the subject though) with a couple of fixes
<amitk> tjaalton: for the nvidia?
<tjaalton> amitk: that and the convenience package for fglrx-amdcccle
<Kano> btw. as you like your lrm package so much: ati updated fglrx
<tjaalton> we know
<tjaalton> or, at least I do :)
<tjaalton> the list of known issues is longer than the list of fixed ones..
<tjaalton> which is no news
<Kano> i think only the widescreen bug was fixed not much more
<tjaalton> partly
<Kano> the most funny part was the modline fix mentioned in the release notes
<amitk> tjaalton: This week has been overloaded. We'll get to processing all the patches next week
<Kano> http://www.phoronix.com/forums/showthread.php?t=7427&page=2
<Kano> one more modelines -> fatal server error for me...
<tjaalton> amitk: there are also some reports about not being able to uninstall nvidia*. I'd like to fix that too
<tjaalton> seems to affect amd64 only
<amitk> ok
 * amitk calls it a day. Have a good weekend guys
<tjaalton> hehe
<tjaalton> "look at the time fly"
<tjaalton> sheesh
<tjaalton> I'll work on lrm this weekend and then send a patch on the kernel list..
<Kano> tjaalton: do you need a fix for the avm drivers or did you find it on your own?
<Kano> i mean the objcopy -L hack
<Kano> from Karsten Keil <kkeil@suse.de>
<mjg59> Is it legal to distribute the modified binaries?
<Kano> i see no problem, i even got the test hardware for free
<Kano> nobody will hurt you
<mjg59> Yes, but what does the license say?
<Kano> read it if you like to
<mjg59> You're the one offering the patch
<Kano> you find it in my avm package
<Kano> http://kanotix.com/files/thorhammer/kanotix/non-free/avm/avm_3.11-18.dsc
<Kano> this also adds a the cz mod of one driver
<Kano> if you want to add that to your repository be sure you have got drdsl for i386+amd64 in it
<Kano> capiinfo
<Kano> Number of Controllers : 2
<Kano> Controller 1:
<Kano> Manufacturer: AVM-GmbH
<Kano> CPU[AMD Athlon 64 X2 Dual Core 3800+ clocked at 1000.000 Mhz]  Kernel[Linux 2.6.24-5-generic i686]  Up[-5:32-]  Mem[-284.8/2027.1MB-]  HDD[-800GB(90%used)-]  Procs[-144-]  Client[Konversation 1.0.1]
<Kano> the drivers work
<Kano> as long as you know how to use em ;)
<Kano> look for fxusb_cz special handlinng
<Toma-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/156050/comments/13
<ubotu> Launchpad bug 156050 in linux-source-2.6.22 "r8180 and ieee80211_rtl cause total system lockup." [Undecided,Won't fix] 
<Toma-> could someone PLEASE re-enable this driver? at least so it can be tested?
<Lure> can somebody define upstream packaging for linux-source 2.6.2[04] packages, so that we could link to upstream bugs at bugzilla.kernel.org (and use LP's bug tracking)?
<Lure> for bug 104837, I was unable to add link to upstream bug tracker, as the upstream link is not defined
<ubotu> Launchpad bug 104837 in linux-source-2.6.20 "kernel warns BUG: at fs/inotify.c:172 set_dentry_child_flags()" [Medium,Confirmed] https://launchpad.net/bugs/104837
<Lure> [08:51] <persia> Lure: You'll first need to use https://launchpad.net/ubuntu/feisty/+source/linux-source-2.6.20/+edit-packaging to link the feisty kernel to an upstream project.  You may need to define the project.
<laga> btw, i posted an updated patch to bug #182603 . are patches like that one actually suitable for inclusion? (no, not pushing, just wondering if there's any hope for me :))
<ubotu> Launchpad bug 182603 in linux "Please add simple lhash patch for aufs" [Wishlist,Triaged] https://launchpad.net/bugs/182603
<amitk> laga: is this patch not going to make it into 2.6.24?
<laga> amitk: i don't think the aufs maintainer has submitted it for inclusion yet. maybe he will do that when he submits aufs. 
<blueyed> Can you confirm that my investigation on bug 177713 is correct?
<ubotu> Launchpad bug 177713 in boinc "2.6.24-2: Regression with idle cpu cycle handling" [Medium,Triaged] https://launchpad.net/bugs/177713
<crimsun> yes
<crimsun> I was just about to comment that CFS is "causing" that
<blueyed> Ok. So all those "use idle cpu in the background" programs need to get patched to change the cpu_share value for their user to something like 2?
<crimsun> it's a feasible approach, but it would need more testing
<blueyed> I think it's cumbersome to change all those packages. To be more futureproof we might want to use cgroups instead and put those scripts in this group - to make it easier to just apply cpu_share=2 to all of them.
<blueyed> btw: I don't think cfs is good in this regard: a totally niced process from another user should not hug the whole cpu slices assigned to this user.
<blueyed> I've linked a patch in the lkml post, it may be worth testing, if it applies and makes sense (just skimmed it)
#ubuntu-kernel 2008-01-20
<kritzstapf> hi, update-initramfs -u brings up a warning about invalid lines in /etc/crypttab, even when the only line is "crypt /dev/hda5"
<Banana_Joe> hello :) i ahve got 1 question. why do you name your kernel like 2.6.22-14 and nocht 2.6.22.x ( wath it is ) ... it makes me a little bit confuse because i dont know wath kernel im using. so why are you soing it? :)
<Banana_Joe> any one here to answare my question?
<Banana_Joe> oO
<laga> Banana_Joe: the ubuntu kernel is patched anyways. there's only limited usefulness in comparing it to upstream
<laga> (IMHO)
<Banana_Joe> laga: i dont thing that this is good sorry. if a stable version of ubuntu releast wo wont change the kernel. but why not. any other distribution is updateing their kernel to the next kernelversion so i mean the update for the kernel :) ... but why not ubuntu? oO
<jln> Hi, sorry to disturb, but I have a kernel related problem, although not development I was hopping for some debug help? Problem is that my P5K SE Asus motherboard based Desktop simply locks when hitting suspend. I'm using Gutsy, and I think /proc/acpi/wakeup looks a little funny..
<jln> Could anyone just slightly hint me in some direction?
#ubuntu-kernel 2009-01-12
<pwnguin> wtf
<CarlFK> can it_rsa hold multiple private keys?
<pwnguin> sure
<pwnguin> but you probably wanted id_rsa ;)
<CarlFK> er, yeah, that.
<CarlFK> thaks
<pwnguin> actually, i donno about id_dsa
<CarlFK> I would think ssh would have an option to specify which key it tried to use
<CarlFK> if it supported multiple keys in one file 
<pwnguin> or perhaps it tries all of them ;)
<pwnguin> but i dont quite understand why -kernel is the place to ask about ssh
<CarlFK> it isn't.  I got confused :)
<CarlFK> ... for linux?  made me think this was #linuxhelp :)
<pwnguin> ok ;)
<soren> How do I pass a paramater to the modules that you're now compiling into the kernel?
<soren> <modulename>.<paramter>=<value> on the kernel command line, perhaps?
<smb_tp> soren, put them into a file in /etc/modprobe.d. Format "options <module> <name>=<value>"
<smb_tp> soren, Oh forget it
<smb_tp> Should get my eyes open
<smb_tp> Yeah, yours is correct
<soren> So there's no way to change these values, since I can't rmmod and then modprobe with new options?
<soren> *sob*
<smb_tp> soren, If the code has no /proc or sysfs interface I fear not.
<soren> Oh, right.
<soren> AFAIUI, all module paramaters are exposed in sysfs these days?
<soren> Althought, they might be read-only. :(
<mjg59> soren: /sys/module/modulename/parameters
<mjg59> Should be there even if it's statically linked
<soren> mjg59: But that doesn't necessarily mean I can change the value. Some might require a reinitialisation.
<mjg59> soren: Right
<mjg59> If it's marked read/write then it should work on the fly
<soren> Hmm.. I don't even see processor.max_cstate exposed in sysfs anymore.
<soren> if the module_param is created with mode 0000, does that mean it doesn't even get exposed in sysfs?
<soren> include/linux/moduleparam.h suggests that that is indeed the case.
<soren> So I lose. :(
<soren> I have a laptop that makes a really annoying noise when on AC in C3 and C4, so I want to set max_cstate=2 when on AC and max_cstate=4 when on battery. I don't see a way to do that now.
<mjg59> You can use the pm_qos stuff to mimic that
<mjg59> If you set the dma latency to a number smaller than the C3 latency
<soren> *chuckle*
<soren> Well, yes, that would work.
<soren> Ok, so how do I find the relevant numbers?
<soren> And once I find it, I just write that as a signed 32 bit integer to /dev/cpu_dma_latency and hold it open until I switch to battery?
<soren> mjg59: in /proc/acpi/processor/CPU0/power, the C3 line reads (among other things, of course): "latency[057]", and the same number for C2 is 001... So I just put e.g. 56 in /dev/cpu_dma_latency ?
<mjg59> soren: Yeah, though I can't remember if the units are the same
<soren> mjg59: I'm not sure how to find out. include/acpi/processor.h just says the latency attribute is a u32. No mention of units.
<mjg59> soren: I /think/ it's usec
<soren> Lovely. That's what /dev/cpu_dma_latency expects as well, apparantly.
<soren> mjg59: Thanks. I'll tyr.
<soren> try, even.
<soren> mjg59: It seems to work. Thansk!
<soren> Thanks, even!
<soren> (typing is hard)
<mdz> evening
<mdz> (wrong window)
<marijus> hello, did anyone mage to build 2.6.29-rc1? i tried yesterday but build failed...
<marijus> sorry typo... mage=manage
<TimStarling> how do you debug the kernel in ubuntu?
<TimStarling> just stare at the source until the truth becomes clear?
<TimStarling> the buddha method?
<apw> TimStarling, some of that yes
<cking> TimStarling: a combination of staring at the source and also the use of printk() :-)
<apw> some bits have debug you can enable, others you add as you stare
<TimStarling> I have a production server with a top that looks like this: http://p.defau.lt/?84j7MTR_v4d7BUgx5E91bw
<TimStarling> it works just fine for a few days, then dies
<TimStarling> I could add printk() all over the whole kernel (one of us thinks the bug could be pretty much anywhere)
<TimStarling> but a few days' worth of output might be a bit ugly
<apw> is that mysql really 30GB ?
<apw> how much ram do you have?
<TimStarling> 32 GB
<apw> can you define dies
<soren> Erk... Those kswapd processes don't look too good.
<TimStarling> connections to mysql time out, attempting to attach with strace hangs forever
<TimStarling> soren: no shit
<apw> how is mysql aquiring all that memory?  large shm segments?  something else?
<soren> You only have 1GBof swap?
<TimStarling> 30GB is normal
<TimStarling> 31 actually
<apw> i would suspect the machine is trying to find something to release cause it has no swap
<soren> With 32 GB of RAM and a mysql server that wants to eat 31 GB of memory, 1 GB of swap sounds like a disaster waiting to happen.
<apw> and if the memory mysql has is anonymous this can trigger almost infinite list active/inactive list scanning
<TimStarling> it may be that the margin is too small, our DBA likes to set it real small
<apw> in older kernels, what version is this
<TimStarling> Linux db18 2.6.24-22-server #1 SMP Mon Nov 24 20:06:28 UTC 2008 x86_64 GNU/Linux
<TimStarling> stock ubuntu kernel
<apw> yep ... .24 does not have the fixes for that
<soren> What else is running on the machine?
<soren> The run queue is ~22..
<TimStarling> http://p.defau.lt/?GNY7y_PM7vcQfy4C4bf0xQ
<TimStarling> could be FS-related, with the logrotate processes
<TimStarling> but I've seen OOM conditions crash ubuntu kernels before so adding a bigger margin is an obvious thing to try
<TimStarling> apparently changing the FS was already tried
<TimStarling> could be a block driver
<apw> i would suspect the unevicatable pages problem at first glance, kswapd's running madly and achieving nothing
<apw> note they arn't in D writing stuff, they are running
<apw> the changes to fix that are major and so not likely to appear in a hardy kernel
<apw> _if_ the memory that mysql is at least in theory swappable adding swap that will never be used may prevent the issue (iirc)
<TimStarling> are there fixes in 8.10 that I should know about?
<apw> i believe the fixes are in 2.6.28, so that would be jaunty
<apw> possibly adding swap would tell you if that is the issue, though getting it back will be hard with only 1gb by default
<TimStarling> the easiest thing is to reduce mysql's memory usage back to 28 or so
<apw> if it is reliable there yes
<apw> if the problem is the spinning lists issue, then that tended to get reported by people who had 32GB of ram or more
<apw> and tended to have 0 swap as 'who needs swap with this much ram'
<TimStarling> mysql's memory usage is very stable, it just allocates a big chunk at startup and uses it for most things
<TimStarling> we know enough to not set swap=0, lots of bugs if you do that
<TimStarling> ok, going to reboot it, last chance if you want more data
<TimStarling> presumably there's some page table overhead, what's the effective amount of memory available for mmap() if there's 32GB physical?
<TimStarling> I'm just wondering if that 30.9GB virtual figure for mysql was hitting it
<apw> i tend to work on the rule of thumb that 10% is used by the system but you were clearly 'at the end' as you kswapd was awake
<apw> you are only talking about having 1.1GB free, i have some 180MB missing even before the kernel gets going for the kexec kernel, so you are squeezing the entire system (other than mysql) into 900MB
<TimStarling> mmm
<TimStarling> looks like our (stable) 16GB servers have about 1.7GB free for non-mysql stuff
<TimStarling> so I should probably be thinking about keeping the same proportion free, ~3.4
<TimStarling> we would like to have graceful OOM behaviour at some point, we've had a lot of trouble with that on our application servers
<TimStarling> because they have a load-dependent memory usage
<TimStarling> maybe we should package our own kernels
<rtg> soren: is there any reason we should enable CONFIG_NFSD_V4 in the hardy -virtual flavour?
<rtg> s/should/shouldn't/
<soren> rtg: I can't think of any, no.
<rtg> soren: thanks. looks like it must have been an oversight.
<persia> Good day.  I'm trying to understand the difference between the "lpia" and "lpiacompat" kernel flavours.  A diff -u of the config confuses me, as config.lpia seems to have CONFIG_M586=y and config.lpiacompat seems to have it unset, which is contrary to the information I have previously received.  Is there a set of known devices on which the lpia kernel is not expected to work?
<rtg> persia: lpiacompat was built for a standard PC, e.g. a   non-Atom CPU.
<rtg> at least, if I recall correctly.
<persia> rtg, That's the information I had before, which is why I'm confused at the config values I'm seeing.
<persia> Atom doesn't need CONFIG_M586=y and many "standard" PCs (e.g. Via C7M) do.
<rtg> where is Amit? He knows all these details.
<persia> You ask the hard questions :)
<rtg> soren: where does the JeOS kernel image come from in Intrepid? 
<soren> rtg: The server image.
<soren> It's the same image, with a stack of modules ripped out.
<soren> I think BenC calls it subflavours?
<rtg> soren: this guy is complaining that NFSv4 doesn't work, but it _is_ enabled.
<rtg> ah, perhaps too may debs are ripped out?
<apw> sconklin, ok ...  you have filed a bug for the apport changes.  acording to sources (#ubuntu-bugs) it seems the appropriate thing to do is to share that bug for all the changes for this overall feature so that they all have the same number and track together
<persia> Well, assuming they are all related to the same issue.
<sconklin> apw: that makes a lot of sense
<sconklin> I'm glad I gave it a generic title
<apw> it can be changed anyhow!
<fabbione> hi gusy
<fabbione> who is in charge of the hardy-updates tree?
<fabbione> rtg: ?
<rtg> fabbione: dude
<rtg> fabbione: uh, smb_tp is the Hardy guy
<fabbione> rtg: hey.. who does pull from linux-2.6.24.x into hary tree?
<fabbione> something is hutterly wrong in the kernels you are releasing
<fabbione> smb_tp_: you there?
<rtg> how so?
<fabbione> there are missing commits
<fabbione> and changelogs are missing entries
<rtg> missing from stable?
<smb_tp_> fabbione, I am
<fabbione> yes
<fabbione> smb_tp_: i am looking at linux (2.6.24-23.46) hardy-proposed; urgency=low
<fabbione> according to the changelog:
<fabbione> lots of entry for bug: #301608
<fabbione> that is merging 2.6.26.4 into hardy
<fabbione> but upstream 2.6.24.4 has:
<fabbione> commit 68b498d251d97de9adda518fda42cfe1451063b7
<fabbione> Author: David S. Miller <davem@davemloft.net>
<fabbione> Date:   Thu Mar 6 14:47:20 2008 -0800
<fabbione> SPARC64: Loosen checks in exception table handling.
<fabbione> [SNIP]
<fabbione> that is missing from the hardy tree completely
<fabbione> or at least is not in the released tarball
<rtg> I think thats because we haven't incorporated all of the stable commits in Hardy as  we have for Intrepid. smb - is that still the case?
<fabbione> this is an example of a missing commit
<fabbione> broken changelog:
<fabbione>   * Linux 2.6.24.6, 2.6.24.7
<fabbione>     - LP: #301634
<smb_tp_> rtg, No the intention was to gte all.
<smb_tp_> Let me see
<fabbione> ^^ points to the same bug as 2.6.24.4 and they have no references to the 2 security bugs fixed in those 2 upstream releases
<fabbione> smb_tp_: i simply need to know if you are going to pull them all or not..
<fabbione> as easy as it, it means for me removing ubuntu from all my machines or keeping it around
<smb_tp_> fabbione, They should all get pulled
<fabbione> smb_tp_: ok then you should check why that one is not there
<fabbione> 68b498d251d97de9adda518fda42cfe1451063b7
<fabbione> i know this is missing because without it my hardy sparc firewall doesn't boot
<rtg> fabbione: its in the hardy git repo.
<fabbione> rtg: it's not in the released tarball
<rtg> it may not have been promoted to -updates yet
<fabbione> rtg: it is according to the changelog...
<fabbione> i don't use proposed.. that kernel has been copied from proposed to updates
<rtg> fabbione: gimme a minute....
<fabbione> sure even 20
<fabbione> i am honestly worried that something in the release process went wrong
<fabbione> on the other side i also have the issues to keep my machines running :)
<fabbione> i am sure you can understand
<fabbione> anyway you'll sort it out :)
<rtg> fabbione: 2.6.24-23.46, right?
<fabbione> yes
<fabbione> do you need any more info?
<smb_tp_> fabbione, We well do
<fabbione> my wife is about to yell at me if i don't show up
<smb_tp_> fabbione, No I don't think so
<fabbione> ok
<fabbione> i'll pass by in about 2 hours..
<fabbione> root@vultus5:~/linux-2.6.24# patch -p1 < ../fix_sparc.diff 
<fabbione> patching file arch/sparc64/mm/fault.c
<fabbione> ^^^fix_sparc is that commit on top of that kernel..
<fabbione> so it is missing somehow :)
<fabbione> later!
<fabbione> re
<fabbione> rtg, smb_tp_: found anything?
<smb_tp_> fabbione, Yes, found some patches missing (including yours) for 2.6.24.3->2.6.24-4
<fabbione> smb_tp_: ok!
<smb_tp_> I did not understand however, the thing about 2.6.24.6/7
<fabbione> that's something to do with changelog
<fabbione> not sure if it's automatically generated or manually done
<fabbione> but:
<smb_tp_> automatically
<fabbione> then it's wrong :)
<fabbione> look at the same kernel changelog
<fabbione>   * V4L: Fix VIDIOCGAP corruption in ivtv
<fabbione>     - LP: #301634
<fabbione>   * Linux 2.6.24.6, 2.6.24.7
<fabbione>     - LP: #301634
<fabbione> ^^ last two entries for that release
<fabbione> .6 and .7 points to the same bug as .4
<fabbione> (or .5... doesn't matter)
<fabbione> 2.6.24.6 fixes one bug, not reported in the changelog
<fabbione> .7 fixes another bug.. not reported in the changelog
<fabbione> as long as the fixes are there, this is "minor" but makes the changelog incomplete
<smb_tp_> There might be some not in that log because they got fixed before with another name potentially
<fabbione> worth checking tho
<fabbione> need to reboot my firewall.. brb
<smb_tp_> The updates were only to track importing the patches from -stable that not yet went into hardy
<fabbione> gotcha
<fabbione> re
<fabbione> well at least that fix works :)
<rtg> smb_tp_: I think I remember pointing out that there was a typo in the changelog for that bug number.
<maxb> ooi, what does SAUCE mean in Ubuntu kernel changelogs? Googling was unfruitful
<smb_tp_> maxb, That is a patch that is not (yet) upstream
<rtg> maxb: we use it to denote patches that are either not upstream, or patches that will never get upstream
<smb_tp_> rtg, Hm, somehow I am blind to that. I posted the missing 6 to the list
<rtg> smb_tp_: you are blind to what?
<fabbione> smb_tp_: did you check that manually or a git pull did show them?
<rtg> oh, the typo?
<smb_tp_> rtg, yes
<smb_tp_> fabbione, I compared the export names and checked all missing from my list
<rtg> smb_tp_: maybe it was a different changelog entry.
<fabbione> smb_tp_: it might be wise to check the whole tree tho..
<fabbione> smb_tp_: just to make sure other bits didn't get lost in other pulls
<smb_tp_> fabbione, I will double check that
<fabbione> smb_tp_: is linux_2.6.24.orig.tar.gz a pristine copy from upstream or is it generated from your git trees?
<fabbione> smb_tp_: if it's a pristine copy from upstream, then it's "simple"...
<fabbione> if it's generated from your git tree, you want to check the whole thing from scratch
<rtg> fabbione: its pristine from upstream
<fabbione> rtg: ok.. then it's simple..
<smb_tp_> fabbione, don't think that simple the orig is the tree at point of first release
<fabbione> smb_tp_: yes it's simple in git.. you can just branch out v2.6.24 in git and then compare the commits in your tree with whatever is in 2.6.24.x
<fabbione> smb_tp_: everything local to ubuntu has proper UBUNTU or SAUCE tags. EVerything else either matching commits (everything in .24.x should be there) or a very detailed commit entry
<fabbione> but starting from v2.6.24 tag and going, will reduce the load a lot
<fabbione> anyway.. again... you will sort it out :)
<smb_tp_> I guess so :)
<fabbione> you are all young guys full of energy :)
<smb_tp_> who? young? :)
<smb_tp_> fabbione, rtg Ok, I went through the remaining commits of 4,5 and 6. Looks like those from 3 were the only missing ones
<fabbione> "Remote root kernel exploit..." ...
<fabbione> :)
<fabbione> ^^doens't exist but can scare the hell out of people ;)
<smb_tp_> heh, well you can scare people even by "panic can't find /" as a fortune message. :)
<fabbione> speaking of which.. do I get a pony for finding this problem? :)
 * fabbione really really wants a pony
<rtg> fabbione: I'll buy you a beer the next time we cross paths, how about that? I can't afford a pony.
<smb_tp_> Me neither
<smb_tp_> But we can make two beers of it
<fabbione> rtg: ahha works for me.. 
<fabbione> rtg: even if i doubt somebody will ever fly me to a UDS or anything :)
<smb_tp_> fabbione, There might be other opportunities ... :)
<fabbione> smb_tp_: very unlikely tho.. i am located in DK..
<smb_tp_> I'm in DE (just one letter difference) :-P
<fabbione> smb_tp_: well you could.. rtg might be problematic :)
<rtg> fabbione: Its Barcelona in the spring...
<fabbione> rtg: again?
<fabbione> we have been close to Barcelona
<fabbione> rtg: do you have dates already?
<rtg> It was Seville last time in Spain. this one is somewhere in the Catelonia district. May 22 I think.
<fabbione> rtg: there was one before Seville .. a long time before Seville.. in a small city close to Barcelona :)
<fabbione> rtg: at that time the kernel team was made of me and.. me...
<rtg> ah, I wasn't around for that one.
<fabbione> nope :)
<fabbione> not even Ben was there
<rtg> UDS - 25-29 May
<fabbione> IIRC it was right after warthy release
<fabbione> ok.. i'll keep an eye
<fabbione> can't efford to fly on my own.. maybe i can find a sponsor or two
<rtg> send an email to Mark :)
<fabbione> he is not my only sponsor :)
<fabbione> night guys
<fabbione> take care
<fabbione> and try to get those fixes out :)
<fabbione> so i can finally stop building my kernels ;)
<rtg> they'll percolate in -proposed for awhile. Should be uploaded in the next day or so.
<smb_tp_> Right, I am on it
<fabbione> yeah that's fine...
<fabbione> day more, day less.... worst case /. will have a nice story of 100's of Ubuntu machines being r00t3d :D
<laga> is there a new root exploit?
<tjaalton> hum, how come linux-libc-dev is only for i386/amd64/armel? since it contains the drm headers now the xserver build fails on other archs (no drm.h)
<tjaalton> although armel fails too..
#ubuntu-kernel 2009-01-13
<persia> tjaalton, Have you also looked at the other kernel trees?  (linux-ports, linux-lpia).  I think those would be the sources for linux-libc-dev for architectures for which the kernel isn't provided by linux.
<tjaalton> persia: oh right :)
<tjaalton> I didn't
<tjaalton> anyway, the armel build should've pulled linux-libc-dev AIUI, since libc6-dev should depend on it
<TimStarling> apw: thanks for your help yesterday
<TimStarling> Domas still hasn't made a showing so I just went ahead and restarted most of the 32GB servers with 3GB less target mem usage
<TimStarling> http://ganglia.wikimedia.org/pmtpa/?m=mem_report&r=hour&s=by%2520hostname&c=MySQL&h=&sh=1&hc=4&z=small
<CarlFK> I am getting a kernel panic in about 10 min when running some firewire cam stuff 
<CarlFK> 2.6.27-9 generic x64
<CarlFK> I am now trying  -7 
<apw> CarlFK, also try the -11 kernels in -proposed
<CarlFK> will do
<afflux> Hi! bug 51779 was about having to manually load the ircomm module and to  create some /dev/ircommX devices. The devices are now created automatically, after loading ircomm manually. Can I consider this fixed?
<ubot3> Malone bug 51779 in linux-source-2.6.17 "IRDA-Devices are not created by default (ircomm: 161-0" [Wishlist,Won't fix] https://launchpad.net/bugs/51779
<CarlFK> -7 just paniced.  but i got -11 installed in time :)
<CarlFK> -11 panic: up 23 min, load average: 1.33, 1.56, 1.18 Cpu0  : 82.0%us,  1.3%sy,  0.0%ni, 16.7%id,  
<CarlFK> I bet I should pull nvidia...
<CarlFK> what's the command to rebuild menu.lst?  (it adds lines for the kernels it finds in /boot)
<maxb> update-grub
<CarlFK> thanks
<CarlFK> update-grub lies: Found kernel: /boot/vmlinuz-2.6.27-11-generic ... Updating /boot/grub/menu.lst ... done http://dpaste.com/108526/
<Kano> hi rtg , did you change some dell blacklight settings in the last kernels?
<Kano> somebody with dell vostro 1000 had working fn keys for backlight but then it stopped working
<rtg> Kano: apw did in Jaunty. perhaps http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=e9c7dae04d7168ce7f3b823a1d7349e2212e29fb
<Kano> hmm i guess i revert that
<apw> there are a bunch of people in various tates of regession against hardy, the fixes there fixes most.  with the stack there we have been able to get all of the reporter working either automatically or diabling acpi_backlight on the command line.  a more complete fix needs to come from upstream
<Kano> or i just compile 4.9 kenrel again
<mjg59> Someone just needs to figure out why i915 interrupts don't work properly
<apw> lool, would you be able to test an lpia kernel for me, the test image is in my ppa: deb http://ppa.launchpad.net/apw/ubuntu jaunty main
<apw> as linux-lpia as 'normal'
<lool> apw: Yup
<apw> rtg, ok i've squashed down all the debian/* junk into one commit and pushed the new tree to zinc.  ubuntu/ubuntu-jaunty-lpia.git
<rtg> apw: cool. thanks.
<apw> note there are some AUTO commits in there which are built but amits automation
<apw> now its all cleaned and squashed the delta is minute, four patches
<rtg> apw: you want it packaged and uploaded?
<apw> i'll counter with two questions:
<apw> 1) is it any use without -lum et al?
<apw> 2) should we wait for the testing smb and lool are doing
<rtg> apw: the kernel needs to be uploaded _before_ LUM for header packages
<apw> there is actually only a  lrm it seems, no idea what is in it yet
<rtg> apw: until we upload linux-lpia-meta no one automatically pulls the package.
<apw> as its a rebase tree, a new kernel isn't the end of the world its just a bounce of the .N at the end, so if you think it looks sensible as a first step thats fine with me
<lool> apw: I understand that the debian/ changes were not merged; if you intend to keep this tree, I guess you might want to merge the debian/ changes from ubuntu-jaunty.git into ubuntu-jaunty-lpia.git perhaps?
<rtg> lool: can't we just start with what it is? Its a 2.6.28 kernel with some UBUNTU patches applied, which _are_ represented in the changelog.
<lool> rtg: I thought you guys wanted to minimize delta between linux and linux-lpia
<lool> And I wish that too
<apw> yeah we do, but you wanted it yesterday too
<lool> Sure, I'm not saying this is urgent
<lool> Sorry, I should have hinted this is minor
<rtg> lool: I really only care about code delta. The debian directory changes don't matter much.
<apw> i can't see why we have a different debian directory in here really
<apw> we should probabally pull the differences out that matter and make them a delta on the top of the normal debian dir
<lool> rtg: These include config changes for instance
<lool> All the work you've been doing on demodularizing the kernel
<rtg> I'll get back to you. kernel IRC meeting right now
<apw> those of course are lpia specific so less difficilt to manage
<lool> rtg: I also have decent ARM hardware (Thecus N2100 I think it's 600 MHz 512 M) but not running jaunty yet
<lool> If it's something blocking you, I can prioritize bringing it up
<rtg> lool: I need to get this fixed anyway since its sort of a long term issue.
<lool> Obviously porter box would be much more convenient
<rtg> I'll just figure out qemu, I have a dual quad core.
<lool> It's relatively slow and segfaults a lot with lots of memory
<lool> But I'm glad you'll try that out, will make you have a look at the video issue :)
<persia> apw, So, you're the current lpia person?  Would you be able to help me understand the difference between lpia and lpiacompat?
<apw> erm, i think thats an over simplification.  i touched it last :)
<persia> OK.  Last I looked, "lpia" had CONFIG_M586=y and "lpiacompat" had CONFIG_M586 is not set.  The information I received originally was that "lpia" was for A1x0 and Atom, and "lpiacompat" was for everything else.  Something seems not to match.
<apw> persia, but the difference as i see it is that lpia has lots of useless things turned off so is leaner
<persia> "useless"?  Would that be why I have better device support with -generic on i386 on my Atom device than with lpia?
<persia> Actually, ignore the second question :)
<apw> persia, very probabally, lots of things like ATM AppleTALK, HIPPI, IPX etc are off in that kernel
<persia> So, is there any way to tell which would the better kernel to install between lpia and lpiacompat?
<persia> Oh, those are useless :)
<persia> I thought maybe M586 would be the key, but it seems backwards from how I would expect it.
<apw> the only difference is config, and the difference there is in the git tree
<persia> So when should "lpia" be installed, and when "lpiacompat"?
<persia> About 6 months ago, amitk told me that it was 586/686 as a split, but it seems to have moved.
<persia> (or is opposite what I expected, or I misunderstand the CONFIG_M586 config option)
<apw> i can't say i have definitive knowlege, but i would say lpia is for real devices in the field (it has 586 set), and lpiacompat might be for buildd's or something, running the same code on a normal machine
<persia> So every sensible end-user device should just have "lpia" installed, and if that doesn't work, users ought file bugs?
<persia> (noting that some users may be told "Use i386")
<apw> persia, that sounds reasonable to me yes
<persia> Thanks.  That makes the necessary installer magic really simple :)  If later something (e.g. /proc/cpuinfo flags) can be used to differentiate or something, we can change to support that.
<rtg> apw: did you use some variant of rebase-intrepid when creating the Jaunty lpia tree?
<apw> yes, i did exactly that
<apw> rtg, i used it to handle the auto part, then pulled the patches in by hand
<apw> and then massaged it to fold them down
<rtg> apw: but you didn't update the script, right? It still references Intrepid
<apw> yes that is partly error, partly deliberate
<apw> as to do an intrepid to jaunty conversion on has to hack it to be scitofrenic
<apw> so a new rebase-jaunty needs to be in there, but i've not had a chance to test it
<rtg> apw: ok, I'm just cleaning out some arm cruft
<apw> could you see if we need the -virtual thing in control while you are there
<rtg> apw: I don't think we do. though its in the Intrepi LPIA tree, its never build 'cause it doesn't exist within the LPIA arch
<apw> i was confused by it, but left it cause it was in intrepid too
<rtg> apw: if you look in debian/sub-flavours/virtual.vars you can see thats its only built for arch="i386 amd64"
<apw> yeah
<apw> rtg is there some trick to building an lrm?
<tjaalton> apw: the new -intel fails to build again using the kernel drm headers.. libdrm 2.4.3 has something newer that's needed.. just a heads up, can't hunt commits right now: http://pastebin.com/m3a90934c
<tjaalton> (the new being 2.5.99.2)
<tjaalton> post-alpha3 stuff anyway..
<apw> tjaalton, ok thanks
<Kano> hi, are there somewhere older 2.6.28 kenrels than -4.9?
<Kano> as deb
<klasikahl> is kernel-package maintained by the kernel team?
<klasikahl> the upstream is severely broken... it produces unusable headers, for one.... see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475036 and http://sidux.com/PNphpBB2-viewtopic-t-11109.html
<ubot3> Debian bug 475036 in kernel-package "kernel-package: kernel-package is suffering from bit rot, and is severly broken" [Serious,Closed] 
<klasikahl> anyway the version in ubuntu is likewise affected
<klasikahl> be back in a few... lunch
<klasikahl> it appears the fix received hex: 1872151 according to a changelog for 11.002
<rtg> apw: still having problems with lrm?
<rtg> apw: jaunty lpia uploaded
<apw> rtg, no i think i got myself sorted basically
<apw> it needs the headers
<rtg> apw: yeah, needs kernel headers
<apw> rtg, so whats the rules on version matching.  i assume its supposed to be the same as the kernel 
<rtg> apw: only the ABI has to match. the minor (uopload) number is not relevant
<rtg> upload, even
<apw> ahh thats better
<rtg> apw: you can look in the generated /debian/control to see what it depends on
<apw> doh of course
<Kano> rtg: btw. it seems the 4.9 kernel without that backlight patch works
<rtg> apw: ^^
<Kano> for vostro 1000
<Kano> i fetched the u binary
<Kano> because my pbuilder failed with the source
<apw> 'that backlight patch' whats the title for that one
<Kano> there are not so many patches from .9 to .10
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=e9c7dae04d7168ce7f3b823a1d7349e2212e29fb
<apw> that one was the one smb_tp reverted i believe
<apw> in intrepid at least, he replaced it with something else
<smb_tp> apw, No just reverted
<smb_tp> at least this code
<apw> i thought you put some other change on the top, the one i reviewed, to get things working
<smb_tp> for the time being I just allowed acpi and vendor drivers concurrently
<smb_tp> ok, so speaking i replaced it
<apw> thats the one i was thinking of
<smb_tp> The -4.9 without that patch in question will probably work mostly
<smb_tp> just not for T61 and Asus...
<Kano> yes, it did work, just not 4.10
<smb_tp> Kano, At least with Intrepid there were some happy some not
<Kano> maybe make an extern video override package
<smb_tp> I guess we got a workable state for Intrepid now. For Jaunty it is more of getting the acpi driver better in upstream
<rtg> apw: why does scripts/setlocalversion in the kernel keep adding cruft to include/config/kernel.release. i.e., 2.6.28-4-orion5x-00002-gf1820d3
<smb_tp> rtg, There was a config option about local option that adds git sha's 
<smb_tp> Trying to remember
<apw> it does that by default if the tree isn't clean
<apw> or something like that
<apw> you should never see that in the debian/build thing
<smb_tp> CONFIG_LOCALVERSION_AUTO
<rtg> distclean'ing
<rtg> smb_tp: you're a genius.
<smb_tp> I think it was if this option is set and the head is not tagged it creates that stuff
<rtg> its been driving me nuts. keeps hosing up my armel build
<apw> heh ... yeah its not always on
<rtg> well, it is inconsistently set in the jaunty tree. fixing that now
<apw> thats very wrong...
<apw> so waht defines the source package for a package other than the Source: line in debian/control?
<apw> dpkg-gencontrol: error: source package has two conflicting values - lpia-linux-restricted-modules and linux-restricted-modules
<rtg> apw: the source package name is defined in debian/changelog
<rtg> apw: uh, maybe it needs to be the same as debian/control
 * apw tries that
<rtg> apw: looks like you have the name backwards
<rtg> should be linux-restricted-modules-lpia
<apw> i didn't change that
<apw> (i don't think)
<rtg> where are you getting lpia-linux-restricted-modules
<rtg> ?
<apw> thats in control.stub.in
<apw> so at least i am past there
<rtg> apw: not in the intrepid version, its linux-restricted-modules-lpia
<apw> wtf
<apw> rtg not in the one i have cloned here:
<apw> ~/git2/ubuntu-intrepid-lpia-lrm
<apw> apw@dm$ head -1 debian/control
<apw> Source: lpia-linux-restricted-modules
<rtg> apw: zinc.canonical.com:/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-intrepid-lpia-lrm.git ?
<rtg> rtg@lochsa:/usr3/ubuntu/ubuntu-intrepid-lpia-lrm$ head -1 debian/control
<rtg> Source: linux-restricted-modules-lpia
<rtg> apw: huh, I just updated, now I have the same as you: lpia-linux-restricted-modules
<rtg> apw:   * Change the source package name to work around Soyuz.
<rtg> apw: Steve K has been messing with it.
<apw> no wonder its all broken
<rtg> apw: well, it built for Intrepid, so it shouldn't be too far off for Jaunty.
<calc> anyone happen to know if e4defrag is in jaunty yet?
<calc> it appeared to be part of the patchset for 2.6.28 but as its a userland tool I wasn't sure if it made it into jaunty
#ubuntu-kernel 2009-01-14
<elmargol> I have installed 2.6.28 and 2.6.28-rc8 and somehow 2.6.28 can not find /lib/modules/2.6.28 :(
<elmargol> Is kinitramfs -o /boot/initrd.img-2.6.28 the valid command to create the initrd?
<elmargol> my /root is encrypted ...
<siretart> why is there no linux-image-debug-2.6.27-9-generic on security.ubuntu.com? `apt-cache madison linux-image-debug-2.6.27-9-generic` claims it to be produced from the source package linux_2.6.27-9.19, but it does not seem to be published at all!
<DeSony> Hi, I want to know: In the boot process, does BIOS is loaded into the memory (RAM)?
<DeSony> I mean, does BIOS in loaded from ROM to RAM at the boot time.??
<Keybuk> I believe that BIOS is executed directly from ROM
<Keybuk> (well, flash ram)
<DeSony> I am reading about kernel boot process. In one of the document it is given as follows: "Given the different uses of BIOS functions, the BIOS is made up of two parts: the POST code and runtime services. After the POST is complete, it is flushed from memory, but the BIOS runtime services remain and are available to the target operating system."
<DeSony> what does it means "it is flushed from memory"?
<Kano> hi apw , what do you want to do about the backlight problem?
<lool> sconklin: I've sent the Poulsbo update as a patch against hardy-lum; it's pending moderation (it's 60 kB for a limit of 40)
<lool> smb_tp_: ^ and that's post-A3 stuff of course
<rtg> lool: hey, I know the moderator. 
<smb_tp_> me too :)
<lool> rtg: Happy to send it in a different form if 60kB is too big
<sconklin> lool: I'm feeling quite a bit better today, I'll have a look
<lool> sconklin: Glad about that; FYI I'm feeling awful, I think we swapped
<rtg> lool: no problem. its done
<smb_tp_> lool, Well for hardy post 8.04.02
<sconklin> lool: Mine was viral, nothing to do for it except sleep
<smb_tp_> lool, but I will look into it
<lool> smb_tp_: What actual date does that mean?
<smb_tp_> lool, The release is scheduled next week. So right after that
<lool> smb_tp_: Ack
<lool> thanks
<lool> rtg: Thanks
<lool> BTW folks, I massaged git-format-patch's output into an email; I'm sorry if the result is incorrect, and am happy to fix it if I messed up things
<tjaalton> what kernel are the jaunty ports builders using?
<lool> tjaalton: Perhaps something to ask infinity or lamont about
<tjaalton> lool: ok, thanks
<rtg> tjaalton: they are likely Hardy based.
<tjaalton> rtg: ok.. I think it shouldn't matter either, as long as the current one is available
<rtg> lool:  an alternative to large patches on the mailing list is to request a pull from a git repo on zinc (or some other publicly accessible location)
<tjaalton> regarding the xorg* ftbfs's
<lool> rtg: Yeah, I don't have zinc access though; I was thinking that perhaps I should contribute some patches and then request access; in the mean time, I guess I can push to people.ubuntu.com or so
<rtg> lool: its pretty easy to get an account on zinc. I think you just file an RT.
<lool> "To request an account on this machine for working with Ubuntu's Kernel Team and its git tree, email Ben Collins. " says kernel.ubuntu.com
<rtg> lool: who will just file an RT, but start with BenC2 anyway
<lool> Understood
<CarlFK> dmesg shows: [    0.000000] Kernel command line: root=UUID=7a52d80c-2091-492f-b21a-f9c3174934c0 ro netconsole=@/,@192.168.1.155/
<CarlFK> but netconsole didn't get loaded
<CarlFK> "because netconsole isn't included in your kernel" -- duh.
<Kano> CarlFK: modprobe it
<CarlFK> Kano: yeah, just trying to automate it.  debugging a panic.
<Kano> add a initramfs hook
<CarlFK> i don't need it early - it's an app (dvswitch) - so some startup script is fine 
<rtg> apw: pong
<apw> rtg, hi
<apw> you back?
<rtg> I've been giving the lpia trees some thought myself
<apw> on the short term front i've just pushed up a version of the ubuntu-jaunty-lpia.git tree which fixes the dependancy problem
<apw> and i've pushed up a new ubuntu-jaunty-lpia-lrm.git tree
<apw> both of which i have compiled together in my PPA
<apw> so i think they are at least in reasonable state
<rtg> apw: ok. I'll have a look. I also have some thoughts about development and tree management, but I think I'll propose them on the mailing list
<apw> would be nice to stop these being entirly sepearate if we can cope, as the lrm is actually unmodified, other than the mods to make it build for lpia alone
<apw> it has 0 local modifications right now
<apw> rtg, am going to purchase some food for dinner.  will check in with you in about an hour to see if i need to do anything else with those lpia trees or if we can call them good
<rtg> apw: don't sweat it 'cause it'll be tomorrow. gotta get CRDA packaged.
<CarlFK1> I need this to happen later: cat /etc/modules; netconsole netconsole="@/,@192.168.1.155/"
<CarlFK1> cuz that gives me:  [   19.952019] netconsole: no IP address for eth0, aborting
<CarlFK1> so where is the right place to put: sudo modprobe netconsole netconsole="@/,@192.168.1.155/"
<apw> well it may even be after you login, so ..
<CarlFK1> this is to gether dumps for https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317227
<ubot3> Malone bug 317227 in linux "skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP " [Undecided,New] 
<apw> i would imagine netconsole must have some other mechanism to connect early?
<CarlFK1> late is fine - i need to run a user space app
<apw> netconsole=[src-port]@[src-ip]/[dev],[tgt-port]@<tgt-ip>/[tgt-macaddr]
<CarlFK1> I just want it setup as part of the boot so I don't have to
<CarlFK1> <tgt-ip> isn't optional 
#ubuntu-kernel 2009-01-15
<CarlFK1> this is only a little OT: where can I put a script to load netconsole?
<CarlFK1> smb_tp: remember my "boot pauses" https://bugs.edge.launchpad.net/linux/+bug/254668 
<ubot3> Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] 
<apw> rtg, did you have a chance to look at the lpia trees i pushed yesterday?
<CarlFK1> wondering if it is related to  "Tainted: P   M "   https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317227
<ubot3> Malone bug 317227 in linux "skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP " [Undecided,New] 
<CarlFK1> or there is anything related, given you looked at that boxes dmesg more than once 
<rtg> apw: its on my todo list for this morning.
<apw> no worries
<smb_tp> CarlFK1, Hi, yes I do remember, though I have been distracted by other stuff since. From somewhere I heard that people had success with jaunty for that...
 * smb_tp looks at the link
<CarlFK1> smb_tp: ill try a jaunty kernel and comment both of those bugs 
<smb_tp> CarlFK1, Ok, I am not really convinced they are tied together but thats just by quickly looking upon it
<rtg> smb_tp: 2.6.27 stable updates pushed
<smb_tp> rtg, Ok, thanks
<smb_tp> rtg, that was stable update to -11, right?
<smb_tp> Doh, 2.6.27.11 I meant to say
<rtg> smb_tp: 2.6.27.11
<smb_tp> ok
<rtg> not to be confused with -11 :)
<smb_tp> yeah, thought of it the moment I hit enter
<smb_tp> The upload of this will have to wait until we got the current one to -updates
<CarlFK1> smb_tp: fixed the pause - yay
<CarlFK1> "failed to start X"... not so yay.
<CarlFK1> nvidia...
<smb_tp> CarlFK1, So rather yayno. First is good, now I only would have to find which of the zillion changes this was.
<Keybuk> well
<Keybuk> and I stress that this isn't final
<Keybuk> with just kernel and udev updates, it looks like jaunty takes 10s less time to boot than intrepid already
<Keybuk> (no switching to ext4 or anything like that)
<rtg> I've read similar anecdotal evidence. Is that with readahead?
<Keybuk> same readahead as intrepid
<Keybuk> I did reprofile it to make sure
<Keybuk> before both
<Keybuk> so that shouldn't effect the numbers
<Keybuk> grub to full login is now 61s
<rtg> huh, I didn't know we were doing readahead. Is that part of initramfs?
<Keybuk> it's part of the normal system booy
<Keybuk> /etc/rcS.d/S01readahead
<Keybuk> has been since, err, hoary
<Keybuk> I'm pretty sure it was Mataro we put that in, the food still haunts my memories
<Keybuk> so it wasn't warty
<rtg> drat, I was hoping readahead would get us the next 10 second win.
<Keybuk> sorting out readahead might buy us more
<Keybuk> but this is SSD
<Keybuk> readahead counts for less than 1s of the boot to read in the entire profile
<rtg> I'm working on LRM boot time link. that ought to buy us 2-4 secs
<pwnguin> one thing ive noticed is that boot time degrades over time =/
<Keybuk> switching from "read in entire profile then move on" to "read in by access order throughout the boot" may be an improvement of a few seconds, since less ram is required
<Keybuk> pwnguin: sure, because your readahead profile gets increasingly out of date
<Keybuk> so you need to load more from disk
<rtg> Keybuk: have you messed with ext4?
<pwnguin> Keybuk: there's also the matter of fragmentation
<Keybuk> pwnguin: ext* are largely self-defragmenting
<Keybuk> rtg: no, noet yet
<Keybuk> my next task is to sort out module-init-tools
<Keybuk> I'm hoping for another couple of seconds there
<pwnguin> Keybuk: and yet, i have documented proof that super duper hack involving tar retrieves a few seconds
<Keybuk> then sort out the hardware clock and console setup (on the sprint agenda), I'm hoping *that's* another couple of seconds
<rtg> a few sends here, a few seconds there, ....
<Keybuk> pwnguin: sure, but that's for a different reason ;)  it realigns your disk order with your readahead profile (which is in that kind of order)
<pwnguin> it could be that the fs groups writes together
<Keybuk> there's a sleep in procps I'm going to uncover
<pwnguin> so theres fewer seeks
<Keybuk> that's almost 2s
<rtg> thats an odd place for a sleep
<pwnguin> Keybuk: what do you think about removing the png-ification on bootchart, and leaving it as svg?
<Keybuk> rtg: I know
<Keybuk> pwnguin: SVGs are a pain
<Keybuk> name me a program that can view them
<pwnguin> inkscape?
<Keybuk> inkscape can't view them, it can edit them
<pwnguin> firefox
<Keybuk> firefox can't view them last time I looked unless they're embeded in html
 * Keybuk doesn't understand why people mind the pngification
<pwnguin> it basically defeats datamining
<Keybuk> rtg: well, with all the bits and pieces everywhere, including ext4 ... I'm hoping for X in 15s for jaunty
<Keybuk> pwnguin: I don't follow? bootchart doesn't include itself in its own chart ;)
<rtg> now if we could speed up that pig GDM startup
<Keybuk> rtg: this is rather less than what I thought we could get - so I'm really happy
<Keybuk> you guys have done great work
<Keybuk> kernel accounts for roughly half of that improvement from what I can tell
<pwnguin> Keybuk: imagine being able to graph the bootchart over time
<Keybuk> pwnguin: personally I disable stop-bootchart and run it by hand once I get to the logged in session anyway
<Keybuk> pwnguin: again, irrelevant, since bootchart doesn't include itself
<Keybuk> you start generating the png at the point you've stopped collecting data
<pwnguin> im vastly confused
<Keybuk> bootchart generates a chart of your boot
<pwnguin> yes
<Keybuk> at some point, it decides to stop collecting data
<Keybuk> that's when it generates the chart
<pwnguin> indeed
<Keybuk> so the time to generate the chart is irrelevant to the length of time it takes to boot
<pwnguin> and then it writes to $version-$date-$uid
<Keybuk> now, some people install bootchart
<Keybuk> and leave it installed
<pwnguin> i agree, but i never said anything about bootchart itself
<Keybuk> and complain that it slows down login or something, because it's generating the png
<Keybuk> but well
<Keybuk> that's silly
<pwnguin> let me re explain
<Keybuk> why would you leave it installed if you're not doing work on the boot sequence?
<pwnguin> i dont care about bootchart speed
<Keybuk> the collector slows down your boot anyway
<pwnguin> i care about having access to a vast array of bootcharts
<Keybuk> why?
<Keybuk> unless you know what you changed between each chart, they're not really helpful
<pwnguin> for example, graphing performance over time
<pwnguin> maybe to identify common problems outside the defaults tested
<Keybuk> but it's not useful
<Keybuk> because you don't know what changed to cause any bootchart changes
<Keybuk> "my boot is faster/slower" kinda of reports are nice
<Keybuk> but not really helpful
<Keybuk> "with ext3 my boot takes 25s, with ext4 my boot takes 21s" are useful
<Keybuk> you only need two charts for that, one before, make the change, then another one after
<pwnguin> well it would at least provide a high level view for people who don't dedicate themselves to the task, and help identify large upward spikes
<pwnguin> presumably you arent testing thnigs that would make it worse
<Keybuk> but that data isn't helpful
<Keybuk> to use a real-world example
<Keybuk> it's like taking your weight every morning
<Keybuk> and making pretty graphs
<Keybuk> and realising you're getting fatter, and identifying spikes
<Keybuk> but then not recording what you're eating, or how much exercise you're doing
<Keybuk> it's no good knowing that there was a 7-day spike when you weighed 5kg more
<Keybuk> if you don't also note down that it's christmas and you stuffed your face
<Keybuk> bootchart is only the measurement of time
<Keybuk> in order for it to be meaningful, we need to know what changes between successive ones
<Keybuk> so they don't identify large upward spikes at all
<Keybuk> worse still, they can be self-propelling
<pwnguin> they're meaningful
<Keybuk> two people can both identify an increase in boot time
<pwnguin> they're just not proscriptive
<Keybuk> and assume they're for the same reasons
<Keybuk> and unfortunately, the chart doesn't tell you they're not
<Keybuk> (we've seen this)
<pwnguin> it tells you there's a problem, not what the problem is
<Keybuk> one person had a legitimate bug
<Keybuk> the other's hard drive was dying
<Keybuk> exactly, and I don't think that it's a good way to detect the problem
<Keybuk> simply logging /proc/uptime at the end of rc.local is as good as anything
<Keybuk> you don't need bootchart for that ;)
<Keybuk> bootchart is a tool for people actually making changes and wanting to see whether they have an effect
<Keybuk> (actually, bootchart is largely a tool for making changes to the readahead profile, but hey)
<pwnguin> you could measure the change in readahead time =/
<pwnguin> i donno if that would help, readahead is a cache trick with distributed consequences
<Keybuk> doesn't quite work
<Keybuk> but yes, that kind of thing
<pwnguin> Keybuk: so if firefox rendered bootchart svgs correctly in jaunty, is there any reason to continue pngification?
<Keybuk> yes
<Keybuk> I like pngs
<Keybuk> you can view them with zvg
<Keybuk> zgv even
<pwnguin> well, its trivial to enable / disable it, and you can easily convert later ;)
<Keybuk> I'm sorry, but I just don't agree with your use case
<Keybuk> you're complaining because it makes your boot slower
<Keybuk> well, bootchart in general makes your boot slower
<pwnguin> im not
<pwnguin> of course its slower
<Keybuk> so what's the issue? :-)
<pwnguin> it's bigger on disk, throws away potentially valuable information, and in random edge cases, massively delays boot
<Keybuk> err, the svg is much bigger on disk actually
<pwnguin> svgz
<Keybuk> no valuable information is thrown away, the svg is identical
<Keybuk> however the png is much more portably viewable
<Keybuk> (including can be viewed on the console)
<Keybuk> (I'd be interested to see the random edge cases, btw
<pwnguin> https://bugs.launchpad.net/ubuntu/+source/bootchart/+bug/218499
<Keybuk>  and would wager that the process taking the longer time isn't rsvg but is the java one :p)
<ubot3> Malone bug 218499 in bootchart "after fsck, bootchart -> rsvg-convert makes computer slow" [Low,Confirmed] 
<pwnguin> you've seen it already
<Keybuk> right, and that one, it's mostly the java one that takes longer
<Keybuk> rsvg-convert just takes longer too
<Keybuk> so by the time people look, it's that one as well
<Keybuk> and as I say in the bug
<Keybuk> "then uninstall bootchart"
<Keybuk> rtg: and I really must stop lsb-release calling apt-cache
#ubuntu-kernel 2009-01-16
<CarlFK1> What does "Tainted GM" mean in:  Pid: 6523, comm: dvswitch Tainted: G   M      2.6.27-11-generic #1 [
<CarlFK1> full dump: http://dpaste.com/109665/ 
<apw> CarlFK1, the G means you have modules loaded but they wern't proprietry, the M means your machine recieved a machine check in the past
<Kinnison> Hi guys, one of the things I'd like to do this weekend is update my toshiba acpi module so that it doesn't crash modern kernels. To do that, I need jaunty's kernel tree. Is it simply git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git ?
<Kinnison> And is there a simple set of instructions for turning that into a kernel package? (I'll need to update the kernel on my laptop)
<Keybuk> yes
<Keybuk> "fakeroot debian/rules binary" usually does the trick ;)
<Keybuk> though if you're patching, you'll find it annoying to rebuild every time
<Keybuk> I usually do out-of-tree ordinary kernel builds (grab the config out of debian/...) until I've got the patch right
<Kinnison> right, so the configs are just in debian/ ?
<Kinnison> cool
 * Kinnison is apparently 52% through 'checking out files'
 * Kinnison sighs. kernels are so big these days
<Kinnison> Is Jaunty going with 2.6.28 or hoping for 2.6.29?
<Kinnison> Keybuk: Presumably I need to concatenate config and config.generic ?
<Keybuk> right
<Keybuk> 2.6.28 for jaunty
<Kinnison> Okies
<apw> Kinnison, it is highly unlikely .29 will be out before the kernel is frozen, and we are unlikely to change at this late stage in the cycle.  this is even less likely now we are seeing much more fixes via the stable kernel trees
<Kinnison> nod. 2.6.28 is fine I believe
<Kinnison> I *think* what I need is in 27 so it should be fine
<apw> if you can't just pick the kernels out of /boot/config-* then you can make the configs using debian/rules prepare-generic 
<apw> and find them in debian/build/build-generic/.config
<Kinnison> I can't pick them out of /boot because the laptop is on 8.04 and I'm loathe to move it on from there because of openvpn issues in 8.10
 * Kinnison starts a kernel building
<Kinnison> Okay, awkward question.. Given the debian/build/build-generic directory containing a built kernel, can I use that for building out-of-tree modules?
 * Kinnison is *so* out of date on kernel building it's sad.
<Kinnison> if it's not 'make CROSS_COMPILE=$XC ARCH=arm zImage' then I get confused :-)
<Keybuk> cking: sorry, but for filing that bug I'm going to pick on you now ;)
<cking> Keybuk: yeah yeah
<Keybuk> cking: I need you to step through the boot process by hand
<Keybuk> init=/bin/bash, then run each init script in turn (/etc/rcS.d/S01... start, S02... start, etc.)
<Keybuk> and between each one, look in /dev for pktcdvd
<Keybuk> and see which init script creates it
<Keybuk> or is it there in the initramfs, etc.
<cking> Keybuk: OK - I will do this in ~1 hour or so once I've finished the current ISO test - is that OK?
<Keybuk> sure
<Keybuk> it's your bug ;)
<cking> ..well it's not a  mega-high show stopper. I will figure out which script creates the message and report to the bug sometime today...
<Kinnison> Keybuk: Once I've built a kernel, can I just take the contents of the firmware/ dir and copy that to /lib/firmware/$(kver) and expect it to behave?
<Keybuk> Kinnison: I should think so
<Kinnison> Keybuk: sweet.
<Kinnison> yay, and make -C ..../build-generic M=$(pwd) does the trick
 * Kinnison should be able to sort out tlsup for jaunty
 * Kinnison is pleased
<rtg> Keybuk: you were chortling yesterday about some change that saved several more seconds at boot time. What was it?
<Keybuk> rtg_: making lsb_release just return the values in /etc/lsb-release if they're all present
<Keybuk> instead of firing up things like apt-cache to work it out
<rtg_> not a kernel issue :)
<EtienneG_home> hey guys!  is the difference between -virtual and -server documented somewhere?  Is it just the VMI stuff, or there is more to it?
<rtg_> EtienneG_home: Hardy?
<EtienneG_home> rtg_, yes indeed
<rtg_> EtienneG_home: if memory serves, the server kernel is used in the virtual package, so there is no differnce.
<EtienneG_home> rtg_, ok!
<EtienneG_home> thanks for the info
<EtienneG_home> I think I will diff the config, just to see
<rtg_> EtienneG_home: hmm, there is a virtyual flavor in i386 but not amd64.
<rtg_> looks like a lot of devices are not enabled.
<rtg_> EtienneG_home: I get confused, it was Intrepid where we started using the server kernel in the virtual package
<EtienneG_home> rtg_, ok
<EtienneG_home> I will investigate
<Keybuk> cking: there's a patch to grub that replaces the delay with a "hold down a modifier key"
<rtg_> Keybuk: that doesn't work on all BIOSs. sometimes the keyboard is disabled if you're holding down a key during boot.
<cking> rtg_: thanks for that insight
<rtg_> seems like crack to me, but there you have it.
<cking> probably holding down a key during boot confuses the Embedded Controller
<cking> ..and the user
<cking> Keybuk: I'd hate to change the expected functionality (use the ESC key) with something that won't work for all machines - especially for the sake of 1 second 
<cking> I expect anyone who really wants to shave time off the grub delay can do so by editing the menu.lst file#
<cking> I will look at the patch sometime soon though 
<Nafallo> isn't that patch of preventing flicker as well?
<Nafallo> s/of/for/
<Keybuk> why would it prevent flicker?
<Nafallo> just something I read on some fedora interview site :-)
<Nafallo> let me see if I find the URL
<Nafallo> http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-better-startup/ <-- Keybuk 
<Nafallo> Keybuk: there is a five point list about 2/3 in.
<tjaalton> the menu is not shown unless you have a dualboot setup
<tjaalton> but it doesn show the countdown
<tjaalton> -n
<Nafallo> oh. those people are talking about the full menu?
<tjaalton> yes
<Nafallo> man. I should try fedora at some point :-P
<tjaalton> with grahix :P
<tjaalton> uh
<tjaalton> *graphix
<Keybuk> Nafallo: that only counts for Fedora because they have a graphical grub
<Nafallo> Keybuk: hehe. fair enough.
<Keybuk> that's why I've used phrases like "over my dead body" when people suggest Ubuntu has a graphical grub menu
<Nafallo> Keybuk: we did have that! :-)
<Nafallo> I remember using it :-)
<cking> Keybuk: w.r.t /dev/pktcdvd  - it's created by /etc/rcS.d/S10udev by the line "if /sbin/udevadm settle; then"
<cking> "by" means by the time we get to
<Kinnison> is it mentioned in any of /etc/udev/rules.d ?
<mdz> will call you in just a moment
<Keybuk> cking: can you tar up your /dev for me
<Keybuk> I assume you mean it's not created by anything before that init script
<cking> Keybuk: it's not created until we hit S10udev - I added some debug into the script and watched it appear while the script was executing
<Keybuk> ok
<cking> ..tar file in an Email in a mo
<cking> it's a mystery why it's being created
<MykelSilver> hi, first best wishes to everyone. My question: this morning my ubuntu request a reboot because of a new kernel update: linux-image-2.6.27-11-generic (2.6.27-11.23) to 2.6.27-11.24.... I cannot find any information what the security issues are to update... Normally I can find them at http://www.ubuntu.com/usn ... But not this time.... Any has a link for more info...?
<rtg_> MykelSilver: its not a security update. you're subscribed to -proposed.
<MykelSilver> o sorry
<rtg_> MykelSilver: look at https://edge.launchpad.net/ubuntu/+source/linux for changelog entries
<MykelSilver> THANKS :-)
<MykelSilver> very happy for helping me 
<MykelSilver> got it... very fast response. amazing
<MykelSilver> nice day. bye
<rtg_> I live to serve
<rtg_> kirkland: did you get a chance to try 'eCryptfs: Filename Encryption: mount option' ?
<kirkland> rtg_: on my todo list for today ;-)
<rtg_> kirkland: I'm installing a laptop right now. I didn't realize it requires a mount option.
<kirkland> rtg_: yes.  if we like it, we can add it to mount.ecryptfs_private
<kirkland> rtg_: ie, if it works well
<kirkland> rtg_: well, make it configurable anyway, in your .ecryptfs dir
<rtg_> kirkland: if it works well, I think it ought to be a package default
<kirkland> rtg_: agreed
<kirkland> rtg_: i'm thinking we can perhaps target that for the next alpha
<kirkland> rtg_: the installer just started supporting encrypted home yesterday/today
<kirkland> rtg_: that's what I'm testing at the moment
<rtg_> kirkland: me too.
<rtg_> kirkland: whats the story on encrypted swap?
* You're now known as ubuntulog
<kirkland> rtg_: i need to talk to Keybuk about that....
<kirkland> Keybuk: ping?
<Keybuk> yup?
<rtg_> Keybuk: encrypted swap
<Keybuk> never touch the stuff ;)
<cking> that's fairly straight forward response
<rtg_> Keybuk: :) we discussed the fact the encrypted home isn't much good if you leave stuff in swap
<Keybuk> I recall
<Keybuk> was there anything in particular about it you wanted to discuss?
<rtg_> Keybuk: uh, just wondered if/when it was going to get enabled whenever some chooses encrypted home.
<rtg_> s/some/someone/
<Keybuk> my dead body may be involved ;)
<rtg_> oh, not that again, right along with graphical grub, huh?
<Keybuk> <g>
<Keybuk> I still object to the detail that a multi-user machine cannot be resumed if encrypted swap is used
<rtg_> Keybuk: ugh, I forgot about resume.
<Keybuk> cking: around?
<cking> Keybuk: yep. 
<Keybuk> cking: could you run sudo udevadm test /devices/virtual/misc/pktcdvd
<cking> Keybuk: not quite at the moment - the laptop is being "upgraded"
<cking> ..but I will once I can 
<Keybuk> kk
<Keybuk> you're sure that symlink did not exist before S10udev ?
<rtg_> cking: were you having problems with udev? my laptop complains that it can't read /etc/udev/rules.d and then nothing really works right after that.
<cking> Keybuk: pretty certain - I put in "ls -al /dev/pktcdvd" in the script and observed when it could list the device
<cking> rtg_: only /dev/pktcdvd 
<rtg_> huh, so far I'm underwhelmed by A3
<cking> three steps back.. for one forward?
<rtg_> seems like
<Keybuk> cking: I really need a bit more live help debugging this one I'm afraid
<cking> Keybuk: OK - well I will run the udevadm as suggested when I reassembled the laptop this evening
<Keybuk> that'll push us back until monday before I can look at it :-/
<cking> Keybuk: OK - but I've got a family to put to bed and I've been working since 7am.. give me a 30 mins...
<cking> ..I've got little kids to sort out.. hold on
<Keybuk> :)
<Keybuk> cking: ahh, no panic
<Keybuk> I've just realised that this isn't hardware related
<Keybuk> I can replicate it here
<cking> Keybuk: that's good news to me :-)
<ogasawara> cking, rtg:  you guys have migrated to ext4 ya?  I just read bug 317781 .  Curious if you guys have seen any issues?
<ubot3> Malone bug 317781 in linux "Ext4 data loss" [High,Triaged] https://launchpad.net/bugs/317781
<rtg_> ogasawara: ext4 doesn't claim to preserve data, only the journal
<rtg_> ogasawara: perhaps he's getting nipped because ext4 is lazier about committing data
<Keybuk> wtf. are
<Keybuk>  /dev/cpu_dma_latency
<Keybuk>  /dev/network_latency
<Keybuk>  /dev/network_throughput
<CShadowRun> Does anyone know when the 2.6.29 kernel is due in ubuntu?
<CShadowRun> i'm waiting on it since support for my webcam has been regressed since intrepid and the fix is supposed to be in that release :D
<ogasawara> CShadowRun: Jaunty is going to have 2.6.28, so Jaunty+1 will likely be 2.6.29.  do you have a specific patch reference?  It could probably be cherrypicked.
#ubuntu-kernel 2009-01-17
<CShadowRun> ogasawara no, but i can show you the mail i got from the webcam dev
<ogasawara> CShadowRun: sure, pastebin it and I'll take a look
<CShadowRun> http://pastebin.com/m745f2222
<CShadowRun> to use my webcam i either have to use usb passthrough to windows in virtualbox or use a hardy livecd :(
<ogasawara> CShadowRun: can you also open a bug report about it (if you haven't already) - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+filebug
<CShadowRun> ok
<CShadowRun> should i call it webcam regression?
<CShadowRun> ogasawara that ok? :)
<ogasawara> CShadowRun: if you can make it a bit more descriptive that would be great - ie specify which webcam
<CShadowRun> is there an edit button?
<CShadowRun> aha, update description button
<CShadowRun> ogasawara there, added that information
<ogasawara> CShadowRun: what's the bug #?
<CShadowRun> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/318061
<ubot3> Malone bug 318061 in linux "Webcam regression" [Undecided,New] 
<CShadowRun> ogasawara so what's the word on that bug?
<CShadowRun> i've been considering just going out and buying a new webcam :(
<mnemo> will jaunty ship with .28 or .29 kernel??
<nokia3510> hello everyone
<nokia3510> after updating from hardy to intrepid (via ssh) the upgraded machine cannot boot intrepid's kernel because of a grub error: something with a cylinder exceeding... hardy's remnant kernel boots fine
<nokia3510> perhaps a rebuild of initramfs for the intrepid kernel could help ?
#ubuntu-kernel 2009-01-18
<CarlFK> what is the vanilla #kernel chan name?
<ia> hello. could you tell me, please, which the best way to create deb package with sources of modificated linux kernel? for example, i clone ubunut-jaunty source tree via git; it compiles successfully via debian/rules or via make-kpkg as well. But I would like to know, does exist some alternative for "make-kpkg kernel-source" via existing original debian/rules way?
<ia> by other words, what kernel maintainers do, that user can just type "apt-get source linux-image-2.6.X-Y-<type>"? i will be very appreciate for any useful information about "right" packaging of kernel.
<Kano> time debian/rules binary-debs flavours=generic skipabi=true skipmodule=true
<Kano> time debian/rules binary-headers
<ia> Kano: oh, well, all words clear except one - "time" - could you explain, please, what it do?
<Kano> just for benchmarking ;)
<ia> and another question - if i compile generic kernel via debian/rules binary-generic, then binary-deb compiles debs not just for generic, but for each "package" in debian/control, right?
<Kano> the way i showed you works
<ia> Kano: oh, sorry, i've just don't notice "flavours=<type>". that's answer for my question.
<ia> Kano: thanks you very much for answers :-)
<fransman> What kernel git is used for ports in jaunty ?
<ia> fransman: do you mean kernel version? 2.6.28
<fransman> Ia i found ubuntu-intrepid-ports.git 
<fransman> but theres no jaunty
<fransman> I do not think sparc on ports is on 2.6.28 yet
<ia> Kano: hello again :-) i've tryied "... debian/rules binary-debs ..." but it built debs with binary debs only without building any debs with sources. just in case, to clarify - i would like to know equivalent to "make-kpkg kernel-source" command, but via existing debian/rules. any other ideas?
<Kano> look into the rules
<ia> Kano: thanks. "debian/rules binary-indep" - that's what i've looked for :-)
<Kano> btw. i worte 2 mails to the mailinglist, would like to see the changes soon in git...
#ubuntu-kernel 2010-01-18
<akshay> Hello.. Is it possible to shutdown the linux system from a kernel IRQ.?
<csurbhi> hello smb :)
<csurbhi> is the default option for ext4 fs ordered ?
 * apw suspects he'll ask you
 * csurbhi looks
<smb> csurbhi, it was
<smb> but when they added an option, it defaulted to writeback
<smb> thats how we got it
<csurbhi> but should it not be ordered again ?
<apw> smb that is ext3 right?
<cking> perhaps we need a per-release table of fs default mount options written up somewhere
<smb> apw, yes
 * csurbhi is cursing the slow laptop
<smb> csurbhi, exactly
<csurbhi> ok, i will make one 
<smb> cking, The problem was it slipped in
<apw> there are two questions, should we change the default back for ext3, and is ext4 affected
<apw> i assume 1) is yes, and 2) is don't know
<csurbhi> yes, i think ext4 is affected as well
<smb> As the default without having an option was ordered and the default with the option was writeback
<smb> ext4 has no option as far as I can tell
<smb> but I might be mistaken
 * csurbhi thinks, ext4 has options of ordered, journal, writeback and now guarded too
 * maco agrees with csurbhi
<apw> yeah they are mount options though right, which is the default if you don't say
<csurbhi> i think that the default mount option is writeback
<csurbhi> and it ought to be ordered
<smb> You always can tweak them on or after creation as well. I just did not find one compile option as clearly related to that than for ext3
<csurbhi> yes, there does not seem to be any compile time option 
<smb> Probably for ext4 we should think about which mode is best for us, after figuring out the exact implications
<apw> cking, yeah thats not a bad idea
<csurbhi> ok
<apw> csurbhi, ok this machibne is a standard install.  i took no action
<apw> /dev/disk/by-uuid/5fdffa9d-a806-4009-930a-bf637c8f5cfa / ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
<apw> it seems to be in ordered mode
<csurbhi> ok
<cking> apw, and perhaps any known bugs against these fs defaults too
<smb> At least that is (between ordered and writeback) the mode that sounded less quick but safer
<csurbhi> apw, thanks !
<apw> and i note there are no options in my fstab
<apw> UUID=5fdffa9d-a806-4009-930a-bf637c8f5cfa /               ext4    errors=remount-ro 0       1
<smb> same here
<apw> so ... i assume the default is ordered in _lucid_
<smb> in Karmic
<apw> anyone got a karmic install they can confirm
<apw> wicked
<smb> So ext4 looks ok (though might get checked whether the other two look more appealing)
<apw> smb, sounds liek a job for super-csurbhi to me
<smb> Sounds good to me. :)
<cking> perhaps we need to keep an eye on the default mount options over the lucid alpha/beta cycles too
<csurbhi> i think ordered with barrier=1 is the best
<csurbhi> or safest
<smb> csurbhi, So if you can get us a dummy-style wrapup of the pros and cons of those to the kernel team list? ;-)
<csurbhi> smb, sure i will do that today :)
<cking> cool
<csurbhi> smb, so few questions ..need your help !
<smb> No problem
<csurbhi> can you please tell me the tasks that are involved in taking a lead on a stable kernel ?
<smb> So have you cloned the upstream repo
<csurbhi> not yet
<smb> I guess that would go first
<csurbhi> ok
<smb> We got up to 2.6.31.9 in the ubuntu Karmic tree
<smb> If unsure you would see that by the subversion number in the makefile
<csurbhi> ok
<smb> So basically you look at the changes between 2.6.31.9 and 10 and then at those between 10 and 11 (which is easy as its only one patch)
 * csurbhi is cloning the tree
<csurbhi> ok
<smb> When you look up the mails Leann wrote, you can see there is one bug report related to each update from stable
<smb> You can take the things she wrote in the mail and the bug report as a reference 
<csurbhi> ok
<csurbhi> and then ?
<smb> You do a review as you did with the ext4 patches and then send an email like Leann which announces the update and all (including your review notes)
<smb> At the same time have the patches applied to a Karmic branch of yours and push that to your repos for review
<csurbhi> ok
<smb> During that process you might find some patches already applied. There it depends on whether we got that through a security update or a sru/before release. In the case of a security release you drop the upstream stable patch
<smb> otherwise you revert the one we carry and apply the new one. But I think you just ask again when that happens
<csurbhi> yes, i will do that.. so basically the patch should mention whether its come from a SRU or security ?
<smb> Its part of the process to find out. When we apply it to a tree it usually has a CVE number in the description. But you also can look into the changelog to see whether the patch was part of *-proposed or *-security updates
<csurbhi> ok, thanks :)
<csurbhi> one more question, last time i got the patches directly from your dir.. 
<csurbhi> are the patches stored in somewhere ? 
<smb> That is what you download from the 2.6.31.y repo. I usually export the range from there and apply them to a working tree in Karmic for myself. Or you have it as a remote and cherry pick them. But the source is always the upstream repo
<csurbhi> so you get the patches out of the kernel 
<csurbhi> ok
<gnarl> csurbhi, If you look at the 2.6.31.y tree. That is an upstream tree which has been branched of 2.6.31 and then gets the stable patches applied.
<csurbhi> ok
<gnarl> So you can easily get a range of patches that are new
<gnarl> There are tags on that tree for every release
<gnarl> so a "git log v2.6.31.9..v2.6.31.10" works
<csurbhi> ok
 * csurbhi thanks gnarl profusely :)
<gnarl> csurbhi, Don't worry too much about the later steps. You can get back about them when you are there. The first thing is to have the upstream tree, extract the patches that come as new ones and look over them making your notes. 
<csurbhi> ok
<apw> smb, you know that fix you did way back when for the mmc exploding on suspend/resume
<apw> did anything come of that?
<smb> apw, Nothing. And it reminds me to try out latest Lucid to see whether it can still erase on resume
<apw> smb could this be the fix for it?
<apw> commit 5fa83ce284a4b7cd9dcfadd01500b0ed4ab9b740
<apw> Author: Adrian Hunter <adrian.hunter@nokia.com>
<apw> Date:   Fri Jan 8 14:43:00 2010 -0800
<apw>     mmc_block: fix queue cleanup
<apw> this sounds a bit like a fix for what you were seeing to me
<smb> apw, Lemme look at that
<smb> apw, Yeah, it looks pretty similar to what I remember. 
<smb> Both the description and the patch
<apw> smb, so should i be dropping yours in favour of that?  its coming in via stable for 32
<smb> apw, I guess yes. It likely should not apply with mine on. Right?
<apw> it seems to collide only on the comments amazingly but feels like a bad idea to fix it
<apw> ok will try dropping yours and applying this one
<smb> apw, Yeah. Interesting. But yes, drop mine and I test with that kernel
<apw> obviously a more successful approach :(
<smb> apw, As long as the problem is fixed I don't care. But I obviously must remember that one can sneak into any place through mm :)
<apw> heh yeah ... a side road round a road-block and no mistake
<apw> smb, we doing the review today?
<smb> apw, yup
<apw> bah
<ivoks> apw: ping
<ivoks> apw: bug 474660
<ubot3> Malone bug 474660 in linux "drbd8-utils not dependent on drbd8-source" [Medium,Triaged] https://launchpad.net/bugs/474660
<ivoks> apw: that's actually bug in karmic
#ubuntu-kernel 2010-01-19
<luckyduck> Hi. We're using 8.04 on a lamp cluster. yesterday at 12:24 the packetfilters on all 3 wwwnodes (loadbalanced) logged an dropped packet at the same time. 
<luckyduck> it looked like the conntrack rule est. / related stopped working
<luckyduck> however , the conntrack table was not reported as full at that time
<luckyduck> i then inserted a rule which should allow the traffic (incoming answer packages from the mysql server at port 3306).
<luckyduck> there is also a central firewall which connects the different subnets for wwwnodes and the mysql servers (there are a few others, but not relevant)
<luckyduck> it seems that there is the same problem, but nothing gets logged and the conntrack table is also not problem (not reported as full). 
<luckyduck> it seems that some packages simple get dropped, without getting logged or something
<luckyduck> it doenst happen all the time, it's occurs in a "random" fashion
<luckyduck> is there anything you can recommend to debug this?
<luckyduck> the main problem is that everything worked fine for ~2-3 month
<luckyduck> it started with the dropped packages on all 3 wwwnodes at the same time
<Ng> at the exact same time?
<luckyduck> yep, with 1 second difference
<luckyduck> 12:23:59 on two wwwnodes and 12:23:58 on the other
<luckyduck> we'll, the wwwtraffic is loadbalanced. ~  the same amount of traffic is handled by each node
<luckyduck> is it possibly related to a bug in netfilter or the kernel?
<luckyduck> i can show you logs or anything else you need. 
<luckyduck> we've analyzed that at some point the mysql connections which get initiated by the wwwnodes get dropped by the central firewall:
<luckyduck> the wwwnode sents the SYN, this is received on the vlan interface on the firewall
<luckyduck> but then it's not routed into the database subnet
<luckyduck> nothing gets logged about dropped packages and as i said, the conntrack table isn't full
 * apw_ is disconnected from his proxy ... history is ... history
<smb> apw_, You need the instant video to rewind it
<apw_> actually i need the [] button in Braid to run time backwards and try again
<smb> apw_, Heh, one would wish to have that from time to time
<smb> apw_, Ok, I forwarded a mail from hpa to the kernel-team list. It is about CPU_DEBUG
<apw_> cool.  i saw the original so we may well want to drop it so we don't regress
<smb> apw_, For us it seems to be only enabled in Lucid-amd64 as a module
<apw_> less modules == happy apw
<smb> But as it sounds, yes, we probably just want to get rid of it before release
 * apw_ wonders just how slow his hard drive really is ... check out my tree damn it
<smb> happy apw == less whip lashes in my back ;-P
<apw_> i'd not assume that :)
<apw_> _still_ checking out
<smb> *ouch*
<apw_> _finally_
<apw_> its that first time after reboot.... a world of pain
<apw_> smb, i may have to go back to bed ... a wheel just fell off my chair and it tried to eat me
<apw_> its just not safe out here right now
<smb> apw_, Nasty
<apw_> yeah its just _not_ my day
<smb> You have to be careful when opening the fridge...
<apw_> bah _now_ banshee is all mental, getting jammed on OSD ...
 * apw_ cries
<apw_> seems happy with katy perry but not kate nash wtf
<smb> apw_, That surely is the new "policy enforcer" :-P
<apw_> heh ... seems like it
 * apw returns ... something is working at least
<soren> apw: It'll pass.
<apw> lol sadly true
 * apw looks at the massive heap of updates for lucid ... 'stable' updates hrm
<smb> Sometimes it feels like staple udates
<apw> yeah ... luckily i am not under quite the review constraints you are ... for which i am thankful
<apw> smb, well that kernel boots on my 10v at least, and doesn't eat my card, but its not a direct mmc so ...
<smb> apw, Sounds at least good enough to try it here again. With an unimportant card, though
<apw> heh yeah ... am pushing the i386 build now is that useful to test;  assume so
<apw> smb, can you get to rookery? 
<smb> apw, nope
<apw> ahh sorted
<soren> Could one of you guys take a quick look at bug 499520? Specifically the last comment (with attachment). I'm puzzled why 251192 kB of RAM is used by those processes.
<ubot3> Malone bug 499520 in vm-builder "default uec-image requires at least 300 M of RAM to run - m1.small and c1.medium not needed by default" [High,New] https://launchpad.net/bugs/499520
<soren> Adding all the processes' SZ and RSS comes to 27219 and 21608, respectively.
<soren> To me, it looks like a kernel problem. I can't see where else all that memory could have gone.
<apw> soren, define gone
<apw> the machine there has 1.7gb of ram, just cause ram has stuff in doesn't mean it would be needed and retained if the machine had 256MB of ram
<soren> apw: I understand that.
<apw> so whats our proof that 300mb is 'needed' to boot
<soren> apw: That is, nevertheless, the case. People have attempted to run this on a 256 MB RAM box, and failed.
<apw> do we have a boot log from such a failure?
<apw> as the consumer is likely the one to get it in the eye when we run out
<soren> apw: And even though the kernel usually makes smart decisions about this sort of thing (like you suggest), you can still look around and account for the current memory use. However, in this case, I cannot.
<apw> how much can you account for in userspace
<soren> apw: 27 MB.
<soren> Sorry, no. 22 MB.
<apw> and 206 is in the buffer cache
<soren> apw: Sorry, it didn't fail to boot with only 256 MB of RAM, but it was swapping.
<soren> apw: Yes.
<soren> apw: Err... Sorry, what?
<apw> doesn't the output of free tell us that 206 is in the buffer cache
<apw> ie hanging about
<apw> with near 2gb of ram we'd have a fair chunk for the kernel
<apw> and we're only 23 short there
<soren> You make a reasonably convincing argument.
<soren> What significance do 3460 and 41492 have, then?
<apw> /proc/meminfo has a lot of data on whats where too
<soren> Sorry, phone call.
<apw> not sure i've ever used the output of free to know exactly what its fields are, i tend to use /proc/memingo
<apw> Buffers:          422960 kB
<apw> on my 4GB machine i have almost nothing but buffers ... wow
<apw> doh missreading ...
<apw> Cached:          2363964 kB
<apw> impressive as there is only me on it
<apw> soren, /proc/meminfo and /proc/slabinfo are worth collecting when its up
<soren> apw: I'll make a note of that.
<soren> apw: Thanks for your feedback.
<apw> soren, what we are here for :)
<apw> smb, http://people.canonical.com/~apw/lucid/ <- i386 test build for your mmc machine
<smb> apw, Ok, cool
<bjf> **
<bjf> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> **
* smb changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || SRU period for Karmic ends mid February || Ubuntu Kernel Team Meeting - Jan-19 - 17:00 UTC
<mjeanson> could someone have a look at bug #508008 ? very straightforward with patch attached, but I'm not sure how to get this considered for an hardy update
<ubot3> Malone bug 508008 in linux "[hardy] Bridging a 802.3ad bonded interface will break it" [Undecided,Confirmed] https://launchpad.net/bugs/508008
<rtg> mjeanson, hmm, looks like an obvious fix
<smb> mjeanson, You should probably forward the patch with a reference to the bug and a short description of the impact and where the fix comes from to kernel-team@lists.ubuntu.com
<mjeanson> smb: will do, thanks
<mjeanson> rtg was faster, thank you both for your help
<rtg> mjeanson,  bridging on servers is fairly important. I'm surprised I haven't noticed this before 'cause the bug is not strictly related to bondings. It appears that if _any_ intermediate bridge segment could drop STP packets if its not enabled on that bridge host.
<mjeanson> rtg, I was supprised to be the first to notice that, I tough bridge on bond was a fairly regular scenario for kvm hosts
<rtg> mjeanson, well, kvm _was_ in its infancy for Hardy.
<mjeanson> rtg, when should I expect a fixed kernel in the archive?
<rtg> mjeanson, it'll go to -proposed first where it'll rattle around for the best part of the first quarter. 
<rtg> mjeanson, smb could better answer
<smb> Its a good summary. With the special exception of other security updates in the works which take precedence on it
<smb> For now this probably could get up to proposed somewhen next week. The bug gets an update that is will be available and if this gets verified (positive test comment on the proposed kernel in the bug) usually moves into updates a week later
<mjeanson> well thank you both again, I'm not used to such good feedback on IRC
<rtg> timing is everything :)
<smb> It might be beer time which it bad for responsiveness. But we try our best. :)
<rtg> dude, I just finished my oats for breakfast. beer time is a ways off yet
<smb> Its all relative. Mine would in theory just be half an hour away...
<smb> Just typing in the meeting with one bottle in the hand is kinda hard :)
<JFo> heh
<rtg> smb, clamp it between your knees
<apw> smb, how is your SD card?
<smb> apw, Still well but more to the fact that I wanted the surrounding system to be up to date, which still ploughs along
<apw> oh ok... wanted to get that testnig before i upload ... let me know when you are there :)
<smb> rtg, Heh yeah, should do that. I hope I never have to explain any strange muscle cramps resulting from that
<rtg> smb, that would be TMI
<smb> apw, I wished I could say. But I hope soon
<smb> rtg, Ohh, I am sure we have heard worse. :)
<rtg> apw, what kind of external USB drive are you carrying? I need to get something light for travel
<apw> smb, you need a straw
<smb> apw, Interesting, remember that bug we discussed yesterday about the mouse that has both absolute and relative axis? While trying to figure out what goes wrong it seems all my mice show up in "xinput list" as type keyboard. Just with a relative mode.
<smb> apw, And yes, the straw would solve the hand problem. Maybe with the side-effect of getting drunk quicker. Which again impacts typing. :-P
<smb> rtg, You probably want to look for an external case for 2.5" drives
<rtg> smb, externally powers and small case
<rtg> powered*
<smb> rtg, I got a IcyBox which is usb powered (with an option of having a second usb port as additional power)
<apw> rtg that one is a Maxtor one touch which seems to work pretty well
<apw> actually it being separate is a bit annoying as its like carrying a bag of worms when you have it attached
<apw> but its better than nothing and better than lugging this heap round with me
<rtg> apw, well, I mostly want it for evenings since I rarely do development on my laptop
<apw> yeah i do use my netbook without it a lot when i am away
<smb> apw, Update finished now. But unfortunately it now seems to stop dead in its boot. Next thing for me to try is nomodeset
<apw> wtf
<smb> apw, Was that nomodeset? At least its not the kernel. The old one gets stuck at the same place
<apw> nomodeset yes
<apw> OH check thingy
<apw> crap, those .so's for X
<apw> smb, check the version of xserver-xorg-core
<apw> and paste it
<smb> apw, If I ever get a working console I will
<apw> boot single perhaps
<smb> Neither nomodeset, nor text worked yet
<apw> pgraner`, where did we look for missing .so's for your xserver-xorg-core issue
<apw> and smb you had it too ... could it be the same
<smb> It finished "Staring crypto disks" but nothing after that. 
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
<bjf> ##
<apw> hrm
<apw> so somthing else in userspace
<apw> grrrrrr
<smb> apw, I remember seeing the same in one bug report. But need to dig further to get somewhere
<smb> Might be just on my installation too
<smb> apw, Hm, whatever it was. At least I now dropped into the busybox
<apw> jjohansen, so is that miss reporting thing important enough to hold up my upload for?  and disrupt you to get it ready?  or shall we wait 
<jjohansen> no, upload away
<jjohansen> the tool still works, it just can't combine the unconfined tasks together
<apw> minor then ... fine
<jjohansen> yep
<apw> smb, so its more about you and whether you might be able to test ... sounds like you are in a heap
<smb> Yeah. And it does not seem to me tied to a kernel
<smb> So, any is as bad as the other to me
<apw> smb, ok i just risked an update on my mini, so i should have the same 'rest of the crap' as you
<apw> and i seem to be booting ok there
<smb> Its a weird thing
<apw> [jjohansen] clean up on pam_apparmor: TODO
<apw> any idea when that might be planned to be done?
<jjohansen> apw: hrmm, either this or next week, its is an entirely user space task
<smb> apw, fs is mounted. system reacts well to sysrq. it seems to fall into the idle of death on something
<apw> so lucid-alpha-3 then?
<jjohansen> apw: ys
<jjohansen> s/ys/yes
<apw> jjohansen, ta
<lamont> WTF does ping of a remote host go from 2 ms to 3500 ms when I do it via the openvpn tunnel?
<lamont> meh.  nm
<stgraber> I just confirmed bug 509808 as something that should be done in order to get full LXC support as described in the server-lucid-contextualization blueprint. I forgot to include that parameter in the initial bug report so would appreciate it being turned on if possible by alpha-3.
<ubot3> Malone bug 509808 in linux "Enable user namespaces in Lucid server kernel" [Wishlist,Triaged] https://launchpad.net/bugs/509808
<stgraber> Please tell me if you'd prefer I e-mail ubuntu-kernel about it too. Thanks
<dhillon-v10> stgraber, hi there :) it would be a great idea to email the list as it might get more attention, but you should stick around for a little bit and other could probably help you more
<dhillon-v10> ogasawara, ping regarding glibc()
#ubuntu-kernel 2010-01-20
<lamont> so if I have an SMP box and I want a process and all of its children to run on one processor (and pretend that we are uni-processor), is there anyway short of booting a non-smp kernel or firing up a kvm guest with one processor?
<stgraber> lamont: "echo 0 > /sys/devices/system/cpu/cpu1/online" will turn of cpu1 (at least it do here)
<lamont> ah.well... it'd be nice to leave the other processors running, to handle the rest of the machine...
<stgraber> right, maybe cgroups can do that
<lamont> but if I must, I suppose that'll do - trying to figure out if something is really non-smp safe or not... seems to work just fine on a UP hardy box, not so well on a SMP karmic box
<lamont> though if it actually finishes on the hardy vm, I'll just smash it against a karmic uniproc (32-bit) box, and see if that works too
<lamont> hrm... I wonder... is 6GB of RAM and 4cores a bit overkill for a firewall box?
<stgraber> it tends to be ;)
<lamont> it was available, dammit
<stgraber> (says the one using a Q6600 as his firewall + router at home ... ;))
<lamont> actually, just pulled 2 of the 2GB sticks from it (dropping it to 6GB) due to single bit ECC errors
<lamont> nothing quite like a binary search in memtest
<slytherin> apw: can you please take a look at bug 506546 when you get time.
<ubot3> Malone bug 506546 in linux-ports-meta "Bump version for karmic-security" [High,Confirmed] https://launchpad.net/bugs/506546
<csurbhi> smb, hello ! 
<smb> morning csurbhi 
<slytherin> smb: can you please take look at the bug I mentioned?
<csurbhi> smb, did you get a chance to look at the 2.6.31.10 stable update mail ?
<csurbhi> do you think it looks good ?
<csurbhi> (apart from the buglink rtg mentioned about ?)
<smb> csurbhi, I will do when looking through your post. I have not get gotten there as I was hit by some problems on the Lucid update
<csurbhi> or is there anything i should do better ?
<csurbhi> ok..
<smb> Please give me time :) I am just one old man ;-P
<csurbhi> smb, hey... u are doing too much :) besides i am hogging your time :)
<csurbhi> smb, just for letting you know.. as you suggested.. i have added the buglink to the sru tracing bug and signed the patches
<csurbhi> but not acked them.. i thought that they should be acked after the review ?
<csurbhi> i hope that was right :)
<smb> Ah, its ok. Ok, cool, sure. I'll go through your mail immediately and see how it looks.
<csurbhi> ok.. thanks a lot :)
<smb> csurbhi, Right one question. As Tim noted, the links in the bug are malformed. Did you put in all manually?
<csurbhi> actually no.. i did not
<csurbhi> i just right clicked and pasted them.. but i did that late at night... maybe sleep disoriented my sense :( 
<smb> Hm, then there is a case that the script should catch
<smb> Oh,  wait
<csurbhi> the link in the patch.. i added through the maintool..
<csurbhi> but in the email.. by right clicking
<csurbhi> and then i sent the email
<csurbhi> is there any tool for doing that too ?
<smb> Hm, but look there http://kernel.ubuntu.com/git?p=surbhi/ubuntu-karmic.git;a=commit;h=0d2fb5a37a483f422186ba028d93f0985cc5bf40
<smb> Seems it is wrong in the patches
<smb> Which means you found something the script should not do
<smb> Do you remember how you called it to get that result?
<smb> Ah, seems "maint-modify-patch --bug =<nr> file" is handled incorrectly
<csurbhi> oh !
<smb> I need to fix that. The script should either throw an error or remove the = in that case.
<csurbhi> hmmm..
<csurbhi> so what do i do now ?
<smb> The simplest way (maybe only for me) would be to export the patches again from your tree, then do some sed magic to fix the buglink and ten re-import them after resetting the head. Then you can replace your repo with "git push origin +master"
<smb> Err, replace +master with +<your branch name>
<smb> csurbhi, Oh, an another thing: that repo you have. Is that a separate working tree with your private repo as origin?
<csurbhi> i pushed from my machine yes
<smb> Just one "trick" one can but does not need to use. You could have our main tree and then add your repo as a remote. This allows you to fetch the current stuff and easily push it to your repo.
<smb> So instead of "git push origin <branch>" you would say "git push <myrepo> <branch>"
<csurbhi> it push surbhi@kernel.ubuntu.com:/srv/kernel.ubuntu.com/git/surbhi/ubuntu-karmic.git <my branch>
<csurbhi> s/it/I did this:/
<csurbhi> smb, i will do this today again
<csurbhi> and should i resend the email again then ?
<csurbhi> smb, I invoked the script as follows:
<smb> csurbhi, try this: "git add remote myrepo surbhi@kernel.ubuntu.com:/srv/kernel.ubuntu.com/git/surbhi/ubuntu-karmic.git"
<csurbhi> ./maintools -b = <bugnumber> *
<smb> then you can next time do a "git push myrepo +mybranch"
<csurbhi> the directory only had patches in it
<smb> No need to send the email again (if there is not other things)
<csurbhi> ok
<csurbhi> will do that :)
<csurbhi> thanks again :)
<smb> np :)
<apw> smb, so once you got booted did you mmc card survive the suspend?
<smb> apw, You logged off a second to early yesterday. :) I was about to tell you that I cannot suspend anymore with a sd/mmc card mounted. On the positive side the card is not damaged in the process and it is the same with the -10 kernel.
<apw> smb, oh so somthing userspace has changed to prevent it
<apw> or just you never can now
<apw> hrm
<smb> apw, Probably that or the other, though I was too tired to bother to get to the bottom of it yesterday.
<smb> Have you had a run on your system?
<smb> apw, btw, S on boot hangs the same
<apw> yeah am running on it here, seems ok
<apw> smb, hrm, sounds like it needs a bug then
<smb> Yeah, we need something. Just idling around forever is not very intuitive
<slytherin> apw: Can you please sponsor this upload - bug 506546
<ubot3> Malone bug 506546 in linux-ports-meta "Bump version for karmic-security" [High,Confirmed] https://launchpad.net/bugs/506546
<apw> slytherin, looking ...
<apw> TheMuso, any reason we haven't bumped linux-ports-meta there?
<apw> (for karmic)
<slytherin> apw: the version has not been bumped for any updates in karmic. It should be bumped at least for -security.
<apw> slytherin, yep it should indeed.  trying to figure out what has gone wrong to prevent it happening again as much as anything
<smb> apw, Ok, so you say the linux-image packages for ports are created at the same time as the normal ones?
<apw> for karmic and lucid yes they are in the main repository, we just worry less about them failing to build
<apw> and its that that means we want the meta source separate to allow them to remain at a working build
<slytherin> and that is the reason why meta package is separate for ports
<apw> yep
<apw> but there is a procedural whole when we prepare a -security update in particular where that does not get pushed as part of the set.  fail.
<smb> So pulling the meta sources completely back into meta would be bad. But at least as a branch. Still this requires someone to know to check the ports builds and only upload the meta for those when everything is ok
<slytherin> I can take up that job as keep watch on powerpc builds. My primary machine is a iBook G4.
<smb> The problem likely is that all the ports meta packages are created from one ports-meta source package (if it works like for the main meta)
<smb> So its a all good or nothing issue
<apw> smb, yep.  though generally we assume if they build they are good enough for distro architectures
 * slytherin will be back after sometime.
<smb> apw, Yeah, I think this is mostly a procedural issue. When we document that abi bumps on the kernel also require a bump for ports-meta, then we less likely forget to add them to the security upload and get the sec-team to notify us should the ports have failed
<apw> smb, except right now we don't necessarily have the source to update
<smb> apw, Which is the problem to solve first
<apw> am workign on that right now
<smb> apw, tried "apt-get source linux-ports-meta"?
<apw> yeah obviously we can get that.  trying to find lukes repo
<apw> smb, think i have them
<smb> ok
<apw> smb, ok i've dropped an email onto kernel-team to start some discussions, i suspect you as a stable maintainer can add some detail on how things work and how it affect your end
<smb> apw, Ok, tahnks. I try to get to it later today.
<apw> no rush ...
 * slytherin is back
<apw> smb, what did you think to putting the ALPS patch into lucid
<smb> I wanted to spend a little more time to read over it. but with the feedback from Ben and given the implications it probably even makes sense to have it in Karmic.
<smb> For Lucid you might try to wait waht Greg decides
<apw> yeah it being in debian already, and it does sound like stable may take it
<apw> well it being in karmic, and not lucid puts us in regression territory
<apw> and it affects some common platforms i think ... a tricky one
<apw> and at this stage in the cycle its easier to shove it into lucid to test on non-affected h/w to give karmic some feedback perhaps
<smb> Definitely yes. Especially being so highe
<smb> hughe
<apw> so i think it makes sense to shove it into lucid in the next upload and see what happens then
<smb> This sounds reasonable. And would also be the usual SRU policy
<apw> ok ... i'll do that and see how we get on
<smb> Ok, ta
<vish> ogasawara: apw: hi... upstream has marked  http://bugzilla.kernel.org/show_bug.cgi?id=15047 as something to be handled by desktop/userspace feature ? so i would have to reassign Bug #503286 to which package?
<ubot3> Malone bug 503286 in linux "Bluetooth killswitch does not remember previous session state" [Unknown,Confirmed] https://launchpad.net/bugs/503286
<ubot3> bugzilla.kernel.org bug 15047 in Bluetooth "Bluetooth killswitch does not remember previous session state" [Normal,Resolved: invalid] 
<slytherin> vish: bluez package probably
<apw> hrm ... that is a good question ... yeah perhaps bluez
<vish> ok.. reassigning .. thanks guys
<vish> slytherin/ apw could someone comment on the bug ? for the bluez devs ?
<slytherin> vish: You can add a comment yourself pointing that upstream has closed the bug as invalid.
<vish> that was my last alternative. ;) but sure thanks
<csurbhi> smb, I wanted to change the kernel config option..
<csurbhi> i have changed it from debian.master/config/<file>
<csurbhi> manual change
<csurbhi> is that alright ?
<smb> csurbhi, I believe it was only set there. But to be sure run "fdr updateconfigs" to check whether the result remains the same
<csurbhi> alright :) thanks!
<smb> welcome :)
<smb> csurbhi, I hope I covered everything in my reply mail. All in all I thing there are the two bugs where to either add or remove bug links and then also adding the patch that gets dropped with .11. Plus putting .11 patches on  top of it all (referencing the one tracking bug)
<csurbhi> smb, ok.. thanks for the review.. i am going through it once again :)
<smb> csurbhi, It _is_ a treadmill, I am afraid. :)
<csurbhi> smb, i agree totally :)
<csurbhi> smb, there is also a comment about ABI bump
<csurbhi> for a ipv6 patch
<csurbhi> how do we deal with tat one ?
<smb> I think it might. But in the end, its only found out by compiling without and then see
<csurbhi> ok
<smb> If the build fails without an abi bump we need one
<csurbhi> and also about the  s/390 ?
<csurbhi> smb, ya..  so the next step is to try to build karmic with the update ?
<smb> Don't worry too much about that. Its just as I worked on that. :)
<csurbhi> ok :)
<csurbhi> so i need to remove the lp buglink from your patch
<smb> csurbhi, Right. Take your branch and test build it on at least amd64 and i386
<csurbhi> and then redo everything again
<csurbhi> ya.. i will do that :)
<smb> Maybe the simplest way is a export all, modify as needed then pull them in again approach
<smb> that way you could also squeeze in the one patch dropped , to be reverted by .11
<csurbhi> ok
<csurbhi> right.. so we apply the patch that needs to be reverted as a part of .11 ?
<csurbhi> and do all this together ?
<smb> Yeah, I think thats the best approach. The patch itself should then actually not even show up in the changelog and we got the same sequence as upstream
<csurbhi> ok.. cool.. i will do that ..
<smb> Just make a note on the tracking bug (that it includes both) and also reply to your own mail to update that we chose to take both in one go
<csurbhi> alright
<rtg> smb, is there a more elegant way of determining host type without asking bash? 'set|grep HOSTTYPE'
<smb> rtg, hm is uname -m what you want?
<rtg> smb, ah, how could I have forgotten that ?
<smb> rtg, It is actually not the same result
<csurbhi> uname -m
<rtg> smb, no, but it at least tells me the arch 
<smb> rtg, Otherwise "dpkg-architecture -qDEB_HOST_ARCH"
<csurbhi> uname -m and echo $HOSTTYPE.. print differnt vals ?
<rtg> smb, that requires dpkg-dev
<rtg> csurbhi, i386 vs i686
<csurbhi> hmm..
<smb> or i486 vs i686 on my netbook
<rtg> right
<rtg> mostly I'm interested in it _not_ being x86_64
<smb> Ok, so uname -m is usable for that
<csurbhi> smb, one question
<smb> hmm
<csurbhi> while reverting a commit.. do we note the revert in the tracking bug ?
<smb> I don't think we did... Though you might check on the other tracking bugs
<smb> But probably it is a good idea to make at least a comment there.
<smb> csurbhi, So lets do it this time and onwards. Just add a comment with the subject of the patch and note that this replaced one we already carried.
<csurbhi> ok.. cool :)
<csurbhi> smb, do you think i should make a new git branch as the name 2.6.31.10 for the two updates 2.6.31.10 and 11 will be misleading ?
<smb> csurbhi, I usually avoid that problem by calling my branch "proposed" or something similar unspecific. In the end its for the purpose of review only.
<csurbhi> i will keep that in mind now
<smb> Its just a minor detail and you can freely be creative with the name of your branch
<smb> as long as you tell the name when sending emails
<rackerhacker> jjohansen: sorry for bugging you, but did you happen to find time to review that initrd memory freed issue in linux-ec2?
<jjohansen> rackerhacker: I poked at it briefly but haven't had time actually figure out what is happening
<rackerhacker> that's okay... would it help at all if i snagged some details and made a proper bug report/
<rackerhacker> or would that just be annoying ;-)
<jjohansen> rackerhacker: by all means go ahead and provide as much detail as you can
<rackerhacker> jjohansen: will do - thanks much... this build is quite helpful
<rackerhacker> i ran into a lot of trouble with getting karmic to boot in a domu using 2.6.24 kernels from hardy
<rackerhacker> i stumbled across some documentation that said upstart required 2.6.27+
<jjohansen> rackerhacker: well it would certainly be a good idea,  I have booted a domu on less but I wouldn't call it reliable
<rackerhacker> the 2.6.24-59 group of kernels from hardy seem to work well on all of the distros we run with the exception of karmic
<rackerhacker> there was a switch in the release candidate that required a later kernel for upstart to function
<rackerhacker> it caused much head-pounding-on-desk ;)
<rackerhacker> jjohansen: i logged the bug, but i wasn't sure which details would be relevant (https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/510243)
<ubot3> Malone bug 510243 in linux-ec2 "linux-ec2 x86_64 memory calculation incorrect" [Undecided,New] 
<rackerhacker> well that's fancy
<jjohansen> rackerhacker: okay thanks, I'll look at it in a bit
<rackerhacker> no problem, thanks!
<rackerhacker> jjohansen: i'd love it if we could eventually get an upstream fix for the save/restore bug in domu's :/
<rackerhacker> i know fitzhardinge has a patch or two
<jjohansen> rackerhacker: interesting
<rackerhacker> have you run into that bug before?
<rackerhacker> i know it's an upstream issue, so i didn't want to waste your time with it
<rackerhacker> the xm save hangs, and you end up with this in the domU's dmesg -> http://pastie.org/786816
<rackerhacker> i was able to make a build of jeremy's xen.git repository, and the save eventually worked, but i ran into other issues
<jjohansen> rackerhacker: no I haven't but I was aware there were some issues
<rackerhacker> it's not the best time to be a xen vps provider with the pv_ops shenanigans ;)
<sconklin> ogasawara: do you know which git repo Greg queues his patches for stable in?
<ogasawara> sconklin: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.31.y.git
<sconklin> AH! he applied it to the 32 tree and it probably also should go to .31, I'll take care of it
<sconklin> thanks
<TheMuso> apw: Haven't got to it, will take care of it this morning.
<TheMuso> apw: If you mean lucid that is.
#ubuntu-kernel 2010-01-21
<achiang> what is the process for requesting a backport into currently shipping kernel? say i have a patch i'd like to see in karmic...
<achiang> hm, and i guess i'd want to see it backported to lucid too, since /subject says it's based on .32
<achiang> http://bugzilla.kernel.org/show_bug.cgi?id=15064
<ubot3> bugzilla.kernel.org bug 15064 in Config-Processors "no deep C-states on core-i7, thus no turbo" [Normal,Resolved: code_fix] 
<achiang> without that patch, lots of folks are experiencing issues on the new batch of Intel Core i7 laptops
<crimsun> achiang: is it in a .32.x point release?
<achiang> crimsun: hm, no. we did not mark it for -stable
<achiang> crimsun: i mean, linus hasn't even pulled it yet, but even after he does, we didn't tag it with -stable, so it won't get picked back up by gregkh
<crimsun> I suppose the most straightforward way is to file a bug affecting linux and get it into a point release
<achiang> crimsun: you mean a launchpad bug?
<crimsun> yes, https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<achiang> crimsun: reading the KernelTeam homepage to try and find the policy; do ubuntu only backport patches in the -stable trees?
<crimsun> achiang: I'm unfamiliar with the precise SRU policy/policies for each Ubuntu release; smb/rtg/apw would be best to ping on that.
<dhillon-v10> ogasawara: ping regarding glibc changed in the lucid kernel
<JFo> dhillon-v10, can you elaborate for the channel at large? perhaps someone here can help you.
<JFo> and I am also not sure what you mean about glibc changing in the kernel... it isn't in the kernel
<dhillon-v10> JFo: hi there, sorry for the delay, a friend of fine and a lot of other people are experiencing this problem: when they use kvm with lucid images it breaks kvm, that's because of a commit made upstream to glibc which changed all calls that previously pointed to about() to free() now
<dhillon-v10> JFo: and free() returns an aborting signal breaking kvm
<dhillon-v10> JFo: I have a fix for it, but its a dirty hack, it involves adding a line to /etc/profile
<cooloney> dhillon-v10: that looks like an glibc issue
<dhillon-v10> cooloney: yup :) I read a conversation on LKML where they made this change to glibc so I was wondering how do I go about fixing it
<cooloney> dhillon-v10: is there any bug tracker on launchpad for this issue, maybe we can help that. 
<cooloney> dhillon-v10: i guess ogasawara is going to sleep now.
<dhillon-v10> cooloney: ahh right, sorry ogasawara, I will get you the link in a sec.
<less1> Hi, I am sure if this is right place to ask this question.  I am working on ubuntu booting over http.  I have working prototype up at http://www.etherboot.org/share/pravin/UbuntuNet/  Can someone guide where can I get more feedback about this?
<JFo> less1, you are looking for #ubuntu
<JFo> someone in there should be able to help or at least point you in the right direction. :)
<less1> JFo: thanks.. I will check it out.
<JFo> certainly
<crimsun> bjf: hi, some questions about the git packaging of cod alsa: firstly, is there supposed to be a metapackage in debian/control.d/flavour-control.stub? linux-alsa-driver-modules-PKGVER-ABINUM-FLAVOUR doesn't do anything useful, so I guess it's supposed to be renamed and a proper Depends added?
<crimsun> bjf: I can push those changes for alsa-driver-cod-{karmic,lucid}.git to my tree on zinc
<bjf> crimsun, I tried to just take the LBM packaging and reuse it, but I may have messed it up, I'm pretty green w.r.t. packaging
<bjf> crimsun, I'd welcome any changes you have
#ubuntu-kernel 2010-01-22
<bjf> crimsun, got to run for now but I'll be back
<crimsun> bjf: sure, just working out the -meta split
<tvrotsurbrain> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<tvrotsurbrain> !staff
<ubot3> Hey nalioth, jenda, rob, SportChick, seanw, Dave2, Christel, tomaw, Gary, PriceChild, niko or stew, I could use a bit of your time :)
<mozmck> I'm getting a bunch of errors like this trying to run debian.master/scripts/misc/kernelconfig oldconfig
<mozmck> kernel/ubuntu-karmic//config/amd64: No such file or directory
<paultag> Hey hackers. I need some help with the kmalloc implementation. Anyone know the details of how it's implemented in the kernel ( how it works out where it pulls mem from / the flag system etc )
<mozmck> This is with the ubuntu-karmic git tree.
<cooloney> mozmck: run 'fakeroot debian/rules clean'
<cooloney> mozmck: then try 'fakeroot debian/rules editconfigs'
<mozmck> will do, thanks.  I'm trying to add another flavour for an rtai patch.
<cooloney> mozmck: and we use 'fdr' alias to 'fakeroot debian/rules'
<mozmck> It adds some kernel config options, will they show up properly?
<cooloney> yeah,
<cooloney> mozmck: try fdr help
<mozmck> so I can type fdr?
<mozmck> 'fdr help' No command 'fdr' found...
<cooloney> oh you need to add this -> alias fdr='fakeroot debian/rules' into your .bashrc
<cooloney> or just fakeroot debian/rules help
<mozmck> I see.  thanks.  Also, I switched back to bash from dash because there have been programs that wouldn't compile under dash.  That shouldn't be a problem for working with the kernel scripts should it?
<cooloney> mozmck: bash is ok, i think, but i never change my shell program
<mozmck> haven't had any problem with bash so far, and that's what I've used for years.  dash has given a few problems...
<cooloney> mozmck: heh, i guess you can ping Herbert Xu, he is the author of dash,
<paultag> Any chance I can get a kernel guru to enlighten me? :)
<mozmck> It was probably related to how the scripts in the build system for those programs worked.
 * mozmck no guru
<cooloney> paultag: you can grep the kmalloc in kernel source code, 
<paultag> cooloney, that's all well and good, but I'd spend a long time tracing code back to how it manages a lot more then just the heap. I was looking for some insight from a hacker 
<paultag> cooloney, I started doing that and got lost
<cooloney> paultag: yeah, that is very tedius, but i suggest you to post email on LKML for help
<paultag> cooloney, awww. Crap. They always hate the friendly n00b.
<paultag> cooloney, thanks anywho
<cooloney> paultag: most of the kernel hackers are there, or you can send out email to the mm developer directly, heh
<paultag> cooloney, I'm probably better working off working it out by hand on paper :/
<paultag> cooloney, thanks anyways :)
<paultag> I'll leave ya'll to your hacking :) -- thanks for the stable kernels :)
<tim> hi all, is it possible to apply a patch to the module sources before building it with dkms? i am trying to build the nvidia driver for 2.6.33-rc 
 * cking having bad network afternoon
<dhillon-v10> hi all, just wanted to know if its possible to get links for *all* the kernel-bug days that took place
<achiang> what does it mean if a kernel bug is in "confirmed" state? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/463940
<ubot3> Malone bug 463940 in linux "No fans, thermalzone on HP Envy 15 and HP DV6T Quad" [Medium,Confirmed] 
<dhillon-v10> achiang: that means someone else tested it and it indeed is a bug :)
<achiang> dhillon-v10: ah, so has nothing to do with actually shipping the fix? :)
<dhillon-v10> achiang: well that means devs will work on that one as soon as they find the time, or you can go ahead and work on it ;)
#ubuntu-kernel 2010-01-23
<fwec> Hi all.  It seems we are again seeing javascript based flood spam.  If you are experiencing this, please do not click the links in the messages as they will cause you to repeat the spam. More information is available at http://peoplesprimary.com.  Thanks!
<fwec> Hi all.  It seems we are again seeing javascript based flood spam.  If you are experiencing this, please do not click the links in the messages as they will cause you to repeat the spam. More information is available at http://peoplesprimary.com.  Thanks!
<sbufw> sloth and jenk show is LIVE Theme: Hating on Haiti (877-419-7477) http://klulz.fm/listen.pls
<sbufw> sloth and jenk show is LIVE Theme: Hating on Haiti (877-419-7477) http://klulz.fm/listen.pls
<sbufw> sloth and jenk show is LIVE Theme: Hating on Haiti (877-419-7477) http://klulz.fm/listen.pls
<sbufw> sloth and jenk show is LIVE Theme: Hating on Haiti (877-419-7477) http://klulz.fm/listen.pls
<sbufw> sloth and jenk show is LIVE Theme: Hating on Haiti (877-419-7477) http://klulz.fm/listen.pls
<sbufw> sloth and jenk show is LIVE Theme: Hating on Haiti (877-419-7477) http://klulz.fm/listen.pls
<JFo> thanks kloeri_ :)
<kloeri__> you're welcome
<mtx_init> since C is a foundation for the kernel, is it also possible use another language like python?
<RAOF> mtx_init: In linux kernel code?  No.
<mtx_init> why not, given its just libraries no?
<RAOF> Because kernel code doesn't get to depend on libraries.
<RAOF> It doesn't even link to libc.
<mtx_init> but it does have a library it uses? it must
<mtx_init> Freebsd uses libc, so linux doesnt?
<RAOF> Why would the kernel need a library?  libc *uses* the kernel to do its stuff; the kernel can't use libc :).  It has to be actually implemented somewhere :)
<RAOF> Code *written* for linux can use libc or whatever libraries it wants.  The kernel can't, because the kernel is the thing which is providing the underlying bit-twiddling that makes the libraries work.
<mtx_init> so lets say you want to use a basic c function like read, if the kernel doesnt use a library where does it get read from?  I mean when you compule a kernel it goes through a linker doesnt it?
<johanbr> it doesn't get read from anywhere, the kernel can only rely on functions internal to itself
<mtx_init> yeah but the kernel is just a image like everybody else and needed to be built and compiles with libraries. The functions still came from a library at one time or another. 
<RAOF> No.  No libraries.
<RAOF> Compiled, but not linked.
<RAOF> (Well, not to anything outside itself).
<mtx_init> why does the freebsd kernel need to be linked then and not the linux?
<RAOF> All the âstandard C functionsâ you can think of are implemented *on top of* functions provided by the kernel.  The kernel can't use read(), because the kernel is providing the functionality that read() uses to work :)
<RAOF> Maybe the freebsd developers are more confident in their ability to segregate the code that can't link to anything from the code that can?
<mtx_init> so how does a system call use read()
<RAOF> You mean, a call from within the kernel?  *It doesn't*.
<RAOF> There's a whole bunch of stuff you can't do from within kernel (linux) code.  Use the FPU, for example.
<mtx_init> so usermode can only do that?
<RAOF> Right.
<mtx_init> so the kernel knows what read is but cant use it?, how the heck is the kernel pulls if the hdd then?
<mtx_init> pulled*
<DanaG> hmm, are the mainline kernel builds supposed to have staging drivers disabled?
<DanaG> I need two specific drivers: r8192se, and samsung-laptop.
#ubuntu-kernel 2010-01-24
<xxthink> How to upgrade the kerenel of my 64 bit ubuntu 9.10 2.6.32
<xxthink> I have downloaded the deb package
<xxthink> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc5/linux-headers-2.6.33-020633rc5-generic_2.6.33-020633rc5_amd64.deb
<xxthink> and 
<xxthink> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc5/linux-image-2.6.33-020633rc5-generic_2.6.33-020633rc5_amd64.deb
<xxthink> How to install it?
<dhillon-v10> xxthink: any specific reason to upgrade the kernel ?
<xxthink> now the kernel is 2.6.31
<dhillon-v10> xxthink: a lot of other stuff can break because of updating the kernel
<xxthink> dhillon-v10: this kernel version is too slow for me
<crimsun> xxthink: you also need linux-libc-dev and linux-headers-2.6.33-020633rc5
<dhillon-v10> xxthink: :) when the ubuntu kernel team releases the next version you will get an SRU so until then don't worry about it, you can screw up a *lot* of stuff on your computer, but if you don't care then its okay :)
<xxthink> dhillon-v10: I now need this latest kernel
<xxthink> especially for my 64 bit unbutu server edition
<dhillon-v10> xxthink: alirght then, let me get the link in a sec.
<xxthink> ok
<xxthink> dhillon-v10: do you find the corresponding linkï¼
<johanbr> xxthink, there's no particular reason to believe the next kernel version would be faster
<xxthink> http://x264dev.multimedia.cx/?p=185
<johanbr> unless it's due to a bug and it's been fixed in the next version
<xxthink> this is why I use the latest version
<xxthink> the thread scheduling efficiency is low for me. This problem is fixed in 2.6.32 version and later
<johanbr> ahh, okay
<johanbr> if you download linux-image-blah and the corresponding linux-headers-blah package and install those, you should be fine
<xxthink> johanbr: but I don't know how to install
<xxthink> I just download the two deb package
<johanbr> sudo dpkg -i linux*deb
<xxthink> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc5/linux-headers-2.6.33-020633rc5-generic_2.6.33-020633rc5_amd64.deb
<xxthink> ok, let me try
<xxthink> johanbr: where these two package should be placed?
<johanbr> anywhere
<xxthink> in the same folder?
<johanbr> yes
<dhillon-v10> xxthink: sorry had to go: https://help.ubuntu.com/community/Kernel/Compile
<xxthink> dhillon-v10: I have installed the kerenel 2.6.33 I have downloaded before
<sroecker> hi, how do I check if my acpi has a backlight interface?
<RAOF> Oh, it's still Sunday for most of the kernel team, isn't it.
<jk-> most of it :)
#ubuntu-kernel 2011-01-17
<drop_bear> hello. I was just at ubuntu beginners with a printer problem and was told to run this command "tail /var/log/messages" and paste the results which can be found here http://paste.ubuntu.com/554930/ they said that I have a segmentation fault and that I should head here straight away and let you guys know.... so here I am
<drop_bear> hello?
<paultag> pgraner: prod -- sorry for the ping ( and if you're anything like amber you won't be online right now ), but I sent drop_bear over. He has a module level segfault. Thought you guys might like toknow
<paultag> BBL
<jk-> paultag: module level? looks like a segfault in libc, possibly caused by system-config-printer
<paultag> jk-: I did not look too carefully. I'm packing to leave as I type
<paultag> jk-: great, thanks. I think it's bugreport time
 * lamont is saddened that lvm won't let him make a snapshot of a snapshot
<Kano> hi apw` 
<Takyoji> Any straightforward method of testing a kernel regression that occurred between 2.6.31-20 and 2.6.35-22?
<Kano> i saw the 37-12 kernel has got the older r8192_pci driver renamed as r8192se_pci together with r8192e_pci
<Kano> basically thats useles
<Kano> a backport worked maybe for older kernels but not for .37
<Kano> how about fixing the new r8192e_pci one?
<Kano> for my n510 i still use the latest .32 mainline kernel, no other kernel has working wlan out of the box
<komputes> Is there any way to have the fix in Bug #380126 be applied to 10.04?
<ubot2> Launchpad bug 380126 in xserver-xorg-input-synaptics (Ubuntu Natty) (and 7 other projects) "[Karmic] Touchpad not recognised correctly, synaptics driver not in use (affects: 82) (dups: 1) (heat: 399)" [Undecided,Invalid] https://launchpad.net/bugs/380126
<apw> komputes, as far as i can see the backport to maverick is out for review and lucid is marked as being worked on
<komputes> apw: does it show by which individual?
<apw> komputes, yep the assignee
<komputes> apw: rtg?
<komputes> k thx
<apw> indeed
<maxb> Hrm. Something about the maverick-proposed kernel makes my radeon very very unhappy. Corrupted graphics in X to the point of unusability
<maxb> [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
<RAOF> maxb: And it's *just* the maverick-proposed kernel?
<maxb> yup, I just rebooted a couple of times in it, and reprocably got the problem. Went back to -24, and it's fine
<maxb> *reproducably
<maxb> bug 703553 apparently
<ubot2> Launchpad bug 703553 in linux (Ubuntu) "After upgrade to linux-image-2.6.35-25 graphics are broken (affects: 5) (dups: 1) (heat: 28)" [Undecided,Confirmed] https://launchpad.net/bugs/703553
<skaet> bjf, sconklin can you paste me the link where I can find the bug numbers of the tracking bug for last week's maverick/lucid kernel drops?
<bjf> skaet, https://kernel-tools.canonical.com/srus.html
<skaet> thanks bjf!
<bjf> skaet, look for the lines with the "asterisk" icon
#ubuntu-kernel 2011-01-18
<poelzi> a question. do you guys plan to enable the autogrouping feature in 2.6.38 ?
<abogani> poelzi: It is already enabled.
<poelzi> abogani: is there a common way to disable it. my current project ulatencyd does the same job more advanced. i just made packages in they should disable the autogrouping then
<poelzi> ahh. i found it
<apw> poelzi, there is meant to be a kernel comamnd line option and a sysctl with the full patch
<apw> poelzi, not sure they are there for the one which is in natty as uploaded
<poelzi> apw: i just looked it up and i'm now using the sysctl to disable autogrouping when detected
<apw> not sure if the v2.6.37 version we have applied has those toggles or not
<poelzi> that would be quite bad
<poelzi> but i guess the autogrouping will schedule only once ?
<apw> poelzi, *shrug* it won't be in the archive that long, and natty is often broken
<poelzi> as ulatencyd uses netlink to schedule new processes quite fast, it should move it away
<apw> poelzi, sounds about right
<jibel> apw, Hey, could you have a look at bug 703553, it's been introduced by the kernel in maverick-proposed apparently.
<ubot2> Launchpad bug 703553 in linux (Ubuntu Maverick) (and 1 other project) "After upgrade to linux-image-2.6.35-25 graphics are broken (affects: 14) (dups: 2) (heat: 62)" [High,Confirmed] https://launchpad.net/bugs/703553
<apw> jibel, looks bad to me, i've subscribed the stable team ... they will be pleased
<jibel> apw, thanks. 
<apw> bjf[afk], ^^
<bjf> apw, yes, I saw it earlier
<apw> bjf, cool
<bjf> apw, not really :-)
<apw> bjf, cool for me its on your list not mine :)
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<sforshee> regarding bug 702407, I have a pretty trivial patch that helps with diagnosing hotkey issues on thinkpads. Would this be something we would want in a lucid/maverick SRU?
<ubot2> Launchpad bug 702407 in udev (Ubuntu) (and 1 other project) "thinkpad_acpi generated EV_KEY events are mssing scancodes (affects: 1) (heat: 8)" [Medium,Fix committed] https://launchpad.net/bugs/702407
<sforshee> I've submitted the patch upstream and it's been acked by the maintainer, but it isn't merged into any trees yet
<smb> We probably should wait until it hits upstream. As it is not directly a bug that is fixes the argument may be sort of aiding enablement. Which may rather qualify it only for Lucid as Maverick more and more reaches the end for that kind of things
<mjg59> sforshee: I'll merge that this week
<apw> sforshee, then i could suck that in to natty for the -rc1 kernels for you to test
<sforshee> mjg59: great, thanks!
<apw> smb, i think we should consider it for L and M as it does mean that pitti can fix a lot more stuff without bothering us
<apw> and sforshee congrats, thats great
<sforshee> apw, thanks
<smb> apw, He might be more relaxed about that change (not fixing a bug) in that case as he is affected. :)
<tgardner> apw, will soon push a patch for bnx2 firmware file name updates in d-i/firmware/nic-modules 
<tgardner> just test building to make sure
<apw> tgardner, again?  what the heck is with that driver changing each and every time
<apw> tgardner, and mei aculpa i did not do a full build yet
<tgardner> apw, I guess its just firmware version updates.
<apw> tgardner, yeah, just odd that that one driver is always the one which does it
<tgardner> apw, not so odd really. there are only 2 drivers in that udeb that need firmware, and the e1000 seems to be pretty stable.
<apw> tgardner, i just didn't want you getting over excited and doing the rebase too, it took me a day and half with all the issues in ubuntu/ drivers
<apw> so i pushed it before i had time for a full rebuild test
<tgardner> apw, no worries. I just sat around and drank beer and chased woman for 3 days :)
<apw> tgardner, sounds wonderful ;)
<apw> tgardner, let me know when you've pushed and i'll get my builds going
<tgardner> apw, pushed
<apw> sforshee, have you got a bug number for that thinkpad patch ... do i can track it as it merges
<apw> so
<sforshee> apw, 702407
<apw> sforshee, doh its in my web browser already ... mind==gone
<sforshee> apw, np, it's near the end of your day so you have an excuse
<bjf> ##
<bjf> ## Kernel team meeting in 30 minutes
<bjf> ##
<Diels-Alder> hi everybody
<Diels-Alder> I need an information
<Diels-Alder> do you know the first kernel that fully support core i7?
 * apw wonders which code name i7 had
<smb> Had been running 2.6.32 with one, though that probably was not the first one
<elmo> nehalem
<Diels-Alder> yes nehalem core i7 930
<apw> yeah my earliest experience i think was on Lucid for those
<smb> apw, Sounds reasonable. There is a patch to recognize Nehalem IDs in coretemp going into 2.6.27-rc4
<smb> which seems about the first places to see that word. Whether that means full support is something else
<Diels-Alder> thanx
<Diels-Alder> byebye
<tgardner> bjf, pushing Maverick LBM to canonical-kernel-team PPA
<tgardner> sconklin, ^^
<bjf> tgardner, ack
<sconklin> tgardner: ack
<bguthro> I think .35 had the first full Ironlake support, as part of the i7 - so if by "full support" you include graphics, I think it was .35
<tgardner> sconklin, as part of your source package checklist, do you verify the upload pocket is correct for the canonical-kernel-team PPA? e.g., maverick v.s. maverick-proposed ?
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<sconklin> Not on the manual checklist, bradf can say whether it's in the script
<bjf> tgardner, noted
<komputes> Anyone seen rtg recently?
<apw> komputes, if thats about the touchpady thing, then its now Fix Committed for both maverick and lucid
<komputes> apw: it is, when can we expect the update?
<apw> komputes, i think we are in the middle of an SRU cycle, so if a perfect world i think its about 3 weeks from release if its in master-next
<komputes> apw: will pass that along, thanks for the info
<tgardner> bjf, sconklin-afk - did the armel build issues get sorted? I notice that the maverick meta still has them disabled.
<bjf> tgardner, not that i'm aware of, sconklin is tracking it
<tgardner> bjf, ok. I'm gonna whack on maverick meta to enable the new compat-wireless-2.6.37 package
<bjf> tgardner, ack, sconklin ^
<apw> tgardner, i suspect till we ask for a build in there we won't find out
<jjohansen> rebooting
<tgardner> apw, I guess I was asking 'cause I wanted to know that someone was actually working on it.
<tgardner> sconklin-afk, bjf: could you use your not inconsiderable influence to get linux-backports-modules-2.6.35 copied to -proposed from the canonical-kernel-team PPA ?
<bjf> tgardner, ack, will ping pitti
<cking> bjf, where is that webby page of patches that need testing in proposed?
<bjf> cking, https://kernel-tools.canonical.com/srus.html
<cking> ta muchly
<cking> and when's the next proposed - in 2 weeks time?
<cking> (for maverick)
<bjf> cking, roughly, yes
<tgardner> bjf, I'm wondering if its really worth uploading LBM and meta to the canonical-kernel-team PPA if there are no CVEs ? Why not go straight to -proposed ?
<bjf> tgardner, sconklin and i were talking about the same thing last week
<cking> hrm, the Dell AMI all-in-one patch - got acked but did it get applied?
<bjf> tgardner, i hate to have multiple processes but it seems to be more work to put things in the ppa
<bjf> cking, yes, I put in into maverick yesterday
<tgardner> bjf, seems like its only the kernels that are required to go through c-k-t
<bjf> tgardner, ack
<tgardner> bjf, well, I'll just upload meta to -proposed directly, then when LBM gets pocket copied everything ought to be copascetic
<bjf> tgardner, ok, sounds reasonable
<cking> bjf, thanks!
<bjf> brb
<bjf> apw, have a screenshot of the panic if you care :-)
<apw> yep paste it up
<bjf> it's in the root of my zinc account
<bjf> apw, i have a thought on it
<bjf> apw, i booted with a live image and mounted the root partition
<bjf> apw, i noticed that though i'm booting 2.6.37-12, my initrd.img is still pointing at a -7 img
<bjf> apw, looking in the boot directory, there isn't a -12 initrd.img file
 * tgardner --> lunch
<jbarnes> can someone make sure avahi gets patched so upstream kernels will work?
<jbarnes> see http://www.spinics.net/lists/netdev/msg152775.html
<cking> apw, ^
<jbarnes> oh and making sure /sbin/installkernel gets fixed too would be a plus :)
 * jbarnes has been waiting impatiently for 3 years for that fix
<smb> :
<tgardner> jbarnes, can you refresh my memory on your issues with installkernel?
<jbarnes> tgardner: it doesn't make a new initrd nor update-grub to add it to the boot menu
<tgardner> jbarnes, I guess I've never used it. lemme look. its part of debianutils
<jbarnes> tgardner: I always just add mkinitramfs -o /boot/initrd.img-$ver $ver and update-grub to the end of the script
<jbarnes> it's an easy fix
<jbarnes> I just have to do it everytime I install a new dev machine :)
<tgardner> jbarnes, Clint Adams <clint@gnu.org> appears to be the upstream for this. Have you sent him a patch?
<jbarnes> no, iirc there's an upstream bug and fix, but it hasn't landed in debian
<tgardner> jbarnes, I'll drop a note on the debian kernel list to find out if there is a good reason why mkinitramfs and update-grub shouldn't be run, especially if its an x86 arch.
<jbarnes> thanks
<tgardner> jbarnes, do you have a pointer to the bug? If not I can likely find it.
<jbarnes> not offhand, apw gave it to me last time
<bjf> Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - January-25 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - January-25 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<tgardner> jbarnes, is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607411 what you're thinking of?
<ubot2> Debian bug 607411 in debianutils "installkernel should run-parts /etc/kernel/postinst.d" [Wishlist,Open]
<jbarnes> tgardner: yeah looks like that would do it
<tgardner> jbarnes, I'll mess with it. I can likely get it fixed for Natty
<jbarnes> sweet
 * jjohansen -> lunch
<apw> jbarnes, i have the avahi issue reported with the upstream avahi
<apw> jbarnes, i assume that they are not going to back out the change
<jbarnes> cool
<tgardner> apw, did you get it uploaded?
<apw> tgardner, not as yet, the advice from foundations was to wait a couple of days to let upstream fix it, if that occurs in time the we can just sync the fix in, if that isn't here in time then we do my fix
<tgardner> apw, so, in the meantime everything is broken?
<apw> tgardner, only if you have .38 installed which isn't in the archive
<apw> basically they said shove it in if we upload .38
<tgardner> ok
<apw> i will ask my friendly tgardner to sponor my upload should that happen
<tgardner> apw, I'm not gonna be around much tomorrow. Likely gone by 0900 my time
<apw> tgardner, no worries, i am sure martin or colin will handle it, they are both aware
<manjo> sforshee, did not see a mail from you yet ... 
<manjo> bjf, call is 6pm pacific ? 
<bjf> manjo, that's what the email says
<manjo> bjf, just making sure, that is 8pm for me 
<sforshee> manjo, I sent one on Thursday, I'll try resending
<manjo> sforshee, thanks
<sforshee> manjo, just resent the message, let me know if you don't get it sometime soon
<manjo> sforshee, did you send it to marjo ? :) 
<manjo> will wait for it ... 
<sforshee> manjo, i replied to the message you sent me
<manjo> ok
<sforshee> manjo, did the email ever arrive?
<manjo> sforshee, just pm me .. I did not get it 
<bjf> apw, I "fixed" my natty, I reinstalled Alpha 1 and then just updated the kernel. The initrd was correctly updated. I rebooted and then dist-upgraded and rebooted again and I'm up
<bjf> apw, if you just do a straight dist-upgrade from an alpha 1 install "bad things happen"
<jjohansen> bjf: is that a new problem?  I have a machine that I have been updating and haven't run into any problems
<jjohansen> well besides it still doesn't have video
<bjf> jjohansen, i had a natty that was dist-upgrading just fine until the friday before the sprint and then it just came apart
<bjf> jjohansen, i was forced to install Maverick to have a system to take with me
<jjohansen> bjf: interesting, I know I have dist-upgraded during the sprint
<bjf> jjohansen, I just tried putting natty on it today and ran into the same issue, above is my work around
<jjohansen> hehe, well I still have maverick + natty kernel on the machine I was going to take
<jjohansen> bjf: okay, I'll take a stab at replicating here
<mrtadis> Hi, my Ubuntu 10.04 laptop wakes up from suspend unexpectedly. Does the OS logs what was the wake-up source?
#ubuntu-kernel 2011-01-19
<Kano> hi apw , is 38-rc1 ready soon?
<Kano> mainline i mean
<apw> smb, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/681083 looks to be a xen issue in the lucid -proposed kernel (i think)
<ubot2> Launchpad bug 681083 in linux (Ubuntu) "Ubuntu Crashes/Freeze on XenMotion (affects: 3) (heat: 26)" [Undecided,Triaged]
<smb> apw, Just one more I need. :-P Thanks for the pointer though
<apw> smb, i subbed the stable team, but thought you might have insite as you have more xen knowledge
<smb> apw, The initial output looks more like generic blockage though the others hit some BUGON in spinlock. And there seems to be a patch referenced as well
<apw> smb, yeah thats why i saw it, patch piloting over the patch
<smb> apw, So it seems Natty is safe already as that went into 2.6.37. And as there is no xen in .32 we need our topic branch pull that in
<apw> the patch in the bug is already upstream?  got a commit id ?
<smb> yes it is. bah, just closed the window. A sec
<smb> I believe that one: 6903591f314b8947d0e362bda7715e90eb9df75e though the title is slightly different
<apw> yes that is deffo the patch
<apw> smb, will you write that up for the bug
<smb> yup
<apw> smb, ta muchly
 * tgardner --> server room
<apw> sconklin-gone, bjf, we seem to be missing some kernel dependant packages in the latest uploads, ie. that meta has been uploaded before lum/lbm/lrm etc are built
<apw> this has been reported on our kernel-team list for hardy
<tgardner> apw, actually, I'm just checking that. I think its LPIA thats missing
<apw> tgardner, as in lum for lpia only ?
<smoser> smb, just trying to remember. i386 natty kernels on m1.small fail like : http://paste.ubuntu.com/555805/
<Warlock072> hey guys 
<Warlock072> ive got ubuntu lucid server showing high cpu usuage on this command ksoftirqd
<smoser> smb, never mind . i found bug 699828
<ubot2> Launchpad bug 699828 in linux (Ubuntu) "natty 2.6.37-11-virtual doesn't boot on EC2 in 32bits (affects: 1) (heat: 444)" [High,Confirmed] https://launchpad.net/bugs/699828
<apw> Warlock072, that is interrupt related, does any of the lines in /proc/interrupts show high numbers/high change between two consecutive cats ?
<Warlock072> ps -aux | grep ksoftirqd root        22 73.1  0.0      0     0 ?        S    15:11  84:25 [ksoftirqd/6]
<Warlock072> Local timer interrupts
<Warlock072> TLB shootdowns
<Warlock072> changes alot
<Warlock072> IO-APIC-fasteoi   megasas
<Warlock072> this one seems to jump alot
<hallyn> ppa:kernel-ppa/ppa only has natty images.  Where should I point a user for maverick daily builds?  Or should they just use the natty one?
<cking> kentb, so how's it going?
<kentb> cking, well, macallan with 10.10 server + your kernel and no iommu settings survived 100 s4 cycles
<cking> perhaps I should have asked somewhere else. hold on
<kentb> cking,  ick...just noticed that, too ;)
<mjg59> Hm. You people took the Dell patch that changes the touchpad from basic PS/2 to IMPS/2?
<hallyn> jjohansen: ppa:kernel-ppa/ppa only has natty images.  Where should I point a user for maverick daily builds?  Or should they just use the natty one?
<jjohansen> hallyn: for daily builds just natty
<jjohansen> hallyn: for most recent maverick -proposed kernels
<jjohansen> just check the -proposed update option in software sources
<hallyn> so the natty one will run ok in maverick for a test?
<jjohansen> yeah, I actually use the natty kernel on maverick on a couple machines
<hallyn> awesome, thanks
<apw> mjg59, i think we have something like that in our tree at the moment
<apw> commit f233403def40bee6ae6bd05c6f998a5f820bf106
<apw> Author: Rezwanul Kabir <Rezwanul_Kabir@dell.com>
<apw> Date:   Tue Nov 23 20:15:14 2010 +0000
<apw>     Add support for Intellimouse Mode in ALPS touchpad on Dell E2 series Laptops
<apw>     
<apw>  
<apw> mjg59, that one?  i applied that to natty to to get some coverage on it before deciding if it was safe for older releases
<apw> as everyone expects to get borked boxes on natty anyhow :)
<mjg59> apw: I'm somewhat worried about it. Dell seem to be pushing it hard, but it just turns one broken configuration into another
<mjg59> apw: ie, you get scrolling and tap to click, but now you can't turn them off...
<apw> mjg59, ok that sounds most undesirable 
<apw> mjg59, that doesn't sound very acceptable and pushing back on it sounds appropriate
<mjg59> They're trying to get us to take it as well, but I'm pushing back there
<apw> mjg59, cirtainly taking it in natty does not consitute 'acceptance' here
<apw> the purpose of that is to determine if there is regressions for non-dell h/w
<mjg59> Really need to have support for putting it into absolute mode
<apw> well saying that seems completely appropriate
<mjg59> Ok - just wanted to make sure we didn't end up in a situation where their argument is "Ubuntu's taken it, so it must be fine" :)
<apw> mjg59, definatly i intended the application to natty to be for regression testing on non-dell h/w as we had applied it once before and all hell had broken loose
<apw> (a previous version)
<mjg59> Awesome
<mjg59> I think this one's DMI-limited to Dell?
<apw> mjg59, indeed so, but i got badly burnt on the last iteration so i am suspicious of it
<apw> mjg59, now you mention we cannot turn of click-to-tap i'll make sure someone goes test that
<mjg59> apw: I suspect it simply won't appear as a touchpad to X, so the control panel won't appear
<apw> mjg59, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/632884 ... the intent is loosly worded but in that bug
<ubot2> Launchpad bug 632884 in linux (Ubuntu Maverick) (and 2 other projects) " Add support for Intellimouse Mode in ALPS touchpad on Dell Latitude series Laptops (affects: 1) (heat: 44)" [High,Triaged]
<mjg59> apw: Yeah, I think the upstream answer to that is going to be "no"
<apw> mjg59, heads up ... x86: Make relocatable kernel work with new binutils ... is triggering hard early boot failures for me (v2.6.38-rc1 based kernels)
<mjg59> Yes, we've been hitting that
<apw> mjg59, i don't see it reported on lkml yet, so i guess i'll whine
<ilmari> is the intel-drm-next kernel package built on a regular schedule?
<ilmari> drm-intel-next, even
<apw> ilmari, that is one of the ones which is built when the tree changes, in theory at least
<bjf> smb, isn't there a wiki page which says what in lucid are our "franken" kernel bits?
<apw> kees, you might want to look at this: [REGRESSION] S3 resume on SandyBridge doesn't work with NX protection (5bd5a45)
<ilmari> apw: it seems to have been rebased today, so I guess there should be a new package shortly?
<apw> ilmari, its checked daily at 10am UTC
<apw> so yes i'd expect it to pop out tommorrow in that case
<ilmari> cheers
<apw> kees, thats your NX patches triggering all that :)
<kees> apw: upstream! :)
<kees> apw: I can poke at it, but we'll need upstream to help with it. since it's now in the .28 tree, it shouldn't be too insane.
<apw> well knowing linus it might not be in upstream if it doesn't get fixed and quick
<apw> cking, i note that natty is now reporting dmi information on boot ... not sure when it arrived:
<apw> [    0.000000] DMI 2.6 present.
<apw> [    0.000000] DMI: 3653/HP Mini 5102, BIOS 68PGU Ver. F.05 03/11/2010
<apw> might be useful for the fwts stuff too
<cking> nice
<kees> apw: yeah, true. I'll try to take a look at it, but we might need to dig deeper with it. I don't understand why they did it the way they did.
<apw> cking, were you telling me something about acpi_init performance yesterday
<jjohansen> rebooting
<bjf> apw, git://git.kernel.org/pub/scm/linux/kernel/git/longterm/linux-2.6.35.y.git
<apw> :wq
<apw> grr
 * jjohansen -> lunch
<cking> apw shows off his vi skills
<apw> cking, shows off his "i want apw to call my wife skills"
<cking> dude, I've been offline for last 2 hours - honest!
<vanhoof> apw: can you begin calling my fiance as well?
<vanhoof> she would appreciate it :D
<apw> sure can, where do you want her to kick you ?
<vanhoof> lulz
 * vanhoof makes mental note to not joke like this w/ apw as he'll likely make a call :)
<apw> vanhoof, sure will ... :)
<cking> vanhoof, he will do - that's for sure
<Kano> hi, why is there still no .38 mainline kernel?
<htorque> hello, everyone! are there known issues with 2.6.38-rc1and the ubuntu kernel config? like dying right after grub?
<apw> htorque, thats an upstream error
<apw> htorque, revert "x86: Make relocatable kernel work with new binutils"
<apw> Kano, timing ... it will be built in the next hour or so
<Kano> and it will not work?
<apw> Kano, it is actually possible for you to make your own if you need them that urgently
<apw> rc1 won't boot indeed, its broken
<Kano> ah, is the script available
<Kano> :)
<Kano> would be no problem, my pc is fast enough
<Kano> i just dont like to upload kernel which are unpatched, thats wasted time
<htorque> apw, thanks :-)
<apw> htorque, np
<tgardner> apw, I was able to get that zillion core machine to boot by using maxcpus=0
<apw> tgardner, heh thats a good one and no mistake, tried rebuilding with MAX_CPUS=128 ?
<tgardner> apw, not yet, I had to leave before I could get it built.
<apw> tgardner, doh of course ... i wonder if we should be upping that regardless
<tgardner> apw, I'm gonna research that option to see what side effect it might have. it could be appropriate for a Lucid SRU
<Kano> apw: where is the script used?
<Kano> it could be optimizied too because rc kernels are in front of final kernels
<Kano> you should use ~rc
<sconklin> apw: I had the wrong patch implicated earlier. It's fa7e0b "drm/radeon/kms: properly compute group_size on 6xx/7xx"
<sconklin> http://web.archiveorange.com/archive/v/hhSc5lXjWhzzBSGwGzzM
<smb> bjf, https://wiki.ubuntu.com/Kernel/Dev/KernelDriverDeviations in case you are stll looking
<bjf> smb, thanks
<smb> Though by now, we also got the deviations.txt in the tree itself
<bjf> smb, forgot about that
 * apw notes that v2.6.38-rc1 doesn't boot on any of his 32bit machines ... sigh
#ubuntu-kernel 2011-01-20
<poelzi> ohh man. kms is so broken on my radeon
<apw> poelzi, on what release
<poelzi> apw: 10.10, but i'm running a vanilla kernel. 2.6.36. without kms the desktop is fast, without it's slow like hell
<apw> not heard of that i am afraid, but .36 wasn't a release we tested
<poelzi> 2.6.37 crashed on my 2 times so i booted back into 2.6.36.3 . i have to test if 37 with kms works
<poelzi> both times x died and sysctl key did not work eighter except for reboot
<poelzi> oh man. i just had to write a very dirty workarround because you can't set a pids task group id even as root :-(
<poelzi> now i can't restart ulatencyd without loosing my grouping of processes :-((((
<cooloney> apw: hey, andy, i am trying to fix the linux-tools package breakage for ti-omap4
<apw> cooloney, yep, that was a the bug that there was no way to instlal the linux-tools-foo package for ti-omap4 right?
<cooloney> apw: in debian.ti-omap4/control.stub.in
<cooloney> apw: yeah, exactly.
<apw> cooloney, the tools work fine if you install the linux-tools-foo package right ?
<cooloney> apw: currentlt we got SRCPKGNAME-tools-common and SRCPKGNAME-tools-PKGVER-ABINUM in ti-omap4
<cooloney> apw: oh, i manually install the deb package which is linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb
<cooloney> apw: SRCPKGNAME = linux-ti-omap4 is not linux
<cooloney> apw: so i think i might need to modify that to linux-tools-common and linux-tools-PKGVER-ABINUM
<apw> cooloney, i don't think changing those names will help
<apw> as the issue is there is no way to ask for them whatever their name
<apw> people expect to be able to install linux-tools to get those files for their system
<apw> and those map normally to linux-toolss-XXX
<apw> however the linux-tools for armel points to the ones built out of the armel architecture builds from the master branch
<apw> i think the simplest solution is to add a linux-tools-<flavour> type meta package which points to linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb
<cooloney> right. 
<apw> then at least one can install linux-tools-omap4 and get some tools
<apw> and get updates automatically
<cooloney> apw: you mean the linux-meta package?
<apw> yes in the linux-meta-ti-omap4 package
<apw> i can have a look at it later on if you like
<apw> it should be pretty easy
<cooloney> yeah, i am studying that, but failed find such linux-tools mapping in our natty linux-meta
<cooloney> neither master nor ti-omap4
<cooloney> so i assume it is not a issue about linux-meta
<apw> apw@dm$ cd git2/ubuntu-natty-meta/
<apw> apw@dm$ git grep linux-tools 
<apw> meta-source/debian/changelog:  * Enable linux-tools on armel
<apw> meta-source/debian/changelog:  * Add linux-tools meta package
<apw> meta-source/debian/control.common:Package: linux-tools
<apw> meta-source/debian/control.common:Depends: ${misc:Depends}, linux-tools-${kernel
<apw> cooloney, it is in my linux-meta ...
<cooloney> apw: ah, got it. let me checkout that
<cooloney> is that public?
<apw> cooloney, that is the contents of the public git repo ... that is the source for the meta package
<poelzi> ohh man, having a script language to optimize kernel sheduling is really the best idea of the hole project
<cking> wish I knew what that meant
<poelzi> https://github.com/poelzi/ulatencyd/
<apw> every time someone has tried to implement a core key function partly in userspace it has had severe corner cases issues particularly when there is insufficient cpu to run the userspace scheduler
<poelzi> apw: it is not a scheduler
<poelzi> it is a scheduler optimizer, that is something completly different
<apw> "Ulatency is a daemon that controls how the Linux kernel will spend it's
<apw> resources on the running processes."
<poelzi> yes. 
<apw> where i come from that is the definition of the role of a scheduler
<cooloney> apw: is this one: git://kernel.ubuntu.com/ubuntu/ubuntu-natty-meta.git
<apw> cooloney, that is the one for the master branch yes
<apw> you need to change the one for your branch
<cooloney> apw: thanks a lot, my bad, i always grepping in the ti-omap4 branch
<apw> you need to change the ti-omap4 branch one
<apw> to include a linux-tools-<flavour> package similar to that one
<cooloney> ok, i will try to provide a patch to ti-omap4,
<poelzi> apw: i do not schedule, but i "constantly" optimize the parameters of the kernel scheduler. so, the sentence is true
<cooloney> got it
<cooloney> thx
<apw> poelzi, that makes it a scheduler component, part of the scheduler
<apw> and if it is necessary to run something to change the way things run, you are in a risky spot for corner cases under load
<poelzi> not exactly i would say. the scheduler will never ever wait on the optimizer for a result of some sort. but the optimizer uses the interfaces of the scheduler to adjust him
<poelzi> apw: i do work hard on the corner cases. man i fixed the swap of death with it
<cooloney> apw: need i post the patch back to maverick?
<apw> cooloney, do we really care about maverick for that kernel?
<poelzi> and optimization should never be done in kernel, to much heuristics involved
<cooloney> apw: yeah, some users are still trying to use linux-tools in ti-omap4 maverick, i believe
<apw> cooloney, we have some h/w they can install maverick on somewhere in the world?
<cooloney> apw: sure, Panda board is our Maverick release targeting HW.
<apw> cooloney, well the rules state, update natty then SRU previous releases
<cooloney> apw: got it.
<cooloney> apw: about this?
<cooloney> Package: linux-tools-ti-omap4
<cooloney> Architecture: armel
<cooloney> Section: metapackages
<cooloney> Depends: ${misc:Depends}, linux-ti-omap4-tools-${kernel-abi-version}
<cooloney> Description: Linux kernel versioned Tools This package will always depend on the latest Linux kernel versioned tools available. The Ubuntu patches have been applied.
<cking> apw, gpes + SCI: http://zinc.canonical.com/~cking/presentations/gpes-and-embedded-controller/EmbeddedControllerAndACPI.odp
<apw> cooloney, i suspect its either linux-ti-omap4-tools, or its linux-tools-omap4 (assuming the installed flavour is omap4)
<apw> generally things on the right hand end are flavour names, and things on the left end are source package names
<cooloney> apw: thx, sorry for the delay, i think linux-tools-omap4 is right
<apw> cooloney, i think i do to, then we can consider making that the norm for all flavour
<cooloney> ls
<cooloney> apw: i found the deb file name is linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb 
<cooloney> is that right?
<apw> the name in the binary seems right yes, as its architecture specific for that branch, ie not flavour specific
<apw> but i think the right thing is to make the name flavour specific
<apw> just in case it does become flavour specific
<cooloney> it's supposed to be linux-ti-omap4-tools-2.6.35-1101_armel.deb
<apw> the tools are version specific so the binary name should be linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb
<cooloney> SRCPKGNAME-tools-PKGVER-ABINUM = linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel ?
<apw> yes
<apw> well no, its the first bit, linux-ti-omap4-tools-2.6.35-1101, the bit after the _ is the version of the package from changelog the next bit after _ is the architecture
<apw> in the dev
<apw> so to link to the contents of the deb _filename_ linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb you link to a package called  linux-ti-omap4-tools-2.6.35-1101
<cooloney> oh, yeah, linux-ti-omap4-tools-2.6.35-1101 = linux-ti-omap4-tools-${kernel-abi-version} = SRCPKGNAME-tools-PKGVER-ABINUM
<shadeslayer> could someone look at bug 702341 ?
<ubot2> Launchpad bug 702341 in xserver-xorg-input-synaptics (Ubuntu) "synaptics touchpad does not work (affects: 1) (heat: 416)" [Undecided,New] https://launchpad.net/bugs/702341
<shadeslayer> or would this be a #ubuntu-x issue?
<tgardner> sconklin, I'm gonna re-upload Hardy LUM to see if I can figure out the lpia build failure. It won't rebuild because it was pocket copied from the c-k-t PPA, and the original package has since been deleted.
<sconklin> tgardner: ack
<tgardner> I'll just bump the upload number
<sconklin> tgardner: there's special magic required to upload to the new ppa
<tgardner> Has it changed? I'vev uploaded to c-k-t before
<sconklin> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
<sconklin> bottom of that page
<tgardner> sconklin, yep, I grok that
<sconklin> ok
<sconklin> I think SteveK said that there's another way to do it, but this works
<tgardner> sconklin, yeah, once I have the magic runes correct, I don't really care what they are
<JFo> <- food
<tgardner> sconklin, bjf : did the c-k-t PPA armel build issues get sorted? we need to remember to revert the meta package carnage if so.
<sconklin> tgardner: when we reupload packages tomorrow or monday, the armel builds should complete, then we'll fix the metas
<sconklin> Need a complete LSI-11/2 system? http://huntsville.craigslist.org/zip/2167211100.html
<tgardner> sconklin, bjf : the no-change Hardy LUM upload appears to have built on lpia this time. I guess it was just a transient failure
<bjf> tgardner, good
<cking> apw, http://freeworld.thc.org/root/phun/unmaintain.html
<jjohansen> so sconklin: basically this is bug#683743 and the best way currently is indeed adding a rule to the profile file, the plan is to add a directory where application can drop their own rule bits, that would automatically get included without modifying the profile but its not done yet
<sconklin> ok, thanks. I'll pass that on
<tgardner> sconklin, bjf : Hardy LUM has successfully rebuilt. Who does the security pocket copies ?
<bjf> tgardner, i usually ping kees
<bigon> hi, I'm trying to boot the natty installer (daily build), but it seems that the kernel freeze (back screen just after grub) an idea?
<bigon> booting on a machine with uefi mode
<LetoThe2nd> hello! i have a board here on which ubuntu names all connected usb memories starting with sda, and puts in the sata stuff afterwards from sdf or sdg, depending on how much is connected. is there a way around this?
<LetoThe2nd> (cpu: phenom ii x6, chipset ati sb800
<BenC> There probably is, but the best thing is to not use the dynamic naming...use the uuid device nodes for example
<LetoThe2nd> yeah, but thats more like a workaroung to me...
 * jjohansen -> lunch
<sforshee> smb, you there?
<cking> sforshee, it's probably bit late for smb now
<cking> way past beer time :-)
<sforshee> yeah, i figured, but he's still logged in so I thought I'd check
<bryceh> has anyone packaged 2.6.38-rc1 any place so far?  Intel is demurring about looking at our X bugs unless confirmed against the newest upstream gunk.
<bjf> bryceh, yes, it's been built but last i heard was borked quite badly
<bryceh> bjf, ah ok
<bryceh> I will tell them so
<RAOF> I saw apw complaining that it didn't boot on any of his 32bit machines, at least.
<RAOF> LetoThe2nd: No, a work-around is to try to wrangle a stable naming out of the inherently unstable dynamic naming scheme :)  The UUID *is* the stable naming scheme, so it's what you should use if you need stable naming.
<ohsix> mjg59: what am i looking at if gnome-power-manager tends not to know the backlight level, but it often changes appropriately (showing ui from the hard buttons and stuff)
#ubuntu-kernel 2011-01-21
<apw> bryceh, yep, working on getting a kernel which will boot on 32 and 64 bit at the same time
<apw> cking, this may be of interest to you
<apw> commit d551d81d6a720542873f478def60baab6b5df403
<apw> Author: Rafael J. Wysocki <rjw@sisk.pl>
<apw> Date:   Wed Jan 19 22:27:55 2011 +0100
<apw>     ACPI / PM: Call suspend_nvs_free() earlier during resume
<cking> apw, ta. last night we cornered the bug down to issues in the i915 driver for sure.
<apw> diwic, about ?
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/682617 <-- anything happening on this bug ?
<ubot2> Launchpad bug 682617 in linux "Microphone not working in Optiplex 980" [Critical,Incomplete]
<apw> diwic, it seems that that one is not a kernel issue per-see, perhaps a pulse setup issue ?
<diwic> apw, let me see
<diwic> apw, yeah, I wanted cr3 to confirm that I and he had the same opinion on what was wrong and he never replied back
<diwic> apw, or replied back saying he had more important issues that day
<apw> diwic, would it make sense to move it over to pulseaudio package
<diwic> apw, yes, and would hopefully be fixed with my pulse-mixer patch which should be in Natty given some more testing and review
<diwic> apw, ok, moved to pulseaudio
<apw> diwic, wicked thanks
<apw> cking,     2. powersave (CPU_FREQ_DEFAULT_GOV_POWERSAVE) (NEW)
<apw>  <-- might be of business
<bguthro> dwic, we developed a fix for that same problem...let me see if I can pastebin it somewhere
<bguthro> dwic, take a look here:
<bguthro> http://paste.ubuntu.com/556518/
<bguthro> I don't think my colleague has had an opportunity to submit it upstream yet...
<bguthro> FWIW, this was developed under 10.04
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539467
<ubot2> Launchpad bug 539467 in pm-utils-powersave-policy "SATA link power management causes disk errors and corruption" [Undecided,Fix released]
<smb> sforshee, Morning, btw /me seems to be always around as I got a bip proxy running. Still always worth checking but I could be off :)
<sforshee> smb, I figured you were probably offline, but like you said, always worth checking
<sforshee> pgraner said you've fixed problems with the Huawei modems in the past?
<diwic> bguthro, hmm, I've fixed optiplex 380 a while ago - I think that fix has reached Lucid as well as Maverick and Natty by now, but I'm not completely sure 
<smb> sforshee, I certainly was looking at one or two bug with them. Though usually it was finding stuff upstream. wHY?
<sforshee> smb, does but 565058 look like anything you've dealt with before?
 * smb punches the stupid capslock key
<smb> bug 565058
<ubot2> Launchpad bug 565058 in linux "Lucid: hotplugging Huawei E220 doesn't load 'option' module" [Undecided,Incomplete] https://launchpad.net/bugs/565058
<bguthro> dwic, it's entirely possible. We're working with a somewhat outdated local mirror.
<sforshee> the mode switch happens okay, but the ttyUSB devices don't show up
<sforshee> not sure if udev isn't loading the option module or something else
<smb> sforshee, I think we looked at that briefly in Dallas. Wasn't it the usb id showing up in two drivers or so?
<sforshee> smb, not sure what you mean
<sforshee> the id does match usb_storage and option
<smb> Though reading the description, things do work when manually loading the option driver. Just that autoloading seems to stop with the storage module
<sforshee> but the device class, etc. are different between the two
<sforshee> yeah, I think it's that udev doesn't load the module, but I'm trying to get some more logs to verify that for certain
<sforshee> I do see for sure that udev receives events for the device that should match the option module though
<smb> sforshee, It surely will be interesting to see what events get triggered by udev. So lsusb says we got one device with three interfaces, one of which is generic storage class and the other two probably the modem part.
<smb> So (I am guessing) option probably matches only based on the usb id, while usb-storage matches on the class. 
<sforshee> smb, if you look at the udevadm_monitor.txt attachment, you see the events for the modem interfaces
<sforshee> actually usb_storage matches only on the id and option matches on the class
<smb> ok, have not got that far yeet
<sforshee> alias usb:v12D1p1003d0000dc*dsc*dp*ic*isc*ip* usb_storage
<JFo> iirc there was some issue with them where it wouldn't work if it had storage mounted, but it you unmount that it begins working
<sforshee> alias usb:v12D1p1003d*dc*dsc*dp*icFFiscFFipFF* option
<smb> sforshee, Ah, actually option matches on both
<sforshee> JFo, when it's first plugged in it shows up as a storage device, then udev runs something called usb_modeswitch
<JFo> right
<sforshee> that part is working, but after the modeswitch things are going wrong
<JFo> hmmm
<sforshee> it ought to be able to use all three interfaces that appear after the modeswitch concurrently though
<sforshee> (one of those being a storage device)
<smb> Yeah, one would expect
<sforshee> smb, if you haven't dealt with this situation before I'll just keep working on it
<sforshee> just wanted to make sure there wasn't a known solution
<smb> And as manually loading is said to work there must be something in the udev rules
<sforshee> maybe
<sforshee> I wish udev would output what it actually does in response to an event
<smb> That would be nice
<smb> Actually I think you should look for whether there is indvidual events for the interfaces
<smb> Interface 0 matches up with the storage device
<sforshee> there are events for the interfaces
<sforshee> after the mode switch interfaces 0 and 1 are the modem, and interface 2 is the storage device
<sforshee> smb, the only other interesting thing I see is that usb_modeswitch thinks the mode switch failed
<sforshee> it looks like it's just an error in the logic
<smb> Oh, right, wrong line taken for the interface number
<sforshee> that shouldn't affect udev's response to the events for the modem interfaces, right?
<sforshee> well, the logic error is that it expects to see more modem interfaces after the mode switch than before, but the way it counts both before and after the mode switch is incorrect
<sforshee> it's fixed in later versions
<smb> I would think it should run driver probes for each interface
<sforshee> as long as the option module is loaded
<smb> rigth and that I would hope to be tied to an event that occurs when those interfaces come up
<sforshee> it should be, due to the line in modules.alias
<sforshee> unless another udev rule matches the devices first, I guess
<sforshee> doesn't udev stop after the first match for an event?
<smb> INO, they should all be checked. And every match may add additional things to run or other info
<sforshee> okay, thanks for clarifying, I couldn't remember for sure
<tgardner> apw, CONFIG_NR_CPUS=256 did the trick
<apw> tgardner, awsome ...i'll just apply that to my latest tree
<apw> as i have done an updateconfigs since then, which flavours are we going for?
<tgardner> apw, we likely only need it for server flavours, right?
<smb> sforshee,At least all the interfaces seem to emit events again after (I would think by modeswitch) the go away briefly
<smb> sforshee, But as you say, there is no way to see from this what actions were started
<apw> tgardner, yeah so -generic-pae and -server i guess
<apw> actually perhaps it doesn't make any diff on 32 bit
<tgardner> apw, I'm not sure we want to support that many on generic-pae. I think tahts insane
<smb> sforshee, I wonder whether that could be made visible by changing the loglevel of udev for a moment
<apw> tend to agree.   ok i'll apply it just for amd64 server, how about virtual, you might be mad enough to have a lot of cpus; maybe
<apw> smb, whats the most cpus you can get in ec2 instancs ?
<tgardner> apw, I think we should leave -virtual alone for now until we run into a case where its really needed.
<apw> tgardner, ack, just -server amd64 for now then
<sforshee> smb, any idea how that's done?
<smb> apw, Bonkers, the doc say 20 ec2 compute units (which is 8 virtual cpu with 2.5 ec2 computeunits). Cant they write normal terms?
<apw> heh 8 then, ok
<smb> apw, but I think in essence 8 vcpus
<tgardner> certainly less then 64
<sforshee> smb, I found it, it's in /etc/udev/udev.conf. I'll look to see what kind of things get logged at other levels
<smb> sforshee, There is also a way with udevadm
<smb> sforshee, udevadm control --log-priority=debug
<smb> or back to err
<sforshee> smb, that's even easier, thanks!
<sconklin> https://launchpad.net/ubuntu/+source/linux/2.6.32-28.55/+buildjob/2159614
<smagoun> pgraner: sconklin: Hi, OEM would like to request an SRU verification exception for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/685015 . The patch has already been tested and signed-off by OEM QA in a custom OEM kernel. OEM no longer has access to the specific hardware for testing the patch in -proposed. We think the patch is a very low risk of regression - it affects only a single hardware variant.
<ubot2> Launchpad bug 685015 in linux "[MAVERICK] Thinkpad Edge 13 External headphones/mic not functiona" [Low,Fix committed]
<pgraner> smagoun, dude are we a bit late on this? the deadline was yesterday
<apw> smagoun, where is the custom OEM kernel, it would be good to know how similar to the one that was tested by oem-qa to know how valid that testing is
<vanhoof> apw: its in oem-master
<vanhoof> one sec
<smagoun> pgraner: yup, I realize that. We've been scrambling to try to find access to the hardware, and our last lead ran out yesterday at about 7pm ET. I understand that the upload happens today at 11am ET
<vanhoof> apw: http://kernel.ubuntu.com/git?p=hwe/oem-master.git;a=shortlog;h=refs/tags/oem/kernel/sutton/02
<pgraner> smagoun, yea in 30 min? 
<pgraner> smagoun, I thought we were supposed to have two of everything in OEM QA? 
<smagoun> pgraner: In this case the vendor asked us to return the machines for use in a trade show
<pgraner> smagoun, gotcha, let me talk to the stable team and get the thoughts there
<smagoun> pgraner: thanks, let me know if I can help
<pgraner> smagoun, TBH I hate doing this cuz it sets a precedence, and we can't keep doing things like this
<smagoun> pgraner: I agree, I don't want to do this either. I'm out of options though, and I don't want an ubuntu update to cause a regression on hardware that ships with Ubuntu
<pgraner> smagoun, and have it sustainable
<pgraner> smagoun, ack lemme take the the team on risk and such
<pgraner> smagoun, can you send an email to ubuntu-kernel asking for the exception and we will get the proper acks
<smagoun> pgraner: will do that right now
<pgraner> smagoun, its not totally our decision we recommend and it has to be accepted by the release team make sure you cc: skaet 
<smagoun> ACK
<sconklin> and pitti
<smagoun> pgraner: mail sent to kernel-team cc skaet, pitti, and vanhoof
<pgraner> smagoun, ack thanks
<ilmari> hm, no updated drm-intel-next kernels since 2011-01-13
<apw> JFo, hey
<kamal> I'm looking for AKPM's (Andrew Morton)'s kernel git tree (is it still called the "-mm" tree?).  anyone know where I can find that?
<kamal> oh... http://en.wikipedia.org/wiki/Mm_tree says that the -mm tree is now the linux-next tree, which I can find easily at kernel.org
<apw> jjohansen, about ?
<jjohansen> yep
<apw> kamal, there is no git for it is there?
<apw> jjohansen, you have three patches in our delta whch i am wondering if we still need or not
<jjohansen> apw: shoot?
<apw> UBUNTU: SAUCE: Improve Amazon EBS performance for EC2 (d4cd6a8bb5575a999e3ff8a4c28b79188e4e542a)
<apw> UBUNTU: SAUCE: fix pv-ops for legacy Xen (43a5c4e9edd44daf3beaf563724d1fcd60de242d)
<apw> UBUNTU: SAUCE: blkfront: default to sd devices (fe8b3202017eba2a51c805c6ed1d64e0f24bc47d)
<apw> do we need em?
<apw> i suspect we do
<jjohansen> UBUNTU: SAUCE: Improve Amazon EBS performance for EC2 yes
<jjohansen> give me a sec to check the other ones
<apw> cool then i can close off your task :)
<kamal> apw: there is a git tree for -next :   http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary
<apw> kamal, not sure that represents -mm though
<jjohansen> UBUNTU: SAUCE: fix pv-ops for legacy Xen yes
<sforshee> kamal, apw, http://userweb.kernel.org/~akpm/mmotm/mmotm-readme.txt
<sforshee> maybe this is what you're looking for?
<apw> sforshee, thats my memory of where its at
<jjohansen> apw: hrmm, I thought we reverted fe8b3202017eba2a51c805c6ed1d64e0f24bc47d
<kamal> apw: oh I'm not sure of that either, but the wiki article impled that there just isn't anything called "mm" anymore
<apw> jjohansen, let me check we may have
<jjohansen> I know I tested reverting it and had problems, but smb picked it up
<jjohansen> as I recall reverting it was working for him
<kamal> sforshee: yes, I guess I stumbed upon that also, but that appears to be just a snapshot, and the git tree it points to is bogus
<smb> yes it has
<apw> jjohansen, yes it is dropped already, page out of date
<apw> (page fixed)
<sforshee> kamal, I think maybe all that's provided is a snapshot
<sforshee> iirc akpm maintains -mm as a patch series using quilt or something like that
<apw> sforshee, indeed so, he is not a git-ter
<jjohansen> apw: okay
<apw> jjohansen, the third one looks needed to my eye too, concur ?
<kamal> sforshee: ah, got it.  ok, anyway I think -next is what I'm really looking for.  thanks much!
<jjohansen> apw: yep, its needed.  so two needed 1 reverted
<apw> jjohansen, cool i'll do the admin, and you can forget about that task -> DONE
<jjohansen> apw: actually I thought I had marked it DONE
<jjohansen> apw: maybe I didn't hit save :(
<apw> seems not... somehow, maybe it came back or something as i note its missing from those slipped too
<apw> so its probabally a balls up elsewhere
<apw> sconklin, about ?
<sconklin> apw: yep
<apw> sconklin, you have an open slipped A1 task "document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)" ...
<apw> i seem to remember you had done most of that somewhere along the line?
<sconklin> hmmm. Let me look for the wiki page I made and the spreadsheet it came from. I'm not sure it's complete
<apw> [jjohansen] PV on HVM support (XEN_PCI_PLATFORMDEV) turned on for all, requires testing: INPROGRESS
<apw> jjohansen, is that testing done, is it something smb should be doing?
<jjohansen> apw: done
<apw> jjohansen, ok will close it off for you :)
<jjohansen> gah, I can't even get to it, I keep getting server error
<apw> jjohansen, heh working for me, and now closed :)
<sconklin> apw: here's what I had done https://wiki.canonical.com/KernelTeam/StableSupportMatrix
<apw> sconklin, that looks pretty complete
<sconklin> I'd be happy to have it marked as a completed task
<apw> sconklin, if you added ti-omap4 and marked "patches from TI" i recon that one is closed
<sconklin> ok, which releases?
<apw> natty, and i think maverick
<apw> sconklin, i'll assume you're adding those two lines and write it up and close it
<sconklin> I can check. I am all up in maverick today
<sconklin> apw will do
<apw> sconklin, thanks ... i am glad to find we are not as far back as the items are sayng
<sconklin> yay
<sconklin> another reason to drink
<sconklin> apw: done
<apw> sconklin, great ... two more items down ... *smack*
<sconklin> you're channeling ogasawara
<apw> someone has to :)
<apw> JFo, about?
<apw> [jeremyfoshee] look at arsenal scripts to nag the users:TODO
<apw> you have that one hanging about?
<apw> sconklin/bjf, actually do you already have automation in place for nagging people to validate ?
<apw> (in launchpad bugs; for stable releases)
<apw> sconklin, also, do you know if victor has done any of these, i guess most of it would be output for your consumption:
<apw> [vtuson] HW Cert team - provide a description of what testing they provide, and an idea of the number of hours required to run those:TODO
<apw> [vtuson] to investigate which systems are "common" for cert testing:TODO
<apw> [vtuson] blueprint for cert-team:TODO
<sconklin> apw: yes, we have a nag script done
<apw> sconklin, ok so shall i assign that to bjf or you, as i close it?
<sconklin> don't know about victor's items. we've still been discussing the best platforms to use for test, but I haven't seen written docs that address the work items
<sconklin> assign it to bjf AND close it.
<apw> sconklin, sounds like not done then, hastle time :)
<apw> sconklin, will do
<apw> *smack* one more closed
<apw> sconklin, you have been doing a git bisect haven't you ... recently ... wonder if you are going to document the how of it
<sconklin> apw: it's not obvious by running "git bisect --help"?
<sconklin> well, I suppose that doesn't tell you what to do with the changelog, ets
<apw> well i suspect there is some hoop jumping when config is broken or changelog is ... yeah
<apw> i personally just pull debian* from HEAD each time
<sconklin> ok, I'll document that. Won't touch the config broken case. with a pole.
<apw> but ... perhaps between us we need to document a sane way to make them
<apw> i can add to it when done
<apw> sconklin, we have a task for it, so i'll pencil you in on it
<sconklin> ok
<apw> (its not urgent or anything)
<apw> sconklin, uts i
<sconklin> should be part of newbie training anyway, and is potentially something anyone in the community can do for themselves
<apw> sconklin, its on https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-bug-handling
<apw> sconklin, well you could instruct sforshee-lunch and pass it on to him too :)
<apw> cnd about?
<sconklin> It'll be easy for me to do as I still have the bisect log and all that, and we have an example bug that shows testing. 
<cnd> apw, yep
<apw> [chasedouglas] Investigate input-redirection patches:
<apw> any idea whats going on with that?
<cnd> you can close it out
<cnd> we don't need it for natty
<apw> cnd, excellent thanks
<apw> cnd, gone
 * tgardner --> lunch
<apw> tgardner, i think that it is allocating memory for all possible CPUs, and as we have HOTPLUG_CPU=y that might mean all that you allow:
<apw>  *  If HOTPLUG is enabled, then cpu_possible_mask is forced to have
<apw>  *  all NR_CPUS bits set, otherwise it is just the set of CPUs that
<apw>  *  ACPI reports present at boot.
<apw> tgardner, seems that this line in dmesg tells you how many pages per CPU you are allocating
<apw> [    0.000000] PERCPU: Embedded 30 pages/cpu @ffff880001e00000 s91520 r8192 d23168 u1048576
<apw> (so 30 pages per CPU in my case)
<apw> tgardner, and this line tells you how many 'possible' CPUs you have:
<apw> [    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
<apw> in my case 2 + 0 is how many 'possilble' bits are set
<apw> from tangerine i see this:
<apw> [    0.000000] SMP: Allowing 64 CPUs, 0 hotplug CPUs
<apw> but i think that is the maximum anyhow
<apw> but this is from tyler:
<apw> [    0.000000] SMP: Allowing 24 CPUs, 0 hotplug CPUs
<apw> so that implies, dispite the comments i pasted above, that actually it knows that no more CPUs can come, and its stopped at 24
<tgardner> apw, so, should we reconsider  HOTPLUG_CPU=y for very large machines?
<apw> tgardner, if you read the rest of that, i think its lying when it says HOTPLUG_CPU will make all of them available
<apw> could you check the new machine?
<apw> pm me if you prefer
<apw> the SMP and PERCPU lines from dmesg
<tgardner> apw, actually, tangerine should show the results we need
<apw> tgardner, i thought it has 64 cpus, which is what the thing is set to
<tgardner> or any 64 bit machine for that matter
<apw> therefore its not representative
<apw> tyler there says 24, so i think we are ok
<apw> but i'd like to see your line from the thing with 256 set
<tgardner> I booted a kernel with NR_CPUS=256
<tgardner> ok, gimme a bit
<tgardner> it takes about 5 minutes to boot
<apw> tgardner, as far as i can tell that initla comment is out of date, if you look at prefill_possible_map
<apw> it seems to take some account of HOTPLUG but only to enable 'disabled' processors in your acpi information
<apw> so i think it really bounds out at what holes you have in the mobo
<tgardner> apw, agreed, though it looks like it rounds up to the nearest power of 2. I have a 6 core hyper thread, with 'NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:16 nr_node_ids:1'
<apw> whats the SMP line looks like
<tgardner> apw, actually, I'm mistaken. its a 4 core
<tgardner> SMP: Allowing 16 CPUs, 8 hotplug CPUs
<apw> ok so i thinks you have 16 real cpus int he machine and space for 8 more
<apw> my laptop for instance has 
<apw> [    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:2 nr_node_ids:1
<apw> [    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
<apw> so it would only be wasting room for two dispite NCPUS=64
<tgardner> here is the 4 way server: SMP: Allowing 80 CPUs, 0 hotplug CPUs
<apw> and dispite having HOTPLUG on
<apw> so your bios is reporting 80 cpus!
<apw> and no extra space ...
<apw> so we are golden
 * jjohansen -> lunch
 * smb -> out
<bjf> rtg, https://spreadsheets.google.com/a/canonical.com/ccc?key=0AgFTUDTDyXredE92dFdsVGkxN1FMMWJabS0wZENLRWc&hl=en&ndplr=1#gid=0
<sconklin> https://api.edge.launchpad.net/beta/bugs/cve/2010-3086
<sconklin> https://bugs.launchpad.net/launchpad/+bug/322560
<ubot2> Launchpad bug 322560 in launchpad "Cannot lookup CVEs by name" [Medium,Triaged]
<bjf> sconklin, https://edge.launchpad.net/+apidoc/1.0.html#cves
<bjf> sconklin, that gets you a collection of cves
<bjf> sconklin, https://edge.launchpad.net/+apidoc/1.0.html#cve
<sconklin> yeah, and the data structure reflects what's in that page of cve info
<sconklin> looking at that now
<sivang> hi all
<sivang> I hae a very strange behavior with LG T380 and maverick
<sivang> the keyboard misses keys while I type
<sivang> e.g. as if the keyboard interrupt is being ignored or blocked through the normal operation of the kernel
<sivang> can that be? What would be the way to solve this?
<sivang> http://pastebin.com/PxKdQVh8
<sivang> this is my cpuinfo
<sivang> any lead will bemuchly appreciated
#ubuntu-kernel 2011-01-22
<HandyGandy> How can I disable edid?
<tim> hi, i have some old entries in my dkms configuration and would like to do a cleanup. however it complains, that the original configuration file is missing: http://pastebin.com/6fs8SpuN
<tim> i there any clean way to remove all references to this module?
<Kano> hi, is 38rc2 automatically triggered or not?
<ilmari> apw: still no drm-intel-next build since the 13th. the branch was last updated on the 20th
#ubuntu-kernel 2011-01-23
<psusi> I just got a new sandybridge system and in order to read the cpu temperature I have to manually load the coretemp and pkgtemp modules.  I assume it just needs a new modalias to match my hardware.  can anyone explain to me a bit about how that works so I can try to get it into natty?
<mjg59> There aren't any modaliases for cpu devices
<psusi> how do the modules get loaded then?  I thought they had some kind of modalias that matched dmi or something
<mjg59> They get loaded by you adding them to /etc/modules
<mjg59> Do modinfo coretemp - there's no modalias lines there
<psusi> why not?  k8temp and k10temp do?
<mjg59> Because the AMD machines have a specific PCI device ID associated with the CPU
#ubuntu-kernel 2012-01-16
<balaraja> Hi All, I am trying to debug Ubuntu 10.04 (2.6.32) running inside a VM with KGDB using a serial connection. But when I boot through the kgdb vmlinux its not waiting for remote connection. Any help,plz?!?
<balaraja> I did add the kgdbwait parameter in grub.cfg.
<balaraja> My question is almost similar to this post (http://askubuntu.com/questions/4230/how-to-modify-grub-entry-for-supporting-kgdb-kernel-image). Any help, plz??
<diwic> apw, the fix for bug 825709 seems to have made its way into the precise kernel (see 645e9035 ), how come it is not automatically closed?
<ubot2`> Launchpad bug 825709 in linux "[Asus 1101HA] Choppy sound due to excessive rewinding on Atom chipsets" [Undecided,Fix committed] https://launchpad.net/bugs/825709
<smb> diwic, You suppose apw is around... :)
<apw> smb, oh he is, in spirit at least
<smb> But its only closed when something in the buglink magic would be correct...
<apw> i would guess the change came down as a stable and yours got lost in the process
<diwic> apw, I thought you made some fix which made the stuff that comes down as a stable to be closed as well?
<apw> oh hmm, but then it does have the BugLink in it
<apw>     BugLink: https://bugs.launchpad.net/bugs/825709
<ubot2`> Launchpad bug 825709 in linux "[Asus 1101HA] Choppy sound due to excessive rewinding on Atom chipsets" [Undecided,Fix committed]
<apw> oh bugger, but leann rebased onto it ... and that takes manual updates ...
 * apw will take care of it
<diwic> apw, thanks
<ohsix> diwic: there are cases where a rewind can never complete due to whatever circumstance, are those the same rewinds ratelimited by the patch?
<diwic> ohsix, the patch is about changing the controller driver to report better dma positions
<ohsix> ah
<ohsix> hadn't got to the bottom yet, i've seen problems on my netbook with the default resampler before, resampling 6 channels from a dvd was too expensive, it would eventually kill itself after failing rewinds and using a lot of cpu for a while
<ohsix> i've seen logs from other people with rewinds that don't have any chance of finishing and pulse not killing itself though, it would be nice if pulse could measure that and change the resampler if it happens
<ohsix> i'll investigate a bit closer next time i see it :]
<ohsix> how you inferred that pulse took 8 seconds to wake up will be useful for a problem i've been having for ages too
<ohsix> i hadn't thought to look at it like that
<snadge> wow people talking :)
<snadge> where were you guys the other day when i was building a custom kernel.. never mind.. i figured it out myself, and it turns out bulldozer just sucks (not news)
<snadge> it seems to have higher than average system usage when building source.. approx twice that of a phenom 2 x4
<diwic> ohsix, PulseAudio should detect (IMO) when the sample position drifts too much from the expected one (i e system clock) and give a warning, or something like that
<snadge> i thought i could be clever and specifically optimise for that architecture, but of course it makes no statistical difference
<ohsix> it does already doesn't it? i was just reading them as errors from alsa and presuming the driver reported it, not that there was 5 seconds between the last event :>
<snadge> that is -march=bdver1 .. turning off all intel related options.. hyperthreading etc.. turned off all debugging.. compiled with -fomit-frame-pointer... pretty much makes zero difference
<ohsix> it's weird people are still using poulsbo stuff
<snadge> oh and -Ofast
<snadge> dont worry im not a gentoo user.. its okay, it was just to satisfy my own curiosity ;)
<ohsix> detecting when a rewind will never finish covers a few classes of problems though ... would be nice to have some sort of message pointing out the resampler, but other things can cause it as well
<snadge> also the kernel build documentation doesnt tell you how to update the version string.. it seems the control file or whatever, overrides the version string in the kernel makefile.. what is the "correct" way to change that?
<ohsix> the rewind scenario i'm thinking of settles max rewind and max possible rewind down to a number that won't change "soon", leading to idempotenet volume changes, just a running tally from the cached old values and incrementing something that aborts the rewind and warns the user after it's happened 2000 times or so would work ok
<snadge> also i had to patch out the test in the makefile for .config and include/config or else it errors out and complains that i should run "make mrproper" .. i cant see reference to that in the documentation :/
<ohsix> snadge: typically you don't want to touch EXTRA_VERSION like you would if you were building the kernel from a tarball, since it's part of the package name proper; but the control file does offer you a way to set custom package versions, which can include arbitrary strings
<snadge> right i just wanted my kernel to be very obviously different from a standard ubuntu one.. so that it didnt conflict
<snadge> eg -snadge
<ohsix> also i'm pretty sure apt-build works for the kernel and if you just wanted to build a bulldozer version you could have used it, independent discovery of the uselessness of the thing is always good though
<snadge> but its called 3.2.0-9 even though its a 3.2.1 kernel from git
<diwic> ohsix, the volume changes are also a stupid rewind case. I mean, in most cases that just translates to hw volume changes, so we shouldn't have to rewind in the first place. But that's another story (and slightly off-topic in #ubuntu-kernel anyway!)
<snadge> i was just following https://help.ubuntu.com/community/Kernel/Compile
<snadge> so im assuming when 3.2.0-9 is released.. its going to override or conflict with the one i just built ;)
<ohsix> snadge: the name resolution policy for package versions is pretty understandable, and documented; so you can pick versions for whatever behaviour you desire, or you could just pin your version; there's really nothing stopping you from doing it however you'd like, many different ways
<snadge> i just thought there might be a simple way to do it.. eg "some-script-myversion 3.2.1-snadge"
<snadge> or i just do a simple string replace in the control file?
<snadge> yay freenode ;)
 * diwic thanks apw for updating the ones I forgot to reassign from alsa-driver to linux as well
<apw> diwic, this demonstrates the manual nature of my 'fix' :)
<apw> though i am fixing it for next time round
 * ppisati -> coffe, back in 5mins
<tgardner> apw, interesting thread on linux-wireless list: "calling request_firmware() from module init will not work with recent/future udev versions"
<apw> tgardner, yea
<apw> tgardner, yeah i was copied, came out of the udev stuff i was doing for nbx2
<tgardner> apw, it should be backward compatible when  we start backporting LTS kernels again
<apw> yeah indeed, as we have more features in udev not fewer
<apw> snadge, normally one adds like newpsmouse1 to the end of the version
<apw> so that yours falls between the official versions
<apw> foo1 for after ~foo1 for before the version you are appending to
<cking> yawn
<DBO> so I am getting a crash with the nvidia drivers in precise if I dont start my kernel with iommu=no
<DBO> is there something I can do to avoid this issue (other than disabling the mmu subsystem)?
<DBO> rebuilding the nvidia module with the oeniric kernel works
<DBO> without the need to turn off the iommu
<DBO> so I guess something in the new kernel is not happy with the nvidia driver
#ubuntu-kernel 2012-01-17
<apw> cking, mooin
<cking> apw, hiya
<pgraner> apw, ping
 * ppisati -> back in 10mins
<apw> pgraner, pong
<pgraner> apw, hey just a heads up I'm getting lots of MCEs in the new kernel and my box has locked up twice a few mins after resuming from suspend
<pgraner> apw, I'm traveling today but will debug when I get home
<apw> pgraner, that sounds bad, -9 yes?  drop back to -7 and see if it persists, could always be true
<pgraner> apw, will do, also lots of strange ecryptfs errors now with this kernel as well
<apw> pgraner, cking has the same machine and is having no trouble ... hmm
<cking> very nearly almost the same machine
<pgraner> apw, this is what I get right before it hangs
<pgraner> [ 2097.443535] [Hardware Error]: Machine check events logged
<pgraner> [ 2152.493292] CPU2: Package power limit notification (total events = 2551)
<pgraner> [ 2152.493297] CPU0: Package power limit notification (total events = 2548)
<pgraner> [ 2152.493300] CPU3: Package power limit notification (total events = 2551)
<pgraner> [ 2152.493302] CPU1: Package power limit notification (total events = 2548)
<pgraner> [ 2152.494510] CPU0: Package power limit normal
<pgraner> [ 2152.494514] CPU2: Package power limit normal
<pgraner> [ 2152.494516] CPU3: Package power limit normal
<pgraner> [ 2152.494518] CPU1: Package power limit normal
 * apw is pretty sure there was no ecryptfs changes in the mix between -7 and -9
<pgraner> apw: this is what I get
<pgraner> [ 1697.455029] Valid eCryptfs headers not found in file header region or xattr region
<pgraner> [ 1697.455032] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
<pgraner> apw, just keep your eye out, could be just my crap box
<apw> pgraner, i suspect that is an empty file in your lowerdir, that was hitting rtg too
<apw> probabally caused by all the crashing you are having
 * pgraner nods
<pgraner> apw, well time to take this steaming pile of dung offline for a bit, got a flight to catch
<apw> luck man
<pgraner> apw, thanks later
 * ppisati -> out for lunch
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<kirkland> pgraner: try: find $HOME/.Private -size 0
<kirkland> pgraner: looking for 0-byte files
<kirkland> pgraner: which, ecryptfs considers "invalid" since there are no headers
<kirkland> pgraner: sorry, you need a trailing slash
<kirkland> pgraner: find $HOME/.Private/ -size 0
<tgardner> kirkland, I've a patch in progress with tyhicks to print inode numbers which will make those bogus files easier to find
<kirkland> tgardner: cool
<kirkland> tgardner: pgraner: here's another trick:
<kirkland> ecryptfs-find $(find $HOME/.Private/ -size 0)
<kirkland> that'll show you decrypted (real) filenames of the offenders
<tgardner> kirkland, then you can do 'find $HOME/.Private/ -inum INODE'
<kirkland> tgardner: I have one right now, /home/kirkland/.speech-dispatcher/speechd.sock
<kirkland> no effing clue what that is
<kirkland> so i'm removing it
<tgardner> kirkland, that is generally your only option
<tgardner> kirkland, cking is about to start doing some thorough ecryptfs testing. I expect he'll shake out a few more bugs
<cking> that's my plan :-)
<kirkland> tgardner: cool
<kirkland> cking: awesome, thanks
<cking> tgardner, kirkland, any specific releases to concentrate on?
<tyhicks> kirkland: Are you running precise? Did you have any hard crashes that could have resulted in that zero length file?
<tyhicks> cking: Are you asking about kernel or ecryptfs-utils releases?
<cking> tyhicks, well, I suppose both if necessary
<tgardner> cking, lets start with precise, then work backwards. Lucid definitely needs some love
<cking> ack
<tyhicks> Ah, I was misunderstanding the question. I agree with tgardner.
 * cking has a nice ivybridge multicore box with raid to try this out
<kirkland> tyhicks: I am not running precise yet
<kirkland> tyhicks: still on 11.10
<kirkland> cking: kernel or userspace releases?
<tyhicks> kirkland: Any recent hard crashes?
<kirkland> cking: i agree with tgardner 
<kirkland> tyhicks: nothing in a very long time
<kirkland> tyhicks: however, i shutdown my laptop almost every day now
<cking> kirkland, gonna start with precise userspace + kernel
<kirkland> tyhicks: whereas before, i'd suspend/resume for weeks at a time
<tgardner> kirkland, I think there still exist some inode race bugs in 11.10 that haven't been backported. tyhicks - isn't that correct?
<kirkland> tyhicks: basically, i never used to reboot except for when there was a pending kernel update reboot
<tyhicks> tgardner: Well, I think that the fix is still in -proposed
<kirkland> tyhicks: however, i have a problem that I haven't tracked down, with openvpn, iwlagn, and suspend/resume
<cking> lemme understand the domain first, then I'll write a bunch of tests and put them ultimately in a git repo 
<kirkland> tyhicks: when i suspend my laptop at home, and resume at the office, i get 8 seconds of networking, and then poof -- no more networking until i reboot
<tyhicks> kirkland: Strange. The reason I was asking is because tgardner has had some zero length files pop up recently.
<kirkland> tyhicks: precise?  and he's had hard crashes, presumably?
<kirkland> tyhicks: i reckon i'll bump up to precise in a month or so
<tyhicks> kirkland: There's some uncertainty about when they showed up, but it is something that we need to keep a close eye out for
<kirkland> tyhicks: current job doesn't lend itself to fighting with alpha-quality OS problems on a daily basis ;-)
<tgardner> kirkland, no hard crashes (I think), but I've killed t-bird a time or 2 which is where my 0 length files popped up (in .cache)
<kirkland> tyhicks: tgardner: interestingly, the file I just nuked looked like it was a "socket"
<kirkland> tgardner: maybe keep your eyes out for your 0-byte files, and see if there's a pattern at all around sockets
<kirkland> tgardner: tyhicks: also, it's almost always a cache file that this happens to, in my experience
<kirkland> ie, its rarely a file that i lose sleep over
<tyhicks> We should be passing non-regular files (like sockets) through without touching them. There may have been a regression, though.
 * ogasawara back in 20
<jsalisbury> apw, I noticed you were working on bug 894768  If you have a chance, can you take a look at comment #43 in that bug?  
<ubot2> Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [High,Fix released] https://launchpad.net/bugs/894768
<dannf> ogasawara: anything more i need to provide for #647043, other than eventual testing of proposed updates? wasn't clear to me if i should send a patch w/ my 2.6.35 backport to the list or not
<ogasawara> bug 647043
<ubot2> Launchpad bug 647043 in linux "Dell Studio 1536 Unable to detect USB ports (Maverick)" [Medium,In progress] https://launchpad.net/bugs/647043
<ogasawara> dannf: so it looks like the patches have been cc'd to upstream stable and noted that they should be applied from 2.6.34 onward.  so we should get them though our normal SRU maintenance process.
<dannf> ogasawara: is 2.6.35.y still maintained upstream? 
<ogasawara> dannf: that I'd have to check
<dannf> if so - i probalby need to send them my patches - they won't apply cleanly
<dannf> (file renames)
<apw> jsalisbury, the bug in that code was introduced realtivly soon previous to us seeing it, whether it was there long enough to be in the previous release i don't know off the top of my head
<ogasawara> dannf: if anything, I'd suggest just sending them to the kernel-team mailing list and ask them to be applied as pre-stable
<jsalisbury> apw, thanks for the info.
<apw> i'll add it to my todo to try and figure it out
<jsalisbury> apw, thanks
<smb> dannf, 2.6.35.y looks rather neglected to me
<smb> or abandoned even
<dannf> ogasawara: ok. perhaps i should wait until the corresponding stable updates flow into oneiric/precise trees and then do that for mav/nat? i don't want to cause extra work, and it seems like getting the fix in devel is normal policy
<dannf> smb: yeah - its not a longterm one afaik, and i don't know of anyone who's picked up maintenance
<dannf> s/in devel/in devel before backporting/
<apw> dannf, if they are fixes you are sending in for those others, its almost better to have the fix for everything at once
<apw> so one person can apply them and make sure they are all on at once
<apw> (not that i have a clue what they fix :)
<ogasawara> dannf: +1 to what apw just said
<dannf> ok
<dannf> usb-doesn't-work-at-all on some laptops
<dannf> is what it fixes
<ogasawara> dannf: I'll go ahead and just pick the patches for Precise right now (hoping they cherry-pick cleanly)
<apw> bah why would we want that for :)
<dannf> ogasawara: yeah, they do - should all the way back to natty
<dannf> ogasawara: thanks
<ogasawara> dannf: for Oneiric and earlier we'll need a proper SRU (ie patches sent to mailing list, 2 Ack's, etc)
<dannf> ogasawara: ok.
 * ogasawara runs to make coffee before meeting
<cking> apw, http://download.intel.com/technology/computing/vptech/Intel%28r%29_VT_for_Direct_IO.pdf
<bjf> -meeting
<ogra_> ppisati, hummm ... did you see the mail from ndec about basing the omap4 kernel for precise on 3.3 instead of 3.2 ?
<ogra_> ppisati, i have no idea if thats doable for you guys wrt maintining it, could you answer the thread ?
<ppisati> ogra_: saw the email, and and we are discussing what to do
<ogra_> great
<ppisati> ogra_: my gut feeling is that, if we can we are gonna stay with 3.2
<ogra_> take your time, we can bring it up in the friday call 
<ogra_> so dont make a rushed decision, i will defend whatever the kernel team decides here :)
<ppisati> if it's not mandatory to have hw accelerated video decoding and the new X stuff (that, anyway, will still require some PPA components), we are going to stay with 3.2 for P and suggest people to install Q kernel if they need these new features
<ogra_> well, its mandatory to have working GLES
<ppisati> does it work now?
<ogra_> we had releases without multimedia stuff before, but never had one where GLES was broken
<ogra_> so as long as the latter works i'm fine ...
<ogra_> there is a lot of work going on to make unity (3D) work in precise, so the GLES bits are kind of essential :)
<ppisati> ok, but since it's arm hw we can tell people to switch to unity 2d and no one can complaing so much about it
<ppisati> anywa
<ppisati> y
<ppisati> how do i check about this GLES stuff?
<ogra_> that would mean 2 years of wasted work on porting unity to GLES 
<ogra_> i dont think thats acceptable 
<ppisati> ok, but Linaro is holding to 3.1 since some multimedia stuff is broken in 3.2
<ppisati> and some pieces won't be ready for P anyway
<ogra_> right, as i say, multimedia is fine to not have 
<ppisati> so, either way, we are going to ship a "broken" product
<ogra_> graphics support is essential to have 
<ppisati> but when you say graphic support
<ppisati> what you mean?
<ppisati> a working X?
<ogra_> the prob is what will TI do wrt making GLES still work on 3.2 if they skip it
<ogra_> a working accelerated X, yes
<ppisati> well, X works with the actual P kernels
<ogra_> framebuffer or accelerated ? what did you test :P 
<ogra_> (i.e. did you install the dkms PVR drivers ?)
<ppisati> nope
<ogra_> right
<ppisati> that is not avai;lable
<ogra_> it is, if you click the icon on the desktop they get installed 
<ppisati> let me try
<ogra_> (the TI icon i mean ... that code might currently be broken though but will be fixed before A2)
<ppisati> can't i apt-get $something?
<ogra_> it installs the DKMS based PVR driver from the TI PPA ... this part is supposed to mive to restricted soon 
<ogra_> *move
<ogra_> did it not work ?
<ppisati> so, does the icon work right now?
<ogra_> i have no idea, but it definitely will for A2
<ogra_> aqnd thats not the point 
<ogra_> we always shipped with GLES support threough this icon, in precise that will be handled a bit differently but this shouldnt be your headdache, what we need to make sure is that GLES works in the final release
<ppisati> ok
<ppisati> so GLES is mandatory, got it
<ogra_> we can live without fullHD video playback imho
<ogra_> so multimedia isnt actually mandatory ... we had that in the past 
<ppisati> icon doesn't work
<ppisati> let me install via PPA
<ogra_> right, thats what the icon does
<ogra_> (as i said, the driver stuff will move to restricted and be handled by jockey for final release)
<ogra_> (so there wont be an icon anymore but he "additinal hw drivers are availabel" dialog instead)
<ppisati> pvr-omap4-dkms?
<ogra_> they currently should work if you manually install them, linaro develops the unity fixes based on that 
<ogra_> just install the metapackage 
<ogra_> ubuntu-omap4-extras-graphics or so 
<ogra_> but as i said, linaro uses that driver daily so it should currently work 
<ppisati> nope
<ogra_> if it doesnt we have to fix it before final release
<ppisati> they use it on 3.1 i guess
<ogra_> but even that doesnt matter 
<ogra_> we have rto have it *by release date* ... working with teh kernel we ship then ....  thats the point 
<ppisati> but it
<ppisati> 's impossible even if we move to 3.3
<ppisati> because some components won't be ready
<ppisati> so, in both directions, we are screwed
<ogra_> i dont know, the mail only talks about multimedia (codecs and syslink etc)
<ogra_> that doesnt touch GLES at all
<ppisati> ok, so first le't gather some info about this GLES dkms
<ogra_> i dont think anything changed about it since the 2.x.x days 
<ogra_> and it should just work even with the current kernel we have in the archive
<ppisati> they said syslink is broken in 3.2
<ppisati> dunoo if it's a dependency
<ogra_> yes, syslink is for video playback 
<ogra_> nothing to do with 3D support
<ogra_> lets discuss it at the call wheer ndec can give input
<ppisati> agrred
<ppisati> *e
<ogra_> I#m pretty sure syslink and GLES are independent 
<ppisati> i hope they are
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Jan 24, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<ppisati> uhm
<rsalveti> ppisati: sgx and syslink are quite independent 
<rsalveti> ppisati: and it's a lot easier to enable sgx
<rsalveti> because it's out of the tree
<rsalveti> and something the ti lt will work on anyway 
<ogasawara> dannf: for bug 647043, I assume you have hw to test with?  If so, what arch?  I wanted to have you install a Precise test kernel before I push the patches to the main repo.
<ubot2> Launchpad bug 647043 in linux "Dell Studio 1536 Unable to detect USB ports (Maverick)" [Medium,In progress] https://launchpad.net/bugs/647043
<dannf> ogasawara: i386, pae
<ogasawara> dannf: ack, thanks
<ogasawara> dannf: test kernel -> http://people.canonical.com/~ogasawara/lp647043/i386/
<ogasawara> dannf: I'll post a comment to the bug with the same info, if you could respond with your feedback there that would be great
<dannf> ogasawara: absolutely, thanks!
<tjaalton> does precise not have aufs? sbuild seems unhappy
<tjaalton> ok so overlayfs seems to have replaced it
<geri> ji
<geri> hi
<geri> how can i recompile the kernel usb driver and manually load it with modeprobe? is that possible?
<ohsix> usb is many drivers, if you mean usbcore no
<geri> i patched the usb driver and dont want to always recompile and install the kernel
<ohsix> what did you patch it for? it's possible to get ubuntu to include it, or the upstream kernel
<LetoThe2nd> geri: let me introduce you.
<geri> i modified drivers/usb/class/cdc-acm.c
<LetoThe2nd> ohsix: we've seen the ticket for some days in #ubuntu-de. its a kind of queue modification patch to cdc-acm.c to quirk some ti msp430 dev kit.
<ohsix> that driver is a module already isn't it? you can write your own dkms thing but i don't know what the rules are for overriding existing modules
<geri> i successfully tested the patch but i dont want to always rebuild and install the kernel....
<LetoThe2nd> ohsix: he patches the kernel source directly and wants to only rebuild the particular module, as the bottom line,
<geri> if there is some way to manually build the usb driver and manually load it with modprobe...would be helpful
<LetoThe2nd> geri: its not "the usb driver"
<LetoThe2nd> geri: for clarity, please refer to it as cdc-acm
<geri> ok
<ohsix> it's a usb class driver, kernel.org and ubuntu would probably be receptive into adding it
<ohsix> what's the nature of the failure when it's not present? what kind of quirk is it?
<LetoThe2nd> ohsix: they certainly won't, because it breaks blocking of incoming characters.
<ohsix> so you need a quitk for the _class_ not the actual device
<LetoThe2nd> geri: BTW, here a link to dkms as he mentioned: https://help.ubuntu.com/community/DKMS
<geri> whats the goal now?
<LetoThe2nd> geri: i'd suggest reading that page.
<geri> thats the only way to succeed?
<LetoThe2nd> geri: from an architectural way, it looks very good to me.
<geri> which kernel source should i use?
<geri> kernel.org?
<LetoThe2nd> geri: read the link, find out and be surprised :)
<LetoThe2nd> ohsix: found the link (post #6): http://groups.google.com/group/ti-launchpad/browse_frm/thread/e414bf066fbd1d59/1dacabc8a4f00ab6?pli=1
<LetoThe2nd> ohsix: i don'T you want that in production code ;)
<ohsix> there's a git tree for all the ubuntu kernel versions, you'd get cdc-acm from there and build your own version
<LetoThe2nd> s/don'T/don't think/
<ohsix> yea that doesn't look like a "fix"
<geri> no?
<ohsix> it's a semantics change since the driver or device is fruity
<ohsix> yea, by fix i mean it probably wouldn't be accepted as-is
<LetoThe2nd> ohsix: thats why i said "quirk something". i personally believe its snakeoil anyway, or that it merely curing the symptoms of something completely different.
<LetoThe2nd> .. like a b0rken tty hardware peropheral or something.
<geri> LetoThe2nd, where is this awesome-20091211-v1.1.tgz. ?
<ohsix> yea, someone hitting the datasheets can probably find a way to reset the device or something in a way that it works correctly
<LetoThe2nd> geri: think a bit about it, and maybe you'll come to the conclusion that there could also be printed $superawesomecodeexamplethingthatdoesntevenexist.08154711.tar.gz
<SpamapS> I just upgraded my MBA 4,1 (11") to precise and the touchpad doesn't seem to work at all...
<SpamapS> also the keyboard seems to be flaky.. sometimes its stops accepting keystrokes for a while (took me 3 tries to type ths message)
<slangasek> bjf: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html seems to have broken again?
<bjf> sigh
<bjf> slangasek: looking into it
<slangasek> cheers ):
<slangasek> :)
<bryce> hey, anyone remember if there's a tool for changing the framebuffer resolution at run time (assuming X is not running)?
<SpamapS> yeah, something definitely broken with the precise kernel.. had to roll back to my oneiric kernel to make the system usable again. :-/
 * SpamapS will try upstream kernel shortly
#ubuntu-kernel 2012-01-18
<sconklin> sforshee: you around?
<Gerald> hi
<Gerald> ohsix, are u here?
<smb> morning
<Kano> hi apw , why is CONFIG_INTEL_IOMMU_DEFAULT_ON=y on by default? the option before renaming was NEVER on by default
<Kano> DMAR_DEFAULT_ON was definitely always off
<Kano> same option, just renamed
<apw> policy got applied to new options so it moved on
<Kano> but is is no new option
<apw> renamed items look like new options
<Kano> on one system i have to use intel_iommu=off in order to boot with nv card
<Kano> because of that new default
<apw> yep there are a few systems with problems as a result
<Kano> funnly phoronix mentioned that as regression in 3.2 kernel
<Kano> but it was caused just by that config change
<apw> yeah well well all know how phoronix strive for accuracy
<cking> 'cos phoronix knows best â¢
<Kano> most likely it never worked
<Kano> on those systems
<apw> yep most likely those systems are broken
<apw> we have all sorts of issues with iommus right now, and all sorts of issues with rc6, in some cases related
<cking> still unsure if rc6 + iommu are totally the root cause for some rc6 failures
<Kano> did you see a solution for rt2800pci problems with 3.2?
<apw> unless you enable things in devel you don't find out why they might be off, and what needs fixing
<Kano> i googled but did not found anything
<cking> it's hard to substantiate facts when facts are rumours
<apw> perhaps we should check on wikipedia [irony]
<cking> LOL
<apw> Kano, anyhow, i see what you are saying about the rename, and will discuss it with leann
<Kano> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=d3f138106b4b40640dc667f0222fd9f137387b32
<_ruben> gotta love all them tweets about kids not being able to do their homework due to wikipedia
<Kano> _ruben: it is not offline, just disable java script on that page
<Kano> it also works when you disable css
<Kano> thats a block for noobs
<_ruben> i hardly use wp myself .. so couldnt care less really :)
<brendand> that's hardly making a stand
<ppisati> brb
<apw> brendand, i'd say its blatant self-advertisment
<ogra_> and its the english page only apparently
<ogra_> who speaks that anyway 
<ogra_> :P
<apw> ahh perfect i can redirect all my wp needs via ogra_ 
<ogra_> only if you also read the pages in german ... i get it as soon as i click on the english version
<apw> i am using you as translator, you read .de and type it in here for me, purfec
<ogra_> haha
<brendand> you can also just press ESC before the message flashes up. does the same trick as disabling javascript
<pgraner> apw, ping
<apw> pgraner, pong
<pgraner> apw, so the -9 is broke on my box, after every suspend I lock up within seconds
<pgraner> apw, -8 works fine
<apw> pgraner, which 8 have you got?  14 or 15 ?
<apw> someone else was mentioning 8s after resume before they hung, hmmm
<pgraner> apw, pgraner@x220:~$ uname -a
<pgraner> Linux x220 3.2.0-8-generic #15-Ubuntu SMP Wed Jan 11 13:57:44 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<apw> 15 then
<apw> pgraner, can you test the 3.2.1 mainline kernel and see if that exhibits the same behaviour ... -9 pulled in .1
<apw> not that i can see anything either way whch would make this occur, hrm
<pgraner> apw, will do need to send a few emails first
<pgraner> apw, does this help, this is the what happened during the resume
<pgraner> http://pastebin.ubuntu.com/808528/
<apw> pgraner, thats just a slower resume, just over the 10s boundary, so probabally not related
<apw> you have that disk thats as slow as snot i think
<pgraner> apw, is an Intel SSD
<apw> pgraner, as slow as snot when resuming
<cking> but for some reason we get an -EBUSY on the reset, which is peculiar
<apw> cking, didn't you mention ^^
<cking> apw, there were a bunch of issues, including a 3 second delay on that touch screen thingy too
<apw> yeah, so just hitting the 10s warnign isn't supprising
<pgraner> apw, I rmmod the touch driver and reinsert via pm-utils
<cking> pgraner, did you try the "ahci.ignore_sss=1" tweak?
<pgraner> cking, not yet, I'm battling two issues, this suspend resume hang and the slow ssd, any suggestions on which should go first?
<cking> ah, I missed the earlier comment that S3 resume now fails :-(
<cking> pgraner, well I'd sanity check you box with a few S3 tests with a previously known good kernel to see if its a kernel issue first
<pgraner> cking, you mean the fwts tests?
<cking> pgraner, just do your normal suspend/resume a coupla times with a previous kernel - if that fails we know it's not necessarily a kernel update issue
<pgraner> cking, I've done that with the -8 kernel and it works fine
<cking> lemme see if I can reproduce on my X220i
<cking> working fine with 3.2.0-9-generic #16-Ubuntu SMP Fri Jan 13 20:46:38 UTC 2011 x86_64...
 * apw boggles
<cking> pgraner, does it behave differently when running on AC or battery?
<pgraner> cking, don't know I'll check that 
<apw> well this isn't very damn helpful: MARC is participating in SOPA Blackout Day. marc.info and lists.kde.org will be dark from midnight US/Eastern January 18th, 2012, until midnight US/Pacific the following day.
<apw> so one cannot look at mail list archives today either ...
<apw> all they are doing is pissing me off, and well, frankly, i have no say
<egon> CALL SENATORS
 * apw has no senators, well other than the car and those don't respond to calling
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917211 <-- smb do you have the h/w to test that ?
<ubot2> Launchpad bug 917211 in linux "Xen + nouveau + modeset = corrupted console" [Undecided,Confirmed]
<egon> I like what torbit has done.. popup that you can dismiss
<smb> apw, by reinstallting my build box maybe... 
<smb> apw, It has at least a nvidia card in...
<apw> smb, bah thats more effort than i wanted expended
<smb> apw, Also what is this. using pci passthrough to have the card in the guest... Probably in the bug... should have a look
<apw> yeah ... difficult to say
<jsalisbury> smb, apw, Is there someone familiar with lxc containers: bug 917660
<ubot2> Launchpad bug 917660 in linux "Installing qemu-user-static on an i386 lxc container will hose your amd64 host" [Medium,Confirmed] https://launchpad.net/bugs/917660
<apw> jsalisbury, it is unclear to me that that is a kernel issue
<smb> Feels like another problem comming from lxc not being a real vm
<apw> jsalisbury, it feels like the container is not correctly 'closed' and the contents are escaping
<smb> If you access proc / sys or what you look at the host ones
<jsalisbury> apw, smb, could be a qemu issue: qemu: uncaught target signal 11 (Segmentation fault) - core dumped
<apw> whether its possible to make it closed or not i am unsure, but i think i'd add a task to lxc for this
<jsalisbury> apw, will do
<apw> jsalisbury, i think the complaint is that the request to use qemu for binaries has leaked out into the host
<jsalisbury> apw, hmm. leaks don't sound good
<smb> Not sure how the binfmts are updated. Maybe another syscall the containter needs to prevent..?
<apw> jsalisbury, the kernel does not have a container mechanism, they are faking things by using 100 different bits of protection ... but ... its never been intended for this use so it doesn't work well
 * smb tries asking on #server
<apw> smb, via /proc, which i am sure is not containerised, it may be possible to remove it though in the container
<smb> Hm, think hallyn is not around yet
 * apw hasn't seen hallyn for days
<smb> right, though that probably completely fails install then
<smb> proc is not ocntainerized afaik
<smb> apw, he was on the kernel-team meeting yesteraay
<smb> but I think it is too early on that side of the world
<apw> smb, then he is hiding from me
<apw> swine
<tgardner> apw, did you tell me I don't have to update CVE tracker states? IIRC you said the shank bot (or its equivalent) will get them set to the right state automatically based on git repo contents ?
<apw> tgardner, tracker or bug states ?  but in the main both are handled from the trees yes
<tgardner> apw, bug states, e.g., fix committed
<apw> tgardner, there is hourly updates of the tracker from the repo contents, and daily updates of the bugs when jjohansen does his processing
<apw> tgardner, so yes if you don't fix commit things that will get handled later by jjohansen's scripting
<tgardner> apw, cool
<tgardner> automation is king
<smb> darn handy
<apw> avoids me making 100s of errors
 * ogasawara back in 20
<jsalisbury> ogasawara, Figured I'd send a heads up.  Lots of duplicates of bug 917962 this morning.
<ubot2> Launchpad bug 917962 in linux "BUG: scheduling while atomic: swapper/3/0/0x10000100" [High,Confirmed] https://launchpad.net/bugs/917962
<ogasawara> jsalisbury: you been able to skim through them and determine if it's a recent regression?
<jsalisbury> ogasawara, It appears they are all with 3.2.0-9 and they all were reported today.
<ogasawara> jsalisbury: would also be good to know if it's easily reproducible
<ogasawara> jsalisbury: didn't apport kerneloops get turned back on recently?
<jsalisbury> ogasawara, One reporter says it happens every three minutes.
<jsalisbury> ogasawara, I don't think so.  I asked for it to be turned on, but kerneloops.org is still down.
<ogasawara> jsalisbury: I though bdmurray mentioned he could disable sending it on to kerneloops but still get the reports filed in lp
<ogasawara> jsalisbury: regardless, might be good to work with the reporter who triggers it every 3 minutes to narrow down the window of regression
<jsalisbury> ogasawara, Ahh, right, he did mention that.  I think he commented out that code in apport.
<jsalisbury> ogasawara, will do.  I'll work on getting the version it was introduced then bisect.
<bdmurray> jsalisbury, ogasawara: yes apport and kerneloops have both been uploaded
<bdmurray> jsalisbury: that'd be a good bug to write a pattern for ;-)
<jsalisbury> bdmurray, yes indeed.  I'll write one up for this.
<apw> ogasawara, there?  i want to push up an overlayfs update, that ok ?
<ogasawara> apw: yep go for it.
<ogasawara> apw: also saw your conversation this morning about iommu configs, I've got them fixed up and pending some testing from bug reporters before I push them.
<apw> as in copying the pre-rename values forward ?
<ogasawara> apw: yep
<ogasawara> apw: which results in INTEL_IOMMU_DEFAULT_ON to be disabled and will likely resolve a lot of the iommu bugs we're seeing
<apw> yeah
<apw> ogasawara, sounds good to me
<ogasawara> apw: for anyone who really wants it enabled, they can boot with "intel_iommu=on"
<ogasawara> apw: I just want to get confirmation on some of the bugs first so I can shove the BugLinks in the commit
<apw> very reasonable
<doctormon> I'm trying to trace a critical bug in 12.04 kernel, but I admit I'm not very good at kernel stuff. Can someone give me a walk through?
<apw> doctormon, some background would help
<apw> ogasawara, oh did i mention the new script for adding teh 'rebased to' in the changelog which also finds any LP references?
<ogasawara> apw: no, what's it called?
<apw> debian/scripts/misc/insert-mainline-changes
<apw> which makes sure we detect and close bugs which come back from upstream
<ogasawara> apw: nice, I'll have to use it after the next rebase
<doctormon> apw: An error in the kernel is causing the pci bus to fail, this causes the video to fail on any driver (vga/nouvou/nvidia) and a black screen to apear.
<doctormon> Sorry for the delay, meeting :-)
<apw> and we know its the pci bug how ?
<apw> pci bus
<apw> doctormon, and is there a bug open for this behavior
<SpamapS> So, I'm on the upstream kernel (3.2.1-030201) on precise, and bcmwl doesn't seem to be working
<apw> SpamapS, have you installed the headers?  so that the modules get built ?
<SpamapS> apw: indeed, if I dpkg-reconfigure bcmwl-kernel-source the module is built
<apw> and how does it fail ?
<apw> oh i bet it fails to laod
<SpamapS> -rw-r--r-- 1 root root 3155008 Jan 18 09:39 /lib/modules/3.2.1-030201-generic/updates/dkms/wl.ko
<apw> if you modprobe wl, what happens, what do you get in dmesg ?
<SpamapS> wl                   2568210  4294967295 [permanent]
<SpamapS> [    8.586967] wl: module license 'MIXED/Proprietary' taints kernel.
<apw> ahh so that says, you build wl with the wrong compiler
<apw> wh
<apw> which is true, as we don't build in precise
<apw> so i am not supprised it doesn't work
<SpamapS> wasn't this supposed to be open sourced / upstreamed at some point like.. a year ago?
<apw> we really don't expect you to be using kernels in tis way
<apw> yep they are working on it, there is brcmsmac now which works for my cards
<apw> what device do you have ?
<SpamapS> 02:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n (rev 01)
<SpamapS> mac book air 4,1
<apw> heh mac, you lose ;)
 * SpamapS melts like the witch doused with water
<apw> why the heck are you using an upstream kernel anyhow?
<SpamapS> Because the precise kernel is unusable for me on this one
<apw> why so?
<SpamapS> keyboard cuts in and out, touchpad does not work
<apw> and 3.2.1 works ?
<SpamapS> Figured I'd try 3.2.1 before going into bug filing mode
<apw> tgardner-afk, isn't that one of the ones you have ?
<apw> ENOseth
<apw> SpamapS, ok to build wl right you need to make a lucid chroot and install the dkms package in there
<apw> let it build the modules, and use the result
<apw> (all very painful)
<SpamapS> oh *awesome*
<apw> they arn't meant for anthying other than a quick test
<apw> and well binary stuff is always a HUGE pain in the ass, and this is just one example
<SpamapS> ok, well in this case, my quick test is, whatever is wrong with the keyboard and touchpad in the precise kernel is fixed in the upstream kernel
<apw> this is why one should not buy machines which need binary stuff ever
<apw> you don't need wireless to test that
<SpamapS> apw: I failed .. the shiny... it sparklezzzz
<apw> magpie
 * apw suggests the ethernet socket :)
<SpamapS> apw: so should I make sure to report the bug or just hope that whatever these fixes are will land in the next precise kernel?
<apw> i'd file something, we won't notice if its on a mac and not one of the 4 we bought
<apw> SpamapS, specially as we're now onto stable kernel updates so much less will get fixed without action
<SpamapS> apw: alright, will do... hopefully I can coax the keyboard enough to get a decent report typed in. :-P
<apw> SpamapS, and go figure out the latest ernel which did work, as i assume it worked in O
<apw> they are all in the launchpad librarian for your enjoyment
 * SpamapS looks around for the SpamapS-bisect tool that will automatically reboot his machine with each version since 3.0.0-12
<doctormon> apw: Because going into the root shell mode, lspci shows all the bus ids to be 0000, which is unlikely to happen.
<doctormon> I've dug up an older bug report
<apw> doctormon, and which kernel is exhibiting this behaviour
<doctormon> https://bugs.launchpad.net/bugs/661248
<ubot2> Launchpad bug 661248 in nvidia-graphics-drivers "PCI Race Condition with COMPAL FL90" [High,Incomplete]
<doctormon> Linux delen 3.2.0-9-generic #16-Ubuntu SMP Fri Jan 13 22:16:32 UTC 2012 i686 i686 i386 GNU/Linux
<apw> ogasawara, what was the symptoms of that MMCONFIG change that you just applied ?
<ogasawara> apw: frequent system hangs/pauses and repeated spewing of error messages to dmesg
<apw> doctormon, and is that the old report or your bug ?
<ogasawara> apw: bah, I take that back, /me confused my bugs
<ogasawara> apw:  the MMCONFIG one is busted usb ports
<doctormon> apw: it's an old report, and my bug
<apw> doctormon, when did this issue appear for you
<doctormon> want a new one?
<apw> i want a bug report from the machine with the issue when it has the issue yes
<doctormon> Kernel 2.6.35, Maverick
<apw> so it last worked in maverick ?
<doctormon> apw: No it first appeared in maverick, it work in 2.6.32 lucid.
<doctormon> worked*
<apw> ok so do file a bug from the machine when running precise if you can
<apw> as thats a valid update L -> P
<doctormon> apw: When it's working or when it's failed? I presume failed.
<apw> if you can when its failed indeed
<apw> as the pci stuff will be right then
<doctormon> OK, command line bug tool, that doesn't need a browser right?
<doctormon> Why do I get the feeling I might have to do this manually...
<apw> if it can work then also get a dmesg froma working boot and an lscpi)
<apw> well if it can work sometimes you could make the bug in a working moment (and say so)
<apw> and add the two files above from the broken one manually
<apw> as in if precise will work sometimes
<amitk> apw: any of you showing up for ELC in ~1month?
<apw> unsure as yet
<doctormon> apw: thanks for your help
<apw> cking, do we have AGP on arm, i assume not ?
<cking> apw, not to my knowledge
<apw> cking, config seems to agree, good, thanks
<cking> sanity exists
 * tgardner --> lunch
<doctormon> apw: Bad news, I went to collect the dmesg/lspci, the recover mode doesn't boot
<doctormon> Stops just after doing ACPI, a message that says to use "pci=usr_crs" which I will try a few times.
<thomi> Hi - Can anyone help give me an update on lp:901386 ? It's turned my brand new laptop into an unusable brick, which isn't so good for work productivity ;)
<hallyn> apw: what's the process you followed to get your kernel.org account back?  did you jsut send an email to hpa?
<BenC> thomi: running alpha releases isn't so good for work productivity either :)
<BenC> thomi: if it's too much of an issue, I see there are plenty of working alternatives until it gets fixed
<hallyn> hm, guess i'll try following this old email's instructions
<thomi> BenC: none of the alternatives seem to work for me (I assume you're referring to acpi=off or intel_iommu=off). Because of that, is it worth filing a new bug?
<BenC> No, I mean running a 3.1 kernel (e.g. not running precise, but oneiric)
<BenC> Or use nouveau(sp?)
<thomi> ahh ok.
<thomi> Thanks
<apw> hallyn, yeah i followed the original email from hpa
<hallyn> cool, thanks.  lessee what kind of response i get, if that' still the procedure :)
#ubuntu-kernel 2012-01-19
<apw> sconklin, i have just fiddled with your jenkins XML doc adding some information on using python unittest
<apw> sconklin, which i believe is commonly used in this context from the results produced by other tests
<tgardner> jsalisbury, are you gonna start a bisect on bug #917962 ?
<ubot2> Launchpad bug 917962 in linux "BUG: scheduling while atomic: swapper/3/0/0x10000100" [High,Confirmed] https://launchpad.net/bugs/917962
 * ogasawara changes locations.  back in 20.
 * tgardner is rebooting tangerine at the top of the hour for a kernel update
<jsalisbury> tgardner, yes, I will bisect bug 917962
<ubot2> Launchpad bug 917962 in linux "BUG: scheduling while atomic: swapper/3/0/0x10000100" [High,Confirmed] https://launchpad.net/bugs/917962
<ogasawara> tgardner: I'm gonna prep an upload, anything else you want shoved in?
<tgardner> ogasawara, nothing leaps to mind
<tgardner> oh, forgot to reboot tangwerine
 * ogasawara makes sure to use gomeisa
<ogasawara> tgardner: I might be off the grid by the time the upload finishes.  It's an ABI bumper, could you or apw do the linux-meta upload tomorrow for me?
<tgardner> ogasawara, no problem. drop Andy a note since he'll be on earlier then me.
<ogasawara> tgardner: ack
<tgardner> ogasawara, I'm updating your chroots on gomeisa. they should be done in a couple minutes
<ogasawara> tgardner: ok thanks
<jsalisbury> ogasawara, tgardner, is it OK to build test kernels on tyler?
<tgardner> jsalisbury, sure
<jsalisbury> tgardner, cool, just wanted to check.
<tgardner> ogasawara, gomeisa updated
<ogasawara> tgardner: cool, thanks
 * ogasawara kicks off test builds
<pgraner> apw, ping
<tgardner> pgraner, apw is out until tomorrow
<tgardner> sforshee, did you get the DSDT table?
<sforshee> tgardner, yes, thanks. Haven't gotten around to looking at it yet.
<tgardner> sforshee, np
<tgardner> smb, nice write up: https://wiki.ubuntu.com/Kernel/Reference/Orchestra
<smb> tgardner, Thanks, hoped it could be helpful and actually remind me as I tend to forget. :)
<bjf> smb, i'm working on orchestra+koan+jenkins and will add to your doc. very nice start
<tgardner> smb, bjf: nagios is installed with the orchestra server. I wonder what stats it keeps ?
<smb> bjf, cool. The other idea was to have the tools (in that case hopefully helpful) in seperate docs and then put them together under a starting point
<bjf> smb, yes, i wasn't going to polute your doc so much as maybe add pointers from it
<bjf> tgardner: don't know, that package install a *lot* of other packages
<smb> tgardner, I seem to see some nagios messages on those machines I had install via orchestra, but have not looked closer
<tgardner> smb, bjf: may SpamapS knwos
<tgardner> maybe*
<smb> bjf, Oh I wasn't so much afraid of pollution. Just liked the idea of separation because that way my brain tends to be more single tasked :)
<smb> errr
<smb> that does not make sense
<kirkland> tgardner: smb: damn, nice write up :-)
<bjf> smb: understand. i don't want it to turn into a doc like some of our "build" docs which are so hard to understand
 * smb nods
<smb> kirkland, thanks
<kirkland> smb: fyi, there's also https://help.ubuntu.com/community/Orchestra
<smb> kirkland, Ah cool, I will go trhough that
 * smb bookmarks
<tgardner> smb, whenever you update one of the cobbler config files, don't you need a 'sudo cobbler sync' ?
<smb> tgardner, Good point. I not sure when and when not. 
<tgardner> smb, I think anytime you want your changes deployed
<pgraner> tgardner, ok thx
<tgardner> pgraner, he sent email to c-k-t that he was out early to do to the opera (or some such shit)
<tgardner> pgraner, maybe he was jealous of your experience :)
<smb> tgardner, Right, on the other hand a lot of those are local text files and I don't really understand toward where that sync works to understand why I need it
<smb> But probably it restart various daemons or builds other files
<pgraner> tgardner, don't rub it in
<tgardner> :)
 * smb leaves for appointment
<BetaBrain> hi all 
<BetaBrain> http://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers are confused with this kind of damn realtek driver (rtl8187 - r8187) from when we have a quarrel one day and I absolutely do not find the solution. this chipset (RTL8187) is still poorly supported by linux. but in practice it works very well because realtek linux drivers not provide decent features it provides to be able to write from scratch. What can I do? I have
<BetaBrain>  looked everywhere with open source drivers I have tried with this result http://rtl8180-sa2400.sourceforge.net https://rtl-wifi.svn.sourceforge.net/svnroot/rtl-wifi/ but compiles it and then reading http://forums.fedoraforum.org/archive/index.php/t-151020.html here and that some expert tell me how thanks: Delta
<BetaBrain> Sorry for my bad English
<Gerald> ohsix,  hi...what is causing this problem? http://openpaste.org/f67E0f34
<Gerald> i refering to the build
<geri> can someone help out with my problem refering to dynamic kernel module support...?
<geri> http://openpaste.org/cB0Ae2B9
<niksoft> Hi
<elfurbe> Anyone know the status of TRIM support for md devices offhand?
<elfurbe> It looks like it was added to dm a while back
<geri> hi elfurbe can  u help out with my problem refering to dynamic kernel module support...? http://openpaste.org/cB0Ae2B9
<elfurbe> I definitely cannot, geri
<elfurbe> I'm here looking for help myself
<niksoft> elf, have you looked at: http://www.ocztechnologyforum.com/forum/showthread.php?82648-software-RAID-LVM-TRIM-support-on-Linux
<elfurbe> I did, but he's not doing mirrored lvs, just striped
<niksoft> no raid 1 is mirror...
<elfurbe> He was doing raid0
<elfurbe> I mean
<niksoft> i see, it is deceiving, he does mirror for boot
<elfurbe> raid1 for boot
<elfurbe> which is fine, I don't think you can boot from lvm, I'm not entirely sure
<elfurbe> Yeah :D
<geri> hi niksoft ... can u help on this?
<niksoft> hold on for a sec geri, i'll look at it (though i am not a kernel dev, i still should be able to figure this out, i think
<sforshee> geri, is hello.ko file present in the build directory after your build fails?
<geri> no
<geri> im not sure what im mission from the description... ;(
<sforshee> geri, you're looking in /var/lib/dkms/hello/0.1/build ?
<geri> i pasted it
<sforshee> i mean for the .ko file
<geri> there is not .ko created
<geri> whats this path here? /lib/modules/$(KVERSION)/build
<geri> thats set in the makefile
<sforshee> geri, can you paste your dkms.conf, and also check that you have the linux-headers package installed for your kernel
<geri> ok mom
<geri> http://openpaste.org/28463Dd1
<geri> here
<geri> i manually build the linux kernel
<sforshee> okay, but you have to have the necessary files in /lib/modules/$(KVERSION)/build to build modules against your kernel
<sforshee> the headers package normally provides this
<geri> i have a folder /lib/modules/$(KVERSION)/build
<geri> there is a build kernel and source directory
<niksoft> Would anyone be able (or willing) to help me with a bonding issue? More specifically 802.1ad link aggregation that is not balancing tx (at all)
<geri> any idea sforshee?
<sforshee> I think you should try a stock kernel. If it works there then it's something about your custom build. Maybe some missing infrastructure under that /lib/.../build directory, it needs to have the makefile and headers in place for what's in your makefile to work
<geri> wait i have a problem in the makefile
<geri> i forgot to add the tab
<geri> now it says: http://openpaste.org/43A44CFF
<geri> :)
<sforshee> and make.log says what?
<geri> http://openpaste.org/6AFB5Eac
<geri> oh
<niksoft> actually hold on my issue may be a tool issue
<niksoft> i swear i will kick some spirent devs if it is
<sforshee> geri, I think your /lib/module/.../build directory doesn't have all the required stuff
<geri> ok it builds now
<geri> it compiles against the linux header files?
<sforshee> yes, the #includes have to be satisfied from somewhere
<geri> ok it works fine now
<geri> i patched a linux kernel file in drivers/usb/class/cdc-acm.c...could i apply this method to avoid recompiling of the complete kernel?
<geri> i only compile this single file or how does that work?
<sforshee> yes, so long as you set up dkms.conf to install to /updates it will override the modules shipped with the kernel
<sforshee> you have to compile whatever files are needed for the module ...
<sforshee> in this case it looks like only that file would be needed
<niksoft> anyone know what the linux implementation of 802.3ad uses for load balancing?
<niksoft> i am guessing not round robin, but what is the hash based on?
<geri> sforshee, what should i set the package name and package version to?
<geri> shoudl i modify the source direct in the kernel path?
<sforshee> really they can be whatever you want, I'd probably use cdc-acm and 0.1, incrementing the version each time you update the package
<sforshee> I don't know what you mean
<niksoft> nm, so digging in the documentation, by default 802.3ad uses an xor balancing method based on the 2 macs
<geri> can i modify the cdc-acm.c direct in the kernel source path?
<sforshee> you can modify it in the kernel source tree, but it's what gets into your dkms source package that matters
<zpmorgan> Is the kernel's ASPM overheating regression supposed to be fixed by now in Oneiric?
<geri> sforshee, any idea what i did wrong? http://openpaste.org/DE031c9e
<geri> ok try to fix it
<geri> so it build now
<geri> sforshee, modprobe will automatically overwrite the kernel module?
<geri> how can i reset modprobe?
<geri> sforshee, one last question will apt-get source linux-2.6.35-generic include the linux header files?
#ubuntu-kernel 2012-01-20
<mdeslaur> bjf: I was told you maintain this page: http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
<mdeslaur> bjf: it seems to be borked at the moment
<bjf> mdeslaur: crap!
<bjf> mdeslaur: it's slightly more sane but it's still being looked at
<mdeslaur> bjf: hrm, yes, seems to be stuff still missing...ie: security
<mdeslaur> bjf: of course, I _could_ pretend all our bugs are fixed :)
<bjf> mdeslaur: it's back, i'll keep an eye on it
<mdeslaur> bjf: awesome, thanks!
<niksoft> hi, any devs in here who have a few minutes?
 * apw waves to cking and smb
<apw> ... and the tumbleweeds
<ppisati>  whom shall i prod to get the new omap4 kernels moved into the archive?
<ppisati> btw, tumbleweeds FTW! :)
<apw> ppisati, i think they all just got done
<apw> ppisati, i just asked for some of the main ones and they all got done by the looks of it
<apw> ppisati, indeed rmadison seems to indicate nothing in proposed
<ppisati> strange
<apw> it would have possibly occurs visibly 4m ago though
<ppisati> apt-get upgrade still suggets a 3.2.0-1403 instead of 3.2.0-1404
<ppisati> uhm ok
<apw> it might be mirroring delays then
<ppisati> yep
<ppisati> uhm
<ppisati> on my desktop:
<ppisati> [flag@newluxor ~]$ apt-cache show linux-image-3.0.0-14-generic | grep Filename
<ppisati> Filename: pool/main/l/linux/linux-image-3.0.0-14-generic_3.0.0-14.23_amd64.deb
<ppisati> wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-3.0.0-14-generic_3.0.0-14.23_amd64.deb
<ppisati> find the file and download it
<ppisati> but it's not the same for arm
<ppisati> apt-cache show linux-image-3.2.0-1403-omap4 | grep Filename
<ppisati> Filename: pool/main/l/linux-ti-omap4/linux-image-3.2.0-1403-omap4_3.2.0-1403.5_armel.deb
<ppisati> wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-ti-omap4/linux-image-3.2.0-1403-omap4_3.2.0-1403.5_armel.deb
<ppisati> ERROR 404: Not Found
<ppisati> well, actually the entire directory "linux-ti-omap4"
<ppisati> doesn't contain any .deb
<ppisati> just .dsc and .tar.gz
<apw> they've not gone to universe again have they?
<ppisati> ah right
<ppisati> didn't check universe
<apw> or are they ports
<ppisati> well, in ports.ubunt.com, i can find the .deb
<ppisati> but under pool/main/l/linux-meta-ti-omap4/
<apw> ok so i think that makes sense
<ppisati> while pool/main/l/linux-ti-omap4 doens't exist at all
<apw> oh no that doesn't
<ppisati> wait
<ppisati> bullshit
<apw> if its meta only
<ppisati> it does exist
<ppisati> nevermind
<ppisati> it does exist
<ppisati> but cut&paste
<ppisati> *bad
<ppisati> btw, did you see linux-backports-modules-2.6.32?
<apw> ppisati, whats up with 2.6.32
<ppisati> broken build
<ppisati> https://launchpadlibrarian.net/90500609/buildlog_ubuntu-lucid-i386.linux-backports-modules-2.6.32_2.6.32-38.39pre201201200400_FAILEDTOBUILD.txt.gz
<ppisati> /build/buildd/linux-backports-modules-2.6.32-2.6.32/debian/build/build-generic/compat-wireless-3.2/drivers/net/wireless/libertas/if_usb.c: In function 'if_usb_suspend':
<ppisati> /build/buildd/linux-backports-modules-2.6.32-2.6.32/debian/build/build-generic/compat-wireless-3.2/drivers/net/wireless/libertas/if_usb.c:1139: error: implicit declaration of function 'olpc_ec_wakeup_clear'
<ppisati> /build/buildd/linux-backports-modules-2.6.32-2.6.32/debian/build/build-generic/compat-wireless-3.2/drivers/net/wireless/libertas/if_usb.c:1141: error: implicit declaration of function 'olpc_ec_wakeup_set'
<apw> ppisati, ahh that i think is ogasawaras baby .. 
<ppisati> oky doky
<htorque> bryce: about bug 899159 - i can't seem to be able to cause the right gpu hang anymore. i tried for an hour and only got 0x7a000002 hangs (the one that's supposed to be fixed in xorg-edgers). should i still confirm it's gone with the ppa?
<ubot2> Launchpad bug 899159 in xserver-xorg-video-intel "[snb-gt2] GPU lockup render.IPEHR: 0x7b009004 [Needs mesa 7.11+git]" [High,In progress] https://launchpad.net/bugs/899159
<ppisati> no, the kernel is not there yet
<ppisati> with whom shall i talk?
<apw> ppisati, if you are talking to me there, then i normally talk to pitti
<ppisati> anyone who knows, ok, i'll talk to pitti
<tgardner> herton, how about adding an example to the maint-upload-mail help message ?
<herton> tgardner, I'm not against it, would be better indeed to have one
<herton> I'll put one in
<tgardner> herton, there are enough options to that script that an example would help.
<tgardner> especially because python is pretty unhelpful when it crashes
<tgardner> paolo, apw, I uploaded the Precise meta packages for linux-ti-ompa4 and linux
<ppisati> am i wrong or the headers are still stuck @ 1403?
<tgardner> ppisati, http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-ti-omap4/linux-headers-3.2.0-1404-omap4_3.2.0-1404.6_armhf.deb looks right
<ppisati> tgardner: just saw, but can't be upgraded
<ppisati> "The following packages have been kept back: ..."
<ppisati> among which there's the linux-headers
<tgardner> ppisati, perhaps because the publisher hasn't run yet and meta is still in flight ?
<tgardner> though I assume you're using the meta package I just uploaded....
<ppisati> tgardner: yes, i'm using meta
<ppisati> ii  linux-headers-omap4                    3.2.0.1403.3
<ppisati> let's see when the new one is available
<tgardner> ppisati, it appears to be right in the archive: 'rmadison -S linux-ti-omap4|grep precise|grep linux'
<tgardner> ppisati, looks like the tools meta package binary went to universe, but everything else is OK: 'rmadison -S linux-meta-ti-omap4 | grep precise'
<ppisati> ok
<hallyn> yikes i'm getting flooded in syslog by oopses from /build/buildd/linux-3.2.0/drivers/net/wireless/ath/ath9k/rc.c:697 ath_rc_get_highest_rix.isra.19+0x15c/0x1e0 [ath9k
<bryce> htorque, hmm
<bryce> htorque, yeah there can be some variance in the id's returned  I guess.  Verify the ppa solves the 0x7a000002 bug at least
<htorque> bryce: i was just surprised that i didn't get any crash files (apport was definitely running). updating now.
<htorque> bryce: should i be able to do a full upgrade? dist-upgrade wants to remove xorg, xserver-xorg, and co. a partial upgrade didn't suffice to get rid of the 0x7a000002 hangs.
<Sarvatt> htorque: i'm transitioning it to xserver 1.12 at the moment, dont upgrade
<Sarvatt> i put a huge warning that shows up when you add the ppa, guess that wasn't enough :)
<bryce> htorque, ok, in that case use the x-staging ppa
<htorque> Sarvatt: thanks for the info. i'll ppa-purge and https://launchpad.net/~bryce/+archive/lp830136
<Sarvatt> bryce: damage is done, can't ppa purge it at the moment
<htorque> or that :)
<bryce> Sarvatt, x-staging has new mesa right?
<Sarvatt> ppa-purge doesn't work with multiarch
<Sarvatt> nope
<bryce> no?  hrm
<Sarvatt> htorque: it'll be a few hours until everything builds, sorry about the trouble but theres no other way around the transition
<htorque> Sarvatt: hehe, yeah, reading warnings... totally my fault, but i'm fine with breakage.
<ohsix> i'm not, omg!
<htorque> bryce: is your ppa for bug 830136 fine if i should be able to fix the mess? :-)
<ubot2> Launchpad bug 830136 in xserver-xorg-video-intel "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x7a000002" [High,In progress] https://launchpad.net/bugs/830136
<jsalisbury> apw, I have a git question.  Is it possible to do multiple bisects in the same mainline linux src tree?  For example, I created two branches, one for each bug.  I started a bisect in one branch, but running 'git bisect log' in the other branch shows the bisect logs from the first branch.
<ohsix> Sarvatt: is there a way to sign up and be notified when you change the ppa description?
<Sarvatt> ohsix: i wish
<Sarvatt> even better i wish i could stop publishing, but disabling publishing means new uploads wont build against the new packages and theres a big dependency chain in the x stack
<Sarvatt> need to build protos, then libs against those protos, then xserver against all that, then drivers against the new xserver
<ohsix> can you add a new fake series to do the build, then move it?
<tgardner> jsalisbury, I don't think so. you'll have to clone the tree and run your second bisect out of that one.
<jsalisbury> tgardner, cool, I can do that.  I'll use the -reference option to save disk space.
<jsalisbury> tgardner, thanks for the help
<bryce> htorque, the ppa for bug 830136 is really only for oneiric
<ubot2> Launchpad bug 830136 in xserver-xorg-video-intel "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x7a000002" [High,In progress] https://launchpad.net/bugs/830136
<htorque> bryce: okay, in that case i'll wait. thanks!
<bryce> Sarvatt, maybe if the text were trimmed down a bit, the warnings would be more noticeable?
<Sarvatt> htorque: so the theory is that you remove the sources, apt-get update to get rid of the sources, and for every package installed that came from the ppa you need to sudo apt-get install package/release, like this for example http://pastebin.com/ewBeCnMR
<Sarvatt> in case you want to try to fix it yourself without waiting
<Sarvatt> that list wont work right now though, there are many libxcb libs installed also that need to be downgraded now too
<Sarvatt> and you might not have all that installed
<htorque> Sarvatt: thanks, already on it. ppa-purge might not work, but it seems to give me the right order in which i can mark the packages for a downgrade in synaptic. should be done soon. :)
<Sarvatt> yeah the big problem with ppa-purge is it doesn't do :i386 packages, and things will be all kinds of screwed up if you leave those installed :)
<ohsix> Sarvatt: is that a technical problem or has nobody got to it yet?
<Sarvatt> unless you're on i386 and dont run into the problem :)
<htorque> bryce: i simply didn't read the description. only i can fix that. ;-)
<apw>  jsalisbury yep what rtg said
<apw> js though actually now i think about it, you can git bisect log and save the output
<jsalisbury> apw, thanks.  I'll do that from on.
<apw> and switch to that one by running it
<apw> though its not quick, you could use the git bisect log output as your 'store' for each one you are doing
 * apw whines about how unity is GONE
<jsalisbury> apw, hmm, right, and then restart the bisect everytime
<apw> yeah quite slow to 'catch up' to the end each time on each tho.
<apw> but if space is your issue then ...
<jsalisbury> apw, yeah.  I think I'll have a seperate tree for each bug, then use the --reference option to point to a master tree.  That way I don't risk confusing multiple bugs ;-)
 * tgardner --> lunch
<niksoft> hi, is anyone actually here?
<bryce> niksoft, nope
<niksoft> thats what i thought
<_ruben> this channel is rather bursty when it comes to activity: either no action at all, or a lot of it ;)
<_ruben> gotta love them timezones/workdays/etc and all :)
<niksoft> sorry, i generally never get a reply if i just ask the question. So i am working on an ubu server, i need it to be able to both serve at extreemely high throughput, and at extremely high tps, like higher than most people dream about in most datacenters. Does anyone have any experience with setting up the kernel stacks for 10+gbit/sec? 
<geri> how can i remove dynamic kernel support?
<_ruben> 10+gbps takes a bit of effort indeed, tho packet size distribution plays a large role here obviously .. is juniper looking to use linux instead of bsd? ;)
<niksoft> lol i dont want to give in and build a bsd box, no juniper is, and will continue using bsd, though i cant comment where that's going ;)
<_ruben> hehe
<_ruben> was just a too easy remark to make ;)
<niksoft> so max i can hit at the moment is 13 sustained and 16gbit max, with pretty huge fail rates
<niksoft> this is on a 5mb file... oh fif i mention its a web server?
<_ruben> the packetshader ppl do ~40gbps by offloading to the gpu 
<niksoft> but i don't hit cpu perfomance issues, it is barely touched
<_ruben> packetshader likely wont help there ;) 
<_ruben> ic, interrupts?
<niksoft> 24 cores, 96gb ram, no disk io
<niksoft> yeah interrupts are around 30k
<_ruben> tcp window scaling?
<niksoft> on
<niksoft> infact... let me dump sysctl.conf
<_ruben> i assume the nic(s) is/are msi-x capable?
<niksoft> http://pastebin.com/JHKftWzf
<_ruben> seems you got the "usual suspects" covered .. does the loadavg shoot up ?
<niksoft> no not really
<niksoft> i am looking into msi atm
<_ruben> almost sounds like a really low level, like broken nic or so
<niksoft> nah both nics work          RX bytes:8560452364 (8.5 GB)  TX bytes:431279836182 (431.2 GB)
<niksoft>           RX bytes:8532901172 (8.5 GB)  TX bytes:430141265520 (430.1 GB)
<niksoft> ethtool doesnt seem to display MSI info at all... lets see maybe lspci will?
<niksoft> there it is
<niksoft> http://pastebin.com/apKNUzFg
<niksoft> yes msi is supported
<_ruben> tho if load's low as well as cpu usage, i doubt it'd be of any help :)
<_ruben> as it'd help to spread the (interupt) load over the cores
<niksoft> well that may help
<niksoft> i mean i get sustained 30000 interrupts, and that's a fair amount of ticks if it's going to the same core
<_ruben> well, does for instance 'top' show just one cpu being pegged?
<_ruben> looking at the total load on a 24-way sys doesn't mean much :)
<ohsix> theres an irq top too, that will read /proc/interrupts, don't remember the name of it tho
<niksoft> there is a core that is used a lot more than others
<ohsix> irqbalance (the daemon) can collect statistics too, i think
<niksoft> i am using nmon
<_ruben> irqbalance might help things, or make it worse, from what i've read about this stuff
<_ruben> not really sure if it takes anything special (configuration wise or whatever) to make use of msi-x
<niksoft> irqbalance is running
<niksoft> yeah i read that too, i will try stopping it
<niksoft> yeah i think you have to enable it manually
<niksoft> ok one thing at a time
<niksoft> running the tps test 1-10k tps on a 5kb file
<niksoft> irqbalance off
<niksoft> http://www.mjmwired.net/kernel/Documentation/MSI-HOWTO.txt on the msi
<ohsix> there are some lwn articles on napi that tell you what's important for high pps, and how to see what thet driver does with respect to it
<niksoft> ohsix, would you be able to point me in the right direction on that?
<ohsix> lwn napi in the googles brings up some stuff; i'm looking where the in tree documentation ended up
<niksoft> TY, also i am googling over here too
<ohsix> most of the fancy nics seem to have a corresponding file in Documentation/networking
<niksoft> wait i take that back  successful transactions went up by about 30k on a 3million transaction run thre from 1-10k tps
<niksoft> i will look into that, just going to start this throughput test
<niksoft> not much luck on that, the most i see in there is a setup for a gig nic
<niksoft> qlogic driver is nowhere to be found atm
<niksoft> grep to the rescue
<niksoft> ok greping through i have some progress, but it needs testing
<niksoft> enabling MSI-X, at least with these preliminary results gave me a 0.8% boost on throughput on a 5mb file
<niksoft> trying something smaller (5kb file) at 1-10k rps, lets see if that about confirms these results
<niksoft> so i increased the buffers further, following suit with the intel 10GbE driver notes in the kernel doc (though my values are higher yet, since i have 2 10 gig and 2 1 gig interfaces
<niksoft> may not seem much, till you consider that it's roughly 100megabit difference
<hallyn> is there a commonly used trick for getting vmlinux back from vmlinuz?
<hallyn> (i remember finding one a few years ago, but it was not common nor reliable)
<hallyn> looking for a way to run gdb against the kernel from linux-image.deb...
<hallyn> <shrug>  followed http://www.codeguru.com/forum/showthread.php?t=415186  which is in fact what i did years ago
<Sarvatt> hallyn: it's in the ddeb
<hallyn> Sarvatt: thanks, I may use that in the future - though 'fakeroot debian/rules binary-generic' did not create a ddeb
<hallyn> i suppose i should use that anyway as i appear to have no symbols
<hallyn> Sarvatt: do you happen to know the rule to make the ddeb?
<Sarvatt> hallyn: afraid not, looking through this crazy build system now though
<hallyn> Sarvatt: no worries, don't waste time on my account - thanks for the tip
<Sarvatt> hmm
<Sarvatt> skipdbg=false?
<Sarvatt> fdr binary-generic skipdbg=false
<Sarvatt> not sure if you need pkg-create-dbgsym installed also
<hallyn> cool will try, thx
#ubuntu-kernel 2012-01-21
<dg_> Hello, I wondered if the 3.3 kernel (with the power usage fixes) will be backported to Ubuntu 12.04 (LTS)
<bryce> dg_, debs of 3.3-rc1 @ http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc1-precise/
<Gerald> hi
<Gerald> hm what is causing this issue? http://codepad.org/SAeKiFJr
<dg_> hi bryce, does that mean that 12.04 will ship with the 3.3 kernel instead of 3.2?
<bryce> dg_, it does not mean that
<hallyn> am i the only one for whom the new 3.2.0-10-generic kernel won't boot?
<hallyn> i'll have to get a screenshot of the msg i get, it's one i've notseen before
<Gerald_> why is the module not correctly removed from the kernel? http://codepad.org/zClCoi4t
<vanhoof> cnd: have you seen any bugs filed lately where the window sizing handles have dissapeared on precise?
<vanhoof> cnd: three finger tap on a magic trackpad
<cnd> vanhoof, utouch is going to be broken for a while on precise until we finish some work on utouch-geis
<cnd> though it should still be working if you don't have any ppas installed
<vanhoof> cnd: nah, no PPAs here, just an upgrade from Oneiric
<cnd> but as soon as we upload the new X bits, which probably will happen monday, utouch-based gestures will disappear for a bit
<vanhoof> cnd: four finger tap still works, as does three, just lost the window handles
<cnd> there may be changes in the latest unity too, which I don't really know about
<vanhoof> cnd: gotcha
<vanhoof> cnd: yeah, just curious if you'd come across any bugs that might match up
#ubuntu-kernel 2013-01-14
<infinity> ppisati: Can you make sure someone uploads your ti-omap4 SRUs to the PPA today?  The earlier, the better, so I can promote them when I get up in the morning. :)
<ppisati> infinity: the person who usually deal with omap4 kernels is in Brasil, should be up&running in ~7hrs
<smb> morning
<ppisati> building another kernl
<ppisati> back in a bit
 * apw whines about broken internets
<smb> apw, Mine works
<apw> smb, well thats nice for you
<apw> mine works a bit right now
<smb> apw, :) I know it doesn't help you much
<apw> well you could bring some internet pixy dust with you i suppose
<smb> apw, More hw going to die ?
<apw> smb, no this is a tunnel issue
<smb> apw, Ah, still not using one of those but I suppose this years resolution should be to start sharing a bit of your pain
<apw> smb, not sure how much you can bear, as it is ip address changes which trigger my pain most often
<apw> and you have a high level of those
<apw> if weechat wasn't so bust i'd probabally not notice
<smb> Ah yeah, got those, but with ipv4 that kind of thing was more "normal"
<smb> (not that irc really copes with it)
<apw> finally ... all back and working
<apw> stoopid thing
<tjaalton> apw: hey, do you have ideas about what bug 982889 is missing? we have a ton of dupes, and looks like precise will get some of them with the backport stack
<ubot2`> Launchpad bug 982889 in xorg-server (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Undecided,Confirmed] https://launchpad.net/bugs/982889
<tjaalton> well, it's become more common with quantal, this one was reported on precise already
<apw> tjaalton, the bug seems to imply it is a plymouth X handoff issue, that plymouth has not yet released DRM when X starts
<apw> tjaalton, which seems like it would be an issue with the way we handle plymouth from the upstart scripting
<apw> or, plymouth says its exited before it has i suppose
<apw> tjaalton, could it be as simple as needing to make the /etc/plymouth quit have a --wait ?
<apw> tjaalton, no probabally not as that is done out of a parallel job plymouth-stop, which is triggered on 'starting lightdm'
<apw> jodh, if an upstart job is triggered on 'starting', will that have to complete before the 'starting' completes or in parallel with the start
<tjaalton> yeah this is hairy..
<jodh> apw: job completes before the starting event does. This is documented in upstart-events(7) - table 1 shows 'starting' event is of type 'Hook' which blocks.
<tjaalton> also, plymouth in both precise and quantal is quite old
<apw> no actually that one isn't doing it, cause its not triggered for lightdm ... bah
<apw> jodh, thanks :)
<apw> tjaalton, actually lightdm does the plymouth quit itself, and _that_ version may need --wait
<tjaalton> that's for su-mode?
<tjaalton> ah no
<tjaalton> well, for text and su-mode?
<apw> tjaalton, no whne handing over to X i think
<tjaalton> if [ "$ARG" = "text" ]; then, if [ "$RUNLEVEL" = S -o "$RUNLEVEL" = 1 ]
<apw> tjaalton, no not in the upstart jobs, in the normal case, builtin to the binary
<tjaalton> huh?
<tjaalton> ok
<apw> tjaalton, there seems to be some 'start X' and wait for it to send us a SIGUSR1
<apw> when we then (in lightdm) do a plymouth quite --retain-splash
<xnox> apw: "starting" == in parallel, e.g. just as the other is ready to be started. "started" the other one must finish starting.
<tjaalton> apw: oh, nice..
<apw> tjaalton, and it is not clear to me that that quit incantion should not have a --wait on it
<tjaalton> "Wait for boot daemon to quit"
<tjaalton> what does that mean
<apw> its hard to be 100% sure from the description and plymouth is obtuse in the extreme to read
<apw> tjaalton, ahh ok, yeah --wait would make the client side wait for the daemon to actually exit, else it is just sending it a message and then assuming it is done
<apw> this seems a clear rate without --wait
<tjaalton> weird that lightdm does this inside the daemon.. I'd have thought it's upstarts job
<apw> it is doing some complex dance with the Xserver
<apw> allowing it to start but not open drm, stopping plymouth and then letting the xserver grab it
<apw> so that the framebuffer contents can be copied to the root window
<apw> and us not get that flicker
<tjaalton> probably why I can get my hsw in a state where the mouse cursor is shown on a perfectly functional getty..
<apw> heh yeah
<tjaalton> plymouth never has a chance of actually showing any splash, since X is up and running <2s into the boot
<apw> tjaalton, nice i am sure,
 * henrix -> lunch
 * henrix reboots...
<sforshee> stgraber, can you give me the output of 'dmidecode -s system-manufacturer' and 'dmidecode -s system-version' for your x230?
<stgraber> root@castiana:~# dmidecode -s system-manufacturer
<stgraber> LENOVO
<stgraber> root@castiana:~# dmidecode -s system-version
<stgraber> ThinkPad X230
<sforshee> stgraber, ta
 * ogasawara back in 20
<sforshee> stgraber, I have a patch for your backlight issue. Do you want me to make a build for you or just give you the patch?
<stgraber> sforshee: if you have something more powerful than a quadcore i7 to build that kernel, go ahead, otherwise I'll build it here
<sforshee> stgraber, I've definitely got something more powerful than that at my disposal ;-)
<sforshee> I'll post to the bug when I've got a build for you then
<stgraber> cool, thanks ;)
<wookey> the linux package build-deps on libelf-dev, libunwind8-dev, libdw-dev, libnewt-dev.
<wookey> which are those are for build arch and which for host arch?
<wookey> or both
<wookey> lobunwind looks to be for host arch for perf. maybe libelf too.
<wookey> oh and libaudit. And there is a flex dependency - should that actually be libfl-dev now?
<wookey> who knows about this stuff?
<apw> they are for perf mostly indeed 
<apw> obviously for the lib* ones those are for the 'arch we are making packages for'
<apw> flex would be used for the 'arch we are building the package on'
<apw> flex and bison are both used in perf, and both 'arch we are building on'
<apw> wookey, any others you care about ?
<apw> wookey, not that cross compiling the upstream kernel works so very well of course
<apw> as the headers assemblages have some of the tools in them, and in a cross environment that makes them usless
<wookey> what about libnewt - isn;t that for make menuconfig curses stuff, and thus for build arch? Or are we actually makiing a tool to run on the host arch later still?
<wookey> Yes I see that the kernel tools stuff is not multiarch -ready. You can specify a dir for libunwind for example, but it assume that inlcude and lib dangle from that, which is wrong for multiarch.
<wookey> my understanding is that the kernel crossbuild works OK. it's the tools stuff which is a problem. Am I wrong about that?
<wookey> apw: what exactly do you mean by "as the headers assemblages have some of the tools in them, and in a cross environment that makes them usless"?
<wookey> The kernel seems to understnad that it has a build arch (called 'ARCH@ it seems) and a host arch (called 'CROSS-COMPILE'). And that host-arch libs might be in funny directories
<wookey> Which should be suffient to make it all cross properly without major surgery
<wookey> And people cross-build their kernels all the time so one can reasonably expect thing to be set up sensibly
<apw> it builds ok, using BUILD binaries, the problem is you also need those same binaries for the target as well to allow extern .ko's to b
<apw> be built, and there is no concept of building them both ways in there
<wookey> OK, so there are some things that we need to build for both build and host arch. ONe for use during the build and one for packaging?
 * ppisati -> gym
<wookey> s/for packaging/to get put in packages/
<apw> wookey, yeah things like the config binary and related things which are used during the build, and from the headers package when installed
<wookey> could we fix this by making the kernel build depend on the kernel-tools package so one of the correct (build) arch is installed, and then it makes them for the host arch in the build for packaging, presumably as now?
<wookey> the config binary ends up in the headers package? Is that what you said?
<wookey> I guess I should look at what's in which packages...
<cking> bjf, can you pull in the latest ecryptfs into the autotest tests to pick up the latest fixes and goodness?
<bjf> cking, will do
<cking> thanks!
<wookey> there are about a billion packages ther kernel makes - which one(s) do the tools end up in?
<arges> wookey: do you mean linux-tools?
<wookey> arges: probably, but the control file I have in front of me doesn;t contain that, which is why I didn't find it.
<wookey> right I see it in the distro. and linux-tools-common and linux-tools-<board> 
<wookey> will investigatte
<apw> wookey, yeah kernel-wedge is a menace, you get a more comprehensive control when you clean the package
<apw> but even then it is arch specific
<wookey> currently haveing fun decoding the logic in debian/rules.d/0-common-vars.mk which is full of Make double-negatives
<wookey> this is confusing: 
<wookey> # linux-libc-dev may not be needed, default to building it.
<wookey> do_libc_dev_package=false
<wookey> does setting do_foo to false really mean its gets built or is that comment out of date?
<rtg> wookey, what branch or repository do you have ? do_libc_dev_package in only true for the master kernel branch.
<rtg> s/in/is/
<wookey> I'm looking at linux-linaro-origen-3.7
<apw> wookey, i suspect that the comment is crook, this is probabally a derivative with the opposite default to the master default
<wookey> which is simply the one someone complained didn't corss-build
<apw> yeah then it ouwld be 
<apw> so that comment is from master, where it is =true
<apw> but the only place it is true
<wookey> aha. OK. just checking I wasn;t too confused
<wookey> Is there a blessed way to set env vars for the build - e.g if I wanted to set do_tools=false or the V=1 verbose builds.
<apw> wookey, i tend to just set those by hand in the environment or directly on my debian/rules incantation
<wookey> I tried do_tools=false dpkg-buildpackage -aarmhf -d -nc  and export do_tools=false but no joy. I think dpkg-buildpackage clears anything not starting with DEB_ IIRC
<wookey> Ah call rules diretyl, not via dpkg-buildpackage. OK
<apw> yeah i tend to do that kind of thing for my messy builds
<wookey> cheers. sorry for all the dumb questions. I have a vague idea how it works now - will have a poke. 
<apw>   HOSTCC  scripts/mod/modpost.o
<apw> wookey, i think that is one of the ones which ends up wrong in teh final pacakges
<apw> in a cross environment
<apw> and we are of course interested in any insight you have to making it not broke :)
<wookey> OK, great. I'll try and serve up some insight this week :-)
<apw> wookey, as we do cross compile routinly for the main package to confirm they build, which works
<apw> but they arn't quite the same, this issue for one
<wookey> nobbling with do_tools=false gets me to a wrong-arch objcopy in " Add .gnu_debuglink sections to each stripped .ko"
<wookey> I guess there are both issues in the main package and the question of why variants don't built (which is what linaro cares about right now)
<wookey> I'll look at both. 
<ogra_> linaro uses /debian.$subarch dirs which override the /debian stuff
<ogra_> (at least i always have to do the do_tools disabling in /debian.$subarch when using linaro based kernels)
 * rtg -> lunch
 * smb walks away
 * cking shuffles off
<stgraber> sforshee: new kernel doesn't seem to work here
<stgraber> sforshee: or I didn't boot the right one, stupid secureboot... will be back in a sec :)
<sforshee> stgraber, yeah my build obviously won't boot with secureboot enabled
<sforshee> unless you allow grub to boot unsigned kernels I guess
<stgraber> sforshee: alright, works fine now ;)
<sforshee> stgraber, good :)
<stgraber> sforshee: yeah, an archive kernel wouldn't boot on my laptop either as I have a custom secureboot PKI in that machine (to test experimental self-signed shim)
<stgraber> so I need to remember to manually sign vmlinuz before I can actually boot it :)
<sforshee> sounds like fun
<stgraber> it's easy once you have that whole mess setup, it's just that you need to remember that installing a kernel isn't actually enough to make it bootable :)
<sforshee> stgraber, I'm hoping to get some testing with the T430s too on the upstream bug, so I'm gonna sit on the patch a day or two to see if anyone tries it
<stgraber> k
 * rtg -> EOD
<hggdh> herton: there?
<hggdh> bjf: I was working on bug 1097914 -- it states the kernel should be 3.5.0.1607-9, but the kernel installed is 3.5.0-1607-11. Which version is the target here?
<ubot2`> Launchpad bug 1097914 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.5.0-1607.9 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1097914
<hggdh> bjf: bah, forget
#ubuntu-kernel 2013-01-15
<infinity> bjf: Why did you reassign 960770 from linux-meta to linux?  It's a bug in (and being fixed in) -meta.
<ppisati> moin
<infinity> o/
<ppisati> reboot
<ppisati> and reboot (again)
<ppisati> and reboot again
<smb> cking, not for you
<tjaalton> pulling 48e858340dae43 for quantal would fix a regression in 3.5.0-18, bug 1088271
<ubot2`> Launchpad bug 1088271 in linux (Ubuntu) "X startup fails with "failed to get resources" error after update to 3.5.0-18 " [High,Triaged] https://launchpad.net/bugs/1088271
<henrix> tjaalton: i took a look and this commit is already present in quantal
<tjaalton> really?
<tjaalton> it's not in the stable series
<tjaalton> yet
<tjaalton> the original commit is in quantal
<tjaalton> this reverts it
<tjaalton> at least -21 is still broken, is it in -22?
<henrix> let me check...
<henrix> it was added into 3.5.0-18.29
<tjaalton> yes, the original one
<tjaalton> which is brokne
<tjaalton> broken
<henrix> ah, you meant to revert 48e858340dae43?
<tjaalton> no
<tjaalton> this _is_ the revert :)
<henrix> yeah, right :)
<henrix> so, this sha1 was added into 3.5.0-18.29
<tjaalton> 47f80be7fc108d4 is the one you mean?
<tjaalton> this would revert that
<henrix> gah, you're right. sorry
 * henrix got confused :)
<tjaalton> :)
<henrix> tjaalton: i can submit a patch to SRU it next cycle
<tjaalton> ok, thanks
<henrix> np
 * smb starts to move over
<cking> smb, have a good journey
 * henrix -> lunch
<ppisati> brb
<xnox> it's funny how with 3.8 kernel my usb2.0 ports sometimes stop working, but I am not complaining since the 3.0 usb port is working more reliably now =)
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<akgraner> jsalisbury, thank you again - my laptop seems to working well today
<jsalisbury> akgraner, that's great news.  
<akgraner> yes it is
<ppisati> rtg: tim, what do you use on your imx6? linaro? debian? ubuntu?
<jsalisbury> akgraner, you should be able to apply the latest updates again.  But maybe wait until the end of the day ;-)
<ppisati> rtg: and how do you boot it? u-boot on spi flash? or u-boot on sd?
<rtg> ppisati, I installed the linaro image, then built a raring chroot to do builds. I think it must be booting from SPI
<rtg> The raring chroot is on an external USB drive
<rtg> as is /home
<ppisati> rtg: ok, and do you know if you are using boot.scr? uenv.txt or do you boot straight from uboot env?
<ogra_> what a waste
<ogra_> use SATA !
<ogra_> USB is for pandas
<ogra_> :P
<akgraner> jsalisbury, ok I'll do it after I end my day
<rtg> ogra_, nm, it _is_ SATA
<ogra_> :)
 * ppisati wonder if ogra has some kind of irc filters because he shows up everytime an arm discussion sparks...
<jsalisbury> akgraner, or whenever you feel like it.  No need to rush.  It would just be good to confirm all goes well with applying updates.
<ogra_> haha
<ogra_> intuition ;)
<rtg> ppisati, IIRC it is booting from uboot env. I don't think I customized anything (but then its been awhile)
<ppisati> rtg: ok
<akgraner> jsalisbury,I'll let you know for sure
<ppisati> ogra_: do you have an imx6?
<ogra_> yes
<ppisati> ok
<ogra_> using an image cooloney gave me
<ppisati> i'm adding imx6 support to R/master as part of multiplatform
<ogra_> 3ith my own ubunt-coe based rootfs onSATA
<ppisati> but since we never had any official ubuntu img fr it
<ogra_> i might try it then
<ppisati> i was wondering which solution i should pursue for booting it
<ogra_> i would go for SD, easiest to modify
<ppisati> yep
<ppisati> but there's all kinds of config out there
<ppisati> booting from SPI flash
<ppisati> from u-boot on sd (dedicated partition)
<ogra_> iirc the first stage is in flash anyway
<ppisati> using u-boot env vs boot.scr vs uEnv.txt
<ppisati> yes, but some use it to jump to u-boot on sd (Linaro does that)
<ogra_> and thedefault is to boot from flash all the way
<ppisati> others jump straight from flash u-boot to mmcblk0pX/uImage
<ogra_> so you likely need to tweak that for SD
<ogra_> and then just provide a u-boot sd image
<ppisati> ogra_: actually, if i take an omap img and just change the kernel it shoud be ok, right?
<bjf> brendand, what's your ETA for having the precise and quantal testing done?
<ogra_> u-boot too indeed
<ogra_> but yeah
<ppisati> ogra_: yeah, u-boot of course
<ogra_> (and initrd if you need modules from there)
<ppisati> well
<ppisati> with multiplatform there's one kernel for many chips
<ogra_> ah, k
<ppisati> omap3, omap4 and imx6 now
<brendand> bjf - thursday latest
<ppisati> omap3/4 works
<ogra_> i forgot you said DT
<ppisati> imx6 not yet
<brendand> bjf - tomorrow would also be possible if earlier is strictly better
<ogra_> i want tegra2 and 3 more than imx
<ogra_> :)
<ogra_> (totally selfish indeed )
<ppisati> ogra_: that's the hw that i've handy, first let me make it work well :)
<bjf> brendand, sooner is always better than later
<ogra_> they need to gibe you a nexus7 !
<ogra_> :)
<jsalisbury> bjf, herton, henrix Just wanted to give you guys a heads up on bug 1098262  
<ubot2`> Launchpad bug 1098262 in linux (Ubuntu) "Precise crashes hard when HP array rebuilds" [High,Incomplete] https://launchpad.net/bugs/1098262
<bjf> jsalisbury, ack
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 22nd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * rtg -> lunch
<rtg> jsalisbury, having a look at bug #1099913
<ubot2`> Launchpad bug 1099913 in linux (Ubuntu) "Please consider applying upstream patches for mtip32xx" [High,Confirmed] https://launchpad.net/bugs/1099913
<jsalisbury> rtg, thanks
<rtg> jsalisbury, so I accidentally deleted your email about ^^. Could you forward it to bjf as well ?
<jsalisbury> rtg, sure
<rtg> I'm sure he'll have some thoughts about timing.
<jsalisbury> rtg, done
<vanhoof> rtg: talked with kentb on that one, its ok for SRU proposal post 12.04.2
<rtg> vanhoof, yeah, I didn't think it would make .2
<rtg> however, it'll be in the pipeline soon
<vanhoof> yeah, he ping'd me on that bug this morning, wanted to make sure it wasn't end of the world waiting for the next sru cycle
 * vanhoof doesnt want to derail the .2 train
<vanhoof> (if possible :))
<rtg> works for mwe
<rtg> me*
<bjf> rtg, i've talked to him as well, we are all good
<rtg> bjf, ack
<bjf> rtg, you mumbling today?
 * rtg -> EOD
<hallyn> so for raring on a NVIDIA Corporation GT218 [GeForce 310M], what is the recommended nvidia package right now?  (right now i can't boot a raring kernel - using old quantal one - and jockey-text -l says none are installed)
<hallyn> i guess i'll try nvidia-current... 
<vanhoof> hallyn: might wana check w/ tseliot when he's up
<vanhoof> hallyn: i know he's been sorting some of that out last week/this week
#ubuntu-kernel 2013-01-16
<hallyn> woohoo, nvidia-current worked this time
<hallyn> apw: say, i'm hoping to do a lxc irc meeting in a few weeks to discuss direction with userns.  The first 20 minutes would be an overview.  Would you or anyone from kernel team want to listen in on that part?
<ppisati> moin
 * ppisati hopes my UK kernel mates are ok...
<ppisati> flag@linaro-ubuntu-desktop:~$ grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//'
<ppisati> Freescale i.MX6 Quad (Device Tree)
<ppisati> it works :)
<ppisati> flag@linaro-ubuntu-desktop:~$ uname -a
<ppisati> Linux linaro-ubuntu-desktop 3.8.0-0-omap #2~multi8 SMP Wed Jan 16 11:21:38 UTC 2013 armv7l armv7l armv7l GNU/Linux
<ppisati> brb
<jodh> FYI - I raised an apport bug today that stops users from raising bugs on the current kernel: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1100198
<ubot2`> Launchpad bug 1100198 in apport (Ubuntu) "source_linux.py logic fails to detect 3.8.0-0-generic as an Ubuntu kernel" [Undecided,New]
 * henrix -> lunch
<ppisati> brb
<arges> found an interesting kernel bug. plugging and unplugging a usb headset causes a panic on 3.2
<jsalisbury> arges, can you reproduce it easily?
<arges> jsalisbury: yea i'm doing that now... getting a backtrace and if we are really lucky ill have a vmcore as well
<jsalisbury> arges, cool.  I recall a similar bug reported in the past few days.  I don't remember off had if it was for Precise.  I'll go an look
<jsalisbury> arges, it could be bug 1097396 that you are hitting.  
<ubot2`> Launchpad bug 1097396 in linux (Ubuntu) "Unplugging USB Headset causes Kernel Panic" [High,Incomplete] https://launchpad.net/bugs/1097396
<arges> jsalisbury: easily reproducible at this point.. tempted to try my raring laptop. but don't want to loose IRC
<arges> jsalisbury: cool looks like this is also precise
<jsalisbury> arges, yeah, I started a bisect, but waiting for testing feedback.  
<jsalisbury> arges, can you try the latest 3.2 kernel?  It's 3.2.37 now
<arges> jsalisbury: let me compare notes
<arges> jsalisbury: to see if i'm hitting the same thing
<jsalisbury> arges, that bug is fixed in mainline
<jsalisbury> arges, and raring
<arges> jsalisbury: we have a winner snd_complete_urb
<arges> jsalisbury: same backtrace here
<jsalisbury> arges, cool
<arges> downloading and testing 
<jsalisbury> arges, yeah, it could be fixed in .37 since it's fixed in the 3.7 and 3.8 kernels.
<arges> jsalisbury: ok tried that kernel still paniced
<jsalisbury> arges, ok.  Maybe a reverse bisect is needed
<arges> hmm now kdump wants to work :)
<jsalisbury> heh
<sforshee> cking, does the firmware on your x230 have an object named BRTW in the EC namespace that is returned by _BCL?
<jsalisbury> arges, i haven't done any research upstream on that bug yet.  That's another approach in addition to a reverse bisect
<arges> jsalisbury: if you want to start the bisect, i could look at the backtrace a bit and see if  I can get anything by looking and blaming
<jsalisbury> arges, I believe v3.7 final did not have the bug.  Maybe try v3.6 final?
<arges> jsalisbury: ok that's a bit easier... machine is still taking a dump
<arges> that sounds bad
<jsalisbury> arges, sure.  I can't reproduce the bug here, but I'll update bug 1097396 and work with Tony
<ubot2`> Launchpad bug 1097396 in linux (Ubuntu Precise) "Unplugging USB Headset causes Kernel Panic" [High,Triaged] https://launchpad.net/bugs/1097396
<arges> jsalisbury:well i'lll test 3.6 first 
<jsalisbury> arges, cool
<arges> jsalisbury: and i can do the bisect
<jsalisbury> arges, great.  can you also update that bug as you go?
<arges> jsalisbury: yup
<jsalisbury> arges, thanks!
<apw> hallyn, sounds interesting indeed
<ppisati> time for some pain...
 * ppisati -> gym
<hallyn> say, I'm getting a build error in libvirt due to include/linux/if_bridge.h using struct in6_addr without it being defined.  
<hallyn> can that be considered a bug in the header?
<hallyn> or is it reasonable to say all userspace using that now has to #include <netinet/in.h> ?
<doc___> Kernel question: I'm trying to write an app that talks to USB cameras. Should I use /dev, /proc or sysfs?
<hallyn> it was added on dec 6 as part of commit "bridge: export multicast database via netlink"
<apw> hallyn, well if in4_addr is defined without additional headers and in6_addr not, that sounds like a bug
 * rtg -> EOD
<hallyn> apw: i suspect in4_addr is also not defined
<hallyn> apw: but that isn't used in if_bridge itself
<apw> oh hmmm, i wonder why in6_addr is used
<hallyn> apw: see https://www.redhat.com/archives/libvir-list/2013-January/msg00957.html.  it was used as of a commit on dec 7
<hallyn> oh, i see.  i thought the thread on netdev had died, but i guess it's more recent than i thought, so still on-going
<apw> hallyn, well that doesn't really resolve ... but hopfully will
<hallyn> apw: right.  hopefully.  meanwhile i'll work around it in libvirt (using the upstream patch) but i expect more build breakages in raring
<noisepub2> <noisepub2> quantal kernels in precise are not packaged correctly for multiarch
<noisepub2> <noisepub2> linux-headers-`uname -r` needs to be Multi-arch: foreign
#ubuntu-kernel 2013-01-17
<henrix> brb
 * henrix -> lunch
 * ogasawara back in 20
<bjf> brendand, how is the SRU kernel testing coming?
<brendand> bjf - quantal done. precise soon
<bdmurray> ogasawara: how should I fix bug 1100198?
<ubot2> Launchpad bug 1100198 in apport (Ubuntu) "source_linux.py logic fails to detect 3.8.0-0-generic as an Ubuntu kernel" [Undecided,New] https://launchpad.net/bugs/1100198
<bdmurray>     # If running an upstream kernel, instruct reporter to file bug upstream
<bdmurray>     abi = re.search("-(.*?)-", report['Uname'])
<bdmurray>     if abi and (abi.group(1) == '999' or re.search("^0", abi.group(1))):
<bdmurray> just remove the 'or' or something else?
<ogasawara> bdmurray: I'm trying to remember what that the second half of the 'or' expression was supposedly checking for
<bdmurray> ogasawara: well its checking for a 0 in 3.8.0-0-generic
<ogasawara> bdmurray: I'd say remove it
<ogasawara> bdmurray: or just wait till we bump our abi to 3.8.0-1 :)
<ogasawara> bdmurray: which will likely  happen within a week
<bdmurray> ogasawara: it'll take just a moment so I'll do it
<rtg> bdmurray, I'm curious why '0' has special significance ?
<ogasawara> rtg: I think it was the lazy way of detecting our mainline builds which are versioned eg 3.8.0-030800rc3-generic
<rtg> ah
<ogasawara> bdmurray: so we may want to make that mainline build check smarter
<bdmurray> ogasawara: what are they numbered now?
<ogasawara> bdmurray: lemme install one and double check, but I'm pretty sure it'll be 3.8.0-030800rc3-generic or similar
<bdmurray> oh, well ^0\d should work
<ogasawara> bdmurray: except in the case when we have -0 in our distro kernel abi
<ogasawara> bdmurray: oh wait, I should have parsed that better
<ogasawara> bdmurray: yes, you are correct
<bdmurray> ;-)
<ogasawara> bdmurray: so I say go with that
<utlemming> question about 12.04.2: what is the default kernel going to be? I heard a rumor it might be 3.5. 
<bjf> utlemming, yes, the default will be the quantal kernel
<utlemming> bjf: will there be a -virtual kernel? 
<bjf> utlemming, for quantal, there is no separate -virtual kernel
<utlemming> bjf: right, I understand that. What I am trying to figure out is how this screws up the cloud-images and all the things that expect a -virtual kernel. For example, grub2-legacy, will be broken because of this change...which means that we need an SRU, otherwise the new kernel won't get used. 
<bjf> utlemming, ok, so the answer is for the default, there is no -vertual flavour
<rtg> the primary purpose of the LTS kernels is for HW enablement.
<utlemming> bjf: for quantal there is no -virtual flavour, but there is a linux-image-virtual package to install from
<smb> rtg, bjf I cannot really say from top of my head. Wondering whether in precise there really was a seperate kernel still or already the meta-package only.
<smb> and iirc at least at some point the cloud images had to know how to tell from the /boot/ config options whether they would use it in grub
<utlemming> so the question, I guess, is if there will be the meta-package for -virtual
<utlemming> smb: for the boot loader, this going to be a bit screwy...I'll have to SRU version detection logic
<rtg> utlemming, I don't think virt instances should (or can) use the point release.
<rtg> the 12.04.2 point release that is.
<utlemming> for 12.04.2, generally the release team wants a point release update. We build daily images of precise. So if this change breaks the dailies, then that is a problem for us.
<rtg> ogasawara, help me out here. don't we have a page describing how point releases address HW enablement ?
<ogasawara> rtg: we have https://wiki.ubuntu.com/KernelTeam/Specs/QuantalLTSEnablementStack
<ogasawara> rtg: but that's more regarding the policies and procedures for updates/upgrades etc
<rtg> ogasawara, which kind of addresses -virtual, right ?
<rtg> AMI images should be sticking with the original release, or 12.04.1 at the latest.
<bjf> rtg, have we clearly messaged that 12.04.2 is for HW enablement and should not be used for cloud instances?
<utlemming> that's kind of what I am reading here
<rtg> bjf, according to ogasawara's wiki pages, that is the message we've been sending.
<bjf> rtg, i'm reading that and don't come away with that message
<rtg> bjf, lemme review it. it was certainly our intent when messaging this to the community that point releases were for HW enablement.
<bjf> rtg, yup, no argument there
<rtg> bjf, well, I guess you do sort of have to imply from the decisions listed in that page that some stuff just won't be supported in the point releases. perhaps we should expand the discussion therein to include impacts on virt instances. ogasawara ?
<ogasawara> rtg: wfm, did you want to add a blurb or shall I
<rtg> ogasawara, you are so loquacious that I thought you ought do it :)
#ubuntu-kernel 2013-01-18
<datakid23> Hi, I"m having weird apt-get issues regarding a missing kernel image. It's a kernel from a while ago though - the issue happened as a result of having to move /boot (initial partition too small) coupled with updates that failed due to power failure. Pastebin of error after an apt-get upgrade: http://paste.ubuntu.com/1543233/
<datakid23> Error message is "Internal Error: Could not find image (/boot/vmlinuz-3.2.0-31-generic)". I've tried apt-get clean/remove/update etc Anyone know where I might find that boot image online? 
<datakid23> I am running 12.04
<datakid23> nothing? No one can tell me where the kernel image or deb for vmlinuz-3.2.0-31-generic is? I've tried google, this was a last resort
<lifeless> internal error from what?
<datakid23> internal error from an apt-get upgrade/dist-upgrade
<datakid23> apt is upgrading everything except the kernel atm, because of this unresolved config on an image that is AWOL
<datakid23> lifeless: sorry, I should have made that clear to start with
<lifeless> have you tried update-grub ?
<datakid23> lifeless: yes, updating grub works fine - but apt still fails on the missing vmlinuz file
<datakid23> the file isn't on my box at all - I'
<datakid23> ve done a updatedb/locate
<lifeless> well apt itself doesn't care about vmlinuz
<lifeless> update-initramfs may
<lifeless> and update-grub
<lifeless> which are shell scripts used to setup your boot environment
<lifeless> its likely one of those is the actual thing failing
<datakid23> lifeless: it seems to be a dpkg error
<lifeless> it may look like that
<datakid23> as per pastebin above
<lifeless> but dpkg, like apt, has no direct involvement with the kernel or those files.
<datakid23> it's true - but the problem isn't with the kernel per se, it's with dpkg --configure isn't it?
<lifeless> try dpkg -P linux-image-3.2.0-31-generic linux-image-3.2.0-31-generic-pae
<jwi> datakid23: you're looking for http://packages.ubuntu.com/precise-updates/linux-image-3.2.0-31-generic ?
<datakid23> lifeless: weird. It didn't create anything new, but it has changed the errors in and apt dist-up
<datakid23> jwi: I believe I am, thanks!
<datakid23> lifeless: now it's complaining htat "dpkg: dependency problems prevent configuration of linux-image-generic:  linux-image-generic depends on linux-image-3.2.0-31-generic; however:   Package linux-image-3.2.0-31-generic is not installed."
<datakid23> of course, apt install and apt -f install on linux-image-3.2.0-31-generic fail
<lifeless> datakid23: does it fail the same way ?
<datakid23> yes
<datakid23> lifeless: for clarification, if you mean does the apt -f install fail in the same way as the dist-up fails, after having done dpkg -P... yes
<lifeless> datakid23: did it unpack linux-image-3.2.0-31-generic to disk again ? if so the file should have been written now...
<datakid23> lifeless: I'm still downloading the deb - I'm on the wrong side of a satellite connection (Tarawa, Kiribati)
<datakid23> We just upgraded our network and the students are off for the summer, so there's finally enough bandwidth to look into this :|
<datakid23> lifeless: the deb puts the ubuntu software centre into a infinite loop of fail
<datakid23> will need to unpack/install via cli I think
<datakid23> lifeless: ok, done, and I repeated your dpkg -P line from above, and I now have a vmlinuz-generic and initrd.img-generic but no generic-pae for this kernel 
<datakid23> the number of errors has significantly reduced
<datakid23> which is nice
<datakid23> but it still fails
<lifeless> datakid23: -pae is a separate package
<lifeless> datakid23: you may need to repeat with that
<datakid23> lifeless: I know I was just coming here to facepalm
<lifeless> :)
<datakid23> apols :)
<datakid23> lifeless: and jwi: thanks! All sorted
<datakid23> apt get upgrade runs without error
<datakid23> wahoozi
<datakid23> ok, reboot time - out
<zequence> apw: infinity: I was testing linux-lowlatency precise-proposed. Accelerated graphics failed during first boot. Works now, after installing linux-generic (was going to see if it had the same problem). 
<zequence> I'm not much help tracking down errors. Any tips?
<infinity> zequence: I'm assuming that was because you didn't have headers installed and thus didn't get a dkms module build for your nvidia/fglrx drivers?
<infinity> zequence: How were you testing?  Just by installing "linux-image-$foo"?
<zequence> infinity: Intel graphics
<infinity> Oh.
<zequence> I just did a dist-upgrade to get the newer version (from proposed)
<infinity> Define failed...
<infinity> X went into crazy safe mode antics?
<zequence> Seemed ok, but gnome-shell went into fallback mode
<zequence> hmm, I accidentally went through recovery boot before I resumed normal boot though
<infinity> When you say "Works now, after installing linux-generic", do you mean that linux-lowlatency now works after installing linux-generic, or that you're currently running generic?
<zequence> linux-lowlatency works now, after installing -generic
<zequence> And -generic worked also
<infinity> Kay, then installing generic probably didn't fix/change anything.
<zequence> infinity: I just retried booting into recovery mode first, then resume normal boot
<zequence> That's what did it
<zequence> no accelerated graphics
<infinity> zequence: Okay, so totally unrelated to the kernel update.  Good to know.
<infinity> zequence: Possibly still a bug, mind you, but not an issue with the SRU. :P
<zequence> infinity: Yeah :). So, I'm looking at the kernel-sru-workflow at the wiki, but if I'd try a shortcut and ask you directly. I've booted the kernel for precise. Anything else I should try? And, should I change a status in the bug for the kernel?
<infinity> zequence: Andy and I are going to have a talk with bjf about how best we should be mangling the verification tasks for those bugs.
<infinity> zequence: For now, just dumping your comments in the tracking bug "smoketested lowlatency/i386, lowlatency-pae/i386, lowlatency/amd64 and it worked fine" (pick whatever kernel(s) you actually tested), we'll figure out proper process for next time.
<zequence> infinity: All right
<ppisati> brb
<apw> infinity, ok i've boot tested all 5 and put testing results in the bugs
<infinity> apw: Shiny.
<infinity> apw / zequence: Okay, so.  I think I've come up with something sane here without needing to talk to bjf, just from looking at how other derivatives are handled.
<infinity> The "Verification-testing" task should have someone quickly check and see if -lowlatency fixes any bug other than the ones fixed by master.  If not, set it to Fix Released.  If yes, verify them first, then Fix Released.
<infinity> And we should use Regression-testing to indicate that the install/reboot smoketesting has been done.
<infinity> apw / zequence: ^-- Seem reasonable?
<apw> infinity, seems a valid semantic to me, so mostly verification == noop as there are no patches, but if there are there is something to use
<apw> and r-t tells us it has been tested by someone to boot, ack
<infinity> Right.
<infinity> Also, the bot has a hissy fit if you don't set "qa-testing-passed" as a tag when setting Regression-testing to Fix Released.
<infinity> (I'm going to do all of this right now on the two current bugs)
<infinity> So, in an hour or two, while I slumber, the bot should update all of this and set my SRU releasy tasks appropriately.
<apw> sounds good
<apw> we need to get the thing to add that tag when missing :)
<infinity> Well, it's looking for qa-testing-passed or qa-testing-failed and assuming the QA engineer is a doofus if it finds neither.
<infinity> Which is probably a sane safeguard for Canonical-maintained kernels.
<infinity> Maybe overkill for others.  I dunno.
<infinity> Oh, depending on when Shankbot's "Friday" starts, it might not update the release tasks.
<infinity> I guess we'll see.
<infinity> It'll get around to it by Monday, at any rate. :P
<apw> heh
<infinity> Oh, look at that, Shankbot doesn't think it's Friday yet.
<infinity> apw / zequence: Releasing those kernels now.
<infinity> rtg: Any idea what the verification status of your linux-firmware/precise SRU is?
<infinity> rtg: (Or if you can hunt people down and find out?)
<rtg> infinity, bug # ? it has perhaps been so long that I've forgotten.
<infinity> rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1024884
<ubot2> Launchpad bug 1024884 in linux (Ubuntu) "Bluetooth with AR9462 WLAN/BT-Combo don't work" [Medium,In progress]
<infinity> rtg: The bug log is pretty messy.  I get the impression the firmware update is mostly a no-op without a matching driver update...
<rtg> infinity, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1024884/comments/68 indicates that it might work...
<ubot2> Launchpad bug 1024884 in linux (Ubuntu) "Bluetooth with AR9462 WLAN/BT-Combo don't work" [Medium,In progress]
<rtg> infinity, they are new files, so it would be hard to regress methinks
<rtg> you'd think the cert dudes would notice since the added a blocks-hwcert tag
<infinity> Yeah, that's what I was thinking.
<rtg> hell, they added that tag yesterday
<infinity> I'll leave it over the weekend and ping them next week for some definitive "yeah, it's working for us" before I release it.
<rtg> wfm
<infinity> I just want the kernel SRU report to be empty. :P
 * rtg pushes rebase to v3.8-rc4. apw, ogasawara
<apw> rtg cool
<rtg> apw, build testing...
 * henrix -> lunch
<rtg> herton, ~/kteam-tools/stable/create-release-tracker: Exception: linux-3.8.0-1.5: can't figure out the distro series for it.
<herton> rtg, looking
<herton> rtg, please pull kteam-tools and try again, not tested but I think I fixed it
<rtg> herton, looks like its working
<herton> ok cool, let me know if it something else breaks
 * herton -> lunch
<diwic> the directory structure under /lib/modules/<version>/ changed between quantal and raring seems to have changed, is this intentional?
 * ogasawara back in 20
<diwic> ah wait
 * diwic just forgot to install linux-headers.
 * apw whines at sforshee
<rtg> herton, so that tracking bug will puke out an upload message as soon as 3.8.0-1.5 is done building, or when it is accepted ?
<apw> sforshee, i am seeing all sorts of badness with 3.8-rc3 raring on brcmsmac, locking up and generally going bad
<sforshee> apw, any errors in dmesg to share?
<sforshee> apw, this one has never worked well with brcmsmac, right?
<apw> sforshee, a couple i have seen transmit failures and not recovered, others i have seen upsetness
<sforshee> apw, do the errors say something about MI_TFS and then reset the hardware?
<sforshee> I was working with broadcom on that one, but last I heard they suspected a ucode problem
<apw> Jan 18 15:05:01 localhost kernel: [ 7538.086453] brcmsmac bcma0:0: queue 7 >= NFIFO
<apw> Jan 18 15:05:01 localhost kernel: [ 7538.086478] brcmsmac bcma0:0: MI_TFS: fatal
<apw> Jan 18 15:05:01 localhost kernel: [ 7538.086494] brcmsmac bcma0:0: wl0: fatal error, reinitializing
<apw> sforshee, so yes ... :/
<apw> but i have been using brcmsmac for the last 3-4 releases ok, and its only in 3.8 i have this poppage
<apw> oh has tim given me new shiney microcode
<sforshee> I don't think so
<sforshee> it's more that something changed in the driver to expose the bug
<rtg> apw, no changes for brcmsmac in -rc4
<sforshee> at least that's the theory
<apw> sigh
<sforshee> there's corrupt data in the tx status we're being handed from the ucode
<apw> qualtiy
<sforshee> it's show up in various manifestatins
<sforshee> *manifestations
<apw> well it is cirtanly utter broke for me
<sforshee> I'll ping broadcom about it
<apw> thanks
 * rtg notices that a Lenovo x120e now beeps just before S3
<sforshee> apw if they haven't made progress I'll start a bisect, as I can reproduce one minor instance of that problem in a contrived scenario
<apw> sforshee, ok thanks
<sforshee> apw, what's your wireless card?
<herton> rtg, when it enters proposed in the archive, I believe it'll be when it's accepted
<sforshee> apw, you did try brcmsmac in 3.7 and didn't see those problems?
<rtg> herton, ack
<herton> rtg, I assigned the tasks there to in progress, otherwise the bot will not act, I have yet to fix this so the bot automates more of it
<arges> jsalisbury: hi
<jsalisbury> arges, hey
<arges> jsalisbury: so bug 1097396 i bisected down to the bad commit, reverted it and things works fine now
<ubot2> Launchpad bug 1097396 in linux (Ubuntu Precise) "Unplugging USB Headset causes Kernel Panic" [High,In progress] https://launchpad.net/bugs/1097396
<arges> jsalisbury: however i'm still looking for a solution that isn't a revert
<jsalisbury> arges, ack
<jsalisbury> arges, maybe see how it was fixed in 3.3 and see if that can be backported?
<arges> jsalisbury: yea trying to do that... git blame on yields patches that seem to alrleady be in stable
<jsalisbury> arges, hmm
<jsalisbury> arges, maybe the fix is already queued for 3.2 and just hasn't made it yet.
<arges> jsalisbury: you mean in master-next ubuntu-precise
<jsalisbury> arges, maybe here: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
<jsalisbury> arges, did you find a specific commit that fixes the bug?  
<arges> jsalisbury: ok i'll test that
<arges> jsalisbury: yea i did its on the bug
<jsalisbury> arges, commit 10e44239f67d0b6fb74006e61a7e883b8075247a had a CC to stable, so if that is the fix, it should make it into 3.2
<arges> jsalisbury: yea that doesn't fix the issue
<arges> jsalisbury: so that's already in 3.2.0-36
<jsalisbury> arges, ahh, ok
<arges> jsalisbury: anyway i'll keep poking at this
<jsalisbury> arges, cool
<herton> arges, jsalisbury: this is looking like a buggy backport of the patch you reverted. The commit causing the problem was a backport sent to the stable mailing list for 3.2, it differs in some parts to the mainline commit
<arges> herton: ahh. this might be the issue then
<arges> herton: should I try to re-backport it?
<arges> herton: or send a mail to the stable list explaining that the stable patch is buggy
<herton> arges, this was the thread with the set of backports: http://www.mail-archive.com/stable@vger.kernel.org/msg22850.html
<herton> arges, better send an email I think
<arges> herton: ok i can do that. for the time being should we revert in ubuntu?
<herton> arges, perhaps, if we don't get a solution until next SRU time frame we could do it
<arges> herton: ok i'll start with an email
<jsalisbury> herton, arges, ack
<arges> ok sent
 * ppisati -> EOW
 * rtg -> lunch
 * cking -> EOW
 * henrix -> EOW too!
<thotypous> hi, i've found a bug on 3.5.0-22-generic (which wasn't present on 3.5.0-21-generic), is this the correct place to report: https://bugs.launchpad.net/~ubuntu-kernel-team ?
<thotypous> I didn't check if it is upstream (I only tested Ubuntu kernels, not vanilla kernels)
<herton> thotypous, use this one: https://bugs.launchpad.net/ubuntu/quantal/+source/linux/+filebug
<herton> thotypous, actually like said in the link, use ubuntu-bug linux on a terminal on the affected machine
<thotypous> herton: thank you
 * rtg -> EOW
#ubuntu-kernel 2013-01-19
<Kano> hi, could somebody fix the build problem of ndiswrapper?
<mjung> Hi. I am having a lot of pain with my Intel HD2000 graphics in the Quantal stock kernel (3.5.0-22). Before start building a kernel.org vanilla kernel I wondered whether there are any repos that I should try first?
<freedomrun> mjung, http://kernel.ubuntu.com/~kernel-ppa/mainline/
<penguin42> Seem to be having a bunch of people walking into crypto+CIFS oops - bug 1070256 - can't get any of them to give a full set of logs though
<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
#ubuntu-kernel 2013-01-20
<ubuntu-tester> Just updated to 3.5.0-22 kernel. intel video driver failed to initialize. found in Xorg.0.log: "open /dev/dri/card0: No such file or directory". how do i troubleshoot this further?
<ubuntu-tester> Just updated to 3.5.0-22 kernel. intel video driver failed to initialize. found in Xorg.0.log: "open /dev/dri/card0: No such file or directory". how do i troubleshoot this further?
<howefield> hi elfy :)
<ubuntu-tester> After updating to 3.5.0-22 kernel on Quantal most drivers are not loading, including video, sound, eth, wireless etc. With 3.5.0-21 kernel everything is fine.
<ubuntu-tester> How do i troubleshoot this?
<ubuntu-tester> People, if this channel is not right place for such problems, please tell me where to go!
<Kano> hi, why is CONFIG_HOTPLUG in 3.8 kenrel config when it was removed?
 * lamont wonders who knows kvm bridge networking
<nerdopolis> Is there a reason why on virtualbox, when I start the Kubuntu 12.10 Live CD on Virtualbox, I have no /dev/fb0, and vesafb isn't loaded? And I only get /dev/fb0 once I INSTALL the live environment CD onto VirtualBox,
<Jef91> Where can I find package sources for these packages? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7.3-raring/
#ubuntu-kernel 2014-01-13
<ppisati> yo!
 * ppisati -> goes for some more coffee...
<smb> ppisati, You are a weird person. Rising much too early for a Monday morning. :-P
 * smb may just get done with cup #1
<ppisati> smb: after the christmas/end of year vacation, i'm trying to get back to my early schedule... not as easly as i would like to, but i'm getting there... :)
<smb> Bah. Who ever would want an early schedule... and even voluntarily
<ppisati> :)
 * apw finds he gets more done if he can drag self out of bed earlier
<smb> apw, You mean before us steals your time with idle chatter. :)
<apw> smb, hehe ... before i feel compelled to read email actually
<smb> apw, Don't destroy all my believe. You actually read email sometimes. 3:-)
<apw> *slap* ... i do, just not yours
<brendand> am i missing something, that there are no kernels on : http://people.canonical.com/~kernel/reports/sru-report.html
<apw> brendand, everything seems to be released indeed.  wasn't this cadance cycle extended by a week to allow settling for 12.04.4
<brendand> apw, the last email said prep would start on the 6th
<brendand> seems like promote-to-proposed hasn't quite been done yet
<apw> indeed
<ppisati> seems like latest T kernel is not happy on omapX:
<ppisati> [   18.513641] [<c068a640>] (panic+0xa0/0x1f4) from [<c0055be4>] (complete_and_exit+0x0/0x1c)
<ppisati> ...
<ppisati> uhm
<apw> ppisati, sounds like you get to have some fun today
<apw> ppisati, it has a heap of config updates in it, but they in theory are for ppc64el not for arm
<apw> ppisati, any luck :)
<apw> rtg, fyi i pushed an -rc8 rebase which is working fine here on my lappy, not uploaded it yet as the previous upload hadn't made it out even :)
<apw> (though it has now)
<rtg> apw, cool
<apw> though i am a bit supprised to be seeing -rc8 and not final
<rtg> Linus said he was gonna do an -rc8 being at Linux conf AU and all
<apw> ahh he is traveling, yeah
<rtg> apw, I'll prolly get the trusty LTS uploaded to the c-k-t PPA today
<apw> ok
<ppisati> apw: not yet, but i suspect it's a problem between an old bootloader and the new kernel
<ppisati> apw: latest T works fine on other arm hw though
<apw> ok
<apw> henrix, i have re-wacked the ti-omap4 cves in trusty and added support to keep them so
<henrix> apw: ack, thanks
<apw> henrix, and for completeness lts-raring-next is now being used
<henrix> apw: oh, that also makes sense ;)
<rtg> apw, any reason not to upload the -rc8 rebase ?
<apw> rtg, none that i know of, i was mearly waiting for the previous version to clear on sunday
<rtg> apw, ok, then I'll finish packaging and do some test builds
<rtg> apw,  -2.18 will clear before this pile is ready
<apw> rtg, yeah it has all cleared out now
<apw> as in all in -release now
<rtg> apw, cool. I pushed the changelog, but haven't tagged yet
<apw> great
<apw> BenC, any luck with the 3.13 rebase ?
<jdstrand> minor nitpick> I think the kernel scripts may be adding trailing whitespace to CVEs
<jdstrand> eg:
<jdstrand> '-devel_linux-ti-omap4: needs-triage'
<jdstrand> '+devel_linux-ti-omap4: ignored '
<jdstrand> that is when performing an import from the kernel tree
<jdstrand> eg, active/CVE-2013-2929
<apw> jdstrand, that'd be my fault
<apw> jdstrand, should be fixed now, for new ones it flips, which is just that ti-omap4 which has not yet gone
<jdstrand> ok, thanks :)
<apw> jdstrand, i added a new phase to wack 'ignored' releases, and got it wrong :)
<BenC> apw: In progress. Sorry, traveling to Dallas tomorrow and that's slow me down a bit. 
<apw> ok thanks
<apw> just making sure i didn't miss it somewhere
 * apw wanders to where there is beer
#ubuntu-kernel 2014-01-14
<ppisati> yo!
<apw> ppisati, yogurt
<ppisati> apw: "i'm just plain yogurt!"
<ppisati> let's see who get the citation :)
<smb> hail scrooch?
<ppisati> who?
<smb> Not exactly sure how the guy was spelled. The one trying to steal all air
<smb> Ah, "Skroob" obviously
<apw> 'balls
<ppisati> anyway, it was spaceballs! :)
<smb> That's what you get for living in a country that dubs all movies
<ppisati> http://www.youtube.com/watch?v=sen8Tn8CBA4
<ppisati> (ok, not that scene, but hilarious nonetheless)
<smb> Yeah, a classic
<smb> And for a total evil abuse of Skroob quotes: "Did it work? Where's cking?" :-P
<apw> rsalveti, ok uploaded linux-mako to the ckt ppa
<apw> rsalveti, let me know if that sorts you out
<rsalveti> apw: kernel seems fine, thanks!
<apw> rsalveti, good news
<apw> are you wanting it in the archive ?
<rsalveti> apw: not yet, for that to happen I need to first finish the 4.4 porting (just got the first image for mako)
<rsalveti> hopefully by the end of this week
<rsalveti> but keep it in the ppa for now
<apw> rsalveti, i'll package up teh associated linux-meta and push it into the ppa as well
<rsalveti> apw: great, thanks
<apw> rsalveti, ok meta updated as well
<rsalveti> apw: great
<smb> dpk
 * smb hums the focus mantra
<apw> sforshee, that bluz thing, i think i looked at, and i conjectured it was a platform where the bluetooth device is powered down when 'rfkill' is applied hense the race is presnet on every switch or s/r attempt
<sforshee> apw: yeah, it's a usb device and I think it's probably disconnected from the bus on rfkill, but the logs are insufficient for me to be sure
<apw> yeah, note we asked for htem in october
<sforshee> but the drivers come from some random compat-drivers build whose version says something about 3.10-rc1
<apw> oh jolly dee ... i suggest we mention that in the bug, and re-request testing and log collection then
<sforshee> I'm in the process of adding a comment
<apw> to see if it has gone away with the 30 or so updates isnce hten
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<smb> xnox, On chinstrap:~smb/dmraid is a version I fiddled around with (beside other things this one won't bother with imsm and not use dm-raid45). There is one drawback which is dm-raid does not accept an offset for raid member devices. Which in theory should be ok as meta-data seems to reside at the end of fake raids and the current code should at least bail out if that is not true.
<apw> smb, hey is that the dmraid userspace switched to use the supported kernel side
<smb> apw, yup
<apw> nice
<smb> Though I could only test with intel msm and that I removed in a later patch... :-P
<apw> heh .. you removed it ;)
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<smb> ogasawara, Oh hm, just remember the iscsitarget package. I did a backport version of the Saucy code and kind of started a MRE for it. Just not exactly sure whether or what this is waiting on. I believe I wrote slangasek some email but cannot remember hearing anything back. Usually I forget to ask him directly at an appropriate time of day... Well now I did
<smb> (that is for precise)
<ogasawara> smb: ack, thanks for the update
<slangasek> smb: it's not an MRE, an MRE is when you want a standing exception; this should just be done as an SRU
<slangasek> it may be an exceptional SRU, but we can deal with that without the SRU team
<smb> slangasek, Ah ok, shall I modify the lp bug with different wording?
<slangasek> smb: well, most important is to upload the package to the queue :)
<smb> slangasek, which I need sponsor for
<smb> :)
<smb> I really really need to get my act together and complete that self-bullshitting page to apply for core-dev
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 21st, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<BenC> apw: Rebase complete. Running test build and will boot test shortly.
<apw> BenC, lovely, when you are happy shove it in the saucy repo and i'll grab it
#ubuntu-kernel 2014-01-15
<phillw> Hi, whilst not 100% kernel, when we do test (or are asked to test) we often need a kernel and a build.. So, https://launchpad.net/~jsalisbury have you any idea why kernel team can build ISO's and https://answers.launchpad.net/ubuntu/+source/debian-cd/+question/240037 gets closed?
<phillw> Oh, and please do not think that is me being harsh, Joe is a complete and utter star for the work he did for the zram issue in such short time. 
<rsalveti> apw: you published the meta package for saucy (linux-mako, ppa), mind copying it for trusty as well?
<ppisati> hallo
<smb> ppisati, Gudda morga
<apw> rsalveti, bah... will do
<apw> phillw, that question gets closed by the launchpad autocloser cause noone did anything with it in 15 days, that seems to be a "feature" of questions; building CDs is a complex process and has changed in the last cycles to match upstream supported tooling.  as far as i know the appropriate tooling does exist in published repos, but it is slightly outside the normal archive system so some of it may not
<apw> be at all obvious
<apw> phillw, as for what joe did, most likely what he did was sub in a replacement kernle into an existing CD which with a lot of playing can be done in a "dirty" way, but you would have to ask him.
<apw> phillw, it is unlikely he is mastering a cd the way the main builders do, as they have dedicated kit to do so currently
<apw> phillw, all of that said, you are likely to find more authorative answers from the installer team 
<brendand> does anyone know why the -proposed kernels haven't been copied yet even though they've been ready since friday?
<apw> i believe there is a delay in the point release which is in the way, but i would not like to claim to be cirtain
<smb> apw, I think that is exactly what bjf was saying in yesterday's kernel-team irc meeting
<apw> smb, ahh yes there was "Holding" all over the place
<apw> smb, though i blinked and missed it with the meeting
<smb> apw, True, the email Joe sends out is more reliable as a data source
<smb> https://lists.ubuntu.com/archives/kernel-team/2014-January/037696.html
<apw> brendand, ahh there it is: "We are in a holding pattern waiting to see if any regressions show up that would cause us to respin before the 12.04.4 release goes out."
<brendand> apw - okay - but the kernels aren't in -proposed so how will regressions be detected?
<apw> brendand, that refers to the previous kernels which are in -proposed/-updates; though technically it presumably only means that for precise 
<apw> though i guess that is actually saucy as well as we're using the lts kerenl on the cd
<apw> this is about leaving a window where we can pick up whats in the -updates pocket and rev that separatly from what we are staging for the next cycle
<cking> oops, rebooted the wrong machine
<apw> cking, that is an oops ... especially when it has been running that test for 3 days
<cking> unfortunately the ssh session I was in exited and thus I didn't reboot the machine I intended to reboot
<apw> cking, i hate that when it happens
<apw> as you always notice after you have asked your fiinger to press return but before it has done so, but there is no stopping it
 * cking wonders why ACPICA always gets released the day before fwts is, I can never get these in sync
<apw> cking, you need an entire cycle to get apica working again anyhow
<apw> it always has new 'features'
<cking> well, a bunch of fixes, so it's new and shiny and good ;-)
<apw> yeah but out of sync with the releases is probabally good, so you have time to adapt :)
<cking> cadence cadence cadence
<smb> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269401
<ubot2> Launchpad bug 1269401 in linux (Ubuntu) "[Trusty] Switching framebuffers fails on VMs using cirrus" [Undecided,Confirmed]
<rtg> apw, suspend stopped working on my Lenovo within the last couple of uploads. I'm gonna have to spend part of the day figuring that out lest it drive me nuts.
<cking> rtg, is that suspend or resume?
<rtg> cking, it is suspend, but now its working with -rc8. oh well.
<henrix> rtg: looks like you forgot to apply my last patch to the Lucid kernel
<rtg> henrix, uh, wich one ?
<henrix> rtg: b4789b8e6be3151a955ade74872822f30e8cd914 ("[Lucid][LTS-Raring][CVE-2013-6380] aacraid: prevent invalid pointer dereference")
<rtg> henrix, right, sorry.
<henrix> rtg: np ;)
<rtg> henrix, done
<henrix> rtg: ack, thanks
<apw> henrix, if these stables exist is there anything which prevents them being applied to master-next btw ?
<henrix> apw: not sure i understand what you mean... are you talking about the CVEs fixes?
<apw> henrix, no i was thnking about this fix which i proposed and is coming down from stables in fact
<apw> or have the stables themselves not yet released with that in
<apw> as i looked for the commit on master-next on the assumption if they were in stable they weould be on ther
<apw> e
<henrix> apw: ah, right :) no, the fix can be applied.  bjf (or sconklin) will handle that when merging the stable trees into the ubuntu kernels
<henrix> apw: i believe there are scripts to handle that
<apw> henrix, i don't need to apply it cause i know the sta
<apw> stables will apply it in the next window anyhow, i was more trying to work out what triggers stable to be applied
<henrix> apw: there are several sources. the primary source are the commits tagged for stable
<henrix> apw: then, for network-related patches, davem explicitly sends requests to the stable mailing list (there are no network commits tagged for stable!)
<henrix> apw: this also applies for sparc patches
<rtg> apw, if you apply it, then you can also jam a bug number in the commit log
<henrix> apw: and then... there's stable mailing list.  people keep sending requests for stable inclusion (CVE fixes, fixes that missed the stable tag, etc)
<brendand> bjf, hi
<brendand> bjf, can you clarify when the kernels are going to be pushed to -proposed? i understand you're holding them because of 12.04.4
<rtg> henrix, please have a look at https://bugs.launchpad.net/bugs/1268780 - that commit looks like a candidate for 3.11 stable
<ubot2> Launchpad bug 1268780 in linux (Ubuntu) "Please backport the "libata.force disable" patch to 13.10 kernel" [Medium,Triaged]
<henrix> rtg: looking
<rtg> henrix, ah, nm. you are already on it
<henrix> rtg: yep :)
<BenC> apw: Working through a few build errors (mostly missing include for of_address stuff that got moved)
<apw> BenC, sounds promising
<brendand> bjf, around?
<bjf> brendand, just
<bjf> brendand, well.. no i can't actually. we have not found any regression at this point that would cause a respin so i don't think it will be much longer.
<bjf> brendand, and yes i know this messes with everyone's schedule.. we'll just be flexible about it and when the next cycle starts
<brendand> bjf, by the end of the week?
<bjf> brendand, probably next week
<brendand> bjf, ok
<brendand> bjf, are all of them being held to the same extent? i would have thought you'd just be concerned with the saucy kernel
<bjf> brendand, yeah, we're holding them all right now . we could just hold saucy but we like to maintain a single sru cycle that has them all. if we do them individually it could get more messy schedule wise. (which one am i doing this week)
<brendand> bjf, makes sense
<bjf> brendand, honestly, we should have just skipped this entire cycle
<bjf> brendand, i sort of screwed this up
<rtg> cking, have you had any luck reproducing the 3.13 performance issues on tangerine ?
<cking> rtg, I'm still gathering data on some other kit at the mo to get an idea
<rtg> cking, cool
<cking> it does involve a load of builds to get some idea what's going on
<rtg> yup
<cking> rtg, perhaps we should also cull a load of unused files on the device just for the sake of cleaning up the drive anyhow
<rtg> cking, on tangerine ?
<cking> yup
<rtg> I do periodically hassle folks. is it full again ?
<cking> 75% or so, so its not too bad
<cking> rtg, anyhow, I'm still gathering data on some boxes, I may get an idea tomorrow once I've collated the results
<rtg> cking, I generally don't start to worry until 95% or so. do you think a 75% full file system will have an impact ?
<cking> rtg, most probably not the issues you see
<rtg> cking, shall I update the kernel to 3.13-rc8 ? 3.13.0-3
<cking> rtg, well, it's another data point I guess
<BenC> apw: I think I've fixed them all...letting all 5 builds go before claiming victory
<rtg> cking, didn't want to mess with your results or testing
<cking> rtg, how about tomorrow, I want to get a spin on it tomorrow morning when it's quiet
<rtg> cking, np
<lamont> I have a machine booting (root is an lv on swraid1) that keeps telling me "WARNING: Thereappears to be one or more degraded RAID devices", spews mdstat showing the rcovery in progress (eta 137 min), says that it's starting it, complains that CREATE {user_root,group_disk} not found, says that it started the RAID in degraded mode, and then pauses for several seconds and repeats.
<lamont> is that the "don't boot with degraded RAID" crap, or something else, I wonder?
<rtg> smb, ^^
<apw> smb, ^^ ... oh heh
 * apw relocates
<smb> lamont, Donboot would drop into busybox shell imo (not that I had that case)
<lamont> ok. sigh
<smb> lamont, But maybe it is actually what you say.
<lamont> it`s also possibly me..
<lamont> I don't remember if I rebooted after I did all my shenanigans to partition the new drive and add it to the raid1s
<lamont> another 45 min or so, and I can see where I'm at... if this is really hating me, are you around then for me to pester with mdadm questions, or am I reading source/
<lamont> ?
<smb> Can you get the actual /proc/mdstat output 
<lamont> it's on the screen in front of me
<lamont> recovery = 87.1%.... finish=36.6
<lamont> min
<smb> lamont, Well I could try to be around if you get my attention then
<lamont> ta
<lamont> hopefully it'll just be to tell you that all is better
<smb> Heh, one always can hope
 * smb hope to get enlightened meanwhile what d-i option finally causes the partitions to be re-done with the preseed
<lamont> smb: it was either me, or strange...  fixed by: lvm vgscan; lvm lvdisplay -C (root not active); lvm lvchange -a y ${ROOTlv}
<smb> lamont, quite weird. cannot remember ever having to activate an lv manually
<lamont> smb: I deactivated it manually after I chrooted into it to fdisk the new drive
<lamont> hence "lamont" is the most likely root cause here
<smb> Sounds like deep surgery . A bit more than I usually do for my "servers" which actually only serve one person
<lamont> well... it was being... difficult
<lamont> note to self: do not have the ilo(equivalent) on your dhcp server use dhcp to get an address. :/
<sforshee> hallyn: is ns_capable(&init_user_ns, CAP_SYS_ADMIN) equivalent to capable(CAP_SYS_ADMIN)?
<hallyn> sforshee: hes
<hallyn> yes
<sforshee> hallyn: thanks
#ubuntu-kernel 2014-01-16
<ppisati> 1 2 3 test...
<smb> ppisati, nobody is here to hear you screaming. :)
<ppisati> nobody can hear you scream! :)
<ppisati> let me start mumble so you can hear it at least... :)
<smb> Heh
 * apw yawns
 * apw has a vision of ppisati being attached to large electrodes ... bzzzzztttt
<RAOF> Bees!
<apw> RAOF, Beeeees :)
<phillw> hi, please do not laugh :P when using make to compile a kernel up, how do I specify which .config file to use? 
<phillw> I've made what I believe are the changes I want using menuconfig and saved the resulting file as .myconfig
<phillw> sorry about that, the build a new kernel cooked my laptop! I'm stansferring over to the dedicated server :)
<eagles0513875> apw: re the multitouch patch can you follow up as I never got a response on the kernel input mailing list and it has been more then a few days
<rtg> apw, 3.13.0-3 seems to have wrecked my user experience on a Dell M1710. nouveau crashes almost immediately.
<apw> rtg, woh unexpected, was there anything much in there at all ?
<rtg> just the rebase to -rc8 AFAICT
<rtg> -2 works fine
<rtg> guess I'll try the vanilla kernels first
<apw> rtg, when you say crash does it bug ?
<rtg> apw, all I get is the tail end of the stack dump
<apw> arses
<rtg> can't tell if its bugging or not
<apw> is it locked so hard you cannot get in ?
<rtg> yup
<apw> phillw, depends if you are talking about a "make" in a mainline tree where it uses .config, or a debian package where it is "harder"
<apw> rtg might be worth seing if you can boot it without graphics and the ssh in tail -f /var/log/syslog and then start X
<phillw> apw I was at http://bodhizazen.net/Tutorials/kernel#easy and had worked out which pentium chips I wanted etc.... then headed to http://bodhizazen.net/Tutorials/kernel#Compile but suspect that I need to tell that command the name of my .config file?
<rtg> apw, ack - rebooting to vanilla -rc7 and -rc8 just to be sure
<rtg> apw, the last line printed with vanilla -rc8 is :
<rtg> drivers/video/fbmem.c:                  printk(KERN_INFO "fb: conflicting fb hw usage 
<rtg> that is without the  splash screen
<smb> Hey that sounds a bit like the framebuffer eject problem all over the place again
<rtg> smb, weren't you looking at a bug like that ?
<smb> rtg, VMs and cirrus
<rtg> hmm
<smb> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269401
<ubot2> Launchpad bug 1269401 in linux (Ubuntu) "[Trusty] Switching framebuffers fails on VMs using cirrus" [Medium,Confirmed]
<smb> I was told there should be a user-space fix that prevents load of the generic fb for certain cases
<smb> In theory also cirrus but something seems to have gone amiss
 * henrix remembers something like that on lkml...
<smb> Main problem is plymouth doing something with the current fb even without splash
<smb> So releasing the current one for another one cannot free resources
<apw> rtg, hrm, nasty
<rtg> apw, at least there are some google hits on that string
<apw> not sure why the -rc7->-rc8 would expose that any more than before
<rtg> apw, dunno. back in a asec, gonna migrate to my workstation so I can mess with this laptop and not disappear constantly.
<apw> rtg, any luck ?
<rtg> apw, uh, working on a couple of distractions. I'll get back to it in a sec
<phillw> smb rtg https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674 it goes back a lot further :) As no one will fix it, I just use the work around.
<ubot2> Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed]
<smb> phillw, Without looking into the bug... likely that is the background gfx issue when not using the cirrus drm driver... 
<smb> Which iirc is a bug in the cirrus x driver in conjunction with probably llvm-pipe + unity
<smb> and no nobody seems to care much about that
<phillw> smb I did run with that bug for a while, but there is a limit as to how many brick walls you wish to bash your head on :)
<smb> Sure and given the (not)performance of using llvm-pipe for 3d gfx anyway there seems to be a lost ground for running desktop in a VM (warning: very personal and opinion)
<phillw> smb I'm not a kernel person! but the word 'cirrus' causes my ears to pick up, as I still have to use https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674/comments/43 when installing desktop systems into KVM
<ubot2> Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed]
<smb> phillw, Right the current better option is to use a different virtual gfx card. If we can solve the race with the framebuffer you would have a kernel-mode-settting driver (the mentioned cirrus module) which then gets you X to use a generic kvm drivers which gives not corrupted gfx
<smb> *shat should be generic kms
<phillw> smb: like forrest gump, simple be, simple do. That work around works for me.. as to if https://bugs.freedesktop.org/show_bug.cgi?id=58574 will ever be fixed? Well, let's just say I'm not holding my breath :)
<ubot2> Freedesktop bug 58574 in Driver/cirrus "pixmap regression with cirrus graphics driver" [Normal,New]
<smb> phillw, Neither would I (hold my breath) :)
<phillw> he he,,, well, I'm back to build a kernel on a VM that will not over heat and shut down... I'll be able to state how 12.04lts server to 14.04 lts server goes when I have made a new kernel :)
<eagles0513875> apw: ping
<rtg> apw, -rc8+ may have solved the problem
<phillw> rtg: is it worth me trying http://bodhizazen.net/Tutorials/kernel and build a kernel, as the server spent 2 hours on upgrading to 14.04 and still has 3.8.0 as the kernel (NOT what I spent 2 hours waiting for)
<phillw> :)
<phillw> rtg: I have linux-3.13-rc8 on the VM.... your call :)
<rtg> phillw, you upgraded to trusty and you _still_ have the raring kernel ?
<phillw> rtg: indeed.... but that is a server test issue... i actually need trusty for a community respin
<phillw> rtg: ali@amjjawad:~/src$ uname -a
<phillw> Linux amjjawad 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<rtg> I assume you rebooted ?
<phillw> you assume correctly :)
<rtg> dpkg -l|grep linux-image
<phillw> ali@amjjawad:~/src$ Linux amjjawad 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<phillw> No command 'Linux' found, did you mean:
<phillw>  Command 'linux' from package 'user-mode-linux' (universe)
<phillw> Linux: command not found
<phillw> ali@amjjawad:~/src$ 
<phillw> rtg:  this worked better
<phillw> ali@amjjawad:~/src$ dpkg -l | grep linux-image
<phillw> ii  linux-image-3.8.0-29-generic                          3.8.0-29.42~precise1                                      amd64        Linux kernel image for version 3.8.0 on 64 bit x86 SMP
<rtg> cat /etc/lsb-release
<phillw> rtg: ali@amjjawad:~/src$ cat /etc/lsb-release 
<phillw> DISTRIB_ID=Ubuntu
<phillw> DISTRIB_RELEASE=14.04
<phillw> DISTRIB_CODENAME=trusty
<phillw> DISTRIB_DESCRIPTION="Ubuntu Trusty Tahr (development branch)"
<phillw> ali@amjjawad:~/src$ 
<rtg> phillw, you upgraded from 12.04 ?
<phillw> indeed, my best guess is that the server kernel was not allowed to update.... server kernels are funny things!
<phillw> server was 12.04.3
<rtg> phillw, hmm, I may know what happened. guess I'd better go fix that.
<phillw> that's fine. can you ping me on #phillw (in case I have left here) to let me know what to do to bring that test area for 14.04 "up to speed". many thanks :)
<BenC> apw: I'm having serious issues with 3.13. When it hits initramfs, I get immediate kernel stack overflow in random processes
<BenC> apw: Are you guys syncing to a newer -rc soon?
<rtg> BenC, we're up to -rc8 now. then next one should be the 3.13 release
<BenC> rtg: I may have rebased before you did -rc8. When was that?
<rtg> a couple days ago I think. apw did it
<BenC> Nope, I'm on rc8
<BenC> Let me check upstream tree and see if there's anything of interest
<phillw> rc8 is the latest they advertise on https://www.kernel.org/ no doubt, there is another link I should look at :)
<apw> BenC, hrm, thats very odd indeed stack overflow as in stack space exceeded implosions ?
<rtg> BenC, there is on poerpc patch after -rc8
<BenC> apw: As in, something is recursively going on inside the kernel, through a sys call from userspace
<BenC> Unsure if the details, because it's no certain process or syscall
<apw> rtg, perhaps we should do an interim re
<apw> rtg, perhaps we should do an interim rebase, if they sound plausible
<rtg> apw, I'm thinking about rebasing against tip for the nouveau fix
<apw> that said, i don't think this one powerpc fix can be relevant
<rtg> apw, it definitely blocks on console_lock() in -rc8, but works with tip. there are 4 patches that look to be of interest
<apw> but if you needed to do it for that ... that'd be worth it
<apw> as we are still rebasing and all
<BenC> I'll inspect the patches and see if it fixes me before rebasing on your update
<rtg> apw, you have anything in the pipe yu wanna commit ?
<apw> BenC, this doesn't look hopeful, it is all old h/w
<BenC> Ok, first I'll back out all of my sauce and see if that alleviates the issue
<BenC> Best to make sure of that first
<apw> rtg, nothing other than whats already pushed, i am trialing splitting out the hyper-v tools into their own tools package, might make maintenace easier and slim the virtual images
<rtg> apw, ack, then I'll package and upload
<phillw> if you guys would like a VM (OVH) I do still have a free one with unique ipV4. build it, break it as often as you wish :)
<phillw> rtg please give me a ping when you have it fixed (or a note to phillw@phillw.net ) It seams I now have a queue :)
<bjf[afk]> phillw, that's what bugs are for ... have you filed one?
<phillw> bjf[afk]:  Nope I did not, as rtg sated that he saw the issue, I saw no reason to "raise paper work". We are sill in alpha area and a chat is often better than a bug report.... unless some one wants to get into the "I closed most bugs" report.... which the kernel team do not play in :D
<bjf> phillw, "paper work" is for just such a thing .. so you get notified of fixes. this has nothing to do with bug-games people play
<phillw> bjf: I arrived here to ask a question, the question has been asked and an answer given. Had the person who is solving the issue wished a bug report to be raised, I'm quite sure he would have asked me to do so..... When it comes to devs... I approach quietly and do as I'm told :)
<phillw> bjf: I cannot file a bug for the in ability to move from 12.04 to 14.04 at kernel level. As it is a server, the log in sequence to try and register a bug is none working
<bjf> jsalisbury, we want to keep an eye on bug 1269917
<ubot2> Launchpad bug 1269917 in linux (Ubuntu) "Kernel GPF" [Undecided,Incomplete] https://launchpad.net/bugs/1269917
<jsalisbury> bjf, ack
<bjf> jsalisbury, that apport collect failed to capture dmesg. i've not seen that HookError_source_linux.txt msg before.
<jsalisbury> bjf, I haven't seen that one before either.  I'll see if it's happened before and keep an eye out for new ones.  
<jsalisbury> bjf, think I should request testing of 3.11.10.3 and or mainline in bug 1269917 ?
<ubot2> Launchpad bug 1269917 in linux (Ubuntu) "Kernel GPF" [High,Incomplete] https://launchpad.net/bugs/1269917
<bjf> jsalisbury, no, i want them to test this new saucy kernel once it gets built
<jsalisbury> bjf, got it, thanks.
<bjf> jsalisbury, with 700+ commits in it we might get lucky
<jsalisbury> bjf, yeah
<jsalisbury> bjf, looks like saucy-proposed will be at 3.11.10.3 anyway.
<bjf> jsalisbury, yes
<phillw> jsalisbury: i mentioned an issue earlier, but as the machine is in flux, I cannot fully raise a bug
<phillw> (16:19:56) rtg: phillw, you upgraded from 12.04 ?
<phillw> (16:20:50) phillw: indeed, my best guess is that the server kernel was not allowed to update.... server kernels are funny things!
<phillw> (16:21:26) phillw: server was 12.04.3
<phillw> (16:22:05) rtg: phillw, hmm, I may know what happened. guess I'd better go fix that.
<phillw> jsalisbury: I most likely have the log on the VM but cannor send them to you good people :(
<bjf> phillw, you can use: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug to file a bug from a different system if that helps
<jsalisbury> phillw, Would you be able to open a bug report manually at launchpad.net ?  You should be able to select Ubuntu as the distro and Linux as the package.
<jsalisbury> heh, or just follow the link from bjf :-)
<phillw> jsalisbury:  and bjf oh, i need to go password hunting :)
<phillw> ahh, wonderful... it requires GUI.... :(
<phillw> ali@amjjawad:~$ https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<phillw> -bash: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug: No such file or directory
<phillw> ali@amjjawad:~$ 
<jsalisbury> phillw, You would need to enter that URL in a web browser, not from the command line.
<phillw> jsalisbury: that is a server VM (KVM) is has no browser
<apw> lynx ?
<phillw> apw: the VM is a try to be 14.04, but the upgrade has messed up and it still have 12.04 kernel. 
<phillw> jsalisbury: scroll back to (12:12:39) UTC and do feek free to join #phillw to tell me off :)
<phillw> s/feek/feel/
<phillw> and, of course, being CLI... have no idea of the command to issue :)
<phillw> jsalisbury: Linux amjjawad 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<phillw> that does seem a bug when you issue dist-upgrade -d .... this does need resolving as it spends two hours doing things and leaves you with 
<phillw> ali@amjjawad:~$ uname -a
<phillw> Linux amjjawad 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<phillw> and 
<phillw> ali@amjjawad:~$  cat /etc/lsb-release
<phillw> DISTRIB_ID=Ubuntu
<phillw> DISTRIB_RELEASE=14.04
<phillw> DISTRIB_CODENAME=trusty
<phillw> DISTRIB_DESCRIPTION="Ubuntu Trusty Tahr (development branch)"
<phillw> ali@amjjawad:~$ 
<phillw> jsalisbury:  ^^
<infinity> phillw: apt-get install linux-generic
<infinity> phillw: And the migration path for lts-backport kernels is known to be a bit sketchy right now, we need to solve that.
<hallyn> sforshee: sorry i've not had a chance to test that patch myself, but it looked good to me (and i assume you've tested it yourself)
<hallyn> will install and test it tomorrow. 
<sforshee> hallyn: I have, but I noticed something today that makes me think there's something else going on
<sforshee> upstart opens console with O_NOCTTY, which should prevent it owning the tty
<sforshee> so I still don't know how upstart ends up owning that tty
<phillw> infinity: thanks, I'll try that. 
<hallyn> sforshee: ah.  interesting.
<hallyn> potentially a bug elsewhere then...
<sforshee> yeah, not sure where though
<sforshee> is there some way I could strace init when it starts in the container?
<phillw> infinity: no major errors, can I ask it to be a new kernel, or is it still too unstabe?
<infinity> phillw: It'll default to being the current kernel, and we're all running it.
<phillw> infinity: when I go to http://bodhizazen.net/Tutorials/kernel#easy for my non-pae kernel build how do I tell it to use the the .config file I want them it to use,?
<infinity> phillw: Read the paragraph you linked to me?
<phillw> infinity:  bohdi-zazen is on #phillw  -- much easier to chat there?
<infinity> phillw: Dude, you just asked me how to do the thing that that paragraph tells you how to do.  Pretty sure more chatting won't clear that up.
<phillw> infinity: and I install kernel 3.13 on to that 12.04 VM?
<phillw> that is what I'm awaiting for,
<infinity> phillw: What 12.04 VM?  You were talking about a 14.04 system above...
<infinity> phillw: Or, so lsb_release claimed.
<phillw> infinity: That is why you say what you say, and the bug team go "we do not believe you".... But, I actually believe bohdi-zazen who is on #phillw.
#ubuntu-kernel 2014-01-17
<jsalisbury> phillw, it would be best if you could open a launchpad bug, so we can track all the appropriate information.  You can open a bug using a web browser on any system(It doesn't have to be the system exhibiting the bug).  Again, just go to the following link: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<jsalisbury> Any system with Internet access that is.
<phillw> jsalisbury: my VM does not want to to play...... 
<phillw> jsalisbury: where do you need me to pull logs from? as it is a KVM I can pull any data you need.
<jsalisbury> phillw, the following commands will collect all the appropriate data:
<jsalisbury> 1) uname -a > uname-a.log
<jsalisbury> 2) dmesg > dmesg.log
<jsalisbury> 3) sudo lspci -vvnn > lspci-vvnn.log
<jsalisbury> 4) cat /proc/version_signature > version.log
<jsalisbury> phillw, what happened after you ran:  apt-get install linux-generic
<phillw> jsalisbury: there seems to have been a drop of support for kernel (and motu). We do have people who want to make community re-spins but some of the tools that they used are no longer there.
<phillw> jsalisbury: Hi Joe, this is the last I got from the VM
<phillw> root@amjjawad:/home/ali/src/linux-3.13-rc8# make oldconfigscripts/kconfig/conf --oldconfig Kconfig
<phillw> #
<phillw> # configuration written to .config
<phillw> #
<phillw> root@amjjawad:/home/ali/src/linux-3.13-rc8# 
<phillw> root@amjjawad:/home/ali/src/linux-3.13-rc8# apt-get install linux-generic
<phillw> Reading package lists... Done
<phillw> Building dependency tree       
<phillw> Reading state information... Done
<phillw> linux-generic is already the newest version.
<phillw> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<phillw> root@amjjawad:/home/ali/src/linux-3.13-rc8# 
<jsalisbury> phillw, Are you now running the 3.13.0-3-generic kernel (After a reboot) ?
<phillw> jsalisbury: the VM I'm working with is Linux amjjawad 3.13.0-3-generic #18-Ubuntu SMP Mon Jan 13 19:11:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
<phillw>  my machine is phillw@piglet:~$ uname -a
<phillw> Linux piglet 3.13.0-3-generic #18-Ubuntu SMP Mon Jan 13 19:11:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
<jsalisbury> phillw, ok, to summarize, you upgraded a server flavor from Precise running the 3.8 backport kernel to Trusty, but the kernel remained at 3.8.  But you were able to upgrade to 3.13.0-3-generic manually?
<phillw> I did a -d to ask the server to jump to 14.04.
<phillw> jsalisbury: correct
<infinity> jsalisbury: As it turns out, rtg just fixed that bug. :P
<ppisati> TGIF
 * apw yawns mightily
<smb> I am sure RAOF has mighty AUS BEEEES
<apw> who stole my bees?
 * apw notes .au does have above average bees
<eagles0513875> hey apb1963
<eagles0513875> i mean apw
<eagles0513875> are you around 
<eagles0513875> apw: i stole them i forgot to tell you 
<eagles0513875> lol
<apw> Sarvatt, was it you i was talking to about the gm45 "character square corruption" which looked like fence issues?
<apw> Sarvatt, as i have just upgraded userspace from S to T and it has gone away now
<apw> Sarvatt, though the tearing is appaling in chromium
<eagles0513875> apw: finally got a reply to the email about the multitouch track pad
<eagles0513875> apw: and the response is You mean that one?   http://www.spinics.net/lists/linux-input/msg26869.html  It never got applied, would be nice to hear whether that bug still exist and have it resubmitted.  Thanks David
<apw> eagles0513875, sounds like movement, was the original submitter on the thread, if not maybe time to poke them 
<apw> the patch has a lot of questions you might hope that the maintainers would reply on
<eagles0513875> apw: the original submitter i think is MIA
<apw> but ... seemingly not
<eagles0513875> i dunno if you could step in or not
<apw> it is very hard to own a patch when you don't have the h/w to test changes on
<eagles0513875> apw: i can test it but I have no idea what i would need to do to patch the kernel and recompile
<eagles0513875> well i have a site on how to do that but not sure how to go about it
<eagles0513875> apw: Would you be willing to help me out in this regard or am i a bit on my own
<apw> eagles0513875, we may have a amchine with the same h/w will investigate
<eagles0513875> apw: thanks I would though like to apply the patch for now to my existing kernel on 13.10
<eagles0513875> apw: going to update the bug from the response i got in the email
<apw> eagles0513875, canyou confirm this is a lenovo L530
<eagles0513875> im not on a lenovo
<eagles0513875> im on a toshiba sattelite s75-A7221
<apw> and you know htat patch fixes your issue ?
<apw> eagles0513875, ^^
<eagles0513875> apw: i need help patching the existing kernel to test it as i dont know how to patch my kernel as well as recompile it
<eagles0513875> apw: would it be possible for you to provide a testing kernel somewhere for me to install and test
<apw> eagles0513875, is there a bug number for this?
<eagles0513875> apw: for the upstream bug
<eagles0513875> the only bug i have is the launchpad one linking to the discussion upstream previously 
<apw> which is which one
<eagles0513875> apw: this is upstream http://www.spinics.net/lists/linux-input/msg26869.html
<eagles0513875> on launch pad its bug 967399
<ubot2> Launchpad bug 967399 in linux (Ubuntu) "[11.10] Elantech trackpoint does not work Lenovo " [High,In progress] https://launchpad.net/bugs/967399
<rtg> smb, have you been running trusty kvm sessions lately ? I just upgraded from 12.04.2 to trusty and it appears to have wedged.
<smb> rtg, KVM installs only not upgrades
<rtg> smb, hmm
<smb> I mean Trusty server installs
<rtg> smb, right, thats all I'm doing to
<rtg> guess I'd bettercheck that the daily works
<smb> rtg, You are using a raid1 by chance?
<rtg> nope
<smb> Ok, that was one piece that has issues currently. Otherwise my installs were using a daily iso from the 15th
<phillw> (15:00:07) phillw: hi, do we expect the bug that does not use the 3.13 kernel as a an upgrade from 12.04 LTS? 
<phillw> aka, when updating from 12.04 lts, we do not get the kernel release for 14.04
<eagles0513875> phillw: O_o not like you to be in here
<phillw> eagles0513875: the people here are proffessional. 
<eagles0513875> i know im working on getting a multi touch track pad issue solved
<phillw> I need them to to fix an issue
<phillw> eagles0513875:  joe salisbury is afk, as is bodhi-zazen.... I'm stuck until the kernel team fix it :)
<apw> phillw, no we expect something upgraded to use the correct kernel
<phillw> apw
<eagles0513875> apw: how should i proceed with the issue of the multitouch track pad?
<phillw> apw: it did not.... how do I fix it?
<apw> phillw, if it was an update-manager update then (unintuitvly) the thing to do is to file a bug against update-manager and say "yes" to the during an update from a previous release
<phillw> it's really good to catch this error so early :)
<apw> as that gets the appropriate logs from the update
<phillw> apw: the VM is non GUI.... so I cannot file a bug :(
<apw> eagles0513875, we need to find out that this patch even has a thing to do with your issue, which would mean i need to spin a kernel (as you don't seem to be able to), and that'll happen when i get to it
<apw> phillw, you can file a bug, its just harder
<eagles0513875> apw: if you can give me the steps on what i need to do I can do it 
<apw> phillw, iirc you can just do the same thing, and it uploads it and then gives you the URL for it to continue on another machine
<phillw> apw: the VM is there... tell me what you need & I will do it. Just recall that I am a tester not a coder and you will have to give me step by step instructions.
<ikonia> if you need step by step instructions, he may as well just do it himself
<eagles0513875> ikonia: i just really need help with patching. if http://www.howopensource.com/2011/08/how-to-compile-and-install-linux-kernel-3-0-in-ubuntu-11-04-10-10-and-10-04/ works then i can follow those instructions to apply
<eagles0513875> compile*
<phillw> ikonia:  I have offered them root access to the VM. More than that I cannot do :)
<apw> phillw, "ubuntu-bug update-manager" should work GUI or not
<apw> phillw, i think ikonia was talking to eagle
<ikonia> eagles0513875: I'm missing background here - but what kernel version are you trying to build ?
<eagles0513875> ikonia: the one that comes with 13.10
<eagles0513875> forget that that article is for older kernels and release. are the steps to compile it the same?
<apw> if you arn't confident building it then a negative test will not be conclusive anyhow
<eagles0513875> ok 
<phillw> ikonia: I'm building the kernel for 14.10
<ikonia> phillw: so ?
<phillw> sorry... 14.04
<eagles0513875> apw: ill leave it in your hands
<eagles0513875> phillw: i think that was directed at me btw
<ikonia> eagles0513875: is there a bug logged for this ?
<phillw> eagles0513875: that communities can not make respins is an issue. 
<ikonia> communities can make respins
<eagles0513875> ikonia: my issue has nothing to do with what phillw is doing
<ikonia> who said they can't ?
<ikonia> ahh
<eagles0513875> wait a min we are on two different wave lengths here
<ikonia> I'm missing background/context for both issues
<eagles0513875> ikonia: my issue is relating to my multitouch track pad on my laptop 
<eagles0513875> i found https://launchpad.net/bugs/967399
<ubot2> Launchpad bug 967399 in linux (Ubuntu) "[11.10] Elantech trackpoint does not work Lenovo " [High,In progress]
<phillw> ikonia: https://answers.launchpad.net/ubuntu/+source/debian-cd/+question/240037
<eagles0513875> and this laptop has an elantech multitouch track pad but that bug is geared specifically for lenovo so I was wanting to patch my kernel to see if that fixes my track pad not working at all. 
<ikonia> eagles0513875: is that your exact bug ?
<eagles0513875> btw apw thanks for offering to compile a test kernel with the patch
<eagles0513875> ikonia: yes that my track pad doesnt work at all right now. 
<apw> phillw, when something is hard to do, that doesn't make it easy to document, cd creation is such a beast, it has evolved over some 12 years
<ikonia> eagles0513875: ok - so it's the same bug but on version 13.10 ?
<eagles0513875> correct
<ikonia> eagles0513875: ok, cool, so the bug is valid. 
<ikonia> eagles0513875: so where are you getting the patch from ?
<eagles0513875> the bug
<eagles0513875> there is one as well as a diff
<apw> ikonia, though this bug is for a lenovo, and that isn't what he has
<ikonia> what ???
<ikonia> the patch isn't even for the 13.10 kernel
<eagles0513875> the patch is for a lenovo lapto mine is a toshiba
<ikonia> eagles0513875: why are you talking to upstream ???
<phillw> apw: I do have people to help.... what is needed is kernel for server edition to up grade to the 14.04 edition (3.13)
<ikonia> what the debvil.....
<eagles0513875> apw asked me to see what happened to it as it had initially been filed upstream for inclusion into mainline
<eagles0513875> and basically the last comment i got today about it. 
<ikonia> eagles0513875: so what is the model of track pad you have ?
<eagles0513875> how would i check that
<ikonia> you don't even know the model ???
<ikonia> you're assuming the lenovo track pad has the same model as yours and the lenovo patch will fix it
<apw> phillw, and hopefully the log as to why the upgrade didn't complete will be in the logs from the bug you're filing with the ubuntu-bug command
<phillw> apw: I cannot file a bug :(
<ikonia> eagles0513875: how are you following bugs looking at patches, when you don't know the model of the hardware that's failing ????
<phillw> apw:  it is a server with no X
<ikonia> you can manually look at the logs ?
<ikonia> log the bug manually on launchpad.net ?
<apw> phillw, you do not need X to file a bug, i just did it here by doing a DISPLAY= ubuntu-bug ... and it does it all in ascii
<apw> did you even try it ?
<eagles0513875> ikonia: i found out how to determine which track pad i have but not the model
<eagles0513875> â¡ Virtual core pointer                          id=2    [master pointer  (3)] â   â³ Virtual core XTEST pointer                id=4    [slave  pointer  (2)] â   â³ ETPS/2 Elantech Touchpad                  id=11   [slave  pointer  (2)] 
<phillw> apw and what is the name of the bug you want?
<apw> ubuntu-bug update-manager
<apw> and say Yes to the "during an upgrade from a previous release" prompt
<phillw> runnig
<phillw> apw: The collected information can be sent to the developers to improve the
<phillw> application. This might take a few minutes.
<phillw> ..==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
<phillw> Authentication is needed to run `/bin/cat' as the super user
<phillw> Multiple identities can be used for authentication:
<phillw>  1.  ali,,, (ali)
<phillw>  2.  Jason,,, (jason)
<phillw>  3.  eagles,,, (eagles)
<phillw>  4.  Kris,,, (kris)
<phillw>  5.  bipul
<phillw>  6.  dan
<phillw> Choose identity to authenticate as (1-6): ................
<ikonia> eagles0513875: you're on shacky ground
<ikonia> eagles0513875: it seems a very random approach
<eagles0513875> ok
<eagles0513875> i guess ill just wait it out. for apw
<ikonia> eagles0513875: I would try to get some factual information together
<ikonia> eg: your hardware make/model - the hardware make/model that this patch fixes/support would be a good start
<ikonia> before pushing/wasting peoples time for tests
<ikonia> do you even known if it uses the same module to drive the touchpad as this bug ?
<eagles0513875> ok. thing is the bug doesnt specify which elantech model it fixes either
<ikonia> eagles0513875: right - so you finding out would be a good start
<eagles0513875> ikonia: that is why im asking for help to patch my kernel 
<eagles0513875> to test and see if it truly does fix the issue.
<ikonia> eagles0513875: why are you patching the kernel when you don't know the scope
<ikonia> eagles0513875: you're running before waling
<ikonia> walking
<eagles0513875> how am i supposed to determine the scope by looking at the patch and determining my model?
<phillw> eagles0513875: do you have a profile at https://wiki.ubuntu.com/QATeam/Hardware ? makes life a lot easier to the devs :)
<eagles0513875> phillw: no
<phillw> eagles0513875:  then do it :)
<ikonia> eagles0513875: a good basic check would be "what is the target kernel that patch is aimed at"
<ikonia> eagles0513875: that patch maybe for 3.1.8 - and the changed between 3.1.8 and 3.1.12 make it useless
<eagles0513875> from the looks in the bug report 11.10
<eagles0513875> im guessing what ever kernel was on that
<ikonia> eagles0513875: right, so quite old - so probably not going to be targeting / compatible with the same kenrel you are using
<ikonia> 3 years is a long time
<ikonia> a lot gets changed in 3 years
<eagles0513875> ikonia: if that is the case besides filing a bug report with all the appropriate bug information 
<ikonia> ?
<phillw> apw: I have no idea what it is up to..... 
<eagles0513875> ikonia: what i need to do is file a bug report against 13.10 instead
<eagles0513875> with the version of my track pad in that case
<ikonia> yeah, I think that's a good thing to do, reference the other bug if you want, but a lot has changed
<ikonia> try to get solid factual information though
<ikonia> nothing half hearted or guessed, facts only
<phillw> eagles0513875: have a read of https://wiki.ubuntu.com/QATeam/Overview/Install_Bugs
<ikonia> why are you giving him an installer bug link ?
<ikonia> I thought this was a problem after the install, with the running OS
<eagles0513875> phillw: O_o not sure what that has to do with anythign im experiencing plus im not on 14.04
<eagles0513875> ikonia: do you mind if we take this discussion back to kubuntu
<ikonia> no problem at all
<ikonia> phillw: I'd suggest focusing on your own problem
<phillw> eagles0513875: I give people all options. 
<ikonia> you give bad information
<ikonia> that is random and not helpful
<ikonia> so I'd sugget focusing on your own problem only
<phillw> ikonia: that, my friend, is something I do not give.... a bug is a bug, the dev's need what is available. Having the the hardware is always handy :) But, we will not fall out @P
<ikonia> you're giving bad information and bad links to people, please don't
<ikonia> focus on your own bug please.
<phillw> ikonia: I'd like to query as to a link given that is run by a canonical person can be seen as you as a bad link? https://launchpad.net/~nskaggs
<ikonia> for the exact reasons I said earlier
<ikonia> it's nothing to do with the installer
<ikonia> he's not running 14.04
<ikonia> seems pretty clear giving a link to installer bugs for non-installer problems is "bad"
<phillw> ikonia: and I didn't know that... as to how updates break installed systems is "bad" :)
<ikonia> sorry, I don't understand your last statement
<phillw> ikonia: I'm chatting with eagels, chatting on two channels does get confusing! I'm awaiting the fix to have the 3.13 kernel installed onto 12.04 lts :) Please do not take my frustrations personally, it is just somewhat frustrating at times :)
<apw> phillw, earlier you said you were upgrading this machine and didn't get 3.13, are you saying you are doing 'update' of 12.04lts and expecting to get the 3.13 kernel
<phillw> apw indeed, i expected an lts to lts upgrade actually bring the new kernel :)
<apw> phillw, so the machine is now running 14.04 yes?
<apw> (just confirming that that is right, as that makes the bug i asked you for the right thing)
<apw> eagles0513875, ok a saucy kernel with that patch applied is here: http://people.canonical.com/~apw/lp967399-saucy/
<eagles0513875> thanks apw :) will give it a try
<phillw> apw: you know something... I've got lot a lot of apologising and self kicking to do.... although reminding us in upgrades that we need to reboot twice instead of trying to remember. :D
<apw> one doesn't need to reboot twice in an upgrade, i just did one on my other computer, S->T not half an hour ago, and only rebooted once
<phillw> apw I had to on the KVM virtual machine
<apw> that may be an artifact of the way the kvm images are maintained there, not something i have seen on any of mine
<phillw> it *may* be worth a release note for any server people running kvm.... but is more a #ubuntu-server issue. I'm only here to build the non-pae 13.03 kernel :)
<infinity> phillw: I told you yesterday that the upgrade from a non-3.2 kernel wouldn't upgrade you to 3.13, and told you how to work around it.
<infinity> phillw: As it turns out, rtg fixed that bug last night, so it should work now.
<infinity> phillw: I'm not sure why you're still talking about this.
<phillw> infinity: i was aware the the bug was in progress, and then got asked to raise a bug...... 
<infinity> Where's the bug you filed?
<phillw> infinity: I was still in the process of trying to file it! the server is cli and has sat for 60 minutes '''collecting data'''
<rtg> smb, just installed the trusty server amd64 daily. same result. gets stauck right after /scripts/init-bottom
<infinity> phillw: Okay, or you could not file it.  Since the bug is "there's not path for precise+lts-backport upgrades to to 14.04" and, like I said, this was (a) a known bug, and (b) fixed 6 hours after you tripped on it.
<smb> rtg, weird...
<rtg> I wonder why it would boot the installer....
<phillw> infinity: if the bug is fixed, no need to report... unless some one wants bug fixing points :P As I have the VM with 3.13 I can use it to build the non-pae kernel. To the other wonderful people on here, a massive thank-you. 
<infinity> phillw: Is this just a one-time kernel build for yourself, or something you're hoping to upload to the archive?
<infinity> phillw: Cause as I've told many people, many times, I won't accept a non-pae kernel in the archive without it also coming with a (believable) statement of support intent, like I have for lowlatency.
<phillw> infinity: it is going to be a 14.04 lts kernel for any flavour that needs it.
<infinity> phillw: Throwing a rotting corpse of an unmaintainer kernel in the archive so people can have unpatches security holes on their old hardware isn't a win.
<infinity> phillw: It is, is it?  According to whom?  And who will maintain it?
<infinity> s/unmaintainer/unmaintained/
<infinity> phillw: Who's going to rebase it against master every 3 weeks?
<infinity> phillw: Who's going to test those rebases to make sure they still boot and work?
<infinity> phillw: Since I'm pretty sure this isn't you, who are yo uvolunteering to do work that they didn't sign up for?
<phillw> infinity: "we" the people will maintain it. on http://phillw.net/isos/ and as bodhi-zazen has agreed to teach us http://bodhizazen.net/Tutorials/kernel we are secure in how we support this.
<phillw> infinity: https://answers.launchpad.net/ubuntu/+source/debian-cd/+question/240037 what you seem to forget, is that with some help... communities can co-ordinate and make spins.
<infinity> phillw: If this isn't going to be in the primary archive, you can do whatever you like.
<phillw> infinity: the kernel will be in a ppa (so I'm told) and any community can use it as a build / update area. I've now to build my first kernel :)
<psivaa> smb: rtg: i think we are seeing the same issue that you are discussing, today's trusty server installs being broken... just confirming if it helps
<rtg> psivaa, change your display from cirrus to vga
<smb> psivaa, Turns out broken means only that in kvm the default cirrus card causes framebuffer issues
<smb> psivaa, The guest gets up just the screen stops getting updated
<phillw> smb: I'm sure we discussed this last night? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674
<ubot2> Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed]
<psivaa> smb: rtg: ok, just to confirm... does that tally with the following log:
<psivaa> Jan 17 07:32:43 anna[8496]: corrupted status flag!!: 0
<psivaa> Jan 17 07:32:43 anna[8496]: (process:10447): tar: write error: No space left on device
<psivaa> Jan 17 07:32:43 anna[8496]: (process:10447): tar: write error: No space left on device
<smb> psivaa, No that rather sounds obviously like disk too small?
<psivaa> smb: no disk size is no different to what we used yesterday, 8G
<phillw> rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674/comments/43
<ubot2> Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed]
<smb> phillw, No it is not. That is an x driver bug
<phillw> okies :)
<smb> rtg, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269401
<ubot2> Launchpad bug 1269401 in linux (Ubuntu) "[Trusty] Switching framebuffers fails on VMs using cirrus" [Medium,Confirmed]
<rtg> jjohansen, bug #1270215 looks like an AA issue, e.g., trusty LTS prevents dhclient from running.
<ubot2> Launchpad bug 1270215 in Ubuntu "kernel 3.13.0-4.19~precise1-generic: no internet" [Undecided,New] https://launchpad.net/bugs/1270215
<jrr> what should I try next on this?: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269986
<ubot2> Launchpad bug 1269986 in linux (Ubuntu) "kernel oops - unable to handle kernel NULL pointer dereference; probe_monitoring_device / nouveau_i2c_identify" [Undecided,Confirmed]
<jsalisbury> rtg, shall I hold off on bisecting bug 1270215 ?  since it may be an AA issue?
<ubot2> Launchpad bug 1270215 in linux (Ubuntu Precise) "kernel 3.13.0-4.19~precise1-generic: no internet" [High,New] https://launchpad.net/bugs/1270215
<rtg> jsalisbury, yeah, it'll be a waste of your time. lets get jjohansen to look at it first.
<jsalisbury> rtg, ack
<rtg> jsalisbury, However, bug #1270218 looks like a good bisect candidate.
<ubot2> Launchpad bug 1270218 in linux (Ubuntu) "3.13.0-4-generic [Radeon HD 7950] No Display at Login Screen" [Medium,Confirmed] https://launchpad.net/bugs/1270218
<jsalisbury> rtg, heh, looking at that one right now :-)
<rtg> there just weren't that many commits between -3 and -4
<jsalisbury> rtg, looks like it was introduced between v3.13-rc8 and commit 85ce70f
<rtg> yup
<jsalisbury> rtg, although there were a few branch merges
<eagles0513875> apw: trying to install the kernel headers and its complaining  about missing dependencies
<jsalisbury> rtg, Should be a quick bisect, I'm guessing it's one of these:
<jsalisbury> git log --pretty=oneline b25f3e1c358434bf850220e04f28eebfc45eb634..85ce70fdf48aa290b4845311c2dd815d7f8d1fa5 -S radeon
<jsalisbury> f244d8b623dae7a7bc695b0336f67729b95a9736 ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
<jsalisbury> 59aebe2b32466f7ed5b79f18646be6dddc926a6d Revert "drm/radeon: Implement radeon_pci_shutdown"
<jsalisbury> 9c57a6bd3ea4a9870a7ce2fd961da6ef4986bbc1 drm/radeon: add radeon_vm_bo_update trace point
<jsalisbury> 84d597b74b58dd52621abf5f052a81370ace1816 drm/radeon: add VMID allocation trace point
<jsalisbury> ec39f64bba3421c2060fcbd1aeb6eec81fe0a42d drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
<rtg> jsalisbury, seems likely
<Sarvatt> hmm, the kernel apport hook should probably have /var/log/kern.log in it so it doesn't just have the successful boot dmesg attached like that bug
<rtg> Sarvatt, doesn't bdmurray own apport ?
<bdmurray> rtg: that's pitti but I work on it some
<eagles0513875> apw: sadly that didnt fix the problem for me :( 
<rtg> BenC, from LKML: Kernel stack overflows due to  "powerpc: Remove ksp_limit on ppc64" with v3.13-rc8 on ppc32 (P2020)
<apw> rtg, nice catch ...
<rtg> apw, just drifting thru LKML...
<apw> we do rely on it :)
<rtg> hopefully it'll pop out for 3.13 final
<jjohansen> rtg: yep 1270215 looks like a policy issue
<rtg> jjohansen, ack
<rtg> bjf, from LKML: 'Baytrail problems (was Re: Linux 3.13-rc8)' talks about a stable patch that might give you fits.
<bjf> ARGH!
<stgraber> sforshee: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
#ubuntu-kernel 2014-01-18
<BenC> apw: commit 83f315bdcb1482d6916027a488bf53df63ba4ba6
<BenC> Author: Frederic Weisbecker <fweisbec@gmail.com>
<BenC> Date:   Tue Sep 24 00:50:25 2013 +0200
<BenC>     irq: Force hardirq exit's softirq processing on its own stack
<BenC> That's the problem I was seeing
<BenC> apw: That one-liner stack fix from lkml fixed my ppc booting issue
<BenC> apw: Pushed trusty3.13 branch to my ubuntu-saucy tree
#ubuntu-kernel 2014-01-19
<infinity> win 206
 * apw sends infinity about 100 /closes
<TheDrums> apw: Where do you think he gets his name from? :P
<BenC> apw: Just pushed a new trusty3.13 branch. Gets a missing patch that caused a build failure. I've run this full build, so it all works as expected
#ubuntu-kernel 2015-01-12
<apw> xperia (N,BFTL), you don't need to sign it, it will whine about it but not break it; you cannot obtain keys to sign it, we cannot
<staylor_> Curious about the recommended way of handling device trees with custom kernel packaging.  We have a custom package for support various embedded boards for a number of customers, right now we have one package per customer but the kernels themselves are effectively all the same and custom device tree files is the main difference.
<staylor_> So I'm thinking of just removing the *.dtb from the kernel-image-custom package and instead have a number of device-tree-customerA/device-tree-customerB packages.
#ubuntu-kernel 2015-01-13
<seb128> hey
<seb128> is there any know issue with the recent kernel updates in vivid and I5 graphics? since a week or so I my latitude e6410 show only a blank screen after plytmouth, no lightdm greeter, things work fine if I boot an old kernel
<apw> seb128, doesn't sound familiar no ...
<apw> seb128, i assume this is with v3.18 that it fails, and ok with v3.16 ?
<seb128> apw, correct, assuming 3.18 started ~ a week ago
<seb128> I don't have a previous 3.18 in my grub list, but yeah 3.16 works fine
<apw> seb128, there is a v3.19 in the CKT ppa you might want to try as well
<seb128> apw, is that the most useful thing to try?
<apw> seb128, well if it is working i can forget about it as that will be at least the version for vivid
<apw> seb128, though as always a bug would be nice, if you could let us know the number here
<seb128> ok, I'm going to do that and open the bug with the details on whether 3.19 resolves it
<seb128> apw, https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa is the ppa right?
<apw> seb128, sounds good, yes, thats the right PPA, there is a -1.1 without associated -signed and -meta, and a -2.2 building right now
<seb128> ok
<seb128> apw, thanks
<apw> seb128, thanks, we shall wait your tests with interest
<seb128> apw, didn't try the ppa yet, but the issue seems similar to https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1408593 which apparently is fixed/working in 3.19
<ubot5> Launchpad bug 1408593 in xorg (Ubuntu) "X server disables acceleartion or turns off output (makes screen black) after kernel upgrade to v3.18 (Ubuntu Vivid)" [High,Confirmed]
<jsalisbury> ##
<jsalisbury> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<jsalisbury> ##
<apw> seb128, so i think they also say it might be fixed in 3.18.2 which is also being built in -proposed
<seb128> apw, cool, I'm going to try that one as well
<apw> seb128, sitting in the new queue waiting on the AAs it seems
<seb128> k
 * apw pokes the releasey peeps
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 10 minutes
<jsalisbury> ##
<seb128> apw, the kernel from proposed give me a display back but with the wrong screen resolution
<seb128> going to try the ppa one next
<apw> seb128, ack
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 20th, 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.
<seb128> back
<seb128> apw, same issue with the ppa most recent kernel
<seb128> screen is back on but with the wrong resolution
<apw> seb128, same as v3.18 -proposed ... ok
<seb128> apw, should I comment/add details on https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1408593 on open a new bug?
<ubot5> Launchpad bug 1408593 in xorg (Ubuntu) "X server disables acceleartion or turns off output (makes screen black) after kernel upgrade to v3.18 (Ubuntu Vivid)" [High,Confirmed]
<apw> it really does sound rather like the same issue, though generally people file their own to get the h/w info, and then link them to the oriignal
<seb128> k, I commented on it, going to watch the activity/provide info if needed
<apw> jsalisbury, ^ one worth looking at
<jsalisbury> apw, ack
<jsalisbury> apw, right, I recall that one.  3.19 fixes it for some, as does latest upstream 3.18, but not for others.  I'll dig in to it.
<jsalisbury> seb128, If you have a chance, can you test this kernel:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-01-13-vivid/
#ubuntu-kernel 2015-01-14
<hfmanson_> hello, I'm using ubuntu 14.04.1 and since 3.13.0-43 i get kernel crash involving IPv6. Version 3.13.0-44 doesn't kernel panic, but I get 'BUG: unable to handle kernel paging request at 0000000000001268'. I have saved then dmesg output
<hfmanson_> can i send the report somewhere, I don't think it is a hardware issue
<apw> hfmanson_ (N,BFTL), yes, that sounds like a kernel bug, file a bug against linux "ubuntu-bug linux"
<apw> jibel, can you remind me what time it is that the DKMS kernel checks occur?  i am asking becasue it feels like vivid is not being checked, as both the 3.18.0-9 in -release and 3.19.0-2 in the CKT PPA didn't fire last night; there are two fired manually to confirm the jobs work
<apw> (and happy new year :)
<jibel> apw, hey, happy new year :) They run at 02:something every day. I'll check why vivid didn't run.
<apw> jibel, thanks :)
<apw> jibel, i triggered "acpi_call_dkms" by had in both -v's just to check that the jobs themselves work
<apw> jibel, according to launchpad the 3.18.0-9 hit -release 12 hours ago, so in theory at least in the pocket before 2am
<jibel> apw, hm, there is something wrong with the scheduler, last run were 2015-01-09 07:51, 2015-01-11 11:13, 2015-01-13 14:45 . Not really my understanding of everyday at 02:something
<apw> jibel, interesting, it is doing every other day by the looks of it
<jibel> apw, no and there is no overlap between runs, last automated test ran on Jan 13, 2015 3:00:33 PM, so they should have run on the 14th@2AM
<apw> jibel, because jenkins i assume
<jibel> apw, yeah, I suppose jenkins has his own implementation of cron, NIH syndrome :)
<apw> jibel, i see we finally got the sync'd views out in public for dkms, so we can finally see the utopic lts ones
<apw> jibel, so in the importal words of the song "where do we go from here"
#ubuntu-kernel 2015-01-15
<pmatulis> anything to worry about re leap second or should i just organize a party? ;)
<visiot> how can i enable eMMC on my board , the Memory Card  Interafce is initialized already but i'm not able to see mmcblk in kernel log messages
<apw> jibel, hmmm well those builds never did turn up, so it is not every 2 days either ...
<jibel> apw, I didn't figure out what's wrong yet. If I run them from my account it's fine, but from jenkins it does nothing.
<apw> jibel, lovely, we so love jenkins
<staylor_> 	I'm a little confused by the proper way to package a kernel for sharing, I started off with make-kpkg but it seems the official kernels may be built using the pkg-deb system built into the kernel?
<apw> staylor_, we build ours directly using dpkg-buildpackage -S etc
<staylor_> apw: so if I need to build a kernel for distribution I should be making my own debian/ dir from the ubuntu kernel packages then and not bothering with make-kpkg or make deb-pkg?
<apw> staylor_, making your own version or whatever yeas, and just building direct, i fyou are making a drivative then linux-lowlatency etc are doinga good job
<staylor_> apw: okay thanks, the documentation tends to be more focused on building a custom kernel for personal usage so doesn't really provide a system for maintaining changelog and ensuring packages are all correctly signed for apt-get distribution.
<apw> yeah, i would expect you to follow the pattern for linux-lowlatency there, and use a PPA for distribution
<infinity> zequence: It's that time of month again: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1410911
<ubot5> Launchpad bug 1410911 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
#ubuntu-kernel 2015-01-16
<smoser> apw, workdir= for overlayfs...
<apw> smoser, yes
<smoser> it cannot be under upperdir ?
<apw> smoser, it cannot
<smoser> thats annoying.
<apw> smoser, yes, it is very annoying
<smoser> basically means i can't have overlay go to the root of a filesystem.
<apw> smoser, in other places i have done like $upperdir-workdir, and where .. isn't on the same filesystem it fails to mount
<apw> smoser, no indeed, it means exactly that, which is a royal pain
<apw> smoser, i have tended to take the <dir> people supply and make upper and workdir in there
<smoser> do you have  suggestion on how to determine if i have use workdir= ?
<apw> smoser, i have tended to mount with workdir= and when that fails mount without, though if that is hard
<apw> smoser, and in overlayroot, i believe that is hard because we build the fstab first
<apw> smoser, then you can use version > 3.18.0-0
<smoser> i dont think fstab is an issue. as we dont even write the "correct" mount options tehre.
<cyphermox> hey, I've added a task for linux to https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1408495; looks like any moving of a file on the underlying read-only filesystem of the overlayfs on the CD leaves behind a 0,0 character device of the same name; could someone check if there would be an explanation for this as an overlayfs bug?
<ubot5> Launchpad bug 1408495 in ubiquity (Ubuntu Vivid) "Ubiquity crashes prior to keyboard configuration in 15.04" [High,Confirmed]
<cyphermox> apw: looks like my bug 1408495 is most likely a duplicate of bug 1410480
<ubot5> bug 1408495 in ubiquity (Ubuntu Vivid) "Ubiquity crashes prior to keyboard configuration in 15.04" [High,Confirmed] https://launchpad.net/bugs/1408495
<ubot5> bug 1410480 in linux (Ubuntu) "overlayfs v1: renaming existing file uses chardev whiteout (should be symlink)" [High,In progress] https://launchpad.net/bugs/1410480
<apw> cyphermox, yes given you had a c------- device, that is nominally a whiteout, and wrong, and the second bug yes
<apw> cyphermox, i am working on that one right now, feel free to dup yours to it
<cyphermox> alright, so I'll mark duplicate
<cyphermox> thanks!
<apw> smoser, it occurs to me where these are in tmpfs, that you can (and likely should) use V2 format, ie use -t overlay
<apw> smoser, for the maas use case they are ephemeral right ?
<smoser> maas is backed by tmpfs.
<smoser> what is 'v2 format' ?
<smoser> apw, ^
<apw> upstream overlayfs format ... in v3.18 there are two filessytem overlayfs which is (in theory, and actually not right now) backwards compatible on disk, and overlay which is how upstream is doing it going forward
<apw> smoser, ^
<smoser> apw, does 'overlay' have the same symantics as overlayfs from client 'mount' ?
<apw> smoser, yes
<smoser> so just '-t' overlay
<smoser> why did you ask about 'tmpfs' ?
<smoser> oh. i see. because of data format.
<apw> smoser, right, if the upperdir is empty you can use the new form cause you really have no old data
<smoser> apw, would there be an easy way to know the format of the data ?
<smoser> because if i try to be smart and "auto" select overlay rather than overlayfs, then i have to later on make the right choice.
<apw> smoser, no none
<apw> smoser, a filesystem with no superblock, it is a bit of a disaster
<smoser> then i think its best to just be stupid, and not try to "help" the user at all.
<smoser> apw, why would i want the new 'overlay' type for tmpfs ? ie, you're right we could make that decision, but why would i want to
<apw> because the old one is going to go awy, for tmpfs, as it is ephemeral the new one is most appropriate because it is going to go away anyhow
<apw> smoser, and the new form is upstream supported, and should be more reliable as a result
#ubuntu-kernel 2015-01-17
<SturmFlut> I am building an app for Ubuntu Touch which makes use of an unprivileged ICMP socket. The call    socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)    works on my phone (Nexus 4, Ubuntu Touch r14, Kernel 3.4.0-5-mako), but returns EACCES on my Desktop (Vivid, Kernel 3.18.0-9-generic). I already checked that the 3.18.0-9-generic kernel contains the necessary code for unprivileged ICMP sockets and there are no AppArmor 
<SturmFlut> violations on the Desktop.
<SturmFlut> Any ideas?
<jjohansen> SturmFlut: first I would check that it works correctly from a privileged user
<SturmFlut> jjohansen: I'll build a minimal example in C, all I currently have is a lot of C++ code
<SturmFlut> jjohansen: https://github.com/Sturmflut/unprivileged-icmp/ should contain a working example. It fails with errno = 13 (EACCES) after the socket() call on my desktop, and completes successfully on the phone. It also fails with errno = 13 when run as root on the desktop.
<SturmFlut> jjohansen: I could compare the source code of the 3.4.0-5-mako kernel with 3.18.0-9-generic and find out if there are any differences regarding unprivileged ICMP
<jjohansen> sure
<SturmFlut> It is 03:16 AM here in Europe, though ;)
<SturmFlut> I found the solution to my unprivileged ICMP socket problem
<SturmFlut> The file /proc/sys/net/ipv4/ping_group_range controls which group id ranges are allowed to create such a socket
<SturmFlut> On the phone, the content of the file is "0	2147483647", effectively allowing access to anybody
<SturmFlut> On the desktop the content is "1 0", effectively disabling the feature completely
<SturmFlut> I think this setting should be consistent across devices, but it has some security implications. Fedora 21 Workstation e.g. also ships with the feature disabled
<aeoril> I am interested in working with the ubuntu community on low level stuff - kernel, modules, vms, etc.  This is a long term goal, and I want to prepare myself properly.  I have a history of doing real-time, embedded programming at my last job in C.  However, I want to read up on operating systems development and was hoping for pointers to good resources to help bring me up to speed.  I am 
<aeoril> thinking of buying "Modern Operating Systems" by Tanenbaum version 4, but it is expensive and wanted to make sure this was a wise investment.  Any pointers would be appreciated to prepare me to contribute in this area.
<aeoril> Note that I already have Modern Operating Systems v. 3 and found it very good, but it seems version 4 is much more up-to-date and releveant today
<aeoril> Note that I have looked at the kernel development wiki for Ubuntu and understand there is a ton of stuff there, but wanted to get into some of the academic side of things to be better prepared overall for this direction
#ubuntu-kernel 2015-01-18
<swordsmanz> aeoril experement
<aeoril> swordsmanz I am sorry, I do not understand
<aeoril> swordsmanz expirement?  Try different books/resources myself?
<swordsmanz>  aeoril  no experenment with the kernal 
<swordsmanz> im asumeing that you know how to compile the linux/bsd/mach kernals ? 
<aeoril> swordsmanz no
<swordsmanz> well you know how to compile other programmes? 
<aeoril> swordsmanz but that I think should just be a matter of following recipes.  I am thinking it might be best to learn some of the theory behind OSes before I dive into the practical realm
<aeoril> swordsmanz yes, I can compile other programs
<swordsmanz>  well compileing a kernal is no different 
<aeoril> swordsmanz I'll give you an example of why I was thinking of pursuing theory and taking a more academic approach at first
<swordsmanz> and no its best to just learn, the hardware will have manuals for the specific proc types and stuff, and its a matter of translateing that into code that will run well when compiled 
<aeoril> Some years ago, I worked on a problem in a low level system that involved needing to send data across a bus.  I could not use a semaphore because there was no way to coordinate with something like that - it was to disparate systems existing across a bus.  I did my own FIFO routines to accomplish this communication.  I tested it it tortuously, and thought the theory behnd my FIFO routines 
<aeoril> was solid, but years later, on reading Tanenbaum's book I learned that the way I did it was not right - it was not a lock-tight, solid implementation and could have sporadic errors, however unlikely
<aeoril> So, I found in his book the perfect algorithm that I needed for this specific problem.  I could never have come up with that algorithm on my own (most likely) and that particular algoritm if I remember correctly had come along somewhat late in the grand scheme of things even for the experts in OS development that had worked without this algorithm for years before
<swordsmanz> yeah but there is always a better way to do something 
<aeoril> So, I wanted to learn some of these things to get some of the theory internalized so I could know better how to do OS and kernel development before diving into the practical side of htings
<aeoril> swordsmanz so, you would think looking at kernel code, etc. might be more useful?
<aeoril> modern kernel code
<aeoril> experimenting with it, playing with it, reading it, understanding it ...
<swordsmanz> i think that unless your comfertable makeing small tweaks and compileing your not gonna find it simple to do more complex stuff 
<aeoril> My idea was (1) theory (2) small tweaks and experimentation (3) go from there to more complex things - baby steps.  But I wanted to get some of the theory and stuff I would normally get in university done first, or maybe alongside, the baby steps with the actual linux kernel, modules, etc.
<swordsmanz> hmm in my experiance theory is opnly really good for referance 
<aeoril> swordsmanz I am sorry, my wife is calling me to eat - I will be back in a few.  Thanks for the help
<swordsmanz> kk 
<aeoril> swordsmanz back!
<swordsmanz> YAY 
<swordsmanz> its proberbly not a good idea to listen to my thughts on this anyway as im just getting my head around the basics of how the ernal is structured, even tho i have been compileing my own for a while now 
<aeoril> swordsmanz I was thinking there is great value in what you are telling me.  I think it would be best to work through some of the basic theory behind operating systems, but as I do so learn to compile, alter and test the kernel and find examples of the theory as I learn in the kernel and experiment with changing it, breaking it, fixing it, etc. to best learn not just the theory but how 
<aeoril> it relates to real implementations in the Ubuntu/Linux kernel
<swordsmanz> aeoril yeah that sounds sensible 
<aeoril> This will also give me a less "dry" path and allow me to more quickly assimilate into the community to start doing minor helpful things, like bug triage, etc. and get my toes wet
<aeoril> First my little toe, then my other little toe, then go from there ... :)
<aeoril> swordsmanz I found some other resources that recommended Tanenbaum's book so I went ahead and bought it.  I am now reading it.  Wish me luck!
<swordsmanz> im only really here becouse there is a powermanagment bug on amd apu's that is really realy iritateing, and i want to see if i can have a go at fixing it becouse its bugging me :S 
<swordsmanz> GOOD LUCK 
<aeoril> swordsmanz ty :)
#ubuntu-kernel 2016-01-18
<phillw> greetings people, is there any further plan for the 4.4 kernel to arrive into xenial test builds by 25th Jan? if you have an answer, please ping wxl so that he stops pinging me :) Humour, on the kernel team is still allowed :)
 * tsimonq2 is gone: 
#ubuntu-kernel 2016-01-19
<rtg_> apw, re: bug #1534780 - do you remember why ppp-modules is excluded from the s390x d-i ?
<ubot5> bug 1534780 in linux (Ubuntu Xenial) "Xenial: review s390x module exclusions" [Undecided,In progress] https://launchpad.net/bugs/1534780
<apw> rtg_ i am going to suggest it is empty on s390x, and so is disabled.  if so that means we are missing a provides on the kernel-image or similar
<apw> rtg_, i can have a look
<rtg_> apw, please do, thanks
<apw> ppp prolly depends on serial devices and there are none on s390x something like that
<apw> rtg_, ack
<stgraber> cking: hey, so https://github.com/zfsonlinux/zfs/issues/4177 is going to be a serious problem for us on Ubuntu and upstream hasn't reacted yet. Is that something you or someone on your team could take a look at? or do you guys have a more direct upstream contact you could poke?
<stgraber> ogasawara: ^
<cking> stgraber, i'll see if I can get some headway on this by chatting to upstream
<stgraber> thanks
<xnox> oh, you know it's going to be a good one when stgraber opens with "First a quick introduction to the world of containers"
<stgraber> :)
<manjo> apw, do you have the initramfs tools for xenial in PPA? or does that comes from the archive ? this is to test the PARTUUID change 
<manjo> apw, ok I found it .. 
<soee> we have 4.3 kernel updates in Xenial, shouldn't ther be 4.4 already ?
<manjo> apw, around ? (I guess not)  have something I wanted to run by you about initramfs tools 
<apw> manjo, did it work?  email me what happened
<apw> soee (N,BFTL) its coming, soon
<manjo> apw, I sent you an email about related topic 
<manjo> apw, will be testing the partuuid change in the next hr or so
<manjo> and will email you about that 
#ubuntu-kernel 2016-01-20
<tjaalton> apw: do you have an estimate for the initramfs-tools update to fix nvme? should happen before 4.4 hits xenial
<apw> tjaalton, i could do that todya i think if i back out manjo's change.  as that does not seem to work for him
<caribou> apw: yes, on this nvme note, do you need me to re-test on my platform or cking's test is sufficient ?
<apw> tjaalton, i think i need to pull in 0.122 from debian to fix manjo and that is a bigger job
<tjaalton> ok..
<apw> caribou, if cking is working i suspect you are good, though yours was a slightly differnet use case
<apw> caribou, i applied a change for each of you and cking
 * cking just do the NVME test
<apw> cking,  ?
<caribou> apw: what was cking's problem btw ? mine was a failure when using MODULES=dep
<apw> you just tested nvme booting right ?
<apw> caribou, i don't think he could have his as root
<caribou> in building initrd.img
<apw> caribou, perhaps its safest if we say, could you test :)
<apw> then i can upload those two fixes at least
<apw> and then merge 1.122 or whatever it is
<apw> which has a lot of new bits so will be more frightening
<smb> jsalisbury, Hey Joe, a random question... Did you see any bug reports from Wily or later that may happened on bare-metal servers or KVM guests and crash in run_timer_softirq()? 
<jsalisbury> smb, I don't recall off hand, but I'll review the latest reports to see 
<smb> jsalisbury, ok thanks. Its just a feelign or me wondering. Was looking at bug 1534345 and was not really finding anything striking out in the xen parts. There was some rework of the timer code, though. But then it should be not only Xen/AWS that gets affected...
<ubot5> bug 1534345 in linux (Ubuntu) "Ubuntu 15.10 Crashing Frequently on EC2 Instances w/ Enhanced Networking" [Critical,Triaged] https://launchpad.net/bugs/1534345
<jsalisbury> smb, latest one I see with that RIP is bug 1534345
<jsalisbury> heh, good timing
<smb> jsalisbury, heh yeah
<smb> That was where I was coming from
<jsalisbury> smb, I'll search through some older reports too
<smb> jsalisbury, ok. _IF_ it had anything to do with switching from list_head to hlist in the timer code it would only start with kernel 4.2. But again its just a wild guess right now
<jsalisbury> smb, I don't see any other recent bugs, but I'll keep an eye open for any new ones.  
<smb> jsalisbury, ok thanks
<TJ-> unable to reproduce so far, but today had a v4.4 boot-time kernel panic in interrupts with the CFQ in kernel/sched/fair::update_blocked_averages() 
#ubuntu-kernel 2016-01-21
<phil__> Does anybody here know anything about pam_tally2.so, pam_tally2, and tallylog?
<phil__> Does anybody here know anything about pam_tally2.so, pam_tally2, and tallylog?
<tsimonq2> !patience | phil__ 
<ubot5> phil__: Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
<phil__> Apologies. I feel I've done a fairly extensive search (even of those forums) and I am simply not finding much. I'll remain patient.
<hallyn> Why is master-next xenial kernel giving me gcc: error: unrecognized command line option â-fstack-protector-strongâ
<hallyn>  ?
<Frogging101-chan> I want to append a custom name to the end of the kernel version. But CONFIG_LOCALVERSION breaks the build with the scripts
<Frogging101-chan> How am I meant to do it?
<dsmythies1> hallyn: You are getting "-fstack-protector-strong" becuase you are using an older version of the compiler. Perhaps you are using a 14.04 computer, like me. I just turn it off. Wait a minute...
<dsmythies1> Hallyn: This is as of Ubuntu kernal configuration for kernel 4.4 series.
<dsmythies1> hallyn: run this just before you start the compile: scripts/config --disable CC_STACKPROTECTOR_STRONG
<dsmythies1> hallyn: Or use a new version of the compiler.
<Frogging101-chan> I compiled GCC 5 on my 14.04-based (Mint 17.2) machine. Kernel compiles mostly fine but I'm having other build issues
<hallyn> dsmythies1: i'm on xenial...
<hallyn> but i'll try scripts/config --disable CC_STACKPROTECTOR_STRONG - thanks
<dsmythies1> hallyn: Oh. I thought xenial was suing a new enough version of the compiler.
<hallyn> D'OH!  i bet my environment from an arm cross compiler leaked
<hallyn> sorry for the noise :)  
<dsmythies1> Frogging101-chan: Are you compiling mainline kernel or Ubuntu version? It has been years since I compiled Ubuntu way, so my notes are old.
<Frogging101-chan> dsmythies1: I used Git to checkout v4.4 and applied the .patch files from here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-wily/
<Frogging101-chan> and then I do fakeroot debian/rules do_mainline_build=true binary-generic -j10
<Frogging101-chan> (after setting up configs and setting the CONFIG_LOCALVERSION among other things)
<Frogging101-chan> The CONFIG_LOCALVERSION is what breaks the build; it even says so on some Ubuntu wiki page
<dsmythies1> I just do this: I never seemed to get things to work with the fakeroot stuff. I just do this: "time make -j9 bindeb-pkg LOCALVERSION=-stock"
<Frogging101-chan> what is the reason to use the debian/ubuntu/whatever (can't figure out where that stuff comes from actually) scripts? 
<Frogging101-chan> There seem to be a few different ways to do the same thing and one of them has more caveats
<dsmythies1> or this: time make -j9 olddefconfig bindeb-pkg LOCALVERSION=-stock     (to just use defaults for any new config stuff)
<dsmythies1> Someone will correct me if I am wrong, but you need to use the unutnu methods if you are going to submit chnages or use a PPA. I submit upstream, and not often, so only use mainline kernel, building the way I mentioned.
<Frogging101-chan> ah
<Frogging101-chan> all right
<Frogging101-chan> does Ubuntu only patch the config or are there other patches I should apply to get it close to what Ubuntu has already?
<Frogging101-chan> Because the existing config can be obtained from the OS as it's running already
<dsmythies1> Frogging101-chan: For the PPA you referred to, it is just the mainline kernel. And yes, I just steal the ubuntu kernel config after I install the kernel from that PPA. For the real Ubuntu version (not out yet, but there is a PPA somewhere (Ithink)) , there is a lot of stuff done to it, making it different than mainline.
<Frogging101-chan> well I've been on Git+config patches for a long time. Whatever I'm missing from the Ubuntu kernel doesn't seem to be causing issues
<dsmythies1> Frogging 101-chan: I forgot to mention... After stealing the Ubuntu kernel config, run this: "scripts/config --disable DEBUG_INFO" or it will make an enormous kernel and take twice as long to compile.
<Frogging101-chan> lol
<Frogging101-chan> thanks :p
<Frogging101-chan> what's that, debug symbols?
<dsmythies1> Something like that.
<peaceful> Hi, i just found same bug i have: https://bugzilla.kernel.org/show_bug.cgi?id=110451
<ubot5> bugzilla.kernel.org bug 110451 in Config-Tables "Boot fails on HP 6715s" [Normal,Assigned]
<peaceful> How can i contribute to help solve it?
<peaceful> cant boot laptop with kernel later than 3.19.0-25.26
<peaceful> i also have hp compaq 6715s
<peaceful> need some help to report  bug
<apw> peaceful, so on whatever the last working version is, run 'ubuntu-bug linux', that will make a machine specific bug with your details
<apw> peaceful, then add the infor that the above version is the latest which works, and point to the upstream bugzilla in there too
<apw> peaceful, and then tell me the bug number and i'll find someone to help bisect it
<peaceful> apw, ok but i see someone already reportred this bug. should i report again?
<apw> peaceful, that is an upstream bug, so tracks the fix if any upstream, the ubuntu bug helps us track the fix in ubuntu itself
<peaceful> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1529381
<ubot5> Launchpad bug 1529381 in linux (Ubuntu) "[HP Compaq 6715s] Updating kernel renders system unbootable" [High,Triaged]
<apw> jsalisbury, ^ hey that might be a bisection candidate for you
<peaceful> this i found this
<apw> peaceful, as our kernel has other stable bits on it, it can be a different fix as well
<peaceful> hmm so how can i help to existing ubuntu bug report?
<apw> well firstly you can mark it me-too at the top, you can also say you have the same issue as a comment
<peaceful> okay
<peaceful> apw what means assign to?
<apw> peaceful, the assignee is the person who is owning the problem and who you should talk to before working on it (normally)
<peaceful> should i assign?
<apw> peaceful, to yourself, no it would be an engineer
<apw> and we don't get much hung up on assigning bugs in the kernel, there are so very many of them
<peaceful> ok
<peaceful> i just commented i have same problem
<apw> peaceful, ok this bug implies he found a commit which causes it, so that is quick to test.  i will produce a kernel based on 3.19.0-26.27 with just the commit removed to confirm that is the issue
<peaceful> apw, ah okay, thanks i can test it
<apw> peaceful, the builder is making it now, it'll be a little while
<peaceful> apw, no problem thanks
<apw> peaceful, http://people.canonical.com/~apw/lp1529381-vivid/
<apw> peaceful, ok you will need a linux-image and linux-image-extra for your machine (i386 or amd64)
<apw> peaceful, i386 for 32bit and amd64 for 64bit
<peaceful> apw, thanks
<peaceful> do i need linux-headers too?
<apw> if you don't have dkms packages, then no
<peaceful> not sure if i have
<peaceful> apw, do you work for Canonical?
<apw> peaceful, yeah, on the kernel team
<peaceful> apw, nice :)
<peaceful> Thanks for help i will test right now
<apw> peaceful, having some people who are dedicated to these things cirtainly makes it easier to keep on top of
<peaceful> apw, what's in linux-image-extra package?
<peaceful> some kind of modules(drivers)?
<apw> peaceful, bits you need on real hardware, linux-image is what you need in a virtual machine
<apw> so linux-virtual only needs the first half, linux-generic needs both
 * peaceful installing kernel
<peaceful> apw, i have been frustrated with this problem :( i cant install current released linux distros, they have new kernels :/
<peaceful> and im afraid to upgrade ubuntu
<peaceful> glad i found someone that has same problem as me :)
<apw> yeah it is good to not b unique
<peaceful> im sure all who have hp compaq 6715s experience this
<peaceful> but not many are tech guys who know how to report it :)
<peaceful> apw, to my greatest surprise it booted up!
<peaceful> 3.19.0-26-generic
<peaceful> So now i have to wait for latest kernel release to fixed?
<apw> peaceful, and if you could say that in the bug, under my call for testing
<apw> peaceful, well that commit is applied to upstream stable but it also says we might want to revert it if it causes regressions which it clearly is
<apw> peaceful, cirtainly someone need to investigate why it is blowing things up
<peaceful> apw, ok i will comment that you helped me to fix it
<apw> peaceful, comment to say that the kernel in my comment boots for you, that is useful info
<peaceful> apw, sure
<apw> peaceful, of course that is a vivid kernle, so there very well may not be another kernel for it
<apw> as it goes off support in like 2 weks
<apw> i also note that -26 is _anchient_ compared to vivid
<apw> peaceful, have you tested anything recent at all ?
<peaceful> apw, yep
<peaceful> not booting
<peaceful> i tested 4.3
<apw> ok
<peaceful> I didnt test 4.4, but guy in that bug report seems to ahve tested 4.4
<peaceful> seems kernels later than 3.19.25.26 not booting at all
<apw> now when it doesn't boot does anything happen at all, any kind of error or output
<apw> if you boot without splash enabled
<peaceful> i dont see any error
<peaceful> it kind of stucks sometimes at different text
<peaceful> and after freezing few seconds later black screen
<peaceful> and only way to restart laptop is holding power button
<peaceful> so i have no idea whats causing it
<peaceful> There isnt consistency in showing error messages
<peaceful> Its very strange
<peaceful> But you something did and unbootable kernel booted up
<apw> depending what that text is, getting a picture may be interesting
<apw> right we know the commit which broke things, what is breaking whne its there is less clear
<apw> likely it is a bios issue, given the nature of the commit
<peaceful> apw, hmm
<peaceful> well originaly this pc came with windows vista
<apw> this commit makes it use the 64bit info the bios supplies over the 32bit info, which are supposed to be the same or your bios is broken :)
<apw> cking, ACPICA global things (like acpi_gbl_use32_bit_fadt_addresses) are they exposed somewhere as changable ?
<apw> cking, and remind me what the fadt even is ... stupid acronyms
<peaceful> apw, sorry i dont know :/
<peaceful> not sure what it is
<peaceful> i have 32bit ubuntu now
<peaceful> The guy on bug report has 64bit
<peaceful> even though hp6715s has Amd sempron 64bit processor
<cking> FADT - Fixed ACPI Description Table - this defines various fixed hardware ACPI information vita to an ACPI-compatible OS, such as the base address for the following hardware registers blocks
<cking> *vital
<peaceful> okay
<cking> The PM register block addresses are 32 bit or 64 bit.  There are ways to determine if the kernel should be using the newer 64 bit addresses (like 32 bit fields being zero)
<cking> sometimes firmware gets it broken, e.g. supplying two different 32 bit addresses, one in the 32 bit field in the 64 bit field
<cking> peaceful, the firmware test suite (fwts) can check for a broken FADT, e.g. sudo fwts fadt -
<peaceful> apw, ok i commented on both ubuntu and kernel websites
<cking> apw, the acpi_gbl_use32_bit_fadt_addresses is not tweakable from user space
<apw> cking, dman
<apw> peaceful, yeah if you could run fwts at least we would know it is bios related or not
<peaceful> apw, yes im installing fwts
<cking> https://wiki.ubuntu.com/FirmwareTestSuite/Reference/fadt
<peaceful> sorry guys what was the command to pastebin straight trough terminal?
<cking> pastebinit ?
<cking> peaceful, also output from "sudo fwts acpidump -" would be useful
<peaceful> so the command would be sudo fwts fadt - | pastebinit ?
<cking> i think so
<peaceful> somehow not working: Bad API request, invalid api_dev_key
<peaceful> ok ill do it manually
<peaceful> http://paste.ubuntu.com/14589657/
<peaceful> "sudo fwts acpidump -" : http://paste.ubuntu.com/14589663/
<peaceful> hope it helsp
<apw> cking, so i think fwts says it is fine, but the kernel blows chunks on it :)
<cking> apw, yeah, well, there is a lot of stuff to check ;-)
<peaceful> If i can help giving me you more info just say:)
 * cking eyeballing the commit, kernel source and fwts output
<cking> OK, so there is a bug in the firmware, 32 bit PM2 control block address is 0x00008800, where as the 64 bit PMS control block is 0x0000000000008100
<cking> so the bios has got the 64 bit address wrong, hence the crash. There kernel has to follow what it is given, and the bios is lying on the 64 bit address
<cking> s/PMS/X_PM2_CNT_BLK/
<soee_> how is the work on 4.4 going ? :)
<cking> apw, there should be a acpi_fadt_use_32_bit=[0|1] option, sigh
<peaceful> cking, yeeey!
<cking> apw, so if that fix is reverted, it probably breaks one lot of machines that get the 32 bit variant wrong, where as the commit breaks machines that get the 64 bit variant wrong.
<cking> meanwhile, I'll get fwts fixed up to detect this discrepency.
<cking> peaceful, can you run "sudo fwts --dump" and pastebin the acpidump.log just for reference.
<peaceful> cking, sure
<peaceful> cking, where that file is being saved?
<cking> peaceful, hopefully in the directory you run fwts in
<peaceful> ah yes sure
<cking> :-)
<peaceful> http://paste.ubuntu.com/14589797/
<peaceful> in case you need:
<peaceful> dmesg.log: http://paste.ubuntu.com/14589807/
<peaceful> lspci.log: http://paste.ubuntu.com/14589809/
<peaceful> dmidecode.log: http://paste.ubuntu.com/14589814/
<cking> thanks peaceful.
<cking> apw, so is a revert on that patch the way forward?
<peaceful> cking, thanks you too
<apw> cking, well the problem is the patch was applied in 3.19 and is still there unreverted, so now there is a lot of precident of it being that way round on newer kit
<smoser> hey. looking for some guesses
<smoser> we boot maas on iscsi root using an 'ephemeral image'.  http://maas.ubuntu.com/images/ephemeral-v2/daily/trusty/amd64/ .  In latest daily image 20160119 shutdown fails.  I believe the previous ( 20160114.4/) worked fine.  The manifest diff between the two is http://paste.ubuntu.com/14590395/ .
<smoser> I see on the console of hung system http://i.imgur.com/qEFH4MN.jpg .
<beisner> smoser, similar for me with trusty + trusty kernel http://i.imgur.com/oKzFqvD.jpg
<smoser> beisner, you're on iscsi root also, right ? thats commissioning or install environment of maas ?
<beisner> smoser, deploying node from maas ui or from juju.
<smoser> right.
<peaceful> Hi everyone!
<peaceful> apw, cking any news about my laptop kernel problem? :)
<peaceful> oops
<cking> peaceful, i'm building a kernel with a workaround in it and will update the bug when it's all ready
<peaceful> cking, thanks a lot
<cking> no problem
<peaceful> Will latest kernel releases work on my laptop?
<peaceful> cking, what do you suggest for me to do for example if I want to install ubuntu 15.10 but it has kernel 3.19.25+ which doesnt boot on my laptop?
<cking> peaceful, lets test you H/W with the fix, and if that works and it is acceptible I will need to get the fix into other releases
<peaceful> cking, ah ok thanks a lot
<apw> yeah the wheels of open source grind slow
<cking> especially if we need to test it, SRU it, and release it
<peaceful> Okay :)
<peaceful> Looking forward to it :)
<cking> peaceful, check the bug report, it is ready to try out now
<peaceful> cking, sure thanks
<peaceful> Hi, cking! It works.
<peaceful> 3.19.0-48-generic
<cking> peaceful, excellent. I'll go ahead and SRU this fix. it will take some time to get through to release stage.
<peaceful> at first i forgot to add "acpi_force_32bit_fadt_addr" in grub cmd line
<peaceful> it didnt boot, but after addind that line it booted!
<cking> yay \o/
<peaceful> yey
<peaceful> cking, thanks ;)
<cking> no problem :-)
<peaceful> cking, will this fix be only on ubuntu or other kernels too?
<cking> peaceful, i'll SRU it for Wily and get it into Xenial too
<cking> and for Vivid of course ;-)
<peaceful> cking, thanks a lot
<cking> my pleasure
<apw> cking, i doub you will sru it for vivid, as vivid is dead
<apw> or dead before we get a new sru cycle (i believe
<cking> apw, can I squeeze the fix in, or is it too late for the final SRU cycle?
<peaceful> cking, so kind will i need to use override parameter whenever i use new kernels on my laptop?
<cking> i forgot it's EOL soon
<cking> peaceful, afraid so
<apw> henrix, have we rolled vivid for the last time ?
<henrix> apw: we have; i expect 3.19.0-48.54 to be the last one
<henrix> apw: we will continue to support it in trusty
<peaceful> will this fix be pushed in mainstream kernel? :)
<henrix> apw: so, we're still queuing patches for 3.19 in the master-next branch, which will come into the lts-vivid kernel
<cking> peaceful, yes, I'll do that later today if I get some time
<peaceful> What should i comment here? https://bugzilla.kernel.org/show_bug.cgi?id=110451
<ubot5> bugzilla.kernel.org bug 110451 in Config-Tables "Boot fails on HP 6715s" [Normal,Assigned]
<peaceful> Should i link your kernel with fix?
<cking> peaceful, please do
<xnox> apw, i have run file on the kernel image and it just says that it's a s390 kernel image....
<xnox> is that enough test to figure out the image is or isn't compressed?
 * xnox is not even sure if compressed kernels are supported.
<apw> so i think that is "uncompressed" rather then the vmlinuz which is deffo compressed
<apw> dont think so yet
 * xnox goes to figure out what's happening on the rhel
<peaceful> Thanks for help guys
<peaceful> cking, how long will it take for fixes to go officially?
<cking> peaceful, hopefully end of next week if all goes well
<peaceful> cking, awesome :)
<kfk2> It looks like the IPv4 version of static mfc/dev leaks fix (0e615e9601a15) was not applied to the latest trusty kernel (3.13.0-76.120) but the IPv6 version was (4c6980462f32b); was this a mistake?
<kfk2> I wrote the wrong latest version; I'm looking at 76.121
<apw> kamal, ^
<kamal> apw, kfk2 is correct: this commit got missed for 3.13 or 3.19 -stable (the other one had a Fixes: tag that triggered its inclusion).   I'll get it applied:
<kamal> 0e615e9 net: ipmr: fix static mfc/dev leaks on table destruction
#ubuntu-kernel 2016-01-22
<emmtee> Hi, I managed to rebuild a patched module by issuing sudo make drivers/net/ethernet/atheros/alx/alx.ko from the kernel source root, and it built alx.ko fine.  A reboot doesn't seem to pick it up though.  What I can't understand is that even if I move the original alx.ko out of its home in /lib/modules/.... , the alx module is still loading at boot???  Where is it reading alx.ko from if it is no longer in /lib/modules?  
<emmtee> Is there a cache?  
<apw> emmtee (N,BFTL), there is not a cache no, but there is an updates directory in lib/modules
<decoder> hey
<decoder> i wanted to report a strange issue we've been seeing with the 14.04 kernel lately
<decoder> we're doing extensive fuzzing on the mozilla JS engine both on 14.04 and some old machines on 12.04
<decoder> recently, the developers turned on w^x, a feature to mark jit pages either as writable or executable (for security reasons)
<decoder> since then we've been seeing unexplained crashes on one machine+kernel combination where hardware failure is highly unlikely
<decoder> the crashes seem to be due to instruction pointer pointing at non-executable memory (I see kernel: [8453579.233671] js[23624]: segfault at f76c6000 ip 00000000f76c6000 sp 00000000ffffbfcc error 15) in dmesg and error 15 indicates typically an NX bit error
<decoder> when we inspect core dumps, the memory pointed to is marked executable though
<Odd_Bloke> Are release kernels and HWE kernels handled on the same SRU cadence?
<Odd_Bloke> bjf: (^)
<bjf> Odd_Bloke, yes
<decoder> we hit this kind of bug only on one combination of hardware: an AMD opteron 6272 (32 core) machine with 14.04
<decoder> same hardware with 12.04 is fine
<decoder> other hardware with 14.04 is fine
<decoder> the hardware has ECC memory and doesnt show any errors, nor any other weird crashes indicating hardware failure
<decoder> just nx problems
<decoder> not necessarily related to ubuntu kernel changes, but i dont know where to start :)
<apw> decoder, well if the page is correctly marked, that kind of implies the change in type was not migrated correctly to the CPU itself, those crashes are application level crashes right not the kernel exploding
<apw> decoder, so i'd say its likley a lack of correct tlb flushing, which could easily be kernel and amd/intel specific
<decoder> apw: yes, application level crash. though from the crash information it is then unexplainable why it crashed (instructions that cannot crash + instruction is on executable page according to coredump)
<decoder> sounds reasonable
<decoder> the page not being properly unmarked in the CPU would cause such a symptom
<decoder> apw: do you think I should send this to lkml or is there anything we could try?
<apw> decoder, well if you can figure out what the app is doing to change the permissions (mprotect perhaps) you may have some luck comparing the code that triggers for intel and amd
<apw> decoder, though if it is a single AMD cpu (and other amd are not affected) it may be very hard to work out what semantic need we are not fulfilling
<apw> after that a full specified report with as small as possibl reproduce by to upstream sounds appropriate
<decoder> okay. that might get really hard. the JS engine is such a complex beast
<decoder> and it's the JITs that use this feature
<decoder> ill try to talk to the JS devs and see what we can come up with
<peaceful> hi cking, any news about kernel? :)
<cking> peaceful, it needs to go through the SRU process, get built, regression tested and then releases, so it's another week or so at least
<cking> *released
<peaceful> cking, ah so next week the fix will be in the newest kernel?
<cking> peaceful, perhaps week + a few days
<peaceful> Does it pertain only ubuntu kernels or mainlain kernels?
<cking> ubuntu kernels, and mainline if my fix gets pulled in, but maybe not until 4.6, it depends
<peaceful> cking, ah ok
<peaceful> pretty slow process
<cking> peaceful,  merging in thousands of patches per release takes effort
<peaceful> cking, does it mean downloading ubuntu 15.10 and booting it will have my kernel fix? or not?
<peaceful> cking, i wonder is there a way to download ubuntu 15.10 with older kernel, a kernel that works with my hardware?
<cking> peaceful, no, because the CD image has to be respun for that, which we do for LTS releases only
<peaceful> cking, okay
<cking> as a "point release"
<peaceful> cking, is there a way to replace ubuntu 15.10 iso kernel with other one of my preferance?
<peaceful> So it's possible for me to boot it, install it and use older but working kernel like 3.13 for example
<cking> peaceful, it's only 0's and 1's, so all is possible, but I don't know how
<peaceful> i guess thats a no :)
<cking> if you were to install vivid now, it would work because the ISO does not have the bug in the kernel, then wait for the fix to roll out, and pull in the new fixed kernel 
<peaceful> yeah trust 14.04 works
<peaceful> cking, ok thanks for info :) Im leaving :)
 * cking too it's way past my end of week (again)
#ubuntu-kernel 2016-01-23
<xnox> apw, what does CONFIG_DEBUG_INFO_DWARF4=y do?
<apw> xnox, adds extra more detailed debug info to the debug info in the ddebs
#ubuntu-kernel 2016-01-24
<tjaalton> nfs4 mounts don't seem to cope with suspend, after resume they're stuck
#ubuntu-kernel 2017-01-17
<xnox> rtg, hey hws would like to chat about s390x =)
<hwpplayer1> hi friends , could you please inform me about the current kernel support roadmap 
<hwpplayer1> i'm talking about the default kernel of the distro and the kernel patch services of canonical. i read a local news that says canonical will continue patching 4.8 kernel
<hwpplayer1> i solved my issue about canonical services thanks
#ubuntu-kernel 2017-01-18
<manjo> rtg, could you please apt install dh-autoreconf in xenial-amd64 chroot for tangerine ?
<rtg> manjo, done
<manjo> thank you 
<stgraber> so are you planning a quick follow-up to the latest SRU to sort out bug 1655842? I've got a few systems here (mostly armhf somehow) that are basically non-fonctional because of this.
<ubot5> bug 1655842 in linux (Ubuntu Xenial) ""Out of memory" errors after upgrade to 4.4.0-59" [High,Triaged] https://launchpad.net/bugs/1655842
<apw> bjf, ^
<bjf> stgraber, i'd like jsalisbury to build you a test kernel and verify his reverts work for you 
<stgraber> jsalisbury: can you build me an armhf generic kernel?
<bjf> stgraber, watch that bug, i'm sure he will do so
#ubuntu-kernel 2017-01-19
<LocutusOfBorg> apw, please sync kernel modules from virtualbox
<LocutusOfBorg> 5.1.14 has important fixes
<LocutusOfBorg> also the kernel that will go in 16.04.2 probably needs updates from here https://launchpad.net/ubuntu/+source/virtualbox/5.0.32-dfsg-0ubuntu1.16.04.2
<LocutusOfBorg> apw, I'm back :)
<apw> LocutusOfBorg, the .2 kernel will be the hwe kernel and has (in theory) 
<apw>     Vileda SuperMocio 3 Action Refill - Twin Pack by Vileda
<apw> no not that
<apw> 5.1.6-dfsg-2
<LocutusOfBorg> tooo old
<LocutusOfBorg> 5.1.14 has fixes
<apw> that is what is _in_ yakkety, which is where the kernel comes from
<LocutusOfBorg> so kernel 4.8?
<apw> yes, it will be essentially yakkety's kernel
<LocutusOfBorg> ok fine then
<LocutusOfBorg> fixes are for kernel 4.9+
<LocutusOfBorg> so, please apply them for zesty only
<apw> ack
<LocutusOfBorg> but question: most changes are build fixes for newer kernels, how do you handle them? I can't understand how you can update the kernel without updating vbox kernel modules too
<jsalisbury> stgraber, I'll post a link to a test kernel in bug 1655842? shortly
<ubot5> bug 1655842 in linux (Ubuntu Xenial) ""Out of memory" errors after upgrade to 4.4.0-59" [High,Triaged] https://launchpad.net/bugs/1655842
<montvid> hi there. i would like to ask for a kernel fix as written in http://askubuntu.com/questions/674179/ubuntu-device-flash-fails-on-nexus-7-2013-android-5-0-2-cant-copy-image-to the device is officialy supported but completly not installing for more than a year now. see bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1496756
<ubot5> Ubuntu bug 1496756 in Canonical System Image "Nexus 7 devices which ship with android 5 need revised storage drivers" [High,Confirmed]
<montvid> how come a device that is supported officialy does not work at all for over a year?
<montvid> i asked popey in ubuntu touch and he answered he has no idea what to do...
<montvid> i see people in xda fixed their twrp recovery, made a kitkat boot image and are good. is there a possibility to merge these changes in ubuntu touch kernel?
<montvid> because the nexus 7 device bought in 2015 and later do not install at all. How can it have support if it does not boot?
<montvid> any ideas? 
<montvid> :)
<LocutusOfBorg> montvid, the patch posted on askubuntu is already inside the kernel AFAIK
<LocutusOfBorg> commit 6636bad839d9936e73e48c4841eda83a58fcdb53
<LocutusOfBorg> $ git tag --contains 6636bad839d9936e73e48c4841eda83a58fcdb53 |head -n 1
<LocutusOfBorg> v3.11
<LocutusOfBorg> the first one was kernel 3.11, shipping that fix
<montvid> but nexus 7 is on 3.4.0 as i understand?
<LocutusOfBorg> so, the fix is already there
<LocutusOfBorg> s/is/should be
<montvid> is the fix applied to ubuntu recovery too? because yesterday it did not install. it installed with github files only.
<montvid> https://github.com/ddagunts/UTCWM_N7_patch/blob/master/boot.img?raw=true
<montvid> using this repo i could install ubuntu touch stable
<montvid> i get the same error as in the bug link
<montvid> if i try to use official builds of boot.img and recovery.img
<montvid> thanks for the info LocutusOfBorg 
<LocutusOfBorg> I'm not an Ubuntu kernel developer unfortunately, so I don't know how they patch it
<montvid> well android devices can not change kernel versions. they stay in the same branch nexus 7 2013 is in 3.4 branch and cant go to 3.5 
<montvid> or 3.11
<montvid> can anyone change the bug status from high to critical?
<montvid> because of this bug one cant install and run the system. seems critical :)
<LocutusOfBorg> which bug?
<montvid>  <montvid> hi there. i would like to ask for a kernel fix as written in http://askubuntu.com/questions/674179/ubuntu-device-flash-fails-on-nexus-7-2013-android-5-0-2-cant-copy-image-to the device is officialy supported but completly not installing for more than a year now. see bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1496756
<ubot5> Ubuntu bug 1496756 in Canonical System Image "Nexus 7 devices which ship with android 5 need revised storage drivers" [High,Confirmed]
<montvid> sorry for the dublicate
<LocutusOfBorg> mterry, ^^ seems that I can't change the bug severity :)
<montvid> thanks for trying
<montvid> maybe you could add a comment? i dont have a login...
<LocutusOfBorg> it won't add much value :/
<montvid> i understand. 
<caribou> smb: FYI, uploaded crash 7.1.7-1ubuntu1; autopkgtest found a bug which is fixed in post 7.1.7 so I have just uploaded a ubuntu2 with the upstream fix
<smb> caribou, oh ok. I just recently saw some crash going to the archive but have not looked closely at the version numbers
<caribou> smb: well, it got stucked into -proposed following a failure in DEP8 test
<caribou> smb: the failure is specific to live crash session so I missed it by testing on a _real_ kernel crash
<smb> caribou, Ah, but at least good to see the dep8 testing being good for something
<caribou> smb: indeed; I should have run it before uploading though
<smb> caribou, True, though I must admit that often I forget that part, too. 
<stgraber> jsalisbury: thanks
<jsalisbury> stgraber, good timing.  The build just finished.  Once second, I'll scp it and drop a link
<jsalisbury> stgraber, http://kernel.ubuntu.com/~jsalisbury/lp1655842/armhf/
<stgraber> jsalisbury: thanks. I'll install that on one of the boards and see if it shows OOM over the next 24 hours (it's a jenkins runner)
<jsalisbury> stgraber, thanks
<setuid> Is there a way to parallelize update-initramfs on a test box with hundreds of kernels? 
<setuid> update-grub takes hours
<setuid> It
<setuid> It's a pipeline from a failed apt-get, so running dpkg --configure -a 
<setuid> This sort of works, but it's ugly: ls -1 /boot/vmlinuz* | cut -b9-40 | while read line; do sudo update-initramfs -c -k $line & done;
#ubuntu-kernel 2017-01-20
<apw> setuid, i have to say in that situation i have temporarily replaced update-grub with "exit 0" done the updates and then put it back, running it once at the end
<leitao> rtg, hi. It seems that 16.04 is not able to build 4.8 Zesty kernel 
<leitao> it fails with the .TOC
<setuid> apw, I have a script that cuts it down to 6m30s for 308 kernels, so it's running fast
<setuid> well... fast-ER
<rtg> leitao, try reverting "powerpc: Simplify module TOC handling"
<leitao> in the kernel?
<rtg> leitao, yup
<leitao> ok
#ubuntu-kernel 2017-01-21
<kees> I'm finally playing with SecureBoot! :)
<kees> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1658255
<ubot5> Ubuntu bug 1658255 in linux (Ubuntu) "Kernel not enforcing module signatures under SecureBoot" [Undecided,New]
<apw> kees, 
<apw> kees, would you dump in a dmesg on that one please
<hwpplayer1> Hi 
<hwpplayer1> Could you please show me the documentation for live kernel patch 
<hwpplayer1> I need more details
<apw> hwpplayer1, what sort of details are you looking for (so i can figure our who is best placed to help you)
<hwpplayer1> how it works , which protocols , source code of service 
<hwpplayer1> i want to create a new technical support and collaboration service 
<hwpplayer1> which different teams work on the same issue / computer
<hwpplayer1> if i can learn how canonical patch , i can design a clean service
<apw> the live patches themselves use the in kernel live patching facilities
<hwpplayer1> yes beginning from 4.x
<apw> the patches themselves are generated by a team of people and batched up
<apw> into release packages which are provided via a canonical service hosted in-house
<apw> i will let people know you are asking and they may have more details to share
<hwpplayer1> okay , if it is a basic server - client model 
<hwpplayer1>  than we can expand it with different models
<apw> the livepatch service installs a daemon which handles aquisition and delivery of livepatches
<hwpplayer1> the daemon works like an init ?
<apw> it runs all the time yes
<hwpplayer1> apw : thanks , i'm searching other things related , by the way i work with hardened team , i'm new , not accepted to the team yet
<apw> ahh ok
<hwpplayer1> Patch Analysis                                                                                                                                                 --------------                                                                                                                                                                                                                                                            
<hwpplayer1> sorry
<hwpplayer1> http://paste.ubuntu.com/23839078/
<hwpplayer1> So we need more hackers
#ubuntu-kernel 2018-01-15
<f_g> jsalisbury: I/we don't have any affected hardware for testing, and our production kernel has the problematic commit reverted currently. if alkisg does not report back, feel free to ping me and I can see about spinning up a test kernel and attempting to convince our affected users to try it out ;)
<alkisg> It's rainy today, I'm not sure I'll be able to bike to the affected school...
<alkisg> OK, I got remote access, testing http://kernel.ubuntu.com/~jsalisbury/lp1742630/i386/linux-image-4.13.0-25-generic_4.13.0-25.29~lp1742630_i386.deb
<f_g> apw: the 4.4 origin/pti branch is missing GPR scrubbing on vmexit for Intel / VMX
<f_g> the upstream mainline commit has both Intel and AMD in one commit, your branch contains one by AMD for AMD only
<f_g> a1c61c3a6dec6fca6380fa7aa294978dc84e616c in xenial's pti branch
<f_g> 0cb5b30698fdc8f6b4646012e3acb4ddce430788 in mainline
<alkisg> jsalisbury: in cooperation with the school teacher, he tells me that  4.10.0-42 boots, your 4.13.0-25 does NOT boot, and the stock 4.13.0-26 does NOT boot either
<alkisg> Also, now I have 3 schools affected
<bjf> alkisg, i can't tell if your saying that jsalisbury's test kernel also does not boot
<alkisg> bjf: exactly, jsalisbury's test kernel does also not boot
<alkisg> I can go visit some school in person if that can somehow help
<alkisg> E.g. maybe I could boot with `debug` and get some better error message than "it reboots"... :)
<f_g> alkisg jsalisbury: we've had positive feedback from affected users for our kernel with the revert, and Debian went the same route in their 4.9 (which got the buggy commit via -stable it seems?). maybe that would be the better short-term option given the lack of response upstream, especially with users being forced to 4.13 from a previously working 4.10..
<alkisg> f_g: I don't know your case exactly, but if you have a kernel with some reverted commit that I could test, different from the one of jsalisbury's, I'd be glad to
<alkisg> (i386 only here though)
<apw> f_g, what bug number is that ... 
<apw> alkisg, if someone can tell me what patch we are reverting i can give yuo a kernel to test at least
<f_g> alkisg: it's a derivative, so it's not a stock Ubuntu kernel. amd64 only as well, so that is likely not much help to you. you can just do a git revert of the offending commit, bump the version and build your own (for testing purposes). the ubuntu wiki has details ;)
<f_g> apw: the scsi/libsas one? #1726519
<apw> f_g, the one you and alkisg are talking about
<alkisg> apw: jsalisbury mentioned https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742630
<ubot5> Launchpad bug 1742630 in linux (Ubuntu Artful) "Booting from 4.13 leads to Oops: NULL pointer dereference - RIP: isci_task_abort_task+0x30/0x3e0 [isci]" [High,Triaged]
<f_g> both are the same bug ;)
<alkisg> I tested his kernel but it did NOT solve the issue
<apw> alkisg, his was adding the "likely fix" i assume
<apw> f_g, and 909657615d9b ("scsi: libsas: allow async aborts") is what you reverted with success ?
<f_g> apw: exactly
<alkisg> apw: he's mentioning what he did in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742630 comment #5
<ubot5> Launchpad bug 1742630 in linux (Ubuntu Artful) "Booting from 4.13 leads to Oops: NULL pointer dereference - RIP: isci_task_abort_task+0x30/0x3e0 [isci]" [High,Triaged]
<apw> alkisg, and did you test the kernl he refers to comment #34 which to my eye claimes the revert is applied ?
<alkisg> apw: exactly, although he had to rebuild for i386 just for me
<apw> bah, i need to smack him, there are no patches in that directory
<apw> alkisg, and it did not fix you is that also true ?
<alkisg> Hehe
<alkisg> apw: the school teacher that tested jsalisbury's kernel reported that it did not boot
<alkisg> I installed it for him, he said he got a black screen when he selected it in grub, and then he booted with the previous 4.10 kernel
<alkisg> apw: if you spin an i386 kernel for me, I can test it as soon as it's ready
<alkisg> (in person)
<apw> no it appears if you had an i386 built then it wasn't that one
<alkisg> apw, that one: http://kernel.ubuntu.com/~jsalisbury/lp1742630/i386/
<apw> alkisg, right, that actually #34 points to this one, which has no i386 ... http://kernel.ubuntu.com/~jsalisbury/lp1726519/
<apw> alkisg, so i don't think you have actually tested the revert, but some other "likely fix"
<alkisg> apw: jsalisbury's prepared an amd64 build with the revert. I told him I don't have amd64 to test with that, and he issued another build of that just for me
<f_g> apw: that likely fix comment is by me - I based that on the Fixes stanza and commit message, like I said I don't have any affected hardware to test.
<alkisg> apw: so afaik they both have the same fix; but jsalisbury would know more...
<apw> alkisg, right but the one you just pasted to me, is not the same build ... it is a build pointed to by the "likely fix" commit
<alkisg> ok
<f_g> there is one user reporting that the patched kernel fixes the issue, so maybe alkisg's "does not boot" is unrelated
<apw> alkisg, so i would say basically we have no idea because jsalisbury didn't include the patches in the results so we cannot tell ... *grrrr*
<apw> alkisg, so all i can suggest is i build you an i386 with that definativly reverted
<alkisg> apw, if you can build/point me to an i386 build with the revert, I can test it immediately
<apw> ok
<alkisg> Cool
<apw> alkisg, so this is a xenial linux-hwe ... right ?
<alkisg> Right
<f_g> alkisg: if you go there in person, it would be good to check if you get an oops that matches the description. all the reports I have print the oops loud and clear right at boot
<alkisg> f_g: I can arrange to be there in half an hour; the problem is I can't stay there for a loooong time, let's say half/one hour
<alkisg> So, it'll be best if we gather whatever I need to test before going there
<f_g> alkisg: yes, having the kernel with revert at hand for testing is a good idea :)
<apw> alkisg, you can test this kernel remotely i think ?
<alkisg> apw: sure, but I don't mind going there, in case I can get more info with "debug" or something
<apw> alkisg, lets see if it is this i guess :)
<alkisg> ok
<apw> alkisg, http://people.canonical.com/~apw/lp1726519-xenial/
<alkisg> apw: ty
<alkisg> Eh the teacher left the school, I'll go there and test in 30'
<apw> how annoying
<apw> you need a school in your house, the only sensible solution :/
<f_g> apw: missing the GPR scrub on vmexit for VMX in 4.13/pti as well (compared to mainline again)
<apw> f_g, yep, thanks, will get that replaced, what a mess the world is right now
<f_g> indeed.
 * apw wonders how alkisg is getting on
<apw> f_g, pti branch is updated with those now, pending them passing some kind of testing
<apw> alkisg, any luck?  we are running out of runway to include anything in this respin
<f_g> apw: we've been running with them for a week already without any negative reports
<apw> f_g, great, the vmx one i am pretty confident with as they were clean applications
<apw> it is the other thing that is worrying me right now, but it may become moot fairly soon
<f_g> yep, the vmx part is from google to fix a google PoC - I guess that part is already pretty battle-tested ;)
<f_g> apw: initial limited testing looks good for both 4.4 and 4.13
<f_g> I hope re-integrating the pti branches with mainline RETPOLINE won't cause too much problems - lots of user out there still running affected CPUs that will never get IBRS and IBPB
<apw> f_g, upstream will be adding ibrs/ibpb on top of their reptoline, once that exists and stops moving we'll be wanting to flip to that
<alkisg> apw: sorry, I went to the school but there were many students in the computer lab and it was very hard to reboot. I did install the kernel, and I'm waiting for the result tomorrow morning.
<alkisg> (eh, I didn't explain that we're using a server/netbooted client model, and the problem happened on the server)
<apw> okies, tehn we'll ignore that one for now
<jsalisbury> alkisg, f_g I'm reviewing the scrollbck on this channel now.  I'll review the bug comments too, but it sounds like the kenrel posted in comment #5 of bug 1742630 does not boot for you, alkisg?  Did the kernel apw built for you resolve the bug?
<ubot5> bug 1742630 in linux (Ubuntu Artful) "Booting from 4.13 leads to Oops: NULL pointer dereference - RIP: isci_task_abort_task+0x30/0x3e0 [isci]" [High,Triaged] https://launchpad.net/bugs/1742630
<alkisg> jsalisbury: correct, your kernel didn't boot, I'll know tomorrow about apw's kernel
<jsalisbury> alkisg, ok, thanks!  
<alkisg> Thank you too :)
<jsalisbury> alkisg, if you can, can you grab a screen shot of diginal picture of my kernel when it does not boot?
<jsalisbury> s/of/or/
<alkisg> jsalisbury: sure; will "debug" help more?
<alkisg> I'll check both anyways
<jsalisbury> alkisg, it would be good to see if there is a panic or stack trace for my test kernel
<alkisg> ok
<jsalisbury> alkisg, I'd like to send that info upstream as well, and provide feedback on the patch.
<jsalisbury> IDENTIFY jsalisbury
<apw_> he shoots ... and misses
<jsalisbury> heh
#ubuntu-kernel 2018-01-16
<alkisg> apw: the school reported that your kernel didn't boot either
<alkisg> It sounds like a different issue
<alkisg> I'm currently at one of the affected schools where that "immediately reboots" issue happens, with xenial-hwe
<alkisg> I tried terminal-output=console in grub, removing quiet splash, adding debug... I can't get anything at all, it reboots 2 secs after loading kernel/initramfs
<alkisg> I have the exact same hardware at my office, and the problem doesn't happen there with the same kernel
<alkisg> Any suggestions to try would be most welcome :)
<alkisg> (or even test kernels)
<alkisg> apw: is that new kernel respin that you did yesteray (for all, not the one just for me) available somewhere, e.g. in -proposed, to test with that one?
<apw> alkisg, that is horribel symptoms to work with, if you have the same h/w and nothing
<apw> alkisg, i wonder what cpu microcode it hsa installed
<apw> alkisg, should be hitting -proposed "now", you can find the builds that will move in the CKT PPA though you need to take great care getting kernels from there to make sure they are consistent
<apw> alkisg, ie you cannot sensibly add that PPA to apt
<apw> alkisg, also they are not signed in there if efi secure boot is a thing you care about
<alkisg> apw, one difference that I just thought of, is that schools have i386 while in the office I have amd64 installation
<alkisg> office intel-microcode: 3.20170707.1~ubuntu16.04.0
<apw> that is old microcode so not likely that
<alkisg> school => same one
<apw> alkisg, and this is 4.13 on xenial right ?
<alkisg> (it's xenial with hwe and fully updated)
<alkisg> Right
<alkisg> Let me see if I can make sense of the ckt ppa.. 
<alkisg> Ah, another difference is that I'm using uefi, they're booting with legacy (exact same hardware, batch purchase)
 * alkisg tests 4.13.0-29.32~16.04.1  from the ppa...
<alkisg> https://launchpad.net/~canonical-kernel-security-team/+archive/ubuntu/ppa/+build/14230584
<alkisg> apw, that had the same symptoms, "reboot in 2 secs after loading initramfs, without displaying anything at all in the screen"
<alkisg> I'll try to download the 64bit kernel that I have at work, and boot the 32bit userspace with the 64bit hwe kernel, and see if that makes it better...
<alkisg> apw: I tried the kernel from the PPA. The i386 kernel reboots. The amd64 kernel (on the same i386 installation) BOOTS correctly.
<alkisg> So the problem that my schools report (about 10 so far) happens only on i386 architecture.
<apw> alkisg, hrm, ok ... thinking
<alkisg> The good thing is that I'll probably be able to reproduce it at the office now that I know the problem is i386 vs amd64
<apw> it is a shame one cannot install a 32bit kernel in 64bit for testing
<alkisg> It doesn't happen with VMs though; my i386 virtualbox VM boots fine
<alkisg> It does show some pagefault something, which it didn't show in the past, but it continues fine
 * apw tries to get some testing done on this, hrm
<apw> alkisg, i wish we had a 64bit kernel for use in 32bit installs, it is hard to see how it would not be a sensible option to take always
<Caribou> Hi, any reason why the linux-meta pkg has a higher rev in Artful-proposed than in Bionic ?
<Caribou> linux-meta | 4.13.0.25.26   | bionic           | source
<Caribou>  linux-meta | 4.13.0.29.31   | artful-proposed  | source
<apw> Caribou, because bionic is lagging against -proposed currently
<apw> that has been respun so many times, we would be making people sad if it was updated so very often
<Caribou> apw: :-)
<Caribou> apw: just trying to fix lp: 1743537 that I just created
<ubot5> Launchpad bug 1743537 in linux-meta (Ubuntu) "linux-crashdump meta-package does not exist for arm64" [Undecided,New] https://launchpad.net/bugs/1743537
<Caribou> nothing urgent but I just fumbled over it
<alkisg> apw: sorry, I tried to run my 32bit virtualbox installation and it crashed my amd64 host. Twice. :)
<alkisg> I haven't seen anything you might have written after the last time I wrote something
<apw> just saying i would get some testing done, and see if we can see it here
<apw> and musing that it would be nice to have a 64bit kernel for 32bit userspace
<alkisg> I *thought* I tested my 32bit VM, but maybe I hadn't fully updated then, not sure. For now, and AFAIK, the 32bit kernel doesn't boot anywhere, even in VMs
<apw> as that would likely always be a better idea
<alkisg> OK, thanks for everything, I'm leaving the school now, I'll be online later.
<apw> alkisg, ack thanks, will let you know what we find here
<alkisg> apw, at home now, same setup as the office. New "find": when I boot my 64bit host with 4.13, and I try to launch my 32bit virtualbox VM, the HOST hangs
<alkisg> When I boot the host with 4.10, it works fine
<alkisg> I'll try removing intel-microcode, to see if that's to blame
<apw> alkisg, hrm, ok thanks will get that on the to-investigate list
<alkisg> I'll continue reporting new finds here; hopefully that's something helpful and not annoying :)
<apw> yep
<alkisg> I reverted intel-microcode to 3.20151106.1, it didn't help
<alkisg> I'll try to find the latest *pre-spectre* 4.13 kernel to see if it happened there as well
<alkisg> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.16/ has the same issue
<alkisg> I have a better description of this issue: with 4.13 and 64bit installations, when starting virtualbox clients, the HOST crashes with this: https://snag.gy/HkOoeK.jpg
<alkisg> Starting the same client with kvm works fine. This issue may be unrelated to the other one that I reported previously, that "4.13 reboots in 2 secs in 32bit clients". I'll investigate more.
<thresh> how would I go about applying a patch on top of apt-get source'd kernel?
<thresh> would `cat foo.patch | patch -pN;  dpkg-buildpackage -us -uc` work?
<apw> thresh, might do indeed
<apw> with a -b to say binaries
<jsalisbury> alkisg, would it be possible for you to open bugs in launchpad for the issues you are seeing?  That will help us keep track of all the data and investigate more efficiently.  
<alkisg> jsalisbury: of course, I just wanted to be able to reproduce it locally in my office first, so that I'm able to give proper feedback, without relying on remote teachers
<alkisg> jsalisbury: the vbox issue is filed in https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1736116, so we can ignore it
<ubot5> Launchpad bug 1736116 in virtualbox (Ubuntu) "Host with kernel 4.13 freezes when starting a VM with VirtualBox" [High,Confirmed]
<jsalisbury> alkisg, great, thanks!
<alkisg> Thank you too
<tkamppeter> Hi
<tkamppeter> I have a problem with a USB printer. When I unplug it, it does not correctly unregistered from systemd.
<tkamppeter> "systemctl list-units" still shows
<tkamppeter> sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d1.device                                     loaded active plugged   Deskjet_2540_series
<tkamppeter> after unplugging.
<tkamppeter> xnox told me that it is a kernel problem.
<TimStarling> jsalisbury: regarding https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742602
<ubot5> Launchpad bug 1742602 in linux (Ubuntu Artful) "Blank screen when starting X after upgrading from 4.10 to 4.13.0-26" [High,Incomplete]
<TimStarling> 4.14rc1 works, which I think just leaves 12600 commits to choose from?
<TimStarling> so bisection would take about 14 iterations, right?
<TimStarling> and each iteration would require recompiling?
<TimStarling> I'll just say it on LP
#ubuntu-kernel 2018-01-17
<jsalisbury> TimStarling, I added comment to the bug as well.  If you can confirm 4.13 final is bad, I'll start a bisect between 4.13 and 4.14-rc1.  
<TimStarling> jsalisbury: I was worried you'd be off for the night, I see you are US east
<TimStarling> I'm UTC+11, 11:53 am, so I can keep doing this for a while yet
<jsalisbury> TimStarling, I check in here an there after the usual hours :-)
<TimStarling> I replied on the bug about 4.13 final
<jsalisbury> TimStarling, cool, I see it's broken, so I'll start the bisect and post the first kernel when it's built.
<TimStarling> would you be interested in having ssh root access to it overnight my time? I'm pondering whether I can set something up for that
<TimStarling> maybe a proper (debootstrap) install to a USB stick, then it could boot up without intervention
<jsalisbury> TimStarling, not sure I like the liability associated with having remote root access.  But at any rate, I built the first test kernel and posted it.
<TimStarling> it's slow to download, ~40KB/s, seems slower than the mainline ones, will take at least 10 minutes
<TimStarling> supposedly I have a 28 Mbps wired connection
<TimStarling> stupid internet
<TimStarling> it was saying it would take another 40 minutes, so I downloaded it to my linode instance and then from there to home
<TimStarling> which was 100x faster
<TimStarling> tested it, reported "fixed"
<TimStarling> next time I'm downloading it via ssh -D
 * thresh dances
<thresh> looks like launchpad #1742721 is fixed for me \o/
<ubot5> Launchpad bug 1742721 in linux (Ubuntu Artful) "linux-image-4.13.0-26-generic / linux-image-extra-4.13.0-26-generic fail to boot" [Critical,In progress] https://launchpad.net/bugs/1742721
<alkisg> thresh: I think my schools have the same issue, did you use jsalisbury's kernel from comment #18 there?
<thresh> yep, as I've said in #19 :)
<thresh> the issue was the framebuffer driver being broken
<alkisg> thresh: which graphics card is that? I see this in i5's with internal graphics...
<thresh> 26:00.0 VGA compatible controller: Silicon Motion, Inc. SM750 (rev a1)
<thresh> and the kernel module is sm750fb
<alkisg> Thank you, so it must be unrelated to my case :)
<thresh> too bad!
<alkisg> Yeah, I'll have to do a kernel bisect too when I get again to one of those schools
<alkisg> Probably tomorrow
<thresh> that's never fun
<thresh> but at least you've got a physical access :-)
 * alkisg wonders if we can program grub to boot to a specific test kernel only once...
<thresh> we can, it's called grub-reboot
<thresh> https://wiki.debian.org/GrubReboot
<alkisg> Ah cool then, I'll try that
<thresh> but you have to be careful with all the submenu subtleties
<alkisg> OK, I think that will be the same as GRUB_DEFAULT there, so I know the syntax
<thresh> yep
<alkisg> 0>2 for submenus etc
<tkamppeter> Hi
<tkamppeter>  I have a problem with a USB printer. When I unplug it, it does not correctly unregistered from systemd.
<tkamppeter> "systemctl list-units" still shows
<tkamppeter>  sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d1.device                                     loaded active plugged   Deskjet_2540_series
<tkamppeter> after unplugging.
<tkamppeter>  xnox told me that it is a kernel problem.
<TJ-> Do we have any tools for intelligently comparing dmesg logs ignoring timestamps and slight numeric-value differences? I'm /trying/ to debug a loss of all USB devices when kexec-ing (4.13.0-25-lowlatency - but affects all versions tested so far) 
<TJ-> tkamppeter: would/should that be handled by a udev 'remove' rule? 
<tkamppeter> xnox, around?
<andrebrait> Hi there, guys. I'm looking for some advice on a bug I've found (and reported) in the linux-firmware package, regarding a Qualcomm wi-fi controller firmware. I feel it's a rather important bug and it has a rather trivial fix (which has been in upstream for about 3 months). It's been introduced in Xenial when the 4.13 HWE kernel landed (it's also pr
<andrebrait> esent in Artful as of this moment). I've been to #ubuntu-bugs and they recommended I should come here to ask for advice on this. The bug in question is reported in LP1743279.
<TJ-> bug #1743279
<ubot5> bug 1743279 in linux-firmware (Ubuntu) "QCA6174 stops working on newer kernels after second group rekeying" [Undecided,Confirmed] https://launchpad.net/bugs/1743279
<apw> sforshee, ^
<sforshee> andrebrait: thanks, I saw that bug and it's on my todo list
<andrebrait> sforshee Oh, ok. I got worried because it's kind of a big deal and I didn't know if someone had seen it or not. Let me know if I can be of any further assistance.
<sforshee> andrebrait: I'll try to get a test package done "soon" (hopefully today) and post it to the bug so you can confirm that it works
<andrebrait> sforshee If that helps, can I create the package or follow some instructions as per http://packaging.ubuntu.com/html/fixing-a-bug.html
<sforshee> andrebrait: thanks, but that's not necessary
<andrebrait> sforshee Ok then. Thanks a lot. :)
<tkamppeter> TJ-, xnox, USB unplug problem solved, was not kernel, as I upgraded to Bionic, not even rebooted into the new kernel, and problem went away, so was probably UDEV or systemd.
<TJ-> tkamppeter: ahhh, corner-case then :) I wish my issue was so easily solved :D
<mamarley> Yesterday I encountered an odd issue when I tried to plug my Pixel XL into a USB3 ExpressCard in a laptop.  It initally seemed to work but as soon as I tried to put it in file transfer mode, file transfer didn't work and I got "usb 9-1: can't set config #1, error -28" and a bunch of "usb 9-1: Not enough bandwidth for new device state." in dmesg.
<mamarley> I'm not sure if this is a bug or just something with my setup, which is why I decided to ask here first.
<TJ-> mamarley: which controller took the port? xhci or ehci  ?
<mamarley> TJ-: It is an add-in USB3 card that only has an XHCI controller.
<mamarley> A "Renesas Technology Corp. uPD720202 USB 3.0 Host Controller" to be specific.
<TJ-> mamarley: but the controller supports high/full/low-speed devices too, and that should mean the kernel's xhci module *may* hand over to another module if the port doesn't show as SS - does dmesg indicate if the newly discovered device us superspeed or high speed?
<xnox> tkamppeter, or probably dbus
<xnox> as one cannot restart that one on upgrade
<xnox> tkamppeter, so.... all of your udev rules and jobs work fine now, and you have no more bugs open against systemd?
<tkamppeter> xnox, my current udev rules and jobs work, as s-c-p upstream has worked around the quote/unquote problem, the quote/unquote problem, bug 1721839, still persists, only it is not release-critical any more.
<ubot5> bug 1721839 in systemd (Ubuntu) "[REGRESSION] Services asked for by UDEV do not get triggered" [Critical,Confirmed] https://launchpad.net/bugs/1721839
<tkamppeter> xnox, unplugging problem, which affected both ippusbxd and system-config-printer services is fixed, ippusbxd was never affected by bug  1721839, only system-config-printer, but newest s-c-p upstream works around the problem.
<ubot5> bug 1721839 in systemd (Ubuntu) "[REGRESSION] Services asked for by UDEV do not get triggered" [Critical,Confirmed] https://launchpad.net/bugs/1721839
<tkamppeter> xnox, why could the unplugging problem be caused by dbus?
<mamarley> TJ-: It shows up as a SuperSpeed device.
<TJ-> mamarley: does "lsusb -v -d VVVV:PPPP" show anything strange in the EndPoint Descriptor's wMaxPacketSize ?
<mamarley> TJ-: That command outputs nothing.
<TJ-> mamarley: VVVV:PPPP is the vendor:product IDs :D
<mamarley> d'oh
<TJ-> mamarley: the xhci.c source indicates the 2 bandwidth errors generated when trying to configure endpoints, so there may be some clue in that info, although I'm not sure what would cout as 'bad' :)
<mamarley> TJ-: It says "wMaxPacketSize     0x0400  1x 1024 bytes" 5 times for different interface descriptors.
<TJ-> mamarley: I don't have a similar device here to compare against
<mamarley> I'm pretty sure it has something to do with that one controller because if I plug the same phone into my desktop or my other laptop (both of which have Intel XHCI controllers) it works properly.
<TJ-> mamarley: it would make sense. I've just been comparing outputs here. Using "sudo lsusb -v -d VVVV:PPPP" with the 2 root hubs exposed by the controller ("Linux Foundation X.0 root hub") - maybe that will provide some clue
<mamarley> TJ-: https://paste.ubuntu.com/26405967/
<TJ-> mamarley: so "0000:0d:00.0" is the PCI device ?
<mamarley> TJ-: Wait, I somehow screwed that up and posted the output of one of the EHCI USB2 root hubs.  The USB2 root hub from the XHCI controller is actually https://paste.ubuntu.com/26405994/.
<mamarley> Not that it matters since the device is on the USB3 root hub anyway.
<mamarley> And yes, that is the PCI device.
<TJ-> mamarley: when the Pixel XL is connected is it listed by lsusb ? if so can you pastebin "sudo lsusb -v -d ..." for it?
<TJ-> mamarley: also, does this happen after a suspend/resume or (also) on a cold/fresh boot ?
<mamarley> TJ-: It is indeed: https://paste.ubuntu.com/26406010/  (I don't know why it says it is a Nexus 4; it is most definitely a Pixel XL.)
<mamarley> It happens starting the first time I plug in the phone after booting the PC.
<TJ-> mamarley: is that "lsusb" when the Pixel is in file-transfer mode? if not, can you put it in that mode and redo the lsusb ?
<TJ-> mamarley: OK, so not an ACPI/device-reset issue
<mamarley> TJ-: Yes, I put it in file transfer mode before capturing the data.
<mamarley> I also tried turning off ADB to see if that had any effect, but it did not.
<TJ-> mamarley: you notice the device shows 3 endpoints for the MTP interface? I wonder if there should be an "EP 2 OUT" to match the "EP 2 IN" - any chance you can check that on another PC (and capture the lsusb output for that too so we can compare) ?
<TJ-> mamarley: I also notice EP 2 IN has bMaxBurst == 0 which looks strange
<mamarley> TJ-: OK, here it is plugged directly into the USB-C port on my desktop: https://paste.ubuntu.com/26406045/
<TJ-> mamarley: OK, so the value is the same but ...
<TJ->  ... the laptop is getting the bandwidth error, so something different is causing the driver to miscalculate the total
<mamarley> I have found a few similar reports on various bug trackers, but those all seem to happen when multiple devices are plugged in and can be worked around by unplugging other devices.  In my case, the phone is the only device plugged in to that controller.
<TJ-> mamarley: yes, I saw the RH report with no conclusion has been ongoing for a while
<TJ-> mamarley: which kernel version is it?
<mamarley> TJ-: 4.15-rc8 from the mainline builds.
<TJ-> mamarley: I notice your error -28 and in drivers/usb/host/xhci.h I see "#define COMP_STOPPED_SHORT_PACKET   28" 
<TJ-> mamarley: does the same error occur for all (Ubuntu) kernel versions  ?
<mamarley> I haven't tried it on any other kernels yet.  It looks like that define wasn't introduced until 4.11, so I will try 4.10.x and see what it does.
<TJ-> mamarley: No, it just changed from COMP_SHORT_TX like many others
<mamarley> Ah, OK.
<mamarley> It looks like it would be printing a different warning if it hit that condition anyway.
<mamarley> TJ-: After painstaking tracing through lots of kernel code, it looks like my error is probably coming from drivers/usb/host/xhci.c:1787 (that is the only place in the XHCI driver that returns -ENOSPC, which is -28).
<mamarley> But, besides the definition and a user-friendly string converter, that is literally the only usage of COMP_BANDWIDTH_ERROR and COMP_SECONDARY_BANDWIDTH_ERROR in the entire kernel.
<mamarley> It looks like that value is coming back from the controller itself, so the controller must be bugged.
<TJ-> mamarley: I wonder if commit da997066894817 is responsible? Did you test on the early kernels?
<mamarley> TJ-: That's not even my controller (mine is 0x0015).
<TJ-> mamarley: your device /is/ already there using the same quirk. Can you pastebin the dmesg? Looks like it should also contain "QUIRK: Resetting on resume"
<mamarley> TJ-: https://paste.ubuntu.com/26406653/
<mamarley> And I just tried kernel 4.4.0, it suffers from the same problem.
<TJ-> mamarley: do you have another ExpressCard PC to test the controller in? (wondering if the PCI/e config is responsible
<mamarley> TJ-: I was wondering that myself, but sadly this is an ExpressCard/54 card and my other laptop only has an ExpressCard/34 slot.
<TJ-> mamarley: looking at dmesg indicates xhci is applying XHCI_SPURIOUS_SUCCESS and XHCI_RESET_ON_RESUME quirks: "hcc params 0x014051cf hci version 0x100 quirks 0x00000090"
<TJ-> mamarley: shame. I've got 6 here!
<TJ-> mamarley: any other USB 3.x devices you can test besides the Pixel ?
<mamarley> No, sadly.  Only a bunch of USB2 devices.
<TJ-> mamarley: any USB3 hub you could interpose between Expresscard and Pixel?
<mamarley> Nope, I don't even have any USB2 hubs.
<TJ-> mamarley: ooo, that might be a useful test, a USB2 hub to force the port to use USB2
<mamarley> I could replicate that by only partially plugging in the USB cord, not allowing the extra USB3 contacts to touch.
<TJ-> mamarley: :D now there's the sign of proper hacker :p
<TJ-> mamarley: not the chipset, but what is the make/model of the ExpressCard - I might be able to find one
<mamarley> TJ-: In USB2 mode, it works fine.  The card is a StarTech ECUSB3S254F.
 * mamarley wonders if this might be because this old laptop only has 2.5gT/s PCIE and not 5.0gT/s.
<TJ-> mamarley: that's a very good point
<TJ-> mamarley: does "sudo lspci -vvvnnk -d xxxx:yyyy" confirm that via LinkSta:~Speed  and LinkCtl2:~Target Link Speed?
<mamarley> TJ-: "LnkSta: Speed 2.5GT/s", "LnkCtl2: Target Link Speed: 5GT/s"
<TJ-> mamarley: Yes, that's from the COMP_BANDWIDTH_ERROR I was looking at originally
<TJ-> mamarley: Ignore ^^^^ I was scrolled back up in the history :D
<TJ-> mamarley: right, so it could be the xhci_reserve_bandwidth() ought to be considering the upstream PCI port for determining the maximum, not just what the USB3 controller reports
<mamarley> It looks to me like the error is coming straight from the controller itself, not from the driver.
<mamarley> The only way it can ever return -28 is because of the COMP_BANDWIDTH_ERROR or COMP_SECONDARY_BANDWIDTH error directly from the controller.
<TJ-> mamarley: I wonder if the   XHCI_SW_BW_CHECKING quirk might help
 * mamarley busts out the compiler.
<mamarley> Oh wait, apparently the module has a "quirks" command line option.
<TJ-> mamarley: mamarley yes... I think it needs quirks=0x20 ?
<mamarley> Yeah, I was trying to find documentation on how to use that argument.
<TJ-> presumably command-line since module is built-in, xhci_pci.quirks-0x20 ??
<TJ-> mamarley: presumably command-line since module is built-in, xhci_pci.quirks=0x20  (since the flags are only additive - it won't remove deefault quirks)
<mamarley> TJ-: How are you getting 0x20?
<TimStarling> jsalisbury: I can test another bisection kernel in about an hour from now if you compile one before then
<TJ-> mamarley: by reading the wrong option! I was remembering the << 4 option but it's "#define XHCI_SW_BW_CHECKING     (1 << 8)" here so 0x0100 :)
<mamarley> Yeah, I was going to say my C is a bit rusty, but it seems like 1<<8 ought to be 0b100000000 or 0x100.
<jsalisbury> TimStarling, ack.  There is one posted in comment #17 now.
<TJ-> mamarley: hehehe testing you :p
<TimStarling> thanks
<TJ-> mamarley: it'd be good to open a bug for this bandwidth issue if only to track all the diagnosis and testing we're doing
<mamarley> Hmm, that didn't take, the quirks are still 0x00000090.
<TJ-> mamarley: boot-time cmdline entry ?
<mamarley> It is.
<mamarley> Ah, the quirks need to be applied to xhci_hcd, not xhci_pci.
<mamarley> But, I still get exactly the same error. :(
<TJ-> mamarley: ahhh, of course
<TJ-> mamarley: right, because - if our hypothesis is correct - the driver currently doesn't consider bandwidth of upstream devices. The thing is, if that is the cause, and the current error is from the controller, does it 'know' it's on a PCIe x1 2.5TG/s link and that's why
<mamarley> Yes, looking at the code it seems it would have bombed with -ENOMEM if the driver didn't think there was enough bandwidth before it even got to the part where it tries to send the command to the controller.
<TJ-> mamarley: presumably then the Vostro only has a PCIe v1.1 hub
<mamarley> I already knew that.
<TJ-> mamarley: I've not seen the lspci report for it
<mamarley> Apparently these chips have updatable firmware, but (of course) one needs MicrosoftÂ® WindowsÂ® in order to update the firmware or even check the current versionâ¦
<TJ-> mamarley: the Renesas or the Intel PCI bridge? :)
<mamarley> The USB controller.
<TJ-> mamarley: Renesas aren't very helpful in documenting errata, and looks like all their docs are behind a registration wall
<TJ-> mamarley: looks like the Intel site has the most useful info and updater https://downloadcenter.intel.com/download/22775/Renesas-Electronics-USB-3-0-Firmware-Updates
<mamarley> TJ-: I figured out how to execute the FW updater, using a sketchy WinPE disk I downloaded from somewhere, a sketchy DLL file I downloaded, and typing "ls" instead of "dir" entirely too many times.  Now I just need to find which sketchy website has the latest FW available.
<TJ-> mamarley: the link I gave you has 2, one for 4 rear ports and 1 for front 2 ports - I'd suspect the 2-port version might be what you need if the fwupdater is generic enough (from Renesas rather than specific to Intel mobos)
<mamarley> Yeah, but that is an old FW version.  I can see at least 2.0.2.6 elsewhere.
<mamarley> TJ-: Regardless of how this turns out, I definitely owe you a drink of your choosing, if I ever meet you in real life.  Thanks!
<TJ-> mamarley: can you trust the version number? I'd trust Intel over some no-name at least
<hallyn> jjohansen: any update on the artful/bionic stacking apparmor bug?
<jjohansen> hallyn: yeah, I have a patch for it, but I haven't tested it yet
<TJ-> mamarley: you might find this very useful if you haven't already seen it. http://pete.akeo.ie/2011/10/flashing-necrenesas-usb-30.html
<mamarley> I got it flashed, but it didn't do any good. :(
<jjohansen> hallyn: are you specifically looking for a xenial kernel?
<TJ-> mamarley: the FW fixes I've seen seem to be solving a suspend/resume lock-up/fall-off-the-bus issue
<mamarley> That's what I saw too, but it was worth a shot.
<jjohansen> err no not xenial, bionic
<hallyn> jjohansen: no, actually an artful kernel :)
<jjohansen> sorry xenial was where it was working
 * hallyn tries to remember which file he had to edit as a workaround
<jjohansen> hallyn: ack, I'll kick a build off,
<jjohansen> /lib/apparmor/profile-load
<hallyn> jjohansen: yeah, found it in my logs too :)  thanks - will kernels actually build right now?  i thought intelpocolypse prevented builds?
<jjohansen> hallyn: it has
<jjohansen> I am giving it a go
<jjohansen> I think most of that has been cleaned up now
<jjohansen> hallyn: I'll ping you in 30 min or so when I know if the build succeeded or failed
<hallyn> thanks :)  *hopefull* i'll be out for dinner :)
<TJ-> mamarley: not sure if this will help but it sure is interesting! https://lkml.org/lkml/2016/6/23/632
<TJ-> mamarley: and the author's related firmware repo: https://github.com/chunkeey/renesas-fw
<TJ-> mamarley: fw-uploader is on patchwork: https://patchwork.kernel.org/patch/9195761/
<jjohansen> hallyn: I haven't tested it yet, but you can grab it from http://people.canonical.com/~jj/nsname_fix/
#ubuntu-kernel 2018-01-18
<hallyn> thanks
<TJ-> Do we have any tools for intelligently comparing dmesg logs ignoring timestamps and slight numeric-value differences? I'm /trying/ to debug a loss of all USB devices when kexec-ing (4.13.0-25-lowlatency - but affects all versions tested so far) 
<TJ-> With 16.04 and hwe (4.13) I've just noticed on 1 system that the symlinks /vmlinuz -> 4.4.0-111-lowlatency and /vmlinuz.old -> 4.13.0-25-lowlatency whereas on another it's /vmlinux -> 4.15.0-041500rc7-lowlatency and /vmlinuz.old -> 4.4.0-110-lowlatency. Shouldn't the first pair be reversed so /vmlinux.old ->  4.4.0-111-lowlatency ?
<TJ-> It seems as if the vmlinuz symlink issue was due to having the hwe-16.04-edge package instead of hwe-16.04 
<alkisg> Good morning everyone
<alkisg> apw, jsalisbury: I managed to reproduce the "kernel reboots immediately" issue here in my office. I semi-bisected it using the mainline ppa, and I saw that:
<alkisg> v4.15-rc4 = good, v4.15-rc5 = bad, v4.15-rc5 +nokpti = bad (although afaik rc5 is before meltdown patches, it didn't hurt to test)
<alkisg> Anything else I could try? Should I start git-based kernel bisection? Is it time to file a bug now even though all I have is "kernel reboots on certain hardware between rc4 and rc5"?
<alkisg> I have an almost identical hardware in the office that is NOT affected, the difference being i5-4440 (affected) vs i3-4150 (not affected) on the same motherboard Gigabyte B85M-HD3
 * alkisg reboots to test maxcpus=2...
<alkisg> ....it didn't help
<alkisg> rc5 64bit works fine...
<alkisg> Adding acpi=off works around the issue
<alkisg> No other kernel parameter from https://wiki.ubuntu.com/DebuggingACPI worked, only acpi=off
<alkisg> I'm reading https://wiki.ubuntu.com/Kernel/KernelBisection, and I believe I can follow the instructions for the xenial git tree.
<alkisg> Will this tell me the offending commit, or should I bisect using 4.15 instead, and if so, what is the git URL for that?
<f_g> alkisg: there are only 262 non-merge commits between those RCs, bisecting should be easily possible
<alkisg>  f_g, cool, if I only knew how :)
<f_g> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git is the upstream git repo
<alkisg> I'm reading various sources, but I'm not sure which one to follow
<alkisg> Ah, will this build me a debian package, or an initramfs anyway?
<alkisg> I think https://wiki.ubuntu.com/Kernel/KernelBisection is using the ubuntu git trees that also contain a debian/ dir?
<f_g> https://wiki.ubuntu.com/Kernel/KernelBisection#Bisecting_upstream_kernel_versions
<f_g> and what is linked there
<alkisg> f_g: so a rough idea is that git bisect will compile the kernel for me, and I'll then need to manually install it and calll update-initramfs ?
<f_g> alkisg: git bisect just tells you which commits to test, the instructions tell you how you get the kernels from those commits. the generated kernel deb will call update-initramfs automatically after installing, just like a regular kernel from Ubuntu would
<alkisg> f_g: what I can't understand in that workflow is how a kernel.org git will know to produce a .deb...
<alkisg> I won't have the debian/ dir there, will it?
<f_g> alkisg: the kernel build scripts have simple support for creating packages, both for .deb and .rpm
<alkisg> Oh very nice, thank you
<f_g> they are nowhere near as fancy as what RH/Debian/Ubuntu do, but for quick testing with integration into the package manager (especially for clean removal) they are sufficient
<alkisg> OK, on to my first real kernel bisection then :)
<f_g> alkisg: if you manage to compile one kernel successfully, bisecting is basically just repeating that over and over in a strategic manner.
<alkisg> Oh the bisection logic was very easy to understand, it was the .deb part that I was missing
<alkisg> f_g: I'm unsure what to put in series, in "build-mainline-one tag series". I tried "xenial" but it fails.
<alkisg> Would that be "master"?
<alkisg> http://termbin.com/rwuf
<f_g> alkisg: not sure what you did there. running git bisect and then following https://wiki.ubuntu.com/KernelTeam/GitKernelBuild minus the clone and checkout (git bisect already gets you each commit checked out) should "just work"
<alkisg> f_g: with a first look, I think the previous page that you linked required having a debian/ dir, and this one doesn't... trying this method now...
<f_g> alkisg: the KernelBisection page I linked to has the link to GitKernelBuild right at the place where I linked to ;)
<alkisg> f_g: but if you read that page, instead of following the second link to the second page, it says to use the mainline-build-one script, and it has instructions for bisecting etc, which I supposed was what I wanted :D Ty, trying...
<f_g> alkisg: it does say to use, it says you can use ;) mainline-build-one is more Ubuntu-ish, GitKernelBuild is closer to upstream. both should be fine to find the culprit (provided your own build of rc5 shows the issue, and the one of rc4 does not - it's always good to verify this before starting a long bisect only to find out that your kernel config for bisecting does not match what Ubuntu used to build
<f_g> their mainline PPA kernel deb ;))
<alkisg> Gotcha. On an i5-4440, how long a compilation would take? Half an hour? Two hours?
<alkisg> Whoops disk space became an issue before compilation time :/ 10 GB may not be enough :(
<f_g> alkisg: no clue, but once you built your first one you know ;) it's very consistent if your system is otherwise idle
<alkisg> f_g: I hope I don't need to `make clean` on each bisection step, do I? (trying to save time...)
<f_g> since you are potentially going back in time, you need to
<alkisg> Whoops. I'll need another pc to work on while my good one compiles :D
<alkisg> Thanks again
<f_g> if compiling a single kernel takes > 45 minutes, maybe you can convince jsalisbury or apw to play bisect ping pong with you using Ubuntu build machines?
<f_g> on a fast server a single kernel build is doable in a few minutes, but you need lots of cores for that ;) e.g., our EPYC with 16*2*2 threads does it in 6 minutes or so
<apw> f_g, the exact config used is included in the patches in the output
<alkisg> apw, I copied /boot/config...rc5 as a starting point, hope that's good enough for the bisection...
<apw> alkisg, sound be the same indeed
<alkisg> Cool, I hope each build will only take about half an hour on my i5, let's see...
<alkisg> ...although now that I switched to the hdd instead of the ssd due to space issues, it seems to go much slower... :(
<thresh> if you have 32G ram or so, the build should fit into that
<f_g> apw: yep. IMHO still a good idea to verify the bisect assumption holds for your local build env before doing a whole bisect run for nought ;)
<thresh> IIRC it takes me more than 20 gigabytes disk space to do a build
<thresh> (also yeah epyc and nvme ssds are awesome)
<alkisg> thresh: just 8 GB RAM here :/
<alkisg> Do builds produce both amd64 and i386 debs? Can I do the build itself from either an amd64 or i386 installation?
<alkisg> (I'm currently using i386 because I wasn't sure if it produced both or just the running one)
<alkisg> Yey, 46 minutes :) Rebooting...
<lorddoskias> guys i just got the following message from latest HWE kernel: https://paste.ubuntu.com/26409755/
<lorddoskias> Linux fisk 4.13.0-26-generic #29~16.04.2-Ubuntu
<alkisg> Yey, test kernel booted. Oh no, I misttyped 4.5 instead of 4.15 and it was a wasted effort. apw, since it takes 46 minutes, do you think it would be worth it to use the ubuntu builders for that?
<alkisg> f_g: I've completed the first step of the bisection, "good". Now before continuing with the bisection, I'd like to test that "rc5=bad", any hint on how to do that without losing the current bisection progress?
<alkisg> Hmm, although restarting the bisection doesn't mean I need to rebuild the first step, I can just answer it's good and get to step 2... :)
<hallyn> jjohansen: just to confirm, your kernel fixed the issue - thanks!
<jjohansen> ack
<chiluk> Hey apw bjf, what's the plan on the Spectre_v2 mitigation?  Are you guys planning on doing IBRS/IBPB or Retpoline compilation changes or both?
<apw> ibrs to start with, then retpoline + ibrs when upstream catches up
<chiluk> is upstream still working on repoline patches?  I was under the impression that they had made it to stable now.
<chiluk> yeah it really looks like retpoline is in linux-stable now.  It should get pulled in with stable updates.
<chiluk> also isn't retpoline + ibrs duplicate effort?  even though you might have retpoline compiled in, only one gets used at run time.
<chiluk> ^^ that's supposed to be a question 
<chiluk> I guess I should move to hardened.
<apw> no some things need ibrs as well, and we'll wait for that to settle out
<chiluk> apw are you referring to unrecompiled userspace?
<chiluk> also is there any plan to enable gcc with retpoline and do a full archive recompile?
<apw> I Amelia referring to CPUs which are not necessarily fixed with retpoline only
<chiluk> I was unaware such cpus existed... 
<chiluk> retpoline is effectively simply disables speculitive execution for indirect branches
<apw> retpoline makes it hard for the CPU speculate to useful code, skylake at least  may be able to still speculate even with retpoline forms
<chiluk> That'd be pretty impressive given my understanding of how retpoline functions.. it basically sandboxes the speculative branch in sleeps
<ratliff> https://lwn.net/Articles/744193/
#ubuntu-kernel 2018-01-19
<jjohansen> hallyn: can I throw your tested by on the patch
<hallyn> jjohansen: yup!
<alkisg> Good morning all
<alkisg> So currently I'm at: problem verified between vanilla 4.15rc4 and 4.15rc5, and I've also done two "git bisect good" steps after that. Each "git bisect" step takes me 1 hour, so I might hopefully finish it today...
<f_g> alkisg: welcome to the world of kernel bisecting, where progress can be slow and tiresome :) at least your reproducer is easy and fast - I've had bisects where the test was "do the following non-trivially automatable steps in several VMs, some of which run Windows", with the chance of triggering the problem being about 30%.
<f_g> so each build took ~10 minutes, then rebooting/kexecing, then preparing the VMs, then running the test (that took about 20 minutes), then repeat the preparation and test at least 5 times unless the issue triggered
<f_g> that was a fun week and a half ;)
<alkisg> Meh... well, at least I can do a few things while I'm building the kernel... but I'd really appreciate a monster PC right now, that could build it in under half an hour...
<thresh> :S
<alkisg> One of the builds needed 88 mins because I was doing some other work simultaneously :(
<alkisg> Testing time :) (unfortunately I can only reproduce it on my work pc, not any spare ones!)
<alkisg> 3rd bisect => good. I'm afraid the problem will be the pti patches that came right before rc5.
<f_g> alkisg: three good beside rc4? or including?
<alkisg> f_g: rc4 good, rc5 bad, then git bisect good 3 times
<alkisg> $ git bisect good
<alkisg> Bisecting: 20 revisions left to test after this (roughly 4 steps)
<alkisg> [ed1bbc40a0d10e0c5c74fe7bdc6298295cf40255] x86/cpu_entry_area: Move it to a separate unit
<f_g> alkisg: sounds like you should be done soon, and that it's like one of the PTI changes.
<alkisg> well, in 4 hours... :(
<f_g> out of curiosity, did you test -rc8 as well? if not, you might want to add that to your next reboot cycle..
<alkisg> Yes, that was one of my very early tests, but only using the mainline .deb, not with compiling
<f_g> nevermind then
<alkisg> (I also tested the daily deb)
<alkisg> git status ==> HEAD detached at ed1bbc4, You are currently bisecting, 
<alkisg> ...and yet that gave me a kernel named 4.14? Is that possible?
<alkisg> (while bisecting between 4.15rc4 and 4.15rc5)
<alkisg> In bisection step 3, I got this: linux-image-4.15.0-rc4-custom_4.15.0-rc4-custom-6_i386.deb
<alkisg> Then moving forward (git bisect good), I got this: linux-image-4.14.0-custom_4.14.0-custom-7_i386.deb
<alkisg> ...can that be because some older commit got merged later on, or does it sound like I did something wrong?
<alkisg> Anyway continuing with: $ git bisect good/ Bisecting: 10 revisions left to test after this (roughly 3 steps)/[9c294ec08408ed90c0f2d994a7979366675e3734] Merge tag 'powerpc-4.15-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
<f_g> alkisg: yes, that is usually an artifact of bisecting into some merged branch which hasn't been rebased prior to getting merged. the git DAG in linux-stable looks rather interesting :P
<alkisg> ty! I got worried for my sanity there for a while :D
<alkisg> $ git bisect good / Bisecting: 5 revisions left to test after this (roughly 3 steps) / [24e3a7fb60a9187e5df90e5fa655ffc94b9c4f77] libnvdimm, btt: Fix an incompatibility in the log layout
<alkisg> Yey for grub-reboot, it allows to continue this remotely :)
<alkisg> $ git bisect good/ Bisecting: 2 revisions left to test after this (roughly 2 steps) /[f6c4fd506cb626e4346aa81688f255e593a7c5a0] x86/cpu_entry_area: Prevent wraparound in setup_cpu_entry_area_ptes() on 32bit
<alkisg> So, I'm guessing I'll find that the problem was https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=caf9a82657b313106aae8f4a35936c116a152299, the pti preparation patches.
<alkisg> What next? File a bug report in Ubuntu? Or directly upstream? Or both?
<alkisg> Or "blame" that commit on github?
<alkisg> Also, would I be able to test the latest version without that huge patch? I'm not sure it can be cleanly un-applied in the latest version...
<mattsm> do any scripts / automation exist to copy a ubuntu kernel to a remote machine and boot into it?/
<alkisg> mattsm: I don't know, but it shouldn't be hard to do this with ssh/scp/grub-reboot...
<mattsm> alkisg yea i was just curious... for grub-reboot I'd need to add an entry for it is all i suppose
<alkisg> mattsm: normally, installing a kernel add the grub entr
<alkisg> grub-reboot then just selects that for the next reboot
<mattsm> well, i need to copy kernel + modules and add grub entry... and try it out
<mattsm> was just hoping for a script that copied stuff to a target machine existed
<alkisg> mattsm: ah, you're not using a .deb package that does all that automatically?
<mattsm> alkisg im attempting to rebuild a kernel on a remote machine and copy it over
<TJ-> mattsm: you can also reboot into another kernel using kexec - but best to test it on the actual target hardware in person first before relying on it for remote reboot :)
<mattsm> TJ-: i've got remote power reset, so that would be OK
<TJ-> mattsm: in which case after rsync-ing the /boot/vmlinuz-$VERSION, /boot/initrd.img-$VERSION and /lib/modules/$VERSION/* you can do "sudo kexec -l /boot/vmlinuz-$VERSION --initrd /boot/initrd.img-$VERSION --reuse-cmdline" (that  loads them into memory) you can do either "sudo systemctl reboot" or for a more abrupt switch "sudo kexec -e"
<mattsm> TJ-: that sounds like it will work pretty good, also it seems like the kernel build instructions do in fact build a deb as well
<TJ-> Although recently I've found kexec seems to be broken on every hardware and kernel version combination I've tried
<mattsm> a major downside
<TJ-> mattsm: if you're doing "fakeroot debian/rules binary" yes that generates the packages in the parent directory
<mattsm> does anyone know where the zesty kernel configs are?
<mattsm> TJ-: yea im playing with that
<mattsm> i suppose that will put the config somewhere?
<TJ-> mattsm: they're combined at build-time from fragments (-common + -flavour specific)
<TJ-> mattsm: the generated config will be in the build directory as .config 
<mattsm> TJ- nice, i  think i have a zesty kernel building
<OliverO> Hi everyone!
<OliverO> Any idea why v4.14.14 (released 2 days ago) build does not show up in http://kernel.ubuntu.com/~kernel-ppa/mainline?
<apw> alk
<chiluk> OliverO it could be getting held up by requisite changes to gcc in order to enable retpoline.  If I was the kteam that's what I would expect.
<mattsm> What gcc version does Ubuntu intent to use for building zesty kernel?
<mattsm> and is there a way to tell fakeroot which version to use?
<tomreyn> !zesty | mattsm 
<ubot5> mattsm: Ubuntu 17.04 (Zesty Zapus) was the 26th release of Ubuntu. Support ended on January 13th, 2018. See !eol and !eolupgrade
<tomreyn> just in case you're not aware of the EOL status
<tomreyn> other than that, to actually answer your question, my guess would be: the gcc version available in zesty.
<mattsm> hmm which tree is in the next version?
<tomreyn> !info gcc artful
<ubot5> gcc (source: gcc-defaults (1.173ubuntu1)): GNU C compiler. In component main, is optional. Version 4:7.2.0-1ubuntu1 (artful), package size 5 kB, installed size 64 kB
<mattsm> !artful | mattsm
<ubot5> mattsm, please see my private message
<tomreyn> note my guess can be very wrong, i'm not sure how / where default kernel image packages are built.
<mattsm> you made it clear to me i was confused as well
<mattsm> i wanted the next kernel version, so bionic beaver...?
<tomreyn> but i would indeed expect that building them with the gcc version of the same ubuntu release will work without an issue
<tomreyn> bionic is going to be 18.04 lts
<mattsm> right
<tomreyn> zesty was 17.04, artful is 17.10
<tomreyn> so 'next' can mean many things ;)
<mattsm> well, there is an ubuntu-bionic tree in the same place
<alkisg> $ git bisect bad / Bisecting: 0 revisions left to test after this (roughly 1 step) / [613e396bc0d4c7604fba23256644e78454c68cf6] init: Invoke init_espfix_bsp() from mm_init()
<alkisg> At least it's NOT the pti preparation patches :)
<mattsm> Does anyone know if there is a wiki for getting changes into an Ubuntu kernel release....
<TJ-> mattsm: bug report, plus email to the kernel-team mailing list
<mattsm> TJ- perfect, thanks
<alkisg> $ git bisect bad / Bisecting: 0 revisions left to test after this (roughly 0 steps) / [92a0f81d89571e3e8759366e050ee05cc545ef99] x86/cpu_entry_area: Move it out of the fixmap
<alkisg> ...so I guess I'll file this to bugzilla.kernel.org...
<alkisg> https://bugzilla.kernel.org/show_bug.cgi?id=198529
<ubot5> bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New]
<TJ-> alkisg: best to send an email to the maintainer and sub-system mailing list (using "scripts/get_maintainer.pl  path/to/source/file.c" )
<alkisg> TJ-: after reporting the bug, bugzilla said it notified his mail
<alkisg> Is that enough, or should I also send it to the sub system mailing list?
<TJ-> alkisg: oh, cool, i've not noticed it do that for my reports!
<alkisg> Email sent to:            bugsfx@gmail.com,          tglx@linutronix.de
<alkisg> That second mail there is the committer
<TJ-> alkisg: yeah, that's Gleixner :)
<alkisg> I saw a follow up commit where fixes a breakage in 32bit, and he blames "the moron that wrote the code", and I think that's again himself... sounds like he has a sense of humor :D
<TJ-> alkisg: he signed off under protest on a commit for 4.14 that fixed a regression for nvidia that I reported with " Despised-by: Thomas Gleixner <tglx@linutronix.de>" (commit 87df26175e67)
<alkisg> Haha
#ubuntu-kernel 2018-01-20
<teward> anyone on the kernel team also on Ask Ubuntu and wants to gain some rep/cred by answering this either as an answer or in comments?  https://askubuntu.com/questions/997861/why-only-spectre-protection-for-ubuntu-mainline-kernel-4-9-77#997861
<teward> since only the Kernel team people will probably be able to answer.
<hallyn> yes i'd be curious to hear if there is a plan to push 4.4.112
<hallyn> for hwe
<hallyn> or, if we should be switching to whatever gives us 4.9 or 4.14 if we're on a xenial lts
<apw> teward: answered
<apw> hallyn: those are automated builds
<apw> hallyn: they push themselves, if they are mia, let me know
#ubuntu-kernel 2018-01-21
<tsimonq2> Hi there, it seems to be a while (September) since this bug was looked at - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1720219 - it would be good to have a fix, but it might just be cherry-picking commits, right?
<ubot5> Ubuntu bug 1720219 in linux (Ubuntu) "Repeated keys stop after a few characters (^@ character spam every second)" [Medium,Confirmed]
<tsimonq2> Specifically, it seems that these three commits fix the issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1720219/comments/46
<ubot5> Ubuntu bug 1720219 in linux (Ubuntu) "Repeated keys stop after a few characters (^@ character spam every second)" [Medium,Confirmed]
<apw> \
<apw> jsalisbury, ^
<TJ-> apw: is there any interest in providing realtime builds, posssibly just via the kernel-ppa ?
<apw> TJ-, as in RT ?
<apw> the RT patch set ?
<TJ-> apw: indeed, from the mainline linux-stable-rt repo
<apw> TJ-, i have no real use for them, but i also have nophilosphical objection to producing such a thing
<TJ-> apw: do we have public access to the build tooling you use? I could work on it see if it's feasible. We do see people asking for -rt for studio-related tasks
<TJ-> in theory it's a different pull URI plus a new package flavour -realtime
<hallyn> apw: well, my xenial server has linux-image-hwe-generic-trusty and is at 4.4.109, no 4.4.112 is available as of yet.  not sure whether that constitutes mia, or just behind.
#ubuntu-kernel 2020-01-13
<zx2c4> yo apw, kerneltoast 
<kerneltoast> o/
<zx2c4> got a minute to discuss wireguard plans and recent packaging stuff?
<zx2c4> oh, it's late now in the UK
<zx2c4> alright, will ping ya back maÃ±ana
#ubuntu-kernel 2020-01-14
<midnight> Hello -- is the mainline-crack git repository at git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack supposed to be updated with vanilla? it appears out of date..
<apw> midnight, that repository gets tags pushed which are consumed by our testing kit
<apw> midnight, mostly those are pushed as tags, so if master is out of date i would not be supprised
<apw> midnight, tracking that repo is probabally not snesible
<midnight> apw: I was perusing here: https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D, and then popping into (in this case) v5.4.11, as in the past this was the easiest way for me to track mainline for my Talos (mainline had some critical patches I needed), but it appears the vanilla mirror stopped being updated (like, missing commitids) as of v5.4-rc8
<midnight> I'm completely fine just getting it from vanilla, but since I'd been tracking it regularly up to recently, just thought I'd double-check that something wasn't broken. No big deal either way, I'm completely fine just grabbing the patchset and getting vanilla elsewhere.
<midnight> at the very least, the instructions in the build results page are no longer functional as a result :)
<apw> midnight, oh, point me to one that is definatly broken
<apw> midnight, as the instructions should work
<apw> midnight, as in theory that is how the internal stuff gets the same thing you are trying to
<midnight> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.4.11/ <--  go here, try to git clone from that repo, and checkout v5.4.11 
<midnight> The patchset is downloadable though, so it's just a minor speedbump.
<midnight> or.. I guess just observe that commitid 9d61432efb21c224b710f397809f3a4fef281f9c isn't present in that git repo.
<vadre> does ubuntu include silk guardian?
<apw> midnight, ok i know the cause; a section of our mirroring has failed
<apw> midnight, so i'll try and work out why that has occurred
<vadre> https://github.com/NateBrune/silk-guardian
<vadre> _ruben, are you still using virgin mobile
<vadre> silk guardian?
<apw> vadre, not as far as i know
<vadre> apw, did you check?
<apw> vadre, i have never heard of it, and i have maintained our kernel for a very long time
<apw> and it does not appear to be a dkms module either
<vadre> so when running an init script which produces console text output does something need to be added to pipe it into null or can it be let run without breaking anything like the tty session
<vadre> I haven't noticed any spyware yet this ubuntu lts seems clean.
<vadre> Mouse jumps can happen when vnc connects.
<vadre> or what is it with ubuntu remmina
<vadre> starlight, starbright
<vadre> so long as you are perfect apw it is "our" all the way
 * apw notes for the record he is far from perfect
<apw> as a member of the ubuntu community i am comfortable calling our kernel "our"
<vadre> the web of trust?
<vadre> apw, far from perfect may be the perfect answer humbly so
<vadre> apw, do you know why I need the usbkill?
<apw> vadre, nope
<vadre> a chat with myself may lead to new skills for far from perfect
<vadre> apw, do you visit other irc networks?
<apw> some
<vadre> apw, poxified
<vadre> snags the usb bus
<midnight> apw: acknowledged. thank you. \o
#ubuntu-kernel 2020-01-15
<alkisg> Hi, I want to test netbooting without an initramfs on amd64. I managed to do it on Raspbian.
<alkisg> Question: is there any network driver that is embedded in the default ubuntu kernel? E.g. virtio or intel or something that I could use with vbox or qemu?
<alkisg> Found /lib/modules/$(uname -r)/modules.builtin; missing nfs; can't continue :)
#ubuntu-kernel 2020-01-16
<Eickmeyer[m]> Hey all. I've been seeing a number of issues pop-up with the lowlatency kernel lately from Ubuntu Studio users, much more than I've been comfortable with. There are quite a few bug reports that reference these issues, particularily dmesg errors. Is there any way to "light a fire" under somebody to look at the config and maybe solve some of these issues?
<aberrant> hi :)
<tomreyn> are OEM kernels meant to be only used on LTS releases or are 9 month releases also fine? I just noticed a user running a 4.15 OEM kernel on 19.10, is this meant to work?
#ubuntu-kernel 2020-01-17
<tjaalton> tomreyn: I don't see why not, but when upgrading to focal it'll migrate to the master kernel (same for oem-osp1)
<tjaalton> the oem kernels are available on non-lts releases too, just copied forward
