#ubuntu-kernel 2005-11-07
<makx> the initramfs-tools and klibc don't show up in scott's patches list.
<makx> (been told that it would do automatically after breezy)?
<infinity> makx : I need to do some by-hand merging of the Ubuntu<->Debian diffs in initramfs-tools anyway, and get us reasonably in sync.
<makx> infinity: there is an bzr archive out there with all that is in debian.
<makx> bzr branch http://debian.stro.at/bzr-test/initramfs-tools/
<infinity> makx : Yeah, I know.  jbailey and I have been discussing it, off and on, including me probably joining in with the Debian maintenance.
<makx> infinity: cool
<infinity> makx : Not much will be done about it until after I get home from UBZ, though.
<makx> what is UBZ?
<infinity> Ubuntu Below Zero.  The conference we're all at right now. :)
<infinity> I get home in ~11 days.
<makx> nice, thought it was for a weekend. :)
<infinity> And initramfs hacking is high on my priority list, both for Ubuntu and Debian.
<makx> i may need soon newer uploads on debian for initramfs/klibc
<makx> shall i bug you?
<makx> (i'm in nm, but can find others in #d-kernel uploading).
<infinity> Sure, just do it via email, I'm not watching IRC much while I'm here.
<infinity> adconrad@debian.org for Debian stuff.
<makx> ok, do you fetch from debian mentors?
<infinity> Not generally, but there's no reason I can't.
<makx> klibc in debian is missing jbailey's jfs patch, had hoped for an quicker upstream integreation.
<infinity> Just point me at whatever I need to sponsor, so I can do a quick once-over/audit, and I'll make it happen.  (just not today, it's 2am, and I really should sleep)
<makx> sure, i'll prepare today with my testing and send you mail with pointers to latest. :)
<makx> thanks
<zul> morning
<zul> morning lamont 
<lamont> morning zul
<fabbione> hey guys
<zul> hey fabbione 
<zul> how goes it?
<fabbione> zul: just starting the morning session
<zul> nifty
<zul> just 3 more days and ill be back wohoo..
<zul_> ok im going to throw up a git archive together tonight
<johnm> anyone here living in the UK? specifically near York?
<root89> can you help with a question on installing kernel 2.6.14?
<zul_> johnm: all the people in the channel right now are either in montreal or probably not in england
<johnm> zul_: thats very true actually, I forgot you were all gonna be meeting up.
<BenC> we're all getting drunk and dancing in the hotel halls
<BenC> oh wait, that's the 14:30 session
<chmj> lol 
<bhna> why CONFIG_PREEMPT is not set in the kernel? is there a deb with preemtion enabled?
<zul_> BenC: you are doing the charleston wow! 
#ubuntu-kernel 2005-11-08
<dilinger> BenC: any idea what plans are wrt yaird vs initramfs?
<dilinger> er, initramfs-tools
<BenC> pretty sure we are still using initramfs
<BenC> smp2up: Dynamically optimizing SMP kernel code for UP operation...
<BenC> smp2up: Made 3632 modifications to kernel code.
* BenC scores one for UP vs. SMP
<dilinger> BenC: yaird does initramfs as well
<dilinger> nice
<dilinger> aiui, they're both the same, just implementation differences (and yaird supported old style initrd as well, but i guess that code was recently removed)
<dilinger> fyi, the page that was just pointed out to me: http://wiki.debian.org/InitrdReplacementOptions
* dilinger heads home to play w/ his new toy^Wlaptop
<manveru> hey guys, somebody knows something about 'nobody cared' oppses?
<manveru> -p+o
<crimsun> that's too vague
<crimsun> do you have ksymoops output?
<zul> heylo
<zul> i finally have a git tree going
<zul> i just need to populate it
<BenC> cool
<zul> BenC: when are you leaving montreal btw?
<BenC> Monday
<zul> cool so we can hang out on saturday
<zul> hey fabbione 
<BenC> yeah, I'll be here
<fabbione> hey
<fabbione> BenC: i am rechecking HWregressions
<fabbione> we got some interesting comments from SteveA
<dilinger> fabbione: do you think the openafs thing is going to happen?
<BenC> fabbione: cool
<fabbione> dilinger: the bof hasn't been scheduled at all
<fabbione> dilinger: we can probably consider it offline
<fabbione> dilinger: did you actually write a spec?
<fabbione> that would help to speed up stuff
<dilinger> fabbione: yea, i wrote a spec
<dilinger> https://wiki.ubuntu.com/OpenAFSSupport
<fabbione> dilinger: did you link it to launchpad?
<fabbione> well.. that's just the request for it :)
<fabbione> it's misssing all the implementation plan & co.
<fabbione> i can't push it in that stutus
<dilinger> yea, i linked it to launchpad
<dilinger> i didn't put implementation stuff into it, since i'd intended to actually discuss that stuff w/ you guys at UBZ :)
<fabbione> dilinger: https://wiki.ubuntu.com/BootingFromUSB
<dilinger> (note that openafs 1.4.0 was *just* released)
<fabbione> dilinger: try to make it a complete specs
<fabbione> because i seriosly doubt we can discuss it here
<fabbione> but for sure we can evaluate it
<fabbione> as drafting etc...
<fabbione> BenC: i *think* i did clean HWregression enough to make Steve happy
<fabbione> we still have the next hour to look at it
<fabbione> but if we can manage to do it faster > teh rock
#ubuntu-kernel 2005-11-09
<zul> guys, i should be there around 9:00 tomorrow\
<fabbione> hey zul
<fabbione> cool
<zul> cold enough for you ugys yet?
<dilinger> is it below zero yet?
<zul> not yet here at least
<zul> it should snow in a couple of day me thinks
<dilinger> there was snow in boston last saturday
<zul> wet snow? or sticky snow?
<dilinger> wet snow
<dilinger> it stuck to the ground, but only where there was grass and stuff
<dilinger> but it went on for most of the day
<zul> icky
<zul> it hasnt snowed in ottawa yet
<zul> hey you guys want to go to a steak house tomorrow for dinner?
<zul> a steak bof..
#ubuntu-kernel 2005-11-10
<chuck> slackers
<BenC> strange seeing everyone come on at the same time
<fabbione> ehehe
<zul> oops..maybe i should have logged off my machine at work before i went home
<lamont> heh
<BenC> mine stays connected, good ole screen sessions :)
<fabbione> eheh
<zul> what about git and luanchpad?
<fabbione> no way
<fabbione> why do you think i am such a bitch
<fabbione> and lp guys just avoid me :P
<BenC> lol
<chmj> lol
<fabbione> i just created the Ubuntu Kernel Team in launchpad
<zul> cool
<zul> i finally have git working properly
<zul> my git archive can be pulled from http://zulinux.homelinux.net/git
<zul> er..http://zulinux.homelinux.net/git/ubuntu-2.6.git
<BenC> zul: can you send that to my email?
<zul> sure..
<zul> i guess i could do that
<fabbione> ok .. kernel logo is up thanks to Keybuk
<fabbione> if you don't like it, please propose a new one before complaining :)
<zul> url?
<chmj> I want a pony 
<Mithrandir> what would you need a pony in the basement for?
<chmj> you make it sound wrong
<fabbione> zul: https://launchpad.net/people/ubuntu-kernel-team/
<fabbione> zul: what's your plan to become MOTU -> uploader and all that thing?
<zul> fabbione: i was already accpeted as a motu long time again i just never uploaded anything
<fabbione> zul: ok
<fabbione> that's kinda of a stopper for us to get the kernel team to be part of the core team
<fabbione> or do we want the other way around. hmmm
* fabbione needs to think about it
<zul> all i have is done is a patch here a patch there..
<fabbione> right
<fabbione> we don't want ubuntu-core- to upload kernel
<fabbione> so they shouldn't be part of our team
<fabbione> in theory our team doesn't need to upload *
<fabbione> but it still targeted to main
<zul> true
<fabbione> it's kind of a weird situation
<fabbione> we will need to bring this up as usecase for the TB meeting
<zul> doh..
<chmj> You are not a member of this team.
<zul> i aint?
<fabbione> zul: hm no.. the problem is that to be part of ubuntu-core to upload to main
<fabbione> each team memebers need to have main upload privileges
<fabbione> but our case is different
<fabbione> you are part of the kernel team
<fabbione> but you don't have full main upload privileges
<fabbione> for the kernel team to be able to upload (as a team), it needs to be part of ubuntu-core
<zul> well we only have one person really uploading to main, except for updates
<fabbione> so it's kind of a weird loop
<fabbione> zul: later on with lp managing the kernel
<zul> heh..ill just go home then ;)
<chmj> I mean't me, I'm not added as part of the kernel team 
<fabbione> all of us will be able to ask lp to make an upload
<zul> chmj: im in montreal btw
<chmj> zul: oh yes, I'm in the big room, where are you ? 
<zul> im sitting across from lamont near the front
<dilinger> oh man
<dilinger> this promise driver sucks so badly
* dilinger sighs.  the SPC-3 spec is 500 pages.
<fabbione> dilinger: no shit :)
<fabbione> BenC: ping?
#ubuntu-kernel 2005-11-11
<makx> git pull rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
<makx> Not a git archive
<makx> i wanted to know if you have:
<makx> a) dropped the xu "modular" ide patch
<makx> b) building ps keyboards into the kernel
<makx> (although i'm pretty sure about b ;)
#ubuntu-kernel 2005-11-12
<zul> hey
<janimo> now the ubuntu kernel is in git there will no longer be debian/patches ?
<janimo> and no more debian dir in bazaar?
<fabbione> janimo: there is and will be debian/
<fabbione> no debian/patches
<janimo> does ubuntu kernel packaging change a lot?
<fabbione> everything is in the kernel itself
<fabbione> not really
<janimo> so is debian/ going to be in bazaar?
<fabbione> no
<fabbione> in git
<janimo> ok, that's what I asked above :) obviously there needs to be debian/ 
<fabbione> bazaar is deprecated
<fabbione> we will work in git from now on
<janimo> so it's about the same deb building process but without the patching phase
<fabbione> exactly
<janimo> I already cloned the tree but wanted to know if there's anything else
<fabbione> we will also kill some packages
<fabbione> like linux-tree
<fabbione> linux-patch
<janimo> the more killed the merrier
<janimo> is there going to be a main packge of 2.6.14 or does it directly go to universe?
<janimo> and tilll 2.6.15 we stay with breezy kernel?
<fabbione> it will land in universe first
<fabbione> and switch to main as soon as it is stable
<fabbione> stable for us..
<janimo> aha
<janimo> but goal is 2.6.15 bc of the input udev stuff?
<fabbione> yes we will got for .15 in dapper
<fabbione> s/got/go
<janimo> do you know if the current u-kernel tree has the breezy patches?
<fabbione> almost all of them, if not all
<janimo> cool, thanks
<zul> gday
<fabbione> hey zul
<zul> how is it going?
<fabbione> sleepy
<fabbione> you?
<zul> same
<zul> i went to bed at like 9:00 am on saturday
<fabbione> ehhe no surprise
<fabbione> saturday we went out
<fabbione> went to sleep around 5
<fabbione> iirc
<zul> er...i mean 9 pm
<zul> have you guys sample the more adult bars on st. catherine's yet?
<fabbione> nope
<zul> heh..i should have while i was there
<zul> oh well
<dilinger> hm
<dilinger> what are these devmapper devices that show up in breezy's kernel?
<dilinger>    3     1      48163 hda1
<dilinger>  253     0      48163 dm-0
<dilinger>    3     2     249007 hda2
<dilinger>  253     1     249007 dm-1
<dilinger> and so on
<dilinger> vgchange -ay shows no VGs
<dilinger> are those crytpo devices or something?
<zul_> not sure
<fabbione> dilinger: uh? never seen that stuff
<fabbione> ah in /proc/partitions ?
<dilinger> yea
<zul_> bbl
#ubuntu-kernel 2005-11-13
<zul> evening
<krellan> hi, psmouse question
<krellan> am thinking of changing it to do a reset in addition to just printing "lost synchronization, throwing %d bytes away"
<zul> hey
<fabbione> morning
<fabbione> what's up zul?
<zul> not much just at work
<zul> u?
<zul> git already has a debian directory :)
<fabbione> yeah but it's utterly wrong
<fabbione> not much really
<fabbione> getting some coffee
<dilinger> of course it's utterly wrong
<dilinger> when have you seen a correct upstream debian directory?
<dilinger> they just cause more headaches than they solve by creating debian packages
<fabbione> yeah
<fabbione> it would be good IF they actually maintain it
<zul> ill poke around it tonight again
<infinity> BenC : Do I have a 2.6.14 yet, huh, huh?
<fabbione> infinity: git clone ....
<fabbione> ;)
<fabbione> infinity: drug bof?
<zul> oh you wild and crazy people
* fabbione sniffs
<dilinger> anyone have a hoary amd64 machine i can use for building stuff on?
<dilinger> or a breezy machine w/ a hoary chroot?
<fabbione> dilinger: i do, but it's turned off
<fabbione> i will get access to it when i will be back from ubz
<dilinger> ok.  i probably won't need it by then; i have an amd64 machine in front of me, but i can't install onto it without a custom parted :)
<fabbione> ah o
<fabbione> k
<fabbione> sorry. i can't phone my wife at midnight to turn it on
<dilinger> that's ok
<dilinger> i'm wondering if i can bootstrap it with i386, put an amd64 kernel on there, and then get an amd64 chroot on it
<dilinger> just seems like a lot of work, though :)
<dilinger> huh.  hoary's parted works
<fabbione> yeah way too much work
<dilinger> maybe i won't need it after all
<fabbione>  dr_d_19 writes "According to Groklaw, SCO is now demanding IBM to turn over 'all documents concerning IBM's contributions to the Linux 2.7 kernel, including development work'. Of course, there is no 2.7 kernel and no plans at all to create one."
<fabbione> AHAHHAHAHHAHAHAHA
<fabbione> oh god guys
<fabbione> look at /.
#ubuntu-kernel 2006-11-06
<hillapple> hello
<hillapple> is there someone who has the experience of compiling the linux kerner 0.01?
<itsyou> hello all
<alex_joni> just installed an ubuntu-server and the default 2.6.15-26-server kernel has HT disabled. should I install the bigiron? or is it not usefull to run with HT enabled?
<crimsun> was disabled for a CVE
<crimsun> if you must, boot with ht=on
<alex_joni> is it usefull?
<crimsun> there are varying answers, none of which I can really tell. It depends on the context, perhaps.
<alex_joni> found http://www.daemonology.net/hyperthreading-considered-harmful/ .. will read there (thanks for the answer)
<BenC> infinity: ping
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.19-5.5 uploaded - The Sleezy Hotel release. Use it, but there are still a few missing modules.
<ajmitch> nice naming
<infinity> BenC: ?
<BenC> infinity: Was going to ask about doing a kernel upload, but I already did it :)
<infinity> BenC: Oh.  Alright.  I fully support this kernel uploading initiative.
<BenC> infinity: Thanks for your blessing Godfather
<infinity> ;)
<BenC> I'm getting lrm ready to upload too
* kylem moos.
* tfheen bounces
* fabbione wonders if 5.5 will not crash as much on ppc
<infinity> BenC: FTBFS, suckah.
<infinity> BenC: Oh, never mind.
<infinity> BenC: Build-deps confused.
<hughsie> okay, I'm sure this is the hundred and first time someone's asked, by is there a link to the missing modules? and WELL DONE to rebase so quickly.
<hughsie> also, how to get the kernel de-jour the easiest way rather than downloading .debs?
<tfheen> git gives you the freshest source code
<hughsie> tfheen: nahh, that's a little too hardcore even for me:-) - i mean the 2.6.19 debs
<hughsie> i need those for the OPLPC work...
<johanbr> hughsie: Downloading from kernel.org and then doing "fakeroot make-kpkg --initrd kernel_image" in the source dir gives you a nice .deb. 
<hughsie> johanbr: yes, that's what I've been doing, but I wanted to know if the nice ubuntu uys have pacakged up my ipw3945 in the restricted modules and stuff like that
<hughsie> hacking without the net is painful :-)
<tfheen> hughsie: ipw3945 is packaged, yes
<hughsie> tfheen: SWEET!
<tfheen> I thought that was supported in edgy as well.
<tfheen> /lib/modules/2.6.17-10-generic/kernel/drivers/net/wireless/ipw3945/ipw3945.ko exists in my edgy install at least.
<hughsie> i cant seem to find it tho... i'm using feisty repo, and i get 2.6.19 but no restricted modules
<johanbr> No, l-r-m doesn't exist yet for Feisty.
<hughsie> ahh, i need 2.6.19
<hughsie> johanbr: as i guessed, thanks.
<tfheen> oh, sorry, Ben was talking about lrm for feisty earlier today.
<tfheen> so, "soon"
#ubuntu-kernel 2006-11-07
<mann> hey guys, seems like an unexpected behaviour. I hibernated my IBM thinkpad R40, with Edgy installed. But, when I boot it up again, it starts from scratch, as in, all the applications that were in use while hibernating, are all closed. Its as if, I restarted my computer. 
<crimsun> have you filed a bug against linux-source-2.6.17 with dmesg attached?
<mann> sure I'll. Meanwhile, I'd like to look into the matter, and figure what's going wrong. Do you have any suggestions (i'm a newbie) on which branches of kernel src code to look at. 
<crimsun> will need the bug report first
<mann> hey guys, just figured out that the hibernate was failing coz of swap space not being mounted on boot. The bug is already reported here: https://launchpad.net/distros/ubuntu/+bug/66637 . After following steps mentioned, hibernate works fine.
<crimsun> good to hear.
<BenC> infinity: my scripts wonder why ia64 isn't on the ports machine yet :)
<BenC> the linux-image packages that is
<gnomefreak> i should be fine with linux-libc-dev 2.6.19... and the 2.6.17 kernel or should i not reboot?
<BenC> it should be fine
<gnomefreak> ok cool
<gnomefreak> ty
<infinity> BenC: Znarl's fixing it now.
<BenC> infinity: thanks
<zul> BenC: so how cracktastic is it so far?
<BenC> zul: It's so ugly :)
<zul> yes it is
<zul> but it did work with the 2.6.18 vanilla kernel :)
<tfheen> xen?
<zul> yep
#ubuntu-kernel 2006-11-08
<jbailey> BenC: Launchpad doesn't seem to know about linux-restricted-modules-2.6.19 yet, where do you want bugs? =)
<BenC> it should, they are built
<BenC> are you talking about the ppc ftbfs?
<jbailey> Nope =)
<jbailey> linux-restricted-modules-2.6.19-5-generic - Non-free Linux 2.6.19 modules on x86_64 generic
<jbailey> This is the description on i386. =)
<BenC> ooh, ok
<jbailey> (as I was checking to see if they were available yet. *g*)
<BenC> just an email directly will be ok
<jbailey> Done, thanks.
<zul> interesting you can detach block devices in xen
<tfheen> BenC: you never pulled in ca96426a13f7a30c9fd768a0e56785ee2d471918 from rookery:~tfheen/public_html/git/ubuntu-2.6.git  Mind doing that?
<BenC> tfheen: is that for feisty?
<tfheen> it was for dapper, but it should be applicable for feisty too
<tfheen> oh, it's there already
<tfheen> ignore me then
<BenC> heh, ok
<rikai> bbl, off to play some F.E.A.R.
<rikai> Err, sorry, that wasn't meant for here. ;)
<cbx33> hi guys
<cbx33> I want to write a HID driver for an interactive whiteboard, where would I start
<cbx33> I'm presuming it is going to be either a modification to or a base of a mouse driver or something similar
<aapje> bug soft lockup detected on cpu#0! is what i get when I put my rt61 in
<aapje> I'm running 2.6.15-27-k7
<Administrator__> hello
<Administrator__> i get bug:soft lockup detected onm cpu#0
<Administrator__> when i use my rt61 wifi card
<Administrator__> using 2.6.15
<Administrator__> smp why is it eneabled in generic?
<Administrator__> this causes softlockups on some wifi cards
<fabbione> then there is a bug in the wifi driver
<Administrator__> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2268
<Administrator__> there are a lot of users who own a rt61l, see ubuntu forums.
<Administrator__> *rt61
<fabbione> ubuntu forums are NOT a bug reporting tool.
<fabbione> if there is a bug in launchpad somebody will look at it
<Administrator__> who reported a bug there?
<fabbione> otherwise tough luck
<Administrator__> I'm just gathering info
<Administrator__> and proofing a proof of concept
<fabbione> well open a bug
<fabbione> with all the info
<Administrator__> how well do you developers intergergrate with your users
<mjg59> Administrator__: SMP is enabled in the generic kernel because it's now difficult to purchase a machine that isn't SMP
<mjg59> That's not going to change
<fabbione> Administrator_: opening bug in the right place is the right thing to do
<fabbione> it's no matter of "integrating".. we can't track stuff that's not in the right place
<rikai> Developers have more important things to do with their time(fixing bugs, adding new things), than to search the internet for problems reported in incorrect places. :)
<Administrator__> mjg59, because of that reasons (i assume that you made that conclusion from your own perpective)  you guys enable smp in kernel?
<mjg59> Administrator__: We enable SMP so that people can actually use their computers properly, yes
<Administrator__> the help on the smp options is wrong, it can cause harmn.
<Administrator__> so why not acutall make two flavors?
<Administrator__> or several flavors?
<mjg59> Because it would increase support load
<mjg59> And because we could, instead, try to fix the broken drivers
<mjg59> The answer to "My driver is broken and doesn't work properly with SMP" is not "Disable SMP"
<mjg59> But in any case, the -386 kernels don't have SMP enabled
<makx> b0rked drivers that are not smp ready are not even preemtible
<Administrator__> ok that's great to here because, i already tried a bootparm nosmp but ubuntu didn't boot
<Administrator__> hang on i'll install 386 kernel
<JanC> Administrator_: the Ralink SMP bug is here: https://launchpad.net/distros/ubuntu/+bug/34902
<JanC> no need to file a duplicate :)
<jbailey> BenC: Hey - the kernel upload from last night fixes the crash-on-startup-when-usplash-running. Thanks.
<mini> are there any plans for releasing an updated edgy kernel?
<jbailey> mini: Define updated?
<jbailey> It will get security fixes from here.
<mini> as in bugfixes
<jbailey> Depends on the bug.
<mini> I'm thinking about this one https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418
<mini> prevents many laptop users from booting...
<mini> and has a very trivial workaround patch, that I just  tested
<jbailey> mini: Mostly up to BenC and the rest of the kernel team on specifics like that.
<mini> "many" as in all laptops with the ipw3945 intel wireless card
<mini> thus, probably majority of Core Duo laptops
<mini> BenC: comments?
<BenC> mini: "all laptops with ipw945" seems to exlude my laptop, since that's what I have
<mini> Did you try booting with wireless off?
<mini> i.e. killswitch on
<mini> that's what triggers the bug
<BenC> I can test it later...if I can reproduce it, then the more likely it is to get fixed :)
<mini> :-)
<mini> ok, there's a patch in that report, produced by Intel
<mini> trivial timeout implementation that should be safe
<mini> see the intel bugzilla at http://bughost.org/bugzilla/show_bug.cgi?id=1096
<BenC> mini: ok, looks easy enough...Note it will go into edgy-proposed initially and hopefully work its way into edgy proper
<mini> thanks, makes me feel better.
<zul> BenC: i updated the fiesty-xen stuff can you reivew it please
<mini> BenC: thanks for listening
<BenC> mini: no problem
<BenC> zul: Yeah, give me a few minutes to get this kernel upload done
<zul> sure
<zul> heh i can be an asshole no you must do it now!! ;)
<BenC> hehe
<ivoks> BenC: well, that bug is real :/
<ivoks> (/me is late :)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.19-5.7 uploaded - Ciggarette BOF release. Use it, but there are still a few missing modules.
<jbailey> zul: 
<jbailey> Cant main packages depend on universe packages? - chuck
<jbailey> zul: No.
<zul> jbailey: ah ok
<zul> what about multiverse?
<jbailey> no
<zul> damn..
<jbailey> They call it the ogre model.
<jbailey> main, wrapped by restricted, wrapped by universe, wrapped by multiverse.
<jbailey> Dependancies have to face in.
<zul> ok good to know
<lamont> jbailey: and they fixed it after me...
<lamont> universe can't depend on restricted either
<lamont> although it could in my day, since I'm a lazy slacker
<lamont> and it broke the purity of the ogre model.
<lamont> but it had to be
<zul> damn..
<zul> is it possible to make a special case to get the xen-kernel in main eventually?
<zul> of course i might be on crack
<lamont> nope.
<tfheen> zul: what's the problem?
<lamont> what might be possible is to build the xen kernel without the dependency and have a multiverse package that delivers the extra module or whatever
<zul> tfheen: the problem is I would like to have xen in main evntually
<tfheen> zul: yes, and that is problematic why?
<mini> sorry, I missed the issue - what's the troublesome module in xen?
<zul> because the xen patch for the kernel is really really ugly
<lamont> zul: main consists (by definition) of everything seeded in main, and all of the dependency chain to make it installable.  so it _can't_ depend on any other component...
<lamont> really really ugly doesn't imply multiverse or universe...
<zul> ok
<lamont> what does it depend on that is not in main?
<zul> it depends on the kernel basically
<lamont> that's in main. :-)
<zul> *sigh* ill talk to you guys after this bof
<thom> lamont in "helpful" mode
#ubuntu-kernel 2006-11-10
<zul> BenC: http://ozlabs.org/~rusty/paravirt/
<zul> ill have a look but it looks like it touches alot of stock files as well
<crimsun> missing 'h' in chuck's patch (last hunk) for ATI RS690 HDMI
<radone> greetings. I am trying to compile project and I got:  /lib/modules/2.6.15-27-386/build: No such file or directory
<radone> linux sources are already installed, but how can I create build directory?
<crimsun> you need linux-headers-$(uname -r), not linux-source-2.6.15
<radone> crimsun: installed, but without any effect - /lib/modules/2.6.15-27-386/ exists, but sub-directory build/ not :-(
<crimsun> well, what's uname -r ?
<radone> uname -r: 2.6.15-27-386
<crimsun> and what's the dir listing of /usr/src/ ?
<crimsun> we should migrate to #ubuntu, btw
<radone> linux-headers-2.6.15-27 is included in /usr/src/
<crimsun> bingo, you're missing linux-headers-2.6.15-27-386
<radone> crimsun: thanks for help. I have overlooked this :)
<user__> where is the diff.gz of 2.6.19-5.7? there is no 2.6.19-5 on packages.ubuntu
<crimsun> that's because you misread.
<crimsun> there is no diff.gz, because it's native.
<crimsun> 929c6c7855932231f20b8148235b1d17 59289186 devel optional linux-source-2.6.19_2.6.19-5.7.tar.gz
<crimsun> https://lists.ubuntu.com/archives/feisty-changes/2006-November/000206.html
<user__> why is there no 2.6.18?
<crimsun> because .19 is the target
<user__> crimsun, is 2.6.17 using readahead patches?
<user__> and where can one obtain the brokenout? of the patchset?
<user__> oot@vulaogdx:/usr/src/linux# fakeroot make-kpkg --initrd
<user__> exec debian/rules  DEBIAN_REVISION=2.6.18-allesineenpc-1-10.00.Custom  INITRD=YES 
<user__> is not working
<user__> where did it go wrong?
<user__> running edgy
<makx> user__ try to specifiy a target also you don't need to be root to build your kernel
<makx> user__ also use your home to build something aka ~/src
<user__> can I do a request? could ubuntu distribute ck kerenels? 
<makx> the ck patchset is useless
<makx> mainline is much better
<user__> howcome?
<makx> if you want hard rt you need to use -rt
<user__> what makes it useless?
<makx> the O1 scheduler
<makx> on 2.4 the -ck patchset was very interesting
<user__> is there a -rt(realtime??) patchset?
<makx> also requests on irc are lost in the noise so not very effictive :-P
<makx> yes ingo takes care of the -rt effort
<makx> anyway need to work now
<user__> ok last question,what patches also need to be in for good performance?
<user__> latency ..
<makx> depends on your hardware
<user__> can I combine rt with hz patch or other patches from ck? like the hz default patch or the swap prefetch swappiness?
<user__> would it benefit ?
<makx> rt has dynticks much cooler
<user__> so none of the patches in ck would benefit if  one would ues -rt
<kylem> Keybuk, ping. what kernel version were you seeing the waitid problems?
<Keybuk> kylem: 2.6.17
<kylem> k
<Keybuk> the code looks identical in 2.6.19
<Keybuk>         set_fs(KERNEL_DS);
<Keybuk>         ret = sys_waitid(which, pid, (siginfo_t __user *)&info, options,
<Keybuk>                          uru ? (struct rusage __user *)&ru : NULL);
<Keybuk>         set_fs(old_fs);
<Keybuk>         if ((ret < 0) || (info.si_signo == 0))
<Keybuk>                 return ret;
<Keybuk> note that if ret < 0 or no signal received, it just returns
<Keybuk> without ever calling copy_siginto_to_user32
<Keybuk> oh, hmm, there's a memset above now
<Keybuk> ah
<Keybuk> no
<Keybuk> that memset is for the 64-bit sigingo
<kylem> right.
<Keybuk> uinfo is never cleared, and can be returned as passed
<kylem> er, shouldn't there have been a copy_siginfo_from_user?
<Keybuk> no, the struct is not used
<Keybuk> ie. it's only to return data
<Keybuk> not to pass in
<kylem> ahh. righto.
<Keybuk> (note that do_wait deliberately clears the struct when returning certain conditions
<Keybuk> so that sys_waitid gets a cleared struct
<Keybuk> but because compat_sys_waitid exits early, it never copies the cleared struct into the wider one)
#ubuntu-kernel 2006-11-12
<gnomefreak> has 2.6.19 been uploaded for updates? i see it in the repos but i havent seen update for it yet?
<crimsun> what updates?
<gnomefreak> crimsun: upgrade from 2.6.17 - 2.6.19 on feisty. ive been running feisty since start of UDS and i see the kernel in apt-cache search but no updates for it
<crimsun> 2.6.19-5.7 is the latest.
<gnomefreak> i just got done with a bug i wanted to close because it was against 2.6.19 and i had said its nto in feisty how can there be a bug on it
<gnomefreak> dist-upgrade isnt giving me the new kernel it did give me libc6-bleh-dev  cant remember what middle word was for 2.6.19 and resticted-modules-common-2.6.19 but no kernel
<crimsun> I'm not sure what you mean by "no updates for it". Certainly linux-meta does not point to the 2.6.19 images. It doesn't make sense to. Thus, it still points to 2.6.17
<crimsun> Essentially, if you're running 2.6.19-5.7, it's because you explicitly installed it
<gnomefreak> so i would have to install 2.6.19 to get it at this point
<gnomefreak> ah
<gnomefreak> ok
<admin123> I used the 2.6.17 config for building my own kernel image(2.6.18) however my dvdrom is not getting detected anymore on bootup of the 2.6.18 is there a module that needs to be loaded?
<admin321> I used the 2.6.17 config for building my own kernel image(2.6.18) however my dvdrom is not getting detected anymore on bootup of the 2.6.18 is there a module that needs to be loaded?
<admin321> and what is the diffrence between profile and oprofile?
#ubuntu-kernel 2007-11-05
<kraut> moin
<fuzzy> kraut: i didn't know you were a part of this room
#ubuntu-kernel 2007-11-06
<gene6482> I would like to report a fix to an open bug report, that has fixed my issue, I was told this would be the place to share that.
<gene6482> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/136469
<ubotu> Launchpad bug 136469 in linux-source-2.6.22 "toshiba p100 series dsdt acpi error no sound, works with acpi turned off." [Medium,Triaged] 
<thomas_newbie__> where do I find help with setting up honeypots?
<r11t> can I download the kernel source for ubuntu gutsy via apt-get?
<crimsun> apt-get source linux-image-2.6.22-14-generic
<r11t> thank u crimsun :)
<jiver> Anyone knows if the SATA disk shutdown issue got fixed in newer kernels?
<jiver> Newer than 2.6.18
<jiver> whoever is awake
<bullgard4> Is it true that the interrupt handler XT-PIC-XT is obsolete? (https://bugs.launchpad.net/update-manager/+bug/158397/)
<ubotu> Launchpad bug 158397 in update-manager "[Ubuntu 7.10] dmesg: "serial8250: too much work for irq11"" [Undecided,New] 
<kraut> moin
<ln-> is there anyone here who is in any way involved with Ubuntu kernel development?
<fabbione> ln-: they will be around in a few hours
<maks_> fabbione: lurking to catch you
<maks_> do you know of the newer gcc klibc sparc troubles
<maks_> i got it to compile again but it seems to segfault..
<fabbione> maks_: nope?
<fabbione> maks_: i haven't been working on sparc for a bit now.. is that hardy or debian?
<maks_> debian sid
<fabbione> nope.. haven't been playing with debian sparc in ages
<maks_> i haven't seen yet a sync to hardy
<maks_> but it will hit soon i guess
<fabbione> maks_: we are all in the East Coast area these days
<fabbione> there will be almost no sync activity for this week
<maks_> http://marc.info/?l=linux-sparc&m=119427098411110&w=2
<maks_> http://bugs.debian.org/399724
<maks_> i'm pondering to switch back to gcc 4.0 for sparc
<fabbione> no we are switching to gcc-4.2
<maks_> well if you know of a fix i'd be happy to hear fabbione :)
<fabbione> maks_: as i just said i didn't poke sparc in a bit
<maks_> ah ok
<fabbione> it will need to wait next week that I am back home
<fabbione> and switching gcc because of code bugs is not the right solution
<fabbione> better to get stuff fixed properly
<maks_> trave11er is also gone, leaves allmost no sparc porters :P
<fabbione> where did he vanished?
<maks_> rl
<fabbione> he used to be very active
<fabbione> rl?
<maks_> exhausting job afaik
<fabbione> oh rl = real life
<fabbione> sorry i am barely awake and trying to code a fix for qdiskd :)
<fabbione> anyway don't worry
<fabbione> we will fix it at some point
<fabbione> no panic you need to
<maks_> cool, if i'd come up with something i'd let you
<maks_> know
<fabbione> ok
<fabbione> keep me posted
<fabbione> but i won't be able to look at it before next week
<fabbione> i am just too far away from my machines :)
<fabbione> and latency here is killing my nerves
<maks_> sure thanks
<fabbione> np
<manchicken> So is this the right place to come with possible bugs with acpi handling?
<ln-> manchicken: i don't know if this is the right place for anything.
<manchicken> ln-: Fair enough.
<manchicken> heh
<manchicken> I'm now looking at this from the gnome-power-manager angle.
<manchicken> I'm wondering if it may be bug #145131
<ubotu> Launchpad bug 145131 in gnome-power-manager "[Gutsy] Screen constantly flashing while g-p-m is running" [Undecided,Confirmed] https://launchpad.net/bugs/145131
<manchicken> Okay, no, my /var/log/acpid doesn't look anything like that.
<manchicken> Okay, I just reported bug #160467.  I'm updating it with more info.
<ubotu> Launchpad bug 160467 in acpid "acpid reports insteresting messages as my screen is constantly blanked" [Undecided,New] https://launchpad.net/bugs/160467
#ubuntu-kernel 2007-11-07
<kraut> moin
<xipietotec> anyone have some ideas for troubleshooting a problem with the systemclock and an ancient version of the PheonixBios? I'm trying to set up a friends laptop with Ubuntu, but the OS cannot seem to get access to the Bios to change the system clock (I can temporarily just set the system clock to the correct settings in the bios, but I'm worried about what happens later and this pops up, as if you select "Change it" it crashes X.)
<jc-denton> how can i rebuild the aacraid driver w/o compiling the whole kernel?
<jc-denton> its using dkms,  but that's for redhat afaik
#ubuntu-kernel 2008-11-03
<maco> in which ubuntu git tree would i find drivers/char/drm/i915_drv.h?  I checked ubuntu/ubuntu-intrepid.git but it's not there
<nigel_c> Feisty, Gutsy and Hardy all have it.
<nigel_c> (Haven't checked earlier ones)
<maco> it's gone in intrepid?
<nigel_c> Not there in my git trees.
<maco> :-/ i wonder where those macros moved in 2.6.27
<maco> ok ill look through lxr
<nigel_c> drivers/gpu/drm/i915
<nigel_c> maco: ^^
<maco> nigel_c: thanks
<nigel_c> You're welcome
<NCommander> lamont, I'd like to have my ubuntu-jaunty-ports branch blessed as the offical jaunty ports branch since there is no existing jaunty ports branch, and I'd like to be able to upload it (with the kernel teams blessing)
<lamont> and I'd like a installable 2.6.27 for ia64
<lamont> and iwl4965.ko for intrepid/i386
<lamont> interestingly, iwl4965=y in config
<NCommander> hey lamont 
<NCommander> lamont, well, it compiles on ia64, but the box I have access to I don't own thus I can't even smoke test the kernels
<lamont> the final intrepid kernel was ftbfs
<lamont> so my ia64 box here running intrepid has 2.6.24 :(
<NCommander> lamont, I'm talking jaunty
 * NCommander has a 2.6.27.4 ports branch w/ apparmour and Ubuntu drivers added
<NCommander> Even AuFS, though it needs some porting on ia64
<NCommander> It builds on all port architectures (I just got sparc building tonight)
<lamont> and for total amusement, my laptop works just fine with a livecd, not so fine with the hardy system upgraded to intrepid
<NCommander> What architecture is your laptop ;-)
<lamont> dell inspiron 1520 == iwl4965, running i386 kernel
<NCommander> lamont, if you could smoke test my ia64 2.6.27.4 ports kernel, I'd apperiate it
<NCommander> lamont, try blacklisting iwl4965, and using iwlagn
<lamont> that'll happen at some point after I get a working laptop
<lamont> iwlagn is what loads
 * NCommander notes someone needs to go through the config for ia64 and sanity checking
<NCommander> Most of the things that should be built as modules aren't, the upshot that virtually no udebs are being built
<NCommander> I dunno what hardware is present or not on most ia64s, so all I did was blacklist every udeb that didn't have a module compiled for it (i.e., ppp/slip/etc.)
<NCommander> THe upshot is I bet the installer is going to be completely hosed until someone can look at it
 * lamont notes that he is totally ignoring ia64 tonight
<NCommander> lamont, HPPA w/ 2.6.27.4 also builds and gets udebs
<lamont> ditto
<NCommander> :-)
<NCommander> sparc?
<lamont> tonight is: 1) fix laptop.  2) sleep
 * NCommander runs for cover
<NCommander> Ah
 * NCommander needs to simply find what the kernel team wants before I find a sponsor for the ports kernel upload I want to do
<NCommander> morning abogani 
<abogani> NCommander: Good morning to you.
<NCommander> abogani, how goes your morning
<abogani> Just started ;)
<NCommander> cool
<Kano> hi, how about adding a 2.6.28 based git tree?
<sebner> hi folks! is there any progress in getting the proposed fixes uploaded/What's needed for it?  bug #283316
<sebner> no bot? :\
 * lamont cries a little.  sleep made things different... now I have no ethernet:  eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:... is missing
<rtg> lamont: forcedeth?
<lamont> module version missmatch for the win
<rtg> lamont: uh, are you off in the weeds?
<lamont> ssb_dma_set_mask etc, etc.
<lamont> 2.6.27-7.14 and .15
<lamont> and it was me sleeping for a while, not the laptop. :(
<rtg> oh, b44 which is dependent on SSB
<lamont> and linux-b-m-g installed a new ssb.ko
<lamont> but not a new b44.ko
<rtg> lamont: do you mean lbm-intrepid?
<lamont> well, yeah
<lamont> once you dig through to l-b-m-2.6.27-7-generic :-)
<lamont> could I maybe have a working wireless _AND_ b44?
<rtg> lamont: ok, I remember this from Hardy. Can you start a LP report?
<lamont> s/wireless/iwlagn/
<lamont> sure
<rtg> lamont: yes, as long as the wireless isn't b43.
<lamont> against l-b-m-intrepid?
<lamont> the wireless is iwl4965
<rtg> lamont: I was gonna upload a new LBM today anyway. your timing is good.
<rtg> yes - against LBM -intrepid
<lamont> https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-intrepid <--- 404
<lamont> so... against what source package?
<rtg> just linux-backports-modules
<rtg> lamont: be sure to assign me to it
<lamont> sure
<rtg> coffee, back in a few
<lamont> https://edge.launchpad.net/ubuntu/+source/linux-backports-modules <-- also 404
<lamont> ah, lbm-2.6.27
<lamont> rtg: already reported as 287450, now assigned to y
<lamont> ou
<lamont> rtg: scream if you need more
<lamont> meanwhile, working wireless is actually more important than working wired.  so I guess that's a win
<rtg> lamont: well, I ought to be able to get both working. 
<lamont> heh. ok.  if you need a tester, happy to help with that once I make the transition to town in a bit
<rtg> lamont: I think I have a b44 in my quiver of laptops
<lamont> inspiron 1520, fwiw 
<rtg> lamont: cool. I'll bug you later this morning once I've got it uploaded (assuming wireless testing goes ok)
<apw> rtg, hiya
<apw> you remember that sound thing, the crackling on alsa oss working one ... well i redid all my testing against the updated intrepid kernel and the problem is still there and again my home build module is working fine whereas the 'standard' one is not
<apw> you mentioned you had some issues with previously working laptops and i was wondering which ones they were
<rtg> apw: you talked to me about this? If so, I don't remember. Is there a bug number?
<apw> it was around the release so i can understand forgetting :)  bug #273578
<rtg> apw: if OSS works, how does that make it a kernel issue? Seems more like ALSA library problems, perhaps pulseaudio?
<rtg> apw: the other thing to look at is if there were quirks for your codec that went missing between Hardy and Intrepid
<apw> rtg i agree the oss thing is confusing, but literally recompiling the module seems to make it work
<apw> no other change, to userspace ... so something odd is going on for sure
<apw> i can't see any quirks going away since 2.6.24 mainline
<rtg> apw: can you get the same result by restarting pulseaudio ?
<apw> nothing i did to pulse audio seemed to help at all
<rtg> apw: 'killall pulseaudio; /usr/bin/pulseaudio -D --log-target=syslog' ?
<apw> yep, that had no effect iirc, i can go reinstall the bad module and re-test if thats helpful
<rtg> apw: the fact that you are getting any sound output at all indicates its probably not a kernel issue, especially if you are getting interrupts. run the sound test and watch /proc/interrupts for steady increases in IRQ count.
<rtg> apw: also, describe in the bug report _exactly_ what you are doing wrt recompiling and insmod'ing etc.
<apw> will add that info to the bug, but litterally just built it using fakeroot debian/rules binary-generic
<apw> and copied the built version out of the debian directory into /lib/modules
<rtg> apw: thats the part that doesn't make sense to me. why would a recompile have any effect?
<apw> indeed, its completely illogical as i recall you went to try rebuilding a kernel youself
<apw> as i was compiling on a 64 bit install
<apw> with a different compiler from you, something like that
<apw> will go redo that test with pulse audio and write up what i have done here
<rtg> apw: thanks
<jcastro> ogasawara: ~25 minutes until your session!
<ogasawara> jcastro: thanks :)  I totally forgot about daylight savings being a factor so I would have been late!
<jcastro> ogasawara: yeah that's been going around, I'm just doublechecking people just in case. :D
<didrocks> rtg: apprently your advice correct the "too hot wifi card bug". I put a commentary. Thanks a lot and keep me in touch if you need more advanced tests
<rtg> didrocks: I'll be updating LBM again later this morning, so watch for regressions.
<didrocks> rtg: ok, I will
<didrocks> rtg: basically, what was the cause of the issue? Too many calls to the Wi-Fi card?
<rtg> didrocks: dunno. I didn't have time to drill that deep.
<didrocks> rtg: ok. the most important is that it is corrected :)
<drunkenkilla> hello
<drunkenkilla> i can't regulate the screen brightness... is this a problem, which can be solved with the next kernel-version?
<didrocks> rtg: I think that finally, it didn't fixed it
<didrocks> it froozes
<didrocks> then, I tried to switch back in a wired connexion
<didrocks> but I just have now a red light (no green one) :/
<didrocks> I am afraid that my network card is broken now :/
<TomJaeger> So about bug #276990...
<TomJaeger> Can this patch please be applied to the intrepid kernel? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55d6a3cd0cc85ed90c39cf32e16f622bd003117b
<rtg> TomJaeger: try linux-backports-modules
<TomJaeger> The patch is clearly 100% safe and in any case has gotten some testing in linux-backports-modules
<TomJaeger> rtg: Not everybody knows about linux-backports-modules
<TomJaeger> plus, the iwlagn module in linux-backports-modules generates all kinds of additional kernel oopses
<TomJaeger> I'm completely dumbfounded by this.  Why exactly are we exposing users to a module that is known to cause kernel panics when there is a one-line patch upstream working around the problem?
<TomJaeger> And if we care about stability, why on earth would we recommend anyone to install a random daily snapshot of compat-wireless?
<TomJaeger> And is it really to much to ask to set the importance of this bug to High?
<rtg> TomJaeger: how about posting a request to kernel-team@lists.ubuntu.com lest I lose track of all the damn wireless bugs?
<trv> does anybody know why linux-image-debug in intrepid is for 2.6.25 kernel and not 2.6.27? i want to find the vmlinux file for the current kernel
<TomJaeger> rtg: done
<TomJaeger> It's kind of sad that I have to spend my time arguing for something so obvious but here you go
#ubuntu-kernel 2008-11-04
<lamont> so when I run kvm -cdrom foo.iso, can I change foo.iso to a different iso without rebooting?
<stgraber> lamont: yes, you need to use the qemu console for that, use ctrl+alt+2 to access the console ctrl+alt+1 to go back to the VM
<stgraber> you can then eject and mount a new CD (don't remember the syntax but there is help included IIRC)
<lamont> cool
<lamont> and if the machine has never been defined in qemu, I can still talk to it (kvm cli instance) with the qemu console?
<stgraber> yeah, kvm is using qemu so the ctrl+alt+X shortcuts should work (even with the other frontends like VNC)
<lamont> coolness
<CarlFK> I am trying to track down a memory leak.  the memory does not get freed when I exit the app.  someone suggested I look at /proc/meminfo
<CarlFK> is there a tool that will show me those on a graph so I can look for deltas?
<amitk> CarlFK: something like slabtop?
<amitk> assuming you are looking at a kernel mem leak
<CarlFK> amitk: not what I was hoping for (a graph) but I am open to suggestions - looking at ï»¿slabtop
<amitk> CarlFK: another one to look at might be sysstat
<CarlFK> isag - Interactive System Activity Grapher for sysstat
<CarlFK> that sounds like what I want 
<CarlFK> amitk: um... how do I run sysstat?  "sysstat is already the newest version; -bash: sysstat: command not found; $ man sysstat; No manual entry for sysstat
<_ruben> sysstat package has iostat and some other tools
<CarlFK> ah - got it
<rtg> mjg59: Does 'Input: atkbd - expand Latitude's force release quirk to other Dells' seem like a candidate for 2.6.27.y ?
<mjg59> I don't see why not
<BenC> rtg: is that related to eject key hang?
<rtg> BenC: thats what I'm thinking.
<BenC> rtg: definitely sounds like it
<BenC> rtg: too bad my latitude doesn't have a cdrom or I would test that theory
<rtg> BenC: I don't have the equipment back yet to test with, but shold by weeks end
<mjg59> It is, yeah
<mjg59> Since there's a keyboard grab for the eject key and it doesn't get released until the key gets released
<BenC> good deal then
<mjg59> Which it never does
<asac> rtg: there?
<rtg> asac: yep
<asac> rtg: do you have an ipw 50XX chipset somewhere?
<asac> apparently the thing that came after 4965
<rtg> asac: Shirley Peak, iwlwifi  5K
<rtg> asac: I have 2 of those
<asac> rtg: are those identical?
<rtg> asac: Model 512_AN, and Model 533_AN. don't know the differences between them since they are too big to fit any PCIe slots that I have.
<asac> rtg: oh so you cannot test them?
<rtg> asac: not easily.
<asac> rtg: so. do you have any chipset at hand that doesnt connect with WPA in intrepid ;)?
<asac> (and that connects properly with wpasupplicant manually)
<rtg> asac: do you mean with a simple Open AP?
<asac> no with WPA
<asac> there are a bunch of regressions with iwl ... and other drivers
<rtg> asac: oh, you are asking if there are any drivers that _fail_ to connect with WPA, right?
<asac> rtg: and at best such chipsets that still work with wpasupplicant manually
<rtg> I use iwl4965 and ath5k every day, connecting to a WPA/PSK/TKIP AP. I never have problems.
<asac> rtg: with NM?
<rtg> asac: always. in fact. I've never use wpa_supplicant manually.
<asac> rtg: i think the biggest prob is the IPW 50XX chipset ... i have reports that that doesnt even work with PSK
<asac> but works with supplicant alone
<asac> all others have issues with enterprise network
<rtg> stock 2.6.27, or LBM?
<asac> only some users report that its just slow
<asac> rtg: thats all stock i think.
<rtg> asac: I'm not surprised that there are issues with the stock kernel. The wireless release was totally flubbed.
<asac> rtg: maybe you have a setup where connecting with NM takes a bit longer than one want?
<rtg> asac: 1-2 seconds, about what I'd expect.
<asac> rtg: so how can we ensure better in future
<asac> ?
<asac> is there anyway to better deal with such "flubbed" wireless releases on our side
<asac> ?
<rtg> asac: since we aren't upstream developers for wireless, we pretty much get what we're given.
<asac> rtg: who is upstream for iwl? just those intelliwireless folks?
<rtg> asac: yep - I think we'll meet some of them at UDS.
<asac> and who maintains the wireless stack in vanilla kernel?
<rtg> linville and crew
<asac> i mean most likely someone pulls in stuff from those intelli folks
<asac> ok
<asac> so redhat ;)
<asac> or is that wrong?
<rtg> I think John Linville is pretty distro agnostic.
<asac> ok. thought he had a redhat address
<asac> rtg: and atheros is done by atheros in-house and then pushed over the wall?
<rtg> All of these wireless drivers are developed in the open using Linville as the maintainer. Subscribe to linux-wireless@vger.kernel.org
<asac> ok thanks
<NCommander> hey amitk & lamont 
<lamont> morning
<NCommander> how goes it lamont?
<rtg> lamont: I'm getting complaints that LBM didn't fix the b44 problem.
<lamont> rtg: last I looked it wasn't in the archive (as I saw it)... where should I go grab it from
<lamont> ?
<rtg> checking...
<rtg> https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27/2.6.27-7.5
<rtg> lamont: does it need further stroking? Its marked DONE
<NCommander> rtg, hi
<lamont> rtg: no, it means I need to add intrepid-proposed to my list
<rtg> lamont: doh :)
<rtg> NCommander: need something?
<NCommander> rtg, I'm trying to figure out who knows what I need to do to get a ports kernel release (and to get my branch blessed as the next offical tree). I have someone willing to sponsor to upload once the kernel team says its ok
<rtg> smb_tp is the guy
<smb_tp> huh?
<smb_tp> NCommander, Ah sure. If you have updates, post a message to the kernel-team mailing list, stating where to get (ideally pull) the changes from
<NCommander> smb_tp, I have a 2.6.27.4 tree, but its not based off the old tree (git rebase was never meant to go four releases, so I had to start from linus branch and cherry pick)
<smb_tp> NCommander, are you working on a specific architecture?
<NCommander> smb_tp, all of them, but PowerPC is my priority
<NCommander> Its been test built on all architectures
<NCommander> ANd smoke tested on x86 and powerpc. I'm looking for people to smoke test them on sparc, ia64, and hppa (qemu-system-sparc doesn't like my laptop, and I can't find a good ia64 or hppa emulator)
<smb_tp> NCommander, I guess munkfish would have to be involved a bit (since he did a lot up to now)
<NCommander> smb_tp, he already has been involved :-)
<smb_tp> NCommander, Cool :) ia64 is a bit of a trouble. I only got access to a porter machine, so I can compile but not run a kernel
<NCommander> smb_tp, yeah, same problem here
<NCommander> smb_tp, but I did get permission to run daily runs on my ia64 porting box
<smb_tp> rtg, Did you have such a beast or was that BenC 
<NCommander> (my contact at HP is trying to get the same for HPPA)
<NCommander> I'm handling powerpc dailies, and I'm using spooky for sparc
<NCommander> I just need to throw dak or repopro somewhere
<rtg> BenC has the ia64
<NCommander> THe installer is hosed on ia64 (a lot of things that should be built as modules are compiled a y, but I don't know enough about the architecture to know what should and shouldn't even be built)
<smb_tp> NCommander, sounds great. So maybe you just have to announce what you want on kernel-team mailing list and if there are no objections just let me know where your tree can be pulled from
<NCommander> smb_tp, its on zinc already: mcasadevall\ubuntu-jaunty-ports :-)
<smb_tp> NCommander, Yep same with me. I got it somewhat to compile but saw there were several module issues like that
<smb_tp> NCommander, Great. :) So there were is done
<NCommander> Someone with an ia64 is going to have to bash the kernel with a hammer. I found ski, but it needs a special kernel configuration to be usable, so I might add a flavor
<smb_tp> NCommander, yeah, most likely. But otherwise you seem to have covered the ground well. The only thing left is some sort of announcement (if you didn't already and I missed that). Not that someone feels stepped onto...
<NCommander> smb_tp, I also ported AppArmour to the port architectures ;-)
 * NCommander was extremely busy
<NCommander> It compiled without issue, its just testing it since there is no documentation that I could find :-/
<smb_tp> NCommander, If it boots, its not too bad ;-)
 * NCommander is working hard to make the port architecture be awesome again
<smb_tp> NCommander, Thanks a lot for that
<NCommander> Only doing what I do best :-)
 * NCommander is a debian porter
<NCommander> A part of me wants to port Ubuntu to the m68k ...
<smb_tp> :)
<NCommander> Although mips is much more realistic
<sebner> A part of sebner only wants to support x86 and x86_64 :P
<NCommander> Mostly because I know someone with suitable buildd hardware, and I have an interest in architecture
<NCommander> infinity, ping
<infinity> NCommander: Yeah?
<NCommander> infinity, I need you to weigh in on a question about PPAs, and giving one to the ports kernel team that is non-virtualized. Cprov told me to ask the distro team for permission who passed me to the buildd admins :-)
<NCommander> (building the ports kernel on x86 is sorta an exercise in futility)
<infinity> NCommander: Ugh.  As much as I love ports (and would like the see the ports kernels stop sucking), there are some policy and security reasons for not allowing community PPAs to touch the non-virtual buildds.
 * NCommander whacks head on the desk
<NCommander> I was told an exception could be granted if I got an ack by the proper teams
<NCommander> But I seem to be going around in a circle
<NCommander> infinity, second BTW, I have a question about the powerpc builders (I'm told they have issues with Hardy, and I was hoping I could get more information so we could track down equivelent hardware and debug)
<infinity> NCommander: If you can get your hands on some old Xserves, it becomes pretty self-evident under load.
<infinity> NCommander: Repeated OOPSing until you get a hard lock.
<NCommander> infinity, oh, its an issue under load?
<NCommander> Damn it, thats anonying
<NCommander> THe kernel post hardy hasn't been touched until about two weeks ago
<infinity> NCommander: I tihnk we have some dumps somewhere of the OOPSes.  I'm a bit swamped right now to go hunting, though. :)
<NCommander> IF you could get me the specific model of Xserve
<NCommander> I can try and track one down before the next LTS
<NCommander> (or issue a SRU for hardy to fix it if I can track it down)
<infinity> NCommander: Yeah, I can dig up some info.  I just can't do so right this instant.
<NCommander> SUre, no rush, we still have two years to fix it ;-)
<infinity> Well, I'd *love* to see it fixed in an SRU.
<infinity> Having the PPC buildds on an ancient release is not my idea of good times.
<NCommander> No kidding
<NCommander> OUr glibc build has about five hacks to disable parts of the test suite
<NCommander> ITs no just PPC team member has an xserve
<infinity> I know.
<infinity> Yeah, I don't either.
<NCommander> (a few IBM servers, and a small army of G4/G5s :-))
<infinity> My main PPC devel machines are a 32-bit G3, and an IBM PowerStation.
<NCommander> You will be happy to know jaunty will be sporting a 2.6.27.4 kernel
<NCommander> (and I'm seeing if I can get the TB to approve a backport of the kernel as linux-ports-backport to intrepid so we have parity on that distribution)
<infinity> Which also reminds me, I need to make our yaboot love my Powerstation.
<NCommander> ugh
<NCommander> I don't even want to think the last time yaboot was touched
<infinity> Unless someone feels like finding YDL's patches and doing so for me.  *hint*
 * NCommander adds it to the TODO for today
<NCommander> infinity, if you care to sponsor, and help ACK making my kernel branch the offical jaunty ports one ;-)
<infinity> Given that it came with YDL installed, I know they have patches.  They weren't kind enough to send me a source CD, though, and I've not had a chance to go hunting.
<NCommander> I don't have the same hardware, but I'll post a source package to my PPA (at least THAT works), and then point you to it to test
<infinity> But, yeah.  Regarding non-virtual PPAs... We'll need to discuss precisely who and how many people would be able to upload to it, and then perhaps see if we'd need any formal paperwork, or if we're happy with our trust level with those people, etc.
<NCommander> infinity, personally, I would just want it to be snapshots of our git tree
<NCommander> No direct uploads would be necessary
<infinity> The general problem with PPAs is that they're much lower exposure than the archive itself, so it leaves much longer windows of opportunity for people doing Very Bad Things to those machines through PPA uploads.
<NCommander> Right
<NCommander> I have managed to get approval to run sbuld and friends on four of the five port architectures
<NCommander> so if I can't get a non-virtual PPA
<NCommander> I'll cobble something together
<infinity> Which are you missing?
<NCommander> HPPA
<infinity> I can do that.
<NCommander> Cool
<NCommander> HP provided the itantic
<NCommander> I have a (slow) PPC
<infinity> I have some very fast PPC hardware too.
<NCommander> And sistpoty already blessed using spooky (aka REVU) as the sparc builder
<NCommander> I need people to smoke test kernels
<NCommander> I don't have physical access to any of these machines
<NCommander> and someone has to beat the ia64 installer w/ a hammer of pain
<infinity> So, yeah.  If we don't want to be bothered too much with the possibility of red tape involved in abusing LP for this, I can certainly help with daily builds.
<NCommander> infinity, I need a place to setup dak and wanna-build ... (I've done it before; back when I was an archive manager briefly for the m68k port ;-))
<infinity> You worked in Debian 68k?
<infinity> Must have been after I stepped down.
<NCommander> and ARM
<NCommander> And MIPS
<NCommander> I ran four buildds
<NCommander> and our w-b after we got kicked off buildd.d.o before moving to d-ports.org
<infinity> Yeah, that's way after my time.
<infinity> I kinda gave up around the time we became a non-release arch.
<infinity> Lost motivation.
<NCommander> Actually, we got a new glibc now
<NCommander> FreeScale did the enginneering work
<NCommander> Which means its likely we will return in squeeze
<infinity> NPTL?
<NCommander> NPTL
<NCommander> :-)
<infinity> Nice.  I wonder how much of my groundwork got included in that.
 * infinity shrugs.
<NCommander> One of the cool things about coldfire and m68k being nearly the same architecture
 * NCommander also did work bootstrapping coldfire debian
<NCommander> Sadly, I got the board with a hardware fault on it
<infinity> They are the same, module a few instructions.
<infinity> No one ever claims that i386 and i686 aren't the same arch, so why split hairs? :)
<NCommander> infinity, well, that's why we have lpia
<NCommander> For better or worse
<infinity> My ColdFire board is very dusty these days.
<NCommander> infinity, I got my from Stephan
<NCommander> infinity, I actually got as far as a native GCC bootstrap, and booting from flash directly
<NCommander> infinity, actually, I think our yaboot problem is simply we're a year behind on the last current release
<infinity> NCommander: That's possible.  Given that YDL's Powerstation release is actually a completely seperate CD from their "normal" PPC release, though, I'm assuming there's either a custom yaboot, custom kernel, or (likely) both on there.
<NCommander> There are issues with the kernel when you compile in support for multiple platforms
<NCommander> It crashed and burned when I tried to add anything beyond CHRP and NewWorld
<infinity> They can get more than one kernel on a CD, mind you.
<infinity> But, yeah, that might be beyond YDL.
<infinity> They have some great technical people, but when it comes to user-friendly, they fail.
<NCommander> infinity, what happens when you try and boot on the powerstation?
<infinity> I almost audibly cried when I saw their default desktop.  It's... It's why most people think UNIX is terrible.
<NCommander> Its based off Red Hat
<NCommander> What do you expert?
<infinity> And, to be honest, I don't recall what exactly happens.  Dies in yaboot land, though.
 * NCommander is trying to find their SRPMs
<infinity> No, RedHat's default desktop is a pretty clean and friendly place.
<NCommander> Not in the 6.x days which YDL was based off of
<infinity> YDL's reminds me of CDE, circa 1993.
<NCommander> infinity, what version of yellow dog are we talking about?
<infinity> Booted, and was like, "Oh hai, IRIX, I've missed you!"
<NCommander> IRIX was my first UNIX ever ;.;
<infinity> NCommander: The "latest", I imagine... Whatever shipped with my Powerstation.  Let me find the DVD.
<infinity> DVD claims it's "Version 6".
<NCommander> Ok
<infinity> "Powerstation Edition"
<NCommander> so there are no yaboot differences between powerstation and regular
<NCommander> X11 and the kernel is where the changes are
<NCommander> infinity, ok, YDL ships with yaboot 1.3.13 with specific changes
<NCommander> so its a just matter of diffing
<NCommander> o_o; wow, lot of patches
<NCommander> and no patch system in the deban packaging
<NCommander> nice
<TheMuso> NCommander: Yeah I know, kinda annoying.
<NCommander> nothing powerstation specific here
<NCommander> Wait
<NCommander> who makes powerstations?
<infinity> IBM does, but they're unbranded.
<infinity> http://www.terrasoftsolutions.com/products/powerstation/
<NCommander> There are a whole bunch of amiga, and pegasos patches
<infinity> Every part inside is IBM, but the box just says "YDL Powerstation".
<NCommander> and one ppc64 intrd patch
<infinity> Anyhow, I have lots of work to do, sadly.
<NCommander> infinity, I'll ping you if/when I h ot test
<infinity> I'd love to take a weekend and figure out the most minimal way to make Hardy support this machine, though.
<NCommander> infinity, if you however figure out what the error is, it can isolate which patches I need to merge
<infinity> NCommander: Ping me on Friday?
 * NCommander shall do so
<NCommander> That will be after the jaunty kernel lands I hope
<infinity> NCommander: I'm taking Fridays off work for a while, so I might have some "community fiddling time".
<NCommander> very awesome
<NCommander> speaking of community fiddling
<NCommander> TheMuso, feel like uploading something?
<TheMuso> NCommander: Sure. What may that be?
<NCommander> a kernel
<NCommander> *hears a gunshot*
<TheMuso> um... Shouldn't the kernel team bless that?
<infinity> The kernel team has almost entirely washed their hands of ports.
<NCommander> ^- infinity 
<TheMuso> I'm not willing to touch it unless the kernel team really don't want to worry about uploading ports kernels.
<infinity> TheMuso: You have my blessing to sponsor any ports kernel uploads.  Assuming you have the know-how to do the usual sponsorship vetting/review.
<infinity> TheMuso: The primary kernel team has almost no interest in them, hence the split. :/
<infinity> I'm just glad the split happened after Hardy, so the hardy kernels are at least somewhat homogenous.
<NCommander> infinity, the only reason they support lpia is because its not that hard to keep it building
<infinity> Intrepid ports kernels are a mess. :/
<NCommander> infinity, yeah, it took most of the cycle to clean that up. We only got it fully working towards final freeze (and the installer is still an absolute trainwreck)
<TheMuso> infinity: Yeah the sponsoring is no problem. NCommander Alright, what git tree am I working with, your ports tree?
<NCommander> TheMuso, that would be mine, but the changelog isn't up to date (you need to call the proper rules to make the changelog be generated correctly)
<infinity> NCommander: Are there plans to keep ports kernels based on the non-ports git from here on it?
<infinity> s/it/in/
<TheMuso> NCommander: I understand that.
<NCommander> infinity, unless a port because offically supported again, yeah
<infinity> NCommander: Having different kernel versions, slightly different patchset, etc, between ports is... Terribad.
<NCommander> infinity, not for jaunty
<NCommander> infinity, we're actually half a revision higher than the mainline :-)
<NCommander> (mainline is .2 with cherry picking, ports is .4)
<infinity> That still feels icky, to a man who has many different arches at home.
<NCommander> Same here
<TheMuso> Agreed.
<NCommander> How abotu I add amd64 and i386-generic support to ports
<infinity> I like all my systems to be predictably similar.
<NCommander> Then you can run the same kernel across the board ;-)
 * NCommander actually did his inital cherry picking patch work on amd64, and then removed those files before committing
 * NCommander makes sure the ports tree is up to do
<NCommander> *date
<NCommander> TheMuso, you do know how to do a kernel release, right?
<TheMuso> NCommander: Yeah there are docs on the wiki. I'll take care of it once I've processed my morning email and taken care of some other things, but it is on my TODO for today.
<NCommander> Ok, I'll generate all the ABI files in the meantime, and then add them to the tree once 1.1 is uploaded so we have a constant ABI to base against
<TheMuso> Right.
<NCommander> TheMuso, since I have done some work in linux-ports-lrm ;-)
<TheMuso> NCommander: Ok cool.
<NCommander> (its just madwifi, but I figure its worth having)
<NCommander> linux-rt will need an upload, but thats multiverse, and I need to clear it by its maintainer anyway
<TheMuso> NCommander: I see you posted to the kernel list re this kernel. Are you still waiting for a response to that before we go ahead?
<NCommander> Thats more moving my tree to ubuntu-jaunty-ports.git
<TheMuso> NCommander: Right.
<NCommander> I personally want the kernel to hit jaunty so people can test the damn thing
<NCommander> (its only been smoke tested on powerpc)
<NCommander> also, not having a kernel package available has blocked work on linux-rt on powerpc, and linux-ports-lrm (its hardware to work against packages that only exist on 127.0.0.1 ;-))
<NCommander> s/hardware/harder
<TheMuso> Right.
<NCommander> We probably should look at linux-ports-lbm as well, but I first rather just make sure the kernel is usable (since I can probably find a PS3 or two user willing to test jaunty)
<NCommander> also, once this kernel is uploaded, the next ports daily image will tell us if the installer is completely broken
<NCommander> TheMuso, second BTW< please leave my name on the changelog so if a build FTBFS, I can get direct notification of it
<TheMuso> Well the installer still needs to have some udebs added. Once Colin has merged d-i, I'll add them.
<NCommander> TheMuso, I added them to the d-i files in the kernel
<TheMuso> NCommander: Ok.
<TheMuso> NCommander: But work needs doing on the d-i side as well.
<NCommander> ok, well, at least this is progress ;-)
<NCommander> brb, dinner
<TheMuso> NCommander: hrm when attempting to isnert the change in the changelog using your ports tree, I get the following error. Looks like there may be a tag missing or some such:
<TheMuso> fatal: ambiguous argument 'Ubuntu-2.6.27-0.0..HEAD': unknown revision or path not in the working tree.
<TheMuso> Use '--' to separate paths from revisions
<TheMuso> NCommander: I think you missed something.
<NCommander> o_o;
<NCommander> Its possible the repo needs to be tagged 1.1
 * NCommander hasn't done this before
<TheMuso> Right, and I think the tag is used to display changes between the last upload and head.
<NCommander> So what do I need to do to fix the tree?
<TheMuso> NCommander: I am not entirely sure.
<NCommander> Let me see if I can tag and get it to work here
<NCommander> What was the command you used?
<TheMuso> NCommander: ./debian/rules insertchanges
<NCommander> Worked fine here
<TheMuso> hrm.
<NCommander> I'm going to tag it ubuntu-ports-2.6.27-1.1 (we can't overlap with the main kernel, or it will break remotes)
<NCommander> TheMuso, I'll just tag and commit with the changelog generated and all that
<TheMuso> Well my copy of your tree has no tags.
<NCommander> My tree has no tags
<TheMuso> NCommander: hrm ok.
<NCommander> wel
<NCommander> I do have tags from remotes
<NCommander> Very strange
<NCommander> I think its because I restarted the branch things broke
<NCommander> If it does this again next upload, we'll investiage futher
<TheMuso> NCommander: have a look at this page for instructinos: https://wiki.ubuntu.com/KernelMaintenance
#ubuntu-kernel 2008-11-05
<NCommander> I did all that
<TheMuso> NCommander: Ok.
<NCommander> Very strange
<TheMuso> Let me know when its ready to pull.
<NCommander> http://kernel.ubuntu.com/git?p=mcasadevall/ubuntu-jaunty-ports.git;a=summary - I pushed it, but I don't see the tag ....
<NCommander> TheMuso, oh, it seems tags aren't automatically pushed
<TheMuso> NCommander: aaaaahhhhh!
<NCommander> TheMuso, lets try that again
<TheMuso> This is a nice learning experience.
<NCommander> I dunno fi I call the lack of automatic pushing of tags a feature or a bug
<NCommander> Its uploading now
<TheMuso> Ok.
<TheMuso> I call it a bug personally, but thats just me.
<NCommander> SOmeone should note that you need to git push --tags :-)
<TheMuso> Yeah.
<NCommander> Its designed so if you pull someone elses branch, you don't get private tags from during release
<NCommander> wow, 10MB worth of tags
<NCommander> Linus has been busy ;-)
<TheMuso> Ouch.
<NCommander> (ubuntu-ports tags are obviously enough Ubuntu-ports vs Ubuntu so we can't accidently get the same tag)
<TheMuso> NCommander: Well you probably need to change the debian/rules files to look for those tags then.
<TheMuso> Otherwise the insertchanges et al commands will fail.
<NCommander> Probably
<NCommander> TheMuso, that change is in my branch, once 1.1 is released, it will be available for 1.2 (or 2.1)
<TheMuso> NCommander: ok.
<NCommander> TheMuso, TADA http://kernel.ubuntu.com/git?p=mcasadevall/ubuntu-jaunty-ports.git;a=summary
<NCommander> The changelog is amusingly long
<NCommander> and
<NCommander> I think incorrect
<NCommander> Damn it
<NCommander> Freaking insert changes pulled in stuff it shouldn't
<NCommander> actually, wait, it only grabbed 2.6.27->2.6.27.4
<NCommander> Which is correct
<TheMuso> NCommander: ok.
<NCommander> Ok, so just grab my branch, build a source package (with a orig.tar.gz), sign and upload
<TheMuso> Will do.
<TheMuso> NCommander: Do you want me to give it a test build on PowerPC hardware?
<NCommander> TheMuso, sure
<NCommander> (I tested it on my box, but I haven't tested it since fixing the other archs, but there were no code changes)
<TheMuso> Right.
<NCommander> TheMuso, if you do, save the abi folder
<NCommander> We'll need to generate those on all architectures from this release forward, since we'll have lbm and lrm soon
<TheMuso> NCommander: I'm building in an LVM snapshot with sbuild.
<NCommander> oh
<NCommander> Ok
<TheMuso> I can grab it during the build however if you like.
<NCommander> Its not a priority until we start getting lrm and module packages
<TheMuso> Is it created early on?
<NCommander> No
<NCommander> Towards the very end of the build
<TheMuso> Right.
<TheMuso> NCommander: actually I will build it manually, so I can get the ABI folder.
 * NCommander nods
<TheMuso> NCommander: I thought there was a bug opened for ports kernel in intrepid to not use gcc 4.1 for powerpc, yet I see it in the build-deps.
<NCommander> I haven't cleared it yet
<NCommander> 1.2 build task
<TheMuso> ok
<NCommander> (doko wants to zap 4.1, once 1.1 is uploaded, that will be the first thing I do, since I need to make sure we don't have any nasty ices on any platform and still have working kernels)
<NCommander> i.e., I want a baseline to work against
<TheMuso> Right.
<TheMuso> NCommander: Kernels are cooking.
<NCommander> I thought I smelled something burning ;-)
 * NCommander runs from the bad pun
<TheMuso> It still made me laugh however.
<NCommander> Yay, 7 packages pending uploading (with an eight pending successful pbuildering)
 * TheMuso slaps his head. I should have told it to use both CPUs to build faster...
<NCommander> -j2 is broken
<TheMuso> Oh ok.
<TheMuso> That solves that then.
<NCommander> It kinda works
<NCommander> But you get a weird race condition which causes dpkg to explode
<TheMuso> Right.
<NCommander> I need to sit down and debug it at some point
<TheMuso> I wonder if that can be sorted out.
<NCommander> Enviornmental variable which just passed -j to the kernel build
<NCommander> WHich is what is already implemented
<TheMuso> Yeah I saw that.
<NCommander> (KERNEL_CONCURENCY_LEVEL or something)
<TheMuso> Yeah.
<TheMuso> NCommander: powerpc kernel cooked, powerpc-smp kernel now cooking.
 * NCommander holds the extinisher ready
<TheMuso> lol
<TheMuso> NCommander: powerpc64-smp now cooking.
<NCommander> TheMuso, can you test run them?
<TheMuso> NCommander: As in try to boot from them? Sure.
<NCommander> TheMuso, since we're on the topic of things to be done
<NCommander> TheMuso, can I get a few sponsoring on other packages?
<TheMuso> NCommander: Sure. Shall we take it to a more appropriate channel?
<NCommander> motu or devel, your pick
<TheMuso> NCommander: doesn't bother me, whatever suits you.
<TheMuso> :p
<TheMuso> \/c
<TheMuso> Wow documentation takes a while.
<NCommander> TheMuso, yup
 * NCommander should have told you to debuild -B
<TheMuso> Oh well.
<NCommander> TheMuso, did you get your zinc acocunt fixed?
<TheMuso> NCommander: Its in progress I believe.
<TheMuso> NCommander: kernels done.
<TheMuso> I can smoke test powerpc, and powerpc64-smp. I don't have a generic powerpc-smp box though.
<NCommander> now do they boot?
<TheMuso> Bout to try powerpc64-smp.
<NCommander> powerpc-smp will work fine on powerpc, or on a powerpc64-smp box
<TheMuso> Ok.
<TheMuso> NCommander: booting into powerpc64-smp.
 * NCommander crosses fingers
<TheMuso> It boots.
<TheMuso> Ok sound works, all disks present and correct, hrm not sure what else to check.
<NCommander> Good enough for me
<NCommander> The powerpc kernel been tested
<TheMuso> testing powerpc-smp now.
<NCommander> TheMuso, just as a reminder, remember to leave my name on the changelog (on the bottom) so I get the build failure notices if any occur :-)
<TheMuso> NCommander: since you fixed the changelog, that is not a problem.
<TheMuso> hrm powerpc-smp doesn't want to boot.
<TheMuso> on my G5./
<NCommander> coooooool
<TheMuso> yeah
<TheMuso> it brings up a screen with a lot of OpenFirmware stuff, or thats what it looks like.
<TheMuso> ok will try the powerpc and powerpc-smp kernels on my mini.
<NCommander> Hrm
<NCommander> the smp kernel might be hosed
<TheMuso> haha and the old boot option is broken. Time to dig out a desktop CD from hardy...
<NCommander> I'll have to smash it with a stick but unless I can find someone with a 32 bit SMP box
<NCommander> TheMuso, maybe the -smp kernel for some ungodly reason tries to put the G5 into little endian mode which would crash and burn
<TheMuso> possibly.
<TheMuso> NCommander: what makes you think that?
<NCommander> Its the only thing that could possibly cause the kernel to fault all the way back into open firmware
<TheMuso> NCommander: right
<NCommander> At least thats what I'm thinking
<NCommander> If it works on your mini, yay, if not
<NCommander> 1.2 :-)
 * NCommander hears a gunshot
 * TheMuso slaps his head.
<TheMuso> I was trying to boot old on my mini, not the G5.
<NCommander> oh
<NCommander> Your mini crashed and burned
<NCommander> Nice :-/
<TheMuso> no
<NCommander> Wait
<NCommander> huh?
<NCommander> What machine failed to boot the smp kernel?
<TheMuso> When I tried to boot into another kernel on what I thought was my G5, it didn't work, but it was on my mini.
<NCommander> Oh I see
<TheMuso> the G5 failed to boot the powerpc-smp kernel.
 * NCommander is resmoketesting the -smp kernel
<NCommander> I dunno why we have an non-smp/smp varient
<NCommander> Every other architecture is compiled to smp
<TheMuso> Yeah I know what you mean.
<NCommander> THere may be issues with the smp kernel on non-smp PPC hardware
<NCommander> THats the only reason I can think of
<NCommander> The G4 made it through a full startup with the SMP kernel
<NCommander> (its a single chip box)
<TheMuso> Right.
<NCommander> I think there must be hardware the SMP kernel crashes and burns with
<NCommander> TheMuso, I think we can write the issue as "Needs Investigation" and upload it
<TheMuso> Ok.
<NCommander> TheMuso, I just had a brainwave
<NCommander> TheMuso, your mini might have faulted because the kernel uses OpenFirmware to determine the presence of a second processor
<NCommander> Want to be on your mini crashed and burned due bad OF information?
<NCommander> *bet
<TheMuso> NCommander: it was the G5.
<TheMuso> NCommander: not the mini.
<NCommander> Oh!
<NCommander> same point applies ;-)
<TheMuso> Right.
<TheMuso> But powerpc64-smp worked.
<NCommander> and powerpc-smp worked on non-smp hardware
<NCommander> We need someone with an SMP G4
<TheMuso> Yep.
<TheMuso> ok powerpc works on the mini
<NCommander> so either smp is broken on smp hardware :-/, or smp is broken on smp64
<TheMuso> NCommander: NCommander Well 64-smp is fine, as I am now back on that with my G5, and both CPUs are showing.
<NCommander> I think infinity or lamont have to have a multicore non-SMP G5
<NCommander> can you boot a powerpc kernel on your G5?
<NCommander> (maybe its a general 64-bit issue vs. smp)
<TheMuso> NCommander: the powerpc kernel non-smp boots fine.
<NCommander> ok
<NCommander> We'll have to mark that on the Needs Debugging list
<TheMuso> NCommander: powerpc-smp boots on mini.
<NCommander> woooo
<NCommander> so its just a 64-bit issue
<TheMuso> sounds like it.
<NCommander> do we care enough to fix it at this very moment?
<TheMuso> I don't.
 * NCommander doesn't
<TheMuso> NCommander: i have some things to do so I'll look further into this later.
<NCommander> TheMuso, the smp crash, or uploading ;-)?
<TheMuso> NCommander: uploading.
<NCommander> ok, no
<NCommander> *np
<NCommander> ah, abogani 
<abogani> NCommander: Hi
<NCommander> abogani, I've been working on linux-rt-powerpc, and I found a rather disturbing problem
<NCommander> The current rt kernel in Intrepid isn't actually RT :-/
<abogani> :-?
<NCommander> (CONFIG_PREEMPT_RT is not defined)
<NCommander> and I can be blamed for it
 * NCommander whacks head on the desk
<abogani> No way: it is defined.
<NCommander> Nope
<NCommander> abogani, here's the debdiff
<NCommander> oh wait
<NCommander> bah
<NCommander> Screw me, I can't spell "PREEMPT"
<NCommander> morning smb_tp 
<smb_tp> Good morning NCommander 
<NCommander> smb_tp, how goes your morning
<smb_tp> NCommander, Good so far. :) Just got the first coffee. Saw your mail
<NCommander> smb_tp, TheMuso will be uploading the first ports kernel soon, and I'm bending linux-ports-lrm into shape :-)
<smb_tp> NCommander, Sounds great. :) I guess I will give the mail some time today to be seen by others and then pull it to the repo.
<NCommander> \o/
<NCommander> smb_tp, if you have sometime at some point to sit down with the ia64 config files, and figure out what things should be built as modules, it would be apperiated because then I can fix d-i for ia64
<smb_tp> NCommander, I only had a config that compiled (but had to discard serial-modules) and produced some udebs but whether this really is useful for the installer, I don't know.
<NCommander> smb_tp, someone who knows the hardware needs to sitdown and smash the kernel into shape :-/. Even HPPA has working d-i/udeb support and thats the architecture thats usually broken
<smb_tp> NCommander, True. I will try to ask BenC whether he got a little time to help. At least he has the HW
<NCommander> Oh, I thought you had ia64
<NCommander> d'oh
<smb_tp> NCommander, No, I only have access to one (but only as user, so I can't install new kernels)
<NCommander> oh right
<nodeboy_999> hello
<nodeboy_999> ï»¿does apt-get <linux-kernel> provide a static or dynamic kernel image for any given kernel?
<drunkenkilla> hello
<drunkenkilla> i got a problem
<drunkenkilla> i can't change the brightness...the fn-keys and the applet in the panel doesn't work
<drunkenkilla> i tested even now pre-release of fedora 10 and i could change the brigthness with the applet in the panel
<mjg59> F10 implements opregion support which is required for backlight control on a bunch of Intel graphics laptops
<mjg59> It'll be in 2.6.28 of the upstream kernel, but it's not in Intrepid
<psusi> isn't there a libata option somewhere for verbose debugging output?
<rtg> lamont: https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27 has finished building. this time it should _really_ fix your b44 issue.
<lamont> rtg: and which suite does it show up in, I wonder?
<lamont> intrepid-proposed?
<rtg> lamont: yes.
<lamont> kewl
<rtg> lamont: adventurous souls such as yourself should always have -proposed enabled :)
<lamont> heh.  not.
<lamont> well. maybe pinned at 25 :-)
<BenC1> rtg: I'm worried about the patch that fixes backlight key...it's not in upstream yet
<drunkenkilla> BenC1: which patch? i have problems too witch backlight
<BenC1> drunkenkilla: what's the problem you are having?
<drunkenkilla> i can't change the brightness
<drunkenkilla> i'm using ubuntu 8.10 and i can't change the brightness with the fn-keys and the applet in the panel
<BenC> Could be fixed by this patch
<drunkenkilla> but today i tested pre-release of fedora 10 and i could change the brightness with the applet, but not with the fn-keys
<BenC> The case I'm fixing is where the brightness key causes two key press events
<drunkenkilla> i will show you dmesg...
<drunkenkilla> BenC: http://paste.ubuntu.com/67995/
<BenC> drunkenkilla: full dmesg would be better
<drunkenkilla> BenC: http://paste.ubuntu.com/67998/
<drunkenkilla> re
<drunkenkilla> BenC: when will come this patch?
<BenC> drunkenkilla: not sure
<mjg59> BenC: You get an ACPI key event and an event from the keyboard?
<psusi> what did you have to do to see KERN_DEBUG printks again?
<Pici> Howdy kernel people.  It looks like the current kernel compiling help on help.u.com assumes that the user is running Intrepid. I don't really know enough about kernel compiling to split out the directions, but this is the wiki diff that appears to be the culprit: https://help.ubuntu.com/community/Kernel/Compile?action=diff&rev1=69&rev2=61
<Pici> linux-kernel-devel is not on Intrepid and makedumpfile isnt on anything pre intrepid
<BenC> mjg59: yeah
<NCommander> hey BenC 
<BenC> NCommander: hey
<NCommander> BenC, did you see my email to the list?
<mjg59> BenC: I suspect gnome-power-manager is the right place to handle that
#ubuntu-kernel 2008-11-06
<BenC> mjg59: well it stops if I kill acpid (and it happens even at the terminal without X running)
<BenC> mjg59: Actually, I should have answered "no" since I get two actual keyboard events if acpid is running
<BenC> mjg59: noticed by running showkeys
<cathyal> Hi
<cathyal> is the ubuntu kernel based off the debian kernel
<TheMuso> cathyal: No.
<cathyal> figures
<CarlFK> I can cause a kernel panic - what's the app I run to help with the bug report?
<Kano> hi, did you know about the new ndiswrapper problem: http://www.mail-archive.com/frugalware-git@frugalware.org/msg22366.html
<Kano> i see no fix for that in 8.17, or do i miss something?
<rtg> Kano: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=fb54a3e61f44d37b07426f2e7a86d7ca0a99e90a
<Kano> ok, thanks
<NCommander> smb_tp, thanks! (I saw your email)
<Kano> rtg: will you do a 2.6.28 test git soon?
<rtg> Kano: soon, being sometime in the next few weeks.
<CarlFK> "kerneloops is a daemon that collects kernel crash information..."  does that include panic ?
<rtg> an oops is a panic. 
<CarlFK> neat.  it's magic. :)
<CarlFK> I am guessing I have to do something?  kerneloops.org is not loading 
<rtg> amitk is out kerneloops expert
<rtg> s/out/our/
<amitk> CarlFK: once you isntalled kerneloops, a gnome applet should be running in the background
<CarlFK> amitk: what if I am runing on u-server?
<amitk> CarlFK: no UI?
<CarlFK> right
<CarlFK> well, no gui :)
<amitk> CarlFK: ps aux | grep kerneloops 
<CarlFK> if it is a huge problem running it without X, I can load it up - this box is just to hack on this 
<CarlFK> ï»¿ps aux | grep kerneloops = nothing but the grep...
<amitk> just run it manually then
<amitk> with --nodaemon
<amitk> if you want to know what it is doing
<CarlFK> gah - "Connection to cp666 closed by remote host."
<amitk> CarlFK: I guess it was designed mostly for desktop users.
<amitk> cp666?
<CarlFK> I am working with a memory leak, and it kills processes 
<CarlFK> compaq 666mhz 
<CarlFK> hostname 
<amitk> CarlFK: run it manually and let me know what happens.
 * amitk -> steps out for 30mins
<rtg> amitk: what do we have to do to prep the Jaunty kernel to be  a good kerneloops citizen?
<amitk> rtg: add something in the VERSION to identify it as Ubuntu
<amitk> rtg: and info d-i and buildd folks about the same
<rtg> amitk: lets make sure it gets done early, cause its gonna break some stuff, right?
<amitk> rtg: right
<amitk> rtg: who is preparing the tree? you on BenC ?
<amitk> s/on/or
<rtg> haven't started yet. isn't pgraner keeping a list of UDS topics somewhere?
<BenC> amitk, rtg: I'm doing the rebase for jaunty this weekend
<CarlFK> amitk: as memory gets used, processes are being killed.  I bet kerneloops gets killed.  is there some way to prevent that?  (I am guessing best to disable the killing processes process...
<CarlFK> how can I set 80x50 to get more lines on the console ?
<nxvl> hi!
<nxvl> is there any way i can have my own branch in kernel.ubuntu.com?
<nxvl> and how can i create one
<NCommander> nxvl, you need a kernel.ubuntu.com (aka zinc) account
<nxvl> oh
<amitk> CarlFK: use sysctl to write '2' to /proc/sys/vm/overcommit_memory to turn off overcommit. That should keep OOM killer at bay.
<CarlFK> amitk: given I have to keep rebooting the box, what's the kernel param to do it?
<amitk> CarlFK: shove it into /etc/sysctl.conf
<CarlFK> amitk: didn't help: juser@cp666:~$ cat /proc/sys/vm/overcommit_memory ; 2
<CarlFK> still killed lots of processes before the panic 
<amitk> CarlFK: how do you it kills processes?
<CarlFK> amitk: on the console: "out of memory, kill process (123)..."
<CarlFK> I am about to run it in a vm, so I should be abele get screen shots
<amitk> CarlFK: is this a custom app leaking memory?
<CarlFK> amitk: I think it is the vivi v4l2 driver (that is part of vanilla kernel)
<CarlFK> the app I use is the V4L2 sample: caputre.c 
<amitk> CarlFK: ohh.. a kernel driver
<CarlFK> yes
<NCommander> amitk, https://launchpad.net/bugs/290153 - do you know if anyone been working on this?
<amitk> NCommander: not that I know of. Make sure ogasawara knows about it. She is our task master.
<amitk> CarlFK: so running the capture app causes the oops?
<NCommander> ogasawara, https://launchpad.net/bugs/290153 - mind taking a look, I know a few people who are having this one
<CarlFK> amitk: yep
<CarlFK> amitk: I am building up docs on it: http://linuxtv.org/v4lwiki/index.php/Test_Suite#memory_leak_2
<amitk> CarlFK: you might try running ulimit on the capture process to limit its memory
<amitk> man bash -> grep ulimit
<CarlFK> amitk: will that help fix the bug, or just prevent it?
<amitk> CarlFK: prevent the capture process from exceeding its size. If it is the one leaking memory, it should crash first, not other processes.
<CarlFK> amitk: given the memory isn't freed when the app exites, will ulimit help?
<amitk> CarlFK: the app exits correctly?
<CarlFK> amitk:  exit(EXIT_FAILURE);   line 54 http://linuxtv.org/hg/v4l-dvb/file/b45ffc93fb82/v4l2-apps/test/capture_example.c
<CarlFK> if i run the app 8-12 times (depending on box) I get various flavors of crash that require a reboot 
<amitk> CarlFK: can't get into it right now (9pm here). Could you please file a bug with all the info consolidated and how to reproduce it.
<CarlFK> amitk: on lp, right?
<CarlFK> what package?
<amitk> CarlFK: yeah. File it against 'linux' now since you suspect the kernel is oopsing
<CarlFK> amitk: I have a few screen shots of the console - wana see?
<CarlFK> http://dev.personnelware.com/carl/a/qemu_2.png
<CarlFK> 0-4 are the whole sequence 
<CarlFK> er, stops at 3.  4 is this chat window... opps.
<amitk> CarlFK: I find it very surprising that turning off overcommit_memory still triggers OOM
<amitk> CarlFK: what is the line you put in sysctl.conf?
<CarlFK> for that I ran sysctl
<CarlFK> amitk: oh hell... I forgot to sudo 
<amitk> CarlFK: you don't need sudo there. Just add vm.overcommit_memory = 2 to a new line in the file
<amitk> and reboot
<CarlFK> well... takes a while for qemu to reboot
<CarlFK> so I need to sudo for kerneloops --nodaemon ?
<CarlFK> do I... ?
<amitk> CarlFK: you shouldn't need to. But no harm in it.
<CarlFK> amitk: ï»¿kerneloops --nodaemon means if the shell is killed, ï»¿ ï»¿kerneloops goes too, right?
<amitk> CarlFK: yeah
<amitk> CarlFK: kerneloops isn't really a solution to your current problem. If you are able to reproduce this in a VM, then see if you can get a serial console going there.
<CarlFK> amitk: ok.  I have done it, but will take a while to figure that out, so get out of here while you have a chance :)
<amitk> heh
<ogasawara_> NCommander: thanks for the note about bug 290153
<CarlFK> Is this the OOM killer, or something else? [  289.211607] Out of memory: kill process 3980 (sshd) score 2809 or a child [  289.215599] Killed process 3982 (bash)
<soren> CarlFK: Yes, that's the OOM killer doing its thing.
<CarlFK> thanks.  
<soren> CarlFK: It sees you're out of memory and using a set of heuristics, it selects a process and kills it to free memory.
<CarlFK> any idea how to turn it off?
<soren> Stop running out of memory.
<CarlFK> I am trying to gather info about a kernel panic, 
<CarlFK> heh - good plan.
#ubuntu-kernel 2008-11-07
<CarlFK> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294951
<CarlFK> anything else I can add?  
<henrik-kabelkaos> hi! just packaged some drivers for the ralink tech RT28xx series WiFi chipsets. And it would be cool to get that into ubuntu development series. any tips?
<CarlFK> henrik-kabelkaos: check in #ubuntu-motu
<CarlFK> i don't know for sure, but that is where I would start 
<henrik-kabelkaos> i just came from motu. they said it belonged in jaunty and perhaps in the backports-modules package.
<CarlFK> well, so much for that idea.  
<CarlFK> amitk: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294951 "vivi memory leak = kernel panic"
<bsnider> rtg, i'd like to file a bug against LBM as it relates to ath9k. but i'm not 100% sure what information i could include with the report that would make it more helpful
<rtg> bsnider: whats it doing wrong? Helpful info is usually stuff from dmesg, the 'lspci -vvnn' info, etc
<bsnider> well, it's strange. netowrk-manger shows a good connection, but every few minutes, the connection is dropped, there's no question about it. i can't stay signed in to msn, i can't maintain a skype call for more than that time.
<bsnider> i checked dmesg and it doesn't seem to yield any different info than what is there with the regular ath9k, so i didn't know if there was anything else i could put int he bug report
<rtg> bsnider: well, there is probably  some bitching in /var/log/syslog.
<bsnider> ah, i'll check that
<ArShAm> hi all
<ArShAm> I have a question about dvb modules
<ArShAm> is here the appropriate channel for this question?
<ArShAm> I get this : b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 DVB-S rev 2.8' at the 'PCI' bus controlled by a 'FlexCopIIb' complete
<ArShAm>  but I also get this : DVB: Unable to find symbol cx24113_attach()
<ArShAm> and : b2c2-flexcop: CX24113 could NOT be attached
<ArShAm> when I search , I get this : CX24123: it seems I don't have a tuner...<4>cx24113_agc_callback: driver disabled by Kconfig
#ubuntu-kernel 2008-11-08
<kimus> hi, need help compiling a module
<kimus> insmod is giving me a -1 Unknown symbol in module
<kimus> insmod is giving me a -1 Unknown symbol in module after i compiled from linux-source packate
<howdyall> don't know if this is the right place but #ubuntu wasn't much help....i have a problem with ubuntu 8.10....i moved from ubuntu 8.04 to 8.10 but now there is something with my motherboard's Marvel raid controller.  When I have drives plugged into it, ubuntu won't even boot, it puts me into a busy box shell.  I have since tried a clean install of ubuntu 8.10 hoping that would clear it up, but with no luck...   Can I use a 8.04 kernel w
<frankbass> hello
<frankbass> some1 know edimax adapters?
<frankbass> USB EDIMAX EW-7318USG 
#ubuntu-kernel 2008-11-09
<aroth> Hello everybody!
<aroth> I have a question: Is there a way to find out if a PC has been started by the power button or an wake on lan request?
<kimus> hi, I need some help building a module
<kimus> compiled a rtl8187 module but it does not load on the kernel. I think the problem is a version missmatch
<kimus> I tried linux-source package and build module source with make -c /lib/modules/$(uname -r)/build modules and does not load either
<emgent> hello
<kimus> can anyone help me compiling a single module? I can compile the module but gives an error on insmod
<Shanix_> kimus, what error ?
<Shanix_> kimus, you should go to #ubuntu
<kimus> Shanix_: should go to #ubuntu ?!?!
<kimus> isn't this the right channel to ask for help on kernel / module building?
<CarlFK> kimus: /topic ï»¿"kernel development "
<kimus> sorry, for me kernel development is module related
<CarlFK> no problem.  
<kimus> couldn't anyone help? it's kernel related... please :-)
<kimus> #ubuntu is full of people asking stuff
<alex_joni> kimus: if you expect any help, then at least put the error in a pastebin somewhere
<kimus> errors i'm getting > "insmod: error inserting 'rtl8187.ko': -1 Unknown symbol in module", and dmesg gives more > "rtl8187: Unknown symbol
<kimus> so I'm guessing that source != from current kernel
<kimus> alex_joni: any hint?
<alex_joni> kimus: if you expect any help, then at least put the _whole_ error in a pastebin somewhere, including parts from dmesg which are relevant
<kimus> humm... paste wrong here :-)
<kimus> I will put in a pastebin
<kimus> alex_joni: http://paste.ubuntu.com/69742/
<alex_joni> try modprobe
<kimus> modprobe? how can I modprobe from the module I just compiled?
<johanbr> Put it in the subdirectory of /lib/modules/ that goes with your kernel, run "sudo depmod -a" and then modprobe.
<kimus> humm that worked
<kimus> insmod should work :-S
<johanbr> insmod does not take module dependencies into account
<kimus> stupid error... ok thank you. i had to build this module because it lacks an device id
<alex_joni> kimus: lsmod | grep for your module, look at the deps
<alex_joni> then you can load them by hand, and use insmod
<alex_joni> but modprobe is usually easier
<kimus> oh... was only that? I had to modprobe for the deps before insmod ?
<CarlFK> kimus: or load the deps 
<alex_joni> kimus: either you use modprobe (and it pulls in the deps), or you install the modules by hand, then you can use insmod with the new module
<kimus> i get it... next time :-)
<kimus> you should update wubuntu wiki, there's no info on building a single module
<alex_joni> if it's a wiki page you read, then you can improve it yourself
<alex_joni> that's the whole point of the wiki, for people to give back to ubuntu (in a simple way)
<kimus> sure... I can put there how to build and the insmod error :-D
<alex_joni> kimus: make sure the missing device id is fixed upstream or in a later kernel version
<kimus> is fixed on upstream
<CarlFK> alex_joni: as long as you are .. here... :)  Do you have an x64 that you don't mind panicing?  I was asked if a bug crashed it too, and am getting anoyed trying to setup a VM to try it https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294951
<kimus> http://bugzilla.kernel.org/show_bug.cgi?id=11728
<alex_joni> CarlFK: you might mistaken me for a kernel dev :)
<alex_joni> no x64 install atm, nly i386 hardy
<CarlFK> rats.
<CarlFK> back to qemu...
<alex_joni> CarlFK: sorry :/
<CarlFK> wana pannic your i386? :)
 * alex_joni should note he's not running -generic
<alex_joni> but yeah, if it helps..
<CarlFK> I doubt there is anything to gain... so probably not much point 
<CarlFK> na
<alex_joni> I panic and oops it all the time, so it's used :P
<alex_joni> all the time might be an exageration though :D
<kimus> ok thanx
<kimus> bye
#ubuntu-kernel 2009-11-02
<dtchen> sorry about the bug spam, folks. I can't really prevent people from filing bugs clearly caused by the grub configuration not being properly updated.
<EbolaVirus> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<EbolaVirus> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<dtchen> um, what do you need?
<EbolaVirus> ban me 
<dtchen> why don't you just /part ?
<EbolaVirus> why not ban me
<dtchen> sigh, /ignore
<eggonlea_> hi guys, I read https://help.ubuntu.com/community/Kernel/Compile but am still a bit confused about how to update config files. After "make menuconfig", how to merge what I changed in .config to debian/config? I saw /debian/config/config.common and debian/config/ARCH/config.xxx. Should I manually modify all files in /debian/config or replace them with the new .config?
<eggonlea_> which way is recommended to change them? Thanks!
<eggonlea_> [answer my own question] found it. just copy .config to either debian/config/xxx and run debian/rules updateconfigs and then Mr. Proper.
<eggonlea_> maybe the wiki need update a little bit to clarify this "copy" step. I saw lots of guys asking the same question in LP and other maillist. :)
<lifeless> eggonlea_: its a wiki, you can do that
<apw> smb, did we get any testing feedback on the -virtual kernel issues?
<smb> apw, Yes, luckily even good ones
<smb> I guess the plan is to prepare and push everything for upload and then plan for it being up Thursday
<smb> apw, ^
<apw> smb, yeah sounds about right.  we should consider the m586_tsc thing too
<smb> apw, Oh, ok. So I probably should delay the finalizing commit to the kernel to get that in as well
<apw> i guess it could go in with the stables ... as noone has yet mentioned it
<smb> apw, Right. it would be slightly more preferable to stay with the current finalized version. At least for non-lava issues
<apw> smb, then that sounds like a plan
<smb> apw, ack
<indus> hei all 
<amitk> hehe, I like that term: non-lava issue. (assuming it wasn't a typo)
<indus> hi i need some help, can someone oblige
<smb> amitk, no I meant anything that is not melting and very hot
<indus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/425756
<ubot3> Malone bug 425756 in linux "[regression karmic] cd/dvd drive not detected" [Medium,Triaged] 
<amitk> smb: yeah, thats what I thought. I propose we change our bugs from critical to lava and non-lava
<amitk> :)
<smb> amitk, It would be a nice change :)
<smb> indus, I am not sure there is any advice that can be quickly given. The report seems to cover potentially various issues. I believe to remember something about detection in CDs but it might be different too. apw, do you have more recollection there?
<apw> smb, i was just reading same, and i concur there is nothing easy to follow in there.  i thought some cd stuff was improved generally but clearly not fixing this person
<indus> smb: hmm, sorry i dont quite understand 
<apw> indus, what are your symptoms?
<smb> indus, And in your case since when (Jaunty, or before)?
<apw> yep, when did it last work
<indus> ok once i put in the live cd, the cd reaches menu for booting ubuntu etc , then when i select 'try ubuntu without change to your computer' it starts looking at HDD instead of cd drive and later fails with initramfs
<indus> it last worked in Hardy heron
<indus> once i used some boot options pci=nomsi, rootdelay bla bla etcand it worked once to twice but no idea what it does
<indus> works in hardy nicely
<apw> i am not sure if that is the same bug or not, the bug referenced implies a normal boot without cd
<smb> I'd suspect something with libata, as that was one of the major changes after hardy
<apw> so ... i would recommend getting a new personal bug filed with the machine info on it
<apw> and try and get a picture of the failure into initramfs
<indus> apw: yeah the bug is normal boot, but live cd also doesnt work, i instaleld it with usb
<apw> and a dmesg output from there if you can get it
<apw> ...
<indus> wait i give you another live cd bug
<indus> i have one for casper intrepid
<apw> ok if you have a normal boot without CD then what is in the dmesg when it fails
<indus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/425756
<ubot3> Malone bug 425756 in linux "[regression karmic] cd/dvd drive not detected" [Medium,Triaged] 
<indus> no no sorry
<indus> wait'
<indus> https://bugs.launchpad.net/ubuntu/+source/casper/+bug/303654
<ubot3> Malone bug 303654 in casper "[intrepid] Live CD cannot mount - panic Unable to find a medium containing a live file system" [High,Triaged] 
<indus> apw: dmesg says, and also at boot i have a message , libata1 soft reset failed , expecting a reference package element, device not ready
<smb> one problem might be related to rootdelay, I remember there had been issues with waiting long enough for the root fs in some cases. But together with the other behaviour it might be ata related
<apw> so we need to get that log element into the bug so we can see its exact form
<smb> right
<apw> also we need to know the exact hardware you have both mobo / disk interface / drive
<indus> dmesg 3.972516] ata1: softreset failed (device not ready)
<indus> [    3.972519] ata1: failed due to HW bug, retry pmp=0
<indus> asus M2A VM motherboard amd 690 g chipset / sata HDD /IDE samsung combo drive
<smb> I would say booting with an usb-cdrom and replacing "quiet splash" with "debug" on the grub line, and then posting the whole dmesg (maybe try to access the internal drive too)
<indus> smb: i dont have usb cd rom :)
<indus> if i couldget some kernel parameters to boot , i could try 
<indus> rootdelay , so many things i had tried
<indus> but its a hit and miss mostly
<smb> indus, was something with all_generic_ide amongst those
<indus> smb: of course , but it doesnt work always
<indus> i tried it too
<indus> its like, instead of reading the cd drive, it reads from HDD 
<indus> hdd light stays on after cd boots from menu
<smb> indus, How did you say you secceeded booting? From a usb stick?
<indus> smb: yeah 
<indus> flash 
<apw> if the cd is missing then its not unlikely it falls back to the hdd
<indus> no , cd is present when live cd boot i use
<indus> it boots from cd, but once i press menu options, it starts reading HDD
<apw> not to the kernel its not is it ... else you'd not be reportng a missing cd dirve
<smb> Ok, if you do that again and get up (with using the debug line), then gather dmesg, cat /proc/interrupts
<indus> ya ok
<indus> kernel cant see or tries to look in wrong location i believe
<indus> smb: hmm what do i need to do?
<indus> smb: you saw that bug report, i have dmesg in there
<indus> its with the live cd , also have casper.log
<smb> indus, you boot from the usb stick, then on the boot menu you would go to advanced options and edit the line to remove splash and quiet and put debug there instead
<smb> then boot the live image
<indus> smb: ok and ? but with usb it boots fine.
<apw> indus, ok where is your dmesg, the one in the bug you first referenced does not have your message in it
<indus> apw: wait which dmesg you need, normal boot or live cd?
<smb> indus, still it would try to access your cd and hdd and the errors should be there
<indus> smb: here is dmesg from live cd intrepid http://launchpadlibrarian.net/34279545/dmesg.txt
<apw> as the problem is likely the same i am not sure it matters.  debugging on your booted system is probabally easier i'd assume
<indus> http://launchpadlibrarian.net/34279424/casper.log  this is casper
<apw> indus, that dmesg is from a .27 kernel
<indus> apw: yeah have had the problem since 
<indus> apw: ill give you karmic dmesg then
<indus> apw: http://launchpadlibrarian.net/31444487/BootDmesg.txt
<smb> which is also a bit outdated
<indus> aah ok
<indus> so you need the current kernel
<smb> indus, Have you tried with the release version?
<indus> smb: of course, iam fully updated to release
<indus> basically, as i stated earrlier, hasnt worked in any kernel after hardy 8.04
<smb> indus, Just the log you had was from 2.6.31-9. And at the current point, when looking at the problem it helps to start of as recent as possible
<indus> aah damn it, iam at work now
<indus> diff system
<indus> ill give you dmesg with latest one in evening then
<indus> anyother way i could get cd rom to be read?
<indus> temporary solutions
<indus> secondly, i have a general question about multi threaded applications
<indus> nvm
<apw> oh so this sm600 system isn't the right one
<indus> apw: ?
<apw> nothing springs to mind without knowing more about it.  a current dmesg can't hurt and if you have a dmesg from hardy that might be useful to se ehow it was recognised in that kernel
<smb> indus, Sure. And with those kind of problems, it also helps when we have a good summary on how things are connected (should the drives be on the sata port, or ata, are the sata ports set to ahci or ide) all that stuff. Thought info can be found in the dmesg it is slower to gather it manually.
<indus> smb: in bios its set to ide controller
<apw> i interepreted what you suggested there as saying the second dmesg is not from the system
<indus> smb: HDD is on sata port
<indus> apw: no no all were filed from my system, iam just chatting with you from work system
<smb> indus, from the log it seems ahci is firing up
<indus> smb: hmm i must have fiddled iwth bios settings that time
<indus> smb: but itsdefault on ide controller,there are 2 other options raid and ihce
<indus> but i use ide 
<indus> also, the cd drive is connected with this wide and thin cable , which ironically says 'asus HDD cable'
<indus> i believe its ide cable
<smb> indus, Ok, so this is all stuff that we should have in the bug report. The better we know how things should be, the better one can spot differences.
<indus> smb: hmm where do i add it
<indus> smb: apw ill try to give you a 8.04 dmesg, and ill attach it today
<smb> indus, You either edit the description section of you bug or add a comment with it
<indus> smb: ok
<indus> but is that really necessary? 8.04, man ill have to install it and all that
<indus> just reinstalled 9.04 a few days ago
<apw> indus, you could boot the livecd for 8.04 and take it from there
<indus> wait let me get an old bug with hardy then
<apw> as the cd works in 8.04
<indus> apw: hmm , from live cd when it boots into desktop?
<apw> yep ... it must have detected and used the CD
<indus> yes ok ill surely do that today, 
<indus> apw: so from a terminal i type dmesg and paste it there in report?
<indus> i mean, no need to install right?
<smb> indus, you actually should have network from the live cd and could add it to the bug report
<smb> indus, No need to install
<indus> smb: ya i know, i have network, ill add it
<smb> Its just to get a dmesg from a working case as compared to a non-working
<indus> let me see if i can do this in an hour or so
<indus> so i have a question,is the kernel in C?
<apw> the majority of the kernel is in C yes
<indus> apw: smb i have an ubuntu 8.04.1 cd , is that ok?
<apw> if the cd works yes
<smb> what apw says
<indus> also one more important thing here, some peopel had this problem befoer hardy and some patch fixed it, so it fixed for some and broke for me
<indus> not sure if its related though
<indus> nvm
<indus> ill brb and upload dmesg
<indus> 5 min
<apw> indus, i note that your karmic kernel is an old one 2.6.31-9.29 ... the current one is -14.28 or so
<smb> apw, Not sure about the .28 but certainly -14
<smb> -14.48 I would guess
<apw> doh ... typo
<indus> ok got the dmesg
<indus> apw: i attached the kernel
<indus> its ATAPI cd drive , is that different from ide
<indus> guys are you there? smb apw
<smb> indus, yes. not so much difference that it should not work
<indus> so now what :)
<smb> indus, you happen to know whether the cd driver is specifically set to master or slave?
<indus> smb: ooh dont remember, wait i came back to office now, :)
<indus> smb: slave i think though
<indus> smb: isnt it in the bios post screen?
<smb> and exactly where has the dmesg gone?
<indus> smb: dmesg i attached to bug report
<smb> indus, you added to the first or second bug
<indus> smb: hmm karmic bug report
<smb> indus, ok
<smb> indus, And the drive definitely should be set to master
<indus> smb: hmm ok how do i do that
<smb> it is the only drive on the pata bus
<smb> I would not know except by opening the case and look at the drive
<smb> in theory there should be a selector
<apw> sometimes its cable select, so it depends which connector on the cable its connected to
<apw> smb, how did you tell it was a slave from the dmesg?
<smb> apw, No I am working on indus statement atm
<smb> I have not got to the dmesg itself yet
<apw> i had the feeling it was a slave too, and am wondering what i saw to trigger that
<smb> if that is visible there anyways
 * smb wonders whether it would be visible in the bios. maybe, depending on how good/bad that is
 * apw shakes his head at all the 'sb600' needs workaround messages in the karmic dmesg ... a lemon of a machine i recon
<indus> i think its visible in my bios , i remember the words
<indus> its a beautiful chipset actually :) onboard graphics are really good
<indus> in the first post messages, it mentions HDD first ,then cd drive is probably slave , ugh i dont really remember
<indus> apw: its a 1 mm thin 5 cm wide cable connected to mobo
<smb> Well, as your hdd is sata that would be different worlds
<indus> ya hdd is sata sure, so no master slave business
<smb> the cable might provide cable select ability but this needs to be supported by the drive
<indus> cable select, its a simple cable,a wire
<apw> [    1.000067] ata5.01: NODEV after polling detection
<apw> smb, looking at other messages i think that that can be .00 and .01 and .01 is slave
<apw> (this is from karmic dmesg)
<smb> indus, its one of the cables deliberatly broken after one of the connectors
<indus> smb: sorry i dont know this one
<apw> there were some changes in the final karmic kernel to handle better selection of speeds for pata disks ... speed of the io over the cable. which might be related to the issue
<smb> So there might be disagreement between controller, cable and drive what should be master and slave
<indus> aah internal fighting :)
<apw> i wish they documented what these damn messages really are meant to mean for humans
<smb> apw, Also the dmesg of hardy shows the cdrom as hdb (which would be another indicator of it being slave)
<indus> yeah hdb 
<indus> i noticed
<apw> yeah smb i think thats pretty definative... though that means it can work
<apw> and i think the .01 failure indicates it found something on the cable and rejected it as a broken thing
<indus> where is this .01? in 8.04 dmesg? or new one
<smb> indus, yes that was in the new dmesgs
<indus> hmm which line is this? lots of .01, just interested in knowing
<apw> [    1.000067] ata5.01: NODEV after polling detection 
<apw> pretty sure ata1-4 are your sata ports and ata5-6 are your pata ports
<apw> i think the .01 can be .00 and .01 and i think they are master and slave indicators in this context
<apw> not yet confirmed that but it seems more than conincidental that is emmitted
<apw> and that message means 'i talked to it and it was junk so i am ignoring it'
<smb> indus, What I would suggest, when you get home. Try taking out the drive and check, whether it can be manually set to master or slave. I would suspect it can, as you said you use the hdd cable and probably the last connector (leaving the middle one free) and I believe those are wired to set cable select capable drives to master
<indus> smb: i think it can be
<indus> smb: some jumper settings which iam a little scaredof
<apw> i note that the bios is setting the drive to pio mode in the hardy dump, and the NODEV message in karmic is sometihng which can only be emitted in ATA PIO mode:
<smb> hopefully documented on the drive and not in the documentation one usually discards quite soon
<apw>                                         /* If diagnostic failed and this is
<apw>                                          * IDENTIFY, it's likely a phantom
<apw>                                          * device.  Mark hint.
<apw> so its very likely that line indicates that the drive is being dropped as it failed to respond appropriatly
<apw> for some definition of appropriatly
<indus> smb: hmm there is a connector in the middle of cable you mean? hmm i will check this 
<indus> smb: http://www.cksinfo.com/clipart/electronics/computers/cables/ide-cable.png 
<indus> this one?
<smb> indus, those ata flat cable connectors I know usually have three connectors...
<indus> whats the middle one for
<smb> indus, yep, iirc blue goes into the board side and black and gray would be master and slave drives
<jk-> middle is generally slave, IIRC
<smb> jk-, Yeah, so do I 
<indus> http://www.novell.com/coolsolutions/img/16837_ide-cable.gif
<indus> make up your minds
<indus> :)
<indus> *joke*
<indus> ok let me get this right, i set cd drive to master, but connect the cables as it were? 
<smb> indus, Well doesn't that prove us. :)
<indus> yeah heh
<indus> what if i let cd drive remain slave and connect that middle grey one? just wondering
<smb> indus, yes, I believe there had been issue running  slave only setups like this
<smb> as a general rule, if there is only one drive on the cable it should run as master
<indus> smb: hmm but ther is only 1 drive
<indus> smb: i hada floppy, on another port which i removed after karmic got stuck with floppy mesages
<smb> indus, soooo? ;-)
<indus> smb: i mean, since ther is only 1 drive, shouldnt it run as master
<indus> bah nvm , iam speculating
<smb> I thought thats what I said :)
<indus> smb: anyways ill set it to master manually
<indus> smb: will you guys be around here in a few hours?
<smb> indus, Chances are good
<indus> excellen
<indus> t
<indus> now,i have a general question for you guys/ladies
<indus> i have this game called quake4 which has an executable called quake4-smp which takes use of dual cores
<indus> ever since karmic alpha 4 it crashes now, is this a kernel thing or an application thing
<indus> i guess this is too little information for you , but i wonder what the problem could be
<smb> indus, An application crashing is certainly an application thing. 
<indus> i get a segmentation fault 
<indus> was wine since dapper drake 
<indus> fine
<indus> funny thing is , if i run the regular non smp file and enable smp in console it runs fine
<indus> ok  but can this qualify for a regression?
<apw> you could try stracing the -smp version and see what it does just before
<apw> its likely its something that the app is running to find out how many cpus there are or something
<apw> something which is likely allowed to change, and something userspace is meant to cope with
<apw> coredumping would clearly be a fail on the applications behalf
<apw> s/clearly/very highly likely/ ... if i am totally fair about it
<indus> apw: ok , but if this application worked fine for 2 years, and started crashing in the newer karmic os, what is the solution
<indus> i wrote to id software, but unlikely they will do anything now
<apw> newer karmic kernel and user space ... well if the app is broken in some way which is now exposed by karmic thats not likely something we can fix for them
<indus> hmm
<apw> if its breakage in the kernel/userspace then we can address that
<apw> figureing out which with a closed source app would be very hard
<apw> though i would start by stracing it and seeing what it did last
<indus> apw: ok ,hmm  iam going to try running this gaem with hardy today again to make sure its not a corrupt data file
<indus> apw: running strace <gulp> ill try reading more on that
<indus> apw: could you explain userspace 
<indus> apw: also, what is it i could do for you to address the kernel/userspace issue in relation to this application?
<indus> if any*
<apw> userspace == everything thats not the kernel and not your application in this case
<apw> so libraries and the like... they could have had a bug fixed which the app is relying on for instance
<indus> oops sorry
<indus> i got disconnected
<indus> apw smb hello again
<apw> hi
<indus> any further comments on my bug?
<indus> apw: setting jumper will involve physically dismounting the drive isnt it?
<apw> i would expect so, the jumper docs are bnormally on the bottom of the drive
<apw> i am building a test kernel with some additional diagnostics information to try and find out which of three cases are triggering the drive reject ... which may help understanding
<indus> the three cases would be?
<indus> this is all so interesting, i should learn some C i guess
<indus> also, would you like me to test this kernel you are building?
<apw> the three cases are a controller diagnostic failure, an HSM violation, and a stuck register check
<apw> when the kernel is built and pushed up i'll add some instructions and commenty to the bug with the details
<indus> bye now and thanks
<indus> ill drop in later in 3 hours or so
<indus> apw smb hooray it works when i changed it to master 
<indus> so now what
<indus> :)
<indus> i want to thank you for this help
<apw> indus, heh well thats good new.  first thing is to report that in the bug
<apw> did you boot my kernel at all? before that?  might be interesting to have that data
<indus> ya cool isnt it, and i finally found out what a jumper is
<apw> but with the drive as slave
<indus> which kernel? havent checked the report
<indus> you added ?
<indus> i just came home
<apw> i pushed a kernel to try and find out why it errored there
 * indus is happily browsing through the 8.04 cd  
<apw> very nice
<indus> iam really greatful (i hope i spelled that right)
<indus> finally iam gonna rent some dvd's 
<smb> Im not very positive having a single drive forced to slave is a use case which would be thought of supported
<apw> heh well please do write up that you change it to master and it started working
<smb> It might have worked with the old driver but ...
<indus> smb, hmm?
 * apw isn't at all convinced there is any techinical reason that the slave should not work on its own
<apw> but ... its good to know how to make it work
<apw> its possible that the error from the master failing is getting in the way of the slave identify
 * cking is bemused by thus too
<apw> its possible its an obvious thing to upstream
<smb> If I recall that correctly there is some relationship between detection sequence and used ports
<indus> apw yeah, not all people will be able to drop in here and do the master slave thing
<indus> lucky i had  a screwdriver
<apw> indus, if you have the energy to put it back as slave then test my kernel it may help us in deciding what if anything to report upstream.  if not not the end of the world
<apw> but do report your success either way
<indus> apw, what is the size of kernel?
<apw> 25MB or so
<indus> hmm
<smb> So they go somewhat master, then slave. But when no master is found they might stop. Maybe even the drive keeps silent unless it "heard" his master
<indus> ok so just download and install the kernel?
<apw> i think in this case we get a controller level error on the master and then that is still pending when the slave error occurs and that moves that drive to bust
<apw> possibly incorrectly.  though i am cirtian that master is the preferred place for a dive
<apw> drive
<apw> indus, is only worth doing that kernel if the drive moves back to slave ... else it'll report nothing new
<indus> ya ill move it back to slave
<indus> but which kernel exaactly? i see a few 
<indus> oops sorry headers  and image, so i need 64 bit and all.deb?
<apw> if you don't have any binary drivers then just the kernel image is enough
<indus> i have nvidia
<indus> actually iam not sure what you mean
<apw> so you need the headers too and the all
<indus> so headers amd64,image amd64 and all.deb
<indus> downloading
<apw> indeed so
<apw> thanks for testing
<indus> no problem at all
<indus> so i install it now? or move slave and then?
<indus> yikes i already installed
<indus> aah boot time i guess
<indus> will this appear in grub?
<indus> brb 
<root> hi
<root> smb: help
<smb> indus, what's up?
<indus> i installed those kernel and now my screen flickers , but i dont see that kernel in grub
<indus> wher is apw
<indus> man
<apw> ?
<smb> indus, it would be a bit strange when a kernel, you not even see in grub would affect your system. sure there was no looseing of cables while switching back to slave
<apw> what kernels do you see
<apw> the kernel should have been a -15 right?
<apw> which should be separate from your real kernels
<apw> hmm he is gone
<smb> Loose power cable?
<indus> smb: just do me  a favour, please go to that bug report and tell me name of kernel which andy gave
<indus> i have to remove it
<indus> x wont start for me now
<smb> indus, So nvidia module does not get rebuild correctly... a sec
<indus> yeah but i cant see  that kernel in grub either, i booted normal kernel, i guess x starts after that doh !
<smb> should be linux-image-2.6.31-15-generic_2.6.31-15.49~lp425756apw1
<smb> as the package name
<indus> how come i dont see it in grub?
<smb> indus, Its a bit strange as the nvidia modules should get rebuild when you install that. All the kernels before were -14. And it should be in grub as well
<indus> hmm i have a 15, but it doesnt say fullk name
<indus> but i booted 14 and that too wotn get to x
<smb> The latest release kernel was -14.48, so everything saying -15 is new
<indus> anyways ill brb
<indus> ok solved
<indus> smb, but when i did apt-get remove and pressed tab, it only showed upto 15 , not the full name
<indus> phew
<smb> Glad, to hear. Though I cannot see how installing a -15 kernel would kill your -14 version... 
<apw> indus, so what happened there?
<indus> smb, i swear it killled 14 too
<indus> apw, display trouble
<apw> yeah installing -15 would not normally have any way to touch -14
<indus> apw, well , it happened i swear
<Darkness> question: to enable bluetooth on my laptop, i need to load a module. the problem is i have to do it everytime i reboot. is there anyway to load it automaticly?
<apw> indus, well lets call it day on testing, and just get you to report 'moving to master fixed it for me' to the bug
<indus> apw, :)
<apw> we can let the others play with -15 if they can't move to master
<smb> Darkness, Tried to add it to /etc/modules?
<indus> apw, iam willing to try it 
<apw> Darkness, what smb said
<indus> apw what about your kernel then, you make new one?
<Darkness> ok ill try, thanks
<indus> also,what do i mark the bug report as? 
<indus> this will need to be addressed isnt it?
<apw> indus, i'll try booting it on my other laptop, it would be unexpected if there was anything wrong with it
<indus> apw did i mention , i didnt get display, i have nvidia 
<apw> indus, as for the bug, we'll need someone to be able to run the debugging kernels if we are going to get a s/w fix for them
<smb> indus, The status likely stays on whatever it is now. We just need to get that info in as a comment to help others
<indus> ok i do it now then
<apw> indus, your info is a good work around so we don't need to change the status at this juncture
<apw> smb, if this is an nvidia interaction its likely in your pre-proposed kernel too ... 
<indus> so i suppose, this bug is not amd specific then, and could happen to anyone?
<apw> got any nvidia stuff to test on
<smb> indus, and you installed linux-image and linux-header-generic and linux-headers*all for the -15 kernel?
<indus> wait
<smb> apw, I would expect it to behave the same way. Only adding the ppa offers all required packages in one without need of dpkg -i
<apw> smb, yeah so if indus installed all three and its not working then we may have an issue on the horizon
<smb> indus, It still might depend on amd (as in the controller of the sata/pata)
<smb> apw, If, maybe but somehow it seems very odd. Let me boot my desktop with nvidia and update
 * apw is suspicious its related to the combination thereof ... the kit in that machine has many a brokenness qurked around
<Darkness> another question: shutdown and reboot through gnome gui doesnt work. it logs me out, the screen turns off, and then the pc just get stuck. any idea why?
<indus> yes i installed 3 things , http://people.canonical.com/~apw/lp425756-karmic/linux-image-2.6.31-15-generic_2.6.31-15.49~lp425756apw1_amd64.deb
<indus> http://people.canonical.com/~apw/lp425756-karmic/linux-headers-2.6.31-15_2.6.31-15.49~lp425756apw1_all.deb
<indus> http://people.canonical.com/~apw/lp425756-karmic/linux-headers-2.6.31-15-generic_2.6.31-15.49~lp425756apw1_amd64.deb
<indus> correct ?
<apw> looks correct to me ...
<indus> shall i install it again to double check? 
<smb> yep
<apw> indus, be nice to see the output of those commands if you are willing to install them
<indus> also, why would it only show 2.6.  15 and not the full name of the deb file
<apw> put them in pastebin or something
<indus> apw which commands
<apw> indus, the output fromt he install commands, as we should see dkms doing things for nvidia etc as it goes
<smb> indus, That might be because the grup lines do not show the release numbers, only the -15-generic part
 * indus updated the bug report and thanked 2 people
<indus> smb, no no ,also when i wanted to remove with apt-get, it didnt show full name
 * apw installs the kernel on a misc  machine
<apw> indus, right you remove by package name, not version
<apw> the package name happens to contain the 2.6.31-15 part of the version as well as being in the version
 * indus scratches head
<apw> that is how we let you have more than one kernel install
<apw> look at a simple package like upstart ... its just called upstart
<indus> aaah ook the 3 packages together make the kernel?
<apw> and you can only have one of it installed
<apw> yep those three packages are the kernel, and there can be more than one set installed
<apw> so you can boot back when it fails
<indus> wait stay online
<apw> so you'l find 3 lots of -14 and 3 lots of -15 installed
<indus> aah crap wrong channel
<indus> lol
<indus> ok iam too tired now, all over my head
<apw> indus, all you need to remember is the names of the kerenl are complex and confusing ... and its necessary :)
<indus> apw, so can i do this tomorrow now?
<indus> smb, did you try the kernel?
<smb> Shoot, seems I haven't booted that for a while... no its first 550MB of other stuff that needs to go on
<apw> indus, whenever
<indus> ok its 9 30 pm here, need to shower etc :)
<indus> apw, jusst tell me, which commands were you talking about?
<apw> i would be interested to see all of the output that the dpkg -i commands produce when you install the three packages of mine ...
<apw> that should include some install information for the the nvidia stuff which would be handy if there is an issue there
<indus> apw hmm from a terminal 
<apw> yeah from a terminal ...
<apw> you can use 'script' to record the output
<indus> sorry dont know anything about script
<smb> indus, you could also the old fashioned way and add "2>&1 |tee logfile.txt" to the dpkg command
<indus> iam a noob really
<indus> give me full syntax please
<smb> indus, just to be safe, you were amd64 or i386?
<indus> smb dpkg -i filename 2>&1 |tee logfile.txt ?
<indus> amd 64
<smb> dpkg -i linux-headers-2.6.31-15-generic_2.6.31-15.49~lp425756apw1_amd64.deb linux-headers-2.6.31-15_2.6.31-15.49~lp425756apw1_all.deb linux-image-2.6.31-15-generic_2.6.31-15.49~lp425756apw1_amd64.deb 2>&1|tee logfile.txt 
<indus> smb, so all individually ?
<smb> indus, all 3 files in one go
<indus> smb, so shall i copy paste those commands ?
<smb> indus, if line break does not get messed up that should work
<smb> indus, it is just one command
<smb> with the 3 packages as agruments
<indus> smb, ok wait
<indus> i have a 15 min window befoer all shops close here :)
<indus> then iam doomed
<smb> indus, then I would propose to do that first and then come back
<indus> np
<smb> We don't want to be responsible for someone starving
<indus> lol dont worry
<indus> its not food but cigarettes
<indus> also a phone recharge
<indus> oh no
<indus> wrong commands
<indus> my mistake
<indus> got it
<indus> how do i give it to you?
<smb> attach it to the bug
<indus> done
<indus> check it out
<indus> ill see you in 15 min
<smb> k
<indus> ok smb it works
<indus> Linux rajeev-desktop 2.6.31-15-generic #49~lp425756apw1 SMP Mon Nov 2 11:44:42 UTC 2009 x86_64 GNU/Linux
<indus> i probably missed a package
<indus> or maybe was some other problem 
<smb> Seems 15mins are quicker in other places. :)
<smb> But good
<smb> Still it should have not effected the -14 part
<smb> indus, Now it will be interesting to get your new full dmesg attached to the bug as wel
<indus> i changed it to master though :)
<smb> indus, the drive?
<smb> that would make the dmesg useless
<smb> We'd need one with the drive failing 
<indus> smb, ya ok ill set it to slave again
<indus> damn
<indus> smb, what changes are there in this new kernel that will make you fix the issue?
<smb> indus, not fixing, apw put in debug messages to see which of the three things will fail
<indus> aah ok ok
<indus> ill brb
<bdmurray> Why are apport-kerneloops still being reported about karmic?
<Ng> bdmurray: possibly /usr/share/apport/kernel_oops needs to check /etc/default/apport ?
<indus> smb, apw hi i attached dmesg
<apw> indus, damn lost the link to the bug, can you remind me of the number
<indus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/425756
<ubot3> Malone bug 425756 in linux "[regression karmic] cd/dvd drive not detected" [Medium,Incomplete] 
<apw> kd
<apw> indus, i take it your video worked this time round on my kernel?
<indus> apw yeah
<apw> smb, good news on the nvidia video with -15 ...
<indus> probably messed up installation
<indus> apw, yeah he knows already 
<indus> so  does dmesg say anything noteworthy
<smb> apw, indeed :)
<apw> it says this is an 'HSM violation' ... and the drive is rejected
<indus> ok
<indus> now?
<apw> now one needs to know what the heck it mean
<indus> lol
<apw> stupid acronymus
 * indus googles it
<indus> apw i go now
<apw> indus, ok
<indus> apw, smb bye bye, ill keep checking the bug report
<smb> bye
<indus> apw, anything else you need?
<apw> not till i know what it means ... thanks
<indus> ok bye and thanks a million,i will set this to master till you have any new things
<Kano> hi, is there a reason why the -15 kernel was not updated to 2.6.31.5? 
<dtchen> bjf: hi, received your e-mail and will follow up. Traveling a bunch this week, so apologies in advance.
<bjf> dtchen, understood
#ubuntu-kernel 2009-11-03
<kees> jjohansen, arjan: I will now get out of this communication loop.  ;)
<arjan> hehe thanks
<jjohansen> arjan: I have kicked off a debug kernel build for you, I'll ping you when its done
<arjan> all I need is the drivers/acpi/processor-idle.o file
<arjan> http://www.kerneloops.org/oneweek31.php
<arjan> that is currently mostly ubuntu reports (until Fedora 12 ships I suspect.. then it'll be amix)
<arjan> looking at the nr 2 issue
<arjan> and failing to make sense out of it without knowing exactly which instruction we're executing
<arjan> -> hence the request for vmlinux or drivers/acpi/processor-idle.o
<jjohansen> arjan: okay, I just build that then, it will be quicker
<jjohansen> arjan: http://kernel.ubuntu.com/~jj/processor_idle.o
 * arjan grabs
<arjan> thanks a lot!
<arjan> ooh fun
<arjan> this is in a paravirt hook
<arjan> anyway that's good food-for-thought
<arjan> thanks again
 * arjan will ponder more after dinner ;)
<eswenson> Is there an irc channel where I can ask a question about the ubuntu/debian kernel build environment?
<rtg> eswenson, this is the right channel, but most folks are about gone. can you post an email to the canonical-kernel-team@lists.canonical.com list?
<eswenson> rtg: I could, but I'm not on the kernel team.  I'm just a developer who has a need to update/add modules to a local copy of the kernel.  Can I still send email to canonical-kernel-team list?
<rtg> eswenson, yep, I'll moderate it later tonight.
<eswenson> rtg: And my question regards the jaunty kernel, not the karmic kernel.  Ok, I'll post the question to the list.  THanks.
<indus_> hello
<Appiah> On launchpad bugs , should the team be the ones selecting confirmed and priotrity?
<Appiah> or the team?
<Appiah> or the user* i mean
<JanC> Appiah: confirmed is if other people can reproduce the same bug, so it can be another user
<JanC> priority is for the developers (or team managers or such)
<JanC> never confirm your own bugs though ;)
<apw> Appiah, yeah what JanC said ... the priority is covered by our 'policy' so data loss is critical, crashes are high or medium etc
<apw> the status implies things about the bug, co
<apw> confirmed for more than one user, trigaged for 'having all the data we need' etc
<hyperair> does anyone know if there's a difference between the sreadahead and the ureadahead kernel patches?
<hyperair> and how come the said patches aren't entering mainline?
<apw> hyperair, yes the patches differ.  and as it says in the leader to those patches, we are expecting a more sane common and standard way to trace all syscalls via ftrace which would superceed most of the patch
<hyperair> @_@
<hyperair> i see
<hyperair> you really meant header and not leader, right?
<apw> those words mean the same thing to me for patches ... :) ... the description of the patch
<hyperair> are you sure "leader" can be used in this context?
<hyperair> "leader" applies to a person who leads, right?
<apw>     It's not upstream because it will need to be rebased onto the syscall
<apw>     trace events whenever that gets merged, and is a stop-gap.
<apw> a leader is something or someone who leadsd
<apw> the header arrives in your eyes first, so i can be called a leader
<apw> english is stupid
<apw> you get a similar confusion with rider, a rider can be someone who rides or it can be something which is carried with and is a bout something, like a limitation
<hyperair> @_@
<hyperair> alright, point taken
<apw> hyperair, apparently we have 12 meanings for leader
 * hyperair groans
<apw> 1. 	a person or thing that leads.
<apw> is the one i was using it in
<hyperair> ah
<apw> you don't need to remind me that english is massivly ambigious even to native speakers and a nightmare for the rest of the world :/
<hyperair> so anyway, what does ureadahead require that the sreadahead patch doesn't provide?
 * hyperair considers himself to be a native speaker of english
<apw> it needs to know which binaries you are running
<hyperair> ah i see
<hyperair> well then off i go to hack the ureadahead patch to apply ontop of sreadahead's
<apw> hyperair, why so?
<hyperair> apw: i compile and run the zen kernels. they have the sreadahead patch applied.
<hyperair> but not the ureadahead one
<hyperair> maybe i'll go suggest to them
<apw> well we are expecting to switch out sreadahead for ureadahead at the same time that the kernel updates
<apw> and i assume xen is a patch on top of our main branch
<apw> so they should switch when they rebase
<hyperair> zen, not xen.
<apw> ... oh yeah ... no idea :)
<hyperair> heh
<hyperair> and no, zen isn't a patch..
<apw> what the heck is zen
<hyperair> it's a tree
<hyperair> http://www.zen-kernel.org/
<hyperair> it's the mainline with all kinds of unapproved extras applied
<hyperair> stuff like phc, bfs, tuxonice
<hyperair> and they frequently pull from mainline
<apw> gotcha
<apw> so you'd want them to have 'both' so you can use that kerenl with ubuntu userspace i assume
<hyperair> but of course
<apw> sounds like fun for them :)
<hyperair> heh
<hyperair> well the ureadahead patch isn't much on top of the sreadahead patch, is it?
<hyperair> i only had one conflict
<hyperair> and that conflict was from stuff already added by sreadahead
<apw> i think it produces more data for the existing sreadahead hook iirc
<hyperair> yeah it does
<apw> dunno how sreadahead would take that change
<hyperair> isn't it a different ftrace?
<apw> to be honest sreadahead has major issues, like its not aware of hdd ... so it makes things worse there
<hyperair> agreed
<hyperair> my boot up time is 2m 30s
<hyperair> this is ridiculous
<hyperair> readahead-list was way better
<hyperair> why did we get rid of that?
<apw> yeah ... it was ... and ureadahead is fixing that and doing better
<apw> was where the majority were going, and probabally was wrong
<hyperair> yeah, at least we don't need readahead-list wasting time setting up inotify hooks on every single file on the filesystem >_>
<hyperair> there was quite some noise made re readahead-list's removal, but somebody said that sreadahead's packfile was equivalent if not better <_<
<hyperair> and conveniently stifled out all the noise by invalidating said bug
<hyperair> very elegant.
<apw> heh ... sometimes you need to try things, find its wrong, and fix it
<apw> i think thats what happened here
<hyperair> heh i suppose =\
<hyperair> aw damnit it won't compile
<Appiah> JanC and apw thanks for the explaination
 * hyperair reverted every sreadahead commit on the list and then applied the ureadahead patch
<michLinuxGuy> Hi!
<apw> s'up
<michLinuxGuy> Question: How do I install an older pre-built kernel on Karmic.  (Like the kernel used in Jaunty) ???
<michLinuxGuy> I am trying to troubleshoot a failing wireless adapter
<apw> older kernels are available in the launchpad librarian, i blieve all of them are there
<michLinuxGuy> Do I get to that from synaptic?  Or can you give me a URL?
<apw> you can get to the current ones at least here: https://edge.launchpad.net/ubuntu/+source/linux
<michLinuxGuy> Thanks!
<apw> this link looks to show you _all_ kernels ever: https://edge.launchpad.net/ubuntu/+source/linux/+publishinghistory
<michLinuxGuy> I have a Linksys USB wireless adapter that won't connect now that I installed Karmic.  It worked fine with Jaunty.  I'm going to try the Jaunty kernel with my karmic installation.  Does that sound like a good approach to diagnosing this?
<apw> michLinuxGuy, yep ... what device is it inside?
<michLinuxGuy> ID 13b1:000d Linksys WUSB54G Wireless Adapter
<michLinuxGuy> I tried the adapter on another machine with karmic and it did work, but dropped and reconnected once.
<apw> odd
<michLinuxGuy> Yeah.  This was with a clean install.  I could try reinstalling, but I think I will try the older kernel first.
<michLinuxGuy> The problem machine is an older HP laptop: ze4210
<michLinuxGuy> apw: Are the links you showed me source only?  Is it possible to get a prebuilt .deb file with the kernel and modules?
<apw> michLinuxGuy, binary packages appear to be there if you click trhough the build links for an architecture
<michLinuxGuy> I guess I am not as smart as I thought I was.  I can't quite find what I need to install an older kernel from binary.  :(
<michLinuxGuy> To install a binary kernel, do I just need an image .deb and a .deb containing the kernel modules?
<apw> michLinuxGuy, the linux-image contains the whole kernel, if you have any binary drievers you also nead the linux-headers, and the generic headers the _all package which is only built on i386
<michLinuxGuy> apw: Thanks for all your help.
<michLinuxGuy> apw: I installed kernel linux-image-2.6.28-16-generic_2.6.28-16.55_i386.deb and my linksys USB wireless adapter started working again.  Do you have advice on what I should do with this information?
<apw> file a bug using ubuntu-bug when you are booted on the karmic broken kernel.  include a dmesg from the working kernel
<apw> and clearly mark that dmesg, and clearly indicate the version you found it does work 
<michLinuxGuy> apw: Thanks, I'll do that.  One note: the symptom is it finds the access pt, but never connects and times out.  I didn't see anything informative in the dmesg output about it.
<apw> but having both tells us if the same driver picked up the device and the like
<michLinuxGuy> apw: Okay - will do.  Thanks!
<michLinuxGuy> apw: I submitted a bug for the problem [Bug 472953].  Thanks again for your help with this.
<ubot3> Malone bug 472953 in ubuntu "Linksys WUSB54G won't connect to wireless network with karmic kernel" [Undecided,New] https://launchpad.net/bugs/472953
<tormod> is the Mainline Kernel PPA source web-browseable somewhere like with cgit?
<cwillu> tormod, it's just the vanilla kernel, so kernel.org
<tormod> cwillu, thanks, right, I guess that's the whole point of the PPA :) but there is some Ubuntu building stuff like a debian dir?
<cwillu> can't speak to that, sorry :p
<tormod> btw there is 2.6.32-rc6 now
<tormod> is the daily ppa build exactly like the upstream "snapshot" or is it a pull from linus tree at some time of day?
<cwillu> I would guess that it's a package for each tagged upstream release
<tormod> yes, but plus the daily builds
<cwillu> sorry, missed that
 * cwillu clams up
<tormod> thanks for answering
<_maks> hey
<_maks> the gitweb installation on kernel.u.c seems quite old
<_maks> what's the refspec to clone http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=summary
<_maks> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git # works
<_maks> would be cool to have that on gitweb ;)
#ubuntu-kernel 2009-11-04
<NCommander> apw, just a off question, but why break the ABI range for ARM kernels; its a different source package after all. (I curious at the rationale why imx51 starts at 100, and dove starts at 200 ...)
<theemahn> I think this is the place, I want to be straight kernel issue with 9.10, not a showstopper right?
<apw> NCommander, we have split ABI ranges because the shared header packages collide in the archive.  that could likely be resolved by renaming that package but at the time it was simply less risk to split the abi
<NCommander> apw, ah, that makes sense. I was just unsure the reasoning behind it
<apw> yeah mostly lack of time to go the 10 uploads needed to get it all sorted as it was only spotted late in the cycle i think
<benh> apw: ping
<apw> benh, yo
<benh> yo mate !
<benh> any chance you guys stick that in:
<benh> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cede3930f0ca6fef353fa01306c72a01420bd45e
<benh> and respin the powerpc ISOs ? :-)
<benh> I forgot to send it to greg for -stable
<benh> I'll do that asap
<TheMuso> benh: I don't think respinning the powerpc isos is possible, I'll have to rebuild them by hand I'd suspect, once the updated kernel is made available, if it is done at all
<benh> ouch
<TheMuso> /c/c
<benh> oh well, if you can put the rebuilt ones somewhere on ppa, that will do
<benh> we can then point the poor users of those nasty iMac G5 "iSight" to that
<benh> without that patch, offb is busted on those (and some G5s with the X1900 "mac" radeon)
<apw> benh, can they boot the CD without the patch and get it as an update?  i assume so if a PPA is helpful
<benh> nope
<apw> ouchies there
<benh> problem is, the gfx card gets moved by the PCI code due to bogus conflicts
<benh> so they get no display
<benh> ie
<apw> so how would they recover from that using the PPA you suggest
<TheMuso> apw: I'd have to role disks by hand to get the new kernels.
<benh> radeonfb would have worked ... except it doesn't work with those specific machines due to some fuckage I never sorted out (need physical HW access and I haven't got that yet)
<benh> so offb fallback is the only solution
<benh> and the bug breaks .. offb
<benh> since the address of the framebuffer changes
<benh> apw: a new ISO
<benh> apw: another option would be to put on PPA a set of files to stick on a USB dongle
<benh> apw: just yaboot, config & new kernel/initrd
<benh> apw: that can then move on to the CD
<apw> yeah that would work i guess
<TheMuso> benh: also note that pPAs don't build ppc packages
<apw> so ... an updated kernel should do the trick.  so lets get a LP bug in the system with the patch on it
<apw> i think you said it was going via stable as we speak
<apw> and i'll get it on our stable teams radar so we can get it in ...
<benh> TheMuso: ok, whatever, your home dir somewhere we can point people to :-) 
<benh> I'll send it to Greg tomorrow, need to check that it applies cleanly on .31 first etc...
<benh> ok cool
<benh> no big hurry
<benh> only one user nagging so far :-) 
<TheMuso> heh right.
<benh> that PM code is also needed for some older x86 boxes in fact
<apw> if you get the launchpad bug and .31 patch together  one of us can build you a kernel you can use for your USB thingy
<benh> ok
<benh> I can cook up a yaboot.conf for the users myself
<benh> allright, I'll try to get that done over the next few days
<apw> benh please subscribe me to the bug
<benh> will do when I open it :-)
<apw> (indeed)
<benh> ie, not tonight :-)
<benh> btw, about that Huawei modem fiasco
<benh> I find it funny that there have been tons of "me too" with E220/E620 for which the patch don't fix it yet
<benh> and none of them so far has sent usbmon logs
<benh> which I've asked ... about 3 times
<benh> oh well, no logs, no fix
<apw> users are like that, they have changed the title to 'some huawei dongles' now ...
<benh> but I wonder if you guys should just revert the initial patch that caused the whole damage in the first place
<smb> benh, That is the magic one is supposed to have
<benh> from a distro quality POV it makes a lot of sense
<apw> when the fix releases we'll ask for a retest, and a 'file a new bug if you don't have E169 and its not working' style on it
<benh> ie, bring it back to 2.6.31.1 status
<smb> benh, btw, subscribe me to that bug too please
<benh> smb: email, or I'll forget :-)
<smb> benh, An as good memory as mine :) ok
<benh> apw: it's all caused by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d0defb855c8504c49b92bdc0203689ce9b4cf7ba
<apw> benh, possibly yes but then we are out of step with stable which may trigger ongoing maintenance, and we'll only get the issue back in lucid where we would much less prefer to have it
<benh> apw: as far as I can tell... the fun thing is .. the patch was submitted by Huawei themselves :-)
<apw> that being an LTX as upstream also has it
<apw> LTS
<benh> apw: right well, we'll still try to fix it :-)
<apw> yeah they are looking a little foolish for sure
<benh> apw: but in the meantime, fixing the problem for all users would seem like a priority 
<benh> apw: ie, it's a fucking lot of 3G modems out there that don't work
<apw> we always have that backout as an option if this is not sufficient (which we know its likely not)
<benh> apw: but it's your call guys :-) I don't do Canonical policy :-)
<benh> right
<apw> but till we fix E169 we can't see whats left
<benh> I'd really like to not let it drop until we fix 220 and 620 either, I kept the kernel.org bug open for that too
<apw> and as you can tell everyone just says 'mee too'
<benh> but there's little I can do without users sending logs
<benh> true
<apw> being not fixed on the update should help us there
<benh> yup
<benh> definitely
<apw> so we think that 220 and 620 are not going to be fixed with this update
<benh> that's what it -seems- from the reports
<benh> but it's hard to tell with lusers
<apw> i may go do some stiring on the bug then, and push that bug to E169 only
<benh> backing out the original patch will have the side effect of disabling the storage part of the modem
<benh> which is not a big deal
<apw> yeah ...
<benh> nobody cares about the windows SW on it
<benh> which leaves the micro-SD thingy but that's not a huge issue, and it didn't work before either anyway
<apw> we should likely point them all at the pre-proposed kernel build 
<apw> yeah there is no regression in that, if we have to back it out
<benh> it doesn't help that some bot keep fucking up the bug status :-)
<smb> yeah, could that have been that one of in size problem with "no sense"?
<benh> smb: well, the size problem with sense is fixed by the patch that went into .5
<smb> benh, exactly
<benh> smb: but -apparently- (hard to tell for sure) there's more problems with 220 and 620
<smb> just being at that to put into pre-proposed kernels
<benh> smb: all related to what looks like FW bugs in the modem, in their implementation of the USB storage protocol
<apw> i applied that same fix in the batch we did before the .5 drop arrived, so it should be in your curent built
<apw> joy :)
<benh> yeah :-)
<benh> foot-crafted firmware
<apw> heheh ...
<benh> for the sense stuff, at least we made the fix in the form of making the driver robust enough to cope with that crap in all cases rather than a quirk
<benh> but it looks like we still get defeated somewhere
<apw> ok so it sounds like we'll get the .5 update into pre-proposed and we'll ask those users to test there
<benh> sounds good
<apw> lets find out if it fixes them all at once
<benh> you may want to stick a build with the original patch backed out somewhere too
<benh> so users can test both and report
<benh> what would give us more solid data
<apw> yeah sure
<benh> eventually, we can then write up the procedure to do the usbmon log
<benh> it's actually very easy
<benh> but I'm sure most users just didn't know what I was talking about
<benh> brb
<apw> benh, sounds good, if you can show us we can get someone to do a wiki page on it
<smb> benh, you mean something like https://wiki.ubuntu.com/KernelTeam/Debugging/USB?
<Appiah> hey apw 
<Appiah> that kernel that you compiled (?!) worked great for the "no network on some laptops"
<apw> Appiah, which bug # please/
<Appiah> https://bugs.launchpad.net/bugs/418933
<ubot3> Malone bug 418933 in linux "no internet connection (wifi+ethernet doesn't work)" [Low,Confirmed] 
<benh> apw: there's already something on the wiki
<benh> smb: right
<apw> nice, love it when a plan comes together
<benh> smb: but that might be a bit thick for a luser
<smb> benh, It can be improved I agree
<apw> benh, ok the plan is to get the .5 stable and .5 stable with that original patch reverted built and pushed to that bug for comparitive testing
<benh> smb: easy enough to write up the 3 commands to type in the bug, will do that after we have sorted out whether they really still have a problem
<benh> sounds like a plan :-)
<Appiah> apw: if any more info is needed I'd be happy to help
<apw> Appiah, that old kernel is so out of step with current mainline and karmic kernel its not likely a useful data point now.  do you have a dell?
<Appiah> apw: nope a Acer
<apw> what does rfkill status say
<Appiah> on the kernel that dont work or yours?
<apw> on the non-working one
<TheMuso> apw: Out of curiocity, do you guys have a tentative target kernel version for lucid?
<apw> TheMuso, its in the air still based on timing and where other stables go, definatly at least .32, maybe .33 if its early enough
<TheMuso> apw: Right, I thought as much.
<apw> i think we may be conflicted, .32 for stabilty and .33 for sexy goodness
<TheMuso> Right.
<indus> hi
<indus> hi friends apw smb here?
<apw> indus, high
<indus> apw hello
<indus> apw: i need a small favour ( or big one)
<indus> apw remember i said about that game called quake4 which crashes on running the quake4-smp executable.? Could you give me some possible places or hints where i could look at? I generated an strace but its 130 MB size, and in the end it just says segmentation fault
<apw> well the clues if any are just before the crash i'd think
<apw> what did it do just before going bang
<apw> of course if you can't change the program, you can't fix its likely
<apw> i thought you could get the same smb mode by starting the non-smp version and enabling it from the menu anyhow?
<indus> apw the crash happens when i connect to any server online. It reads a config file , initialises display again(where it comes back to desktop), then starts game again, says loading menus then boom
<indus> apw well, the quake4-smp is meant to use multicore capabilities, so right now i disable smp in console, then after map loads,  i enable it again 
<indus> works fine in single player is the reason iam curious
<indus> could it have something to do with ext4 at all?
<apw> sounds unlikely it would be ext4 to me
<apw> what was the previous few system calls before the explosion
<indus> hmm dont recollect now, but some munmap 4096
<indus> ok i rephrase this question, what are the things which are extra into an exe which takes into account multicore processors.? anything at all to do with libs etc? or just low level 
<apw> given it worked on an older kernel, and it works in non-smp mode for the map load, and you then can reenable it, i'd say that its most likely quake4 has always had an SMP issue in the map loading code and has always been lucky before now, some change in the scheduler has changed timings of the threads and exposed the bug
<apw> and if thats true, unless you can look at and modify the code you are likely to not be able to fix it
<apw> (the code in quake4 i mean here)
<indus> apw yeah always had an issue with it , it was fixed in a patch later on, various fixes
<indus> apw i guess we wait for q4 to be open sourced then, which will happen eventually
<apw> heres hoping
<indus> so how are things today with you
<indus> your friend smb not here it seems
<indus> apw did you find out what an HSM violation is
<apw> heh smb is like that, off making kernels i expect
<apw> yep, it is a Host State Machine violation ... ie the host has no idea where to go next based on what the drive said ... the drive said something mad
<smb> sort of here and not. and not much help for quake issues too
<indus> could you tell me other tools like strace for debugging? strace didnt tell much before segfault
<apw> you could try gdb
<apw> if quake has debug symbols in it it may help
<smb> yeah, not sure how much more info you get out of that given your app is closed source
<indus> ok 
<indus> just curious thats all, its the only game i play
<indus> you folks can try it, it looks great
<indus> btw, can i volunteer to help you? 
<apw> to help with kernel stuff?
<indus> maybe testing, iam not a computer engineer though
<indus> but iam always interested
<apw> we are always interested in people helping us generally
<apw> some people help with testing, which can be as little as using the -proposed repositories
<apw> others help with our bug days, or with bug triage
<indus> so all require a knowledge of C then
<apw> that requires less specific knowledge of computers, and more of our process and the things we need to knw
 * indus grumbles i never quite learnt it in college
<indus> iam a mech engineer actually
<indus> but did a little python
<apw> ogasawara is a good person to talk to about helping out on bug days and with triage if that interests you
<indus> apw ok ill do that then, is he around here too?
<apw> she is normally around around in my afternoons
<apw> she is west coast US timezone 
<indus> hmm ok late 
<smb> well helping with testing and looking at bugs often requires more of a reprodible and repeatable approach at things
<apw> i think you are east of me, so she may be awake still in your morning?
<indus> iam in india
<indus> ya probably
<indus> but its better later nights when its morning for her
<indus> i have a job regular daytime
<apw> yeah
<indus> so are you folks working on something special for the ubuntu kernel 
<indus> boot etc maybe
<apw> i personally am working on the lucid kernel in general
<indus> ok carry on, ill speak some other day, you probablywork full time for canonical?
<apw> indus, ogasawara would point you to: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies in the kernel team wiki, in our knowlege base
<apw> https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
<apw> you might find those informative in how we do things and the like
<apw> yeah i am lucky enough to get paid to work on the kernel
<indus> sadly, i have a problem with alsa also in quake 4 :)
<indus> lots of changes seem to have been done in newer releases
<apw> heh ... yeah the kernel moves on a furious pace
<indus> personally i found alsa output much richer than oss in this game, and they added support 3 years ago with a patch
<apw> people like to improve the kernel... about 2000 commits wo
<apw> make that 11000 commits in the last kernel update
<apw> and we have about 2 kernel releases per ubuntu release ...
<smb> indus, there is also a #ubuntu-bugs channel which should have people in them to help n generic bug triaging procedures
<apw> i think there is an #ubuntu-bug channel where you can get .... waht smb said
<indus> iam already triaging bugs
<indus> little slow due to work and other commitments though
<apw> ahh ... then if you have those skills then we always need help traiging kernel bugs :)
<indus> huhuhu
<apw> and hanging out here and helping people who ask questions, helping them to find things like docs and stuff helps us a lot
<apw> anything anyone can do to help lightens the load on us
<indus> yeah know i know ubuntu-bug -p linux is the way to get data
<apw> cool
<indus> here? this is a dev room isnt it, 
<apw> thats how most people start, pointing people to the docs
<indus> you mean in general #ubuntu?
<apw> yeah it is, but that doesn't stop people asking questions :)
<indus> like me for example :D
<apw> heh yeah like you
<smb> yeah :-D 
<indus> but is it a bother if users generally drop in here?
<smb> but here mostly things related to the kernel in special
<apw> generally they end up here whent hey are desperate and #ubuntu/+1 has not been able to help and its kernel
<indus> in my case, i had no dvd for a year so someonein ubuntu-bugs directed me here
<smb> no, if they can accept that we might not be helpful when it comes to user-space applications
<apw> people who are trigaing bugs for us might well want to hang out and ask us questions to aid them triage better etc
<apw> heh see so the process works, if slowly
<smb> As for the dvd thing, it actually helped as we had a quicker feedback and could give you hints on the master slave thing
<indus> so , will that bug be addressed in future? not everyone reads launchpad :) most are new general users 
<indus> i guess peopel like me help them fix it then :)
<apw> the master slave one?  its a tricky one, the general information we are getting is that mostly its not expected to work if you have just a slave on a cable
<apw> in that context its hard to know why it did work before
<smb> what apw said. maybe it was just coincidental but not according to the spec
<indus> why should the kernel not look if there is a slave drive there?
<apw> of course its not cirtain that everyone with a broken cd is the same issue as the issue is so broadly stated in the bug
<apw> its not so much about looking, it is looking, and finding and breaking
<indus> hmm
<apw> the drive is doing something it should not and being rejected
<apw> which it does not do if its a master drive
<apw> which is somewhat supprising and incomprehensible
<indus> or maybe the kernel doesnt like what the drive is telling her
<indus> its a sony combo drive, maybe firmware issues?
<smb> based on the assumption that there cannot be a slave without a master
<apw> well what the drive says makes no sense under the spec.  iirc correctly its saying ERROR with data and then provides no data
<indus> well, the cd drive came with default jumper at slave
<apw> so we ask it to identify and it says ERROR read this then refuses to tell us why and we say .... it doesn't seem to be a drive, hrm and ignore it
<indus> but now, my boot up is much smoother it seems without kernel probing madly all devices
<smb> which probably was at some time mostly used on the same channel as a hd
<apw> yeah common default, as in the old days we put them on the same channel as our disk which was master
<apw> now we would not do that as the DMA modes for drives go much hihger, and are capped at the slowest drive on the cable
<apw> and extra ports are cheap.  so all drives are on their own and should be primary
<apw> but the manufacturers put the cd ones in the same place still 
<apw> as to whether it should work, that is still an open question
<smb> at some point things changed and cds where placed as master on the second bus. I actually think they canged to make it master by default
<smb> but that might be not always the case
<indus> one question, there is a cable selector option other than msater and slave, how does tht work?
<smb> when you set the drive to cable select it will depend on which of the connectors you put it
<smb> usually the cables have on line broken up between the second and third connector
<indus> ok nvm now, its a different discussion anyway
<indus> but iam really glad, you people helped me solve this long standing problem 
<indus> ok ill see you around
<indus> bye and have a nice day/days apw and smb and others
<Appiah> apw: sorry for the late response
<Appiah> but rfkill status is not valid..
<apw> what does it say?
<Appiah> status is not a command
<Appiah> just shows the help
<Appiah> you mean rfkill list ?
<apw> apparently so yes
<Appiah> http://pastebin.ca/1656506
<ricflomag8> Hi, i need advice on tweaking the generic karmix kernel: i want to disable the experimental VIA PATA driver and replace it with the VIA IDE driver (I suspect the VIA PATA driver to be responsible for random hardlocks)
<ricflomag8> i've tried to build the whole kernel using https://help.ubuntu.com/community/Kernel/Compile (old debian way), but i get a huge deb file (900M)
<ricflomag8> is it the place to ask ? :)
<apw> 900M ... which one is that big
<apw> Appiah, is the dmesg for that machine available ?
<smb> apw, I strongly suspect it has to do with the old debian way (which seems to be kpkg-make) and the fact that our config is to make debugable code and strip before putting into packages.
<apw> yeah ... sounds like the debug stuff.  just wondering which file it made was that big
<smb> sort of all of them
<apw> rsync -a --exclude debian --exclude debian.mvl-dove * /home/apw/local/git2/ubuntu-karmic/debian/build/build-dove
<apw> how is that safe ?
<apw> oh missed the --exclude debian ... blind as a bat
<smb> heh, happens
<Appiah> apw: not at the moment sorry
<apw> dtchen, hey ... it seems we have a lot of people running the wrong kernel after an upgrade
<apw> do you have any feel for how many you have seen?
<apw> i hear you get to find out cause it breaks sound
<MsMaco> i think on friday he said 200 or so in 2 days
<MsMaco> i saw his inbox. timestamps for bugmail on that issue were every minute
<apw> MsMaco, thanks for the info
<apw> i assume he must have  closed them out as i cannot find them currently
<Appiah> apw: what more then dmesg output do you want?
<apw> interested to see the bits where the wireless is initialised
<Appiah> cuz I gotta reboot , get the log , save it , reboot , upload it
<sconklin> I discovered a cool tool for intel graphics hardware - blogged about it here: http://www.illruminations.com/post/232984141/development-tools-for-intel-graphics-drivers-on-linux
<apw> Appiah, its not that big, so i'd get the lot
<Appiah> oki you will get it in a min
<tormod> sconklin, that's intel-gpu-tools, is moved to a separate package now
<tormod> *will be
<tormod> sconklin, sorry, the reg dumper will be moved to the separate package intel-gpu-tools
<Appiah> apw: http://pastebin.com/d239546a7
<Appiah> 1413 wlan stuff begins
<apw> thanks can you get that in the bug pls
<Appiah> alright
<Appiah> apw: posted
<hagabaka> I installed the image and header packages from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc6/ , grub update says it found the new kernel, and I see symlinks to them in /boot/, but menu.list doesn't list them. how can I fix that?
<smb> hagabaka, Have you tried "sudo update-grub"?
<hagabaka> yeah
<smb> I see. Is the file actually touched after you run that. (ls -la)
<hagabaka> yeah, it is touched
<hagabaka> does grub use the symlinks in /boot/ if I don't enter the menu?
<smb> no, only the first entry in menu or whatever was saved...
<hagabaka> oh
<smb> it is strange that it seems to tell you it finds it but does not add it
<hagabaka> I wonder if it's using a regexp and not considering versions containing "rc"
<smb> This would have been seen more often by now. There are quite some using those afaik
<hagabaka> oh
<hagabaka> ah, it was because I was using gdebi-kde to install it before, the installation asked me to choose whether to use maintainer's menu.list, since it had modifications. the KDE version doesn't deal with those dialogs...
<smb> ah. ok. think there are variations of that problem around
<apw> yeah that -kde tool seems to betriggering all manner of issues
<hagabaka> does the gtk one deal with them?
<hagabaka> I'll try the new kernel, see you
* apw changed the topic of #ubuntu-kernel to: "Home: https://wiki.ubuntu.com/KernelTeam/ || Karmic Kernel Version: 2.6.31 || Ubuntu Kernel Team Meeting - Next Meeting after UDS - 17:00 UTC"
<hagabaka> I'm using x-edgers, 2.6.32 kernel to enable KMS for ATI Radeon 9800 Pro using the open source driver. there are flashing lines on the screen in both console and X. I can stop the flashing lines by changing to a different resolution or refresh rate, but after rebooting they're back again. is there a way to "save" the refresh rate setting? it doesn't seem to be just an X configuration problem.
<hagabaka> the flashing lines have the screen image shifted horizontally, and the shift grows larger near the right edge of the screen
<hagabaka> I do have the hsync and vrefresh values for the monitor in xorg.conf
<ukev> hi, what does the following want to tell me?
<ukev> [86251.635098] python2.6[18415]: segfault at 7f06b9c70d49 ip 00007f06b1994610 sp 00007fff63ffb9c8 error 4 in libpython2.6.so.1.0[7f06b1900000+156000]
<apw> hagabaka, you should ask that question over on #ubuntu-x, as they do the x-edgers stuff
<tormod> sconklin, you want to upload stuff in xorg-edgers?
<sconklin> tormod: no, but I'm working on getting a crack-of-the-day build going for the upstream Intel drivers
<tormod> sconklin, kernel driver?
<sconklin> tormod: yes, sorry. Porbably it will be a build of their kernel working tree
<tormod> sconklin, aha, nothing we want into xorg-edgers, but maybe a separate PPA?
<tormod> we can use intel-gfx-testing ppa for it maybe
<sconklin> tormod: Yes, I already have a PPA set up, first test build with some patches should land any minute
<sconklin> tormod: I'll publicize it once I've tested and got my work flow down
<tormod> sconklin, cool I'll add you to the teams, but ask before dumping something in there :)
<sconklin> tormod: no problem :)
<sconklin> tormod: is xorg-edgers a good place to call for testing of intel kernel driver patches?
<tormod> sconklin, well xorg-edgers is just a ppa, and as I said we probably don't want a crack kernel in there
<tormod> but you can advertise on the PPA page
<sconklin> tormod: yeah, ok. That's good.
<tormod> the phoronix forum is the best place to find crack testers with good technical skills
<tormod> plenty of people will love to test fresh kernels, we often get requests
<sconklin> tormod: ok, thanks for that.
<sconklin> gotta run now, I'm burning dinner :)
<tormod> if you could team up with apw and make daily builds  including drm-next ...
<Kano> hi, is it known that p54 does not work with 64 bit  only 32 bit?
<tormod> sconklin-afk, (when you're back) if you can build dailies with aufs so we can make live cd iso's with them that would rock
<tormod> Kano, you reminded me about asking for that :)
<Kano> thats really crap that kernel, i had to use my 32 bit install to get online
<sconklin-afk> tormod: Let me check with apw on that, he already has the build process set up for Linus's upstream and is going to be looking at how to do the intel driver upstream also.
<sconklin-afk> tormod: oh and thanks for the package note on intel_reg_dumper, I updated the blog post
<tormod> sconklin-afk, well I was a bit coming in from the future on that remark :)
<sconklin-afk> that's ok, since blog posts live forever
<dtchen> apw: yes, all related to some strange failure-to-update-grub's-conffile
<tormod> ogasawara, what is that httpd trick on the initramfs wiki page?
<ogasawara> tormod: hrm, not quite sure I know what you're talking about here.  Can you point me to the wiki you're looking at?
<apw> dtchen, yeah it does look that way doesn't it ... we'll get some automation on gettting those responded to tommorrow
<tormod> ogasawara, sorry can't find it now, it was about debugging boot and stuff, there was a section about httpd in the initrd and I traced that to you
<tormod> never heard about it before
<tormod> https://wiki.ubuntu.com/DebuggingKernelBoot
<dtchen> apw: I think bug 463853 is the tracking one
<ubot3> Malone bug 463853 in grub "no sound at all in 9.10" [High,Incomplete] https://launchpad.net/bugs/463853
<tormod> dtchen, so grub gets blamed?
<tormod> oh kernel upgrade
<dtchen> tormod: it clearly isn't an alsa-kernel issue
<dtchen> tormod: I've triaged about 700 of these by myself
<dtchen> along with the awesome spew that people leave in comments saying "ubuntu sucks", etc., etc.
<tormod> have you seen a menu.lst yet?
<dtchen> I've seen quite a few
<tormod> and they only have the old kernel?
<dtchen> yes
<dtchen> I'm not going to devote cycles to debugging it, because 1) I'm tired, 2) others more experienced are looking at it, 3) there are a crackton other bugs to look at
<tormod> can you link to one report which has menu.lst or more?
<tormod> ok I found bug 470265
<ubot3> Malone bug 470265 in grub "[MASTER] jaunty to karmic upgrade failed to update menu.lst (update-grub missing from kernel-img.conf)" [High,New] https://launchpad.net/bugs/470265
<dtchen> tormod: sure, there's also 465937
<dtchen> just take a look at the bugs affecting alsa-driver if you're interested
<dtchen> bjf: hi, thanks for helping with these grub bugs
<bjf> dtchen, happy to help
<TheMuso> Yeah, any help with audio bug triage is welcome. We have received so many bugs since Karmic came out its not funny.
<dtchen> actually, it's pretty awesome. linux-side at least they break down into three big classes: 1) grub fubar (resolved by fixing the grub conffile), 2) mic sensing for IDT, VIA, & Realtek (resolved by installing linux-backports-modules-alsa-karmic-generic and rebooting), 3) powerdown anomalies for non-IDT/Sigmatel (resolved by disabling power_save)
<dtchen> pulseaudio-side is a little -- okay, a lot -- more bleak
<joaopinto> will anyone be working on the libsdl 1.2.14 upgrade which according to the release notes fixes improves support for PA ?
<dtchen> joaopinto: yes, I am. I've got it in another terminal here.
<dtchen> it also improves support for ALSA
<joaopinto> I have started settings dupos into bug 454879
<ubot3> Malone bug 454879 in libsdl1.2 "Applications using libsdl1.2-alsa randomly use 100% cpu and have broken sound playback" [Undecided,New] https://launchpad.net/bugs/454879
<dtchen> yes, I've seen. Thank you!
<joaopinto> grr, hedgwars played fine now, I didn't figured yet the random factor
#ubuntu-kernel 2009-11-05
 * bjf off to a meeting
<dtchen> ogasawara: hi, did you have a laptop that experienced bug 279478?
<ubot3> Malone bug 279478 in linux "alsa sound fades out when headphones are plugged in until you inaudible" [Low,Triaged] https://launchpad.net/bugs/279478
<ogasawara> dtchen: not that I know of, but let me test really quick
<dtchen> ogasawara: seems to hit Dell Dimension E52x
<dtchen> anything with SSID 0x102801?d
<ogasawara> dtchen: I've got a 1420 here, 1028:01f3
<dtchen> excellent, same codec
<dtchen> it defaults to the model=dell-bios quirk, however
<dtchen> so I don't think you'll have the same symptoms
<ogasawara> dtchen: sound remains after I insert headphones
<dtchen> ogasawara: do you have a separate Headphone profile when you right-click the speaker icon in the lower GNOME panel and choose Sound Preferences > Hardware ?
<dtchen> regardless, you have a completely different quirk, so this bug wouldn't be relevant 
<ogasawara> dtchen: I don't see it
<dtchen> mmkay
<dtchen> how about: echo autospawn = no|tee -a ~/.pulse/client.conf && killall pulseaudio && sudo alsa force-unload && sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf
<dtchen> jack sense is such a mess right now :(
 * MsMaco gives dtchen cookies
<ogasawara> ogasawara@emiko:~$ echo autospawn = no|tee -a ~/.pulse/client.conf && killall pulseaudio && sudo alsa force-unload && sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf
<ogasawara> autospawn = no
<ogasawara> [sudo] password for ogasawara: 
<ogasawara> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ogasawara/.gvfs
<ogasawara>       Output information may be incomplete.
<ogasawara> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ogasawara/.gvfs
<ogasawara>       Output information may be incomplete.
<ogasawara> Unloading ALSA sound driver modules: snd-hda-codec-idt snd-hda-intel snd-hda-codec snd-hwdep snd-pcm-oss snd-mixer-oss snd-pcm snd-seq-dummy snd-seq-oss snd-seq-midi snd-rawmidi snd-seq-midi-event snd-seq snd-timer snd-seq-device snd-page-alloc (failed: modules still loaded: snd-hda-codec-idt snd-hda-codec snd-hwdep snd-pcm snd-timer snd-page-alloc).
<dtchen> barf 
<dtchen> sudo fuser -v /dev/dsp* /dev/snd/* /dev/seq*
<ogasawara> ogasawara@emiko:~$ sudo fuser -v /dev/dsp* /dev/snd/* /dev/seq*
<ogasawara> Cannot stat /dev/dsp*: No such file or directory
<ogasawara> Cannot stat /dev/dsp*: No such file or directory
<ogasawara> Cannot stat /dev/seq*: No such file or directory
<ogasawara> Cannot stat /dev/seq*: No such file or directory
<dtchen> ok, and sudo alsa force-unload
<ogasawara> ogasawara@emiko:~$ sudo alsa force-unload
<ogasawara> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ogasawara/.gvfs
<ogasawara>       Output information may be incomplete.
<ogasawara> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ogasawara/.gvfs
<ogasawara>       Output information may be incomplete.
<ogasawara> Unloading ALSA sound driver modules: snd-hda-codec-idt snd-hda-codec snd-hwdep snd-pcm snd-timer snd-page-alloc.
<dtchen> excellent
<dtchen> sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf
<ogasawara> ogasawara@emiko:~$ sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf
<ogasawara> ogasawara@emiko:~$ 
<dtchen> so let's try: speaker-test -c2 -l4 -Dplug:front:0
<dtchen> try inserting headphones
<dtchen> do the internal speakers mute properly?
<ogasawara> yup
<dtchen> and unplugging unmutes the int speakers, correct?
<ogasawara> yup
<dtchen> sigh
<dtchen> would you please add your /proc/asound/card0/codec* to the bug?
<ogasawara> will do
<dtchen> thanks!
<ogasawara> dtchen: posted my info, let me know if you need any other testing from my end.
<dtchen> I just need a big hammer
<dtchen> thanks, regardless
<stavrob> hey guys, why is ubuntu configured with 100hz timers for the standard desktop kernel?
<ikepanhc> stavrob: you are using amd64 arch?
<stavrob> ikepanhc: yes
<ikepanhc> stavrob: 250hz timer in i386 and 100hz timer in amd64
<stavrob> im wondering why
<ikepanhc> let me check out
<stavrob> 100hz timers really do introduce actual noticeable latency problems, its visible as little stutters and jerks, occasionally music skipping etc
<stavrob> dunno about 250hz but i compiled the ubuntu kernel again with 1000hz and it's streets better
<ikepanhc> Some discuss about set CONFIG_HZ to 1000 for a more "real-time" environment, I will check if there is discuss about why set to 100MHz for amd64 :-) 
<stavrob> personally i think 1000hz timers for desktop kernels for both arch's would be lovely, but if we can at least get the timer resolution up on amd64 it'd be a nice start
<stavrob> it really is a noticeable difference, compile your kernel with 100hz and then with 1000hz and just use each one for a bit. i know desktop interactivity is quite a woolly thing but trust me it's very noticeable
<ikepanhc> stavrob: ya, I think so, but maybe there is some story behind this (digging for story)
<stavrob> ikepanhc: ok cool
<phenompanda> hi, ericm 
<phenompanda> i see sa1100 defconfig have CONFIG_ARCH_DISCONTIGMEM_ENABLE =y
<phenompanda> ericm, is there any special purpose for add this feature in ARM arch?
<ericm> phenompanda, no - we are moving to sparsemem
<stavrob> ikepanhc: did you find anything in the end
<ikepanhc> stavrob: not yet, is there anyone know why CONFIG_HZ=100 in arch amd64?
<apw> ikepanhc, cause the higher HZ is the more expensive tick handing is
<apw> and where you have any sort of high res timer a high HZ is just useless noise
<apw> so on amd64 where highres timeres are always present there is no point in maintaining a high HZ
<ikepanhc> apw: you mean cost cpu time on content switch?
<apw> it contributes many %'s of SPU usage
<apw> i mean the cost of taking the interrupts to handle it and update the jiffies
<apw> which we don't use in the main even
<Appiah> 100 isnt that typical server usage?
<apw> therefore the recomendation was 250 for i386 where highres timers are not present
<apw> and 100 for amd64 where you have highres timers which form the bases for everything
<apw> Appiah, my understanding is that when you have high res timers the HZ value is no longer relevant for scheduling
<apw> and most times and timing uses the tick + high-res offset for accuracy
<apw> so it matters little how often tick changes within the resolution of the high-res timer
<apw> ie ... updating it less often has no downside, and much upside in overall cost
<Appiah> oki
<Appiah> I just remeber from putting my kernel togheter myself on gentoo where you could choose between 100 , 512 or 1000 where it said 1000 recommended higher for desktop/workstations and lower for servers
<apw> which kernel version tho?
<Appiah> last time I used gentoo was about little less then a year ago
<apw> moving HZ to 1000 from 250 was tested recently as the pulse peopel were shouting for it.  a full 8% cost in CPU alone
<stavrob> apw: according to con, high res timers are mostly broken in the kernel atm so are disabled, they're apparently still limited by tick resolution for scheduling timeout decisions
<apw> i seem to have timers enabled in my kernel ... the recomendation for the HZ change came down from mainline developers
<stavrob> my bad, it seems highres timers are actually enabled, just not for scheduling decisions
<stavrob> which unfortunately has a noticeable impact on responsiveness
<ghostcube> simple question why is there an grub2 now
<ghostcube> i hate it 
<ghostcube> i just hate it
<ghostcube> :|
<_ruben> then dont use it?
<ghostcube> on new karmic install its defaulted so i wanted to test
<ghostcube> but it pure bah
<_ruben> and supposedly grub2 has more to offer than grub(1) .. then again, i havent played with it myself, yet
<ghostcube> _ruben: try it 
<ghostcube> to configure it it drives you nuts :D
<_ruben> i only have 1 karmic box, and it was upgraded step by step from uhm .. hardy i think
<apw> ghostcube, whats is so bad about it
<apw> it seems almost identicle user interface wise
<smb> The config file format is different but not necessarily worse. You now mostly do changes in /etc/default/grub and do update-grub. The only thing that is a bit annoying is the persistence it tries to go for the master boot record by default
<smb> jjohansen, Is that virtio thingy from bug 458521 going to require a kernel patch too or is that more or less done with the kvm package update. (I believe they included dkms modules, but I am not sure)
<ubot3> Malone bug 458521 in qemu "kvm crash when using virtio for network, hardy guest" [Medium,In progress] https://launchpad.net/bugs/458521
<smb> Keybuk, around?
<ghostcube> apw: the config is pure horror
<ghostcube> old grub had one file and all worked
<ghostcube> new grub2 is script and file based daemon thingy
<ghostcube> i dont like this 
<apw> ghostcube, it has a slightly different syntax.  and yes it uses cat to make a file out of it
<apw> its split config, but its not that different
<smb> ghostcube, err do you generally need more than grub.cfg?
<ghostcube> smb: iam not only talking about me :)
<ghostcube> i have oure linux install
<ghostcube> p
<Keybuk> smb: briefly ;)
<Keybuk> what's up?
<ghostcube> no need for any features of grub2 
<ghostcube> but i think its not the best solution to make linux boot stage easier or ?
<smb> Keybuk, Just wanted to make sure we do the right thing on the next Karmic upload. I got the modified trace patch in that took out the uselib part, but the ureadahead from the ubuntu-boot ppa does not like this much
<Keybuk> yeah, I have another one to upload
<Keybuk> there you go, uploaded ;)
<smb> Keybuk, ah, so you won't yell (at me) when I upload that kernel without uselib. :) Good
<Keybuk> no
<Keybuk> it'd only break tracing anyway
<Keybuk> go right ahead
 * smb goes off to test the new ureadahead and then upload the kernel
<smb> hrm... actually... with the speed of the ppa builders atm, I should probably just upload... :-P
<apw> smb what else can you do
<jjohansen> smb: it looks like it probably requires a kernel patch but I hadn't gotten to it yet
<smb> jjohansen, Ok, ta. Just wanted to make sure I not forget about it
<jjohansen> smb: right
<bjf> dtchen, are we marking all the grub audio bugs as duplicates of 470265?
<HorsePunchKid> I have a somewhat obscure problem with a non-ubuntu kernel. The problem does not occur when I use the ubuntu kernel from the minimal installation CD. Is this a place where I might find some help discovering what has fixed the problem in the ubuntu sources?
<dtchen> bjf: yes, please
#ubuntu-kernel 2009-11-06
<benh> hoy
<benh> are you guys playing nasty trick with the kernel config or so ?
<benh> install linux-source-...
<benh> unpack it
<benh> stick /boot/config-* in there as .config
<benh> apply a patch
<benh> make drivers/usb/storage/usb-storage.ko
<benh> and the resulting file ... doesn't work
<benh> FATAL: Error inserting usb_storage (/lib/modules/2.6.31-14-generic/kernel/drivers/usb/storage/usb-storage.ko): Invalid module format
<benh> apw ?
<TheMuso> benh: Likely asleep atm, but since the way kernel packages are built has been changed recently, there still may be bugs that need sorting out.
<benh> niiiiice
<benh> remind why you guys did an LTS release in such a shamble ? :-)
<TheMuso> Well not so much built, but since several trees are used to track various arm flavours, the debian dir has been abstracted a bit, so bits from the linux-source package may be incorrect/missing.
 * Ng wonders if anyone has seen odd kernel crashes sneak into karmic very recently, my laptop was re-installed at RC and has been running since then. shut it down last night, this evening i've had it drop me to a console and start flashing capslock three times
<Ng> I may have rebooted once in the time from RC to last night, but no more than that, so I suppose the answer is to roll back all of -updates
<Ng> s/answer/test case/
<pgraner> benh: Karmic is not an LTS
<benh> pgraner: oh I though it was ... my bad
<benh> when is the next LTS ?
<pgraner> benh: Lucid
<benh> ok, I stand corrected
<benh> apw: so for this modem stuff ... I have the nagging feeling that most users on the bug that say it's not fixed for them are -not- actually running a kernel with the patch in
<jk-> hey benh
<benh> hey jk :-)
<jk-> benh: do you know if the blue & white G4s have a RS232 header?
<benh> jk-: it might
<benh> tho B&W is G3 :-)
<jk-> has a RJ11 modem connector on the back
<benh> www.geethree.com
<benh> they still exist ?
<jk-> oh, blue & clear then :)
<benh> nah, it's not a real one
<benh> but the modem slot carries the serial signals
<benh> (TTL) and those guys used to make an adapter
<jk-> right, ok
 * jk- cracks it open
<benh> http://www.geethree.com/stealth/index.html
<benh> ah
<benh> sold out !
<benh> crap
<benh> maybe you can get them to send you the schematics :-)
<benh> or the connector pinout
<benh> or maybe on ebay
<jk-> hm, i don't like my chances of finding a new connector for this modem socket
 * jk- heads to ebay
<jk-> computer says no
<benh> well
<benh> I think xmon still had an option to send modem commands to connect it :-)
<benh> so you can cross wire the modem to another modem
<benh> though that works only if the modem uses serial, not USB or i2s
<benh> apple has all 3 options depending on the machine
<benh> (the connector has all 3 afaik)
<jk-> maybe i could also install a punchcard reader :P
<benh> :-)
<benh> you may be able to blink the front LED in morse :-)
<TheMuso> heh what bus did the moems use in those old machines? Afaik they used i2s in the G5s and aluminium powerbook G4s for the modems.
 * jk- notices a label on an IC on the modem "I2C-01/0001"
 * jk- uses FB console instead
<benh> TheMuso: could be USB
<benh> TheMuso: apple had serial first, then usb, then i2s
<TheMuso> benh: Ah ok.
<TheMuso> Pitty drivers weren't written for the USB/I2S modems.
<benh> drivers existed for the USB one
<benh> but they were not open source
<benh> hfcusb or something like that by that canadian dude
<TheMuso> meh I guess there is not much point these days.
<jk-> i was just planning to get a ppc machine for easy boot tests
<benh> apw: so at least that "Joel" guy was running the wrong kernel
<benh> apw: also, Alan Stern had a look at his log anyways and the problem appears to be exactly the same as the E169
<benh> apw: so it's -possible- that they are all fixed, but people have been utterly confused by the bug status changing to "Fix Released" all the time
<benh> apw: we'll know better once you guys finally release something based on .5 
<benh> apw: moin
<apw> moin
<benh> apw: looks like we might finally get some light on that modem mess :-)
<apw> yeah?
<benh> apw: well, your post ... I think the main problem was confusion as to what kernel did what
<benh> apw: your two test kernels should clarify things hopefully
<apw> yeah lets hope so
<apw> benh, i spend about 40 minutes writing and re-writing that update ...
<benh> :-)
<benh> users are a pain !
<Appiah> hey apw had any chance to look at #418933 after i uploaded the dmesg ?
<csurbhi> one quick question, in karmic, how do i stop booting into X.. i mean i want to login into text mode by default ?
<apw> disable the gdm upstart job?
<csurbhi> apw, i am searching just that.. ! how to stop gdm using upstart !! the wiki is outdated
<csurbhi> :(
<apw> perhaps comment out the start on stanza from /etc/init/gdm
<apw> you may also be able to change the /etc/X11/default-display-manager to not include the gdm path too
<apw> and you may also be able to add text to the kernel command line in grub
<mementomori> hi
<mementomori>  I've built my custom kernel using make-kpkg. Now if I modify/patch a module source should I rebuild the whole kernel or is there a way to build only the updated module?
#ubuntu-kernel 2009-11-07
<bmhm> Hi, got a question about luks-support in 9.10
<bmhm> seems to have been altered
<bmhm> I got a laptop with luks-encrypted partitions. While booting with 9.04's kernel, decrypting works
<bmhm> doesn't work when booting with the new kernel
<bmhm> any ideas?
<hyperair> strange, it works for mine nicely
<hyperair> what happens when booting 9.10's kernel?
<hyperair> could it be that cryptsetup somehow disappeared and your initrd doesn't have it?
<bmhm> hmm
<bmhm> probably my initramfs is faulty
<bmhm> but how did this happen?
<bmhm> and how do I restore it?
<hyperair> wait a sec. how is your setup like?
<hyperair> is root on a luks partition?
<bmhm> yes it is
<bmhm> ./boot is not
<hyperair> ah
<hyperair> similar to mine thne
<hyperair> then*
<bmhm> ./ and ./home are
<hyperair> lvm?
<bmhm> no lvm
<hyperair> ah
<hyperair> so they're separate
<hyperair> okay, do you have your jaunty kernels around with the same installation, or is your karmic and jaunty installation separate?
<hyperair> (and you should leave the leading ".". "." stands for "current directory")
<bmhm> I cant leave .
<bmhm> at least in IRC
<bmhm> try starting a chat message with a slash
<bmhm> :-)
<bmhm> yes, it works with my jaunty kernel
<bmhm> I just saw some issues with ldconfi
<bmhm> g
<hyperair> /blah
<hyperair> ;-)
<hyperair> try either // or / /
<hyperair> well boot using your jaunty kernel and run sudo update-initramfs -u -k all
<hyperair> see if that works
<bmhm> I fixed some library-problems, maybe this is already it. Afterwards, I'll try your suggestion (currently rebooting)
<hyperair> good luck
<bmhm> at least I can now use vim again...
<bmhm> while updating, ldconfig said, my libavahi* and libgpg*-files were empty
<hyperair> heh
<hyperair> soudns like your isntallation's kinda knocked up
<bmhm> yeah
<hyperair> i'd install debsums and run a check
<bmhm> debsums? never heard of it, i'll try
<hyperair> it's good for detecting files which differ from what the's installed
<bmhm> you wouldn't guess what happened to my fathers laptop
<hyperair> what?
<hyperair> tossed it out the window and it survived? =p
<bmhm> /boot was full. But I couldn't remove old kernels, because dpkg --configure -a had no disk space on /boot
<bmhm> ...
<bmhm> and there was no "resume"-optin
<bmhm> the upgrade process just broke
<bmhm> how annoying
<hyperair> ah
<hyperair> you could dpkg --configure -a again
<bmhm> do you have a cipher= option specified in /etc/crypttab?
<hyperair> it'll continue from where it left off
<hyperair> no i don't
<bmhm> I see, maybe this might be an issue
<hyperair> cryptostuff /dev/sda2 none luks
<hyperair> that's the only line there
<hyperair> aside from the comment
<bmhm> I see. mayby I'll try to remove that option
<hyperair> it shouldn't cause issues imo
<hyperair> the problem is most probably because dpkg failed
<bmhm> yeah
<hyperair> make sure dpkg completes whatever it's doing
<bmhm> update-initramfs found the crypto devices
<hyperair> give /boot more space or whatever
<bmhm> let's reboot
<bmhm> I thought 200MiB are enough for /boot
<bmhm> but jaunty had a lot of kernel updates
<hyperair> /dev/sda1             510M  126M  359M  26% /boot
<bmhm> I see
<hyperair> 200MiB is kinda cutting it close
<hyperair> you can purge some of your kernels
<bmhm> I did
<hyperair> the older ones
<hyperair> ah
<bmhm> but...
<bmhm> I couldn't do via dpkg or aptitude
<bmhm> since i had to do dpkg --configure -a first
<bmhm> and I couldn't execute that because of low disk space
<bmhm> so I had to remove them via 'rm'
<bmhm> that's what bugging me
<hyperair> lol
<hyperair> i see
<hyperair> rm, dpkg --configure -a, then purge
<bmhm> yeah
<bmhm> exactly
<bmhm> from SLES, I know `rpm -qf </path/to/file>` and rpm tells, to which pakage this file belongs to
<bmhm> very handy
<_maks> dpkg -S file
<bmhm> ah
<bmhm> gotto remember that
<hyperair> or dlocate
<hyperair> dlocate is a very much faster dpkg -S
<bmhm> rpm is extremely slow
<bmhm> both dlocate and dpkg are probably faster
<hyperair> heh
<hyperair> well dpkg -S takes quite some time
<hyperair> but dlocate is almost instantaneous
<hyperair> it seems dlocate can also do md5sums check
<bmhm> I guess dlocate builds some sorta hash map
<hyperair> s
<hyperair> it does
<hyperair> no actually it says it keeps a text dump
<bmhm> o.O
<hyperair> it says it keeps a text dump from dpkg
<bmhm> dlocate -l understands regex, hooray!
<hyperair> and just uses grep
<hyperair> lol
<hyperair> $ wc -l dlocatedb
<hyperair> 408412 dlocatedb
<hyperair> my my, that's a lot of lines. xD
<bmhm> grep is fast then :-P
<bmhm> I had some issues using grep on AIX, but that's another story
<bmhm> hyperair: cryptsetup works, thanks!!
<hyperair> heh
<hyperair> np
<bmhm> in our company we use SLES, AIX, Solaris on servers. on AIX and Solaris there is only ksh88 available. bah!
<bmhm> by the way, hyperair, have you seen that recent picture of Linus Torvalds in front of a win7-store?
<bmhm> http://tr.im/Eqan
<hyperair> bmhm: i did, yes.
<hyperair> it was hilarious
<bmhm> hyperair: can you help me with another LUKS-Issue?
<hyperair> what's up?
<bmhm> as I said... no LVM. I am trying to derive keys from root. Works with swap, but won't work with home (both deriving from root)
<hyperair> what do you mean derive keys from root?
<bmhm> means using /lib/cryptsetup/scripts/decrypt_derived as option
<hyperair> hmm
<hyperair> never done anything of that sort O_o
<hyperair> what does it make your crypttab look like?
<bmhm> erhm wait a mo
<bmhm> hyperair: http://pastebin.ca/1660772
<hyperair> bmhm: how do you create your cryptsetup volumes?
<bmhm> it's been some time since I created them
<hyperair> heh
<bmhm> dunno, does it really matter?
<bmhm> hyperair: it works when I remove the script-part from the /home-line. I just have to type the password twice
<hyperair> hmm
<hyperair> is there documentation on this script?
<bmhm> hyperair: just found the issue
<bmhm> to use a derrived key, it has to be added to the luks header first
<hyperair> ?
<hyperair> luks header?
<hyperair> what do you mean?
<bmhm> the partition header created by luks
<bmhm> it has to be added via cryptsetup luksAddKey
<hyperair> i don't understand
<hyperair> dion't you mean luksFormat?
<hyperair> oh i get it
<hyperair> i understand now.
<hyperair> % /lib/cryptsetup/scripts/decrypt_derived crypt-part > /mnt/crypt-part/key-file
<hyperair> 2.% cryptsetup luksAddKey /dev/sda7 /mnt/crypt-part/key-file
<hyperair> aha.
<bmhm> yeah
<bmhm> i took it from german ubuntuusers-wiki
<hyperair> ah
<hyperair> well i faced that problem at first, so i used lvm instead
<hyperair> i don't regret it, since lvm makes it extremely easy to resize partitions.
<hyperair> or create new ones
<hyperair> resizing cryptsetup volumes are kinda.. @_@
<bmhm> Yeah, true
<bmhm> but when I created my luks partitions about 1.5 years ago, there was no appropriate tutorial
<hyperair> 1.5 years?
<hyperair> that's about the same time i created mine
<hyperair> there were cryptsetup/lvm tutorials lying around
<bmhm> well... 
<hyperair> it's a good thing i used lvm anyway, i learnt loads about lvm (and use it for sg.releases.ubuntu.com now)
<bmhm> true
<bmhm> LVM really is a good thing to have
<hyperair> yep
<bmhm> btrfs will have some interesting features as well, which will interact with LVM
<hyperair> hmm
<hyperair> is it?
<hyperair> interact with LVM? i thought it was going to provide all kinds of LVM which will make LVM rather useless for it
<bmhm> ah perhaps that's what I meant
<bmhm> this is where I get my information from:
<bmhm> http://www.h-online.com/open/features/The-Btrfs-file-system-746597.html
<bmhm> it's a translation of the german site "heise.de", which is the publisher of the best-known german computer magazine (called "c't").
<bmhm> btrfs has also raid built in. I wonder what happens to md,
<hyperair> it'll be around for legacy file systems i suppose
<bmhm> do you know "the h"? great page imho
<hyperair> nope
<hyperair> what's that
<bmhm> the page i just posted an article from
<bmhm> well anyway. got to go
<bmhm> thanks for helping
<dtchen> apw: should I modify build-mkschroot to accept lucid as a valid $SUITE, too?
<dtchen> ugh, this is going to require kludging in a newer debootstrap, too
<dtchen> ...which of course doesn't exist yet.
<Ng> lool: have you had any complete kernel panics on your 301 in karmic, particularly recently?
#ubuntu-kernel 2009-11-08
<starek> hi
<starek> antone worked on schedulers
<krgn> hi. quick question; when I use the git tree and do a checkout of say Ubuntu-2.6.31-15.46 or something... why is it that there are two directories "debian.master" and "debian" and how can I generate it so there is only "debian" left with all the lates config etc...
<dtchen> ogasawara: Takashi would like the contents of /proc/asound/card*/codec* after passing probe_only=1 (append to the options snd-hda-intel line in /etc/modprobe.d/alsa-base.conf *without* any model quirk) using linux-backports-modules-alsa-karmic-generic
<dtchen> ogasawara: sorry, more context: This would be on the Dell with the jacksense problem
<lool> Ng: I had kernel hangs, but no visible panics
<Ng> lool: I've had 4 instances now of X disappearing leaving me with just a blinking cursor, flashing capslock and no response to any input
#ubuntu-kernel 2010-11-08
 * apw yawns
<lag> pgraner: Hi Pete
 * lag mpoirier Hi Mathieu 
<lag> Lol
<lag> mpoirier: Hi Mathieu 
<mpoirier> lag: I'll get back to you in 5 minutes.
<lag> No problem 
<cooloney> hi lag and mpoirier 
<cooloney> how's going, 
<lag> Hey cooloney 
<lag> Good thanks buddy, and you?
<lag> Are you safely home?
<cooloney> lag: i am still in Boston with ericm|ubuntu and minipanda
<cooloney> lag: working from our lexington office
<lag> Ah, is apw there too?
<lag> And rtg?
<cooloney> lag: sure, we are together
<lag> How romantic 
<cooloney> lag: they are in a meeting. i think
<pgraner> lag, howdy
<lag> Hey Pete
<lag> Are you in Lex too?
<pgraner> lag, no I'm home
<ericm|ubuntu> pgraner, hope everything is OK with your house now?
<pgraner> ericm|ubuntu, no house left, but we are all fine
<lag> pgraner: Did you manage to find somewhere nice to stay in the mean time?
<ericm|ubuntu> pgraner, sad to hear but glad you are all good
<pgraner> lag, currently at my inlaws, looking for a rental house
<pgraner> ericm|ubuntu, thanks
<bjf> lag, irc meetings start up again tomorrow, you still going to report out ARM status?
<lag> bjf: I don't believe I am
<lag> bjf: You'll need to speak to pgraner for a replacement ARM spoke person 
<bjf> lag, maybe we'll just skip ARM this cycle
<lag> bjf: :)
 * lag feels a weight lifted 
<ogra> hey !
<cooloney> bjf: no, actually, i will still work on ti-omap4
<ogra> dare you 
<ogra> :)
<cooloney> ogra: heh, big brother you are here
<ogra> sure i am ... someone said arm :)
 * ogra hopes the kernel team can answer his questions on the ubuntu-devel ML
<cooloney> bjf and pgraner, i will join the meeting this week. since I am still in Boston.
<pgraner> cooloney, great glad to have you
<bjf> cooloney, maybe while you are together in boston you can pick a regular victim for the weekly irc meeting?
<bjf> cooloney, or you can just send the status to me and I can just report it out
<cooloney> pgraner: thx. np for me. glad your family are good.
<pgraner> cooloney, thanks
<cooloney> bjf: i will be in the meeting. and thanks for lag 
<cooloney> he sent out the email for collecting ARM status
<cooloney> ericm|ubuntu: will you join the IRC meeting?
<ericm|ubuntu> cooloney, no problem - as long as you guys are OK
<bjf> cooloney, you'll be in the meeting every week?
<lag> cooloney: I did this week, but probably won't do it again
<lag> cooloney: Take a copy of it and remember to send it out to the ARM Kernel folks every week
<cooloney> bjf: we will join the meeting this week.
<cooloney> bjf: and how about we sent status to your every week later
<bjf> cooloney, that works
<cooloney> bjf: thanks, man
 * cooloney feels good when working from office
<ericm|ubuntu> cooloney, you been house boy for so long time
<hallyn> jjohansen: hey - do you know if there is any trick i need to do, other than putting a bare git tree under /srv/git..../git/serge/, to have it show up in gitweb on kernel.ubuntu.com?
<hallyn> (i looked at yours as example, didn't see any export-ok or anything like that)
<jjohansen> hallyn: did you change the commit hook?
<hallyn> nope
<hallyn> i can git-clone it, fwiw
<jjohansen> hallyn: hooks/post-update
<hallyn> hm, created that, no listing yet
<jjohansen> right, you need to run it manually
<jjohansen> https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide
<jjohansen> the bottom of it
<jjohansen> git update-server-info
<hallyn> doh
<jjohansen> hrmm, it seems I am using a slightly different hook in natty
<hallyn> hm, still nothing.  i guess i'll start from scratch later and try again
<jjohansen> hallyn: hrmm, that should work, the post-commit hook is only needed to update the web when new commits are made,
<jjohansen> hallyn: just follow the wiki, it has worked for me everytime
<hallyn> jjohansen: the wiki page you pointed me to doesn't list --bare, which someone was telling kees to use
<hallyn> think i had used --bare, so i'll try without
<jjohansen> hallyn: right just add --bare
<hallyn> hm, tha'ts what i had done then :)  ok
<jjohansen> hallyn: the whole move the .git out of the checkout is what --bare does
<hallyn> ok, will try that workflow verbatim and then push my patches from externally, thanks
<hallyn> jjohansen: oh, i just looked at index.README - i think my problem was actually just combination of not having originally called it 'name.git', and then not waiting an hour for the cronjob :)  (bc i thought the git update-server-info cmd would do it)
<hallyn> will check later if cronjob did its thing -thx
<jjohansen> hallyn: ah yeah that makes sense
<ericm|ubuntu> apw, ping - so any chance ubuntu-lucid-lbm could be made to work on ARM and how?
 * ogasawara lunch
<ericm|ubuntu> apw, copying over the rt28* from lbm works for me just perfectly
<ericm|ubuntu> apw, thanks man
<ericm|ubuntu> apw, could you take a look at this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/668554
<ubot2> Launchpad bug 668554 in linux (Ubuntu) "Blank display at startup in Sony Vaio CW series (affects: 1) (heat: 464)" [Undecided,New]
<ericm|ubuntu> apw, there should be a fix in 2.6.36 (finding out which is just a matter of git bisect) but it's more like a feature than a fix for SRU?
<apw> ericm|ubuntu, is not a blank screen a pretty obviously a bug thing ?
<ericm|ubuntu> apw, cool - then I'll try figure out the patch and get it backported
<lighta> hi guys, can we attribuate a specific processor for a process in unix ? if yes how ?
<sconklin> lighta: http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.html
<lighta> thanks =)
<sconklin> lighta: you're welcome
<lighta> sconklin, may I ask how should I attribuate a % usage now ?
<sconklin> lighta: if you mean te get a process to run on a particular CPU some % of the time, I don't know whether you can do that.
<lighta> hmm ok thx, i'll continue dig info then
<sconklin> "processor affinity" is probably the most useful search term for this topic
<sconklin> lighta: in general, the types of problems solved by setting processor affinity would mean that you want to leave a task locked to one processor forever
<lighta> yes, because it's long task but wasn't develop to run on multithread
#ubuntu-kernel 2010-11-09
<jjohansen> running and errand
<bjf[afk]> :w
<vanhoof> :w!
<achiang> ZZ
<diwic> smb, when I open "computer janitor" nothing shows up as being cleaned away, and "sudo apt-get autoremove" does not show any kernels either...
<smb> diwic, It usually only shows up excess kernels, so if you have more than 3 or so
<smb> and autoremove would not work with kernels
<smb> as it only cleans packages automatically installed as dependencies and the primary packages removed
<diwic> seems like I have here 35-23, 35-22, 35-20 and 35-19 installed
<diwic> btw, when we talk abi bump, we mean the "20" digit of "2.6.35-20.29", right? 
<smb> diwic, right, 20 is abi and 29 the upload number
<diwic> but -20 and -19 does not have the ubuntu icon in front of them (in synaptic), shouldn't they then show up in the janitor?
<smb> Hm, when I run it here I get only one of 6, so 5 seems to be the threshold
<diwic> ok
<diwic> smb, for autoremove, it would seem wise of dpkg/apt to be able to detect that the dependency is now removed, since linux-meta moved on?
<smb> diwic, Not completely sure but I think it depends on how the package was pulled in. I think I see it happen for the headers, but cannot remember to have seen it with the image
<smb> It might be something to think of
<smb> Or at least to trigger a message on install
<diwic> smb, that's true. Interesting
<diwic> bug #672964
<ubot2> Launchpad bug 672964 in linux (Ubuntu) "udevadm trigger is not permitted while udev is unconfigured (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/672964
<simar> Hi there
<simar> I want to contribute in kernel bug triaging. I was reading the documents at wiki pages. I got most of it except using arsenal?
<simar> Is there anyone avaliable forhelp
<cking> simar, I think mentioning this to JFo would be useful. He comes online in a few hours
<simar> cking, ya I know that. I tried to ping him but he isn't available yet. So I thought asking openly in the channel might help.
<cking> simar, well, JFo is your best bet really
<simar> cking, Lets hope that he will come online soon. Thanks a lot though, for attending me..
<diwic> simar, thanks for wanting to help out, we need you! :-) So "arsenal" is a tool used to change bug reports in an automatic fashion, e g expiring them or adding comments to them based on specific criterias.
<nigelb> so, that's how jfo comments on a lot of bugs at the same time :D
<diwic> simar, so if you want to use that method, probably the easiest way is to talk to JFo or bjf[afk] 
<cking> yep, bjf can help too - forgot that
<diwic> nigelb, yes, that's correct
<nigelb> isn't bryce nifty with arsenel?
<nigelb> diwic: I was impressed that he managed to catch the name of the poster too (not any more thought :p)
<diwic> nigelb, I think bryceh wrote the arsenal scripts originally, but bjf[afk] and JFo are the ones carrying it out for the kernel.
<nigelb> diwic: oh, ok :)
<diwic> simar, what page is it that references "arsenal"?
<simar> hi diwic
<simar> hi nigelb
<simar> I want to start triaging kernel rightaway .. do i need to know what is arsenal just now?
<diwic> simar, no, just get started :-)
<simar> diwic, ok thanks
<simar> diwic, So what should be my first job? Assigning right subsystem tags...
<diwic> simar, it depends on what you know about the kernel 
<diwic> simar, making sure all relevant information is present is a good thing e g
<simar> diwic, I work on touchpad ... in xserver-xorg-input-synaptics and handle some kernel related stuff also..
<diwic> simar, but adding subsystem tags doesn't hurt either
<simar> diwic, here my lp page https://launchpad.net/~simar
<simar> diwic, I have a strong feeling that i can help something in kernel..
<diwic> simar, so there are many things you can do so choose a task you find fun/rewarding to do 
<simar> diwic, Is there anything that I need to follow, that is different from normal triaging, while triaging in kernel .. like input subsystem tags etc...
<diwic> simar, the only thing that comes to mind is to try to avoid marking things as duplicates unless you're sure both hardware and symptom is exactly the same
<simar> diwic, that one i already know
<diwic> simar, also, if you're interested in particular subsystems, there were triaging classes held a month or so ago
<diwic> I held one about audio
<simar> diwic, ya but before that I think I must get myself accustomed to the triaging practises in the kernel team.. 
<simar> May I know where are the logs .. anyhow?
<diwic> simar, http://irclogs.ubuntu.com/2010/09/11/%23ubuntu-classroom.html
<simar> diwic, thanks
<simar> diwic, Thanks a lot, these logs are really very helpful
<yann2> hello! I am stuck with a kernel problem on hardy, and wanted to know what risk I would be taking installing a lucid kernel on hardy... is it like safe, rather safe, rather not safe, or totally insane :) (it's for a critical server)
<yann2> related to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/353070
<ubot2> Launchpad bug 353070 in linux (Ubuntu) "BUG: soft lockup - CPU#2 stuck for 11s! [kswapd0:332] (affects: 4) (heat: 8)" [Undecided,Confirmed]
<yann2> (which isn't that great either, and justifies that I would take some risk to solve it... not sure how long ext3 will enjoy hard power resets..)
<smb> yann2, I'd say somewhere between not safe and insane
<yann2> I guessed so... I don't have that many options sadly :(
<bjf> smb, sconklin, as far as my thinking goes, it doesn't matter if the bug/patch comes in via a support issue or via a linaro request, the patch needs a bug and the bug needs to be verified in a given -proposed or it's reverted
<smb> yann2, afaik the sysfs layout changed to quite some amount and all the kernel drm could be quite a problem. Is upgrading to the next lts a non-option?
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<smb> bjf, That would be my understanding
<yann2> smb,  yes, it is for a Zimbra server, support for lucid only announced for late january
<sconklin> smb: agreed. The new policy is that unless you can verify it we don't take it.
<yann2> and the server is crashing like every 5-6 days, with a hard reset needed
<smb> yann2, is there by chance any network bonding involved?
<yann2> not yet
<smb> yann2, Ok, just was thinking it sounded like an old bug report which may or may not be fixed. 
<apw`> bjf, to confirm ... the meeting is in 1 hour and 15 minutes ... correct
<yann2> alright sent a few options to my boss... looks very close to http://www.youtube.com/watch?v=C9f1TYyvEx8 :)
<smb> I guess the make the options so that the right one is picked. Even if it means to reboot at a relative safe time each x days
<smb> apw`, I think that is correct
<smb> tgardner, You around? Would something obvious strike you when glancing at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/415353 ?
<ubot2> Launchpad bug 415353 in linux (Ubuntu Lucid) (and 1 other project) "karmic/lucid installation slow on "detecting network hardware" with bnx2x (affects: 2) (dups: 1) (heat: 27)" [Medium,Confirmed]
 * apw` notes that google (as always) is showing the thing in the wrong place at least in the US
 * smb wonders which us timezone this thing follows
<cking> apw, it's a double whammy of daylight saving times changing in US and UK over a space of a couple of weeks that can be so confusing to google calender
<apw> cking, yeah cause its _so_ complex to track the location of a calendar entry in a UTC based calendar like the fridge
<bjf> apw, yes, meeting in 1 hr, 7 minutes
<cking> I make it 1hr 6 mins :-)
<apw> bjf, damn google cal.
<cooloney> yeah, date -d '17:00 UTC' will tell you the result
<cking> nice
<sconklin> bjf, apw: when a kernel goes from proposed to updates, isn't it supposed to be pocket copied to -security as well?
<apw> sconklin, nope
<bjf> sconklin, didn't think so
<sconklin> ok.
<apw> sconklin, they are overlays only
<ogasawara> apw: the day 0 kernel/missed ABI bump regression, was there a bug # for that?  and do you need me to look into helping with a bisect?
<smb> sconklin, only security will go into security and updates at the same time
<sconklin> smb: ok. Then in the past for your kernel team meeting report, why is there one column for Updates/Security when the versions may differ?
<sconklin> is that the more recent of the two?
<smb> sconklin, Yes, I tried to save space by making that assumption (always latest updates which is either updates or security)
<sconklin> smb: ok, that makes sense
 * smb tries to remember what he was thinking last...
<apw> ogasawara, the machine turned out to be unreliable phyically, an overheating fault, so the 'worked in -release' 'failed with day-0' is likely related to that and not a real testable case ... so we can ignore it
<sconklin> smb: in your verified nnn/mmm did you count the SRU tracking bugs in the mmm total?
<smb> sconklin, Yes mmm is the total number of bug reports as seen on the proposed tracking page
<sconklin> easy, thanks
<tgardner> smb, what was the change that made Maverick so much faster then Lucid? Was it purely installer bits, or was there a timing change in the driver?
<ogasawara> apw: ah ok.  I did a palm->face maneuver when I realized I'd forgot to bump the ABI.
<smb> tgardner, You are assuming I know that?
<apw> smb, you know everything
<smb> apw, I know that I do not know that
<apw> ogasawara, heheh, not the end of the world
<tgardner> smb,  hmm, frankly I'm assuming its your problem :)
<tgardner> server dude....
<smb> tgardner, Well I hoped the network dude would know something. :)
<smb> Ok, it has a wire
<tgardner> smb, I'm sure its just some stupidly long delay in the driver.
<smb> tgardner, It seems to run into a timeout at some point. Did not see something immediately when scanning over the changes there, so I thought, maybe you may have stumbled over that somehow
<smb> tgardner, I guess i will then have a closer look :)
<bjf> smb, i probably missed it but did you send out any announcement that your stable tree was up-to-date w.r.t. greg's latest and that we could come and get it?
<smb> bjf, You did not miss that. There was no wide announcement yet. Just some verbal, "ok" if at all. I pushed it out to include .32.25 but I am not really sure to remember whether the mainline builds build it
<smb> bjf, It is ready without the drm patches though
<bjf> smb, ack, thanks
<smb> apw, Hm, seems for some reason it did not get build for mainline...
<smb> ugh, I might have forgotten to push the tag
<ogasawara> smb, bjf, sconklin: couple questions regarding the cve scripts...
<ogasawara> smb, bjf, sconklin: I've been using cve-item-start <CVE-####-####> to checkout the CVE's I'm working.
<ogasawara> smb, bjf, sconklin: I notice this checks out a separate branch for each CVE.  Is there a different script I should use so that they all live on the same branch, for ex. a "security" branch?
<ogasawara> smb, bjf, sconklin: Also, is there a script to then push my patches somewhere, even if I've not ran cve-item-save nor built or tested them yet.  I sorta like having a remote backup of all my work just in case.
<bjf> ogasawara, your doing it the way that i do it
<smb> ogasawara, Its meant to be a branch on its own, so that one can later pull the seperate branches together
<sconklin> ogasawara: no, when you run the scripts at the end of all your work they get assembled
<ogasawara> ah, ok
<smb> ogasawara, cve-item-save is it
<sconklin> you can run cve-item-save multiple times
<smb> ogasawara, will push to your repos on zinc so one can get them with cve-item-pull (or cve-release-start)
<apw> smb, bad you
<smb> sconklin, ogasawara The only downside is that when you have not done work on some release yet it is over eager and sets the status to not-needed for some time
<apw> bjf, can we drop none-kernel-n-misc from the meeting -- there are no items on it yet
<smb> apw, Doh! Why always me. :-P
<bjf> apw, can / will do
<apw> bjf, thanks :)
<bjf> apw, done
<ogasawara> bjf, sconklin: just fyi, I've started working my way up from the bottom of the CVE list.  I'm going to stop for a bit and throw together a compat-wireless-2.6.37 LBM prototype for Lucid and Maverick and then resume CVE work.
<sconklin> ogasawara: sounds great, thanks!
<bjf> ogasawara, cool, was planning on going top down
 * bjf is currently working on maverick stable upstream update
 * bjf is running full natty on his x301 and it's working just fine
<cking> gobsmacked
<smb> apw is working on filling my inbox
<cking> denial of service attack?
<smb> more of a report of service attack. All these blueprint updates
<apw> smb, heh
<bjf> sconklin, in my public repo, i've applied the latest upstream stable patches, they build and boot, will send out the announcement with tracking bug shortly
<bjf> tgardner, ericm, is talking to me about mvl-dove changes for lucid and i seem to recall you making a support decision about that in the last two weeks
<tgardner> ericm|ubuntu, why do we care about mvl-dove in Lucid? There are no shipping products based on it as far as I know.
<ericm|ubuntu> tgardner, I need to base hedley on top of that
<ericm|ubuntu> tgardner, or I can keep all the crap within hedley
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
<bjf> ##
<smb> sounds like a new meaning of no-project-uses to me...
<ericm|ubuntu> smb, heh
<ericm|ubuntu> tgardner, what do you think?
<tgardner> ericm|ubuntu, you'll have to remind me offline what hedley is and why I should care.
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<apw> bjf, confusing, a meeting with discussion
<smb> unheard of for quite some time
<bjf> apw, agreed, lets not do that again :-)
<bjf> so remind me, whey do we have uds?
<apw> bjf, heheh well put
<smb> So we have about 12 minutes before I get distracted by the server team meeting
<sconklin> I have a lunch appointment, so we can either do this in 12 minutes or schedule another meeting
<jjohansen> smb: which will have discussion too ...
<smb> sconklin, Not sure we manage that in 12 minutes... but we could try
<sconklin> For discussion of stable schedule, I'd like to have the people responsible for testing present
<apw> a most of us are in the US right now we could do it a little later
<smb> Yes we should. It was more about how physically removing the patches not tested
<sconklin> but I'm game for discussion of process, such as whether to revert or drop patches
<smb> I can drop what I think and then run
<sconklin> go ;-)
<smb> IMO anything involving a force push should not be part of a standard process. 
<smb> But I can see the problem with the changelog
<smb> We have done one upload with buglinks and all
<smb> Doing another upload to proposed will require to include _all_ changelog entries from the version in updates to current
<achiang> can someone educate me on what the abi-<version> file does in the kernel package?
<smb> The add and revert is split into two uploads and the janitor unlikely knows how to handle reverts
<smb> We might get away by hand-removing the bug numbers from the changelog for the reverted patches
<smb> (or script that)
<smb> though sometimes the sru team complains about changelog entries without bugnumbers
<smb> completely removing the patch comments from the old and new changlog (for the reverts) might end in an upload without apparent patches
<smb> So I am not sure I really can offer a good solution atm
<ogasawara> I think you can keep the bug number, just remove the "BugLink" string right?
<sconklin> While we're planting flags in the ground - I am fundamentally opposed to introducing any more processes which rely on hand-applying things such as this. Every bit of new process we add should be scriptable, even if we have to abuse or redefine tags and changelog text to implement it. The number of human errors we have is way too high.
<smb> Except the inherit fear of evil when I hear drop and force-push
<smb> ogasawara, The buglink in the patch may not need removal
<smb> ogasawara, just the lp # entry in the changelog
<sconklin> It seems that we could come up with a solution that reverts and drops buglinks in the changelog
<apw> yeah i can see that working
<ogasawara> smb: right, and I thought the lp janitor searches for the "BugLink" string
<smb> sconklin, right and do scripting for that
<ogasawara> smb: so if we just remove that string from the changelog
<sconklin> One thing tha worries me is our lack of any way to test these changes before we push the first proposed kernel
<jjohansen> smb: you don't have credentials to upload EC2 kernels yet do you?
<sconklin> smb: agreed - it could be scripted
<smb> ogasawara, I thought not, it searches for the thing generated in the changes file generated from the lp: # strings generated from the buglink
<smb> jjohansen, Not that I conciously know about any
<sconklin> we will probably find some assumptions that exist such as "no bug will ever go from fix committed and in proposed to wontfix"
<jjohansen> smb: okay, I'll bug smoser
<smb> sconklin, right, that might be another thing
<smb> We have it in fix-committed, it won't go to released after removing the bug references in the changelog
<smb> but also not go into won't fix
<smb> Though i think thats just what sconklin said
<sconklin> going to wontfix is the manual (scripted) step we'll take when it's not verified at the end of the window for verification
<bjf> we need a script to put the final comment onto the bug, that can just as easily change the state while it's at it
<sconklin> bjf: ack
<smb> ack, and by using reverts you have a sensible (at least to me) forward flow from one upload to the revert upload
<sconklin> in fact, I'd like to run a script, have it close all unverified bugs wontfix with a text explaining it, then generate a list of reverts to apply so that I can feed that into git
<bjf> interesting email from pitti that we are going to be dropping changelogs from packages
<smb> sconklin, bjf Probably needs some training or talking to pitti about their archive admin scripts and how they like that
<sconklin> One thing I'm afraid of is that reverts make it too easy to put things back in, and I want them really very dead
<bjf> sconklin, i don't see how a revert makes it easier to get back in (revert a revert?)
<sconklin> yeah, ugly idn't it?
<sconklin> isn't it. I'm not that redneck yet ;-)
<smb> sconklin, Probably trying to bite yourself while saying it. :)
<bjf> sconklin, the policy is that we don't revert a revert, a new, full sru request must be made
<sconklin> although it looks like reverting is the concensus, and I'm ok with that. We just have to figure out the tools
<skaet> bjf, sconklin - wontfix has the semantics of closed, so shouldn't it really be moved back to "In progress"?   
<sconklin> My intention is closed.
<bjf> skaet, no, if they can't be bothered to test, it's not a bug we care about
<sconklin> what he said
<skaet> bjf, sconklin - define "they"
<sconklin> The people who file bugs
<bjf> skate, "they" is the original bug submitter
<skaet> and if the original submitter is on vacation for a week....   seems a bit harsh.
<kamal> idea? change it to "Incomplete" and let it auto-expire if "they" don't take further action.
<sconklin> if they don't care enough about having it fixed to test a proposed kernel, we're done with it
<bjf> skaet, agreed, i think i mentioned that at UDS
<smb> interesting question would be what if it is verified by someone else?
<sconklin> so - if we are to allow re-inclusion of a patch - who decides?
<bjf> smb, i don't think we look closely enough to tell so that would get in
<sconklin> Two more acks from the kernel team?
<smb> bjf, sounds reasonable
<bjf> sconklin, full SRU process, new bug, two acks, etc.
<sconklin> I don't care whether it's verified by the exact reporter - I'll take anything that's the correct kernel on the correct hardware
<bjf> sconklin, but how do you verify that? I could just write a script which marks all the "verification-needed" to "verification-done"
<sconklin> bjf: I can support that, but be aware that our commit logs are going to be horrendous.
<sconklin> bjf: I can;t verify anything that I haven't put my hands on. At a certain level, we have to trust people
<bjf> sconklin, that was my point w.r.t. "I'll take anything that's the correct kernel on the correct hardware"
<sconklin> And I expect that at some point, we'll have to make a value call on something for which the hardware is no longer available.
<bjf> sconklin, bottom line is that you'll just have to trust people
<sconklin> "I'll take anything for which someone has claimed to have tested the proposed kernel on the specific hardware in the bug"
<sconklin> better?
<bjf> heh
<smb> At least this should make "they" clearer for skaet 
<skaet> :)
<sconklin> If we don't trust people, all bets are off, and we may as well give up.
<smb> "In god we trust, but you pay cash" :)
<sconklin> I have to run to a lunch appt. This needs more discussion, want to set a time?
<bjf> did we decided anything or just continuing to stir the pot?
<sconklin> if we decided anything tentatively I think it is to:
<sconklin> use reverts
<bjf> if reverts become an issue we can always revisit the issue
<sconklin> close bugs either wontfix or incomplete and requrie a new SRU and ack process to repoen
<sconklin> investigate the side effects of what we want to do on archive admin scripting
<sconklin> make sur ethat what we do is scriptable
<sconklin> anything else?
<bjf> sounds like a good summation 
<smb> ack
<smb> I think more discussion will come as implementation comes closer if so
<sconklin> I suspect that our workload from processing repeat requests will increase in the short term until people figure out that we a re serious about reverting patches - for the first few cycles.
<smb> Yes, that sounds like to be expected
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - November-16 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<manjo> apw, can you install dos2unix on tangarine ? 
<apw> manjo, which package is that in
<manjo> I think if you do apt-get install dos2unix it works .. it does on my local machines atleast
<manjo> manjo@lazy:~$ apt-cache search dos2unix
<manjo> dos2unix - convert text file line endings between CRLF and LF
<manjo> manjo@lazy:~$
<manjo> apw, can you find it ? 
<manjo> strangely dos2unix has no package on tangerine... might be in multiverse ?
<manjo> apw, I have multiverse on mine ... 
<apw> multiverse ... gah
<manjo> sorry
<manjo> apw, also what do you think of sending rtl8192se to staging ? we are currently carrying that weight around in ubuntu-delta
<manjo> apw, I can also send the fw to woodhouse now that they have re-distributable licence for it 
<manjo> apw, ofcouse I will check with realtek before I do any of this.. currently I am trying to get it integrated in mainline kernel 
<manjo> build
<skaet> apw, can you send me a link to the page you and Allison were discussing last week?
<apw> manjo, are you sure its not already carried, see tgardner's email
<manjo> apw, yep I see what he is saying.. can you install dos2unix ... I have already pulled the latest for Natty, but I need to clean it up before I add and commit 
<tgardner> manjo, use tofrodos on tangerine
<manjo> ok
<sconklin> does this ring any bells with anyone? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/672964
<ubot2> Launchpad bug 672964 in linux (Ubuntu Lucid) (and 1 other project) "2.6.32-26 unbootable: does not find root file system (affects: 1) (heat: 8)" [Critical,New]
<manjo> tgardner, command not found 
<sconklin> Stefan said it looks a bit like a dependency problem from before that was never found
<tgardner> manjo, 'man tofrodos'
<sconklin> from Stefan earlier - "sort of the kernel gets configured before a udev or inittools update and when that is ready the kernel is not reconfigured"
<manjo> tgardner, goit
<tgardner> sconklin, did you look in his dmesg? there are a boatload of errors. I think maybe he's got HW problems, or his disk is full.
<sconklin> hmm. His misfortune would make me happy if that's the case. Does that make me a bad person?
<tgardner> sconklin, hmm, looks like those are cdrom issues.
<tgardner> this does not appear to be systemic. I think its something specific to his machine.
<sconklin> tgardner: he does state that using the previous kernel works
<tgardner> sconklin, right, but it could also be a partial initramfs update.
<sconklin> yes
<sconklin> I'm finding earlier reports of similar problems
<tgardner> bummer
<sconklin> The last few comments of this bug could relate https://bugs.launchpad.net/ubuntu/+source/devmapper/+bug/358654
<ubot2> Launchpad bug 358654 in watershed (Ubuntu) (and 9 other projects) "udevadm trigger is not permitted while udev is unconfigured (affects: 31) (dups: 2) (heat: 161)" [Medium,Fix released]
<sconklin> also a long forum thread http://ubuntu-ky.ubuntuforums.org/showthread.php?t=1567147
<godber> has this ticket reached anyones eyeballs? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/659422
<ubot2> Launchpad bug 659422 in linux (Ubuntu) "Boot failure after upgrading kernel to 2.6.32-25-generic (affects: 4) (heat: 133)" [Undecided,New]
<godber> oh, nice bot
<sconklin> jjohansen: ^^
<sconklin> godber: thanks, we'll have someone look at it
<jjohansen> sconklin: looking
<sconklin> see? ;-)
<godber> thank you, you guys are magic
<sconklin> jjohansen: thanks
<godber> uhm, something I did has just stopped the segfaulting in 659422
<godber> I installed a bunch of the -25 kernels that might work for my platform {generic,virtual,386}
<godber> then I went back and installed linux-image-2.6.32-24
<godber> to verify that that worked like the reporter said
<godber> it worked, then I rebooted into the -25 (which previously segfaulted), and it worked too
<godber> and the console login now says "Ubuntu lucid (development branch)
<apw> bug #659422
<ubot2> Launchpad bug 659422 in linux (Ubuntu) "Boot failure after upgrading kernel to 2.6.32-25-generic (affects: 4) (heat: 133)" [Undecided,New] https://launchpad.net/bugs/659422
<godber> oh, I may have installed from a lucid development iso
<godber> I will fix that
 * jjohansen -> lunch
<godber> apw, yes, thats what I mean
<godber> AFAIK it only happens when running as a guest in VMware ESX 4.1
<apw> godber, and no idea what you changed which made this work
<godber> yeah me neither
<godber> unless maybe its related to initrd maybe?
<godber> oh, I misread you
<godber> the only thing I did was install the previous kernel, reboot to that, then reboot again to the most recent kernel
<godber> I am trying to recreate that again
<godber> though I am annoyed to discover I am not on 10.04 proper, though I know that fails as well
 * ogasawara late lunch
<xelister> how to get the ubuntu kernel (checksummed/signed) sources?
<xelister> in order to patch it (with parts of grsecurity) and build it
 * manjo checking out 
#ubuntu-kernel 2010-11-10
<sugnan> hello, am using Ubuntu 10.10 (Maverick), when i tried to compile the linux kernel of version 2.6.36 and 2.6.37( my default version is 2.6.35), i get the error mount mounting none on /dev failed: no such device, when i try to boot. can someone please help, am a newb and compiling kernel for the first time. is it because the ubuntu version am using doesnot support this version
<sugnan> is it the right channel to ask question regarding ubuntu kernel  development ?
<RAOF> Yes.
<sugnan> RAOF, am using Ubuntu 10.10 (Maverick), when i tried to compile the linux kernel of version 2.6.36 and 2.6.37( my default version is 2.6.35), i get the error mount mounting none on /dev failed: no such device, when i try to boot. can someone please help, am a newb and compiling kernel for the first time. is it because the ubuntu version am using doesnot support this version
<RAOF> First, the meta-question: why are you building a new kernel?
<sugnan> actually i wanted to upgrade to the latest version, and i have added few user defined protocols in it
<sugnan> RAOF, i have made my own device, in order interact with it i have designed my own protocol, so i have added that protocol in the linux kernel code, now i want to compile it, but i ended up with this problem
<RAOF> I'm not familiar with that specific problem; it sounds like you perhaps haven't built in all the necessary options, such as devtmpfs?
<sugnan> RAOF, ya i get some error relating devtmps too
<sugnan> RAOF, can i just know how to compile the modified kernel for the current ubuntu am using, is it necessary that i need to compile the whole ubuntu? or is it necessary that i compile the same version of the kernel am having by default ?
<RAOF> I'm not sure what the question is.  It's certainly not necessary to recompile anything other than the kernel, and it's entirely possible to use different kernels; the kernel team maintain a couple of different mainline builds, which work.
<sugnan> RAOF, thanks
<smb> morning
<smb> -> lunch
<komputes> Is there a tag for card reader bugs - Can someone please have a look into this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/670181
<ubot2> Launchpad bug 670181 in linux (Ubuntu) "Dell Precision M6300 SD Card Reader (Ricoh R5C592 memory stick) Will Not Mount After Upgrade To 10.10 (affects: 1) (heat: 433)" [Undecided,New]
<manjo> komputes, can you try http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-11-04-maverick/ ? and post the results to the bug? 
<manjo> komputes, sorry http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-11-09-maverick/
<komputes> manjo: just the "image" and the "headers" for my arch? or the one that says "all" as well?
<manjo> komputes, I think those headers are for i386
<manjo> ie all
<komputes> manjo: never mind
<manjo> komputes, do you have the module  tifm_sd loaded?
<m4t> i filed this under gcc, but maybe someone here can shed some light: https://bugs.launchpad.net/bugs/673236
<ubot2> Launchpad bug 673236 in gcc-4.4 (Ubuntu) "maverick toolchain producing unbootable (hanging) kernels (affects: 1) (heat: 6)" [Undecided,New]
<komputes> manjo: I don't see tifm_sd in the lsmod output
<skaet> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
<hallyn> uh oh, i see tangerine got rebuilt?  :)
<jjohansen> hallyn: tim upgraded the disks
<hallyn> jjohansen: yup, i knew it was coming eventually :)
<pmatulis> why is the lucid netboot kernel [1] dated april 2010?  this is old.  am i missing something?
<pmatulis> [1] http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
<sconklin> For bugs which are not verified and have the fix reverted, we can set them "wontfix" or "incomplete". Any thoughts from anyone about this?
<bjf> sconklin, personally, i like "wontfix" and require a new bug and full, new SRU process for the related patch
<sconklin> That's what I proposed, but I've heard the arguments that 1) wontfix isn't accurate, as we will fix it if it's tested, and 2) incomplete accurately reflects what happened. I'm afraid that bugs already turn into a mess too often, and we use them essentially for tracking tasks, so we should open a new bug. Otherwise, we also have to unwind the "fix committed" states
<bjf> sconklin, but once a bug "needs verification" then it is more than just a bug, it is also tracking a process, which the bug states were never intended/designed to be for so it seems we can make them mean anything we want (i know this is a bit of a stretch but i hope you get my drift)
<sconklin> bjf: right - we have no way to re-use a bug for another trip through the process, so I think we need to close it and start another. We agree?
<bjf> sconklin, agreed
<jjohansen> ugh, that is less than ideal
<bjf> what would be ideal then?
<sconklin> I'm open for suggestions
<sconklin> by the way, I think we'll also break patchwork, when people reply to earlier email to re-request acceptance of a patch that was previously accepted. But we can deal with that later
<jjohansen> sconklin: I don't have a better suggestion, ideally you could reuse the bug.  Having to close and start a new bug is just extra work and an extra step that mistakes can happen in.  /me was just kvetching that the process isn't as nice as it could be if it had been designed to accommodate SRU needs from the start
<ogasawara> sconklin: hrm I slightly in favor of re-using the existing bug.  It should be simple enough to hammer out an arsenal script which posts a comment about the revert, sets the bug to Incomplete, and resets the tags.
<ogasawara> sconklin: having to open a new bug, re-submit/re-ack patches is going to get annoying.  The patches and ack's should still be good, it's just the verification that failed.
<lamont> how do I disable ipv6 on just one interface?  or can I?
 * lamont finally finds it
<sconklin> ogasawara: the actual agreement that was reached at UDS was that bugs will be closed "wontfix". There was a lot of discussion at UDS, and I feel like we're having it all over again.
<sconklin> It's not that I'm opposed to refinement, but I do want to end discussion at some point and try something
<ogasawara> sconklin: ack
<ogasawara> sconklin: and we can always refine the process if we find our approach need tweaking
<sconklin> My overriding goal from a selfish point of view is to minimize the amount of work that the stable team has to handle, as I'm not sure we will be able to keep up.
<sconklin> And I am very open to changing things that don't work.
<sconklin> I'm also concerned about creating still more bugs which seem to live forever
<bjf> ogasawara, i'm curious to your thinking on not having to re-ack patches, once a patch has been reverted how would it get back into the repository?
<sconklin> I'm frustrated by having to use a bug tracking tool to implement process, but it's what we have . . .
<sconklin> so bjf - to recall some of the discussion that we had at UDS . . . One proposal was just to revert the patches and leave them on the tip of the tree until they eventually get tested.
<sconklin> But this would lead to an ever-increasing load of cruft that we have to carry around.
<bjf> sconklin, you'd revert, re-upload, then reapply?
<sconklin> e also wanted to get assurance by whoever re-proposed the second SRU that there was a commitment to testing
<ogasawara> bjf: I guess my thought process is that the patch was already reviewed and ack'd for it appropriateness, the fact that it was reverted due to failed verification doesn't actually reflect the patch itself is bad.  so if a reporter said "oops I was on vacation and wasn't around to test" we could just re-apply it.
<sconklin> bjf: yeah - I'm NOT recommending that, it was just an idea that was rejected
<ogasawara> bjf: and we could tag the bug with something like "re-apply" or whatever to know which patches to shove back in for the next upload.
<sconklin> ogasawara: from the end user's POV I see this - if they're on vacation for a week and miss verification, we should make it easy for them to reapply. And honestly, getting everything correct on an SRU request is hard enough as it is.
<sconklin> to totally throw a wrench in this - there are bugs which track the same fix in multiple releases
<ogasawara> sconklin: ugh, now that could get messy
<bjf> sconklin, known issue, and the question is when someone marks it verified which release were they referring to?
<sconklin> example: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/580749
<ubot2> Launchpad bug 580749 in linux (Ubuntu Maverick) (and 5 other projects) "Pulseaudio is not running VT1708 (affects: 2) (heat: 33)" [Undecided,Fix committed]
<ogasawara> almost seems you'd need to make it verification-done-<release>
<sconklin> bjf: This is currently handled manually by pitti. As he described it to me, when someone says it's verified for a release, he leaves both the verification-needed and verification-done flags set until every release is verified, then removes the verification-needed tag.
<sconklin> I think we should probably change to verification-xxxxx-<release>, but this requires changes to Pitti's scripts that he uses
<bjf> sconklin, but how does he know which release the commentor tested? does he ask them? (i'm assuming that he does)
<sconklin> bjf: dunno, if it's not obvious from the comment
<bjf> sconklin, if we ignore reverting patches, the fact that we now require certification testing of the proposed releases puts us in a much better place than we were before
<sconklin> I'm worried that we have so much home-grown processes and so many tools which are dependent on special tags, text formatting in changelogs, etc, and so little of it is documented, that we have potential to break things unless we add more unique tags for our use.
<sconklin> bjf: you mean if we don't revert? I don't think that's an option. But yes, I think we get more goodness from testing than from any other piece of this
<bjf> sconklin, frankly the fact that we are using tags (which any user can add/remove/modify) for processes is not a good thing
<bjf> sconklin, i'm not suggesting not reverting (though i'd like to)
<sconklin> bjf: agreed, but today;s not the day for that fight. It's beyond the scope of what we can influence
<sconklin> and reverting patches is being done to bring us in line with the release guidelines for Ubuntu, so unless they change, I'm trying to do a better job of compliance with those. I think requiring verification is a good thing.
<sconklin> If we can manage the repositories, I don't think it would be terrible to just revert and reapply patches that don't get verified, then drop them after three strikes or something. We can think about that as an option if the process is too difficult to manage with reverts
<sconklin> (that was more thinking out load than anything)
<ikepanhc> sconklin: once verification for an SRU bugs finished, shall bug reporter modify the tag from verification-needed to verification-done or wait SRU team to review the verification and modify the tag?
<sconklin> So far, we've let the user do it, and even instructed them to do it in the text added to tge bug
<sconklin> ikepanhc: the reason is that I want to avoid another task that the stable team has to do on the verification deadline day, which is to open all the unverified bugs and read the comments to see whether it's verified. I want all of our operations to be scalable to more fixes without requiring more time, and I want them all to be able to be automated with scripting when possible.
<ikepanhc> sconklin: make sense to me
<jjohansen> however relying on reports to set tags right is not going to work well
<ikepanhc> sconklin: another question, for bug 640214, everything is fine with karmic to enable Intel B43, but not on lucid, x-x-v-intel driver is not updated (maybe because nomination for lucid is not accpeted yet), can I just put verification-done there? (for kernel, it is done)
<ubot2> Launchpad bug 640214 in xserver-xorg-video-intel (Ubuntu Karmic) (and 8 other projects) "X failed on Intel B43 machine (affects: 2) (heat: 24)" [Medium,Fix released] https://launchpad.net/bugs/640214
<sconklin> ogasawara, bjf: another argument I just thought of in favor of NOT closing unverified bugs - they may have milestones set which are important, and be requiring new bugs to be opened, we may be proliferating cruft into the release and milestone tracking tools - this is another example of magic processes that work off of bugs that I don't fully understand
<sconklin> ".... by requiring new bugs ... "
<bjf> jjohansen, i agree completely, but we do it all the time
<sconklin> bjf, jjohansen: so more accurately - instead of eliminating the need to review every unverified bug before reverting on revert day, I'm hoping to minimize the number that need to be looked at, by asking people to set the tags. I think review will still be required.
<bjf> sconklin, so, we are going to have to visually inspect every bug to make sure the bug was not left on by mistake nor removed by mistake
<jjohansen> bjf: yep, however we seem to be doing it more and more, and basically fear its getting to be too much
<jjohansen> sconklin: what bjf said
<bjf> sconklin, sorry "bug" -> "tag"
<sconklin> I think that we at least have to check the ones without a verification-complete tag and see whether a comment says they are verified. For the converse, we have to decide what it means if someone sets the verification-done tag with no comment or explanation.
<sconklin> As it stands now, we let them pass.
<sconklin> and I think that now, no one pays much attention to bugs unless they are verification-needed. pitti would know. 
<sconklin> I've asked him to join this room - he's away at the moment. 
<sconklin> On monday we're going to do ~something~ to the unverified bugs - either close wontfix, or set to incomplete. (and we'll revert the changes). Since we're unsure about this, it seems to me that setting incomplete is the safer of the two options until we figure it out. Agree? Disagree? There will be text added explaining everything that is done.
 * jjohansen -> lunch
<ogasawara> sconklin: agree, setting to incomplete for now seems better imo.
 * apw notes boston has ok wifi
<sconklin> ikepanhc: it's not clear to me from yoru comment in bug #640214 whether this is a pass or fail
<ubot2> Launchpad bug 640214 in xserver-xorg-video-intel (Ubuntu Karmic) (and 8 other projects) "X failed on Intel B43 machine (affects: 2) (heat: 24)" [Medium,Fix released] https://launchpad.net/bugs/640214
<ikepanhc> sconklin: for karmic, its passed, for lucid, proposed kernel works but still need xserver-xorg-video-intel supported
<sconklin> ikepanhc: the change that's needed for lucid is all in xorg and not in the kernel, right? Are there any bad effects of having it in the kernel and not fixed in xorg?
<ikepanhc> sconklin: for graphic chip support, we need to add ids in kernel and x-x-v-intel. no bad effects after kernel patched, at least we have the correct resolution on monitor
<apw> that sounds like a pass to me :)
<sconklin> apw: +1
<ikepanhc> for kernel, I think it is
<sconklin> I'm updating the bug now
<apw> sconklin, whats the verified/unverified count today :)
<ikepanhc> thanks
<sconklin> give me a sec, and I'll have some numbers, I'm reviewing them all and spamming them now
<apw> sconklin, liking the sound of that
 * apw notes t.b has started building lucid
<apw> (chroots)
<sconklin> ikepanhc: you dais karmic and lucid in the bug, but the bug is open for karmic and maverick kernels
<ikepanhc> sconklin: yes, but SRU patches is for karmic and lucid
 * ogasawara lunch
<sconklin> ikepanhc: yes I see. Thanks
<ikepanhc> sconklin: the same patches landed on maverick through stable kernel
<sconklin> excellent
<sconklin> apw Lucid numbers are (probably) 8 verified, 15 unverified, and one fail that could be a show-stopper
<sconklin> the status page is genrated by a cron job and lags reality
<apw> sconklin, i assume we can just revert the fail too
<sconklin> That's my plan
<apw> is it one we care about ?
<sconklin> apw: scratch that - the fail is probably not associated with any particular patch, and is reported against a tracking bug
<apw> sconklin, heh ... well that is no use
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/672964
<ubot2> Launchpad bug 672964 in linux (Ubuntu Lucid) (and 1 other project) "2.6.32-26 unbootable: does not find root file system (affects: 1) (heat: 8)" [Critical,New]
<sconklin> David is out today, so I expect he will respond to the latest comment tomorrow
<apw> sconklin, isn't that one the one someone was talking about on here yesterday and had gone away and was not reproducible ...
<sconklin> apw: I forgot - probably 4 of the "unverified" bugs I listed for Lucid are tracking bugs, so don't count - so it's better than it looks
<apw> shouldn't you just move them verified (as they have no verification to do?)
<apw> other than the one for QA of course
<sconklin> smb said he thought that this one had come up before and been unreproducible, and a search of the forums, etc finds references to similar problems going way back, as far as I can tell they are generally fixed by doing what Tim suggested in the bug comment
<sconklin> Pitti uses the verified status in those for tracking something, I think
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/654586 looks like a pass to me from the comments - any TI-OMAP experts wanna have a look?
<ubot2> Launchpad bug 654586 in linux-linaro (Ubuntu Maverick) (and 1 other project) "No functionality to detect IGEPv2 board version (affects: 1) (heat: 99)" [Undecided,Fix released]
<apw> sconklin, you'd probally want bryan or ogra for ti-omap (omap3) stuff
<apw> coolooney is in the air though
<sconklin> mpoirier: is it possible to test https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/654590 on Maverick?
<ubot2> Launchpad bug 654590 in linux-linaro (Ubuntu Maverick) (and 1 other project) "WLAN-BT GPIOs need proper initialization (affects: 1) (heat: 97)" [Undecided,Fix released]
<mpoirier> sconklin: looking
<sconklin> There may be bugs for which we must accept verification in Linaro kernels of the same patch as valid for distro releases
<mpoirier> sconklin: I thought I asked enric to test that one... hold on.
<mpoirier> sconklin: I did ask him.  I'll look around for his anwer - I'm sure he did test it...
<jcrigby> apw:thanks for fixing my work items
<apw> jcrigby, heh, i get the error messages :)
<apw> and i figured if i did that one, the email update would help you fix the others :)
<jcrigby> apw, ahh now I understand
<apw> jcrigby, fwiw you probabally should always use the 'Work items for <milestone>:' form, as without a milestone they don't track correctly and if you use the one on the blueprint some swine can change the overall milestone and make them all move without your notice
<jcrigby> ok,I'll do that
<sconklin> mpoirier: https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/651589
<ubot2> Launchpad bug 651589 in linux-linaro (Ubuntu Maverick) (and 1 other project) "VBUS and overcurrent GPIO init missing in IGEPv2 board (affects: 1) (heat: 87)" [Undecided,Fix released]
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/654586
<ubot2> Launchpad bug 654586 in linux-linaro (Ubuntu Maverick) (and 1 other project) "No functionality to detect IGEPv2 board version (affects: 1) (heat: 99)" [Undecided,Fix released]
<sconklin> apw: Maverick numbers are approximately 17 verified, 2 tracking bugs, and 11 unverified, with two that I expect will get verification soon
<apw> sconklin, that must be about a 4x on the normal ratio!
<sconklin> I'm going to try to track the numbers each cycle. It will be interesting to see how it trends
<apw> sconklin, sounds good to me ... /me goes find a tin can with wings
<sconklin> I'm bailing out - thanks for all the help with the new stuff everyone!
<bjf> c u monday
<sconklin> There's a cold one calling me . . .
<skaet> have a good weekend.
#ubuntu-kernel 2010-11-11
<brucezhang> hi all, i have a camera supporting the Mjpeg and H264 format. Now i can play the mjpeg format streaming, but i have no idea to play the h264 format. the linux do not support the h264 format.
<brucezhang> Could you give me some advices?
<RAOF> I think that it's highly unlikely this is a kernel problem; looking further up the stack is probably what you need to do.
<brucezhang> Hi RAOF , thanks for your reply. I want to add MPEG format  to the V4L2 Driver. Do you have any ideas? 
<RAOF> brucezhang: Is the V4L2 layer currently incapable of forwarding mpeg streams on?  It's not a problem further up?
<brucezhang> In linux driver layer, V4l2 does not support the H264 format.
<RAOF> It surely can't be too hard to add that :)
<RAOF> You're basically just passing on data from the card, right?  All that's needed is an extension of the content negotiation, and possibly some metadata?
<brucezhang> i get data from usb dev.
<brucezhang> by the command usb-devices, the MJPEG interface can mount the dirver, but the MPEG interface can not mount the driver.
<akgraner> apw - guess what is happening again - but now it's not all the time - and I am trying to narrow down what triggers the temp increase reliably 
<apw> akgraner, bah i hate that machine
<akgraner> me too
<akgraner> just want to give you a heads up
<akgraner> as soon as I figure the trigger part - I'll file a bug :-)
<mpoirier> sconklin: https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/654590
<ubot2> Launchpad bug 654590 in linux-linaro (Ubuntu Maverick) (and 1 other project) "WLAN-BT GPIOs need proper initialization (affects: 1) (heat: 12)" [Undecided,Fix released]
<tseliot> apw: did you port this patch of yours to 2.6.37? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=985f7e2eabee43c30fd3f4d44c8c291c143615f3
<apw>  tseliot i believe this is patch is currently missing as it failed to apply
<apw> its on my list to fix
<apw> tseliot, seeing issues ?
<tseliot> apw: ok, I was asking as, after porting some new radeon code to Maverick's kernel, the kernel works well but the ddx driver can't open the drm device
<apw> could easily be the issue, i have a crap load of patches on the floor at the moment
<tseliot> apw: I'll work on it as otherwise I really wouldn't know what could be causing the issue
<apw> want me to have a peek ? 
<apw> tseliot, ^^
<tseliot> apw: yes, please, help would be welcome :)
<tseliot> apw: BTW here's what I get in the X log (i.e. it fails to open /dev/dri/card0): http://pastebin.ubuntu.com/530053/
<smoser> jj-afk, smb if you're both about (i realize jj-afk is afk) then we can chat a bit whenever
<jj-afk> smoser: i'm here
<smoser> smb, ?
<smb> Got here
<smb> Is it 6pm utc ?
<smoser> cool
<smoser> no. not for another 50 minutes, but if we're here and available we can get it out of the way
<smb> sounds good
<smb> just got another cup of tea
<smoser> ok. you want to just do it here ?
<smoser> i see no reason not to, unless others are annoyed by it
<smb> Nah, they are mostly on holiday anyway. :)
<smoser> ok
<smoser> walking through http://paste.ubuntu.com/530110/
<smoser> bug 614853
<ubot2> Launchpad bug 614853 in linux-ec2 (Ubuntu) (and 1 other project) "kernel panic divide error: 0000 [#1] SMP (affects: 2) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/614853
<smoser> jj-afk, it looks like we've got a functional patch there ?
<jj-afk> right I think we have this one
<smoser> ok. so you are who supplied the kernel, that wasn't apparent to me
<jj-afk> but the question is whether the patch is SRUable
<smoser> really ?
<jj-afk> yeah sorry, I built that at UDS
<smoser> http://launchpadlibrarian.net/58956370/lp614853.patch ?
<smoser> kind of looks SRUable to me :)
<jj-afk> hehe
<jj-afk> we can try
<smb> Main question about sru ability is whether upstream takes it
<jj-afk> upstream will not take it
<smb> have you asked?
<smoser> well, this is quite common, so we need to get a fix in for it.
<smoser> who do we/I have to beg ?
<jj-afk> smb: no but there hasn't been any desire to pickup the 2.6.35 fix that its backported from
<smb> I think what jj-afk means is that it only covers things, but does not fix the main issue
<jj-afk> smoser: we can send it to gregkh for the stable tree
<jj-afk> but with it not going into newer kernels I doubt he will take it
<smb> jj-afk, Though he usually wil reject it when there is no upstream
<jj-afk> right
<smb> yeah
<smoser> i've not seen this on maverick (ie, newer kernels)
<jj-afk> we can try to push it as an UBUNTU: SAUCE:
<smoser> possibly still there, but we dont see it. only on linux-ec2.
<smb> We will probably need to see who is upstream for that bit and see whether it is acceptable as temp solution
<smb> until they find the real fix
<jj-afk> smoser: the schedule is significantly different on newer but it still exists
<smoser> well, ok. so will one of you push on that (and put these comments in the bug) ?
<smoser> push on that == SRU 
<jj-afk> smoser: speaking of which can you bundle and upload the test kernel for me, I haven't been able to get my credentials to work
<jj-afk> smoser: yes
<smoser> jj-afk, where is that kernel ?
<jj-afk> smb, and /me will coordinate
<smoser> ok. jj-afk get me a link to your kernel builds for that and i'll get them uploaded
<smoser> next bug
<smoser> bug 651370
<ubot2> Launchpad bug 651370 in linux (Ubuntu Maverick) (and 1 other project) "ec2 kernel crash invalid opcode 0000 [#1] (affects: 7) (dups: 1) (heat: 54)" [Medium,In progress] https://launchpad.net/bugs/651370
<smb> I think were only waiting for it to be applied to maverick
<smoser> i think we have that ready to go.
<smb> (disabling intel_idle for virtual)
<smoser> so its in kernel teams tree ?
<jj-afk> yes
<smb> not yet I believe
<smb> mostly due to uds and plumbers
<jj-afk> hrmm, I got a merged mail
<jj-afk> maybe it was only natty
<smoser> and when would the next sru kernel come ?
<smb> I think it was for natty
<smb> yeah
<smoser> ie, when can we have this in ?
<jj-afk> but sent for both natty and maverick
<smoser> for maverick, when can we have it in.
<smb> I ll chat with ogasawara  about it
<smoser> ok. thanks.
<smoser> next bug
<smb> basically I could as well as the acks are there but I don't wan to mess
<smoser> bug 567334
<ubot2> Launchpad bug 567334 in linux (Ubuntu) (and 1 other project) "blocked tasks delay cloud-init for 240 seconds (affects: 2) (heat: 27)" [Medium,Triaged] https://launchpad.net/bugs/567334
<hallyn> looking around the wiki, but not finding:  if I want a valid kernel version for a custom natty tree, how can i name it?  2.6.37-2.10userns1 doesn't work.
<smoser> do either of you feel like that might actually be bug 666211 ?
<ubot2> Launchpad bug 666211 in linux (Ubuntu) "maverick on ec2 64bit ext4 deadlock (affects: 3) (heat: 28)" [High,Confirmed] https://launchpad.net/bugs/666211
<smoser> or that they're the same issue
<smb> hallyn, tried +userns1?
<smb> smoser, It could be
<smb> Not really sure about that, yet
<smoser> ok, and we think we have that understood ?
<smb> smoser, Though while you said it woul dbe both I only saw lucid feedback i think
<hallyn> smb: no, i'd tried '-'.  (but i think that actually failed for a different reason).  '+' works - thanks!
<smoser> yeah.. .i'm not sure , i'd have to look at logs again if i've seen it on maverick.  
<jj-afk> smoser: I'm actually don't think it is 666211 but that they are related
<smoser> ok. and do we think we're moving towards a fix for them ? 
<smb> something io related seems to be at least very slow
<smb> or deadlocked 
<smoser> well, yeah, i think deadlocked.  nothing goes that slow.
<smb> but this is not so easy to understeand
<apw> smoser, why doesn't 2.6.37-2.10userns1 work, that fits a pattern i use comonly
<smoser> hallyn, ^ apw, i think that was to him
<apw> jj-afk, i cirtainly did merge that patch for natty, i did not merge it anywhere
<smb> smoser, we got similar messages when lucid ext4 had writeback problems. Things would go away eventually but very very slowish
<apw> hallyn, yep i meant you
<smoser> smb, ok.
<smoser> ok. so well, i'll let you move on that one, primarily looking at bug 666211
<ubot2> Launchpad bug 666211 in linux (Ubuntu) "maverick on ec2 64bit ext4 deadlock (affects: 3) (heat: 28)" [High,Confirmed] https://launchpad.net/bugs/666211
<smoser> and hoping that 651370 is related
<smb> I am looking at that but as said progress is slow
<apw> hallyn, can you tell me what goes wrong with that version number
<smoser> smb, well, jay seems to be responding there, and it seems easily reproducible for him, so maybe we can get to a easy recreate scenario
<jj-afk> hrmm, this one is going to be hard
<smb> dpepends on how complex the backend with the sql-db is
<hallyn> apw: sure, one sec
<smoser> smb, right. 
<smoser> but hoepfully closer at least.
<smoser> bug 613273
<ubot2> Launchpad bug 613273 in linux (Ubuntu) "kernel panic on ec2 in system_call_fastpath (affects: 1) (heat: 37)" [Medium,Confirmed] https://launchpad.net/bugs/613273
<apw> hallyn, i use lpNNNN commonly as a postfix without issues
<smoser> the subject on that is bad, and i'm not sure all my occurences of that should have been considered to be it.
<hallyn> apw: solar flares, crack, or hasty mis-parsing of errors.  in any case, it does work now
<smoser> but we see panics.  you have either of you have any thoughts on that ?
<apw> hallyn, good, it was hurting my head that it might not work
<hallyn> it must have all come down to my malformed email address in the trailer
<hallyn> but i was sure it first complained about version #...
<smb> smoser, I was thinking whether this is still true. cause the last comment was at least a bit older
<hallyn> (guess not)
<smoser> smb, i think i've seen it recently... i'll check logs 2010-09-16 was last comment, so that wasn't to long ago
<smb> jj-afk, knowing the xen code a bit better, would this give some clue to you?
<smb> Sort of all I would see it some interrupt handler failing which is the quite obvious
<smoser> i'll try to attach more console logs for refernece.
<jj-afk> their was something about irqs, I am trying to remember
<jj-afk> I remember futzing with panics on fastpaths before
<smb> jj-afk, The lost irq problem?
<jj-afk> no, I don't think  so
<jj-afk> I think it was machine specific
<jj-afk> ie it would happen on some machines and not others, kind of like the intel_idle
<jj-afk> I need to spend some time digging, and trying to recall
<smoser> i'll try to get all logs i have on that, that will give more info for you to look at.
<smoser> and then will ping jj-afk for some help (follow the bug)
<smb> jj-afk, Agreed, hm. This at least seems to be related with some notify call
<smoser> bug 634487
<ubot2> Launchpad bug 634487 in sun-java6 (Ubuntu) (and 3 other projects) "t1.micro instance hangs when installing sun java (affects: 20) (dups: 1) (heat: 154)" [Undecided,New] https://launchpad.net/bugs/634487
<smb> I think there were at least some useful comments in the bug
<smoser> smb, jj-afk you're more than welcome (encouraged) to keep thinking about this, i'm just trying to get jj-afk back to afk and smb to his evening quicker.
<smoser> smb, right. for the java b ug, there is some help from the amazon engineers.
<smoser> also, the fedora and amazon linux AMIs do not have this issue
<smb> By someone who apparently understands a bit more of the xen memory management than /me
<jj-afk> right this one is weird, we just need to understand it more
<smoser> you think looking at amazon kernel source would be helpful ?
<jj-afk> yes
<smoser> or you think its just likely too different to add much value
<smoser> ok
<jj-afk> configs too
<smoser> well, please try that...
<jj-afk> hehe, yes we will
<smb> jj-afk, you need to show me next week how to do that
<jj-afk> smb: okay
<smoser> jj-afk, launch an ec2 ami from http://aws.amazon.com/amazon-linux-ami/
<jj-afk> right
<smoser> then, there is some command you can run to get source... it will give you a source rpm
<smoser> i forget hwat command , but its in their docs
<jj-afk> yep its just remembering the command :)
<smoser> bug 614853
<ubot2> Launchpad bug 614853 in linux-ec2 (Ubuntu) (and 1 other project) "kernel panic divide error: 0000 [#1] SMP (affects: 2) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/614853
<smb> deja vu?
<smoser> http://aws.amazon.com/ec2/faqs/#Can_I_view_the_source_code_to_the_Amazon_Linux_AMI
<smoser> deja vu indeed
<smoser> bug 586530
<ubot2> Launchpad bug 586530 in linux-ec2 (Ubuntu) "kernel BUG at /build/buildd/linux-ec2-2.6.32/fs/ext4/inode.c:1852! (affects: 1) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/586530
<smb> That seems so old that it could already be resolved
<smb> The upstream bug was never really closed due to the reporter there vanishing
<smb> But since then a huge pile of ext4 updates went into lucid
<smoser> yea... that is what concerned me, is that there seemed a legit upstream bug
<smoser> ok.
<smoser> i think we close that one as incomplete for now
<smb> So we probably should close it with a omment
<smb> yeah, I would do that
<smoser> well, 2.6.32-305-ec2 is kernel version shown
<smb> This was roughly 2.6.32.11 level
<smb> were at .25 nowish
<smoser> ok. i'll trust you know more on this. i've never seen this one... so, incomplete and move on
<smb> bug 660163
<ubot2> Launchpad bug 660163 in linux (Ubuntu) "ec2 kernel hang on XENBUS: Waiting for devices to initialize (affects: 1) (heat: 152)" [Low,New] https://launchpad.net/bugs/660163
<jj-afk> right this one is I believe a lost interrupt
<smb> I am not sure what to say on this one other than strange. ah ok
<smb> might be an explanateion
<smoser> and do we have fix for that?
<smoser> i thought jj-afk had patches or ideas.
<smb> I was wondering whether the dom0 xenbus process could be at fault
<jj-afk> hrmm, there was a patch that went into stable that I thought would help
<jj-afk> smb: possible
<jj-afk> the xen devices are split into front and backend and communicate over the xen bus
<smb> and iirc that correctly that was some user-space process in dom0?
<smb> smoser, how often did you see this?
<jj-afk> hrmm, no I think its kernel
<smoser> i've never seen this one
<smoser> but i do not hit network io hard
<smoser> so can one of you at least try to freshen your memory on that one (reading the links posted) and see if you think it might be reasonable to close at this point as "maybe fixed"
<jj-afk> that is the problem its rare
<smoser> i think maybe i did see it once
<smb> smoser, Oh, I assumed as you reported it
<jj-afk> smoser: yeah, I'll look again since I was chasing it and thought the patch would come in from stable
<smoser> no, if i had reported it it would have kernel version info :)
<smoser> jj-afk, thanks.
<jj-afk> the big problem again is verifying
 * smb wonders whether he looks at the right bug
<jj-afk> smb: XENBUS: ...
<smb> seeing a reported by scott moser and not any links
<smoser> oops
<smoser> i was confusing with https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/648721
<ubot2> Launchpad bug 648721 in linux-ec2 (Ubuntu) "page allocation failure on machines under heavy network load (affects: 1) (heat: 77)" [Undecided,New]
<smb> Oh that one I would say is not a bug
<smb> more of a mis-configuration for much network traffic
<smb> sort of
<smoser> i've only seen the XENBUS once, maybe twice ever , and i think once.
<jj-afk> right that is how I was leaning too
<smoser> hm..
<smoser> so what does that mean ?
<smb> jj-afk, I wonder whether the min_free_pages should be modified for instances a bit
<smoser> user error ?
<jj-afk> basically allocating order 5 is guarenteed to fail at some point
<jj-afk> smb: min free pages can be tweaked but that won't help an order 5 allocation when there isn't 32 contiguous pages
<smb> That is true. 
<smb> Question is why a network thing needs such a huge area
<smb> relatively
<apw> is that for firmware ?
<jj-afk> apw: no, its a nf hook
<smb> apw, no maybe nf
<smb> netfilter
<smb> ?
<jj-afk> yep
<smoser> ok. so one or both of you update that bug please
<smoser> bug 669496
<ubot2> Launchpad bug 669496 in linux (Ubuntu) "natty kernel fails to mount root on ec2 (affects: 1) (heat: 437)" [Critical,Confirmed] https://launchpad.net/bugs/669496
<jj-afk> works
<smoser> ?
<smoser> really ?
<smb> jj-afk, i try to understand it better and then update tomorry (previous bug)
<jj-afk> yep
<smb> for me too
<smoser> ami ?
<smb> at least as described by installing current natty in maverick
<smb> used the first one of the dailies showing up...
<smb> oh actually I wrote it in the bug I think?
<smoser> right, and i tried to reproduce that and it failed for me
<smb> or not?
<jj-afk> smoser: I used the natty kernel on maverick daily last week and smb booted it today
<smoser> i dont come back up at all (using t1.micro though)
<smoser> and its not user space in natty
<smoser> see my most recent comments in that bug
<smb> I used a m1.large
<smb> ami-00877069
<smoser> right. so i did that with t1.micro 3 times this moring and it never came back up.
<smoser> (and no console messages either... our lovely friend for that)
<jj-afk> smoser: okay we will give it another round of testing
<smb> We can trie again with a t1.micro I guess
<jj-afk> yep
<smoser> but look at the console logs
<smoser> the volume gets mounte dread-write
<smoser> and cloud-init even does some work
<smoser> but then bad things happen
<smoser> and kernel remounts ro
<smb> because of io error
<smb> that much is understandable
<smb> but not really why those io errors happen
<smoser> right... so i dont understand how you could suggest that  that is user space or plubming
<smoser> nothing should cause that
<smb> because it booted for me
<smoser> booted once
<smb> and I was tinking of something (like udev) in userspace needing to adapt the size of the blkdev
<smoser> maybe check that natty isn't runing ureadahead.
<smb> as it seems to change from 0 to its actual size somewhere
<smoser> ...
<smoser> but the poitn at which it goes bad is *so* far up in the boot process
<smoser> cloud-init runs at mounted=/ and network up
<smoser> so much is already functional at that point
<smoser> i just would have thought that any udev issues related to the above would have been past
<smb> Lacking the exact details if the init i sort of assumed things went wrong roughly where we pivot over to the real root device
<smoser> yeah... i had thought htat too
<smoser> but its much further up , now seeing the cloud-init messages there.
<smoser> the root device was functional, and lots of things happened before it goes bad
<smoser> hmm... 
<smoser> but then i see
<smoser> "An error occurred while mounting /
<smoser> Press S to skip mounting or M for manual recovery
<smoser> "
<smoser> which i would htink is coming from mountall
<smb> Hm, ok. Sadly we only see half of the picture
<smoser> i'll poke ther e abit also
<smoser> i'll try turning on mountall debug
<smb> It could be also from remounting / rw
<smb> after the fs ckeck step
<smoser> and note, this occurs both on instance store and on ebs
<smb> But press s sounds like mountall
<smoser> which are different devices in the back
<smoser> ok. 
<smoser> well, smb jj-afk thanks for your help. 
<smb> Ok, so I'll poke around ext4 deadlock, the order 5 allocation and the natty kernel on ec2 more tomoorow
<smoser> i'll poke at the natty early next week from the user sapce side.
<smoser> i'll send you all my notes too.
<jj-afk> alright I'm out of here for the weekend
<jj-afk> if there is anything pressing send me a mail it will be checked a few times
<smb> jj-afk, You should formulate that more like tim
<smb> ;-)
<jj-afk> lol
<smb> ogasawara, are you around
<ogasawara> smb: yep
<smb> ogasawara, Just wanted to ask about one sru for maverick (Disable intel_idle). I think we got enough acks for it and it only affects the virtual config.
<smb> I believe Brad and Steve are not around today and tomorrow
<ogasawara> smb: cool.  yah, bjf has been handling Maverick SRU's and tree maintenance
<smb> So just wanted to check with you whether i just can slip it into the tree tomorrow
<ogasawara> smb: I'd be cool with that
<ogasawara> smb: and I'm sure bjf[afk]  wouldn't mind
<smb> And hopefully I won't get into the way of the new process
<ogasawara> smb: ahhh right I forgot about the mew process and possibly reverting patches
<ogasawara> smb: I think sconklin was planning on reverting any unverified patches on Monday
<smb> yes, and we don't know the new process enough ourselves to know how that exactly goes.
<smb> probably I should wait then till monday
<ogasawara> smb: so he actually might not want new patches applied.  I recall him mentioning having a type of merge window for new SRU patches. 
<smb> and write myself an email to make me remember
<ogasawara> smb: probably a good idea if it can wait till Monday
<smb> Depends on whom you ask as always ;) But I would say yes, it is not super urgent
<ogasawara> smb: yah, I've got some Lucid patches I want to apply but am waiting for the green light to push.
<smb> ogasawara, yup, feels safer that way
<smb> ogasawara, I'll be writing reminder mail to all of us. So we all not forget. :)
<ogasawara> smb: sounds good
 * apw suspects that this new process is going to exacerbate the need for a next branch for stuff thats ready for the next sru cycle
<smb> apw, could as well be done by modifying a proposed branch and merge it back
<smb> But that is highly depending on personal taste
<smb> iow, not mine to decide. :-O
<smb> err meant :-P
<smb> bloody o being too close to p
<apw> yeah i suspect a next branch is easier process wise.  as we can automate the 'commited' state on rebasing it ... but hey
 * smb shudders a bit when hearing rebasing
<ogasawara> I really started to like rebasing in Maverick actually, but I think that was more because I was lazy and liked how I could easily edit/drop patches
<apw> smb, only next never master, so ust the pending stuff
<apw> so next is only a parking place for things with acks
<smb> I guess it is really nice when you are the only one mangling the tree. It feels (just a feeling) a bit dirty for a released tree as it looses the info about what happened
<smb> apw, Oh, ok. Sounds much better
 * smb relaxes
<smb> ogasawara, rebasing is a bit like teleporting trees. You are there now but you have no idea how you get there.
<bjf> smb, it's still not clear to me how the process will work (i have a batch of upstream stable sitting in my personal repo ready to push), i think after monday's revert run we should be able to get your intel idle in
<smb> apw, Reminds me, you see any potter fans queuing up to your place? :) I beleive it was today
<apw> right, and only the pending patches which are currently not even seen as they are not anywhere
<apw> smb heh not as yet
<bjf> smb, I can add the idle patch to my tree as well if that would help
<smb> bjf, Sounds cool. If you don't mind i just send that nag mail anyway. Given the state of post-uds memory of mine I forget what I was thinking till then
<godber> Anyone have a recommendation for how to isolate this problem? VV
<godber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/659422
<ubot2> Launchpad bug 659422 in linux (Ubuntu) "Boot failure after upgrading kernel to 2.6.32-25-generic (affects: 4) (heat: 133)" [Undecided,New]
<apw> gober idid you get that reproducible again ?
<godber> absolutely
<godber> I went back and made sure I started fresh on 10.04.1
<godber> (I had accidentally started with an old lucid alpha iso)
<godber> booting off the latest generic kernel fails
<godber> generic-pae does not
<godber> as I noted udevadm segfaults about half the time I run it when in the initramfs console
<smb> fwiw, I did a i386 generic install just yesterday and got a booted 2.6.32-25-generic
<godber> I compared the initramfses between the two versions and they match ... all but the kmodules of course
<godber> on VMware ESX 4.1?
<smb> no native
<godber> works fine native
<godber> AFAIK
<smb> hm, something stepping on the toes of vmware...?
<godber> _shrug_ I guess
<godber> it also does not happen on VMware ESX 4.0
<godber> I had thought of two possible ways for me to narrow it down
<godber> I had considered either rebuilding the kernel eliminating the new patches one by one
<godber> or, comparing the configuration differences between the generic and generic-pae kernels
<apw> gober that'd be a bisect
<godber> apw, thanks, I am somewhat new at this level
<godber> is there a handy way to do that?
<apw> git bisect does the trick
<godber> ok, thanks
<godber> is there like a candidate kernel for the next release in a PPA somewhere I can try?
 * cking yawns
<apw> ts
<smb> godber, There is http://launchpad.net/~kernel.ppa
<smb> err kernel-ppa
<smb> but that is the same release. There is also the mainline kernels
<smb> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<godber> If I get this isolated down to a specific patch, whats the odds of getting the attention of someone who knows how to fix it?
 * ogasawara lunch
<rlpb> Any help on getting a panic backtrace out of Ubuntu please? I've tried CrashdumpRecipe but can't seem to get the machine to reboot after panic. I've tried sysctl -w kernel.panic=15 but that didn't seem to work
<camden> hi folks
<camden> I'm interested in trying out a kernel with the bfs patches, found at http://ck.kolivas.org/patches/bfs/
<camden> I'm having some trouble, in that I can't seem to get the patches to apply, I think because the minor version is different. is this something that someone around here has worked on?
<camden> nobody?
#ubuntu-kernel 2010-11-12
<achiang> camden: i've never tried applying them myself, but my impression is that con develops against upstream linux, not the ubuntu tree
<camden> this is my impression as well
<camden> I may have had some success
<camden> we will see when my compilation is done.
<godber> Anyone have time for, what I hope is, a quick newbie question?
<achiang> godber: just ask. someone may see the question later and have a response
<godber> just want to know how to build for x86 when on amd64
<godber> https://help.ubuntu.com/community/Kernel/Compile
<godber> according to those instructions ^^
<godber> does running
<godber> debian/scripts/misc/oldconfig ARCH
<godber> somehow make the build be for that architecture?
<achiang> godber: i'm confused. what is it you are trying to do? build a 32 bit kernel or a 64 bit kernel? it sounds like you have a 64 bit host, is that right?
<godber> yes, 64bit host
<godber> want a 32bit kernel
<achiang> godber: i'm not familiar with the Ubuntu way. but the upstream way is to say: linux32 make
<godber> ok
<achiang> godber: so, you might want to experiment with: linux32 debian/scripts/misc/oldconfig x86
<godber> yeah, I am trying that right now ... will let you know, thanks
<godber> except of course oldconfig doesnt exist
<godber> theres kernelconfig
<achiang> godber: did you run debian/rules updateconfigs ?
<godber> oh, I thought those were alternatives
<godber> will try
<achiang> godber: and probably, what you want would be: linux32 debian/rules updateconfigs
<achiang> godber: but i'm just guessing.
<godber> k
<godber> actually looking at the kernelconfig script, it looks like it might do the same thing
<achiang> godber: should i ask why you think you want to do this? or should i be afraid? :)
<godber> well, I have been questioning the wisdom of my actions all day
<godber> since I put the odds of success low
<godber> but I was going to try and identify which patch causes 
<godber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/659422
<ubot2> Launchpad bug 659422 in linux (Ubuntu) "Boot failure after upgrading kernel to 2.6.32-25-generic (affects: 4) (heat: 133)" [Undecided,New]
<camden> alright, kernel done. wish me luck
<achiang> godber: yuck.
<achiang> godber: i assume you're doing a git bisection run, and not a manual one?
<godber> agreed, but until I can convince someone to care, I am out of luck
<godber> that was the plan
<godber> I thought the exercise would be worth it ... at least up until a point
<godber> then I accidentally spent the last hour building the wrong arch :)
<godber> I think its been at least ten years since I built a kernel, things have changed
<achiang> godber: i don't think you need to run updateconfigs
<achiang> or even kernelconfig, really
<godber> hmm, I am trying to get as close to the Ubuntu way as I can
<achiang> godber: right, but you really only need to run that script if you've updated the Kconfig, which it doesn't sound like you're trying to do
<godber> true, though ...
 * achiang is grabbing the lucid tree to poke around a bit
<godber> oh, you don't have to bother, I am gonna have to split soon
<godber> I appreciate your help though
<godber> I am gonna have to pickt this pack up in the morning
<achiang> do you know the kernel revisions between .32-24-generic and .32-25-generic?
<achiang> well, that's easy enough to find, actually
<godber> no, I thought I could use the git tags
<achiang> right, you can
<achiang> i found them
<godber> and the bisect good/bad stuff
<godber> really, I am on step one ... which is "Create an identical kernel to the one that fails"
<godber> at least I am building on an 8core ec2 instance now, instead of my laptop
<godber> it really seems to me that the arch should be an argument here
<godber> DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic
<jj-afk> godber: you have picked a bad day, most of us are away, /me included :)
<jj-afk> https://wiki.ubuntu.com/Kernel/Dev
<jj-afk> contains all the docs on how we build kernels etc
<godber> yeah, I have been digging around in some of those
<jj-afk> generally, you can just git bisect, and remove debian/stamps-build*
<jj-afk> and then build using fakeroot debian/rules binary-generic
<achiang> jj-afk: the challenge is building i386 on an x86_64 host
<jj-afk> you just need to setup up and i386 chroot and use schroot
<achiang> ew, there's no way to use linux32 somehow?
<rlpb> any ideas about getting a crash dump when I can't get the kernel to reboot after panic (if that's the cause)?
<jj-afk> achiang: you can but the packaging depends on other bits, so it gets messy fast
<godber> achiang, its building a whole deb package, so the chroot needs to match the arch
<godber> I see
<jj-afk> if I am just building kernels I can do it, but packaging up a deb, I just use the chroot
<jj-afk> there is a script to set them up for you its pretty painless
<achiang> jj-afk: got it.
<godber> https://wiki.ubuntu.com/KernelTeam/BuildKernelWithChroot
<achiang> godber: ok, sounds like you know the steps then, good luck. :)
<godber> ok ... yeah, brilliant
<godber> now I know where to start tomorrow
<godber> thanks guys
<achiang> godber: http://pastebin.ubuntu.com/530367/
<achiang> fortunately, you probably don't have to iterate very many times, since you've isolated your issue to -24 and -25
<godber> oh, yeah, good, thanks
<godber> thanks again guys, bywe
<Maahes> I could use some advice, my touchpad won't come back after suspend. I've tried reloading psmouse (the only module I've found running prior), I've tried loading synaptics(_i2c) but it says the modules don't exit (but zsh autocompletes them for me) the touchpad is no longer in /proc/bus/input/devices but tpconfig sees that's there, but cannot get information from it.
<Maahes> Additionally, I tried binding XF86TouchpadToggle to Ctrl+shift+t, but it says there's an error, no output to any error log though, additionally manually clicking and unclicking the gconf setting for touchpad_enabled does nothing as well
<TeTeT> What are the plans for the .26 kernel in lucid-proposed? When will it be moved to lucid-updates?
<smb> TeTeT, I believe that one too will be subject to exercise the new revert patches if not tested process, which Steve wants to have a go on Monday. From then on it depends a bit on the decision of waiting for regression testing or not. I would ask him on Monday
<TeTeT> smb: so the screen resolution on Esprimo E patch would be safe as I've spent quite some time testing it?
<smb> If you mention/report this in the bug report, yes. That should be ok
<TeTeT> smb: was done, the tag verification_done was added too
<smb> TeTeT, Then I would say you are good/safe
<smb> (As long as the scripting goes right of course, but I am pretty sure they double/triple check on that :))
<TeTeT> smb: does this mean after removing the untested patches, the kernel will be published in -updates right away, or does it stay in proposed for another week?
<smb> TeTeT, The target for the future will be a re-upload with untested things reverted. Then another week for qa regression testing. I don't think we are quite there, but I would think that this at least will be kept for another week in proposed to have some baking time.
<TeTeT> smb: sounds reasonable
<smb> TeTeT, Mind that I am not authoritative there anymore. Last words would be Steve (or Martin). Just most of the US might be on swap days after the holiday yesterday.
<smb> (Martin not being affected there, of course)
 * smb waves to cking 
 * cking waves back
<smb> cking, cannot hear
 * smb got a feeling there is an apw hiding somewhere
<apw> smb, now what makes you think that
<smb> apw, Some Andy sends out mail. :)
<apw> damn i should have thought of that 
<smb> :) morning anyway
<apw> morning
<diwic> bug #640254
<ubot2> Launchpad bug 640254 in linux (Ubuntu Maverick) (and 1 other project) "[Dell Inspiron M101z] Internal speakers does not function in Ubuntu after booting into Win7 once (affects: 1) (heat: 64)" [Undecided,Fix committed] https://launchpad.net/bugs/640254
<diwic> Can somebody tell me how this stuff is supposed to work with the new throw-your-patches-out policy?
<diwic> First it was accepted to pre-stable
<diwic> Then it came from upstream
<diwic> neither seems to be enough to avoid the throw-patches-out 
<diwic> I thought we would keep whatever came from upstream.
<diwic> upstream stable, that is.
<smb> diwic, I would hope that upstream stable takes precedence
<smb> but that might be a special case the scripts to come need to handle
<smb> You may want to talk to Brad and/or Steve on Monday about that
 * diwic does NOT like the new policy.
 * smb is not the one to complain about it ;-P
<diwic> smb, assuming people do what they should and send things to upstream stable, that is the common case rather than a special case
<smb> right, and I think that you would get the benefit of not getting reverted in that case
<smb> Though it does not really matter what I think
<apw> diwic, things coming down from upstream stable are meant to be immune to the validation failure mode
<apw> so if its being thrown out coming down from there there is something wrong
<smb> Just make sure that people writing scripts are aware, too
<diwic> apw, so if you look at the bug you would agree with me that the threat comment by sconklin (or his bot) is wrong in this case?
<apw> diwic, if it came from stable it is a bug yes.  he is probabally assuming all patches with BugLink are not from stable
<smb> It could just be a matter of updating the bot not to send a threat when there is a buglink to a stable tracking bug in the same patch as well as being the only one
<smb> There is this thing about programs written by humans not always being bulletproof
<diwic> yeah.
<apw> yeah.  diwic just make sure you bitch at them in email to say you don't think this bug is one that should be on the drop list
 * apw notes we are down to just two now
<diwic> apw, just two what?
<apw> oh ... heh ... /me notes we are down to just two patches dropped from Maverick to Natty which I do not either know should be dropped or have replacements for
<diwic> apw, so, now I have bitched.
<apw> diwic, hehe good man
<diwic> apw, now that I got your attention, how do I review my personal patches for upstreaming and update?
<apw> that work item is about looking at the ones we are carrying in your name and deciding whether they should be upstream
<apw> if they should not then let me know and i will mark them so that i don't ask you again
<apw> if they should be, its a reminder to push them along up there
<diwic> apw, and how do I know which ones we are carrying in my name?
<apw> ahh they are listed on https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyUbuntuDeltaReview search for your name
<diwic> apw, ok, only one and that one should be dropped. Someone else tried to upstream it, I think it got rejected.
<apw> ok if you edit the Spec there and add a * this should be dropped (diwic) under them, then i'll drop them as i go
<apw> then you can close your work-item :)
<diwic> apw, thanks
<lag> apw, smb: https://patchwork.kernel.org/patch/249861/
<kraut> howdy, anyone an idea what's going wrong here? http://pastebin.com/sBp8d3ag
<kraut> the problem happens on a via esther, is there any issue with the cpu scalling?
<kraut> it's reproducable when heavy disk i/o happens
#ubuntu-kernel 2010-11-13
<opaquish> hello ppl
<opaquish> anybody out there?
<opaquish> no chit chat seems to go on in the room
<opaquish> queer
<maco> it's not a chat channel
<maco> plus, it's a weekend
<maco> *and* the middle of the night in the US and oh-god-early in europe
<opaquish> :)
<opaquish> i am new here
<maco> woah its nearly 4am...
<maco> and you're interested helping out with kernel...stuff?
<opaquish> i have a few questions in my mind, but i don't know how to get attention of somebody that can answer
<maco> step one would be to ask during business hours
<maco> if its something only a kernel engineer can answer
<opaquish> no i think everyone in this room can answer
<maco> (most of the kernel team does it as their job-job)
<opaquish> interesting 
<opaquish> so are you interested in my questions, or are you enough telling me about kernel team
<opaquish> (which i apreciate)
<maco> sure, ask
<opaquish> i am running maverick
<opaquish> and need a low latency or rt kernel
<opaquish> for recording audio
<opaquish> can i use an rt kernel of lucid for example?
<maco> there's a chance of it working
<maco> but there's also a chance of various other things getting wonky
<maco> so, give it a try and see how it is?
<opaquish> or maybe i should install ubuntu studio lucid , i just installed a fresh maverick (didn't update yet)
<opaquish> which way would you advice?
<maco> ubuntu studio lucid
<maco> plus, its long term support
<opaquish> what do i miss by downgrading? (it sounds bad)
<opaquish> (how noob does it seem:)
<maco> umm...some indicator menus...and ability to pay for stuff in software center
<opaquish> downgraded! thanks for advice
<opaquish> cust curious where were you?
<maco> dc
<opaquish> good night to dc then! 
<opaquish> thx again see you
<happyaron> Hi, I have a problem with natty kernel, that is I have audio ouput working, but input not working. This problem didn't exist with 2.6.36 kernel. Here is my alsa-info.sh output: http://paste.ubuntu.com/531296/
<happyaron> filed bug 674952, thanks
<ubot2> Launchpad bug 674952 in linux (Ubuntu) "natty kernel doesn't work with voice input by microphone (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/674952
#ubuntu-kernel 2010-11-14
<aegis> Hey all, is there a working kernel I can install that will allow Ubuntu to start?
<aegis> The latest upgrades caused my system to fail... It's specifically a problem with grub-pc, lvm2, and I believe udev
<aegis> Also, does anyone know why my system always wants to upgrade to a pae version of the kernel when I am only using 1 GB of RAM in a 32 bit system?
<rsalveti> bjf[afk]: just to understand better, any reason why 2.6.35-23.37 is still not in proposed? at least I can't find it at omap
<bjf[afk]> rsalveti, omap3 or omap4 ?
<rsalveti> bjf[afk]: omap 3
<rsalveti> I saw that it did build fine for arm, but still can't find at proposed
<bjf[afk]> rsalveti, https://launchpad.net/ubuntu/+source/linux/2.6.35-23.37/+build/2033772
<rsalveti> yup, shouldn't it be at the proposed repo already?
<rsalveti> or do we need someone to approve it first?
<bjf[afk]> should be, where are you looking?
<rsalveti> I tried to find it by activating http://ports.ubuntu.com/ubuntu-ports maverick-proposed
<rsalveti> then I went to the http address and can't find it there
<rsalveti> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.35-23-omap_2.6.35-23.37_armel.deb
<rsalveti> hm, it's here, why I can't find it with apt
<bjf[afk]> rsalveti, after you added it, did you "apt-get update"?
<rsalveti> yup, can't find it
<rsalveti> http://paste.ubuntu.com/531536/
<rsalveti> I got many updates from different packages, but not for the kernel
<bjf[afk]> rsalveti, not sure what to tell you at this point, you could try #ubuntu-release but i'm afraid since it's the weekend your not likely to find any help
<rsalveti> yeah, np, will ping them later then
<rsalveti> thanks anyway :-)
<rsalveti> then what are the following steps to move it from proposed to main/
<rsalveti> ?
<rsalveti> bjf[afk]: oh, ok, the package is there but the meta-package is not requesting it yet
<rsalveti> it's still depending on the 23.35
<rsalveti> that's why apt-get upgrade doesn't pull it by default
<rsalveti> no, it seems to be fine
<rsalveti> argh
<rsalveti> apt-get install linux-image-omap gets the correct kernel, but apt-get upgrade doesn't
<rsalveti> nevermind, after another apt-get update I now can find everything it needs and apt-get upgrade gets it fine
<rsalveti> weird
<kaushal> Hi
<kaushal> what exact information i need to look into the reason behind kernel panic
<kaushal> I have encountered Kernel Panic umpteen number of times
<kaushal> whats the best way to handle it
<hyperair> netconsole
<hyperair> or a serial cable
<kaushal> hyperair: Are you referring to me ?
<hyperair> yeah i guess i am
<kaushal> ok
<kaushal> not sure i understand about your answer though
<kaushal> hyperair: understood now
<hyperair> =)
<kaushal> Also why kernel panic occurs
<kaushal> How do we fix them
<hyperair> i'm sure you've seen a segfault before, right?
<hyperair> a kernel panic happens when the kernel segfaults =p
<kaushal> segfault occurs due to bad RAM ?
<hyperair> programming errors.
<hyperair> bugs
<hyperair> but yeah i figure bad RAM can cause it too..
<hyperair> anyway use netconsole and get a backtrace, and then file a bug
<hyperair> that's the best way to handle a panic.
<kaushal> hyperair: thanks
<kaushal> file a bug ?
<hyperair> yes.
<kaushal> is it on launchpad ?
<hyperair> file a bug.
<hyperair> yeah.
<kaushal> so backtrace means the kernel messages ?
<hyperair> bugs.launchpad.net/ubuntu/+source/linux
<hyperair> i think.
<hyperair> you want something that looks like a series of function calls
<hyperair> something that says Call Trace:
<hyperair> followed by a bunch of lines that looks like this:
<hyperair> [<ffffffff8167411d>] schedule_timeout+0x20d/0x310
<hyperair> well similar to it anyway
<kaushal> hyperair: Are there Ubuntu Specific documentation for Understand Kernel ?
<hyperair> nope.
<hyperair> wait, yes there is
<hyperair> at wiki.ubuntu.com
<hyperair> but i forgot where
<hyperair> you'll have to poke around a bit.
<hyperair> there's something in the title of this channel
<kaushal> Hi
<kaushal> I would like to contribute to the Ubuntu Kernel Team
<kaushal> How do i start with
<m4t> hey, does ubuntu's kernel build use special LD_FLAGS versus stock vanilla kernel.org 'make'?
#ubuntu-kernel 2011-11-07
<ppisati> morning
<cking> yawn
 * apw yawns
<lilstevie> cmorning
<lilstevie> -c
<Q-FUNK> in Oneiric, I regularly get notices from various CLI and GNOME apps that memory forking failed. I have never seen this until now. What causes this? To answer an obvious question, I indeed have a (large enough) swap partition.
<apw> Q-FUNK, what is the exact text of the message
<apw> as memory forking really doesn't make any sense
<Q-FUNK> fork epÃ¤onnistui: Muistin varaaminen ei onnistu
<Q-FUNK> (fork failed: memory allocation failed)
<Q-FUNK> that's from CLI
<Q-FUNK> I see a similar message from gnome-shell whenever starting GUI apps from it, too.
<apw> ok so some memory pool or other was depleted at the time of the fork.  this may not be a general pool of course
<apw> was there anything notable at the bottom of the dmesg at the same time
<Q-FUNK> nothing malloc related.
<Q-FUNK> in fact, the newest dmesg entry is from about 30 minutes ago and not memory related at all.
<apw> a tricky one then, as ENOMEM has any number of actual meanings not all even related to memory (such are the vaguaries of error codes)
<apw> is this 32 or 64 bit
<apw> it isn't a general issue for everyone as none of my oneiric installs are seeing it
<Q-FUNK> 32-bit.  686 centrino
<Q-FUNK> it could be that my swap partition has gone awry but since nobody ever got around inveting any fsck.swap, I wouldn't know.
<apw> swap is empty once you reboot, it isn't persistant
<apw> (deemed empty)
<apw> but you might check it is actually activated
<Q-FUNK> that says nothing about the sanity of the blocks within the swap partition.
<apw> define sanity, the kernel should never assume the contents of any of them after reboot
<Q-FUNK> Swap:          494        494          0
<Q-FUNK> well, does the kernel at least perform a badblock check on it at reboot?
<apw> nope, no bad block scans.  modern drives are assumed to remap blocks
<apw> you should however get errors in dmesg for disk realted failure
<Q-FUNK> ok
<apw> is the failure persistant or transient
<Q-FUNK> random.  mostly seems to happen whenever firefox has run into too many broke javascripts and started utilizing more than 60% of available memory.
<apw> and you don't have to do anything for the next attempt to be successful ?
<Q-FUNK> which attempt?
<Q-FUNK> at doing what?
<apw> you do "something" and it fails, you do "something" again and it works?
<lilstevie> running what ever throws the error message
<apw> or you do "something" and it fails, you take a machette to various programs, and you do "something" and it works
<Q-FUNK> it doesn't work again until I have Quit Firefox, let it close itself down and reached 0% of resource consumptions.
<Q-FUNK> then, other applications are able to malloc again.
<apw> so it could genuinly be an issue with firefox then
<apw> could we sub in say chromium for a few days to see if that is immune
<Q-FUNK> possibly.  then again, I wonder why the kernel would let firefox consume all the resources to the point of also filling the swap.
<apw> why would the kernel not let you fill up all your resources with things you are running
<apw> if you overcommit all of ram and all of swap on your system, it cannot do anything to help you
<apw> how much swap do you even have
<Q-FUNK> it can TERM the offending app.
<apw> in a serious memory crunch it would, but it takes the simpler
<apw> and safer course and prevents you asking for more in your fork
<apw> at least that way you get to chose which apps are surplus and kill those cleanly
<apw> instead of them going pop and you getting annoyed cause it loses something
<Q-FUNK> grsec was very good at this. if an app requests an insane amount of RAM, it would sigterm it.  if that didn't do the trick, it would sigkill it.
<apw> that this is new, that it "only" happens with firefox, and exiting firefox restores the world tends to lean to a problem with firefox leaking memory
<Q-FUNK> well, the thing is that a normal user wouldn't know what those messages mean or how to debug it.  here, I happen to know about 'ps' and 'top' enough to notice, but even then.
<lilstevie> but in your case it really isn't requesting an insane amount of ram, it is taking it over time :)
<apw> and they would not be able to cope with apps dieing at random when they got big either
<lilstevie> apw: my thoughts exactly
<apw> that your machine wasn't too small on natty and is on oneiric it says there is a bug somewhere
<apw> that exiting firefox helps means its less likely to be a kernel memory leak
<apw> as those tend to just persist across exiting the app
<apw> so i'd start by blaming firefox, and try and prove that is to blame
<apw> subbing in an equivalent app temporarily should tell us something i'd hope
<Q-FUNK> it probably is.  firefox has never been a well-behaved app.
<apw> they would be very interested to know if they are broken though
<apw> they are pretty popular
<lilstevie> judging from what you said about it being after running too many broken javascripts, it is most likely in the javascript parser
<apw> yeah, or indeed if the apparent brokenness of those is a side effect
<lilstevie> yeah
<Q-FUNK> well, I simply notice that after firefox has popped too many alerts about runaway scripts, asking me if I want to intereupt them, its memory consuption goes to absurd extremes.
<Q-FUNK> it apparently doesn't know about freeing the memory after stopping those runaway scripts.
<lilstevie> so that could be part of the effect not the cause
<apw> Q-FUNK, are these alerts new or more frequent since the upgrade
<Q-FUNK> apw: they started happening since oneiric.
<apw> so lets start with a bug against firefox
<Q-FUNK> before that, the kernel never had any problem offering more memory to new applications, even though it sometimes resulted in furious drive spins because of heaving swaping.
<Q-FUNK> i wonder if we could make apparmor TERM firefox gently when it exceeds a certain amount of memory usage, though.
<lifeless> Q-FUNK: that would rather stop it being usable
<lifeless> Q-FUNK: its not exactly svelt
<apw> i personally would rather find new thing stopped, than existing things just dissappeared when i wasn't looking
<apw> the user experience is very poor if firefox just goes pop
<Q-FUNK> it becomes unusuable after it exceeds a certain amount of memory usage anyhow. it becomes as slow as molasses.
<apw> yes and you can click remember this specific page and the like, read whats there, make a decision to close it
<lifeless> Q-FUNK: mine is up at 3G, still responsive
<apw> either way its sick and needs a bug
<Q-FUNK> right, except that stoping new apps doesn't tell anything useful to the user as to why new apps cannot be launched.
<apw> 3G for firefox, wtf
<apw> and it dissappearing is better.  neither is good
<lifeless> apw: yes, which is lean compared to chromium :)(
<apw> and it is clearly broken papering over it isn't appropriate
<Q-FUNK> I cannot use chromium. its resource consumption has become even worse than FF3 used to be.
<apw> well then even more of a reason to file a bug on it
<Q-FUNK> FF4 and newer eventually became slightly better at resource consumptions, but the handling of broken content is still dumb.  it expects users to add items to an ever-growing blacklist, rather than have a sane policy of killing faulty content after a while and asking the user whether we should attempt to re-load.
<Q-FUNK> I've already suggested changing that model to upstream.  never got any response.
<lilstevie> browsers have been pretty bad lately
<apw> feature creap
<Q-FUNK> instead of waiting for content to go awry and request 100% of availble resource and then try to allocate more resources for a pop-up asking the user whether it should kill the bad content,
<Q-FUNK> I suggested that it should promptly kill misbehaved content and then notify the user that this happened, offering to reload.
<lilstevie> my uptime is pretty low at the moment cause I just rebooted, and chrome is already using 490MB ram on 8 tabs
<Q-FUNK> lilstevie: I'm not surprised. here, I keep chromium as a backup, in case firefox really becomes unusable, so that I at least have something to access online banking, but even then, I'm not putting my hopes too high.
<Q-FUNK> mind you, I wouldn't entirely put the blame on browsers (at least not for recent firefox).  rather, the issue is all those sites with real-time content refresh and tons of javascript.
<Q-FUNK> by the time you have 20 tabs, each trying to refresh the number of Facebook Likes for that page and the number of backtracks on every syndicated blog, in real-time, even the new and improved firefox slows to a crawl in no time.
<lilstevie> heh I don't do that stuff
<lilstevie> I have 2 self updating pages
<lilstevie> uni email, and my domains webmail, powered by gmail
<ppisati> herton: O/ti-omap4 3.0.0.-1206-11 has been superseded by 3.0.0-1207-12, so according to the new workflow i should mark as "duplicate" the old tracking bug
<ppisati> herton: but does it apply even if 1206-11 is already in -proposed?
<herton> ppisati: yes, we will just build the new package to replace the old one in -proposed
<ppisati> ok
<njin> Hallo, what do you blame linux or xorg ? bug 881830 thanks
<ubot2> Launchpad bug 881830 in linux "Track pad does not respond properly" [Undecided,Confirmed] https://launchpad.net/bugs/881830
<apw> njin, hard to say, likely as its an apple product its something stupidly complex and undocumented
<apw> you may be able to tell using input-events on the appropriate input channel
<apw> if you see the 'wrong' clicks etc there then its kernel side
<apw> but being an apple touchpad, we may well not be able to do anything
<apw> njin, also do we know why they are running a random upstream kernel?
<njin> apw, thanks is an ubuntu member using the macbook
 * ogasawara back in 20
<herton> ppisati: still around?
<ppisati> herton: yep
<herton> ppisati: I was looking at the ti-omap4 (oneiric), does it need an abi bump on the new rebase?
<herton> ppisati: on the latest rebase you did, from 1206.11 to 1207.12
<herton> ppisati: as there was only the rebase, and the master oneiric tree didn't bump the abi from 13.21 to 13.22, I was expecting the ti-omap4 to not bump as well
<apw> -       $(kmake) O=$(hdrdir) -j1 silentoldconfig prepare scripts
<apw> +       $(kmake) HOSTCC=$(CROSS_COMPILE)gcc KBUILD_SCRIPTROOT=$(kbsr) O=$(hdrdir) -j1 silentoldconfig prepare scripts
<ppisati> herton: but it goes from Ubuntu-3.0.0-13.20 to -22 in my case
<ppisati> herton: the rebase i mean
<herton> ppisati: well, I see it here only as a rebase between 13.21 to 13.22 (12.20 was the previous from these two): http://pastebin.ubuntu.com/731144/
<herton> ppisati: do you get a abi mismatch or some like that while building after the rebase?
<herton> (the diff from pastebin is the differences between origin/ti-omap4 and your ppisati ti-omap4 with commits removed so the diff is easier spotted)
<ppisati> herton: wait
<smoser> smb`, you have any thoughts on a target for having bug 881076 fixed ?
<ubot2> Launchpad bug 881076 in linux "precise kernels do not boot on ec2" [High,Triaged] https://launchpad.net/bugs/881076
 * tgardner -> lunch
<ppisati> herton: should be fixed now
<herton> ppisati: thanks, will check and push
 * ppisati -> bails out
<jsalisbury> bjf, sconklin, herton regression in Lucid, that has a possible commit identified that caused the issue: bug 875300
<ubot2> Launchpad bug 875300 in linux "[Realtek ALC268] ALSA test tone not correctly played back (regression in lucid from 2.6.32-33.72)" [Medium,Triaged] https://launchpad.net/bugs/875300
<herton> jsalisbury: ack, we will check that
<jsalisbury> herton, thanks
<jdstrand> tgardner: hey. your --reap patch to iptables pretty much has to be reworked for iptables 1.4.12
<tgardner> jdstrand, um, how so ?
<jdstrand> tgardner: upstream made quite a few changes. I'd like to do the merge, but don't want to rewrite your patch. I'm wondering how to proceed-- perhaps I could do the merge and back out the --reap change, and then file a bug for that functional regression and assign it to you?
<tgardner> jdstrand, you mean the user space portion? I thought that got accepted upstream.
<jdstrand> tgardner: they redid the struct and the arg parsing, etc
<jdstrand> tgardner: (yes the userspace bits) no it didn't. we've been carrying this delta for a long time
<tgardner> jdstrand, huh. ok, I'll see about getting the patch redone and accepted upstream
<jdstrand> tgardner: sounds great. looks like openwrt picked it up (noticed in my google search)
<jdstrand> so hopefully upstream will be willing
<jdstrand> I'll back it out for now and assign a new bug to you
<tgardner> jdstrand, ok, thanks for the note
<cnd> tgardner, ogasawara: I tested hid-ntrig in oneiric vs the latest daily mainline
<cnd> I motion for reverting all our patches and just going with upstream
<ogasawara> cnd: Ooo, nice
<tgardner> cnd, in oneiric or precise ?
<tgardner> or both
<cnd> tgardner, in precise
<cnd> I don't want to mess with oneiric
<tgardner> cnd, works for me.
<cnd> though I'll be requesting a hardware ID addition soon
<cnd> however, I don't know how to send patches for this
<tgardner> cnd, that is a deeply curious statement
<cnd> sorry, I need to be more clear
<cnd> I know how to send a patch for the new ID that needs to go into an oneiric SRU
<cnd> I don't know how to fix up precise
<cnd> the git log in precise for drivers/hid/hid-ntrig.c does not show the upstream commits at all
<cnd> I expected to see upstream, then a bunch of upstream reverts until our commits applied cleanly, then our commits
<cnd> but I only see upstream up to 7b2a64c96ad53c4299f7e6ddf8c2f99cb48940a9
<tgardner> cnd, are you assuming we've been following the merge window? we generally don't until -rc1
<cnd> then sauce patches
<cnd> tgardner, there's been no change to ntrig during this merge window
<tgardner> cnd, huh, you should consult with ogasawara I guess
 * tgardner ducks out for a moment
<cnd> if I had to take a stab, I would send a pull request which included ~10 sauce patch reversions and then another ~10 upstream patches that we don't have
<ogasawara> cnd: this is what I see --> http://pastebin.ubuntu.com/731333/
<ogasawara> cnd: so I assuming you're saying we can drop the first 10?
<ogasawara> ie revert the following:
<ogasawara> 961ed450b0e8019a615774712b05db18e36bbea7 UBUNTU: SAUCE: HID: ntrig: fix suspend/resume on recent m
<ogasawara> 712ad9598cb31639546faa2b57311bc32145a978 UBUNTU: SAUCE: HID: hid-ntrig: add support for 1b96:0006 
<ogasawara> b624fabc45a8b9bd42af2f066ce52934d44df028 hid: ntrig: Mask pen switch events
<ogasawara> f5180d5875606b3e4fd68be65373326e60c835b6 hid: ntrig: Support single-touch devices
<ogasawara> 11238108398464f35574fec4e0360d6cce32a742 UBUNTU: SAUCE: hid: ntrig: New ghost-filtering event logi
<ogasawara> b0613584b5f5c2c393ba46fcab5ea073f15cef95 UBUNTU: SAUCE: hid: ntrig: Setup input filtering manually
<ogasawara> 25826a386b28c76aa9580b05d5c75f5ade02f781 UBUNTU: SAUCE: hid: ntrig: remove sysfs nodes
<ogasawara> 489814f46a3c69da2109a076a81620aeb476b927 UBUNTU: SAUCE: hid: ntrig: zero-initialize ntrig struct
<ogasawara> 4fff4d1f822e3dc85942598cbe2727f1bdb271bb UBUNTU: SAUCE: hid: ntrig: Correct logic for quirks
<ogasawara> 5dc230ad38578ceb9d88218eb6507bf0b858dab6 UBUNTU: SAUCE: hid: ntrig: Remove unused device ids
<cnd> ogasawara, yep
<cnd> ogasawara, and then pull in all the latest upstream changes
<cnd> oh wait
<cnd> I guess they all are in the tree
<ogasawara> cnd: right, there's no additional changes upstream we'd need to pull in
<cnd> yeah
<cnd> so reverting those commits is all that needs to happen
<cnd> somewhere in those commits there must be a large amount of changes that are nothing but reversions of previous upstream commits :)
<ogasawara> cnd: cool.  how about I build you a quick test kernel with the 10 commits reverted just confirm before I actually drop them.
<cnd> ogasawara, sure
<jjohansen> apw: you still around
<ogasawara> cnd: test kernel -> http://people.canonical.com/~ogasawara/ntrig/
<cnd> ogasawara, thanks!
<cnd> ogasawara, kernel looks good
<cnd> is there anything else you need me to do?
<cnd> I can send a pull request for the revert if you like
<cosmosis> I am installing ubuntu 11.10 on a brand new system.  8 core AMD FX-8150 CPU with a ASUS M5A97 -- AMD 970 motherboard and 16 gig of ram.   When I go to install I get as far as  864 and detecting the usb keyboard and then it just hangs.  Any ideas?
<holstein> cosmosis: unplug the keyboard
<cosmosis> ok will give it a shot
<cosmosis> now its getting hung after 5.36 detecting the sr0 device (cd drive)
<cosmosis> its not locked its just sitting there sort of..
<cosmosis> but its not proceeding with install
<holstein> i would probably just start testing the hardware to make sure
<holstein> you can try #ubuntu and/or #ubuntu-beginners as well... this is not really a support channel
<cosmosis> ok sorry its just I tried the ubuntu-installer channel and they said ask the kernel guys
<ogasawara> cnd: no need to do anything else.  I'll just add a note to the commits that they were dropped per our delta review.
<cnd> ogasawara, great
<cnd> ta
#ubuntu-kernel 2011-11-08
<mfilipe> how do I do to get .config of oneiric kernel?
<mfilipe> my kernel is 32bits-pae 
<Sarvatt> mfilipe: /boot/config-3.0.0-whatever-generic
<mfilipe> Sarvatt, thanks a lot! :)
<Sarvatt> replace whatever with a number of course, dont know what kernel you're using :)
<mfilipe> Sarvatt, default... 3.0.0. I found the config
<mfilipe> ;)
 * smb yawns
<TeTeT> a customer reports random freezes on x220 (sandybridge) with 10.04 and lowell and natty-backports-lts kernel. Is there any magic sysreq thing I can ask them to run to gather useful info from the crashed systems?
<smb> TeTeT, Depends a bit on what really happens. Is it freezing (desktop only or whole system) or a crash. First may show not much and if the whole system is frozen, the sysrq keys don't work either.
<TeTeT> smb: ok, seems system is completely frozen, e.g. ssh doesn't work any longer. Only at times the mouse pointer remains moveable
<smb> TeTeT, So one thing to try could be to ssh in before and do a tail -f on the syslog and hope to catch something there.
<TeTeT> smb: ok, good thing to monitor in real time, I'll suggest that, maybe using the remote option of rsyslog as well
<ppisati> morning
<cking> morning
<smb> morning
<smb> cking, You know what, I fixed the jumbled characters in my battery readout that caused udev to go wild...
<cking> smb, how?
<cking> smb, was this a user space fix or in the kernel?
<smb> cking, Removing the battery for a while... Now the strange characters are gone... :/
<cking> oh
<cking> that's kinda amusing
<smb> So it was a hardware fix... :-P
<cking> still, the udev issue still needs to be fixed IMHO
<smb> Wished I had thought of that last week. Would have saved me the annoying stop/start cycles on udev
<smb> I tend to agree, there must be a way to stop a call that has a permanent issue instead of repeating it 
<apw> jjohansen, hello
<smb> morning apw
<apw> morning
<Kano> hi apw , could you take a look in pata_of_platform.c ?
<Kano> apw: it seems there must be a 32 bit error?
<ppisati> herton: hold on for the omap4 kernel, i'm respinning it
<herton> ppisati: ok, it's ok to respin it, that problem in the changelog should be fixed
<ppisati> herton: yep, but Tim pushed the Linaro revert on top of the previous version, let inclue that patch too
<ppisati> *let me include
<herton> ppisati: ok, see if there is an abi change needed also because of the change, may be not, I'm not sure but I think abi check is enabled for this one (only disabled for armhf from what I saw yesterday)
<ppisati> no abi changes
<herton> ok cool
<ppisati> herton: ok, all done
<herton> ppisati: ack, thanks
<ppisati> herton: and it passed the verify-release-ready test
<herton> ppisati: tim pushed the patch to you? it misses the signed-off (may be I'm being too pedantic now)
<ppisati> herton: nope, it's alreadi in ubuntu-oneiric/ti-omap4
<ppisati> (why kernel.ubuntu.com is always so slow????)
<herton> ppisati: indeed, I forgot to fetch
<ppisati> git://kernel.ubuntu.com/ubuntu/ubuntu-oneiric.git ti-omap4
 * ppisati goes to find something for lunch...
<apw> cking, about ?  wondering about resurecting the kernel power consumption blueprint, as a bucket for your workitems
<apw> seems the logical thing to od
<tgardner> ogasawara, given Rick's test policy, do you suppose we should delay uploading precise until about -rc2 ?
<ogasawara> tgardner: that sounds safer
<tgardner> ogasawara, shall I rebase against -rc1 ? I'd like to get some master-next testing under way
<smb> Though potentially that policy does not apply to us as I think they say Ubuntu developed sw
<ogasawara> tgardner: go for it
<tgardner> smb, folks will howl anyways if we break their kernel
<ogasawara> tgardner: gimme 5min to push the reverted ntrig patches
<tgardner> ogasawara, ack
<smb> tgardner, That is true. Even more if it stops booting... So to wait an rc sounds like a save play
<smb> tgardner, Btw, not sure whether you would still look at it but 2.6.32.47 feels like soon being followed by a fixup .48. Some patches seem to break builds...
<tgardner> smb, yep, saw that. armel failure, right ?
<smb> tgardner, Well that and an allmodconfig explodes on my amd64 build in some soc module
<tgardner> smb, if it builds for our configs, and doesn't break omap3, then its likely still worth applying.
<ogasawara> tgardner: pushed
<tgardner> ogasawara, ack
<smb> tgardner, Not sure whether we would hit those (well the first one likely). I have not yet tried any builds on our side. I'd probably delay until it is fixed, then I can push a fixed up drm33 and we could use that one.
<tgardner> smb, do you have some drm patches for this next stable update ?
<smb> There is two drm fixes from Debian that I would add as well. And then it might just be one run on the formal (tracking side)
<tgardner> ok
<ogasawara> tgardner: fwd'd you a patch from apw to fix a 3.2-rc1 build failure
 * smb finds it scary to start answering tgardner questions before he asks them...
<tgardner> smb, she's just that good
<smb> tgardner, I do not count me as a she... ;-P
<tgardner> smb, thought you were talking about ogasawara
 * apw looks vague
<smb> Nah, I was typing the answer to the drm question when you asked it
<smb> Of course I am not that fast of a typist so I did not beat you on pressing enter
 * smb wonders whether he needs to slap apw...
 * apw sends smb a typing tutor
<apw> smb, always
<tgardner> apw, how's the custom binary maintenance prototype coming? this epoll patch continues to clog my folder.
<apw> tgardner, heh i was just checking that branch out ...
<ppisati> tgardner: can you install u-boot-tools on tangerine inside the oneiric-amd64 chroot? need it to create the uImage kernels for arm (when i'm building from vanilla)
<tgardner> ppisati, done
 * ogasawara back in 20
<apw> tgardner, ok so i have a prototype basically working.  i am a little concerned about the semantics
<apw> tgardner, essentially we have two options, either clean creates the patches, or we have a 'refresh' option you use for this function
<apw> in the first instance things are automatic, but local test builds you need to know you need to push the dependant branches also
<apw> in the latter you need to know to refresh them when changing things, which can be inforced at insertchanges time
<apw> but testing is much more 'as it is now'
<smb> I'd tend towards the refresh option...
<ogasawara> are we having a meeting today?
<apw> ug i hope not :)
<smb> It would be in one hour, or?
<apw> bjf, is the master of all things meeting
<bjf> ogasawara, who would run it?
<ogasawara> bjf: I don't know if we actually decided who's running the meetings now
 * jussi waves to ogasawara
<apw> oh did bjf abdicate ?
<ogasawara> apw: he did
 * ogasawara waves to jussi 
 * smb missed that, too
<ogasawara> I don't think it was widely circulated that he stepped down from being the chair
<apw> well i am pretty sure noone wants to do it, so perhaps we need to return to a rotating chair
<ogasawara> I vote that we postpone till next week.  I'll chair.
<bjf> ogasawara, smb and apw were at the same table with me at plumbers when i made the statement :-)
<apw> ok, works for me.  we need to make sure its nice and documented to the untrained eye so we can rotate it
<smb> bjf, probably too drunk then... :-P
<apw> plmbers, plumbers, you expect me to remember that far back ?
<bjf> smb, could be though it was in the a.m. at the hotel
<cking> I recall bjf saying it
<smb> bjf, Oh, morning bah... 
<jussi> DO you peoples use the meeting bot for your meetings?  (meetingology) 
<apw> cking, heh then you should have reminded us :)
<apw> jussi, yep
<bjf> jussi, the new bot sucks
<cking> ...and I thought "if it I join the kernel team it means somebody as disorganised as me running the meeting == fail"
<jussi> bjf: how so?
<bjf> jussi, the output is ignored
<jussi> bjf: more specific pleasE? 
<apw> it does tend to stomp all over what you are trying to read by repeating everything and chainging the topic all the time
<bjf> jussi, we developed our own scripts for deailing with the meeting output, the bot doesn't come close to producing the same, so I/we just ignore it
<apw> quite why it does that i am unsure
<jussi> bjf: and if there are specific issues, bugs would be super. 
<apw> for me the issue it about once a year we get a new format out of it
<jussi> bjf: so you dont like the wiki output the bot makes? 
<jussi> AlanBell: ping
<apw> which is just a pain.  we already had to make something make what we wanted to cope with the old
<bjf> jussi, no, it's not helpful
<jussi> (AlanBell is the author fyi)
<bjf> jussi, i explained this to AlanBell
<apw> bot, so ... we just continue to do the same and we are bot agnostic
<jussi> strange. I find it most helpful. 
<apw> do you push many tables through it ?
<jussi> No...
<jussi> I guess IRC team meetings are very different to kernel meetings ;)
<bjf> jussi, the bot grabs the topic changes but then just adds the raw irc log at the end, i don't find that usefull
<jussi> bjf: As I said, Im sure bugs would be helpful - perhaps in the future we can create modes in it so theres a mode that puts the output to a style that works better for teams with this kind of meeting. 
<bjf> jussi, as i said, i discussed it with AlanBell, he didn't see it as bugs, i'm more than happy to keep doing what i'm doing
<apw> often trying to make something do everything is a recipe for disaster
<apw> bjf, does the new bot at least give us the beginning and end so we can find the poo to process mroe easily ?
<bjf> apw, i just use the raw log, it's easy enough to find the beginning and end
<bjf> apw, there is a startmeeting/endmeeting
<apw> fair enough, was thinking if there was a url it gave you at the end and you could use that to process against that it might have value
<bjf> apw, maybe, but i'd have to make changes to the script, and the next time they change the bot output i'd have to make more, and so on, and so on, ...
<apw> fair enough
<bjf> apw, the next person to run the meeting can decide if they want to do it differently
<ogasawara> I doubt anyone is really reading our meeting minutes that closely to even care
<bjf> jussi, "our way" is completely documented: https://wiki.ubuntu.com/KernelTeam/RunningTheIRCMeeting
<bjf> ogasawara: that is very true
<joaopinto> Hi
<joaopinto> after apt-get sourcing the kernel where can I find the list of Ubuntu specific patches ?
<jjohansen> apw: morning, so what I was pinging you about was CVE-2011-4081, it is marked as needed for hardy but at least on a first glance it looks like the code wasn't introduced until 2.6.32
<ubot2> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4081)
<apw> ogasawara, that RunningTheIRCMeeting page doesn't seem to have the kteam-tools magic in it, perhaps you could slam it in when you work it out
<ogasawara> apw: yep, will do
<apw> joaopinto, the ubuntu specific patches are all directly applied in the version you get from apt-get source
<joaopinto> ah ok :\
<jjohansen> have you managed to fully script the meeting now :)
<apw> joaopinto, if you want the raw patches they are in the our public git trees
<apw> joaopinto, every upload has a corresponding tag in those repositories to allow you to find the exact source
<joaopinto> I have checked the source, just wanted to be sure the patch was not applied somehow during the build process
<apw> other than on hardy there are no patches applied at build time
<apw> jjohansen, you should be able to mark hardy 'not-affected' then and my bot will trust you
<apw> jjohansen, in theory if the other end was working changing it to Invalid in the bug would be sufficient
<joaopinto> there is no patch included for bug 843431 yet :\
<ubot2> Launchpad bug 843431 in linux "Logitech camera microphone does not work / makes "chipmunk" sound" [Medium,Triaged] https://launchpad.net/bugs/843431
<apw> jjohansen, propogating to UCT as not-affected and triggering my ignoreing it
<apw> joaopinto, is it marked Fix Released ?
<joaopinto> no, actually there are many bugs related to this issue, with different status and progresses
<jjohansen> apw: okay, so just fix it in uct, or do I need to mark invalid in the bug too
<apw> joaopinto, indeed from the bug it is not clear that anyone has a fix for it even
<joaopinto> http://pkgbuild.com/~heftig/linux-zen/usb-add-reset-resume-quirk-for-several-webcams.patch
<joaopinto> https://build.opensuse.org/package/view_file?file=usb-add-quirk-for-logitech-webcams.patch&package=linux&project=home%3Agrayden&srcmd5=ac65d19a58e7dbdcd8a328e124aac0b5
<joaopinto> well, someone is applying patches for it :)
<joaopinto> I have one affected webcam, whose device id is not listed on that specific patch, I am testing it now
<bjf> joaopinto, it helps to know which version you are talking about
<joaopinto> bjf, version for ?
<apw> joaopinto, ok that patch seem to have _just_ hit mainline in v3.2-rc1
<bjf> joaopinto, also, we get most of these cinds of patches from upstream stable releases
<joaopinto> yeah, was checking http://www.spinics.net/lists/stable-commits/msg13878.html
<apw> joaopinto, and it is marked for stable so we should see it for older releases soon enough via there
<bjf> joaopinto, kernel version or hardy/lucid/maverick/natty/oneiric
<joaopinto> I don't remember when the problem was introduced, it's present on oneiric
<bjf> joaopinto, that's all i wanted to know, what kernel you were trying to build (didn't see it in the scroll back)
<apw> joaopinto, ok added the useful bits of that to the bottom of the bug
<joaopinto> apw, where can I check the v3.2-rc1 quirk patch ? (want to to check for my device id)
<apw> it is 2394d67e446bf616a0885167d5f0d397bdacfdfc in linus' tree
<apw> joaopinto, ok that patch is sitting in gregs queue for 3.0 and 3.1
<apw> so we should get it in oneiric in the next weeks
<joaopinto> ok, QuickCam E 3500 not there, I am going to test for a few more days to be sure that it fixed, once I am sure, how should I proceed to ask for a device id to be added to the list ?
<apw> the most direct way is to send a patch up to mainline and mark it for stable handling
<joaopinto> (the issue is random, I can't reliably determine that the fix is working)
<apw> if that too scarey you can send a patch to the ubuntu kernel list and we can help
<joaopinto> well, I am an end-user, whatever is easier for me :)
<joaopinto> I will email the ubuntu kernel list with the bug report link
<AlanBell> bjf: if it doesn't work for a team then that is a bug
<joaopinto> tks for your time
<joaopinto> this bug is present since the last LTS http://www.techytalk.info/logitech-e3500-webcam-and-cannot-set-freq-16000-to-ep-0x86/ :\
 * ppisati bails out for a bit...
<bjf> ogasawara, we have a "bugs with patches" report somewhere don't we? or do we just do a lp advanced search ?
<ogasawara> bjf: lp advanced search
<bjf> ogasawara: ack
<smb> https://bugs.launchpad.net/ubuntu/+source/linux/+patches
<ogasawara> bjf: although I had a pretty graph of it somewhere
<bjf> smb: thanks
 * bjf wonders if "patch attached" should be displayed on our custom reports
<htorque_> hi all! is bugzilla.kernel.org down for you (or still not up after the security breach)? i'm wondering if it's known that intel wireless (ultimate-n 6300) is not working with 3.2-rc1 (just tried the mainline ppa yet).
<bjf> htorque_: bugzilla.kernel.org is still down
<htorque_> bjf: thanks!
 * tgardner -> lunch
<cwillu_at_work> 32bit mainline ppa builds?
<cwillu_at_work> (broken until the build tools are updated for precise?  something else?)
<undriedsea> Hey Everyone,
<undriedsea> I am having a problem accessing /proc/<pid>/mem range after mprotect has made it readable. It almost seems the procfs driver is not aware of the updated permissions. Any ideas or hints would be great!
<undriedsea>     1. Process A ptrace ATTACHs to process B
<undriedsea>     2. Process A cannot access of a given range in process Bs /proc/<pid>/mem due to the associated mapping in /proc/<pid>/maps being non-readable
<undriedsea>     3. Process A requests process B use mprotect to mark given mapping as readable (mprotect returns success)
<undriedsea>     4. Process A now should be able to read the range in /proc/<pid>/mem but can only read part of the range...
<undriedsea> Details: http://codepad.org/DMItNdYa
<undriedsea> Does anyone know who is the maintainer of the part of the kernel that container the mprotect systemcall?
<Somedude> I get this when trying to turn on VT-d. (Intel VT-d tech enabled), intel_iommu=on(!): Your BIOS is broken; DMAR reported at address fed90000 returns all ones
<Somedude> The BIOS is up to date, so what can exactly cause this error/warning?
<Kano> hi, is there a reason why the generic target is dropped for 32 bit?
<Kano> older pentium m do not boot with pae enabled
<Kano> and some other older cpus
<Sarvatt> http://www.linux-archive.org/ubuntu-kernel-team/596063-3-2-rc1-rebase-review.html
<Sarvatt> geode and pentium-m yeah
<Somedude> Sarvatt: any ideas on my one?
<Sarvatt> Somedude: you literally have a buggy bios, its not exactly uncommon or anything, VT-d is all kinds of pain
<Kano> there are lots of pple with that hardware out there
<Sarvatt> does it fall back to swiotlb gracefully?
<Sarvatt> if not you can boot with intel_iommu=off to work around it
<Somedude> how do I check?
<Sarvatt> dmesg | grep SWIOTLB will tell you
<Somedude> I need it for directed I/O, that's a bit of the pain
<Somedude> yes
<Somedude> it does
<Somedude> what to do to work around this problem?
<Somedude> Sarvatt: can I get Directed I/O with swiotlb too?
<Somedude> I need to put an PCI card to an KVM VM
<Sarvatt> Somedude: honestly I have no clue, I imagine you can though
<Sarvatt> there was a bug awhile back where it would completely turn off iommu support if you got that error but thats fixed now apparently
<Somedude> Sarvatt: this one you mean? http://freecode.com/articles/red-hat-updated-kernel-packages-fix-multiple-security-issues-16
<Somedude> 588638 - [abrt] crash in kernel: Your BIOS is broken; DMAR reported at address fed90000 returns all ones!
<Somedude> I need to contact the supplier of the motherboard and ask them for a fixed BIOS, I guess?
<Sarvatt> yeah sounds like what google pulled up when I searched for it, you might be able to get more info there :) https://bugzilla.redhat.com/show_bug.cgi?id=524808
<ubot2> bugzilla.redhat.com bug 524808 in kernel "swiotlb should be enabled when VT-d setup fails" [High,Closed: errata]
<Sarvatt> yeah but honestly don't expect that would happen unless its really new (then theres probably still no chance..), OEMs usually just ship crap out the door and give up on it :)
<bjf> Kano, it was discussed at uds and the decision was made there, feel free to post a question to the ubuntu kernel team mailing list
<Sarvatt> Kano: maybe send a mail to kernel-team@lists.ubuntu.com discussing it
<Sarvatt> bjf beat me to it
<bjf> heh
<Kano> Sarvatt: ?
<Sarvatt> regarding the dropping support for pentium m
<Somedude> Sarvatt: I have a contact by ASUS Holland, I will tickle him until he provides me a new BIOS
<Somedude> *A working one, that is
 * Somedude yawns
 * Somedude -> bed
<Somedude> 'night all
#ubuntu-kernel 2011-11-09
<Kano> Sarvatt: it is definitely a very bad idea...
<bjf> Kano, we review *all* the flavours that we support at every UDS
<Kano> well the server one was obsolete, i never used that
<Kano> only generic + generic-pae
 * smb considers just going back to bed
<smb> gah
<brendand> has anyone tried to build the kernel with gcov on recently?
<apw> brendand, not recently no
<brendand> apw - do you normally need anything extra to do it? 
<apw> i don't think i have ever done it, though iirc it is an external patch set and lags the kernel mostly
<apw> UBUNTU: SAUCE: rtl8192se: Force a build for a 2.6/3.0 kernel
<Fudge> cjwatson  are you about cobber
 * Fudge pokes apw 
<cjwatson> Fudge: it helps to give a reason rather than just poking people.
<Fudge> sry cjwatson , we spoke a few weeks ago about kernel sound, i wondered if i can show u a bug report Attila submitted, i tink i saw ur name on there
<cjwatson> I know nothing about kernel sound
 * cjwatson <- not a kernel hacker
<Fudge> mm my mistake
<Fudge> wonder who it was loL
 * apw looks at Fudge
<_jmp_> good $localtime
<apw> _jmp_, hiya
 * tgardner reviews 104 stable patches
<smb> tgardner, Most of them just are as from upstream. I would say the ones that can use a bit more thought would be the two drm ones and the adaption I made as noted in the pull request
<ogasawara> tgardner: I'm getting ready to push over the top of precise master-next.  just want to make sure you haven't got anything locally that you wanted to push.  am also going to push up sforshee's alps patches at the same time.
<tgardner> ogasawara, whack away
<tgardner> smb, just pushed lucid master-next with a small compile fix to 'NLM: Don't hang forever on NLM unlock requests'
<smb> tgardner, Gosh I managed to break it with copy and paste. :(
<tgardner> smb, your forgot a ','
<tgardner> you*
<smb> tgardner, Bah. Thanks for fixing it.
<tgardner> smb, the DRM patches look fine. I'm gonna reboot with that kernel here shortly
<smb> tgardner, ok, probably should do the same here. are you building on gomeisa or tangerine
<tgardner> smb, I built locally
<smb> Someone has too much powerful gear... On the other hand its noisy enough nobody else wants it...
<tgardner> smb, indeed. its probably time to ship that one to 1SS
 * ogasawara back in 20
<smb> tgardner, guess I will hammer gomeisa a bit with that master-next plus that xen fixup. Then I can test that on various places
<alexbligh> smb, we talked a week ago about the Ubuntu kernels not booting on Xen PV-on-HVM because xen-platform-pci is missing from  the udeb. I have Iain Watson sitting next to me who is happy to provide a patch. Would you rather it put it in the udeb as a module or built it in to the kernel (the latter definitely works, the former we haven't got working yet).
<alexbligh> (i.e. we got it into d-i but have not yet discovered what filters the modules into what appears in the udeb and what doesn't).
<smb> alexbligh, Well, from the mailing list I think that it will be built-in at least for newer kernels, so it feels like that approach would be simpler
<alexbligh> OK, so if Iain provides a patch for that, and puts it against one of the LP bugs, you would apply it? (in principle)
<smb> It sounds reasonable. Btw, are we talking about Oneiric or Peecise target
<alexbligh> smb, both ideally, but mostly Oneiric, as we'd actually like a version of Oneiric we can run on Xen :-)
<smb> alexbligh, It is not that you cannot *run* it on Xen. You want the paravirt disk for install
<alexbligh> It won't run at all on Xen because it unplugs the non-PV disk.
<alexbligh> And cloud customers don't have the option of disabling all PV emulation...
<alexbligh> therefore it just 'doesn't run on Xen' :-)
<alexbligh> (yes, I know they can do xen_emul_unplug=never)
<alexbligh> s/never/unnecessary/
<smb> alexbligh, or unnecessary, but yeah if you need HVM it gets a bit difficult of that option is not put into your pv-grub commandline
<apw> alexbligh, so if he is supplying the patch get him to send it to kernel-team@ directly
<alexbligh> apw, hi Andy, OK, I will get Iain to do that. Our problem is that we need one Xen config that works with everything as we don't know what is in the image that we will run
<apw> an admirable goal if it can be done for sure,y
<alexbligh> Iain is iwatson@flexiant.com, and is just looking over my shoulder, so I shall leave it to him.
<apw> yeah as long as we have the bug reference in there we'll be good and get the right people looking at it quickest
<apw> bugs dissappear in the quagmire
<apw> tgardner, ogasawara, i have the armhf bits pending to push, is the tree stable enough for me to push them on the top... they have a config copy in them so i neeed to have a stable config when i push
<ogasawara> apw: go for it, I pushed the bits I wanted already.
<apw> ogasawara, tgardner, ok pushed
<tgardner> apw, ack, will have a look when I get back in a couple of hours.
<ogasawara> bjf: I'm looking at kteam-tools/ktl/ubuntu.py .  It notes db["12.04"]["supported"] = False.  Will that remain False for the remainder of the dev cycle and then flip to True once we release 12.04?
<apw> tgardner, ogasawara, the config is identicle to armel at this point.  the config does maintain them separatly and this needs to be considered when doing config changes for arm
<ogasawara> apw: ack
<tgardner> apw, I assume we must have an armhf chroot ? or did you just use the armel chroot
<apw> tgardner, we have no way to build it without the right cross compilers and the right chroot
<tgardner> ah
<apw> tgardner, and you can't make those without the libc from the kernel.  so its a test it as well as you can and pray job
<bjf> ogasawara: i think so but i need to dbl check the meaning of "supported" in some of the tools, there was a specific reason for that at the time i did it
<apw> bjf, yeah i think that means 'stable teams repsonsibility' in there effectivly
<ogasawara> bjf: only reason I ask is because I've got a script using supported_series which I believe included the dev release (it at least oneiric when it was in development)
<ogasawara> bjf: so I'm just curious if it's meaning of supported has indeed changed and i need to fix up my script
<bjf> ogasawara, that's what i was going to check, then it probably needs to go to "True"
<bjf> ogasawara, the Precise block was added before Oneiric was final so i probably made it False so scripts wouldn't use it
<ogasawara> bjf: I'll make the change and push.  let me know if it buggers up any of your scripts.
<bjf> ogasawara: thanks
<smb> alexbligh, Btw, for precise XEN_PCI_PLATFORM does not exist anymore as configurable option
 * apw has to pop to the store for a washer, else we won't be using the loo
 * smb now probably has more info than he wanted to have...
<brendand> Does anyone know why, if I have GCOV_KERNEL enabled I get:
<brendand> II: Done
<brendand> make: *** [abi-check-generic] Error 1
<brendand> when I don't without it enabled?
<smb> brendand, because enabling gcov changes some structures and thus the abi
<brendand> smb - fair enough
<brendand> smb - do i build just the headers with gcov to begin with then?
<brendand> smb - i'm very green on kernel building
<smb> That won't help you to get a gcov enabled kernel. Depending on whether you do local builds or on a ppa you can disble the abi check...
 * smb tries to find that wiki page again
<smb> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
<brendand> smb - thanks
<komputes> Hi everyone, I was wondering if someone can explain to me how the Linux kernel decides to assign a specific driver when a particular device when detected. From what I understand each module has a table of IDs it supports. Can I view this table? Where in the source should I look for this information?
<tgardner> komputes, in any particular driver you can look for the usb_device_id or pci_device_id table.
<komputes> tgardner: How would I go about looking for the USB ID in /lib/modules/2.6.32-34-generic/kernel/drivers/media/video/usbvideo/usbvideo.ko
<komputes> it is not ASCII text but ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
<apw> komputes, also that information is extracted and forms the module.dep stuff that modprobe uses; thats all in ascii
<tgardner> komputes, get the source code?
<tgardner> apw, thats kind of the hard way isn't it?
<apw> tgardner, i'd say it was the easy way if you only have the binary
<tgardner> I guess if you already know the ID and able to format your search correctly
<apw> komputes, so you can see the matches which will map to a specific driver like this: grep i915 /lib/modules/`uname -r`/modules.alias
<tgardner> komputes, look in /lib/modules/`uname -r`/modules.alias
<komputes> That works.
 * jsalisbury has recovered from changing Unity settings 8-O
<tgardner> ogasawara, I'm test building the rebased seccomp_filter patches from kees
<ogasawara> tgardner: ack
 * tgardner -> lunch
<kees> tgardner: oh excellent, thanks!
<kees> tgardner: please double-check it on ARM. I *think* will fixed it for ARM, but that was the main thing I wanted to double-check when I was going to do the rebase.
<kees> tgardner: and, if you want, qrt has seccomp_filter tests in it, but, again, I haven't tested them against the newer patch set. it _should_ pass, but it's possible something subtle changed that I was accidentally depending on in the test.
<tgardner> kees, were you going to consider any of Tetsuo's suggestions ?
<kees> tgardner: I replied to his email, I'm happy to switch from #if to #ifdef. the code changes I disagree with, but am curious if he sees something I don't.
<tgardner> kees, ok, I just hadn't seen anything on the kteam list
<tgardner> kees, I'll pull 'em into Precise for now. We've got plenty of time to fix any issues.
<jjohansen> kees: often not, he likes to pick on style
<kees> jjohansen: I think he wanted to just minimize the patch, but I like having it be as functional as it is.
<kees> tgardner: hrm, is that a subscriber-only posting list? maybe it got moderated.
<jjohansen> kees: ah could be
<tgardner> kees, um, likely
<tgardner> kees, ok, moderated
<kees> hm, weird. https://lists.ubuntu.com/archives/kernel-team/2011-November/017663.html went through
<tgardner> kees, 'cause I'm the moderator
<kees> hah, okay :)
<kees> I'll get my @chromium subscribed...
<tgardner> kees, thanks
<kees> though frankly, I'm already in there as @ubuntu and read it that way. I just did stuff from @chromium because of the @google in the original email. :P
<kees> wheee
<kees> too many email addresses
<hallyn> smb: bug 795717 is the one which needs a patch sent to -proposed
<ubot2> Launchpad bug 795717 in linux "32bit rhel and centos 5.(5|6) hangs on boot on natty" [Medium,Confirmed] https://launchpad.net/bugs/795717
 * ogasawara lunch
<tgardner> ogasawara, what is the name of the kernel config spec ?
<tgardner> blueprint, I mean
<ogasawara> tgardner: https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-config-review
<tgardner> ogasawara, thanks
<ogasawara> pgraner: you want me to take over filling in the monthly report blurb each month for ya?
 * tgardner is off to bike in the snow.
<pgraner> ogasawara, sure
<bjf> jsalisbury: did you look into whether bugs are being expired ?
#ubuntu-kernel 2011-11-10
<jsalisbury> bjf, I'm pinging bdmurray and the landscape team now.
<jsalisbury> bjf, s/landscape/launchpad/ :-)
<bdmurray> about what?
<jsalisbury> bdmurray, do you know whether the lp expiration bot is running? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/399911 looks like it should have expired a while ago.
<ubot2> Launchpad bug 399911 in linux "samsung x360 fn-keys work incorrectly" [Medium,Incomplete]
<jsalisbury> bdmurray, from my understanding launcpad itself expires bugs, versus manual bots.
<jsalisbury> bdmuarry, s/manual bots/bots we create/
<bdmurray> jsalisbury: yes the launchpad janitor expires bug reports
<bdmurray> jsalisbury: I'd expect to see "This bug can expire in xyz days" on the page
<bdmurray> jsalisbury: for example in bug 846652 you can see this
<ubot2> Launchpad bug 846652 in xserver-xorg-video-intel "Screen shifted right and incorrect refresh rate when switching VTs and unsuspending" [High,Incomplete] https://launchpad.net/bugs/846652
<jsalisbury> bdmurray, could there be a bug in the expiration janitor?  Does it only trigger off of an incomplete status
<bdmurray> jsalisbury: it must be incomplete and a not match a few other criteria
<jsalisbury> bdmurray, yeah, maybe the number of affected people has something to do with it?
<bdmurray> jsalisbury: that criteria is listed at https://help.launchpad.net/BugExpiry
<bdmurray> jsalisbury: no its not that I'm thinking / looking at it
<jsalisbury> bdmurray, thanks for the link, I'll take a look at that page.
<bdmurray> jsalisbury: I don't see anything my only thought is it might be because date_incomplete is so old
<jsalisbury> bdmurray, you think because it was set to incomplete back on 2009-12-10, and maybe the expiration logic was different then?
<bdmurray> jsalisbury: no that maybe the janitor only looks at date_incomplete within the past 90 days ... I'm grasping at straws though
<jsalisbury> bdmurray, I wonder what would happened if I marked the bug as confirmed then incomplete again?
<bdmurray> jsalisbury: there is a bug.isExpirable method that returns False
<bdmurray> well you'd have to wait 90 days for the actual expiration to happen
<jsalisbury> bdmurray, I also noticed the background for Incomplete in bug 399911 is a brighter yellow compared to incomplete say in bug 846652, not sure if that actually means anything
<ubot2> Launchpad bug 399911 in linux "samsung x360 fn-keys work incorrectly" [Medium,Incomplete] https://launchpad.net/bugs/399911
<ubot2> Launchpad bug 846652 in xserver-xorg-video-intel "Screen shifted right and incorrect refresh rate when switching VTs and unsuspending" [High,Incomplete] https://launchpad.net/bugs/846652
<bdmurray> jsalisbury: don't think so
<jsalisbury> bdmurray, do you have a script, or is that one in arsenal that you used to pull the bug.isExpirable method?
<jsalisbury> bdmurray, I guess I could just write a quick one.
<bdmurray> jsalisbury: I just used ipython to check on that bug
<jsalisbury> bdmurray, ahh, ok.  I wonder if it has anything to do with being assigned to someone, then reassigned to nobody.
<jsalisbury> bdmurray, bjf, I'll dig further and maybe see if someone on the launchpad team knows.
<bdmurray> oh, I've an idea now
<jsalisbury> :-)
<bdmurray> jsalisbury: I'm pretty sure its because the status for 846652 is "Incomplete w/o response" and the status for 399911 is just "Incomplete"
<bdmurray> jsalisbury: and the API only tells you that they are Incomplete
<jsalisbury> bdmurray, I'm not sure I understand the "Incomplete w/o response", Are comments in the bug not responses?
<jsalisbury> bdmurray, or is it comments added after the bug was marked Incomplete?
<bdmurray> the latter
<jsalisbury> bdmurray, ahh, ok.  
<jsalisbury> bdmurray, and once a bug has a response after marked incomplete, it looks like it can't be forced to expire.  For bug 399911, I marked it confirmed, then incomplete again, and the message "This bug report will be marked for expiration in N" did not show up.
<ubot2> Launchpad bug 399911 in linux "samsung x360 fn-keys work incorrectly" [Medium,Incomplete] https://launchpad.net/bugs/399911
<jsalisbury> bdmurray, oh wait, I also see that that bug has a duplicate!
<jsalisbury> bdmurray, but the Expiry page says that the bug must be a duplicate itself not to expire :-/
<bdmurray> jsalisbury: having a duplicate isn't a factor
<jsalisbury> right
<martijn> Quick question, forgive the newbie on this, I'm trying to get the ubuntu kernel to diagnose a USB driver issue I'm having, but I run into "fatal: The remote end hung up unexpectedly" when git clone'ing from kernel.ubuntu.com - is this something really obvious I should know about?
<martijn> (cmd was: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-oneiric.git lixsrc )
<martijn> (now trying git clone http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-oneiric.git -- will post here when/if that fails, not aware of any firewall issues between me and the inet)
<martijn> (USB issue in question is isochronous URB reception seems to not work from userland, my suspicion is a problem in drivers/usb/core/devio.c line 1347 processcompl() and I'd like to add some printk's there to diagnose.. but that requires the kernel.)
<bjf> martijn: there is something wrong with kernel.ubuntu.com right now
<martijn> bjf: Thanks for the response! does the http request have any hope of succeeding or should I retry tomorrow?
<bjf> martijn: i think there is no hope right now
<martijn> Assuming that statement is limited to kernel.ubuntu.com, I'll try again tomorrow - thanks for the info & good luck to who is working on fixing it.
<martijn> (http also failed as expected, tomorrow!)
<T3CHKOMMIE> hey guys. i need some help with a kernel project im doing. Im having the hardest time and ive spent well over 40 hours trying to figure this crap out. i feel like I am missing just a small piece of the puzzel.... can someone help me?
<T3CHKOMMIE> maybe someone can help me. i downloaded ubuntu kernel from source. did a make menuconfig and tweaked it how i liked. then did a make...
<T3CHKOMMIE> im pretty sure that compiled the kernel. now im just trying to get it to an install CD so i can install it on my test machine. can anyone help me?
<T3CHKOMMIE> hey guys, i still cant figure out how to "use" a kernel. i compiled one and cant figure out how to get it working. i tried using UCK and that was a miserable failure. has anyone compliled their own kernel?
<T3CHKOMMIE> anyone?
<semitones> hello, valorie suggested I come here from #kubuntu to ask about my bug
<semitones> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/888415
<ubot2> Launchpad bug 888415 in pulseaudio "Speakers do not mute when headphone jack is in use. Multimedia keys unmute speakers." [Undecided,New]
<semitones> she said it ended up being a kernel problem for her
<semitones> let me know if that sounds familiar -- I can idle here for a while :)
<diwic> bjf, if you're awake - I'm trying out your kernel scripts (the alsa cod), but when try to "make source", it fails with "file not found: source/debian/control". What is the correct way to fix this problem? I notice that there is no debian/control, but debian/control.stub.in, debian/control-scripts, and control.d/ 
<diwic> all exists in the debian directory
<diwic> aha, "fakeroot debian/rules debian/control" did the trick
<apw> diwic, likely you really wanted fakeroot debian/rules clean
<apw> that creates all the transient debian stuff
<diwic> apw, aha, thanks
<apw> else you won't have a changelog later in the process
<apw> semitones, yep that is likely a kernel issue
<apw> diwic, do we have a good debugging guide for jack problems
<diwic> apw, eh 
<diwic> apw, could you specify "jack problems" a little
<apw> diwic, classic is "i insert headphones and speakers don't turn off"
<apw> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/888415
<ubot2> Launchpad bug 888415 in pulseaudio "Speakers do not mute when headphone jack is in use. Multimedia keys unmute speakers." [Undecided,New]
<apw> is one we got asked about in scrollback last night
<diwic> apw, only one of 84 open bugs for pulseaudio :-/
<apw> heh yeah, i assume its more likely a kernel issue in this case right ?
<apw> semitones, is this machine reallly running maverick ?
<diwic> apw, probably, but determing that is non-trivial
<apw> diwic, so pulse also takes a hand in jack handling ?
<diwic> apw, hmm, since oneiric it does, but if this is maverick, it's definitely kernel
<apw> oh ... thats news, i am unsure i want to know how pulse is involved ... yeeks
<apw> diwic, i'll shove it over to kernel anyhow, then it can be 1/6k bugs and even more lost
<diwic> telling user to try https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS
 * apw tells them to test an oneiric liveCD
<diwic> heh
<diwic> either should be just fine.
<apw> diwic, thanks
<apw> man maverick seems like so long ago, and yet its only a year
<apw> diwic, i note that all of those dkms packages failed to build on i386
<diwic> apw, fixed today, but yeah, maybe I should trigger a new build
<diwic> apw, is this something to worry about: "package linux-alsa-driver-modules-oneiric-generic in control file but not in files list"
<apw> its poor on our behalf but likely not an issue that stops you, thats an lbm package
<apw> oh are you trying to start up auto builds of alsa for oneiric ?
<apw> i suspect lbm doesn't have an alsa backport in it yet which would lead to that error
<apw> it'd all be commented out, still in there but off
<diwic> apw, yeah, I started off with bjf's tree for cod-natty and trying to make something launchpad based for oneiric
<diwic> apw, as bjf's stuff is non-existent for oneiric and broken for the older
<apw> diwic, nice, so yeah it may well be we have no alsa in lbm if that is what you are using
<apw> though how would that differ from your dkms package ?
<apw> if you used that against the crack of the day alsa tree ?
<diwic> they use the same source, the dkms package is for snd-hda-* modules only and is dkms based
<diwic> if you need all modules (i e testing something different than HDA Intel cards you'll need the full sound tree
<apw> ahh yes, there is a lot more poo in there
<brendand> smb - sorry to bother you, but if i were to use 'skipabi' where would i put it?
<smb> brendand, depends a bit on what command you use to run the build I believe
<smb> I use it rarely so it is easy to forget. Would skipabi=true dpkg-buildpackage -b ... work?
<brendand> the instructions i am using use debian/rules
 * smb thinks there both "skipabi=true debian/rules ..." and "debian/rules skipabi=true ..." may work
<smb> brendand, Seems right. You can use debian/rules printenv to check what settings get used
<brendand> smb - great, trying that now
<ogasawara> apw, tgardner: I'm trying to remember bits from UDS, wasn't there discussion about building in SATA_AHCI?
<tgardner> ogasawara, yep, in fact that is what I set out to do, but got confused with xhci instated.
<apw> ogasawara, there was confusingly conversations about XHCI for usb3 and ahci as its the common sata.  they got conflated at times
<tgardner> instead*
<apw> ogasawara, overall though i think we should move that one boot essential
<apw> tgardner, indeed :)
<tgardner> ogasawara, i did build in xhci in precise though. we'll need to make sure it doesn't break suspend
<ogasawara> tgardner: ack
 * apw is just doing some of those annotations as it happens
<ogasawara> apw: I'll add it as a work item so we don't forget
<apw> ogasawara, cool thanks
 * tgardner pours gas into ubuntu-devel
<Kiall> Hiya - I'm trying to figure out the cause of a kernel panic, anyone about to understand the logs? ;) http://dl.dropbox.com/u/1400487/panic/IMG_20111026_040053.jpg
 * ogasawara back in 20
<apw> Kiall, from the log that looks like a problem in a combination use of bridging and netfilter
<apw> Kiall, what release is this on as the kernel version is off the top on that dump
<apw> smb, didn't we have a problem in a stable update recently in this area ?
<apw> tgardner, ^
<Kiall> apw: Mine is running 3.0.0-13-server on oneiric
<smb> apw, Nothing I know of...
<tgardner> Kiall, you have bridging enabled with iptables rules ?
<Kiall> tgardner: yes
<tgardner> apw, IIRC it was netfilter and lxc that had issues
<Kiall> Its a server running OpenStack, So a combination of VLAN's, NF, Bridging and KVM (ie .. everything)
<tgardner> Kiall, a VPN with tun/tap ?
<Kiall> No - no VPN involved
<Kiall> I think the tap is KVM
<apw> its the bridge for kvm then in this case
<tgardner> Kiall, right. I haven't setup KVM in awhile
<tgardner> Kiall, what net filters are you using ?
<apw> Kiall, was this the host or the VM that dumped
<Kiall> apw: the host
<tgardner> apw, only yhte host can see the bridge
<apw> tgardner, point
<Kiall> tgardner: DNAT, SNAT, and standard accept/deny rules..
<tgardner> Kiall, nothing particularly dangerous there
<apw> so this is a NAT bridge not a native one (that how virtmanager talks about it)
<apw> so ... he is running a v3.0.6 base, so it'd be worth a scan of everything in stable after
<tgardner> Kiall, is this a recent change in behavior ? and how often does it happen ?
<Kiall> I've seen it twice, and I've just found another person who's its just happened to..
<Kiall> Obviously, Oneiric installs so they havenât had very long lives yet
<apw> cirtianly worth getting a bug filed with that on it, we are bound to see it plenty as well
<Kiall> yea, will do
<apw> if you can reproduce it i'd like to know if its there in -12, though i suspect it is
 * smb wonders wehter the 200+ patches pending on 3.0.y will help or do worse...
<Kiall> Standard traffic seems to trigger it, but I haven't figured out what traffic in particular :(
<apw> smb, yeah
<tgardner> ogasawara, did 3.1 compat-wireless for Lucid stay on your list ?
<ogasawara> tgardner: it did, was planning to get to it today or tomorrow.
<tgardner> ogasawara, np, thanks
<smb> Wasn't tomorrow a holiday over there?
<apw> ogasawara, also do we have an alsa backport in oneiric yet ?
<ogasawara> smb: it is, but I'm planning to swap it for another day
<tgardner> smb, yep
<smb> ah ok
<ogasawara> apw: we don't
<apw> i assume we should now/soon, i wonder if thats on -stable's radar
<ogasawara> apw: do we have a strong need for an updated alsa in oneiric?
<apw> a good question indeed
<bjf> apw, did we have a backported alsa for maverick or natty ?
<tgardner> I'm thinking we should only bother with backports to the current release and Lucid.
<tgardner> backports being compat-wireless and possible alsa
<tgardner> possibly*
<apw> so current == oneiric right now ?
<apw> bjf, another good question
<bjf> tgardner: my question was more along the lines of, "do we regularly backport alsa to N-1?"
<tgardner> on the other hand, with the LTS kernels, does it make sense to backport anything to Lucid ?
 * apw was thinking the same as tgardner on lucid
<tgardner> apw, thats one more bit of maintenance that we could shed
<apw> if we are doiing the work to support backports then they should be sufficient in theory
<apw> i guess the only question is whether we get alsa/wireless backports sooner than the 'next' kernel
<apw> as they are synced to upstream releases and not ours
<tgardner> apw, I'm sure I care about a 3 month gap
<tgardner> I'm *not* sure
 * apw has assumed sarcasm
 * ppisati bails for a bit
 * smb would be using alsa backports at least on his media pc... I could probably change to an LTS backports kernel. But assumes much whining about any support that gets dropped
<tgardner> apw, ogasawara: whats the story on powerpc flavours ? can we drop support for the old Apple G4 ?
<ogasawara> tgardner: I think we were meant to chat with lifeless and jk about it
<apw> tgardner, is that the 32bit non-smp job?  didn't jk do some work to confirm we didn't really need that
<apw> ogasawara, get a WI made perhaps then we won't forget
<ogasawara> tgardner: bah, not lifeless, luke
<tgardner> can you guys run that ground ?
<apw> ogasawara, i am thinking we want to resurect our power blueprint so that cking's work is visible
<tgardner> that to ground *
<apw> ogasawara, also i suspect we are going to have some work on boot speed which i suspect i'll want to make a new bleuprint to track; see any problems with me doing that
<ogasawara> apw: sounds fine
<cking> apw, that sounds like a good idea - needs to be trackable
<apw> cking, have you done your WIs for your stuff yet ?
<ogasawara> cking: let me see if I can find that blueprint
<apw> ogasawara, it was power-management or something
<cking> apw, nope, I'm draining my HWE worklist this week
<apw> cking, ok
<cking> all 37 mins left of it
<apw> cking, :)
<cking> not that I'm counting ;-)
<apw> rm HWE-TODO
<cking> oh yeah
<apw> sleep 2160; rm HWE-TODO
<ogasawara> cking: I couldn't find the existing one so I just made you a new blueprint.  I'll let you fill it in accordingly.  https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-power-management
<cnd> bjf, do we still pull everything from upstream stable releases?
<cnd> I've got a patch that is working its way through stable for macbook trackpads
<tgardner> cnd, yes
<bjf> cnd, yes
<cnd> ok, thanks
<bjf> cnd, which release you hoping it gets into ?
<cking> ogasawara, thanks
<cnd> bjf, it's in the review for the next one
<cnd> 3.0.9 I think?
<bjf> cnd, ok, oneiric then, yes we will pick that up
<cnd> ok
<bullgard4> http://kernelnewbies.org/Linux_2_6_26: "2.6.26 adds support for ... BDI statistics and parameters exposure in /sys/class/bdi, ... Linux 2.6.24 merged per-device dirty thresholds: The limits that the kernel put to the amount of memory that a process can "dirty" changed from being global to be per-device. 2.6.26 exposes a interface in /sys/class/bdi that allow to set several parameters....
<bullgard4> ...There's another set of read-only parameters that are exposet in debugfs (debug/bdi/<bdi>/stats) " What does Â»BDIÂ« stand for?
<tgardner> bullgard4, block device interface ?
<cnd> bullgard4, probably a debugger used for doing low level hardware bringup
<cnd> wait, nm, that doesn't make sense given the rest of the comment
<cnd> unless they are unrelated
<smb> Documentation/ABI/testing/sysfs.class-bdi: "Provide a place in sysfs for the backing_dev_info object." 
<bullgard4> tgardner, cnd, smb: Thank you very much for your help. --  I will continue snooping. 
<broder> how frozen is the upstream kernel during the rc period? i have a patch i'd like to see get in (http://paste.ubuntu.com/734424/, based on https://lkml.org/lkml/2010/3/10/188), but i've never interacted with the lkml before and don't really know what i'm doing
<broder> err, http://paste.ubuntu.com/734429/ would be the one actually rebased onto master, but whatever
<tgardner> broder, you'll likely need to run it past the list and the maintainer.
<tgardner> rtg@lochsa:~/proj/linux/linux-2.6$ scripts/get_maintainer.pl -f drivers/leds/led-class.c
<tgardner> Richard Purdie <rpurdie@rpsys.net> (maintainer:LED SUBSYSTEM)
<tgardner> linux-kernel@vger.kernel.org (open list)
<broder> so just send it off and hope for the best? :)
<tgardner> broder, you should check with Samuel Thibault that it hasn't already been reviewed
<broder> tgardner: ok, thanks for the pointers
 * tgardner -> lunch
<tgardner> apw, ogasawara: can you remember any reason why CONFIG_MEMSTICK_R592 is not enabled in either Oneiric or Precise ?
<ogasawara> tgardner: no idea
<apw> tgardner, nothing jumps out at me, its not in any of our groups we check regularly
<tgardner> seems like it should have popped up in our config review
<apw> it may be one we have on our list for review
<tgardner> apw, well, we clearly missed it in oneiric
<tgardner> bug #238208
<apw> we didn't have the same tooling in oneiric, but ogasawara lets add a wi to investifate it
<ubot2> Launchpad bug 238208 in linux "Need MemoryStick driver Ricoh R5C592 (part of R5C832/822chipset)" [Wishlist,Confirmed] https://launchpad.net/bugs/238208
<ogasawara> apw: ack
<tgardner> apw, I'm just gonna write a patch to enable it.
<GrueMaster> bjf: Erm, arm Lucid is EOL.  No need for Bug 888698 .
<ubot2> Launchpad bug 888698 in linux-fsl-imx51 "linux-fsl-imx51: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/888698
<apw> || CONFIG_MEMSTICK_R592 || n || n || n || - || - || n || n || n || n || n || n ||  '''EXPERIMENTAL''' ||
<apw> GrueMaster, until the buildd's are transitioned off on to panda we are stuck with supporting them
<GrueMaster> grmbl.
<apw> GrueMaster, they have _told_ me 'weeks', we shall see
<tgardner> apw, isn't that inconsistent with policy ?
<apw> tgardner, its experimental and not special cased
<apw> if the option is dependent on EXPERIMENTAL then our normal policy is to not enable it,
<tgardner> apw, oh, I thought we _were_ turning on experimental options if they were modules.
<tgardner> we sure seem to have turned on a bunch so far
<apw> we have tended to if they are very definatly only going to pop up with hardware
<tgardner> well, this one counts then
<apw> yep, and it sounds like MEMSTICK_* is a class of exceptions
<apw> tgardner, its a bit frightening if that option has been available since jaunty and still EXP
<tgardner> if it breaks, I'll let 'em keep both pieces
<apw> yep
<apw> i'm going through the annotations so i'll look see if there are any more patterns
<apw> ogasawara, as we'll nearly be on final kernel by rally, do we want to have a re-config review, as we already have new problems introduced by -rc2.  i'll be adding WIs for them shortly
<apw> (at rally)
<ogasawara> apw: sounds like a good idea
<apw> ogasawara, added to the agenda
<ogasawara> apw: thanks
<bjf> apw, have we reached out to upstream stable to see if they have any plans to support 3.2 ?
<bjf> apw, also, have you heard anything about bugzilla.kernel.org coming back ?
<apw> bjf, the only thing i've heard in that space is what jjohansen said about 'one per year' and i think that means we miss
<apw> bjf, not heard a thing on bugzilla, though as people are only just getting back on at all i am not supprised
<jjohansen> apw: I don't know that is really 1 per year, but that is the talk I heard
 * jjohansen can't remember where he heard it though
 * herton -> eod
<apw> jjohansen, yeah, i was likely tipsy during that conv.
<tgardner> apw, do you have some kvm runes that work on precise ? testdrive seems to have stopped working for me
<kirkland> tgardner: hmm, what's wrong with testdrive?
<tgardner> kirkland, can't find a display, -vga cirrus
<kirkland> tgardner: hrmf?  how odd
<kirkland> tgardner: you can edit that, fwiw
<kirkland> tgardner: sudo vi /etc/testdriverc
<tgardner> Running the Virtual Machine...
<tgardner> 	kvm -m 1024 -smp 2 -cdrom /home/rtg/precise-server-i386-daily.iso -drive file=/home/rtg/.cache/testdrive/img/testdrive-disk-iZzs3g.img,if=virtio,cache=writeback,index=0,boot=on -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus
<tgardner> Could not initialize SDL(No available video device) - exiting
<kirkland> tgardner: find the line that says "-vga cirrus"
<kirkland> tgardner: and change it
<kirkland> hallyn: ^
<tgardner> to what?
<kirkland> hallyn: what would be wrong with tgardner's kvm invocation?
<kirkland> tgardner: you can try -vga std|vmware|cirrus
<tgardner> I also had to figure out the pxe-virtio.bin problem
<kirkland> tgardner: honestly, though, we need to figure out why cirrus isn't working
<kirkland> tgardner: sudo apt-get install kvm-pxe ?
<hallyn> kirkland, dunno "kvm -cdrom /iso/precise-mini-amd64.iso -boot d -vga cirrus" at least works for me
<hallyn> i do have ipxe installed of course
<tgardner> kirkland, lemme check if that fixes kvm-pxe
<tgardner> kirkland, kvm-pxe is already the newest version. the issue is that qemu wants pxe-virtio.rom, not pxe-virtio.bin
<kirkland> hallyn: mind troubleshooting that for tgardner ?
<tgardner> kirkland, so hallyn's command works.
<tgardner> even over 'ssh -X'. I also tried testdrive on the physical console.
<hallyn> tgardner, can you remove 'boot=on' from your drive spec for hard drive in your command?
<tgardner> hallyn, on the war kvm command? or testdrive ?
<tgardner> raw*
<hallyn> kvm command
<hallyn> kvm -m 1024 -smp 2 -cdrom /home/rtg/precise-server-i386-daily.iso -drive file=/home/rtg/.cache/testdrive/img/testdrive-disk-iZzs3g.img,if=virtio,cache=writeback,index=0, -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus
<hallyn> uh, (sigh)
<hallyn> kvm -m 1024 -smp 2 -cdrom /home/rtg/precise-server-i386-daily.iso -drive file=/home/rtg/.cache/testdrive/img/testdrive-disk-iZzs3g.img,if=virtio,cache=writeback,index=0 -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus
<hallyn> that
<hallyn> tgardner, is this on an oneiric host?
<tgardner> hallyn, precise host
<hallyn> ok, i'm on oneiric host but with precise's kvm...
<tgardner> so I reran 'sudo testdrive -u file://`pwd`/precise-server-i386-daily.iso' to populate the COW image and now its working.
<tgardner> etf ?
<tgardner> wtf?
<hallyn> tgardner, i'll blame it on the kernel :)
<tgardner> lemme go rerun this on the console.
<hallyn> oh, i hadn't seen some of the history
<hallyn> 'could not initialize SDL" - sounds like it may be an sdl lib problem then
<hallyn> or weird perms
<tgardner> hallyn, the console hates me, but I can run it over an 'ssh -X' session.
<hallyn> i can try to reproduce on my precise laptop.  you just ran 'testdrive' and chose precise-i386?
<tgardner> it paints a little slow, but its a server install so I don't really care
<tgardner> hallyn, yes
<tgardner> clean install from today
<hallyn> ok, thanks. 
<tgardner> plus archive updates
<hallyn> I really do wish I could live my live without having to itneract with SDL
<kirkland> sdl blows
<kirkland> tgardner: thanks for the info;  when/if you ever find testdrive broken, poke hallyn and roaksoax
<kirkland> tgardner: hallyn maintains the kvm pieces, roaksoax testdrive itself
<tgardner> can do
<kirkland> tgardner: it's *supposed* to be working at all times;  if it ain't, we wanna get it fixed ;-)
<tgardner> kirkland, I was actually trying it out in order to verify that generic-pae still worked. next I'll try the same combo on a 64 bit host
<kirkland> k
<tgardner> still worked in kvm-qemu taht is
<hallyn> tgardner, oh, right, i saw that thread, was curious myself
<matthias_> Hi there. I'd like to report a kernel problem, however the command "ubuntu-bug -p linux" does not do anything :)
<matthias_> Should I manually file a report or is there another recommended way?
<tgardner> matthias_, thats a good start. would the nature of your kernel bug cause ubuntu-bug to stop working?
<matthias_> No, I do not think so.
<matthias_> My system is running. The problem is that I frequently see a bunch of annoying messages in my syslog. I wonder whether it is a hardware problem or a kernel problem.
<tgardner> matthias_, seems like it ought to work. what release ? oneiric ?
<matthias_> 11.10, fresh install
<tgardner> matthias_, other folks have been using it.
<matthias_> The problem is: I bought a new Laptop (Thinkpad T520) and received it today. Ubuntu runs, however I see the following errors:
<matthias_> kernel: [  781.456768] ata4: irq_stat 0x00000040, connection status changed
<matthias_> kernel: [  781.456775] ata4: SError: { CommWake DevExch }
<matthias_> kernel: [  781.456787] ata4: limiting SATA link speed to 1.5 Gbps
<matthias_> kernel: [  781.456794] ata4: hard resetting link
<matthias_> kernel: [  782.177920] ata4: SATA link down (SStatus 0 SControl 310)
<matthias_> kernel: [  782.193880] ata4: EH complete
<tgardner> matthias_, one time, or repeating ?
<matthias_> repeating frequently
<matthias_> say every 20 seconds
<matthias_> btw, thanks for your help!
<tgardner> you could try the 3.1 kernel: http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-3.1.0-2-generic_3.1.0-2.3_amd64.deb
<matthias_> So if it was a hardware problem I'd return the laptop to the dealer. But somehow I guess that it is a kernel problem (since the system is running)
<tgardner> it might be power management messing with your link. 
<matthias_> tgardner, software or hardware related?
<tgardner> software
<matthias_> Would you think it is worth to report a bug?
<tgardner> matthias_, yep
<matthias_> The interesting thing is that someone with another T520 reported a similar problem: http://comments.gmane.org/gmane.linux.kernel/1207661
<matthias_> tgardner, would you recommend me to file the bug manually or do you have an idea how to get the "ubuntu-bug" running?
 * ogasawara lunch
<tgardner> matthias_, manually
<matthias_> thanks, and sorry for the many questions ;)
<matthias_> ok, filed the bug (#888764)
<hallyn> tgardner, yeah i386 precise starts fine for me on just-upgraded precise
<hallyn> (boy that was a slow iso sync)
<tgardner> hallyn, well, I'm installing a 64bit precise host, so I'll see if that is any different
<apw> tgardner, i have a precise install but that was an oneiric-i386 which i think upgraded it to precise
<apw> (in a KVM i mean)
<tgardner> apw, I've now a 64bit precise host installing a PAE server ISO
<apw> ahh, i see
<apw> i guess i have an early enough kernel to have generic anyhow
<tgardner> apw, I believe this combo addresses cjwatson's concerns about qemu not working with PAE
<apw> ahh is 32 bit only really only 32bit not pae capable, interesting
<tgardner> apw, you've just bent my mind
<apw> is 32bit kvm not actually pae
<tgardner> I was really only concerned that PAE work in all cases
 * tgardner is outta here
<ppisati> have we ever released a kernel for the n900?
<jjohansen> ppisati: nothing official that I know of
<ppisati> uhm
#ubuntu-kernel 2011-11-11
<abhijit> I am seeing an issue here  have 25G of RAM, and swapiness is set 0 , with no swap device.  I see that when the free memory reaches 500M the kswapd kicks in and starts freeing around 13G  and the CPU utilisation shoots to 100%  I have also tried adding 24G of swap and I see the same issue (when the swapiness is 0)  ..  I dont like the cpu utilisation shooting to 100% and freeing such a huge 13G size.  Is there a way to reduce both of
<abhijit> them?   I am on 2.6.38.6
<LLStarks> hi, is iwlwifi missing from 3.2 debs? i can't find it outside of the precise.git repo.
<TeTeT> hello, one of our customers experiences random crashes on a x220 with the lowell build. They are adding drm.debug=0x06 to the grub command line to get more logging from drm. Are there any other options that can be enabled to increase log verbosity? Note that the system freezes completely, neither ssh nor sysreq key have any effect
<ppisati> morning *
<smb> morning +*
<smb> TeTeT, If you replace the "quiet" with "debug" you generically raise the log level. Not sure that will make that much of a difference.
<smb> (in the grub command line that is)
<TeTeT> smb: thanks, I'll recommend that
 * apw yawns
<smb> apw, morning 
<apw> heloo
<diwic> smb` or apw, do you have a sense for the response to https://lists.ubuntu.com/archives/kernel-team/2011-November/017692.html ? The answer of that question would sort of dictate what I'll do next week
<apw> they are pretty huge.  if we think overall that support is easier with them then we might be persuaded
<apw> i assume there is no hope stable would take them which might make life tricker longer term
<smb> And doing so sooner than later can help to find out how much pain this gains...
 * smb assumes we are talking about precide
<apw> yes, this is for precise
<apw> we are in more of a position to take them and see how painful things are at this stage
<apw> diwic, ^^
<diwic> apw, hmm
<diwic> apw, I do think they'll fix up the jack detection stuff for a lot of people; with jack detection meaning exposing the stuff to userspace rather than in-kernel automute
<apw> it is a risk tradeoff, ease of kernel maintenance due to being closer to mainline, against ease of support of users h/w which might just work, plus a component on how hard pulse is to make work in each case
<apw> we are in your hands for the ease part for pulse and for new quirks as you do both
<diwic> ok, so from my side of things we should definitely take them (once they've been tested a little bit more upstream), but then I don't see much of the "kernel maintenance" part
<apw> diwic, also does that imply that with jack handling moving to userspace that pulse with work but if you use jack et al your sockets will stop muting etc
<diwic> apw, automute is still done in kernel space
<apw> well i guess we get a lot of audio stuff from stable which would likely collide with these changes yes?
<apw> though a lot of that comes from you anyhow
<apw> and perhaps with this added we won't get them
<diwic> most stable stuff will be oneliners and at quite different places compared to this one
<smb> apw, Hm, one argument may be that if that all lands 3.3 then any stable updates will be rather fix the new than the old style (for the maintaining thoughts)
<diwic> so you might ask, if automute is done in the kernel, how does this affect people? Well, pulseaudio is involved with port selection, which in practice means that when you plug your headphones in, changing volume on your media keys will start to control your headphone volume instead of your speaker volume
<diwic> instead of manually have to go to speaker -> sound preferences -> output -> connector -> change to headphones 
<diwic> every time you plug your headphones in
<apw> ahh i see
<diwic> smb, that's actually an interesting point
<apw> so overall i am not anti, just wary of it
<diwic> I'll work on the pulse parts next week, and then the question would be if I should spend time testing the old or new kernel interface
<diwic> but I guess I'll go with the working theory of that we're taking the new interface (that could use some testing either way!)
<smb> diwic, Generally this is something to weight risk against use. P is an LTS, so of course we all try to minimize the risk of very new things. However if you as the expert in that area have the feeling the gains are big enough we should consider it. And rather early so we see any problems soon enough to have time for plan b...
<diwic> smb, risk wise the old interface was tested in oneiric and turned out to be stable but not adding enough jacks for many devices, so PulseAudio would not pick it up. The new interface will be used by other upcoming distros (as it's being blessed by upstreams) so in time it'll be more stable than the old one. Question is what "in time" really means here
<diwic> smb, I do have faith in Takashi here, he's very good in writing code that does not randomly screw up things
<smb> diwic, I guess in time sort of is defined as how much you will hear me and apw cursing about pa at the next ralley... ;)
<smb> But yeah, I guess I tentatively would go forward and see the outcome
<diwic> ok, thanks for the answers!
<Nafallo> hi! I'm looking for some information about a regression in the iwl3945 driver I've discovered on my laptop.
<Nafallo> first I thought it was my old hardware getting flakey, but the common denominator struck me this morning.
<Nafallo> when the AP is a UDS-style Cisco, I keep loosing the connection and re-associating ever so often.
<Nafallo> is there a bug open about it yet?
<Nafallo> this is up-to-date oneiric, with -proposed.
<brendand> Nafallo - which wireless card do you have?
<Nafallo> brendand: 03:00.0 0280: 8086:4227 (rev 02)
<Nafallo> "Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)"
<Nafallo> I'm happy to file a bug and help debug this, both using new unreleased test kernels and with older kernel ABIs to try and determine when this issue first appeared.
<Nafallo> it's only oneiric. that much I'm sure of, but I can't remember when it started. I upgraded around beta1.
<apw> Nafallo, are you saying on a cisco, or on those ciscos in the UDS environment
<apw> (there are typically many more stations and more APs with the same SSID etc
<Nafallo> apw: the same type of ciscos in the UDS environment. I'm on a linksys WRT54GL 1.1 right now just to prove it doesn't happen with them, and it's stable.
<Nafallo> apw: I see this in the millbank office, with four APs (IIRC) and also in one more place running the same AP, but just a single one.
<Nafallo> apw: same issue on both b/g and a bands (different SSIDs)
<apw> ok, so some interaction between the two, that won't be hard to fix oh no
<Nafallo> heh.
<Nafallo> this is why I want to narrow it down to a specific kernel ABI at least :-)
<apw> if you can find a kernel which it works with that'd be great
<brendand> i'm curious to know if it's a regression
<Nafallo> brendand: it is. this all worked fine in natty :-)
<Nafallo> well. any previous release I have had installed would be more correct, and I've had this hardware since 7.10 :-P
<brendand> Nafallo - well, I meant a -proposed regression or whether it also doesn't work with the release kernel
<apw> Nafallo, its possible there is a firmware change between natty and oneiric too
<Nafallo> brendand: ah. yes.
<brendand> Nafallo - 3.0.0-12-generic-pae #20
<brendand> (pae not being important)
<Nafallo> brendand: I've got ABIs 11, 12 and 13 installed, and I plan to try next time I'm close to one of these Ciscos.
<Nafallo> oh, this is also x86_64. not sure if that matters.
<Nafallo> hrm. I should probably try the precise kernel on my 11.10 installation as well? just to see if it has been fixed upstream?
<apw> Nafallo, if it failes with one, make sure you take one of them with you home so we can continue to test :)
<apw> Nafallo, yep, all good tests, find a bracket in which it broke
<brendand> Nafallo - can I have the exact details of the router involved?
<Nafallo> brendand: Cisco AIR-AP1131AG-E-K9
<Nafallo> (Cisco Aironet 1130AG series)
<apw> Nafallo, i assume we can borrow one for testing and you are the clear ideal person
<tjaalton> how can i verify that a certain version of a module is used (with dkms replacing some)
<Nafallo> apw: yeah. I just need to confirm I can clear the config of the ones I have in the DC with my manager, but I think it shouldn't be a problem.
<Nafallo> apw: I've got ~24 of them a few metres away in a flight case ;-)
<smb> tjaalton, "modinfo" would print a path, I guess you mean that
<tjaalton> smb: excellent, thanks
<tjaalton> just what i needed
<tjaalton> a silly drm-dkms backport worked after all :)
<smb> Always good when things finally work
<smb> :)
<tjaalton> yes, especially when it's friday and soon to be beer o'clock
<apw> Nafallo, thought you might :)
<smb> tjaalton, Ah good point. :) 
<tjaalton> :)
<smb> apw, We need to both switch to the Finland tz. Its so much more convenient...
<Nafallo> I also found https://launchpad.net/ubuntu/oneiric/+source/linux, which should be helpful in my testing ;-)
<apw> its cirtainly feasable as our beer-meter time zone
<Nafallo> that's UTC+2, right?
<apw> yeah
<Nafallo> the linksys connection is fine for sure. grabbed a ~630MB file while chatting to you guys ;-)
<Nafallo> no drop outs.
<Nafallo> science!
<ppisati> herton: is the verify-release-ready tool supposed to work with maverick/mvl-dove or not?
<herton> ppisati: nope, it fails. I'm not sure it's worth fixing just for it
<ppisati> ah ok
<herton> as maverick/mvl-dove is non standard in respect to the abi  files it tries to find, just ignore it, we can check by hand for now
 * herton -> lunch
 * ogasawara back in 20
<cwillu_at_work> what's up with the missing -i386 mainline kernel debs?
<komputes> Hi everyone, I see the two the i386 mainline kernel packages I expected are missing. Any ideas why this is?: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc1-oneiric/
<Sarvatt> komputes: its in the build.log there, some drivers failed to build on i386
<komputes> Sarvatt: ah, who to report this to?
<Sarvatt> the dailies will start building soon, looks like theres an upstream fix http://www.gossamer-threads.com/lists/linux/kernel/1453092
<komputes> great, looking forward to it, cheers Sarvatt 
<LLStarks> sarvatt, iwlwifi hasn't been building for amd64
<Sarvatt> brcmsmac either
 * herton -> eow
#ubuntu-kernel 2011-11-12
<matthias_> Hi, two days ago I filed a bug (https://bugs.launchpad.net/bugs/888764) concerning some frequent ata events in my syslog. I've just disabled the Optimus technology in my BIOS settings and somehow it seems that the problem disappeared.
<ubot2> Launchpad bug 888764 in linux "SATA link frequently resetting" [Undecided,Confirmed]
<matthias_> Does that make sense? If so, I'll update the bug report..
<ohsix> if you enable them again does it continue?
<matthias_> ohsix, good point ;)
<matthias_> I'll try that after a reboot.
<matthias_> However I was quite surprised that the graphics device might be related to ata errors. The only thing I can think of is something like address conflicts.
<ohsix> interrupts are shared too, though between video and a disk controller would be unusual, /proc/interrupts lists them all
<matthias_> weird
<matthias_> anyhow, I'll reboot and see :)
<matthias_> see you later
<matthias_> ok, the problem returns when Nvidia optimus technology is enabled..
<matthias_> so it seems to be related..
<JanC> matthias_: it might be related to interrupt task scheduling (e.g. if the Optimus tech keeps the OS so busy in its interrupts that the SATA interrupts time out or so)  (I am not a kernel specialist)
<JanC> especially if Optimus interrupts require trips back through the BIOS (and thus possibly trips back to 16-bit mode...)
<ebel> Let's say I want to patch my kernel to do something. Is there a simple, offical, "Copy & Paste these lines into the terminal to recompile things" guide?
<ebel> Or even an offical "Ubuntu kernel recompile HOWTO"? (There's a community one on wiki.u.c)
<ebel> oh, maybe I've already found it https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<erichammond> jjohansen: Your notes on https://bugs.launchpad.net/ubuntu-on-ec2/+bug/365233 inspired somebody to try to build a 1000Hz kernel for EC2 and they  ran into problems: http://stackoverflow.com/q/8088901/111286
<ubot2> Launchpad bug 365233 in linux "Provide Ubuntu EC2 kernels with 1000Hz timer (for VOIP/Asterisk)" [Wishlist,Triaged]
<erichammond> I guess it's something people still want to be able to do.
<jjohansen> erichammond: hrmm, I'll have a look
#ubuntu-kernel 2011-11-13
<mfilipe> hi! is there any approach for release kernel-3.2 to oneiric? it will have many improvements in energy management 
#ubuntu-kernel 2012-11-05
<rtg> apw, pushed raring rebased on v3.7-rc4, build testing now
<cking> rtg, I'll be happy to give it a test spin on various boxes
<rtg> cking, I had a docs build failure that I'm still tracking down, but the kernel binary builds OK if you want to give it a go
<cking> ack
<cking> rtg, have you any .debs that I can download?
<rtg> cking, working on it. the docs failure stops the build before the kernel binaries are packaged. should have them in 10 mins or so (on gomeisa)
<ricotz> rtg, hi, i ran into having broken input (keyboard/mouse) earlier (raring master-next with rc4 merged)
<rtg> ricotz, I've only _just_ [ushed -rc4. are you sure it wasn't an earlier version ?
<rtg> *pushed
<ricotz> rtg, i merged it myself yesterday
<rtg> ricotz, well, if you have a kernel version that does work, then how about starting a bug report and working with jsalisbury to bisect the issue ?
<ricotz> rtg, i am not sure if this is something real, i guess i will try to reproduce it with the new rebased branch
<ricotz> also having nvidia-blob around might be doing this
<ricotz> just wanted to mention it, but you probably not running it yet
<rtg> nope, haven't tested it. I've asked Alberto to have a look
<ricotz> patched nvidia works fine with the rc3
<rtg> cking, I turned on signed modules. do you have an external module you could build and install to make sure the kernel complains ? Isn't there something in fwts ?
<cking> rtg, I will give it a spin
<rtg> cking, we decided to not make requiring signed modules the default, but there some Xen folks that would like to use it.
<cking> rtg, the skarkbay laptop works so much batter with that 3-7rc4 kernel
<rtg> cking, haswell ?
<cking> rtg, yep
<rtg> huh
<rtg> I guess thats a good thing
<cking> well, I get get a desktop now that works, and 3D games render OK w/o it dying
 * ogasawara back in 20
<bjf> rtg, got that -rc4 kernel somewhere handy
<bjf> ?
<rtg> bjf, gomeisa.buildd:~rtg/ukb/raring/amd64/master-next
<apw> bjf, i need to drop an patch for the linux-lts-quantal package on the branch see any issues with that?
<bjf> apw, you need to commit a patch to quantal master-next branch ?
<apw> bjf, nope specially to the lts-quantal version in precise, to the branch specific machinary, to enabled signed kernels there
<bjf> apw, ah! i see no problem there
<bjf> apw, you are free to maneuver
<apw> bjf, thrusters to one half indeed
<bjf> rtg, how come only the -generic headers were built and not the -all?
<rtg> bjf, likely because of the way I built. lemme check
<apw> bjf, herton, does shankbot know about when -signed is needed yet.  if not we likely need to codify that too
<bjf> apw, i believe it is already on heron's todo list
<apw> purr'fec
<apw> we probabally talked about it over beer, and that is what i am blaming for me not remembering
<infinity> bjf, herton: While we're talking shankbot wishlists, it's getting unwieldly for people who aren't intimately familiar with the process to hunt down all related/dependant packages.  Maybe the description should list them all, so we don't miss any on promotions? (linux, lbm, meta, signed, etc)
<infinity> bjf, herton: Granted, that can be worked out from the prepare-* tasks (well once there's a prepare-signed), so maybe it would be duplicate info, I dunno.
<infinity> None of this is a huge deal while I'm the one doing the AA side of all of this, cause I know what's up, but I imagine it'll make someone's head explode if they have to cover for me on vacation.
<bjf> infinity, i'm not sure what you'd like to see .. a wiki page explaining the relationships?
<infinity> bjf: No, a list in the description of "these are the packages involved in this SRU".
<bjf> infinity, ah, ok, that seems reasonable
<infinity> bjf: Since the bug is (technically) only against linux (or linux-flavour), it's not immediately obvious that "promoting this also means promoting meta, lbm, signed...)
<bjf> infinity, wouldn't they get "the idea" when we pocket copy those packages?
<infinity> bjf: Well, I tend to do all the PPA copies too.  But, even if that weren't the case, you/me doing the PPA copy today, and someone else doing the promotion in two weeks, is a fair bit of disconnect.
 * infinity shrugs.
<infinity> It's not a huge deal, and I'd like to think I'll train someone a bit before they cover for me anyway.
<infinity> And, to me, the relationships are obvious.
<bjf> infinity, i'm not disagreeing, i'm just thinking about it
<infinity> But I can see how the list on sru-report.html would be mind-bending to someone who's not used to reading it. ;)
<infinity> Actually, maybe we could just make the report more clever.
<bjf> i was thinking that as well
<infinity> If it could group things in related units, so the base/meta/lbm/signed were always together.
 * rtg -> lunch
<herton> apw, yes shank bot should be covering the signed packages only for quantal and later now
<herton> we will need to update this though on the backport for precise and may be precise when it's done there too
<infinity> apw: When is the first kernel upload for raring going to happen, BTW?  Trying to decide if I should care about copying qunatal SRU kernels to raring, or just leave it be.
<infinity> ogasawara: ^
<ogasawara> infinity: I say just leave it be, we just rebased to v3.7-rc4 today so I suspect we'll attempt an upload of this soon baring anything catastrophic
<infinity> ogasawara: Shiny, thanks.
<infinity> ogasawara: If some dreadful security vuln shows up in the next SRU cycle and R still doesn't have its own kernel, I'll reevaluate. :P
<bjf> rtg, rc4 working ok on my macbook air
<bjf> rtg, also on SandyBridge HEDT
<jdstrand> jjohansen: hey, so this linux-lowlatency, is that a supported kernel (ie, it gets USNs)?
<jjohansen> jdstrand: no, its community supported
<jdstrand> jjohansen: so, how does that work with the process?
<jdstrand> ie, the cadence process
<jjohansen> jdstrand: its just not part of the process, they rebase on our kernels
<jdstrand> oh I see. it is entirely driven by them. cool
<jdstrand> jjohansen: thanks
<arges> jsalisbury, hi
<jsalisbury> arges, hey
<arges> jsalisbury,  were you able to re-open the upstream bug for bug 922906
<ubot2`> Launchpad bug 922906 in linux (Ubuntu) "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [High,Triaged] https://launchpad.net/bugs/922906
<arges> jsalisbury, i was going to start investigating this a bit more
<jsalisbury> arges, I wasn't able to, I didn't have the appropiate premissions
<arges> jsalisbury, ok should i reopen after i take a look at it a bit?
<jsalisbury> arges, I noticed Ben Hutchings requested that it get reopened as well, but never got a respnse
<arges> i mean file a new bug not re-open
<jsalisbury> arges, sure, that may get it moving again
<jsalisbury> arges, there were a couple of discussions on LKML about it as well, but none ever went anywhere.
<jsalisbury> arges, I think it was left off around March of 2011
<jsalisbury> maybe april
<arges> ok i'll get more data first
<jsalisbury> arges, I think henrix and apw also looked at this for a while and there was even a test kernel.
<jsalisbury> arges, Actually there was a fix upstream on fsdevel: http://marc.info/?t=130806561400010&r=1&w=2  I don't think it was ever picked up in mainline though.
<arges> jsalisbury, yea i'll have to dig on this a bit more
 * rtg bugs out
<bjf> ogasawara, i just boot tested rc4 on two server systems, it's up on both however, the emerald ridge system has no video and lots of backtrace in the dmesg
<ogasawara> bjf: ack
<akhileshss> Hi, I am trying to add a new system call to kernel 3.6.5. I followed the steps here: http://goo.gl/f0hk7 . But I hit the error "arch/x86/built-in.o: â¦: undefined reference to "sys_foo".  I am trying to put new sys call foo. Can anyone help me figure out what is missing ?
<bjf> ogasawara, i tested rc4 on 7 systems, only the one had any issues
<ogasawara> bjf: ok good to know.  are you able to pull the logs from that emerald ridge?
<bjf> ogasawara, sure, it's up and running if anyone wants to also poke at it
<ogasawara> bjf: I'll sync with rtg in the morning about debugging it
<bjf> ogasawara, it's "statler" in the lab
<ogasawara> bjf: ack
#ubuntu-kernel 2012-11-06
 * apw grumbles about PPA builders
 * apw needs more instant gratification
<caribou> hi, would there be any reason against having hpwdt (watch dog timer) module built for Precise ?
<caribou> it's being built for Quantal but not for Precise
<caribou> apw: any thought on building hpwdt for Precise ? I'm testing a build right now
<apw> caribou, if it is hardware specific (ie loads only on specific machines) and we can test it on those machines then it likely would be SRUable
<caribou> apw: not sure if it is H/W specific, but it will only be usable with system equiped with iLO I think
<caribou> apw: since we now build it for Quantal, I thought it would be also possible for Precise
<caribou> apw: I'll test my kernel on the proper h/w and will report back
<apw> caribou, yeah sounds reasonable, if we can regression test it, and there are not heaps of reports pointing at it in Q then its not sounding very high risk indeed
<caribou> apw: ok, I'll let you know what I find, thanks
 * henrix -> lunch
<bjf> apw, moin, is mumble down?
<apw> bjf, seems to work for cking and me.
<bjf> sigh
<apw> bjf, i don't see you on server
<bjf> apw, server won't take the saved password (which hasn't changed forever)
<apw> bjf, did you enable 2-factor ?
<bjf> not recently
<rtg> bjf, you're back in the states by now, right ?
<bjf> was working just fine yesterday
<apw> not that then
<bjf> yes, back in the states
<apw> i see leann, but not you
<rtg> I've been waking up at 0430 as well
 * apw pokes rtg to try logging in
<rtg> apw, I'm in the living room right now. I'll migrate downstairs in awhile
<apw> ack
<rtg> apw, my house is so big that it takes awhile to hike down to my office :)
<apw> *slap*
<bjf> it's something he has to commit to doing
<bjf> he doesn't want to make the long trek back and forth if not necessary
<rtg> bjf, speaking of commits, home come Oneiric/Precise master-next branches aren't building ?
<rtg> how come*
<rtg> hmm, ARCH_RANDOM is new
<bjf> rtg, don't know, haven't looked
<rtg> bjf, I'm fixing them....
<bjf> rtg, who's been pushing broken shit on my trees?
<rtg> bjf, gotta be one of your guys.
<bjf> rtg, we know it wasn't henrix, i know it wasn't either me or sconklin so that just leaves ...
<rtg> bjf, looks like 2 new config options appeared with the last stable update, CONFIG_ARM_ERRATA_775420 and CONFIG_ARCH_RANDOM
<bjf> hmmm
<rtg> I'm assuming stable wants them enabled
<bjf> i guess
<herton> bjf, rtg, probably was the stable updates I pushed yesterday
<rtg> herton, yep, I'll have it done in a few minutes.
<bjf> herton, did you build test them?
<herton> no
<herton> rtg, while you're on it, I think you can remove that via6656 module enable patch on master-next as well, since you saw it doesn't work on 64-bit
<herton> I saw it yesterday, but was already late, so sent an email about it
<rtg> herton, was that just Quantal ?
<herton> rtg, no, you applied it on Precise too
<herton> rtg, forget, it was quantal indeed
<rtg> herton, yep, just found the email
<herton> rtg, gahhh, I was looking at wrong branch, it's really on precise, commit 72b07b241819c0320c0def2376645bd27339655c
<herton> on master-next
<herton> I knew I saw it yesterday, I'm not going crazy :)
<rtg> herton, good, 'cause I couldn't find it in Quantal.
<herton> rtg, yes, I think on quantal you just didn't applied in the end
<rtg> herton, if tis driver is so bad, should we even bother with 32 bit ?
<herton> rtg, for me it's ok just disabling it, after all we have it disabled for some time already
<rtg> the only reason I looked at it is 'cause some folks were casting aspersions on us
<herton> in that case may be we want to enable the 32bit version, or just state the driver is broken anyway
<rtg> I'm inclined to leave it disabled until the upstream fix is merged (and I'm not seeing anythig so far). Perhaps I'll turn it on in raring. there has been a little activity since v3.6
<rtg> herton, ^^
<herton> yeah, agreed
<rtg> herton, pushed precise master-next
<herton> ack
 * rtg vows not to watch the news today
<arges> rtg, hello. can we get libncurses5-dev installed on gomeisa ?
<rtg> arges, in a chroot or in the default host environment ?
<rtg> arges, I'm pretty sure the chroots have it
<arges> rtg, hmm 'fakeroot debian/rules editconfigs' seems to complain 
<caribou> rtg: just that I tried to run fakeroot debian/rules editconfigs and it complained about the missing pkg
<caribou> rtg: maybe there's a better way of doing it
<rtg> caribou, have you tried it from within a chroot ?
<rtg> rtg@gomeisa:~$ dpkg -l |grep libncurses5
<rtg> ii  libncurses5                      5.9-4                                   shared libraries for terminal handling
<rtg> rtg@gomeisa:~$ dpkg -l |grep libncurses5
<rtg> ii  libncurses5                      5.9-4                                   shared libraries for terminal handling
<caribou> rtg: nope, maybe that's what is missing
 * caribou must learn the best way to build kernels on those build servers
<rtg> caribou, I've got nearly every chroot within the Ubuntu hegemony installed on the buildds
<arges> caribou, 'schroot -c quantal-amd64' then type 'fakeroot debian/rules editconfigs'
<arges> thanks rtg 
<caribou> rtg: :) ok, I'll do that
<rtg> np
 * ogra_ has some license fun for the kernel team ... added in bug 1075549
<ubot2`> Launchpad bug 1075549 in linux-firmware (Ubuntu) "please include fw_bcmdhd.bin and bcm4330.hcd in linux-firmware for support of the nexus7" [High,New] https://launchpad.net/bugs/1075549
<ogra_> :)
<rtg> ogra_, its all about licensing....
<ogra_> yeah
<rtg> ogra_, first roadblock :
<rtg> echo
<rtg> echo The license for this software will now be displayed.
<rtg> echo You must agree to this license before using this software.
<rtg> echo
<rtg> I hate shrink wrap licenses
<ogra_> do we have any broadcom contacts we could ask about a fix of that ? 
<rtg> ogra_, you should be talking to vanhoof about that
<ogra_> i was actually surprised that even works ... 
<ogra_> shell script with binary blob inside
<rtg> ogra_, majorly, totally ugly
<ogra_> ++
<caribou> rtg: looks like I need some special setup to use schroot : E: Access not authorised
<rtg> caribou, log out completely, then back in and retry
<caribou> rtg: will do sir.
<rtg> you were not in the sbuild group
<caribou> rtg: works fine, thanks !
<rtg_> bug 1019025
<ubot2`> Launchpad bug 1019025 in ubuntu-online-tour (Ubuntu Quantal) "Ubuntu Tour menu becomes unreadable when interrupting a tutorial" [Undecided,New] https://launchpad.net/bugs/1019025
 * herton -> lunch
 * ogasawara back in 20
<herton> apw, I commited the task assignments for shank bot on lowlatency bugs, this is the example of what it will look like: https://bugs.qastaging.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/939627
<ubot2`> Launchpad bug 937132 in Ubuntu Single Sign On Client stable-3-0 "duplicate for #939627 ubuntu-sso-login crashed with RuntimeError in /usr/lib/python2.7/dist-packages/gi/overrides/Gdk.py: Gdk couldn't be initialized" [Undecided,Fix committed]
<apw> herton, yeah later the promote-to-proposed will likely be something they do, but yeah that looks like the right thing
<apw> herton, cirtainly as close as it can without trying it out
<ogasawara> bjf, sconklin: mumble?
<sconklin> sure
<Theodoros> I found an issue with the 'Quantal kernel for precise' testcase http://packages.qa.ubuntu.com/qatracker/milestones/223/builds/25321/testcases
<Theodoros> Running with the quantal kernel from the ppa causes panics and coredumps in samba
<apw> Theodoros, sounds bad, could you file a bug and attach any logs you have
<apw> (and let us know the number)
<Theodoros> sure
<Theodoros> I was wondering if 3.5.0-18.29 was going to hit the PPA/repositories so I could test that
<Theodoros> Since it recently left proposed in quantal
<apw> Theodoros, it is in precise-proposed now for testing
<Theodoros> Okay, I'll look into that later
<apw> i would imagine the one in the x-swat PPA will be out of date by now
<Theodoros> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1075670
<ubot2`> Launchpad bug 1075670 in linux (Ubuntu) "samba panics with sys_setgroups failed" [Undecided,New]
<balloons> ogasawara, or perhaps someone else :-), can you tell me what the kernel teams plans for the 12.10 kernel stack on 12.04? Will you continue targetting and testing on 12.10? Is it going to be a 3.5.X kernel for sure?
<balloons> I guess I'm just asking which series will be targeted by this: https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/
<bjf> balloons, there was this UDS thing where we discussed all that :-)
<balloons> bjf, I'm sure there was :-) I'm happy to look @ a blueprint if needed
<balloons> sorry I missed the discussion!
<bjf> balloons, there is a quantal lts-hwe kernel for precise
<bjf> balloons, quantal is 3.5
<bjf> balloons, there will be a raring lts-hwe kernel for precise (raring will be 3.8)
 * rtg grinds through the endless LKML thread "[RFC] Second attempt at kernel secure boot support"
<bjf> balloons, did that answer your question?
<balloons> bjf, yes, I saw the new raring upload
<balloons> so that menas you will keep going with the quantal lts, releasing 3.5.. and the next hwe will be on the raring kernel via 3.8
<balloons> the quantal hwe still dropping in december for 12.04.2?
<bjf> balloons, quantal-lts is officially supported for the length of support for quantal
<bjf> balloons, that is true for all non-lts kernels (after 14.04 that may change)
<bjf> balloons, yes on the point release
<balloons> bjf, sorry  I mean to say.. the quantal-lts hwe stack will enter precise at 12.04.2
<balloons> and raring will be for 12.04.3 or 12.04.4?
<bjf> balloons, whatever the schedule says :-)
<balloons> fair enough :-)
<balloons> thanks for your help
<bjf> np
<balloons> so we'll plan to ramp up some raring hwe at some point
<balloons> *testing I mean to say
 * rtg -> lunch
<chadbyoung> looking for help enabling CPU performance counters in the kernel
<ogasawara> balloons: sorry for the delay, the world has been on fire today.  I think bjf answered all your questions.
<ogasawara> balloons: but https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-xorg-lts-updates was the bp/UDS session
<ogasawara> balloons: I've also documented a lot at https://wiki.ubuntu.com/KernelTeam/Specs/QuantalLTSEnablementStack
<balloons> ogasawara, thank you
<ogasawara> balloons: let me know if you have any additional questions, I'll be happy to answer
<chadbyoung> are the room logs searchable?
<chadbyoung> by room I mean this channel
#ubuntu-kernel 2012-11-07
<Lrush> Dear all, I find fedora 17 isntall  i3-3240 CPU  platform  Huaping screen!  have test latest kernel 3.6.2-2  ,but didn't work ? who can help me ?
<Lrush> Dear all, I find linux isntall  i3-3240 CPU  platform  Huaping screen!  have test latest kernel 3.6.2-2  ,but didn't work ? who can help me ?
<apw> caribou, do you guys still keep copies of the .ddebs offline ?
<caribou> apw: I have some stashed somewhere, but not all of them
<caribou> apw: what do you need ?
<apw> caribou, damn i had rumours you were keeping them all in an automated fashion
<apw> caribou, one of the precise ones has gone missing and was wondering if you had them
<caribou> apw: I did, but when they changed how ddebs were kept, my script went haywire and deleted some (mostly Natty's)
<apw> ahh would you  have 3.2.0-32-* by any chance ?
<caribou> apw: lemme check...
<henrix> apw: what do you mean by "gone missing"?  an accident?  or they failed to build?
<apw> henrix, actually "not there now and i would expect them to be"
<henrix> apw: interesting. any idea how that could happen?
<caribou> apw: I have 3.2.0-32.51
<apw> caribou, can they all be somewhere i can pass them to pitti ?
<caribou> apw: is .51 the only one you need ?
<caribou> apw: I have the -generic, -generic-pae & virtual ones
<caribou> i386 & amd64
<apw> caribou, for now yes just .51 and those are better than none at all
<caribou> apw: what are these ? 
<caribou> apw: http://ddebs.archive.ubuntu.com/ubuntu/pool/main/l/linux/kernel-image-3.2.0-32-generic-di_3.2.0-32.51_amd64.udeb
<caribou> apw: nevermind, they're udebs
<apw> yeah ... that :)
<brendand> henrix, hi
<henrix> brendand: hey
<brendand> henrix, i see the precise kernel is just verified. are we still expected to do certification testing by tomorrow?
<henrix> brendand: we had 2 kernels (oneiric and precise) blocked by a bug verification, and i just got precise freed today
<henrix> brendand: it would be nice to have the certification during this week, i believe.
<brendand> henrix, ok - it's possible
<henrix> brendand: that would be great
<henrix> brendand: sorry for the delay
<apw> henrix, where are we with linux-lts-quantal, how far from promoting that to -updates are we?
<henrix> apw: it should be in -updates late this week
<apw> henrix, and does another cycle start monday? 
<henrix> apw: or, worst case, on monday
<henrix> apw: yep
<henrix> apw: i mean, another cycle starts on monday
<apw> yep, cool
<apw> henrix, we have a tiny patch to enable signed kernel generation on that one which we are waiting on, just wondering when we might see it in -proposed
<apw> henrix, if you could poke me when the current one promotes that would be great
<henrix> apw: sure, will do
<apw> as i might sneak an upload (for -proposed only) in immediatly; which would just be the same with that patch
<apw> it would not need testing or promoting to -updates or any of that jazz, and would be replaced when you do your normal uploads for the cycle
<henrix> apw: ok, cool. maybe we can get jjohansen and infinity to have the current one on -updates today
<apw> henrix, that would rock, i only care about lts-quantal the others are not blocking us at all
<apw> henrix, if i wanted to upload something like this, i assume i would not put a tracking bug in it
<apw> henrix, as it is not an SRU or indeed destined for anywhere, and i believe your tooling would just cope as it tells you the -vVERSION to use when making the src package
<henrix> apw: no, tracking bugs are generated using a script, i.e., it has to be manually executed
<henrix> apw: so, i guess that would be fine
<apw> cool
<apw> i will discuss with you all (bjf, herton etc) again later to make sure people are happy
<henrix> apw: sure. in the mean time, i'll try to have it promoted to -updates today
<apw> henrix, thanks indeed
<rtg> apw, do you intend to create ubuntu-precise-signed.git ? I'm wondering if we shouldn't collapse all of the '-signed' repos into ubuntu-signed.git in order to cut down on the proliferation of the small repos.
<rtg> of these*
<ogra_> rtg, hey, i found some differently licensed firmware files for bug 1075549, linked it  in the last comment
<ubot2> Launchpad bug 1075549 in linux-firmware (Ubuntu Raring) "please include fw_bcmdhd.bin and bcm4330.hcd in linux-firmware for support of the nexus7" [High,In progress] https://launchpad.net/bugs/1075549
<rtg> ogra_, ack
<rtg> ogra_, if it is appropriately licensed then why not just have Jani include it with the N7 kernel ?
<ogra_> well, i suspect we'll have more devices using such a chipset in the future
<ogra_> so linux-firmware seemed appropriate 
<ogra_> we'll surely have more android device support in the near future and will likely need firmware even beyond broadcom
<apw> rtg, i was intending on that indeed.  to be inline with -meta
<rtg> ogra_, I'll be doing the raring linux-firmware filtering against kernel MODULE_FIRMWARE() useage soon. Perhps that binary will pop up as being used by the kernel but not provided by linux-firmware.
<ogra_> technically it doesnt make any difference where its shiupped indeed
<apw> rtg, i should probabally do that for now, and we can revisit whether there should be a -meta.git and a -signed.git as you have for firmware
<ogra_> as long as the driver finds it in the instaled system
<apw> rtg, as a separate action
<apw> rtg, as indeed right now it would be a strange -signed as it won't have a master
<rtg> ogra_, for now why not include it with the N7 kernel. If I find its in wide use then we can always populate linux-firmware
<ogra_> rtg, alternatively someone could try to get brcm80211 on the nexus, thjey claim to support our chip 
<ogra_> i didnt manage to though
<rtg> apw, I'm just thinking these gizmos would be easier to manage if they were in a common repo.
<apw> rtg, i cannot deny bootstrapping a local copy is a pain in the ass
<apw> rtg, though once you have them there is little to differentiate them for me
<rtg> apw, also updating your local repo is easier since you only have to fetch one origin
<apw> rtg, there is slight advantage when one is doing what i am now, backporting features to have them separate
<apw> rtg, but there is also nothing to prevent me having 3 clones of the same repo ...
<ogra_> rtg, as i said, trechnically i dont care where it is shipped, l-f just seemed appropriate since a have a policy to get evereything for the device properly in the distro (like we would do with any x86 based device) 
<apw> rtg, if we merge this one, we should merge -meta as well
<rtg> apw, agreed
<apw> rtg, ok for now then i will play with it merged here and see how that works
<rtg> apw, we should first make sure we don't cause herton problems with maint scripts
<apw> rtg, i assume we use precise as 'master from precise'
<apw> rtg, ok ... as it is easy to merge un-merge i'll proceed as i am then
<apw> and engage with -stable on it.  it will break all the preproposed stuff if i mangle meta etc so
<apw> some planning is needed
<rtg> apw, I kind of wish we'd done this years ago.
<apw> well it doesn't work for linux anyhow because of tag overlaps i believe
<apw> but for the non-linux repos it is a reasonable plan
<rtg> apw, right, but the other repos shouldn't
<apw> rtg, and the tagging should be fixable postumously
<apw> if we ever cared to do it
<rtg> that would _really_ cause herton problems
<apw> heh i am sure it would :)
<apw> though the great things about signed tags is they can point to tags, so we can even preserve them old ones without maintaining the names
<apw> as i do for the u* series
<janimo> rtg, hi, is shipping firmware blobs in the kernel package being done by any other kernel flavour that I could look at? Would shipping in an entirely new package be ok as well as long as it is not linux-firmware?
<rtg> janimo, have a look at the Quantal LTS branch in precise.
<rtg> janimo, since firmware tends to track kernel versions I've been packaging firmware with the kernel when it isn't already provided by linux-firmware
 * rtg fixes 'BUNTU: [Config] CONFIG_USB_OTG=n for all but armel/armhf' typo in raring
<apw> rtg, i note we are using lts-backport-<series> for branch names regardless of name of the source package
 * apw follows this for -signed
<rtg> apw, right, since I started the naming convention quite some time before 'backport' became a dirty word.
 * henrix -> SIGFOOD
<arges> smb, caribou : somebody could be using this: http://moss.csc.ncsu.edu/~mueller/cluster/ps3/
<janimo> rtg, apw has the possibility of using dpkg source format 3.0 for kernels ever come up?
<janimo> just thought of that as it makes shipping blobs inside the package saner
<rtg> janimo, how about a patch explaining the advantages ?
<janimo> rtg, I'll try it on the nexus7 kernel first then see. Advantages should be about the same as for any other package that has witched
<ogra_> rtg, multiple upstream tarballs
<janimo> ogra_, upstream is a rolling git , so kernel may be special in that regard
<ogra_> janimo, well, packages use a tarball still :)
 * rtg will be back on in a bit
<ogra_> no matter how well your VCS rolls them ;)
<janimo> ogra_, one thing I could use though is not uploading 100Mb with each slight packaging change. But that is more of a native vs not distinction, not 1.0 vs 3.0
<janimo> anyway, trying that on nexus kernel now
<rainman> where can I get the details of power management protocols instructed by ubuntu-kernel on multicore systems?
<BenC> http://kernel.ubuntu.com/git takes *forever* to load, FYI
<rtg> BenC, zinc is a little under powered. gitweb causes swapping
<BenC> rtg: what's the reference tree I can use to base off of for powerpc?
<rtg> git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
<BenC> Does that contain the mechanisms for having powerpc build out-of-mainline?
<rtg> BenC, I could prep something for you in an hour os so if you'd like
<rtg> BenC, it doesn't yet. 
<BenC> I'd appreciate that, thanks
<rtg> BenC, gimme awhile. I'll get back to you
<BenC> Ok
<BenC> rtg: Do I just base it off of the ti-omap4 branch and debian.ti-omap4 directory? If so, that's easy enough for me to handle
<rtg> BenC, Its gonna be a bit different, but close to the same. I'm almost there....
<rainman> Hello, I need detailed information about Linux Operating System Power Management System Code(Drivers, protocols, algorithms, strategies) on especially multi-core systems. Can some experienced one give me a hand please? Thank you.
<BenC> rainman: That could easily be a semester long 3xx level college course worth of informationâ¦maybe you can ask a specific question?
<rainman> BenC: The question is, I am making a research on optimizing power of multi-core systems. In order for me to do that I first need to know what linux does in this respect and what does it allow for user-space applications to manipulate power schemas.
<BenC> rainman: ==> www.google.com
<rainman> BenC: Thanks for the hand.
<rtg> BenC, have a look at git://kernel.ubuntu.com/rtg/ubuntu-raring.git ppc
<rtg> this branch should be a strightforward rebase against raring master (eventually). I used master-next to start with.
<rtg> BenC, once you've got it building then think about enabling the doc/headers indep/libc packages. See debian.ppc/rules.d/*.mk for that.
<abogani> Is debian.powerpc too long? :-)
<BenC> rtg: thanks
<rtg> BenC, the ti-omap4 branch in Raring isn't really a good example. in fact, it may disappear if we can get a unified arm kernel working from master
<ogra_> rtg, wow, brave target ... are you prepared to double up build time ? :)
<rtg> ogra_, hey, thats just what my arm dudes are telling me....
<rtg> why would it double up build time ?
<BenC> rtg: do we really have a ppc64 port?
<ogra_> rtg, omap  and omap4 are built on pandas 
<rtg> BenC, we've been building it. dunno if anyone is using it.
<ogra_> so adding one new binary will get you one more build
<BenC> I can't see it being built because there is no DEB_BUILD_ARCH=ppc64 on ubuntu
<rtg> ogra_, it should be a wash if we can collapse arm4/5 into one binary
<BenC> We have a powerpc64 kernel build for arch=powerpc
<ogra_> rtg, we can do that already for omap ... prob here is that if we want to go on to support desktop on panda we'll have to add all the patches
<ogra_> (mainline allows a single binary kernel for omap/omap4 atm)
<BenC> rtg: I'll take care of it from here, thanks for setting up the tree
<amitk> rtg: unified arm kernel was just a demo last week, there are still several problems to solve in real-life to get it into production
<rtg> BenC, np. IIRC we pared down the powerpc flavours to just powerpc64-smp since it will also run on a UP
<rtg> powerpc64*
<rtg> amitk, so, you don't sound optimistic.
<BenC>   * ppc64 -- add basic architecture
<BenC> Added by Andy Whitcroft for 2.6.38 Feb/2011
<rtg> BenC, I get lost in the acronyms for the power arch. ppc64 is different then powerpc64 ?
<amitk> rtg: for R? A single fully-functional kernel for all your ARMs? I'm not. As they say in the single zImage world - it's not about the destination, it's about the journey. :)
<BenC> rtg: yeah, it's a target for building a native 64-bit powerpc target (full userspace and such) that Debian supports, but we only have 32-bit powerpc userspace port, with 64-bit (powerpc64-smp) kernel
<rtg> amitk, then I suppose I should get paolo bringing the ti-omap4 branch up to snuff.
<rtg> BenC, ok, then that would be the fallout from an OEM deal that never panned. AFAIK we're only building the arches in debian.ppc/rules.d
<amitk> rtg: he should talk to the architects of that work in Linaro, but yes, I'd do that.
<BenC> Ok, I'll ditch it for now until I have a port to actually work on
<rtg> BenC, cool. I'll consider it all your'n for now.
 * ogasawara back in 20
<StFS> Hi. I was hoping that 3.5.0-18 would have my alsa patch but it doesn't seem like it does. Is there a way for me to figure out what ubuntu kernel will include the patch for this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1060372
<ubot2> Launchpad bug 1060372 in linux (Ubuntu) "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,In progress]
<rtg> bjf, can you try vanilla mainline 3.7-rc4 on that emerald ? 'PERCPU: allocation failed' seems pretty heinous.
<bjf> rtg, sure
<BenC> rtg: FYI, debian.ppc/config/enforce does not override debian.master/config/enforce. Should I just remove the latter?
<BenC> Err, former
<rtg> BenC, that sounds right. apw ^^
<rtg> BenC, I likely copied it by accident.
<BenC> Np
<apw> rtg, BenC, indeed it just uses master version and deliberatly so.  if you need to change it do patch that file, but also send it back to us so we can record it as part of our requirements
<BenC> Will do
<apw> (and fold it back into the master version)
<BenC>     CC perf.o
<BenC> In file included from util/../perf.h:29:0,
<BenC>                  from util/cache.h:7,
<BenC>                  from perf.c:12:
<BenC> util/../../../arch/powerpc/include/asm/unistd.h:12:29: fatal error: uapi/asm/unistd.h: No such file or directory
<BenC> rtg: I'm seeing that when I kick off the build.
<BenC> arch/powerpc/include/uapi/asm/unistd.h does indeed exist
<BenC> Are you seeing that on other architectures?
<rtg> BenC, I'm just building arm (which has a ways to go), so I'm not sure yet. I may have disable perf for all but x86en.
<BenC> Disabling do_tools for now
<smooth-texan> Where can I download older versions of the Ubuntu kernel?
<infinity> smb: Your email seemed to lack the footnote you referenced. :P
<infinity> smb: So, I'm not sure precisely which package you're referring to.  But, if it really is "useless" as-is, that's a pretty valid justification for an SRU, and if backporting the whole thing is more readily verifiable and sane than cherry-picking patches, we'll need to look at doing it that way, yes.
<BenC> rtg: So for meta, I'm just creating a whole new standalone package, right?
<rtg> BenC, yep. you could start with raring-meta from a few commits ago (before ppc was removed)
<BenC> Ok
 * rtg -> lunch
 * henrix -> EOD
<rtg> apw, just pushed ubuntu-raring-signed. please review before I upload it.
<arges> infinity, I think he was referring to bug 1064475
<ubot2> Launchpad bug 1064475 in crash (Ubuntu) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress] https://launchpad.net/bugs/1064475
 * ogasawara lunch
<bjf> rtg, same results with the mainline kernel
<BenC> ogasawara: Any thoughts on moving powerpc specific kernel bugs to the new linux-ppc package?
<ogasawara> BenC: that works for me.  Is that package in the archive yet?  /me is not seeing it
<BenC> Not yet
<BenC> rtf branches for me today and I'm still in the process of testing the builds
<BenC> *rtg
<ogasawara> BenC: ack, lemme know when it's there and I'll have jsalisbury migrate existing bugs
<BenC> Great, thanks
<jsalisbury> ogasawara, BenC, ack
<infinity> Oo, new kernels.  Yay.
<infinity> BenC: Where is this PPC kernel maintenance going to be happening?  With a community hat on, I might want to get in on that action, should you ever drop the ball on a rebase or something. :P
<infinity> (Plus, I want to learn apw's new world order of out-of-tree maintenance)
<BenC> infinity: I have it on github. What email can I forward the info to you?
<BenC> Sent info to ubuntu-powerpc and kernel-team, but I suspect you may not be on either of those
<infinity> BenC: I'm on the latter, but I don't read it often.
<infinity> BenC: But sending to adconrad@whatever will do fine.
<infinity> BenC: You could also pre-emptively give me commit on the github project. ;)
<BenC> Is that adconrad as well?
<BenC> infinity: You could just fork it and send pull requests :P
<infinity> BenC: Looks like.
<infinity> BenC: If I'm doing scary things, fork and pull makes sense.  If I'm doing things I intend to actually upload (rebases, security updates, whatever), I'd rather the master repo match the archive.
<BenC> infinity: you've been added to the kernel and meta packages
<infinity> Danke.
<infinity> I don't intend to use this power, except in anger.
<infinity> But if you fall behind, I want my PPC kernels to match my x86 kit. :P
<BenC> Your vengeance is likely better than most people's whole-hearted attempts at chipping in
<rtg> bjf, ack. I'll work on it tomorrow.
 * rtg -> EOD
#ubuntu-kernel 2012-11-08
<smb> infinity, Argh, I should add those at the same time as I add the index number. I do not seem to be able to remember long enough to finish a paragraph in between.
<smb> ... and morning, btw
<smb> https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1064475
<ubot2> Launchpad bug 1064475 in crash (Ubuntu) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress]
<dupondje> disabling my VGA card with switcheroo, and then unloading the module causes a cpu hang :s
<dupondje> bleh :)
<apw> (flavour powerpc-smp &/ value CONFIG_NVRAM y) | \
<apw>  value CONFIG_NVRAM m | \
<apw>  !exists CONFIG_NVRAM | \
<ubot2> apw: I am only a bot, please don't think I'm intelligent :)
<apw>  value CONFIG_NVRAM y
<apw> ubot2, given the the dumb things you say and do, trust me i don't
<ubot2> apw: I am only a bot, please don't think I'm intelligent :)
 * apw sighs
<cking> perhaps we need a predicate to english translator :-)
<apw> <-- predicate to UK engish translator
 * cking sees a job for life
<cking> http://en.wikipedia.org/wiki/Ternary_logic
<cking> http://en.wikipedia.org/wiki/Balanced_ternary
<smb> http://en.wikipedia.org/wiki/Fuzzy_logic
<cking> apw, what about this https://bugzilla.redhat.com/show_bug.cgi?id=811227
<ubot2> bugzilla.redhat.com bug 811227 in libvirt "RFE: Ability to specify custom BIOS for QEMU/KVM using <loader> XML (for WHQL testing)" [Unspecified,Closed: errata]
<smb> http://libvirt.org/formatdomain.html
<smb> http://www.redhat.com/archives/libvir-list/2009-September/msg00001.html
 * henrix -> lunch
<xnox> Do we ship ndiswrapper in generic ubuntu kernels?
<xnox> the package says that it is provided, yet lsmod does not show ndiswrapper, nor modprobe -r ndiswrapper work on the LiveCD without network access.
<rtg> xnox, indeed we do not provide ndiswrapper
<xnox> rtg: can you figure out _when_ you stopped doing this?
<rtg> xnox, its been awhile. lemme check
<xnox> rtg: cause it means I have an argument on ubuntu-devel to drop ndiswrapper tools from the CD \0/
<rtg> xnox, we disabled ndiswrapper in Precise (3.2.0-1.1)
<xnox> rtg: interesting. And why / how come?
<rtg> xnox, ogasawara dropped it completely as of 3.2.0-17.26, but there are no notes in the changelog as to why.
<rtg> likely because its now a DKMS package ?
<ogasawara> rtg: yep, dkms if I recall correctly
<ogasawara> rtg: and I thought we'd dropped it a few releases ago actually
<xnox> ogasawara: rtg: ok. since it's dropped, can you drop the provides from the linux-image package?
<xnox> do you need a bug for that?
<rtg> xnox, that would be good for an SRU
<xnox> ack.
<ogasawara> xnox: yes please.  it'll make sure it stays on our radar and is useful for SRU paperwork
<xnox> ogasawara: rtg: bug 1076395
<ubot2> Launchpad bug 1076395 in linux (Ubuntu Raring) "ndiswrapper module is not provided any more" [Low,Confirmed] https://launchpad.net/bugs/1076395
<ogasawara> xnox: thanks
<xnox> after checking ndiswrapper there is dogpile of bugs along the lines "ndiswrapper module is missing"
<xnox> *sigh*
<rtg> ogasawara, I can crank those out if you wish. I'm kind of idle  waiting on arm test builds.
<ogasawara> rtg: sweet, its all yours then
<ogasawara> rtg: I've been hammering on these haswell patches.  I've got the v3.6 and v3.7 ones applied, but of course the i915 driver is then oopsing on load.  so am digging further.
<rtg> ogasawara, have fun with that :)
<BenC> rtg: will the master package still build linux-libc-dev on powerpc? I ask because when I enable it on .ppc it errors out saying that it's not supposed to build outside of the master build
<rtg> BenC, I would think it ought to be provided by your source package.
<rtg> apw, whaddya think ? ^^
<BenC> echo "non-master branch building linux-libc-dev, aborting"
<BenC> What is going to happen on powerpc when it tries to build master? Maybe it will actually produce the package?
<rtg> BenC, I don't think it will. I was just checking, but it looks like _all_ support for powerpc has been removed except for the config enforcer.
<BenC> I'm going to checkout master-next and see what it does when I run binary-arch...
<apw> yeah that is in there to stop derivatives producing them ... i note that we did used to produce them linux-libc-dev for arm
<rtg> BenC, if there is no rules file in debian.master/rules.d/ for power, then it ain't gonna do nothing.
<apw> even when we did not have arm in our package flavour wise.  perhaps it makes sense for us to do the same here
<apw> as getting versioning wrong on that is fatal across the board
<apw> rtg, so perhaps we should have a flavour free powerpc in ours to make that
<BenC> I would suspect that is the ideal solution
<BenC> I can create the commit for that and send a pull request when I can test that it works as expected
<apw> something similar to what we have just done for aarm64 should be sufficient
<apw> in theory at least
<rtg> BenC, works for me
<apw> BenC, thanks, did you see my update to your enforcer patch
<BenC> What is the plan of action for ABI handling in this package? Should I just hold off anything I do that causes an ABI bump until one is incremented in master?
<BenC> apw: I did, thanks
<apw> i appologise in advance for the opacity of the syntax
<apw> infinity, did i not see you dropping the dkms headers linkage during UDS ?
<apw> ogasawara, rtg, i have spun through the main blueprints and kicked them into shape, copied out the work-items and moved them approved and the like
<rtg> BenC, ABI handling for a separate source package should be independent of master, right ?
<ogasawara> apw: thanks
<apw> rtg, that reminds me, does ppc produce a common headers or share ours ?
<BenC> So if I bump the ABI in powerpc, it won't cause any random conflicts with master, but how do I detect that master ABI bumped and then also ABI bump my side?
<rtg> BenC, after you rebase and build ? if thereis an ABI change then the ABI checker should catch it.
<apw> rtg, as if it shares ours it needs to be insync abi wise, if not, then the common headers needs to be renamed or have a different avi series
<apw> abi
<rtg> apw, maybe thats why ppc should produce its own header packages
<apw> Package: linux-headers-3.7.0-0
<apw> not linux-libc-dev, that should be ours, but the common headers
<apw> that needs to be a differnt name
<rtg> linux-headers-ppc ?
<apw> rtg i think it should ve SRCPKG-headers
<apw> or whatever the sub variable is
<rtg> apw, what  are you doing for rt ?
<rtg> or lowlatency rather
<apw> rtg, right now they are sharing our headers, which we need to fix anyhow
<apw> else they will prevent our kernel getting out of -proposed
<apw> BenC_, hi
<rtg> apw, ok, then the same for ppc
<apw> BenC_, ok i think there is a bug here.  we need to change the link from linux-headers-PKGVER-ABINUM-FLAVOUR from Depends: linux-headers-PKGVER-ABINUM -> SRCPKGNAME-headers-PKGVER-ABINUM
<apw> BenC_, and change the name of it in stub to the same
<apw> so that it produces non-overlapping common headers naming
<BenC_> Ok
<BenC_> makes sense
<rtg> and fix your meta accordingly
<apw> else you and we will argue over common headers and bad poop will happen
<BenC> right
<apw> rtg, i don't think that file is mentioned in meta anywhere
<BenC> bad poop is never good
<apw> it is not the names of the per-flavour ones, just the shared common one
<apw> rtg, you going to reneable the linux-libc-dev in our packaging yes ?
<BenC> It is only mentioned in the linux-headers-*-FLAVOUR depends
<apw> BenC, right, so i think that is the only one we can clash with
<apw> as flavour names are necessarily unique otherwise the installer gets all miffed
<apw> BenC, perhaps once you have done that you could build a set of packages and put them somewhere so we can review thats the only issues -- before we upload them and break the archive :)
<apw> we made a bit of a pigs ear of lucid this way
<BenC> No problem
<BenC> apw, rtg: Same pull request as the last change will get the enablement of linux-libc-dev headers for master branch
<BenC> That's all it builds
<apw> BenC, thanks ... 
<rtg> BenC, got it
 * apw lets rtg handle it
<rtg> apw, I'm gonna upload to the c-k-t de-virt PPA first to make sure we've got the powerpc bits correct.
<rtg> I also put the whammy no +master-next to put Ubuntu-3.7.0-0.4 at HEAD
<rtg> s/no/on/
<StFS> does anybody know of a way to make apt prefer a locally installed package rather than a package with the same version number from the repository?
<StFS> woops... probably the wrong channel... although in my defence the packages _are_ the kernel packages ;)
<apw> StFS, heh you would likely get more help elsewhere indeed.  i think the term for that is 'apt pinning' though quite what incantion you would need is beyond my apt foo
<StFS> ok, I'm sorry if this next question was already answered (I got logged out before I noticed one at least), but I submitted a patch to a bug a little while back which got applied and I was told it would show up in the Ubuntu kernel. However, the last kernel from the repo (3.5.0-18) does not seem to have this fix. Is there a way for me to see when my patch will end up in the official ubuntu kernel? The bug in question is this one: https://bugs.launchpad
 * ogasawara back in 20
<apw> StFS, seems the bug number got truncated here
<apw> rtg makes sense
<StFS> here it is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1060372
<ubot2> Launchpad bug 1060372 in linux (Ubuntu) "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,In progress]
<apw> StFS, it does seem to be applied to quantal's master-next
<apw> StFS, so it will be in the next kernel which hits proposed, which would be wrapped up sometime next week in the normal flow of things
<apw> StFS, and it is pending for the first upload to raring as well.  so nearly there
<StFS> apw: awesome :-) thanks.
<StFS> apw: just out of curiosity (mostly), can you tell me how to figure this out myself? you know, teach a man to fish and all that :-)
<apw> i've updated the bug to indicate the same.  you should watch the bug for quantal as you will be asked to confirm the -proposed kernel as built works for you
<apw> i am looking at the kernel git repositories and looking for the patch by bug number
<apw> http://kernel.ubuntu.com/git under ubuntu/ubuntu-<series>
<StFS> ok sorry, I'm an absolute n00b here.. watch the bug for quantal? so there's another one than the one on launchpad?
<bjf> StFS, when the quantal kernel reaches -proposed, a comment will be added to the bug asking that you test that kernel to verify it fixes the issue
<apw> StFS, heh, no that bug is the right one -- note it ha two tasks now, one for quantal and one for raring
<apw> as bjf says there will be a request in your bug there
<bjf> StFS, if we do not get a verification, we will revert the commit
<apw> jsalisbury, hmmm when you did the patch for bug #1060372 you didn't use the BugLink: format, so it will not close the bugs out correctly ... you'll have to monitor and do that manually ...
<ubot2> Launchpad bug 1060372 in linux (Ubuntu Quantal) "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,Fix committed] https://launchpad.net/bugs/1060372
<apw> jsalisbury, for mainline, you can use it even there
<jsalisbury> apw, so any patches send upstream should also contain the BugLink line?
<rtg> jsalisbury, that is ideal
<apw> jsalisbury, there is no harm indeed.  then when we get the fixed via mianline or stable we find out
<StFS> bjf, apw: ok awesome... I'll wait for that comment and verify as soon as it appears
<jsalisbury> rtg, apw, got it.  I'll be sure to include it from now on
<apw> jsalisbury, for upstreaming i tend to include it in the s-o-b area so it tends to get left alone
<jsalisbury> apw, ack. 
<rtg> apw, https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/3967077
<apw> looks good rtg 
<rtg> apw, I'm about uploading BenC's branch as well.
<rtg> to the PPA I mean
<rtg> I'm thinking*
<rtg> can't freaking type today
<apw> rtg, as we might kill the PPA if its wrong, i'd wait till we see benc's builds
<apw> i'd hate to have to respec that PPA
<rtg> apw, can't we just delete the packages ?
<apw> if the version are wrong and higher than we want, its just as irrevokable as the main archive, i am told
<rtg> well, that doesn't provide much isolation
<apw> now i can't say as to having tested that of course
<apw> but that is what i am told.  that the version cannot be lower bit still exists
<apw> you can zap a ppa and remake it, and for any other PPA that is easy, but that one, not so much
<rtg> apw, if versioning carnage were possible then anyone could wreak havoc on the archive
<apw> rtg, i am not saying it breaks the archive, i am saying you could break the PPA itself
<rtg> apw, hmm
<apw> rtg, they are very archive-esk in design
<apw> if davis wasn't broken i'd suggest building there
<apw> but with 4 flavours you are going to be in a world of pain either ways
<rtg> apw, I thought infinity provisioned a new poerpc porter, or was that just a buildd ?
<rtg> powerpc*
<apw> rtg, hmmm, a good point indeed
<infinity> rtg: No, davis is the only porter.  It's dead?
<apw> infinity, it was yesterday indeed
<apw> it looks to be back today
<apw> infinity, is it still the same sluggard it has always been?
<infinity> It's not magically turned into something better than an Xserve.
<infinity> apw: Also, yes, I dropped the dkms->headers dep.  Is this having a sad somehow?
<apw> infinity, no there is a work item in your name for it, i'll close it
<apw> infinity, done
<apw> infinity, i also added that Suggests: link for raring for our first upload
<infinity> apw: image suggesting headers?  I was going to test that that actually does what I want it to do (keeps the headers installed on autoremove), but it certainly doesn't hurt, and feels like a sane suggests anyway.
<apw> infinity, indeed, well it helps to have some old kernels with it, so i'll let it be
<infinity> apw: I'd suggest that the suggests should be a recommends (which would definitely have the desired effect), but minimalist folks would probably scream about having to install kernels with --no-install-recommends then. :P
<infinity> rtg, apw: Is someone on top of fixing the raring kernel on ARM?
<apw> infinity, fixing ?
<rtg> infinity, test building on non-virt PPA right now
<infinity> rtg: Yay.
<infinity> And if it weren't the for LP bug preventing me from seeing /builders, I'd know that.
<rtg> infinity, its still grinding away in https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages
<apw> ahh its in, woopeedoo
<infinity> Does this upload include the discussed -generic image for ARM, or will that happen later?
<rtg> infinity, somewhat later (if at all). amitk was not very optimistic.
<infinity> (Granted, it would be a generic with one platform, since we dropped highbank, but whatever, I don't want to fight that political battle today, I just want the bits in place some time)
<infinity> rtg: Alright, fair enough.  Just want to know what I need to mangle in d-i.  So, for now, I just need to drop highbank from d-i, and the rest is business as usual?
<infinity> Oh, and I need to decouple powerpc from master.  Ugh.
<rtg> infinity, thats sound about right
<infinity> Yay for creating more work in the name of reducing workload. :P
<apw> rtg, ignore -signed for raring for the moment, as although i think it is ready cjwatson wants to interlock before upload in case it breaks the images
<rtg> apw, works for me. its pushed to the repo
<apw> rtg, yep all pushed just not closed out once your bits are built and in -proposed then i'll upload it to the ppa for final testing
<apw> rtg, if that build works in the PPA i assume you'll just copy it out into -proposed ?
<janimo> pgraner, USB_SERIAL=y in current nexus kernel. Is that ok for your testing lab?
<rtg> apw, works for me
<pgraner> janimo, ack
 * rtg -> lunch
 * apw wanders off out for the evening ... shock horrot
 * henrix -> EOD
 * ogasawara lunch
 * rtg -> EOD
#ubuntu-kernel 2012-11-09
<bizhanMona> hi
<bizhanMona> Hi how could I force Linux to re-enumerate the PCIe bus? thx
<the_voice_> Hi
<the_voice_> I followed the tutorial here on how to update the Ubuntu http://wiki.freeswitch.org/wiki/Amazon_EC2 here
<the_voice_> however when I go /boot/
<the_voice_> I don't see a newer version of vmlinuz-*
 * apw yawns heavily
<rainman> how do most recent linux kernels alternate the frequencies of processor and/or cores in order to save power? do they do it on the core level or the processor level? anybody has an idea?
<amitk> rainman: it depends on the processor (HW). The software can do either. It really depends on whether the cores can be scaled independently or not.
<rainman> amitk: let's say the processor allows scaling on the core level, so OSPM(operating system power management) code does individually scale cores?
<amitk> rainman: yes
<amitk> rainman: look at affected_cpus and related_cpus in the cpufreq framework code
<rainman> amitk: I am on it, thank you very much for the lead
<rainman> amitk: do you have experience on ACPI and power management by the way?
<amitk> x86 hides a lot of this behind acpi bios calls, ARM deals with the details in kernel code
<rainman> wow that's a good point
<amitk> rainman: a bit..
<rainman> so that means arm gives a lot of playability since it does the stuff in kernel code
<amitk> rainman: but current ARM-based SoCs can only do processor-level scaling (architecture limitation). I think Qualcomm, Marvell and Nvidia can do core level since they only have to be compatible and can play around with the arch
<rainman> amitk: can I humbly request a contact detail of you to ask lots of questions if you do not mind of course, I am doing a research in optimizing power on multi-core systems.
<herton> apw, do you know if am I safe cloning from linux repo on zinc under ubuntu/, for the 3.5 stable stuff? I just don't want to use it if it can be modified or be gone etc. in the future
<rtg> herton, I periodically update it, and have no plans to remove. it could be used as a ''reference for some repos
<apw> herton, thats the repo with the u* tags in it right?  if so then that is a slowly following linus branch and will never rewind; ie. it is safe to reference
<rtg> --reference (I mean)
 * smb would believe that if that is gone then zinc is gone
<herton> rtg, ack, yes I want to use it as reference, instead of cloning everything from master linus, will do thanks
<herton> apw ^
<apw> yep
<rtg> herton, have you thought about making 3.5 stable just a branch in ubuntu-quantal ?
<rtg> instead of creating yet another repository ?
<herton> rtg, I could do, but then it ties more to our kernel may be, I think just using a master linus branch and putting 3.5 in a branch would be better, don't know
<rtg> herton, then just create a 3.5.y branch in the linux repo
<herton> yes, that's my plan
<herton> rtg, ah, you mean directly in the linux repo, instead of cloning another? I could do that as well
<rtg> herton, yes
<smb> herton, The only reason I could see for a seperate tree would be people often getting confused by branches...
<smb> But then, they changed to that in upstream, too. Just with one linux-stable...
<herton> smb, yes, I think using existing linux is fine. But if we plan to maintain other versions in the future, may be we should have also a linux-stable separated
<herton> rtg, ok, so I'll create 3 branches there, 1 for the main 3.5, one for the -queue (I don't want to have a separate repo for the queue), and one for review (to announce review of the patches, alternative to who doesn't want to download the patches for review from the mailing list)
<rtg> herton, s'fine with me
<rtg> apw, it took me all freaking day yesterday to get armel to build properly, then slangasek announces armel is dead.
<apw> rtg, man you kid me ... really
<apw> so we are dopping armel in R ?
<apw> herton, sounds better than what we have for the others
<rtg> apw, https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036106.html
<apw> well i guess thats good ...
<rtg> apw, I finally have an armhf system built up 'cause the qemu-armhf gizmo on tangerine just kept faulting
<apw> yeah it does that ... pos
<apw> rtg, are we expecting powerpc uploads from BenC soon do you know ?  dropping them has put us in all sorts of britany pain
<BenC> apw: I'll be uploading today or today
<apw> BenC, great
<BenC> *tonight
<rtg> apw, why is britany complaining ? that kind of ties powerpc to the distro kernel build. wtf ?
<apw> rtg, it is complaining because our src stops making them, so migrating our package would leave us with no ppc builds at all
<apw> so it gets all whiney.  i believe once bens package is in, they will migrate as a pair this time
<apw> and once thats done they will be unlinked from each other
 * rtg grumbles
<apw> rtg, britany has a point, you are orphaning whole swathes of the archive
<apw> it doesn't know ben is sorting that out, till he uploads
<rtg> apw, we've still got a periodic parallel build failure that I'm gonna go after today. Its bitten me several times in the last couple of days.
<apw> rtg, arse, those are a royal pain, in what bit ?
<apw> (if you know)
<rtg> apw, thats the hard part.
<apw> rtg, fyi i am working on raring-meta, we have some other deps issues due to the temp disablement of the linux-tools on arm
<apw> which is also stopping migration
 * henrix -> lunch
<rtg> britany doesn't seem very flexible
<apw> rtg, her job is to stop you breaking the archive.  by dropping linux-tools a couple of package exploded
<apw> she knows what she is doing 
<rtg> apw, if I figure out the armhf tools build problem, can we just ignore armel ? (though they are likely the same).
<apw> rtg, ahh while i remember, we are missing a couple of tags for ubuntu-raring (the last two uploads) and one of the meta ones too
<rtg> apw, I just fixed the Ubuntu-3.7.0-0.5 tag
<apw> rtg, probabally, i'll find out when armel is getting zapped
<apw> rtg, i think we are also missing .4
<rtg> apw, I never uploaded the others so I didn't bother tagging. those commits are also linear and easy to reproduce
<apw> though i suspect it is linear from .5
<apw> ack
 * rtg will bbiab
<rtg> cking, are you OK with me bouncing gomeisa ?
<rtg> I'm trying to remove a chroot and can't get all of the mount point released. damn schroot anyways.
<cking> yep
<rtg> cking, done
<BenC> apw: When I get a chance I'll write up a test case for you
<BenC> Gotta get this package out the door first...
<apw> BenC, if you can just show me the form i can debug it, as all the forms i'd expect you to have used test right and have tests already
<BenC> apw: Use the old enforce (before my commit) against my set of powerpc configs (with e500 and e500mc)
<BenC> That NVRAM check fails on e500 and e500mc, but it shouldn't
<apw> BenC, ta
<BenC> And the ADT check before it succeeds even though the check is the exact same syntax against the exact same flavours and the exact same value in the configs
<apw> (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \
<apw>  value CONFIG_NVRAM m | \
<apw>  !exists CONFIG_NVRAM
<ubot2> apw: I am only a bot, please don't think I'm intelligent :)
<apw> BenC, like that ... but you have it =y on powerpc-e500 and powerpc-e500mc and thats not valid under that form
<apw> so it correctly fails on those two
<apw> BenC, or perhaps not ... /me pokes
<apw> BenC, no i am right
<apw> CONFIGS/powerpc-config.flavour.powerpc-e500:CONFIG_NVRAM=y
<apw> CONFIGS/powerpc-config.flavour.powerpc-e500mc:CONFIG_NVRAM=y
<apw> CONFIGS/powerpc-config.flavour.powerpc-smp:CONFIG_NVRAM=y
<apw> those three have NVRAM set, so for the rule to be right it has to expect Y for those three
<apw> (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \
<apw> and that only allows it to be powerpc and powerpc-smp, so they will fail
<apw> (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \
<apw> damn that paste
<BenC> apw: I tried add "| value CONFIG_NVRAM y" and it still failed
<apw> BenC, will try that even though it doesn't represent what you want
<BenC> apw: I don't want to force NVRAM=y on e500/e500mc
<BenC> It's fine if it's one, don't care otherwise
<BenC> *on
<BenC> apw: What I want is for it to be forced on powepc-smp, and not care for anything else
<BenC> But the error only arose when it listed power and powerpc-smp as flavours, and the exact same situation existed for the ADT rule and it worked as expected
<BenC> powerpc
<BenC> So if the NVRAM rule works as expected, then the ADT rule isn't :)
<apw> BenC, nope, cause that _is_ only Y on powerpc-smp, and that rules says Y for that and _must_not_exist_ on all the others
<apw> so the rule matches reality, not necessarily what you care about
<BenC> it exists on e500/e500mc right?
<apw> nope
<apw> apw@dm:~/git2/ubuntu-raring$ grep CONFIG_THERM_ADT746X CONFIGS/*
<apw> CONFIGS/powerpc-config.flavour.powerpc-smp:CONFIG_THERM_ADT746X=y
<BenC> Hmmâ¦then I wasn't paying close enough attention
<apw> (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \
<apw>  (flavour powerpc-e500 powerpc-e500mc) | \
<apw>  value CONFIG_NVRAM m | \
<apw>  !exists CONFIG_NVRAM
<ubot2> apw: I am only a bot, please don't think I'm intelligent :)
<apw> so i think that encodes what you are saying
<BenC> so the second line just basically ignores e500/e500mc?
<apw> yeah it says this rule is "happy" if we are on one of those flavours, without checking anything related to the option
<apw> its just a logical or
<apw> i'll test that on master, and if it works splat it in
<BenC> Ok, thanks
<BenC> apw: I suggest you comment out the debug in the loop for possibles for the flavour predicate thoughâ¦in my testing, it only showed the first flavour
<BenC> Hence my concern about multiple flavours
<apw> BenC, the commented out debug is just plain wrong, i prints $a[1] each time, instread of $possible
<apw> but its commented out indeed
<BenC> err, meant uncomment so you see what it is
<BenC> I didn't see it only prints the [1] in the array
<BenC> That alleviates some of my concern then :)
<apw> yeah i clearly fixed the debug in the arch one, and not the flavours one
<apw> must have not had to debug flavours recently
<apw> BenC, ok i've fixed the debugging for next time
<BenC> Gracias
 * rtg takes a break to shovel some of the 16" of snow received overnight while the armhf build slowly crawls along
 * smb -> EOW
 * henrix -> EOD
<slangasek> rtg: urk, you were losing time fighting with armel?  Well, on the bright side... you don't have to do that again :P
<rtg> slangasek, urk, indeed :0
<rtg> :)
<rtg> slangasek, the next kernel upload won't contain _any_ armel support. Is brittany gonna be able to deal with that ?
<slangasek> yep
<rtg> slangasek, I understand moving powerpc support kind of made it complain
<slangasek> well, once removed we have to make sure we clean up behind it and aren't leaving uninstallable packages in the archive
<slangasek> but that's what britney's supposed to do
<rtg> hopefully BenC's upload will get everything sorted
<BenC> I'm in the final stages of proofing the packages
 * apw calls it a day
<BenC> infinity: Will I need to do a MIR for linux-ppc?
<infinity> BenC: No, it's just a source split producing things that were already in main.
<BenC> infinity: Ok, upload is in progressâ¦can I pester you for processing when it's done?
<infinity> BenC: If you've already added your bits to it, it might need a quick audit to make sure your patches are all license-compliant as part of the NEW process, but here's hoping you've been doing that sanely, with an eye to upstreaming. :P
<infinity> BenC: I'm ubufluish, and considering wandering back to bed, but poke me and I'll get to it this weekend with a community hat on.
<BenC> infinity: There's some patches from Freescale, but they are all available from Freescale's public linux.git and are in the process of upstreaming
 * rtg -> EOD
#ubuntu-kernel 2013-11-04
<ppisati> moin
<smb> ppisati, morning
<smb> ppisati, Still in one piece? :)
 * apw yawns
<apw> (himself)
 * smb already had
<ppisati> smb: yep :)
<apw> smb, i thought the dm-raid45 driver was effectivly a meta-data reader, and setup md underneath once so read ?
<apw> smb, and ... what do we think about just leaving it off for T, to figure out if anyone is actually affected by it
<smb> apw, The dm-raid45 module is the kernel-side implementation (as I wrote in my reply)
<smb> Right now the dmraid user-space uses it to set up the dm driver
<smb> But as I wrote too, one could change it maybe to use dm-raid -> md  
<apw> so dmraid userspace is still using raid45
<smb> Or leave it off but change the installer to make mdadm at least support two formats
<smb> apw, It seems to be as abandoned as the kernel module, yes
<apw> hmmm
<apw> well that is poop.  what do we use to setup raid normally, dmsetup instead now ?
<smb> Not sure whether RH silently came up with something differently named to replace it or just did not care for those
<smb> apw, fakeraid not the normal raid
<smb> apw, for softraid the tools should use mdadm already and that is md
<smb> apw, dmraid is fakeraid which is those bios'es claiming to have raid but only do some meta-data and the rest is software
<apw> smb, ok ... so from your email it sounded like some of the formats supported by fakeraid now were supported by mdadm ?
<smb> apw, Mostly the IMSM. I can not say whether or if which of those might be DDF
<smb> apw, Though I would doubt that a lot of those cared about any standard
<apw> well presumably fakeraid support formats A B and C, do we know that list
<smb> apw, Not from memory. We could use the source...
<apw> smb, ok i am comparing now ... and will reply
<smb> apw, I guess the problem might be that the utils say support this and that controller or board but not what kind of format that was
<apw> smb, right ... am i right in thinking you have something which used this ?
<smb> apw, Well I have one, maybe two kinds... not really very much
<smb> apw, And one of those is my work-desktop... which is a lot of pain to try things on (while preventing to end up with a lot of pieces)
<apw> smb, is either of those actually using it?  or did you use something else
<apw> smb, and if they are can you get me a dmsetup table off one
<smb> apw, Neither is using it right now
<apw> ok
<smb> apw, And the work machine uses md raid
<smb> apw, You would see nothing with dmsetup
<apw> smb, i thought dmraid45 was a real dm personality when loaded
<apw> it is used that way in the dmraid userspace
<smb> apw, The problem is that "it" is quite ambiguous... 
<apw> the dmraid userspace uses the dmraid45 kernel module via making dm tables, which seems to doo it that way
<smb> apw, Right, just when you asked whether I currently use "it" I was not sure you asked about dmraid or any softraid.
<apw> i am being oblique indeed
<apw> xnox, hey ... know anything about dmraid userspace ... 
<apw> it is so clear this has not changed like forever
<smb> Wonder whether this would be worth a session on vUDS
<apw> yeah we might want to touch on it in our 'misc' session at least
<xnox> apw: smb: i want a vUDS session on fakeraid. IMSM works "best" with mdadm, which means we need to pull mdadm into initramfs (done) and actually start mdmon to monitor / make those "special" raid devices work (IMSM and DDF)
<xnox> after 3.3 is merged, since that actually makes DDF work.
<xnox> my motherboard has support for both DDF and IMSM raid devices.
<xnox> but that means to organise switchout from dmraid, which helpfully will also try to activate "all" raid devices it can regornise.
<xnox> I haven't tried yet on my machine to see what happens if both dmraid and mdadm are racing to activate same raid device, or if it's ok for both of them to activate it (as long as only one of them mounted I guess)
<smb> xnox, I am not completely sure what I got. nvidia and something else. But we would also tend to rather want to drop the dm-raid45 special kernel module dmraid uses right now
<smb> xnox, In the past (when I tried last) mdadm won but only worked read-only
<xnox> smb: but mdadm does not support _all_ raids that dmraid does.
<smb> (for intel msm)
<smb> xnox, right
<xnox> smb: for intel msm, mdadm is best. I was thinking to patch out IMSM out of dmraid & upload dmraid with "Depends: mdadm" to transition people to mdadm who use Intel MSM.
<smb> xnox, The question would be whether (or how difficult) it would be to make dmraid use the dm-raid target instead (which then uses md in the background)
<xnox> not sure how sane that approach is though.
<smb> At least imsm is a known subset, so that does sound sane at least
<xnox> smb: just using md in the background is not enough. For intel msm raid with mdadm, one needs to have mdmon daemon running - which actually does the talking to the firmware/raid-chip-on-board to write/read/update raid metadata, as far as I can tell.
<xnox> DDF doesn't have 1-to-1 mapping into dmraid set of supported devices =/ and i'm happy to mostly ignore DDF for now, until some vendors come and say we really want this and that supported via mdadm.
<xnox> (intel expressed such interest before)
<smb> Yeah, I can see no easy way to figure out which is which. Hm, somewhat I'd be surprised that mdmon talks to firmware (that firmware seemed pretty dumb to me) But I would have to look into that. But yeah, probably that is doing the loggin via something else
<apw> xnox, will you own getting a dmraid session on the core- track ... and put smb and myself on it ... as clearly this needs some work and we should have a BP for it :)
<apw> xnox, that first bit really is a question btw :)
<xnox> apw: yes. let me put it in.
<apw> xnox, great, a plan then
<xnox> apw: smb: summit is aweful, please "attend" http://summit.ubuntu.com/uds-1311/meeting/22017/transitioning-to-use-mdadm-by-default-for-some-of-the-fakeraid-devices/ as well =)
 * xnox couldn't be bothered to scroll though non-searchable list of people who signed up to vUDS =)
<xnox> you are subscribed to the blueprint already... maybe summit will import that, maybe not.
<apw> xnox, thanks ... 
 * ppisati disappears for a bit...
<apw> henrix, i've applied that patch and tried to sort out the bug, it is missing the SRU bits
<henrix> apw: thanks
<henrix> apw: that bug has been fixed in Q before, and i thought the fix was applied from 3.2 stable. i was wrong
<apw> henrix, ok, just needs the SRU templaste copying over from the last one i suspect
<henrix> apw: yep, i'll take care of that
<henrix> apw: thanks
<apw> otherwise it looks fine to me, and well smb and sconklin have staked their reputations on it :) so i don't need to read it
<henrix> heh 
<apw> clap4ham
<apw> i am do going to remove unity from this machine
<apw> that'd be the fourth time it has done htat in as many months
 * apw is jetlagged to hell and back ...
<bjf> marrusl, around?
<bjf> kamal, is bug 1163720 something you can verify or get someone to verify?
<ubot2> Launchpad bug 1163720 in linux (Ubuntu Raring) "Brightness control broken on XPS13 and 3.8.0-16, 3.8.0-22 and 3.11.0-12" [Medium,In progress] https://launchpad.net/bugs/1163720
<bjf> kamal, i seem to have a commit that has that as the buglink in quantal
<marrusl> bjf, hey
<bjf> marrusl, is bug 1208740 something you can verify
<ubot2> Launchpad bug 1208740 in linux (Ubuntu Raring) "Large pastes into readline enabled programs causes breakage from kernels v2.6.31 onwards" [Medium,Fix committed] https://launchpad.net/bugs/1208740
<bjf> ?
<bjf> marrusl, or will arges be back this week and he can do it?
<marrusl> bjf, arges is back I believe.  one of us will get to it.  making a note.
<bjf> marrusl, thanks
#ubuntu-kernel 2013-11-05
<marrusl> bjf, np.  thank you!
<elpis> I want to ask question how to grep in order to get only the essid and signal level when i issue the iwlist command. 
<elpis> I want to ask question how to grep in order to get only the essid and signal level when i issue the iwlist command. 
<elpis> hello there can someone help me how to use grep in this problem given . http://pastebin.com/c01UX1B8 
<Eimann> iwlist wlan0 scan|egrep 'ESSID|Signal'|sed -e 's/.*"\(.*\)"[^"]*$/\1/' -e 's/.*=\(.*\)*$/\1/' -e 's/ dBm//'
<FreezingCold> How does Debian and Ubuntu's kernel differ?
<elpis> Eimann: thank you so much you are really great you save my day. BTW do you have any good tutorials on how you do it ?
<Eimann> I used http://regex101.com/
<elpis> Eimann: thank you so much
<ppisati> moin
<cking> yawn
 * apw yawns hard
<apw> smb is in network hell ... 
 * ppisati disappears for a bit
<qengho> Hi all.  I have a thinkpad with a hard crash that leaves no log file and blinking caps-lock and I want to file a bug report in LP. I can reproduce easily. Is there a good way to capture the crash log? I think my photo of the console is terrible.
<antarus> does sysrq work?
<qengho> Hrm. Thinkpad funniness. I think I tried right-alt, SysRq, S-U-B and Fn + right-alt, SysRq, S-U-B and had to push the power button.  I can try it again.
<qengho> antarus: If it does, what should I do?
<qengho> (I have only this target machine here, so IRC debugging is iffy.)
<qengho> IRC client on my phone. Rock. Okay, I can do that.
<qengho> antarus: Okay, now what?
<qengho> dang. hang and reboot that time.
<psusi> isn't it time for the kernel meeting?
<cking> psusi, it was cancelled 
<apw> psusi, we don't typically do them between release and UDS
<apw> psusi, if you have something you want to bring up you are more likley to get a response here though as you would there
<apw> qengho, if sysrq doesn't get you anything better, then filing a bug with the photo however bad it is is the right thing
<apw> with little to go on we would then recommend you start looking for an older kernel which was ok
<apw> as i assume this is a new issue to you
<psusi> hrm... ok, I've just been wanting to float the idea of CONFIG_EXT[23]=n
<apw> =n ok
<psusi> with them disabled, the ext4 driver will take over and do a better job than the old code, and give a smaller kernel ;)
<apw> so ... the right thing to do is probabally to add that to the vuds kernel session
<psusi> ok
<apw> as that is quite a big scarey sounding challenge, and we will want to get someone to do some real testing to confirm it works ok
<apw> psusi, you would be free to come to the session and discuss or just put it on the adgenda, as i am happy to bring it up
<psusi> will do
<apw> https://blueprints.launchpad.net/ubuntu/+spec/core-1311-kernel
<psusi> as an added benefit, the ext4 driver allows online resize on ext2 filesystems, which the ext2 driver can't handle
<apw> that is the one it needs to be associated with
<apw> psusi, heh ... don't frighten me
<psusi> hehe
<psusi> I've been trying to get gparted to handle online resize and in testing noticed that I had built my kernel with the ext2/3 drivers disabled so it worked, but on a stock kernel ext2 can't do the resize online
<apw> psusi, include that nugget
<psusi> so I shuold report a bug and link it to that bp?
<apw> hmmmm, i guess that might make sense if you can be bothered
<bjf> arges, are you able to verify bug 1208740?
<ubot2> Launchpad bug 1208740 in linux (Ubuntu Raring) "Large pastes into readline enabled programs causes breakage from kernels v2.6.31 onwards" [Medium,Fix committed] https://launchpad.net/bugs/1208740
<antarus> bjf: that is my teams bug
<bjf> antarus, cool, can you verify ?
<antarus> bjf: I can have marga verify
<antarus> won't be until tomorrow pobably
<bjf> antarus, ok, it has been waiting for verification for over a week
<antarus> I sent her a note
<bjf> antarus, thanks much
<antarus> no worries, we are trying to be better about this sort of thing ;)
<antarus> mostly we just need a launchpad bot that syncs launchpad with our internal bugtracker
<antarus> because we mostly ignore launchpad ;p
<bjf> antarus, i can relate to that
<arges> bjf: looking
<arges> bjf: i'll do this today
<bjf> arges, thanks
<xnox> apw: i think debian starting building with  CONFIG_EXT[23]=n, i'll check.
<apw> xnox, thanks
<nhm> I've got 13.04 and am trying to use the dwarf support in perf (ie "-g dwarf").  It appears that this isn't enabled in the 3.11.0-12-generic version of perf I have.  Was NO_LIBUNWIND set when that version of perf was built?
<nhm> or maybe the build machine didn't have libunwind?
<apw> likely the latter
<apw> nhm, could you file a bug and put some details in it, and ping me the number, file it against linux
<nhm> apw: sure, will do
<nhm> apw: I'm afraid I' don't file launchpad bugs very often, so hopefully I did this right: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248289
<ubot2> Launchpad bug 1248289 in linux (Ubuntu) "Missing libunwind support in perf" [Undecided,New]
<bjf> nhm, looks good
<qengho> apw: not necessarily new bug. It's new hardware.
<qengho> referring to mine of 2 hours ago.  Just submitting now. 
#ubuntu-kernel 2013-11-06
<kees> any reason we build the ARM kernels with CONFIG_OABI_COMPAT?
<bjf> kees, can't think of any reason. we don't notmally turn on anything with EXPERIMENTAL in the description. rtg would be the one to ask however
<bjf> kees, file a bug?
<bjf> kees, or mail to the mailing list
<kees> bjf: okay, cool
<leb> can anyone help with this
<leb> https://gist.github.com/tildeleb/7329005
<infinity> leb: Not really a kernel question, but you want sys/inotify.h, not linux/inotify.h... You should never include linux/ headers from userspace.
<leb> I know it's no a kernel question
<leb> sorry about that
<leb> but other channels didn't have much of a clue
<netrunner__> hello everybody
<leb> trying to compile an older inotifyd so this is not my code
<netrunner__> i need support due to a fail at the new kernels
<netrunner__> http://imagebin.org/275897
<netrunner__> http://imagebin.org/275900
<netrunner__> output of dmesg:
<netrunner__> http://paste.ubuntu.com/6367846/
<netrunner__> does anyone have a idea?
<netrunner__> some more information:
<netrunner__> the 3.2.1-52-generic-pae kernel is the last one who works
<leb> infinity thanks
<netrunner__> the newer one dont work
<netrunner__> cant boot
<leb> changing from linix/ to sys/ solved the issue
<netrunner__> how i do that??
<netrunner__> i am not an expert
<leb> muchas gracias
<netrunner__> jep, thanks in advance for help :-)
<netrunner__> or is this message for another guy?
<netrunner__> anybody here who can help me?
<bjf> netrunner__, what i suggest is you boot the working kernel and file a bug
<bjf> netrunner__, what timezone are you in?
<bjf> netrunner__, once you file the bug and we take a look at it you are going to get asked to test some kernels
<netrunner__> MEZ
<netrunner__> ok, i have already boot the working kernel
<netrunner__> how can i file a bug
<bjf> kinda late for you :-) (or early depending on how you look at it)
<netrunner__> ?
<bjf> netrunner__, from a terminal type: "ubuntu-bug linux"
<netrunner__> it is not possible because i have a kubuntu ditro
<netrunner__> distro
<bjf> netrunner__, https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<netrunner__> http://paste.ubuntu.com/6368039/
<netrunner__> that is the output of "ubuntu-bug linux
<netrunner__> i have netrunner - a kubuntu distro
<netrunner__> should i really register at: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug?
<bjf> netrunner__, yes, we need the bug filed
<netrunner__> ok i will sign up
<netrunner__> ok, how can i file this bug now?
<bjf> netrunner__, got to the url i posted ^
<netrunner__> jep, there is a wizard, but i dont know the cause of the problem
<netrunner__> and i dont know the package the wizard is asking for
<bjf> netrunner__, the package is already set to "linux" just fill out the summary and further information (what the probelm is and how to reproduce) then "submit bug report" at the bottom
<netrunner__> Can i also add pictures to the bug report?
 * apw yawns
<reisei> hi, all! I'm compiling kernel for omap4, but got the error: objdump: /lib/libc.so.6: File format not recognized
<reisei> dpkg-shlibdeps: error: objdump gave error exit status 1 How can I fix it?
<reisei> Any advice will be appreciated
<ppisati> robher: didn't you leave some debug printk around in your mac address learning patch?
<ppisati> robher: printk("unlearned addr %pM\n", addr);
<ppisati> robher: printk("learned addr %pM\n", src_addr);
<apw> reisei, compiling in what environment, that sounds like you are running a forign binary
<reisei> apw: already found that was some kind of ASCII file. Just copy the library itself and it work.
<reisei> apw: arm-linux-gnueabi- lost some of the files...
<ppisati> robher: and one last thing that it's a bit counterintuitive, why do you learn the src_addr on the xmit path? since we are on the way out, shouldn't we learn the dst_addr or maybe the src_addr on receive?
 * ppisati should put some printk and check by himself...
<apw> https://wiki.ubuntu.com/ARM64/FoundationModel
<athira> i am new to contributing to ubuntu launchpad.i reported a bug in secure-delete package and i have attached and submitted the patch.i didnt set a reviewer for my patch.can anyone tell me how to set a reviewer?
<robher> ppisati: yes, those printks should be removed. We need to learn the src addr so that received pkts with that dst addr are not dropped. We'll never get the pkt on the receive side if the addr is not known.
<apw> athira, you would normally subscribe the ubuntu-sru team if it is for a stable release, or for devel just ask the patch-pilot on #ubuntu-devel
<apw> hallyn_, hey .. we have reports of networking issues inside lxc containers on 3.12 kernels
<apw> hallyn_, mean anything to you ?
<hallyn_> apw: well there's the known offloading of checksums for veth as of 3.11 or 3.10...
<hallyn_> ubuntu software as of saucy should be updatd to handle it
<hallyn_> but what sort of issues are yous eeing?
<smb> apw, hallyn_ maybe we should find out whether the setup has openvswitch for the container involved
<ogasawara> ah, wasn't that one of the busted dkms packages for 3.12?
<smb> one of the complicated cases where features moved to the in-kernel module and caused a lot of head scrating as of how to cope with the dkms module (especially in P userspace)
<smb> *scratching
 * hallyn_ is surprised at the # issues in 3.12
<ppisati> back in 20
<smb> apw, Hm, just my few cents here... maybe you are already further in looking but from the console logs its hard to say whether network went away completely or "just" some fail in the resolver
<apw> smb, i think the implecation of the further testing is that it works outside the lxc and not inside
<apw> hallyn_, so in this case we have a report of an lxc container where the 'host' can talk to archive.u.c, and the lxc container processes cannot
<apw> hallyn_, this is from a test case which works with a downgraded kernel
<apw> hallyn_, do we know of any configuration changes between 3.11 and 3.12 in that area, i assume more is available there namespace wise
<hallyn_> apw: i can't think of anything...
<hallyn_> apw: is there an lp bug for this?
<apw> hallyn_, not as yet
<apw> hallyn_, is this something i can easily (or you) test in isolation 
<apw> that network isolation is working on 3.12, do we have any tests ?
<hallyn_> apw: well lp:~serge-hallyn/+junk/lxc-tests has some.  but i've been experimeinting with containers on 3.12 for the last few days with no issue
<hallyn_> haven't upgraded kernel in 2 days probably
<apw> hallyn_, ok that is a good data point, what kernel would you have tested ours or something of your own
<apw> bug #1248590
<ubot2> Launchpad bug 1248590 in linux (Ubuntu) "on qa-radeon-7750, containers lose network connectivity" [Critical,Confirmed] https://launchpad.net/bugs/1248590
<apw> hallyn_, thats the one
<hallyn_> apw: I'm on 3.12.0-1-generic #3-Ubuntu SMP Tue Oct 29 18:41:32 right now
<apw> hallyn_, ok thats the archive one ...
<hallyn_> apw: alas the dmesg in that bug is from a run where they haven't tried a container
<apw> hallyn_, they say it is an autopilot test, and it goes wrong in the 'update yourself' phase thereof
<hallyn_> apw: ok, but - the containers, are they newly created each time, or are they using stale ones?
<hallyn_> if they are using older contaienrs (or debian) then they can get the old dnsmasq which won't work with newer kernel
<apw> hallyn_, do you know the otto tool at all, its that one
<hallyn_> i don't
<hallyn_> also, 3.11 is not old enough to make a difference with that
<hallyn_> i'm readig the linked incident log right now
<kees> whee, it only took me 5 months to get this backported and tested, but I've sent a Precise ARM seccomp-bpf patch to the list now.
<hallyn_> apw: good news, reversing the CLONE_PARENT restriction which broke lxc-attach seems to be acceptable upstraem.
 * hallyn_ out for the day
#ubuntu-kernel 2013-11-07
<apw> hallyn_, g
<apw> hallyn_, great
<smb> apw, Just because I remember right now, did you have time yesterday to look at one of the Xen MRE packages?
<smb> (I guess you where rather busy handling that Trusty kernel)
<apw> no i veered off into disaster ... yeah that
<smb> Just out of interest, is there any light
<apw> any light ?
<smb> at the end of the disaster tunnel
<smb> Probably better asked: do you know what is missing or do we still wonder?
<apw> the kernle which just finished publishing should be fixed, it was a lack of apparmour patches, which jj shoved over last night
<apw> with some help from inifinity over night that made it out, so hopefully they will be happy now
<smb> Oh wow, pretty amazing to find out apparmor with that dubious error in networking
<jjohansen1> smb: not really, while there are other changes in that kernel most of them aren't exposed, the networking is the largest user visible changes
<smb> jjohansen1, Right but then one usually tries to figure out what in networking broke things
<jjohansen1> true
<smb> jjohansen1, And morning (or goodnight?), btw. :)
<jjohansen1> I think the started trolling the logs and noticed an apparmor messages
<jjohansen1> night
<smb> Yeah, probably after having a manually started container
<smb> to look at them
<smb> (well night as time of day is clear, its much harder to find out the jj-time of day ;))
<jjohansen1> heh, well it would be night in jj-time of day, I started my day about 17h ago
<smb> jjohansen1, Heck, why are you here then? Go to bed... now! :)
<jjohansen1> hehe, I am about to finish driving a stake through a very annoying bug
<smb> Hm, a vampire killed by a zombie. I think that is novel...
<jjohansen1> lol
<infinity> I do my best bugfixes at zombie-o-clock.
<infinity> It's the sleep deprivation equivalent of the ballmer peak.
<jjohansen1> this zombie is particularly reanimated by killing this vampire
<smb> infinity, You are weird, too. :)
<jjohansen1> oh! infinity I think your onto something there
<smb> I tend to create more vampires in that state
 * smb is amazed at his dist-upgrade performance... its almost as if I had proper internet
<infinity> jjohansen1: Yeah, it atcually makes some sense.  I do menial tasks during the day when I'm awake, then as I start to get a bit fuzzy, I have a flurry of creative "I can totally port that to VMS/VAX", and then a few hours after that, I'm just drooling and staring at kitten pictures on imgur.
<jjohansen1> smb: wait your doing dist-upgrade over your phone? Isn't that going to eat the chunk of data you bought
<smb> jjohansen1, Luckily it isn't to long ago that I updated my servers, but yes. 
<smb> And I run apt-cacher to avoid duplicates
<jjohansen1> sure but still you have to get that first pull through
<jjohansen1> how many more days until you get your internet fixed?
<smb> Right, according to ifconfig I "only" used about 70M today, so it would be okayish
 * infinity doesn't understand this concept of "buying data"...
<jjohansen1> I guess thats okay
<infinity> I could tether on my phone 24/7 here, if I wanted to.
<smb> infinity, Its that weird interpretation of "flatrate" ISPs seem to have
<smb> at least here
<jjohansen1> infinity: just switch to verizon, they will make you buy data and then bend you over, beat you and take anything left in your wallet
<infinity> jjohansen1: I'll pass, thanks. :)
<infinity> jjohansen1: I get unlimited data, unlimited north american calling, unlimited international text, and a few other goodies, for 35/mo.  Which still feels like too much to me because I'm a cheap bastard, but I get the impression it's not a bad deal compared to some. :P
<jjohansen1> infinity: which service?
 * smb sees drooling
<infinity> jjohansen1: WIND in Canadia.
<apw> the have as much as you want data game is here for broadband, and now for some on phones, but tethering not so much
<apw> why they think they can claim their data is 'only 1p/MB' i do not know
<ppisati_> WTF moment:
<ppisati_> [    5.882305] RAMDISK: Couldn't find valid RAM disk image starting at 0.
<ppisati_> ???
<apw> ppisati_, initrd not actually an initrd bits ?
<ppisati_> apw: eh
<ppisati_> apw: fresh reubuilt armhf generic kernel
<ppisati_> apw: the -lpae variant works ok, while the non-lpae gave me that
<apw> hmmm, and the initrd is an initrd on disk
<ppisati_> apw: didn't decompress/open it
<ppisati_> apw: but i'm used to get a valid initrd after the usual fdr clean binary-generic stuff
<ppisati_> apw: hold on
<ppisati_> apw: indeed, it's a valid initrd and eveyrthing works on omap
<ppisati_> apw: vmlinuz overwriting initrd, that's it
<ppisati_> -ETOOFAT
<sergiusens> can anyone helping me building the goldfish kernel?
<ogra_> sergiusens, https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile ?
<sergiusens> ogra_, yeah
<sergiusens> ogra_, but it needs arm-*-gcc-4.6
<sergiusens> ogra_, I tried 4.7 but the kernel dies
<ogra_> hmm, ricardo said he had cross built it ... 
<ogra_> probably there is a trick to get the 4.6 gcc 
<sergiusens> ogra_, I might need a schroot; but is precise what I want
<ogra_> ogra@anubis:~$ apt-cache search gcc 4.6|grep arm
<ogra_> gcc-4.6-arm-linux-gnueabi - GNU C compiler
<ogra_> gcc-4.6-arm-linux-gnueabi-base - GCC, the GNU Compiler Collection (base package)
<ogra_> gcc-4.6-arm-linux-gnueabihf - GNU C compiler
<ogra_> gcc-4.6-arm-linux-gnueabihf-base - GCC, the GNU Compiler Collection (base package)
<ogra_> (i'm on precise on my desktop)
<sergiusens> ogra_, ack, so I need to create a schroot; thanks
 * ppisati_ disappears for a bit
<Deugsy> Hello
<Deugsy> Could you help me concerning the compilation of kernel 3.11.0 ?
<Deugsy> it's a stupid and simple question
<apw> tell us your issue and you nevre know
<Deugsy> thanks
<Deugsy> Do you know if it is possible to start again the compilation after an error just when it stopped ?
<Deugsy> to avoid to re-compile all it was done 
<apw> what command are you using to build it
<Deugsy> make-kpkg --append-to-version "-perso" --initrd --us --uc buildpackage
<Deugsy> to build a debian build
<Deugsy> sorry , to make a debian build
<apw> cking, you use that routinly i think ^^ is that restartable ?
<ppisati_> -nc?
<Deugsy> sorry i'm french, when i re-execute the line command, it rebuilded all
<Deugsy> now i am waiting to see when the error will appear 
<Deugsy> again
<Deugsy> i am compiling the kernel to see again when it crashes
<Deugsy> and what is the error
<Deugsy> I thought it was possible to start again the compilation without compiling all was done the first time
<apw> Deugsy, i believe it is, possibly switching 'buildpackage' for 'binary' might do it, but i have never tried that one
<Deugsy> ok thank you apw
<Deugsy> i will try
<cking> apw, I don't use that, I use  make deb-pkg INSTALL_MOD_STRIP=1 
<cking> which is dead easy to use 
<Deugsy> ok cking
<cking> just copy over the appropriate config to .config, and run that make deb-pkg command
<Deugsy> perfect
<apw> cking, thanks
<cking> np
 * rtg -> EOD
#ubuntu-kernel 2013-11-08
 * smb grumbles about unhelpful service providers
<cking> smb, still no luck?
<smb> cking, nope (except tethering)
<cking> smb, did they give you any idea when you would get it fixed?
<smb> cking, No, that would be far too helpful. Things change between, this can take days to we don't think we have an issue
<cking> sigh
<cking> that's really awful
<smb> One of the main issues is that it is *impossible* to actually talk to any technical staff
<cking> smb, quality service provision :-/
<smb> cking, Yeah, probably even ISO certified (keep technical staff firewalled behind a call center)
<v41> Is the linux-generic-lts-saucy package (version 3.11.0.13.12) based upon mainline kernel 3.11.3 or 3.11.5+ ? The reason for asking is that some critical btrfs filesystem bugs in 3.11.3 have been fixed in 3.11.5 .  I checked the ubuntu-to-mainline-kernel-version-mapping-page, but it doesn't list version 3.11.0.13.12.
<xnox> v41: https://launchpad.net/ubuntu/+source/linux/3.11.0-13.20 lists a few bug fixes for btrfs.
<smb> IF it is that linux-image version it should be based on 3.11.6
<v41> xnox:  yes, the kernel-version-mapping page shows that 3.11.0-13.20 is based upon 3.11.6, so it contains the btrfs fixes.  But linux-generic-lts-saucy is based upon an earlier version, 3.11.0.13.12
<smb> That version number looks like the one from a meta package
<v41> smb:  Thankyou, that clears up the problem.  As you suggested, the meta package depends upon linux-image version 3.11.0-13.20 .   I ought to have checked this before asking the question.  (Headslap).
<smb> -> 3.11.0-13.20~precise2
<smb> linux-image-3.11.0-13-generic
<smb> Right :)
 * ppisati -> out for lunch
<stgraber> apw: around?
<stgraber> apw: I'm looking at tweaking our d-i armhf images a bit and one thing that'd help quite a bit there is for all the existing .dtb to be shipped in the udeb
<ppisati> stgraber: nope, is off now
<stgraber> ppisati: ok, anyway, I think I've got a patch that should do the trick, I'll send that to the list asking if there may also be a way to avoid having those hardcoded in two places
<stgraber> ppisati: as apparently just having the dtb enabled in the kernel config isn't enough, they also need to be added to rules.d/armhf.mk to actually show up in the udeb
<rtg> stgraber, IIRC there is a firmware udeb where the DTBs sholdgo.
<rtg> should go*
<stgraber> rtg: so all the current ones appear to be in the kernel-image udeb
<stgraber> rtg: I can't find a generic firmware udeb, the only ones I see come from the linux-firmware source
<rtg> stgraber, which kind of makes sense (that they are in the kernel image udeb). lemme refresh my memory about firmware.
<jsalisbury> jodh, Hey James, when you have a chance, can you test the kernel posted in bug 1247769 I can send that patch to the mailing list if you confirm it fixes the bug.
<ubot2> Launchpad bug 1247769 in linux (Ubuntu Trusty) "kernel headers do not define OVERLAYFS_SUPER_MAGIC " [Medium,In progress] https://launchpad.net/bugs/1247769
<jodh> jsalisbury: currently working on a release (I can look on Monday), but can't that just be tested by someone simply grepping for OVERLAYFS_SUPER_MAGIC in the appropriate header?
<jsalisbury> jodh, cool, thanks.  Just like to have to bug reporter test to confirm it fixes the problem.
<ppisati> either i'm doing somthing wrong or upstream u-boot is broken WRT omap3/am335x
<ppisati> and with that said, /me call it a day/week
<ppisati> EOW
<stgraber> rtg: any idea when these two extra dtb will land in the archive? It's currently blocking a d-i change I'm preparing.
<rtg> stgraber, I assume you're targeting trusty ? noly one of them is supported for Saucy.
<rtg> only*
<stgraber> rtg: yeah, I only care about trusty
<rtg> stgraber, gimme a bit. I can get it uploaded today.
<stgraber> rtg: I'm reworking the way we generate armhf d-i images to be much faster and use the upstream u-boot with the generic kernel for all boards using device-tree
<stgraber> rtg: awesome, thanks!
<rtg> stgraber, I was messing with generating the udeb from the DTB list, but I'll just postpone that for now
<rtg> too many distractions right now
<stgraber> yeah, I think it'd be good to get there eventually so adding support for extra boards isn't nearly as painful, but for now I mostly care about getting my wandboard be installable ;)
<infinity> stgraber: Selfish. ;)
<rtg> stgraber, uploaded trusty with your DTB patch (somewhat modified)
<stgraber> rtg: thanks!
<stgraber> rtg: oh I see, I guess it works better when applied to the right place ;)
<rtg> stgraber, yup
<infinity> CONFIG_OABI_COMPAT=n
<infinity> That was seriously not set before?
<rtg> infinity, nope, kees pointed it out
<rtg> I hate xchat
<infinity> rtg: I mean, it's mostly a no-op on the userspace side, since we tore OABI (completely) out of glibc a couple of releases back.
<infinity> But still.  Wha?
<rtg> there are a zillion config options. I'm not surprised we missed this one for awhile
<infinity> rtg: Yeah, I'm just surprised it was ever on in the first place, since our userspace has been EABI from day one.
<infinity> Though, maybe someone made an argument for the compat long ago.
<rtg> I likely inherited it from somewhere and didn't notice.
<kees> infinity, rtg: it's been "default y" in mainline, so that's probably why. it does add syscall overhead to have built in. anyway, I sent a patch to "default n" it in mainline...
<rtg> kees, confused for a sec. I was still thinking CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
<infinity> kees: Yeah, it should definitely default to n, given the lack of userspace support these days.
<kees> rtg: ah, yeah, no, I meant CONFIG_OABI_COMPAT. :)
<kees> rtg: and sorry about the glitch on the seccomp patch. It seems I totally screwed up my "master" checkout months ago and didn't notice "git pull" was doing merges :(
<kees> rtg: I've sent a pull request now with the two missing upstream patches too.
<rtg> kees, cool
<rtg> thanks
<kees> rtg: np, sorry for wasting a build :(
<rtg> kees, make M=kernel takes very little time
<kees> heh, okay, whew :)
<kees> I've also forgotten the joys of 64-way builds. first world problem of now having ONLY 32-way :)
<rtg> kees, oh, I'm doing this on a Calxeda. I wanted to make sure the cross compile wasn't the issue.
<kees> ah! okay.
 * rtg -> EOW
#ubuntu-kernel 2013-11-09
<Kano> hi, could somebody fix the ndiswrapper package for 3.12?
#ubuntu-kernel 2013-11-10
<phillw> Hi good people, your most hated person here :D I've had a report of https://bugzilla.redhat.com/show_bug.cgi?id=1014289 and would like to ask how I should progress this with the OP
<ubot2> bugzilla.redhat.com bug 1014289 in kernel "[drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags (expected 2, found 0)" [Medium,Closed: currentrelease]
<apw> phillw, well the rh bug claims this is fixed in 3.11.4 which is applied in the saucy kernel in -updates, so confirm they have tested that -13 kernel
<phillw> apw: I'll ask the OP to double check, as He is on saucy I'm not sure why he sees the error.
<phillw> I've asked him to do a "ubuntu-bug linux" from the affected machine and await a bug report.
#ubuntu-kernel 2014-11-03
<[Neurotic]> Hi! I'm looking for the source for http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17.1-utopic/ - I *think* I found it in git://kernel.ubuntu.com/ubuntu/ubuntu-utopic.git under the unstable branch (I see there is a commit to rebase against 3.17). Is that correct?
<apw> [Neurotic], nope, there is no branch for the mainline builds; they are made from the base commit (see COMMIT) and the patches there
<apw> in the same directory with the binaries
<[Neurotic]> apw: Sorry, not understanding what the "base commit" is - is that in the kernel.ubuntu git repository? or are you referring to the mainline linux kernel repository?
<apw> [Neurotic], the base commit is the commit listed in COMMIT which is found in either linus' tree or the stable tree in those (mostly)
<[Neurotic]> apw: (thanks for answering though)
<apw> for v3.17.1 clearly that is a stable version, which is therefore in the stable tree
<[Neurotic]> apw: But there is no tag for v3.17.1 in the utopic git repo
<[Neurotic]> I am looking at the cloned git repository now, and I can't see anything to match it up to
<[Neurotic]> (thanks for your help btw, much appreciated apw )
<[Neurotic]> ...so I'm guessing it's a v3.17.1 tag in linus's tree then?
<[Neurotic]> Which I'm assuming is this: https://github.com/torvalds/linux/tree/v3.17
<apw> nope, v3.17.1 which is in the stable tree
<apw> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
<[Neurotic]> aaah
<[Neurotic]> I would never have found that on my own - much appreciaed
<mvo> hi, does anyone have concerns if I remove some kernels (like linux-dove, details under http://paste.ubuntu.com/8800923/) from platform.vivid ? AFAICT these kernels are no longer in utopic or vivid and some not even in trusty. 
<infinity> mvo: Go nuts.  Just make sure there are no transitional metapackages you're removing.
<infinity> mvo: Though, if there are (for, say, omap or highbank), that would be a bug, as they should have been dropped post-trusty.
<mvo> infinity: ok, I check. 
<infinity> mvo: That said, that file is pretty much a lie anyway, as we don't build any bootable images for armhf.
<mvo> infinity: while you are here â¦ ogra_ suggested that I ask if you might have a idea why https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image fails to build armhf - well, it fails because it tries to install linux-mx5 and linux-omap
<infinity> mvo: The icky regex in supported-kernel-common is more interesting.
<mvo> infinity: the linux-omap might come from the seeds, but I can't find anything linux-mx5 rleeated
<ogra_> thats long gone
<mvo> infinity: oh, I haven't touched this one yet :)
<ogra_> was mx5 even there for more than one release ? 
<ogra_> (in the archive i mean) 
<ogra_> iirc that was just to please linaro 
<infinity> mvo: That failure has nothing to do with seeds at all.
<mvo> infinity: all livecd-rootfs releated?
<infinity> mvo: It's because you're not selecting a kernel (or "none")
<infinity> mvo: And live-build is picking a default for you.
<infinity> functions/defaults.sh:			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-mx5 omap}"
<mvo> woah, thanks
<mvo> silly me for not looking into live-build and only into livecd-rootfs
<mvo> thanks infinity \o/
<infinity> mvo: See livecd-rootfs config.
<infinity> mvo:         ubuntu-server|ubuntu-core|ubuntu-touch)
<infinity>                                 KERNEL_FLAVOURS=none
<infinity> mvo: That's what you want if you want to be kernel-free.  Just add your flavour to that case.
<infinity> mvo: Or if you want a kernel, specify one there.
<mvo> infinity: hm, our flavor is ubuntu-core, but I think I know enough to fix it now, thanks again
<infinity> mvo: There's already a system-image sub-case in that case.
 * ogra_ wishes the livecd-sh script back ... live-build is such a beast
<infinity> mvo: You just didn't add KERNEL_FLAVOURS=generic
<ogra_> *livecd.sh
<infinity> mvo: (Assuming you want a kernel, which seems to have been your intent)
<mvo> infinity: right, I think I did in the PPA but we don't have arm support in the ppa yet, I will use the archive until we get that. (and yes, we want a kenrel :)
<mvo> kernel even
<infinity> mvo: Anyhow, clean up the cruft in the seeds if you want, but it won't make a difference here, that's all no-ops.
 * mvo nds
 * mvo nods
<infinity> mvo: You might want "add_package install flash-kernel u-boot-tools" too.
<mvo> infinity: thanks, I will add that!
<infinity> mvo: The armhf case that would naturally follow the amd64 case for grub-pc.
<mvo> infinity: right
<mvo> infinity: thanks for your help here, my arm experience is still limited, so I'm thankful for those hints
<Kano> hi, is there a git for linux-firmware-nonfree?
<apw> Kano, do not believe so
<Kano> why not
<Kano> did you try overlayfs for live?
<apw> because the archive is definative for that package
<apw> we default to overlayfs for live
<Kano> so casper already boots with it?
<apw> yes
<Kano> where is the git?
<apw> for?
<Kano> casper
<Kano> what to see the changes
<apw> i believe that is in bzr, in the udd branches
<Kano> ubuntus website is really bad compared to debian, there you see git/svn directly
<apw> could be
<Kano> i mean the packages.ubuntu.com
<Kano> and fully outdated, vivid is not mentioned, utopic not default and if that is the right bzr it has no 1.345
<Kano> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/casper/vivid/changes/1144?start_revid=1144
<Kano> cant you use git...
<apw> not yet
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues November 4th, 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> apw: holy cow.  i only just noticed that overlayfs has been merged.  woot
<hallyn> stgraber: ^
<stgraber> hallyn: oh, I heard about the pull request, didn't realize it was actually accepted this time, nice!
<stgraber> now maybe more people will care about making it suck less :)
<apw> stgraber, yep maybe
#ubuntu-kernel 2014-11-04
<jason1> Hi kids.
<infinity> zequence: It's that time of month again.
<infinity> zequence: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1389061
<ubot5> Ubuntu bug 1389061 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<ppf> hi
<ppf> i'm still trying to build a new kernel flavour
<ppf> and i'm running into "previous or current modules file missing!"
<ppf> what do i need to do about that?
<apw> ppf, add the ignore files to the previous abi directory for those flavours
<apw> ppf, doesn't the error message now even tell you waht was missing
<ppf> the .modules file of a previous kernel version
<ppf> (which is missing of course because i'm adding the new flavour just now)
<ppf> apw:  how do i add the ignore files to the previous ani directory?
<apw> well the error message tells you the abi number it is lookin for IIRC
<ppf> i find it hard to find comprehensive documentation on what's required to create a new flavour
<ppf> yes, it does
<ppf> abi/3.13.0-38.65/amd64/
<apw> and in there, you want to add files called "ignore" and "ignore.modules"
<apw> which turns it off
<ppf> will that ignore these for all flavours?
<apw> note that they cannot be empty is you are going to upload it to a PPA etc
<apw> yes that ignores the abi for all flavours in that arch
<apw> you probalally want to ignore it in all builds, as you will be likely building i386 at least as well to get the indep arch packages
<ppf> alright, i'll give it a shot!\
<ppf> thank you :)
<zequence> infinity: Thanks
<bjf> zyga, there is a new precise in -proposed. please ignore it. some CVE fixes are working their way through upstream right now and when they pop we will pull them and respin
<zyga> bjf: hey
<zyga> bjf: understood, thanks
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues November 11th, 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.
#ubuntu-kernel 2014-11-06
<Lugal> hello
<Lugal> what is the difference between the Ubuntu Kernel and Kernels from other distros like Debian, Arch, Fedora...?
<apw> Lugal, they are generally at different base versions and carry differnt patches, for more specifics you woudl want to compare the source
<Lugal> is one better than another or are they just best for its purpose_
<Lugal> ?
<Lugal> and another thin: some systems start up faster then others and some run faster.  does this depend on the kernel, or the packages? or on what?
<apw> Lugal, i'd suggest that each distro would claim theirs is best for their distro's purpose
<apw> speed of boot depends on pretty much everything, speed of machine, speed of disk, size of memory, versions of things, how much crap is installed.  how long is a piece of string
<kees> https://wiki.ubuntu.com/Kernel/LTSEnablementStack implies there should be an "early preview" of 3.16 on trusty by now. Where do things stand for that? (I'm curious to try an LTS backport of the utopic kernel on trusty...)
<kees> and in other news, http://people.canonical.com/~kernel/reports/sru-report.html seems pretty empty for utopic...
<stgraber> kees: currently hasn't hit trusty-proposed yet. An experimental backport is available in the kernel team PPA though (I've been using it for a week or so here)
<kees> stgraber: ah, cool. I can't find the PPA ...
<kees> oh, wait, maybe
<kees> me checks ~canonical-kernel-team/ubuntu/trusty 
<stgraber> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa
<fibbance> In 14.10, what is the difference between 'linux-generic' and 'linux-kernel-generic'? It seems that 'linux-kernel-generic' depends on 3.13, while 'linux-generic' depends on 3.16. Is there any other difference?
<kees> stgraber: cool, yeah, got it now. thanks!
<kees> fibbance: I don't see that on trusty.
<kees> $ apt-cache show linux-generic | grep -m1 Version
<kees> Version: 3.13.0.39.46
<fibbance> I'm on utopic
<kees> fibbance: I think you've got a left-over package. I don't see linux-kernel-generic on utopic
<kees> apt-cache show linux-kernel-generic | grep -m1 Version
<kees> E: No packages found
<fibbance> http://paste.ubuntu.com/8853901/
<fibbance> This is from apt-cache show linux-generic linux-kernel-generic | pastebinit
<kees> Maintainer: Clement Lefebvre <root@linuxmint.com>
<kees> you've got some other repositories...
<fibbance> Oh, didn't notice that. This was originally a Mint install, I switched to Ubuntu in-place & then upgraded to utopic
<kees> double-check your /etc/apt/sources.list and /etc/apt/sources.list.d/ for left overs, I'd say. then "apt-get update"
<fibbance> I removed all the other sources before upgrading, and just checked that it is indeed the case. Is linux-generic the default kernel metapackage?
<apw> yep, that is the default kernel meta
<fibbance> Thank you
<fibbance> Normally Debian doesn't remove old kernels when new versions are installed, so I wonder why those two can't be installed at the same time.
<apw> fibbance, which two ?
<fibbance> linux-generic & linux-kernel-generic
<apw> what happens if you try
<apw> oh i bet they both depend on linux-image-generic but different ones
<fibbance> From aptitude: linux-kernel-generic : Conflicts: linux-generic but 3.16.0.25.26 is to be installed.
<apw> well that sounds like it has an explicit Conflicts: probabally from a debian kernle name change
<apw> trying to install a debian and ubuntu kernel at the smae time does sound like asking for trouble
<apw> though of course rmeoving just the metas doesn't actually remove the kernel either
<fibbance> apw: the kernels are from ubuntu & mint - http://paste.ubuntu.com/8853901/
<kees> stgraber: wooo, thanks. rockin' 3.16 now. 
<kees> "kaslr" on the commandline works. :) :)
<stgraber> nice :)
<apw> fibbance, ok the mint kernel explicityly conflicts with ours, presumably to prevent its install
<apw> or because they use that to uninstall ours when they install theirs
<fibbance> That makes sense
<apw> which makes some sense if thye are using an ubuntu base, but want to control when you get our kernels
<apw> and ours doesn't conflict with theirs, because we have no reason to
<fibbance> Although only the metapackage is removed, not the kernel itself
<apw> right, that is the way with kernels
<apw> and indeed is how the "some old kernles" are maintained
<fibbance> brb rebooting into new kernel
<fibbance> That seems to have worked :)
<fibbance> Is there a reason ubuntu-desktop (or some other such package) doesn't depend on linux-generic?
<tseliot> apw: JFYI I've just fixed fglrx and nvidia for Linux 3.18. I only have to fix the nvidia legacy (304) driver and broadcom
<apw> fibbance (N,BFTL), because different arches have different kernels but the same desktop
<infinity> zequence: There's a new precise kernel because reasons (sorry), if you have time to do another rebase?
<infinity> zequence: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1390177
<ubot5> Ubuntu bug 1390177 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
#ubuntu-kernel 2014-11-07
<lfaraone> Is there any way to verify the authenticity of kernels uploaded to http://kernel.ubuntu.com/~kernel-ppa ? 
<lfaraone> I'm wary of downloading over HTTP and not being able to check a signature. 
 * lfaraone waves at apw
<td1212> Hello
<td1212> I have dell 5737 laptop and since the ubuntu 14.04 upgrade it consistently frezes as soon as resuming from suspend
<td1212> I tried pretty much all upstream kernels since 14.04 - the same
<td1212> My quick question - can I keep loading old kernel 3.11.10 with new 14.10 release?
<td1212> anyone?
<apw> td1212 (N,BFTL), that sounds like an issue i have been tracking recently and may be fixed in an update shortly, in the short term yes you can run the older kerenl but it won't get updated
<jibel> apw, morning. I added DKMS tests for Vivid. They'll appear on next run of the job. I kept Utopic until it's EOL in July next year.
<apw> jibel, most excellent, thank you for that
<apw> jibel, did you add PPA as well ?
<jibel> apw, yes
<apw> great :)
<apw> jibel, what triggers those dkms jobs, is it next kernel change?
<jibel> apw, Daily check of a kernel or dkms module update.
<apw> jibel, ok so "sometime in the next 24 hours" we'd expect a baseline to drop out.  great
<jibel> apw, every day at 2:23UTC
<jibel> apw, everything seems quiet now, I'll start a run of vivid.
<apw> hey thanks
<apw> jibel, the replication for those jobs, is that something which is time based, or is that something which also needs adding
<jibel> apw, if by replication you mean publication to jenkins.qa.ubuntu.com, it's automated. the CI team has to create the views manually
<jibel> I sent an RT for that
<apw> jibel, i do, and great
#ubuntu-kernel 2014-11-08
<kungr> anyone know a link for a tutorial on how to compile a kernel in ubuntu in a fakeroot?
#ubuntu-kernel 2015-11-02
<kharnov> hey, kernel dudes. the amd64 build for 4.3 didn't upload, same problem as last week?
<who_me> apw: building 4.3 mainline still fails. 4.3-rc7 seems to have built fine after the fix... but looking at debian/rules, there's no "do_mainline_build"
<who_me> I wonder whether actually installing ZFS would work around this build issue.
<exslackwarer> Hi! I have a bug!
<exslackwarer> Take a look at the AMD64 build log for Ubuntu's mainline 4.3-unstable. http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3-unstable/BUILD.LOG.amd64 
<exslackwarer> It results in an error at the end, where Rsync supposedly uploads the built packages.
<exslackwarer> As such there is no AMD64 build available on http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3-unstable/  !
<apw> crshman, i have fixed it 3 times already, dammmit computer do what i say
<who_me> heh
<who_me> it's weird that 4.3-rc7 was fine but 4.3 seems to be using the old rules/template. this also affects the daily builds
<who_me> they've been failing to build 64bit packages for more than a week now
<apw> who_me, no installing zfs would not help, it is a lack of zfs source in the tree you are building which is breaking the packaging
<apw> a fix for which was commited and lost twice at least, grrr
<apw> ok the mainline builds ought to be re-fixed and rebuilding
<cristian_c> jsalisbury: hi
<who_me> apw, 4.3 mainline built. thank you for fixing it :)
#ubuntu-kernel 2015-11-03
<ogra_> rtg, do you happen to be around ? seems there is something broken with triggers in the linux-raspi2 package ...  https://launchpadlibrarian.net/224109673/buildlog_ubuntu_xenial_armhf_ubuntu-core-system-image_BUILDING.txt.gz (i thought it was 1:1 based on -generric packaging which would enforce the trigger execution ?)
<rtg> ogra_, I don't think we've even upload raspi2 to xenial yet. I'll sic Paolo on it. 
<ogra_> rtg, it was synced over from wily 
<ogra_> ppisati, yo 
<apw> ogra_, which triggers ?
<ogra_> apw, postinst initrd creation doesnt run 
<ogra_> https://launchpadlibrarian.net/224109673/buildlog_ubuntu_xenial_armhf_ubuntu-core-system-image_BUILDING.txt.gz
<ogra_> (see the bottom)
<ogra_> Setting up linux-image-4.2.0-1013-raspi2 (4.2.0-1013.19) ...
<ogra_> Running depmod.
<ogra_> update-initramfs: deferring update (hook will be called later)
<ogra_> cp: cannot stat '/boot/initrd.img-4.2.0-1013-raspi2': No such file or directory
<ogra_> Failed to copy /boot/initrd.img-4.2.0-1013-raspi2 to /boot/initrd.img at /var/lib/dpkg/info/linux-image-4.2.0-1013-raspi2.postinst line 745.
<ogra_> dpkg: error processing package linux-image-4.2.0-1013-raspi2 (--configure):
<ogra_> it seems to completely skip /etc/kernel/postinst.d/initramfs-tools for some reason
<ogra_> (if you scroll up in the log you see the same thing work for -generic)
<apw> ogra_, it decided this was a delayable initramfs build
<apw> update-initramfs: deferring update (hook will be called later)
<ogra_> apw, -generic prints the same and then executes /etc/kernel/postinst.d/initramfs-tools
<ogra_> before trying to copy the initrd 
<ogra_> update-initramfs: deferring update (hook will be called later)
<ogra_> Examining /etc/kernel/postinst.d.
<ogra_> run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.2.0-16-generic /boot/vmlinuz-4.2.0-16-generic
<ogra_> run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.2.0-16-generic /boot/vmlinuz-4.2.0-16-generic
<ogra_> thats a bit further up in the log 
<apw> ogra_, who is doing that copy ?
<ogra_> so it works for generic but not for raspi2 in the same chroot 
<apw> ogra_, that is not a "standard" behavour
<ogra_> apw, your postinst
<ogra_> in line 745 obviously :)
<apw> we would not normally copy it
<ogra_> well, i see the code here 
<apw> we don't make the name "/boot/initrd.img" on a default install
<ogra_> Failed to copy /boot/initrd.img-4.2.0-1013-raspi2 to /boot/initrd.img at /var/lib/dpkg/info/linux-image-4.2.0-1013-raspi2.postinst line 745.
<ogra_> well, thats definitely your postinst 
<apw> ogra_, indeed, i am not disputing it, i am saying we don't normally copy it, we normally symlink it, which isn't order dependant
<ogra_> right, looks like it uses a wrong code path or some such 
<apw> ogra_, so the / and /boot we are building here, what are they, what filesystem type etc
<apw> ogra_, what is in your /etc/kernel.conf in that filesystem
<ogra_> apw, no idea, it is the rootfs of an image build ... the config should be fine and -generic installs fine on the same setup (as i said, a few lines up -generic gets installed in the log)
<apw> ogra_, can we find out ?
<ogra_> apw, thats quite some work and hackery to livecd-rootfs, but yes, i can .,.. just takes long
<apw> ogra_, hmm
<apw> ogra_, so the -generic which works, was that a fresh install or an upgrade, was there a generic kernle in whatever you started from ?
<ogra_> apw, this is a livefs build, it starts from a basic debootstrap 
<ogra_> installs the ubuntu-core task and then installs kernel packages 
<apw> ogasawara, all starting with an empty directory i assume
<apw> ogra_, ^^
<apw> ogra_, and i assume this is the "same" as wily was and it works there ?
<ogra_> apw, well, except that i additionaly try to install the raspi package now to create a device tarball from that later 
<ogra_> it works, yes
<apw> ogra_, ok so the code is trying to use "cp" because when we try and buid the symlink called /initrd.img and that is already present and is already not a symlink
<apw> ogra_, what that file is is hard to understand given you have no kernel installed when you do that, right ?
<ogra_> apw, so i apt-get purge linux-image-*-generic ... then i install linux-raspi2 
<ogra_> technically it should remove all symlinks 
<ogra_> and re-create them
<apw> update-initramfs: diverted by livecd-rootfs (will be called later)
<apw> ogra_, what is that all about
<ogra_> thats normal, livecd-toofs does that ... but wont matter for our issue
<ogra_> (that diversion is gone at the point where i install the kernel package)
<apw> ogra_, in the generic it appears to be still active when the kernel was installed
<apw> ogra_, yeah it was still in place when the delayed trigger in the generic case was called
<ogra_> well, /etc/kernel/postinst.d/initramfs-tools generates the initrd just fine for -generic ... with or without the diversion 
<apw> ogra_, but what does it divert it to
<ogra_> it diverts the update-initramfs executable to /bin/true
<ogra_> but thats moot 
<ogra_> as i said, -generic creates the initrd at package install time 
<apw> why it is moot, we are doing the initramfs handling completely different in the two cases
<ogra_> (and it woorks fine in all image builds)
<apw> and the working one has the divert and then makes the initrd itself (i assume)
<apw> whereas the one which does not, doesn't work
<ogra_> the working one execs /etc/kernel/postinst.d ... the non working one ignores that comepletely 
<ogra_> totally independent of that diversion 
<apw> ogra_, the non working one fails before it calls those hooks because it found a /initrd.img which was not a symlink, and so it tried to cp, and failed ... so processing is aborted before we call out to the hooks
<ogra_> apw, hmm, so me simply doing an "rm /initrd.img" before installing the package would help ? 
<ogra_> thats trivially added to the code :)
<apw> ogra_, maybe, i would love you to do an ls -l /initrd.img as well so we can find out what it is
<apw> ogra_, why are we installing -generic and then ripping it anyhow, why arn't we just seeding he right packages i wonder ?
<ogra_> (sadly the armhf image builder doesnt like me now and wants to delay the image build by 35min :/ )
<ogra_> apw, i plan to do all device tarball generation from the code i'm currently adding ... to not break beaglebone snappy i simpply left the old code in place for now ... later this will be a loop over the different kernels 
<ogra_> the current snappy installs the kernel in the rootfs, then does a ton of hackery to create a device tarball from it and remove all traces of the kernel from the rootfs again ... i'm currently trying to move all this to a point after the rootfs tarball was created (so abusing the still existing builkd chroot) to get rid of all that awful hackery
<cristian_c> jsalisbury: hi
<ogra_> apw, hmm ... could it be that the postinst parses /etc/kernel-img.conf first ? 
<ogra_> (we dont configure that file on snappy rootfses ... so there is no "do_initrd = yes" in it)
<ogra_> (though this wouldnt explain the discrepancy to -generic )
<ogra_> apw, ok, test build has run, there is definitely no /initrd.img in the rootfs
<apw> ogra_, and it worked or failed ?
<ogra_> apw, well, forget about it ... what i'm trying to do here is to re-use the build chroot from the snappy rootfs ... it didnt strike me until 1h ago that we remove half of apt and dpkg .... which means ... well .... you know ... *blush*
<apw> ogra_, ahh heh, oops
#ubuntu-kernel 2015-11-04
<catbus1> Dear Ubuntu kernel team, I am working with the Cisco SNIC (SCSI NIC) team. SNIC is a new driver accepted in upstream 4.2.4. I see our latest Wily kernel is based on upstream 4.2.3. Can someone please tell me about when we will be based on 4.2.4? Or should I work with them to submit a patch to Ubuntu kernel? 
<henrix> catbus1: 4.2.4 (and 4.2.5) patches should be applied to the wily kernel soon(ish).  next week we start a new 3-week SRU cycle, and usually apply stable patches to our kernels during the 1st week
<catbus1> henrix: Thank you. One more question, is a new driver consider a stable patch? It's accepted in 4.2.4: http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=24136f 2c0b3bd55d98bdfe097331a4ab7eb1869b
<catbus1> probably this is a better link: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/scsi/snic?id=refs/tags/v4.2.4
<henrix> catbus1: new drivers/features are not acceptable for stable kernels.  but the wily kernel is *not* a stable kernel -- we simply apply upstream 4.2 stable kernel patches, but it has lots of other ubuntu-specific patches
<catbus1> henrix: Just want to make sure I fully understand this. So snic will be in wily kernel after the next SRU cycle. The wily kernel will become HWE kernel for 14.04 in Jan/Feb. The snic driver will be in-box in 14.04.4, right? 
<henrix> catbus1: correct.  and although i'm just not sure about the next 14.04 point-release dates, it's likely that the linux-lts-wily kernel will be available before that ;)
<catbus1> henrix: Great, thank you very much. 
<rtg> kamal, http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=2459ee8651dc5ab72790c2ffa99af288c7641b64 should go to 4.2 stable
<kamal> rtg, 4.2-stable is still gregkh's responsibility.  That commit bears a Fixes: line, but the commit it says it fixes didn't land until 4.3-rc1 ...
<kamal> rtg, so how sure are you that its actually relevant for 4.2?   I expect that gregkh will _not_ apply that one to 4.2 automatically.
<rtg> kamal, I've already submitted the patch on the k-team list. It appears to fix an issue related to bug #1499089
<ubot5> bug 1499089 in linux (Ubuntu Wily) "Please enable kconfig X86_LEGACY_VM86 for i386" [Wishlist,Fix released] https://launchpad.net/bugs/1499089
<kamal> rtg, ok relevant for wily, but not for 4.2 mainline -- got it.   ok, issue resolved   :-)
#ubuntu-kernel 2015-11-05
<Kano> hi, will you update 4.2 to 4.2.5?
<ohsix> heheh
<apw> Kano, yes that will happen most likely in the next sru round
#ubuntu-kernel 2015-11-06
<bananapie> I did a git checkout of the kernel sources for wily. Is it possible to recompile a single driver ( gpu/radeon ) without recompiling everything? I want to do testing on the driver based on comments from freedesktop.org, and I don't want to spend hours compiling the kernel.
<hallyn> apw: anyone on the team well-versed in the cgroup code?
<apw> hallyn, well versed prolly not, but ask and we cna think on it ... 
#ubuntu-kernel 2015-11-08
<luc4> Hello! I read that before reporting bugs to the kernel I should test the lastest mainline kernel. So should I install 4.3 from here http://kernel.ubuntu.com/~kernel-ppa/mainline/? Is this correct?
<TJ-> luc4: Correct
<luc4> TJ-: thanks
#ubuntu-kernel 2016-11-07
<zma> when is xenial kernel expected to be updated from 4.4.0.45? The very next change in linux kernel has a patch I need.
<cachio> hi, ogra_ 
<cachio> ogra_, I am working defining some KPIs
<cachio> ogra_, some of those kpis could be extended easily to snappy, in fact we plan to run those in pi3 and dragonboard
<cachio> ogra_, are you planing to run any KPIs for snappy? I would like to see if our tests could be reused for that too
<apw> zma, "very soon" we are finishing testing up testing on -46 at the moment
<zma> @apw, thanks!
<phil42> when was the last how-to-compile-a-kernel-the-ubuntu-way published?
<WeiJunLi> i ve downloaded the kernel source did make config and now i want to load this kernel compiled on boot, should I replace the folders i have on /usr/src by this one?
<phil42> make config is only the first step
<phil42> i should do one just to make sure i still can
<WeiJunLi> well you'r right im having an error when doing make
<WeiJunLi> phil42: http://dpaste.com/0S7HHV4
<WeiJunLi> whats your thoughts about that
<WeiJunLi> how can i pass that
<WeiJunLi> i want to enable kasan (i've enabled it, on .config  it is =y) so im not sure about that error on line 6
<WeiJunLi> can i ignore that?
<phil42> i don't know. maybe someone here can help
#ubuntu-kernel 2016-11-08
<WeiJunLi> ive compiled the ubuntu kernel succesfully, how do I use this specific kernel?  
<WeiJunLi> ive compiled ubuntu kernel and now i updated grub but when i try to boot i have this issue http://imgur.com/a/hXjuk ? hints pls 
<ogra_> hmm, building an initrd with a non numeric version (i.e. you want an initrd being called initrd.img-debug without containing modules) results in scary "depmod: ERROR: Bad version passed debug"  ... i wonder how hard it would be to turn that rather into "WARNING" so it looks less scary
#ubuntu-kernel 2016-11-09
<TJ-> Any ideas why (iwlwifi) would fail to locate its firmware during boot, but does after a "modprobe -r  && modprobe" later? I confirmed one of the firmware files it asks for is in the initrd in case it was an early-boot issue.
#ubuntu-kernel 2016-11-10
<hallyn> Hm, yakkety-updates kernel is failing to build locally,
<hallyn> cc1: fatal error: /home/ubuntu/linux-4.8.0/ubuntu/vbox/vboxguest/include/VBox/VBoxGuestMangling.h: No such file or directory
<hallyn> compilation terminated.
 * hallyn wonders whether and how he messed that up
<ginggs> jsalisbury: hi, what needs to happen for LP: #1630063 ?
<ubot5`> Launchpad bug 1630063 in linux (Ubuntu Yakkety) "specific USB devices disconnect and don't reconnect" [Medium,In progress] https://launchpad.net/bugs/1630063
<WeiJunLi> what will be the kernel version of this https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial , 4.8.0 ?
<apw> WeiJunLi, the master branch of that will be 4.4, the HWE kernel will be 4.8 initially
<JanC> is there any chance we can get an updated rtl8812au (rtl8812au-dkms) package?
<JanC> the current one doesn't build...
<JanC> latest from https://github.com/diederikdehaas/rtl8812AU.git builds & works fine
<JanC> seems like pretty much all these bugs are about that: https://bugs.launchpad.net/ubuntu/+source/rtl8812au
<JanC> v4.3.14 of the driver seems to work fine
#ubuntu-kernel 2016-11-11
<hallyn> rtg: is a local build (fakeroot debian/rules binary-generic) of linux in yakkety-updates expected to work right now?
<rtg> hallyn, I would expect it to. Are you building from a source package or from the git repo ?
<hallyn> pull-lp-source linux yakkety-updates
<hallyn> edit debian/rules and debian/scripts/module-check, and build.  nothing more.  in a yakkety vm
<hallyn> well, container
<hallyn> rtg: ^
<hallyn> i don't relaly need that specific one, maybe i should use z instead
<rtg> hallyn, they should both build successfully
<hallyn> well, in fact /home/ubuntu/linux-4.8.0/ubuntu/vbox/vboxguest/include/VBox/VBoxGuestMangling.h does not exist and vbox makefiles do seem to reference it
<rtg> hallyn, leeme repro
<rtg> lemme even
<rtg> hallyn, ok, looks like a packaging issue.
<hallyn> rtg: ok cool, thanks.  i'll just wait then
<rtg> hallyn, you can build from the repo in the meantime. 
<rtg> hallyn, also, please file a bug and assign me to it. I've kind of got my hands full for  awhile
<hallyn> rtg: ok will do
#ubuntu-kernel 2016-11-12
<sacarde_> hi
<sacarde_> I have an error building module bochs-drm from source 4.8.0
<sacarde_> drivers/gpu/drm/bochs/bochs_drv.c:1:0: error: code model kernel does not support PIC mode
<sacarde_> I run this command:
<sacarde_> make M=drivers/gpu/drm/bochs
<sacarde_> what I wrong?
#ubuntu-kernel 2016-11-13
<sacarde> hi
<sacarde> I read this problem: https://wiki.ubuntu.com/SecurityTeam/PIE
<sacarde> but I dont understand the solution
<JanC> sacarde: the issues on that page are more something the security team works on; they are in #ubuntu-hardened
<gart> i yam popeye of borg.  resistansk is fruitile. yew will be akskimilgrated.  heh hehehhe heheheheheheh
#ubuntu-kernel 2017-11-07
<sforshee> jjohansen: I think I forgot to ask you about this a couple of weeks ago when it happened. I had to drop "UBUNTU: SAUCE: apparmor: af_unix mediation" in 4.14 after Linus reverted that one patch, but wanted to know if you'd prefer I re-apply both of those patches.
<jjohansen> sforshee: yes reapply please, Ubuntu has always had the "regression"
<sforshee> ack, thanks
<jjohansen> sforshee: specifically the regression is to do with userspace can be configured to break users (deny access) booting into new kernels if they don't have updated policy.
<jjohansen> - Ubuntu has updated policy, and has been running ahead of the kernel
<jjohansen> - we have the freedom to also configure userspace so it doesn't break by pinning policy versions (assuming we didn't have updated policy)
<jjohansen> - suse's case was exacerbated by not having picked up a fix in userspace
#ubuntu-kernel 2017-11-10
<mike13b13> Hi, can someone help me to debug s2disk/hibernate that randomly hangs on 0% when saving image plz?
<cking> we have notes on S3 debugging https://wiki.ubuntu.com/DebuggingKernelSuspend - but they are quite old
<mike13b13> thanks cking!
<cking> mike13b13, hope that still works OK 
