#ubuntu-kernel 2005-07-25
<fabbione> morning
<Mithrandir> fabbione: it appears that davyd has tickled a bug in the 32 bit support code in the kernel.  gdb /bin/ls in a 32 bit chroot on a 64 bit kernel falls over when running the program
<fabbione> Mithrandir: what kernel?
<fabbione> .10 ? .12 ?
<Mithrandir> fabbione: "any".  he can reproduce it using 2.6.12-3-amd64-generic, I can reproduce it using 2.6.10 from kernel.org with a regular debian 32 bit userland.
<fabbione> Mithrandir: .. what are the symtomps?
<Mithrandir> (gdb) r
<Mithrandir> Starting program: /bin/ls
<Mithrandir> (no debugging symbols found)
<Mithrandir> (no debugging symbols found)
<Mithrandir> (no debugging symbols found)
<Mithrandir> (no debugging symbols found)
<Mithrandir> (no debugging symbols found)
<Mithrandir> [Thread debugging using libthread_db enabled] 
<Mithrandir> Error while reading shared library symbols:
<Mithrandir> Cannot find new threads: generic error
<Mithrandir> and then it just hangs.
<fabbione> it looks more likely a glibc bug....
<Mithrandir> LD_ASSUME_KERNEL=2.4.1 fixes it, so it's probably related to NPTL somehow.
<fabbione> blame glibc :)
<Mithrandir> well, it's not there on i386, is it?
<fabbione> no idea..
<fabbione> it works on i386
<Mithrandir> so it's a kernel bug. :-)
<fabbione> i suggest you mail Andy Kleen
<Mithrandir> will do
<fabbione> ak@muc.de
<zul> jbailey: ping..
<zul> nevermind he is probably at ols
<surak> hello people
<surak> Ubuntu's mailing lists pages ( http://www.ubuntulinux.org/community/lists ) lists no page for kernel development. In wiki we find only the kernel-team one.
<surak> Reading http://lists.ubuntu.com/archives/kernel-team/2005-April/000495.html (regarding vt6410 ide raid controller) , Chuck says "I have looked over the patch and made a diff for breezy."
<surak> I'm using a breezy live cd from june 28, which reports kernel 2.6.12-2-386, but there is no via92cxxx module on it (just via82cxxx). Where can I look for help on it? I have a spare machine with two 150gb drives on this controller and willing to help testing this driver.
<jammcq_ols> fabbione: hey, can we get the FUSE driver added to the kernel package?  We need it for ltsp local device support
<fabbione> hi jammcq_ols 
<fabbione> jammcq_ols: i remember there are 2 drivers similar.. one is fuse and the other i can't remember..
<fabbione> one of them has a dead upstream
<fabbione> if fuse is the ok one, i can include it yes
<fabbione> but i would like you to file a bug or send me an email as reminder
<surak> fabbione: can vt6410 ide support be included in kernel? there is a patch for via82cxxx in linux-kernel - http://www.ussg.iu.edu/hypermail/linux/kernel/0502.0/1870.html
<jammcq_ols> fabbione: I'm at OLS, and it was mentioned this morning that FUSE was likely going into the mainstream kernel
<jammcq_ols> I'll file a bug report
<surak> hello?
<fabbione> re
<fabbione> surak: let me check
<surak> ok
<fabbione> surak: no. the patch has been submitted a while ago and not included upstream meaning that the patch is not good enough. Also note that the chipset still get to work with the generic driver
<surak> it is not recognized as a valid drive here in 2.6.12-2 
<surak> which means, I cannot partition it with any partitioning tools found at breezy live
<surak> What can I do to help? Create a module for it and post it for public testing?
<fabbione> surak: you can't. the patch is on top of an existing driver. You need to get upstream to apply it.
<fabbione> i am not going to include patches that are not on the way to upstream anymore
<fabbione> not so close to release
<surak> so, no vt6410 for breezy live?
<fabbione> does it work with the installer?
<surak> didn't try it yet. 
<fabbione> try with the installer
<fabbione> if it can see the controller.
<surak> but you can always install on a sata drive and upgrade kernel...
<surak> any breezy installer? or you mean hoary?
<fabbione> breezy
<fabbione> hoary won't get anything like that
<surak> ok. I'll download one now.
<fabbione> i am off
* fabbione &
<nsillik> I have a kernel driver I've written and I need a little help testing, is this the proper place to post an announce?
<surak> nsillik: just curious: what kind of driver?
<nsillik> it adds usuability for the OneTouch driver on Maxtor OneTouch drives... it's really a small thing, but it was my first (usable) kernel driver
<nsillik> it uses the unusual_devs.h file to declare an extra init function for the usb_storage driver, then connects the interrupt endpoint on the hard drive to input, the button can then be programmed using any keybinding software
<nsillik> even if you don't have the drive, but have a few minutes to get your eyes on it, to see if you see any obvious errors, the .diff is locate here http://www.ducttape-and-marbles.com/onetouch.diff
#ubuntu-kernel 2005-07-26
<lamont__> fabbione: you around?
<jbailey> zul: pong
<fabbione> morning
<fabbione> lamont: i am now
<fabbione> infinity: ping?
<infinity> pong?
<fabbione> infinity: so.. let's talk about flavours :)
<fabbione> did you get all your hw in place?
<infinity> I seem to be much better off hardware-wise than I was a month ago, yes.
<fabbione> infinity: i think it's time to test the k7 - 686 thingy and possibly other combinations
<infinity> One ppc32 (1.0 GHz G3), one amd64 (2.0 GHz Athlon64) and one i386 (2.0GHz Pentium-M)
<fabbione> i am pretty sure we can
<fabbione> i am pretty sure we can't drop 686 vs 686-smp or similar
<infinity> Assuming we don't run into driver instability issues, yes.
<fabbione> according to bugzilla some smp kernels are suffering some weird extra bugs
<infinity> Given that I'm pretty sure ipw2200 locks up my 686 machine occasionally, I wonder if it'll get worse if I go SMP...
<fabbione> infinity: ipw2200 is broken for N millions other reasons
<infinity> I've noticed.
<infinity> At least it mostly works for me right now.
<fabbione> what we need to see are performance issues :)
<fabbione> if any
<fabbione> and imho there are none
<infinity> I'm doubting we'll see any worth noting.
<fabbione> all the other arches are down to N and N-smp
<fabbione> only i386 is still bloated
<infinity> Okay, how many i386 flavours do we have?
<infinity> And how many do we ideally want?
<fabbione> 5 
<fabbione> with the tendency to increase soon
<fabbione> if we get 686-xen0 686-xenU
<fabbione> so i am on the idea of killing k7 completely
<infinity> Can we build -i386 with arch=i486 tune=pentium, or something similar?
<fabbione> hi Janew
<fabbione> infinity: that's what the 686/k7 selection does at the end
<infinity> k7 is hard to test, as I don't have a real k7... I might be able to dig up someone who does.
<fabbione> my k7 is half broken even with 386 kernels
<infinity> ?
<fabbione> infinity: we still need a clean 386 .. that should be really 486 by now
<fabbione> infinity: hw problems :)
<infinity> Yeah.  I don't have a 486 anymore, but I can test on a Pentium-MMX.  That's as slow as it gets.
<infinity> (Are we carrying the 486 emulation patch in our 386 kernels, BTW?)
<fabbione> infinity: nope...
<infinity> Or do we just not support anything < 486?
<infinity> Kay.
<Mithrandir> I have k7s just fine.
<fabbione> we dropped real 386 support a while ago
<JaneW> hi fabbione
<infinity> Mithrandir : Hi, you just signed up to do some 686 vs k7 performance testing, then. :)
<fabbione> Mithrandir: can you run a 686 kernel on it and tell us if there is any noticable performance issue?
<Mithrandir> fabbione: sure.  Urgently? (please say no)
<fabbione> brb i need more coffee
<fabbione> Mithrandir: well asap.. within yesterday is fine
<fabbione> Mithrandir: kidding.. sometime within monday or tuesday if possible
<infinity> fabbione : Is there actually a reason for the amd64-{generic,k8,xeon} split at well, or just people looking for that 2% performance boost again?
<Mithrandir> fabbione: I'll see what I can do.  Most of my systems are still boxes on the floor around here.
<infinity> I have no xeon to test on, but I can do the opposite thing of testing the xeon kernel on my k8 and see if it sucks.
<Mithrandir> I don't think I have any xeons, but I could ask around at hardware.no and see.
<Mithrandir> infinity: I think the xeon and k8 kernels won't necessarily work on both kinds of hardware.
<infinity> That's a theory I'd like backed up with proof.
<fabbione> infinity: i have no idea...
<infinity> (Keep in mind that we have a "generic" amd64 kernel which apparently works on both, so dropping k8 /and/ xeon would be the sane option if the performance hit isn't terribly noticeable)
<fabbione> about xeon/k8
<fabbione> and generic i *think* works on emt64 too
<infinity> Well, that's the point, yes.
<infinity> It's the kernel we use in the amd64/em64t installer, so it better work on both.
<fabbione> even if i saw Debian spawning the usual 24 flavours on svenl's ppc wave
<fabbione> amd64-k8-smp:CONFIG_SMP=y
<fabbione> amd64-xeon:CONFIG_SMP=y
<fabbione> that's the only thing...
<fabbione> well more or less
<fabbione> # disable it for opteron optimized builds because it pulls in ACPI_BOOT
<fabbione> config X86_HT
<fabbione>         bool
<fabbione>         depends on SMP && !MK8
<fabbione>         default y
<fabbione> MK8 = k8
<fabbione> so there are differences
<Mithrandir> I've asked fs who does the amd64 kernels in Debian about the reason too
<infinity> No terribly large differences.
<fabbione> ok
<fabbione> well HT can make a difference.. and associate to ACPI
<infinity> amd64 and amd64-smp would probably cover all our bases if amd64-smp also had HT enabled, and still works fine on k8.
<fabbione> the latter makes me feel not particularly conmfortable
<fabbione> you mean generic and generic-smp :)
<infinity> Well, no, there'd be no need for the "generic" moniker if there were no non-generic ones. :)
<fabbione> but yeah i agree 2 flavours should be more than enough
<infinity> If you can build an amd64-smp with HT enabled, I can spin it with elmo on a buildd.
<infinity> That's the best way to find out if it's broken.
<fabbione> infinity, Mithrandir: can you 2 focus today and tomorrow to do this research between cpu diffs?
<fabbione> infinity: i can spin it.. that's no problem, but where is elmo?
<fabbione> he needs to go to a DC to reboot a buildd...
<fabbione> s/a/the
<infinity> Yes, he and I already have a date to do amd64 kernel testing.
<fabbione> ok.. and when is that supposed to be?
<infinity> We want to make sure breezy's kernels are all capable of running the buildds for breezy+1, so it's something that needs to be done anyway.
<fabbione> because 2.6.12 on concordia is giving the same problems as 2.6.10 on the buildd...
<infinity> Early next week is when I was planning on pinging him back about it.
<infinity> concordia's still going down?
<fabbione> no
<fabbione> but it's segfault-o-rama
<infinity> Not quite the same problems, then.
<infinity> The buildds actually crash.
<fabbione> i can't even build the kernel there
<infinity> We'd prefer they didn't.
<fabbione> same synmptomps of G5 on ppc32 kernels
<infinity> Fun.
<fabbione> just much worst
<fabbione> and dmesg full of the same crap you pasted to me
<infinity> Well, if you want to try to spin a bunch of test images, we can make a play-date.
<fabbione> but yeah.. it's not going down.. that's true
<fabbione> i can't spin images without concordia..
<fabbione> i can give you a config...
<fabbione> but you can as well just edir amd64-generic locally
<infinity> Very true.
<infinity> He and I will play then, and get back to you.
<infinity> Do you have changes queued up to linux-source, or is -3.3 still the "best known" version?
<fabbione> infinity: 4.4 is on the way
<fabbione> but i was hoping to get amd64 sorted out before
<fabbione> otehrwise it will be a neat FTBFS
<infinity> An FTBFS never killed anyone.
<fabbione> it will kill my patience because i need the ABI files out of the build
<infinity> If you can roll up what you're planning to release, that's the source elmo and I will play with.
<fabbione> before be able to upload a fixed version
<fabbione> infinity: ok.. i will try to do that asap
<fabbione> i need to finish to cleanup the udeb creation
<infinity> Just roll a prerelease and toss it on chinstrap.
<fabbione> but it is possible to build the debs
<fabbione> infinity: see /topic :)
<fabbione> grab the source and apply some baz magic :P
<infinity> Yeah, yeah.  Will do.
<fabbione> eheh
<fabbione> don't worry
<fabbione> i will give you the diff.gz
<fabbione> i am still working on staff
<fabbione> infinity: also.. another question.. are we going to drop gcc-3.3 from breezy?
<fabbione> doko: can gcc-3.3 actually build ppc64 binaries?
<infinity> How are the kernel builds with gcc-3.4 looking?
<fabbione> not good
<infinity> Feh.
<infinity> Then I guess we need 3.3
<fabbione> they build.. but it seems that some stuff is miscompiled
<infinity> Not surprised at all.
<fabbione> i386/ppc seems to be ok
<fabbione> but all the other arches are showing regressions
<infinity> We don't have time to fix that sort of breakage.
<fabbione> nope
<infinity> Debian does, we don't.
<fabbione> not at all
<fabbione> and jumping to 4.0 is no solution
<infinity> So we need 3.3 in main, and we should probably use it to compile everything but ppc64.
<doko> fabbione: hmm, I don't know. do you really care?
<fabbione> doko: yes i do care :)
<fabbione> read above...
<infinity> And compile ppc64 with 3.4 (I assume?)
<fabbione> infinity: i am more happy to use the same compiler everywhere
<infinity> I don't think 3.3 will generate a pcc64 kernel to save its life.  But yo ucan try.
<fabbione> isn't gcc-3.3 still in main?
<fabbione> gcc-3.3 -m64 -o hello.o -c hello.c
<fabbione> cc1: error: invalid option `64'
<fabbione> i guess it doesn't
<Mithrandir> 11:20 < fs> Mithrandir: hyperthreading, no IOMMU, and compiled with -march=nocona
<fabbione> Mithrandir: meaning of?
<Mithrandir> the xeons doesn't have an IOMMU
<fabbione> so we need xeons
<fabbione> but i think we can kill k8* and make generic and generic-smp
<fabbione> that will remove one flavour
<fabbione> i am not even sure it's worth the pain
<fabbione> but k7* should go
<fabbione> infinity: we can probably cheat there
<fabbione> set M486 that is common
<fabbione> and call it 686
<fabbione> that should work on k7 too
<fabbione> k7 has a different cache shifting level
<fabbione> so there is a bit of performance impact
<fabbione> config X86_L1_CACHE_SHIFT
<fabbione>         int
<fabbione>         default "7" if MPENTIUM4 || X86_GENERIC
<fabbione>         default "4" if X86_ELAN || M486 || M386
<fabbione>         default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 
<fabbione> || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODEGX1
<fabbione>         default "6" if MK7 || MK8 || MPENTIUMM
<Mithrandir> would that be hard to detect runtime?
<Mithrandir> using cpuid or something?
<fabbione> cflags-$(CONFIG_M686)           += -march=i686
<fabbione> cflags-$(CONFIG_MK7)            += $(call cc-option,-march=athlon,-march=i686 $(align)-functions=4)
<fabbione> Mithrandir: eh.. it depends. let me check
<fabbione> these kind of patches are sort of intrusive
<infinity> Defaulting to 6 and seeing if it hurts Pentium4 and PentiumII would be my preference.
<infinity> But that's cause I own a Pentium-M. :)
<fabbione> i don't like playing with L1 cache at random
<fabbione> i am pretty sure who did that stuff knows more than us
<fabbione> include/asm-i386/cache.h:#define L1_CACHE_SHIFT (CONFIG_X86_L1_CACHE_SHIFT)
<fabbione> include/asm-x86_64/cache.h:#define L1_CACHE_SHIFT       (CONFIG_X86_L1_CACHE_SHIFT)
<fabbione> arch/ia64/sn/kernel/bte.c:      BUG_ON(!(len < ((BTE_LEN_MASK + 1) << L1_CACHE_SHIFT)));
<fabbione> arch/ia64/sn/kernel/bte.c:      transfer_size = ((len >> L1_CACHE_SHIFT) & BTE_LEN_MASK);
<fabbione> it's stuff like this i have no idea it can be mangled at boot time, early enough to make it working
<infinity> Well, given than all those options work on all CPUs, just to varying degrees, it can't be that bad to fiddle with it.
<fabbione> infinity: i am not completely sure about that...
<fabbione> the option is to a certain value...
<fabbione> changing the value at runtime, might require a flush of cache 
<fabbione> i think at least..
<infinity> Oh, yes, changing it at runtime could blow things up.  I meant that defaulting to something sane enough for everyone at build time wouldn't kill us.
<fabbione> not sure...
<infinity> Given that 7 is the default for generic, and 4 is the default for 386, and both those options work everywhere...
<fabbione> let's make it 5.5
<infinity> Rock.
<infinity> Then round up to 6, and I win.
<infinity> As do all k7 and Pentium-M owners.
<fabbione> and 686 lose
<infinity> And, really, anyone buying a new 686 system that isn't k7 or Pentium-M sucks anyway. :)
<fabbione> given i have only 686.. you lose
<infinity> (But we don't know how much you lose by without testing)
<fabbione> excactly
<fabbione> and given the -ENOTIME...
<infinity> Right now, our 686 kernels are already slower than they should be on k7 and pentium4, I don't see much difference here, except that we probably improve both those situations.
* infinity -> dinner
<fabbione> ok let see what's the outcome from Mith's tests on k7
<fs> better kill 686, crappy stuff anyways ;)
<fs> hi fabbione =)
<fs> why the flavour reduction at all?
<fs> the k8 and xeon flavours do different cache aligning, too
<fabbione> hi fs :)
<fabbione> fs: -ETOOMANYFLAVOURS
<fabbione> we are experiencing problems with users not being able to understand what to install
<fabbione> reducing the set of options will make it simpler
<fs> that drives users in compiling more own kernels, as they want a best fitting kernel for their arch
<fs> well, thats an argument
<fs> but why not just explain what to install instead?
<fabbione> fs: we do.. and it's a FAQ..
<fabbione> still people don't understand :)
<fabbione> also
<fabbione> there are some bugs that are coming up only in specific flavours...
<fabbione> probably due to compilation options?
<fs> I see
<fabbione> so that would also reduce the amount of things to debug
<fabbione> so getting to a smaller set of kernels, will reduce a lot of problems
<infinity> Ubuntu's target audience is (generally) not the sort of group that would compile their own kernels for optimal performance anyway.
<fabbione> to a certain degree
<infinity> And the few tha treall want to can use make-kpkg and I won't yell at them.
<fabbione> infinity: tell that to glxgears and daniels :)
<infinity> I still build my own kernels in most situations too (though, I use a stock kernel on my laptop)
<fabbione> i think we should upload a fake glxgears that multiply by 10 automatically
<infinity> Or just drop the glxgears binary completely.
<infinity> Or include a real OpenGL benchmark for people who seem to think they need one.
<fabbione> ehhehe
<fabbione> i prefer to cheat.. it's more fun
<infinity> But, really, our target market is a "win32 killer", and I haven't noticed Windows installing a sozen different kernels depending on your CPU.
<infinity> (THough they may do on-the-fly cache tuning, depending on CPU)
<zul> damn idiots
<fabbione> hey zul
<fabbione> sup?
<zul> not much...idiot is taking my nick again
<zul> i think ill drop a huge megaton bomb on his ass
<Mithrandir> you could just register your nick and ghost him
<zul> i have and did
<infinity> The same guy takes my nick every time I fall offline (which is usually for a very short period, once or twice per month)
<infinity> I can't understand the fascination with it, since he always gets punted shortly after.
<Hohlraum> Sorry to barge in.. would someone happen to know what version of 2.6 the hoary installer is using?  i've got some dell 1850 and 2850 hardware that needs the drivers included with newer versions of 2.6
<mjg59> 2.6.10
<Hohlraum> very cool.. i think that might be the magic version that those drivers were included in. excellent. thanks!
<lamont> fabbione: I remembered why I was looking for you...
<fabbione> lamont: ah cool
* fabbione goes offline
#ubuntu-kernel 2005-07-27
<zul> hey
<zul> jbailey: ping
<fabbione> morning
<lamont> fabbione: so how's your current thinking on 3.3 for the kernel?
<fabbione> lamont: i am more and more convince to roll back to 3.3
<fabbione> but we can't for ppc64
<lamont> hppa needs gcc-3.4 as well
<fabbione> so we need 3.4 for hppa and ppc64
<lamont> (since there is no gcc-3.3 in the archive for hppa....)
<fabbione> i386 can handle
<fabbione> amd64 seems ok
<lamont> ia64 would kind of like 3.3, at least for a test build...
<fabbione> the only one that needs 3.3 seems to be ia64 right?
<lamont> which I'll wind up really doing tomorrow
<fabbione> ok
<fabbione> does hppa boot with 3.4?
<lamont> OTOH, if we assume that there will be another kernel upload for ia64, and we further assume that lamont is lazy, then if there was an excuse to upload a new kernel in the next several hours, it'd be really nice if it (a) switched ia64 to 3.3, and (b) overrode the abi change that almost certainly causes
<lamont> yes
<lamont> well, last I checked
<lamont> 2.6.12-1-hppa64 
<lamont> and the other buildd is even more new
<lamont> gcc-4.0/hppa is in the dh_builddep maze!!!
<lamont> doko: dh_movefiles: Compatibility levels before 3 are deprecated.
<fabbione> yeah i told him already
<lamont> hehe
<lamont> coolness.  all of my packages are at 3 or 4.
<fabbione> so are mine :)
<fabbione> coolness! f11 is back online
<fabbione> for the first time i can pretest/build all 6 arches
<fabbione> lamont: dunno if you are looking at baz anymore, but i did a huge rework of the udebs
<lamont> haven't looked at baz in a bit..
<fabbione> ok
* lamont has been trying to focus on (1) ia64, and (2) getting hppa built
<fabbione> i won't manage to realling the configs for breezy... tough
<fabbione> that will be the first step for breezy+1
<lamont> realign, you mean?
<fabbione> like CONFIG_PREEMPT enabled on some arches and not others?
<lamont> right
<fabbione> afaik HPPA has PCI, but doesn't build a lot of drivers...
<fabbione> stuff like that
<lamont> well, more pedantically, many of the PCI drivers for generic cards don't work on hppa.  maybe... (really don't know)
<fabbione> wee if nobody builds them we will never know and get them fixed..
<infinity> fabbione : Where are you currently enabling preempt?
<infinity> fabbione : My last spin of preempt on my powerpc machine resulted in random spectacular oopses and panics.
<fabbione> infinity: i386, ppc64, ia64
<fabbione> all the others are unset
<infinity> Is davis running a ppc64 kernel with preempt right now?
<lamont> Built successfully
<lamont> Purging chroot-breezy/build/buildd/gcc-4.0-4.0.1
<lamont> !!!!!!
<fabbione> infinity: yes
<fabbione> YAY
<infinity> fabbione : Ahh, good, then that seems like an adequate test for ppc64. :)
<fabbione> infinity: PPC + PREEMEPT needs SMP
<fabbione> that
<fabbione> that's what i was told
<infinity> fabbione : I'll just warn you now that it seems hideously broken on ppc32 and if you enable it, you'll be in for a world of hurt.
<fabbione> it's not..
<infinity> Hrm.  Or, it needs SMP.  I guess that makes sens, since preempt just reuses SMP spinlocks.
<fabbione> i wonder why it's not enabled on amd64 at all
<infinity> (THough, I thought there had been work years ago to abstract that, so they were independant of each other)
<fabbione> or we can just disable it everywhere
<fabbione> that would make me even more happy
<infinity> Me too, TBH.
<fabbione> given that GFS isn't exactly PREEMPT safe
<infinity> PREEMPT is still one of those "play with it yourself if you're smart enough to compile your own kernel and break your own machine" things, IMO.
<infinity> Also, bed for real now.
<fabbione> config PREEMPT
<fabbione>           Say Y here if you are building a kernel for a desktop, embedded
<fabbione>           or real-time system.  Say N if you are unsure.
<fabbione> well we are distributing a server, aren't we?
<fabbione> or did i misundertood something about Ubuntu? ;)
* lamont sleeps
<fabbione> night lamont
<fabbione> PREEMPT is gone
<fabbione> hey JaneW
<JaneW> hi
<fabbione> JaneW: i need a name :)
<fabbione> something really sexy or totally weird..
<fabbione> no nuts this time :)
<JaneW> fabbione: no problemo
<JaneW> Whooping	Wholewheat
<fabbione> oky :)
<fabbione> thanks
<zul> hey
<fabbione> hey zul
<zul> hey fabbione 
<fabbione> ok... 4.4 on the way
<zul> jbailey: you around?
<fabbione> zul: hey
<fabbione> he is at OLS
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,5--2.6.12
<zul> yeah i wanted to go hang out after work
<fabbione> zul: it's easier if you hook up on ofct #parisc
<fabbione> there are the people that share the room with him there
<zul> okie dokie
<zul> fabbione: no more extra drivers or is it still ok?
<fabbione> zul: it depends
<fabbione> i am being a bit close on accepting stuff
<zul> i was thinking speakup
<fabbione> but it really depends what it is
<fabbione> hmmmm HMMMMM
<fabbione> zul: i would be more happy go get the acerhk back
<zul> since im going back to development this weekend for sure
<fabbione> you removed it because it was apparently unmaintained
<fabbione> but it is
<zul> i think there might be a more of demand for speakup though
<zul> i read it on the website it wasnt maybe i misread it
<fabbione> yeah the website is crpa
<fabbione> cra
<fabbione> CRAP
<zul> besides i think its on breezy's roadmap
<fabbione> nobody bothered to ask us
<zul> yeah...uh...whatshisname
<zul> damn it
<zul> heh...i can check the logs and prove it ;)
<fabbione> zul, chmj: a very simple task for all of you
<fabbione> closing the bugs in bugzilla with the latest upload?
<chmj> erm, just closing ?
<fabbione> chmj: see the kernel changelog...
<fabbione> for 4.4
<fabbione> there are a bunch of bug closers
<fabbione> pick these bugs and bugzilla -> resolved+fixed with a note that has been in done in kernel 2.6.12-4.4
<fabbione> nothing too fancy...
<fabbione> i am just too tired to fight with bugzilla
<zul> slacker..:)
<lamont> fabbione: linux-source-2.6.12_2.6.12-4.4 is near the top of the queue for hppa.  I guess that's a good thing... :_)
<lamont> fabbione: can't just do edit many?
<lamont> or you're _that_ tired??
<jbailey> zul: Am around now.
<zul> im off around 4 today and am getting downtown around 5:30ish what are you up to around that time
<fabbione> re
<mjg59> Wurgh.
* mjg59 has correctly diagnosed the AGP resume failure, hurrah
<mjg59> fabbione: I'll need to send you a patch for that before too long
<fabbione> mjg59: ok...
<fabbione> too bad i just uploaded a kernel today
<mjg59> Yeah, it's not urgent
<jbailey> fabbione: Ooo.  New kernel?/  Perhaps it will unbreak my acpi...
* jbailey hides.
* fabbione hits jbailey with an apm cluebat
<zul> ah sweet...im being sent hardware
#ubuntu-kernel 2005-07-28
<lamont>  /build/buildd/linux-source-2.6.12-2.6.12/debian/build/build-hppa64/scripts/gcc-version.sh: line 11: hppa64-linux-gcc-3.4: command not found
<lamont> grumble
<lamont> now to figure out if that's a problem with the chroot, or the package
<fabbione> mornign
<infinity> fabbione : #ubuntu-toolchain ... I misfired.
#ubuntu-kernel 2005-07-29
<fabbione> morning
<zul> hey
<fabbione> hey zul
<zul> how goes it?
<fabbione> just finished to reorganized my office
<zul> oh yes?
<zul> im back..
<fabbione> i am tired to death and i didn't even manage to start cleaning up the server config
<zul> heh
<zul> fabbione: how do you want to handle 10809 http://bugzilla.ubuntu.com/show_bug.cgi?id=10809
<fabbione> right now?
<fabbione> i don't
<fabbione> we don't
<zul> i was going to handle it
<fabbione> it's not our business
<zul> okie dokie
<fabbione> it's not kernel directly.. basically
<zul> oh yeah didnt see that...duh..
#ubuntu-kernel 2005-07-30
<calc> ugg!
<calc> 2.6.12-4 downgraded ipw2200 from 1.0.4 -> 1.0.1 which broke it entirely instead of going to 1.0.6 which probably fixed whatever bugs 1.0.4 had and actually works as well :\
<crimsun> err
* calc had to switch back to 2.6.12-3 to be able to use his nic at all
<calc> 11601 wasn't even about ipw2_2_00
<calc> it was for ipw2100
* calc notes the changelog entry
<calc>   (Closes: #11601, #12417, #10627, #11696)
<calc> 12417 is real for ipw2200 but was also fixed in 1.0.5
<calc> also note 12417 did cause problems but didn't cause it to completely stop working for me unlike the current 1.0.1
<crimsun> so the better option is to upgrade ipw2200 to 1.0.6
<crimsun> I haven't checked if that implies we need to update ieee80211, too
<calc> 10627 might be fixed in new firmware but can't really tell since it says some WEP fixes
<calc> crimsun: yea
<calc> crimsun: maybe 1.0.6 refers user to ieee80211.sf.net site
<crimsun> probably ipw2100 to 1.1.2 as well
<crimsun> yeah, ipw2100 1.1.2 and ipw2200 1.0.6 both need the separate ieee80211 1.0.2
<calc> btw 11696 sounds like it might be related to the firmware problem that was fixed in 1.0.5 also
<crimsun> so if possible, ieee80211 1.0.3, ipw2100 1.1.2, and ipw2200 1.0.6
<crimsun> I really miss my P4 build machines
<crimsun> it's gonna be a pain testing on this celeron
<calc> do i need to file a bug in bugzilla stating 1.0.1 doesn't work at all for me? :)
<calc> i think i have feeling why it doesn't work at all for me too :)
<calc> after reading the changelog between 1.0.4 and 1.0.1
<calc> it appears among other things doing that completely removed support for WPA
<calc> downgrading the driver to support WEP and nuking WPA support is er beyond stupid
<calc> WEP can be cracked in an insignificant amount of time, its worse than useless
<crimsun> many manufacturers don't even enable WEP by default
<calc> of course the usefulness of an insecure protocol may vary by user
<calc> hmm didn't know about that
<calc> i need to look into upgrading to WPA2, the new bios for my AP supports that too
<calc> hmm it seems WPA2 mainly just requires that the hardware do AES
<calc> appears WPA2 is just a slightly updated WPA to fully comply with the 802.11i standard
<calc> while some older WPA hardware already supported most of it but wasn't required to
<fabbione> morning
<crimsun> morning, fabbione. I presume you found what you needed?
<fabbione> crimsun: yup.. thanks :)
<crimsun> great :)
<zul> morning
<chmj> hi chuck 
<zul> hey chmj 
<zul> hey jeff
<jbailey> Heya Chuck.
<jbailey> Glad to have you over last week, thanks for coming.
<fabbione> did you 3 meet?
<fabbione> jbailey: did you also sign his key?
<jbailey> fabbione: I didn't, although I would have.  I've met him more than once.
<jbailey> It hadn't come up, sorry.
<jbailey> ...
<jbailey> 3 ?
<jbailey> =)
<fabbione> because that would give zul the option to be a MOTU
<jbailey> ARE YOU CALLING ME FAT?
<fabbione> uh?
<jbailey> *g*
<fabbione> who said FAT?
<jbailey> One of us has to be doubled in order to make 3 of us.
<jbailey> And since youv'e never met Chuck, you must mean me. =)
<zul> fabbione: willy signed my key long time ago
<fabbione> zul: willy isn't an ubuntu devel
<zul> doh!
<fabbione> even tho i did sign his key
<jbailey> fabbione: When did we stop trusting the Debian web of trust?
* jbailey hates how the motu procedures change by the week.
<fabbione> jbailey: i am not sure multihops are valid.. but i definetely trust willy's judgement
<fabbione> and i am happy with that
<jbailey> =(
* jbailey checks #ubuntu-motu
<fabbione> jbailey: i need to get in touch with the Firewall guy...
<fabbione> is he active or MIA?
<jbailey> Which Firewall guy?
<jbailey> My SoC student?
<fabbione> the one you are mentoring...
<fabbione> yes
<fabbione> is he active?
<jbailey> He's active.  carstenh, we were chatting this morning.
<fabbione> ah ok
<jbailey> on #ubuntu-devel even. =)
<zul> stupid ksh
<jbailey> zul: Can you join #ubuntu-motu for a sec?
#ubuntu-kernel 2005-07-31
<lamont__> fabbione: by morning, I expect to have a gcc-3.3 kernel to test on ia64
<dilinger> or else?
<fabbione> morning
<fabbione> lamont: ping+
<lamont> fabbione: acl
<lamont> ack, even
<lamont> my 3.3 kernel was still building away the last time I looked
<fabbione> lamont: yo.. any luck with ia64?
<fabbione> ehehe ok
<fabbione> lamont: i need some baz help
<lamont> haven't felt like checking on it this evening...
<lamont> ah, ok
<fabbione> if you have time.. otherwise don't worry
<lamont> was about to go to bed...
<fabbione> i need to branch foo and publish the branch on people...
<lamont> register a mirror (pushing), that has --listing --signed
<fabbione> is it a 2 command operation or does it need 230298 settings?
<lamont> then baz archive-mirror (or was that mirror-archive_)
<lamont> the branch and the mirror are completely separate ops
<lamont> if you just want to publish the branch, then it needs it
<lamont> 's own archive
<lamont> (since you publish archives)
<lamont> did that make any sense?
<fabbione> hmm more or less.. given that i don't even have my own archive...
<fabbione> well i can wait later today.. it's nothing extremely urgent
<fabbione> thanks lamont
<fabbione> and good night :)
<lamont> g
<lamont> g'night
<lamont> yeah - catching lifeless is probably easiest...
<lamont> or just jump into #arch and ask there
<fabbione> yeah..
<fabbione> thanks a lot :)
<zul> heylo
<fabbione> yo
<zul> how goes the battle?
<fabbione> it's going...
<zul> thats good
<zul> whats trulux pattling on about?
<fabbione> http://pearls.tuxedo-es.org/patches/security/random-pid.patch
<zul> umm...ok
<zul> uh...why?
<Mithrandir> fabbione: moo.
<fabbione> Mithrandir: pong
<Mithrandir> Xen
<fabbione> Mithrandir: i need a patch for 2.6.12
<fabbione> can you give me one?
<fabbione> Mithrandir: the Xen guy from SoC was/is MIA
<Mithrandir> not now, no.
<Mithrandir> yeah, you said.
<fabbione> there is a possility i can make the kernel side within this week
<fabbione> and you will have more time to work on userland
<fabbione> Mithrandir: how long would it take for you to grab it?
<fabbione> i don't need a dpatch
<fabbione> i need something that applies on top of 2.6.12
<fabbione> xen 2.0.6 has .11
<fabbione> that's not good enough
<fabbione> perhaps they have it in their SCM or something
<Mithrandir> they're using mercurial, which seems to be a python clone of bk.
<Mithrandir> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-unstable-src.tgz is a nightly snapshot
<Mithrandir> it appears to have something which can apply on 2.6.12
<zul> cool..im doing high-availibility stuff at work
<jbailey> But it's government, isn't it?  Do you have to do it on Tandem machines? =)
<zul> nope it isnt government its health care...so tty terminals
<zul> :)
<jbailey> Even *better* =)
* jbailey hops off a moment to swap some hardware around.
<jbailey> Much better, life should suck alot less now.
<zul> fabbione: when i get home tonight im going to go through bug reports that have needinfo in the last 30 days and if they dont have a response from the user am going to close them
<fabbione> ok thanks
<zul> did i mention im back baby!
<fabbione> i am not sure yet.. it depends on other info i don't have yet
<fabbione> ops
<zul> heh
<jbailey> zul: Spent time at a men's clinic?
<jbailey> (Do they have those ads in Ottawa?)
<zul> jbailey: no we are more civilized in ottawa ;)
#ubuntu-kernel 2006-07-24
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-5.16 uploaded, Welcome more header fixes | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<zul> hi
<kylem> morning zul.
<zul> hi kylem how goes it?
<kylem> it goes, it goes.
<zul> did you got to linux in the wild?
<kylem> no, slept in.
<kylem> :)
<zul> hehe..
<Kamion> zul: otavio asked me to nudge you about grub
<zul> Kamion: yeah its on my todo list
<zul> xen is a horrible bitch goddess
<makx> infinity: jbailey merged initramfs-tools 2 weeks ago, do you wana do a follow-up :)
<makx> infinity: add 2.6.18 drivers and small fixes all over the place
<makx> infinity: 0.71b is latest
<zul> http://www.kroah.com/log/linux/ols_2006_keynote.html
<johanbr> Hi. As I mentioned in the channel yesterday, kernel.org kernels do not build in Edgy, due to problems with the stack smashing protection. Against which package should the bug be filed? gcc-4.1 ?
<zul> linux-source-2.6.17 but it might not get fixed but it would be nice to reference it
<johanbr> Are you sure that's the right package? Since I got the kernel from kernel.org, I don't quite see what linux-source has to do with it. Does the Ubuntu kernel not compile either?
<zul> yes it compiles with -fno-stack-prtoector turned off
<crimsun> meaning it compiles with -fno-stack-protector, johanbr.
<crimsun> johanbr: so filing a bug against linux-source-2.6.17 is valid, and while it may not be fixed, it'll be a reference point as zul mentioned.
<johanbr> Okay, will do. I'm trying to compile 2.6.18-rc2 and I have this in the kernel Makefile:  "CFLAGS          += $(call cc-option, -fno-stack-protector-all,  -fno-stack-protector)", but it doesn't seem to help.
<crimsun> erm
<crimsun> adjust HOSTCFLAGS
<crimsun> according to my $COLUMNS, it's line 210
<crimsun> also CFLAGS, which is line 359
<johanbr> Alright, I'll give that a try and see if it helps. Thanks.
<Keybuk> that's a weird one
<Keybuk> this kernel didn't appear in menu.lst
<cjb> It's a bug.  Thought it was fixed in latest edgy, though.
<Keybuk> it could have been fixed since yesterday
<Keybuk> me
<Keybuk> h
<Keybuk> I cannot find a "clean" way of doing this upgrade without causing initramfs-tools to depend on udev
<zul> hey
<Keybuk> hihi
<zul> hey Keybuk how is it going?
<Keybuk> well
<Keybuk> yourself?
<zul> good
<crimsun> Keybuk: Is usbfs not mounted by default in Edgy?
<Keybuk> crimsun: no, I'm weening everyone off it
<Keybuk> use /dev/bus/usb
<crimsun> all right, thanks.
<Keybuk> I enabled it for the dapper release, but disabled it again immediately after
#ubuntu-kernel 2006-07-25
<crimsun> ah, that would explain why this firmware is loaded in Dapper whereas I have to wait a tick before hotplugging the sound device in Edgy
<crimsun> I'll just have to fix the loader then
<zul> Keybuk: is it possible to remove xen-3.0.2+hg9697-1 from the archive?
<Keybuk> zul: the particular version?
<Keybuk> when a package is removed ... it can't come back
<zul> Keybuk: yes that version, i have a new one to be uploaded that works for edgy
<Keybuk> just upload the new version then
<Keybuk> it'll supersede the old one
<zul> im keeping getting rejects sayint that new version is older than the one in the archive
<Keybuk> right, what version are you uploading?
<zul> gimme a sec
<Keybuk> I only see xen 2.0.6-1 in the archive
<zul> trxen-3.0_3.0.2+20060724_source.upload
<zul> sorry...
<zul> xen-3.0_3.0.2+20060724_source.upload
<Keybuk> right
<Keybuk> that version is older than the one in the archive
<zul> hmm...ok
<Keybuk> 3.0.2+20060724 < 3.0.2+hg9697-1
<Keybuk> because "+" < "+hg"
<Keybuk> why the change in version number?  why not use the +hgNNNN format again?
<zul> ah ok...so should it be 3.0.2-20060724?
<Keybuk> no
<Keybuk> it should be 3.0.2+hg(number bigger than 9697)-1
<zul> so 3.0.2+hg11127-1
<Keybuk> right
<zul> ok ill do that
<zul> thanks
<Keybuk> 11127 > 9697 ... so you win
<Keybuk> unless you have a very good reason, stick to the version numbering in the archive
<Keybuk> even if you disagree with it
<zul> ok
<lifeless> Keybuk: around ?
<Keybuk> lifeless: yup
<lifeless> can you eyeball this quickly -
<lifeless> https://launchpad.net/products/launchpad/+bug/53698
<lifeless> its a discussion about a change to dyson, it tried to register a cvs snapshot of grass
<lifeless> which failed the upstream version number format check. But more interestingly, cvs snapshots are not that interesting, so we're considering how to get it to not register that
<Keybuk> lifeless: it's more of a single e-mail than a discussion
<lifeless> I'd just like your thoughts on it
<Keybuk> don't really have any
<lifeless> ok, fair enough.
<Keybuk> I agree that it doesn't make sense to import cvs snapshots
<zul> hi
<crimsun> Keybuk: RE: the mount-by-UUID conversion: Does it handle [read-only]  NTFS mounts?
<Keybuk> why wouldn't it?
<crimsun> well, it appears to have correctly converted it, but I'm uncertain about the actual writing of the UUID
<crimsun> for reference:
<crimsun> # /dev/sda1 -- converted during upgrade to edgy
<crimsun> UUID=58E475CEE475AEBE /media/sda1 ntfs umask=022,nls=utf8,users 0 0
<crimsun> but /media/sda1 is empty after a reboot
<Kamion> doesn't look like a proper UUID
<crimsun> hmm, true, the others are of the form '11f6ccb2-f5bd-4d3b-87cc-c6fe260023fd'
<crimsun> so that incorrect UUID is from ``/sbin/vol_id -u /dev/sda1''
<Keybuk> Kamion: that's what NTFS uuids seem to look like
<Keybuk> quest scott% ls /dev/disk/by-uuid
<Keybuk> 2b4dde85-714c-42fa-b43f-02af9c64dc4b@  7d074f9a-80e7-4f0c-89aa-8efa8366766a@
<Keybuk> 43DB-3ADE@                             C84C0C3A4C0C25B2@
<Keybuk> of course, vol_id could be on the cock, but it shouldn't matter given things just convert to /dev/disk/by-uuid anyway
<Keybuk> crimsun: does "mount" claim it's mounted?
<crimsun> Keybuk: no
<Keybuk> of course, the interesting thing is whether mount can support those uuids :)
<Keybuk>  * For now, only ext2, ext3, xfs, ocfs, ocfs2, reiserfs, swap are supported
<Keybuk> "no"
<crimsun> right, "no such partition found"
<Keybuk> http://lists.opensuse.org/archive/opensuse-commit/2006-Jun/0412.html
* Keybuk looks at that patch
<Keybuk> lamont: how much would you hurt me?
<mjg59> No jfs?
<lamont> Keybuk: what is that adding?
<Keybuk> lamont: it replaces mount's current "find the uuid" code with calls to libvolume_id
<Keybuk> (well it's got the code to do that in it, anyway)
<lamont> if the patch is reasonably clean, and libvolume_id is reasonable sane (rather than full of festering security vuls), I'd be happy to include it in debian, too.  Then again, I need to corner you sometime and figure out what the right answer is for my debian-issue that you were able to just smash through when you last branched util-linux for dapper....
<lamont> of course, assuming that it works with the existing stuff as well, rather than forcing user changes.... :-)
<Keybuk> what's the debian issue?
<lamont> hwclock.sh
<Keybuk> oh, which one?
<Keybuk> hwclock.sh is a zillion issues all to itself
<lamont> we need to set the clock before we load the modules so that we can mount /usr so that we can get the TZ to set the clock.
<Keybuk> that's not entirely true
<Keybuk> you need to set the clock before you run depmod
<Keybuk> not "load the modules"
<lamont> right
<lamont> and actually, modules startup doesn't run depmod anymore
<lamont> (the bug in question is the front of the #debian-devel topic...)
<lamont> 342887\
<Keybuk> yeah. it's amazing how Debian stop arguing once Ubuntu has gone ahead and changed it anyway
<lamont> yep
<Keybuk> so hwclock.sh is an annoying case:
<Keybuk> it DOES need to run before dhclient
<lamont> it helped that someone else was doing bootchart type stuff and discoverd that depmod takes _FOREVER_
<Keybuk> yet needs /dev/rtc, which udev creates
<Keybuk> heh, we noticed that 6 months ago!
<lamont> yep
<lamont> I think debian noticed that it took much longer to boot debian than ubuntu....
<Keybuk> it takes less time to boot a clean debian than ubuntu
<Keybuk> because they support less crazy fabbione shit
<Keybuk> (yay, edgy's dropped it all)
<lamont> yeah fabbione! :-0)
<lamont> the simple solution to the /dev/rtc thing is to quit compiling it as a module... if the hardware is there, you want it.
<Keybuk> yes
<fabbione> Keybuk: we can do that too.. install lvm and raid stuff only on demand.. we just never did it :)
<lamont> fabbione: fix that. kthxbye
<lamont> (CONFIG_RTC that is)
<fabbione> lamont: what arch?
<lamont> arch: any
<fabbione> how do you want it? M or Y or just fix the driver?
<fabbione> the latter i accept patches :)
<lamont> it's an architecture independant fact that I need the RTC available before we do stuff.
<lamont> =Y
<lamont> it's very tiny, you see....
<fabbione> lamont: ok i will talk to Ben and Kamion
<fabbione> yup
<fabbione> but CONFIG_RTC is not available on all arches as it is iirc
<lamont> oh, well, just on the architectures where there is something that (uniquely) provides /dev/rtc
<fabbione> i will look at it
<lamont> better yet - just change Kconfig to force it on when it can. :-)
<fabbione> ehehe
<lamont> oh, that'll probably be an ABI bump, of course...
<fabbione> no big deal on edgy
<lamont> of course, I want it in etch
<lamont> and edgy. :-)
<fabbione> etch i can't do nothing.. file  a bug on those kernel guys
<fabbione> but there will be people objecting to it for another 398398439 reasons
<Kamion> there are some arches where there are multiple possible providers of /dev/rtc, aren't there?
<Kamion> so you might have to deal with the problem anyway :(
<fabbione> Kamion: i am not sure..
<Kamion> hmm, there's a whole drivers/rtc/ tree now with rtc-dev.ko and stuff, so maybe that's been fixed
<fabbione> i think Al Viro was working on a generic rtc implementation across all arches
<fabbione> or there was at least
<fabbione> no idea if it's fixed in .17
<fabbione> we can always do it the old good way
<lamont> Keybuk: if the volume_id patch looks sane, pls file a bug against the debian util-linux package with a pointer, and I'll merge it in
<Keybuk> lamont: hmm, looking through the code, mount is using libblkid
<lamont> yes
<lamont> and before that, it used it's own random guessing techniques
<fabbione> except the code in libblkid is a copy or almost of the one in util-linux :)
<lamont> fabbione: not my problem :-)
<mjg59> Keybuk: http://lkml.org/lkml/2006/7/25/280 ?
<Keybuk> mjg59: interesting
#ubuntu-kernel 2006-07-26
<zul> hey
<Mithrandir> Keybuk: rewriting fstab for evms devices == not a good idea.
<Keybuk> -v
<Kamion> probably similar to bug 54002
<Mithrandir> Keybuk: changing /dev/evms/* entries in fstab to UUID entries breaks stuff since the system then tries to access /dev/evms/.nodes/lvm/[...]  rather than /dev/evms/name
<Keybuk> is that a mount bug?
<Mithrandir> fsck + mount at least.
<Keybuk> right, both use libblkid, no?
<Mithrandir> looks like fsck.ext3 does at least.
<Keybuk> so it could be a difference between libblkid and libvolume_id?
<Mithrandir> or libvolume_id could have gotten the "cannot open" error and gone on its merry way.
<Keybuk> hmm?
<Mithrandir> : tfheen@golem ~ > LANG=C sudo fsck.ext3 UUID=e956b7b4-6ebf-4bd4-98ac-ffa52eb26028
<Mithrandir> e2fsck 1.39 (29-May-2006)
<Mithrandir> fsck.ext3: Device or resource busy while trying to open /dev/evms/.nodes/lvm/lvm0/home0
<Mithrandir> Filesystem mounted or opened exclusively by another program?
<Mithrandir> well, I gotta run now.
<Keybuk> right, but why's it looking there?
* Keybuk doesn't know anything about any of the fabbione filesystems
<Mithrandir> "it" being?
<Keybuk> fsck.ext3, apparently
<Keybuk> I suspect this is a libblkid problem
<Mithrandir> because the block device is exposed there too.
<Mithrandir> quite possibly.
<Keybuk> it's not mapping UUID=* to evms volumes correctly
<Keybuk> what does /dev/disk/by-uuid/e956b7b4-6ebf-4bd4-98ac-ffa52eb26028 point to?
<Mithrandir> well, technically it's available with the .nodes/lvm name too, but that's just for internal consumption by evms, AIUI.
<Mithrandir> unsure, the machine is on the other side of a firewall now.
<Kamion> Keybuk: oh, speaking of, has anyone mentioned this problem yet?
<Kamion> $ sudo blkid -t UUID=424fb11b-b062-4c5b-83bc-6ffd84c17ae7
<Kamion> /dev/hda3: LABEL="debian" UUID="424fb11b-b062-4c5b-83bc-6ffd84c17ae7" SEC_TYPE="ext2" TYPE="ext3"
<Kamion> /dev/evms/hda2: LABEL="debian" UUID="424fb11b-b062-4c5b-83bc-6ffd84c17ae7" SEC_TYPE="ext2" TYPE="ext3"
<Keybuk> nope, what's the problem there?
<Kamion> I have a feeling that that's deliberate on EVMS' part, although I'm not sure
<Kamion> the problem is that I don't use EVMS
<Kamion> (although I have it installed)
<Kamion> and apparently (ogra says) fresh reboots cause the /dev/evms/* one to be picked and mounted
<Keybuk> they appear to be the same block device?
<Keybuk> what does /dev/disk/by-uuid/424fb11b-b062-4c5b-83bc-6ffd84c17ae7 point to?
<Kamion> ../../hda3
<Kamion> they're not actually the same block device (3,3 vs. 253,1) although the underlying contents are probably the same
<Kamion> (note, I haven't upgraded to new udev yet or rebooted since the fstab transition or anything; if you need that, talk to ogra)
<Keybuk> really, we need someone who understands EVMS, LVM, software RAID, etc.  and is actually co-operative and willing to fix it themselves instead of just bitch all the time
<Mithrandir> I could conceivably do it, except I'm leaving for a couple of week of vacation from Friday.
<Keybuk> *nods*
<Keybuk> my general feeling with this stuff is that 95% of people haven't even noticed the conversion taking place
<Keybuk> so we're good to move on to the other boot loaders, and play with kernel modules
<Keybuk> and the silly exotic filesystems can be fixed after feature freeze :p
<Mithrandir> yeah, in most cases it seems to have gone over fine.  I'm a bit worried about LVM + EVMS and other similar cases.
<Mithrandir> evms isn't a filesystem. :-P
<Keybuk> ntfs/fat/vfat is unhappy also
<Keybuk> that's because vol_id supports uuid from those filesystems, so the conversion goes ahead
<Keybuk> but blkid doesn't, so mount can't actually use them
<Mithrandir> that should be a SMOP to fix, shouldn't it?
<Keybuk> where P=Stealing the patch to make mount just use libvolume_id from SuSE
<Mithrandir> why did udev NIH libblkid, really?
<Keybuk> I suspect the original vol_id author didn't know about blkid
<Keybuk> it's kinda hidden inside e2fsprogs
<Keybuk> and then got more people involved, so vol_id is sufficiently better than blkid that it's got used by udev
* Mithrandir nods
<fuoco> i use dapper, and i need some new things found in newer kernels like 2.6.17. what is the best way to get that? manually compile my kernel, or cam i find a kernel image for these versions somewhere ?
<BenC> fuoco: easiest way is to use edgy
<fuoco> BenC: but i lose stability...
<BenC> fuoco: them's the breaks...you lose stability if you compile your own kernel too :)
<BenC> you can always do a partial upgrade of just the kernel and its dependencies, which is pretty small
<fuoco> BenC: true, but it's different if only my kernel is 'unstable' (2.6.17 not necessarily less stable than 2.6.15 + it fixes crashes for me)
<fuoco> BenC: like take only the kernel from edgy ?
<BenC> edit /etc/apt/sources.list, s/dapper/edgy/; sudo apt-get update; sudo apt-get install linux-386 (or 686, or whatever kernel you use)
<fuoco> what if i just get a .deb from the kernels-daily url in the topic ?
<fuoco> can it not cause problems to mix parts from edgy and dapper ?
<BenC> the one in the url above wont installe
<BenC> because it depends on things from edgy
<BenC> and the small amount of things you have to upgrade for the kernel wont cause any instabilities that I know of
<cjb> I'm doing the reverse, running edgy on a dapper kernel, and it's fine.
<BenC> if you don't upgrade the things the kernel needs, you might not even boot
<cjb> (The edgy kernel just kicks me to a blank screen, for some reason, and haven't had time to debug.)
* BenC is off to gamble
<jbailey> BenC: =)
<jbailey> BenC: Practice, or is it tournament time already?
<makx> hmm no output from usplash after init, hmm i guess i need better drugs from lsb
<doko> BenC: http://librarian.launchpad.net/3573913/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<doko> $ dpkg -S asm/kbio.h
<doko> dpkg: *asm/kbio.h* not found.
<rodarvus> hi there
<rodarvus> any hints on why this build failure happened? -> http://librarian.launchpad.net/3573913/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<rodarvus> (just for reference) asm/kbio.h is not found. This file is included on sparc only
<zul> rodarvus: might want to talk to fabbione, otherwise it was probably missed in the lkh transition stuff
<doko> rodarvus: I already did ask :)
<crimsun> right, probably needs prodding from the linux-source side so it can be included in l-k-h
<rodarvus> doko, heh, thanks :)
<rodarvus> zul, crimsun: *nods*, thanks - I'll wait for fabbione to be online and ask him on the subject
#ubuntu-kernel 2006-07-27
<rodarvus> fabbione, ping
<fabbione> rodarvus: pong
<rodarvus> yesterday I reported (here) a ftbfs on sparc, for xorg-server
<rodarvus> do you have any hints on what I can do to fix this problem?
<rodarvus> (I can paste the conversation to you in /msn if you want)
<rodarvus>  /msg even
<fabbione> i have seen the backlog
<fabbione> it's a linux-kernel-header problem to ship that file
<fabbione> you will need to wait for BenC on monday
<fabbione> because there is also something else broken in the kernel that makes me unconfortable to upload
<rodarvus> oh, ok, no problem
<rodarvus> fabbione, thanks!
<fabbione> no problem
<zul> does anyone know what stubs-32.h is?
<djbmister> any powerpc devs here?
<jbailey> djbmister: Depends how deep you need to go with it.
<djbmister> Does anyone have any experience with the chrp systems - namely the pegasos board
<jbailey> I'm on a pegasos box right now.
<djbmister> Its a serious issue regarding the re-compile of the dapper kernel source
<djbmister> I've managed to get the edgy kernel to work, but the dapper source (2.6.15) just keeps rebooting the pegasos, very strange?
<djbmister> Have you had any of these issues?
<jbailey> Nope.  I'm running Dapper on this box right now with no troubles.
<jbailey> The only thing that differes from the norm is that I'm using a beta firmware and booting with yaboot.
<djbmister> Have you done a re-compile from source??
<jbailey> No.
<jbailey> I have generally no need to compile my own kernels.
<jbailey> And pegasos boxes are slow enough I wouldn't want to do it.
<djbmister> do you help with support for pegasos at ubuntu?
<jbailey> I'm the support manager at Canonical ;)
<djbmister> Great!
<djbmister> Well as a part time dev, there are still issues to resolve for the pegasos support - as you probably know ;-)
<djbmister> Me and Sven luther where the first few devs to get a ODW
<mjg59> Sven doesn't love us any more
<jbailey> Ah, was that before Sven went to go work there?
<mjg59> After we conspired to break Pegasos support
<djbmister> Yep
<jbailey> mjg59: Setting heads on pikes outside his door, digging a moat, filling it with blood, and the lighting all the trees around his house didn't help with that... 
<djbmister> svens ok, just got a bad temper ;-))
<mjg59> djbmister: Are we talking Pegasos I or II here?
<djbmister> Well i was there from the beginning, i still have a pegasos 1
<djbmister> eeek
<jbailey> I think all I have access to is the pegasos 2.
<djbmister> The problems im talking about are with ubuntu kernel source and pegasos 2
<jbailey> djbmister: In general, I advise people not to recompile their kernels.
<jbailey> djbmister: And the stock Dapper kernel works for me unaltered when booting from yaboot.
<Kamion> were you recompiling by means of a normal full package build on a dapper system, or some other way?
<rodarvus> hi
<rodarvus> I just got another FTBFS, apparently also due to missing stuff in l-k-h
<rodarvus> gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wall -Wall -g -O2 -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../../src -MT evdev_drv_la-evdev.lo -MD -MP -MF .deps/evdev_drv_la-evdev.Tpo -c ../../src/evdev.c  -fPIC -DPIC -o .libs/evdev_drv_la-evdev.o
<rodarvus> In file included from ../../src/evdev.c:66:
<rodarvus> ../../src/evdev.h:74:24: error: asm/bitops.h: No such file or directory
<rodarvus> ../../src/evdev.c: In function 'EvdevReadInput':
<rodarvus> ../../src/evdev.c:95: warning: format '%ld' expects type 'long int', but argument 6 has type 'unsigned int'
<rodarvus> ../../src/evdev.c: In function 'EvdevParseBits':
<rodarvus> ../../src/evdev.c:348: warning: implicit declaration of function 'set_bit'
<rodarvus> make[3] : *** [evdev_drv_la-evdev.lo]  Error 1
<rodarvus> this time, it was for xserver-xorg-input-evdev (just for reference)
<mdz> BenC: are you back?
#ubuntu-kernel 2006-07-28
<BenC> mdz: Wont be back till Saturday, but I'm available
<zul> hey
<mdz> BenC: ok, I'll talk to you then
<mdz> or monday rather
<zul> hey mdz
<mdz> zul: good day
<fabbione> Keybuk: do you happen to know if udev in edgy is broken? It seems i have lost some devices with one of the last updates...
<Keybuk> it's not broken
<Keybuk> the kernel might be, of course
<Keybuk> but there's no reason why udev would be dropping kernel events
<fabbione> hmm weird
<fabbione> yeah i see no reason except it started happening all of a sudden
<Keybuk> *shrug*
<Keybuk> udev is almost never to blame
<zul> heh..
<makx> Keybuk i've a questions for dapper initramfs-tools
<Keybuk> makx: dapper?
<makx> yes i'm facing same sort of upgrade somehow
<Keybuk> hmm?
<makx> Keybuk: mkinitramfs is adding vgchange and mdrun, but i see no boot script
<Keybuk> it's in mdadm or lvm2 ?
<makx> (conditional addition)
<Keybuk> you'll have to be more verbose
<makx> well mkinitramfs add mdrun if there is no md hook around from mdadm, but mdrun and mdadm is installed
<makx> but i see no boot script calling this mdrun
<makx> some story for vgchange
<Keybuk> BE MORE VERBOSE :)
<Keybuk> /usr/share/initramfs-tools/hooks/lvm
<Keybuk> /usr/share/initramfs-tools/scripts/local-top/lvm
<Keybuk> /usr/share/initramfs-tools/hooks/evms
<Keybuk> /usr/share/initramfs-tools/scripts/local-top/evms
<Keybuk> *shrug*
<Keybuk> it's all there
<makx> # FIXME: Remove this LVM block after Dapper releases
<makx> if [ -x /sbin/vgchange -a -d /lib/lvm-200 -a ! -f /usr/share/initramfs-tools/hoo
<makx> ks/lvm ] ; then
<makx> copy_exec /lib/lvm-200/vgchange /sbin
<makx> and so on..
<makx> but i don't see the usage inside of 0.40ubuntu32
<Keybuk> why would it be in initramfs-tools ?
<Keybuk> it's in our lvm packages
<makx> also the breezy lvm had no hooks yet
<Keybuk> I don't understand what you're going on about
<Keybuk> could you please be more verbose
<makx> i think it was done for partial upgrades
<makx>   * Conditionalise the use of lvm and md in mkinitramfs so it's a no-op if
<makx>     you don't have those packages installed, but allows for smooth upgrades
<makx>     if you have older versions that don't ship their own hooks yet.
<Keybuk> *shrug* no idea
<Keybuk> ask whoever did that change
<makx> the strange thing is that it is not accompagnied by an lvm or md script in scripts/local-top
<Keybuk> no, it wouldn't be
<Keybuk> the lvm and md script are in lvm2 and mdadm
<Keybuk> it's likely that code was supposed to be removed from mkinitramfs and never was
<makx> no it was added shortly before dapper release
<makx> so it was on purpose
<Keybuk> then it's likely to be a bug fix for something
<Keybuk> no idea what
<Keybuk> dependency ordering, maybe?
<makx> yes partial upgrade where you still have old lvm2 from breezy around
<Keybuk> right
<Keybuk> there you go then
<makx> still i miss the boot scripts of that idea, so it was only half done
<Keybuk> no
<Keybuk> the boot scripts are in lvm2
<Keybuk> I keep saying this
<Keybuk> but you keep ignoring me
<Keybuk> quest scott% dpkg -L lvm-common | grep initramfs
<Keybuk> /usr/share/initramfs-tools
<Keybuk> /usr/share/initramfs-tools/scripts
<Keybuk> /usr/share/initramfs-tools/scripts/local-top
<Keybuk> /usr/share/initramfs-tools/scripts/local-top/lvm
<Keybuk> /usr/share/initramfs-tools/hooks
<Keybuk> /usr/share/initramfs-tools/hooks/lvm
<makx> no i don't ignore you but lvm2 versioned dep is pulled in by?
<Keybuk> ubuntu-desktop
<makx> i see
<Keybuk> or probably ubuntu-standard or something
<makx> ok that explains why you didn't to care about the boot scripts
<Keybuk> in edgy, we don't install either lvm2 or mdadm by default
<makx> have no such dep on the Debian side
<Keybuk> and we made an effort in dapper to remove all the specific stuff out of initramfs-tools
<Keybuk> so it's just a "kit for making initramfses"
<makx> Keybuk: sure but you upgrade from a package that has already initramfs hooks
<makx> much easier, thanks Keybuk
<rodarvus> infinity, ping
<infinity> rodarvus: pong
<rodarvus> infinity, I'd like to blacklist build of a bunch of X.Org packages on some architectures - sometime ago I was informed I should talk to you to do this :)
<rodarvus> (sorry for asking in #ubuntu-kernel, btw - I didn't noticed before actually asking here)
<infinity> rodarvus: We don't actually have that capacity correctly in place right now.  I have an outstanding soyuz bug about it.
<rodarvus> oh, no problem, then
<infinity> rodarvus: Is it too much trouble to set the arch: line in the source? (I assume this is for the suncg drivers and such)
<rodarvus> it is set
<infinity> Right, so no big deal.  They'll fail, which is what we want.
<infinity> It wastes a few buildd cycles to get there, but not the end of the world.
<rodarvus> the "bug" is only cosmetic, actually - packages are showing as "build failed" on Soyuz, even with Arch: set on debian/control
<infinity> Yeah, no big deal.  Some day, soyuz will be fixed to do P-a-s stuff properly, like Debian, and you won't have to see that.
<rodarvus> *nods*
<rodarvus> infinity, thanks!
<mdz> one day, we'll make the Architecture line in the .dsc work correctly
<infinity> mdz: Well, it does, but that only works well for inclusive arch lines, not exclusive.
<infinity> So, in the case of a sparc-only driver (like this), Arch: sparc is fine.  In the case of sometihng that you DON'T want built on a single arch (or a few), it gets... Ugly.
<mdz> exactly
<rodarvus> infinity, apparently its failing for inclusive arch lines too
<infinity> And changing those sorts of semantics across the board in dpkg, sbuild, etc, etc gets... Interesting.
<rodarvus> (see latest build of xserver-xorg-video-i810)
<mdz> it should contain enough information for the buildds to determine whether they need to bother
<infinity> rodarvus: No, it works fine.  sbuild bombs out when it sees it.
<infinity> rodarvus: soyuz isn't looking at it, but the buildds do.
<rodarvus> infinity, oh, right - sorry
<rodarvus> I thought you were mentioning soyuz
<infinity> No, not especially.  The soyuz problem is purely cosmetic, really.  Having the buildds DTRT is what really matters.
<infinity> Catching it in soyuz first saves a bit of time, but it's not really a big deal.
<thom> uh, is http://www.kernel.org/git not actually showing any projects for anyone else?
<zul> thom: no problems here
<rodarvus> no problems here either
<thom> great, thanks. 
<freeflying|away> use edgy-alternate-amd64(today's iso), it can not install on an AMD64 Turion 64x2's notebook, after boot kernel, it hangs, and give a message like this " kernel dicrect mapping tables up to 10000000 @ 8000-8000" at the bottom of the screen
<freeflying|away> I've tried with noapic and nolapic 
<zul> well that was unpleasant
<crimsun> Fjodor: are you referring to a specific source file or the config{,s} themselves?
<Fjodor> crimsun: I assume that /usr/src/linux-source-2.6.17/include/linux/config.h (or autoconf.h, as it is) is generated on kernel build. There, I find a #undef CONFIG_D80211 (not unset, sorry)
<Fjodor> crimsun: This prevents building of rt2x00 cvs sources
<Fjodor> crimsun: as their rt2x00_compat.h #include <linux/config.h>
<crimsun> Fjodor: but CONFIG_D80211=m appears in all the i386-class configs.
<crimsun> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob;h=0da4742d94127974c29d20325fd47e6933e40da8;hb=b6e0a65ea85c03dc1512b4b13d1f24bc837a6481;f=debian/config/i386/config
<crimsun> what do the cvs snaps offer in addition?
<Fjodor> crimsun: cvs sources has their own config file, where it must be set to y
<crimsun> and other distros' kernel headers have it set?
<Fjodor> crimsun: Wouldn't know. I'm not sure other kernel trees have it at all
<Fjodor> crimsun: It is hardly stable now, and thus even less so at the time the sources where put in the kernel
<Fjodor> crimsun: All in all, any config for rt2x00 and dscape 80211 in the kernel autoconf.h will override values from rt2x00 cvs config. I am in the process of reporting this to their fora, but a specific #undef seems unnecessary, and is atm. counterproductive
<crimsun> Fjodor: I can't speak for a policy decision, sorry
<Fjodor> crimsun: inasmuch as the #undef is the result of completely unselecting rt2x00 from the kernel with cvs build in mind
<Fjodor> crimsun: Ok. You said BenC?
<crimsun> yes.
<crimsun> (he's off at a tourney atm)
<Fjodor> crimsun: Ok. I'll get back sometime then
<Fjodor> crimsun: For now, though, I'm off to bed. Thanks so far
<wesj> hi
#ubuntu-kernel 2006-07-30
<shifter> anyone about ?
<rodarvus> infinity, ping
<infinity> rodarvus: Hrm?
<rodarvus> infinity, I'm plannning to update the fglrx driver on linux-restricted-modules, but couldn't find any public download of the .tar.gz tree we use to package this driver
<rodarvus> and I've seen you were the last person to update it
<infinity> rodarvus: I'll do it on Monday.  I run fglrx on my laptop, so it's a bit of a priority for me.
<rodarvus> so, I was wondering if you know the procedure to update this driver, if via another ftp/www site, or if we just repack the default installer
<rodarvus> *nods*, ok
<infinity> rodarvus: It's also moderately tricky what we do to mangle it, and only Ben and I are privvy to that currently.
<rodarvus> :)
<infinity> (It includes a pretty sketchy license violation that we have tacit permission to make, but not public agreement)
<infinity> So, yeah.  Best to leave it to me for now.
<rodarvus> ok, thanks!
<rodarvus> infinity, also, it would be nice to at least update Depends: to xorg-server (>= 1:1.1.1)
<rodarvus> (if I read correctly, version 8.27 of the driver is for X.Org 7.1 only)
<infinity> Well, their module SHOULD support 6.9, 7.0, and 7.1
<infinity> You read incorrectly, I think.  But I'll test that theory when I build it.
<rodarvus> and how does it deals with xorg-server ABI - it just ignores whatever ABI the server provides?
<rodarvus> (just curious)
<infinity> Both the nvidia and fglrx modules adjust to the ABI (well, the ones they know about) on the fly, IIRC.
<infinity> It's all rather scary.
<rodarvus> haha :)
#ubuntu-kernel 2007-07-23
<kraut> moin
<doko> lamont, kylem: is there a kernel which has the fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32857 ?
<alesan> hi.
<alesan> we are developing a kernel driver for our device (www.ncomputing.com) it is based on alsa. we want to support ubuntu as best
<alesan> how can we know in advance when you are about to release a kernel update so that we can anticipate and create a binary that is going to work with your package?
<IntuitiveNipple> alesan: Is the driver proprietary ?
<alesan> GPL
<alesan> and yes, we could ask the lkml to include it in the main kernel, but we need some time for that (code clean-up etc etc)
<alesan> but before it gets accepted we would need a solution.
<IntuitiveNipple> If it is GPL, then submit it to Andrew Morton's -mm so it can be reviewed and tested, Ubuntu and other distributions pick up their 'extra' drivers from there based on user demand
<zul> BenC: ping ^^^
<alesan> ok but - in the meantime - isn't there any option to anticipate your releases?
<BenC> alesan: best bet is to submit the driver to use for inclusion in gutsy
<IntuitiveNipple> I think the roadmap illustrates the releases... 6 month cycles
<BenC> alesan: gutsy will be released in October, and is based on 2.6.22 kernel
<alesan> ok but there are often minor releases
<alesan> like 2.6.20-16
<BenC> alesan: if it's in our source tree, it's being built every time
<alesan> that went in 7.04 few weeks ago'
<alesan> ok
<alesan> I see
<BenC> alesan: we can't anticipate those
<BenC> the ABI bump - the -16 in the above example - is caused by changes we don't control, usually security updates
<BenC> and we don't usually drop new drivers into a stable release, like 7.04
<BenC> but we can include it in the upcoming release of gutsy now, and if it's in our tree, then you need not worry about those minors, since it'll get rebuilt everytime
<alesan> BenC, ok. very good
<BenC> alesan: I suggest checking http://kernel.ubuntu.com/, get the ubuntu-gutsy-lum git tree, and send us a request to include via kernel-team@lists.ubuntu.com
<BenC> alesan: best way is to clone the tree, get it in the build, and send a pull request to the list, otherwise, just send us a nice patch
<alesan> ok I'll talk with the driver author what he thinks is best
<alesan> ask I mean
<alesan> ok thank you very much at this point
<alesan> BenC, IntuitiveNipple maybe there is a little problem. the driver needs to upload a firmware to our PCI board that is not going to be opensource. will this constitute a problem?
<BenC> alesan: the ubuntu-gutsy-lum package already has other firmware in it, so long as we have redistribution rights, it should be ok
<IntuitiveNipple> That's rather like the Intel wifi firmware situ, it should be ok
<alesan> IntuitiveNipple, but such a thing won't help our driver to get included in the main kernel, right?
<alesan> main kernel I mean -mm first and Linus' kernel after
<BenC> alesan: it wont keep it from getting into the main kernel
<BenC> there's plenty of drivers already that need firmware
<IntuitiveNipple> alesan: see BenC's comment :)
<BenC> alesan: just make sure you're using firmware API in kernel, and not doing something silly like building the firmware into the driver via bin2hex header :)
<alesan> BenC, ok it is ok for now. thank you. and you too IntuitiveNipple 
<IntuitiveNipple> Do we have any ACPI suspend experts? I've found an issue with feisty & gutsy whereby a notebook prematurely suspends and immediately resumes in acpi_enter_cleep_state() when flushing the CPU cache, *before* the SLP_ENABLE bit is written
<IntuitiveNipple> s/cleep/sleep/
<alesan> BenC, I checked and, actually, we load our firmware with a userspace tool. the kernel module (which is only for audio) must be loaded before and needs no special firmware to be loaded, but it won't "work" until the firmware is loaded
<alesan> sorry I've been pretty confusing :)
<BenC> alesan: a firmware tool?
<BenC> alesan: so the driver doesn't request the firmware from userspace like all the other firmware-using drivers in the kernel? :)
<alesan> BenC, you know we are building up our Linux-team and some work has been done already maybe not in the best way
<BenC> alesan: ah, ok. Most likely the lkml will suggest you use the request_firmware() and related calls in the driver to handle the loading
<BenC> alesan: fits into userspace and distros much better that way
<alesan> see it like this, our device implements a kind of X-server. the audio part (for which we need the kernel driver) is "optional" and appeared later during the development process
<alesan> sorry my network went down.
<alesan> any answer to my latest message :) ?
<BenC> alesan: didn't see a last question :)
<alesan> :) well it was an attempt to explain why we don't load the firmware via a kernel call
<BenC> I'd have to see the driver/product to really understand it better, but I'll take your word for it :)
<BenC> if you're interested in getting into gutsy, the clock is ticking
<BenC> we have feature/kernel freeze coming soon, like 4 weeks or so
<alesan> ok
<alesan> thank you for the info
<BenC> no problem
<bullgard4> In  http://tinyurl.com/2vy5ul FUNCTION: acpi_evaluate_object: What is meant with "find and evaluate the given object"?
<IntuitiveNipple> bullgard4: It means that the ACPI namespace is walked to find the 'object' (aka method or device etc) and then the 'object' is executed
<bullgard4> IntuitiveNipple: Ok, thank you.
<alesan> re
<alesan> BenC, or everybody else that can help me: I have this dual-dual xeon (4 cores) machine with 4GB ram. I can only see 3GB, is standard ubuntu kernel able to get full 4GB or should I compile some 64GB kernel?
<IntuitiveNipple> alesan: Are you using 64-bit Ubuntu?
<alesan> no 32 bit for development reasons :)
<IntuitiveNipple> I think the max you'll see is about 3.2GB in that case
<alesan> really
<alesan> should I compile my own kernel then, ok
<IntuitiveNipple> I *believe* there is a way to see all the memory, I read about it some time ago, but I can't remember what it was
<alesan> only a problem with upgrades but it's ok
<IntuitiveNipple> do some Googling for "linux kernel 4GB limit"
<alesan> IntuitiveNipple, there is an optionin the kernel for 64GB support, do you mean that?
<IntuitiveNipple> see http://kerneltrap.org/node/2450
<alesan> or something that won't require a recomiplation?
<IntuitiveNipple> "The lower 3 GB of the process virtual address space is accessible as the user-space virtual addresses and the upper 1 GB space is reserved for the kernel virtual addresses."
<alesan> argh my http is broken... this router's crap it blocks http and the only thing I can do is to reset it
<mjg59> IntuitiveNipple: That's not the issue
<mjg59> That's per-process, not kernel address space
<IntuitiveNipple> yeah, the page goes on to talk about HIGHMEM though :)
<mjg59> alesan: Install the -server kernel
<IntuitiveNipple> mjg59: Hobbsee tells me you're a bit of an ACPI suspend expert - is this correct?
<mjg59> Yes
<IntuitiveNipple> Can I bend your ear on something?
<mjg59> Sure
<mjg59> (In here is good)
<IntuitiveNipple> Ok... if you want a link there's a clear concise explanation in the Ubuntu forums too
<IntuitiveNipple> Feisty and Gutsy with a sony Vaio PGC-SRX51P/B notebook, suspend goes fab but the system resumes immediately
<IntuitiveNipple> I've been debugging it and found that the call to ACPI_FLUSH_CPU_CACHE() doesn't return, and then the system is Back to C!"
<IntuitiveNipple> So i never reaches the acpi_hw_register_write() for SL_ENABLE
<IntuitiveNipple> Any ideas ?
<IntuitiveNipple> Details here: http://ubuntuforums.org/showpost.php?p=3066404&postcount=9
<mjg59> Ah., I saw this on acpi-devel
<IntuitiveNipple> you did :)
<IntuitiveNipple> I've tested it without paravirt and get the same result. It seems the ASM WBINVD causes this
<IntuitiveNipple> Right now, I'm wondering about moving the call to ACPI_FLUSH_CPU_CACHE() to before the acpi_hw_register_write() alls begin, to see if its tipping something off
<IntuitiveNipple> s/alls/calls/
<mjg59> Yeah. It's not especially obvious what's going on there.
<IntuitiveNipple> It certainly has me stumped to explain it!
<IntuitiveNipple> The acutual suspend/resume itself looks beautifully clean and perfect in the log, too
<alesan> ok sorry my cionnection was bropken.
<alesan> connection
<alesan> mjg59, I read your advice, you mean linux-image-server right?
<alesan> mjg59, am I going to miss the low-latency features in such kernel? or will I hardly notice the difference?
<arthur_kalm> Hi everyone, I'm trying to get a D-Link DWL-G122 wireless USB adapter to work with Feisty. The adapter worked perfectly in Dapper but after the upgrade to Feisty, every time I plug the D-Link into the computer all the USB ports instantly disconnect and I get the following error: http://paste.plone.org/15873. Any help would be much appreciated, thanks in advance.
<JanC> arthur_kalm: are you sure it still works with dapper (try a dapper live cd)
<arthur_kalm> JanC: well it was working with Dapper right before I did the fresh install
<JanC> the error you posted is from the USB controller saying something really bad happened  :)
<arthur_kalm> JanC: hehe true, well it only happens when the wireless adapter connected. Otherwise the USB works fine. The adapter works in windows too..
<JanC> hm, DWL-G122 sounds most likely uses a Ralink chip...
<arthur_kalm> JanC... perhaps
<JanC> do you have a multi-core CPU?
<arthur_kalm> no it's a P3
<arthur_kalm> 5 years old computer
<IntuitiveNipple> arthur_kalm: In the process of upgrading did you tinker with the insides of the PC at all? I've seen similar reports when ppl have accidentally 'nudged' something
<arthur_kalm> IntuitiveNipple: Hmmm I sure hope not... however, now that you mention it... this isn't my computer, it's actually my boss's and he brought it in from home inside a wheeled suitcase and it was bumping around a lot. Let me check that nothing is loose.
<IntuitiveNipple> that sounds like an inspired idea :)
<IntuitiveNipple> reseat everything and pull/push all wires
<arthur_kalm> hmm just checked and it looks fine.. the thing is that Dapper was working fine when he brought the computer in and we had no problems backing up his personal files
<IntuitiveNipple> it does sound strange... have you tried it with the Dapper LiveCD to be sure this is not a general problem?
<arthur_kalm> no, but it _was_ working when it came in...
<arthur_kalm> I can bring in a live CD tomorrow...
<IntuitiveNipple> If you can prove that Dapper is working, then you can investigate what changes would affect it. Have you tried the device in another PC running feisty? 
<arthur_kalm> haha, why didn't I think of that :P
<arthur_kalm> well it works fine in my computer
<IntuitiveNipple> Is it using ndiswrapper or regular Linux driver?
<IntuitiveNipple> It might be worth investigating the USB hub on the problem PC
<arthur_kalm> both do not have ndiswrapper
<IntuitiveNipple> Will another device work in the same USB port that you plug it into?
<arthur_kalm> well the USB hub works fine with an external hard drive
<arthur_kalm> yes
<IntuitiveNipple> narrowing it down nicely :)
<arthur_kalm> hehe
<arthur_kalm> but yeah lsusb shows up normally on my machine
<arthur_kalm> and I just plugged in my USB drive and it works fine
<IntuitiveNipple> When you plug in the device, are there any usb messages in kern.log before the failure?
<arthur_kalm> well it registers the USB device, and then tries to probe it, that's when it fails
<IntuitiveNipple> so the probe is suspect?
<arthur_kalm> well prism54 yes
<IntuitiveNipple> howabout if you blacklist the module and try plugging it in? that way if it doesn't kill the hub you know you've isolated where the problem is
<arthur_kalm> so blacklist prism54?
<IntuitiveNipple> yes
<arthur_kalm> let me try
<arthur_kalm> 1 second
<arthur_kalm> err
<arthur_kalm> I forgot, where do you blacklist?
<IntuitiveNipple> /etc/modprobe.d/blacklist i think
<arthur_kalm> ok
<arthur_kalm> so I added it to the blacklist and ran "modprobe prism54usb"
<arthur_kalm> I don't _have_ to restart right?
<IntuitiveNipple> is prism54usb loaded? (lsmod | grep prism)
<arthur_kalm> yes
<arthur_kalm> so I guess restart...
<IntuitiveNipple> I'd probably do a full restart so you can guarantee the system is 'clean'
<arthur_kalm> OK
<arthur_kalm> btw thank you so much for the help :)
<IntuitiveNipple> np... I'm sat here twiddling my thumbs building various kernels :)
<JanC> prism54 != Ralink
<arthur_kalm> IntuitiveNipple: hehe
<IntuitiveNipple> JanC: You saying arthur has the wrong driver?
<JanC> but I found DWL-G122 revision 2 & 3 being Ralink, maybe revision 1 (which I didn't found anything about) was prism54...
<JanC> stupid hardware manufacturers 
<arthur_kalm> JanC: hehe, well I'm using Version A2, 1.02
<IntuitiveNipple> ahhh... I see... arthur, you'd best check the details ! you might be working with the wrong driver
<IntuitiveNipple> A2/prism according to https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported#head-603c9481d6c6288b6b674cc50132d21f6d539c53
<arthur_kalm> ok
<arthur_kalm> so it seems to be prism
<IntuitiveNipple> arthur_kalm:  *** "Also works with Feisty but you need to blacklist prism54usb driver" *****
<arthur_kalm> hahaha
<IntuitiveNipple> (from that table)
<arthur_kalm> yeah I blacklisted prism54usb and now the USB drives work
<JanC> arthur_kalm: yeah, rev. B & C (instead of 2 & 3) are Ralink
<IntuitiveNipple> arthur_kalm: Does that mean its fixed?
<arthur_kalm> JanC: haha so they work out of the box I guess. I think my girlfriend has rev B or C and they work out of the box
<JanC> arthur_kalm: if you don't have a multi-core CPU  :)
<arthur_kalm> IntuitiveNipple: to the point that it doesn't take out all the other USB devices
<IntuitiveNipple> arthur_kalm: progress indeed :)
* arthur_kalm goes to take a look whether wireless is working
<IntuitiveNipple> On another subject entirely...
<arthur_kalm> ok so the network manager doesn't recognize it...
<arthur_kalm> and no multicore :P
<IntuitiveNipple> ... does anyone know how I can do a kernel package build and have it only recompile dependencies rather than having to do a clean ?
<arthur_kalm> but it _is_ recognized by lsusb
* arthur_kalm never done a kernel compilation ;)
<IntuitiveNipple> I did some updates in the ACPI code, but the build with binary-debs only rebuilt what was in the debian/build tree, it didn't recompile the acpi changes
<IntuitiveNipple> maybe I can do an out-of-tree build and then create the kernel package in another stage?
<arthur_kalm> IntuitiveNipple: I should have looked at the wiki :P thanks so much for your help. Thanks JanC
<IntuitiveNipple> arthur_kalm: is it working now?
<arthur_kalm> IntuitiveNipple: hmm no it doesn't turn on automatically... but at least we can plug it in now
<IntuitiveNipple> ok
<arthur_kalm> which is progress already
<IntuitiveNipple> yeah
<arthur_kalm> and I gotta go home already :(
<IntuitiveNipple> "Google is your pal"
<arthur_kalm> yeah I'll look up howtos for it
<arthur_kalm> why do all the helpful people come on when I'm just about to go home? :P
<arthur_kalm> but thank you so much for the help, much appreciated
<IntuitiveNipple> your welcome
<IntuitiveNipple> ^you're^
<arthur_kalm> have a good night everyone!
#ubuntu-kernel 2007-07-24
<kraut> moin
<doko> lamont, kylem: is there a kernel which has the fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32857 ?
<Keybuk> any particular reason that CONFIG_TMPFS_POSIX_ACL=n ?
<zul> amitk: i added some more devices to the usb autosuspend blacklist as well
<zul> Keybuk: not that Im aware of
<amitk> zul: did you check _both_ my commits?
<zul> amitk: not yet..
<amitk> zul: please submit a patch against those commits. Thanks.
<zul> can drop that one ;)
<allyson> Hi, I don't know if this is the right place to ask, but I am not able to install a new module in the Ubuntu server 7.04. Everything compiles and install, but when I reboot the old module comes back. any suggetions?
<IntuitiveNipple> allyson: blacklist the 'old' module in /etc/modprobe.d/blacklist
<allyson> Hum, I think I was not clear in my question, sorry. It's an module update, not a new module.
<allyson> The old module file not even exists anymore. I don't know where it is been loaded from.
<allyson> I have just found something, maybe I have to rebuild my initrd. I'll try that.
<BenC> allee: sudo update-initramfs -u
<BenC> err, late answer
<BenC> team meeting in #ubuntu-meeting, 2 minutes
<zul> whee..
<allee> BenC: was this the answer how to add a linux-image to netboot.tar.gz content?
<BenC> allee: no, improper nick completiong, sorry
<allee> BenC: pity :)
<bdmurray> BenC: I found a kernel bug with "apm: BIOS not found" in dmesg.  Is that indicative of something wrong with the laptop?
<AnAnt> hello, how do I report problems with kernel ?
<AnAnt> what outputs should I provide ?
<ScottK> AnAnt: https://wiki.ubuntu.com/KernelTeamBugPolicies
<AnAnt> ScottK: now, what if I have a problem in booting ubuntu
<AnAnt> ScottK: ie. it freezes at the Loading device drivers stage
* ScottK is not a kernel expert.  I'd say do your best.
* ScottK looks around.
<bdmurray> Have you tried booting w/o quiet and usplash?
<bdmurray> To get more details
<AnAnt> bdmurray: yup
<AnAnt> hmmm, w/o quiet ?
<AnAnt> I'll try w/o quiet
<AnAnt> thanks
<bdmurray> Which kernel version is it?
<AnAnt> bdmurray: I tried feisty & gutsy amd64 on my laptop
<AnAnt> bdmurray: funny thing is that sometimes it works , sometimes not 
<AnAnt> bdmurray: but if acpi=off, it is more likely to work
<bdmurray> Which Gutsy CD?
<AnAnt> bdmurray: live CD
<AnAnt> bdmurray: I think it was 22/7 build
<bdmurray> Cool.
<AnAnt> ?
<AnAnt> what's cool about that ?
<bdmurray> That you are using a recent version of the CD.
<AnAnt> oh
<AnAnt> oh, the live CD worked
<AnAnt> the gutsy live CD worked, it's the installation that didn't work
<AnAnt> in feisty live didn't work
<bdmurray> What do you mean the installation didn't work?  That the install process worked but you couldn't boot or that the install process failed?
<AnAnt> bdmurray: install process worked, but couldn't boot after installation
<bdmurray> AnAnt: So getting information from the Live CD regarding your hardware would be quite useful.
<AnAnt> ah, yes
<AnAnt> ok, thanks
<AnAnt> bye
<BenC> bdmurray: no, I get that on my laptop too
<BenC> bdmurray: usually means that it's not APM, but ACPI
<BenC> which is almost always the case
<BenC> bdmurray: we've hit a threshold where it seems like there is more bug traffic for gutsy-2.6.22 than there is for feisty-2.6.20
<BenC> not sure about the actual bug numbers
<bdmurray> BenC: I think I have numbers
<bdmurray> Do you mean rate of growth?
<BenC> bdmurray: yeah, like the rate of NEW bugs
<BenC> bdmurray: I can already see that the traffic alone has increased, which seems to be a good sign that people are testing it more
<bdmurray> Yes, we talked about testing a lot at ubuntu live
<bdmurray> Or getting people interested in it.
<BenC> I just don't know if it means that we are just more active on those bugs or if it's more NEW bugs coming in :)
<bdmurray> I have text files with numbers similar to carthiks at p.u.c
<bdmurray> I haven't had a chance to graph them yet though
<bdmurray> doh, I am graphing them!
<bdmurray> http://people.ubuntu.com/~brian/testing_graphs/plots/
<BenC> lol
<bdmurray> comparing the week-open for 2.6.20 and 2.6.22 is interesting
<bdmurray> there has been a slight upswing in .22 since tribe 3
<BenC> yeah, definite spikes
<bdmurray> BenC: Does "hdc: status error: status=0x58" indicate a hardware issue or is it hard to tell?
<BenC> bdmurray: that's the usual case, but it could be driver related as well
<bdmurray> hmm, is there more triaging information to gather than the usual stuff?
<BenC> bdmurray: cases like that, just the usual, plus a request on whether it works with another kernel (feisty or something)
<bdmurray> BenC: okay, thanks
#ubuntu-kernel 2007-07-25
<Kano> hi, anybody here who creates the restricted driver package
<Kano> grep pci_module_init -Rs *
<Kano> is still there in the avm drivers, must be pci_register_driver
<Kano> also a nice addon would be: ftp://ftp.avm.de/cardware/fritzwlanusb.stick/linux/suse.10.2/fwlanusb-1.00.00.tar.gz
<Kano> and
<Kano> fxusb_cz
<Kano> which is a tiny mod of fxusb, apply just
<Kano> http://kanotix.com/files/fix/avm/fxusb_cz.patch
<Kano> and rename the binary part
<Kano> in lib dir
<Kano> rest is same as fxusb
<Kano> suse has that patch for years
<Kano> you also lack: fcpcmcia fcusb2
<infinity> You might want to mail all of this to kernel-team@lists.ubuntu.com ... I suspect no one's going to bother picking it out of their backscroll
<Kano> http://kanotix.com/files/fix/gutsy/gutsy-problems.txt
<Kano> will add more problems soon
<Kano> i dont like to write to mailinglist for every little issue , please look there, you can ask me on that server or via mail
<ScottK> Kano: File bugs.  Those get looked at.
<Kano> whats the problem to look into a text file?
<Kano> added fuse-utils now too
<infinity> Kano: The problem is with expecting people to wake up, check IRC scrollback, and notice or care that there is a text file to look at.
<mjg59> Kano: If you want this to happen, please file a bug. If it can't be tracked, it won't be done.
<infinity> Kano: The ideal would be bugs, the minimum would be to at least mail the list.  IRC is a horrible way to inform sleeping people about anything.
<ScottK> There is a workflow for how people get stuff done.  Looking at bugs in stuff they care about is in that workflow.  Reading someone's complaints on other web sites is not.
<ScottK> Kano: After I upgraded my test machine to gutsy I spent several hours filing bugs.  It's labor intensive, but gets the best results.
<Kano> i currently test only kernels recomplied on etch + kubuntu live images
<Kano> no hd install
<Kano> bye
<kraut> moin
* #ubuntu-kernel  [freenode-info]  if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
* Starting logfile irclogs/ubuntu-kernel.log
(BenC/#ubuntu-kernel) and when you say "required" just remember you really mean "required for 3d graphics"
(BenC/#ubuntu-kernel) because you can definitely use ubuntu on those cards with the free 2d xorg driver
<Kano> that package contains 3d drivers which i dont need in there. i need networkdrivers
<Kano> these usually do not change
<BenC> the flow of this conversation isn't making much sense
<BenC> first you say we need 100.x series nvidia, then you complain that you don't need them
<Kano> i dont need it packaged
<Kano> i have a script for it
<Kano> same for fglrx
<BenC> ok, then why are you complaining?
<BenC> is the few megs of disk space for a module that isn't even linked really that much of an issue?
<Kano> because these drivers make the package very huge
<BenC> 5.9M    /lib/linux-restricted-modules/2.6.22-8-generic/nvidia
<BenC> 4.8M    /lib/linux-restricted-modules/2.6.22-8-generic/nvidia_legacy
<BenC> 7.9M    /lib/linux-restricted-modules/2.6.22-8-generic/nvidia_new
<BenC> 1.1M    /lib/linux-restricted-modules/2.6.22-8-generic/fglrx/
<BenC> compressed, it's probably about half that size...it's not small, but not a problem for other people
<Kano> it is no problem for you because you dont like at add other things...
<BenC> the network drivers account for half the size of lrm
<BenC> add what other things?
<Kano> these are the most important ones. as soon as you can go online you can download the rest
<BenC> To you maybe
<BenC> the usage of the fc* drivers is very limited
<BenC> important, yes, but still very limited compared to fglrx/nvidia
<Kano> fwlan is very heavyly used
<Kano> at least in germany
<BenC> that's interesting because I don't know anyone (except you) that does use it
<BenC> see, that's what I mean by scope
<Kano> because nobody else has the hardware to try
<Kano> they dont work
<Kano> without the mentioned patch
<BenC> you want to remove nvidia/fglrx, which is used EVERYWHERE so people in germany don't have to install it
<Kano> no split it
<Kano> restricted-network + rest
<BenC> Kano: it will get installed by default anyway
<Kano> not when i can change these defaults ;)
<BenC> Look, I have no intention of splitting the package up
<Kano> ok, then add the missing ones, how about that
<BenC> you have not provided a single good reason for it
<BenC> Kano: Ok, then add the bugs to launchpad, how about that?
<BenC> we have a workflow, which revolves around this product that Canonical has spent years on, and it's called launchpad
<Kano> thats the difference to tell it to you or to add em to lauchpad?
<BenC> we use it a lot
<BenC> Kano: because I'm not going to do it right this second, and my todo list comes from bugs in launchpad
<BenC> adding a special note somewhere to check your pet problem will most likely get lost in my work flow
<BenC> Kano: all this effort you've spent here, would have been better spent just following our requests instead of actively working against them
<BenC> Hell, even Dell and Intel use launchpad exclusively for working with us
<BenC> In fact, they prefer it because they know it increases our attention and response to problems
<BenC> Kano: then there's the fact that if I say, "ok, I got your request", I may not have time to do it, and no other people on the kernel team or in the community would now about it
<BenC> if it's in launchpad, hundreds of people know about it, and chances are better one of them will do the work
<Kano> how to attach files?
<BenC> There's a link in the left panel for attachments
<IntuitiveNipple> BenC:  I can see you have other things on your mind, but could I ask a question about the kernel-build process?
<BenC> Kano: also, scrolling to the bottom, there is a "Add a comment/attachment" link
<BenC> IntuitiveNipple: that's part of this channels purpose :)
<Kano> BenC: i dont see that only
<Kano> Further information, steps to reproduce, version information, etc.:
<BenC> Kano: you have to file the bug first, then you can attach files
<IntuitiveNipple> Thanks... I'm building from git, successfully now (thanks!) but wondered if there is a way, when building a kernel-package to have the changes to source on one or two files included. Doing binary-debs seems to rebuild from a separate source-tree and doesn't pick-up source changes unless I do a clean first, which of course then means the package build takes a long time.
<IntuitiveNipple> I'm making test packages to install on another machine, so I move the generated debs to it to install
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128289
<Kano> that way or do you need more info?
<Serge378> Hello, can someone please answer my question: I am going to upgrade from an old 2.6.15 kernel to the latest 2.6 one with smp support, however the package 'coreutils' needs to be upgraded. If the new kernel does not work(for whatever reason), and I have to revert to the old kernel, would the old kernel work ok with the new andupgraded coreutils?
<BenC> IntuitiveNipple: your problem is because you are clearing the hard link in the build tree from the source tree...that's probably the fault of your editor
<BenC> IntuitiveNipple: gutsy build system is better about that since it uses the kernels O= out-of-build feature
<BenC> Serge378: wrong channel for that question
<Serge378> BenC: why is it the wrong channel? And which channel is more approptiate?
<BenC> Serge378: because this is specific to Ubuntu kernels and is specific to kernel development...your quick answer is "probably yes", but I'm not sure who to ask about it
<Serge378> ok thanks 
<BenC> Kano: in regards to via quirks, did you write this patch, and if so, have you bothered to send it to upstream linux-kernel?
<BenC> ...and if not, do you have any context on where the patch came from
<Kano> i fixed another patch, that did only apply to kernel below 2.6.20. the first patch made locsmif
<Kano> as he has that specific problem
<BenC> Kano: I wonder about patches like this that are against a 2.6.20 kernel, but not in 2.6.22 by now
<Kano> thats only the name
<Kano> it is against 2.6.20+
<IntuitiveNipple> BenC: Hmmm... I did set up an out-of-tree build directory and built to that (as per the Kernel Wiki), but the debian build scripts are an acquired art-form and I got lost trying to figure out what was required to create the linux-image/linux-header debs :) So to save time I just switched back to doing complete fresh binary-debs builds. Did I miss something obvious?
<BenC> That's not my point, my point is that it's been around, obviously more than 6 months now, and is not upstream
<Kano> it has been out for years that patch, locsmif posted it even on lkml, but noone saw it
<BenC> IntuitiveNipple: the build tree for pre-gutsy kernel builds does a hard link tree of the sources...if you use an editor on the source files that unlinks/writes, then the hard link is then broken and you are left with a modified source in your main tree, and an original source in the build tree
<IntuitiveNipple> oh i see! I've been using Anjuta to pop in and out as needed... what you've said now makes sense since the other day I noticed it alters the permissions of a shell script I was testing! Thanks for that... I'll investigate
<IntuitiveNipple> I've not done too bad - using CONCURRENCY_LEVEL an NOEXTRAS speeds things up :)
<Kano> BenC: for more info ask locsmif on that server, he is online
<BenC> Kano: the issue I have with patches like that is divergence from upstream...I don't like carrying around patches that are not going to be upstream soon (like next release)
<Kano> BenC: is the hostap-cs patch going upstream?
<BenC> what hostap-cs patch?
<Kano> the 2nd that i need, zul said he has it already?
<zul> BenC: its a hostap-cs patch that i pulled from a bug in linux-meta seems innocent enough its in my git tree right now
<Kano> http://kanotix.com/files/kernel/kernel-update-pack/source/t-sinus_111card-2.6.16.diff
<Kano> that patch works since 2.6.16
<BenC> Kano: I haven't pulled that into the Ubuntu tree yet, but it needs to go upstream as well
<zul> BenC: http://kernel.ubuntu.com/git?p=zul/ubuntu-gutsy.git;a=commit;h=d3ad468775b97d222817fc02e75aa3bd9629a093
<BenC> see, why are things like that around for basically 2 years without being pushed upstream?
<BenC> We as distros shouldn't be held accountable for pulling in all these patches...we should be getting them from usptream
<BenC> Kano: If you are as interested in these patches as you seem to be, I think your best bet in the long run is to get them upstream
<Kano> seems to be not that easy when they are just ignored, both have been posted by the original authors
<BenC> we can get them in Ubuntu, but in the long run, we risk becoming over loaded with maintaining them, and also add to the problem because people think it isn't important to get these things into the mainline kernel
<BenC> Kano: to the proper lists?
<BenC> posting to lkml is not the proper list in most cases
<Kano> to which one then
<BenC> there's a nice file called MAINTAINERS
<BenC> HOST AP DRIVER
<BenC> pkl_:      Jouni Malinen
<BenC> macd:      j@w1.fi
<BenC> lamont:      hostap@shmoo.com (subscribers-only)
<BenC> lamont:      linux-wireless@vger.kernel.org
<BenC> W:      http://hostap.epitest.fi/
<BenC> damn nick completion
<Kano> i mailed the author even years before...
<BenC> do the list
<Kano> should i report one bug for restricted modules or serveral?
<BenC> generally, email the list for the driver/subsystem and Cc lkml
<BenC> Kano: one for each instance of problem, please
<Kano> like: fix for existing avm drivers + need for others?
<BenC> Kano: for hostap, wireless-dev list may be a good Cc as well
<BenC> Kano: one per driver is good
<BenC> one bug per driver I mean, as long as it's a cohesive bug
<Kano> but it is the same package?
<BenC> in that sense, all the bugs in lrm can be lumped together
<BenC> each bug should have one task in order to complete it
<BenC> not a checklist of items to mark off
<zul> BenC: for #127461 (suspend2) should we just out and right reject it?
<IntuitiveNipple> BenC:  you're a star!! I just checked the inode # after an edit and it changes, which means I now understand the problem... many thanks!
<BenC> IntuitiveNipple: np
<IntuitiveNipple> Now to post a 'bug' report aka feature request for Anjuta!
<BenC> zul: yeah, but direct them to blueprints
<BenC> IntuitiveNipple: IMO, an editor using unlink/write is a bug...it's not a feature to make it work correctly :)
<IntuitiveNipple> BenC:  I entirely agree, but sometimes you have to be diplomatic to get things done :)
<IntuitiveNipple> I don't fancy having to fix that myself! I've got other things to do!
<BenC> IntuitiveNipple: good point
<zul> BenC: done
<BenC> zul: thanks
<zul> np
<IntuitiveNipple> BTW, for your information... I'm working extensively on/around ACPI and suspend/resume this past couple of months, and writing a new kernel driver (sony-notebook-control) that implements 100% of the Sony notebook Windows driver functionality... so if there's anything needs doing around ACPI suspend/resume let me know. On Launchpad my id is "intuitive-nipple" and my display-name (and real-name) is TJ.
<BenC> IntuitiveNipple: excellent...ACPI is one of our hotspots
<BenC> IntuitiveNipple: if you would, please, join the ubuntu-acpi team
<BenC> kernel bugs relating to it are assigned to that team
<IntuitiveNipple> BenC: ok, I'll go do that now... as a celebration that my debug-messages on resume have just given me a clue as to why the problem-PC is resuming immediately it S3 suspends :)
<IntuitiveNipple> Well, I got lost in launchpad for while there! Found it in the end though
<IntuitiveNipple> BenC: as you're the team owner, can I tax your ACPI brains on a specific issue?
<Kano> so can i put 3 drivers to one bug...
#ubuntu-kernel 2007-07-26
(ScottK/#ubuntu-kernel) That's my guess.
<ThrobbingBrain66> ok, that's done.  i also subscribed the kernel team to my bug, i dunno if that's frowned upon or not.  anything else i need to do?
<ScottK> Actually, IIRC the kernel team prefers to be assigned, not subscribed.
<ThrobbingBrain66> yeah, i figured that.  oops.
<ThrobbingBrain66> thanks for the help
<kraut> moin
<doko> please see bug 116648; did we have problems building madwifi in feisty and/or gutsy?
<Kano> BenC: added a new fetch script: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/128297
<mikepj> I have a kernel update question.  Recently I came across a blog entry noting a data corruption problem on machines with over 4Gb of memory.  This was due to a kernel bug.  I was wondering if the patch for this has been merged into the 6.06 LTS version of Ubuntu.  The blog entry is here:  http://blogs.smugmug.com/don/2007/07/25/silent-data-corruption-on-amd-servers/
<bdmurray> mikepj: one thing you could do is look for a launchpad bug linked to the kernel.org bug
<bdmurray> mikepj: I think it is safe to say it has not been merged
<bdmurray> BenC: are you familiar with that at all? it is commit cf6387daf8858bdcb3e123034ca422e8979d73f1 I think.
<BenC> bdmurray: looks to be in our gutsy tree
<bdmurray> Right I was thinking about dapper
<BenC> Sounds pretty serious, probably mark it for dapper-6.06.2 milestone and we can look at it in the next week
<BenC> really simple patch too, so definitely should be easy :)
<bdmurray> I don't think there is an lp bug yet though.  Is there a preferred way to make a new for this?
<zul> BenC: do you guys need any help for 6.06.2 from the "community" side?
<BenC> zul: basically going to need a lot of testing from anyone with the target hardware
<BenC> if you check the dapper-6.06.2 milestone tagged bugs, you can get a glimpse at what we're hoping to fix/support
<zul> ah ok im running gutsy now
<zul> url?
<bdmurray> https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2
<zul> htanks
<mikepj> sorry, I was away.  Thanks for the info.  Glad to hear the patch might make it into 6.06.2.
<bdmurray> mikepj: I submitted a bug about it but seem to have misplaced it.  It should be listed in the milestoned bugs though.
<mikepj> Yeah, I found it here:  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/128568
<mikepj> I thought it was effecting all AMD processors though.  Must have missed something in one of the other bug reports
<IntuitiveNipple> I saw a related bug in launchpad earlier searching for "iommu=soft" (2 bugs; only 1 is using >=4GB RAM) but got side-tracked checking for patches to 6.06, and there is a debian bug #404148 with fix for 2.6.18.
<bdmurray> BenC: Could you look at bug 47768?
<BenC> bdmurray: the original report appears to be an ordering problem
<BenC> bdmurray: do you know if we used UUID in dapper? I can't seem to recall, and don't have a dapper system handy
<doko> are kyle and lamont on vacation?
<BenC> doko: kyle was hung up returning from UbuntuLive
<bdmurray> kees's UsingUUID page says since Edgy
<BenC> I wonder if we should backport UUID stuff to 6.06.2
<ScottK> BenC: I have a dapper system.  Checking
<ScottK> BenC: No UUIDs in /etc/fstab.
<ScottK> It sounds invasive/risky/dangerous to backport to me.
<bdmurray> That's what I would think too - quite the "surprise"
<BenC> actually it's not dangerous at all
<BenC> we've been upgrading people to UUID since edgy
<BenC> the main purpose of 6.06.2 is for people that can't install 6.06{,.1} anyway
<ScottK> Yes, but dapper-updates will get it all too, right?
<BenC> right, but then anyone running dapper right now will eventually be pushed to UUID no matter what
<BenC> unless they want to stay with dapper forever
<ScottK> Well just 5 years.
<BenC> then they'll be pushed into the UUID upgrade then
<ScottK> Yep.
<ScottK> Exactly.
<BenC> either way, not putting it into 6.06.2 is just deferring it, not making it any less dangerous
<ScottK> At the end of a stable series, not in the middle.
<BenC> so that argument is pointless
<ScottK> I'd put it the other way around.
<BenC> ok, so we'll just leave people with no sure way to install a system because of a feature that we've tested over a year now isn't going to be backported :)
<ScottK> Deferring the upgrade puts the change where it would be expected, not where it would be unexpected (~ 20% of the way into a stable LTS baseline's life).
<BenC> same could be said for some of the things we're already doing for 6.06.2
<BenC> UUID usage is stable, it's the non-use of it that is unstable
<BenC> especially with SATA and SCSI drives
<ScottK> It seems like a significant design change to me.  If you did it and broke my LTS server, I'd be pretty annoyed.
<BenC> I mean, the upgrade is a single shell script
<BenC> and it's very well written to avoid breakage...any problems, and it leaves the fstab/menu.lst alone
* ScottK recalls helping people survive the transition during Edgy and perhaps that colors my perception.
* ScottK got burned personally, but was able to recover.
<ivoks> i wouldn't do that in LTS :/
<BenC> guess we'll just have people installing and not being able to boot then :/
<ScottK> Why?
<BenC> read bug #47768
<BenC> and maybe you'll have some context
* ScottK looks
<ivoks> people are unable to install cause of missing drivers :)
<BenC> ivoks: this is a case of people being able to install, and then not being able to boot it afterwards
<ivoks> i heard about that problem
<BenC> ScottK: so the alternate installer loads the drivers in a different order than the installed system (which is ok, because driver load order shouldn't matter and can't be enforced)
<ivoks> right
<ivoks> i2o and stuff
<BenC> as such, they install and on boot, sda becomes sdb, and sdb becomes sda
<BenC> blammo
<BenC> no, nothing to do with i2o
<BenC> this could be onboard SATA == sda, scsi controller == sdb
<BenC> load the drivers in different order, and you no longer have a bootable system
<ivoks> yes, that happend to me once
<ivoks> i upgraded to feisty then :D
<BenC> hehe
<ivoks> ok, you got my vote, since this will personaly help me in some cases
<ivoks> (not that it matters :)
<ivoks> are there plans for new version of e1000, 3w-9xxx and some IDE controlers for 6.06.2?
<BenC> e1000 I believe so, I'd have to check 3w-9xxx, but there's a good chance of it
<IntuitiveNipple> Hmmm, UUID install-and-not-boot occurs for kernel upgrades even for Feisty/Gutsy, when you've got one boot partition and 2+ root partitions on the boot disk (multiple distro's) the menu.lst UUIDs are always set to the last root partition UUID, regardless of what they were set to already. Should I post it as a bug?
<ScottK> What about using UUID for new installs and not "upgrading" something that's already working.
<ScottK> Personally, I've had a lot more trouble with the UUID transition than I've had with not having UUID.
<BenC> IntuitiveNipple: sounds like an update-grub issue
<BenC> IntuitiveNipple: not a kernel issue
<BenC> ScottK: that's possible too
<ivoks> then go with that... only for new installs
<BenC> ScottK: I can't see how anyone could not be using UUIDs to be honest
<ScottK> That would not place existing working installs at risk and so would be a lot more consistent with the LTS guarantee in my book.
<BenC> things were so broken before that
<IntuitiveNipple> BenC: I'll do some digging, if necessary post a bug against update-grub then
<ScottK> Well I'm typing this on a Dapper desktop that's never had troubles and has no UUID.
<BenC> IntuitiveNipple: just 'grub', the script is part of that package
<BenC> ScottK: and has one disk, right? :)
<ScottK> Ah.
<ivoks> ScottK: i had scsi and sata controller
<IntuitiveNipple> BenC: ok :)
<ScottK> It has two, but they're RAIDed.
<ivoks> depending on moon and sun, once scsi was sda, and in other cases sata was sda
<BenC> yeah, if the OS only sees one disk, you'd never have to concern yourself
<ScottK> Right.
<BenC> but think if you have a SATA, and boot with a USB disk plugged in
<BenC> SATA or SCSI
<ScottK> Yeah.
<BenC> it might not be a problem, but it could
<BenC> ScottK: I think you're right about the UUID upgrade part
<BenC> just leaving it for new installs is a safe bet, since it targets the people we're concerned about
<ScottK> That sounds quite sane to me.
<ScottK> You might also have it so someone that wanted to could run the upgrade script manually, just don't do it automagically.
<ScottK> If that's feasible.
<ivoks> additional complication and my guess is that no one would do that on working system
<ScottK> Yeah, but someone who has been having trouble would do that over a re-install.
<ivoks> don't fix if it isn't broken
<ScottK> That's the least important part.
<ScottK> Absolutely not.
<ivoks> well, i would love to see uuid on new installs, but i wouldn't touch running servers
<ivoks> i'm just happy cause of e1000 and probably 3w-9xxx :)
<ivoks> what about support for ICH8 IDE?
<JanC> hm, someone I know complains that grub sees his internal hard disk as hd 2 and sometimes as hd 0, depending on whether his USB disk is connected...
<JanC> AFAIK grub doesn't understand GUIDs ?
#ubuntu-kernel 2007-07-27
<BenC> zul: ping
<mikepj> Good to know about that UUID issue.  I had the same problem when installing on my server with 4 SATA disks.  Devices would switch names, etc.  Took me a few hours to figure it out and make the correct GRUB changes.
<zul> BenC: pong
<BenC> zul: xen on amd64 is failing to build...did you test it before you sent the config?
<zul> yes I did 
<zul> whats the error?
<BenC> In file included from include/linux/mm.h:40,
<BenC>                  from include/linux/suspend.h:11,                 from arch/x86_64/kernel/asm-offsets.c:12:
<BenC> include2/asm/mach-xen/asm/pgtable.h:489: error: 'ptep' undeclared here (not in a function)
<BenC> include2/asm/mach-xen/asm/pgtable.h:489: error: 'entry' undeclared here (not in a function)
<BenC> include2/asm/mach-xen/asm/pgtable.h:489: error: expected identifier or '(' before 'if'
<BenC> include2/asm/mach-xen/asm/pgtable.h:489: error: expected identifier or '(' before 'whi
<BenC> and then some more
<zul> crappers can you disable it for amd64 and send me the output
<zul> sorry timed out
<kraut> moin
<AnAnt> bdmurray: Hello
<AnAnt> bdmurray: what does "Triaged" mean ?
<AnAnt> bdmurray: you are Brian Murray, right ?
<soren> AnAnt: He is, but he's probably also very much asleep. :)
<AnAnt> soren: ok, what does "Triaged" mean ?
<soren> AnAnt: Do you mean in the traditional (medical) sense, the general Ubuntu sense or the kernel sense?
<cjwatson> AnAnt: see https://lists.ubuntu.com/archives/ubuntu-bugsquad/2007-June/000559.html and thread
<soren> AnAnt: Triaging is the process of going evaluating patients (especially after battles in war) evaluating which should be taken care of first, etc.
<soren> AnAnt: In the general Ubuntu sense, it means "This bug has been looked at, verified, and should for all practical purposes be ready to be looked at by a developer".
<AnAnt> soren: in the launchpad sense
<soren> AnAnt: The kernel team has traditionally had slightly different procedures for bug management, so I'm not entirely sure if Triaged means something slightly different when it comes to kernel bugs.
<AnAnt_> soren: thanks
<AnAnt_> sorry, I got d/c 
<AnAnt_> soren: regarding this bug: #103273
<AnAnt_> soren: I just sent that it got partially solved by setting the option pci=noacpi
<AnAnt_> soren: shall I provide any outputs (dmesg or whatever) when I passed pci=noacpi option?
<soren> AnAnt_: I have no clue.
* soren is not on the kernel team
<AnAnt_> k
<AnAnt_> anyone got a clue ?
<AnAnt_> ok, later then
<Mithrandir> how can I force a driver to bind to a device?  I have a device I believe is supported by a driver, but I'd like to test before recompiling
<infinity> You can echo the PCI ID to somewhere magic in /sys ..
<Mithrandir> it's a USB device, though
<infinity> They surely have IDs too... Of some sort. :)
<cjwatson> find /sys -name new_id
<cjwatson> you need the right syntax though
<cjwatson> which I think is just "%x %x" % (vendor, product) for USB
<cjwatson> (it's more complicated for PCI)
<abogani> What is the best tool for manage a patch series on top fo git? stgit?
<Mithrandir> hm, btsco needs the snd_bt_sco module to be loaded to be useful, but bluetooth devices aren't really plugged in like USB and such, so I don't think udev can get a uevent, reasonably.
<Mithrandir> what's a good way to make sure snd_bt_sco gets loaded?
<IntuitiveNipple> Mithrandir: I set it up so it is loaded when the --connect occurs
<Mithrandir> IntuitiveNipple: where do you set that up?
<IntuitiveNipple> I can't remember now; it was a while ago I set it up. I do recall having to trawl through a lot of Google search results until I found the correct mix of tips
<IntuitiveNipple> The problem I had after getting it set-up was many apps wouldn't easily allow the selection of the ALSA device, and therefore they would insist on using the internal sound device
<bdmurray> BenC: There is a bug a bugzilla.kernel.org that looks, uh, misplaced to me.  It is bug 7954 if you could have a peak that would be great.
<BenC> bdmurray: ok, I'll check it out
<bdmurray> BenC: It's about a MacBook Pro bug filed with Component Power-Processor which seems wrong and it should be an upstream bug of one of ours.
<bdmurray> BenC: I'm having a hard time linking a linux-source-2.6.22 bug upstream.  The LP process is a bit confusing but I think there is not an appropriate upstream project for l-s-2.6.22.
#ubuntu-kernel 2007-07-28
<defendguin> hi i just built a kernel module to test out some changes to a driver but when i modprobe the drive it still appears to be using the old one
<bdmurray> I think modprobe looks in /lib/modules you'll want insmod
<defendguin> i think i got it
<defendguin> i just copied the new .ko file over the other one
<IntuitiveNipple> usually, you do "sudo make install; sudo depmod -a; sudo modprobe <module>" assuming you unloaded the original module beforehand with "sudo modprobe -r <module>"
<lifeless> bdmurray: you finished for the day yet ?
<lifeless> kylem: ping
<bdmurray> lifeless: mostly what is up?
<lifeless> bdmurray: really a kernel team thing, I was going to draw attention to what appears to be a simple config flag fix
<lifeless> which is gaining me toos 
<lifeless> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/118303
<lifeless> and as no kernel heads were around I was pinging you as a convenient proxy :)
<bdmurray> I'll make sure it is looked at if you triage 5 other bugs. ;)
<lifeless> bdmurray: I'll do that first thing monday
<lifeless> bdmurray: thanks :)
<kraut> moin
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-9.19 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/
#ubuntu-kernel 2007-07-29
<Amaranth> Is there any way to build _just_ the rt kernel?
<Amaranth> hrm, i wonder if `AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-debs custom_flavours=rt` works
<egro> hallo
<egro> i have problem with compile kernel... I am downloaded kernel "http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.22/linux-source-2.6.22_2.6.22.orig.tar.gz" and compiled it with command " AUTOBUILD=1 fakeroot debian/rules binary-debs flavours=generic". After one hour i have 4packages > "linux-headers-2.6.22-9-generic_2.6.22-9.19_amd64.deb linux-image-2.6.22-9-generic_2.6.22-9.19_amd64.deb linux-image-debug-2.6.22-9-generic_2.6
<egro> .22-9.19_amd64.deb linux-libc-dev_2.6.22-9.19_amd64.deb" but when i install it i have problem > http://openpaste.org/sk/2553/
<egro> i need linux-headers-2.6.22-9 package...
<egro> ...sorry for my english... ;)
<egro> How i make this package???
<egro> hmm
<egro> sleep?
<kraut> moin
<egro> hmm
<egro> can you help me? :D
<egro> crrrrrrrrn, wake up
<egro> :D
#ubuntu-kernel 2008-07-21
<AnAnt_> Hello, I noticed that there are new linux-image-2.6.24-20* & linux-restricted-modules-common  packages for Hardy, yet linux-image-generic is still at version 2.6.24.19.21, is that correct ? 
<ivoks> zul: hi there
<zul> hey ivoks
<AnAnt_> Hello, I noticed that there are new linux-image-2.6.24-20* & linux-restricted-modules-common  packages for Hardy, yet linux-image-generic is still at version 2.6.24.19.21, is that correct ? 
<ivoks> it is
<AnAnt_> so I can upgrade the linux-restricted-modules-common without expecting any problems ?
<ivoks> wait for the meta package
<AnAnt_> the linux-restricted-modules-common new version is 2.6.24-20
<AnAnt_> ok, thanks
<Kano> hi BenC , do you want to keep 686 setting? k6-2/3 are only 586 and usually fast enough too
<Kano> like the hardy kernel, intrepid is 686
<BenC> Kano: 586 will probably work still
<Kano> BenC: current kernel definitely does not boot on k6-2
<Kano> due to: CONFIG_M686=y
<Kano> before it was CONFIG_M586=y
<mkrufky> is cogito available in hardy?  i dont see it in apt :-/
<bboschman> Hi
<bboschman> I'm compiling my own kernel using make-kpkg - just extracted linux-source.tar.bz2; copied /boot/config-*server .config and run make-kpkg kernel-image
<bboschman> this results in a 180MB linux-image*.deb
<bboschman> why is this so large?
<abogani> bboschman: Please don't you use the Debian way to build Ubuntu kernel: it is completely unsupported. The Ubuntu way ("fakeroot debian/rules binary-server") should be works great.
<bboschman> abogani, but I'm not sure how to make config changes the ubuntu way
<_ruben> anyone know why im seeing only 4gb of ram on a system which has 6gb? .. this is what i get in dmesg:
<_ruben> [   40.008864] Memory: 3993236k/6291456k available (2295k kernel code, 135080k reserved, 1238k data, 308k init)
<_ruben> its a dual 1st gen opteron running 64bits gutsy gibbon
<Kano> maybe wrong bios settings?
<_ruben> post shows 6gigs
<_ruben> and it does detect it, but cant use it somehow
<stgraber> _ruben: what kernel are you using ?
<_ruben> Linux vn-vm03 2.6.22-15-server #1 SMP Fri Jul 11 19:20:50 UTC 2008 x86_64 GNU/Linux
<bboschman> can I just overwrite debian/config/i386/config.server with a Full .config file?
<maks_> mkrufky: cogito is gone, use plain git
<maks_> pblumbing disappears and porcelaine of git itslef gets good!
<smb_tp_> bboschman, configs are combined config and config.server (in your case) you might want to empty one and place everything else into the other
<Blinny> bboschman: FYI, "the Ubuntu way" is described here: https://help.ubuntu.com/community/Kernel/Compile
<_ruben> most 4gb related stuff i see on google is 32bits related .. not much 64bits stuff there
<bboschman> Blinny, I know that it is described there, but not how the config files are defined (or even a own branch is set)
<bboschman> I'd like to build something like linux-image-*-preempt
<mkrufky> thanks, maks_
<_ruben> i'll try with hardy tomorrow, perhaps the hw is just too old (HP DL145 G1) to handle 4+ GB properly .. gotta go now
<bboschman> does config.server override options from config?
<smb_tp_> bboschman, AFAIK it is cat'ed together so normally it would by name sorting...
<bboschman> let's see ... :)
<rtg> zul: did you see the note on the kernel team mailing list regarding Xen: "Lates XEN Kernel do not come up"
<zul> rtg: yeah its something to do with his raid 
<zul> we didnt make any changes to the xen bits 
<rtg> zul: perhaps you could respond to him.
<zul> rtg: sure
<_ruben> lets see if upgrading to hardy fixes the 4g/6g prob
<_ruben> will see in the morning afterall .. box doesnt come up after reboot ;)
<BenC> _ruben: what 4g/6g issue do you mean?
<RAdams> I need to compile 2.6.24-19 AND 2.6.26-4.10 with acpi debugging AND tracing to track a known issue on Dell Latitude d800 and so laptops. This issue occurs in both kernels, I am certain. I am familiar with how to do this with a vanilla kernel, but I want to confirm what the most useful/correct way to do this for this Ubuntu-specific build. I would love to help finally nail down this problem and thus contribute to the improvement of Ubuntu, 
<smb_tp_> RAdams, have you already looked at https://help.ubuntu.com/community/Kernel/Compile?
<BenC> RAdams: if it occurs on vanilla kernel too, best bet is to start there
<RAdams> smb_tp_: yes. Would using the steps under "Alternate Build Method: The Old-Fashioned Debian Way" yield a good enough kernel/debugging to help trace this issue? The only way I know how to enable acpi debugging and tracing is with make menuconfig, which I apparently don't get the opportunity to do using the first method
<RAdams> benc: that would be more helpful? I can do that. But won't I have to obtain/rebuild drivers for hardware? what other changes can I expect I'll need to make to get a workable system for testing? It doesn't have to have every feature, just enough to replicate the problem
<RAdams> benc: I am not certain that the problem exists in vanilla, so the first thing I would have to do is verify that it does :o
<BenC> RAdams: cp /boot/config-`uname -r` .config
<RAdams> Also, passing acpi=off stops the problem from happening, so it's something with /proc/acpi as it's implemented into the ubuntu kernels
<BenC> RAdams: in a vanilla kernel, and start from there
<RAdams> benc: will do
<smb_tp_> RAdams, Otherwise, if you want to use the git source, you can do. For test purposes you could put you could put your config file to debian /config/<yourarch>/config and empty the config.generic there.
<RAdams> which vanilla kernel should I use? http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.26.bz2? any need to build http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.24.bz2 as well, or is the current sufficient, so the problem gets fixed upstream (if that's where the problem is)
<RAdams> I have 0 git experience, btw, so if it's best to go that route, I'll have to read up on git I suppose o.O
<smb_tp_> RAdams, You would need t know only one command "git-clone http://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git <yourdirname>"
<RAdams> smb_tp_: that will get me the current devel version of the kernel?
<smb_tp_> RAdams, Just don't ask for "mrproper" He is too clean
<smb_tp_> RAdams, Replace hardy with intrepid and you get the current intrepid tree. If you mean Linus tree with devel version, that would be a different url
<RAdams> oic
<RAdams> so the hardy one will get me the current hardy kernel in use?
<RAdams> .24-19?
<smb_tp_> RAdams, Current Hardy: yes. 24-19 no. 24-20 is somewhere rolling
<RAdams> oh
<RAdams> ok ty
<netzwurm> hi
<netzwurm> I am trying to patch the server kernel. I am confused, however. If I get linux-source-2.6.24 and copy the config from /boot/config-2.6.24-19-server to the source, the source doesn't build because arch/xen/Makefile doesn't exist. that same file is also neither in the linux-headers packages for 2.6.24-19 or 2.6.24-19-server. Is that a bug?
<netzwurm> Obviously the server-kernel is patched with xen, but how do I build that kernel? where does the patch come from?
<smb> netzwurm, You should not need that. I am not sure what you did. I just tried a "fakeroot debian/rules binary-server" and a similar out-of-tree build. both seem to run happily
<netzwurm> smb: oh. that's in the debian source package? What I am asking about is whether there is a way to build the server-kernel from within the linux-source-2.6.24/ dir.
<netzwurm> smb: you took the apt-get source linux-image-2.6.24-19-server i take it?
<smb> netzwurm, yes
<netzwurm> smb: hm. how do i add my custom patches to that then?
<netzwurm> oh. i just patch the source.
<netzwurm> whatever.
<netzwurm> thanks.
<smb> netzwurm, I would guess so. :) np
<netzwurm> smb: although that's still complicated with modifying the config.
<netzwurm> i mean, i am trying to find the patchset for the server-kernel now.
<smb> netzwurm, Practically you could replace the debian/config/<arch>/config{,.server} file(s)
<netzwurm> smb: right.
<smb> smb, Will you need to distribute a patchset later or would just getting a kernel package compiled be enough
<smb> netzwurm, Anyways, I am not sure this gets repeated too often but https://help.ubuntu.com/community/Kernel/Compile should be of help...
<netzwurm> smb: what i'd really like would be a configured kernel-source with all patches. I don't really want to build the kernel, but i need the build-source.
<netzwurm> smb: because the headers aren't enough.
<smb> netzwurm, the linux-headers-server package is not enough? maybe the missing headers from lum... but sorry I have to go. bbiab
#ubuntu-kernel 2008-07-22
<_ruben> BenC: the "4g/6g" issue that i have a box with 6G in it, of which only 4G is being seen (dual 1st gen opteron running 64bits gutsy)
<Nafallo> _ruben: just out of curiosity, how many banks and CPU-slots does that machine have? what machine is it?
<_ruben> Nafallo: 2 cpu sockets, 4 dimm slots (2 banks) per cpu socket .. HP DL145 G1 .. i removed 2G (making it 'symetric' again) because after upgrading to hardy it gave me kernel panics at boot up .. im gonna try with 8G later on
<Nafallo> hm. k.
<_ruben> 2 cpus and 2gb (2x1gb in one bank) did seem to work .. so the 'asymmetric-ness' shouldnt be a prob
 * _ruben heads to the basement to temporarily steal another 2G kit from another server
<_ruben> 8G seems to work fine .. reinstalling gutsy 
<_ruben> guess its some flaky hardware thing afterall .. will see
<apt_get> Hi
<apt_get> iproute2 have a package for kernel 2.6.26?
<maks_> in git irc apt_get 
<maks_> 01eb17a66dec4db6206fdba17b1dfed2f72f8ef3 "Update headers to 2.6.26"
<apt_get> hmmm
<apt_get> i go there
<apt_get> with this?  git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
<maks_> check it out, not spoon feeding you
<apt_get> ok
<apt_get> how u get this info from git maks_?
<maks_> git log
<saispo> no one have error when building ubuntu-hardy-lum with openvz headers ?
<soren> BenC: Er... Did I send that virtual kernel module list thing to you yet, or did I just dream that I did? Like earlier today or something?
<BenC> soren: you dreamed it I believe :)
<soren> Dang.
<soren> mutt apparantly dreamed it, too. I sent it to benc@ubuntu.com rather than the kernel-team mailing list, though.
<BenC> ah, heh
<BenC> not sure benc@ works...it would be bcollins or ben.collins
<soren> Ah.
<BenC> _ruben: If you are using a 32-bit generic kernel, you wont see past 4G
<BenC> _ruben: either use 32-bit server kernel, or a 64-bit install
<soren> _ruben: I asked _ruben about that yesterday, and he said he was running the amd64  server kernel.
<_ruben> BenC: upgrading to 8GB 'fixed' it
<_ruben> must be some flakey hardware thing
<soren> sounds like fun :)
<_ruben> soren: virtual kernel module list .. ehh .. oh .. my request for the driver to be included?
<_ruben> HP DL145 G1 is ancient stuff ;)
<soren> _ruben: No, that's completely unrelated.
<_ruben> soren: doh .. for some reason i thought you addressed it to me
 * _ruben goes out to buy glasses
<soren> _ruben: Two seperate, but interwoven conversations. IRC is fun :)
<_ruben> add some interwoven braincells and double the fun :)
<soren> BenC: Do you want me to resend to you or the mailing list?
<_ruben> and regarding my tulip driver request (-virtual kernel), that probably aint happen before intrepid i guess, if ever? ;)
<soren> It'll be in Intrepid, at least.
<soren> It's not out of the question to add it to Hardy in an SRU, is it? BenC?
<_ruben> soren: ic
<amitk> soren: let's make it three. did you have a chance to look at my git tree?
<soren> amitk: Yes. I'm not going to use it. :)
<soren> amitk: BenC would rather go in an entirely different direction.
<rtg> soren: its possible to enable tulip for the virtual flavours
<soren> rtg: ok, cool. I think we should, then. Apparantly, that's what Microsoft's virtualisation thingie emulates.
<rtg> soren: for just the -virtual flavour, correct?
<rtg> I thinks its already enabled for others.
<_ruben> rtg: it is, for -server atleast that i know
<_ruben> havent tested any other flavours
<_ruben> should look into which hardware hyper-v's accelerated nic uses .. its the legacy nic that uses the tulip driver
<_ruben> the accelerated one is some 10Gbps thingie
<amitk> soren: and what is this other direction? I don't want to end up doing something just for lpia
<soren> amitk: He wants to take the server build and just "cherry pick" the modules from that and stitch it together to form a new .deb.
<amitk> soren: hmm. That isnt useful for lpia
<soren> amitk: No, not at all.
<soren> I imagine, though, that your lpia work will be useful for all the other ports.
<mkrufky> when do i need to submit drivers for intrepid?  
<mkrufky> er, i mean... "by when do i ..."
<mkrufky> i ask, because i am waiting for the last moment -- i'd prefer to send in the driver AFTER the kernel janitors do their cleanups in the -rc phase
<amitk> mkrufky: beta freeze is 25th Sept: https://wiki.ubuntu.com/IntrepidReleaseSchedule
<mkrufky> oh, then i have time... :-)   thanks, amitk
<amitk> mkrufky: there is _never_ enough time :)
<mkrufky> ;-)
<rtg> soren: bug #250857
<soren> rtg: Oh, cool. Thanks. It's for HyperV, though, but apart from that..
<rtg> soren: oh well, no one else knows the difference :)
<soren> Heh :)
<_ruben> heheh
<BenC> Ok....kernel IRC meeting...
<BenC> amitk, rtg, smb_tp: You guys awake and lucid?
<rtg> huh? what?
<smb_tp> partially
<BenC> I don't have many topics for a meeting other than "Go fix bugs"
<smb_tp> Me neither
<amitk> BenC: ack
<BenC> Anyone have anything they want announce, discuss, complain about?
<BenC> amitk: wasn't the same without you and cking at the sprint last week...we'll all have to make up for it at UDS
<rtg> BenC: maybe the plumber's conf instead of UDS
<BenC> ah, good idea
<kylem> BenC, why are you guys doing UDS so late this year?
<BenC> kylem: to avoid thanksgiving
<rtg> kylem: when Jane says jump, we all ask "Where should I land?"
<kylem> BenC, oh right, your allhands thing.
<amitk> BenC: my feelings exactly...
<BenC> kylem: no allhands this year...I think it was put off until May after UDS
<kylem> ah.
 * BenC is glad they avoided thanksgiving
<BenC> would have killed attendance in the US...and since we will be in the US, that's pretty important :)
<kylem> wild turkey and a bucket of kfc?
<amitk> kylem: still based in Ottawa?
<kylem> amitk, aye. how goes dude?
<BenC> kylem: you should make UDS...call it "public relations" :)
<amitk> kylem: good going. Perhaps you'll run into some of our folks at OLS this week.
<kylem> BenC, maybe... escaping snow for mountain view is tempting.
<kylem> amitk, yeah, tony espy is here at least.
<rtg> kylem: track down Colin King and Stefan Bader and introduce yourself.
<amitk> kylem: you saw him at the wireless mini-summit then?
<kylem> i'm here now, yeah.
 * BenC loves how this digressed into a kylem reunion :)
<smb_tp> will be there this evening. any pub to meet. :)
<kylem> sorry. ;-)
<BenC> kylem: it's ok, gave us something to talk about :)
 * BenC has nothing to talk about and needs lunch now
<smb_tp> Ok, enjoy. :)
 * amitk needs dinner. So long folks...
<tormod> hi, should l-u-m bugs now be filed against "linux" ? I don't see any l-u-m-2.6.26 on launchpad.
<rtg> tormod: yep, LUM was sucked back into the Intrepid kernel package.
<tormod> so we should move all l-u-m-2.6.24 bugs to "linux" ?
<tormod> all that applies in Intrepid, that is
<tormod> rtg, now that I've got you here :)  what about the prism2_usb/linux-wlan-ng updates?
<rtg> actually, I'm surprised ogasawara hasn't already done that.
<rtg> tormod: it was unclear if I needed to do more. it functions for Intrepid, correct?
<tormod> rtg, the prism2/p80211 just got back into the kernel, but they are from February and needs updating.
<ogasawara> rtg, tormod: moving lum bugs to linux is on my todo list
<rtg> tormod: I deal with too many versions of the kernel. Which one are you referring to?
<tormod> rtg, and the linux-wlan-ng 0.2.9 has a pending merge.
<tormod> the normal intrepid kernel?
<rtg> Intrepid is 2.6.26
<tormod> rtg, yes
<rtg> tormod: so there are 2 issues? 1) the wireless drivers in kernel need updating, 2) user space needs an update. correct?
<tormod> rtg correct!
<tormod> bugs 192772 and 245026 
<rtg> tormod: for the kernel drivers, please post a patch to the kernel team mailing list. kernel-team@lists.ubuntu.com, and either Ben or myself will pick it up.
<tormod> rtg, last time you just pulled down from upstream
 * tormod just reassigned 245026 to "linux"
<tormod> rtg as described in BOM
<rtg> tormod: one moment. spousal interrupt.
<tormod> NMI
<alex_joni> heh
<rtg> tormod: Intrepid is a little different. have the prism2/p80211 drivers been submitted during the 2.6.27 merge window?
<rtg> Intrepid is different in that we are not yet backporting upstream wireless.
<tormod> I am not sure if I understand. But prism2/p80211 is not part of the linux kernel.
<rtg> tormod: right. I forgot that.
<rtg> tormod: it looks like BenC copied the  prism2/p80211 Hardy LUM drivers into the Intrepid kernel package at ubuntu/misc/wireless. It would help me out if you could submit patches against the Intrepid package that updates those drivers.
<tormod> rtg, hmm I don't have a kernel tree here to diff against.
<tormod> hd space issue. can I get a subtree from git?
<rtg> tormod: not as far as I know
<tormod> how much space does the whole git tree need?
<rtg> rtg@dearborn:/usr3/ubuntu$ du -sh ubuntu-intrepid
<rtg> 634M	ubuntu-intrepid
<rtg> seems like a lot.
<tormod> can you give a tarball of the u/m/wireless tree?
<tormod> it seems like BenC rearranged the directory structure quite a bit...
<_ruben> i guess a 'bug' like this (http://bugzilla.kernel.org/show_bug.cgi?id=10424), cant be easily worked around other than patching the kernel right? :/
<infinity> rtg: Does that new -proposed kernel include the hppa fix?
<rtg> infinity: ought to.
<rtg> _ruben: needs kernel source code change to fix SATA
<infinity> rtg: Mmmkay.
<rtg> infinity: has it actually built yet?
<infinity> Nope, but the hppa buildds were blocked over the weekend.  Let me smack it.
<_ruben> rtg: guess i'll work around it hardware wise then ;)
<noelferreira> any solution for this bug: https://bugs.launchpad.net/linux/+bug/124406
<noelferreira> ?
<noelferreira> any solution for this bug: https://bugs.launchpad.net/linux/+bug/124406
#ubuntu-kernel 2008-07-23
<joumetal> 2.6.24-20-generic from hardy-proposed doesn't boot. 24-20-386 and 24-19-generic both boot well.
<soren> "doesn't boot" is not quite enough information to fix anything.
<joumetal> Boot freezes and last line is Checking 'hlt' instruction... OK. Only way to restart is power button. Magic sys rq doesn't work
<joumetal> Next message in working boot is  Freeing SMP alternatives: 0k freed
<aib_> my system is experiencing a High Priority kernel panic https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/21481
<aib_> its been high pri for 3 years because canonical never had a system experiencing it to debug
<aib_> i contacted the bug owner bug no reply. i know its only been a day but this is my workstation
<rtg> pgraner, BenC: uploaded linux-restricted-modules_2.6.26-4.10 w/Broadcom 5.10.27
<pgraner> rtg: great I'll get it in one sec
<rtg> pgraner: uh, you might have to wait until its actually built.
<rtg> pgraner: watch for it here: https://edge.launchpad.net/ubuntu/+source/linux-restricted-modules
<pgraner> rtg: thats what I get for not fully reading.... I'm between irc windows
<AMDpenguin> will they backport 2.6.26 to hardy?
<ln-> why would they do that?
<AMDpenguin> more drivers?
#ubuntu-kernel 2008-07-24
<bboschman> Hi
<bboschman> I get the following error while kernelcompile:
<bboschman> http://paste.debian.net/12712/
<bboschman> the only I changed was debian/changelog (new version) and CONFIG_VERSION_SIGNATURE
<alex_joni> bboschman: what's the command you used?
<bboschman> alex_joni, CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-server
<soren> I see you moved the virtio drivers into a seperate udeb, and marked it priority: extra.. Is the latter deliberate?
<johanbr> Is timg around? He's marked bug #183033 as "fix committed" for intrepid, which I don't think it is.
<BenC> soren: it is...we don't want all those modules being forced in lowmem netboots
<soren> I can think of modules that are much more ripe for a move to extra than virtio. virtio will actually be used. :)
<BenC> soren: but if it's forced to be loaded on lowmem systems, it makes the lowmem install useless :)
<soren> AFAICS, it's only virtio and crypto that are extra, while *everything* else is there by default.
<soren> Or am I reading too much into the priority of the udebs?
<BenC> I can change the extra setting if you want, I just need it in a separate udeb
<BenC> I think you are reading too much into it
<soren> Ok.
<soren> What I'm seeing is that the virtio_pci and virtio_ring modules were missing in the installer.
<soren> d-i failed to find my nic.
<soren> Truth be told, I didn't spend *that* much time on it, but it just seemed to me that the only difference between now and back when it worked was that virtio_ring and virtio_pci were moved to a udev with priority: extra.
<soren> ...and it just so happens that the only two udebs marked as extra are crypto and virtio.
<orangepeelbeef> guys how do i build the git linux-modules in hardy it keeps saying it needs the source for 2.6.24-21 but the latest package in the repo is 2.6.24-19
<orangepeelbeef> how do i retrieve a specific version from the git kernel repository
<baron1984> what kernel release is the 2.6.26-4 kernel in Intrepid using?
<amitk> baron1984: 2.6.26
<baron1984> final?
<baron1984> will the backports for ACPI in the Linus git tree be backported into Intrepid?
<amitk> baron1984: 2.6.26 final + cherry picked patches from 2.6.27-rcX is the plan
<erle-> suspend to ram broken since last kernel update in hardy 64 bit
<erle-> anybody who can confirm that?
<baron1984> suspend to RAM just doesn't work in ANY Linux kernel for me
<amitk> baron1984: what are the backports for ACPI?
<baron1984> it does in 2.6.26-4 on Intrepid
<baron1984> but when I reboot
<baron1984> it freezes
<erle-> kernel panic comes up
<baron1984> just before it restarts
<erle-> suspend works with kernel 2.6.24-19
<baron1984> I've filed a bug on it
<baron1984> [patch] acpi: fix crash in core ACPI code, triggered by CONFIG_ACPI_PCI_SLOT=y
<baron1984> may fix this?
<baron1984> bug 251338
<baron1984> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/251338
<baron1984> the initial report was for Hardy
<baron1984> but I redid the dumps with 2.6.26-4 on Intrepid
<amitk> baron1984: I am not sure what your situation is - Is the intrepid kernel a regression from Hardy?
<baron1984> amitk: No, in fact it's a large improvement, ACPI has gone from hardly working at all to working "more"
<baron1984> it crashes on reboot after having suspended
<baron1984> I've asked Foxconn what their problem is
<baron1984> they told me to go buy Vista
<baron1984> well, after several layers of "support"
<mkrufky> sounds like fighting words to me
<mkrufky> or like a mystical curse
<mkrufky> who "buys vista" ?
<baron1984> telling me to yank out my RAM modules and see if the problem continues?
<mkrufky> never install vista on an old machine!
<amitk> baron1984: so what are you looking to be backported? and from where?
<baron1984> oh, I have Vista, it's an OEM copy
<baron1984> and this motherboard is a replacement
<mkrufky> it makes sense to run vista on a NEW machine that COMES with it installed
<mkrufky> (if you absolutely must)
<baron1984> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246222
<baron1984> I think this may fix the problem? 
<amitk> baron1984: that bug only enables custom DSDTs. Do you have one for your board?
<baron1984> I'm sure I could come up with one
<baron1984> there was a Gentoo guide on how to do it
<baron1984> http://www.lesswatts.org/projects/acpi/overridingDSDT.php
<baron1984> that may work
<baron1984> but only when the patch that allows it lands
<baron1984> unless I want to futz about with a custom kernel on an Alpha distribution
<baron1984> (I really don't)
<baron1984> amitk: If I understand this correctly
<baron1984> I'd build the DSDT, and just place it into /boot?
<amitk> baron1984: you could give it a try when the next kernel is available. The git commits have already landed. I just checked
<amitk> baron1984: correct
<baron1984> amitk: How exactly would I fix the DSDT I have?
<baron1984> I do not know assembler
<amitk> baron1984: there is a lot of documentation around to fix DSDT, but you should start by looking if someone has already posted something for your board at http://acpi.sourceforge.net/dsdt/view.php
<amitk> http://acpi.sourceforge.net/dsdt/index.php
<baron1984> amitk: should I upload my disassembled dsdl in to Launchpad?
<baron1984> or would this not be kosher?
<baron1984> amitk
<baron1984> looks like it probes to find out what Windows it's using
<baron1984> and if it doesn't find one, it falls back to NT 4
<amitk> baron1984: that is usually the beginning of DSDT problems - customization of behaviour for differnt windows versions :)
<baron1984> If (MCTH (_OS, "Linux"))
<baron1984>   Store (0x03, OSVR)
<baron1984> peculiar
<baron1984> it doesn't do that setting for any Windows version
<baron1984> it gets better
<amitk> baron1984: it is unlikely that anybody will be able to help with a particular DSDT. You are on your own there because it is so HW specific. But the acpi list is a good place to ask for help.
<baron1984> there is no package 0x03
<baron1984> only 0x04
<baron1984> you figure recompiling it telling it to detect Linux and use Windows Vista's DSDT package would help?
<baron1984> B-)
<amitk> baron1984: as a rule of thumb, from the ACPI maintainer - they try to be bug-compliant with Windows for the ACPI implementation. And they keep pleading to BIOS vendors not to do different things for different OSes.
<baron1984> amitk: This is sabotage
<baron1984> plain and simple
<baron1984> there's no other explanation for telling Linux to use different DSDL table
<baron1984> amitk: I recompiled it and got 7 warnings
<baron1984>  Acquire (MUTE, 0x03E8)
<baron1984> Warning  1103 -                                 ^ Possible operator timeout is ignored
<baron1984> oh hell no
<baron1984> I know what they did
<baron1984> they gave a bogus table just for Linix
<baron1984> *Linux
<baron1984> that they know will break it
<baron1984> clever bastards
<baron1984> http://ubuntuforums.org/showthread.php?p=5451708#post5451708
<BenC> soren: ping
<soren> BenC: Oui?
<BenC> soren: in zinc:~bcollins/ is the test virtual package
<soren> BenC: i386?
<BenC> soren: amd64
<soren> Whee!
<soren> My favourite :)
<BenC> soren: I can do 32-bit later if needed
<BenC> soren: NOTE: it's based on -server build, so uname looks like -server and everything is installed as 2.6.26-4-server, and it conflicts with the -server image
<BenC> soren: I don't see that as a problem really, but just so ya know
<soren> BenC: I'm curious how you'll pull of building an amd64 kernel for i386, though. You said you'd use the same approach, right?
<soren> s/of/off/
<BenC> soren: I have no intention of doing that
<soren> Oh, ok.
<soren> You did mention a similar use case for this approach in Boston, didn't you?
<BenC> Perhaps, but I can't recall what it is
#ubuntu-kernel 2008-07-25
<hwilde> do the kernel wireless modules attempt to associate to any open network on boot?
<hwilde> coworker observed it on the client  "I was running iwconfig every second. It shows the free wifi at that point, but by the time everything is loaded we are on the correct ssid. "
<hwilde> orion caught the snmp trap    apf_policy.c:538 APF-1-DISCONECT_MOBILE_DUE_TO_WLAN_SWITCH: Disconnecting mobile 00:16:6f:b4:0d:68 due to switch of WLANs from 4 to 6
<hwilde> running 8.04 server with no network manager
<hwilde> correct ssid in /etc/network/interfaces with WEP key, boots up and authenticates fine, but flickers to public free wifi on boot?
<hwilde> Intel 2200bg mini-pci card,   modules ipw2200, ieee80211 
<baron1984> I've uncovered a ploy between Foxconn and Microsoft
<baron1984> Microsoft has apparently gotten Foxconn to write bad DSDT tables just to pass to Linux
<baron1984> while Windows gets the valid ones
<baron1984> when I override the DSDT with my custom version, it fixes most ACPI related problems
<baron1984> and I think kernel 2.6.26+ my DSDT table would fix it completely
<hwilde> I have crappi ACPI problems
<hwilde> how do you get a custom version
<baron1984> they have their BIOS set to pass Linux a bogus DSDT table, I changed it so it passes Linux the same one it gives Windows XP/Vista
<baron1984> you have to pull your DSDT table, disassemble it, rewrite sections of it yourself
<hwilde> ok how
<hwilde> gimme
<baron1984> recompile it, and make a boot image set to use that
<hwilde> do you have any links or resources confirming any of this
<baron1984> it varies depending on your BIOS
<baron1984> I can't just give you mine
<hwilde> how would I find mine hten
<hwilde> "pull your DSDT table"    how 
<hwilde> and how does the bios know if its linux or windows
<hwilde> sounds bogus
<baron1984> hwilde: The tables are passed to the OS
<baron1984> which runs it as a program
<baron1984> it's in assembler language and OS independent
<baron1984> it then initializes it's ACPI implementation based on what the BIOS gave it
<baron1984`> are there currently many known, non-acpi related problems, regarding a hang on rebooting right after the "Will Now Reboot" message?
<baron1984`> this seems to affect hardy and intrepid, but only after you have used suspend in that session
<johanbr> rtg: You marked bug #183033 as "fix committed" for Intrepid. Are you sure that's right? I couldn't find the patch in the git tree, and it's definitely not in 2.6.26-4.11-generic.
<elmo>  /go soren 
<soren> elmo: ?
<elmo> soren: nothing, I wasn't talking to you - (mis)leading space and tab completion gone mad (nick vs. channel)
<soren> elmo: Oh :)
<rtg> johanbr: looks to me like its in Intrepid, at least the patch that was attached by Mario is in Intrepid.
<johanbr> rtg: Really? 2.6.26-4.11-generic shows the same "one core stuck at max frequency after resume" behaviour that the early hardy kernels had.
<rtg> johanbr: look at the code. as far as I can tell, that patch has been applied.
<johanbr> rtg: I don't have a complete dev environment on the machine I'm using right now, but I don't see the patch when browsing the git logs. And if it's there, it doesn't seem to have any effect. Anyway, I'll have a closer look over the weekend.
<johanbr> rtg: I just had a look and I don't think the patch has been applied.
<johanbr> I'm comparing http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=8a8edfd73da81c311e15ffba945a7b8eeb7f992f (the patch) with http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=blob;f=drivers/acpi/executer/exconfig.c;h=39d7421905840f1437c5408d2e4fe47e31f8b68d;hb=HEAD
<johanbr> If you look at the latter link around line 324, it's pretty clear that the patch is not there.
<rtg> johanbr: hmm, it appears that you are correct. I'll see about getting this one upstream.
<rtg> johnin the meantime I'll get it applied to Intrepid.
<rtg> johanbr: damn tab completion.
<johanbr> rtg: Great. Thank you.
<johanbr> rtg: Oh, and there's an upstream bug at http://bugzilla.kernel.org/show_bug.cgi?id=10734
<joumetal> Could patches in bug 249135 be related to bug 251344?
<joumetal> latest -generic and -rt kernels in hardy are affected. Any intrepid kernel is not affected.
<joumetal> seems that many users are willing to help but they have no ideas but add me too comments.
<rtg> joumetal: looks like a possibility. I'll contact the author to see what he thinks.
#ubuntu-kernel 2008-07-26
<pwnguin> well thats an unfortunate blowup regarding foxconn
<AlmightyCthulhu> I'm in contact with Foxconn's Chinese headquarters
<AlmightyCthulhu> they say that even after applying my ACPI mods, some types of RAM are freezing the kernel
<AlmightyCthulhu> this does not happen in Windows
<pwnguin> well, i meant more the instant reaction and villification of foxconn
<baron1984> I just got off the phone with Foxconn
<baron1984> They called me at 1 AM (here) from China
<baron1984> and were asking me to help them with Linux support for their BIOS
<pwnguin> heh
<pwnguin> if you feel out of your league, just give them canonical's email
<pwnguin> or url
<pwnguin> they have an OEM vendor cert thing
<pwnguin> http://ubuntu-virginia.ubuntuforums.org/showpost.php?p=5459641&postcount=120
<pwnguin> baron1984: ^ was that a joke?
<baron1984> no
<baron1984> they actually called me
<baron1984> from Shenzen, China
<pwnguin> the other part
<pwnguin> teh s3kr3t me55ag3
<baron1984> the part about them sending me a fixed BIOS ROM?
<baron1984> oh, hehehehe
<baron1984> yeah
<baron1984> that was a joke
<pwnguin> sorry, that thread is just so chock full of accusations, vitrol and hate that I can't take anything at face value =(
<pwnguin> it seems very un Ubuntu what transpired there
<baron1984> what, they gave out a sabotaged BIOS
<baron1984> when they get massively and publicly called out on it
<pwnguin> its not very collaborative, productive or respectful
<baron1984> they go from buy vista screw yourself, to "how can we help?"
<pwnguin> granted, they might not have treated you with respect
<pwnguin> i think you would have been better off writing an open letter to the acpi folks
<AlmightyCthulhu> it's not Intel's fault
<pwnguin> intel doesnt run acpi
<pwnguin> and acpi owns the acpi trademarks
<AlmightyCthulhu> they have a reference implementation of how ACPI should work
<AlmightyCthulhu> and a compiler that validly compiles the BIOS code
<pwnguin> if someone's claiming "acpi compliance" ACPI probably had a hand involved in it
<AlmightyCthulhu> so why are they passing the completely busted  and incorrect Linux table
<AlmightyCthulhu> when even Vista's works better?
<pwnguin> for the same reason we ship busted software in 8.04
<AlmightyCthulhu> they never had any intention to fix it
<pwnguin> shit happens, and what isn't a priority slips through the cracks
<AlmightyCthulhu> and wouldn't have, unless it broke Vista or XP
<pwnguin> clearly they had no intention, but it seems unfair to accuse them of fraud
<AlmightyCthulhu> in any event
<AlmightyCthulhu> they admitted it was an invalid implementation
<AlmightyCthulhu> written by unskilled programmers
<pwnguin> (well duh)
<AlmightyCthulhu> which makes it non compliant, even if it wasn't their intention
<pwnguin> do you know who the acpi sig secretary is?
<AlmightyCthulhu> probably Microsoft
<pwnguin> bingo
<AlmightyCthulhu> probably signs off on bad BIOS implementations
<AlmightyCthulhu> just to bite Linux users
<pwnguin> at any rate, mjg59 thinks the point is moot since newer kernels masquerade as windows
<AlmightyCthulhu> then my mod shouldn't do anything
<pwnguin> you two might talk
<AlmightyCthulhu> but it does
<pwnguin> newer kernels
<pwnguin> what are you using?
<AlmightyCthulhu> 2.6.26?
<AlmightyCthulhu> :P
<AlmightyCthulhu> Linux ryan-desktop 2.6.26-4-generic #1 SMP Mon Jul 14 18:39:36 UTC 2008 x86_64 GNU/Linux
<pwnguin> http://mjg59.livejournal.com/94560.html contains comments from some fairly influential and intelligent people
<pwnguin> you two might talk and compare notes. its part of the CoC after all ;)
<pwnguin> at any rate, im goin to bed, what i know about dsdt and acpi wouldn't amount to a plate of beans
<pwnguin> oh, and I'd love to see a way of keeping up to date on progress via this. now that you brought it up and made it a huge deal, it would be terrible to see it wasted =(
<pwnguin> ubuntu-kernel has a fairly low volume ML that might be appropriate, I donno.
<ceeka1> i'm getting a kernel oops on ubuntu 7.04. i have set up kdump and crash so i'm able to see where the error occurred... appears to be in line 717 of skbuff.h (skb_dequeue which is inlined into process_backlog) anyone have suggestions where i could start on figuring out what could be going wrong? the machine it crashes on just sits on my network at the office
<Nafallo> BenC: ping 3945B :-)
<BenC> Nafallo: yes, was there a fix?
<BenC> Nafallo: I don't really have a test rig
<Nafallo> BenC: ah. should I look for someone that has one or just go with the obscurity of my findings this far in a bugreport? :-)
<BenC> Nafallo: I have a 3945 card, just no B network to connect to
<Nafallo> yea. same here at the moment :-)
<Nafallo> hmm... I should try setting my linksys in B only mode...
<Nafallo> not now though. I need my internets :-)
<smb_tp> :q
<holycow> hi guys
<holycow> i have a fujitsu u810 umpc.  everything works great but this thing has a set of keyboard led lights id like to learn how toturn off or on.  i guess ill haveto blearn how to write drivers.  what sorts of techniques should i be looking at when trying to discover how these leds afre turned on?
<holycow> lspci  doesnt szeem to show anything that looks like it controls the leds
<pwnguin> arent keyboard leds kinda controlled by the keyboard?
<pwnguin> i dont think you'd need a PCI slot for that
<holycow> not this one, i think its driver controlled but i didnt get windows with it to check
<pwnguin> well theres still a driver
<pwnguin> its just not PCI
<holycow> its two leds on a ledge above the kb starngely
<holycow> and i dont see a switch for them ... everything is in japanese
<holycow> heh
<pwnguin> there's a kernel LED module i think
<pwnguin> clever
<holycow> oh!
<pwnguin> im not sure what it controls, or if its sort of a generic interface for all things that have leds
<pwnguin> at any rate, there's also Xkb
<holycow> aha, googling
<BenC> holycow: usually things like that hang off the parallel port IO range (or similar IO ranges)
<BenC> and they are usually poorly documented, requiring IO sniffing in windows to reverse engineer
<BenC> or decompiling the windows driver to find out the write/read combos used to control it
<holycow> aha!
<BenC> holycow: is this keyboard on a USB bus?
<BenC> if so, not integrating the led's is a very poor design :)
<holycow> lol i dont know, im just starting my journey
<pwnguin> holycow: lsusb is a complimantary tool that might help answer that without logic analyzers and taking the device apart ;)
<holycow> actually i doubt it
<pwnguin> you'd be surprised
<holycow> oh right forgot about that
<pwnguin> sometimes the quest to reduce costs means integrating several functions into a single chip / bus
<pwnguin> even though its more expensive
<BenC> pwnguin: I'd be surprised if they hung keyboard led's off a usb bus and not have them hardware integrated into the keyboard itself
<pwnguin> true
<BenC> actually, I'm surprised they aren't already
<holycow> i have a touch screen and a finger scanner on the usb bus
<BenC> holycow: are these caps/num lock led's or something else?
<holycow> no led controller of any kind ... makes sense
<holycow> oh something elese
<holycow> they are additional leds on little raisers to light the kb at night
<holycow> its a umpc fujitsu u810
<BenC> oh, keyboard backlight
<holycow> thats it!
<BenC> most likely low level IO type things
<holycow> that sounds right
<holycow> your original suggestion is probable the right approach
<BenC> under windows does it change the keyboard backlight based on ambient lighting in the room?
<BenC> or is it manual control?
<holycow> manual
<BenC> might be good to email fujitsu to see if they are willing to cough up specs
<holycow> fgqrtyu-=
<holycow> oops sorry
<holycow> BenC: indeedy, will do
<pwnguin> BenC: i saw your talk on hardware whoring
<holycow> thx for the heads up
<BenC> pwnguin: hehe
<pwnguin> i thought it was kinda wierd, because it didnt mention how developers can get in touch with the right people
<BenC> damn innanet
<pwnguin> it was basically all "when vendors call you"
<BenC> pwnguin: I've never had to go that route
<BenC> pwnguin: and doing so is usually different (and difficult) depending on the company you are talking about
<pwnguin> apparently if you call the FTC and claim they're committing fraud they get you in touch with people
<BenC> pwnguin: good starting points are linux-kernel@vger.kernel.org archives to find out if an engineer from that company has already come out
<BenC> and similar places...websites are good places too, but always hard to find something other than customer support
<pwnguin> i guess what i'm saying is it might be a good idea to give people ideas on constructively contacting the right people
<pwnguin> but thanks for the tips
<BenC> true, but it wasn't an area where I had experience, so I neglected to mention anything :)
<pwnguin> if you're invited to give the talk again, i might suggest pointing out the deficiency as a way of starting a dialog at the end of the talk :)
<holycow> slowly windowsonly hardware is starting to lessen tho
<BenC> pwnguin: good idea, thanks for the feedback
<pwnguin> sure
<holycow> hopefully vendors will buildintotheirproduct cycles better community interaction
<pwnguin> doubtful
<pwnguin> product cycles dont fit into neat six month releases
<holycow> well i dont meant ubuntu community specifically, just thinking more generically
<pwnguin> intel hired some smart people to deal with that, but i think we'll quickly see a "peak keithp" similar to "peak oil"
<holycow> heh
<holycow> bbl low on battery powr
<holycow> thx for the help btw
<pwnguin> BenC: is there a better resource for toshiba than that website?
<BenC> holycow: np
<BenC> pwnguin: Don't know off hand
#ubuntu-kernel 2008-07-27
<emgent> BenC: please see Bug #244990
#ubuntu-kernel 2009-07-20
<NCommander> apw, do you still need to forward the SPARC patches? (it hit the queue, but I didn't get the bounce until I took off for the weekend)
<cooloney> ericm, Jaunty 2.6.28 kernel already merged that patch?
<cooloney> ericm,  do you know the SHA of the commit?
<ericm> cooloney: please check arch/x86/kernel/cpu/intel.c: line 39
<ericm> cooloney: seems to be merged via the stable tree
<cooloney> ericm, that is OK
<ericm> the change is brought up by the fix
<cooloney> ericm, we can change the status to Fixed in Release
<cooloney> ericm, cool
<ericm> cooloney: now your turn ;-)
<cooloney> ericm, ok, no problem. 
<cooloney> ericm, thanks for taking a look at this
<ericm> cooloney: you are welcome, bro
<kdub> hello everyone
<apw> kdub, hi
 * apw pokes apw_
<smb> apw, talking to yourself again. :-P
 * apw_ waves to cking 
<apw> heh yeah ... just got wireless working
 * Keybuk tries to figure out TRACE_EVENT
<rtg_> amitk, are you accumulating all of the Karmic  ARM patches from the list? 
<Keybuk> rtg_: remind me, is there an easy way to build an i386 kernel on an amd64?
<rtg_> Keybuk, other then using a chroot? not that I know of.
<Keybuk> that's what I thought
<Keybuk> let's see if this works
<Keybuk> I've rewritten the old sreadahead ftrace-based open() patch
<Keybuk> it now uses TRACE_EVENT
<Keybuk> I'm hoping it'll be much easier to get upstream like that ;-)
<Keybuk> (assuming that the syscall tracer stuff doesn't make it)
<Keybuk> ooh, it compiled :D
<rtg_> Keybuk, is anyone championing the syscall tracer stuff ?
<Keybuk> no idea
<rtg_> Keybuk, couldn't get it in Andrew's tree?
<Keybuk> who couldn't/
 * Keybuk doesn't follow LKML remember
<Keybuk> I only have 24 hours in one day
<Keybuk> last I heard about the syscall tracer stuff, Ingo had said he though it was the right thing to do
<rtg_> Keybuk, he's also another avenue for getting a patch like that accepted.
<Keybuk> (the syscall tracer stuff not being my work :p)
<rtg_> oh, I thought it was. I get so confused.
<Keybuk> :)
<Keybuk> in jaunty we have a patch in our kernel tree which adds a trace for the open() syscall using ftrace
<Keybuk> that patch doesn't apply in karmic, so I've rewritten it to use TRACE_EVENT
<Keybuk> we'll obviously want to include that in our tree if it works
<Keybuk> and I'll forward it upstream as well
<rtg_> ok
<Keybuk> but I'm mindful that there's separate work upstream to provide a generic all-syscall tracer using tracepoints, which would supercede it anyway
<rtg_> its probably time to get it into Karmic 'cause whatever happens upstream won't appear (for us) until LL
<Keybuk> but at least, by implementing it on top of trace_event, it'll be compatible :P
<Keybuk> right, I only wrote it today :)
<Keybuk> am doing the test compile now <g>
<rtg_> slacker
<Keybuk> hah
<Keybuk> hmm, didn't quite work
<Keybuk> oh, no, I just didn't copy a file over
<Keybuk> hmm, no I didn't
 * Keybuk is clearly missing some glue
<Keybuk> how do I ignore ABI changes again?
<Keybuk> oh, I just fix the changelog entry, that's right
<rtg_> Keybuk, you can also 'echo 1 > debian/abi/2.6.31*/ignore'
<rtg_> rather, 'echo 1 > debian/abi/2.6.31*/ARCH/ignore'
<Keybuk> btw, is it me or is the kernel package missing build-deps these days?
<Keybuk> neither kernel-wedge nor makedumpfile are in its deps
<rtg_> Keybuk, hmm
<rtg_> Keybuk, Build-Depends: debhelper (>= 3), module-init-tools, kernel-wedge (>= 2.24ubuntu1), makedumpfile [amd64 i386 lpia], device-tree-compiler [powerpc]
<Keybuk> rtg_: ah, but debian/control is an empty file
<Keybuk> that's what breaks it
<rtg_> debian/rules clean
<Keybuk> so deps work from the source but not from git?
<Keybuk> rtg_: clean depends on kernel-wedge <g>
<rtg_> Keybuk, debian/control is generated
<rtg_> Keybuk, the source package has a correct debian/control, but not the bits that are checked out from git
<Keybuk> yeah
<Keybuk> Could not open /home/scott/co/linux-karmic/debian/linux-image-2.6.31-4-generic/lib/modules/2.6.31-4-generic/modules.alias at debian/tests/check-aliases line 10.
<Keybuk> weird
<Keybuk> probably an issue with changing the version part way though the build ;)
<rtg_> Keybuk, likely. you're better off using an ignore file.
<Keybuk> wildo
<amitk> rtg_: I am (collecting all the ARM-related patches, that is). They are at git://kernel.ubuntu.com/amitk/ubuntu-fsl-2.6.31.git
<rtg_> amitk, shouldn't we have an official topic branch in the Karmic repo?
<bjf> rtg_, we are using a topic branch named "arm" in the Jaunty tree
<Keybuk> # grep open /sys/kernel/debug/tracing/available_events
<Keybuk> ADMIRAL!  THERE BE TRACERS HERE!
<Keybuk> \o/
<Keybuk> # tail trace
<Keybuk>   tail-2176  [001]    58.986011: do_sys_open: "/etc/ld.so.cache" 0 0
<Keybuk>   tail-2176  [001]    58.986054: do_sys_open: "/lib/tls/i686/cmov/libc.so.6" 0 260045
<Keybuk>   tail-2176  [001]    58.986149: do_sys_open: "/dev/urandom" 0 26776604320
<Keybuk> yay
<Keybuk> not sure why the junk at the end, admittedly
<Keybuk> ah, random mode when opening without O_CREAT of course
<Keybuk> rtg_: incoming patch for you
<rtg_> Keybuk, cool.
<apw> jjohansen, did we decide that we were happy to enable apparmour now, as the ecryptfs issue was already in jaunty and the static IP addy thing there was going to be a work around in the definition
<jjohansen> apw: nope, but I think it is worth doing
<apw> i think it was a patch for that functonality wasn't it.  we should get that up onto the mailing list for inclusion
<jjohansen> apw: yeah, it adds a config option to set a default security module
<apw> cool.  so lets get that up soon and i can get it tested in my ppa
<jjohansen> apw: okay, I will commit and push
<apw> sounds good
<jjohansen> apw: request sent
<apw> jjohansen, thanks
<rtg_> apw, any erason why CONFIG_SSB and CONFIG_B44 shouldn't be common across all arches/flavours?
<apw> probabally not ... shall i sort them out as i have been doing that merging?
<apw> and i am about to do an AA config option too :)
<rtg_> apw, I've already got that committed locally and am build testing.
<apw> ahh ok ...
<rtg_> the CONFIG_SSB/CONFIG_B44 patch (I mean)
<apw> let me know when you have it pushed so i can work from the top of that on the next config thing
<apw> they tend to collide like a pig
<rtg_> k, about 30 minutes.
<rtg_> I'm also getting Keybuk strace patch
<rtg_> er, trace event patch
<apw> sounds good to me
<smb> rtg_, apw Probably the only risk is for bcmwl but jockey can sort that
<apw> smb, whats that risk?
<rtg_> smb, its already built for the distro arches anyway. so jockey already has to handle it.
<apw> oh i see having it turned on you mean
<apw> yeah its arm which is mostly the one which isn't common
<smb> apw, ssb has the tendency to grab all ssb capable devices (not necessarily only those it has backends for)
<apw> ahh i see
<smb> apw, So the wl driver wont work until you remove ssb (plus those using it) then modprobe wl and the again all the others
<smb> which is the modprobe rule jockey instals
<apw> ahh hence when i installel the wl thing i had to reboot to get it to work
<smb> or remove b44+ssb then modprobe wl and probe the other like I did 
<smb> exactly
<rtg_> apw, karmic pushed
<rtg_> Keybuk, what would be a good package for an rfkill application? its needed for acpi-support. perhaps wireless-tools ?
<Keybuk> yeah something like that
<rtg_> Keybuk, so, just drop it in and send a patch to the debian maintainer?
<Keybuk> yup
<NCommander> apw, you around? (I'm guessing my SPARC config patch never materialized on the mailing list since i don't see it in history)
<apw> not seen it no
<apw> if you want to send it again and cc: me then i can follow up on it
<NCommander> apw, *sigh*, ok, I have a copy here
<apw> these things happen
<apw> i assume its not huge?
<NCommander> apw, not too big
<NCommander> apw, forwarded. If it fails to apply, then we've got a problem; my home router has failed, and I can't access my SPARC box remotely (and unless my super can restart the router which is a longshot), I probably won't be able to fix the problem until I return to Rochester in ~3 weeks
<apw> lets hope it applies
<NCommander> apw, yeah .... I can try working on faure if it doesn't, but I obviously won't be able to test the results :-/
<NCommander> O_O;;;;  http://news.slashdot.org/story/09/07/20/1643251/Microsoft-Releases-Linux-Device-Drivers-As-GPL?art_pos=4
<apw> well sparc wasn't building last i looked 
 * NCommander feels its a very very cold day in hell ...
<apw> its an odd move, lets hope its the open move we would want it to be
<NCommander> Indeed
<NCommander> But still, Microsoft committing kernel patches ...
<apw> i like the chosen tags
<NCommander> Next thing you'll know, Apple is going to dump Darwin and move to a LInux base
<apw> heh ... that really would imply flying pigs
<apw> NCommander, you are in luck it applied
<NCommander> \ooooooooo/!
<NCommander> That makes me feel better
<apw> as it only can affect the ports its pretty safe
<apw> (for me)
<NCommander> My issue w.r.t. to the new layout of debian/config is one config change breaks all other pending config patches
<NCommander> But on the flip side, its nicer to see what is common to all architectures ...
<apw> yes and no, not as much as you might think
<apw> your change is an issue as its a big mother
<apw> and changes a lot of the file
 * NCommander notes the ports configs are very very unhappy in general as it stands
<NCommander> Well, until now
<apw> but there was an apparmor related changed between your change being diffed and applied by me
<apw> and they didn't collide
<NCommander> Thats a nice warm fuzzy feeling
<apw> the ones where you do what you did there, take an arch from BUST to WORKING
<apw> is going to run that risk, but generally we change one option at a time and the collisions are managable
<apw> i am also sure this isn't the last improvement to config management in my lifetime either
<NCommander> Well, it just needed one big change to make everything happy
<NCommander> I'm kinda wondering how the configs got this broken though, I thought I fixed all the -ports configs in the jaunty cycle :-/
<apw> cannot say, perhaps the wrong ones got pulled to karmic when they merged into the kernel package not sure
<NCommander> possibly
<NCommander> Oh well, fixed now
<apw> heres hoping ... 
<manjo> dinh, did u get a chance to repond to amits question regarding the USB patch ? 
<rtg_> apw, I figured out where NCommander's patch went. I'd forgotten to moderate the list this morning.
<apw> rtg_, ahh did wonder ... it looked benign to us so i have applied it
 * NCommander doesn't understand why he keeps hitting the moderation queue
<NCommander> I'm subscribed, and @ubuntu.com addresses should be whitelisted
<apw> maybe the size limit is very small
<rtg_> apw, 40k
<dinh> manjo: I responded to amitk's email with a condensed patch that only fixes USB...did you not see it?
<manjo> dinh, ah I must have missed it 
<manjo> dinh, thanks for the update sir
<dinh> sure thang
#ubuntu-kernel 2009-07-21
<Keybuk> cking: heh, the only documentation I could find about ioctl (FIBMAP) was your blog! :D
<cking> now that's amusing :-)
<cking> glad the blog is doing something useful :-)
<Keybuk> (we use it for sorting the readahead lists on rotary hard drives)
<cking> Keybuk, does it work on all filesystems in a sane manner?
<Keybuk> cking: it works on ext[34]
<Keybuk> and seems to work on btrfs
<Keybuk> that's *all* I care about ;)
<apw> smb, you have a bug which is about the wrong kernel getting selected as the next kernel when a kernel is installed
<apw> can you remember the #
<smb> apw, I remember there was one. But I have to dig for it
<apw> if it takes more than a minute, don't bother i don't need it for anything other than a comment
<smb> apw, must be bug 364029
<ubot3> Malone bug 364029 in linux "boots into busybox with 2.6.28-11-generic kernel." [High,In progress] https://launchpad.net/bugs/364029
<smb> apw, It is not directly about selecting the wrong kernel, but related to what is in the / link
<apw> right but thats the one thanks
<Keybuk> rtg_: when's the next kernel upload scheduled for?
<rtg_> Keybuk, gotta wait until after A3 is done. Friday perhaps?
<Keybuk> ok
<Keybuk> that works for me
<rtg_> apw, do you know how the LKML tip-bot works?
<apw> rtg_, not explicitly but i assume its reporting on the tip tree as people add branches there
<amitk> rtg_: have you considered patchwork for our ML? http://ozlabs.org/~jk/projects/patchwork/
<rtg_> amitk, have you used patchwork ?
<amitk> rtg_: not personally. But it is used on several lists nowadays including the OMAP list
<rtg_> amitk, ok, I'll get on my list of things to think about.
<amitk> and netdev
<amitk> http://patchwork.ozlabs.org/project/netdev/list/
<amitk> rtg_: you can put it on the bottom of you TODO pile. But it looked interesting...
<rtg_> amitk, if davem is using it, then it likely has some merit. he reviews a boatload of patches.
<amitk> rtg_: more than review, it is useful to ensure that patches posted to the list are not lost
<Keybuk> how clever do we think the kernel's I/O scheduler is?
<dinh> \n
<apw> Keybuk, better than it was before karmic
<Keybuk> ;)
<apw> weekly meeting in 10 mins
<apw> *** kernel meeting starting over on #ubuntu-meeting
<apw> a
<Athunye> Hello.
<Athunye> When I have to pass boot options to the kernel, should I remove the -- that are in the end of the line?
<manjo> Athunye, are you doing it on the grub edit line ? 
<Athunye> manjo: I'm editing the line. Although, my ubuntu does not show my Ethernet card in lspci, and wireless is detected but does not connect. 
<Athunye> So, I'm looking for boot options that could help me on this issue...
<manjo> Athunye, are you already booted into the system ? 
<manjo> what version of ubuntu are u running (please tell me atleast jaunty :)  )
<Athunye> Yes. Jaunty. I'm using the live cd now.
<Athunye> Wireless tries to connect for about 40 seconds and then gives up, saying that I'm disconnected...
<manjo> can you do lspci -vvnn | less ? 
<manjo> look for Network Controller 
<Athunye> Bradcom BCM4312
<manjo> ah crap
<Athunye> I already had it working, but I had to reinstall the system...
<Athunye> It worked out of the box before. (the wireless card at least)
<manjo> it should say in your lspci -vvnn Kernel modules:
<manjo> see what driver it needs
<manjo> and modprobe that driver 
<Athunye> It uses wl
<manjo> ok
<manjo> lsmod | grep wl
<Athunye> It is loaded.
<manjo> hmmm
<Athunye> Well, perhaps the problem is in the wireless router.
<Athunye> and what about the Ethernet card?
<Athunye> I know it is should use the module atl1c
<manjo> ieee80211_crypt_tkip ? 
<Athunye> Yes. It is loaded as well
<manjo> what ethernet card do you have ? 
<manjo> Ethernet controller: ? 
<Athunye> When I still was able to see it in lspci it was Atheros L1C Gigabit Ethernet
<Athunye> after I did an update-pciids
<Athunye> Because it was being called attansic, wich is not the correct
<manjo> hmm... you did an upgrade of jaunty ? 
<Athunye> No. I tried a fresh install
<manjo> did you install restricted modules ? 
<Athunye> No, because I do not have connection
<manjo> ah heh
<manjo> hmm... 
<Athunye> The only boot option I haven't tried yet is acpi=off
<manjo> does the your wireless try to connect ? 
<manjo> what does dmesg say ? 
<Athunye> Yes.
<Athunye> eth0: no ipv6 routers present
<manjo> wlan0: ? 
<Athunye> No. It gets called eth0 
<Athunye> The other was called eth1
<Athunye> I even tried karmic alpha 2
<Athunye> I'm trying noapic
<manjo> Athunye, what happens with alpha2 ? 
<jjohansen> Athunye: have you tried disabling ipv6?
<Athunye> No single card gets recognized.
<Athunye> jjohansen: No. I don't know how to do that. :D
<manjo> jjohansen, even mine says no ipv6 router .. that is normal message 
<manjo> its bad if his card does not get recognized in karmic 
<Athunye> It sure is. 
<jjohansen> manjo: yeah, but I have seen people report turning it off make things magically happen
<Athunye> I was hoping 2.6.30 would make things better.
<manjo> jjohansen, oh!
<manjo> Athunye, lets try turning off IPV6 sudo vi /etc/modprobe.d/aliases
<manjo> Find the line: alias net-pf-10 ipv6
<Athunye> Mandriva does get the wireless working.
<manjo> change to
<manjo> alias net-pf-10 off
<manjo> or alias net-pf-10 off ipv6 rather 
<manjo> and reboot
<Athunye> Just a moment, please
<jjohansen> actually I was thinking more ipv6.disable=1 in grub
<manjo> apw, you know of the issue where Atheros  L1C Gigabit Ethernet not recognized in karmic ? 
<manjo> jjohansen, heh or that 
<manjo> Athunye, jjohansen's method is more straight fwd I think...
<Athunye> Should I put that after title ... -generic. Am I right?
<manjo> yeah you can put it before ro quiet splash
<Athunye> And how coma 2.6.30 does not have wl?
<Athunye> how come*
<jjohansen> which 2.6.30?
<Athunye> The .deb ones I tried to install (I could not compile because I could not eve install ncurses-devel run make menuconfig.
<jjohansen> Athunye: hrmm from alpha2?
<manjo> Athunye, linux-restricted-modules
<Athunye> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/
<Athunye> It says "ignoring unknown option ipv6.disable=1
<manjo> jjohansen, are you sure of that option ? 
<jjohansen> manjo: hrmm, I know it exists in some kernels, I just assumed it was present
<manjo> heh
<Athunye> manjo: I don't have /etc/modprobe.d/aliases
<manjo> vi
<Athunye> yes. I don't have that file.
<jjohansen> how about  echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
<manjo> alias net-pf-10 ipv6 off
<manjo> alias net-pf-10 off
<manjo> alias ivp6 off
<Athunye> Waht about /etc/sysctl.conf?
<manjo> once you reboot you can see if ipv6 is on by using the command " ip a | grep inet6 "
<manjo> Athunye, you can also create a /etc/modprobe.d/bad_list 
<manjo> with those lines 
<jjohansen> you can add net.ipv6.conf.all.disable_ipv6=1 to /etc/sysctl.conf
<manjo> in the bad_list file you can say alias net-pf-10 off
<manjo> and reboot 
<manjo> Athunye, either way .. so you have so many options now to turn off IPV6 :) more than you needed to know 
<jjohansen> hrmm, doing a little googling turned this up http://www.ubuntu-inside.me/2009/04/howto-disable-ipv6-at-ubuntu-jaunty.html
#ubuntu-kernel 2009-07-22
<Athunye_> Well. With noapic and irqpoll boot parameters the wireless finally got connected.
<jjohansen> Athunye: good to hear
<Athunye> :)
<Athunye> Thank you guyed for the time you lent me. :)
<Athunye> guys*
<jjohansen> hehe, np. I am just glad to hear you got it working
<Athunye> jjohansen: And without irqpoll, the connection gest very slow.
<Athunye> I'm going to take a bath.
<Athunye> While I update ubuntu.
<Athunye> :)
<jjohansen> Athunye: you have something that isn't responding to its interrupts correctly
<Athunye> jjohansen: What could be done?
<Athunye> I'll try to update the bios.
<jjohansen> Athunye: that really depends on what is causing the problem
<jjohansen> Athunye: updating the bios is worth trying
<jjohansen> so is turning off unused devices in the bios
<Athunye> Yes. I can see two messages saying something I don't remember. I'll try to see them again.
<jjohansen> it is also worth comparing /proc/interrupts with noapic irqpoll and without them
<jjohansen> Athunye: on some machines even physically switching pci cards around can cleanup some of these issues
<Athunye> Anyway, it is a cheap notebook
<Athunye> Acer aspire 5516...
<jjohansen> Athunye: ah, well I guess that option isn't open :)
<Athunye> :)
<Athunye> jjohansen: I just don't understand why lspci does not show the Etherned card anymore...
<Athunye> And that happened before. And it started to show, and then didn't anymore.
<jjohansen> Athunye: that is strange, even with noapic irqpoll
<Athunye> :P
<Athunye> I hate companies that don't give a good linux support.
<jjohansen> sadly that is almost all of them
<Athunye> Yes.
<Athunye> I think Intel and Nvidia do.
<jjohansen> Athunye: have you grabbed the broadcom firmware?
<Athunye> For the wireless? No.
<Athunye> Why? 
<Athunye> Sorry my lack of knowledge.
<jjohansen> Athunye: its your ether net that is not showing up and your wireless that is working (with noapic irqpoll) right?
<Athunye> Yes. That is correct.
<jjohansen> Athunye: the broadcom firmware for 43xx can be found http://packages.ubuntu.com/jaunty/b43-fwcutter
<jjohansen> well the fetcher
<Athunye> What does a firmware?
<jjohansen> it is code that is run on the card, think of it like the devices bios
<Athunye> Thanks.
<jjohansen> Athunye: http://ubuntuforums.org/showthread.php?t=1047297&highlight=4318
<jjohansen> Athunye: follow the instructions on that page it is easier to follow than me typing
<Athunye> jjohansen: OK. Thanks. I'll keep you up to date with what is going on :P
<doko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537389
<ubot3> Debian bug 537389 in binutils "binutils 2.19.51.20090714-1 produces non-bootable kernel" [Grave,Open] 
<doko> are some ubuntu kernel variants built with HIBERNATION unset?
<rtg_> apw, ack
<apw> doko, all of the karmic ones have the same hibernation config options set
<doko> ok, thanks. so the workaround can wait until after alpha-3
<rtg_> doko, you're talking about CONFIG_HIBERNATION=y, right?
<doko> yes
<apw> thats on in all karmic builds
<rtg_> apw, if I understand correctly, changing the concatenation order allows one to more more easily integrate an already fully formed config.
<apw> exactly so
<rtg_> cool, good idea.
<apw> means you can literally put a complete config in the .<flavour> file and hit fdr updateconfigs
<apw> and the right thing will happen
<apw> as it was before the world went to poo
<apw> and you ended up with an utter mess for your trouble
<rtg_> right, doing new flavours in Hardy, intrepid, and Jaunty was a pain
<apw> and it got harder in karmic with the new merging system
<apw> all for an ordering change :/
<rtg_> apw, return from suspend on my Inspiron is about 1.5 seconds
<apw> very nice ... mine is normally around there, though now when i get in wireless is still faffing about getting connecterd
<billybigrigger> can someone help me out here
<billybigrigger> ever since the .31 kernel, my webcam hasn't been working at all...and i know that gspca is built into the kernel now, so do i have to wait for this to be fixed in the kernel? or can i fix it on my own? as i see there have been some updates to v4l-dvb and my webcam module
<billybigrigger> http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=summary
<billybigrigger> i see nothing from this tree merging into linus's 2.6.31 tree
<billybigrigger> anyone?
#ubuntu-kernel 2009-07-23
<billybigrigger> is it possible to git pull a fix from kernel.org before it's put into linus' tree?
<billybigrigger> there are some fixes here > http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=summary
<billybigrigger> that should fix my webcam, but i don't when they will be put into linus' source
<jjohansen> billybigrigger: yes. you can cherry pick commits from another tree and merge them into your own
<billybigrigger> so if i have linus' source in ~/linux-2.6
<billybigrigger> cd ~/linux-2.6
<billybigrigger> git pull git://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git
<billybigrigger> ?
<nuspeck> whats a good book for device driver programming?
<mjg59> http://lwn.net/Kernel/LDD3/ is decent and free
<nuspeck> thank you I'll take a loot at it.
<nev> hi all... Does Ubuntu actually use group scheduling? It enables Group CPU Scheduler and Control Group support, but I don't see it mounts cgroup fs and use it...
<amitk> apw: so what is genconfig used for?
<apw> for debugging the config
<apw> you run that and it gives you a CONFIG/* with the compile level configs
<apw> lets you check things are as you expect
<amitk> so it give you the merged config?
<apw> it gives you a clean config for each arch/flavour which you can use to build
<apw> and to confirm options end up set as desired
<apw> every time i changed anything in the config i wanted to be able to confirm i'd done it right
<amitk> aah, so you can copy it to you .config, analyse it in menuconfig, etc...
<apw> and so i had a patch to do 'genpatch' and figured it was generally useful
<apw> right exactly that
<apw> do 'grep ADFS_FS' and check its on in all of them as expected
<amitk> ok, just wonder how it was different from calling the 'prepare' target
<amitk> *wondered
<apw> it makes _all_ of them instead of just one
<amitk> yeah, now I understand
<apw> its most handy when one is changing the config system again :)
<amitk> apw: I'm ready to do one last test and _then_ create the configs for imx51 on karmic. Are the configs going to be relatively stable today. That last config patch almost always fails to apply when the git tree changes.
<apw> the configs just changed, as i just rebased the tree to -rc4
<amitk> *groan*
<apw> its not yet pushed ... just testing it
<apw> we rebase weekly your life is never going to be easy
<apw> is this going into the master branch or onto its own
<amitk> into its own branch for now
<apw> with that new config fix the configs are easier to inject
<apw> then the config is always going to conflict ...
<apw> as you are going to be a rebase tree ongoing till you arn't a branch
<amitk> true
<apw> you could just keep the entire configs as a file
<apw> and put it as the flavour config
<apw> and not run updateconfigs
<apw> or ... keep it separate somewhere else in the tree
<amitk> that's an idea!
<apw> and cp it to the flavour and run updateconfigs after each rebase
<apw> which will collapse it in
<apw> (now i've fixed the config update :))
<amitk> OTOH, since imx51 kernels are needed by -mobile to create images, are we prepared to have a different package namespace for this for karmic?
<amitk> separate branch would mean separate source package
<apw> we need to have a conversation about this, if it can wait, then at sprint would be appropriate
<apw> we need a strategy on how we handle these branches
<amitk> it needs to get in before A4
<amitk> and sooner the better so that -mobile team works out all the kinks in image building
<apw> so this new branch makes a new amx51 flavour yes?
<amitk> it adds the patches for the new mx51 flavour yes. We already have a mx51 flavour in karmic, but it is borked and defaults to some mx3 config
<apw> imx even
<amitk> basically karmic has the infrastructure for imx51 flavour but no code :)
<apw> yeah so if this is a branch, then we have no machinary to get that built in the main build
<apw> so either we need some of that, or we need to make it a different source package
<apw> and strip imx51 from the main tree
<apw> its custom-binary basically
<amitk> IMHO, we should just merge this into the karmic tree after reviewing that all the fencing is in place to separate Freescale code from upstream code.
<apw> thats a simpler approach i am sure
<Kano> hi apw , you saw rc4?
<apw> yes
<Kano> tell me when you are done
<apw> archive is frozen for alpha-3
<apw> so there won't be an upload for a bit
<Kano> i dont need uploads, i need only git
<Kano> kdb.c has a conflict
<Kano> and there are some modules more
<apw> a conflict with what?
<Kano> i guess with one of your sauce patches
<apw> there is no kdb.c
<Kano> well maybe not that name, but similar, was on the other pc ;)
<apw> ah atkbd.c perhaps
<Kano> something like that yes
<apw> its in progress ... will go up once its tested ok
<Kano> rc3-git5 had still several bad issues for me
<Kano> like kdesu not working
<Kano> virtualbox module working in 50% of all cases
<apw> can't say i generally test on kubuntu
<Kano> i can test kubuntu, maybe kdesu can be tested when a root account is enabled...
<Kano> just need to reset the sudo override
<cking> in what way is it not working?
<Kano> well here i get connection to su refused
<Kano> only with that kernel, when i boot 2.6.30, no problem
<cking> Hrm. Has the virtual box KMS module not been built successfully with 2.6.31 then?
<hyperair> hmm for some reason, grub refuses to load the 2.6.28-14 kernel
<hyperair> -generic.
<Kano> cking: for vbox it is no problem building the module
<Kano> cking: you have to restart the service till you dont get a dmesg error, when i do that 100 times about 50 fails
<cking> Lemme look into that later today and see what's up
<cking> Kano, what dmesg error do you get?
<Kano> it has something to do with the watchdog
<cking> I suggest filing a bug, putting all the dmesg details in and then we can see exactly what's up
<Kano> hmm when i try to write a custom .kde/share/config/kdesurc in the home it does not seem to work
<Kano> with super-user-command=su
<Kano> ok, it works,but you have to disable the admin line with visudo
<hyperair> try booting with nmi_watchdog=0
<Kano> yes thats the error, but that option does not help
<Kano> you just try a few times then it works
<Kano> i just dont get why kdesu is not in the path on kubuntu...
<Kano> apw: but the error you can verify
<Kano> apw: the passwd is not accepted
<hyperair> wait, what does kdesu have to do with vboxdrv?
<Kano> there is no connection error as with kde 3.5,but the correct pass fails
<hyperair> ?
<hyperair> you haven't answered my question.
<Kano> hyperair: both errors are because of .31
<hyperair> ...ha?
<hyperair> i don't see how .31 can affect kdesu
<hyperair> but then again i don't use kde, i use gnome.
<hyperair> and i don't use gksu very often either. i usually use sudo because i'm in the temrinal most of the time
<Kano> well ubuntu does not use su by default at all
<Kano> so no vaild comparison
<Kano> you play with sudo all the time
<hyperair> right.
<hyperair> and what's the problem with kdesu now?
<Kano> the connection fails
<hyperair> what connection?
<Kano> on kde 3.5, not fully sure if kdesu is reading the super-user-command override
<Kano> hyperair: thats the error message
<hyperair> ._.
<hyperair> what a pile of fail.
<Kano> it is harder to verify that error with u
<hyperair> imo you should go and poke the kde people about this.
<rtg_> apw, did you pick up Ike;s bnx2x firmware patch for Karmic?
<apw> has that been resubmitted?
 * apw checks
<rtg_> apw, I don't think he needed to. It was correct in its original form.
<apw> ahh i saw cjwat sons responce and hand't seen ikes responce.  will double check his stuff and pull it in
<apw> yeah ike appears to be correct, subtle having xxx and libxxx in the kernel
 * apw sucks
<apw> rtg_, this is mind mangling.. had a discussion this am how the installer does not use udebs and yet we are updating udebs for the installer ... 
<apw> i guess this could be the alternate cd images ?  hrm
<rtg_> apw, Ubiquity doesn't use udebs, but the alternate installer does.
 * apw watches the light bulb go on ... makes sense
<apw> so if we could ubuquity on the alternate cds all of kernel wedge could go away
<rtg_> apw, ain't gonna happen.
<rtg_> apw, udebs are also used on the server install IIRC
<apw> i assume that is actually just an alternate installer
<rtg_> apw, yep
<rtg_> same framework with some behavioral differences
<smb_tp> rtg_, Would you agree with a modified version of your e1000e-next patch that adds the new module to the nic udeb
<rtg_> smb_tp, sounds right, especially if you want net booting to work
<rtg_> or net install, rather
<smb_tp> rtg_, Yeah, thought so. Ok, then I guess it is ready to push now
<rtg_> apw, how about pushing your -rc4 stuff. I'm working on an rfkill bug, and I want to be able to complain on the wireless list about it using current kernel bits.
<rtg_> note that rfkill is not in wireless-testing
<apw> rtg_, will do ... will poke you when its done
<apw> rtg, karmic updated
<amitk> apw: can I rebase on top of this?
<rtg_> amitk, you ought to be able to. we won't rebase again until the next rc
<amitk> rtg_: do you plan on make a separate source package for imx51 karmic?
<amitk> *making
<rtg_> amitk, if its on a topic branch, then yes.
<rtg_> amitk, do you have something functional yet for karmic?
<amitk> rtg_: yes, cleaning up the patchset (merging, annotating, etc.) currently.
<amitk> rtg_: but I won't be able to fix up a new source package for the next upload.
<apw> amitk, yeah its basically there, just pushed one more patch
<rtg_> amitk, then why not put it in the master branch? Its not like the current imx51 flavour is doing us much good, is it?
<amitk> rtg_: It would certainly make it easier for me to put things in master. And yes, the current imx51 flavour is a dud.
<amitk> rtg_: there might be rebase conflicts though, until .31 is released
<rtg_> amitk, I'd just as soon avoid the hassle of a topic branch if you have something that works. 2.6.31 is getting pretty close do being done, so I wouldn't expect many rebase conflicts.
<Kano> apw: do you know why dm is still borken and needs a patch?
<apw> i don't know that dm is broken
<Kano> http://kanotix.com/files/excalibur/linux-2.6.31-generic/source/
<Kano> i also would suggest to apply at leaste the copy ieee header patch
<Kano> that will be needed for dvb external
<Kano> not yet compiling with .31 however, but thats a requirement i found for .30
<Kano> 2.6.31-rc2-v2-dm-table-pass-device-s-length-to-device_area_is_valid.patch	
<Kano> that was needed to make dm work
<amitk> apw: why don't we set CONFIG_IP_PNP?
<apw> what the heck does that do?
<amitk> kernel autoconfiguration (bootp, dhcp, rarp) for diskless systems
<amitk> https://wiki.ubuntu.com/KernelTeam/2.6.28-2-generic-config doesn't have any remarks
<amitk> apw: CONFIG_ATM=y?
<rtg_> amitk, every desktop should have an ATM stack
<apw> i would say take the default from i386 if in doubt
<apw> and list the defaults you think are wrong separatly... we can then review those now or at sprint
<rtg_> amitk, if size is not a consideration, then I'd like to see as many common selections as possible across ARM and x86.
<amitk> rtg_: size isn't a consideration on ARM anymore. But I assume that for drivers/protocols that can be modules, we default to modules, except when boot critical. And ATM didn't fit that category :)
<rtg_> amitk, ATM is a protocol stack, so I'm not sure why its built in. apw ?
 * apw will check hang on
<amitk> apw: that was meant as a question. Why it is built-in? Not "should I build it in". But I'll stop bothering you and just keep a list of options needing review
<apw> i thought at the jaunty uds we decided to move a lot of those =y
<apw> bringing in the stacks themselves, not the drivers
<rtg_> well, the stacks that are in common use. When was the last time you connected to an ATM device?
<apw> indeed, have to agree it seems anomolous
<apw> trying to see when it occured to see if there is some reasoning supplied
<rtg_> it could be we were all so zoned out by that time in the review that it just slipped by
<apw> heh yeah quite likely
<apw> 'its a stack =y'
<rtg_> apw, I'm fine with CONFIG_ATM=m across the board
<apw> rtg_, yeah me too... will wait for amitks list and we can do them all together
<apw> it think he and brad will explode if the config changes radically again before they can even finish rebasing onto the current one
<rtg_> apw, besides, we have a bit more experience now with what is _actually_ boot essential.
<rtg_> apw, ack on the stable config for now :)
<apw>  yes very true ...
<rtg_> apw, A3 is released, so I guess we can crack a kernel just about anytime.
<apw> rtg_, anything pending?
<apw> from your end?  if not i'll do the do on it 
<rtg_> apw, you might check with jjohansen. how about the printk format fix?
<apw> yeah good point
<rtg_> apw, I'd say just apply it and he'll pick it up when he rebases.
<apw> yeah will do that
<rtg_> apw, I've about got it built, so I can do some boot testing while working on rfkill
<apw> cool
<apw> i'll shove that one fix in and tie the bows on it
 * smb_tp waves to chris-qBT, thanks for testing all that kernels :)
<chris-qBT> smb_tp, no problems :)
<chris-qBT> I was surprised no one else reported that problem.
<chris-qBT> I guess jfs is not used as much as I thought
<smb_tp> chris-qBT, Yeah, that seem to be true. Even not upstream
<chris-qBT> smb_tp, Thanks a lot for fixing this. This bug was annoying me since rc1.
<smb_tp> Or we found it first. apw will make sure it is in our next upload
<chris-qBT> great.
<apw> smb_tp, is that that nasty rcu freeing things which are not free looking bug?
<smb_tp> apw, yes
<apw> yeeks, that one is very nasty ... use after free ... be worth getting in me thinks, get it on the mailing list so rtg can review it
 * smb_tp is lready typing
<apw> ack
<rtg_> apw, you gonna get that jfs patch in before you tie the ribbon ?
<apw> rtg yep,
<bjf> rtg, when building the kernel, where is the knob to not spawn multiple compiles?
<rtg_> bjf: CONCURRENCY_LEVEL=1
<rtg_> apw, its all built, I'll upload in a bit
<apw> rtg_, thanks ...
<rtg_> apw, you gonna send out the ABI bump announcement? Its uploading ...
<apw> rtg_ ack
<rtg_> apw, how is it that dmraid4-5 ever compiled?
<apw> thats a goodie
<apw> cause on all of our architectures test_bit is a #define
<apw> so its defined as (soemthing)
<apw> so it _happens_ to be valid code
<rtg_> ah, makes sense
<apw> its wild amazing luck
<rtg_> I pushed that fix
<apw> ack
<rawler> hi people.. I've got a _really_ weird problem with a Karmic kernel ATM, I figured maybe someone wants debug-info before I reboot?
<rawler> basically, "du -sh" at a certain folder chews disk like a maniac, and consumes 100:s of MB of rsize..
<rawler> oh.. cd:in into a certain subfolder makes my shell go nuts as well.. :S
<rawler> strac:ing the process (either DH), or the shell process, I get TONS of getdents64() calls..
<amitk> rawler: best thing would be to note all these observations with logs to a bug in launchpad
<rawler> is there anything in particular to make note of? I've got a really bad experience submitting bugs to LP.. even when I submit bugs with a solution (I.E. working patch), I've seen it take years to get attention..
<rawler> so, for a problem like this (which may perhaps even go away after a reboot), I'm naturally a bit reluctant..
<rawler> this is interesting though.. ls says the _directory_ itself is 170M.. :S
<jjohansen> rawler: the best way to capture this is ubuntu-bug -p linux
<jjohansen> if it goes away after boot then there is a least a record of it in launchpad
<rawler> seriously? is that going to figure exactly what happened here?
<jjohansen> also if it goes away after boot, it is going to be really hard to replicate
<jjohansen> rawler: no, but it does grad a lot of info and feed a bug into lp
<rawler> yeah, my thought exactly.. which is why I wondered if someone wanted to do some short investigation BEFORE I reboot.. :)
<jjohansen> rawler: what kind of short investigation? ssh into the box?
<rawler> (although, considering the directory-entry itself is of ridiculous size, I kindof doubt that the problem will go away.. my prime suspect right now is that ext4 have done something bad.. :S)
<rawler> jjohansen: well, I thought maybe one could start by feeding specific info to a pastebin or something like that.. :)
<jjohansen> rawler: ugh, I hope not
<jjohansen> rawler: feel free to paste away
<rawler> neither do I.. :)
<rawler> well, I don't know how to troubleshoot this further.. ls on the directory kills the shell, du on the directory kills du.. (or at least, takes a ridiculous amount of time), and the directory itself is silly large..
<rawler> http://pastebin.com/d7cae0828 <- info is the culprit.. look at the size.. can a dir-entry even grow that big?
<rawler> also, it must have happened fairly recently.. I clean .Trash fairly often so anything taking THIS much time would have been noted before.. 
<rawler> is it better to take this directly to ##kernel, or so?
<jjohansen> rawler: what does strace ls on the dir show
<jjohansen> and what is in dmesg, when ls gets killed
<rawler> it goes http://pastebin.com/d396295e9
<rawler> dmesg shows nothing in particular..
<rawler> ls doesn't die.. it just spins the disk like crazy, and consumes ridiculous amounts of ram.. (100s of meg after a while)
<jjohansen> rawler: well that isn't surprising considering the size of directory
<rawler> actually, my bad.. ls doesn't seem to go nuts with ram.. THAT is just du who does.. ls keeps to a few megs of rsize..
<rawler> but, what could have happened making the directory that big all of a sudden?
<rawler> and, 170meg directory-entry.. that's absolutely HUGE?
<jjohansen> what do fsck -nf show
<rawler> that's millions of files?
<jjohansen> maybe, I am wondering if it can spot format corruption
<rawler> fsck while the fs is mounted?
<jjohansen> well -n == nochanges
<rawler> yeah.. I just thought about false positives while checking a mounted FS.. :)
<jjohansen> it still not ideal but when trying to avoid a reboot ...
<rawler> (it's just done pass 1 so far, but i does complain about some maybe 75 orphaned inodes..
<rawler> damn.. I've gotta re-run.. I forgot to set LANG before fsck, and I assume you don't read swedish.. ;)
<rawler> it also complains something about a bunch of faulty blocks.. I'll pastebin it all..
<rawler> http://pastebin.com/da2bb66a
<rawler> oh, yeah.. I forgot to mention one piece of information that may be relevant.. I run on mdadm-raid1, and yesterday I did "replace" one of the disks.. (actually, just re-partitioned it, but still)
<rawler> it maybe also have made something funky, perhaps..
<rawler> dmesg (and uptime just in case).. problems were discovered today, and I'm pretty sure I emptied trash this monday without problems
<jjohansen> rawler: sigh mdadm-raid1 and repartion, I have a feeling this is going to be one of those bugs that isn't easily reproduced
<rawler> http://pastebin.com/d3f52b941
<rawler> jjohansen: me too.. which was the largest reason why I felt a LP-bug would just add noise and help nobody.. :)
<rawler> is it interesting to keep troubleshooting, or should I just reboot and fsck and be done with it?
<rawler> as 
<rawler> as I said, this IS a weird problem.. :)
<jjohansen> rawler: I don't see anything to follow, the interesting bit has already happened and left its mess
<jjohansen> yep
<jjohansen> I would fsck it and see if that fixes it
<rawler> oki.. I'll just make it work again and be done with it then.. :)
<rawler> thanks for now, and have fun!
<praveen> hiiii
<praveen> looking for source code of fopen function
<praveen> want to know if fopen calls open to get its task done in the end
<rawler> jjohansen (or anyone else reading): well, fsck showed no problems after a clean unmount.. :S
<rawler> now trying to rm the problematic dir, but it's been going on for over an hour, with no luck.. :S
<rawler> one peculiar thing is that it seems to make a lot of others apps freeze up for a while.. :S
<rawler> although, it now seems like there's actually really nothing wrong on the fs (thank god).. when stracing the rm-process it actually prints the files it removes while working... for some reason, it seems nautilus actually has created millions of files.. :S
<rawler> of the form file.<incrementing_number>.extension.trashinfo.. 
<rawler> in any case, not an ext4-problem, or  a softraid-related problem (again, thank god).. just nautilus having done something stupid..
<jjohansen> rawler: well it is nice to hear that it is unlikely the kernel but it is still disturbing
<rawler> yeah, kindof.. there's thousands of .trashinfo for each file I've removed during the last week.. that's what made the dir so big, and I guess the utils didn't really cope all that well with that huge amounts of files..
<rawler> interesting kernel-related question though; since it makes my system half-freeze for up to 15-secs at a time, could this be used to DOS a multi-user-system?
<rawler> it certainly doesn't seem like the I/O is CFQ-scheduled while doing this... :)
<jjohansen> rawler: possibly, though with the proper limits set a user could be prevent from ever creating those millions of files
<rawler> oh? in ulimit, or where?
<jjohansen> well ulimit would be run time limits I was thinking more of quotas
<rawler> btw, while I'm here, I've actually already devised a small prgram that really sinks my desktop machine I/O-wise..
<rawler> what it does is allocate just a little too much ram, so the swap gets used... 
<jjohansen> rawler: yep that will do it
<rawler> then iterate over it's memory, doing some read/write in a cyclic fashion.. it absolutely kills my desktop-machine.. power-cycle or sysrq is the only way to kill it.. logging in through ssh will just time out, so it's almost impossible to terminate this remotely
<rawler> on my laptop, it's not just as bad.. it definately gets tired, but it doesn't keel over and die..
<rawler> the interesting part of this, is that on my desktop, I've actually set a ulimit rss-size on half my ram..
<rawler> so, in theory, other apps should be able to use the remaining 512 GB, which SHOULD be enough to login and kill the memhog.. :S
<rawler> I've been waiting to get it tested on more systems before concluding anything, but isn't this also a potential DOS on multiuser-systems?
<rawler> esp. if ulimit is not effective?
<jjohansen> rawler: in theory, but swap storms can make apps very unresponsive if they involve any disk io
<rawler> how come? if ulimit is limiting rss, I mean?
<rawler> it still shouldn't be much worse than, for instance copying a file, I'd presume?
<jjohansen> rawler: well, you can get into situations where you are triggering swap, even with the rss limit set to half.
<jjohansen> rawler: it would depend on what kind of mem the other apps are using
<jjohansen> rawler: not saying it isn't broken, just it is possible
<rawler> yeah, but things like ssh? it could certainly do with 512MB ram before, when that was all that was in the system?
<rawler> oki.. seems a bit worrying to me.. :) (that's administrating a multi-user-system at work.. sure, everyones benevolent NOW ;) )
<jjohansen> well ssh still works with a lot less.  But again its the sum of the parts, and if you manage to push a machine into a swap storm all bets are off
<rawler> ouch.. :S
<rawler> sounds like a minefield.. just hoping someone doesn't go nuts with memory..
<jjohansen> rawler: it does sound broken, but I would want to see a lot more detailed accounting of where all the memory is being used
<rawler> if you're interested, compile up http://pastebin.com/df09cd1c and test on your machine.. :)
<jjohansen> rawler: yeah, I am not a fan of swap, from a usability stand point it can be better to fail things than going to swap
<rawler> well.. swap is good in theory, provided it does not burden the rest of the system more than other I/O access does.. (like, copying a file)
<rawler> swap in THEORY, shouldn't be any worse than an app mmap():ing a large file..
<rawler> although, practice seem to differ.. :)
<rawler> in any case, I think maybe ubuntu, especially -server, should think a little about this.. it may still be an issue with some part of my specific system that makes it completely freeze and die.. but in that case, I wonder exactly what that circumstance is, and if it's likely to affect others..
<rawler> jjohansen: oh, btw.. if you (or someone else) DO decide to test my little program, do remember that oom-kill is triggered by sysrq+f.. (you won't be able to look it up after ;) )
<rawler> and, if you're on a 32-bit-system with more than 2GB ram, you'll want to run the program several times at once, each instance set to consuming a couple of gigs..
<jjohansen> hehe, yeah that is why you don't run something like that on your main system :)
<rawler> yep.. :)
<rawler> also, I'm a bit curious exactly how evil that is in virtualization.. I.E. what happens on a KVM-system.. does other vhosts also get bogged all down to unusable, or does that somehow work differently.. 
#ubuntu-kernel 2009-07-24
<shtylman> kernel team!
<shtylman> bug #398059
<ubot3> Malone bug 398059 in linux "system does not boot due to device-mapper error" [Undecided,Confirmed] https://launchpad.net/bugs/398059
<shtylman> can someone bring that into our  kernel line?? (patch with last post)
<shtylman> this is a major showstopper for some people...
<shtylman> or at least update us on the status... :)
<shtylman> much appreciated
<dtchen> shtylman: i have to run another build anyhow, so i'm happy to merge that into my tree if you'd like to test it
<dtchen> shtylman: i suspect it hasn't been merged into ubuntu-karmic.git due to it not appearing in linux-2.6.git, either
<shtylman> dtchen: will gladly test it :)
<shtylman> just point me to the right ppa or whatnot and I will try it
<dtchen> shtylman: will be ~90 minutes
<shtylman> sounds good
<dtchen> shtylman: my target arch is amd64, so i hope you're running amd64 ;-)
<shtylman> indeed i am ;)
<Brent_Roth> excuse me, is anyone available to aid me with part of /usr/src/linux/arch/x86/kernel/entry_64.S ??
<dtchen> you might have better luck in #kernelnewies on irc.oftc.net
<Brent_Roth> dtchen ok, thank you
<dtchen> err, ..newbies
<Brent_Roth> sorry for coming to wrong channel
<dtchen> shtylman: http://kernel.ubuntu.com/~dtchen/test-kernels/lp398059/
<shtylman> pull and install all 3?
<dtchen> shtylman: yes (source is http://kernel.ubuntu.com/git?p=dtchen/ubuntu-karmic.git;a=shortlog;h=refs/heads/lp398059)
<shtylman> cool
<shtylman> alright ... lemme give it a go
<shtylman> damn...I love my download speed
<shtylman> dtchen: installed...will reboot (crosses fingers)
<shtylman> dtchen: uname: Linux namlyths 2.6.31-4-generic #22~crimsun1lp398059 SMP Fri Jul 24 00:17:51 UTC 2009 x86_64 GNU/Linux
<shtylman> :)
<dtchen> excellent
<shtylman> nice...glad to see the patch worked...
<shtylman> now to get it into mainline :)
<dtchen> shtylman: please comment in the bug report
<shtylman> will do
<albertico> hi... I am having a problem with the kacpid process consuming 80% of my processor... is there a way to fix this?
<albertico> I am running ubuntu 9.04 with 2.6.28-13 kernel
<rtg_> apw, -meta uploaded
<apw> thank you sir
<apw> smb, how are your sd cards on your AA ?  i am finding on my 10v that they are only detected on first insertion
<smb> apw, In/out works. Just the slightly strange fact that the right slot needs a card in on boot to work
<smb> apw, At least it _did_ work like that. I have not been actively using them for a few releases
<smb> apw, looks still the same
<rtg_> apw, pushed newrelease
<apw> rtg thanks
<rtg_> apw, there are a lot of CONFIG_CAN modules.
<amitk> rtg_: apw: can I expect the configs to remains stable today?
<rtg_> amitk, I'm wanting to commit CONFIG_CAN in the worst way :)
<rtg_> but I'll wait.
<amitk> :)
<amitk> good, I want this patchset committed before another config upheaval
<apw> i have no plans to chage the config
<apw> anyone know how one rescans a usb channel after ejecting something on it?
<amitk> apw: at the bus level?
<apw> yeah you know if you 'eject' a usb key it sort of goes away and you unplug replug it to return it to life
<apw> is there a way to trigger that without removing/reinserting?
<amitk> ohh, don't know how to do it w/o reinserting
<apw> just figured out why my sd slot stops working on the mini 10v, basically its a usb connected card reader slot
<apw> so when you 'eject' it in nautilus, that ejects the usb card reader device which i cannot then unplug and replug as its inside
<hyperair> so just unmount?
<amitk> hmm.. This patch is causing rebase issues... "UBUNTU: SAUCE: hotkey quirks for various Zeptro Znote and Fujitsu Amilo laptops"
<amitk> apw: did you see this when you rebased to rc4?
<apw> no this is normal for this dell
<apw> i think its problem that would always be seen on any version from the nature of it
<amitk> apw: did you see a problem when you rebased to rc4?
<apw> amitk, asking about my eject issue, or the rebase in general
<apw> the eject issue i had before on the -3 kernel too
<amitk> apw: rebase to rc4. I am seeing a problem with an old SAUCE patch (^^^) when I try to rebase
<amitk> not talking about eject here...
<apw> amitk, is it one of your patches?
<apw> are you just doing a git rebase origin/master ?
<amitk> nope, an old patch
<apw> ok then i think you are doing the rebase wrong, as we have rebased the tree underneath you
<apw> you would want to do a git rebase --onto origin/master <sha1 of the commit before the first patch you want to move>
<apw> as you are not interested in rebaseing the patches below those
<apw> as i already did them
<apw> make any sense?
<amitk> i think, yes
<apw> basically git rebase thinks all of the patches since linus is to be rebased by default which is not what you care about
<amitk> yup, rebase of a rebase. Works now, thanks.
<amitk> rtg_: apw: git://kernel.ubuntu.com/amitk/ubuntu-fsl-2.6.31.git has the rebased tree. I'll send email to the list now.
<apw> ta
<rtg_> amitk, do you think its OK to ignore ARM ABI changes with this patch set?
<amitk> rtg_: yes please. The old flavour was a dud.
<rtg_> amitk, will do
<amitk> manjo: I've pushed the initial rebase to my git tree. I still have to do some more adding of mx51 conditionals. But this kernel boots and stays alive on the device for now. So I'm asking for a merge to enable -mobile to start building images.
<amitk> manjo: IOW, be gentle :)
<manjo> amitk, :) will take a look 
<EagleScreen> hi
<EagleScreen> dvb-usb-af9015 is not working in karmic
<EagleScreen> it shows some crash by dmesg
<manjo> amitk, your email says pls pull... but from where ? 
<rtg_> manjo, I've got it covered
<rtg_> git://kernel.ubuntu.com/amitk/ubuntu-fsl-2.6.31.git master
<amitk> manjo: it points to the git repo later in the email
<manjo> rtg_, I just wanted to take a look... 
<amitk> manjo: http://kernel.ubuntu.com/git?p=amitk/ubuntu-fsl-2.6.31.git;a=summary
<manjo> amitk, yeah i see .. it came as an attachment "request-pull"
 * amitk disappears for a while
<manjo> amitk, so you did not fix ./arch/arm/plat-mxc/gpio.c ? 
<amitk> manjo: i have a patch in my tree. I'll push it as part of cleanup after the initial kernel is available to the mobile team
<maks_> hello have asked for initramfs-tools merge, will stick around so if any questions arise..
<rtg_> maks_, its not really a question for the kernel team. you should be bugging the platform team, e.g., Keybuk
<Keybuk> maks_: I mailed you a while back about the direction you were taking initramfs-tools
<Keybuk> you didn't reply
<maks_> Keybuk: Message-Id: <1244716927.4532.34.camel@quest>
<maks_> sure i read it.
<maks_> it's still lying in my inbox, didn't know what to say..
<maks_> anyway you added kms module too.
<Keybuk> no, Colin did
<Keybuk> my plan with initramfs is to strip it right back down to its bare essentials
<Keybuk> it should only mount the root filesystem
<maks_> rtg_: afaik it is a kernel team question as the last merge was done by the kernel team
<Keybuk> no other fancy stuff
<Keybuk> I'm considering switching to dracut for better alignment with other distros as well
<maks_> well MODULES=dep provides you in most cases with a small initramfs
<rtg_> maks_, only by accident :)
<Keybuk> maks_: that's not what I mean
<maks_> Keybuk: speaking of you as the ubuntu version
<maks_> dracut is interesting a agree
<maks_> and klibc is dommed to failure
<maks_> as hpa has no time for it.
<Keybuk> MODULES=dep vs. MODULES=most is not the same as "stick everything in the initramfs just because it's there"
 * maks_ neither since some time, my phd needs work :)
<maks_> and klibc needs massive uplifting
<maks_> the plan was to wait for util-linux to hit sid
<maks_> and then to use the generic utilities
<maks_> people already complain about busybox.
<maks_> Keybuk: please be more specific.
<Keybuk> I have been specific
<maks_> afais from your kernel config that was quite strange you had old ide build in.
<Keybuk> the initramfs should only mount the root filesystem
<maks_> so you wouldn't need initramfs in most cases.
<Keybuk> err, what?
<maks_> Keybuk: that would axe what?
<Keybuk> maks_: there's no need to set up console fonts, keymaps, locales, kms, splash screens, etc.
<maks_> Keybuk: keymaps are needed for encrypted root
<maks_> don't think i have them right now in, if you haven't cryptestup installed.
<maks_> locales shouldn't be either
<Keybuk> encrypted root need not be enabled by default
<Keybuk> if someone wants it, they should turn it on, and then rebuild their initramfs
<maks_> so you want a turn from "Put everything on initramfs as user might need it"
<Keybuk> yes
<Keybuk> indeed, we've never done that
<maks_> in debian that would put most work on the hook maintainer
<maks_> aka lvm mdadm cryptsetup maintainer
<Keybuk> the entire reason Jeff wrote initramfs-tools to be modular was so that it could be extended by installing additional packages
<maks_> known
<maks_> so what?
<Keybuk> ?
<Keybuk> so you've gone a different direction with initramfs-tools in Debian and made it do everything out of the box by default in the initramfs-tools package
<Keybuk> rather than making other packages ship their own hooks
<Keybuk> so I haven't merged it
<maks_> woow
<maks_> you are insuniating things
<Keybuk> no... I'm reading diffs and changelogs
<Keybuk> and when I asked you about it, you didn't bother to reply to my mail
<maks_> your mail didn't leave much room to a reply afais
<Keybuk> I thought it was a good start for a dialogue about what we wanted from initramfs-tools
<Keybuk> how we could make it more modular and configurable
<Keybuk> etc.
<maks_> well that thought wasn't how i read the mail.
<maks_> anyway thanks for pointer and you'll get a reply.
<Keybuk> thanks
<maks_> over and out, back to work.
<Keybuk> anyway, technical disagreements aside
<Keybuk> we're after merge window closure now
<Keybuk> so the next merge would be for karmic+1
<Keybuk> and will be competing with "use dracut instead"
<maks_> no trouble with dracut they have it booting on debian itself afaik
<maks_> not that it is a slim initramfs afaik
<Keybuk> it's much simpler
<Keybuk> and has "I want these bits" built in from the start
 * Ng wonders if -4 fixes rfkill :D
<rtg_> Ng, nope, but I'm working on it
<Ng> ah
<rtg_> Ng, I have the OK to upload wireless-tools from slangasek and Keybuk with the rfkill application from sipsolutions.org (the guy that rewrote rfkill)
<Ng> :)
<rtg_> Ng, I wast just waiting on A3 to clear the decks, so I should be able to finish it up today.
<nduthoit> I'm having a problem setting acpi temperature trip_points: 'echo -n "65:0:55:60:0" > /proc/acpi/thermal_zone/THRM/trip_points' returns "-bash: echo: write error: Input/output error" anyone know a different/new way to set trip_points? Thanks
<nduthoit> wrong channel?
<rtg_> apw, karmic pushed
<apw> anything exciting?
<rtg_> apw, mostly armel stuff, misc other patches.
<rtg_> I'm tempted to squash the IMX51 stuff into one giant patch
<apw> ahh ok ... so a biggy
<apw> i say lets see how we get through a rebase before that
<apw> its likely to be a world of pain either way i guess
<rtg_> apw, yeah. I'm thinking about uploading this afternoon (no ABI bump)
<apw> presumably the arm is a bumper but as noone is using it as it doens't work it should be ok
<rtg_> apw, I added ignores after consulting with amitk
<apw> yeah the previous amx51 wasn't so noone could be running it so ... it seems safe to me 
<rtg_> one can get away with murder during the dev cycle :)
<bjf> rtg_, my thoughts on a big squash are it's easier to find a single buggy commit with a bisect if it's multiples
<rtg_> bjf, that would normally be my approach, but there are several in that pile that are not bi-sectable
<rtg_> e.g., won't compile if you reset HEAD back to the right spot
<bjf> rtg_ that's true
<rtg_> bjf, while I'm developing something I'll have lots of small commits. When I'm at a point where the series works I'll usually squash them into logical, bi-sectable patches.
<bjf> rtg_ that makes sense for things you are developing
<bjf> rtg_, but for things like the FSL patches, I was trying to keep my mods separate from the FSL changes
<bjf> rtg_, also, if i needed to communicate with FSL on something I could give them a sha1 for the individual change
<bjf> rtg_, if it's one commit, it can be more difficult
<bjf> rtg_, just my thinking, don't claim it's right :-)
<rtg_> bjf, A lot of the Karmic patches appear to be fix-ups that amitk did after the FSL patches were applied. Those are the patches that I'd consider squashing.
<bjf> rtg_, that makes sense
<bjf> rtg_, it's the next batch that I'm thinking of
<apw> fraken-kernel
<rtg_> apw, passowrd ?
<apw> heh no a description of the melange 
<billybigrigger> anyone alive?
<jjohansen> billybigrigger: its friday afternoon so no
#ubuntu-kernel 2009-07-25
<dtchen> TheMuso: will be calling for testing this weekend for a test kernel with some amp powerdown fixes
<Ng> the rfkill tool seems to work on the two devices I've tested it on. don't want to check wifi since I'm using it, but bluetooth and wwan work :)
<Le-Chuck_ITA> Hi all, could someone please take a look and triage https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/402982 ?
<ubot3> Malone bug 402982 in linux "Frequent screen flashing with intel video card (not present with the same packages and kernel 2.6.30)" [Undecided,New] 
#ubuntu-kernel 2009-07-26
<Kernel_n00b> Hi...
<Kernel_n00b> Hmmm... where can I ask questions regarding Linux Kernel ? (Memory Swapping to be exact) ?
<Kernel_n00b> Hello ?
<Kernel_n00b> ?
<billybigrigger> might take awhile to get an answer
<billybigrigger> but someone usually does answer
<Kernel_n00b> Oh...
<Kernel_n00b> So I'd better just post it here.....
<Kernel_n00b> Hi,
<Kernel_n00b> I need to measure the time consume by the Page-Fault process.
<billybigrigger> best bet ya
<Kernel_n00b> I'm trying to measure the software's overhead (no including the HDD overhead).
<Kernel_n00b> I'm using Ubuntu 9.04 running Linux Kernel 2.6.28
<Kernel_n00b> I have a small application which generates Page-Fault and then calculate the time (user mode) it is handled.
<Kernel_n00b> In order to deduce the IO (HDD) Time, I try to wrap the following section:
<Kernel_n00b> file : linux/mm/page_io.c
<Kernel_n00b> function: int swap_readpage()
<Kernel_n00b> bio = get_swap_bio(GFP_KERNEL, page_private(page), page,
<Kernel_n00b> end_swap_bio_read);
<Kernel_n00b> Is this the correct location ?
<Kernel_n00b> In addition, in order to time the process correctly, I couldn't decide whether I should use "gettimeoftheday()" , RDTSC (on Intel's CPU) or maybe the new Intel's HPET.
<Kernel_n00b> Any Suggestion ?
<Kernel_n00b> Thank you for your help.
#ubuntu-kernel 2010-07-26
<AceLan> does anyone know how to generate the dmi info in the last part of the bug report # ex. in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585520 , dmi.bios.date: 02/13/2009 ...
<ubot2`> Ubuntu bug 585520 in linux (Ubuntu) "Unable to resume from second consecutive suspend (affects: 2) (heat: 14)" [Medium,Triaged]
<cooloney> AceLan: you mean, you wanna generate the dmi info from the dmesg.txt of that bug?
<cooloney> AceLan: i don't think we can do that. i just know 'dmidecode'
<AceLan> cooloney: yes, dmidecode don't have the same info as that shown on the bug report
<AceLan> cooloney: I need dmi.bios.vendor: INSYDE and dmi.board.name: ZQ1B
<AceLan> cooloney: do you know where can I get such info?
<cooloney> AceLan: i think you can get that from dmidecode.
<cooloney> BIOS Information Vendor: Intel Corp.
<cooloney> that's mine
<cooloney> Base Board Information -> Product Name: DG45ID
<AceLan> cooloney: got it, thanks
<cooloney> AceLan: no problem, man. i am still very sleepy due to the jetlag
<devurandom_> hello
<devurandom_> I have a problem in my 9.04 rootstocked ARM ubuntu-desktop image
<devurandom_> no user but root is allowed to use networking
<devurandom_> I tried it in several rootfilesystems with different network devices
<devurandom_> so I suspect it is a kernel configuration matter
<devurandom_> something in .config level that breaks permssion system
<lag> devurandom_: Which board are you running it on?
<jk-> devurandom_: how do you mean 'allowed to use networking'? what is failing?
<lag> Morning jk- :_)
<jk-> heya lag
<lag> jk-: Did you use terminator to extinguish your decoration? 
<jk-> lag: I have this in CompizConfig Settings Manager -> "Window Decorations" -> "Decoration Windows" = "(any) & !(class=Gnome-terminal)"
<jk-> heh, snap
<jk-> could probably simplify that to just "(!class=Gnome-terminal)"
<jk-> err
<jk-> "!(class=Gnome-terminal)"
<lag> Okay - yeah, I've done that before when I made an invisible web browser :)
<devurandom_> CONFIG_DNOTIFY=n
<lag> Cheers 
<devurandom_> lag: htcleo
<devurandom_> jk-: non root can't ping
<devurandom_> jk-: or use networking in any other way
<jk-> devurandom_: what error does ping give?
<devurandom_> permission denied
<jk-> that's odd, as ping is setuid root
<devurandom_> I've seen it in several rootfilesystems
<lag> devurandom_: What is the result of: ls -l /bin/pin
<lag> g
<devurandom_> think I can't blame ubuntu arm
<devurandom_> lag: I will check once I booted again. but it will not work with any problem. always some permission err
<jk-> devurandom_: can you give us a little more info about how you're testing this? you're logged into a desktop session as a normal user, opened one terminal and 'ping foo.com' doesn't work, but sudo ping foo.com' does work?
<devurandom_> jk-: exactly
<devurandom_> on the tty
<devurandom_> and same is reconstructible in gnome
<devurandom_> $ firefox --- no joy
<devurandom_> # firefox internet fun
<jk-> devurandom_: ok, check the output of lag's command there
<jk-> ls -l $(which ping)
<lag> Oooooooooo
<lag> :)
<jk-> mm?
<lag> ?
<jk-> *suspense*
<jk-> hey cking :)
<cking> hiya
<devurandom_> I'll check that in a minute.
<lag> Morning cking
<devurandom_> somebody got a fully known working with 9.04 ubuntu ARM .config ?
<lag> For the kernel?
<lag> Maverick or Lucid?
<devurandom_> yeseh
<devurandom_> lucid
<lag> I have two
<lag> One for OMAP3 and one for OMAP4
<lag> Actually, I may be able to dig out an armel one too
<devurandom_> I have a cortex-a8 device
<lag> OMAP3, cool
<devurandom_> so gimme the omap3
<lag> k
<devurandom_> tanks
<devurandom_> want to look and see if something striking is in the diff vs my local config
<devurandom_> thanks*
<lag> np - give me a minute 
<devurandom_> you have a beagle ? or some phone ?
<lag> OMAP3: Beagle XM 
<apw> isn't omap3 a standard build in maverick
<jk-> devurandom_: this doesn't seem like a kernel config issue :/
<devurandom_> I destroyed a beagle board with 12V on the supply line
<devurandom_> jk-: how do you know ?
<lag> Yep
<lag> apw: -^
<devurandom_> jk-: since I was spending two days trying to figure what inside my rootfs breaks apt to find out I had file locking disabled in the kernel I never exclude kernel problem
<devurandom_> <apw> isn't omap3 a standard build in maverick   <- maverick has any neon & vfp optimization ?
 * apw has not idea about neon/vfp ... but it does have a config
<lag> devurandom_: How big is your rootfs when bzipped? 
<amitk> devurandom_: why are you on 9.04?
<devurandom_> around 600M
<devurandom_> amitk: because the rootstock tool is very broken
<lag> Can you make it available to me? If so, I can test it for you
<devurandom_> amitk: it will only succeed with 9.04 for me
<lag> It will save you diffing configs, which can be laborious 
<amitk> devurandom_: were you running 10.04 when runnning it?
<devurandom_> lag: that would be marvellous
<lag> devurandom_: np
<devurandom_> amitk: no - I tried lucid rootfs in lucid and maveric rootfs in lucid. both fail
<lag> I think 10.04 works fine though?
<devurandom_> amitk: also lucid and maverick fail in the karmic
<lag> devurandom_: Then you're doing something wrong
<devurandom_> amitk: so I can only to karmic rootfs in karmic.
<amitk> devurandom_: ogra would be interested in rootstock bugs
<devurandom_> amitk: all of my bugs are documented on launchpad for many months.
<devurandom_> amitk: and all in the changelog is a broken gui-
<amitk> devurandom_: but have you tried the pre-built ubuntu images for omap?
<devurandom_> amitk: I am aware of them but no
<devurandom_> lag: as mentioned I documented all failures I got and all of them are reported
<devurandom_> lag: and not marked fixed
<lag> devurandom_: Thanks for reporting
<lag> devurandom_: Where are the bugs?
<devurandom_> lag: I did not update any
<devurandom_> I was happy with the current situation of documentation launchpad as non of the stuff I've seen was marked to be solved
<lag> devurandom_: Ah, I see. Would you mind pointing me to the bug inanycase? If they are still causing issues, I would like to either help, or gee the necessary people up.
<devurandom_> lag: if you think it will still be helpful I can retry lucid rootstock from lucid host
<devurandom_> I don't remember. all I know it was sth during qemu
<lag> devurandom_: Are you uploading your rootfs to a place where I can access it?
<devurandom_> download works
<devurandom_> I think dependency trees are broken!
<devurandom_> maybe the full desktop-image s are not sufficiently tested ?
<amitk> devurandom_: lucid on lucid works for me
<amitk> (for rootstock)
<devurandom_> amitk: ubuntu-desktop ?
<lag> Lucid rootfs and lucid kernel works for me
<lag> And 
<lag> Lucid rootfs with Maverick kernel also works for me
<amitk> devurandom_: full desktop images have the problem of running out of memory - too little on beagleboard. 
<amitk> Try the netinstall one
<devurandom_> I am excited on here people are way more interested in rootstock status than in #ubuntu-arm chan
<lag> devurandom_: That's a worrying factoid - the author is very busy in #ubuntu-arm
<devurandom_> amitk: I don't have any target performance problems.
<amitk> devurandom_: I'd suggest you first try the pre-built images : http://cdimage.ubuntu.com/ports/releases/lucid/release/ubuntu-10.04-netbook-armel+omap.img
<amitk> (assumin you're after a beagle image)
<devurandom_> lag: can you pastebin that config ?
 * apw bounces to take a new kernel
<devurandom_> maybe have a 2.6.32 one available ?
<devurandom_> ping localhost
<devurandom_> socket: Permission denied
<lag> There is working everything in: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/maverick-preinstalled-netbook-armel+omap.img.gz 
<lag> dd bs=4092 if=<image> of=/dev/<sdcard>
<lag> And help yourself to everything
<lag> Working rootfs
<devurandom_> is it an ext3 ?
<lag> Working .config
<lag> Yes
<lag> No
<lag> It is an entire SD card image
<devurandom_> downloading
<lag> VFS and EXT3
<lag> You'll need an sd card with ~2GB
<devurandom_> I work with .ext3 filesystem files I loop mount as /
<devurandom_> no direct partitions on card for more flexibility
<devurandom_> anyway I have to run
<lag> You can loop mount it once on an SD card#
<devurandom_> thank you guys a lot. I will let you know how things developed
<lag> np
<devurandom_> hold on
<devurandom_> wait a sec
<devurandom_> I don't need to try that
<lag> devurandom_: We'll be here all day :)
<devurandom_> I forgot to mention that I tried various rootfs
<lag> There is a working kernel in there too
<lag> There is working _everything_ for OMAP3
<devurandom_> yea I can't bot a random omap kernel on my qualcomm SoC
<lag> The requested .config is in there also
<devurandom_> lag: do you have the config from that thing available ?
<lag> Nope, I've just downloaded it though, so I can dig it out if you like?
<devurandom_> ok I will take it from there then
<devurandom_> taht would be nice as I have very slow link
<lag> You know that it's our latest one though? i.e. Maverick
<devurandom_> yea
<devurandom_> wondering if it has neon mplayer
<amitk> devurandom_: we don't yet support the qualcomm SoC
<devurandom_> amitk: in that case it was nice to meet you ;)
<lag> devurandom_: http://paste.ubuntu.com/469224/
<lag> Not the latest, but it works
<lag> devurandom_: Good luck
<devurandom_> lag: thanks. but I need to be in the club to download it raw
<lag> Club?
<lag> http://paste.ubuntu.com/469224/plain/
<lag> If that doesn't work for you send me your email address
<lag> Or just highlight it and copy/paste 
<devurandom_> I think I even have a launchpad account but I don't see the neccessity to login for a pastebin
<lag> Either copy/paste the one you can see, or send me your email address
<apw> ogasawara, morning ... early isn't it ?
<lag> ikepanhc: ping
<lag> Does anyone know where I can get the slide templates that ike used at the rally?
<hrw> morning 
<cking> lag, i've asked for them too
<lag> You asked ike? 
<hrw> are there any chances that ubuntu will get working 'apt-get source linux' one day?
<cking> lag, email'd him this morning
<lag> Are you going to use them at the summit? 
<cking> lag, no, I just wanted to re-read it and stash it somewhere
<lag> http://www.tuxresources.org/blog/wp-content/uploads/2006/10/1.png
<lag> I might use that one :)
<lag> Oooooooooooo: http://www.tuxresources.org/blog/wp-content/uploads/2006/10/4.png
<th1> hi, I'm packaging a special kernel for use in a Xen environment. I need it to cause some extra modules (xenfs.ko and a couple others) to be added to the initramfs automagically somehow on the target system, how can I do this
<tgardner> th1, /etc/initramfs-tools/modules
<th1> tgardner, yes that's how I do it but I need it to happen automatically on a system when the kernel-image I'm making is installed
<th1> ie. without the user editing that file
<th1> I could do it in the postinst script of the kernel package but if I edit that file and then the user uninstalls my kernel package and switches back to a standard one, it's going to break
 * vanhoof waves
<th1> tgardner, I think I found what I needed by creating a hook like there is for lvm2..
<tgardner> th1, in /etc/initramfs-tools/hooks ?
<th1> in /usr/share/initramfs-tools/hooks 
<th1> so I put that in my kernel image package and call manual_add_modules for the modules I need
<tgardner> ogasawara, you should uncomment the backports entries in Maverick -meta before you upload Ubuntu-2.6.35.12.13
<paultag> Hey kernel guys. After a quick exchange with cndougla ( howdy! ) I've decided to test the -M kernel. Is it safe to fetch the dsc and run a pbuild against Lucid? I have a driver regresson from 31-21 to 31-24, B43 issues on boot locking up initrd
<cnd> paultag, I *think* you should be fine to build the kernel in lucid
<cnd> but the toolchains are quite different now, so you never know
<tgardner> paultag, there is already a kernel build for lucid in https://edge.launchpad.net/~kernel-ppa/+archive/ppa
<paultag> tgardner: you've saved the day :)
<paultag> cnd: I'd love to test this to see if it's an issue for 10.10, and if it can't get squashed before +1
<paultag> I'll do my bit and homework :)
<cnd> paultag, the other route you could try is the maverick kernel backport to lucid
<cnd> tgardner would know more about that than I though
<tgardner> cnd, which is just what I suggested, i.e.,  there is already a kernel built for lucid ...
<paultag> swaping over now
<cnd> oh, I thought that was in a different repo
<cnd> nm then :)
<paultag> Well, it booted, but it's a random chance thing ( I'm fairly sure it's a race condition ). Let me test a few times to get a nice sample pool
<cnd> tgardner, there were some b43 fixes a few weeks ago
<cnd> are they in lucid yet?
<cnd> maybe apw or smb know?
<apw> cnd, i don't think i know specificially ... if you have a reference to the fix i can find out
<paultag> Opp! Still locked up. Two good boots, one failure
<cnd> apw, I don't have a reference, I just remember you looking at a fix for b43 that made it actually work
<cnd> something about disabling dma
<cnd> cause it just doesn't work
<apw> paultag, we a
<apw> we have some boot hangs due to a unrelated graphics issue which is being worked on, so it might be that too
<rsalveti> devurandom_: can you report the problems you're facing with rootstock? also let me know what version you're using
<cnd> apw, he's hitting issues in lucid
<cnd> and he's testing maverick right now
<rsalveti> devurandom_: I'm maintaining it now, and fixing bugs everyday
<apw> cnd that rings some kind of bell, i would have to defer to smb with such thin memory though ... think smb is off today, sounding like he was ill
<apw> cnd right, i mean if you have boot hangs in maverick kernels it may not be the same hangs you have in lucid
<paultag> apw: when I boot single user, it's always the last line -- and since it's single user I am not so sure it's a graphics thing
<apw> as we know we have some in maverick which are all new
<apw> paultag, good enough then
<paultag> apw: it's present on current lucid to ppa kernel team <
<paultag> erm, M
<ikepanhc> lag: those slide at chinstrap.canonical.com:/home/ikepanhc
<paultag> 2.6.32-24-generic to nightly, not present in 32-21
<lag> ikepanhc: Did you make them?
<paultag> Failure line off the initrd is :
<paultag> b43-pci-bridge 0000:01:00.0: PCI INT A -> GSI 16
<paultag> (level, low) -> IRQ 16
<ikepanhc> lag: which slide you ask?
<paultag> Humm, I've just had about 8 good boots in a row. The issue looks to be harder to reproduce. This just screams Race Condition to me :/
<lag> I'm after the templates that you used for your presentations whilst in Prague 
<ikepanhc> you mean the template for presentation? I think they comes with lucid
<lag> Oh okay
<lag> ikepanhc: So it does
<lag> ikepanhc: What's the time there/
<lag> ?
<ikepanhc> lag: ya, the name is GlossyUbuntu
<paultag> cnd: OK. I'm going to reinstall from scratch. I'm going to try and reproduce with another driver to try and isolate. Are there any special steps I should take to aid in tracking it down?
<ikepanhc> lag: oh, the time, it is 21:48 in Taiwan :)
<cnd> after you reproduce we can look at debug steps
<paultag> OK.
<cnd> but there's nothing I would worry about for now
<lag> ?
<dcordes__> rsalveti: it is good to see rootstock is being fixed. I will retry a lucid rootfs soon and report any bugs found. I've been using the latest version from 2 weeks ago when I encountered the errors
<dcordes__> amitk: may I ask if you are working for canonical ?
<amitk> dcordes__: yes I am
<rsalveti> dcordes__: cool, I'll try to release another version this week, and get it uploaded in maverick
<jpds> 1/12
<dcordes__> rsalveti: ok seems like I will ugprade to maverick on my workstation
<dcordes__> amitk: I am very excited about all the ARM work done at canonical these days. you mentioned that qualcomm is not _yet_ supported and I have noticed that in fact quite som work is being done for the qualcomm SoCs. Is there some official documentation on the development process available?
<amitk> dcordes__: we've carried the tree from android, but there is no ready-to-use image being created for qualcomm socs
<dcordes__> amitk: I am very familiar with the msm7xxx msm7xxxA and qsd8xxxx (snapdragon) platforms and would like to help out
<dcordes__> amitk: tree being kernel ?
<amitk> dcordes__: right. You should talk to tgardner/rtg when he gets online. But we're didn't have a contract for qualcomm work like we did for TI, Freescale and Marvell.
<amitk> s/we're/we/
<dcordes__> amitk: I'm sure such things can also be achieved on community level :)
<tgardner> dcordes__, qualcomm isn't gonna happen for Maverick. You might look into the ChromeOS project if that is the HW you're really interested in.
<dcordes__> no thanks I'm not so anxious to promote all the google projects. enough people do.
<paultag> cnd: It's slowly getting worse. I can't rule out hardware.
<dcordes__> tgardner: that's why I am here
<amitk> dcordes__: the rootfs will be usuable as-is, so you only need a kernel
<cnd> apw, for the next three weeks (or until multitouch is off my back), could you or someone else handle my bug triaging responsibilities?
<apw> cnd, we'll find someone yes
 * apw gets his monkey tongs ready
 * apw yanks that monkey off cnd's back
<apw> JFo, that reminds me, seems you broke the links on the tagging page making them all 'OR' so that we had 50 in each category!  fixed it up
<dcordes__> cnd: is this any tslib related ?
<JFo> ?
 * JFo looks
<apw> JFo, the 'To Review' links we cleaned up and made nice and short, which unforuantly made them into 'any of these tags' searches ... so all of the links showed all bugs marked kernel-needs-review
<apw> JFo, i added a stanza to say we want 'ALL' of the tags to each
<JFo> ok, I can fix that
<JFo> I know what i did
<apw> already did after i noticed i had 54 in therm
<cnd> apw, thanks!
<cnd> dcordes__, tslib?
<JFo> k
<JFo> i see your fix
<dcordes__> cnd: the multitouch worked on your back. is it related to touchscreen driver or tslib implementation ?
<dcordes__> s/worked/work/
<apw> JFo, some arsenal script is using https://wiki.ubuntu.com/KernelMainlineBuilds ... which is doubly out of date i think
<JFo> indeed it is. i have an item to update some of the links as there is another that is old, but still gets you to the right place
<apw> JFo, indeed, more a 'is this on your todo' than anything else
<dcordes__> cnd: I am interested because I have a multitouch screen
<dcordes__> I think many nice things could be done e.g. with mpx
<JFo> cool :)
<JFo> I have added it specifically
<cnd> dcordes__, I haven't looked at tslib
<cnd> I'm mostly focused on drivers and work to enable applications
<dcordes__> cnd: are you using tslib to interface your drivers ?
<cnd> no
<cnd> I'm focusing on figuring out proper ways to interface with X
<dcordes__> what options are there ?
<dcordes__> ah a whole new approach
<dcordes__> nice
<paultag> cnd: JFo czajkowski and myself did a differential diagnosis. current theory is that it's the graphics card + fb issue
<paultag> cnd: czajkowski has the same issue, and the only hardware in common is intel vga ( 945GME / GM965 )
<JFo> apw, did we get any kind of fix in for the fb issue? my memory indicates no, but I could be wrong
<JFo> actually, looks like you may have answered that already
<JFo> <apw> we have some boot hangs due to a unrelated graphics issue which is being worked on, so it might be that too
 * apw is working on it at the moment
<paultag> Is there anything you would like me to run on the hardware that can reproduce this?
<paultag> ( to help identify anything you might need )
<apw> if you are seeing the issue i am working on you should see panics associated with fb_release triggered by plymouthd
<paultag> apw: will the kernel panic?
<paultag> and will this present it'
<apw> for the issue i am tracking, it commonly emits a panic yes, though often it continues
<paultag> Humm
<paultag> and will this present it's self even if I don't try and run Plymouth? 
<paultag> ( read: remove splash from GRUB )
<apw> nope, it would only be tickled by plymouth running, removing splash from the command line is not sufficient to stop it
<apw> as plymouthd still opens the framebuffer and closes it even if it does not paint the splash
<paultag> Ahha
<paultag> apw: I'm not seeing a panic
<apw> i see a variety of symptoms as it is a rave condidtion
<apw> race
<paultag> OK. Would you like me to document anything apw?
<apw> mostly though its either a hard hang with blank screen or flashing a lot
<paultag> apw: Hard hang
<apw> then dropping to low res mode
<apw> now the hard hang comes with a blank screen normally
<paultag> apw: It does not change kernel display modes
<paultag> apw: blinking cursor
<paultag> unresponsive to keyboard input, REISUB or Ctrl+Alt+Del
<apw> not sure i had a blinking cursor or not
<paultag> apw: would you like anything documented and posted anywhere to aid in your work?
<apw> if you cannot confirm the panic, i suspect you have a different issue
<paultag> apw: There is no numlock or scrolllock LEDs, but the Caps Lock is not blinking
<apw> thats not sounding 100% like my issue ... cirtainly mine is more random, not 100% hard lock
<apw> if i had something which fixed it i'd suggest testing it, but i don't
<paultag> apw: it's random
<paultag> apw: it just always hardlocks
<paultag> apw: e.g. no blinking screen, etc
<apw> random and always are not really something you can put in one sentence are they ?
<paultag> apw: sure they are
<apw> i randomly always sneeze
<apw> hrmmm
<paultag> well, you could say, when I randomly sneeze, I always see spots
<paultag> when I randomly crash, it always hard-hangs ( no other symptoms )
<apw> do you ever get to the point where the machine is up long enough to look for an oops in the dmesg
<apw> as the issue i am tickling is a boot only issue
<paultag> apw: this is boot only
<paultag> apw: in the first second after grub hands off execution
<paultag> it's always in the initrd
<apw> do you have a regular setup ?  no encryption etc ?
<apw> as the driver at fault here doesn't load till we get into the main root for a normal setup
<paultag> apw: I've wiped this four times in the last two days trying all setups. No encryption, present in all Lucid images I've tried
<paultag> Hummm
<apw> t
<apw> that sounds like it rules my issue out
<paultag> OK
<paultag> thanks apw 
<ogasawara> tgardner: you didn't put nouveau in ubuntu-maverick-lbm right?  ie I'm still gonna leave linux-backports-modules-nouveau-RELEASE_NAME-generic commented out in linux-meta.
<tgardner> ogasawara, uh, right. nouveau is mainline in Maverick
<ogasawara> tgardner: maybe I'll just delete that entry all together
<tgardner> ogasawara, ack
<sconklin> JFo: If I find a bug for which a patch is already in proposed, but isn't connected by having a buglink in the patch, is there any way I can set it up to automatically change to fix released when the SRU is released?
<apw> crap the locking is all buggered in fbcon ... there is no locking whatsoever on the 'registered_fb' list ... so it can cause random panics if one ever goes away
<apw> which is exactly what happens when drm starts up
<ogasawara> JFo: we having a bug chat this morning?
<JFo> we are if you like
<JFo> I can cancel if needed
<JFo> since we were all gone last week
<ogasawara> JFo: I'm indifferent, whatever the group wants to do is fine with me
 * apw abivalent
<JFo> lets have it then and see what we can accomplish :)
<ogasawara> JFo: my mumble is horked, I can't year you.
<JFo> :-(
<tgardner> ogasawara, well, get unhorked
<JFo> heh
<ogasawara> JFo: continue on without me while I try to get it fixed
<JFo> ok
<ogasawara> tgardner: you sound sick
<tgardner> ogasawara, <sneeze>
<paultag> OK, just an update cnd, apw: Issue not present in 9.10, I'm calling this a regression. Bug filed ( ask JFo asked ) #610124, #610126.
<JFo> thanks paultag :)
<paultag> no problem, thank you guys for putting up with me all day
<paultag> I'll be here if you need anything more out of me. I'll leave 9.10 on here if I need to do anything more for you guys.
<vanhoof> JFo: ping
<vanhoof> JFo: you mentioned in an email a while back about having a few wifi/usb dongles
<JFo> I do indeed
<JFo> :)
<vanhoof> JFo: I assume these are all external devices? ... do you have anything that can connect to the mobo?
<JFo> these are external
<vanhoof> kk I assumed so
<JFo> pete may have some that connect to the mobo
<JFo> as I had to swap mine out at the kernel sprint in january\
<JFo> vanhoof, anything in particular you need?
<vanhoof> JFo: just seeing what we have in hand to do some testing 
<JFo> I see
<JFo> I'll get with pete to see if we have any chips for mobo
<JFo> and if so, what
<vanhoof> JFo: that would be awesome
<JFo> who loves ya baby? ;)
<vanhoof> JFo: this is all in reference to that thread for usb/wifi recommendations we had last month
<JFo> yeah, I remember
<JFo> cool
<JFo> I'll get you a list of what I have as well
<vanhoof> JFo: that'd be cool
<vanhoof> JFo: just cc'd you in the thread for frame of reference
<cnd> paultag, sounds good :)
<JFo> vanhoof, cool, thanks
<JFo> I'll send back my list to that group of folks
<JFo> so tgardner any ideas what days you paid for dinner?
<JFo> I want to make sure my per diem is correct :)
<tgardner> JFo, yeah, hang on.
<JFo> k, thanks
<apw> tgardner, lbm was turned off for maverick in -meta, did you handle that, or does someone need to do so?
<JFo> think he pinged ogasawara earlier about that
<ogasawara> apw: doing so now
<tgardner> apw, I bugged ogasawara about it just this AM
<JFo> man, I'm good ;)
<apw> heh ... and the circle is closed ... :)
<tgardner> JFo, I don't have you on any of the receipts for when I paid.
<JFo> huh, ok
<JFo> oh right, because that sushi place didn't take plastic
<JFo> dang, what night was that?
<JFo> :-/
<tgardner> JFo, right, that was just per-diem
<JFo> right
 * JFo has to take better notes
<tgardner> JFo, 7/20
<JFo> ah, thanks
<jjohansen> 7/21 was pizza after bowling
<JFo> I didn't go
<JFo> can't remember where we went that night
<jjohansen> JFo: ah, I couldn't remember for sure
<JFo> heh
<JFo> yeah, you guys ditched the fat kid :-(
<JFo> j/k
<apw> JFo, you didn't go to place with the accordion didi you?  seem to remember you went somewhere like that
<JFo> that was the last night
<JFo> when we took 'the photo'
<apw> yeah i think pete went there another time, and you went with him somewhere on bowling night right?
<JFo> yeah
<JFo> may have been the fat koala
<cking> JFo, I'd like to see that photo. I heard it was quite amusing to say the least
<apw> JFo, we need to get you a little book of calm
 * tgardner lunches
<paultag> JFo: Just an interesting note for you guys
<paultag> JFo: I just tried installing arch to the box. I downloaded 2010.05 ( archlinux ), same exact error line with b43. Breathe easy, it's upstream, not Ubuntu diversions
<JFo> apw, indeed we do
<JFo> paultag, while not good news, at least we know it is universal
<paultag> JFo: yessir, and at least it's not your guys's fault.
<JFo> indeed :-D
<paultag> I think I might just try and debootstrap it, and compile an old kernel
<paultag> and test every few releases
<apw> paultag, there are older .debs for mainline kernels in the mainline kernel archive
<paultag> apw: Oh? I only saw the recent series in my apt-cache. Do I have to install the debs by hand and divert upgrades on it?
<paultag> And are they "safe" with 10.04 ?
<apw> they install in their own namespace, so they are unaffected by other kernel
<paultag> Ah, even better
<apw> safe is harder to say ... they are upstream as i comes
<paultag> thanks for your help guys :)
<paultag> thanks apw, I'll try it
<apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
<paultag> can't be worse then compiling your own kernel
<apw> quicker for sure
<JFo> oh yeah\
<paultag> aye aye
<ogasawara> sconklin: I just submitted a patch to upstream stable which should resolve bug 544740 assuming upstream stable accepts it
<ubot2`> Launchpad bug 544740 in linux (Ubuntu Lucid) (and 1 other project) "fix for iSight cameras not being recognized (affects: 4) (heat: 24)" [Medium,In progress] https://launchpad.net/bugs/544740
<ogasawara> sconklin: I tagged it 2.6.32.y, is there a different tag you guys are using to track bugs that will possible get fixed with future stable releases?
<sconklin> ogasawara: I'm not aware of any tag that's being used, but there probably is one. I want to ask Stefan, and get it documented on the tags page. Thanks for the patch!
<vanhoof> sconklin: did you hear back on that email you sent last week to intel-gfx?
<sconklin> vanhoof: Manoj heard back from upstream. They rejected that patch, and are working on a real fix.
<vanhoof> sconklin: this was the two liner?
<sconklin> vanhoof: Yes. Manoj will be the interface person between OEM and the kernel team on this (and all kernel issues)
<vanhoof> sconklin: https://patchwork.kernel.org/patch/109959/
<vanhoof> looks like it was applied
<sconklin> vanhoof: talk to Manoj about it, I haven't seen any of the emails that were exchanged with upstream about this
<vanhoof> sconklin: k
<sconklin> manjo:  ^^
<manjo> vanhoof, I just emailed you 
<vanhoof> manjo: right saw that ... thats the bug for failure to return from suspend
 * vanhoof was referring to the two liner for the x201 w/ no graphics at all
 * manjo so many intel video issues... 
 * ogasawara lunch
<JFo> sigh, now I'm sneezing... all I had before was a cough. :-/
 * JFo hates rallyflu
<ayan> ugh.  bummer.
<jjohansen> -> Lunch
<tgardner> ogasawara, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=00f7ee15c69a78ba2551322b184b5b337dca2e4e is obsoleted by Linus' e7b96f28c58ca09f15f6c2e8ccbb889a30fab4f7
<ogasawara> tgardner: ack, I'll replace it.
#ubuntu-kernel 2010-07-27
<jj-afk> back on later
<dcordes__> hi
<dcordes__> are there any release notes for http://cdimage.ubuntu.com/ports/releases/lucid/release/ubuntu-10.04-netbook-armel+omap.img ?
<dcordes__> -sorry. I'm wondering about this here http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/maverick-preinstalled-netbook-armel+omap.img.gz what is the user pass ?
<persia> dcordes__: My guess would be "ubuntu"/<none>
<dcordes__> persia: ubuntu/<none> ubuntu/ubuntu both don't work
<persia> Oh, I remember.  It doesn't have one.  Boot it into X, and it will launch oem-config to set up the user/password.
<dcordes__> persia: X doesn't seem to work
<dcordes__> persia: I remember it has some platform specific accerlation thing
<dcordes__> xf86-video-omap ?
<persia> Hmmm.  I'm not sure then (and I don't have any hardware that can run that).  Try asking in #ubuntu-arm.
<RAOF> dcordes__: Might you be thinking the xserver-xorg-video-omapfb binary package?
<dcordes__> RAOF: sorry ?
<RAOF> dcordes__: Your âplatform-specific acceleration thingâ
<dcordes__> RAOF: yes what about it ?
<RAOF> I uploaded a new version last Thursday, which (should have!) fixed installability and make it actually work.
<dcordes__> you must be maintainer then. cool
<dcordes__> many ubuntu staff people here
<RAOF> If omapfb is not working on Maverick you should check that 0.1.1-3ubuntu2 is the version that's installed; the previous version won't work.
<dcordes__> RAOF: s/on Maverick/on my device/ :)
<dcordes__> don't have any omap dsps
<dcordes__> Oliver Grawert  wrote on 2010-07-09:  	  #2  the netbook session should not be the default here, we need to add a proper settings package that makes it default to 2D once the mobile-m-lightweight-panel-for-efl spec is implemented
<apw> morning all
<cking_> morning apw
<apw> cking_, having network fun today?
<cking_> nope, just swizzling my connection directly to my server so I can run QEMU remotely more responsively
<apw> heh sounds like a plan
<cking_> darn this ubi-flu
<apw> you too?  avoided it so far
<cking_> rubbish cold, hot head, urgh, it hit me yesterday afternoon/evening
<apw> yay
<amitk> cking_: welcome to the club (*sniffle*)
 * apw refuses to have it
 * abogani waves
<ikepanhc> good morning .eu :)
<apw> ikepanhc, moin ... used your new instructions to update the wiki ... https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey ... and added an automatic menu generator
 * ikepanhc looks good, thanks. I shall write the wiki
<ikepanhc> wow, you have a script for it
<apw> ikepanhc, yep ... slap on iso's run rebuild and done
<apw> doesn't install grub thats still manual, but a one off
<ikepanhc> I think it is ok. enough info in the wiki
<apw> yeah i used your text in your email as a basis as it was nice and clear
<apw> and added the rebuild script i just wrote while testing the instructions :)
<apw> ikepanhc, thanks for writing that up its great
<ikepanhc> :) I will have a presentation to all of us because it amazed me when I saw it
<ikepanhc> I believe it can make our life easily
<jk-> anyone have sudo on frylock?
<abogani> apw, ping :-)
<apw> jk-, not i
<apw> jk-, tgardner i would thnk
<apw> abogani, hi ya
<abogani> apw, Do you have some news for me?
<apw> abogani, gah ... no ... i will book some time with smb to get that done
<abogani> apw, Ok thanks. Sorry for bother you so frequently.
<apw> abogani, no no problem its lack of time is all ... but i see A3 in my ear and it neesd to be done before that
<ericm|ubuntu> guys, silly question - how to extract the contents from an .img file (the file used to 'dd' onto a USB disk for installation) ?
<ericm|ubuntu> mount -o loop doesn't work, I guess it's not simply a partition but a whole disk image
<ikepanhc> I dont have a better way then dd into a usb disk
<apw> ericm|ubuntu, you might be able to mount it if you do the looping back yourself
<apw> as the underly loop mechanism is actually raw disk loopback
<apw> ie it should find the partition table etc as far as i know
<ericm|ubuntu> apw, what's the exact command - dude I'm a slack to find that out :-)
<apw> its losetup i think
<ericm|ubuntu> apw, let me have a try
<apw> you may then have to use the offset stuff to map just the partition manually ... not sure
<ericm|ubuntu> apw, ah that way I may prefer to use dd to get rid of the MBR from that .img file
<ericm|ubuntu> though not exactly sure about whether the 1st partition starts right behind
<ikepanhc> ericm|ubuntu: try iat
<apw> ericm|ubuntu, if you know how far in the partition is you can just sue --offset
<ikepanhc> ericm|ubuntu: it can convert .img to .iso, then mount iso
<ericm|ubuntu> ikepanhc, apt-get install iat?
<ikepanhc> yeah
<ikepanhc> but apw is right, if we know the offset of the partition, mount with offset will be quickest
<ericm|ubuntu> ikepanhc, I'd try apw's suggest first, I'm already a slack cannot depend on more tools now
<ericm|ubuntu> :-)
<ericm|ubuntu> yow, this works: sudo mount -o loop,offset=512 ~/canonical/wyse/images/hedley-usb-hdd-20100712-2.img /mnt
<ericm|ubuntu> damn
<apw> damn?
 * ericm|ubuntu goes off to prepare some ice coffee
<soren> ericm|ubuntu: You can use kpartx to access partitions in disk images.
<ericm|ubuntu> soren, I did it in a silly way - losetup and fdisk :-)
<soren> ericm|ubuntu: Yeah. kpartx is your friend. :)
<ericm|ubuntu> soren, I might try that out later
 * ericm|ubuntu be back in a minute
<tseliot> apw: you backported drm from some newer kernel version in Lucid, right? Do you remember what version you backported it from?
<apw> tseliot, originally 2.6.33, though it is following stable 33.y
<tseliot> apw: this is a bit weird as I can reproduce a bug with radeon with 2.6.33 (from the mainline builds) or higher but not with Lucid's kernel
<apw> tseliot, so you'd want to test the tip of the v2.6.33.y branch too ... maybe fixed there
<tseliot> apw: I tried v2.6.33.6-maverick
<apw> ok ... so then we must have something else fixing it :)  whats the bug
<tseliot> apw: videoclips stutter every 16-17 second
<tseliot> with any player and with or without compositing
<tseliot> I also used ftrace to see what was going on
<apw> so this is a maverick issue i assume ?
<tseliot> yep
<apw> how can i reproduce it?
<apw> and are you saying its just radeon?
<tseliot> apw: http://pastebin.ubuntu.com/469759/
<tseliot> yes, it's radeon and it affects my RS880 chip
<apw> so, what in that ftrace is indicating it?
<tseliot> that's a good question ;)
<apw> tseliot, also which maverick kernel are you testing?
 * ericm-afk a long minute
<tseliot> apw: currently it's 2.6.35-10-generic
<tseliot> 2.6.32-22-generic is fine
<apw> what version is that based on?  check /proc/version_signature last word
<tseliot> Ubuntu 2.6.35-10.15-generic 2.6.35-rc5
<tseliot> I've also tried the following kernels from mainline: 2.6.33.6, 2.6.34, 2.6.35
<apw> there is no mainline 2.6.35
<tseliot> and while the problem is less noticeable in 2.6.33.6 and 2.6.34 it's worse in 2.6.35
<tseliot> then I must have compiled it from source
<apw> well there are -rcN's there, but 2.6.35 itself isn't out yet
<tseliot> this is what I tried: v2.6.35-rc5-maverick
<tseliot> and v2.6.35-rc2-maverick/
<apw> tseliot, ok there is now an -rc6 and the latest maverick kernel is on that too
<tseliot> ah, -11
<tseliot> I'll try that and let you know
<apw> i am not expecting much tho
<tseliot> yes, at this point there shouldn't be many changes
 * apw notes that udev is getting plymouth up and attached to /dev/drm* before the i915 driver has even finished initialising
<apw> that is never going to be a pretty thing
<diwic> apw, that sounds quite bad
<apw> i am not sure it is truly ready to be opened, a feeling backed up by the fact it panic's pretty soon after
 * apw suspects he is only hitting this cause he has a fast SSD in this box
<diwic> apw, is there something asynchronous in the i915 driver, or would something like while(1) { fopen('/dev/somedevice'); } make most devices go crazy?
<diwic> apw, I mean all by definition, the device node for any device must be created before initialization finishes
<apw> diwic, everything about module insertion is async, udev probed i915 in the background, and is responding to the dev files appearing by firing off plymouthd to open then
<diwic> apw, so then the i915 driver should implement synchronisation/muteces that makes opening of the device node not to succeed before the i915 is fully initialized?
<apw>  diwic indeed so ... now to find out what the heck is wrong with it
<apw> tseliot, hey ... sconklin worked out you could turn on drm debug right?  did he document it?
<tseliot> apw: right, I forgot about that
<tseliot> apw: drm.debug=1 if I remember correctly
<apw> or it might be i915.debug
<tseliot> this is with radeon
<tseliot> modprobe -v drm debug=1
<tseliot> as they suggest here: http://www.x.org/wiki/radeonBuildHowTo
 * tseliot wonders if he can do it on the fly by acting upon /sys
<apw> yes you can, sconklin reported you could
<tseliot> maybe echo 1 > /sys/module/drm/parameters/debug
<apw> 1,2,4 bits have meaning
<tseliot> ok
<apw> #define DRM_UT_CORE             0x01
<apw> #define DRM_UT_DRIVER           0x02
<apw> #define DRM_UT_KMS              0x04
<tseliot> hmm... maybe 2?
<apw> well 7 was bad (too much output), 2 doesn't have what i need
<apw> 1 has too much, 2 too little
<tseliot> apw: maybe vblank has become too expensive? http://pastebin.ubuntu.com/469792/
<tseliot> not that it has ever been cheap
<tseliot> apw: actually this is what I got right after playing the video: http://pastebin.ubuntu.com/469795/
<apw> tseliot, i am not sure what to make of that much outut
<apw> do you have one from a good run ?
<tseliot> apw: I could do it from 2.6.32 and compare it
<apw> not sure what to suggest other than that
<cooloney> anybody found the maverick daily build iso does not boot?
<cooloney> apw: ^^
<apw> not tried an iso recently no
<cooloney> i tried to install it on my Samos machine
<apw> i'd suggest trying it on your mac, but that never works anyhow right?
<cooloney> apw: my mac needs a real cd disk. i am using usb boot disk now.
<cooloney> i will reboot my desktop to try it. later
<apw> * bjf[bjf] is now known as bjf
<bjf> moin
<apw> moin, interesting transition there
<cooloney> apw: on my samos, SYSLINUX failed and said "Unknown keyword in configuration file."
<apw> i'd suspect thats going to be wrong for everyone then
<apw> i'd need to sync an image to confirm, it'l take 20 mins
<cooloney> apw: yeah, i gonno to reboot my this desktop for testing. let you know the result soon
<bjf> apw, i've got today's iso, will give it a spin
<apw> bjf, ta
<tseliot> apw: nothing too interesting with 2.6.32: http://pastebin.ubuntu.com/469807/
<tseliot> maybe in 2.6.35 drm:r600_irq_process is causing the issue
<apw> well vblank only shows up twice in that new one
<tseliot> not here: http://pastebin.ubuntu.com/469795/
<tseliot> and that's with 2.6.35
<apw> [ 5229.289043] [drm:r600_irq_process], IH: D1 vblank
<apw> there are millions of those in the .35 one
<tseliot> right
<dandel> i'm wondering is sleep is broken in the kernel.
<cooloney> apw: it looks a common issue about syslinux
<apw> dandel, seems unlikely generally
<cooloney> the same maverick usb stick does boot my desktop and samos machine
<dandel> http://pastebin.ubuntu.com/469810/ (Some code i have which shows this)
<apw> cooloney, thanks, i am about to test, and bjf is testing ... so if we all fail
<apw> dandel, and how does this program exhibit brokenness
<cooloney> apw: no problem, i'm just going to test maverick on my samos, then found that. 
<tseliot> dandel: were you referring to the vblank issue?
<dandel> no.
<dandel> actually, this is something else
<dandel> 200000 usleep should be 0.2 seconds on the clock.
<dandel> however, it's returning 0.0
<maxb> I'm using schroot, and it's taking ages to exit a chroot. Does anyone know what might cause the umount syscall on a bindmount to take ~0.5seconds?
<apw> maxb, lucid ?
<maxb> apw: yes
<apw> umounting anything currently triggers a pre-sync, to avoid a major performance issue in unmount
<apw> you are likely hitting that ...
<dandel> the first half of my program uses usleep to put the program to sleep for 0.2 seconds and the second half forces a busy wait for 0.2 seconds however the clock is showing no difference.
<cyphermox> apw, I had noticed something like booting too quickly as well... there were issues with the hand-off between my netinstall system and booting to the disk. let me know if I can provide more info
<maxb> oh. yes that sounds like it
<apw> smb was looking at some patches
<dandel> the broken part is that the top half registers 0.00 seconds.
<apw> bjf, do you know what happened to the writeback patches for lucid ?
<bjf> apw, were those the ext4 patches or others?
<apw> the ones called 'writeback:' i am referring to i think :)
<bjf> apw, will take a look
<apw> dandel, well when i make it 2s then the Time Difference is still 0 on the usleep on
<apw> and yet it visibly and clearly sleeps
<dandel> i know, but for some reason there is a problem with the functions registering the change in clock time.
<bjf> apw, cooloney daily iso busted for me as well
<dandel> the time function i would expect this out of, however the clock should not be doing this.
<apw> dandel, indeed, but the delay is occurng
<apw> so ... something else is odd
<cooloney> bjf: thx, too bad. so we need to file a bug for syslinux?
<dandel> I need to find out where i am supposed to bug report this to.
<apw> dandel, this isn't a bug, its correct
<apw>        The clock() function returns an approximation of processor time used by
<apw>        the program.
<apw> clock() is telling how long you have been running, that won't increment when in a sleep
<apw> dandel, ?
<dandel> I'm looking into something.
<apw> maxb, fyi you can confirm if thats the issue, by manually sync'ing before you hit exit
<dandel> now it's somewhat working, although sometimes the program will get the values inverted (which is strange)
<bjf> apw, are you referring to: https://lists.ubuntu.com/archives/kernel-team/2010-June/010889.html
<cooloney> tgardner: just shot by your checkpatch email.
<cooloney> tgardner: i'm wondering what's the right way to solve this issue
<apw> bjf yep thats the series indeed
<bjf> apw, sconklin and i are discussing it
<sconklin> it appears to have fallen through a crack
<tgardner> cooloney, make them fix their patches and resubmit ?
<miked595> I'm running the i7-980x cpu which has 6 cores and with hyperthreading makes 12 threads. My cpuinfo and mpstat only see 8 threads. mpstat > Linux 2.6.32-24-generic-pae (sysops) 07/27/2010 _i686_ (8 CPU). I have tried setting maxcpus past 11 in grub but it has no effect. Any ideas on what I should try next?
<cooloney> tgardner: yeah, i am going to do that
<cooloney> tgardner: since sebjan will be on vacation, i will do that tomorrow. 
<cooloney> tgardner: sorry for missing running checkpatch.pl,
<tgardner> miked595, you are screwed: debian.master/config/i386/config.common.i386:CONFIG_NR_CPUS=8
<mjg59> miked595: CONFIG_NR_CPUS=8
<mjg59> miked595: Rebuild your kernel or run 64-it
<mjg59> 64-bit
<miked595> *sadface*
<miked595> any easy way to upgrade to 64bit without a reinstall?
<miked595> tgardner: mjg59 gonna take a stab at building my own kernel. thanks
<tgardner> miked595, start here: https://wiki.ubuntu.com/Kernel
<miked595> tgardner: I went there when I first got in this channel.. was kind of lost
<tgardner> miked595, one of the pointers is to here: https://wiki.ubuntu.com/Kernel/Dev
<miked595> tgardner: I'll read that too
<apw> miked595, i am told you can get the 64bit kernel and force it on too, ignore the arch error ... not that i have ever tried it
<miked595> found a tutorial going through "make menuconfig" now. anytips other then CONFIG_NR_CPUS
<tgardner> miked595, it might be simpler to just edit it directly, then run debuild
<miked595> tgardner: first time ever doing this. so all the previous options in the source would not already be selected here? It isnt me just editing the current option then?
<miked595> it does show "Support for big SMP systems with more than 8 CPUs"
<miked595> unchecked
<tgardner> miked595, ah, I forgot about that one. you might be betrter off going through the editconfig phase
<miked595> what is the diff between editconfig and menuconfig? tgardner
<tgardner> miked595, editconfig uses menuconfig
<diwic> meeting in three minutes, right?
<diwic> in #ubuntu-meeting?
 * apw hopes not
<bjf> diwic, no in two hours
<apw> its at 17:00 UTC i think
<tgardner> diwic, methinks you forgot to restore yuor home timezone on google cal
 * diwic thinks UbuntuPlatform/Kernel needs serious updating then
<diwic> It says 1500 UTC then
<diwic> s/then/there
<bjf> ##
<bjf> ## Kernel team meeting in two hours
<bjf> ##
<apw> diwic, yep, why that is info is duplicated on that page I do not know
<apw> we should have one listing and one listing only ... will rmeove that reference and point it at the public wiki
<diwic> yes please
<apw> but no you are not going mad
 * ogra thought that was a prereq for the kernel team 
<ogra> or an aussie accent
<apw> no just drinkiing
<ogra> heh, k
<apw> diwic, ok that errant copy is beating into submission
<diwic> apw, put the old text in the pit! Just like in robot wars! 
<miked595> tgardner: compiling
<apw> yep and send in one of those spinning disk monsters to trash it
<tgardner> miked595, you can shortcut the build process and only build the flavour you want, e.g., 'fakeroot debian/rules clean binary-generic-pae'
<apw> bjf, did that stick boot ok ?
<miked595> tgardner: i ran this "fakeroot make-kpkg --initrd --append-to-version=-sysops kernel-image kernel-headers"
 * diwic reschedules the evening and will return in two hours.
<tgardner> miked595, as a newbie you shouldn't stray off the reservation quite so far.
<bjf> apw, having disk space issues, resolved now, am building stick
<miked595> tgardner: hehe was just following the tutorial
<bjf> apw, a live image from july 12, usb stick created on lucid, boots just fine
<tgardner> miked595, indeed. Can you give me a pointer? make-kpkg is a bit outside our normal build process.
<tgardner> we're in the process of cleaning up the wiki pages, so there is still some cruft around
<bjf> apw, today's iso, usb stick created on maverick, is booting fine
<apw> bjf ok thats about right as thats before the 13 days ago when the change occured
<miked595> i think he they got their info from here https://help.ubuntu.com/community/Kernel/Compile tgardner which shows 'Now you can compile the kernel and create the packages:
<miked595> make-kpkg clean # only needed if you want to do a "clean" build
<miked595> fakeroot make-kpkg --initrd --append-to-version=-some-string-here kernel-image kernel-headers'
<bjf> apw, so you have to have a maverick already, to create a maverick boot disk, sweet!
<apw> bjf, hehe currently ... yes
<tgardner> miked595, good luck with that. the only build method I'll support is in https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<apw> it seems a pretty blocky type bug, so we need to figure out how to fix it
<miked595> tgardner: Ill try that too. I didnt think the custom compiles were supported 
<miked595> main reason I was trying to avoid it
<tgardner> miked595, we'll help you out a bit as long as you aren't straying too far from the norm. a good deal of the info in  https://help.ubuntu.com/community is just shite.
<maxb> apw: Thanks for the thought about sync, but unfortunately it doesn't work - the sync takes ~400ms, and then every subsequent umount *still* takes ~400ms
<miked595> tgardner: nice I'll now to stay away from it
<apw> maxb, ok ... tsk ... sconklin/bjf so do we have  a test kernel with the writeback stack applied for testing?  sounds like we have an avid tester
<sconklin> apw, maxb: no, but I can spin one right now
<maxb> Don't rush, I won't have time today, but feel free to leave me some instructions here to test something tomorrow
<sconklin> maxb: good deal, I'll have one in a few hours then, and leave a pointer in irc
<maxb> Or, just tell me what to build - that works too :-)
<sconklin> maxb: I have access to a very fast build machine, and can turn this pretty fast
<sconklin> besides, this will make it available to anyone else wanting to test
<apw> sconklin, good plan
<miked595> ok it's done wish me luck
<apw> ok so this image issue is not trivial to fix as we need to run syslinux to install it onto the new image, which means it needs to be a locally runnable thing
<apw> ie compatible with the host ...
<apw> bjf, ok you can work round the incompatibility on the post-built images by running this on them
<apw> sed -i -e 's/ui gfxboot/gfxboot/' /media/USBSTICK/syslinux/syslinux.cfg
<shadeslayer> \o
<shadeslayer> we recently got this mail http://pastebin.com/9X26M2ts
<shadeslayer> and were wondering if /proc/sys/fs/inotify/max_user_watches can be increased
<shadeslayer> currently its 8192
<shadeslayer> whereas the suggested value is 524288, can something be done about it?
<jjohansen> shadeslayer: you can set that value just by echo a value into it as root
<jjohansen> echo 16384 >/proc/sys/fs/inotify/max_user_watches
<jjohansen> you should also be able to throw a value into /etc/sysctl.conf
<jjohansen> or /etc/sysctl.d/
<jjohansen> see > man 5 sysctl.conf
<jjohansen> rebooting
<shadeslayer> wow.. long reboot ^
<shadeslayer> or something went wrong :P
<shadeslayer> also.. im on btrfs on maverick, but the boot takes alot of time, i think its because btrfs tools tries to fsck the partition but fails to do so, any suggestions ?
<cnd> tgardner, in regards to linux-firmware licencing
<cnd> I thought only licenses that were very large needed their own file
<cnd> if it was a very small licence, like 2-4 lines, then putting it in WHENCE was fine
<tgardner> cnd, what would Woodhouse do? Looks like they are all in their own LICENSE files.
<cnd> tgardner, some of the existing firmware licenses are just like that
<cnd> no LICENCE.* files
<cnd> but the licence is in WHENCE
<shadeslayer> jjohansen: i just wanted to make sure that if we modified it via our packages it would be fine for you 
<shadeslayer> s/for/by
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
<tgardner> cnd, do those license entries make it into the package?
<cnd> tgardner, I'm not sure, does the WHENCE file make it in?
<tgardner> cnd, I don't think so. I think to be compliant with debian policy we need to separate out those license entries so that they make it into the packaging.
<cnd> tgardner, WHENCE is renamed to README when it's packaged
<tgardner> cnd, hmm, I suppose thats just enough.
<cnd> tgardner, https://code.launchpad.net/~private-sparsha-dev/sparsha/gesturetest
<cnd> oops
<cnd> argh
<cnd> why does middle click never work right anymore
<cnd> /usr/share/doc/linux-firmware/README.gz
 * diwic listens to the outcome of this conversation.
<tgardner> cnd, well, you can update the bug refuting my position
<cnd> ok
<tgardner> cnd, I'd still like to see a separate WHENCE.ubuntu for Maverick
<cnd> tgardner, I think that's a good idea
<cnd> I'll add it to me todo list :)
<diwic> When must upstream merge it for us to avoid that whence-file?
<cnd> diwic, we've had difficulty getting upstream to merge our additions
<cnd> so unless something changes, I think we'll definitely need it one way or another
<apw> cnd, you don't have a middle button ...
<cnd> apw, I have shift+insert
<cnd> (and I do on my magicmouse :)
<cnd> same difference
<diwic> cnd, tgardner: Just to clarify, do you currently expect me to do something?
<cnd> diwic, I think your changes are fine
<cnd> there aren't any long licenses there that I can remember
<cnd> the other stuff is just firmware packaging maintenance that I will get to sooner or later
<sconklin> maxb: kernels are here: http://kernel.ubuntu.com/~sconklin/kernels-bug543617/ I'll update the bug with the same link
 * maxb prepares to afk for beer, but will investigate tomorrow
<maxb> bug 543617
<ubot2> Launchpad bug 543617 in linux (Fedora) (and 3 other projects) "Unmount of an fs with dirty cache buffers causes pathological slowdown (affects: 9) (dups: 2) (heat: 101)" [Unknown,Unknown] https://launchpad.net/bugs/543617
<sconklin> apw: are the writeback patches in maverick? I'm trying to get the bug status sorted
<maxb> sconklin: Does your build also revert the temporary SAUCE mentioned earlier in the bug?
<sconklin> maxb: sigh. I'll check. I thought it had already been dropped
<maxb> sconklin: oh, maybe it has
<maxb> I didn't check
<maxb> sconklin: The fact I'm seeing this problem at all is suggestive that it has _not_ been dropped.
<sconklin> maxb: No, it wasn't dropped. I'll fix it.
<sconklin> I wish (again for the 10,000th time) that launchpad would let me delete or edit a comment
<manjo> please check your credit card statements & any accounts you logged in while in prague, I got some suspicious charges on mine, looks like it happened while I was connected to the hotel wireless (but that is just a guess)
 * tgardner lunches
<apw> sconklin, i think they may be in -rc6
<sconklin> apw: ok, thanks. I'll just set that line in the bug to invalid. It was targeted for 10.04 anyway.
<apw> or fix released as it was affected originally
<ogasawara> pft, 2.6.35-12.17 on ia64 isn't queued to build for another 2 days.
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - August-03 - 17:00 UTC
<shadeslayer> er... is anyone looking into btrfs issues?
<apw> shadeslayer, do we have any btrfs issues ?
<shadeslayer> apw: i do
<apw> with which kernel
<apw> and what sort of issues
<shadeslayer>  Linux kubuntu 2.6.35-11-generic #16-Ubuntu SMP Sat Jul 24 21:37:44 UTC 2010 x86_64 GNU/Linux
<shadeslayer> ok so when i boot, the boot seems to be stuck at btrfs tools trying to fsck the partition
<shadeslayer> ive been informed that this is a reported bug and btrfs.fsck can only fsck when the partition is offline
<shadeslayer> so something needs to be done to either fix btrfs tools, or not fsck at all ( which is a BAD option )
<apw> hrm sounds like a major limition ... presumably that renders it unsuitable for a root fs
<shadeslayer> ^ totally
<ogasawara> jjohansen: I'm seeing build failures for armel with apparmor http://pastebin.ubuntu.com/469927/
<shadeslayer> apw: so my boot goes from a 20-25 sec boot to 40 sec boot
<shadeslayer> lemme see if i have a bootchart
<apw> sounds like btrfs is just the bees-knees
<shadeslayer> :P
<jjohansen> ogasawara: okay, that should be an easy fi
<jjohansen> s/fi/fix
<shadeslayer> apw: http://imgur.com/fPdyF
<shadeslayer> please guys.. can you fix it in alpha 3 ? :D
<shadeslayer> ill be reformatting my system to ext4 this weekend because of this :S
<apw> shadeslayer, shouldn't think so :/
<apw> yeah its not ready for prime time is it
<shadeslayer> had high expectations from BTRFS :(
<shadeslayer> apw: yep
<apw> the authors told us it would save us from world hunger ... its a bit short of that
<shadeslayer> i really wouldnt give out that option in the installer, since its this sucky
<shadeslayer> apw: so what can be done?
<shadeslayer> im ready to test .. but only till this saturday
<shadeslayer> then i format everything :P
 * ogasawara lunch
 * shadeslayer is still waiting for a answer from apw
<kees> ... how does armel not have vmalloc?
<kees> or is it just a missed include that only manifests on armel?
<kees> jjohansen: ^^
<jjohansen> kees: it does, its just missing from one of the includes, lib didn't include it directly
<kees> *whew*
 * jjohansen has patched and is setting up new pull request
<jjohansen> -> Lunch
<sconklin> ok maxb there are new test kernels
<squarebracket> any chance we can get the newest linuxwacom module in the next kernel release? it sucks having to recompile every time, not to mention the fact that new users have no idea what that means
<komputes> I'm having this issue with a Dell Precision T7500 Workstation - https://bugs.edge.launchpad.net/ubuntu/+bug/579572 - I have tried rootdelay=60 but that doesn't work
<ubot2> Ubuntu bug 579572 in ubuntu "Lucid: Gave up waiting for root device (mptsas) resolved by rootdelay (affects: 3) (heat: 64)" [Undecided,New]
<komputes> Second question, Can I install a mainline 386 kernel when a pae kernel was previously there?
#ubuntu-kernel 2010-07-28
<mozmck> how do I make an ubuntu kernel source package for my customized ubuntu kernel?
<komputes> mozmck: Would this do it? https://help.ubuntu.com/community/Kernel/Compile#AltBuildMethod
<mozmck> komputes: I don't know, but I just used this command and got .tar.gz and .dsc files of the source: dpkg-buildpackage -S -us -I.git -I.gitignore
<mozmck> so I think that's what I needed.
<komputes> good to hear
<squarebracket> any of the devs around?
 * apw yaens
 * apw yearns for a keyboard with the keys where he seems to think they are
<RAOF> Is that a Scottish yawn?
<apw> heheh ...
<apw> RAOF, so how are we doing in maverick ... graphics wise?
<RAOF> Our plymouth/bootup fandangaling remains a source of endless frustration.
<apw> yeah plymouth seems to be tickling at least three bugs in the kernel
<RAOF> Apart from _that_, things are going nicely.
<RAOF> vesafb seems to be crazifying thnigs a bit, too.
<apw> i _think_ i have a reliably bootng kernel now at least on my worst affected test box
<RAOF> :)
<apw> that of course does not include getting the damn splash in the right format so it doesn't look like someone vomited on the screen
<ogra> apw, talk to kwwii 
<apw> ogra, any idea where they hang out?
<ogra> #ubuntu-art (or artwork) or in #ayatana i think
<hego> hello, i seem to be experiencing some troubles with my fglrx driver in maveric with kernel 2.6.35. It just won't install, the bug report says that it won't build... why is that?
<Sarvatt> hego: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
<Sarvatt> fglrx is only going to work for a few more days in maverick though, will be broken once xserver 1.9 goes in
<hego> Ok, thanks
<hego> And what should i do when it gets broken?
<hego> Wait?
<hego> well, nvm. Thank you SO much!
 * cooloney using checkpatch.pl to fix coding style
<cooloney> apw: found some issue about the checkpatch
<apw> cooloney, that happens
<apw> its cirtainly not perfect
<cooloney> apw: http://pastebin.ubuntu.com/470152/
<apw> what you found wrong with it?
<apw> yep thats a bug, and you should ignore it from a submission stand point
<apw> do send that to me in email
<cooloney> apw: i have to say the code from TI is a good testcase of checkpatch.pl
<apw> heh i bet
<cooloney> apw: np, man.
<cooloney> i assume i can fix the coding style this morning, 
<cooloney> just found it took me all the morning to fix one patch
<cooloney> just one patch
<apw> heh
<cooloney> actually their originally code is "MCBSP3_DMA_TX*ATC_SIZE,"
<cooloney> checkpatch.pl reported the same error
<apw> you can just ignore that complaint, it is wrong, the rules for * is either x*y or x * y, just be same cosistent
<cooloney> even if i changed it to "MCBSP3_DMA_TX * ATC_SIZE,"
<cooloney> yeah, thx
<cooloney> will email you later
<apw> the official style is either, the bug is matching that as a type
<cooloney> apw: how about this one?
<cooloney> ERROR: need consistent spacing around '-' (ctx:WxV)
<cooloney> #10695: FILE: sound/soc/codecs/abe/abe_typ.h:26:
<cooloney> +#define MAX_UINT8	((((1L <<  7) -1)<<1) + 1) ^
<apw> is that - a subtraction ?
<apw> i thnk it is, then it should be either )-1) or ) - 1)
<cooloney> http://pastebin.ubuntu.com/470167/
<cooloney> oh, sh*t,
<cooloney> my bad
<apw> yep that is clearly meant to be a subtraction so the code is wrong
<cooloney> i gonna crazy today
<cooloney> #define MAX_UINT8((((1L <<  7) - 1)<<1) + 1)
<cooloney> is this right?
<apw> i would also put spaces round the second <<
<cooloney> yeah, i always do that.
<apw> as you are not being consistant on the spaces both sides or not spaces both sides there
<cooloney> #define MAX_UINT8((((1L <<  7) - 1) << 1) + 1)
<apw> yep
<apw> well space after the INT8 and before the (
<apw> its not a function
<apw> and cpp will do the wrong thing
<cooloney> #define MAX_UINT8 ((((1L <<  7) - 1)<<1) + 1)
<apw> << undone again
<cooloney> who wrote this code, i wanna kill him
<apw> not me :)
<cooloney> #define MAX_UINT8 ((((1L <<  7) - 1) << 1) + 1)
<cooloney> wonderful code
<cooloney> thx a lot man
<apw> looks fine to my eye
<cooloney> yeah, me2.
<cooloney> feel much better
<cking> there is a double spacing between <<   7 by my eye
<cooloney> cking: good catch
<cooloney> #define MAX_UINT8       ((((1L <<  7) - 1) << 1) + 1)
<cooloney> #define MAX_UINT16      ((((1L << 15) - 1) << 1) + 1)
<cooloney> #define MAX_UINT32      ((((1L << 31) - 1) << 1) + 1)
<cooloney> that's the code
<cking> ok, that's ok then ;-)
<cooloney> they wanna make it beautiful
<cooloney> add one more space between << and 7
<cooloney> apw: i got tons of warning about line over 80 characters
<cooloney> most of them are in the header files for some macros and registers. 
<cooloney> is that ok to keep them. 
<cooloney> otherwise most of their header files code need to rewrite
<apw> its frowned upon unless they only look sensible in that form
<apw> always what looks best and is most readable is the correct form
<cooloney> apw: ok, understand
<cooloney> and how to deal with WARNING: do not add new typedefs
<apw> heh .. don't add them :)
<apw> generally unless they are in the core official typedefs like atomic_t etc they are not beneficial is the thought
<cooloney> apw: right, that's duplicated. but i cannot remove them, it is used by tons of code
<cooloney> let me keep it and let them to fix it
<apw> yep
<apw> it all depends on the typedef in the end of the day
<cooloney> just got this ONE patch totally crazy
<cooloney> looks like an alien wrote this code
<andreoli> Hi, what is the exact procedure to build a kernel source package of a modified Ubuntu kernel, suitable for upload to a PPA? This link (http://tjworld.net/wiki/Linux/Ubuntu/Kernel/CustomBuildPPA) is showing one that does not work for me (missing debian/changelog)
<apw> andreoli, you probabally need to clean the tree 'fakeroot debian/rules clean' to get the changelog
<andreoli> ok, thx. Now, debian/rules tells me there's no rule to make target "print-ppa-file-name". I guess the prepare-personal-ppa-source script is obsolete. Can you point me to any docs explaining the current way of building and uploading a kernel source package to a PPA?
<apw> andreoli, the source package for a ppa is the same as a normal upload package, and that is in the maintenance document.  someone is writing a simpler one but its not present today
<andreoli> ok, thx. So upload to a PPA shouldn't be a problem. But I'm a bit confused about building kernel packages. I know how to build a binary kernel package (https://help.ubuntu.com/community/Kernel/Compile) but, as far as I understand, I need a source package for PPA upload. I think I don't understand how to create a kernel source package from the ubuntu git repositories.
<andreoli>  So I'm asking you: is the procedure for building a source package (described here: https://wiki.ubuntu.com/PackagingGuide/Complete) still valid for building a kernel source package, or do I need to do something different?
<diwic> andreoli, dpkg-buildpackage -S ?
<apw> andreoli, there is a specific guide for the kernel
<apw> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<apw> see 'preparing an upload'
<apw> from after where you tag ...
<apw> basically the clean, then the buildpackage -S
<andreoli> apw and diwic, thx for your help. I'll try it now.
<apw> andreoli, luck
<tgardner> apw, how's your plymouthd race condition patch(s) coming?
<apw> i have something which seems to work in broad brush and gives userspace some hope of coping
<apw> they are a bile unpleasant in some senses
<tgardner> time to get some other eyeballs on it?
<apw> tgardner, close too ... i am just building the first set whihc is a 'clean' set of patches not just 100 commits
<apw> with all the deubggin out etc to prove to myself they work without
<apw> then yes... i'll want to send them out to us lot 
<apw> the cleanup process is the highest danger of losng the fixing ... grr
<apw> but last night i did get 20 sequential boots without a problem
<apw> so i think its there
<tgardner> apw, cool. I was just looking for something to do this morning, so rather then actually produce something I thought I'd just pick on you :)
<tseliot> apw: are you saying that you can make sure that grub doesn't interfere with plymouth and with the graphics driver?
<tseliot> if so, I'd love to see your patch
<andreoli> I guess I should be using debian.master/rules ... instead of debian/rules
<andreoli> never mind, forgot to fakeroot debian/rules clean
<apw> tseliot, this is a different issue, that the kernel is sensitive to plymouthd getting to the framebuffers while they are initialising
<apw> tseliot, that we boot so fast we are tickling a number of bugs in initialisation and crashing ... the current boot instabilities
<andreoli> problem: git log shows my changes, but debian/rules insertchanges won't insert them into debian/changelog
<tseliot> apw: ah, ok. It looks at least as nasty as a race condition ;) and of course I'm still interested in the patch
<apw> tseliot, yes there are two, one is that the drm driver advertises the existance of the drm devices _before_ it calls load on the driver ... so a process can see and open /drv/dri/card0 or whatever before the i915 etc part of the driver has finished initialising itself ... leading to explosions
<apw> tseliot, the second is a bug in the frambuffer code which essentially renders it unsafe to unregister one... which is procisly what drm does. ... again we have a race triggered by udev gettting to the party real quick
<tseliot> apw: ok, now I can see why things were failing despite the fact that the drm device was reported as being there...
<apw> yep ... its just not ready, and random behaviour results.  i think plymouthd finds no screens (as they arn't there) and immediatly closes the device ... and blows the kernle up as its still instantiating it
<tseliot> ouch, I'm curious to see how you're going to handle the second case. I guess I'll have to wait until your patches are complete
<apw> tseliot, i delay a critical hashing of the minor number to the driver until initialisation is complete.  this renders the /dev/dri interfaces unsable until its ready
<apw> i've tried to do it in such a way we could either loop in the kernle, or as it does now, return EAGAIN to userspace such that userspace can be fixed to retry
<apw> we still have no solution such that plymouth is in sync with which buffer to use etc
<tseliot> it seems like a good idea
<tseliot> ah, it could try using the wrong buffer
<apw> i have tried to prevent the instantiation of the udev stuff until after, but the driver assumes they are there such that it can send out udev events
<apw> such as hotplug ... so likely this is a tape over job, and a proper much larger solution needed from upstream
 * tseliot nods
<apw> i suspect if i am crafty glibc will retry the open
<bjf> diwic, moin
<diwic> bjf, hi there
<bjf> diwic, did you get a mentor assigned to you and regardless of that, do you have mumble installed?
<JFo> brb Reboot
<ericm> apw, ping
<apw> ericm, pong
<ericm> apw, what needs to done every time after mvl-dove branch is rebased against master?
<apw> as in once the rebase is done, what happens ?
<ericm> now suppose you need an upload of mvl-dove, what needs to be done?
<ericm> fdr startnewrelease?
<ericm> getabi?
<apw> to do an official one, yes you need a newrelease (which includes the abi updates) then an insertchanges, the make clean, make the source package, and upload it
<ericm> and normally because the rebased mvl-dove carries over the previous tag commit like "UBUNTU: Ubuntu-2.6.32-207.20"
<apw> ericm, right, you should do a startnewrelease with abi stuff
<apw> then you should ubuntu-insert-cchanges with the old and new base
<apw> and commit that as 'UBUNTU: rebase to <new release>'
<apw> then insertchanges sort of thing
<apw> making any sense ?
<ericm> yep, I'll make a test run here and let you know if I don't understand something
<apw> ericm, though normally for stable releases the stable team does this lot for you
<ericm> apw, yeah that saves me a lot trouble, but now I need to upload a kernel for a oem branch, which is conceptually a similar thing
<ericm> apw, still a bit confused, e.g. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/mvl-dove
<apw> ericm, how are you confused.  that looks ok
<ericm> apw, so commit 'UBUNTU: SAUCE: dove: avoid page table overwrite when...' is actually the tip of what's rebased against tag '2.6.32-24.38' in master branch?
<apw> its the newest patch on the branch yes, your rebasing onto our master by definition leaves the same tip patch on the top
<sconklin> http://en.wikipedia.org/wiki/List_of_Ubuntu_releases
<trapmax> i'm trying to create an lvm-snapshot. my machine just gets stuck there. here's the kern.log http://pastebin.com/KUzVGZSQ
<andreoli> thx all, I think I just prepared my first kernel source package :) Now I have a problem: I have a file named "linux_2.6.32-24.39_source.changes". The PPA packaging guide (https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage) tells me to use a linux_2.6.32-24.38-ppa1~lucid1 name.
<andreoli> How do I enforce this? Is there any command that I can use to change the package name? Or is a simple "mv linux_2.6.32-24.39_source.changes linux_2.6.32-24.38ppa1~lucid" enough?
<abogani> andreoli, You should change the debian/changelog accordingly
 * abogani waves all!
<andreoli> abogani, I tried to do it through the debian/rules insertchanges script, but it seemed to fail silently (it did not apply my git log to debian/changelog). Should I modify the changelog manually?
<abogani> andreoli, dch -i 
<andreoli> thx
<andreoli> So, is it expected for debian/rules insertchanges to fail unless the upload is official? And in case of unofficial uploads, I have to insert the changes interactively through dch -i?
<apw> andreoli, not if you followed the standard no
<apw> that doesn't add it to debian/changelog, but to debian.master/changelog
<apw> debian/changelog is generated by the clean processing
<ogasawara> JFo: around today?  was just looking at the kernel-maverick-firewire-stack blueprint.  seems there's just one item left that belongs to you, "triage and maintain a list of bugs reported on the new firewire stack".
<ogasawara> JFo: I did an informal search in launchpad -> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=firewire&orderby=-datecreated&field.tag=maverick
<ogasawara> JFo: it didn't seem to turn up anything significant
<ogasawara> JFo: did you have something separate in mind for tracking this list of firewire bugs (if any)?
<andreoli> apw, thx for your response. My modifications don't seem to have been added to debian.master/changelog. I am modified a local git branch. I'll read the docs again.
<andreoli> (modified and commited)
<JFo> ogasawara, I'm here
<JFo> ogasawara, my main hope was that those individuals that tested would let me know if they found bugs and filed them
<JFo> no one told me that they had
<ogasawara> JFo: that's good then
<JFo> yeah, I know of no issues with the new stack
<JFo> want me to set that to DONE?
<ogasawara> JFo: sure
<JFo> or have you got it already?
<JFo> cool
<JFo> will do
<andreoli> another question; should the changelog be for lucid or for lucid-proposed?
<apw> JFo, and we have confirmed its turned on?
<apw> andreoli, lucid for a PPA
<JFo> apw, I am under that impression yes, but I defer to manjo 
<JFo> my understanding was that it was turned on before we sent the CFT
<ogasawara> JFo: I was under the same impression
<manjo> for lucid ? 
<ogasawara> manjo: maverick
<apw> JFo, ogasawara, confirmed that in maverick the blacklist is inverted
<apw> so if we have exactly 0 bugs we must be reasonably ok
<JFo> grrr, screen corruption
<apw> those damn mac users must have firewire for everything i am sure
<JFo> need to reboot
<JFo> brb
<bjf> manjo, what is your timeframe for having the kernel-qa tests ready for addition into kteam-tools?
<manjo> I should be able to send a pull request this week
<apw> ok so lets plan on doing that friday
<bjf> manjo, wfm
<manjo> have a couple of dell things I am busy with atm
<apw> well if you don't get to it, we can just pull in the officail verion and you can work agianst that
<manjo> apw, I will have it by fri
<apw> good enoug
<apw> enough
<JFo> k, I'm back
<JFo> I agree 0 bugs means we are good
<manjo> :)
<manjo> do we know if people are testing it ? 
<JFo> yes, we have had feedback from several people on the list
<JFo> <-lunch
<manjo> cool!
<manjo> fedora already had it turned on for a number of releases so I did not expect anything bad to happen in our case 
<andreoli> interestingly, running the git log 087ca8b7e71139f7a0b21a5ad82f1ce7031daf28..HEAD | perl -w -f debian/scripts/misc/git-ubuntu-log works properly
<andreoli> trying to achieve the same through debian/rules insertchanges does not work
<apw> sconklin, tgardner that dodgy frequency relaxing patch for ironlake monitor frequency (the one which changes >> 10 to >> 9) seems to have hit stable
<sconklin> apw: yes, I think Manjo is planning to send it to u-k-l
<tgardner> sconklin, well, why would he have to? We'll get it naturally as part of stable
<manjo> tgardner, so that will be in the kernel next 3 weeks or so ? 
<tgardner> that'll happen anyway
<manjo> asking so that vanhoof has an idea of time line 
<tgardner> I think we've made it clear that the stable update and SRU process is not deterministic
<apw> and he was there for that discussion ..
<vanhoof> apw: right
<vanhoof> im not asking when it will be released
<vanhoof> i was more interested in making sure its proposed
<sconklin> Actually he was also there for a discussion about how the patches could land in proposed within a couple of weeks provided they were in stable upstream and the security release went as expected.
<apw> proposed for inclusion, or "in proposed"
<vanhoof> apw: proposed for inclusion
<apw> right they should indeed be in proposed pretty soon in the normal run of things
<apw> so i'd say if we are going to have that stable release in the next -proposed we rely on that, if we have too much stacked already to take the whole stable then we do it as one on its own
<apw> ogasawara, does the -12 kernel use the new compilers
<apw> JFo, have we or are we considering a call for testing on the new compiler/M686 combination ?
<ogasawara> apw: yep
<apw> i wonder if the announcement should have said that ...
<ogasawara> apw: QA team should have results as well and relay them to us
<apw> ok cool
<apw> with all the graphiics issues, i suspect their testing will be 'its broken' both sides of the line
<ogasawara> apw: yah, I should have noted that in the announcement
<ogasawara> apw: scratch that.  the -11.16 was actually the first to be build with the new compiler/M686 combo, and I noted it in that announcement
<apw> ahh cool... my mistake
<bjf> ogasawara, where can I get the -12.17 kernel from?
<andreoli> I think I got the problem. It seems I have to debian/rules startnewreleas in order to get the "  CHANGELOG: " tag into debian.master/changelog.new. Then, debian/rules insertchanges works as expected. Problem is, I have to change the version name by hand. I'll do that.
<ogasawara> bjf: https://edge.launchpad.net/ubuntu/+source/linux/2.6.35-12.17/
<apw> ogasawara, its amusing that tgardner's PPA had the same kernel before the archive :)
<apw> (which i've been running for two days)
<tgardner> apw, well, I didn't have to wait on the tool chain
<apw> tgardner, ahh good point
<apw> still good results ... so far ok for 2 days
<tgardner> apw, did the writeback patches help performance? (or am I thinking of 2.6.32 stable)
<apw> hrm not sure, i've not notices much in the way of issues
<apw> ogasawara, i'll try and get you some patches for review today ... i have some obvious ones which should go in
<apw> you are aiming for either friday or monday depending on linus i believe
<ogasawara> apw: hoping for friday, but yes waiting to see if 2.6.35 final drops
<apw> i guess upload friday with whatever you have, and then see on monday?
<apw> this damn console issue is going to kill me before long, now the console switcher has broken
<ogasawara> apw: yep, that was my plan
 * apw removes his mind-meld
<apw> ogasawara, you got the release meeting on friday? 
<ogasawara> apw: yep
<ogasawara> apw: take the day off
<apw> cool then i think i am going to take friday as a comp day
<manjo> apw, drm fixes should go to 2.6.33 or 32.y ? 
<manjo> sconklin, ^ ?
<apw> generally when submitting to stable you are saying 'this should go anywhere it applies'
<apw> and indicate places known to be affected
<manjo> ok coz I need to do some backporting 
<manjo> the patches don't apply cleanly to 32 or 33
<apw> grr
<sconklin> manjo: yes, what apw said
<manjo> apw, so I need to pick a tree and backport
<apw> if you can supply ported ones then you will be much more popular, .33 is what we need, which may mean .34 in some senses
<manjo> ok so I will port againt .33 sounds resonable ? 
<apw> we 
<apw> we need it there regardless
<manjo> I thought you said 'yes' in french
<tgardner> manjo, I had to backport a hostap_cs patch to each stable release, so I sent stable 4 separate patches
<apw> probabally worth noting we need to test them before sending them
<manjo> apw, tested against lucid 
<manjo> which is 2.6.32+~33
<apw> yep the backports though need testing where possible
<manjo> tgardner, I am going to send stable port against .33 1st so that it will make it to lucid, 1st prio, then send them others later if required ?
<tgardner> manjo, I take it that this is a DRM patch? 
<manjo> apw, I can have james from OEM team test the backport
<manjo> yes
<manjo> tgardner, yes
<tgardner> then .33 is likely the oldest kernel to which it applies anyway
<apw> manjo, yep i don't mean you have to test necesasarily but sending broken things to stable makes you die horribly
<manjo> tgardner, ok cool that is the ans I was looking for 
<manjo> apw, yep understood 
<manjo> Q2: do we include buglink: ... in the patch ?
<manjo> like we did for SRU ?
<tgardner> manjo, since you have to update the commit log anyways to explain that this is a backport, then you might as well include the buglink.
<tgardner> I guess if Greg doesn't like it he'll either elide it or make you do it over
<apw> i say for that i'd tend to put it in the s-o-b block
<sconklin> I'm looking at our SRU policy - can anyone tell me why the retention times are specified like this?:
<sconklin> "Uploads containing a upstream stable patchset increase the retention period to two weeks, while it is one week otherwise."
<sconklin> wouldn't we consider upstream patches to be better tested than otherwise and thus requiring less time to bake?
<sconklin> Should we just make it two weeks regardless?
<ogasawara> sconklin: smb would know for sue, but I think that was originally written because of the size of some of the stable patch sets and the SRU team thus preferred a longer baking period
<ogasawara> sconklin: I'd say just make it two weeks regardless.  I don't think I've seen kernels promoted after only 1 week anyways.
<sconklin> ogasawara: thanks. Yeah, I'll check with smb, but I think a flat two weeks is good policy
<apw> sconklin, thats because the updates in a stable block are not known to fix an issue someone is seeing, so more care is needed
<sconklin> apw: yes, but we seldom actually get any feedback that a proposed kernel has fixed anything for anyone, so whether issues are fixed don't see to be related to the bake time - only whether we get reports of regressions
<sconklin> don't seem
<apw> right its about the expection that there is more likelyhood of a regression in 100 patches than the 10 we'd have otherwise
<apw> so it needs longer to shake out
<apw> remember on average we add 5-10 sru patches and 150-300 stabe patches in an update
<sconklin> apw: point taken.
<apw> damn recursion error ... i've printed something for every update to the console, which includes the printing ... DAMN
<sconklin> But - I think the opposite is true, that stable patches are less risky. As an example, look at the "temporary" patch that was put in Lucid for the file system unmount delay, which caused a new error.
 * JFo goes to take meds and nap a bit
<JFo> bbl
 * sconklin needs meds
<sconklin> and I don't have the flu :)
<apw> sconklin, well indeed, and look at the ones we have put in in stable and had them reverted in the next stable
 * JFo just got some at lunch... here's hopng they help
<apw> so ... its all much of a muchness
<sconklin> apw: I suppose that the biggest lesson is that there's no substitute for adequate QA
<apw> the wording as there was a result of talking to the sru people who didn't want to take them at all, but said if we soaked them longer they would not whine too much
<achiang> does lucid support ext3's data=guarded mode?
<achiang> i don't see anything in Kconfig regarding it. i haven't poked into the source just yet
<achiang> hm, git grep guarded doesn't seem like it's there
 * ogasawara lunch
<achiang> just a followup, data=guarded isn't even upstream. not sure what happened to it, but oh well.
<jjohansen> -> lunch
<manjo> sconklin, have you seen this ? http://www.arrl.org/ubuntu-linux-for-hams
<sconklin> manjo: yes, thanks
<sconklin> manjo: I've already exchanged email with the author
<manjo> sconklin, cool!
<sconklin> he's not happy about nvidia in Lucid
<apw> heh, then she should have tested it when it was fresh
<apw> sconklin, ^^
<sconklin> apw: wrong side of the chasm
<apw> bah
<apw> its like taking responsibility for anti-social behavour in your neighbourhood
<apw> you should also take responsibility for your digital welfare
<apw> sconklin, ^^
<tgardner> what _are_ you guys ranting about?
<sconklin> apw: aer you calling nouveau anti-social?
<apw> heh not quite
<sconklin> :)
<Sarvatt> speaking of nouveau - https://bugs.freedesktop.org/show_bug.cgi?id=26980#c25
<ubot2> Freedesktop bug 26980 in Driver/nouveau "GT230M or GT218 with nouveau: X server hangs spontaneously" [Normal,New]
<Sarvatt> a large chunk of cards could probably do with being quirked to noaccel=1
<sconklin> Sarvatt: wow, that is sooo special! (new microcontroller)
<sconklin> Sarvatt: any idea how we can generate such a list of cards>
<sconklin> ?
<Sarvatt> 10DE:00A3 10DE:00A5 10DE:00A8 10DE:00A8 10DE:00AF 10DE:00C0
<Sarvatt> oops minus the 00A8 repeat
<Sarvatt> theres a list here in order of newness - http://github.com/pathscale/envytools/blob/master/nvchipsets.xml
<Sarvatt> can't just use the whole range because 00AA and 00AC are older than those others
<komputes_ubuntu> hi sconklin apw, I had a few issues, in which I would appreciate some kern dev love... I was unable to install i386 RC5 mainline kernel on a system which currently uses a pae kernel (4GB+ RAM).
<sconklin> Sarvatt: is there an ubuntu bug for this yet?
<Sarvatt> yeah i'm sure there are a bunch, i haven't had a chance to look yet but will tonight and tag them
<sconklin> komputes_ubuntu: unable to install, or unable to boot?
<sconklin> Sarvatt: ok, and we should probably wrap them all in one master bug for the quirking
<komputes_ubuntu> sconklin: shows as installed, does not show up in grub
<sconklin> thanks
<komputes_ubuntu> sconklin: looks like pae kernel is there already, also looks like system is has grub 0.97 installed
<Sarvatt> wish i could search file attachments on LP for this backtrace in one of the old logs - https://bugs.freedesktop.org/show_bug.cgi?id=26980#c27
<ubot2> Freedesktop bug 26980 in Driver/nouveau "GT230M or GT218 with nouveau: X server hangs spontaneously" [Normal,New]
<sconklin> Sarvatt: bjf has some tools that might be able to do that
<komputes_ubuntu> sconklin: After successful installation of these packages, rebooted holding down shift, GRUB only shows 2.6.32 kernels
<bjf> Sarvatt, which log would that backtrace show up in? dmesg?
<Sarvatt> one of the 3 gdm logs or xorg.0.log.old
<Sarvatt> just searching for nouveau_bo_wait would spot most of them
<bjf> Sarvatt, do you have one bug that you can point me at as an example?
<bjf> Sarvatt, in the title?
<Sarvatt> no it'd be in the old logs, i don't have a bug handy and i have to run for a few hours but i'll dig one up when i get back
<bjf> Sarvatt, i'll look in the mean time
<Sarvatt> oh those pciids i listed were wrong, it goes like 10de:0a30-10de:00a3f for each range
<Sarvatt> bjf: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/585462
<ubot2> Ubuntu bug 585462 in xserver-xorg-video-nouveau (Ubuntu) "random interface freeze (affects: 1) (heat: 60)" [Undecided,Confirmed]
<Sarvatt> thats for sure the same bug
<bjf> Sarvatt, thanks
<Sarvatt> nouveau_bo_map_range would be what you'd have to search for, nouveau_bo_wait doesn't show up without debug symbols
<bjf> Sarvatt, ok, will look into it
<Sarvatt> http://launchpadlibrarian.net/49083633/GdmLog2.txt
 * bjf will be back in a bit
<astinus> jjohansen: I just wanted to apologise, the bug with regards idle load is getting a lot of FUD in the last 72 hours; too many users jumping to conclusions IMO
<jjohansen> astinus: np, that happens
<astinus> jjohansen: I still think the best way to approach is to look at it on an idle box which has just been installed, no workload - if there is an actual knock-on performance impact due to whatever bug, we can clobber that ("Two birds, one stone") later on
<astinus> jjohansen: I can't help but feel there is a huge glaring "RIGHT HERE!" plastered over the fact a Karmic Koala kernel loads using like 85% less memory (straight after boot) and my only issue so far has been, beyond the Wiki page detailing changes and the obvious version bump, I don't know how to bisect 
<jjohansen> astinus: there is an actual problem, its not just load reporting
<astinus> jjohansen: I presume this is liable to slip 10.04.1 and will be finally fixed in 10.04.2 but you can ship a patched kernel via repositories sooner than a bump release?
<jjohansen> right
<jjohansen> we will make it available as soon as we can
<astinus> jjohansen: my basic reason for screaming "Help!" was this essentially makes 10.04 undeployable for me at the moment, especially combined with the grub/multipath issues also introduced :(  Which means we're rolling out RHEL5 boxes for R&D at the moment, and that doesn't really make me happy =)
<jjohansen> completely understandable :)
 * astinus needs to get better resolution on the grub/multipath and file bugs
<astinus> essentially we run a SAN environment with two production fabrics, a dual-port HBA and *previous* releases supported that fine, but 10.04 with grub2 fails to boot on that config
<astinus> not got a workaround for that, but it only affects nodes booting from the EVAs - anything with local disks is hunky dory
<jjohansen> astinus: what of using grub1 then
<astinus> jjohansen: that fixes booting, but there is still some weirdness with DM and multipath
<astinus> jjohansen: so if fabric1 fails, we don't automatically failover to using fabric2
<astinus> jjohansen: Problem is we're at the end of Q3 right now at work so I'm essentially swamped and won't have time to actually spend 1-2 days on this until mid-August :) 
 * astinus hopes by then the main kernel issue is on the way to fixed and we can nail the SAN stuff
<jjohansen> I expect we will get the load bug nailed soon
<astinus> do you have a line on it? Need anything tested?
<jjohansen> astinus: not yet but I am narrowing it down
#ubuntu-kernel 2010-07-29
<amitk> morning
<lag> Morning
<abogani> Morning
<cooloney> morning, eu
<apw> moin
<jk-> hey apw 
<apw> hi
<ericm_> apw, cking, is smb on vacation this week?
<jk-> all of the UK is taking a swap day tomorrow
<trapmax> i'm trying to create an lvm-snapshot. my machine just hungs there. here's the kern.log http://pastebin.com/KUzVGZSQ
<ericm_> jk-, ok
<ericm_> apw, so I have to bug you again
<apw> ericm_, smb is in today
<ericm_> after mvl-dove branch is rebased, all the tags could possibly be inconsistent with the current history right?
 * smb is there
<apw> ericm_, the tags are correct in that the point to the tree at the time the release was made
<ericm_> morning smb
<apw> the release commits in the latest copy of the tree do not correspond to the tags ... but the tags are right
<ericm_> apw, yeah - but now the rebased commit isn't
<ericm_> I mean the equivalent one, you know what I mean
<apw> right ... that is correct, but only the tag matters
<ericm_> apw, ok I see
<smb> The tags should still be there but point to something not linearly connectect to the releas
<apw> you don't use the release commit to find the tree for the release, you use the tag, that is what the release was really made from
<ericm_> smb, apw, OK I see
<ericm_> smb, one other thing - why don't we just put maint-startnewrelease to replace the fdr startnewrelease?
<smb> ericm_, Mostly because I just recently wrote it
<ericm_> smb, mostly I much enjoyed using that script :-)
<smb> ericm_, Another thing that is a bit of a problem it that those scripts use other libraries in the kteam-tools domain
<smb> ericm_, Thanks, I enjoy those too. Take some of the manual labour away
<ericm_> smb, ok - I copied the lib directly to my /usr/lib/python, though not sure if that's the right way
<ericm_> smb, maybe for the scripts in kernel package, we could just hardcode those libs into the scripts, but that creates maintenance problems :-/
<smb> ericm_, From my intention you would just add the kteam-tools/maintsacripts to your PATH and all should work
<smb> All scripts look for libraries relative to their own path in kteam-tools/lib
<ericm_> Grr.... I copied those to ~/bin, ugly hacks
<smb> Hmm, seems its only me that thinks adding a path is much simpler. :-P
 * apw notes he mentioned that smb adds that dir to their path ...
<smb> apw, That dir? Which one
<apw> kteam-tools/maint-scripts
<apw> the one you said just now, i mentioned it yesterday when i mentioned the scirpts for doing start new release, which is how he knows about it!
<smb> Ah, ok. Understand now
<apw> smb, that the scripts don't cope correctly still if you run them directly ... is still annoying, and something i mean to fix
<smb> apw Hm, well should be a relative simple fix
<apw> yep, should be, just not obthered to look yet
<smb> apw, Just that I never saw that much need as I got it in my path
<apw> its a proformer fragment of code needed to do it
<smb> Because I am lazy and don't want to type the complete path all the time
<smb> apw, The problem likely is this needs to go into all scripts looking for a lib
<apw> and everything looking for a binary too
<smb> Huh?
<apw> other binaries called from the binaries (or scripts) needs it too, so i don't have to add the path
<smb> Well, thats what PATH is for
<apw> but for a small code change it can work both ways and ~/git/kteam-tools/maint-foo/maint-bar
<smb> I find it somewhat strange to expect a script or binary will find anything somewhere
<apw> will work as expected instread of exploding randomly for some commands
<apw> plus actually just using path is dangerous as i could have two versions installed
<apw> and get the libraries or binaries from the other one
<apw> the tools come as a kit, and should ensure they use the ones from the kit
<apw> i am not asking you to do the work, i'll get to it when it next annoys me
<smb> apw, Somehow you sound like asking for bulletproof shoes while waving around your gun :-P
<apw> smb, its a personal way of working that i use commonly with other applications is all
<apw> and its odd that that one does not follow the same rule
<apw> i tend to not have random scripts on my path that have low utility, by which i mean i use them seldom
<smb> As odd as it is to me that you don't work like me. 
<smb> But ok
<apw> especially ones which mess arround with the current directory state
<apw> as there is inhearnt risk of running the wrong thing and shitting all over what you are doing
<apw> so if i am doing a review i can see adding that dir to the path for that session and using lots of scripts for a bit there
<apw> but normally to just get one function out of it, i'll just pick it by absolute path
<smb> I can try to put in a more robust lookup and you can do the others
<apw> as i say, don't feel you need to do anything
<apw> i have lots of experience of doing this mod, as i have it in everything i write for the same reason :)
<smb> I would do it just once in one script to have a reference for it. Also in case I do more scripts
<apw> watch out for the path case, ie there are three cases ./xxx ~/foo/xxx and xxx via path, they all present differenet via $0
<apw> in my scripts i typically have a $here which is instantiated from $0 and basically allow me to find everything else .... include $here/../lib/foo $here/oother-binary
<smb> I believe there is an abspath which returns the complete path, which I can use instead of getcwd alone
<apw> yeah there may even be a python lib fn for finding  'here'
<apw> here=`dirname $0`
<apw> case "$here" in
<apw> *)  here="`pwd`/$here" ;;
<apw> esac
<apw> is what i do in shell
<smb> here = os.path.abspath(os.getcwd()) 
<smb> I think
<apw> no that is 'here' of the user, not the here of the program
<apw> ok a line is missing from that fragment ... cause it starts with a /
<apw> damn irc client
<smb> right, replace that the path of the program
<apw>         here=`dirname $0`
<apw>         case "$here" in
<apw>         /*) ;;
<apw>         *)  here="`pwd`/$here" ;;
<apw>         esac
<apw> the problem is that $0 is not always fully qualified
<apw> it is generally what the user typed, which can be relative
<apw> so you have to be sneaky
<smb> Hm, so does maint-getabis currently fail for you that way. It seems at least for the libpath I already use abspath
<ericm_> smb, hrm... maint-getabis doesn't work with version number like: EE: Ubuntu-2.6.32-206.19foo1 does not seem to be a valid name
<ericm_> it's in maint-getabis
<smb> ericm_, Did you tag it like that?
<ericm_> smb, oh no - let me tag it again
<ericm_> smb, now it works
<ericm_> smb, hrmm... downloading abi failed
<ericm_> smb, it's an OEM kernel, so the kernel image package isn't on the server
<smb> Well the script is geared towards official releases. So it looks on official host archives only
<ericm_> smb, yeah - that makes sense - but is it possible to provide kernel package manually?
<ericm_> smb, I'm thinking of maintaining the OEM kernel tree as our official ones with same branch management
<smb> ericm_, Not yet. You could add that to a wish list.
<smb> ericm_, Though I probably would make it an additional  'location' to look for packages
<ericm_> smb, yeah that's a good idea
<cooloney> apw: just saw your patch about readahead, will this one be summitted to upstream?
<apw> cooloney, likely yes, whether they will take it is another question as it uses a page bit, and they are very scarese
<smb> apw, So maint-getabis seems to work for me without having the path set. So it seems lib lookup is ok. when calling other scripts it seems to require a little more. I changed maint-startnewrelease accordingly. Maybe there is a simpler way by adding it to the right path within python but this seems to work for me.
<apw> smb ta, will try it out
<cooloney> apw: understood
<cooloney> apw: ureadahead needs this patch, i guess.
<apw> ureadahead2 needs it yes
<ikepanhc> when sprint, Tim said when UDS, we make agreements, its means "Each team makes agreements for next release" or "Kernel team makes agreements to other team"?
<apw> each team agrees with the other teams what it will deliver for the release
<apw> so both i think
<ikepanhc> apw: thanks
 * ikepanhc hates writing slide :(
<jk-> ike: if you like, I'm happy to read & review
<ikepanhc> jk-: sure, but please wait me finish :)
<jk-> ikepanhc: of course :)
<ericm_> smb, in maint-getabis:DownloadPackage(), it looks like if I download the .deb package manually, it won't bother to download
<ericm|ubuntu> smb, yet the problem is where, I downloaded the package in the current ubuntu-lucid/ directory, but doesn't seem to be recognized as already existing
<smb> ericm|ubuntu, Might work, though you would have to do it either on the remote host or say --local
<ericm|ubuntu> smb, but maint-startnewrelease doesn't accept --local
<smb> Hm, I should add that as passthrough then
<diwic> what (Maverick) kernel repo/ppa should I enable if I want to help out with testing?
<apw> ~kernel-ppa/pre-proposed
<diwic> whoa! That was an interesting resume effect
<apw> heh what did you see ?
<diwic> My (other) laptop makes screen effects that reminds me of the demo scene in the 90's
 * apw is intregeded, but has no idea what that might look like
<diwic> It purely hang under Lucid, so this is maverick. Every other scanline is black, and  the others are fading between white and blue-black
<diwic> hmm...seem to have settled as being grey + black now
<diwic> a few blue pixels in the top and bottom though
<marco74> hello anybody here in this room
<marco74> I have a problem concerning the ubuntu-kernel of Lucid
<marco74> can anybody help me?
<apw> wtf why to people just appear ask and go without waiting?
<apw> diwic, sounds mad enugh
<apw> oh _and_ logoff irc completely ... 
<apw> cking, hey
* apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - August-03 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<cking> apw, what?
<apw> cking, was trying to work out if you could hear me on mbl
<apw> as you clearly wern't there ... 
<diwic> apw, you have a movie in bug #611254
<ubot2> Launchpad bug 611254 in linux (Ubuntu) "Resume hangs and shows funny patterns on screen (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/611254
<apw> diwic, what do you use to play it?  totem just ignores it
<diwic> apw, it works in VLC. It's straight from the phone
<apw> diwic, so it does, cute effect
<diwic> apw, I'll just wait for our suspend/resume guy (still haven't learned all names and who does what) to take care of it :-)
<apw> cking, http://launchpadlibrarian.net/52687216/MOV00503.MP4
<apw> diwic, i wonder if thats just the video ram decaying cause its not being refreshed cause we are crashed
<Sarvatt> diwic: does booting with vesafb=fubar fix it? :)
<apw> literally =fubar ?
<Sarvatt> invalid parameter so it wont load
<apw> Sarvatt, do we have any idea why vesafb is relevant ?
<diwic> If that matters, it's Via/OpenChrome
<Sarvatt> i'm just curious because i've seen similar caused by vga16fb. I saw it was openchrome, I'm sorry diwic :)
<apw> framebuffer handling is mostly broken .. i am working on what is becoming a major patch for it now
<diwic> Sarvatt, I tried it and as we already suspected, it didn't work, i e no difference
<diwic> apw, video ram decaying was the best theory out of 1 theories so far
 * apw likes those odds
 * apw bets his theory is the closest to the truth
<apw> smb, these new ext4 patches are they the ones we already have or new ones?
<apw> (the ones in the stable queue for .32)
<smb> apw, May or may not. I have not done a comparison yet to find out whether the sets are 1:1
<apw> there seems to be 52 of them
<smb> that sounds not too bad
<apw> 142 in total on the queue, 52 ext4
<smb> Let me run over them with a script to be sure its all we had
<diwic> should I put something into a git kernel commit to make it automatically close a LP bug?
<apw> diwic, yep, a BugLink: link
 * smb is too slow
<apw> BugLink: http://bugs.launchpad.net/bugs/581525
<ubot2> Ubuntu bug 581525 in linux-meta (Ubuntu) (and 1 other project) "Lucid: system becomes unstable randomly, seems related with apparmor (affects: 5) (heat: 32)" [Undecided,In progress]
<manjo> apw, how does that automatically close an LP bug ?
<diwic> apw, thanks
<apw> insert changes copied them over to LP: #nnnnn in the debian changelog
<apw> and things so marked in there are closed by the janitor when the package is published
<apw> manjo, ^^
<manjo> did now know that ... thanks 
<apw> t'is why they are important to have in the bugs
<apw> the - LP: bits of the debian changelog are made from them
<manjo> apw, I always added them not knowing their side effects 
<apw>   * SAUCE: Yama: search for PTRACE exceptions via thread group leader
<apw>     - LP: #603716
<apw> like that ... and that is grepped out by the janitor
<soren> manjo: Technically, it's dpkg-genchanges that does it. It spots the stuff in debian/changelog and adds a line to the _source.changes file (X-Launchpad-Bugs-Fixed, IIRC), which in turn is handled by Launchpad.
<apw> soren, heh even more complex
<soren> Well, the magic has to happen somewhere :)
 * manjo is feeling dizzy 
<soren> This way, if the distro team feels like changing preferred format for it in the debian changelog, it doesn't require changes in Launchpad.
<apw> /home/apw/upload/arm/linux-fsl-imx51_2.6.31-104.12_source.changes:Launchpad-Bugs-Fixed: 310760 410933 410933 416325 416325 427948 430694 430694 430694 430809 430809 433904 435958 438687 445580 446595
<apw> and there it is lurking in the changes file
<soren> Ok, so no "X-" prefix. My bad :)
<manjo> so if a patch fixes multiple bugs we need to have multiple Buglink: ... in the commit comments ? 
<apw> yeah such inaccuracy you should be fired
<apw> manjo, yes
<soren> apw: You can't fire people who've already left. :)
<apw> and they end up as - LP: #xxx, #yyy
<apw> and so on
<apw> soren, i didn't say who should fire you did i ?   :)
<soren> apw: point :)
<manjo> cease fire
<ericm> smb, when you rebase mvl-dove branch against master, what is the command you use, 'git rebase Ubuntu-2.6.xx-xx.xx' or 'git rebase --onto Ubuntu-2.6.xx-xx.xx <some start point> mvl-dove'
<smb> ericm, The second form
<ericm> smb, as I expected, ok
<smb> ericm, Though I started to run it as a script: maint-rebase-branch
<smb> ericm, This would end on a branch named auto-tmp-rebase which one can check and then reset the target branch to that
<ericm> smb, ah - script again, thanks - I love your scripts :-)
<smb> ericm, Thanks :) These are quite ego-centric for the moment, so feel free to let me know anything that can be improved.
 * manjo going down for reboot
<manjo> I will be offline for a few mts my electric company is cutting my power to replace the meter 
<apw> yeah right :)
<apw> you will be gone for HOURS :)
<cking> days even
 * cking hopes manjo has a lot of batteries
<jjohansen> ogasawara: I'm going to have another AA sync request for tonight / friday morning.  Its not that different from what we have but brings it up to match with the latest updates.
<ogasawara> jjohansen: cool, I'll wait for it then
<jjohansen> ogasawara: well no real need to wait, I can push it when you want.  Just the longer I wait the more likely it will match whats hopefully going upstream
<jjohansen> its done now, just waiting on feedback
<ogasawara> jjohansen: maybe just wait and see if you get any feedback by tomorrow.  I'd like to be as close to what's upstream as possible.
<ogasawara> jjohansen: I'm gonna hold off the upload as long as I can anyways as I'm hoping 2.6.35 final might land
<jjohansen> ogasawara: also I have a pv-ops request coming too, no nasty xen branch :)
<ogasawara> jjohansen: sweet
<apw> jjohansen, that sounds good
<apw> ogasawara, i shot you a summary email on all the patches i've puked out today
 * apw is wandering off for some beer shortly, i'll try and check my email tonight in case you have any issues
<ogasawara> apw: yep, saw it.  Just getting through the last set.  looking okay so far.  I'm gonna fire up some tests across some of my systems before I push.
<apw> sounds good.  doesn't solve the fact that plymout
<apw> plymouth fires up too soon on a lot of drm h/w.  but at least it not longer blows the kernel up (for me at least)
 * manjo getting lunch will be back soon
 * vanhoof just loves updating wikis :)
<cking> vanhoof, watch out - you may become a wiki gardener soon
<jjohansen> cking: beat me too it
<vanhoof> lol
 * vanhoof *hides*
<jjohansen> -> lunch
<bjf> jjohansen, i added you as UDS-N roomie :-)
<jjohansen> bjf: wow you are on top of things :)
 * ogasawara lunch
 * manjo going to post office ... brb 30mts 
<bjf> ogasawara, hope you don't mind if i poke at qa about testing proposed :-)
<ogasawara> bjf: don't mind at all, was actually hoping others would chime in :)
<ogasawara> bjf: I was thinking the exact same questions you posted.
<jjohansen> bjf: have fun tilting at windmills
<ogasawara> heh
<bjf> jjohansen, i'm willing to have a go at this one for a bit, it's been years since I sent some really flaming email
<jjohansen> :)
<ogasawara> bjf: after the chat with them at the rally I thought we'd figured out the preseed bit, and modification of the dist.info file to search for results of testing from -proposed, and tweaking their prober or whatever to detect new packages in -proposed
<ogasawara> bjf: I swear ronald even sent an email about it
<bjf> ogasawara, yes i had the same thoughts as well, I guess we were mistaken
<komputes> ogasawara: hi there! :)
 * komputes hands ogasawara a present - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/611474
<ubot2> Ubuntu bug 611474 in linux (Ubuntu) "boot failure SAS hard drives controller (affects: 1) (heat: 6)" [Undecided,New]
<apw> ogasawara, yo ... checking in ... all good?  any problems?
<ogasawara> apw: all good
<ogasawara> apw: just have one more system I want to install and test on
<ogasawara> cool, the touchscreen on the hp-mini is working again
<apw> ogasawara, awsome :)   ... night
<daishadar> can someone give me a general idea of what will probably stop working if i install a mainline kernel?  what are ubuntu specific patches and drivers for?
#ubuntu-kernel 2010-07-30
<jjohansen> daishadar: most things will still work
<jjohansen> daishadar: the ubuntu specific patches provide features, drivers, and fixes that are not upstream yet, and in some cases will never be upstream but are useful in their current state for our users
<jjohansen> eg. aufs is used to provide union mounts for the livecds and schroots
<jjohansen> ndiswrapper lets users fall back to windows wireless drivers
<daishadar> i see... so they may be things i notice but they should be relatively minor, depending on what features i'm using
<jjohansen> AppArmor provides the default MAC, but if you boot without things will work you just won't have the extra restrictions on some applications
<daishadar> the other problem is that i will lose binary drivers (e.g. nvidia), right?  but i should be able to download those from the manufacturer's website...
<jjohansen> right you loose prepackaged binary drivers, but with some digging you can find the source stubs and blobs and compile them
<jjohansen> where you get them just depends
<jjohansen> usually from the manufactures website or out of ubuntu DKMS packages
<daishadar> ok, great, so it sounds like it's reasonable.  i'm thinking about buying a thinkpad t410s laptop but apparently there are major issues if you aren't running 2.6.34
<ogasawara> jjohansen: \o/, just saw your email
<jjohansen> 5
<jjohansen> hehe, lets try that again
<jjohansen> 5
<jjohansen>   \o
<ogasawara> will definitely have to highlight that in the release meeting tomorrow
<jjohansen> ogasawara: I'll get you a request pull out as soon as I rebase and verify
<ogasawara> jjohansen: cool, thanks
<jjohansen> ogasawara: I have a couple kernel related work items that won't make tomorrows freeze but may make feature freeze deadline, should I just push those items out now?
<ogasawara> jjohansen: yah, go ahead and push them out to be safe
<jjohansen> okay
<bjf[afk]> jjohansen, that's fantastic, good job
<jjohansen> thanks :)
 * bjf[afk] wants to scream about the build scripts
<xsaiddx> hello guys 
<xsaiddx> i got this on start up
<xsaiddx> http://pastebin.com/kgSrGqe5
<xsaiddx> anyone ca help me pls
<jjohansen> xsaiddx: ubuntu kernel? or other?
<jjohansen> was this a clean install or an upgrade?
<xsaiddx> jjohansen, sorry
<xsaiddx> i didnt get you
<jjohansen> basically there is not enough information to figure out what is happening
<xsaiddx> no i removed plymouth and it takes off mostly all of the packges
<jjohansen> ugh, uhmm yeah that is a problem
<xsaiddx> so i had to install an image kernel  and follwin that tip in the end of it it says 
<xsaiddx> unlink sbin/init so i got this message i showed you
<xsaiddx> and b4 i had acces only to my console
<xsaiddx> but like this xsaiddx@none
<jjohansen> hrmm, what do you still have access too?
<jjohansen> for ex. can you reinstall plymouth
<xsaiddx> no
<xsaiddx> now only acces to see that nice message and thats it
<xsaiddx> : D
<xsaiddx> i can go live via a cd and do link sbin/init ?
<jjohansen> hrmm can you boot a livecd, or usbstick?
<xsaiddx> wud it work
<xsaiddx> yeh
<jk-> xsaiddx: you could try booting with init=/bin/sh
<xsaiddx> uhm how cus i cant type anythin
<xsaiddx> or you mean from the live cd
<jk-> xsaiddx: at the grub prompt
<xsaiddx> theres no grub now
<jjohansen> hold down the left shift key at boot
<jk-> shift to get the grub menu
<jjohansen> has to be left shift
<jk-> select the right boot option, press 'e' to edit it
<jk-> https://wiki.ubuntu.com/DebuggingKernelBoot
<jk-> instead of step 3, add 'init=/bin/bash'
<jk-> (probably remove 'splash' and 'quiet' too actually)
<jk-> which 'tip' were you following that told you to remove init?
<xsaiddx> jk ill link you
<xsaiddx> http://forum.phillw.net/viewtopic.php?f=4&t=35, this
 * jk- looks
<xsaiddx> jk btw where ishud type that init
<jk-> xsaiddx: what is on your screen at the moment?
<xsaiddx> jk??
<xsaiddx> sory didnt get you 
<jk-> what do you have on your screen now?
<jk-> are you in grub?
<xsaiddx> no im on xp 
<xsaiddx> now
<xsaiddx> when i start lubuntu theres no grub
<jk-> xsaiddx: instructions are here: https://wiki.ubuntu.com/DebuggingKernelBoot
<xsaiddx> jsut that message i shpwed you
<jk-> jjohansen: hm, wiki says 'escape' for some reason
<jjohansen> ????, its always been left shift for me
<jk-> jjohansen: i blame manjo :)
<xsaiddx> jk well hit esc then what
<jjohansen> yeah its got to be manjo
<jk-> xsaiddx: then read the next step
<jk-> xsaiddx: if escape doesn't work, try left-shift instead.
<xsaiddx> yeh but still didnt get it sorry
<xsaiddx> can you tell me what to do 
<jk-> xsaiddx: do you have important stuff on that machine? maybe a reinstall is besst
<xsaiddx> yeh 
<xsaiddx> and i  dont like the idea to reinstall all
<jk-> 1) reboot the computer
<xsaiddx> yeh ten
<xsaiddx> then
<jk-> 2) after the BIOS screen goes away, press left shift
<jk-> and hold it down
<jk-> you should get the grub screen
<xsaiddx> then
<jk-> is this a separate computer? can you do this as we talk?
<xsaiddx> no i have dual boot
<jk-> so you're going to remember this stuff?
<xsaiddx> you can tell me im takin notes tho
<xsaiddx> hello jk
<xsaiddx> jk-, hello
<jk-> xsaiddx: just a sec
<xsaiddx> ok
<xsaiddx> sure
<jk-> xsaiddx: print this out: https://wiki.ubuntu.com/DebuggingKernelBoot
<jk-> xsaiddx: before you press 'b', add "init=/bin/bash"
<xsaiddx> dude my english sux and i didnt get that doc so thats why iwas askin your help clearly
<jk-> I've just re-written the doc for you
<xsaiddx> where i can add that init.... ?
<jk-> xsaiddx: however, you will need to do a few more things after you've done that boot, and I can't tell you what you need to do there
<xsaiddx> why i have to tell wht im goin to get so you can kno is it
<xsaiddx> i can go and see now and come bk n tell you
<jk-> sorry, i don't understand either of those lines. could you rephrase?
<xsaiddx> jk-, well im goin to try okies brb please and tnx for ur help
<xsaiddx> i said
<xsaiddx> you cant tell me wht to do after that 
<jk-> i would suggest these commands, but I can't be sure:
<xsaiddx> cus you need to see wht im goin to have as an error so you can kno the issue
<xsaiddx> so i said ican go and come back to tell you
<xsaiddx> okies ?
<xsaiddx> well im goin now
<xsaiddx> but i jst wnana kno when gettin grub when ishall add tat init=...
<jk-> apt-get install --reinstall linux-image-generic-$(uname -r)
<jk-> xsaiddx: it says where to add it in that document
<jk-> sorry, make that:
<jk-> apt-get install --reinstall linux-image-$(uname -r)
<jk-> i have updated the document with more details. please refresh the page to see the latest version
<xsaiddx> ok
<jk-> also, apt-get install --reinstall upstart
<xsaiddx> ok ill get back to you tnx
<xsaiddx> wish me luck 
<cooloney> ericm: how can i build the upstream kernel for omap without defconfig file?
<jk-> cooloney: the defconfigs should still be there, no?
<cooloney> jk-: no omap4_panda_defconfig
<jk-> ah
<jk-> menuconfig? :)
<cooloney> and i tried to build the omap kernel from Tony's linux-omap tree
<cooloney> it failed
<cooloney> weird
<cooloney> jk-: yeah, i chose TI OMAP system, it will select omap2/3/4 and build for Panda board as well
<cooloney> jk-: my bad. i just turned on ARCH_OMAP. forget to turn off OMAP2 and OMAP3
<cooloney> now it is building 
<jk-> ericm, cooloney: pull request sent, for the debug macro changes
<ripps> It looks like l-b-m and linux-meta were merged together, and now linux-meta is held up in NEW. How long before it gets into the repos?
<ericm> cooloney, I don't think omap4_panda_defconfig is gonna squeeze into mainline recently
<cooloney> ericm: i know, it was enabled in omap_4430sdp_defconfig
<cooloney> ericm: i can build the kernel, but doesn't boot on my board. serial port driver is not set to the right one
<ericm> cooloney, that always happen, maybe you should change the command line in u-boot
<cooloney> ericm: still checking the right config, will let you know the result.
<cooloney> ericm: btw, i am trying tony's linux-omap tree instead of linus mainline
<ericm> cool
<trapmax> anyone experiencing "INFO: task x blocked for more than 120 seconds." messages. In our system it gets triggered when using lvcreate. Started after updating to 2.6.32-24-server -kernel. Workaround?
<RAOF> trapmax: That'll happen when something bogs down so much that forward progress doesn't get made fast enough.  I've managed to get almost all my tasks to spit that message when doing a bunch of I/O in btrfs.
<trapmax> RAOF: this did not happen before updating to newest kernel
<RAOF> I'd guess that what's happening is lvcreate is blocking I/O, and is chomping on long enough to trigger that messsage for your other tasks to trigger the message.
<smb> Usually there would be a backtrace about it. To offer more info
<trapmax> http://pastebin.com/KUzVGZSQ
<smb> Most of the -24 update was ext4 which would not have an impact on lvcreate though
<smb> Oh, actually it is ext4 related...
<trapmax> we have ext4 environment though
<smb> I was just wondering because lvcreate itself does no filesystem
<smb> It could be related to the general writeback regression that we are currently seeing with 2.6.32 kernels. Maybe the ext4 update in some cases just makes it happen more often
<trapmax> this makes our lvm-snapshot -backup virtually impossible
<smb> trapmax, I got some test kernels to try if you want to.
<trapmax> production server. not really confident with that option
<smb> trapmax, Hm, hard to offer a workaround that way. The ext4 updates are verified to fix some data integrity issues and seem to cause long(er) IO times in your case
<smb> the bug in question would be bug 585092
<ubot2> Launchpad bug 585092 in linux (Ubuntu) "giant IO delays (affects: 1) (heat: 20)" [Medium,Triaged] https://launchpad.net/bugs/585092
<smb> As this relates to some syncs done synchronously, I wonder whether issuing manual sync's from the command line change anything
<trapmax> we have manual sync runnin with 5s sleep
<smb> Hm, ok
<smb> trapmax, All the backtraces in your log somehow go through writeback. I am currently trying to get some feedback on the backport of the writeback patches which are in the test kernels. But this will take a bit.
<smb> Until then the only thing to play with seems to be the interval of the manual sync. The previous kernels somehow worked but from the tests that were done for the ext4 patches I would not really recommend going back to those old kernel.
<trapmax> smb: ack
<jjohansen> rebooting
 * smb blinks
<jjohansen> urghh, don't update!!!
<smb> jjohansen, Maverick kernel? Or something else?
<jjohansen> many things
<jjohansen> seems kernel is broken for networking
 * smb thinks jjohansen should be sleeping instead of updating anyway ;-=
<jjohansen> theme is broken
<jjohansen> gnome panel seems to be broken
<smb> Seems everything is ready to alpha3
<smb> Have we been doing something in the networking area?
<jjohansen> I have a high load almost 50% each cpu, but nothing is showing up via, top, htop etc
<jjohansen> the load isn't the kernel as I had to reboot into an older kernel, and it still remains
<smb> jjohansen, would perf give more hints?
<jjohansen> smb maybe
<RAOF> You might need to re-run apt; they're discussing the gtk update which is probably what has caused your âeverything brokenâ
<jjohansen> theme is comletely broken too, I had to revert to human :)
 * smb likes human. :)
<jjohansen> RAOF: already have no dice
<RAOF> That, plus a reboot, fixed it for me.  Although I didn't have a high load.
<jjohansen> I'm sure it will get sorted out, soon just putting out the warning that now is not a good time to update
<jjohansen> smb: do we have a wiki on perf yet
<smb> I guess an indication that its not kernel or is would be good to know for Leann on the release meeting
<smb> jjohansen, I am not sure. Maybe not
<smb> I usually try "perf top" first, that would give an overview on calls
<smb> jjohansen, Other than that maybe in some presentation slides from chase
<smb> II think the other was a "sudo perf record" paired with a "perf report"
<jjohansen> smb: right, but that records a command, I was looking for a way to just get a sampling of all commands and kernel fns
<jjohansen> after all what I am seeing is not showing up
<smb> Would "sudo perf record -a -f -c 5000" be what you are looking for
<smb> The 5000 might be a tad long
<jjohansen> maybe
<smb> I was stabbing in the dark with the count
<smb> Seems already quite long with 50
<jjohansen> something is really hammering my system load average 3.28 2.10 1.18
<smb> Strangely you would expect it to show up in top if it gets accounted in the load
<jjohansen> cpus are varying between 30- 100%, but htop isn't showing
<jjohansen> that is it shows the cpu load and the processes are like 7%, 9% etc just small little figures
<smb> I thought that one patch from Chase about accounting small runtimes went upstream as well
<jjohansen> hrmm, so did I
<smb> jjohansen, btw, -c# is not really needed. And i have no clue what it relates to
<jjohansen> I think its something to do with panel icons, as they have been slowly showing up, 1 by 1
<jjohansen> I now have a wifi icon, and a screen orientation icon, which I didn't before
<smb> I see no such thing here. Oh, you mean your load
<jjohansen> yeah
<smb> So you could try "sudo perf record -f -a", let it run a bit then ctrl-c
<smb> Then do "sudo perf report"
<jjohansen> yeah, I'll give that a try, as soon as I get perf installed on this machine, the install is crawling
<smb> jjohansen, Maybe start it and get some rest? :) I see your continent mostly in the dark...
<jjohansen> hehe, no I am going to finish getting a pv-ops kernel together and fix my AA request-pull
<smb> jjohansen, *sigh* There is always the next thing to do. ;-)
<jjohansen> hehe, yeah but I want this to make kernel freeze for alpha-3 so ...
<jjohansen> rebooting
<smoser> hi. i'm guessing this is known, but just want to make sure if its not already resolved that someone is looking at it:
<smoser> The following packages have unmet dependencies:
<smoser>   linux-virtual: Depends: linux-image-virtual (= 2.6.35.11.12) but it is not going to be
<smoser> installed
<smoser> , stderr: E: Broken packages
<smb> smoser, Hm, it feels like ringing a bell. Though I am not sure whether this was back in a previous release. Could you send this hint to the kernel-team mailing list as a more permanent reminder?
<smoser> this is last night maverick
<smoser> the uec build fails due to that.
<smoser> i'll send mail.
<smb> Ok, thanks. The kernel looked like a recent Maverick. It just sounded familiar but usually I am not so much looking at the bleeding edge. :)
<smoser> it seems to me that its fixed now.
<smb> Hm, maybe that was just a delay in the archive...
<smb> I would not think that someone had a chance to change anything, yet. Though there are some early birds...
<smb> tgardner, Re: bug to look at: ok. I have also seen some reports of problems with lvm snapshot since the ext4 patches went into updates. I have not yet looked at the other bug but it seems some changes in ext4 might trigger the bad writeback behaviour or even hangs there. Just fyi
<tgardner> smb, ack. you should verify the kernel version they are running to see if there is a strong correlation
<diwic> bjf, ping
<bjf> diwic, go
<diwic> bjf, just wondering what time takashi releases his daily and if your c-o-d's are synced to that
<diwic> bjf, but it matters less as launchpad is three days behind. :-(
<bjf> diwic, don't know and no
<bjf> diwic, let me check
<bjf> diwic, i just pushed a source package, i'll look at my cron job to see what's up with that
<jjohansen> ogasawara: you about?
<ogasawara> jjohansen: yep
<ogasawara> jjohansen: saw both your apparmor and pv-ops pull requests, will review and apply momentarily
<jjohansen> I am updating specs, and pushing out the pv-on-HVM part of pvops out to next week
<ogasawara> jjohansen: ack, sounds good
<jjohansen> ogasawara: so the pv-ops one doesn't include pv-on-HVM drivers which is what I am pushing out.
<jjohansen> I am putting in an explanation of them
<ogasawara> jjohansen: perfect, thanks
<jjohansen> ogasawara: check your mail
<ogasawara> jjohansen: ack
<ogasawara> jjohansen: have you slept yet?
<jjohansen> no
<ogasawara> jjohansen: go take a nap
<jjohansen> soon
<jjohansen> -> nap
<manjo> nap ? 
<manjo> jjohansen, you ?
<jjohansen> manjo: no its my evil twin
<manjo> jjohansen, hmmm that sound more possible :) 
 * manjo have never seen jjohansen sleep
<tgardner> ogasawara, I've a couple of issues with jj's pv-ops pull request. I'll fix 'em up and send you an alternate pull request
<ogasawara> tgardner: cool thanks, I haven't had a chance to review yet anyways
<ev> Would anyone be willing to add the fix for bug 599569 to the next 10.04 update?  It works perfectly on the two 10.04 systems I've tested it with.
<ubot2> Launchpad bug 599569 in linux (Ubuntu) "No kernel support for Sierra Wireless 250U 3G/4G USB Dongle (affects: 4) (heat: 24)" [Undecided,Triaged] https://launchpad.net/bugs/599569
<tgardner> ev, I think the stable team accepts bribes
<ogasawara> looks like stable was CC'd on the upstream patch
<ogasawara> so should be coming down the queue already?
<ev> name your price and I'll smuggle it it across the border when I go to Debconf tomorrow
<smb> If thats true it will come sooner or later
<smb> I would need to check the queue
<smb> ...
<ev> oh, cool
<smb> ev, There is a USB: Add PID for Sierra 250U to drivers/usb/serial/sierra.c queued for the next (2.6.32.17) release from upstream stable
<ev> hooray
<tgardner> ev, don't hold your breath. it could still take weeks.
<ev> well, I've solved the problem for myself (well, my dad really)
<ev> I'd just like to make sure it gets solved for others
<ev> which seems to be happing, glacial pace or otherwise
<ev> :)
<cwillu_at_work> iotop reports CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %
<cwillu_at_work> it's one thing to not know I'm missing out, it's quite another when a program tells me I'm missing out :)
<jpds> cwillu_at_work: bug #493156.
<ubot2> Launchpad bug 493156 in linux (Ubuntu) (and 1 other project) "Please enable CONFIG_TASK_DELAY_ACCT (affects: 55) (dups: 3) (heat: 232)" [Medium,Fix released] https://launchpad.net/bugs/493156
<tgardner> cwillu_at_work, use maverick, or the LTS backport kernel on Lucid
<cwillu_at_work> okay, thanks
 * cwillu_at_work reads the relevant threads
<cwillu_at_work> also, is there any way to make swap act... sane? by which I mean:  at the end of my day, everything is running smoothly:  gedit, inkscape, firefox, they all run without hiccups.  However, at the start of my day, I have to wait 5-15 seconds at fairly random intervals as those applications hang, presumably swapping back in on demand
<cwillu_at_work> case in point:  inkscape just spent the last thirty seconds paging in at around 1mb/s;  however there was no disk write traffic at the same time:  to me, this implies that memory is available, but the allocation policy is buggered
<tgardner> ogasawara, I reset jj
<tgardner> I resent jj's pull request
<ogasawara> tgardner: ack.  my tree is somehow corrupted at the moment so am getting it fixed back up first
<bjf> anyone else notice the daily live isos have not changed for 3 days?
<tgardner> oh, bummer. bad disk, or fat fingers?
<ogasawara> tgardner: I have a feeling it might be the disk :(
<tgardner> ogasawara, back to the trusty, but ancient, laptop
<sconklin> I'm bailing for the rest of the day, I feel terrible. See you Monday!
 * tgardner lunches
 * ogasawara runs errands, back in an hour
 * bjf taking a headache break
<jjohansen> ogasawara: hrmm, what happend that my patches needed to be reset?
<ogasawara> jjohansen: looked like just minor commit log changes that tim made a small tweak with updateconfigs
<jjohansen> hrrm, I'll poke at what he did, I did do a rebase that did a 3 way merge, perhaps that did something?
<jjohansen> ogasawara: is there anything you would like help on, or should I dive back into pv-on-HVM drivers?
<ogasawara> jjohansen: nope, looking good on my side.  just waiting for test builds on ports to finish before I push all the bits
<jjohansen> okay
<manjo> jjohansen, you did not sleep enough 
<jjohansen> manjo: ? really I thought almost 5 hours was pretty good
<jjohansen> well 4.5h maybe
<manjo> jjohansen, good for 4.5 days atleast! 
<manjo> :)
<jjohansen> :)
<manjo> adios amigos .. have a good weekend
<cwillu_at_work> What's the trick to run make-kpkg in a freshly clone'd git repo?
<cwillu_at_work> It's complaining about a missing files list file, which I can't imagine I have to actually build by hand
#ubuntu-kernel 2010-07-31
<simon___> hello, i have found a bug but don't know where to report: i have a packard-bell laptop and the kernel loads asus_laptop by default. this driver is causing some problems (e.g. wifi) and the workaround is to blacklist the driver
<andreoli> hi all, I have uploaded a source package for a modified kernel
<andreoli> upload is ok, build fails with the following message
<andreoli> II: Checking ABI for generic... EE: Previous or current ABI file missing!     /build/buildd/linux-2.6.32/debian.master/abi/2.6.32-24.38/amd64/generic make: *** [abi-check-generic] Error 1 dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2
<andreoli> How do I skip ABI checks in launchpad builds? Is it possible at all?
<andreoli> I wouldn't like to bump the ABI
<andreoli> Forgot to tell: upload is to a PPA
<abogani> andreoli, "skipabi = true" in debian.XXX/rules.d/ARCH.mk
<andreoli> thx, abogani :) will try right now
<andreoli> by the way, anyone care to try my work? Where can I announce it?
<abogani> andreoli, You could let people let know of it announcing it on kernel-team mailing list and on ubuntu-devel.
<abogani> andreoli, Can you explain me your work in a single line?
<andreoli> yes
<andreoli> I and my colleague have written a new diskj I/O scheduler that outperforms significantly the current one (CFQ)
<andreoli> it has latency 5 to 10 times better and a twofold throughput for many workload scenarios
<andreoli> for more information, you can read here (sorry for advertising :)): 
<andreoli> http://algo.ing.unimo.it/people/paolo/disk_sched/
<andreoli> I mainly helped debug the beast, my colleague paolo worked the algorithm out and proposed an implementation
<shadeslayer> when i installed the nvidia drivers it said that it could not build modules for the current kernel since it did not have kernel sources, any ideas on this?
<shadeslayer> ( ive already installed linux-source-2.6.35 to no avail )
<abogani> shadeslayer, You should try to install appropriate linux-header-*s package
<shadeslayer> ah i see
<shadeslayer> E: Package linux-headers-2.6.35-11-generic has no installation candidate
<shadeslayer> hmm 2.6.35-13 does exisist tho
<abogani> uname -a should report which version you are need to have installed
<shadeslayer> abogani: there is no  -11 headers package
<shadeslayer> which is weird.. but i guess its due to the fact we have a -13 package now
<simon___> again.. i have found a bug and don't know where to report it: i have a packard-bell laptop and the kernel loads asus_laptop driver by default (it's enabled in the stup process). it's a driver that's causing some problems (e.g. wifi) and the workaround is to blacklist it. where should i report it?
<proppy> Hi, which rc is 2.6.35-12 ?
#ubuntu-kernel 2010-08-01
<ogasawara> proppy: based on upstream 2.6.35-rc6.  Just for future reference, https://wiki.ubuntu.com/Kernel/FAQ#How can we determine the version of the running kernel?
<proppy> ogasawara: yes, Thanks, FYI I've found it by apt-get install kernel-maverick source and cat debian.master/changelog
<simon___> bump.. anyone?
<penguin42> I could do with some help understanding some drm ioctl code - I think it's missing a copy_from_user but don't understand the code well enough
<penguin42> hmm, now I'm sure and have a patch that fixes it
<squarebracket> has anything happened with the linuxwacom backports module?
<Sarvatt> it's not really a backport given that its not upstream.. you can get a dkms-ified version from ripps - https://edge.launchpad.net/~ripps818/+archive/wacom
<Sarvatt> and go figure they aren't here anymore :)
<lubosz> hi. i'm trying to build a kernel package with make-kpkg. but i get "dpkg-gencontrol: error: package linux-image-2.6.35-rc6+ not in control info." How do i get rid of the +?
<lubosz> my version stirng in the kernel config is empty and i don't append stuff to the version with make-kpkg
<crimsun> akgraner: did you get a chance to ask about the macbook air?
#ubuntu-kernel 2011-07-25
 * apw yawns
 * smb joins
 * smb tries to remember what he was doing last week (when failing to take notes along)
<cking> smb, doing the usual random server stuff?
<smb> cking, Sort of. But it would look a bit slim to have only "random stuff" in the report.. ;)
 * cking nods
<apw> smb, copy the week befores perhaps :)
<smb> apw, Heh, that would be nasty... :) Wonder how long one gets away with sending old status...
<apw> pretty sure you did some cve testing for me
<apw> also a bunch of reviews for that
<smb> Yep, taht as well. And random testing an analysis to get hvm working... or at least to help upstream to get it working...
<cking> apw, I'm getting the flights for UDS sorted, I will copy you when I get some details back
<apw> cking, ack
 * apw idly wonders if there are any united flights, i might just make pink on their awards scheme
<smb> apw, Will that give you anything substantial good or just the good feeling of having reached some status anywhere...?
<apw> heh no idea :)
 * apw notes that someone is still using the old kernel numbering in their branches; for-v2.6.41
 * Tommeh has e-mailed Realtek over their r8168 driver makefile not properly behaving when it sees kernel version 3.0
<Tommeh> </OT>
<apw> Tommeh, yeah we just wacked the version check in the version in the kernel
<jk-> apw: heh
<jk-> kicking and screaming into 3.0
<apw> jk-, more sort of out of the code all together
<jk-> apw: ah, i meant in reference to 2.6.41
<apw> yeah the reference actually was merging for-2.6.40 into for-2.6.41
<apw> so they are pretty adament :)
<jwi> hmpf, is current lucid-proposed really just a single patch?
<jwi> anyway, apparently it's causing a regression; bug 815379
<ubot2> Launchpad bug 815379 in linux "Shutdown problem with the last Lucid kernel updates (linux-image-2.6.32-33.71-generic)" [Undecided,Confirmed] https://launchpad.net/bugs/815379
<apw> jwi, yep, there is almost no way that that update can affect shutdown
<Tommeh> apw: r8168 doesn't need to be built from source manually?
<Tommeh> I wasn't aware it was distributed with the official kernels.
<apw> Tommeh, no idea, the same bug is in every single one of their code clone drivers
<Tommeh> Ah, bah
<Tommeh> I was going to start begging for a patch against the makefile then :p
<apw> they cirtainly know how to amk
<apw> make their h/w undesirable for oss
 * ppisati -> out to get some food
<jwi> apw: well if it turns out that it does affect shutdown, i'd *love* to know why ;)
<apw> jwi, very true
<smb> apw, Hm, at least in my 64bit VM the #71 lucid kernel shuts down to (virtual) power off
<apw> smb, good to know (for sconklin) :)
<smb> reduce panic level by two points... :)
<tgardner> ogasawara, did you forget to announce the ABI bump? or have I just not received the list email yet?
<ogasawara> tgardner: I got distracted, will send it momentarily
 * apw would have done it if he could get the post to the blog to work
<apw> ogasawara, i am running the new kernel on my netbook ok so far
<ogasawara> apw: I've got it on 3 of my boxes here, no fires yet
<dupondje> Jul 25 15:44:20 laptop-jl kernel: [16860.323922] dell_wmi: Unknown key e0f7 pressed
<dupondje> But the key actually worked ... Any idea's ?
<dupondje> kernel bug or ?
<apw> dupondje, what does the key do
<apw> dupondje, also if they key works i am not sure it matters if we report a diagnostic for it
<dupondje> it changes volume
<dupondje> volume is changed, but kernel trows error
<dupondje> Only seem to happen with some hotkeys
<apw> dupondje, my gut reaction is that if the buttons work then its not very important
<dupondje> True :) But its strange kernel throws a warning for a working key
<dupondje> but its not really an issue indeed
<apw> not necessarily, it may be passing both a WMI event and a normal key event for them
<apw> so we get 'two'
<dupondje> Ah ok
<ohsix> theres something with the hotkey stuff that makes g-p-m adjust the backlight 3 times for every press too; couldn't figure out what
<apw> ohsix, yep, as far as i can see in my setups the kernel emits 1 keypress and the tripple adjust occurs after.  i got bored after that
<ohsix> i found out a way to disable one extra reporting, but not the third
<ohsix> acpi and the input device for the video reports it
<ohsix> dunno if i posted this in here already https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/802276
<ubot2> Ubuntu bug 802276 in gnome-power-manager "brightness adjust 3 steps from hard (Fn) keys" [Undecided,New]
<ohsix> if g-p-m isn't running the adjustments don't happen, but g-p-m from its output appears to state it only sets it once
<ohsix> i think the X thing opening it as a device for input is ending up as an extra adjustment somewhere
<ohsix> possibly delivered to g-p-m as a keysym
<dupondje> apw: for the key errors, I create a bug in kernel bugzilla?
<apw> dupondje, probabally yeah, perhaps file a bug agianst linux and link it to the upstream bug so anyone else who comes across it can find the links easily
<ohsix> the most annoying thing about 3 steps isn't the lost resolution, but that there's 10 steps overall and you need to turn it all the way down then back up to set a level, or the other way around
<edrozim> Hello . I am trying to setup limits for open files . I use /etc/security/limits.conf for this 
<edrozim> but when I do grep files /proc/<PID>/limits  I see another value not one that I specified in limits.conf
<apw> have you logged out and in since ?
<edrozim> yap several times
<edrozim> I add following lines to limits.conf
<edrozim> * soft nofile 65536
<edrozim> * hard nofile 65536
<apw> and what limit does it limit to
<edrozim> 4096
 * apw has the feeling that that may be the upper limit in the kernel
<smb> That limits do not always apply to all processes
<dupondje> https://bugs.launchpad.net/linux/+bug/815914 there :D
<ubot2> Ubuntu bug 815914 in linux "dell_wmi: Unknown key eXXX pressed" [Undecided,New]
<smb> It depends on pam applying the limits and IIRC that is done differently for processes with a terminal and without (one does nothing at all I think)
<tgardner> apw, seems like I wrote a patch for that awhile back. 
<apw> tgardner, indeed that is my memory, and why 4096 seemed relevant
<edrozim> the process that important for me is crash with "Too many open files " :(
<smb> apw, You could change it but for that you'd need to change common-session-noninteractive
<edrozim> and I see that it have 4092 open files 
<apw> edrozim, what the heck does it do that 4k open files is not enough, likely it is broken
<edrozim> apw, I agree with you it is application that written by not very good programmer . But I force to deal with it :(
<edrozim> and I should make it alive 
<apw> tgardner, smb, any idea if you can raise limits beyond the base in the kernel?
<smb> apw, yes
<tgardner> apw, IIRC you cannot exceed the hard limit.
<smb> edrozim, You need to experiment, though I think it is /etc/pam.d/common-session-noninteractive which needs an additional line like
<smb> session    required     pam_limits.so
<tgardner> apw, 0ac1ee0bfec2a4ad118f907ce586d0dfd8db7641
<edrozim> smb , thanks I will try and get back to you with result
<apw> tgardner, yeah thats the one
<smb> edrozim, It needs a reboot as well as far as I know
<edrozim> smb, doing it right now ( it is another system ) 
<edrozim> smb , after restart I still see 4096 for "grep files /proc/<PID>/limits"
<smb> edrozim, hm, is that maybe a process that could be considered interactive?
<smb> There are two common files in /etc/pam.d one for interactive sessions and one for the others...
<edrozim> smb, it is java process but it don't have any UI it run like a service
<edrozim> smb, I will try to update second file /etc/pam.d/common-session
<smb> edrozim, So maybe its worth a try to try the other one. And remove the changes in the first
<edrozim> smb,  I see that I already had session required pam_limits.so
<edrozim> in /etc/pam.d/common-session
<smb> Hm are the additional entries before the optional ones?
<herton> ppisati: can you check and rebase against master (2.6.38-11.47) the natty ti-omap4 branch? we need to release a new update
<edrozim> smb, http://paste.pocoo.org/show/446058/ - this is common-session
<edrozim> smb , and this is http://paste.pocoo.org/show/446060/ - this is noninteractive
<apw> edrozim, and how does the app get started
<smb> Hm, the place looks right. So all should get the soft limit set in limits.conf...
 * ogasawara back in 20
<edrozim> apw , it is java application that have several *.sh  that call each other so it is difficult to detect 
<edrozim> apw, I can give you output of ps ax if you want ?
<apw> nope that won't help me i don't thin
<smb> I guess the question was more targettat at whether you start them form cmdline or it gets started as a init task
<edrozim> smb, but anyway I update both session files
<edrozim> also I see that NetworkManager process have same limit
<edrozim> I take it just for example
<edrozim> grep files /proc/<NetworkManager PID>/limits 
<edrozim> give me Max open files            1024                 4096                 files
<edrozim> so actually issue is not with this certain java application but genrally with system - it get limits per process not from limits.conf
<edrozim> ... or I can to give this limits correctly :)
<smb> That are the kernel default, but I thought I had been playing a while ago and got the limits changed by limits.conf and changes to the session files
<smb> Hm, wait... could the number you give be too high...
<smb> edrozim, Have you tried some smaller values yet? like 8192 for soft and hard?
<edrozim> smb , ok I will try 
<edrozim> smb, is it OK if I will leave "session required pam_limits.so" in both files ?
<smb> edrozim, You just have to be aware that the limits (if it works) then apply for anything in the system
<apw> edrozim, one limitiation in there is that * will not match root, so if your task starts as root and does not use anything which triggers pam to switch user it might avoid the limits
<apw> you might try adding root soft ... and root hard ... and see if that changes anything
<smb> apw, good point
<apw> smb, its not at all clear unless su/sudo is used in application startup that any of pam will apply
<apw> edrozim, what starts this program, is it an init script
<smb> apw, As I said, I though I had seen the noninteractive have some effect on things started through init
<edrozim> apw , I start it manually . I login as normal user than made "sudo -s"  and start "sh" file
<edrozim> apw , smb , but any I add special lines for root 
<edrozim> *anyway*
<apw> edrozim, so if you do like ulimit -n 8192 after sudo -s, then run it does it work ?
<apw> if so you could just add that ulimit to the .sh and be happy
<edrozim> apw , !!!! thanks now it works :)
<edrozim> I add lines to limits.conf
<edrozim> smb , thanks to you too 
<edrozim> main point was as I understand that '*' don't apply to root
<apw> thats what it says in the comments in the limits.conf file
<edrozim> yap no I see this ...
<hggdh> herton: you there?
<herton> hggdh: yes
<hggdh> herton: I am looking for the 2.6.35-30 backport for lucid
<hggdh> herton: and cannot find the packages... archive.ubuntu.com only has the .dsc and .tar.gz, no binaries
<apw> hggdh, are they in universe
<ricotz> https://launchpad.net/ubuntu/+source/linux-lts-backport-maverick
<hggdh> apw: ah! thank you
<apw> hggdh, ok thats wrong
<hggdh> did not even think of looking in universe
<apw> hggdh, i don't think they are meant to be in universe
<tgardner> apw, it should be in main
<hggdh> apw: still, I should have looked there (just in case), and asked about them being in universe ;-)
<apw> hggdh, heh, will poke an AA and find out whats what
<apw> tgardner, ok master watson is sorting out the universiness ... should be sorted in an hour
<tgardner> apw, ack
<tgardner> now if I could just get linux-ti-omap4 NEW'd, life would be good (or at least less of a hassle)
<apw> m.watson is at debconf so you'll be looking for a new help
<apw> i thought we had a new kernel  trained aa in the us now
<tgardner> apw, should be clint
<jvgeli> I am running Natty on a laptop with AMD Fusion E350. HD Radeon 6310. My kernel is .39 RC4 but I get these freezes on the log in screes. Logs are clean, no indication of an error. Already filed a bug but somehow no one seems to know what he issue is. Hunch is pm_utils. someone tried downgrading pm_utils to Lucid version and it worked for them, but not for me. Is this a kernel issue? do we...
<jvgeli> ...have some kind of workaround?
<Tommeh> jvgeli, IIRC Fusion was a little flakey without newer packages from xorg-edgers.
<Tommeh> You might wish to try that.
<Tommeh> Actually, first, try kernel 3.0
<jvgeli> Tommeh: tried kernel 3.0 broke my system
<jvgeli> added xorg edgers and upgraded, broke my system
<Tommeh> You are having fun. :)
<jvgeli> yes I am, reinstalled 4 times in 3 days. really fun
<Tommeh> Heh
<Tommeh> Well, http://www.phoronix.com/scan.php?page=article&item=amd_llano_graphics&num=1
<jvgeli> now I am on .39 with an fglrx patch. got the GPU part working
<Tommeh> Bottom paragraph of that page (article written on June 14th) mentions that there isn't good Fusion/Llano support in any OS, which would include Natty at that point.
<jvgeli> the issue is this freezing problem on battery. looking at the bugs list looks like im not the only one. 
<Tommeh> And hints at 3.0 + what will be in 'edgers to get stable support.
<Tommeh> jvgeli, do you know if you're using dynpm power management?
<jvgeli> Tommeh: how do i find that out? talk to me please as if I am a newbie:)
<Tommeh> http://www.x.org/wiki/RadeonFeature
<Tommeh> Scroll down to the paragraph regarding power management. :)
<Tommeh> Or Kernel Power Management options.
<Tommeh> You might find that you can keep the GPU stable with 'mid' power profile and/or disabling dynpm if it's enabled.
<Tommeh> (Just heed the warnings regarding the low profile - it's not meant to be used with the monitors on. :))
<Tommeh> FYI, there's a #radeon channel for the ATI/AMD FOSS drivers, too. :)
<jvgeli> okay, im okay with warnings. been  hearing it a lot lately. When i told #ubuntu about me running kernel 3 on Natty the first words were bad and idea
<Tommeh> airlied/agd5f/glisse are all there. :)
<Tommeh> Haha.. I've been running it since -rc1. :)
<Tommeh> Depends really where you get it from and/or how you compile it.
<Tommeh> But it's been quite good to tell the truth.
<Tommeh> I can only hope that 3.1 is as quiet for a nice, stable 11.10 release.
<jvgeli> Tommeh: yeah, I also observed the faster performance in 3.0. If a stable one comes out id definitely get it. 
<apw> jvgeli, i am running 3.0 on much of my kit and its holding together
<Tommeh> I know how you feel though. My first experience of Ubuntu was installing 7.04 on a fakeraid set. I wound-up installing it by hand from a chroot, because the installer had no knowledge of dmraid/fakeraid. You had to install it manually with dpkg and use apt-get to pull down ubuntu-minimal/ubuntu-desktop meta-packages, etc. :)
<Tommeh> Endless 'fun'
<Tommeh> jvgeli, in theory, 3.0 is out now and stable. Where are you getting your kernels from?
<jvgeli> canonical kernel team
<Tommeh> As-in, this page? http://kernel.ubuntu.com/~kernel-ppa/mainline/
<jvgeli> pre compiled one. I dont have the patience to compile my own. 
<jvgeli> bingo!
<Tommeh> WFM. :)
<Tommeh> 3.0 works here (with Intel 2500K and HD6850) but my NIC driver is funky and doesn't allow for 3.0 as the kernel version, so spits out a 2.4.x kernel module.) 
 * apw is using the oneiric kernels
<jwi> hm, 3.1 in oneiric - you think that's likely?
<apw> jwi, no
<jwi> thought so
 * Tommeh figured 3.1 would be out well before October.
<Tommeh> Oh well. :)
<jjohansen> jwi: well you can always try the 3.1 mainline kernel, I'm sure you will be able to be oneiric on it
<bdmurray> bjf: bug 717167 isn't really missing anything
<ubot2> Launchpad bug 717167 in linux "package linux-image-2.6.38-3-generic 2.6.38-3.30 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 2" [Undecided,Incomplete] https://launchpad.net/bugs/717167
<apw> bjf, it looks to be a different class of bug which is really about packaging not about running so those files may well make sense as a complete set in that context
<bjf> bdmurray, i'm not making a distinction between package bugs and others
<bjf> apw, ^
<apw> bjf, it looks like we have a ProblemType, perhaps we could just ignore those with 'Package'
<apw> or indeed tag them kernel-packaging or somethin
<bdmurray> yes either the tag apport-package or ProblemType: Package
<bdmurray> ^- those mean the same thing
<apw> oh its already tagged
<bjf> apw, bdmurray, will look into it
<bdmurray> I'm going through and looking for grub2 bug reports and moving them to the right place
<apw> bjf for your todo list :)
<bjf> apw, bdmurray, we seem to be getting a lot of packaging bugs
<apw> yeah there was a huge spike in those recently i heard, an apt problem or something, bdmurray are you saying there is also a grub2 problem in the mix
<bdmurray> well the kernel post-inst calls update-initramfs which uses grub scripts to generate the grub.cfg
<bdmurray> and people mucking about with grub config files can cause this to fail
<apw> bdmurray, right so do we have a grub2 regression in natty, or ...
<apw> ahh
<bdmurray> or it could just be a bug in grub2
<bdmurray> anyway I've fixed apport now to send more bugs to grub2 and this is just cleanup
<apw> bdmurray, nice, the more bugs we don't get the happier i am
<apw> bjf, i assume you noticed the but report is 'stuck'
<bjf> apw, nope
<bjf> apw, but i see it now
<bjf> how annoying
<kees> apw: okay... what CVEs you see that are "pending" that you think should be released? my scanners don't show anything to me presently, and I wanted to double-check with you before I moved on to the status-sync tool work.
<apw> kees, things seem much more what i'd expect now, as in lucid is mostly released etc
<apw> kees, and i have no specific examples in mind right now
<apw> kees, i am mostly waiting now for things to actually release
<apw> kees, ps what did you do, i had all those lovely 0s and now 2011-1083 is back
<apw> that's just plain mean
<bjf> bdmurray, i think i've fixed that for package bugs, if you see any new ones which are incorrect, please let me know
<kees> apw: 2011-1083 and 2011-1747 turn out to not actually have upstream fixes (they had been incorrectly linked to other CVE fixes)
<kees> apw: on the other hand, 7 CVEs that aren't tracked yet have already been fixed in several releases
<apw> kees, when might we get those on our list
<kees> I'm gonna get those into the list today
<kees> will be using them as a test for the status sync tool
<kees> "does this CVE have a bug? *create*" etc
 * tgardner slinks off for lunch
<apw> kees, ok cool, will look out for them in the AM
<apw> and see what we find
<kees> cool
 * apw wanders off ... see ya tmmrrow
 * jjohansen lunch
 * bjf -> errand 
 * herton -> eod
<bdmurray> ogasawara: could you look at bug 811913?
<ubot2> Launchpad bug 811913 in linux "grub-pc replaces grub-efi and grub-efi-amd64 on upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/811913
<facundobatista> Hey sconklin 
<facundobatista> Hello everybody
<sconklin> hi facundobatista
<sconklin> so , I suggest that you enable the -proposed pocket, which will give you all the packages which are being tested there in preparation for release
<facundobatista> sconklin, is that at apt-get level?
<sconklin> Including the latest kernel package, which is a good way to see whether the problems you have are already solved by a change which has yet to be released
<sconklin> one sec while I find the wiki page
<facundobatista> ok
<sconklin> well, I can walk you through it. I can't find a wiki doc
<jwi> bdmurray: see bug 800910
<ubot2> Launchpad bug 800910 in apt "Kernel Upgrade forces removal of grub-efi due to missing recommends entry" [Undecided,Confirmed] https://launchpad.net/bugs/800910
<sconklin> open the update manager, and then click on "Settings"
<sconklin> Then under "Updates" select "Pre-released updates"
<sforshee> sconklin, facundobatista: https://wiki.ubuntu.com/Testing/EnableProposed
<sconklin> sforshee: thanks
<sconklin> facundobatista: you can follow those  instructions, and if you only want to enable kernel updates, you can do the part under "selective upgrading"
<facundobatista> sconklin, and which would be the kernel package to install from proposed?
<sconklin> if you enable -proposed and install it, right now you will get the 2.6.38-11.47 kernel for Natty
<sconklin> You can always see the kernel versions here:
<sconklin> http://people.canonical.com/~kernel/reports/versions.html
<facundobatista> sconklin, but which package is it? "linux-generic"?
<sconklin> (ignore the PPA version unless you're on the kernel team)
<charlie-tca> question? bugs are confirmed by brad figg pretty quickly. Are these complete bugs, and do they need to be marked triaged?
<sconklin> bjf^^
<sconklin> facundobatista: why? are you trying to pull the package and install it manually?
<sconklin> (which is an ok thing to do)
<bjf> charlie-tca, 1) that's a bot doing it, 2) "confirmed" means it has the logs we require
<quentusrex_> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/815540
<ubot2> Ubuntu bug 815540 in linux "Server becomes unresponsive after spawning 16 ksoftirqd processes" [Undecided,Confirmed]
<facundobatista> sconklin, no, but I want to do the "sudo apt-get install linux-generic/proposed" or something
<sconklin> you can see what version you have now with "uname -a"
<bjf> charlie-tca, going to "triaged" usually means that the latest upstream kernel has been tested
<charlie-tca> Okay, That sounds good to me
<facundobatista> ajÃ¡! I have a -generic one
<sconklin> facundobatista: once you change the  settings in update manager, all you have to do is "apt get update" and "apt-get dist-upgrade" and it will use the new pocket
<quentusrex> Anyone know how to get a per device(piece of hardware) interrupt statistics?
<sconklin> (and also get every other package in -proposed) 
<facundobatista> sconklin, I specifically put a file to not do that (following the wiki instructions), I do not want to update *everything*
<sconklin> ok
<facundobatista> sconklin, aptitude tells me that it doesn't find an archive "proposed" for the package "linux-generic" :(
<sconklin> just use "linux"
<facundobatista> it installed 2.6.38.10.25
<sconklin> facundobatista: that is the meta package version, and it will pull in the kernel versions. But - it's the one in -updates, not the one in -proposed
<sconklin> so check your package exclusion filtyers
<facundobatista> sconklin, yes, I just found that
<facundobatista> if I do apt-cache policy I see the newer version in proposed
<facundobatista> sconklin, so, the instructions in that wiki page are not working :(
<sconklin> that wiki page is very badly written
<sconklin> I have never filtered anything, I always take the latest -proposed, in order to help test all packages. So I'm not terribly skilled at that part
<facundobatista> sconklin, it's my working laptop, stability is a priority, I don't want to go bleeding edge :|
<bjf> facundobatista, if you have -proposed enabled, you could use synaptic pkg manager to just select the kernel version you want
<bjf> facundobatista, you can also run update-manager and just select the kernel, though deselecting all the other cruft is a pain
<sconklin> facundobatista: and yes, this is a pain. It should be easy to take proposed on only one or several packages, and it's been a wish list item for years.
<jwi> bjf: have you considered doing all the bot work through a proper bot account (or with some disclaimer)? i saw several bugs where users were confused and thought you were experiencing the same issue (thus confirming)
<bjf> jwi, you don't think: "This change has been made by an automated script, maintained by the Ubuntu Kernel Team." is enough of a disclaimer?
<jwi> the new -> confirmed script doesn't have that ...
<bjf> jwi, the script will eventually be run as "kernel-janitor" though i'm not sure what that buys anyone, other than people don't know who to ask about it
<bjf> jwi, i don't add a comment if it's just changing from new -> confirmed
<facundobatista> sconklin, it works ok with the proposed kernel!!
<sconklin> facundobatista: thanks a lot for going to the trouble to test that for us. It helps us a lot.
<facundobatista> sconklin, :)
<facundobatista> sconklin, thank you!!
<jwi> bjf: ok, either you completely misunderstood me or just dont think its a problem. fair enough :)
<bjf> jwi, i'm open to listening, is there an issue with this being done as me while it's in development?
<sconklin> and thank you for your kind words
<sconklin> kamal ^^
<kamal> sconklin: np
<xteejx> Hey guys, are there any kernel triagers hat can look into something for me please?
<xteejx> Its about bug 816145, it has personally affected me on the exact same laptop (was previously my machine). Is there enough information there for me to be able to send it upstream??
<ubot2> Launchpad bug 816145 in linux "Atheros AR5001 wireless card "wireless is disabled by hardware switch"" [Undecided,Confirmed] https://launchpad.net/bugs/816145
#ubuntu-kernel 2011-07-26
 * apw waves to smb
 * smb waves back to apw
<RAOF> apw: 302983e9059e9ef5de3ca7671918eeb237c5971e in drm-intel-fixes says âHi, I fix that diagonal crazyness bugâ
<apw> RAOF, got the bug number for that one by any chance ?
<RAOF> apw: bug #753994
<ubot2> Launchpad bug 753994 in linux "[arrandale] Display is slanted when using 1360x768 resolution" [Medium,Confirmed] https://launchpad.net/bugs/753994
<apw> ta
<apw> RAOF, has drm-intel moved again?  i don't see that in ickles tree
<RAOF> Yeah.  Keith's now managing drm-intel, and has been for some months.
<apw> damn
<RAOF> It occurs to me that the drm-intel-next autobuilds might be a little bit staleâ¦ :)
<apw> RAOF, ok wahts the official right URL so i can fix these up :)
<RAOF> url = git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
<apw> RAOF, ok i've switched the mainline builds to that tree too
<apw> smb, is .38 stable dead already?
<smb> apw, yup
<apw> RAOF, are commit ids stable in drm-intel-fixes ?  i am suspecting not
<RAOF> apw: I am uncertain.
<apw> ppisati, can i assume you are not doing any CVEs ?  we have no bugs right now as kees has not made them
<apw> so we have no way to interlock till he sorts that
<ppisati> apw: yep. doing other stuff
<cooloney> ppisati: hey, man. your 3.0 omap4 kernel rocks
<ppisati> cooloney: save these words for when it will panic :)
 * apw wonders if sound works
<cooloney> apw and ppisati, i only player server image like headless without testing sound
<ppisati> nope, sound is broken
<ppisati> at the kernel level
<ppisati> and pulseaudio is so stupid that, in case a dsp device doesn't react correctly to an open+ioctl
<ppisati> it keeps retrying like an idiot
<ppisati> sucking 100%cpu
<ppisati> so in entirely disabled snd*
<smb> apw, Would you consider installing linux-tools from a different release for debugging a valid use case? There is bug #783660 and the change of linking libfd statically may be acceptable... If we think that should be supported
<ubot2> Launchpad bug 783660 in linux "linux-tools: perf should link statically to libbfd" [Low,Triaged] https://launchpad.net/bugs/783660
<apw> smb, a different release, so for that you'd need to be using a different kerenl from a different release
<apw> and we don't really support that either
<smb> I guess the usage is mainly to debug issues with newer/or against newer kernels, yeah. It is certainly not normal use
 * ppisati -> out for lunch
<apw> smb, reading the bug in full it seems that this represents a policy violation so i'll probabally do something about it
<smb> At least something that should not be done with debian yeah
<smb> Trying to check the suggested approch atm
<apw> well ubuntu policy is very much unchanged from debian in the general case
<smb> Yeah, agreed. Downside for us is that this will be something we will then carry as a deviation
<tgardner> apw, I came in on the 2nd half. what y'all talking about?
<smb> tgardner,  bug #783660
<ubot2> Launchpad bug 783660 in linux "linux-tools: perf should link statically to libbfd" [Low,Triaged] https://launchpad.net/bugs/783660
<apw> we are linking perf against a dynamic library, which 1) doesn't work in all installs and 2) is (liely) a policy violation
<tgardner> apw, has it done this from the start ?
<apw> yep
<smb> apw, Was the violation actually any dynamic lib ?
<apw> smb, no it seemed to be libbfd specifically
<tgardner> apw, seems like a straightforward fix. do wee need to add a build dependency?
<tgardner> or is libfd already there somewhere
<apw> we are already dep on htat
<apw> tgardner, smb i think is testing the patch at th mo
<smb> apw, tgardner At first it looks straight forward enough
<tgardner> apw, smbremember tangerine is liekly to disappear today
<smb> Just strangely I do seem to not get what I think I should get from that print-file-name
<smb> tgardner, Thanks. Not yet doing something there but reminding me not to try even
<smb> apw, For some reason it looks to me as -print-file-name=x just outputs whatever x is. /me wonders whether it would not then be simpler to just replace -lbfd with libbfd.a
<apw> kees, what tz are you on today i wonder
<apw> smb, doesn't it have to be a full path name
<apw> if its not -l
<apw> apw@dm$ gcc -print-file-name=libc.a
<apw> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../libc.a
<smb> Could be and that is what man gcc suggests...
<apw> smb, that looks like it does the right kind of thing
<smb> wtf...
<apw> apw@dm$ gcc -print-file-name=libtic.a
<apw> /usr/lib/libtic.a
<smb> Great it prings the full path name if it exists and whatever you type if not...
<kees> apw: I'm in central and up early
<smb> apw, Ok, guess its then failing later and if it works then you got the full pathname...
<apw> kees, wondering how we are getting on with making bugs for those cves, i'd like to wack some of them but they have no bugs
<kees> apw: I'm about 30 minutes from having it automated, but I can shove them in manually now if you want?
<apw> (oneiric-i386)apw@dm$ gcc -print-file-name=libbfd.a
<apw> /usr/lib/libbfd.a
<apw> smb, ^^ i
<apw> smb, ^^ in a chroot
<smb> gcc -print-file-name=thisistupid
<smb> thisistupid
<apw> kees, no as long as they are soon
<kees> okay, cool
<apw> smb, right when its not found it returns just the name
<smb> apw, That confused me a bit... but as said it likely fails at some point in that case
<apw> smb, right it should just error cause the file is missing, but the tool should only use it when it is available anyhow iirc
<smb> apw, So it looks ok, then I will try test build and forward it to the list
<apw> smb, thanks
<linuxR> hello everyone..whn upgrading my ram from 1g to 2g, the system (ubuntu 11.04) becomes unusably slow. windows not affected, other distros not affected,  booting from live cd not affected..can someone help?
<_ruben> sounds like a coincidence to me
<linuxR> it is reproducible
<linuxR> I suspect a relation to video mode setting because grub is also affected, only works at normal speed when used in text mode
<apw> where is the extra ram placed by the bios?  that info is in the e820 dump in dmesg
<apw> also could you give us a hint as to what unusably slow means?  particularly in grub which isn't doing anything much
<linuxR> sure, slow grub means that switching the cursor from one menu entry to another takes a second, editing an entry takes 10 seconds to load the edit screen 
<linuxR> I have put together all dmesg and lshw memory output here:
<linuxR> https://bugs.launchpad.net/ubuntu/+bug/816035
<ubot2> Ubuntu bug 816035 in ubuntu "Memory upgrade makes Ubuntu painfully slow" [Undecided,New]
<linuxR> I'd love to believe that this is just a flawed BIOS, but other OS seem to have no problem with that. And I really don't want to drop ubuntu :(
<apw> linuxR, what linux distros did work and which boot loader did they use
<linuxR> apw, I installed fedora15
<apw> and which boot loader does that use
<linuxR> gotta check that
<apw> linuxR, ok i'd say the problem is almost cirtainly the bios setup of the MTRRs
<apw> with 1GB of ram you have:
<apw> [    0.000000]   0 base 000000000 mask FC0000000 write-back
<apw> and with 2GB you have:
<apw> [    0.000000]   0 base 000000000 mask F80000000 write-back
<apw> oh hmm maybe that is right ... argle they hard to decode
<linuxR> seems not fundamentally wrong to me
<apw> interestingly the timings are very very similar if not faster on the 2g machine well into kernel init
<linuxR> is there anything more I can provide to narrow down the problem?
<apw> linuxR, you could try booting with enable_mtrr_cleanup mtrr_cleanup_debug
<apw> linuxR, i am suspicious there are overlapping mtrrs with the same type and a lot of the things you cannot do that with in mtrrs
<apw> the processor just gets it wrong
<apw> [    0.000000]   1 base 07E800000 mask FFF000000 uncachable
<apw> [    0.000000]   2 base 07F800000 mask FFF800000 uncachable
<apw> particularly 2 there, is that not overlapping with the first half of 1
<apw> linuxR, the other thing being what bootloader does F15 use as that is not affected and grub2 is
<apw> linuxR, and you said that a liveCD was not affected even with 2g of ram.  that uses syslinux, so doesn't help bootloader side, but a dmesg there may also be eligntening
<linuxR> oh...
<linuxR> I booted with "enable_mtrr_cleanup" and it booted FAST
<apw> ok ... so it is very likely those overlapping mtrrs which are causeing the issue
<apw> ok could you add that info and the dmesg for 2g with that option to the bug
<linuxR> what does mtrr_cleanup" do? is the problem solved by this?
<apw> i suspect that the bootloader may be fixing those in the F15 case, so finding out what that uses is also useful
<linuxR> I'll just attach the new dmesg
<apw> linuxR, it is designed to make more space in your mtrrs (there are only a handful) for bad bioses, it does this by combining those that it can and removing the unnecessary ones
<apw> this will likley remove the overlapping one i am worried about
<apw> which is why i wanted you to test with it
<kees> apw: wasn't the cve tracker LP tag changed from kernel-cve-tracking-bug to kernel-cve-tracking ?
<apw> it doesn't appear so
<kees> okay
<apw> kees, thuough i'd based that on whatever the script puts on
<kees> yeah, looks like it's still -bug from all the scripts
<kees> actually...
<kees>                                 elif 'kernel-cve-tracker'           in lp_bug.tags: state = 'cve-tracker'
<kees>                                 elif 'kernel-cve-tracking-bug'      in lp_bug.tags: state = 'cve-tracker'
<kees> both show up in the sru-report, but create-cve-tracker uses kernel-cve-tracking-bug
<kees> is there a preference?
<apw> maybe they are meant to be switching, hrm ... i'd have to refer you to bjf/sconklin
<apw> i am assuming we use whatever the script does
<kees> okay
<apw> linuxR, is that dmesg coming ?
<linuxR> in a sec
<linuxR> its there
<apw> linuxR, ok its wrapped the dmesg with the debug, could you reboot with just enable_mtrr_cleanup and paste a dmesg of that
<apw> and perhaps the output of cat /proc/mtrr, could you paste that in privmsg so i can look at it while you do that :)
<linuxR> oh sure, wait :)
<linuxR> added /proc/mtrr to the bug
<linuxR> apw, new dmesg uploaded
<apw> linuxR, thanks, so yeah that shows the new layout is without any overlaps but covering the same range i think
<linuxR> so the problem can be considered as solved now I guess
<apw> i thought that grub2 could clean up the mtrrs but i don't know if thats something that got slipped, or has to be enabled by default
<apw> i beleive the underlying issue is the bios producing invalid mtrr settings and that freaks the cpu out which is likely effectivly disabling the cache on the cpu for all of ram
<linuxR> is this "mtrr cleanup" something persistent that grub could do and would still be correct when the kernel is started?
<apw> the kernle uses whatever mtrrs are set up before it starts normally, unless you ask it to cleanup
<linuxR> so grub would have to do this on its own
<apw> i don't believe any mtrr support has been added to grub2 as yet, as the bios is expected to do the right thing
<apw> it is required to do the right thing
<apw> now i wonder why the CD isn't affected
<sforshee> apw, is there a reason we don't enable mtrr cleanup by default?
<apw> sforshee, its not something the kernle does by default i assume
<sforshee> apw, it looks like can be enabled by setting CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
<apw> interesting, maybe that is the difference
<apw> where is jj and his magic comparison table when i need it
<tgardner> apw, would that be in jj's spreadsheet ?
<apw> tgardner, yeah did he email that out ?
<apw> tgardner, my quick googles say it is on by default in fc12 at least
<tgardner> apw, perhaps we ought to have a look at it
<apw> tgardner, yep am doing so now
<ogasawara> apw: if it helps, people.canonical.com/~jj/amd64-default.ods
<apw> ogasawara, thx
<apw> ok so on in FC and off in SLES
<apw> tgardner, what do you think about enabling same in oneiric as an experiment
<tgardner> apw, seems like a good idea. I assume its not experimental ?
<mfilipe> sforshee, hi! someone released a patch to fix the problem with weaver output: https://bugs.freedesktop.org/show_bug.cgi?id=38750#c9
<ubot2> Freedesktop bug 38750 in DRM/Intel "[Arrandale] Intel Core i3 External Monitor Wavy Output" [Normal,New]
<mfilipe> sforshee, is there any date to that patch will be applied in lucid?
<sforshee> mfilipe, I've been monitoring the comments. It's looking good for those affected by the problem, but I'm unsure whether or not it could cause regressions for others.
<sforshee> mfilipe, it would be nice to have some comment from the upstream developers. Maybe I'll poke at them and see if we can get some feedback.
<apw> tgardner, no not experimental 
<apw> i'll enable it for oneiric then i think and see what happens
<mfilipe> sforshee, please. thanks a lot
<tgardner> apw, ack
 * ogasawara back in 20
<EtienneG> bjf, hey!
 * tgardner pushes a natty build fix 'cause he didn't do his homework first.
<bjf> sconklin, herton, ^ bug 811745
<ubot2> Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [Undecided,Confirmed] https://launchpad.net/bugs/811745
<EtienneG> bjf, I am still not 100% positive, but it seems like there's a regression in 2.6.32-33 (bug #811745)
 * sconklin looks
<EtienneG> bjf, I have not reproduced it myself, but I work with someone who confirmed it
<EtienneG> bjf, it is not in the bug, but I am vaguely suspecting it might be NTFS-specific
<tgardner> gosh EtienneG, could you be a little more vague ?
<EtienneG> sconklin, bjf: I have asked the person who can reproduce the bug to check if non-NTFS removable storage also trigger the bug.  Waiting to hear back from him.
<EtienneG> tgardner, sorry!  :)
<bjf> EtienneG, it's the usual story, let's reproduce and then we can bisect and test
<bjf> EtienneG, have you been able to repro the problem?
<apw> if its ntfs sticks which blow then it should be easy to check
<EtienneG> bjf, sure.  I will let you know if/when we have it confirmed.  Just wanted to give you a heads up.
<apw> EtienneG, have you tried formating a usb memory stick to NTFS
<bjf> EtienneG, sure, thanks
<EtienneG> bjf, apw: I have not reproduced the problem myself, it's a second hand account.  That's what I am working on now.
<herton> looking at the kernel changelog, the same scsi change that brought regressions into natty is applied on lucid after 2.6.32-32
<herton> so probably it's it causing issues (bug 811745)
<ubot2> Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [Undecided,Confirmed] https://launchpad.net/bugs/811745
<tgardner> herton, sconklin was muttering dark thoughts about that patch last week
<herton> tgardner: that patch that was bisected on natty and reverted ("put stricter guards on queue dead checks") is applied on lucid also, can likely be issue here
<tgardner> herton, I'd say its a likely candidate
<jwi> there was a long thread of possibly related noise on lkml, i believe this is were it started: https://lkml.org/lkml/2011/7/1/335
<herton> I'll build a lucid kernel with the reverts and ask for testing on that bug report (may take some time if tangerine is offline)
<tgardner> herton, use tyler
<linuxR> thanks apw for solving the mtrr memory issue! I need to have a drink now  :)
<herton> tgardner: is it tyler.buildd?
<kees> apw: so, it looks like there are only 6 open CVE tracking bugs. can you confirm that?
<apw> kees, before your new ones?
<kees> apw: right. currently in LP.
<kees> apw: actually, that seems low. where is ogasawara's CVE bug report?
<ogasawara> kees: http://people.canonical.com/~kernel/reports/kernel-cves.html
<kees> hmmm. that's more than 6 :)
<kees> ogasawara: can I see the code you're using to generate that list?
<kees> ogasawara: I want to make sure I'm doing the same thing... which it seems i'm not
<apw> kees, you arn't making the mistake of searching for open ones are you ?
<ogasawara> kees: sure, do you have a copy of our kteam-tools repo?
<kees> yup
<kees> apw: maybe?
<apw> kees, you have to sarch for all of them and ignore the closed ones
<apw> when you search for 'open' against linux you are searching for open in devel only
<apw> you either have to search for all bugs and ignore the closed ones
<apw> or you have to search in ubuntu/oeniric/linux ubuntu/lucid/linux etc and merge the results
<ogasawara> kees: look at kteam-tools/cvescripts/kernel-cves.py
<apw> kees, you should find i put a could of the bug numbers in the cve files when i made them at the end of last week
<apw> kees, so you should have some lknkage already
<ogasawara> kees: basically I'm starting by looking at all bugs tagged kernel-cve-tracking-bug
<apw> ogasawara, are you searching in 'ubuntu'
<ogasawara> apw: yep
<apw> and including closed ones
<ogasawara> ubuntu = lp.distributions['ubuntu']
<ogasawara> cves = ubuntu.searchTasks(tags=['kernel-cve-tracking-bug'])
<ogasawara> apw: and then I just basically loop all bug tasks for each bug
<apw> and that doesn't make LP nearly collapse oh no :)
<kees> ogasawara: ah, yes. ubuntu.searchTasks. I was doing ubuntu.getSourcePackage(name='linux').searchTasks
<kees> adjusting...
<kees> I'm actually using this:  ubuntu.searchTasks(
<kees>                     tags=['kernel-cve-tracker','kernel-cve-tracking-bug'],
<kees>                     tags_combinator='Any',
<kees>                     omit_duplicates=True):
<kees> we'll see if it comes out the same
<kees> okay, much better. found 20
<apw> kees, i thought we were just putting hte bugs numbers in the cve tracker
<kees> apw: I am. but I need to find the bugs to avoid creating duplicates.
<kees> apw: and when I find the LP bug, I add it to the tracker
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<mfilipe> sforshee, http://pastebin.com/AjeiNxm5
<mfilipe> :(
<mfilipe> I'm thinking buy a displayport monitor but they are expensive in Brazil :(
<sforshee> mfilipe, yeah, I was just reviewing the patch prior to pinging Chris but was coming to the conclusion that it would probably have the same problems as the one Chris originally supplied
<sforshee> mfilipe, have you tried passing lvds_use_scc=0 on the command-line? I'm not sure whether or not it would help, but might be worth trying.
<mfilipe> nop
<mfilipe> I will try
<mfilipe> but I don't know where the best place to add these argument 
<mfilipe> where?
<sforshee> mfilipe, if the fundamental problem is with disabling ssc when plugging in the external panel, it might help since it should keep ssc off
<sforshee> mfilipe, you need to modify /etc/default/grub
<sforshee> mfilipe, add that parameter in GRUB_CMDLINE_LINUX
<sforshee> mfilipe, then run 'sudo update-grub'
<sforshee> mfilipe, that makes it permanent...
<mfilipe> aff
<sforshee> but if you want to try it first you can modify the command line from grub as well
<mfilipe> my driver version hasn't that option: http://pastebin.com/bDm0jisK
<mfilipe> I'm using 2.6.35 yet
<mfilipe> backport of maverick
<mfilipe> I see that you released the backport of Natty
<mfilipe> so, I will use it 
<mfilipe> do you know if it has that option in module? 
<sforshee> mfilipe, sounds good
<sforshee> mfilipe, let me check...
<sforshee> mfilipe, yes, natty's driver has that parameter
<sforshee> mfilipe, actually you probably need to use i915.lvds_use_ssc=0
<mfilipe> I will reboot
<kees> apw: so, I have a sync question ... 2010-3448 is tracked in 706999. it doesn't show up in ogasawara's report -- it's missing lts maverick in the tracker still.
<kees> what should be done here?
<apw> any idea why its not in her report ?
<kees> looks like all the bug tasks are closed. (i.e. it's missing the lts-maverick task)
<ogasawara> because all the bug tasks states are in a closed state (eg Fix Released or Invalid)
<ogasawara> I skip all close bug states
<apw> kees, probabally the backport didn't get added back then
<apw> i would add it now and it should close anyhow
<kees> yeah
<apw> or else appear on leanns list, which is good
<kees> it's already pending, but I wonder if the sync tool should add the missing task
<apw> i suspect its not necessary as you'll make them right in the first place no ?
<apw> we could just fix the broken ones by hand
<apw> i cna help do that
 * kees wonders about adding new LTS backports ...
<ogasawara> kees: I notice that bug is also only tagged kernel-cve-tracker, should I be looking at that tag too?
<kees> ogasawara: yes. see stable/sru-report -- it seems to look for both tags
<apw> ogasawara, i think it is probabally ppisati who made it :)
<kees> ogasawara: no idea why there isn't just one
<ogasawara> kees: ack, will add that to my script
<apw> kees, confusion i suspect, and there should be, and we should get sconklin to chose one and fix it
<sconklin> apw: I'm not aware that we have ever picked a standard tag for CVEs, nor do we (stable team) have any scirpts which deal with them as far as I know (But I could be wrong).
<kees> sconklin: there are multiple scripts that use the two tags :)
<kees> sconklin: including the bug-creation script
<sconklin> ok, well, I'll investigate when I finish today's meeting prep
<bjf> sconklin, apw, when i wrote the original script i started putting "kernel-cve-tracker" on all of them, what happens now, I don't know
<apw> it seems to have become perverted into kernel-cve-tracking-bug, possibly to mirror the stable trackers
<apw> bjf, ^^
<kees> LP API is soooo slow
<bjf> apw, i see, i could have done that, don't remember
<apw> kees, it is wonderful, sexy, and all powerful and dont you forget it
<apw> (else it may come round and hide your toys in the night)
<kees> heh
<mfilipe> sforshee, ldvs_use_ssc=0 without solution :(
<sforshee> mfilipe, too bad
<sforshee> it was worth a shot
<mfilipe> ldvs_use_scc*
<sforshee> mfilipe, wait...
<sforshee> did you see my message about using i915.lvds_use_ssc instead?
<mfilipe> we need something like enable that code when we use ldvs_use_scc=0 
<mfilipe> "<sforshee> mfilipe, actually you probably need to use i915.lvds_use_ssc=0"
<mfilipe> your last message
<sforshee> mfilipe, run 'sudo cat /sys/module/i915/parameters/lvds_use_ssc' and see what the value is
<mfilipe> lol
<mfilipe> I will boot again with the argument 
<mfilipe> one minute
<sforshee> mfilipe, catting the value will tell you whether or not you need to test again
<manjo> tgardner, I might have missed you wall message.. is tangerine coming back up soon ?
<mfilipe> sforshee, but I rebooted without the arg
<mfilipe> I added it in grub
<mfilipe> boot grub*
<sforshee> mfilipe, okay, that won't work then :)
<tgardner> manjo, tangerine is gone for a couple of days. I've been sending out regular notices that tangerine will be down for disk maintenance.
<mfilipe> one minute
<manjo> tgardner, ok looks like I did not read those... np
<manjo> tgardner,  just an idea ... probably you could put that in motd next time ... my bad anyway for not reading the notice by email
<mfilipe> sudo cat /sys/module/i915/parameters/lvds_use_ssc => 0
<tgardner> manjo, like yuo'd read the motd anyways...
<mfilipe> with weave output 
<mfilipe> sforshee, thanks for your time, it was a good shoot :)
<sforshee> mfilipe, np, sorry it didn't work
<mfilipe> sforshee, you don't need apologize us but Intel yes :P
<mfilipe> a basic function without a solution 1+ year ago :(
<bjf> ##
<bjf> ## Kernel team meeting in one hour
<bjf> ##
<mfilipe> they don't gave nothing answer... they can answer something like "we don't know the solution but we have a employee working fulltime in this problem"
<mfilipe> but nothing
<mfilipe> 1+ year with nothing 
<mfilipe> sorry for my english
<mfilipe> hehe
<sconklin> kees, bjf, apw: I'm starting to look at unifying the CVE tagging throughout our tools
<kees> sconklin: cool
<tgardner> apw, I assigned you to bug #816035 since you'r already working it
<ubot2> Launchpad bug 816035 in linux "Memory upgrade makes Ubuntu painfully slow" [Undecided,In progress] https://launchpad.net/bugs/816035
 * herton -> lunch
<kees> ubuntu.searchTasks(search_text='CVE-2010-3448', omit_duplicates=True, status=["New","Confirmed","Triaged","In Progress","Fix Committed","Fix Released"]) returns nothing :(:(
<ubot2> kees: drivers/platform/x86/thinkpad_acpi.c in the Linux kernel before 2.6.34 on ThinkPad devices, when the X.Org X server is used, does not properly restrict access to the video output control state, which allows local users to cause a denial of service (system hang) via a (1) read or (2) write operation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3448)
<tgardner> hmm, the bot has sharp eyes
<kees> ogasawara: any clue on that? I can't find any closed tasks...
 * ogasawara scrolls back
<kees> ogasawara: just before the bot spew
<ogasawara> kees: what's the actual bug # it should return
<kees> 706999
<ogasawara> kees: I think the search_text= capabilities are crap.  I recall apw saying it was utterly stupid.
<kees> ogasawara: as in, it doesn't search titles?
<ogasawara> kees: even when I go to https://bugs.launchpad.net/ubuntu/+bugs and put "CVE-2010-3448" in the text box to search, it returns nothing
<ubot2> ogasawara: drivers/platform/x86/thinkpad_acpi.c in the Linux kernel before 2.6.34 on ThinkPad devices, when the X.Org X server is used, does not properly restrict access to the video output control state, which allows local users to cause a denial of service (system hang) via a (1) read or (2) write operation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3448)
<kees> ogasawara: greeaaat
<kees> this is a total show-stopper for sane tracker/LP sync :(
 * smb thinks to remember apw saying, he got told hypens are not lps best friend
<kees> and I can't search for all statuses with tags=['kernel-cve-tracker','kernel-cve-tracking-bug'],tags_combinator='Any' because the search times out
<ogasawara> pft, lovely
<kees> this is stupid
<kees> okay, so new requirement: if the bug isn't linked in the tracker, it doesn't count. :P
<sconklin> of interest to all of us who develop scripts using the LP API:
<sconklin> http://blog.launchpad.net/coming-features/no-more-monthly-90-minute-downtime
<sconklin> "If you have API scripts running against Launchpad, you may want to build in a retry mechanism to deal with up to a few minutes of downtime."
<ogasawara> kees: when the bugs get created, would it help to tag them CVE-####-#### so you could look them up by tag, rather than having to search the title?
<kees> ogasawara: well, since I can't search by title, I guess that's the only option
<kees> ogasawara: actually, no
<kees> ogasawara: that won't help because it needs to be in an open state to find them
<kees> ogasawara: I can't find closed bugs is the problem
<kees> so, in the case of 2010-3448, the sync tool (if it didn't have a manual entry) would just build another bug
<ogasawara> kees: but you could tell the search to include the closed states as well right? 
<ogasawara> kees: status=["New","Confirmed","Triaged","In Progress","Fix Committed","Fix Released", "Won't Fix", "Invalid"] tags=['CVE-2010-3448']
<ubot2> ogasawara: drivers/platform/x86/thinkpad_acpi.c in the Linux kernel before 2.6.34 on ThinkPad devices, when the X.Org X server is used, does not properly restrict access to the video output control state, which allows local users to cause a denial of service (system hang) via a (1) read or (2) write operation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3448)
<ogasawara> or does that time out as well
<kees> ogasawara: it times out
<ogasawara> what a POS
<bjf> kees, then you should be talking to them in #launchpad
<kees> ogasawara: I was trying to just look up all the tagged bugs, but it can't do "all", just "open"
<bjf> kees, that's really not acceptable
<apw> tgardner, thanks, pushed
<apw> kees, you can't search based on titles
<apw> if they have '-'s in them
<kees> bjf: hundreds of things about LP are not acceptable. usually they ignore "special" requests. https://wiki.canonical.com/Security/Malone has multi-year old platform-blocking bugs listed
<kees> apw: is there a bug open for that?
<bjf> kees, so we don't talk to them about it?
<bjf> kees, timeouts are one of if not the highest priority for LP
<apw> kees, i think so, someone pointed me to it, i think it was <100k though so no much chance of it ever being actually fixed
<apw> i gave up when they showed me 4 bugs in what i was trying to do, ie stopping me
<apw> thats when i started just looking them all up and eliminating them by hand and sod the performance consquences
<kees> bjf: we do, and i will, but it won't be fixed for literally years, so it's not high on my list to do
<apw> kees, for example i iterate over all the cve tasks in bugs/proc-cve-bugs
<bjf> kees, it wouldn't time out if you were using GO
<apw> which applys the equivalent of DNE to all the tasks
<kees> bjf: hahah
<ogasawara> kees: if you throw in the 'has_cve' in the search criteria, does that help reduce the set so it doesn't time out?
<apw> bjf, can you imagine what go would do to them, as your 40 thread thing killed it in the face
<kees> ogasawara: good question, let me try
<apw> kees, you trying to find related bugs now as well A
<apw> ?
<kees> ogasawara: nice trick :)
<kees> apw: no, just kernel tagged ones to make sure I have a full mapping
<apw> my searches don't time out, odd
<kees> apw: ubuntu.searchTasks(tags=['kernel-cve-tracker','kernel-cve-tracking-bug'], tags_combinator='Any', omit_duplicates=True, status=["New","Confirmed","Triaged","In Progress","Fix Committed","Fix Released"])
<kees> that ^^ doesn't time out for you?
<apw> i don't think i check for status at all
<kees> apw: right, that will only show "open" tasks
<apw> ahh yes, it would work with only open ones in this case
<apw> don't you need Invald in the list too
<kees> apw: I need the ones that are missing tasks (like the 2010-3448 example)
<apw> well thats what i mean, if i make them all invalid you'd miss the bug en-toto
<kees> either they won't be in that state or I can add it to the status list.
<kees> regardless, this is a corner case, and i'm going to ignore it for the moment
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 10 minutes - #ubuntu-meeting
<bjf> ##
<sconklin> so apw and kees, have you two made a decision about which tag will be the officially correct one, or is that still waiting for me to do?
<kees> sconklin: I'm looking for either at this point. I have no preference since I'm just using the kteam tools to build the bugs
<kees> (but my thinking would be that having "-bug" at the end seems redundant)
<apw> sconklin, i don't care which we use, i think whichever is most similar to the normal naming for our other trackers is the one to take
<sconklin> kees: it looks to me as if the tools looks for both, but only ever create "kernel-cve-tracking-bug"
<kees> kyupagreed
<kees> er, yup, agreed
<sconklin> so let's make that the definitive choice, and deprecate kernel-cve-tracker
<kees> fine by me (I'm not sure what created "kernel-cve-tracker" in the first place)
<apw> a lot of the older ones were manual
<sconklin> apw: yes, I'm sure that's how it happened
<apw> kees, so ... a while yet before i see bugs
<kees> apw: I'm very close now :)
<kees> apw: this is where I am at the moment: http://paste.ubuntu.com/652530/
<kees> apw: but I have a meeting now...
<apw> kees, i wonder if it is worth making bugs where things are essentially about to move over to retired
<kees> apw: right, I'm doing the new ones now, just to unblock you
<apw> kees, most of our stuff being in pending already so soon.  perhaps we could mark all the ones that don't have a bug at the moment and arnt your new ones as like Bug: not-required
<apw> kees, and ignore them for now
<bjf> ogasawara, can you post: http://pastebin.ubuntu.com/652562/ in voices for me, it's still borked
<ogasawara> bjf: yep, 2secs
<bjf> ogasawara, no rush
<bjf> maybe i'll use pastebin as my blog
<kees> apw: okay, 7 bugs opened
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - August - 02 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<ogasawara> bjf: done
<apw> kees, thanks
<cking> apw, I've punted you some UDS flight info updates. I hope to make a booking in the next 36 hours or so, so let me know what you think tomorrow 
<apw> cking, ack
<apw> bjf, i like the sound of that
<apw> kees, are the numbers in the tracker?
<kees> "numbers" ?
<apw> bug numbers
<apw> as ... seaching for them is as you know difficult !
<kees> testing that now (it's the first sync action finished in the sync tool)
<apw> ahh yes, i see the bugs, i assume they will start to close/invalidize themselves and i should leave those bits be
<kees> apw: right, that's what I'll be poking at here
<apw> i'll only touch the bits i am working on and make them in-progress then you will have a full spectrum to 'fix'
 * kees nods
<kees> apw: okay, bug links are now in the tracker
<bjf> captain, there be cve bugs here!
<apw> bjf, sharks ho
 * tgardner --> lunch
 * cking notes that pulling images from .tw to .uk takes forever
<apw> cking, luckily i don't need to use the binaries i am building, otherwise yep its mostly useless
<jmburgess> Hey kernel team! I'm triaging bug 814323 and it looks like the original reporter and one of the commenters(andrea) is having the same issue...one caused by virtualbox, one by vmware I asked the original repoter to try the mainline kernel, should I also ask andrea?
<ubot2> Launchpad bug 814323 in linux "The laptop does not suspend anymore" [Undecided,Confirmed] https://launchpad.net/bugs/814323
<apw> jmburgess, its sounding like external modules are triggereing suspend issues, i am not sure we should do anything other than ensure the upstreams for those modules are aware and working on fixing
<jmburgess> apw: thanks ill tell the upstream virtualbox bug about the ubuntu bug. 
<ogasawara> damn, no diwic
<jwi> regression in current natty-proposed: bug 814250
<ubot2> Launchpad bug 814250 in linux "Apple Magic Mouse stopped working" [Undecided,Confirmed] https://launchpad.net/bugs/814250
<apw> kees, how far away is the status sync, i have a scriptlett which will apply DNE which i could run to clear out the cruft on these cve bugs
<apw> (particularly the sync of DNE -> Invalid
<kees> apw: I'll do DNE in a bit here, I'm still looking at adding tasks for missing packages (the CVE adding script doesn't add linux-ec2 for some reason...)
<apw> kees, probabally simply a bug
<kees> apw: yeah, it's just not in the list of pkgs in create-cve-tracker
<apw> kees, linux-ec2 is almost exclusivly a 'rebase' applied tree
<kees> doesn't mean it's not tracked :)
<apw> no but it means noone normally needs to execute on it, so noone noticed they have no task to change
<kees> heh
<ogasawara> bug 792959
<ubot2> Launchpad bug 792959 in linux "Error in upstream stable patch for xhci" [Undecided,Fix released] https://launchpad.net/bugs/792959
<apw> ogasawara, ?
<apw> ogasawara, that looks like a bug which should have stable-next as a tag on it
<ogasawara> apw: was just checking which state the bot would show
<ogasawara> apw: was already marked Fix Released for Lucid and Maverick, but the root linux task, eg implying oneiric, was marked Incomplete
<apw> sconklin, should ^^ bug have stable-next on it?
<ogasawara> apw: so I've since closed it completely
<apw> ogasawara, sensible indeed
<sconklin> apw: yes, although it predates the beginning of when we started that convention. I would like to have all such bugs tagged so we can go back later and get some numbers
<sconklin> I can add it
<apw> sconklin, ack
<sconklin> done
<bjf> sconklin, are you marking new bugs "kernel-stable-next" ?
<sconklin> bjf, no but we should. I will start now.
<sconklin> And I'll change all the old ones, while there aren't many
 * bjf likes putting "kernel-" on the front of any of our tags
<apw> bjf, +1
<kees> apw: does 816542 look the way you'd expect it?
<apw> bug #816542
<ubot2> Launchpad bug 816542 in linux "CVE-2011-1078" [Undecided,In progress] https://launchpad.net/bugs/816542
<apw> kees, thats looking pretty good, is that pending -> fix_committed 
<kees> yeah, but only for a bug in "New" state (which is defined as having a description of "Placeholder")
<apw> kees, yes thats matching the row in the matrix i recon
<kees> cool. I will update the other 6 and then continue to work on "old" stuff
<apw> you are only touching Placeholder bugs ?
<apw> ahh i see its also got a bit of the description
<kees> apw: for the moment. I have 3 sync phases. new bugs: uct->lp, old bugs uct->lp then lp->uct for the bits we discussed
<apw> if you could put in the description from the CVE when you have it, that'd rock
<apw> when there isn't if you could send a nasty-gram to erm kees, that would be good too :)
<kees> yup, that's the plan. descriptions, when they exist, will get shoved into the lp description
<kees> well, that's the problem -- these 7 CVEs doesn't have any descriptions from Mitre yet :(
<kees> I'll fill them in, but that's part of the "old" bug sync phases.
<apw> kees, yeah mitre sometimes never seems to get one
<kees> well, they do eventually, but they're over 3 months behind at this point :(
<apw> they arn't sounding like the best upstream
<kees> it is unfortunate
<sconklin> bjf, apw: everything is converted to stable-kernel-next, and that's what we should use from now on
<sconklin> sorry, kernel-stable-next
<apw> sconklin, ack
<bjf> heh, i was wondering how you went from what we said to "stable-kernel-next"
<dupondje> sforshee: About my bug for the dell_wmi unknown keys. How you'd liked the key list? With keymap or ?
<sforshee> dupondje, all I need is something like "volume up: e0f8" (or whatever the actual code is)
<sforshee> and for you to verify that it's the same code every time you hit a given key
<sforshee> for each of the keys that is giving the message
<dupondje> Ok
<dupondje> only 4 keys
<dupondje> sforshee: posted :)
<dupondje> 2 more
<sforshee> dupondje, do all of those keys work already?
<sforshee> dupondje, or at least report something on the AT keyboard input device?
<dupondje> Yea all of them work
<quentusrex> Anyone around to help triage an io kernel issue? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/815540
<ubot2> Ubuntu bug 815540 in linux "Server becomes unresponsive after spawning 16 ksoftirqd processes" [Undecided,Confirmed]
<quentusrex> Basic symptom: server becomes unresponsive(appears to be io-bound) for minutes at a time when there should be no large disk io operations. 
<quentusrex> I have two servers with nearly identical hardware(The working one has 3 Western Digital drives, and the one with the problem has two WD drives and a Seagate drive).
<quentusrex> Exact same Ubuntu installation and configuration in the bios and install. 
#ubuntu-kernel 2011-07-27
 * apw waves
 * abogani waves back
 * apw waves to smb
 * smb waves back into general directions
<apw> ppisati, try sudo apt-get install ubuntu-desktop^
 * smb wonders whether he is the only one seeing badly corrupted graphics inside a kvm with Oneiric
 * apw has no kvm installs of oneiric
 * ppisati -> rush out to get some food
<ehw> hi, guys, i'm looking to rebuild the natty backport kernel for lucid with a couple of patches; is it radically different than https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel ?
<apw> ehw not radically different, the backport kenel is in the lucid repo on the appropriate lts-backport branch
<ehw> apw: ah, ok; so if i git clone the lucid tree, it's one of the branches?
 * ehw <- gitn00b
<apw> ewh yep
<herton> apw: can you verify bug 805494? (well, it's a build issue and we could mark as ok, I think just check what code is currently in proposed, don't know...)
<ubot2> Launchpad bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,Fix committed] https://launchpad.net/bugs/805494
<tgardner> herton, I think that one is obvious IIRC
<herton> tgardner: indeed, I think I can mark he verification-done then straight away
<tgardner> herton, tag changed
<herton> ok thanks
<herton> smb, tgardner: last one needing verification, trivial also, is bug 809838
<ubot2> Launchpad bug 809838 in linux "Re-enable RODATA for virtual i386" [Medium,Fix committed] https://launchpad.net/bugs/809838
<smb> herton, That one actually should be ovious when the qa-regression suite does not fail anymore for virtual...
<herton> smb: yeah, can you ack that? (change the tag)
<smb> herton, yep
<lamont> any chance we could get 690370 fixed for oneiric?
<apw> bug #690370
<ubot2> Launchpad bug 690370 in linux-ti-omap4 "Strange out of memory on pandaboard" [Undecided,Confirmed] https://launchpad.net/bugs/690370
<apw> ppisati, ^^
<tgardner> lamont, you should hassle ppisati
 * lamont would just like a time horizon for when he can drop the ugly hack he has for $arch=armel
<lamont> since ISTR it turned out to be "usb on arm", not "panda" :(
<apw> lamont, whats the ugly hack
<lamont> vm.min_free_kbytes = 16384
<lamont> which also doesn't quite always provide enough to survive
<lamont> most of the arm builders are running with just 8192, but the image builders turned out to need, well ,more
<apw> that potential patch is utterly vile, a nice cacheline bouncer
<ppisati> lamont: last i heard, our builders were ok
<ppisati> lamont: but i could be wrong
<lamont> ppisati: because we hack around the problem
<ppisati> lamont: ah, i wasn't aware
<lamont> given that rebooting most of them involves someone physically in the data center, I'm not really inclined to test until someone tells me they've fixed the bug
<apw> lamont, i thought we now had new ones
<lamont> apw: new is relative
<apw> lamont, well ones we can remotly cycle
<lamont> *aceae are remotely powerstabbable, the others are not
<lamont> panda boards are a current ticket being worked on this week, might even get done by then, though I'
<ppisati> lamont: does it mean that we are running the builders with that hack, otherwise we experience the problem?
<lamont> m getting less confident in friday as the ready date
<ppisati> lamont: did you try ming lei patch?
<lamont> ppisati: I'm saying that when they started panicking, I was pointed at that bug as the likely cause, and setting min_free_bytes to 8192 fixed things, so we went with that as the cause and have been happy since, other than a brief period when we lit up some beaglexm image builders and discoverd that 8192 doesn't seem to be enough for them
<lamont> ppisati: only noticed the patch today.  if someone wanted to roll me a kernel to try on one of the builders, I could drop the hack there and give it a new kernel and we could see how long it takes to fall over, though at this point, I'm not aware of what build would be a good testcase
<lamont> afk for a few
<ppisati> lamont: do the builders use NFS for building? or do they have local usb disks?
 * ogasawara back in 20
<lamont> ppisati: the image builders use nfs, the non-image builders use local disk, the pandas-to-be will be devmapper with local disk over a read-only nfs
<lamont> actually, the pandas-to-be may be localdisk only, haven't decided completely yet
<tgardner> herton, do you remember what bug it was that you worked with Lamont on the 'af_unix: Only allow recv on connected seqpacket sockets.' regression ? Its in the proposed 2.6.35 stable update, so I thought I should point out to the list the possibility for regression.
<ppisati> lamont: uhm, and i guess image builders show this problem while the non-image builders don't have it (or don't show it so often)
<lamont> ppisati: it was much more repeatable (at 8192) on the image builders, than it was on the non-image builders with no hack
<ppisati> lamont: i see
<herton> tgardner: let me check here, looking
<lamont> ppisati: from that, you can infer the timeline of the hack
<ppisati> lamont: i see, ok, if i roll a new kernel with tha patch, can you test it (without the hack)?
<herton> tgardner: bug 791512
<ubot2> Launchpad bug 791512 in linux-meta "tcp connections hang in forwarding machine" [Undecided,Invalid] https://launchpad.net/bugs/791512
<ppisati> lamont: on one of the image builders i mean
<tgardner> herton, thanks
<lamont> ppisati: I believe so
<ppisati> lamont: actually the patch will just limit the numer of simultaneous skb
<ppisati> lamont: so it won't fix it
<lamont> heh
<ppisati> lamont: when you it the problem, it will start to drop pkts
<lamont> dropping packets is better than dropping the  machine
<ppisati> lamont: and i guess with NFS that would be trigger another problem
<ppisati> lamont: but does it panic?
<lamont> oh yeah.
<lamont> "trying to allocate memory on interrupt stack with no free memory" or such
<lamont> I'll take kernel panic for $200, bob.
<ppisati> i see, ok so, let's try with that patch
 * ppisati goes to compile a new natty kernel
<ppisati> lamont: natty right?
<lamont> hahaha
<lamont> maverick on those machines
<ppisati> ah ok :)
<lamont> the pandafarm will be natty
<lamont> and if #distro is willing to sign off on building lucid bits on a natty kernel (y'all factor into that answer...), then the greater-we will be happier and maybe we can get all the arm builders up to natty
<lamont> but we'll probably want to hold off on oneiric until the next LTS, and then flash forward to the LTS
 * lamont heads to town, afk for a bit
 * ppisati wonders if there's a way (zone tunable, sysctl, /sys/*, etcetc) to tweak/limit/throttle skb allocations by size/requester
<apw> ppisati, it doesn't look like it, but worth trying to find out from more expert people
<ppisati> apw: i'm pretty sure there's some kind of mechanism
<ppisati> uhm...
<apw> ppisati, i was saying at the level the code is being modded, above it there may be, i'd take my input as "don't know, you should find out"
<ppisati> yep
 * bjf -> dentist
<davmor2> ogasawara: Hey give me five to grab the netbook out the other room and I'll fire it up for you
<ogasawara> davmor2: awesome, thanks
<ppisati> lamont: http://people.canonical.com/~ppisati/lp690370/linux-image-2.6.35-903-omap4_2.6.35-903.23~throttleusbnetskb_armel.deb
<davmor2> ogasawara: sorry for the delay needed to install some missing packages to get the the desktop
<ppisati> lamont: please test it on a builder (that shows that bug) and don't forget to remove the min_free hack
<davmor2> ogasawara: kernel .5 generic has working wifi
<ogasawara> davmor2: ack, k gimme a few minutes to fire up a kernel build to start bisecting the set of patches
<davmor2> ogasawara: just trying .6 does too
<ogasawara> davmor2: eh? I thought .6 was broken for you
<davmor2> .7 doesn't
<davmor2> ogasawara: just gone throught them all
<ogasawara> davmor2: ah, thanks for clarifying
 * ogasawara restarts to bisect between the right versions
<davmor2> ogasawara: sorry for the confusion :)
<ogasawara> davmor2: so could I get you to now test http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0-rc7-oneiric/
<ogasawara> davmor2: it's the upstream v3.0-rc6 kernel which the Ubuntu 3.0.0-6.7 kernel was based on
<ogasawara> davmor2: just want to confirm that works
<ogasawara> bah, s/v3.0-rc6/v3.0-rc7/
<ogasawara> davmor2: ^^
<davmor2> give me a second
 * herton ->lunch
<davmor2> ogasawara: last package installing now man this is now a fast machine :(
<ogasawara> davmor2: heh, no worries
<davmor2> ogasawara: right 3.0.0-300rc7-generic has no wifi running
<davmor2> 0300 even
<ogasawara> davmor2: hrm, really?  well that's not what I was expecting
<ogasawara> davmor2: and you installed the header packages too?
<davmor2> ogasawara: all 3 .deb packages
<jmburgess> Hey kernel team.  I was wondering of bug 814323 should he marked as triaged. Its a known problem with the virtualbox module and I've forwarded it on upstream
<ubot2> Launchpad bug 814323 in linux "Virtualbox 4.1 (vboxdrv) Blocks Machine Suspend" [Undecided,Confirmed] https://launchpad.net/bugs/814323
<ogasawara> davmor2: hrm, k lets see if I can find a different way to bisect then.  can you try http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0-oneiric/
<davmor2> ogasawara: I'm just double checking should I be setting these up from a kernel with the wifi working? I'm assuming is shouldn't matter but as I've found out before assumption is the best policy
<davmor2> isn't
<ogasawara> davmor2: it shouldn't matter
<davmor2> ogasawara: that's what I thought, right this is the last one up and running now,   no wifi
<apw> jmburgess, possibly so yes
<ogasawara> davmor2: and you said 3.0.0-6.7 was working right
<davmor2> ogasawara: let me grab you the uname of the one that was working
<ogasawara> davmor2: cool
<davmor2> ogasawara: http://paste.ubuntu.com/653236/
<davmor2> ogasawara: if you want something other than uname -a let me know :)
<ogasawara> davmor2: nope that confirms 3.0.0-6.7
<ogasawara> davmor2: "3.0.0-6-generic #7"
<davmor2> ogasawara: that's fine then :)
<ogasawara> davmor2: K, give me a about 30min.  I'm going to rebase the patches we were carrying for -6.7 onto v3.0 and build you a kernel to retest
<davmor2> ogasawara: I'm off at 18:30 and it's 17:52, I'll happy try it tomorrow for you if you drop the link/package on the bug
<ogasawara> davmor2: sounds good, I'll post to the bug.  thanks for the testing.
<davmor2> ogasawara: no probs
<davmor2> ogasawara: while we are at it is there any other relevant info you want for 815064 or does that cover everything you guys need?
<ogasawara> bug 815064
<ubot2> Launchpad bug 815064 in linux "No driver for the Network controller: Ralink corp. Device 5390" [Undecided,Confirmed] https://launchpad.net/bugs/815064
<ogasawara> davmor2: at a quick glance, it looks like you posted everything we'd need.  I'll ping you otherwise.
<davmor2> ogasawara: cool
<davmor2> ogasawara: I tried to add everything I could think of :)
<jmburgess> apw: does importance medium sound correct? If it does ill ask someone on the bug control team to mark it as triaged 
<apw> jmburgess, i can mark it so
<jmburgess> Great thanks
<apw> jmburgess, done
<jmburgess> I think bug 816110 is ready to be marked as triaged.  He's running oneric on kernel 3.0 and has all the apport info. is there anything else I should ask of him, or is it good to be marked triaged?
<ubot2> Launchpad bug 816110 in linux "Don't work multitouch on acer 522" [Undecided,Confirmed] https://launchpad.net/bugs/816110
<apw> jmburgess, i suspect that the answer to that one is, you have an ALPS, sorry
<jmburgess> ALPS?
<apw> jmburgess, make of touchpad, wherein the the manufacturer thinks their wire protocol is super secret
<jmburgess> apw, sorry I'm new. How did you know its an alps, and does that mean this is a duplicate of bug 550625?
<ubot2> Launchpad bug 550625 in linux "Alps touchpad is recognized but synaptics clients and scrolling do not work" [Medium,Confirmed] https://launchpad.net/bugs/550625
<apw> jmburgess, i am not 100% sure as the device is matched as a ps/2 mouse, but it has an alps glide point so i am suspicious
<jmburgess> ape: gotcha...i guess ill just mark it as a duplicate then
<jmburgess> Sorry that was to apw, not ape
<apw> jmburgess, hard to know if its is really a dup or not
<apw> the other one implies it is recognised as a touchpad, which does not fit the symptoms here
<jmburgess> Oh good point.
<jmburgess> Let's see if I can find if this is a dup
<jmburgess> Oooooo looks to be related/duplicate of bug 565543
<ubot2> Launchpad bug 565543 in linux "Alps touchpad detected as ImPS/2 Generic Wheel Mouse(in VAIO E series) after the kernel upgrade" [Medium,Incomplete] https://launchpad.net/bugs/565543
<jmburgess> Is the latest dev release running kernel 3.0.0.7-generic considered upstream mainline?
<apw> jmburgess, thats an ubuntu kernel so not mainline, it has our delta on it
<BenC> amitk, apw, cking, kees, pgraner, ogasawara, tgardner: Any of you going to linuxcon?
<tgardner> BenC, none of the kernel team. kirkland will be there.
<tgardner> plumbers for you ?
<BenC> when is plumbers?
<tgardner> sep7-9, santa rosa
<BenC> I'll see, but no idea
<kirkland> BenC: howdy, long time no see :-)
<BenC> kirkland: hey, I will likely see you at linuxcon :)
<BenC> First beer is on me...jaeger bombs are on you...
<kirkland> BenC: nice, will be good to catchup
<kirkland> X-o
<BenC> hehe
<apw> bug #817187
<ubot2> Launchpad bug 817187 in linux "libvirt FTBFS on 2.6.39 and later kernels" [Undecided,Invalid] https://launchpad.net/bugs/817187
 * tgardner -> EOD
<amitk> BenC: going to plumbers, not linuxcon - jaegers are on you if you attend ;)
<kees> BenC: I'll be in santa rosa for 1 day (for the linux security summit day)
<jjohansen> rebooting
#ubuntu-kernel 2011-07-28
<quentusrex> Alright, I have been following this guide for kernel building and installation: http://blog.avirtualhome.com/2010/11/06/how-to-compile-a-ubuntu-10-10-maverick-kernel/
<quentusrex> Is there any way to build the package(or even just build the replacement kernel) faster than rebuilding everything from scratch?
<quentusrex> I'm trying to test patches to fix a problem with Seagate Barracuda 7200.12  SATA drivers, but it takes 30+ minutes between attempts currently.
<apw> quentusrex, you can patch the source, remove debian/stamps/*build* and then fakeroot binary-<flavour> will not rebuild everything
<quentusrex> thanks apw, but just to confirm that will rebuild the parts of the kernel that have changed?
<apw> quentusrex, it should yes, the packaging still occurs so its still not zippy but doesn't build every c file
 * smb waves to apw
 * apw waves to smb
<quentusrex> thanks apw. I'll give that a try. 
<quentusrex> I'm trying to track down a problem with the Seagate Barracuda 7200.12 and the ATI chipset. 
<apw> sound fun
<ohsix> quentusrex: what problem? the link keeps going down?
<quentusrex> ohsix, basically there is a load of ~3 on idle and trying to write anything above 20MB will cause the server to become io-bound and unresponsive.
<ohsix> have you looked at dmesg?
<ohsix> there's a pretty general problem with seagate drives and the link going down
<quentusrex> if I unplug the Seagate hard drive and plug in a Western Digital then everything works fine, and everything works fine if I plug in a 7200.9 Seagate drive.
<quentusrex> ohsix, I haven't see anything about the link going down in dmesg
<ohsix> post the output to a pastebin, it doesn't say "link down" there are ata errors about resets
<quentusrex> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/815540
<ubot2> Ubuntu bug 815540 in linux "Server becomes unresponsive after spawning 16 ksoftirqd processes" [Undecided,Confirmed]
<quentusrex> there is a dmesg file uploaded there. 
<quentusrex> 'reset' isn't in the log.
<ohsix> sec, there was a change not too long ago that made the resets transparent too
<ohsix> i'll have to think a bit about what i did back when i had the problem drives; they've since been replaced with other seagates that don't do it
<quentusrex> ohsix, I would appreciate it.
<ohsix> quentusrex: have you tried to track down a firmware update for the drive yet?
<quentusrex> ohsix, I started with the drives on CC46
<quentusrex> then updated to the latest which is CC49
<quentusrex> no difference.
<ohsix> ok
<ohsix> hm, you know it's been quite a long time; i remember having to disable ncq for some reason, and i'm pretty sure the link resets were it, but i can't remember if just setting the queue depth less than 31 also helped
<apw> ohsix, now that seems familiar, some drive causing reserts if you used all of the queue entries or something
<ohsix> you could try disabling ahci too; it does the same thing basically
<ohsix> then you're back to 'ole classic chipset restrictions
<ohsix> there's also something to show those resets again but i'll have to look a bit
<quentusrex> yeah, I see a check around them all for verbose. I'm back tracking it to find the config. If you find it first, let me know.
<ohsix> ok i found my emails from 2008, i'll look through them :]
<quentusrex> What feels crazy is that these are brand new drive models from Seagate. I would think they wouldn't make the same mistake again only 3 years later.
<apw> quentusrex, and i bet you are being sensible and spreading your maker to avoid systemic failure too
<quentusrex> spreading my maker?
<ohsix> they don't actually do the firmware on some of their models, it's actually pretty hard to figure out if you want to avoid stuff
<apw> buying differnet makers kit so that if say like the old death-stars they have a manufacturing fault you don't loose everything
<quentusrex> apw, aah. Yes, and I stress test every new server before it touches production.
<quentusrex> and by stress test I mean memtester for a week straight, then at least a week running boinc for rosetta@home.
<quentusrex> rosetta does well at finding incompatible or flaky drives, at least it is good at finding them for me.
<apw> so i guess +1 for it catching this bad drive, -1 for seagate for their drive
<quentusrex> apw, it's the entire model. I have 3 of the same drives from different batches. all with the exact same problem.
<ohsix> ok this is back when i had spindles lock on a bunch of seagate drives, one locked; got rma, the rma had the link down problem
<apw> quentusrex, yep, awsome
<ohsix> the ncq thing worked around it, and they had to contact an engineer to actually make a new firmware image to update the drive i had to fix it
<apw> ohsix, now that sucks, "i want the old one, oh no i don't"
<ohsix> apw: they were the enterprise series drive too
<ohsix> i had accounted for all types of failure besides then turning into a block of aluminum
<apw> probabally why you got anything other than ignored when you said it was broke
<ohsix> they use fluid dynamic bearings; they spin weld themselves :D
<ohsix> the other drive i had in the set did it within a few power on hours of the first too
<ohsix> this is what i said at the time to support: 3.AAK, nforce5 mcp55, the sata link keeps going up and down and the drive keeps resetting with controller errors, and its worse with NCQ enabled [06:01:40 PM]
<apw> ohsix, i had all of my personal data on a pair of travel-stars, they both died in the same way within a day of each other
<ohsix> they sent me 3.AAM, and they had a hard time doing it too :] but that fixed it
<apw> those were the days mind when the manufacturer could claim "oh we don't rate those drives for continuious spin"
<ohsix> but according to that message and my confusion, the problem wasn't entirely resolved with disabling ncq
<ohsix> quentusrex: i'll keep looking for a way to reenable those messages, and the patch that disabled them (cuz i explicitly remember seeing it on patchwork); i'd start the process to getting even newer firmware, since it takes a while
<apw> ohsix, the odd thing is i do recall a reduction in outstanding queue count helping for something like this
<ohsix> ya i couldn't figure out why the controller kept resetting, there was no rhyme or reason
<apw> quentusrex, cirtanly worth reducing the queue depth on the drive to see if it helps
<ohsix> it really liked to break when i was reading enough off the drive constantly, but barely enough to keep the head moving (like playing mp3s or a movie from it)
<ohsix> i tried using short and stout cables and stuff to see if that mattered, it didn't
<ohsix> it was just some firmware badness
<ohsix> oh, you can also try forcing the link speed to sata1.5
<quentusrex> I've got to crash soon. It's 1:20am here.
<ohsix> ok, you can set the link mode, and ncq at boot with libata.force=1.5Gbps,noncq
<ohsix> nohrst, nosrst, and norst controls the hiding of the different reset messages, hard, soft, and both respectively
<ohsix> so quick confirmation wrt what i think it is, is libata.force=norst, then get it to do it and check dmesg
<quentusrex> ohsix, so how do I enable them?
<quentusrex> ok
<ohsix> edit the commandline in grub before you boot, or add them to /etc/default/grub (GRUB_CMDLINE_LINUX_DEFAULT) run grub-update and reboot
<quentusrex> I'll know shortly ohsix 
<quentusrex> ohsix, do you know why it was decided to hide the ata reset messages?
<ohsix> i don't remember, that's why i'm looking for the patch again
<ohsix> they're mostly useless messages, except in this particular situation heh
<ohsix> links go down occasionally anyways, and it doesn't really hurt; but if the host is doing something that crashes the drive firmware you want to know :]
<ohsix> aha, forgot about git-blame, i can see who added the documentation
<ohsix> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=05944bdf6fadb5394710269df6770dde447b23ca
<ohsix> er, heh; going by the commit message that doesn't do what i thought it does
<ohsix> that actually disables resets alltogether
<quentusrex> ohsix, yeah, that actually made it worse. Took much longer to boot with that option.
<ohsix> right
<ohsix> i don't see anything that actually hides the messages, looks like stuff just changed
<amitk> apw: you guys sprinting before Plumbers?
 * ppisati -> out
<davmor2> ogasawara: Morning both test kernels seem to have wifi beaming out quite happily, not seen any issues, on either box hibernate, suspend etc have all brought the wifi back up and connected successfully etc
<ogasawara> davmor2: cool, so for the broadcom one, I'll put together a few more kernels so we can narrow down the regression
<davmor2> ogasawara: no probs
<ogasawara> davmor2: for the ralink, I'll apply the commit and it should hit Alpha3
<davmor2> ogasawara: nice,  I'll keep an eye on the ralink one for you over the weekend makes sure nothing drops out etc but so far seems nicely stable
 * smb wonders whether reviewing cves is not a waste of time...
<tgardner> smb, how so?
<smb> tgardner, They seem to get applied quicker than I can look at them.. :-P
<tgardner> smb, it seems straightforward to me if they are cherry-picks, and have already been applied to other master branches.
<tgardner> I did look at the backports pretty carefully
<smb> Yeah, did the same. And yes, more or less those are not very critical in the sense of having much change compared to other branches...
<smb> Just for those the question is whether I look at them or just wait whether they get applied the next hour... ;)
<tgardner> well, I'm just compulsive about clearing out my inbox first thing. you'll just have to start earlier.
<smb> tgardner, Good point. Unfortunately Andy sent them out between the end of my lunch break and your start of the day. I just need to avoid that kind of work in your mornings :)
<apw> http://www.debian.org/releases/lenny/example-preseed.txt
<ogasawara> skaet: at the rally we had a gcc discussion for the P release.  I recall you had taken notes, did they get transcribed anywhere by chance?
<ogasawara> davmor2: when you have a chance, new test kernel at http://people.canonical.com/~ogasawara/lp814882/
<ogasawara> davmor2: same info posted to the bug as well
<davmor2> ogasawara: righto I'll give it a go in a bit just doing some testing at the minute so might be an hour or so
<ogasawara> davmor2: cool, thanks
<skaet> ogasawara: have the notes, and happy to put them somewhere public - ideas/preferences?  mail/spec/wiki?
<ogasawara> skaet: wiki or spec would be good, I just wanted to have some reference I could share with some Intel folks
<skaet> ogasawara, is there a SPEC you want me to add them to?  happy to do that.
 * skaet figures there might be a few feathers ruffled if I start off a Oneiric/ToolchainPlans page.
<ogasawara> skaet: we can probably add it to https://launchpad.net/ubuntu/+spec/other-kernel-o-gcc-build-dependency as that's where the action was listed for us to get together at the rally
<ogasawara> skaet: just throw it on the whiteboard as notes from that meeting
<skaet> ogasawara, makes sense.   adding.
<ogasawara> skaet: thanks
<apw> tgardner, well if i had to guess i'd say it'd be worth adding this to the boot command line via F6: cdrom-detect/eject=false
<tgardner> apw, ack
<skaet> ogasawara, raw notes added to the spec.
<ogasawara> skaet: thanks again
 * ogasawara back in 20
<sforshee> mjg59, cking: either of you have a minute for an AML question?
<apw> ogasawara, ok i've pushed a bunch of cleanups to patches to the tip of oneiric, all from the delta-review.  i've reverted and reapplied patches where they were updated so you can see them, feel free to collapse and move them as appropriate on your next rebase
<ogasawara> apw: ack thanks
<apw> ogasawara, that represents the bulk of what i am doing for that work item so i have closed it out and made a new one for the remainder
<ogasawara> apw: cool
<apw> none of the remainder is release critical, so once i have the patches in progress i'll close that too
<ogasawara> works for me
<apw> ogasawara, i did revert some include additions which may pop an FTBS, i don't think so as none of my test builds needed them, but just in case so you know they are there ... all my reasons are on the wiki
<bdmurray> afaict bug 817213 seems fixed in oneiric
<ubot2> Launchpad bug 817213 in linux "Spaces instead of mainboard vendor name in dmesg DMI: line" [Undecided,New] https://launchpad.net/bugs/817213
<tgardner> apw, 'cdrom-detect/eject=false' seems to have worked
<apw> tgardner, awsome
<apw> something going our way
<apw> something going our way
<apw> (but apparently not mine)
<bdmurray> hey there so I was looking at https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Battery_drained_whilst_suspended_stock_reply and wanted to stop those from being reported
<bdmurray> What is the tell for your your battery drained?
<davmor2> ogasawara: sorry for the delay, the latest kernel you added has working wifi
<ogasawara> davmor2: thanks, was hopping you'd say that.  I'll kick off the next build...
 * cking-afk --> EOD
 * tgardner-afk is out early today
<ogasawara> davmor2: k, next test kernel at the same location - http://people.canonical.com/~ogasawara/lp814882/
<ogasawara> davmor2: comment also posted to the bug so that I keep track where we are
<apw> (but apparently not mine)
<quentusrex> apw, ohsix just to let you know the Seagate issue appears fixed in the 2.6.38-11.47 kernel
<apw> quentusrex, and its broken in which version ?
<quentusrex> I will try to figure out which patch resovled the issue
<quentusrex> broken as late as 2.6.38-10.46
<apw> quentusrex, what host controller do you have
<herton> does someone have any idea why we don't have linux-image-2.6.38-11-powerpc64-smp_2.6.38-11.47_ppc64.deb on repositories?
<herton> maint-getabis is complaining:
<herton> II: linux-image-2.6.38-11-powerpc64-smp_2.6.38-11.47_ppc64.deb
<herton> II: Downloading to kernel.ubuntu.com ... FAILED!
<herton> it's the only one missing
<davmor2> ogasawara: I have wifi again with that installed
<quentusrex> apw, SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
<ogasawara> davmor2: k, kicking off the next test build...
<apw> herton, it is in the launchpad librarian, so it did exist 
<davmor2> ogasawara: I'm off soon so I'll take this one from lp when I get back home from shopping and stuff possibly around 22:00bst currently 19:19 for a reference
<ogasawara> davmor2: cool, thanks
<herton> apw: hmm, maint-getabis looks at that 4 urls, none has it. strange thing as also none of them have any deb with arch=ppc64
<apw> herton, it is in universe
<apw> which i believe it should not be
<apw> change http://ports.ubuntu.com/pool/universe/l/linux/linux-image-2.6.38-11-powerpc64-smp_2.6.38-11.47_powerpc.deb
<apw> herton, you can grab it from there for your purposes i suspect
<apw> but ... i'd ask why its there, we've had a lot of stable kernels drop in the wrong hole recently
<apw> and its meant to be scripted to avoid that
<herton> apw: but this url also doesn't have the ppc64 deb (note that file it looks ends with "ppc64.deb")
<bjf> herton, jjohansen, apw, ogasawara, bug 747092
<ubot2> Launchpad bug 747092 in linux "[FUJITSU FMVNP2PL] edge scrolling does not work" [Undecided,Confirmed] https://launchpad.net/bugs/747092
<quentusrex> apw, It seems to be much better now, but not fixed.
<quentusrex> it is possible that restarting the machine after returning the command queue to 20 might have had an effect.
<quentusrex> apw, any idea why dmesg never gets written to after boot? even when there is a printk that should be printing to it.
<apw_> should work in my experience 
<quentusrex> apw, so the issue is down from 10-15 times the overhead down to about 5-10 times the overhead.
<apw_> herton: the ppc binaries should be sorted shortly
<herton> apw_: cool. I noted that previous natty releases didn't include ppc64 abi (there is no debian.master/abi/2.6.38-*/ppc64 on them)
<apw_> ignore ppc64 it is not enabled
<apw_> powerpc64 is a powerpc not ppc64 kernel
<bjf> ogasawara, sforshee, jjohansen, herton, whoever is looking at that bug, take a look at 74de8a14d8afe3d8dd009e223eea742a753314f4 in the oneiric repo
<bjf> ogasawara, sforshee, jjohansen, herton if we do the same thing but match on FMVNP2PL would that get us what we want?
<herton> bjf: it's possible, if the "Magic Sequence" is the same on Fujitsu
<ogasawara> bjf: posted an additional comment to the bug
<bjf> ogasawara, i responded to your comment
<bjf> ogasawara, i'm getting "port 22: Connection refused" for tangerine
<ogasawara> bjf: hrm, lemme try.  I've been using tyler lately
<ogasawara> bjf: I keep getting a "Permission denied, please try again." when I enter my password
<bjf> ogasawara, try "the standard password"
<ogasawara> bjf: ah, that works
<bjf> ogasawara, working for me now
 * herton -> eod (soccer)
<kamal> rtg: at your convenience... htop for tangerine?
<kamal> tgardner-afk: at your convenience... htop for tangerine?
<apw> kamal, done
<kamal> apw: ty
<kees> with pitti on vacation, who is doing kernel publications?
<quentusrex> Anyone know how to enable ahci debug in the kernel?
<Fanfare> Hi @ All! I get a kernel freeze when ever i disconnect  from LAN. How to debug? 
<bjf> kees, that's always a good question
<bjf> kees, the answer is supposed to be SpamapS, skaet, or jdstrand are all supposedly capable 
<kees> jdstrand: I think you're EOD, but I'd rather do publications before friday. any chance you can look at the pending ones?
<skaet> bjf,  I lack the right permissions on cocoplum it appears.  
<jdstrand> kees: what is needed?
<skaet> kees,  I can move to -proposed, but not -updates.
<kees> bjf: do you have it handy? I know there is at least one I saw go into "needs copy" mode a few days ago.
<bjf> kees, i'll look but i'm on rotation this cycle
<kees> bjf: I can look too, no worries
<kees> jdstrand: let me find them
<bjf> kees, it's just that i've not been tracking them
<kees> bjf: yeah. I have searches for "what needs me attention" but I don't have a "what's pending?" search handy... building
<bjf> kees, i don't see anything right now that needs copying
<kees> bjf: https://bugs.launchpad.net/kernel-sru-workflow/+bug/811215 lucid linux-lts-backport-maverick does, IIUC
<ubot2> Ubuntu bug 811215 in kernel-sru-workflow "linux-lts-backport-maverick: 2.6.35-30.56~lucid1 -proposed tracker" [Undecided,In progress]
<jdstrand> http://people.canonical.com/~ubuntu-archive/pending-sru.html shows that as having *many* bugs that haven't been confirmed
<jdstrand> and one that needs to be backed out
<kees> https://bugs.launchpad.net/kernel-sru-workflow/+bug/808934 maverick linux does too
<ubot2> Ubuntu bug 808934 in kernel-sru-workflow "linux: 2.6.35-30.56 -proposed tracker" [Undecided,In progress]
<skaet> jdstrand while you're at it, ;)  could you take a look at moving the .71 lucid kernel from -proposed to -updates https://bugs.launchpad.net/ubuntu/+source/linux/+bug/813507
<ubot2> Ubuntu bug 813507 in linux "linux: 2.6.32-33.71 -proposed tracker" [High,In progress]
<kees> https://bugs.launchpad.net/kernel-sru-workflow/+bug/813507 lucid linux too
<skaet> heh
<bjf> jdstrand, i believe most of those *many* are CVE's
<kees> so, that's 3 that are many days old
<bjf> jdstrand, oops, looking at the wrong one
<bjf> kees, that is a lts-backport
<kees> bjf: so?
<bjf> kees, nothing just making sure we are looking at the same thing
<kees> lucid linux is 6 days old (!)
<jdstrand> I'm happy to process the kernels, though I would like to verify it is ready so need to review
<kees> lucid linux-lts-backport-maverick is 2 days old
<jdstrand> I'm currently looking at http://people.canonical.com/~kernel/reports/sru-report.html
<kees> jdstrand: bugs 808934 813507 811215 all show full sign-off
<ubot2> Launchpad bug 808934 in kernel-sru-workflow "linux: 2.6.35-30.56 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/808934
<jdstrand> I don't really understand that page
<kees> jdstrand: as in, they're at the "promote" part of the workflow, iiuc
<bjf> kees, jdstrand i'm not sure the backport should go to updates before the regular maverick kernel does
<kees> jdstrand: basically https://wiki.ubuntu.com/Kernel/kernel-sru-workflow steps 16 and 17
<jdstrand> oh my gosh, there is a lot in there
<kees> bjf: sure, but they're both ready, afaict
<jdstrand> been a while since I looked
<bjf> kees, look at http://people.canonical.com/~kernel/reports/sru-report.html
<bjf> kees, looks like 805209 needs verification on maverick
<jdstrand> kees: so bug 808934 goes to security and updates?
<ubot2> Launchpad bug 808934 in kernel-sru-workflow "linux: 2.6.35-30.56 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/808934
<kees> bjf: "Verification-testing" is Fix Released
<jdstrand> bug 813507 to updates
<ubot2> Launchpad bug 813507 in linux "linux: 2.6.32-33.71 -proposed tracker" [High,In progress] https://launchpad.net/bugs/813507
<bjf> kees, i'm also unsure about 790754 w.r.t validation
<bjf> kees, meant validation
<jdstrand> and bug 811215 to security and updates?
<ubot2> Launchpad bug 811215 in kernel-sru-workflow "linux-lts-backport-maverick: 2.6.35-30.56~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/811215
<kees> bjf: oh
<kees> jdstrand: in theory, yes, but hold on a sec. I want to understand what bjf is pointing out. :)
 * jdstrand holds for one sec
<kees> bjf: where are those bugs verified in the workflow process?
<bjf> kees, i'm confused, the "Verification-testing" should be set to "Fix Released" when the bugs have all been verified
<kees> bjf: "will be reverted" was 20 days ago
<kees> bjf: yeah, I would agree.
<kees> bjf: herton set it to fix-released on the 13th, 5 days after 790754 was marked incomplete
<kees> jdstrand: lucid linux to -updates appears good to go, though
<bjf> kees, yes, and without talking to either him or sconklin, i'm not sure what to tell you
<kees> bjf: yeah, I will hold off. I just saw it sitting for a long time and then realized pitti was on vacation. :)
<bjf> kees, i'll send email to find out what's up
<kees> jdstrand: please ignore the maverick backport and the lucid linux for now. we'll get this sorted tomorrow when sconklin and/or herton are here
<kees> bjf: cool, thanks
<kees> jdstrand: sorry _maverick_ linux. lucid linux to -updates is fine
<jdstrand> kees: what do you need me to do now?
<jdstrand> (bug number)
<kees> jdstrand: 813507 appears ready for copying to -updates (and not -security)
<jdstrand> kees: 'appears ready for copying' doesn't instill as much confidence as I would hope :P
<kees> jdstrand: hah. well, the workflow process shows it ready, and sru-report seems to agree.
<jdstrand> kees: are you talking about http://people.canonical.com/~kernel/reports/sru-report.html? I don't know how to read that report
<jdstrand> well, it has enough so I can figure it out
<jdstrand> 1 bug, 588861, and jamespage confirmed it as fixed
 * jdstrand goes to copy
<kees> jdstrand: right, was just waiting for LP to cough that up.
<jdstrand> though I'm not sure why 588861 doesn't have verification tags...
 * bjf -> errand
<jdstrand> ok, copied
<kees> jdstrand: thanks!
<jdstrand> tha is a lot of steps :)
<jdstrand> (kernel-sru-workflow)
<jdstrand> I am not suggesting anything different; just suprised :)
<kees> jdstrand: it's actually pretty great; the transitions are well-defined and a bot keeps us all honest
<jdstrand> seems like it
<skaet> re jdstrand, 813507 is ready,  I've just been blocked on it going out since last Friday by not having the right permissions or getting someone not traveling who does.   Should have been pinging you yesterday.... (thanks kees - ;) )
<jdstrand> skaet: ack and done
<skaet> jdstrand: THANK YOU!  
<jdstrand> hehe
<jdstrand> sure :)
#ubuntu-kernel 2011-07-29
 * smb yawns
 * smb waves to apw and cking
<smb> cking, Network issues? You seem to be coming in a lot this morning
<cking> smb, yep, faffing around with my DNS server settings
 * apw waves
 * smb tries to talk to apw... without much success...
<apw> bah mumble neither exists nor starts at the moment, wtf
<ogasawara> davmor2: able to get the latest test kernel installed and tested?  just posted a comment to the bug.
<ogasawara> davmor2: I'm planning to upload our alpha3 kernel today, so would like to get this resolved in time if we can.
<davmor2> ogasawara: ah okay so the newer kernel might of been over riding it?   the RAlink driver has a glitch but it's really hard to get it to reproduce reliably,  every now and again it will drop out and not reconnect, disable the wifi and enable it again or flick the wifi switch off and on and it connects and works fine till it decides to drop again
<davmor2> only happened twice
<davmor2> today it hasn't dropped at all
<ogasawara> davmor2: that ralink driver is still noted as experimental, so I'm not too surprised it might still have some issue
<davmor2> ogasawara: Yeap I was just forewarning you
<davmor2> ogasawara: on the whole it's fine
<ogasawara> davmor2:  if you're maybe able to find a good reproducer, might be good to open an upstream bug
<davmor2> ogasawara: right so I've knocked some of the old test kernels off and am trying again now
<ogasawara> davmor2: cool
<davmor2> ogasawara: I will do it's trying to get it to reproduce on spec at all currently
<davmor2> ogasawara: okay so I reboot I have no wifi but is the kernel right now as it still doesn't look it http://paste.ubuntu.com/654489/
<ogasawara> davmor2: so that looks like the mainline v3.0 kernel, care to make sure that's uninstalled?
<davmor2> ogasawara: will do although I though I already had once
<davmor2> ogasawara: right purged from the system and now to try again
<ogasawara> davmor2: thanks, sorry for all the confusion
<tgardner> jjohansen, so what patches went into your test kernel at people.canonical.com/~jj/linux-image-2.6.38-11-generic_2.6.38-11.47~lp813748_amd64.deb ?
<ogasawara> tgardner, apw, bjf[afk]: wanna mumble after I'm done with the release meeting this morning?
<tgardner> ogasawara, wfm
<jjohansen> tgardner: it was the full set listed in the redhat patch, the tree was on tangerine
<jjohansen> tgardner: I can recreate
<jjohansen> just give me a few min
<tgardner> jjohansen, well, attach them to the bug report. thats about the only permanent place.
<jjohansen> tgardner: ack
<davmor2> ogasawara: finally got the right one, no wifi
<ogasawara> davmor2: ok, seems to be something in our overlayfs patches.  gonna require a few more test iterations to narrow down which one and not sure we'll be able to resolve in time for the Alpha 3 upload.
<ogasawara> davmor2: will kick off the next test build...
<davmor2> ogasawara: go for it :)
<tgardner> ogasawara, overlayfs isn't loaded automatically (I think), so how could that affect wifi ?
<ogasawara> tgardner: does seem a bit odd that it would have any affect at all
<tgardner> ogasawara, well, it could have a memory corrupter if loaded. is it getting loaded ?
<ogasawara> davmor2: ^^ can you check for the overlayfs module
<ogasawara> davmor2: can you also double check that you indeed had the following test kernel installed when you confirmed it was working?  http://people.canonical.com/~ogasawara/lp814882/good/linux-image-3.0.0-7-generic_3.0.0-7.8~lp814882v3commitf59f91_i386.deb
<davmor2> ogasawara: yeap right kernel this time it was replacing 3.0.0-7-generic in the grub menu
<apw> ogasawara, there are a couple of generic patches in the start of the overlayfs stack, if tis not working pull it
<lilstevie> Im getting this error while trying to build a kernel package: "Checking for dupe aliases in tegra...
<lilstevie> run-parts: debian/tests/check-aliases exited with return code 2"
<apw> ogasawara, though they are all vfs related iirc
<davmor2> ogasawara: how do I check for the modules is there an lsmod or something like that?
<ogasawara> davmor2: yah, do an lsmod
<davmor2> ogasawara: no overlayfs listed in lsmod
<apw> ogasawara, so why do we think its overlayfs
<ogasawara> apw: only because I built him a test kernel right up to before we applied the overlayfs bits, and it worked.  with the overlayfs bits, fails.
<ogasawara> apw: you by chance have a netbook with broadcom?
<apw> ogasawara, thats pretty conclusive
<ogasawara> bug 814882
<apw> ogasawara, yep
<ubot2> Launchpad bug 814882 in linux "BCM-sta driver stop working with the latest kernal update" [Medium,In progress] https://launchpad.net/bugs/814882
<ogasawara> apw: have you thrown the latest 3.0.0-7.8 kernel on there by chance?
<ogasawara> apw: I'd be curious if you're able to reproduce
<apw> ogasawara, if its that conclusive rip it out and give him another test kernel with it off
<ogasawara> apw: ack
<apw> as in reverted, and it that sorts him, then lets drop it for A3 and scratch head, how it could affect wirelss
<apw> i suspect its as likely a kernel layout issue as anything else
<apw>  ogasawara is BCM-sta == the wl driver ?
<tgardner> apw, I think so since he's complaining about jockey installs
<tgardner> Broadcom Corporation BCM4312
<apw> i have a 4313
<davmor2> ogasawara: is it worth me double checking the other kernels to ensure I was looking at the right one when they were working?
<apw> tgardner, can you remember which one is supported by the staging driver
<tgardner> there is some overlap, so I'm not sure I ever knew for sure.
<ogasawara> apw: can't off the top of my head
<apw> ok
<ogasawara> davmor2: yes, double check http://people.canonical.com/~ogasawara/lp814882/good/linux-image-3.0.0-7-generic_3.0.0-7.8~lp814882v3commitf59f91_i386.deb
<ogasawara> davmor2: that should work
<ogasawara> davmor2: or so you claimed
<apw> davmor2, you say the driver "uninstalled itself" and "cannot reinstall it with apt-get"
<apw> what error do you get when you try and reinstall it with apt-get
<davmor2> apw: ah pass I can find out after one sencond
<davmor2> ogasawara: sorry it look like I might of booted into the wrong kernel with that one it's not working and I've double checked it this time :)
<ogasawara> davmor2: ok, lets try to walk back through these then
<ogasawara> davmor2: retest http://people.canonical.com/~ogasawara/lp814882/good/linux-image-3.0.0-6-generic_3.0.0-6.7+lp814882v1_i386.deb
<kirkland> apw: are there instructions in the wiki for how to add a minor patch to an Ubuntu kernel and push to a PPA for building?
<lilstevie> http://pastie.org/2290069
<kirkland> apw: these aren't for me;  I need to pass them on to someone
<davmor2> apw:  bcmwl-kernel-source is already the newest version, with remove and install it does just that.  so no error just it's already there
<lilstevie> I saw that ogra had a similar issue when googling the error but following what was said after that didn't seem to work
<apw> davmor2, hang on there was a bug with dkms not rebulding dkms things which was fixed really really recently
<apw> what version of dkms do you have right now
<davmor2> apw: 2.2.0.1-0ubuntu1
<apw> davmor2, can you tell from the apt logs when it was installed for you
<davmor2> apw: it was install way back I'll check for you though
<awilkins> kirkland, I haven't so far been able to get a Kernel / PPA going
<awilkins> kirkland, I have built kernel debs locally though
<awilkins> I'm not sure that the kernel builds are integrated into Soyuz anyway ; the kernel team seem to use git and the Bazaar imports are just there to be useful
<apw> davmor2, the update is only 2 weeks old
<davmor2> apw: I have kernels 3.0.0-5 on here and I'm pretty sure there is one before that too
<davmor2> ogasawara: That one fails now I'm looking in the right place, I think I must of been using that mainline the whole time as it was the newest kernel version
<davmor2> apw: what the new version of dkms or do I have it installed?
<apw> davmor2, the version of dkms until this latest update would randomly decide that it didn't need to make external modules
<jcastro> sconklin: ok, the old forum threads have been deindexed, can you try a few queries and see if anything bad shows up in google?
<apw> davmor2, you seem to have it installed now, which is why i am interested when it became installed
<davmor2> apw: the driver worked fine in 3.0.0-6-generic then when it updated to 3.0.0-7-generic it stopped,  ogasawara has given me a newer mainline version that has the wifi working if I understand correctly
<ogasawara> davmor2: you confirmed mainline 3.0-rc7 was working, so I'd like you to retest that the final v3.0 is indeed broken as that major change between 3.0.0-6.7 and 3.0.0-7.8 is the rebase from 3.0-rc7 to 3.0 final
<ogasawara> davmor2: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0-oneiric/
<apw> davmor2, right so in each test you confirmed the running kernel version, and whether there was a wl loaded ?  yes ?
<apw> ogasawara, are you giving davmor2 different kernels with the same abi ?
<davmor2> apw: I thought I had but it seems not which is why I'm going back over it all now
<apw> and if you don't have wl, we'd want to know waht modprobe wl says too
<davmor2> apw: is it just wl for the module name if so it say "Module wl not found"
<apw> davmor2, well i'd want that confirmed too
<apw> and when we are in that situation i want to ask dkms to rebuild so we can check the build logs
<jjohansen> tgardner: attached, though I don't think all of the patches should be necessary for this particular bug, but I haven't weeded through them yet.
<tgardner> jjohansen, please keep working it to narrow down to the minimum set.
<davmor2> ogasawara: right 3.0.0-0300-generic Doesn't work, which wsa right it was the modded rc7 that did from memory
<jjohansen> tgardner: ack
<tgardner> plus, lets use the public bug. there are no real secrets here.
<apw> davmor2, ok can you look in /var/lib/dkms/bcmwl/5* and see what directories you have
<apw> do you have one called 3.0.0-0300-generic 
<apw> davmor2, and you confirmed that modprobe wl says "Module wl not found"
<davmor2> apw: /var/lib/dkms is empty bar dkms_dbversion and modprobe wl still says "Module wl not found
<davmor2> "
<apw> you have _no_ bcmwl directory even
<davmor2> apw: Nope 
<apw> davmor2, ok then i think we want to uninstall and reinstall the bcmwl-kernel-source and can you pastebin all of the output that produces
<davmor2> ls
<davmor2> apw: now there is
<davmor2> apw: http://paste.ubuntu.com/654555/
<apw> davmor2, and modprobe wl now ?
<davmor2> apw: FATAL: Erro inserting wl (/lib/modules/3.0.0-0300-generic/updates/dkms/wl.ko): Operation not permitted
<davmor2> Error even
<apw> did you do that as you or via sudo
<davmor2> apw: no that went through now D'oh
<davmor2> apw: and now I have wifi
<apw> davmor2, so now we need you to re-install the linux-image .deb for the latest release kernel which didn't work
<davmor2> apw: the one from the repo's correct?
<apw> you should find a copy of the .deb in /var/cache/apt/archives
<apw> yes the one from the repos
<apw> and again i want a pastbin of the output
<davmor2> apw: grrrr it looks like it is installing the version that I install from ogasawara rather than the version from the repo :(  let me see if I can kill that and try again
 * ogasawara back in 20
<davmor2> apw: right installed linux-generic and linux-headers-generic which grabbed 3.0.0-7-generic from the repo,  no wifi,  Fatal: Module wl not found.   http://paste.ubuntu.com/654574/ was the install and /var/lib/dkms/ still has the bcmwl folder in it
<apw> davmor2, ok whats in /var/lib/dkms/bcwml
<davmor2> apw: the bcmwl folder only lists the 3.0.0-0300-generic-i686 kernel
<apw> davmor2, what does dpkg -l | grep 3.0.0-7
<apw> say
<davmor2> apw: exact contents are 5.100.82.38+bdcom kernel-3.0.0-0300-generic-i686 for completeness
<davmor2> apw: http://paste.ubuntu.com/654579/
<apw> davmor2, ok what does "sudo /etc/kernel/postinst.d/dkms 3.0.0-7-generic /boot/vmlinuz-3.0.0-7-generic"
<apw> say
 * apw notes this is looking like a dkms issue
<davmor2> apw: doesn't say anything took ages and then went back to the command prompt
<apw> and now whats in /var/lib/dkms/bcwml 
<davmor2> apw: now the current kernel is listed
<apw> davmor2, and if you wudo modprobe wl
<apw> sudo even
<davmor2> FATAL: Error inserting wl (/lib/modules/3.0.0-7-generic/updates/dkms/wl.ko): Invalid module format
<smb> dmesg|tail 
<davmor2> smb: last line reads wl: disadrees about version of symbol module layout
<davmor2> disagrees even
<apw> davmor2, are you rebooted onto the reinstalled kernel ?
<davmor2> apw: I did
<apw> cat /proc/version_signature
<smb> and check what modinfo wl tells about version 
<davmor2> apw: http://paste.ubuntu.com/654586
<apw> davmor2, ^^ what smb said
<davmor2> smb, apw: is that another sudo one?
<apw> i suspect its fine either way
<smb> davmor2, nope that should work even without but sudo does not hurt
<davmor2> http://paste.ubuntu.com/654592/
 * ppisati officialy hates how thunderbird format emails...
<smb> The 3.0.0-0300-generic does not look right
<apw> yeah that looks like dkms used the wrong headers wtf
<apw> davmor2, could you pastebin /usr/lib/dkms/dkms_autoinstaller please
<tgardner> ppisati, how broken do you think the latest TI BSP is, e.g., the version you are holding whilst on vacation ?
<davmor2> apw: http://paste.ubuntu.com/654597/
<apw> davmor2, ok ... that has the bug i was talking about, whuch must not be releaased yet
<ogasawara> apw: what was that dkms bug #?
<apw> bug  #812979
<ubot2> Launchpad bug 812979 in dkms "Kernel modules are not built when the kernel is upgraded" [Medium,Fix committed] https://launchpad.net/bugs/812979
<apw> ok that is the upstream bug
<davmor2> apw: so that would explain it not building the package then correct, it did it's just the kernel couldn't use it,  is that the general gist?
<apw> davmor2, one sec let me see if i can find a fixed dkms
<apw> davmor2, u t
<apw> davmor2, i think if you uninstall brcml-kernel-source and reinstall it, it will fix you current kernel version
<apw> and i'll try and get a working dkms
<davmor2> apw: give me a second
<apw> davmor2, are you 32 or 64 bit
<davmor2> apw: 32
<davmor2> reinstalling works
<apw> davmor2, sound good
<davmor2> apw, ogasawara:  I'll add it as a work around incase anyone else hits it,  I don't know if you want to redirect the bug at dkms?
<apw> davmor2, ok i think that the dkms .deb here will sort you out http://people.canonical.com/~apw/lp812979-oneiric-dkms/
<ogasawara> davmor2: I'm gonna dupe your bug to the dkms one
<davmor2> apw: cool I'll give it a go and see
 * bjf -> fetching the boy
<ppisati> tgardner: well, sound is still broken
<ppisati> tgardner: and i guess we;ll get aniother update in these two weeks so...
<tgardner> ppisati, I was just thinking that there may be other improvements that could use testing. Bryan or Ricardo could always help out if it really sucks, or I could just revert the whole thing until you return.
<davmor2> ogasawara: I give up on finding a way to trigger the wifi being dropped for the RAlink driver as soon as I find one I'll let you know though :)
<ogasawara> davmor2: ack
<ogasawara> davmor2: definitely sounds like a hard to hit corner case, so I'm not going to worry about it much
 * bjf -> pediatrician 
<TREllis> any known issues booting the oneiric kernel on hp server hardware? I've opened http://bugs.launchpad.net/bugs/818177
<ubot2> Ubuntu bug 818177 in linux "HP DL380G5 does not see disks after upgrade to Oneiric" [Undecided,New]
<TREllis> not seeing the local disk afaik
<tgardner> TREllis, can you boot an oneiric CDROM ?
<TREllis> tgardner: hmmm I've some how made it recover by booting without quiet and with INIT_VERBOSE set, might be a race condition I guess
<TREllis> tgardner: can try that too yes
<tgardner> TREllis, just trying to figure out if its a grub2 issue
<TREllis> tgardner: ah ok
<TREllis> tgardner: ok, will try the cd. After a reboot, I'm back to where I was before booting but RO / and not able to see the disks
<tgardner> TREllis, are you perhaps missing a RAID driver from initrd ?
<tgardner> or firmware for it ?
<tgardner> hmm, cciss appears to be happy
<TREllis> tgardner: I was reading http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617891
<ubot2> Debian bug 617891 in linux-base "initramfs-tools: HP G6 hardware kernel boot issue > 2.6.37 cciss/hpsa" [Normal,Fixed]
<TREllis> cciss is moved to hpsa?
<tgardner> TREllis, lemme check.
<TREllis> hmm all new controllers only
<TREllis> this is g5 server, so not that new, so maybe it's pciids are still linked to the cciss one
<tgardner> you're definitely load cciss
<tgardner> loading*
<tgardner> TREllis, nope, hpsa doesn't service 103c:3234
<TREllis> ok, good to know anyway
<tgardner> better make its in cciss
<tgardner> make sure*
<tgardner> yep:        {PCI_VENDOR_ID_HP,     PCI_DEVICE_ID_HP_CISSC,     0x103C, 0x3234},
 * tgardner --> lunch
<TREllis> tgardner: hmm, dmesg seems to show that cciss loaded correctly and saw the disks 
<TREllis> anyway, enough for the day, more debugging on Monday
<TREllis> thanks tgardner 
 * jjohansen -> lunch
 * bjf is finally back
<herton> sconklin: I think bug 816148 can be set now as duplicate of 813850 (also there is the similar bug  814323 for lucid, may be they all should be in one bug with nominations)
<ubot2> Launchpad bug 816148 in linux "Sleep / Hibernate is broken, laptop just goes blank, get stuck, and only blinks numlock and capslock keys" [Undecided,Confirmed] https://launchpad.net/bugs/816148
<ubot2> Launchpad bug 814323 in linux "Virtualbox 4.1 (vboxdrv) Blocks Machine Suspend" [Medium,Triaged] https://launchpad.net/bugs/814323
<sconklin> herton: I agree. This seems to be specific to virtualbox, which loads a kernel driver. I'm not sure whether it's ABI skew or some other problem, but it seems to be related, in multiple series
 * herton -> eow
 * bjf notices lots of new bugs today
<jjohansen> rebooting
#ubuntu-kernel 2011-07-30
<GrueMaster> Can someone here tell me how to build the af_net module in the linux-ti-omap4-3.0.0 3.0.0-1200-omap4 kernel without rebuilding the entire kernel?  I have the headers, build-essential, and the kernel source.
<mdeslaur> I'm pretty convinced natty kernel in -proposed has a regression: bug 814325
<ubot2> Launchpad bug 814325 in linux "fuzzy and corrupted display with update in natty-proposed" [High,Triaged] https://launchpad.net/bugs/814325
<ohsix> hm i get panics during resume after mem sleep, with the stack showing acpi calls to enter sleep, guess it's back to -9 again
#ubuntu-kernel 2011-07-31
<contsa> Hi, I am trying to port a driver to 2.6.38. My problem is with recent changes on the USB stack. Anyone who can help me?
<contsa> usb_autopm_get_interface returns -EAGAIN . Why?
#ubuntu-kernel 2012-07-23
<ppisati> moin
<smb> morning
 * smb enjoys non-charcoaled coffee...
<jk-> moving up in the world, hey?
 * ppisati actually likes the American coffee...
<smb> ppisati, pervert! ;)
<ppisati> yes i am :)
<smb> jk-, More "right"
<jk-> next it'll be non-charcoaled charcoal
<ppisati> rsync after a travel takes forever...
<smb> jk-, Hm, I wonder whether that would work so well on the next barbecue...
<smb> ppisati, Was ok for me, just the full backup that followed still runs...
 * smb wonders whether Bryan will make it back...
<ppisati> seems Bryan has *a lot* of luck with airplanes lately... :)
<ppisati> i know these words will condemn me to God knows what for *my* next travel anyway...
<smb> ppisati, Probably. :) But yeah, birds, sick people... He works hard to become the next Colin... ;)
<ppisati> "No space left on device"
<ppisati> ARGHHHHHHHHHHHHHHHHHHHHH
<RAOF> btrfs, or *actually* running out of space? :P
<ppisati> the second one
<smb> ppisati, You should not have downloaded so much p... err data... ;-P
<jibel> is there a know issue with resume from suspend with kernel 3.5.0-5 ?
<smb> jibel, I think we heard the one or the other curse a bit about it recently... 
<jibel> smb, should I file a bug or it's on the team's radar already ?
<smb> jibel, A bug report in general would be good but maybe you can wait until apw gets conscious and ask him whether he already knows of one filed.
<jibel> smb, ack, will do as soon as I can bring down my machine
<apw> jibel, i don't know of a specific bug report as yet.  cirtainly its affecting my travel laptop as well
<apw> jibel, would "black screen on resume machine may be alive unsure" describe what you are seeing?
<apw> thats what i am seeing about 3-4 resumes on -5.5, -4.4 was ok
<jibel> apw, yes, it describes what I'm seeing.
<jibel> and no reaction from keyboard e.g caps lock led
<apw> jibel ok i have filed bug #1027828
<ubot2> Launchpad bug 1027828 in linux "[Quantal] black screen on resume on 3.5.0-5.5 (regression from 3.5.0-4.4)" [Undecided,New] https://launchpad.net/bugs/1027828
<jibel> apw, confirmed, thanks
 * apw seems to be able to hit it all the time, so hopefully we can find it pretty quick
<apw>     net: dont use __netdev_alloc_skb for bounce buffer
<apw> smb, i see your net thing made it in for v3.5
<smb> apw, yep
<smb> apw, Just the scheduler thing still not pulled for right now
 * apw gets building some test kernels, why does resync home take soooo long
 * smb found it to be relatively quick... starts wondering whether all went back...
 * apw was more thining the mental sync back :)
<smb> ah
 * smb probably is not back then
<amitk> apw: I see those black screens on suspend too, with the latest from X-swat PPA
<amitk> on precise
<apw> amitk, what kernel is in there?
<apw> my issue is definatly a regression -4.4 -> -5.5
<amitk> apw: 3.5.0-5
<apw> amitk, ok thats fine (and likely expected) then
 * apw has his suspicio
 * apw has his suspicions about a s/r fix that went in there
<amitk> apw: so the quantal kernel on precise isn't really the latest quantal kernel? (sorry not running quantal yet)
<apw> amitk, no it is the latest and thats where i am seeing this regression too
<amitk> apw: the kernel makes resumes a _lot_ faster on macbook pro, when it does work
<apw> amitk, interesting
<cking> yawn
<apw> cking, morning
 * cking notes that jet lag sucks
<apw> cking, indeed so
<brendand> cking, the fwts cpu_scaling test tests all the frequency governors, right?
<cking> brendand, which specific test are you referring to?
<cking> cpufreq?
<brendand> cking, yeah - cpufreq would be the name of the test in fwts
<cking> brendand, it basically figures out the set of CPU freqs available and steps through each one on each CPU. It does NOT test the different governors
<brendand> cking, thanks
 * henrix is out for ~30mins (errands...)
<apw> jibel, ok the latest 3.5 based kernel no longer reproduces the s/r hang for me, could you try the kernel at this url and see if it works for you too pls: http://people.canonical.com/~apw/lp1027828-quantal/
<apw> (remember you need an -extra package too)
<jjohansen> apw: haven't tried your kernel yet, but I built a 3.5 vanilla end of last week, and it fixed the s/r hangs for /me
<apw> jjohansen, then i suspect mine will too
<jjohansen> apw: yeah, I expect it will, I will test it in a bit
<ogasawara> apw: sounds like we should squeeze in an upload for Alpha3
<hggdh> please look at bug 1027524 - failure on QRT tests on omap-hf
<ubot2> Launchpad bug 1027524 in linux-ti-omap4 "QRT failed on test_072_config_debug_rodata and test_072_strict_devmem" [Undecided,New] https://launchpad.net/bugs/1027524
<apw> ogasawara, yeah for me its a bit improvement over the -rc7 kernel
<apw> if we can persuade jjohansen to test soonest then we can get the show on the road
<ogasawara> apw: I've kick off some build tests in the mean time
<apw> ogasawara, also i have pushed a 'tim did the rebase in on top'
<ogasawara> apw: yep saw that, thanks
<apw> ogasawara, if this does fix it for jjohansen as well then we should add that bug number to the rebase commit
<ogasawara> apw: ack
<apw> jibel, did you get to test that kernel at all?  we would like to get some confirmations to justify an upload
<ogasawara> apw: I am a little worried about the config vomit and firmware bits tim shoved in, so it would be good to get a little extra testing all around.
<jibel> apw, oh, forgot to resume the mac, doing now
<jibel> apw, it works
<jibel> apw, any other verification you'd like me to do on this machine ?
<apw> ogasawara, yeah am somewhat concerned about it all but if you are doing a bunch of config you want people to have tested after it
<apw> jibel, well i found the issue was one in a few, so if you could do like 5 or so s/r's and just check
<apw> jibel, i did 10 and seemed ok for me
<jibel> ack
<apw> jibel, other than that playing with it a little to see if its generally not pants
<apw> smb, cking, if you have spare machines getting some testing on the kernels in http://people.canonical.com/~apw/lp1027828-quantal/ which is basically what ogasawara would upload
<cking> apw, testing anything in particular?
<ogasawara> apw: got any arm builds for ppisati?  If not, mine should finish shortly.
<smb> apw, I can get it into the acer relatively quickly (though it would be quite the same as yours)
<smb> cking, I guess supend/resume
<apw> cking, just as wide a set of "touch tests" machines wide as we can
<smb> Not sure what is on the dell right now... lets see
<apw> cking, as this has our config review hackery on top of it
<cking> apw, ack
<apw> ogasawara, no not done arm builds
<ppisati> ogasawara: done this morning all arm builds
<ppisati> ogasawara: i'm testing omap4 and is ok
<ppisati> ogasawara: don't know about omap3
<ppisati> ogasawara: asked ogra to give it a sping
<ppisati> sping
<ppisati> grr
<ppisati> sping
<ppisati> ARGH!
<ppisati> spin!
<ogasawara> hehe
<ogasawara> ppisati: thanks :)
 * ogra_ spings 
<smb> ogra_, maybe spring? :)
 * cking thinks ppisati is suffering from jet lag
<apw> cking, its hard to imagine anyone not, other than ogasawara of course
<apw> though she will be kai-lagged
<ogasawara> apw: heh indeed, I think I'll go refresh my cup of coffee
 * apw will be offline for a couple of hours, watching the torch
<jibel> apw, resume failed at 7th try, but differently. Screen is white instead of black and the machine is alive. Likely an issue with screenlock or compiz, it looks like a stacking issue.
<cking> apw, did 30 suspend/resumes OK on Lenovo x220i and a Ivybridge Intel SDP laptop,  more results to come later
<vanhoof> cking: on the new one?
<vanhoof> cking: new sdp? :)
<vanhoof> cking: if so, \o/
<vanhoof> ;)
 * ogasawara back in 20
<skaet> ogasawara, apw - any ETA on when we'll get the suspend/resume kernel fix uploaded?     Anything else on the horizon kernel wise for A3?
<pgraner> apw, any clue on this one? bug 1028004
<ubot2> Launchpad bug 1028004 in linux "MMC Card Reader not working" [Undecided,New] https://launchpad.net/bugs/1028004
<ogasawara> skaet: just waiting on a powerpc test build and then I plan to upload
<ogasawara> skaet: probably another 2-3hrs.
<cking> apw, that kernel works on 30 s3 tests on a Dell 6400 and Atom based HP 210-1000 too
<skaet> thanks ogasawara 
<ogasawara> skaet: just fyi, this upload will pull us up to v3.5 final as well
<skaet> ogasawara,  will we need a d-i update then as well?
<ogasawara> skaet: yes, it is an ABI bump
<ogasawara> skaet: I'm going to upload it to quantal-proposed, so you guys can ultimately make the call if you want to pull it in for A3
<bjf> ppisati: can you look at bug 1027524?
<ubot2> Launchpad bug 1027524 in linux-ti-omap4 "QRT failed on test_072_config_debug_rodata and test_072_strict_devmem" [Undecided,New] https://launchpad.net/bugs/1027524
<ppisati> bjf: ack
 * ppisati -> gym
<jjohansen> apw: so it didn't work for /me. It fixed the odd time out pause at the boot screen but the machine never came back from suspend. I tested it twice but have to admit I only waited a few minutes
<cking> jjohansen, wait to see if it comes back after 300+ seconds (~5 + mins)
<jjohansen> cking: I will give it another try in a minute, point being it didn't make the odd pause after resume go away for /me. Wanted to let apw know asap as they where considering it for and upload
<cking> ack
<infinity> bjf: https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/1021084 has been stalled for a week.  Is cert testing not something that actually happens for linux-ec2?
<ubot2> Ubuntu bug 1021084 in linux-ec2 "linux-ec2: 2.6.32-346.51 -proposed tracker" [Medium,In progress]
<cking> apw, 30 more S3 tests passed on an AMD based Dell laptop and a UEFI Intel SDK box
<bjf> infinity: looking
<bjf> infinity: i didn't think we did cert testing
<bjf> infinity: of ec2
<bjf> infinity: marking it invalid
<infinity> bjf: That would unstick it, yeah.  Thanks. :)
 * henrix wonders why i didn't realised the -ec2 was still stuck
<smb> cking, Hm, seems the aspire one stuck itself on some s3 cycle... Now that not necessarily means the kernel is bad...
<bjf> henrix: i don't know if it is smart enought to detect that something is 'confirmed' for too long
<cking> smb, that just means fwts s3 is good
<smb> cking, And this netbook quite broken... :)
<cking> smb, I'm doing a 32 bit install on a HPMini210 to see how well 32 bit works
<henrix> bjf: well, at least we could detect something failed the 3 weeks cycle and fire an alarm
<bjf> henrix: agreed
<infinity> henrix: Or, you could rely on third parties to tell you! ;)
<henrix> infinity: heh, right :)
<smb> cking, Btw, I am sorry to report that fwts is not foolproof. It allowed the fool that is me to specify the --s3-multiple after the s3 argument without telling me that I am stupid... ;)
<cking> ah, yeah, that's a problem indeed
<jjohansen> cking, apw: test kernel didn't come back from suspend even after 15min
<smb> cking, Oh well, one that sits in front of the screen.
<jjohansen> apw: however the 3.5 vanilla that I tested earlier didn't either when I retested it
 * henrix reboots
<apw> jjohansen, ok so i am going to call you an outlier, i think that is another issue
<jjohansen> apw: yeah it seems so, I'll keep poking at it
<smb> apw, My Acer also seems to suffer of something else. It failed the fwts s3 tests after 7 and 12 repeats but with a black screen, the dell was ok 
<cking> apw, my HPMini210 in amd64 and i386 can do S3 x 30 successfuly
<ogasawara> apw: still want me to shove 1027828 in the changelog to get autoclosed?
<bjf> cking: bug 1028111
<ubot2> Launchpad bug 1028111 in linux "ecryptfs tests fail on Lucid" [Undecided,New] https://launchpad.net/bugs/1028111
<bjf> cking: bug 1028112
<ubot2> Launchpad bug 1028112 in linux "kernel SRU: ecryptfs tests fail on Natty" [Undecided,New] https://launchpad.net/bugs/1028112
<cking> bjf, ack, will look at that first thing tomorrow, probably a test failure rather than a kernel bug, but I will poke it tomorrow
<bjf> cking: thanks
 * smb -> eod
 * cking -> eod too
<apw> ogasawara, i'd say yes.  i say my problem is fixed
<ogasawara> apw: cool, I'd had the same train of thought so I shoved it in and uploaded
<apw> ogasawara, excellent.  clearly we have other issues, but those are bad
#ubuntu-kernel 2012-07-24
 * infinity likes it when http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html is empty.
<infinity> bjf[afk]: No more SRUs.  Ever.  Thanks.
<bjf> infinity: So let it be written, so let it be done
<infinity> \o/
<ppisati> moin
<smb> ppisati, morning
<ppisati> guys, do you know where i can get the "qrt-test-kernel"?
<ppisati> (sleeping with airco turned on was such a bad idea...)
<cking> smb, http://www.amazon.co.uk/64GB-KingSpec-50-pin-Solid-State/dp/B0036YWAVY
<ogra_> ppisati, gah, just trying an omap netboot install, seems we're missing the NIC driver udeb 
<ppisati> ogra_: omap3 or omap4?
<ogra_> omap ... so 3
<ogra_> i havent tried omap4 yet ..Ã¶ just trying to get an install on the beagle to test your kernel atm
<ppisati> k
 * ppisati wonders: didn't we compile it in?
<ogra_> well, i didnt see a NIC at all
<ppisati> ah, so it's the previous kernel (the one in master) not the one in master-next
<ppisati> ok
<ppisati> do you have a console?
<ppisati> dmesg | grep smsc
<ppisati> it'
<ppisati> s a module
<ppisati> lsmod 
<ppisati> and see if it's there
<ppisati> ppisati@tangerine:~/ubuntu-quantal$ ls -la debian/nic-usb-modules-3.5.0-2-omap-di/lib/modules/3.5.0-2-omap/kernel/drivers/net/usb/*sms*
<ppisati> -rw-r--r-- 1 ppisati ppisati 24120 Jun 26 12:06 debian/nic-usb-modules-3.5.0-2-omap-di/lib/modules/3.5.0-2-omap/kernel/drivers/net/usb/smsc95xx.ko
<ppisati> it's there
<ppisati> and it's present even in the soon to be uploaded:
<ppisati> ppisati@tangerine:~/ubuntu-quantal$ ls -la debian/nic-usb-modules-3.5.0-6-omap-di/lib/modules/3.5.0-6-omap/kernel/drivers/net/usb/*sms*
<ppisati> -rw-r--r-- 1 ppisati ppisati 24112 Jul 23 13:33 debian/nic-usb-modules-3.5.0-6-omap-di/lib/modules/3.5.0-6-omap/kernel/drivers/net/usb/smsc95xx.ko
<ogra_> no lsmod on netinst :)
<ppisati> -rw-r--r-- 1 ppisati ppisati 283372 Jul 23 13:38 ../nic-shared-modules-3.5.0-6-omap-di_3.5.0-6.6~next_armhf.udeb
<ogra_> cat /proc/modules ;)
<ppisati> right
<ogra_> but i'm already installing live atm
<ppisati> ah k
<ogra_> will come back to netinst 
<ppisati> ack
<ogra_> live is fine, it just seems to be missing in the debian-installer based setup (i.e. udeb)
<ppisati> uhm
<cooloney_> ppisati: hey, man.
<cooloney_> ppisati: did you try the wifi on my new panda ES in Portland?
<ppisati> cooloney_: nope
<ppisati> cooloney_: mine works here on my es here
<cooloney_> ppisati: hmmm. i can't connect to my 2 APs but my old Panda does
<cooloney_> ppisati: probably i have to use wired connection
<ppisati> cooloney_: i'm connected via both wired and wifi
<ppisati> flag@panda:~$ ifconfig wlan0 | grep inet inet addr:192.168.2.201  Bcast:192.168.2.255  Mask:255.255.255.0 inet6 addr: fe80::dcad:beff:feef:0/64 Scope:Link
<ppisati> ops
<ppisati> http://paste.ubuntu.com/1107932/
<ppisati> cooloney_: ^
<ppisati> i'm using the network manager
<cooloney_> ppisati: great, thanks flag
<cooloney_> i will try again
<ppisati> and i can tear down eth0
<ppisati> and my network keeps working
<ppisati> http://paste.ubuntu.com/1107934/
<ppisati> cooloney_: ^^
 * ppisati has just noticed that we don't install traceroute by default!!!
<ppisati> tcpdump is there but not traceroute
<ogra_> ppisati, since liker 5 releases ...
<ogra_> use tracepath ;)
<cooloney_> ogra_: a quick question, do you know what's the difference between ubuntu-server daily image http://cdimage.ubuntu.com/ubuntu-server/daily/current/ and preinstall image http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/
<ogra_> yes, preinstalled doesnt build atm :)
<ogra_> and will soon be dropped completely for all builds apart ac100
<cooloney_> ogra_: yeah, it's about 1 month ago.
<cooloney_> ogra_: so can i just download the daily image and dd it to SD for installation?
<ogra_> yes
<cooloney_> ogra_: awesome, thx
<ogra_> there is also a boot.scr-serial on the server image now
<ogra_> it defaults to framebuffer as x86 does but you can just cp boot.scr-server boot.scr to get a serial installation
<ogra_> (right after dd'ing)
<cooloney_> ogra_: ok, got it. will try 
<ppisati> "everytime you use something different from traceroute, Van Jacobson kills a kitten"
 * ppisati -> out for lunch
 * henrix is out for lunch too
<apw> ogasawara, i assume the plan is for -6.6 to be our A3 kernel
<ogasawara> apw: yes, that's my intentions
<ppisati> hggdh: when you are awake, give me an update on bug1027524
<hggdh> ppisati: I am awake
<hggdh> ppisati: all tests come from git://kernel.ubuntu.com/ubuntu/kernel-testing
<hggdh> ppisati: the QRT home is lp:qa-regression-testing (bzr). I understand the kernel-testing grabs from there
<hggdh> ppisati: you can branch the QRT, and then run (from ./scripts) 'make-test-tarball' to select a specific test. In our case, it is 'kernel-test-security'
<hggdh> then copy the tarball to the system, untar it, and run as 'sudo ./test-kernel-security.py -v'
<ppisati> ah easy, why i didn't figure it out by myself...
<rtg> henrix, how about a pull request for the leap second fixes ?
<henrix> rtg: ok, i'll do that
<hggdh> ppisati: I also pinged jjohansen on this bug
<apw> bug #1027524
<ubot2> Launchpad bug 1027524 in linux-ti-omap4 "QRT failed on test_072_config_debug_rodata and test_072_strict_devmem" [Undecided,New] https://launchpad.net/bugs/1027524
<henrix> rtg: pull request sent
<rtg> henrix, ack
<apw> yay filebug has stopped working ...
 * cking needs more coffee
 * josepht hands cking coffee
 * ogasawara back in 20
<cking> bah, jetlag is a brain killer
<ppisati> hggdh: /home/flag/canonical/qa-regression-testing/scripts
<ppisati> hggdh: [flag@newluxor scripts]$ ./make-test-tarball 
<ppisati> hggdh: make-test-tarball <test script>
<ppisati> hggdh: ls *kernel-test-security*
<ppisati> hggdh: ls: cannot access *kernel-test-security*: No such file or directory
<ppisati> hggdh: the correct instructions are:
<ppisati> hggdh: [flag@newluxor scripts]$ ./make-test-tarball kernel-security/mem
<ppisati> and it says:
<ppisati> Copying: mem
<ppisati> now i only have to figure out what "Copying: mem" does...
<herton> ppisati, not sure if it helps or what problem you're getting now, or if you solved already, but our autotest clone has a "snapshot-qrt" script, that does the tarball in a bit of different way
<herton> ppisati, http://kernel.ubuntu.com/git?p=ubuntu/autotest.git;a=tree;f=client/tests/qrt;h=f21db82b572fcd5be43f924c286e1b293ec30f34;hb=HEAD
<hggdh> ppisati: [cerdea-aws]cerdea@xango3:/build/buildd/qa-regression-testing/scripts$ ./make-test-tarball test-kernel-security.py 
<hggdh> Copying: test-kernel-security.py
<hggdh> Copying: testlib.py
<hggdh> Copying: install-packages
<hggdh> Copying: kernel-security
<hggdh> Skipping 'private/qrt/kernel_security.py' (couldn't find 'private')
<hggdh> Test files: /tmp/qrt-test-kernel-security.tar.gz
<hggdh> To run, copy the tarball somewhere, then do:
<hggdh> $ tar -zxf qrt-test-kernel-security.tar.gz
<hggdh> $ cd ./qrt-test-kernel-security
<hggdh> $ sudo ./install-packages test-kernel-security.py
<hggdh> $ ./test-kernel-security.py -v
<hggdh> [cerdea-aws]cerdea@xango3:/build/buildd/qa-regression-testing/scripts$ 
<hggdh> ppisati: I for got the ".py" in the test name
<ppisati> hggdh: ok, let me retry
<joshhunt_> not sure if this is the proper place, but i got an email yesterday for usn-1515-1, but www.ubuntu.com/usn and the corresponding rss feed does not show said USN.
<ogasawara> **
<ogasawara> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<ogasawara> **
<joshhunt_> is it just that the feed was note updated?
<joshhunt_> s/note/not
<jjohansen> hggdh: you did?
<hggdh> jjohansen: I did what?
 * hggdh is operating in single buffer mode today
<jjohansen> hggdh: sorry reading backscroll, pinged me on bug #1027524
<ubot2> Launchpad bug 1027524 in linux-ti-omap4 "QRT failed on test_072_config_debug_rodata and test_072_strict_devmem" [Undecided,New] https://launchpad.net/bugs/1027524
<hggdh> jjohansen: yes, there was a Q on the error from ppisati 
<jjohansen> hggdh: so what is the question?
<hggdh> jjohansen: comment # 3: test_072_config_debug_rodata (__main__.KernelSecurityTest)
<hggdh> CONFIG_DEBUG_RODATA enabled ... (skipped: only x86) FAIL
<hggdh> this is clearly not arm related
<jjohansen> hggdh: okay, odd that it would report that its skipping and FAIL
<hggdh> yup
<ppisati> hggdh: check the /dev/mem stuff too, i bet it doesn't find the correct headers and goes belly up
 * cking --> EOD
<hggdh> ppisati: will do
 * henrix --> EOD
<smb>  /me -> EOD
 * ppisati -> EOD
 * rtg -> lunch
<lehjr> is there any chance of getting this fixed before quantal ships? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1022351
<ubot2> Ubuntu bug 1022351 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000000000000080" [Medium,Fix released]
<ogasawara> lehjr: I can take a look to make sure it gets applied for Quantal.  It probably won't make the Alpha-3 release, but I should be reasonable for it to be applied before it officially releases in Oct.
<ogasawara> lehjr: I'll try and throw together a test kernel for you too to use in the interim
<lehjr> thank you, very much appreciated
<Chlorek> hi dudes
<Chlorek> I'm looking for ubuntu kernel sources, with aufs etc.
<Chlorek> but patched for grsec
<Chlorek> do you have any?
 * rtg -> EOD
<bjf> tyhicks: bug 994247 i am hitting this on latest Precise
<ubot2> Launchpad bug 994247 in ecryptfs "BUG() when opened miscdev fd's are used after being inherited/passed" [Medium,Fix released] https://launchpad.net/bugs/994247
<bjf> tyhicks: very repeatable running the lp-994247 test in ecryptfs tests
<herton> bjf, I saw today that a fix for it is coming through 3.2.24 proposed stable
<herton> bjf, "eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files"
<bjf> herton, thanks
<herton> bjf, on gomeisa in my home dir, there are built kernels with it, but it's just the upstream kernel (build/stable-builds/3.2.24), if you want to test
<herton> just the version of the packages are misleading, they are 3.2.23, but in fact they contain the proposed 3.2.24 patches :P
 * herton -> eod
<lehjr> ogasawara, Thanks for the kernel, I'm installing it now but it's giving errors during install 
<lehjr> bad return status for module build on kernel: 3.5.0-6-generic (x86_64)
<lehjr> brb...
#ubuntu-kernel 2012-07-25
<lehjr> ogasawara, checked that kernel on a quantal install and seems good, I don't think it liked my fglrx driver on mint, but that's a driver issue, not a kernel issue
<ppisati> moin
<smb> morning
 * ppisati -> back in 20mins
 * apw giggles
 * smb slaps apw
 * cking --> popping out for a mo
 * ppisati is already hungry...
<ogra_> ppisati, bug 746137, how hard do you think would it be to have the suggested changes from comment 16 in the kernel for a test ?
<ubot2> Launchpad bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released] https://launchpad.net/bugs/746137
<ppisati> ogra_: creating the patch is easy, but i doubt it'll fix any real problem
<ppisati> ogra_: omap3 or omap4?
<ogra_> ppisati, well, plaing around with omap4 is probably less intrusive (since you dont need to hack around in the mainline tree)
<ogra_> up to you, hqappy to test it on either platform
<ogra_> omap3 exposes it easier though since the ram is less
<ppisati> i'm in the middle of the tilt porting
<ppisati> when i cut a working new kernel
<ppisati> i'll create the patch
<ppisati> someone suggested the rx200 commit upstream
<ppisati> but i can't find that comment in that bug report
<ppisati> do you remember where it is?
<ogra_> no, but ask marvin24, he was the one suggesting the fix to me 
<ppisati> ack
<ogra_> i suppose he was also the one sending it upstream
<ppisati> when i've a bit of time i'll comment on that bug too
<ogra_> (he is usually very german^Wstrict with upstreaming)
<ppisati> ogra_: just pinged him
<ogra_> great
<henrix> apw: when you have some time, could you take a look at my oneiric lts git trees?
<henrix> apw: ubuntu-lucid and ubuntu-lucid-meta, branches lts-backport-oneiric
<apw> henrix, ack
<henrix> apw: thanks
 * henrix goes grab some food
<apw> henrix, reviewed and pushed
<henrix> apw: great, thanks!
<rtg> ayan, ppisati, jjohansen, henrix: rebooting tangerine for kernel update
<ayan> rtg: okay.
<henrix> apw: i've uploaded packages for signing into zinc
<rtg> cking, rebooting gomeisa for kernel update
<cking> ok
 * cking logs off
 * henrix is out for ~20mins
 * apw giggles again
 * amitk know what the outcome will be this time :)
<amitk> *knows
<amitk> 14:27  * apw giggles
<amitk> 14:39  * smb slaps apw
<smb> amitk, you are welcome to do it yourself. :)
<amitk> smb: too many in one day might cause damage and cause you more work ;)
<infinity> apw: What's with the giggling?
<apw> infinity, 20m ... obviously
<smb> infinity, And apw's dirty imagination
<infinity> apw: Oh, heh, I'm too tired to go looking for context. :P
<infinity> apw: IT WAS FOUR WHOLE LINES UP.
<apw> infinity, was that yesterday?  i lost some context yesterday due to bip fookage
<smb> infinity, The context need even more than just 4 lines
<infinity> smb: I've been filled in on the rest of the context. ;)
<smb> infinity, :) I bet
<ppetraki> I think I've hit a btrfs bug: https://pastebin.canonical.com/70912/
<ppetraki> df says I have plenty of free space but when things like apt-get upgrade start to run, it fails with have no free space
<ppetraki> \/home is a subvolume that the precise installer created, perhaps \/ and \ /home are being double counted?
<apw> ppetraki, cking is likely your best bet for knowledge, but i do recall that freespace in btrfs is basically random and useless
<apw> ppetraki, another example why it is so not ready for use
 * smb believes to recall the same... 
<ppetraki> apw, sigh... I saw something similar a couple weeks ago when using a chroot but thought it was chroot related.
<ppetraki> well, it won't get better if we don't dogfood it :)
<smb> I was wondering whether "df -i" is sensible for btrfs. That was another factor at least on ext4
<cking> ppetraki, the free space is a bit "off" in btrfs
<cking> use btrfs fi df
<cking> ppetraki, see https://btrfs.wiki.kernel.org/index.php/FAQ
<ppetraki> yeah, I've been reading that, what isn't clear though is that if their df mechanism is integrated into the system df?
<cking> ppetraki, nope, df on btrfs seems like fiction
<cking> urgh, who changed the libreoffice splash screen? it's way ugly
<ppetraki> sigh... will try disabling cow and run balance, good thing my backups are current
<diget> hi
 * ppisati notes it *almost* compiles again...
<ppisati> and with that said, calls it a day
 * ppisati -> EOD
<hyperair> hi. does anyone have overlayfs working for v3.5?
<hyperair> i just looked at the v3.5 packages in the kernel-ppa, but it looks like overlayfs is missing frmo there.
 * ogasawara back in 20
<rtg> bjf, dput -uf ppa:canonical-kernel-team/ppa *.changes
<bjf> rtg, look at the bottom of: https://wiki.ubuntu.com/Kernel/StableReleaseCadence
<henrix> rtg: i usually just do: dput -u kernelteam:lucid <pkg>.changes
<rtg> bjf, huh. maybe we should change the directions that are on the PPA page
<henrix> rtg: but i have the .dput.conf with the ppa configuration
<rtg> bjf, henrix: so, I think the commit log messages in 'ubuntu-lucid-meta ports ' are difficult to distinguish from master if we are using them to create tags (which I normally do). For example, the most recent ports branch commit is Ubuntu-2.6.32.42.34, whereas master is Ubuntu-2.6.32.42.49. You cannot quickly pull a tag and know which branch it references.
<rtg> hmm, I see that someone has been creating tags that don't match the commit, e.g., ports-Ubuntu-2.6.32.41.33
<skaet> ogasawara,  rtg -  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1027851 is there a workaround?  
<ubot2> Ubuntu bug 1027851 in linux "Quantal desktop installation on a vm hung on reboot." [High,Confirmed]
<rtg> skaet, hold down the red button until everything is quiet.
<skaet> rtg, ack
<rtg> skaet, ok, there were some suspend/resume fixes that I think affected shutdown.
<rtg> they would be in -6
<rtg> skaet, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1027851/comments/4
<ubot2> Ubuntu bug 1027851 in linux "Quantal desktop installation on a vm hung on reboot." [High,Confirmed]
<henrix> rtg: hmm... ok
<henrix> rtg: so, from the history, it looks like the ports tree follows a different logic: tag is different from commit
<henrix> herton: ^ is this correct?
<herton> yes, that's what being done, putting a 'ports-' prefix to the tag
<henrix> rtg: and if that's true, my last tag *is not* correct: i tagged with Ubuntu-2.6.32.42.34 instead of ports-Ubuntu-2.6.32.42.34
<herton> as it's a branch on the repo, it could potentially clash with tags from master for example
<herton> so I think that's why it's done this way
<rtg> henrix, I'm generating my own tags after a fetch, so we're OK.
<brendand> cking, this problem : FAILED [HIGH] DMIInvalidHardwareEntry: Test 1, Unmatched Chassis Type SMBIOS
<brendand> cking, is it generic or would it need to be fixed on each system affected?
<brendand> cking, or was that something that was taken care of in FWTS?
<henrix> rtg: ok, i meant: Ubuntu-2.6.32.42.49 instead of port-Ubuntu-2.6.32.42.49
<henrix> s/port-Ubuntu-2.6.32.42.49/ports-Ubuntu-2.6.32.42.49
<cking> brendand, i can't tell from almost zero context, can you send me the entire output
<rtg> henrix, I just created a ports tag that matched the others, then pushed that
<henrix> rtg: still can't see it...
<rtg> henrix, doh! now pushed...
<henrix> ah, now i can see it. thanks :)
<brendand> cking - http://paste.ubuntu.com/1110316/
<brendand> cking, there was https://bugs.launchpad.net/bugs/1021674
<ubot2> Ubuntu bug 1021674 in fwts "DMIInvalidHardwareEntry - Unmatched Chassis Type" [High,Fix released]
<brendand> cking, wonder if it's covered by that
<cking> brendand, yes it does, and it will be fixed in 0.25.06
<cking> ..I'm just waiting for it to be packaged and uploaded
<cking> brendand, so skip this one, it's a non-bug (fwts false positive)
<brendand> cking, will that end up in precise too?
<cking> brendand, not unless we explicitly get it uploaded to precise, I will talk to kengyu about this
 * herton -> lunch
<ppetraki> apw, cking,  https://pastebin.canonical.com/70912/ , evidently btrfs fi balance is not "optional"
<ppetraki> ran a defrag too, everything is good, and faster
<ppetraki> once I disabled cow, lots of space opened up, it's enabled by default
<cking> once cow is disabled you will see file updates performance drop
<ppetraki> turned out ssd wasn't enabled by default, added that too, overall the system feels snappier
<cking> ppetraki, ..until it eats your data :-/
<ppetraki> cking, regular backups :)
<ppetraki> cking, ext4 has failed me more on ssd than btrfs has
 * cking wonders how many hours ppetraki has run ext4 vs btrfs ...
<ppetraki> cking, well its my primary workstation so... since Dec 2011
<ppetraki> spent about a year on ext4, that didnt go so well. my early days of btrfs however, 2.6.32, when I was using compression, ended badly when I had an epic power failure. So I don't do that anymore
<bjf> ppetraki: i was just running btrfs on my laptop (encrypted home) and it was slooooowwww
<ppetraki> bjf, ever try it without cryptfs?
<bjf> ppetraki: yes about a year ago, slow and it ate data
<ppetraki> bjf, yeah, it moves fast, when I was using compression, everything that was zipped ended up with zero file size after a power outage
<ppetraki> but that was 2.6.32
 * smb -> EOD
<rtg> skaet, https://bugs.launchpad.net/ubuntu/quantal/+source/linux/+bug/1027851/comments/8
<ubot2> Ubuntu bug 1027851 in linux "Quantal desktop installation on a vm hung on reboot." [High,Fix released]
 * rtg -> lunch
<skaet> rtg,  agree.
 * henrix -> EOD
<navincool_2003> HI frieds
<cking> Libreoffice: cut'n'paste does not mean cut'n'crash, doh
<navincool_2003> yes
 * cking --> beer time
 * rtg -> EOD
#ubuntu-kernel 2012-07-26
<DanaG> Hmm, I'm trying to install the aspeed KMS driver (ast.ko) on 3.5-rc7 from kernel-ppa... and I'm getting this: 
<DanaG> make[1]: *** No rule to make target `/usr/src/linux-headers-3.5.0-030500rc7-generic/arch/x86/syscalls/syscall_32.tbl', needed by `arch/x86/syscalls/../include/generated/asm/unistd_32.h'.  Stop.
<DanaG> Same happens when I try to "make prepare" at the root of /usr/src/linux-headers-`uname -r`/
<DanaG> That file is also not in the installed kernel package.
<DanaG> oh wait, if this has been merged, the whole issue is moot: http://osdir.com/ml/kernel-team/2012-07/msg00111.html
<DanaG> er, wrong link.  this one: http://patchwork.ozlabs.org/patch/170358/
<DanaG> cool, it has been merged.  I'm still wondering about that syscall_32.tbl, though..
<smb> morning
<fredrikj> Hi, I installed mainline kernel linux-image-3.5.0-030500-generic_3.5.0-030500.201207211835_amd64.deb on 12.04 today, and it seems my graphics card doesn't work properly with that kernel. In gnome I end up in non-accelerated fallback mode. It is some intel mobile chipset on a clevo laptop. Acceleration works with a ubuntu mainline 3.4-rc6 deb. Is this a expected issue? Should I open a bug report?
<ppisati> moin
<infinity> ppisati: Can you think of anything from the most recent ti-omap4/precise SRU that would lead to TCP timeouts, poor network performance, poor USB performance in general, anything like that?
<RAOF> fredrikj: Did you also install linux-somethingorother-extras? That's where the GPU drivers are now.
<ppisati> infinity: an usb problem
<ppisati> infinity: i klnow there;'s a bug about it
<infinity> ppisati: I need to get lamont to downgrade all the shiny new precise buildds (or some of them) to the previous version to confirm, but I'm getting increasingly suspicious that the kernel is bouncing my machines temporarily offline here and there.
<infinity> ppisati: Oh, you have a bug?  Erk.  Kay.  And it's in 1416?  Downgrading to 1415 should make me happy?
<infinity> ppisati: Do you have a # for me?
<ppisati> infinity: and i know ming was going back and forth on it with a user
<ppisati> infinity: lemme find it
<fredrikj> RAOF: Nope, i didn't install extras. Will do. (The extras package description gave me the impression it was all about virtualization, so i didn't think it applied to me). Thanks.
<infinity> fredrikj: It's actually the inverse of being about virtualization.
<RAOF> fredrikj: It's all the stuff that virtualised installs *don't* want.
<infinity> ppisati: Hrm, I can't find a bug for it anywhere.  But if it's being tracked by *someone*, that's enough for me.
<ppisati> infinity: https://bugs.launchpad.net/linux-linaro/+bug/709245
<ubot2> Ubuntu bug 709245 in linux-linaro "ARM SMP scheduler performance bug" [Medium,Fix committed]
<infinity> ppisati: Do you know if downgrading to 1415 makes it all better, or if I need to go further back in time?
<ppisati> infinity: last comments talk about poor eth performance
<ppisati> infinity: dunno, it came out lately
<ppisati> infinity: but IMO it's the same root cause as all the other problems that we are facing on usb (crap performance, page fault, etcetc)
<ppisati> infinity: and it has always been there
<ppisati> infinity: why don't you downgrade just a couple of boards and try?
<infinity> ppisati: Hrm.  Yeah, nothing in this bug talks about precise kernels at all.
<ppisati> infinity: wait
<infinity> ppisati: And yeah, I'll try some downgrading.  Sadly, I don't have access to them directly, so it's a bit of an annoyance to use them for testing.
<ppisati> infinity: i see
<ppisati> infinity: but what are the symptoms?
<infinity> Unfortunately, I'm not sure how to reproduce the issues they're having.
<infinity> The symptom, from a distance, appears to be occasionally disappearing from the network and/or TCP timeouts.
<infinity> Only briefly.
<infinity> But just long enough to make the daemon monitoring them go insane.
<infinity> It's pretty much universally when they're doing heavy network I/O.
<infinity> Right at the beginning (downloading chroot and source) or end (uploading built packages) of builds.
<infinity> Which is somewhat frustrating, when you wait for 28 hours for a webkit build only to have the whole process explode in the uploading phase. :P
<ppisati> doh
<infinity> Anyhow, I'm trying to fix my sleep schedule a little bit, so I should get to bed.  But I'll get IS to downgrade some machines in the morning and see if they behave better. :/
<infinity> If they do, I'm at a loss as to how to report this effectively.
<infinity> "buildd-manager says the buildds go away sometimes" is a reeeeeally crappy testcase.
<ppisati> infinity: but at least we narrow down the window of troubled commits
<infinity> ppisati: Yeah.  Though, if the old bug was never really properly fixed, we're narrowing it down a commit that "made it worse".
<infinity> ppisati: Maybe that's even more helpful.  Dunno.
<ppisati> infinity: in my opinion, we are still working around it
<infinity> The patch we committed was certainly a workaround (and an unpleasant one at that).  I didn't realise that it never got fixed better upstream. :/
<apw> http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
<dileks> apw: is eugene teo still maintaining linux CVE stuff?
<dileks> http://git.kernel.org/?p=linux/kernel/git/eugeneteo/linux-cve-tagged.git;a=summary
<dileks> just found this, but remember there was a GIT repo with (fixed) CVE issues
<apw> dileks, i don't think i knew they were doing that?
<fredrikj> Just want to let you know that the problem with lack of acceleration of my graphics card indeed was caused by me not installing linux-image-extra. After installing linux-image-extra-3.5.0-030500-generic_3.5.0-030500.201207211835_amd64.deb acceleration works like a charm. Thanks again.
<apw> and a 10s window to react yay
 * henrix is out for lunch
<josepht> I have a similar kernel panic as in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018547, but it only seems to happen when using the Fn+F2 hotkey to disable/enable the radio.
<ubot2> Ubuntu bug 1018547 in linux "Kernel panics when connected to wifi" [High,Triaged]
<_ruben> hmm .. seeing http://pastebin.ubuntu.com/1111966/ more and more often in the logs of a router running gutsy .. guess it's time for both hardware and software upgrades :p
<apw> gutsy ... boggle
<apw> josepht, as yours only happens on wifi rfkill toggle i would recommend getting it to occur and filing a bug on it with ubuntu-bug linux.  also put the backtrace you get in your bug
<josepht> apw: ack, thanks
 * henrix reboots
<smb> has anybody seen this too? after upgrading quantal on my acer aspire one and rebooting dmesg and nm connection info shows the lan and wlan connected but the indicator would not show this in the overview for quite some time...
<josepht> apw: done, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1029547
<ubot2> Ubuntu bug 1029547 in linux "Disable -> Enable wifi via Fn+F2 results in kernel panic on Dell XPS 14z" [Undecided,New]
 * rtg -> lunch
<smb> also is white the new black for the screensaver?
 * ogasawara back in an hour
<cking> smb, surely somebody has filed a bug for that
<cking> if not, I nominate you ;-)
<smb> cking, I always suspect apw
<cking> smb, for filing a bug, or just whinging about it? ;-)
<smb> cking, But do you see it too?
<cking> smb, yep
<smb> both
<smb> :)
<cking> it's ridiculously warm here, /me calling it a day
<apw> smb, there is a bug for white is the new black as well
<smb> cking, see
 * cking -> EOF
<cking> oops, EOD
<smb> F being frustration...? :)
<apw> smb, but i don't have it on my list it seems, damn
 * dileks thinks the date of meeting can be dropped/updated in topic?
 * rtg -> EOD
<Kano> hi, is there the code for the efilinux variant which should be used instead of shim?
<Kano> or will shim used instead now?
<rtg> bjf, I saw the armel build breakage for Precise. I've pushed a startnewrelease patch to master-next that fixes the build problem.
 * rtg is now really gone...
#ubuntu-kernel 2012-07-27
<smb> morning
<ppisati> moin
<cooloney> apw: hey, andy
<cooloney> i'm trying to use aufs in quantal, but found it's not built as module. like modprobe aufs will fail.
<cooloney> even i tried my own built kernel package from latest master-next
<cooloney> smb, morning, ^^^
<RAOF> Aufs has never been in mainline, right? And we've stopped patching it in - it's now overlayfs only.
<smb> cooloney, morning, yes afaik aufs is not build to see who screams
<smb> Its unionfs i think 
<smb> or overlay
<smb> bah
<smb> RAOF, Oh btw, when I just see you around... May I express my unhappiness with X for Quantal (bug 1029582)? :)
<ubot2> Launchpad bug 1029582 in xorg "Unusable graphics with ATI RS690M" [High,New] https://launchpad.net/bugs/1029582
<cooloney> RAOF and smb, exactly, we are using overlayfs from upstream now. but i'm working on a bug which is on overlayfs but not on aufs
<cooloney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/959352
<ubot2> Ubuntu bug 959352 in lxc "Ephemeral containers have "/rootfs" prefix in /proc/self/maps entries" [High,Confirmed]
<cooloney> it looks like there is a bug in overlayfs, but i wanna make sure it is not on aufs.
<cooloney> so trying to enable aufs in kernel now
<smb> cooloney, I am not very confident that the aufs module has been kept in a buildable state... even if it is still in there
<cooloney> smb: hmmm. looks like i can only use old kernel 
<smb> cooloney, Well I'd probably try to follow the "rootfs" hint. There seems to be not too many places in fs/ than have it. So fs/namespace.c and fs/ramfs/inode.c seem to be the only places. namespace.c looks like a good place to start...
<cooloney> smb: thanks, i'm looking at that. probably fs/overlayfs/inode.c, but i fail to find the lxc configuration in Quantal, looks like lxc changed a log
<RAOF> smb: Sadface.
<smb> cooloney, Right, maybe it would help to talk to stgraber / hallyn about the differences in mounting between ephemeral and non (like whether one uses its own namepsace or not). Since one seem affected but not the other
<smb> RAOF, Me too, I use that laptop normally for iso tests. but right now it is not very helpful
<smb> And I could not even tell why... To me the logs are not very bad looking... at least not that critically bad...
<smb> Not that I know what to look for...
<RAOF> smb: It looks like some acceleration snafu.
<RAOF> Yeah, all the logs look fine.
<smb> RAOF, Yeah, well I will help as much as possible. Just need someone to add someone to add a few pointers about debugging this.
<smb> oops
<smb> mental loop detected... abort for more coffee
<RAOF> :)
<RAOF> Does it actually work, just fail to display correctly?
<RAOF> ie: if you type blindly to log in, does the screen change?
<smb> No, with the current state I seem to get some more broken graphics and then fall back tolightdm
<smb> Well probably you can say that works in some way a bit
<RAOF> Ah, so it actually crashes somewhere?
<smb> But sooner or later (if I insist on using graphics) I also had total lockups
<smb> Let me try again and see whther there is more in and *old.log
 * smb just was glad optional text mode worked to get sshd installed...
<cooloney> smb: i found the templates of lxc moved from /usr/lib/lxc to /usr/share/lxc/
<smb> Ok, right now there is a black screen but I heard drums...
<cooloney> smb: do you know why lxc should use overlayfs? is it for chroot rootfs?
<smb> cooloney, Well since the dictionary say ephemeral means temporary I assume their purpose is to be playgrounds to revert back to what things where when you end the container...
<cooloney> smb: yeah, ephemeral just start the lxc container and execute some commands in it then shutdown the container
<smb> cooloney, But also I guess your fs will be unchanged whatever you do. Thus overlay or aufs...
<cooloney> smb: and in /usr/bin/lxc-start-ephemeral, it use overlayfs as default unionfs
 * smb would prefer temporary for simplicity
<RAOF> smb: Could you try adding an Xorg.conf with Option "NoAccel" "true"?
<smb> RAOF, Yes, if I get it up in a state it is usable. Seems it exploded right after the drum sound. No ssh no nothing... arg
<RAOF> Ok, that suggests that the driver is just sending garbage to the drm device. That's not wonderful.
<smb> RAOF, :) No I think it makes the device a bit unhappy
<cking> smb, http://en.wikipedia.org/wiki/Zero_insertion_force
<cking> so many standards
 * apw yawns
<smb> apw, slacker. :)
<smb> apw, cking and I already completed all of our morning whining...
<apw> i can't speak yet, know i am moaning inside
<cking> yep, as ever, lots of stuff to whine about
<smb> apw, We pretend we can hear you complain then
<cking> the old geezers whining channel
<smb> RAOF, Ok NoAccel allows to use things... /me goes updating the bug
<cking> apw, smb, I've sent some slub/slab results to you for your eyeballing
<apw> cking, ack
<smb> ok
<apw> cking, remind me, did we decide that EFI would need FAT
<apw> i think we did 
<cking> yes
<apw> thought so
<cooloney> cking: hey, cking, i've setup ceph server on my host and i'm going to setup a ceph client on a PandaES board
<cking> cooloney, cool, lemme know if you need any assistance
<smb> cking, After finishing my netbook surgery I am looking at the slab/slub report. One note about the graphs: if possible I would use the same y-scale for left and right. But that is probably just my personal preferance. :) And about locality, that is the unsigned byte distance? Just wanting to understand better. Maybe I missed the real explanation,,,
<cking> smb, it's the unsigned difference between the addresses
<cooloney> cking: so i've mount vm'ceph fs on my host machine. if i write some file to this /mnt/cephs, can we read it out in vm?
<smb> cking, Ah ok, thanks
 * cooloney is going to upgrade his old macbook pro to SSD and 8G RAM, and hope to do some testing in the future
<cking> cooloney, you can only make sense of the data on the client - on the host it's in CEPH's format
<cooloney> cking: it means i need setup a ceph client somewhere and mount the directory in that ceph client, right?
<cking> cooloney, yes, you need to mount it with a ceph client
<cking> cooloney, but ceph client is built into our kernel, so it should work easily on a client
 * henrix -> lunch
<cooloney> cking: ok, thanks, will bring up on my pandaES
<cooloney> apw and cking, enjoy your Olympic Game Openning
<apw> cooloney, just waiting for the rain to start
<cking> cooloney, so you probably need to do three tests of tests:  client on x86, server on arm, and client on arm and server on arm and finally client on arm, server on arm
<apw> cking, on arm .. fun
<cking> cking, gotta be thorough :-)
<cking> bah, /me now talking to himself
<njin> hallo guys, can be this a linux bug ?  [drm] nouveau 0000:00:05.0: PGRAPH - ERROR nsource: FORMAT_EXCEPTION nstatus:
<njin> [drm] nouveau 0000:00:05.0: PGRAPH - ch 3 (0x000db000) subc 6 class 0x009f mthd 0x0308 data 0x00180042
<njin> [drm] nouveau 0000:00:05.0: PGRAPH - ERROR nsource: FORMAT_EXCEPTION nstatus: INVALID_STATE BAD_ARGUMENT PROTECTION_FAULT
<apw> njin, that is the kernel complaining about the format of a GPU command it was passed likely from mesa
<njin> apw, thanks, so this is not an error ? my syslog is full of this
<njin> andf the graphic is garbled
<apw> njin, its clearly an error, its not necessarily a kernel bug, it is as likely a mesa bug as mesa writes the GPU instructions
<njin> apw thanks, so i open a bug report against mesa
<apw> as the X folk have more knowledge of the GPU side i tend to file their side and let them decide if its kernle :)
<apw> i would file it against the xorg drvier for your card, and they will reassign it sensibly if its wrong
<njin> ok, i do then, thanks again
<apw> np
<infinity> libdrm seems like a sane spot to assign blame.
<infinity> It could just as easily be an overheating video card, though.
<apw> infinity, by filing it against the ddx for nouveau the right logs get got automatically, then X bots it into the right place generally
<apw> infinity, indeed, could be the kernel not doing powermanagement or 1000 other things :/
<infinity> njin: File wherever apw tells you to file, but I do recommend checking your fans. :P
<apw> if only these vendors realised they need to _support_ the crap they sell
<apw> especially as win8 looks like its going to be an utter disaster and is driving the games people away
<infinity> apw: Nah, I didn't mean to imply it was software overheating it, but that 99% of "my screen is garbled" video card issures are airflow and/or loose heatsinks.
<infinity> issues...
<njin> infinity, ok I try to put an additional one, but the case is already opened
<apw> infinity, oh i cannot argue with your analysis at all.  i still file against ddx just to get right X info
<infinity> njin: I didn't mean "add more fans", I just meant "check that the one on the card is still spinning, check that the heatsink is hot to touch", etc.
<apw> those heatsinks where the paste is dried out are the worst
<cking> or fluff stuck in the fan outlets
<infinity> (The heatsink should be so hot that it burns your fingers under load, if it's not, it's come loose or the thermal paste has gone bad)
<njin> infinity, fan is spinning, and cleaned
<infinity> njin: Alright.  Then happy bug filing.  ;)
<njin> then I file a bug against xserver-xorg-video-nouveau
<infinity> Frying video cards is actually (seriously) why I gave up on high-end gaming. :/
<apw> wtf i am suddenly getting 40k a second instead of 500 from the DC ... wobble
<apw> oh i wonder if we are suffering olympic internet syndrome already
<infinity> apw: A flood of Romney-mocking tweets, no doubt.
<rtg> henrix, I just pushed a closing entry to Precise master-next. do some test builds on that.
<henrix> rtg: thanks. i'll check that
<henrix> rtg: i'm building it now, it will take a while.
<henrix> rtg: so, there was nothing wrong with your patch. the prob was that i modified the abi directory (basically, i renamed it). since there were changes done to the arm abi, these changes were lost
<henrix> rtg: the origin of this issue was the rename, due to the unreleased version on git
<rtg> henrix, but you are agreed that what is in master-next right now is correct ?
<henrix> rtg: yep, it is and it should fix the prob. the ignore file should fix it
<rtg> henrix, and you understand _why_ the ignore files are OK in this instance ?
<henrix> rtg: yep. i guess i overcomplicated this :(
<henrix> rtg: solution is far less complex
<henrix> rtg: thanks
<rtg> henrix, normally an ABI ignore on a minor update is dangerous, but since that kernel was never published...
<henrix> rtg: ack
<rtg> apw, drat. I've just done a 'reset --hard' on a branch that I hadn't pushed. Is there a way to figure out what the origin SHA1 was on that branch before I lose all the commits leading up to it ?
<rtg> original*
<rtg> aha! ORIG_HEAD perhaps ?
<apw> rtg, if you did a git reset --hard then git log -g will show the previous locations of the HEAD
<apw> over time back for about 2 weeks
<apw> this drops out a list of somethig called the reflog, git log -g shows HEADs location, git log -g <branch> does just the branch tip
<apw> rtg, did you find it ?
<rtg> apw, yep, ORIG_HEAD had what I needed
<apw> rtg, ok the reflogs have a longer view should you really mess up :)
<rtg> I assume that a 'git gc' cleans up all history wrt previous HEADs ?
<apw> rtg, the reflogs hold references to old trees based on time, so they should be there i think it is either 14 or 21 days, then the reflog entries go and release them
<rtg> ok
<apw> that said my reflogs for my ubuntu-quantal head goes all the way back to 18-nov-2011 wow
<apw> rtg ok its 90 days for entries which point at things which still exist from a the tip you are on, and 30 days for others
 * rtg relocates...
<josepht> I'm trying to bisect commits between mainline v3.4.6-quantal and v3.5.0-quantal.  Should I be using the Ubuntu... tags or the v3... tags?
<rtg> josepht, likely the v3 tags since the commits are more or less linear. the Ubuntu tags could be across a rebase.
<josepht> rtg: thanks
<apw> bjf, https://wiki.ubuntu.com/Kernel/KernelPPA i have created a new page which describes the KernelPPA, how to make one, how to upload, how to copy to -proposed, why debug is bad etc.  but it needs the how to copy bit filling in ... perhaps you could do the honours
<bjf> apw, will do, thanks
<apw> bjf i have also rejigged the bottom of stable release cadance so it tells you sh
<apw> 'who to give the package to, or where to upload it' sort of thing instead of all those details on the Kernel PPA which are now in the other page
<bjf> nice
<dileks> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=commitdiff;h=dc9bd4098f0cf9703f30fe2fa3c433fafddf435c
<dileks> http://kernel.ubuntu.com/~cking/iosched/
 * cking suspects an impending discussion about this
 * dileks looks at Overall.. section
 * cking recommends dileks to read the entire report rather than just drawn a conclusion from the final section
 * dileks cross-read it
<cking> ah
 * dileks ...and looked at the result sheet (ods)
<dileks> depends whats your focus... more modern hardware and filesystem, you might be on the right track
<dileks> more on*
<cking> dileks, like all things, some win, some lose
<dileks> IIRC the linux-fsdevel guys have a testsuite. you tested with it?
 * dileks checks mailbox
<cking> dileks, no, but if I tested with all the fs test suites out there I wouldn't get any results out before 14.02 :-/
<cking> apw, so, I think the conclusion from the slub/slab data is we should stick with slub 
<dileks> hehe. visited donald knuths blog yesterday for 1st time... referenced from a x32abi link... and while reading more articles taocp page was listing about book part V an ETA 2020
<cking> hopefully knuth with be alive then, we can only hope
<cking> bjf, we got any precise SRU kernel updates coming down the pipe? I think I'm waiting for the U300 S3 bug to get verified
<henrix> cking: on its way
<dileks> age 74
<bjf> cking: yup, this is prep week. 100+ are inbound
<cking> ooh, that's a whole load of patches  in the pipe 
 * ogasawara back in 20
<dileks> cking: nice editing with test-results
<cking> dileks, much appreciated :-)
<apw> cking, slub> thanks for investigating
<cking> apw, if you think I should explore more avenues, I'm happy to do so, but I think we have enough data to make a decision
<apw> cking, no i trust your judgement, we had what was an arbitrary choice made "this is new and cool" some two years ago, now we have numbers to say it was cool
<apw> cking, that is good enough for me
<cking> and other distros are using the same config too, so that's helpful
<rtg> apw, IIRC there was _some_ LKML data to justify the switch.
<apw> rtg, yeah but i knew it was by someone who tended to say things were great for everyone when only had tested them on vast machines with zillions of cpus
<rtg> well, true
<apw> so its good to have some proper analysis tell us we made a sane choice :)  and more importantly it remains a sane choice
<rtg> apw, I was just pointing out that our decision to change  wasn't _completely_ frivolous.
<apw> rtg, heh sorry, i know it wasn't quite as arbitrary as i make it sound ...
<cking> it wasn't a flip of a coin choice that's for sure
<dileks> so, slub + deadline is todays choice?
<apw> at least while cfq continues to have these hideous corner behaviours i recon
<cking> dileks, slub has been our choice for quite a while
<apw> cfq must be one of the most incongiously named drivers there is
<rtg> dileks, yes, deadline appears to behave a little better under extreme conditions.
 * dileks remembers discussions with fellows from grml and debian and both switched to slab... so this might have changed again
<dileks> any link to "...LKML data to justify the switch"
<dileks> cking: testsuite is called xfstests which you can use also for numerous other fs#s
<cking> dileks, yes, I'm familiar with those, I used them to exercise eCryptfs a lot
 * cking --> more coffee. when will this flippin' jet lag wear off?!
 * dileks recommends a centrifugal machine for astronauts to kill jetlag
 * cking recommends sleep 
<apw> ppisati, remdind me did you tell us why we have CONFIG_SATA_AHCI_PLATFORM off on ti-omap4 ?
<apw> ppisati, i sort of think you said it turned something ugly on
<ppisati> apw: it breaks compilation if OMAP5 is not defined (and we don't define it)
<apw> ppisati, ahh thanks thats the one
<infinity> apw: It's somewhat moot anyway, unless you can figure out how to staple an AHCI controller onto your Panda.
<apw> infinity, indeed but we are looser with things in the config review, clearly here it should be off though
<infinity> At least until we start flirting with the idea of building unified omap kernels, yeah.
<infinity> (Which would be nice, if omap4 and omap5 are finally being upstreamed enough to get away with it...)
<apw> ogasawara, i think we decided we'd keep CONFIG_WAN_ROUTER on only where it might possibly have been used before, which for me is i386/amd64 and powerpc ... right ?
<apw> infinity, oh indeed, which is one reason we try and turn on as much common stuff as we can so any future merge is easier
<ogasawara> apw: yep
<ppisati> infinity: omap3 + omap4 is doable for R IMO
<apw> ogasawara, and can you remember anything about GPIO_SYSFS
<ppisati> infinity: while omap5 is clearly impossible
<infinity> ppisati: Well, Linaro is already doing it now, but obviously not with mainline.
<infinity> Not sure how massive the TILT changeset still is, I haven't looked in a long time, but I trust that you're on top of it, so I try not to care. :P
<ogasawara> apw: i remember we asked jj and he didn't have a good recommendation for it
<ogasawara> apw:  so it seems we tabled it for later
<apw> ogasawara, oh hrmmm ... 
<ppisati> infinity: http://people.canonical.com/~ppisati/ti-omap4-tilt-34-on-35/tilt-3.4/
<infinity> ppisati: So, still "huge", then.  Basically.
<infinity> Although, they're all rather tiny changes.  Maybe they just need to upstream harder.
<apw> heh so we can merge omap3 and 4 if we pull it out of master
<ppisati> yes
<infinity> apw: Which we could do if master could either (a) build linux-libc-dev without a kernel, or (b) we added a different flavour (like, say, vexpress)
<infinity> Oh, wait, we have another flavour now.  Hi there, highbank.
<apw> infinity, i beleive we can do that anyway
<infinity> (Except on armel, but we'll cross that bridge when we get to it)
 * smb -> EOW
 * herton -> lunch
 * ppisati -> gym
<apw> ogasawara, ok other than GPIO_SYSFS there are only three red lines in the 'common drivers' sections, they are all bryan's fault, once my test builds are done i'll push
<ogasawara> apw: heh, awesome thanks
<apw> ogasawara, if we ignore ti-omap4 things are very close to as good as they are going to gt for Q i recon
<apw> get
<ogasawara> apw: I can be happy with that
<apw> ogasawara, i recon we let bryan do a bit more and then relegate the rest to R's torture
<ogasawara> apw: do we want to have a WI for cooloney/ppisati to clean up ti-omap4 or feed us annotations?
<ogasawara> apw: whatever they don't hammer out we can grind through at UDS-R and our next sprint
<apw> ogasawara, i think they have one for some of it anyhow... i have some open WIs for it so i may just hammer them out and use them as testing bitches
<ogasawara> apw: ack
<apw> s/it/general beta2 review/
 * apw waits impatiently for gomeisa
<apw> ogasawara, heh a 15m load average of 178 ...
<cking> it's almost on fire
 * cking --> food
<apw> ogasawara, ok it seems to build for me, highbank is an abi bumper so you'd need to slip one of those underneath when you are tieing the bow
<apw> (as and when)
<ogasawara> apw: ack
<apw> ogasawara, i've close that WI so we are making progress ...
<apw> ogasawara, i think that gets us back to normalised relative to the slow even after the crap we added last week
<apw> s/slow/slope/
 * rtg -> lunch
 * cking --> EOW
 * rtg -> EOW
<joshhunt_> i saw usn-1515-1 for a new kernel pass by the other day on the mailing list, but then it seems to have disappeared. does anyone know the status of this?
<sbeattie> joshhunt_: hunh. that's odd. Will look.
<sbeattie> joshhunt_: I've caused the USN to be regenerated at http://www.ubuntu.com/usn/usn-1515-1/ I'm not sure why it wasn't there before
<joshhunt_> sbeattie: thanks
<joshhunt_> sbeattie: yeah it was weird. i saw it in the mailing list, but then it wasn't on the rss feed/web site.
#ubuntu-kernel 2012-07-28
<thebishop> if i want to build a 3.5 kernel on 12.04, can i do this through the git method or do i need to grab source from kernel.org "the old-fashioned way"?
<thebishop> it's not clear to me from the git method guide:  git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git  whether this repo has the absolute latest or just the latest for precise.  I see the mainline ppa stops at 3.4x for precise
<thebishop> https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide?action=show&redirect=KernelTeam%2FKernelGitGuide
#ubuntu-kernel 2012-07-29
<ChaoPeng> Hi, there
<ChaoPeng> I'm a new comer
<autojack> I'm trying to follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel on a Lucid system. I've built kernels completely from scratch before, but never built kernel packages like this. the 'fakeroot debian/rules binary-headers binary-generic' step is failing because there's no binary-generic make target. help?
<infinity> autojack: On which arch?
<cobra> When I  try to update the kernel it says cryptsetup: WARNING: failed to detect canonical device of /dev/sdb1
#ubuntu-kernel 2013-07-22
<ox8085_> unable to patch my wireless card bcm4312 for packet injection
<jpds> When will raring pieces be available in http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/ ?
<apw> RAOF, that mir staging PPA is all out of sync and eating my machine today
<apw> RAOF, there are no bees
<xnox> apw: Debian is removing a few obscure filesystems from their kernel config http://lists.debian.org/debian-boot/2013/06/msg00107.html and to this effect various parts of d-i are also removed to no longer offer unsupported filesystems.
<xnox> apw: are our kernels going to follow suite, or shall some of the d-i bits continue to be maintained to continue supporting those/some fs mentioned above?
<RAOF> apw: That's unfortunate! I've been pouring bees upstream!@
<apw> xnox, i think this we are aware of this, i guess we'll discuss with foundations and see that they plan for d-i in light of that, though as cjw is heavily involved i am sure he is aware
<apw> xnox, looking at the list, there is no standard install which would use those filesystem types for install, i don't see us removing them unless they get broken, wich if they are not maintained i suspect they would
<xnox> apw: ok. in debian they went on a removal spree of (partman-$foo) and we haven't merged d-i stack in a while. both colin and i busy with other ubuntu-touch things =)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203211 => Somebody can check this out ?
<ubot2`> Ubuntu bug 1203211 in linux (Ubuntu) "Modprobe doesn't recognize any parameters on 3.10.0-4" [Undecided,Confirmed]
<apw> xnox, yeah, i think i'll see you sometime next week so we can discuss it in person :)
<xnox> apw: well, unless you are planning on kidnapping me, you will only see colin/steve in person sometime next week. =)
 * xnox guesses i somehow don't know something =)
<apw> dupondje, thanks ... am look at that indeed
<dupondje> thx apw, as it seems quite broken :)
<apw> dupondje, indeed quite
<psivaa> apw: I have reported bug 1203694 not realising the existence of the above bug. Assume both are related. Pls feel free to mark it dupe if you think its appt.
<ubot2`> Launchpad bug 1203694 in linux (Ubuntu) "virtual-host saucy server smoke tests fail because kvm_intel and kvm_amd are not present in lsmod output" [Undecided,Confirmed] https://launchpad.net/bugs/1203694
<apw> psivaa, yeah prolly the same, thanks
<psivaa> yw
<apw> dupondje, smb, could you test the kernels here: http://people.canonical.com/~apw/lp1203211-saucy/
<smb> apw, yup
<apw> and let me know if that works for one
<smb> apw, seems to wfm. kvm_intel with nested=1 is loaded
<apw> smb, thanks ... sigh
<infinity> apw: What did you change?  Do I want to know?
<smb> infinity, These are not the changes you are looking for...
<apw> infinity, reverted a patch we carry which is an optimisation for init, whcih i suspect (if these all become working) has been miss forward ported to this release
<apw> we don't need it per-se any how so i would propose to revert it and upload without and think about it at my leisure
<infinity> apw: Curious.  But also, WTF did -3 work? :P
<infinity> apw: Just dumb luck, I guess?
<apw> some of that i suspect yes
<apw> now i have found a blatent unititialised pointer in lightdm which
<apw> seeming should stop it working for anyone ever
<apw> and yet has only started hitting my machine today randomly
<apw> now to try and find the frigging source branches for it
<apw> oh god ... it has a packaging only branch ... i hate those even more
<infinity> Heh.  Just pull-lp-source
<apw> yeah i am going to, it is clear seb128 has done that in the past as well :)
<apw> now i could just edit this shit, and debcommit it and it will make me a quilt patch right ?
<apw> arse, not that, its erm, why are names so hard
<infinity> apw: dpkg-source --commit
<apw> now, why doesn't debcommit do that
<infinity> apw: debcommit is for magically committing to packaging branches (it even sorts out if you're in git, bzr, svn, etc)
<apw> infinity, is it reasonable to just upload this lightdm change
<dupondje> apw: can only test this evening if still needed :)
<apw> dupondje, ok
<apw> i guess smb's and my confirmation will have to do
 * ppisati -> out for lunch
<infinity> apw: Just uploading it is probably fine, but if the packaging branch is up to date, you should commit there too.
 * henrix -> lunch
<zequence> infinity: If I were to update linux-lowlatency for the development release now and again, how would the uploading work? Do you have something similar to SRU for the development release as well? I think I read something about you changing routines for saucy, or maybe I was just imagining?
<infinity> zequence: kernels to straight to the archive for devel releases, no interim PPA business.
<infinity> zequence: For the master kernel, they're using tracking bugs, but no need for derivatives.
<apw> zequence, infinity, i suspect once i've done a couple to amke sure its working ok, you could do them, and just upload them to your normal ppa
<apw> then we can copy them out in the normal way
<apw> infinity, ok this revert is looking like it is doing the business on the module param issue
<apw> so i'll get that preped and uploaded shortly
<apw> rtg, yo
<rtg> apw, dude
<apw> rtg, i am just prepping a 3.10.0-4 upload to quickly fix a module load iss
<apw> rtg, but i see there is a .2 in stable and now wonder if we should shove that in
<rtg> apw, wanna pick up a stable ?
<apw> thoughts?
<apw> i'll take that as a yes :)
<zequence> apw: infinity: ack
<rtg> apw, yeah, I'll get the -rc2 in shape in the meantime. gonna start prodding the dkms folks to be ready for a switch by te end of the week.
<rtg> apw, don't forget the tracking bug :)
<apw> rtg, ok ... revert the 'all parameters' patch en-toto for now, we don't require it in fact and it is causing these issues right now; i'll fix it up
<apw> and resubmit once i have figured out the issue
<rtg> apw, 'UBUNTU: SAUCE: (no-up) add option to hand off all kernel parameters to init' is the patch causing problems ?
<apw> yes .... revert that, upstart will cope (and be marginally slower)
<apw> but something in the forward porting (or lack thereof) has broken it all of a sudden in -4
<rtg> apw, ack, I'll just drop it from unstable for now
<apw> though i suspect -3 working is complete luck there
<infinity> apw: Wait, is that the patch responsible for my upstart getting passed things like --debug and --no-sessions from the cmdline?
<infinity> apw: Losing that will be a bit irritating.
<apw> yes it is
<apw> oh, no it isn't
<apw> those are unknown which are passed on, its the known ones like quiet that are the issue
<apw> which upstart looks for in /proc/cmdline anyhow, its all a bit stupid
<apw> i want to rework it anyhow, cause i think when we are doing it, the init needs to know, so we need to say like "ALL" at the front or something to say they are indeed all there
<apw> so i'll revisit it, and fix it right this time
<dupondje> apw: just home, will test
<dupondje> apw: ok, it works :)
<ppisati> brb
<apw> dupondje, nice thanks
<ppisati> on S/generic (but only highbank related so far) i need to run a script/function at postinst time
<ppisati> is there a generic way to hook into the installation process, or shall i just modify debian/control-scripts/postinst and be done?
<ppisati> what i need to do is to change some constants in /boot/boot.script, since the new kernel in S needs more space (and thus we need to move initrd further below in memory)
<caribou_> ivoks: I have one Maas bug that I haven't had time to work on
<Caribou> ivoks: would you have some cycles to look at it ?
<Caribou> ivoks: pretty simple issue
<Caribou> crap ,sorry for  the noise guys, wrong room
<apw> Caribou, np
 * apw wanders to another (hopefully cooler) location ... bah for heatwaves
 * apw discovers that this "other location" has cold cider, who would have guessed
<apw> rtg-afk, ok kernel uploaded
<apw> ogasawara, i uploaded a -5 kernel today to fix a module parameter issue which was affecting testing pretty badly, fyi
<ogasawara> apw: ack
<rtg> apw, how will reverting that parameters patch affect upstart in Lucid (with the LTS kernel) ?
<rtg> not Lucid, but precise
<apw> rtg, shouldn't affect it in theory, though i intend on fixing it tommorrow
<apw> it needed a cleanup anyhow
<rtg> apw, ack
<apw> rtg, basically upstart has no way to know the kernel can do the feature, so it has to check, so it should find out what it needs by other means
<lool> Hi, Xorg doesn't start anymore with 3.10.0-4 but it does with 3.10.0-3; is this a known bug?
<apw> and we need a way to allow it not to do that, so it needs ot know it can not do that
<lool> this is on intel graphics on a thinkpad X301
<apw> lool, i have been some issues with lightdm and unity-greeter with later kernels
<apw> lool, so far the bugs have not been the kernel though
<apw> what is the last thing you see
<lool> apw: If I try to launch X, it says no device detected
<rtg> apw, I also sent an email to you and the k-team list about a couple of other patches that I dropped. 
<lool> [    16.760] (EE) No devices detected.
<lool> is what it says in the Xorg log
<lool> it's possibly related to some Xorg side changes that are needed for the new kernel
<apw> lool do yo uhave any i915 kernle parameters
<dupondje> lool: prolly some modules not loaded ? :)
<apw> (on your command line)
<lool> /proc/cmdline: BOOT_IMAGE=/@/boot/vmlinuz-3.10.0-3-generic root=UUID=b13b1eeb-f9f4-404f-bb88-3c87466c9c14 ro rootflags=subvol=@ quiet splash vt.handoff=7
<apw> not that then, that one may be new, though i would strongly suggest trying the .5 i just uploaded to confirm
<lool> apw: in -proposed then?
<apw> lool building, i'll find you a binary
<lool> I discovered a bug in the failsafe handling while I was there
<lool> apw: thanks
<dupondje> https://launchpad.net/ubuntu/+source/linux/3.10.0-5.14/+build/4816287/+files/linux-image-3.10.0-5-generic_3.10.0-5.14_amd64.deb
<dupondje> :P
<dupondje> https://launchpad.net/ubuntu/+source/linux/3.10.0-5.14/+build/4816287/+files/linux-image-extra-3.10.0-5-generic_3.10.0-5.14_amd64.deb
<apw> lool, if those don't do it: http://people.canonical.com/~apw/master-next-saucy/
<rtg> my Sandy Bridge server sure doesn't get along with 3.11-rc2
<apw> rtg, my efi obox doens't either
<apw> it is not a happy release
<rtg> apw, so far its not
<apw> fingers crossed for -rc3
<rtg> apw, yeah. in the meantime I guess I'll go work some Nexus kernel issues
<lool> apw: good news!
<lool> apw: it's indeed fixed with 3.10.0-5-generic
<lool> apw: thanks for putting it together
<apw> lool, great, that is already uploaded, so should be in the images tomorrow if we are lucky
 * rtg -> lunch
<cooloney> ogasawara: your video about Ubuntu for phone is great!!!
<hallyn> jdstrand: we should probably discuss the kvm.ko problem here
<rtg> infinity, were you considering making use of saucy-udebs-generic in Precise ? That patch is causing a build error in the LTS backport (though easily fixable)
<jdstrand> hallyn: ok. still, I want to reboot into 3.10.0-5 :)
 * jdstrand is almost done downloading
<rsalveti> rtg: thanks for rebase & upload
<rtg> rsalveti, I figured that was the most thorough approach
<rsalveti> yeah, that's fine as well
<kamal> bjf, jsalisbury, mjg59: just fyi, I have released 3.8.13.5-stable which includes the fixes "Modify UEFI anti-bricking code" and "x86/efi: Fix dummy variable buffer allocation" (plus some supporting framework)
<mjg59> kamal: Thanks!
<mjg59> Appreciate it
<kamal> mjg59, likewise!
<jdstrand> hallyn: ok, 3.10.0-5 fixes the kvm_intel nested=1 issue
<jdstrand> let's see if it also fixes the hard lockup
<jdstrand> that would be a 'no'
<jdstrand> erf, ubuntu-bug won't let me report it ye
<jdstrand> yet
<apw> jdstrand, hard lockup doing what
<jdstrand> apw: the 3.10 kernel, kvm and my x201s (i7) do not get along
<apw> so kvm, ok, i have seen a lock there too
<jdstrand> apw: qemu-kvm crashes hard unless I downgrade to a raring kernel
<apw> when you have filed a bug, would you ping me the number so i can look at it
<jdstrand> sure thing
 * jdstrand wonders if there is a way to waive the official Ubuntu package check
<jdstrand> ah, maybe I just have to add -proposed back to sources.list
<jdstrand> ah, no it is in NEW and arm is still building
 * jdstrand reboots in 3.8 for now
 * rtg -> EOD
#ubuntu-kernel 2013-07-23
 * apw yawns
 * smb waits
<apw> smb, have you seen this KVM hang people are reporting in saucy (since -3 i _think_)
<smb> apw, no, but mostly because I have not yet looked at kvm recently as I was busy with xen
<apw> (and by hang i mean host locking solid)
<smb> apw, do you have the bug number more ready than me?
<apw> i saw it myself last night, and someone was reporting it on #ubuntu-kernel last night, but though i asked for a number i wasn't present if and when it was filed
<smb> Hm... lets see what is see in scrollback...
<apw> so there was no bug from jdstrand then ?
<smb> not mentioned in this channel
 * apw starts looking to see whne it was introduced
 * apw gets out a piece of paper
<apw> smb, jdstrand, KVM hang bug filed: bug #1204005
<ubot2`> Launchpad bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005
<ppisati> apw: brb
<ppisati> ops
<ppisati> brb
<apw> ppisati, heh
<larsu> booting into 3.10.0-4 messes up my graphics. Uses vesa because it can't find /dev/dri/card0. Is that a known issue?
<larsu> oh, this is an intel card btw
<smb> larsu, If 3.10.0-3 was working still it might be the same module loading with arguments stopped working regression. I thought i915 was sometimes affected too. You might try the -5 kernel. apw, is that somewhere already
<larsu> yep, -3 is definitely working (I booted into that now)
<smb> https://launchpad.net/ubuntu/saucy/+source/linux/3.10.0-5.14
<apw> smb, larsu, seems to be in -proposed at the moment, but there are some prerelease ones here: http://people.canonical.com/~apw/master-next-saucy/
<smb> Currently still in proposed but that should not be enabled
<smb> Or directly wget from launchpad
<larsu> smb, apw: thanks, I will try that one
<seb128> hey there
<seb128> larsu, did you figure out your intel issue?
<rickspencer3> apw pinging you because I thought you might be up
<rickspencer3> wireless doesn't work for me with the new kernel :(
<rickspencer3> and it sounds like larsu has some video issues?
<larsu> rickspencer3: yep, apw just pointed me to -5, which might fix the issue
<larsu> http://people.canonical.com/~apw/master-next-saucy/
<larsu> smb, apw, rickspencer3: -5 fixes it indeed. Thanks!
<apw> larsu, great ... it is stuck in migration cause of the alpha2 freeze, but they actually want it
<jdstrand> apw: re bug #1204005, thanks!
<ubot2`> Launchpad bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005
<smb> apw, Unfortunately I am as unsuccessful in getting the hang with a EFI booted desktop as I was before... :(
<apw> smb, i am going to put that on the boggle list and not worry about it too much for now
<apw> smb, it is clearly reproducible for many of us, so that is very odd indeed
<apw> smb, so i get to find it :/
<smb> apw, Yeah. Just sad that I cannot be of any help there
 * ppisati -> reboot
<nessita> diwic, hello! I'm ready for debugging whenever you can
<diwic> nessita, hi, I just started looking at your logs
<diwic> nessita, it looks like several "maybe" bugs in combination somehow
<diwic> nessita, but first, don't get confused by Raymond - he's often out on the wrong track
<nessita> diwic, I was going to mention, his comments really, really confused me
<nessita> diwic, is there anything I can run/test from here to help?
<diwic> nessita, maybe we should try the wakeup_rt tracer to see what's causing system latencies. Instructions coming shortly, I just have to refresh my memory a little on how to do that...
<nessita> diwic, great, I'll wait for those
<infinity> BenC: Were you going to do any regression testing (or a smoketest, at least) of the raring-proposed kernel on your hardware?
<diwic> nessita, ok, now posted as comment in the bug
 * nessita goes and check
<diwic> nessita, when it says "run for a minute or two" that means run skype/mumble/hangout 
<nessita> diwic, what should I run for the "Run for a minute or two" part?
<diwic> nessita, just try to talk to someone on mumble e g
<nessita> ah, ok
<nessita> diwic, attached, shall I also attach the pulseaudio verbose log?
<diwic> nessita, thanks, I'm analysing the wakeup_rt file now
<diwic> It's the graphics, that's for sure
<nessita> diwic, the graphics mess up with the sound?
<diwic> nessita, do you use open-source or binary nvidia drivers?
<nessita> diwic, checking
<diwic> nessita, binary it seems like
<nessita> NVIDIA Driver Version: 304.88
<diwic> yeah, that's binary
<nessita> yeah, wasn't fully sure because in the upgrade to raring I did not explicitely enabled any propietary drivers
<diwic> so; either we can try pursuing this track, i e, trying different driver versions, open-source drivers if you don't need anything that the binary drivers provide etc
<diwic> or I could try looking deeper on the PulseAudio side to see if I can understand why you start getting underruns every 200 ms 
<diwic> or both...
<nessita> diwic, happy to do whatever you think is best. I'm not sure about the open-source drivers, there was a time were those were underperforming, no idea now
<diwic> nessita, okay, let's say you give the open-source nvidia drivers (nouveau) a try, and see if they work sufficiently well for you or if they cause other trouble.
<apw> BenC, yo ... do i have access to your saucy repo, i was just trying to push the new linux-ppc-udebs thing that infinity was after
<diwic> nessita, and if they cause trouble, come back to me and we'll try to look deeper on the PulseAudio side of things
<nessita> diwic, so, before I do that, question: I reproduce the sounce bug in a raring booted in mem from a pendrive
<nessita> diwic, doesn't that setup use the default stuff from the ubuntu repo?
<nessita> I reproduced*
<nessita> (ie, the default stuff would be the open source driver)
<diwic> nessita, yes, if you boot Ubuntu from a pendrive, that should use the open-source drivers by default I believe
<nessita> diwic, right, I reproduced the same audio playback issue there (was the second thing I tried -- first one was latest kernel)
<diwic> nessita, so if that also causes the problem, it would be interesting to see what a pulseaudio verbose log looks like when booted from the pendrive
<nessita> diwic, I can do that. Is there any way of enabling verbose pulseaudio output without rebooting
<diwic> nessita, https://wiki.ubuntu.com/PulseAudio/Log doesn't include rebooting 
<nessita> diwic, ah, yes, but that disables autospawn, and I've noticed different behavior of the sound stopping with or without autospawn
<diwic> nessita, in what way is it different?
<nessita> without autospawn is much "harder" to reproduce the bug
<nessita> with autospawn I can reproduce almost instantly
<diwic> nessita, autospawn is unrelated, possibly the debug level can cause that effect, but not autospawn in itself I believe
<nessita> diwic, but if the information is the same for you in both cases, I can certainly try that
<diwic> nessita, you can also just execute "pacmd set-log-level 4", without restarting PA, and it will start outputting the verbose log to /var/log/syslog
<diwic> nessita, if you like that better
<nessita> diwic, I do! will use that
<nessita> ok, so, rebooting to raring from pendrive
 * henrix -> lunch
<nessita> diwic: hi there, I'm in the raring booted from pendrive. Definitely using nouveau: video                  19390  1 nouveau
<diwic> yep
<nessita> diwic:  ran the pacmd set-log-level 4 command but verbosity did not increased in syslog
<nessita> diwic: shall I have restarted the pulseaudio service?
<diwic> nessita, no, that's not necessary
<diwic> nessita, did "pacmd set-log-level 4" say anything else than "hi and welcome to pulseaudio"?
<nessita> diwic: yes, it did
<nessita> will paste the whole output
<nessita> diwic: I had audio playback at first, but opened chrome to do a hangout and audio stopped. Pasting output
<nessita> diwic: http://paste.ubuntu.com/5904065/
<nessita> PA output seems not verbose though
<diwic> nessita, could you execute "pulseaudio -k", start the wakeup_rt tracer, go to a hangout, stop the wakeup_rt tracer and attach the output?
<nessita> diwic: yes. Shall I start from a clean raring again?
<diwic> nessita, from the pendrive
<diwic> nessita, you don't need to reboot, just restart pulseaudio with "pulseaudio -k"
<nessita> diwic: ack!
<nessita> diwic: I have more log in syslog (opening it with less showed me that there was much more verbosity). Shall I pastebin that?
<diwic> nessita, ok
<nessita> diwic: http://paste.ubuntu.com/5904076/ doing the other test now (pulseaudio -k)
<diwic> Scheduling delay of 105.41ms, that's a lot, really
<nessita> diwic: does that give you any hint of what needs fixing?
<diwic> nessita, the kernel needs fixing
<nessita> heh
<diwic> nessita, if we could capture one of those really high spikes with the wakeup_rt tracer it could tell what part of the kernel needed fixing, too
<nessita> diwic: yeah, trying to do a hangout, but it keeps erroinh
<nessita> erroing
 * nessita is on it
<diwic> nessita, you can also try just using the audio wizard in mumble
<nessita> great, let me install mumble
<nessita> gaaaah 2fa
 * nessita hunts a 2fa code
<diwic> nessita, no, just start the audio wizard
<diwic> nessita, you don't need to connect to a server
<nessita> diwic: yeah yeah, already did, the 2fa is for logging in to LP
<nessita> and upload the trace
<diwic> nessita, pastebin it here instead
<nessita> diwic: as you wish, already found the code generator
<nessita> diwic: http://paste.ubuntu.com/5904115/ (also uploaded to the bug)
<apw> jdstrand, you are hitting this hang in kvm, could you tell me which display adpater you have configured
<apw> jdstrand, if you have vmvga configured, could you switch it to cirrus and see if it will boot without eating your machine
<diwic> Sarvatt, ping, what do you think of the trace nessita just posted?
<diwic> Sarvatt, nouveau hanging the kernel for 90 ms? And nvidia did it for ~20 ms
<diwic> Sarvatt, also I can't really understand that even if nouveau wants to do that, why don't we just schedule audio/Pulseaudio on another CPU core?
<nessita> diwic: is there anything else I can do from this raring boot? happy to wait if that could help, but otherwise I may reboot to my "normal"  setup
<diwic> nessita, feel free to reboot to your normal setup
<nessita> thanks
 * nessita brb
<nessita> diwic, so, I will be resuming some tasks, let me know if you need something else from me
<diwic> nessita, ok, thanks!
<nessita> thank you :)
<nessita> diwic, not sure if it's relevant, but in all cases mic keeps working (people keeps listening to me)
<diwic> nessita, I'm not sure if it's relevant either.
<nessita> ack
<rtg> apw, just pushed a rebase to saucy unstable that might impact the boot issues on your laptop.
<rtg> bjf, apw: did either of you have time to read the k-team email I sent yesterday entitled 'Patches dropped on the way to 3.11-rc2' ?
<bjf> rtg, i glanced at it
 * bjf goes back to find it
<infinity> BenC: Are you around?  linux-ppc in saucy is very broken.
<smb> apw, After running for a while I had a kvm guest crash my AMD machine (using vmvga). Though it took a while and also the stacktrace points to virtnet ...
<apw> smb, hmmm perhaps it is not the same, there seems to be a lot of issues this week
<jdstrand> apw: lucid and precise are cirrus, quantal and higher are vmvga
<jdstrand> let me reboot to see if either makes a differnce
<apw> jdstrand, it isn't reasonable for that to fix it at all, as clearly there should be nothing which allows a hang like this, but i would like to confirm you see the same as me
<jdstrand> apw: yeah, and fwiw, cirrus is rubbish for quantal and higher 
<apw> jdstrand, yep, i was much happier with the other one in R, but if it is that at least i have it cornered a little
<jdstrand> there is a bug on that too
<jdstrand> bug #1080674 was for display corruption
<ubot2`> Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed] https://launchpad.net/bugs/1080674
<jdstrand> but on quntal, there were frequent guest crashes
<jdstrand> I don't know if a bug was filed for that
<smb> jdstrand, fwiw it also affects Xen and you cannot change the gfx there :-P
 * smb wished they had fixed the driver and not just the default gfx card for KVM
 * rtg starts bisect for mb raid0 mount failure in 3.11-rc2
<rtg> md*
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<infinity> I assume someone's still looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204005 ?
<ubot2`> Ubuntu bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged]
<rtg> infinity, I think apw is on it
<apw> infinity, yeah that one i am working on right now
<apw> infinity, if you switch the graphics for your VM to cirrus it'll likely stop it eating your machine
<apw> while i struggle to find out wtf is going on
<nessita> diwic, saw your comment in the bug, shall I try that ppa with my current raring installation (nvidia) or booting raring from the pendrive?
<infinity> rtg: Oh, you mentioned that the foo-udebs package blows up for you on lts-raring?  I don't much care but, on the other hand, we tried to engineer it to work right for derivative kernels.  What breaks?
<rtg> infinity, I fixed it, no big deal.
<infinity> apw: I'm not hitting it personally, I'm just being annoying about following up on what looks like a nasty bug.
<apw> rtg, what did you have to change
<rtg> apw, added the flavours bit that is specific to saucy LTS
<rtg> control info
<apw> oh yeah, i see what you mean
<apw> infinity, so he just had to configure it is all
<infinity> Right, okay.  I was worried that fixing it meant breaking it. ;)
<rtg> gimme _some_ credit :)
<infinity> rtg: I dunno.  Do I have to?
<jdstrand> apw: ok, booting into 3.10.0-5 I started amd and i386 vms for lucid and precise, all at once, all using cirrus
<jdstrand> apw: I got to the login screen, logged in, started a browser, all fine
<jdstrand> apw: I then shut those down, and started an amd64 saucy vm with vmvga, got to the login screen, logged in and bam
<jdstrand> I don't think I always had to log in though
<jdstrand> (maybe, not sure)
<apw> jdstrand, that sounds like waht i saw thanks
<apw> so somehow vmvga tickles this, now to try and work out how a userspace emulation is imploding the world
<BenC> infinity: Broken how?
<diwic> nessita, it does not matter.
<infinity> -rw------- 1 adconrad adconrad 153262637 Jul 23 07:59 vmlinux-3.10.0-0-powerpc64-smp
<infinity> -rw------- 1 adconrad adconrad   5148092 Jul 23 07:59 vmlinux-3.10.0-0-powerpc-e500
<infinity> -rw------- 1 adconrad adconrad   5160618 Jul 23 07:59 vmlinux-3.10.0-0-powerpc-e500mc
<infinity> -rw------- 1 adconrad adconrad 113357254 Jul 23 08:00 vmlinux-3.10.0-0-powerpc-smp
<infinity> BenC: ^-- The lack of stripping on two out of four flavours...
<BenC> That'sâ¦very odd
<nessita> diwic, ack!
<BenC> infinity: I'll check into it
<infinity> BenC: Many thanks.
<BenC> infinity: how do I reproduce the environment in the buildds that causes it to build debug debs?
<BenC> infinity: And are the modules stripped ok?
<apw> BenC, full_build=true to fdr binary-arch will ensure the ddebs are made, expect it to take a while though
<apw> BenC, if you are using an sbuilder then you can find where we set that in the source and just force it on
<BenC> apw: Thanks
<infinity> BenC: Can you think of a module that would be large enough to tell for sure?
<BenC> du -sh /lib/modules/*
<BenC> And see if there's a large descrepancy
<apw> file on them tells you if they are stirppedd or not
<infinity> BenC: file(1) claims none of my modules are stripped, even for e500*
<BenC> 131M	/lib/modules/3.10.0-0-powerpc-e500mc
<BenC> 123M	/lib/modules/3.8.0-11-powerpc-e500mc
<BenC> 123M	/lib/modules/3.8.0-12-powerpc-e500mc
<BenC> I suspect the modules are ok for e500mc
<infinity> http://paste.ubuntu.com/5904539/
<BenC> At least they match up with raring
<infinity> Random module pick.
<infinity> So, I dunno.  file(1) could be wrong, or module stripping might just be weird.
<BenC> I don't think they would be fully stripped
<infinity> Yeah, it could just be file being wrong.
<BenC> There'd at least a debug link to the /usr/lib/debug blob
<infinity> BenC: Anyhow, as you point out, the module sizes appear to match 3.8.x, ish.
<BenC> infinity: My guess is that the ppc64/ppc-smp kernels show this problem because it is just a copy of vmlinux where as e500 kernels are the uImage (stripped/compressed/wrapped)
<infinity> BenC: So, whatever's going wrong here, I imagine it's just the kernel images.
<BenC> Probably need to add some machinery to strip these sorts of cases
<infinity> BenC: I'm a bit curious as to how that only became necessary between 0.3 and 0.5
<BenC> apw: this will likely be something to pull back into master for debian/rules.d/ 
<infinity> BenC: Did we not always have massive debug kernels that needed stripping?
<BenC> infinity: That's what I'm wondering
<infinity> BenC: The new CONFIG_ option may have tickled this.
<BenC> What is the config option?
<infinity> CONFIG_DYNAMIC_DEBUG=y
<infinity> And CONFIG_DEBUG_INFO
<infinity> So, two of them.
<BenC> debian.ppc/config/config.common.ubuntu:# CONFIG_DYNAMIC_DEBUG is not set
<BenC> CONFIG_DEBUG_INFO is on
<BenC> That's likely it
<rtg> BenC, is that a change from 0.3 ?
<BenC> rtg: Did this problem not happen in previous saucy linux-ppc kernels?
<infinity> +  [ Ubuntu: 3.10.0-2.11 ]
<infinity> +
<infinity> +  * [Config] enforce CONFIG_DEBUG_INFO
<infinity> BenC, rtg: This only showed up in -0.5, -0.3 was fine.  And -0.5 includes the above rebase.
<BenC> Ah, I remember having to enable that for the enforce
<BenC> Had it disabled before
<BenC> Problem identified
<infinity> So, it's probably right to enforce that, *but*, only if we can sanely strip the kernel that lands in the pakcages. :P
<infinity> Otherwise, dropping it for PPC for now seems a sane workaround.
<apw> yeah striping is normal during install i am supprised yours is not
<BenC> infinity: I can safely get it to strip
<apw> BenC, i am somewhat supprised you have to get it stripped
<apw> as the install i am sure asks for that for the binaries, and not for the ddebs
<BenC> apw: All of the other kernels that end up in .deb's are bzImage and similar, which get stripped before they are compressed
<BenC> apw: ppc/ppc64 use the raw vmlinux, which doesn't
<infinity> Yeah, but this should have been a problem for years, not suddenly today.
<infinity> That's what I'm unsure about.
<BenC> infinity: CONFIG_DEBUG_INFO wasn't enabled on ppc before this
<infinity> I mean, yeah, more CONFIG_DEBUG stuff got turned on, but the kernels should have still been big and debuggy before.
<apw> BenC, good to know
<infinity> BenC: Oh, that *was* enabled elsewhere before, but not enforced on PPC?
<BenC> Right
<BenC> Probably because nobody felt like dealing with it (maybe even me)
<apw> enforcement is new, because we lost it in master and that is bad for the ddebs
<infinity> Well, it would have never been on on PPC, even when it was in master, then.
<infinity> That's the bit I'm confused about.
<apw> hmm indeed, odd
<infinity> apw: Is CONFIG_DEBUG_INFO actually arch-specific in precise?
<BenC> The debian.master/config/enforce is what changed
<infinity> BenC: Sure, but keep in mind powerpc wasn't always rebased source.  I'm trying to sort out the root of this.
<BenC> infinity: Most likely
<infinity> If it really was arch-specific (perhaps due to this), that's a bit lolz.
<infinity> BenC: Anyhow, I assume there's some canonical kernel way to strip that isn't just "strip vmlinux"?
<BenC> infinity: I'm checking if there's maybe a "make STRIP=1 vmlinux or something like that
<apw> there must be a way
<infinity> I nly see the MOD_STRIP business.
<apw> stupid thing
<infinity> $(obj)/vmlinux.strip: vmlinux
<infinity>         $(STRIP) -s -R .comment $< -o $@
<apw> yeah you might be able to switch
<infinity> No idea if that's bootable, but that seems to be the object we'd want.
<infinity> (I see no reason why it wouldn't be bootable, I just can't test right now)
<infinity> BenC: ^
<infinity> BenC: So we want vmlinux.strip, not vmlinux, and a bit of movey-twiddling when installing it.
<BenC> infinity: Ah, that's really easy to do then
<infinity> (Which is fine, you have to rename it anyway to add version/abi/etc)
<BenC> Doesn't require syncing a fix back to master
<rtg> apw, drat. my SNB mount failure appears to be Ubuntu specific. vanilla 3.11-rc2 works OK.
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
 * ppisati -> gym
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 13th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * rtg -> lunch
<xnox> does our mako kernel have USB on the go patches ?
<ogra_> xnox, all android kernels use the android gadget to be able to run adb
<ogra_> so USb is claimed by that atm
<xnox> ogra_: ok, but that was not my question =)
<ogra_> well, we dont really offer a way to re-enable adb again if you disable it 
<xnox> stock mako kernel has on-the-go disabled and needs patches to be enabled, there are custom kernels available on $forums, but i'd like mine from a deb =)))))
<ogra_> and you cant reboot without cmdline ... so it would be useless 
<ogra_> we'd need a UI switch to toggle adb, then you could use OTG 
<ogra_> i assume we will want these patches in 14.04 for convergence though 
 * rtg -> EOD
<F41l> Question... can I get 32bit ubuntu kernel booting with EFI?
<F41l> I have an IA32, efi-only atom tablet that I'm having issue getting ubuntu installed on. I tried a method of installing to a usb-stick and using boot-repair to change it to EFI, but it's complaining about the kernel not being compatible.
<BenC> infinity: Can yaboot use gzip compressed kernels?
<BenC> infinity: Better yet, can I send you a deb to see if it works on your ppc64 and ppc32?
<RAOF> F41l: As far as I'm aware, EFI-for-IA32 is blissfully unimplemented.
<infinity> BenC: Not home in front of test hardware until August. :/
<infinity> BenC: I think it would be safe to assume the stripped vmlinux would boot fine, gzipped kernels would need a lot more testing, and not all ppc32 machines are yaboot.
<BenC> infinity: Unfortunately, you can't "make vmlinux.strip" directly, and calling "make zImage" creates vmlinux.strip.gz
<BenC> infinity: The compressed zImage is actually an executable, that would unzip itself
<BenC> I just need to make sure it works
<infinity> BenC: Sure, I realize what a zImage is and I realize that, in theory, it should Just Work from pretty much any bootloader, but I make no guarantees.  One would think that if there were no problems with zImage on PPC, we'd have been using them all along, no?
<infinity> BenC: And, at least on my 32-bit system, I fear for things like BootX and Quik sucking. :P
<infinity> BenC: Right, so, load addresses are the issue.  Any modern yaboot should probably be fine, ancient bootloaders (like mine) might not be.
<infinity> BenC: You could just make vmlinux and strip it with the same arguments that vmlinux.strip uses as you install it to the deb?
<BenC> infinity: Yes, but that requires me to mess with things in debian/rules.d/ and I was hoping to avoid that :)
<infinity> BenC: Well, I'm willing to bet I won't be able to coax my ppc32 machine into booting a zImage, but happy to play next month when I get home.
<infinity> BenC: I realize that machine (an ancient G3) is hardly a large or common use-case, but I see no reason to gratuitously break it either.
<BenC> infinity: Very true
<infinity> BenC: From what I can tell, though, yaboot should have supported zImage since 2001, ish.
<infinity> BenC: We can, again, confirm that when I get home, but I'd see no reason we can't switch ppc64 to zImage if that's true, since the only ppc64 bootloaders we use (yaboot or grub2) would both work.
<BenC> infinity: I'd be willing to bet the executable zImage will work even on your machines, but I'd have to make sure
<BenC> infinity: I might post these images to debian-powerpc and see if people can test it
<infinity> BenC: Well, as pointed out in the yaboot-supporting-zImage thread I found, the fundamental issue is that the bootloader needs to detect if the image is a zImage or vmlinux, cause they need to be loaded to a different address before jumping into them.
<infinity> BenC: http://lists.debian.org/debian-powerpc/2001/09/msg00710.html
<infinity> BenC: So, I'm willing to bet no one ever bothered to retrofit quik and bootx to do that, cause who cares.
<infinity> BenC: Worse, benh hasn't touched bootx since 2000 or so, so I imagine it's bitrotted to the point where my trying to fix it would make me want to shoot myself.  Or he may have even lost the source, I forget noew.
<infinity> BenC: On the other hand, we don't support bootable media with anything but yaboot, so I could totally support zImage by default, and a bit of a hack to provide a linux-image-coff package that just has the vmlinux binary in it (and depends on the full linux-image) for schmucks like me. ;)
<infinity> BenC: If we do some testing and discover that zImage works for everyone who isn't me, I may give you a patch to do that.
<infinity> BenC: Cause smaller kernels for everyone who can use them sounds good.
<BenC> infinity: How about thisâ¦I'll upload with zImage and we'll figure out the fallout from there :)
<BenC> Worse case, we revert to stripped vmlinux
<infinity> BenC: Sure.  I suspect the fallout won't be all that interesting.  The people in my position (stuck with ancient bootloaders) are probably few, far between, and all running Debian.
<infinity> BenC: Oh, wait.
<infinity> BenC: No, please don't.
<infinity> BenC: We'll need a migration strategy too.
<infinity> BenC: Cause that changes the names yaboot.conf needs to look for.
<BenC> infinity: Well, if it "just works" what is there to migrate?
<BenC> No, I left it as vmlinux (I don't really care about the name matching with x86 vmlinuz type things)
<infinity> BenC: Oh, fair enough.  If the naming doesn't change, it should Just Work, unless it doesn't. ;)
<infinity> BenC: I'd test remotely right now, but I need that machine to not explode while I'm away. :/
<BenC> I'll expect a full report when you return home :)
<BenC> Or at least silence if everything works with no harm done
<infinity> BenC: Although, qemu-system-powerpc should emulate a yaboot-using type of machine.
<BenC> I think qemu stuff boots linux directly
<infinity> BenC: I'm pretty sure you'll hear from me about the ppc32 kernel.  But we'll see.  Maybe I'll get lucky.
<BenC> Even on e500 qemu stuff it doesn't even emulate uBoot
<infinity> Well, there's an openfirmware build specifically for qemu, which leads me to believe it *can* give you an early boot experience, if you so choose.
<infinity> Admittedly, I've never used it, cause I have faster PPC hardware than I could possibly emulate on my x86 kit.
<BenC> I'll toss it around in there and see what happens
<infinity> BenC: openhackware - OpenFirmware emulator for PowerPC
<infinity> BenC: Not installed as a dep of qemu by default, to keep the PPC cross-compiler and friends out of main, so you'll need to install it.
<infinity> Oh, hrm.  The package description claims it doesn't know forth, so maybe it just fakes it.
<infinity> And yaboot is a forth OF application, isn't it?
<infinity> So, nevermind.
<infinity> Not a valid test.
<BenC> yaboot is 32-bit native
<infinity> Oh, is it?
<BenC> only the bootX stuff is forth
<infinity> It was quik that was forth.
<BenC> I know the boot logo is in forth :)
<infinity> BootX is a MacOS application.
<BenC> Ah, right
<BenC> yaboot is the same base code as silo
<BenC> Neither of which is forth
<BenC> Althought both call into open firmware routines in order to work
<BenC> So maybe openhackware implements just enough for that
<F41l> RAOF: "blissfully unimplemented", as in, not coded, or... do I need a module, something?
<infinity> It's probably high time I spend a Saturday just switching PPC to grub2 and ditching yaboot anyway.
<infinity> Not that this helps my poor beige G3 with its BootX woes. :P
<RAOF> F41l: Not coded, AFAIK
<F41l> fek
<BenC> infinity: I purchased an Apple //c last week from a thrift storeâ¦thinking of adding a 6502-a2c kernel some time soonish
<F41l> how am I supposed to run 32bit 'buntu on an EFI-only system?
<F41l> thought linux runs on friggin' everything!
<infinity> BenC: Hah.  Masochist. :)
<BenC> F41l: why not run 64-bit?
<F41l> Impossible with this system.
<infinity> BenC: I assume it's a 32-bit-only Atom.
<F41l> It's IA32 Atom
<infinity> Intel's special way of saying they hate you.
<BenC> F41l: Oh, I suspect it's not an EFI problem as much as a correct kernel problem
<BenC> You said you got it to boot a kernel but it claimed it wasn't the right type of system
<F41l> Not necessarily. 
<BenC> Atom requires special binary, right?
<BenC> Like, it can't just run any old x86-32-bit kernel
<F41l> I installed ubuntu on a USB drive (as the hard drive), and am trying to change that installation to use an EFI bootloader.
<infinity> No, Atoms are just plain old i686
<infinity> But you need an EFI-happy kernel (and bootloader) if you have EFI-only firmware.  We provide none of that on i386.
<BenC> infinity: I thought the assembly was slightly different because of some ripped out functionality...
<F41l> using the boot-repair-disk, I attempted to do this, but the software gave me an error akin to something that the kernel wasn't compatible.
<BenC> Ah
<BenC> F41l: As they say in my countryâ¦SoL
<infinity> F41l: It's not wrong, our 32-bit kernels don't support EFI (and 32-bit EFI may be incomplete upstream too, haven't looked in a while), and we also don't provide a 32-bit grub-efi.
<F41l> Seems kind of dumb to alienate an entire swath of systems from running ubuntu.
<infinity> F41l: This isn't Ubuntu.  Upstreams don't support 32-bit EFI either, or didn't last we checked.
<BenC> F41l: I doubt it's an ubuntu problem
<F41l> I can get elilo to boot, but need a kernel too
<infinity> F41l: And to be fair, that "whole swath" is, like, three and a half computers.  All 32-bit Atoms were legacy BIOS until very, very recently.
<BenC> F41l: and to be fair the "swath" of Atom-EFI systems is more like a sliver 
 * BenC ^5's infinity
<F41l> *surprised horror* you rather I run windows 8
<F41l> !
<Sarvatt> they even made 64bit atoms that never got 64bit blob drivers (hello cedartrail with pvr graphics blobs) so needed the 32 bit efi crap to fix that fail.
<infinity> F41l: Anyhow, this isn't something we're being intentionally obtuse about either.  If the upstream support is there, we'll look at enabling EFI on i686 in Ubuntu too.
<F41l> blegh
<F41l> fucking clovertrail
<infinity> F41l: Trolling us with "threats" to run the OS that came on your hardware won't really help. ;)
<F41l> It was a joke :P
<infinity> It won't convince me to port Ubuntu Touch to iPhones either.
<F41l> If i had the technical knowhow and programming knowledge I'd single handedly put the support in myself.
<F41l> But I don't.
<F41l> *cry*
<F41l> I'd really like ubuntu touch to work on this device.
<F41l> I was going to settle for using Kubuntu and KDE Active
<infinity> Sarvatt: Mentioning cedartrail around me is a punishable offense.
<Sarvatt> infinity: hey you just messed with it on the archive side, i had to put up with it for months working with intel :)
<infinity> Sarvatt: You were paid to do it, I do 95% of my archive admin stuff off hours as a volunteer.
<Sarvatt> infinity: ugh, I'm so sorry.
<infinity> Sarvatt: So, basically, I was volunteering to gouge my eyes out with a fork and scream obscenities into the nether.
#ubuntu-kernel 2013-07-24
<F41l> man, I'm a bit miffed
<F41l> This clovertrail junk :(
<F41l> I'd have hoped some enterprising kernel devs would have taken that "challenge accepted" I read about intel saying no linux support on clovertrail and made it work.
<BenC> apw: Are you guys just incrementing the ABI during development on master regardless of whether it is needed or not?
 * apw yawns
<infinity> BenC: Did you pick up the debian/control change from apw on that upload too?
<infinity> apw: Or did you not push that to github yet?
<cking> apw, http://lwn.net/Articles/365835/
<apw> infinity, i didn't have push rights when i tried last
<infinity> apw: Oh, weird.  I thought we both did.
<ppisati> brb
<Caribou> Any reason why ubuntu kernel packages are marked "Priority:optional" ?
<Caribou> is it because it is not mandatory to install newer kernels (mandatory == automatic) ?
<davmor2> Caribou: I'm assuming it is because you may not want/limit downtime on a server so being able to plan a kernel upgrade post testing is important, you don't want your system to die because it got installed with the security updates
<Caribou> davmor2: yeah, that's sort of what I understood. We want to keep control over how kernel are upgraded
<Caribou> davmor2: thanks
 * henrix -> lunch
<nessita> diwic, hello there. So, I installed the PPA yesterday, rebooted this morning, and tried to reproduce the bug. Sound does not work at all, not even the mic, and I can not hear anything (not even for some minutes). In any case, I uploaded the syslog with the verbose pulseaudio content to the bug
<ogasawara> apw_: can you refresh my memory for why we suppressed the -extra's package for mainline builds?
<diwic> nessita, hmm, okay
<rtg> ogasawara, why do we need that level of confusion ? extra's just tends to confuse folks
<rtg> plus its kind of a maintenance hassle
<ogasawara> rtg: a maintenance hassle for the mainline builds?  I thought that's just a cron.
<rtg> ogasawara, new upstreams often cause missing modules or missing symbols in the main package.
<rtg> ogasawara, is someone hassling you about the size of the mainline package ?
<apw> ogasawara, casue they were confusing and not needed, and it was hard to make sure the right combinations were in the non-extras without knowing in advance the depandancies which caused it to fail to build
<apw> who is caring
<ogasawara> rtg, apw: Intel is trying to bisect that Romley boot issue for me and notes that the mainline builds fail while 3.10.0-4 from a daily live image is working and they were interested if it might be due to the lack of installing the linux-image-extra's package
<ogasawara> rtg, apw: which might indicate we are missing a boot essential module out of the main package
<rtg> ogasawara, they should be using 'make deb-pkg' as their build target during bisection.
<diwic> nessita, argh, it might be that the logging itself causes too much CPU power, so Pulseaudio ends up getting killed
<diwic> nessita, this bug is doing everything it can to escape us it seems 
<nessita> diwic, bad bug, bad
<rtg> ogasawara, 'deb-pkg' bypasses all of our packaging issues. they only need the initial config.
<diwic> apw, what does a "trap int3" message from the kernel mean?
<apw> diwic, what is the fulle message
<diwic> apw, from syslog: "kernel: traps: alsa-source-ALC[4882] trap int3 ip:xxxxx sp:xxxxx error:0" (where xxxx are hex addresses)
<rtg> apw, I'm wreaking havoc on saucy unstable this morning. reorganizing and squashing a bunch of commit log noise.
<rtg> apw, trying to bisect amongst our SAUCE patches to figure out what borks my SNB server boot has made me realize was a disorganized mess our commit history has become. I'm in full OCD mode for a bit.
<apw> rtg, ok i am sitting on my hands till you tell me otherwise unstable relaed
<rtg> apw, ack
<apw> rtg, in better news, the recent rebase you did to a commit post -rc2 has fixed up my ultrabook boot
<rtg> apw, cool
<nessita> diwic, anything else we/I can try on the audio front?
<apw> rtg, and that version seems to start my VMs ok as well
<apw> rtg, so i am be searching for something that isn't worth finding here
<diwic> nessita, oh sorry. I got caught up with other stuff. 
<rtg> apw, isn't that what you and jdstrand were fighting yesterday ?
<apw> yeah, i was unable to boot 3.11 on the machine experiencing the issueyesterday
<apw> your new one today i can
<diwic> nessita, it looks like the "scheduling delays of ... ms" does not show up in this version, which is annoying
<apw> rtg, though i have variously discovered that changing the video and changing the network can help in the VM
<apw> so it is all a bit mad
<rtg> apw, yeah, some of the post -rc2 patches were pretty meaty
<diwic> nessita, can you try the non-syslog version of logging (i e, to a file, like wiki.ubuntu.com/PulseAudio/Log says) ? Maybe that won't take so much CPU power.
<nessita> diwic, need me to revert to older pulseaudio?
<diwic> nessita, with this new pulseaudio
<nessita> diwic, will do
<nessita> diwic, me again. So, having pulseaudio running as per the wiki, when opening mumble, I got:
<nessita> nessita@dali:~$ LANG=C pulseaudio -vvvv --log-time=1 > ~/pulseverbose.log 2>&1
<nessita> Trace/breakpoint trap (core dumped)
<nessita> it died
<nessita> want the verbose log?
<diwic> nessita, oh
<diwic> nessita, install gdb and run "gdb --args pulseaudio -vvvv"
<nessita> on it
<diwic> nessita, you'll come into a gdb shell, where you write "r" to run the program.
<diwic> nessita, hopefully it will catch the trap
<nessita> Program received signal SIGTRAP, Trace/breakpoint trap.
<nessita> [Switching to Thread 0x7fffed380700 (LWP 3580)]
<nessita> 0x00007fffedbad451 in ?? () from /usr/lib/pulse-4.0/modules/libalsa-util.so
<diwic> argh
<nessita> w will not show a traceback
<nessita> ah, newer gdb
<nessita> where shows;
<nessita> https://pastebin.canonical.com/94962/
<nessita> diwic, ^
<diwic> nessita, hmm. I'll need to make a new PPA build
<nessita> diwic, happy to try it
<nessita> diwic, shall I attach to the bug the verbose log before the crash?
<diwic> nessita, if you like
<diwic> nessita, I think it breakpoints on underruns
<nessita> diwic, is that something from 1.4 or from your custom code?
<diwic> nessita, it's from enabling DEBUG_TIMING which gives us useful output
<nessita> ah
<nessita> diwic, do you need something else from the gdb session? tracebacks from the threads? (I see 3 threads)
<diwic> nessita, okay, I uploaded a new build to the ppa.
<diwic> nessita, no, let's wait for the new build. 
<nessita> ack then. When built will upgrade and re-test
<nessita> thanks!
<diwic> nessita, btw, if the lack of audio is causing you a lot of trouble, have you tried a USB headset? It might work better, but I'm unsure, because the system latencies could affect that one too
<nessita> diwic, so far I'm workaround this with my phone using skype or hangouts there
<nessita> workarounding*
<nessita> diwic, I have a bluetooth headset, I may give it a try
<diwic> yeah
<diwic> that's worth a try
<nessita> diwic, not sure if this is relevant, but I hit 'c' in the gdb session, before exiting, and got more info https://pastebin.canonical.com/94965/
<nessita> there are some "overrun" there, so perhaps is interesting for you
<diwic> nessita, yeah, it confirms the trap happened due to the overrun
<brendand> bjf, regression in precise SRU testing: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1199470
<ubot2`> Ubuntu bug 1199470 in Kernel SRU Workflow certification-testing "linux: 3.2.0-50.76 -proposed tracker" [Medium,In progress]
<brendand> bjf, sorry - the actual bug is: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204548
<ubot2`> Ubuntu bug 1204548 in linux (Ubuntu) "[HP ProBook 6550b] can't send files via Bluetooth" [Undecided,New]
<bjf> brendand, looking
 * apw watches his firewall root disk go bad before his very eyes
<apw> what else can go wrong htis week, i wonder
<rtg> git checkout -f un
<rtg> -EWRONGWINDOW
<arges> question for those that understand the backports packaging
<arges> i see bug 1194121
<ubot2`> Launchpad bug 1194121 in linux-meta-lts-quantal (Ubuntu) "linux-meta-lts-quantal should provide a kernel sources package" [Undecided,Confirmed] https://launchpad.net/bugs/1194121
<arges> Basically if I'm running 12.04.2 with the quantal-lts backport kernel, I would expect apt-get linux-source to install the 3.5 sources instead of the 3.2 sources right?
<rtg> arges, why ?
<rtg> apt-get doesn't know (or care) what kernel you're running.
<arges> rtg: right, but wouldn't a user expect linux-sources to install the same version of the kernel that's runnin
<rtg> arges, no. linux-source is packaged by linux (the source package).
<arges> Ok. so then would it make sense for the lts-quantal package provide a linux-source-*-lts-quantal package?
<rtg> arges, perhaps, but we chose not to at the time the LTS packages were developed.
<rtg> arges, what is your use case ?
<bjf> brendand, are you or someone else going to be around to test kernels?
<brendand> bjf, you want to be in touch with our lab engineers - roadmr and spideyman
<bjf> brendand, can you ask them to join this channel?
<brendand> bjf, yeah
<brendand> bjf, i'm currently writing instructions on how to reproduce it on the bug
<brendand> bjf, spideyman and roadmr can help
<bjf> brendand, spideyman, roadmr thanks, i'll have a kernel to test in about 15 min.
<bjf> maybe sooner
<roadmr> bjf: awesome!
<brendand> bjf, oh do you have a commit that's suspect already?
<bjf> brendand, yes, one kind of "jumps out"
<brendand> bjf, do you want me to mark the kernel 'certification-testing-failed'?
<bjf> brendand, sure
<bjf> roadmr, pleast try: http://people.canonical.com/~bradf/1204548/
<roadmr> bjf: downloading kernel (sorry for the delay)
<ppisati> brb
<bjf> roadmr, given https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204548/comments/5 is this a kernel bug or a bug in the test tool?
<ubot2`> Ubuntu bug 1204548 in linux (Ubuntu) "[HP ProBook 6550b] can't send files via Bluetooth" [High,Confirmed]
<roadmr> bjf: the test tool doesn't change, all I do is reboot with a different kernel
<bjf> roadmr, i understand that, but you say using obexftp fails, using the panel applet works
<roadmr> bjf: I'd understand if the tools poked the bluetooth stack differently, so one of them exposes a problem and the other does not, but it seems like *something* changed in the kernel that's making obexftp unhappy
<bjf> roadmr, yes but it could be that obexftp was doing something it shouldn't and getting away with it before. now that has been tightened up in the kernel and obexftp is failing.
<roadmr> bjf: good point... well, the BluetoothRevert kernel works fine, obexftp can send OK with that one, whereas with the -proposed one it fails (and further, with the .49 one in -updates it also works well)
<bjf> roadmr, so we know the commit to revert, we just need to decide if it's a userspace issue or not
<roadmr> bjf: hmm yes that makes sense
<bjf> roadmr, can you add the version of obexftp that you are running to the bug?
<roadmr> bjf: fwiw, obexftp has worked well on all other releases we test (quantal, raring). Precise 3.2.0-50.76 is the only one that failed
<roadmr> bjf: certainly
<bjf> roadmr, i'll look at the other releases but i'm thinking that commit may make it into the others if it isn't there already
 * rtg -> lunch
<roadmr> bjf: ok, sorry for the delay, last kernels we tested were 3.5.0-37.58 (quantal), 3.8.0-27.40 (raring)
<bjf> roadmr, that commit is in raring as well. i'm leaning towards reverting that commit for precise and looking at reapplying it for the next cycle. there are a couple other commits that may fix the issue you are seeing.
<henrix> bjf: are you talking about commit c15a1f053c753c375d1d61fdd3a77bcfcb305bfa (in precise)?
<henrix> bjf: i just took a look and it looks like there's a fix on top of it (not sure if it solves the prob)
<henrix> bjf: upstream commit 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112
<bjf> henrix, yes, and yes i saw that "fix"
<henrix> bjf: its already queued for stable 3.2
<henrix> bjf: ah, ok :)
<bjf> roadmr, i'll spin another kernel for testing in just a sec. probably take about 30 - 45 minutes
<roadmr> bjf: awesome, I'll step out for lunch while that's building, back in a bit!
<rtg> apw, I guess I'm done exercising my compulsions on saucy unstable for now. all pushed...
<rtg> back to bisecting why my server won't mount /home
<rtg> apw, dang. rebasing to Linus' tip fixed my mount problem. 
<bjf> roadmr, new kernel, same location: http://people.canonical.com/~bradf/1204548/
<roadmr> bjf: awesome, thanks, downloading now...
<roadmr> bjf: ok, the fixup kernel also works using obexftp.
<bjf> roadmr, this one you just now tested?
<roadmr> bjf: yes
<bjf> roadmr, cool, i think that all
<roadmr> bjf: so to recap, 3.2.0-49.75 from updates works well, 3.2.0-50.76 from proposed fails, the BluetoothRevert works well, BluetoothFixup also works well
 * rtg -> EOD
#ubuntu-kernel 2013-07-25
<slangasek> so apparently the mako kernel doesn't have PERF enabled, which means powertop doesn't run.  I'm surprised given how much focus there's been on power management on the phones - is there something other than powertop I should be using?
<ppisati> brb
 * apw reboots to see if any of his desktop will come back
 * henrix -> late lunch
<ppisati> any brave soul who is willing to review my packaging of an armhf/generic-lpae flavour for S?
<ppisati> watch out: at the end of the packaging, it craps out with an error
<ppisati> "dpkg-gencontrol: error: package linux-udebs-lpae not in control info"
<rtg> ppisati, where is your repo ?
<ppisati> "dh_gencontrol: dpkg-gencontrol -plinux-udebs-lpae -ldebian/changelog -Tdebian/linux-udebs-lpae.substvars -Pdebian/linux-udebs-lpae returned exit code 255'
<ppisati> rtg: let me push it
<ppisati> the problem is that $someone is passing 'linux-udebs-lpae' to dpkg-gencontrol instead of 'linux-udebs-generic-lpae'
<ppisati> but i can't find where it comes from
<apw> ppisati, that would be my fault
<apw> rtg, the udebs thing is my fault
 * rtg is still waiting on the repo location
<apw> rtg, i'll fix the udebs bit ... 
<apw> ppisati, can you post your repo ... then i can test my fix
<ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-saucy.git;a=shortlog;h=refs/heads/master_generic-lpae
<ppisati> apw: ^
<ppisati> rtg: ^
<apw> rtg, this packaging error is mine ... sigh
<ppisati> it's a S/master-next of yesterday (my time)
<rtg> ppisati, do you really need an inclusion list ? I think it would be simpler to just have a single linux-image package.
<ppisati> rtg: ah, could be that we can away without it
<ppisati> *we can go
<rtg> ppisati,  its simpler, and I assume calxeda isn't all that worried about package size
<ppisati> rtg: ok
<rtg> ppisati, is there currently HW available that will run arm LPAE ?
<ppisati> rtg: not in my hands, but cortex a15 are lpae capable
<ppisati> rtg: and qemu can emulate the a15
<ppisati> rtg: if we want something really cheap, there's the samsung chromebook
<ppisati> ~250$
<rtg> ppisati, ok, just making sure that this isn't a new flavour for vaporware. I don't follow arm developments as closely as you
<ppisati> http://en.wikipedia.org/wiki/ARM_Cortex-A15_MPCore
<ppisati> rtg: ah, and of course, the new calxeda silicon :)
<ogra_> ppisati, pfft, chromebook ... crap ... you want ubuntu edge !
<ppisati> ogra_: auahauh :)
<ogra_> 128G at SSD speed and 4G ram :)
<rtg> ppisati, I'd be tempted to squash all of the config patches into 'UBUNTU: [Config] add an armhf/generic-lpae flavour' in order to make building somewhat bisectable, thought this has been good granularity for review.
<rtg> though*
<rtg> ppisati, I assume this flavour will be important for the LTS kernel as well ?
<rtg> ppisati, cut and paste error in kernel-versions.in: 'armhf  PKGVER-ABINUM   generic-lpae            PKGVER-ABINUM-generic'
<nessita> diwic, hola! I just saw your msg in the bug report. I'm not currently in the computer that has the issue, I will report back this afternoon, but I can tell audio does not work even on almost "0" load
<diwic> nessita, okay...
<diwic> nessita, these delays are really strange
<nessita> diwic, also, this happens since my update to raring, in precise I had no audio issues at all
<nessita> diwic, besides checking the load, which I will do, is there anything else I can check/try?
<nessita> I'm happy to upgrade or fresh install saucy
<diwic> nessita, you can surely test random things 
<rtg> diwic, perhaps she should go back to Precise, but run the Raring LTS kernel in order to isolate any upgrade differences.
<diwic> rtg, yeah, that is not a bad idea
<rtg> or, are you pretty sure it is kernel related ?
<diwic> rtg, no I'm not sure where in the system it is, at all
<diwic> rtg, all I see is sudden delays, up to 200 ms, that causes the PulseAudio process to freeze
<diwic> rtg, and underruns as a result
<diwic> rtg, I don't know where those delays come from
<rtg> nessita, after re-installing Precise (and verifying that all works as it should), then install linux-generic-lts-raring-eol-upgrade
<nessita> diwic, other apps such as mplayer and youtube on fierfox does not have this issue -- I guess those do not use PA?
<diwic> I haven't ruled pulseaudio out completely either
<diwic> nessita, it has to do with low latency I believe - when streaming media you can have higher latencies than when having phone conversations 
<rtg> I guess if things work well with the LTS kernel, then the issue likely is with PA
<nessita> rtg, can do that, no problem (over the weekend)
<diwic> nessita, so those delays of 200 ms are not a problem when the audio buffers are bigger than 200 ms, but in case of VoIP, buffers are more like 10 ms or so
<nessita> diwic, ah, so that explains why mumble/skype/hangouts are the one that trigger the issue
<apw> ppisati, yo ... i have just pushed a quicky fixy to saucy master-next which ought to fix your udebs issue
<apw> ppisati, could you give that test for me
<ppisati> apw: let me check
<apw> you ought to be able to cherry-pick it
<nessita> diwic, so, summarizing I should: report about system load on current installation when bug appears, and, wipe raring and install precise fresh, with raring kernel
<rtg> nessita, install precise fresh, verify that all works well, _then_ install the Raring kernel
<diwic> nessita, if raring kernel only does not show the problem, try with the raring X stack as well
<nessita> diwic, any how to on how to pull the raring X stack in? is there a ppa? 
<nessita> rtg, right, yes
<ppisati> apw: ok, it's building
<rtg> though its easy enough to reboot with the desired kernel
<diwic> nessita, hmm, rtg should probably know the name of that package
<rtg> linux-generic-lts-raring-eol-upgrade ?
<diwic> rtg, right, that's both kernel and X stack?
<apw> rtg, this last commit on unstable, it seems to be a rebase commit, a start new release, and a removal of alx at the saem time, is this intencional
<rtg> diwic, no, just kernel
<apw> ppisati, let me know ... thanks
<rtg> maybe xserver-xorg-lts-raring. But there is no going back after installing that.
<diwic> oh
<diwic> and libgl1-mesa-glx-lts-raring
<diwic> according to the wiki
<diwic> wiki.ubuntu.com/Kernel/LTSEnablementStack
<apw> rtg, i thought you could downgrade again by installing the xserver-xorg (in theory)
<apw> not that i have ever tried of course
<rtg> apw, perhaps, never tried it
<apw> mlanghost is the one who should know i think
<rtg> as would jmleddy or Sarvatt
<nessita> ok, I guess that going back would be re-installing fresh after all those tests
<nessita> (which is ok)
<diwic> nessita, btw, there are no error messages or similar in dmesg that could give us a hint of the kernel is timing out waiting for something?
<apw> rtg, this last commit on unstable, it seems to be a rebase commit, a start new release, and a removal of alx at the saem time, is this intencional
<rtg> apw, oh yeah, I collapsed a bunch of noise
<rtg> mostly useless history
<nessita> diwic, will also check when I get to that computer. Would you please add this questions to the bug report, so I don't forget to check anything before wiping that raring?
<rtg> apw, all that noise is well preserved with the 3.10 tags
<diwic> nessita, hopefully the latest comment is sufficient?
<nessita> diwic, right, I need to rememebr to check dmesg, but think I will remember :-)
<ppisati> apw: ok, the udeb fix did it
<ppisati> but now i've another error:
<apw> whats the new one
<ppisati> http://paste.ubuntu.com/5911420/
<apw> ppisati, that implies the d-i config for is not being used i suspect
<rtg> you need a firmware exclusion file in d-i
<rtg> ppisati, did you fix the typo in kernel.versions.in ?
<ppisati> rtg: yep
<apw> ppisati, did you copy the armhf-generic files over in debian.master-/d-i
<apw> ppisati, did you copy the armhf-generic files over in debian.master/d-i
<apw> over to the new name
<ppisati> uhm
<ppisati> i'm actually missing debian.master/d-i/exclude-firmware.armhf-generic -> debian.master/d-i/exclude-firmware.armhf-generic-lpae
<ppisati> rtg: if i delete my generic-lpae.inclusion-list, will it automagically pick generic.inclusion-list or do i need to do something particular?
<rtg> jjohansen, apw, would you review http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=commit;h=7e78ed6018577530d4ec1fe9f60486aa6d9de529 to make sure I've not done something stupid security wise.
<rtg> ppisati, no, it simply doesn't use an inclusion list, and therefore only creates a single linux-image package.
<rtg> at least, thats the theory.
<ppisati> rtg: let's see
<rtg> ppisati, you shuld also be OK if do_extras_package != true
<BenC> apw: Can you look at this build failure and explain what I need to do for ppc? https://launchpadlibrarian.net/145776419/buildlog_ubuntu-saucy-powerpc.linux-ppc_3.10.0-0.6_FAILEDTOBUILD.txt.gz
<rtg> BenC, apw just applied a patch to master-next that ought to fix it.
<rtg> UBUNTU: [Packaging] fix SRCPKGNAME-udebs-FLAVOUR handling for complex flavours
<BenC> rtg: Thanksâ¦when's the next upload?
<rtg> BenC, unless something critical comes along, likely not until next week. we're considering switching over to 3.11-rc*
<rtg> we might sneak in a 3.10.y stable....
<BenC> rtg: ack
<ppisati> rtg: ok, i based my stuff on top of master-next and i'm doing the last build, can you refrain from committing to master-next?
<infinity> BenC: You may also be missing the debian/control tweaks you need, unless Andy pushed those to you.
<rtg> ppisati, I dunno, I'm kind of commit happy these days.
<infinity> BenC: (We both noticed, FWIW, that we don't have write access to your saucy treee on github)
<bjf> roadmr, just fyi, the newly respun precise kernel is in -proposed and ready for testing
<rtg> bjf, I don't think he's on IRC
<bjf> rtg, i just noticed :-(
<ppisati> brb
<BenC> infinity: Ah, I'll fix that up
<infinity> zequence: We had to respin precise, FWIW.  Should be ready for a lowlatency rebase.
<BenC> infinity: added both of you
<apw> right BenC soz was in a meeting
<apw> BenC, so that error is due to you needing the new control stanza for that package in the flavour-control.stub
<apw> BenC, did rtg already point you at it ... i was oging to commit it last night but couldn't
<BenC> apw: I added you to the repo, so if it's quick for you, please commit it
<apw> BenC, ack
<apw> BenC, i've pushed up what ought to be the right changes, could you do a build test, your kit is sooo much faster than mine
<BenC> apw: starting a full build now
<rtg> ppisati, is there any reason to call the new flavour generic-lpae as opposed to just lpae ? or maybe arm-lpae 'cause it _is_ specific to arm.
<apw> rtg, well generic-<variant> the first part imples it is meant to be a common image for all systems ... right ?
<ppisati> rtg: no reason, but that's what we had in x86 before (e.g. generic-lpae), wasn't it?
<apw> in the smae vein as generic/generic-pae in x86
<ppisati> and i think i heard someone sayign that the lpae version of arm should have been called generic-lpae
<bjf> ppisati, are you going to respin precise ti-omap4 ?
<ppisati> bjf: isn't it just a bluetooth fix?
<bjf> yup
<rtg> apw, ppisati: well, I think the 'generic' part of the flavour name is useless information. it doesn't really convey any meaning. (nor did it for x86 really)
<apw> rtg generic is what we call kernels for things which arn't machine specific
<apw> it has to have some name, well where we have a default variant
<infinity> rtg: I can agree with the "it doesn't convey anything", but be consistent.  If you want to take it off the ARM kernels, ditch it from x86 too.  And that's way more effort than matters.
<infinity> (In other words, don't bother)
 * rtg is just stirring the mud, and doesn't _really_ care all that much.
<ppisati> pull sent
<rtg> on the other hand, I really don't want to give the x86 32 bit folks any hope that we might someday reinstate support for x86 LPAE.
<apw> they will have to get that past you
<rtg> I still get hate mail once in awhile
<rtg> cyphermox, sforshee: if I've 2 APs with similar characteristics, but one has clearly inferior signal strength, why would NM _ever_ choose the weaker one on resume ?
<apw> rtg, we should hold off merging this new flavour until we get the new buildds
<apw> rtg, as we will be moving to 24 hours to build
<rtg> apw, I can merge but just not enable the flavour in armhf.mk
<apw> rtg, sure makes sense
 * ppisati -> EOD
<rtg> ppisati, CONFIG_KVM_ARM_MAX_VCPUS=0 ? the default is 4.
<cyphermox> rtg: could it be a 2.4Ghz and the other a 5?
<rtg> cyphermox, both are BG only
 * rtg -> lunch
 * rtg -> EOD
#ubuntu-kernel 2013-07-26
<BenC> linux-ppc-udebs-powerpc-e500_3.10.0-0.6_powerpc.udeb
<BenC> linux-ppc-udebs-powerpc-e500mc_3.10.0-0.6_powerpc.udeb
<BenC> linux-ppc-udebs-powerpc-smp_3.10.0-0.6_powerpc.udeb
<BenC> linux-ppc-udebs-powerpc64-smp_3.10.0-0.6_powerpc.udeb
<BenC> apw: That fix seems to work, thanks
<nate15329> ok...i have a pci_root PNP0A03:00: fail to add MMConfig information and then it hangs on pci_bus resource mem on boot for ubuntu 13.04 server...any ideas?
 * apw wonders where all his indicators are gone
<smb> apw, To the land of daily quality?
<apw> i wish i was on monkey island rather
<smb> True at least there problems are solvable after a while at least
<apw> heh and there is a hint button for when it isn't :)
<smb> You may add some sort of hint-button for some developers? :)
<apw> yay ... and hour to get machines upgraded and ready to use in the morning
<RAOF> Your machines need more bees!
<smb> rolling, rolling, rolling... :)
<apw> RAOF, now that is a truism ... i nearly ordered one yesterday
<RAOF> Only one bee?
<RAOF> That would be a very sad, lonely bee.
 * ppisati hands apw a rubber chicken with a pulley in the middle...
<apw> ppisati, :) ... that might make some nice soup
<ppisati> :)
<smb> it all voodoo...
<RAOF> Speaking of voodooâ¦ my Galago Ultrapro is currently being assembled.
<RAOF> So I'll soon get to see just how well HSW GT3 works 
<apw> RAOF, heh ... i hpe you arn't having to pay for that yourself :)
<apw> (it sounds expensive)
<RAOF> Laptop refresh.
<RAOF> It surprisingly wasn't.
<RAOF> The laptop refresh covered it (and a little bit more!)
<apw> nice
<apw> got a link to the machine
<apw> or is it a bespoke job
<RAOF> apw: Bespokeish - https://www.system76.com/laptops/model/galu1 with all the trimmings (240G Intel mSATA SSD, 1TB rotating rust, 16GB ram, etc)
 * henrix -> lunch
<rtg> apw, ogasawara: just pushed Saucy master-next rebase on to v3.10.3. I'm thinking we should upload from this relatively stable version in order to make the armhf lpae plumbing is good.
<ogasawara> rtg: ack, upload away
<apw> makes sense to not do both at once for sure (3.11 and that)
<rtg> ok, I'll get it in shape in awhile.
<zequence> infinity: Going away for a day or so, but seems like all is well with my uploads today
<infinity> zequence: Shiny, thanks.
<infinity> zequence: Please stop marking the prepare-package* tasks done.  It confuses the bot.  Just set "upload-to-ppa" to confirmed when you're ready for one of us to have a look.
<ppisati> rtg: i'm fixing the generic-lpae rebase in unstable
<rtg> ppisati, cool, I'm fixing master-next and preparing to upload
<ppisati> brb
 * smb -> EOW
<rtg> apw, https://launchpadlibrarian.net/145921281/buildlog_ubuntu-saucy-amd64.linux_3.10.0-6.16_FAILEDTOBUILD.txt.gz
<apw> rtg looking
<rtg> infinity, ^^ builld don't like your awk syntax
<apw> rtg, that is mine
<rtg> apw, I know
<apw> but we tested it ... so erp
<apw> infinity, which awk is the awk in a builder chroot
<rtg> apw, I pushed Ubuntu-3.10.0-6.17 with a release tracking bug in the changelog, but haven't uploaded it yet. I forgot with Ubuntu-3.10.0-6.16
<apw> rtg ok, we don't care enough about release trackers to re-upload do we ?
<rtg> so just slam any fixes on top
<apw> they only gneerate an email after all
<apw> ok
<apw> shit, it must be mawk
<apw> ok ... i will poke my eyes out and fix it
<rtg> bjf tells me they trigger the test cycle
<rtg> apw, ack
<rtg> apw, can you explicitly call mawk just as a test ?
<apw> mawk: line 4: syntax error at or near ,
<apw> rtg, yep that sdeem to confirm that awk is mawk and not gawk, and this is a an extension
 * apw hates on gawk for a bit
<bjf> apw, rtg, as long as the tracking bug title matches the kernel version "the right thing will happen" so if you need to fudge it a bit, do so
<rtg> bjf, I think we're OK. you created a tracking bug against tip of master-next which should be correct
<bjf> rtg, ack ... just saying if you had to respin it and you wanted to reuse the same tracker that can be done
<rtg> apw, if you explicitly call gawk, then we likely have to add it to the Build-Depends
<apw> rtg, yep makes more sense to refactor this to be right
<infinity> apw: Did you test with gawk or mawk?
<infinity> apw: Cause that's going to be mawk in the chroot, since you don't build-dep on gawk.
<infinity> Also, how did that succeed on i386...?
<apw> infinity, i wonder if we build-dep-indep on gawk for tools
<apw> infinity, or on something which deps on it ... 
<rtg> not directly
<apw> anyhow, i tested with 'awk' and didn't think about which it was, as i have both here.  refactoring to mawk
<infinity> apw: Or just build-dep on gawk and call it done.
<apw> one more build-dep, one more problem in bootstrap
<apw> i can fix it pretty easy
<infinity> apw: And yeah, your build-dep-indep pulls in gawk.
<apw> infinity, what are we using which uses that ?
<infinity> apw: So, be sure to make it work in both. :P
<apw> heh i will, ARRRG
<infinity> apw: transfig is what pulls in gawk, FWIW.
<rtg> might as well just use gawk then
<apw> rtg, well i've pushed a fix to the top, which works in mawk and gawk
<apw> rtg, either use that, or add gawk which ever 
<rtg> apw, I guess its a question of how explicit you want to be ?
<apw> if we are using gawk anyhow in indep i guess it is safer to use same in both
<apw> just for this kind of this
<apw> thing
<rtg> apw, so, do you wanna change the patch to just call gawk directly ?
<rtg> that is the simpler fix
<apw> rtg, you need to add the builddep as well
<apw> else we won't have it
<rtg> apw, yes
<rtg> apw, once upon a time I think it _was_ a build-dep
<rtg> I don't really care _that_ much. are you comfortable that this code is awk variant independent ?
<apw> rtg, ok i have reshoved with the gawk dep
<apw> as it does make sense to be consistant
<rtg> apw, Duild-Depend ?
<rtg> apw, now that I've completely pissed you off, maybe you should go have a beer :)
<rtg> I can take it from here
<apw> heh i am hopeless today
<apw> everything i touch it falling to bits
<apw> i now have a drive jammed in the 'hotswap bay' on my machine
<rtg> could be a problem for tomorrow
<apw> bloody thing is the 5th thing to go wrong today
<apw> grub cannot boot my disks cause they are mirrors
<apw> so i try and fix that and put it in my hotswap bay, now it won't come ot
<apw> finally, some wiggling and out it comes, phew
<infinity> apw: PHRASING
<apw> infinity, wonderful british phrasing deployes
 * henrix -> SIGWEEKEND
<bjf> henrix, see you next week
<bjf> henrix, safe travels
<henrix> bjf: yep, see you guys ;)
 * rtg -> lunch
 * ppisati -> WEEKEND :)
<rtg> bjf, arges: do you see this ? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1200117/comments/4 I wonder if that isn't the root of many of our unexplained kernel package install failures.
<ubot2`> Ubuntu bug 1200117 in linux (Ubuntu) "package linux-headers-3.2.0-49 (not installed) failed to install/upgrade: ErrorMessage: unable to create `/usr/src/linux-headers-3.2.0-49/include/asm-generic/cmpxchg-local.h.dpkg-new' (while processing `./usr/src/linux-headers-3.2.0-49/include/asm-generic/cmpxchg-local.h'): No space left on device" [Low,Incomplete]
<arges> rtg: looking
<bjf> rtg, that's very interesting
<rtg> isn't it just
<bjf> sconklin, kamal, ^
<kamal> hmmm
 * bjf wonders why jsalisbury set that bug to incomplete
<kamal> hmmm, but didn't we get a flurry of those reports from people who appeared to have just installed day-0 Raring, then updated?  I'm not wholly convinced.
<rtg> kamal, dunno, but it is certainly something to look at in the future
<kamal> rtg, ack.  and while I understand that dpkg/apt does check for "sufficient disk space", I don't know if it checks for "sufficient inodes"
<rtg> kamal, is the squash image a dd copy, or a file system copy during installation ? Maybe something was wrong with the squashfs image.
<kamal> rtg, I don't know the details of how that copy works
 * rtg is just injecting general paranoia into the situation
<kamal> and thanks for that, man!
<rtg> kamal, its just a little something to keep your mind off of the upcoming security debacle at the airport :)
<bjf> rtg, kamal is not participating
<kamal> rtg, what debacle?  I'll be sitting comfortably in my easy chair ;-)
<rtg> oh man, I was _so_ looking forward to stories of cavity searches
<kamal> rtg, sorry to disappoint ...  maybe next time!   hmmm.   :-/
<rtg> kamal, as if we'll ever get you on a  plane again
<kamal> I've been spoiled by consecutive events in Oakland
 * rtg -> EOW
<zequence> infinity: Alright. upload-to-ppa only then :)
#ubuntu-kernel 2013-07-27
<[Ch4m3l30n]> How can I tell which version/release of BlueZ is in the kernel I'm running?
<[Ch4m3l30n]> I'm trying to pair my OUYA controller to my desktop PC so my wife and I can play Trine 2 together and it seems like the controller requires the "Auto-pairing (PIN lookup) support" introduced in BlueZ 5.5 released on May 14th 2013. Two subsequent releases within the last 7 days have further improved that controller support and fixed bugs.
<mjg59> [Ch4m3l30n]: bluez is in userspace, not in the kernel
<[Ch4m3l30n]> kernel modules = userspace?
<mjg59> I'm not seeing any kernel modules in the bluez tarball
<[Ch4m3l30n]> I wouldn't expect that you should... wouldn't they come from kernel.org?
<[Ch4m3l30n]> http://www.bluez.org/about/ says "Currently BlueZ consists of many separate modules:
<[Ch4m3l30n]> Bluetooth kernel subsystem core
<[Ch4m3l30n]> L2CAP and SCO audio kernel layers"...
<ohsix> bluez us entirely userspace, the radios have a socket interface
<[Ch4m3l30n]> Let me ask my question a different way... the website http://www.bluez.org/ lists the latest releases as 5.x and the Ubuntu 13.04 package manager lists the latest available package for bluez as 4.101-0ubuntu8b1. Is that an indication that the bluez distributed in Ubuntu is incredibly old or what?
<mjg59> It is
<[Ch4m3l30n]> OK, I see that 4.101 was released about 1 year ago and the new 5.x versions are only 7 months old...
<[Ch4m3l30n]> I will compile from the latest release source code. Thank you for your time and helping me understand the architecture to rectify my confusion. Cheers!
<ohsix> theres a reason they're still using 4
<ohsix> heh
<ohsix> you will break your system, not in a way that can't be fixed,  but in a way not many people are willing to walk you through
<[Ch4m3l30n]> ugh
<[Ch4m3l30n]> It's so frustratingly paradoxical that Linux is so far ahead of the competition in many ways, yet also so far behind.
<ohsix> big number changes imply a lot of change, takes time; most of the bluetooth work is use driven, and people are trying to get audio and stuff for phones/in vehicle entertainment work a bit better in the transition
<[Ch4m3l30n]> Yes; I agree.
#ubuntu-kernel 2014-07-21
 * shengyao 
 * shengyao aaaa
 * shengyao å¥æ¯AMEé¿
<rtg> stgraber, you have an action item: https://lists.ubuntu.com/archives/kernel-team/2014-July/046332.html
<stgraber> rtg: any chance you can build me a kernel with that? I'm away and on my laptop so it'd take me 4-5 hours to test build with that patch...
<rtg> stgraber, gimme a bit
<rtg> stgraber, amd64 OK ?
<stgraber> rtg: yep
<rtg> stgraber, http://kernel.ubuntu.com/~rtg/3.13.0-33-lp1344049/
<stgraber> rtg: thanks, downloading now, should have results in 15min or so
<stgraber> or maybe in just a minute, I'm really not used to that 250Mb/s internet I've got here :)
<rtg> stgraber, please reply on the email thread. I'm gonna relocate shortly (which means I'm dropping off IRC)
<stgraber> ok, will do
<stgraber> rtg: works fine
<rtg> stgraber, cool
<stgraber> rtg: and I apparently deleted the ML thread so having a hard time replying to it :)
<rtg> stgraber, I'll do it
<stgraber> rtg: thanks!
#ubuntu-kernel 2014-07-22
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 29th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<hallyn> jsalisbury: is medium really the right priority for bug 1341364 ?  It basically makes cleanup of cgroups impossible.
<hallyn> (if you think it is, that's fine;  just checking for rationale)
<jsalisbury> hallyn, Medium is just the default.  I'll bump it to high, but it should be fixed now in Utopic, since we rebased to 3.16-rc6.  I'll ask for testing in the bug report.
<hallyn> jsalisbury: cool, thanks.  
<jsalisbury> hallyn, np.  bug updated.
#ubuntu-kernel 2014-07-23
<ZaggeO> does anyone know what is the reason that xhci_hcd is compiled into the kernel and is not as a module
<mlankhorst> why is it important to you?
<ZaggeO> mlankhorst: it sometimes blocks suspend of the kernel and without being a module I can't unload to make suspend work
<apw> ZaggeO_, iirc they are compiled in else you cannot ensure that usb3 things are found by that first
<ZaggeO_> apw: what might not be found?
<ZaggeO_> apw: you mean during bootup or in general?
<apw> in general
<apw> i believe
<apw> as i think usb2 can be loaded in responce to a device, then it will always take everything
<apw> and so usb3 is never loaded, something like that
<ZaggeO_> apw: it is a module on my debian machines and it works without problems there. It used to be a module on ubuntu too some releases ago
<apw> indeed, and we changed it because it was an issue
<ZaggeO_> since then I have the issue that my kernel sometimes no longer suspends and I need to reboot
<ZaggeO_> and quite often I don't notice it and then the battery runs out in my backpack and when I want to use it again it is empty
<ZaggeO_> apw: is there a different stock kernel one could use without the need to compile my own kernel?
<apw> all our stock kernels have essentially the same config
<apw> you should file a bug for it, perhaps it can be fixed the suspend issue
<ZaggeO_> apw: what kind of infos should I attach to the bug report?
<apw> everything you said above at least
<hallyn> sforshee: hey, so tried out fuse-ext2 in a container.  Created loopback on host with ext2;  created /dev/loop0 in container;  used fuse-ext2 to mount htat.  could only mount read-only.  is that expected?  (I assume so, but am not sure based on your intro email why)
<sforshee> hallyn: you have to supply -oforce with fuseext2 to get a rw mount
<sforshee> hallyn: also you don't have to mess with loop if you don't want to, you can give it the name of an fs image file
<hallyn> sforshee: thanks
<hallyn> think i'll set up some package builds in and out of that fs and see how the timings compare
<hallyn> sforshee: smoser: wow, completely naive test (timing building of lxc package exactly once) shows fuse-ext2 being faster than the container's native ext4
<hallyn> I suspect ocne I start some page cache clearing that'll change,
<hallyn> but still that completely belies smoser's argument that fuse can't be good enough :)
<smoser> you dont think that runnning all reads and writes through user space is faster than the kernel ?
<smoser> if it turns out that ext4 via fuse is as fast as in-kernel ext4
<smoser> then... um... that is really bad.
<smoser> embarrassingly bad from the kernel ext4 perspective
<hallyn> well i didn't compare to a *real* fs :)
<sforshee> hallyn: that's interesting, I wonder if that will hold over multiple test runs
<sforshee> and if it does I'd really like to know why
<hallyn> sforshee: multiple runs, probably.  I'm guessing the data never even hit disk
<sforshee> hallyn: it would be more apples to apples to compare ext2 in kernel to ext2 in fuse
<hallyn> so bigger runs, where i start swapping page cache, will probably get a hit
<hallyn> sforshee: i thought fuse-ext2 was actually doing ext4
<sforshee> hallyn: possible, but would it have hit disk in the normal case? I assume you were using loop.
<hallyn> Yeah, using loop
<hallyn> for the fuse fs
<sforshee> I don't think fuse has any driver for ext4. afaik fuseext2 supports ext2 and ext3 only
<hallyn> and no, it wouldn't have hit disk in normal case either - which is the confusing part.  
<hallyn> hm
<hallyn> well ext4 is supposed to be way faster no? :)
<sforshee> dunno, there's definitely more complexity
<hallyn> anyway i wasnt out to do a *good* comparison this morning;  i only wanted a "this isn't completely unusable" comparison
<sforshee> I wonder if cking has any benchmarks for ext2 vs ext4
 * hallyn waits for smoser to more explicitly suggest that we should all be using microkernels
<sforshee> though these days we're using the ext4 driver even for ext2
<cking> sforshee, nope, but I can add them to the mix
<smoser> yeah, its caching.
<smoser> same reason that loop is faster than direct sometimes :)
<smoser> thats the only thing i could figure.
<sforshee> smoser: but I think both cases should be cached, that's why I'm confused
<sforshee> we'
<sforshee> we'll just wait and see what further testing shows I guess
<cking> smoser, maybe metadata writes are being cached more when on the loop
<smoser> i never understood that.
<sforshee> cking: not more than when going through fuse I suspect
<smoser> but lots of times people report loop being faster than non-loop
<smoser> oh. well. i thikn that 'fsync' doesnt actually fsync
<smoser> through loop
<smoser> is that the case ?
<cking> smoser, the "advantage" of more dirty pages being cached and that extra layer may give some advantage I guess
<smoser> i sweare i read that once. that loop devices had no fsync. but i'm clearly in over my head here :)
<sforshee> smoser: I don't know for sure, but I'd guess that it only syncs to the backing file and not all the way through to the disk
<smoser> right.
<smoser> thats what i had thought.
<smoser> which would mean a spinning disk would be slower when the fsync was actually forced to go to it.
<sforshee> right
<cking> i guess we can speculate to the cows come home, whereas using perf may tell us what's actually happening
<ev> arges: hi. Would you be able to help me find out if nested kvm is something you guys are willing to support? Running the Touch emulator on Canonistack gives me unhappy results: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1347737
<ubot5> Launchpad bug 1347737 in linux (Ubuntu) "Kernel nested kvm support" [Undecided,New]
<arges> ev: hi, taking a look. nested KVM should work, but there are some hardware dependent issues that can occur
<ev> in that case, let me get you some more details on the VM
<ev> or do you mean the compute node's hardware?
<arges> ev: well both will be relevant
<ev> presumably the latter :)
<ev> ah, right
<arges> ev: so what is a bit confusing is that you are running on i386, but the VM is ARM arch? are you emulating?
 * ev bangs his head on the desk
<ev> let's try this with x86 on x86, shall we
<arges> ev: : )
<xnox> why shan't we ;-)
<xevious> Will dmsetup remove flush any buffers for the device prior to removing it, or should sync be run manually? If I do need to sync manually, would `blockdev --flushbufs /dev/mapper/name` accomplish what I need? For reference, I'm concerned because of this: http://www.redhat.com/archives/dm-devel/2012-January/msg00082.html Has this been patched in recent versions of Device Mapper? If so, which version?
<Hauke> apw: I created a bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1347879
<ubot5> Launchpad bug 1347879 in linux (Ubuntu) "Compile problem with external module and 031600rc5" [Undecided,New]
<rtg> Hauke, I'm about EOD, but I'll look at it in the AM
<Hauke> rtg:  thanks
#ubuntu-kernel 2014-07-24
<Guest95490> I'm a noob. Can I install linux-headers-3.11.0-19-generic  on Ubuntu 14.04?
<Guest95490> anyone?
<sargas> can I install linux-headers-3.11.0-19-generic  on Ubuntu 14.04?
<RAOF> sargas: Yes
<RAOF> sargas: But it won't be in the 14.04 repositories, so you'd need to download it manually.
<sargas> RAOF: Thanks
<sargas> RAOF: I am running 14.04 on the Acer C720 Chromebook
<sargas> RAOF: Trying to get it to suspend properly
<sargas> RAOF: I think kernel 3.11.0 will do the job
<xevious> Will dmsetup remove flush any buffers for the device prior to removing it, or should sync be run manually? If I do need to sync manually, would `blockdev --flushbufs /dev/mapper/name` accomplish what I need? For reference, I'm concerned because of this: http://www.redhat.com/archives/dm-devel/2012-January/msg00082.html Has this been patched in recent versions of Device Mapper? If so, which version?
<mnaser> I finally found the reason why I was having issues (bug).  It is reported as fix committed.  How often / when does Ubuntu make releases?  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1346917
<ubot5> Launchpad bug 1346917 in linux (Ubuntu Trusty) "Using KSM on NUMA capable machines can cause KVM guest performance and stability issues" [High,Fix committed]
<brendand> mnaser, should be in the next SRU'ed kernel
<mnaser> brendand: hate to sound impatient but im going on disabling ksm on a ton of machines, is there a schedule when that kernel goes out or is it based on kernel team's decision "we're due for an update"
<brendand> mnaser, no there is a regular cycle
<brendand> mnaser, every 3 weeks
<mnaser> ah, gotcha
<brendand> mnaser, looks like we're at the start of that
<mnaser> brendand: that's good enough for me to have an idea :)
<brendand> mnaser, so not longer than 3 weeks, but not much shorter it looks like
<mnaser> brendand: it's alright, i can live with disabling ksm until then... thank you so much
#ubuntu-kernel 2014-07-25
<bjf> mnaser, are you still there?
<mnaser> yes hi bjf 
<bjf> mnaser, yeah that one is hitting us hard
<mnaser> bjf: http://puu.sh/apMOE/81afd2ddc9.png
<mnaser> guess when i turned it off..
<bjf> mnaser, here's the deal. we should be releasing 14.04.1 today and 12.04.5 on aug. 7
<bjf> mnaser, we will have a kernel with the ksm fix built and ready to be released to updates on aug. 8
<mnaser> bjf: that sounds awesome to hear, i'm on 12.04 with trusty lts enablement kernel
<mnaser> so i'll be looking forward for that
<bjf> mnaser, ok, we'll roll that out on the same day
<bjf> mnaser, check with me next week. it might be in -proposed
<mnaser> bjf: thank you so much for this, i will do so, i'm subscribed to the bug as well
<mnaser> feel free to ping anytime here
<bjf> mnaser, my plan right now is to upload it on tuesday
<bjf> mnaser, it will take a little to work through the system and we can't impact the .5 release
<mnaser> i understand that, disabling ksm was a life saver (not that much of a dependency on it)
<mnaser> so i can live with it until then
<bjf> ack
<mnaser> anyways, gotta head out to gym, thanks for your time and info bjf :-)
<bjf> np
<pcarrier> hi! I can't fetch from git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git: "fatal: remote error: access denied or repository not exported: /ubuntu/ubuntu-quantal.git"
<pcarrier> any idea?
<TJ-> pcarrier: yes; it has moved to the archive since it is EOL
<pcarrier> TJ-: thanks! for reference, ubuntu-archive/ instead of ubuntu/
<TJ-> pcarrier: Indeed :)
<diwic> hi,
<diwic> is there a macro like KERNEL_VERSION() that also includes the ubuntu version?
<diwic> e g, if I want different code for 3.13.0-24 and 3.13.0-32
<apw> diwic, in recent kernels there is an UBUNTU_something_ABI
<diwic> apw, okay, so I'm looking for something like LINUX_VERSION_CODE >= KERNEL_VERSION(3.13.0-24)
<diwic> or -30 in this case
<diwic> apw, can one do comparison >= on the UBUNTU_something_ABI symbol?
<apw> diwic, it is just hte 24 in that case
<apw> i guess one could do like 
<apw> (LINUX_VERSION_CODE * 1000) + UBUNTU_SOMETHING_ABI >= KERNLE_VERSION(3.13.0) * 1000 + 24
<ogra_> thats a french kernel ... 
<ogra_> kern le 
<ogra_> :)
<diwic> le kern
<apw> it is indeed
<brendand> 'kern. le version 3.13'
<diwic> apw, hmm, what's "something"? I thought it resolved to the version, like UBUNTU_24_ABI or something.
<apw> #define UTS_UBUNTU_RELEASE_ABI $(abinum)
<apw> no it is that
<apw> i think you want like:
<apw> #define UBUNTU_VERSION(a,b,c,d) ((KERNEL_VERSION((a),(b),(c)) * 1000) + (d))
<apw> and use that
<apw> and if you paired that with
<apw> #ifndef UTS_UBUNTU_RELEASE_ABI
<apw> #define UTS_UBUNTU_RELEASE_ABI 0
<apw> #endif
<apw> you could use it with normal code too
<apw> normal versions
<diwic> apw, ok, thanks!
<apw> plus
<apw> #define UBUNTU_VERSION_CODE ((KERNEL_VERSION_CODE * 1000) + UTS_UBUNTU_RELEASE_ABI)
<apw> and i think you would have a winner
<apw> it is possible some of these should come with the kernel as it were
<diwic> yup, sounds like a nice improvement indeed if UBUNTU_VERSION and UBUNTU_VERSION_CODE were already there
<apw> i'll poke rtg about it when he wakens
<xevious> Will dmsetup remove flush any buffers for the device prior to removing it, or should sync be run manually? If I do need to sync manually, would `blockdev --flushbufs /dev/mapper/name` accomplish what I need? For reference, I'm concerned because of this: http://www.redhat.com/archives/dm-devel/2012-January/msg00082.html Has this been patched in recent versions of Device Mapper? If so, which version?
<YoungSoo> hello
<ProfessorKaos64> I saw the report that kernel 3.13.0-32 was released, but when I go to upgrade, it is held back. Is there a dependency I am missing?
#ubuntu-kernel 2014-07-27
<snadge> i want to debug an issue with nkey usb keyboards.. which looks to be an issue with the kernel.. how does one enable hid debugging ?
#ubuntu-kernel 2015-07-20
<jtaylor> hi, 497b4050e0eacd4c7 should be a good candidate to add to the kernel packages, issue applies down until at least 3.13
<rtg> jtaylor, it is Cc stable, so should trickle down organically
<apw> that
<jtaylor> ok good, I'll wait then :)
<rtg> apw, bug #1453117 - seems CONFIG_ACORN_PARTITION_CUMANA got set in Utopic
<ubot5> bug 1453117 in linux (Ubuntu) "Partitions not recognized because of kernel option CONFIG_ACORN_PARTITION_CUMANA" [High,Confirmed] https://launchpad.net/bugs/1453117
<apw> lovely
<rtg> any memory of why ? I certainly don't have one
<apw> isn't U out of support like ... today
 * apw waits for the bug to appear, come on LP
<rtg> apw, indeed, but V still has it
<apw> but indeed it does seem that it would be neiche at best to want that on
<apw> i do wonder why it would matter, but i am sure we can turn off the entire ACORN_* family if any are on
<apw> there is a group of the iirc
<rtg> apw, yup, so I'm gonna write an SRU patch to disable it
<apw> ack
<rtg> likely needs an annotation as well
<apw> i would like to know why it matters, do they have the same on disk signature as something else i wonder
<rtg> apw, looks like a false positive when detecting the super block
<rtg> apw, I wonder about the rest of the ACORN partition types ?
<apw> rtg, i can see no reason to have any of them really
<rtg> apw, I'm good with that
<rtg> apw, hmm, not to be confused with the Acorn SCSI card
<rtg> apw, oops - bug #1475662
<ubot5> bug 1475662 in linux (Ubuntu) "Kernel postrm calls /etc/kernel/postinst.d/*" [Undecided,Confirmed] https://launchpad.net/bugs/1475662
<apw> rtg, no that is just extra, and that is correct
<apw> that is because once you remove -extra you now have a fully installed slim kernel and we need to
<apw> do whatever one would want to do for that, ie rebuild initrd with only the slim kernel bits etc
<rtg> apw, k, makes sense
<apw> the real fix for _their_ issue is the use of triggers for things like grub etc which delays it, which
<apw> i have some prototype patches for lying about somewhere
<rtg> apw, not sure it is worth bending over for a benign DKMS issue
<apw> i've written something in it
<rtg> apw, I set it invalid
<rtg> apw, are you still looking at bug #1475078 ?
<ubot5> bug 1475078 in linux (Ubuntu) "VirtIO (and probably other modules as well) is built-in, make it modular..." [Wishlist,Confirmed] https://launchpad.net/bugs/1475078
<apw> rtg, thats on my backlog yes
<rtg> k
<cristian_c> jsalisbury: hi
<jsalisbury> cristian_c, hi, I don't have a new update on the bug as of yet.  I should soon.
<cristian_c> jsalisbury: ok
#ubuntu-kernel 2015-07-21
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 28st, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 28th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
<unixabg> apw: greetings, any updates of overlayfs and casper?
<kees> w/in 50
<kees> yay
#ubuntu-kernel 2015-07-22
<smb> ppisati, Is any Arm we care about caring about acorn partition type? Just asking because I am looking at that SRU patch that wants to disable it for V and W. Personally I would not miss that type, I guess.
<ppisati> smb: acorn is dead in the water, no one cares about it
<smb> ppisati, Ok, cool. cheers
<ppisati> smb: except for people who had/still have an acorn system and want to move their data around
<smb> I guess we will then hear from them sooner or later. Likely later when things move out of proposed. :-P
<rtg> jsalisbury, could you build a test kernel for bug #1471029 with b51621abbcb4694b8d2842ce3a66006a60bba6e5 reverted in Vivid ?
<ubot5> bug 1471029 in libxslt (Ubuntu) "ELF programs with R_386_RELATIVE blocks are badly mapped into memory" [Undecided,Triaged] https://launchpad.net/bugs/1471029
<pkern> Hi. Could someone nominate https://bugs.launchpad.net/fedora/+bug/1124250 for Precise?
<ubot5> Ubuntu bug 1124250 in linux (Ubuntu Utopic) "Partially incorrect uid mapping with nfs4/idmapd/ldap-auth" [Low,Fix released]
<infinity> pkern: Some of the comments claim 3.2 is fine...
<rtg> infinity, was just reading the comments after the fix was supposedly implemented. it doesn' look like the patch fixed their problem
<infinity> Oh.  And it seems to mention userspace issues.
<rtg> might get arges and chiluk to have another look
<infinity> Probably needs someone to sort out what package the bug is actually in before opening tasks willy-nilly.
<rtg> yep
<chiluk> rtg sorry switched machines and lost backscrolll what bug are we talking about?
<infinity> chiluk: LP: #1124250
<ubot5> Launchpad bug 1124250 in linux (Ubuntu Utopic) "Partially incorrect uid mapping with nfs4/idmapd/ldap-auth" [Low,Fix released] https://launchpad.net/bugs/1124250
<rtg> jsalisbury, did you see my note about bug #1471029 ?
<ubot5> bug 1471029 in libxslt (Ubuntu) "ELF programs with R_386_RELATIVE blocks are badly mapped into memory" [Undecided,Triaged] https://launchpad.net/bugs/1471029
<chiluk> infinity, rtg .. dgadomski is on vacation till Monday iirc.
<chiluk> I wouldn't pull the patch until he has a chance to weigh in on it.
<chiluk> iirc there were two separate keys stores depending on the security protocols, but I could be recalling that wrong.  He may have only fixed one of them.
<rtg> chiwill you make sure it gets on his TODO list ?
<rtg> chiluk, will*
<jsalisbury> rtg, I'll take a look now
<jsalisbury> rtg, I don't see a note in the bug, where can I find it?
<pkern> infinity: You are right. It should be a task for linux-lts-trusty on precise.
<infinity> chiluk: ^
<pkern> infinity: That or the userland. But I suppose it's hard to support both.
<rtg> jsalisbury, in the scroll back for this channel. I asked if you could revert b51621abbcb4694b8d2842ce3a66006a60bba6e5 and build a test kernel
<pkern> infinity: Unless the kernel tries to be compatible.
<pkern> marga: ^^
<rtg> jsalisbury, you might end up having to revert a couple of patches
<jsalisbury> rtg, sorry I must have missed it. Had to reboot a few times today.  I'll build the test kernel
<rtg> jsalisbury, thanks
<infinity> pkern: If you guys can figure out what you think the correct behaviour for both 3.2+userland and 3.13+userland on precise should be, that might help chiluk's team sort out WTF actually needs fixing. ;)
<infinity> pkern: I'm not sure I have an opinion on the matter, other than "it should probably work".
<chiluk> infinity, I haven't looked at that issue for months.. and even then I didn't look at it too thoroughly
<marga> infinity, the problem happens with the -lts-trusty kernel
<marga> on precise.  That is a supported usecase, right?
<infinity> marga: Right, so then the question becomes "should the lts-trusty kernel attempt to be compatible with the precise userspace, or should the precise userspace be made compatible with both 3.2 and 3.13?"
<infinity> I guess the end result is the same, but whee.
<marga> maybe we can have -lts userspace?
<infinity> marga: Absolutely a supported usecase, yes.  Just need to sort out the facts of the situation and then how to solve it.
<marga> like with xserver-xorg
<infinity> Forking lts-foo userspace stuff should be a last resort thing.
<infinity> The reason it's done for X is the same as for the kernel: to get more hardware support.
<infinity> For other userspace bits, we should either be making the kernel side or the userspace side compatible, not introducing new packages no one will find on their own.
<infinity> (ie: we could ship nfs-utils-lts-trusty or whatever, but who would know it existed and install it?)
<marga> I was not able to get it to renew the keys as it's supposed to do. Installing keyutils, libkeyutils, libnfsidmap from trusty + copying /usr/sbin/nfsidmap & /etc/request.keys.d/* from nfs-common from trusty, made the keys become permanent.
<marga> I'm not sure if I can provide anything else that helps
<infinity> marga: Kay.  The bug is a bit of a mess.  Can you try to clarify in a comment which combinations of userspace+kernel do work, and which combinations don't, and hopefully chiluk's minions can go from there to try to figure out which side should be fixed to be compatible.
<infinity> ie: if precise + 3.2 works, trusty + 3.13 works, and precise + 3.13 doesn't, or whatever.
<infinity> Which is, I think, what you just said.
<marga> Yeah. Although I don't know for sure if trusty + 3.13 leads to permanent keys or renewed keys
<marga> But I'll clarify in the bug
<infinity> Ta.
<jsalisbury> rtg, it appears bug 1471029 is fixed in mainline 4.2-rc3.  I tried a revert of a87938b2 in Wily and Utopic, but the revert requires a backport.  Do you thinks its better to backport the revert or work with the bug reporter to perform a reverse bisect and find the upstream fix?  Or I guess I can do both in parallel.
<ubot5> bug 1471029 in linux (Ubuntu) "ELF programs with R_386_RELATIVE blocks are badly mapped into memory" [Medium,Triaged] https://launchpad.net/bugs/1471029
<infinity> bjf: ^-- This probably points to a need for more extensive and creative userspace testing, too.  If we can figure out without a bug report that userspace nfs or cifs or whatever bits don't work with an LTS backport (or even a new non-lts-backport), that would be nice.
<infinity> bjf: Sounds like something cking would be all over if you mentioned it in casual conversation. :P
<cking> i didn't hear that
<infinity> cking: Heh.  Aren't you usually EOD and offline by now?
<cking> infinity, possibly.. actually just faffing with some packaging while I'm entertaining my kids
<rtg> jsalisbury, it could be a combination of patches, including the 2 that we've already applied.
<jsalisbury> rtg, got it.  I'll dig into it deeper
<cking> infinity, bjf, I don't mind looking at that tomorrow at some point
<bjf> cking, it's all yours
<cking> ta
#ubuntu-kernel 2015-07-23
<Laney> Anyone know what changed in cloud images to make 'scsi_debug' go away? https://jenkins.qa.ubuntu.com/view/Wily/view/AutoPkgTest/job/wily-adt-udisks2/ARCH=amd64,label=adt/48/console
<Laney> It's in -extra- but that's not installed
<apw> Laney, not of the top of my head, its not something i recall being done deliberatly
<apw> perhaps it got split out or something
<apw> Laney, i can see no reason it would not have also been in linux-image-extra-* in vivid also
<apw> the inclusion list is not different in scsi space, hmmm
<Laney> apw: just booting a vivid instance to check
<apw> Laney, and indeed in the latest vivid linux-image-extra-* it is in there too
<Laney> but it is there in vivid
<apw> ?
<Laney> and the cloud manifests of vivid vs wily look the same
<apw> well that file is in linux-image-extras-* so that is confusing
<apw> ask dpkg what installed it
<Laney> there -> in -extra-
<apw> ahh ... well ... erp
<apw> Laney, perhaps the tests have changed and would fail on vivid too
<Laney> I see cloud-init is downloading it
<Laney> OK, probably Not Your Problem. :)
<Laney> go deal with doko :P
<marga> infinity, I've added more data to https://bugs.launchpad.net/fedora/+bug/1124250 (I don't understand why this says fedora in the URL, it's marked as affecting linux on trusty and utopic)
<ubot5> Ubuntu bug 1124250 in linux (Ubuntu Utopic) "Partially incorrect uid mapping with nfs4/idmapd/ldap-auth" [Low,Fix released]
<marga> chiluk, ^My last comment in that bug should show the current state.  It seems like the bug is not fixed for Trusty after all. I'm not sure if I can be of any other help :-/
<TJ-> I've just helped a Vivid amd64 user with a radeon GPU. The recent 3.19.0.23 update (from 3.19.0-22) has caused a regression causing a blank monitor. Cause is the default mode is 1920x1080@60.0 but that fails in the latest kernel, but 1920x1080@59.9 will work (monitor offers @50, @59.9, @60).  Looks like the (intel)drm and radeon patches could be the cause (bug #1460674)
<ubot5> bug 1460674 in linux (Ubuntu Vivid) "[i915_bpo] Rebase driver to 4.2~pre" [High,Fix released] https://launchpad.net/bugs/1460674
<apw> TJ-, i think we'll need to get some bisect action on that, but we'd need to original user for that, and a bug to work in
<TJ-> apw: I'm awaiting their bug report number
<apw> TJ-, great, jsalisbury one for the bisect machine me thinks
<apw> (coming soon from TJ- once he has the bug #)
<TJ-> bug #1477587
<ubot5> bug 1477587 in linux (Ubuntu) "One black screen of two when both on 1080p60" [High,Confirmed] https://launchpad.net/bugs/1477587
<Sarvatt> TJ-, apw: updated that bug, some upstream stable reverts for radeon that came in that stable release update, its not related to the i915_bpo stuff
<Sarvatt> err, we got some radeon stable updates in the regressing kernel that were reverted in other stable releases i mean
<Sarvatt> most likely that :D
<jsalisbury> apw, ack
<jsalisbury> Sarvatt, thanks for updating the bug
<TJ-> Sarvatt: the radeon change mentions the Turks GPU, I noticed. The reason I mentioned the (intel)frm was I saw a specific drm/atmoic CRTC patch
<TJ-> s/frm/drm/
<Sarvatt> https://bugzilla.kernel.org/show_bug.cgi?id=99651
<ubot5> bugzilla.kernel.org bug 99651 in Video(DRI - non Intel) "third monitor connected via dvi does not work on radeonhd 7770" [High,New]
<TJ-> Those 2 mentioned commits aren't in the vivid release though, are they? "git describe --all --contains a10f0df0615  ==> tags/cod/tip/drm-intel-nightly/2015-05-29~6^2~1^2~2"
<Sarvatt> they're in v3.19.8-ckt3, current vivid kernel is based on the v3.19.8-ckt2 stable release
<TJ-> Maybe I'm misunderstanding then, but as I read the bugzilla report those 2 commits need reverting to fix that issue... whereas our user has a kernel without those commits so in theory our issue is something different?
<apw> jsalisbury, sounds like we need confirmation of the version in the bug and confirming if those two are in it or not
<TJ-> Our user does have an HDMI+audio, DVI-D though, so the configuration is similar
<TJ-> apw: The affected version is -23, and the working version is -22 ... kernel upgrade today initiated the problem
<Sarvatt> http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/drivers/gpu/drm/radeon?id=5385d2affc40d9a4f465ebd4dc3c1e6e0b6c1b0f different sha1 in the ubuntu repo
<Sarvatt> The good kernel version was linux_3.19.0-21.21.
<Sarvatt> This Problem occurred in kernel linux_3.19.0-22.22 and linux_3.19.0-23.24.
<TJ-> apw: In fact, the info the reporter gives as to kernel versions doesn't seem to match what I was told (see above for what I was told)
<jsalisbury> apw, ProcVersionSignature: Ubuntu 3.19.0-23.24-generic 3.19.8-ckt2  I can ask them to test: 3.19.8-ckt3
<apw> TJ-, thats not ... yeah that
<TJ-> I've attached the IRC log for clarity
<jsalisbury> apw, Sarvatt I see only one of those commits was added in 3.19.0-22: 
<jsalisbury> http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linux-3.19.y&id=bdb01a9532b5a985631d04aefc10e0a421284f28
<apw> jsalisbury, does the other get reverted in -ckt3 by any chance
<jsalisbury> apw, I'll take a look
<jsalisbury> apw, looks like it does:
<jsalisbury> bde11f3 Revert "drm/radeon: don't share plls if monitors differ in audio support"
<Sarvatt> http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y&ofs=250 about 20 down
<jsalisbury> git describe --contains bde11f3
<jsalisbury> v3.19.8-ckt3~20
<jsalisbury> Sarvatt, :-)  good timing
<apw> jsalisbury, ok so the next update should have it, so ... i'd say ram that commit on a test kernel for them
<apw> and confirm that that is enough to make them right again
<TJ-> I love it when it's simple :)
<jsalisbury> apw, what's strange is I don't see the original commit in Vivid that should be reverted.  
<jsalisbury> 52dfc11 drm/radeon: don't share plls if monitors differ in audio support
<jsalisbury> It looks like it was never added
<apw> jsalisbury, well it must be no, else it couldn't revert off
<jsalisbury> apw, hmm, I can't find it with 'git log' or in the changelog, but a git revert on a Vivid tree using the upstream SHA1 does work
<Sarvatt> are there any automated vivid master-next builds in a ppa somewhere?
<apw> Sarvatt, yep in the ~ubuntu-kernel-test ppa pre-proposed in theory
<jsalisbury> apw, Sarvatt I looked directly at the source and mainline commit a10f0df0615 was never applied to Vivid.  So the revert(Mainline commit  6fb3c025) won't do anything. 
<apw> jsalisbury, or it might do somethig bad like readd it, what does the commit actually contain in stable
<apw> as you can't easily commit a null commit
<henrix> jsalisbury: looks like that commit is only in vivid master-next branch, so there was never a kernel released with it
<henrix> actually, both the commit *and* the revert are in master-next, which is kind of pointless... :-)
<jsalisbury> apw, so maybe a revert of ebb9bf18 is all that is needed, which is comming in 3.19.8-ckt3.  I can build a vivid test kernel with just that change
<TJ-> My reading of it was the user *needs* the commit that splits PLLs when one output has HDMI, as is the case
<TJ-> s/HDMI/HDMI + audio/
<rtg> apw, infinity, I uploaded blktap-dmks to https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa if you'd like to have a look
<infinity> rtg: That seems nice and simple.  If it fixes it, yay.  And we'll also want that SRUed to trusty (for lts-w/lts-x kernels)
<rtg> infinity, oh, hadn't thought about the SRU. Guess I'll do that too.
 * infinity wonders why that doesn't build for arm64...
<infinity> Oh.  It probably should.
<rtg> infinity, in the meantime, would you pocket copy to wily for me when it is done building ?
<infinity> rtg: While you're in there, want to s/i386 amd64 armhf powerpc ppc64el/linux-any/ on the Arch list so we don't have to keep adding arches for every new port? :P
<rtg> infinity, then just upload directly to the archive ?
<infinity> rtg: Yeah.
<infinity> rtg: And happy if both those changes get SRUed.  The Arch list change in trusty will just magically make some packages installable, which won't hurt my feelings.
<rtg> infinity, uploaded blktap-dkms to trusty, bug #1477718
<ubot5> bug 1477718 in blktap-dkms (Ubuntu Trusty) "blktap-dkms FTBS on kernels >= 4.1" [Undecided,In progress] https://launchpad.net/bugs/1477718
<infinity> rtg: That's a very confused version number you have there. ;)
<infinity> rtg: Oh, actually, looking at the debian changelog, we probably just want a backport of the wily version anyway.
<infinity> blktap-dkms (2.0.93-0.3) unstable; urgency=medium
<infinity>   * Add patch for compatability with kernel 3.14+
<rtg> infinity, do you just pocket copy that ?
<infinity> No.  Hold on.  Lemme look closer.
<infinity> rtg: Yeah.  We definitely want all the changes from trusty to wily.  Simplest would just be to take the wily source, tack ~14.04.1 to the version, and add the bug closure.
<rtg> infinity, I can do that. reject my upload ?
<infinity> rtg: Done.
<infinity> rtg: Looks like current trusty blktap is already broken with lts-u and lts-v because we never bothered to backport, so this'll fix those, plus lts-w.  Not bad for a few minutes' work.
<rtg> infinity, that is prolly an indicator of how many folks actually use this driver, i.e., almost nobody
<infinity> rtg: Or the intersection of people who use this driver and lts kernels.
<infinity> rtg: The vast majority of non-cloud server-type people I know tend to prefer the kernel we actually support for 5y.
<rtg> infinity, you'd better have a look before I upload this: http://people.canonical.com/~rtg/blktap-dkms/
<infinity> rtg: Fine, except that should be LP: not Bug:
<infinity> rtg: You know you got the bug closure wrong if you don't get a Launchpad-Bug-Fixed: stanza in your .changes
<rtg> infinity, it must only look at the first changelog entry
<infinity> rtg: Oh, it looks at all the changelog entries you tell it to.
<infinity> rtg: You want dpkg-genchanges -S -v$(last_trusty_version) > ../foo.changes
<infinity> rtg: Then you get a nice .changes with everything in it.
<rtg> ok, lemme update that
<infinity> rtg: So, good news, your wily upload fixed the autopkgtest failure at least.  Yay.
<infinity> rtg: Going to lift the block tag on your tracking bug and let your kernel in.
<rtg> infinity, just refreshed that changes file if you'd like to have another look
<infinity> rtg: Looks perfect, upload away.
<rtg> done
<rtg> now, what was I doing before all this ?
<infinity> rtg: Knowing your schedule, probably EODing?
<rtg> getting close :)
<rtg> looks like a great afternoon for some single tracking
#ubuntu-kernel 2015-07-24
<nusch> hello, my system stopped work after kernel upgrade, I thought i was always using UEFI secure boot but see old working kernel is named vmlinuz-3.13.0-55-generic and new has two variants vmlinuz-3.13.0-57-generic.efi.signed and vmlinuz-3.13.0-57-generic. New kernel gives panic at early boot related to no root partition. I'm using FDE, that requires module in initrd but update-initramfs doesn't help
<nusch> also my /etc/initramfs-tools/scripts/init-premount is empty, I have old backups where it's not but know those scripts are also in /usr/share/initramfs-tools location. What is proper setup allowing update-initramfs include all crypto and lvm modules?
<wyvern> Hi folks, I'm on ubuntu 15.04 and I need to use a newer kernel to avoid some usb3 bugs in 3.19. Ideally I'd use 4.1. How should I update my kernel?
#ubuntu-kernel 2016-07-25
<lorddoskias> do I need to add any other information to this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605843 in order for it to be considered complete ?
<ubot5> Launchpad bug 1605843 in linux (Ubuntu) "Kernel crashes from time to time when using ftrace " [Undecided,Confirmed]
#ubuntu-kernel 2016-07-26
<eanyx> hi, I would like to build some modules independately from building the whole kernel, but when I modprobe, the module say it's wrong signature (tainted kernel).
<eanyx> How to sign module at compilation time?
<apw> eanyx, you need to switch to your own keys to do that ... and use the same key in both
<eanyx> apw:thanks
<eanyx> apw: does ubuntu provide it's own key to certify their OS is not tainted?
<apw> eanyx, we generally only sign everything together currently
<eanyx> so does my own kernel will be supported by canonical?
<eanyx> apw: 11:50 PM here. time to go bed. thank you.
#ubuntu-kernel 2016-07-27
<djs> is there any reason the new 4.7.0 mainline kernel would not want to decrypt the rootfs on boot?
<djs> tried upgrading today but my disk is encrypted and 4.7.0 doesn't ask for a passphrase
<djs> ubuntu 14.04
<apw> djs, no known reason, the configs for those are generated from what is nearest so things can get lost
<apw> they are only test builds
<sforshee> smb: do you know if we still have utilities expecting xenbus to be mounted at /proc/xen?
<smb> sforshee, yeah I was asked the same just a couple of minutes ago
<sforshee> smb: oh, hah, I'm sure it's the same issue
<smb> its those xe-guest-utilities which mount it so the guest can fill some guest data into the xenstore of the host
<sforshee> smb: I just noted that there's a CONFIG_XEN_COMPAT_XENFS option which controls whether /proc/xen is created, and notes that it's for "old xenstore" tools
<smb> sforshee, I had a look into the startup script of dom0 and those still want /proc/xen. So I have afeeling its less legacy than it sounds
<sforshee> smb: ack, thanks
<xboy> Hi there!
 * apw looks up
<xboy> I was wondering if ubuntu 16.10 going to have the kernel 4.6 or above ?
<apw> xboy, yes, we have a 4.6 kernel pending now, which i hope to release when the freeze lifts for alpha2, 4.7 is being prepared
<xboy> great!
<xboy> I'm having trouble installing ubuntu 16.04 in a lenovo yoga 900, because of the nvme ssd, apw do you know if the kernel 4.6 have a good support for that kind of ssd?
<apw> xboy, depends what sort of nvme disk it is, i have heard peopel saying nvme "version 2" disks are a problem but i have not seen any evidence
<apw> xboy, does the disk even get recognised ?
<xboy> no, during installation process(live usb) the system does not recognize the disk 
<apw> xboy, how are you determining that, not offering a disk to install to ?
<apw> if you boot "Try Ubuntu" on it, and open a terminal, is the disk mentioned at all in dmesg
<xboy> apw it's a samsung mzvlv512hcjh
<apw> i can have a look at the dmesg if you can pastebinit or similar
<xboy> give a sec. going to see dmesg 
<apw> xboy, and indeed what does "sudo lswh -c disk" say
<xboy> ok, going to check
<xboy> almost ready
<xboy> here it's apw http://paste.ubuntu.com/21167215/
<xboy> dmesg output
<xboy> apw http://paste.ubuntu.com/21167520/ for the lshw command
<apw> xboy, and if you "sudo modprobe nvme" does anything appear in the bottom of dmesg /
<xboy> no, nothing apw
<xboy> do you know what can I do so the system can detect it?
<apw> xboy, at this moment, no. 
<xboy> do you know if the kernel 4.6 or 4.7 can help me apw?
<apw> xboy, i do not
<xboy> thank you apw!
<xboy> oh one more question apw, do you know who can help me? 
<apw> xboy, from what i can see you are not the only one complaining, and the issue seems to affect linux in gneeral
<apw> there is some discussion out there that suggests there may be something in bios, but not what
<xboy> ohh ok, I'm going to try to talk to samsung
<xboy> or where can I find a ubuntu live usb with a newer kernel(maybe that helps)?
<apw> there is no installer image yet with a newer kernel, there may well be by next week, but not now
<xboy> will wait then, thanks!
<apw> xboy, i believe there is some work looking into this going on somewhere, i just do not know who right now
<xboy> ok great, any idea where can I search?
<apw> this was something i heard spoken about ...
<xboy> oh ok
<apw> ogra_, which package were you seeing us pointing to /GPL ?  i have looked over the primary kernels and they all point to /GPL-2
<ogra_> apw, meta 
<ogra_> iirc
<xboy> Are you there apw?
<apw> ogra_, ahh yes, ok, thanks
<xboy> If I download the latest kernel from ubuntu mainline, where I can find the vmlinuz and initrd.lz?
<apw> xboy, the vmlinuz is in the linux-image-* the initrd is made when installed
<xboy> ok thanks
<attente> hi, how do i pass -no-pie when building the kernel? is there some env var i should set?
<djs> apw: any ideas on how I might debug the 4.7.0 mainline kernel's failure to ask for a passphrase to decrypt the rootfs on boot?
<djs> I assume the problem is in the initrd or initramfs-tools somewhere
#ubuntu-kernel 2016-07-28
<apw> djs, given the only thing you change is the kenrnel, that tends to indicate it is related to that rather doesn't it ?
<ddalex> hi
<ddalex> I'm getting errors with a ppa/mainline kernel
<ddalex> where should I report them ?
<ddalex> or, maybe, how ?
<apw> ddalex, those are debugging tools, so mostly not supported, we may be interested in some classes of issues as they may indicate issues coming down the line
<ddalex> apw, are these unmodified upstream kernels ? i.e. are the bug reports valid for bugzilla.kernel.org ?
<apw> they are unmodified indeed, they have an ubuntu-like configuration applied but otehr than that no changes
<apw> ddalex, so yes filing them upstream is not unreasonable
<ddalex> thanks, I'll fill upstream
<zyga> ogasawara: https://bugs.launchpad.net/snappy/+bug/1607344
<ubot5> Launchpad bug 1607344 in Snappy "snap gives confusing error messages if snap login was ran with sudo" [Undecided,New]
<ogasawara> zyga: thanks!
<attente> does building the kernel require editing the Makefiles to disable -pie? is there some easier way to pass cflags into the build system?
<apw> attente, which series are you building on, and which kernel are you trying to build.  depending on the combinations that can be true
<apw> attente, though there is a patch in recent ubuntu kernels for that
<attente> apw: building from git://kernel.ubuntu.com/ubuntu/ubuntu-yakkety.git
<attente> apw: it's the current master with a small patch on top
<attente> Ubuntu-4.4.0-22.40
<apw> attente, right but what are you building that _on_ as a local host, you should be building it in a
<apw> yakkety chroot, whcih wuold understand the pie bits
<apw> though -22 is very old, why that one of all of them, maybe that is too old to have the fix
<attente> apw: which branch is the development target?
<apw> for the 4.4 that is in the xenial repositories, we're working on 4.6 in the yakkety repo
<djs> apw: well, yes, the failure to decrypt the rootfs is definitely related to the kernel since that is the only thing changing
<djs> apw: I'm wondering whether it's a timing problem of some sort, I was poking through the initramfs-tools scripts a bit trying to see where it might be getting stuck
<djs> but so far no luck... booting with debug doesn't get me anywhere, the problem is earlier than that
<apw> djs, it was 4.7 you were trying out wasn't it
<djs> yeah
<apw> i would guess we have something useful turned off in that 4.7 build, like an encryption algo or something
<djs> yeah possibly... I was also looking over diffs between the 4.6.4 and 4.7.0 initrd and there definitely are some
<djs> so do those builds get refreshed from time to time or are they static?
<apw> builds are a one off, unless we find a clear config issue which gets fixed in our main branches, then i may chose to respin them
<djs> ok, so do you have any suggestions on how I ought to proceed? my interest in newer kernels is support for newer hardware in the laptop I'm running on
<djs> it's not too bad with 4.6.4 but I'm hoping a few issues will be fixed with 4.7
#ubuntu-kernel 2017-07-24
<AceLan> bjf: I have a question, for this bug https://bugs.launchpad.net/bugs/1705633 , I already submitted 2 patches for SRU, but now I found it requires another 2 commits, can you drop the 2 commits and I resend the 4 commits together(it'll make one "backported" commit to "cherry picked"), or I just create another new bug and submit the reset 2 commits?
<ubot5> Ubuntu bug 1705633 in linux (Ubuntu) "[8087:0a2b] Failed to load bluetooth firmware(might affect some other Intel bt devices)" [Undecided,In progress]
<apw> AceLan, the bigger question is where in the pipeline are the existing two and what is the status of a kernel carrying just those two
<apw> AceLan, to my naive looking they are not yet applied, so if they are just on the mailing list you can reply to your own thread and NACK it
<AceLan> apw: the "backported" commit will lead to another issue, I should not backport that way
<AceLan> apw: but it got 2 ack already
<AceLan> apw: can I still nack it?
<apw> AceLan, so NACK it ... that will override that ACKs, and as i say i canot see it applied
<apw> so it isn't in this cycle anyhow
<AceLan> apw: got it, thanks
<apw> we may not have started this cycle on xenial as there was a respin in play
<kerrn> Hey all, i need some help regarding writing a new transport protocol  as a kernel module. 
#ubuntu-kernel 2017-07-25
<android> !which kernel has 16.04.2
<ubot5> android: I am only a bot, please don't think I'm intelligent :)
<apw> android, the media would have had 4.8 i believe
<tjaalton> apw: is the current xenial sru cycle still on target (release on aug 7th)
<apw> tjaalton, as far as i know yes, why ?
<apw> we are somewhat backed up but we are catching up
<apw> we try not to slip release the candance even when we are slipping individual releases
<tjaalton> apw: there's a oneliner for i915 pciids that would like to get in if there's a respin, but not necessarily needs one just for this
<apw> tjaalton, if you get the patch to the list asap, i'll get it on the "if there is a respin" list
<apw> smb, ^
<tjaalton> sure
<apw> klebers, ^
<smb> yeah klebers. I pretend to know nutting bout anyting
<klebers> xenial cycle already started and for now it's kind of on track
<klebers> I will make sure we include it if we have a re-spin (given that it's sent to ML and ack'ed)
<apw> klebers, we have a column for that i tink
<klebers> apw, not on the sru board, but I will create it
<apw> klebers, oh yeah, wrong board, good plan
<android> doea the 4.4 ubuntu16 kernel have in kernel encryption certificates?
<apw> android, certificates for what ?
<android> anything this is a security audit, crypto needs to be capable of being switched off
<apw> the kernel almost cirtainly contains certificates to validate its own modules
<android> apw
<android> this is with conscern to networking
<android> say it is on a lan the ssl and any crypto is turned off is there anthing in kernelspace
<apw> all network related crypto is loaded from userspace, there are no default keys that i know of
<android> Is it better to go with fedora for lan?
<apw> does that question even make sense?
<android> ubuntu works great online
<android> better than any os except possibly windows
<android> for local business lan I need to be able to audit all com lines
<android> crypto makrs it not possible omline ssl comea from rsa
<apw> and if you don't support ssl you won't be able to talk to an increasing section of the internet
<android> and has evolved into a big blob of somebody elses authority
<android> yes apw I agree
<android> google is taking over
<apw> anyhow, the kernel does not do any encrypted communications itself, only on request from userspace
<apw> privacy is increasing is probabally a fairer statement
<android> no more dual booting
<android> screws everything up
<android> npw if I want to invite guests on my network can you make a page ise facebook for login?
<android> something fairly unbiquitis
<android> there are so many captuve portals now
<android> I do want to be kind to strangers
<apw> android, why not have a separate guest network (vlan whatever) and print the password on your wall
<android> let them access through my network without a oruvate password
<apw> have a private password which you give them, but have it easy to find when they are local
<android> the password is then not unique
<apw> indeed
<android> facebook is
<apw> i am sure you can do that if you wanted to, i have no knowledge in this space
<apw> recording people who come just means you have more data you need to keep safe
<apw> just don't let them on the bit you have to audit, keep it utterly separate
<apw> i even do that at my home
<patrik> Hi! I'm debugging a driver and expect it to dump to /sys/devices/virtual/devcoredump but "udevadm monitor" shows that kernel and udev adds and removes them. I've been researching enabling apport to handle it and even overriding the default "core_pattern" settings to avoid apport but I still can't capture it. In 1704. Any ideas?
<android> patrik what command do you run for this expectation?
<android> there is a debug option usually activated at boot with grub modesettings
<nomego> Hi, I'm debugging a kernel driver and is trying to make it device core dump, but udevadm monitor shows that it's getting deleted instantly. Any tips? I've tried enabling apport, setting ulimit -c, even overriding the core_pattern to avoid using apport but nothing seems to work. Something fundamental I've missed?
#ubuntu-kernel 2017-07-26
<nomego> Hi, I'm debugging a kernel driver and is trying to make it device core dump, but udevadm monitor shows that it's getting deleted instantly. Any tips? I've tried enabling apport, setting ulimit -c, even overriding the core_pattern to avoid using apport but nothing seems to work. Something fundamental I've missed?
<apw> nomego, kernel drivers do not produce userspace core dumps
<tjaalton> klebers: turns out that pciid patch does not fix the bug after all, test results were confusing :/
<tjaalton> i'd swlf-nack it if i could reply to it
<klebers> tjaalton, I can send the nack
<tjaalton> thx
<dsd> hi, just curious if any efforts have started to prepare an official ubuntu 4.12 kernel for artful (which i presume is the plan?)
<apw> dsd, yes, the are in fact already 4.12 and 4.13 branches in preparation
<dsd> apw: cool thanks, are they public?
<apw> dsd, i am sure they are somewhere ... /me defers to sforshee 
<dsd> apw: thanks, i spotted ubuntu/unstable.git
<apw> dsd, they may well both be in there, that would be logical
<sforshee> dsd: they are both in unstable, unstable/master is 4.12. I've pushed tags for 4.13 but haven't actually pushed that to a branch yet.
<nomego> Hi, I'm debugging a kernel driver and is trying to make it device core dump, but udevadm monitor shows that it's getting deleted instantly. Any tips? I've tried enabling apport, setting ulimit -c, even overriding the core_pattern to avoid using apport but nothing seems to work. Something fundamental I've missed?
<nomego> apw, I'm trying to follow https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#firmware_debugging to fix https://bugzilla.kernel.org/show_bug.cgi?id=196411
<ubot5> bugzilla.kernel.org bug 196411 in network-wireless "iwlwifi: 8265: Error sending STATISTICS_CMD: time out after 2000ms" [Normal,Needinfo]
#ubuntu-kernel 2017-07-27
<BigBangUDR> Hello all need help regarding kernel panic in 14.04 issue - http://imgur.com/a/3oKAQ
<apw> BigBangUDR, that looks to be 4.4.0-72.93 ... the latest updates kernel is 4.4.0-87.110 have you tried that ?
<BigBangUDR> I am new and not able to boot or get terminal
<apw> do you have any other kernels installed, i assume there was another before that one broke you
<apw> so as it crashed and did not boot, you should get a menu next time you boot
<apw> which lets you select other older kernels
<apw> i would recommend picking the previous one to this one if it is the latest installed
<BigBangUDR> Try all kernal options available in grub menu none worked all went to panic 
<BigBangUDR> even recovery mode
<apw> oh your init is broken
<apw> so yes all kernels will blow up, as it is simply sying "init exited"
<apw> so you could edit the command line and try adding 'init=/bin/sh' to the end and see if you get a prompt then
<apw> of course it will have root mounted read only etc
<BigBangUDR> apw: i have another ubuntu with multi hard disk support, can i mount and do something
<apw> i would try the init thing first
<apw> as you can remount it r/w and ask apt what the heck is up with init
<apw> as it looks like someone has removed libcap2 from teh system
<apw> from the error you have, which is a hard dependency of systemd
<apw> which is init in this context
<BigBangUDR> apw: i am real new to this kernal things dont have any idea what needs to be excuted there
<apw> i am saying select the latest kernel in grub, hit the e key to edit the entry
<apw> and then cursor down to the line with linux at the front, and add init=/bin/sh to the end of the line
<apw> then hit ctrl-x to execute it
<apw> https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter
<apw> if that doesn't panic we have some hope of being able to recover from this
<apw> is this is a server or desktop install ?
<BigBangUDR> apw: Okay this is server install
<apw> what was occuring when this started, as losing that file without systemd being removed
<apw> implies the actual file was removed without removing the package
<apw> so either someone with admin or a harward/software glitch that happened to remove/corrupt that file
<BigBangUDR> This is our node development in-house server, i monitor it
<BigBangUDR> we usually add and remove lots of programmes 
<BigBangUDR> am trying your init solutions
<apw> it isn't a solution, it is an attempt to get you to a point where you can repair this thing
<BigBangUDR> Yes 
<apw> it will not be up in any sense someone can use it from anywhere from the control
<apw> console
<BigBangUDR> apw: got the terminal
<apw> then you have some hope
<apw> then you need to make / writable
<BigBangUDR> how to do it?
<apw> note once you have done this you need to sync it manually at the end otherwise it might not be on disk
<apw> this is very important
<apw> mount -o remount,rw /
<apw> but remember you can make a huge poo mess of this if you do not sync it at the end
<apw> which you do in teh traditional way
<apw> sync;sync;sync
<apw> next we want to find out if you have libcap2 installed
<apw> dpkg -l | grep libpcap2
<apw> dpkg -l | grep libcap2
<BigBangUDR> mount not working
<apw> what does it say
<BigBangUDR> error while loading shared libraries : libblkid.so.1
<apw> does ls work ?
<BigBangUDR> lls
<BigBangUDR> yes
<apw> ls -l /lib/*/libcap.so.2
<apw> does that list any files ?
<apw> ls -l /lib/*/libcap.so.2*
<apw> and indeed does that
<BigBangUDR> no such file or directory
<apw> for both ?
<apw> ls /lib 
<apw> ?
<BigBangUDR> ls it display all libraries
<apw> dpkg -l | grep libcap2 
<apw> does that work ?
<BigBangUDR> yes it display some result like libcap2-bin and more
<apw> dpkg --verify libcap2
<apw> what does that say
<BigBangUDR> its saying ??5????? and a path
<apw> so you have lost that file, what path is it
<apw> approximatly is close enough
<apw> and what is the letter in the second column
<BigBangUDR> This is the path  /lib/x86_64linux-gnu/libcap.so.2.24
<apw> what does
<apw> and ls of that directory short
<apw> show
<apw> ie is there anything else in there, or are all of your arch specific libraries gone
<apw> as we know you are missing blkid already
<apw> ...
<apw> though regardless of that because you have lost your blkid library you are not going to be able
<BigBangUDR> yes right
<apw> to recover this from here easily as your disk is not converable to rw to fix
<apw> so normally in this situation i would make and boot from a usb stick
<apw> then mount up the root disk manually and chroot into it
<apw> and see if i could reinstall the packages which are clearly broken
<BigBangUDR> It throw the same error while boot from USB
<apw> that cannot be, as the usb stick has its own libraries
<apw> that sounds more like you are failing to boot the stick
<BigBangUDR> Okay I'll try one more time
<BigBangUDR> Hope it will work this time.
<apw> once you have mounted root, and chrooted into it
<apw> (remember to bind mount /sys and /proc into it)
<BigBangUDR> Okay
<apw> then you can try apt-get install --reinstall libcap2 libblkid1
<apw> and see if that works
<apw> of course you have little idea if anytyhing else got dammaged by whatever broke you
<BigBangUDR> Sure I go through it and try to recover it. 
<ogra_> are you sure thats not a failed disk in the raid ? 
<ogra_> (looks like there is a md raid in use)
<BigBangUDR> Yes
<apw> if there is any risk that you have lost a disk in your raid you ought to take a backup of course
<apw> well probabally you want to do that anyhow
<BigBangUDR> Right
<apw> ogra_, though as the disk has mounted clean i assume a disk loss would have had to have occured when the machine was not booted
<apw> not impossible of course
<BigBangUDR> Try to mount it with the help of another disk but it failed and dont show all data which is available earlier 
 * ogra_ would actually boot with break=bottom and inspect the raid from there (also gives you accurate logs, i guess any interesting errors are scrolled off screen anyway)
<BigBangUDR> Still throw the same error kernal error while boot from USB
<apw> what usb stick image are you booting
<apw> and is the output identicle
<BigBangUDR> Might be some problem with its version.  
<apw> whos version?
<BigBangUDR> version 16.04
<apw> those images are commonly used, so i doubt it
<apw> what kernel version is shown in that panic
<apw> when booting from usb
<ogra_> which image are you using(whats the download URL yu used)
<BigBangUDR> version 14
<ogra_> ??
<ogra_> thats not a url 
<ogra_> what exactly did you download for your usb stick
<ogra_> surely any imgaes you can download from releases.ubuntu.com will bot standalone
<ogra_> *boot
<apw> i asusme that is mean to be a kernel version, but its not one of those
<apw> if the panic looks similar, then is says "Kernel Panic -...."
<apw> and then two lines below on the right end of the CPU: 0 line it has a full kernel version/flavour/build number
<apw> it is that i am after
<BigBangUDR> https://www.ubuntu.com/download/desktop/thank-you?country=IN&version=16.04.2&architecture=amd64
<BigBangUDR> This is the url
<ogra_> how did you write it to the USB ?
<ogra_> and what is rthe exact error you see when booting from it then
 * apw boots that CD to find out what kernel is on it
<apw> BigBangUDR, what was that kernel version when booting USB, or upload a picture of that too
<BigBangUDR> kernal version is 4.053442
<apw> nope
<apw> that isn't a kernel version, they don't look like that
<apw> 4.11.0-11-generic #16-Ubuntu
<apw> they are shaped like that (from my machine here)
<apw> shaped like that in a panic output
<ogra_> 16.04 should have something like 4.4.0-*
<ogra_> (though that is 16.04.2 ... that probably already has the hwe kernel )
<BigBangUDR> Okay trying to chroot and bind 
<apw> managed to get the usb image booted ?
<BigBangUDR> yes
<BigBangUDR> chroot / right?
<apw> nope
<apw> you need to bind before you chroot
<apw> and then you chroot into wherever you mounted your real /
<apw> chroot /mnt /bin/bash
<apw> sort of thing
<BigBangUDR> have mounted the disk at /mnt/kw
<apw> then there
<apw> mount -o bind /sys /mnt/kw/sys
<apw> mount -o bind /proc /mnt/kw/proc
<apw> chroot /mnt/kw /bin/bash
<apw> and see if you can reinstall that libcap2 package
<apw> if you can, you may have some hope
<BigBangUDR> chroot: failed to run command â/bin/bashâ: Exec format error
<apw> try /bin/sh
<apw> is the installed image also amd64 ?
<BigBangUDR> chroot: failed to run command â/bin/shâ: Exec format error
<apw> what does "file /mnt/kw/bin/sh" say
<BigBangUDR>  /mnt/kw/bin/sh: symbolic link to `dash'
<apw> what does "file /mnt/kw/bin/dsh" say
<apw> what does "file /mnt/kw/bin/dash" say even
<BigBangUDR>  /mnt/kw/bin/dash: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=504637666875a5d526ef51acfe601c99efc99114, stripped
<ogra_> and you definitely downloaded ubuntu-16.04.2-desktop-amd64.iso ? are you sure it is not i386.iso ?
<ogra_> what does: uname -m
<ogra_> say ? 
<BigBangUDR> Ohh sorry my bad it says i686
<ogra_> i686 ? 
<BigBangUDR> yes
<ogra_> where does it say that 
<BigBangUDR> uname -m
<ogra_> apw, is that what we say on i386 installs ? 
 * ogra_ wou8ld have expected x86 ... like amd64 says x86_64
<apw> yes, that is what we say on i386, this amd64 box says x86_64
<ogra_> yeah, wrong iso then
<ogra_> http://releases.ubuntu.com/16.04.2/ubuntu-16.04.2-desktop-amd64.iso
<ogra_> try this image
<BigBangUDR> Okay let me download
<BigBangUDR> ogra_: corrupted one is server edition
<ogra_> there is no difference (apart from one shipping a desktop, they are the same underneath)
<ogra_> but feel free to grab the server iso from the above url instead
<BigBangUDR> Okay
 * apw assumes BigBangUDR succeeded
<BigBangUDR> apw not yet but in very good direction thanks to you
<BigBangUDR> repeating all i have learn from you.
<michael-vb> apw: Michael from the VirtualBox team here.  I was talking to LocutusOfBorg on #vbox-dev about how to deal with the VirtualBox kernel drivers (the host ones) and secure boot.
<michael-vb> He said I should talk to you and thought you might be have plan to include them in the Ubuntu kernel package.
<sforshee> michael-vb: we already have been including them in Ubuntu kernel packages for quite some time now
<michael-vb> The host ones?
<sforshee> oops, missed that part. No, not the host ones
<michael-vb> See for example LP 1574300.
<ubot5> Launchpad bug 1574300 in virtualbox (Ubuntu) "Could not load 'vboxdrv' after upgrade to Ubuntu 16.04" [High,Confirmed] https://launchpad.net/bugs/1574300
<michael-vb> And it applies to our upstream builds as well of course.
<sforshee> yeah, currently the only solutions are to disable secure boot or use install a mok which is used to sign dkms modules. I think cyphermox was planning to work on a user-friendly way to do the latter.
<cyphermox> working on it, I'm testing code at the moment
<michael-vb> Sounds interesting, any pointers?
<cyphermox> when the module gets built though, you should currently be getting a prompt to disable Secure Boot
<cyphermox> in other words, when you see the DKMS logs at package install (or upgrade), provided that you're in UEFI mode you should also be seeing a prompt come up to ask if you want to disable Secure Boot, and the pick a password -- you do want to do that
<michael-vb> We no longer use dkms upstream.  Not all distributions supported it, and using it for some but not all made no sense.
<LocutusOfBorg> I'm back with my flaky connection
<michael-vb> Just looked at mokutil.
<LocutusOfBorg> I didn't probably get the answer from kernel team :)
<michael-vb> mokutil seems to be the answer in short form.
<michael-vb> The long form might be, well, longer.
<michael-vb> sforshee, cyphermox: thanks.
<michael-vb> (I might be back some time...)
<cyphermox> michael-vb: AFAIK what dkms fails is at least on Fedora, but that's because AIUI they decided to not care
<cyphermox> fwiw, you can use update-secureboot-policy --disable to do the same, but a little more user-friendly maybe
<cyphermox> and soon this might be rendered moot, since you'll be able to sign the modules a bit more easily
<cyphermox> currently, you need to use mokutil & openssl to generate a key and enroll it, reboot, finish the enrollment, then use kmodsign to sign, if you manage to guess what parameters it wants :)
<socratis> cyphermox: michael-vb has left the building a couple of hours ago, but I could "deliver" your message... 
<cyphermox> socratis: thanks..
<cyphermox> sorry, I knew something was up when my tab-completion didn't work, but I never got a part/quit message here
<socratis> :D
<socratis> I just happened to follow michael from the #vbox-dev channel, just to see where the conversation was going, and I ... stayed ;)
<socratis> Anyway, if I see him tomorrow, I'll paas it along. Just out of curiosity, you mentioned that the self-signing will be rendered easier soon-enough, or did I miss something?
<cyphermox> yes, that's what I'm working on atm
<cyphermox> I don't know if you work on virtualbox or if you're just interested because; but the idea is that dkms should work, so we need to make sure some kind of signature happens, and that it remains secure so as not to diminish the value of secureboot
<cyphermox> for vbox, it's not quite as critical (ie your system still works) but some wireless/ethernet drivers or even graphics make use of dkms, so it's nice when your computer still works :)
<socratis> No, I'm not a developer (yet), I'm seriously interested. As far as I know, dkms was dropped because it wasn't working across platforms/distros.
<socratis> But I don't want to possibly drive you to the wrong path.
<socratis> As I said, my knowledge is surface only (if that), so I'll let the developers deal with it. Thank you so much in any event!
 * LocutusOfBorg forwards things to michael-vb
#ubuntu-kernel 2017-07-28
<dviola> hi
<michael-vb> cyphermox: Socratis relayed what you said last night (if your time zone matches mine) to me.  Thanks both.
<michael-vb> I hope that secure boot, user-friendly and third-party kernel modules is not a "pick any two", but just now I can't quite wrap my head round it.
<apw> michael-vb, in general secure boot and third-party kernel modules are by definition incompatible, that is the raison d'etre of secure-boot
<apw> is there a reason you don't submit your kernel modules to the kernel, so they become not third-party?
<apw> that is waht all the other hypervisors have done
<michael-vb> apw: to be honest I am rather confused about the raison d'Ãªtre if secure boot.  Matthew Garrett talked a lot about evil maid attacks, and I do not see how third party kernel modules are relevant to that at all.
<apw> michael-vb, its job is to stop random un verified binary being loaded into the kernel
<apw> loaded and run at ring0 to be more accurate
<apw> third-party modules are that very thing
<michael-vb> Regarding submitting our kernel modules to the upstream kernel, that does not make very much sense.  They are tied to a particular version of VirtualBox first, and upstream already has a hypervisor second.
<michael-vb> And third, we just don't have the free engineer time to make them gregkh-compatible.
<michael-vb> I suspect any of those three are blockers.
<michael-vb> Oh how nice, a BBC micro.
<apw> then we get to the self-signing fun ... which is coming
<michael-vb> apw: putting them in distributions might be a different matter, though it would involve some thought.
<apw> yep, might make sense, though lets hope tey don't change as quicly as some others, ugg
<michael-vb> One of the problems is that modules from different major-ish releases are incompatible and can't really co-exist.  At least not in memory.  On disk they can.
<michael-vb> Is that something Ubuntu would be potentially interested in as a solution?  Shipping the modules with the kernel, but not loading them by default?
<apw> michael-vb, i am not going to say no at least
<apw> we would indeed need to think about how hard they are to maintain
<apw> and the level of support we would get for issues when updating primary kernels
<LocutusOfBorg> apw, I know this is OT, but your kernel module has missing udev rules to make copy-paste host-guest work https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/debian/virtualbox-guest-dkms.udev
<apw> LocutusOfBorg, as in we remove them in our delta ?
<apw> or you mean when we include them in the kernel we don't include that
<LocutusOfBorg> you should include them, otherwise copy-paste won't work because the kernel module is not accessible by normal user
<LocutusOfBorg> (sorry I'm doing kernel stuff right now)
<sforshee> tseliot: did you see that I have some build fixes for nvidia with 4.12? We're going to be trying to move artful to 4.12 soon but need to get the nvidia dkms drivers (among others) fixed first.
<LocutusOfBorg> apw, you might want to sync new vbox kernel modules, even if I don't think they differs
<LocutusOfBorg> except for version
<tseliot> sforshee: I must have missed them. Where are they?
<sforshee> tseliot: bug 1700798 and bug 1700799
<ubot5> bug 1700798 in nvidia-graphics-drivers-304 (Ubuntu) "nvidia-graphics-drivers-304 304.135-0ubuntu2 ADT test failure with linux 4.12.0-4.5" [High,Triaged] https://launchpad.net/bugs/1700798
<ubot5> bug 1700799 in nvidia-graphics-drivers-340 (Ubuntu) "nvidia-graphics-drivers-340 340.102-0ubuntu4 ADT test failure with linux 4.12.0-4.5" [High,Triaged] https://launchpad.net/bugs/1700799
<tseliot> sforshee: I'll have a look at them, thanks!
<sforshee> tseliot: ta
<mamarley> tseliot: For 340, there's already a patch in the graphics-drivers PPA package.  It would probably be fairly easy to adapt to 304 too.
<tseliot> mamarley: right, I'll check out the PPA too, thanks
<ricotz> sforshee, hi, did you dare to check with 4.13 yet?
<dviola> hi
<sforshee> ricotz: not explicitly, though I do see that I have a module built for 304 in a vm I'm using to test dkms updates
<sforshee> with 4.13 that is
<ricotz> sforshee, ok, I see -- 4.13 is still meant to be the target for artful?
<sforshee> ricotz: yep
<sforshee> trying 340 with 4.13 now
<ricotz> ok, thanks
<sforshee> looks like it built!
<sforshee> I might have actually checked that already, can't remember for sure
<ricotz> sounds promising, while possible runtime issues are harder to debug ;)
<sforshee> ricotz: yeah, the big caveat is that my patches are only compile tested
<dviola> could this patch get backported to the ubuntu kernel, please? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/i915/i915_drv.c?id=ce3f7163e4ce8fd583dcb36b6ee6b81fd1b419ae
<dviola> my machine freezes without this commit while playing some video games
<dviola> it's already in Linus' git tree and it was also applied to 4.12.4 (stable tree)
<dviola> this is the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=101261
<ubot5> Freedesktop bug 101261 in DRM/Intel "[G45] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:32:pipe A] flip_done timed out" [Normal,Closed: fixed]
<dviola> I run both archlinux and ubuntu on this computer, archlinux will get 4.12.4 soon but I think ubuntu is on 4.10 kernel, so I was wondering if it could also be applied to ubuntu's kernel
<bjf> dviola, we plan to release 17.10 with 4.13. the current artful (17.10) kernel in -release is a 4.11 kernel. we are working to stabilize 4.12 right now.
<dviola> bjf: good, so no need to backport anything I guess?
<bjf> dviola, no
<dviola> ok, thank you
<dviola> :)
#ubuntu-kernel 2017-07-30
<android> problem doing release upgrade
<android> looks like the isp allowed the repo through the supposed pay gor service block
<android> and then the release deappeared from updates
<tomreyn> is it worth reporting oopses with hwe-edge (on xenial)?
<tomreyn> this is a ryzen
#ubuntu-kernel 2018-07-23
<jhg_> greetings
<jhg_> do you guys know of any prebuilt kernels that would have the Fault Injection Framework enabled?
#ubuntu-kernel 2018-07-24
<apw> jhg_, no that i know of
#ubuntu-kernel 2018-07-25
<SysMan-One> Hello There!
 * apw looks up
<SysMan-One> I have a question is related to the Block I/O.
<SysMan-One> It's acceptable here or not ?
<apw> i would ask and see what happens, as without more context i doubt i can tell if it is going to be off topic
<SysMan-One> Ok.
<SysMan-One> I working on filter-driver which is live on top of other block-device.
<SysMan-One> I intercept READ/WRITE request to performs modifications of disk sectors before write to disk and before return to kernel.
<apw> something like device-mapper then
<SysMan-One> Right!  The first question: I clonning oroginal BIO and  buffers to be written to disk as follows:
<SysMan-One> 	if ( !(*dst = bio_clone_bioset(src, gfp /* GFP_KERNEL */, src->bi_pool /* NULL*/)) )
<SysMan-One> 		{
<SysMan-One> 		printk(KERN_ERR  __MODULE__ ": bio_clone_bioset() -> NULL\n");
<SysMan-One> 		return	-ENOMEM;
<SysMan-One> 		}
<SysMan-One> 	if ( status = bio_alloc_pages(*dst , GFP_KERNEL))
<SysMan-One> 		{
<SysMan-One> 		printk(KERN_ERR  __MODULE__ ": bio_alloc_pages() -> %d\n", status);
<SysMan-One> 		return	status;
<SysMan-One> 		}
<SysMan-One> bio_copy_data(*dst, src);
<SysMan-One> Is it correct way ?
<SysMan-One> Sorry, forgot include header:
<SysMan-One> static int __dua_bio_clone	(
<SysMan-One> 		struct bio	*src,
<SysMan-One> 		struct bio	**dst
<SysMan-One> 			)
<SysMan-One> {
<SysMan-One> int	status;
<SysMan-One> gfp_t	gfp =  GFP_NOIO; //GFP_KERNEL; // (GFP_NOIO | __GFP_HIGH);
<SysMan-One> So, is there someone who can help me to resolve question ?
<apw> SysMan-One, i would look at what device-mapper does as it is likley the kind of framework you are becoming
<apw> though why would you not make this a device-mapper personality in that case
<SysMan-One> Thanks for you attention. A some task conditions prevents to use device-mapper way, it's not my choice.
<apw> but as it is doing the same kind of things, it is likley got the right ways of doing things in it
<apw> one of the encryption personalitys sounds closest
<SysMan-One> I understand ... I cannot explain more about of the project, but u are right here, it's transparent en/de-cryption.
<SysMan-One> Can i  ask  second question ?
<apw> yep
<SysMan-One> Ok. Thanks.
<SysMan-One> I wrote "my_endio" routine to performs processing of the read disk blocks. I'll past some portions of code follows, ok ?
<apw> better to pastebinit
<SysMan-One> Hmmm ... It's about of 60-70 lines.
<apw> right which is about 58 lines too much to paste in irc, as it comes out a one line per second and annoys everyone
<SysMan-One> Ok. Will use pastebin and post the link.
<SysMan-One> The piece of code which is supposed to process read disk blocks has been placed at the : https://pastebin.com/Pdyf4dNL
<SysMan-One> May be I doing something wrong with iterators ?
<apw> doesn't bio_copy_block do the sort of thing you are doing, so how it handles them (which seems different) might help
<SysMan-One> I working under 4.4 and 4.15 kernels (Ubuntu 16) . I did not found "bio_copy_block" routine in the headers and sources. Do u mean something other ?
<apw> in mainline kernel linus' tip it exists and looks like something you could use as a template
<SysMan-One> bio_copy_data - works for me, my primary question is related to memory allocation:
<SysMan-One>  bio_clone_bioset(src, GFP_NOIO, src->bi_pool) - it's right usage ?
<SysMan-One> using GFP_KERNEL in  bio_alloc_pages(*dst , GFP_KERNEL) - is acceptable ?
<SysMan-One> (yes, bio_copy_data I have used as template) - but why .bv_length is zero ?!
<SysMan-One> Hello !
<SysMan-One> Can we off from main chatting or it will bother u ?
<apw> sure
<apw> in both cases you care about whether it is safe to block there
<apw> what locks you have held etc, as to whether it is safe
<apw> using NOIO seems logical as you are trying to do IO now, and if you
<apw> cannot get enough memory to do _this_ io, trying to do io to free memory is no more likely to work
<kees> apw: can I convince you to enable some kernel options? :) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1783651
<ubot5> Ubuntu bug 1783651 in linux (Ubuntu) "Please enable CONFIG_PAGE_POISONING" [Undecided,New]
<tyhicks> kees (cc apw): thanks - I left a comment but I'm at my eod at this point so that's all I can do for now :)
<kees> tyhicks: thanks! I don't want the sanity checking -- I think that's too heavy-duty for the general case.
#ubuntu-kernel 2018-07-26
<SysMan-One> Hello!
<SysMan-One> Just a question: i use bioset_clone(srcbio, gfp, src->bi_pool) to get a cloned BIO to be submited to underlaying block device. I fighting with memory leaking at the time.
<SysMan-One> So the question is: can I use src->bi_pool.bio_pool (bvec_pool).curr_nr to monitoring usage (alloc/free) of elements ?
<SysMan-One> I use bioset_clone(srcbio, gfp, src->bi_pool) to get a cloned BIO to be submited to underlaying block device. I fighting with memory leaking at the time.
<SysMan-One> So the question is: can I use src->bi_pool.bio_pool (bvec_pool).curr_nr to monitoring usage (alloc/free) of elements ?
<asfar> Hello anyone else had this bug on linux 4.15 or any ideas? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1783906
<ubot5> Ubuntu bug 1783906 in linux (Ubuntu) "Linux 4.15 and onwards fails to initialize some hard drives" [Undecided,New]
<asfar> Long story short, i have two HDDs and the Western Digital one doesn't work on linux 4.15 and onwards
#ubuntu-kernel 2018-07-27
<apw> jsalisbury: ^
<bhelgaas> i'm considering changing the way CONFIG_PCIEASPM_DEBUG works.  does anybody have info about why ubuntu enables that, or how ubuntu uses the /sys/.../link_state files it enables?
<apw> bhelgaas, why it is enabled, a good question ... i don't think i am aware of any userspace we specifically rely on using it
<bhelgaas> apw: I did find a launchpad bug requesting it, seemed like mostly to enable manual testing
<apw> bhelgaas, got the bug number handy, so i can see what was said
<bhelgaas> Yeah, but I'm working out right now. Will get it to you later
<bhelgaas> apw:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398544
<ubot5> Ubuntu bug 1398544 in linux (Ubuntu Vivid) "Please enable CONFIG_PCIEASPM_DEBUG" [Wishlist,Fix released]
<apw> bhelgaas: ok so yeah just for debugging,nao changing them isnt the end if the world, if upstream will accept such a change
<danieru98> By using Ukuu Kernel Update Utility i found this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1783906 happens on linux 4.15rc4, but not linux 4.15rc3. How can i further "bisect the kernel"?
<ubot5> Ubuntu bug 1783906 in linux (Ubuntu) "Linux 4.15 and onwards fails to initialize some hard drives" [Medium,Confirmed]
<ryuo> I have an unusual issue that I reported today to the kernel bugtracker. Should I just wait now to hear something further? I've already exhausted everything I could think of. Report is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784008
<ubot5> Ubuntu bug 1784008 in linux (Ubuntu) "brightness keys incorrectly mapped for ProBook 455 G5" [Medium,Confirmed]
#ubuntu-kernel 2018-07-28
<apw> ryuo, i suspect we need to report that upstream, if you have found it is also broken in the mainline tips
<ryuo> apw: it is. i suspect it may be an issue with how the kernel interprets ACPI events from this newer model.
#ubuntu-kernel 2019-07-22
<loothelion> Hey, I couldn't find any links to a bug tracker under the wiki tree for this group. So I have two questions: Can I have a link to a tracker? and is there already something tracking failures in the mainline builds for non-rc builds? It looks like things started failing around the beginning of July because of -mindirect-branch
<loothelion> I should clarify that the mainline build failures I'm talking about are for amd64 and i386 builds like so: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2/BUILD.LOG.amd64
<amurray> loothelion: this is a known issue - https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961
<ubot5> Ubuntu bug 1830961 in nvidia-graphics-drivers-430 (Ubuntu) "Kernels & kernel drivers fail to build with gcc-9 [error: â-mindirect-branchâ and â-fcf-protectionâ are not compatible]" [Critical,Fix released]
<dupondje> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.3-rc1/
<dupondje> this one builds again :)
#ubuntu-kernel 2019-07-28
<fling> Hello! How can I grab the proper shiftfs patch for a certain kernel version?
#ubuntu-kernel 2020-07-20
<fling> are not there any recent shiftfs patches for 5.4?
<fling> the patches I extracted a while ago are producing a warning on 5.4.52
<fling> Which tree is for 5.4 kernel now?
<fling> Is 5.4.44 in focal the latest available 5.4 kernel?
<fling> found 5.4.47 in master-next in focal
<fling> shiftfs patches from master-next apply to 5.4.48 but getting a warning with 5.4.49
#ubuntu-kernel 2020-07-21
<fling> Are all the shiftfs patches touching fs/shiftfs.c ?
<apw> sforshee, ^
<luna_> Is there any Ubuntu Kernel Meeting today during GUADEC? Or you already had it 
<luna_> #ubuntu-desktop 
<luna_> whoops
<apw> luna_, we don't really have irc meetings; if you have something to bring up you can do it at anytime here
<AlexMax> Good afternoon.  I've been running into some various freezing issues with my Ubuntu installation, and the most recent freeze seems like it might be in your folks wheelhouse.
<AlexMax> The behavior is that I'll be doing something and suddenly I'll get a hard freeze.  I thought it might be graphics drivers, but I have observed this hard freeze behavior with both a Radeon 5700XT and an nVidia 1060 3GB - open source drivers on both.
<AlexMax> I started out on stock Ubuntu Kernel and drivers, but now I'm using 5.7.9 from Ubuntu and graphics drivers from oibaf.
<AlexMax> And the most recent crash resulted in a rather interesting thing in my journalctl: https://hastebin.com/xagixisile.txt
<AlexMax> A write attempt to an NX page.  At the time I was simply opening a new page in Firefox.  My intuition is that it points to faulty RAM, but I've already run memtest86 (not +) overnight
<luna_> apw: ah alright nah i don't just saw it in the fridge calendar and wondered
<luna_> will join todays Firefox and Fenix meeting instead then
<AlexMax> My apologies if this isn't the right channel, I was suggested to go here to ask
<tyhicks> AlexMax: hey - I'm not going to be able to help you out here but please double check that there's not a stack trace in your logs following what you've already pasted
<AlexMax> No stack trace, unfortunately.
<tyhicks> AlexMax: bummer - there's not really enough info for anyone to debug your issue
<AlexMax> Thanks for what little time you had to spare
<tyhicks> AlexMax: the kernel attempts to print a normal stack trace after those messages but your system must be dying before those log messages can reach the disk
<JanC> might be possible to send them elsewhere (in the future), depending on why it doesn't reach the disk?
<AlexMax> Is there enough information to know what it couldn't be?  Or could it be any of kernel bug/driver bug/bad RAM/Motherboard?
#ubuntu-kernel 2020-07-23
 * JanC wonders what "Stella Cmit Abra" is...
<sarnold> belgian beer? czech beer?
<sarnold> ooh ooh mixing a belgian beer with a czech beer. got it.
#ubuntu-kernel 2020-07-24
<pdbogen> Howdy! There's a patch in Linux 5.4.53 that addresses a kernel panic we experience on bionic w/ `linux-image-aws-edge`; is there any guidance on when we might see the patch available from ubuntu?
<pdbogen> (this one, if that's helpful: https://patchwork.ozlabs.org/project/netdev/patch/20200702185256.17917-1-xiyou.wangcong@gmail.com/)
