#ubuntu-kernel 2006-02-27
<zul> heylo
<mjg59> BenC: Hmm. The bcm driver still seems to need a little handholding.
<mjg59> BenC: Any chance of us being able to get an update?
<BenC> mjg59: Updated it not too long ago, but I can always do another
<mjg59> BenC: Ok
<mjg59> BenC: I need to set the channel manually right now, and also need to limit it to 11M by hand
<dilinger> yeesh
<dilinger> dilinger@throat:~$ w
<dilinger>  22:32:06 up 17 min,  3 users,  load average: 10.46, 10.69, 6.68
<dilinger> BenC: any idea why a cp between an AMD8111 device and a 3w-9xxx device would be creating a bunch of d-state processes (that make the load look really high) and make kswapds go nuts?
<dilinger> this is on 2.6.15-16-amd64-generic, dual processor opteron system
<dilinger> 1g of ram.  it's not actually swapping, but both kswapd's show up consistently right behind the cp process in top
<dilinger> hm, wonder what happens if i swapoff..
<dilinger> well, they're lower in the process list as far as cpu usage, but still D-stating regularly
<dilinger>  4267 ?        D      0:00 [pdflush] 
<dilinger>  4289 ?        D      0:00 [pdflush] 
<dilinger>  4290 ?        D      0:00 [pdflush] 
<dilinger>  4291 ?        D      0:00 [pdflush] 
<dilinger>  4292 ?        D      0:00 [pdflush] 
<dilinger>  4293 ?        D      0:00 [pdflush] 
<dilinger>  4294 ?        D      0:00 [pdflush] 
<dilinger> ugh.
<dilinger> looks like the pdflush processes are spinning in lock_timer_base
<dilinger>                         spin_lock_irqsave(&base->lock, *flags);
* dilinger wonders why the x86-64 process backtrace looks like such ass compared to the i386 one
<dilinger> (and sparc64 one, for that matter)
<infinity> dilinger!
<infinity> Oh, wait.  I'm an hour late.  I suck.
<mjg59> http://www.livejournal.com/userpic/34302017/658522 is excellent
<infinity> mjg59: A bit unreadable, though.
<mjg59> "Of course, every stylish man wears a laptop as underwear"
<dilinger> infinity: hey!
<infinity> dilinger: I had an odd feeling I wanted to talk to you a few days ago, but I have no idea why now, so, uh... "Hi!"
<dilinger> heh
<dilinger> infinity: small talk, no doubt.  so how's the weather? :P
<infinity> BenC: When you reassign kernel stuff to initramfs-tools, can you change the assignee to me as well, so I actually get notified about the bugs by email? :)
<infinity> dilinger: The weather is hot.  And stuff.  How's NYC treating you?
<dilinger> infinity: i'm about ready to leave NYC, i've had enough of it :/
<fabbione> hey guys
<dilinger> fabbione: hiya
<fabbione> hey dilinger 
<fabbione> how you doing?
<dilinger> good, other than the problems i'm having w/ this 3w-9xxx card :) 
<dilinger> you?
<fabbione> i am fine
<fabbione> busy as usual.. but i am surviving
<chmj> BenC: ping? 
<jbailey> BenC: Heya!
<BenC> hey
<BenC> chmj: pong
<jbailey> I need to file a bug for my touchpad bug (seems to move at half speed compared to breezy).  What info can I collect for you?  Just the usual lspci and dmesg bits?
<mjg59> jbailey: Userspace, not kernel
<jbailey> mjg59: Ah?  It works fine when I plug a USB mouse in.
<jbailey> mjg59: So I'd assumed it was something in the /dev/input/mice mux.
<BenC> jbailey: pb?
<mjg59> jbailey: No, it seems to be the synaptics driver
<jbailey> BenC: The only thing that comes to mind is "Philip Blundelle"..  What does that mean?
<mjg59> Powerbook
<BenC> powerbook :)
<jbailey> mjg59: Ah, okay.  Anything I can usefully do?
<fabbione> BenC: can you please pull from my branch on people? 
<jbailey> Ah, no, Toshiba.
<BenC> fabbione: sure thing
<fabbione> BenC: changelog: SUN4V support.
<fabbione> BenC: more to come today or tomorrow
<BenC> jbailey: if it's a powerbook, it's a known issue
<fabbione> but i need you to pull and push to clean up my local branch
<fabbione> BenC: packages can build. we will test tomorrow if they boot ok on niagara.
<fabbione> BenC: i got ssh access to it :)
<fabbione> BenC: we only need to get silo done for now.. asap
<fabbione> KNOWN ISSUE: possible memory corruption with make -j 512
<chmj> do we still push to our repo's in rookery 
<chmj> I notice that are people-<name> branches 
<mjg59> jbailey: Try sticking:
<mjg59> Option          "MinSpeed"              "0.49"
<mjg59> Option          "MaxSpeed"              "0.63"
<mjg59> In the synaptics section of xorg.conf for now
<jbailey> mjg59: 'kay.  firing it up, lagging a sec.
<fabbione> BenC: do you think you can silo today?
<fabbione> BenC: i must prepare a redhat cluster suite update for you before yesterday
<fabbione> BenC: upstream did send me an email like: "UPDATE TO CVS NOW OR CLUSTER MANAGER WILL BITE YOUR ARSE!"
<jbailey> mjg59: Silly question.  Those decimal places aren't locale-specific, right?
<mjg59> jbailey: Doubt it
<jbailey> In fr_CA, we use , 's
<fabbione> jbailey: no they are not
<jbailey> 'k
* fabbione has read the code to try to fix that problem
<jbailey> mjg59: Appears to fix the problem.
<mjg59> jbailey: Ok. Need to test it on a real synaptics.
<jbailey> The min and max are ranges for accelleration, right?  The min might be a touch fast, but that might be me misremembering and just getting used to the painfully slow that I had.
<jbailey> mjg59: Do you want me to make any 'worksforme' noises in a bug somewhere?
<mjg59> jbailey: No, it's ok right now
<jbailey> Hmm, this reminds me that I need to check for a bios update to see if that makes my suspend/resume happy.
<BenC> fabbione: lol, yeah, I'll do silo today
* BenC has been playing with his new Athlon box
<fabbione> BenC: ok thanks! 
<fabbione> i really must take off now
<jbailey> BenC: Are you and Dave still working wit Vincent on grub2 at all?
<fabbione> BenC: if you can manage to pull/push within the next 2 hours it will just great.. 
<fabbione> BenC: my local repo is falling apart in push/pull
<fabbione> a new clone would be helpful ;)
* fabbione takes off
<zul> heylo
<jbailey> g'm Scott, Chuck!
<jbailey> zul: I still have to try disturbingly hard not to call you chunk.
<zul> hehe...thats second on my list of most commonily used joke about my names
<jbailey> It was an honestly misspelling the first time.
<jbailey> Unfortunately, it's now what pops into my head as the mapping for "zul"
<zul> hehe...
<zul> i heard stupid comments that hey you arent short...blah blah...i heard it twice yesterday while i was at the hospital
<jbailey> Bah.
<jbailey> Nah, the only game that I really like with your name isn't derogatory.
<jbailey> It's just so perfect for the name game.
<jbailey> And I heard it from a teacher first, which made it so special. =)
<jbailey> (clearly hadn't thought it through...)
<zul> chuck, chuck, banna banna...bo...etc
<jbailey> zul: Yup, that's the one. =)
<jbailey> zul: Nice because it doesn't poke fun at the owner of the name, but usually the person in authority you convinced to lead the game.
<zul> not how we played
<zul> BenC: have you seen that PnPACPI thing yet?
<BenC> zul: yeah, mjg59 is supposed to be looking into it
<fabbione> re
<fabbione> BenC: how is the merge going?
<zul> BenC: i should have some patches for you by friday as well
<mjg59> BenC: What am I meant to be looking into?
<mjg59> BenC: Oh, I sent you a fix for acpi-sbs - did you get that?
<BenC> fabbione: going through bug reports then I'll merge
<BenC> zul: ok
<BenC> mjg59: let me check
<BenC> mjg59: I have a battery fix, but nothing that I can see for the PnPACPI thing
<fabbione> BenC: ok.. you might want to give me an hour or two so i can give you the RH Cluster updates too
<mjg59> BenC: Yeah, that's what I meant
<BenC> fabbione: sure, I can hold off
<fabbione> ok
<fabbione> BenC: test building now..
<fabbione> include/asm-generic/pgtable-nopud.h:15:1: warning: "PUD_SHIFT" redefined
<fabbione> <command line>:1:1: warning: this is the location of the previous definition
<fabbione> ^^ BenC do you see this one too?
<BenC> never looked for it, but I don't recall seeing it
<BenC> weird that it is defined on the command line
<fabbione> yeah
<fabbione> BenC: ok.. green light to pull from me
<fabbione> test builded on i386 :)
<BenC> fabbione: great, thanks
<fabbione> no problem
<lamont> fabbione/BenC: http://www.parisc-linux.org/~kyle/for_lamont/
<lamont> these are relative to the top of git
<BenC> our git, or upstream git?
<lamont> tulip is needed for more than just hppa boxes
<lamont> our git
<lamont> or rather, "BenC's git"
<BenC> sweet
<lamont> sym2 is willy's version (he's upstream for sym2, does his initial releases to the parisc tree)
<lamont> compat.diff is the only iffy one...
<lamont> in that it appears to be half-applied already in our tree.
<BenC> it is, but when I did it, I kept it local to parisc to reduce noise
<lamont> ah, ok
<BenC> I may skip that one
<BenC> the other three, I'll include
<lamont> the parisc.diff file has patches outside of arch/parisc type stuff, but they're all bug fixes that shouldn't hurt, or are required fixes to support said chip in hppa properly, or it's an hppa-specific driver (e.g., harmony)
<lamont> dropping compat.diff is probably no big deal
<lamont> BenC: there might be one more, I'm told.
<BenC> ok
<fabbione> lamont: is there any chance to get the 17bit jmp fixed?
<fabbione> on hppa so to speak...
<lamont> fabbione: I know someone was working on it, dunno if they fixed it...
<lamont> it's a pretty deep architecturel f-up in ld.
<lamont> (IMO)
<fabbione> lamont: that would have been tas
<lamont> tausq
<fabbione> yeah
<fabbione> i can't type his nick.. 
<lamont> tau<tab> :-)
<lamont> BenC: this "stubs out enough in arch/parisc to make everything work." (without compat.diff):  http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=f671c45df23005692daa200aba768c642fb14ef2;hp=16541c8745e28f62b3dcb6cb354b73c9c01ea178
<lamont> which might be the part that we already grabbed
<fabbione> lamont: yes.. <tab> works when you are in the same chan
<lamont> yeah
<fabbione> and he is not here :)
#ubuntu-kernel 2006-02-28
<BenC> lamont: the patch we have is one I did, but it may be similar
<fabbione> morning
<airlied> do you guys have pre-built kernels for Intel Pentium D + SMP?
<infinity> airlied: In theory, the -686 kernel should be the right thing, there.
<infinity> airlied: Our 686 kernels do SMP/UP switching on the fly, through some dirty trickery.
<infinity> airlied: "apt-get install linux-686" for the minimum fuss (this is on dapper, of course... On breezy or earlier, you probably want linux-686-smp)
<airlied> do I need to go to dapper? or does breezy work?
<airlied> ah thx..
<airlied> nope that doesn't work on breeszy I might just upgrade to dapper anyways..
<infinity> It will only work if you have restricted in your sources.list...
<infinity> If you don't give a hoot about resitrcted modules, then "apt-get install linux-image-686-smp" instead (which should come from "main")
<infinity> (linux-FLAVOR depends on linux-image-FLAVOUR and linux-restricted-modules-FLAVOUR to make sure you always have both in sync, should you actually be using the latter)
<infinity> LRM includes stuff like madwifi, nvidia and fglrx kernel components, etc.
<airlied> shouldn't need those then.. 
<infinity> Or just upgrade to dapper anyway, cause you're a l33t freedesktop hacker, and you need the latest and greatest anyhow. ;)
<infinity> (and kernel 2.6.15 will set much better with you than 2.6.12, I suspect)
<infinity> s/set/sit/
<airlied> well at least I might have ethernet with 2.6.15
<infinity> That would be a good thing.
<Mithrandir> ethernet's supposedly good.
<airlied> yes I've got a USB Ethernet at the moment.. its mostly not good..
<davekempe> anyone got dapper to install on a sun 4100 or 4200?
<davekempe> the megaraid_sas driver seems to dump a stack trace and not detect any drives for me
<fabbione> davekempe: url to the hw please?
<davekempe> http://www.sun.com/servers/entry/x4100/
<davekempe> http://www.sun.com/servers/entry/x4200/
<davekempe> btw, breezy works fine on the next one up, the v40z
<davekempe> but its just megaraid_mm or some older megaraid
<davekempe> not sas
<fabbione> please file a bug on lauchpad.net/malone component linux-source-2.6.15 and add: lspci -vvv to the bug
<fabbione> include also the 2 URL to the hw
<davekempe> no worries.
<fabbione> the megaraid did change a lot between .12 and .15
<fabbione> but i thing that machine actually uses mptsas
<davekempe> I will try out dapper flight 4 amd64 tomorrow and try get it working
<fabbione> and not megaraid
<fabbione> ok
<fabbione> thanks
<davekempe> i really would like hoary on there though. I will have to make a different installer
<infinity> ... hoary?
<fabbione> why hoary???
<davekempe> so i don't have to resolve the libc PT_GNU_STACK mess and can use grsec in the kernel
<davekempe> its a server, not much i need has changed between hoary and dapper
<davekempe> (that I can't backport if really really needed)
<Mithrandir> dapper's 9-10 months into the support period, though, so you'll be stuck without security fixes in less than a year.
<mjg59> Hoary, not dapper
<Mithrandir> uh, true.
<davekempe> yeah, so we have that long to figure out the libc mess one way or another
<davekempe> i really would prefer to not have an executable stack for my purposes
<davekempe> this is what im talking about: http://forums.grsecurity.net/viewtopic.php?t=1152&highlight=debian
<davekempe> its all redhat's fault
<zul> okie dokie
* infinity notes that that "glibc mess" is easy to fix in the apps...
<zul> whats the program thats a front gui for a tcpdump
<zul> i forget what it is called
<Keybuk> ethereal
<zul> thanks...
<mjg59> BenC: Are you sure about http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blobdiff;h=99c0ce2a87645bea35ad161d0552b35307d6af0f;hp=f26d819c9ae13c403b904c97e0be34866a32213e;hb=14de3561b1eab87faf8591b667e14e8e93523dac;f=arch/i386/Kconfig ?
<BenC> mjg59: Pretty sure. The default is 1G of user address space, with anything over that as virtual, and ~190Megs is used for kernel related things to manage that, which gives us the ~870 megs of non-highmem we have by default
<BenC> atleast, that's the way I understand it
<BenC> it could be backwards, because the patch I used for it is really confusing
<mjg59> BenC: No, that's 1G of physical address space, surely?
<BenC> yeah, I think you're right
<mjg59> The more physical memory the kernel can access, the less address space available to userspace
<BenC> Should change the description
<mjg59> Yeah
* Keybuk swoons over LWN
<Keybuk> Linus and Andrew both ganging up on kay and gregkh for breaking sysfs/uevent/etc. every week
<BenC> goodness
<fabbione> hey guys
<fabbione> BenC: please pull from me again.. more |Viagara love ;)
<BenC> ok :)
<fabbione> BenC: we need silo.. do you think you can make it today?
<fabbione> .10 + the 2 patches
<BenC> Yeah, I can try
<fabbione> thanks
<fabbione> BenC: both .15 UP and SMP have been tested.
<fabbione> BenC: so we are "certified" :)
<BenC> gotta love that :)
<fabbione> oh yeah
<fabbione> that's when we found out a few extra bugs with silo (second patch) and an error in trap/syscall table not being properly alligned
<infinity> BenC: Has anyone whined to you yet about a bunch of ISAPNP (I think it was?) printk's flashing by on boot before usplash kicks in?
<BenC> yeah, I see them too
<BenC> I'm bugging mjg59 about them, since they are his fault :)
<infinity> Yeah, can we get the severity lowered, so they get shut up by "quiet"?
<infinity> Unless they shouldn't be happening at all.
<BenC> they seem to be harmless, so I'll make them quiet
<infinity> Also, has anyone yet requested that we bump up the default size of our ringbuffer a tad?  I find it painfully irritating that by the time I boot, "dmesg" doesn't go back to the beginning anymore, cause our boot is so noisy.
<Keybuk> BenC: how are you on the kernel filesystem layer?
<BenC> Keybuk: so so
<Keybuk> I'm having issues with the FIBMAP ioctl
<Keybuk> which may be just me ... :)
<Keybuk> if I pass 0 rather than "uninitialised local variable" it works
<fabbione> hmmmm
<fabbione> there has been hell of a lot of activity on OCFS2
<BenC> Keybuk: looking at the code, you are supposed to pass a block number
<BenC> mjg59: your last email contained no patch
<mjg59> BenC: Argh. Hang on.
#ubuntu-kernel 2006-03-01
<bluefoxicy> I want oops insurance
<bluefoxicy> when my kernel oopses I want it to file a bug and mail the full oops output to every kernel dev so I KNOW they're fixing it  :D
<infinity> bluefoxicy: Every time I commit a fix for something, I want it instantly forced on every user's machine, and I want them to be forced to test it immediately.  (Also, we can't always get what we want)
<bluefoxicy> infinity:  it was a joke
<infinity> So was mine.  Sort of. ;)
<bluefoxicy> infinity:  although instant testing would be nice ;)
<dilinger> infinity: i'd like every user to accompany their bug reports w/ patches that solve the problem.  also, a pony.  i want a pony.
<Mithrandir> dilinger: what colour?
<dilinger> blue
* dilinger works on making x86_64's printk_address print something reasonable looking
<dilinger> [  123.737130]  Call Trace: [ffffffff802e0e15]  schedule_timeout+0x25/0xd0
<dilinger> [  123.737143]   [ffffffff8014b803]  prepare_to_wait+0x23/0x80
<dilinger> [  123.737148]   [ffffffff802dc383]  unix_stream_recvmsg+0x2c3/0x5d0
<dilinger> [  123.737155]   [ffffffff8014b550]  autoremove_wake_function+0x0/0x30
<dilinger> hey look, it's an almost readable backtrace, just like i386 and sparc64
<dilinger> ugh, is that intentional?
<dilinger> dmesg output:
<dilinger> [   82.375220]   [<ffffffff8019adc0>]  __pollwait+0x0/0xf0
<dilinger> syslog (kern.log):
<dilinger> Feb 24 05:15:42 throat kernel: [   82.375220]   [__pollwait+0/240]  __pollwait+0x0/0xf0
<mjg59> BenC: Why the change to CONFIG_2GB?
<doko> is it intended for a server setup that the hard disk spin down after activity? and if yes, that period seems to be too short
<BenC> doko: that would be one of the startup scripts doing that, or it's your bios
<BenC> mjg59: mainly to allow laptops with 1GB of ram to still be able to suspend/resume
<doko> BenC: no, did start sometime in the dapper cycle
<BenC> doko: has to be a startup script then...not sure which one though
<mjg59> BenC: Eh?
<mjg59> BenC: Suspend/resume should work with highmem...
<BenC> mjg59: I've had reports that it doesn't, also read it somewhere
<mjg59> BenC: How weird
<mjg59> BenC: It has the side effect of breaking sbcl
<BenC> yeah, it seems to be breaking more than it fixes
<Mithrandir> when I get "recursive die() failure, output supressed", that's bad, right?
<fabbione> hey BenC 
<BenC> hey fabbione
<mjg59> BenC: Suspend to RAM or suspend to disk?
<BenC> fabbione: I did silo last night, just forgot to upload new upstream tarball
<Mithrandir> our current live CD seems exceedingly unhappy in vmware.
<BenC> mjg59: can't recall, let me check
<fabbione> BenC: please pull from my tree. changes: more sun4v love, config changes for sparc to move sunhme, sungem and esp from mod to inline to spare people a few errors in d-i
<BenC> fabbione: those d-i problems were supposed to be fixed, I filed bugs :/
<fabbione> BenC: i am talking about modprobe errors during install
<BenC> fabbione: did you also make scsi/sd built-in aswell?
<fabbione> no i didn't
<BenC> what sort of modprobe errors?
<fabbione> only sunhme, sungem and esp
<fabbione> it's problem with the drivers
<fabbione> when the hw is not there, they exit badly
<fabbione> and d-i catch the error and show a big fat red screen to the user
<fabbione> = scary
<fabbione> bu
<fabbione> BUT
<fabbione> if they are compiled in, hw is still recognized
<fabbione> and there is no need to modprobe them
<fabbione> = works
<BenC> gotcha
<fabbione> BenC: i also added the sparc ABI files for 16.22 and 16.23
<fabbione> and removed the abi checker
<fabbione> sorry i meant the sparc.ignore
<BenC> ok
<fabbione> now it takes me about 20 minutes to build :)
<BenC> how's the DC sparc hw coming?
<BenC> 20 minutes? my machine can do it in 10 :)
<BenC> btw, someone is giving me an e3.5k
<BenC> not sure where I'll put it, or why I need it, but it's free
<infinity> mjg59: swsusp is the one that supposedly doesn't work with > 1GB of RAM (according to reports on user lists and forums, etc), though it's worked in the past on my laptop with 2GB of RAM..
<fabbione> BenC: 20 minutes including udebs and without ccache?
<fabbione> BenC: 20 is full dpkg-buildpackage :)
<infinity> BenC: Don't suppose they want to spend ridiculous sums to ship it to Australia?
<fabbione> BenC: the machines are installed in a rack.. i think elmo crashed before installing anything on them
<BenC> fabbione: full udebs, but ccache, yes
<fabbione> kill ccache :)
<fabbione> and we can talk ;)
<BenC> infinity: maybe I can sneek it through customs in to germany in my duffle bag
<infinity> BenC: You must have gotten a larger duffle bag since last we met...
<BenC> I think It was 30 minutes without ccache
<fabbione> Feb 24 04:40:30 sunrise udevd[2686] : get_netlink_msg: unable to receive kernel netlink message: No buffer space available
<fabbione> HMM
<fabbione> kernel or udev issue?
<BenC> fabbione: AHA! someone else sees it aswell
<BenC> that's been fucking up my e3k for weeks now
<infinity> Blame davem.
<BenC> it has to be kernel, I haven't seen it anywhere else
<BenC> someone the netlink foo is returning ENOBUF but I can't see how
<fabbione> BenC: AHHHHH
<BenC> s/someone/somewhere/
<fabbione> crap
<fabbione> i will blame davem :)
<infinity> Or, blame davem's girlfriend.  She's too distracting.
<BenC> infinity: s/duffle bag/empty crago hold/
<fabbione> because it looks like udevplug is triggering that thing exactly when it needs to probe the network driver
<BenC> fabbione: for me it occurs when it needs to load sd_mod, which means I have to manually bring the machine past initrd stage
<fabbione> ok..
<fabbione> so it's random..
<fabbione> good to know
<fabbione> david will love to fix that :)
<BenC> not really, for me sd_mod is the first thing it is trying to do
<fabbione> the netdriver is not the first
<fabbione> it's way past that i think
<fabbione> but i collected all the infos together
<BenC> it's probably the first thing that requires a kernel event
<fabbione> could be
<fabbione> BenC: btw.. silo is up
<fabbione> uploaded this morning
<BenC> yeah, saw that
<fabbione> cool
<fabbione> hey Keybuk 
<fabbione> i was just waiting for you
<fabbione> Keybuk: http://people.ubuntu.com/~fabbione/sparc/
<fabbione> this is the error i am getting on sparc
<fabbione> there is lspci, the error in syslog and the strace of both udevd and udevplug
<fabbione> each time i run udevplug i can reproduce the error
<fabbione> what i see at each reboot is network not loaded (e1000)
<fabbione> but BenC for instance has no sd_mod
* BenC concurs
<fabbione> BenC: i also fixed hw-detect and Mithrandir did kbd-chooser
<fabbione> the latter will make that annoying error disappear when you don't have a keyboard installed
<BenC> so hw-detect should find my sbus devices now?
<fabbione> BenC: only after you will upload the new kernel...
<fabbione> that has esp built in
<BenC> well that's no help, new kernel will make my sbus modules built-in :P
<Keybuk> cute, that error message isn't listed in the recv() manpage
<Keybuk> ENOBUFS
<fabbione> BenC: i will look at hw-detect in debian and see what they have 
<BenC> Keybuk: that error is from the netlink core
<Keybuk> BenC: how do we avoid that error?
<fabbione> BenC: otherwise yeah. i guess that's the solution :/
<BenC> Keybuk: I couldn't figure out why it happened
<BenC> netlink code is so confusing
<Keybuk> could it be that the kernel overflowed the netlink buffer space
<BenC> fabbione: they have a working libdetect that correctly descends secondary sbus busses :)
<BenC> Keybuk: seems that it some how does
<fabbione> BenC: what package is that?
<BenC> fabbione: detect or libdetect or something like that
<BenC> from what I remember, we don't use the same thing they do to detect devices
<fabbione> BenC: oh you mean discover?
<BenC> yeah, that's it
<fabbione> they did get rid of it
<fabbione> and the fix for the double sbus was merged in breezy under my "heavy" pressure
<Keybuk> BenC: what's BUFFER_SIZE in lib/kobject_uevent.c ?
<Keybuk> (that's the size allowed for a single uevent)
<BenC> Keybuk: no idea, but there is no ENOBUFS in that code, so I think it's elsewhere
<Keybuk> it could be that it's trying to generate a uevent that's too big
<Keybuk> or it could that it's queuing too many uevents, and udevd isn't getting enough cpu time to slurp them all
<BenC> the BUFFER_SIZE overun case returns ENOMEM
<fabbione> it's probably the latter
<fabbione> too many events
<BenC> net/netlink/genetlinks:ctrl_build_msg() returns ENOBUFS
<BenC> and so does net/netlink/af_netlink:netlink_overrun()
<BenC> it's probably the second one generating the error
<Keybuk> that function's called in a few places
<fabbione> Keybuk: is it possible to build udevplug to wait let say half second between sending each event?
<fabbione> that would exclude the "too many events at once"
<Keybuk> fabbione: you'd be in the ten-minutes-to-boot area with that delay
<fabbione> Keybuk: i don't need to run at it boot :)
<fabbione> i can test it in userland
<fabbione> i get the same error
<fabbione> in both situation
<fabbione> 10 minutes.. no problem ;)
<Keybuk> run "udevplug -s" to test if that's the case
<Keybuk> that waits for the previous event to be processed before sending the next
<fabbione> what does -s do?
<fabbione> ok
<fabbione> sure i can do
<fabbione> in a few minutes..
<fabbione> i am enjoying this extremely cleaned up d-i
<Keybuk> BenC: could be caused by nlmsg_new not returning a message, though I can't find that function
<BenC> do_one_broadcast() also has a few failure points
* Keybuk looks in the header files
<Keybuk> static inline struct sk_buff *nlmsg_new(int size)
<Keybuk> {
<Keybuk>         return alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
<Keybuk> }
<BenC> netlink_broadcast_deliver() seems like a likely candidate
<Keybuk> yeah, there's a whole bunch of them there
<BenC> it tries to push one to the queue
<Keybuk> if only we could tag it so we knew which one it was
<BenC> if fabio's test doesn't prove anything I'll start sprinkling some printk's to find out where it is failing
<Keybuk> ah, that pushes into an actual socket rcvbuf ... so if that was full, then it wouldn't fit
<BenC> right
<Keybuk> interesting that this has only affected sparc so far though
<fabbione> hmmm
<BenC> hey, can you increase udev's socket bufsize?
<fabbione> Keybuk: it might be a cpu speed issue?
<Keybuk> I'd've thought an amd64 would show up more
<BenC> Keybuk: sparc64 is slower
<Keybuk> ahh, of course, sparc is slower so udevd gets less time because the kernel is using it all
<BenC> it's odd that it happens on a 6-way system though
<Keybuk> BenC: remind me how to do that
<BenC> my sparc64 has 6 cpu's and 6gigs of ram :/
<Keybuk> it's a setsockopt isn't it?
<fabbione> "mine" only 32 CPUs and 16GB of ram
* fabbione ducks
<Keybuk> fabbione: cat /proc/sys/net/core/rmem_max /proc/sys/net/core/rmem_default
<fabbione> Keybuk: you will have to wait.. i am in the middle of testing parted.. just a few minutes
<BenC> Keybuk: maybe setsockopt(), let me check
<fabbione> rebooting now...
<BenC> fabbione: maybe we have just too much memory/cpu and it's confusing udev :)
* fabbione goes for a break while POST
<fabbione> BenC: possibly
* Keybuk wonders what SO_RCVBUFFFORCE is
<fabbione> BenC: these udev hackers and their laptops
<BenC> lol
<BenC> Keybuk: IIRC, you can set the buffer to a local one
<BenC> SO_RCVBUF maybe
<Keybuk> it already sets that SO_RCVBUFFORCE thing
<BenC> what does that do?
<Keybuk> dunno
<fabbione> re
<Keybuk> ah
<Keybuk> got it, sets the rcvbuf and forces it over the maximum if necessary
<Keybuk>         const int buffersize = 16 * 1024 * 1024;
<fabbione> Keybuk: ok.. now i am without network
<Keybuk>         setsockopt(uevent_netlink_sock, SOL_SOCKET, SO_RCVBUFFORCE, &buffersize, sizeof(buffersize));
<Keybuk> so that forces the rcvbuf of that socket to 16MB
<fabbione> root@sunrise:~# cat /proc/sys/net/core/rmem_max /proc/sys/net/core/rmem_default
<fabbione> 131071
<fabbione> 124928
<Keybuk> which is roughly 16,000 uevents
<BenC> Keybuk: maybe that's broken on sparc
<fabbione> BenC: or events are bigger?
<Keybuk> events are fixed at 1024 in the kernel and in udev
<Keybuk> fabbione: try "udevplug -s -v | tee events.txt" then count how many lines you get :)
<fabbione> Keybuk: udevplug -s is running
<Keybuk> ah, ok
<fabbione> i can do that later again :)
<fabbione> the error did always appear before..
<fabbione> so one run more or less won't cahnge my life
<Keybuk> ok
<BenC> Keybuk: are you checking the return value of setsockopt()?
<Keybuk> see whether it appears this run first
<Keybuk> BenC: no...
<BenC> it may be failing
<Keybuk> BenC: looking at the code, it can only fail with -EPERM
<BenC> yeah, but it could also be something as stupid as a signed extension or 32/64 value that is getting junked and causing it to be set at minimum bufsiz
<BenC> but that wouldn't error out
<BenC> amd64 isn't doing this in 32-bit
<fabbione> Keybuk: it looks like that the run did not generate the error, but it still doesn't bring up the network
<fabbione> BenC: amd64 doesn't need memory to be alligned at 64 bit
<fabbione> that can cause issues
<fabbione> like it was with apt in breezy
<BenC> no, I mean amd64 isn't pushing this through a compat layer
<fabbione> yes i understand
<fabbione> are we?
<fabbione> yes
<fabbione> i think..
* fabbione is tired and confused
<fabbione> Keybuk: i have the events file..
<Keybuk> fabbione: just "wc -l" it
<fabbione> wc -l events.txt 
<fabbione> 0 events.txt
<zul> heyl
<fabbione> ?
<fabbione> hey zul 
<BenC> looks like it just pushes it through as a compat, no translation
<Keybuk> fabbione: you ran with -v ?
<fabbione> udevplug -s -v | tee events.txt
<Keybuk> weird
<fabbione> exactly as you wrote it
<Keybuk> dunno why that didn't give you anything
<Keybuk> does it without the | tee ?
<Keybuk> ie just udevplug -s -v ?
<fabbione> yeah
<BenC> Keybuk: doesn't give me anything on my amd64 box either
<fabbione> udevplug -s -v | wc -l 
<Keybuk> fabbione: is /sys mounted? :)
<BenC> ah, are you in a chroot?
<fabbione> Keybuk: you joking right? it's ubuntu running system 100%
<fabbione> no chroot
<Keybuk> find /sys -name uevent
<fabbione> find /sys -name uevent | wc -l
<fabbione> 730
<Keybuk> BenC: it works just fine on mine, I get a huge number of /sys lines printed
<BenC> I do now that /sys is mounted
<BenC> I need a serial console to my sparc so I can test this stuff too
<Keybuk> fabbione: what about just "udevplug -v" does that print anything?
<BenC> I ran udevplug under linux32 in an i386 chroot on my amd64, which should use the same codepath as sparc, and it was just fine
<fabbione> Keybuk: checking in a sec
<Keybuk> BenC: yeah, I've just done the same
<Keybuk> quest scott# time udevplug -v | wc -l
<Keybuk> 773
<Keybuk> udevplug -v  0.01s user 0.03s system 2% cpu 1.685 total
<fabbione> hmm
<fabbione> it's taking too long
<Keybuk> fabbione: check you don't have an empty /dev/.udev/queue directory (just sudo rmdir it)
<fabbione> Keybuk: yeah that's where i was sticking my nose :)
<Keybuk> that's a common failure mode of previous udevd
<fabbione> time udevplug -v | wc -l
<fabbione> 735
<fabbione> real    0m1.093s
<fabbione> user    0m0.048s
<fabbione> sys     0m0.164s
<Keybuk> could also explain why -s doesn't work (it's also waiting for that to go away first, and just times out after three minutes)
<Keybuk> ok
<fabbione> so now
<fabbione> let's try again the -s
<Keybuk> well, you don't have any more events than my amd64, slightly less in fact
<fabbione> i got the error in syslog
<Keybuk> those should take only 735,000 bytes of memory to hold in the kernel
<Keybuk> BenC: do you know of a way to find out the size of a socket from userspace?
<Keybuk> lsof?
<fabbione> hmmm this is interesting
<fabbione> Keybuk: if i run udevplug -v -s
<fabbione> it gets to /sys/class/vc/vcsa
<fabbione>  /sys/devices/pci0000:02
<fabbione> and it stalls there
<Keybuk> probably aborts with SIGALRM :)
<fabbione> no no
<fabbione> udevplug is still running
<fabbione> i had to ctrl+c
<Keybuk> odd
<Keybuk> what's in /dev/.udev/queue?
<fabbione> no queue
<Keybuk> hmm
<Keybuk> strace it
* fabbione tries again
<fabbione> it's polling queue
<fabbione> probably udev is still processing
<Keybuk> does queue still exist?
<fabbione> yes
<fabbione> but it's empty
<Keybuk> ah
<Keybuk> did you rmdir it first?
<fabbione> yes
* fabbione will do again to be sure
<fabbione> like i said
<fabbione> udevplug did generate the queue
<fabbione> and waiting for it to disappear
<fabbione> but it's empty
<BenC> Keybuk: getsockopt()
<fabbione> Keybuk: udevd is doing nothing
<Keybuk> that's weird
<Keybuk> that suggests the kernel never gave the event to udevd
<fabbione> well it did
<Keybuk> can you run "udevmonitor -e" as well?
<fabbione> otherwise i would have no / ;)
<Keybuk> if it had given the event to udevd, udevd would have done something and removed the queue directory
<fabbione> ok one sec..
<fabbione> i am setting up a slightly better env
<fabbione> like 20 xterm
<Keybuk> udevmonitor should give you a UEVENT and UDEV for each things udevplug prints (with -s)
<fabbione> root@sunrise:/dev/.udev# ls -asl
<fabbione> total 0
<fabbione> 0 drwxr-xr-x  4 root root    80 Feb 24 06:09 .
<fabbione> 0 drwxr-xr-x 14 root root 13920 Feb 24 06:05 ..
<fabbione> 0 drwxr-xr-x  2 root root   520 Feb 24  2006 db
<fabbione> 0 drwxr-xr-x  2 root root    40 Feb 24 06:09 failed
<fabbione> root@sunrise:~# udevmonitor -e
<fabbione> udevmonitor prints the received event from the kernel [UEVENT] 
<fabbione> and the event which udev sends out after rule processing [UDEV] 
<fabbione> ok?
<fabbione> do we agree that it is ok?
<Keybuk> ok
<fabbione> i can see the events
<Keybuk> that's a good starting point
<Keybuk> "udevplug -s -v" on that ... for each thing it prints you should see a UEVENT and then a UDEV for it
<Keybuk> if you get no UEVENT, then that's bad
<Keybuk> if you get a UEVENT and no UDEV, that's even worse
<fabbione> UEVENT[1140790262.767691]  add@/class/vc/vcsa
<fabbione> UDEV  [1140790262.770291]  add@/class/vc/vcsa
<fabbione> ok?
<Keybuk> ok
<Keybuk> and udevplug printed /sys/class/vc/vcsa as well?
<fabbione> it didn't get that far???
<fabbione>  /sys/class/tty/tty4
<fabbione> it stopped a few letters before
<fabbione> make that 40
<fabbione> it did skip 4
<fabbione> meh 0
<fabbione> there is a queue
<fabbione> and it is empty
<Keybuk> ok, what was the last thing udevplug printed?
<fabbione> yes
<Keybuk> what was?
<fabbione>  /sys/class/tty/tty4
<Keybuk> ok
<fabbione> now
<Keybuk> what was the last UEVENT/UDEV combo printed?
<fabbione> ok one second dude
<fabbione> when udevplug was at /sys/class/tty/tty4
<fabbione> udevmonitor was printing the vcsa
<Keybuk> that's a bit weird
<fabbione> there was a queue and it was empty
<fabbione> now one more thing
<fabbione> i did remove the queue
<fabbione> and saw it recreated
<fabbione> more events did pass
<fabbione> and udevplug did finish
<Keybuk> (btw, worth noting that "udevplug -s" is not very well tested)
<Keybuk> it could be just a general bug with it
<fabbione> so ok.. what do you want me to test next?
<Keybuk> hmm
<Keybuk> so udevplug completed normally
<Keybuk> and you didn't get that error
<fabbione> nope
<Keybuk> nope it didn't complete noramlly?
<fabbione> but know i don't know if it would have loaded the module
<fabbione> nope = no error
<fabbione> i think the problem is here:
<Keybuk> right, so this suggests that the netlink buffer doesn't overflow if you go slowly
<fabbione> tty4 was way before than /sys/class/vc/vcsa
<Keybuk> how do you know? :)
<fabbione> (in the print from udevplug)
<fabbione> the print order?
<fabbione> now
<fabbione> listen up
<Keybuk> did udevplug never do vcsa before then?
<fabbione> no it didn't
<fabbione> it did it after
<fabbione> if you let me :)
<fabbione> udevplug was printing tty4 - udevmonitor was at vcsa
<fabbione> the line after vcsa in udevplug is /sys/devices/pci0000:02
<fabbione> the same where it was hanging a long time before
<fabbione> now...
<Keybuk> yeah, I get the same behaviour here (though udevplug actually prints that ... I suggest your stdout buffers weren't flushed <g>)
<fabbione> could it be a bug in /sys parsing of that device?
<Keybuk> this is just a "-s" bug
<fabbione> next test...
<fabbione> queue was never deleted tho
<fabbione> if i run only udevplug
<fabbione> i can see all the events and the error
<fabbione> that happens very early
<pappan> is there kernel debugging tool in ubuntu
<fabbione> almost at the beginning
<Keybuk> right, because udevd had finished processing the event, and was waiting for the next ... where udevplug had made the queue directory and then ended up waiting on it
<pappan> i am facing a problem with reboot in my laptop
<fabbione> but if i run it normally, the queue dir disappear
<Keybuk> I'll have to debug that, but it's reasonably safe race :)
<Keybuk> so ignore that for now
<fabbione> Keybuk: so do you think the bug is from udev itself?
<Keybuk> fabbione: no, I think this is a kernel bug
<fabbione> i am not really worried about the message itself
<Keybuk> sending the events slowly seems to not produce ENOBUFS
<Keybuk> sending them at normal speed produces it
<Keybuk> so, BenC, can we get some printk()s to find out which -ENOBUF that is?
<fabbione> it's only annoying that it doesn't bring up the ethernet
<fabbione> anyway i need to take off for a while now
<fabbione> Keybuk: thanks a lot dude
<BenC> Keybuk: yeah, let me get my sparc back up
<fabbione> later guys
<zul> toodles
<Keybuk> damn, that -s bug is entirely consistent at the first pci device
<Keybuk> tickle: uevent: '/sys/devices/pci0000:00/uevent'
<Keybuk> make_queue: directory: '/dev/.udev/queue'
<Keybuk> create_path: stat '/dev/.udev'
<Keybuk> wait_for_queue: directory: '/dev/.udev/queue'
<Keybuk> oh
<Keybuk> because tickling /sys/devices/pci0000:00/uevent DOES NOTHING
<Keybuk> BenC: kernel bug! kernel bug! kernel bug! :)
<BenC> Keybuk: stop picking on me! :)
<Keybuk> (this is irrelevant to the ENOBUFS error, it's just amusing to find more errors along the way to debugging that one)
<BenC> I think ENOBUFS is a red herring
<Keybuk> you do?
<BenC> more than likely our problem is more related to uevents not getting where they should
<Keybuk> yeah, but if the socket buffer is full, they won't get there
<Keybuk> the fact that pci0000:00 doesn't generate a uevent is only important when using "-s" where it waits patiently for the event ... during normal booting it's irrelevant
<BenC> I can't see generic sockets getting full...lots of things would be broken
<Keybuk> aye
<Keybuk> udevd used to do it quite regularly until they increased the size to 16MB
<BenC> were the symptoms the same?
<Keybuk> yeah, I think so
<BenC> I just can't see 16k uevents occuring, even on a sparc :)
<Keybuk> we know there's only 730 events
<BenC> so filling it would take a lot of effort
<Keybuk> which is less than my amd64
<Keybuk> I'm wondering whether it's actually that there's an event bigger than 1K
<Keybuk> an event is just an env buffer, after all
<BenC> true...guess I can put some debug to see what the event size is
<BenC> or just check for > 1k
<Keybuk> I wonder ...
<Keybuk> the fact udev wants the socket buffer to be 16MB is just a hint about how big it should never grow past
<Keybuk> it doesn't mean it can actually grow that big, the kernel might not have any free memory to grab
<Keybuk> so it may actually be effectively smaller than the 730K needed to do the job
<shaya> anyone home?
<shaya> just filed a bug, can help try to debug it if that would help?
<cjb> Sorry, stupid question:  dmesg/lspci dumps for lkml, should they go inline or attached?
<cjb> (The only examples I can find were all attached, so I wonder if there's some differing standard for dmesg as opposed to patches.)
#ubuntu-kernel 2006-03-02
<bluefoxicy> Hi
<bluefoxicy> this may be a stupid question
<bluefoxicy> but should running mplayer on a half-corrupted wmv file cause it to stop, complain it died
<bluefoxicy> and then if you hit "OK" so it exits OR kill -9 it
<bluefoxicy> the kernel decides it's time to have a fit and hard-lock?
<bluefoxicy> (i.e. apparently mplayer caused kernel memory corruption)
<crimsun> that shouldn't be possible
<bluefoxicy> crimsun:  ok, I think the ubuntu amd64 kernels in dapper need some nice looking at then.  Are you guys using any weird patches?
<crimsun> heh, what do you call "weird?"
<bluefoxicy> or anything aside from drivers that's experimental?
<bluefoxicy> crimsun:  well, if it does something to the kernel's source tree, it's weird.
<crimsun> well by that classification, everything that's patched is done by something weird, which is some non-negligible amount of source
<bluefoxicy> there's a specific reason why the linux mainline kernel is what it is.  Additional drivers are pop in and out; but modifications to the VM system, initialization routines, VFS subsystem, CPU schedulers, or the like that aren't backported bugfixes are DISTINCTLY odd
<bluefoxicy> crimsun:  if it's a bug in something you added, I can't go to the LKML and report it; otherwise I can just bounce it at them
<crimsun> the kernel isn't precisely the first place I'd look for an oops caused by mplayer
<bluefoxicy> If I bring them something and say "Oh there's some odd patches in ubuntu's kernel like the hard-deadline-scheduler and the memory-split-merge-mapper and ingo molnar's realtime patches" they'll go "THEN DON'T ASK US!"  :(
<crimsun> do you have ksymoops output?
<bluefoxicy> crimsun:  it's not an oops.
<crimsun> how are you ascertaining it's not an oops if you get a hard lock?
<bluefoxicy> mplayer sits there fine; then when I send kill -9 at it, the box drops straight off network, the mouse stops working, sound stops playing, hard disk stops, the screen stays as is, keyboard won't work. . .
<bluefoxicy> crimsun:  because an oops is a condition where the kernel says, "Oops," and keeps on going.
<bluefoxicy> The most kernel-aware activity this could be is a panic
<bluefoxicy> which is where the kernel says "HOLY SHIT" and stops
<crimsun> that doesn't mean you don't have an oops and then a panic
<crimsun> in any case, can you reliably reproduce it?
<bluefoxicy> well, I guess I could cause one and see
<bluefoxicy> but I'm a little shakey
<bluefoxicy> every 2 or 3 hard-locks, gnome's settings reset.
<bluefoxicy> applet configurations go, background goes, xchat-gnome settings reset, gnome-terminal settings reset, startup programs reset, rhythmbox settings reset. .
<crimsun> the first thing I'd do is try with an ia32 kernel
<bluefoxicy> anything stored in the ~/.* directories for the apps stays there
* bluefoxicy doesn't have IA32 ubuntu installed
<bluefoxicy> I had IA32 dapper installed, it was stable
<crimsun> which kernel with ia32?
<bluefoxicy> the x86-64 kernels are being a real pain
<bluefoxicy> I had i686 up to 2.6.15-14
<bluefoxicy> then i installed a 64-bit base.
<crimsun> so do flight 2 amd64 or flight 3 amd64 have this issue?
<bluefoxicy> no idea.
<bluefoxicy> oh
* bluefoxicy facepalm
<bluefoxicy> I most likely know where the problem is anyway
<bluefoxicy> I keep forgetting, I'm using the via driver in xorg
<bluefoxicy> and it seems to be really bitchy
<bluefoxicy> but I don't see how that could be linked to killing mplayer. . .
<bluefoxicy> Feb 23 14:30:05 localhost kernel: [ 8564.581410]  RIP: 0010:[_end+134114922/2132357120]  <ffffffff88453e6a>{:via:via_mmFreeMem+10}
<bluefoxicy> This is where every single oops I've had has happened.
<bluefoxicy> like ever
<bluefoxicy> so I'm assuming there's a bigger bug around there that's causing a panic or hard-lock
<bluefoxicy> crimsun:  I can't make the logical link between "killall -9 gmplayer" and "Hard lock," but that's a starting point.  There's no logs of kernel panics (for a specific reason-- the kernel halts immediately)
<bluefoxicy> for now I'm getting off the via driver.
<bluefoxicy> ok my test data to reproduce it is gone now damn.
<mjg59> infinity: It's supposed to - we should probably work out what's up (swsusp)
<infinity> mjg59: Well, check recent threads on ubuntu-users.  Several users claim that adding RAM to their machine breaks swsusp (and removing it again to drop below 1GB fixes it)
<makx> there swap might be to small
<bluefoxicy> swsusp could be better designed though
<bluefoxicy> halt programs, flush disk buffers (so file system is consistent), check how much swap is free vs how much memory is used
<bluefoxicy> if there's not enough swap, see if there's enough space on / for the rest, if yes then create a swsusp file there and make note of it in the swap partition
<bluefoxicy> flush to swap, flush remaining to the new inode on /, flush disk buffers, and halt
<bluefoxicy> when coming back up, look for something that claims there's an inode holding a swsusp file.  If there's one there, load that entirely into RAM and unlink the inode
<bluefoxicy> a little less lazy, but it would be possible.
<bluefoxicy> but that's out of scope.
<bluefoxicy> makx is probably right, they probably get like a gig and a half of application memory used and have a gig of swap.
<bluefoxicy> SHIT.  I can't run apt.
<bluefoxicy> gotta reboot I guess.
<mjg59> infinity: Hnngh.
<bluefoxicy> I can say with 95% certainty at this point that the bug was in the via dri code in the kernel.
<bluefoxicy> if I stay up for another day, I'll promote that to 99%
<bluefoxicy> I've had no oopses since boot and no crashes
<desrt> oh where oh where is benc
* desrt tackles BenC 
* BenC doges and runs for the touchdown
#ubuntu-kernel 2006-03-03
<fabbione> BenC: drivers/usb/media/spca5xx/Makefile:     -DPUD_SHIFT=0
<fabbione> this is the Makefile making the PUD_SHIFT noise
<fabbione> i don't understand why it forces it to 0
<fabbione> each arch has its own value for PUD_SHIFT
<fabbione> if you check spca5xx-main.c
<fabbione> it's the only bit that uses an #ifdef PUD_SHIFT
<fabbione> and it's inside another block almost RHish..
<fabbione> as i imagined.. the new version of the driver doesn't define it
<fabbione> BenC: fix is in my tree.. just pull please
<twstr> hi guys
<fabbione> twstr: ciao bella
<fabbione> twstr meet mjg59 
<fabbione> mjg59 meet twstr 
<twstr> ciao fabbione, -a+O please :)
<fabbione> mjg59: my friend here is haveing amd64 acpi issues...
<cjb> Isn't everyone.
<cjb> (At least, if they have the ATI chipset.)
<cjb> fabbione: (If they do have something like 0000:00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10), davej is collecting boot logs.)
<twstr> Disconnected. someone said something? :)
#ubuntu-kernel 2006-03-04
<psusi> what the crap?  git-unpack-objects says it is unpacking 187,127 objects.... only it doesn't.... the objects aren't there
<psusi> shouldn't git-unpack-objects < .git/objects/pack/pack-xxxx.pack undo a git-repack?
<dolson> if there is a driver that I want to see get into Ubuntu, how do I make that request? do I open a bug on Malone?
<psusi> if the driver is in the linux kernel, it should be in ubuntu already
<dolson> it isn't
<psusi> it isn't in the stock kernel or it isn't built into the ubuntu build?
<dolson> I don't think it's in either. it's for Logitech Quickcam Communicate. I don't think it works with the `quickcam` module, and I did some searching, and I found http://home.mag.cx/messenger/ which has another driver
<dolson> unless I'm a moron and can't figure it out for myself.
<psusi> if it isn't in the stock kernel, it won't go into ubuntu AFAIK
<dolson> well there is a big list of add-on drivers in the kernel source tree, in the debian folder
<psusi> hrm.... interesting....
<dolson> podxtpro is one of them that I can recall, and I don't think it's in a stock kernel
* psusi needs to figure out how to compare the ubuntu kernel git tree with linus's to see what's different
<psusi> it is open source right?
<dolson> yes, well, it looks like it's based on the qce code. I am going to look more into it, because I am not sure why it looks like the same stuff as the standard quickcam module.. modinfo quickcam doesn't show an alias for my vendor+device ID that I get from lsusb though
* psusi kicks git-unpack-objects
<dolson> hrmm. that's not good. it makes a module called `quickcam`
<Mithrandir> kernel bugs should be assigned to kernel-source-$version or ?
<fabbione> linux
<fabbione> afaik
<fabbione> otherwise linux-source-$version
<Mithrandir> yeah, linux worked.  It kinda sucks that the "choose" dialog just gives you some semi-random ordering rather than anything sensible.
<Tonio_> hi everyone
<netzmeister> hi
<Tonio_> just noticed there is no "build" simlink in /lib/modules/2.6.15-16-386 with linux-headers version 2.6.15-16-386
<Tonio_> the resulting is about al kernel modules compilations are failing... is that normal ?
<netzmeister> i have the same problem too
<netzmeister> i have installed the ......-686 Kernel. And all works fine
<Tonio_> hum, probematic :)
<netzmeister> *g*
<Tonio_> s/b/bl
<netzmeister> why is this problematic?
<Tonio_> well much people will install directly there uname -r linux header versions
<netzmeister> yes thats right..
<netzmeister> let's wait..
<netzmeister> the maintainers are sleeping ;-)
<netzmeister> -are
<fabbione> BenC: ping?
<fabbione> hmm it's a bit early...
<fabbione> BenC: please pull from my tree and push to kernel org.
<fabbione> Changes:
<fabbione> More SUN4V love and fixed a few problems on old sparc hw
<fabbione>   * Update redhat cluster suite to CVS20060222.
<fabbione>   * Stop spca5xx to redefine PUD_SHIFT that's arch specific mem management.
<fabbione>   * Import OCFS2 and configfs bug fixes from 2.6.16-rc5. This commit must be
<fabbione>     reverted before we will sync 2.6.16 directly from git or they will
<fabbione>     conflict badly.
<fabbione> if you can also push to kernel.org it would be lovely
<fabbione> i also checked the git purge stuff
<fabbione> it works just fine
<fabbione> it basically removes from the tree al unrequired objects
<fabbione> making the tree WAYYY smaller
<fabbione> i meant.. git prine
<fabbione> ARGH
<fabbione> GIT PRUNE <-
<fabbione> ^^^^^
<fabbione> that one
<BenC> fabbione: getting it in just a minute
<fabbione> BenC: cool
<BenC> git-pruned the kernel.org and people repo's, finishing the repack on people right now
<fabbione> nice
<BenC> git-repack needs to be done before git-prune (/me makes a note)
<BenC> have to run prune after repack anyway
<fabbione> ok
<BenC> ok, both repo's done, and my local repo is nice and tidy :)
<fabbione> BenC: if you did pull/push i will be glad to trash my local one and clone again...
<BenC> I've got it, so yeah, go ahead and ditch your local repo
<BenC> push in progress
* fabbione frees up a few tons of GB
<fabbione> BenC: note that the OCFS2 update has not been done via git-cherry
<fabbione> we will need to revert that commit before we sync 2.6.16
<fabbione> it was way too complicate to do it with cherry
<BenC> ok
<fabbione> nice.. pack rsyncing here :)
<fabbione> much much better :)
* desrt pokes BenC 
<desrt> turns out my firewire woes are fixed by a patch that you personally signed off on for inclusion upstream :)
<BenC> desrt: really? :)
<BenC> point me to it, and I'll include it
<desrt> BenC; i've been annoying the heck out of you on launchpad :p
<BenC> is it Al Viro's patch?
<desrt> BenC; it seems like launchpad reduces the effectiveness of communication by a good 80%
<BenC> my bug emails are backlogged, so I guess I'll get to it soon
<desrt> fwiw, this one: https://launchpad.net/malone/bugs/28174
<desrt> it's "from the scsi maintainers"
<BenC> ok
<davyd_> ok
<davyd_> on #30557
<davyd_> at the moment, on 2.6.15-16
<davyd_> when my machine boots up, it is putting itself into C2
<davyd_> and the idle counter goes whack, and it clocks the CPU up
<davyd_> if I force the machine into C1, the idle counter starts working
<davyd_> but my CPU can't idle properly
<BenC> davyd_: what CPU type is this?
<davyd_> Pentium <
<davyd_> M
<davyd_> on the i915 chipset
<davyd_> incidently, and possibly related to this, is that my laptop is running very warm
<BenC> which cpufreq module is being used?
<davyd_> and the fan isn't engaging
<davyd_> (it hard locked once because of this)
<davyd_> BenC: userspace
<BenC> you're not using speedstep or anything?
<BenC> powernowd uses a kernel module
<davyd_> oh, right, let me look
<davyd_> where is that kept now, it is no longer in proc
<BenC> lsmod | grep cpu
<davyd_> speedstep_centrino
<davyd_> but yeah, it counts idle ticks properly in C1, but not C2, never seems to go into C3
<davyd_> the fan is also not engaging reliably
<davyd_> my machine was at 64C
<davyd_> since my options were C1 or dodgy idle times causing the CPU to clock up
<BenC> was there a prior 2.6.15 kernel that worked ok?
<davyd_> the fan trip would appear to be 114C
<davyd_> (as a result the machine hard locked)
<davyd_> BenC: I've not have a lot of success with Ubuntu 2.6.15
<davyd_> 2.6.12 worked perfectly
<BenC> what was the first 2.6.15 kernel you used?
<davyd_> I didn't personally try, but someone said Debian 2.6.15 was working on this
<BenC> but that doesn't help me much :)
<davyd_> two secs
<davyd_> the first 2.6.15 I have installed is -15
<BenC> trying to find out if there was a point where this went bad with our kernel
<davyd_> I only upgraded this machine to dapper about a fortnight ago
<BenC> ok, so you've only used very recent ones
<BenC> any chance of you trying flight 1/2/3 liveCD's to see if they fix anything?
<davyd_> someone with an ASUS has had this problem forever
<BenC> I assume you are using the -686 kernel, have you tested the -386 kernel?
<davyd_> I haven't tested -386, I can
<BenC> yeah, that would help a little
<davyd_> interestingly, forcing C1 seems to stop cpufreq from working, scrollkeeper update didn't clock my CPU up from 600Mhz
<davyd_> ok, I'm installing linux-image-2.6.15-16-386
<davyd_> ok, testing -386, back in a bit
<davyd> BenC: positive results with -386
<davyd> machine has put itself into C3
<davyd> getting 100 idle ticks/s (~)
<davyd> cpufreq is clocking up and down as required
<davyd> fan cut in and out to cool the machine down
<davyd> sky2 still seems busted though :-(
<BenC> ok, so we have an SMP issue
<BenC> the 686 kernel is compiled with SMP support, it's really the only difference from the 686 kernel
<BenC> 386 kernel
<BenC> Please annotate the bug about this...I would stick with the 386 version (it's really not a performance hit as most people would think)
<bluefoxicy> the 686 kernel can see more than 900M of RAM
<BenC> so can 386
<bluefoxicy> no it can't
<bluefoxicy> unless I missed something new
<BenC> 386 kernel has highmem
<bluefoxicy> in Dapper?
<BenC> yes
<bluefoxicy> but not breezy
<BenC> we aren't talking about breezy :)
<bluefoxicy> ok just making sure
<bluefoxicy> I know the 386 has never had highmem before
<davyd> hmm, on the network front sk98lin is also dysfunctional
<davyd> have you had any reports on ethernet usefulness with dapper and the R200?
<davyd> (you can tell I use wireless all the time, but that I perhaps forgot to install the -restricted package)
<BenC> not that I recall
<davyd> ok, I just booted into Windows to check the hardware was actually working
<davyd> sky2 gives me an interface, but does no link detection or dhcp
<davyd> sk98lin, which used to work, doesn't even give me an interface
<davyd> I suppose I should file this as a separate issue
<BenC> yeah, I probably need to update the sky2 driver
* bluefoxicy holy craps at all the patches in -mm
<davyd> ok, -386 seems sane
<davyd> do you want me to file on sky2?
<BenC> I marked it on my todo, so no need
<davyd> ok
<davyd> thanks for your help
<BenC> no, thanks for checking in
<BenC> hopefully I'll get this squared away for you
<davyd> no probs
<BenC> mjg59: ping
<bluefoxicy> psusi:  the via dri in 2.6.15 seems horridly broken, do any of the devs have via chipsets, or do you know if it's part of mainline?
<bluefoxicy> if it's part of mainline I'll hit the lkml with the bug.
<psusi> via dri?  I have a via chipset, but my video card is an ati radeon 9800 pro
<bluefoxicy> my via chipset has a via video adaptor in its north bridge
<psusi> ewww.... don't use it... integrated video sucks ;)
<BenC> I have a VIA EPIA, I can try that some time
<psusi> it robs memory space and time from the cpu
<bluefoxicy> 0000:01:00.0 VGA compatible controller: VIA Technologies, Inc. S3 Unichrome Pro VGA Adapter (rev 01)
<bluefoxicy> psusi:  I don't need heavy video
<bluefoxicy> I'm running VESA right now, and if I play any animated videos the CPU hits 100% and they lag and X drags and shit.
<psusi> bluefoxicy: that's fine... it's still slowing down processing because of the stollen memory cycles
<BenC> that doesn't sound like a kernel issue
<psusi> what exactly does "horrbily broken" mean?
<bluefoxicy> with the Via driver, I can actually seek back and forth while playing videos, and I get decent GLX gears performance, and the CPU usage is lower.
<BenC> My VIA EPIA M10k dies completely in windows if I startup any opengl apps :)
<bluefoxicy> psusi:  um, well, if I use the via driver in X
<bluefoxicy> my kernel oopses several times
<bluefoxicy> and somewhere between an hour and 5 hours in I get a hard freeze (kernel level memory corruption?)
<BenC> ah, that's a different story :)
<psusi> oopsesses are not good ;)
<BenC> yeah, dem oopsses is bad tings
<bluefoxicy> at first I thought it was because of rhythmbox so I filed a bug against rhythmbox, then i changed the bug saying it was video related, and worked down :)
<bluefoxicy> (I thought it was rhythmbox because it seemed playing shit in rhythmbox made my kernel freeze in about 5 minutes)
* psusi wishes there was something like Soft Ice for the linux kernel
<BenC> kernel freezes are always the kernels fault
<bluefoxicy> https://launchpad.net/distros/ubuntu/+source/linux/+bug/29586
<BenC> just because it happened when app Foo was running, doesn't make it the apps fault
<BenC> reassign to linux-source-2.6.15
<bluefoxicy> yeah
<BenC> don't create a new target, just rename the old one
<bluefoxicy> It's targeted at kernel
<bluefoxicy> also when 2.6.16 is out will there be a universe package for it?  ^o.o^
<zul> no 
<BenC> bluefoxicy: target it at "linux-source-2.6.15", else I will never see it
<bluefoxicy> BenC:  what's the priority
* bluefoxicy already marked it as critical severity. . . kernel bug. . . . .
<BenC> Major
<bluefoxicy> priority low med high?
<BenC> Is it a regression from breezy, or did 2.6.12 work ok?
<bluefoxicy> Back in the day of 2.6.12 there wasn't even a driver IIRC
<bluefoxicy> I KNOW there was no X driver in breezy
<BenC> well, if it's not a regression, and there exists a workaround, and it affects few people (this is the first I have heard of it), then mark it Normal, High
<bluefoxicy> reassigned
<peterz> BenC: I got 2.6.15-16-686 and it still won't boot a UML kernel.
<BenC> was that related to the 1G/3G change?
<BenC> right now it's 2G/2G
<peterz> might be; I'll try and boot one of my own kernels for a change and see what they do with a 2/2 split
<mjg59> BenC: Hi
#ubuntu-kernel 2006-03-05
<bluefoxicy> does anyone think that the Linux kernel mainline should have built-in memory compression for memory stress?
<bluefoxicy> I did some test with Rodrigo's patch, tweaked it to be able to compress in larger blocks
<bluefoxicy> using the WK4x4 and WKdm compression algorithms (lz0 I didn't like, it corrupted memory on occasion) I got 20% or so at 8k blocks
<bluefoxicy> but with 16k blocks I averaged 35%, and with 32 I got 40%.  Beyond there, there wasn't much gain.
<airlied> just buy more RAM.. it's cheap...
<airlied> or fix apps to not chew it all up..
<airlied> I don't think the gain of in-memory compression is that majorly useful for most people..
* airlied remembers win95 tools to do it..
<bluefoxicy> airlied:  in-memory compression can get up to 40% memory gains on the compressed area.  If you allow typically 25% of memory to be in-memory compressed, this may be significant.
<airlied> but what about the process using that memory?
<bluefoxicy> For example, at 256M this allows 299M memory to be used; at 512M this allows 597M to be used; and at 1 gig this allows 1194M to be used.  This is an average of 170M per gigabyte.
<airlied> it doesn't really...
<bluefoxicy> the process using that memory would hit an invalid pagefault trying to access it
<bluefoxicy> which would trigger decompression.
<airlied> fi you are under memory pressure you are going to run out, unless you fix the problem..
<bluefoxicy> This happens when the linux kernel swaps memory to disk as well; execpt that the the memory is retrieved from disk instead of decompressed.
<bluefoxicy> You won't necessarily run out under memory pressure
<bluefoxicy> Linux is ALWAYS under memory pressure; disk cache typically uses whatever programs don't
<airlied> I'm just not seeing the advantages outweighing the complexity of it..
<bluefoxicy> If you have ample memory already, then the system just becomes faster, as it can simply compress disk cache until memory pressure increases enough to dump it.
<bluefoxicy> I'm currently thinking of liveCDs, although database applications may benefit largely as well.
<bluefoxicy> LiveCDs may run on systems without swap.  While you may say it is "nice" to try to use less than 25% for memory compression, without swap memory pressure suddenly results in one of two things:  OOM kills or eating more memory for compressed cache
<airlied> but if I'm running a firefox and an openoffice and I've got no RAM left I don't think I'll be able to do much compression ...
<bluefoxicy> A system with 256M of memory runs somewhat slow on a LiveCD.  There is a LOT of reading from the CD, because disk cache is constantly invalidated.
<bluefoxicy> airlied:  remember I'm talking about compressing 32K blocks.  The WK4x4 algorithm in Rodrigo CAstro's patch used about 128K of memory for this (it errantly over-allocated 300k, which it didn't use)
<bluefoxicy> at any rate, given severe pressure (growing disk cache, growing program memory) and no swap, a livecd system may compensate by compressing memory and using up to 90% of memory for a compressed store.  This may slow programs down by perhaps 10% between pagefaults and decompression routines (remember we're spending a fraction of a millisecond decompressing a compressed 32k block or vice versa)
<airlied> well I'll remain sceptical that the good outweights the bad... and I doubt it'll turn up in mainline any time soon..
<bluefoxicy> however the apparent memory capacity of such a system becomes 410MB
<bluefoxicy> disk access is much, much longer than the compression, decompression, and spaztic pagefaults until you use a lot of memory for a compressed store.  I don't like anything over 50%, heh.
<airlied> but if an apps working set is larger than 10% you'll end up compress trashing it..
<bluefoxicy> yes, you would
<bluefoxicy> but if an app's working set is larger than 10%, you're risking OOM kills.
<bluefoxicy> well, maybe not
<bluefoxicy> that would be 25 megs on a 256 meg system
<airlied> true... I can see it being rejected though as RAM is cheap..
<bluefoxicy> However, if an application is working with a lot of libraries (openOffice, gnome applets, firefox.. . . these feel this a lot), then every time you do something your CD drive spins
<bluefoxicy> which means you wait about 5-10 seconds, instead of a few miliseconds
<bluefoxicy> on the subject of database systems, many of these would like to mmap() large areas of the database into memory
<bluefoxicy> as your server may have 8GB of memory and a 256GB database (there are multi-TB databases on 64GB of RAM, btw), you could feasibly map in 256GB of the database (64-bit system will do this, you have 256TiB of VM space and the kernel gives access to 87TiB)
<bluefoxicy> but only 8GB could be resident at once, minus other stuff in memory.
<bluefoxicy> database servers such as this could feasibly use half of memory max as a compressed store, since most of that would become disk cache for the database anyway; they'd have about 10GiB (2GiB extra) of effective ram
<bluefoxicy> RAM may be cheap, but CPU clocks are even cheaper
<bluefoxicy> airlied:  ram is cheap yeah, it's nice to get something for free though ;)  It's been nice talking though, just felt like running through it to see if anyone actually cared.
<airlied> bluefoxicy: yes it's an intersting idea.. just not sure it'll get mainlined :-)
<dolson> if I am compiling a customized dapper kernel that I want to be the default over any of the ubuntu standard ones, what should I put in the EXTRAVERSION field or kpkg parameters to do this?
<cjb> I don't think what you put in EXTRAVERSION will affect where it goes in the grub menu.  If you want it to be the grub default, make it that in /boot/grub/menu.lst.
<dolson> well then when a new kernel comes out, it takes over as the default
<dolson> BenC: hey man, would you answer a question for me? you said you would in your emails to me :)
<BenC> sure
<dolson> cool. ok, I've got a version of Ingo's patch that applies to Dapper's kernel, and I want to compile my kernel and have it as the default kernel at bootup, even if a new Ubuntu kernel comes out. how do I do this? is it in EXTRAVERSION, make-kpkg, or in menuconfig?
<BenC> well, building requires make-kpkg
<BenC> but whether or not it is the default depends on your boot loader
<BenC> if it's grub, then edit /boot/grub/menu.lst appropriately
<dolson> ok, but then if there's a kernel update, it takes priority and becomes the default
<BenC> not if you setup menu.lst correctly
<BenC> look at the default config option, and read what it says about saveddefault
<dolson> alright. I was hoping to not have to add a section about configuring grub to my wiki, but I guess that's the only way
<infinity> dolson: No one's stopping you from removing the Ubuntu kernels completely once yours is installed.
<dolson> I know, that but I'm not going to advise that in a tutorial
<BenC> the only other way, maybe, is to set the extra version to something like -99-foo
<BenC> --append_version for make-kpkg
<BenC> but I can't gurantee that we wont hit -104-* before dapper is released :)
<dolson> heh.
<dolson> is there a need to change the localversion (in menuconfig) or EXTRAVERSION in the Makefile, or is just --append_version enough
<BenC> --append_version works
<dolson> alright thanks Ben
<mgalvin> BenC: has the fix for #28660 been uploaded yet b/c it does not appear to be fixed on the current (2.6.15-16-686) kernel I have installed?
<HAL> anyone here
<HAL> need a little assistance with kernel stuff
<HAL> Q1: what is the command to report kernel version
<fabbione> uname -a
<HAL> cool
<fabbione> but you should really ask stuff like this in #ubuntu :)
<HAL> tried in there they all seam to be having there own little discussions
<HAL> thanks for that
<fabbione> welcome
<bluefoxicy> holy shit that scared me
<bluefoxicy> for a second i thought I had an e-mail from Richard Stallman and I was like "Oh no not this moron"
<bluefoxicy> sleep
<raphink> hi guys
<raphink> I'm currently working on a minor bug on update-grub
<raphink> and would like some comments on how to fix it
<fabbione> raphink: i think zul is working on grub, but he is not around right now. he is on .ca time
<raphink> ok
<raphink> fabbione: do you know of update-grub ?
<raphink> I think you might be able to help me the issue is pretty simple
<raphink> update-grub detects existing ^splashimage= lines
<fabbione> raphink: sorry i am busy and i don't have time for it :/
<fabbione> you will have to wait for zul
<raphink> and add them to the buffer
<raphink> ah ok
<fabbione> otherwise file a bug
<raphink> :(
<raphink> the bug exists fabbione, I'm fixing it 
<raphink> ;)
<raphink> but I need some guidelines from the kernel guys
<raphink> cause I don't want to break update-grub
<Keybuk> raphink: fabbione says he's busy, and suggested you speak to zul when he's around
<raphink> Keybuk: yes I can understand what fabbione said ;)
<Keybuk> raphink: ah, then why did you carry on bugging him?
<raphink> I don't need english->english translation :)
<Keybuk> if somebody says they're busy and don't have time to help you, it's generally quite rude to carry on talking to them
<raphink> I've uploaded a fix for the grub package. Who shall I assign the bug to so the fix gets uploaded ?
<Keybuk> ... if you've already uploaded it ?
<Keybuk> leave it unassigned, it'll get assigned to the appropriate person
<raphink> I've uploaded to malone
<Keybuk> ah, leave it unassigned
<raphink> I doubt it'll get assigned soon, otherwise it would already be
<Keybuk> what makes you think that?
<raphink> cause this bug is not very very new ;)
<Keybuk> there's nobody in particular who knows/cares about grub
<raphink> Keybuk: I mean is there an equivalent to motu-reviewers for main?
<Keybuk> yes, the default assigness
<Keybuk> (ie. "nobody")
<raphink> this is a quite small patch, could you have a look at it ?
<Keybuk> no, sorry
<Keybuk> I don't know grub
<raphink> it's just a piece of bash in update-grub
<raphink> to better detect and replace the splashimage line
<Keybuk> having attached the patch to the bug, it should get noticed on the ubuntu-bugs mailing list
<raphink> it has nothing to do with grub itself
<Keybuk> have you talked to mvo about it?  he was dealing with splashimage stuff
<Keybuk> (according to the changelog)
<raphink> really?
<raphink> hmm
<raphink> I'll go talk to him
<fabbione> BenC: new OCFS2 rocks :)
<fabbione> it doesn't crash anymore on super load
<BenC> sweet
<fabbione> i am checking if i have something for you
<fabbione> i don't hounestly rememeber if i did some push/pull :)
<fabbione> oh crap
<fabbione> i do have some stuff
<fabbione> i did a pull from david but it did download all the 1500 objects again
<fabbione> and now it's pushing them to roockery
<fabbione> commit 0351e92ae406408854d0a4a6d7251f8e04308a79
<fabbione> Author: Ben Collins <bcollins@ubuntu.com>
<fabbione> Date:   Mon Feb 27 18:39:56 2006 -0500
<fabbione>     Blah
<fabbione> AHHAHA
<fabbione> lovely
<fabbione> BenC: please pull from me
<fabbione> i have a couple of changes/fixed
<fabbione> fixes
<fabbione> more sun4v and one tg3 fix
<BenC> fabbione: that stupid file wouldn't go back to "no change"...I've no idea why it had a delta
<BenC> ok
<fabbione> (for sun blade 2500(
<mjg59> BenC: Did those diffs I sent look ok?
<BenC> mjg59: yeah
<mjg59> Rock
<fabbione> receiving file list ... rsync: link_stat "/scm/linux/kernel/git/bcollins/ubuntu-2.6/objects/." (in pub) failed: No such file or directory (2)
<fabbione> something wrong on master.k.o ben?
<fabbione> never mind
<BenC> I'm doing a git-prune
<fabbione> ok
<fabbione> it was only for 30 secs or so
<fabbione> it disappeared immediatly after
<zul> heylo
<fabbione> hi zul
<zul> apparently my ears were burning in the log file
<zul> BenC: ping
<BenC> zul: pong
<zul> im getting the following error when im doing a pull
<zul> inux/kernel/git/bcollins/ubuntu-2.6
<zul> rsync: link_stat "/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/refs/heads/ubuntu-fixes" (in pub) failed: No such file or directory (2)
<zul> rsync error: some files could not be transferred (code 23) at main.c(1173)
<BenC> currently?
<zul> yep...ill try again thought if you want
<BenC> oh, yeah, rm -f .git/refs/heads/ubuntu-fixes
<BenC> actually cd .git/refs/heads/
<BenC> rm everything except for master and origin
<zul> done
<fabbione> BenC: 
<fabbione> rsync: link_stat "/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/refs/heads/ubuntu-fixes" (in pub) failed: No such file or directory (2)
<fabbione> again?
<fabbione> BenC: can you please pull from me again?
<fabbione> i have got the SPARC64 IIIi SMP bug fix
<fabbione> so we will make elmo and the porting machine more happy :)
<lamont> BenC: it would be wonderful if the next upload included the hppa patches - it'll help the DC buildd machines out some, as well as making it possible for me to use my new test machine...
<BenC> fabbione: yeah
<BenC> fabbione: also, cd .git/refs/heads/ and rm everything but master and origin
<BenC> lamont: it will be
<fabbione> BenC: i did try that too... it didn't work.. i had to clone again
#ubuntu-kernel 2007-02-26
<xorAxAx> hi, does the edgy kernel contain the device mapper patch needed for some evms setups?
<JaccoH> goodmorning from europe :)
<JaccoH> anyone awake?
<JaccoH> :)
<JaccoH> still all asleep?
<zul> morning
<abogani> Good morning to you, zul.
<zul> hi
<JaccoH> hi
<JaccoH> yes same from me i guess :)
<JaccoH> did you find any time to look at that bugreport of mine? :)
<zul> no i was doing baby stuff this weekend
<JaccoH> me too .. as in .. tending to my son
<JaccoH> anyway .. if you need anything let me know
<zul> yep
<JaccoH> im not sure how long i can leave this server in this state though.. we work with deadlines :) 
<JaccoH> if you need access to the machine.. thats also doable
<zul> JaccoH: ill get someone to look at it..what was the bug number again?
<JaccoH> https://launchpad.net/bugs/86965
<zul> thanks..
<JaccoH> btw im not trying to push this cause for me the solution is simple.. but if it would help ubuntu/linux ... .. :)
<JaccoH> things are being splitty
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-9.15 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules. | BUG STATUS (2.6.20): 281 Open, 70 Unconfirmed, 165 Unassigned
<[g2] > what's the plan for feisty and vmware support ?
<JanC> hm, linux-image-debug-2.6.20-9-lowlatency is in main, while linux-image-2.6.20-9-lowlatency isn't?  :)
<kylem> JanC, accident.
<BenC> [g2] : Depends on what you mean by support
<stgraber> BenC: About vmware did you take a look at this issue ? https://bugs.beta.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/59474
<stgraber> BenC: It would help me and some madwifi users for sure
<stgraber> it's annoying not to be able to use the wireless card with vmware especially during demos ...
<BenC> stgraber: "This is fixed by VMware workstation 5.5.2"
<BenC> stgraber: So I suggest just upgrading vmware
<stgraber> I'm running Vmware 6 beta
<stgraber> and it's not
<stgraber> the bug was closed and then reopened
<BenC> which build of the beta are you running?
<stgraber> 39849
<BenC> hmm, ok, I'll take a look at it
<stgraber> thank you
<BenC> would be best of someone else fixed it so I don't have to keep the patch around (like vmware or madwifi)
<stgraber> Indeed and especially for a 1 year old issue :)
<fabbione> hey BenC 
<BenC> fabbione: Hey
#ubuntu-kernel 2007-02-27
<jwendell> good morning, folks
<jwendell> i've noticed today that - when i upgraded my feisty kernel - it automatically tried to recompile a proprietary modem module i have on my system
<jwendell> this is a new feature, right?
<jwendell> BenC, ?
<stgraber> Was any sound driver update recently done in Feisty ?
<stgraber> I just have no sound anymore and only the PCM mixer in gnome-mixer :)
<BenC> jwendell: No, sounds like the prop modem driver did that, not us
<gismo_> hello all
<BenC> stgraber: Try alsamixe
<BenC> alsamixer
<gismo_> I submited a bug last week: https://bugs.launchpad.net/ubuntu/+source/vmware-player-kernel-2.6.15/+bug/86848
<gismo_> but we still don't have news
<jwendell> BenC, hmmm, smart driver, no? :)
<BenC> jwendell: smart packaging (probably an init script)
<gismo_> lionel on ubuntu-motu just confirmed the bug and I tell to ask here
<Keybuk> BenC: I've updated initramfs-tools to get rid of the 10MB size limit for /dev
<Keybuk> so beware there's an ubuntu4 in the queue
<BenC> Keybuk: Ok, thanks
<BenC> Keybuk: what caused you to hit a 10Meg limit in /dev? :)
<Keybuk> bootchart
<Keybuk> the Debian bug that caused the 10MB being added to initramfs-tools complained that it was disjoint with their udev package
<Keybuk> since our udev package doesn't have a 10MB limit either ... the bug was invalid for Ubuntu :p
<stgraber> BenC: same result as gnome-mixer : two playback channels pcm and mic with PCM doing strictly nothing
<stgraber> BenC: it's one of those HDA sound card
<kylem> crimsun, how much do you know about hda_intel cards?
<BenC> stgraber: File a bug, noting that it regressed in -9, and assign it to the Ubuntu Audio Team
<stgraber> ok, will do
<BenC> kylem: I think one of crimsun's patches for hda regressed that actually
<BenC> it's the only changes in the kernel for sound
<kylem> eh?
<kylem> my question was this Intel SDV exposes the pci device, but has no codec attached. was wondering if this is normal. :)
<stgraber> BenC: Any information I should attach from the -8 and -9 ? (dmesg doesn't give much information)
<BenC> stgraber: There's a wiki on what to supply with audio bugs, but mainly "lspci -vvn" and "cat /proc/asound/card0/codec#*" seem to be the most useful
<stgraber> ok, thank you
<crimsun> stgraber: which codec?
<crimsun> kylem: I know of a regression for conexant 504[57]  that's fixed already, was too tired last night to push it
<kylem> crimsun, this is not production hardware, so it's entirely possible that it is just missing the codec chip.
<crimsun> essentially, jack sense broke and does the precise opposite of what is intended (plug in headphones -> sound out of both speakers and headphones; unplug headphones -> no sound)
<stgraber> crimsun: ALC861
<crimsun> kylem: ok, can you get lspci -vvn ?
<kylem> unfortunately no. i can tell you that it's ICH8...
<crimsun> stgraber: right, when you've filed a bug with the info from DebuggingSoundProblems, I'll take a look after lectures
<crimsun> kylem: hmm, any additional codec info?
<kylem> crimsun, i'll poke at it in a bit and let you know, the machine is powered off atm.
<crimsun> kylem: ok, thanks
<stgraber> crimsun: https://beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88400
<stgraber> crimsun: Feel free to ask if you need any more information from the working or non-working kernel
<crimsun> ack, beta?
<crimsun> I can't log in there, using non-beta
<stgraber> just remove beta.
<crimsun> (I did)
<crimsun> stgraber: err, the codec and SSID are correct. Have you unmuted 'Mixer' and 'Line'?
<crimsun> that shouldn't be a regression at all, that's verified working for hardware from upstream
<stgraber> I can't :)
<stgraber> there are both in the Capture section
<stgraber> and I can't set a volume or mute/unmute them
<crimsun> ok, can you mute 'Mic'?
<stgraber> yes
<crimsun> still inaudible? (with speaker-test, let's say)
<stgraber> I just tried with playing a mp3 file (mplayer -ao alsa) and changing all the settings I can and strictly no change ...
<crimsun> I have to run to lecture, but if it's still inaudible, there are two separate things to try:
<crimsun> 1) unload all alsa modules, remove /var/lib/alsa/asound.state, reload snd-hda-intel
<crimsun> if that remains inaudible, then:
<crimsun> 2) unload all alsa modules, reload snd-hda-intel passing model=ref
<crimsun> please document results in 88400
<stgraber> ok, I'll
<stgraber> crimsun: results posted (they are bad)
<stgraber> crimsun: no change with single_cmd=1
<kylem> hmm. perhaps adding a kernel command line flag to blacklist modules that udev could respect?
<mjg59> kylem: Might be helpful
<kylem> [17179579.020000]  current capacity is 66055248 sectors (33820 MB)
<kylem> [17179579.020000]  native capacity is 234493056 sectors (120060 MB)
<kylem> yow.
<mjg59> ...
<kylem> i wonder if some vendor is selling modern sized disk as replacement for old small disk just by using HPA.
<mjg59> Really?
<mjg59> Oh, yeah, that's likely
<kylem> Windows will just blindly respect it, I imagine.
<mjg59> kylem: Some disks are set to 32GB because Award BIOSes older than 1999 or so will explode
<mjg59> The Windows driver sets them back to full size during boot
<kylem> so basically /everyone/ dumps the HPA...
<mjg59> Nah, these are usually drivers that come with the disk
<kylem> huh. my ps2 keyboard stopped working.
<mjg59> BenC: I've just sent you a patch to let appletouch actually bind to recent Macs
<BenC> mjg59: I thought you already sent me that patch
<mjg59> I sent one for appleir
<BenC> ah, that's the one I remember then
<BenC> kylem: Odd, I didn't get that email
<mjg59> BenC: Though, looking at the code, the one I just sent was insufficient
<BenC> and I'm sure I sub'd to that list
<mjg59> BenC: Hang on, I'll update
<kylem> maybe you got bounced? :)
<BenC> mjg59: Ok
<mjg59> BenC: New one sent
<BenC> mjg59: Thanks. I have a patch backlog that should go in tonight
<mjg59> BenC: No problem
<mjg59> I've one or two more minor Apple fixes to go
<mjg59> Will try to send them this evening
<mjg59> (Also, this machine compiles stuff bloody quickly)
<BenC> mjg59: what sort of machine you using for builds now?
<kylem> MBP?
<BenC> trying to get my xeon upgraded to quad-core still
<kylem> heh.
<mjg59> MBP at the moment
<kylem> why haven't you?
<BenC> kylem: waiting on "them"
<mjg59> Desktop core 2 otherwise
<BenC> mjg59: Ah, yeah, my core2duo laptop compiled pretty quick
<mjg59> dual 2.33GHz with 2GB of RAM
<mjg59> It's the fastest machine I have
<kylem> BenC, did you see the mail from "them" today? :)
<BenC> mine's only 1.82GHz
<BenC> 1.83 I mean
<BenC> kylem: yeah, send them your address
<mjg59> Hm. We should ask Apple for permission to redestribute the firmware for the isight
<kylem> someone should spec hacks for migration-assitant to copy all the windows drivers on livecd install.
<kylem> so you can cut the firmware out.
<kylem> (or mac os x drivers, clearly)
<kylem> <- not volunteering, mind you. ;-P
<BenC> mjg59: Not sure how well an email asking "Can you redistribute your firmware to facilitate a competing OS" will go over :)
<mjg59> kylem: Hm. Not a bad idea.
<mjg59> BenC: Haha.
<mjg59> BenC: Well, nothing to lose. Do we have people to handle this sort of thing?
<BenC> mjg59: Yeah, we usually sick sabdfl on them
<kylem> BenC, we don't really compete...
<kylem> certainly not in battery life. ;-)
* kylem ducks & runs.
<mjg59> Jesus. The build's finished already.
<BenC> ah, to have decent batter life on linux
<mjg59> That's < 15 minutes for a full build
<mjg59> Though only one flavour
<mjg59> Ooh. Actually, it bailed partway through.
<kylem> damn you and your speedy machines.
<mjg59> Right. it's actually going to take a bit longer now
<mjg59> Since it failed part-way through ubuntu
<JanC> hm, I talked to someone from SARA at FOSDEM; they do linux kernel builds in 47 seconds and less  :)
<mjg59> Ha
* kylem usually builds in < 1 minute.
<kylem> but i usually don't build all the crap ubuntu does. ;P
<JanC> of course, they are a cluster research centre  ;)
<kylem> er s/crap/fine community supported drivers/
<ajmitch> kylem: such diplomacy is admirable
<zul> kylem: heh...
<zul> damn...I forgot what I was going to say..
<zul> how is it going Kyle?
<mjg59> Hm. I've managed to build myself a kernel that won't boot.
<mjg59> "runaway loop modprobe binfmt-464c"
<mjg59> If I've build myself the wrong architecture, I'll be jolly upset
<mjg59> Ah, no
<mjg59> It just turns out that cp arch/i386/boot/bzImage isn't what you want to do on amd64
<mjg59> BenC: New patch for applesmc in flight
<kylem> mjg59, hehe.
<mjg59> Just adds the PNP ID so it'll be autoloaded
<mjg59> Should really convert it to a proper PNP driver for resource allocation, but, well
<kylem> gah. so much to do. so little day left.
#ubuntu-kernel 2007-02-28
<Jake333> hi
* Starting logfile irclogs/ubuntu-kernel.log
<poningru> hey what do you guys think should go into herd5 'release notes' for kernel?
<Nafallo> BenC: ping
<Nafallo> hmm
<Nafallo> BenC: ping rt61 :-)
<fryfrog> is it okay to ask for edgy kernel help in here?
<Nafallo> fryfrog: no. this is a development channel. #ubuntu is the place.
<fryfrog> blah, such a busy channel :)
<fryfrog> is there any place for kernel specific help?
<Nafallo> not that I'm aware of.
<fryfrog> okay, thanks :)
<fabbione> BenC: are we still in contact with that dvb guy that used to show up here?
<BenC> fabbione: haven't heard from him in awhile
<fabbione> BenC: ok thanks
<zul> merky or soemthing like that?
<Mithrandir> zul: what is xen-feisty blocked on?  It's listed as blocked in the spec overview.
<zul> its not blocked, I havent update it in a while
<Mithrandir> can you fix the spec status, then?
<zul> yes will do
<mjg59> BenC: 86457 sounds like a pretty valid request
<kylem> ugh. my eyes aren't working yet this morning.
<BenC> kylem: Oooh, I think I found the problem with ASLR
<BenC> COMPAT_VDSO is disabled because PARAVIRT is on, but in reality, those should be ok together now
<kylem> BenC, wow. ten minutes. that was quick.
<kylem> ;-)
<mjg59> BenC: Ok. Fancy updating the bug? :)
<BenC> just did
<mjg59> Cool
<mjg59> Did those patches I sent look ok?
<BenC> yeah, merging everything now
<BenC> if there's no ABI bump, maybe I can convince Mith to let another kernel upload squeeze in for Herd5 :)
<mjg59> Heh
<mjg59> Should be ok, I think
<Mithrandir> BenC: I'd really like to avoid that unless it's "does not boot on any hardware" or a similar problem.
* lamont grumbles about irq crappage in 2.6.17-11-generic
<lamont> -11 fails to let me find any USB devices unless I boot with 'irqpoll'
<lamont> historically, every now and then USB would go belly up - never tracked it down
<lamont> -10 was happy, for the most part
<lamont> HP pavillion a1130n, and yes, I apologize
<lamont> ati chipset, so feh
<BenC> lamont: I think the USB breakage was due to a late change in some USB host setting we had to enable
<BenC> it was one of those things where the option was enabled as early as breezy, and some USB wouldn't work at all, or we enable the option, and some people had to use irqpoll
<lamont> BenC: is it worth me working on tracking down the change that broke it?
<BenC> lamont: I believe it's a config option
<BenC> finding out why that broke working setups would be very worth it
<lamont> -10 and -11 configs differ only in CONFIG_VERSION_SIGNATURE
<BenC> maybe it was something else then
<lamont> so, yeah, it's an old option :-)
<lamont> would acpi=noirq help maybe?
<mjg59> Unlikely
<mjg59> But if it does, it gives a pretty clear indication what hte problem is
<kylem> it would be nice if people could reproduce such things with newer upstream kernels and file it in kernel.org bugzilla.
<mjg59> kylem: Maybe we should package pristine kernels as well
* lamont will fetch kernel git tree at work today, and do a little bisecting tonight.  sadly, 'tis the home workstation
<kylem> when a shared irq is raised, every registered handler gets called. because we have 3 usb on the same irq line, i was thinking maybe it got confused.
<lamont> can I drop a feisty kernel on an edgy system?
<kylem> lamont, shall i just fedex you a kernel.org dvd? :P
<mjg59> kylem: It's pretty normal to have multiple USB controllers on one IRQ
<lamont> kylem: good bandwidth, high latency.  I'll just fetch it at work
<lamont> because fedex same-day service is _EXPENSIVE_
<kylem> lamont, if you use git over http, you should be able to pull just a few large packfiles instead.
<BenC> lamont: feisty kernel on edgy is ok so long as you also upgrade initramfs-tools, module-init-tools and udev
<kylem> (instead of tonnes of small files, etc.)
<lamont> BenC: the newer other stuff works with an edgy kernel?
<BenC> lamont: That part I don't know :)
<lamont> heh
<lamont> how stable is feisty these days?
<lamont> will herd 5 be safe enough for production?
<lamont> production == my primary workstation
<BenC> I've been using feisty (kernel AND userspace) on my laptop for about 4 weeks now
<lamont> and no blood?
<thom> i've been running feisty on my laptop since UDS, as it happens
<lamont> thom: nice
* lamont decides that maybe he'll take the plunge.  Or should I bisect edgy's kernel first?
<thom> it's been occasionally entertaining, but pretty sane on the whole
<lamont> lol
* lamont makes particular note of 'entertaining'
<Mithrandir> I haven't had a single entertaining episode on my laptop, at least.
<kylem> python got out of synch last friday so i had update-notifier crashing every 10 minutes all weekend.
* lamont heads to the office, sneakernet-bandwidth-enhancement device in hand
<zul> die rpm die!!
<zul> BenC: ping...can we get some time to train the guy who is doing the breezy updates because after the 12th I wont be around much
<BenC> zul: Sure
<zul> when is breezy EOL anyways?
<kylem> zul, june.
<kylem> is my guess.
<kylem> april + migration period, i would imagine
<Mithrandir> more like april.  18 months from the release date.
<zul> so in theory this could be the last update?
<kylem> zul, see, there's always a bright side to things.
<zul> kylem: definently
<JaccoH> good .. afternoon
<kylem> JaccoH, hallo
<JaccoH> hallo
<JaccoH> you speak dutch? 
<kylem> no sir.
<JaccoH> but you do know hallo :)
<kylem> heheh
<JaccoH> or was that a lucky typo?
<kylem> i'm just being odd. i had no idea. :)
<JaccoH> i see .. hallo is dutch for hello.. close enough
<JaccoH> zul i ordered dual e1000 nic to uh .. fix my problem with the bnx2
<JaccoH> but its not in yet
<zul> ah
<kylem> lamont, oi.
<lamont> si?
<kylem> lamont, how come ia64 doesn't have builds.
<kylem> of edgy-security kernels.
<lamont> ??
<lamont> oh.  dunno.  I should go look
<kylem> Fetching itanium...FAILED.
<kylem> Fetching mckinley...FAILED.
<kylem> the srcpackage is there.
<Nafallo> hmm
<Nafallo> new security-upload on the way?
<kylem> yes.
<Nafallo> damnit. I never get the uptimes I had ;-)
<Nafallo> I should probably play with the server and XENify it or something... that might help :-)
<thom> you still have to reboot for the xen kernel updates, so it doesn't buy much :-)
<thom> can we kexec from a running kernel to a new one yet?
<lamont> thom: depends on the platform, I think...
<lamont> kylem: as mentioned elsewhere, I'll drive fixing that...
<kylem> lamont, thanks chief.
<kylem> it's blocking me for now, ironically.
<poningru> so... anyone want something about kernel to go into herd 5 'release notes'?
<poningru> everytime usually BenC puts something in this time nothing :(
<kylem> poningru, sure, can you add that "rtl818x/rtl8187 drivers have been blacklisted due to being broken"
<kylem> feel free to dress up the language. :)
<poningru> heh
<poningru> I dont think I can put that in a release note ;)
<BenC> poningru: There's not really a whole lot new between herd4/herd5
<poningru> cool bugfixes it is
<BenC> poningru: Oh, bcm43xx is working again :)
<BenC> was broken in herd4
<poningru> still requires firmware right?
<poningru> or does it do it automagically?
<poningru> with bcm-fwcutter
<poningru> dude... please dont keep me in suspense I am gonna have a brain aneurysm here, this is one of my pet peeves
<poningru> :(
<Nafallo> my feisty crashed a lot until I tried rmmod rt61
<Nafallo> almost 1d uptime now
<poningru> BenC: it still requires firmware right?
<BenC> right
<bdmurray> Is there a wiki page about debugging kernel crashes via serial connection?
<zul> I dont think so
<zul> there probably should be
<BenC> I think it's generally one of those things where the hardware has to support console on serial
<BenC> if it's a crash where the system is still stable enough that the kernel serial console still works, then most likely you don't need serial console
* BenC is working on kdump right now, so that may become helpful
<lamont> tifm_7xx1: sd card detected in socket 1
<lamont> does that mean I can actually talk to it now?
<lamont> hrm.. VESA virtual size - how do I change that in xorg.conf?
<BenC> lamont: It works ofr some types of cards, not all
<lamont> so if removable media are configured to automount and it doesn't, then no love yet, eh?
<BenC> check /lib/modules/`uname -r/kernel/drivers/mmc/
<BenC> might have to manually load one of the block drivers and card handlers
<lamont> ah, ok
<fryfrog> would questions about the linux-restricted-modules debian/rules build script be appropriate here?
<pkl_> lamont: check you've got mmc_core and mmc_block loaded
<pkl_> lamont: some people are not getting mmc_block automatically loaded.
* lamont begins by burning an install CD
<zul> BenC: er...when is the freeze?
<Mithrandir> which of the freezes?
<zul> kernel freeze
<Mithrandir> april 5th
<zul> ah still plenty of time
<BenC> we're in semi-freeze right now
<BenC> I'm not taking much of anything other than bug fixes
<zul> Ill probably have a couple of bug fixes for you on monday
<BenC> the 04/05 freeze is "don't touch it unless it wont boot or eats endangered species"
<Nafallo> ah good. it can eat children then :-).
<Mithrandir> the April 5th freeze is "Ben will pay Tollef cases of beer for each upload". :-)
<zul> lol
<Nafallo> hehe
<zul> right Im heading home..
<BenC> Mithrandir: that might get kind of expensive :)
<ajmitch> BenC: just try & put all the fixes in 1 or 2 uploads
<BenC> there's always last minute fixes
<ajmitch> as long as he doesn't specify expensive beer, it should be fine :)
<ajmitch> you couldn't claim it as misc work expenses?
<crimsun> after a few cases he'll be zonked anyhow, so you can just forego the remainder
<psusi> I'm having a little trouble understanding the relationship between struct request, and struct bio... could someone explain?
#ubuntu-kernel 2007-03-01
<lifeless> kylem: up?
<kylem> lifeless, am now.
<lifeless> kylem: https://beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88899 is really painful for me.
<lifeless> kylem: anything you guys can do would rock, also anything I should do to up the chances of you doing it
<lifeless> jamesh thought it might be linux listening to ACPI from the hardware, and if so that would suck :(
<mjg59> Unlikely
<lifeless> mjg59: apparently salgado's laptop did this in feisty: the IBM ACPI stuff set a throttle when the battery was removed, or something.
<lifeless> you'd need to ask him or jamesh for details though.
<mjg59> I'm not clear what you mean by IBM ACPI stuff
<lifeless> neither am I
<salgado> lifeless, ?
<lifeless> salgado: jamesh was telling me about your ACPI kernel patching
<lifeless> salgado: and I have a possibly similar thing, but nowhere near enough context to point mjg59 in the right direction.
<lifeless> so...
<lifeless> :)
<salgado> hmmm. there's a bug which is still open, but I'm pretty sure it's a bug in my BIOS
<salgado> let me find it
<jamesh> salgado: the fix you did for your problem with the speed being limited with the battery out
<jamesh> salgado: I mentioned to lifeless that his speed limiting problem might be related
<jamesh> (i.e. related to bad info from the ACPI code)
<salgado> well, the fix was basically to ignore the BIOS when it tells the kernel to do stupid things. :)
<salgado> jamesh, lifeless, http://bugzilla.kernel.org/show_bug.cgi?id=7060
<jamesh> lifeless: so you probably want to check if /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq is lower than expected
<lifeless> jamesh: that was fine
<lifeless> jamesh: no it wasn't!
<lifeless> its reporting 6000000 there
<lifeless> rather than 11000000
<lifeless> there are lots of similarly named files :(
<salgado> lifeless, it may also be the same issue Ingo describes in http://lkml.org/lkml/2007/1/16/120
<salgado> (in case you haven't seen it)
<lifeless> I dont track kernel foo - so I haven't
<salgado> I don't either, until it slows down my processor to half of its speed. ;)
<lifeless> cool
* lifeless hopes
<lifeless> night all
<kylem> lifeless, ok. that patch was merged, i'll slurp that in for you.
<kylem> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4233dec749a3519069d9390561b5636a75c7579
<kylem> lifeless, salgado, jamesh: we already have that reversion in ubuntu-2.6.git
<zul> BenC_: I got a patch for you to look at for breezy but Ill show you it tonight when I get home
<Eruantalon> breezy?
<BenC> zul: Ok
<mkrufky> did you guys hear that ivtv is being merged into mainline now?
<mkrufky> it's been a long time coming :-)
<kylem> mkrufky, what's ivtv?
<mkrufky> hardware analog video mpeg encoder driver, based on the iTV cx2341x encoder
<mkrufky> it's the "preferred mpeg encoder" driver
<mkrufky> i believe it is packaged with the ubuntu kernel in the "out-of-tree" driver section
<mkrufky> anyway...  you guys wont have to worry about making ivtv packages and / or compat-porting that driver any longer
<kylem> spiffyo.
<mkrufky> :-)
<dholbach> hey guys
<kylem> holy holbach!
<dholbach> pkl_: do you want me to attach  http://daniel.holba.ch/temp/mmc-KILL.txt  to bug 82680? that's what happened, when I tried to  modprobe mmc_block  and inserted an SD card into my x40
* dholbach hugs kylem
<pkl_> dholbach: yes, please do.
<dholbach> if you want a separate bug for that, I can do that too
<dholbach> (dunno if that's the same cause or not)
<pkl_> dholbach: you have a TI mmc card reader?
<dholbach> pkl_: how do I check?
<dholbach> daniel@lovegood:~$ lspci -v | grep Texas
<dholbach> daniel@lovegood:~$ 
<dholbach> doesn't look like
<dholbach> 02:00.1 Generic system peripheral [0805] : Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSP
<dholbach> ro Host Adapter (rev 13)
<dholbach>         Subsystem: IBM Thinkpad X40
<dholbach>         Flags: bus master, medium devsel, latency 64, IRQ 17
<dholbach>         Memory at d0221000 (32-bit, non-prefetchable) [size=256] 
<pkl_> what does lsmod say? do "lsmod | grep tifm"
<dholbach> empty
<pkl_> If you've got a TI mmc card supported by Linux, it should come up with either "tifm_7xx1" or "tifm_sd"
<pkl_> Can you attach the output of lscpi, lsmod, and  dmesg somewhere, that way I can see what you do have.  Best if you raise a bug, #82680 is (I think) TI mmc card specfic.  I'll check. 
<dholbach> ok, I'll file a new one and let you know.
<pkl_> ok, thanks.
<dholbach> the SD reader worked in edgy
<pkl_> There seems to be a lot of regressions regarding mmc cards.  Still working on finding out why... :-)
<pkl_> dholbach:  "Generic system peripheral [0805]  " is supported by the sdhci driver.  It's likely a problem there.  I'll know more when I've looked at the output from the various commands. 
<dholbach> ok nice, *attaching info*
<dholbach> pkl_: bug 88992
<dholbach> if you need any more info let me know
<pkl_> dholbach: OK.  WIll do.
<dholbach> gracias :-)
<gilligan_> hi
<gilligan_> I have a question regarding the patch made to super_umount which has been patched from super_umount(struct super_block*) to super_umount(struct vfsmount*, int flags) .. flags seems to be 0 in most cases -  I have some sources that rely on the old prototype. I can easily add the integer argument, but is there a straight forward way to patch the sources to  use the vfsmount isntead of the super_block ?
<gilligan_> i.e can I somehow find the vfsmount struct that the super_block belongs to ? then the patching would be easy
<lifeless> kylem: its in git, is it in a package ?
<kylem> yes.
<kylem> it's been in all of them since we merged 2.6.20
<lifeless> so, its not that then.
<salgado> lifeless, is it a regression?
<kylem> sounds like it.
<lifeless> salgado: from edgy yes,
<salgado> lifeless, that patch could have caused the regression. is it broken on pre-2.6.20 kernels too?
<salgado> I mean, post-edgy, pre-2.6.20
<lifeless> salgado: I'll install one today
<lifeless> ok thats *freaky*
<lifeless> I've gone to battery
<lifeless> and now $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
<lifeless> 1100000
<lifeless> excuse while I say WTF
<kylem> possibly some userspace policy is inverted?
<lifeless> scaling_governor is set to 'conservative' now
<lifeless> presumably by gnome-power-manager
#ubuntu-kernel 2007-03-02
<stgraber> Sorry to disturb but I still have this really annoying regression on Feisty : bug #88400
<stgraber> anyone has something I should try that I didn't do already ?
<stgraber> I really hate the idea to have sound on Edgy and then nomore on Feisty
<zul> Im pretty sure its being worked on
<stgraber> I hope so (I'm currently retrieving the latest kernel from git to check what really does this patch and maybe find the key)
<crimsun> stgraber: it's probably the toshiba model addition
<crimsun> stgraber: have you verified that you're running the latest bios on your hardware?
<mjg59> crimsun: Did you see my followup about the Macbook audio?
<crimsun> mjg59: yes, I was just about to reply in -devel
<crimsun> (I've got about 6000 backlogged emails from travel)
<mjg59> Heh
<mjg59> Anyway, it seems to work for me (which is arguably an improvement over the current situation)
<crimsun> great, I'll look at that as soon as I get this email conundrum into reasonable shape
<crimsun> I've also got elmo's sound regression on radar
<mjg59> Cool
<stgraber> crimsun: I'll check but I updated it something like two months ago
<stgraber> crimsun: They released a new bios 3 weeks ago, I'm flashing it now
<stgraber> (If I can find a non-Windows version of it :))
<stgraber> crimsun: ok, I've flashed my bios but still no sound ...
<bdmurray> What do kernel error messages about usb like "not accepting address xy, error -71" mean?
<kylem> oh, pftt, error -71! isn't that obvious!
<kylem> ;P
<kylem> (i haven't the foggiest, got a bug url?)
<bdmurray> kylem: https://launchpad.net/ubuntu/+bug/88746
<bdmurray> see the dmesg attachment
<kylem> thanks.
<kylem> i'll queue it after my current AT
<bdmurray> I'm not specifically curious about this bug but rather about that set of messages in general
<stgraber> crimsun: I've flashed my bios with the latest version from toshiba and guess what, no change ...
<crimsun> stgraber: yes, I read backscroll. I'll give you a patch to try backing out.
<stgraber> thank you
<crimsun> ETA is a few hours, right now I'm a bit busy
#ubuntu-kernel 2007-03-03
<lfittl> zul_, could you take a quick look at  bug #89133 ?
<zul_> which one is this?
* Nafallo misses Ubugtu ;-)
<zul_> lfittl: yeah its queued up for this weekend
<lfittl> zul_, ok thanks :)
<Nafallo> woha! adams twin! :-)
<Nafallo> infinity2: hi :-)
<mjg59> I'm sure we don't need two infinities
<Nafallo> hehe
<mjg59> BenC: Hm. Have you merged the Apple patches I sent you?
<BenC> mjg59: They are in my git, let me make sure I pushed
<mjg59> Ah, cool
<BenC> pushed, you should be able to see them now
<mjg59> Thanks!
<kylem> Keybuk, ping.
<Keybuk> kylem: hi, what's up?
<kylem> http://librarian.launchpad.net/6601009/debdiff
<kylem> can wait til monday if you don't feel like it (i'm working today)
<Keybuk> kylem: heh, good catch
<ssubbiah> Hi ! I am trying to compile the kernel with CONFIG_SERIO_I8042=m to make suspend work in my laptop, but when I issue the make-kpkg command somehow this option is changed back to  CONFIG_SERIO_I8042=y and its not compiled as a module anymore ?  :( 
<ssubbiah> Any pointers
<ssubbiah> ?
<kinley> hi there
<kinley>  hi, want to compile kernel image for xen : got error : "dpkg-gencontrol: error: package linux-xen0-2.6.16.29-bfkdom0 not in control info"  with this command : /usr/src/linux-2.6.16.29# make-kpkg --append-to-version -bfkdom0 --revision 1.00 kernel_image
<kinley> help?
#ubuntu-kernel 2007-03-04
<imbrandon> doh no benc
<lfittl> zul, do you have any idea how to further debug malone #89133 ?
<lfittl> or is there some way to change the major device number lvm2 is using?
<zul> lfittl: you might want to check with iwj
<zul> because I dont use lvm
<lfittl> k, thanks
#ubuntu-kernel 2008-02-25
 * lamont grumbles at -m multiport apparently not liking ipv6 very much
<lamont> (iptables)
<bullgard4> What tools does Ubuntu provide to low-level query the SMBus?
<amitk> bullgard4: i2c-tools?
<bullgard4> amitk: packages.ubuntu.com doesn't know anything about 'i2c-tools' for Gutsy. 
<amitk> bullgard4: aah.. I am on Hardy
<bullgard4> amitk: Are you going to tell me that Hardy will provide a DEB program package 'i2c-tools'?
<amitk> bullgard4: run 'apt-cache search i2c'
<amitk> bullgard4: I am telling you it is already available in hardy :)
<bullgard4> amitk: Excellent! Thank you very much for the good news.
<bullgard4> amitk: http://ubuntuusers.de/paste/46586/
<amitk> hmm.. I guess Gutsy didn't have libi2c-dev, python-smbus, i2c-tools, etc. But you could try to compile them from source packages from hardy
<ki> ghost ride ittttt!
<amitk> jayc: I meant this commit: http://kernel.ubuntu.com/git?p=ume/hardy-ume.git;a=commit;h=1343698dbfde5798b17a56becd663ace088e7cbc
<jayc> amitk: so, what's the right way to do it?
<amitk> jayc: keep them in separate patches :)
<amitk> jayc: I have fixed it now, pushing soon
<jayc> amitk: ok, patch for a patch :-)
<el_cubano> Hello.  I am trying to build the lustre modules for the 2.6.22 kerne.  However, there appear to be some changes because of the AppArmor patch which prevent the lustre modules from actually building.
<el_cubano> Would someone be able to give me a pointer on how to go about removing the AppArmor patch entirely?
<johanbr> Shouldn't 2.6.24-10 have appeared in the archive by now?
<amitk_> johanbr: lum/lrm still need building
<alex_joni> el_cubano: you probably want apt-get source linux-source-...
<alex_joni> then check the patches dir, and remove the patch you don't want
<johanbr> amitk_: Oh, I see. Thanks.
<el_cubano> alex_joni: Really?  There is no patches dir when I apt-get the source.  That is why I am asking for help here.
<alex_joni> el_cubano: you probably did apt-get install linux-source..
<el_cubano> alex_joni: No.  I did 'dget -x http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.22/linux-source-2.6.22_2.6.22-14.52.dsc'
<el_cubano> BTW, I am a Debian developer.  I know the difference between 'apt-get install' and 'apt-get source'
<mjg59> There is no patch system
<mjg59> It's maintained as a git tree
<alex_joni> el_cubano: you should listen to mjg59 :)
<mjg59> el_cubano: You can grab it from git on kernel.ubuntu.com and then revert any of the apparmor commits
<el_cubano> mjg59: Is there an easy way to see which are the app armor commits?  Or do I just need to read the logs.
<mjg59> el_cubano: Probably just the logs, I'm afraid
<el_cubano> mjg59: OK.  Thanks.
#ubuntu-kernel 2008-02-26
<edosar> hi
<edosar> i 'm trying to connect my hardy alpha4 to wireless without much luck, i have a Dynex DX wgUSB
<edosar> some one could redirect me to the proper information so i can give it a try
<kraut> moin
<allerbest> Hi!
<allerbest> I was sent here by folks in #ubuntu-install
<allerbest> I've got a problem installung Edubuntu 7.10 on a brand-new Xeon C2D, Areca 1200 PCIe SATA hardware RAID controller, 8 GB RAM
<allerbest> The installer can't see any disk devices
<allerbest> What to do now? (syslog, lspci -vvnn etc. is online available, if needed)
<rtg> tjaalton: do you have time to do an lrm upload today? The -10 kernel has been accepted into the archive.
<tjaalton> rtg: yes, it's ready although not much has changed
<tjaalton> xen enabled again..
<rtg> tjaalton: cool. thanks. I'm about to prep and upload meta.
<tjaalton> rtg: I also added some plumbing for -virtual but didn't enable it yet
<rtg> tjaalton: what do you think is likely to be a candidate for support in the virtual image?
<tjaalton> rtg: you mean which lrm version will support virtual?
<rtg> tjaalton: no, I was just wondering which module in lrm should be built for virtual.
<rtg> the virtual image doesn't have much for hardware needs.
<tjaalton> rtg: oh right.. I'm not sure if it's needed at all
<tjaalton> just that you asked about it earlier :)
<rtg> OK, I might have been smoking crack at the time :)
<tjaalton> hehe, I'll drop it then
<rtg> anyway, I gotta go. I'll be back online in about 90 minutes.
<tjaalton> ok, see you
<tjaalton> bah, lrm still doesn't build with xen
<tjaalton> well, nv doesn't
<tjaalton> rtg: fglrx failed to build for xen on i386, and the error seems strange (amd64 built fine)
<rtg> tjaalton: turn it off for xen until zul can look at it.
<zul> can you send me the build log?
<tjaalton> rtg: ok..
<tjaalton> zul: a sec
<tjaalton> zul: http://pastebin.ubuntu.com/5010/
<tjaalton> part of firegl_public.c there
<abogani> tjaalton: -rt compile fine?
<tjaalton> abogani: yes
<abogani> tjaalton: Thanks!
<tjaalton> abogani: -rt was enabled already ;)
<abogani> tjaalton: Opssss :-)
<zul> I think you want CONFIG_X86_XEN there
<zul> tjaalton: ^^^
<tjaalton> zul: yep
<tjaalton> zul: so amd64-xen just happens to have one of those defined and it worked?
<zul> I would have to check
<zul> tjaalton, amd64 xen is setup different 
<tjaalton> zul: ok
<tjaalton> zul: nv-new fails to build as well, "nv-linux.h:115:22: error: xen/page.h: No such file or directory"
<zul> tjaalton, ok Ill have a look 
<zul> where can I get the source from?
<tjaalton> https://edge.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/2.6.24.9-10.26
<tjaalton> note that you need to add xen to nv_flavours
<tjaalton> zul: I wonder if "export IGNORE_XEN_PRESENCE=1" has anything to do with it..
<zul> tjaalton, no idea im still downloading it
<tjaalton> zul: there was a patch for ati in ati/patches-old :)
<zul> so it works now?
<tjaalton> ati build works
<zul> nifty but not the nvidia?
<tjaalton> right
<tjaalton> actually, I didn't try the build on i386
<zul> tjaalton: http://people.ubuntu.com/~chucks/1-nvidia-2.6.24-xen.patch
<tjaalton> zul: that's the one from the package?
<zul> tjaalton, yeah I modified where its looking for page.h
<tjaalton> aah
<tjaalton> one final build with both archs..
<tjaalton> zul: ok, more problems :)
<zul> tjaalton, yay send me the log
<tjaalton> zul: http://pastebin.ubuntu.com/5016/
<BenC> New page: https://wiki.ubuntu.com/KernelTeam/Sprints
<abogani> Good Sprint days guys! :-)
<BenC> Updated: https://wiki.ubuntu.com/KernelTeam/Roadmap
<johanbr> mjg59: Could I ask you about something ACPI-related? Could an error like "ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node ffff81007c364b60), AE_NOT_FOUND" on resume make cpufreq support disappear on one core?
<BenC> BTW, kernel meeting canceled today because of sprint...we are all stuffing our faces with lunch right now :)
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-8.14 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 4, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-10.16 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 4, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<jayc> amitk__: Does ubuntu-hardy have the latest moblin patches (USB Client beta 4) yet?
<amitk__> jayc: What does the DRIVER_VERSION string in iusbc.c read?
<amitk__> jayc: alpha4 will be uploaded to hardy later this week
<jayc> amitk__: DRIVER_VERSION  "2.0.0.32L.0008"
<jayc> amitk__: alpah4 or beta4? I was talking about 0017-poulsbo_USBC.patch
<jayc> amitk__: From the ubuntu/ubuntu-hardy.git log it looks like the latest moblin patches are not in ubuntu-hardy yet.
<amitk__> jayc: I meant alpha4 in hardy. The last patch you submitted isn't in hardy yet. It will come end of the week
<jayc> amitk__: Ok, thanks. some one here at Intel was asking about it.
<amitk__> jayc: is there a deadline for that?
<jayc> amitk__: I'm not aware of it, I will have to find out
<amitk__> jayc: i'm am not aware of it either, once an image for intel is made this week, I will update hardy with your last set of patches
<jayc> amitk__: got it
<mjg59> johanbr: Quite possibly
<allerbest> Hi.
<allerbest> I've got a problem installing Edubuntu 7.10 x64 on a brand-new server with Xeon 3075, 8 GB RAM, Areca ARC-1200 SATA RAID controller. Installation runs smooth until a "Detect disks" dialog pops up.
<allerbest> I'm asked to pick a drive since none was detected.
<allerbest> The guys from #ubuntu-installer send me to this channel.
<allerbest> 'parted_devices' returns no output, same for 'list-devices disk'
<allerbest> (in the rescue console ALT-F2)
<allerbest> lspci detects the controller as:
<allerbest> 05:00.0 RAID bus controller [0104]: Areca Technology Corp. Unknown device [17d3:1201]
<allerbest> But the ARC-1200 should be supported by the 'arcmsr' module, right?
<johanbr> mjg59: I see. Can the kernel be made to work around that somehow? (this is bug #124797)
<ubotu> Launchpad bug 124797 in linux-source-2.6.22 "CPU Frequency Scaling Monitor applet on dual-core doesn't work after resume" [Undecided,Invalid] https://launchpad.net/bugs/124797
<mjg59> johanbr: If you only get it on resume and not on boot, we probably need to work out why it's happening
<johanbr> Alright. Cpufreq works fine on boot, but after resume the sysfs cpufreq directory on the second core disappears. What more information would you need?
<johanbr> Apart from what's already in the bug, that is.
<allerbest> Has anyone got a clue what's going on with the kernel & ARC-1200?
<allerbest> The guys from #ubuntu-installer send me to this channel.
<allerbest> I've got a problem installing Edubuntu 7.10 x64 on a brand-new server with Xeon 3075, 8 GB RAM, Areca ARC-1200 SATA RAID controller.
<allerbest> Installation runs smooth until a "Detect disks" dialog pops up.
<allerbest> I'm asked to pick a drive since none was detected.
<allerbest> 'parted_devices' returns no output, same for 'list-devices disk'
<allerbest> (in the rescue console ALT-F2)
<allerbest> lspci detects the controller as:
<allerbest> 05:00.0 RAID bus controller [0104]: Areca Technology Corp. Unknown device [17d3:1201]
<allerbest> But the ARC-1200 should be supported by the 'arcmsr' module, right?
<BenC> allerbest: It's not supported in gutsy (7.10), but it is in hardy
<BenC> allerbest: I suggest either giving hardy Alpha 5 a try, or wait a couple days and try Alpha 6
<BenC> both should work
<allerbest> Hm. Thanks for the answer.
<allerbest> Unfortunately I don't have weeks to wait
<allerbest> The pupils are waiting and without the LTSP server they don't have anything ...
<allerbest> Why is it not supported? "arcmsr" is included in 7.10.
<allerbest> Is there a way to inject a new module to the installation process?
<amitk__> allerbest: because support for the 1200 was only added in September, so it didnt get into Gutsy 7.10
<allerbest> Argl.
<allerbest> Bummer.
<allerbest> Are there any workarounds?
<amitk__> allerbest: you could patch your own kernel
<allerbest> Is there a how-to?
<allerbest> I know how to compile a kernel.
<allerbest> but not how to inject/add to the installation process of Ubuntu/Edubuntu
<JanC> allerbest: try searching the wiki for "kernel"
<JanC> and maybe you only need to compile a module ?
<allerbest> https://wiki.ubuntu.com/ModuleBuilding?highlight=%28module%29
<allerbest> ?
<allerbest> nope ...
<alex_joni> allerbest: there's a wiki page on the LiveCD, it also includes a section how to replace the kernel
<alex_joni> Customizing the LiveCD I mean
<allerbest> Hm. I hope the procedure is the same for the server version
<allerbest> (because I need the server)
<alex_joni> I'm sure it's very similar
<alex_joni> I packaged a LiveCD with a custom kernel a while ago (2 years), and basicly I had to follow those steps, install the new kernel packages, then replace vmlinuz and the initrd
<allerbest> okay, thanks
<tjaalton> rtg: typical.. nvidia released 169.12 today
<tjaalton> rtg: but it'll have to wait for a while
<rtg> tjaalton: isn't that the way it always works :)
<tjaalton> rtg: apparently yes.. anyway, there's the conexant driver which could be useful as well, so a new tarball would take some time anyway :P
<tjaalton> also, fritz and ltmodem have been disabled all this time, so maybe try to resurrect those as well
<allerbest> Thanks for the support & good night ...
<rtg> jayc: how about changing the email address in debian/changelog before you upload to your PPA ? I assume you want the build failure emails.
<jayc> rtg: Was that the reason for build failure?
<rtg> jayc: probably not, I didn't read them.
<jayc> rtg: but I'm getting the emails though
<rtg> jayc: as am I :)
<jayc> rtg: sorry, :-( I didn't realize that
<CarlFK> what has to take place for this patch: http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01968.html  to get into the hardy kernel? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/usb/host/ehci-q.c;h=b10f39c047e944848f3ac2aa4067e820d2f5df90;hb=HEAD#l314
#ubuntu-kernel 2008-02-27
<CarlFK> can the compiles done by fakeroot debian/rules use distcc?
<bullgard4> What is meant by 'platform' of the /sys/devices/platform directory? What does the term 'platform' comprise here?
<dade`> http://packages.ubuntu.com/hardy/linux-restricted-modules-2.6.24-10-generic
<dade`> there is no i386 version ?
<kraut> moin
<CarlFK> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/media/video/vivi.c;hb=053fcb6014eef31c2674d344c704118e0ac229ef#l1125
<CarlFK> 1125 //      .release        = video_device_release,
<CarlFK> pretty sure that is //ed in the stock kernel - 
<CarlFK> and shouldn't be
<CarlFK> where should I report that?
 * ogra_cmpc hugs rtg 
<ogra_cmpc> whatever you did to the rt73usb driver between -5 and -10 it was a 500% improvement 
<ogra_cmpc> (at least 500 :) )
<ogra_cmpc> (on the classmate)
<CarlFK> ogra_cmpc: your usb comment causes me to ask if you can comment on this: 
<CarlFK> what has to take place for this patch: http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01968.html  to get into the hardy kernel? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/usb/host/ehci-q.c;h=b10f39c047e944848f3ac2aa4067e820d2f5df90;hb=HEAD#l314
<CarlFK> (05:15:59 PM) crimsun_: CarlFK: although I might add that since it is targeted to 2.6.25, hardy will pick it up automatically.
<crimsun_> CarlFK: sorry, that should have been against 2.6.24.x, not 2.6.25
<CarlFK> either way - whats the schedule/process that takes place for it to be picked up?
<crimsun_> CarlFK: either request that it be picked up, or just wait
<CarlFK> request on u-dev list?
<crimsun_> here, the kernel-team@ list, ...
<CarlFK> ok.
<CarlFK> crimsun_:  another issue I just bumped into, but I want the details worked out before I make a request: where is the upstream kernel tree?  I am trying to figure out why this line is //ed out:
<CarlFK> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/media/video/vivi.c;hb=053fcb6014eef31c2674d344c704118e0ac229ef#l1125
<CarlFK> same line: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/media/video/vivi.c;h=1db067c028157609c895b0124e72143acd94c8b2;hb=a6352cddc743300b0b64b5fd8dfb688524e884e9#l1194
<amitk__> CarlFK: file a bug in launchpad, and/or send email to kernel-team@lists.ubuntu.com
<CarlFK> but not sure if that is the right upstream source 
#ubuntu-kernel 2008-02-28
<arcticpenguin380> would it be possible to add reiser4 in the ubuntu kernel in hardy +1?
<_MMA_> arcticpenguin380: I'm sure when it's ready, it will be.
<arcticpenguin380> its ready but ists not in the kernel
<CarlFK> what exactly  (url) is "Linus' tree" in ""During development, the kernel git repository  is being constantly rebased against Linus' tree"  https://wiki.ubuntu.com/KernelGitGuide 
<CarlFK> I am guessing  linux/kernel/git/torvalds/linux-2.6.git  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;h=b4e3c8094b13fe3361213d0a2893a10bdd19a24b;hb=a6352cddc743300b0b64b5fd8dfb688524e884e9
<CarlFK> but i'm not sure 
<crimsun_> yes, linux-2.6.git
<CarlFK> arg
<CarlFK> crimsun_: how do I find out why a line differs between linux-2.6.git and ubuntu/ubuntu-hardy.git ?
<crimsun_> well, "why" is more complicated.  What's the issue?
<CarlFK> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/media/video/vivi.c;hb=053fcb6014eef31c2674d344c704118e0ac229ef#l1125
<mjg59> CarlFK: We pull off the stable branch, rather than the head of Linus's tree
<CarlFK> why is that line //ed? 
<mjg59> CarlFK: git-blame on a file will tell you who touched it
<mjg59> CarlFK: In this case, it was //ed since 2006. I'd guess it's been changed in 2.6.25, which we don't rebase off
<CarlFK> ah
<CarlFK> getting somewhere...
<mjg59> CarlFK: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f905c442e5b19f75fe4e8ce96f2acffa565f2392
<CarlFK> awesome
<mjg59> CarlFK: If you email kernel-team@ubuntu.com, you can probably ask for that to be cherry-picked into the hardy kernel if it fixes a bug
<CarlFK> cool.  
<CarlFK> thank you very much - I have been trying to pin this down on and off all day
<CarlFK> probably burned up 2 hours 
<CarlFK> easy
<Yashy> I was using xubuntu amd64 with my dual core (X2) CPU just fine. I just replaced it with xubuntu i386, and although the kernel (uname -a) says SMP, it's only showing one CPU. Any ideas?
<Yashy> [    5.316000] CPU #1 not responding - cannot use it. # from dmesg 
<CarlFK> Yashy: I bet you want -generic 
<Yashy> Linux delly 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
<CarlFK> no clue - I was in over my head from the start :)
<Yashy> acpi=off was the magic answer if anyone else ever asks.
<shashi> Can any one tell me, if i have x86 hardware, and if i install Linux on it, through which command i can check whether my hardware is 32-bit or 64-bit ?
<CarlFK> shashi: lshw: product: Intel(R) Pentium(R) 4 CPU 3.00GHz
<CarlFK> also: cat /proc/cpuinfo model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
<shashi> Is "lshw" works only in Ubuntu ?
<shashi> From this "Intel(R) Pentium(R) 4 CPU 3.00GH" , how we can tell whether my hardware is 32-bit or 64-bit ?
<CarlFK> good Q.  look up the specs on that chip I suppose 
<CarlFK> btw /topic says " Ubuntu kernel development discussion ONLY " so this discussion should continue in #ubuntu 
<Kano> hi rtg , did you add my fix for the xplorer guitar?
<Kano> also lum is not bumped to 11
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic/source/xpad-2.6.24.patch
<Kano> just 2 lines change, then it works
<rtg> Kano: have you filed an LP bug so I can track it?
<Kano> no, why is always a bug needed for a 2 lines change
<Kano> isnt that a bit extra complicated
<rtg> Kano: its part of the process. If I commit the fix with the bug number in the commit message, then the ubuntoid will update the bug report and mark it fix released.
<Kano> produces extra work
<rtg> Kano: it ain't gonna change.
<Kano> can you show me an example line for vfat on a hardy install
<Kano> i dont want to install it yet
<rtg> Kano: I'm not sure what you mean.
<Kano> fstab
<Kano> did you update aufs?
<rtg> Kano: did you file an LP bug?
<Kano> it really seems nobody from ubuntu adds "bugs" himself to fix even major problems
<Kano> when you look at ntfs-3g for example
<rtg> complain, complain. Look, I'm done for the day. She who must be obeyed is calling.
<Kano> it is still 1.1120 and you should read on the ntfs-3g.org homepage that the 1.2216 is an really needed update
<Kano> a clever one would get the ntfs-3g mailing list
<Kano> so added for both bugs...
#ubuntu-kernel 2008-02-29
<mjg59> BenC: #180678 - seriously. Every single release I can remember. This really isn't funny any more.
<alex_joni> bug #180678
<ubotu> Launchpad bug 180678 in acpi-support "dmesg: toshiba_acpi: Unknown parameter `hotkeys_over_acpi'" [Medium,In progress] https://launchpad.net/bugs/180678
<BenC> mjg59: every release it is the same reason...acpi core changes so much the patch cannot be applied
<BenC> mjg59: pretty sure it was in the list of "patches that got left behind"
<BenC> mjg59: we've audited the patches that got removed at hardy kernel rebase, and that's the only one
<mjg59> BenC: As far as I can tell, that mail never went anywhere public?
<mjg59> Amit replied with a subset Cc:ed to kernel-team
<BenC> mjg59: I mean the list I sent you months ago
<mjg59> BenC: No, it's not in that list
<mjg59> Can you check whether any other patches have fallen through the cracks?
<amitk> BenC: can you please send me this other list that you sent to mjg59
<BenC> mjg59: I told ya we just did an audit of the patches :)
<BenC> amitk: it's the same one you got, minus stuff that already got checked
<amitk> BenC: ok
<mjg59> BenC: As I said, that patch isn't in hardy git. It was in gutsy. It's not in the email you sent me.
<mjg59> If your audit process doesn't pick that up, then that's a problem with your audit process
<mjg59> Which is consistent with previous occasions where patches have gone missing from the lists of missing patches
<mjg59> BenC: 2d35697db5e3c4f240ac288c7c5abeb5a03c805c in gutsy
<BenC> interesting...it applies cleanly...wonder why it didn't hit the rebase
<mjg59> BenC: It would be good to know if anything else falls into the same category
<rtg> BenC: be sure to mark it as  a SAUCE patch so we don't lose it again.
<siretart> did someone already encounter bug #197006, and/or knows a workaround?
<ubotu> Launchpad bug 197006 in linux-meta "NFS over Unionfs prevents updating existing files" [Undecided,New] https://launchpad.net/bugs/197006
<BenC> mjg59: toshiba_acpi patch applied
<mjg59> BenC: Thanks
<rtg> tjaalton: I'm turning the ABI crank today. I'll upload -11 in a few hours in advance of Alpha 6 scheduled for next Thursday.
<Kano> hi rtg , did you find my bug report
<Kano> rtg: btw. the ivtv-fb driver is not working, maybe compiled against wrong header
<rtg> Kano: I didn't notice it. What number is it?
<Kano> #196745
<Kano> will check if i can do a fix for ivtv-fb
<rtg> Kano: we are still working on the ABI mismatch which is probably what is wrong with ivtv-fb
<Kano> yes the most easy way is to overwrite the included .h files with the one from the kernel
<Kano> that fixes it
<rtg> Kano: can't do that (debian policy). see https://wiki.ubuntu.com/KernelTeam/Sprints/Feb2008/HeadersABI for possible solution
<Kano> then remove the included headers
<Kano> how about that
<Kano> they are not needed anyway
<rtg> dunno. we'll get it figure out before Beta.
<Kano> the fastest hack is just to replace the ivtv-fb headers - not the kernel ones
<rtg> Kano: at the risk of sounding pedantic, file a  LP bug so I can track it.
<Kano> rtg: will try to fix it and then report a bug
<Kano> i have got a pvr 350..
<Kano> just dont use it so often
<tjaalton> rtg: ok, I have nvidia almost ready to go, targeted -11
<Kano> rtg: how about enabling vmware client modules?
<rtg> Kano: which ones? seems like there is a pending LP for a sound module.
<Kano> well the standard ones needed for vmplayer
<Kano> i think those will not change
<rtg> Kano: do you think enabling ALSA in the kernel would be sufficient?
<Kano> virtual box needs always differnet modules, so i would not integrat it
<Kano> i think you have alsa already enabled?
<Kano> didnt you
<tjaalton> zul: what about xen & nvidia?
<zul> tjaalton, i havent got a chance to look at it
<tjaalton> zul: ok
<Kano> rtg: also did you notice that "ifneq ($(wildcard /CurrentlyBuilding),)" has to be "ifeq ($(wildcard /CurrentlyBuilding),)" in debian/rules.d/0-common-vars.mk ?
<Kano> currently it is absolutely stupid that it compiles faster when there is a dir/file named /CurrentlyBuilding
<Kano> dont you think so...
<Kano> ps aux|grep -e -j
<rtg> Kano: looks to me like it just overrides CONCURRENCY_LEVEL when on a buildd.
<Kano> yes, but completely in the wrong way
<Kano> why would somebody build on a multi core machine with -j1?
<Kano> you could even disable that check
<rtg> Kano: because there might be other builds going on the same machine.
<Kano> rtg: i thought that, but then the logic is completely reversed!
<Kano> as you compile with 1 thread when there is NO such file and with twice the number of cores when it is there
<Kano> check it out yourself
<Kano> you will at least see -j2 even with a single core when the file is there and -j1 when it is not there
<Kano> must be clear
<Kano> that this is wrong
<rtg> Kano: this particular problem is not important. I've a zillion other issues to deal with. buildd passes happen overnight for me, so I just don't care.
<Kano> rtg: but i care
<rtg> start a bug report then.
<Kano> you only have to remove the "n" 
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197040
<ubotu> Launchpad bug 197040 in linux "reversed logic for bbuild check leads to -j1 default" [Undecided,New] 
<Kano> here it is
<Kano> sound/usb/usx2y/snd-usb-usx2y.o
<Kano> you mean that erro?
<Kano> hmm no, the error is in toshiba_acpi.c
<Kano> what did you do there
<rtg> Kano: I'm just getting to buld testing. looks like the acpi crack broke something.
<Kano> yes it does not build
<tjaalton> rtg: lrm with new nvidia ready
<rtg> tjaalton: I'm still build testing. it'll be a bit yet.
<tjaalton> rtg: np
<Kano> tjaalton: if you added .12 then you can be sure it will not be the last update
<tjaalton> Kano: surprise
<Kano> latest is still set to 169.112
<Kano> that can show my script with -v latest option...
<Kano> DISPLAY= fakeroot install-nvidia-debian.sh -pv latest
<Kano> 169.12
<rtg> mjg59: can you have a look at the acpi patch BenC applied? It doesn't build, so I've reverted it. I'm kind of on a deadline for Alpha 6.
<mjg59> rtg: Not currently, no
<mjg59> I'm up to my eyes in mobile
<rtg> mjg59: ok, its gonna have to wait until after -11 is released.
<mjg59> Well, as long as it hits before final, I'm unfussed
<rtg> mjg59: can do.
<Kano> btw. you know that at least 2 ide modules are too much?
<Kano> via82cxxx and amd74xx are useless, because you have pata_via and pata_amd
<Kano> which work much better
<Kano> maybe more, but you can be sure that pata drivers are tested for those
<Kano> tjaalton: so what did you package 169.12 or 171.05?
<Kano> btw. did you try pxe boot for your live images?
<Kano> live-helper can for example use net as target
<Kano> and creates a tftpboot dir
<boucman> hello all
<boucman> I have been skimming the bug list for some time, but can't find a bug similar to what I observe
<boucman> my machine has some huge speed problems with 2.6.24 (2.6.22 is fine)
<Kano> boucman: lsmod|grep -e ide -e pata
<Kano> best check this
<Kano> if you have got an legacy ide + pata driver loaded blacklist the old ide and run: update-initramfs -u
<boucman> Kano: thx... I'm using 2.6.22 right now, are you interested in what it reports, or should I reboot in 2.6.24 to check ?
<Kano> well you would need 2.6.24
<Kano> to get this output
<boucman> I do get an output :P
<Kano> sure, but i dont think something with pata or?
<boucman> Kano: you're right
<boucman> I'll reboot in a minute, but since I'm unable to log to irc with that kernel, what should I be looking for precisely ?
<Kano> the problem is when you would do that now you could not boot your old kernel ;)
<Kano> i would prefer those old modules removed, but..
<boucman> you mean 2.6.22 wouldn't boot anymore after doing that ?
<Kano> if you blacklist the module and run update-initramfs -u (updates initramfs for current kernel)
<Kano> usually the new kernel runs the devices without dma access
<Kano> because 2 drivers want to work with the same device, disabling the old ones fixes that usally
<boucman> Kano: ok, can you walk me throught the process (or point me to a web page ) I would be gratefull
<Kano> well i dont think that ubuntu ppl did that before, thats what i did for kanotix users ;)
<boucman> ok, so 
<boucman> 1) blacklist the module 
<tjaalton> Kano: 169.12
<boucman> 2) reboot with .24 kernel
<boucman> 3) run "update_initramfs -u"
<boucman> right ?
<Kano> no you forget the major step
<boucman> oh, 
<Kano> the blacklisting
<boucman> that was step 1, but I'm not sure how to do that
<Kano> show me lsmod|grep -e ide -e pata
<Kano> after reboot
<boucman> Kano: ok, I'll reboot, do that and come back.
<boucman> then we'll discuss how to fix
<boucman> and thx a million for your help
<boucman> brb
<boucman> back
<Kano> so check lsmod|grep -e ide -e pata
<Kano> also
<Kano> cat /etc/fstab
<Kano> cat /proc/cmdline
<boucman> video                  23316  0 
<boucman> output                  5632  1 video
<boucman> ide_core              136344  1 amd74xx
<boucman> pata_amd               16772  0 
<boucman> pata_acpi               9856  0 
<boucman> libata                176304  4 pata_amd,sata_nv,ata_generic,pata_acpi
<Kano> to be sure that you use uuids
<boucman> that's under .24 (i'm back to .22 right now)
<Kano> the problem is definitely amd74xx
<boucman> ok
<Kano> why dod you boot the .22 kernel?
<Kano> doesnt it boot at alls?
<boucman> it does, but usually it takes approx 5' just to start pidgin
<boucman> so not really usable
<Kano>  cat /proc/cmdline
<Kano> show this
<boucman> root=UUID=aefdb9c5-c42d-4de4-863d-e8db4afcd1e8 ro quiet splash
<Kano> ok, should be no problem to use the fix
<boucman> :)
<Kano> which 2.6.24 do you want to fix
<boucman> main one, I guess
<Kano> -10?
<boucman> yes, that's the latest one
<Kano> ls /boot/vmlinuz-2.6.24-*
<boucman> (so far :P )
<Kano> show this
<boucman> /boot/vmlinuz-2.6.24-10-generic
<Kano> echo blacklist amd74xx > /etc/modprobe.d/custom-blacklist
<Kano> update-initramfs -uk 2.6.24-10-generic
<Kano> then you should be able to boot new kernel
<boucman> running...
<boucman> ok, done
<boucman> I'll be back in a minute (hopefull with .24) thx again for your time
<Kano> i hope you did that after sudo -i
<Kano> then it should work
<boucman> yeah, I used the "administrator terminal" not the normal one
<Kano> rtg: at least it compiles with reverted toshiba
<Mike_Feravolo> Hello People
<Mike_Feravolo> I loaded the lastest hardy update and my dual amd opteron 840 will not boot anymore
<Kano> Mike_Feravolo: i guess because of amd74xx kernel module in initrd ;)
<boucma1> hmm
<Mike_Feravolo> i just what to make sure that someone knows
<Kano> boucma1: didit boot
<boucma1> Kano: yes, but pidgin froze at startup like it used to, I'll start a few app to see if it's better than previously
<Mike_Feravolo> i have been running the hardy alpha for a couple of months and this is the first major snarl
<boucma1> and login was very slow...
<Kano> boucma1: but at last the hd should be fast, you could check that
<Mike_Feravolo> kano- hangs on the UBUNTU splash screen
<boucma1> Kano: yes, it seems to work better but still very slow
<Kano> boucma1: i only use the kenrel not the rest
<boucma1> Kano: well, pidgin start time was my measure of perf, but it applies to everything
<boucma1> it's usable now, at least
<Kano> boucma1: fdisk -l
<Kano> then you will see only sd?
<Kano> you can then check performance with
<Kano> hdparm -tT /dev/sd?
<Mike_Feravolo> I am not near that system now, but i will try a few things before reloading gusty - Thank You
<Kano> Mike_Feravolo: can you boot antoher kernel?
<boucma1> /dev/sda:
<boucma1>  Timing cached reads:   1604 MB in  2.00 seconds = 801.97 MB/sec
<boucma1>  Timing buffered disk reads:  220 MB in  3.00 seconds =  73.27 MB/sec
<boucma1> (no idea if that's good
<Kano> sure, without dma it would be less than 10 the 2nd one
<boucma1> ok
<Mike_Feravolo> yes the gusty 64 live cd boots, so does dsl, slax and other 32bit distros
<Kano> well you only need a live cd to chroot to it
<Kano> if your install is 64 bit you need that of course
<Mike_Feravolo> kk
<Mike_Feravolo> thanks
<boucma1> ok, thx a lot, I'll use it like that
<boucma1> bye all
<Kano> rtg: i hope you get how bad the amd* module is...
<Kano> via is not needed too
<Kano> blacklisting is a bit dangerous to older kernels,but easy to verify
<Kano> best disable the modules you dont need
<Kano> via+amd are the most common ones
<Kano> rtg: disable at least
<Kano> grep BLK_DEV /boot/config-2.6.24-10-generic |grep -e AMD -e VIA
<Kano> CONFIG_BLK_DEV_AMD74XX=m
<Kano> CONFIG_BLK_DEV_VIA82CXXX=m
<Kano> to avoid huge problems
<Kano> amd is critical
<Kano> rtg: also you could use -jX for lum too
<Kano> rtg: http://paste.debian.net/50205
<Kano> thats the problem with ivtv-fb
<Kano> rtg: what you try is to use ivtv-driver.h
<Kano> rtg: thats basically <linux/ivtv.h>, but then you have to fix the driver itself
<rtg> Kano: is there a patch for ivtv-fb ?
<Kano> well not an easy one
<Kano> 1.0.3 is only up to 2.6.23
<Kano> where did you get the driver?
<rtg> dunno, probably inherited it from Feisty/Gutsy
<Kano> will check if the driver can be used from v4l hg
<Kano> maybe you need then ivtv + ivtvfb from hg
<Kano> hmm that will also need m52790
<rtg> Kano: https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/197089
<ubotu> Launchpad bug 197089 in linux-ubuntu-modules-2.6.24 "ivtv oops" [Medium,Confirmed] 
<Kano> well disalbing is not really fun. as you could even use a new xorg driver with it or for pvr350 output plugin
<Kano> btw. the -j bug is in lum too
<Kano> for debugging -j1 is more easy but in that case you can set CONCURRENCY_LEVEL=1 if needed
<Kano> rtg: maybe it is much more easy 
<Kano> you have that module already
<Kano> in the main kenrel
<Kano> but you miss the right firmware
<rtg> Kano: attaching a patch to the LP report increases the likely hood  that it will get fixed .
<Kano> rtg: you can remove the code completely from lum
<Kano> the module is default and enabled in the kernel
<Kano> you only need the correct firmware
<rtg> which needs to be updated in lum
<Kano> hmm
<Kano> when this is already in lum just disable the module -you can completely remove the code
<Kano> http://paste.debian.net/50210
<Kano> when i remove lum
<Kano> grep -i ivtv /boot/config-$(uname -r)
<Kano> CONFIG_VIDEO_FB_IVTV=m
<Kano> CONFIG_VIDEO_IVTV=m
<Kano> standard kernel
<rtg> is the firmware the same version as is already in lum? the file names are the same as the web site.
<Kano> didd not try, but look
<Kano> isnt that nice
<rtg> its certainly an easy fix.
<NthDegree> where can I find a list of .patch files used in the Ubuntu Gutsy kernel?  as in each individual patch, like for example just ubuntu's apparmor patches or just ubuntu's dazuko patches 
<Kano> rtg: yes and it seems to work
<rtg> NthDegree: https://wiki.ubuntu.com/KernelGitGuide
<Kano> http://paste.debian.net/50212
<rtg> NthDegree: search the log for 'SAUCE:'. Thats most of our special patches.
<NthDegree> hmmm
<Kano> so you just have to disable some legacy ide modules
<rtg> Kano: I'm still researching that
<NthDegree> rtg: so there's no chance of just grabbing things like a linux-2.6-apparmor.patch or the like that applies to the Ubuntu kernel then?
<Kano> rtg: kanotix thorhammer has a kernel completely without config_ide set. only very few pcs could not boot it
<Kano> the 2 modules i told you before are definitely verified
<Kano> and share the same pciids
<rtg> Kano: its likely that I'll blacklist them so that the binaries are still built, just not installed.
<Kano> no good idea
<Kano> because when somebody executes update-initramfs -uk all
<Kano> then older 2.6.22 kernel will never be bootable
<Kano> isnt something like that even triggered by module-init-tools?
<Kano> you can use that as hotfix
<Kano> but no for permanent use
<rtg> Kano: start an LP report so we don't lose track, but its gonna have to wait until after Alpha 6 and I'm gone Mar 4-27 so you'll have to deal with the other kernel folks
<zul> hmmm... https://wiki.ubuntu.com/ZenKernel
#ubuntu-kernel 2008-03-01
<Solarion> any chance on getting usb persist enabled in the hardy kernel?
<Solarion> would help those with ee's a lot
<Solarion> eee, even.  :)
<cyrusjunior> Hello All.
<amitk> Solarion: could you elaborate what you are looking for?
<Solarion> amitk: still there?
 * Solarion is UTC-6
<Solarion> guess not
<Solarion> so usb support is compiled in, not modular?
<clever> i seem to have a usbcore.ko loaded in 6.06
<rtg> tjaalton: the -11 headers are in the archive.
<soren> I have a question about the gitguide on the wiki.
<soren> It says that if I have local commits, the way to update my tree from ubuntu's main branch is to:
<soren>   git log origin..HEAD | awk '/^commit/{print $2}' | tac > local-commits
<soren> so I have all my local commit shas in local-commits in a sensible order..
<soren> Then:
<soren>   git branch new-head
<soren> That will create a new branch based on my current branch which is the one with my local commits, right?
<soren> Assuming that that's indeed the case, let's move on:
<soren>   git checkout new-head
<soren> Switches my working tree to the new-head.
<soren> And then it wants me to do:
<soren>   for cmt in `cat local-commits`; do git-cherry-pick $cmt || exit; done
<soren> ...but if the branch is based on my branch with all my local commits, how does it make sense to cherry pick all the commits again? They're already there?
<soren> And that "exit" should probably really be a "break".
<soren> rtg: Ah, great timing. Got a minute to clear some git business up for me?
<Nafallo> I hope this channel is http-logged ;-)
<soren> because...
<Nafallo> hehe. it's not logging fast enough :-P
<soren> I was going to /msg it to him.
<Nafallo> just checked to see if I could save you some typing ;-)
<soren> :)
<soren> Aha. "git branch new-head origin" rather than "git branch new-head" restores sanity.
<soren> Yay wikis.
<tjaalton> rtg: thanks, lrm uploading
<__Neo__> Hi, is there a variant of Ubuntu that uses official (or mirrors of) Debian repositories either stable or later?
<Nafallo> __Neo__: wrong channel for that question.
<Nafallo> __Neo__: you could actually try #ubuntu
<__Neo__> ok
#ubuntu-kernel 2008-03-02
<TMM> hi all
<TMM> I've got a quesion about suspend/resume, I'm not entirely sure it is kernel related though, but it might be. if you suspend with an USB drive attached and mounted with files open, on resume the filesystem is apparently thawed before the device comes back, leaving some fairly undesireable effects :) I'm not entirely sure if it affects all usb removeable devices, but at least my SD slot suffers from that problem. I want to locate exactly what
<TMM>  goes wrong, but I haven't had any luck
<TMM> So, I ask here :) I hope that is OK
<TMM> so, normal external usb devices present the same problem
<peppy> hello all
<peppy> Have a question, Why is it
<peppy> Ubuntu?
<peppy> I mean why that name?
<tuxmaniac> :)
<sioux> hi :-D
<sioux> no one is on line?
<sioux> just a quick and simple info
<sioux> i need
<sioux> fabbione: are you sleeping?
<rambo3> What gcc version is kernel compiled with?
<matjan> hi, i have some troubles after the hardy update of this morning... can i report that here?
<matjan> Mar  2 12:37:56 quadpc kernel: [    0.000000] WARNING: NR_CPUS limit of 1 reached.  Processor ignored.
<Nafallo> no. you need to file a bug on launchpad.
<matjan> ok
<mjg59> matjan: You're running the -386 kernel?
<lovetotouch> could someone help me build a modified usbmon for use with the stock kernel in Gutsy?
<Solarion> anyone around?
<Kano> hi, is the dkms maintainer here
#ubuntu-kernel 2009-02-23
<msa> I've kernel mod doing debug <7> msg's, however cant seem to get them visible anywhere on intrepid... (used to -work fine earlier into syslog
<msa> killing syslogd and klogd, and doing "sudo cat /proc/kmsg" shows them, but does not do it continuously (again, -used to work fine)
<msa> (e.g. I can see all messages wth cat /proc/kmsg, but have to keep doing ctrl-c and reissuing the command)
<riham> guys, I would like to ask a Q about kernel native aio , io_submit seems to be blocking so ...  does anybody have a clue ?
<JackWinter> is this the right place for problems compiling a kernel module under kubuntu 8.04 ?
<JackWinter> i'm trying to install vbox-2.1.4 on kubuntu 8.04.  i can compile the kernel module but when i try to load it i get the following error: [  621.528827] vboxdrv: Unknown symbol __stack_chk_fail
<JackWinter> have tried different kernels and also removing and reinstalling linux-headers
<mjg59> Build with -fno-stack-protector
<JackWinter> mjg59: sorry not very good at this.  how do i do that ?  can i change a global option for my system ?
<mjg59> I've no idea how the virtualbox build system works
<JackWinter> it's got a Makefile.  what is strange is that it worked before, something must have changed on my system
<smb_tp> In general I would suspect they use a "normal" out of tree thing...
<smb_tp> What exactly is before. 8.04 but older kernel?
<JackWinter> i think i have a problem loading the closed nvidia drivers too.  also a kernel module
<smb_tp> JackWinter, Hm, could it be that this happened after getting 2.6.24-23.48 kernel?
<JackWinter> no i have the problem with any 8.04 kernels i try.  before = a few weeks ago with the same kernels i'm trying now.   probably my fault, since i've tried to compile my  own kernel and failed on something related to the nvidia driver.  not sure if it has anything to do with it, but i suspect so...
<JackWinter> smb_tp: could be but happens with .21 .16 etc....
<smb_tp> Ok, in that case it isn't what I had in mind.
<JackWinter> vbox people tell me that the vbox module should compile with settings from the linux-headers of my kernel, so i don't understand why it doesn't
<smb_tp> Right IIRC those builds take the config from /lib/modules/$(uname -r)/build. So it should be right if nothing changed that contents
<JackWinter> if it helps ls -l /usr/src: http://pastebin.com/d3e120806
<smb_tp> looks sensible
<JackWinter> and ls -l /lib/modules/2.6.24-16-generic: http://pastebin.com/d1683e7b6
<JackWinter> could it not be that some global default has changed for my build enviroment, and that the Makefile doesn't take it into account so tries to build the module with stack checking while the kernel doesn't have it ?
<smb_tp> what does "grep STACK /lib/modules/2.6.24-23-generic/build/.config" print for you
<JackWinter> smb_tp: http://pastebin.com/d363cc5a7
<smb_tp> ok, same here
<JackWinter> and "grep STACK /lib/modules/2.6.24-16-generic/build/.config" shows the same
<smb_tp> JackWinter, A compile for 1.5.6 vboxdrv works here. Maybe you want to pastebin a build log to compare
<JackWinter> smb_tp: here is the build log: http://pastebin.com/d501a6128, but think that works fine, it's when it's trying to load it that there is a problem
<JackWinter> my guess is that something went wrong when i tried to build a kernel.  i managed to build a couple of kernels based on the config of my existing kernel.  they failed to install from package though due to some conflict with the nvidia driver.  i had some problems until i manually removed the half installed kernels, but think i've cleaned the system out...
<smb_tp> JackWinter, I had hoped the log would be a bit more verbose. To see which options are taken.
<JackWinter> no it doesn't really show very much at all :(
<JackWinter> my guess is that for some reasons the modules build with the wrong options and thus can't load.  i think i have the same problem with the nvida closed driver, the module builds but can't load.  prefer to trouble shoot with the vbox module though :)
<smb_tp> As it saves a little time, yes. :)
<JackWinter> smb_tp: mind you that i have no clue what i'm doing, but i copied the vbox module source from /var/lib/dkms/vboxdriver/2.1.4 to my home and tried to run a make from the build directory, this is the output: http://pastebin.com/m30123aa1
<smb_tp> JackWinter, Well, good clueless thinking... ;-)
<JackWinter> smb_tp: in any case the beginning of the output.  i have no clue as to what i'm expecting, but it doesn't look like all is in order ?
<smb_tp> It looks strange, some things might be testing some environment. Give me a sec
<JackWinter> here is ls -l /usr/local: http://pastebin.com/d7d6df7c2  include is indeed not a dierectory and the date is recent ?  and no worries about when, i am happy for all help i can get :)
<JackWinter> on another install i have /usr/local/include is indeed a driectory, so this must be at least one thing borked with my system
<smb_tp> It is an empty directory on my system
<smb_tp> So at least this being a file is quite strange
<JackWinter> looks to be emtpy on my 8.10 system too.  do you think i can just delete it and then recreate it with the right owner and access rights ?
<smb_tp> May be look into it (or at least save it as evidence) to know what probably has written there
<smb_tp> It might be worth a try to replace it by an empty dir again, but who knows what else got changed
<JackWinter> hehe, looks like cpp code :)
<JackWinter> must have been written when i tried to install a program from source...:(
<smb_tp> JackWinter, Things like this could happen more likely if /usr/local/include was not there before. 
<JackWinter> smb_tp: think it was always there...  in any case i removed it, recreated the dir and recompiled the kernel module.  it installed without a problem.  hopefully that was the extent of the problem, because i don't really feel like reinstalling the whole system...
<smb_tp> Maybe it got its options wrong since the build system got confused. With the older vboxdrv module on my system here, I saw that -fno-stack-protector was used. This seems to be the case for you again.
<JackWinter> am gonna remove the offending source, because that build didn't complete anyway and i don't really need it.  hopefully nvidia will also build again...  Many thanks for your help!
<smb_tp> JackWinter, Np, I was just pointing a bit :)
<JackWinter> :))
<Laney> Quick instant-triage on this: https://s3.amazonaws.com/pikchurimages/pic_mba_l.jpg - kernel issue?
<Laney> (just happened to my PC on Jaunty upgrade)
<mjg59> Either your hard drive died or it's a kernel issue
<mjg59> The latter is probably more likely
<Laney> hdd dying is a coincidence too far
<Laney> I will file a bug soon then
<mdz> I noticed the following run-on message in dmesg:
<mdz> [   20.835571] psmouse serio1: ID: 10 00 64<6>elantech.c: unexpected magic knock result 0x5a, 0x03, 0xc8.
<mdz> I think there was supposed to be a newline in there somewhere
<JackWinter> probably off topic but since i'm already here and you guys might know.  if i install the closed nvidia 180.29 drivers on my kubuntu 8.04 system, kernel 2.6.24, will dkms still work ?
<apw> mdz, what did the next line look like?
<apw> its possible they really are interlieved one from the interrupt handler
<mdz> apw: 
<mdz> [   20.835571] psmouse serio1: ID: 10 00 64<6>elantech.c: unexpected magic knock result 0x5a, 0x03, 0xc8.
<mdz> [   21.197163] Adding 1023976k swap on /dev/sdb6.  Priority:-1 extents:1 across:1023976k
<apw> mdz ta
<apw> mdz indeed that looks like a missing newline
<apw> mdz can you confirm you have an alps touchpad: cat /sys/devices/platform/i8042/serio1/protocol
<mdz> apw: no I do not, this is a desktop
<apw> hmmmm
<mdz> mizar:[~] cat /sys/devices/platform/i8042/serio1/protocol
<mdz> ImPS/2
<apw> oddness
<apw> ahh i see, this gets dropped out whether the alps driver attaches or not
<apw> mdz i'll get that patched and push it upstream
<mdz> apw: thanks
<_ruben> hmm .. for some reason my module-assistant built kmod wont load .. earlier versions did work just fine .. now i get: scst: disagrees about version of symbol struct_module
<_ruben> the headers i built against match the running system's kernel
<maxb> "Latest kernel upload:" in the topic really really isn't
<_ruben> bah .. this is annoying .. cant figure out what broke it
<_ruben> hmm .. apparently using m-a on a 2.6.27-9-server system with 2.6.27-11-server headers installed, doesnt create proper kmods for 2.6.27-11-server systems
<_ruben> (did use the -l option, and the package name looked ok)
<maco> apw: hello?
<apw> maco, hi
<maco> apw: pgraner says you'd be the person to ask about figuring out how to add support for 2 hotkeys that are on my laptop but don't show up in asus_laptop.c
<maco> apw: i disassembled the dsdt with iasl, but i don't really understand it
<apw> i can have a look at the problem, is there a bug for it?
<maco> bug 268429 and bug 327949 ...the web browser key and the video output switch key respectively.
<ubot3> Malone bug 268429 in linux "asus-laptop module has incomplete support for hotkeys on Asus" [Undecided,New] https://launchpad.net/bugs/268429
<ubot3> Malone bug 327949 in linux "Asus Z37E no keypress registered for video output switching key" [Low,New] https://launchpad.net/bugs/327949
<maco> hrm i should probably attach the dsdt to the bugs
<apw> yeah do that
<maco> ok its attached to 32749
<maco> er 327949
<apw> maco, ok will have a look at the pair, and see what i can do, whats your normal around hours UTC?
<maco> i looked about half way through it trying to make sense of it. i saw CPU and LED sections, and dtchen said the hotkeys won't be named, they'll likely be hex values....but that's all i got
<maco> um...16 UTC to 7 UTC, i guess
<apw> ok cool.  will see what i can figure out, likely talk to you your am
<maco> ok. do you mind explaining it after you have a look? i'd like to learn
<apw> sure, we can learn together!
<maco> hahaha
<maco> the most sense i can make of it is that it looks rather similar to verilog
<maco> Keybuk: that email you just sent out about stop_machine_create(), you mentioned a 1/2 second delay.  is that 1/2 second total for 40 modules, or is that 1/2 second *per* module?
<Keybuk> total for 40 modules
<maco> ok
<maco> was just wondering :)
#ubuntu-kernel 2009-02-24
<gourgi> hi, i apologise for discussing this here. i have a kernel warning about my BIOS and tells me to report it to "the Linux ACPI maintainers". who are they ? 
<gourgi> here is the warning http://pastebin.com/m1895eaa
<apw> gougi, ... /me hits complete uslessly
<Kamping_Kaiser> Hi all. will bugs filed be announced here?
<Kamping_Kaiser> I just filed a bug, and i'm hoping for feedback (specifically, if its got enough information to be useful)
<IntuitiveNipple> No, they're announced on the kernel-bugs mailing list
 * Ng wonders if anyone's come across cryptsetup in jaunty not doing its magic during initramfs (I have a root-on-lvm-on-crypto made with intrepid's alternate installer's default option for that). It times out and gives me a busybox shell, I run "cryptsetup luksOpen /dev/sda5 kodachi" enter the passphrase, exit the shell and it boots
<Kamping_Kaiser> hm, ok. could someone look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/333766/ and tell me if anything extra is needed?
<ubot3> Malone bug 333766 in linux "linux packages in hardy-security FTBFS in a ppa" [Undecided,New] 
<smb_tp> Kamping_Kaiser, I have a look at it.
<smb_tp> Looks like ABI file problems. Let me verify this. Can take a bit because I have to step out for a little
<Kamping_Kaiser> smb_tp, thanks for checking. take your time, its been broken for a few months, i can wait a while longer :)
<Kano> hi, why are clockmod options built in?
<Kano> nforc2 does not allow standard powersave modes, and the module for changeing the fsb is nothing i would use by default. but now it is even builtin!
<Kano> who had that idea? now everbody even gets an error because of no nforce2 chipset
<Kamping_Kaiser> smb_tp, i'm off to bed. ping me if you need any more info from me, and i'll try and reply when i wake up.
<smb_tp> Kamping_Kaiser, Sure
<Kamping_Kaiser> thanks.
<dholbach> hey my kernel friends!
<dholbach> is http://paste.ubuntu.com/122406 anything I should worry about?
<dholbach> I have no idea what happened there, just booted up the system and everything worked as I expected
<dholbach> is this "if it's no big deal for you, it's no big deal for us"? :)
<smb_tp> dholbach, Not sure how much this is to worry but it wants to tell us there is something outside its defined resource range. Is there a message like "resource map sanity check conflict:" before?
<dholbach> smb_tp: yep
<smb_tp> This should also have some address numbers
<dholbach> I can make the whole dmesg output public if you want
<dholbach> hang on
<dholbach> smb_tp: http://paste.ubuntu.com/122417
<smb_tp> dholbach, Looks like the driver tries to map the BIOS into memory but (probably because the BIOS flagged that range as reverved) it fails. When it fails to request the resource it just goes on and gets the warning from the sanity check. This does sound a bit dangerous, but then the whole driver is flagged with "use with care".
<dholbach> ah ok
<smb_tp> The mapping itself seems to work. What is visible is just the failure to reserve that memory range and then the sanity check when mapping that range into memory (because there is no resource reserved for it)
<dholbach> smb_tp: if you have no concerns about it, I'm happy too :)
<dholbach> just thought I'd let you know
<smb_tp> dholbach, It probably would be better if that bios is not mapped into memory in general. But overall it looks like it won'T explode the next second
<dholbach> smb_tp: I can confirm, the machine is not burning yet
<dholbach> thanks a bunch
<maco> apw: hello?
#ubuntu-kernel 2009-02-25
<Keybuk> quest procwatch% sudo ./forkwatch
<Keybuk> 1 -> 19414
<Keybuk> 1 -> 19415
<Keybuk> 1 -> 19416
<Keybuk> 1 -> 19417
<Keybuk> 1 -> 19418
<Keybuk> 1 -> 19419
<Keybuk> ...
<Keybuk> why does the kernel keep spawning things
<Keybuk> (at least I assume it's the kernel and not init :p)
<Keybuk> hmm, something to do with threads
<Keybuk> 1/1 -> 20348/6513
<Keybuk> 	'evolution --component=mail '
<Keybuk> 1/1 -> 20349/6506
<Keybuk> 	'/usr/lib/firefox-3.0.6/firefox '
<Keybuk> ah
<Keybuk> I'm being stupid
<Keybuk> if you clone() to make a new thread, the new thread shares the same parent as the old one
<Keybuk> firefox and evo's parents are init
<Keybuk> so a new thread will also have a parent as init
<mjg59> Keybuk: Oops
<Keybuk> mjg59: don't laugh :p
<mjg59> Keybuk: I spent half of today trying to debug something before realising that I'd stubbed out the functionality last month
<Keybuk> d'oh
<Laibsch> I'm sure DKMS is nice and all, but I wonder if we're not going to see Ubuntu-supplied kernel modules as a separate package anytime soon (compiled with the help of dkms, I suppose)
<Laibsch> I hope this is on-topic here, if not suggest a better channel, please
<soren> Laibsch: I don't think I understand what you're saying.
<Laibsch> Alright, I'll retry
<Laibsch> virtualbox has a module.  that module used to ship in a separate package, but was available for ubuntu supplied kernels
<Laibsch> That is not the case anymore.  I have to install dmks, linux-headers, lots of dev-packages and lots of other stuff pulled in by virtualbox-ose-source these days to compile the module myself
<soren> Yes.
<Laibsch> I wonder if ubuntu couldn't handle packaging that module (probably with the help of dkms) so everybody (including me) doesn't have to do that
<Laibsch> Right now, I don't see any obvious reason it couldn't be done
<soren> On the other hand, you'll never more upgrade your kernel and suddenly have virtualbox not working because noone bothered to upload a new virtualbox-modules-2.6.xx-newabi-foobar package and go through the whole process of getting it accepted, through the various queues and stuff.
<Laibsch> I'm here to understand the situation
<soren> ...which is exactly the problem dkms solves.
<Laibsch> OK
<Laibsch> But it still is inconvenient
<Laibsch> I'm wondering if a PPA might help?
<soren> How is it inconvenient?
<soren> It's all automatic.
<Laibsch> But I don't think dkms works in a PPA environment
<soren> What do you mean+
<soren> ?
<soren> dkms runs on the target system, not on the buildd's.
<IntuitiveNipple> I put DMS packages in my PPA 
<Laibsch> Yes, that is what I was basically saying
<IntuitiveNipple> s/DMS/DKMS/
<Laibsch> soren: I think the previous situation was preferable, at least speaking from my POV
<soren> IntuitiveNipple: You mean packages that actually run dkms on the buildd's or just a package that uses dkms when it's installed in the final system?
<soren> Laibsch: Why?
<soren> Laibsch: How is it inconvenient? It's /automatic/.
<IntuitiveNipple> soren: Just regular DKMS packages... built on the target client
<soren> IntuitiveNipple: Right, there's no reason that wouldn't work. They're regular packages.
<IntuitiveNipple> I wrote a tutorial on how to do the packaging, if it would help
<soren> IntuitiveNipple: We're not discussing how to create packages that use dkms.
<IntuitiveNipple> ahh, sorry.
<Laibsch> soren: i don't like all the packages pulled in.  You may have a fat HD, unlimited bandwidth and whatnot, I may not.  I just see the sources and all the associated things on my system as cruft.  If I wanted LFS, I'd go gentoo.
<Laibsch> It's basically the same reason I use Ubuntu over Gentoo.  In that sense, I'm a binary-type-of-guy
<Laibsch> I hope that makes sense
<soren> dkms solves a very real problem:
<Laibsch> I'm not disputing that
<soren> We have lots of kernel modules that are built outside the kernel, but needs to be in sync with the kernel.
<soren> During development, this is not all that bad, but if, after release, a security problem comes up that requires us to bump the ABI, there are a few options:
<soren> a) Don't install the updated kernel until someone else has taken care of updating *all* the other packages.
<soren> b) Install the new kernel and lose the functionality provided by the other packages.
<soren> Neither is very useful.
<Laibsch> Understood, if the kernel team itself can't handle *all* out-of-source kernel modules, fine
<soren> They can't, and shouldn't.
<soren> What if you have an extra module from a PPA?
<Laibsch> I'm wondering if there isn't a way to make dkms one more step
<Laibsch> source -> binary -> package
<Laibsch> dkms stops at dkms AFAIK
<soren> Again: How about the packages you get from a PPA?
<Laibsch> I want package ;-D
<Laibsch> soren: what do you mean?  what about them?
<soren> Laibsch: They will obviously not be rebuilt by the kernel team or anything else automatic. Only your system knows that the package even exists.
<soren> ...so you end up having to choose be between the two options I mentioned a few minutes ago.
<Laibsch> I'm not following you
<Laibsch> Let's concentrate on virtualbox for a minute
<Laibsch> so things are clearer (at least for me)
<soren> Ok.
<soren> So, say you wanted a more up-to-date version of virtualbox than is in the archive, and you go and install it from a PPA.
<Laibsch> That is also the case I'm most interested in, I don't use proprietary drivers, for example
<Laibsch> no, that is not what this is about
<soren> Says who?
<soren> It's my example :)
<Laibsch> Ubuntu vbox and Ubuntu kernel
<soren> Ok, then.
<Laibsch> Let's not make things complicated before I understand the basics fully
<soren> Ok.
<Laibsch> Situation before dkms: ubuntu provides package
<soren> So, say you have linux-image-2.6.27-22-generic installed and virtualbox-modules-2.6.27-22-generic as well.
<soren> Both from the archive.
<Laibsch> after dkms: ubuntu provides source and automatic system for user to compile binary
<soren> Note: Virtualbox is in universe.
<soren> A security problem comes up that forces us to update the kernel in a way that breaks the ABI.
<soren> So, to be safe from whatever was the security problem, you need linux-image-2.6.27-23-generic.
<Laibsch> OK
<soren> ...but since it's not the kernel team that maintains virtualbox-modules, it might take hours, days, or weeks before there's a virtualbox-modules-2.6.27-23-generic.
<Laibsch> virtualbox-modules-2.6.27-22-generic isn't currently available, right? It's just to illustrate your point, do I understand correctly?
<soren> Right, these are made up version numbers.
<Laibsch> Yes, and that is where my PPA suggestion came in
<soren> Oh, no.
<Laibsch> Why not?
<soren> If I don't get to talk about PPA's, neither do you :)
<Laibsch> I for one would prefer that over the current solution
<Laibsch> Be serious now, will you ;-)
<soren> So, during the time between linux-image-2.6.27-23-generic comes out and virtualbox-modules-2.6.27-23-generic comes out, you can choose between being safe or having virtualbox.
<Laibsch> Yes
<Laibsch> I'd be OK with that
<soren> Right, because virtualbox is not a critical function to you, or you don't care about security.
<Laibsch> Given that the recompilation is automatic
<soren> Eh?
 * amitk thinks Laibsch is misunderstanding how PPAs work
<Laibsch> Given that the recompilation is automatic it shouldn't take a dedicated team too long to update their modules packaegs
<Laibsch> amitk: I think I do
<soren> But it's not automatic!
<Laibsch> I'm not a DKMS expert, though
<soren> That's why we added dkms to /make/ it automatic.
<Laibsch> yes, dkms is a good thing -> see my first sentence in this channel
<amitk> Laibsch: someone has to upload a _new_ version of vbox to the PPA to make a new version available to you
<amitk> it is not automatic, it brings us back to the original problem
<Laibsch> What I don't think is so great is that currently things stop at the very first step in "source -> binary -> package"
<soren> Laibsch: Your first sentence in this channel was the one I completely didn't understand. At all.
<Laibsch> I'm wondering if it isn't possible to officially or inofficially continue to ship modules (can be a subset of those depending on dkms currently)
<amitk> soren: Laibsch doesn't like things being compiled on his machine. He wants it to be available _automatically_ through PPAs
<Laibsch> soren: vbox has to be rebuilt?  I think that isn't ture
<Laibsch> true
<Laibsch> It's the module that needs to be rebuilt
<Laibsch> amitk: yes
<Laibsch> thanks for clarifying
<soren> Laibsch: Of course. I didn't mean to discuss userspace at all.
<Laibsch> PPAs, or some other official or inofficial channel
<soren> Laibsch: Well, you're free to set something like that up.
<Laibsch> I'm willing to put some work into that
<Laibsch> But I need help
<Laibsch> help and guidance with what dkms does and how it works
<soren> Then you need to find someone who /can/ and who also thinks it's useful. I'm only in one of those categories :)
<amitk> soren: Laibsch: something like this - a new kernel upload (abi bumper) should automatically trigger a rebuild of all dkms packages in the archive and make their binary .debs available.
<soren> amitk: That seems to be the stated goal.
<Laibsch> amitk: Yes, that is what I'm looking for.  I think currently, it isn't done, or is it?
<amitk> Laibsch: currently it can't be done
<soren> It all means that the time from known vulnerability to patched system is longer.
<Laibsch> amitk: because dkms doesn't do it and there is nothing else, right?
<Laibsch> I wonder how complicated it would be to either extend dkms to also churn out packages or wrap something around dkms like is done with pbuilder and friends
<amitk> dependencies handling in external kernel modules, automatic trigger support, package naming issues,
<soren> Laibsch: Are you familiar with module-assistant?
<amitk> and several other issues wil have to be solved. You should probably check on #ubuntu-devel for experts on this sort of thing.
<soren> Laibsch: It's how some packages used to do this. It builds packages that you can install, but it can't be run automatically for various reasons.
<Laibsch> soren: I used to run m-a a few times in the past
<Laibsch> I wouldn't call myself familiar with it
<Laibsch> BTW, this isn't really automatic
<Laibsch> Error! Could not locate vboxnetflt.ko for module vboxnetflt in the DKMS tree.
<Laibsch> You must run a dkms build for kernel 2.6.28-2-386 (i686) first.
<Laibsch> Whatever that means, I hope google will tell me
<apw> jbuncher, cool.  this a kernel issue, so we might as well have it here, #u-bugs is not really the right venue
 * apw goes look at the 2.6.24.4 build logs
<apw> jbuncher, could you confirm the /proc/version string from the .4 version
<jbuncher> apw:  I just rebooted, hang on
<jbuncher> apw:  "Linux version 2.6.24-02062404-generic (root@zinc) etc etc"
<jbuncher> apw:  I have not been installing the headers, btw.
<apw> jbuncher, yeah no worries if you'd needed them you would know by now
<apw> seems that iwl has moved to l-u-m, will try and work out what to do to test this next
<jbuncher> apw:  l-u-m = linux-ubuntu-modules?
<apw> yeah
<apw> of course there isn't one of those for a mainline kernel
<apw> so ... we need anything 'moved' there turned on in mainliine builds
<apw> not somethign thats trivial to detect automagically
<apw> a royal pain
<jbuncher> should I just enable "Intel Wireless WiFi Link Drivers" in the kernel config?
<jbuncher> or would that not work (e.g., if the source ot make those modules has been physically removed from the source debs you posted)
<apw> they are in there.
<apw> i was jsut going to try a rebuild of the .4 with that enabled
<apw> need to figure out how to do this in a safe manner
<jbuncher> apw:  what would the "danger" be?
<apw> the problem is how do i reenable it in such a way that each time i build a new .24.N build
<apw> it will happen right and automatically without intervention
<jbuncher> ok
<apw> give me a couple of mins to think on it
<jbuncher> sure thing
<apw> jbuncher, ok i think i have something workable.  am rebuilding the .24.4 now, will let you know when its done so you can test before i rebuild and others
<jbuncher> ok
<apw> sadly it will take somewhat over an hour so no holding of breath
<jbuncher> apw:  you don't happen to know of a tool that scans your hardware and then auto-configs a kernel, so you don't have to build modules for stuff you don't have/use, do you?
<apw> jbuncher, nope, that would be nice.  i bought some bigger build engines to get round that issue
<jbuncher> nice
<IntuitiveNipple> I saw something that does exactly that last week... let me see if I can remember what it was
<apw> easier than waiting for godot
<apw> IntuitiveNipple, intresting
<apw> just when i've stopped being allowed to make small kernels :(
<IntuitiveNipple> Trouble is, when you're visiting tons of search-engine hits a day, it's hard to remember when or where :)
<apw> Keybuk, the work you are doing with netlink, does that make the work on pselect et al for arm less urgent?
<apw> jbuncher, ok the 2.6.24.4 is rebuilt if you could test that sometime
<jbuncher> apw: alright, I need to head to work and get some lunch, but I should be able to get to it this afternoon.  Is it on the same page as before?
<apw> jbuncher, yep replaced the originals with some with iwl stuff turned on i hope
<apw> if you could report back in the bug too that would help me keep track
<jbuncher> apw:  sure thing, thanks again for all your work.
<apw> no problem, be nice to get that one nailed
<mgolisch> anyone here?
<mgolisch> which dump facilities does ubuntu provide?
<Keybuk> apw: no, it has nothing to do with udev
<jbuncher> apw:  Success on both counts.  The .4 recognized my wireless card, as well as being able to connect to the wireless.  I'm posting in the bug thread now
<apw> jbuncher, i will re-build the remainder and let you know when they are done
<mgolisch> crash dump facilities in ubuntu kernels?
<mgolisch> anyone?
<apw> i think crash dumping is a jaunty goal
<mgolisch> i wonder why its not there yet
<mgolisch> for example ubuntu ships the crash tool for debuging crashdumps since ages
<mgolisch> i allways wondered why there is no crashdump stuff
<mgolisch> i mean srsrrly they try to do server stuff, i wouldnt want a server without the ability to get dumps of kernelpanics
<mgolisch> enough ranting :) ill wait for the next release then
<mgolisch> :)
<apw> i would't take my word for it, i know some stuff is going on in that space for jaunty
<apw> it may be workable if you have the recipe on server
<apw> mgolisch, have you asked on #ubuntu-server ?  they would have the definative answeer
<mgolisch> ill try that
#ubuntu-kernel 2009-02-26
<jbuncher> apw:  I won't be able to test those kernels today, but I should get a chance to tomorrow.
<apw> they'll take some hours yet anyhow ... will reply on the bug
<jbuncher> sounds good
<pARAd0X85> where is the best place to discover the Linux Input Architecture ?
<smb_tp> Ok, so maybe we look at the same stuff with https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/286672 as for
<ubot3> Malone bug 286672 in linux "WARNING: at /build/buildd/linux-2.6.27/kernel/power/main.c:176 suspend_test_finish+0x74/0x80()" [Medium,In progress] 
<smb_tp> bug 318978
<ubot3> Malone bug 318978 in dell "Hard drive in Studio XPS 13 and 16 cause a 17-18s resume time" [High,Fix released] https://launchpad.net/bugs/318978
<rtg> smb_tp: the driver was violating the spec in that it was not waiting the minimum amount of time for the link to reestablish
<smb_tp> Ok, what happened when it did not wait long enough? It went into a reset?
<rtg> smb_tp: it would eventually resover, but not until after the resume time had been exceeded
<rtg> recover, even
<smb_tp> Hm, from the logs in the other bug report it looks like the link has been reset (could be the recovers) and it requires quite some time until the disk is ready
<rtg> smb_tp: exactly, thats why its disk specific
<smb_tp> Then the best thing to check is whether that patch has been backported to intrepid, but I too don't think so.
<rtg> smb_tp: its a real simple change
<apw> IntuitiveNipple, on bug #286673 you suggest that there is a relationship with firmware loading, i don't see any firmware loading in the kernel logs there
<ubot3> Malone bug 286673 in flashplugin-nonfree "flash plugin 10 is extremely slow !" [Undecided,Confirmed] https://launchpad.net/bugs/286673
<smb_tp> The other thing is, should kerneloops react on a WARN like it does? It seems to act as if a kernel crash had occured. 
<apw> all i see is a machine loading slowly, cause its disk took a little while to come back
<IntuitiveNipple> apw: Relationship *could* have been related to the firmware issue. My investigation showed it isn't on that bug
<apw> rtg, smb, one thing i would note here, is that its ok for sata to take up to 5 seconds, and yet the overall resume warning time is 5 seconds
<IntuitiveNipple> apw: It was in the context of my sweeping through the suspend/resume bugs trying to identify which might be caused by the firmware load issue
<apw> i think in tandem we should up the rather arbitrary resume timeout by the delta there
<apw> IntuitiveNipple, makes sense then
<rtg> apw: correct, but in general most disks re-synv in something less then 2 seconds, whereas the original timeout was only 1 second.
<apw> smb_tp, most WARN_ON's are something that needs reporting, that one really isn't
<apw> rtg, yes, but the one in the bug smb quotes first the disk take of the order of 2s to recover
<apw> and in that machine that pushes recovery to 8s total, there is nothing major there, other than the disk at 2s to my eyey
<smb_tp> I guess it is only the "your kernel crashed" string that apparently is somewhere in the popup window when it asks for submitting a report that makes users jump
<apw> if its going to be that close to a pretty idea time, its too agressive as a WARN_ON if you have kerneloops installed
<apw> my feeling is that that is a bit low with the state of the art, its an ideal not a hard deadline
<apw> i wonder if perhaps there should be a 'look_i_am_slow_at_resuming=yes' kernel command line to shut it up
<apw> else people will report an oops for every resume
<smb_tp> The reports would require something like a 5s delay (that is when the atalib prints be patient)
<smb_tp> But that probably is not needed if the other timeout is larger
<smb_tp> IntuitiveNipple, I think we should try the patch from 318978 with some Intrepid  test kernels. If that prevents the recovery this should help there as well.
<IntuitiveNipple> smb_tp: Have I got confused? I *thought* one of the reporters was using 2.6.28-6 or -7 ?
 * smb_tp looks again
<IntuitiveNipple> smb_tp: You're correct! I've looked at som many kern.log's recently I don't know where I am :)
<IntuitiveNipple> s/som/so/
<smb_tp> No, there seems to be one, thoug hard to say which extactlly kernel level
<IntuitiveNipple> in which case I agree, if Tim's patch will help it'll calm some nerves
<smb_tp> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/286672/comments/16
<ubot3> Malone bug 286672 in linux "WARNING: at /build/buildd/linux-2.6.27/kernel/power/main.c:176 suspend_test_finish+0x74/0x80()" [Medium,In progress] 
<IntuitiveNipple> oh, well spotted!
<smb_tp> Hm , must be 2.6.28-8-24
<smb_tp> Lets check when the other patch got in
<IntuitiveNipple> It shows 2.6.28-8-generic #24-Ubuntu
<smb_tp> rtg, patch went in 2.6.28-5.12, so it should be in there
<rtg> smb_tp: in Jaunty for sure. I thought you were talking about Intrepid?
<smb_tp> Most of the others yes. One single WARN for 28 but funnily when he supplied the whole dmesg it was 2.6.27 again...
<rtg> hmm, some crack involved?
<IntuitiveNipple> Someone testing kernels to fix it maybe?
<IntuitiveNipple> I'll ask him to clarify
<smb_tp> Sounds a bit like it. Well the WARN jsut says takes to long on resume, we don't know why for 2.6.28, so I would really go with that patch and see
<smb_tp> IntuitiveNipple, I could provide a test kernel to try and link it to the bug report
<IntuitiveNipple> That'd be useful :) I'm just adding a comment now
 * smb_tp goes to cook a kernel
<IntuitiveNipple> smb_tp: Can you throw in a printk() so we know which code-path ata_wait_ready() takes when -ENODEV applies? I don't think we can figure it out any other way. It would help determine if the ATA_TMOUT_FF_WAIT is used to cause ready to be reset artificially
<smb_tp> IntuitiveNipple, should be possible. hopefully after the other patch the wait won't occur
<IntuitiveNipple> And if it does, we get to know which code-path to poke
<IntuitiveNipple> smb_tp: Looking at it, it might be best to use a count of how many times 'ready' is reset in both paths and print the summary at function-exit else printing to log every~ 50ms might add a delay of its own :)
<smb_tp> Heh, yeah :)
<philsf> ogasawara: ping?
<ogasawara> philsf: what's up
<Martyn> Had anyone had experience configuring and using gfs or OCFS2 on ubuntu-server?
<philsf> ogasawara: I was told to contact you about a bug, could you take a look at a kernel backtrace for me please?
<ogasawara> philsf: sure, which bug #
<philsf> http://launchpadlibrarian.net/21975410/dmesg.log from bug #325238
<ubot3> Malone bug 325238 in linux "BUG: unable to handle kernel paging request" [Undecided,New] https://launchpad.net/bugs/325238
<philsf> I think I inputted everything the wiki asks for
<Martyn> philsf : Considering I'm also currently working in the kernel paging subsystem .. I'll take a quick gander too
<philsf> Martyn: cool, thanks!
<philsf> it looks like it should be a nvidia blob thing, but since it also happens with the LiveCD, it also should not be. kind of a paradox for the lay me
<ogasawara> philsf: you mention you're able to reproduce with a LiveCD, have you tried the latest Jaunty Alpha?  has a 2.6.28 based kernel.
<ogasawara> philsf: I'd just be curious if it still oopses
<philsf> ogasawara: I haven't. I only tried hardy CD and DVD
<philsf> the strange thing is that it worked perfectly for almost a year
<ogasawara> philsf: http://cdimage.ubuntu.com/releases/jaunty/
<ogasawara> philsf: if you wouldn't mind testing that would be great - also Alpha 5 should drop today
<philsf> ok, I'l try it in a couple of hours
<ogasawara> philsf: thanks. I'll subscribe to the bug report, so if you can post a comment with your test results there I'll see it
<Martyn> ogasawara : The OOPS recorded in the log is odd.
<Martyn> ogasawara : It was in the middle of trying an execve
<Martyn> Which would be what you'd expect if it .. say .. couldn't read the file from the page_cache after it expected to load it from disk.
<Martyn> However, the whole chain of Oops'es seems to start early on, during the initialization of the intel 915...
<Martyn> [   51.475653] EIP: [<f990f9ee>] intel_i915_configure+0xce/0x100 [intel_agp] SS:ESP 0068:f741bde4
<Martyn>   (agp bus)
<Martyn> philsf : When you remove the nVidia card, everything boots correctly, right?
<kristian_> oooo. is this the kernel?
<maco> kristian_: yes, would you like some popcorn?
<kristian_> thanks, but no thanks!
<kristian_> i fount the kernel! :-D
<kristian_> found*
<philsf> Martyn: yes, when I remove the nvidia card, everything boots ok, afaict
<Martyn> You have a conflict, in hardware then.
<Martyn> i know you say it's been working before, which leads me to think there might be a hardware change somewhere.   Specifically, I'm wondering if the internal intel 915 based video is trying to map the same resources as the nVidia card now.  Not something that would _usually_ be a bios setting.
<Martyn> More a jumper.
<Martyn> but sometimes it can be something the manufacturer lets you set in the BIOS of the machine (disable internal video card) etc...
<IntuitiveNipple> It could be an MTRR issue... I was suspicious of the VESA framebuffer
<Martyn> Why?
<Martyn> "intuitive nipple?"  I have to know the origin
<IntuitiveNipple> depending on the CPU, there may be insufficient MTRRs 
<IntuitiveNipple> philsf: Did the system work ok previously with the nvidia adapter ?
<Martyn> True, but phil said that there were no major changes, and it was working in the past...
<Martyn> so mtrr exhaustion seems unlikely
<IntuitiveNipple> Unexpected BIOS reset might influence that. I've seen many systems cause unexpected issues because of that.
<Martyn> Ah, good point.
<jbuncher> apw:  I'm posting in the bug right now, but I was able to test all 3 of those kernels, and they all worked.  The 24-23 kernel still won't connect though.  Do you know of any other changes would there be between .24-22 and .24-23 that would have caused this?
<IntuitiveNipple> If you look at the vm addresses of the oops they are very close to pkmap. I wondered if something was invading pkmap
<Martyn> Although would linux early initialization really pay attention to what the BIOS settings are vis-a-vie MTRR's?
<IntuitiveNipple> The MTRRs are being configured to take account of holes and so forth by things like agpgart and so on. Also, the vesa fb driver can also allocate them.
<philsf> IntuitiveNipple: yes, it worked for almost a year, since I bought it
<IntuitiveNipple> philsf: OK, I noticed you said that it started 'shortly after' after adding the additional hard disk
<IntuitiveNipple> philsf: how 'short' is short?
<philsf> IntuitiveNipple: about a week
<IntuitiveNipple> philsf: And the nvidia adapter was in the system at that time, yes?
<philsf> IntuitiveNipple: yes
<IntuitiveNipple> philsf: but when things started going wrong, you discovered that removing it solved the problems?
<philsf> correct
<IntuitiveNipple> OK. Did you see my suggestions I added to the bug report?
<philsf> I just read them. I'll try them in order now
<philsf> can I skip some steps, since I know the HDs work without the nvidia?
<philsf> and do you need all dmesg.logs for each step?
<IntuitiveNipple> philsf: I would place a mild bet on the BIOS step right now. Not just resetting it, but looking for alternate configuration options that affect the internal/external video chipsets and memory mapping
<philsf> so, should reset to factory defaults suffice?
<IntuitiveNipple> No, don't need logs. The idea is to try and find some point at which the system is stable.
<IntuitiveNipple> You've confirmed two things: 1) removing the nvidia adapter solves the issue and 2) it used to work with it in
<apw> jbuncher, thnkas for the test, will think on it
<IntuitiveNipple> philsf: So I'd be looking in BIOS for any and all options that affect the video chipsets and memory-mapping (AGP window, for example)
<jbuncher> apw:  no problem, glad to help.
<philsf> IntuitiveNipple: ok, I just booted the ahrdy liveDVD sucessfully, with everyting except for the nvidia adapter. Since I have no idea what a proper setting would be for AGP window, nor anything related to that, I never changed it (willingly, that is)
<philsf> *hardy
<IntuitiveNipple> philsf: OK. In BIOS did you see any options anywhere that allow the enabling/disabling of the internal graphics chipset ?
<IntuitiveNipple> philsf: Also, what motherboard make/model is it?
<philsf> IntuitiveNipple: it's an intel d945gpt mobo
<philsf> IntuitiveNipple: I honestly didn't even look for such an option, will do now
<IntuitiveNipple> philsf: there usually is something buried away. First thing I do with any system is go through every BIOS menu and option so I will remember in future when something like this comes up
 * IntuitiveNipple has to leave now. Dinner.
<philsf> IntuitiveNipple: me too, with the exception of the arcane PCI settings
<philsf> IntuitiveNipple: thanks for the tips, I'll update the bug with any news from the tests
<IntuitiveNipple> philsf: Those are the important ones... sometimes something important is buried 3 menus deep
<IntuitiveNipple> philsf: I'll keep an eye on the bug report
<Martyn> Okay, is there some arcade voodo I have to do in order to get gfs working in Intrepid?
<Martyn> Because right now, the gfs kernel module is -not- cooperating
<wmat> Martyn: not cooperating how?
<maco> would "iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks" be the first thing sent to dmesg after modprobing iwlagn?
<rtg> maco:  looks like the module banner to me
<maco> total kernel newbie here..does that make it the first thing that happens when i modprobe it?
<wmat> maco: try removing it, then tailing dmesg while adding it
<rtg> maco: its close enough to the first thing that happens
<maco> ok
<maco> er...oh...should i be looking at dmesg, syslog, or kern.log to find what the iwlagn module was doing during ifup?
<maco> i think it's the modules fault ifup kept failing. unload/reload fixed it
<rtg> maco: dmesg collects all driver log output
<maco> thanks
<rtg> maco: actually, dmesg collects all printk() output.
<philsf> Martyn: doI understand correctly IntuitiveNipple's suggestion was somehow the BIOS got corrupted?
<Martyn> philsf : I also think it's possible your BIOS settings _may_ be involved here.   It might be worth it to go into the BIOS, choose some default settings, and then try again.
<Martyn> wmat : It's not loading.   
<Martyn> wmat : It seems to load, and the kernel reports the symbols as being available, but the gfs tools refuse to work.
<wmat> Martyn: GFS2 tools?  I recall something about everything GFS related moving to GFS2, but I could be wrong.
<philsf> resetting BIOS config to factory defaults apparently solved it for good. I'd like to know why :)
<Martyn> Hmmm .... does tmpfs (or any of the RAMfs drivers) pin the pages into memory to prevent them getting swapped out?
<Martyn> Aka.. is it safe to use a tmpfs volume for swapping?
<Majost> Is there some documentation I can look at to figure out how to create an additional patch set for ubuntu-hardy-lum?
<laga> Majost: what do you want to do?
<Majost> I want to add a couple HDA patches and update the existing hda_codec.patch
<laga> have you found the kernel team wiki yet?
<Majost> Yes, but I haven't found anything specific to the hardy-lum package just yet.
<laga> you get a git checkout, apply your patches, update changelog, rebuild?
<Majost> so for the .patch files, is there a series file or anything which is used to apply a patch order?
<laga>  i believe it's all kept in git. not sure about that anymore
<Majost> okay, I will look there
<Majost> So is there any preferred specific method of patching to be able to push fixes upstream?
<laga> Majost: git commits seem to be the preferred way..
<laga> who is "upstream"? hardy-lum probably is pretty old
<Majost> Well, hopefully Ubuntu.
<laga> ah, that patch flow is documented in the wiki
#ubuntu-kernel 2009-02-27
<d3xter> hey
<d3xter> is anyone here?
<apw> there are lots of people here
<IntuitiveNipple> Of course not - this is a virtual world :)
<heywood> hi all
<heywood> trying to strip down running kernel modules on a netbook (acer aspire one, SSD version) running intrepid, 2.6.27-7-generic. having trouble understanding relationship between sdhci_pci and sdhci.
<heywood> modprobe sdhci_pci says "WARNING: Error inserting sdhci (/lib/modules/.../sdhci.ko): Invalid module format"
<heywood> assume sdhci_pci depends on sdhci, which modprobe tries to install first. but why would sdhci (which is unmodified from stock kernel source) give an invalid format error?
<alex_joni> heywood: did youo check dmesg for further errors?
<alex_joni> usually the invalid format can be generated if you compiled the module with a different compiler as the stock kernel
<heywood> checking now. looks like one of my modules exports the same symbol as sdhci_pci, which may be causing that error. brb...
<d3xter> i've got a problem with =>2.6.27
<d3xter> i've got a bcm4401-b0 lan and bcm4328 wlan
<d3xter> at startup the lan-adapter loads b44 and ssb driver
<d3xter> and after that the propritaery broadcom driver cant use the wlan-chip, because ssb blocks it
<heywood> @alex_joni: weird. i have an sdhci driver i've built myself (call it sdhci_extended) and i'm doing the following, in order, in a shell script (as root): rmmod all_relevant_modules [in order] --> modprobe mmc_core --> insmod sdhci_extended --> modprobe sdhci_pci
<d3xter> so i have to manually unload ssb and b44 and load the wl driver frist
<IntuitiveNipple> d3xter: Have you posted a bug report?
<d3xter> IntuitiveNipple: not yet
<IntuitiveNipple> d3xter: That would be best... generally people don't have time here to follow instant questions
<d3xter> on launchpad?
<IntuitiveNipple> d3xter: Yes, against the "linux" package. The post the bug reference here. It'll also be announced on the kernel-bugs mailing list
<d3xter> ok thx
<heywood> dumb question: in the output of lsmod, is the last column "depends on" or "used by"?
<d3xter> used by
<heywood> thanks
<heywood> @alex_joni: (continuing previous comment...) when i insmod my sdhci_extended, it shows up in lsmod normally, and also in the "referred to by" list for mmc_core. so far so good.
<heywood> now when i do modprobe sdhci_pci, it shows up in the lsmod output by itself, and also in the "referred to by" list for my sdhci_extended. both of those are as expected. but at this point i also get the error about "error inserting sdhci: invalid module format". in dmesg i see that same message, but then a bunch more from sdhci _after_ it -- which suggests sdhci is loading after all.
<heywood> does that sound like a showstopper, or more like a nuisance?
<heywood> (point is, i need to do many many hours of data gathering, have no easy way to check if all is OK during the run, and don't want to find out only at the end that it didn't work or dropped packets or something)
<alex_joni> heywood: try loading your module with insmod
<alex_joni> modprobe will do smart things and pull in dependencies, insmod won't
<heywood> assume i should call insmod with /lib/modules/`uname -r`/... , correct? (i have several kernels on the machine)
<alex_joni> yup
<heywood> ok, will give it a try. thanks!
<d3xter> ok, i've posted a bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/335391
<ubot3> Malone bug 335391 in linux "Broadcom LAN Driver blocks Broadcom WLAN" [Undecided,New] 
<heywood> @alex_joni: ran modprobe -v to check i wasn't missing any other dependencies. confirmed that it only tries to insmod sdhci (which fails), then sdhci_pci. so just doing insmod sdhci_pci should be safe and i won't miss anything else.
<heywood> thanks for your help! :)
<alex_joni> heywood: glad I could help
<heywood> ?
<heywood> can anyone help me understand what the commands in the Linplus section of "tweaks for powersaving" on https://help.ubuntu.com/community/AspireOne do?
<heywood> trying to figure out if i can safely comment them out. don't care about power saving (running from AC adapter), but do care about minimizing system activity (interrupts, etc.) while my code is running.
<bullgard4> [Ubuntu 8.04.2, 2.6.24-23-generic] I have doubled my RAM size from 512 to 1024 MB. Why does Ubuntu not increase the value 512*1024 in /sys/power/image_size accordingly?
<smb_tp> bullgard4, See Documentation/ABI/testing/sysfs-power. It is just a default value not related to your ram size.
<bullgard4> smb_tp: /usr/share/doc/linux-doc-2.6.22/Documentation/ABI/testing/sysfs-power/Rafael J. Wysocki says differently: "The /sys/power/image_size file controls the size of the image created by the suspend-to-disk mechanism."
<smb_tp> And in the other Doc he writes, that the kernel will try to get the image within that size but will continue to hibernate if that fails.
<smb_tp> However, if it turns out to be
<smb_tp>                 impossible, the kernel will try to suspend anyway using the
<smb_tp>                 smallest image possible.  In particular, if "0" is written to
<smb_tp>                 this file, the suspend image will be as small as possible.
<smb_tp>                 Reading from this file will display the current image size
<smb_tp>                 limit, which is set to 500 MB by default.
<bullgard4> So where will I find guidance how to make better use of available RAM size in order to resume or thaw faster?
<heywood> hi all, does anyone know what the most serious consequences are of turning off sysklogd and klogd for runlevel 2? is there anything to worry about beyond not having debug info available via dmesg?
<IntuitiveNipple> heywood: If you're not worried about missing kernel reports I don't see a problem with that
<IntuitiveNipple> apw: ping
<apw> hi
<IntuitiveNipple> Hey. I'm working through all the bugs tags 'resume' right now. There's a fair few that have "High/Medium" but haven't been touched and may be fixed. Could you look at Bug #312411 and close it if appropriate please?
<ubot3> Malone bug 312411 in linux "[Jaunty] Suspend/resume failure on ThinkPad T61 (pulseaudio-related?)" [High,In progress] https://launchpad.net/bugs/312411
<heywood> @IN: ok, thanks.
<apw> IntuitiveNipple, done
<IntuitiveNipple> apw: many thanks. I want to get the launchpad report into some kind of sane order :)
<apw> which report you looking at?
<IntuitiveNipple> Advanced search for all tags "resume" against "linux"
<apw> ahh i see
#ubuntu-kernel 2009-02-28
<lesshaste> hi.. I have a problem of fairly regular kernel oopses in intrepid
<lesshaste> any suggestion for how to diagnose what the cause is?
<gqwerty> is it possible to configure lpia kernel to other cpu family then generic 586/686, like GEODE on geode based netbook?
<gqwerty> is it possible to configure lpia kernel to other cpu family then generic 586/686, like GEODE LX/GX on geode based netbook?
<JanC> is it possible that something is wrong in initramfs causing partitions not being mounted because the device they are on "isn't there yet"?
<JanC> especially when mounting using the UUID
<Cool_Nick> Is this channel for developing a kernel? or help with compiling and running a kernel?
<IntuitiveNipple> It's for the kernel developers to communicate
<amitk> Cool_Nick: It is specific to the development of the Ubuntu kernel. Generic info is better discussed on kernelnewbies.org, kerneljanitors.org, etc.
<Cool_Nick> ty
<IntuitiveNipple> amitk: Do you get bombarded with email bug reports from the Audio Team because Kernel Team is a member of it? I've been trying to figure out how to get launchpad to not send me anything from the associated teams
<amitk> IntuitiveNipple: yes, unfortunately
<amitk> IntuitiveNipple: I have a bunch of filters that highlight only bugs I am cc'ed on, assigned to, etc.
<IntuitiveNipple> I was just about to dive into .procmailrc on my server to >/dev/null them but thought I'd ask :)
<IntuitiveNipple> I think "* ^X-launchpad-message-rationale: Subscriber.*@ubuntu-audio" should catch them
<amitk> IntuitiveNipple: https://wiki.ubuntu.com/Bugs/HowToFilter
<IntuitiveNipple> hehehe... just done that too :) thanks
<ernstp> isn't there a kernel option to pick cpufreq governor?
<ernstp> I think the performance governor feels snappier than ondemand
#ubuntu-kernel 2009-03-01
<draik_> Hello all. My computer seems to freeze every so often, always within 5-7 minutes. It varies; boot, login prompt, KDE splash, login, and minor usage (yakuake and kwrite).
<draik_> Right now, it just froze on the KDE splash screen. I got the image of the hard drive, but the 2 following images are still blurry.
<draik_> I am on Intrepid with 2.6.27-12-generic
<steve_baker> i'd like to change a driver to load as a module instead statically linking
<steve_baker> but make menuconfig will not let me change the option
<steve_baker> it doesn't give an error or warning, just doesn't change
<steve_baker> it looks like this:   -*- Sonics Silicon Backplane support
<steve_baker> i know its a noob ?, sorry, i just haven't had any luck finding an answer
<mjg59> steve_baker: Something that depends on that module is built into the kernel
<steve_baker> makes sense
<steve_baker> is there an easy way to navigate to a config option in menuconfig if you know its identifier, i can't seem to find SSB_POSSIBLE anywhere in menuconfig :(
<tcole> hello
<tcole> I've got a kernel bug with a patch and everything that's been sitting there for at least a month now
<tcole> could someone please take a look at it?
<tcole> bug #300143
<ubot3> Malone bug 300143 in linux "tablet devices show up as non-functional joysticks" [Medium,Triaged] https://launchpad.net/bugs/300143
<heywood> hello all
<heywood> anyone know the difference between disabling hyperthreading by passing "noht" to grub at boot time, as opposed to issuing "echo 0 >/sys/devices/system/node/node0/cpu2/online" in /etc/rc.local?
<JanC> I guess, you mean passing noht to the kernel from within grub?
#ubuntu-kernel 2010-03-01
<apw> ericm, i've asked on #ubuntu-x about the caps light thing
<matti> I have a question: -pae should enable 32bit machine to be able to access whole of 4GB by introducing another level of page tables and utilizing PAE.
<matti> But I cannot see a difference between -generic and -generic-pae on Karmic.
<apw> matti, it actually should allow the processor to access more than 4GB of physical address space, depending how your bios maps you memory you may or may not get all of your 4GB.  if you can paste the e820 output (from dmesg) from the PAE kernel we can tell where it is
<matti> e820?
<matti> apw: Hold on.
<apw> [    0.000000] BIOS-provided physical RAM map:
<apw> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009c400 (usable)
<apw> [...]
<apw> that bit of the dmesg output following boot ... shows us wherre the BIOS thinks your memory is
<matti> Yes, sorry.
<matti> I had to put my glasses back :)
<matti> http://pastebin.com/i3LEEepW
<apw> matti, ok so your ram is all below 4GB, so PAE will not help you
<apw> with the current memory layout
<matti> :(
<apw> now sometimes its changable (i am told) in the bios, but i've never seen it personally
<apw> in my 4GB ram machine i have this
<matti> BIOS is very limited and rather simple.
<apw> [    0.000000]  modified: 0000000100000000 - 0000000140000000 (usable)
<apw> the last GB of my ram is from 4-5GB physical, therefore pae would help me
<apw> you are getting less thant 4GB cause your ram is being shadowed by the PCI space, AGP etc etc
<apw> what machine is this?
<apw> same laptops particually are limited in maximum memory, even if vendors sell you more than they can really utilise
<matti> HP Desktop
<matti> Give a second, I'll give you the exact model.
<matti> HP Compaq dc7700p
<matti> From dmidecode
<apw> matti, did you add the ram yourself, do you know how many slots the mobo has?
<matti> apw: Thank you for your help. I am rather disappointed in this machine ;(
<matti> apw: Yes, I did.
<matti> apw: 4 slots, each 1 GB.
<apw> how much memory does the os report?
 * apw suspects 3.5GB
<matti> Yes.
<matti> 3482884 kB to be precise.
<matti> I reckon I have -512 MB for the PCI/AGP space.
<matti> Which means that the chipset is rather limited.
<apw> crucial tends to concur with that expectation
<matti> apw: Hm?
<apw> ram seller who tend to tell you how much ram to expect
<matti> apw: I know :)
<tgardner> apw, you'll be happy to know that I can crater Karmic with stress (the program), but not Lucid. 4 proc, 4 cores, 64 threads.
<apw> i am very happy to hear that!
<apw> smb, i've just resynced lucid with karmic hopefully for the last time, keep that in mind if you apply anything to lucid ... sync tag is updated
<apw> s/lucid/karmic
<smb> apw, Ok, I don't think that from now on there should be anything going into Karmic that is not in Lucid, but I keep it in mind
<apw> yeah i am pretty sure we have almost no skew now, i did find three quirks marked as upstream which are not so in lucid, so i pulled them in
<smb> Just watch out for those keyboard quirks which are supposed to be solved differently
<apw> those definatly not needed?  we have the userspace support for those?  i read them as being not necessary if you have the userspace but ... 
<smb> Ok, in theory probably we should, but I cannot say for sure. Maybe asking on #ubuntu-devel to know for sure?
 * matti hugs apw 
<matti> apw: Thanks for your help :)
<apw> np
<akgraner> sconklin, you around?
<sconklin> akgraner: yeah, I'm here
<manjo> smb, does you lenovo S12 take a long time to boot and shutdown ? 
<smb> manjo, no. but it could happen that it needed a keypress to trigger it to go on. (like shift)
<manjo> smb, yes or mouse movements ? 
<smb> manjo, Strangely it seemed to be solved in that case by mem=nopentium
<manjo> smb, I was trying to track down why this weekend ... but failed 
<manjo> thought you might have some insight 
<smb> manjo, Normally it something which is described in debugging voodoo (solved by acpi_skip_timer_override)
<smb> manjo, But it this case the mem= option seems to solve quite a lot of strangenesses
<manjo> smb, you mean its already doc in some wiki ? 
<smb> manjo, https://wiki.ubuntu.com/KernelTeam/DebuggingVoodoo
<manjo> smb, thanks did not see that 
<apw> smb, where might i find that wacom change?  i don't see it in patchworks
<smb> manjo, np, but please try mem=nopentium on your S12 to see it also helps you in that case
<manjo> yep doing it now 
<smb> apw, Hm, might have been a pull req?
<apw> smb, doesn't look like it either
<apw> cnd, was it you who had that?
<smb> apw, yep
<apw> i am running seriously short of uploads so i want them to count
<smb> https://bugs.launchpad.net/bugs/516777
<apw> cnd, did you ever send that wacome thing out for review? i know smb tested it
<ubot3> Malone bug 516777 in linux "HP Touchsmart tm2 requires newer wacom driver" [Low,In progress] 
<cnd> apw, a decision hadn't been made yet as to what we should do with it
<cnd> I was going to get to it sometime today
<cnd> should I send the patches out for review to kernel-team?
<cnd> apw, oh yeah, I'm remembering now
<cnd> I sent an email (you should have been cc'd) to the wacom driver maintainer
<cnd> he's interested in helping to push it to -stable
<apw> if we want it in lucid before it gets hard to get things in, ie before smb has a hand ... then it needs to be very very soon
<cnd> apw, should we put it in as a pre-stable?
<apw> smb you seemed to be keen
<apw> cnd i was assuming it was a pre-stable from your conv with them, but ... not 100% sure
<cnd> conversation with who? the wacom driver maintainer?
<smb> apw, Well for the same reasoning. I think, yes we were thinking of how to progress, the problem is that its hard to predict wether the change as is gets into stable
<smb> apw, So pre-stable might be wrong
<apw> smb, yep ... ok so perhaps i'll punt that one to you :)
<smb> apw, On the other hand our (limited) testing seemed to show no regression
<smb> apw, So it might be a goody to have at that point of time (at least some users of this new hw will be thankful)
<apw> yep, it seemed like we were already getting people hitting issues with new wacome stuff
<smb> apw, So I would tend to include it (maybe still pre-stable as thats our intend)
<apw> i probabally am doing just two uploads of distro before freeze.  one today with everything but drm33 and then if thats a go, the other will be just that
<smb> If we get people screaming for regressions with some wacom stuff we still could revert before release...
<apw> so ... i need it sooner rather than later
<cnd> apw, there's another issue I want to talk to you about, re intel graphics
<apw> smb, yep as thats a 'fix'
<cnd> but I'll come back to it
<apw> cnd i wouldn't wait, whats up
<smb> cnd, So forward the wacom patches today to kernel
<cnd> first, what are we doing with the wacom stuff? you want me to submit patches as pre-stable to k-t?
<smb> (our kernel list)
<cnd> smb, k
<smb> apw, agree?
<smb> Its still your tree. :)
<cnd> apw, bug 488328
<ubot3> Malone bug 488328 in linux "screen brightness won't come back when I open the lid" [Unknown,Fix released] https://launchpad.net/bugs/488328
<apw> cnd get them to kernel-team now yes, i'll put them in as U: S: for now
<cnd> it makes suspend/resume (or even just backlight turning off on screen closure, impossible to resume from on some intel hw
<cnd> there's a patch that seems to fix things
<apw> whats the patch
<cnd> but it seems to have gotten lost upstream when one of the other intel gfx maintainers questioned it
<cnd> apw: http://lists.freedesktop.org/archives/intel-gfx/2010-February/005902.html
<cnd> you can see the reservation noted in the reply email
<cnd> I'm not sure if the reply email is referring to issues that should be fixed in the future (making this moot for them, but still necessary for us)
<cnd> or if we shouldn't apply it at all
<cnd> I'm thinking the former, but wanted to know what you think should be done about it
<apw> it sounds like a 'better' way to fix it, in that we are fixing the wrong bug
<apw> but, if its broke and the fix fixes it ... then it may be much better than nothing
<apw> cnd, do you have affected h/w ?
<apw> wondering if the drm33 kernel also does this?
<cnd> apw, I may in the form of this montevina box rtg sent me, but it seems to have other issues in that it hangs when I flip the lid switch
<cnd> so even though I may have the hw, I can't seem to effectively test it
<apw> heh great
<cnd> apw, I think someone testing against one of the .33-rc kernels, and it wasn't fixed
<cnd> apw, upstream bug report shows someone testing 2.6.33-rc6
<cnd> and it was still broken
<apw> ok get that one out on the list too so we can see how horrific it is
<apw> and make a decision there ... thanks
<cnd> apw, will do, thanks
<cnd> smb, I'm looking into sending the wacom patches upstream to -stable, but the commits don't apply perfectly cleanly to the 2.6.32.y tree
<cnd> is it still reasonable to say, please pick these two changes?
<cnd> or should I point to my own kernel tree hosted at kernel.ubuntu.com with a branch for the changes?
<smb> cnd, In this case generate patches that apply to current 2.6.32.y and send the patches as whole
<cnd> smb, ok
<tgardner> cnd, be sure to reference the upstream commit IDs from which your patch is generated
<cnd> tgardner: ok
<apw> yeah we use the upstream ids when stripping the commits we won't need in a rebase for M
<manjo> have you guys seen this : [    0.562289] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._OSC] (Node f7016a68), AE_ALREADY_EXISTS
<manjo> apw, ^^ smb, 
<manjo> [    0.562269] ACPI Error (dsfield-0143): [CAPB] Namespace lookup failure, AE_ALREADY_EXISTS
<smb> manjo, Yes
<smb> manjo, I think there is an acpi option to make execution serialized, maybe try that
<manjo> https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux/+bug/507148
<ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] 
<smb> manjo, Would "acpi_serialize" help with you error messages?
<manjo> smb, will check thst 
<manjo> apw, I need to focus on what I am doing .. so dropping off... 
<apw> manjo, i hope i said that you could all do that!
<manjo> another pulseaudio problem, this time on lenovo s12 bug #530234
<ubot3> Malone bug 530234 in pulseaudio "[LUCID] unable to record sound though external mic Lenovo SL12" [Undecided,New] https://launchpad.net/bugs/530234
<manjo> smb, If you are on karmic can you confirm that this works/fails on karmic ? 
<manjo> and update the bug ? 
<smb> manjo, I can't tell much about the boot speed
<manjo> smb, regarding the bug above 
<manjo> its about pulse audio I am asking to you see if this is a regression from karmic 
<smb> manjo, On Karmic it works partially (I have to switch to microphone 1 or 2 manually to make internal or external microphone work) It does not seem to switch automatically
<smb> Will add comments
<manjo> :) thanks 
<manjo> apw, I need RTL8192SE driver to get wireless working on EEEPC, currently the driver is in realtek website and not even in staging, I can add that to ubuntu-delta ? 
<apw> you sure? that sounds familiar number?
<manjo> yep I looked 
<manjo> rtl8192e is available
<manjo> which is pci 
<apw> how bad is the delta.  and is it in wireless-testing?
<manjo> let me look at wireless-testing 
 * apw reminds manjo just how close kernel freeze is
<manjo> apw, yes I know 
<apw> i likely will be closing my distro tree by friday ... so ... hurry
<manjo> apw, I will build and test the module 
<manjo> today
<manjo> apw, they should have thought about these netbooks at the start of the cycle
<manjo> apw, I will do my best then its your call 
<apw> manjo, indeed
<manjo> apw, do you mind if I open a bug and do that delta that way ? 
<manjo> apw, that way I have a number I can give krafty regarding enablement etc 
<apw> manjo, you can use bugs for it if it helps you
<apw> we just reserve the right not to use bugs in developement where it doesn't help us
<manjo> apw, ok
<manjo> apw, wireless-testing does not carry that module 
<manjo> apw, there is e, su, 
<manjo> one is pci the other is usb
<apw> manjo, deep joy
<manjo> apw, will start work on it now ... should have test results for you by this evening / request-pull
<apw> i guess it will miss this upload
<apw> manjo, this fix for bug #507148 ... how did you choose this fix for it?
<ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] https://launchpad.net/bugs/507148
<manjo> apw, look at the upstream but on this one 
<apw> manjo, as that fix fixes an oops
<apw> and the error is not an oops
<manjo> oh that last cherry pick I posted ? 
<apw> manjo, yes that one, it seems to be an Oops avoider and to my eye not likely to fix the drm error he has
<manjo> apw, you are correct... 
<manjo> apw, sorry dude, I thought I had the fix 
<apw> manjo, happens ... no worries
<manjo> apw, is there a way to build just a subdir in kernel ? 
<jk-> RAOF: welcome :)
<RAOF> jk-: Thank you!
<jk-> RAOF: you're in .au? whereabouts?
<RAOF> Sydney.
<RAOF> Where the glorious non-hot weather continues!
<jk-> :D
<jk-> plenty of colleagues around then!
<RAOF> Yeah.
<RAOF> I'll be moving to Hobart soonish, though.  Fewer collegues there, but it's a nicer place.  Also, it's a place where buying a house doesn't require your firstborn.
<RAOF> Maybe I can persuade jml back there, too :)
 * jk- is moving to Perth next week
<jjohansen> jk-: wow, I had missed that.  Hope the move goes well for you
<jk-> jjohansen: thanks! should be OK, I think we have most things organised
<jjohansen> cool, I would offer to come help but there is a little ticket issue standing in the way :)
<jk-> :D
#ubuntu-kernel 2010-03-02
<RAOF> Perth's pretty nice, too. Although it's suffering somewhat from the house-requires-firstborn-child now.
<lifeless> RAOF: what?
<RAOF> Perth house prices are moderately nutty now, what with the (continuing) resource boom.
<lifeless> yes
<lifeless> but how does the firstborn come into it? or are you just saying expensive ? :)
<RAOF> I'm just saying expensive.
<RAOF> Perhaps in an overly roundabout way.
<apw> smb, any sign of a .33.y appearing yet?
<smb> Apart from the tree which is there?
<smb> Nothing in GKH s repo
<smb> Q-FUNK, I saw your comments/updates on the bugs. Though I don't think not having a initramfs is a real workaround as it still seems to cause issues. Just not fatal.
<smb> Q-FUNK, Though as we had some issues with Atom based CPUs, you might try the following option "mem=nopentium"
<Q-FUNK> smb: correct.  it makes the bug non-fatal, but it also deprives users from the initramfs functionalities.
<smb> Q-FUNK, I know yours is a Geode, but who knows, whether those share something
<Q-FUNK> smb: I was mostly currious about instructions on how to figure out exactly what part of the initramfs payload is the culprit that messes with sysfs in a fatal way, whenever an initramfs image is used.
<Q-FUNK> smb: well, geode technically is a i586, but sure, I can try that cmdline option.
<smb> Q-FUNK, I don't think anything specific, the chances are high that it too changes timings. And having one less fs mounted also changes the chances of hitting a weird behavior in fs code
<smb> Q-FUNK, The option will cause it not to use large (4M) pages but only 4K ones.
<smb> But the weird behavior there always could not really be associated to code in the fs. Actually the fact that reading values just put into variables back made the error go away completely very much points to something with processor caches. 
<smb> Q-FUNK, I will be away for a bit, but please let us know if that option helps. It would give a bit more ideas on what to look for.
<Q-FUNK> smb: I'm about to reboot the host with that option now.
<Q-FUNK> smb: I'm not sure if these results are conclusive, but please see my additional comments.
 * apw is curious as to the bug number
<smb> ug 396286
<smb> bug 396286
<ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
<smb> apw, ^
<apw> ta
<Q-FUNK> apw: any ideas on how to solve this bug 396286 ?
<ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
<apw> Q-FUNK, nothing other than what has been suggested
<apw> Q-FUNK, in the bug you say 'noraid' helped but don't indicate in what way it helped
<Q-FUNK> apw: I did. it made the error messages go away.
<apw> your text says "without initramfs" to my reading it doesn't say if just the noraid is a work around with no other change
<mozmck> I get four errors like this trying to compile the karmic kernel from git:
<mozmck> drivers/usb/core/hcd.c:144: error: expected expression before '>>' token
<mozmck> I'm using tag Ubuntu-2.6.31-20.57
<mozmck> any idea why?
<abogani> mozmck: Try git reset --hard origin
<mozmck> bleh, I installed a patch, will it undo that?  I'm pretty sure my patch didn't touch that file...
<abogani> mozmck: Yes it'll do it.
<smb> Q-FUNK, apw My guess is that using noraid just avoids disk access because it does not need to scan for signatures...
<Q-FUNK> smb: that sounds plausible.
<Q-FUNK> smb: I really thought that this nopentium was gonna be it, since what it reports is a paging error.  apparently wasn't.
<apw> so at least we have some knd of work around with noraid right
<smb> Q-FUNK, It was worth a try. As it prevents the need to split large pages it would help if the Geode had issues there. Not that the CPU could have other issues. But I must say that I don't know how to proceed from here
<Q-FUNK> it feels that way, although it baffles me as to why.  
<smb> apw, If I understood correctly this is only without having a initrd as well
<apw> smb, that is not what i was just told iiuc
<Q-FUNK> right. it didn't seem to affect operation with an initrd.
<apw> ok does that mean that with an initrd it was still broken or not?
<Q-FUNK> still borken with an initrd.
<Q-FUNK> it only made the errors disappear when running without initrd.
<smb> It feels a bit like disk activity at early boot -> problem. Maybe bad DMA? But why does it work when getting past that stage? And why does it help to read back a value that got written to a struct (is it really read or from a cache)?
<Q-FUNK> from cache.
<Q-FUNK> the errors appeared with 2.6.31, when ACL caching was added to all filesystem types.
<smb> Q-FUNK, I meant a cpu cache. The ACL caching just happens to be some structure that really has bad effects when being wrong
<Q-FUNK> ah
<apw> one has to be suspicious that this cpu has a flaw
<Q-FUNK> I doubt it, since kernels up to 2.6.30 run flawlessly.
<Q-FUNK> there's really something shady that was done starting with 2.6.31 that buggers.
<smb> Q-FUNK, This can just be something that was flawed before, but with the other changes now takes place
<Q-FUNK> then again, a similar change happened with 2.6.23 that already killed support for older geodes.  that time, it was a known change and easy to spot.  not so this time.
<Q-FUNK> apw had tried to help me inviestigate that older bug.  it turns out it was a complete rewrite of how some interupts are handled.
<Q-FUNK> and there was no turning back on that change.  support for older geodes is factually gone (unless someone is willing to figure out what's wrong with the new implementation for that interrupt handler).
<smb> Q-FUNK, Well the code change that triggers your problems this time has showed no bad parts on its own. Make a structure a bit bigger to add two pointers. Set those pointers to -1 (all bits set) and take that value as unset. Checking access functions to these pointers they are not accessed after init. But still some bits get cleared. But not if you read back the pointers directly after you written the values to the structure.
<Q-FUNK> I'm wondering if what we're not seeing might be in some new include that implements the ACL caching's core functions or a mere copy/paste error.
<tgardner> apw, what are the odds that a karmic->lucid upgrade will wreck my life? nVidia dual head being the salient issue.
<apw> do both your heads work now?
<apw> there are also hints that suspend/resume does not work so well with nvidia
<apw> i would be concerned, and recommend you take a usb stick and test it before committing
<apw> tgardner, ^
<tgardner> apw, yep. both heads work. I never suspend/resume this box anyways.
<tgardner> apw, any reports of neauvou (sp?) working with 2 heads?
<apw> nouveau, i think the only report i have had was from smb who had poor experience with his external
<tgardner> apw, thats different then a dual display
<tgardner> dual DVI
<smb> Right, its only single VGA
<smb> (but behind monitor switch)
<apw> point, then i think you'd be the first.  i'd be interested to know how it worked out but have no bacjground
 * tgardner is not often a first adopter :)
<apw> tgardner, what does msm stand for in our new branch
<tgardner> apw, mobile station modem
<apw> tgardner, i assume i should be treating this like any other distro arm kernel and making it work with our userspace
<tgardner> apw, yep, did I miss some config options?
<apw> no but there is a bunch of recent backports to handle lucid userspace
<apw> amd pulling them over now
<tgardner> apw, ppoll et al?
<apw> devtmpfs, modules.builtin async_populatefs, kmsg permissions and ppoll
<tgardner> egads, I missed a bunch of stuff
<apw> nothing major, will take 10 mins i hope
<tgardner> apw, just rebase that branch instead of starting a new release. 
<apw> tgardner, will do
<apw> tgardner, how are we going to keep this branch in sync with other development?
<tgardner> apw, other development? do you mean the chromeos tree?
<apw> yeah i assume its going to be developed in a way that we have this lucid delta
<apw> and need to maintain that on top
<tgardner> apw, we _should_ be able to just cherrypick from the msm Qualcomm 2.6.21.12 branch. However, I don't expect that they'll be making many more changes.
<tgardner> 2.6.31.12*
<apw> tgardner, ok cool, i guess we'll need to get that documented, where the master tree is sort of thing
<tgardner> apw, I created a README*
<apw> ahh good
<tgardner> apw, this may not be cast in stone yet. Martin is pushing to cut over to 2.6.32 sometime in March.
<apw> so we may have a replacement branch at .32 anyhow
<tgardner> apw, possibly.
<apw> tgardner, ok am bulding the 'final' branch now ...
<tgardner> apw, ah, at least those patches just slid in. I can't remember if the config checks ended up in the karmic tree, from whence this originated
<apw> heh no they arn't there yet, the backport will pull those over, one more thing on my todo which is nearly done
<apw> tgardner, you using anything special to build test this branch?
<apw> /home/apw/build/lucid/ubuntu-lucid/arch/arm/mach-msm/avs_hw.S: Assembler messages:
<apw> /home/apw/build/lucid/ubuntu-lucid/arch/arm/mach-msm/avs_hw.S:36: Error: selected processor does not support `fmrx r3,fpexc'
<manjo> tgardner, I saw you ans to the firmware question I had, the fw is not in any of the linux-firmware or linux-firmware-nonfree tree but it is part of the tarball source package 
<tgardner> apw, different cross-compile tools then I'm using?
<apw> i am using the 2009q3 toolchains from code-sourcery, what you got?
<tgardner> manjo, thats not really relevant. there must be a license for the firmware.
<tgardner> apw, arm-2008q3, so I'm down-rev
<apw> hrm
<apw> tgardner, then i am suspicious its not toolchain
<tgardner> apw, push your changes and I'm upgrade and get it sorted.
<apw> can you pastebin your incantation to build it
<apw> i suspect its me
<tgardner> apw, hang on...
 * apw holds everything and looks pensive
<tgardner> apw, :) 'debuild --set-envvar=CONCURRENCY_LEVEL=1 --set-envvar=CROSS_COMPILE=arm-none-linux-gnueabi- --prepend-path=$(CROSSTOOLS_ROOT)/bin -b -nc -aarmel -us -uc'
<tgardner> apw, nothing special really
<apw> tgardner, ok branch pushed ... see if that builds for you
<tgardner> apw, ack
<manjo> tgardner, where should I be looking for a firmware license?
<tgardner> manjo, I assume in that tarball.
<tgardner> manjo, work with cnd. He's well versed in the issues.
<manjo> cnd, ^^
<cnd> manjo, give me a minute, writing up a bug report comment
<apw> tgardner, same when invoked direct like you did ... oddness
<tgardner> apw, building, it'll be done in a couple minutes
<apw> its breaks right a the start for me, you using the old or new toolchaings
<tgardner> the old one
<tgardner> 2008q3
<apw> yep, a good test
<apw> thats a royal pain in the bottom
<Sarvatt> has anyone seen any bugs around where 2.6.32-rc2+ need MMC/SDHC built into the kernel instead of as modules to get around hangs on suspend if a SD card has ever been mounted?
<tgardner> apw, looks like its gonna finish
<apw> Sarvatt, i think there was a few issues with mmc, i remember not being able to get them auto mounted, not sure i remember that specific error thoug
<tgardner> apw, suppose there is a compiler flag that we need? I'll get the 2009q3 version and mess with it.
<apw> tgardner, so the only question is why the tool chain is pissed off, is that a port issue
<apw> i could upload it and see if it builds i guess
<apw> would make testing hard and annoying tho
<cnd> manjo, have you found the license in the tarball?
<tgardner> apw, yeah, lets try and sort it before creating archive carnage
<apw> tgardner, works for me
<manjo> cnd, no there is no such file
<Sarvatt> i built a kernel with SDHC/MMC built in and unsafe resume enabled and I'm able to suspend, but with the ubuntu kernels where they are modules it hangs when I try to suspend if I've ever mounted the sd and suspends fine even with a sd in the slot as long as I've never mounted it
<Sarvatt> so strange
<apw> tgardner, i am suspecting we need to get on the mir bandwagon too before we could upload it
<cnd> manjo, does it seem to be an oversight on their part (i.e. it looks like it should be redistributable, but they don't have a license file)?
<apw> Sarvatt, i suspend routinely with SDHC cards in my mini 10v
<cnd> manjo: if so, I suggest emailing them to let them know
<smb> Sarvatt, apw I think I tried to suspend on 2.6.32 but failed when a mmc card was mounted. But I have not tested lately...
<cnd> manjo: for now though, we'll need to put it in linux-firmware-nonfree
<manjo> cnd, I am emailing them now to find out 
<Sarvatt> it doesnt work on a mini9, you're lucky apw :D 
<smb> apw, Is yours the one attached to a usb controller...
<manjo> cnd, is linux-firmware-nonfree part of our repos ? 
<apw> manjo, is there no licence on the whole tarball?
<cnd> manjo: for -nonfree you have to use apt-get source
<cnd> manjo: there's no git tree
<apw> if not its not obvious we can take the driver either
<cnd> manjo: it should be fairly obvious how it builds in debian/rules
<manjo> cnd, wait I am confused 
<tgardner> apw, nah, I think this can be a universe package for the time being.
<Sarvatt> smb: did it hang with the screen still on when you tried it?
<manjo> cnd, there are is no repo for linux-firmware-nonfree, then where do I add the fw to ? 
<apw> tgardner, is there any hoop jumping for uploading a new package to universe?
<cnd> manjo: there's no git tree, the process is just 1. take the latest package source 2. update it 3. upload the new source to somewhere rtg can get to 4. tell him to upload it into lucid
<tgardner> apw, nope, you only have to be a core-dev, or have rights to linux source package (AFAIK)
<smb> Sarvatt, backlight, yes (but blank/black screen) Seems to be the same right now
<manjo> cnd, you are suggesting a dkms package ? 
<manjo> for the fw ? 
<apw> good enough you'll be able to shove it in then, i won't as i suspect i can't ask for upload rights to it till you have uploaded it once
<cnd> manjo: no, a dkms package is only meant for kernel modules
<cnd> manjo: this is like typical debian packaging
<Sarvatt> ah my screen still shows what was on it when i suspended here, it definitely does most of the suspend because i hear the acerhdf module unloading and fan spinning up and when i reboot the network is still disabled
<cnd> manjo: dkms is a package you install that builds a new kernel module from source for every kernel you subsequently install, so it's a special type of debian package
<cnd> manjo: most debian packages are already built in binary form, so they just install files to the filesystem
<manjo> cnd, I know what debian packages are 
<smb> Sarvatt, This is an Acer Aspire One as well?
<manjo> I still don't get it 
<Sarvatt> yeah acer aspire one AOA150
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/477106/comments/6
<ubot3> Malone bug 477106 in linux "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware" [Undecided,Confirmed] 
<cnd> manjo: where's the disconnect?
<smb> Sarvatt, Mine is AOA110
<apw> manjo, the package is only in the archive, you get the source with apt-get source <foo>
<apw> change it and upload that againt, it exists nowhere else but the archive
<manjo> apw, ah! so don't add to /ubuntu 
<Sarvatt> same thing then but mines the HDD model
<apw> this is just for the firmware ...
<apw> manjo, does this driver have any licence at all?  where did you get it?
<cnd> apw, manjo, it's just for firmware-nonfree
<cnd> linux-firmware is kept in git
<apw> cnd, right
<apw> i meant in his case we were talking about just the firmware
<cnd> yeah
<smb> Sarvatt, Yes, so mine fades the screen to dark, fan is spinning to, then stays there as well. I see some disk activity before which stops at some point
<smb> Sarvatt, I believe apw's sd slot is a USB device while the aoa is a pci/jmicron
<apw> smb, yes could be
<apw> please don't tell me there are more issues, thanks a lot
 * Sarvatt nods
<smb> apw, I can tell you not if you prefer. :-P
<Sarvatt> i'll have to try just building mmc/sdhci/sdhci-pci into the kernel and not enabling unsafe resume to see if that also fixes it
<apw> Sarvatt, sounds good, get a bug filed and let us know the number
<apw> i'll need to find someone who can reproduce it to try and fix it ... :)
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<smb> Sarvatt, Yes, that would provide a better pointer. With unsafe suspend the card will not get ejected on suspend. iirc. And that might be the difference that counts
<apw> smb, yeah mine get bounced every time i suspend i think
<smb> apw, Though probably through a different mechanism. Just guessing, but usb probably has eject code in the core, while mmc does something similar somewhere else
<apw> i think my big latop has an mmc, but that machine is broken for suspend already
 * bjf just noticed the team meeting date in the topic
<smb> bjf, But we cannot change it
<smb> Sarvatt, In my tests I can suspend even after having had mounted the SD card. It just must not be mounted on suspend
<apw> indeed one needs to be an op to do that
<Sarvatt> apw: there's a bug here - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/477106 building a kernel with just the sd stuff built in and no unsafe resume now to see if that also works. i always enable unsafe resume on the kernels I build because its a pain remounting every resume when I usually have files open on the SD at suspend time :D
<ubot3> Malone bug 477106 in linux "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware" [Undecided,Confirmed] 
<Sarvatt> smb: odd, here if I have ever mounted it even if its unmounted at suspend time it still hangs
<Sarvatt> smb: are you using the left SD slot?
<smb> Sarvatt, Yes, the right one only work(ed)s when I have a card in on boot 
<apw> Keybuk, hey ... i have a preliminary patch for this readahead tracking, and wondered if you fancy testing it
<Keybuk> apw: hey, could you mail me the details and stuff
<Keybuk> I'm in the middle of Plymouth at the moment and can't really drop state since this does need to be working by Î²1
<apw> Keybuk, will do
<Sarvatt> btw smb, you might want to add enable_mtrr_cleanup mtrr_spare_reg_nr=1 to the kernel command line on your aspire one since they have screwy mtrr's
<smb> Sarvatt, Heh, I know. I have enable_mtrr_cleanup alone. 
<Sarvatt> any particular reason we dont enable pcie aspm in the kernel config?
<smb> Sarvatt, Because its marked experimental and "in doubt say no"?
<Sarvatt> i could have sworn experimental got removed a few releases ago but I just looked and you're right
<bjf> smb, did you want to change the topic?
<smb> bjf, Yes, tried it before
<apw> you nneed to be an op, 
<bjf> smb, I'm in #ubuntu-ops asking
<johanbr> Sarvatt, https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/342096 seems related and has some useful information
<ubot3> Malone bug 342096 in pm-utils "SD Card containing /home corrupted on resume" [Undecided,Confirmed] 
<Sarvatt>  /home on sd needs unsafe resume enabled in the kernel config, need to build your own kernel for that
 * smb wonders whether that was his bug filed for Karmic
<Sarvatt> that should probably be wontfix since i doubt you guys are ever going to enable unsafe resume by default :D
<Sarvatt> oh looks like you did in hardy
<smb> Sarvatt, Somehow it feels like unsafe might be safer than safe
<Sarvatt> ohh nice
<smb> Sarvatt, would unsafe resume work for you also when built as a module? Won't promise anything but it might help on a decision
<Sarvatt> This option sets a default which can be overridden by the module parameter "removable=0" or "removable=1".                   
<Sarvatt> can test that without rebuilding the kernel now
<Sarvatt> unsafe resume depends on MMC being built in and not a module unfortunately
<Sarvatt> ah nevermind CONFIG_MMC=y is what it needs and thats already there
<Sarvatt> so booting with mmc.removable=1 should work, lets see
<smb> Sarvatt, I am not sure were you exactly get that option from. The code looks to me like completely changing functions when UNSAFE_RESUME gets set
<apw> jjohansen, hiya, i've been playing with rebasing the -ec2 kernel, as there are lots of interactions i have created ... there were two conflicts in the early patches is just correcting those the righ way forward
<apw> jjohansen, will have some images from those for potential testing shortly
<jjohansen> apw: okay
<apw> am i correct to just fix conflicts or is there a magic way
<jjohansen> apw: just fix them
<apw> cool
<jjohansen> and pray it doesn't break
<jjohansen> :)
<jjohansen> apw: I am running slightly behind (sleep caught up with me) will finish pam_apparmor today
<bjf> ##
<bjf> ## Kernel team meeting in 10 minutes
<bjf> ##
<apw> jjohansen, heh yeah thanks ...
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<apw> jjohansen, those new lucid ec2 kernels are here: http://people.canonical.com/~apw/ec2-lucid/
<jjohansen> apw: thanks
<apw> we don't get much in the way of interactivity in our meeting ... hrm
<smb> apw, At least we get it done quick
<cnd> apw, fyi I'm working on a patch against the alsa driver to prevent a warning message from polluting the boot splash screen (it's level is KERN_ERR, which upstream has acknowledged is too high)
<cnd> oops, against acpi
<cnd> not alsa
<apw> cnd sounds ok, that would be a minor change, and a bug fix so i am sure we can get that past the ack process after freeze if its not ready in time
<apw> smb, ^^
<smb> cnd, That is a bug fix
<smb> yeah
<apw> cnd, but bringing it up is the right thing
<Sarvatt> smb: i pasted that from the kernel config option, but its in drivers/mmc/core.c
<smb> Sarvatt, Seems to be upstream but not Lucid. If I am not looking at the wrong version
<Sarvatt> smb: booting with mmc.removable=0 (aka enabling unsafe resume) changed it so the screen goes black but the backlight is still on like you were saying you get
<Sarvatt> well thats odd, i did it with the lucid kernel and it changed what happens when i suspend
<smb> Sarvatt, That option was added in 2.6.33 and I do not remember it being in stable. Basically you know have the same behavior as I do without anything specially set.
<smb> But the option should have no effect other than being ignored
<tgardner> apw, if I was going to be able to enable 2 monitors, then one would expect they'd both be detected in 'Monitor Preferences", right?
<apw> i would expect so, but i would also  run xrandr to see what happens when you do, and also to see what it says you have
<tgardner> apw, hmm, it sorta thinks I _might_ have 2 displays. I think I'm gonna install to an external HD first and do some experimenting lest I totally wreck my dev box.
<apw> tgardner, very sensible
<Sarvatt> smb: without mmc.removable=0 and a SD mounted suspend freezes with the screen contents still on the screen, with the option I get a vt switch and the backlight is still on and the screen is blank. I just reproduced it 4 times with each method even though mmc.removable=0 doesn't do anything on 2.6.32-15. very confusing
<Sarvatt> i still have the kernel where all the mmc stuff was built in though and I can just boot that with mmc.removable=1 to test if disabling unsafe resume with the modules built in works on .33 at least
<smb> Sarvatt, That is indeed beyond my understanding. Yes, in .33 it should (in theory work that way)
<Sarvatt> 2.6.33-rc8 + mmc.removable=1 (aka disabled unsafe resume config option) + mmc/sdhc modules built in works
<manjo> cnd, apw sorry I had to drop off I had an emergency
<cnd> manjo: how far did you get with the firmware stuff?
<manjo> cnd, I will get together with you in 2 hrs or so and sort this firmaware stuff out 
<cnd> manjo: ok
<manjo> cnd, I still need to be away for a little bit.
<cnd> manjo: if you have pressing, more important issues I can do the firmware work for you
<manjo> cnd, you mean I just give you the fw files and you magically make them appear in /lib/firmaware/RTL8192SE/ ?
<cnd> manjo: I mean I take the bug and work it and get it uploaded for you
<manjo> cnd can I skype you quickly ?
<cnd> sure, one sec
<cnd> need to get headset
<cnd> manjo: ready
<manjo> I don't think I have you on my list
<manjo> cnd, what skype id ? 
<cnd> manjo: corp186
<cnd> I'm not keen on providing my details in the skype directory :)
<cnd> anyone familiar with hotplug?
<cnd> I've read the README in Documentation, it says the kernel somehow calls "hotplug" in userspace to do stuff, and there's a sample hotplug script
<cnd> but I don't know of any hotplug user space script or executable
<smb> cnd, That sounds like old cruft, when there was a callout to a hotplug script
<cnd> smb, do you know how it's done now?
<cnd> is it all in-kernel through vfs?
<smb> cnd, But that has been all replaced by netlink(?) messages. And udev reads those messages
<cnd> hmmm
<cnd> smb, looks like udev now handles hotplug events, but the mechanism is still the same
<cnd> it's just that the hotplug script is now part of udev
<cnd> I've found it in /lib/udev/firmware.sh
<smb> cnd, The method is uevent, not netlink. Too late here. But its a bit more than that.
<cnd> smb, I'm most interested in the firmware loading part, not the event propagation part, so I think I've found what I need
<cnd> thanks
<smb> cnd, ok.
<Sarvatt> hmm wasn't this upstream in the 2.6.29 timeframe? UBUNTU: Disable 4MB page tables for Atom, work around errata AAE44 - http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=97684193e8c6fea095adcc4928f389b090559fc6
<Sarvatt> aka shouldnt be needed to be backported to karmic-lucid
<jjohansen> apw: your EC2 kernels are as good as the last set (ie. doesn't fix outstanding bug but doesn't introduce any new ones that I can see)
<Sarvatt> yeah the fix is already there at line 535 - http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=blob;f=arch/x86/mm/pageattr.c;h=dd38bfbefd1fa1972f47403fa6b35e20663e3590;hb=97684193e8c6fea095adcc4928f389b090559fc6
<Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=211b3d03c7400f48a781977a50104c9d12f4e229
<Sarvatt> I put a note on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/523112 about how its already in the kernel for lucid apw
<ubot3> Malone bug 523112 in linux "Intel Atom CPU can oops because of bug listed in Intel errata AAH41 and AAE44" [Medium,Fix committed] 
<cnd> is there anything that can be done about an rfkill hard blocked device?
<cnd> the external switch is set to on, so I'm guessing it's something that's either in the bios or set in some windows driver?
<cnd> bdmurray: I'm removing your patch tag on bug 530348 because the patch is diagnostic in nature, not a "fix"
<ubot3> Malone bug 530348 in linux-firmware "e100: eth0: e100_request_firmware: Failed to load firmware "e100/d101m_ucode.bin" [Undecided,Incomplete] https://launchpad.net/bugs/530348
<bdmurray> cnd: then maybe the attachment shouldn't be flagged as a patch?
<cnd> bdmurray: it's still technically a patch
<bdmurray> but not a patch that fixes the bug which is what the flag should be used for
<ogasawara> bdmurray, cnd: yah, I'd vote to not flag the attachment as a patch
<cnd> bdmurray: ok, bugzilla land is different
<cnd> you flag things that are patches in bugzilla land so that the attachment viewer handles them correctly
<cnd> maybe the flag should be called patch-fix?
<manjo> cnd, I added the firmware to the linux-firware-nonfree package, and it build and works fine, how do I modifiy the changelog ? 
<manjo> since this is not a git package 
<manjo> or git tree
<cnd> manjo: dch -i starts a new changelog template and opens it in your $EDITOR
<manjo> duh! ok 
<manjo> thought there was some other magic to it 
<cnd> manjo: nope, pretty simle
<cnd> the magic comes when you're using a git tree
<manjo> cnd, after I do that just tar up the direcotry and upload to zinc ? 
<cnd> manjo: so you've been building by running debuild right?
<manjo> yes
<akgraner> bjf, ping
<cnd> so, first delete everything debuild created in .. (this will make it easier to figure out what's created in the next step)
<cnd> manjo: then run debuild -S
<cnd> that should create a source.changes file, .dsc file, and tarball file
<manjo> ok
<manjo> it did 
<bjf> akgraner, yo!
<cnd> then upload it somewhere, like I did at kernel.ubuntu.com/~cndougla/linux-firmware-nonfree
<cnd> and then yell at rtg :)
<manjo> cnd, why did mine get renamed to linux-firmware-nonfree-1.6ubuntu1 ?
<cnd> manjo: ahhh, dch -i be default appends a new ubuntu release version (maybe there's a better option than -i?)
<cnd> so in your changelog you should change that to -1.7
<cnd> manjo: looks like dch -v 1.7 would have been the best route
<manjo> ok I will redo
<cnd> manjo: you don't really need to undo what you did though
<cnd> just modify the changelog 
<manjo> cnd, thanks a ton 
<manjo> its done 
<cnd> manjo: np, you got it uploaded some where?
<manjo> cnd, sorry I had to step out a few times during the day... so get interrupted getting this done 
<cnd> manjo: that's fine, I hope the therapy helped with whatever issues you had
<manjo> yep its on my people page ... http://people.canonical.com/~manjo/lp530275-lucid/firmware-nonfree/
<cnd> manjo: btw, you don't need the .build file
<cnd> that's just a log of the build process
<manjo> yeah I did an scp * so that got in as well
<cnd> which for a source package build is even less useful :)
<cnd> manjo: what did rtg say about the format of directories in the package?
<manjo> cnd, I did not talk to him yet... I am shipping the firmware to lib/firmware and that is where the driver is picking it up from
<manjo> cnd, but looks like its really a simple change to the rules script to do it 
<manjo> right 
<cnd> ok
<manjo> cnd, too late in the cycle to mess with it now 
<cnd> heh
#ubuntu-kernel 2010-03-03
<RAOF> I've tracked down the cause of a large (I think almost all) segment of our nouveau bugs - it really is vga16fb loading before lbm_nouveau and claiming fb0.
<RAOF> The in-tree KMS drivers don't suffer from this, because they're listed in modules.order prior to vga16fb, so they get first dibs at providing a framebuffer.
<RAOF> Adding nouveau to modules.order before vga16fb fixes the problem, but that file is generated on kernel build.
<jk-> hm, the imx51 led support looks pretty dubious
<RAOF> jk-: Are you familiar with the kernel's modules.order, how it's built, and how I could futz with it to make nouveau work?
<jk-> RAOF: no I'm not, sorry :/
<RAOF> That's ok.  I'll wait for apw or sconklin.
<lifeless> RAOF: http://lwn.net/Articles/260856/
<RAOF> lifeless: Thanks.  I've already found that one; I need to work out with the kernel guys how to best make the changes I need in it.
<RAOF> Specifically, to ensure lbm_nouveau.ko appears in it, and appears in it before vga16fb.
<lifeless> RAOF: change the kernel  Makefile
<lifeless> as that appears to be the driver according to the article
<RAOF> Except lbm_nouveau isn't built by our kernel; we build it out of tree.
<lifeless> true
<RAOF> Otherwise this wouldn't have happened in the first place.
<Kano> hi, apw , will there be a .33 kernel soon. or do i have to wait till you know a name for next release? i would call it mad monkey ;)
<apw> Kano, prep for the next kerenl will start after kernel freeze next week
<Kano> good
<Kano> one system has got problems with .33 the other works fine
<Kano> btw. you have to change the firmware for hauppauge nova s2
<Kano> there is even a launchpad entry but still not fixed
<Kano> i have got a fixed firmware in my package
<Kano> md5sum /lib/firmware/dvb-fe-cx24116.fw
<Kano> b8c856ac15b768854a222e6864e7dc7f  /lib/firmware/dvb-fe-cx24116.fw
<Kano> thats a working firmware
<apw> Kano, whats the bug number?
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/363682
<ubot3> Malone bug 363682 in linux-firmware-nonfree "cx24116 firmware doesn't load - firmware corrupt" [Medium,Triaged] 
<RAOF> apw: Will you be available for a chat about nouveau in an hour or so?
<apw> RAOF, should be about yes, anything specific 
<Kano> apw: thats dvb-fe-cx24116-1.26.90.0.fw btw
<Kano> the md5sum
<RAOF> A couple of things: adding lbm-nouveau to linux-meta, and working out how to ensure lbm_nouveau gets to claim fb0 before vga16fb (which could be done by futzing with modules.order).
<Kano> you dont need to use the old firmware
<Kano> apw: the 1.26.90.0 is verified by a kanotix user
<Kano> http://james-lloyd.com/xbmc-live/
<Kano> if you want to extract it yourself...
<Kano> well best fetch it from my package...
<Kano> bye
<tjaalton> RAOF: doesn't the .33 drm backport fix those issues?
<tjaalton> which should land soon aiui?
<apw> lbm-nouveau should be in linux-meta shouldn't it ... but yes i think the decision is to take drm .33 directly so some of this will be moot.  let me know when you want to talk
<RAOF> apw: Knowing that pulling .33 into the kernel image is planned makes things less urgent; indeed that should fix most of the problems.
<apw> sounds like we still have issues with vesa16fb
<RAOF> Not unless vga16fb gets built before nouveau; modules.order should keep everything ticking along smoothly.
<RAOF> Anyway, I'll have dinner and come back.
<RAOF> apw: Ok, so the .33 backport will fix the issues that I wanted to discuss.  What sort of timeframe are we looking at for that?
<apw> i have it in testing, you've probabally seen my red ppa i want to get the stake-holders together one last time to say 'go' but i think we all agree its the least pain route
<apw> i would expect to get it in the archive in my next uppload, by friday i would think
<RAOF> Ok.  I wanted to send out a final nouveau call for testing, but I'll wait for that, since I'm pretty sure that'll fix the biggest issues people have run into.
<RAOF> I take it that we won't be having a 2.6.34 linux-backports-modules package?
<apw> RAOF, i'll get the kernel sorted as soon as possible and pushed into my red PPA, then we can ask for testing on that while i finalise the archive uplaod
<apw> i would expect nouveau to dissappear from LBM and am not wanting to support a later one no
<RAOF> Good.  Because I don't think we can support both from userspace, either.
<apw> well that is a very good reason to not have one.  
 * apw thanks RAOF for all his contributions already
<apw> handy to have someone on this end of my day :)
<RAOF> :)
<RAOF> Hm... can we have the kernel conflicts/replaces the nouveau-kernel-source package?
<apw> i guess your day is tending to the end given you mentioned dinner ... so i'll get the latest tip of my tree with drm33 up into 'red' then you can ask for testing on that, should be there for your morning
<RAOF> (Incidentally, bug #531085)
<ubot3> Malone bug 531085 in linux-backports-modules-2.6.32 "linux-backports-modules-nouveau should replace nouveau-kernel-source" [Undecided,New] https://launchpad.net/bugs/531085
<RAOF> apw: Thanks.
<apw> yeah we will need to replace or whatever the previous one
<apw> and indeed all of those probabally
<lifeless> RAOF: conflicts is bad
<lifeless> RAOF: don't use it unless you really mean 'cannot be in state unpacked with $other'
<lifeless> RAOF: see debian policy for precisely what unpacked means
<lifeless> RAOF: breaks + replaces is the recipe to use for what used to be conflicts + replaces.
<RAOF> lifeless: Thanks.
<lifeless> RAOF: no probs; used to be hat breaks didn't exist.
<RAOF> Indeed.  And last time I read policy I didn't pick up that conflicts/replaces should become breaks/replaces.
<RAOF> apw: I'll need to upload a new xserver-xorg-video-nouveau to a PPA, dropping the lbm-nouveau dependency, to complement your kernel image.  I'll do a binary-copy from your PPA so that everything's in the one place.  Could you ensure your kernel image have a breaks/replaces pair on linux-backports-modules-nouveau-2.6.32-15-generic?
<apw> so Breaks: and Replaces: on that
<RAOF> Yeah. (According to lifeless ;))
<RAOF> And possibly also on nouveau-kernel-source, but that'll be less of a problem because I'm pretty sure it doesn't actually build against our kernel.
<RAOF> And it's time for me to sign off.  Thanks for that; I'll send of the testing request in the morning.
<lifeless> RAOF: its not just me; its policy :)
<lifeless> breaks - not usable while installed; conflicts - not unpackable.
<lifeless> a breaks cycle is upgradable without --force, a conflicts cycle is not.
<apw> lifeless, presumably i should be Breaks; and Conflicts: with linux-backports-modules-nouveau-2.6.32-15-generic <= current version
<lifeless> apw: hmm ?
<apw> presumably i should just conflict etc with the current and older versions, in case we ever have a newer backport
<lifeless> you should break: with it
<lifeless> if you have files they also have but you should own, then you should replaces: with it
<lifeless> a break: relationsip works the same way at the 'apt' or 'synaptic' level.
<apw> and conflicts?
<lifeless> but it works very differently at the dpkg level
<lifeless> you should only conflict when:
<lifeless>  - you have a file another package has
<lifeless>  - you don't 'replaces:' that package
<lifeless>  - it does not 'replaces:' you
<apw> the files do not overlap at all so i don't think i need a replaces
<apw> and it sounds like i don't conflict either
<lifeless> in which case you don't need a conflicts.
<lifeless> if installing the package will break stuff, you want 'breaks'
<apw> if i make it Breaks: what will happen, what i want is the old to be removed
<lifeless> yes
<lifeless> but its a little looser about the ordering during the upgrade
<apw> ok cool.  Breaks: foo it is
<lifeless> which is good, otherwise you can end up in situations where you cannot upgrade without forcing dpkg to do unsafe things
<lifeless> (which apt does today, because the package graph has lots of mutual-conflicts in it)
<apw> so replaces is for moving things from one package to another cooperativly
<apw> conflicts is for two packages which do the same thing
<apw> and breaks is for 'push that other thing out for me'
<apw> "i am taking over from that package"
<matti> Hi apw ;]
<lifeless> conflicts is for two packages that cannot be 'unpacked' simultaneously
<lifeless> which is fairly technical in the guts of dpkg: its the stage before maintainer scripts run
<apw> lifeless, so they literally hit the same filenames before anything can do anything about it
<lifeless> right
<lifeless> exim and postfix
<apw> so it would still typically be packages for the same thing, like sendmail
<lifeless> yes
<lifeless> and there are actualy virtual packages they will both provide: and conflict: with
<apw> cool thanks ... /me files that away
<lifeless> which tells dpkg - let only this one thing be in that 'slot'
<apw> matti, hi
<lifeless> that way they don't have to list all their peers
<apw> so is conflicts in a virtual namespace?  Conficts: email-server stylee?
<apw> and can it therefore conflict with a provices: foo sort of thing
<lifeless> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
<lifeless> it and the next section
<lifeless> the virtual thing is 'A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing some feature. '
<apw> lifeless, you sound like someone who would know ... the kernel declares an old standards version, how would i know what changed in the standard between that versions and the latest to know if we are compliant and can move there?
<lifeless> zless /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
<apw> lifeless, awsome
<apw> lifeless, though file not found on my system
<lifeless> apt-get install debian-policy
<apw> doh, thanks, /me turns on his brain
<lifeless> :P
<apw> lifeless, gah we a miles behind ...
<lifeless> happens :(
<apw> lifeless, being the kernel its easier than most to move forward as we don't make most of the things like shared libraries whcih change a lot ... where is the right place to ask for advice as to meaning of some of the changes?
<lifeless> #ubuntu-devel
 * apw has read through the upgrading-checklist and i actually think (assuming our sections are right) that we are actually complient with all the changes already ... awsome
<tgardner> apw, have you pulled lp531017 yet? I'd add another d-i module if not.
<apw> tgardner, not yet, feel free to ipdate
<apw> tgardner, just sorting out the perf binary at the moment... i think it'll be without manuals for the first version
<tgardner> oh yeah, I've been forgetting about that. good call.
<apw> the 'easy' bit is done, i now have it making /usr/bin/perf-2.6.32-15-generic ... but there is no sane method to version the manuals, so i thin we'll have to have a new package to handle those
<apw> i think if i add like a linux-tools package which contains the 'perf -> perf-version' mapper script, that could include the manuals too
<apw> and make it like the docs package, you get the latest only job
<tgardner> apw, couldn't the manual just go into /usr/share/doc/* ?
<tgardner> thought the linux-tools package idea isn't bad
<tgardner> though*
<apw> well it needs to be installed correctly to get man perf foo and perf --help foo to work
<tgardner> ack, I've been treating perf sort of like a bastard stepchild.
<apw> as we need a linux-tools to carry the common shell script.  if i cheat and use it to carry the manuals too, then i have to put it in the main kernel source, which means we don't have to find somewhere else to put the source for it at least
<apw> and i can make the binary packages depend on the linux-tools ... which sounds like a win
<tgardner> apw, one more -meta package relationship...
<apw> i think we don't even need a meta for it
<apw> but i'll check, it should be able to work the same as linnux-doc i think
<apw> Package: SRCPKGNAME-doc
<apw> yeah linux-doc is actually a real package, i think linux-tools can be too and use the same 'Conflicts/Replaces' magic to get only the last one on
<tgardner> apw, just a simple version? no ABI in it?
<apw> right no abi, as all thats in it is the shell script for versioning and the latest manuals for perf
<tgardner> heh, works for me
<apw> the binary tools are really in the linux-image
<cnd> apw, I'm looking at bug 363682 you commented in earlier today
<ubot3> Malone bug 363682 in linux-firmware-nonfree "cx24116 firmware doesn't load - firmware corrupt" [Medium,Triaged] https://launchpad.net/bugs/363682
<apw> cnd ok, just recording the information on how to get it i was given
<cnd> I was wondering why you posted about the 1.26.90.0 firmware version, when others above (specifically comment 4) refers to newer versions
<cnd> apw, were you told by someone that that's the best fw to grab?
<cnd> I'm going to update the fw package, but I want to grab the best version
<apw> i was told that one worked ... for them, sounded like they tested on just one machine
<apw> so it might be worth asking for testing on it in that bug... 
<apw> i have little dea what the card even is, so as to whether we have them to test with either
<cnd> ok
<cnd> just wanted to know if you had inside information :)
<apw> cnd no nothing other than i was told the info and thought i would record it before i forgot!
<cnd> apw, I've sent a message to mythtv-users mailing list, I'm sure I'll get some good info there
<apw> cool ta
<Keybuk> oh, that's right
<Keybuk> KDSETMODE and VT_SETMODE are *totally different* ioctl()s that are both used on console devices
<apw> yay
<Sarvatt> Keybuk: are you messing with plymouth? I found some stuff regarding the sig quit and x restart after pressing enter the first time that might be helpful.. http://paste.ubuntu.com/382615/ shows it coming from the tty layer, 0x1c is the keycode of the enter and 0x1c is also the control-\ (quit) character, i'm guessing it might be the resetting of the isig flag on x's vt in plymouth might be doing it
<Sarvatt> suse/moblin is getting around it with this - http://suse-moblin.com/obs-status/Moblin:Factory/aaa_base/aaa_base-bootsplash.patch
<Keybuk> Sarvatt: messing a lot with it, yes
<Keybuk> X crashes because the enter causes getty to respawn
<Keybuk> which steals both VT_PROCESS and controlling terminalness away from X 
<Keybuk> and X doesn't like that
<Keybuk> (I'm sure getty's sttys don't help either)
<JFo> had tons of issues with that at SCaLE when testing key
<JFo> err Keybuk 
<JFo> <-tab complete fail
<JFo> :)
<Keybuk> "that" ?
<JFo> sorry Keybuk that == enter causing getty to respawn I think. It was freezing everything out. We had to use the on screen keyboard for our testing.
<JFo> unless none of that ^^ made any sense. in which case I shall crawl away quietly. :)
<Keybuk> lots of things cause that though
<JFo> hmmm
<Keybuk> enter killing X is a fairly common symptom of a lot of different problems
<JFo> well, it wasn't killing it so much as it was freezing the machine
<JFo> no input was possible
<JFo> I don't recall specifics but manjo and bjf were there 
<JFo> so they may be able to provide some detail where I cannot
<JFo> just wanted to mention it while the subject was warm
<apw> Keybuk, well crap .. guess what ... if your binary is called perf-xxx then perf assumes you meant perf foo and fails cause our version isn't a command ... you ok with perf_<version> or shall i rip that support out ... hrm
<Keybuk> yup
<Keybuk> can be an underscore
<Keybuk> can be any character you want except / and \0 ;-)
<apw> well yeah, just not as pretty ... sigh
<Keybuk> could be just perf2.6.32 if you like
<Keybuk> though will it not get confused by the - in kernel versions?
<apw> it checks for perf- literally so we should be ok there
<apw> perf2.6.32-15-generic perf_2.6.32-15-generic
<Keybuk> latter is nicer
<apw> yeah i concur ... sold
<manjo> tgardner, confused a little I did a git clone  git://kernel.ubuntu.com/ubuntu/linux-firmware.git and based my changes on that ... 
<tgardner> manjo, change to the lucid branch
<manjo> tgardner, is there a lucid specific branch?
<manjo> I see master 
<tgardner> git branch -a
<tgardner> git checkout -b lucid origin/lucid
<manjo> got it !
<manjo> tgardner, I put the license file as-is ... I am assuming it is ok to change the name to LICENSE.* ?
<tgardner> manjo, yep
<manjo> cool will send you a request pull this afternooon
<manjo> tgardner, any reason why many of them are spelled LICENCE ?
<manjo> and some LICENSE ?
<tgardner> manjo, David Woodhouse has normalized on the UK spelling, so follow his lead.
<manjo> tgardner, ok
<cnd> manjo: I thought the firmware was supposed to go into -nonfree?
<manjo> cnd, tgardner I talked to realtek into sending me a licence
<cnd> manjo: awesome!
<manjo> tgardner, request pull sent 
<tgardner> manjo, k, I'll get to it after my upgrade is complete (or has wrecked my life)
<manjo> tgardner, no worries as long as it and the patch makes it into lucid at some point 
<manjo> tgardner, it enables the Asus laptop that is on the radar for enablement, kevin shipped to me 
<manjo> although suspend/resume is broke coz of nvidia
<cnd> manjo: where'd you end up putting the fw?
<cnd> where the original driver expects it?
<manjo> where the driver wants it 
<cnd> cool
<manjo> although changing that behaviour is also trivial
<cnd> yeah, just easier for when we update the driver if there aren't any changes
<manjo> right
<manjo> we review ubuntu deltas only on new releases
<manjo> so won't happen until M
<manjo> I was thrilled when someone walked up to our booth and thanked us for adding omnibook module to kernel.. felt good 
<manjo> at SCALE 8x
<apw> tgardner, do you think i should call linux-tools something independant like linux-tools-common in case we end up needing an arch layer?
<tgardner> hmm
<tgardner> apw, I guess it won't hurt, but I'm having a hard time imagining what might require an arch layer.
<apw> if there was a tool which was a .c but somehow not version specific ... seems odd i know
<tgardner> apw, I'd say for Lucid just keep it simple. not much is gonna change between now and release.
<apw> tgardner, i guess we can rename it then should we need to
<apw> concur, linux-tools it is
<apw> tgardner, cking, http://pastebin.com/RZWcLJ2F
<tgardner> apw, huh, thats interesting stuff.
<cking> is that showing it works or what?
<apw> yeah, that you type perf and it works
<tgardner> cking, kind of looks like it
<cking> nice
 * cking looks forward to installing it and using it
<cnd> tgardner: I'm working on a fw-nonfree issue in karmic (and lucid soon)
<cnd> bug 363682
<ubot3> Malone bug 363682 in linux-firmware-nonfree "cx24116 firmware doesn't load - firmware corrupt" [Medium,In progress] https://launchpad.net/bugs/363682
<cnd> tgardner: what is the SRU process for something like this?
<tgardner> cnd, its not subject to SRU 'cause its not in main
<cnd> tgardner: ok, so what is the process?
<cnd> same as what I've been doing for -nonfree firmware for lucid?
<tgardner> cnd, just the usual. you make a package and get someone to sign and upload.
<cnd> tgardner: ok, what about jaunty as well? is that still recent enough for a fixed package to be uploaded?
<tgardner> cnd, frankly, I wouldn't fix firmware for anything more recent then Karmic
<cnd> tgardner: I think there are still people in the community hit by this bug in jaunty
<cnd> lots of people set up their mythtv systems and don't bother to upgrade after they get everything just right
<tgardner> cnd, and my philosophy is that its a desktop issue and therefore they should upgrade.
<cnd> tgardner: well, I don't mind packaging it up if it's not too much trouble on your end to upload it
<tgardner> cnd, fine, but in general I'm not interested in spending time on older releases. they are what they are.
<tgardner> LTSs are different, obviously.
<cnd> tgardner: ok
<cnd> (I already kinda promised on mythtv-users I'd look into jaunty too)
<apw> heh that doesn't mean we'll say yes though :)
<cnd> apw, I promised I'd look into it
<cnd> nothing more
<cnd> so I think I'm ok :)
<apw> always good to be ok :)
<apw> tgardner, that 'Add vlan' patch, will the installer include all .udebs or do those need to go into one of the network ones?
<tgardner> apw, I think its OK because its in package-list
<apw> tgardner, ok i'll get it in and see what happens .. ta
<tgardner> apw, gah, does that mean I sent a pull request from the wrong SHA1 'cause I already have that patch in my repo
<apw> tgardner, perhaps but i'll cope with it
<tgardner> apw, drat, sorry about that
<apw> i don't see it in your recent pushes
<tgardner> apw, in the xt_recent pull request
<apw> ahh will keep it in mind, will get there shortly
<cnd> manjo: might want to use git://kernel.ubuntu.com instead of ssh://zinc.canonical.com
<cnd> no one but canonical people can get to zinc I'd assume
<manjo> cnd, yep.. I keep doing that
<manjo> apw,  reminded me a few times already
<apw> manjo, iassume the commits remaining on lp530275 doesn't include the firmware ...
<manjo> yes
<manjo> that is correct
<akgraner> Keybuk, ping
<manjo> apw, I just sent an update to the fw to rtg 
<manjo> hopefully he will pick it up
<apw> manjo, a third update?  he replied about WHENCE
<manjo> yes 
<manjo> I did send him another pull request a few mts ago
<manjo> I cleaned up using dos2unix and updated whence
<apw> cool
<apw> manjo, when you send out pull requests it helps if they have either pull request or PATCH in the title, else its a pig to find them
<manjo> there are binary files in the diff (firmware)
<manjo> so I did not include the patch 
<RAOF> apw: Oh, of course!  The drm-backport kernel will have a new ABI number.  Forget what I said about breaks/replaces on linux-backports-modules-nouveau; they're unnecessary, because we won't *have* a -16 ABI version of them.
<manjo> and the driver had tons of files so did not inculde the patch as well
<manjo> apw, ah you said title 
<manjo> sorry did not read the full scentance 
<manjo> right noted
<tim> hi, i've upgraded one of my machines to jaunty ... compiling a custom kernel, it seems, that the initrd is not generated correctly, although i run make-kpkg --initrd ...is this a known issue?
<crimsun> apw: how would you like to shave ~15ms from the boot?  Is it worth a request-pull?
<crimsun> I suspect it would be lost in the noise, but...
#ubuntu-kernel 2010-03-04
<manjo> crimsun, I was trying to get you info on bug #528719
<ubot3> manjo: Error: Could not parse data returned by Malone: HTTP Error 500: Internal Server Error
<crimsun> the maintenance window for LP was just extended another 1,5 hrs
<manjo> do you want me to cat /proc/sound/... codec/* while capturing ? is this correct ? 
<crimsun> manjo: yes
<manjo> crimsun, also The front mic playback toggle is muted. Please adjust this accordingly.
<manjo> what does this mean ? 
<manjo> crimsun, sorry I am audio illiterate 
<crimsun> which bug was this?
<manjo> Launchpad is undergoing maintenance and is in read-only mode. You cannot make any changes. Please see the Launchpad Blog for details.
<manjo> Launchpad is undergoing maintenance and is in read-only mode. You cannot make any changes. Please see the Launchpad Blog for details.
<manjo> [LUCID] Aphla3 Acer AspireOne: Playback of audio recorded from external mic not loud. 
<crimsun> ah
<crimsun> amixer set 'Front Mic' unmute 
<manjo> crimsun, for my edu... what is 'Front Mic' stand for ? external mic input ? 
<crimsun> manjo: unfortunately that is ambiguous. It's supposed to mean the built-in mic if you have it.
<manjo> crimsun, awesome!
 * manjo learned something important today
<crimsun> it's unfortunate because it's the precise opposite in many cases :/
<manjo> crimsun, if I get a chance and you get some free time @ uds I would like to learn some basic audio debugging 
<crimsun> sure
<manjo> crimsun, that is very kind of you .. thanks 
<TheMuso> bjf and I were thinking of doing something audio related at UDS.
<crimsun> TheMuso: like a plenary?
<TheMuso> Since I've been learning a bit recently as well.
<bjf> TheMuso, we were? news to me :-)
<TheMuso> crimsun: No, more a session of "audio doesn't work, bring it here and we'll do what we can to fix it"
<crimsun> oh, that would be nice
<TheMuso> bjf: I vaguely remember saying such to you and Conor. Its not on record, so don't hold me to it.
<crimsun> (granted, that's what I end up doing at UDS anyhow)
<manjo> crimsun, luke I have few audio related bugs on netbooks that I have filed this week...
<TheMuso> crimsun: Right, with more of us knowing what the hell to do, we can get more done, and set asside some time where people can come to us to do it.
<manjo> s/luke/TheMuso
<bjf> crimsun, if you go I don't want you stuck fixing peoples audio the whole time
<TheMuso> manjo: Yeah saw those. Unfortunately I am not yet learned enough to help debug hda issues without access to real hardware.
<manjo> TheMuso, yep I have the HW, just need the knowledge 
<TheMuso> manjo: I think crimsun knows enough to do remote debugging, but I could be placing him on a pedistel.
<manjo> crimsun, ^
<crimsun> as long as there's the codec output at the time the symptom is seen, it's easier
<manjo> crimsun, where can I read/rtfm about codecs etc ? 
<crimsun> I've been inquiring whether there's a way to trawl through these alsa-driver/linux bugs to retrieve the codec output, because fixing the volume dB ineptitude is fairly straightforward from them
<manjo> crimsun, infact how can I disipher what alsa-info prints out 
<JFo> crimsun, I am interested in compiling some kernel audio troubleshooting pages if possible
<JFo> perhaps you me TheMuso and bjf can get our heads together at UDS
<crimsun> manjo: so the good/bad news is that it's the Azalia spec on Intel's web site
<manjo> crimsun, so that is a place to start ? 
<crimsun> manjo: the bad news is that you then need to download the data sheets for every existing codec from codec manufacturers' web sites
<crimsun> manjo: yes
<manjo> s**t 
<crimsun> JFo: sounds like a plan
<JFo> crimsun, cool
<manjo> JFo, remember we were talking about how to unmute the mic ? ... crimsun just gave me a command line option
<JFo> manjo, I saw that
<JFo> coolness :)
<crimsun> manjo: unfortunately that's actually a quirk
<manjo> crimsun, on most laptops/netbooks mic come muted by default 
<crimsun> manjo: if the codec were sane, it would be a capture toggle instead of a playback toggle
<manjo> crimsun, we have a kernel-qa testsuite for audio, right now it tests basic stuff, you can probabaly help me expand it by adding more tests... one thing I learned today is you need to cat proc/sound while recording, so I need to change the caputre test to do that 
<manjo> ie help me identify areas where I can write more test 
<crimsun> manjo: yes, I began updating it to account for an additional round based on negative results, i.e., unloading the existing drivers and loading a daily snapshot's
<manjo> crimsun, by default on a fresh install... SoundPreferences->Input is always muted ... is this some default in gnome ? 
<crimsun> manjo: presumably
<manjo> amixer set 'Front Mic' unmute  == Unable to find simple control 'Front Mic',0 
<manjo> crimsun, ^
<manjo> crimsun, amixer scontrol == does not list 'Front Mic' ... this is on a Asus EEPC
<crimsun> manjo: this is the same hardware as in bug 528719, correct?
<ubot3> Malone bug 528719 in alsa-driver "[LUCID] Aphla3 Acer AspireOne: Playback of audio recorded from external mic not loud." [Undecided,Incomplete] https://launchpad.net/bugs/528719
<manjo> no this is on a different one 
<manjo> crimsun, this is on ASUS 1201N
<crimsun> different hardware, different codecs, most probably different control elements
<manjo> eeepc
<manjo> ah!
<crimsun> would you pastebin amixer output, please?
<crimsun> 'amixer'
<manjo> doing ...
<manjo> crimsun, http://pastebin.ubuntu.com/387946/
<crimsun> in the current 1201N's case, it's due to 'Capture' being muted and 'Front Mic Boost' being zeroed
<manjo> crimsun, so I have to manually unmute it ... is there a command line option to unmute ?
<crimsun> amixer set 'Capture' cap && amixer set 'Front Mic Boost' 100%,100%
<crimsun> you probably want to increase 'Capture', too: amixer set 'Capture' 100%,100%
<manjo> wow magic
<manjo> crimsun, I have another one .. http://pastebin.ubuntu.com/387953/
<manjo> this is on a Acer aspire R1600
<bjf> crimsun, and you got that "Capture" was muted by seeing that "Front Left" and "Front Right" were "off"
<manjo> when I record sound all I hear is white noise 
<crimsun> bjf: correct
<crimsun> manjo: 'Mic' is zeroed and muted
<manjo> ah crap
<manjo> crimsun, I did 'Caputure'0 & 1 cap 
<manjo> ok let me try again 
<bjf> manjo, do you see in your pastebin where the 'Mic' is 'off'?
<crimsun> I would not be surprised if one or more of these need a more recent driver (you could verify with linux-alsa-driver-modules-foo from ppa:ubuntu-audio-dev)
<manjo> crimsun, ok let me try that .. 
<manjo> when I unmuted mic I get some constant white noise on the audio out 
<manjo> crimsun, so can we quirk this in the driver for each laptop ie unmute, set cap etc ? 
<crimsun> manjo: it doesn't appear to be a driver issue
<manjo> or is this some kind of user space quirk that needs to be done for each model laptop/netbok
<crimsun> manjo: I would start by seeing if it's a gnome-media (mixer applet) decision
<manjo> ic
<crimsun> we could unmute 'Mic', 'Front Mic', 'Capture', etc., but that could result in some pretty nasty feedback
<manjo> I assume they have some base config for each type of codec 
<crimsun> (the unmuting would be done in /sbin/alsa-utils)
<crimsun> right, there's the init db, too
<crimsun> (alsactl init)
<crimsun> manjo: in bug 531715, can you get amixer output while attempting capture, too?
<ubot3> Malone bug 531715 in pulseaudio "[LUCID] cannot record sound on Acer Aspire R1600" [Undecided,New] https://launchpad.net/bugs/531715
<manjo> yes
<manjo> its attached to the bug
<manjo> oh amixer output ? 
<manjo> just a sec 
<manjo> crimsun, attached 
<crimsun> Capture,1 is muted
<crimsun> amixer set 'Capture',1 cap
<manjo> crimsun, I did that, I also did Capture,0
<manjo> and boosted to 100%
<manjo> crimsun, do you want codec output after I do that ? 
<crimsun> manjo: no need. I presume that unmuting 'Mic' playback has no effect?
<manjo> crimsun, umuting the mic caused the audio out to produce a constant hissing noise 
<crimsun> manjo: ok, at least that works correctly.
<manjo> I have the output of codecs with capture 1,0 set to cap... 
<crimsun> manjo: can you try linux-alsa-driver-modules-2.6.32-15-generic from the ubuntu-audio-dev ppa?
<manjo> do you want me to attach that info ?
<manjo> yep
<crimsun> no need
<manjo> crimsun, rebooting with your ppa installed 
<manjo> crimsun, no luck
<crimsun> manjo: please rerun apport-collect 531715
<manjo> crimsun, updated 
<crimsun> manjo: can you verify the symptom without PA?  pasuspender -- arecord -Dplughw:NVidia -fcd
<manjo> doing 
<manjo> gnarl, lucid tree does not build for me
<manjo> gnarl, can you verify
<manjo> gnarl, I send apw a mail about it 
<manjo> crimsun, doing ... 
<crimsun> manjo: also, is it just capture that doesn't work?
<manjo>  crimsun only capture does not work
<crimsun> ok
<manjo> crimsun, with that command I don't hear any sound 
<manjo> crimsun, earlier I could hear something like a SW radio sound
<manjo> ie noise 
<crimsun> manjo: well, you shouldn't.
<manjo> ok
<crimsun> manjo: did anything garble across the terminal when you, say, tapped the mic?
<manjo> yes
<manjo> strange chars 
<crimsun> and only when you tapped it?
<manjo> ie non-printable chrs
<manjo> no always
<crimsun> but no noticeable change when you tapped it?
<crimsun> please check your mixer settings, too
<manjo> hmm... let me check again 
<manjo> crimsun, I think its pretty much random noise, but when I tap I do see some diff in pattern
<manjo> crimsun, what I could do tomorrow is get a different set of mic and test with that 
<manjo> probably this one has a bad pin... not sure 
<manjo> but this mic works for me with skype 
<crimsun> manjo: pasuspender -- arecord -Dplughw:NVidia -fcd foo.wav
<crimsun> should give you something audible in foo.wav
<crimsun> but I need to head off now
<manjo> yeah I tried that and there was silence 
<manjo> ok then catch you later 
<apw> damned document package is broken
<apw> Document /home/apw/build/lucid/ubuntu-lucid/debian/linux-doc/usr/share/doc/linux-doc/linux-doc-tmp/Documentation/DocBook/media.xml does not validate
<mgoetze> hi... could someone quickly explain the SRU process for me? there's a patch adding pci ids for broadcom 5716 chips, it already has one ack: https://lists.ubuntu.com/archives/kernel-team/2010-March/009099.html does that mean it will automatically be in the next sru, or is anything else missing?
<apw> mgoetze, it would need a second ack to get on the SRU track
<apw> though as i understand things once the current proposed moves there will be a security update before any new proposed kernel would be staerted, so i don't think there is any hurry
<mgoetze> apw: you mean there will be no non-security SRUs for hardy anymore, and it would need to sneak into a security update?
<apw> no not saying that at all.  saying that there is time yet to get any acks it needs
<matti> Hi apw 
<apw> hi
 * apw wins against doc-book
<tgardner> apw, bug #531981
<ubot3> Malone bug 531981 in ubuntu "[MIR] linux-qcm-msm" [Undecided,New] https://launchpad.net/bugs/531981
<apw> tgardner, thanks
<tgardner> apw, prolly don't need to get it in -meta just yet
<apw> tgardner, ack
 * apw has plenty of other poo to deal with
<tgardner> apw, i can take care of it when it finally pops
<apw> tgardner, heh whchever, its not a lot of work, but i'll get it on the tracker
<manjo> tgardner, so we are going back and forth on the firmware update... since there is no clear doc or wiki ... I am always missing things, I am trying to copy what already exists ... and even that is not consistent ... 
<tgardner> manjo, well, like I said, gimme some names and email addresses at least.
<manjo> tgardner, apart from who gave it to me how and when ... is there any thing else I need ? 
<manjo> tgardner, once I am through I will doc it in a wiki and you can cross check 
<tgardner> manjo, k
<manjo> tgardner, sorry about the mess
<tgardner> manjo, np
<apw> manjo, i assume there is no licencing issue with the driver itself
<manjo> apw, I got the licen"ce" from realtek
<manjo> just need doc who when where how 
<manjo> tgardner, I pushed the changes to whence file ... 
<manjo> tgardner, please ping me if there is any more bits missing I will be happy to fix them
<manjo> apw, we have the skype call ? 
<apw> not every other week
<manjo> apw, but I could probably skype you ? :)
<manjo> won't take more than 10mts or so 
<apw> as you wish
<manjo> ok ... skype you in a minute or so?
 * apw makes tea, make it 2
<manjo> apw, https://wiki.canonical.com/KernelTeam/manjo/status-2010
<JFo> I need to do something like that
<tgardner> apw, I have a generic hash library I'm thinking of submitting upstream, cause I couldn't find one anywhere else in the kernel. Do you suppose it would be like tilting at  a windmill?
<apw> the question will be, is it performant enough for any of the use cases which it fits
<apw> generic generally == slower ... and hashes are often in perf critical spaces
<apw> though people for rbtrees and the like in, so it can be done
<tgardner> apw, I've been using it in a couple of netfilter modules for 5-7 years. 
<tgardner> on single core Geods
<apw> you might approach peterz about it, he is into major optimised access for trees and stuff
<tgardner> apw, how about Andrew?
<apw> might have an angle on how to present it
<apw> he is a good conduit in for the code once it has traction as its not for anywhere in particular
<tgardner> apw, I've about got it cleaned of 2.4'isms. I'll run it through the k-t list so you guys can have a  look.
<apw> soudsn good
<tgardner> cnd, kudos on bug #530348, great sleuthing.
<ubot3> Malone bug 530348 in linux-firmware "e100: eth0: e100_request_firmware: Failed to load firmware "e100/d101m_ucode.bin" [Undecided,Invalid] https://launchpad.net/bugs/530348
<cnd> tgardner: thanks
<apw> cnd, yeah that was good work :)
<cnd> apw, thanks
<cnd> I learned all about the firmware upload process on both sides of the kernel divide and udev too :)
<apw> most excellent :)
<apw> now to get that into some debugging hints wiki pages 
<cnd> apw, true true
<JFo> yep yep... and let JFo know where they are cnd ;)
<cnd> JFo: kk
 * JFo adds them to the list to be included in the Kernel Team pages reorg
<apw> jjohansen1, pulled your apparmor update, ta.
 * cnd kills the OOM killer by adding a swap file
<JFo> cnd, that on the new mini or a bug?
<cnd> JFo: no, that's on my macbook with 2G of ram!
<cnd> swap partition was set to 750 MB by default
<cnd> it's not enough apparently
<cnd> evolution is a hog
<cnd> chrome (maybe?) is a hog
<hyperair> evolution is probably the one at fault.
<hyperair> for chrome you can see about:memory for how much it is actually using
<cnd> thunderbird is a hog
<hyperair> that i agree.
<cnd> (not that I run both thunderbird and evolution at the same time)
<hyperair> heh
<cnd> I usually stick with one of the mail clients until it start seizing up in an endless cycle
<hyperair> thunderbird takes up a lot of memory.  but evolution hangs over a bad network.
<hyperair> which is ridiculous
<cnd> then I flip to the other, that miraculously is fixed
<hyperair> lol
<cnd> this has happened about every 2 weeks for a month now
<hyperair> i got rid of evolution completely because it'd hang my panel whenever i clicked on the clock.
 * cnd contemplates using mutt or pine
<hyperair> that pile of crap ought to be rewritten from ground up.
<hyperair> evolution i mean
<cnd> do you think mutt or pine will sync with my google caldav calendars? :)
<hyperair> it's got features, but it hangs too damn much, and is completely dependent on the stability of the network and mail servers (and calendar servers) in order to not hang.
<hyperair> and do mutt or pine even have calendar features?
<cnd> hyperair: I don't think so...
<hyperair> yeah, see?
<JFo> cnd, I have been using the web interface
<hyperair> so we've got nothing that can replace it properly, and evolution is a pile of crap.
<JFo> it is all I have found so far
<cnd> JFo: for which accounts?
 * hyperair uses rainlendar for calendar features.
<JFo> the internal ones
 * JFo googles rainlendar
<hyperair> it's non-free.
<JFo> hmm
<hyperair> i'd rather have something that integrates into the gnome-panel's clock, *AND* not hang my panel.
<JFo> the option I was told about for using on my phone flattens them all
<JFo> I want them to be seperately accessible
<JFo> separately*
<hyperair> so use google cal
<JFo> I do
<JFo> :)
<hyperair> and so do i, so my solutions are all separately accessible
<JFo> I want something that makes sense and that is integrated with my e-mail
<hyperair> anyway what has email clients and calendars got to do with the kernel?
<JFo> <-spoiled :)
<JFo> nothing
<hyperair> JFo: sunbird.
<JFo> we digressed
<hyperair> wait a sec. not sunbird
<hyperair> lightning or something..
<hyperair> lightningbird?
<hyperair> @_@
 * hyperair -> bed
<JFo> night hyperair 
<JFo> :)
<hyperair> night =)
<dyek> Hi! Is Ubuntu 9.10's vmlinuz-2.6.31-16-generic using a compression algorithm other than gzip, such as LZMA?
<cnd> JFo: I just added https://wiki.ubuntu.com/KernelTeam/Firmware
<cnd> A few people were automatically notified, but the list doesn't seem to include you
<JFo> excellent
<cnd> you may want to add yourself
<JFo> yeah, I will subscribe to it
<cnd> well, half the team was notified :)
<JFo> heh
<cnd> JFo: I'm going to add it to the knowledgebase if the wiki stops being DDoS'd
<JFo> ok
<JFo> sounds good
<jk-> dyek: nope, gzip
<mozmck> compiled the karmic kernel from git today and it got almost done and failed with the following:
<mozmck> get_debug_info: Can't create a handle for a new debug session.
<mozmck> makedumpfile Failed.
<mozmck> make[1]: *** [install-generic] Error 1
<mozmck> make: *** [binary-generic] Error 2
<mozmck> what does that mean?
<mozmck> figured it out.  I disabled debugging in the config, so I had to add âno_dumpfile=trueâ before the build command
#ubuntu-kernel 2010-03-05
<crimsun> bjf: please bump alsa-driver-cod-karmic.git for -20.33 in -updates
<bjf> crimsun, sorry I missed that, will do
<crimsun> bjf: rockin', thanks!
<bjf> crimsun, give me a sec and I'll submit a new build
<mozmck> I keep getting 4 off these errors: drivers/usb/core/hcd.c:144: error: expected expression before '>>' token
<mozmck> all in hcd.c  when compiling karmic kernel from git.
<mozmck> anyone seen this before?
<JFo> mozmck, google is your friend
<mozmck> couldn't find anything on it.
<JFo> looks like a gcc issue maybe
<JFo> hmmm, or perhaps something to do with how you are compiling it
<mozmck> I don't know.  The time it worked I applied the patch I needed on master and compiled using "skipabi=true skipmodule=true no_dumpfile=true fdr binary-rtai"
<mozmck> Then I created a flavour for my changes and did the same and I get the errors
<mozmck> basically used the howto here http://blog.avirtualhome.com/2009/11/03/how-to-compile-a-kernel-for-ubuntu-karmic/
<mozmck> ok, I don't get the error it seems if I don't try to make my own flavour
<mozmck> when I try to install the headers package, it says I need linux-headers-2.6.31-21, which was not created.  how do I get this?
<mozmck> forget that, I didn't run binary-indep :(
<cnd> apw, I know this is hitting late, but do you have any thoughts on making hid a module?
<apw> we need to review the generall building in policy.  i hope to upload drm today, then we'll have a window monday to review that and make changes in time for thursday
<cnd> apw, sounds good
<cnd> apw, also, looks like 2.6.33 fixes some nvidia (binary) driver issues
<cnd> hopefully .33 drm contains the fix :)
<apw> but yes its all getting squeeky tight round here
<cnd> apw, if there's anything I can look at to help you out, let me know
<cnd> I'm just browsing bugs
<apw> cnd, wouldn't expect it to, drm is not used for nvidia binary driver as far as i know
<cnd> apw, I can still hope can't I?
<apw> heh you can ... 
<cnd> either way, I directed them to the red ppa
<apw> just don't bet any actual cash on it
<apw> cnd good plan
<cnd> and we can do some git bisecting to figure it out otherwise
<cnd> always better to have upstream work than have only a regression from a previous release
<apw> rtg some nice shiney new nvidia drivers just hit the archive
<apw> cnd, may be of interest to you too
<tgardner> apw, cool. I hope screen save starts working again
<cnd> apw, rtg, they've been using them already I believe
<cnd> these are the bugs where they still fail to resume in lucid (even after the chvt fix), and graphics corruption after resume
<apw> oh where didi you get them from
<cnd> I'm guessing they got them from nvidia
<cnd> yep, looks like they got them directly from nvidia
<cnd> they were perusing the changelogs to see if there was anything of note
<tgardner> apw, do these KVM patches on the k-t list fix the regression that you and smb were looking at yesterday?
<tgardner> the one kirkland was on about
<smb> tgardner, Probably not. That was fixed by reverting another patch
<apw> tgardner, the Pause-Loop ones?
<apw> those are enablement
<tgardner> apw, yeah, the pause-loop ones
<tgardner> k
<apw> and unrelated, i've reverted all the kvm ones in the security block till that is resolved
<tgardner> k, I saw those and wondered
<cnd> apw, where are manjo's suspend timing patches?
<cnd> in a lucid kernel yet?
<apw> in the next one i think
<cnd> are they in a kernel ppa I can point someone at to test with?
<JFo> probably his personal one
<apw> cnd check the changelog for red, i think they are in there
<cnd> apw, ok
<apw> [15232.884115] PM: late suspend of drv:uhci_hcd dev:0000:00:1d.3 complete after 1000.073 msecs
<apw> [15233.884098] PM: late suspend of drv:uhci_hcd dev:0000:00:1d.0 complete after 999.593 msecs
<apw> ...
<apw> [15234.680342] PM: resume of drv:i915 dev:0000:00:02.0 complete after 191.423 msecs
<apw> even seems to work!
<cnd> apw, yep, they're there
<apw> cnd, thats a 'red' kernel so it must be there
<cnd> has there been any thought as to pushing manjo's patch upstream?
<apw> i've cleaned it up a lot, and likely whats there is upstreamable
<apw> we have a bunch in there that i'll remind people about after freeze, i have a few myself
<cnd> apw, ok
<cnd> is this the general way things are done, get patches into ubuntu before freeze, then upstream them after when we have more bandwidth?
<tgardner> cnd, not really, but we're in a time crunch right now.
<cnd> tgardner: so we usually try to upstream in line with adding them to the kernel, but near freeze that may get delayed?
<tgardner> cnd, exactly
<cnd> ok
<tgardner> cnd, for the simple reason that patches do not usually make it through the upstream review process intact, so its  management hassle to revert an old patch, then apply the new one.
<cnd> yeah
<amitk> apw: what are you planning on for making HID a module? (Re: MultiTouchScreen Support thread)
<tgardner> amitk, we'll review it monday
<amitk> ack
<apw> perhaps we should have a mini-meeting on that subject monday ... and chose the things we thing arn't needed
<mozmck> is there a document showing how to create a new kernel flavour for karmic?
<manjo> mozmck, https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
<apw> mozmck, there was a new one added to lucid fairly recently which might help you get the right files
<mozmck> apw: a new flavour?
<tgardner> apw, https://bugs.edge.launchpad.net/ubuntu/+bug/531981/comments/6
<ubot3> Malone bug 531981 in ubuntu "[MIR] linux-qcm-msm" [Undecided,Fix committed] 
<apw> yeha i see it has been approved, though still awaits someone to actually do it
<tgardner> apw, I'll see about annoying the archive admin du jour
<manjo> apw, after an upgrade on my MIni10V booting up with out splash works, but with splash it boots to a black screen with grabage chars on it 
<apw> manjo, which upgrade
<manjo> apt-get distupgrade
<apw> may be 'luck' you may n
<apw> need to test it a few times
<apw> mine is current as of a hour ago and boots ok
<manjo> apw, are you running red on your 10v ? 
<apw> i am yes
<manjo> s**t
<apw> though i have just booted to -15 and that works too
<manjo> 32-16 ? 
<manjo> works for you ? 
<manjo> apw, I just emailed you a screen shot of what it looks like when it boots 
<manjo> apw, ok I found another thing ... while its booting if I press the shift key when it displays the splash screen it boots to gdm
<manjo> apw, otherwise I get what I showed you in the mail 
<tgardner> manjo, have you tried removing plymouth to see if its causal?
<apw> manjo, i see that about one in 10, and suspect plymouth racyness
<apw> hitting ctrl i think did it for me
<manjo> apw, also hitting enter on that blank screen also launched gdm
<manjo> tgardner, definitely looks like plymoth
<manjo> tgardner, removing splash it boots ok 
<tgardner> manjo, I've found tat it really sucks to have nVidia and plymouth
<manjo> tgardner, but this is on intel unfortunately
<tgardner> ah, that sucks even more since it _should_ work
<apw> faster machines hit it i think
<apw> we know there are plymouth issues outstanding
 * manjo is not digging the new color scheme either .. turned his windows purple 
 * manjo does hates that fact that all the buttons 0 - X are now on the left .. 
<cnd> what's the best way to do a git bisect on a mainline kernel?
<bjf> manjo, which theme are you using, I'm using "Ambiance" and the buttons are on the right
<manjo> bjf, did you upgrade today ? 
<cnd> is there some sort of debianized way of doing them?
<bjf> manjo, yes
<manjo> you probbly asked it to keep the original gnome cof 
<manjo> conf
<manjo> I asked it to replace it 
<bjf> manjo, no they were on the left and now are on the right, I'll update again
<tgardner> cnd, likely the easiest way is to just copy a prepared config, then build the normal way.
 * manjo out for lunch & phy therapy
<bjf> manjo, mine flipped back to the left again
<bjf> I guess the design team thinks they work for apple
<cnd> tgardner: is there anything special I need to do about an initramfs though?
 * cnd is used to doing everything manually ala gentoo
<tgardner> cnd, dunno, I've not done much outside of the debian way lately. you may be veering into uncharted waters.
<cnd> tgardner: hrm... well, I'll try stuff out and update wikis if needed
<cnd> tgardner: I should have looked on the wiki earlier, I think everything I need is there
<tgardner> apw, I'm working on an LBM firmware borkage, so don't go uploading it over the weekend before I push a patch.
<apw> tgardner, ok ... i was literally just about to drop it in the queue
<apw> i think we'll do another upload on tuesday for the HID etc changes so it could go in with those
<apw> i'll hold it for now anyhow, so get it to me as soon as you can as i'll be watching the upload over the weekend as it builds
<tgardner> apw, somehow we lost the iwlwifi firmware bits. still investigating.
<apw> probabally my fault when i updated wireless to the 2.6.33 bits
<tgardner> apw, i dunno, the firmware stuff should be version independent
<apw> but if it was in the wireless directory i may have stamped on it by accident
<tgardner> apw, no, the bits are in the firmware directory, so no clobber there
<apw> fair enough
<tgardner> apw, ah, here is the issue: /lib/firmware/2.6.32-15-generic
<tgardner> they should go into  just /lib/firmware
<tgardner> its just packaging
<apw> how can they they would conflict release to release
<apw> or do they 'replace' each otehr?
<tgardner> apw, lbm-iwlwifi-4965-2.ucode v.s. iwlwifi-4965-2.ucode
<tgardner> note the prefix
<apw> no i mean if we have -15 and -16 of LBM installed at the same time
<apw> tgardner, i have pushed up my updated LBM tree which you probabally should base of
<tgardner> good point. 
<apw> base off, as i changed the packaging to get rid of nouveau
<tgardner> k, I'll just change the driver swizzling to add the right path
<apw> perhaps i lost some swizzling in my changes
<tgardner> apw, no biggie, I'll have it figured out in a bit. I even have HW to test it on.
<apw> tgardner, if you get it done tonight send it out and i'll pull it in in the morning ... i want this stack done by monday if i can
<tgardner> apw, will do.
<apw> cool ... /me wanders off to find food
<cnd> tgardner: I think they should still be in /lib/firmware/`uname -r`
<cnd> apw ^
<cnd> if you look in /lib/udev/firmware.sh, it's smart enough to go looking there too
<tgardner> cnd, nah, you can have multiple LBMs installed and you are not allowed to trash files from another package
<cnd> and I think firmware under that directory comes from linux-image
<cnd> hmmm... let me read the backscroll more carefully
<tgardner> cnd, actually, I misread your comment. 
<tgardner> maybe I should review my udev rules.
<tgardner> cnd, where did you find that firmware udev rule in the bug report yesterday?
<cnd> the rule itself is /lib/udev/rules.d/50-firmware.rules I think
<cnd> but what you are probably interested in more is /lib/udev/firmware.sh:
<cnd> FIRMWARE_DIRS="/lib/firmware/updates/$(uname -r) /lib/firmware/updates \
<cnd>                /lib/firmware/$(uname -r) /lib/firmware"
<cnd> so lbm packages (I think this is what you're looking at?) should be putting them into /lib/firmware/updates/$(uname -r)
<tgardner> cnd, hmm, I only have a binary /lib/udev/firmware
<cnd> tgardner: what's your rule in 50-firmware.rules?
<cnd> are you running karmic?
<tgardner> cnd, lucid
<cnd> tgardner: I've been working in karmic, as was the e100 issue
<cnd> maybe it's changed?
<tgardner> cnd, looks like
<cnd> yep, I'm taking a look at my lucid partition
<cnd> tgardner: how much you want to bet firmware.sh was made native for boot speed :)
<tgardner> cnd, ./udev-151/extras/firmware/firmware.c
<cnd> tgardner: still looks like the same paths are used
<tgardner> cnd, looks like the search paths are /lib/firmware/updates/ and /lib/firmware/
<cnd> tgardner: with the possibility of the kernel release added on
<cnd> tgardner: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/firmware/firmware.c;h=16455dec8f3299ef2283ce1382ad1cb1d99a0cb4;hb=HEAD#l137
<cnd> or just look at line 137
<tgardner> cnd, so, you think it'll decend into  /lib/firmware/updates/ ?
<tgardner> ah, yuo're right
<tgardner> I can test that soon enough
<cnd> tgardner: so that's everything you needed to fix your issue?
<tgardner> cnd, I think so. I'll know soon enough
<cnd> cool
<tgardner> cnd, since you're fresh on udev, remind me how to enable debug. 
<cnd> tgardner: https://wiki.ubuntu.com/KernelTeam/Firmware :)
<tgardner> tahts right, I remember seeing your page go by
<cnd> let me know if there's any other info you need or if something's not clear
<cnd> I suppose it will need to be updated for lucid...
<Keybuk> tgardner: udev should look in /lib/firmware/updates/$(uname -r)/FW
<tgardner> FW?
<tgardner> Keybuk, oh, you mean /lib/firmware/updates/2.6.32-15-generic/lbm-iwlwifi-4965-2.ucode
<Keybuk> yes
<tgardner> Keybuk, the log shows FIRMWARE=lbm-iwlwifi-4965-2.ucode, so the names appear to be correct
<tgardner> lemme make sure it can find it if I copy to /lib/firmware
<cnd> tgardner: Keybuk: what's going wrong?
<cnd> the firmware is in the right place, but still isn't getting loaded?
<tgardner> cnd, shit, I may have trashed my drive.
<cnd> tgardner: heh, how'd that happen?
<tgardner> modprobe -r iwlagn, then hard power cycle after it wedges
<tgardner> even recover locks up
<tgardner> recovery*
<tgardner> it must suddenly be lunch time
<cnd> tgardner: boot from an iso and fsck?
<cnd> tgardner: if you want me to look into an issue for you while you fix your drive let me know
<tgardner> cnd, I'll get it figured out eventually. don't worry about it
<cnd> ok
<cnd> apw: how is your mainline ppa generated?
<cnd> I'm wondering if we should have a compat-wireless mainline ppa as well for people to test with
<manjo> bjf, looking for me ? 
#ubuntu-kernel 2010-03-06
<zetheroo> what does it take for a bug fix to get incorporated into the official kernel?
<lifeless> do you mean linus' tree ?
<zetheroo> do I?
<zetheroo> I think what I was meaning was the Ubuntu kernel
<tgardner> apw, no joy on the LBM firmware issue yet. the 2 patches I pushed are righteous, but neither actually fix my problem. More digging tomorrow. 
<cnd> apw, you around?
#ubuntu-kernel 2010-03-07
<bjsnider> is the generic ubuntu kernel compiled with this option: CONFIG_VIDEO_V4L1_COMPAT
<MTecknology> bjsnider: ya
<MTecknology> bjsnider: grep CONFIG_VIDEO_V4L1_COMPAT /boot/*
<bjsnider> well oh my goodness that's funny
<bjsnider> piece of garbage software corked off during make because of missing symbols that sound like they're part of that
<MTecknology> bjsnider: I'd love to help you more but I'm fighting me own kernel issues - trying to move my custom kernel from karmic to lucid :(
<MTecknology> Anybody able to help me figure out what's causing this error?
<MTecknology> http://paste.ubuntu.com/390093/
<cj> bug 533690 is mine in case anyone needs to ask questions
<ubot3> Malone bug 533690 in linux "ASUS G60J keyboard backlight brightness hotkeys don't work" [Undecided,New] https://launchpad.net/bugs/533690
<Sarvatt> what's the proper method to add a patch to the kernel source and increment the version for a PPA? patching and changing the version in debian/changelog to say 2.6.32-15.22+bugx or 2.6.32-15.23~bugx doesn't build the package right
 * Sarvatt has always used make-kpkg and hasn't wrapped his head around the ubuntu kernel build system
<Sarvatt> this guy needs a kernel patch i've attached to the bug to see if it fixes his bad acpi lid status problem - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/507196
<ubot3> Malone bug 507196 in linux "[i945gme] Ubuntu falls back on vesa driver (no screens)" [High,Confirmed] 
<crimsun> Sarvatt: git-request-pull(1)
<crimsun> Sarvatt: (and yes, working with git directly is preferable to debdiffs against source packages)
<Sarvatt> i attached git formatted patches on that bug and didn't request a pull because I need him to verify that they even work first, ubuntu-lucid.git didnt have a debian/ though so I wasnt sure how I would generate that properly
<crimsun> err, what?
<crimsun> there's very clearly a debian/ in ubuntu-lucid.git
<Sarvatt> ah sorry it was that there was no debian/changelog
<crimsun> see debian/rules.d/1-maintainer.mk
<Sarvatt> thanks crimsun, that helps alot
<crimsun> yw
<MTecknology> I just bumped myself up to 10.04. I'm tryingto use the same .config I was using before. I just ran make oldconfig and accepted all the defaults. I get this error during compile and I don't know how to fix it. Any smart people tips?  http://paste.ubuntu.com/390093/
<Sarvatt> might want to take the lucid .config as a base and customize it again since alot of things have changed since the karmic one (and dont expect most staging stuff from upstream linux-2.6 to compile right now)
<MTecknology> Sarvatt: alrighty. I just didn't want to recreate it because I spent > 200 hours getting this one :P
<MTecknology> Sarvatt: thanks
#ubuntu-kernel 2011-02-28
<apw> smb, morning ... this amd quirk, can you remind me of the bug for that one
<ricotz> apw, hello, could a patch like this be considered for inclusion? https://patchwork.kernel.org/patch/244201/
<apw> ricotz, is the patch upstream yet?  and in part the answer depends on where you are looking to put it
<ricotz> apw, this patch isnt upstream, and the current natty kernel (38rc6) breaks the usage of my dvb card, including this patch solved it for me
<apw> the patch doesn't claim for fix anything, just speed things up ... so thats a little unexpected
 * apw drop for a few mins
<ricotz> apw, yes, the current driver gives me timeouts when switching channels/transponders mostly everytime, so this "speed-up" patch solved it for me
 * apw sighs ... 
<cking> wassup?
<cking> more plumbing probs?
 * cking has to reboot
<apw> heh ... no this is the 'fix' for the problems
<cking> ah
<apw> but the plumber was late, so i was waiting around like a lost puppy
<smb> apw, Though we thought they *had* been fixed already
<cking> that are a law to themselves
<apw> no _i_ bodged it till it could be fixed
<smb> Hm, old plumbers law: first it bodges then it comes off
<apw> smb, something like that :)
<ara> Hello all!
<ara> does the regression found in the -proposed kernel for ec2 invalidates this kernel in -proposed?
<ara> https://bugs.launchpad.net/bugs/723335
<ubot2> Launchpad bug 723335 in linux "linux: 2.6.35-27.48 -proposed tracker" [Medium,Triaged]
<ara> apw, ^ ?
<smb> ara, Hm, is that another one than bug 725089?
<ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
<ara> smb, no, that one
<ara> smb, the one above is the tracker, the bug is the one you mention
<smb> ara, I will try to get to the bottom of that today
<ara> smb, cool, if the regression is confirmed, then the linux (not linux-ec2) package will also be dropped?
<smb> I looked at it on Friday and was not sure what could have caused it. Actually it seemed that the kernel before that may already have been causing issues
<smb> ara, Unfortunately for Maverick there is no ec2 package
<apw> smb, so would that be -virtual which has failed then ?
<smb> We use the virtual image generated from the normal linux package
<smb> In some way yes.
<smb> But I am not sure one can fail virtual without failing the main package.
<apw> smb, indeed if -virtual is toast they all are
<nusch> I'm trying to examine some regression with alsa or kernel, what is fastest way of finding it, shoud I install different kernels from packages or compiling from source? I read it can be done with git bisect but could I use git with ubuntu kernels compiled like this https://help.ubuntu.com/community/Kernel/Compile? Or should I use this method  https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<apw> nusch, i would start by picking the pre-build kerenls from launchpad
<apw> to narrow it as much as possible, then probabally try the mainline builds for finer bisection in between
<apw> nusch, which release as this appeared and when?
<fairuz> dma_addr_t dma_map_single (struct device * dev, void * cpu_addr, size_t size, enum dma_data_direction dir);  .. is cpu_addr a physical addr?
<apw> fairuz, looks like a kernel virtual addy to me
<nusch> apw: I'm talking about this bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/662009 and somebody already found this was broken between 2.6.33  and 2.6.35
<ubot2> Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged]
<nusch> so I wanted to examine it deeper
<apw> nusch, so i would seee if .33 and .35 mainline builds show the same pattern
<apw> and then use the -rc builds in the mainline archive to find a finer location
<apw> quicker than building ones own
<nusch> Could you provide m with some details how to do that?
<apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
<apw> that has the docs on where to find them and how to instal them etc
<nusch> ok and should I install also new alsa package like this from ppa linux-headers-alsa-driver-2.6.35-25-generic with kernel version included or get rid of it and use standard ubuntu ones ?
<apw> i'd not expect the headers to make any difference to a sound issue
<nusch> sory I meant linux-alsa-driver-modules-2.6.35-25-generic
<nusch> those are from ppa:ubuntu-audio-dev/ppa
<apw> well that only applies to 35-25, so as long as you arn't booting that you won't be using it
<nusch> I'm saying about whole set of packages from ppa:ubuntu-audio-dev/ppa which has version number included in name, so It will need installing new alsa with every kernel, or should I uninstall it and allow system use standard packages
<diwic_afk> nusch, when you're git bisecting, make sure this package from ubuntu-audio-dev is NOT installed.
<apw> if you are looking for a general bug in the kernel, you don't want any unecesary packages like that
<apw> they just add variables you don't need
<nusch> But I'm not sure the problem exists in kernel or alsa modules
<apw> well from a kernel point of view, it includes alsa, and its that one we care if it works or not
<nusch> ok thx, I'll inform you after testing
<jk-> apw: any thoughts on the baseCommitRegex stuff?
<apw> ?
<apw> jk-, where?
<jk-> kernel-team
<smb> apw, In those rfc mails you tend to ignore ... ;-P
<apw> nthing with that in the title
<jk-> [RFC, PATCH 0/2] UBUNTU: lucid: allow printchanges to accept varying release commit messages
<jk-> smb :)
<smb> jk-, Not that I did much more response. I think the only thing I had was that if we start to change it should be Natty and then potentially go back, but that was already said
<apw> well i don't see any inherant issue with them, though what form are you using thats not being picked up
<jk-> smb: yeah, that's fine; I was starting with lucid because that's the kernel I was most recently working with
<jk-> apw: "UBUNTU: (Release) 2.6.35-6.11 for <project>"
<apw> so if you used "UBUNTU: <project> release 2.6.35-6.11" it would work as it is
<apw> so if you used "UBUNTU: <project> release Ubuntu-2.6.35-6.11" it would work as it is
<jk-> I'll check with Ike about why he's used the different format
<apw> jk-, but overall nothing bad in there.  i've replied as such and mentioned the flexibility we do have with the current pattern
<jk-> apw: ok, cheers. I'll sort out our commit conventions and get back to you
<apw> jk-, it doesn't seem like a bad change overall ... the branch specific file could be useful without your use
<apw> might simplify some of our existing stuff
<_ruben> any clues on how i could persue this issue: http://pastebin.ubuntu.com/573509/ .. apparently using "local my.ip.ad.dr" when creating a sit tunnel "breaks" the link local (/128 instead of /64)
<smb> sconklin, Hm, I found one line on irc from Thursday where jj mentions regressions for Lucid and Maverick. But not which those are. I cannot remember anything about Lucid (beside some load accounting problems maybe which seem to come and go). But we should ask him when he comes online.
<sconklin> ok, thanks!
<sconklin> by the way all - high winds and bad wx here, so if I drop offline that's why
<JFo> bjf, you have likely noticed by now, but I got your nominations done on bug 723945
<ubot2> Launchpad bug 723945 in linux-ti-omap4 "CVE-2010-4258" [Undecided,New] https://launchpad.net/bugs/723945
<bjf> JFo, heh, thanks!
<JFo> bjf, my pleasure
<smb> jjohansen, Hey sconklin refreshed my memory today about you mentioning regressions on ec2 in Lucid and Maverick. But I cannot remember what the regression in Lucid was. Do you still remember?
<jjohansen> smb: yeah, just a sec I am looking up the bug #
<jjohansen> smb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725310
<ubot2> Launchpad bug 725310 in linux "Lucid 2.6.32-29.58 /dev/mem is readable (dup-of: 725308)" [Undecided,New]
<ubot2> Launchpad bug 725308 in linux "Lucid 2.6.32-29.58 /dev/mem is readable" [Undecided,New]
<jjohansen> and I have really started looking at it yet
<smb> not? :)
<jjohansen> smb: yes NOT
<jjohansen> :)
<jjohansen> smb: I did start looking into https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725089
<ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New]
<jjohansen> which is the maverick bug
<smb> jjohansen, I did sort of do that too
<jjohansen> smb: ah okay :)
<smb> jjohansen, Seems I was able to boot the latest proposed kernel there
<smb> Though I think I discovered another regression (but that is old)
<jjohansen> smb: oh which regression is that
<jjohansen> oh nm its in your bug comment
<smb> jjohansen, I noted in the bug report. But it seems running "reboot" in the instance does not work
<smb> yeah
<smb> Or I am not patient enough for it
<smb> But it seems to be consistent with what I see on my local test system
<smb> For a Lucid image I can do a "xm shutdown" and the domU goes away
<smb> For a Maverick image I do the same and it stays around until I do a "xm destroy"
 * smb thinks the reboot / halt vectors may probably need better handling
<jjohansen> hrmm, yeah
<smb> But as said, this is something that probably came with the change from Lucid to Maverick
<jjohansen> apw: any reports of wireless just dying with the newest kernels
<apw> jjohansen, no that have reached me no
<jjohansen> apw: hrmm, I have had my wireless just die a couple times since upgrading friday
<apw> what h/w you got ?
<jjohansen> intel 4965
<apw> hrm pretty common
<apw> i wonder if you got some upgraded firmware recently
<jjohansen> hrmm, unlikely I haven't upgraded the firmware package
<sconklin> smb, jjohansen: so is it correct that we should not hold the maverick kernel for ec2, and that we should Lucid until further notice from jj?
<jjohansen> apw: it could have an anomally, if it happens again I will file a bug
<jjohansen> sconklin: uh no give a little bit more with maverick, I want to double check
<herton> apw, one more bug I noted to be marked as fixed by latest natty rebase: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722925
<ubot2> Launchpad bug 722925 in linux "bug on fs/inode.c:1422" [High,Triaged]
<smb> sconklin, jjohansen The Lucid thing could just be again something that never was working in ec2 (due to the duplicate files)
<apw> jjohansen, icirtianly worth watching, not someting i have heard from anyone else yet
<herton> apw, same reporter confirmed the fix at upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=29792
<ubot2> bugzilla.kernel.org bug 29792 in Block Layer "BUG: fs/inode.c:1422 when deleting device-mapper devices" [Normal,Closed: duplicate]
<jjohansen> smb: all of qrt was definitely passing on lucid and maverick, the question is when kees added the test that is failing last year
<jjohansen> smb: I couldn't remember, so the failure could have always been there
<jjohansen> I was going to boot an older instance to test if it was there
<jjohansen> to determine whether it was a regression or not
<sconklin> smb, jjohansen: could you please send me an email with as detailed a status as you have - I need to keep everyone informed on this, as we're slipping until this is resolved. I've forwarded Stefan's earlier status to you so you can build on that
<smb> jjohansen, Yeah, sounds good. Let me check something quick
<apw> herton, thanks for the pointer ... helpfiul
<apw> herton, marked in the changelog
<herton> cool
<apw> herton, bug -> Fix Committed
 * apw notes herton is reading a lot of bugs :)
<herton> great, thanks
<herton> yeah, trying to follow them :)
<kees> jjohansen: let me know if I can help with the qrt thingy
<jjohansen> kees: will do
<kees> jjohansen: fwiw, the SECCOMP test was added roughly in May 2009
<smb> Question would be whether we ever saw it ok with xen... Or just went meh...
<smb> ... seems to check devmem_is_allowed and that is defined in init.c... for which xen has a copy...
<kees> which bug is thiat? devmem not working or seccomp killing it?
<smb> kees, jjohansen So there is a difference here. The x86 code says "if (!page_is_ram(pagenr)) -> ok" while xen has something like if the page is beyond the given pages, then it is ok"
<smb> if (mfn_to_local_pfn(pagenr) >= max_pfn)
<jjohansen> smb: hrmmm, interesting
<kees> smb: the devmem checks we never validated on Xen, that's for sure. and those were added in Oct 2010
<jjohansen> kees, smb: yeah I think we haven't run qrt since devmem checks were added
<jjohansen> err that is on lucid
 * jjohansen isn't sure because he does remember running qrt last fall for some other bugs around that time frame
<kees> jjohansen: yeah, I don't think the devmem test was run on Xen. again, it's likely my test sucks. :)
<kees> jjohansen: I'm trying to work up a more definitive test. right now it's a bit "just try a whole range of addresses"
<smb> Well at least it may not take into account xen strangeness or xen needs some tweaking
<jjohansen> kees:  is brute forcing the address space again :)
<smb> But either way. I also thought to have seen something fail on Lucid before
<kees> jjohansen: hehe
<jjohansen> smb: really, my recollections of xen qrt are that it was clean
<jjohansen> that is one of the things we made sure of before the release
<jjohansen> but there have been a few tests added since then, and those recollection are a lot more fuzzy
<smb> jjohansen, The only thing one can be sure of is that one cannot be sure...
<jjohansen> smb: yep
<smb> Probably we quickly can check that with a current ec2 instance for Lucid. The latest kernel should not be in there. If the test fails too, then its at least not a new regression
<smb> And the SECCOMP thing seems to be something that not always happens too. But feel free to get it a second try
<apw> smoser, hey ... you have a bug open which is getting dogpiled, and as reporter i'd like your feedback: bug #625364
<ubot2> Launchpad bug 625364 in pm-utils "lenovo/thinkpad R500/T6x/T400[s]/T500/W500/W700/X60/X200 suspend fails" [Undecided,Confirmed] https://launchpad.net/bugs/625364
<smoser> apw, i think there are 2 bugs there in the dogpile
<smoser> one is the tpm bug
<smoser> one is, i think intel video related
<apw> smoser, tend to agree.  if you are working though i want to close out the tpm bit you were suffereing
<apw> so i can get them to make new ones
<jjohansen> smb: that is what I am doing, I fired up some fresh instances and am giving it another test
<smoser> my T400 was suspending and resuming fine in natty.
<kees> smb: oh, also note that I disabled the /dev/mem check on ec2 for the time being
<smoser> i was sufffering i think from the intel video bit.
<smoser> i haven't suspended and resumed a lot in several upgrades on natty
<smoser> but it *was* working when i originally jumped to natty
<apw> yeah we've had a number of bugs come and go
<apw> cking, did you find that patch ?
<cking> apw, the S4 one?
<apw> cking, yeah
<nusch> I asked afternoon about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/662009
<nusch> I tested it on my Y530, and last working kernel-ppa version is 2.6.34.7-maverick and in 2.6.35-rc2-maverick which is next it's already broken - I hear music very silent when I connect external speakers and set them to full volume. What next, should I download git version of those or test vanilia kernel?
<ubot2> Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged]
<jjohansen> bjf, sconklin: neither are regressions release the kernels
<sconklin> jjohansen: ok, thanks. Are they bugs which are not regressions?
<jjohansen> sconklin: correct I sent an email with a little more detail
<jjohansen> very little more
<sconklin> jjohansen: thanks much! We'll crank the machine back up ;)
<jjohansen> sorry it took so long the one really did look like a regression, passed on old first time I tried failed, on new started bisecting and then it just got weird
<bjf> JFo, if you could bless bug #726796, i'd be so grateful 
<ubot2> Launchpad bug 726796 in linux "linux: 2.6.35-28.49 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/726796
<apw> bjf, approved
<bjf> apw, thanks
#ubuntu-kernel 2011-03-01
<fairuz> how to use dma functions to flush caches?
<fairuz> simple question, we use > to write the output to a file
<fairuz> how to append the output to the existing content of the file
<apw> fairuz, >>
<fairuz> apw: ok ty
<_ruben> weird .. the link local address "oddity" with sit tunnels i see also on an old SLES9 box (2.6.5 based kernel) .. yet my sixxs interface (created by aiccu) doesn't seem affected somehow .. bah
<fairuz> i use flush_cache_all() in kernel space to flush L1 cache, do similar function exist in user space?
<smb> apw, In a quiet minute, maybe you have a pointer for that booty thing you mentioned
<apw> commit 299c56966a72b9109d47c71a6db52097098703dd
<apw> Author: Don Zickus <dzickus@redhat.com>
<apw> Date:   Mon Feb 7 23:25:00 2011 -0500
<apw>     x86: Use u32 instead of long to set reset vector back to 0
<apw> smb ^^
<smb> apw, ta
<smb> apw, Looks like one of those things you hope other people know what they are doing. When setting its done high, then low. And when resetting its just writing 32bit, which would be low, then high...
<apw> i think that in thory we can spin on it not being 0 or something, so there is magic going on
<smb> It is probably so old magic, that it might be documented in my ancient tome of pc internals... :)
<apw> heh yeah.  i think on reset they jump to a routine which is doing:
<apw> while (!reset_vector);
<apw> *reset_vector()
<nusch> I asked yesterday about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/662009
<nusch> I tested it and last working kernel-ppa version is 2.6.34.7-maverick and in 2.6.35-rc2-maverick which is next sound it's already broken. What next, should I compile kernel from git?
<ubot2> Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged]
<nusch> I asked yesterday about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/662009
<nusch> I tested it and last working kernel-ppa version is 2.6.34.7-maverick and in 2.6.35-rc2-maverick which is next sound it's already broken. What next, should I compile kernel from git?
<nusch> I asked yesterday about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/662009
<nusch> I tested it and last working kernel-ppa version is 2.6.34.7-maverick and in 2.6.35-rc2-maverick which is next sound it's already broken. What next, should I compile kernel from git?
<apw> ?
<apw> argle
<nusch> I asked yesterday about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/662009
<nusch> I tested it and last working kernel-ppa version is 2.6.34.7-maverick and in 2.6.35-rc2-maverick which is next sound it's already broken. What next, should I compile kernel from git?
<ubot2> Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged]
<apw> nusch, yes we saw that the previous 3 times you said it too!
<apw> as you have now a small range v2.6.34..v3.6.35-rc2 on mainline it seems appropriate to do a bisect between them
<nusch> apw: sopry my irc client is bugged id didn't show send message after presing enter
<nusch> and is there a way to not compiling it such long? I left compilation of Ubuntu-2.6.35-1.1 for night, and after few hours it stopped due to no space left on hdd.
<nusch> I'm compiling with this line DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 skipabi=true fakeroot debian/rules binary-generic am I compiling more than my amd64 architecture or this is normal?
<nusch> Also is there a method to shorten compile time while switching betwwen git tags - to not compile again modules which didn't changed ? Are there such modules ?
<apw> nusch, what are you trying to compile on
<apw> i have some faster kit i could do a build on for you
<apw> and what release are you running
<nusch> maverick
<apw> nusch, ok so v2.6.34 is good and v2.6.35-rc2 s bad ... correcet ?
<nusch> yes
<nusch> or maybe I should also test compiled vanilia kernels to test if the bug was introduced by ubuntu o r kernel maintainers?
<apw> you tested the ones in the mainline archive i pointed you to right ?
<nusch> yes
<nusch> and this http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc2-maverick/CHANGES says only 2 people were involwed in snd_hda_intel 
<apw> nusch, ok so you did test virgin upstream builds, those have no ubuntu ness applied to them
<apw> nusch, are you 32 or 64 bit ?
<nusch> so if the bug was introduced by ubuntu devs it should be quite easy to locate
<nusch> no
<apw> no?
<nusch> I tested ones from  http://kernel.ubuntu.com/~kernel-ppa/mainline
<apw> right ... those _are_ mainline virgin builds without any ubuntu sauce
<apw> that is the point of them, they don't have anything we do applied so we can tell if its our fault
<apw> 32 or 64 bit builds ?
<nusch> so why they have maverick in the name ?
<nusch> 64
<apw> because that tells me which configuration was used, which release they are most likely to work on
 * apw notes that this is described in the faq
<nusch> ok, so I used thos virgin build from there for 64bit and only tagged as maverick
<apw> thats fine, we can do this using bisect from here
<nusch> should I continue Ubuntu-2.6.35-1.1 build or wait for your script ?
<apw> nusch, normally it takes about half an hour a build here, so i shouuld have something to test in that kind of time
<apw> nusch, this is a sound issue right?
<nusch> yes
<nusch> ahould I also do something with alsa?
<apw> i think a bisect is our best hope, it says 207 revisions to test, 8 steps so it shouldn't take forever to get through
<nusch> so simpy I should compile every time tag good/bad with bisect and compile again until I find revisions ? And shouldn't I compile alsa also every time ? Doesn't alsa need to fit currently running kernel ?
<apw> nusch, alsa is part of the kernel
<apw> and nusch i was volunterring to use my fast build box to make the kernels for you
<nusch> I'd be grateful
<nusch> and what's  about userspace as alsamixer, I had issue that after installing new kernel all channels in sound card were muted so I need restore it once
<apw> nusch, yep it often does that, you'll need to check the basics like that every time
<nusch> So i need to compile alsa-tools also ?
<apw> no you should need to do nothing other than check the mixers are not muted when testing the kernels i provide
<nusch> ok
<apw> nusch, ok first test kernel at: http://people.canonical.com/~apw/bisect-maverick/
<nusch> ok, I don't have any irc bnc so I'll be back after testing
<nusch> \query apw the one you provided is ok, waiting for next
<apw> nusch, ack
<apw> nusch, ok second set there ( the later numbered ones in the same place)
<nusch> apw, this one was bad
<apw> nusch, ack
<apw> cking, smb how does this look: http://people.canonical.com/~apw/misc/key.html
<cking> great. Should "critical" be red and "high" be orange?
<apw> cking, oh the colours are someone elses fault :)
<apw> but possibly, i got distracted before i pointed out the change
<apw> wh
<apw> which is to include all tasks of a bug, but sqashed on status where they match, se 600453 as an example
 * cking looks
<apw> nusch, next one is up
<nusch> apw, thx I'll check
<nusch> apw, this one is broeken in early boot, last message it says is usb 2-5: new high speed USB..
<nusch> no errors or, warning, i unplugged all usb but know my laptop camera also uses USB bus
<nusch> after presing ctrl alt del  i get md: stopping all md devices and blinking curor - at this stage even SysRq doesn't work
<nusch> apw, I must left for a while, if it won't be a problem please prepare more than one most probable build, I'll test all and provide you with results
<apw> nusch, thats annoying as we don't know whether it is good or bad to tell bisect
<apw> nusch, two new builds in the bucket ... please test both and report back
<fairuz> the function flush_cache_all() flushes all cache or only L1 cache?
<fairuz> it's from asm/cacheflush.h
<nusch> apw, first of these also not booting to the end, testing second
<apw> nusch, bah thats most unhelpful as it provides no information
<nusch> but did you changed anything, i tested some times ago one of the most recent kernels in mainline build and it booted to the end (without sound)
<nusch> I'll try second one, be back in a moment
<apw> nusch, those two are as if the former one was bad and good respectivly
<apw> as the original did not boot far enough for us to know
<nusch> apw, second one did boot
<nusch> but no sound
<apw> crap that is worst outcome as we have no idea where the good has gone
<nusch> i mean bisect201103011259 booting, no sound, bisect201103011238 not booting can't check
<apw> yep, indeed the worst possible combination of results
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<apw> nusch, ok we are likely wasting our time here, with such a big hole in the bisect, but here is another one to test
<apw> nusch, let me know if it works or not
<JFo> apw, we aren't done with alpha 3 yet are we, just in the freeze bit?
 * JFo brain isn't cooperating today
 * JFo digs for the schedule
<apw> yeah we are frozded for it
<apw> as of today, releasing thursday
<JFo> k, thought so
<JFo> thank you sir :)
<apw> bjf,  i have some further updates for lpltk for your consideration: lp:~apw/arsenal/python-launchpadlib-toolkit-milestones-etal
<apw> bjf, been playing with the task oriented view of our tasks, ending up with a hybrid which collapses common status: http://people.canonical.com/~apw/misc/key.html
<apw> bjf, note 600453 has two nominations, what do you think
<apw> manjo, about?  did you get a chance to test the natty pre-proposed kernel; to confirm it fixes your s/r issues
<bjf> apw, looking it over, looks pretty good, personally, the "Summary of bugs" at the top just wastes space and I don't care about "Closed bugs" but they are at the bottom and I can ignore them
<apw> bjf, not really sure myself what we use that for, i've not touched that bit yet
<apw> bjf, does the multiple nominations bit make sense 
<bjf> apw, i like the "Pending" pulled out
<bjf> apw, yes, i think it makes sense
<bjf> apw, if you needed the room, for nominations you could use a single capital letter
<apw> i was thinking the milestones and noms might merge into one
<apw> as they are logically pairs, Lucid:lucid-updates, stylee
<bjf> can you have mileston: lucid-updates without being nominated: Lucid ?
<bjf> ##
<bjf> ## Kernel team meeting in 20 minutes
<bjf> ##
<apw> bjf, sort of, if the linux (Ubuntu) task is given a milestone
<apw> though i actually think that that is stupid and any linux (ubuntu) task which is not actually nominated should be converted to Natty
<apw> as really thats what i means
<apw> we already have to elide those when they are nom'd to natty, else you get duplicates
<bjf> apw, now what i want is for us to come up with a "kernel heat" index that we add to each bug based on criteria that matter to us
<apw> bjf, any idea what the criteria would be 
<bjf> apw, there are a few "Incomplete" up in the "Active" section
<apw> yes, those are correct, they are Incomplete (with response) ie ... active
<bjf> apw, so not really incomplete
<apw> we haven't got the auto flipper working yet, thats on my list to sort
<apw> right, they need flipping into another state, but lp doesn't do that by default
<apw> i have a prototype that knows how to do it, just not had time to verify its not going to spack up all our bugs
<apw> before letting it loose
<bjf> so anything "incomplete" but "active" needs some manual love
<bjf> for right now
<apw> yeah, its on jfo's list of 'daily' tasks to flip them back
<apw> the key is its hard to flip them to the right place
<apw> you have to look at the activity log for hte bug to know where they have come from, then use some magic to convert that to an appropriate place
<JFo> that and I haven't even touched the list yet this week
<JFo> :-/
<apw> the prototype also handle the New bugs, for when people flip an Incomplete back to New (as thats the only place they can) it can then flip them back to trigaed or whatever they should be
<JFo> headed for some lunch
<skaet_> apw, kernel version for A3 is 2.6.38-rc__ ?
 * skaet_ started into the TechOverview docs now...
<apw> skaet_, -rc6
<skaet_> thanks apw,  adding now.   Can you give me a nice summary paragraph of the changes for this release to add to the Tech Overview?
<apw> skaet_, will do
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-08 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> sconklin, http://people.canonical.com/~apw/lp658307-natty/
<apw> arrggle
<apw> http://people.canonical.com/~apw/misc/key.html
<JFo> brb, gonna step over and hit the big red update button on my Natty netbook
<kees> bjf: tgardner is gone at the moment, can you maybe check a CVE in his absence? nelhage noticed an issue
<nelhage> bjf: I noticed that http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2653.html claims the CVE only affects ppc, because of CONFIG_HVC_CONSOLE
<ubot2> nelhage: Race condition in the hvc_close function in drivers/char/hvc_console.c in the Linux kernel before 2.6.34 allows local users to cause a denial of service or possibly have unspecified other impact by closing a Hypervisor Virtual Console device, related to the hvc_open and hvc_remove functions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2653)
<nelhage> But the affected file is hvc_console.c, and looking at the Makefile: obj-$(CONFIG_HVC_DRIVER)+= hvc_console.o
<nelhage> And CONFIG_HVC_DRIVER is enabled x86
<nelhage> er, on x86
<nelhage> I'm guessing someone just checked the wrong config option (the naming is certainly confusing), but maybe there's some reason HVC_CONSOLE matters anyways?
<bjf> kees, nelhage will look into it
<kees> bjf: cool; thanks
<nelhage> thanks
<smb> bjf, Sounds sensible to me. I remember that ppc had a console driver named hvc and xen also has one of the same name. So I guess for that cve both drivers were confused and it affects x86
<smb> kees, It looks like it should probably be re-activated (the cve tracker file), so we will look at it again
<nusch> apw, for last kernel you provided I've got panic at early boot stage, swapper tainted - not syncing attempted to kill init and ~ following backtrace http://pastebin.com/JJi289qf (written from screen)
<kees> bjf: btw, for uct, it's just "released", not "fix-released"
<bjf> kees, sorry, got mixed up hopping between lp and the cve tracker files
<kees> bjf: but, I'm curious, since you have it as "released" but without a version.
<kees> bjf: where was it fixed?
<bjf> kees, let me look ...
<kees> bjf: do you mean "not-affected"?
<bjf> kees, if it was already fixed as part of a upstream stable release, is that "not-affected" or "released"
<kees> bjf: if it's part of upstream stable release, it must still be included in -security and announced in a USN.
<kees> bjf: i.e. it must show up in the changelog
<kees> bjf: it should be marked "pending" so that we flip it to "released" on USN
<kees> bjf: if it's already in an earlier release, then the first version that fixed it should be listed.  released (2.6....-abi.m)   
<kees> and if a package started its life with it fixed, it would be not-affected
<bjf> kees, fixed up the active status file and pushed the changes
<kees> bjf: cool; thanks. pulling now
<kees> bjf: I'm about to publish USNs for lucid and maverick. have all the CVEs fixed in those two been called out in the changelog?
<bjf> kees, as far as i know
<bjf> kees, i didn't go through every commit and verify
<kees> bjf: well, I mean, last time there were CVEs fixed in the stuff that came from stable, and people yelled at me for leaving CVEs out of the USN.
<kees> bjf: did all the open CVEs get compared to the stable patches? sounds like no?
<bjf> kees, we just apply the stable commits as is, if they don't have the proper "CVE-xxxx-yyyy" line in the commit then they don't make it into the changelog
<bjf> kees, we have no control over upstream
<kees> bjf: right, but we need to have the CVEs actually reported as fixed. that's part of the triage. (this was in my email after the last maverick USN)
<bjf> kees, that means that i'd have to go through all the outstanding CVEs and see if they were fixed in a stable upstream release that we are applying and we don't do that
<bjf> kees, we only look at the CVE as we work them
<kees> bjf: right, this was the process change I requested last time.
<jdstrand> bjf: you don't have control over upstream's changes, but you do over your changelog. if you have already verified that upstream has fixed it, then you need to update the changelog, otherwise no one (not us, not other kernel team members, not ksplice, not users, no anyone) knows what was fixed
<jdstrand> I thought this was already worked out?
<bjf> jdstrand, not to my knowledge
<jdstrand> well, it is pretty clear from an accounting perspective that we need to correlate fixes coming in with CVEs even if upstream isn't doing it
<jjohansen> jdstrand: you just look in the git tree ;P
<bjf> jdstrand, if a CVE was fixed in some previous release and we just now find out about it as we work the cve from our end, you want us to update the changelog ?
<bjf> jdstrand, we update the cve tracker status, that is the accounting we are correlating
<jdstrand> bjf: if it is the same release, yes
<jdstrand> bjf: that works for part of the accounting, but not the part that users see
<bjf> jdstrand, that's not the issue
<jdstrand> if something was vuln in lucid, but not maverick, then maverick's kernel doesn't need it
<bjf> jdstrand, however it could be, we don't look at all the outstanding CVEs when we apply a stable release
<kees> there are two cases. I outlined them both in my email: stuff that is so late to get a CVE it was in a prior release, and CVE fixed in stable patch series for current release
<kees> where "release" means publication of an update
<kees> the former case requires manually editing the USN database. the latter requires manually editing the kernel changelog.
<kees> both require code inspection during tirage
<bjf> kees, if i get a set of stable patches today, i apply them. I do not go through the list of outstanding cves and see which of them got fixed in that batch of upstream stable commits
<jdstrand> bjf: sure, but when you are looking at CVEs, you are presumably verifying if maverick is affected
<jdstrand> bjf: and you do that by looking at the commits
<kees> bjf: right; that's the process I asked to be fixed. the merging of security and stable requires it, else we're not accurately reporting what CVEs have been fixed.
<jdstrand> bjf: when you see maverick has the commit, you update the changelog
<bjf> jdstrand, correct and i update the cve tracking bits, i do not rework the commit of a stable upstream commit to add the CVE verbage
<bjf> jdstrand, nope, we don't do that
<bjf> jdstrand, our changelog is updated via script that culls the commits between versions
<jdstrand> bjf: you need to be adjusting the debian/changlog in some manner to indicate that it has CVE-20XX-NNNN
<bjf> jdstrand, we are not doing that and i am not committing to doing that
<jdstrand> bjf: whether that is part of the automated commit message you guys do, or somewhere up above or below the automated ones, it doesn't matter
<jdstrand> bjf: how are user's supposed to know if their kernel is fixed?
<jdstrand> bjf: how are USNs supposed to be written?
<jdstrand> I suppose the USNs could be written based on the status of the CVE in the tracker, but users don't know
<jdstrand> bjf: I don't understand why a stanza can't be added to the debian/changelog when you have all the info
<jdstrand> * CVE fixes as part of stable tree merge:
<jdstrand>   - CVE-2011-NNN1
<bjf> jdstrand, if a cve was fixed as part of a stable upstream commit pulled into one of our releases, two updates ago users didn't know that the cve got fixed
<jdstrand>   - CVE-2011-NNN2
<bjf> jdstrand, because we didn't go through the entire list of outstanding cves looking for them
<jdstrand> bjf: when you pull the commits, there needs to be review of what is fixed
<bjf> jdstrand, no
<kees> two updates ago is a separate issue that we can fix separately by pulling from UCT and stuffing it into the USN db.
<jdstrand> bjf: if it went into upstream stable, there is already a CVE in the CVE database
<jdstrand> that CVE in the database already has a commit
<jdstrand> (typically)
<jdstrand> bjf: no as in 'no, you are not doing it'?
<bjf> kees, the issue is no different in my mind whether it was a commit two releases ago or this one now
<kees> jdstrand: no, UCT will have upstream not stable commit id
<bjf> jdstrand, no we are not reviewing all the patches from stable upstream releases
<kees> bjf: the difference is that if the CVE is known to the world now, and it has been fixed now, it must be announced as fixed now.
<kees> bjf: if it was fixed in the past, and the CVE identified now, then we can only update the historical USN
<bjf> kees, it was fixed in the past, known in the past but we (the kernel team) had not gotten to it yet
<jdstrand> bjf: I am not asking for review of every commit. I am saying look at the open CVEs which have commit ids. correlate those to what was just pulled in
<bjf> kees, therefor we don't know that it was fixed in a stable release
<bjf> jdstrand, you are asking us to review every cve that we have not already applied against every stable upstream release
<jdstrand> bjf: yes? that is how one determines if that release is affected by a CVE
<jdstrand> and that is something you need to know anyway, for what to fix
<kees> bjf: correct. "had not gotten to it yet" is the problem. in the past, CVE triage always happened before stable updates, so all CVE fixes were already identified prior to do the stable patch series.
 * jdstrand feels like he is missing something
<jdstrand> bjf: I realize that during the 'catch-up phase' there needs to be some understanding that there will be accounting issues. I get that. However, the only way I see to make sure that things don't go awry is if triage happens before stable release commits. if that happens, then it is easy to add the non-automated changelog stanza I mentioned
<bjf> kees, i don't know how CVE triage was done in the past, i know that i do it by trying to apply the patch and if it fails, looking at why
<smb> kees, bjf I would say it never was guaranteed. Just because application of patches was slow with all the review and limited resources, it may have ended up that way
<sconklin> stable release updates come in asynchronous to any work we do with CVEs and will arrive after some and before others
<jdstrand> bjf: well, that works for isolated commits to prior releases. but it doesn't work for wholesale stable updates from upstream, because they are bug fixes *and* security fixes
<kees> I'm just saying we have a responsibility to report what was actually fixed.
<jdstrand> I mean, at some point, someone has to say-- "this doesn't affect maverick because it is already part of the stable release patches"
<smb> kees, Would it not be possible to scan a cve file when moving it to inactive and check for the released status?
<sconklin> we do that. At the moment we triage a CVE and try to apply it to a kernel, we learn whetehr it has been previously applied
<bjf> jdstrand, and i'm saying i find out it doesn't affect maverick because it is already part of a stable release patches because i just tried to apply it and i see that it already has been patched
<jdstrand> since users need to know if their kernels are vulnerable, not to mention comparisons of our kernels ot other distros and 3rd parties like ksplice, why can't the applying of the stable patches be done in accordance to CVE triage, if CVE triage is out of date
<sconklin> There is no mapping of stable upstream commits to CVEs
<jdstrand> bjf: perhaps the answer is do do CVE traige immediately after applying the stable patches?
<sconklin> There is a mapping of CVEs to Linus's commits
<jdstrand> there has to be a correlation between Linus' commits and the upstream stable commits
<bjf> jdstrand, if that was what we were doing, there would be no backlog of CVEs needing to be worked and all CVEs would be processed before we see stable updates
<jdstrand> bjf: I'm sorry, I don't follow you
<bjf> jdstrand, i think the disconnect is what you call "cve triage" and how we do "cve triage"
<jdstrand> bjf: there is initial triage and 'for reals' triage
<jdstrand> bjf: for a non-kernel update, our team gets the initial CVE, see it probably affects our releases, and gets a priority
<jdstrand> bjf: someone is assigned to it and they dig down and see what releases it really affects
<jdstrand> bjf: and then we fix, etc, etc
<jdstrand> bjf: we do the intial, you guys do the 'for reals'
<jdstrand> look
<bjf> jdstrand, i only do "for reals" triage and I do it by applying a patch if the patch applies, i update a tracking bug, post the patch and the patch goes in
<jdstrand> bjf: yes
<jdstrand> bjf: why can't the changelog be a part of that?
<bjf> jdstrand, when I "apply" a patch, i first take the upstream commit, and add the necessary text so that when it gets applied, and we run "insertchanges" it gets picked up
<bjf> jdstrand, that will add it to the changelog
<sconklin> our changelog is generated just before building our package, by a script that processes the git log. It isn't a manual incremental process
<jdstrand> bjf: but you aren't adding the CVE reference. you said that
<bjf> jdstrand, that's not what i said
<bjf> jdstrand, i said i don't go back and add it for stable release commits
<jdstrand> alright, when you do 'for reals' and send it up, you ignore whatever it doesn't apply to
<jdstrand> I see that
<bjf> jdstrand, oh and by the way, since we now get stable updates at different frequencies for different series, lucid may get a cve fixed before maverick
<jdstrand> but, this is a real problem. it isn't us just whining and asking for busy work
<jdstrand> eg, ever since Ubuntu issued security updates, the changelogs include CVEs references. this dates back to before Ubuntu far back into Debian
<jdstrand> people look at changelogs to decide if the update is worth upgrading for
<jdstrand> many people won't apply updates without CVE references in them
<jdstrand> so people remain vulnerable because they don't know they need to upgrade
<sbeattie> (or won't reboot into the new kernel without them)
<bjf> jdstrand, and it still includes CVE references, we just don't guarantee that it's for all the CVEs that were fixed in a particular release (and we never did guarantee it)
<jdstrand> the USNs try to help with that, but we don't know what was fixed because the CVEs aren't in the changelog
<jdstrand> bjf: I understand it will have some. I understand you are saying you never guaranteed that. I am saying that is a problem
<sconklin> But it was the case before that this happened
<jdstrand> all other packages do this
<jdstrand> before is neither here nor there
<jdstrand> the problem seems exacerbated lately, but if it was broke before and now, it still needs to be fixed now
<bjf> jdstrand, it is "worse" now because of the two week cadence and that most releases now have at least one cve in them and you are looking closer
<jdstrand> I'm not sure what the fix is, and I want to reiterate that the work being done is not lost on me. I very much appreciate it and have been quite public about prasing all the hard work you guys have been doing
<jdstrand> (to management and others)
<jdstrand> (and that includes your manager_
<jdstrand> )
<jdstrand> upstream stable commits are not going into -proposed without other SRU or CVE bugs are they?
<bjf> jdstrand, yes, we take them wholesale
<sconklin> yes
<sconklin> with or without, whenever they land we take them
<jdstrand> so it is possible that a kernel will hit -proposed with no open CVEs or SRU bug fixes?
<bjf> jdstrand, that is correct
<jdstrand> ok
<sconklin> theoretically yes
<jdstrand> so, after everything is caught up, there won't be such a backlog of CVEs
<sconklin> and it's almost happened - we've had kernels with dozens of patches and only one open bug that needed verification
<jdstrand> therefore, it should not be hard to then apply the stable commits, then go through the open CVEs and try to apply the patch. this happens before the upload to -proposed. then you can add an non-automated 'CVE stanza' before uploading to -proposed
<jdstrand> this is not 'extra work' because this is work that you will be doing anyway
<bjf> jdstrand, then there would be no backlog of cves right ?
<sconklin> except that we'd have to go through ALL the unapplied CVEs
<jdstrand> sconklin: I said 'after everything is caught up'
<sconklin> when pigs fly
<jdstrand> bjf: there isn't a 'backlog', but there might be open CVEs
<bjf> jdstrand, i don't see a day when there won't be a backlog
<sconklin> Despite the rapid rate at which we're working, I don't see the backlog getting a whole lot smaller
<jdstrand> bjf: define backlog. I am talking about all the CVEs that didn't get fixes. it is my understanding that these are getting fixed and people are helping out
<bjf> jdstrand, http://people.canonical.com/~apw/cve/pkg/linux.html
<jdstrand> sconklin, bjf: you need to talk to your manager if you can't catch up. if you can't catch up, any hiccup means you can't keep up
<bjf> jdstrand, everything on that page that says "needs-triage" is backlog
<jdstrand> bjf: yes, I am familiar with that page
<jdstrand> bjf: you have already gone through almost all the 2010 CVEs
<sconklin> jdstrand: we're working on that as a separate issue ;)
<bjf> jdstrand, you asked me to define backlog and i just did
<jdstrand> there is one outstanding 2011 CVE on that page
<jdstrand> bjf: k
<jdstrand> I have been very encouraged by how much you guys have been catching up
<jdstrand> that page looked much worse 10 days ago
<jdstrand> we are getting caught up on the wrong things
<bjf> jdstrand, so, we are making progress, that has nothing to do with what started this discussion
<sconklin> jdstrand: is it the case that for every CVE we care about that's in yoru CVE tracker, we know the upstream commit ID?
<jdstrand> if part of the work is triaging a CVE by trying to apply it to a branch, then when you do that isn't 'extra work', it is 'rescheduled work'
<kees> bjf: btw, given that the sru-report is empty for dapper hardy karmic, why are there "pending" on http://people.canonical.com/~apw/cve/pkg/linux.html ?
<kees> sconklin: not always, that assumes there is a fix
<bjf> kees, no idea
<kees> sconklin: or assumes that the location of this fix was known during triage
<jdstrand> therefore, if you reshedule CVE triage to 'right after' you pull stable upstream commits, you can both adjust the changelog, accurately reflect the state of that kernel, etc, etc
<bjf> kees, i'm assuming we are not merging with your updated active files
<jdstrand> kees: isn't it now part of our process to push our updates to the kernel team?
<jdstrand> kees: (our new CVEs)
<kees> bjf, jdstrand: we pull the kernel team tree daily.
<jdstrand> right
<kees> s/daily/at every CVE triage cycle, which is supposed to be daily/
<sconklin> jdstrand: yes, but CVE triage has now been redefined to mean 'review every open CVE, determine the upstream commit identified with it, and see if we applied the same patch'
<sbeattie> kees: right, but how often does the kernel team pull from our tree?
<kees> sbeattie: not sure
<jdstrand> sconklin: ok. whatever you call it, can't you just do what I suggested for trees that pull upstream stable updates? it would completely solve the problem for those kernels, and wouldn't hurt the full triage done for the others. plus, you could conceivably add that commit id to the tracker as a pointer on where to look later, so it could make it easier down the road
<jdstrand> I really don't see how that adjusted workflow would adversely affect you guys. that work has to be done regardles
<sconklin> I'm questionin the premise that this must be done
<apw> jdstrand, that is maybe true, but you are adding an ordering constraint which does not exist currently
<jdstrand> sconklin: see backscroll for users trying to decide on updating. USN publication, 3rd parties like ksplice. accurate accounting. comparison with other distros
<jdstrand> it is an important change
<jdstrand> people are confused
<sconklin> And I'm sorry, I'm not intending to avoid discussion, but I have four more kernel packages I have to get built today so I'm going to have to get to those
<apw> how do you do it for packages where you do not control uploads
<jdstrand> apw: not to mention, it is the same people applying upstream stable commits as fixing CVEs: the kernel stable team
<apw> when grub2 gets a 'sync'd with debian' how do you ensure it has USN numbers in it before it is uploaded
<bjf> jdstrand, how about someone from security team doing a rotation onto the kernel team ?
<jdstrand> apw: we don't sync from Debian for stable releases. we backport patches. we don't write USNs for the devel release. the devel release is ok to have only 'released' or 'not-affected' in the CVE
<apw> what i don't see is how it differs from when a CVE is discovered after the fix was accidentally applide to natty
<apw> or any release
<jdstrand> bjf: I'm not sure where you are going with that
<apw> there the fix preceeds the USN, why can we not postumously indicate a previous release has a fix
<jdstrand> apw: because people don't run the devel release in production?
<apw> as we triag and find the fix, and mark it released (xxx)
<apw> ignore the word natty, it just came out
<bjf> jdstrand, i'm suggesting that that to properly understand each others point of view and the work involved, perhaps someone should do a rotation onto the kernel team
<apw> so if we apply .11 and the next week you tell us about a cve that was already released
<apw> how do we handle that, that must be a situation we have a process for
<kees> apw: it's two situations, a CVE being identified months after a fix is published already and a fix being applied when the CVE is already known.
<jdstrand> bjf: no trying to be daft, but we have worked very closely with the kernel team for years on this
<kees> the latter is what needs to be fixed, as it is causing a lot of confusion now since merging stable and security updates
<apw> kees, well i'd say if its not been triaged, its not know yet
<kees> apw: that might be true for you, but for people who watch public CVEs, this is not true.
<apw> till thats done we don't know if the random sha1's in the CVE report even are the right fix
<kees> apw: it looks like Ubuntu is "silently fixed" CVEs
<kees> *fixing
<jdstrand> bjf: sometimes the patching, etc was more on us, and sometimes on the kernel team. there are too many kernels for us to maintain
<bjf> jdstrand, ah, nevermind, thought we were in disagreement about something, guess i was wrong
<apw> kees, right but that does happen, we sometimes do pull in a fix for a bug and push it
<apw> without knowing it also fixes a cve
<apw> it is bound to happen isn't it ?
<kees> apw: we have a responsibility to announce what CVEs are fixed. that means we must always compare the shipped code against the known CVE fixes.
<jdstrand> sure, occassionally, but now it is guaranteed to happen
<kees> apw: having no CVE back log helps that greatly, of course.
<kees> apw: in the past, all CVE work was finished before doing stable updates.
<kees> apw: so this never happened
<apw> kees, actually smb disagrees that that was guarenteed
<kees> apw: well, it never had multiple people yelling as us for inaccurate USNs
<apw> kees, then someone needs to make the decision that we don't ship updates till the triage backlog is comlplete
<apw> because until the cve's are triaged and we know the SHA1's are accurate we have nothing to work with
<jdstrand> apw: or we reorder the work, which seems not a hard thing to do?
 * jdstrand really doesn't understand the problem there
<pgraner> jdstrand, reordering is not possible
<jdstrand> pgraner: why?
<apw> jdstrand, to do what you ask, which is to know all of a stable update is a CVE we need to know the information in
<kees> apw: you have the code...
<apw> it is accurate, which means it needs to be triaged.  this neceesarily moves CVE triage before all releases
<apw> kees, no i have a report with text, and some possible sha1's
<jdstrand> bjf stated that his triage consists of trying to apply a patch
<apw> that does not tell me those patches are cve patches till i read them
<jdstrand> so, apply all of stable upstream commits. then try to apply the commits that we know about in the CVE tracker
<kees> apw: right, you go through the CVE list, not the stable patch list
<apw> so does that not mean i need to triage all cves before i can do that matching?
<kees> apw: if the CVE fix appears in the stable patch list, mark it up, etc
<kees> apw: yes.
<apw> kees, right ... and right now we do not triage all CVEs before we apply any patches to the krenl
<kees> apw: you need to identify all the CVEs that have fixed, and know what the fixes are.
<apw> to move to that model is an ordering change
<kees> apw: you have identified the problem. :)
<pgraner> jdstrand, kees, to do that we can't keep up the schedule
<apw> kees, i thought triage of cves came from the security team
<kees> pgraner: but schedule should be secondary to correctness
<apw> but ignoreing that, its a still an ordering change
<apw> we have never checked that a patch for a bug was a cve fix to my knowledge
<kees> apw: no, you have the knowledge to be able to understand when/if CVEs apply to which trees
<jdstrand> pgraner: but it isn't extra work, it is only reshuffling the work that is done. I am not proposing to do all triage for all previous releases immediately after apply upstream cstable
<apw> and you are asking us to do that now
<jdstrand> apw: you do do that every time you mark something 'released' or 'not-affected' in the tracker
<apw> jdstrand, yes when i triage a cve i mark the tracker, but i do that when biting of a cve and fixing it
<apw> i don't do all of the triage for all of them, then apply one
 * jjohansen -> lunch
<anon^_^> any issues persisting with latest kernel updates for 10.04 in update manager?
<anon^_^> http://img121.imageshack.us/img121/1092/oopsd.jpg
<anon^_^> dummy files are showing up, but not the binaries
#ubuntu-kernel 2011-03-02
<kees> bjf: lucid linux-ec2 changelog shows release tracking bug as 712864, but that bug has nothing to do with the kernel? should that be 716657 ?
<bjf> kees, i'll look, thanks for the heads-up
<kees> bjf: cool; thanks.
<bjf> kees, where do you see 712864 as the tracking bug, i'm looking at the changelog in the kernel tree and it shows 716657
<bjf> kees, i see it
<bjf> kees, i don't know how that happened, but i can guess, and it was very sloppy work on my part
<bjf> kees, thanks again for pointing it out though
<anon^_^> anyone able to address my question?
<MTecknology> If you were to compile a kernel that was completely monolithic vs using a lot of modules.. when you boot is the longer wait time only in loading the entire kernel into memory; or is there a lot of extra processing that needs to be done?
<ohsix> modules builtin will be initialized, modules will be loaded on demand and only initialized when that happens, it's not a huge difference but it is a difference
<MTecknology> so there is extra load time for built-in modules if you're not going to frequently use them?
<MTecknology> ohsix: thanks :)
<jjohansen> MTecknology: actually, it depends.  Modules have linking overhead, and if you are talking about loading modules from the initramfs then builtin is definitely faster
<MTecknology> jjohansen: I don't use an initrd though
<jjohansen> well that you won't have that added problem to consider
<MTecknology> jjohansen: I have a 2.2MB monolithic kernel; I was just wondering if I'm losing by having monolithic and changing some things to loadable modules would be a better idea.
<jjohansen> MTecknology: it will just depend, on when it gets used etc. /me likes the flexibility of modules,
<MTecknology> jjohansen: I've been kind of sad though... having to stick with -rc2. When I try anything newer X won't start. I see -rc7 has been released; so I think it's time to try that. :)
<MTecknology> I know there have been a lot of changes with intel video
<jjohansen> MTecknology: yeah, I just tried my machine that display won't work, its still a no go for me
<MTecknology> intel video?
<jjohansen> yep
<jjohansen> I hear some are now working, mine isn't
<MTecknology> I hope I have more luck than you then... but i doubt it
<MTecknology> I wish I could use acpi -t too :(
<anon^_^> anyone able to address my question?
<anon^_^> are there issues persisting with latest kernel updates for 10.04 in update manager?
<anon^_^> http://img121.imageshack.us/img121/1092/oopsd.jpg
<anon^_^> placeholder values for linux kernel are showing up, but not the binaries
<jjohansen> anon^_^: not that I know of
<anon^_^> jjohansen, so why would placeholders show up as an update but not the actual kernel files
<jjohansen> anon^_^: have you tried dropping to the terminal and doing apt-get update, apt-get dist-upgrade
<anon^_^> no
<jjohansen> anon^_^: sorry I really don't know
<jjohansen> anon^_^: try forcing a refresh, hit the check button
<anon^_^> refreshed update manager a few times, same result
<jjohansen> anon^_^: what sources do you have?
<anon^_^> can't select the placeholders for the new kernel 2.6.32.29.35
<anon^_^> default sources, no change
<anon^_^> added some ppa repos, but nothing that influences the kernel
<jjohansen> anon^_^: x86 or x86_64
<anon^_^> x86_64
<anon^_^> presently running 2.6.32-28-generic
<jjohansen> okay, I'll see if I have a lucid around that needs updating
<anon^_^> the new kernel placeholders showed up with updates this morning
<anon^_^> well that is interesting, when I unchecked docky-core ppa from other software in sources list and then refresh, i suddenly see kernel update files
<anon^_^> http://ppa.launchpad.net/docky-core/ppa/ubuntu
<anon^_^> was the ppa that i unchecked from sources list
<anon^_^> after deselecting docky-core ppa
<anon^_^> http://img52.imageshack.us/img52/9138/itworksnow.png
<anon^_^> anyone have an idea of why that would occur?
<RAOF> anon^_^: Because you've updated the apt lists, and the missing packages have now been added?
<anon^_^> when docky-core ppa was included
<anon^_^> http://img121.imageshack.us/img121/1092/oopsd.jpg
<anon^_^> RAOF, why would apt lists not show kernel updates when a dock ppa is selected
<anon^_^> the dock shouldn't change kernel dependencies
<RAOF> It won't, but when you removed the docky PPA you also updated the apt lists.
<RAOF> (As in: the locally cached list of packages available in the archive)
<anon^_^> so RAOF, if i re-enable docky-core ppa in sources list
<anon^_^> and refresh, it shouldn't interfere
<anon^_^> yes?
<RAOF> Indeed.
<anon^_^> well that's not the case
<anon^_^> because i just re-enabled the docky-core ppa, and the output for update manager
<anon^_^> is the same as it was before
<anon^_^> i installed linux-libc-dev because i could
<anon^_^> then disabled docky-core ppa refreshed
<anon^_^> output showed all kernel updates
<anon^_^> http://img52.imageshack.us/img52/9138/itworksnow.png
<anon^_^> go back and re-enable docky-core ppa in sources list
<anon^_^> update sources list
<anon^_^> http://img843.imageshack.us/img843/1320/somethingsfishy.png
<anon^_^> and it's blocking kernel updates again
<fairuz> any special channel I have to join for Perf tool related problems?
<apw> perf is shipped as part of the kernel
<fairuz> I have this error when I try to use perf stat : Consider tweaking /proc/sys/kernel/perf_event_paranoid
<fairuz> taht is when I try to collect caches miss data
<fairuz> i tried this command perf stat -e L1-dcache-load-misses echo "test"
<jjohansen> apw: this is a screen shot of anon^_^'s failure : http://img121.imageshack.us/img121/1092/oopsd.jpg
<fairuz> i tried the command with verbose, and it sais I dont have the permission. So, I tried with sudo and now It says Error counter 0 , sys_perf_event_open() syscall returned with -1 (no such device)
<fairuz> *says
<apw> fairuz, hmmm never seen that myself
<apw> bug #662009
<ubot2> Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged] https://launchpad.net/bugs/662009
<fairuz> I'm running ubuntu on ARM, maybe Perf not supported on ARM platform?
<apw> its cirtianly likely that differnet sub-sets of fucntionality are missing yes, they may not yet expose any physical counters
<fairuz> hmm ok
<fairuz> are you running on x86? can you try the command and see if it come out with cache miss?
<fairuz> perf stat -e L1-dcache-load-misses echo "test"
<apw>               15419  L1-dcache-load-misses   
<apw> seems to work on my intel box yes
<fairuz> hmm ok
<fairuz> apw: thanks anyway
<apw> if you are using arm specifically you might also ask in #ubuntu-arm, they may have more specific knowledge 
<Specialist> Hi there! I am currently running 2.6.35 on Ubuntu 10.10 and am considering switching to 2.6.38, which would allow me to use my second video card (which is detected by 2.6.38's nouveau driver, but not by the one from 2.6.35). Are there any pitfalls that I should be aware of? Maybe even some pre-built packages (I have found only packages for 10.04 so far)?
<apw> Specialist, it is a common combination for those of us in the kernel-team so it might be expected to work
<apw> but its not supported, and as you note there arn't any official packages for that combination
<Specialist> Thanks! So I guess compiling it from the git repo is the way to go...
<smb> Specialist, You can just use the deb packages of the kernel for Natty
<kengyu> smb, good morning. for the eeepc SRU patchset I sent yesterday, two of them (from Corentin Chary) are too new and not yet in mainline, but they're already in mjg59's linux-next branch (http://git.kernel.org/?p=linux/kernel/git/mjg59/platform-drivers-x86.git;a=shortlog;h=refs/heads/linux-next). Since rtg is asking for commit SHA, do you think if it is okay to leave it blank or any preferable way you'd kindly suggest? :-)
<smb> kengyu, Well _usually_ you should wait until things _are_ in Linus tree before requesting SRU. (at least imho)
<smb> kengyu, Are the changes at least in the official linux-next tree?
<kengyu> smb, yes, they are. I suppose you already know patches from me are usually for some reasons. :-/
<smb> kengyu, Of course I do not question that they are there for a good reason. Being poking you about them being upstream is more because I want to avoid things getting lost. And us ending up on having working Maverick but not in Natty
<smb> kengyu, So if they are in linux-next, then at least add those commit shas and reference to linux next
<smb> Like: (cherry-picked from commit x linux-next)
<kengyu> smb, appreciated for the suggestion. another question is that if we do use "[Upstream]" in the subject? from debian/commit-templates/upstream-patch, there it is. Though the commit sha is not really mentioned there.
<fairuz> a stupid question.. i included arch/arm/include/asm/hardware/cache-l2x0.h in my code..but why I cant use the functions defined in arch/arm/mm/cache-l2x0.c
<fairuz> i got l2x0_init undefined error
<smb> kengyu, Hm, I am not sure whether we probably need to update the templates. I personally would not use anything in the subject/commit message than is in the upstream version and only modify the content of the message with BugLink and sob and sha reference
<apw> yeah [Upsream] does seem to have become redundant these days
<apw> as we use the presence of an upstream commit id as that indication now
<kengyu> smb, I think I can just follow your convention. :-) I will re-send the patches later. now we have 2-week SRU cycle, is there any regular day for the upload, eg always upload on Fri, any SRU patch after that should wait for the next cycle.
<smb> kengyu, I believe that it seems to happen on Fridays. But you want to ask Steve there. I am not paying that much attention to the details anymore. :)
<kengyu> apw, will it be a good idea to update the debian/commit-templates/upstream-patch  to reflect current kernel team's convention?
<apw> yeah it would ... will add it to the agenda for next week, as we'll be teaching people to use them :)
<apw> added to the agenda
<kengyu> smb, sure. thanks for the nice answering. you're appreciated as usual. :-)
<kengyu> apw, thanks for that. saw your wiki update. :-)
<smb> kengyu, You are welcome. I try to be as helpful as one being as anal as me can. ;-)
<kengyu> smb, no need to try, you're always helpful. thanks again anyway. :-)
<lag> When you use "fdr binary-arch" the build udebs and debs are placed in .. - is there any way to configure that?
<lag> Also, how do you tell the fdr not to build a million udebs
<lag> apw: ?
<apw> lag, nope thats where they go
<apw> binary arch is designed to build everything
<apw> that includes the udebs
<apw> but you ony get those cause you asked for them in kernel_versions.in
<lag> apw: So to get the image*.deb I use binary?
<apw> nope
<lag> apw: So to get the image*.deb I use?
<apw> disable_d_i=true binary-arch
<lag> That'll do - thanking you
<apw> or if its one flavour, simply binary-<flavour>
<lag> I don't have a u8500 flavour
 * apw wonders if lag remmbers anything we taught him
<apw> lag, you must have cause you make a -u8500 package
<lag> I know what I used to use fdr binary-omap3/4
<apw> it was listed as the flavour in your xorig.log earlier
 * lag checks
<apw> <lag> I'm using Linux version 2.6.35-1000-u8500
<apw> u8500 in that context is the flavour name
<lag> I could have sworn I tried fdr binary-u8500 and it couldn't find the flavour
<lag> I build the packaging, so I guess I should know
<lag> built*
<lag> Hmm... it seems to work now
<lag> That'll do me, thanks apw
<apw> sconklin-gone, bjf, the tag for hardy maverick is missing
<apw> sconklin-gone, bjf, the tag for hardy _master_ is missing
<skaet_> apw,  thanks!
<apw> skaet_, ?
<skaet_> comments in the TechOverview. :)
<tgardner> apw, mumblwe
<apw> tgardner, there
<apw> skaet_, ah
<sconklin-gone> apw: did you tag hardy? 
<apw> sconklin, nope, was assiming it was sitting in your tree
<sconklin> it was. I just got a strange warning when I tried to push it to the master. But it's all resolved and pushed now
<JFo> <-lunch
<tgardner> sconklin, I'm not really in favor of another mailing list. why isn't the existing kernel team list sufficient?
 * apw wonders what it is for
<smb> tgardner, Though I just pushed the additional patchset to 2.6.32.30, I would not announce it yet as it seems to need the swiotlb patch reverted. Otherwise compile breaks.
<sconklin> tgardner: because this includes people from qa, cert, archive admins, release managers, etc
<tgardner> sconklin, and they can't subscribe to the k-t list?
<sconklin> tgardner: no. too much traffic and not specific enough
<bjf> tgardner, there is more noise in that mailing list that they don't want to deal with
<tgardner> thats what filters are for
<bjf> tgardner, one of the issues with the new cadence is the difficulty of clearly handing things off between the different parties and clearly communicating what is happening, this addresses those concerns
<bjf> tgardner, some of them anyway
<tgardner> bjf, I don't think a mailing list is a good method for state management. Isn't that what LP is supposed to do?
<bjf> tgardner, it's not handling that part its to help with clearer communication of kernel sru work/issues
 * smb -> away to buy a new power supply
<tgardner> sconklin, bjf: gimme some examples of the kinds of messages you intend to send on this mailing list.
<sconklin> just sent one
<sconklin> Will be sending another one soon about copying packages from ppa to proposed
<vish> apw: hi.. poking about Bug 652934 again ;) , can we get that SRU milestoned.. all testing work has already been done, we just need to upload it :)
<ubot2> Launchpad bug 652934 in linux "[RV515] Guest session causes screen to flicker violently and session is unusable" [Medium,Confirmed] https://launchpad.net/bugs/652934
<vish> apw: also, we should probably look into dropping that patch from natty too..
<bjf> tgardner, there was an issue with ec2 kernel which we wanted all the relevant folks to know about which was holding up maverick from moving to updates, that email would have gone to that mailing list
 * vish noticed that we got a kernel update this week, and was hoping this bug would have been included ;)
<bjf> vish, if you subscribed to the kernel team mailing list you'd have a clearer idea if any given patch had been submitted for sru and if it had been accepted
<apw> vish, that commit is gone from natty as far as i can see
<vish> bjf: ah, cool! but i'm not that list yet.. :)
<vish> apw: about the SRUs for lucid & maverick? (atleast maverick as I'm still on it ;p)
<vish> i did test your lucid kernel too 
<apw> vish will look
<vish> thanks.. :)
<tgardner> bjf, it seems to me that ubuntu-devel would be appropriate for emails of that nature, e.g., "Lucid and Maverick EC2 kernels still lack verification". It should reach all concerned parties, its a well known list, _and_ you don't have to subscribe the key players 'cause they're already there. Starting a new list cuts out a big chunk of the public.
<sconklin> tgardner: well, this was discussed among the people who actually tale action items from the sru kernel process. I included you more for your information than anything else. So I think it's serving the needs of the stakeholders in a reasonable way
<sconklin> s/tale/take/
<apw> vish ok patches submitted to the lists for revieww
<vish> apw: thanks.. :)
 * tgardner --> lunch
<bdmurray> I really don't see much relevant information in https://wiki.ubuntu.com/Kernel/LinuxWireless other than the link to upstream documentation
<JFo> well that was interesting
<kamal> apw: fyi that mem=nopentium panic fix that I sent upstream landed in linux-next but does not appear in 2.6.38-rc7 ...  maybe it won't hit mainline until 2.6.39 (?)
<kees> tgardner: hi, if it's not already on your TODO list, can you take a look at bug 707577 for pitti's questions?
<ubot2> Launchpad bug 707577 in linux-meta-lts-backport-maverick "Lucid LTS Maverick backport, update to 2.6.35-25.44" [Undecided,In progress] https://launchpad.net/bugs/707577
<tgardner> kees, otp, gimme a bit
<kees> tgardner: sure, no rush. I added the "kernel-tracking-bug" tag to that bug too, since I didn't see it in the sru-report.
 * jjohansen -> lunch
<rick_h_> howdy, wanted to check in and see if anyone was familiar with this failed to get i915 symbols, graphics turbo disabled issue that seems to be going around in 10.10?
<rick_h_> upgraded and having display issues: http://askubuntu.com/questions/28730/upgrade-wont-allow-second-display-to-go-to-1920x1080
<rick_h_> and stumbled upon a bunch of bugs, this one lends me hope a kernel upgrade might fix? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/651104
<ubot2> Launchpad bug 651104 in linux "intel graphics turbo disabled" [Undecided,New]
<rick_h_> but nervous of just dropping in some linked kernel/etc
<sforshee> rick_h_, yeah, looks like you'd need to upgrade to kernel version 2.6.37 for the turbo mode fix, but I don't know if that will fix the screen resolution problem
<sforshee> rick_h_, which linked kernel are you referring to?
<apw> JFo, about ?
<JFo> apw, yessir
<apw> got time for a chat ?
<JFo> sure, though I am in the hammock and my headset is inside :-D
<JFo> want me to grab it?
<apw> JFo, sure :)
<JFo> brb
<pmathews> I'm having problems with git:
<pmathews>  git clone git://git.omapzoom.org/kernel/omap.git 
<pmathews> Initialized empty Git repository in /home/pmathewslocal/DB-117/omap/.git/
<pmathews> remote: Counting objects: 2021581, done.
<pmathews> remote: Compressing objects: 100% (318816/318816), done.
<pmathews> remote: Total 2021581 (delta 1686376), reused 2019306 (delta 1684356)
<pmathews> Receiving objects: 100% (2021581/2021581), 430.22 MiB | 600 KiB/s, done.
<pmathews> error: inflate: data stream error (invalid distance too far back)
<pmathews> fatal: serious inflate inconsistency
<pmathews> fatal: index-pack failed
<pmathews> I have tried 4-5 times to clone the kernel but get this same error every time
<sconklin> pmathews: have you tried cloning from any other repo? (just to see whether it's a local problem or one with the remote repo)
<dorpsgek> hi
<pmathews> <sconklin>Give me an alternative repo please
<dorpsgek> why is /dev/dsp taken from the kernel, it cannot be the size of the module, i have to compile a new kernel every new kernel update
<sforshee> pmathews, I cloned that repository without issue, may be a local problem
<sconklin> pmathews: git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git for example
<rick_h_> sforshee: http://kernel.ubuntu.com/~manjo/maverick/lp651104/ was what I was checking out
<rick_h_> that's still .35 though
<rick_h_> sforshee: so the debate now is, how best to approach this. Should I just test a natty alpha? Is it a later kernel? (haven't looked yet)
<rick_h_> go back to LTS and wait it out
<rick_h_> or best way to get a .37 kernel that won't cause me issues with anything else going forward with 10.10
<dorpsgek> ok, i think it will be goodbey for ubuntu, it is no fun to compile everytime a new kernel for this
<herton> dorpsgek, oss is disabled in the kernel, I think since bug 579300
<ubot2> Launchpad bug 579300 in linux "Please disable CONFIG_SOUND_OSS* and CONFIG_SND_*OSS*" [Wishlist,Fix released] https://launchpad.net/bugs/579300
<sforshee> rick_h_, manjo's kernel should be safe to try, but natty is using .38 so it will have the fix
<rick_h_> ok, I'll give a usb boot a test then tonight. Thanks
<sforshee> np
<dorpsgek> herton: to disable something without a (good) replacement is not nice
<mjg59> dorpsgek: There's been a good replacement for it since 2002
<apw> dorpsgek, and pulse is meant to supply a replacement
<apw> that is why it was disabled
<dorpsgek> ut2004 --> open /dev/[sound/]dsp: No such file or directory    etc....................
<dorpsgek> during DOOM 3 initialization...
<dorpsgek> WARNING: failed to open sound device '/dev/dsp': No such file or directory  etc...............
<dorpsgek> so for a lot of stuff what people can use to have some fun
<kees> dorpsgek: OSS devices were eliminated a while back. perhaps try using "padsp /your/command"
<JFo> <-headset battery finally died.
<dorpsgek> ok, ik know what to do, thanx for the support
<dorpsgek> is there a way to blacklist kernelupdates
<apw> probabally can pin: the kernel
<kees> bjf, sconklin: regression in 2.6.32-29? bug 727653
<ubot2> Launchpad bug 727653 in linux "initrd.img-2.6.32-29-generic breaks iwlwifi-6050" [Undecided,New] https://launchpad.net/bugs/727653
<apw> kees, beat me to it :)
<kees> apw: :)
<kees> it doesn't look to bad, maybe a bad dkms hook or something? not really sure
<sconklin> kees: thanks for letting us know. I wonder if we have any of this hardware
<apw> sconklin, it looks like a firmware load failure
<jsalisbury> sconklin, I have this laptop with this wireless card, I plan on applying updates on Friday, so I guess my wireless will break :-O
<apw> was there anything like that in the changes in -29 ?
<apw> otherwise it might be a firmware updare issue ... we might want to check they didn't get a firmware version update
<apw> as in a linux-firmware package
<bjf> apw, there is one sitting in -proposed
<bjf> apw, a linux-firmware
<JFo> my connection has gotten fragile, thanks for looking bjf, sconklin, apw :)
<apw> any idea what is changed in it bjf ?
<bjf> apw, looks like some new firmware, i need to pull the sources and look
<jsalisbury> sconklin, Actually, I'm running Natty, so I can't test.
<apw> see if those new names are in there
<apw> Mar 2 03:47:28 cogito kernel: [ 109.671281] iwlagn 0000:02:00.0: firmware: requesting iwlwifi-6050-3.ucode
<apw> it looks for -4, -3, -2, -1 in that order
<bjf> apw, i see iwlwifi-6050-4.ucode but no -3, -2, -1
<apw> bjf, in the new one?
<apw> or in the old one
<bjf> apw, yes the one in -proposed
<apw> wahts in the current one ....
<bjf> apw, well the git repo actually
<apw> bjf, worth asking if the firmware is on their machine, the updates to l-f don't appear to change anything
<apw> on those filenames
<bjf> apw, the lucid firmware package in updates has:   * iwlwifi: 41.28.5.1 iwlwifi-6050-5.ucode      in the changelog
<apw> oh crap looking at the wrong branch
<bjf> brb
<apw> bjf, not really sure why its not there the -4 as it is on maverick
<apw> i suspect we need that adding in, just not sure why we suddenly are missing it
<apw> but its only one piece of h/w so i think we can get tim to look at it in the mornign
<apw> bjf i think we should get the user to try manually installing the -4 firmware
<apw> and see if things work, if so then we can add it to the package tmrow
<apw> sconklin, ^^
<sconklin> sounds reasonable.
<sconklin> I'll update the bug
<apw> sconklin, it seems to be in the maverick branch, ie there is -4 and -5 in there, but the lucid only has -5 which seems counter intituitive at best
<apw> why it worked before the -29 i do not know, best to ask what version tehy had before too
<sconklin> agreed
<bjf> so maverick has both -4 and -5 , lucid only has -5
<bjf> natty has both
<apw> has to be the cause, but how it ever worked on lucid is beyond me
<apw> some background digging seems appropriate
<sconklin> yeah, I'm fetching now
<bjf> as usual we probably are getting a small part of the story
<apw> too true
<sconklin> This is another area where we probably need to share some knowledge
<apw> anyhow, one piece of hardware affected, and they have an old kernel to use so no need to be escalated any further me thinks
<apw> sconklin, yeah indeed
<jsalisbury> apw, sconklin, One piece of info.  I'm running Natty, with linux-firmware 1.47 on the same hardware.  iwlwifi-6050-5.ucode looks like it was added in l-f 1.42 according to the changelog.  I've seen no issues.
<apw> jsalisbury, and you have -5 and -4 on your machine right ?
<apw> in /lib/firmware
<jsalisbury> apw, yes: 
<jsalisbury> jsalisbury@salisbury:/lib/firmware$ ls iwlwifi-6050*
<jsalisbury> iwlwifi-6050-4.ucode  iwlwifi-6050-5.ucode
<apw> yeah so it seems we have -4 and -5 on later releases, but only -5 on earlier ones; which is unexpected
<jsalisbury> apw, not sure who to check if my system is using -4 or -5, maybe something in /proc?  Already checked dmesg and logs.
<jsalisbury> apw, I do see this in /var/log/udev:
<jsalisbury> KERNEL[1298912762.504059] add      /devices/pci0000:00/0000:00:1c.4/0000:02:00.0/firmware/0000:02:00.0 (firmware)
<jsalisbury> UDEV_LOG=3
<jsalisbury> ACTION=add
<jsalisbury> DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/firmware/0000:02:00.0
<jsalisbury> SUBSYSTEM=firmware
<jsalisbury> FIRMWARE=iwlwifi-6050-5.ucode
<jsalisbury> ASYNC=1
<jsalisbury> SEQNUM=1897
<sconklin> jsalisbury: I just updated the bug, with an attached version 4 of the firmware.
#ubuntu-kernel 2011-03-03
<jsalisbury> sconklin, I can add my system details to the bug.
<jsalisbury> sconklin, if needed
<sconklin> jsalisbury: I don't think we need them but thanks
<jsalisbury> sconklin, ok, thanks
<fairuz> is this the right channel to ask about DMA? =)
 * apw yawns
 * _ruben agrees with apw
<fairuz> how to backport patches to my kernel?
<fairuz> do i need to recompile the kernel if I backport some patches?
<tgardner> apw, linux-backports-modules-wireless-2.6.35-lucid-generic
<apw> fairuz, after applying them to the source, normally yes you need to recompile
<fairuz> apw: so I just have to apply the patch normally, and recompile the kernel?
<apw> fairuz, thats what i do
<fairuz> apw: thanks. I give it a try
<fairuz> sorry, one more easy question, so to backport what exactly i should do? my idea is to modify the file in question and add the differences?
<fairuz> (I'm new to the patch and git thing)
<apw> i presume that patch is not able to apply the change you have
<fairuz> hmm I confuse between a backport and an upgrade
<cnd> diwic, something has come up for me on my multitouch stuff
<cnd> I don't think I'll be able to help out with the firmware packaging :(
<diwic> cnd, today, or ever?
<cnd> diwic, well, for a few days at least
<cnd> at least
<cnd> someone is leaving our team
<cnd> so a pile of tasks got shifted on to everyone
<diwic> cnd, ok :-( I'll remind you in a week or two then
<cnd> and those tasks are a little late already :)
<cnd> diwic, you can prepare the upload and tim can push it to the archive
<sforshee> apw, bug 662288 was brought to my attention
<ubot2> Launchpad bug 662288 in linux "rt3090: freeze on module rt2800pci unload" [Undecided,Confirmed] https://launchpad.net/bugs/662288
<sforshee> there's a fix in linux-next, but it won't make .38
<sforshee> I was asked if we could pull it into natty
<sforshee> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=7f6e144fb99a4a70d3c5ad5f074204c5b89a6f65
<apw> sforshee, as its for unload its not so important i assume, but sure if it fixes bugs we can take things like that
<sforshee> apw, I think it causes a hang when shutting down
<apw> sforshee, ok, thats deffo worth a poke.  i'll look it over and see shortly
<sforshee> thanks apw
<tgardner> sconklin, would you check the moderation queue for ubuntu-kernel-sru@lists.ubuntu.com ? I've sent 2 emails that have not appeared.
<sconklin> tgardner: not seeing any pending requests
<tgardner> sconklin, hmm
<sconklin> This has been happening because I subscribed people and sometimes they send from their alias. As I see them I moderate and whitelist the new address. But I'm not seeing yorus
<tgardner> sconklin, my mail server says they are going out: Mar  2 19:06:16 mail postfix/smtp[20232]: 6FFCF2A4074: to=<ubuntu-kernel-sru@lists.ubuntu.com>, relay=lists.ubuntu.com[91.189.94.204], delay=4, status=sent (250 OK id=1PuysF-0005fa-LX)
<sconklin> tgardner: don't know what to say - I've gotten moderation requests for two other people on the list and fixed them. Haven't seen yours. I'll have to open a ticket
<tgardner> sconklin, well, I sent my email to the k-t list with a Cc to the sru list
<tgardner> (just now)
<sconklin> tgardner: Re: [kernel-SRU] linux-lts-backport-maverick archs? ???
<sconklin> I think what happened is that there's an option turned on in the mailing list to eliminate duplicate emails to members, and it's probably only sending to one of the lists for you. I'll turn that off, as it's counterintuitive
<sconklin> done
<JFo> brb, need to make some more coffee
 * smb orders one
 * JFo fedexes :)
<smb> JFo, Many thanks. :)
<JFo> my pleasure 
<JFo> ooh I hate computers right now... they keep doing what I tell them to.
<JFo> they are supposed to know what I want :)
 * JFo keeps closing pages before he is done with them
<JFo> <-lunch bbiab
<aakshay___> hi.. i want to begin fixing bugs for kernels.  can somebody suggest me easy bugs for the start?....  :)
<aakshay___> JFo: hi.. i want to begin fixing bugs for kernels.  can somebody suggest me easy bugs for the start?....  :)
<aakshay___> hi.. i want to begin fixing bugs for kernels.  can somebody suggest me easy bugs for the start?....  :)
<charlie-tca> aakshay___: seems to be issues with freenode right now, give it a few minutes
<aakshay___> charlie-tca: okiez.. :)
 * tgardner --> lunch
<JFo> well, that was interesting
<charlie-tca> is it done yet?
<JFo> charlie-tca, I think that last one was my provider
<JFo> my entire connection dropped
<charlie-tca> Mine dropped twice during all those spits
<JFo> hmmm
<JFo> I think we are as good as we will get for today
<JFo> aakshay___, were you looking for me earlier?
 * JFo reads back
<JFo> ah, interested in looking at kernel bugs :)
<JFo> excellent!
 * JFo digs up some links
<aakshay___> JFo: hi JFo ..... yes i am intrested in fixing kernel bugs
<aakshay___> but dont know where to start with.. :p
<JFo> aakshay___, our kernel wiki pages are helpful
<JFo> https://wiki.ubuntu.com/Kernel/BugTriage
<JFo> is the first place you should go
<JFo> from the https://wiki.ubuntu.com/Kernel page there are a number of other pages of interest
<aakshay___> JFo: i went through all the bug triaging process..
<JFo> ah, great
<aakshay___> but i not read debugging yet.. do i need to or can i start?
<JFo> it would probably be good to read, but you can start without it for now
<aakshay___> yiipii.... :).. so an easy bug for me?
<JFo> that is a good question. Unfortunately, I don't have any easy bugs. All of them require some basic triage to a certain extent
<JFo> then there is a more advanced triage that I do
<JFo> my best advice to you is to go through the bugs and see which ones you are comfortable looking at
<JFo> I am here if you have questions :)
<aakshay___> okiez..  can you please tell me exact bugs page link..
<JFo> sure
 * JFo grabs it
<aakshay___> :)
<JFo> this is the entire list of linux package bugs: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs
<aakshay___> thanks..:)
<JFo> my pleasure
<aakshay___> let me check if any suits me.. hehe... :)
<JFo> sounds good, ping me here if you need any advice or help :)
<aakshay___> sure....thanks... :)..
<aakshay___> JFo: i found this bug "289584: networking disabled after resume from sleep" ... how will it be to start working with it?
<aakshay___> JFo: i need your help.. i dont know how to start with it.. where to get the modules?
<JFo> ok, one sec..
<aakshay___> yes... 
<JFo> I would start with basic triage, requesting what basic logging we require
<aakshay___> okiez.. so do i need to check it in upstream mainline?
<JFo> I'd ask them to check, yes
<aakshay___> JFo: okiez... but sorry to ask can you please give me further directions.. :)
<JFo> ok
<JFo> what kind of advice do you need? :)
<JFo> so on this bug...
<aakshay___> JFo: yes
<JFo> I would ask for apport-collect data
<aakshay___> JFo: that as i understand , i need to take the driver files and check them or so?
<JFo> so the requests for information text is here: https://wiki.ubuntu.com/Kernel/BugTriage/Responses
<aakshay___> ok.. let me read it
<aakshay___> :)
<JFo> ok :)
<JFo> sorry about that, was a bit distracted by another conversation going on at the same time.
<aakshay___> no issues... :D
<JFo> :)
<aakshay___> JFo: ya.. downloading the image.. and it seems to take long time. so i will come back to you after completing with basic triaging.. :)
<JFo> not sure what you mean by downloading the image aakshay___ 
<JFo> maybe I am misunderstanding what it is you are wanting to do
<aakshay___> JFo: its mention to check with the latest development release
<JFo> right, we ask the reporter to check, as they are the ones encountering the issue
<aakshay___> and the URL to ISO CD images is given
<JFo> right, we provide that to them so they know where to look for it
<aakshay___> so i moved to it and it ask to download one as per the system arch
<aakshay___> yes.. so i am downloading an image for X86... :)
<JFo> but why are you not asking the reporter of the bug to do that?
<JFo> I guess that is where you are losing me :)
<aakshay___> JFo: :D.. we can ask the reporter !!!.. okiez...
<tgardner> bjf[afk] I have a lucid stable branch almost ready. I wanted to make sure you weren't working on it before I create the tracking bug.
<JFo> yep, that is preferred as we want to find out if they still have the issue they reported in the places we point them to
<JFo> that helps the team determine if a fix exists
<JFo> it also allows us to find out the differences between the two
<JFo> so we can identify the problem further
<aakshay___> so i will contact him and ask to run the same to check..
<JFo> sounds good :)
<aakshay___> then i need to add comment there??
<JFo> yes, you would take one of the responses I pointed you to and see which one fits the best
<JFo> and then provide that to the reporter
<aakshay___> let me see which one can be best
<JFo> ok
<aakshay___> JFo: i think this is best "Old With No Activity"
<JFo> yep :)
<aakshay___> and then when i will add in comments there.. :)
<JFo> that sounds fine :)
<aakshay___> JFo: sorry to say  but i think reporter will take lot of time to respond?? .. :(
<JFo> perhaps, it is also possible that they will not respond. 
<JFo> their issue may have been fixed already in a later release
<JFo> and they may just not be willing to answer
<JFo> once you comment, set the bug to incomplete so that we will have the correct state of that issue
<aakshay___> JFo: ok....
<aakshay___> JFo: is there any direct way to enter in developing modules for kernel?.. :)
<JFo> not sure what you mean
<aakshay___> JFo: i have been reading a lot of stuff on programming linux kernel.. so eager to implement and design something.
<JFo> ah
<JFo> so you are wondering what the best way to contribute is?
<aakshay___> JFo: like any module of kernel. :).. please suggest something
<aakshay___> yes.. in development of it
<JFo> on that I am afraid I would be no help. I am the bug triager :)
<JFo> development would be something one of the engineers would be better advising on
<aakshay___> :)... no problem.. so whom can i ask here or elsewhere?
<JFo> well...
<JFo> let me see.
<aakshay___> please.. :)
<JFo> apw, you forgot to mark yourself away. :)
<JFo> sconklin, got a minute?
<JFo> or are you in the middle of something?
<sconklin> for you, sure ;)
<JFo> heh, thanks
<JFo> sconklin, aakshay___ was wondering where to begin on kernel module development
<sconklin> reading back
<JFo> as I am hopelessly lost in bugs, I wondered if you could point in the right way
<JFo> thanks
<sconklin> there was an excellent book out a few years ago, let me see if it's up to date with the latest kernels. One sec
<aakshay___> sconklin: hi.. i am looking for programming the kernel.. can you please suggest me
<aakshay___> sconklin: please :)
<sconklin> aakshay___: If you want to know specifically about how to write drivers, this book is probably the best resource: http://lwn.net/Kernel/LDD3/
<sconklin> drivers are equivalent to modules, essentially
<aakshay___> sconklin: thanks.. :) and i have completed half of it.. 
<aakshay___> and doing the "Programming with Linux" as well
<aakshay___> so eager to implement now
<aakshay___> :)
<Krunch> "LDD3 is current as of the 2.6.10 kernel" that's a bit old
<sconklin> The examples in that are going to give you a different method for building the kernel than the way we typically build Ubuntu kernels, so the build steps may not be what you see on our wiki for how to build kernels
<herton> one good book is also "Writing Linux Device Drivers" (Jerry Cooperstein)
<aakshay___> Krunch: yes.. :)
<sconklin> yes, but I don't think that the major APIs have changed. Some things like debugfs have changed tho. I wish it were more up to date
<Krunch> well, it can certainly get you started
<sconklin> the more I think about it the more I think of that changed
<kees> tgardner: say, are there any sandybridge systems we can do builds on?
<Krunch> but double check all the details in the source (that applies even with the latest book really)
<JFo> oh yeah, the kernel is a constantly moving target
<tgardner> kees, none of the kernel buildd's are SBs. you might ask VanHoof
<sconklin> aakshay___: are you interested in developing a new driver, or working on an existing one?
<JFo> it is a main reason all of the bugs require constant triage
<kees> tgardner: okay, cool. I was curious about some benchmarks.
<tgardner> kees, they are all laptops AFAIK
<aakshay___> as i am a begineer.. dont have much idea.. you suggest me.. :)
<kees> vanhoof: if you get some sandybridge systems that I can get access to for some builds, I'd be curious. not a priority at all, just idle curiosity. :)
<kees> tgardner: yeah. just a random bit of curiosity. thanks!
<aakshay___> sconklin: as i am a begineer.. dont have much idea.. you suggest me.. :)
<vanhoof> kees: I'm sure we can sort something out :)
<vanhoof> kees: after a desktop I assume?
<vanhoof> kees: the bulk of what we have out there now are mobile, but there are a few desktops scattered around the team
<kees> vanhoof: no real preference, just curious about some the CPU extensions
<kees> *some of the...
<vanhoof> all of them are presently in flux with a pretty awesome S4 issue :)
<JFo> vanhoof, you forgot the </sarcasm> tag
<JFo> :)
<kees> vanhoof: cool, yeah, if one goes idle, keep me in mind. consider me at the end of the line after any real work. :)
<kees> JFo: I sensed that tag :)
<sconklin> aakshay___: well, the two things that are important are to pick something you have hardware for, and to pick something that interests you. The way that a lot of kernel driver development is done is by sub-groups who work on video4linux, or audio, or any number of other things.
<sconklin> aakshay___: But to just experiment, if you can get to the point of building your own kernels, and loading and using a very simple 'hello world' driver, then you will have learned a lot
<JFo> kees, me too, but I was worried for the others ;)
<kees> hehe
<vanhoof> kees: bjf /may/ have a SNB desktop in hand, I want to say he was doing some builds there
<vanhoof> but i can see if i can sort one out for you once this s4 bug unwinds a bit
<vanhoof> we're nearly there
<aakshay___> sconklin: so i start with the "hello world" driver...?? 
<kees> vanhoof: cool; thanks
<sconklin> aakshay___: if there is one called that. I was using it as a dort of generic name. I can't find my copy of the book, but I think it has an example driver that just loads and unloads and is a basic shell
<bjf> kees, i have a sugar-bay SDP here at home, bryce has a variant as well (i delivered it to him)
<sconklin> aakshay___: but the very first things to do are to use git to fetch the kernel source and get it to build and make sure it runs on your machine. You should do that before you start writing any code at all
<sconklin> aakshay___: have you ever built a kernel?
<aakshay___> sconklin: no.. :(
<sconklin> ok, hold on while I find our wiki page about how to build the Ubuntu kernel. You should get that working before you do anything else
<aakshay___> sconklin: its my first time to be here on this channel..
<aakshay___> ok
<aakshay___> :)
<sconklin> aakshay___: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<aakshay___> sconklin: for this, first i will download the kernel from "git"
<aakshay___> then build as per instruions in wiki?
<Krunch> aakshay___: have you read much C so far?
<sconklin> aakshay___:  git is a user application tool used for source code management. You will use it to fetch a copy of the source code
<aakshay___> Krunch: yes.. i have been keep reading more and more of it
<aakshay___> :)
<aakshay___> sconklin: ok.. i will do this.
<Krunch> a good starting point is to build your own kernel, look at the CONFIG_* options and go see in the code how they are implemented
<aakshay___> and will finish with the LDD3..
<kees> bjf: ah, cool; I'll check with bryce and see if I can snag it for an afternoon
<Krunch> that should give you a good general idea of how the kernel works and what the code looks like compared to userland applications
<Krunch> but then, if you only want to write drivers that's not strictly necessary
<aakshay___> i have a confusion. here "ownKernel" is the one from Git? :)
<sconklin> aakshay___: own kernel means that you have compiled it yourself from source code instead of installed one that we built for you
<Krunch> build a kernel, from git or from ubuntu, doesn't matter much for a start
<aakshay___> ok.. so i will first build own kernel.. and then come back with problems if any.. :)
<aakshay___> sconklin: Krunch:  JFo:  thanks a lot for guidance..
<sconklin> aakshay___: I hope it helps ;-)
<aakshay___> thanks.. :)
<aakshay___> and will be back to ask more
<aakshay___> :)
<aakshay___> good bye... :)
<JFo> thanks sconklin 
<bjf> JFo, amber had an easy way to find all the wiki pages under a certain path, do you remember that ?
 * JFo thinks
<JFo> let me see if I have it marked... one sec...
<JFo> hmmm, I don't see it
<JFo> akgraner, do you happen to have that wiki link for all kernel pages?
<apw> bjf i think that is described under macros in the wiki help which you get to from the bottom of an edit page
<bjf> apw, looking
<apw> we use something link it in the faq edit page i think
<apw> <<PageList(Kernel/FAQ/)>>
<apw> something like that in your page would do it
 * jjohansen -> lunch
<bjf> apw, is there some way to know where the "Action" wiki pages have been included so one could look at them in context to see if they make sense ?
#ubuntu-kernel 2011-03-04
<fairuz> I tried to open remote file (mounted over SSH) using gedit but gedit hangs
<Krunch> fairuz: if you think it's a problem with the software and not with your network or the remote system, get a gedit and kernel stack trace (pstack and sysrq-t) and open a bug
<fairuz> Krunch: ok ty
<fairuz> what is the equivalent function of ioremap in user space?
<fairuz> mmap?
<Ampelbein> hi there! when trying to run qemu-kvm I get a "BUG: unable to handle kernel NULL pointer dereference at 00000014", full dmesg report at http://paste.ubuntu.com/575485/. Is this a known issue? If not, what more information do you need if I file a bug?
<herton> Ampelbein, I don't know if it is a known issue, but this oops is a valid reason to report it, to file bug against the kernel you can follow instructions at https://wiki.ubuntu.com/Kernel/Bugs
<herton> Ampelbein, also make sure you attach the same oops of pastebin to the bug report
<Ampelbein> herton: will do that, thank you!
<flag> smb: ok
<flag> smb: here i am
<JFo> <-lunch
<JFo> ok apw, the list is updated
<pmatulis> how do i install Server with the lts-backports kernel?  i thought it was supposed to be on the DVD but that installs the Desktop
<pmatulis> ok, release notes suggest the lts kernel is used by default
<kees> apw: you've done the aufs merges in the past, yes? I've hit a really odd situation where hardlink restrictions are getting triggered on aufs (liveCD). does anything about this jump out at you? bug 729338
<JFo> brb
<kamal> Wha?... the natty kernel 'master' branch FTBFS in PPA (but is fine on tangerine)...
<kamal> http://launchpadlibrarian.net/65638703/buildlog_ubuntu-natty-amd64.linux_2.6.38-5.32%2Bkamal~NOCHANGE_FAILEDTOBUILD.txt.gz
<kamal> arch/x86/kernel/entry_64.S:1544: Error: .size expression does not evaluate to a constant
<kamal> entry_64.S:1544 (last line of the file):         .popsection
<jjohansen> kamal: what arch?
<kamal> blows up the same way in amd64 and i386
<jjohansen> i386 was failing on tangerine this morning
<jjohansen> kamal: yeah that is the failure we were seeing this morning
<kamal> i've only tried amd64 on tangerine, and that continues to be fine
<jjohansen> we assume its because of a new tool upload
<kamal> *sigh*
<jjohansen> and that the i386 chroot was updated but not amd64
<kamal> sounds like a very logical analysis
<jjohansen> but ppa would see both updated
<jjohansen> you can build in the maverick chroot and it works
<kamal> yeah, maverick is just fine (tangerine and PPA)
<kamal> jjohansen: yup, confirmed -- I'm getting it on i386 but not amd64 on tangerine.  thanks for the info!
<kamal> s/getting it/getting the problem in natty/
 * jjohansen has just been reminded of a dentist aptmnt
<jj-afk> back on in a bit
<JFo> k, see you guys monday
#ubuntu-kernel 2011-03-05
<psusi> say, is the natty kernel going to resync with linus's tree again soon?
<psusi> it's been a while and there's an important bug fix that's been pending for a week
<jjohansen> psusi: yes it will happen soon
#ubuntu-kernel 2011-03-06
<hajni> hello, I've just reported my first kernel-related bug, and I am not sure whether I have provided all the necessary info
<hajni> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/730212
<hajni> would someone please have a look at it?
<kklimonda> hey, anyone can tell (or point to an explanation) me why did you release kernel that so mane CVEs, some of them from 2009?
<genux> hi
<genux> I am getting a error when trying to compile the 11.04 kernel alpha 3
<genux> 2.6.38
<genux> /usr/src/linux-2.6.38/arch/x86/kernel/entry_64.S: Assembler messages:
<genux> /usr/src/linux-2.6.38/arch/x86/kernel/entry_64.S:1544: Error: .size expression does not evaluate to a constant
<genux> is the error
<genux> any ideas
#ubuntu-kernel 2012-02-27
<jMCg> I'd argue one of the basic operations of an OS is to boot. If it can't do that, then something's going wrong.
<jMCg> Wonderful, after installing the kernel from oneiric-proposed, it still doesn't boot.
<ppisati> moin
<smb> morning
 * apw waves to smb
 * smb waves back
<ppisati> *reboot after dist-upgrade
<jMCg> https://bugs.launchpad.net/ubuntu-release-notes/+bug/818177/ (#128)
<ubot2`> Launchpad bug 818177 in udev "boot failures as /dev is not transferred to /root (because 'udevadm exit' times out waiting for a deadlocked worker)" [High,Fix released]
<jMCg> So, after six hours it's still dead-locked, yes.
<smb> A lockup that long does not sound like the initial problem
<apw> henrix, morning
<apw> jMCg, what are you seeing exactly, and are you using lvm
<henrix> apw: hey, morning
<cking> smb, http://awaseconfigurations.wordpress.com/2011/11/21/automated-ubuntu-release-upgrade/ 
<smb> cking, Ah thank, guess I have to fold that into doing it through do-release-update. At least that has a frontend option as well iirc. It just did not explain much. And the dpkg env variable theoreticall should pass it as well...
 * smb will reset the vm and try
 * cking wishes smb luck
 * smb needs to re-adjust coffee levels first, though
<jMCg> apw: the kvm's installed on an LVM partition. It doesn't use lvm by itself (I even uninstalled the lvm2 and mdadm packages from the VM images)
<jMCg> What I pasted is what I see in the end, of course I can paste the entire boot process.
<smb> jMCg, And the problem is the kvm guest that does not boot? 
<jMCg> smb: it doesn't finish booting. It starts, which is great progress!
<smb> At least that could make it less likely related to the initial problem. Is that guest running with the graphical splash screen or a server install coming up in text mode? 
<smb> Not sure whether one can send kvm magic sysrq-keys... That might be one way to find out what is blocking...
<jMCg> smb: I'm on the serial console thingy, I don't think it's got any splash stuff installed. (It's based on my ISP's minimal image, I don't think that has any splash stuff)
<smb> jMCg, Hm, ok so a blind stab would be to try press 's' when it hangs. 
<smb> There had been cases in the past when mountall was waiting for something but did not print a message when there was no plymouth
<jMCg> Oh... plymouth is installed, wonder why
<jMCg> mountall depends on plymouth. that explains it, I guess.
<jMCg> ii  plymouth-theme-ubuntu-text       0.8.2-2ubuntu28                         graphical boot animation and logger - ubuntu-logo theme
<jMCg> Okay, waiting for the 61 timeout to finish.
<jMCg> smb: pressing s does nothing.
<jMCg> Just as a reminder: I'm booting the kvm, I'm connected to it via serial console
<smb> jMCg, Ok, but I guess you have something like console= in the kernel arguments, otherwise you would not see anything in that serial console...
<jMCg> smb: yeah.
<jMCg> http://sprunge.us/VFch
<jMCg> nomodeset, cute.
<jMCg> Well, it was late and I was desperate.
<apw> jMCg, ok the fixes that went in on the bug you mention fixed the issue triggering that bug, therefore you must have a different if similar issue, so it'd be good to have your own bug, as noone is going to look at that closed one
<jMCg> I didn't realize it was closed.
<apw> yeah i had a system i could actually reproduce that specific issue and we found root cause and fixed that one
<apw> i believe at least
<jMCg> apw: okay. So, what do I call this bug, and how do I provide more info?
 * apw is thinking
<apw> i would title it something like 'boot hanging at "<whatever the last line of console output>" to start with
<apw> and i would like to see the whole log at least on that bug
<smb> Question would be to find out where it is hanging/waiting. So like apw said and having the dmesg from the serial console
<jMCg> virsh start ; virsh console > log should be easy to give you that.
<smb> probably add a debug to the kernel arguments
<smb> I mean "debug" as an option
<jMCg> s/nomodeset/debug/
<smb> and what was that other one for startup
<smb> keep the nomodeset
<apw> yep
<apw> and add --debug as well
<smb> at least prevents the kernel from trying fancy graphics where you don't really need
<apw> which gets to upstart in case we are getting that far
<jMCg> I don't have a graphics card configured :)
<smb> Ah, ok. Probably won't make a difference but neither does hurt then
<apw> jMCg, yeah i _think_ we are making it into the main root
<smb> apw, initcall_debug?
<apw> will make his buffer be very big, so initially i think i'd leave that one off
<jMCg> Well, there's some ugly formatting.
<apw> so i think its getting to real root, as we have run and completed 'init-bottom' which kills udev off
<apw> and then we have udevd starting some time later, over 1s, which i believe should be only occuring in real root
<apw> so you definatly have a different error, as the error on that bug, we get stuck in init-bottom
<jMCg> Heisenbug!
<jMCg> Sweet. When I add debug --debug, it doesn't get post-start.
<apw> 'post-start' ?
<jMCg> http://sprunge.us/igSh
<apw> bah i hate serial ports which lose charactes
<apw> [    3.8 console-setup main process (347)   3.893235] init: console-state changed from spawnost-start
<jMCg> The best part is that this is an emulated serial port ;)
<apw> ok so that mess has enough in it to tell us we got as far as upstart
<jMCg> I'm gonna send it a shutdown command and see what that does.
<jMCg> http://sprunge.us/SIQC not much.
<apw> so it responded, and shutdown as far as i can see
<apw> it ran rc scripting at least to try and kill stuff
<jMCg> So from what I gather, we're past mounting / in the right place.
<apw> long past that yes
<apw> as soon as all the init: stuff comes out in the --debug mode, we are running that in the real root
<apw> [    1.7 linear personality registered for level [    1.74271path personality registered for leve[    1.827 (vda): mounted filesystem with ordea mode. Opts: (null)
<apw> Loading onfiguration from /etc/init.conf
<apw> that is the disk coming online and us flipping over
<jMCg> So, what's the next point to get stuck?
<apw> jMCg, heh there are no sensible points to get stuck
<jMCg> I'd argue that getting stuck at all in a boot isn't very sensible, but then I've passed the point of sensibility a long time ago.
<smb> jMCg, Just to be sure this is not something there. If you can extract the /etc/fstab from the lv you use as root
<apw> jMCg, well what i am saying is there are no know points to get stuck
<jMCg> The job of an OS is to manage resources. If I spend 4 days trying to get it to boot, that's a terrible waste of my resources :-/
<apw> jMCg, yep and we're trying to help
<apw> you asked where is the place i expect a hang, i told nowhere
<jMCg> apw: thanks
<jMCg> So, /etc/fstab from the kvm?
<apw> jMCg, ok so advice is to boot with --verbose instead of --debug and add --no-log in case
<apw> that might get us less output so we can read it
<jMCg> http://sprunge.us/fNUY
<jMCg> New command line for the kernel:
<jMCg>     <cmdline>root=/dev/vda ro serial=tty0 console=ttyS0,38400 nomodeset debug --verbose --no-log</cmdline>
<jMCg> sweet! That looks readable!
<apw> yeah that looks fine
<apw> thats something at least
<jMCg>  http://sprunge.us/BiSi
<smb> Hm
<smb> jMCg, Have you sshd running
<smb> Or other thing, is there a /etc/init/ttyS0.conf to actually bring up a login session on the serial console?
<jMCg> smb: last time I checjked, there was one. But I'll check again.
 * ppisati -> out for lunch
<smb> jMCg, No, I guess then it is still there
<smb> Just going through my memory of things that had been failing and looking similar
<jMCg> gah.
<smb> The virtual fs stage seems to be waiting
<apw> jMCg, ok ... can you try creating /etc/init/procps.override in the image containing the word 'manual'
<apw> and try booting it again
<jMCg> apw: first, I'll re-dd ttyS0.conf
<jMCg> Which magickally got lost since last week.
<jMCg> So, right now, I feel like punching myself in the face.
<jMCg> apw: thank you.
<apw> so was that a missing ttyS0 config ?
<apw> jMCg, ^
<jMCg> So, between the real issue, which hung up the domains, and my ghost issue, I (accidentally) axed ttyS0.conf and have been wondering why it doesn't boot ever since.
<apw> smb, you win a cookie
 * smb munches
<jMCg> The real issue was fixed with the udev/and or kernel upgrade (in the Host), this here should be fixed by head-desking ;)
<jMCg> freaky. This thing actually works. O_o
<jMCg> I appear to have done a pretty decent job creating my vm image. Except for that ttyS0.conf thing :D
<apw> heh we hope most of the time
<smb> Unfortunately no login tty and hanging rather look similar from a console. ;)
<jMCg> RFE: put a ttyS0.conf in by default
<apw> thats kinda image specific, as i don't have a S0 most of the time
<jMCg> Neither do I, except with KVMs and servers.
<apw> sadly even in virtual ones it differes depending if its kvm or xen
<jMCg> :-/
<smb> Yeah, at least differently named
<jMCg> There needs to be a unified way of managing servers (real or virtual ones) if there's no ethernet connection, or the OS is otherwise not up and running.
<jMCg> Oh, and it should be cheap and secure.
<apw> a nice utopia indeed
<jMCg> Yeah.
<smb> At least that way makes people earn their money by knowing where to hit with the hammer... ;)
 * henrix will be back in ~20m
<herton> ppisati, do you know someone who can verify bug 927526 against latest ti-omap4 proposed?
<ubot2`> Launchpad bug 927526 in linux-ti-omap4 "missing support for some LIRC devices" [Undecided,Fix committed] https://launchpad.net/bugs/927526
<ppisati> herton: community only i guess
<ppisati> herton: personally i don't have any IR receiver/transmitter (maybe my tv remote?!?!?! :) )
<herton> ppisati, ok, will try pinging reporter on that bug
<ppisati> the sticking edge on the other screen is just annoying
<apw> ppisati, on the other screen ?
 * ogasawara back in 20
<ppisati> apw: yes, in a dual screen setup, on the left i've email + terminal (stacked) and on the right i've chrome
<ppisati> apw: and when i move to the right one, i find it to be a *royal* pain to go back to the left one
<ppisati> apw: since i've to rush the mouse pointer else it gets stuck over there
<ppisati> it's just innatural
<apw> ppisati, yep i hate it too, the gluey ness is configurable, in ccsm
<smb> ppisati, Maybe you need to think of it as like you have to break through the monitors edges to get to the other screen... :)
<ppisati> apw: i just tried U3d, i'll probably go back to 2d: less resources, and it doesn't have this feature  :)
<ppisati> smb: or probably i should stop going over there altogether
<apw> heh, well its good someone tests 2d, as it is supported
<manjo> herton, https://bugs.launchpad.net/linux/+bug/925552 verification done 
<ubot2`> Launchpad bug 925552 in linux "[12.04] Broadcom Bluetooth device (Vendor=0a5c ProdID=21f3) not supported" [High,In progress]
<herton> manjo, yep, everything is ok now. I released oneiric for testing this morning
<manjo> oh cool thanks a ton 
 * cking grabs a coffee
 * henrix follows cking
<pgraner> cking, ping
<cking> pgraner, pong
<pgraner> cking, hey on your sandybridge laptop are you seeing high fan useage recently? 
<cking> pgraner, nope, it's running relatively quietly
<pgraner> cking, powertop is estimating its using 9.4w to run it 
<pgraner> cking, that seems like a lot of juice
<cking> I am running with UEFI as the default
<cking> pgraner, ah, well, powertop results may be a bit iffy if you run them for too short a period. use my powerstat tool instead and see what it reports
<pgraner> cking, ok, powertop has been running for over an hour (box is on battery)
<cking> let me look up my latest power usage stats
<cking> I was getting ~8.8W on a default clean install with the latest Precise kernel on Saturday
<cking> w/o RC6 it was consuming  ~17W
<cking> pgraner, you could try: https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues
<cking> (best to try power-usage-report, about 1/2 down the wiki page)
<cking> the X220i that I've got is an i3-2350M with BT disabled too
<amitk> cking: some scary (as in wrecking the scheduler -scary) bed-time reading for you in case you haven't seen this yet: http://lwn.net/Articles/482344/ , https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/HMPscheduling
<cking> amitk, eek, more data ;-)
<amitk> cking: lots more data :) , but if you have an input, I'd love to hear it
<cking> amitk, no "fix the broken apps" items on the action points then?
<amitk> cking: -EMAKEPROGRESS
<cking> amitk, how about "why do so many apps do such low poll() timeouts and causes dozens of unnecessary wakeups? ;-)" 
<pgraner> cking, ok powerstat show avg power use at 10.3w 
<pgraner> cking, powertop lies, lies, lies
<cking> pgraner, well, powerstat applies some sneaky sliding window averages, so we are comparing apples vs pears so to speak
<amitk> cking: that was solved by powertop, but I've been thinking about a new cgroup type to catch these sorts of apps in automated testing - multi-stage cgroup that only delivers a certain percentage of wakeups to the apps at each level. At L1 you get 100% of your wakeups, if you wake up too many times, you get demoted to L2 where you only get 75% of your wakeups, so on and so forth...
 * amitk waves to pgraner 
<cking> amitk I was thinking more like the OOM style killer for badly behaving apps that do poll() with a zero timeout ;-)
 * pgraner waves back at amitk
<cking> amitk, sometimes wakeups are legitimate, eg. perhaps audio/video requires it on AV sync. however, sometimes it is just badly written apps
<amitk> cking: which is why OOM would be a big hammer. I'd like to run then entire application stack in this new cgroup type and see how many end up in L2, L3, go correlate with what the ongoing activity was, and if necessary go fix them.
<amitk> s/run then/run the/
<cking> amitk, yep, I was being joking about OOM ;-)
<amitk> cking: heh :)
<Amoz> hi cking :) about the RC6 testing, intel_reg_dumper doesn't return any rc6 register, is this normal?
<Amoz> looks like it's the same for all of us..
<cking> Amoz, yep, it is consistently "none"
<Amoz> and that's why you check it, I suppose...
<Amoz> cking, have you checked the results recently? if so, do you think rc6 will be enabled for precise? 
<cking> Amoz, it is our intention to
<cking> ogasawara, I see you added to the RC6 power testing the request for intel_reg_dumper data - everyone is getting "None" for that 
<Amoz> cking, could other i915 kernelparams interfere with the results?
<Amoz> I ran my test with fbc=1, lvds_downclock=1
<cking> Amoz, potentially, so best to test w/o the other i915 options so we can compare like for like in this table. 
<Amoz> cking, I'll rerun my test then
<Amoz> without other params
<cking> but it is also valid to test with fbc=1 etc as these may save a little bit more power, but we are not going to use these by default for precise because of the associated risk that they may cause other bugs 
 * tgardner reboots to test AA patches
<cking> Amoz, thanks for testing!
<ogasawara> cking: hrm, lemme double check.  I'd gotten that from eugeni.
<Amoz> cking, no thank you for making my computer perform better!
 * cking likes to point out this one wasn't his work at all ;-)
<cking> amitk, that's a lot of info to digest, I may get back to you later on those links
<ogasawara> cking: RC6 state output via intel_reg_dumper is only available in intel-gpu-tools v1.2, and it looks like we've only got v1.1 in Precise.  I think I'll just remove it from the wiki for now and let eugeni know.
<cking> ogasawara, ah, that explains it, I couldn't see what I was doing wrong on Saturday when I ran this and got no output.
<amitk> cking: sure thing, it was meant for you bed time light reading anyway ;)
<cking> amitk, the synthetic simulation of smart phone apps is going to be hard to do - that requires a lot of data gathering and some deep analysis to understand different use-cases correctly.
<amitk> cking: we want to start with simple models first which I suspec will be similar to a desktop usecase model (except for the input sources) e.g. web browsing, mp3 playback, video playback, etc.
<cking> amitk, yep, chose some misbehaving apps to ;-)
<Amoz> cking, updated, almost the same results
<cking> Amoz, thanks, that was to be expected, we just wanted to see if it fixed any existing issues or threw up any new ones - thanks for testing - it is good to see that your data does not vary much at all between test - that's a good sign!
<Amoz> cking, yeah I know. especially the low std deviation is good I assume :)
<cking> yes, that makes me very confident ;-)
<Amoz> cking, is there anything else one can do to exercise the rc6 code?
<Amoz> and while I'm at it, how can one start contributing to the kernel team?
<cking> Amoz, do you normal work on the desktop, watch videos, etc and see if you can spot any issues.
<cking> (for rc6)
<cking> Amoz,  there is always a load of bug triaging and stuff - perhaps talk to jsalisbury about this
<jsalisbury> Amoz, We can *always* use help triaging :-)
<Amoz> I guess everyone need to start out with the triaging stuff before doing development :)
<Amoz> jsalisbury, I figured
<jsalisbury> Amoz, there are some good documents available at:
<jsalisbury> Amoz, https://wiki.ubuntu.com/Kernel/BugTriage
<Amoz> I've read some
<Amoz> still doesn't make me a good triager
<Amoz> :(
<Amoz> but I suppose one need to know everything there
<jsalisbury> Amoz, Not everything.  Basically just start of with one bug at a time
<jsalisbury> Amoz, Testing is also another area that is of great help.  Especially if you can reproduce a bug easily.
<Amoz> jsalisbury, I guess stacktrace dumps are very helpful for crashes etc?
<jsalisbury> Amoz, sure, when we can get them.
<Amoz> jsalisbury, so what bugs should be triaged? undecided - new, unknowns - new ?
<Amoz> jsalisbury, if something's in the wiki, just direct me there
<jsalisbury> Amoz, we have a bug bot that checks for all required information and then changes to "Confirmed".  Those are the bugs that need to be triaged.
<jsalisbury> Amoz, this is a good link for the various bug states:
<jsalisbury> Amoz, https://wiki.ubuntu.com/Kernel/BugTriage/BugStates
<jsalisbury> Amoz, the #ubuntu-bugs channel on Freenode is a good place to go to.  There is also some good info at:
<jsalisbury> https://wiki.ubuntu.com/BugSquad/KnowledgeBase
<jsalisbury> Amoz, The previous wiki link I mentioned has lots of info, but is focused on all Ubuntu packages, not just linux package.
<Amoz> jsalisbury, thanks, already aware of them
<jsalisbury> Amoz, cool
<ogasawara> jsalisbury: was just reading your status... bug 914161, have you had them test a more recent Precise kernel?  We disabled CONFIG_INTEL_IOMMU_DEFAULT_ON a while ago due to issues it was causing.
<ubot2`> Launchpad bug 914161 in linux "Linux 3.2 freezes system on FUJITSU ESPRIMO P7935" [Medium,Confirmed] https://launchpad.net/bugs/914161
<jsalisbury> ogasawara, I will confirm he is running 3.2.0-17.27
<ogasawara> jsalisbury: ah nm.  just saw their recent comment.
<ogasawara> jsalisbury: based on their comment, you can close it Fix Released.
<jsalisbury> ogasawara, I'll still confirm what he means by "Latest" kernel
<ogasawara> jsalisbury: he gave uname -a output in comment #68, shows 3.2.0-17
<jsalisbury> ogasawara, ahh, cool.
<ogasawara> jsalisbury: we intend to keep iommu disabled by default
<jsalisbury> ogasawara, great, I'll mark as fix released and update the bug.
<Amoz> are there any sources for the bot scripts you're using?
<jsalisbury> ogasawara, thanks
<jsalisbury> Amoz, The following wiki describes them:
<jsalisbury> https://wiki.ubuntu.com/Kernel/kteam-tools
<bryceh> Amoz, https://code.launchpad.net/bugbot
<Amoz> jsalisbury, bryceh, thanks
<htorque> jsalisbury: hi! bug 808384 - i'm not seeing it with the current mainline kernel - do you think it's worth it testing again with a vanilla kernel 3.2 with ubuntu's config?
<ubot2`> Launchpad bug 808384 in linux "[drm:drm_mode_getfb] *ERROR* invalid framebuffer id (FujitsuSiemens Amilo Pi 2530 Hotkeys)" [Medium,Triaged] https://launchpad.net/bugs/808384
<jsalisbury> htorque, Or possibly the latest precise kernel.  I'll post a link in the bug.
<jsalisbury> htorque, ahh, wait, you already tested 3.2.0-17-generic, correct?
<htorque> yes
<htorque> jsalisbury:  i'm building the 3.2.7 vanilla with 3.2.0-17-generic's config now
<jsalisbury> htorque, ok, can you post your results to the bug.  
<htorque> sure, will do
<apw> htorque, the mainline kernels are built ubuntu's configs ?
<htorque> apw: oops, i bookmarked http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/ - never knew there are older kernels available too !:-)
<htorque> thanks, that should save some time ;-)
 * cking -> EOD
 * apw gets something to work as intended instead of exploding ... sounds like time to quit to me
<jjohansen> apw: nice, run don't walk don't walk, if you look back it might break
<htorque> jsalisbury: also got the warning/error message with the 3.2.7 mainline kernel, so it sounds like this has been fixed upstream, right?
<jsalisbury> htorque, sounds like it.  Are you able to test the latest v3.3-rc5 kernel?  It is available from:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc5-precise/
<htorque> jsalisbury: can test it, though it's older than the daily one i tested
<jsalisbury> htorque, if the bug exists there, we will want to open a bug upstream.
<htorque> ok, on it
<jsalisbury> htorque, great, thanks.
<htorque> jsalisbury: doesn't seem to be in 3.3-rc5 either :-)
<jsalisbury> htorque, but it does happen in 3.2.7 mainline?  That would indicate a bug in 3.2 stable.
<jsalisbury> htorque, that was fixed in 3.3
<htorque> right, it's there in 3.2.7, it's gone in 3.3-rc5
<jsalisbury> htorque, thanks for testing.  I'll do some upstream searches and see if the fix in 3.3 has been queued up for 3.2 stable.
<htorque> jsalisbury: np! verified the results on a second system and also the new 3.2.8 seems affected.
<jsalisbury> htorque, great, thanks. 
<jsalisbury> htorque, I posted some additional comments to the bug report.
<htorque> jsalisbury: the ftrace commit is also in 3.2.8
<htorque> so that's not it
<htorque> it seems fixed with 3.3-rc1 but that's a lot of commits...
<jsalisbury> htorque, do you see any additional messages in syslog when you reproduce the error?  
<htorque> no, it's just "[drm:drm_mode_getfb] *ERROR* invalid framebuffer id"
<jsalisbury> htorque, ok, I'll do some more investigation
<jsalisbury> htorque, is anything written to your /var/log/Xorg.0.log log file?
<htorque> jsalisbury: yes! http://paste.ubuntu.com/859764/
<jsalisbury> htorque, thanks, that give some more to search on.
#ubuntu-kernel 2012-02-28
 * apw yawns
<smb> apw, morning
<apw> smb, moin
 * smb checks his clock
<smb> apw, btw changing the workplace switch keys to super+ctrl work much better for my mind. Now maybe I should file a bug that the shortcut help screen still displays the old binding... >:-)
<lifeless> definitely should do that
<apw> smb, heh, you should tell didrocks cirtainly, that you had to change it to stop your fingers falling off
<smb> meh, I probably will just get told that help screens are supposed to show the divine supposed to be configuration... Also I had the feeling that the key bindings (default) may change again after many users expressing their joy with super-shift
<apw> you should file a bug that you changed them an its not right, that seems sensible
<smb> Actually it was not so much the fingers, but imagination or not, it felt like that typers thing (aching things in lower arm)
<smb> OK, maybe I really should really file it...
<smb> ...yet another one
<apw> smb carple tunnel, and yep a simple binding can easily cause that
<bullgard4> Red Red offers a "Netdump" crash dump facility.  What is the nearest Ubuntu program to it?
<apw> bullgard4 what does it do
<apw> take crash dumps and shove them over the network somewhere ?
<bullgard4> "Unlike traditional crash dump facilities, this facility dumps memory images to a centralized server via the network. "
<bullgard4> "The goal of a crash dump facility is to provide fault analysis, particularly exhaustive first fault analysis (first fault analysis is when a bug can be corrected without requiring reproducing the bug), in the case of software or hardware bugs that manifest as system crashes (in Linux parlance, Oops, BUG(), or panic). "
<apw> we have crash dumping indeed, not sure if there is any support for remote deliver of those immediatly when the dump is taken
<apw> though that is only a matter of what you put in the crash initrd
<bullgard4> Ah! Thank you for commenting.
<apw> i think we did have some discussions on this sort of thing, but its more a server need than anything.  so i would suggest asking on #ubuntu-server as well, they may remember or have pointers
<apw> smb, whats the crash package called again, i keep forgetting
<smb> apw, crashdump?
<apw> ahh here it is linux-crashdump
<apw> looking for crash is a mistake it seems
<apw> bullgard4, ^
<smb> crash is the tool to look at the dumps
<bullgard4> apw: Excellent! I will get acquanted with the DEB program package Â»linux-crashdumpÂ« (because I have infrequently kernel crashes). -- Thank you very much.
<bullgard4> s/acquanted/acquainted/
<ppisati> if it's just a matters of oops&c, why don't you configure syslog to send all the stuff abroad?
<smb> ppisati, I think working crash-dump gives you the whole memory + registers of the time of the crash
<ppisati> i see (and that being said i take swallow another coffee)
 * smb needs a refill
<smb> apw, btw, there seems to be kdump-tools as well, not that I would know what the differences would be...
<apw> smb, seems linux-crashdump pulls all of those in
<smb> apw, Hm, interesting, saw only kexec-tools, makedumpfile and some grub depends and a crash suggest...
<_ruben> what are the chances of network being operational after a kernel crash??
<Kano> hi
<Kano> when you compare
<Kano> http://packages.debian.org/wheezy/amd64/linux-headers-3.2.0-1-amd64/filelist
<Kano> against
<Kano> http://packages.ubuntu.com/precise/amd64/linux-headers-3.2.0-17-generic/filelist
<Kano> you should notice that include/generated/compile.h is missing, why?
<Kano> is it missing because of include/config/cross/compile.h ?
<Kano> the problem is that you need that file when you use the debian nvidia-dkms package. it should be included in the u package as well
<RAOF> Kano: Why would you use the debian nvidia-dkms package?
<Kano> because i use the kernel on debian!
<Kano> but thats a packageing fault, has nothing to do with the distro
<apw> Kano, likely the layout has changed and we haven't followed it, and nothing has noticed
<apw> Kano, can you file a bug against 'linux' and tell me the number
<Kano> against precise?
<apw> Kano, against linux the package, that'll go againstr precise by default yes
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/942569
<ubot2`> Launchpad bug 942569 in linux "missing include/generated/compile.h" [Undecided,New]
<Kano> apw: i see you updated the bug. hope you find the issue why the file is missing. i think you already cp include but maybe too early?
<apw> Kano, nope compile.h is a special and doesn't get made when you ask the kernel tree for the headers 
<apw> which frankly is rather crap
<Kano> ah
<Kano> maybe you see how debian did that
<Kano> it shows similar if as /proc/version
<Kano> just with defines
 * tgardner reboots tangerine
<apw> Kano, yep, its beyond me why it would be needed by this out-of-tree crap in the first place
<Kano> in theory even an empty file fixes the compile, it just has to be there
<tgardner> if that is the case, why not fix the OOT code ?
<Kano> i dont know where this file is included
<Kano> but you see it in the make.log as missing
<Kano> what i want is that i could use the same dkms code for nv with d and u kernel
<Kano> if i use the code for u kernel it fails with d and vice versa
<ppisati> tgardner: hold on before uploading the M/omap4 kernel
<tgardner> ppisati, I'm letting the stable team upload M kernels.
<ppisati> ah right
<tgardner> ppisati, how about P kernels ? do you need one of those ?
<ppisati> tgardner: i'll wait for ogasawara's rebase of 3.2.8, i saw gkh released it yesterday
<tgardner> ppisati, 3.2.8 only contains x86 cruft, e.g., FPU corruption fixes (I think)
<ppisati> tgardner: ok, then go ahead
<tgardner> ppisati, ack
<ppisati> tgardner: watch out since it's complaining about a missing module
<tgardner> ppisati, already fixed and pushed
<ppisati> cool, thanks
<tgardner> ppisati, the last rebase for ti-omap4 was against Ubuntu-3.2.0-16.25. perhaps you should bring ti-omap4 up to date ? there are some YAMA patches that are relevant.
 * apw notes we don't produce reminder bugs for precise
<ppisati> tgardner: ok, i'll do, hold on
<tgardner> ppisati, reset you ti-omap4 HEAD to 3643ea0b470b40ca53d2f870df6e3ade07e11b5b before you start your rebase
<herton> ppisati, about maverick kernel, the config change should fix the QA failure right?
<ppisati> herton: yep, but i had an headless installation so i'm testing the sgx binary driver (see apw's email about it)
<herton> ppisati, ok, once you do and everything is ok, let me know, do you want to open a new tracking bug for it and push a new branch for pulling?
<herton> otherwise I just apply if it tested ok and I do the release process (new tracking bug etc.)
<Kano> tgardner: dont forget to fix fglrx for 3.2.8
<tgardner> Kano, fglrx isn't my problem. I think its alberto milone
<hallyn> gah complete hang on vostro, no crash or sysrq response or anything (uptopdate precise)
<jwi> tgardner: re bug 942256, you sure that those two will work without having hv_vmbus.ko on the inclusion list?
<ubot2`> Launchpad bug 942256 in linux "HyperV modules missing from -virtual flavor" [Undecided,Fix committed] https://launchpad.net/bugs/942256
<jwi> oh, and this closes bug 560821 as well
<ubot2`> Launchpad bug 560821 in linux "No hyper-v modules on linux-generic-pae/virtual" [Medium,Confirmed] https://launchpad.net/bugs/560821
<tgardner> jwi, looks like 560821 is now a duplicate
<tgardner> of 942256
<jwi> yeah, not sure if microsoft renamed or killed the block driver...
<apw> tgardner, i can have a look, as i did the bits to get the right drivers into initramfs, so i should know the list
<tgardner> jwi, I'm not sure what you'r first statement meant. are you implying that the 4 hv modules in the bug report are not sufficient ?
<apw> tgardner, there are 5
<apw> hv_vmbus hv_utils hv_netvsc hv_mouse hv_storvsc
<jwi> tgardner: you only added two new files.
<tgardner> I thought mouse got dropped
<apw> tgardner, oh bugger have the names changed _again_ with the update to 3.4
 * apw hates upstream sometimes
<tgardner> apw, I think its now hid-hyperv
<tgardner> but is it really needed for -virtual  ?
<jwi> tgardner: duh, utils and vmbus are in the initramfs - sorry for the noise.
<tgardner> jwi, np
<apw> tgardner, hmmm there is a question, if you are going to use the mouse with a VM then perhaps so
<apw> potentially it is running connected to your X display or whatever you have in hyper-v
<tgardner> apw, its easy enough to add. lemme take care of it
<brendand> herton, bjf - quick note to say that the Lucid kernel is probably going to be finished by Thursday, maybe Friday
<bjf> brendand: ack
<tgardner> apw, hid-hyperv.ko needs unknown symbol hid_allocate_device, which means more shit in the -virtual flavour. I'm thinking anyone who has X installed can also install the linux-image-extra deb to get hid-hyperv. agreed ?
<apw> tgardner, i guess the simplest approach is to not add it, and see if anyone screams
<brendand> bjf - point releases always put a lot of strain on our resources
 * ogasawara back in 20
<apw> tgardner, bah union-mounts is rearing its ugly head again, and the overlayfs maintainer remains very quiet
<tgardner> apw, he's on LKML but won't respond to you
<apw> tgardner, and union-mounts is 73 patches of doom
<tgardner> apw, did I see a merge request for union-mounts ?
<apw> tgardner, i haven't seen that yet, the patch spew looked to be an RFC to me
<apw> but it doesn't make it any more likely we are betting the right horse
<tgardner> ah, couldn't remember
<apw> that with the current issues i have with semantics for inotify
<apw> i am all a dither as to the best way forward
<tgardner> apw, still the lxc guys whinging about overlayfs ?
<apw> yeah, lots of packages rely on inotify, like upstart does so it does't see new jobs
<apw> so a lot of things need fixing if inotify is not available
<tgardner> apw, have you tried aufs lately ? I saw that it gotupdated
<apw> tgardner, i have touch tested it though its not enabled
<apw> tgardner, i am keeping it around in case we end up having to keep it available for these use cases
<tgardner> apw, well, we could re-enable it and let the lxc dudes have a go at it
<apw> phhhh, yeah we could indeed, i just didn't want to have to support both
<tgardner> apw, though I have to wonder why all of these apps are depending on a kernel feature that is not mainline
<tgardner> can we tell them all to just pound sand ?
<apw>  tgardner inotify i mainline, it just doesn't work on overlayfs
<tgardner> ah, right
<apw> ie the apps work fine on a real root
<tgardner> how does ecryptfs do it? can we steal that logic ?
<apw> and i've gotten most of the way with overlays, adding support but there is a semantic
<apw> difference on overlayfs files which bugger some use cases
<tgardner> the 'tail -f' case ?
<apw> specifically the tail type use case, monitoring a file for change case
<apw> if the file gets copied, that consumer can get confused
<apw> that and my patches are vile right now
<apw> s/copied/copied up to the rw layer
<tyhicks> I missed the backscroll, but I think we're talking about why inotify doesn't work on overlayfs?
<apw> yep
<apw> so i have some patches which in concept resolve the lack of notity
<apw> by mirroring the underlying notifications up
<tyhicks> interesting
<apw> but that doesn't help with the semantic issues for copy_up against already open files
<ppisati> herton: go ahead with M/omap4
<herton> ppisati, ok
<apw> tyhicks, ie you get a correct file size change notification, you re-fstat and the file is unchanged
<apw> cause you are conncted to the wrong one
<tyhicks> ugh
<apw> tyhicks, now if that idiom is isolated to tail, then moving it to stat against the filename likely could fix it up
<apw> but .. is that common or uncommon idiom
<tyhicks> yeah
<tyhicks> I'm glancing through the code now, but it is architected quite a bit different than eCryptfs - I don't think I'll have any great ideas here
<apw> yeah it does passthrough of the open, you can't and don't want to do that
<apw> and perhaps our issue is we don't want to do that either
<apw> tyhicks, so how do you handle passing on operations to the underlying layer
<apw> i guess you don't cause you are modifying offsets and data
 * tgardner messes with his firewall. back in a bit.
<tyhicks> apw: eCryptfs has duplicate inodes and dentries of everything. IIRC, overlayfs does fancy things to keep from having its own inodes, correct?
<apw> yeah it tries to, well it has them but only when not doing open
<tyhicks> By duplicates, I mean for every dentry and inode in the lower filesyste, eCryptfs has a corresponding inode and dentry
<apw> and to stop having to pass on everything to the original inode
<apw> yeah
<apw> it is such a shame there isn't a sensbl
<apw> wrapper for each op in the kernle, so you could just call them
<apw> all this if (op exists) then call op, else call something else
<apw> all being open coded, just makes life hard for slipping oneself in the chain
<tyhicks> apw: There are wrappers for most. Are you looking for one in particular?
<apw> more thining about the case where you mnight want to wrap any underlying one
<apw> where you dont in advance know which ops it uses
<apw> to act as a pass through, to maintain performance 
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> whilst having a real inode
<tyhicks> Ok, I'm seeing what you're saying now. opens are entirely passed through and overlayfs doesn't have its own file objects (for regular files) nor any file operations
<tyhicks> apw: If you run into needed wrappers, let me know. There's a good chance eCryptfs could benefit from them too.
<apw> tyhicks, right, and if we want open to follow copy_up one would need that indirection layer, but if it was there i'd feel i would want to wrap all the ops, and pass them down
<apw> we shall see what the maintainer says, if he says anything
<tyhicks> eCryptfs was the only stacked filesystem but if/when there are 2 stacked filesystems, requests for wrappers and vfs changes should carry a little more weight
<apw> yeah, though there really should be no open coded 'defaults' like there are
<apw> they should be in forceinlined functions if anything
<tyhicks> When you start getting into wrappering the file operations, it gets a little hairy because you're now dealing with data and the page cache
<apw> yeah, it is not going to work well i suspect
<apw>  /b smb
 * smb wonders what /b does... bash'me
<smb> Meh, probably send message to buffer or switch to buffer 
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Mar 6th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> smb, yeah select buffer by that name
 * apw is feeling well below par, so i am calling it a day
<kees> tgardner: have you been skimming the seccomp_bpf threads at all? it's starting to stabilize, but the timing is really ugly what with precise beta, etc. do you have an opinion on carrying the series for precise?
<tgardner> kees, I have not been following with any kind of attention. I've just noticed that there has been a fair amount of activity.
<tgardner> kees, is chromium still the primary consumer ?
<kees> tgardner: that's the trick. nothing uses it yet since it doesn't exist yet, but so far chromium and lxc (among others) are interested. RH has a libseccomp in the works, so there's lots happening, but it's not clear to me about the value of having it in precise with no consumers in precise. but if people use precise as a development platform... it'd be _really_ nice.
<tgardner> kees, well, this kernel will be around for awhile. do you have a patch set that comfortable with ? I'd prefer something thats gonna make it into the 3.4 merge window.
<tgardner> kees, on the other hand, we'll also be backporting subsequent kernels into the Precise user space
<kees> tgardner: I think redpig's v12 will be the last version (or extremely close to final). v11 comments are drawing to a close and everyone seems pretty happy with it. It's not clear to be if it'll make the 3.4 window (I _really_ hope so).
<tgardner> kees, there is still time. kernel freeze isn't until April 15
 * kees nods
<kees> tgardner: what would be your preferred schedule for pulling a patch series for precise?
<tgardner> kees, likely no later then April 1. that'll give us a bit of time to verify things.
<kees> okay, great
<tgardner> ogasawara, I do have the date correct, right ?
<ogasawara> tgardner, kees: kernel freeze is april 5th (not 15th)
<tgardner> ogasawara, ah, good thing I asked :)
<kees> hah, so... middle of march then?
<ogasawara> tgardner, kees:  if possible, I'd maybe shoot for Beta-2 Freeze, which is March 22nd.
<tgardner> kees, yeah, Mar 22 at the latest
<ogasawara> kees: so yes, mid march would be ideal.
 * cking -> EOD
 * tgardner -> EOD
<mahmoh> hallyn: are armhf precise containers working?  Or can you tell me what I'm doing wrong?  If I enter the container it appears to work fine but I'm trying to execute commands externally to get info. from within - http://paste.ubuntu.com/861153/
 * mahmoh moves to ubuntu-devel with the question
<pbuckley> mahmoh: goto ubuntu-arm
<pbuckley> err #ubuntu-arm
<pbuckley> youll have better luck
<mahmoh> ack
<skaet> ogasawara, thank you!  :D  spotted update in the release notes before I sent out the request.
#ubuntu-kernel 2012-02-29
<ppisati> "
<ppisati> ops
 * ppisati -> out to buy some food
<tgardner> apw, bug #943119
<ubot2`> Launchpad bug 943119 in linux "aufs.ko missing from the Precise kernels" [Undecided,Confirmed] https://launchpad.net/bugs/943119
<cking> tgardner, i think apw is out of action today
 * cking going to be back 'n' forth between keyboard and downstairs - got the plumber fixing a burst pipe
<henrix> jsalisbury: ping
<ppisati> tgardner: what's happened to the P/omap4 kernel? i see it in git but the package is not queued for building
<tgardner> ppisati, its pending approval until after B1 is released
<tgardner> likely Thursday
<ppisati> ok
<cking> hrm, netconsole is surprisingly good at capturing S4 issues
<tgardner> cking, really? I would not have expected that the network subsystem was alive in the earliest phases.
<cking> tgardner, it's giving me enough info on the resume phase, and that's the part i'm interesting in  - using no_console_suspend helps ;-)
<jsalisbury> henrix, ping
<henrix> jsalisbury: hi. just a quick question
<henrix> jsalisbury: i believe that bug #938195
<ubot2`> Launchpad bug 938195 in linux "kernel 3.2.0-17-generic crashes constantly" [High,Confirmed] https://launchpad.net/bugs/938195
<henrix> is a duplicated of bug #910519
<ubot2`> Launchpad bug 910519 in linux "network breaks - ath9k for TP-Link 5008" [Medium,Confirmed] https://launchpad.net/bugs/910519
<henrix> what do you think?
<henrix> i'm asking you because you initially tagged it as rc6
<henrix> jsalisbury: btw, i have built a test kernel for this (or these) bug(s)
<jsalisbury> henrix, yes they do look like dups comparing the trace
<jsalisbury> henrix, The bug reporter for 938195 has been unable to reproduce the bug by enabling rc6
<henrix> yeah, and there's another dup for these bugs (924486)
<jsalisbury> henrix, ok
<jsalisbury> henrix, we can pick one as the "Master" bug and mark the others as duplicates of it
<henrix> jsalisbury: the reporter of 938195 ends up saying at some point that his system crashed w/ rc6
<henrix> jsalisbury: check comment 34)
<henrix> jsalisbury: i was planning to pick the oldest bug as the master
<henrix> jsalisbury: is this ok?
<jsalisbury> henrix, sounds good
<henrix> jsalisbury: ok, cool.
<henrix> jsalisbury: and thanks
<jsalisbury> henrix, np.  Is this the same patch that is mentined in bug 923512?
<ubot2`> Launchpad bug 923512 in linux "ath9k wireless stopped working after kernel upgrade to 3.2.0-12" [High,Fix released] https://launchpad.net/bugs/923512
<jsalisbury> henrix, actually, probably not.
<henrix> jsalisbury: let me take a look...
<jsalisbury> henrix, They probably are not releated.  923512 was for wifi not working not crashes
<henrix> jsalisbury: yeah, doesn't look the same. and the patch is not the same
<henrix> jsalisbury: but i'll take a closer look. they may be related...
<jsalisbury> henrix, ok, thanks
<henrix> no prob
<cking> jsalisbury, do we have any trends on ath9k crashing on boot?
<cking> causing an un-bootable system?
<jsalisbury> cking, not crashing on boot, but crashing at run time and producing call traces.
<tgardner> ogasawara, do you suppose we should more widely advertise the fact that we don't plan to support aufs ? given the deficiencies we've encountered with overlayfs, we may have to change our minds. see bug #903897
<ubot2`> Launchpad bug 903897 in linux "-virtual kernel missing modules" [High,Fix released] https://launchpad.net/bugs/903897
<ogasawara> tgardner: yah I saw it.  I ran into a similar bug request the other day and have duped it to that one.
<ogasawara> tgardner: I've been posting a blurb about aufs to every milestone's TechnicalOverview.  I can craft a more wide spread email.
<tgardner> ogasawara, given that apw has kept aufs up to date, I'm tempted to just turn it back on. maybe overlayfs will get its problems fixed in 3.5
<jsalisbury> cking, There was this one though bug 894584
<ubot2`> Launchpad bug 894584 in linux "ath9k driver causes kernel panic" [Medium,Incomplete] https://launchpad.net/bugs/894584
<jsalisbury> cking, However, the original bug reporter stated he could not reproduce the issue.
<tgardner> ogasawara, I know you need more email in your inbox, but perhaps we should request use case scenarios on ubuntu-devel ?
<ogasawara> tgardner: indeed, I'd like some compelling evidence for carrying it for the next 5 years
<tgardner> ogasawara, ok, while you're sending out that email I'll go figure out why Lucid doesn't build
<ogasawara> tgardner: ack
<cking> jsalisbury, bug 919815 manifests this problem, but I've seen nobody else with this issue - which makes me wonder if it is a (broken) H/W issue
<ubot2`> Launchpad bug 919815 in linux "Ubuntu freeze on battery after power on/off - blacklisting ath9k stops freeze" [Medium,Confirmed] https://launchpad.net/bugs/919815
<jsalisbury> cking, hmm, yeah maybe hw issue with the wifi device itself
<jsalisbury> cking, I suppose I can ask him to try an oneiric or earlier kernel to confirm
<cking> jsalisbury, well, we could try this out, but I was wondering if we had seen other ath9k regressions - but if not, it is worth trying out a previous version just in case. But my gut feeling is that it is borked H/W
<jsalisbury> cking, no pattern of ath9k regressions similar to this bug
 * cking nods. google searches affirm that assertion ;-)
<cking> lemme chat to him - he reached out to me privately, so I will plug away at this bug with him
<jsalisbury> cking, ok, thanks
<tgardner> herton to the rescue. I see the Lucid build problem is already fixed by bumping ABI
<herton> yeah, fixed some minutes ago :)
 * ogasawara back in 20
<ppisati> didn't we have an installer called ubiquity (or something like that)?
<tgardner> ppisati, that is the live CD installer
<ppisati> tgardner: yeah but i remember using it to "move" my sd card installation to the external usb hdd
<tgardner> ppisati, seek out evan dandrea
<ppisati> tgardner: i'll do
<ppisati> tgardner: but could be that i'm wrong
<tgardner> ppisati, even if you are, Evan will likely know the right tool
<ppisati> tgardner: ok, then i'll do
<tgardner> jsalisbury, did you see "testkernel script to automate trying new kernels" on the ubuntu-devel list ?
<jsalisbury> tgardner, I did not, but I'll look now
<jsalisbury> tgardner, I'm not subscribed to that list, but I'll subscribe now.  
 * tgardner drops offline to reconfigure a router
<allan_shand> Hello is any one online at the moment?
<allan_shand> I have a problem with one of my machines not booting linux kernel you can find more info here http://askubuntu.com/questions/58763/why-wont-ubuntu-11-04-11-10-boot-after-install
<jMCg>  * Starting Userspace bootsplash                                         [ OK ]
<jMCg> How do I get rid of that, since I'm pretty and sure my servers won't need that.
<jMCg> Boot is taking obscenely long: http://dpaste.com/709502/ What I don't understand is the part where it says "Waiting for network..." --
<jMCg> ...that doesn't make sense, considering that the /backup (cifs) and /home (nfs) where mounted before that point.
<jsalisbury> sforshee, I recall you have a few Macbooks.  Have you seen this regression: bug 942334
<ubot2`> Launchpad bug 942334 in linux "synaptics touchpad no longer seems to detect 2- and 3-finger clicks" [Medium,Confirmed] https://launchpad.net/bugs/942334
 * tgardner -> lunch
<Sarvatt> jsalisbury: it's because of http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=1dbed2d965092b1d119e791689ed1895018a0c99 but its a problem in the software stack
<Sarvatt> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/941046 is the bug
<ubot2`> Launchpad bug 941046 in xserver-xorg-input-synaptics "Recent "clickpad patch" breaks two-finger-right-click" [High,Triaged]
<jsalisbury> Sarvatt, cool, thanks.  Then bug 942334 is a dup then.
<ubot2`> Launchpad bug 942334 in linux "synaptics touchpad no longer seems to detect 2- and 3-finger clicks" [Medium,Confirmed] https://launchpad.net/bugs/942334
<Sarvatt> yep, except 3 finger was disabled on purpose i believe since it interferes with utouch stuff I think? not having right click is nasty on these things right now though, been having to use http://paste.ubuntu.com/862318/
<jsalisbury> Sarvatt, thanks for the info!
<cking> hrm, now I've added netconsole my box has not crashed onced today. Urgh.
<phiphi> I recently read about improved jack-detection landing in the kernel. unfortunately on my machine it still doesn't work. Can I help to fix that?
<cking> phiphi, best to talk to diwic, however, he's normally around 0800-1700UTC
<phiphi> can I send a mail to diwic?
 * ogasawara lunch
<allan_shand> Is there any one online at the moment?
<allan_shand> I have a problem with all of the recent kernels I have some information about the problem here http://askubuntu.com/questions/58763/why-wont-ubuntu-11-04-11-10-boot-after-install
<jsalisbury> allan_shand, I would recommend opening a bug by running the following from a terminal: ubuntu-bug linux
<allan_shand> I can't Install ubuntu to start a kernel bug the bug stops ubuntu from being Installed.
<allan_shand> I ran a verbose boot from the Live disk and the line in the Question at askubuntu is the line it stops at during the boot of the live disk
<jsalisbury> allan_shand, what version are you trying to install?  If possible, can you see if you can boot from a Live CD?
<jsalisbury> allan_shand, so you can boot/install 10.04 and 10.10, but not 11.10?
<allan_shand> At the moment I have 10.10 on the system I have tried all versions including the current daily build of 12.04 all with the same result.
<allan_shand> I was able to boot 10.04-3 but since the update to 10.04-4 this also won't boot
<allan_shand> 10.10 will boot /10.04-4 no /11.04 no /11.10 no /12.04 no
<jsalisbury> allan_shand, can you boot into 10.10 and open a bug?  That way we can gather some information about your system.  That will allow some further debugging and possible testing of kernels.
<allan_shand> how should I inform about the bug being about a different kernel?
<jsalisbury> allan_shand, Just add that information as a comment, and I can add the appropiate tags
<allan_shand> give me a couple of minutes to boot and set up the bug thank you for the advice jsalisbury
<jsalisbury> allan_shand, thanks for reporting the bug!
<allan_shand> btw I forget should I run ubuntu bug as sudo?
<jsalisbury> allan_shand, sure.  If you don't you'll be prompted for the administrative password.
<allan_shand> Bug posted #943585 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/943585
<ubot2`> Launchpad bug 943585 in linux "All kernel's after 2.6.35-32-generic fail to boot" [Undecided,New]
 * tgardner -> EOD
<kklimonda> hey, what's the definition of "SAUCE"? Are those ubuntu-specific patches, or are they backported from staging and other upstream branches?
<smoser> smb, ping
<smoser> if you're awake
<smoser> http://paste.ubuntu.com/862565/ is pastebin of cg1.4xlarge, it had a soft lockup on boot
<ogasawara> kklimonda: SAUCE basically means it's usually a patch which has been submitted upstream but not yet applied to Linus' tree but it is of enough value for ubuntu to carry it.
<ogasawara> kklimonda: https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat might help explain
<kklimonda> ogasawara: and can I grep through changelog to see what "SAUCES" have been applied to the precise kernel, or should I just clone the git repository?
<ogasawara> kklimonda: yep, you should be able to grep through the changelog for "SAUCE"
<kklimonda> ogasawara: great, thanks
<htorque> jsalisbury: bug 943625 - sorry again for hijacking the other report. :-)
<ubot2`> Launchpad bug 943625 in linux "[drm:drm_mode_getfb] *ERROR* invalid framebuffer id" [Undecided,New] https://launchpad.net/bugs/943625
<jsalisbury> htorque, not a problem.  Thanks for opening a new bug.
#ubuntu-kernel 2012-03-01
<ppisati> moin
<smb> morning
<ppisati> i love the smell of Linus's rants in the morning
 * smb rather prefers the scent of fresh coffee...
<ppisati> :)
<smb> ppisati, what is going wrong today? :)
<ppisati> smb: nothing yet, but it could get worse
<ppisati> it could rain :)
<smb> it could snow if it was colder... no, anything particular that roused Linus?
<ppisati> smb: opensuse security model requiring root password for everything
<ppisati> smb: he said one of his daughter called him from school saying she couldn't add school's printer without root pwd
<ppisati> you can imagine his reaction... :)
<smb> heh. :) can imagine
<ppisati> but the real question is, did he give the root pwd to hhis daughter at the end or not? :)
<smb> maybe remote login and change it after... well in some way the security of being able to do all those things with your default user is relatively similar
<ppisati> yeah
<ppisati> but i agree he has a point
<diwic> why not boot from a live-CD and just change the root pwd that way?
<ppisati> he mentions some other mundane tasks like chaging wireless network or date/timezone
<smb> Yes, I guess there are probably things/subsystems which you would expect to operate on their own rights without requiring additional ones. At least making decisions only affecting your profile
<ppisati> right
<ppisati> and i wonder where we stand in this stance
<ppisati> e.g. will Linus's daughter be able to add a printer without root? changing network? timezone?
<ppisati> anyway, dist-upgrade just finished, brb
<smb> ppisati, Guess in out case she would not need the non-existent root password but do a lot of things as root anyway. :)
<ppisati> :)
 * apw yawns
<cking> hrm, creating a minimal USB DOS image for a BIOS upgrade from scratch is interesting
<Daviey> cking: does freedos not cover it?
<cking> Daviey, I wish it did, but alas no
<ppisati> perhaps i'm drunk, but it seems i'm getting a completely different panic on armhf vs armel...
 * henrix is out for lunch
<apw> ppisati, if that is a float triggered issue then it could easily be different
<apw> henrix, i assume we are still committing to lucid/mvl-dove, in order to make maverick/mvl-dove
<apw> herton, ^^
<apw> (a new h on the block, messing up my tab completion)
<herton> apw, yes, ppisati usually pushes on his branch, I push the updated branch
<ppisati> apw: yep, i update my zinc branch and then pull from it for M/dove
<herton> then I verify and push to "master" (lucid/mvl-dove, maverick/mvl-dove) when ppisati sends the request to fetch/pull
<ppisati> herton: ah btw, Houston we have a problem
<ppisati> latest P/omap4 update is ok for armel
<ppisati> while it complains about a missing module for armhf
<ppisati> any way we can fix it?
<ppisati> i mean, can we withdraw the pull and fix it? or it's already queued and thus we are screwed?
<herton> ppisati, I think tgardner is taking care of P
<ppisati> herton: yes, but he forgot we have armhf too
<ppisati> herton: so he fixed the armel side only
<ppisati> ah right, you are the stable team... :)
<herton> yes, you have to see with him this, not sure what he already done/queued
<apw> ppisati, which module is missing ?
<apw> (i presume by this it is meant to be missing now)
<ppisati> apw: the led heartbeat was compiled in
<ppisati> apw: tim took care of the armel side, but not armhf
<apw> oh yeah, so i assume it was a build faliure on armhf
<ppisati> yep
<ppisati> but since it takes AGES to build a kernrl on one of our arm builders, if we can fix it would be nice
<apw> ppisati, so its not uploaded yet
<ppisati> nope
<herton> removing  ledtrig-heartbeat from debian.ti-omap4/abi/3.2.0-1406.8/armhf/omap4.modules should fix it, may be fixing the commit and rebasing, on push a fix on top, should do it
<herton> *or push a fix on top
<apw> herton, yeah easy to fix, will do that and repush it
<ppisati> apw: thanks
<apw> ppisati, pushed ... and tim emailed just in case
<ppisati> apw: cool, thanks
<henrix> cking: ping
<henrix> cking: i remember you were asking yesterday something about ath9k-related panics...
<cking> henrix, yep
<henrix> cking: well, i accidentaly came across this commit: 07445f688218a48bde72316aed9de4fdcc173131
<henrix> cking: not sure if related with the bug you were looking at...
<henrix> and it looks like its not on precise
<cking> henrix, that's a great find - I will spin a test kernel with that in for the user who's seeing issues with it - thanks!
<henrix> it may be completely unrelated, but worth taking a look ;)
<henrix> btw, its already on stable
<apw> henrix, nice :)
<cking> it sounds like it definitely worth trying :-)
<henrix> cool
<henrix> i was looking for something completely unrelated on stable... and just found this
 * ogasawara back in 20
<jsalisbury> cking, henrix, comment #13 was added to bug 894584  This is someone other than the original bug reporter reporting panics possibly related to ath9k
<ubot2`> Launchpad bug 894584 in linux "ath9k driver causes kernel panic" [Medium,Confirmed] https://launchpad.net/bugs/894584
<cking> jsalisbury, I'll take a peek at that once I've popped my stack of things to do
<jsalisbury> cking, cool.  Not much to look at.  Just another person stating they see panics and thing they could be related to ath9k.  I asked them to post a screen shot of the panic.
<henrix> cking: have you managed to build the test kernel?
<cking> henrix, yep, uploading the debs is taking a while at the mo
<henrix> ah, ok. cool
<cking> patch applied cleanly which is good
<henrix> since we have a "fresh" comment, maybe the new guy may be able to test it quickly :)
<cking> the user is sporadic, sometimes he tests immediately, sometimes it takes a week or more to get back to me
<brendand> hey
<brendand> if i install on a system with > 3GB of RAM, is there something that tells the -pae kernel to be used?
<brendand> past experience shows this to be the case on my main laptop
<brendand> but not sure if this is 'guaranteed'
<brendand> in other words, is it a bug for a system which needs pae to address all it's memory not to install it?
<brendand> never mind
<brendand> preseed #fail
<JanC> a non-PAE kernel kan address 4 GiB of RAM, which is > 3 GiB...  :P
 * cking ->EOD
<jdstrand> ogasawara, jsalisbury: thanks for your work on bug #911059
<ubot2`> Launchpad bug 911059 in linux "Intel wireless randomly drops connection" [High,Fix committed] https://launchpad.net/bugs/911059
<ogasawara> jdstrand: np, jsalisbury did all the heavy lifting.
<bjf> jjohansen: bug 931627 has been waiting for your signoff
<ubot2`> Launchpad bug 931627 in kernel-sru-workflow/security-signoff "linux: 2.6.24-31.99 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/931627
<jjohansen> bjf: hrmm, right sorry /me has been deal with a mailbox implosion
<bjf> jjohansen: np, this was just a reminder :-)
<jjohansen> bjf: looking at it now
#ubuntu-kernel 2012-03-02
 * kees looks around for tgardner
<kees> here's what seccomp_bpf will look like, most likely... https://lkml.org/lkml/2012/3/1/504 just to give folks a heads-up.
<kees> ogasawara: ^^ if you're interested.
 * apw yawns
<apw>     UBUNTU: SAUCE: iwlwifi: fix key removal
<apw> if that isn't the fix for my constant disconnects i will be amazed
<smb> That being SAUCE even?
<smb> Err, I mean I am (positively) surprised about it
<smb> ah, sauce because it may not yet be upstream
<RAOF> apw: Oh, iwlwifi is going to stop being crap?  Yay!
<ppisati> apw: P/omap4 failed to build - missing module
<apw> ppisati, ?
<apw> ppisati, so much for updating the tree and emailing tim
<apw> ppisati, will sort it out
<apw> ppisati, so i think what happened was that the previous version was already uploaded, just stuck in the freeze queue.  but you can't tell that easily from the normal interfaces we check in the archive
<apw> ppisati, anyhow, i've uploaded the fix over the top
<ppisati> apw: cool, thanks
<apw> ppisati, we tried at least to avoid it
<ppisati> apw: we fought an unfair battle, we knew we would loose but we did our best, rust in peace previous P/omap4 HEAD...
 * ppisati feels extremely stupid today :)
<apw> heh
 * cking notes that systemtap for Precise works in the kernel space fine
<apw> tgardner, fyi i re-uploaded precise/ti-omap4 to fix a build failure
<tgardner> apw, ack
<tgardner> apw, what was it? I test cross compiled first
<apw> tgardner, we forgot that armhf is also built when handling the module being removed
<tgardner> apw, ah
<tgardner> doh!
<apw> its going to happen a few times before we remember :)
 * tgardner reboots after update
<herton> ppisati, bug 927526 is still unverified, if we think the config changes are enough we can just verify the config on new kernel and mark as verified, what do you think?
<ubot2`> Launchpad bug 927526 in linux-ti-omap4 "missing support for some LIRC devices" [Undecided,Fix committed] https://launchpad.net/bugs/927526
<apw> herton, if all we have done is turned things on it is pretty low risk, as they clearly didn't work before
<herton> yeah, the only worry I had was that the guy talks about other config options we didn't touch, anyway if there is more to turn on can be done later
<ppisati> herton: sorry, i was in a call
<ppisati> herton: since it's just a config change (and actually someone rported it was ok IIRC), i think we can move fwd
<ppisati> that being said -> lunch
<herton> ppisati, apw: marked as verified, in case something more is needed I just requested feedback on the bug
<brendand> bjf - i set the certification-testing-passed tag on the Lucid tracking bug, but now Launchpad is barfing so I can't update the task status. hope it doesn't mess anything up
<herton> brendand, I set the task there to fix released
 * tgardner must deliver a vehicle for repair. back in 30 or so...
<kirkland> amitk: ping
<kirkland> amitk: so I think I'm reproducing your byobu bug here, I saw that creep up last week
<kirkland> amitk: I think it's a very recent regression
<kirkland> amitk: I have a few questions for you, if you have a minute
<apw> ogasawara, fyi i think you should find gcc already published
<apw> (so i am told)
<ogasawara> apw: yep, saw the note.  I'm planning to kick off some test builds/boots and then upload by eod
<apw> ogasawara, awsome, that Intel wireless fix sounds just like the problem i have here on my boxes
<ogasawara> apw: yep, I think a few people are going to be happy with that one
<ogasawara> apw: I say we flipped aufs back on too
<ogasawara> s/say/saw/
<apw> ogasawara, i think tgardner already did that
<apw> tgardner, ^^
<apw> ogasawara, after this upload i'll recheck aufs is up to date, was last i checked
<ogasawara> apw: ack
 * tgardner is back
<tgardner> ogasawara, the arm chroots on gomeisa are broken again. looks like I'll have to re-install. you can use tangerine in the meantime.
<ogasawara> tgardner: ack
<tgardner> cking, herton ^^
<herton> tgardner, ok
<cking> ok
<apw> tgardner, did you just destroy all the precise chroots on gomisa?
<tgardner> apw, just now
<apw> tgardner, that explains why my build just went bang rather specitacularly then
<tgardner> apw, dang, I checked to see if anyone was using the chroots
<tgardner> apw, wouldn't there be mounts against the chroot ?
<apw> tgardner, i'd assume so, it got about half way through, so it had been going about 5m when objdump went away
<apw> tgardner, i am using schroot to get in em
<tgardner> apw, hmm, maybe my checking was defective
<apw> oh well, done now
<tgardner> apw, I'll have x86'en back in 10 mins or so
<tgardner> sorry
<apw> hopfully my build will finish before leann lets loose and kills it
<ogasawara> heh
<tgardner> apw, I am going to box up my emerald today and send it too the Boston DC so we'll have a tangerine duplicate
<apw> tgardner, sounds good ... 
 * apw pops out to get some supplies
<amitk> kirkland: hiya
<kirkland> amitk: hey!
<kirkland> amitk: couple of questions for you...
<amitk> kirkland: how goes it? 
<amitk> sure
<kirkland> amitk: pretty well
<kirkland> amitk: I think I might be seeing the same thing as you
<kirkland> amitk: but I'm not sure
<kirkland> amitk: does this feel like a recent regression?
<amitk> kirkland: TBH, I don't know. I switched to the tmux backend in January I think. But I never really looked at cpu usage.
<kirkland> amitk: k
<kirkland> amitk: also, are you seeing this on real hardware, or vm's?
<kirkland> amitk: or both?
<kirkland> amitk: and how much mem/cpu does your system(s) have
<amitk> kirkland: amazon ec2
<kirkland> amitk: instance size?
<amitk> kirkland: large (dual core 2.7GHz, 8Gb RAM)
<kirkland> amitk: hmmf
<kirkland> amitk: okay
<amitk> and it consistently takes 15-30% whether I'm attached or not
<kirkland> amitk: yeah, that's definitely not right
<kirkland> amitk: okay, I'll spend some good time on it this weekend
<kirkland> amitk: this should absolutely be fixed asap
<amitk> kirkland: I was just helping out a friend when I saw this. Thought you'd like to know. I'll let him know it is being looked at urgently. Thanks a lot!
<kirkland> amitk: thanks -- so you're not experiencing it yourself directly?
<amitk> I am
<kirkland> amitk: k
<amitk> kirkland: i'll be able to help debug it if you need 
<kirkland> amitk: k
<tgardner> ogasawara, do you think my message about aufs was sufficient to put the fear of *choose your deity* into current aufs consumers ?
<ogasawara> tgardner: heh, yep.  I liked it.
<tgardner> ogasawara, please remember to continue dissing aufs during the Q cycle
<ogasawara> tgardner: ack.  I'm gonna flip it back off for Q.
 * ogasawara back in 20
 * tgardner is off to box an Emerald
<kirkland> amitk: the next time you see it, can you post a screenshot of top running?
<kirkland> amitk: so that I see the processes that are running?
<amitk> kirkland: I've switched back to tmux, but the problem is failing to show up ATM. Will post to the bug if I see it again.
<lamont> [1531525.609275] nf_ct_sip: dropping packetIN=eth0 OUT= MAC=00:0e:0c:5c:1c:78:00:0c:85:be:5a:85:08:00 SRC=192.168.133.192 DST=192.168.133.1 LEN=591 TOS=0x10 PREC=0x40 TTL=64 ID=45472 PROTO=UDP SPT=50855 DPT=5060 LEN=571 
<lamont> that is bothersome
<lamont> mostly since it happens every second or 4
<smb> someone calling in?
<smagoun> bjf: Hey, I'm having trouble testing a mainline kernel for bisecting bug 929111 - the machine doesn't boot completely w/ mainline kernels like linux-image-3.2.1-030201-generic 3.2.1-030201.201201121644. I can get to a VT, and in top I see that a number of modprobe calls are hung in I/O wait. Commands like 'lsmod' hang in I/O wait too. Any suggestions (try a different mainline kernel?)
<smb> seems destined to sip
<ubot2`> Launchpad bug 929111 in linux "Repeated freezes when running on battery power" [High,Confirmed] https://launchpad.net/bugs/929111
<bjf> smagoun: yes, the only thing i can suggest right now is to try a different one
<smagoun> k
<smb> bah... nf_ct_sip should be clear it is sip. stupid me
<lamont> smb: it's a cisco 7940 phone registering... over and over and over.
<lamont> and netfilter going "hey, wtf?  I don't understand.  HALP HOW MAKE COMPUTAR WORK?" and so on.
<smb> lamont, Ah, fun... not
<lamont> On the bright side, the phone is demonstrating that it can count, since the source port goes up by one each time
<lamont> there is no established connection between the two, and nf doesn't think there should be, apparently
 * smb wonders what happens when it wraps back to 0...
<lamont> 46095 now
<smb> wasnt that 50855 already
<lamont> sigh.  ID!=SPT
<lamont> 51583
<smb> lamont, Oh, looking at the modules code there does not seem to be much desire to have it be more specific about what is bad if it is bad... :/
 * smb decides to have reached wheat-o-clock
 * apw is of a similar position ... later
 * cking --> winding down, EOD
 * tgardner -> lunch
 * tgardner makes yet another trip to town to fetch repaired vehicle.
<kees> apw: so... dieter is a troll
#ubuntu-kernel 2012-03-03
<help-needed> Hi!  I have a process not responding to "kill -9",  almost surely stuck in kernel.  Can you hing me how to get some useful info about the problem, please?
<help-needed> *hint
<kirkland> I'm getting a lot of these, all of a sudden in precise:
<kirkland> [drm:pch_irq_handler] *ERROR* PCH poison interrupt
<bryceh> kirkland, hmm, sounds familiar, I think I saw that when reviewing someone else's dmesg recently
<bryceh> kirkland, (I assumed it was something unrelated to the bug I was investigating)
<bryceh> kirkland, any freezes or other symptoms?  is it triggerable by monitor hotplug, or switching in a kvm?
<bryceh> kirkland, anyway, file a bug report and sub me to it and I'll shoot it to Intel on monday
<bryceh> kirkland, https://www.libreoffice.org/bugzilla/show_bug.cgi?id=35103 maybe?
<ubot2`> bugs.freedesktop.org bug 35103 in DRM/Intel "[SNB/IVB] â[drm:pch_irq_handler] *ERROR* PCH poison interruptâ after S3 resume on a SugarBay" [Normal,New: ]
#ubuntu-kernel 2012-03-04
<dupondje> https://lkml.org/lkml/2012/2/8/246 -> could this small patch be added to Precise kernel. Just hit that 'bug' :)
<gordonjcp> hi
<gordonjcp> I'm having a problem when I eject USB drives, where I can no longer access the drive as a block device
<gordonjcp> dmesg shows the following:
<gordonjcp> sdb: detected capacity change from 4004511744 to 0
<gordonjcp> what exactly is going on when I eject in Ubuntu, and how can I prevent it doing this without having to reboot into Arch every time I want to write to a USB drive?
<RAOF> Why are you ejecting it?
<gordonjcp> because I don't want the filesystem mounted
<JanC> you can unmount it...  âº
<gordonjcp> yes, but then it stops working, as I just said
<JanC> unmount != eject
<gordonjcp> same thing
<JanC> eject makes it invisible until you remove it & plug it back in
<gordonjcp> so does umount
<JanC> unmount does not do that
<JanC> eject is on a lower level
<gordonjcp> I've just tried it; umount does the same thing as eject, or right-click and "Safely Remove..." from the desktop
<JanC> I mount/unmount USB disks all the time...
<JanC> or partitions on them
<gordonjcp> in 11.10?
<JanC> yes
<gordonjcp> hm, well it's not working here
<JanC> eject removes the block device, so naturally you can't (easily) remount it then, but umount shouldn't do that (AFAIK)
<gordonjcp> it's definitely removing the block device...
<gordonjcp> you're starting to make me wonder if someone has aliased umount to eject, just to annyo me
<gordonjcp> *annoy
#ubuntu-kernel 2013-02-25
<wooo> hey guys I have a doubt about vnode. I think the inode for a specific file system is the vnode for virtual file system. Am I right?
<ppisati> moin
<wooo> guys please help !!
<wooo> hey guys I have a doubt about vnode. I think the inode for a specific file system is the vnode for virtual file system. Am I right?
 * apw yawns
<ppisati> brb
<cnf> apw: package is working now, btw
<cnf> apw: ugly, ugly hacks, but it works :P
<apw> cnf, send it back, and don't forget the brick
<cnf> indeed :P
<cnf> and the herpes!
<apw> too true
<apw> ppisati, well it hasn't crashed yet
<apw> ppisati, and none of the 'regular' oopsy things we used to see in dmesg
<apw> ppisati, now if you could just add a patch to make teh cpus 4x faster ...
<ppisati> apw: just wait for the new panda omap5, i heard it's so awesome (when it comes out) :)
<apw> ppisati, heh sounds good, the build will likely still running when they do :)
<smb> apw, So just for additional info, it seems that indeed an objdump -g on the raring ddeb gives me nothing while it seems still ok for the vmlinux file. But the modules in debian/build seem to be stripped already. Got a log of that build to look at
<apw> smb, ok ... likely it is something to do with module signing, so perhaps i should poke it ?
<apw> that alll caused chaos when we first added it, as it changes where things are
<smb> If you have the time. I may have a bit too, but then I have not looked into the whole signing issue the first place
<jjohansen> bjf: I'll be in at about 7:30
<smb> apw, Hm, CONFIG_DEBUG_INFO seems to be gone
<smb> ah no
<smb> still there
<ogra_> its stable enough now ... screw debugging
<smb> apw, Interestingly only amd64 =y i386 =n
<apw> smb, doh ... will look into it ...
<smb> apw, more doh... the same vmlinux has output on the raring objdump -g but nothing on precise objdump -g
<smb> apw, probably whatever that output is, its not the things I tried to look for
<ppisati> apw: is your panda still ok?
<apw> ppisati, yes and no panics indeed no dmesg messages since 13s after boot
<apw> ppisati, and it has been up 4 hours
<ppisati> apw: nice, then we can safely assume that patch fixed it
<apw> ppisati, i would say so, about 15m was the best i got before
<rtg_> ppisati, apw is that with a DT kernel ?
<apw> rtg_, thats the 'unified' kernel
<rtg_> DT == device tree kernel
<ppisati> rtg_: our img don't use DT by default
<ppisati> rtg_: but if you modify the uEnv.txt, it works
<apw> but they are unified :)
<rtg_> cool
<rtg_> apw, on a different topic, shouldn't 'apt-get autoremove' be removing old kernel in raring ?
<apw> rtg_, if you didn't install them by hand yes
<rtg_> hmm
<rtg_> apw, ok, looks like it removes them but doesn't purge them
<apw> rtg_, does headers or image contain anything a purge would make go away any harder
<rtg_> apw, huh ? a 'dpkg -P' makes the listing go away
<apw> ahh you mean you can still see the old package names yeah
<rtg_> apw, so, some are marked 'rc', but most are still 'ii'. the 'ii' kernels are the ones I would expect to get removed, but I may have installed them by hand
<apw> righjt if you installed it by hand, then it is marked as permenant
<rtg_> apw, I've seen them cleanup on gomeisa and tangerine, so that capability must have been backported
<apw> apt-mark showmanual linux-\*
<apw> rtg_, yes it has, that will show which it thinks you installed manually
<apw> rtg_, yes it has, that will show which it thinks you installed manually
<apw> apt-mark showmanual linux-\*
 * smb thinks there is a flaw in the matrix
<apw> yeah :)
<rtg_> 3.9 is telling me my SB server is insane. arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
<rtg_> sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
<xnox> reboot syscall supports passing a string which is used as rebootcommand further down the stack. Thus for example on nexus7 one can "reboot bootloader" to reboot into fastboot/flashing mode.
<xnox> is there any way to discover supported reboot commands from the running kernel/sysfs/etc?
<xnox> Because we may want to expose these features to the user in the future of e.g. UEFI Fastboot modes and/or booting multiple operating systems on devices (e.g. reboot into recovery)
<xnox> apw ^ would you know about this?
 * xnox got lost in per-arch trees in the kernel sources.
 * ogasawara back in 20
<avoine> ppisati: Hi, if you have 2 min, I would like to test your multi-plateform kernel on a imx6 board and I have some questions about the installation.
<ppisati> avoine: i'm here, shot
<avoine> Do you know if there is some documentation about the u-boot part? 
<avoine> Right now, I have the linaro's U-boot and image installed from here: https://wiki.linaro.org/Boards/MX6QSabreLite
<avoine> but I think it won't work unless I update the u-boot for ubuntu
<ppisati> avoine: we never released an official ubuntu img for imx6
<ppisati> avoine: do you have uboot on imx6's flash? and do you read the kernel from sd?
<ppisati> avoine: if yes, you should be ok
<avoine> yeah it boot from SD
<avoine> ppisati: ^
<avoine> ppisati: ok, I'll try to update the kernel to the latest one and see if it boot
<ppisati> avoine: would you use the .deb? or would you build the zimage from src?
<avoine> ppisati: the deb
<ppisati> avoine: in the first case, flash-kernel will complain (-omap doesn't match your arch)
<ppisati> avoine: so be aware that you need some hacking on it
<ppisati> avoine: ping me and i'll try to dig up what exactly do you have to do
<ppisati> avoine: if you can't figure out
<avoine> ppisati: ok, thanks
 * ppisati goes for some sweating... later...
<doanac> bjf: i've added a comment to bug 1092924.
<ubot2> Launchpad bug 1092924 in UTAH "Cobbler install of recent raring-desktop images failing" [High,Triaged] https://launchpad.net/bugs/1092924
<doanac> I think the easiest way to help move forward would be to give you access so that you can re-produce and poke around.
<bjf> doanac, the easiest way was for you to find a kernel / iso that was successfully working. 
<doanac> bjf: i can't find an ISO that does work
 * rtg_ -> lunch
 * rtg_ -> EOD
<infinity> zequence: Around?
<zequence> infinity: Yep
<infinity> zequence: Once bjf sorts out the bugs so you're working on the right one, there's a fairly urgent (quantal-only) lowlatency rebase needed.
<bjf> zequence, bug 1132942 is the one to use, i'll fix any others
<ubot2> Launchpad bug 1132942 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1132942
<zequence> Ok, so I'll do a rebase shortly and let you know when it's done
<infinity> bjf: According to your lts-q changelog, you seem to have broken your stated "use the oldest bug" rule. ;)
<infinity> bjf: (Not that it matter, just make sure you close the right ones)
<bjf> infinity, i refused to wait so i created that one by hand :-)
<infinity> bjf: But it's newer than the others. :P
<bjf> infinity, i was busy working on it and had not refreshed so i missed the fact that shankbot created it for me
<infinity> Ahh.
<infinity> Twice, no less.
<infinity> Overzealous bot.
<bjf> impatient me
<zequence> infinity: Who's doing the pulling?
<infinity> bjf or apw, I imagine.
<infinity> apw: If you're around and feel like helping zequence.
<zequence> apw: quantal source ready to be pulled
<bjf> zequence, where from?
<zequence> It's at https://github.com/zequence/ubuntu-quantal-lowlatency.git
<zequence> branch lowlatency
<infinity> zequence: You should make the bug reference an actual closure.
<infinity> ie: have the magic sequence "LP: #1132942"
<ubot2> Launchpad bug 1132942 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1132942
<zequence> Ah, sorry. I messed it up this time.
<infinity> You messed it up last time too, by omitting the space.  I had to close your bug by hand. :)
<zequence> infinity: There's a bot scanning for that, right?
<infinity> zequence: Not a bot, per se.  When you build a source package, things with the proper syntax get torn out of the changelog and put in a special field in .changes
<infinity> zequence: https://launchpadlibrarian.net/132343151/linux-lts-quantal_3.5.0-25.39~precise1_source.changes
<infinity> zequence: ^-- See "Launchpad-Bugs-Fixed:" in there.
<infinity> zequence: The archive then obeys that to auto-close bugs on accept.
<infinity> zequence: So, broken syntax means no closures.  If you use vim, it actually highlights bug closures in gold, so they show up as correct.
<bjf> zequence, is your tree the authoritative tree, we are missing a number of rebases from out git repo. does apw normally just build and upload a package based on your git repo?
<zequence> infinity: I see. I'll try to be more careful with the changelog. Should I make some changes, and reapply the last git tag? 
<zequence> bjf: I don't know how apw does. I know one time (again a problem with the changelog :( ), he added one commit to change that, and uploaded it to his own tree at kernel.ubuntu.com
<bjf> zequence, ack
<zequence> ..or pushed
<bjf> infinity, looks like i don't have upload rights for linux-signed-lts-quantal :-(
<infinity> bjf: Irksome.  Ask stgraber to fix that?
<infinity> stgraber: ^
<stgraber> bjf: added
<bjf> stgraber, can you check sconklin as well? thanks
<stgraber> bjf: anyone with rights to the packageset will be fine now. That source simply wasn't in the set.
<bjf> stgraber, ah, thanks
<bjf> infinity, do i need to do a new package or can i just try again?
<stgraber> bjf: just retry
<bjf> stgraber, thanks
<zequence> infinity: bjf: I've deleted the tag, and redoing it now. Hope that doesn't mess anything up for you?
<bjf> zequence, nope, i'm going to leave for apw and then i'll talk to him about how he normally does this
<bjf> zequence, i'd think that if your tree was authoritative, you'd just be producing souce packages which he could sponsor for you
<zequence> bjf: I think that's the plan, yes. For now, he has been doing the packages.
<bjf> zequence, ack
<bjf> infinity, ok, i just reuploaded the same pkg again that was rejected, i guess i'll roll the version and upload another
<bjf> infinity, this is a pita
<infinity> bjf: Hrm?  Shouldn't have needed to rev the version if the first was rejected.
<bjf> infinity, actually, it wasn't the signed pkg that was rejected
<bjf> infinity, you still around?
<bjf> infinity, i think i know what i did, i uploaded it to the wrong pocket
<infinity> bjf: Oh?  Pockets don't matter to PPAs.
<infinity> bjf: Oh, you uploaded directly to the archive. :)
<bjf> infinity, yes, i'm out of practice
<infinity> bjf: Want me to reject that one, and we can use the PPA instead?  Doesn't actually matter to me, we can just use the archive one.
<infinity> bjf: It has to rebuild in the archive ANYWAY (we don't copy those binaries from the PPA), so no big deal.
<infinity> bjf: I'll just accept the one in the queue after I copy the kernel.
<infinity> bjf: Work for you?
 * infinity -> food.
<bjf> infinity, linux-lts-quantal_3.5.0-25.39~precise1 this was rejected and the signed-lts pkg is waiting
<infinity> Yeah, I'm looking at the queue right now.
<bjf> infinity, if you can make it just work, do so, otherwise let me know if i need to re-upload
<infinity> So, what I'm saying is that when the linux-lts-quantal in the PPA is done building, I'll copy it, and accept the linux-signed-lts-quantal that's in the queue.
<infinity> That'll work fine.
<infinity> I'll get to it after dinner.
<bjf> ok, i'll not do anything at this point, i'll be around if you need me to do anything
<bjf> infinity, ^
<infinity> bjf: Err, what I need you to do is not botch the linux-lts-quantal upload.  I didn't look at that carefully. :/
<bjf> infinity, ack
<bjf> infinity, do i need to roll the version number or just upload correctly this time?
<infinity> Maybe I can fix that with a copy.
<infinity> bjf: Can you try running this (I don't have rights to the PPA) http://paste.ubuntu.com/5566371/
<infinity> bjf: Assuming you have ubuntu-archive-tools checked out somewhere.
<bjf> ack
<infinity> bjf: You can't reupload, since it's the same version, but a copy should work, since the binaries never built.
<infinity> (Depending on whatever artificial constraints the PPA may have)
<infinity> If that doesn't work, I'll cheat and copy it to the security PPA to build it there. :P
<bjf> Traceback (most recent call last):
<bjf>   File "./copy-package", line 27, in <module>
<bjf>     from ubuntutools.question import YesNoQuestion
<bjf> ImportError: No module named ubuntutools.question
<bjf> infinity, ^
<infinity> That can't be a recent checkout of ubuntu-archive-tools...
<bjf> infinity, i'm on precise by the way
<bjf> i just did: bzr branch bzr+ssh://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/
#ubuntu-kernel 2013-02-26
<infinity> Oh.  Or maybe the current trunk depends on something from a newer ubuntu-dev-tools.
<infinity> Developers running precise.  Crazy talk.
<bjf> stable kernel folks are allowed
<bjf> we actually support lts
<infinity> I run both, to be fair.
<infinity> Just that my laptop is raring.
<bjf> i can try raring if that makes a diff (i also run multiple)
<infinity> And all my other machines are precise.
<bjf> same here
<infinity> Well, it works here on raring.
<infinity> YMMV.
<bjf> can't hurt to try ...
<infinity> Anyhow, if it doesn't work for some reason, I'll just copy it to a security PPA and be done with it.
<infinity> Since I do have access to those.
<bjf> nope, same error
<infinity> It could just be that you don't have ubuntu-dev-tools installed...?
<infinity> At least, I assume that's where that import is from.
<bjf> trying
<bjf> infinity, that seems to have made a diff
<bjf> infinity, it thinks it did it
<infinity> Well, we'll know in a minute or two.
<infinity> copies are async.
<infinity> Yeahp, looks good.
<bjf> i see a second one in the ppa
 * infinity scores those up.
<infinity> You should be able to delete the oopsed quantal one.
<bjf> infinity, the signed one is probably in the same situation
<infinity> The signed one was uploaded to the archive, not the PPA.
<bjf> so we just leave it
<bjf> ?
<infinity> I've got that covered, yeah.
<bjf> ok, i'm backing away, let me know if i need to do anything else
<infinity> ;)
<infinity> Other than prodding people for rebases, I think we're good now.
<infinity> Is this already fixed in raring?
<bjf> it had not hit linus' tree the last i looked
<bjf> i mentioned it to rtg, i'm not sure what his plan is/was
<bjf> let me look at our tree
<bjf> infinity, it's on our master-next
<infinity> bjf: Say, not to nitpick, since this has been wrong for a few releases now, but why do the linux-signed changelogs say "precise"? :)
<infinity> bjf: No point fixing it for this upload, but someone might want to get it right on the next.
<infinity> https://launchpad.net/ubuntu/+source/linux-signed/3.5.0-24.37
<infinity> https://launchpad.net/ubuntu/+source/linux-signed/3.5.0-25.38
<infinity> Etc.
<infinity> Oops. :)
<bjf> infinity, looking
<infinity> bjf: I assume someone just made it precise somewhere in the distant past, and automated tooling has kept it broken. :)
<infinity> bjf: And since you upload to the PPA in a targetted fashion, and I copy to the archive in a similarly targetted way, it's never actually mattered.
<infinity> bjf: Anyhow.  No big deal for this round, just entertaining.
<bjf> infinity, yup, looks like i may have been the one to "break" it in jan.
<infinity> Heh.
<infinity> Then you can fix it in a week or two. :)
<bjf> infinity, tomorrow most likely since this is the start of a cycle
<infinity> bjf: Also curious that linux-signed-image doesn't depend on sbsigntool in quantal, but it does in precise and raring...
<bjf> infinity, your just all kinds of fun today
<infinity> Yeah, I'm great at parties.
<infinity> bjf: Again, not world-ending, since that was already wrong in the previous uploads, but if you could fit it in git so it matches precise/raring on the next round, that'd be cool.
<bjf> infinity, i've noted it and will correct tomorrow
<infinity> bjf: (Not sure how else the packaging differs between linux-signed/quantal and linux-signed-lts-quantal/precise, but it seems on that they should differ at all, except for the linux-extra dep.
<infinity> )
<infinity> s/on/odd/
<infinity> Typing hard.
<infinity> bjf: Anyhow, this all looks like it's going to build and be happy, so feel free to run away, I'll sort the promotions myself in a bit when it's all done and do bot/bug faffing.
<ppisati> moin
<brendand> henrix_, can you help re-orient me in the kernel cadence?
<brendand> henrix_, i'm starting to get lost
<smb> morning
<infinity> brendand: The current cadence is a bit out of whack due to emergency security releases.  We should be back in the normal flow of things in a day or three.
<infinity> ppisati: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1132939 could use some urgent attention while I sleep, so I can deal with it in the morning. :)
<ubot2> Launchpad bug 1132939 in kernel-sru-workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress]
<brendand> infinity, an estimated date for the next kernels to finish verification?
<infinity> brendand: Well, the current set are skipping the whole process, due to the aforementioned security urgency.
<ppisati> infinity: saw it, doing the rebase right now
<infinity> brendand: So, after that, you'd have to ask bjf about the next cycle.
<apw> bjf, linux-signed in Q differs from P or R in that it contains the full binaries, and so doesn't need those other deps as it works different.  we may want to change that, but it is "right" at least
<infinity> bjf: Translation, I'll probably work with Andy to make sure it gets changed to match P and R, for sanity and consistency but, yes, it's "correct" right now, as explained.  False alarm earlier.
<henrix> apw: i understood that linux-3.5.y.z-queue was being built automatically from git but the latest build seems to be from Feb 16
<henrix> apw: do i need to kick it off?
<apw> henrix, they are automatic, but i thought there was two parts, the parts i was doing which are based on tags appearing
<apw> henrix, and another part which herton did which was maybe a daily
<henrix> apw: hmm... ok. so i pushed some commits to -queue yesterday. do you have any idea how do i start a build in there?
<henrix> apw: anyway, i'll ping herton later about this. i have .debs i've created manually yesterday so i'll just use those for now
<apw> henrix, ack
<apw> henrix, erm, there are builds in the mainline builds since the 16th ?
<apw> henrix, in the -review ?
<henrix> apw: oh, i checked the -queue branch only
 * henrix goes look
<apw> it is optimising only one build i think
<apw> if they are the same
<henrix> ah, ok. makes sense
 * apw needs to check it is doing it a sane way round
<apw> henrix, yeah so if -review has built and matches -queue then we don't bother building that one too
<apw> as they would be identicle
<henrix> apw: yep, got it.  thanks
<apw> i wonder if we should be linking it into there ... maybe we should
<henrix> you mean the 'current', right? it could make sense, yeah
<henrix> but since very few people will actually look at those, not sure if its worth the trouble
<apw> i was more thinking the dates actually
 * apw watches raring crater ... great
 * rtg_ fixes quantal master-next build
 * henrix -> lunch
 * rtg_ preps raring kernel for upload, includes CVE-2013-1763
<rtg_> uploaded...
<Kurdistan> Hi my friend has fujitsu siemens amilo laptop and this is graphical card detail: http://paste.ubuntu.com/5567659/ . The issue is resume back from suspend. It goes to suspend, but when wake up it goes black screen. He really likes 12.04.2.
<Kurdistan> I think it is kernel related because there was no fglrx driver in jockey-gtk
 * cafetiere whines about i915 page flip hangs in v38 final 
 * cafetiere also wonders how he is the first to hit them
<Kurdistan> cafetiere, was your message to me? desperate to help my friend I made him switch from windows.. I do not want to look bad
<rtg_> cafetiere, isn't there a SAUCE patch just forthat ?
<cafetiere> I think that was p
<rtg_> cafetiere, UBUNTU: SAUCE: drm/i915: Wait for pending flips to complete before tearing down the encoders
<Kurdistan> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1082314 <<<-- I found this but I do not understand anything about it :(.
<ubot2> Launchpad bug 1082314 in mesa "Raring wake up from S3 broken" [Medium,Fix released]
<cafetiere> Kurdistan: nope whining about my own woes
<Kurdistan> cafetiere, oki sorry... :(
<cafetiere> rtg_: that is the one but this is during normal boot running
<cafetiere> I have Somme pointer from the x people to try, but not being able to use ones own devel box is a pain
<smb> Kurdistan, The best way to help your friend is to open a seperate bug report. Just run "ubuntu-bug" on the affected machine. That runs you through some questions and opens a launchpad bug. 
<ppisati> brb
 * ogasawara back in 20
<Kurdistan> smb, he do not have launchpad account.
<Kurdistan> but I will ask him if I do not find out ha way and his laptop have really high temp. I am afriad of overheating.
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<bjf> brendand, all you all sorted on what's happening wrt kernel SRU cadence now?
<infinity> ppisati: What's happening with ti-omap4/quantal?  Just waiting on one of your coworkers to upload to the PPA?
<ppisati> bjf: henrix: herton ^^^
<ppisati> bug 1132939
<ubot2> Launchpad bug 1132939 in Kernel SRU Workflow "linux-ti-omap4: 3.5.0-220.29 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1132939
<henrix> infinity: ppisati: ok, i guess we forgot about those branches. thanks
<brendand> bjf, a clear idea of when the next testing week will be would be handy right now
<infinity> brendand: I'm not entirely clear on when your testing week is, but the next uploads should start today/tomorrow.
<infinity> brendand: So, testing is the week or two following, I assume.
<brendand> infinity, right
<infinity> bjf: So... Setting verification testing to invalid REALLY pissed off the bot.  Let's not do that again. :P
<bjf> infinity, lol
<henrix> infinity: last week i just set those to 'fix released'. and then, manually, set the 'promote-to-*' to 'confirmed'
<infinity> henrix: Yeah, I opted to set verification to fix released after I promoted, so everything stayed automated.
<infinity> henrix: But we'd earlier set verification to invalid and the bot commented on the bug every few hours, saying "SOMETHING'S WRONG, AND I REFUSE TO DO ANYTHING ABOUT THIS BUG, BUT I'LL STILL ADD COMMENTS, NYAH NYAH".
<infinity> I think it's just being a brat for attention.
<henrix> infinity: heh, probably :)
<bjf> brendand, this is a prep week, next week is verification, the following week is regression testing
<brendand> bjf, ok thanks
<bjf> brendand, there was a small error on the interlock schedule which i've just corrected: https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 5th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati -> EOD
 * rtg_ -> lunch
<zequence> Woa, another Quantal -lowlatency update. What's going on?
<bjf> zequence, yesterday was for a high priority CVE
<bjf> zequence, today, it's the start of the regular 3 week cycle
<zequence> bjf: Ok
<bjf> zequence, c'mon, you didn't have anything else to do did you? :-)
<zequence> bjf: Actually, I'm taking the chance while I'm being sick to get some mixing done :)
<zequence> ..not that updating the kernel takes me a long time
<zequence> I just run a script pretty much
<zequence> And try not mess up the changelog :P
<infinity> bjf: Not to harp, but should I be concerned that you're starting the new Q SRU cycle and no one's uploaded the ti-omap4/Q rebase for yesterday's CVE fiasco? :P
 * rtg_ -> EOD
<bjf> infinity, i guess i'll have to deal with that myself
<infinity> bjf: I think that was the implication made earlier, yeah.
<BenC> apw: I've had to revert a few of your config changes on ppc
<BenC> apw: namely, all of the built-in self tests for FMAN/BMAN/QMAN were enabled, and really shouldn't be on unless doing extensive (performance hindering) debugging
<BenC> Also, had to disable CRASH_DUMP because it really mucks up ppc in general (especially kexec kernel loading)
<BenC> CRASH_DUMP makes it so it will be only relocatable to page aligned memory, where as normally we can relocate to arbitrary memory
<BenC> And kexec doesn't have a way to detect that and mask/offset the memory when loading the kernel
<infinity> BenC: Those are probably valid points for kexec in general which, while we don't officially support on other arches, we probably don't want to hinder.
<infinity> apw: ^
<BenC> infinity: I'm all for re-enabling it on non-freescale kernels, but as I can't test them with it enabled (and it appears it never was before), I'm hesitant of doing so
<infinity> BenC: I was sort of arguing that your reverts might be valid across the board, not that you should revert the reverts anywhere. :)
<BenC> infinity: right, I was just saying that I know it keeps our equipment from even booting the kernels, just noting I don't mind if it's enabled in places where that isn't an issue :)
<infinity> BenC: Booting is overrated.  What you have there is the fix for every CVE, past, present, and future.
<BenC> Optimism runs strong in you
<infinity> Yeah, I get accused of that a lot.  Must be my sunny disposition and friendly personality.
<infinity> BenC: Does this mean there's a linux-ppc upload coming soon?
<BenC> infinity: Yeah, recompiling now to make sure this all works
<infinity> BenC: If so, give me a bit of warning, and I can make sure it lands on sagari.
<BenC> Ok, thanks
 * infinity should probably test your kernels on his PPC750 occasionally to make sure you haven't broken powerpc32.
<infinity> I run raring's powerpc64 kernels on another machine, and they're not obviously broken, but my PPC750 is precise.  I suppose installing and boot-testing the odd kernel wouldn't hurt.
<antarus> people still use powerpc32? :)
<antarus> we were discussing this at scale recently ;p
<infinity> antarus: A fair few people do, AFAIK, though I'm just an "old hardware" case.
<infinity> antarus: It's an ultra-low-power IBM PPC750 core, so despite being ancient, I don't really feel bad about running it, like I do with, say, old Pentiums.
<bjf> infinity, i've uploaded a ti-omap4. i'm prepared for you to tell me all the ways i've screwed it up.
<infinity> bjf: Looks fine to me.
<infinity> bjf: Sorry to disappoint.
<infinity> bjf: I'll get it copied and released as soon as it's built tonight to clear the way for the normal SRU that should follow.
<bjf> infinity, still plenty of time to find fault, don't rush.
<infinity> bjf: Well, the one thing you did wrong was to mangle the bug so the bot started lying about builds being completed. :P
<infinity> bjf: But the source itself looks fine.
#ubuntu-kernel 2013-02-27
 * apw hates computers
<ogra_> and they hate you too :)
 * ppisati hates computers and humans: /me wins!
<apw> ppisati, humans go without saying surely :)
<apw> ogra_, so very true
<apw> ppisati, elloco is still running fine, 48hrs
<ppisati> apw: nice
 * apw pops to the postoffice, lucky me
<cking> apw:   git config alias.fixed "bisect bad"
<cking>   git config alias.buggy "bisect good"
<cking> apw:  make deb-pkg INSTALL_MOD_STRIP=1 -j 24
<apw> those bisect aliases are such an obvious solution, and done that way they are repo specific
<apw> cking, we must make sure js is aware
<cking> yup, will do
<rtg> ogasawara, do you have a haswell ?
<rtg> just pushed a couple of raring master-next patches for intel_idle that I'd like to get tested.
<ogasawara> rtg-afk: yep I do, I'll test and get back to you
<tjaalton> ogasawara: hey, could it be possible to "enable" some non-haswell machines to use i915_hsw instead of the older i915 on quantal kernel?
<ogasawara> tjaalton: definitely possible I would think, we'd just need to move the pci id's from one to the other
<tjaalton> ogasawara: right, that's what the people testing the new machines on the oem pipeline have done now for quick testing
<ogasawara> tjaalton: if testing supports moving to the i915_hsw driver I wouldn't be opposed as it would be hw specific and low risk of regression
<tjaalton> it's unfortunate that i915 modesetting was rewritten in 3.7 so that it's very hard to backport anything eDP related :/
<ogasawara> tjaalton: I gotta jump on a call right now.  send us a patch if it's what you guys want.
<tjaalton> ogasawara: ok, I'll see how it goes and get back to you or someone who could do the changes, thanks
<tjaalton> yeah that works
 * ogasawara back in 20
<rtg> apw, git://github.com/CyanogenMod/android_kernel_asus_grouper.git for N7 origin ?
<apw> rtg, checking
<apw> rtg, looks to be the same cm-10.1 in both
<rtg> apw, thats what the phablet dudes were using ?
<apw> rtg, that looks to be the base for their stuff yes
<rtg> k
<rtg> apw, incidentally, I've had to disable aufs and overlayfs for todays 3.9 rebase. the usual maintenance BS. wanna put that on your TODO list ?
<apw> rtg, ack, yep as soon as we get an -rc1 i'll start fixing it i recon
<rtg> that shuold be soon
<apw> yeah i was assuming so nideed
<rtg> apw, I've been rebasing daily just so the number of new configs isn't so mind numbing to go through.
<apw> rtg, i assumed as much :)
<apw> i've done a couple of preliminary passes over the config too for the same reason
<rtg> most so far appear to be straightforward
<apw> yeah i didn't see anything i wanted to change in review, so thats good
<apw> Bisecting: 104 revisions left to test after this (roughly 7 steps)
<apw> sigh
<jsalisbury> rtg, apw, Are the kernel header files available if the lts backport kernel is used? Seems they may be missing per bug 1134441
<ubot2`> Launchpad bug 1134441 in linux (Ubuntu) "kernel headers are missing from 3.8" [Medium,Confirmed] https://launchpad.net/bugs/1134441
<apw> jsalisbury, that might mean he has not installed the common package
<rtg> jsalisbury, I'll check in a bit. you can have a look yourself at https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport
<apw> apw@dm:~/git2/ubuntu-raring$ ls /usr/src/linux-headers-3.8.0-7
<apw> arch    Documentation  fs       ipc      kernel    mm       scripts   tools   virt
<apw> they are in the normal raring kernel ones, so if they arn't in backport we would be supprised
<jsalisbury> apw, rtg, thanks for the info, I'll update the bug.
<apw> linux-headers-3.8.0-7-generic_3.8.0-7.16~precise1_amd64.deb (1.0 MiB)
<apw> linux-headers-3.8.0-7-generic_3.8.0-7.16~precise1_i386.deb (1.0 MiB)
<apw> linux-headers-3.8.0-7_3.8.0-7.16~precise1_all.deb (76.8 KiB)
<apw> there is something there, but it does look a little small
<apw> rtg, did you copy the machineary from the previous release, from the lts-quantal ?
<rtg> apw, mostly I think. its been awhile
<apw> rtg, there was a change in raring debian* i think to hand the change to uabi headers
<apw> handle
<rtg> it should get it automatically, right ?
<apw> i would have thought so, hmm
<apw> rtg, the file list for the package in the build looks ok though
<apw> jsalisbury, i would download that _all .deb and just 'less foo.deb' on it and see if it has the usr/src directory in it
<jsalisbury> apw, will do
<apw> jsalisbury, oh did cking tell you about 'git buggy' ?
<jsalisbury> apw, is there a link to show the builds for both archs, or do I have to look at i386 and amd64 separately 
<jsalisbury> apw, yeah, I saw that post.  Pretty cool stuff
<apw> separatly
<jsalisbury> apw, ok, thanks.
<apw> jsalisbury, so very simply, and its per-repo so you can do it safely in all your pending repos
 * apw is doing a reverse bisect now, and it has saved my fragile mine
<apw> mind
<jsalisbury> apw, I'm going to look into the ktest.pl script.  It looks interesting
<jsalisbury> apw, I've been just touching a file called REVERSE-BISECT in the src directory, so I remember to think backwards, heh.
<apw> just setting the aliases the right way before you start in each has worked great for me
<jsalisbury> apw, yeah that would work well.  I have so many bisects going at once I would have to do it on a per src tree basis maybe.  I have a separate tree for each bug I'm bisecting.
<apw> those aliases are per-tree by default
<jsalisbury> apw, great.  I'm going to give that a try then :-)
<cking> it definitely saves a lot of pain
<jsalisbury> apw, cking, thanks for the info.  It will help a great deal.  
<jsalisbury> apw, the linux-headers-3.8.0-7-generic_3.8.0-7.16~precise1_amd64.deb seems to have a /usr/src directory, so I'll check that the bug reporter installed the package correctly.
<apw> jsalisbury, great
<jsalisbury> apw, thanks again
<rtg> jsalisbury, he shuold be installing linux-generic-lts-raring to get both kernel _and_ headers
<jsalisbury> rtg, ok
<jsalisbury> apw, rtg, I looked at linux-headers-3.8.0-7_3.8.0-7.16~precise1_all.deb.  It looks like it may be missing some stuff.  Especially when comparing to the mainline all headers package at: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-raring/
<apw> jsalisbury, ok 'great' so it is real
<jsalisbury> apw, rtg, here's a file size comparison:
<jsalisbury> -rw-rw-r-- 1 jsalisbury jsalisbury    78630 Feb 27 12:09 linux-headers-3.8.0-7_3.8.0-7.16~precise1_all.deb
<jsalisbury> -rw-rw-r-- 1 jsalisbury jsalisbury 12190890 Feb 27 12:10 linux-headers-3.8.0-030800_3.8.0-030800.201302181935_all.deb
 * ppisati -> sweating
<ogra_> ppisati, no wonder after that election :P
<ogra_> would make me sweat too :)
<ppisati> ogra_: actually after the election i wanted to hang myself... but that's another story...
 * ppisati -> gym
<ogra_> ah, no, dont hang yourself for stupidity of people 
 * smb -> dinner
<JanC> I'm not sure the Italian election results are all that bad, depending on how mature the politicians involved will act on them...
<cking> politicians and mature are words that don't exist in the same universe
 * cking -> food
 * rtg -> lunch
<rtg> apw, pushed nexus7 master-next after rebase and config harmonization. would you run your config annotation tools over it ?
 * rtg -> EOD
<hggdh> bjf: I opened bug 1134927 against QRT, Raring; eventually they will have a patch for it
<ubot2`> Launchpad bug 1134927 in QA Regression Testing "QRT apparmor failures on test-pam-*, Raring" [Undecided,New] https://launchpad.net/bugs/1134927
<bjf> hggdh, ack
#ubuntu-kernel 2013-02-28
 * smb yawns
<apw> when things are broken, they are very broken
<smb> apw, They can get more broken easily
<smb> but not the other way round
<cking> breakage is like entropy, always increasing and always unavoidable
<apw> heh yeah, i have much internal network outage
<apw> dhcp server and radv servers both went on the friz
<apw> and now my tunelling has gone wonkey
<ppisati> brb
<ppisati> http://www.androidcentral.com/google-working-experimental-38-linux-kernel-android
 * ppisati wonders if they'll try to use nvidia's opensource tegra driver
<apw> ppisati, interesting
<ppisati> apw: /me wonders if we can use it for our phablet/nexus7 img
<apw> ppisati, indeed.  why don't you find out :)
<ogra_> theiur opensource driver is for X, isnt it ?
<ogra_> wont help on phablet
<ppisati> ogra_: no idea
<ppisati> apw: don't think it's ready yet, but i can give it a look
<ogra_> and i dont think it has full 3D support in X so wont be of much use on n7 desktop either
<ogra_> phablet uses libEGL directly, thats the part they will never make free
<rtg> apw, 'binary-arch-deps-$(do_libc_dev_package) += binary-arch-headers' is why headers are not getting packaged in the LTS backport build for Raring.
<apw> rtg ?
<ppisati> ogra_: "x11, drm, fbdev, and gdi" which backend do we use with libegl?
<apw> rtg, how does that work in any version if that is true
<rtg> apw, bug #1134441
<ubot2`> Launchpad bug 1134441 in linux-lts-raring (Ubuntu Precise) "kernel headers are missing from 3.8" [Undecided,In progress] https://launchpad.net/bugs/1134441
<rtg> apw, becasue we set that flag false for the LTS backport build
<apw> rtg, obviously we don't want libc making back there though
<apw> rtg, and how does it work in the quantal lts backport
<rtg> apw, dunno, was just gonna go have a look
<apw> rtg that change is nothing new
<apw> rtg, and remember binary-arch-headers is in more than one place, depending on settings
<apw> rtg, and binary-arch-headers is _not_ the headers for the kernel, that is only libc-dev
<rtg> apw, well, hmm.
<rtg> apw, what builds linux-headers*all.deb ?
<apw> rtg,  install
<rtg> install-headers
<apw> rtg, ie binary-arch
<apw> rtg, so binary-arch-headers is only about libc-dev, binary/install et al all make the headers
<apw> binary-headers is a convienience for you as a human and not used internally iirc
<ogra_> ppisati, gralloc
<apw> rtg, search for "        # The flavour specific headers image
<apw> rtg, this is on the raring backport branch right ?  
<rtg> apw, yep
 * apw pokes
<apw> rtg, any idea when we might see 3.8.1, cause this had is pissing me right off
<apw> heap
<rtg> apw, today according to his announcement
<apw> as soon as you have it i want want want want *stamp foot* *cry*
 * apw is getting grumpy a losing his environment every other hour
<apw> and this is too hard to reporoduce to be able to bisect it reliablly
<apw> and not far enough apart to not be annoying
<apw> rtg, not that there is any hope that it will be fixed by that, there is none of the flip fixes in there, bugger
<apw> rtg, got it, its that -SRCPKG thing agian
<rtg> yeah, I was just getting to that conclusion
<apw> dh_installchangelogs -plinux-lts-raring-headers-3.8.0-7
<rtg> must be in a control file
 * apw will sort it out
<rtg> apw, k, I'll go back to the N7 kernel
<rtg> apw debian.master/control.stub.in:Package: SRCPKGNAME-headers-PKGVER-ABINUM
<apw> rtg, we're not using those in theory
<apw> rtg, as we are on the branch
<apw> and control is right actually as we make the right package name in the output
<apw> but we don't put the shit in the right place, so it is empty
<apw> rtg, this is all because we don't let the indep package change name, which we should really do
<apw> these lts-backports packages are a bit of a mess ... arg
<rtg> the indep packages are unique because of the ABI number, right ?
<apw> they are for lts-backports _only_ because they don't overlap
<apw> for example in ppc they are not
<apw> or indeed in the linux-lowlatency
<apw> so we have to be very careful in changing the indep parts
<apw> _or_ more likely we should be letting the indep package in the lts-backports be different
<rtg> so you're thinking it _should_ be linux-lts-raring-headers 
<apw> perhaps, we can discuss that at 'sprint', the important thing is for now we need to fix that
<apw> but only on the lts-backport branch
<apw> not in the master, as that is carried over to ppc and lowlatency
 * apw confirms this is the issue
<rtg> apw, well, if we are going to change the name we need to do it before sprint
<apw> rtg, will figure out the deps for ppc and lowlatency and propose somethign on kernel-team@
<rtg> ack
<apw> we need the change i am having to revert there, so for now i'll do it on the branch
<rtg> apw, policy on CONFIG_PATA_ACPI in raring is that it has to be 'y' or 'm', right ?
<apw> yeah
<rtg> I think it should _never_ be 'y'
<rtg> as it will match any storage PCI ID
<apw> rtg is it causing an issue? 
<rtg> apw, bug #1084783
<ubot2`> Launchpad bug 1084783 in linux (Ubuntu Raring) "[Regression] SATA reset failing since Linux 3.6" [High,Fix committed] https://launchpad.net/bugs/1084783
<apw> rtg, if the description in that bug is right then indeed it should not be y, it being y is interesting it must have been switch that way for a reason, no idea why tho.
<rtg> apw, I couldn't find one either. just thought you might know.
<rtg> I'm gonna make the policy 'm'
<apw> nope i dont recall, perhaps uni-cum ?
<rtg> wtf is uni-cum ?
<apw> what we were drinking in bundapesht
<rtg> ah :)
<apw> rtg, though from its position in the annotation list i would say we did it when we were picking the most common disk device drivers, soh
<rtg> likely just a foobar decision then
<apw> rtg, what was teh headers thing bug #
<rtg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084783
<ubot2`> Launchpad bug 1084783 in linux "[Regression] SATA reset failing since Linux 3.6" [High,Fix committed]
<apw> ta
<rtg> apw, nm
<apw> oh thats the other one
<rtg> apw, yeah, looking. hang on
<rtg> apw, bug #1134441
<ubot2`> Launchpad bug 1134441 in linux-lts-raring (Ubuntu Precise) "kernel headers are missing from 3.8" [Undecided,In progress] https://launchpad.net/bugs/1134441
 * ppisati kicks a new arm build and evaporates for a bit
 * ogasawara back in 20
<rtg> apw, working on v3.8.1. should have it in a bit
<apw> great
<rtg> apw, I was within 30 seconds of uploading for that PATA_ACPI boto fix when I noticed your build daemon email
<rtg> boot*
<apw> rtg ?  boto daemon?
<rtg> boot fix
 * apw cannot recall this boot fix
<rtg> apw, bug #1084783 is a boot failure
<ubot2`> Launchpad bug 1084783 in linux (Ubuntu Raring) "[Regression] SATA reset failing since Linux 3.6" [High,Fix committed] https://launchpad.net/bugs/1084783
<apw> rtg i don't recall sending any email about that one, you sure it was me
<rtg> apw, 'Mainline Build v3.8.1'
<rtg> that one ^
<rtg> isn't that your build bot somewhere ?
<apw> yeah it is a build bot jobby
<apw> now i get you, yo mean you uploaded just before seeing there was a .1 you could rebase to at the saem time
<rtg> I *almost* uploaded. caught it just in time. now I have to go remove the tag etc
<apw> heh
 * ppisati disappears again
<Windows> Hello is this the English Channel?
<rtg> apw, zinc.canonical.com:~rtg/linux-image-3.8.0-9*
<apw> Windows, it is an ubuntu kernel discussion channel, wherein people know english
<Windows> apw: German?
<Windows> apw: Where can I find a german channel?
<apw> not me
<apw> #ubuntu-de ?
<Windows> apw: I have got a question about the kernel!
 * rtg bounces
<BenC> infinity: ppc kernel about to be uploaded
<apw> Windows, then as per the topic, ask it and see what happens
<rtg> apw, did you have a patch for the raring LTS headers issue yet ?
<rtg> apw, never mind. I fixed it.
<BenC> rtg: when are you guys going to switch to using an upstream tar ball with 3.8?
<rtg> BenC, usually just before handoff prior to release. guess thats coming right up.
<BenC> Ok
<rtg> BenC, I'll try to remember it for the next upload.
<infinity> BenC: Ah, wasn't around.  Oh well, you get adare.
 * rtg -> lunch
<apw> rtg, you changed that indep thing on master-next in raring, that is the wrong place, that will break ppc et al
<rtg> apw, you're sure ?
<rtg> apw, ok, dropped that patch for now
<apw> rtg, yeah they both have full header sets, including their own independant common header, to allow them to migrate britney independantly
<rtg> apw, ok, I've just left it in the LTS branch
<unkle_george> This is more of a glibc/alloc thing, but maybe someonehere can explain it to me:  "deallocated space is not placed
<unkle_george>  on the free list for reuse by later allocations" http://man7.org/linux/man-pages/man3/mallopt.3.html
<unkle_george> So any allocations over 128k are not reusable by my app even after free?
<unkle_george> while(1) {delete [](new char[128*1024]);} will eventually exhuast memory space?
<rtg> henrix, I think 'Re: [PATCH 018/139] tty: Prevent deadlock in n_gsm driver' on the kteam list is directed at you.
<rtg> apw, pushed N7 again with some config updates. seems to work OK on the desktop.
<henrix> rtg: checking
<henrix> rtg: interesting, looks like we're not building that driver in with our config.
<henrix> rtg: i need to take a closer look at that
<rtg> henrix, you should likely be building vanilla stable with allyesconfig
<henrix> rtg: i was testing with the same config we use for the mainline builds
<rtg> henrix, which I beleive is derived from Ubuntu
<henrix> rtg: most likely. i'll start doing that. thanks
 * rtg -> EOD
<ppisati> do any of you know how i can debug a dkms pkg? IOW it doesn't want to apply one of the patch that are "there"
<ppisati> if i explode .deb, go inside and manually apply the patch, it works ok
<ppisati> but during the installation, that patch is not applied
<ppisati> (but it's there, it's corrent and it's in the right place)
<ppisati> grrr...
 * ppisati has found the problem... :P
<JanC> ppisati: so, what was it?
<ppisati> JanC: spoke too early...
<ppisati> JanC: mispelled patch in dkms.conf.in
<ppisati> but now i've another problem... uhm...
<JanC> sounds... interesting  âº
<JanC> about debugging: I suppose you already checked if the build log has some useful info?
<Redoubt> 1swutrif;QWE
#ubuntu-kernel 2013-03-01
<ppisati> moin
<apw> moin
<zequence> apw: both lowlatency ready to be pulled
<apw> zequence, more ?
<zequence> apw: hmm, more?
<zequence> apw: Oh, and I wanted to ask you if now would be a good time to hand over the prepare package bit too?
<apw> zequence, yes it probabally is a good time to start that
<apw> zequence, i'll get myself suitibly caffinated and put together a short description
<apw> zequence, then you can make one, and i'll do the same for comparison
<zequence> apw: I'll do the same (get myself some coffee) :)
<apw> zequence, just dropped you a potted instruction set on makeing the packages have a read and then we can have a go
<zequence> apw: Yes, thanks. A very thorough one as well
<apw> zequence, i don't know if you have somewhere you can publish those easily, perhaps google drive would work, or ubuntu one, as ideas
<zequence> apw: Can't I just push to a PPA?
<apw> zequence, that would work i think, i can just copy it out of there into our one once happy to get it in the process
<apw> zequence, so, lets try that :)
<apw> zequence, i suggest you make a new PPA for your attemps as once you get it wrong the PPA can get broken and need removing, which is annoying if it is a useful one
<zequence> apw: Yes, I'm creating one specifically for lowlatency SRUs only
<apw> zequence, sweet, that works welll then our process becomes 'pocket copy the packages when happy' which is nice
<apw> zequence, this covers the main packages, when we have this working i'll show you the meta packages and you will be self-sufficient
<apw> zequence, then i can write it up for my team so anyone can help with it too, win win
<zequence> apw: Sounds great
<ppisati> that's what i'm saying:
<ppisati> flag@flag-desktop:~$ find /usr/src/linux-headers-3.5.0-17/drivers/ -name \*.h | wc -l
<ppisati> 177
<ppisati> flag@flag-desktop:~$ find /usr/src/linux-headers-3.8.0-7/drivers/ -name \*.h | wc -l
<ppisati> 0
<ppisati> and i need one of those headers for a dkms
<zequence> apw: So, the packages are awaiting build at ppa:zequence/linux-lowlatency. I'll let you know when they finish. The only addition I had to make to the procedure was changing the release in the changelog from "precise-proposed" to "precise". I suspect this is what you do for the Canonical PPA as well?
<apw> zequence, actually we normally change the name in the .changes file and re-sign it ... that said the archive now knows you mean precise-proposed when you say precise now so it no longer matters, so in short what you have done makes sense
<apw> zequence, i have recently changed the lowlatency rebase script in raring to remove the -proposed bit permenatly we might want to do that anyhow
<apw> in the ones in P and Q as it no longer matteres
<apw> ppisati, the flavours header package is actually using include only in raring
<zequence> apw: I see, I see
<apw> ppisati, and if a header is outside there it seems to be copied by hand specifically by name in 3-binary-indep.mk
<ppisati> apw: ah, found!
<ppisati> "cp -a drivers/staging/omapdrm/omap_dr*.h $(indep_hdrdir)/drivers/staging/omapdrm"
<ppisati> that's what i need
<apw> so we need an equivalent indeed in raring, spin a patch and i'll get it in
<ppisati> apw: i'll do
<ppisati> 1fd90d0b88f66b1759b498b8c00dbbe43c672f85
<ppisati> UBUNTU: [Config] installing omapdrm specific headers for external drivers
<ppisati> we already have it
 * rtg grinds through 93 emails in ubuntu-devel
 * ppisati builds another kernel
 * rtg goes to figure out why his server isn't booting
<rtg> cking, henrix: bouncing gomeisa for kernel and ssl update
<ppisati> rtg: if yo've to do the same on tangerine, let me finish a build first
<rtg> ppisati, will get to it _after_ gomeisa comes back.
<henrix> rtg: ack
<cking> ack
<rtg> cking, henrix: gomeisa is back
<henrix> rtg: ack, thanks
<rtg> ppisati, lemme know when your build is complete non tangerine
<ppisati> rtg: ok
<ppisati> rtg: go ahead
<rtg> ppisati, ack
<rtg> jjohansen, rebooting tangerine ?
<rtg> tangerine is _such_ a pain in the ass to reboot
<rtg> ppisati, tangerine should be back
<cking> rtg, why? cos it gets stuck or just slow to spin up again?
<rtg> cking, it won't shut down after it has accumulated a zillion chroot mount points. something to do with upstart I think
<ppisati> rtg: yep
 * ogasawara back in 20
<lfaraone> Is there a way to get advanced notification of new proposed kernels for precise that are going to get rolled in as a stable update? 
<lfaraone> the recent kernel update adversely affected a rather large deployment because of #1015925
<lfaraone> LP 1015925
<ubot2`> Launchpad bug 1015925 in openafs (Ubuntu Precise) "openafs: Support quantalâs kernel 3.5" [High,In progress] https://launchpad.net/bugs/1015925
<apw> zequence, those source packages seem ok indeed -- will copy them over and see what happens
<apw> zequence, a good thought to use a ppa here, it looks to be a simple workflow for us
<bjf> lfaraone, i'm not sure what exactly you are asking for
<bjf> lfaraone, we run a 3-week cadence. new kernels hit proposed approx. every 3 weeks
<apw> zequence, ok copied over ... looking to be working well ... plus i have pushed your source too
<apw> zequence, this is getting close
<apw> lfaraone, yeah kerenls which are coming to a release pop into the -proposed pocket some two weeks minimum before they would make -updates
<apw> lfaraone, and i would not expect this to affect anyone who didn't opt into the 3.5 kernel which they would have not done accidentally ?
<zequence> apw: nice!
<lfaraone> apw: this apparently hit users who did not "opt in". 
<apw> lfaraone, how ?  if they havent' opted in they won't have any 3.5 kernels to affect the dkms package
<lfaraone> apw: how does one opt-in?
<apw> lfaraone, by installing the linux-lts-backports-* meta package normally
<apw> if this was a new install from .2 then they might i guess have had this but then that ought to be a new install and by definition tested before use
<rtg> or installing from the 12.04.2 point release
<apw> so i am somewhat confused how an existing install got broke
<apw> rtg, indeed that was what i was trying to say
<rtg> apw, you don't suppose the headers got trashed, do you ?
<lfaraone> apw: sorry, we had people reinstall Ubuntu on their workstations at MIT and it made OpenAFS sad
<apw> rtg, i don't think so, in this case the dkms package is not 3.5 aware in precise so any 3.5 kernel on the system will break it
<rtg> ok, so that makes it hard to claim that an existing functional installation broke unless the kernel release was upgraded
<apw> lfaraone, so thats just a basic failure to test in advance error (which sounds harsh) not us breaking existing installs at least
<apw> lfaraone, obviously it should be fixed, and it think has been indeed
<apw> rtg, do we announce when we add a new lts-backports-foo kernle to precise or whereever anywhere ?
<lfaraone> apw: I didn't say you broke existing installs. 
<apw> lfaraone, no probabally not, i inferred it from what little irc i read and the bug
<rtg> apw, kteam list
<Sarvatt> apw: 12.04.2 release notes
<apw> lfaraone, so all i am saying is good, we havent' broken everyone in the world here only people installing fresh
<apw> lfaraone, so that is less frightening than i thought it was
<rtg> point release install then ?
<apw> lfaraone, so it sounds like we announce them in the .x release notes and on our main kernel-team@ mailing list
<apw> seems so indeed rtg
<lfaraone> The main thing that's confusing is if a user says  "I'm running Ubuntu 12.04 and have applied all the updates", we still have no idea i.e what kernel they're running. 
<apw> i can see that indeed, a trade off between stable versions and modern hardware support
<rtg> lfaraone, note that you can also be testing against a 3.8 Ubuntu kernel from https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport by installing linux-generic-lts-raring
<apw> in older releases.  not an easy trade off to make without some confusion
<lfaraone> So it becomes a world where we have to test both upgrades and new installs, in order to catch things like this.
<lfaraone> apw: To ensure this doens't happen again, should I subscribe to kernel-team? or is there a way to just get messages about proposed kernels and not other traffic? 
<rtg> lfaraone, have you tried to upstream your driver ?
<apw> lfaraone, we normally announce anything significant there indeed.  like when rtg started publishing the 3.8 lts backport kernels for testing they would have been announced there
<apw> lfaraone, and those are likely to come to precise in the same manner in the next point release i would assume
<rtg> ogasawara, you have any USB 3.0 gizmos ? just pushed the patches for bug #1011415
<ubot2`> Launchpad bug 1011415 in intel "[Feature] USB3 Port power off mechanism " [Undecided,New] https://launchpad.net/bugs/1011415
<ogasawara> rtg: I don't unfortunately
<rtg> hmm, I wonder who does....
<apw> ogasawara, rtg, wasn't it manjo who had such things
<apw> and just maybe sforshee may have said he had something
<apw> i have a disk which claims to be it, but i don't think i have anything with a blue hole to shove it in
<sforshee> rtg, I do have a USB 3.0 flash drive
<rtg> I'm inclined to just turn it loose on the word, then go away on vacation :)
<cking> apw,  you have that intel laptop
<rtg> world*
<apw> cking, ahh maybe that has one
<cking> apw, reckon it does
<sforshee> based on the bug description I wouldn't think that the peripheral itself needs to be 3.0, just the port
<manjo> was wondering why this is USB 3.0 specific and not to the whole of usb 
<manjo> ie usb ports that are unused 
<apw> rtg, i note that the request says "most" ... are we sure this is even complete
<sforshee> I'm thinking it's a feature of their USB 3.0 host hw to turn off vbus
<rtg> apw, it is what is upstream so far
<rtg> at least it does not appear to have wretched USB2.0
<apw> rtg, and it is no use without the userspace bits, that description implies the sysfs interface is not yet set in stone ... so there won't be anything using ti either
<apw> might we actually be jumping the gun if the abi might change
<rtg> apw, the ABI cannot change if these commits are in the 3.9 merge window
<apw> rtg, it could if they change it before 3.9 final
<cking> sforshee, I like the reference in the bug to " If BIOS writers have done their job right..."  -  some hope
<sforshee> apw, the description in comment #5 indicates it would be used to power off unused internal ports, which I presume requires no userspace interaction
<sforshee> cking, ;-)
<rtg> I wonder what sarah thinks about 'em. I'm happy to retract 'em, but they also don't appear to be doing any harm.
<cking> sforshee, it seems to imply that we should add some user space interaction with it on specific events, like screen blanking
<sforshee> cking, for external ports yes
 * cking wonders how much extra power it saves
<manjo> cking, its in mAmps x 5v ... 
<sforshee> of course the question is how much current is used to power vbus when no device is attached
<cking> i doubt it will keep my laptop alive for an extra 30 mins then
 * ppisati -> EOW
<manjo> I think the displays eat more battery than unused usb ports 
<cking> bah, I'm now so curious I'm itching to get the power meter onto this..
<manjo> s/more/faster
<manjo> cking, but that quirk seems more appropriate for mobile devices 
<sforshee> manjo, mobile devices don't typically operate as usb hosts. I'm not sure about the details of how OTG works however.
<apw> or indeed have any ports worth speaking about
<manjo> deviating slightly ... have you guys seen this ? http://www.apple.com/thunderbolt/ it can provide up to 10Watts to devices
<manjo> we will soon need nuclear powered batteries at this rate 
<sforshee> I'd hope there's some kind of negotiation involved so that a laptop running only on battery could limit power draw to something more reasonable
<apw> i am amazed the port doesn't melt pulling that sort of current
<kamal> 10W!?   I can make ham radio contacts with that!
<sforshee> 18V at 550 mA, wow
<apw> kamal, you will probabally be making contact with people via radio whether you intend it or not at that power and frequencies
<kamal> apw: hahaha!
<cking> hrm, thunderbolt powered taser...
<manjo> cking, yeah there is an app for that 
<apw> cking, whats that about 3 ports would be enough to kill you i recon
<cking> depends what you taser really
<sforshee> manjo, I was curious about the OTG thing so I looked it up
<manjo> yeah me too ... 
<manjo> :) 
<sforshee> for OTG there's a different connector type with an extra pin and two different plug types, A for plugging in a peripheral and B for connecting to a PC
<sforshee> the new pin on the A-type cable is grounded, so I suspect a mobile device puts a weak pull-up on that pin and only turns on vbus when it detects the pin being pulled low
<manjo> I wonder what kind of efficiencies they get .... 80% ? 
<manjo> cking, tasers are old school now ... replaced with drones now 
<cking> sforshee, http://www.maximintegrated.com/app-notes/index.mvp/id/1822
<sforshee> cking, that's a nice description. It doesn't quite confirm what I said, but I can't think of any other way it would work.
<cking> once I need piccies of the H/W schematics I get a better idea of how it all hangs togther
<cking> s/need/get/
<sforshee> yeah, it's helpful. But it just shows the id pin as going off into the ether or something.
<cking> indeed, a bit weird that
<apw> bjf, fyi i only marked the upload-to-ppa tasks in progress and everything else has done its thing magically including closing that task too
<bjf> apw, thanks, good to know
<sforshee> cking, but the way I've typically seen that done is to pull up the signal and look for a high-to-low transition
<apw> bjf, only slight wrinkle is it has picked the wrong person as the owner of upload-to-ppa, it would be more right to use the copier if that information was available in the interfaces it is using
<sforshee> cking, for a b-type cable you wouldn't see that because the id pin will still be floating
<cking> ok
 * cking ~~> food
 * manjo off to school .. 
<apw> bjf, in the ckt ppa i see some natty packages, we could zap those i assume
<infinity> ikepanhc: How is it that armadaxp is the only flavour that didn't bump ABI in precise?  Did something get messed up there?
<lfaraone> apw:  cool, thanks
<lfaraone> rtg: that's not possible, sadly, for licensing reasons. 
<lfaraone> http://git.openafs.org/?p=openafs.git;a=blob;f=doc/LICENSE
<lfaraone> there's a choice of law clause which is GPL-incompatible.
<lfaraone> There's kAFS which is in the kernel, but kAFS is basically a bad idea based off a misunderstanding which doesn't support things like authentication. 
<apw> lfaraone, has anyone asked ibm if they can relicence it, they have been receptive in the past
<apw> lfaraone, it may take them a year of course, but they like gpl
<infinity> ikepanhc: Hrm, looks like the ABI checker ran, so assuming you had the right ABI files from the previous version, I guess it didn't lie.  Weird.  The ABI bump must have been x86-specific.
 * rtg -> lunch
<lfaraone> apw: I asked around, and heard back "yes, and no because $politics and $embargoed_reasons"
<apw> heh
<lfaraone> apw: this apparently was brought up ages ago and people are still talking about it. 
 * henrix -> EOD
 * rtg -> eow
<ikepanhc> infinity: I do not fully check the abi number, the checker do not ask for bump abi number
<ikepanhc> s/number/hash
<bjf> ikepanhc, where is your git repo for armadaxp?
<ikepanhc> bjf: git://kernel.ubuntu.com/hwe/armadaxp-{precise,quantal}.git
<bjf> ikepanhc, thanks
<bjf> ikepanhc, is that really: git://kernel.ubuntu.com/hwe/ubuntu-{precise,quantal}-armadaxp.git ?
<ikepanhc> bjf: yes, sorry, just wake
<bjf> ikepanhc, np
#ubuntu-kernel 2013-03-02
<infinity> smb`: I can haz linux-ec2?
<honcho>  I am new to linux kernel programming and I have recently written a very simple netfilter interupt handler that drops all packes. What I cant figure out is inorder to get the program to build correctly I had to do this
<honcho> #undef __KERNEL__
<honcho> #include<netfilter_ipv4.h>
<honcho> #define __KERNEL__
<honcho> if I did not it would throw an error when I would try to build the module
<honcho> NF_IP_PRE_ROUTING undeclared (first use in this function)
#ubuntu-kernel 2013-03-03
<hughhalf> clear
<dirtyfreebooter> I am building a custom kernel via make-kpkg but my symlinks in /lib/modules/*/build are never correct on the installed system, they always point to build directory on the system I built the kernel on
<dirtyfreebooter> and I noticed the postinst/preinst/etc scripts from /usr/share/kernel-package are different then the ones inside the official ubuntu kernel packages
<dirtyfreebooter> is there any recommended approach here when building a custom kernel to get those symlinks correct ? its cause dkms to hate me
<dirtyfreebooter> i've also tried different options in /etc/kernel-img.conf, but it doesn't seem to matter
<dirtyfreebooter> I am building out of the git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git and git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git git repos
<dirtyfreebooter> I need to backport an FCoE patch that is only in 3.6+
<dirtyfreebooter> seems like I should override the control scripts from /usr/share/kernel-package with the ones from the git repo in debian/control-scripts?
<_bjf> dirtyfreebooter, not a direct answer to your question but the instructions here have always worked for me: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<dirtyfreebooter> so _bjf suggestion worked great, only when I add my own custom flavour and run fakeroot debian/rules binary-custom .. I don't get the "extras" deb package, whereas I do if I run fakeroot debian/rules binary-generic
<dirtyfreebooter> I can't seem to figure out the missing piece to tell my custom flavour to build the extras package...
<dirtyfreebooter> needed to add a debian.master/control.d/custom.inclusion-list (copied from generic) to get extras package :-)
#ubuntu-kernel 2014-02-24
<infinity> apw: Diffing powerpc64-smp/powerpc and generic/ppc64el configs is an interesting read.
<infinity> apw: I'd expect them to be nearly identical except for default CPU twiddles and maybe some PS3 crap.
<miseria> "crimen legal es diabolico; crimen ilegal es satanico. Â¿donde esta el terrorista?: hay uno, es inmortal y se llama tiempo" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<ppisati> moin
<apw> infinity, yep, the config is a mess, and we all know how much fun a review is
 * apw yawns the yawn of mondayness
 * infinity still needs the elusive sleep of Sunday nightness before he can get to Monday yawning.
<infinity> zequence: lowlatency SRU ping.
<infinity> BenC: ppc SRU ping.
<apw> ppisati, hey ... you boneblack config patches, could you look at repeating those for unstable ?
<ppisati> apw: i'll do
<ppisati> apw: done, let me do a test build and i'll send it
<zequence> infinity: All kernels uploaded and waiting to build
<ppisati_> apw: actually T/unstable FTBFS - http://paste.ubuntu.com/6986421/
<ppisati_> apw: DRM_MSM
<apw> ppisati_, oh yeah so it does, you fixing that or i can put it on my list for later
<ppisati_> apw: doing it, else i can't test my bbone config changes there
<apw> ppisati_, ack
<ppisati> apw: actually T/unstable FTBFS
<apw> ppisati, it build on x86 for me
<apw> well 45m ago it did
<apw> ppisati, ok i have just pushed a few pulled forward changes to unstable
<apw> ppisati, not sure they would affect you but do match what i build-tested on x86 successfully
<apw> (pulled forward == a resync with changes falling into master-next)
<apw> (pulled forward == a resync with changes falling into master-next)
<apw> ppisati_, did you see my msg about pshing ?
<ppisati_> apw: failed building armhf
<ppisati_> apw: just saw it, i'll rebase
<apw> ppisati_, i expect it'll do that same, but worth a try indeed
<apw> henrix, i am futzing with some android cves to try and get them off of our non-android view
<apw> henrix, so prepare for carnage when the tooling loses its mind over what i added
<henrix> apw: ack, thanks. i'm not doing any cve work this morning, so feel free to break everything :)
<ppisati_> and another one...
<ppisati_> http://paste.ubuntu.com/6986491/
<rick_h> morning all, I'm working on getting trusty working on an air and it worked once, but then updates killed it and reinstalls aren't helping. It dies in boot at "Booting SMP configuration" per https://www.dropbox.com/s/behviox991o01o1/2014-02-23%2016.15.15.jpg
<rick_h> any ideas I can use to follow up/file a bug?
<ppisati_> that's weird
<rick_h> that's a boot where I edited the grub stanza to not be quiet, noapic, and nomoseset (though it's intel graphics and all the stuff I see around nomodeset is nvidia/ati stuff)
<apw> ppisati_, isn't bad_udelay meant to be missing, and something like a range check failure
<ppisati_> bah
<apw> rick_h, sounds bad ... which air is it?  file a bug with working kernel you had, and mention the broken one, though i thought we had a bunch of airs working ok around here
<ppisati_> at least bbone doesn't break anything
<rick_h> apw: it's a 2013 11". More details here http://askubuntu.com/questions/425267/issue-booting-14-04-on-macbook-air
<rick_h> apw: I can't get it to work again, even on the -8 kernerl. I thought the upgrade to the -11 was what killed it but I've reinstalled off the same usb media 3 times and can't get it to boot once after install
<rick_h> it's got me confused as the very first time I installed and rebooted it worked. I installed updates and it broke. I thought it was something with grub, but seems more kernelish
<apw> rick_h, could easily be, apple don't want you running linux so they don't help keep it working
<apw> rick_h, have you tried like a saucy live cd ?
<apw> live image
<rick_h> apw: no, the live image for trusty works. I used that to go back and do the reinstalls. I also used it to try to update-grub on it and see if something was off that a grub reset would fix
<rick_h> so I can boot reliably off of that daily iso each time
<rick_h> just not after install is completed
<apw> and which kernel does the daily iso have in it
<rick_h> good call, /me goes to get it and boot it again
<apw> rick_h, i would also say try booting it nr_cpus=1 on the kernel command line
<apw> never know might make it start at least
<rick_h> apw: k, will do
<apw> rick_h, and if you do another install when the install is finished but before you reboot one needs to see what kernel that has
<apw> you should be able to open a terminal C-A-t stylee, and check the linux-image-* package version
<apw> on your disk, by mounting it up and chrooting in
<rick_h> the daily iso I've got is using 3.13.0-8 3.13.0.8.12
<rick_h> that's what works repeatedly to get the installs up
<rick_h> and that's what's installed as well. 
<apw> if you don't install updates during the install then it would definatly stay the saem
<rick_h> yea
<rick_h> trying the single cpu thing now
<rick_h> is that a "set nr_cpus=1" or does that go in the linux stanza?
<apw> well if that is the last thing it says on boot, then it has to most likely be a kernel issue, or a bootloader init issue, so i would file a bug against 'linux' to start with, and let us know the bug number so we can see if someone has the same h/w you do
<rick_h> apw: rgr
<apw> no it is a kernel command line change, so where like 'quiet debug'
<apw> splash wahtever
<rick_h> cool, that boots
<rick_h> well got to the init list
<rick_h> there we go, lightdm asking for password
<rick_h> apw: ok, thanks. from this install I can run XXX to file the bug so it grabs my hardware info?
<apw> 'ubuntu-bug linux' from the command line
<apw> and include the cpu hack which got you booting
<infinity> Of course, the first thing people will ask is to upgrade to the latest kernel and try again, so that might be worth doing now. :P
<apw> there being a new kernel on there :)
<rick_h> heh, networkless atm booo
<apw> henrix, ok that seems to have worked right, panic over
<henrix> apw: cool, and looks like 2 cves are now gone from the matrix
<apw> henrix, yeah, finally got those to go away
<ppisati_> apw: bbone changes for T/unstable sent, i'll let you deal with the FTBFSs
<apw> ppisati_, thanks
<rick_h> apw: thanks, filed bug with notes #1284085. Had to file from the liveusb boot because of the wireless issue, but it had the same kernel so hopefully ok
<apw> bug #1284085
<ubot2`> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [Undecided,New] https://launchpad.net/bugs/1284085
<apw> rick_h, you should try updating that kernel to -12 and see if that works any better
<rick_h> apw: I'll try to find a way to update it. 
<rick_h> check out the latest daily iso, maybe it's in tere
<apw> ppisati_, is it you who does the ti-omap4 updates for SRU ?
<apw> rick_h, and i assume you have tried booting without the noacpi option
<rick_h> apw: correct, it still hangs at that SMP section
<psivaa> apw: just noticed, running command 'top' takes up about 2.3% cpu with Linux ubuntu-phablet 3.4.0-4-mako #25. would someone be able to take a look why this could be?
<apw> psivaa, is that a lot ?
<apw> takes .7 on my big laptop
<psivaa> apw: it appears so. we check for 97.5% idle time *using top command
<apw> you run top to find out if the box is idle?
<psivaa> so top itself taking up 2.3+ will always make that test fail
<psivaa> apw: yes, we run top about 10 times with some time interval to see if the system has settled down before running other autopilot tests
<apw> psivaa, was it ever anything other than 2.3% or could it be that what this is doing on a lame cpu like that will always be 2.3%
 * cking wonders how much cpu top uses nowadays on these devices...
<ogra> apw, it was below that in the past ... we have a test called systemsettle that runs top 10 times in a row, the average idle needs to be better than 97.5%
<psivaa> apw: so this behaviour is only after a new kernel update. earlier we used to have someting like http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/27/artifact/clientlogs/ubuntu_weather_app/topbefore.log/*view*/
<ogra> it used to be better until the switch to android 4.4 
<psivaa> about .1%
<apw> anyhow, it seems to me a daft way to get the idle time, when it is reported in /proc/stat
 * ogra didnt write the test ... 
 * apw didn't write the test either
<ogra> but i can see that it massively degraded since the weekend
<apw> yes, but perhaps that isn't top
<ogra> there are other processes too that expose higher CPU load though 
<ogra> (pulse mainly) 
<ogra> but that top jumped that high is also significantly noticeable
 * apw laughs, pulse on a phone, yeah ... lets do that
<ogra> ofono needs it 
<ogra> (well, telepathy does)
 * apw still laughs
<apw> pulse that machine eater here
<cking> ogra, so which ones of these have changed, considering you have output from top it should be obvious?
<ogra> it used to behave too for the last 200 images :P
<ogra> you would have to flip the whole android stack
<ogra> which makes the testing moot 
<apw> there is only 197,000 lines of change between the two
<ogra> ah, easy then
<ogra> ping me back for dinner about the responsible line please 
<ogra> :P
<apw> ogra, so what phablet-flash incantation do i need to get the image that is showing this
<ogra> phablet-flash is dead ... you want ubuntu-device-flash 
<apw> ok, what ubuntu-device-flash incantation do i need
<ogra> ubuntu-device-flash -channel=trusty-proposed -bootstrap=true
<apw> and ... where does it come from
<ogra> on mako, manta or flo ... 
<apw> given my lovely shiney updated 20m ago trusty box doesn't have it
<ogra> either trusty archive or for pre-trusty from the phablet-team ppa
<ogra> ogra@styx:~/Devel/branches/rootstock-ng$ apt-cache policy ubuntu-device-flash|grep 500
<ogra>         500 http://archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
<ogra> should be in universe
<apw> ogra, so if my phone has a -3 and is therefore pre this change yes?
<apw> psivaa, what top incation do you use to get this 2.3% number 
<ogra> system-image-cli -i 
<ogra> check the image version 
<ogra> 202 was the last android 4.2 one 
<ogra> you should see something like 206 if your device is recent
<apw> 153
<ogra> wow
<ogra> thats ancient
<apw> so, this is pre the change to 4.4 right? and top says top is taking 2.3%
<apw> though that is from looking at the screen and not at however how ps... is doing it
<apw>  2613 root      20   0    2556   1128    732 R  2.3  0.1   0:01.06 top          
<ogra> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/79/artifact/clientlogs/ubuntu_calculator_app/topafter.log/*view*/
<ogra> there you see that it bups up to 36% at times 
<apw> there is little supprise at that, have you seen just how much output this thing produces
<ogra> this is from image 196: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/64/artifact/clientlogs/ubuntu_calculator_app/topafter.log/*view*/
<ogra> for comparison
<ogra> and it was constantly like this 
<ogra> hmm, in faxct 
<ogra> apw, i see the 37% there as well at times ... i wonder if psivaa is just hunting fleas here 
<ogra> (btw the test was written by asac ... not sure why he didn parse /proc instead)
 * ogra waits for psivaa to come back
<ogra> i dont really think it is tops fault 
<apw> top is a very cpu intensive thing, it is doing 3 or file open and reads per process on your system for every single sample
<apw> ogra, ubuntu-device-flash seems to just hang anyhow, is there a trick to this new undocumented interface?
<ogra> apw, no, its the same thing in green^Wgo
<ogra> just a rewrite of the python tool in go ... 
<ogra> it should behave and function no different than phablet-flash did (less racy though)
<ogra> psivaa, so looking at older logs, top always spiked to something like 36% inbeteen 
<ogra> so i dont think this is something new
<psivaa> ogra: aiui when the settle test starts to run, 'top' always takes about 20% +, but then it settles down to .1% ish soon enough so that it dint influence the test
<psivaa> but now it stays on 2.+ %
<ogra> psivaa, i see it even on 196 spike to 36% during the run
<psivaa> ogra: would you mind pasting the top log please. i am only seeing that on the first iteration it goes to some large value and then on the comes down
<ogra> psivaa, https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/64/artifact/clientlogs/music_app/topbefore.log/*view*/
<ogra> at least three times in there 
<ogra> *during* the tests ... not at the beginning or end 
<psivaa> ogra: yea i see that. but the test will pass as soon as we see at least one top run where the idle time goes above 97.5
<ogra> psivaa, right, i just think it isnt an issue with top 
<ogra> it doesnt behave differently 
<psivaa> ogra: ok, yea, i was only concerned that it stayed at a constant level 2.3 % in the current image when it was only spiking in the past. probably something else then
<apw> psivaa-afk-bbl, ogra, ok this is accounted for by a change to what is reported in /proc/stat (which is consumed by top)
<ogra> aha
<apw> basically when the machine is idle, cpus are turned off complely, in the previous kernel the offline cpus counted as 100% idle, now the do not
<apw> they no longer exist when off, so if you busy the one online cpu it counts more
<ogra> yeah
<ogra> we need to adjust the test 
<ogra> (and someone should re-write it to not use top)
<BenC> infinity: building
<psivaa> apw: ogra ack, thanks
<apw> ogra, ok so phone in either the bootloader or recovery, flash does nothing obvious, so i cannot tell if it is doing it, or not, though if i remove the phone it doens't notice so i assume not
<ogra> apw, complaints go to sergiusens 
<ogra> :)
<ogra> apw, the code is go at least :)
 * apw gives up, 2 hours is enough, someone else can do the testing
<sergiusens> apw, there's a landing in the train with hints
<apw> sergiusens, but how do i diagnose it right now
<sergiusens> apw, what are you running?
<apw> ubuntu-device-flash -channel=trusty-proposed -bootstrap=true -device=mako
<sergiusens> apw, are you in the android bootloader?
<apw> device cause without it pukes about getprops being missing
<sergiusens> no need to use device flag
<apw> sergiusens, looks like the bootloader to me, the green thing on its back
<apw> it pukes without the device flag
<sergiusens> apw, does it say fastboot mode on the screen?
<apw> or does nothing
<apw> sergiusens, in red, yes
<sergiusens> apw, ok, might be a bug in the flags package which I'm changing (still under review)
<sergiusens> apw, run it like ubuntu-device-flash --channel trusty-proposed --bootstrap
<apw> sergiusens, ok so i pulled out the usb and put it back in, after booting it to the bootloader, and it has done something
<apw> so i suspect there is an ordering issue here
<sergiusens> apw, can you strace it?
<apw> sergiusens, it looks to have done whatever it was meant to and exited now
<apw> and the phione is doing something plausible.  so it seems lpugging in the phone then moving it to bootloader does not work
<apw> replugging it once in bootloader seems to have unstuck it
<sergiusens> apw, I tried that though
<sergiusens> apw, let me try again and see if I can reproduce
<apw> beyond me, hopfully you put some hints in there that tell you what it is trying so you can tell :)
<hallyn> apw: sforshee: hi, any new thoughts on the overlayfs xattr patch?
<infinity> BenC: \o/
#ubuntu-kernel 2014-02-25
<ppisati> moin
<apw> ppisati, moin
 * apw whines about the rain ... again
<smb> apw, Could send you a sunshine picture from outside my window. :-P
<smb> But don't worry, we are supposed to get rain again as well... soonish
<apw> smb, sounds better than the lashing rain we have ... again
<apw> i am going to hav to upgrade the gutters for monsoons
<smb> apw, You probably need bilge pumps
<apw> smb, sluice gates, probabally our own barrier
<smb> apw, At least you are uphill in the downs. Most of the water goes downhill from there. :)
<apw> ikepanhc, those two blocks of apm code, are they everything one needs to make those boards work on 3.13 ?
<ikepanhc> apw: I am afraid not. there are more coming for ethernet pcie kvm and rtc
<smb> apw, I see 5 and 12...
<ikepanhc> good news is most of them are for apm hardware only
<apw> smb, yeah two blocks, not two patches
<smb> apw, Ah right. /me should read
<apw> i could be clearer, but what is the fun in that
<apw> ikepanhc, and any idea how many further patches those three batches are?
<ikepanhc> apw: I can give you the exact number in few hours
<apw> ikepanhc, no rush
<apw> smb, cking, ppisati, i have a request to spin a kernel sooner rather than later (to build in some boot essential bits); anything on deck i shoudl be waiting on?
<smb> apw, not from my side right now
<cking> same here
<apw> ikepanhc, as and when you have a complete "stack" of all of those 5 sets i'd love a branch to look at, doenst have to be ready to submit to us, just so i can start looking at how frigtening it is
<ikepanhc> apw: sure, no problem
<brendand> cking, can you have a look at this fwts error message: http://paste.ubuntu.com/6994264/
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ppisati> what's the dpkg-buildpackage switch to pass down some opts to fdr?
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes - #ubuntu-meeting
<jsalisbury> ##
<hallyn> rtg: ogasawara: hi, stgraber and I were wondering, is it possible to turn off CONFIG_RT_GROUP_SCHED for all trusty kernels?  is there anyone who is using it  /depending on it?
<apw> hallyn, well it was on in saucy, so its a longterm on... so we'd need a good reason
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284731
<ubot2> Launchpad bug 1284731 in linux (Ubuntu) "Please turn off CONFIG_RT_GROUP_SCHED in all our kernels" [Undecided,New]
<stgraber> apw: the reason was that we never actually used those cgroups before trusty so never had the problem before then :)
<stgraber> now that we do, rtkit just fails for everyone
<apw> stgraber, so we never used it in S even though it was on
<apw> do you have the link to the upstream discussion which says they are bad for security?
<stgraber> hallyn: do you have some references to those e-mails from Tejun?
<hallyn> uh, gimme a few mins
<apw> you have a small window (if you can convince me) to get it in the next upload, which was 10s away
<hallyn> probably related to http://lkml.org/lkml/2013/4/8/912
<hallyn> stgraber: it was discussed several times at the plumbers sessions
<hallyn> it was a way in which a task in cgroup /a/b/c which had delegated write access to it scgroup could affect cgroups which were not just its decendents
<apw> as we didn't get to plumbers we don't have that background
<hallyn> smb may have been there?  hm
<stgraber> which happens to be the case since we delegate write acccess to the user for /user/<uid>.user/cX.session/
<ogra> apw, we definitely need it off on all phone kernels since pulse is critical there and needs RT functionality (which this option breaks)
<stgraber> apw: so yeah, the main point is that rt_* is fundamentaly broken at the moment. For any other key, if you mkdir a sub-cgroup, you'll get the same value as your parent and can then choose to set a lower value if you want to restrict your tasks. That all works for everything, except for rt_*
<ogra> the good news is that it is fixed for systemd :P 
<ogra> so we just need to do the switch before release and can keep it on 
<stgraber> apw: rt_* requires you to manually set that value, however apparently the hierarchy doesn't quite work with it, so if you have a/b and a/c and set a value for a/ nothing seems to prevent a/b + a/c to be <= a
<stgraber> ogra: no, that's wrong
<ogra> stgraber, i thought lennart fixed it ? 
<ogra> thats what the fedora bugs suggest
<stgraber> ogra: systemd doesn't fix this at all, Fedora has the exact same bug it's just that they don't set a cpu cgroup by default in their user sessions
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 4th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<stgraber> ogra: if they did, they'd hit the exact same problem with pulseaudio
<ogra> ah
<apw> ogra, which touch kernels need this
<hallyn> http://lwn.net/Articles/576049/
<stgraber> ogra: what Lennart did in systemd is prevent rtkit itself from being broken because of that cgroup stuff but he didn't do anything to prevent pulseaudio from being broken
<hallyn> so it's only "starving your siblings"
<ogra> apw, all of them ... flo, mako, manta, grouper, hammerhead and maguro (not sure how long we will still use the latter though)
<ogra> stgraber, aha ... 
<stgraber> apw: touch needs it urgently but the exact same applies to desktop. My laptop is reporting rtkit failures whenever I start pulseaudio an pulseaudio sure doesn't get rt prio
<ogra> yeah
<apw> stgraber, and did we ever decide that letting pulse should have it
<hallyn> stgraber: so why not have logind not create cpu cgroups?
<apw> hammerhead never heard of it
<ogra> apw, i think thats only in a PPA yet ... nexus5
<ogra> rsalveti, ^^^^
<stgraber> hallyn: because I kind of like unprivileged lxc to work and be able to set cpu cgroup restrictions
<apw> ok that is nothing at all to do with moi then, as we don't even have a branch for it
<hallyn> cpu or cpuset?
<ogra> apw, i guess you will get one soon :)
<hallyn> stgraber: cpu tracks, but i dont' think it restricts anything
<stgraber> hallyn: both. Cpu gives you cpu.shares, cpuset gives you cpuset.cpus
<rsalveti> ogra: yup, I got the tree, but only in a ppa for now
<apw> ogra, till i do :)
<ogra> apw, but yeah, not urgent now
<apw> rsalveti, ok ... if i spin kernels for these madmen :)  all to the PPA ?
<apw> "the PPA" == "the CKT PPA" 
<hallyn> stgraber: i was thinking cpu.shares was only tracking.  i *really* don't see why these are combined in one cgroup
<rsalveti> apw: yeah, please
<stgraber> hallyn: cpu.shares sure is writable, that's the only way you can restrict cputime AFAIK
<rsalveti> ogra: so you were right in the end
<ogra> rsalveti, indeed ... i am most of the time, i just cant prove it until someone else does :)
 * ogra trusts his guts :)
<rsalveti> hahah :-)
<apw> hallyn, none of those links make much sense, in that they don't indicate the security issue to my mind
<hallyn> apw: so if you have a cgroup /user/1000.user/c2.session, and you can write to cpu.rt-runtime_us, you can starve /user/1000.user/c3.session...
<ogra> but i know more about cgroups than i ever wanted to know since today :)
<hallyn> apw: mind you, cgmanager doesn't give you that write access, so it's moot there.
<stgraber> hallyn: except we're not using cgmanager yet
<apw> i thought we have a majorly clever cgroup manager with the lennart API and the world was going to be purfect
<hallyn> stgraber: lol.  "I am" :)  sorry, i forgot
<stgraber> apw: ha ha ha ;)
<hallyn> stgraber: so is logind not using cgmanager when it is available?  then logind is also doign the right thing
<hallyn> bc /sys/fs/cgroup/cpu/user/1000.user/c2.session/cpu.* is not owned by me
<stgraber> hallyn: it's not yet, I haven't finished that work and until cgmanager is in main, I can't possibly land that work
<hallyn> so anyway, I can't make either decision, but I do think the best option is to shut off that blasted RT CGROUP option, and the second best option is to have upstart put pulseaudio into /console cpu cgroup
<stgraber> hallyn: I'm just not sure how you'd want upstart to move something to /console, upstart isn't privileged and is already inside the user's cgroup, it can't possibly do that
<apw> ok i'll change this, and set fire to your hair if it mattered and you fibbed to me
<hallyn> free haircut
<hallyn> apw: is the overlayfs xattr bit going to be landing in trusty btw?
<apw> hallyn, wasn't it in -12 ?
<hallyn> stgraber: well we need some sort of solution - even if it is just having a separate cgroup subsytem for rt
<stgraber> apw: I need a haircut anyway ;) Anyway, I'd be very interested to know of anyone who actually depends on the current behaviour, because that sounds like depending on a bug to me... and a quick grep through all the usual suspects didn't get me any result for those cgroup keys, so I'm pretty sure nobody cares.
<hallyn> apw: hm, i checked a few days ago in master-next and didn't see it.
<hallyn> lemme re-fetch
<stgraber> hallyn: long term, having rt be sane would be nice, or have it in its own separate controller that we can blacklist and ignore ;)
<hallyn> stgraber: ^ tbh i fjeer there is someone out there who does depend on rt for some project they haven't told us about
<hallyn> apw: fs/xattr.c doesn't seem to have the change, no
<stgraber> hallyn: depend on rt, sure, ubuntustudio comes to mind, but depending on the cgroup bits of rt, I doubt it
<stgraber> hallyn: well, besides whoever got those in the kernel in the first place
<apw> hallyn, did yu get any further with that upstream
<hallyn> apw: no.  I cc:d Miklos on the patch, he never replied
<hallyn> I'll re-send the patch cc:ing linux-fsdevel@vger.kernel.org
<hallyn> stgraber: but getting back to the rt cgroup splitting up point - everything in kernel is long-term, so if we want that long-term we shoudl probably be talkign to Tejun/ml now
<stgraber> hallyn: well, to be honnest, I don't really care about the rt cgroup at all, so long as it doesn't get in my way ;) It'd probably be best for someone who actually uses the thing to argue about doing things right...
<hallyn> stgraber: the good news is if there is such a person we're about to hear from him or her
<apw> hallyn, so i am trying to understnad why this xattr change in the core isn't applicable to all of them, ie why it is not just ns_capable
<apw> hallyn, either way you should be using:  strcmp(name + sizeof(XATTR_TRUSTED_PREFIX) - 1, "lov") == 0) style matching as you know the first bit is trusted. already
<apw> hallyn, and can you cc: me on it this time when you send it as well, makes it easier to find
<hallyn> apw: well I suspect there are some $bigcorps using trusted.* as secret cookies in filesystems which they shouldn't be able to bypass
<hallyn> apw: sorry thought you were on the list
<hallyn> on my To list i mean
<apw> do you not have to be priviledged to make the user mappings though?
<hallyn> (bc i copy/pasted from last email, and why would i not have it in there?)
<hallyn> yes, though you can be uid -1 without any privilege...
<hallyn> or map uid 0 in namespace to your host uid
<apw> so then i could look at all of my trusted. attrs i assume hmmm
<apw> i suspect then they are going to make a new bit, like trusted.X. which is ok to use this way
<hallyn> apw: there is still something to your earlier idea of having overlayfs override_creds() also change the cred->userns
<apw> i suspect that is the right approach for its trusted bits, and not for everythign else, ugg
<apw> hallyn, i think i'll leave xattr out of this one as i am rushing it, and try this other approach first thing
<apw> hallyn, do you have a nice little recipe for me to test with, could you email it to me
<hallyn> apw: ok, thanks
<hallyn> ok
<jsalisbury> sforshee, you want me to build a test kernel with commit  c297c8b reverted for bug 1282302 ?  Or are you already taking care of it?
<ubot2> Launchpad bug 1282302 in linux (Ubuntu) "deadlock when unmounting nfs shares in trusty" [High,Confirmed] https://launchpad.net/bugs/1282302
<apw> jsalisbury, i say just go for it
<jsalisbury> apw, ack
<apw> ogasawara, ok ... fire in the hole
<ogasawara> apw: ack, thanks.  I'll keep an eye on it if you want to bail.
<sforshee> jsalisbury: I kicked off a build before I left for lunch, looks like it's done now
<jsalisbury> sforshee, ahh ok.  I built one as well and posted a link to it in the bug.
<sforshee> jsalisbury: in that case we'll use yours ;-)
<apw> ogasawara, i have every confidence in it building across the board :)
<apw> rsalveti, ok i have uploaded linux-mako to the CKT PPA for you, if you could let me know if that stops the fires
<rsalveti> apw: great, thanks
<apw> i'll get the others done in a bit
<apw> rsalveti, ok flo uploading shortly as well, let me know how those go
<rsalveti> will do, thanks
<cetex> uhm. i have an issue. i'd like to try the intel_pstate driver instead of the acpi-cpufreq one, but when i add the line "intel_pstate=true" to my /etc/default/grub's "GRUB_CMDLINE_LINUX" line, i still end up with acpi-cpufreq as my scaling_driver
<cetex> i've run update-grub2, and on /proc/cmdline i see: BOOT_IMAGE=/vmlinuz-3.11.0-17-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro "acpi_osi=!Windows 2012" intel_pstate=enable quiet splash vt.handoff=7
<cetex> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver still returns acpi-cpufreq
<Sarvatt> cetex: i think your quoting of acpi_osi is making it stop reading the later stuff, try GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=enable acpi_osi=\"!Windows 2012\""
<Sarvatt> thats what i'm using right now and it works
<cetex> ah, right.
<cetex> reboot. :)
<cetex> nope, didn't do it.
<Sarvatt> do you still have intel_pstate=enable after the acpi_osi?
<cetex> BOOT_IMAGE=/vmlinuz-3.11.0-17-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro intel_pstate=enable "acpi_osi=!Windows 2012" quiet splash vt.handoff=7
<cetex> though, i had it on the GRUB_CMDLINE_LINUX
<cetex> entering exactly what you have..
<cetex> nope, no difference.
<cetex> are you running the same kernel?
<cetex> then comes the question. does pstate support the new haswell cpu's?
<cetex> especially the i5-4300u
<cetex> i'd believe it does, but since i can't seem to get it working..
<cetex> hm. maybe not.
<Sarvatt> cetex: oh thats probably the problem, it does work on 3.11 for me but i'm on ivybridge, haswell was added in 3.12
<cetex> right.
<cetex> and as it seems, the latest for saucy is 3.12rc7
<cetex> should i go for a trusty kernel instead?
#ubuntu-kernel 2014-02-26
<infinity> cetex: The trusty kernel should Just Work on saucy.  Just means keeping on top of updates yourself (or using apt-pinning to allow trusty kernels but saucy userspace)...
<cetex> great. :)
<cetex> wget, dpkg. :)
<infinity> BenC: How did that ppc test build go yesterday?
<cetex> wooh, intel_pstate.
<cetex> :)
<cetex> i love the ulv cpu's.
<cetex> battery reports a discharge rate of 3.6w (gnome3/shell, urxvt, ssh, wifi), remaining battery time 6hours on one 3cell battery.
<cetex> :)
<bjf> did you do an update-grub?
<bjf> nevermind
<cetex> yeah. i did.
<cetex> when idling there's not much of a difference, but with pstate it seems to return to low power-usage much faster than it did with acpi-cpufreq
<cetex> this means i'll probably go from 16hours to around 18hours. totally awesome ;)
<ppisati> yo
<smb> ppisati, ho
 * apw yawns theatrically
 * ogra throws little marshmellows into apw's open moouth from the other side of the room
<apw> yumm, i needed some breakfast
<apw> rsalveti, did you try any of those new kernels?
<rsalveti> apw: sorry, not yet, getting there in a few
<didrocks> apw: hey, about the brightness issue I was mentioning: bug #1285172
<ubot2> Launchpad bug 1285172 in linux (Ubuntu) "Display brightness on internal monitor is set to minimum and can't be changed after plugin out the external monitor." [Undecided,New] https://launchpad.net/bugs/1285172
<didrocks> tell me if you need any other infos
<apw> didrocks, will do
<didrocks> thanks!
<apw> rsalveti, is there any point in updating the maguro kernel for this RT issue, given it is not 4.4
<rsalveti> apw: no, that's dead
<apw> rsalveti, ack
<ogra> apw, could it be that the latest touch kernels (mako, flo at least) have ACL support off ? 
<apw> ogra, which acls
<ogra> [   12.516784] systemd-udevd[796]: Failed to apply ACL on /dev/snd/controlC0: Operation not supported
<ogra> i see a lot of that in dmesg
<apw> ogra, if they arn't used on android, i'd be not
<ogra> well, i didnt see these messages in android 4.2 
<ogra> with the former kernels
<apw> was systemd the same version in that testing ?
<ogra> yes, i think so 
 * ogra checks
<ogra> yeah
<ogra> last upload was on the 6th this month
<ogra> and that were only ubuntu changes, no upstream 
<ogra> (we switched last week to 4.4 and the new kernels)
<apw> though flo never had a 4.2 kernel did it?
<ogra> yeah
<apw> ogra, for mako which does have such a kernle, the ACL config options are identicle as to tip
<ogra> ok
<apw> ogra, and indeed as /dev is a tmpfs they are enabled for that filesystem type at least
<ogra> i must admit i havent exactly checked on mako 
<ogra> only saw it in a logfile from someone else 
<ogra> on flo i can see it though 
<apw> do we care?
<apw> if so file a bug i guess
<ogra> well, acls should work across all devices i think :)
<apw> and we don't know they don't we have a single line from systemd saying stuff that sounds like it doens't
<apw> and feature parity not necessarily appropriate on a phone
<apw> ogra, anyhow, file a bug against the kernel you have definatly seen it on and we can poke
<ogra> apw, will do
<BenC> infinity: All done...what's the tracking bug on this?
<infinity> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1281893
<ubot2> Launchpad bug 1281893 in Kernel SRU Workflow "linux-ppc: <version to be filled> -proposed tracker" [Medium,In progress]
<BenC> infinity: All done
<infinity> BenC: Ta.  I'll spin up a test built later today.  After meetings and a nap. :P
<BenC> Have a good nap :)
<cetex> how do i find the people managing the cdc_ncm (wwan) driver?
<miseria> "la paciencia: es estar activo mientras esperas. la resignacion: es bajar la guardia, los sueÃ±os pasan y no te ven" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-02-27
<chilicuil> hi, I'm confused about how to generate a .dsc file from the kernel package, I downloaded an upstream kernel, applied some patches and on top of it ubuntu packaging files http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12.1-trusty/ (0001 and 0002), however it seems to require some special steps, I can see a debian/ and a debian.master/ folders, and debuild -S fails since debian/ doesn't contain a changelog.txt and control files, do I re
<chilicuil> if I run $ fakeroot make-kpkg --initrd kernel_image kernel_headers modules_image it compiles and creates .deb files correctly, though
<bjf> chilicuil, run fakeroot debian/ruls clean first
<bjf> chilicuil, then run the debuild command
<bjf> chilicuil, are you wanting to upload the package to your own ppa to have it built there?
<chilicuil> bjf: yep
<bjf> chilicuil, then you want to first "fakeroot debian/rules clean"   followed by: "debuild -S -I -i -uc -us -sa"
<chilicuil> bjf: ok, yep, it seems to work, do you know by change how to change the version pkg?, I tried s/3.12.1-031201.201311201654/3.12.1+chilicui~ck1/ and when running d/rules clean it fail with: debian/rules.d/0-common-vars.mk:9: *** first argument to `word' function must be greater than 0. Stop, line 9 in the mentioned file seems to look at the package version to set revision, revision ?= $(word $(words $(revisions)),$(revisions)) 
<bjf> chilicuil, change the version string in the first line of debian.master/changelog
<chilicuil> bjf: awesome, I may even take a look at how to do a flavour, the files start to make sense, thanks for your  help!
<bjf> chilicuil, after you do that you need to run "fakeroot debian/rules clean" again
<bjf> chilicuil, you should then have a debian/changelog that has your version in it
<chilicuil> it's clear, thanks for your help =)
<bjf> chilicuil, np
<ppisati> moin 
<apw> moin
<rtg> apw, have you been looking at why the ppc64el 64K config change broke the build ?
<infinity> rtg: *blink* ... It did?
<rtg> infinity, or rather, it has broken thecross compile (at least)
<infinity> Is it actually a 1-liner to the config, or did he oops something? :P
<rtg> infinity, as far as I can tell it is a legitimate change
<apw> rtg, not yet no
<rtg> apw, maybe I'm just being stupid, but it doesn't work for me
 * apw has a look
 * apw bets it is the subpage stuff it offered me
<infinity> -# CONFIG_PPC_HAS_HASH_64K is not set
<infinity> +CONFIG_PPC_HAS_HASH_64K=y
<infinity> That bit?
<apw> nope
<apw> oh stupid zone order issues
<infinity> Oh, subpage_prot.  I don't even know what that does.
<infinity> Seems suspicious that it landed in common.ubuntu when it wasn't set before, though.
<infinity> Unless it's only a dep of 64K, I guess.
<apw> but the first issue is zone bit sizes
 * apw sorted out the spagetti
<infinity> Anyhow, are we actually ready to make that change?  Are we satisfied on the state of the openldap issue?
<rtg> infinity, apw thinks he's proved it to be a test issue and can repro it using amd64 (IIRC)
<rtg> unless I completely misread his analysis, which is a distinct possibility
<infinity> rtg: Yeah, I'm familiar with the state of the bug.  But we were still not going to move until it was fixed.
<apw> infinity, the plan was to get the change ready, and when we are ready to upload again check with the    state of play in the bug
<apw> seems it was good idea, to make sure it builds even :)
<apw> we can revert it off if we arn't ready, i had hoped for more movement
<infinity> apw: Fair enough.  Easy enough to revert the commit (well, 2 commits now, probably), if we decide we're not ready.
<infinity> apw: I'm backchannel escalating a response on the matter. :P
<rtg> apw, since it is HEAD, how about just lopping it off
<apw> rtg, lop it sure, i'll queue it here
<apw> with the second half if htis builds
<rtg> apw, lemme know when you're done. I've got some mei cherry-picks to push
<rtg> (which I have test built)
<apw> rtg, zap that commit and shove over it, i'll branch here to keep this safe
<rtg> apw, done, and pushed
<apw> rtg ack thanks
<rsalveti> apw: can you also bump the meta packages in the ppa?
<rsalveti> guess it changed the abi for every device/kernel
<rsalveti> argh, got disconnected 
<rsalveti> apw: can you also bump the meta packages in the ppa?
<rsalveti> guess it changed the abi for every device/kernel
<rsalveti> Feb 27 15:02:08 ubuntu-phablet rtkit-daemon[1552]: Successfully made thread 3042 of process 1546 (n/a) owned by '32011' RT at priority 5.
<rsalveti> Feb 27 15:02:08 ubuntu-phablet rtkit-daemon[1552]: Supervising 3 threads of 1 processes of 1 users.
<rsalveti> looks good now
<rsalveti> ogra: ^
 * ogra has a hard time to type .... just chopped two trees in the garden 
<ogra> (cant feel my fingers)
<rsalveti> hahah
<ogra> but i won !
<ogra> :)
<apw> rsalveti, yep can do
<apw> ogra, whats the bug number for that second one
<rsalveti> thanks
<ogra> apw, havent filed it ... will do so ... soon 
<ogra> i wanted to check on all devices first 
<ogra> i'll get that done today
<henrix> kamal: hi! while processing 8d80390cfc9434d5aa4fb9e5f9768a66b30cb8a6 for stable kernels, i had to hack the notify-stable-patch-queued script
<henrix> kamal: here's a proposed patch: http://pastebin.ubuntu.com/7005732/
<henrix> kamal: the reason is the SMTP RFC that seems to limit lines to 998 chars :)
<henrix> kamal: a similar change will need to be done for the -review script
<kamal> henrix, looks fine to me
<henrix> kamal: cool!  i'll push it to kteam-tools
<henrix> kamal: and don't forget to use that new option in the next batch of 3.8 emails :)
<kamal> henrix, ok, I'll try to remember ... what's the effect if you don't use it?  it just stops in the middle of the notify run?
<henrix> kamal: no, it won't stop -- it will fail to send the 8d80390cfc patch, and hopefully you'll notice that :)
<kamal> henrix, ack
<henrix> kamal: ok, fix pushed
<miseria> "el amor inicia con la velocidad de tus ojos, aterriza en el poder de tu mente se cristaliza con la piel de tus manos" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<smoser> sforshee, 
<smoser> oops.
<rtg> jsalisbury, 'cifs: use standard token parser for mount options' is a giant patch
<jsalisbury> rtg, yeah, I figured it would be too big for inclusion in stable.  
<rtg> jsalisbury, I'm thinking we could just backport  the relevant part of 'cifs: set MAY_SIGN when sec=krb5'. After all, its a one line patch.
<jsalisbury> rtg, the problem is the one line is in a function named cifs_parse_security_flavors, that gets added in the other large patch(8830d7e)
<jsalisbury> rtg, Maybe the bug reporter can use the lts-backport kernel 
<rtg> jsalisbury, vol->secFlg exists in the old code. I think its just a matter of adding that flag. See line 1116 in fs/cifs/connect.c in Precise
<rtg> Using the LTS kernel is also an option
<jsalisbury> rtg, cool, thanks for the pointer.  I'll build a test kernel with that one line change and also propose the LTS kernel.
<jackbrown> rec and arecord commands don't capture any sound on my machine could anyone help me to check how to set the proper device to capture sound ?
#ubuntu-kernel 2014-02-28
<rsalveti> apw: let me know once the meta packages are available in the ppa, so we can try to land them today in the archive
<apw> rsalveti, sorry been having fallout from any upgrade this morning, will be soon
<apw> rsalveti, ok they are all building or pending publication now
<snadge> whats the easiest way to try out the latest kernel/radeon driver in saucy? .. oibaf? edgers?
<apw> snadge, i would guess edgers, but #ubuntu-x might have better info
<jdstrand> so, I've noticed for a little while that if I have VMs running and then I suspend my machine, when I come out of suspend, sometimes they are unresponsive and qemu is pegging the cpu
<jdstrand> so I decided to look in kern.log this morning, and see: http://paste.ubuntu.com/7010323/
<jdstrand> what's interesting to me is that I suspending at Feb 27 21:36:08 and resumed at Feb 28 07:16:05
<jdstrand> I don't know how the ordering is supposed to all go, but it seems like all the 'kvm: disabling virtualization on CPU1' is happening way too late (as in, after I resume)
<jdstrand> maybe that is just when it hits syslog
<apw> the date on the left is a lie, that is "stopped" when syslog is frozed in the freezeing ling
 * jdstrand tries to remember the format of the kernel timestamp
<apw> seconds and microseconds since boot
<apw> or nanoseconds or something
<apw> Feb 28 07:16:05 localhost kernel: [260761.679027] ACPI: Low-level resume complete
<apw> i think that is the first thing it says on the way up, everything before that is before it went down, but cking is more is an expert on those msgs
<apw> jdstrand, are these 64 or 32 bit guests ?
<jdstrand> it was a 64 bit bit guest last night
<apw> not smb's bug then.  well, i think its time to file a bug, and we'll get smb et al too poke at it
<cking> apw, yep the timestamp is a lie at that poinmt
<jdstrand> I've seen it with more than this guest, but I'm not sure if I've only ever seen it with 64 bit
<jdstrand> ok, that makes sense then
<jdstrand> I don't see anything particularly wrong from a kernel perspective looking at the kern.log if I consider 'ACPI: Low-level resume complete' as the place to split
<jdstrand> except perhaps the CPU0 is never actually listed as having kvm disabled or enabled
<jdstrand> but I'm not convinced that is wrong
<jdstrand> ok thanks. I'll be testing hallyn's new qemu at some point soon, so I'll just put this on the backburner
<rsalveti> apw: thanks!
<apw> jdstrand, ok if its there, bug us up please
<apw> rsalveti, let me know if they are any good
<rsalveti> sure
<_bjf> arges, bug 1270237
<ubot2`> Launchpad bug 1270237 in linux (Ubuntu Quantal) "prevent the conntrack table from filling up in the kernel" [Medium,Fix committed] https://launchpad.net/bugs/1270237
<bjf> arges, you think we can set this to verified?
<arges> bjf: so far the user that's tested it hasn't hit the problem, but its one of those 'run for a long time and try not to hit it' problems
<bjf> arges, right. but we have to decide if we are going to revert or not at some point and now would be a good point :-)
<lamont> why does trusty's grub-probe say: grub-probe: error: unknown filesystem.
<apw> lamont, any idea which one it is whining about ?
<lamont> there are several options
<lamont> which is to say, no.
<lamont> trusty upgrade threw a fit when memtest86+ and the kernel postinsts failed as a result.
<lamont> and then the reboot led to a kernel panic (no root fs, iirc - didn't look much), so I'm running trust on a 3.11 kernel atm
<lamont> apw: I don't mind the unknown filesystem as much as I mind the exit(1)
 * lamont gives the reboot the ol' college try
<lamont> apw: hints on where I might add a --verbose to have grub-probe be more forthright?
 * lamont throws strace -ff at the problem
<lamont> apw: it's complaining about /dev/mapper/sda5_crypt ...
<lamont> which, yes, it shouldn't like so much
<lamont> because it's an lvm pv
<apw> hurumph, i suppose this is related to the grub2 update
<apw> cjwatson, ^^ have yu seen any reports of grub getting whiney about encrypted drives ?
 * lamont really tries the reboot thing.  brb hopefully
<lamont> apw: after manually moving grub.cfg.new -> grub.cfg, life is happier and I'm running a trusty kernel
<apw> lamont, well that is something at least
 * lamont generates a strace -ff update-grub stream
<lamont> apw: who should I be pestering to look at chinstrap:~lamont/update.strace?  (is grub2 kernel, or foundation?)
<ogra> apw, bug 1286184
<ubot2`> Launchpad bug 1286184 in linux-flo (Ubuntu) "udev ACLs for sound devices can not be set" [Undecided,New] https://launchpad.net/bugs/1286184
<ogra> apw, seems it doesnt happen on mako 
<ogra> checking manta now 
<ogra> but it smells like this is flo specific 
<ogra> yup it is ... verified on manta 
<apw> ogra, ack
<apw> rsalveti, do you want to copy out the current flo before i upload, or shall i replace it
<rsalveti> apw: just replace it, I'm publishing the other packages in a CI silo (as we need to rebuild the android package as well)
<rsalveti> so don't worry, I'll get  them in the archive via a CI silo
<apw> rsalveti, so yo have taken them "elsewhere" ok
<rsalveti> apw: yeah
<ogra> yeah, so we are able to fish them out of the conatiner at least
<ogra> still better than having to download the package 
<rsalveti> yeah
<rsalveti> apw: just ping me once the new flo kernel is available in the ppa
<apw> rsalveti, ack
<hallyn> hi - i keep getting lockups which i was blaming on unity, but now am wondering whether it's kernel.
<hallyn> http://paste.ubuntu.com/7011147/  does this mean anything to anyone?
<apw> hallyn, not sure i know of them specifally, but it sounds like bad commands in the gpu pipeline, of course that could be mesa
<hallyn> ok - yeah i couldn't tell if nouvou was misbehaving, or was getting a bad command.
<hallyn> was wondering whether it is the same as https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1282342, or a kernel cause for it
<ubot2`> Launchpad bug 1284536 in compiz (Ubuntu) "duplicate for #1282342 compiz crashed with SIGSEGV in two_way_long_needle()" [High,Confirmed]
<hallyn> but no i guess it is unrelated.  sigh.
<apw> i would bring this up on #ubuntu-x someone might recognise it
<hallyn> heh, i try to avoid that chan, but ok will do :)  thanks
<sforshee> ogasawara, apw, bjf: do we have anyone going through these fedora kernel patch report emails and seeing if there's anything we should consider picking up?
<sforshee> e.g. https://lkml.org/lkml/2014/2/28/302
<bjf> sforshee, i'm sure kamal will be happy to look at those :-)
<sforshee> bjf: I noticed that the most recent one is patches on 3.13, which seems it would definitely be of interest
<bjf> sforshee, yeah, so someone from the dev kernel team should be looking at those. your on that team aren't you? :_)
<apw> sforshee, yeah that looks interestnig indeed, if you arn't looking :)  then i can on monday or s
<apw> so
<sforshee> bjf: I am, I just didn't want to duplicate effort if someone else is already doing it
<henrix> sforshee: i usually look at those in my usual review of stable patches, but this one may be of particular interest for T
<apw> sforshee, then ... we have a plan :)  thanks
<henrix> most of the time these are patches that hit the stable trees anyway, so... :)
<kamal> bjf, sforshee, henrix: I'm not convinced that all of those (or perhaps any of those) are suitable for stable
<henrix> kamal: well, yeah... i just saw there was an email, i didn't look at the patches
<bjf> kamal, and i'm ok with that evaluation
<kamal> bjf, sforshee, apw:  ok,henrix and I will look through them and compare notes
<ppisati> hey
<arges> hallyn: hey i'm looking at bug 1278531. there is a patch that fixes 3.13, but are you still seeing issues with a 3.11 kernel?
<ubot2`> Launchpad bug 1278531 in linux (Ubuntu) "nested kvm fails with trusty and upstream kernels" [Medium,Confirmed] https://launchpad.net/bugs/1278531
<hallyn> arges: 3.11 has a idfferent bug,
<hallyn> at least for me.  for some ppl it works fine
<hallyn> for me, kvm jsut hangs with 100% cpu
<arges> hallyn: ok is that tracked in a different bug or same one?
<hallyn> arges: iirc that bug originally was for that failure
<hallyn> we re-used it as i assumed at first it was the same.  but smb found that the 3.11 bug was probably fixed somewhere between 3.11 and 3.13
<arges> hallyn: ahh here's the other bug 1208455 to track it
<ubot2`> Launchpad bug 1208455 in linux (Ubuntu Saucy) "general protection fault running apt-get inside double nested kvm VM" [High,In progress] https://launchpad.net/bugs/1208455
<hallyn> that one gets more convoluted :)
<hallyn> arges: what exactliy are you trying to nail down?
<hallyn> you're having a failure on saucy?
<arges> hallyn: just want to make sure 3.11 work as well
<hallyn> ok.  yeah, i'm kinda letting 3.11 suffer until trusty is golden
<sconklin> #rake
<apw> rsalveti, ok uploaded flo, should be about an hour all things being equal
<rsalveti> apw: awesome, thanks!
<cetex> ACPI. Is it polling-based or event based? or a combination?
#ubuntu-kernel 2014-03-01
<mjg59> cetex: Event, by and large
<mjg59> Some devices won't deliver battery level without polling
<lamont> if I want to tell the kernel to just flat out ignore the do-not-fragment field, is that just a sysctl? or ?
<cetex> mjg59: thanks. I'm wondering since it takes about a minute before a battery shows up in acpi on my laptop.
<cetex> mjg59: the laptop has 2, one internal and one pluggable, when i remove the pluggable one it disappears within a couple of seconds. when i plug in a new one it takes slightly over a minute before it shows up.
<mjg59> Shows up in the UI, or shows up in sysfs?
<cetex> i replaced the battery within 10 seconds, and this is from syslog:
<cetex> Feb 28 21:51:50 kernel: [ 9633.140290] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: undocking
<cetex> Feb 28 21:53:01 kernel: [ 9704.235534] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking
<mjg59> Sounds like the firmware
<mjg59> But also possibly a Linux bug in dealing with the firmware
<cetex> battery firmware?, bios/uefi?
<mjg59> ACPI
<cetex> hm, right.
<cetex> so, file a bug somewhere?, i believe i'm running the latest firmware. (going to doublecheck this weekend though)
<cetex> err, bios and stuff.
<cetex> tried it again. seems to take exactly one minute..
<cetex> hm
<cetex> pluged it in on 01:44:45, appeared 01:45:46.
<cetex> shouldn't be an issue usually, i switched batteries today when i had ~3minutes left in total, i plugged the battery in, and in slightly less than one minute the os shutdown causing me to loose some work. (i'll remember to switch earlier in the future though)
<cetex> i'll look into it some more tomorrow. will probably be back. ping me if anyone would happen to be interested.. ;)
<miseria> "El Tiempo no agrada a todo el mundo, libre albedrio, quien seria yo si pudiera hacer lo que el tiempo no puede?" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-03-02
<raj_> " kernel: Cannot read proc file system: 1 - Operation not permitted. " getting these messages repeated, unstoppingly million times every minute in my syslog on 12.04 ubuntu VPS based on OpenVZ, anyone has any idea please ???
#ubuntu-kernel 2015-02-23
<diwic> Are you going with 3.18 or 3.19 for vivid? I thought it was 3.19 but it isn't yet in the archive...
<apw> diwic, we are planning on 3.19, it isn't in the archive only because we have issues with some dkms packages, it is in the CKT PPA
<diwic> apw, ack, thanks for the update
<awe_> cking, could ( or someone else ) help me determine the device types of both USB ports on my macair?  The online hw specs states it's two USB 3.0 ports, but lsusb shows me a USB 2.0 and 3.0 hub
<awe_> neither port uses a colored connector ( as is usual on machines with mixed ports )
<cking> awe_, i would have thought lsusb -v will provide enough info
<awe_> -v dumps so much damn info, that it makes my head spin
<awe_> ;D
<awe_> but that said, I guess I can dump to a file and read it a bit more carefully
<smb> awe_, maybe lsusb -t helps more but only maybe
<awe_> smb, thanks.... a little bit more.  Maybe I'll just reboot into OS X and ask it
<cking> yep, compare apple with pear, so to speak
<awe_> hah
<awe_> that said, wasn't there an app that Dell was lobbying to land that dumped detailed hw info for users?
<cking> awe_, you mean something like "hardinfo"?
<awe_> I think so... this was a few years back
<cking> http://smackerelofopinion.blogspot.co.uk/2010/11/hardinfo-look-at-hardware-information.html
 * awe_ installing
<awe_> course it doesn't output anything useful for USB devices.  ;(
<awe_> thanks for the suggestions cking and smb
<cking> oh, that's why we use lsusb ;-)
<awe_> long time since I've had to come to you guys for help
<awe_> ;D
<hallyn> apw: sforshee: sorry, i think i've asked before, but to be sure, noone from kernel team is attending lsf/mm, is that right?
<apw> hallyn, not i
<hallyn> was hoping there'd be someone who coudl talk with clameter and aluto about ambient capabilities
<hallyn> (without me having to fly out on my own dime)
<sforshee> hallyn: I'm not, was possibly going to bug cannot for personal reasons
<sforshee> *but
<hallyn> sforshee: right i knew you weren't, was hoping someone from the team was :)
<hallyn> ok, thanks
<sforshee> yeah no one that I know of
#ubuntu-kernel 2015-02-24
<mssbrg> Hi, I'm trying to download the source for a 3.17.8-031708-generic ubuntu kernel (running on a 14.10 system) but I'm having trouble
<mssbrg> apt-get source always seems to download a 3.16 kernel, and I don't see tags for 3.17 in the ubuntu/ubuntu-utopic git
<tmpRAOF> mssbrg: You've got that 3.17 kernel from the kernel âPPAâ; that's not an official Ubuntu kernel.
<tmpRAOF> mssbrg: If you want the source package you'll need to reconstruct it from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17.8-vivid/; COMMIT tells you the upstream commit, plus the 000?-*.patch files.
<infinity> mssbrg: And, to be fair, you really should never run those kernels except for testing, they're not in any way supported (or supportable).
<infinity> Nor are they tested in any way.
<mssbrg> O_O
<mssbrg> oh jeez. i never knew
<mssbrg> infinity: i guess i don't really understand why they exist or are available then?
<infinity> mssbrg: They're really just there to be able to test upstream kernels quickly as a coarse pre-bisection "does this work here?" tool.
<mssbrg> infinity: Ok. So if kernel.ubuntu.com/~kernel-ppa isn't a good place to get kernels, what is the recommended place? kernel.ubuntu.com/git?
<tmpRAOF> mssbrg: The recommended place to get kernels is âapt install linux-genericâ :)
<tmpRAOF> mssbrg: On 14.04 we also do backports of the latest release's kernel (+ X stack) for hardware-enablement purposes.
<mssbrg> tmpRAOF: sort of confused now because "apt search linux-generic" lists the linux-image-3.17.8-031708-generic kernel (currently installed) which infinity told me I shouldn't run?
<tmpRAOF> mssbrg: apt show linux-generic
<tmpRAOF> The âlinux-genericâ package is a metapackage that depends on the latest version of the official kernel.
<mssbrg> ah
<mssbrg> tmpRAOF: I also just realized I'm running a vivid kernel on utopic...is that bad? did I just get lucky that things seemed to work?
<tmpRAOF> mssbrg: The kernel version is not particularly important, as long as it supports your hardware.
<mssbrg> tmpRAOF: interesting. also a follow up ques on what you said earlier ("that's not an official Ubuntu kernel"): if that wasn't an official kernel, is it right to think that the git tags of the form "Ubuntu-3.xx.xx-etc" are the official ones?
<mssbrg> and the tags that are just vx.y.z are the regular mainline versions?
<tmpRAOF> mssbrg: The (source of the) official Ubuntu kernel is what you get when you run apt-get source linux-image-3.xx-yy-generic :)
<mssbrg> (sorry I have so many questions)
<mssbrg> 1. apt-get source always seems to download 3.16 for me. is there any way to force it download a 3.17+ kernel? or does that mean there are no official 3.17+ kernels for 14.10?
<tmpRAOF> There are no official 3.17+ kernels for 14.10
<mssbrg> 2. and from a git perspective was I correct about Ubuntu tags == official? or is there any way to tell what is official or not from git?
<tmpRAOF> Yeah, the official kernels are built from those git tags.
<mssbrg> thanks tmpRAOF! :)
<apw> jibel, hey ... trusty proposed-migration, the kernel autopkgtests show as Test in progress, and yet to my eye they are both complete, i suspect some kind of disconnect
<apw> jibel, and ... morning :)
<jibel> apw, good* morning :)
<apw> :) i like good mornings
<jibel> apw, well it was good until now. I'll have a look
<apw> (jibel, you get to chose channel)
<yggdrasi1> hello o/
<yggdrasi1> I have some issue using the USB blutooth dongle CC2540 from TI. It will be not recognized by ubuntu.
<yggdrasi1> [538509.561120] usb 3-1: new full-speed USB device number 44 using xhci_hcd
<yggdrasi1> [538509.580009] usb 3-1: New USB device found, idVendor=0451, idProduct=16b3
<yggdrasi1> [538509.580017] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<yggdrasi1> [538509.580021] usb 3-1: Product: CC2540 USB Dongle
<yggdrasi1> [538509.580024] usb 3-1: Manufacturer: Texas Instruments
<yggdrasi1> [539665.450983] usb 3-1: USB disconnect, device number 44
<yggdrasi1> bletooth module hci_uart, cdc-acm, btusb, rfcomm loaded
<yggdrasi1> but i didn't fire up th ACM0 tty
<yggdrasi1> is it an issue with the cdc_acm driver?
<yggdrasi1> also try to force this using modprobe cdc-acm but still the same
<yggdrasi1> also used the usbserial but not so much more result
<yggdrasi1> did one have an idea of my problem. What I want to do is to hciattach this dongle
<yggdrasi1> http://pastebin.com/vLB2BJMf
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<tohoyn> When I use kernel version 4.0.0-040000rc1 the system fails to shut down.
<tohoyn> It gets stuck on a blank screen with a cursor.
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
<tohoyn> ubuntu with kernel version 4.0.0-040000rc1 fails to shutdown
<tohoyn> is here some meeting ongoing?
<ogra_> no, thats usually in #ubuntu-meeting
<ogra_> (but i think they are done)
<tohoyn> ogra_: did you see my message about shutdown failures?
<ogra_> yeah, i'm no kernel dev ... 
<apw> tohoyn, that is an -rc1 so i am not supprised
<ogra_> and it has a scary amount of zeros in the minor version :) 
<mssbrg> can anyone explain to me the format used for tags in the ubuntu kernel trees? for example: Ubuntu-3.18.0-10.11
<mssbrg> I can see that the upstream version number always seems to be held at .0 and then it seems like the other two numbers refer to updates being pulled from upstream?
<apw> mssbrg, yes, we would like to call it 3.18-10.11, but some of usespace gets all snarky
<apw> so ignore the .0 and then -10 is the ABI number, and .11 is the upload number
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 3rd, 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.
<mssbrg> apw: I think I understand, but I'm not familiar with ABI/upload numbers :/ To rephrase, for the mainline v3.18.7 kernel for example, where does the .7 go/what is the corresponding ubuntu tag? 
<apw> mssbrg, it does not go anywhere, it will be inside one of the ABIs if it is applied
<apw> you can tell from the running system what base version it really is in /proc/version_signature
<fossterer> Hello kernel team! Can I get sources for the kernel I downloaded from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.6-maverick/ ?
<fossterer> The source... deb there is empty!
<infinity> fossterer: The source is in git.
<infinity> apw: What's the magic to translate mainline builds into git repo/tags so people can actually hunt down the source?
<fossterer> infinity: Here? http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.6-maverick/
<fossterer> !git
<ubot5> git is a distributed revision control/software code management project created by Linus Torvalds. For more information, see http://en.wikipedia.org/wiki/Git_(software)
<fossterer> !kernel
<ubot5> The core of Ubuntu is the Linux kernel: see https://help.ubuntu.com/community/Kernel - You shouldn't have to compile your own, and if you need to troubleshoot issues, you can try a !Mainline kernel instead, but if you insist, see https://help.ubuntu.com/community/Kernel/Compile (see also !Stages)
<fossterer> I get hits for 2.6.32 as well as 2.6.34.. Where do I find 2.6.33 ?
<fossterer> Help ^^
<fossterer> I am looking here: http://kernel.ubuntu.com/git
<infinity> fossterer: I would guess ubuntu-archive/ubuntu-maverick.git, or the 2.6.33.6 tag in linus's tree upstream, but I'm not positive, hence why I asked apw for input.  Be patient.
<infinity> fossterer: But a more curious question, WHY?!  Why do you want an ancient unsupported kernel? :P
<fossterer> Ohh.. Thanks.. I'll be here
<fossterer> infinity: Sorry, I was away...
<fossterer> infinity: I have a few patches to be applied to 2.6.33.6 kernel to make it work with 802.11p
<apw> fossterer (N,BFTL), there is no source package for the mainline builds, they are built from virgin upstream sources, the COMMIT file contains the linus tag/commit they are built from and the patches therein ????-* are applied on top to make the source
<apw> infinity, ^ incase he asks again
<mssbrg> out of curiousity, if the idea for those mainline builds to to have a virgin upstream build, then what are the patches for?
<mssbrg> *is to
<infinity> apw: Given that they're producing binary packages, it might be nice to produce a matching source package so people don't ask questions.  Or, at least, have the top of the build log explicitly state what to clone, what to checkout, and what to add to make it go.
<infinity> apw: But, in that guy's case, I'm less fussed about GPL compliance and more still very confused by why he cares about 2.6.33
#ubuntu-kernel 2015-02-25
<mssbrg> reposting in case no one saw this (ping apw): out of curiousity, if the idea for those mainline builds is to have a virgin upstream build, then what are the patches for?
<mssbrg> also, are the patch files supposed to be applied to the tree from kernel.org or the Ubuntu tree? seems the first patch file is changing the debian.master directory which does not exist in the kernel.org tree
<mssbrg> and if I'm indeed supposed to apply the patches to the ubuntu tree, for my case where I'm using the 3.17.8 ppa build, there is no v3.17.8 tag in the vivid tree to checkout to :/ 
<apw> infinity, a source package is bigger than the entire output we are making them for, and at least at the start we didn't have the space for that
<apw> infinity, though yes, why that anchient poc
<mjg59> apw: Are you pointing people at an Ubuntu git mirror?
<apw> mjg59, for the mainline builds, no, they are pure linus
<apw> i guess i get to try and add some wording to every build, hmmm
<mjg59> apw: Hm. That's dubious.
<mjg59> Pointing to repositories outside your control isn't usually considered sufficient for GPLv2
<mjg59> Just keeping a mirror of Linus on kernel.ubuntu.com/git should be fine, though
<apw> mjg59, $DEITY i should just stop producing them
<mjg59> Heh
<apw> mjg59, i'll look at sorting a mirror out, we may have one already
<apw> and get some more docs in there
<mjg59> I mean, the alternative is for you to just fall back to written offer and provide source on request
<mjg59> And then manually put the packages together whenever someone asks for it :p
<apw> mssbrg, the patches apply in theory at least to the virgin commit listed in the COMMIT file, from a linus clone
<apw> that is how the binary builder which made the binaries, makes them
<apw> bah some of these are so old they don't even have the commit file, thats ... annoying
<apw> time for some heavy surgery me thinks
<apw> mssbrg, you'd need to give me the exact version you are looking at to follow along
<apw> mjg59, oh good we do have a virgin tree already, so i can just refer to that in a README perhaps
<mjg59> apw: Yeah, a pointer to that and a hash should be fine
<apw> mjg59, i will make it so
<jhenke> hi folks, it seems today's kernel update introduced a regression for people using the 2015 Dell XPS: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1425445
<ubot5> Launchpad bug 1425445 in linux (Ubuntu) "Regression: 3.16.0-31-generic breaks touchpad on Dell XPS13 (2015)" [Undecided,Confirmed]
<smb> henrix, Sounds like ^this may require the patch that Seth posted recently for Vivid
<smb> HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events
<apw> mjg59, how does http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-rc1-vivid/README sound
<mjg59> apw: Looks good to me
<apw> mjg59, great thanks, i've pushed that to them all, and will rebuild a few which are missing patches
<henrix> smb: i'll have a look in a sec
<smb> henrix, ok, thanks. I also sent some reply to our ml to make us not forget
<henrix> smb: ack, thanks
<mssbrg> apw: I'm looking at this version: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17.8-vivid/
<apw> mssbrg, ok there now is a README in there which should help you get the source you want
<mssbrg> Thats so helpful, thanks apw! Part of my misunderstanding was that I didn't know that "virgin" referred to an actual tree in ubuntu's repos and not the one from kernel.org
<apw> mssbrg, np, i've shoved those into all of the builds
<Suudy> So, the latest Ubuntu ABI change for 14.04 moves from 3.13.0-45 to 3.13.0-46.  Unfortunately, this change breaks my MVFS driver (for Clearcase).  It looks like they have the 3.19 version of dcache.h sucked into a 3.13.0 kernel.  I see the raw 3.13.0 version of dcache unchanged until 3.19, but certainly such a change to a key data structure (dentry) would trigger a much larger change.
<Suudy> Is there a way to detect this sub-version (e.g. -46)?
<infinity> bjf: ^
<bjf> apw, ^ we have a define for that don't we? ... /me goes looking for it
<Suudy> I know the fix for the driver, I just need a way to tell the difference between 3.13.0-45 and 3.13.0-46
<infinity> So, this has an elegant(ish) autoconf solution to the problem: http://launchpadlibrarian.net/197087396/openafs_1.6.1-1%2Bubuntu0.4_1.6.1-1%2Bubuntu0.5.diff.gz
<infinity> But yeah, if you're looking for a kernel version check, that's tougher, as it's all 3.13.11, with extraversion bumped.
<infinity> (Thanks, Greg)
<bjf> i'm sure we put something in for out of tree drivers detecting the abi ... i just can't find it ... still looking
<infinity> You did.
<infinity> I just forget where. :P
<infinity> And if we backported it.
<Suudy> Is that extraversion then Ubuntu specific?  I suppose an ifdef check to see if that extraversion is there, then do further checks.
<apw> bjf, we do indeed have an ABI specific define
<apw> Suudy, bjf, UTS_UBUNTU_RELEASE_ABI
<infinity> That said, relying on a version check will be fragile.
<bjf> apw, yeah
<infinity> apw: Oh, it's autogenerated at build time, no wonder I can't find it in a diff.  Derp.
<Suudy> And what I'm most confused about is how 3.13.0-46 changed dcache.h so significantly.  Yet looking at the raw 3.13 dache.h (http://lxr.free-electrons.com/source/include/linux/dcache.h?v=3.13) it is the same as 3.13.0-45
<Suudy> infinity:  Thanks for the autoconf solution.  Sadly, the MVFS driver is Makefile based.  And I'm not sure how to replicate the functionality of AC_CHECK_LINUX_STRUCT
<infinity> Then yeah, you might be stuck with a version check.
<bjf> Suudy, it was a backport of: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=946e51f2bf37f1656916eb75bd0742ba33983c28
<Suudy> I guess I'm a bit confused then.  So when the version says 3.13.0-46, it really means 3.13.11 with a bunch of later changes merged in?
<Suudy> Or is this for a pending (if ever) version of 3.13.12?
<infinity> Suudy: It's 3.13.11-ckt15
<bjf> Suudy, it is 3.13.0 with all stable releases applied up to ^ what infinity just said
<infinity> Suudy: 3.13.11 is dead upstream, we're the new maintainers, however for political reasons, we don't maintain it on kernel.org (not our choice).
<Suudy> Ah!  Well, I learned something new.  I'd never heard of 'ckt' before.  Now it makes sense.
<bjf> Suudy, if you look at our git repo for trusty it's easier to understand (i think)
<Suudy> And no wonder the folk on #kernel-newbies told me to talk to Canonical or IBM.  Makes sense now.
<infinity> Anyhow, it looks like this is about the only useful define you're going to find:
<infinity> include/generated/utsrelease.h:#define UTS_UBUNTU_RELEASE_ABI 46
<Suudy> Thanks for the clarification!
<infinity> Which is... Kinda useless for differentiating between upstream and Ubuntu, since you can't include it unconditionally...
<infinity> And it's not uapi exported.
<infinity> apw: Dude.
<infinity> apw: How are people supposed to use this header? :)
<infinity> Oh, I guess it doesn't need to be uapi.
<infinity> But still.  Not sure how one's meant to use it for code that's meant to work on !ubuntu as well.
<Suudy> Well, since this change would be Ubuntu specific, I just forked off the source and made Ubuntu specific changes.
<infinity> Suudy: Okay, well, in the forking world, easy enough, as above.
<Suudy> And this driver source only checks for < 3.6.  So any other changes (such as in 3.19) would be broken anyhow.
<Suudy> Again, thanks for the help!  Greatly appreciated.
<apw> infinity, you'd use it in a define which is different depending on whether the underlying define is present
<apw> infinity, and there is no point in us supplying that as you need to do something depending on whther that was present
<apw> #ifdef UTS_UBUNTU_RELEASE_ABI
<apw> #define UBUNTU_VERSION(a, b, c) (((a) * 10000) + ((b) * 100) + (c))
<apw> #else
<apw> #define UBUNTU_VERSIONS(a, b, c) 0
<apw> #endif
<apw> stylee
<cyberkryption> anyone tell me what the three numbers after the hash in uname-a mean?
<apw> cyberkryption, paste an example ...
<apw> cyberkryption, as the default there is only one number there 
<cyberkryption> ok i am building arm kernel for a raspberry pi and have kernel modules that wont load. pi kernel uname -a is Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Mon Feb 23 19:52:56 GMT 2015 armv7l GNU/Linux my compiled kernel is Linux kali 3.18.7-v7+ #758 SMP PREEMPT Mon Feb 23 19:52:56 GMT 2015 armv7l GNU/Linux
<cyberkryption> i want to know the difeerence between #755 and #758 it looks to be some sort of kernel subversion
<mjg59> That's the buld number
<mjg59> build number
<mjg59> The first build from a kernel tree will be #1
<mjg59> Every subsequent build from the same source tree will increment it
<mjg59> It's ignored for module versions
<cyberkryption> ok so my pi kernel is three builds from my kali ie 755 vs 758
<cyberkryption> could the difference be accounted for by difference source tree kernel branches/
<ogra_> no, it just means that one of them was built 3 times more often from the same tree
<cyberkryption> problem no kernel modules get loaded as part of boot process, if i try manual insmod i get uio: disagrees about version of symbol module_layout
<cyberkryption> on googling this pointed me to some module or kernel differences
<cyberkryption> but i have done modinfo on the modules that fail to load and they are identical
<cyberkryption> so i wanted to know the significance of the hash in uname -a
<cyberkryption> is there a better way to pull a running config than zcat /proc/config.gz
<cyberkryption> does this mean that the symbols in the modules are in different position in the compiled modules to where the kernel expects it to be?
<cyberkryption> therefore it wont load?
<cyberkryption> ok solved it, it has to wth the fact that the modules.symers was not used in the kernel compilation process
<infinity> apw: My point is that to get that ifdef working, you need to include a header that isn't included from any other standard header, which is a fail.
<infinity> apw: You can't know it's Ubuntu without that header, so you can't conditionally include it, and you can't unconditionally include it, since it's not in !ubuntu kernels.
<apw> infinity, that include file is a completely standard header that the other kernel version defines are in 
<apw> infinity, it is the one with the normal kernel base version in
<apw> infinity, or at least that is the intent, if it is not it is broken
<infinity> apw: Oh, is UTS_RELEASE an upstream define?  In that case, never mind my whining.
<apw> infinity, UTS_RELEASE is what is included in the uname -a output
<infinity> apw: Check.
#ubuntu-kernel 2015-02-26
<cmagina> a commit that was pulled into the recent trusty sru via lp1419838 broke booting on arm64. the fix is already upstream and in the ubuntu/linux tree as commit: d6ad36913083d683aad4e02e53580c995f1a6ede what is the process for getting that in as soon as possible?
<apw> bjf, henrix ^
<henrix> and kamal :)
 * henrix goes look at the bug
<henrix> ah, it's a stable update
<cmagina> yeah, sorry, guess i should have left off the lp part so mup grabbed it
<henrix> cmagina: a new SRU cycle will start next week
<apw> bug #1419838
<ubot5> bug 1419838 in linux (Ubuntu) "Trusty update to v3.13.11-ckt15 stable release" [Undecided,Confirmed] https://launchpad.net/bugs/1419838
<cmagina> henrix: today is the last day for commits, correct?
<henrix> cmagina: if we have that fix in, it will take ~3 weeks to be released.  is that soon enough?
<cmagina> henrix: well, it currently breaks all arm64 boards that install the updates kernel
<cmagina> they won't boot
<henrix> yeah, a nasty one :-/
<henrix> bjf: ?
<apw> cmagina, do these board have a button to boot a previous krenel or are they bricks after this
<cmagina> apw: not easily, they all use uboot. so requires a rescue environment
<cmagina> so, pxeboot a working kernel and fix it there type deal
<apw> cmagina, and that id in updates or proposed
<apw> is
<henrix> apw: updates
<henrix> i was just checking that :)
<henrix> so, it has been already released
<cmagina> yeah, we missed it in our testing
<cmagina> our infrastructure has been getting moved around
<apw> as in we didn't do any i assume ?
<cmagina> yeah, the tests that verified the proposed kernels was disabled
<cmagina> were
<cmagina> fun of moving labs
<henrix> cmagina: do we have a bug # for that already?  let's wait for bjf and see what he thinks
<cmagina> henrix: i will submit one
<henrix> cmagina: thanks
<apw> cmagina, and only trusty yes ?
 * bjf reading
<kamal> fyi, the offending commit was ported to 3.16 also
<cmagina> apw: i have not tried utopic yet, its on my list
<apw> did we get the fix above as well ?
<kamal> ah, I see the fix got applied to 3.16
<kamal> ... but hasn't yet appeared in utopic.
<henrix> kamal: yeah, both commits are in 3.16 stable, but none has hit utopic yet
<bjf> henrix, apw, cmagina are we only talking about Trusty at this point?
<kamal> henrix, lucky!!
<cmagina> bjf: thus far, i need to test utopic
<apw> bjf, i think kamal is just saying that utopic has been spared
<henrix> kamal: :)
<kamal> bjf, yes, this looks like it should only affect trusty at this time
<kamal> though cmagina is welcome to test it anyway
<kamal> bjf, the fix commit is trivial.  I'll apply it to 3.13-stable immediately:
<kamal> d6ad369 clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64
<bjf> kamal, henrix, cmagina, apw, i think we need to get this fixed and get that fix out asap 
<bjf> kamal, henrix, cmagina, apw, put simply, we spin trusty with just this fix
<kamal> bjf, I'm okay with that
<kamal> cmagina is filing a bug (right now?) ... we'll need that bug number.
<cmagina> kamal: yes, i'll get that now
<bjf> kamal, henrix, cmagina, apw, however, we need to get the testing of these sorted out so we don't end up here again
<henrix> would this also affect lts-backport-trusty?  since it's arm64, i guess not...
<henrix> cmagina: ^
<henrix> bjf: ^
<apw> there is arm64 arch in trusty 
<apw> but not in precise, so 
<apw> i assume that means spinnin ghte lts-backport is pointless for this
<henrix> cool
<cmagina> kamal: bug 1426043
<ubot5> bug 1426043 in linux (Ubuntu) "kernel 3.13.0-46.75 fails to boot on arm64" [Undecided,New] https://launchpad.net/bugs/1426043
<kamal> cmagina, thanks much
<bjf> apw, cmagina do we know if we use any of this HW for buildds ?
<cmagina> bjf: i do not believe so. we did donate a board as a porter
<cmagina> dannf: did we donate any of our arm64 hardware as buildd's?
<dannf> bjf: yes, but they don't run ubuntu's kernel
<bjf> dannf, we are not running our own kernels on our buildds ?
<dannf> bjf: nope - and no technical reason ttbofmk. i send gentle pokes about that every month or so
<bjf> dannf, do you know where the kernels come from that they are using?
<dannf> bjf: yes - prebuilt binaries from apm
<dannf> from their bsp (which worked before ours did)
<dannf> to switch, they'll require a firmware update and initializing flash-kernel - i'm guessing that's just a man-effort issue
<kamal> bjf, apw: I just sent a [Trusty SRU PATCH] request for this ^^ to kernel-team@  ...  awaiting some ack's.
<kamal> Subject:	[Trusty SRU PATCH] clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64
<cmagina> kamal: what would the fixed kernel version be if thats possible to know at this point? that way i can get the word out to not reboot unless running that kernel
<kamal> cmagina, it will be 3.13.0-46.76
<cmagina> kamal: thanks
<mssbrg> is virgin/linux-stable an exact mirror of mainline? what is the diff b/t virgin/linux-stable and virgin/linux?
<kamal> mssbrg, virgin/linux.git is a mirror of mainline.  virgin/linux-stable.git is a mirror of the kernel.org stable repo (it includes all their stable branches, e.g. linux-3.19.y)
<kamal> cmagina, still around?  could we get you to verify that our freshly baked kernel fixes the ARM64 boot problem?
<bjf> dannf, ^ you available?
<dannf> bjf: yeah - working on it. making sure i can reproduce w/ the old before trying the new
<dannf> kamal: ^
<bjf> dannf, thanks!
#ubuntu-kernel 2015-02-27
<dannf> bjf, kamal : reproduced, now testing fix (sorry for delay, was letting a long-running build finish before rebooting)
<kamal> dannf, np -- we're still waiting on another arch to build it anyway, but wanted this test to happen before everyone disappears today
<dannf> kamal, bjf : new one works - is there a pub bug i should use to mark it verified or somethign?
<kamal> \o/
<kamal> dannf, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1426043 <-- maybe just add a comment
<ubot5> Launchpad bug 1426043 in linux (Ubuntu Trusty) "kernel 3.13.0-46.75 fails to boot on arm64" [High,In progress]
<kamal> dannf, and we'll take it from there.  thanks a bunch!
<dannf> yeah, thank you!
<cmagina> kamal, dannf: thanks much
#ubuntu-kernel 2015-02-28
<stgraber> so looks like the latest trusty SRU kernels are causing panics for IPv6 again... bug 1426618
<ubot5> bug 1426618 in linux (Ubuntu) "Latest 3.13 kernel update (3.13.0-46) is causing kernel panics related to IPv6" [Critical,Triaged] https://launchpad.net/bugs/1426618
<stgraber> happened here three times and had someone else report the same issue in bug 1404558 *which was from the previous similar issue)
<ubot5> bug 1404558 in linux (Ubuntu Trusty) "IPv6 related kernel panic following upgrade to 3.13.0-43" [Critical,Fix released] https://launchpad.net/bugs/1404558
<stgraber> apw: ^ FYI since you figured it out last time around
<stgraber> for now I'll be rebooting on -45
<tjaalton> ahah, it was the kernel nfs server that was eating all of my ram, and not letting go of it
<tjaalton> cache size increased at a rate of 8MB/5sec, stopped when the daemon was killed
<tjaalton> or maybe it was just bootchart, couldn't even free the cache once it hit 9GB
<Zhenech> heya, just a quick q: will vivid ship with 3.18 or 3.19?
<apw> Zhenech, 3.19
<cristian_c> Hello
<cristian_c> Where can I find the patched kernel for 3.19 stable?
<cristian_c> not mainline kernel,  but ubuntu kernels
<apw> cristian_c, in our main ubuntu-vivid.git report, now as master/master-next
<apw> s/report/repo
<cristian_c> ok
#ubuntu-kernel 2015-03-01
<udknight> is anybody oneline? I have a question concerning do_mmap_pgoff, anybody could help me?
<udknight> why we could just call do_munmap in mmap_region without care overlapping vma's vm_flags and new vma's vm_flags?
<udknight> If overlapping vma has different vm_flags or vm_page_prot or others' property,  how could we just destroy it and say new vma will cover old range?
<pepee> hi. this bug has been fixed, apparently:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313804  https://bugs.freedesktop.org/show_bug.cgi?id=42960
<ubot5> Launchpad bug 1313804 in linux (Ubuntu) "[HP Pavilion dv6-6145eo Entertainment Notebook PC] Laptop display does not turn back on after resuming from suspend" [Low,Incomplete]
<ubot5> Freedesktop bug 42960 in DRM/Radeon "Display does not work when resuming from suspend" [Major,Resolved: fixed]
<pepee> could you guys please merge the patch in the next release?
<pepee> I haven't been able to test it... but judging by the comments, it should work
#ubuntu-kernel 2016-02-29
<tseliot> apw: what is the proper way to request a config change in the kernel? I need DRM_AMD_POWERPLAY=y for my backport
<apw> tseliot, at this stage, a bug with the justification would be good, and then a patch as normal
<apw> or file the bug, and just tell me the number
<apw> tseliot, or are you asking how to apply a change in a big pull request ?
<tseliot> apw: that could probably fit the same bug report I filed for my backport (which affects the same code)
<tseliot> apw: I was thinking it would be worth doing it myself as part of the pull request
<tseliot> since, you know, backporting code just to keep it disabled is probably a little useless :D
<tseliot> the thing is, I don't recall doing that before
<tseliot> (a config change)
<leitao> rtg, hello. It seems that there is an issue with kernel 3.19 on the fixes for 1481357.
<rtg> leitao, yeah, I see verification-failed-vivid
<leitao> good. I want just to make sure that it does not fly under the radar. Thank you!
<rtg> leitao, I'll look at it a bit later this afternoon. gotta wrap up some other stuff first.
<leitao> rtg, no worries. As I said, just to make sure that you guys saw the problem.
<tych0> hi folks. i'm on the xenial kernel, 4.4.0-8-generic
<hallyn> sforshee: apw: hey, tych0 is finding apparmorfs sometimes not loaded 
<tych0> and i'm missing my /sys/kernel/security/apparmor is missing
<hallyn> but sometimes loaded (and for me it is loaded)
<hallyn> tych0: anything in journalctl?
<tych0> yeah, for me it is loaded too on other vms but this one
<tych0> nothing jumps out at me, but, http://paste.ubuntu.com/15245948/
<tyhicks> Feb 29 11:40:56 criu2 kernel: AppArmor: AppArmor disabled by boot time parameter
<tyhicks> Feb 29 11:40:56 criu2 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-8-generic ... selinux=1 security=selinux ...
<hallyn> tsk tsk
<tych0> oh
<tych0> how did that get there :)
<hallyn> gremlins?
<tych0> or an extremely elaborate troll
<tyhicks> I vaguely remember seeing a xenial bug go by for a package that was depending on selinux-policy-default
<tych0> i wonder how i turn it off
<tych0> somehow i do have that package installed, let's see what happens if i uninstall it
<tyhicks> tych0: do you have the "selinux" binary package installed?
<tych0> rc  selinux                             1:0.11                                  all          Security-Enhanced Linux runtime support
<tych0> but that might be because i just removed some stuff
<tyhicks> tych0: ok, do you have the "apparmor" package installed?
<tych0> tyhicks: yes, i have that one
<tyhicks> tych0: hmm... I thought that if you had it installed, it would set the right kernel boot params but it has been a while since I've tried switching between apparmor and selinux
<tych0> wwell, let me try to --reinstall
<tyhicks> that may work
<tych0> hm, even that didn't do it
<tych0> well never mind, maybe i'll just blow this vm away and start over :)
<tyhicks> tych0: the selinux packaging simply modifies /etc/default/grub to add security=selinux selinux=1
<tych0> ah, ok
<tyhicks> tych0: you should be able to remove those two params and run update-grub2 to return to using apparmor since our kernels are configured to use apparmor by default
<tych0> oh
<tych0> update-grub2 vs. update-grub :)
<tyhicks> either one
<tyhicks> I think they're the same
<tyhicks> yeah, update-grub2 is a symlink to update-grub
<tych0> ok, cool
<tych0> tyhicks: \o/ thanks!
<tyhicks> tych0: glad that it worked :)
<rharper> on Xenial, I've a USB flash drive that shows up when directly connected to x1 carbon gen1; but when plugged in via USB3 hub does not;  other usb devices on hub work (keyboard, nic, mouse) but not mass storage devices;  worked fine in 15.10; thoughts? lsusb does not even list the device when plugged in 
 * hallyn at that point in writing a new kernel patch where you wonder 'do i type make for the first time and see where it breaks, or reread the patch to look for obvious errors?'
#ubuntu-kernel 2016-03-01
<apw> rharper, hrmm, no that just sounds odd to me normally they would be the same as even your first level ports are on a hub
<apw> rharper, i would ask you to file a bug, and get straight to bisecting for it as it worked before
<tjaalton> is the amd64 build of 4.4.0-9 stuck somehow?
<tjaalton> https://launchpad.net/ubuntu/+source/linux/4.4.0-9.24/+build/9279168
<tjaalton> nah, done now
<apw> tjaalton, was stuck indeed
<tjaalton> ah
<tseliot> apw: hey, would this be a good pull request? http://paste.ubuntu.com/15256740/
<tseliot> bjf: my work is complete, and applies cleanly, with zero conflicts ^
<tseliot> and it works well :)
<apw> tseliot, i am just going to assume you are jesting
<tseliot> so, if that pull request is good, shall I paste it in the bug report or send it to the mailing list?
<tseliot> apw: I didn't say it was just a couple of commits
<apw> tseliot, so you are serious ... ugg, good in the sense it is properly formed, bad in the sense there is like 200 commits
<apw> tseliot, i'd need to fetch it to see how impactful it is in !amdgpu
<apw> tseliot, but if its what you need, sending it to the mailing list is your next thing ... but do add some "why" to the top of the pull request
<tseliot> apw: ok, I am also going to complete the bug report, just in case
<apw> tseliot, thanks indeed
<apw> tseliot, though i man never invite you to meet my parents after this
<tseliot> apw: am I detecting a hint of sarcasm? :P
<apw> just a hint
<tseliot> :D
<rtg> leitao, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481357/comments/13
<ubot5> Launchpad bug 1481357 in linux (Ubuntu Xenial) "[LTCTest][Kernel][OP810]Ubuntu14.04.3: kernel call trace while continuously switching between smt on/off and changing subcores" [Medium,Fix released]
<peat-psuwit_> Could anyone help with using backport tree? I ran ./gentree.py --integrate ... and it said "no such file or directory: <kernel-target>/backports/Kconfig"
<apw> peat-psuwit_, i am not sure i know what gentree.py is for ?
<peat-psuwit_> apw: like, in this one: https://github.com/ubuntu-phonedations/backports
<peat-psuwit_> apw: I don't know what it's called.
<apw> hrm, you would have to talk to the phonedations lot, and i am struggling to find out where they hang out
<bdmurray> apw: Do you have an opinion on bug 1550719? My specific question is should usb-devices be in addition to lsusb or instead of?
<ubot5> bug 1550719 in apport (Ubuntu) "Add output of usb-devices when ubuntu-bug linux or apport-collect'ing existing report affecting linux (Ubuntu)" [Wishlist,Triaged] https://launchpad.net/bugs/1550719
<peat-psuwit_> apw: Ok, Thank you. I guessed they might be in #ubuntu-touch. I'll try to ask there.
<apw> peat-psuwit_, worth a shot indeed
<apw> bdmurray, if the upstream maintainers are complaining we have something missing in our bug reports it seems reasonable to add it, we're uploading a ton of stuff already i am sure it will not make the size any different; someone would want to check that file is password freee, bit i expect it to be so
<bdmurray> apw: okay
<apw> yeah reading the rest of the commentary it seems that this is not expected to have private info in it, so that sounds fine, i wonder if lsusb is any use with that attached, but one problem at a time :)
<leitao> rtg, replied to your comment. Thanks!
<rtg> leitao, I'm pretty sure we have not changed how the initrd is built, so I'm wondering if the tester actually installed both kernel packages.
<leitao> rtg, right. It might be a problem with the test. I will double check that
<leitao> Thanks
<leitao> rtg, yea. It seems that they wish to have something that never existed in 3.19, which means that this is NOT a regression. 
<rtg> leitao, I'm good with that :) I'm going to assume until otherwise notified that the bug is solved.
<jdstrand> jsalisbury: fyi, I left feedback for bug 1547619
<ubot5> bug 1547619 in linux (Ubuntu Xenial) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Medium,In progress] https://launchpad.net/bugs/1547619
<jsalisbury> jdstrand, ack, I'll take a look
<jdstrand> jsalisbury: thanks!
<jsalisbury> jdstrand, np.  sorry that we have to use the upstream kernel for testing.  
<rtg> jderose, could you open a new bug regarding ureadahead ?
<jderose> rtg: after looking into it more, i don't think there's an issue... the warnings about relative paths seem expected, even though there are a lot of them these days
<jderose> rtg: but if it seems like there is a new bug, i'll definitely file a bug :)
<rtg> jderose, I haven't looked in awhile. Is there actually valid ureadahead info being generated ?
<jderose> rtg: i'm not 100% sure about that, it's a bit hard to tell from the logging. currently my theory is valid entries are being generated, but that there are (for whatever reason) a lot more relative paths that are getting ignored during the scan
<rtg> jderose, I'll try to remember to have a look tomorrow.
<jderose> rtg: this caught my attention at first because there are so many ureadahead warnings in syslog, but maybe their expected, dunno
<rtg> jderose, I haven't touched it since Ubuntu was concerned about boot speeds (which has been a few releases)
<ngomes> hello , i have a question 
<apw> (just ask if you have a question)
<ngomes> as far as my understanding from linux,  the hardware devices are probed from the kernel in order to load apropriate driver. my question is : as far as hardware is probed , wouldn't it be faster to write to a file the hardware , than to always probe hardware every single boot ?
<xnox> ngomes, .... you are assuming kernel has a device to read a file from.
<ngomes> xnox, i know few about kernel , just wondering
<xnox> does not scale, cause hardware is different each time one boots, or even resumes from suspend/hybernation
<ngomes> how is different ?
<xnox> and it often needs to be re-initialised, in a device specific manner.
<ngomes> i dont see any load module when i resume from suspend
<ngomes> at least, at dmesg
<xnox> ngomes, usb devices attached/detached missing, firmware updates changing how hardware is seen, bios updates changing properties as to what sort of things stuff depends on.
<xnox> in bios a user can go and change which things are available/visible/enabled, etc.
<xnox> it really is a different world each time. And probing, and loading things on demand is often faster than disk-io reading caches =)
<ngomes> would give a load error, no problem ?
<ngomes> hmm ok
<ngomes> i really don't know how probe works , so yeah , overall might be faster
<xnox> ngomes, https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
<ngomes> that's ACPI , isnt that about power management ?
<xnox> before one can power things on and off, one needs to configure and find them....
<ngomes> xnox, so kernel talks AML to ACPI in order to gather info about the hardware components ?
<ngomes> ok, i get a better ideia
<ngomes> thanks for all
<ngomes> byebye
#ubuntu-kernel 2016-03-02
<rtg> sbeattie, re bug #1551894 - I'm building a test kernel with 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 applied. I'll post in the bug when its done.
<ubot5> bug 1551894 in linux (Ubuntu Xenial) "linux: 4.4.0-9.X fails yama ptrace restrictions tests" [Undecided,In progress] https://launchpad.net/bugs/1551894
<Odd_Bloke> apw: Don't know if you're around (and have a minute), but if you could check my working in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1551419/comments/8 to confirm that my reading of things is correct, it'd be much appreciated.
<ubot5> Launchpad bug 1551419 in linux (Ubuntu) "Fix UUID endianness patch breaks cloud-init on Azure" [Critical,Confirmed]
<Odd_Bloke> apw: (This is super-hot, because it breaks all Azure trusty instances on post-kernel-upgrade reboot)
<apw> Odd_Bloke, is that the one where cloud-init loses its mind and thinks scorched-earth on a clearly installed instance is a good idea 
<apw> Odd_Bloke, you sound convincing .... as this is stables, i recon we want bjf to chime in
<apw> Odd_Bloke, i assume we are going to also fix cloud-init to not juju the machine on reboot anyhow
<Odd_Bloke> apw: Yeah, I've asked bjf to chime in already; just wanted to make sure that I hadn't got the wrong end of the stick as soon as possible. :p
<Odd_Bloke> apw: The problem with fixing it in cloud-init is that we support using a snapshot of an instance as an image.
<Odd_Bloke> apw: Which means that distinguishing between 'first boot of a snapshotted image' and 'second boot of any image' is difficult.
<apw> but applying scortched earth should be something that snapshot has to tell you surely, else there is a high risk
<Odd_Bloke> apw: So each data source provides a way of uniquely identifying instances.
<apw> of exactly the kind of thing that occured here, an uninteded consequnce of another bug is "world ending"
<apw> which is _never_ acceptable, think of ps4.5
<apw> that'd be like newfs'ing / because i think it is blank
<apw> without being told it is really expected to be blank
<apw> Odd_Bloke, what i am saying is those snapshots should be marked, and it should ahve said "this is not a snapshot, but appears to have a different machine ID, this is utterly wrong, refusing to boot" not "yeah lets eat your machine"
<Odd_Bloke> Yeah, I've never been wild about supporting the snapshot-as-image-without-modification workflow.
<Odd_Bloke> So we should probably re-visit this.
<apw> i can see the convienience, i can also see the potential for disaster for all instances it creates
<apw> even if the original bug is a kernel one
<Odd_Bloke> Yeah, agreed.
<Odd_Bloke> We'll need to think about it, though, because I'm pretty sure changing this behaviour in trusty will break a lot of people; I expect that 'launch base image; perform customisation; snapshot' is the most common way that people produce derivative images, and they'd have to add a step in there.
<apw> Odd_Bloke, which series are affected by this, is it primarily trusty ?
<Odd_Bloke> apw: wily is fine, I haven't checked precise.
<Odd_Bloke> I will do so now.
<apw> great.  it being only one release makes life a heck of a lot less upsetting
<apw> Odd_Bloke, the problem with fixing this is anyone running a newly created image with -8 or indeed anyone affected and rebooted and zapped
<apw> Odd_Bloke, will  suffer the same problem again on update to the next version without the bug, right?  how are you going to mitigate that
<Odd_Bloke> Will my tears fix it?
<Odd_Bloke> :p
<apw> s/-8/the broken version/
<Odd_Bloke> So I was thinking about this yesterday.
<apw> i think we need a paired fix for cloud-init which knows how to reconstruct the machine id for the broken kernel version which is only applied on the broken kernle version
<Odd_Bloke> Yeah, that.
<Odd_Bloke> I _think_ it could happen in cloud-init's packaging, rather than in cloud-init itself.
<rtg> apw, is there a way to tell that the kernel is broken other then version number ? I was thinking about folks that try mainline crack, etc.
<apw> as we will need that anyway, and such a fix would immediatly mitigate the broken kernel version, and would let us confirm the fix and roll it out kernel side in a more leisurely manner
<apw> rtg, we might be able to say its "upstream x.y.z-cktN" which is fail perhaps
<apw> though i doubt there are a lot of mainline kernel crack runners in Vms
<Odd_Bloke> And we could make it work both ways: current_endian_version = $(cat /sys/...); reverse_endian_version = ...; if [ -d /var/lib/cloud/instances/$reverse_endian_version ]; then mv <that> <fixed path; fi
<apw> Odd_Bloke, as if we rush out the kernel change and its wrong again, we just have two wrogo's to mitigate.
<Odd_Bloke> Yeah.
<apw> Odd_Bloke, i also think we should be getting that out "now" regardless
<apw> if we are blowing people up
<apw> as we have to get that out before the fixed kernel can go out safely too
<rtg> apw, "that" being the cloud_init fix ?
<rtg> and how do we fix the kernel besides reverting the endian patch ?
<apw> rtg, yes if we don't mitigate the broken kernel, then updating the kernle to fixed will re-blow up the instances and zap them a second time
<apw> rtg, so we have to mitigate that by fixing cloud-init, and that has to occur sooner than the kernel
<rtg> agreed
<Odd_Bloke> We also have to handle this in case Azure decide to upgrade their reported SMBIOS version to >=2.6 (probably without changing the endian-ness of what they report).
<apw> Odd_Bloke: so we shoulf add a cloud-init task to the bug and cordinate thay getting out before the kernel
<Odd_Bloke> apw: Yep, task already added and I'm looking in to it.
<apw> are you on the hook for that?
<Odd_Bloke> apw: I think so.
<apw> ok good, that makes it make sense to try ans get this fix into the next upload but not expedite it out
<apw> bjf
<apw> bjf: fyi discussion above
<apw> Odd_Bloke: did you say we might be able to detect the mallformed version? rather than thinking in terms of kernel versions? in your code fragment above. that would be safer for aure
<apw> ahh yes you are saying that, good
<Odd_Bloke> apw: Yeah, so my plan is to assume that if cloud-init currently has an instance id of "11223344-5566-7788-DEAD-BEEFDEADBEEF" and it now thinks it should have "44332211-6655-8877-DEAD-BEEFDEADBEEF" then we assume it's the same system.
<apw> doesmthat account for the shift as well?
<apw> but i think the plan is sound
<Odd_Bloke> apw: "the shift"?
<Odd_Bloke> (There is a remote possiblity that this could produce false positives, but (I think) only on a snapshotted image which was then launched with a UUID that appeared exactly oppositely-endian in its first three fields)
<Odd_Bloke> But that's unlikely to happen before the heat death of the universe. :p
<ruchlos> never underestimate the mind of a computer that wants to punish humans to trigger such unlikely scenarios ;)
<Odd_Bloke> Ah, hmph, doing this in cloud-init packaging would mean it would only work once per cloud-init version.
<Odd_Bloke> So I do need to do it in cloud-init proper.
<Odd_Bloke> On the bright side, I won't have to work out to reverse endian-ness of parts of a UUID in shell. :p
<apw> heh
<apw> Odd_Bloke, you are able to test a kernel for us I assume to confirm a fix ...
<Odd_Bloke> apw: Yep.
<xnox> hello =)
<xnox> apw, got a fresh bug for udebs
<xnox> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1552314
<ubot5> Launchpad bug 1552314 in linux (Ubuntu) "[s390x] zfcp.ko missing from scsi-modules udeb" [Medium,Confirmed]
<xnox> apw, just what you wanted to hear right? =))))) enough info to fix it?
<rtg> xnox, it'll do
<xnox> rtg, tah.
#ubuntu-kernel 2016-03-03
<tseliot> rtg: hi, I recovered all the commits from my original branch but now master-next fails to build (not my fault). Shall I base my branche on master?
<tseliot> *branch
<rtg> depends on what is failing to compile I guess. Is it in your pile or mine ?
<tseliot> rtg: drivers/scsi/qla2xxx/tcm_qla2xxx.c:466:12: error: 'TARGET_SCF_USE_CPUID' undeclared (first use in this function)
<tseliot> that's not mine
<rtg> tseliot, ok, thats mine. base on master-next and I'll figure it out.
<apw> man i really wanted that pile to get its own upload
<tseliot> rtg: ok, but I'm going to use master for testing, just to be sure
<rtg> tseliot, thats fine. the stuff already on master-next is completely unrelated
<tseliot> rtg: ok, good
<rtg> tseliot, fixed the compile failure
<tseliot> rtg: great, I'll rebase on that, thanks!
<rtg> tseither one is fine
<rtg> tseliot, either branch is fine
<tseliot> rtg: and by either you mean master-next and...?
<rtg> tseliot, master or master-next
<tseliot> rtg: ok, I just wanted to be sure
<tseliot> master builds. Building master-next now
<rtg> tseliot, I'm happy with master. just send the updated pull request.
<tseliot> rtg: a pull request of my master-based branch into master or into master-next?
<rtg> tseliot, doesn't matter. whatever you currently have is fine
<tseliot> ok
<rtg> there isn't enough difference between master and master-next at this point to mamke a difference
<tseliot> true
<tseliot> rtg: ok, pull request sent. The kernel works well here
<rtg> tseliot, ack
<jdstrand_> jsalisbury: hey, fyi my comments in bug #1547619. I can summarize though, the new xenial kernel in the archive has the bug, and the url you gave in you last comment has kernels I previously tested
<ubot5> bug 1547619 in linux (Ubuntu Xenial) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Medium,In progress] https://launchpad.net/bugs/1547619
<tseliot> rtg: here is the upstream pull request that includes the only non-upstream patch in my branch https://lists.freedesktop.org/archives/dri-devel/2016-March/102119.html (just in case)
<rtg> tseliot, ack, thanks
<jsalisbury> jdstrand, ack, let met make sure I uploaded the right kernel
<jsalisbury> jdstrand, I must have copied it to the wrong place.  I'm just going to rebuild the kernel, so we're confident it's the right one.
<jdstrand> thanks
<jsalisbury> jdstrand, I rebuilt that kernel and re-posted it: http://kernel.ubuntu.com/~jsalisbury/lp1547619
<Hell-Razor> hey fellas... anybody good with patching kernels? I have been trying to get this patch working for an hour probably with no luck. i downloaded it from sorceforge (reiser4) trying to patch 4.4
<jdstrand> jsalisbury: thanks
<jtaylor> hi, you updated the megaraid driver in the 4.4 kernel right?
<jtaylor> bug 1544679
<ubot5> bug 1544679 in linux (Ubuntu Xenial) "Request to merge upstream fixes into 16.04 for megaraid driver" [Medium,Fix released] https://launchpad.net/bugs/1544679
<jtaylor> because my machine is not booting anymore due to some issue with it
<jtaylor> someone interested in debugging? then I could go get a picture of the error ._.
<apw> jtaylor, yep, if its blowing up, anything you can get ... file a new bug against linux and reference the update above and include the piccy
<apw> jtaylor, and ... let us know the bug# here
<jtaylor> apw: do you know if there have been updates to this driver since 4.2?
<jtaylor> I haven't tested the 4.4 before the thing mentioned in the changelog
<jtaylor> but 4.2 works
<jtaylor> I'll file a bug
<apw> jtaylor, i do not, i just recall that bug going past ...
<apw> yes please, and note hte bug# here please, so we can get some attnetion on it, so we can determine if it is that update
<apw> we should be able to offer you an old 4.4 build from just before it
<jtaylor> apw: I have been using the recently uploaded lts-xenial build
<jtaylor> thats ok to file a bug from?
<apw> sure, its the same bits inside
<jtaylor> file against linux or the lts source package?
<apw> file it against the lts if you are running that, in case it is an interaction with userspace that triggers it
<apw> and i can add a task for linux too as it is more likley general and affects both
<jtaylor> the root is on the raid so it shouldn't be using userspace before it fails
<jtaylor> ok starting to file it now
<jtaylor> apw: bug 1552903
<ubot5> bug 1552903 in linux-lts-xenial (Ubuntu) "fails to boot on megaraid" [Undecided,New] https://launchpad.net/bugs/1552903
<jtaylor> ups should have probably shrunk the image a little in size ..
<apw> jtaylor, thats fine, could you also grab a dmesg from the latest kernel which worked for you
<apw> and indicate that in the bug
<jtaylor> sure
<jtaylor> apw: done
<apw> jtaylor, passed it on to rtg as he did the update ... thanks for reporting
<jtaylor> thanks, I'll can probably do some testing tomorrow or next week in evenings
<rtg> jtaylor, I'll pass on your bug to the Canonical project manager that deals with these guys. The update request was in bug #1544679.
<ubot5> bug 1544679 in linux (Ubuntu Xenial) "Request to merge upstream fixes into 16.04 for megaraid driver" [Medium,Fix released] https://launchpad.net/bugs/1544679
<cristian_c> jsalisbury: hi
#ubuntu-kernel 2016-03-04
<DalekSec> apw: Any luck looking at the new cryptsetup?  If it helps, I did a merge for myself end of last month.
<DalekSec> https://sigma.unit193.net/source/cryptsetup_1.7.1-0ubuntu1.dsc
<tjaalton> apw: do you have initramfs-tools in git somewhere? bug 1500751 needs fixing
<ubot5> bug 1500751 in initramfs-tools (Ubuntu) "Cryptsetup Keyboard not working on Xubuntu 3.19.0-30" [High,In progress] https://launchpad.net/bugs/1500751
<tjaalton> then again it's not out of proposed yet
<tjaalton> should it still be blocked by https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1548120 ?
<ubot5> Launchpad bug 1548120 in initramfs-tools (Ubuntu) "[xenial][initramfs-tools] support uppercase and lowercase uuids" [High,New]
<apw> tjaalton, almost cirtainly not be blocked ... checking
<tjaalton> it broke something for ntfs mounts
<tjaalton> but that was not the reason for the tag
<apw> tjaalton, oh poo ... ok ... so that needs fixing too
<apw> tjaalton, do you have a fix in hand for your problem, if so if you email it to me now
<tjaalton> I do
<apw> tjaalton, i'll fix this uuid thing again, and apply yours at the same itme
<tjaalton> https://launchpadlibrarian.net/223637474/debdiff-vivid
<apw> (as yes it is in git)
<apw> tjaalton, thanks ...
<apw> grrr
<tjaalton> this still works, sans changelog
<tjaalton> yeah this fell through the cracks, and now vivid is eol. trusty would need this too, but it's also still in proposed waiting for testing
<apw> ack
<xnox> ah, i'm not the only one
<xnox> bug 1500751 =)
<ubot5> bug 1500751 in initramfs-tools (Ubuntu) "Cryptsetup Keyboard not working on Xubuntu 3.19.0-30" [High,In progress] https://launchpad.net/bugs/1500751
<xnox> i have this optimus things, with nvidia & intel graphics. Is there a known good way to force intel graphics only, in plymouth and elsewhere?
<xnox> my input is all weird with latest kernel -> plymouth is shown, yet i "type" at top left corner, and not into "plymouth" as if plymouth doesn't have focus.
<apw> tjaalton, ok ... i've applied your fix and what i hope is the fix for the other issue, and uploaded to ppa:apw/ubuntu/initramfs-tools-test
<apw> xnox, plymouth not having focus iirc is often when plymouth has rejected all the graphics displays as non-primary
<apw> so it doesn't open the terminal, so the underlying vt reads and echos
<xnox> ack.
<xnox> apw, i'm suspecting the kernel/plymouth might have started to either use noveau instead of intel graphics, or noveaue graphics (with plymouth) got broken
<apw> manjo, it seems your UUID fix is blowing up NTFS installs, i've uploaded a "only apply this to rfc4122 format uuids" fix to ppa:apw/ubuntu/initramfs-tools-test, could you verify that still fixes youpls.
<xnox> i've blacklisted noveaue, purged noveaue xserver packages, booted without splash (to unlock the drive) and have desktop now (previously lightdm would work, unity/gnome-shell/plymouth crash/not-work)
<apw> sounds like you are having fun, i don't know what wally thought switchable graphics was ever a good idea architecturally
<tjaalton> xnox: is this a skylake laptop?
<xnox> yes.
<tjaalton> so you need that new initramfs-tools
<apw> xnox, ahh that should be in ppa:apw/ubuntu/initramfs-tools-test
<tjaalton> because otherwise initrd doesn't come with i915_bpo
<apw> ubuntu2~rc1
<tjaalton> oh I missed the backlog
<tjaalton> so yeah
<apw> tjaalton, oh i wasn't asking him to test it :)  i was just asking you and manjo :)
<apw> if he can test too ... yay
<apw> xnox, make sure you have an old kernel and initramfs :)
<xnox> apw, i'm using a spare machine =) that seems to work.
<apw> the initramfs-tools fixes you ?
<xnox> apw, did i hear that right, that i shall dist-upgrade and everything will work.
<xnox> apw, i've booted the laptop by hand, without splash and not shutting it down now =)
<apw> without any risk of explosion, yes i definatly said that :)
<tjaalton> it might also unbreak your nouveau
<xnox> wheere can i get the magical ubuntu2~rc1?
<apw> xnox, ahh that should be in ppa:apw/ubuntu/initramfs-tools-test
<apw> ubuntu6~rc1
<xnox> i ponder to just cowboy in the hooks/framebuffer thing
<xnox> cause i don't want to enable that ppa, will forget about it.
<xnox> apw, the copy_modules_dir of ubuntu/i915 is kosher.
<apw> xnox, as long as it fixes you :)
<apw> xnox, i tend to enable the ppa, instlal the pckage, and then remove it immediatly
<apw> i always version before the archive in there
<manjo> apw, sure will do today
<apw> manjo, thanks ... hopefully that one will work for everyone and can actually go out
<manjo> apw, thanks a ton .. will test do you have a bug number I can report back to ? 
<apw> bug: #1553107
<ubot5> bug 1553107 in initramfs-tools (Ubuntu) "initramfs-tools: UUID checks now fail for NTFS which has upper cases UUIDS" [Critical,In progress] https://launchpad.net/bugs/1553107
<apw> manjo, ^
<manjo> apw, awesome .. we are in a critsit with one of our friends today.. but I will definitely find time to test that for you and report back in that bug 
<lamont> apw: (or anyone) in trusty and later, which, if any, filesystems still report 1-second granularity timestamps?
<apw> lamont, hmmm, fat perhaps
<apw> those kinds of places, not sure you'd keep dns things one one of those
<apw> i'dbe slightly suspicious of samba mounts, and would suggest checking nfs
<lamont> apw: let me reprhase that - places where even the most insane user/admin might put /etc
<apw> but ... they should all just return 0 in that
<apw> they should still return valid times in the calls which support ns numbers though right ?
<apw> so ... do you care ?
<lamont> fat is so broken in so many ways for that, making it not a consideration
<lamont> https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1553176
<ubot5> Launchpad bug 1553176 in bind9 (Ubuntu) "BIND ignores nanoseconds field in timestamps, fails to load newer versions of zones on reload" [High,Confirmed]
<apw> lamont, right but if you take them into account (the ns) tey should be valid and always 0 or something on older broken filesystems
<lamont> and a related "maas does crazy things trying to work around 1-sec granularity" issue - I'm looking at "do I push to fix this in trusty, or not.
<lamont> apw: true, making them either "still broken" or "fixed?"
<lamont> s/?//
<lamont> newly-broken being the one I really want to avoid
<apw> well i think your contention that all sane underlying things would support <1s granularity
<apw> i beleive if they are using something without, they already are broken, so makign it take ns into account won't make them any worse i odn't think
<lamont> and no architecture where the patch in that bug would be bad?  (given that bind9 made it into xenial with that fix, it at least compiles, so nevermind that question
<lamont> cogent argument.  thanks for the clarifying conversation
<apw> do bear in mind just because the FS reports ns timestamps in its stat info
<apw> that does not make the granulatity ns, it may well jump in multiple ms
<apw> so i am not sure you can be confident of avoiding your issue if you keep updating the file at line speed
<apw> lamont, ^
<smb> line or light...
<apw> all of the above :)  "very quickly" might be less than the fs granulairity regardless of the stat result maximum granularity
<apw> though it would be easy enough for maas to stat the file, update it, stat it again, if the timestamps match, touch it again until its not
<smb> yeah, true indeed
<lamont> oh, that's fine
<lamont> we take lots longer than that to acutally write the file
<apw> and guarentee we never hit that issue
<apw> or ... you could fix bind so when you ask it to reload, it does regardless of the timestamps
<apw> because you know you asked it to
<lamont> http://paste.ubuntu.com/15276110/ <-- from the headscratching yesterday finding the bug
<apw> and it seems rude for it to say, naaa you are a tool the file is the same date i hate you
<apw> all of the above :)  "very quickly" might be less than the fs granulairity regardless of the stat result maximum granularity
<apw> damn you paste
<smb> apw, nah you cannot make "tools" useful... :-P
<apw> lamont, it is actually unreasonable for bind9 to be sent an _explicit_ reload and for it to say "nope i know better"
<apw> why would you send it a reload if you didn't want it to like actually reload
<lamont> if you send it a bunch of reloads for 1 zone, there's no reason it can't combine them into one load
<lamont> it's specifically code that was added to help named installs with thousands of zones survive the admin saying "rndc reload"
<lamont> the process goes: update zone file (atomically...), run rndc reload $ZONE, bind9 wakes up, processes zonefile, remembers when that happened
<lamont> so there's definitely some lag between the zone getting written and bind9 serving new data
<lamont> and yeah, milliseconds is fine
<apw> lamont, so why is it not checking the inode and device numbers as well as the time
<lamont> also, I'm fine with adding code down the road that says "while (timestamp hasn't changed) {write the *(^)*&*& file;}"
<apw> as to make an atomic update you necesarily need to change the file, ie the inode number on the device
<lamont> because we hate veryone
<apw> if bind9 did that, we'd avoid this completely
<lamont> true.  that will go in the bug report to upstream
<lamont> but it's invasive enough of a change that I'd rather just go lalalalaalalala and ignore it for now
<apw> surely the bit which adds ns check is the identicle bit we'd want to keep the inode number, but hey
<smb> apw, though then bind9 has bigger issues right now than to worry about timestamps
<smb> or rather not bind9 but poor tools trying to use its libraries... :-P
<apw> heh
<lamont> smb: adding back in the -export libs is inplan for this weekend (mgilbert is working on that, and worst case, I'll work on it early next week)
 * lamont has a flight to kill time on monday evening
<smb> lamont, Yeah, I know. And thanks for that.
<smb> lamont, Just seriously felt like needing a shower after having been up to my throat in user-space code... ;)
<apw> smb, :)
<lamont> smb: heh
<manjo> apw, initramfs tools is in your test PPA correct ? 
<manjo> apw, https://launchpad.net/~apw/+archive/ubuntu/initramfs-tools
<manjo> apw, $ apt-cache policy initramfs-tools
<manjo> initramfs-tools:
<manjo>   Installed: 0.122ubuntu5~rc2
<manjo>   Candidate: 0.122ubuntu5~rc2
<manjo>   Version table:
<manjo>  *** 0.122ubuntu5~rc2 100
<manjo>         100 /var/lib/dpkg/status
<manjo>      0.122ubuntu3 500
<manjo>         500 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 Packages
<manjo>      0.122ubuntu1~rc4 500
<manjo>         500 http://ppa.launchpad.net/apw/initramfs-tools/ubuntu xenial/main arm64 Packages
<manjo> apw, are you missing arm64 ? 
<cristian_c> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imgur.com/ !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<manjo> apw, or is it the version in proposed ? 0.122ubuntu5 500
<manjo>         500 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 Packages
<manjo> apw, it is no clear to me that proposed have any changes for NTFS .. can you please tell me which PPA / archive the new initramfs tools is in ?
<apw> manjo: i thpught i turned arm64 on on that ppa
<apw> manjo: oh initramfs-tool-test, note the -test
<manjo> apw, it is working .. I will update the bug 
<manjo> apw, testing upper case now 
<apw> manjo, great thanks
<manjo> apw, wait .. upper case does not wrok
<apw> hrm, what format is the thing, can you paste it for me
<manjo> yes
<manjo> I was going to update that bug ... but I can paste here
<apw> ta
<apw> do update the bug too pls
 * apw drumbs his fingers
<manjo> root=PARTUUID=7c5978e5-a56f-4c4c-a3f1-de1467d0b602 (lower case) works
<manjo> root=PARTUUID=7C5978E5-A56F-4C4C-A3F1-DE1467D0B602 (upper case) does not work.
 * manjo is sorry .. did not realize this would turn into such a cluster 
<apw> manjo, meh, we'll get there, i was over zelous applying it to everything, and underzelous applying it to anything now it seems :)
<apw> manjo, oh blech ... i see whats going on ... boo
<manjo> thing do with the 5 digits / 
<manjo> ? 
<apw> manjo, no just not thinking when writing the code, i was losing the DEV when checking it ... so i've just uploaded a ~rc2 ... should be built in about 20m
<manjo> ok sure I can test that 
<manjo> apw, drinking and typing on Friday evening ... s**t happens 
<apw> manjo, heh i did that this morning, so no excuses
<manjo> apw, âº beer fixes sober coding errors .. works either way ..  
<apw> heh i wish i was drinking, but i am not
<manjo> apw, heh I hear ya .. I could use a strong drink right now ... s**t blowing up on my face all day
#ubuntu-kernel 2016-03-06
<simcha> Hi I was testing sth with mainline kernel 4.5-r6 and realised that it is missing aufs driver needed by docker in default configuration. Where shall I file the bug if any?
<jtaylor> simcha: mainline kernels don't have aufs
<jtaylor> its a ubuntu specific addition
<jtaylor> so if you want to file a bug it needs to be against upstream linux
#ubuntu-kernel 2017-02-27
<rellis> Hello all. I'm trying to use the linux-aws package provided by the Ubuntu kernel team to get a newer version of the ixgbevf driver. However after I install the package I'm still seeing the old 2.12.1-k driver version. Any ideas what I'm doing wrong? or am I misunderstanding the release notes talking about a newer version of this driver?
<ogasawara> rellis: ah, sorry, that's expected right now as we were seeing issues with the newer version of the driver.  We're working on getting that sorted asap to provide a newer driver again.
<rellis> ogasawarasa: Thank you for the response. I was able to install the LTS enablement kernel to get version 3.2.2-k
<rellis> which I hope won't be fubar :)
<rellis> although i would like to be able to use linux-aws
<ogasawara> rellis: cool, that should work for you.  Any feedback you have on the 3.2.2 version of that driver from the LTS enablement kernel would be great.
<rellis> ogasawara: Would you just like feedback in this channel? or is there a ticket or anything?
<ogasawara> rellis: I'll try to remember to ping you when we have linux-aws with an updated ixgbevf
<rellis> thanks
<ogasawara> rellis: informal feedback in this channel is fine
<rellis> cool
<kamal> rellis, I think I'm about to make you very happy ...  :-)   https://launchpad.net/~kamalmostafa/+archive/ubuntu/test-linux-aws/+packages
<rellis> oh you rock sir
<rellis> i was just updating the chef recipe to go install the hwe kernel too :)
<kamal> rellis, that includes an update to ixgbevf to 3.2.2-k, which I'm testing in preparation for merging into linux-aws.  your feedback on that exact build would be most appreciated
<rellis> i will definitely do that
<rellis> kamal: So strange, after I add your ppa apt search linux-aws shows the new 1006 rev of all the dependant packages but not the linux-aws meta package itself
<kamal> rellis, oh, I should have warned you (sorry!) ... there is no 1006 meta package (yet), so you have to install the linux-image-xxxxx.deb specifically
<rellis> ahhh i see
<rellis> thanks!
<kamal> rellis, try "sudo apt-get install linux-image-4.4.0-1006-aws"
<rellis> well im doing this from chef, but i will attempt give or take the same thing
<kamal> rellis, y'know what?  I'll just construct and upload a 1006 meta pkg to that PPA.
<rellis> that's very nice of you :)
<kamal> rellis, ok, that's building now, in my test-linux-aws PPA -- should be available within the hour, maybe much sooner
<rellis> cool, thanks much!
<kamal> rellis, sure, and thanks in advance for your feedback
<rellis> well that build was nice and fast
<kamal> rellis, yup, I guess "much sooner" was right
<rellis> indeed
<kamal> rellis, and it looks like it works properly ... let me know if you have any more trouble with it.
<rellis> i will, im installing it now
#ubuntu-kernel 2017-03-01
<WeiJunLi> how can i see what ioctl commands calls a specific function?
#ubuntu-kernel 2017-03-02
<rbasak> Could someone please take a look at my comments in bug 1648143? I tried to verify the fix, but found that it's fixed in Xenial (but seems to have been released before verification), still broken in Yakkety (but already released before verification) and still broken in Zesty. Not sure how to triage it.
<ubot5> bug 1648143 in linux (Ubuntu Yakkety) "tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_<var-lib-lxd>" profile="unconfined" name="system_tor"" [Undecided,Confirmed] https://launchpad.net/bugs/1648143
<rtg> jjohansen, ^^
<hallyn> where does one sign up for livepatch?
<mdeslaur> hallyn: https://www.ubuntu.com/server/livepatch
<hallyn> thx!
<hallyn> oh noes - i need snap? :)
<hallyn> oh-double-noes - and snap requires systemd?
<hallyn> ok good enough for my server, not my laptop.  i can live with that - thx :)
<jjohansen> rtg: thanks, I'll take a look at it
<shubjero> Hi all. I was updating a bunch of servers kernel's for Ubuntu Trusty and noticed that a slew of them received 3.13.0-111, but the rest received 3.13.0-110. Did someone push -111 to the repository before it was supposed to be pushed?
<shubjero> I now have about 100 servers running -111
<shubjero> and 25 running -110
<rtg> infinity, apw ^^
<infinity> shubjero: Yeah, -111 was accidentally released and reverted.  It should be mostly harmless.  Hopefully.  But if you're paranoid, rebooting those into -110 would not be a crazy option.
<infinity> -111 (or possibly a -112) will release properly in a week or so.
<infinity> shubjero: Anyhow, if they're happy on -111, I wouldn't worry about it.  We accidentally released if before our testing was done, but there aren't any known issues with it either.
<shubjero> thanks for your feedback infinity 
<shubjero> we're a research organization so running 111 isnt a big deal. if we have issues we can do an emergency maintenance to install -110
<apw> shubjero, we'd be interested in knowing if you have to revert and why
<shubjero> apw: yeah if i have any issues ill be sure to come visit here and let everyone know
<shubjero> or i may throw a post on the ubuntu mailing list
<shubjero> either way 
<shubjero> im sure we'll be fine
<hallyn> has anyone here followed the bus1 progress?  It seems to be an out of tree module now - is it slated to go upstream at some point?
<stgraber> FYI we're getting panics every few minutes on our Jenkins test runners ever since we upgraded to the latest 16.04 kernel (4.4.0-65)
<stgraber> trying to get those systems setup in a way that we can actually see said panic rather than just have them drop from the network and not print anything...
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1669611 filed as critical SRU regression with traces from 4 different systems
<ubot5> Ubuntu bug 1669611 in linux (Ubuntu) "Regression in 4.4.0-65-generic causes very frequent system crashes" [Critical,Triaged]
<stgraber> bjf: ^
<bjf> jsalisbury, ^ can you jump on that
<stgraber> I'm moving all those test runners to the zesty 4.10 now, we'll see if it's affected too or not
<bjf> jjohansen, you might take a look at ^ there are a bunch of __aa_fs_* symbols in the call trace (in case that's apparmor)
<stgraber> yeah, I pinged him in #security when I saw the aa stuff in there
<jsalisbury> bjf, ack
#ubuntu-kernel 2017-03-03
<jjohansen> bjf: yeah looking
<jsalisbury> bjf, jjohansen, this one sticks out from a quick look: 
<jsalisbury> d6d69ebc5b3f UBUNTU: SAUCE: apparmor: Fix no_new_privs blocking change_onexec when using stacked namespaces
<jjohansen> jsalisbury: well thats a big nasty one but by the call trace it actually looks more likely to do with
<jjohansen>   UBUNTU: SAUCE: apparmor: fix lock ordering for mkdir
<jjohansen> or
<jjohansen>   UBUNTU: SAUCE: apparmor: fix leak on securityfs pin count
<jjohansen> or
<jjohansen>   UBUNTU: SAUCE: apparmor: fix reference count leak when securityfs_setup_d_inode() fails
<jjohansen> or
<jjohansen>   UBUNTU: SAUCE: apparmor: fix not handling error case when securityfs_pin_fs() fails
<jsalisbury> ugg
<JokesOnYou77> Hi all
<JokesOnYou77> I'm trying to understand the difference between the *-edge kernels and those that don't have that designation.  Based on https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack I thought the *-edge kernels should be newer, but from what I can see in pat it looks like linux-generic-hwe-16.04 is 4.8.0.39.10 while *-edge is 4.8.0.34.6
<apw> JokesOnYou77, -edge is typically newer, the whole -hwe -hwe-edge is new and we're just getting -edge rebased to 4.10 atm
<JokesOnYou77> apw: Thanks!  I'll go with the regular one for now and see if it fixes my issues.
#ubuntu-kernel 2017-03-05
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<chu> @mark chatter29
#ubuntu-kernel 2018-02-26
<kees__> bionic's linux-image-4.15.0-10-generic doesn't have any /lib/firmware/* files, is this intentional or a bug? And where could i get those files?
<PaulePanter> Hi. 4.16-rc3 is missing at http://kernel.ubuntu.com/~kernel-ppa/mainline/.
<PaulePanter> https://lkml.org/lkml/2018/2/25/280
<ricotz> kees__, install linux-firmware (which should be there by default though)
<ricotz> PaulePanter, I would say, wait a few more hours ;)
<kees__> ricotz, it is installed, but (for example) 4.13.x has version-specific firmware files in /lib/firmware/4.13.xx (like bnx2 firmware), and those are missing from 4.15.xx
<PaulePanter> ricotz: It was quite fast in the past. First time, itâs not there, when I check.
<PaulePanter> Iâd say, something wrong. Would be nice to have a way to check myself how far the builds went.
<PaulePanter> *where the builds are at.
<ricotz> kees__, I see, I am familiar with that, sorry
<ricotz> PaulePanter, just saying it is just 5 hours since it has been tagged
<ricotz> kees__, oops, of course "not familiar"
<PaulePanter> ricotz: Right, but five ours on decent servers are a long time to build ten Linux kernels.
<ricotz> not if the launchpad builders having some troubles and needing to be poked regularly, not sure where those mainline kernels are built though
<PaulePanter> ricotz: Understood. One more reason to document it, or make that information easy to access.
<apw> PaulePanter, yep we have some infrastructure down apparently so it has not yet been built
<PaulePanter> apw: Thank you for the confirmation.
<Tomazzu> any chance get kernel update for avermedia h323 dvb-pci-card ?
<kees> 15:02 -!- kees__ [~kees@devvers.tweaknet.net] has quit [Remote host closed the connection]
<kees> well that was a confusing nick that wasn't me! :P
<Moral_> lol
#ubuntu-kernel 2018-02-27
<TJ-> I've been working with a user who has multiple DVB adapters in a system (12) and it breaks since 4 of them cannot be configured due to DVB_MAX_ADAPTERS=8 in .config. Is it worth opening a bug and requesting that value be increased (since there is no dynamic way) - would it be considered for increase in the immediate future?
<jdstrand> jjohansen: who would be the right person to talk to about add kernel tasks for https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1746463/comments/6?
<ubot5`> Ubuntu bug 1746463 in snapd "apparmor profile load in stacked policy container fails" [Undecided,Triaged]
<jdstrand> sorry
<jdstrand> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1746463/comments/7
<jjohansen> jdstrand: I can do that
<jdstrand> jjohansen: k. I just looked for 4.13 based kernels and listed them
<jdstrand> jjohansen: thanks!
<jjohansen> jdstrand: well maybe not, lp keeps oopsing on me
<jjohansen> :)
<jjohansen> I'll give it a bit and try again later
<PsyRabbit> Hello, is someone here who knows some iSCSI target internals? LIO/TCM... I just want to know if there is a way to have multiple threads to handle the IO to VFS <-> elevator? I dont see any multithread implementation in iscsi_target_core.h
#ubuntu-kernel 2018-02-28
<thresh> having something weird on an AMD Ryzen machine on the linux-hwe in 16.04: http://thre.sh/stuff/ryzen-ubuntu.png
<thresh> any idea what could that be?
<thresh> machine is offline, but that image is updating every few seconds with different addresses
<thresh> as offline I mean networking does not work
<Snicksie> that is a kernel panic
<Snicksie> just reboot
<thresh> sure.  it happened for a second time in a day.
<thresh> I was wondering if something similar was reported already.
<Snicksie> in that case check out journalctl to get the full log
<Snicksie> with this image there's not much to report
<thresh> nothing related
<Snicksie>  nothing in /var/log/syslog either?
<Snicksie> or kern.log
<thresh> nope
<thresh> setting up netconsole now, maybe it'll have something next time
<thresh> ok, set it up.  let's wait for the next crash.
<thresh> those Ryzen machines are soooo unstable it's not funny.
<thresh> this looks very related: https://utcc.utoronto.ca/~cks/space/blog/linux/RyzenMachineLinuxHangs
<thresh> and this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085
<ubot5`> Ubuntu bug 1690085 in linux (Ubuntu) "Ryzen 1800X freeze - rcu_sched detected stalls on CPUs/tasks" [High,Confirmed]
<Fjodor> any news on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749015 ?
<ubot5`> Ubuntu bug 1749015 in linux (Ubuntu Bionic) "4.16 - VBOXGUEST not built" [Medium,Triaged]
#ubuntu-kernel 2018-03-01
<LocutusOfBorg> hello apw sforshee which vbox driver are you using nowadays? 5.2.8 is out, should I ping you or you will take the one mainline?
 * LocutusOfBorg hopes for the latter
<LocutusOfBorg> apw, ping :)
<LocutusOfBorg> BTW virtualbox is "regressed" because some new tests see that the built kernel and the one in Ubuntu differ... obviously
<apw> yep, dkms is a pile of crap, it has no idea how to compare versions if there is not a manual version
<LocutusOfBorg> apw, second question, are you using vbox mainline kernel drivers? 
<apw> we are still at .26 i think, and i believe not using those, because the only one which existed at the time was blowin up
<apw> but i would have to defer to sforshee for accurate memory on that 
<LocutusOfBorg> please delete it, and switch to the mainline version :)
<apw> mainline only provides one of them at 4.15 level right ?
<LocutusOfBorg> no, even 4.14 IIRC
<ricotz> hi, is bionic getting 4.16 after all?
<sforshee> LocutusOfBorg: bionic currently has version 5.2.6-dfsg-5, we are using the in-tree vboxvideo driver which I believe is the only one that exists in 4.15
<sforshee> once the 5.2.8 package promotes I can update to that
<LocutusOfBorg> sforshee, sorry, I mean, don't use the vboxvideo from vbox, but use the one inside the kernel source tree
<LocutusOfBorg> it is now fixed
<LocutusOfBorg> git tag --contains ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6
<LocutusOfBorg> v4.15
<LocutusOfBorg> since 4.15~rc1
<sforshee> LocutusOfBorg: yes, that's what I meant by "using the in-tree" driver. We've been using that in-kernel one rather than the one we import from vbox-guest-dkms for a while now
<LocutusOfBorg> I don't get this: [14:06:00] <sforshee> once the 5.2.8 package promotes I can update to that
<LocutusOfBorg> I mean: please continue to use the in-tree one then
<sforshee> LocutusOfBorg: we still import the vbox-guest-dkms drivers but disable the vboxvideo one from there
<LocutusOfBorg> oh... ok, I don't see the need, but fine
<sforshee> it provides other functions than the video doesn't it?
<sforshee> otherwise maybe we don't need to do that anymore
<LocutusOfBorg> vboxsf and so on...
<LocutusOfBorg> ok
<LocutusOfBorg> just disable vboxvideo from there then
<sforshee> yeah, our import script does that automatically now
<LocutusOfBorg> ack
<LocutusOfBorg> unfortunately such drivers might have a bug
<LocutusOfBorg> KERNEL=="vboxguest", NAME="vboxguest", OWNER="root", MODE="0660"
<LocutusOfBorg> KERNEL=="vboxuser", NAME="vboxuser", OWNER="root", MODE="0666"
<apw> (see truth you need sforshee :)
<LocutusOfBorg> this is the content of: debian/virtualbox-guest-dkms.udev
<LocutusOfBorg> anyhow, it is fine to grab even 5.2.8 right now, but I don't think there are updates there
<sforshee> LocutusOfBorg: hmm, so you're saying without those udev rules having those drivers in the kernel may not provide any benefit?
<sforshee> I mean, if you think there's no benefit in having them shipped with the kernel now we should talk about removing them
<sforshee> would save me some effort at minimum ;-)
<sforshee> I'm unfamiliar with the history of why we started shipping them in the kernel packages anyhow
<LocutusOfBorg> I didn't receive any complain about them, so maybe they are fixed now, and I should remove the udev rule too
<LocutusOfBorg> unfortunately it has been added too many years ago
<LocutusOfBorg> so, I prefer to "don't touch if it isn't broken"
<LocutusOfBorg> BTW please grab 5.2.8, the difference with 5.2.6 is *only* kernel 4.15 fixes, so, before trying to fix, update the tarball :)
<sforshee> ack, will update
<LocutusOfBorg> (I'm about to send a diff)
<LocutusOfBorg> https://paste.ubuntu.com/p/WnZgVw7h5C/
<LocutusOfBorg> there is a new timer function, probably some fixes in timer syncronization host/guest
<LocutusOfBorg> and the most important thing is a new structure
<LocutusOfBorg> + * Intel PCID invalidation types.
<LocutusOfBorg> (I presume, because upstream refuses to release CVE patches), it has something to do with spectre/meltdown
<LocutusOfBorg> +    /* Clear bits which we don't pass through for security reasons. */
<LocutusOfBorg> +    pDst->Attr.fMode       &= ~(RTFS_UNIX_ISUID | RTFS_UNIX_ISGID | RTFS_UNIX_ISTXT);
<LocutusOfBorg> apw, can you please update the vbox hint, I don't want to loose days to fix dkms, better have a vbox versionless hint for now
<apw> not gong to make it versionless
<LocutusOfBorg> it is clearly a bad test, and I don't need autopkgtests because in case of dkms failure I get reports from debian and Ubuntu *minutes* after dinstall, really
<apw> i read the logs before updating the hints normally
<amitk> apw: do you guys provide linux-tools-common for the mainline builds at http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<amitk> I'm looking for perf
<apw> nope we don't make tools mostly, because they don't work in a cross environment
<apw> likely we don't do them at all, when we could for x86 at least
 * amitk nods
<Misha_R> Hello! A friend is looking for a HWE kernel DEB for Ubuntu LTS from December. He wants a version before the Meltdown/Spectre patches.
<Misha_R> Where can he find such a DEB?
<apw> Misha_R, in the launchpad librarian ...
<apw> https://launchpad.net/ubuntu/+source/linux/+publishinghistory
<apw> Misha_R, ^ that has the complete publishing history for the kernel; oh you wanted linux-hwe
<apw> https://launchpad.net/ubuntu/+source/linux-hwe/+publishinghistory
<apw> Misha_R, ^ so that one
<apw> iirc -26 was the first one with those changes, but you should check
<Misha_R> apw thanks
<Misha_R> apw: we can't seem to find the way to download the actual debs. For example we try this one https://launchpad.net/ubuntu/+source/linux-hwe/4.10.0-41.45~16.04.1 . There is a list of binary files but there does ot seem to be a way to download them
<Misha_R> Is rebuilding from source the only option?
<TJ-> Misha_R: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/13771372
<TJ-> Misha_R: That's the link from the page you referenced, under "Builds > amd64"
<Misha_R> Thanks!
<Misha_R> TJ-: thanks!
<raidghost> TJ had a question about modify dvb amount. Possible to turn the limit of 8 up to 16 ?
<raidghost> TJ-: Did you get any answer for that dvb question?
<TJ-> raidghost: no I didn't... create a bug report so we can log/follow it
<raidghost> TJ-: Where to make that kind of report? not that into this things :p
<TJ-> !bug ~ raidghost 
<TJ-> grrr
<TJ-> !bug | raidghost 
<ubot5`> raidghost: If you find a bug in Ubuntu or any of its derivatives, please report it using the command Â« ubuntu-bug <package> Â» - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs.
<TJ-> raidghost: report it against the package "linux"
<raidghost> Have to figure out how to explain the thingy. not good with words
<raidghost>  thought that it was the driver i had to rebuild. but if its the kernel. Its a bit more not easy.
<TJ-> raidghost: "Increase DVB_MAX_ADAPTERS from 8 to 16 in kernel config" and then explain why (because there are 4 cards each with 4 devices on)
<TJ-> raidghost: tell me the bug once you're created it and I'll add some commentary
<raidghost> TJ-: okey ;)
<raidghost> TJ-: Just a quick question. Since the host that i want to type the ubuntu-bug thingy on doesnt have graphical. is that needed to get that box that selects all the hardware information?
<raidghost> TJ-: Just created it. link is in PM
<Misha_R> Excuse me, another question again
<Misha_R> With Xenial (LTS) and the HEW kernel, how should one decide whether to install linux-image or linux-image-extras ?
<Misha_R> I could not find any explanations later than 14.04
<apw> you always need linux-image add linux-image-extra if you are on hardware
<thresh> I always install -extra, because I've been burned too many times upgrading my OS and being unable to boot or no network card up.
<mozmck> What is in the -extra package, and should a mainline build create one?
<apw> -extra has modules you don't need on a virtual machine, mainline builds do not make one because they do no split at all, linux-image is "fat"
<mozmck> apw: thanks.  I'm running preempt-rt and no virtual machines.
#ubuntu-kernel 2018-03-02
<raidghost> TJ-: was my bug report correct made?
<TJ-> raidghost: what's the bug number? I have private messages blocked so I didn't see it yesterday
 * apw didn't know you could block PMs ... interesting
<TJ-> apw:  /umode +g
<TJ-> apw: you get a server message telling you a msg was blocked, and you can have a PM with that person by doing "/query <nick> hi" to open it from your side
<apw> oh that is quite nice if you are getting slapped about
<TJ-> raidghost: post the buglink, apw is someone I'd like to see it :)
<TJ-> apw: being in support channels, without +g, everyone thinks they're special and can get 1-to-1 help
<TJ-> apw: raidghost's issue is that there is a system with 12 DVB devices in and the kernel config is hard-coded to 8... the request is to increase that, I'm going to suggest 16 ... hopefully the bug number will be provided soon. The problem is 4 devices don't get initialised due to insufficient device numbers
<apw> yeah i bet, most people do think they are special :)
<TJ-> apw: in this case 3 physical adapters each with 4 DVB frontends
<apw> i'm sparticus
<apw> TJ-, that doesn't sound like an unreasonable request, if it isn't making multi-megabyte buffers for DVD cards you don't have at least
<TJ-> It needs DVB_MAX_ADAPTERS=16 rather than =8
<TJ-> apw: right... raidghost show is the bug link !
<apw> the default is 16, so that should tell me something :)
<apw> yeah and they changed the defualt quite recently
<TJ-> sounds like a no-brainer as they say, then
<apw> if someone gives me the buglink i will add some commentary
<TJ-> raidghost: yooo-hoooo, anyone home!?!?
<apw> i am more suppriused it isn't something could be changed later, very odd
<TJ-> apw: me too, you can change the minor numbers but not the major
<apw> mostly those kinds of configs now define the number which are made by defualt
<TJ-> like you suggested, maybe it was a reserved bufferse compromise
<apw> for old s/w which cannot cope with asking for new ones
<apw> i don't see it doing that, so i think it is just 8 ... noone could have more than 8
<TJ-> yeah, that's what I expected, but it is hard coded with no over-ride
<raidghost> TJ-: of course anyone home :P
<TJ-> raidghost: show us the buglink .. apw is raring to go :)
<raidghost> https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1752692
<ubot5`> Ubuntu bug 1752692 in linux-hwe (Ubuntu) "Increase DVB_MAX_ADAPTERS from 8 to 16 in kernel config" [Undecided,New]
<raidghost> not sure if its made the propper way. But i gave it a try
<TJ-> raidghost: can you attach the system logs using "apport-collect 1752692"
<raidghost> TJ-: Would that show everything? i know there has been some issues with mdraid and others. But now fixed.
<TJ-> raidghost: it's the standard bug info collection tool, you could just attach the output of 'dmesg' ("dmseg > /tmp/dmesg.log") 
<raidghost> give me a sec. had to isntall python-apport
<raidghost> weird. Bad bot go away. didnt like my links :P
<raidghost> i use my ubuntu username and password. 
<raidghost> Something went wrong TJ- 
<TJ-> raidghost: just log-in to Launchpad and attach the captured dmesg output manually
<LocutusOfBorg> hello guys
<LocutusOfBorg> vboxvideo.ko:
<LocutusOfBorg> Running module version sanity check.
<LocutusOfBorg> Error! Module version 5.2.8_Ubuntu for vboxvideo.ko
<LocutusOfBorg> is not newer than what is already found in kernel 4.15.0-10-generic (5.2.8_Ubuntu).
<LocutusOfBorg> You may override by specifying --force.
<LocutusOfBorg> this makes *no* sense
<raidghost> Tj: so just use add a comment or attachment. and write in description dmesg and just upload file?
<LocutusOfBorg> sforshee, apw^^^ AFAIK vboxvideo is from staging, and *can't* return such version
<apw> LocutusOfBorg, indeed, the dkms version checker is bonkers
<LocutusOfBorg> I did modinfo and there is no 5.2.8
<apw> it cannot cope with the idea that the module you have has no version field but the dkms one does
<apw> it is a bug in dkms
<LocutusOfBorg> ack, thanks for confirming
<LocutusOfBorg> so "if version == NULL" pass?
<apw> it more correctly should sya, these two use different versioning so i cannot make any kind of judgement
<LocutusOfBorg> I would like to fix it
<apw> LocutusOfBorg, if we are using the in kernle one from 4.15 upwards then you can tell the dkms package that
<apw> that it is not appopriate for that system
<apw> obsolete after, something like that
<TJ-> raidghost: yes, log-in to LP, at the bottom of the bug page there's the "Add atachment or patch" link
<raidghost> TJ-: Done
<TJ-> raidghost: you'll see apw has already adopted the bug so it's in progress
<raidghost> thats why it says invalid on some affects?
<TJ-> raidghost: correct, he's assigned it to the correct projects/packages
<raidghost> I wrote 4 cards, since gonna install the last card tonight. Hoe that doesnt kill the prosess
<TJ-> raidghost: the new default in mainline is to set the value to 16, which would support 4 adapters with 4 heads each
<raidghost> Great <3 What time aspect do you think it will take?
<TJ-> raidghost: can't say, but watch the bug report. It's a pretty trivial change.
<raidghost> Thanks alot for help both you and apw. And the rest of ubuntu <3
<raidghost> breakfast time here in norway. See you later. 
<LocutusOfBorg> apw, this is even worse, the vboxvideo from vbox-guest-dkms is not installed at all now
<apw> right because it thinks the one we have is good
<LocutusOfBorg> I found a fix
<LocutusOfBorg> that 5.2.8 was leftover from previous modules verification, initializing it with 0 makes everything work
<LocutusOfBorg> and the check with version not found is: 5.2.8 > 0 -> install
<LocutusOfBorg> this is the patch:
<LocutusOfBorg> vboxvideo.ko:
<LocutusOfBorg> Running module version sanity check.
<LocutusOfBorg> Error! Module version 5.2.8_Ubuntu for vboxvideo.ko
<LocutusOfBorg> is not newer than what is already found in kernel 4.15.0-10-generic (5.2.8_Ubuntu).
<LocutusOfBorg> You may override by specifying --force.
<LocutusOfBorg> oops
<LocutusOfBorg> get_module_verinfo() 
<LocutusOfBorg> there is an "unset res", but seems to be not unsetting res[1] res[0] res[2]
<LocutusOfBorg> so, I added res[0]=0 res[1]=0 res[2]=0
<LocutusOfBorg> seems working
<LocutusOfBorg> dkms uploaded
 * LocutusOfBorg feels dirty
<LocutusOfBorg> now apw with this dkms, the testsuite will pass, and fail once you merge 5.2.8 in the kernel
<LocutusOfBorg> the usual stuff
<apw> LocutusOfBorg, yep, great, thanks
<LocutusOfBorg> 5.2.8-dfsg-2	virtualbox/5.2.8-dfsg-2 dkms/2.3-3ubuntu5	2018-03-02 12:50:07 UTC	0h 04m 03s	pass	log â artifacts â
<apw> when a userprocess sleeps it asks the krenel to do something
<apw> and then schedules away to run something else, which may be idle
<apw> if the machine is not doing anything
<apw> but it is not in userspace when it is not doing something
<apw> which is how it multi-tasks
<Martiini> I'd wanna compile my own kernel for my laptop
<Martiini> https://kmuto.jp/debian/hcl/Lenovo has device info for kernel compile
#ubuntu-kernel 2018-03-03
<Martiini> Can I contact linux kernel developer and ask them to build kernel for my laptop?
<TJ-> Martiini: please stop cross-posting the same question when you've already received answers in other channels
#ubuntu-kernel 2018-03-04
<stgraber> sforshee: so this is pretty bad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753288
<ubot5`> Ubuntu bug 1753288 in linux (Ubuntu) "ZFS setgid broken on 0.7" [Critical,Triaged]
#ubuntu-kernel 2019-02-27
<astraljava> Hi all, I have a long history with *buntu, currently (and for the past ~10 years) using Xubuntu. One part I haven't delved too deeply, though, is kernel and it's lifecycle for releases. I'm struggling with some issues on my new Lenovo ThinkPad P52, there are issues which were not present with the initial kernel line (4.15 I believe) but were introduced with the current line (4.18). I'm talking about
<astraljava> 18.10 release. I checked your 4.19 line (from PPA), which fixed many (most?) issues, but couldn't use the nVidia drivers with that. So my question is, are there plans to upgrade the kernel line for 18.10 or will I have to do it manually, or wait for 19.04?
<tjaalton> astraljava: it'll stay at 4.18
<tjaalton> but, you actually have an option to use the oem kernel which is available on cosmic too and is based on 4.15
<astraljava> tjaalton: Thanks! I'll look into that. :) Good info, appreciated!
#ubuntu-kernel 2019-03-03
<bear38> Hi guys, I had a simple question. I'm trying to backport a commit to mm/zswap.c, the "same filled pages" change, to 4.15.X. I'm also backporting another change to z3fold.c. I heard in another channel that rebuilding the z3fold module would make my changes to both zswap.c, and z3fold.c take effect. But so far, only my changes to z3fold.c are having an effect.
<bear38> So my question is, is there some way for me to patch zswap.c without rebuilding the entire kernel?
<arighi> bear38: zswap and z3fold are two separate modules, in particular z3fold is one of the available compressed memory pool allocator that zswap can use, so patching z3fold can affect zswap if this specific memory allocator is used (check /sys/module/zswap/parameters/zpool). About recompiling the kernel, it depends what you're touching with the code that you're backporting, if you touch only zswap.c (and it seems to b
<arighi> e "same filled pages" patch), recompiling the kernel should only rebuild the zswap module. Then to apply these changes you need to reboot, or remove and re-insert the zswap module, or use live-patching (but I wouldn't recommend using live patching with this particular change, it doesn't look safe at all, because the change is affecting zswap's metadata)
<bear38> arighi: Thank you for that info. Apologies for being totally new at kernel hacking, but is zswap an actual module? I'm unable to find any .ko file with zswap in the title. I do see z3fold.ko, for the changes to that file. Do you have any guess about what module file I would need to rebuild in order to get my changes to zswap.c to take effect?
<arighi> bear38: you're right! Looking at the code (zswap.c), it's written like a module, but if you look at CONFIG_ZSWAP in mm/Kconfig, it's defined as bool (not tristate, like any module), so it can be either compiled into the kernel or disabled. Probably the reason is because it requires a lot of internal kernel functions that are not exported to modules (with EXPORT_SYMBOL)
#ubuntu-kernel 2020-02-24
<apw> zx2c4, ok merge applied and uploaded for focal
<zx2c4> apw: excellent, thank you!
<zx2c4> now _thats_ a good version to backport to eoan if you still have appetite for that
<zx2c4> i just checked the dpkg, looks good
<apw> zx2c4, once its had a few moments to get some testing on my machine, yes
<apw> it hasn't passed britney's scrutiny as yet
<apw> zx2c4, we also identified the two process failures that let that kernel out without wireguard being fixed in eoan; and the gaps have been closed
<zx2c4> oh cool, thanks
<zx2c4> i guess you guys have some mega dkms auto builder?
<zx2c4> very glad that none of this will matter in the least moving forward, with the binary module and all
<apw> we have lots of checks and balances, some of which failed this time, we have changed the ones in question
<DalekSec> wireguard and wireguard-linux-compat were both uploaded to Debian now too, the former adds a NEWS entry notiing that the metapackage no longer implies a reload.
<zx2c4> \o/
#ubuntu-kernel 2020-02-26
<ricotz> arighi, hi :) could you delete "linux-meta - 5.5.0.2.11" from ~canonical-kernel-team/bootstrap ?
<ricotz> arighi, and likely even "linux - 5.5.0-2.3"
<arighi> ricotz, oh.. why that? because now unstable moved 5.6?
<ricotz> arighi, yes, as long there is no plan to make linux-meta point to 5.6?
<ricotz> (in focal pocket)
<arighi> ricotz, there is a linux-meta-5.6, so yes, all the unstable 5.5 stuff can be deleted
<ricotz> arighi, I know, I just wondering if there is a reason for the "real" linux-meta package pointing to an unmaintained package, and not to delete it
<arighi> ricotz, yeah I don't see any reason, we can definitely clean those up
<ricotz> arighi, thanks , " linux-signed - 5.5.0-2.3 " and " linux-restricted-modules - 5.5.0-2.3 "
<arighi> ricotz, yep, thanks for pointing that out!
#ubuntu-kernel 2020-02-27
<fructose> I'm on kernel 5.0.0-38-generic, but when I apt source kernel-source, edit and build a driver, and insmod it, it fails and dmesg reports a version magic 5.0.21. How do I get that to match 5.0.0-38-generic instead?
<fructose> Alternatively, I've tried to manually bind a driver and am given 'No such device', but I'd be happy to have help figuring out if I'm using the wrong bus id.
#ubuntu-kernel 2020-02-29
<zx2c4> I woke up to see this garbage in my inbox... apparently somebody made a launchpad project impersonating the WireGuard team and then used the platform to send invitation join notices to a variety of highprofile kernel devs. The perpetrator of this impersonation attempt is a username called "roguescholar", who foolishly made me an admin (perhaps to bolster the fake team's credibility?), so I promptly moved to delete the thing. Yowza. 
<zx2c4> https://usercontent.irccloud-cdn.com/file/MyLVJCXw/Screenshot_20200301-074823.png
<zx2c4> Might want to lock down "roguescholar" account...
#ubuntu-kernel 2020-03-01
<FurretUber> I found a regression on 5.6 kernel and I'm bisecting it now. While I understand Ubuntu currently does not use this version, could I ask help on reporting the bug?
<amurray> zx2c4: might be worth reporting that in #launchpad-ops
<cjwatson> #launchpad-ops is an internal channel
<cjwatson> https://answers.launchpad.net/launchpad/+addquestion is preferred for this sort of thing.  However, Launchpad was designed to track things that are hosted externally to Launchpad, so it is emphatically *not* abuse just because somebody creates a Launchpad project for something that is hosted elsewhere
<cjwatson> It might be more effective to have a small official placeholder project on Launchpad just so that people aren't tempted to make their own
<cjwatson> This looks much more like somebody well-meaning but a bit misdirected, than somebody who deserves to have rockets sent their way and their account locked down
<amurray> oh thanks for the correction cjwatson :)
