#ubuntu-kernel 2005-06-06
<zul> dont really remember check the patch
<fabbione> morning
<zul> hey
<zul> me thinks i desperately need a new job
<fabbione> i need a cleaning lady.....
<fabbione> do you have big bobbies? :P
<zul> :P
<fabbione> if so you are hired ;)
<zul> i have man boobies if that counts
<zul> oh yeah are you going to pull from my archive soon?
<fabbione> zul: today i need to so userland... i will do kernel tomorrow
<fabbione> but yes.. i will pull from your archive soon
<zul> ok goody...im going to bed then :)
<fabbione> ehe good night
<zul> hey
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> zul: pretty ok.. i think i have almost done packaging the first version of redhat cluster
<fabbione> i only need to change again the branch that's in the kernel
<fabbione> because upstream sucks
<fabbione> but i am getting use to it :)
<zul> cool..im watching guadec
<zul> or trying to
<fabbione> i am taking a look at Grid Engine in the meanwhile :)
<fabbione> http://gridengine.sunsource.net/
<zul> im trying my hand at packaging
<zul> heh the ogg of mark at guadec is basically people in the background trying to figure out why the settings are not working...damn it
<chmj> fabbione, you got mail 
<fabbione> chmj: looks ok to me, but please mail kernel-team so that we can do open discussion
<zul> oooh....what what? :)
<chmj> fabbione, ok 
<zul> wtf? E: dmraid: FSSTND-dir-in-usr usr/man/
<fabbione> man pages should be in /usr/share/man/
<fabbione> just configure it to install man pages in the right place :)
<jbailey> There's a kernel-team mailing list?
<jbailey> Hmm
* jbailey wonders if he should subscribe to yet another mailing list that he probably won't actually red.
<jbailey> +a
<infinity> It gets no traffic anyway.  Go nuts.
<dilinger> sure it does.  that's where i file bugs ;)
<infinity> <smirk>
<infinity> Shouldn't you be off having a holiday or something?
<dilinger> i am holidaying
<dilinger> and by holidaying, i mean unpacking my stuff and going out to buy more stuff like a shower curtain  so i can actually shower
<infinity> You moved?
<infinity> Further north again?
<dilinger> nope
<dilinger> south this time
<dilinger> way south
<dilinger> nyc
<infinity> Huzzah!
<infinity> Where in the city did you end up?
<dilinger> queens
<infinity> How far out?
<infinity> (Not like anything in NYC is far out, really)
<dilinger> http://maps.google.com/maps?q=1670+gates+ave,+11385&spn=0.025879,0.059720&hl=en
<dilinger> and there's apparently a parade going down the street
<infinity> That seems suspiciously far from a subway line.
<infinity> Otherwise, looks cool.
<dilinger> it's a block away from a subway
<dilinger> L train
<infinity> Oh, then I can't read google maps. :)
<infinity> So, can we crash with you when we come visit?
<zul> party party party
<zul> or sort of
<dilinger> infinity: sure
<infinity> Rock.
<infinity> Looks like a decent location.  Though, I can't picture the neighboorhood in my head.
<infinity> Nice enough to cost a bit, but crap enough to not be too expensive? :)
<infinity> Also, that's a lot of cemeteries you have...
<dilinger> infinity: the better to.. uh.. something you with, my dear
<dilinger> it's a decent location.  apparently lots of ecuadorians around, which i wasn't expecting
<dilinger> more expensive than i wanted to pay, but still reasonably priced for what i'm getting
<infinity> Sounds about right.
<jbailey> I don't think places in NYC are ever in the range of what one 'wants to pay'
<jbailey> My place in the Bronx was still $700USD a month or somethign like that.  Just insane.
<zul> gah...description-synopsis-starts-with-an-article
#ubuntu-kernel 2005-06-07
<infinity> jbailey : You'd complain about 700 USD a month?
<infinity> jbailey : I pay about 1250 AUD per month in Melbourne.
<dilinger> jbailey: my rent is double that :/
<infinity> jbailey : Which is a LOT more than 700 USD.
* infinity would be pretty happy to find a cardboard box in NYC for 700 USD...
<zul> heh my mortagage is more than that :)
<fabbione> morning
<zul> hey
<fabbione> hey zul
<zul> how is it going?
<fabbione> dunno... just woke up
<jbailey> infinity: In a neighbourhood that I moved out of because there was a shooting?  Yes, the price is higher than I'd like to pay.
<fabbione> jbailey morning 
<jbailey> Heya Fabio
<fabbione> hmm i have the feeling that .12 is slightly slowest on disk I/O
<fabbione> zul: nice changes in the kernel dude.. but i would love if you can cover a bit more than i386....
<fabbione> can you give me the basic infrastructure to add -dbg for amd64 and possibly the other arches?
<fabbione> (skip ppc for now since we need to make the ppc -> ppc64 transition first)
<zul> hey
<zul> fabbione: i dont have an amd64 to test...so im not sure kdb will work on amd64
<zul> but i can do a config for 1,3 though
<fabbione> zul: just prepare what you think is right
<zul> ok
<fabbione> also for ia64/sparc/hppa
<fabbione> we will get people to test them later
<fabbione> but if they are not there, it will take too long to explain them the process
<zul> okie dokie..
<zul> for 1,2 or 1,3?
<fabbione> 1.3
<zul> morning btw ok
<fabbione> i might need to get 1.2 out pretty soon
<zul> possible free laptop...hell ya ill join :)
<zul> lol...wallace and grommit
<zul> fabbione: see this? http://lists.ubuntu.com/archives/ubuntu-devel/2005-May/007830.html
<zul> im thinking no..
* #ubuntu-kernel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
(zul/#ubuntu-kernel) i can probably throw up a debug kernel for you later tonight on my website
(Mithrandir/#ubuntu-kernel) yes please.
(fabbione/#ubuntu-kernel) acx sucks..
(fabbione/#ubuntu-kernel) you can problably enable the debugging for that driver
<Mithrandir> I know that acx sucks.  That's even more of a reason to have that card. :P
<zul> Mithrandir: which amd kernel are you using?
<Mithrandir> 21:36 < Mithrandir> ii  linux-image-2. 2.6.11.93-1.1  Linux kernel image for version 2.6.12 on AMD
<Mithrandir> 21:36 < Mithrandir> (it's amd64-k8)
<zul> okie dokie
<zul> Mithrandir: building now
<zul> fabbione: i think i made a mistake on the kdb stuff the debug kernels dont have it enabled i thought i did the commit on my tree i guess it didnt
#ubuntu-kernel 2005-06-08
<jbailey> Anyone know if there
<jbailey> 's a sane way to get the driver information for the SCSI or IDE layer from sysfs?  I seem to get as far as finding out that the [sh] da wasn't ide-disk or sd, and not any further.
<jbailey> Oh, and joy.  It calls it 'sd' instead of 'sd_mod'
<zul>  /sys/block
<jbailey> zul: /sys/block/sda/device/driver just points to sd.
<zul> is this that scsi card bug that i cced you about?
<jbailey> Nope.  Did you cc: me on something?
* jbailey looks.
<jbailey> It's initramfs autodetection without using /proc/scsi
<jbailey> I don't see an email from you...
<zul> i cced you from bugzilla
<jbailey> Ah, lemme check that folder.
<zul> there is  a program called lsscsi which works with sysfs
<zul> http://sg.torque.net/scsi/lsscsi.html
<jbailey> Oo, appears to be in breezy.
<zul> have you tried /sys/host/channel/id/lun or something like that
<jbailey> I haven't gone that need.  I got caught up trying to figure out how to work find. =)
<jbailey> Nice, lsscsi will give me the info.
<jbailey> So maybe I can use sysfsutils to figure it out rather than diving through symlinks.
<zul> there is a library sysfs as well
<jbailey> zul: Yeah, I might have to resort to that, but Id' rather not.  It's all done in shell so far.
<jbailey> zul: The idea is that I want to use hotplug-ng in the initramfs, but it would be nice to continue to support some sort of hard autodetection.
<jbailey> It think I've figured it out for scsi, but it looks like the IDE layer might suck too much.
<mark_> hi, is this a good place to ask how i can gather more data to add to a bug i submitted a while ago
<mark_> things like crash reports etc. its a problem with a sound module.
<zul> heh...someone is "forking" the kernel lol good luck
<fabbione> morning
<dilinger> ugh, yes it is :/
<TheMuso> .cl
<TheMuso> argh
<zul> hey
<fabbione> hey zul
<zul> hey fabbione 
<zul> what time is the meeting today?
<chmj> 16:00, I think 
<fabbione> 16:00 UTC
<zul> coolio
<infinity> There's a kernel meeting today?
<jbailey> infinity: Are you in the same timezone as Sydney?
<jbailey> infinity: 'cause we know you love 2am meetings. =)
<fabbione> infinity: yes at 16:00 UTC
<infinity> Yeah, I'm in the same TZ as Sydney.
<infinity> You're all cocks.
<infinity> The end.
<infinity> (I was going to stay up anyway, to attent the backports meeting)
<infinity> s/attent/attend/
<jbailey> infinity: We need to get grrlz on the Kernel Team just so you can't say that anymore. =)
<infinity> Because it's politically incorrect, or factually so?
<fabbione> ahaha
<infinity> I'm pretty sure that when used as a derogatory term, "cock" can apply to just about anyone, regardless of their genital trappings.
<fabbione> at what time is the backports meeting?
<lamont> kernel meeting?
<lamont> ouch
<lamont> 1600 UTC --> I will attend in spirit only, I fear.
<fabbione> lamont: i guess you will be at the office...
<lamont> and dealing with administrivia, I fully expect.
<fabbione> have fun :)
<lamont> I'm hoping to really be online sometime after lunch
<lamont> yeah
* lamont flees for real
<infinity> fabbione : Backports is 1700 UTC.
<fabbione> infinity: good.. because the kernel team will not last longer than one hour.. i hope
<infinity> Looks like I won't be getting any sleep tonight.  Oh well.
<infinity> Gives me time to rebuilt firefox over and over and over again until I finally have something to upload.
<fabbione> infinity: you need no sleep :)
<infinity> That's what I keep saying, right before I pass out.
* dilinger smirks.  genital trappings?
<chmj> hmmm 
<chmj> if i don't have transport, I'm not gonna make it to the meeting also 
<fabbione> chmj: uh?
<fabbione> chmj: well if you could have told a bit in advance we could have changed the time
<chmj> fabbione: I arranged transport with someone, now the guy seems unsure, how dissappointing 
<fabbione> chmj: try to convince him again ;)
<chmj> I'm trying 
<zul> heh they are trying to backport the kernel
<chmj> who is 'they' ?
<zul> backport people
<fabbione> eh?
<fabbione> where?
<fabbione> lart them!
<fabbione> kill them!
<zul> gimme a sec...ill dig it up
<fabbione> they must not backport the kernel
<fabbione> ehhe
<zul> http://www.ubuntuforums.org/showthread.php?t=15913
<chmj> shoot them !
<fabbione> oh god
<zul> *shudder*
<zul> so who is suppose to be coming to the backport meeting ;)
<fabbione> i am going :)
<zul> so am i
<fabbione> i need to see what they have in mind
<fabbione> and kindly ask not to backport the kernel :)
<fabbione> because they do not know what they are doing
<zul> ya think?
<fabbione> no.. i am sure
<zul> ok good...just making sure :)
<chmj> lol 
<chmj> let them do it, its gonna be fun to watch 
<chmj> unless you worried about them pinging you aboutit 
<infinity> I'd be worried about bug reports relating to it.
<fabbione> at the first pint i will make the kernel unportable
<infinity> I already have some bug reports with text like "I haven't changed anything except to upgrade to some random backported packages..."
<zul> see thats why users are bad
<chmj> aren't customers always right ?
<chmj> :-P 
<zul> no i learned that the hard way when i was doing a customer service test for an interview
<infinity> I just love how people will add any random repository to their sources.list until stuff appears to finally work.
<zul> its the only way :)
<infinity> "Yeah, just add potato, woody, sarge, warty, hoary, and these 5 sources from apt-get.org, and you'll get most of the packages you need... Oh, and download this .deb and install it by hand"
<infinity> Someone hold me.
<chmj> hahaha
<zul> im not a touchy feely person infinity 
<fabbione> infinity: ahhahahahahhaa
<fabbione> bug number?
<infinity> Oh, no, that was me paraphrasing the forums. :)
<fabbione> ahah
<infinity> Why find bugs in your backported packages when you can just tell people to install other packages to satisfy your bogus dependencies?  Yay!
<infinity> I have a feeling this backports meeting will be frustrating.
<infinity> I'll have to hold my tongue.  A lot.
<fabbione> do will i
<chmj> sound too good to miss 
<infinity> Backporting kernel packages is just plain retarded, though.  If users really need new kernels, kernel-package is there for a reason, compile your own and have some control over what you break.  Don't let someone else break it all for you.
<infinity> In that thread up there <points>, I love the one user's laundry list of stuff that stopped working after the upgrade.
<infinity> (last page of the thread)
<jbailey> My favourite is the people who loaded a new glibc and then their system stopped working after the next kernel upgrade.
<jbailey> They give me WARM and FUZZIES.
<infinity> A new... glibc?
<infinity> Doesn't that defeat the purpose of backporting?
<jbailey> infinity: Pulled it from breezy by the looks of it, because backports didn't have what they wanted. =(
<infinity> Once you backport glibc, you may as well, y'know.. UPGRADE.
<fabbione> infinity: you kidding right?
<infinity> jbailey : Oh.  I see. :)
<infinity> jbailey : Even funnier. :)
<fabbione> it's soooooo 31337 to run the latest glibc
<jbailey> Erp, apt-get install 'git' isn't quite what I'd hoped it was.
<fabbione>  _____ _ _______________ 
<fabbione> |___ // |___ /___ /___  |
<fabbione>   |_ \| | |_ \ |_ \  / / 
<fabbione>  ___) | |___) |__) |/ /  
<fabbione> |____/|_|____/____//_/   
<fabbione> 
<fabbione> jbailey: pkg is cogito
<jbailey> fabbione: Thanks.
<infinity> Although git is fun too.
* jbailey used to work for cogitoinc.com and wonders when the trademark lawsuits will start *sigh*
<fabbione> who needs a wake up text message via irc?
<infinity> I'll need a /msg, I'm sure.
* infinity claps.
<fabbione> damn FEENODE
<fabbione> no wake up message
<fabbione> damn FEENODE
<fabbione> no wake up message
<fabbione> anyway
<fabbione> i am off for a little while before the meeting
<chmj> hehe 
<chmj> jbailey, never tried git ?
<jbailey> chmj: Nope.  I'm trying to get a changelog for klibc, so figured I'd try the other git. =)
* jbailey backs away slowly.
<dilinger> i need those kick-ass new glibc features, though!
<fabbione> dilinger: ehehhe
<jbailey> Reminds me that I need to do a glibc upload to fix gdb on ppc.
<fabbione> mu4 syst3m runs s0 much f4st3r w1th th15 31337 gl1bc
<jbailey> I figured I'd give it some time so that Fabio's machine could catch up with the rest of the archive for a bit. =)
<fabbione> jbailey: oh ehehhe
<fabbione> sparc is looking good at the moment
<fabbione> there are really few pkgs left that still needs manual love
<jbailey> fabbione: Cool.  I'll do the gdb fix, the ia64 binutils 2.16 fix, and drop pre-v9 support on sparc in one pass, then.
<fabbione> jbailey: works for me
<fabbione> jbailey: plus most of the stuff is ccache right now
<fabbione> so it will be pretty fast to do that
<jbailey> Do far my experiments with ccache don't seem to get a high hit rate on glibc.
<fabbione> no, but i get high rates on all the other pkgs :)
<fabbione> given that doko doesn't upload gcc :)
<jbailey> Right. =)
<fabbione> speaking of which.. i will need to increase the cache size
<jbailey> Yeah, and gcc's never ccachable.
<fabbione> we could make it ccachable ;)
<jbailey> Not trivially.
<jbailey> You'd have to override each stage so that it used ccache instead of xgcc.
<fabbione> actually.. the only reason why gcc needs bootstrapping is because we don't know if the external compiler can build gcc
<jbailey> Which would sort of defeat the purpose of the multistage bootstrap. =)
<fabbione> right?
<jbailey> Well, you also build the compiler with itself, the new version.
<jbailey> That way you get any new optimisations and bug fixes, but also a compiler built with itself, and a compiler built from that one should be identical.
<jbailey> So you know you're not gradually losing by doing a relatively simply comparison.
<fabbione> well perhaps that can be switched to be build option
<fabbione> if you know that the changes are at packaging level only
<fabbione> you can disable all the bootstrapping torture
<fabbione> and use ccache
<fabbione> if you change code in the compiler
<fabbione> than you do the bootstrapping dance
<jbailey> Maybe.  You'd have to make a few promises about assembler version and stuff, too.
<fabbione> let's see:
<jbailey> But aside from that, yes, just a simple build / no testsuite / etc might be safe.  I'd want to think on that for a month before doing it. =)
<chmj> ok, got a cab for later, now I can stay 
<fabbione> ehheh
* chmj ponders making something to eat 
<jbailey> chmj: Where are you going?
<fabbione> you upload -1 with the full bootstrap build
<chmj> from hbd offices to home, late 
<jbailey> chmj: Right, I keep forgetting that you have offices there.
<fabbione> you realize that file foo should have been in another directory due to errors in debian/whatever.install
<fabbione> so you need to upload -2
<jbailey> fabbione: doko applies patches on a per-arch basis.
<fabbione> but what's the point in enabling the overall if -2 is exactly the same as -1
<jbailey> fabbione: So it could even be a per-upload "Screw: " list of arch's.
<fabbione> oh crap
<fabbione> well i am off to spend a bit of time with my wife
<fabbione> later
<jbailey> Enjoy. =)
<chmj> Enjoy !
<jbailey> Heya Tollef
<Mithrandir> hiya Jeff
<Mithrandir> today's thing which makes me angry: Hardware.  Apart from that: EVMS needs to shrink my 1.8TB volume to fit a measly 256KB (or thereabouts) of metadata at the end.
<fabbione> kernel-team meeting will start in 9 minutes in #ubuntu-meeting
<zul> lol..https://bugzilla.ubuntu.com/show_bug.cgi?id=10499
<zul> gday
<zul> kablooie
<zul> fabbione: you coming to the meeting?
<fabbione> yup :)
<fabbione> i am not gonna miss this one :)
<fabbione> jbailey: i just hooked up benc on irc :)
<fabbione> and bitching him about silo/grub2 ;)
<Mithrandir> fabbione: what did he say?
<fabbione> Mithrandir: didn't answer back yet :)
<fabbione> oh crap 
<fabbione> he had a huge mail loss..
<Mithrandir> ew :(
<jbailey> fabbione: *lol*
<zul> *sigh*
<fabbione> ohhh
<fabbione> of course!
<fabbione> new glibc will stage for a week or two!
<fabbione> *shrug*
<zul> hehe
<zul> hey fabbione i was thinking after debian and ubuntu systems merged how about one big assed meeting between debian and kernel to get to know each other
<fabbione> zul: we should probably do that during the merge :)
<zul> yeah because i hardly know anyone in the debian side
<fabbione> sure
<fabbione> they are all pretty nice.. some of them upstream
<zul> can they be trusted ;)
<fabbione> yes
<zul> fuck fuck fuck..
<zul> fuckity fuck
<jbailey> fabbione: Do you follow lkml?
<fabbione> sometimes
<jbailey> I'm looking at this for initramfs integration and simplified coldplugging: http://lkml.org/lkml/2005/5/12/188
<jbailey> Can you offer an opinion on whether this is likely to wind its way into a mainstream kernel?
<fabbione> zul: mind to tell mdz wth you saw that kernel?
<fabbione> i think it already is....
<fabbione> jbailey: let me check
<fabbione> jbailey: the patch is alredy in Linus tree
* jbailey blinks.
<jbailey> Right.
<fabbione> it will be either in rc6 or final.. whatever will come first :)
<jbailey> I wonder what it will choose the preferred driver when more than one is possible for a device.
<jbailey> greg kh's response seems to be to just not building the conflicting driver.
<fabbione> what case is that?
<jbailey> Like eepro vs. e100, or oss vs. alsa.
<dilinger> http://lkml.org/lkml/2005/6/1/109
<fabbione> jbailey: hmm right
<fabbione> dilinger: NEAT
<jbailey> fabbione: Anyhow, not hard to do an alias map or something like that.
<fabbione> i was thinking that we sould actually use 2 criterias
<fabbione> one would be to have a module priority
<fabbione> and one to use module masks
<fabbione> the first would solve the e100/eepro100 problem
<fabbione> we prefer e100 (for ex) and we assign priority 1
<fabbione> excluding automatically all lower priorities
<fabbione> if e100 is banned, than we look for a lower priority
<fabbione> the module masks are included in the PCIid table already
<fabbione> if we have a perfect match between a module and a device than we load it
<fabbione> in there are 2 perfect matches we use the priority
<fabbione> if there is a perfect match but it's banned than we look for a larger mask
<fabbione> this latter would solve the case for modular IDE
<fabbione> where the perfect match is done by the specific driver
<fabbione> and the larger match by the generic IDE driver
<fabbione> we can use both criterias at the same time
<fabbione> because we might want to override the mask with a priority...
<fabbione> SCARY
<fabbione> I GAVE BIRTH TO A ENDLESS PROBLEM
<jbailey> In this case, I don't know how much of that intformation I'll actually have available to me for the decision.
<jbailey> It looks like modalias might just contain a single name.
<fabbione> jbailey: that needs to be done before the event is sent to userland
<fabbione> basically in kernel hotplug it self
<jbailey> Ah, okay.
<jbailey> Oh, hmm.  Or am I confused?  I had assumed that this would contain a module name to feed to modprobe.  Does it just hand in a device id instead?
* jbailey actually reads the sprintfs
<jbailey> Are you going to promote the current kernel to main or wait until the next one?
<jbailey> fabbione: (re: silo)  Greeat, sounds like fun.  Are you willing to do half of the cleanrooming with me?  I have a u5 here now, I just need to plug it in.  (Not for a couple weeks at least)
<jbailey> That way I don't have to look at the silo code, I can just ask you questions.
<fabbione> jbailey: next one
<fabbione> jbailey: if i can understand what you ask and what to look for.. yes
<jbailey> Lovely.  I'll try and get my machine plugged in, otherwise it'll be when I'm back from Debconf.
<dilinger> wait, benc's online?
<fabbione> not here.. not anymore...
<dilinger> damn
<fabbione> dilinger: mail him :)
<fabbione> he did lost a big bunch of emails not too long ago
<dilinger> are you kidding?  in the past 2 years, he's emailed me back exactly twice
<jbailey> cisco just manages to make their site worse everytime they touch it.
<dilinger> and i've sent him and cc'd him on numerous mails
<fabbione> that's because you need to know what to tell him and how :)
<fabbione> jbailey: they had this look for a while now.. but it sucks
<dilinger> jbailey: i'd offer to help you cleanroom silo, as i've been playing around w/ the code and reading up on ieee1275, but i'd rather take care of higher priority stuff..
<jbailey> fabbione: Yeah, a year and abit, I think.
<fabbione> yeah
<fabbione> it still sucks :)
<fabbione> dilinger: ok.. i will give you a hint on how to grab benc attention
<jbailey> dilinger: The ieee1275 works well enough atm to boot a mac, so I suspect there will just be little quirky things to ask.  
<fabbione> first line of the mail has to start like this:
<fabbione> Hey GoogGuy,
<fabbione> in 99% of the cases you will get an email back
<fabbione> meh
<fabbione> GoodGuy i mean
<fabbione> well it's time to go and crash i can barely type
<jbailey> g'n fabio
<fabbione> night ladies and gentlemen
<jbailey> dilinger: When it comes time, I'll ping you to see if you're still busy ;P
#ubuntu-kernel 2005-06-09
<zul> uh dont you have to be a student?
<fabbione> morning
<lamont> fabbione: tomorrow I'll push -pa1 for hppa, and roll patches
<fabbione> lamont: cool
<fabbione> tomorrow might be a good day to upload the kernel
<chmj> morning 
<zul> morning
<fabbione> hey zul
<zul> hey fabbione 
<chmj> fabbione: should I try to find the right url base for the drivers ? 
<fabbione> chmj: yes please
<chmj> ok 
<chmj> just finished reformating it 
<chmj> how do you feel about tabs ?
<fabbione> tabs are fine
<chmj> ok 
<zul> is it in the wiki?
<fabbione> zul: debian/external-drivers?
<zul> i thought it was on the wiki nm
<Mithrandir> fabbione: weren't you supposed to tell me how to debug acx today? :-)
<zul> heh now i can buy chucksuperporn.xxx
<fabbione> Mithrandir: sorry, but i did completely crashed today
<fabbione> zul: eheheh
<Mithrandir> fabbione: as would my acx if I had booted your kernel. :-P
<fabbione> Mithrandir: gimme 2 minutes to wake up :)
<Mithrandir> fabbione: sure.
<fabbione> Mithrandir: the driver is already compiled with ACX_DEBUG by default
<fabbione> so there is not much that needs to be done there...
<fabbione> let see what kind of info we can find
<Mithrandir> one problem here is that the whole system just freezes.
<fabbione> is there anything in the logs?
<Mithrandir> no
<fabbione> so the thing is.. if it is loaded before X it crashes
<Mithrandir> there's a panic on the screen; I'm going to up the resolution so I can see what it says.
<fabbione> otherwise it works
<Mithrandir> no, then it works for a while then crashes
<fabbione> oh a panic would help
<fabbione> if you can hand copy it would be great
<fabbione> i need to go now.. so take your time
<fabbione> Mithrandir: either stick it in a bug with all the info or send it via email
<Mithrandir> I'll see what I can do
<fabbione> ok
<fabbione> i am off
#ubuntu-kernel 2005-06-10
<zul> scarey http://lkml.org/lkml/2005/6/2/264
<fabbione> morning
<fabbione> zul: the fact that a var is not used on one architecture, does not mean that it is not on the others. kthxbye
<crimsun> he timed out
<fabbione> bah
<fabbione> i know he reads the logs :)
<crimsun> :)
<chmj> OMG 
<chmj> spam, with all our email addresses 
<jbailey> Mithrandir: ping?
<zul> logs what logs? :)
<zul> hey lamont__
* lamont__ makes a note to hurt someone in HR's IT dept
<jbailey> lamont__: Still bitter about the email address?
<lamont__> no.  they tell me to go to a URL to deal with benefits, and "you will find a message in the Your Action Needed section of the home page."
<lamont__> I can't even find the "Your Action Needed"
<lamont__> for extra credit, I may just fire up an rdesktop to a windows box, and see if IE gets it different...
<Mithrandir> jbailey: pong
<jbailey> Now the joy of seeing if I can make initramfs do md
<Mithrandir> woo
<lamont__> morning fabbione 
<fabbione> so today we added ppc64 and we are busted because none of the chroot on davis are updated
<fabbione> suckage
<zul> oops
<fabbione>     Debug detection (SND_DEBUG_DETECT) [N/y/?]  (NEW) y
<zul> yeah i missed that one
<fabbione> zul what about checking the config before asking me to merge? :)
<zul> :P
<zul> i have had a rough week :P
<jbailey> fabbione: What do you need?  I can do some builds here if you need for testing.
<zul> jbailey: how is the lsscsi working out for you?
<zul> fabbione: for the non-supported-linux-kernel-modules i was going to set it up like lrm
<jbailey> zul: I'm waiting until the release of 2.6.12, it looks like it has the magic I acutally need built into it.
<jbailey> I don't want to special case scsi, and then special case ide if I can avoid it.
<zul> cool
<jbailey> (or the next RC should have the magic, too, acc. to Fabio)
<fabbione> zul: just do it as you feel is best, we can review it together once it's done
<zul> ok...ill take the drivers from debian/external-drivers as well
<fabbione> zul: follow the policy we agreed on
<zul> yep
<fabbione> start from external drivers and everything that is not required for install.. go in non-supported
<zul> now i must go gardening
<fabbione> ehhehe
<zul> its too hot outside for gardening fuck it
<fabbione> zul: ehehhe
<jbailey> My weather applet claims that it's 16 out.
<jbailey> force refresh, oh look.  21
<jbailey> Much more accurate.
<zul> jbailey: i think its like 28 in ottawa
<zul> sorry 26
<jbailey> And 4 in Iqaluit
<zul> they must be melting
<jbailey> *lol*
<zul> woho...i got a pre-call screening interview
<fabbione> zul: cool
<fabbione> i think it's time to start the weekend
<fabbione> i am foff
<fabbione> off
<zul> c ya
<jbailey> Is there any way of poking the md driver through /sys or /proc to tell it what the raid components are?
<jbailey> Nope, looks like I need mdadm on the initramfs
<dilinger> mdstat?
<jbailey> mdrun seems to be the trick.
<jbailey> just giving it a try now.
<jbailey> Bah, it's a shell script.
<jbailey> look, *then* act, Jeff.
<zul> hehe
<zul> i do the same
<jbailey> So does infinity, maybe it's a Canadian thing..
* jbailey hides.
<zul> traitor
<jbailey> Why so?
<jbailey> Canadians are good at hiding from enemies.
<jbailey> It's either that or fight them.
<jbailey> There's a *reason* we have more submarines in West Edmonton Mall than we do in our navy...
<jbailey> special, it works well enough to boot the box.
<jbailey> Now to struggle hard not to overengineer the hooks in mkinitramfs.  cdbs2 has spoiled me.
<jbailey> busybox contains an httpd.. evil.
<zul> yay....things are starting to pick up
#ubuntu-kernel 2005-06-11
<zul> well...almost linux-non-supported-modules-2.6.12-1-386_2.6.12-1_i386.deb
<Micksa> hi :)
<Micksa> oh, there's nobody here that's not in #ubuntu-devel anyway
<Micksa> oh, I see. ext2 isn't in the kernel
<Micksa> how quaint >:)
<Micksa> ramfs then I guess
<Micksa> er, or maybe not
<fabbione> ext2 is in the kernel
<fabbione> or as module
<fabbione> it makes no difference
<fabbione> ~
<fabbione> Micksa: what i suggest to do usually is to install linux-source-2.6.X (where X is the version you want)
<Micksa> oh, I am :)
<Micksa> (on here)
<fabbione> and you will find the source in /usr/src
<fabbione> unpack it
<fabbione> apply the patch
<fabbione> and install kernel-package
<Micksa> just "apply the patch"? okay
<fabbione> use make-kpkg to build the kernel
<fabbione> yes you can apply the patch on top of that tree
<Micksa> I was half expecting to have to place the patch into a patch dir
<fabbione> that tree is the ubuntu tree
<Micksa> *after* resolving conflicts etc :)
<fabbione> clearly
<Micksa> I watched it apply a bunch of patches in a compile before
<fabbione> the one you get there contains already all the ubuntu patches
<Micksa> sweet
<fabbione> it's "easier" to start with than with apt-get source linux-source-2.6.x
<fabbione> note the difference in apt-get install/source :)
<infinity> Much.  Especially if you just want to make-kpkg a single kernel.
<fabbione> exactly
<Micksa> oh, so "apt-get source linux-image-xxx" != "apt-get install linux-source-xxx"?
<Micksa> fuck :)
<Micksa> guess which one I already did :)
<Micksa> oh well. 5 mins I'll never get back
<Micksa> Suggested packages:
<Micksa>   libqt3-dev
<Micksa> eh wot?
<fabbione> that's to use make xconfig
<Micksa> kda config front end I guess
<fabbione> yes
<Micksa> kde even
<Micksa> I don't know the compile process anymore
<Micksa> it hardly changed at all between, like, 1.2 and 2.4
<Micksa> then all of a sudden BOOM
<infinity> It's not that changed, really.
<Micksa> aha!
<Micksa> mjg59: after resume I can blindly type commands in the ramdisk install I've created
<fabbione>   LD      arch/ppc64/mm/built-in.o
* fabbione grins
* Micksa pokes mjg59 again
<Micksa> I have network access :)
<Micksa> grr
<Micksa> that patch worked. woo
<Micksa> now I just gotta make it so I can *see* after I resume :)
<Micksa> aha
<zul> gday
<Micksa> morning
* lamont commits the latest hppa patch
#ubuntu-kernel 2005-06-12
<mjg59> Micksa: Rock
<mjg59> Micksa: vbetool is probably what you need
<Micksa> mjg59: the PCI config for the card gets trashed
<Micksa> I believe it's PCI express
<Micksa> vebtool doesn't appear to help
<Micksa> okay, so maybe I'll have to read the PCI spec 8)
<lamont> g'night all
<fabbione> morning
* dilinger waves
<fabbione> hey dilinger 
<fabbione> lamont: i guess you did commit to your local tree, didn't you?
<fabbione> dilinger: btw did you ever tested clvm ?
<fabbione> (since you are one of the lvm2 folks ;))
<dilinger> nope
<dilinger> i haven't played w/ GFS stuff at all
<fabbione> you don't need GFS to play with clvm :)
<fabbione> i guess i am going to play with it for you soon
<dilinger> oh.  well, no, i've only dealt w/ basic lvm
<dilinger> clvm is cluster lvm, no?
<dilinger> since redhat ate sistina, and joe thornber stopped working there, i haven't really kept up.  they're no fun anymore :)
<fabbione> eheh ok
<fabbione> yeah it's cluster lvm
<dilinger> i never really had the opportunity to play w/ it
<fabbione> oky doky :)
<dilinger> sistina freed GFS around the time i quit voxel, i believe
<dilinger> s/sistina/redhat/
<fabbione> yeah
<dilinger> and i don't have the hardware at home
<dilinger> and my current job is big on openafs
<fabbione> you need 3 pc to do that
<fabbione> s/pc/boxes/
<dilinger> i didn't have 3 working pcs :)
<dilinger> i ended up buying a whole bunch of parts, i had a bunch of dead machines
<dilinger> and sparc boxes
<fabbione> well you can mix hardware...
<dilinger> i wouldn't quite trust the sparcs w/ stuff like that
<fabbione> why not?
<dilinger> 'cause i'm happy if i can get the things to boot; clustering seems like an extravagancy
<fabbione> well but testing doesn't mean production :)
<fabbione> btw.. did you finally got your appartment?
<fabbione> so that we can turn one of your sparcs into a buildd?
<dilinger> yep
<fabbione> cool :)
<dilinger> i moved in last weekend
<dilinger> still making it habitable
<fabbione> congratulation :)
<fabbione> yeah i can imagine
<dilinger> thanks :)
<dilinger> the 280's sitting on the floor, i need to get all my machines up and running still
<fabbione> no rush
<dilinger> i'm not sure what i'm going to do about the internet connection
<fabbione> why?
<dilinger> i tried contacting roadrunner, but they haven't gotten back to me
<dilinger> in the meantime, someone in the building has an open AP that i've been using
<fabbione> are you still without net at home?
<fabbione> ahhh
<fabbione> ehehhe
<dilinger> i'll try to get it online sometime this week, though
<fabbione> well without bw it might be an issue
<dilinger> maybe i should see if i can host it at work
<dilinger> although getting it there will be.. interesting
<fabbione> and i should probably move wanna-build to a public host
<fabbione> dilinger: for the size? :)
<dilinger> they're also firewalled like crazy; does anything need to connect to the buildd, or does the buildd do all the connecting out
<dilinger> ?
<dilinger> yea, the size and weight.  i certainly couldn't move it myself
<fabbione> buildd connects to outside
<fabbione> nothing connect to buildd
<dilinger> carrying from my car to my room, when i first got it, nearly killed me
<fabbione> ehe i can imagine
<fabbione> buildd needs ssh access to wanna-build
<fabbione> and clearly access to a public sparc archive
<dilinger> ok
<fabbione> like http://ports.
<dilinger> so it ould be fine to host it at work
<fabbione> i guess there is no way to ssh in, is it?
<dilinger> i'd have to set up a tunnel
<dilinger> which wouldn't be permanent
<fabbione> hmmmm
<dilinger> of course, if you can find me hosting in nyc somewhere, i can put it there instead..
<fabbione> it was more to be able to do admin tasks, like updating chroot, unfucking chroots
<fabbione> yeah but i know shit about hosting in NYC
<fabbione> it's like 4000 Miles from here if not more :)
<dilinger> heh
<fabbione> building iseries kernel is a royal pain in the butt :)
<dilinger> hm, my laundry's probably done..
<fabbione> i need to wake up my wife and listen to her for the next hour...
<fabbione> given that we have been having a fight all night
<fabbione> i would rather do your laundry :)
<fabbione> ttyl
<lamont> fabbione: no, I simply failed to actually do the commit. :-(
<mjg59> fabbione: Would it be possible to set CONFIG_ACPI_DEBUG to y for a while?
<fabbione> lamont: ah ok :)
<fabbione> mjg59: there will be 2 -dbg images with the next upload
<fabbione> 686-dbg and 386-dbg with all the DEBUG=y
<fabbione> i guess that includes ACPI too
<mjg59> fabbione: Oh, rock
<mjg59> fabbione: Did you get my mail?
<fabbione> mjg59: for the libata suspend/resume patch is not really go.. we will drah 2.6.12 into main and as default kernel within the next 2 weeks :/
<mjg59> fabbione: This code needs testing. It's not going to get tested unless we put it somewhere
<mjg59> And it's vital for ACPI on new laptops
<fabbione> mjg59: i need to be at least sure it's not going to eat people disks
<mjg59> It /looks/ fine
<Mithrandir> make it twiddlable by a boot parameter?
<mjg59> The only time this code patch is followed is during suspend or resume
<mjg59> Uh, path
<mjg59> It won't affect any other use
<fabbione> ah it's from Jeff
<fabbione> i will ask him
<fabbione> hmm he is not online
<Mithrandir> fabbione: ok, I have an oops now.  What do you want me to do with it?
<fabbione> Mithrandir: stick it somewhere i can look at it?
<fabbione> or the best option would be to print it in 4 layers toilet paper for firther usage :)
<Mithrandir> fabbione: I mildly hate you then, since it means I have to copy half a screenfull off by hand.  Or do you do digicam shots? :)
<fabbione> lamont: can you commit asap? i might upload the kernel either today or tomorrow my morning (your late evening)
<mjg59> fabbione: http://lkml.org/lkml/2005/5/23/116 is the disclaimer
<fabbione> Mithrandir: it needs to be the full OOPS
<mjg59> But various people are using it without complaint so far
<Mithrandir> fabbione: sure, but is a picture of it ok or do you really want the text?
<fabbione> digikam is ok if fully readable
<Mithrandir> ok, fine.
<fabbione> fuck ppc and its random process killer
<fabbione> it should have finished the ppc64 build while i was asleep
<fabbione> mjg59: Patch 2/2 for review by the linux-scsi crowd.
<fabbione> where is 1/2 ?
<fabbione> nver mind
<fabbione> 509700  build-power4-smp
<fabbione> 561520  build-powerpc64-smp
<fabbione> YEAH
<fabbione> elmo and the mirrors will love me :)
<mjg59> fabbione: 1/2 is unrelated
<fabbione> yup
<Mithrandir> fabbione: http://err.no/tmp/DSC00879.JPG 
<fabbione> Mithrandir: ok...
<Mithrandir> it's probably the biggest backtrace you've seen, at 2.7MB. :P
<fabbione> ahhaha
<fabbione> Mithrandir: is that card usb or pci?
<Mithrandir> pci
<fabbione> ok
<fabbione> * acx_ether_to_txdesc
<fabbione> *
<fabbione> * Uses the contents of the ether frame to build the elements of 
<fabbione> * the 802.11 frame.
<fabbione> *
<fabbione> * We don't actually set up the frame header here.  That's the 
<fabbione> * MAC's job.  We're only handling conversion of DIXII or 802.3+LLC 
<fabbione> * frames to something that works with 802.11.
<fabbione> Mithrandir: given that the driver is compiled with DEBUG
<fabbione> can you show me the logs from kern.log or syslog?
<fabbione> they should be there somewhere
<Mithrandir> fabbione: the box is hung when that oops happens.
<fabbione> Mithrandir: yes, but the logs should be written before that :)
<Mithrandir> they aren't.  Or wasn't last time.
<fabbione> WTF!!!!1
<fabbione> I HATE EXTERNAL DRIVERS
<Mithrandir> or, which part of the logs?
<fabbione> THEY SHOULD DIE OF SLOW PAINFUL DEATH
<fabbione>                 acxlog(L_DEBUG, "tx: 802.3 len: %d\n", skb->len);
<fabbione> there should be entries like that around
<fabbione>                 acxlog(L_DEBUG, "tx: DIXII len: %d\n", skb->len);
<Mithrandir> no tx: from today.
<fabbione> do you actually get any data out of the device before the crash?
<fabbione> data like IP connections
<Mithrandir> sure, I can ping my router, for instance.
<Mithrandir> ssh-ing made it die.
<fabbione> Mithrandir: was that piece of code working in 2.6.10?
<fabbione> (can't remember if you told me)
<Mithrandir> fabbione: 2.6.10 works just fine on the box, yes.
<fabbione> ok
<Mithrandir> the driver is in the kernel and I haven't reviewed any changes.
<fabbione> yeah the acx100 is anyway an external one
<fabbione> UHAAAA
<fabbione> the code has been changed hell of a lot
<fabbione> -               e_snap = (wlan_snap_t*)((UINT8*)e_llc + sizeof(wlan_llc_t));
<fabbione> +               e_snap = (wlan_snap_t*)((u8*)e_llc + sizeof(wlan_llc_t));
<fabbione> stuff like this might make it amd64 unfriendly :)
<fabbione> Mithrandir: do you have any option to test it on i386?
<Mithrandir> I can install i386 on the box and try, sure.
<Mithrandir> it'll take me an hour or so, though.
<Mithrandir> but, food now
<fabbione> sure no rush
<fabbione> but if it works on i386.. well there is only one solution
<fabbione> bomb upstream :)
<zul> blah
<fabbione> hey zul
<fabbione> dpkg-deb: building package `linux-image-2.6.12-1-powerpc64-smp' in `../linux-image-2.6.12-1-powerpc64-smp_2.6.11.93-1.2_powerpc.deb'.
<fabbione> dpkg-deb: building package `linux-image-2.6.12-1-iseries-smp' in `../linux-image-2.6.12-1-iseries-smp_2.6.11.93-1.2_powerpc.deb'.
<fabbione> there we go
<fabbione>  /usr/share/kernel-wedge/commands/copy-modules: line 13: 14622 Segmentation fault      mv $tmpdir/work.new $tmpdir/work
<fabbione> YEAHH!!!!!!
<fabbione> GO KERNEL-WEDGE IT'S YOUR BDAY!
<fabbione> i am afraid kernel wedge needs some ppc64 love too
<Micksa> man
<Micksa> I wanna hack kernels all day
<Micksa> I can do that
<Micksa> you don't believe me huh :)
<fabbione> Micksa: there are tons of bugs that need love :)
<fabbione> welcome to provide patches to fix them
<Micksa> there are always bugs
<Micksa> it's mostly a time issue
<Micksa> well, uh, also
<Micksa> do you work for canonical?
<fabbione> yes
<zul> fabbione: i wont be around much tomorrow since i have an interview
<Micksa> crap
<Micksa> lemme try that again
<Micksa> fabbione: do you work for canonical?
<fabbione> Micksa: yes
<fabbione> zul: no problem.. i am fighting with ppc64
<zul> that must be fun
<Micksa> see, you're getting paid to do this stuff :)
<Micksa> I could SO do that
<Micksa> but man I'm crap at making good use of spare time
<Micksa> I mean, shit, I spent all day yesterday trying to get my laptop working 8)
<zul> oh and linux-non-supported-modules is coming along nicely
<fabbione> zul: it was fun until i hitted the random PPC segfaults
<zul> he
<zul> hehe
<fabbione> zul: ah nice
<fabbione> i guess i am going to try to hack on 64 images only
<fabbione> building 8 images takes too long
<zul> it does...usually yes :)
<fabbione> Micksa: well up to you to get known.. a good point to start is MOTU :)
<zul> *sigh* i have to wear a tie tomorrow
<fabbione> amen
<fabbione> i hate ties
<Micksa> MOTU?
<fabbione> Micksa: #ubuntu-motu
<fabbione> Master Of The Universe
<fabbione> it's a good point to start
<Micksa> mmmkay
* Micksa commences lurking
<zul> do we have a list of which external-drivers run on which arch
<zul> yet
<fabbione> zul: no, you will need to grab the images from archive and ports
<fabbione> and check them there
<zul> thats what i thought
<fabbione> i have the feeling that ppc buildd will never make a kernel build
<fabbione> ppc has this nice issue of doing random segfaults
<fabbione> it did it 4 times in one build
<zul> meh...drop ppc :)
<fabbione> hehehe
<fabbione> with Apple switching to intel, it might be an option :)
<Mithrandir> fabbione: I'll believe that when I see it.
<fabbione> Mithrandir: well it was on /. yesterday
<Mithrandir> fabbione: "IT WAS ON SLASHDOT. OH GOD IT MUST BE TEH TRUE!"
<Mithrandir> :-)
<fabbione> ahhaha
<fabbione> AH SHIT..ok i am too tired
<fabbione> time to stop for today
<fabbione> the OCFS2 update is FTBFS
<fabbione> and of course i can't build ppc64 anymore
<zul> what slashdot always reports the truth?
<fabbione> that makes all my d-i changes pointless
<fabbione> fs/configfs/inode.c:51: error: unknown field `memory_backed' specified in initializer
<fabbione> BAH
* Mithrandir installs i386 breezy kernels
<fabbione> bah fixed
<Mithrandir> fabbione: well, if I switch to i386, it doesn't associate at all, even. :P
<fabbione> Mithrandir: fun :) bug upstream :)
<fabbione> or check if there is a newer version
<Mithrandir> fabbione: it's the stock kernel driver.
<Mithrandir> 2.6.12 doesn't have lrm
<Mithrandir> :P
<zul> um...is the hotplug stuff the same from the old version and the new version of acx100
* Mithrandir tries to parse zul's sentence a few times an fails.
<Mithrandir> s/an/and/
<zul> bah...the acx100 driver we are using is from a different source has the *.bin files in the hotplug directory the same as the 2.6.10 version?
<zul> http://www.tsn.ca/columnists/bob_mckenzie.asp
<zul> oops....wrong one
<zul> http://rhlx01.fht-esslingen.de/~andi/acx100
<Mithrandir> I had to symlink in the firmware from 2.6.10 since the kernel didn't find it otherwise.
<zul> wierd
<fabbione> hmmmmmmmmmmm
<fabbione> HMMMMMMM
<fabbione> i think the acx100 firmwares are in l-r-m
<fabbione> they probably need to be updated
<zul> yes they are
<fabbione> the acx100 hotplug code from 2.6.10 to 2.6.12 is different
<zul> bbl need to eat
<fabbione> bah ocfs2 update is fucked
* fabbione reverts
<Mithrandir> hm, ok.  
<Mithrandir> except there's no newer firmware upstream?
<Mithrandir> hm, I'll see if compiling the newest and shiniest external driver works.
<fabbione> is there a new version?
<fabbione> acx100             | 0.2.0pre8+fixes52          | ok     | 18/04/2005   | http://acx100.sourceforge.net/ http://rhlx01.fht-esslingen.de/~andi/acx100/
<fabbione> this is the one in the kernel right now
<fabbione> anyway i need to go and cook dinner
<fabbione> ppc64 is pissing me off too much
<Mithrandir> yes, there's a newer upstream
<Mithrandir> fixes56
<fabbione> Mithrandir: ok.. test that one and let us know :)
<fabbione> we will update the driver anyway, but if it fixes the problem i will find the time to include it in the next release
<fabbione> i am off :)
<lamont> * committed kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.93--patch-25
<lamont> that was either last night or first thing this morning...
<lamont> almost 8 hours ago
#ubuntu-kernel 2006-06-05
<WebMaven> I've filed a serious bug affecting users of Averatec 3200-series laptops. Would anyone here like to take a look?
<BenC> WebMaven: it's already being looked at
<WebMaven> BenC: OK. I just figured you said you were off the rest of the weekend.
<BenC> most everyone is
<infinity> What weekend?  It's Monday.
<BenC> aussies and their weird days
<infinity> Hey, I live in the future, man.  THE FUTURE.
<infinity> We have flying cars here.
<BenC> are they powered by kangaroos? :)
<WebMaven> You could make a good living export jetpacks.
<WebMaven> you know, like ' TO THE PAST.
<infinity> WebMaven: You can't export to the past.  That's why Australia has a negative GNP.
<WebMaven> Ah, I always wondered about that.
<WebMaven> you can import from the future though...
<infinity> If you could, you'd have a flying car too.  Do you?
* infinity stares.
<infinity> I didn't think so.
<WebMaven> No, can't afford the customs.
<infinity> BenC: How soon after I announce that edgy can build do you want to upload?
<infinity> BenC: Are you booting on all 6 arches now?
<BenC> yep, it's building everywhere
<BenC> and I'm using it on ia64, x86, x86_64 and powerpc without problems
<infinity> Note that I said "booting". :)
<BenC> hppa is a binutils/gcc bug
<infinity> Ahh, right.  Haven't found a clever workaround for that yet?
<BenC> sparc64 is good for 99% of the machines out there, just not mine
<infinity> Typical.
<BenC> nah, it's pretty horrible
<infinity> I need to get a sparc box in my house somewhere.
<WebMaven> But do this: start Python
<WebMaven> and in python do this: >>> from __future__ import division
<WebMaven> viola! importing from the future!
<WebMaven> unfortunately, from __future__ import jetpack fails
<WebMaven> BenC: Can I consider my bug confirmed at thisd point?
<BenC> WebMaven: as I said before, you can consider it so, it's just a matter of state at this point before I assign it
<WebMaven> OK.
<WebMaven> Sorry for being so anxious. I really want to get my laptop working.
<WebMaven> Also, regarding the dupe with #34958... which way should I mark the dupe?
<infinity> If both have crap info, always make the new one a dupe of the old one.
<infinity> If one bug in the set has lots of really good debugging info, I tend to make that they "master" bug, just cause.
<WebMaven> I *think* mine has slightly better info, but I'm biased.
<WebMaven> they both have good info.
<infinity> Either way, they link to each other in the end, so it doesn't really matter.
<infinity> Make sure the "master" bug has a good bug title, for people searching later, that's all.
<infinity> (Cause the other one becomes effectively invisible to bug lists and simple searches)
<BenC> sat signal strength going...storm is not very nice to my broadband...I may be going out here soon
<infinity> BenC: Pull fiber to the farm.
<WebMaven> OK.
<infinity> BenC: Or MOVE SOMEWHERE WITH FEWER COWS.
<infinity> *cough*
<WebMaven> Yes. Because we all know the effect cows have on internet connectivity.
<infinity> They do seem to relate.
<infinity> Not many cows in the downtown core of a city, where you're alsmo more likely to find fiber criss-crossed every 18 inches in the ground.
<crimsun> out of us all, BenC probably has the highest possibility of having ponies, though
<infinity> crimsun: This is a good thing?
<crimsun> ponies can only be good!
* crimsun ahems
<WebMaven> I want electricsheep. And a pony.
<WebMaven> Ok, all three old bugs maked as dupes of mine.
* dilinger wonders how well sarge->dapper upgrades work
<infinity> dilinger: Depends on how much stuff you have installed.
<infinity> dilinger: From a base debootstrap, "Really Well"... From a full desktop system, I make no guarantees. :)
<dilinger> infinity: it's a server
<dilinger> close enough to debootstrap, i think
<infinity> Yeah, that should go smashingly well, then.
<infinity> Make sure to add a pin-priority over 1000 to force downgrades if we have any (though we SHOULD be newer for everything)
<infinity> Package: *
<infinity> Pin: release a=dapper
<infinity> Pin-Priority: 1001
<infinity> In /etc/apt/preferences
<infinity> And then go hard.
<dilinger> infinity: also, i'm told IP-over-bovine, while a bit slower than carrier pigeon, is actually pretty robust.  benc just needs to parallelize his cows.
<infinity> Painful round-trip if you lose a frame, though.
<dilinger> but you get a hamburger out of the dropped frame
<WebMaven> I don't like Bullian logic...
<dilinger> interesting
<dilinger> 8 packages downgraded w/ pinning
<infinity> Care to tell me which ones, so I make sure we get them in sync for edgy? :)
<dilinger> they're actually all just same versions
<dilinger> The following packages will be DOWNGRADED: ed host libatm1 libgdbm3 libgdbmg1 libident libpcap0.7 reiserfsprogs
<dilinger> the sarge versions match the dapper ones
<infinity> Ahh.  But pinning is still The Right Thing in that case, so you get our builds of the binaries instead of the Debian builds.
<dilinger> indeed
<BenC> there's 12 cows, maybe I can get them to mozy over to the cable drop and pull a few thousand feet of coax
<zul> BenC: ping
<BenC> zul: pong
<zul> BenC: i probaly ask this question before but we can blacklist noapic motherboards cant we?
<zul> my memory is a sieve
<BenC> yeah, should be able to
<zul> in  arch/i386/kernel/acpi/boot.c it doesnt mention anything about disable_ioapic_setup though
<zul> meh...ill play with it later...night night
<roh> hi there
<roh> i've notified a very strange problem here on my thinkpad which is not in the bugtracker, but it seems i cannot file bugs there
<mjg59> Which bugtracker?
<roh> the one accessible from the launchpad
<mjg59> You ought to be able to file bugs there...
<roh> it says the kernel is not in malone
<mjg59> How are you trying to file it?
<mjg59> Try https://launchpad.net/distros/ubuntu/+filebug and then choose linux-source-2.6.15 as the source package
<roh> hm.
<roh> i have a patch. its 2 lines
<roh> -# CONFIG_CPU_FREQ_DEBUG is not set
<roh> +CONFIG_CPU_FREQ_DEBUG=y
<mjg59> Hm. What's the reasoning?
<roh> debugging is off by default in the runtime. so it only changes some macros to be compiled in.
<mjg59> Yes
<roh> and that changes runtime behaviour.. 
<mjg59> That doesn't really answer my question :)
<roh> without speedstep-smi does not work at all. the module does not find the hardware to be working
<mjg59> The speedstep-smi issue is already known
<roh> at least on my thinkpad x20
<mjg59> I believe it's being fixed properly (rather than depending on the debug stuff)
<roh> that would be nice... but eventually not trivial without a lot of testsystems at hand
<roh> i looked into the code and couldn't find anything that looked like a thinko and not like 'timing'.. i didn't try adding some delays though
<roh> mjg59 do you have a link for me where the speedstep-smi issue is already listed as bug?
<zul> heylo
<zul> BenC: did you grab crimsun's changes on the mailing list
<zul> hey mdz 
<mdz> morning
<ajmitch> morning mdz 
<BenC> lamont: ping
<zul> do do do
<ajmitch> don't?
<zul> BenC: ping...so whats the verdict?
<BenC> zul: almost done
<zul> heh...is it that bad?
<BenC> nah, just being swamped at the moment
<BenC> doing 15 different things at once
<lamont> BenC: ack
<zul> whee...i convinced my boss to switch to ubuntu
<BenC> lamont: Can you moderate some stuff though kernel-team please?
<BenC> I think desrt has some patches on hold
<lamont> sure
<BenC> thanks
* lamont considers making BenC a moderator...
<BenC> if you email me the password pgp encrypted, I can do some moderation too
<lamont> moderated.  and desrt added to the accepted list
<zul> later
#ubuntu-kernel 2006-06-06
<jcole> debconf-get-selections --installer
<jcole> debconf: DbDriver "di_questions": could not open /var/log/debian-installer/cdebconf/questions.dat
<jcole> is the debconf installer questions now nuked?
<Keybuk> shouldn't be
<Keybuk> are you root?
<makx> Keybuk: for the record the same question was asked on freenode on #debian-boot
<zul> hey
<chuck> heh..some of the edgykernel ideas is funny
<crimsun> zul: on the spec page?
<zul> the communityedgyideas/kernel page
<crimsun> ah, ok. thanks.
<zul> reiserfs4 
<crimsun> swsusp looks interesting
<infinity> Uhm, "squashfs support" as bullet point 1... Awesome.
<infinity> Someone check that off, since without it, our livecds wouldn't be working.
<ajmitch> sad, I haven't seen autopackage mentioned yet
<infinity> I hope that was irony.
<crimsun> I think point 6 (NTFS fs mounted by default) is already done...
<crimsun> s/fs//
<ajmitch> the autop* question seems to come up & have to be beaten down every few months
<TheMuso> c
<WebMaven> BenC: are you around?
<WebMaven> Yoo hoo...
<WebMaven> Ben, the new kernel I installed does not change any of the broken behavior.
<kimo> Guys, I am facing problems with my sky2 driver and with my laptop not powering off. Both are filed bugs, and confirmed. I just wanna ask about, when to expect the new kernel update ?? (if not soon, is there some sort of dev build I can use ?)
<zul> heylo
<ajmitch> hi
<zul> BenC: ping
<zul> mmm....dapper running on 3 cpu xeon
<BenC> zul: pong
<zul> BenC: morning...is everyting ok with the 2.6.12 diff?
<BenC> yeah, looks good
<zul> sweet...2 for 2 :)
<zul> so ill send off the changelog to pitti
<jag_fsf> i'm sorry for asking this on the devel channel, but i think it's probably a little to specific for the support channel... running ubuntu's 2.6.10 kernel, one of my machines during kernel boot analyzes the raid1 arrays on disk and determines that one of them has to be reconstructed... then it says: "Stopping tasks: ====\n stopping tasks failed (1 tasks remaining)" which appears to be an error related to software suspend -- why would the kernel be invokin
<WebMaven> BenC: ping
<alex_joni> infinity: hello
<alex_joni> infinity: need a bit of help.. you gave me directions for a custom post-install to write, that copies the vesa16fb? to initrd, but 'make-kpkg clean' ate it .. :( care to tell me again how it should work?
<infinity> http://cerberus.0c3.net/~adconrad/post-install
<infinity> The part you want is near the end.
<alex_joni> THANK YOU :-)
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: hey, in dapper is there a way to disable use of ACPI in libata?
<mjg59> Yup
<mjg59> libata=noacpi, or something
<mjg59> Ah, noacpi=1
<mjg59> libata.noacpi=1, rather
<BenC> ok, thanks
<mjg59> echo stuff into /sys/module/libata/parameters/noacpi at runtime
<BenC> https://launchpad.net/bugs/48556
<BenC> for reference
<zul> BenC: the server kernel works well
<WebMaven> BenC: Hi.
<infinity> zul: Good, cause it's a bit late to change it. :)
<zul> really i didnt know? :)
<zul> crimsun: welcome to the club
<crimsun> zul: danke
<jcole> anyone here know how to create a bootable sparc iso?
<jcole> mkisofs -r -J -o $(TEMP_MINIISO) -G /boot/isofs.b -B ... $(TEMP_CD_TREE)
<jcole> i get a mkisofs: No such file or directory. Cannot open '/boot/isofs.b'.
<cvp> Is it true that all kernels in Dapper have hyperthreading junk enabled?
<infinity> (base)adconrad@cthulhu:~$ grep X86_HT /boot/config-2.6.15-23-686
<infinity> CONFIG_X86_HT=y
<infinity> CONFIG_X86_HT_DISABLE=y
<infinity> Looks like it's compiled in but disabled by default to me.
<infinity> (boot with "ht=on" to turn it on, I think.. or "ht=enable"... Or something... I never remember)
<cvp> Alright, I've tried tacking on "ht=on" after the "ro quiet splash", and I saw absolutly no boost in performance...
<alex_joni> infinity: that's odd.. my /boot/config-2.6.15-23-386 has no X86_HT in it
<infinity> What were you expecting?
<infinity> alex_joni: makes perfect sense, since th -386 kernel is the "uber safe, failsafe default"
<alex_joni> oh, yours is 686 .. sorry :)
<cvp> Well, I was expecting a boost in performance, really.
<infinity> cvp: What performance change were you expecting?  HT doesn't magically grow you a second CPU, just makes some context switching more efficient in some cases.
<alex_joni> shouldn't it show up as a second virtual processor under cat /proc/cpuinfo ?
<infinity> alex_joni: Yes, it should.
<alex_joni> cvp: just to check that it actually was turned on
<cvp> In particular, I was told that I'd see an improvement in the fps output in glxgears...
<alex_joni> cvp: that's crap probably
<infinity> cvp: Okay, now you're just trolling, right?
<cvp> By the way, my /boot/config-2.6.15-23-686 has HT=y and HT_DISABLE=y
<infinity> cvp: A) glxgears isn't a benchmark, B) glxgears isn't multithreaded, C) WTF?
<cvp> What? No, I'm a little noobish...
<cvp> Okay...
<cvp> Um... that other thing you were mentioning, the checking to see the virtual processor and junk?
<cvp> How do I do that?
<alex_joni> cat /proc/cpuinfo
<alex_joni> infinity: it seems the kernel I built (with your help) still didn't quite work ok on another machine. but I just built a new one, and I hope it'll work OK.. if not I might get back to bug you some more
<cvp> Alrighty, and that outputs information for processors 0 and 1... does that mean I have hyperjunk enabled?
<alex_joni> "quite work" means that usplash stays dark
<infinity> cvp: If you only have one CPU, and it's not dual-core, then HT is enabled.
<alex_joni> cvp: unless you do have a second CPU, yes
<cvp> Okay, cool. Thanks for the help, and sorry for the inane questions!
<infinity> (If you have two dual-core CPUs with HT enabled, you'd see 8 CPUs in cpuinfo, for instance)
<alex_joni> guess 8 CPUs scared him away
<alex_joni> infinity: could you explain why only vesafb is needed in initrd? isn't it possible that some user might need some other fb?
#ubuntu-kernel 2006-06-07
<infinity> vesafb is just the one we copy there by default.  Users could put another one there if they really want it.
<infinity> We don't actually use vesafb by default either, we use vga16fb.
<alex_joni> ok, so I should probably put vga16fb in there too?
<infinity> Nah, initramfs copies it in properly even if it's not in the initrd directory.
<infinity> The hack we discussed is only required for vesafb, primarily because I didn't notice that slightly buggy behaviour before release.
<alex_joni> to better explain what I'm trying to do. we're working on a linux-based CNC controller, and we chose Ubuntu as the primary platform. because it needs RT stuff, we need to provide kernel packages aswell. but we would like to have them as close as possible to the Ubuntu ones
<alex_joni> ok, I'll ship the new kernel to some beta testers, and if they still have trouble with usplash I might get back to you if that's ok..
<zul> heylo
<zul> BenC: i emailed pitti the changelog
<zul> BenC: what do you think of this for dapper-updates http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5a9191ff683ce4ebfd2c6a15e2989f5b1f420321
<zul> er..for 386 # CONFIG_USB_SUSPEND is not set
<BenC> zul: maybe
<BenC> zul: been in the main kernel since dec., so yeah, email me the URL so I can cherry pick it
<BenC> zul: or cherry-pick it into your tree that I can pull from
<zul> done.
<zul> hmmm...i wonder when hoary-security and breezy-security will be open again
<bluefoxicy> http://rafb.net/paste/results/mVnwz695.html  How's that for clean-up :)
* bluefoxicy wonders if a 2.6.17 or later kernel will be packaged for Edgy?
<zul> uh...the answer was on the kernet-team mailing list
<bluefoxicy> zul:  I do not have that list.
<zul> well check the archives then
<bluefoxicy> ugh now I have to grep archives.  be back in 20 minutes.
<bluefoxicy> ubuntu-kernel or what kernel-team
<bluefoxicy> cool ok so it should be.
<bluefoxicy> hopefully I can get the above patch merged.
<bluefoxicy> (if it doesn't have retarded breakage)
<bluefoxicy> I rewrote the address space randomization code (with help) to be more cross-platform in an attempt to get it working on alpha, arm, ppc, ppc64, x86, x86-64, sparc, and sparc64
<bluefoxicy> the code delta is rather small and light, minimally intrusive, and builds on current infrastructure; I should be able to get it working on like every architecture that PaX randomizes on (since it's an adaptation of the PaX code to slip into existing infra)
<bluefoxicy> which is like 13 archs.
<bluefoxicy> Problem is due to the mmap_base being changed to TASK_SIZE without randomization at random times, there is a large lack of stability :)
<bluefoxicy> I don't know WHY
<bluefoxicy> and haven't figured out how current infra copes
<bluefoxicy> it may be because I touch certain places in the code where in the same code block the mmap_base is used, changed, and used more
<bluefoxicy> or something silly.
<zul> heylo
<ajmitch> hi
<zul> hey ajmitch 
<sivang> hi all
<sivang> what is the source package for an arch'es bin kernel package?
<sivang> I want to check up the hook that dispatches a notiication to restart the system after a kernel is installed
<sivang> anybody any idea?
<zul> eh?
<sivang> hi zul 
<sivang> whenever I Installa new kernel in dapper,
<sivang> I get thje notification bubble that a system restart ir required
<sivang> where lies the code to dispatch the notification ?
<sivang> and also, how do I track which source package was used to produce my current running kernel?
<sivang> (sorry for the too many questions)
<zul> sivang: the notification is done in the debian/rules in linux-source-2.6.15
<sivang> ah, thanks
<sivang> that answers nmy ther quesiton as well ;)
<alex_joni> infinity: around?
<alex_joni> infinity: could you take a peek at http://pastebin.com/765049 (it boots ok, but no splash visible), the kernel is this one: http://dsplabs.cs.upt.ro/emc2/dists/dapper/emc2/binary-i386/linux-headers-2.6.15-magma_aj3_i386.deb
<zul> ick....https://wiki.ubuntu.com/HideFilesystemStructure soneone wants use to use the gobohide patch..
<bluefoxicy> o_O
<mvo> hello BenC, do you have a opinion about the dazuko (http://www.dazuko.org/) kernel module? we got a request if we can make it available in our kernel by default
<zul> for edgy?
<crimsun> yeah
<sivang> where di dthe request come from? :)
<crimsun> sivang: meaning who submitted it, or where is the request? [https://wiki.ubuntu.com/CommunityEdgyIdeas/Kernel] 
<sivang> ah, thanks
<zul> mvo: i dont have a problem with it but thats just my opinnon
<sivang> crimsun: how does KalamV utilize this kernel module?
<crimsun> sivang: I'm not familiar with either, actually. It looks like ArthurPenn added it.
<sivang> ah, I see.
<bluefoxicy> dazuko is interesting, it provides access control from user space
<bluefoxicy> this allows you to write SELinux in user space I guess
<bluefoxicy> but more interestingly, you can do things like virus scan files when someone tries to open them, and control access based on results.
<sivang> bluefoxicy: wow, this is cenrainly cool
<BenC> mvo: Does anything (like gnome) use dazuko yet?
<fabbione> hey ben
<fabbione> BenC: if you want to pull from ubuntu-dapper from me, i did the HUGETLB page changes on davem input, but they change the ABI
<fabbione> i am not sure you want to bump it or we should hide it since sparc is not released
<fabbione> imho it would be better to bump it
<fabbione> but i leave it up to you
<fabbione> tg3 is almost fixed
<zul> BenC: i could do the bump so i could learn howto
<zul> or not
<fabbione> zul: there is a debian/rules target for it :)
<fabbione> it's not that difficult ;)
<zul> true but dont you have to change the control files and the like?
<fabbione> nope
<fabbione> the target should do that for you
<fabbione> read the code luke
<zul> meh..
<BenC> fabbione: do we really need a dump for dapper-updates?
<BenC> s/dump/bum/
<BenC> damnit...BUMP
<fabbione> well it would be dapper-security
<zul> heh..dyslexia is setting in
<BenC> well, yeah, but we are doing a bump?
<fabbione> and it's only sparc.. on one side it's not released.. on the other we know that tons of people are running it
<fabbione> i think we can't avoid abi bumps forever
<fabbione> so we might as well do it properly
<crimsun> yeah, better to be safe than sorry
<BenC> well, if we have to have a bump, I have a change that needs to be made too :)
<BenC> HZ=250 instead of HZ=1000
<mvo> BenC: no, we got a request from a 3rd party vendor
<BenC> it's killing a lot of laptops
<fabbione> BenC: i think we need to change pov for dapper...
<fabbione> with a 5 years support we will change abi a lot
<fabbione> no matter what
<BenC> yeah, we may even move to a newer kernel in dapper over time
<fabbione> exactly
<fabbione> so i think we should remove the dust from the procedure and do it
<BenC> I wouldn't mind moving to edgy's kernel in dapper after edgy releases and is proven stable
<zul> BenC: i think pitti wants to talk as well as well
<fabbione> well that's not an easy step.. rememebr we have hw certification
<BenC> zul: repetition...sign of alzheimers :)
<zul> hehe
<BenC> mvo: File a wishlist bug for dazuko...I can do it, but I need the reminder :)
<mvo> BenC: cool, thanks :)
<zul> ooh...can we have reiserfs4 in edgy ;0
<fabbione> mvo: did they ask it for edgy or dapper?
<BenC> fabbione: is davem's tg3 fix in your tree or his?
<fabbione> BenC: it's none, the fix is not complete yet
<BenC> ok
<fabbione> BenC: there are more bugs
<BenC> no upload till we get that anyway
<fabbione> that one fixes one of them
<mvo> fabbione: they asked for dapper, but we can't do it (obviously), but it would be nice to make the maintainance easier
<fabbione> well you can still upload for -security
<fabbione> don't hold up everything on sparc
<fabbione> mvo: right...
<BenC> fabbione: if it's a matter of 1-2 days, I can hold off
<BenC> mvo: if it's self-contained, I can do it for dapper...
<fabbione> BenC: no idea.. there is also the 4 core T1 issue that's not being investigated yet
<zul> BenC: i should have a couple of patches for you for dapper soon..
<fabbione> zul: don't break anything please
<fabbione> ;)
<zul> fabbione: when was the last time i broke something :)
<zul> dont anwser that..
<fabbione> *no comment*
<zul> :P
<zul> whoops...it looks like i got some work to do tonight
* BenC unleashes 2.6.17 on edgy
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-1.1 uploaded, please use responsibly
<zul> uh so edgy is open now?
<Keybuk> nope
<Keybuk> however there's a queue at the door
<Keybuk> and I'm dressed up as a bouncer deciding who can come in or not
<zul> ah..
<Keybuk> a bit like Steve Rubell ... "not in that shirt"
<zul> with your velvet rope no doubt
<BenC> go figured, I had to bribe him to get in
<WebMaven> BenC: Did you get my feedback on the 2.6.17 kernel?
<zul> BenC: the asm_volitile needs to be changed to alternative_input :(
<BenC> WebMaven: yeah
<BenC> zul: where?
<zul> in the arch/i386/kernel/cpu/amd.c file
<zul> uh...i mean the include/asm-i386/i387.h it was changed 2005-07-22
<BenC> Ok, so you're working on a patch for x87 bug?
<zul> yeah..i was looking through it..
<zul> i should have a fix for it tonight
<BenC> excellent
<zul> build it tomorrow during the day and all that fun stuff
<BenC> are you also working on the bugs you assigned to yourself?
<BenC> just want to make sure I can take them out of my list
<zul> yeah all the bugs im working from now on are assigned to me
<WebMaven> BenC: So when would you like me to test a fix for my bug on this laptop?
<BenC> WebMaven: when I get a fix...
<WebMaven> OK.
<zul> hey
<crimsun> heya zul
<zul> hey crimsun how is it going?
<crimsun> zul: not too bad, having some coffee, yourself?
<zul> good just doing fixes
<zul> and watching simpsons
<crimsun> nice :)
#ubuntu-kernel 2006-06-08
<zul> BenC: ping
<BenC> zul: pong
<WebMaven> BenC: Is someone assigned to produce the fix for my laptop?
<BenC> WebMaven: yeah, me
<WebMaven> BenC: Ah, OK.
<BenC> WebMaven: first part is actually figuring out what to fix
<WebMaven> Is there any further info I can get you to help that along?
<WebMaven> I obviously have a workaround for now, but I'd rather have an actual fix.
<zul> BenC: the fxsave_clelar function doesnt exist in 2.6.10 looks like i might have to backport it
<zul> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=cba8a3b0cded5a77191d9528710b04c85bc13c5b;hp=876eb9a2fe7868a7c7ce01ef694403b3150f4601;hb=18bd057b1408cd110ed23281533430cfc2d52091;f=include/asm-x86_64/i387.h
<zul> and i gave you the wrong link
<zul> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7180d4fb83085fef9d24b353f5bd79cf6fd98447
<bluefoxicy> I 
<bluefoxicy> have no fucking clue if this is going to work.
<bluefoxicy> oh that's right I have to throw stuff in elf.h all over the place
<zul> thre patches for hoary done
<zul> BenC: are you going to the the distro team meeting tomorrow morning?
<zul> im debating whether to get up for it or not
<ajmitch> morning
<ajmitch> zul: do it!
* sivang better get to sleep if he wants to make it to that meeting
<zul> wohoo...dateline is doing internet predators again
<bluefoxicy> did they get me on there this time?
* bluefoxicy predates zul
<zul> uh...ok
<Keybuk> BenC: awake?
<Keybuk> BenC: un-ping
<zul> BenC: yay it builds
<fabbione> BenC: please pull from my edgy tree when you are around.. i completed the cluster cleanup for gfs1
<zul> hey
<ajmitch> hi zul 
<zul> hey ajmitch 
<zul> hey
<ajmitch> hey zul
<zul> hey ajmitch 
<zul> BenC: ill send you the diff for hoary tonight
<cbx33> Hi all, ogra pointed me here
<cbx33> I have a problem my keyboard on a Toshiba Laptop
<cbx33> it happens on the live cd as well as the system I upgraded from breezy
<cbx33> it was fine before
<cbx33> but now every minute or so, it just skips two characters or so
<Keybuk> cbx33: the letters "w", "i", "t" and "h" don't work? :p
<cbx33> Keybuk, see, it skipped those 4
<cbx33> sometimes, it holds down one letter for the 2 that it skipped and replaces them with that character
<BenC> cbx33: Does it skip and sometimes repeat?
<Keybuk> it started happening after the upgrade?
<cbx33> Keybuk, yes
<cbx33> BenC, yes
<BenC> cbx33: There's a bug report about that, search linux-source-2.6.15 bug reports for "repeat"
<mjg59> cbx33: Did you have working battery status in breezy?
<cbx33> mjg59, no
<mjg59> Do you in dapper?
<cbx33> yes
<BenC> yeah, that's the one
<mjg59> Ok. It'll be the smart battery driver
<cbx33> wow thanks guys
<cbx33> anything I can do
<BenC> unload the driver
<cbx33> I'de prefer to get rid of the battery monitor
<mjg59> It seems to disable interrupts for long enough that things break
<BenC> acpi_ something
<cbx33> any helpers on how
<mjg59> cbx33: sudo rmmod acpi-sbs
<cbx33> how do I make that permanent?
<mjg59> Will do it temporarily. It's a bit harder to make it permanent.
<Keybuk> echo blacklist acpi-sbs > /etc/modprobe.d/blacklist-sbs
<mjg59> Keybuk: No
<Keybuk> or is it force loaded?
<mjg59> Keybuk: acpid modprobes everything in drivers/acpi
<Keybuk> mjg59: gnargh, and it doesn't use modprobe -b ?!
<mjg59> Keybuk: Doubt it
<BenC> acpid should call modprobe -b
<cbx33> could I add it to my login script?
<cbx33> actually no
<fabbione> hey BenC 
<BenC> hey fabbione, saw your msg
<BenC> I'll pull shortly
<cbx33> that'll do for now
<Keybuk> cbx33: edit /etc/init.d/acpid and add MODPROBE_OPTIONS=-b near the top
<fabbione> BenC: perfect thanks.. it kills cluster/ and update the gnbd code that's the only left over from the cvs tree
<cbx33> what does that do?
<Keybuk> cbx33: it means that the blacklist line I gave you above with work
<BenC> cbx33: and then do the blacklist shown above
<Keybuk> and prevent that module being loaded at boot
<cbx33> ok cool
<cbx33> shall i create blacklist-sbs
<cbx33> if it doesn't exist?
<Keybuk> yes
<Keybuk> (filed a bug on acpid to remind myself to fix that)
<cbx33> can I test by restarting the acpid service ?
<Keybuk> cbx33: if you've done the rmmod, yes
<zul> BenC: so if my hoary boots tonight ill upload it sounds good? or do you want to have a look at the diff again?
<Keybuk> if the module doesn't show up in lsmod after, then it's worked
<alex_joni> hello, any idea what to check if a custom built 2.6.15 (from dapper 2.6.15-23) doesn't show the splash? (it simply stays black)
<BenC> zul: upload sounds good
<cbx33> w00t
<cbx33> thank you guys so much
<cbx33> you have nooooo idea how annoying that was
<cbx33> Keybuk, do you have a bug number for that so I can see when it's fixed
<Keybuk> #49017
<zul> BenC: excelente el presidente
<Keybuk> (for the acpid blacklist)
<Keybuk> #39315 for the battery module problem
<cbx33> thanks
<cbx33> oh you guys are amazing
<cbx33> thank you so much
<cbx33> do you guys hug here ;) like in motu?
<cbx33> and -bugs
<cbx33> if so 
* cbx33 hugs Keybuk, BenC and mjg59 
<BenC> there seems to be a patch to fix that hang when reading BAT/state
<BenC> mjg59: Have you seen the patch that makes acpi/ec.c use a sema instead of a spinlock, and fixes the acpi-sbs problem?
<BenC> presumably it slows down access to the ec, but keeps it from holding off interrupts while reading the bat status
<cbx33> does the fix we just implemented stop the batt monitor from working
<BenC> yes
<cbx33> ok cool just soas I know
<cbx33> thought it did
<mjg59> BenC: Might help
<BenC> mjg59: I'm a little reluctant to put it into dapper...but the problem it's causing is pretty big
<BenC> might be best to disable acpi-sbs for dapper, and test this patch in edgy
<mjg59> What codepath does the patch hit?
<BenC> acpi_ec_polling_wait(), acpi_ec_poll_read(), acpi_ec_poll_write(), acpi_ec_poll_query()
<mjg59> Does anything else use them?
<BenC> it's just ec.c...changing the spinlocks to semaphores and some udelays to msleeps, but with same timeouts
<BenC> use those functions?
<BenC> hmm..not sure
<mjg59> The answer seems to be "no"
<mjg59> I'd just go ahead and do it, tbh
<BenC> ibm_acpi
<BenC> and i2c_acpi_ec
<BenC> acpi_sbs.c uses i2c_acpi_ec
<BenC> fuck it, can't hurt I guess
<BenC> 11 out of 16 hunks FAILED -- saving rejects to file drivers/acpi/ec.c.rej
<BenC> figures
<mjg59> Ha
<mjg59> i2c_acpi_ec is only used for acpi_sbs
<mjg59> The rejects are probably due to acpi *finally* being lindented
<BenC> yeah, looks that way
<BenC> the patch is for .14
<BenC> plus s/polling/poll/
<BenC> crimsun: ping
<zul> right im out of here..
<zul> ttyl
<crimsun> BenC: pong
<BenC> crimsun: should any of the sound patches you sent me for dapper need to be merged into 2.6.17, or will they get pulled from upstream?
<crimsun> BenC: they're all from upstream hg, so they'll get pulled, no need to merge
<crimsun> (saves much work)
<BenC> ok, thanks
<crimsun> np
<zul> yay it boots
<zul> BenC: ping
<BenC> zul: pong
<zul> is there anything i have to do to dput to upload to hoary-security?
<zul> i guess not..
<zul> Uploading via ftp linux-source-2.6.10_2.6.10-34.18.dsc: done.
<zul> Uploading via ftp linux-source-2.6.10_2.6.10-34.18.diff.gz:
<zul> crap it got rejected
<zul> it says im not permitted to upload to hoary security
#ubuntu-kernel 2006-06-09
<WebMaven> BenC: Ping
<BenC> zul: pass everything to me and I'll upload
<WebMaven> BenC: Anything for me to test yet?
<BenC> WebMaven: not yet
<BenC> WebMaven: paste your bug # again please
<WebMaven> https://launchpad.net/distros/ubuntu/+bug/48263
<WebMaven> Not sure who adjusted the importance down from 'Major' to 'High'.
<Keybuk> WebMaven: there is no such thing as Major anymore
<Keybuk> you'll notice Severity and Priority got combined into a new "Importance" field
<Keybuk> High is equivalent
<zul> BenC: sure..
<zul> must...get...key...added :)
<zul> BenC: im just building breezy right now
<alex_joni> infinity: ping
<infinity> alex_joni: ?
<alex_joni> infinity: was wondering if you can look at another kernel (if that's not too much to ask)
<alex_joni> http://pastebin.com/765049
<zul> hey
<zul> BenC: ill do an upload for breezy tonight im just rebuilding again
<zul> i just love rants http://www.inittab.de/blog/rants/20060609_dapper-kernel.html
<alex_joni> I need a bit of help on building a new kernel on dapper with make-kpkg
<alex_joni> it seems make-kpkg doesn't build according to /etc/kernel-img.conf (I put 'silent_modules = yes' in there, but the  deb produced still asks about the modules dir)
<BenC> do you have the latest kernel-package installed?
<alex_joni> this is a fresh dapper install
<BenC> and the deb doesn't build with that info in it, it should read it upon being installed
<alex_joni> reading some more through that "nice" perl script.. the settings in /etc/kernel-img.conf are read only on install?
<BenC> however, it should produce a .deb that doesn't even need that conf option
<BenC> right
<alex_joni> that doesn't do me much good, I need a .deb which I can distribute
<BenC> you'll have to hack the default stuff in /usr/share/kernel-package then
<zul> Hey BenC did we get this patch? ing some more through that "nice" perl script.. the
<zul>                    settings in /etc/kernel-img.conf are read only on install?
<zul> 12:57 < BenC> however, it should produce a .deb that doesn't even need that conf
<zul>               option
<zul> sorry..
<BenC> lol
<alex_joni> I also have issues with the build link beeing removed, for now I think I'll hack the stuff in /usr/share/kernel-package
<BenC> zul: I uploaded hoary
<alex_joni> BenC: thanks a lot
<zul> i hate gnome sometimes
<zul> BenC: good ill upload breezy tonight
<zul> http://bugzilla.kernel.org/attachment.cgi?id=8247&action=view
<BenC> yeah, already in dapper git
<BenC> it'll get pulled to edgy soon as well
<zul> ok..
<zul> im more worried about dapper these days ;)
<BenC> do you have any dapper stuff for me?
<BenC> I need to upload today
<zul> no i dont i been working on hoary/breezy i havent had time for dapper...next upload will have my stuff
<alex_joni> BenC: hacking /usr/share/kernel-package defaults works OK, except that I still get the message the symlink will get removed (which doesn't happen)
<alex_joni> I see this as a bug for kernel-package, any place to report it?
<BenC> launchpad.net/malone/
<BenC> against kernel-package
<alex_joni> BenC: ty
<WebMaven> BenC: anything new on my bug?
<BenC> WebMaven: try pci=noacpi  
<BenC> see if it works and keeps the machine usable
<alex_joni> BenC: fyi #49167
<WebMaven> BenC: I *have* a workaround: acpi=noirq
<zul> WebMaven: cool, can you attach the output of sudo dmidecode to your bug k thx
<BenC> zul: already done
<BenC> fix is in git
<zul> BenC: you are just a busy bee arent you
<zul> which bug # was that?
<BenC> 48263
<zul> oh yeah i already had that patch :)
<zul> heh...im going home...talk to you later//
<BenC> later
<WebMaven> zul: How many times do I need to attache that info?
<WebMaven> Oh, OK.
<WebMaven> BenC: so the fix is in? When can I expect to be able to test it?
<BenC> just uploaded the new kernel
<BenC> so expect to see it from dapper-security within a day or two
<WebMaven> That long? OK.
<WebMaven> So, my testing procedure will be to update and test *without* acpi=noirq, correct?
<BenC> it has to go through the build systems, get ok'd by an archive maintainer, and wait on linux-restricted-modules and linux-meta
<BenC> that's the idea
<WebMaven> OK.
<WebMaven> Cool.
<zul> heylo
<ajmitch> morning zul 
<zul> afternoon ajmitch how is it going?
<ajmitch> badly :)
<ajmitch> just had a hard drive crash & the box lock up
<zul> oops..
<ajmitch> yeah
<ajmitch> I was expecting the hard drive to go out one day soon
<ajmitch> but not take out everything else
<zul> that day arrived
<ajmitch> couldn't ping the box
<ajmitch> oh well
* ajmitch just pulled the cable on the drive before restarting
<ajmitch> it was an old 160GB WB drive out of my old box :)
<infinity> "old" 160GB drive?
<infinity> Dude, that can't be THAT old.
<infinity> I run drives that are past their 10th birthdays.
<ajmitch> I know..
<ajmitch> I haven't had much luck with WD drives though
<infinity> (and now I'm paranoid about the 100GB WD drive sitting over there...)
<ajmitch> should have known when I bought this one
* alex_joni still runs a few pre 1G drives
<infinity> I normally buy Quantum^WMaxtor, but was lured into the whole WD craze when they were the first people with 8MB caches.
<infinity> (I've since repented and gone back to the Quantum lineage)
<alex_joni> infinity: just bought a Maxtor few days ago (16MB cache, works quite good)
<ajmitch> md: md0: raid array is not clean -- starting background reconstruction
<zul> go dput go
<ajmitch> mmm, how I love to see that...
<infinity> alex_joni: Yeah, I have 4 of the 16MB cache SATA drives.  They're quite nice.
<zul> ajmitch: i was playing with drbd today its really neat...
<alex_joni> infinity: this is IDE, but still nice
<infinity> I was very happy to see Maxtor pretty much completely drop their own product line on the floor and just go with Quantum's tech when they bought out Quantum.
<infinity> (A very wise move, IMO)
<ajmitch> certainly
<zul> Uploading via ftp linux-source-2.6.12_2.6.12-10.33_source.changes: done.
<zul> Successfully uploaded packages.
<infinity> I love how you can even HEAR the Quantum mechanics in them.
<zul> yay!
<infinity> Quantum drives have always had the most distinctive seek patterns (and accompanying sound)
<alex_joni> infinity: how about one of these? http://www.grandideastudio.com/src/portfolio.php?cat=&prod=20
<ajmitch> zul: good work
<zul> now if it doesnt get rejected
<infinity> alex_joni: Cool.
<infinity> I don't think my wife would approve of me building one of those for our living room.
<alex_joni> that was about 1.2 MB Hdd
<infinity> zul: Was that an upload to the security queue?
* alex_joni read the manual
<zul> infinity: yep
<infinity> zul: Did elmo add your key to that keyring?
<infinity> Apparently not. :)
<zul> argh!!
<infinity> Rejected: The key (0x207677DEFA14013B) used to sign linux-source-2.6.12_2.6.12-10.33_source.changes wasn't found in the keyring(s).
<infinity> zul: The keyrings on jackass aren't kept automagically in sync with the LP keyrings.
<infinity> zul: So, they're a bit.. Stale.
<zul> can we get them updated somehow?
<infinity> (And, no, I don't have access to fix that)
<zul> yeah ok..
<infinity> I poke elmo about fixing it a few hours back.  He'll likely get to it "sometime"
<zul> ill bug elmo 
<infinity> But for now, you're better off just having BenC re-sign that for you.
<zul> yeah thats what im going to do that
<zul> *sigh*
<zul> on to grub...
<zul> BenC: when are you going to do an upload for dapper?
<infinity> zul: Is 2.6.10-34.18 one of yours?
<infinity> zul: It's FTBFS on amd64.  Where should I forward the log?
<zul> to me
<infinity> zul: Address?
#ubuntu-kernel 2006-06-10
<zul> zulcss@gmail.com
<infinity> Forwarded.
<zul> merci
<zul> ABI has changed!  Refusing to continue; please update the ABINAME accordingly.  Differences
<zul> anyone have access to an amd64 box that i can borrow to test a build?
<ajmitch> yeah
<ajmitch> you need breezy chroot?
<zul> hoary
<ajmitch> hm
<ajmitch> I only have an x86 hoary chroot
<zul> meh..
<ajmitch> but I can make one for amd64
<zul> thanks
<zul> i have my key on my launcpad page
<ajmitch> bah, it has to fetch everything
<ajmitch> typical
<ajmitch> will be a few minutes :)
<zul> okie dokie
<infinity> zul: I assume that was from a different log, since I see no ABI change in the one I sent you. :)
<zul> no that was in the log
<zul> thats the last line in the email you sent me
<infinity> Err, then the mail was cut off...
<zul> ah ok..
<zul> can you put it on the on public_html or something?
<zul> infinity: nm..
<infinity> Oh?
<infinity> Learned how to scroll in gmail? :)
<zul> yes i did! wow..
<ajmitch> heh
<zul> i need a real email provider
<infinity> I can hook you up with POP/IMAP.
<zul> that would be nice
<infinity> Mial me (ha, ha, ha, the irony!), and I'll sort it for you when I'm less asleep.
<infinity> s/Mial/Mail/
<zul> ok will do
<zul> crappers
<ajmitch> infinity: been up all night again?
<infinity> ajmitch: Yeah.
<infinity> zul: Which continent do you live on?
<zul> north america
* ajmitch might try out keybuk's bzr ideas
<zul> infinity: about 2 hours away from jbailey
<infinity> zul: Ahh, kay, the my mail services should be pretty good for you (Florida and/or Texas, depending on moon phase)
<infinity> Better for you than they are for me anyway. ;)
<zul> depending on the moon phase?
<infinity> IMAP from Australia to the US is kinda suck.
<zul> yeah...i wouldnt make fun of austrailia right now because im using your box ;)
<ajmitch> heh
<infinity> zul: Two colo boxes, in the process of failing over from one to the other and decomissioning the one in Florida.
<ajmitch> feel free to make fun of NZ
<infinity> ajmitch: It's hard not to.
<ajmitch> I know, and I live here..
<zul> infinity: ah i see
<infinity> zul: Cheeky email for a man asking for a favour. :)
<zul> infinity: its not running drugs isnt it? :)
<infinity> Wow, all those english words, and not a single english sentence to be found.
<infinity> Congratulations!
<ajmitch> heh
<zul> :P
<zul> infinity: nothing in my email
<infinity> "So hook me up k thx"  <-- That's what I was referring to as "cheeky".
<zul> ah...ok..
<zul> infinity: fixed
<ajmitch> it's building ok now?
<zul> yeah its building ok now...keep fingers crossed thugh
<ajmitch> & wait a few hours
<ajmitch> I see it's only using 1 core
<ajmitch> no -j ?
<zul> nah i forgot :(
<ajmitch> ah
<zul> i could start over if you want..
<infinity> zul: A simple 1-liner, I assume?
<ajmitch> zul: whatever works
<zul> infinity: well the first part was, then it was some funky asm shit
<infinity> The security updates broke some inline assembly?
<infinity> That's worrying...
<zul> no it was me, typos
<infinity> Oh, phew.
<zul> i suck sometimes
<infinity> We all do.
<infinity> Anyone willing to do kernel security gets cut some slack.  It's a thankless task.
<zul> i should check breezy as well
* ajmitch thanks zul 
<ajmitch> you want a breezy chroot as well now?
<zul> please :) but ill let you know
<infinity> Well, dapper built on all 6 arches, so BenC gets a gold star.
* ajmitch debootstraps
<zul> rob schneider is a tool
<ajmitch> k, got the 2.6.12 orig in place, just waiting for breezy debootstrap to go
<zul> ajmitch: thanks so much
<ajmitch> I should put the breezy one on tmpfs & see how long the compile takes :)
<infinity> As core-dev expands further, I think we're going to have to sort out a way to get some porter machines in the DC accessible by non-Canonical developers...
<zul> that would be good
<infinity> (Obviously, on a seperate segment from any Canonical-senstive machines, etc, etc)
<ajmitch> it is pretty necessary
* ajmitch has access to most official archs, but I'm unusual
<infinity> ajmitch: Well, it's all a learning and growth process.
<infinity> When this all started, core-dev WAS Canonical staff.
<infinity> As that shifts a bit, we need to figure out how to deal.
<infinity> (Like the recent change to make the seeds accessible by all of core-dev, and not just staff)
<infinity> Etc..
<zul> ajmitch: well you are a debian dev...unlike us losers non canoical employees ;)
<ajmitch> yeah, it's expected that things will change as you find you need them
<ajmitch> zul: I mean non-debian machines, if I care to upgrade the ppc box downstairs :)
<infinity> zul: I'm a Debian dev too, but I almost never use Debian machines.
<zul> ah..
<zul> infinity: yeah but you are also a canoical empolyee :)
<infinity> I use Debian boxes to debug arm, mips, and s390, since those are the only arches I don't have direct access to.
<ajmitch> not many people have direct access to an s390
<infinity> zul: I don't use Canonical porting machines either.
<infinity> zul: (Of course, I abuse the buildds directly sometimes, but let's not split hairs)
<zul> nyeah nyeah nyeah :)
<ajmitch> infinity: you have sparc boxes?
<infinity> ajmitch: I keep meaning to find one of the rare little deskside ones, but they're A) hard to acquire, and B) a bit pricey still.
<zul> i have sparc boxes though
<infinity> (deskside s390, that is)
<infinity> ajmitch: I have no sparc at home right now.  It left when Daniel moved to Finland.  I'll get another.
<zul> i was on the gentoo sparc team for a while
* infinity revokes your key from the keyring.
<ajmitch> heh
<zul> heh...i also maintained apache for gentoo :P
<zul> that was thankless
<ajmitch> wasn't sabdfl one of the original debian apache maintainers?
<zul> check the changelogs :)
<infinity> There are claims to that effect, though the changelog (which goes back to 1.1.1-1) is missing his name.
<ajmitch> infinity: jelmer's estimate for samba4 & edgy - don't expect much more than a proof of concept
<infinity> Hrm, but 1.1.1-1 wasn't the first upload.  The source package was called apache-httpd before that.
* infinity goes to find it.
<ajmitch> google finds a messages to debian-changes from him
<ajmitch> so the rumours seem true
* infinity nods.
<infinity> Which version?
<ajmitch> he mentions 1.0.3-2
<ajmitch> & an old debian-devel thread, with iwj
<infinity> Ah-ha.
<infinity> That was before the source package format was sanitised.
<infinity> Hence the lack of changelog.
<ajmitch> I feel young
<zul> ajmitch: how old are you?
<ajmitch> at the moment? 23
<zul> you are young
<ajmitch> 24ish next week, but yes, I am young
<zul> i so freaking old 
<infinity> Anyhow, the version of apache in Debian 1.1 (the first Debian release) was done by Miquel van Smoorenburg.
<infinity> And by Debian 1.2, the new packaging was in effect.
<infinity> So Mark's apache contributions were never in a Debian release.
<zul> cool..
<infinity> Sucks to be him. :)
<zul> ...this day in history
<infinity> (My apache releases, OTOH, have been in a few distro releases now... Odd)
<infinity> I guess this means that in ~10 years, I'll be a gazillionaire.
<zul> heh
<zul> http://cia.navi.cx/stats/author/zul?s_message=0 (whee)
<zul> yes at one point i didnt know any better
<zul> but it was just so easy to become a dev
<infinity> So, you spent all that time maintaining apache, and you've not given me  asingle bug report or patch for the apache packages in Debian/Ubuntu?
<infinity> Shame on you! :)
<ajmitch> now you're stuck doing kernel security stuff for ubuntu..
<zul> i wouldnt say stuck :)
<ajmitch> better you than me :)
<ajmitch> zul_: did the kernel build finish, or did you forget to use screen? ;)
<zul_> screen...its late ;)
<ajmitch> ah well
<zul_> im going to bed the compile is still going ill check in later
<ajmitch> ok
<ajmitch> you want to start the breezy compile now?
<zul_> thanks for the helpi appreciate it
<bernard_> hi all. can anybody enlighten me on how i can build the ubuntu kernel for a particular flavour to do some debugging?
<bernard_> if i cat the config and config.686 files into .config, and make-kpkg, i get a kernel which boots, but has serious module versioning issuse.
<fabbione> bernard_: move debian/config/$arch/$otherflavours out of the way
<fabbione> then you do fakeroot make -f debian/rules binary-deb
<bernard_> fabbione: ahh, ta. that won't do a clean first?
<fabbione> you can do:
<fabbione> then you do fakeroot make -f debian/rules clean binary-deb
<bernard_> (i also noticed the rules file borks if there's no -386 build done)
<fabbione> it breaks if you do a dpkg-buildpackage
<fabbione> that's why i didn't use it
<fabbione> and it "breaks
<fabbione> and it "breaks
<bernard_> fabbione: ah, np. i didn't want it to do a clean first. i'll give it a shot, thanks.
<fabbione> OH CRAP
<fabbione> and it "breaks" because 386 is expected to be there
<fabbione> bernard_: you will need to clean.. no matter what
<bernard_> oh?
<fabbione> what sources are you using?
<fabbione> apt-get source linux-source-2.6.15 ? or apt-get install linux-source-2.6.15 ?
<bernard_> 2.6.15-23 from dapper
<bernard_> apt-get source
<alex_joni> bernard_: take the time and set up ccache
<fabbione> ok if you did create a .config and builded in the same source tree, you might as well kill that dir and unpack the source again
<fabbione> the build system makes a copy of the tree in debian/build/build-$flavour
<fabbione> bernard_: what alex_joni said is good too :)=
<bernard_> fabbione: ah, of course.
<bernard_> alex_joni: shall follow your advice. :)
<alex_joni> it saves a lot of time later
<alex_joni> any advantages when apt-get source vs. apt-get install linux-source ?
<alex_joni> except the multi-platform stuff (I'm only interested for x86)
<bernard_> alex_joni: hmm, seems my MAKEFLAGS='"CC=ccache gcc"' isn't being passed to make-kpkg. how do you do it?
<fabbione> bernard_: use the envvars
<fabbione> if [ -d /usr/lib/ccache ] ; then
<fabbione>     export PATH=/usr/lib/ccache:"${PATH}"
<fabbione>     export CCACHE_DIR=/usr/src/.ccache
<fabbione> fi
<fabbione> i slam this one in .bashrc
<alex_joni> yeah, what fabbione said
<fabbione>     export CCACHE_NLEVELS=8
<fabbione> and this one
<fabbione> still inside the if/fi block
<alex_joni> fabbione: what's the basic difference between apt-get source and apt-get install linux-source?
<bernard_> but how do you get the kernel builds to use ccache?
<alex_joni> bernard_: start compiling
<fabbione> bernard_: if you use my snippet, just logout and login again and build
<fabbione> bernard_: it's transparent
<fabbione> and it starts using ccache automatically
<fabbione> alex_joni: the source is the same, the build system isn't
<alex_joni> bernard_: ccache will run the compiler itself, and cache the compiled code on disk, next time (the time you build the kernel again) it will use the cached stuff, it it didn't change
<bernard_> fabbione: ahh, $PATH... i see :)
<alex_joni> fabbione: ty
<alex_joni> fabbione: debuild vs. make-kpkg ?
<fabbione> alex_joni: well somehow yes..
<fabbione> the install doesn't have a debian dir
<fabbione> source does
<fabbione> and you can do more tricks
<alex_joni> right.. ok, thanks
<fabbione> like building an "official" source
<fabbione> or let say.. standard
<fabbione> enabling all the checks
<alex_joni> checks?
<fabbione> like for the ABI compatibility (important)
<fabbione> yeah we do some build time checks 
<alex_joni> ahh.. ok, stumbled across that when I tried apt-get source
<fabbione> if you break the ABI you might not be able to load some external modules
<fabbione> so you want to know that before installing the kernel
<fabbione> specially when you use out-of-tree modules
<alex_joni> indeed.. ok, probably a bit much for me right now .. but good to know where to ask :D
<bernard_> thanks for your help alex_joni, fabbione.
<fabbione> no problem
<alex_joni> bernard_: don't give up ;) it might feel like a bumpy road sometimes
<bernard_> alex_joni: ahh, i'm not easily put off :)
<bernard_> i did a lot of kernel hacking under debian and make-kpkg was great! i've just switched to ubuntu two days ago and i've been trying to nut out the fancy build system.
<alex_joni> bernard_: doing it on dapper?
<bernard_> alex_joni: yup
<alex_joni> oh, you mentioned 2.6.15 so probably yes
<alex_joni> there's one small problem I encountered on dapper & make-kpkg
<alex_joni> infinity helped me out on that
<alex_joni> if you apt-get linux-source && make-kpkg then the usplash won't work
<bernard_> as in apt-get install?
<alex_joni> bernard_: yeah
<alex_joni> it seems that make-kpkg doesn't link vesafb.ko in the initrd dir, which appearantly causes fbcon not to get loaded, which means no usplash
<bernard_> ahhh, bizarre.
<bernard_> i found that too, but thought it was related to the symbol version issues i was seeing
<alex_joni> for now I used a post-install script, placed by hand into the debian/ folder
<alex_joni> let me blog the info
<alex_joni> http://dsplabs.utt.ro/~juve/blog/index.cgi/01149939865
<bernard_> ta :)
<bernard_> so it worked under debian/rules but not just make-kpkg?
<alex_joni> np
<alex_joni> I did use make-kpkg, but had to put the script there
<alex_joni> make-kpkg includes the stuff from debian/ in the deb, so it will eventually get executed when you install the deb.
<alex_joni> but there is no debian/ folder when you apt-get install linux-source, it gets created by make-kpkg, so you need to copy the script there while it's running
<alex_joni> and beware that make-kpkg clean will delete debian/, so you'll need to recopy it later
* bernard_ nods.
<bernard_> next question... where do i bump the ABI version? and does it need to be completely numeric?
<alex_joni> bernard_: if you're using the apt-get source then I think there is a rule to bump the ABI version automagically
<alex_joni> but take this with a pinch of ??? .. I'm not very sure ;)
<bernard_> hehe. i gathered from the rules file that pulls it from the control file, but i was wondering if there was anything higher up that generated that
<alex_joni> bernard_: I know BenC advised me to set a flag to ignore it once
<bernard_> ah hah. you're absolutely right - bumpabi :)
<alex_joni> after asking smarter people (Ben Collins), it seems I have an ABI bump, and I needed to run:
<alex_joni>  	$ echo "Yes" > debian/abi/i386.ignore
<bernard_> it seems that just ignores the fact they've changed
<bernard_> alex_joni: are you distributing your kernels? or are they mainly for you?
<alex_joni> bernard_: not only for me
<alex_joni> smallish number of users though
<alex_joni> couple hundred tops I reckon
<bernard_> how do you version your packages?
<bernard_> i'm debating with myself the best way to do this still
<alex_joni> make-kpkg --version=foo#
<bernard_> ahh, you don't use the abi verioning done by the rules file?
<alex_joni> nope, not really
<bernard_> hmm. perhaps it's not worth the hassle for me either.
<alex_joni> I also don't use the apt-get source package
<BenC> zul: ping
<alex_joni> bernard_: bet BenC knows better which way you should go :)
<BenC> if you change the ABI, then people will likely need other packages rebuilt against your kernel (like linux-restricted-modules-2.6.15)
<bernard_> BenC: ah. if i'm building with debian/rules, i should get big fat warnings if the abi has in fact changed, yes?
<BenC> bernard_: yeah, it's usually preceeded with a diff of the changed symbols
<alex_joni> BenC: who might have some knowledge about the new dapper CD ? I wonder how hard it would be to change the kernel on it..
<BenC> alex_joni: there's probably a howto somewhere on the wiki
<alex_joni> BenC: there wasn't for breezy, but I eventuall figured it out. but the dapper one looks nothing alike :) .. I'll keep looking
<bernard_> BenC: cool. is there any recommended way to maintain out-of-distro kernels with various patches (which alter the abi) ? eg, a different package name, or an abinum like 23.1?
<BenC> bernard_: I'd got for something like 99.1
<BenC> like 2.6.15-99.1-386
<BenC> that way a new ubuntu kernel wont overwrite/override the custom one
<bernard_> ah k. will have a ponder.
<bernard_> thanks BenC
<BenC> np
#ubuntu-kernel 2006-06-11
<jose> please...what change is necessary in source.list to install linux-image-amd64-k8 ???
<brokenthorn> Hello people
<brokenthorn> I want to know how much will ubuntu break if I use a patched vanilla kernel (2.6.16-beyond)
<brokenthorn> Are any patches applied to the ubuntu kernels critical to it's well function?
<cjb> brokenthorn: Should work.
<fabbione> all the bug fixes
<fabbione> BenC: please pull from my dapper tree
<fabbione> there should be only a cosmetic change left for debian/changelog
<brokenthorn> cjb, What does usplash require in the kernel?
<mjg59> Nothing
<mjg59> Other than vga16fb
<mjg59> Well, strictly, any working framebuffer
<fabbione> we also fixed other stuff like modular vesa
<alex_joni> mjg59: hi, any idea who maintains/knows about usplash on dapper?
<mjg59> Me
<mjg59> Or Scott
<alex_joni> mjg59: yay .. I tried following https://wiki.ubuntu.com/USplashCustomizationHowto
<alex_joni> but it stays black
<alex_joni> I do notice an 'splash not found' or similar, while doing 'sudo dpkg-reconfigure linux-image-...'
<mjg59> That's unrelated
<mjg59> No idea, I'm afraid. The instructions look correct
<alex_joni> mjg59: any idea how to debug? any options to usplash?
<mjg59> Nope
<mjg59> gdb is your best bet
<alex_joni> ok, thanks.. 
<infinity> alex_joni: Have you tried just running it at the command line, waiting for it to time out, and see if it had anything angry to say?
<infinity> (Like a failed assertion because your splash image was bigger than your framebuffer, for instance)
<alex_joni> running what at the command line?
<infinity> usplash
<alex_joni> infinity: nice point.. will try
<alex_joni> infinity: how long is the timeout?
<alex_joni> infinity: you were right.. 'Assertion 'yy + pixmap->height <= bogl_yres' failed.'
<bernard_> that's pretty angry ;)
<alex_joni> infinity: is there any way to make the picture centered?
<alex_joni> infinity: if it's smaller, then it defaults top-left. I tried making the picture wider (630px, but it still is off..)
<alex_joni> infinity: nm, I'm just beeing stupid today :(
<alex_joni> mjg59: is there any place where I can read how the usplash stuff works?
<mjg59> Nope
<mjg59> The code is pretty straightforward, though
<alex_joni> mjg59: I am wondering how to build a deb that contains the new usplash
<alex_joni> or will a new make-kpkg already do that?
<mjg59> No
<mjg59> You need to provide the file in /usr/lib/usplash and update alternatives
<zul> hey
<infinity> zul: Hey dude, 2.6.12 failed on amd64 the same way that 2.6.10 did (more or less)
<infinity> zul: 2.6.12 also failed on sparc.
<infinity> zul: You want the logs?
<zul> infinity: meh..
<zul> yeah 
<zul> im fixing breezy as we speak
<alex_joni> mjg59: as a post-install ?
<mjg59> alex_joni: Yes
<alex_joni> mjg59: ty, so I guess I need to hack the make-kpkg debian/rules
<zul> infinity: good morning to you too :)
<infinity> alex_joni: Ideally, you don't want to distribute it with your kernel image.
<alex_joni> infinity: why not?
<mjg59> It would tie a kernel to a given picture
<mjg59> Put the artwork in a separate package (which is how kubuntu, xubuntu and edubuntu do it)
<alex_joni> oh.. ok, I'll investigate
<infinity> zul: Sent.
<zul> thanks...ill take care of it now
<infinity> Danke.
<alex_joni> mjg59, infinity: thanks, looks exactly like what I need
<zul> grrr..
<brokenthorn> mjg59, You said that usplash needs nothing than vga16fb or strictly any working framebuffer. 
<brokenthorn> mjg59, I've chosen vesafb-tng
<brokenthorn> mjg59, what default mode should I pass: 640x480@60?
<brokenthorn> mjg59, So that bootsplash won't stay centered or scale ugly if so
<brokenthorn> Anyone else know?
<zul> infinity: any word on that email account?
<BenC> infinity: is l-r-m uploaded for dapper?
<mjg59> BenC: Hrm. CONFIG_USB_SUSPEND possibly ought to have been switched on.
<BenC> mjg59: ok, done
<mjg59> Ta
<bernard_> mjg59: how experimental is that still?
<mjg59> To the best of my knowledge, not very
<mjg59> (Now - it used to be horribly flaky)
<mjg59> Biggest issue is that it's also tied into device suspend as well as host suspend
<bernard_> and the device suspend code isn't so crash hot?
<bernard_> or just the fact that devices have to be suspended as well now?
<zul> whee...fixing FTBS is fun..
<mjg59> Yeah
<mjg59> Hm. I should really set up a linux-laptop git tree at some point
<BenC> zul: already fixed hoary/breezy FTBFS
<zul> hoary yes, breezy still working it
<BenC> I already did I mean :)
<zul> oh...what about the sparc one?
<BenC> didn't know about the sparc one
<BenC> is that dapper?
<zul> breezy
<BenC> so will you take care of all of breezy?
<zul> im lookin at it right now
<BenC> I can send you my fixed dpatch for the i387 amd64 typo
<zul> sure..
<BenC> email?
<zul> yes please
<BenC> zulcss at something or other
<zul> zulcss@gmail.com
<BenC> ok, thanks :)
<zul> http://zulinux.homelinux.net/ubuntu/kernel/sparc-error.txt
<BenC> sent
<BenC> why are we building kernels for breezy-sparc anyway?>
<zul> infinity: had sent me the build logs and i assumed i ad to fix it *shrug*
<BenC> just wondering why the build system even bothers :)
<zul> hehe...dont as k me :)
<zul> BenC: breezy is building now
<zul> BenC: include/asm/i387.h:193: error: parse error before "GENERIC_NOP8"
<BenC> interesting
<BenC> breezy?
<zul> yep
<BenC> is that x86 or x86_64?
<zul> x86_64
<BenC> $ cat include/asm-x86_64/i387.h | wc -l
<BenC> 150
<BenC> how can there be an error on line 193?
<zul> i dont think GERNIC_NOP8 is defined anywhere
<BenC> but there are only 150 lines in the file
<zul> mine has 220
<zul> sh-3.00# cat i387.h | wc -l
<zul> 220
<zul> sh-3.00# pwd
<zul> /tmp/linux-source-2.6.12-2.6.12/debian/build/build-amd64-generic/include/asm-x86_64
<BenC> even the one in 2.6.17 is only 206 lines
<zul> weird
<BenC> something's not right
<zul> yeah let me look around
<BenC> zul: did you use the dpatch I sent you?
<BenC> I put that into my breezy tree and it built
<zul> grr...let me try again...
<BenC> that patch does add about 50 lines, and I thought I had it patched when I checked the file size
<BenC> I didn't, but now that I do, I still don't see a GENERIC_NOP8 in there
<zul> same here
<zul> can you send me the patch for breezy?
<BenC> sent
<zul> thanks..
<zul> BenC: its building now
<zul> BenC: should i do another upload with a version bump or how should i handle it
<WebMaven> BenC: Whn do you think I'll see the new kernel as an update for Dapper?
<BenC> zul: in the debian/changelog, change just bump the version on the same changelog entry
<BenC> zul: and rename the debian/00list-* files to that version
<BenC> WebMaven: it's up to the -security folks, I have no idea
<BenC> they are probably waiting on the breezy update to finish
<BenC> zul: debian/patches/00list-* files I mean
<BenC> don't forget the hppa one
<WebMaven> BenC: OK. So when will the Breezy update finish?
<BenC> WebMaven: when it happens
* WebMaven rolls eyes
<WebMaven> BenC: Do you have an educated guess, based on your past experience?
<BenC> anywhere from 1 hour to 7 days
<WebMaven> Wow. Okay....
<WebMaven> I guess I'll just wait then....
<crimsun_> BenC rocks, but he can't predict the future. Yet.
<WebMaven> Wasn't asking for a prediction, just a guess.
* WebMaven settles in for a long wait.
<BenC> WebMaven: you do realize that this fixed kernel isn't going to act any different than with acpi=noirq kernel command line, right?
<WebMaven> Right.
<zul> BenC: breezy kernel built on amd64
<WebMaven> But then, I won't have to worry about re-applying the fix when I do a kernel upgrade, or install the K7 kernel.
<WebMaven> For example, I just un-installed the 2.6.17 kernel you had me test, and had to apply the flag to the 2.6.15 kernel that was applied by default.
<WebMaven> I hate doing that.
<WebMaven> I deal with a lot of FS, and install, upgrade, and modify it all the time, but it's all at the web-app-server level.
<WebMaven> I really don't want to even have to think about the OS at all, and prefer think about the desktop as little as possible.
<WebMaven> I know I'm acting a bit like a dog with a bone here, but I wasn't the first reporter for this bug, and I wouldn't be worrying about testing the new kernel so much if the previous reporter hadn't been blown off with only a workaround and no permanent fix.
#ubuntu-kernel 2007-06-04
<poningru> quick question, is the gutsy kernel currently the .22 rc or are we still on .21?
<poningru> need it for tribe1 walkthrough
<crimsun> the latest, 6.13, merged 22-rc3
<crimsun> it's noted in the changelog.
* ..[topic/#ubuntu-kernel:crimsun] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-6.13 | Latest news: -rt and -xen kernels removed, failures in patch | linux-meta uploaded for gutsy 2.6.22 kernels. | New Kernel Team machine: http://kernel.ubuntu.com/
<BenC> crimsun: thanks
<poningru> awesome
<poningru> thanks
<BenC> and 6.13 will definitely be what tribe1 gets released with
<poningru> another question: will SLUB be used?
<BenC> it already is
<BenC> has been for a few weeks now
<poningru> awesome
<poningru> thanks
<BenC> np
<BenC> poningru: since you're doing release notes, please add in there that all of our third party modules and added firmware have moved to linux-ubuntu-modules-2.6.22, and that users need to ensure that they have linux meta packages installed for proper upgrades
<poningru> sweet will put that under upgrade notes
<BenC> mainly linux-generic
<BenC> thanks
<poningru> :D
<poningru> np
<poningru> can you guys look over https://wiki.ubuntu.com/GutstyGibbon/Tribe1#head-8a02e12763c54b7c8a328619650ce2e38f78d93c
<poningru> see if its ok?
<poningru> thanks :)
<poningru> ...
<poningru> can someone check?
<crimsun> it -is- Sunday night or very early Monday morning for most devels
<crimsun> but sure, I'll once-over it, though I'm by no means comprehensive for all changes.
<crimsun> poningru: would you like me to outline suggestions in #ubuntu-doc or just make changes?
<poningru> either or
<poningru> but I can do it
<poningru> crimsun: 
<poningru> yeah I guess it can wait till later
<crimsun> poningru: ok, I'll edit it.
<poningru> gracias
<crimsun> edited.
<crimsun> (also may wish to mention continuing work with powersaving: install powertop from universe)
<poningru> only available in gutsy right?
<crimsun> correct, but you -are- writing Tribe1 notes, so...
<poningru> right just making sure feisty features done make it in there 
<poningru> thanks man :D
<jml> Is it likely that bug 117864 will be fixed in Feisty?
<jml> i.e. https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117864
<crimsun> it's missing `dmesg` at least.
<jml> crimsun: ok. I'll supply that soon.
<tepsipakki> hey, according to debian bug 424975 the fglrx driver now supports xserver 1.3, could we get this in before main is frozen for tribe 1?
<kraut> moin
<dimon08> hi all?
<dimon08> !
<dimon08> why are there so many bugs in the 2.6.20-16 kernel?
* Starting logfile irclogs/ubuntu-kernel.log
<zul> morning
<abogani> zul: morning
* Mithrandir scratches his head over this LSI/megaraid card.
<Mithrandir> isn't the 1068 supposed to just work with feisty?
<toad165> A question about disk buffer cache in linux kernel: Is it possible to disable them completely?
<mjg59> Read or write?
<toad165> to repeat the question: Is it possible to completely disable disk buffer cache in linux kernel?
<Keybuk> <mjg59> Read or write
<mjg59> And do you mean the disk cache or the kernel cache?
<toad165> disk cache
<toad165> I am running kernel inside the simulator
<toad165> and want to disable caching of the kernel
<toad165> That is the cache of disk blocks recenly read/written
<mjg59> Then no
<mjg59> You can flush it
<toad165> Okey
<toad165> thanks
<mjg59> With /proc/sys/vm/drop_caches
<iwj> Anyone here who'd like to comment on a crazy crazy plan I'm concocting ?
<iwj> It's for a weird kind of test harness.  The basic idea is to have the kernel kmalloc a huge buffer and write some trace information into it in a circular buffer style.  It would be read out later by using /dev/mem.
<iwj> How big a piece of contiguous ram can I allocate this way ?
<iwj> And as a not-currently-kernel-hacker how doomed am I ?  (I've done dev work on unix kernels in the past so I'm not completely ignorant)
<iwj> https://blueprints.launchpad.net/ubuntu/+spec/full-filesystem-sanity-gutsy is the relevant spec; wiki page at https://wiki.ubuntu.com/BootLoginWithFullFilesystem.
<iwj> I'd appreciate comments from you guys ...
<mjg59> Hm. It's an interesting idea.
<mjg59> I kind of wonder whether a ramfs based solution would be possible
<mjg59> kmalloc isn't a great plan. Stuff allocated that way is unswappable.
<mjg59> I'm also not sold on the requirement for it to be contiguous. Providing some method for dumping it out of the kernel would be easy enough
<maks_> do you guys deploy nouveau already?
<kylem> no.
<kylem> airlied asked me not to because they hadn't decided to freeze their drm abi.
<kylem> ... then fedora went and did it.
<kylem> anyway, keeping xf86-video-nouveau and kernel driver in sync would be a massive pain in my ass.
<maks_> ok and how is the fedora feedback?
<kylem> no clue.
<kylem> the thought of building the kernel modules externally and shipping them with the X driver occured to me, and i did a bit of work on it, but i don't think nouveau is ready for a deluge of user bug reports.
<maks_> 22:51 <jima> fedora 7 shipped with nouveau, iirc, but not enabled by default.
<maks_> so will gone unnoticed mostly
<kylem> yeah
<kylem> 'nv' is improving a bit recently.
<kylem> so perhaps nvidia is trying to deflect some criticism.
<maks_> kylem fedora says to have added sparse as build req *cool*
<kylem> hmm. interesting.
<kylem> linus hasn't relicensed sparse, has he?
<maks_> would mean trouble as in debian sparse landed in non-free afair
#ubuntu-kernel 2007-06-05
<bdmurray> kylem: are you familiar with 53923?
* #ubuntu-kernel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* Starting logfile irclogs/ubuntu-kernel.log
<kraut> moin
<abogani> BenC: Ingo don't have released realtime-preempt patch for 2.6.22... What do you prefer that i should do? Try to adapt realtime-patch for 2.6.21 to 2.6.22 ? Or wait Ingo?
<crimsun> I would do the latter.
<crimsun> Ingo is familiar with the nuances.
<opti> anyone awake?
<abogani> BenC: Ingo don't have released realtime-preempt patch for 2.6.22 yet... What do you prefer that i should do? Try to adapt realtime-patch for 2.6.21 to 2.6.22 ? Or wait Ingo? crimsun already suggest me the latter...
<BenC> is Ingo expected to work on getting it ready for 2.6.22 any time soon?
<zul> heh you can go crazy like me :)
<abogani> zul: :-)
<abogani> BenC: Three times i asked it to Ingo without response. :-(
<abogani> I obtained only the change of the two EXPORT_SYMBOL for closed video drivers...
<BenC> abogani: you can wait for Ingo, but then you risk it not being ready in time to include for gutsy
<BenC> honestly, I'd work on it myself, but I'm way too busy, and it would set a bad precedent for patches like this (who needs to work on it when Ben will do it out of frustration :)
<zul> besides we dont want to make BenC go crazy..
<zul> not yet alteast
<abogani> i'm agree, zul 
<abogani> :-)
<abogani> BenC: I have already a simple adapt of the realtime-preempt 2.6.21.3-rt9 (lastest) against the updated gutsy git tree but i have a big problem between ide subsystem (drivers/ide/ide-probe.c) and hrtimer (kernel/timer.c) that i cn't resolve :-(
<BenC> can you forward me your current diff + those conflicts?
<BenC> if it's easy, I can get it out real quick
<abogani> BenC: No conflicts and, IMHO, it's not easy to resolve...
<abogani>  ide_generic_init() hang. set_current_state() inside msleep never return. A custom system that lives only in ram works! :-(
<abogani> s/set_current_state/__set_current_state
<BenC> Hmm, a problem with hi-res timers maybe?
<BenC> maybe disable that for preempt kernel?
<abogani> BenC: Can you remember me the lastest day for universe inclusion (for a -rt kernel) ?
<BenC> end of June
<abogani> BenC: Yes i think that is a problem with hrtimer changes by realtime-patch.
<abogani> Ok i wait an other week .... 
<abogani> Thanks BenC
<BenC> np
<tyyy> hi all
<tyyy> can somebody help me?
<tyyy> my system is freezing after a while but i dont knowe why
<tyyy> hi all
<tyyy> anybody there?
<JanC> tyyy: probably a driver that crashes
<JanC> you might try to search for bugs related to your hardware
<tyyy> how?
<tyyy> can i track this down what it is?
<tyyy> wich driver
<tyyy> can adept be the couse?
<JanC> maybe, but first try searching the bug tracker for bugs that happen for other people with the same hardware as you have
<tyyy> where?
<tyyy> i have a sony vaio vgn-u70p
<JanC> http://bugs.ubuntu.com
<tyyy> its a handhelp with touchscreen
<JanC> wat wifi chip is in it?
<tyyy> its working only with the ath driver
<tyyy> prolly atheros
<tyyy> if i look for vgn-u70p i dont get anything
<JanC> I think looking for the hardware pieces in it or attached to it might be more useful
<tyyy> nothing related to my machine
<tyyy> so far
<tyyy> seems like it is specific with my configuration
<tyyy> is there any crash log?
<JanC> you can try looking in the logs in /var/log
<Keybuk> BenC: known problems with 3945?
<BenC> Keybuk: nope, make sure you have lum, linux-image and lrm installed
<Keybuk> I'm having to toggle the hardware switch to make it work
<Keybuk> this could be an NM problem
<BenC> weird, haven't had that issue with mine
#ubuntu-kernel 2007-06-06
<jmg> hey all
<jmg> bug #75295 ?
<kraut> moin
<thedeviantone> I'm trying to install  Ubuntu 6.06 LTS on an AMD650 with a PERC2/SC SCSI Controller and i always get a "Kernel Panic Error" VFS: Could not Mount root device use correct root= boot option
<thedeviantone> can anyone helpme with server install
<JanC> thedeviantone: this is not a support channel but a kernel developer channel
<JanC> you might try #ubuntu 
<thedeviantone> sorry i just can't find the right help newhere
<JanC> or the forums
<thedeviantone> k
<JanC> you might have to change the grub menu config
<shawarma> thedeviantone: You tried #ubuntu-server ?
<thedeviantone> shawarma thanks fir the right channel
<Mithrandir> https://wiki.ubuntu.com/KernelTeam claims the next meeting is May 29th, something which I don't believe in.
<tyyy> need help
<tyyy> my system is freezing
<mjg59> BenC: Why does the git repository keep getting into a state where I can't pull any more/
<mjg59> ?
<mjg59> I get conflicts with debian/changelog and so on
<lamont> what is supposed to be in /usr/src/linux-headers-2.6.22-6-itanium/arch/ia64/module.lds??
<lamont> ('cause it doesn't exist...)
<lamont> sigh.  dear linux-source-2.6.22, Please deliver arch/ia64/module.lds in linux-headers-$version.  kthxbye
<lamont> BenC: since I don't have write access to git, could I talk you into doing that with the upload after tribe 1?  That way linux-ubuntu-modules-2.6.22 will build, and debian-installer has a chance
<lamont> actually, all we need is the symlink in  linux-headers-2.6.22-6-itanium
<lamont> linux-ubuntu-modules-2.6.22-2.6.22/debian/build/build-itanium/wireless/p80211/wlan/wlan_compat.h:136:3: error: #error "No CPU identified!"
<lamont> hrm... and either don't build that one, or I'll have to fix it.
<mjg59> BenC: Have you done a git-rebase, or something? The history looks /very/ odd
#ubuntu-kernel 2007-06-07
<BenC> mjg59: I've been git-rebase'ing on linux-2.6 throughout gutsy
<BenC> will continue to do so until 2.6.22 is released
<mjg59> BenC: It appears to make pulling immensely painful
<BenC> git-pull -f? :)
<crimsun> I basically have to erase my cloned copy and reclone.
<mjg59> It also makes the history a mess
<mjg59> Shouldn't you juts be pulling upstream?
<BenC> I have patches being merged upstream, rebasing is easier
<BenC> plus it'll make it easier when we move to gutsy+1, I can fixup each patch individually and not have to have a huge merge delta separate from the actual commits
<BenC> how does it make the history a mess
<mjg59> Everything appears to be committed on the day you rebase, as far as I can tell
<BenC> there's got to be an easy way to keep synced with a rebased tree, most of the trees that linus pulls from get rebased all the time
<mjg59> No, Linus tells people not to rebase
<mjg59> (for the most part)
* jmg cracks his head open over http://bugzilla.kernel.org/show_bug.cgi?id=8316
<BenC> Well rebasing is making the tree a lot easier to maintain, and makes me not dread gutsy+1, so we might have to figure out how to make it easier for you guys to pull when it happens :)
<mjg59> The history is regenerated. As far as I can tell, that effectively makes pulling impossible
<BenC> but there has to be a way to do it
<mjg59> If I was following Linus's tree, it'd probably be ok
<BenC> kyle, pkl and rtg are doing it
<BenC> if you have gutsy git you have Linus's tree :)
<mjg59> But right now, I pull and get a huge number of conflicts under debian/
<mjg59> Because they've effectively been deleted and readded
<jmg> how come 8316 got assigned to jeff and 8244 got assigned to albert lee?
<jmg> and what do you make of this? http://bugzilla.kernel.org/show_bug.cgi?id=8244#c15
<jmg> 1. Ubuntu Linux issues an incorrect INQUIRY command to the drive. (Other distros seem to have the INQUIRY correct.)
<BenC> mjg59: you could try using git-fetch origin; git-reset --hard origin
<BenC> not sure if that will work
<calc2> anyone know how i could go about building just a subdir of the kernel, eg sound/pci/hda ?
<calc2> i'm trying to write support for the Realtek 268 audio codec
<calc2> bbl, laptop is dying
<calc2> grr battery doesn't last much with wireless on
<abogani> Hi all, Please help me! Reply to my last email in the kernel ml!
<crimsun> well, there seem to be all sorts of things missing.  Was the merge sane and actually correct?  No missing structs?
<crimsun> (I guess those were dumb questions, since the merge wasn't sane...)
<crimsun> hmm, and upstream already merged alc268 support.
<crimsun> Guess Chris will get his wish without blinking.
<abogani> crimsun: No missing struct (to my eyes) :-(
<abogani> crimsun: Uhhhi without CONFIG_SMP -rt kernel compile! :-? 
<abogani> Perphaps realtime-patch add some ifdef/ifndef ?
<kraut> moin
<jmg>  OH NO! upgrading to gutsy hardswitched my wireless off :'((((
<jmg> Radio Frequency Kill Switch is On:
<jmg> Kill switch must be turned off for wireless networking to work.
<jmg> augh, and i deleted windows
<abogani> BenC: Do you a minute for me?
<newz2000> is it remotely interesting that I get 'bug soft lockup detected on cpu#0' on a dapper server running in vmware, repeatable whenever I try to do mkfs.ext3?
<newz2000> I know what's causing the problem (the disk was partitioned on another computer and the vmware bios detected it with different settings.
<lamont> BenC: you about?
<BenC> lamont: yeah
<lamont> the linux-headers-$mumble-{itanium,mckinley} packages are missing a symlink...
<BenC> yeah, I meant to fix it on the last upload
<lamont> arch/ia64/module.lds
<BenC> Yeah, silly ia64 :)
<lamont> and then I have a patch to linux-ubuntu-modules
<BenC> ok
<lamont> and I wonder if hppa also needs module.lds...
<BenC> the fix should do it for any that have *.lds
<lamont> right
<lamont> how would you like me to handle the linux-ubuntu-modules?
<lamont> 21 line unidiff that (unfortunately) adds WLAN_IA64 (a constant.. suckage) and setting vars to that
<BenC> you can either send me a diff via kernel-team@ or I can get you on kernel.ubuntu.com (zinc.ubuntu.com) and you can do some clones I can pull from
<lamont> hrm... the first is easier for me, the second is probably the right direction longer term, no?
<BenC> yeah, patch now, and account request to follow sounds good
<BenC> you can send me a login name and ssh key for that
<lamont> ben.collins@u.c?
<BenC> yeah, sounds good
<lamont> you prefer rsa or dsa keys?
<BenC> Doesn't matter to me personally and elmo never gave a preference
<lamont> sent
<BenC> thanks, will forward that along to admin and they'll email you when it's setup
<lamont> thanks
<lamont> once the kernel fix is there, then linux-ubuntu-modules (patched) will build, and debian-installer stands a chance of building.
* lamont would really love to try a gutsy install on ia64 this week(end)
<abogani> BenC: Do you a have a minute for me? :-)
<abogani> When will be released 2.6.22-7 ? 
<mjg59> BenC: Any chance we can test http://www.codon.org.uk/~mjg59/tmp/ahci.quirk ?
<BenC> mjg59: weren't all the piix/ahci quirks removed awhile back?
<BenC> mjg59: do you want to just send me a login and ssh key for kernel.ubuntu.com so you can do some gitness? :)
<mjg59> BenC: I don't think we ever had anything that tried to shift piix over to ahci
<BenC> mjg59: what's the reason for the patch? Does it override BIOS legacy/native mode or is this working around a bug in the BIOS for AHCI mode to work properly?
<mjg59> Right now, if the BIOS has set the device up for both AHCI and legacy mode, we'll drive it as a legacy device
<mjg59> It'd be preferable if we could use it in AHCI mode
<mjg59> Especially with the link level power saving stuff appearing
<BenC> Ok, sounds reasonable...how much testing has it had so far?
<mjg59> Well, that's why I'd like to push it slightly wider :)
<mjg59> On most machines it'll be a noop
<mjg59> On my Apple, it works
<mjg59> There's the /potential/ for BIOSes to program random shite into the BAR
<mjg59> But it's basically impossible to know unless people run it
<geser> I'm upgrading to gutsy and I'm missing the prism54 drivers from the 2.6.22 kernel. Does somebody know where I find them?
<mjg59> geser: linux-ubuntu-modules ?
<mjg59> Oh, wait, no - that should be mainline
<geser> in the config for 2.6.20-16 it's CONFIG_P54_* but this option isn't listed in 2.6.22 anymore
<geser> btw got the lowlatency kernels got dropped in gutsy?
<crimsun> geser: yes, due to tickless.
<geser> ah
<tsmithe> hi
<tsmithe> i was wondering about getting alsa-firmware into linux-restricted-modules for gutsy
<crimsun> git changeset.
<crimsun> cough.
<tsmithe> yes yes
<tsmithe> i'm not totally sure how to accomplish that, ok!
<tsmithe> :P
<tsmithe> also, having one of these git changesets isn't going to help unless i can get it included
<tsmithe> so i need to know about the process for that too ;)
<crimsun> well, clone l-r-m first
<crimsun> then go through the addition locally, then generate a changeset
<crimsun> or ask for access using the procedure outlined in the wiki
<tsmithe> is the process for making the addition outlined in the tree?
<crimsun> no, you should probably read git-core documentation for that
<crimsun> e.g., www.kernel.org/git/
<tsmithe> righty
<tsmithe> well i'm off to sleep now :)
<astronouth7303> How would I obtain and compile the coretemp module for my currently installed kernel?
#ubuntu-kernel 2007-06-08
<crimsun> for which kernel?
<astronouth7303> 2.6.20-16-generic on feisty fawn
<calc> BenC: hello
<calc> is there a way to build just part of the kernel?
<calc> i want to just rebuild the snd-hda-intel object
<crimsun> 03:42 < crimsun> hmm, and upstream already merged alc268 support.
<crimsun> 03:42 < crimsun> Guess Chris will get his wish without blinking.
<crimsun> of course you parted long before that.
<calc> crimsun: whee!
<calc> thats cool
* calc goes to look for the patch
<crimsun> but to answer your question, yes.  Use SUBDIRS=sound
<calc> i was looking in the git repo that benc controls and it didn't appear to be in there yet, but looking at kernel.org now
<crimsun> no.
<crimsun> http://hg.alsa-project.org/alsa-kernel/rev/dd701601157b
<crimsun> upstream uses Mercurial, not git.
<calc> oh i see
<calc> i was looking at jaroslav's kernel alsa git
<calc> which must not be up to date for everything
<astronouth7303> crimsun: were you answering me?
<calc> http://git.kernel.org/?p=linux/kernel/git/perex/alsa.git;a=log  <- that was where i was looking, oops :)
<crimsun> calc: jaroslav pushes to his git tree fairly regularly but not nearly as frequently as fixes are committed to hg.
* calc oh ok
<crimsun> takashi mostly handles hg.
<calc> er oh ok ;)
<calc> i can rip that patch and rebuild it for feisty :)
<crimsun> astronouth7303: you can grab the source subdir and build it
<crimsun> calc: it'll be merged into gutsy's source anyhow.
<astronouth7303> the only place I can find the coretemp module is from torvald's branch on kernel.org
<crimsun> astronouth7303: ...which is the base of gutsy's current git.
<astronouth7303> so if I build it as a module from gutsy, will it load in my current kernel?
<calc> crimsun: yea
<calc> i tried running gutsy on my new laptop and it couldn't see to work with my intel 3945 wireless
<calc> maybe another bug that will be fixed soon, dunno
<calc> would be nice to be on gutsy by the sprint next month
<mjg59> crimsun: Oh, my neighbour found that position_fix=1 seemed to be needed to make his new MacBook (C2D) have decent sound quality
<mjg59> Had distortion otherwise. This was on fesity.
<mjg59> Is that likely to be sorted upstream, or should I send you subsystem details?
<calc> looks like 268 could use some extending support if i looking at it right, but it should at least work for basic sound after this patch
<crimsun> mjg59: SSID, please
<mjg59> crimsun: Is that the PCI subsystem or the codec subsystem?
<crimsun> PCI
<mjg59> Ok
<mjg59> Hang on a sec
<crimsun> calc: Realtek already has extended support; may want to check there.
<crimsun> (they provide a tarball based on some stable alsa-driver release)
<calc> ah cool :)
<calc> less code i have to think about the better ;)
<jmg> upgrading to gutsy scragged my laptop
<jmg> somehow it managed to hardswitch the wireless off
<calc> jmg: did it to me too, afaict
<jmg> i cant reenable it without booting into windows and i deleted windows ages ago
<calc> jmg: i was on 3945 wireless
<jmg> calc: ipw2200
<jmg> haha 'was'
<calc> jmg: going back to feisty fixed it for me
<calc> er was on gutsy i meant to say with 3945
<calc> hehe
<jmg> calc: im not sure it will fix for me
<jmg> because fn-f2 didnt work in feisty either
<calc> i has a 2915abg laying around here somewhere, but it wouldn't fit in this laptop anyway
<jmg> speaking of which
<calc> may be a different issue than what i saw though they are similar chips
<jmg> i need gutsy alpha 1
<calc> intel 2200bg vs intel 3945abg
<jmg> i wonder if it was something i did when i was in feisty to try and enable fn-f2 which broke it when i upgraded to gutsy
<jmg> so im gonna try the alpha
<calc> crimsun: yea realtek's alsa driver has much better mixer support
<mjg59> crimsun: 8384:7680
<crimsun> mjg59: thanks, could you download and run http://www.linux-sound.info/alsa/scripts/alsa-info.sh on said machine?
<calc> wow i turned my wireless off and then back on about 20s later and i stayed connected :)
<crimsun> thanks, TCP!
* calc turned it back on once he realized he was on irc
<calc> oops ;)
<calc> this laptop eats batteries like nothing i've ever seen :\
<calc> 67% 1h7m
<calc> occasionally it drops down ~ 30m
<calc> and that is with a 4000mAh battery
<jmg> calc: how does it perform on windows?
<calc> not sure i only ran windows on it about 5m
<calc> need to reinstall vista on it for dual boot later on
<calc> it is doing that while using wireless and compiling a kernel though
<calc> also the processor is set to go up to full speed while under load on batteryu
<calc> forcing it at slow setting on battery may help out
<astronouth7303> if I build a module against the 2.6.22 source tree, will it load in a 2.6.20 system?
<calc> my old athlon64 laptop forced the cpu to slow speed on battery always
<calc> so i guess its not too bad
<calc> astronouth7303: doubtful
<astronouth7303> the linux-source-... package has the config used to build the distributed kernels?
<calc> yes
<calc> you can run dpkg-buildpackage on it to get the distributed stuff
<calc> i need to go find the power cord its kill my battery doing the build
<astronouth7303> so I have my coretemp.ko file, and I know where it goes even
<astronouth7303> sortas
<astronouth7303> the kernel will reject modules just made wrong, right?
<calc> yea
<astronouth7303> how do I tell it to just install 1 module?
<astronouth7303> can I?
<poningru> insmod
<poningru> man insmod
<poningru> I have to go to sleep
<astronouth7303> oh, lovely
<astronouth7303> http://www.astro73.com/pastebin/pastebin.php?show=75
<astronouth7303> so here's my last dumb question
<astronouth7303> any ideas when the upstream 2.6.22 will be out?
<kraut> moin
<geser> is bug 114855 really a non-bug? because I've installed linux-image-generic from gutsy but I'm still missing the drivers for my prism54 wireless card
<crimsun> is linux-generic installed, too?
<abogani> crimsun: morning
<abogani> uname -r
<abogani> 2.6.22-rc3-rt
<abogani> uptime
<abogani>  09:01:20 up 13 min,  4 users,  load average: 98.60, 81.98, 454.28
<abogani> :-)
<abogani> up and running
<geser> crimsun: no, linux-generic is not installed
<geser> and when I look at the contents of linux-restricted-modules-2.6.22-6-generic with packages.u.c, I don't see there any prism54 modules
<geser> I'm running 2.6.20-16 for now and the prism54 modules are located at /lib/modules/2.6.20-16-lowlatency/kernel/ubuntu/wireless/p54/
<crimsun> abogani: mornin' :)
<geser> but they aren't in linux-ubuntu-modules-2.6.22-6-generic or linux-image-2.6.22-6-generic anymore
<pmjdebruijn> hi
<pmjdebruijn> I noticed the server/desktop kernels both don't have MMIO and NAPI enabled for the via-rhine
<pmjdebruijn> is there a reason for that?
<crimsun> geser: file a bug
<geser> a new one or simply reopen the old one?
<crimsun> maybe add a gutsy task if it's relevant to the old one.
<crimsun> so yes, reopen it if relevant
<dade`>    6.6% (125.0)       <interrupt> : ehci_hcd:usb1, uhci_hcd:usb2 
<dade`> hm
<mjg59> hciconfig hci0 down
<dade`> but only using xorg
<dade`> if i switch to console with ctrl+alt+f1 
<dade`> they go away
<mjg59> What hardware is this?
<dade`> macbook
<mjg59> Trackpad
<dade`> uh
<dade`> so i read somewhere they're fixingi t
<dade`> i915 vblank interrupt too
<mjg59> Yes
<dade`> if they fix those 2 things the next in the list is wifi, that wakes up 30 - 50 times/second
<dade`> is that avoidable ?
<mjg59> It's being worked on
<dade`> ok
<dade`> i can wait :)
<dfeser> hi!
<dfeser> someone tryed 2.6.21 yet?
<dfeser> ?
<mjg59> We're not shipping 2.6.21
<dfeser> right
<dfeser> but all kernels that come with feisty don't let me charge my blackberry anymore
<dfeser> something has changed from edgy to feisty
<dfeser> can you tell me what it is?
<dfeser> some change in the usb system
<mjg59> feisty uses 2.6.20
<dfeser> i know!
<dfeser> i'm just trying 2.6.21 because the charging does not work anymore
<mjg59> So, yes, lots changed between edgy and feisty
<dfeser> wow. great answer
<dfeser> there is a small script called bcharge. it puts the power of a certain usb port up to 500mA if there is a blackberry connected to it. 
<dfeser> under edgy this was working great
<dfeser> but under feisty it seems as if there is something that puts the power back to 100mA after a few seconds
<dfeser> no clue?
<mjg59> Not off-hand, no
<mjg59> Could you file a bug?
<dfeser> could i what?
<dfeser> is there a way to get the old edgy kernel to my feisty?
<mjg59> Not really, no
<dfeser> :-/
<mjg59> But if you go to https://launchpad.net/bugs/+filebug you can report the problem
<dfeser> does ubuntu ship any kernel sources?
<mjg59> Yes
<dfeser> ah found it
<mjg59> Cool
<dfeser> i will try compiling my own kernel from these sources...
<EtienneG> he guys
<EtienneG> I'm fact-checking for a journalist that do a paper on Ubuntu
<EtienneG> what's the maximum number of CPU we support ? (I think it vary by kernel type, ie generic vs. server)
<EtienneG> and what is the max amount of RAM ?  (IIRC, 16 GB with PAE, but it might be different with 64 bits arch)
<ivoks> -generic 8CPU, 4GB RAM
<EtienneG> ivoks, any idea for -server ?
<ivoks> i can tak a look only in dapper
<ivoks> 64G, 8CPU
<EtienneG> ivoks, thanks a lot
<ivoks> np
<JanC> EtienneG: it might be different in recent versions, but you can look this up in the respective kernel config files...
<EtienneG> good point
<JanC> grep for CONFIG_NR_CPUS & CONFIG_HIGHMEM (I suppose, I'm no kernel dev)
<JanC> -generic is 8CPU, 4GiB RAM on feisty too
<JanC> (for x86 32-bits)
<JanC> I think the 64-bits kernels might have a different config
<EtienneG> just checked on i386, and yes, CONFIG_NR_CPUS is 8
<EtienneG> CONFIG_HIGHMEM64G is not set, downloading the -server kernel to check as we speak
<zul> server kernel has CONFIG_HIGHMEM64G if i remmber correctly
<EtienneG> yep
<JanC> the .config files are in the kernel header packages too (no need to download complete kernels)
<JanC> and maybe in the source package too
#ubuntu-kernel 2007-06-09
<chenrano2002> I can't find the related "linux-headers-2.6.20-15.generic" on 64bit ubuntu server 7.04 CD, how to install the linux header?
<kraut> moin
<jeyries> hello !
<DrFEAR> don't know if this is the channel for this...but...
<DrFEAR> I have a problem with updating my kernel...
<DrFEAR> anyone can help me?
<DrFEAR> anyone?
<JanC> DrFEAR: what problem?
<JanC> DrFEAR: remember that this is a development channel though
<JanC> for support, #ubuntu is a better choice
<DrFEAR> i'm there...
<DrFEAR> but they can't find the solution
<DrFEAR> sorry
<DrFEAR> I have Ubuntu 7.04 Feisty Fawn with kernel 2.6.20-15-generic
<DrFEAR> it says that there are updates available
<DrFEAR> when I try to update, it show an error with dependencies
<DrFEAR> i can install programs and all
<DrFEAR> but everytime i install one, it keep trying to install the same kernel
<DrFEAR> JanC: Keep trying to update to version 2.6.20-16
<geser> can you paste the error message in some pastebin?
<DrFEAR> I think that isn't necessary, so if i can't update my kernel, i'm looking a way to avoid this updating
<DrFEAR> it's in spanish...XD
<DrFEAR> it tries to install 4 packages
<DrFEAR> linux-image-2.6.20-16-generic
<DrFEAR>  linux-image-generic
<DrFEAR>  linux-restricted-modules-2.6.20-16-generic
<DrFEAR>  linux-restricted-modules-generic
<DrFEAR>  linux-generic
<DrFEAR> well 5
<DrFEAR> each one depends on the previous
<JanC> DrFEAR: how do you try to upgrade ?
<DrFEAR> I wasn't trying to upgrade, I only upgrade when the system shows me that there are new upgrades available
<DrFEAR> in that list, there was the kernel update
<DrFEAR> i thought that there wouldn't be any problems
<DrFEAR> and here i am
<JanC> and what does the error say?
<DrFEAR> dpkg: error al procesar linux-generic (--configure):
<DrFEAR>  problemas de dependencias - se deja sin configurar
<JanC> it doesn't say which dependencies are missing?
<DrFEAR> dependencies problem, left without configuring
<DrFEAR> all the packages above
<JanC> I just upgraded to 2.6.20-16.28
<JanC> without any problems
<DrFEAR> if I can't upgrade the kernel, I just want to make that upgrading stop
<JanC> maybe you must update the package database
<JanC> and then try again?
<DrFEAR> how do i do that?
<DrFEAR> with apt-get update?
<DrFEAR> I already did that
<JanC> that's one way yes
<JanC> hm
<DrFEAR> didn't work
<DrFEAR> sorry
<DrFEAR> :S
<JanC> have you tried 'apt-get dist-upgrade' ?
<DrFEAR> it tries to upgrade again...reaching the same error
<DrFEAR> what if...
<DrFEAR> I reinstall my ubuntu....:S
<DrFEAR> ?
<JanC> I'm sure there is a better solution
<DrFEAR> I could't find it
<geser> what happens when you try to install the five packages by hand with apt-get?
<geser> sudo apt-get install linux-image-2.6.20-16-generic
<geser> and so on for the other ones
<geser> one of them should produce an error which might help further
<JanC> I suspect something went wrong with an earlier install...
<JanC> or upgrade
<JanC> DrFEAR: you haven't pinned one of those packages to a certain version?
<DrFEAR> don't know
<DrFEAR> I've never touched the kernel...
<DrFEAR> I'm too newbie to do it
<DrFEAR> yet
<JanC> DrFEAR: try what geser said  :)
<DrFEAR> same thing...:S
<DrFEAR> sorry, i'll try to reinstall 
<DrFEAR> the winbugs way :S
<johanbr> DrFEAR: You really shouldn't have to reinstall for something as simple as that.
<DrFEAR> it's driving me @@
<johanbr> DrFEAR: Try "sudo dpkg --configure -a".
<DrFEAR> i'm gonna put all the error...sorry if its too long...
<DrFEAR> two lines per time
<JanC> DrFEAR: use a pastebin
<JanC> paste.ubuntu-nl.org
<DrFEAR> oh, well, I learned something new today :D
<DrFEAR> I put the link here?
<DrFEAR> http://paste.ubuntu-nl.org/24894/
<DrFEAR> like that?
<JanC> that looks like it might be useful  :)
<DrFEAR> sorry, is in spanish...
<DrFEAR> from Colombia, I'm Oscar by the way...thanks for the help :)
<JanC> I can read a little bit of Spanish  :)
<DrFEAR> lucky me! :)
<JanC> my parents worked in Venezuela for 2-3 years before I was born, a friend of them worked in Colombia for about 20-25 years, another friend of them works in Guatemala for 30 years or so, etc.  :)
<DrFEAR> many sources to learn a little bit of spanish
<DrFEAR> :S
<DrFEAR> oops
<DrFEAR> :)
<DrFEAR> i'm used to put that smiley
<JanC> seems to be a problem with 'update-grub'
<JanC> did you edit /boot/grub/menu.list by hand?
<JanC> '/boot/grub/menu.lst'
<DrFEAR> hmm
<DrFEAR> let me see
<DrFEAR> oops, yes
<JanC> it might be that if you did that, you did something wrong   :)
<DrFEAR> i have the grub like suse
<JanC> ?
<DrFEAR> a little bit more graphical
<DrFEAR> XD
<DrFEAR> but i remember what did i do...
<JanC> "graphical" shouldn't be an issue in itself
<JanC> as long as you don't change things inside the marked area for 'update-grub'
<JanC> or break the menu.lst because of bad syntax
<DrFEAR> I only added one line
<DrFEAR> gfxmenu /boot/grub/message.ubugrey
<DrFEAR> what if I remove it, reboot, and get back?
<JanC> I don't think that's the issue
<JanC> Running postinst hook script /sbin/update-grub.
<JanC> [: 25: ==: unexpected operator
<JanC> exec: 25: -a: not found
<JanC> it's something about "25"  :)
<DrFEAR> mmm
<DrFEAR> maybe it's line # 25 on update-grub?
<DrFEAR> I see a ==
<JanC> possibly
<DrFEAR> maybe it doen't found the operator -a
<DrFEAR> in the line
<DrFEAR> exec -a update-grub /usr/sbin/update-grub.real $*
<DrFEAR> what if....I remove that -a
<DrFEAR> ?
<JanC> where do you see the '==' ?
<DrFEAR> lol
<DrFEAR> another pastebin
<DrFEAR> http://paste.ubuntu-nl.org/24900/
<DrFEAR> thanks for helping, man
<DrFEAR> hope I'm not wasting your time
<JanC> btw, unrelated, but you should use sudo instead of working as root  :)
<DrFEAR> why?
<JanC> it's safer
<DrFEAR> oh, I thought that su were safer
<DrFEAR> oops
<JanC> depends on what you mean by "safer"
<JanC> with sudo it's less likely that you accidentally break your system  :)
<DrFEAR> well, that's true
<DrFEAR> right now I'm looking for deactivating root pw
<DrFEAR> to get back to sudo
<JanC> it won't fix your problem though (AFAIK)
<johanbr> DrFEAR: I know roughly what the problem is. Edit update-grub (the file you just put on pastebin) with a text editor. Put comments (#) on lines 17-21 and 23-25. 
<DrFEAR> all set
<DrFEAR> try again?
<johanbr> Alright, try the "dpkg --configure -a" again.
<JanC> johanbr: there are 2 update-grub on most systems
<johanbr> JanC: Right. And it seems like on of them is a slightly broken shell script.
<JanC> /sbin/update-grub & /usr/sbin/update-grub
<DrFEAR> same error
<DrFEAR> but changed 5 to 22
<DrFEAR> in exec: 22 : -a not found
<JanC> it seems like DrFEAR looks at an /sbin/update-grub that's different from the one I have though
<DrFEAR> oops
<JanC> DrFEAR: edit /etc/kernel-img.conf to have:
<JanC> postinst_hook = /usr/sbin/update-grub
<JanC> postrm_hook   = /usr/sbin/update-grub
<JanC> maybe that will fix things
<JanC> but I wonder how you got the wrong /sbin/update-grub script
<johanbr> JanC: My guess is that the breakage is caused by the change of the default /bin/sh shell from bash to dash. 
<JanC> johanbr: then still, why wasn't his system updated?
<johanbr> DrFEAR: JanC's suggestion sounds good. Or you can try editing line 22 of the file you just changed to just say "exec -a /usr/sbin/update-grub.real $*".
<johanbr> JanC: Oh, you mean that the update-grub script is an old version still? I don't know. Maybe he just hasn't updated the grub package yet?
<JanC> @#$%?!
<JanC> Seveas should fix his pastebin  :-(
<DrFEAR> it already says exec -a /usr/sbin/update-grub.real $*
<DrFEAR> in both of them...the one in /usr/... and the one in /sbin/...
<JanC> exec /usr/sbin/update-grub "$@"
<JanC> that's what it says here...
<johanbr> DrFEAR: Oh, sorry. I meant "exec /usr/sbin/update-grub.real $*".
<DrFEAR> ohh ok
<DrFEAR> that's what I thought
<DrFEAR> in both of them?
<JanC> ( and for some reason, pastebins hate me :-( )
<johanbr> DrFEAR: Yes. Did you try JanC's suggestion already?
<JanC> changing /etc/kernel-img.conf should be enough, I think
<DrFEAR> no, it don't say "$@", it says "$*"
<DrFEAR> i think it's the -a
<DrFEAR> wtf?
<JanC> DrFEAR: the kernel-img.conf should be changed anyway  :)
<DrFEAR> worst!
<DrFEAR> already changed
<DrFEAR> it says like a thousand times: [: 25: ==: unexpected operator
<DrFEAR> mmm
<DrFEAR> something changed: [: 25: ==: unexpected operator
<DrFEAR> no
<DrFEAR> oops
<DrFEAR> exec: 22: update-grub: Argument list too long
<johanbr> DrFEAR: Hmm. Another option: change both update-grub files back to what they were at the start, then change #!/bin/sh at the top to #!/bin/bash .
<DrFEAR> THANK YOU1
<DrFEAR> !!!!
<DrFEAR> thanks everyone for your time
<DrFEAR> thanks johanbr, thanks JanC
<DrFEAR> hoping that I didn't waste too much of your time
<johanbr> DrFEAR: You're welcome. Glad it worked. :)
<DrFEAR> :)))
<DrFEAR> thanks man
<DrFEAR> JanC: Thanks too
<DrFEAR> !
<DrFEAR> gonna rebooy
<DrFEAR> reboot
<DrFEAR> thanks, thousand thanks and blessings
<DrFEAR> good luck to everyone
<DrFEAR> bye
<JanC> DrFEAR: if the #!/bin/bash/ worked, you most likely will have more problems...
#ubuntu-kernel 2007-06-10
<jmg> is there an app for windows similar to acpi_listen?
<jmg> maybe i can snoop however windows enables my wireless...
<okaratas> hello
<kraut> moin
<jonek> hi, I have problems build the em8300 kernel module in feisty. it isn't building via module-assistant, so I tried to build my own kernel with same configuration like official 2.6.20-16-generic. after that em8300-modules is building but complains about "em8300: Unknown symbol i2c_bit_del_bus". which option in the kernel do I have to enable for this?
#ubuntu-kernel 2008-06-02
<emgent> morning
<osmosis> from a kernel driver perspective, what is the preferred RAID card vendor?
<pwnguin> osmosis: ive heard many people suggest software RAID
<pwnguin> but I also don't use raid (I should change that)
<amitk> osmosis: 3ware has always had good support for linux
<amitk> osmosis: http://linas.org/linux/raid.html for other vendors and specific model details
<alex_joni> osmosis: my personal oppinion is that software RAID is sometimes easier to recover
<alex_joni> if your card has problems, it's not possible to recover the RAID on another machine, unless it's a compatible one
<alex_joni> and software RAID doesn't have that much performance loss to be an issue
<tjaalton> should I blame the kernel for not being able to resume from hibernation? Worked fine before enabling -proposed
<tjaalton> hangs after the message "Suspending the terminal(s)"
<newz2000> when running virtualbox 1.6 my computer freezes up and the caps lock key blinks. Is there a way I can get any diagnostic information so I can file a bug report with the vendor?
<rtg__> soren: ^^
<soren> newz2000: Do you have vmware installed, too?
<soren> by any chance?
<newz2000> no
<soren> Hm... Kvm, then?
<newz2000> yes
<soren> Ah.
<soren> That's likely your problem.
<newz2000> :-( I can't use them both? Oh bummer.
<soren> Not at the same time.
<soren> Try unloading the kvm modules (sudo /etc/init.d/kvm stop) and try again.
<newz2000> ok, I have to wait until I have finished my current work because I can't handle a hard lock at the moment
<newz2000> this is a new problem with virtualbox 1.6 (1.5 worked fine)
<soren> The various modules who use the virtualisation extensions in the CPU's have not agreen on a locking mechanism yet, and things go boom if more than one thing tries to use them at the same time.
<soren> newz2000: Well, it's a *possible* cause. It might be something completely different.
<newz2000> ok, I'll test after a bit
<dupondje> https://bugs.launchpad.net/ubuntu/+bug/235889 plz check :)
<ceekay> anyone able to clue me in / point me to docs regarding kernel crash dumps at present and possibly where they were as of 7.04? I see it was accepted for hardy on https://blueprints.launchpad.net/ubuntu/+spec/linux-kernel-crash-dump , but the status does not seem to indicate that it was completed
<jepler> ceekay: I'd also love to know more about this
<emgent> heya
<rtg__> Ng: saw your comment about e1000 EEPROM. Can you reproduce the problem reliably so that if I apply a patch you can tell that I fixed something?
<Ng> rtg__: the machine in particular showing the problem is silbs' laptop, so while we do have a reliable testcase, we probably shouldn't interrupt her too much ;)
<rtg__> Ng: well, if you'll work with her as she has time, I'll apply the patch in my PPA version.  I'll get it done later this evening since she's already left.
<Ng> rtg__: ok, I can probably get on it during lunch or so
<rtg__> Ng: ok, I'll add a comment to the bug report when its ready. I'm out for a bit...
<ceekay> jepler: from what i've seen BenC 's footprints seem to show up in a few places (that link above as well as the grub changelog mentioning something about "we're no longer using kdump kernels") so i suspect he might have an understanding of what's going on/where things have been
<BenC> No, we're still using kdump kernels
<BenC> just that we are using a different method of loading them that the old menu.lst grub thing I had originally
<ceekay> BenC: any documentation out there that i could use to see where things are/were?
#ubuntu-kernel 2008-06-03
<greearb> I have what may be a squashfs bug in ubuntu 8.0.4:  I am building a custom image, and when I view certain files inside of the chroot, everything looks fine.
<greearb> But, when I make a squashfs and iso image, and then mount that with -o loop, certain files in squashfs image give IO errors when I try to read them.
<greearb> I am not sure this is anything other than bad luck, but the files are: /var/lib/scrollkeeper/TOC/16544 - 1651
<greearb> I have not found any others, but it's possible they exist.
<greearb> I'm open to suggestions if anyone has any ideas on how to further debug this
<newz2000> ok, confirmed. `/etc/init.d/kvm stop` did allow virtualbox to run
<newz2000> thanks for the help
<elmargol> Someone knows how I get the virtualbox 1.6 module running on the current ubuntu version
<rtg__> Ng: http://ppa.launchpad.net/timg-tpi/ubuntu has the e1000 eeprom patch.
<Ng> rtg__: thanks
<emgent> heya
<Riddell> linux-image-2.6.25-1-386, main or universe?
<BenC> amitk, rtg__, cking, pgraner: ping
<cking> Hi
<BenC> Riddell: universe
<BenC> Riddell: all other packages from linux-ports are main
<rtg__> BenC: pong
<pgraner> BenC: pong
<amitk> BenC: pong
<BenC> Ok, the ubuntu-kernel-team meeting is now in session
<BenC> No real agenda is in order, but just to update on the status for intrepid...
<BenC> linux-ports => New package, uploaded and built already. This package contains all the architectures/flavours that are community supported
<BenC> This basically means != i386/amd64
<BenC> With the exception of the -386 flavour, which is mostly kept for things LTSP
<BenC> *like LTSP
<BenC> It's 2.6.25 based, and will probably remain that way for intrepid
<BenC> The community port teams are expected to maintain proper configs and patches in that package
<amitk> BenC: I recall Oliver (ogra) mentioning that LTSP used -generic now. rtg__ do you remember?
<rtg__> amitk: yep - all default installs use generic.
<BenC> amitk: some of the older hardware uses -386, but it's an option, not the default
<BenC> There are some LTSP boxes that fit in the palm of your hand, which use the -386 kernel (at $100 a box, they are economical)
<amitk> ok
<BenC> atleast I remember being told that, hehe
<BenC> ï»¿Next, we have some UDS topics that will affect the kernel maint infrastructure...
<rtg__> ogra said that there are no modern LTSP devices that _require_ -386.
<BenC> linux-ubuntu-modules is moving to the main linux source tree (in our git, not upstream)
<BenC> This will be done by placing the third party modules in an ubuntu/ subdirectory, and should alleviate problems we've had with separate ABI/headers for third party modules
<BenC> (e.g. alsa)
<BenC> This is the same way we did things prior to feisty
<BenC> linux-backports-modules will remain the same
<BenC> linux-restricted-modules will get a huge face lift. First, fglrx and nvidia will be moved to DKMS packaging, to remove the need to update them on ABI bumps (recompiles of the kernel module will happen on the local machine)
<BenC> Next, we'll ditch a lot of old drivers that are unused, and we'll perform the usual driver refresh...linux-restricted-modules will then be converted to use the same build infrastructure as lbm/lum/linux
<rtg__> You can read the UDS discussion results at https://wiki.ubuntu.com/KernelTeam/UDS/May2008. I should have published this awhile ago.
<BenC> lbm and lrm will only support the main architectures (x86/x86_64)...port maintainers should create their own infrastructure for third-part/restricted modules
<BenC> Considering that most hardware related to the ports are supported in the kernel, I don't see this being a problem
<BenC> The only exception being aufs, which ports will need if they want a livecd for their architecture
<BenC> The other major change, is that what we used to have as binary-custom in-tree builds (xen/rt) will be moved to external packages, which will build-dep and patch linux-source-2.6.xx to build their respective binaries
<BenC> The same will happen to -virtual
<BenC> rtg__: Thanks, that should fill in some gaps for questions
<BenC> So, that leaves i386=>generic,server and amd64=>generic,server as the only things left in the main kernel tree
<BenC> We are hoping that narrowing our scope will improve our focus and quality on supported architectures
<BenC> Any questions?
<BenC> Anything anyone wants to add to the discussion?
<BenC> Meeting adjourned then :)
<maks_> i'd have 2 points
<BenC> maks_: Ok, just in time...whatcha got?
<maks_> 1) the SAUCE patches, i guess those are on the way to upstream?
<rtg__> maks_: most of them.
<BenC> maks_: Actually, some are pushed upstream, and others will never be accepted
<BenC> and some are in progress...SAUCE will be a never ending endeavor
<maks_> 2) initramfs-tools sync
<maks_> as sauce is rebased should be easy to submit the blacklist ones
<BenC> maks_: the initramfs-tools sync should be done as part of our normal merge-o-matic from Debian
<BenC> maks_: but I'll be sure to give it personal attention :)
<BenC> maks_: Is there anything we have locally in ubuntu that isn't merged in Debian?
<maks_> yep
<BenC> Do you know what they are off-hand?
<maks_> 1sec
<maks_> firmware detection differs
<maks_> mountroot fail hooks
<maks_> loop support
<BenC> maks_: meaning we have loop support and debian doesn't?
<maks_> old ps3 support
<maks_> the old ps3 stuff that didn't go into linux-2.6
<maks_> BenC: yes
<BenC> right, but we released ps3 support, so we need to maintain that backwards compatibility
<maks_> sure but not in hardy irc
<BenC> we can probably ditch it in intrepid
<maks_> trigger support landed
<BenC> gutsy was first release with old driver names, hardy maintained for upgrades, and intrepid can ditch them
<maks_> MODULES=dep got /sys walking logic in debina
<maks_> plus bunch of nfs root fixes
<BenC> nice
<BenC> maks_: Ok, I'll personally review the initramfs-tools sync
<maks_> ok cool
<maks_> Luke was helping out for merging bits and pieces
<maks_> but seemed silent lately
<maks_> once sync happen i'll see what i can do on my side to reduce too
<BenC> Sure thing....ok, so _now_ meeting is adjourned
<maks_> :)
<maks_> cya
<BenC> Thanks everyone
<BenC> maks_: thanks
<infinity> rtg__, BenC : I just read scrollback, and when Ogra said "we use -generic by default and I get no complaints", he and I later discussed that further and, yes, the 386 kernel flavor is still required, even if not the default.
<infinity> rtg__: I meant to catch up with you that same day in Prague (when we also did the 486/586 toolchain discussion), but didn't get around to it. :)
<rtg__> infinity: there are LTSP devices that are not i586 or better?
<infinity> rtg__: There's no such thing as an "LTSP device" but, yes, plenty of people are running LTSP on 486-class hardware still.
<rtg__> infinity: do you think the community port for -386 is sufficient for those users?
<infinity> rtg__: We have two distinct (and very different) target markets for LTSP installations.  The corporate thin-client users are all on reasonably new and speedy hardware (and they'll also be keen on us finally having ARM support), and then the "poor schools and communities recylcing hardware as terminals" have a lot of older kit lying around.
<infinity> rtg__: If -386 moves to linux-ports, that should be fine.  It just shouldn't go away entirely.
<rtg__> infinity: ok, then I think we're fine. We did not plan to remove -386, only move it.
<infinity> rtg__: Kay.  In Prague, it sounded more like outright removal.  Not like adding it back would be hard, but... Best not to remove it in the first place. :)
<rtg__> infinity: to be honest, it was my original intention to remove it. I quickly changed my mind :)
<esox> Hi, when one compiles a vanilla kernel do one need to apply patches ? I eared about ubuntu patches
<rtg__> esox: start here: https://wiki.ubuntu.com/KernelMaintenance
<esox> rtg__: is this how to compile vanilla kernels ? because I want to build a 2.6.25-rt kernel... I did it but no wifi, no alsa, and gdm start issues
<esox> the systems starts but with those issues
<rtg__> esox: that page describes how to build the Ubuntu kernel. For other stuff you're on your own.
<esox> rtg__: ok... so you dont know if there are ubuntu patches available somwhere ?
<rtg__> esox: there are no patches for 2.6.25, but there are a number in the Ubuntu kernel git repository for 2.6.24.
<esox> rtg__: cool, thanks
<esox> I go for that
<maks_> esox: start from a working .config
<esox> maks_: you mean re-build a 2.6.22-rt as a beginning ?
<maks_> no
<maks_> you probably goffed on .config settings thus go from a working /boot/config-2.6.24-whatever
<esox> maks_: I'm on gutsy ubuntustudio, so it's 2.6.22 and that version
<maks_> a lot happened since, anyway good luck
<esox> maks_: well i have too many issues with 8.04...
<rtg__> BenC: did you want that mmc fix in Hardy before I upload?
<Bari_> anyone have any idea why a 2.6.22.2 kernel may have problems initializing and assigning irq's to VIA USB controllers? irq's get assigned and the get disabled since "nobody cared"   cat /proc/interrupts show  10:     100000    XT-PIC-XT        uhci_hcd:usb3, uhci_hcd:usb4   11:     100000    XT-PIC-XT        uhci_hcd:usb1, uhci_hcd:usb2   seconds after booting,  serial debug output: http://pastebin.com/m3320b15f
<BenC> rtg__: does it apply to hardy? If so, yes
<rtg__> BenC: already done and pushed.
#ubuntu-kernel 2008-06-04
<wd4lko> how can i get kernel 2.6.24-18 in intrepid ?
<infinity> wd4lko: Add hardy-updates to your sources.list
<infinity> wd4lko: Or hardy-security.  Or both. :)
<wd4lko> thanks ill give it a try
<fran1> hello
<fran1> I need report bug
<fran1> form kernel
<fran1> help
<doko> rtg__: please could you have a look at #230315?
<rtg__> doko: in a bit. gotta finish the kernel upload for -19.33
<doko> thanks, no haste
<rtg__> doko: I'm going to refer #230315 to BenC. He likely knows the solution off the top of his head.
<BenC> bug #230315
<BenC> hmm
 * BenC reverts to manual
<BenC> doko, rtg__: My first guess is that SIGTRAP has to be handled a certain way in the program, and that become more strict in newer kernels, and the guy is just not adhering to that usage correctly
<BenC> but that's my gut feeling
<doko> BenC: see the debian report, drow assumes a kernel problem (which apparently is gone away in .25)
<tjaalton> how do I debug a problem with resuming from hibernation? it fails with -17, still works with -16. the machine hangs after the message "Suspending console(s)"
<BenC> doko, rtg__: Well, I can't reproduce the bug in 2.6.26-rc4, so must have gotten fixed
<BenC> rtg__: Might want to check 2.6.24.y to see if there's something there
<BenC> err, well, I'm on 64-bit too, some that might skew the results...someone should test 32-bit 2.6.26-rc4
<rtg__> BenC: feel free. I'm busy :)
<tjaalton> ok, the resume bug is triaged already
<tjaalton> and fix committed, yay :)
<rtg__> tjaalton: do you have anything on deck for LRM? Otherwise I'll just upload the ABI bump as soon as the -19 kernel is ACCEPTED.
<tjaalton> rtg__: nope, nothing. go ahead
<rtg__> tjaalton: thanks, will do.
<holst> I am looking for a way to use the pfmon package 
<holst> in hardy 8.04 i386
<holst> it says now: host kernel does not have perfmon support
<holst> is this because its lacking a kernel module?
<Ng> rtg__: hey, did you get a chance to build that kernel for silbs?
<rtg__> Ng: its still building. you can watch http://ppa.launchpad.net/timg-tpi/ubuntu
<Ng> ok, thanks
<rtg__> Ng: I'll refresh the other packages after the kernel is build so there is no ABI skew.
<alex_joni> was colin around lately?
<rtg__> alex_joni: colin king?
<alex_joni> rtg__: watson
<rtg__> alex_joni: dunno. he was out early yesterday.
<alex_joni> rtg__: ok, thanks
<Ng> rtg__: there's no rush, silbs has left the building, I was just wondering if it had managed to build already and we could sneak a cheeky install in tonight
<alex_joni> rtg__: it's cjwatson .. right?
<rtg__> alex_joni: yes
<rtg__> Ng: make the PPA buildds faster.
<alex_joni> anyone else familiar with d-i ?
<rtg__> alex_joni: evand
<alex_joni> rtg__: oh, cool
<Ng> rtg__: not within my powers :)
<alex_joni> evand: ping ;)
<evand> alex_joni: pong
<pwnguin> is there a special trick to debugging a system freeze by serial port?
<pwnguin> ive got a bug report where someone plugs in a wacom tablet and the system "freezes"
<alex_joni> pwnguin: you probably want kgdb 
<pwnguin> hmm; when I say "I've got a bug report" i really mean there IS a report
<pwnguin> not one I can duplicate
<pwnguin> bug #230541
<pwnguin> apparently our faithful bot no longer provides urls or summaries =(
<pwnguin> alex_joni: assuming the reporter is capable of such a set up, which package is kgdb in?
<alex_joni> pwnguin: google might know.. I never used it
<VB-DotNet> hello my friends
<neofax> Is the UDF 2.50 kernel patch included in 2.6.24-18?
#ubuntu-kernel 2008-06-05
<lamont> what piece where creates /var/run/reboot-required?
<lamont> on kernel install, that is
<rtg__> lamont: not sure. update-manager?
<lamont`> rtg__: dunno... I just know that my ia64 box doesn't get it touched...
<rtg__> lamont: sounds like a Scott remnant question.
<lamont__> kewl
<lamont> stupid nick
<bullgard4> Are the /etc/default* files even relevant any more considering the use of upstart?
<stgraber> hi there, I just installed 2.6.24-19 (taken from LP as the meta is stuck in new) and my mouse acceleration and scrolling speed are really weird
<stgraber> I no longer have smooth scrolling and mouse seems slower than usually (that's what I feel at least)
<rtg__> lamont: I just install kernel/lum/lrm/lbm using apt-get and now the upgrade manager is bugging me to restart, so it must be something in the kernel package that sets the hook.
<lamont> rtg__: that was what I thought... and ia64 seems to be lacking that fix.
<lamont> s/fix/change/
<rtg__> lamont: I wonder why its special. 
<lamont> rtg__: short bus. obviously.
<rtg__> lamont: does /usr/share/update-notifier/notify-reboot-required exist as an executable?
<lamont> rtg__: well, then.  that would explain it.
<rtg__> lamont: in the git source its in ubuntu-hardy/debian/control-scripts/postinst , look for notifier. 
<lamont> rtg__: next kernel upload (intrepid certainly, and for hardy-updates maybe?) could you make the *FS_XATTR flags for hppa match x86?
<lamont> and would you like a bug to that effect in launchpad?
<rtg__> lamont: yeah, Martin pretty much requires it for any SRU updates.
<lamont> ok
<rtg__> lamont: you could also attach a patch.
<lamont> meh
<lamont> that would mean fetching source and wearing my dev hat for longer than I want to today :-(
<rtg__> lamont: whiner.
<lamont> I might make a patch for it later today
<rtg__> there is just the 4, right? CONFIG_CIFS_XATTR, CONFIG_EXT2_FS_XATTR, CONFIG_EXT3_FS_XATTR, CONFIG_REISERFS_FS_XATTR.
<rtg__> ignore CONFIG_CIFS_XATTR
<lamont> x86 has JFFS2_FS_XATTR as well... but yeah, just the 4
<lamont> ls -l kinda bitches when it doesn't agree about that setting...
<rtg__> lamont: ok, you make the SRU report and I'll do the patch.
<lamont> SRU justification: "meh. it's hppa."
<lamont> martin == pitti, yes?
<rtg__> lamont: yes, martin == pitti
<lamont> cool
<lamont> rtg__: having learned more about the issue, I'm less certain I care enough to fix hardy, although it seems like a useful thing to allow people to use, eh?
<lamont> fixing /bin/ls to not whine about the syscall returning EOPNOTSUP is certainly more correct (it's a legal return value, why are you whining ls??)
<rtg__> lamont: well, what are extended attributes? security stuff?
<lamont> rtg__: you ask that like I might know... :0)
<infinity> lamont: Fixing hardy's kernel would be nice, especially if there's an SRU or security update queued "soon" anyway.
<lamont> infinity++
<lamont> whatever extended attributes are
<rtg__> infinity: is there any reason that all the arches shouldn't have the same XATTR settings?
<lamont> I mean, hell, even ia64 gets them.. :-)
<infinity> rtg__: I see no reason why they shouldn't all be in sync in that regard.
<lamont> I believe they should all be the same
<rtg__> ok, simple enough.
<infinity> rtg__: Honestly, configs for all arches should be nearly identical for everything that isn't pure hardware support.
<lamont> I would be completely surprised if they were arch-specific
<infinity> rtg__: This is, I fear, a problem that will be compounded by the ports/non-ports package split, but time will tell.
<lamont> infinity: don't say that where hppa can here you... I brutalized that config quite sometime go
<lamont> ago
<rtg__> infinity: agreed.  I don't know how they drifted. I probably inherited it from Gutsy and never noticed.
<lamont> rtg__: so I assume you'd still like a bug and me to poke pitti?
<rtg__> lamont: just file the bug and poke me (since I get to make it happen)
<lamont> cool
<infinity> rtg__: Do we have a pending kernel update soonish, or should we roll our own fixed kernels for now?
<lamont> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/237699
<rtg__> infinity: I just uploaded -19 last night, so there isn't likely to be another before the point release unless there are regressions.
<lamont> rtg__: fwiw, it's buildd-affecting :(  so we're happy to test a kernel for you...
<infinity> rtg__: Damn, our timing sucks.
<rtg__> infinity: some thing like this is a pretty minor update. I don't have a problem with it.
<lamont> meanwhile, I'll see about the "fix ls" approach
<rtg__> infinity: I just have to get it by slangasek.
<lamont> tell him you polled the entire known hppa/ubuntu user community, and they said "please"
<infinity> lamont: While I'll agree that coreutils is "wrong" in this case, I still want a kernel that matches the rest of the architectures.  We should at least NMU this to hardy-cat for now, until a fixed version hits -updates/-security
<lamont> infinity: yeah
<infinity> lamont: You want me to work up the patch and build it in -cat, or will you?
<lamont> infinity: happy to let you do it if you want...
<lamont> kernel muckery is requiring more and more bandwidth
<infinity> Bandwidth is something I have plenty of now that I don't live in Australia.
<lamont> I live in that small part of australia that is in colorado. :(
<infinity> Brainpower, on the other hand, requires waking up.
<lamont> go for the expresso.  who needs water diluting the caffeine?
<infinity> I was thinking I'd just go for the fruit juice approach.
<lamont> OMFG.  coreutils is dbs???
<infinity> There are still DBS packages?
<lamont> _essential_ dbs packages
<infinity> Whacky.
<infinity> I used to maintain a few, until public pressure forced me to change to dpatch.
<lamont> hrm... I guess I can ask myself to install builddeps in the chroot, eh>?
<infinity> Heh.
<lamont> lamont: done.
<lamont> :-)
<Kano> hi, when will be intrepid kenrel update to rc5?
<rtg__> Kano: sometime in the next few days I imagine. BenC has been handling it.
<Kano> ok
 * BenC starts the lum->linux merge
<rtg__> BenC: are still creating the zinc accounts? I have a request from Mario for one.
<munckfish> For those who are interested - tonight I will be building/patching testing the intrepid-ports kernel for PS3.
<zul> that reminds me is the custom flavour git repo ready yet?
<infinity> rtg__: Oh, I didn't realise that -19.33 was only in -proposed, not yet in -updates.  Perhaps there'd still be time to squeeze in the hppa fix, then? :)
<rtg__> infinity: possibly. I have 7 days before it gets moved.
<mkrufky> who should i talk to about packaging kernel modules directly for ubuntu bypassing upstream?
<mkrufky> (for a canonical partner)
<rtg__> mkrufky: me or BenC
<mkrufky> ok... do you have a few minutes now?
<mkrufky> the code i plan to sumbit is not ready, but i have a build system solution .....  i am not using DKMS, but i have good reason not to
<rtg__> mkrufky: I'll answer if I can.
<mkrufky> i just want to run it by u guys to make sure its OK before i lose time depending on it
<mkrufky> ok.... so, this is for two new digital television devices
<rtg__> this is something you want in LUM ?
<mkrufky> i am adding new modules, and i am NOT replacing any preexisting modules
<mkrufky> yes, i believe that lum is the right place for it
<mkrufky> i believe that we're targetting 8.04.2
<mkrufky> basically, i have a build system that allows me to patch linuxtv.org hg tree *and* produce backports to recent kernels without patch conflicts
<rtg__> mkrufky: adding new drivers that have no possibility for regression are fairly easy. Why not DKMS, though?
<mkrufky> not DKMS, because i need to develop *within* the linuxtv.org devel repositories, so this method allows me to build against l-u-m headers instead of local headers
<mkrufky> im sure that there is a WAY to make it work in DKMS, but the solution i have not is working perfectly
<mkrufky> if its not broken, dont fix it :-P
<mkrufky> ...also, i have a deadline
<rtg__> ok, so you want to submit a patch to the kernel team mailing list? Or a pull request?
<mkrufky> er,TYPO
<mkrufky> sorry... i meant, the solution i have not is working perfectly
<mkrufky> oops again .. .noW workingperfectly
<mkrufky> if it's simply a matter of patch submission, then that's fine
<rtg__> mkrufky: thats OK for Hardy, but we're still trying to decide what to do for Intrepid wrt the myriad of third party modules. DKMS is definitely getting some attention.
<mkrufky> however....  im not sure if there are advantages to submit OUTside of l-u-m or not
<mkrufky> i fully agree that DKMS is the way of the future
<rtg__> mkrufky: if your driver is in LUM, then you are stuck with my release schedule.
<mkrufky> this particular project is slated for 8.04.2 (i think) and intrepid is not on the table.  these new modules will already be upstream for intrepid
<mkrufky> ah, ok ... so maybe best to build outside of LUM
<mdomsch> mkrufky, a) I can help with DKMS if you need
<rtg__> mkrufky: it just depends on how frequent you expect updates to be. I'm throttled by the 7 day -proposed delay.
<mdomsch> mkrufky, b) why bypass upstream?  upstream first!
<mkrufky> chill :-)
<mkrufky> i always go to upstream first -- this is for a retail project
<infinity> lamont: Is there any reason why config.hppa32 has EXT{2,3} as modules, but config.hppa64 links them statically?
<lamont> hppa64 is the config that I was gutting like a trout trying to figure out why it hated life.
<mkrufky> just that the device being sold will have 8.04.y pre-installed on it, thats why i have to backport to hardy
<lamont> it was left (a) somewhat gutted, and (b) rather hating life still
<infinity> lamont: Err, kay.  So, I should perhaps just ignore it and fix hppa32? :/
<lamont> infinity: in the end, a working hppa32 just gets told to be hppa64 in the arch-specific section, and there is love.
<infinity> lamont: I was going to move the EXT configs back to hppa/config, and remove the arch-specific configs for the filesystems.
<lamont> pretty much any driver you can need on hppa64 can be found needful on hppa32, and vice versa
<rtg__> mkrufky: so not necessarily a device that can host a DKMS rebuild?
<lamont> (well, that's technically a bit wrong, but feh)
<mkrufky> rtg__: i understand that question
<infinity> lamont: Kay.. Well, I'll just fix hppa32 for now, then.
<infinity> lamont: Since that's what we're running anyway.
<mkrufky> yikes, typos -- i *dont* understand that question, rtg__
<lamont> infinity: for that matter, feel free to throw everything from hppa32->hppa and just breakout the PA1.1 vs PA2.0 diff for hppa{32,64}
<rtg__> mkrufky: DKMS requires the ability to rebuild modules when the kernel ABI changes. 
<mkrufky> i will submit source code, it will totally be rebuildable
<rtg__> mkrufky: that implies a compiler, usually spinning media, etc.
<infinity> lamont: That's slightly too big a change for me to be comfy with for hardy. :)
<infinity> lamont: For intrepid, sure.
<lamont> right
<rtg__> mkrufky: I understand it will be open source, but do you want to be rebuilding the module on your commercial target machine?
<mkrufky> rtg__: i'll qualify the scenario --  a large OEM will be selling a tiny laptop with ubuntu on it, that oem will be packaging two of my digital tv sticks, canonical agreed to host the additional modules
<mkrufky> nah, the consumer must not build the modules
<mkrufky> the consumer will simply install the new module package with the driver support
<rtg__> mkrufky: ok, then DKMS is probably not the right way to go.
<rtg__> mkrufky: how about hosting your driver in your PPA and preseeding the commercial unit to pull from that PPA?
<mkrufky> PPA ?
<rtg__> mkrufky: personal package archive, it works very similar to the main Ubuntu archive.
<mkrufky> it will be hosted on canonicalpartners.com
<tseliot> ï»¿mkrufky: PPA is a personal repository hosted by launchpad
<mkrufky> er, i might have that domain wrong, but you know what i am refering to
<rtg__> mkrufky: the PPA is hosted somewhere in launchpad.net
<pwnguin> when you say "must not rebuild modules"
<pwnguin> is that "not be required, or not allowed"
<mkrufky> pwnguin: was that question to me?
<pwnguin> mkrufky: sorry, yes
<tseliot> ï»¿mkrufky: if you don't use DKMS you will have to make sure that the packages are rebuilt and uploaded every time the kernel ABI is broken
<mkrufky> pwnguin: users must not be required to rebuild the modules themselves ...  of course, they are allowed
<pwnguin> okies
<pwnguin> you'd be surprised ;)
<mkrufky> i believe in open source :-)
<mkrufky> anybody that doesnt should suffer bitrot :-P
<rtg__> mkrufky: DKMS would not require any intervention on the part of the user. The modules gets rebuilt automatically when the ABI changes.
<tseliot> ï»¿mkrufky: with DKMS, if you have the compiler and the kernel headers installed, the kernel module will be automatically rebuilt without user intervention
<mkrufky> so....   basically, if i want to be able to sumbit code to you guys once (assuming i dont need to provide updates) then all i need to do is port my system to DKMS and then you'll rebuild whenever needed?
<mdomsch> no
<mdomsch> the rebuilds happen on the end user's computer
<mkrufky> oooh... so with DKMS, users still have to build locally
<mdomsch> (whcih may be undesirable)
<mkrufky> hmm
<tseliot> ï»¿mkrufky: there's a script which does that automatically. There's no need to reupload anything
<mdomsch> they don't have to - one _could_ set up the build system to build it
<mkrufky> this particular product does not have disk space to allow such kernel builds
<mkrufky> ie:  the OEM does *not* want users to have kernel headers on the machine
<mkrufky> ok... in summary, it sounds like i should do LUM and let that be the end of it
<rtg__> mkrufky: I think you should first investigate PPA and see if it will work for you.
<mkrufky> LUM == i send in a patch or a pull request from my git tree, you guys rebuild on your release schedule
<mkrufky> PPA sounds like it will require that I constantly rebuild when the ABI breaks -- is that true?
<rtg__> mkrufky: yep, LUM will be less responsive.
<rtg__> mkrufky: the ABI won't change more then a few more time, perhaps 4 in the next 2 years.
<mkrufky> eek
<rtg__> mkrufky: its the network security updates that usually cause it.
<mkrufky> i have a deadline to provide code to ubuntu by june20th for imaging, and im under the impression that i'll have two or three update drops after that within the next two months or so
<infinity> rtg__: It's been a while since I've done this.  Do I need to do something to tell the kernel package that "Yes, I know this is the same ABI as the previous upload and no, you don't have ABI files yet, shut up," or does it handle that gracefully now?
<rtg__> infinity: you on -19? I updated the ABI files but I haven't pushed yet.
<infinity> rtg__: I'm just patching -19.33 to suit our needs in the DC for now, yes.
<rtg__> infinity: you can touch debian/abi/*/ignore to _not_ fo the ABI check.
<rtg__> mkrufky: you really need to get code to me earlier then the 20th. Things are starting to freeze right now for an extended test period.
<mkrufky> i can give you code today, but the USB ids are all going to change
<mkrufky> is it easier to do that, and give you a tiny patch later?
<pwnguin> whos usb ids are you using right now?
<rtg__> mkrufky: yeah, that works. I can update LUM easier then the kernel 'cause it won't cause an ABI bump.
<mkrufky> pwnguin: they
<mkrufky> pwnguin: they're all my companie's IDS
<mkrufky> but... this driver is for our CURRENT product
<mkrufky> the new ids are for the actual product, which will have branding on it specific to the OEM
<pwnguin> mkrufky: ok then. just as long as you dont clobber someone else's :)
<mkrufky> nah ... when i give the vid:pid update, i'll be ADDING ids, not changing any
<mkrufky> this driver is already in 2.6.26, but i backported it to 2.6.24 for hardy
<rtg__> ok gents - lunch is calling me. back in awhile.
<pwnguin> I've got a bug filed against wacom-tools that I think is a kernel bug
<pwnguin> what do I do to hand it off / get the right people looking at it?
<mkrufky> heh, a co-worker just told me he added some power management stuff.....   so i have to test this for a day or two before i submit
<mkrufky> rtg__: OK if I send in a patch early next week, instead or today?
<mkrufky> ...and ur eating lunch ....  thanks for the help everybody :-)
<munckfish> Is the AUTOBUILD variable actually still used?
<munckfish> I note that in the hardy kernel sources it's using old/wrong way to get git HEAD id hash (cat .git/HEAD)
<infinity> rtg__: Building a test kernel now, BTW.  If this goes smoothly, I'll pass the patch on to you.
<infinity> rtg__: Cause I'm sure you prefer tested hppa patches to untested ones that require several uploads, using slow buildds as a test platform. :)
<rtg__> infinity: you are so right :)
<rtg__> munckfish: AUTOBUILD might be fubared.
<munckfish> rtg__: I guessed as much
<infinity> rtg__: Given that -19- is only in -proposed, I assume that even if this constitutes an ABI horizon, we can fudge that for hppa?
<infinity> rtg__: (And it almost certainly will be an ABI change on hppa64, since I fixed the static/module ext setup there...)
<rtg__> infinity: last time I looked hppa hadn't even built yet for -19. For an update I can just create abi/*/hppa/ignore so it bypasses the ABI check.
<rtg__> infinity: nope, still needs building. I could ask that it not be NEWED if it does build anytime soon.
<infinity> rtg__: Hrm, good point.  I'll queue it way down so it doesn't build at all.
<infinity> (Or, not for a very, very long time...
<infinity> )
<infinity> Or I could queue it up and fail it intentionally.  That might be easier.
<infinity> (LP really needs a way for me to just make a build not happen)
<rtg__> infinity: thats fine with me. I definitely do not want to roll the ABI again before 8.04.1 is in the can.
<Ng> is there a good way to do a custom build of LUM wrt the version number? altering it seems to break the build somewhat (in that it looks for matching headers packages)
<rtg__> Ng: mess with debian/changelog  ? The do a clean to regen the control info.
<rtg__> *Then do a clean...
<Ng> mmkay, I'll give that a shot. so far I've just been twiddling the version number in changelog to try and find a mutation which doesn't break everything else
<Ng> I'm probably doing this in completely the wrong way just to get newer alsa modules ;)
<rtg__> Ng: oh, good luck. You messing with 1.0.17rc1 ?
<Ng> nightly \o/
<Ng> I didn't realise there was a .17rc yet, I should try that out and see if it works
<rtg__> Ng: ALSA was a major pain in the ass to package.
<Ng> rtg__: I seem to have figured out about 3 steps to replace the one in LUM with a random nightly, but then this package only has to work on one piece of hardware ;)
<lifeless> https://bugs.launchpad.net/bugs/99755 - mario from Dell thinks there is a patch for the suspend problem affecting dell D430 & D630's
<lifeless> can anyone comment on whether the patch is good/missing/etc?
<rtg__> lifeless: that patch made it into -19 via another bug report (can't remember which one)
<lifeless> rtg__: intrepid build right? can I just grab that and lum and drop on hardy?
<rtg__> lifeless: hardy 2.6.24-19
<lifeless> oh cool
<rtg__> in -proposed
<lifeless> I will give it a spin in the weekend all going well
<lifeless> (unless you warn me off :))
<rtg__> lifeless:  it went in because of Bug: #183033
<rtg__> which is likely a duplicate of 99755
<lifeless> different symptoms but yeah I can see that
<rtg__> lifeless: memory corruption can exhibit an infinite number of symptoms.
<rtg__> i think its the same root cause in this case.
<rtg__> tomorrow is another day. later...
#ubuntu-kernel 2008-06-06
<luca_> hy everybody !
<luca_> im' intrested in implementing a file-system changes notification tool
<luca_> i am wondering if is possible to get journaling event from my module
<luca_> are there particular kernel structures involved with the journaling system ?
<BenC> luca_: fs/jfs/ might give some useful info
<luca_> thank you BenC
<luca_> are there anything under /proc or /sys that will let me know if some change in the filesystem occurs?
<mjg59> No
<luca_> sorry I got lost in fs/jfs
<mjg59> If you're purely interested at the filesystem level, inotify will give you notifications
<mjg59> But I suspect it won't work too well if you try to look at the whole filesystem
<pwnguin> that would be pretty crazy
<pwnguin> and god help you if that notification framework ended up causing writes to the filesystem
<mjg59> If you're interested in things at the block level rather than the filesystem level, check block/blk-core.c and search for block_dump. fs-writeback.c has similar code that gives notifications if a page is dirtied.
<luca_> Is it possible (kernel or user space) to read directly that table the journaling fill with envents occurred to file?  
<luca_> read it , and understand what happened?
<mjg59> Well, sure
<mjg59> But ext3 only journals metadata by defau;t
<mjg59> File data changes won't go anywhere near the journal
<luca_> mmm.   right
<luca_> do you know more or less how does this happens:
<luca_> i open a directory with a gui as nautilus
<luca_> i create a file from a shell into that directory
<luca_> and magically nautilus know that a file was created
<luca_> and show the file icon almost immedately
<mjg59> It uses inotify
<luca_> thanks mjg59
<CjNr14> does someone know if there is a way to export a memory area from the host to the guest (Video RAM/ROM for exemple) ?
<CjNr14> Do I need to write a driver like the pci frontend/backend one?
<CjNr14> sorry, wrong chan lol
<rtg__> Ng: talk to me. any e1000 joy?
<Ng> rtg__: not as yet, I don't see silbs around atm, but I'll keep my eye open.
<rtg__> Ng: k
<Ng> I might even keep both eyes open ;)
<Nafallo> hehe
<munckfish> oh depressing. Recompiling the 2.6.25 kernel is taking 2 hrs 20 mins on my PS3 (weeps).
<munckfish> and that's with ccache
 * munckfish eyes G5s on Ebay, wonders what wife would think ...
<dupondje> https://bugs.launchpad.net/ubuntu/+bug/235889
<dupondje> somebody can take a look ? :)
<mkrufky> dupondje: Leann asked you to do a bisection test
<mkrufky> if you do that test, you'll be able to find the exact changeset that fixes the problem, so that they can think about backporting it to hardy
<dupondje> I must say I don't really understand it howto :x
<mkrufky> google git-bisect
<dupondje> I must compile kernel 100000 times then until I get the right patch ? ...
<pwnguin> well
<mkrufky> BISECTION TEST
<pwnguin> more like binary search
<mkrufky> bisection lets you find the fix in ~7 builds
<pwnguin> so something like log base 2 of the number of commits
<mkrufky> er, wait... i think i pulled that number 7 out of my arse ....   
<mkrufky> anyway, bisection helps to find the fix in the least # of builds possible
<dupondje> any id what part of kernel I should look @ for a possible patch ?
<pwnguin> thats what bisect helps with
<pwnguin> you'll find the changeset that introduced the bug with bisect, and that'll narrow the places down considerably
<mkrufky> im goin home .. .tty all later
<pwnguin> dupondje: i agree, i wish building the ubuntu kernel was simpler
<dupondje> well pwnguin, It crashes with ubuntu kernels ... but not with the latest kernel.org kernel ...
<dupondje> dunno about the older kernel.org versions
<dupondje> so maby its just a bug introduced into the ubuntu patches
<pwnguin> here's an idea
<pwnguin> oh, it still doesnt build
<dupondje> indeed :)
<dupondje> ogasawara also had that id ;)
<pwnguin> if ubuntu's kernel built, there shuold be a fairly small diff
<dupondje> and my damn slow CPU :'(
<dupondje> AMD Athlon64 3800+ :(
<pwnguin> plenty fast
<dupondje> not fast enough imo :D
<|dupondje|> mmm :x
<infinity> rtg__: BTW, I have a working hppa kernel patch for you for inclusion in -20- after 8.04.1 is out the door.
<infinity> rtg__: chinstrap:~adconrad/hppa.diff
<infinity> rtg__: Obviously, the change to 2-binary-arch.mk is for our own personal use, but the config changes work smashingly, and that's the precise source we're using in the DC right now.
#ubuntu-kernel 2008-06-07
<rtg__> infinity: got it. I'll do it in London on Monday.
<qense> The Intel chipset drivers are in the normal kernel, aren't they?
<mjg59> Yes
<qense> ok, thx
<hxu> Hi! I need to build a kernel module against the Ubuntu 8.04 kernel. In redhat-like distros, you usually have a kernel-devel package which contains enough kernel source for you to do kernel development.  Is there a kernel devel package in Ubuntu?
<Nafallo> linux-headers IIRC
<Nxx> hi
<Nxx> does anybody know how to make sound work under ubuntuu?
<crimsun> what doesn't work on your audio hardware?
<rysiek|pl> hi all
<rysiek|pl> it's quiet... too quiet
 * rysiek|pl feels uncomfortable
<crimsun> Nxx: ping me in #ubuntu if you need to troubleshoot.
<rysiek|pl> anywhoo... do *anybody* know about any workarounds of i8042 bugs?
<rysiek|pl> my laptop's (LG E200) keyboard dies as soon as the kernel kicks in
<rysiek|pl> needless to say it's quite a showstopper ;)
<rysiek|pl> anybody?
<rysiek|pl> guys, I need some serious help with a laptop keyboard that is not functioning in Linux
<pwnguin> are you going to write a kernel patch for it?
<rysiek|pl> if need be and it will not be some depp-kernell kick-ass kung-fu, why not
<rysiek|pl> pwnguin: why?
<pwnguin> because this is #ubuntu-kernel
<rysiek|pl> anywhoo: it seems to start working after I pass the kernel an i8042.dumbkbd=1 option - but "caps lock" light does NOT light upon using capslock (though capslock works aok, ie. the letters are big)
<pwnguin> from topic: "kernel development ONLY"
<rysiek|pl> pwnguin: yes, I know
<rysiek|pl> pwnguin: google, launchpad, ##linux, ##kernel, #debian, #ubuntu-pl, #kubuntu, #ubuntu and still nothing
<pwnguin> perhaps your laptop vendor will know more about the hardware?
<rysiek|pl> pwnguin: through those 6 hrs of fighting and testing, and re-testing I have come to believe it's a problem with the i8042 PS/2 driver in kernel and some quirky chipset of the laptop I have here
<rysiek|pl> pwnguin: so I am turning - at the very last - to the only place that seems to have people with enough expertise to help me debug this bugger
<pwnguin> just about every laptop chipset is "quirky" :)
<rysiek|pl> pwnguin: e.g. look at dmesgs (i8042.debug=1) or tell me what options should I try now
<rysiek|pl> pwnguin: I have programmed in C a wee bit (not much, and no kernel stuff, but I will know a pointer from a comment...) and - given only little help - I can try to patch the bugger
<pwnguin> irc is a rendevous protocol for debugging something like this; you really want to collect all this information in one place and point experts to that at their leisure
<rysiek|pl> pwnguin: I have got everythin https://wiki.ubuntu.com/DebuggingKeyboardDetection said I should
<rysiek|pl> pwnguin: plus dmesgs from ~10 different runs of the single mode with different options passed
<pwnguin> you mentioned launchpad
<pwnguin> does this mean you filed a bug?
<rysiek|pl> I'm back
<rysiek|pl> pwnguin: not yet. I am not 100% sure it's not a dupe of 2-3 I have found
<rysiek|pl> pwnguin: although I do have (apparently) different chipset and a wee bit different problems
<rysiek|pl> pwnguin: i.e. in one bug the keyboard stops working AFTER suspend/resume, but besides that it's exactly what I have
<rysiek|pl> so, still testing. ;)
<pwnguin> i'd say file the bug and dup it as nessecary
<rysiek|pl> pwnguin: if you have a bit of time, I could point you the dmesgs, lspci logs, etc.
<rysiek|pl> ok, will do
<rysiek|pl> darn, gtg for a while, be back in 45mins
<rysiek|pl> thanks for your time ;)
<pwnguin> well, i don't do much kernel hacking yet
<pwnguin> don't expect a lot of real help from me, but filing the bug might trigger something
<pwnguin> reminds me i still need to follow up with the SD hci guy =(
<emgent> heya
<pwnguin> what's the right way to request a patch be brought into Ubuntu's kernel?
<rysiek|pl> pwnguin: I would say "guys, could you bring this-and-that patch into ubuntu's kernel?" ;)
<dupondje> somebody awake to help creating a patch ?
<dupondje> a fix in fact :)
<pwnguin> well i just see over and over again this pattern where people file a bug against ubuntu, it lingers collecting more and more "is anyone listening" until some lone rider outside the kernel team decides to press upstream and writes a patch
<dupondje> I found the change that makes it crash ...
<dupondje> its 10 lines ...
<rysiek|pl> dupondje: what does you patch fix? (and *do* tell me it's either atheros ar242x, or i8042 on ATI chipsets... ;) )
<dupondje> its a official ubuntu patch ...
<dupondje> for the kernel
<dupondje> Areca Raid controller
<rysiek|pl> dupondje: *disclaimer* I am a complete n00b and I cannot help with the patch
<dupondje> arcmsr
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/235889
<dupondje> check bottom :)
<sectech> Is there a wiki or something that shows what the pci probe error messages mean? I am am triaging a bug that has a PCI probe fail with error -16
<dupondje> Who can commit the patch to the Ubuntu Kernel ?
<dupondje> would be cool if it was fixxed
<dupondje> in next kernel rls
#ubuntu-kernel 2008-06-08
<qense> Do you think that bug 235869 is complete enough for you?
<qense> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/235869)
<qense> isn't bug 238023 just about a change of driver?
<qense> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/238023
<qense> (btw, where is ubotu?)
<mjg59> qense: 238023 doesn't seem to be a bug
<qense> ok
<qense> just a change of driver?
<gnomefreak> qense: ubotu is gone its now ubottu 
<qense> ubottu also seems to be offline
<gnomefreak> and not in this channel 
<qense> oh
<gnomefreak> qense: no hes just not in here
<qense> ok :)
<qense> why does it have two ts now?
<gnomefreak> qense: two what?
<qense> t
<qense> ubotu vs ubotTu
<gnomefreak> because ubotu is gone for now nut sure if it is comming back
<gnomefreak> s/nut/not
<qense> ok, thx
<qense> (thank you too, mjg59)
<leoncamel_> hey. folks. currently, i am using 2.6.24-18-generic now. It seems that it is not quite stable here. 
#ubuntu-kernel 2009-06-01
<TheMuso> u/c
<colonelqubit> I filed a hibernation bug about a month ago and I've been unable to fix it myself (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/366264).
<ubot3> Malone bug 366264 in linux "[Dell XPS m1530] Resume fails after hibernate/suspend" [Undecided,New] 
<colonelqubit> Is this the right place to ask for help in diagnosing and fixing this bug?
<colonelqubit> is there somewhere else I should ask for help with this bug?
<johanbr> colonelqubit: remove "splash" and "quiet" from your kernel boot line
<johanbr> that should give you some more idea what's wrong
<colonelqubit> johanbr: will do
<colonelqubit> johanbr: should I edit menu.lst, or just temporarily change the boot params in the grub menu and then try to test suspend?
<johanbr> colonelqubit: doesn't really matter
<johanbr> it's mostly for debugging, so maybe the temporary way is best
<colonelqubit> johanbr: what should I be looking for? I've been reading notes on the wiki (https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume), but I'm not sure if there's specific info I should put on the bug.
<johanbr> well, it looks like it locks up, right?
<johanbr> just write down what the last few messages are
<colonelqubit> johanbr: yes, it looks like it locks up. I'll append the longer kernel log to the bug
<johanbr> alright
<johanbr> gotta go... good luck
<colonelqubit> johanbr: thanks for the help -- should I ping back to #ubuntu-kernel once I've done this?
<johanbr> sure, that doesn't hurt
<johanbr> although most of the kernel guys are probably asleep now :)
<colonelqubit> okay, I'll try tomorrow morning
<johanbr> alright
<colonelqubit> have a good night
<johanbr> same to you
<Yingying_Zhao> Which kernel will Karmic final use?
<cooloney> Yingying_Zhao, we decided to use 2.6.31
<apw> yep 2.6.31 is the aim
* apw changed the topic of #ubuntu-kernel to: Karmic Kernel Plan: 2.6.31 -- Ubuntu Developer Summit this week. info on http://summit.ubuntu.com - and in #ubuntu-devel-summit
<apw> cking, we were musing about doing a small image for testing of new features on usb
<cking> apw, jaunty or karmic?
<apw> do you have any canned way of making those or is this something we need to think about
<apw> i t
<apw> i think the though was making a karmic job with x-edgers, updated kernels and grub2
<apw> and somehow making all that fit in 0MB (of course)
<apw> so it would be trivial to download and test as a bootable image not installed
<cking> apw: I just do a clean install to a 8GB USB pen drive and then remove the bloaty apps then shrink the partition using gparted 
<apw> how small do you think it might go?
<cking> Mmm.. 2.2GB was everything, so possibly down to less than 2GB and compressed down to 600MB
<apw> so not exacty tiny then
<apw> my chroots which contain X are of the order of 550MB
<cking> I've got a minimal gnome lpia installer which is ~450MB
<cking> (compressed)
<apw> thats not the 100MB i was hoping for ... though it was a naieve wish
<cking> 100MB is just not possible
<cking> apw: would a 500MB image be reasonable?
<apw> frankly i don't think it was me who cared how big it is
<apw> i think the utility to both the user and us outweighs the size downsides
<cking> apw: do you want this image to be produced automatically?
<apw> cking, i am not seeing a need for that ... 
<apw> i can just update it and remake it etc pretty easy once i have a basic one
<cking> I suggest downloading the latest image, install it to a 8GB USB stick and removing all the bloaty apps and shrinking it with gparted and working with this as a basis.
<apw> cking, yeah sounds like a reasonable plan indeed
<ogra> moo
<Sam-I-Am> oink
<ogra> root@osiris:~# grep CPU_FREQ_DEBUG /boot/config-2.6.30-6-generic 
<ogra> # CONFIG_CPU_FREQ_DEBUG is not set
<ogra> hrm
<smb> ogra, trying to find something. But mjg59 if you happen to hang around. Would you know a way to prevent a build-in acpi-cpufreq from getting selected?
<smb> ogra, The whole of acpi debug is disabled by default
<ogra> yeah
<mjg59> smb: No
<ogra> we should probably have it on during development 
<mjg59> Why would you want to?
<ogra> my system is constantly running the fan and the frequency doesnt go below 1GHz since the modules were included in the kernel by default
<smb> mjg59, To try to check what driver would get used next. ogra has a case where he had a lower freq avalable before but not with the acpi driver
<ogra> i'd like to have my 800MHz default back :)
<mjg59> What hardware is this?
<ogra> model name	: Intel(R) Core(TM)2 Duo CPU     T5550  @ 1.83GHz
<mjg59> And now what's the lowest speed?
<smb> mjg59, 1Ghz 
<mjg59> acpi-cpufreq is the only correct driver for that chip
<mjg59> If it's missing a state now then that implies that there's been a code change rather than a driver change
<mjg59> Unless you were somehow using p4-clockmod previously, in which case your life is now immeasurably better than it was then
<ogra> i'm pretty sure with the modules a different direver was used
<ogra> *driver
<ogra> not sure if it was the right one, but it definately scaled to a lower speed by default
<mjg59> Other than acpi-cpufreq, only p4-clockmod could possibly bind to that chip
<smb> mjg59, Yeah, that was somehow my suspicion
<mjg59> And that doesn't do voltage scaling
<ogra> yeah, might be that it was the p4 one
<mjg59> So things are now better than they were previously
<ogra> my lappie is most of the time on AC ... what i care for is the constantly running fan
<mjg59> It'll run coler at 1GHz with acpi-cpufreq than at 800MHz with p4-clockmod
<mjg59> s/coler/cooler/
<ogra> hmm
<mjg59> V^2/R and all that
<ogra> then why does it run constantly even though thermal_zone only shows 55Â°C ?
<mjg59> Because the lowest trip point is below 55C?
<ogra> root@osiris:~# cat /proc/acpi/thermal_zone/TZ0/trip_points 
<ogra> critical (S5):           91 C
<ogra> not really
<mjg59> Oh, so it's all BIOS controlled anyway
<ogra> i have no BOIS option for it though
<ogra> *BIOS
<mjg59> You typically won't
<ogra> well, it used to only spin up once an hour or so when the machine was idling
<stgraber> ogra: got my mail ?
<ogra> until the whole stack of cpufreq/thermal moved into the kernel 
<stgraber> oops, wrong chan :) thought I was in #ltsp, sorry
<mjg59> ogra: Shrug.
<mjg59> ogra: If you were using p4-clockmod before then your machine was running hotter. That's a thermodynamic certainty.
<smb> Probably with p4-clockmod the temp was slightly lower at 800MHz 
<mjg59> smb: No
<smb> Ok, that would have been my only way to explain this
<mjg59> smb: Power consumption is linear with frequency, but tends towards a V^2 relationship with voltage scaling
<smb> Hm, and iirc the p4 driver did only freq scaling
<ogra> is there any way to tell acpi-cpufreq to use 800MHz ?
<mjg59> ogra: It uses whatever frequencies your BIOS provides
<smb> mjg59, Could a custom dsdt override the frequencies?
<mjg59> Yes
<mjg59> But if you're driving the chip at lower voltages then it's designed to, then you risk data corruption
<mjg59> And just dropping the frequency won't save you anything
<mjg59> It just means you spend less time in deep C states
<apw> ogra, i am a little supprised you have no 800mhz given the model you have thre
<apw> my model, looks like a later version of yours and has 800 available
<mjg59> The frequencies available are determined by the bios, not the CPU
<ogra> my system is a clevo tn120
<apw> interesting ... i'd not thought of it that way
<mjg59> ogra: Stick the output of acpidump somewhere?
<ogra> wow, thats huge
<mjg59> Yes
<mjg59> Don't pastebin it
<ogra> http://people.ubuntu.com/~ogra/acpidump.out
<mjg59> Hm.
<smb> mjg59, Triying to learn a bit more here. What would be the thing to look at?
<mjg59> smb: You want the _PSS object
<mjg59> It contains the set of ACPI performance states
<smb> Ok, seems to be referenced in ssdt2 and dsdt
<mjg59> Except it's not actually present in them
<mjg59> There's probably a dynamically loaded table
<smb> I see... hm
<smb> mjg59, That _tss method in ssdt2 looks slightly like setting up something oneshot...
<mjg59> _TSS is for T-states, not P-states
<smb> mjg59, sigh, quite confusing. It walks through the p-states to build the t-states... or so it looks...
<mjg59> Yeah, I'm not sure what it's doing there
 * ogra is back from his phonecall
<smb> ogra, Unfortunately I seem to be far from understanding what your BIOS does... :(
<ogra> well, dont ask me about it either :)
<smb> ogra, I won't :)
<snakie> Hi, I'm looking for a download location for the .ddeb containing debug information on 2.6.28-12-generic for jaunty. Do any mirrors exist or are the 2.6.30 versions on ddebs.ubuntu.com the only available versions?
<apw> i believe ddebs.u.c is the place for those
<snakie> yes, do you know where to find older kernel versions as ddebs.u.c only has 2.6.30
<cwillu> hey, anyone want to look at a dmesg dump from a laptop that slowly dies after resuming from suspend?
<cwillu> 2.6.30rc7 from the mainline kernel ppa
<cwillu> http://pastie.org/496676
<cwillu> The process that triggers the first oops is varies, but it's always "BUG: unable to handle kernel paging request at <address>"
<cwillu> s/is//
<cwillu> I have an ssh open to it, so I can paste additional information, although at this point not much actually runs (dmesg does for instance, new gnome-terminal windows can open, but new bash processes don't start)
<johanbr> the disk doesn't come back to life properly?
<cwillu> it kinda does
<cwillu> it's weird
<cwillu> I can resume and use it normally for a while
<cwillu> and then things start breaking
<cwillu> at which point, any access to the disk seems to hang the process that made the access
<cwillu> under our .30 kernel, it hangs almost immediately on resume (on the order of a few seconds to a few minutes).  on mainline, it works for several minutes to several hours
<cwillu> https://bugs.launchpad.net/bugs/380807 has some info from the -generic kernel
<ubot3> Malone bug 380807 in linux "[karmic, intel] Laptop locks up moments after resuming from suspend" [Undecided,New] 
<pgraner> apw: can you get the bug above [380807] into the Suspend/Resume queue?
<cwillu> would ssh access to the box in this state be useful?
<pgraner> cwillu: yes don't knock it down just yet
<apw> it would be useful to know are able to login to it remotly
<cwillu> pgraner, yep, it's still up, and I can reproduce it fairly easily
<pgraner> apw: I think he had a ssh up prior to the oops
<cwillu> (sec, attaching dmesg to that bug, and then I'll see if I can ssh in a second time)
<pgraner> apw: looks like we have mem being mapped into the ether
<cwillu> bah, ssh session just died
<bjf> pgraner, are we having an IRC meeting tomorrow?
<cwillu> desktop session is still up though
<cwillu> dmesg is attached to that bug now (same as the pastie)
<cwillu> pgraner, if you had one command that you could see the result of, what would it be?  (noting that it may just hang the last remaining terminal I have open)
<cwillu> (can still run dmesg, but have no way to copy it elsewhere)
<apw> any commands you run,. run in the background fo &
<apw> and then if they hang you'll likely keep your shell
<cwillu> k
<cwillu> wasn't sure if it would lock it up too
<apw> it may...
<apw> do you have KMS enabled?
<cwillu> and... gnome-terminal just died
<cwillu> (independently of any other commands, just stopped responding)
<apw> damn
<pgraner> bjf: we should be meeting, I need to look at the page and see who is chairing it
<cwillu> and there goes compiz, although I can still move the mouse :p
<bjf> pgraner, I asked because I think I am chairing.
<apw> cwillu, so this is triggered by a suspend/resume i assume ?
<cwillu> apw, yes, every time
<pgraner> bjf: heh, cool. I think just putting out a summary of kernel actions out of UDS would be good.
<Sam-I-Am> cwillu: i might recommend using 'netconsole' on the next boot
<apw> you don't have an mmc card inserted do you?
<cwillu> nope
<cwillu> desktop is locked up completely now (no mouse, etc)
<apw> mouse too ... hmm
<cwillu> sysrq-s hit the disk though
<pgraner> cwillu: is this a laptop or desktop?
<cwillu> laptop
<Sam-I-Am> if you configure netconsole it'll dump all the kernel output to a udp port somewhere... like syslog
<cwillu> suspend was rock stable from 7.04 up to 9.04
<cwillu> Sam-I-Am, next reboot :)
<Sam-I-Am> heh
<pgraner> cwillu: 2.6.30 got an overhaul of the suspend/resume subsystem
<apw> who was talking about locking issues in -rc6 for suspend?  who told us about that
<pgraner> apw: marcel was telling us at UDS
<cwillu> apw, I saw a bug about that I think, I might have it open still
<apw> cwillu, be good to have any pointers you have found already to save time
<pgraner> apw: perhaps and apport-collect to make sure you have everything?
<cwillu> pgraner, the attachments on my bug were from apport-collect
<cwillu> http://patchwork.kernel.org/patch/1113/
<pgraner> cwillu: cool
<cwillu> that's old though
<cwillu> january
<cwillu> just noticed the date
<cwillu> there's 3 vaguely similar bugs on launchpad that I saw, all against 2.6.28 though
<cwillu> I'm going to reboot and get it reproducing again
<apw> cwillu, looks interesting as i am sure that same routine appears in suspend
<apw> and so far i've not seen that change as presented in the kernel
<cwillu> do you want me on ubuntu's kernel or mainline's?
<cwillu> both have the problem, ubuntu's crashes far quicker though (almost too quickly to do anything with)
<cwillu> other interesting datapoints, I _think_ it worked fine while I was still on jaunty with 2.6.30rcX (needed it to work around the ext4 file deletion hanger)
<apw> cwillu, so that was with a mainline kernel?  your own build?
<cwillu> although you should probably ignore that, I don't remember at all well enough
<cwillu> apw, mainline ppa
<apw> so that should still be on your machine and testable on karmic too
<cwillu> apw, you misunderstood me :p
<cwillu> apw, both the mainline ppa kernel and ubuntu's -generic do this
<cwillu> that dmesg came from 2.6.30rc7 from the mainline ppa
<apw> ok ...
 * cwillu reboots into 2.6.30-020630rc7-generic
<johanbr> any major differences in userspace suspend between jaunty and karmic?
<apw> the patch you pointed to on patchworks is somehow in karmic under a different patch id
<apw> johanbr, outside the kernel no, inside some
<cwillu> how do I verify that I'm not using kms?
<cwillu> I played with plymouth during jaunty's release (as long as I was on 2.6.30 and all that)
<apw> unless you have modeset mentioned on your grub command line
<cwillu> thought I removed it completely
<apw> or in your module options then you don't
<apw> it is opt in currently
<cwillu> k, should be clear then
<johanbr> cwillu: how do you suspend?
<cwillu> johanbr, normal suspend
<cwillu> not uswsusp or anything like that
<apw> cwillu, another good test point would be the tip of linus' tree: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-05-30/
<cwillu> apw, k, downloading it right now
<apw> there are some locking changes for suspend in there, though i think they are meant to be more theoretical to be fair
<cwillu> is there an easy way to force a message so I can see if this netconsole is actually working?
<apw> hrm
<apw> sysrq help might do it
<apw> i think the title is always emitted
<cwillu> yep
<cwillu> good
<cwillu> (in the sense of 'it worked')
<apw> also worth doing the suspend from vt1, as you may see errors there
<cwillu> messages that wouldn't show up in /var/log/{messages/kern.log/syslog/dmesg}?
<apw> depending on the nature of the hang they might not get to disk yes
<cwillu> the oops that starts to bring things down doesn't necessarily occur right away
<cwillu> I'll still try it, I'm just spewing everything I can think of that might be relevant
<cwillu> 8 minutes until the download is complete, at which point I'll install,  and then suspend on the current kernel
<cwillu> or should I go straight to the daily and see if it reproduces first?
 * cwillu pokes apw with an inquisitive stick
<apw> i think continue with your test on the current, and then the c-o-d kernel
<cwillu> k
<cwillu> installing right now
<cwillu> suspending from console
<cwillu> hard lock
<cwillu> 9 segfaults are visible, laptop_mode mostly, and one cpufreq
<cwillu> I think I saw another error flash by too
 * cwillu reboots and tries that again
<cwillu> nothing showed up in the netconsole
<cwillu> actually, that's a lie
<cwillu> [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
<cwillu> show up
<johanbr> cwillu: could you try with the jaunty kernel?
<cwillu> johanbr, sure, doing it now
<cwillu> (noting that jaunty's kernel has ext4 issues that causes other lockups)
<cwillu> (but I shouldn't run into them without deleting files)
 * cwillu suspends
<cwillu> came back with no errors on the console
<cwillu> 2.6.28-10-generic #33
<cwillu> netconsole didn't show anything during the suspend, although it's still connected (I did a sysrq-sync before and after, both showed up in the netconsole)
<cwillu> johanbr, apw, given my original dmesg, is there anything that jumps out at you as a way to check whether something has gone wrong, even before the system oops?
<cwillu> something in /proc/ or /sys/ I could check?
<johanbr> Comparison with the dmesg from the jaunty kernel might be interesting
<cwillu> I'll post that in a minute
<cwillu> just proving to myself that it's stable
<cwillu> by playing flash games on casualcollective.com of course :p
<cwillu> seems to be fine
<cwillu> okay, dmesg
<cwillu> http://pastebin.com/f3757f4a5
<cwillu> was the original with the fault http://pastie.org/496676
<cwillu> (bah, pastie was with fault, pastebin was jaunty's kernel that worked fine)
 * cwillu pokes johanbr and apw 
<cwillu> I'm rebooting into the daily 2.6.30 now
 * cwillu suspends current daily kernel
<cwillu> dmesg from 2.6.30-999-generic (current daily):  http://pastebin.com/f162d6f02
<cwillu> didn't immediately crash, let me test it for a bit again
<cwillu> oh, wait
<cwillu> an error showed up a second after I pastebin'ed it
<cwillu> [  261.585748] EXT4-fs error (device sda1): ext4_lookup: deleted inode referenced: 12206095
<cwillu> [  261.585768] Aborting journal on device sda1:8.
<cwillu> johanbr, apw:  http://pastebin.com/f5c2ec258 has the latest error included
<cwillu> opinions?
<cwillu> I'm tempted to remount rw and see if there's any further instability, 
 * cwillu reboots to fsck and repeat
<cwillu> fsck finished, suspending agani
<cwillu> well, suspending after rebooting :/
<apw> cwillu, hrm. can we get all that info into the bug, and i'll have a look about.  especially the version you are stable on
<cwillu> apw, yep.  I'm not completely convinced the last crash was the related, but I'll post the dmesg's 
 * apw has to pop out ...
 * cwillu tackles apw to hold him in the channel :p
<cwillu> the daily hasn't done anything odd yet
<cwillu> I'm going to keep poking it for a couple hours (longest I've ever had a suspend last and still crash)
<cwillu> apw, updated the bug report with jaunty's dmesg
 * cwillu suspends again for kicks
<cwillu> apw, it's still a little early to be sure, but I've suspended a couple times without rebooting on the daily kernel, and I haven't had any issues except for that first attempt with the ext4 mounting read-only, which may have been related to previous crashes more than the suspend
<apw> cwillu, thats encouraging ... if you have an oppotunity to  do say 10 suspends and report back on the bug that would be handy
<cwillu> definitely
 * cwillu suspends again
<cwillu> [ 4022.240004] BUG: soft lockup - CPU#0 stuck for 61s! [python:8575]
<cwillu> lots of b44: eth2: Error, poll already scheduled
<cwillu> apw, how likely is it that a daily would have random crashers in it?
<cwillu> apw, just completed 20 suspend cycles on the daily, 60 seconds between each resume and the next suspend.  Nothing suspicious shows up in dmesg, I'm posting it to the bug report
<colonelqubit> johanbr: hi again. I've had some progress in testing hibernation on my laptop.
<johanbr> alright
<johanbr> I'm about to head out, but go ahead...
<colonelqubit> if I disable splash/quiet and enable no_console_suspend, and hibernate from vt1, and never try to go to vt7 (with X), then hibernation and resume works (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/366264)
<ubot3> Malone bug 366264 in linux "[Dell XPS m1530] Resume fails after hibernate/suspend" [Undecided,New] 
<colonelqubit> I'm getting errors about btusb_intr_complete and btusb_bulk_complete. They appear to have "failed to resubmit"
<johanbr> that shouldn't matter very much
<colonelqubit> okay
<colonelqubit> johanbr: As I said, it appears that I can get hibernation to work properly in vt1, but I can't hibernate from within X or return to X once I've gone though a hibernation cycle. Any suggestions on what I should try testing next?
<maxb> It is intentional that ddebs.ubuntu.com only provides karmic ddebs?
<cwillu> maxb, I see a bunch of different releases in /dists/
<maxb> Sorry, for the kernel I mean
<maxb> pool/main/l/linux/ only seems to have karmic packages
#ubuntu-kernel 2009-06-02
<dtchen> maxb: the debug packages are generated from the source package; e.g., linux-image-debug-2.6.30-7-gene
<dtchen> ric
<dtchen> maxb: keep in mind that the tree is in flux while ports is rolled back in, so the packaging may well be different for -8
<maxb> No, this is a state of affairs that has existed since Intrepid if the comments in malone are to be believed
<maxb> It looks like ddebs.u.c is keeping only one or two recent package versions, without regard for multiple distroseries
<mase_work> hey guys , i  am running into the same symptoms as https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/240071 on a fully up to date 8.04.2 server. It says a fix has been released but I can't see anywhere what the fix actually was and if that means it's been released as part of the regular update cycle of it need a special repository
<ubot3> Malone bug 240071 in linux "BUG: soft lockup - CPU#0 stuck for 11s!" [Undecided,Fix released] 
<mase_work> I was hoping someone could guide me as to how i can determine if I am hitting this same issue or if I have something different that just presents the same
<cwillu> mase_work, that's an error, it's fixed in intrepid, somebody said they'd nominate it for hardy, but it looks like that didn't happen
<cwillu> mase_work, you might be able to get away with simply installing intrepid's kernel packages though
<cwillu> actually, ignore that
<mase_work> ah ok. so i need to apply this patch normally
<mase_work> manually rather
<mase_work> cwillu: sorry this might seem like a stupid question, is it possible in launchpad to get a patch or a git commit id which i could use to grab the patch 
<cwillu> mase_work, sometimes, but in this case, I don't think so
<cwillu> it looks like it was a "here's a new version with lots of stuff fixed, is your bug fixed?", without a specific patch in mind
<mase_work> I see. Do you have any recommendations as to how best to deal with this ? 
<mase_work> should i revert to a previous kernel or move to a newer kernel ?
<cwillu> move to a newer one is probably the best bet, you can just install the deb files for a later kernel image, they should Just Work.
<mase_work> cwillu: so the intrepid-xen images are acceptable ?
<cwillu> I would imagine s
<cwillu> so
<mase_work> ok thanks. I am using pygrub so i should be able to do it. Do you know if the vpcu=1 work around that is listed is likely to actually work ?
<ZeroProg> hey guys im trying to learn some driver writing but am having trouble compiling and testing....is there an ubuntu doc for doing this?
<ZeroProg> anybody in here
<mase_work> yeh there is
<mase_work> i just don't know the answer to your question sorry
<mase_work> i could google around but i presume you have already tried that approach and been unsuccessful
<ZeroProg> exactly
<ZeroProg> i guess the best place to start would just be ubuntu kernel programming but i cant seem to find a tutorial 
<lifeless> its not an ubuntu specific thing
<lifeless> look for linux kernel docs/tutorials
<lifeless> rusty russell has done several tutorials at LCA for instance
<ZeroProg> i have but after talking to people in #kernelnewbies and they said ubuntu is different
<lifeless> Ubuntu takes the kernel and we add some patches and package it. Its still the same thing though in terms of writing code for it.
<ZeroProg> yes but the source and headers and stuff is different is what i gather
<lifeless> news to me
<ZeroProg> i followed 3 tutorials to the letter and i still get the same errors about not finding linux/init.h
<ZeroProg> the guys in the other channel said something about make-kpkg
<lifeless> are you trying to build with the full kernel source locally?
<lifeless> or using your installed kernel's headers?
<ZeroProg> whatever i need to do to write drivers heh
<lifeless> depends on what you're doin
<lifeless> g
<lifeless> but I can't give you a useful pointer unless you tell me *what you were trying*
<ZeroProg> u mean like what type of driver?
<lifeless> no
<ZeroProg> oh ok
<ZeroProg> i understand....i read these tutorials about what was needed to write drivers and the consensus was to download and build a kernel source 
<ZeroProg> so i followed the readme included with the source
<ZeroProg> other tutorials said headers were sufficient but i still cant get ubuntu to recognize linux/init.h and the other includes 
<lifeless> ok, following the full source approach is easiest I think
<lifeless> and the vanilla upstream kernel will build on Ubuntu
<lifeless> in fact we use that for testing 
<ZeroProg> ok...is there perhaps a newb tutorial on downloading and installing that?
<lifeless> sounds like you were following one
<ZeroProg> yeah :/
<lifeless> so, I'd follow it. Do the full source one, not the headers package - that way you are guaranteed to have everything basically the same.
<ZeroProg> ok
<ZeroProg> thanks again
<ZeroProg> where can i find that kernel
<lifeless> http://kernel.org/
<ZeroProg> ohh ok i thought it was something specific my fault
<ZeroProg> one last newb question for the night....how do u know its vanilla upstream
<lifeless> if you get it from upstream :)
<ZeroProg> lol is there an upstream section on the site?
<mase_work> that is _the_ upstream
<ZeroProg> jeez im confused...what makes it vanilla is that what its named?
<mase_work> no 
<mase_work> vanilla just means no added patches
<mase_work> its the tree that linus holds
<mase_work> Ubuntu uses that then applies some added patches for various things
<mase_work> and packages that up as the ubuntu kernel
<mase_work> but for the most part they are the same
<ZeroProg> ohhh ok
<mase_work> the version on kernel.org is the unpackaged source version.
<ZeroProg> alright im gonna leave before i ask anything else dumb thanks again
<mase_work> ZeroProg: have you done much C programming before ?
<ZeroProg> not on linux but yes
<mase_work> ok cool. 
<mase_work> have fun
<ZeroProg> haha ill try thanks
<ZeroProg> ok i installed the new kernel....to use it it tells me what to do but after i do that i should be able to code correct?
<ikepanhc> hi smb
 * apw waves to ikepanhc 
<ikepanhc> hi apw
<ikepanhc> have a question for you: bug 360966
<ubot3> Malone bug 360966 in linux "bnx2x missing in initrd for install media" [Medium,Won't fix] https://launchpad.net/bugs/360966
<ikepanhc> could I set affect to initramfs-tools?
<ogra> ikepanhc, more likely debian-installer 
<ikepanhc> ogra: you mean debian-installer makes the initrd?
<ogra> initramfs-tools is only used on installed systems or in conjunction with casper for the live images
<ogra> the alternate installer uses udebs ... ogasawara mentioned ./debian/d-i/modules/nic-modules, thats a udeb spec file 
<ikepanhc> oh, you are right
<ogra> so its actually a linux issue ... d-i only uses the produced udeb
<ikepanhc> I know what I am wrong, I test with a new kernel install
<ikepanhc> thanks ogra
<ikepanhc> ogra: but it is useless to send as Jaunty SRU, because we have released it
<ogra> i'm not sure, it would require a d-i SRU as well i think, cjwatson could answer that
<ikepanhc> so, could we assume this issue only affect him because he use NFS as rootfs?
<ogra> well, he doesnt talk anout nfsroot
<ogra> just that there is no network available
<ikepanhc> The jaunty release kernel image contains the module he need, but he said he need the module when initrd.
<ogra> right
<apw> thanks ogra 
<ogra> but debian-installer uses the nic-modules udeb
<ogra> in the netboot iso the udebs are included, in the normal d-i the udebs are loaded from CD
<ogra> either way the driver needs to be in the udeb, no matter if you do a local or netboot install
<ogra> indeed in case of nfsroot its more fatal :)
<ikepanhc> Thanks ogra, I will check the d-i and udeb
<ikepanhc> I assume he use NFS rootfs because he will have the module after mounting local rootfs
<ikepanhc> Then I have to check if there is another net module missing
<ogra> well, how would he do an nfsroot install without network ? :)
<ikepanhc> ohoh, I forget this
<ikepanhc> anyway, I re-open this bug :-D
<ogra> if its for SRU talk to cjwatson first about the d-i situation
<ogra> its pointless to add it to the udeb if d-i wont use it
<ikepanhc> got it
<ikepanhc> thanks ogra
<apw> smb, you had a machine which worked, stopped working for a bit, and started working again on later kernels with no obvious changes in the area of the fault.   what was the symptoms there?
<smb> apw, You probably mean the acer which crashed when chaging the kernel data ro
<apw> yeah thats the one... thanks
<smb> It was the AA1, and crashed early on in the boot.
<apw> you remember nigelp's sata issue.  there his machine failed on -11.38 worked on either .39 or .40 and stopped again on .41
<apw> and yet there is no sata changes in that sequence
<smb> using acpi=off made it working in most cases (strange enough)
<smb> Sounds weird indeed
<apw> nnng... 
<apw> another wierdy for sure
<smb> how did nigelp's machine not work (mean the symptom there)?
<apw> sata timeouts and panics (i believe he has flashing capslock syndrom at times)
<smb> slightly different than the other as that was strictly locatable to the point of making the ro change (though sometimes you got killed by recursive stacktraces)
<smb> Do we have any stactrace hint?
<apw> nothing yet that i have seen.  he is testing -proposed and latest mainline for me now
<cking> apw: it's weird that we have not see this kind of issue on any other identical hardware
<apw> i know ... very
<cking> apw, I suspect the H/W is borked
<apw> ok he has -proposed installed -12 kernel and is now happy
<apw> explain that one to me
<rimvis> hi, i have problem with aoetools who can help me?
<smb> apw, random memory relocation and timing?
<apw> smb, its cirtainly looking like that kind of thing ... very annoying to debug
<smb> apw, You think a fully debug (kernel hacking) kernel might help? Unfortunately this often removes the race
<apw> yeah not sure ... cirtainly intereested in getting the latest mainline tested there
<apw> to see if its going to come back when he upgrades to karmic
<apw> nigelp is with us now :)
<apw> nigelp, so you have no problems now with the -proposed kernel ?
<nigelp> apw, none of those SATA issues that showed up that I had to do irqpoll and all_generic_ide for.
<apw> very perplexing
<nigelp> the test that triggered it was downloading a CD image.. I've just downloaded 10 in a row; it never used to make it past 100Mb before.
<smb> It will be interesting to see how the -13 kernel that will be in -proposed soon fares
<smb> If that fails it is definitely weirdness time
<apw> nigelp, what was your disk controller?
<apw> yeah a quick review of the changes between where it did not work before and the -proposed kernel isn't showing anything i would expect to help you
<nigelp> apw, sorry, being ignorant.  How do I find out what my disk controller is? 
<apw> lspci | grep -i sata 
<apw> might do the trick
<nigelp> apw, is this what you're looking for?  ATI Technologies Inc IXP SB400 IDE Controller (rev 80)
<apw> yep
<apw> nigelp, we need to get all this data into the same bug.  if you have one with support lets get that out of them, else we need a new one
<apw> i can imaging you want to get some work done now its working! but if you have a chance later to test the mainline kernel i pointed you to that would help.  and get that info into the bug too
<apw> then let me have the number when you have it
<nigelp> apw, let me ask shang if he opened one.
<nigelp> apw, support say its the same bug as: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/206635
<ubot3> nigelp: Error: Could not parse data returned by Malone: timed out
 * apw pokes ubot3
<apw> but that bug is duplicate of a bug which was fixed in intrepid and jaunty
<nigelp> ok.. so time for a new one?
<apw> way back in feb.  so ... if you are seeing it now its either a new one, or that one was not fixed
<apw> for now i would open your own bug, and add your info there, if it _is_ dup we can dup it later
<apw> ubuntu-bug linux should do the trick
<apw> smb, the karmic meta update should be in my sign directory if you could look it over
<smb> apw, sure
 * ogra hugs BenC ... good to see you :)
<smb> apw, uploaded
<apw> smb thanks
 * cking waves to BenC
<BenC> ogra, cking: Hey
 * BenC is out, packing for san fran
<apw> nigelp, can you subscribe me to the bug when it exists
<nigelp> apw, sure
<apw> smb, for hardy do we use linux-image-2.6.24 still?
<smb_tp> apw, Hardy is 2.6.24, yes
<smb_tp> or do you mean the naming?
<apw> i mean do we use linux or something else for bugs there
<Kano> hi apw , do you update the karmic kernel now and not rtg?
<apw> our team is responsible for it, i am handling the rebases for a bit while rtg is off doing other things
<smb_tp> apw, Hardy uses linux
<apw> smb_tp, thanksk ... and when did you go back to _tp?
<smb_tp> apw, When I disconnected and irc still thinks me is there
<apw> smb, heh ... still not reset your router at midnight then
<smb> apw, No, you should poke me :)
<smb> apw, BTW, you can see what label to use in debian/changelog. It was linux-source-x.y.z before hardy
<apw> ahh before hardy.  good
<Kano> apw: are you interested in an aufs2 patch
<apw> an updated one for karmic kernel?
<Kano> yes
<Kano> i tested it even with your live iso
<Kano> cjwatson tries to use unionfs-fuse but his approach does not boot
<apw> send it over.  we are looking at vfs-union mount right now for the live cd's but should that not be possible the aufs patch would be a good fallback
<Kano> i needed to update it as you removed aufs completely
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.30-ubuntu-aufs2.patch.bz2
<Kano> thats the new one
<Kano> also i would like to see a patch which removes the usb ids from rt2500usb which are also in rt73usb
<Kano> because i had 2 users with problems where rt2500usb was loaded and nothing worked
<Kano> 4 ids are in both drivers
<apw> we need to get those ids listed in a bug i recon
<Kano> it is easy to get em
<Kano> (/sbin/modinfo -F alias rt73usb;/sbin/modinfo -F alias rt2500usb)|sort|uniq -d
<Kano> /sbin/modinfo -F alias rt73usb rt2500usb|sort|uniq -d
<Kano> thats even shorter...
<Kano> apw: also how about enabling the lzma options for smaller kernel size
<apw> for compressed kernels?
<Kano> you could even update update-initramfs and use lzma if the kernel config has the needed setting
<apw> how well tested is that
<Kano> sure
<Kano> if you dont enable nobody tests it
<Kano> it is one of the major points for 2.6.30
<Kano> i hope that squashfs will get lzma too because it is now inside the kernel
<apw> lzma was the one which had poor rsync behaviour i think?  making it near useless for CD's
<apw> iirc
<Kano> nope
<Kano> did you never hear of lzma patches for squashfs
<Kano> http://www.squashfs-lzma.org/
<Kano> slax used it
<amitk> apw: ack re: lzma + rsync not being friends
<Kano> tar.lzma is now the default for slackware
<Kano> so many use it now
<apw> as i remember the size savings are impressive and would be desirable for our live images, but a problem for the QA process as its non-rsyncable
<Kano> i dont get it
<Kano> rsync is independent of the data
<bjf> *** There will be an Ubuntu Kernel Team meeting on #ubuntu-meeting at the top of the hour.
<apw> Kano, right but the data needs to be similar between images to allow rsync to be efficient
<apw> and lzma produces images which are completely different for a small change in the contents
<Kano> well squashfs stores files basically always the same
<Kano> should not matter that way
<apw> bjf, good idea to announce here
<Kano> did you really test squashfs-lzma or pure lzma?
<apw> seems it does, from the testing that foundations has done
<apw> so they tell me yes
<Notch-1> hi all, should anybody tell me something about https://bugs.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902 ?
<ubot3> Malone bug 342902 in loop-aes-source "Build error: âstruct bioâ has no member named âbi_hw_front_sizeâ" [Undecided,New] 
<Notch-1> in a few words, we need CONFIG_BLK_DEV_LOOP back to "m", is it possible?
#ubuntu-kernel 2009-06-03
<Kano> apw: http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.30-rc8
<Kano> did you rebase yet
<apw> not yet.  was expecting it today, and will be on my todo for today
<Kano> why dont you sent the one sauce patch to linus, for 2 or 3 rc you carry it and it causes always problems with merging
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commitdiff;h=abc55974c570b037c04d33b32f269cd9e9f11bee
<Kano> and drop that
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138
<ubot3> Malone bug 380138 in linux "Do NOT disable HPA by default -> leads to data loss" [Undecided,New] 
<Kano> thats the bug report you always wanted
<Kano> also you could enable lzma kernel compression
<apw> Kano, thanks for the bug and the write up will persume
<apw> persue
<cwillu> apw, I had a delayed crash after resume on the daily kernel earlier today, although it was certainly a record in terms of length of time before a process died with a "bug: unable to handle kernel paging request"
<cwillu> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380807)
<ubot3> Malone bug 380807 in linux "[karmic, intel] Laptop locks up moments after resuming from suspend" [Medium,In progress] 
<apw> cwillu, did you manage to get a panic trace from your later hang?  i am presuming from the different drop dead point that this may well be a different issue
* You're now known as ubuntulog
<Kano> apw: any big problems with rebasing on rc8?
<apw> nope.  rebase was basically clean.
<Kano> i see no rc8 in logs
<Kano> maybe soon there will be 2.6.30 final
<apw> its not pushed yet.  just uploaded the builds
<apw> yep .30 is expected this weekend
<apw> then the .31 madness begins
<Kano> i guess i release an iso based on .30
<Kano> i only have to remove those 4 ids
<Kano> the rest of my testers have got no real problem with it
<Kano> i might try lzma compression for kernel too
<Kano> because it is a bit huge
<Kano> same for initrd
<Kano> those options are disabled currently for the kernel, initrd seems to be on
<apw> i've put lzma on my to investigate list
<Kano> # CONFIG_KERNEL_LZMA is not set
<apw> wanted this pushed as it carries fixes for bugs people are hitting
<Kano> best disable the doublicated ids too
<Kano> /sbin/modinfo -F alias rt73usb rt2500usb|sort|uniq -d
<Kano> only 4, a small patch
<Kano> disable in rt2500usb
<Kano> also i found an interesting patch for another wlan driver
<Kano> http://osdir.com/ml/linux-wireless/2009-05/msg01252.html
<Kano> that a common device in germany
<Kano> needs of course firmware
<_Chase> I need to add a patch to my stock ubuntu kernel for system stability and performance with regards to the cxx88-alsa module
<_Chase> I followed the guide at https://help.ubuntu.com/community/Kernel/Compile
<_Chase> but after installing, apt-get upgrade wants to replace my kernel with the stock one again
<_Chase> how do I get apt-get to not overwrite my new kernel?
<Kano> echo packagename hold|sudo dpkg --set-selections
<_Chase> I tried: echo linux-image-2.6.28-generic hold | sudo dpkg --set-selections
<_Chase> but apt-get upgrade still wants to reinstall linux-image-2.6.28-generic
<Kano> thats a meta package
<_Chase> sorry, I forgot the "-11" on 2.6.28-11
<_Chase> it seems to be ok now
<Kano> it would be very unlikely hat you updated a meta package ;)
<_Chase> I built the kernel, and it spit out linux-image-2.6.28-11-generic_2.6.28-11.42_amd64.deb
<Kano> yes thats the normal case
<_Chase> or are you meaning that 2.6.28 is meta, but 2.6.28-11 is a real package?
<Kano> yes
<_Chase> ok
<_Chase> is this the preferred way to add patches to ubuntu?
<_Chase> I assume on every new kernel release I'll have to do this again
<Kano> if you only need to build one module that does not affect others there might be a more tricky thing you can do
<_Chase> that would be my case
<Kano> first of all you compile the module out of tree
<Kano> and the next step would be adding it to dkms
<_Chase> are there instructions on how to do that?
<Kano> compileing a module is not that hard
<_Chase> I can probably build out of tree manually
<_Chase> yeah
<Kano> sure
<_Chase> the dkms step is more unknown
<Kano> thats correct, i am used to it now
<Kano> also i like to reuse mandrake dkms.conf file with little changes *g*
<_Chase> I think I didn't explain that right
<_Chase> I need instructions on how to use dkms
<_Chase> I've never used it before
<Kano> before you are at this stop komiple it without the kernel
<_Chase> I'm at work, but I know how to do it
<_Chase> I just need a reference for some documentation for dkms
<_Chase> is this it:
<_Chase> http://linux.dell.com/projects.shtml#dkms
<Kano> yes
<Kano> basically you copy your driver as /usr/src/driver-ver
<Kano> add a dkms.conf file, which is very easy for one module
<Kano> and then you add it to dkms
<_Chase> and when I upgrade kernels, does ubuntu automatically use dkms to rebuild the module?
<_Chase> or will I need to do something after I upgrade?
<akgraner> sconklin, Jono was just talking about you on Ustream and how it was you did the piro works for KISS how cool!  YOU ALL ROCK!!!
<sconklin> akgraner: I'll 'thank' Jono the next time I see him ;)
<akgraner> http://www.ustream.tv/channel/at-home-with-jono-bacon  check it out...:-)
<Kano> http://www.opensubscriber.com/message/linux-msdos@vger.kernel.org/9000939.html
<Kano> just had this issue, why is that value not 0?
<sconklin> akgraner: listening now, I'll go back and review the beginning later.
<akgraner> hey said the KISS Kernel...hahaha
<sconklin> akgraner: Keep It Simple Stupid
#ubuntu-kernel 2009-06-04
<StevenK> Hi, can I bleat at someone to update LBM so that -5 can be removed from Karmic, and to also update linux-meta so that -7 can be removed from Karmic? No fair having 4 different versions of the kernel in the archive.
<smb> StevenK, meta proably just waits for me to upload
<smb> apw, have you got a new lbm?
<StevenK> Last person to touch LBM was rtg
<apw> smb, no i'll have a look now
<smb> Look like it. 
<apw> i presume all i need to do is change the abi number
<smb> Probably just needs the abi version bump and be done
<smb> apw, ack
<apw> will give that poke now
<apw> then we can upload that, and meta
<apw> we like having lots of kernels in the archive, makes its nice a full
<smb> apw, poke me with that
<apw> will do
<smb> apw, btw. got a jaunty-pre-proposed ppa set up now. So someone needs the Jaunty with all the stable updates now can do so
 * StevenK grumbles at apw
<apw> smb, sounds good
<smb> https://launchpad.net/~stefan-bader-canonical/+archive/jaunty
<apw> smb, ok seems rtg didn't push his changes for lbm, will reconstruct
<smb> apw, Oh dear. Well I am away for an hour anyway... ;-)
<apw> _thanks_
<lamont> Jun  3 12:08:09 foo kernel: [482756.764829] [drm:i915_getparam] *ERROR* Unknown parameter 6 
<lamont> wassat? ^^
<smb> lamont, something asking the i915 driver an inappropriate question
<lamont> heh
<lamont> ok
<smb> Its from i915_getparam. It return EINVAL but prints also this msg. I'd say forgotten debug code or so.
<apw> from discussions with bryce it seems to be a benign missmatch between the kernel and mesa
<Notch-1> hi all
<Notch-1> news about CONFIG_BLK_DEV_LOOP ?
<nigelp> apw, the mainline kernel you pointed me to is a huge improvement.. not had a single kernel panic since I installed it this morning.
<Notch-1> so there is somebody in there, hello nigelp :D
<Notch-1> guyyyyyys? how can we talk with you if you do not reply on the channel nor on the mailing list?
<Notch-1> (nor on launchpad)
<manjo> Notch-1, what help are you looking for ? 
<Notch-1> oh thank you manjo, i'm so desperate, there is this problem with CONFIG_BLK_DEV_LOOP=y
<manjo> Notch-1, which kernel ? jaunty/karmic ?
<Notch-1> all loop-aes module users need CONFIG_BLK_DEV_LOOP=m or better =n, instead we need to recompile the kernel every update to use the loop module (that i use for the root filesystem, for instance)
<Notch-1> since jaunty
<manjo> Notch-1, let me look at the config... did u mail the ubuntu kernel list about it ? Most ppl were out last week for UDS so everyone is just catching up on backlog of mail
<manjo> Notch-1, your requirement looks fair, let me see if that can be resolved...
<mjg59> Notch-1: The issue was brought up on the mailing list, and a kernel dev asked why this code wasn't just upstream
<mjg59> I didn't see a response to that question
<Notch-1> yeah, i know, but is on launchpad since 3 month, and it's really difficult to talk to you guys :D anyway there is already a post: http://archives.free.net.ph/message/20090524.121638.72482e0d.en.html
<mjg59> Notch-1: Right. Amit then asked why it wasn't upstream.
<mjg59> And nobody replied to him
<Notch-1> mjg59: yes, i talk to them, i'm about to search info to answer on that question, but our question is different, it was just a second question...
<Notch-1> talked to him, sorry :P
<smb> It's already late, so I hopefully don't sound too grumpy. If I understood the things correctly you need loop to be a module to replace it with another module?
<mjg59> Notch-1: The answer is likely to be "It's not a priority to support out of tree kernel modules"
<Notch-1> i don't know why loop-aes is not upstream, i just know that many people use it
<Notch-1> yes but this configuration change is a big deal to us, and it's very simple to get back...
<mjg59> The main reason to build the loop module in is that it can't be easily autoloaded
<smb> The change was also to reduce module loads in favour of boot speed
<Notch-1> as i told to amitk i think that some peoples just don't like loop-aes and jari ruusu (his creator), i've got strange comments to them on some channel...
<Notch-1> yes, but we can't use a new custom module instead of loop
<mjg59> Notch-1: So?
<mjg59> Notch-1: Every configuration change is a tradeoff between different usecases
<Notch-1> so we need to recompile the whole kernel every update, to use a module
<mjg59> The aim isn't to break loop-aes, the aim is to reduce complexity, ensure that loopback devices are always available and slightly increase boot speed
<smb> If aes-loop completely replaces loop I wonder why it isn't a completely separate module. But maybe I did not understand that correctly
<Notch-1> yes but this change cutts off many people, and what is the time advantage? 1/100 sec?
<mjg59> Anyway, Fedora is configured in exactly the same way now
<mjg59> loop-aes should either stop conflicting with standard kernel functionality or get merged upstream
<Notch-1> smb: i don't know this, but i suggest to set CONFIG_BLK_DEV_LOOP to n and force anybody who needs the loop module to just install loop-aes... so more boot speed, and less throubles for everybody
<smb> Just to put off all users of the standard loop device?
<Notch-1> mjg59: you are right, but i'm just a user... and now i can't upgrade to jaunty....
<mjg59> Oh, right, I remember
<Notch-1> smb: with loop-aes they don't need the original loop module anymore...
<mjg59> Jari refuses to submit it upstream because he thinks the kernel developers are inept
<Notch-1> so only who needs loop gets the less boot speed... seems best for all
<Notch-1> mjg59: hahahahaha :D
<smb> But it would require all to get aes-loop instead of having the in-kernel one. 
<Notch-1> so it's personal, as i tought
<mjg59> Notch-1: No. That's why it's not upstream.
<mjg59> Notch-1: I should point out that I'm not an Ubuntu kernel developer
<Notch-1> smb: yes, but it's better to recompile the kernel every update
<smb> I am with mjg59 here. It should get upstreamed or stop being a conflicting module
<mjg59> But if you filed this against Fedora I'd close it WONTFIX
<Notch-1> smb: me too
<Notch-1> but you guys should stop conflicting :D
<mjg59> Notch-1: Uh. The project outside the kernel gets to avoid conflicting with the kernel.
<mjg59> Not the other way around.
<Notch-1> anybody should do his part :D
<Notch-1> with this system now me, a user, need to talk to the creator of a package that i need to convince him to get his module upstrem... it does not sounds right
<mjg59> Notch-1: No, that's exactly how it should be
<Notch-1> :D
<mjg59> Notch-1: If the developer of that external code refuses to work with the upstream kernel developers then it's his fault that users end up unhappy
<Notch-1> sure, easy
<mjg59> So the issue here is Jari
<Notch-1> or you should let us load any module without throubles, even if with a microsecond of boot delay
<mjg59> He needs to either change loop-aes so that it doesn't conflict with loop, or he needs to get his code upstream
<Notch-1> the issue is that your new configuration does not allow me to load a custom module
<Notch-1> the kernel HAS to allow anybodys code without throubles, that's democracy
<mjg59> Notch-1: The kernel isn't a democracy
<mjg59> Notch-1: It's better - if someone does something you don't like, then you get to change it as much as you want
<Notch-1> mjg59: so that's why it does not work :D
<Notch-1> the road it's not so easy if you change the configuration like this :D
<manjo> Notch-1, I think for now you are stuck recompiling the kernel 
<Notch-1> manjo: me too :Â°
<Notch-1> congrats guys, a very clean and usable system...
<Notch-1> linus would be proud :D
<mjg59> Linus would ask you why the code's not upstream
<Notch-1> :D
<Notch-1> still being proud of you :D
<Notch-1> anyway the loop-aes-source package description still says "It can be used with module-assistant, make-kpkg or stand-alone to build loop-AES module packages."...
<mjg59> Notch-1: That sounds like a bug in the loop-aes-source package
<Notch-1> yes, with this configuration now this is a bug
#ubuntu-kernel 2009-06-05
<mochaRHW> hello, quick question about the ath_pci.ko module in Jaunty
<mochaRHW> does anyone know what version of madwifi was used to build the ath_pci.ko in Jaunty?
<mochaRHW> modinfo says "D3FD3BD11169A96DBCFF8DE", that's not much help considering madwifi uses a 4 digit number to identify their svn releases
<amitk> mochaRHW: 0.9.4
<mochaRHW> just the official release version?
<amitk> mochaRHW: yes, we don't carry from trunk. And it is disappearing completely for Karmic
<mochaRHW> so it's being replace with ath5k in karmic?
<amitk> yes
<mochaRHW> I just had a hard lock last night with ath5k
<amitk> in karmic?
<mochaRHW> the only thing in my logs was a single message about the "noise floor" then 15 minutes later a hard lock
<mochaRHW> Jaunty
<mochaRHW> There's a bug report about it
<mochaRHW> anyway, I never had hard locks in Intrepid using an SVN version of madwifi
<mochaRHW> so I'm going back to that
<mochaRHW> but I wanted to ask you if you were using an svn version first, so I could confirm that i wouldn't be "downgrading"
<amitk> ok. but ath5k/ath9k are a lot more stable in karmic. Upstream now believes the drivers cover everything that madwifi did and more.
<mochaRHW> okay, so I'll use ath5k in karmic, I'm still on jaunty right now
<mochaRHW> thanks for your help, I just installed my svn version of madwifi that I was using in intrepid.
<n0yd> Any idea when this might be fixed? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/350695
<ubot3> Malone bug 350695 in linux "Linksys WUSB100 not enabled by rt2870 driver." [Undecided,Confirmed] 
<dtchen> apw: what are your thoughts on enabling CONFIG_PREEMPT in a karmic crack o' the day kernel?
<apw> dtchen, well i would generally prefer it was as similar to our config as possible, as that makes it the best test for the ubuntu kernel
<apw> what is the desire to get it enabled?
<dtchen> apw: testing for pulseaudio
<dtchen> apw: i've been troubleshooting with pa upstream for the karmic-desktop-audio experience, and we're attempting to match as much of the stacks between Fedora and Ubuntu as we realistically can
<apw> perhaps a specific kernel for testing that in a ppa would be approraite
<dtchen> apw: yes, that would work as well
<apw> if you tell me what you need i can put that together for you
<dtchen> apw: ok, i'll work on that over the weekend 
<dtchen> thanks!
<apw> no problem
<gonsolo> Hi. Is it possible that my DVB-T stick doesn't work after suspend2ram because its firmware isn't included in the initrd?
<gonsolo> it seems that the firmware can't be found because sysfs isn't mounted.
#ubuntu-kernel 2009-06-07
<Milan-BV> I'm trying to build my kernel from Ubuntu's PPA sources, and it looks like the debian/ dir is not included
<Milan-BV> I've copied it from git, but now it's starting manual config when I want to build it
<Milan-BV> any ideas?
<Milan-BV> anyone around willing to help about a strange OOM with plenty of swap left?
#ubuntu-kernel 2010-06-07
<kraut> moin
 * apw waves
<apw> morning lag 
<cking> morning
<apw> hi cking 
<ikepanhc> good morning
<apw> evening ikepanhc 
<ikepanhc> not evening yet - afternoon now
<apw> ahh :)
<ikepanhc> 15:38 here
<apw> ahh early you slacker :)
<lag> Morning apw ;)
<ikepanhc> :P
<psurbhi> good morning! o/
<apw> psurbhi, hi-ya, you recovered from the ubu-plague ?
<lag> Hey cking
<ikepanhc> good morning surbhi
<psurbhi> apw, not completely yet :( i have few tests lined up
<psurbhi> but good enough to work :-) so not too bad!
<ikepanhc> psurbhi: still sick?
<apw> psurbhi, thats cirtainly a bad one ... glad to hear you are getting well(ish)
<psurbhi> ikepanhc, a little.. but good during most of the day
 * psurbhi notes the ubu-plague ;) thats not the virus for sure
 * ikepanhc just confused about plugra and prague - thought why prague makes surbhi sick...
<apw> ikepanhc, heh
<ikepanhc> :P
<psurbhi> :D
<smb> morning .*
<ikepanhc> good morning smb
 * apw waves to smb
<ikepanhc> smb: I am rebasing hardy netbook-lpia branch, will send email when done, could you review for me?
<smb> ikepanhc, will do
<lag> Morning smb
<ikepanhc> smb: thanks
<ogra> amitk, why does maverick still have the lucid omap binary ... and apw why does the meta package still point to it ?
<apw> ogra, i would think the latter is triggering the former
 * smb also relates good morning to ogra 
<ogra> oh, and the package description of the new one is wrong, it talks about omap3 and 4, we will need two distinct binaries for that
<ogra> moring too, everyone :)
<apw> ogra, given we don't even have the omap4 ... indeed so
<ogra> apw, and if we have it the current patchset needs its own binary 
<ogra> (we'll need to have omap4 by A2)
<apw> ogra, i've not seen any omap4 code proposed as yet
<ogra> apw, well, cooloney will likely have to work on it (since 10.07 went happen)
<cooloney> apw: i missed some context here. 
<amitk> apw: any ETA for TI to give us a re-based patchset on top of maverick master?
<cooloney> apw: yeah, i got a omap4 branch but it is for lucid not maverick
<amitk> and good morning
<cooloney> amitk: morning, man
<apw> amitk, i've not been told any dates no
<cooloney> i don't know either.
<ogra> cooloney, so the good news for you is that a) i have a panda branch: http://gitorious.org/pandaboard/u-boot/commits/omap4_panda (should be only a few patches on top of the current omap4 kernel)
<apw> cooloney, are you owning omap4 for maverick or is that meant to be mathieu/lag ?
<ogra> cooloney, and b) we dont do 10.07 
<smb> apw, \o Gm, when the others are done I have a question, too
<cooloney> apw: i am going to do that. mathieu will own the omap thing in master branch. i think
<apw> ok then ogra i refer you to the omap4 owner cooloney  :)
<ogra> amitk, we were told they would rebase on to of our tree during this week, so i would expect something latests by beginning of next week
<ogra> apw, ^^
<apw> cooloney, seems we need something very very soon
<apw> ogra, i think we need to get cooloney plugged into the information stream you have from ti
<ogra> apw, the call is at an awkward time for him :(
<apw> ogra, ok, but we need to make sure he gets the info either way, as you know things he needs to be on top of :)
<cooloney> apw: yeah, normally i will email and irc contact with sebjan
<ogra> apw, thats why i gave him the info right now :)
<cooloney> apw: right, i need to sync up with ogra 
<ogra> apw, the decision to drop 10.07 was made friday evening 
<apw> ogra, sounds sane and will make smb happy
<cooloney> ogra: what's kind of decision? hehe. i just arrived at hugh and haitao's hotel, and wifi from the lobby
<cooloney> ogra: maybe i missed some info
<smb> Everything which is a S.E.P. makes me happy
<amitk> cooloney: NO LUCID OMAP4 KERNEL! :)
<ogra> right
<ogra> you can put your efforts into 10.10
 * cooloney feels someone punch his head to the iron door
 * smb immediately forgets about Lucid-ti-omap4
<cooloney> amitk and ogra, really? skip 10.07 ti-omap4 kernel 
<cooloney> and just 10.10 ti-omap4 kernel, right?
<ogra> right
<cooloney> and how about the time frame of this
<ogra> asap, but the ball is at TI
<apw> smb you are up
<smb> apw, Just wanted to check with you on the state of the upstream patches for the sync-time problem. I believe we said we will try to take the set of three and put it into the next proposed. I am not sure I missed something but I saw no mail or git update
<apw> smb, indeed somehow i didn't get to it
<apw> smb, i can look at it now
<smb> apw, Ok, awesome. Thanks
<amitk> dmesg
<amitk> erm, -EWRONGWINDOW
<ikepanhc> eh, looks like ecryptfs with chroot environment is a bad idea, I can not bind /home to chroot's /home
<anoteng> Hello, I'm git-bisecting a kernel, and all of a sudden the kernel image deb depends on linux-tools-kernelversion which of course does not exist. Is it safe to force the installation? What does the linux-tools packages do?
<apw> ikepanhc, heh
<smb> anoteng, Just supplies user-space half of some tools (perf afaik). For testing it should be safe to force
<apw> anoteng, i think you were pretty unlucjy there, pretty sure that that dependancy was not there for very long at all
<apw> anoteng, and yes you can ignore it and push the package harder
<smb> apw, pushed Karmic fsl-imx51 rebased to my current master
<apw> smb, ahh thanks ... am still building the comparisons ... as they broke the first time
<smb> apw, Something on master broke or the merge of abstracted?
<RAOF> Ok, so it seems that both 2.6.34-5 and 2.6.35-1 have a habit of panicking and then rebooting.  Is there a debug kernel I can install to make these events maximally useful?
<apw> smb, the first breakage was because the existing packaging actually is broken and does not make the contents of the docs package ... which does not work, a minor source tweak to the kernel itself sorts that out
<apw> smb, the second is because the new packaging produces the debug packages with the correct new names, which i'd not allowed for
<smb> Ah ok... Not nice but ok...
<smb> Hm... haven't I changed that already?...
<apw> smb, i am assuming we are happy to have the debug images have the new name ?
<Sarvatt> 2.6.35-1 is nasty, my netbook no longer goes into C3 on it and idles around 2x higher power usage :D
<smb> apw, Yeah sure. Ah, ok I only fixed the packaging to be using the contents of CurrentlyBuilding, not the naming
<apw> smb, ahh ok makes sense
<smb> Sarvatt, I think I saw a patch for that today
<Sarvatt> yea it was on master just before rc2 released luckily
<apw> Sarvatt, does not supprise me at _all_, noone should run an -rc1 kernel they are crack smoking messes
<apw> i am sure we'll be uploading -rc2 asap
<smb> apw, If noone would run -rc1, who would find the bugs. ;-P
<apw> s/noone/noone sane/  perhaps :)
<smb> heh
<Sarvatt> finding bugs gives me an excuse to learn more about what's broken, i don't mind :)
<apw> Sarvatt, yeah if i had more time i'd be like that too
<RAOF> So, is there a kernel debug package?  And if so, where is it? :)
<apw> RAOF, there is a a package with more symbols, nothing with more debugging code in it
<RAOF> The former was what I was expecting.  What's the package called?  âaptitude search linuxâ doesn't seem to pick up anything relevant.
<apw> RAOF, they are in the ddebs archive
<smb> Though I am not sure this is what RAOF is expecting. More for post mortem debugging and disassembly that more verbose output. Maybe saying debug on the kernel command line (instead of quiet) is enough for that purpose
<apw> RAOF, what are your symptoms on failure
<RAOF> The screen stops for about a second, perhaps getting distorted colours, and then the system shuts down.
<RAOF> Without the plymouth splash kicking in.  One of the lines is something along the lines of âkernel panic, restartingâ.
<RAOF> Basically what I want to do is to produce a useful bug for you, preferably without rebuilding my kernel a hojillion times.
 * cking-afk goes for some food
<apw> RAOF, ok so i'd first try booting without quiet and splash on your command line and see how that looks
<pgraner> tgardner: emerald is back in the rack
<Daviey> Hi, there seems to be bit of a kernel regression in current maverick that is potentially pretty critical for the server.  It seems to (oddly), caused a userspace issue of a *java* library not working as expected.  I don't know if it's related to entropy or something, but the function is handling en/de-cryption.  I would appreciate input, thanks :)  bug #588861
<ubot2> Launchpad bug 588861 in linux (Ubuntu) (and 1 other project) "Instances block in pending state, and don't start (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/588861
<Daviey> ^^ Unrelated to KVM.
<tgardner> pgraner, ack
<apw> Daviey, i suspect there will be an -rc2 kernel very shortly and that has to be less broken than -rc1
<Daviey> apw: that is great, do you think that will be this week?
<apw> Daviey, i'd say that is very likely
<Daviey> apw: awesome, thanks
<apw> its probabally not worth spending to much time debuggnig on -rc1 is really my feeling
<Daviey> apw: Ok, moving on :), thanks
<Daviey> apw: Whilst i'm here.....
<Daviey> Is there anything that can assist bug #576601
<ubot2> Launchpad bug 576601 in linux (Ubuntu) (and 1 other project) "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected (affects: 85) (heat: 588)" [High,Triaged] https://launchpad.net/bugs/576601
<Daviey> crikey, i notice there is now a bounty! 
<apw> Daviey, other than trying upstream releases like -rc2, probabally not a lot
<Daviey> apw: ok, thanks.
<anoteng> apw: thanks for your reply earlier. Didn't see it until now...
<smb> tgardner, apw *sigh* ok for the sake of simplicity I would squeeze in the sfc update into the same bug as 2.6.32.13. There don't seem other updates for that in .33. 2.6.34.y did not have a stable release, yet. So the other parts of this Frankenkernel had no counterparts, yet (beside of a lot of skipping for thinkpad-acpi)
<tgardner> smb, too late, I've already created a bug
<apw> smb, sounds ok
<smb> tgardner, Ok, we can decide that then in July
<smb> apw, Could you have a quick look and potentially ack or are you quite busy?
<tgardner> smb, bug #590783
<ubot2> Launchpad bug 590783 in linux (Ubuntu Lucid) (and 1 other project) "Lucid sfc stable updates from 2.6.33.4 (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/590783
<apw> smb, if it can wait about 30 mins i may be able to, trying to fix an install bug i think we are about to hit
<smb> apw, It can
<JFo> smb, do we do re-rolls of non-free firmware for older releases?
<JFo> by reroll, I mean do we update that package for them?
<smb> JFo, tgardner and cnd took care of that mostly. I think not too far back, but for LTS
<smb> Depends a bit on the driver too
<JFo> ah, my Q was in reference to the last comment in bug 387875
<ubot2> Launchpad bug 387875 in linux (Ubuntu) "Samsung N120 Realtek wireless fails in Karmic (affects: 4) (heat: 34)" [Medium,Confirmed] https://launchpad.net/bugs/387875
<cnd> JFo: is it marked against linux-firmware or linux-firmware-nonfree?
<tgardner> JFo, I consider those to be desktop issues, therefore encourage a more recent release
<JFo> tgardner, i thought as much
<JFo> thanks
<JFo> cnd, no it was against the linux pkg
<Keybuk> hmm, since the latest kernel update on maverick, my laptop can't connect to the wireless network anymore
<apw> Keybuk, is that using wl ?
<apw> NAME = Sheep on Meth
<apw> i note that 2.6.35 is names at above currently
<Keybuk> apw: iwl3945
<apw> Keybuk, no working from starbucks for you then
<Keybuk> known bug or not?
<tgardner> Keybuk, likely not, so you should try the mainline kernel as well, then complain upstream if its still not working.
<apw> ogasawara, yo!  you about ?
<ogasawara> apw: yep, just startin my day
<apw> ogasawara, ok you are going to his this build issue as soon as you rebase to -rc2 ... the one i was seeing last friday
<apw> i think i know the right fix now, just need a tree to do it to :)
<ogasawara> apw: cool, was going to apply any outstanding patches from the k-t ml and then rebase to -rc2
<apw> ogasawara, awsome, i'll push out a patch for it for you shortly
<ogasawara> apw: sweet
<cnd> JFo: I'd put bug 577114 as kernel-net since it's dealing with rfkill wifi issues
<ubot2> Launchpad bug 577114 in linux (Ubuntu) "Wireless and Bluetooth switch does not work correctly on lenovo ideapad s10-3 (affects: 2) (heat: 10)" [Medium,Triaged] https://launchpad.net/bugs/577114
<bjf> cnd, fyi: http://gizmodo.com/5556985/apple-multitouch-trackpad-peripheral-leaked
<cnd> bjf: yep, saw that this morning
<cnd> I usually read a live blog of wwdc keynote, so I'll see what it's all about
<ogasawara> JFo: I notice the top 50 bug list counts bugs which we've closed (ie Fix Released, Invalid, etc.)
<cnd> ogasawara: maybe they're bugs we've closed in the past week?
<ogasawara> JFo: would you prefer if I modify the script to show the # of open vs closed rather than the total
<cnd> his list is manually created
<ogasawara> cnd: right, I was just thinking along the lines that when the # goes above 50 it indicates we need to hammer on the list, but that's not exactly true right now
<cnd> ahhh, yeah
<apw> ogasawara, but that is in the 'added this week' section isn't it?  and those stay there
<apw> even when closed
<apw> fir t
<apw> for the week they were added
<manjo> bjf, http://people.canonical.com/~manjo/netbooks/
<ogasawara> apw: that's true, so I assume JFo will then go clear out the closed ones
<apw> ogasawara, he may need to be taght
<apw> smb, about
<apw> ?
<apw> ogasawara, i thought that in that table generator that the curernt week was always in full, and there was actually two tables 'this week' and 'the lot' and in the second table the closed ones are elided ?
<JFo> cnd, cool
<JFo> ogasawara, I can remove them during our meeting, I actually like them being there so that we can see what has happened over a week.
<ogasawara> apw: but for the top50 list we only have a single table
 * manjo otp ... brb soon...
<ogasawara> apw: that can obviously be changed though
<apw> ogasawara, i had assumed when i saw 'added this week' that this would work like the other one
<apw> if its easy to do it might be nice to keep that semantic
<ogasawara> apw: should be easy to add back the bits
<apw> ogasawara, no biggie
<ogasawara> JFo: I'll get you an updated script
<JFo> ogasawara, cool
<JFo> cnd, you joining us for bug chat or you busy?
<manjo> JFo, do we have a call ? 
<cnd> I'm going to join
<JFo> cnd, cool
<JFo> manjo, mumble
<JFo> http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
<smagoun> Anyone know much about power mgmt/batteries in ubuntu on apple hardware? I bought a 63 watt-hr battery for my macbook pro. /proc/acpi/battery/BAT0/info shows the design capacity is only 58000mWh, and last full capacity is 52000 mWh. How likely is it that those values are accurate? They don't match what I expect from the hardware.
<smagoun> (i'm on 10.04, fwiw)
<amitk-afk> smagoun: the question is does, MacOS show the capacity correctly?
<jjohansen> smagoun: they should be accurate
<smagoun> amitk-afk: good question, I dunno. Haven't booted macos w/ this battery yet
<smagoun> jjohansen: hmm, I just swapped in my old (OEM) battery, which is clearly labeled 60 watt-hr. /proc/acpi/battery/BAT0/info shows the design capacity is 56000mWh. At least the system is consistently wrong
<jjohansen> smagoun: I've never had a battery match its printed capacity, though they are usually have higher values, not lower
<smagoun> jjohansen: It's Apple kit, Think Different I guess
<amitk> doesn't a LiON battery require a few charge-discharge cycles to reach its pull capacity?
<amitk> *full
<smagoun> amitk: that shouldn't affect the design capacity, just the last full capacity
<amitk> true
<smagoun> 63 W-hr is 5833 mAh * 10.8v (the design voltage). That's pretty close to the reported design capacity (58000mWh). Any chance the hardware reports design capacity in mAh rather than mW? Where does the value come from, is it pulled directly from ACPI or is it calculated?
<jjohansen> smagoun: yeah I think it does actually report in mAh now that you mention it
<bjf> ogasawara, where is the source for the source_linux.py apport hooks ?
<ogasawara> it's in apport
<bjf> ogasawara, a "bzr branch lp:apport" does not give me the source_linux.py anywhere in the resulting tree
<ogasawara> bjf: I'd typically do a `debcheckout apport` and it should be in data/package-hooks/source_linux.py
<bjf> ogasawara, just did that and data/package-hooks only has "source_apport.py"
<ogasawara> bjf: hrm, not sure what's happened then
<bjf> ogasawara, thanks, i'll figure it out
<ogasawara> bjf: I'm seeing it here, but it's lucid.  http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/apport/ubuntu/files/head:/data/package-hooks/
<bjf> ogasawara, hmmm 
<bjf> ogasawara, i've been "bzr branch bzr+ssh://bazaar.launchpad.net/~apport-hackers/apport/trunk/" which doesn't get it for me
<manjo> apw, heh.. https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
<bjf> ogasawara, or even "bzr branch lp:~apport"
<ogasawara> bjf: not sure what the apport-hackers team is
<ogasawara> bjf: https://wiki.ubuntu.com/Apport - "If you want to contribute to it or develop your own system based on it, you can get your own branch with bzr get lp:apport for trunk, or debcheckout -a apport for the Ubuntu packaging branch."
<ogasawara> bjf: but then the "browse it online" link point to the apport-hackers
 * ogasawara is confused
<ogasawara> bjf: is that the upstream source?
<bjf> ogasawara, not sure what you are asking?
<ogasawara> bjf: just trying to figure out what the code shown in apport-hackers is
<bjf> ah, yes, that "seems" the latest and greatest
<bjf> ogasawara, a "debcheckout -a apport" got it for me, but I still don't understand
<manjo> psurbhi, long time no see 
<psurbhi> manjo, hie :)
<manjo> psurbhi, looks like you finally recovered ubuntuflu 
<psurbhi> hey, i did not have a ubuntuflu and nor have i fully recovered.. infact i have to do some tests to eliminate further infection :) 
<psurbhi> so will soon find out if i am out of it or not :)
<manjo> psurbhi, sorry to hear that... looks like it got you good this time 
<psurbhi> :-/
<manjo> psurbhi, will you be in shape to attend the platform sprint ?
<psurbhi> manjo, yes! i think so... so we can meet up then!
<manjo> psurbhi, yep
 * manjo out for lunch
<apw> JFo, ok ... i've put together a very basic todo and style guide linked from the Kernel page
<JFo> cool
 * JFo goes to peruse
<apw> JFo, what do you think about mixing debugging and testing together, or does that need its own section ?
<JFo> hmmm
<JFo> I actually like that idea
<amitk> apw: do you start editing 20 pages at once and do an atomic save?!
<JFo> as there will be parts pertinent to both
<amitk> *wiki pages
<apw> amitk, heh no why ?
<amitk> apw: just wonderig about the 10 emails with wiki updates from you :)
<apw> amitk, ahh no just incompetant
<amitk> hehe
<JFo> looks great apw, I especially like the current layout of both the todo and the gardening guide
<apw> JFo, so what do you think about testing?  should i add it to debugging?
<apw> or perhaps we could have a longer list of topics on the front page
<apw> and that could be one of them
<apw> JFo, i think i'll mock that up for testing and see how it looks
<JFo> hmmm
<JFo> ok
<JFo> maybe we will need to have testing and then set up debugging links from the testing bit?
<JFo> I'd really like for testing to be a bit separate from debugging, i think
<JFo> I could be completely wromg though
 * JFo heads to a quick lunch
<apw> JFo, i'll treat it separate, we can have a full list of areas on the front page, but only links in the menu to those which are critical and commonly used
<apw> see the current front page for what i mean
<JFo> yeah, I like having that in the Topics section
<apw> JFo, ok i've added that to the documentation and copied over the testing topics
<JFo> sweet
 * JFo goes to grab that lunch now
<pgraner> ogasawara: ping
<ogasawara> pgraner: pong
<pgraner> ogasawara: [14:09] <robbiew> pgraner: looks like broadcom (STA) driver is busted on latest maverick kernel (2.6.35)
<pgraner> [14:10] <robbiew> I'll file a bug, just an fyi
<pgraner> [14:10] <robbiew> DKMS crapping out on building the module...works fine in the previous 2.6.34-5 kernel
<robbiew> :)
<ogasawara> robbiew: can you point me to your bug# so I can keep it on the radar
<pgraner> ogasawara: I have notified the proper authorities
<JFo> heh
<robbiew> will do..need to recreate so I have stuff to post :)
 * robbiew finds his ethernet cable :/
<ogasawara> heh
<pgraner> tgardner: any idea when henry will get the OSS driver free?
<tgardner> pgraner, I asked him that just last week. He said he'd let me know as soon as possible. kind of vague.
<tgardner> I've been pushing himto get it available in time for Maverick
<pgraner> tgardner: yea, would be nice if they gave us some beta code to test, I'm sure we would help this whip it into shape, would be nice to have it this early in the cycle
<robbiew> ogasawara: bug 590924
<ubot2> Launchpad bug 590924 in linux (Ubuntu) "Broadcom STA (bcmwl) driver fails to build with 2.6.35-1 kernel (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/590924
<ogasawara> robbiew: thanks
<robbiew> ogasawara: I'll leave it with that version if you all need me to do any testing or log grabbing
 * robbiew used ubuntu-bug, so you should have all the standard files
<jjohansen>  -> Lunch
<ogasawara> robbiew: just want to check, were the dkms errors you saw the same as http://launchpadlibrarian.net/49811242/DKMSBuildLog.txt
 * tgardner wished we could stop packaging wl
<tgardner> wishes*
<manjo> JFo, I marked BGug #564051  as invalid, can you remove bugs marked invalid from your top 50 list ? 
<robbiew> ogasawara: I never saw that on the screen...is there a logfile I can check?
<ogasawara> robbiew: do you have anything under /var/lib/dkms/bcmwl/<version>/log/make.log ?
<kees> ogasawara: do you know which of the maverick CVEs have been fixed?  http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html
<kees> ogasawara: I want to get the tracker updated
<ogasawara> kees: let me try to get a list together for you as we split them up amongst stefan, surbhi, and myself
<kees> ogasawara: ah, cool.  I wasn't sure if maverick was being done the same way as the stables.
<ogasawara> kees: typically for maverick smb will tell me which one's I need fixes for.  but assuming if they're already upstream I might not need to do anything.
<kees> ogasawara: yeah, that where I'm a bit lost.  I assume nearly all of them are fixed, but finding them isn't always obvious to me.
<robbiew> ogasawara: okay...exact same text
<robbiew> except mine was ALL in english
<robbiew> no cyrillic 
<robbiew> lol
<ogasawara> robbiew: cool, thanks :)
<ogasawara> kees: http://pastebin.ubuntu.com/446324/
<ogasawara> kees: a few I marked not-affected? based solely on the CVE description but I didn't dig any further to officially verify
<ogasawara> kees: so you may want to actually mark those needs-triage just so we can double check
 * bjf[afk] will be back later
<kees> ogasawara: cool, thanks
<kees> ogasawara: I validate the ones you had question marks on; all not-affected.  :) wheee
<ogasawara> kees: sweet
<kees> er, validated.
#ubuntu-kernel 2010-06-08
 * apw yawns
<RAOF> Good morning!
<jk-> heya apw, RAOF.
<apw> RAOF, heya, jk- evening!
<apw> RAOF, did sconklin drop you a line about the lid detect bug ?
<RAOF> apw: Indeed he did.  I've replied, and cc'd you.
<apw> ahh then i'll read m'email
 * apw shouts at compiz which has dumped twice in two days
<RAOF> apw: In short, I think it's possible to fix in a way that would minimise regression potential, and be acceptable upstream, but requires more work than the pseudo-patch I dumped in the bug.
<ikepanhc> good morning .eu
<apw> afternoon .ap
<ikepanhc> .ap?
<cooloney> ikepanhc: as you are maintaining the #hwe tree, i got a question for you
<cooloney> ikepanhc: when we got a new board defconfig and some small patches to enable a new board, 
<cooloney> ikepanhc: do you just add a new flavor or something else
<ikepanhc> cooloney: for a custom kernel, its another branch, so I will have a new debian folder
<ikepanhc> cooloney: and restart the abi/changelog/flavour
<cooloney> ikepanhc: ok, creating a new debian.project folder
<ikepanhc> cooloney: yeah
<cooloney> ikepanhc: and if you got a new board which can be fitted into this project
<cooloney> shortly, this project has 2 boards,
<cooloney> board-a and board-b
<cooloney> will you create 2 flavors for that?
<ogra> cooloney, if you are tlaking about the omap4 kernel above, the same omap4 kernel will run on both boards, dont bother with fiddling with different flavours
<cooloney> ogra: the panda board use is own config file instead of the original one omap4_sdp_defconfig.
<ogra> that will change
<ogra> just ignore omap4_sdp_defconfig for that build 
<ogra> and use the panda one
<cooloney> ogra: and we cannot generate 1 kernel to support that 2 boards. i just got a compiling failure
<cooloney> ogra: yeah, that's what i am doing. 
<ogra> TI said it will be one kernel
<cooloney> thanks for heads up
<ogra> probably not yet though :/
<cooloney> ok, it guess it will be panda, not sdp
<cooloney> no problem
<ogra> yes, main target is panda for 10.10 anyway
<cooloney> and one another thing is the panda config also got a problem
<cooloney> it built in both 8250 serial and omap serial driver
<cooloney> weird
<cooloney> i am still working on that
<Kano> apw: is it possible to change options based on enforce?
<apw> Kano, not currently is purely a check and abort function right now
<Kano> so how do you change options
<apw> Kano, add the new values by hand and updateconfigs normally
<Kano> where to put the .config ?
<apw> there is a file called OVERRIDES you can put them in _temporarily_ then run updateconfigs, then remove it
 * cking wonders if that's documented anywhere
 * apw knows it is not, though the source is pretty easy to read
<amitk> apw: our build system is not an easy read anymore (for newcomers) :)
<apw> amitk, bah of course it is :)
<amitk> apw: that's like saying that "War and peace" is an easy read
<amitk> :-p
<ericm|ubuntu> apw, amitk, is there any easy way to extract the scripts of updateconfigs quickly into a separate script, so that multiple _defconfig can be used as input and a common.config and a bunch of <flavor>.config as output?
<ericm|ubuntu> I guess that seems to be very useful for the ARM _defconfig mess we are now facing with
<apw> ericm|ubuntu, the processing works in that manner internally
<apw> there is a script to apply to a directory of configs
<ericm|ubuntu> apw, which one?
<ericm|ubuntu> splitconfig.pl?
<apw> yep
<apw> kernelconfig uses it so you can see how to
<ericm|ubuntu> apw, thanks man - I'll take a look
<amitk> ericm|ubuntu: while it is worth looking into, I don't have high hopes that it will find too much common stuff.
<ericm|ubuntu> amitk, well at least find a base to start the merge with
<ericm|ubuntu> amitk, though I guess won't be very optimal
 * amitk nods
<apw> ogasawara, yo ... hows -rc2
<ogasawara> apw: bah, I sent you email but looks like it didn't go out.  /me re-sends
<apw> ogasawara, heh thanks
<bjf> pgraner, cking needs http://www.bluemic.com/snowball/
<pgraner> bjf: heh
<cking> bjf, I probably need to write a driver for the snowball before I can use it
<bjf> cking, it works on a mac, and that's just like linux, i don't think there would be a problem
<cking> bjf, you being funny?
<bjf> cking, yup
<Zhenya> hi guys!
<Zhenya> i am having lots of fatal kernel panis
<Zhenya> panics
<Zhenya> lol
<Zhenya> It hasn't done it today yet, but once i switch to dual screens and run some music, i feel like its guaranteed in an hour or so
<Zhenya> if someone would help it would make my machine much more usable :/
<Zhenya> anyone?
<JFo> Zhenya, do you have a bug filed about the issue?
<Zhenya> JFo: no i do not as i dont even know how to get all the details except for dmesg and i wanted to make sure it wasnt my hardware
<Zhenya> (however this did NOT happen when i was on 9.10)
<JFo> you can run ubuntu-bug linux from a terminal window
<JFo> it will gather all that we need
<JFo> so the command
<JFo> 'ubuntu-bug linux'
<Zhenya> do i just wait for it to then panic?
<Zhenya> oh cool!
<Zhenya> which is this?
<Zhenya> kernel config? filesystem?
<Zhenya> other?
<JFo> what do you mean?
<JFo> this pulls all the data we want and opens a bug on Launchpad
<Zhenya> gotcha
<Zhenya> nm
<Zhenya> thanks for showing me this!
<JFo> my pleasure :)
<Zhenya> JFo: in case you want to check it out :D https://bugs.launchpad.net/ubuntu/+source/linux/+bug/591330
<ubot2> Launchpad bug 591330 in linux (Ubuntu) "Kernel panic - random (affects: 1) (heat: 6)" [Undecided,New]
<JFo> thanks, I'll take a look in a bit :)
<bjf> ##
<bjf> ## Kernel team meeting in 55 minutes
<bjf> ##
<Zhenya> JFo: next time my machine crashes should i grab the dmesg right after the crash and attach it to the log also?
<Zhenya> log=bugreport
<JFo> sure, that is helpful indeed
<Zhenya> ok great.i am awaiting the caps lock wink of death
<JFo> heh
<JFo> apw, did we ever explain the new bug process to cking?
<apw> JFo, dunno cking ?
<JFo> hmm
<JFo> I can't remember us discussing it with him
<JFo> and I just realized that there are a few in need of review that he may not be aware of
<JFo> kernel-acpi bugs that is
<cking> JFo, I'm not aware of what was discussed, got a brain like a sieve at the moment anyway, so is it documented?
<JFo> heh
<JFo> yeah, lemme dig it up
<apw> more work for cking ... yay
 * cking sinks
<JFo> heh
<cking> glub glub
<JFo> so here are the new tags we crated, did you see them cking? https://wiki.ubuntu.com/Kernel/Tagging
<JFo> we used your name in vain for one
<cking> cool - all the yummy ACPI goo
<JFo> yep, there isn't much
<JFo> here is the rough idea of the process https://wiki.ubuntu.com/Kernel/BugReview
<cking> JFo, that's coherent - great!
<JFo> :-)
<JFo> let me know if you have any questions
<JFo> we are still working out the bugs so to speak
<cking> no - it's easy peasy to use - thanks for making it fool proof
<JFo> well, we try :)
<ogasawara> jjohansen: so I'm sue you saw, but I've rebased our maverick kernel to 2.6.35-rc1 and will soon be pushing our rebase to 2.6.35-rc2...
<JFo> the big thing is to make it super easy for you guys to get relevant and timely bugs to have a look at cking 
<ogasawara> jjohansen: in my rebasing I spaced on dropping any AA patches like we'd discussed.
<ogasawara> jjohansen: will that be an issue for you in bringing us up to date with the latest AA patches for 2.6.35
<JFo> and the top 50 list at http://qa.ubuntu.com/reports/jfo/kernel-Top50.html is so you can have a look  at the overall workload
<jjohansen> ogasawara: yep, its not a problem
<ogasawara> jjohansen: cool, phew
<jjohansen> ogasawara: we can either drop them separately or, patch on top, which ever works best for you
<jjohansen> ogasawara: probably best they didn't get dropped just yet anyways as I have some compatability bugs to work out
<ogasawara> jjohansen: cool.  doesn't make much of a difference to me if we drop them separately or just a patch on top.
<jjohansen> okay, I'll probably drop and do a clean import for you as that will give a nice clean history
<ogasawara> jjohansen: sounds good
<sconklin> I just took a lucid update and now my machine won't boot. I'll let you know what I find out.
<JFo> nicew
<JFo> s/w//
<sconklin> ok, It's not catastrophic. It boots fine when the external USB drive isn't attached.
<tgardner> sconklin, does it have abootable partition?
<Zhenya> JFo: ok i just had a panic
<Zhenya> and i got the dmesg
<Zhenya> should i pastebin it?
<JFo> put the file in the bug please
<JFo> sconklin, I seem to recall someone else seeing that issue as well
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
 * JFo reasies for the meeting
<JFo> redies*
<JFo> sigh
<JFo> I give up on typing for today
<tgardner> JFo, crack your knuckles
<JFo> oh wow... wonder how long I have needed that
<JFo> oh yes, hands are working much better now :)
<JanC> Zhenya: best attach it to your bug report so that it doesn't get lost
<Zhenya> JanC: ok i will do it! i rerequested my password from launchpad and its taking forever to get here.....
<JanC> heh, how did you upload an hour ago without that password?  âº
<Zhenya> i had one
<Zhenya> and i tried using it and it DIDNt work right now
<Zhenya> i know i had the right password, very weird....
<sconklin> http://www.webson.co.za/complete-guide-fixing-grub-error-17/
<JFo> cking, that is by far the BP that has me most excited
<cking> JFo, the BIOS testing one?!
<JFo> yep
<cking> your're welcome to get the sources, build it, use it and give me feedback ;-)
<Zhenya> JFo: still no password, do you have the correct permissions to attach things to the bug reports?
<manjo> apw, do you want us to put names along side the todo items ?
<JFo> yes, if you are going to be doing that item
<JFo> cking, I may do that
<apw> manjo, thats what the instructions say yes
<JFo> I am eager to see what it does in the testing ISOs
<manjo> apw, AH instructions :) 
<apw> bjf, can you remember what smb calls his 'manual' for stable
<apw> he has a nice name i think
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - June-15 - 17:00 UTC
<bjf> apw, yes
<bjf> apw, https://wiki.ubuntu.com/KernelTeam/StableHandbook/UpstreamStableReview
<cking> JFo, I'd better write a README file then ;-)
<apw> bjf, and what does he call it
<apw> handbook, thank you
<apw> JFo, i think we need a Handbook section of the Kernel wiki
<JFo> cking, yes please :)
<bjf> apw, was getting the url from bookmarks
<apw> for those sorts of things
<JFo> apw, I agree
<apw> bjf, sorry i was not actually thinking of the URL though it has the information :)
<JFo> I think that is massively useful
 * bjf thinks we need some user experience people to help design the kernel wiki pages (maybe a useability study or two)
 * manjo getting lunch will be back soon
<JFo> I think that is a thumping good idea bjf
<JFo> work the layout flow out and all
<jaminc> my laptop appears to be periodically rebooting as a result of a kernel crash...  however most attempts to submit the requested bug report for the kernel crash result in a "HTTP Error 500: Internal Server Error" response after several minutes trying to upload the data.  Is there any other way I can report this problem and provide the necessary data?
<JFo> I think you are encountering the same issue as Zhenya jaminc 
<JFo> there seems to be some kind of server issue
<jaminc> k... wasn't sure if it was me or the server... it's an annoying issue... leave the system for a while and come back to find it rebooted at the login screen... no idea why... only report I have successfully uploaded indicated that my kernel was too old, though I'm pretty sure it was the most current at the time
<apw> JFo, as we do not have any advanced topics i wonder if we should make 'Advanced' into 'Other'
<apw> then have essentially the same list of topics under 'Topics' on there
<apw> hrm, perhaps not, what does that get me
<lag> Right, that's me! Night all.
<lamont> Jun  8 11:16:07 rover3 libvirtd: 11:16:07.449: error : udevStrToLong_ui:73 : Failed to convert '008' to unsigned int#012
<lamont>  wtf is up with that
<cking> tgardner, not sure if that patch will work - doesn't the pcmcia_request_irq require interrupts to be enabled to detect the IRQ probing?
<tgardner> cking, as far as I could tell it did not. everything was just I/O reads and writes.
<cking> tgardner, ok - well, then I'm very happy with it ;-) Thanks for picking this up - I'm the slacker
<tgardner> cking, lets see if it actually works :)
<cking> tgardner, if it does, the same code should be applied to a bunch of those drivers that use the same probing/config methodology 
<apw> lamont, odd isn't it, i saw that when testing kvm myself.  i had assumed it was a udev/libvirtd interaction
<apw> lamont, and therefore blamed kirkland 
<Zhenya> JFo: you mean on launchpad or kernel wise?
<apw> tgardner, i think your script which adds ~lucid1 has gotten a little out of hand as its adding them everywhrere there is a ) ... should only apply on lines which do not have whitespace as the first character
<cking> JFo, I've dumped a readme file in the top level of the test suite - it's ready for you to play with
<bjf> pgraner, if I go to http://voices.canonical.com/kernelteam/ i'm not getting any of the links on the right side of the page (so I can't go to admin and post) 
<bjf> pgraner, is it working for you?
 * pgraner looks
<pgraner> bjf: nope
<tgardner> apw, I had that fixed once. sed '1s/..../
<apw> tgardner, hrm well its unwell again i am afraid
<tgardner> apw, no worries. I'll figure it out.
<tgardner> apw, fixed and pushed
<apw> tgardner, cool
 * cking attends to kids - seeya tomorrow
<Zhenya> JFo: still no way to access launchpad
<jaminc> Zhenya, what problem are you having accessing launchpad?
<jjohansen> -> Lunch
<cnd> hooray! I think I'm finally out from under pm-utils work :)
<cnd> twas a little more than I bargained for when I took it over at the end of the lucid cycle...
 * bjf is here
<apw> pgraner, is emerald ok
<tgardner> apw, no tyler either
<apw> yet pgraner is here ... odd
<methril_work> is here the proper place to ask for linux rt kernel?
<methril_work> i see some updates in the rt preempt patch taht are not reflected with the rt kernels
<apw> methril_work, abogani is the man for those kernels, though they are not here at the moment
<methril_work> apw: thanks. Do you know his time zone?
<apw> i think .eu though its sometimes hard to tell as that might be his off work time
<methril_work> apw: iÂ´ll try to catch him later
<Zhenya> jaminc: cannot log in or retrieve password
<smoser> anyone around who can answer a quick question before i open it as a bug ?
<smoser> jjohansen maybe 
<jjohansen> smoser: whats up
<smoser> i'm playing around with eucalyptus, and attaching a bunch of EBS block devices , detaching them, reattaching them.
<smoser> the block devices get (in udev) KERNEL=/dev/vda at first
<smoser> then vdb
<smoser> then vdc .... vdz
<jaminc> Zhenya, hmmm can do both here... simply can't submit a kernel crash bug report
<smoser> they are never re-used
<jaminc> JFo thought we might be experiencing the same issue, but doesn't seem to be
<Zhenya> jaminc: gotcha.i think they are ahving server isssues
<jjohansen> smoser: hrmm, that seems wrong
<smoser> my experience with other busses (scsi) is that when a block device was detached, and then reattached it would be freed.
<smoser> ok. i'll open a bug. just wanted to make sure it wasn't obviously working as expected from the kernel perspective.
<jjohansen> yeah, that is generally the case
<jaminc> smoser, esata doesn't reuse unless you explicitly tell the kernel to delete it
<smoser> hm..
<jaminc> try echoing 1 into /sys/block/${DEV}/device/delete
<jjohansen> right there are some exceptions
<jaminc> that's how I get the kernel to remove the old esata devices
<smoser> well, i'll open a bug, and let kernel deal with it.
<jjohansen> smoser: subscribe me to the bug
<smoser> jaminc, well, there is only at this point a /sys/block/vdag entry (no others)
<smoser> so presumably i'd have to do that before the entry was removed.
<smoser> maybe thats housekeeping that udev is supposed to do ?
<jaminc> hmmm I'd think the device names would be reused if the entry no longer exists...
<jaminc> is there a time limit on uploading lauchpad bug data via apport?
<smoser> jjohansen, bug 591469
<ubot2> Launchpad bug 591469 in linux (Ubuntu) "virtio block devices names are not recycled (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/591469
#ubuntu-kernel 2010-06-09
<bjf[]> exit
<bjf[afk]> -EWRONGWINDOW
 * apw yawns
<RAOF> apw: You should sleep in, then :)
<apw> pgraner, frylock is off the world ... for the 3rd time in two days ... both links to nowhere
<apw> pgraner, actually dsl and ubuntu point to the same IP address ?
<kraut> moin
<ikepanhc> ouch, sent a empty subject to k-t list
<ericm> ikepanhc, yeah - but fortunately it didn't end up in my spam box
<apw> cking, morning ?
<ikepanhc> ericm: ya, fortunately.
<ericm> ikepanhc, it's quite old kernel, why the building issue was revealed recently?
<ikepanhc> ericm: oh, the compile error happen after rebase to lastest hardy master branch
<ericm> ikepanhc, I see
<ikepanhc> ericm: it wasnt there last week
 * apw pokes pgraner 
<ikepanhc> apw: good question on lquest - I dont think we need lguest on netbook branch
<ikepanhc> s/lquest/lguest
<ericm> apw, I cannot connect to pgraner's machine, what about you?
<apw> ericm, indeed been down all morning
<cooloney> try tyler
<apw> i think both are out 
<ericm> apw, I guess helena is also down
<apw> ericm, that has been announced as down, the machine is going to boston
<apw> but it has been 6 damn weeks in transition
 * ericm has to build a kernel on his tiny mini fan-noisy slow machine now
<apw> pgraner should be awake within the hour and we should get .mills back
<ericm> any one has hint for the error below: ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored.
 * ericm is doing a fdr binary
<ikepanhc> ericm: I just ignore the error message. fdr binary still give me the linux-image.deb and the deb works
<ericm> ikepanhc, you are having the same issue? interesting - this never happens on pgraner's machine (never noticed the release difference though)
<apw> ericm, i've seen that before i think but cannot remember what it was about any more sorry
<cooloney> ericm: i got that error several times
<cooloney> ericm: so a) sudo su to get root to build the package
<cooloney> b) sbuild
<cooloney> that's might be a issue from fakeroot upstream
<cooloney> i found that bug was tracked in debian's bug list
<smb> lag, Hey just wanted to let you know that your "make perf more useful in case of error" change likely sneaks into Lucid anyway when apw does his abstracted magic. :)
 * smb waves to apw
<apw> smb, indeed so ... its in the ones i am test building now
<lag> Good news :)
<smb> apw, Did I expect too much or is there only Karmic master updated for now? I fetched but only master changed...
<lag> Will my "fdr editconfigs" change get in?
<smb> I believe to have seen that too
<apw> smb, i thought the plan was i did master, you tie the bow on that than we can rebase the others and do them too
<apw> (ie. i can rebase them during the day)
<smb> apw, I think you are right
<apw> the plan may be flawed but i think that was the plan
<apw> pgraner, ping
<smb> apw, Meh, I think its alright. I do the ties and push, can I hand test building that to you?
<apw> smb, yep... i have to build it anyhow
<smb> Doh!
<apw> doh ?
<smb> apw, You surely have
<apw> yep ... _if_ the build boxes come back of course so i can free up my local box for it
<smb> apw, And me just making little updates to the changelog won't break that
<apw> there is that too, though i thought there may be more updates coming for -proposed for karmic i forget
<smb> apw, No, I know nothing more for KArmic
<apw> i'll re-test buuld it once i have a free box anyhow
<smb> apw, You have something with the bow tie on when you pull
<apw> smb, thanks
<smb> apw, Thanks for going through the rebases. I think to remember there will be a little fallout with the debian.env when doing those. Anything else to expect? Or simpler let me know what happens. :)
<apw> i think it was simpler than i expected actually, but yes will let you know
<ogra> were the omap3 udeb changes for lucid already uploaded before the new d-i was uploaded yesterday ? 
<ericm> smb, reviewing the DOS CR/LF format issue with Marvell code, it looks like a _too_ big issue, (https://pastebin.canonical.com/33183/)
 * apw doesn't remember any omap3 stuff aimed at lucid
<apw> ogra, the bug we had was for maverick was it not
<ogra> the missing USB NIC drivers in udbes ? 
<ogra> *udebs
<ogra> no, that was lucid omap3
<ogra> fixed several weeks ago by mpoirier
<apw> that i don't think i remember that at all, presumably someone else was dealing with that, so ignore me
<ogra> LP#588805: enable armel-omap udebs for netboot use
<ogra> you commented on it 6 days ago
<ogra> oh, though thats a different bug number
<ogra> bug 584920
<ubot2> Launchpad bug 584920 in linux-ti-omap (Ubuntu) "netinstall fails, it has no network driver for moschip (affects: 1) (heat: 264)" [Medium,Fix committed] https://launchpad.net/bugs/584920
<ogra> pull request from may 27th
<ogra> ~two weeks ago
<ogra> since thats stuff needed for netinstall, having it in before d-i gets rebuild is essential
<ogra> else it makes no sense :)
<cooloney> ericm: try dos2unix?
<apw> ogra, i would not be supprised if its not yet uploaded, as we have been under -security for the last 3 weeks
<ogra> hrm, k 
<ericm> cooloney, yeah - but the format itself isn't a big issue, a noisy patch and the problem of application of subsequent patches would be the biggest issue
<apw> the SRU process is not in the least bit determininstic time wise especially when -security pops up its ugly head
<apw> ogra, if your patch has a bug link in it then its not showing up on ti-ompa
<ogra> yeah, understood
<ogra> ompa lompa :)
<ogra> its not my patch
<ogra> https://lists.ubuntu.com/archives/kernel-team/2010-May/010757.html
<ogra> the ,mail had a buglink
<ogra> and according to smb it was applied to the tree two days ago
<apw> ogra, ok found it ... it'll be in the next upload, its right at the tip of the tree
<ogra> i just dont know if it went in with an upload
<ogra> ok
<apw> thats post -security which is only just in
<ogra> ok
<ogra> no prob then, i just want to know what to tell users that ask 
<ghostcube> hmmm ureadhead still gets killed for me at startup :) is there anything known about
<cking> ghostcube, i think it's known about: bug 491943
<ubot2> Launchpad bug 491943 in ureadahead (Ubuntu) (and 1 other project) "Kernel trace buffer should be set to less unrealistic value (affects: 11) (dups: 2) (heat: 54)" [High,Triaged] https://launchpad.net/bugs/491943
<ghostcube> cking: thx looking :)
<ghostcube> hmmm yeah my system has 4 gig mem too 
<ghostcube> looks nearly the same must check this athome later thx for the bug
<cking> my pleasure
<ericm> apw, what if I want to change a blueprint to M+1 (it was target for M, but apparently the topic/work grows more than that)?
<apw> ericm, is there work in M still?  if so leave it as it is, but then move the target on the blueprint front page to N when that starts existing
<ericm> apw, what do you mean by "when that starts existing"? after UDS-N?
<apw> i am not sure uds-n even exists as a goal really
<apw> as yet
<ericm> apw, no - checked and not available in the drop down box
<apw> just put the work-items which flow out under like
<apw> Work Items for NN:
<apw> or something which won't match our current release, and they will not show up
<ericm> apw, I see
<apw> arm work going to take forever ?
<sebjan> Hello, I am wondering if BUG 507503 was fixed in .34 upstream (I see some patches from .34). Anyone to confirm? Thanks!
<ubot2> Launchpad bug 507503 in linux-ti-omap (Ubuntu Lucid) (and 5 other projects) "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes (affects: 1) (heat: 10)" [High,Fix released] https://launchpad.net/bugs/507503
<pgraner> cooloney: ping
<cooloney> pgraner: hey, pete
<apw> sebjan, i thin that was fixed upstream yes, i am pretty sure it was a backport in our trees
<pgraner> cooloney: hey some one was asking about an OMAP bug in the scroll back:  [09:32] <sebjan> Hello, I am wondering if BUG 507503 was fixed in .34 upstream (I see some patches from .34). Anyone to confirm? Thanks!
<ubot2> Launchpad bug 507503 in linux-ti-omap (Ubuntu Lucid) (and 5 other projects) "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes (affects: 1) (heat: 10)" [High,Fix released] https://launchpad.net/bugs/507503
<pgraner> cooloney: and apw just answered
<pgraner> cooloney: so never mind
<cooloney> pgraner: thanks for ping me this. hehe
<cooloney> apw is a nice man, always help us
<cooloney> apw and sebjan, the patch we backported into our lucid tree might be different from upstream. I need to double check
<cooloney> since at that time, we applied the patch from arm mail list
<cooloney> but it might be changed a little bit after rmk reviewed before it entered upstream mainline
<sebjan> cooloney: yes, the lucid backport is different, and the .34 upstream contains the latest patch revision (v5) discussed in this thread: http://thread.gmane.org/gmane.linux.ports.arm.kernel/58722/focus=58724
<cooloney> sebjan: got it, thanks for heading up.
<cooloney> sebjan: i think the upstream version is the right one, in lucid, we just wanna fix the bug in .31/.32/.33 kernel
<cooloney> sebjan: so if you rebase the on .34, you can ignore that backported VFP patches. 
<sebjan> cooloney, apw, pgraner: thanks guys for checking!
<sebjan> cooloney: yep, this is what I did, and wanted to confirm as the patch content did not seem obvious to me :) Thanks!
<JFo> moin bjf 
<bjf> JFo, i'll take your word for that
<bjf> bjf, not awake yet
<JFo> speaking of which...
 * JFo goes for more coffee
<tgardner> ogasawara, please hold off on my LP591416 pull request. I'm working with upstream to build a better solution.
<statik> hi hi
<statik> one of my colleagues is having trouble with an e1000e on the maverick kernels (works fine in lucid)
<statik> I wanted to see whether the patch talked about in this thread was in the maverick kernel already http://kerneltrap.org/mailarchive/linux-netdev/2010/5/11/6276964
<statik> i'm kinda ignorant about kernel stuff, what is the right way for me to get the tree for the ubuntu kernels?
<tgardner> statik, git clone git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
<statik> thanks tgardner
<tgardner> statik, drivers/net/e1000e/hw.h:#define E1000_DEV_ID_PCH_D_HV_DM                0x10EF
<statik> thanks
<statik> dmesg seems to show that it is failing probe during boot, and the patch talked about does a hw reset
<statik> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=627c8a041f7aaaea93c766f69bd61d952a277586
<statik> i have no idea what i'm talking about, but figured this seemed relevant and worth double checking whether it was present or not
<tgardner> statik, that commit is in Maverick. 'e1000e: Reset 82577/82578 PHY before first PHY register read'
<statik> tgardner, thanks :) my clone was still running. nessita has a bug report here: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/591702 , and the dmesg shows a line like this: e1000e: probe of 0000:00:19.0 failed with error -3 
<apw> tgardner, in which upload ?
<ubot2> Launchpad bug 591702 in linux (Ubuntu) "After upgrade lucid -> maverick eth0 interface is gone (dup-of: 591707)" [Undecided,New]
<ubot2> Launchpad bug 591707 in linux (Ubuntu) "After upgrade lucid -> maverick eth0 interface is gone (affects: 1) (dups: 1) (heat: 14)" [Undecided,New]
<tgardner> apw, I'm looking at the tip of the Maverick tree, so its at least in -rc2
<apw> statik, which kernel are you testing when seeing this?
<apw> cat /proc/version_signature
<manjo> tgardner, olimpiya was a good suggestion 
<statik> nessita, ^ can you check the version_signature ?
<statik> it was from a dist-upgrade yesterday
<tgardner> which should be Ubuntu-2.6.35-2.2
<JFo> bjf, got the boxes
<JFo> just 2 of them yes?
<tgardner> statik, oh, maybe not. -meta has not been updated.
<nessita> tgardner: I'll let you know in a sec
<nessita> statik: version_signature where?
<statik> nessita, cat /proc/version_signature as apw suggested above
<JFo> run that from a terminal
<nessita> Ubuntu 2.6.35-1.1-generic 2.6.35-rc1
<nessita> statik: thanks, I missed apw comment above
<tgardner> nessita, can you download and try https://edge.launchpad.net/ubuntu/maverick/+package/linux-image-2.6.35-2-server ?
<nessita> tgardner: yessir
<tgardner> http://launchpadlibrarian.net/49983143/linux-image-2.6.35-2-server_2.6.35-2.2_amd64.deb
<nessita1> tgardner: no luck with rc2 kernel, look http://nessita.pastebin.com/A9zdSyWt
<tgardner> nessita: ok, I'll see if I can grok the error code (right after I scarf some breakfast)
<nessita1> tgardner: ok, I'm in the troubled machine right now, I plugged in a dongle
<nessita1> tgardner: so I can copy and paste more easily :-P
<bjf> JFo, you got both pkgs?
<JFo> yep
<tgardner> nessita: has this e1000e _ever_ worked with any kernel?
<apw> ogasawara, yo ... 
<ogasawara> apw: yo
<apw> seems we had some FTBS's :(
<ogasawara> apw: yep, just looking at those.  it's the firmware not being optional
<apw> yeah i think we may have to make them optional again
<ogasawara> apw: I agree.  I'm gonna send a patch to flip them back.
<apw> though you should speak to tgardner 
<ogasawara> tgardner: ^^
 * ogasawara jump on mumble
<nessita> tgardner: yes, of course
<nessita> tgardner: until yesterday 7pm it was working
<nessita> tgardner: and right now it works with kernel 2.6.32
<nessita> tgardner: which was the kernel from lucid
<nessita1> tgardner: http://nessita.pastebin.com/UHKNCXKM
<cking> manjo, ping
<manjo> cking, pong 
<cking> manjo, hows that UEFI box getting on? Did you get any joy from it?
<manjo> cking, I am talking to 2 people at intel regarding EFI, unfortunately looks like most of the EFI devs are going to be in santa clara during the plugfest week 
<manjo> cking, I read up some docs yesterday regarding EFI 
<manjo> cking if you hop on some channel on mumble we can chat ? 
<cking> OK - gotta bear with me - I've got a migrane
<manjo> oh sorry to hear that 
<manjo> I am looking at the grub2 code right now 
<tgardner> nessita, ok, this seems like a serious regression. 
<manjo> cking, I read your wikis on EFI and they are pretty detailed
<manjo> was wondering with your permission I could move it to our ubuntu wiki ?
<cking> manjo, hold on.. 
<nessita> tgardner: how can I help debug?
<manjo> cking, ok be back with some more coffee
<tgardner> nessita: the first thing is to make sure it really, really works with 2.6.32 lucid. please reboot and paste the whole dmesg just to make sure you've not coincidentally encountered a HW issue. I'd be really surprised to find a regression in a well supported driver like e1000e.
<tgardner> reboot to lucid, that is.
<nessita1> tgardner: rebooting to 2.6.32
<nessita1> tgardner: dmesg for kernel 2.6.32 attached to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/591707
<ubot2> Launchpad bug 591707 in linux (Ubuntu) "After upgrade lucid -> maverick eth0 interface is gone (affects: 1) (dups: 1) (heat: 14)" [Undecided,New]
<nessita1> tgardner: I'm currently using net connectivity through eth0 and e1000e
<dob1> hi, after installing the new ubuntu release on my acer 5100 this problem https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446274 happen again, with the 9.04 the problem wasn't present, with the precedent release to 9.04 (i don't remember the version number) the problem was present, i know is very difficult to find the cause, but someone has some idea to what is changed in the kernel in these releases that can create the p
<ubot2> Launchpad bug 446274 in linux (Ubuntu) "System freeze with ACER aspire 5100 (affects: 2) (heat: 12)" [Undecided,Incomplete]
<tgardner> nessita: cool, now if you could do the same for the 2.6.35-rc2 Maverick kernel? 
<nessita1> tgardner: yessir
<dob1> it's a very bad problem, every time i had to hard reboot the system
<dob1> and i can't find nothing in log or what else
<apw> dob1, sadly there is such a huge ammount of stuff has changed between 9.04 and 10.04 LTS, that we're pretty unlikely to find the issue
<apw> does the previous kernel still boot for you with the updated userspace ?
<dob1> apw: i don't have it anymore
<apw> dob1, the next steps are normally to try and find out if upstream has this fixed via the mainline builds
<apw> dob1 you can likely find it in the lauchpad librariant, it keeps every kernel forever
<nessita> tgardner: second output attached to bug report
<dob1> apw: well can i find some precompiled kernel with no ubuntu patches ?  or i can download it from kernel.org
<dob1> just to test
<apw> dob1, yep in the miainline archive: https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
<apw> report any testing results to the bug
<dob1> apw: the problem is that when this problem happen i can't do nothing, the pc is freeze, no log , it doesn't respond to ping, like dead, i have to hard reboot
<apw> dob1, so you can very easily tell if its happehing or not on that kernel then
<apw> when does it happen, instantly at boot or do you have to do something to trigger it
<dob1> it can happen at boot, after hours i am using the pc, there is no applications that i can identify as a cause
<apw> if you can trigger it at boot, then booting without quiet and splash on the command line may get you something on the screen to report
<dob1> apw: to be clear, i have to login to the system
<apw> never occurs before that ... hrm ... 
<apw> a pig to debug for sure
<dob1> it was happen 1 time before the login, i was at login screen, the screen was ok but the sound of the login was repeated a lot of time, and it was freezed, but not stripe pattern  on the screen
<dob1> as sound of login, i mean the ubuntu login music, you understand what i mean
<tgardner> nessita, 'apport-collect 591707' to get the rest of your system info. Looks like you've got some ATI nouveau issues as well.
<tgardner> is this a thinkpad or something?
<nessita> tgardner: yes, video sucks at the moment, though I have a nvidia card...
<nessita> tgardner: ImportError: No module named gi after running apport-collect, though it keeps running
<tgardner> nessita, do you remember ever havinf flash issues with this e1000e? there was a serious problem during Hardy days when flash could get partially corrupted.
<tgardner> thinkpads were particularly vulnerable
<nessita> tgardner: this is a new box so I only had lucid installed on it
<nessita> tgardner: first installation was during March this year
<tgardner> s/ATI nouveau/nVidia nouveau/ in my previous comment. I get 'em confused sometimes
<tgardner> nessita, then you should be OK there
<tgardner> firmware wise....
<nessita> tgardner: apport-collect finished
<tgardner> nessita, got it, thanks. I know there are a couple of these thinkpads within the canonical IS group. I'll see if I can get someone to duplicate your issue.
<nessita> tgardner: ok, let me know if I can do anything else
<tgardner> nessita, maybe one last thing, attach the 'sudo dmidecode' to the report so I have the BIOS versions, etc.
<nessita> coming right up
<tgardner> I wish apport-collect did taht autmatically
<bjf> tgardner, am talking to cking about adding that to apport
<nessita> tgardner: fill a bug! :-P
<nessita> tgardner: output attached
<tgardner> bjf, why would cking be doing it?
<bjf> tgardner, he wants the information for some of the bios testing work he is doing
<bjf> tgardner, i'll do the work to apport
<tgardner> bjf, it means you'll have to run apport-collect as sudo
<bjf> tgardner, yup, know that
<bjf> tgardner, there is code in apport to collect certain logs as root, gksudo, ksudo, or whatever will run as necessary
<tgardner> cool
<tgardner> nessita, just for kicks and giggles, can you try the nVidia driver? 
<nessita> tgardner: I'd love, how can I? aptitude complains with the xorg packages
<tgardner> nessita, it used to be system/administration/hardware manager
<nessita> tgardner: as per that application, NVIDIA accelerated graphics driver (version 173) is activated and currently in use
<nessita> tgardner: and I can not update xserver-xorg-core because it breaks xserver-xorg-input-7
<nessita> xserver-xorg-core breaks xserver-xorg-video-6 (provided by nvidia-173 173.14.22-0ubuntu11, ...)
<tgardner> nessita, perhaps the best way to test this is to reinstall Lucid and then run the LTS backport kernel? That would get your video issues out of the loop.
<tgardner> maverick is in a bit of flux right now
<tgardner> wrt X packages
<nessita> yes :-)
<tgardner> nessita, you can get the LTS backported kernel from http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu
<nessita> tgardner: what do you mean with "reinstall" Lucid? reinstall from scratch?
<tgardner> nessita, uh, yep. I know that might be painful
<nessita> tgardner: *a lot* :-/ dependencies for ubuntu one are hige
<nessita> huge*
<tgardner> nessita, well, I hesitate to bug the upstream guys about this 'cause the _first_ thing they'll bitch about is the video faults you have in your dmesg.
<nessita> tgardner: I see. Let me talk about this with statik
<tgardner> once you have an oops, all bets are off for future behaviors.
<nessita> statik: ping
<tgardner> nessita, in the future you should try the LiveCD first before stepping off the edge :)
<nessita> tgardner: part of my job is to do this
<nessita> tgardner: isn't argument enough to show that kernel 2.6.32 works?
<nessita> tgardner: for upstream guys, I mean
<tgardner> nessita, not with an oops in your dmesg
<nessita> tgardner: video is totally broken in 2.6.32 but net works
<nessita> ok
<tgardner> nessita, in fact, if you _do_ reinstall, then just install the server (no video issues). you can always update by installing ubuntu-desktop
<nessita> tgardner: reinstall lucid or maverick?
<tgardner> nessita, reinstall lucid. Is this your only machine?
<nessita> tgardner: nopes, I have a laptop as well, with Lucid in it
<tgardner> nessita, um, I thought this _was_ your laptop. Thinkpad, right?
<nessita> tgardner: nopes, laptop is a toshiba satellite (works well so far)
<tgardner> that would explain the DMI information.
<nessita> tgardner: computer with this net issue is a desktop
<tgardner> OK.
<nessita> tgardner: want me to add those details to the report?
<tgardner> nessita, lets just start with the Lucid server re-install first, then add the LTS kernel and report on the results of that.
<nessita> tgardner: just to be sure, how which one would be the LTS kernel backport and how shall I install it? dpkg -i?
<tgardner> nessita, use can do that, or just add the repo to your apt sources, e.g., 'echo "deb http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu lucid main" | sudo tee /etc/apt/sources.list.d/kernel-ppa.list', then 'apt-get update;apt-get install linux-image-server-lts-backport-maverick'
<tgardner> s/use/you/
<nessita> right, thanks
<ppires> hi there. am i wrong if i put a kernel package building question here?
<jjohansen> -> Lunch
<ogasawara> tgardner: heh, I forgot that enabling bnx2 in armel results in additional build failures which I've hopefully fixed up now.
<tgardner> ogasawara, how much fun could that be :)
<ogasawara> tgardner: so hopefully the latest test build will finish soon and then I'll upload
<tgardner> ogasawara, what kind of fixes did you have to make?
<ogasawara> tgardner: needed to define dma_get_ops
<ogasawara> drivers/net/bnx2.c:3102: error: implicit declaration of function 'get_dma_ops'
<ogasawara> make that needed to define get_dma_ops
<tgardner> ogasawara, just a header file inclusion 
<tgardner> ?
<tgardner> I'm wondering if its an upstreamable patch
<ogasawara> I just threw in a #define get_dma_ops(dev) platform_dma_get_ops(dev)
<dupondje> whats the best way to make a bugreport for a kernel bug ?
<tgardner> dupondje, 'ubuntu-bug linux'
<dupondje> [ 2313.242321] BUG: unable to handle kernel NULL pointer dereference at (null)
<dupondje> [ 2313.242329] IP: [<ffffffffa025e0d6>] iwl3945_get_channels_for_scan+0xc6/0x210 [iwl3945]
<dupondje> and firefox gets locked totally .. weird thing :)
<dupondje> https://patchwork.kernel.org/patch/103568/
<dupondje> don't need to make bug for it then? As it hopefully gets fixed upstream ?
<tgardner> ogasawara, dave says he's gonna take that net patch that I sent you earlier today.
<ogasawara> tgardner: cool, I've already applied it locally
<manjo> bjf, where can I get the scripts to generate the modified ISO?
<manjo> bjf, found it... but I get an error chroot: cannot run command `mount': Exec format error
<bjf> manjo, you got it from the kteam-tools repo
<manjo> yes
<manjo> bjf, do I need to fun it from PWD? ie where the script is ? 
<bjf> manjo, don't know, i've run it on three different systems
<bjf> manjo, that's how I normally run it look at the daily script
<manjo> I coped the script to a directory called newiso/ and ran it 
<manjo> so I should run it from kernel-tools/daily-test-isos
<manjo> hmmm ran it from that dir and still get chroot: cannot run command `mount': Exec format error
<bjf> the "daily-iso-builder.sh" script shows you exactly how I run it
<bjf> manjo, are you running it on a lucid system?
<manjo> yes
<bjf> hmmm
<manjo> I have a maverick iso
<bjf> that error seems familiar but I can't recall why
<manjo> bjf, do I need to be in a chroot ?
<bjf> no, the script should take care of any of that
<bjf> manjo, I run that script just as it is from a cron job on emerald.pgraner
<bjf> manjo, just for a test, try to build it as you on emerald.pgraner
<bjf> manjo, in your home dir
<manjo> bjf, yeah emerald is not connecting atm
<manjo> bjf, looks like its dead from here 
<manjo> ssh: connect to host  XX port 22: Connection timed out
<manjo> pgraner, ^
<ogasawara> manjo: should be up, I'm currently watching a build on it as we speak
<bjf> ogasawara, same error for me
<apw> seems to work for me
<bjf> ogasawara, apw, same problem from two systems (was able to ssh in yesterday and maybe earlier today)
<bjf> getting ssh_exchange_identification: Connection closed by remote host
<manjo> bjf, any idea why sudo mount --bind /dev $CHROOT/dev would fail ? 
<apw> bjf, using the main link in right?  dsl is firewalled off when main is up
<ogasawara> bjf: did you just catch what I said on mumble?
<apw> bjf, just logged in successfully right now
<ogasawara> bjf: you probably need to update your .ssh/config
<bjf> ogasawara, why?
<ogasawara> bjf: I'm assuming firewall changes?
<bjf> ogasawara, since yesterday?
<ogasawara> bjf: no idea, but I know I had issues connecting this morning and once I updated my .ssh config to use ubuntu.redvoodoo.org it started working
<apw> ogasawara, the secondary link is not open unless the main goes down, so you have to use the right one
<bjf> ogasawara, yup, that was it
<apw> and we were on the secondary for the first few hours of the day
<bjf> apw, but i've been using dsl for a while, for long enough i forgot i'd changed
<bjf> apw, anyway, can connect now
<bjf> manjo, ^^
<apw> perhaps that bit wasn't working
<apw> bjf, ahh yes i know why, the dyndns on the dsl link was reporting the main address instead of the correct one
<manjo> yeah I switched to ubuntu. 
<manjo> from dsl
<manjo> as per ogasawara 
<apw> so it was no use for fall back
<bjf> ah
<apw> we should get pete to publish a name which points to the up link
<bjf> manjo, as per mount question, don't know why it would fail
 * bjf is going to get some exercise, back later
<manjo> bjf[afk], ogasawara, take a look at http://uck.sourceforge.net/
<manjo> bjf[afk], same script seems to work on emerald, something wrong with my machine setup, I tried uck and that fails on my machines as well.. so using emerald now 
#ubuntu-kernel 2010-06-10
<bjf> manjo, i've looked at uck, what about it?
 * apw yawns
<cooloney> apw: morning
<apw> morning
<jk-> brb, rewiring house
<RAOF> And you'll be right back? :)
<jk-> back
<kraut> moin
<apw> ikepanhc, hey you about ?
<ikepanhc> apw: yes
<ikepanhc> apw: anything?
<apw> ikepanhc, is the current version of the karmic netbook branch well current
<apw> ikepanhc, in order to apply debian commonisation to it i need to 1) modify it and 2) rebase it to the current proposed kernel
<apw> ikepanhc, so i want to be sure you've not got a modified version
<ikepanhc> apw: I do not aware who is using the branch, can you give me a hint?
<apw> ikepanhc, the karmic netbook branch is the karmic equivalent of hardy netbook-lpia ... i thought you sort of looked after those for OEM
<ikepanhc> apw: as I know, we have oem projects using jaunty and hardy netbook branch
<apw> ikepanhc, ok so its likely as anything a dead branch
<apw> ikepanhc, and if you don't have any interest in it i can just 'do it' ...
<apw> thanks
<ikepanhc> apw: can wait for US guys awake? so that I can ask them
<apw> ikepanhc, i can, though if you arn't maintaining it for them, and i am not, then i suspect they arn't using it
<apw> origin/master        Ubuntu-2.6.31-22.61
<apw> origin/netbook       Ubuntu-2.6.31-14.47
<ikepanhc> apw: yeah, that's what I am going to ask, if anyone need a rebase on karmic netbook-lpia branch
<apw> oh dear, its 8 ABI bumps behind ... perhaps it really is _dead_
<apw> ikepanhc, ok thanks man if you could ask, don't stay up till midnight to find out, i can wait till tomorrow no bother
<ikepanhc> apw: thanks, I need to finish hardy netbook branch rebase today, otherwise too much action item queue for me
<apw> good luck with that :)
<ikepanhc> apw: almost, just find out I forget to update debian/control
<apw> ikepanhc, we removed those generated files from the git repository on the other branches
<apw> that way they are missing rather than wrong if you don't clean before building, and the source package build fails then
<ikepanhc> apw: lrm/lum is removed, but not lbm :(
<apw> urgle, rip them out so you don't hit it again
<ikepanhc> apw: good idea
<ikepanhc> apw: btw, can take some time from you reviewing the removing LGUEST_GUEST config patch? Steve gave me a green light on removing it
<apw> ikepanhc, will have a look yep
<ikepanhc> apw: thanks
<apw> ikepanhc, done
<ikepanhc> apw: thanks a lot..
 * apw wanders out to get some parts
<apw> amazing ... success
<nessita> tgardner: good morning! I performed the Lucid server install, yesterday, and then installed the backport of the maverick kernel. Got oops-free dmesg outputs showing the e1000e issue
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=free
<nessita> tgardner: both dmesg output (lucid kernel, backported kernel) are attached to the bug report (#591707)
<nessita> ubot2: link please?
<ubot2> Factoid 'link please?' not found
<nessita> bummer
<nessita> tgardner: I guess I don't need to tell that I still have no eth0 :-)
<tgardner> nessita, ack.
<tgardner> nessita, ok, one last test. Lets try a vanilla upstream kernel (http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc2-maverick/linux-image-2.6.35-020635rc2-generic_2.6.35-020635rc2_amd64.deb) to make sure there isn't an Ubuntu patch causing problems.
<nessita> tgardner: bien sur, monsier. Would that installs in lucid?
<tgardner> nessita, yes, it should work fine in your server flavour installation
<nessita> ok, I'll try as soon as I finish some code reviews
<tgardner> nessita, np, thanks for your time
 * abogani2 waves
<abogani2> apw: ping
<abogani2> apw: Only for information I'm keeping up-to-date lowlatency git tree on Zinc and I'm also doing build test on my PPA: https://launchpad.net/~abogani/+archive/fix-436043/+packages
<nessita> tgardner: test done, no eth0 with the vanilla kernel, dmesg ouput attached to https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/591707
<ubot2> Launchpad bug 591707 in linux (Ubuntu Maverick) (and 1 other project) "After upgrade lucid -> maverick eth0 interface is gone (affects: 1) (dups: 1) (heat: 16)" [High,In progress]
<tgardner> nessita, ok, I've sent an email to the e1000e Intel developers list
<nessita> tgardner: yey!
<nessita> tgardner: keep me posted, please. The connection through the USB dongle sucks :-/
<tgardner> nessita, if you really need Maverick user space, its quite likely the Lucid kernel would work just fine. its worth a try.
<nessita> tgardner: video is messed up in my maverick installation using lucid kernel
<tgardner> nessita, I guess thats life on the bleeding edge :)
 * nessita loves adrenaline
<ogasawara> apw: that check-alias build failure is odd.  I expected the ports to fail in the latest upload, but they built just fine.
<tgardner> ogasawara, are the tools versions changing?
<ogasawara> tgardner: hrm, I'd have to check
<apw> ogasawara, yeah its 'dependant' on the state of the tree whether it triggers
<apw> i've taken the liberty of direct pushing a fix for it to your tree
<ogasawara> apw: cool
<apw> that allowed me to test it on the mainline builds, which trigger it every time
<apw> ogasawara, which in better news the 35-rc2 build has built correctly for the first time
<phunge0> achiang: https://bugzilla.kernel.org/show_bug.cgi?id=16090
<phunge0> achiang: https://bugzilla.kernel.org/show_bug.cgi?id=16161
<ubot2> bugzilla.kernel.org bug 16090 in PCI "sysfs: cannot create duplicate filename" [Normal,New]
<ubot2> bugzilla.kernel.org bug 16161 in Video(Other) "[2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?" [Normal,New]
<achiang> phunge0: ugh, thanks for reminding me. i've been busy lately. :(
<phunge0> np, understood
<achiang> phunge0: the issue, which i haven't figured out a nice way to fix yet, is that pci_sysfs_init() calls pci_create_sysfs_dev_files(), which then calls pci_create_slot_links()
<achiang> phunge0: preventing pci_create_slot_links() from being called during init would fix it, but i wonder why some of the other things like pci_create_capabilities_sysfs() seem to be fine
<achiang> phunge0: if you want to explore this area, i'd be happy to give you pointers. :)
<phunge0> achiang: i can take a quick look
<phunge0> achiang: but given that 2.6.35 is -rc2 people are starting to notice
<achiang> nod
<tgardner> nessita, inbound email re: e1000e
<nessita> tgardner: ok... I'll check. I hate flashing the BIOS :-(
<tgardner> nessita, yeah, its always a bit risky.
<achiang> phunge0: i just asked jesse to revert it. i'll try and find some time in the next merge window to get it working properly, i guess
<achiang> phunge0: especially since i have a reproducer
<achiang> phunge0: thanks for your help
<phunge0> achiang: np, makes sense to me
<nessita> tgardner: other than updating the BIOS, there is nothing else I can try?
<tgardner> nessita, so far thats the only suggestion that I have from Intel
<achiang> phunge0: if you want to keep an eye out for the revert and help manage the bugzillas though, that would be awesome...
<nessita> tgardner: ok, thank you, I'll keep you posted
<tgardner> nessita, if the BIOS upgrade doesn't fix it, then I'll have to instrument the driver and give you a custom kernel 
<nessita> right...
<phunge0> achiang: sure, i keep an eye on lkml... though i'm not comfortable doing the revert request myself :)
<achiang> phunge0: oh, i just pinged jesse on irc, so that part's taken care of.
<achiang> phunge0: when it hits linus's tree, if you could close out the bz's that would be lovely
<achiang> or at least remind me and i can go do it
<jjohansen> apw: is there a per flavour way of overriding the config enforcer
<apw> jjohansen, not currently it would be possible to add pretty easily i suspect ... wahts your usecase ?
<jjohansen> well one of the configs I need if I can get this stupid thing to work is CONFIG_SYSFS_DEPRECATED_V2
<jjohansen> which currently is enforced off
<apw> so for a branch you you can just edit the file and remove it
<apw> if its coming back to master, we'll need to add support for flavours in the file
<apw> jjohansen, i lied, seems i do have a flavour pred
<apw> so you should be able to say
<apw> (flavour ec2; value CONFIG_SYSFS_DEPRECATED_V2 y) | value CONFIG_SYSFS_DEPRECATED_V2 n
<apw> or similar
<jjohansen> okay, thanks
<vosl> hi
 * bjf is having email problems and has no x on laptop after this a.m. update... been trying to get to a setup where I can get something done all a.m.
<jjohansen> ouch
 * jjohansen has been avoiding updates since robbies email
<bjf> but my btrfs is *FABULOUS* :-)
<sconklin> robbie's email to which list?
<vosl> hello
<bjf> sconklin, i'd tell you which list but I can't get to my email
<vosl> guys i just wanted some help on your kernel version numbering system
<vosl> how does it usually wwork
<vosl> i read the wiki but couldnt make sense of it
<bjf> vosl, what is your question?
<vosl> i assume for debian and ubuntu its the same kinda versioning
<vosl> liunx kernel version number
<vosl> how is the numbering done?
<bjf> vosl, via 'uname -r' = 2.6.32-22-generic
<bjf> vosl, we have made 22 abi bumps on a 2.6.32 kernel
<vosl> are you talking in general or this is specific to ubuntu kernels?
<bjf> vosl, this is a ubuntu lucid install
<vosl> ok how does the numbering work?
<vosl> 2.6.32-22
<bjf> vosl, it is telling you that it is based on the 2.6.32 kernel from upstream (linus' tree)
<vosl> ah
<vosl> so this is the same case with vanilla too?
<vosl> the versioning doesnt differ per distro does it?
<dupondje> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208 / https://patchwork.kernel.org/patch/103568/
<ubot2> bugzilla.intellinuxwireless.org bug 2208 in others "Driver hang while running auto test cases" [Critical,Verified: fixed]
<dupondje> is this something we can get into maverick kernel bit earlier ?
<bjf> vosl, i don't know how other distros report versioning but it's probably similar
<vosl> ah
<vosl> what does the -22 stand for?
<bjf> vosl, as I said previously, there have been 22 abi bumps
<vosl> ooh ok
<vosl> bjf[afk]: which is better
<vosl> .30 or a .30.1?
<vosl> depends on which type of patches are allowed for each versions
<vosl> right?
<vosl> new features, regressions or bugfixes only
<cking> manjo, you around?
<manjo> cking, yes
<cking> ok to mumble for 5 mins?
<manjo> sure 
<dupondje> When will maverick kernel be rebased on the upstream kernel ?
<dupondje> the bug seems fixed in it today http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=63a07cb64ccc3ceae619d3298545d602ab5ecd38;hp=b95a56809343fb727c818ad1b9da14a17fa92ef6
<ogasawara> dupondje: it's already been rebased to 2.6.35-rc2.
<dupondje> will it get rebased to rc3 ?
<dupondje> cause that bug is killing me :)
<ogasawara> dupondje: yes, when it's released upstream we'll rebase again
<ogasawara> dupondje: wash, rinse, repeat for the entire 2.6.35 cycle
<dupondje> :)
<dupondje> is there a chance to get the patch in kernel faster, or you say, wait for rebase ? :)
<ogasawara> dupondje: seems we should just wait for the rebase as it'll be in -rc3
<ogasawara> dupondje: and rc3 is just around the corner
<dupondje> lets hope so. its crashing daily atm :( anyway its good to see its in the main git now, so it will be picked up for sure now
<ogasawara> dupondje:  as an interim solution you could use the latest mainline daily build
<ogasawara> dupondje: well you may need to wait till tomorrow for the build to include the patch that landed today
<dupondje> i'll grab it tomorrow
<tgardner> kees, what does dumpable mean wrt to ptrace?
<kees> tgardner: it means core-dumpable.  as in, "has this process transitioned uid?"
<kees> tgardner: you can't ptrace a process that started setuid, e.g.
<kees> tgardner: but this flag can be set by a process itself using prctl.
<kees> tgardner: this is what well-behaved processes that handle sensitive memory do (e.g. ssh-agent)
<tgardner> kees, I was just reviewing your email that includes the 10-ptrace.conf verbage. It occurred to me that dumpable didn't mean anything to me.
<kees> tgardner: see "man prctl" and search for PR_SET_DUMPABLE
<kees> tgardner: I was trying to be as accurate as possible while hopefully not being too opaque.  :P
<jjohansen> ->Lunch
<MTecknology> jjohansen: enjoy
<Laibsch> manjo: please be more careful when closing bugs
<MaximLevitsky> what is the policy on EXPEREMENTAL in the ubuntu kernel?
<manjo> Laibsch, which one ?
<Laibsch> you should have received mail about it
<Laibsch> please be careful with any bug you close
<manjo> Laibsch, checking 
<MaximLevitsky> I have 2 drivers in 2.6.35
<Laibsch> you seem to be new at this
<ripps> What's the likelyhood of an updated wacom driver getting into the kernel? I'm constantly rebuilding the module because the default one doesn't work with my wacom bamboo ctl-460
<MaximLevitsky> one of which I labeled experemental
<MaximLevitsky> now I say it is more or less well tested
<manjo> Laibsch, bug# ?
<dupondje> Is there a way I can build my own daily ? really need the patch that got in today :)
<MaximLevitsky> it still contains a disclaimer about how it can eat your cat & dog though :-)
<MaximLevitsky> I had no reports of this though :-)
<ogasawara> mjg59: hi, we've been carrying an Ubuntu kernel SAUCE patch that was originally authored by yourself years ago.  I wanted to get your feedback on it and am curious if you prefer I use your redhat.com email address or a different one?
<MTecknology> Transaction rate:        7.31 trans/sec
<MTecknology> OUCH
<MTecknology> sorry... wrong channel
<mjg59> ogasawara: Which one is it?
<MaximLevitsky> mjg59: hi
<manjo> Laibsch, if you can't tell me what bug number it is I can't help 
<Laibsch> manjo: bug 527361
<ubot2> Launchpad bug 527361 in linux (Ubuntu) (and 1 other project) "hotplug interferes with ethernet card (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/527361
<Laibsch> manjo: is it too much to ask that you check your mail?
<ogasawara> mjg59: the patch is "UBUNTU: SAUCE: hostap: send events on data interface as well as master interface" from back in 2007
<Laibsch> geez
<manjo> Laibsch, sorry did not see your mail yet not in my inbox yet
<Laibsch> manjo: just don't close bugs if you don't understand what it means, OK?
<MaximLevitsky> How can I ask ubuntu to enable it in marvic kernel?
<mjg59> ogasawara: That was because network manager was only listening for association events on the data interface, and hsotap was only sending them on the master interface
<mjg59> ogasawara: I have no idea whether that's still an issue
<ogasawara> mjg59: I'm inclined to drop it and see who screams
<manjo> Laibsch, I don't think that bug is SRU'able 
<mjg59> ogasawara: Yeah, I'd go for it
<Laibsch> manjo: please learn about LP before making any further embarassing comments
<ogasawara> mjg59: perfect, thanks
<dupondje> ogasawara: can I build my own daily ? Its crashing to much :(
<MaximLevitsky> anybody ?
<ogasawara> dupondje: sure, go for it
<dupondje> ogasawara: is there some easy script or so for it ? or just pull from the git or ? :)
<ogasawara> dupondje: I don't have a link for building the upstream kernel off the top of my head, but should be easily found via google
<dupondje> the script you guys use for the dailies isn't availible ? :)
<MaximLevitsky> mjg59: btw I am bisecting another ACPI bug
<ogasawara> apw: ^^?
<mjg59> MaximLevitsky: Excellent
<MaximLevitsky> mjg59: I see that on boot the EC GPE is disabled
<MaximLevitsky> mjg59: so no notify from battery, ac, ....
<MaximLevitsky> mjg59: suspend/resume 'fixes' this. I use the acpi-test branch now. Going to reboot
<manjo> tgardner, on the phone 
<tgardner> manjo, ack
<MaximLevitsky> Is it possible to enable a driver that depends on EXPREMENTAL in ubuntu kernel?
<MaximLevitsky> my driver is CONFIG_SM_FTL (sm_ftl.ko)
<tgardner> MaximLevitsky, its possible. which driver(s) are you considering?
<MaximLevitsky> tgardner: ^^^
<tgardner> lemme look
<MaximLevitsky> this is FTL (flash translation layer)
<MaximLevitsky> I admit that I overdue the Kconfig option for it 
<tgardner> MaximLevitsky,  likely to have little impact on the general PC class of installs. Are you building for an embedded device?
<MaximLevitsky> All reports I recieve untill now were positive (minus typical user errors)
<MaximLevitsky> tgardner: this is for xD card reader
<tgardner> ah, that thing.
<MaximLevitsky> Ricoh R852 xD card reader
<tgardner> MaximLevitsky, so, do you think it works better then what you've stated in the Kconfig description? 
<MaximLevitsky> tgardner: I think yes
<MaximLevitsky> tgardner: I didn't update it from first merge. In general especially modern xD cards (type M) should be prefectly safe because they use emulated interface
<MaximLevitsky> In addition to that I need new udev rule
<MaximLevitsky> to load the FTL
<MaximLevitsky> and to tell devicekit to treat the device normally
<tgardner> MaximLevitsky, I was just gonna ask what loads the driver
<MaximLevitsky> converting whole mtd system to proper bus interface it too big job for me.
<tgardner> MaximLevitsky, are you getting any traction with the udev developers? I'm not sure I can help you get a new udev rule.
<MaximLevitsky> tgardner: I didn't yet posted anything to udev list
<MaximLevitsky> tgardner: however I also need some modifications to devicekit rules
<MaximLevitsky> the 'udisk' I forgot
<tgardner> MaximLevitsky, send a patch to the kernel team list enabling the config option. I'm not opposed to it. You're on your own for components outside the kernel.
<MaximLevitsky> because it treats all devices as system unless they are in white list
<MaximLevitsky> tgardner: beeing lazy, whats the address :-)
<tgardner> kernel-team@lists.ubuntu.com
<MaximLevitsky> tgardner: thanks!
<MaximLevitsky> tgardner: last question, the debian.master/config is the place I am looking for to change the config option ?
<matumba> hello, i guess i should report bugs with ubuntu's mainline kernel to upstream rather than to launchpad?
<MaximLevitsky> matumba: its is always better to report to upstream
<matumba> MaximLevitsky, well then... thx ;-)
<ripps> What's the likelyhood of an updated wacom driver getting into the kernel? I'm constantly rebuilding the module because the default one doesn't work with my wacom bamboo ctl-460
<tgardner> MaximLevitsky, yeah, change it to CONFIG_SM_FTL=m in debian.master/config/config.common.ubuntu, then run 'fakeroot debian/rules updateconfigs'
<manjo> tgardner, I am looking at SHAID bc9d24a3aeb1532fc3e234907a8b6d671f7ed68f
<MaximLevitsky> tgardner: thanks!
<manjo> which is the 2nd one mentioned 
<tgardner> manjo, so I'm not sure where you came up with bc9d24a3aeb1532fc3e234907a8b6d671f7ed68f. Its not mentioned in either the BS or LP reports, is it? Though it does seem reasonable for a stable update.
<tgardner> BS->BZ
<manjo> tgardner, right I looked at the git logs for 2.6 upstream and I see eeepc-laptop: check wireless hotplug events with SHAID bc9d24a3aeb1532fc3e234907a8b6d671f7ed68f by Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date:   Mon Feb 22 16:03:58 2010 +0000
<manjo> tgardner, the bz report mentions this patch from a private tree 
<manjo> the last comment in BZ
<tgardner> ah
<manjo> that is what I have been talking all along 
<manjo> talking about
<tgardner> manjo, ok, then see if you can get that one included for 2.6.32 stable
<tgardner> manjo, you're gonna have to do a backport of that commit since it doesn't apply cleanly.
<manjo> ah crap
<manjo> tgardner, will do thanks
<MaximLevitsky1> I have another probably newbie question
<MaximLevitsky1> I downloaded the marvic kernel from git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
<MaximLevitsky1> I do 'fakeroot debian/rules updateconfigs
<MaximLevitsky1> dh_testdir: cannot read debian/control: No such file or directory
<tgardner> MaximLevitsky1, fakeroot debian/rules clean  updateconfigs
<MaximLevitsky1> I can copy the file there, but I think I need to start some init script
<tgardner> MaximLevitsky1, do the clean first
<MaximLevitsky1> tgardner: works now
<MaximLevitsky1> tgardner: maybe add that to wiki?
<MaximLevitsky1> didn't find that at https://wiki.ubuntu.com/Kernel/Dev
<tgardner> MaximLevitsky1, I think its there somewhere. we're in the process of rewriting a lot of that info
<MaximLevitsky1> tgardner: ok, thanks
<MaximLevitsky1> tgardner: should I now build the package or the 'updateconfigs' is enough?
<MaximLevitsky1> I hate waiting 2 hours for that :-(
<tgardner> the updateconfigs should be sufficient.
<MaximLevitsky1> tgardner: thanks again
<MTecknology> The only ban in here is a bot - does that still need to exist?
<manjo> emerald not responding 
#ubuntu-kernel 2010-06-11
<bjf> RAOF, after an a.m. dist-upgrade today, i find myself without X
<bjf> RAOF, this is a thinkpad x301 with intel graphics
<RAOF> Reinstall ubuntu-desktop, everything's installable now.
<bjf> RAOF, a daily iso *does* work
<bjf> RAOF, will give it a whirl
<bjf> RAOF, can you also fix my btrfs on the same system :-)
<RAOF> bjf: Did you perhaps miss the u-d@ & u-d-d@ notification a couple of days ago that X upgrades would be broken until everything was rebuilt for the new X server? :)
<bjf> RAOF, i saw the notice, thought everything was rebuilt (I was *wrong*)
<RAOF> Everything (well, almost everything) that needs rebuilding has now been rebuilt.
<RAOF> In return, would you like to fix the frequent kernel oopses in iwlwifi? :)
<bjf> RAOF, which kernel version you running?
<RAOF> 2.6.35-2
<RAOF> or possibly -1
<bjf> hmmm, if -1 try -2 but I haven't seen that problem
<RAOF> Hah.  I bet you also haven't been having kernel crashes every couple of days, either :)
<bjf> i'm fighting a btrfs issue right now, gotta love these linux release candidates
<RAOF> You'd have a launchpad bug already if launchpad would accept ~255MiB vmcore apport attachments.
<bjf> lol
<lag> Morning all!
<jk-> hey lag
<lag> Hey jk-
<lag> How are you this morning?
<jk-> not too shabby, and you?
<lag> Yes mate, bonza ;)
<lag> What time is it there?
<lag> jk-: --^
<jk-> :)
<jk-> 1:57pm
<lag> +7hrs
<lag> That's not too bad
 * apw yawns
<abogani2> apw: good morning :-)
<apw> moin
<apw> heh now thats a good one ... my belkin KVM got mixed up so video and USB were switching in the opposite directions
<abogani2> funny
<TeTeT> hi, a customer has a problem with netbooting and installing 10.04. The last line when booting the kernel is stating 'addrconf link eth0 becomes ready'
<TeTeT> any ideas how to add more debugging output to the kernel, so the messages become more verbose and we have a chance to figure out what's going on?
<kraut> moin
<apw> TeTeT, normally you remove quiet and splash, you can then up the loglevel ... loglevel=8
<apw> may get you more, but just as likly not
<TeTeT> apw: thanks
<TeTeT> apw: quiet and splash was already gone
<apw> though addrconf doesn't sound like the kernle
<apw> do you have any capture of the lines up to the error ?
<apw> bah how did it get to be so late already
<tgardner> apw, what is this? http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.11-karmic
<tgardner> a mis-fire?
 * apw looks
<apw> tgardner, yeah thats a false broken build, i'll zap it and get it rebuilt
<tgardner> apw, how about similar 2.6.33*lucid and 2.6.34*lucid ?
<apw> tgardner, i'll have a finger print for the issue so i should be able to get them all
<apw> we'll  find out in a few hours if they build properly this time
 * apw drops offline for a bit to move location
<manjo> anyone else seeing slow network to/from emerald ? 
<ogasawara> kamal: bug 553498 came up in the release meeting today ... but based on comment #52 from yourself, it seems this should be resolved for Maverick
<ubot2> Launchpad bug 553498 in linux (Ubuntu Maverick) (and 2 other projects) "Intel Core i3/i5/i7 hang on resume from suspend (SCI_EN) (affects: 13) (heat: 84)" [High,In progress] https://launchpad.net/bugs/553498
<ogasawara> kamal: the only thing is I can't see that sha1 id you noted
<ogasawara> ~/linux-2.6$ git show 74ca255e19aac16a689d98126c935ad99a47778c
<ogasawara> fatal: bad object 74ca255e19aac16a689d98126c935ad99a47778c
<kamal> ogasawara: ha!  did I make it all up!?  ;-)  looking
<ogasawara> kamal: I'm sure you're not crazy, maybe just a sha1 typo?
<kamal> ogasawara: maybe my cut-n-paste button broke! ;-)   gotta boot my other machine -- will be just a minute.
<tgardner> ogasawara, hmm, I pasted the same comment in the bug report :)
<ogasawara> tgardner: heh, did you really?  maybe I can't read.  /me refreshes
<kamal> ogasawara, tgardner:  hmmm.  When I do   git show 74ca255e19aac16a689d98126c935ad99a47778c    I do get the patch I'm talking about.
<tgardner> kamal, what repo?
<ogasawara> kamal: what's the patch subject?  I can search by that.
<kamal> tgardner: I see it in my linux-2.6 and in my ubuntu-maverick repos
<kamal> ogasawara: commit 74ca255e19aac16a689d98126c935ad99a47778c   ACPI: Unconditionally set SCI_EN on resume
<ogasawara> tgardner: b6dacf63e9fb2e7a1369843d6cef332f76fca6a3
<tgardner> b6dacf63e9fb2e7a1369843d6cef332f76fca6a3
<manjo> lag, looks like you are beating the heck out of emerald
<tgardner> ogasawara, hmm, theres a lot of patch there, but mostly ripping out code
<ogasawara> kamal: ok looks like that was upstream as of 2.6.35-rc1.  Since we've already rebased maverick to 2.6.35-rc2 I'm going to mark the Maverick task Fix Released.
<kamal> ogasawara: I agree
<ogasawara> kamal: for lucid, have you tested with this patch backported?
<kamal> ogasawara: yes, I've applied exactly that change to lucid and published a test kernel, and have positive test results from myself and from other people on the bug report.
<lag> manjo: My build is finished
<kamal> tgardner, ogasawara: any explanation why I see this patch with two different SHA ID's?  (the one you guys found also works in my trees).
<manjo> lag, yes I noticed 
<manjo> lag how did you get more priority over my build task... it virtually stopped all my builds
<tgardner> kamal, perhaps your repo is polluted. try 'git gc;git prune"
<lag> I had the same thing with ogasawara yesterday, but the roles are reversed 
<lag> It just like the machine has a scheduling issue
<lag> looks*
<ogasawara> as long as it always schedules me with a higher priority I'm happy :)
<lag> Pfft...
<manjo> lag, and your build took 1/2 the time mine normally takes 
<lag> That's because it wasn't a clean build
<bjf> pgraner, ping
<pgraner> bjf: pong
<manjo> tgardner, @selinuxfest
<tgardner> mpoirier, manjo, lag, cnd, sconklin - bouncing emerald for new kernel 2.6.35.2.7. ready soon?
<manjo> tgardner, I have a build going 
<tgardner> manjo, lemme know  when its done
<manjo> tgardner, ack
<mpoirier> not good.
<mpoirier> you're just doing to reboot ?
<cnd> tgardner: I can be off, can you give me a 3 min heads up before you do so?
<tgardner> mpoirier, yep, just a reboot
<mpoirier> give me 10 minutes, just to finish compilation/git clone.
<mpoirier> I'll touch base with you.
<sconklin> tgardner: any time is fine for me
<sconklin> tgardner: I had kernel builds in the lucid chroot hang yesterday during linking on emerald
<tgardner> sconklin, which is why I'm updating the kernel. I think there are some fixes for taht
<sconklin> great
<lag> tgardner: I'm okay with it
<tseliot> mjg59: so, any ideas? I'm asking you as you're the author of that moduel
<cnd> big storm overhead, lost power once, may lose it again
<mjg59> tseliot: What hardware is this?
<cnd> tgardner: feel free to take the machine down anytime
<cnd> power loss disrupted my work anyways
<tseliot> mjg59: it's an unreleased inspiron
<tseliot> mjg59: with fglrx and acpi_listen I get the following: video VGA2 00000081 00000000
<tseliot> mjg59: the F1 button acts as a video switch while Fn+F1 acts as F1
<mjg59> tseliot: Ok, so you should be getting KEY_SWITCHVIDEOMODE through the ACPI video driver
<mjg59> Are you not?
<tseliot> mjg59: no, I'm not. Nothing happens if I use the radeon driver instead of fglrx
<tseliot> and no output in acpi_listen
<mjg59> Well, then there's a bug somewhere
<mjg59> I don't think it has anything to do with dell-wmi
<tseliot> do you think it can be the graphics driver?
<mjg59> Can you send me the acpidump for the machine?
<bjf> http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/3.1rc2/linux-i686/en-US/thunderbird-3.1rc2.tar.bz2
<mjg59> I have NDAs with Dell
<tseliot> mjg59: sure
<mjg59> Anyway, lunchtime
<tseliot> mjg59: BTW I'm also booting with acpi_osi="!Windows 2009"
<mjg59> Why?
<mjg59> Oh, because otherwise it sends Windows+P?
<tseliot> yep
<mjg59> Ok, don't bother sending me the acpidump
<mjg59> Eh. Actually, do
<tseliot> I will
<mjg59> mjg@redhat.com is probably the best
<mjg59> But I suspect that the correct fix here is "Make sure windows+p does the right thing", since we're not going to modify the kernel to disable the Windows 7 OSI string
<tseliot> mjg59: ok, I'll send it there, thanks
<tseliot> ah
<tseliot> mjg59: the key also seems to send an enter key event after a few seconds (per spec)
 * apw wanders back
<apw> tseliot, where in the spec do you see the return being mandated 
<tgardner> mpoirier, manjo - about to bounce tyler
<manjo> tgardner, OK
<tseliot> apw: something worth asking mterry
<mpoirier> I'm out of tyler
<apw> tseliot, i don't even see the spec saying win-P is required
<winlundn> 1364926 objects in karmic, ha. How-dee, all
<winlundn> apw: they're doing that in ayatana
<winlundn> voluntary
<winlundn> just over a mil objects in jaunty. cool, I like git
<tseliot> apw: you may want to ask mterry the same question again
<tseliot> now that he's here
<apw> mterry, where do we see a requirement for the return after the win-p in the windows spec
<mterry> apw, oh, you're going to ask me hard questions.  let me try to find the reference for that
<mterry> apw, jerone knows more on this than I do, will try to find him talking about it in email
<apw> mterry, i've not even found a reference in any of his docs that says win-p should be generated.  only that pressing win-p produces that dialog and your button should produce the same one
<apw> which is miles from must produce win-p
<apw> winlundn, i don't think i understand you
<winlundn> unrelated to what you're talking about now, I see. My mistake
<apw> winlundn, ahh ok
<mjg59> tseliot: Well, I see part of the problem
<mjg59> Looks like Radeon needs to call the ATIF method
<mjg59> I'll talk to AMD about that
<tseliot> mjg59: thanks
<mterry> apw, everything I know is in bug 539477.  Jerone says (comment #40) that he has a secret data sheet that recommends the logic he outlines in comment #39.   The one presentation he can link to has (slide 36) says that "modifying ACPI hot key to display Windows 7 projection hot key" is "highly recommended".  which doesn't talk about return key, but does imply that BIOS should report Super+P for the display key
<ubot2> Launchpad bug 539477 in linux (Ubuntu) (and 4 other projects) "Video out hot key sends super + p + return on many upcoming Dell & HP systems (affects: 10) (dups: 1) (heat: 110)" [Undecided,Confirmed] https://launchpad.net/bugs/539477
<mterry> apw, presumably Jerone can share the secret data sheet with you
<apw> mterry, i think he has, and as i say i just cannot see what they are doing as mandated
<mterry> apw, "what they are doing" means the return key?
<mterry> apw, I haven't seen the data sheet.  You're saying that it's not even suggested?
 * winlundn is always going to look at acpi and go, ``Oh that.''
<apw> mterry, i don't even see the wording meaning you need to win-p at all, cirtainly there was nothing saying anything about also hitting return for the user
<apw> it is a god awful idea
<mterry> apw, agreed.  :)  slide 36 has the language I quoted.  That doesn't strike you as suggesting Super+P?
<mterry> apw, to my eyes it directly says as much
<apw> it says what super-p will produce, and says any magic key should produce the same dialog
<apw> i don't see words saying tehy are the same
<mterry> apw, no, it says any magic key should "display win7 projection hot key"
<mterry> apw, it doesn't say anything about a dialog there
<apw> it says display, not type or send
<apw> and even if i am very generous and accept that win-p is required
<apw> read me the bit about return being required
<mterry> apw, agreed.  But it also says hot key.  And if it was intended that the dialog come up for the magic key, it would be done on win7 side, no need to ask bios people to change anything
<mterry> apw, so it sounds like they are asking bios people to change reported hot key
<mterry> apw, (I mean, if MS wanted dialog to come up for old VIDEOSWITCHMODE key press, they could do it themselves, don't know why that request would be directed at BIOS people)
<apw> i don't agree, but that is imeterial to my point which is the extra return is not mentioned, and that would be a sane thing to do in the win7 side if desired
<apw> ie if the dialog should be self answering why would win7 not do that, why would the bios need to be involved
<winlundn> aye, metric
<mterry> apw, well, Jerone says that the return behavior is clearly spelled out in his secret data sheet.  You say you've seen this sheet but don't agree.  I can't really add anything to this discussion
<mterry> apw, except to say that BIOS's in the wild are doing this
<apw> that bios vendors do stupid things is the very definition of the breed
 * manjo going down for a reboot
<apw> there is almost no way to do anything sane with those semantics
<mterry> apw, except to ape Win7 exactly (throw up a dialog, etc).  Which I agree is a crazy requirement to have to meet
<winlundn> mterry: yes, from what I understand that's bridging that where it's un-needed
<apw> tgardner, the first rebuild just completed, looking good
<tgardner> apw, ack
<apw> right beer time ... see yo lot
<tgardner> apw, havea good weekend
<ogasawara> Mmmm beer
<tgardner> ogasawara, you wish.
<ogasawara> tgardner: I'm still going through withdrawl
<philsf> hi, I can't get my bluetooth adapter to be recognized with Lucid's 2.6.32 kernels. The last one I got it working it, was the 2.6.31 from beta stage. I also lost ability to use my wifi killswitch (which also works with the old .31). How can I debug this, so can I open a proper bug? Sorry for asking here, but no one answered in #ubuntu
<manjo> philsf, does lsusb list anything ? 
<philsf> manjo, nope
<manjo> philsf, what adapter is it ? 
<manjo> philsf, what make model of laptop ?
<philsf> hmm, I think I'll have to reboot in 2.6.31 to see what module it uses
<philsf> it's an Asus EEEpc 1005HA
<philsf> netbook
<manjo> philsf, yep please do
<philsf> ok, I'll check back here then, thanks
<manjo> that will be the easiest way to find out what device/driver we are missing 
<manjo> philsf, https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/416487
<ubot2> Launchpad bug 416487 in bluez (Ubuntu) (and 1 other project) "Bluetooth Doesnt Work - Eee PC 1005HA-P (affects: 5) (dups: 1) (heat: 32)" [Undecided,Won't fix]
<philsf> manjo, lsusb gives now Bus 005 Device 002: ID 0b05:b700 ASUSTek Computer, Inc. Broadcom Bluetooth 2.1
<philsf> wontfix?
<manjo> philsf, a while back I found the problem with bios that prevented bluetooth 
<manjo> philsf, please look at the bug see if that is the same you are experiencing 
<philsf> I will. what about the radio killswitch, is it the same problem?
<manjo> philsf, not sure about radio kill switch... I think there was a recent patch for it ... 
<philsf> manjo, it looks like the same issue, I'll try upgrading the bios, thanks
<manjo> tgardner, build on emerald still hangs (mine hangs in [LD]
<manjo> philsf, cool!
<jjohansen> -> Lunch
<bladernr> Can someone clarify something for me about the time stamping in kernel messages?
<bladernr> Jun 11 11:46:02 klaatu kernel: [  184.568662] ehci_hcd 0000:00:1d.0: PCI INT A disabled
<bladernr> am I correct in reading that as 184.5 seconds since boot?
<manjo> does any one know what this means ? chroot: cannot run command `mount': Exec format error
<manjo> I get this when I try to create my chroot env using the build-chroot scripts 
<phunge0> bladernr: yes i believe it's since boot
<bladernr> any way to reset that without a reboot?  Because, according to my logs (64 bit 10.04) I have been running either a few thousand seconds or over 18 billion seconds...
<bladernr> Here'e one example: http://pastebin.ubuntu.com/448373/
<bladernr> And here's some showing just before entering S3, and just after starting the resume: http://pastebin.ubuntu.com/448374/
<tgardner> bladernr, it sounds like your TSC is getting wonky. its a known problem on some classes of CPU. Atom for example.
<bladernr> Hrmmm... ok.  It's a quad core i7...
<bladernr> Oddly enough, my atom based netbook doesn't seem to have this issue
<kees> ogasawara: so, I take it maverick's tree rebased recently.  how should I deal with this for my local trees?  "git pull" alone doesn't seem to cut it.
<ogasawara> kees: yep, we rebased to 2.6.35-rc2 a few days ago
<ogasawara> kees: you should be able to git fetch origin
<tgardner> kees, if you've no local changes then 'git fetch origin master;git reset --hard FETCH_HEAD'
<kees> tgardner: gotcha, yeah.
 * ogasawara lunch
<kees> tgardner: and how do I rebase local branches that are based on the now-rebased maverick?
<tgardner> kees, git checkout -f YOUR_BRANCH;git rebase master
<tgardner> kees, if they are in the same repo
<kees> that fails for me.
<tgardner> rebase conflicts?
<kees> not from my changes.  my change was a single commit on top of regular maverick, and now it's yelling about merge conflicts in debian/*
<lag-mobile> Can you do cross-repo rebasing?
<kees> $ git rebase maverick
<kees> First, rewinding head to replay your work on top of it...
<kees> Applying: UBUNTU: Fold down debian for ubuntu-m
<kees> Using index info to reconstruct a base tree...
<kees> <stdin>:160857: trailing whitespace.
<kees> ....
<kees> *boom*
<kees> and that rewind took a looong time
<kees> I assume it tried to find the branch point and re-applied the entire old maverick stack to the rebased maverick stack.
<kees> how do I tell it "throw away all of this except my top commit" ?
<tgardner> kees, ah. then the simplest thing to do is restore your original branch and save off your local patch; git checkout -f YOUR_BRANCH;git format-patch -1;git fetch origin master;git reset --hard FETCH_HEAD;git am 0*
<tgardner> kees, does that make sense?
<kees> tgardner: yeah.  though it seems a bit clumsy.  I was hoping to automate this, so "-1" won't always be correct.  hmmm
<tgardner> kees, it is clumsy, but its conceptually simple (for me at least)
<kees> yeah
<kees> tgardner: oh, actually, can't I use FETCH_HEAD as the cut-off for doing the format-patch, since it was set during the last fetch?
<tgardner> kees, I'm not sure that makes sense because your local patches are relative to HEAD.
<kees> hm.
<tgardner> kees, once we stop messing with the debian cruft then rebasing will likely work better.
<kees> I mean, if I do this:  git checkout master; git fetch origin master;git reset --hard FETCH_HEAD; git checkout -b test-branch; *work*commit*; git checkout master; git fetch origin master;git reset --hard FETCH_HEAD; git checkout test-branch.  isn't FETCH_HEAD here equal to where I started my work? as in FETCH_HEAD through HEAD are my local patches, so I could do git format-patch FETCH_HEAD; git fetch origin master;git reset --hard FETCH_HEAD;git am
<tgardner> kees, you're making my head hurt.
 * kees blames git
<kees> also, I think git am is lossy, in that it starts ignoring text after a --- line
<tgardner> kees, which is why I never use it unless its been a 'git format-patch' created file
<kees> well... i have format-patch'd patches that include --- for the purpose of having "am" drop the text after it when someone upstream takes my patch (i.e. I have the patch version history after ---), but I don't want to lose it locally.  that said, I think rebase might be able to do a "from, to" kind of a thing here.
 * kees goes off to dig
<kees> I think some combination of --onto and --root is needed
<kees> hm.  .35 doesn't boot for me.
<kees> seems to hang the system
<jjohansen> kees: well it is only at RC2
<kees> but it's been uploaded to the archive...
 * bjf is headed to work out
#ubuntu-kernel 2010-06-12
 * jjohansen decides to copy bjf
<bjf> ogasawara, Mainline Build v2.6.34-rc3?  ?rc3?
<winlundn> Jeezus we as a civil society need a new TCP/IP protocol to safely detach and no `` pings '', which reverse interlock here then kick PPL. Oops poor mterry.
<winlundn> Because SCTP didn't look that bad when I studied it, glad sctp is supported by kernel.
<MTecknology> You know... I got accepted into ~ubuntu-kernel-team and I pretty much flipped out. Everyone at work knew I got into there. I thought I was special. Then I noticed I'm one of 20. I think I died a little inside.
<MTecknology> I guess I'll just need to set myself apart and be the bestest best of those 20. :)
<MTecknology> what makes bug 193830 need to be private?
<ubot2> MTecknology: Bug 193830 on http://launchpad.net/bugs/193830 is private
<the-fallen> Good Morning
<the-fallen> I am following the Howto at https://wiki.ubuntu.com/KernelTeam/GitKernelBuild (but used the vanilla gzip file instead if git). Kernel builds fine, Deb-Packages are created and can be installed. But when I install my kernel-header it creates the link for "build" in a way that it points to the sources, not to the headers
<the-fallen> so I wonder what I did wrong
<vishu> hi guys
<vishu> how can i monitor changes in file system
<vishu> i noted inotify but heard there is a better one like fschange but there is no /proc/fschange in my system
<vishu> hello???
<vishu> how to get fikesystem events in our program?
<vishu> *filesystem
<abogani2> apw, ogasawara : Are you around?
<shadeslayer> please tell me if i need to add more info to bug 593041
<ubot2> Launchpad bug 593041 in linux (Ubuntu) "New 2.6.35 kernel keeps toggling bluetooth radio (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/593041
<vishu> how to monitor a directory recursively in a program ,inotify is not recursive:(
<cwillu> vishu, you sure?
<cwillu> inotify-tools talks about recursive watching directories
<vishu> yeah is there something in kernel implemented with syscals
<vishu> one suggested fanotify but there is no proper resources in net
<vishu> fsnotify doesn't implement recursion it seems
<cwillu> ya
<cwillu> on the other hand, it's sane to implement recursion yourself via inotify
<cwillu> still only need one open handle
<cwillu> i.e., tracking the directories gives you notifications on the files, as well as enough information to follow directory creates/deletes/moves
<cwillu> and you'd have to scan new directories under any system, as they could be created outside the tree, populated, and then mv'd in
<vishu> hmm seems there is somethingg called fanotify in 2.6.34
<vishu> can you give a start for coding something to catch keystrokes globally
#ubuntu-kernel 2010-06-13
<MTecknology> In the lucid kernel git repo - there's Ubuntu-lts-2.6.35-2.3 <-- -lts and .35 are confusing me..
<bjf> MTecknology, we are going to be supporting back-ported kernels for lts (server)
<MTecknology> oh
<bjf> MTecknology, there is a blueprint somewhere about it ... just a sec
<bjf> https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts
<bjf> MTecknology, ^
<bjf> MTecknology, the blueprint doesn't have much info but the linked spec does
<MTecknology> bjf: thanks :)
<bjf> np
<KhaaL> Hey all, I'm using the latest RC kernel 2.6.35 from http://kernel.ubuntu.com/~kernel-ppa/mainline/ on Lucid. Its working well (i got decent I/O throughput and kernel 12309 seems to be solved!) but my soundcard Creative X-Fi ceased to exist. why is that, has something changed in alsa support in this kernel or should I have done something after the kernel installation?
<Sleep_Walker> AceLan: ping, please
<Sleep_Walker> AceLan: what relation is between araneo and erdos?
<Sleep_Walker> AceLan: are there any plans about newer versions of araneo?
<Flek74> hello, is here somebody?
#ubuntu-kernel 2011-06-06
<ppisati> morning
 * apw yawns at ppisati 
 * smb finishes glancing over most past email
<apw> smb, heh that was quick
<smb> apw, Yeah, not well done but quick
<apw> ppisati, yeah can hear
<ppisati> apw: ping
<apw> ppisati, yo
<apw> ppisati, lp:~canonical-kernel-team/ubuntu-cve-tracker/kernel-team/
 * apw steps out
<jwi> hm, was 2.6.38-10.44 copied to {lucid,maverick}-proposed by mistake?
<apw> jwi i would say so
<apw> jwi, thanks for the heads up, will investigate
<apw> commit 7467571f4480b273007517b26297c07154c73924 upstream.
<apw> ogasawara, yo ... you have added things to dublin adgenda, could you pm me a link?
<ogasawara> apw: yep, lemme get it
<apw> ogasawara, i think the janitor scripts could do with a slot if its not already there
<apw> ogasawara, good its already on there
<elmo> did lucid ever get anything newer than a maverick kernel as a backport?
<tgardner> elmo, Natty should be there by now. I'd have to check if its in updates yet. apw?
<apw> yeah i'd expect that to be in proposed by now
<apw> hmmm
<apw> hmmm not showing up, sconklin did say he was picking it up this round
<apw> smb, subject: xhci: Fix full speed bInterval encoding.
<apw> tgardner, elmo ok the natty branch was held up as it needs re-building for the USB 2.0 regression, i am going to sort that with steve
<elmo> apw: cool, thanks
<Protector1981> why does not exist an x86 3.0 kernel? or must i self compile?
 * ogasawara back in 20
<jwi> sforshee: re bug 787590 - you sure about that? latest -proposed seems to be based on 2.6.38.7, but the nvidia-fixup landed in 2.6.38.8
<ubot2> Launchpad bug 787590 in linux "USB power not turned off using nForce 590 SLI chipset" [Medium,Fix committed] https://launchpad.net/bugs/787590
<sforshee> jwi, you're right. I must have been on the wrong branch when looking at the changelog, I'll add a correction to the bug.
<apw> ogasawara, hey 3.0-rc2 is in the house ...
<ogasawara> apw: am already rebasing it :)
<apw> why am i not supprised, hopefully it'll fix my hp mini
<ogasawara> apw: yah, was gonna test it on there first thing
<apw> ogasawara, i'll get back to testing modprobe changes
<ogasawara> apw: were you able to get the fix applied and uploaded?
<ogasawara> apw: the m-i-t bits that is
<apw> ogasawara, in the intermin debian released a new m-i-t with the fix, and the recommendation was to sync whith that, which is complete and looking good, but the actual binaries need testing in anger
<apw> and i need to get someone to review the bzr branch to make sure i did the merge right so that future merges work right
<apw> hope to get it in today
<apw> ogasawara, actually if the -rc2 boots on the mini that would help my efforts a lot
<smb> sconklin, Hm, could the create-tracker-script be affected by the lp api change you mentioned, too? It seemed at least quite unhappy when I called it...
<apw> sconklin, i am wo
<sconklin> possibly but I doubt it's the same problem. Can you pastebin the failure?
<apw> wondering what changed there, thats a little worrying that we're being broken without apparent warning
<smb> sconklin, http://pastebin.ubuntu.com/619966/
<sconklin> ok, there were actually two problems - firstly, people who fetched the lpltk during a certain window got a bad validation check that resulted in a validation failure. That was subsequently fixed, and grabbing a new lpltk fixes it
<sconklin> The second is that launchpad used to return task names like this "kernel-sru-workflow  hyphenated-task-name"
<sconklin> and now it started using the display name like this: "Kernel SRU Workflow hyphenated-task-name"
<sconklin> which broke my task name parsing
<apw> oh thats so very helpful
<sconklin> I was so pleased to discover that at 9PM on a Sunday.
<sconklin> or maybe it was only 7PM.
<sconklin> smb: that's the first problem. Fetch the newest python-launchpad-toolkit and reinstall
<smb> Ok, so I had been pulling kteam-tools before trying that. Now I pulled the lpltk... 
<smb> looks better
<sconklin> Apparently code changes to the lpltk are not accompanied by unit tests . . .
<smb> at least it takes a looong time now... :)
<apw> tgardner, ppisati just notived that the fix we have committed for CVE-2010-4076/4077 is actually the fix for CVE-2010-4075 ... looks like you did that one, can you remember at all
<ubot2> apw: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076)
<ubot2> apw: The uart_get_count function in drivers/serial/serial_core.c in the Linux kernel before 2.6.37-rc1 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4075)
<tgardner> apw, hmm, looking...
<apw> ppisati, as the right fix for 4076/77 was applied via stable for natty and oneiric i think the right thing to do is just flip that one back en-toto and re-run over it
<apw> (which i can do once tgardner confirms our findings)
<apw> tgardner, if so, i will flip the bits back in the tracker so it gets done by somone
<sconklin> apw, ogasawara: you'll probably also want to make sure that the patch mentioned in my email is in the development kernel asap
<ogasawara> sconklin: which patch?  /me checks email
<sconklin>  [PRESTABLE] [PATCH] xhci: Fix full speed bInterval encoding.
<sconklin> https://patchwork.kernel.org/patch/837082/
<sconklin> ogasawara: ^^
<ogasawara> sconklin: yep, we got it when we rebased to 3.0-rc1 (not yet uploaded though)
<sconklin> ok, cool
<tgardner> apw, the commit referenced by http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076 appears to be the commit that was applied for 'tty: Make tiocgicount a handler, CVE-2010-4076, CVE-2010-4077'. Looks like the same commit _also_ fixes CVE-2010-4075.
<ubot2> tgardner: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076)
<ubot2> tgardner: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076)
<ubot2> tgardner: The ntty_ioctl_tiocgicount function in drivers/char/nozomi.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4077)
<ubot2> tgardner: The uart_get_count function in drivers/serial/serial_core.c in the Linux kernel before 2.6.37-rc1 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4075)
<apw> tgardner, ok thats not what the cve tracker says
<apw> active/CVE-2010-4075: upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d281da7ff6f70efca0553c288bb883e8605b3862
<apw> active/CVE-2010-4076: upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0587102cf9f427c185bfdeb2cef41e13ee0264b1
<apw> active/CVE-2010-4077: upstream: http://git.kernel.org/linus/0587102cf9f427c185bfdeb2cef41e13ee0264b1
<ubot2> apw: The uart_get_count function in drivers/serial/serial_core.c in the Linux kernel before 2.6.37-rc1 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4075)
<ubot2> apw: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4076)
<ubot2> apw: The ntty_ioctl_tiocgicount function in drivers/char/nozomi.c in the Linux kernel 2.6.36.1 and earlier does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4077)
 * apw slaps ubot2
<tgardner> apw, both cve.mitre.org reports reference the same commit 
<apw> ok so one or other is wrong ... will try and figure out which
<apw> tgardner, only 75 has CONFIRM: next to it tho, the others are MISC:
<apw> tgardner, but what you are syaing is that fix is the _one_ fix for 75 76 and 77, and the error is that 75 is not mentioned
<tgardner> apw, I think thats the case.
<ppisati> ok, so the fix in master actualy fixes all thrre
<ppisati> three
<tgardner> if indeed d281da7ff6f70efca0553c288bb883e8605b3862 _does_ fix 75
<tgardner> or rather, if indeed it _does_ fix 76/77 (which are _not_ maked CONFIRM)
 * ppisati -> linaro conf call
<ogasawara> apw: no joy for me on the hp-mini
<apw> ogasawara, dammit thats annoying, we'll prolly have to actually debug that one if its broke in -rc2
<apw> in my brief testing it was loading i915 which bust it
<apw> (in -rc1)
 * ogasawara will try to dig in further
<ppisati> apw tgardner: so what was the outcome? i apply the fix in master and be done with all 3 (75/76/77)?
<apw> ppisati, give me another 5 mins, i am just confirming it does fix all three really
<apw> then i can fix the tracker too
<ppisati> apw: no rush, i'm in a conf call now
<apw> tgardner, ok confirmed we need both commits for 76 and 77 to be fixed, i'll update the tracker to that effect
<tgardner> apw, ack
<sconklin> apw, you wrote the update-from-natty-master script?
<apw> sconklin, tim mostly, but i know it well, wassup
<apw> sconklin, in theory you just use that and it finds the latest tag on <series>/master and uses that
<apw> as a base for the rebase
<apw> once run you do need to commit the result
<sconklin> apw: I may just look myself if I have time - it copied the changelog (as it should) but it leaves in the release tracker bug. If that were not removed manually it could cause some very confusing things to happen on our status pages
<apw> sconklin, ahh ok, then that probabally should be fixed
<sconklin> it's working fine, this is more a feature request
<apw> how to detect the one to remove i wonder
<sconklin> well, you can safely remove them all I think. And the text near it is generated by a script so is consistent
<apw> sconklin, that sounds doable
<apw> ppisati, so that fix actually only fixed 4075, so when you copy it over mark it so
<ppisati> apw: k
<herton> I had one problem with update-from-*-master scripts too, its match usage was breaking mawk (which came by default in my natty install)
<herton> if (match($0, /UBUNTU: (Ubuntu-2\.6\.[0-9][0-9]*-([0-9][0-9]*)[^ ]*)/, a)) {
<herton> mawk doesn't have the third parameter, 'a'
<apw> mawk! wtf
 * apw notes that'll all break hideously with 3.0 as welll sigh
<herton> it was default on natty, had to install gawk manually :)
<apw> herton, did you work out a sensible non ,a form we could use which works with mawk or did you install gawk
<apw> heh :)
<herton> just installed gawk, don't know what could be done about mawk
<herton> apw: ", a" isn't being used, so could be removed
<apw> herton, ahh ok, will look at that when i am fixing the 2.6 issue
<ppisati> but why did they switch awk interpreter?
<herton> dunno, probably it's faster, and to break scripts :)
<smb> coolness... :.P
<smb> and its smaller...
<ppisati> actually i just found out that it's there since end of 2007
<ppisati> at least
<ppisati> http://ubuntuforums.org/showthread.php?t=619985
<apw> pgraner, btw, that "30% power" issue may be found and a patch in stable
<pgraner> apw, oh nice, what was it?
<apw> rounding error in a time calculation leading to miss calculation on whether its worth slipping into lower c states
<pgraner> apw, cool
<apw> ogasawara, have a serious performance issue on kernel install with the new m-i-t, still working on them
<ogasawara> apw: ack
<apw> and the -rc1 kernel doesn't work on either of my atoms, 32 and 64 bit respectivly
<ogasawara> apw: yuck
<apw> ogasawara, which is making mit testing very hard too
<apw> ogasawara, given all the problems i am likely going to just bodge the current mit and upload that
<apw> ogasawara, to unblock you and then i can fix mit at my leisure
<apw> ogasawara, though if we can't boot this on any atom i am worried about uploading it, as they are common scrappers for testing
<ogasawara> apw: yep, not sure if we really want to upload knowing it fails to boot on some common cases
<ogasawara> apw: I can at least work around the hp-mini booting with i915.modeset=1
<apw> ogasawara, i managed to get it half working by booting init=/bin/bash, then it dies when modprobe i915
<apw> with =1 ?
<ogasawara> err =0
<apw> which disabled i915 doesn't it?
<apw> ogasawara, but thats useful for testing here for mit
<apw> ogasawara, are you going to attmept to debug the mini while i finish mit ?  i presume i am not blocking you till then
<ogasawara> apw: yep gonna keep debugging, you're not blocking me
<sconklin> smb: please let us know when the ec2 branch is finished, and whether it's test built and been test booted? Then we can package it
<apw> ogasawara, ok will keep working this perf issue for the moement and get it uploaded my morning when i have reviewers
<smb> sconklin, Well test booted not really yet (though I did that before the uhci addition) and its nearly compile done in the ckt ppa
<smb> Just waiting for i386 currently
<smb> sconklin, branch and meta branch pushed back already
<kees> apw: for 720189, I thought the thing we agreed on was to make a new bug instead of reopening the old one?
<apw> kees, hmmm good point, i'll un bork that
<smb> sconklin, Ok, lucid-ec2 is prepared. Seems ec2-meta is waiting for some publishing step but should be there soon
<sconklin> smb: ok, thanks
<mpoirier> ogasawara: good morning
<ogasawara> mpoirier: morning
<apw> ogasawara, i can confirm you i915.modeset=0 'fix', which concurs with my feeling it was loading that which broke stuff
<mpoirier> I took a look at the patches you identified
<mpoirier> vdd_sdi, for omap processors.
<mpoirier> ogasawara: those patches have been refused upstream.  Arnd wanted an change to how the display subsystem was discovering the output, somehting I couldn't do.
<mpoirier> ogasawara: I'm sure it was fixed by someone but I don't have the HW anymore.
<ogasawara> mpoirier: do you know who has hw now?
<mpoirier> ogasawara: no clue - mobile team most likely.
<ogasawara> mpoirier: if it was indeed fixed, we could probably drop those patches, but would be good to test and confirm first.
<mpoirier> ogasawara: ya, I'd like to test before giving the go ahead.
<ogasawara> mpoirier: thanks, I'll make a note to carry them for now and drop only after testing
<mpoirier> ogasawara: ok.  on another front,
<mpoirier> ogasawara: on https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview it is said that we carry 534 patches on top of mainline.
<mpoirier> ogasawara: what is the suite of instruction you did to come up with that ?
<ogasawara> mpoirier: we have a script we use, it's in kteam-tools, lemme find the exact name
<mpoirier> cool.
<ogasawara> mpoirier: kteam-tools/devel/reconcile-generic
<mpoirier> ogasawara: ok, I'll take a look - thanks.
 * tgardner --> lunch and server room
 * ppisati -> gym
<CarlFK>  "Could you add "pciehp.pciehp_debug" to kernel parameter"   add that to APPEND line, or stuff in some /etc conf file?
<ohsix> theres /etc/default/grub, but people typically mean editing the command line from grub, then booting with it
<CarlFK> ah right.  thaks
<ohsix> if you modify /etc/default/grub you'll want to run update-initramfs
<CarlFK> Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.39-3-generic root=UUID=7a5a1e63-
<CarlFK> 8e75-443f-b732-522709dd36d6 ro vt.handoff=7 pciehp.pciehp_debug
<CarlFK> any idea why I don't see anything new in dmesg? 
<sconklin> sarahsharp: hi!
<sarahsharp> sconklin: hello!
<CarlFK> One of these did it: kernel ... pciehp=pciehp_debug -- pciehp.pciehp_debug
<mpoirier> ogasawara: can you show me the cmd line you used when calling reconcile-generic ?
<ogasawara> mpoirier: for example:  reconcile-generic master v2.6.39
<mpoirier> master being the ubuntu code base ?
<ogasawara> mpoirier: yes
<kees> I sent two patches for the kteam-tools branch but they haven't gotten in; can those get pulled?
<kees> sconklin: where can I find the scripts that are processing the workflow bugs?
<tgardner> kees, I bugged him about getting them reviewd
<bjf> kees, i added part of the patch and commented on it
<kees> I just wanted to see how he was fetching the list of open bugs for a given series
<sconklin> kees: one sec
<bjf> kees, kteam-tools/stable/sru-workflow-manager
<sconklin> I'm multitasking badly
<bjf> sconklin, np, i got it
<kees> bjf: ah, sorry, I didn't see the email reply.
<sconklin> thx
<kees> bjf: ah, I see, you rewrote the verbosity bits. the CVE speed up wasn't added, should I resend that part?
<bjf> kees, you could reply to my email about the patch :-)
<kees> bjf: i will :)
<kees> apw: any thoughts on https://lists.ubuntu.com/archives/kernel-team/2011-May/015693.html ?
<bjf> kees, my questions about that patch were: 1, why have we not run into any problems using linkCVE ? and 2, you are turning that into a manual step for all CVEs is that overkill?
<kees> bjf: because you've only created bugs after the CVE appeared in mitre and was imported into LP already. if I'm going to be using this, it may include CVEs that are not yet in mitre
<bjf> kees, what does it do if you try to use linkCVE and the CVE doesn't exist?
<bjf> kees, does it throw an exception or does it fail silently?
<kees> bjf: one sec (phone)
<sforshee> tgardner, bjf: can one of you approve my nomination on bug #762987?
<ubot2> Launchpad bug 762987 in linux-firmware "RT2870 WLAN Stick (D-Link DWA 140) not working. firmware does not support detected chipset" [Undecided,Fix released] https://launchpad.net/bugs/762987
<bjf> sforshee, done
<sforshee> bjf, thanks
<kees> bjf: afair, it throws an exception
<bjf> kees, then wouldn't it be better to handle that exception, using linkCVE when we can and only adding the "comment" when necessary?
<kees> bjf: walking the CVE list takes forever, though. doing a comment will hook the back-end logic that actually creates the link, so it's the best way to go, imo
 * jjohansen -> lunch
<bjf> kees, you've worn me down, and i'll apply the patch, though it sounds like the justification is "LP is slow so do it manually"
<bjf> kees, and it would seem that rule would apply to most LP things
<kees> bjf: the problems are LP: #322560 and LP: #439470
<kees> if 322560 was fixed, you could instantly look up a given CVE. instead, you're force to the the time-consuming walk
<kees> if 439470 was fixed, you could just link immediately
<kees> so, basically, we just skip both, and do a comment. it'll attach the CVE no matter what.
<bjf> kees, it's a script, i don't care how long it takes to walk it
<kees> bjf: heh. well, since I'll be using it, I'd like it to be fast since I'll be manually adding CVEs while doing CVE triage
<bjf> kees, applied and pushed
<kees> bjf: cool, thanks!
<sconklin> tgardner: do you know what's required for packaging lts-backports kernels? I have a few questions. Do we use the tarball from the first upload as the .orig or do we upload full source each time?
<sconklin> and, we include the entire changelog each time because of the way it's rebased, right?
<tgardner> sconklin, I think I did the full source upload. I can check though. gimme a sec.
<bjf> ogasawara, questions about the meeting agenda
<tgardner> sconklin, there is no orig tarball in the archive
<ogasawara> bjf: sure
<sconklin> tgardner: so basically package it without using -v and upload it . . .
<tgardner> sconklin, I'd use the -v option 'cause there is always a delta from the package in -updates. It'll do the right thing using the -sa option, even when there is no orig tarball
<sconklin> ok, great, thanks
 * tgardner --> EOD
<ohsix> hi, getting panics i was getting on .39 on the newly released .38-10: http://img847.imageshack.us/img847/2017/dscn0955v.jpg
<ohsix> ok i can make it happen with some regularity if i write something to the drive (cat /dev/zero > /media/blah/temp for a few seconds), kill it then eject
<ohsix> how do i translate these numbers to something i can look at in git? 2.6.38-10.44 (other is -9.43, trying to track down something related to that panic)
#ubuntu-kernel 2011-06-07
<ohsix> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/793796 i filed a bug about it, if anyone has appropriate tags to add; or people to subscribe
<ubot2> Ubuntu bug 793796 in linux "2.6.38-10 panic after ejecting drive" [Undecided,New]
<ohsix> woo confirmed, i wonder if someone was waiting for a report :D
<apw> ohsix, the confirmed update was likely a bot
<apw> ohsix, can you get the picture attached to the bug please
<ohsix> i attached one, did it not make it?
<apw> ohsix, bah you did, stupid interface hiding it from me
<ohsix> there were only 2 scsi/block/vm patches in the changelog that might have something to do with it but none that i can see how
<ohsix> you can probably reproduce it easily enough; it's on x86_64 but i don't know if that matters
<apw> ohsix, yep i am sure they will, i've seen similar on .39, but neither of those boxes boot at the moment
<apw> i've tagged it up for the stable peep to sort out
<ohsix> i was trying .39 from the xorg-edgers ppa for other reasons & hit it a week or two ago; didn't report a bug but i did tell one of the guys on top of that stuff
<jussi> Morning all
<jussi> Ive managed to reproduce https://launchpad.net/bugs/792291 and the machine is still on, is there anyone about that can help me get anything out of the machine to help debug? 
<ubot2> Ubuntu bug 792291 in linux "Machine hung, display frozen" [Undecided,Confirmed]
<apw> jussi, do you know what you did to reproduce it?  if so record that
<apw> i seem to remember we didn't know if the machine is still alive on the network or not, you could try and determine that
<jussi> apw: unfortunately not, its happened several times, at random intervals.
<jussi> apw: let me try
<jussi> Hrm, Ive no idea of that machines ip (we have a dhcp system here), but the network lights near the cable are still blinking
<apw> jussi, if you know the machine name, name.local often works as a hostname on the local lan
<jussi> yeah, it doesnt appear to be reponsive
<apw> jussi, and you have tried the sysrq options out?
<jussi> ahh, reisub rebooted it. 
<apw> jussi, so in theory you may have some output in your logs sync'd to disk maybe, cirtainly worth looking now
<apw> jussi, and record that reisub did something too
<jussi> apw: ok. which logs in particular are wothe looking at ?
<apw> syslog contains the output of dmesg if we are lucky
<apw> looknig for sysrq may help
<smb> morning
<apw> smb, moin
<apw> jussi, was this the one with a moving mouse cursor ?
<jussi> apw: no, total freeze, different machine
<jussi> is it safe to pastebin the syslog? 
<apw> jussi, has this problem aways existed on natty?
<apw> (trying to work out where it might have been introduced)
<jussi> apw: we only bought/installed the machine a few weeks ago, and it has happened several times since
<apw> jussi, i think pastbin is ok, you could grep for your password and name before
<apw> jussi, ok so we have no idea if its a regression
<apw> jussi, was there anything interesting in syslog ?
<jussi> apw: Im looking, but let me share it with you also, because Im not certain what to look for.
<ohsix> jussi: are you running 2.6.38-10 on that?
<jussi> ohsix: no, 2.6.38-8 (x86_64)
<apw> Jun  7 10:32:05 monster kernel: [81028.414275] SysRq : Keyboard mode set to system default
<apw> Jun  7 10:32:07 monster kernel: [81029.756536] SysRq : Terminate All Tasks
<apw> ok so the machine was alive per-se
<apw> as the logging deamons saw the sysrq keys and reported them
<apw> so that is useful information and should be recorded in the bug
<jussi> apw: Ill attach that syslog if you think its useful (and doesnt contain too personal stuff)
<apw> jussi, also the fact there isn't any panic before the Sysrq
<jussi> right, so its likely not in the kernel then.
<apw> jussi, include like 5 lines before the SysRQ and the first couple of sysrq things
<apw> jussi, its as likely X i'd guess
<apw> so next time jussi could you do the sysrq-R then try to switch VTs
<apw> and also then try Sysrq-w, to see if anything is hung
<apw> then perhaps Sysrq-t
<jussi> apw: ok, sure.  Thank you for taking the time to help. 
<apw> now the latter will take a while likely, you should be able to see it producing disk activity i suspect as the logs are being pulled out
<apw> (maybe leave it for 1min after then continue with the reisub)
<apw> then look for those in your syslog and see hwats there
<jussi> apw: excellent. Ill note that down for next time something happens. 
<apw> jussi, good luck
<jussi> apw: Thanks - I think Ill need it. :D
<apw> jussi, i've recorded that in the bug for posterity
<jussi> apw: excellent! :D
<Kano> hi, where are the daily builds? also 3.0-rc2 is missing
<apw> Kano, they are missing because some fool changes the version number radically and breaks every damn tool we have
<Kano> well that was done with rc1, no time to fix em yet?
<apw> yes we fixed it in part last time, but not comopletely it seems
<ohsix> haha
<Tommeh> There was some discussion on the release announcement about the tarball being screwed, at least originally.
<Tommeh> Presumably the kernels are built straight from git though?
<apw> Tommeh, luckily we don't use the tarballs
<Tommeh> ah
<apw> but we are getting hammered by the tags not being v2.6.*
<cking> what fun
<apw> i know ... and right now i can't build them with the right version as module-init-tools specifically depmod won't work
<apw> ARRRRG
 * apw bounces to verify a unity bug which someone has FIXED !?!
<amitk> lol
<apw> seems to work too ... amazing, shame i have found another new bug now
<jk-> hey apw
<apw> jk-, hiya
<tgardner> apw, ogasawara, AceLan: tangerine needs a reboot for kernel update. lemme know when is a good time.
<apw> tgardner, don't believe i am using it currently
<ogasawara> tgardner: am in the middle of a quick build, will ping you when it's done
<ogasawara> apw: I'm hopefully zeroing in on the bad commit for the hp mini
<apw> ogasawara, awsome, bisecting ?
<ogasawara> apw: yep.  your mainline-build-one script comes in handy
<apw> :) thats something
<ogasawara> I went ahead and pushed the -rc2 rebase to master-next, if anyone wants it
<apw> ogasawara, i assume its no more working than before
<ogasawara> apw: nope, still the same
<ppisati> tgardner: rsu added
<ppisati> *SRU
<tgardner> ppisati, ack
<ogasawara> tgardner: your good to reboot tangerine from my end
<tgardner> bouncing
<apw> you're
<ogasawara> damn, you know it's bad when apw corrects your misspelling :)
<apw> ogasawara, an embaressment indeed
<ogasawara> hehe
<tgardner> ogI just figured apw had blurted a sentence fragment
<tgardner> ogasawara, ^^
<ppisati> thunderbid formatting of emails is really annoying
<ppisati> i can't make a message without stupid formatting...
<sforshee> tgardner, ogasawara: can one of you accept my natty nomination on bug 770232 ?
<ubot2> Launchpad bug 770232 in linux-firmware "148f:3072 Ralink RT3072 WLAN not working with rt2800usb - firmware missing" [Undecided,Incomplete] https://launchpad.net/bugs/770232
<tgardner> sforshee, done
<sforshee> tgardner, thanks!
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
 * ogasawara back in 20
<apw> ppisati, remind me, mvl-dove is identicle in lucid and maverick isn't it, and we update lucid
<ppisati> apw: yep
<ppisati> apw: i think tomorrow i'll do the rebase
<apw> ppisati, whenever, just interested for a cve i am finishing up
<apw> tgardner, about ?  i see we don't have armel cross compilers in our lucid chroots on tangerine, is this something we can get easily from somewhere?
<tgardner> apw, I'm not sure they exist for Lucid unless we pull the deb from Maverick
<apw> oh hrm, bugger
<tgardner> herton, please have a look at bug #794096. It loooks like it could be a stable update regression.
<ubot2> Launchpad bug 794096 in linux "SMTP and posting to a web-form time out (probably due to netfilter changes)" [Undecided,In progress] https://launchpad.net/bugs/794096
<herton> tgardner: ack
 * herton --> lunch
<apw> smb, about?  got a sec to review a debdiff for m-i-t for me ?
<smb> apw, currently taken up in server meeting 
<smb> a min
<apw> smb np
<smb> apw, k, they moved on. what where?
<apw> chinstrap:~apw/DEBDIFF
<apw> HRM somethign bad happened when i right clicked on a link
<apw> X exited
<bjf> ##
<bjf> ## Kernel team meeting in 15 minutes
<bjf> ##
<cking> already? where did the day go?
<ppisati> yep
<ogasawara> bah, it helps if I actually install the test kernel I downloaded before I reboot
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
<smb> Gah! its time
<Sarvatt> smb: a minute later and you would have missed the meeting :)
<smb> Sarvatt, Too true. :)
<ogasawara> apw: cool, I've isolated the regression
<ogasawara> commit 6067aaeadb5b3df26f27ac827256b1ef01e674f5
<ogasawara> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
<ogasawara> Date:   Thu Apr 28 15:04:31 2011 -0700
<ogasawara>     drm/i915: split clock gating init into per-chipset functions
<ogasawara>     
<ogasawara>     This helps contain the mess to init_display() instead.
<ogasawara> apw: and it appears there's already a fix coming down the pipe
<ogasawara> apw: https://lkml.org/lkml/2011/6/5/12
<ogasawara> apw: gonna build us a test kernel to verify
<bjf> ogasawara, i just modified the moin paragraph levels that kt-meeting-stats generates, be sure to use the latest version
<ogasawara> bjf: ack
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - June-14 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * tgardner --> lunch
<apw> ogasawara, awsome, let me have some test kernels when you've tested :)
 * apw waits with baited breath for ogasawara's testing results
<ogasawara> apw: \o/, it works.  debs are on tangerine in my oneiric-i386 dir
<tgardner> ogasawara, this is for an HP mini?
<ogasawara> tgardner: yep
<ogasawara> tgardner: am gonna push the fix to master-next
<tgardner> ogasawara, cool, I'll give it a try as well.
<ogasawara> apw: if you can, would you also test on the other atom kit you said was having issues with -rc1.  just curious if it's still there with an -rc2 kernel.
<apw> ogasawara, i've got both 32 and 64 bit suffering, got and 64bit debs ?
<ogasawara> apw: I'll kick off a build right now
<apw> ogasawara, good on my 32 bit machine (not the mini)
<apw> yell when we have amd64s
<ogasawara> apw: should almost be finished up
<ogasawara> apw: it'll appear on tangerine:oneiric-amd64
 * jjohansen -> lunch
<apw> ogasawara, i'll watch for it
<ogasawara> apw: generic flavour should be there now
<tgardner> ogasawara, how come you aren't using 3.0.0-0.1 in the oneiric changelog ? There are still 3 version digits in the Makefile
<apw> tgardner, cause it isn't going to be called 3.0.0 but 3.0 when it releases
<apw> tgardner, and if we use 3.0.0 we can't go back down to 3.0 which is <
<apw> he only put the extra .0 in the makefile cause you couldn't build it without it at the time
<tgardner> apw, but this is a packaging version thats only loosely related to the kernel version.
<apw> tgardner, that is true, but we were trying to continue the current system which is to use the version before stable 
<tgardner> apw, and I suspect the first stable version will be 3.0.1, right?
<apw> tgardner, yep, but we don't expose the stable version in our package version
<apw> 2.6.38.8 is still 2.6.38 in the archive
<tgardner> apw, right, as will 3.0.0-ABI-N
<tgardner> it will simplify a lot of our scripting problems if we use 3 digits.
<apw> tgardner, we can do that, its just a change in meaning
<apw> tgardner, though all the scirpting issues we have look to be cause we have Ubuntu-2.6 as searches and the like
<apw> not so much because of the length of the prefix right ?
<tgardner> apw, well, I was thinking about the regexes that extract ABI and the like
<apw> they should be using the 'before' and 'after' really
<apw> they should be using the 'before' and 'after' the - really
<tgardner> apw, perhaps, but fixing them in all places will be a PITA
<apw> tgardner, i think that most of it is working now, that isn't using 2.6 as far as i can tell
<tgardner> I'm thinking about the LTS backports as we go forward.
<tgardner> All of our Lucid stuff wants 3 digits. (I just don't know where yet)
<apw> the lts backports carries the whole changelog and debian machinary with it no?
<apw> the only thing which needs a little love is depmod and that is easy to fix
<tgardner> likely, but its easy to avoid the 'noid by just carrying the 3rd digit. I hate inconsistencies and special  cases
<apw> well it feels like an inconsistancy to represent 3.0 with an extra digit and not 2.6.x
<apw> but i am happy to be persuaded
<tgardner> well, lets see how it goes. we've got a little time before things get cast in concrete
<apw> tgardner, as long as we start with 3.0 we can move 'up' to 3.0.0, the inverse is not possible
<apw> ogasawara, ok this looks good for me, i'll get these two uploaded together and tested, then we can upload to the archive in the morning
<ogasawara> apw: ack, sounds good
<Guest24499> hi - just installed natty.  would like to try out xen - any pointers?  I last tried xen about a year ago, but heard that the 4.1 is much better
<Guest24499> google points me to pages that require manual kernel config/make
<Guest24499> is this the right place to ask?
<apw> Guest24499, i am not sure that the .38 kernel has all the pieces you need to for a dom0 kernel which makes it hard to do
<Guest24499> previous versions of ubuntu has xen-dom0 kernels - natty doesn't have it?
<jjohansen> Guest24499: hardy was the only kernel that had all the pieces for xen-dom0
<Guest24499> ahh
<jjohansen> they have all had the domU pieces
<Guest24499> I guess I was lucky when I last tried xen I hit hardy :)
<jjohansen> the oneiric kernel (11.10) will have the pieces for dom0 and domU
<Guest24499> should I try 11.10 then?  is it even in beta yet or in a position to be used?
<jjohansen> Guest24499: its because since hardy we have tried to follow upstream, where in hardy we had a special xen kernel
<jjohansen> Guest24499: its not in beta yet, and the upstream 3.0 kernel that has all the domo pieces is at rc2
<jjohansen> and uhm isn't the most stable thing at the moment
<Guest24499> so, would it be a good idea to follow https://help.ubuntu.com/community/Xen and compile my own kernel?
<jjohansen> at least from my experience
<Guest24499> heh.
<jjohansen> Guest24499: you could, or you could try the oneric kernel
<Guest24499> man, linux has changed so much from my slackware days...
<jjohansen> Guest24499: just don't expect all the bugs to be ironed out yet
<Guest24499> so the oneric kernel should be ok for dom0?
<jjohansen> Guest24499: yes it should
<Guest24499> any pointers or URLs for a quick howto to pin a oneric kernel to natty?
<jjohansen> I would just download and install the package
<jjohansen> dpkg -i <package-name>.deb
<jjohansen> Guest24499: packages can be found on packages.ubuntu.com
<Guest24499> ok, thanks
<jjohansen> just search in oneiric for linux
<Guest24499> umm, I'm in http://packages.ubuntu.com/oneiric/kernel - don't see any kernels?
<jjohansen> http://packages.ubuntu.com/oneiric/linux
<jjohansen> Guest24499: ^
<Guest24499> ahh, in admin
<Guest24499> not in kernel
<tgardner> ogasawara, so, how are you building this oneiric pile ? I'm getting some really weird errors. 'WARNING: Couldn't open directory /home/rtg/oneiric/ubuntu-oneiric/debian/linux-image-3.0-0-generic//lib/modules/2.6.38-10-server: No such file or directory'
<ogasawara> tgardner: using the kteam-tools buildscripts.  but a usual fakeroot debian/rules binary-generic should work too
<tgardner> ogasawara, thats what I'm doing. hmm
<tgardner> ogasawara, are you keeping a log of your builds? I'm thinking this might be some fallout due to the 2 digit version number. to whit: 'Missing argument in printf at debian/scripts/abi-check line 174.'
<ogasawara> tgardner: yep, look on tangerine:oneiric-amd64/build.log
<ogasawara> tgardner: you have apw's patches to fix up the version?
<tgardner> ogasawara, no, I just pulled from the repo.
<apw> tgardner, that is the bug with depmod, you need an up to date m-i-t in the chroot
<tgardner> apw, ah, thats it
<apw> tgardner, tangerine in my home are some fixed ones
<tgardner> apw, which one ?
<apw> once they are built in my PPA i'll be uploading them to the archive
<tgardner> 3.13-1ubuntu1~test4 ?
<apw> those sound right yes
<apw> module-init-tools_3.13-1ubuntu1~test4_amd64.deb
<apw> module-init-tools_3.13-1ubuntu1~test4_i386.deb
<apw> those are the right ones
<apw> ogasawara, this kernel is looking nice, am pretty sure my fans are on less
<ogasawara> apw: definitely in much better shape than we were a few days ago
<apw> ogasawara, yeah ... 
<tgardner> ogasawara, LKML: Re: 3.0.0-rc2 fails to boot on Atom appliance (bisected, drm/i915)
<ogasawara> tgardner: thanks will take a look
<tgardner> ogasawara, looks like you bisected to the same patch
<kees> apw, ogasawara: bug 771445 in hardy (commit 5caf3ae4c4bed98bd6148021e6e934d94b5dea1d) mentions "backport of commit 272b62c1f0f6f742046e45b50b6fec98860208a0" but it is actually a backport of commit b00916b189d13a615ff05c9242201135992fcda3. the resulting hardy kernel is fine, but we have now a tracking glitch. how should we handle this?
<ubot2> Launchpad bug 771445 in linux-ti-omap4 "CVE-2010-4655" [Undecided,In progress] https://launchpad.net/bugs/771445
<apw> kees, hrm, thats a bit of a problem, i suspect we need an exceptions table for my match up tool
<apw> kees, to handle that ... let me think about it
<kees> apw: okay, cool.
<apw> i think only my tool needs to handle any errors
<kees> well, it's a bit odd since I'll only discover this when comparing u-c-t against the changelog. in this case I found an extra CVE in the changelog and went looking for it, at which point we can add exception maps, etc
<apw> kees, yeah, but i suspect there will be more than one error in there over time
<apw> and i've already wanted to mark an old commit as being a cherry-pick when it wasn't which would use the same
<apw> mapping table.
<apw> anyhow will let the shower brain think about it
<apw> i fear my tooling will keep unding any corrections otherwise
#ubuntu-kernel 2011-06-08
<poolie> tjaalton: hello? 
<poolie> did you want me to try all of http://kernel.ubuntu.com/git?p=lexical/lexical-natty.git;a=shortlog;h=refs/heads/lp788026 or bisect through it or ...?
<jk-> poolie: we've got you hacking the kernel now huh? :)
<poolie> as i said on status.c.c getting away from rebuilding the kernel to work around hardware bugs is why i installed ubuntu in the first place :-P
 * jk- hands poolie a typewriter
<poolie> ?
<jk-> no bugs!
<jk-> :)
<poolie> heh
<poolie> i bet they do these days
<jburkholder> hi folks
<melkor> good evening.  I just tried the 3.0 kernel, and my wireless doesn't work.  I'm using the ath9k drivers normally.
<melkor> I am not so worried about it, I will just go back to my previous kernel, but I thought you might like to know.  I got warnings about missing firmware when I installed it.
<lamont> Generating grub.cfg ...
<lamont> /usr/sbin/grub-probe: error: raid5rec is not loaded.
<lamont> wtf?
<tjaalton> poolie: \o/
<poolie> tjaalton: :-(
<poolie> it's better but it's not all the way
<poolie> but, it's better :)
<tjaalton> ah
<poolie> i replied
<poolie> i'm going to stop futzing with it, unless you have things you specifically want me to test, in which case i'm happy to do that
<tjaalton> oh damn, I didn't read that comment
<tjaalton> poolie: ok, we'll see
<tjaalton> poolie: would be nice to see if some of the other commits from .39-rc1 to drm/i915 would fix these (if they are all absent in -rc3). also, could you clarify if they are regressions from .38 or not
<poolie> so that is to say:
<poolie> which of these problems are in 39-rc1? and which are in current 38?
<tjaalton> right
<tjaalton> well, just rc1 wouldn't cut it, there are a couple of fixes from rc2 that's included in the branch, but if you feel comfortable building kernels, then you could try cherry-picking stuff from rc1 (that touched drivers/gpu/drm/i915, ~71 commits left to test :), that would be great
<poolie> it's going to be hard to tell which are regressions because they're masked by the more fundamental bugs
<poolie> like, if the external display just doesn't work, i don't get the chance to see if it doesn't work from suspend
<poolie> but i can try cherrypicking more stuff, probably
<tjaalton> ah, right, of course..
<ppisati> morning
 * apw yawns
<apw> moin ppisati 
<smb> morning
<apw> smb, moin
<abogani> morning all
<smb> abogani, morning
<apw> [  129.102338] wlan%d: authenticate with 00:0f:b5:b3:4c:ca (try 1)
 * ppisati back in 20mins
 * apw giggles 
 * smb thinks apw does think strangle sometimes... But then he can think of what he thinks of...
<arun_mittal> hey guys i upgraded my system from 9.04 to 10.04, but now i am getting an error and i can not login to my system , error "init: rc-default main process terminated with status 127"
<arun_mittal>  any help with this !!!
<apw> arun_mittal, that doesn't sound like a kerenel error, possibly something upstart might day
<apw> say
<apw> have you asked on #ubuntu ?
<amitk> 9.04 -> 10.04 update (is that even tested?)
<ogra_> -neither tested nor supported
<apw> arun_mittal, how did you do the upgrade?  direct one release to the one two later ?
<ogra_> and likely the cause of the above
<arun_mittal> apw, they asked me to go on ubuntu-kernel
<ogra_> arun_mittal, tell them #ubuntu-kernel isnt a support channel next time ;)
<apw> arun_mittal, how did you do the upgrade?  direct one release to the one two later ?
<arun_mittal> direct from 9.04 to 10.04
<arun_mittal> apw, direct from 9.04 to 10.04
<apw> ok and using what commands
<apw> cirtainly an upgrade like that isn't tested so it not working does not supprise me
<arun_mittal> apw, apt-get upgrade
<apw> ok and that isn't the way to upgrade from one release to another either
<apw> you should have used upgrade manager to update via the intermediate release (for next time)
<ogra_> whoever told you to upgrade like that should actually fix your issue ;)
<arun_mittal> apw, before that i set sources.list to 10.04 rep
<Tommeh> arun_mittal: that's why it broke.
<arun_mittal> :)
<apw> and if do it by hand you would use dist-upgrade not upgrade
<Tommeh> You did something silly. ;)
<amitk> (ouch!)
<apw> and now you are in a huge hole
<apw> arun_mittal, are you able to get to a prompt with working network ?
<arun_mittal> apw,  No
<apw> ouch
<arun_mittal> apw,  i was in middle of my work and done this shit
<Tommeh> Hahaha
<apw> do you have a livecd or bootable memory stick ?
 * amitk would back up my data using boot disk and reinstall
<Tommeh> Or you could try booting the 10.04 livecd and see if you can fix it via a chroot.
<arun_mittal> i ahve live Cd but no cd drive :P
<Tommeh> long-shot though.
<apw> amitk, in theory they can do apt-get install ubuntu-desktop^ and it will sort out the mess
<apw> _if_ they can get to a prompt with network
<arun_mittal> now i am getting a CD drive first
<amitk> apw: true
<apw> so once you are booted from a cd you can mount up your root, bind mount /dev into it, chroot in, mount up /sys and /proc, and then try apt-get install ubuntu-desktop^
<apw> and the trailing ^ is critical
<apw> and then write 200 lines "i will use upgrade-manager to upgrade my system next time"
<smb> possibly do-release-upgrade when you don't have X (like a server)
 * ogra_ wonders how installing the ubuntu-desktop task would fix your upstart configuration
<smb> ogra_, It does sort of force pull in anything that desktop dependson , hope is to catch things that might got missed/not upgraded before
<smb> maybe a slight hope only...
<ogra_> smb, you are still missing the 9.10 upstart version  
<ogra_> which very likely has transition bits that are missing in the system now
<smb> could well be...
<smb> I guess it could end in "backup everything or at least all /home" and do a fresh install now
<ogra_> yeah
<Kano> hi, could somebody fix the 32 build buils of 3.0 kernel?
<apw> Kano, why are they fialing
<Kano> look into the log
<apw> you have such a way with words, so encouraging to people who you want things from
<Kano> you dont want to test the kernel?
<apw> i don't use the mainline builds to test the kernel
<apw> i use the ubuntu kernel to test the ubuntu kerenl, it is a more appropriate test
<Kano> i use u style kernel only for live mode. for testing i think mainline is better because it does not add extra patches
<apw> apw@dm$ cat /proc/version_signature 
<apw> Ubuntu 3.0-0.1~apwv1-generic 3.0.0-rc2
<apw> that may be true for you, for the ubuntu kernel team tesing the ubuntu kernle is clearly the most appropriate kernel to test
<apw> looking at why the mainline builds are not building on 32 bit is on my list, but not high on it right now
<apw> if someone tells me whats wrong then thats a smaller job and it may get done earlier
<Kano> dont they use the same config like your other builds?
<apw> yes they use the same configs, thats how i know its not a conig issue
<amitk> apw: you guys have an offline tool to mass-manipulate several LP blueprints at once?
<apw> amitk, nothing for mnipulaitng blueprints in my toolbox sadly
<apw> amitk, i know how to consume them, not change them
<amitk> apw: consume them? I need something to make mass changes to a group of blueprints (subscribe a group, set milestones, priorities, etc.)
<amitk> dunno how much of my life is wasted going through the slow web frontend
<apw> amitk, no i don't really have that many, i think there may be launchpad lib interfaces though
<tgardner> apw please take a moment to review https://lists.ubuntu.com/archives/kernel-team/2011-May/015693.html so I can get it out of my inbox
<apw> tgardner, replied, not sure the changes work mind
<tgardner> apw, I'm fine with that. just wanted to be sure kees was getting some attention.
<apw> tgardner, yep guessed as much
<tgardner> apw, looks like I should update the chroots for m-i-t ?
<apw> tgardner, yes please
 * apw watches the weather take a vile turn ... i can hardly see out the window its raining so hard
<apw> tgardner, when i looked yesterday maverick didn't have the compiler installed, only the -base package -- meant to mention it
<apw> (on tangerine)
<tgardner> apw, the cross compiler ?
<apw> tgardner, indeed
<apw> in natty there are two packages foo and foo-base iirc, and on maverick only the latter
<tgardner> apw, gcc-arm-linux-gnueabi g++-arm-linux-gnueabi
<tgardner> apw, those are the 2 packages that get installed for either chroot
<apw> in maverick-i386 we have:
<apw> ii  gcc-4.5-arm-linux-gnueabi-base      4.5.1-7ubuntu1cross1.38             The GNU Compiler Collection (base package)
<apw> and in natty we have:
<apw> ii  gcc-4.5-arm-linux-gnueabi         4.5.2-8ubuntu3cross1.47                The GNU C compiler
<apw> ii  gcc-4.5-arm-linux-gnueabi-base    4.5.2-8ubuntu3cross1.47                The GNU Compiler Collection (base package)
<apw> and i found yesterday i could only build in the natty one ... 
<apw> (i meant to mention it when i was talking to you about crosses then)
<apw> tgardner, ^^
<tgardner> apw, (maverick-i386)rtg@tangerine:~/kteam-tools/chroot-setup$ dpkg -l|grep "gcc.*arm"
<tgardner> ii  gcc-4.4-arm-linux-gnueabi           4.4.4-14ubuntu4                     The GNU C compiler
<tgardner> ii  gcc-4.4-arm-linux-gnueabi-base      4.4.4-14ubuntu4                     The GNU Compiler Collection (base package)
<tgardner> ii  gcc-4.5-arm-linux-gnueabi-base      4.5.1-7ubuntu1cross1.38             The GNU Compiler Collection (base package)
<tgardner> ii  gcc-arm-linux-gnueabi               4:4.4.4-9                           The GNU C compiler for armel architecture
<tgardner> ii  libgcc1-armel-cross                 1:4.5.1-7ubuntu2cross1.52           GCC support library
<apw> tgardner, note the version numbers, 4.5 is missing
<tgardner> ah
 * apw notes they have used 4 epochs on gcc-arm-linux-gnueabi !
<tgardner> apw, this looks like a meta package problem. lemme keep drilling.
<tgardner> apw, I've fixed both Maverick chroots by hand. 
<apw> tgardner, i suspect that is why ppisati wants to use natty chroots
<tgardner> apw, nah, I think he's just being lazy (like the rest of us)
 * smb reboots
<ppisati> tgardner: yes, i am :)
<ppisati> i never use chroot, it'
<ppisati> 's simpler
<tgardner> ppisati, 'echo "debuild -B -us -uc -aarmel"|schroot -c maverick-amd64
<tgardner> apw, the installation of the gcc-arm-linux-gnueabi meta package appears to have a generic problem. oneiric chrrots have the same version issues, only its 4.5 and 4.6 instead of 4.4 and 4.5
<apw> tgardner, interesting ... 
<sforshee> tgardner, do you continue to pull in compat-wireless updates for as long as a given release is supported?
<tgardner> sforshee, generally. I usually do all the updates when the next major release comes out. I started on 2.6.39 yesterday, but haven't finished it yet
<sforshee> tgardner, so do you think we should update the rt2800 firmware in maverick/lucid/hardy so that RT307x can be supported?
<tgardner> sforshee, as long as it doesn't create regressions for existing RT devices, though it would be hard to tell since they are all lousy.
<tgardner> sforshee, but yes, I think its worth doing.
<sforshee> tgardner, I have one tester who has tested existing RT devices in lucid at least and found that they work better with the newer firmware
<tgardner> sforshee, that seems like sufficient reson then
<tgardner> reason*
<sforshee> tgardner, ack
<sforshee> tgardner, how is wireless firmware handled in hardy? There doesn't seem to be any linux-firmware package.
<tgardner> sforshee, IIRC its in the LBM package
<tgardner> or the kernel.
<apw> tgardner, ogasawara, just looking at this upload, i am wondering what the documentation and source packages should be called previously we called them -2.6, by that rules they would be come -3 ... thoughts?
<apw> tgardner, or LUM?
<tgardner> apw, LUM might be it. sforshee ^^
<sforshee> tgardner, apw: thanks, I'll dig through those and see what I find
<ogasawara> apw: I was thinking about it a bit, and I think going with -3.x seems more appropriate to me
<tgardner> apw, I think thats another of those cases where the 2 v.s. 1 digit version is gonna give us problems.
<apw> ogasawara, the downside is that we may end up with multiple version numbers on the machine if we call it 3.0, before we had just -2.6 now we'd have 3.0 and 3.1
<tgardner> ogasawara, 3.x is lexicographically inferior
<apw> tgardner, well having 3 digits doesn't help here as we have the equivalent of the 6 in 2.6 changing
<apw> ogasawara, oh did you literally mean -3.x with a letter x ?
<ogasawara> apw: I didn't, but we could do that
<ogasawara> apw: I meant 3.0, 3.1, 3.2 ...
<apw> ogasawara, ok thats what i thought you meant first time
<tgardner> a literal '3.x' might work as well.
<ogasawara> apw: indeed that does mean you would get multiple packages on the machine though, how much space do those consume?
<apw> ogasawara, looking
<apw> ogasawara, tgardner ok they are 91MB however i see they have clever conflicts replaces in them
<apw> so that they replace each other
<ogasawara> apw: that's nice then, that was going to be my next question
<apw> and indeed they are actually called l-s-2.6.38 in full so we do not need to think about those
<tgardner> apw, as long as we're just replacing versions, right? the package name doesn't change with ABI does it?
<apw> there is a small bug in our changes which prevents the bump from
<apw> tgardner, no indeed, and actually it conflicts/replaces on a virtual name linux-source-2.6 which keeps us with just one
<apw> and rather madly i think those actually should remain as -2.6
<apw> so that we replace ourselves correctly, ie we should conflict/replace l-s-2.6 and l-s-3
<apw> which will then do the right thing going forward
<apw> tgardner, one other issue ...
<apw> if we chose 3.0 as the package we can widen the version later to 3.0.0 as 3.0 < 3.0.0 and all is well
<tgardner> apw, as you've mentioned...
<apw> however for the linux-meta 3.0.0.1 (3.0 + abi 0 + upload 0) it > 3.0.0.0.1 (3.0.0-0.1)
<apw> so either way we chose we are in for issues changing them later
<ogasawara> bah, I didn't think about meta borking like that
<apw> ogasawara, its a pain in the botty for sure
<apw> of course we can bodge the meta to widen its 3.0 -> 3.0.0 during package generation
<apw> but its something to consider
<apw> and visa-versa for that matter
<smb> bjf, For the new lucid-ec2 package I opened bug 794420 as new tracking bug. I removed the tracking bug for the main package from the rebase logs as that seemed giving wrong leads (hope that is correct). Remind me what I have to do with the previous tracking bug for lucid-ec2? Mark it a duplicate of the new one?
<ubot2> Launchpad bug 794420 in linux-ec2 "linux-ec2: 2.6.32-317.34 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/794420
<apw> so perhaps the logical thing to do is upload the kernel using 3.0, and meta using 3.0.0 but with a frig to drop the .0
<apw> and then when we decide for sure, we can get out of it
<apw> tgardner, ogasawara ^^
<ogasawara> apw: that sounds like a good idea
<brendand> bjf - are the going to be new -proposed kernels? are the current tracking bugs still valid?
<bjf> brendand, will be updating trackers soon
<sforshee> tgardner, afaict hardy doesn't currently have any rt28xx firmware files. LUM has a ubuntu-firmware/rt2x00 directory -- do I just drop the firmware files in there?
<tgardner> sforshee, is there a firmware directory in Hardy LBM?
<sforshee> tgardner, yes
<tgardner> sforshee, thats likely where it should go.
<apw> tgardner, isn't lbm elective?  arn't be aiming these new firmwares for all users ?
<tgardner> apw, not necessarily. doesn't the RT driver only come through compat-wireless  in Hardy ?
<apw> tgardner, fair point, if so then you are correct it should go with the driver
<tgardner> sforshee, see how iwlwifi firmware is treated. the munge file changes the name so there are no conflicts.
<sforshee> tgardner, thanks, I'll take a look at that
<tgardner> sforshee, hardy, as usual, is a bit of an abomination.
<jpiche> does anyone have documentation on compiling (or installing a pre-build) a vanilla 2.6.39 or 3.0-rc kernel in natty? I'm struggling with bug 775950 and want to test if it was already fixed upstream
<ubot2> Launchpad bug 775950 in linux "fixing recursive fault but reboot is needed! upon boot (always reproducible on battery only, but sometimes on AC too)" [Undecided,Confirmed] https://launchpad.net/bugs/775950
<brendand> bjf - thanks
<jburkholder> are you guys doing arm work on target or cross compiling packages for distribution?
<apw> jburkholder, our packages in the archive are native built
<jburkholder> what target hardware do you use?
<jburkholder> I mean host, as in what arm platform or board?
<apw> jburkholder, i guess when i say native, i mean on armel hardware, on a freescale board
<jburkholder> ah I see
<jburkholder> is beagleboard usable?
<apw> jburkholder, beagleboard is one of those that the arm people pay attnetion to, IIRC its not officially something we prioritise, but its still watched closly ... you should ask in #ubuntu-arm, the'd know better
<jburkholder> ok, thanks
<jburkholder> gotta move to a different computer and watch the kids
<hggdh> bjf, I do not have EC2 kernels to test for Hardy proposed
<hggdh> bjf, as such, I am marking the QA tests done
<smb> hggdh, For Hardy the -xen kernels would be the ones to use under ec2. But I am not sure how well that is integrated (server-team used to have some package in a ppa but the kernel config and level was the same as -xen)
<hggdh> smb, we need a specific image generated for the -proposed kernel; we cannot dist-upgrade
<hggdh> smb, Hardy does not support upgrading the kernel like the newer releases
<smb> hggdh, Well you can but the word is not spread that much
<hggdh> (for EC2)
<smb> hggdh, If you take current amis from http://uec-images.ubuntu.com/hardy/current/ and the pv-grub akis from
<smb> https://lists.ubuntu.com/archives/ubuntu-cloud/2010-December/000466.html
<BenC> Hey guys, what's the current state of powerpc in ubuntu? I notice there's a 10.10, but no 11.04
<BenC> (and even the 10.10 iso is too big to actually burn to a CD)
<BenC> And I'm speaking more from a server standpoint than desktop
<hggdh> smb, I understood Hardy did not have pv-grub support 
<smb> hggdh, Not officially. Its more thanks to lots of work by smoser 
<hggdh> smb, still confused... the link you provided shows AKIs for Lucid
<smoser> hggdh, right... there is a stub /boot/grub/menu.lst there really just as an unsupported mechanism to launch with pv-grub and get its beneifits.
<smb> hggdh, Yes, but basically those aki are not kernels but pv-grub loaders
<tgardner> BenC, AFAIK powerpc works in 11.04, though its mostly still community supported. Luke uses it on his old G4 I think.
<smoser> but i do not intend on backporting the rest of the stuff that manages that file
<smoser> basically the /boot/grub/menu.lst that is there just boots /vmlinuz and /initrd.img
<smoser> so whatever those links are is what you get
<BenC> tgardner: Ok, it looks like I'll be giving it a lot of love here soon
<BenC> definitely not in the Mac area, just generic powerpc work
<tgardner> 11.04 love?
<smoser> so the hardy dailies are good if you boot with the pv-grub loaders, but by default hey do not use them.
<hggdh> smoser, so I can dist-upgrade, as long as I use AKI, correct?
<smoser> you can, as log as you run-instances with the --kernel flag
<hggdh> yes. Doing it now
<BenC> tgardner: probably more for 11.10, but starting with 11.04 as a base
<apw> BenC, sounds intereiting
<BenC> Any if you guys happen to be going to the Freescale Technology Forum in two weeks?
<BenC> *of
<tgardner> BenC, nope, Dublin in a couple of weeks
<apw> BenC, where is it ? ... oh in that case likely we're not
<BenC> It's in San Antonio
 * amitk waves to BenC 
<BenC> Hey Amit
<amitk> tgardner: you guys get better beer than we do - we're going to cambridge in aug (skipping dublin) 
<bjf> ogasawara, apw, at a point where you want to mumble about bug scripts?
<tgardner> amitk, bummer dude :)
<ogasawara> bjf: sure
<amitk> bjf: do you know of any magic to mass-modify blueprints? (like your bug tool)
<amitk> (I already asked andy this morning)
<apw> bjf sure ... yank me
<bjf> amitk, i've not tried that before, so no, i'd think pitti might
<tgardner> bjf, I have an LBM for Natty ready with compat-wireless-2.6.39. Shall I just upload to the c-k-t PPA ? bug #794633
<ubot2> Launchpad bug 794633 in linux-backports-modules-2.6.38 "Add compat-wireless-2.6.39" [Undecided,In progress] https://launchpad.net/bugs/794633
<bjf> tgardner, yes, make it so
<tgardner> bjf, it appears someone (i.e., sconklin) neglected to push Natty LBM 2.6.38-10.4 to the repo
<bjf> hmmm
<tgardner> bjf, s'ok, I'll just skip to 10.5
<apw> presumably that was just an abi bumper
<apw> so you can put the missing changelog entry in
<tgardner> apw, yep, I noted it in the changelog
<ppisati> so, during a rebase, what's the procedure to get the changelog updated? fdr printchanges doesn't show anything
<ppisati> and the release looks correctly closed to me
<apw> ppisati, 
<apw> you first startnewrelease
<bjf> ppisati, how did you do your rebase? did you use the maint script?
<ppisati> manually
<ppisati> and i guess i have to use this script
<ppisati> ...
<apw> then commit use ubuntu-insert-changes previous-base new-base
<apw> then commit that as 'rebase to ...'
<ppisati> ah ok
<apw> hopefully thats roughtly what the script does :)
<bjf> ppetraki, you don't have to use the script, what apw said
<ppisati> so it's doable even manually
<ppisati> cool
<bjf> apw, yes, i believe so
<ppisati> and i've a couple pf patches too
<ppisati> shall i shove it together with the rebase?
<ogasawara> bjf: http://pastebin.ubuntu.com/621856/ so that's what I used to use to for my launchpadlib scripts to run as different users.  you'd only have to authenticate the first time, and subsequent runs would use the stored credentials file
<ppisati> ok
<ppisati> nevermind
<ppisati> i'll do a separate pull req
<ogasawara> bjf: I've not used that in a while though so no clue if it's still valid.  And I think you had actually moved a lot of that into a lp_login class
<bjf> ppisati, also, remember to add the tracking bug, look at https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePatchApplication steps 6 and 7
<ppisati> bjf: ok
<bjf> ogasawara, thanks, will look that over, think most is in the library now
<bjf> ppisati, also step #11
<bjf> ppisati, actually, everything after step #6
<ogasawara> bjf: I'll try to dig up the username and password for the kernel janitor we'd made up in case you want to use that for anything
<bjf> ogasawara, thanks
<apw> ogasawara, yeah i forgot to ask about her
<tgardner> apw, ogasawara: do you remember if there was a reason that the Natty meta package names were shortened from compat-wireless to cw ?
<tgardner> though they are not published yet
<ogasawara> tgardner: hrm, no idea here
<apw> tgardner, yes the CD filenames are too long and you have to use some
<apw> option which makes the CDs non-standard to make them
<tgardner> apw, ah, OK
<apw> i think it was 64 character overall for the .deb name
<ppisati> i get a stack trace using create-release-tracker --staging
<ppisati> lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized
<ppisati> but i authorized my box on the launchpad page that the script opens
<tgardner> bjf ^^
<bjf> ppisati, can you pastebin the stacktrace?
<ppisati> yep
<ppisati> http://pastebin.ubuntu.com/621874/
<bjf> looking
<bjf> ppisati, did it give you a url to the bug it created?
<ppisati> nope
<ppisati> it opened a web page
<ppisati> asked for permission to access my profile
<ppisati> gave it one hour permission
<ppisati> and then it hanged there
<broder> out of curiosity, does anybody know if the interface between module-init-tools and the kernel is arch-specific? i.e., could i use an arm insmod to load i386 modules into an i386 kernel (assuming i could get said insmod to run at all)?
<lifeless> broder: ---meeeeepppppp-----
<broder> i'm trying to figure out whether module-init-tools can be multi-arch: foreign or needs to be multi-arch: allowed :)
<lifeless> yeah
<lifeless> I can see that. Still made my brain implode as I imagined a dash implementation.
<apw> lifeless, erm, that would never make sense it hink
<lifeless> apw: thus the brain implosion
<apw> it seems utterly unreasonable to use a version of the tools which doesn't match the kernel
<broder> yeah, i can buy an unreasonableness argument
<apw> cirtainly you couldn't load a i386 kernel module into an amd64 kernel, whether an i386 modprobe could load it
<apw> is i guess the real question
<broder> looking at an strace of insmod, it seems like it *might* work
<apw> i suspect it mmaps the file and then passes the buffer to the kernel
<hggdh> bjf, smb hardy ec2 tests run, failure on QRT test-kernel-security. I have pinged kees on -hardened. I also cannot change the status on the tracking bug
<broder> apw: yeah, that appears to be correct
<apw> so in theory you could do it, but it seem utterly not something you'd ever want to do
<apw> broder, as i am playing with m-i-t at the moment is this something i should worry about?
<broder> multi-arch: allowed it is, then
<smb> hggdh, I am not utterly sure. Do we have a qrt test run without failure before and is the new one probably a newer test?
<broder> apw: probably not. i'm trying to figure out the concrete changes that would need to be done to allow installing an arch: amd64 kernel on an i386 userland using multiarch
<apw> broder, oh i see, that is a valid use case of multi-arch, there i think you would want the amd64 binaries really
<apw> though if the 32bit ones work that is easier
<hggdh> smb, not to my knowledge, no hardy xen ran before (I did run a m1.large on the current yesterday, but this seems to be i386 only)
<apw> actually given i know of people who slam on the 64bit kernel overriding the screaming alarms
<apw> and they boot ok, i assume the 32bit modprobe does work there
<broder> apw: right, so you'd set multi-arch: allowed in m-i-t, then in things like acpid and bluez that just depend on it for a modprobe binary, we'd change the dependency to m-i-t:any
<apw> broder, ^^
<hggdh> smb, http://reports.qa.ubuntu.com/reports/kernel-sru/home/ubuntu/sru-kernel-test/hardy-2.6.24-29.90/m1.small-i386/qrt-kernel-security.txt
<broder> yeah, i've seen 32-bit and 64-bit work. i'm wondering if that assumption breaks down when the skew between m-i-t and the kernel is more than just bittedness
<broder> but i think likely not
<apw> i t
<kees> hggdh: whoooa, yeah, no. CONFIG_COMPAT_VDSO _must_ stay disabled
<broder> apw: you know, even if such a modprobe could theoretically work, you probably have no hope of bootstrapping enough binfmt-misc-related stuff to get that modprobe to work
<kees> hggdh: if that's what /proc/version_signature shows, that's what you're running, afaik
<apw> broder, i suspect not
<apw> kees, yep /proc/version_signature is burnt into the binary
<apw> kees, you'll be glad to know: !exists CONFIG_COMPAT_VDSO | value CONFIG_COMPAT_VDSO n
<hggdh> kees, http://pastebin.ubuntu.com/621903/
<kees> apw: yeah, that's what I thought. I was pretty sure it was impossible to build a kernel with that disabled.
<apw> hggdh, but thats xen, arn't the domU kernels outside the domU ?
<kees> hggdh: I don't know what to tell you; you're not running the right kernel.
<apw> if memory serves you start a xen instance from a kernel file in the dom0 ?
<apw> smb, ^^ ?
<smb> apw, gah why all people start asking at the same time
<apw> smb, so ignore me for a bit :)
<smb> apw, the hardy kernel can be dom0 and domu
<smb> but for ec2 its domu
<apw> smb, but the image you boot you say like 'xen make instance using this kernel'
<apw> so the physical binary for the kernel is 'outside' the domU image space in the dom0 image
<smb> apw, No you can freely define what kernel you start inside domu
<smb> it can be but does not has to
<apw> ok thansk :)
<hggdh> in this case I ran the instances with the AKI pointed to by both smb and smoser
<smb> which looks inside the disk image and boots a kernel found there
<apw> smb, even on hardy ?
<apw> even on a hardy image ?
<hggdh> which puts us back to the beginning. There is no -generic installed
<apw> hggdh, anything lurking in /boot ?  seems unlikely
<smb> apw, It depends on the image
<smoser> hggdh, and there will not be *ever* on ec2.
<smoser> you want the -xen kernel on ec2.
<smb> but the ones from from current builds suport it
<smoser> for hardy
<apw> ubuntu@domU-12-31-39-16-A8-2A:~$ cat /proc/version_signature 
<apw> Ubuntu 2.6.24-4.6-generic
<hggdh> <sigh/>
<apw> and his domU whereever it is running is picking up an older kernel
<smb> I'd need to see menu.lst
<smb> on the domu
<smoser> are you talking about hardy image?
<smb> IT would not be generic though
<smb> but -xen
<smoser> hardy ami's have a very simple menu.lst
<apw> ii  linux-image-xen     2.6.24.29.31        Real time Linux kernel image
<apw> smb ^^ :) i think our meta package has problems
<smoser> see lines 250-259 at http://bazaar.launchpad.net/%7Eubuntu-on-ec2/vmbuilder/automated-ec2-builds/annotate/head%3A/vmbuilder-uec-ec2-fixes
<smoser> basically, it wil boot whatever is at /vmlinuz
<smb> apw, why exactly. bear with me not spotting what you mean
<apw> hggdh, and what does /vmlinuz look like/point at
<smoser> if you install a bad kernel, it will update the symlink, and when you reboot you'll be hosed.
<apw> smb, -xen -> -rt description
<smoser> it points to the last installed kernel
<smb> apw, Oh, probably noboday cared enough
<apw> smoser, thats what its supposed to point at, what does his actually point at
<smb> apw, That would we need from hggdh 
<smb> or acces to the domu
 * tgardner --> lunch
<hggdh> smb, I am starting a new m1.small instance
<apw> FINALLY 3.0-rc2 mainline kernels built right
<hggdh> smb, smoser, apw well, a hardy current m1.small reports itself as a -generic on /proc/version_signature
<apw> hggdh, runing on ec2? or running on uec
<hggdh> apw, AWS EC2
<smb> Hm, I have never looked close. I think I start one myself just for the fun of it
 * smoser is curious too
<smoser> it *can't* be right
<smb> I had been assuming something somewhere with xen in its name, either form the uec ppa or the custom-binary
<hggdh> http://pastebin.ubuntu.com/621917/
 * smb has some deja-vu
<smb> I think its the bodged version_signature of the xen kernel...
<smb> It tells you lies
<smb> hggdh, look in dmesg
<apw> smb, OH now that rings a bell
<apw> somethign like someone has committed a version into VERSION_SIGNTURE on the xen bits
<apw> didn't we fix that ever?
<hggdh> not really sure it will help :-)
<hggdh> [    0.000000] Linux version 2.6.24-29-xen (buildd@vernadsky) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Thu Apr 21 20:44:30 UTC 2011 (Ubuntu 2.6.24-4.6-generic)
<apw> if not that is lame of us
<smb> apw, Yeah, either that or not changing the right bits and ending up with the wrong one
<apw> debian/config/i386/config.generic:CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-4.6-generic"
<smb> apw, It is pretty lame. We should have changed it a while ago but without it hurting usually and that oteher piles... :(
<apw> yeah look its in the damn config, that is utterly broken
<apw> smb, but it correctly gets fixed for non-xen
<apw>         cat $^ | sed -e 's/.*CONFIG_VERSION_SIGNATURE.*/CONFIG_VERSION_SIGNATURE="Ubuntu $(release)-$(revision)-$*"/' > $(builddir)/build-$*/.config
<apw> so the other build thingy must miss that step
<smoser> ok...
<smoser> hggdh, which ami did you run?
<smoser> latest released version?
 * apw sees if he can FIX that
<smb> It was something only hitting that custom-binary-build
<smoser> wait, apw you dont have anything to fix
<apw> hggdh, that dmesg looks like a sane version
<smoser> hggdh ran latest released version of hardy ami.
<apw> smoser, yeah i do, the /proc/version_signature is _wrong_
<smoser> that runs a kernel from a ppa
<smoser> its crap
<smoser> the latest dailies use a kernel from the archive
<apw> the version in dmesg is right, but /proc/version_signature is not
<apw> and i think its still broken
<smoser> the reason hggdh is in this excercise of frustration is so that we can release an updated ami with an archive kernel
<smoser> which does not show the bug
<smb> smoser, actually the 2.6.24-29-xen looks like from the archive
<smoser> $ dpkg -S /boot/vmlinuz-2.6.24-29-xen 
<smoser> linux-image-2.6.24-29-xen: /boot/vmlinuz-2.6.24-29-xen
<smoser> $ uname -r
<smoser> 2.6.24-29-xen
<smb> I get the same running current daily with pv-grub
<apw> smb, do you have recent kernels in your xen setup could you see if its busted
<apw> hggdh, yeah can you get uname -r and cat /proc/version_signature at the same time
 * apw best v_s is crap
<smb> apw, It surely is still busted, cause I remember not to have fixed anything there
<hggdh> certainly
<smoser> ah.
<smoser> sorry.
<apw> smb, whars your version_sig look like
<apw> smoser, even
<smoser> yeah, version_signature is foobarred
<smoser> but uname -r is not
<smoser> sorry, missed that.
<hggdh> oh bloody hell, I stopped the instannce
<apw> ok ... i am sick of having this same error
 * hggdh starts Yet Another EC2 instance
<apw> i am going to damn well fix it
<smb> ubuntu@domU-12-31-39-0E-A4-E2:~$ uname -a
<smb> Linux domU-12-31-39-0E-A4-E2 2.6.24-29-xen #1 SMP Thu Apr 21 20:44:30 UTC 2011 i686 GNU/Linux
<smb> ubuntu@domU-12-31-39-0E-A4-E2:~$ cat /proc/version_signature 
<smb> Ubuntu 2.6.24-4.6-generic
<smoser> yeah
 * smoser has never looked at version_signature before
<smb> Well apw and me did at some point, shook heads, said this needs a fix and forgot
<hggdh> ubuntu@ip-10-36-7-174:~$ uname -a && cat /proc/version_signature 
<hggdh> Linux ip-10-36-7-174 2.6.24-29-xen #1 SMP Thu Apr 21 20:44:30 UTC 2011 i686 GNU/Linux
<hggdh> Ubuntu 2.6.24-4.6-generic
<apw> smb, no we wasted several hours before realising it was ver_sig which was ass
<apw> then we said we should fix it, and we nearly did it again
<apw> so i am going to fix it NOW
<apw> so i don't waste any more of my life
<smoser> another reason for us to get to an archive kernel for hardy amis
<smoser> apw, and i am willing to wait on that fix to re-release.
<smoser> since its been quite a while since the last anyway
<smoser> but i'd like to have hggdh work though and see if it generally otherwise smells good.
<hggdh> smoser, already did -- last two lines: https://wiki.ubuntu.com/QATeam/kernelSRU-hardy-2.6.24-29.90
<smb> smoser, hggdh So currently it would probably be abi and build time as a rough indicator one has the proposed kernel
<hggdh> smb, that and what linux-image\* you have installed
<smb> hggdh, right
<smoser> hggdh, so what does that say there ?
<smoser> FAILEd
<smoser> ?
<hggdh> well, yes
<hggdh> and the logs show it
<hggdh> but it seems it is an error on the test script, kees knows more
<kees> smoser: so is the hardy xen kernel built wrong for the VDSO_COMPAT?
 * smoser knows not of such a thing
<smoser> but, to re-iterate, all released Ubuntu hardy AMIs are from a ppa kernel build
<smoser> (yuck)
<kees> so what hggdh is testing isn't the real thing?
<apw> kees, from a -xen i just built from the tip: CONFIG_COMPAT_VDSO=y
<smoser> we are trying to get to the archive build of -xen kernel
<smoser> kees, i believe that hggdh is testing the -xen kernel from the archive... thats what we're trying to move to.
<kees> apw: I thought it was enforced to be unset?
<smoser> so, in regard to your question,i believe the answer is "yes, it is the real thing"
<apw> kees, in 'modern' versions yes
<smb> kees, I am currently running the tests again with current proposed -xen kernel
<apw> kees, i think lucid and above, the AAs refused the update to hardy to take the build checks
<apw> kees, but it seems that just the -xen flavour is out of kilter for this
<apw> debian/binary-custom.d/xen/config.i386:CONFIG_COMPAT_VDSO=y
<kees> so we can fix that for the future?
<apw> kees, unless its on for some reason for that flavour ?
<smb> kees, If we make sure we do not accidentally break our builders with that
<apw> smb, can you recall anything about hardy xen needing COMPAT_VDSO turned on
<smb> apw, Not specifically
<smb> apw, ubuntu@ip-10-2-19-128:~$ cat /proc/version_signature 
<smb> Ubuntu 2.6.24-29.90masternext201106081915-xen
<apw> smb, now that looks better doesn't it
<smb> much
<apw> smb, ok i'll get that out for review
<smb> apw, ack
 * jjohansen -> lunch
<apw> smb, smoser, patch to fix that stupid error is out for review
<smb> kees, So yes, there are these two failures on ec2 hardy. But then I have that feeling we never really cared much there and those have been present forever. IF we want to change we need at least make sure the builders still work (using that as dom0 kernel) as well as ec2 using it as domU
<ogasawara> bjf: looks like bug 789982 is fixed in 2.6.38.8.  Do you guys use a specific tag so you know what bug #'s to shove in the changelog?
<ubot2> Launchpad bug 789982 in linux "SRU: Fix kswapd 100% cpu usage in common scenerios" [Undecided,Confirmed] https://launchpad.net/bugs/789982
<ogasawara> bjf: or do you just dupe it to the stable update tracking bug?
<jburkholder42> I'm getting someone's weather
<bjf> ogasawara, i'd just mark if fix released probably
<apw> yeah i've tended to cut-n-paste the changelog in and fix release it myself
<ogasawara> bjf: we haven't pulled in the 2.6.38.8 update yet as far as I can tell
<apw> oh heh :)
<bjf> ogasawara, oh, sorry was thinking of our -8
<tgardner> ogasawara, I started on it but ran into the xhci issues
<bjf> ogasawara, yes, i guess just dupe it against the tracking bug
<ogasawara> tgardner: did you open a tracking bug yet?
<tgardner> yep
<ogasawara> cool, I'll just dupe it then
<tgardner> bug #793702
<ubot2> Launchpad bug 793702 in linux "Natty update to 2.6.38.8 stable release" [Undecided,In progress] https://launchpad.net/bugs/793702
<tgardner> ogasawara, ^^
<ogasawara> thanks
<hggdh> OK. kess, smb: do we consider the hardy kernel passed or not?
<apw> hggdh, i suspect its in flux still.  i think smb is going to test the VDSO change to see if we need t
<smb> hggdh, kees, apw yep, I try to see whether a dom0 is ok with it (and maybe ec2 as well). But in general I would only consider a failure a fail if it ever worked before
<hggdh> kees, smb: I am tagging it a failure then
<smb> hggdh, Which kernel version did pass that test with hardy on ec2?
<apw> hggdh, is this for the current proposed kernel testing ?
<apw> as i think this has been this way forever, so i'd not think it should hold up a -propsoed release
<apw> as the current one is just as bad, so they are no worse off with the update
<apw> smb, ^^
 * smb agrees
<bjf> apw, hggdh, that will make it perfect, regressions for every kernel in -proposed
<apw> bjf, wtf
<apw> more new regressions?
<hggdh> apw, yes, current hardy-proposed
<hggdh> smb, I have no record on a m1.small before
<kees> hggdh: if the prior hardy kernel didn't fail, it's a regression. I think it's always been this way, though for the hardy domU.
<hggdh> kees, I will launch a -89 test on m1.small then
<kees> smb: the two failures are the same thing. the compat vdso config results in an unrandomized vdso address
<apw> hggdh, although this is a test failure, i think you'll find if you test whats in -updates is the same we should count the -proposed as 'good' but get high bugs filed for the failures in the test suite
<smb> hggdh, Right, I am pretty sure those where this way all the way back
<apw> hggdh, if you can test -updates that would be excellent
<hggdh> apw, running it now. I will hold on, then on tagging the bug qa-testing-failed
<apw> yeah sounds good
<apw> but do file bugs against hardy listing hte failures so we don't forget to fix them
<hggdh> apw, bugs 794714 794715 reported
<ubot2> Launchpad bug 794714 in linux "Hardy Xen DomU: /proc/version_signature wrongly reports -generic kernel" [Undecided,New] https://launchpad.net/bugs/794714
<smb> hggdh, actually there is already bug 794698
<ubot2> Launchpad bug 794698 in linux "hardy custom binary kernels have incorrect version reported in /proc/version_signature" [High,Fix committed] https://launchpad.net/bugs/794698
<hggdh> smb, heh. I will dup mine, then
<tgardner> bjf, Ubuntu 2.6.32-33.66-generic 2.6.32.41+drm33.18
<bjf> tgardner, cool
<tgardner> bjf, had some grub 1 problems. guess I should reinstall this 'ol dev box
<apw> bjf, can you let kees know when lts-backport-natty finally gets into -proposed so he can add it to the cve tracker
<bjf> tgardner, was beginning to worry when you went away for so long
<bjf> apw, ack
 * tgardner is shifting locations
<kees> bjf: you sent mail about the workflow tool having issues at the moment. when it's back online, it'll update 788843 for promote-to-security, etc? I noticed it hadn't done that yet.
<bjf> kees, you can update that anytime, thanks
<kees> bjf: I didn't want to, since the workflow doc says the bot will do it.
<kees> (i.e. step 12)
<kees> afaict, 788843 is ready for an archive admin
<bjf> kees, heh, i'll look, can't remember how all this is supposed to work for each step
<bjf> kees, ok, looking into an issue with that bug
<kees> bjf: cool, let me know if I can help
<tgardner> ogasawara, received NICs via UPS today
<ogasawara> tgardner: cool
 * bjf goes to read the wiki page on how the new process is supposed to work
<apw> herton, i see you pulled in the mvl-dove update for lucid, are you also doing the roll forward to maverick for that one
<herton> apw: nope, just bjf asked be to take mvl-dove
<herton> *asked me
<bjf> apw, we are finishing up what ppisati started
<apw> herton, ok the mvl-dove lucid branch is replicated into maverick via a script
<bjf> apw, i expect him to do the maverick 
<apw> bjf, ok will talk to him tommorrow and get that done
<bjf> apw, thanks
<bjf> kees, bug 788843 is now ready (i think)
<ubot2> Launchpad bug 788843 in linux "linux: 2.6.24-29.90 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/788843
<sforshee> tgardner, could you accept the appropriate nominations on bug #762987 (tyring to nominate maverick/lucid for linux-firmware and hardy for lbm, but all nominations showed up for both packages, let me know if I should have done something differently)
<ubot2> Launchpad bug 762987 in linux-firmware "RT2870 WLAN Stick (D-Link DWA 140) not working. firmware does not support detected chipset" [Medium,Fix committed] https://launchpad.net/bugs/762987
<bjf> has everyone / anyone seen http://pad.lv ?
<hggdh> apw, smb: 2.6.24-29.89 EC2 m1.small fails the same with CONFIG_COMPAT_VDSO
<tgardner> sforshee, done
<sforshee> tgardner, thanks
<jwi> sforshee: since you're working on funky firmware issues right now - i think bug 597068 was merged into oneiric recently. not sure whether it really qualifies for any SRU though ...
<ubot2> Launchpad bug 597068 in linux-firmware "Missing Myricom 10GigE firmware" [Medium,In progress] https://launchpad.net/bugs/597068
<sforshee> jwi, I'll take a look at it
<sforshee> jwi, I see myri10ge firmware files in oneiric's linux-firmware package
<jwi> sforshee: right, afair they were merged into upstream linux-firmware just after natty had been freezed
<sforshee> jwi, sorry, I misread your message. I thought you were saying the bug was still present in oneiric.
<jwi> sforshee: ah, no. it's really just about maybe getting the commit into natty and maverick (since that's what the bug was filed against originally). not sure if it's worth the hassle (and whether there's any testers around) though
<kees> bjf: cool, thanks
#ubuntu-kernel 2011-06-09
 * apw grumbles about waking up too early
 * smb couldn't be bothered before
<eagles0513875> hey guys
<eagles0513875> morning apw
<apw> mornig
<eagles0513875> how goes it
<apw> busy as always
<smb> apw, So compat_vdso is only i386 and is said only to be needed with old (<2.3.3 glibc) which is ok in hardy (2.7.x). Normal boot in a vm looks ok and the testcases then pass. Just want to start up one instance to be even more convinced.
<apw> smb, sounds good, perhaps we can get one of the buildd peeps to test one
<apw> really when we push a hardy kernel into -proposed that should happen every time
<smb> apw, Questrion is whether they run anything i386
<apw> probabally not, but worth asking, if not then we really are off the worry pile
<smb> Right, seeing it depends on libc, the version being ok, being able to boot already got me off it quite a bit
<smb> Just for completeness I will do a domU and push that kernel to ec2. If that all works I just push out the change for review
<apw> smb, sounds good to me
<apw> cking, moin
<cking> apw, hiya
<eagles0513875> apw: has the 2.6.38-9 natty kernel been rolled out as an update yet
<Tommeh> eagles0513875: it's been superceded
<eagles0513875> on natty O_O by what though
<Tommeh> 2.6.38-10-generic
<eagles0513875> for natty or for the next release
<Tommeh> I'm still on Natty
<Tommeh> I might have proposed enabled...
<RAOF> I suspect eagles0513875 means 2.6.38.9, rather than 2.6.38-9?
<Tommeh> Ah, my mistake, if so
<eagles0513875> ya thats what i meant sry
<apw> eagles0513875, no -9 had regressions and was replaced with -10
<Tommeh> Though, 2.6.38.8 is the latest 'stable' as per lkml...
<Tommeh> And twitter.com/gregkh
<alex3f> hi, experiencing g #397096 in up-to-date natty, does anyone know something about it?
<Tommeh> "#Linux 2.6.38.8 kernel released. Last 2.6.38 kernel, it is now end-of-life, move to .39-stable."
<eagles0513875> apw: how come my netbook then in the ppa that had 9 in it is still on 9 and has not been upgraded
<apw> eagles0513875, which ppa are you using
<eagles0513875> apw: let me look it was the one you gave me when i was having atheros wifi issues
<eagles0513875> pre-proposed apw
<apw> eagles0513875, no idea why you haven't got an update unless you don't also have -proposed enabled
<apw> as the version in the pre-proposed ppa is
<apw> linux - 2.6.38-10.44pre201106070902
<eagles0513875> let me cfheck
<eagles0513875> apw: proposed would be pre-released-updates in software sources
<eagles0513875> now i got it apw :D 
<eagles0513875> apw: im upgrading my netbook to the ocelot lol
<apw> eagles0513875, good luck with that!
<eagles0513875> hows it looking so far
<apw> eagles0513875, not really running anything other than the kernel myself
<ogra_> shaky :)
<eagles0513875> great thank god i have nothing on this netbook lol
<eagles0513875> if a reinstall is in order so be it
<ogra_> not *that* shaky :)
 * ppisati -> out to get some stuff
<cking> apw, how long does it take to build a debug kernel package - it's taking forever in dpkg
<apw> 15mins or so
<apw> on tangerine
<cking> owchy ouch ouch ouch
<apw> unless you _need_ them you can turn them off
<cking> I _need_ it - otherwise I would not be needlessly burning CPU cycles :-(
<cking> why is it *so* slow?
<apw> then, forever yes, its .5GB and dpkg has to compress it
<cking> ah
<cking> parallelized compression is required
<ogra_> you complain about 15min for a ddeb build 
 * apw suspects about an hour on armel
<cking> at least 
 * ogra_ thiks we really need to force cking into a 6month arm team rotation to develop more patience :P
<cking> noooooooooooooooo
 * cking pretends to forget his ARM knowledge
<ogra_> heh
<cking> heh, takes less time to download than to create
<apw> herton, the mvl-dove rebase ... as it is you guys who put in the final tracking bug and actually close the release i suspect you are going to want to do that rebase... i've spent some time sorting out the rebase script so it works the same as the update-to-natty-master we use in the natty and maverick backports
 * ogra_ doesnt get why we still have to maintain that kernel ...
<herton> apw: hmm ok, isn't ppisati running the script and pushing that to us?
<apw> herton, well we can do that, but its one of those silly round trips currently
<apw> he makes the open branch, pushed it, you close it for lucid
<apw> then he has to pull it, move it into maverick and push it again, then you have to change the tracking bug and check it and push it
 * ogra_ shakes his head
<apw> as its a direct 100% copy of whats in lucid, it doesn't seem that sensible to ping-pong it like that ... to me anyhow
<herton> what you say makes sense. Is the script update-from-lucid-mvl-dove ?
<ppisati> herton: yes, it's that done
<ppisati> herton: i did the lucid->maverick once
<ppisati> herton: but it's not only about this script... ufff...
<ppisati> wait
<ogra_> we should really drop the maverick dove kernel ... it doesnt fulfill any purpose or has any users
<apw> ogra_, dunno mate, but when we talked before it had support for 18m and so we had to support it
<ogra_> apw, not for dove ... 
<apw> ppisati, i pushed an updated script to the branch which actually works ...
<ogra_> the maverick dove support we did was solely for oem to make sure userspace works on dove ... the kernel they use is totally uncompatible to ours
<apw> herton, yes thats the one
<apw> ogra_, but it seems to be marked as supported in the support matric
<ppisati> apw: ok
<apw> ppisati, i tried to use it this morning and it ate my tree, so i fixed it up 
<ogra_> apw, userspace ... i'll talk to david next week if we can drop the maverick dove kernel
<ogra_> lucid is still supported for 18 months though, there you are right
<ppisati> i remeber i had to do some git reset and then launching the script
<apw> ogra_, ok thanks, mostly its 100% the same as lucid, so 
<ppisati> but if it works out of the box now, is much better
<ogra_> but having to go on with dove once lucid on arm is EOL is just insane
<apw> ppisati, right should just work now, it was always meant to
<apw> ogra_, indeed a fair point
<apw> ppisati, i feel that if it works as well as the lts ones, and it should, then it might be most expediant for herton to run it just cause he closes the lucid one and verifies that
<ppisati> herton: btw, what was the problem yesterday with the lucid/mvl-dove kernel? i mean, the create-tracker script
<ppisati> apw: ack
<herton> ppisati: the kernel tools looks at the git branch, and looks for changelog at debian.<branch name>, well that was the problem I had
<herton> just renamed the branch to what it was expecting
<apw> herton, which tools do that, really they should look at debian/debian.env to find out the 'branch name'
<herton> apw: create-release-tracker, which uses ktl/debian.py
<apw> herton, i think that should be fixed to use debian/debian.env if it exists 
<apw> and actually now that karmic is gone if there isn't one then its debian
<herton> yep, or having a possible command line switch to override
<ppisati> regarding the buglink in the commit message of cve patches
<ppisati> some of them point to a real but ticket
<ppisati> e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601226
<ubot2> Ubuntu bug 601226 in linux-fsl-imx51 "Unable to handle kernel NULL pointer dereference in ppdev module" [Undecided,In progress]
<ppisati> others point to the tracker bug of the release that contained that fix
<ppisati> e.g.
<ppisati> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/731226
<ubot2> Ubuntu bug 731226 in linux "Lucid update to 2.6.32.32.14 stable release" [Undecided,Fix released]
<ppisati> but i guess we want just the first case, right?
<alex3f> hi: #397096 happens with 2.6.38-10, but with 2.6.38-9 does not, on my machine
<herton> ppisati: I think it should point to the cve tracking bug?
<tgardner> ppisati, CVE patches that we develop or integrate should have their own bug report, whereas stable updates are batched in one giant bug report. We often get CVE patches via stable updates, so we just need to mark the stable update tracking bug as having a CVE vulnerability.
<ppisati> tgardner: ok
<ppisati> tgardner: so the one pointing to a tracker bug, means we got them via stable update
<tgardner> ppisati, when you notice that a stable update solves a CVE, you should also note it in the changelog.
<tgardner> ppisati, yes
<tgardner> ppisati, apw has developed a script that pairs stable updates and CVE commits from mitre.org and has cleared out some of our backlog of CVE notices.
<ppisati> tgardner: ok, but then that particular patch that i cherry pick won't poing to "real" launchpad bug page, and thus i cannot add any $release/$branch to it
<ppisati> s/poing/point/
<ppisati> tgardner: i mean, you told me that every CVE entry that i pushed should have the correspective $release/$branch in the launchpad bug page
<apw> tgardner, ok the 'final' 3.0 / 3.0.0.0.0 kernel / meta are built in my red ppa: https://edge.launchpad.net/~apw/+archive/red/+packages (as ~pre2) as its irrevocable if i get it wrong i wonder if you might review the packages produced for numbering etc
<ppisati> tgardner: but what if they point to a cve tracker?
<apw> ogra_, ^^
<tgardner> ppisati, if you're doing a wholesale rebase against master then you can likely just add a package task (linux-fsl_imx51) to the original stable update tracker bug. Otherwise you should create a new stable update tracker bug.
<ppisati> sorry, tracker bug
<ppisati> tgardner: ok
<tgardner> apw, looking...
 * tgardner wonders if pgraner is in a noisy air-conditioned space
<apw> meant to be around now i think
<ppisati> tgardner: and for every bug that get a new launchpad bug, i should push again to update the buglink, right?
<tgardner> apw, the east coast is having a heat wave, so it might be  good place to be.
<tgardner> ppisati, yeah. you can just edit the commit logs and I can reset to your HEAD
<apw> tgardner, a heads up ... i've respun all the update-to-foo scripts in the lts-backports and in the maverick/mvl-dove branch to basically be the same script and fixed up a bunch of issues
<apw> tgardner, and i have been wondering if we should rename the files to debian/scripts/misc/update-to-my-upstream
<tgardner> apw, do they now all have a common ancestor in the debian repo ?
<apw> in all of them, so that there is a trivial way to tell if the branch has scripted updates and you know already what it is called
<tgardner> apw, never mind. ack to your last comment.
<apw> tgardner, good point, will do that now
<apw> i'll start a thread on u-k-t for that, so that stable is aware ...
<apw> tgardner, can we turn the emerald raid into jbos and try raiding it higher ... wonder if that might help
<tgardner> apw, I tried that on my emerald. didn't seem to make a difference
<apw> so its just a crap controller, thats poor
<tgardner> i.e., I exposed both drives as used LVM
<tgardner> s/as/and/
<apw> poor indeed, hrmph
<tgardner> apw, push your packaging changes to oneiric master-next so I don't have to download the whole source package from your PPA.
<apw> tgardner, got any other solid use cases for overlayfs other than livecd ?
<apw> tgardner, trying to help shore up the request to merge
<tgardner> apw, hmm, its not really my domain of expertise :)
<ppisati> uhm
<apw> tgardner, other than the closing commit the master-next branch is up to date on linux
<apw> tgardner, and linux-meta master-next has the latest bits 
<ppisati> apw: i can't switch to master to find the sha since i'm in a rebase in fsl-imx51 but
<ppisati> apw: http://markmail.org/message/dy5bldezg6e55tl7#query:+page:1+mid:4oi2w3bs76nwuxxw+state:results
<ppisati> apw: the buglink points to CVE 3875 and not 3876
<ppisati> apw: but in any case, both of them are not that commit
<ppisati> wait
<ppisati> apw: 3876 is the correct one, nevermind
<apw> ppisati, ok
<ogra_> apw, what exactly did you want me to see when you pointed upwards ?
<apw> some patches fix more than one but get applied for hte first
<apw> ogra_, i suspect i wanted ogasawara to see something
<ogra_> heh
<ogra_> k
<ppisati> apw: yeah, i was fooled by the but description, thought it was the commit msg
<ppisati> s/but/bug/
 * ogasawara scrolls back
<apw> ogasawara, ok the 'final' 3.0 / 3.0.0.0.0 kernel / meta are built in my red ppa: https://edge.launchpad.net/~apw/+archive/red/+packages (as ~pre2) as its irrevocable if i get it wrong i wonder if you might review the packages produced for numbering etc
<ogasawara> apw: yep, will look right now
<apw> tgardner, ok i've pushed the close out as well for master-next on ubuntu-oneiric for completeness
<apw> once you two are happy i'll hit the upload buttons
<smb> O_o how many zeros?
<apw> smb, 5
<apw> smb, 5 digits on meta, as 3.0.0.1.5 < 3.0.1.5 ... so for meta we need to use 3 digits till we decide and for the kernel we need to use 2, in order to keep our options open
<tgardner> apw, update Vcs-Git to point to the correct repo
<apw> ahh right will do
<amitk> 5 digits!
<tgardner> apw, well, it looks right as far as I can tell.
<amitk> I though Linus wanted to reduce one digit
<tgardner> apw, the meta package bodge should work
<tgardner> amitk, 5 digits is just for meta package versioning
<smb> Seems in order to reduce we need to increase before being done
<apw> amitk, the meta package has alays had 5, it may reduce to 4 if we stick with the 2 digit kernel numbering
<apw> amitk, a number of tools are just not expecting the version number to stop being 3 digits, like ps, top, depmod
<apw> and till those are fixed we are in a difficult plac
<amitk> x.y.z-abi.upload
<apw> thats the kernel numbering
<apw> which is x.y-abi.upload in the current package
<smb> apw, Oh right, meta was always strange. It just was not that obvious without that many zeros
<apw> we are hedging out bets
<amitk> I small step for Linus, I giant step.....
<amitk> :)
<ogasawara> apw: looks good here
<amitk> s/I/One
<apw> our bets, by taking the side which allows us to upgrade to the other, for the kernel 3.0 -> 3.,0.0 just fine and not the other way, for meta 3.0.0.1.5 -> 3.0.1.5 but not the other, so we are splitting our selves for now
<smb> FYI: It seems all recent proposed uploads of the kernel images strangely ended up in the universe of proposed...
<apw> as in not in main ?
<smb> linux-image-2.6.35-30-server | 2.6.35-30.53 | maverick-proposed/universe | amd64
<smb> piti is trying to fix
<apw> nothing is going right is it
<ogasawara> weird, how did that happen
<smb> maybe another we fix lp issue...
<smb> But that was the thing I noticed yesterday about uninstallable kernels
<smb> Just thought that to be delay on my side
<apw> ogasawara, fyi, if you have broken history and printchanges doesn't work (like it doesn't as we switch 2.x -> 3.0) you can now do fdr prev_release=2.6.39-3.10 insertchanges to override the search
<apw> (on the oneiric tree)
<ogasawara> Oooo nice
 * apw got sick of doing it by hand
<apw> tgardner, was that the only issure or are you still poking
<tgardner> apw, nah, I'm on to a support escalation bug.
<tgardner> so, I guess I'm done
<apw> tgardner, fun
<smb> hopefully not _that_ bug again...
<tgardner> smb, nope, its one of your DRM stable updates methinks. time will tell.
<smb> yiek
<bjf> tgardner, which kernel is that escalation bug against?
<tgardner> bjf, lucid
<apw> bjf, sconklin, quick heads up, i've updated the update-from* scripts in the lts backport branches ... makes them quicker and easier on your repositories
<cking> just like to say that systemtap rocks
<apw> bjf, sconklin, i have also fixed up the one on the maverick mvl-dove so that it actually just works like the ones on the lts branches
<bjf> apw, thanks
<smb> sforshee, bjf With that escalation bug. Be extra careful about versions. At least for the last few proposed uploads things seemed to have gone into proposed/universe instead of proposed/main
 * ogasawara back in 20
<brendand> sconklin - i'm wondering why the tracking bugs for Maverick and Natty SRU's haven't been invalidated yet - aren't they being respun?
<bjf> brendand, working on it
<bjf> brendand, at this very moment as a matter of fact
<brendand> bjf - correct me if wrong, but can't they be invalidated as soon as it's known there will be a replacement?
<bjf> brendand, yes
<apw> git show Ubuntu-lts-2.6.38-10.44
<apw> tag Ubuntu-lts-2.6.38-10.44
<apw>     UBUNTU: Ubuntu-2.6.38-10.44
<CarlFK> what is this?  [    1.356136] acpi device:4e: hash matches
<CarlFK> I have 2 HP EliteBook 8530w laptops.  3 firewire EC cards work on one but not the other.  I am trying to look for differences.  I booted both, dmesg>d.txt, diff, that line is in one but not the other.
<apw> CarlFK, that is a piece of debugging which only has meaning if you had suspend debugging turned on, suspended and then hard booted out of suspend.
<apw> CarlFK, any other time it appears it is just random fluke... litereally some part of your clock matched something in the kernel and triggered that message
<BenC> CarlFK: sounds more like the other fw card is just broken...does it even show in lspci and does the driver detect it?
<CarlFK> it suspend debugging turned on in oneiric ?  
<BenC> CarlFK: and does the card work in another system?
<CarlFK> BenC: 3 cards, they all work in one but not the other 
<CarlFK> and actually 3 cards work in 1, not work in 3 other boxes. 
<BenC> CarlFK: I'm a little ambiguous on what you mean...
<CarlFK> 3 cards are all same make/model.
<BenC> And they all work on one computer, but not another computer?
<CarlFK> BenC: you should be becuase it doesn't make sense :)
<CarlFK> yep.
<CarlFK> thus my quest for what makes the one box special 
<BenC> CarlFK: and the other computer has the same kernel, same mobo, same cpu, etc?
<CarlFK> yep
<BenC> Then sounds like the other computer is broken :)
<abogani> same BIOS version?
<BenC> maybe reset the BIOS
<CarlFK> I don't want to mess with the box where they work.  else I may never get it back to that state, which would make me sad :)
<BenC> But if you're not seeing any difference in dmesg other than that one line, it sounds like the BIOS is POSTing the same, else you'd see difference values for the PCI detection
<BenC> CarlFK: reset the BIOS in the box that doesn't work
<BenC> Or at least check the BIOS versions to see if they match
<CarlFK> BenC: not a bad idea
<CarlFK> biosdecode is the same on both, but it doesn't print much - not sure what that proves.
<CarlFK> bios reset, fw (firewire) still broken.
<apw> CarlFK, not by default you have to ask for it on the kernel command line
<tgardner> apw, When installing a 3.0 kernel on Natty I get this message (as expected): 'dpkg: dependency problems prevent configuration of linux-image-3.0-0-generic:
<tgardner>  linux-image-3.0-0-generic depends on module-init-tools (>= 3.13-1ubuntu1)'
<tgardner> this is gonna cause a huge pain in the ass for LTS backports.
<tgardner> unless we update m-i-t in Lucid
<apw> tgardner, yes either we'll have to use 3.0.0 there (as has been suggested) or we have to fix m-i-t in lucid
<apw> probabally the same patch could be applied, ie not update it much
<apw> and then have the right dependancy on the backoprt
<tgardner> apw, right, just something to keep in mind when you make the final version decision
<apw> tgardner, and the kernel won't boot if you install it without the right tools
<apw> yep i have a lits of known problem packages..
<apw> tgardner, do we have cross compilers for oneiric yet? 
<apw> (for tangerine chroots)
<tgardner> apw, should be.
<apw> make[4]: arm-linux-gnueabi-gcc: Command not found
<tgardner> lemme check, I'm sure I saw that upload go by
<apw> i386 seems to have half of it, no gcc frontends
<tgardner> apw, still seems borked: The following packages have unmet dependencies:
<tgardner>  gcc-arm-linux-gnueabi : Depends: gcc-4.6-arm-linux-gnueabi (>= 4.6.0-8) but it is not going to be installed
<apw> bah, ok thanks
<bjf> kees, smb, can you each add a comment to bug 788843 giving your input on there being a regression or not
<ubot2> Launchpad bug 788843 in linux "linux: 2.6.24-29.90 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/788843
<smb> bjf, done
<tgardner> apw, try again. I updated and the package problems magically disappeared.
<smb> seems apw also disappeared magically. :-P
<apw> tgardner, looks better thanks
<apw> tgardner, did you do amd64 as well?
<tgardner> apw, both
<apw> tgardner, excellent
<smb> Grrr... so have all my window decorations after unity-window segfaulted...
<apw> smb, run unity again on VT1
<smb> apw, That helped. Ta
<tgardner> wtf is up with launchpad today? it times out on everything
<smb> tgardner, They updated it
<tgardner> smb, well, its freaking unuseable
<bjf> tgardner, the topic in #launchpad seems to indicate they are aware of an issue and are working it
<smb> Hrmpf, as useful as unity shitting its pants just because I try to use a java-ikvm
<apw> tgardner, its been broke for most of the last 20 hours, no idea why the don't roll it back
<tgardner> apw, whoo hah! [ubuntu/oneiric] linux 3.0-0.1 (Accepted)
<tgardner> let the carnage begin.
<apw>  /me waits for all the fallout
<apw> :)
<apw> yeah
<apw> right that'll take some hours so i am going to go drink some bubbles :)
<tgardner> apw, cheers. see you in a week
<apw> tgardner, have fun!
<herton> apw, ppisati: I run the updated script to update maverick mvl-dove, worked fine. I'm preparing it for pushing to the repo/create packages.
<CarlFK> why are these different?  < yenta_cardbus 0000:86:09.4: ISA IRQ mask 0x0cb8, PCI irq 22 > yenta_cardbus 0000:86:09.4: ISA IRQ mask 0x0c98, PCI irq 22
<kees> bjf: done
<bjf> kees, thanks
<kees> np :)
<smb> tgardner, will I run into you when I try to apply my cve patch to hardy?
<tgardner> smb, figuratively speaking ?
<smb> tgardner, or virtually. I was about to commit it but I saw some activity there.
<tgardner> smb, I've pushed apw's CVE patch, so you should be OK
<smb> tgardner, Ok cool. Just wanted to avoid both of us trying to push at the same time. :)
<kees> apw: fwiw, I've added linux-lts-backport-natty to uct.
<bjf> tgardner, apw, the carnage has began, i have script failure due to version regex
 * tgardner --> lunch
 * tgardner --> server room
 * jjohansen reboots :\
 * jjohansen -> lunch
<tgardner> bjf, is this indicative of an LP timeout ? 
<tgardner> rtg@lochsa:~/ubuntu/ubuntu-lucid$ ~/kteam-tools/stable/create-release-tracker
<tgardner> https://bugs.launchpad.net/bugs/795219
<tgardner> Traceback (most recent call last):
<tgardner>   File "/home/rtg/kteam-tools/stable/create-release-tracker", line 281, in <module>
<tgardner>     app.main()
<tgardner>   File "/home/rtg/kteam-tools/stable/create-release-tracker", line 237, in main
<ubot2> Ubuntu bug 795219 in linux-fsl-imx51 "linux-fsl-imx51: 2.6.31-609.26 -proposed tracker" [Medium,In progress]
<tgardner>     t.assignee = self.lp.launchpad.people[taskAssignments[task]]
<tgardner> AttributeError: can't set attribute
<bjf> tgardner, no, that can be an indication that you need to update your lpltk
<tgardner> bjf, how do I do that ?
<tgardner> bjf, it wasn't in a package, was it ?
<bjf> no
<bjf> you have to get the bzr repo and then run the setup.py script as root
<bjf> i have a package in my ppa if you want to try it
<bjf> tgardner, ^
<bjf> https://launchpad.net/~brad-figg/+archive/kteam
<bjf> tgardner, ^
 * ogasawara lunch
<sconklin> tgardner: what are you doing with the fsl-imx tracking bug? Almost all status changes are automated and should be made by the bot, and if anything, you should be changing prepare-package after it's built in a PPA? I'm confused
<tgardner> sconklin, I didn't do anything but create it. LP is so freaking slow today that I haven't been able to make _any_ state changes.
<sconklin> tgardner: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/795219 perhaps it's issues with timeouts and LP UI that caused the status changes while you were trying to poke at it, sorry for griping, but that's the way it looked
<ubot2> Ubuntu bug 795219 in linux-fsl-imx51 "linux-fsl-imx51: 2.6.31-609.26 -proposed tracker" [Undecided,In progress]
<bjf> tgardner, did the script complete? non of the assignements got done so i'm thinging it blew up
<tgardner> bjf, sconklin: no, the script didn't complete, not did the package install correctly.
<tgardner> nor*
<tgardner> then I got distracted chatting w/Pete
<bjf> sconklin, i think that one is going to need some human love
<sconklin> tgardner: oh, yeah I hate when that happens. I usually just invalidate everything in the bug nd keep rerunning the script until it all completes. It's too easy to screw it up when you do stuff manually.
<sconklin> I'll fix it up.
<tgardner> sconklin, cool. I'm outta here. see you next week.
<sconklin> and eventually I'll write a "validate and fox" script
<sconklin> later!
<lifeless> tgardner: sorry!
<lifeless> (it is, quite literally, all my fault)
 * tgardner thinks lifeless is buying beers next time :)
<lifeless> well, other folk have done a heap on the things we've improved - I am not taking their credit :) - but I will wear all the blame
<tgardner> its been working well until this morning (for me at least)
<lifeless> tgardner: so we add.d...
<jcastro> jjohansen: any luck with the wireless on the 3.0 kernel?
<jjohansen> jcastro: haven't tried yet.  I was going to try to give it a run tonight
<jcastro> jjohansen: either way I'm going to snag a dongle before ireland, and possibly bring a backup laptop on top of that.
<jjohansen> jcastro: yeah, definitely
<bjf> jcastro, one laptop, 2 partitions: part 1: natty; part 2: oneiric
<jcastro> bjf: the driver causes hard lockups in both.
<bjf> ouch
<jcastro> jjohansen: don't bother putting an intel card in the minipci-e slot, I already tried that, heh.
<jjohansen> jcastro: :(  For dublin I was actually considering just getting a new battery and bringing my x61t
<jjohansen> its a better machine to work from anyways
<jcastro> jjohansen: our bug got duped to this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/749871
<ubot2> Ubuntu bug 749871 in linux "Attempt to Use Realtek RTL8192CE Wireless Causes Computer to Freeze" [Undecided,Confirmed]
<jcastro> but I have an RTL8188CE, should that matter?
<jjohansen> jcastro: it might I am not sure, but it might. I need to dig more into the rtl drivers, and what the diff versions are
<Sarvatt> they have a newer driver for RTL8188CE than RTL8192CE on their website, might be worth a try - http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true
<jjohansen> Sarvatt: indeed, thats one of the reasons I need to dig more into what drivers to what chipset etc
<Sarvatt> err guess i was looking at RTL8188CE-VAU
<jcastro> Sarvatt: I couldn't get the linux one building in oneiric.
<jjohansen> Sarvatt: the point being they do have newer stuff, and I need to dig into the whole mess
<sconklin> apw: still not drinking beer?
#ubuntu-kernel 2011-06-10
<ohsix> was 2.6.38.10.24 -> 2.6.38.10.25 a no change rebuild?
 * apw yawns
<jk-> hey apw
<apw> jk-, yo ... 
 * smb grumbles at udev net rules...
<apw> smb, heh what did they do to you today
<apw> (and moin)
<jk-> do you have an eth4511 device?
<jk-> eth5*10^2
<smb> apw, moin :) Well leaving one of my nics named eth0-eth1 which does not help if your interfaces setup wants eth1 or eth0
 * smb is sadistic and uses bonding
<smb> probably more masochistic
<apw> smb, you are mad
<smb> apw, It is that dogfood kind of madness
<smb> jk-, So not that bad, but still. How do you get that mad numbers?
<apw> yay lts backports natty hit -proposed
<smb> apw, and real proposed this time?
<smb> (as in main)
<jk-> smb: keep changing the MAC, I guess :) 50-persistent-net should take care of the rest
 * jk- wonders how 'random MAC address' ethernet devices are handled by udev
<smb> In theory everyone will get a new name right....
<apw> ohsix, i am supprised to see a bump like that in what i assume is the linux-meta package
<ohsix> apw: apparently it was to include something in the backports, the changelog showed up a few hours later
<smb> Though that seems to be the purpose as the mac is not really supposed to be different that often
<apw> ohsix, actually no its not, its a backport ...
<apw>   * Added compat-wireless packages to Natty LBM
<apw> ohsix, ahh you found it
<smb> \o/ I was able to change a lp status
<apw> smb, i wonder if that is cause it still got a high timeout or if they fixed it
<smb> apw, Sadly it could be either (everybody else not trying to atm or it being fixed)
<jk-> smb: yeah; but some devices don't have an EEPROM for the MAC, so the driver generates one at probe time
<smb> jk-, though probably that one should be in the privately usable range, which is ignored for the persistent rules
<jk-> ahh
<jk-> thinking++
<smb> Just saw some skips in there for xen and kvm/quemu driver ids as well
 * jk- should read the code rather than making assumptions about it
<smb> :) As long as it is findable. I seem to fail finding the piece that would actually trigger the renaming...
<jk-> smb: /etc/udev/rules.d/70-persistent-net.rules
<jk-> sets NAME=
<smb> jk-, Well yes, as well as /lib/udev/rules.d/75-persistent-net-generator.rules would set it
<jk-> but that might not be the issue in your case
<jk-> yah
<jk-> smb: it's not something in /etc/network/ ?
<smb> But that is setting a shell var. The driver will remain unimpressed unless something tells it a new name...
<jk-> smb: I thought udev would see that as a new device name, and do the rename?
<jk-> again, making assumptions here...
<smb> jk-, Would make the same assumptions that something, somewhere will detect that the name set and the name used are not the same and start the rename
<smb> The big question is "where is that hidden"
<smb> At least the names of scripts in /etc/network and /lib/udev are not obviously sticking out...
<apw> # rename interface if needed
<apw> ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"
<apw> smb, ^^ i think those two lines cause the rename, and i suspect the actual change may occur in the udev binary
<smb> apw, Yeah, that sounds like the only possible explanation, cause I could not find anything that remotely looks like doing the job externally.
<smb> Which would hint a breakage there when I am left with a ethx-ethy device while the persistent rule section only has either. Sounds like it is forgetting to make a final move
<apw> smb thats a bugger and no mistake
<lucazade> Hi!  I'd like to know if in kernel 3.0 for OO it is included/enabled the support for Gma500 framebuffer
<apw> lucazade, erm no idea off the top of my head
<lucazade> apw, thanks.. I'll give a look :)
<ppisati> apw: about our CVE tracker
<ppisati> apw: one of the patch i applied in maverick/ti-omap4 had no buglink
<ppisati> apw: and i opened one
<ppisati> apw: but i don't understand why the CVE page says it affects only the omap4 branch
<ppisati> apw: anyway, CVE-2010-3296
<ubot2> ppisati: The cxgb_extension_ioctl function in drivers/net/cxgb3/cxgb3_main.c in the Linux kernel before 2.6.36-rc5 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a CHELSIO_GET_QSET_NUM ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3296)
<ppisati> apw: and here is the LP bug i create: 795436
<ppisati> apw: and, while there, can you accpet the maverick nomination? thanks :)
<apw> bug #795436
<ubot2> Launchpad bug 795436 in linux-ti-omap4 "CVE 2010-3296" [Undecided,New] https://launchpad.net/bugs/795436
<apw> ppisati, approved
<apw> ppisati, do you mean on the ALL-linux.html page ?
<ppisati> yep
<ppisati> the cve says "linux before 2.6.36"
<apw> ppisati, if the page is _white_ in that area it means that there is no information to collect, normally that means that the
<apw> CVE doesn't affect _or_ is already released for that cve on the other branches
<apw> its a limitation on how that page is generated, and on my list to fix 
<ppisati> ok
<apw> maverick_linux: released (2.6.35-23.36)
<apw> yeah in the tracker its all 'released' across the board ... so it is missing in the page i scrape to make that combiined one
<apw> i have a different way to make the page planned, but its not written yet
<ppisati> ok, no prob
<apw> take white to mean "very likely can be ignored" for nwo
<apw> ppisati, ti-omap4 is manually maintained right?
<apw> (for cves_
<tkamppeter> I have a problem with USB, seems that my Lenovo laptop is not compatible with the Oneiric kernel. Even directly after reboot "sudo lsusb -vvv" hangs and on the system console I get several message "usb 7-1: device descriptor read/64, error -110" and after some minutes I get "hup 7-0:1.0: unable to enumerate USB device on port 1". Anyone has an idea what happens?
<apw> tkamppeter, that is possible with the .39 kernel there are a lot of very bad USB fookages about at the moemnt, a lot of them being introduced and fixed by stable updates on all releases
<apw> tkamppeter, i think they are gone in the 3.0 kernels, but they have install problems cause of the stupid version number so i'd hold off on those as well
<tkamppeter> apw, I need a working USB quickly to do testing for CUPS development, what should I do?
<apw> well you can instlal the just built 3.0 kernel and see if it helps but you may find other problems like ps not being happy when you do
<apw> i've just had a libc6 upgrade issue due to the version number ... and i have no idea if that machine can even reboot
<apw> cirtainly reboot into a .39 kernel to do updates
<apw> tkamppeter, those kernels are in the NEW queue, see the version page for links
<tkamppeter> apw, perhaps I better boot into .38 first before installing a 3.0.x kernel. But thanks anyway.
<Kano> hi, is the daily cronjob disabled?
<tkamppeter> apw, now I have booted into 2.6.38-9 and I have still the same USB problem. Do I have to return to a from-scratch install of Natty to get a dev platform for the printing stack?
<apw> tkamppeter, i have no idea what the issue if is you have reverted your kernel and its not working.  maybe udev is borked
<apw> wow Kano is persistant, 40s to get an answer in
<tkamppeter> apw, is "lsusb" using UDEV?
<apw> tkamppeter, nope, hmm, oh lsusb is hanging, ... do you have th 38-8 kernle on there ?
<apw> -9 might have had the stable update which caused all our grief with usb
<tkamppeter> apw, yes, so will go to that.
<tkamppeter> apw, booted 2.6.38-8-generic #42-Ubuntu and still the same problem.
<apw> hrm
<apw> tkamppeter, when did this last work for you
<smb> apw, tkamppeter If that helps I am at 2.6.38-10.44 from proposed and lsusb does work. But maybe it could also be of help to try completly power off the machine in question before booting anything...
<apw> smb, oh not one of those EC issues ... GAH
<smb> Hm, and this is Natty user-space...
<smb> probably not that helpful then
<apw> i guess lsusb might be foobar
<apw> nope works here on a half installed OO bog
<apw> box
<tkamppeter> laptop is Oneiric, the kernel which I am now running must be of Natty times.
<tkamppeter> What are "EC" issues?
<smb> embedded controller. some piece of hardware controlling/driving a lot of internal things (through acpi)
<tkamppeter> The laptop is a Lenovo Thinkpad T400.
<smb> So lsusb also seems to work on my server box...
<tkamppeter> The USB problem I observed only today.
<apw> tkamppeter, the embedded controller on some machines have crashed and mad things occur.  the 'fix' has been power off remove battery wait 20 mins and put it back together ... i was scepticle but it worked for me
<smb> (which is oneiric kernel and user-space)
<tkamppeter> apw, so I will try. I will restart xchat from another box now.
<tkamppeter> So this controller has some memory constantly supplied with power from the battery and also having large backup capacitors to hold data during system reset and battery change?
<tkamppeter> apw, I am still here, the laptop is running an eternal process.
<apw> tkamppeter, cirtainly it draws so little that the capacitors in the mchine are enough to keep it alive for some minutes it seems, cking is the expert
<tkamppeter> apw, smb, I tired the shutdown of my notebook and leaving it without battery for more than 30 minutes, but to no avail, the USB is still broken.
<tkamppeter> apw, smb, I got a fast "sudo lsusb -vvv" once, then I connected the USB hubs with 10 printers again and it broke again. Seems that connecting many devices is messing up this mysterious memory, but it was never that way before. I am still on kernel 38-8.
<tkamppeter> apw, smb, I hope I do not need a new laptop.
<smb> tkamppeter, So does anything change when you connect the hub but for test remove some of the printers?
<tkamppeter> smb, only first hub, no printers, same problem.
<smb> Hm, so without the hub it works but with it, it does not?
<smb> like a single printer directly to the usb port works or not?
<tkamppeter> also the hub removed, same problem.
<smb> Though you said it was working once without?
<cking> best to boot back to a known working kernel, and try with one device plugged in to sanity check it
<smb> cking, Right, though he says that 2.6.38-8 used to work and does not seem to anymore
<cking> so sounds like a H/W issue to me
<tkamppeter> Yes, before connecting the hub OK, hub+printers broken, hub broken, hub removed, broken.
<smb> tkamppeter, I would try then rebooting and trying no hub, but one printer
<smb> Would you have a different usb hub to try?
<cking> and if you have another machine sanity check the printer, then the hub with it.
<smb> Also, depending on whether the hub is active can sometimes help to disconnect that from everything
<cking> good point
<apw> ogasawara, i am holding off on uploading linux-meta becuase my machine here is having trouble installing libc with the 2 digit kernel installed
<ogasawara> apw: ack
<apw> right now i am not at all sure how to get out of my hole
<ogasawara> apw: is that a warning that I shouldn't try testing
<apw> i wouldn't upgrade to oneiric with that kernel as the runnig one
<apw> i have a mahcine half upgraded with libc6 half installed
<apw> i suspect rebooting will not be a winning plan
<apw> as to how to get out of it with a half installed package which won't install ... erm
<tkamppeter> smb, apw, now I have rebooted without any hub or printer connected and the problem persists. 
<tkamppeter> smb, apw, if this is really from a broken piece of hardware this would mean that this piece of hardware is messing up the memory of the USB subsystem, breaking it down until the system gets neutralized again (30 min without battery).
<apw> cking, that sounds like you magic EC loses its mind fix ... scarey
<smb> tkamppeter, Unfortunately that can happen. I got one older desktop that sometimes gets into that state. Removing all power is simpler there, though. 
<smb> Not sure whether 30mins without battery are really needed
<apw> cking, can you rmember what the rules are if you over current a USB port.  i seem to remember they can stay disabled forever
<apw> "forever" meaning until power is removed ...
<cking> apw, I'm not sure - I don't know much about USB.
<tkamppeter> apw, smb, the USB port seems not to be disabled. lsusb -vvv finishes after a timeout of some minutes and all printers are visible after that.
<cking> This is what I googled: "On a laptop, a "power bug" chip is used. That is an 8 pin DIP
<cking> chip. It has a precision current sense inside. If the current
<cking> exceeds 500mA, some FET transistors inside turn off the power
<cking> feeding the USB port. At the same time, a logic signal from the
<cking> power bug, is sent to one of the OC# pins on the Southbridge.
<cking> As a result, the laptop doesn't need a fuse."
<cking> so it should only last until one powers the box off
<apw> cking, thanks :)
<tkamppeter> cking, thanks.
<cking> on a desktop, a polyfuse is used, which may need a long while to cool off before being re-usable
<tkamppeter> strange is that the USB plug in which always have the hubs with the printers I is on bus #1. the internal hub which makes lsusb -vvv hanging for several minutes is bus #7, device #1.
<cking> http://www.pcreview.co.uk/forums/usb-overcurrent-status-detected-t4032559.html
<apw> tkamppeter, and what is that device when it finally tells you
<tkamppeter> Also the plug is still working after once having obtained the hanging "lsusb -vvv".
<apw> perhaps something else is broke, on that bus
<tkamppeter> apw: "sudo lsusb -vvv" tells
<apw> tkamppeter, you know it worked on maverick yes ?
<tkamppeter> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
<apw> so perhaps boot a maverick livecd and see if it still does work there
<tkamppeter> as the start of the new entry, then it hangs for several minutes and continues afterwards.
<apw> so that sounds like there is something on that bus, but its not working hmmm
<tkamppeter> apw, I am running now another "sudo lsusb -vvv" capturing the output, to see what happens after the timeout.
<apw> if you have a place you really know it worked, i think a livecd at that level to confirm if its bug or h/w
<cking> or both perhaps?
<tkamppeter> apw, after the timeout, the broken device's properties are shown normally and no error message is shown. After that the entries of the remaining devices is shown with normal speed.
<smb> apw, cking Could it "think" that something is connected but there is not anything for real? Or something broken indeed. Hard to tell.
<cking> smb, it's hard to tell at this point
<tkamppeter> apw, smb, cking, now I am on Oneiric with the default kernel, all hubs and printers disconnected, shut down the system, taken out the battery for some seconds, booted into said OS. Added back the hubs and printers one by one, tested after each device. Everything perfect as long as the HP LaserJet 1020 is not connected. System even recovers after having connected and removed the LaserJet 1020 (LJ 1020 directly on computer, all the other
<tkamppeter>  printers on hubs as before).
<jdstrand> ogasawara: hey, I wonder if 760131 and 751689 are related in any way...
<jdstrand> ogasawara: nothing to do there, just a thought
<apw> bug 760131 bug 
<ubot2> Launchpad bug 760131 in ubuntu-release-notes "Power consumption raised significantly in natty" [Undecided,Fix released] https://launchpad.net/bugs/760131
<apw> bug 751689
<ubot2> Launchpad bug 751689 in linux "Thinkpad x201* overheats due to slow fans when on 'auto'" [Critical,Confirmed] https://launchpad.net/bugs/751689
<apw> jdstrand, maybe the issue is made visible by the clear heating we see with out the fix for the former, but clearly its still a bug somewhere in the latter case, likely bios
<jdstrand> make sense
<tkamppeter> apw, smb, cking, all is working now for me as long as the LaserJet 1020 is not connected and even returns when disconnecting the LaserJet 1020. On two Natty boxes the LaserJet 1020 works without any problem.
<tkamppeter> apw, smb, cking, thank you very much for your help.
<tkamppeter> apw, smb, cking, and it seems that taking out the battery for some seconds is enough to reset the EC.
<cking> cool
<vish> hi, i'm trying to kernel bisect and i'm following instructions from https://wiki.ubuntu.com/Kernel/KernelBisection , but after i did a $ git checkout -b mybisect origin/master , i dont have a debian.master/changelog file to add the changelog entry
<vish> (there is no debian folder too)
<vish> how do i get to build the bisected kernel?
<jjohansen> vish: what kernel did you clone?
<vish> maverick
<jjohansen> vish: if you do
<jjohansen> git checkout master
<jjohansen> do have a debian folder then?
<vish> oh! , /me tries
<vish> jjohansen: woot! yea, now i have the debian folders,  so would that give me the bisected kernel or the master..  or do i just have to continue as in the wiki?
<jjohansen> vish: making the branch just makes it so you don't mess up the master branch, if you don't care, you can do it on master.  If you need to fix master you can always do
<jjohansen> git checkout -f
<jjohansen> git reset --hard origin/master
<vish> jjohansen: nah, i dont care about the master.. i'm just trying to bisect to find the commit, and i need to build the deb.. so, i can just skip the " $ git checkout -b mybisect origin/master " part of the wiki and work on the master right?
<jjohansen> yes
<vish> jjohansen: thanks.. :)
 * bjf -> lunch
<Kano> hi, why way module-init-tools raised to 3.13-1-u? i had no problems using 3.12-1
<Kano> and even the lenny version was enough in my tests
<Kano> which is 3.4...
<Kano> a bit stupid to use those depends on mainline
<Kano> you compile the kernel in hardy chroot but depend on a oneric package....
<Kano> i can patch that on the fly but it is a stupid thing...
#ubuntu-kernel 2011-06-11
<jjohansen> back on later
<Kano> hi, why do i still need to hack the controls for the daily kernel?
<Kano> module-init-tools should not be higher than the version in hardy for those kernels, otherwise it is useless. hacking with dpkg-deb takes ages on slower systems
#ubuntu-kernel 2011-06-12
<njin> hello guys, seems to me that the 3.0rc2 is having problems, can you confirm that?
<njin> one this machine works, but on two portable it wont work
<njin> bug 390592 spam
<ubot2> Launchpad bug 390592 in ubuntu "I cannot get my headphones to work, tried all the fixes. Sound is fine. Has a ALC861 toshiba card. I work with Jaunty" [Undecided,Invalid] https://launchpad.net/bugs/390592
<CarlFK> 2011-06-08 installed nightly.  it loads yenta_socket module, which my firewire EC card needs.  current nightly does not load it by default.  If I modprobe it, firewire card works.
<CarlFK> I am skimming u-kernel list, don't see much chatter about what modules are included and such.  is there somewhere else I should look?
<chadhogg> I apologize if this is the wrong venue, but I was hoping to get some real-time feedback on what I could do to continue debugging Launchpad bug 793437
<ubot2> Launchpad bug 793437 in linux "Unusable Slowness In 2.6.38-8" [Undecided,Confirmed] https://launchpad.net/bugs/793437
#ubuntu-kernel 2012-06-04
<ppisati> moin
<smb> morning
<ericm|ubuntu> ppisati, what's the solution for irq_to_gpio() being messed up in 3.2 kernel, which may have impact on several ARM flavours?
<ppisati> ericm|ubuntu: messed?
<ppisati> ericm|ubuntu: IIRC every platform provides its own implemantation
<dholbach> hey
<dholbach> how do I debug a kernel which crashed (no magic sysrq, had to turn off and back on again) - nothing in /var/log/syslog?
<ppisati> smb: apw if off today, right?
<smb> ppisati, and tomorrow
<smb> dholbach, not very much
<dholbach> that sucks :-(
<smb> dholbach, You had flashing caps (if there is still a led for it)?
<dholbach> nope, it didn't flash
<smb> So it might not have gone to the crash handler. Did you try to ping/ssh into it and it was dead, too?
<dholbach> no, I didn't have another machine to ping it handy
<dholbach> but changing to the console, magic sysrq and ctrl-alt-del weren't available
<smb> Hm, ok. Wait you were able to change to the console?
<dholbach> no
<dholbach> none of the above worked
<dholbach> I had to power off and back on again
<smb> dholbach, ok, so it still could be a lock up which affected the input handler as well.
<dholbach> right, I guess so
<smb> But the problem is without anything else it could be that or something else. Just not possible to say anything for sure... :/
<smb> dholbach, So the only thing you can do is trying to observe whether it repeats and if it does whether there is any pattern to it.
<dholbach> ok, let's say I have a machine to ssh/ping it with next time
<dholbach> what are the next steps, if I 1) can ssh into it, 2) can't
<dholbach> it doesn't happen very often, so bisecting kernels will be hard to do
<dholbach> is there any debug information I can try to dig out?
<dholbach> (this time I didn't do anything out of the ordinary: IRC, some terminals)
<smb> If it pings, it is at least alive on a low level. If ssh succeeds its a lockup somewhere in X/input, ssh responding but login not succeeded, may point to a low-memory issue
<dholbach> low memory meaning I ran out of memory or that there's a bug in memory handling somewhere?
<smb> right
<dholbach> I can't imagine I ran out of memory this time
<dholbach> but I'll check the next time
<dholbach> is there a way to have a kernel with more debug output or something?
<smb> That was more related to the case that you can ssh but the login does not work. 
<dholbach> ah ok
<smb> The problem with that kind of bug is that if shutting down is the only solution then more debug does not help either
<dholbach> at least some of it might have gone to /var/log/syslog, no?
<smb> You can boot with "debug" (instead of quiet) in the kernel commandline from grub
<dholbach> alright, will do
<smb> Most of the times if there is a hard crash, writing to a filesystem stops before that (its not synchronous)
<dholbach> ok
<ericm|ubuntu> ppisati, omap provides one?
<dholbach> thanks smb
<dholbach> I'll see what I can dig out
<ericm|ubuntu> ppisati, git grep 'irq_to_gpio' arch/arm/mach-omap2/ shows no result
<smb> dholbach, Welcome. The primary step right now would be to find out whether it was really a crash (able to ping/ssh or not). The next steps would then depend on that outcome
 * dholbach nods
<ppisati> ericm|ubuntu: sorry, omap3 in master is busted... :P
<ericm|ubuntu> ppisati, which ARM flavour is not busted so far?
<ppisati> ericm|ubuntu: err.. i think you are right, and i'm pretty sure i hit this in the omap4 branch too
<ppisati> ericm|ubuntu: :)
<ericm|ubuntu> ppisati, I think the issue could have been fixed in Q (3.4) by the way, we may have to identifiy and backport them
<ppisati> ericm|ubuntu: uhm
<ppisati> ericm|ubuntu: drivers/gpio/gpio-ep93xx.c:#define irq_to_gpio(irq)     ((irq) - gpio_to_irq(0))
<ppisati> ericm|ubuntu: and gpio_to_irq() is defined for mach-omap2/$board
<ericm|ubuntu> ppisati, that's actually not a correct fix
<ericm|ubuntu> ppisati, but not irq_to_gpio()
<ericm|ubuntu> ppisati, all those drivers making use of irq_to_gpio() now failed in 3.2
<ppisati> ericm|ubuntu: do you have the commit where they retired irq_to_gpio for omap?
<ericm|ubuntu> ppisati, I think it's a global one, removing all the specific APIs to asm-generic
<ericm|ubuntu> ppisati, wait
<ericm|ubuntu> ppisati, 7563bbf gpiolib/arches: Centralise bolierplate asm/gpio.h
<ppisati> and i just found out another case where having vfat + nls_iso8859_1 builtin is mandatory...
<ericm|ubuntu> ppisati, actually when doing the config comparison, I came up with the table - https://wiki.canonical.com/EricMiao/Highbank/ConfigReview/Ubuntu-3.2.0-25.40/5/PurpleLinesClassified
<ericm|ubuntu> ppisati, where we do have many inconsistent config options between ARM flavours and X86 ones
<ericm|ubuntu> ppisati, some are for no obvious reason
<ppisati> ericm|ubuntu: i know, it's on my todo list
<ericm|ubuntu> ppisati, ok - just let know what I can help on that
<ppisati> ericm|ubuntu: https://wiki.ubuntu.com/Kernel/Dev/pisosandbox
<ppisati> ericm|ubuntu: but this one is only for omap4
<ericm|ubuntu> ppisati, and btw - apw is working on config alignment between flavours
<ppisati> ericm|ubuntu: yep
<janimo> apw, do you know if adjustments were made to kernel package builds to cope with some headers moving to multiarch dirs? I get sys/types.h not found when building scripts/basic/fixdep in the armadaxp kernel
<orated> Hey ppisati
<orated> I'm using Beagleboard B4 and for getting ethernet working, a usb-ethernet adapter is connected. I'm not able to get ethernet working on it. Is there any specific kernel module required to be loaded for it to work? My connection setup - Both beaglebaord and USB hub are externally powered with 5V supply. USB ethernet adapter connected to the HUB
<ppisati> orated: if the adapter is supported, the module should be autoloaded
<ppisati> orated: have you tried this adapter with another pc running ubuntu?
<orated> Yes
<orated> Hold on, I'll give you the details
<ppisati> orated: does it work? which module does it use?
<orated> ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter
<orated> 						driver:dm9601(configuration: autonegotiation=on broadcast=yes driver=dm9601 driverversion=22-Aug-2005 duplex=full firmware=Davicom DM9601 USB Ethernet ip=192.168.10.110 link=yes multicast=yes port=MII speed=100Mbit/s)
<orated> Same setup on host system with the hub
<ogra_> do you see it with lsusb 
<ogra_> ?
<ogra_> (on the beagle that is)
<ogra_> note that nobody in the ubuntu dev team has tested on beage B models in years (they dont fulfill the minimal reqs.we usually only test XM)
<orated> On the beagle, no 
<orated> ah
<ogra_> a server install should still be possible on the rev. B though
<orated> Could you guide me on that?
<ogra_> (dont expect a great experience with 600MHz and 128MB though)
<orated> I only need network connection to install and update packages
<ogra_> hmm, https://wiki.ubuntu.com/ARM/Server/Install used to have a section for omap3 too, seems it is gone, talk to #ubuntu-server, seems they removed that section (especially all the special setup you hgave to do with old beagles)
<orated> I tried sudo dhclient usb0 and then ifconfig usb0 192.168.1.5 netmask 255.255.255.0 and they ran without errors
<orated> ok, I'll try
<ogra_> well, does a plain ifconfig show the usb0 device ?
<orated> yes
<ogra_> so your network should work then after you set up proper routing
<orated> proper routing, like? I'm new to nwtwork related tasks
<ogra_> look on your desktop computer (if its in the same network) with "route -n" what the default GW points to 
<orated> Yes, in the same network
<ogra_> then use "sudo route add efault GW <IP you found above>"
<ogra_> *default
<ogra_> probably gw needs to be non capitalized ... 
 * ogra_ doesnt use this very often
<ogra_> after that try to ping the gateway IP
<orated> ogra_: http://paste.ubuntu.com/1022830/
<orated> Is that correct?
<ogra_> well, are you sure a plain ifconfig (without options) shows usb0 on the beagle ? also, if you use dhclient you dont need to set the IP manually with ifconfig afterwards
<ogra_> (and if the dhclient command worked you shouldnt need to set the route either)
<orated> ogra_: Yes, http://paste.ubuntu.com/1022834/
<orated> There are some garbage character coming on the serial terminal though
<ogra_> looks all fine, you should be able to ping the GW right after the dhclient command, weird that you cant
<orated> Alright, now I would like to know if there is any need to load module like g_ether ?
<ogra_> no, g_ether is for USB->USB networking through an USB cable 
<orated> Ethernet gadget, ok
<ogra_> (it emulates the ethernet connection between two USB devices)
<orated> Then is there any module required for usb-ethernet adapter?
<ogra_> no
<ogra_> not apart from the one that brings it up as usb0
<ogra_> which apparently is already loaded on your beagle (else ifconfig wouldnt see a device)
<ogra_> so there might be a bug with that driver or a wrong/outdated firmware etc ... i'll leave you with ppisati to debug that part :) 
<orated> In desktop with USB hub it uses driver:dm9601 and without usb hub, its not getting connected. So in beagleboard, is there any module to load to be use that driver?
<orated> hmm, thanks for your help :)
<ppisati> orated: i bet you need the dm9601 kernel module
<ogra_> well, if ifconfig sees usb0 that driver should be in use already 
<ogra_> lsmod|grep dm9601
<ogra_> that should show the module being loaded on the beagle 
<ppisati> ogra_: isn't it the usb network?
<orated> no, nothing ogra_
<ppisati> orated: we had the usb0 as a nic till maverick
<ppisati> orated: sudo modprobe dm9601
<ppisati> orated: which kernel are you using?
<ogra_> (and which image did you install)
<orated> omap 3.2.17-11 #1 SMP Tue May 15 12:16:43 UTC 2012 armv7l
<ppisati> orated: find /lib/modules/`uname -r` -name \*9601\*
<orated> one moment please
<orated> ppisati: /lib?mdules?3.217-11?kernel?drivers?net?usb?dm9601.k
<orated> There are still garbage issues, I restarted for the same
<orated> Maybe its the cable or loose connection
<ppisati> orated: ok, then you have the module
<ppisati> sudo modprobe dm9601
<orated> Yes, I did that
<ppisati> uhm
<ppisati> can you bypass the usb hub>
<ppisati> ?
<orated> And its listed now in lsmod
<orated> bypass as in?
<ppisati> and you didn't get anything in console, right?
<orated> nope, just the prompt after the command
<ppisati> ack
<ppisati> then unplug it from the usb hub and attach it directly to the board
<orated> One moment, I think the adapter got disconnected
<orated> Yes, restarting the whole setup. .. One minute
<orated> ppisati:  Regarding OTG port on BB, I've connected a OTB to USB  which is then connected to USB female to female adapter and then it goes to USB hub or USB storage device/usb-ethernet. The problem of connecting it directly without the hub is that, it doesn't get powered up. ..
<orated> Regarding the USB hub, its Belkin self powered 4 ports USB2.0 if that helps
<ppisati> orated: well, the problem is that your board doesn't sense any "usb thing" attached to it wrt to your usb nic
<orated> And I tried it again with the hub, its still outputting nothing on sudo modprobe dm9601, falling back to prompt
<ppisati> orated: so we need to get rid of the usb hub
<orated> It requires to be independently powered
<ppisati> orated: wait
<ppisati> orated: how do you power the board?
<orated> Also , other storage devices comes up with same behaviour. The BB is powered using 5V adapter
<orated> And the hub is also powered using another 5V adapter
<orated> BTW I've noticed that if I connect any storage device to the hub, it doesn't show up in /media
<ppisati> ok, the if the board is powered indipendently, why can't you unplug the usb hub and attached the usb nic to the board?
<ppisati> *attach
<orated> Oh, you wanted to know if OTG is unused or not. Yes, I can unplug the usb nic from hub and conenct to board but its not getting its not getting sufficient power to start it. There is a LED on the nic which glows when RJ45 is connected
<orated> Anyway, I'll try connecting it directly again
<orated> Nic removed from the hub, connected to board, no led on nic
<ppisati> any msg on console?
<ppisati> dmesg?
<orated> No, the serial console hanged
<orated> Its not accepting any input. Hold on please
<orated> ppisati: Back, no no change in dmesg on connecting/disconnecting nic directly to the board
<orated> ppisati: Do you think its due BB being not sufficiently powered?
<ppisati> orated: could be
<ppisati> orated: i've a dm9601 adapter, let me try it with my bbxm
<orated> ppisati: But then what's the problem when USB hub is used?
<orated> ppisati: And secondly, I don't understand why usb storeage devices don
<orated> n't show up in lsusb//media when they are connected to the hub
<orated> storage*
<orated> Is 12.04 LTS server image supported for BB or should I try 11.10?
<ogra_> as i said before, we all only test on beagle Xm since it is the only beagle that fulfills the minimal requirements for ubuntu
<ogra_> so getting it to run on a beagle rev. B is really a matter of luck
<jMCg> I got 10.10 in a KVM in an init=bash: http://dpaste.com/755097/ -- can someone help me debug and make it boot?
<jMCg> s/10.10/10.04/
<ogra_> seems to boot just fine 
<ogra_> (for booting with init=bash at least)
<jMCg> ogra_: that's true, but when I take that away, it chokes. I've pasted --verbose and --debug in this channel, let me reproduce those.
<jMCg> http://sprunge.us/iGaU << --debug
<orated> ppisati: Is dm9601 adapter working for you in BB xm?
<orated> Unfortunately, xm is on back order here and can be available only after a month
<ppisati> [ 3757.129302] usb 1-2.2: new full-speed USB device number 8 using ehci-omap
<ppisati> [ 3757.365447] dm9601 1-2.2:1.0: eth1: register 'dm9601' at usb-ehci-omap.0-2.2, Davicom DM9601 USB Ethernet, 00:10:13:50:a3:43
<ppisati> [ 3757.373413] usbcore: registered new interface driver dm9601
<ppisati> orated: ^^
<ppisati> works here
<ppisati> orated: what's the output of your power adapter used with BB?
<ppisati> orated: i'm using a 5v 3.8A adapter
<orated> 5V 900mA for BB, 5V 2.6A for hub
<ppisati> ah
<ppisati> orated: i doubt that's enough
<orated> current rating, yes
<ppisati> but when you attach stuff, it drains power
<ppisati> orated: try with a beefier adapter
<orated> ppisati: Yes, one moment. brb
<bjf> ppisati: bug 951043 needs verification, can you take care of that ?
<ubot2`> Launchpad bug 951043 in linux-ti-omap4 "Port OOM changes into do_page_fault for arm" [Medium,Confirmed] https://launchpad.net/bugs/951043
<ppisati> bjf: ack
<orated> ppisati: Is it possible to install xfce/gnome and opencv offline on SD card and run them on BB?
<ppisati> orated: an a BB board? no way, it'll swap like hell
<ogra_> on a BB rev. B !
<ogra_> (600MHz/128MB ram)
<ogra_> probably lxde or a standalone window manager might work ... 
<ogra_> xfce and gnome are surely to big for that
<ppisati> bjf: there's no mention of any test to validate that bug, i can confirm the patch is there and kernel boots, but not much more
<orated> Afaik, its lxde>xfce>gnome>KDE in incresing order of memory consumption
<orated> So, is it possible to install lxde and openCV offline on SD or atleast openCV?
<ogra_> yes, install qemu-user-static on your host PC ... 
<ogra_> then *manually* mount the SD, copy qemu-arm-static from /usr/bin of the host into /usr/bin of the SD and you can chroot into the SD card
<orated> ogra_: Does chroot requires that the host and guest should be of same architecture... arm-arm, x86-x86 ?
<ogra_> not with qemu-user-static
<orated> Ah-ok
<ogra_> but you need to copy the binary from the host to the same place on the SD
<tgardner> ogasawara, whats the story on 3.4.0-4.9 ? Is that the version you intend to upload ?
<ogasawara> tgardner: it is, just wanted to get a quick powerpc build and will then upload.
<tgardner> ogasawara, ok, I'll start the precise backport
<ogasawara> tgardner: I just wanted to shove the closing commit in there in case I/you wanted to get a jump on the 3.5-rc1 rebase
<ogasawara> tgardner: I have not yet pushed it to master
<tgardner> ogasawara, nah, I think we can wait until -rc2
<ogasawara> tgardner: ack
<tgardner> ogasawara, 'sides, I'm bailing for a week and don't wanna start something I can't finish today.
<ogasawara> tgardner: I was also looking at the highbank meta package patch, is there a specific reason we mark the linux-headers-<flavor> packages as "Section: devel" rather than "Section: metapackages"?
<ogasawara> tgardner: I notice it's only the headers meta packages which are marked devel, all other meta packages are marked as metapackages
<tgardner> ogasawara, missed that. I'll fix it.
<tgardner> ogasawara, ok, now I've read your comment for content. I don't think 'Section:' has any real impact in the Ubuntu archive, but I'll ask just to be sure. In the meantime I think its OK as its been that way for multiple releases.
<ogasawara> tgardner: indeed, I don't think it should hurt anything and should be ok to fix up later if we want to
<tgardner> ogasawara, its a simple change, so I might as well get it in before A1. gimme a minute.
<tgardner> ogasawara, hmm, I wonder wtf 'Section: restricted/metapackages' means for powerpc*  ?
<ogasawara> tgardner: hrm, no idea there
<tgardner> why not just 'Section: metapackages' ?
<ogasawara> tgardner: that sounds fine to me
<ogasawara> tgardner: I've been trying to find a defined list for Section: but have been unsuccessful in my searching
<tgardner> ogasawara, ok, I pushed both changes, so I guess we'll just see what breaks.
<ogasawara> tgardner: ack
<infinity> Anyone know why the ti-omap4-tools package was dropped from linux-ti-omap4?
<infinity> tgardner / apw: Also, apparently it's our PlusOneMaint month.  Had you guys sorted out how you plan to split your time?
<tgardner> infinity, all of the omap tools should come from the main kernel.
<tgardner> infinity, apw will get started on +1 maint after the UK holiday. perhaps wednesday ?
<infinity> tgardner: I thought tools had to precisely match ABI or some such, hence the extra packages from out-of-tree builds?
<infinity> tgardner: (This was always the case in previous releases, but I'm happy to be told that was a mistake)
<tgardner> infinity, perf is the only tool that is ABI sensitive. lemme review... its been awhile.
<infinity> tgardner: Right, and perf is part of -tools. :P
 * ogasawara back in 20
<tgardner>  I'm not sure we're even building perf 'cause it was causing FTBSs, but that was a bit ago during early -rc's
 * infinity checks the linux-ti-omap4 changelog.
<infinity> I see no mention in the changelog of dropping the tools build, it just disappeared with no word.
<tgardner> infinity, looks like I turned it off during the early dev cycle because of FTBS. 'UBUNTU: [Config] armhf: do_tools=false'
<infinity> tgardner: Oh, was that in the changelog and I'm just blind?  Or just in the git logs?
<tgardner> infinity, just the git logs
<infinity> Anyhow.  Not world-ending for now, just makes the tools metapackage uninstallable, but would be nice to restore it if and when it can be made to work.
<tgardner> infinity, working on it...
<infinity> Or maybe it'll all become moot if omap4 upstreaming keeps going well, and we can build 3.5 from mainline.
 * infinity crosses his fingers.
<tgardner> infinity, ain't gonna happen. there is still a pile of BSP patches for ti-omap4
<infinity> At which point, to keep ppisati from getting bored, we'll have to get him to do an mx6 or omap5 or something. ;)
<tgardner> 5 is coming
<infinity> tgardner: Shame.  I was led to believe it was getting close.  Though, maybe we're still carrying some "won't ever go upstream, don't even try" bits.
<ppisati> it's already here, i didn't turn it on yet
<orated> Sorry, got disconnected before. Thanks ppisati and ogra_ for help
<infinity> ppisati: Does that mean you have a Panda5, or have you just been doing omap5 blind and hoping it will boot? ;)
<ppisati> infinity: it means the BSP supports both omap4 and omap5
<ppisati> infinity: but i din't enable the omap5 side yet
<infinity> ppisati: Ahh.
<ogra_> thats what they tell you :P
<dreks> I'm trying to set up L2TP over IPSec and I've got the IPSec conn established. When I try to start the L2TP connection with xl2tpd, the kernel log starts filling and PC becomes unusable. I have tested the exact same setup on in virtualizatin and its flawless. I believe it has something to do with my ethernet hardware/kernel combination.
<dreks> I've posted a portion of my kern.log here, http://paste.ubuntu.com/1023244/
<dreks> I've tried grabbing the Realtek driver for the integrated adapter straight from their site and using that. It produced the same result.
<ogra_> dreks, your message might become readable if you change your colors ...
<dreks> Sorry.
<dreks> That better?
<ogra_> yep 
<dreks> I'm trying to set up L2TP over IPSec and I've got the IPSec conn established. When I try to start the L2TP connection with xl2tpd, the kernel log starts filling and PC becomes unusable. I have tested the exact same setup on in virtualizatin and its flawless. I believe it has something to do with my ethernet hardware/kernel combination.
<dreks> I've posted a portion of my kern.log here, http://paste.ubuntu.com/1023244/
<dreks> I've tried grabbing the Realtek driver for the integrated adapter straight from their site and using that. It produced the same result.
<tgardner> dreks, try the quantal kernel from https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<dreks> ok, i can try that. Thanks. Do you see anything in the logs that might indicate kernel over driver problem?
<tgardner> dreks, the r8169 driver has had lots of problems in the past, so I suspect you might be right.
<dreks> Is there anywhere else I can look for driver related bugs? I'd like to find out whats to blame, kernel or driver
<dreks> If I need to replace a ethernet card because the issue has not been resolved with the driver, I will do so, but I want to find evidence it's not the kernel
<tgardner> dreks, you could try asking romieu@fr.zoreil.com (the maintainer). be sure to Cc: netdev@vger.kernel.org
<dreks> thanks
 * ppisati -> gym
<tgardner> ogasawara, so, you're happy with Ubuntu-3.4.0-4.9 ? I'll get the LTS backport started.
<ogasawara> tgardner: I am, just pushed to master.  Am prepping the upload right now.
<tgardner> ogasawara, yep, saw that when I jst pulled.
<tgardner> just*
<infinity> tgardner: So, linux-ti-omap4-tools-3.4.0-201 is now the only thing standing between me and beer on the archive health reports. ;)
<infinity> ppisati: ^
<infinity> ppisati: Do you know if the tools can be re-enabled (or, if they need fixing, can we?)
<tgardner-afk> infinity, I've got a test build going. if successful I'll upload later this afternoon
<infinity> tgardner-afk: Ahh, fancy.  Thanks.
 * tgardner-afk is now really afk...
<infinity> ogasawara: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005699 is preventing us from upgrading some of our buildds to precise.  Is there a formal escalation process for these sorts of things?
<ubot2`> Launchpad bug 1005699 in linux "tg3: reports "eth0: DMA Status error. Resetting chip.", fails to work" [High,Confirmed]
<ogasawara> infinity: usually assigning it to the canonical-kernel-team in lp gets it on our radar, or pinging us directly like you've just done
<infinity> ogasawara: Looks like it's fixed upstream, so should just be some tedious bisection back and forth.
<ogasawara> infinity: ack, will get a resource on it and get it sorted
<infinity> (Or perhaps not even that, if the changes to the driver are limited and obvious, I guess)
<infinity> ogasawara: <3
<orated> ogra_: Still there?
<Kano> hi
<Kano> i see your quantal builds need libc 2.14
<Kano> is it possible to lower that to libc 2.13 as debian only uses 2.13
<jjohansen> ogasawara: so I looked into CONFIG_NF_CONNTRACK_PROCFS its obsolete, and should not be set (so no change) do you want an email to the list before I mark the wi done
<ogasawara> jjohansen: if you could just send a quick email that'd be great.  it'd be nice for historical tracking purposes.
<infinity> tgardner-afk: Tools build for ti-omap4 seems to be missing a build-dep on flex.
<infinity> (at least)
<infinity> tgardner-afk: There's also the warnings about missing newt/gtk/python support due to not having those dev packages installed, but I'm guessing you don't turn those on for the master branch either?
#ubuntu-kernel 2012-06-05
<infinity> ogasawara: The linux FTBFS on arm is, I assume because someone kept the abi/modules check on during an ABI change? ;)
<infinity> (Which seems accidentally intentional, from the changelog)
<infinity> ... and bison.
<orated> Hello! Are there packages right to try lxde on BeagleBoard B4 - apt-get install lxdm lxde lxlauncher lubuntu-desktop - ? I know the board is ancient, but would like to try
<ppisati> moin
<smb> morning ppisati 
<infinity> ppisati: You may want to take over Tim's attempts to fix the ti-omap4 tools build with a test build in a clean chroot. ;)
<infinity> ppisati: He added a flex build-dep, and now it fails cause it needs bison.
<ppisati> infinity: did he push it?
<infinity> ppisati: He uploaded it, so I assume it's in git too.
<infinity> ppisati: And if you're bored, sorting out the linux build failure on armel would be snazzy too. ;)
<infinity> (Unsure if it's FTBFS because the modules check shouldn't be on, or if the missing/changed modules it reports are actually a bug)
<ppisati> infinity: i'll give it a shot
<infinity> ppisati: <3
<infinity> ogasawara: Despite the armel build failure (which I hope you guys sort), I suspect it's time for a new linux-meta.
<infinity> ogasawara: I'd upload one, but I get smacked for doing so without comitting to git, and I've never bothered to whine about zinc access. ;)
<ppisati> q/omap4 you mean?
<infinity> ppisati: q/linux-ti-omap4 for the tools build issue (missing build-deps), q/linux for the armel failure (module checker sadness)
<ppisati> ok
<infinity> ppisati: The former is the only real concern for me right now, armel can be fixed later.
<ppisati> but you wanted a new meta for...
<infinity> But if you're bored, by all means, fix both. ;)
<infinity> ppisati: Oh, new meta for linux.  ti-omap4 didn't have an ABI bump.
<ppisati> nack
<infinity> (Though, it would if you rebased, I suppose, which you probably should) :P
<ppisati> q/master wrt arm is broken ATM
<ppisati> i've a patch that restore usb*
<ppisati> and i'm trying to get the video back
<infinity> Oh, fun.
<ppisati> ah, and btw, don't know if we care so much about armel...
<infinity> No, but the breakage there looks obvious. :P
 * infinity decides it's time for a nap.
<orated> Hey ogra_
<ppisati> infinity: can't reproduce your build q/master build failure (cross compiling i got both armel and armhf 3.4.0-4.10)
<infinity> ppisati: Weird.
<jibel> I get bug 1008905 with Quantal A1 on a Mac Mini. Do you need more info than what's been automatically attached ?
<ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [Undecided,Confirmed] https://launchpad.net/bugs/1008905
<smb> jibel, I think this should be good enough
<jibel> smb, k, thanks
<cooloney> morning guys, 
<cooloney> smb and apw, did we discuss to use CFQ to replace deadline scheduler in our -server kernel before? 
<cooloney> as we merge -server kernel with -generic together
<cooloney> actually i'm looking at this bug 1008400
<ubot2`> Launchpad bug 1008400 in linux "Ubuntu server uses CFQ scheduler instead of deadline" [Medium,Confirmed] https://launchpad.net/bugs/1008400
<ohsix> instead huh
<smb> cooloney, I am just on the run, but I think something about schedulers was discussed though I am not remembering the outcome. Would be a matter of command line to the kernel...
<cooloney> yeah, i also think about that. we can easily change that via sysfs.
<cooloney> but no sure about whether we change that to deadline in our server image
<ohsix> he seems to imply that was what it was in the -server images
<ericm|ubuntu> apw, just spotted two issues with devel-config-tag, sent you two patches
<ericm|ubuntu> cooloney, think we are already using deadline for server flavour
<ericm|ubuntu> cooloney, ok - that was CONFIG_DEFAULT_IOSCHED
<smb> No we do not. At least not in Precise and Quantal. It would be a way to change the default to modify the kernel arguments
<smb> It is some sort of decision you have to make anyway when setting up a server. Beside of other things that one needs to adapt
<ppisati> infinity: actually tools/perf is the same for x86 (i386 and amd64) and ti-omap4
<ppisati> infinity: but in *86 chroot flex is installed, while it's not for omap4
<ppisati> infinity: i think it's your problem now since we require it
<ogra_> ppisati, what about flex ? it built and is in the archive 
<ogra_> if you actually require it for a package it needs to be a build-dep
<ppisati> ogra_: and it is
<ppisati> ogra_: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=blobdiff;f=debian.ti-omap4/control.stub.in;h=4eedc6957c482c1b1c1a8e2739980b92ae349dd5;hp=f30e1962d3a382976949b9ec63362c047aaa84e0;hb=8debe7fa58d36bd9d1eb5b2fa90e5735c90239ef;hpb=20db486d4e826c21143ff2e875eb5209ba3216f8
<ppisati> ogra_: isn't it enough?
<ogra_> are you sure that doesnt need to be libfl-dev ?
<ogra_> (what doe the other kernels have there as a b-dep ?) 
<ogra_> *do
<ppisati> ogra_: hold on
<ppisati> ogra_: master has flex and bison
<ppisati> ogra_: but in our case, it chokes on fle
<ppisati> x
<ppisati>     FLEX util/pmu-flex.c
<ppisati> /bin/sh: 1: flex: not found
<ogra_> https://launchpad.net/ubuntu/+source/flex/2.5.35-10ubuntu3 at least indicates that it is available for all arches so if it is a dep it should end up in the chroot 
<ppisati> ogra_: yep, but infinity pointed the compilation failure to me like it was a kernel compilation problem
<ppisati> ogra_: while our side looks sane to me
<ppisati> infinity: ^^
<ppisati> ouch
<ppisati> actually it needs bison too
<ppisati> so we have two problems
<ppisati> 1) chroots need flex
<ppisati> 2) we need to add bison to b-dep
<ogra_> i'm pretty sure chroots dont have flex and are not supposed to 
<ogra_> this needs to come in through the deps
<ppisati> i just built two fresh Q chroot (amd64 and armhf)
<ppisati> and i confitm they don't have flex nor bison
<ogra_> right
<ppisati> but we need both of them for perf/tools
<ogra_> why would they
<ppisati> because upstream want it :)
<ogra_> hmm ?
<ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=blob;f=tools/perf/Makefile;h=92271d32bc30b2056c472f273b1af6bed9847b31;hb=8debe7fa58d36bd9d1eb5b2fa90e5735c90239ef
<ppisati> look for perf and bison
<ppisati> sorry
<ppisati> flex and bison
<ogra_> we should break deboostrap for an upstream that doesnt want build deps in packages ?
<ppisati> i'm not a package expert, so i don't understand what you said here
<ppisati> let's take master kernels as an exam,ple
<ppisati> they have flex and bison listed as dependencies
<ppisati> isn;t it enough?
<ogra_> well, if xorg would say we need blah, would you hack debootstrap to have blah by default or would you fix xorgs build dependencies ?
<ppisati> i see what you mean, but we already do that
<ogra_> (note that if you would do that for every package a default chroot would become several gigabyte big)
<ppisati> i see what you mean
<ogra_> ok
<ppisati> but the linux kernel started to relies on them so, i don't think there's much we can do
<ogra_> what i mean is that it cant be a chroot problem but that something is wrong in your deps
<ppisati> and, btw, master already enforce them
<ppisati> i don't understand why we didn't hit this in *86 world
<ogra_> no idea
<ogra_> but its definitely a package side prob, not a chroot side one
<ogra_> probably a dep of flex is broken or missing and thus the package isnt installable, but then your linux build should forcefully fail
<ppisati> ogra_: imo flex and bison should be added to build-essential
<ogra_> ugh, why ?
<ppisati> ogra_: uhm, right
<ogra_> build-essential should only carry the most common denominator *all* packages need 
<ogra_> (compiler, toolchain etc)
<ppisati> ogra_: should come as part of build-dep $linux
<ogra_> right
<ppisati> uhm no
<ppisati> apt-get build-dep linux doesn't list flex nor bison
<ogra_> weird, there is your prob then
<ppisati> right
<ppisati> but we clearly had these two packages in some chroots
<ppisati> since perf didn't break there
<ogra_> thats even more weird
<ogra_> but surely not caused by the chroots ... 
<ogra_> the buildd chroots are empty by default and get freshly unpackaged on every build
<ogra_> from a tarball that only contains the minimal bits debootstrap puts in place
<ppisati> right, that was my question
<ogra_> iirc debootstrap has a cmdline option to create such a chroot ... and afaik it should be possible to actually download the actually used buildd chroots from LP somewhere 
<ogra_> (dont ask me where though)
<ogra_> so you could inspect them
<ppisati> i'm using a fresh chroot, let's see if generic breaks here
 * ogra_ wonders whom he saw talking about that recently, might have been Laney or tumbleweed
<ppisati> ok, while it builds i'm out to get some food
<ppisati> rtg should be here soon, i guess he'll find the culprit quicker than me
<ppisati> in the mean time, /me -> lunch
<ogra_> yeah, btw, there was a question from TI in #ubuntu-arm :) 
<ogra_> (for after lunch indeed)
<ppisati> ogra_: ah, when?
<ogasawara> infinity: meta uploaded, and I fixed the armel FTBS in the 3.4.0-4.10 upload
<ogra_> armel ? i thought you stopped building el 
<Laney> ogra_: wasn't me, but you can get it using the LP API
<Laney> e.g. In [4]: lp.distributions['ubuntu'].current_series.getDistroArchSeries(archtag='armhf').chroot_url
<Laney> Out[4]: u'http://launchpadlibrarian.net/106153668/chroot-ubuntu-quantal-armhf.tar.bz2'
<Laney> (there may be an easier way)
<ogra_> ah, cute, good to know 
<ppisati> ogasawara: when you are awake, can you explain me why 'apt-get build-dep linux' doesn't list flex and bison?
<ogra_> looking at the quantal-changes ML it seems like tim just did an upload with bison added
<ppisati> ti-omap4 or master?
<ogra_> linux-ti-omap4 (3.4.0-201.6) quantal; urgency=low
<ogra_> ...
<ogra_>  * [Config] Added bison as a build dependency
<ogra_> ...
<ppisati> sneaky
<ogasawara> ppisati: I assume you're referring to ti-omap4?  and I thought tim added both flex and bison as build dependencies just recently
<ppisati> ogasawara: yes, he did, but i built two fresh chroot this morning and compilation of master/generic and ti-omap4 choked on perf/tools because "apt-get build-dep linux" doesn't listen flex nor bison as b-dep
<ppisati> ogasawara: so my question is more like "who is responsible for installing flex and bison? shouldn't apt-get build-dep linux do that?"
<ogasawara> ppisati: assuming they're not already installed, yes I would assume that should do it.  And assuming that the package actually lists them as build deps in the the control file (which I believe is also true at least with tim's latest changes).
<ppisati> ogasawara: yep, are listed in debian*/control, aren't present in chroot, but build-dep doesn't list them
<ppisati> ogasawara: btw isn't it a bit too early for you? :)
<ogasawara> ppisati: nah, I usually start about 5:30am local time.
<ppisati> ok
<skaet> ogasawara, any likelyhood we'll be able to get a fix for bug 1008905 today?  or no amd64+mac images for A1?
<ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [High,Confirmed] https://launchpad.net/bugs/1008905
<ogasawara> ppisati: and you're sure you're checking the build deps for the latest 3.4.0-201.6 kernel?
<ogasawara> skaet: hrm, not aware of a fix at the moment.  so won't be able to promise a fix by EOD.
<ogasawara> skaet: but will try
<skaet> thanks ogasawara,  ok,   will not block on waiting for next set of spins unless you flag a fix is imminent. 
<ogasawara> skaet: ack
<ppisati> ogasawara: http://paste.ubuntu.com/1025030/
<ppisati> ogasawara: fresh q/amd64 chroot + apt-get install fakeroot build-essential crash kexec-tools makedumpfile kernel-wedge git libncurses5 libncurses5-dev libnewt-dev
<ppisati> ogasawara: but i've the same for master
<ppisati> ogasawara: builders don't complain about master's flex and bison dependencies so i'm probably doing something wrong with build-dep  i guess
<ogasawara> ppisati: what's the uname -a output?  and I assume you need to do apt-get build-dep linux-image-3.4.0-4-generic
<ogasawara> ppisati: or the omap4 equivalent
<ppisati> ogasawara: indeed, linux-image-$ver is the right invocation, thanks
<ogasawara> ppisati: I assume you've seen though that tim's uploaded the latest 3.4.0-201.6 ti-omap4 kernel.  it's currently building...
<ppisati> ogasawara: yep, few minutes ago
<ogasawara> sforshee: does one of the macbooks or enablement machines you have in your possession have broadcom?  was curious if you are able to reproduce 1008905?  I looks to originate from an issue of missing firmware because the firmware it wants is in linux-firmware-nonfree which isn't on the install media
<smb> man bzr
<smb> -EFOCUS
<sforshee> ogasawara, I was just about to take a look at that one
<sforshee> I've got a couple of machines that are likely to be affected
<sforshee> but I fixed a missing firmware issue in b43 recently, so it may already be fixed
<ogasawara> sforshee: I also saw the following patch http://www.mail-archive.com/b43-dev@lists.infradead.org/msg02461.html when digging around
<ericm|ubuntu> apw, just curious how the symbols in CONFIGS-dump are generated, checking the source they are generated by zconfdump(), yet the invocation to that function is commented out
<ogasawara> ericm|ubuntu: just fyi, apw is away on holiday today
<ericm|ubuntu> ogasawara, ah
<sforshee> ogasawara, that definitely looks related. The fix I did was in the probe, not remove, so it is a different issue.
<ogasawara> sforshee: could you let me know if you are able to reproduce with hw you have on hand?  if so, could you see if that patch helps at least prevent the panic?
<sforshee> ogasawara, ack
<ppisati> ogasawara: is today last day to get something in for alpha1?
<ogasawara> ppisati: it would be, and would likely need an ack by the release team at this point
<ppisati> ogasawara: ack
<ppisati> ogasawara: because a couple of days ago i sent a patch for q/master, and andy said he was going to handle it (since he was messing with config regen)
<ppisati> ogasawara: now, i saw all the config changes for highbank, but not my stuff for omap3
<ppisati> ogasawara: shall i wait for him tomorrow or what?
<ogasawara> ppisati: hrm :(  I do remember seeing that email.  if you have a patch, send it to me now and I'll get it applied.
<ogasawara> ppisati: ah you've already sent it
<ppisati> ogasawara: that's a second one, the first one is missing too (the LPAE config change)
<ogasawara> ppisati: ah, so both are necessary for Alpha1
<ppisati> ogasawara: yep
 * ogasawara nods
<ppisati> video is still broken (fb modules aren't loaded at boot time), but at least with them board boot up, and everything else should work
<ogasawara> skaet: ^^ kernel config changes necessary for omap to even boot, when's the latest we can squeeze in an upload?
<orated_> Hello! What is "display 0" in "Server is already active for display 0". I get that line on < sudo startx > on Ubuntu 11.10 Beagleboard B4 when attempting to start lxde
<ogra_> ppisati, erm, could we disable the penguins on boot please ?
<ogra_> (on omap4 that is)
<ppisati> ogra_: omap3 are off
<ppisati> ogra_: omap4 maybe? sorry, too late :)
<ogra_> right, i see them on the panda 
<ogra_> yeah, not urgent 
<ogra_> it seems to break plymouth 
<ogra_> (at least i dont see a splash)
<orated_> ??
<ppisati> ogra_: i've splash off my boot args
<ppisati> ogra_: btw i don't even remeber the penguins...
<ogra_> well, you should at least occasionally switch it on 
<ogra_> to see if it breaks the userspace :)
<skaet> ogasawara,  prep it up.   Give me a bug number and we'll add it to the list of possible respin triggers.   Just need to respin for arm?  or all?
<ogra_> skaet, not important for A1, we can let that slip
<ogasawara> skaet: ideally if we can confirm a fix for 1008905 I'd want to squeeze that in too which would then result in a respin for all
<ogasawara> ppisati: can you get a bug filed for the config changes
<ogra_> oh, sorry, though leann stole my ping ;)
<ppisati> ogasawara: i'll do
<skaet> ogasawara,  ack.
<ogasawara> skaet: but wanted to know the latest we'd be able to upload, 2100UTC today?
 * ogasawara back in 10min
<skaet> ogasawara,  we'll block the next respin on your upload,  sooner the better.
<ogasawara> skaet: ack
<ogra_> ppisati, is there any reason to not build fb into the kernel ?
<ppisati> ogra_: nope, and did try that
<ppisati> ogra_: but we get a WARN() on boot and display doesn't work at all
<ogra_> ouch, k
<ppisati> ogra_: instead, being =m, if we load it later and restart lightdm, it works
<ogra_> oh, intresting
<ogra_> ppisati, ignore my penguin comment, seems my dd didnt work at all, i booted a TI experimental kernel apparently
<ogra_> (old cruft that was on the SD)
<jwendell> hi, folks. why does the precise kernel have the 3.2.0 numbering instead of follow upstream 3.2.x schema?
<smb> jwendell, I don't remember which exactly, but there were user-space programs and also some external module package expecting a three digit version number and the risk to not find them all compared to add an artificial 0 was too high (iirc)
<orated_> ppisati: Which adapter are you using to get 5V 3.8A for BB B4? or its custom PSU?
<ppisati> orated_: a commont power adapter, nothing special
<ogra_> ppisati, hmpf, can we please put the leds back into the kernel on omap4 ? if i have a crashed screen by whatever reason i cant see that the board is alive at all until the module is loaded 
<orated_> ppisati: I mean the make of it ...
<orated_> ppisati: Usually 5V adapters are never above 1A rating as they are commonly outputted for USB
<ppisati> orated_: any power adapter with 5v 1.5a+ output is good 
<orated_> Yes, 
<ppisati> ogra_: iirc i had blinking leds
<ogra_> ppisati, cant be if the module isnt loaded
<ogra_> to elaborate, the resizing of the image before the gui installer starts happens from initrd ... usually there is plymouth output, apparently thats currently not working so you dont see that the board does anything at all
<sforshee> ogasawara, I've reproduced 1008905 on my mac mini
<ogra_> ppisati, oh, and is there a bug number for the omap3 config stuff ? release team would like to have it in the docs
<ogasawara> sforshee: cool, keep me posted if the patch helps
<ppisati> ogra_: i'm opening it
<ppisati> ogra_: but i wanted to write down the exact message at boot time
<ogra_> k
<ppisati> ogra_: did you use a daily image?
<ogra_> ppisati, yes
<ogra_> the latest, testing for A1
<ogra_> ppisati, i dont seem to be able to get any graphical output from the current quantal omap4 kernel here 
<ppisati> ogra_: uhm?
<ogra_> neither on HDMI nor on DVI 
<ppisati> i've the beagkexn attached now
<ppisati> can't switch board
<ogra_> k
<ogra_> it seems to hang in some loop or so, my monitor shows me alternating the "no signal" sign and then it behaves like something is connected for a second 
<ppisati> ogra_: did you boot up with the monitor attached and turned on?
<ogra_> indeed i did :)
<ppisati> wait
<ogra_> aha, enabling tehj serial console gives more info
<ogra_> DISPC: error SYNC_LOST on channel tv 
<ogra_> HDP irc request failed
<ogra_> err, IRQ
<ogra_> (thats whith HDMI attached, trying DVI now)
<ogra_> same error over and over 
<ogra_> aha !
<ogra_> booting without monitor attched gets me at least a 1024x786 screen when i attach the DVI port to HDMI later
<ogra_> weird, i never had any probs ever with this monitor (and its my default test screen for the panda since day one)
<ppisati> ogra_: monitor detection in P is from upstream
<ppisati> ogra_: they use a gpio and detect when you attach/detach a monitor
<ogra_> ppisati, eeek 
<ppisati> ogra_: works very well
<ogra_> did you talk to andy about that ?
<ppisati> ogra_: in Q i used what i got from TI
<ogra_> oh, ok
<ppisati> ogra_: and it _seems_ to me
<ppisati> ogra_: they do a kind of...
<ppisati> ogra_: busy loop
<ogra_> yeah, apparently
<ppisati> ogra_: if they don't detect anything attached
<ogra_> it works fine if i attach the screen later 
<ppisati> so it's not working really well
<ogra_> so at least there seems to be a fallback
<ogra_> good enough for A1 i guess if we release-note it
<ppisati> ogra_: wait wait
<ppisati> my panda is still booting
<ppisati> ...
<ogra_> todays image ?
<ppisati> nope
<ogra_> i havent tried my older panda yet 
<ppisati> i wanted to see what i've on my disk
<ogra_> i still have a pre-ES around here 
<ppisati> panda es here
<ppisati> fsck...
 * ogra_ wonders why he has ugly scrollbars around the slideshow
<ppisati> video works ok here
<ppisati> but i've an older kernel... uhm...
<ppisati> let me try the last one
<ogra_> yeah
<ppisati> 3.4.0-201-omap4 #2~sndy
<ppisati> ~3.4.0-201-3
<ogra_> i cant check atm, i'm in the middle of the install
<ppisati> btw
<ppisati> bug 1009061
<ubot2`> Launchpad bug 1009061 in linux "Beagleboard doesn't boot" [High,Confirmed] https://launchpad.net/bugs/1009061
<ppisati> is for omap3
<ogra_> ah, thx
<ppisati> ogasawara: ^^
<ogasawara> ppisati: ack thanks.  am building now on gomeisa, would you be able to test boot when it's finished?
<ppisati> ogasawara: yep
<ogasawara> ppisati: just fyi, for the second patch to restore usb, I did an fdr updateconfigs after applying and it cleaned it up to a smaller patch, eg:
<ogasawara> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
<ogasawara> index 1da26ae..ea1b5f9 100644
<ogasawara> --- a/debian.master/config/config.common.ubuntu
<ogasawara> +++ b/debian.master/config/config.common.ubuntu
<ogasawara> @@ -3152,7 +3152,7 @@ CONFIG_MFD_INTEL_MSIC=y
<ogasawara>  CONFIG_MFD_JANZ_CMODIO=m
<ogasawara>  CONFIG_MFD_MC13783=m
<ogasawara>  CONFIG_MFD_MC13XXX=m
<ogasawara> -# CONFIG_MFD_OMAP_USB_HOST is not set
<ogasawara> +CONFIG_MFD_OMAP_USB_HOST=y
<ogasawara>  CONFIG_MFD_PCF50633=m
<ogasawara>  CONFIG_MFD_RC5T583=y
<ogasawara>  CONFIG_MFD_RDC321X=m
<ppisati> ogasawara: ouch
<ppisati> ah ok
<ppisati> uhm
<ppisati> it shouldn't harm
<ppisati> since MFD_OMAP_USB_HOST it's a #ifdef ... inside arch/arm/mach-omap2/usb-host.c
<ogasawara> ppisati: I did a fdr genconfigs and checked it's only on for arm
<ogasawara> :~/ubuntu-quantal/CONFIGS$ grep -rn "MFD_OMAP_USB_HOST" *
<ogasawara> armel-config.flavour.omap:2789:CONFIG_MFD_OMAP_USB_HOST=y
<ogasawara> armhf-config.flavour.omap:2789:CONFIG_MFD_OMAP_USB_HOST=y
<ppisati> good for me then
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ppisati> flag@flag-desktop:~$ uname -a
<ppisati> Linux flag-desktop 3.4.0-5-omap #11 Tue Jun 5 15:52:24 UTC 2012 armv7l armv7l armv7l GNU/Linux
<ppisati> ogasawara: good on my beagle
<ogasawara> ppisati: cool, thanks
<infinity> ogasawara: Thanks for tidying up linux/linux-meta.
<ogasawara> ppisati: will try to get this uploaded shortly.  just want to wait on feedback on the other issue 1008905
<ogasawara> infinity: no worries, it's my own stupid fault.  sorry for the extra work it caused on your end.
<infinity> ogasawara: Meh, pestering people isn't work.
<infinity> *poke*
<infinity> *poke*
<ogasawara> heh
<ogra_> ppisati, ndec asked in #pandaboard which commit our current omap4 tree is based on 
<ogra_> do you know that from the top of your head ?
<ogasawara> sforshee: cool, seems from your bug comment the patch has helped.  I can get it applied, care if I add your Ack?
<sforshee> ogasawara, feel free to add my ack
<ogasawara> sforshee: will do, thanks for the testing
<ppisati> ogasawara: it's noted in the changelog
<ppisati> ops
<ppisati> ogra_: ^^
<ppisati> wait
<ogasawara> skaet: we have fixes for bugs 1008905 and 1009061, am getting them applied and will bupload.
<ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [High,In progress] https://launchpad.net/bugs/1008905
<ubot2`> Launchpad bug 1009061 in linux "Beagleboard doesn't boot" [High,Confirmed] https://launchpad.net/bugs/1009061
<ppisati> ogra_: TI BSP @ 95a4fb91c8880200462e61662e55ed6f9011e74d
<skaet> ogasawara,  thanks.  :)
<ogra_> thx
<ogasawara> skaet: just fyi, it is an ABI bump so I'll follow up with a linux-meta upload
<skaet> ogasawara, understood. thanks for flagging it.
<ogra_> ppisati, hmm, nicolas says thats pretty old 
<ppisati> ogra_: a couple of weeks old
<infinity> ogasawara: You could just slam both the kernel and meta at -proposed, and we can sort it out when it's all built.
<ogasawara> infinity: cool, I'll do that
 * infinity isn't fond of the -meta delay loop. ;)
 * ogasawara neither, although it does save my ass sometimes
<infinity> Heh.
<ppisati> flag@panda:~$ uname -a
<ppisati> Linux panda 3.4.0-201-omap4 #6 SMP PREEMPT Tue Jun 5 16:24:21 UTC 2012 armv7l armv7l armv7l GNU/Linux
<ppisati> ogra_: video works fine here
<ppisati> ogra_: my lcd picks it up every time i reboot the board
<ppisati> ogra_: can you try with a P kernel?
<ogra_> will do
<infinity> ogra_: Could your issue be commandline related or something subtle like that?  (assuming ppisati isn't using the new flash-kernel...)
<ogra_> infinity, the image still uses the hardcoded cmdline debian-cd sets ... 
<ppisati> this is my cmdline
<ogra_> its definitely omapdss related
<ppisati> ro rootwait elevator=noop vram=32M root=UUID=2a29c98b-32b9-45e7-a484-e1aa17b754ef fixrtc console=ttyO2,115200n8 earlyprintk=ttyO2,115200n8 debug
<ppisati> ogra_: try P kernel first
<ppisati> ogra_: if would be in you, i won't rule out an hw issue
<ogra_> you should bump to vram=40M i was told for xorg
<ppisati> ogra_: or a dying hdmi port
<ogra_> ppisati, i seriously dont want you in me !
<ppisati> :)
<ogra_> the ports work fine with the older image that ran until i started testing A1
<ogra_> (which was precise)
<ogra_> ppisati, 3.2.0-1414 works fine but has the penguins 
<ogra_> i.e. my monitor is fully up and running with it
<ogra_> so its a 3.4 issue 
<ogra_> herton, you uploaded 3.2.0-1414 ... can you please disable the bootlogo (i see two penguins here)
<ogra_> (omap4 precise proposed that is)
<herton> ogra_, I pushed what ppisati gave me
<ppisati> ogra_: i'll have to look how TI does monitor detection
<ogra_> ah, k, i only saw your name on the upload
<ogra_> ppisati, well, lets just wait for their next dump, ndec said that would be soon 
<ogra_> for A1 that kernel is good enough with a release note
<ppisati> ogra_: alpha2 is in 3 weeks
<ogra_> yeah yeah, even for A2 its ok i would say, as long as it boots at all and we can offer a workaround
<ogra_> but i would expect the new code dump from TI to be available within that timeframe anyway ... at least ndec sounded like that
<ppisati> aren't the penguins CONFIG_LOGO_*?
<ogra_> yeah, i think so
<ppisati> if yes, we had that options on since the beginning of P
<ppisati> why do we notice it just now?
<ogra_> cant be, i am 100% sure i havent seen them there
<ppisati> it was turned on in b1ac4ec9cc3eb5e67546824c10baf00587bda8de 
<ppisati> Fri Nov 18 12:27:53 2011
<ppisati> and that's something we inherithed from O/omap4
<ppisati> so it's probably something even older
<ogra_> well, i have never seen logos until i upgraded my panda this morning
<ogra_> even the released kernel didnt show them
<ppisati> it predates P, so we have it on since O
<ogra_> (i did a dist-upgrade from proposed of my precise install this morning before i started testig)
<ogra_> why dont they show then ?
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 12th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<ppisati> /proc/cmdline?
<ogra_> i'm 100% positive they werent there before todays upgrade
<ogra_> ah, could it be that they are hidden when quiet is set ?
<ppisati> ogra_: i don't use quiet or splash cause i want to see kernel msgs when it boots
<ppisati> ogra_: and i've never seen them
<ogra_> quantal only has "ro", precise had "ro quiet splash root="
<ppisati> i'm always running without "quiet splash"
<ogra_> right, but the server install i have upgraded today also has them pff 
<ogra_> *off
<ogra_> so i should have seen it before 
<ogra_> and i definitely havent 
<ogra_> (i would have complained loudly, i hate them ... )
<ppisati> 3.2.0-1414-omap4, right?
<ogra_> yep
<ogra_> and before whatever was current at release time
<ppisati> booting and i've no penguins here
<ppisati> what's your cmdline?
<ogra_> how weird is that !
<ogra_> ro 
<ogra_> nothing else
<ogra_> and the updated precise "ro root="
<ppisati> mine is a precise install
<ogra_> mine too
<ogra_> well, the upgraded one
<ppisati> still booting, wait...
<ppisati> ogra_: my cmdline is
<ppisati> ogra_: ro rootwait elevator=noop vram=32M root=UUID=2a29c98b-32b9-45e7-a484-e1aa17b754ef fixrtc console=ttyO2,115200n8 earlyprintk=ttyO2,115200n8 debug
<ppisati> ogra_: your is "ro root=UUID=..", right?
<ogra_> right
<ppisati> let me try with that
<ogra_> probably the earlyprintk supresses them 
<ogra_> or the debug
<ppisati> don't think so, earlyprintk let the kernel use printk when serial is not configured yet, doesn't do anything on the video
<ppisati> let's see
<ogra_> ah, i thought it prints to the default console as soon as thats available
<ppisati> nope
<ogra_> weird
<ppisati> it substitutes printk in the early boot phase with hardcoded instruction for the serial to print stuff out
<ogra_> ah, k
<ogra_> you dont have console= set now, right ?
<ppisati> yes i have
<ppisati> ro rootwait elevator=noop vram=32M root=UUID=2a29c98b-32b9-45e7-a484-e1aa17b754ef fixrtc console=ttyO2,115200n8 earlyprintk=ttyO2,115200n8 debug
<ogra_> i thought You tried with my cmdline 
<ppisati> not yet
<ppisati> is updating some packages
<ogra_> ah, k
<ppisati> flag@panda:~$ cat /proc/cmdline 
<ppisati> ro root=UUID=2a29c98b-32b9-45e7-a484-e1aa17b754ef
<ppisati> flag@panda:~$ uname -a
<ppisati> Linux panda 3.4.0-201-omap4 #6 SMP PREEMPT Tue Jun 5 16:24:21 UTC 2012 armv7l armv7l armv7l GNU/Linux
<ppisati> i see booting messages on my lcd screen, but no penguins
<ppisati> ogra_: ^^
<ogra_> weird
<ogra_> oh, wait 3.4.0-201-omap4
<ogra_> i thought you used 3.2.0-1414
<ppisati> so it's a Q issue
<ppisati> wait
<ogra_> i cant tell if they are there on 3.4 since my monitor wont work if i have it plugged in at that point of the boot :)
<ppisati> so your lcd *never* works with 3.4?
<ogra_> it does if i plug it in a minute after boot 
<ppisati> weird
<ogra_> i.e. once omapdss has initialized its fallback mode
<ppisati> anyway, no penguis even on 3.4
<ppisati> i'm using the 1080p hdmi plug
<ogra_> me too 
<ogra_> though attched to DVI on the monitor side (i only use plain hdmi for testing, my GF gets angry if i steal the TV cable for to long ;) )
<ppisati> same here
<ogra_> well, all i can say is that they started showing up with 3.2.0-1414 ... cant say anything about 3.4 
<ppisati> you dist-upgraded to Q, right?
<ogra_> no
<ppisati> then we are in the same situation...
<ogra_> i dist-upgraded precise with -proposed enabled 
<ppisati> i don't hjave proposed
<ogra_> well, thats where -1414 lives atm
<ppisati> manually installed it
<ogra_> shuldnt make a difference for penguins though :) 
<infinity> ogra_: What's this about penguins?  I've always had them on my Panda...
<ogra_> infinity, really ?!?
<infinity> AFAIK.
<ogra_> they arent supposed to be there and i'm sure i didnt have them until i upgraded today
<infinity> They might not show on desktop images, but they do on server ones.
<infinity> Which is the same kernel.
<infinity> Just console=elsewhere.
<infinity> So, they're not "disabled".
<ogra_> well, i upgarded a server image today 
<ogra_> (my build setup) 
<ogra_> and i didnt have them before 
<ogra_> in any case... no ubuntu kernel has them on, and we should disable them 
<ogra_> regardless of the past :)
<Daviey> does someone want to answer, http://askubuntu.com/questions/122493/why-is-12-04-removing-the-server-kernel-flavour please :)
<Daviey> added bounty for those that give a damn about that :)
 * ogra_ gives a damn, do i wint the bounty now ?
<ogra_> *win
<Daviey> ogra_: if you answer wins!
<Daviey> you know what points mean?
<Daviey> prizes !!
<ogra_> ah, i thought the bounty was just for giving a damn about it 
 * ogra_ doesnt have an askubuntu account ... i'm a mailing list type of guy 
<Daviey> ogra_: askubuntu points are like enriched LP karma.
<ogra_> lol ... LP karma .... LOL ... 
<Daviey> hence the give a damn ;)
 * ppisati -> off
<orated1> Are these packages correct to try lxde - apt-get install lxdm lxde lxlauncher lubuntu-desktop - ?
<\sh> moins
<\sh> I was wondering if it's somehow possible for the HP smartarray kernel drivers in 3.x to fallback to old 2.6 behaviour having old /dev/cciss/ namespace?
<infinity> \sh: You could write a udev rule to symlink the old namespace to the new?
<\sh> infinity: that's possible, but not nice...I thought there is something like a legacy switch for the kernel commandline
#ubuntu-kernel 2012-06-06
<smb> morning
<dileks> morning has broken, lalala
<dileks> ahh, cat stevens
<smb> Usually that is: Morning, I'm broken... :-P
<dileks> I thought its mostly the software :-)
<Nafallo> good morning :-)
<smb> Nafallo, A visitor from the past or so... ;)
<Nafallo> I never left the channels man :-)
<Nafallo> but.. now I need to go to work ;-)
<Nafallo> ttyl
<smb> see you
<smb> Nafallo, (and yeah but you know how invisible quiet people are) ;)
 * apw yawns
<ppisati> moin
<Nafallo> lol
<tjaalton> when is the precise-proposed kernel released to -updates?
<tjaalton> it has some drm/i915 fixes I'd like to get in
<smb> tjaalton, Seems it might wait on cert
<smb> So maybe next week?
<tjaalton> smb: ok, thanks
<henrix> yeah, it should be there next week 
<henrix> tjaalton: but you can test it before that :)
<tjaalton> henrix: I've asked people to do that, bug 966631 and several dupe candidates :)
<ubot2`> Launchpad bug 966631 in xserver-xorg-video-intel "[sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003 with Google Maps(WebGL) in Chromium" [Critical,Fix released] https://launchpad.net/bugs/966631
<tjaalton> there are a couple of other commits too that have been verified elsewhere
<tjaalton> fixing similar bugs
<tjaalton> those can wait for the next iteration i guess
<henrix> cool
<tjaalton> btw, now that the wacom bamboo updates have been accepted adding intuos5 support is trivial (four commits). would that be accepted by the same criteria as the bamboo ones?
<henrix> if these commits are in mainline, you may send them to the kernel-team ML.
<tjaalton> yeah they got included in 3.5-rc1, missed the 3.4 queue because of a missing S-o-B :)
<henrix> smb: any idea who's maintaining virtualbox?
<smb> henrix, community (or virtualbox company)? What does changelog say?
<henrix> smb: will check...
<henrix> smb: yeah, it looks like its community supported
<henrix> smb: there's a bug on it that's triggered by P in -proposed
<smb> henrix, The dkms mod failing to compile due to some change?
<henrix> smb: no, actually it prevents a shutdown: "unregister_netdevice: waiting for vboxnet0 to become free. Usage count = -1"
<henrix> smb: it has been pointed out on the release tracking bug for the precise kernel
<henrix> smb: not sure if this actually counts as a regression...
<henrix> smb: bug #1009156 if you're curious :)
<ubot2`> Launchpad bug 1009156 in linux "linux-3.2.0-25.40: unregister netdevice change breaks VirtualBox" [Medium,Incomplete] https://launchpad.net/bugs/1009156
<smb> henrix, IMO I would retarget it to the virtualbox source package which likely produces the dkms which in turn creates the vboxnet module
<henrix> smb: yeah, it's open against VB
<henrix> smb: but the bug reporter commented on the tracking bug, that's how i found that bug
<smb> Ah, ok. Is it obvious what change may have changed the netdev usage?
<smb> The question is whether vbox relies on some broken assumption or whether the kernel changes something without knowing all implications.
<henrix> yeah, there's a upstreams bug report and there's a patch for that already.
<henrix> so, its just a matter of the maintainer picking this patch
<smb> Ah ok... 
<henrix> basically, its a change in one of the core network apis... which is always a pain for OOT modules :)
<smb> henrix, So the history looks like it (vbox) usually is just a syc from Debian
<henrix> smb: how can you tell that? by the "unstable" in each entry?
<smb> from the version number not having a ubuntux
<henrix> ok :)
<smb> But also looking at https://launchpad.net/ubuntu/+source/virtualbox/+publishinghistory
<smb> Which usually has copied from debian x
<henrix> ok, i'll check if this is fixed on debian
<dileks> smb: are you still maintaining drm-backports to linux-2.6.32?
<smb> dileks, Yes
<dileks> good guy - you are
<smb> henrix, In the history with the last upload to precise there is an uploader email address which you may contact
<smb> dileks, Thanks. :)
<dileks> smb: BTW, whats your position to kernel-drm vs. libdrm? note: some Xorg and kernel devs wanted it to be at one place
<dileks> oh happy world IPv6 day :-)
<dileks> http://www.worldipv6launch.org/
<smb> dileks, I do not really have a position there. Note that I maintain the tree (only). Which means adding patches that are asked to be added if the match stable change rules. I am as opinionated as any librarian: which is for the 2.6.32 tree not changing too much. ;)
<dileks> best strategy for me in early kms days was - take all from GIT :-) linux-kernel, libdrm, mesa3d and xserver
<apw> dileks, happy World IPv6 Launch Day indeed
<dileks> hmm, German "Deutsche Telekom" seems to have IPv6
<dileks> https://labs.ripe.net/Members/emileaben/growth-in-ipv6-capable-dns-infrastructure
 * ppisati -> out for lunch
<xnox> is there anything I can do, to help with bug 966248
<ubot2`> Launchpad bug 966248 in linux "USB3.0 Ports Not Working" [Medium,Confirmed] https://launchpad.net/bugs/966248
<xnox> It affects me and Daviey =)
<apw> cooloney, are you really looking at the above bug ? ^^
<apw> xnox, i assume you have a precise kernel on there, and that this is new behaviour, can you work out which kernel it did work on before
<xnox> apw: I have quantal kernel
<apw> xnox, it seems the issue appeared in an update in precise, so if you can test 3.2.0-20.32 and config it is also broken, and then step backwards on the 3.2.0 kernels till it comes back that would help a lot
<apw> s/config/confirm
<xnox> apw: ok. so do a 'bisect' =) easy way to download all the kernels?
<apw> they are all linked from the version page for the kernels, but easy probabally not
<xnox> ok
<apw> https://launchpad.net/ubuntu/+source/linux
<apw> links at the top right to the publishing history
 * henrix reboots
<[yates]> Hi all, is someone able to look at my acpitables.txt concerning bug #996782 ?
<ubot2`> Launchpad bug 996782 in linux "ACPI Errors" [Medium,Confirmed] https://launchpad.net/bugs/996782
<jwi> apw: is bug 974830 still on your radar?
<ubot2`> Launchpad bug 974830 in xserver-xorg-video-intel "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x78170003 using Oracle SQL Developer" [High,Fix released] https://launchpad.net/bugs/974830
<apw> jwi, nope lost track of that one completely.  will get the patch rebased and out for review
<ppisati> is there a way to tell dpkg-buildpackage to skipabi?
<ogra_> yes, its documented in the kernel build wiki :P
<ogra_> some env var
<ppisati> all the references i found used fakeroot not dpkg-...
<ogra_> the vars should be the same though as they should apply to the in-package scripts
<cooloney> apw and xnox, yeah, I'm working that USB 3.0 regressions issue
<xnox> cooloney: ok cool. thanks =)
<cooloney> xnox: sure, i guess you have usb 3.0 hardware, right? as apw pointed out, could you please try the kernel on your hardware
<cooloney> xnox: and let us know which one works and which one doesn't
<xnox> cooloney: kernel(s). ok.
<cooloney> xnox: i really appreciate you can provide such information for us bisect. and please update that in the launchpad page
<xnox> cooloney: apw: the publishing history, timesout to render on lp.net due to trying to linkify all 2000 bugs. Is there any other way I can easily get version numbers directly?
<xnox> linux-meta timesout as well...
<cooloney> xnox: what's kind of version number you want to get?
<xnox> cooloney: as per apw: 3.2.0-20.32 and going backwards. Does that mean integer decrements down to 20.1?
<xnox> cooloney: stuff that ever got published in precise-*
<cooloney> xnox: oh, lp is down, sh*t
<apw> xnox, the last number is an upload number so it decrements, but there are not 32 -20 versions
<xnox> cooloney: not down, it fails to render linux package publishing history =)
<apw> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html
<xnox> If I grab the precise-proposed linux-meta, will the changelog show the version numbers?
<apw> xnox, that above has the numbers which were valid
<xnox> yeah! =)
<xnox> apw: so I should work down the first table from 3.2.0-20.32?
<apw> well assuming that that version fails yes ... 
<cooloney> xnox: so you can try 3.2.0-19.31, if it fails, then continue
<cooloney> until you find a kernel works on your hardware with USB 3.0
<xnox> apw: cooloney: do we have a known version that did work with 3.0 usb hardware? maybe my laptop's usb3.0 didn't work, ever =)
<xnox> then my bisect will be pointless
 * xnox just got 3.0usb hardware in the mail
<cooloney> xnox: actually I'm not sure about this, how about try the first 3.2.0 ubuntu kernel firstly, we can shrink the range then
<cooloney> xnox: 3.2.0-8.14 is the first 3.2.0 kernel in Ubuntu
<xnox> ok
<xnox> cooloney: minimal amount of packages that I need to install?
<cooloney> xnox: simply just install linux-image- package is good enough to test
<xnox> I'm going with generic image and generic headers
<xnox> oh ok.
<xnox> Thankfully that is a stable-ish url https://launchpad.net/ubuntu/precise/amd64/linux-image-3.2.0-8-generic/3.2.0-8.14
<cooloney> xnox: that's great, just let us know the result.
 * xnox reboot
<cooloney> in the bug 966248, kernel from 11.10 should works 
<ubot2`> Launchpad bug 966248 in linux "USB3.0 Ports Not Working" [Medium,Confirmed] https://launchpad.net/bugs/966248
<cooloney> so maybe you can try that kernel if 3.2.0-8.14 doesn't 
<cooloney> work
<cooloney> xnox: did it work?
<xnox> cooloney: so 3.2.0-8.14 works. I am in a meeting now. will do reboots after the meeting.
 * ogasawara back in 20
<cooloney> xnox: great, thanks a lot. i have to go to sleep. please help to update LP 
<apw> bjf, just a heads up i am doing the P highbank config review, so it'd be nice to not have any change in configs
<bjf> apw, ack
 * ppisati -> gym
<tjaalton> is it possible to squeeze individual fixes in the precise-proposed kernel before it hits -updates next week?
<henrix> tjaalton: usually these are queued into master-next branch, unless they are critical/security fixes i guess...
<henrix> bjf: ^
<tjaalton> for instance 80e829fade4e for bug 974830 has been confirmed quite some time ago
<ubot2`> Launchpad bug 974830 in xserver-xorg-video-intel "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x78170003 using Oracle SQL Developer" [High,Fix released] https://launchpad.net/bugs/974830
<henrix> tjaalton: at the moment we have 2 days left for adding these fixes and going through packaging, testing, certification, etc again...
<henrix> tjaalton: these fixes could be queued for next cycle and in 3 weeks they would be out in -updates
<tjaalton> henrix: hmm ok, maybe that wouldn't be too far then
<henrix> tjaalton: anyway, you may try to convince bjf that these fixes *really* need to go in this cycle :)
<tjaalton> debian might go for drm from 3.4 :)
<tjaalton> but that ship has sailed
<tjaalton> henrix: ok, well maybe having some more time wouldn't hurt here
<bjf> tjaalton: no, and you are close to missing the window for the next cycle
<tjaalton> bjf: ok, when does it close?
<bjf> tjaalton: we will start preping the next series of kernels next week
<tjaalton> ok, there is now that one commit that has been verified being good, and two others that upstream says are good but not verified by the reporters yet
<tjaalton> what is the procedure to get them in the next batch?
<tjaalton> cherry-pick email on the list+
<tjaalton> ?
<bjf> tjaalton: there is a SRU format for patch requests ... https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
<tjaalton> ok, probably going via the stable queue/release would take too long?
<tjaalton> i mean 3.2-stable
<bjf> tjaalton: you should make the effort to request inclusion of the patches by upstream stable
<tjaalton> yeah I'll do that regardless
<bjf> tjaalton, also: https://wiki.ubuntu.com/KernelTeam/KernelUpdates
<tjaalton> bjf: yeah, I realized my intuos5 cherry-pick email cut corners in various ways ;)
<bjf> tjaalton, if we know ahead of time that you have something that you are trying to get into the next cadence cycle, we can delay the prep to the end of the week
<tjaalton> yeah, I'll rebase my branch on top of -next and see how it works
<jsalisbury> sforshee, Do you happen to have the type of hardware mentioned in bug 1006427
<ubot2`> Launchpad bug 1006427 in linux "(PowerBookG4) Live image won't boot, stuck on "stdin: Not a typewriter"" [High,Confirmed] https://launchpad.net/bugs/1006427
<ogra_> haha, entertaining error message though
<sforshee> jsalisbury, no, all the mac kit I have uses intel
<jsalisbury> sforshee, ahh, ok.  thanks
<BenC> What kernel are you guys pushing for in quantal?
<ogasawara> BenC: at least the 3.5 kernel, maybe 3.6 if the timing is right
<ogra_> 3.5 at least ...probably 3.6 if its there in time
<ogra_> snap :)
<BenC> Nicely done :)
<ogasawara> heh
<BenC> Who handles the ports side of things?
<BenC> IOW, powerpc
<BenC> I want to get a new flavour and it's relevant patches added to the build for quantal
<BenC> *its
<ogasawara> BenC: it's technically in our tree but supposed to be community maintained/supported
<BenC> Right, I want to be that community :)
<BenC> Didn't know if there was a goto person for the powerpc kernel stuff
<BenC> If not, then I'll be that person
<ogasawara> BenC: no go to person that I'm aware of atm.
<jussi> benc please! power PC has been missing leadership in an area for ages (IMHO)
<BenC> Luckily, I won't be doing this as a community personâ¦it's part of my job to get this stuff integrated, so I'll be able to devote a good bit of time toward it
<jussi> BenC excellent :-)  
 * henrix will be back in ~30min
 * bjf -> dentist
<bjf> ogasawara: around ?
<jkyle> If I want the most recent, stable kernel would this be the recommended way, or just rolling my own? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/
<bjf> jkyle: ht emost recent, stable kernel is in Precise
<bjf> jkyle: if you are looking for the most recent, stable upstream kernel, then yes, that probably is a good one
<jwi> 3.4.1 would be an even better one
<dileks> looks like the one for quantal is built on a precise host
<dileks> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4.1-quantal/BUILT
<bjf> in <version>-<series> i believe the <series> indicates the ubuntu series the configuration was taken from
<bjf> so v3.4-precise used the precise config, v3.4.1-quantal used the quantal config
<dileks> OK
<dileks> make: *** No rule to make target `build-generic-pae'.  Stop.
<dileks> make: *** No rule to make target `binary-generic-pae'.  Stop.
<dileks> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4.1-quantal/BUILD.LOG
<dileks> wasnt -pae flavour dropped for Q?
<bjf> dileks, i believe so because we don't support non-pae any more
<dileks> might be a relict in the build-script
<bjf> could be
<dileks> apw: ^^
<bjf> 3c06c9edb79d2c887d26b3977c183a2392700209 UBUNTU: [Config] Collapsed generic-pae into generic [i386]
<bjf> dileks, ^
<dileks> normally an UP machine can use a kernel with PAE support enabled, but I think the upgrade hook-script will not allow an installation
<jkyle> jwi: yeah, 3.4.1 would need to be hand rolled though eh?
<jwi> jkyle: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4.1-quantal/
<jwi> (better install that -extra package as well though :o))
#ubuntu-kernel 2012-06-07
<ogasawara> bjf: am here now, lemme know if you needed something
<bjf> ogasawara: nah, thanks, vanhoof and hugh took care of it
<cooloney> ogasawara: still around, for the bug 1084000
<cooloney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084000
<ubot2> cooloney: Error: <Bugtracker.plugin.Launchpad instance at 0xa91202c> bug 1084000 not found
<cooloney> i believe we can point out to ubuntu server image builder and add a small post-install script to add 'elevator=deadline' to default grub kernel command line
<cooloney> xnox: hey, are you still around?
<BenC> ogasawara: When do you think the quantal tree with by tracking 3.5?
<BenC> *will be tracking
<ogasawara> BenC: I wanted to get it rebased today but got sidetracked, so hopefully tomorrow.
<BenC> ogasawara: sweet, my work pre-depends on that, so if you could just ping me when it's done, I'd greatly appreciate it
<ogasawara> BenC: will do
<BenC> ogasawara: I have my tree on github ready and cloned from ubuntu-quantal
<ogasawara> BenC: you're quick, I haven't heard back about the zinc access yet.
<BenC> ogasawara: It's kind of moot at this point, but I guess for future reference it will give you a litmus test of how likely someone else is to get access :)
<ogasawara> BenC: it's definitely not the first time it's come up, so will indeed be good to know what the actual policy is
<ogasawara> cooloney: while I agree that having that bug reporter use elevator=deadline is a valid workaround in that bug scenario, I don't think it's a convincing enough argument to default *all* server image installs to it.  the fact that the CFQ scheduler is resulting in disk errors and hangs seems like a legitimate issue that needs to be addressed.  Additionally it won't be obvious for anyone examining our kernel config that in so
<ogasawara> me cases the schedule will be set to elevator=deadline.   do you know if we've been able to reproduce?  The bug report doesn't have any logs files of the actual errors to confirm the issue.
<cooloney> ogasawara: i can't reproduce it on my side, I just confirm CFQ is our default IO scheduler for server image now.
<cooloney> ogasawara: and i don't think we need any change in our kernel side,since we have good reason to keep it as the same as desktop kernel 
<cooloney> so might need talk with server folks about this issue, or add elevator=deadline in server image after fully installation
<ogasawara> cooloney: yah, probably best to raise with the server team for feedback.  maybe try and get some benchmarks ran.  I thought we'd done some in the past but can't seem to find the results.
<cooloney> ogasawara: no problem, i will handle that and might discuss this with smb firstly. 
<ogasawara> cooloney: sounds good
<xnox> cooloney: well I am now.
<cooloney> xnox: cool, i saw your update about that usb 3.0 bug
<cooloney> looks like some works some not
<cooloney> quite weird
<xnox> cooloney: well all that tested got a 'P' - pass. Others were not tested. So no fails.
<xnox> it did take between 47-83s to spin up the drive and make it appear
<xnox> the external drive has it's own power, so I'm not sure why it was taking so long.
<taruti> Is it a known problem that installing the 3.5rc quantal kernel on precise makes an usb keyboard nonworking? and are there any workarounds?
<cooloney> xnox: i will take a look at the kernel change based on your testing result
<xnox> cooloney: they are inconclusive. I have tested 4 kernels and all 4 of them passed
<xnox> both the reported kernel by the user, kernels before & after it. As well as the current 3.4 kernel. And all works.
<xnox> APART from that it takes ages for the device to appear (upto a full minute sometimes)
<cooloney> xnox: did you met this issue on some old ubuntu release before? like 11.10
<cooloney> i mean the issue about long enumeration of USB 3.0 devices
<xnox> cooloney: I got this laptop with USB 3.0 port this christmas and it has been running precise until precise release, and quantal since then. My first USB 3.0 device arrived yesterday.
<xnox> Previously I thought that my 3.0 usb port was 'backwards-incompatible' as I would get frustrated and plut the stuff into 2.0 port, as that one 'was not working', well it actually was just enumerating slower.
 * xnox it's not very scientific, and I'm not sure how to numerically test this.
<cooloney> based on you testing, "P 3.2.0-23.363.2.14" means your devices can be enumerated and works fine, right? only it will take about 1 min to see the device appear
<cooloney> xnox: if so, i'm going to check the change between 3.2.0-23.36 to 3.2.0-24.37
<xnox> cooloney: well, all of them were slow. But I was not using, e.g. a stopwatch, nor multiple tests to see if there is a consistent trend/correlation. E.g. there was still a lot of cpu activity while desktop was loading and I would plug my device in.
<xnox> cooloney: i am dogpiling on the bug report now. I think it is best to wait for the original reporter to come back and find out if it's "working slowly" or "not working at all"
<xnox> hence the status incomplete.
<cooloney> xnox: thanks a lot. i got you
<cooloney> cking: morning, how's the celebration for Queen
<cking> cooloney, morning;  the celebrations were a load of fun
<dileks_> "For the fist time in my memory, today's linux-next build required no manual intervention i.e. there are no new conflicts or build problems."
<dileks_> linux-next: Tree for Jun 7
<gema> ppisati: I have A1 desktop image not booting on panda
<gema> ppisati: it's stuck on the Uboot , keeps rebooting
<gema> ppisati: how do I enable the debug info?
<gema> ppisati: I'd like to give some more info than just "it doesn't boot" on the bug report
<ppisati> gema: which board rev?
<ppisati> ogra_: didn't you try A1 installation on panda?
<gema> ppisati: A4
<ppisati> gema: i've a panda a4
<ppisati> gema: where di you get the img?
<gema> ppisati: from the tracker
<gema> ppisati: http://iso.qa.ubuntu.com/qatracker/milestones/221/builds/16974/downloads
<ppisati> gema: ok, i'm downloading it
<ppisati> gema: i'll let you know
<gema> ppisati: thanks
<gema> ppisati: can I enable serial console on the early boot ?
<gema> ppisati: so that I can see something else
<ppisati> gema: on the installation image? uhm
<gema> yep
<ppisati> gema: yes, but you'll have to tinker with uboot
<ppisati> gema: or reroll boot.scr
<gema> I'd like to see the crash
<gema> ppisati: ack, will try
<ppisati> gema: what's the content of boot.scr on the first partition of the sd card?
<gema> ppisati:  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)
<ppisati> gema: so you installed the img somewhere
<ppisati> gema: and it's unablt to mount what root= says
<gema> I dd'ed the image to an mmc and then tried to boot the load
<ppisati> gema: did you have any video output?
<gema> ppisati: no
<ppisati> gema: did you modify boot.scr? or did you manually override u-boot vars?
<ppisati> gema: anyway, just finished downloading the img, let me try by myself
<gema> ppisati: I unset the bootscr var
<gema> ppisati: I will raise a bug, now I have something to put on it :D
<ppisati> gema: can you past the boot messages somewhere? (http://paste.ubuntu.com/)?
<gema> yep
<gema> ppisati: http://paste.ubuntu.com/1028413/
<gema> ppisati: the /dev/mmcblk0p2 in the card is not ext3
<gema> ppisati: that is probably why the board cannot load it
<gema> ppisati: so maybe the image is wrong or .. ?
<ppisati> i'm dding it now
<ppisati> wait
<gema> ok
<ppisati> ogra_ tested the installation img yesterday (or two days ago) and he said it was ok
<ppisati> is this img different in any way?
<gema> ppisati: this image is from yesterday
<gema> ppisati: and it is an A1, so I am retesting
<gema> no result for it on the iso tracker
<gema> ppisati: breaking for lunch now, back in a bit
<ppisati> still dd-ing..
<gema> ppisati: back
<ppisati> gema: ok so
<ppisati> gema: i just tried your img on my panda rev a.4 here
<ppisati> gema: and it's booting
<ppisati> gema: how did you dd the img? 
<gema> ppisati: the image itself is broken
<ppisati> gema: but did you rech the installation? you installed and then it paniced or what?
<gema> ppisati: let me verify I downloaded it correctly
<gema> ppisati: it never booted the installer
<ppisati> gema: works here
<ppisati> choosing the timezone now
<gema> ppisati: ack , I will have to figure out what's wrong with my setup 
<gema> ppisati: thanks :D
<ppisati> gema: zcat $imgfile | sudo dd of=/dev/sdX bs=64k
<ppisati> gema: try this
<ppisati> gema: sd cards are picky if you don't specify dd bs=
<gema> ppisati: I used bs=1M
<ppisati> finished netering my user details, it's installing now
<ppisati> *entering
<gema> ppisati: the second partition, in my image, is ext4 yet the bootargs in uboot tell the kernel it's ext3
<gema> ppisati: any idea how could I do that to an image?
<gema> ppisati: also, what is the correct type for mmcrootfstype? ext3 or ext4?
<ppisati> gema: did you modify boot.scr?
<ppisati> gema: because i don't have that info in mine
<ppisati> gema: setenv bootargs vram=40M mem=456M@0x80000000 mem=512M@0xA0000000   root=/dev/mmcblk0p2 fixrtc quiet splash
<ppisati> gema: that's what you img says
<gema> ppisati: http://paste.ubuntu.com/1028461/
<gema> ppisati: I never get to the installer, those are the env vars for uboot
<ppisati> gema: wait
<ppisati> gema: i've that too, but it shouldn't use that info
<gema> ppisati: then why is it failing there for me?
<ppisati> gema: did you dd it again with bs=64k?
<gema> ppisati: not yet
<ppisati> gema: try it
<ppisati> and the loader prompt, execute 'printenv' and paste it somewhere so i can compare it
<ppisati> *at
<gema> ppisati: changing the mmcrootfstype to ext4 makes it boot (I tried before rewriting the card)
<ppisati> gema: so you've a different boot environment
<ppisati> where does your board come from?
<gema> ppisati: http://paste.ubuntu.com/1028479/ <- the only thing removed is bootscr
<gema> my board came from pgraner, on the same batch as yours, I believe
<gema> ppisati: are we happy for me to try with bs=64K ?
<ppisati> no
<gema> Iok
<gema> ok
<ppisati> don't do that
<gema> ok
<gema> I only have a working SD
<ppisati> why you removed bootscr?
<ppisati> that's the bootscript present on the sd
<gema> ppisati: to be able to see dmesg
<gema> serial output
<ppisati> ok, but then you are using the env of you board that is wrong
<ppisati> if you want serial output
<ppisati> you need to change the file boot.scr on the first partition of the sd
<ppisati> taking out 'quiet splash'
<ppisati> and adding console=ttyO2,115200
<ppisati> boot.scr is created with mknewimage
<ppisati> wait
<gema> ppisati: ok
<gema> ppisati: I am going to document that in our wiki
<ppisati> gema: mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Ubuntu 10.10" -d ./boot.cmd ./boot.scr
<ppisati> gema: and boot.cmd is plain text file containing onle the text part of the boot.scr you find on the sd card/first partition
<ppisati> gema: so, open a text editor, cut&paste from boot.scr ONLY the text part
<ppisati> gema: delete 'quiet splash'
<ppisati> gema: add "console=yyO2,115200"
<ppisati> gema: write the file, close the editor
<ppisati> gema: execute
<ppisati> gema: mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "my Ubuntu boot.scr" -d ./$TEXTFILE ./boot.scr 
<ppisati> gema: copy the resuling boot.scr to the sd card/first partition
<ppisati> gema: of course, do a backup oif the boot.scr found there
<ppisati> gema: just in case
<gema> ppisati: ack
<ppisati> gema: try by yourself, so we can double check it
 * ppisati is hungry
<gema> ppisati: ack, go for lunch, it is going to take me a while... where do I do the mkimage?
<gema> ppisati: ok, on it, follow your instructions helps x)
<ogasawara> ppisati: care to send a quick pull request for your omap4 config sync?
<gema> ppisati, all is good, trying to write the boot.scr to my card it started to behave weirdly
<gema> ppisati: camera to the rescue, all it good I can boot the image and install it
<gema> ppisati: thanks !
<ppisati> ogasawara: i'll do
<ppisati> ogasawara: i did some more config sync, let me test that and then i'll pull req
<ogasawara> ppisati: ack
<diwic> hi, kentb would need ALSA 1.0.25 linux-backports-modules on top of oneiric, any chance we can provide that to him?
<ogra_> ppisati, fyi, omap3 fails with an USB oops and i dont get any display output once the kernel started (i get the yellow u-boot screen though)
<ogra_> (note also that i'm on vacation, just doing some quick image tests)
<ogra_> bug 1010024
<ubot2> Launchpad bug 1010024 in linux "omap fails to boot with oops in qantal alpha1 " [High,New] https://launchpad.net/bugs/1010024
<ppisati> ogra_: i know video is broken on omap3
<ppisati> ogra_: let me try the daily img for it
<ogra_> well, apparently USB too :) 
<ogra_> at least that oops comes up right after USB is initialized it seems
<ppisati> uhm
<ppisati> let's see
 * cking gives his network a poke
 * ogasawara back in 20
<davmor2> network bites cking for poking it
<cking> yep, it's a yappy little fella
<ppisati> ogra_: actually boots here, it reaches the installer
<ppisati> ogra_: but since video is broken, can't go ahead
<ppisati> ogra_: server images shoudl be fine (if we ever build it for omap3)
<ppisati> actually the installer dies cause X can't open a screem
<ppisati> and then drop you in # shell
<jsalisbury> ppisati, did you happen to see this one: bug 1010024
<ubot2> Launchpad bug 1010024 in linux "omap fails to boot with oops in qantal alpha1 " [High,Incomplete] https://launchpad.net/bugs/1010024
<ppisati> jsalisbury: kind of saw it, it actually boots here (i was talking about it with ogra above)
<jsalisbury> ppisati, cool thanks.  Just wanted to give you a heads up.
<ppisati> jsalisbury: but yes, video is broken on omap3, so omap3 desktop image for A1 are dead
<ogra_> ppisati, i'll do a bit research tomorrow when i'm not in vacation mode 
<ppisati> ogra_: don't worry, A1 is done
<ppisati> ogra_: A1 is the target now
<ogra_> not worrying about A1 but about the images in general :)
<ogra_> A1 is done indeed, we'll only release omap4
<ogra_> omap3 in the past didnt init the graphics when you didnt have the right boot options, thats what i planned to play with ... and i didnt do more than one test, might be that the oops doesnt show on every boot 
<ppisati> ack
<ppisati> go have a Weizenbier for me
 * ogra_ will do :) 
<henrix> jsalisbury: ping
<jsalisbury> henrix, pong
<henrix> jsalisbury: hi! i was trying to add the series (precise and quantal) to bug #1010022
<ubot2> Launchpad bug 1010022 in linux "Ext3 filesystems converted to ext4 can get erroneously reported as containing errors" [Medium,Triaged] https://launchpad.net/bugs/1010022
<henrix> jsalisbury: any idea how to do that?
<ogasawara> infinity, apw: bah, so as I'm checking the linux-firmware 1.81 build that I've just uploaded to quantal-proposed I see I managed to typo the bug # in the debian/changelog (the git tree is correct).  what's the preferred way to resolve?  upload a new 1.82 version which only corrects the changelog and then make sure we just copy the 1.82 version to the release pocket?
<henrix> jsalisbury: i guess i've done that before, but can't remember how :-/
<jsalisbury> henrix, I see your nominations.  I can approve them.  I think I can approve them because I'm in the release team, which you may be able to subscribe to
<infinity> ogasawara: Nah, just fix it in git retroactively, and it'll be right on the next upload.
<infinity> ogasawara: And go close the bug by hand.
<ogasawara> infinity: ok cool
<jsalisbury> henrix, I clicked approve, can you check on your end to see if it worked?
<henrix> jsalisbury: oh, so i need approval for that! that means i've never done that before :)
<henrix> jsalisbury: will check
<apw> ogasawara, yeah what infinity said.  once that version is in -proposed its used up anyhow
<infinity> ogasawara: (If it were a stable release, I'd punt it from proposed and make you try harder, but this isn't really the devel workflow)
<henrix> jsalisbury: yeah, thats it. thanks :)
<jsalisbury> henrix, np
<infinity> Oh cute, my ~ was never removed from zinc, I just lots access when I was gone.
<infinity> Not that there was anything in it other than dotfiles...
<Daviey> ogasawara: Am i right in saying a new snapsnot of linux-firmware will resolve.. [   21.388655] microcode: failed to load file amd-ucode/microcode_amd.bin
<Daviey> ie, should i not bother raising a bug or investigating 
<BenC> ogasawara: how goes the rebase?
<htorque> RAOF: hi! do you know if there's any progress on making DP output work under nouveau with NVD9 based GPUs (e.g., the 4200M in the T*20 thinkpads)?
<RAOF> htorque: As far as I'm aware, that should be fixed somewhere in the nouveau git pipeline. My T420s died before I could test out darktama's patch, though. I'd guess it should work in 3.5, if it doesn't already work in 3.4.
<htorque> RAOF: thanks for the info, i'll give 3.4 a go then.
#ubuntu-kernel 2012-06-08
<htorque> RAOF: so, with the 3.4 kernel the screen gets detected on the DP port (according to xrandr and the display settings), but i get no signal. do i need any userspace updates too?
<RAOF> htorque: Not as far as I'm aware.
<RAOF> There'll be shiny new userspace in Quantal soon, but I'm not aware of any specific fixes for that.
<htorque> RAOF: bummer. thanks, anyway!
 * apw yawns
<dileks> htorque: what gfxcard?
<htorque> dileks: nvidia nvs 4200m
<htorque> dileks: (gf119/nvd9)
 * dileks was looking into stable-queue-3.4 patchset this morning, but nothing for nvidia
<dileks> http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=tree;f=queue-3.4;hb=HEAD
<ppisati> doh!
<ppisati> <title>500 Internal Server Error</title>
<ppisati> did i kill the wiki? :)
<ogra_> yeah, nobody can reach it anymore and at the bottom of the error page it says "killed by ppisati" !
<ppisati> :)
<ogra_> (works fine here)
<ogra_> ;)
<ppisati> i know
<ppisati> it even swallowed my stuff
<dileks> https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
<dileks> hmm, where is the feature-definition page?
<ogra_> status.ubuntu.com ?
<dileks> Google calendar of Precise Schedule <--- should be quantal
<dileks> http://fedoraproject.org/wiki/Releases/18/FeatureList
<dileks> I am looking for sth like this for upcoming F18
<ogra_> well,l i think status.u.c is the closest you can get, not sure we have another aggregation page 
<ogra_> (look at the team pages, features are listed by team)
<ogra_> we seems to have way more features defined than fedora, adding all feature definitions (blueprints) to a single list would be huge
<ppisati> apw: CONFIG_*_PHY have a "=y" policy because "PHY drivers are not autoloadable", but all these options are tristate, so they can actually be built as modules
<apw> ppisati, yes but as the annotation says, they cannot be autoloaded
<apw> there is no id to detect and load them as a result of detecting same
<apw> though i will say i have not personally verified that, that came from rtg
<ppisati> uhm, ok
<apw> so if they wern't Y we would have to modprobe them all i believe, or know which ones we need in any machine
<apw> which for x86 is a non-starter
<apw> now, you are welcome to go away and confirm/deny this assertion and we can change it for Q based on that
<ppisati> actually i expect the phy module to be loaded by the nic chip driver
<ppisati> so it makes sense to not have ids there
<apw> that would depend on them being able to detect the phy type inserted
<apw> as often they are replaceable at least in concept
<apw> but as i say, i have not confirmed this personally
<apw> so if you can a test case then you could try it out
<ppisati> right
<apw> i would be delighted to be wrong and be able to pull them all out
<dileks> ogra_: https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha1#New_features_in_Quantal
<dileks> looks more like what I was looking for
<ogra_> well, thats a past doc ... i thought you wanted the features for the quantal release
<ogra_> (future doc instead)
 * ogasawara back in 20
<janimo> apw, in .gitignore there's .orig but not .rej - is this so that git status shows the .rej files ?
<apw> probally just an oversight, that likely comes unchanged from upstream
<janimo> apw, ah discussed on lkml a couple years ago, intentional for various workflow related reasons
<janimo> would have been nice to add a comment detailing it in .gitignore at least :)
 * cking --> food
<infinity> ogasawara: Do you know if the plan for precise is to integrate highbank into master, like you've done for quantal, or will it be an out-of-tree build with its own ABI?
<infinity> ogasawara: (The latter will be a tiny bit more confusing, given that we'll have to remember they're "different", but not a big deal)
<ogasawara> infinity: plan is to integrate into master
<infinity> ogasawara: Sexy.  Thanks.
<ogasawara> infinity: apw's just sent out a config review
 * henrix -> EOD
<adrenalink> hello! it is possible to compile a vanilla kernel on ubuntu?
<adrenalink> in the last but one post in the following link, somebody says it is not legal ... O_O ... http://ubuntuforums.org/showthread.php?t=1387046
<ogasawara> adrenalink:  we provide mainline builds for ubuntu -> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<ogasawara> adrenalink: https://wiki.ubuntu.com/Kernel/MainlineBuilds <- that wiki has some details
<adrenalink> ogasawara: i want manage the kernel by myself (for instructive purposes), so I don't need a .deb package..
<adrenalink> I would know what ubuntu insert in vanilla kernel in its distribution
<adrenalink> and why...
<adrenalink> (I hope this is the right channel for this question)
<ogasawara> adrenalink: I'm not quite parsing your statement, you want to know the delta of patches we carry on top of the mainline kernel?
<adrenalink> yes. You appy a patch to vanilla kernel
<adrenalink> what does this patch do? and why?
<ogasawara> adrenalink: take a look at https://wiki.ubuntu.com/KernelTeam/Specs/QKernelDeltaReview, that's the most recent delta review we did for the Quantal kernel
<adrenalink> is it possible to run ubuntu with a vanilla kernel instead an ubuntu kernel?
<ogasawara> adrenalink: yes, as I noted above, you could install one of the pre built mainline vanilla kernels we're pre packaged for you and you'd be running a vanilla kernel in ubuntu
<ogasawara> adrenalink: if you want to build and run the upstream kernel yourself as an excersice, there's plenty of docs out there describing how to do so
<adrenalink> i know how i can compile by myself
<adrenalink> and I did it.
<adrenalink> but the system does not work. So i wanted to know if you insert something particular on ubuntu kernel..
<adrenalink> I'll read that link. thank you ogasawara !
<bjf> adrenalink, all our sources are public you can see everything we put into them
<adrenalink> ogasawara: of course! But asking to people that work on it, is more helpful that trying to find in the code. XD
<adrenalink> just another question: is what people say on this post false or not? http://ubuntuforums.org/showthread.php?t=1387046
<bjf> adrenalink, so it's better for us to drop what we are working on and answer questions that you could just as easily find out for yourself
<bjf> adrenalink, i think the person was trying to be funny. there is nothing that says you can't build your own kernel and use it
<adrenalink> bjf: you're in reason on this. But consider also that more people know (quickly) about something, more people can help about that!
<adrenalink> bjf: ok. I was trying to find this famous "terms of service"... :D
<dileks> adrenalink: you can use make deb-pkg together with the kernel-config of your installed kernel
<adrenalink> dileks: which are the advantages of creating a .deb for my kernel? (i usually do not use it)
<dileks> easier install/remove
<adrenalink> dileks: on installation I need a simple make install 
<adrenalink> uninstalling require removing the images and config from /boot and eventually /lib/modules/kernelversion modules
<dileks> so you seem to know what to do
<adrenalink> it is clearly faster to remove a .deb ....
<adrenalink> (it is not in doubt..)
<adrenalink> but this is not so a great thing
<dileks> you forgot include $mykernel into $bootmanager
<adrenalink> (dileks: correct me if I'm wrong..)
<dileks> https://github.com/lll-project/kernel/wiki/kernel_build_instructions -> "the normal way"
<adrenalink> yes,  of course! updating grub/lilo
<dileks> a wiki I have written when building upstream-linux with clang
<adrenalink> returning on the problem of ubuntu kernel...
<adrenalink> ogasawara: (and others)  yesterday I compile this ubuntu kernel source (after applying the patch) https://launchpad.net/ubuntu/+source/linux/3.2.0-23.36  with the config file i found in my ubuntu 12.04 distro (installed by iso)
<adrenalink> the compilation took about 5 hours, generating me an initrd.img of about 122 MB !!!
<dileks> see pointed wiki
<adrenalink> I suspect something is not necessary in that image...
<adrenalink> dileks: I would know why the image by the iso was about 14 MB, while the image for the same kernel but compiled by myself (with the same config file) is about 122 MB..
 * ogasawara lunch
<adrenalink> ogasawara: good lunch! XD
<adrenalink> and thanks for all the fish..
<adrenalink> ;)
<dileks> WARNING: With CONFIG_DEBUG_INFO=y the linux-image Debian package can have a huge filesize (minimal kernel-config: >=40MiB vs. >=8MiB without debug-info)!
<adrenalink> dileks: thanks! I'll try without it. But I can't understand why in the config file that comes with ubuntu iso CONFIG_DEBUG_INFO is set to yes (but the kernel image is small...)
<adrenalink> moreover it seems to me that it is not the real problem, because during compilation I noted a lot of driver compilation that weren't useful for my system, so I suspect the config file is too generic for my system.
<adrenalink> but again: 
<adrenalink> 1) I can't understand why the same config file has generated a small image with the "ubuntu iso", while compiling by myself it generate a kernel image greater than 120 MB.
<adrenalink> 2) How can I set by myself the necessary flags without trying them one by one until my system works?
<dileks> if you wanna play with a highly customized kernel - plug-in all hw you use, load all modules you want and create a new kernel-confog with make localmodconfig
<dileks> this will give you a "minimal" kernel-config
<dileks> ...and reduce build-time
<adrenalink> dileks: what "plug-in all hw you use" means for a PC machine?
<dileks> for example
<dileks> I wanted to load pics from my sd-card
<dileks> forgot to enable vfat-fs
<adrenalink> I think I'm not so skilled about this field...
<dileks> yupp
<dileks> thus trust the experts and use the distro kernel-config
<adrenalink> I aim to  understand something about it, so I can't trust on somebody else, because I want learn!
<adrenalink> can you give me any reference about the make localmodconfig prerequisites?
<adrenalink> (what I have to set/plug-in before that command...)
<dileks> its shipped with the linux-kernel kbuild-system
<adrenalink> ok. thanks for all the references and answers.
<adrenalink> stay tuned for next questions XD
 * cking -> EOD
#ubuntu-kernel 2012-06-09
<luc4_mac> Hi! I've been asked to perform a kernel bisection to inestigate a bug. I'm new to this, I would like to know if there is a lower limit to the version of kernel I can use on oneiric.
<orated> Hello! I got a mini usb adapter detected as - [ 1081.544865] Bluetooth: Generic Bluetooth USB driver ver 0.6 [ 1081.545588] usbcore: registered new interface driver btusb - But when I trying to use it with the help of blueman/bluedevil/bluetooth packages, it fails. What am I missing here?
<orated> Ah, got it! Just required to disconnect and then connec
<orated> t
<bjf> luc4_mac, what's the bug #? you probably should not have been asked to do that
<luc4_mac> bjf: bug #997767, why not?
<ubot2> Launchpad bug 997767 in linux "10ec:8139 Network connection rtl8139 lost after some hours of inactivity and comes up again on user interaction" [Medium,Incomplete] https://launchpad.net/bugs/997767
<bjf> luc4_mac: because that's rather intimdating for most folks
<luc4_mac> bjf: I understand
<luc4_mac> bjf: anyway, I was about to do it, but I would like to know how far I can go. I mean, 2.6.38 shows the problem. Can I go earlier in kernel versions? That was part of 11.04 I think.
<luc4_mac> bjf: Can I also go to older kernel?
<bjf> luc4_mac: you can go as far back as you want, what you'd like to find is the last kernel version that it worked and the first kernel version that it stopped working
<bjf> luc4_mac: given the two tags for those two kernel version, you can start bisecting
<luc4_mac> bjf: ok, then I'll try. The doubt was related to the fact that 2.6.38 was maybe part of 11.04 or similar. I've never had problems with those Ubuntu versions.
<bjf> luc4_mac: so you never had a problem as long as your ran Natty. as soon as you upgraded to oneiric, you started having problems?
<luc4_mac> bjf: as soon as I upgraded to 12.04. Never had problems in years with Ubuntu.
<bjf> luc4_mac: did you run oneiric?
<luc4_mac> bjf: of course I mean on the same system with the same hardware.
<luc4_mac> bjf: yes, no problems
<luc4_mac> bjf: also 11.04, no problems
<luc4_mac> bjf: and I don't remember from where I started using Ubuntu :-)
<luc4_mac> bjf: maybe 10.04 or similarâ¦ don't really remember.
<luc4_mac> bjf: no, maybe earlier...
<bjf> luc4_mac: that doesn't matter, the fact that oneiric worked for you is good
<luc4_mac> bjf: yes, but kernels from those versions are still installed, I tested those and the same issue can be reproduced. So it seems something related to kernel, but not entirely.
<bjf> luc4_mac: actually, that sounds more like a user-space issue that a kernel problem
<luc4_mac> bjf: yes
<luc4_mac> bjf: or something related to both
<bjf> luc4_mac: when you went from 11.10 to 12.04 did you upgrade or did you do a full re-install ?
<luc4_mac> bjf: never reinstalled, I always upgrade.
<bjf> luc4_mac: if you are at a point where any kernel you try now shows the same problem, bisecting isn't going to help
<luc4_mac> bjf: I also noticed that something seems to reduce the frequency of the faults, so for instance I assumed recovery mode was fixing, instead, I just discovered after some days that recovery mode reproduced the issue as well. I'll have to update the bugreport.
<luc4_mac> bjf: also keeping the usb mouse plugged in seems to reduce the frequency of faults.
<bjf> luc4_mac: i'd suggest comming back to this channel on monday and see if some of the other guys can help point you in a good direction. i'm at a loss right now what to suggest
<luc4_mac> bjf: I understand. Ok, thanks.
<lifeless> anyone have advice on how to get a reply to http://www.redhat.com/archives/dm-devel/2012-June/msg00013.html?
#ubuntu-kernel 2012-06-10
<janimo> lifeless, maybe G+ ping some of the involved :)
<BenC> ogasawara: Pull request for this stuff to ubuntu-kernel@?
<beata|lemur> I'm trying out a build of 3.2.0 for Lucid; so far so good but I'm tracking down an issue with apparmor, blocking dhclient with that kernel booted.
<lifeless> you may need an updated apparmour profile
<lifeless> just a wild guess
<beata|lemur> I'll know more once I have an unmodified 'generic' kernel. But I suspect that might be right.
#ubuntu-kernel 2013-06-03
<infinity> zequence: Your upload had a single bit-flip.  The git repo on github is fine, but there was a single bitflip on your hard drive (or in RAM when building the package).
<infinity> zequence: I'm going to re-upload directly to the kernel PPA from git once I've tested it builds locally.  You might want to check your hardware.
<shadeslayer> apw: I see, follow up question, would linux and linux-meta be enough if I upload a saucy kernel to the raring pocket of a PPA?
<shadeslayer> or do I need to backport more things?
<shadeslayer> ( I've test built both those packages in a pbuilder, they built fine )
<infinity> zequence: All fixed up now.
<zequence> infinity: ok, thanks. I don't think I mentioned to anyone I had moved the git repos to a project on github, but I guess you found out on your own. 
<zequence> this HD is only about 2 years old. I've only twice had problems with git repos on another HD, but never on this one. But, I guess one bit is all that it takes to screw it up.
<zequence> not that it was a problem with the git repo, only that is how I've noticed corruption in the past
<zequence> might be smart to test locally before uploading I guess
<shadeslayer> odd, I can't even get debuild to spit out the right files :S
<infinity> zequence: If you're doing it on a consumer-grade PC or laptop without ECC RAM, the bitflip could just be a normal consequence of using a computer, it might not be dying hardware.
<infinity> zequence: Still worth a check, though.
<infinity> zequence: (And if that file's corrupt in your local checkout, you'll want to re-clone, or at least replace the corrupt file)
<infinity> zequence: Anyhow, it's all in -proposed now, and ready for the binaries to be tested whenever.
<ohsix> if it managed to make it to software, dmesg and smart should show something, too
<zequence> infinity: right. ECC. Well, I'm not running server hardware here, but I should probably look at enhancing security a bit :)
<zequence> ohsix: dmesg didn't show anything.
<zequence> I just realized these are the same memory sticks though. I should probably check them
<zequence> (..the same sticks as when I had problems on another machine)
<infinity> ohsix: How would dmesg know about a bit flip in non-ECC RAM?
<ohsix> it wouldn't, nor a miswrite to the disk, but there are a lot more likely things to have happened than a random bit flip
<ohsix> unless you're at 40000 feet ;]
<infinity> Random bitflips are more common than people think.
<ohsix> or near an alpha source
<infinity> If only cking was around to cite the source he quoted last time this came up.
<infinity> But background radiation leads to a lore more flips than people assume.
<ohsix> http://www.jedec.org/sites/default/files/docs/jesd89a.pdf probably way more than you want to know about what jedec has to say about testing for soft errors
<ohsix> even if they were 1000x more likely than people think, it'd still be less than other sources of errors that you can check first :p
<infinity> Well, I did point out that failing RAM or a failing disk were worth checking for.
<infinity> But it's not worth tearing one's hair out looking for failing hardware that isn't, either.  Cosmic rays happen.
<ohsix> heh
<ohsix> consumer hard drive uncorrectable bit error rates are only 10e-14, you can check the smart test logs and the status for raw read error rate/reallocated ector count and be pretty confident that it's not it
<ohsix> there's a paper somewhere where google gathered statistics on soft errors in all the ECC/registered dram they used
<ohsix> if you look to see specifically what DRAM is on your memory widgets you can get the jedec measured numbers for the geometry from the vendor ;D
<infinity> ohsix: Ahh, yes, it was Google's study I was thinking of.
<infinity> "Our first observation is that memory errors are not rare
<infinity> events. About a third of all machines in the fleet experience
<infinity> at least one memory error per year (see column CE Incid.
<infinity> %) and the average number of correctable errors per year
<infinity> is over 22,000"
<ohsix> yup
<ohsix> in the aggregate, they leave all the details about what you could infer from a single module out, pretty much; aside from the table that shows a breakdown between ddr1/2/3
<infinity> Now, to be fair, on a non-ECC machine, the most common results of a bit-flip will be either "you don't notice", "you get a segfault", or "your system crashes", but an unlucky write it possible.
<infinity> s/it/is/
<ohsix> if you have a petabyte of ram and you average it across the number of dimms you have ;]
<infinity> Given how little of what gets shuffled around in RAM ever ends up on disk, "you don't notice" (or, you notice, but it's some random character corrupted on screen, etc) is probably the most common result.
<infinity> And most people would forget seeing such a thing once a year, if they saw it at all.
<ohsix> you can't really ignore the die size and sheer quantity of them when assessing if it's likely to happen to you, like i said; you need to get the specific DRAM datasheet to look for the soft error rate, they're all 'jedec' standard parts, but they have very different ratings for soft error rates depending on geometry and layout
<ohsix> lets not forget that a harddrive has dram in it
<ohsix> so you get the double whammy! :p
<ohsix> though with new ssd's and the scsi stuff for end to end integrity you can know a lot about even that, if you need to (*cough* commercial)
<shadeslayer> anyone around to help out a bit? if I do pull-lp-source linux , modify the changelog to build against raring and then run debuild -S -sd , there is no .dsc file to sign
<shadeslayer> and hence dput fails
<shadeslayer> I don't quite understand what's going wrong 
<hyperair> read the error messages
<apw> shadeslayer, well presumably the build fails, so can you pastebin the whole debuild -S output
<shadeslayer> apw: huh? the build works fine pbuilder
<apw> shadeslayer, probabally it is probabally because you have not said -nc and do not have the build-deps installed 
<shadeslayer> hyperair: but a .changes file is generated
<shadeslayer> hm
<apw> shadeslayer, just because debuild is dumb, doesn't mean it worked
<shadeslayer> heh, okay
 * shadeslayer will try with -nc
<hyperair> odd, i didn't think that .changes would be generated.
<shadeslayer> apw: and I just need linux and linx-meta
<shadeslayer> roght?
<shadeslayer> *right
<apw> shadeslayer, 'need' is a difficult word, some releases have lbm as well depending
<hyperair> wasn't there some script that automatically installs the build-deps of a source package?
<hyperair> i keep forgetting, since i just throw the entire thing into sbuild
<shadeslayer> -nc seems to have done the trick
<shadeslayer> apw: lbm?
<shadeslayer> ah
<shadeslayer> linux-backports-modules
<shadeslayer> apw: anything else?
<apw> shadeslayer, not that i can think of right now
<shadeslayer> ok
<shadeslayer> thx
<apw> shadeslayer, though can't you just pocket copy the source if all you are doing is rebuilding it
<shadeslayer> oh
<shadeslayer> I don't see a LP option to do that
<apw> shadeslayer, cirtainly it can be done, it is possible you cannot pull from the main archive without using the archive tools thingy
<shadeslayer> well, yeah, I know it can be done, I just don't see a way to do it from the web interface :)
<apw> shadeslayer, i think you might have to use copy-package
<shadeslayer> yep, looking at that
<shadeslayer> though .. does it do a no rebuild copy
<shadeslayer> ah no, there's a separate option for that
<shadeslayer> odd
<shadeslayer> apw: gives me a key error on 'saucy' http://paste.kde.org/757184/
<infinity> shadeslayer: You want "-s saucy", not "-d"... Distribution in that context is "ubuntu" or "debian".
<infinity> shadeslayer: And --to-suite instead of --to-distribution, too.
<shadeslayer> oh
<infinity> shadeslayer: And no need to mention component at all, since PPAs have no concept of them anyway.
<shadeslayer> yeah
<shadeslayer> hurray, thanks alot :)
<infinity> (And do you really want to rebuild it?  A copy-with-binaries would be much friendlier on the buildds, if the goal is just to have the saucy kernel in a raring PPA)
<shadeslayer> infinity: too late :(
<shadeslayer> plus buildds seem pretty empty
<infinity> shadeslayer: Not too late if it isn't building.  You could delete it and re-copy.  But, you can always copy better next time. :)
<shadeslayer> infinity: newb question, but won't different gcc versions affect the build?
<infinity> shadeslayer: In theory.  In practice, upstream tries really hard to make that not true.
<infinity> shadeslayer: But since the kernel we build in the primary archive is the one that gets heavily QAed, it's generally in your best interest not to rebuild your own, IMO.
<infinity> Better to share the bugs that millions of people have than share a weird new bug with 20 PPA users.
<shadeslayer> infinity: yeah, I can understand, however a derivative *really really* wants the 3.9 kernel since the 3.8 one is causing kernel panics for them
<infinity> shadeslayer: Sure, just arguing against rebuilding, that's all.  But, as you say, a bit too late, since it's already building.
<infinity> shadeslayer: Are their panics reproducible in a way that one could bisect with them?
<infinity> (And is there a bug filed?)
<shadeslayer> well, they said that their issues go away on 3.9
<shadeslayer> but I'll ask if it's possible for them to file a bug
<infinity> Sure, and that's cool for them, but we're still supporting 3.8 for 8 months, would be nice to fix it. ;)
<shadeslayer> *nod*
<shadeslayer> I also haven't heard back on bug 1171940 even though I supplied all the info :(
<ubot2> Launchpad bug 1171940 in linux (Ubuntu) "vgaswitcheroo on the Macbook Pro 8,2" [Medium,Confirmed] https://launchpad.net/bugs/1171940
<shadeslayer> patch wasn't there on 3.9.1 ... haven't checked after that 
<apw> shadeslayer, have you any idea just how many open bugs we have on the kernel?
<apw> shadeslayer, have you tested that patch and confirmed it fixes the issue ?
<apw> ie are you going by more than the description of the patch
<shadeslayer> apw: yes, I've tested it and it does indeed fix the issue
<apw> shadeslayer, it would be helpful to put that in the bug, as it was not clear to me
<shadeslayer> can do
 * ppisati -> out for lunch
<apw> henrix, sconklin, bjf[afk], i am just playing with the cve-autotriager to sort out the issues with "-proposed kernels which never released" versions begin included
<apw> so you may want to ignore it for a bit, as i suspect it will be slapping things about for a bit
<henrix> apw: ack, thanks
 * henrix will be out for a bit
 * ppisati goes out for a bit
<ogra> hmm, where do i find the git tree for linux-grouper ?
<ogra> seatching on kernel.u.c doesnt reveal anything regarding grouper 
<ogra> (same for maguro)
<cking> ogra, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=shortlog;h=refs/heads/grouper perhaps is what you want?
<ogra> perfect, thanks 
 * ogra tries to find out why that one doesnt boot with flipped container (natively into an ubuntu rootfs) 
<ogra> maguro works flawless ... i'm wondering if its a kernel config issue
<apw> ogra, they are all in saucy
<apw> ogra, most likley, it is very hard to get them the same with them all being random versions
<ogra> apw, i only want to see the config, not start a download orgy
<ogra> :P
<apw> it is in /boot on the device
<ogra> it isnt 
<ogra> we dont have the package installe on the images
<ogra> *installed
<apw> ogra, then you'll need either the binary package which has it in, or your'll need the source
<ogra> yes
<ogra> or just look at git with a browser
<jono> ogasawara, hey
<jono> I just saw on G+ that someone got bitten by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/798086
<ubot2> Ubuntu bug 798086 in linux (Ubuntu) "Occasional "The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present" on system startup" [Medium,Confirmed]
<jono> it seems to be a few years old, would you folks mind taking a look into it?\
<ogasawara> jono: sure, I'll ask jsalisbury to follow up
<jono> thanks ogasawara
<jsalisbury> jono, ogasawara I'll take a look at that bug
<jono> thanks jsalisbury
<jsalisbury> jono, np.  If possible, can you also email me the g+ link
<jono> jsalisbury, https://plus.google.com/u/1/117353980479250980339/posts/TFneH4qPrik
<jsalisbury> jono, thanks
<jono> if you could hop on that thread and follow up that would be great
<jono> just shows we care :-)
<jsalisbury> jono, done.  and we do care ;-)  
<jono> thanks jsalisbury :-)
#ubuntu-kernel 2013-06-04
<infinity> zequence: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1187230
<ubot2> Ubuntu bug 1187230 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> ikepanhc: https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1187229
<ubot2> Ubuntu bug 1187229 in Kernel SRU Workflow "linux-armadaxp: <version to be filled> -proposed tracker" [Medium,In progress]
<ikepanhc> infinity: for precise? you will have it today
<infinity> ikepanhc: \o/
<Guest85775> Dear All,
<Guest85775> I have a question about adding a new wireless command to 
<Guest85775> kernel 
<Guest85775> specifically one of depreciated commands
<Guest85775> What is the safest way to do this?
<apw> i don't think we know what you mean by a 'deprecated wireless command'
<Guest85775> sorry
<Guest85775> I mean iwspy
<Guest85775> I can not get any outputs other than errors
<Guest85775> the errors: http://pastebin.com/krdNpPqJ
<apw> Guest85775, when did it last work
<Guest85775> This morning 
<Guest85775> oo sorry 
<Guest85775> it does not work yet
<Guest85775> and I realized that is has been removed from the kernel
<apw> well it is not removed from raring's kernel, which kernel did it last work for you
<Guest85775> http://tinyurl.com/kernel-remove
<Guest85775> see above link
<Guest85775> uname -a out put is 3.8.0-19-generic
<apw> oh then that is even dumber as they removed the 'connection' to ispy but the rest of the code is there
<apw> so ... that implies the numbers wern't valid anyhow, so i don't suppose connecting
<apw> it back up is going to help any, what number are you trying to find with ispy
<Guest85775> I have several nodes in adhoc mode 
<Guest85775> I got their mac addresses with ifconfig -a 
<Guest85775> when I type iwspy eth1 + 0c:1c:6c:0c:3c:86
<Guest85775> with one of MAC add.s or IP adress 
<Guest85775> it generates errors
<apw> what did it do before
<Guest85775> nothing same errors 
<apw> when it worked, in older releases, what did give you
<apw> what infoirmation are you running it for
<Guest85775> ok. 
<Guest85775> I find a forum post to see its output 
<apw> as the upstream wireless people are saying it was producing rubbish
<Guest85775> https://forum.openwrt.org/viewtopic.php?id=12889&p=2
<Guest85775> There is a out put for this command and I am trying to get similar outputs
<Guest85775> to be more specific I need signal levels of each nodes in the ad hoc network
<apw> hmm, well iwspy on mac80211 devices has been gone so long you have near no hope of restoring that, we don't support a kernel old enough to even have it still
<apw> it was removed in 2008
<Guest85775> OK. So is there any way to get similar output by any bash commands ?
<apw> that i know of, sorry i have no idea, i have never setup an adhoc network
<apw> though do they not appear in iwlist <interface> scanning
<Guest85775> no
<apw> as you can see ad hoc networks in network manager
<Guest85775> I have found 
<Guest85775> sudo iw dev eth1 scan
<Guest85775> command yet it behaves strange 
<Guest85775> since it collects completely diffent mac addresses, I mean other than our machines
<apw> presumably it is seeing everything in your area
<Guest85775> anyway, based on my first question, is there a way to integrate iwpsy command to my current kernel?
<Guest85775> if yes how?
<apw> that functionality was declared dead and unsupported for the majority of cards back in 2008, i think that is a dead end
<apw> and they did that saying in 2008 that it wasn't working for a long time
<Guest85775> ouch, it really hurts
<Guest85775> apw, thanks for your answers.
<apw> np
<infinity> ppisati: You have two new rebases awaiting your attention, BTW.
<infinity> ppisati: #1186475 and #1187228
<infinity> smb: And #1186479 for you, if you missed it. :)
<smb> infinity, maybe you noticed the additional version number :)
<infinity> smb: Oh, hah, that was only 40m ago, the workflow report hadn't picked up the title change yet.  Ignore me.
<smb> infinity, Oh well it was only a tad ago... Btw, the saucy xen update to 4.2.2 would not need tech-board involvement, yet... lalala
 * smb looks sadly at the smoke cloud which is now in the place infinity was just seconds ago...
<infinity> smb: I got distracted by a lively conversation on #debian-devel
<infinity> smb: Remind me about Xen at your EOD (which should be vaguely when I'm getting up)
<infinity> smb: s/Remind/Pester/
<smb> infinity, Its just what usually happens when you mention reviewing Xen packages to anybody. Just was abusing you a bit.
<smb> infinity, Will try to remember... sometimes hard after sitting through irc meetings :--P
<infinity> smb: I found the best way to deal with that was to transfer to a team that doesn't have IRC meetings.
<ppisati> infinity: i did a rebase last week, but i was never 'imported'
<smb> There is such a thing?
<infinity> ppisati: Yeah, we skipped your update from last week, as we guaged the impact on omap4 to be not worth the process.  This week's is new. :)
<smb> Guess I need to think about begging to move to release...
<smb> Actually our own team meeting is just noticeable by the irc window getting hot (if open) from the friction
<infinity> You rub your IRC window?
<infinity> Kinky.
<smb> infinity, More the text rushing by rubs against it. ;)
<infinity> Also kinky.  I think?
<infinity> If you're into that sort of thing.
<infinity> Anyhow.  I should wander off and try to nap.
<smb> I would not be completely sure either... Have a good nap!
 * apw giggles at infinity
<apw> [DEFAULT]
<apw> default_host_main = UNKNOWN
<apw> smb, ^^ i have that at the top of my .dput.rc
<infinity> cking: Can you verify your SRU for bug #1180394 ?
<ubot2> Launchpad bug 1180394 in linux-nexus4 (Ubuntu Raring) "ubuntu-nexus4, lttng-modules-dkms won't build with current kernel" [Undecided,Fix committed] https://launchpad.net/bugs/1180394
<cking> infinity, sure will do
<infinity> cking: Shiny, thanks.
<cking> infinity, after some wrestling with the N4, it's verified 
<infinity> cking: Danke.
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 11th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<bjf> Number of commits applied since release -  lucid : 3362; precise : 3173; quantal : 2014; raring : 317
<smb> bjf, I think I see kamal work to "improve" the r-numbers... :)
<bjf> indeed
 * apw manages to get -rc4 to boot ... yay
<zequence> infinity: precise is uploaded to PPA and seems to be building fine
<zequence> I'm still using this same machine for building, but will set up another soon
#ubuntu-kernel 2013-06-05
<apw> diwic, yo ... this SND_DEBUG thing, is this something you would make use of if it was turned on?
<diwic> apw, rarely, but it happens
<diwic> apw, heh, by your latest email it seems we're following upstream's recommendations
<diwic> apw, or, its default but not its recommendation, which is a bit contradictory
<apw> diwic, yeah, so as you are our audio expert we would prefer to be guided by you, if you see value in it, file a bug and let me know the number and we can prototype it in saucy
<diwic> apw, ok. I'll await what Takashi says about it
<apw> diwic, great, i will promptly forget until we hear from you
<diwic> apw, ack
<apw> diwic, i think he has already replied in the positive, so file me a bug
<apw> and i'll get it in the next saucy 3.9 upload, i am keen to upload it as it has a security patch sitting on it
<apw> diwic, there is a new option exposed by SND_DE
<apw> diwic, there is a new option exposed by SND_DEBUG, SND_PCM_XRUN_DEBUG ... do we want that on or off
<diwic> apw, I guess the value is either that we're testing code that others are not testing (QA!), or that we're sticking with what SuSE is doing (less bugs for us!)
<diwic> apw, I've actually fixed a bug once that only occurred with SND_DEBUG off
<diwic> apw, let me check XRUN_DEBUG and see if it has any performance impact
<apw> diwic, we want less bugs i suspect
<diwic> apw, xrun_debug can actually be even more helpful
<diwic> apw, I say let's go for both
<diwic> apw, bug 1187744
<ubot2> Launchpad bug 1187744 in linux (Ubuntu) "please enable SND_PCM_XRUN_DEBUG" [Undecided,New] https://launchpad.net/bugs/1187744
 * henrix -> lunch
<psivaa> jsalisbury: Just curious about the ETA of a fix for bug 1181315. 
<psivaa> This bug is causing a couple of daily smoke test failures and it's not being assigned to anyone.
<psivaa> Would also help to get that assigned. thanks
<jsalisbury> psivaa, I'll start the bisect now.  It would be good to test v3.10-rc4 as well, just to confirm it's not fixed in mainline.
<jsalisbury> psivaa, I'll post a link to v3.10-rc4 in the bug
<apw> diwic, ack
<apw> ogasawara__, i am thinking i would upload a 3.9 saucy, to get the pending security fix out
<ogasawara__> apw: ack
<apw> ogasawara, and i'll upload the unstable to preproposed
<ogasawara> apw: ack
<henrix> jsalisbury: re bug #1186932
<ubot2> Launchpad bug 1186932 in linux (Ubuntu) "Regression: kernel 3.8.0-24 breaks WPA enterprise auth [iwlwifi]" [High,Confirmed] https://launchpad.net/bugs/1186932
<henrix> jsalisbury: looks like the fix is commit a87783699b23395c46bbeeb5d28f6db24897bf26
<henrix> jsalisbury: its a linus tree sha1
<henrix> jsalisbury: if you check the commit body, it refers to bug that seems to be the same one
<jsalisbury> henrix, cool, thanks for finding
<henrix> jsalisbury: np
<henrix> jsalisbury: let me know if you want me to build a test kernel
<jsalisbury> henrix, I'll build a raring kernel with that commit and post it to the bug
<jsalisbury> henrix, heh, 
<henrix> :)
<jsalisbury> henrix, it's up to you.  I don't mind doing it
<henrix> jsalisbury: and it looks like we'll hit the same bug on other kernels as well (at least Q)
<henrix> jsalisbury: heh, looks like the bug reporter has already found the fix himself :)
<henrix> and he confirms it fixes it, so no need for a test kernel ;)
<jsalisbury> henrix, great
<jsalisbury> henrix, it looks like a87783699b23395c46bbeeb5d28f6db24897bf26 was sent to stable
<henrix> jsalisbury: yep, that's how i found it :)
<jsalisbury> henrix, :-)
<henrix> _bjf: is it too late in the sru cycle to add this fix into the kernels (P, Q and R)?
<psivaa> jsalisbury: I've just updated bug #1181315 to say that it is still present in v3.10-rc4 as well. 
<ubot2> Launchpad bug 1181315 in linux (Ubuntu) "unregister_netdevice: waiting for lo to become free. Usage count = 2' is reported and causing kernel hang when floodlight tests are run using utah" [Medium,In progress] https://launchpad.net/bugs/1181315
<jsalisbury> psivaa, cool.  Thanks.
<jsalisbury> psivaa, I started a bisect, so I'll have a test kernel for that shortly.
<jsalisbury> psivaa, I also identified two commits in the changelog from 3.8 to v3.9-rc1 that may be suspect. I'm also going to post  a test kernel with those two commits reverted as well.
<psivaa> jsalisbury: ack, could test that when it's ready
<apw> jsalisbury, sounds like you are haivng fun there
<jsalisbury> psivaa, copying it now.  posting  a link to the bug
<jsalisbury> apw, always having fun ;-)\
<psivaa> jsalisbury: ack
<psivaa> jsalisbury: just fyi, the test kernel also has the issue.
<jsalisbury> psivaa, I started a bisect and posted the first test kernel.  A link to the test kernel is in the bug.
<cafetiere> smb`: it is sunny outside ... Why are we inside ...
<slangasek> oh wow, my system has actually gotten itself into a state where the swap *is* used... 100% of it
<slangasek> that's a curious change
#ubuntu-kernel 2013-06-06
<slangasek> wow, something is seriously wrong with how the memory is being counted here
<slangasek> could unity instances that segfaulted and died be using up system memory that doesn't show up under 'smem'?
<smb> apw, I actually *was* outside
<apw> smb, heh nice, so was i when i sent it :)
<smb> apw, I was guessing from the name
 * apw whines about x hanging in raring
<smb> some people have so much fun
<ppisati> actually, some people have _all_ the fun :)
<apw> can it _hear_ me ?
<ppisati> no
 * apw glares at X
 * ppisati -> out for lunch
 * henrix -> lunch
<ppisati> don't we routinely run xfstests as part of our SRU testing?
<ppisati> sconklin: ^
<ppisati> ok, bjs is not here...
<ppisati> *bjf
<sconklin> ppisati: We have test cases that run it, but I don't know how 'routinely' it gets run, bjf will know. he should be here any minute
 * ppisati goes out for ~20mins
<rsalveti> apw: rtg_: would be nice to have linux-tools for the touch related kernels as well
<rsalveti> so we can have perf
<rtg_> rsalveti, I'll look into it
<rsalveti> rtg_: awesome, thanks
<ogra> (note that we dont install the packages at all though)
<ogra> i wonder if it would be possible to not have linux-tools depend on the kernel package ... so you dont have to do that big download
<rsalveti> ogra: well, we can install in runtime
<rtg_> ogra, aren't we going to use the kernel deb once the container is flipped ?
<rsalveti> no issues with that
<ogra> rtg_, we will do image based updates and the ubuntu rootfs is supposed to be completely arch independent ... 
<ogra> the image based update will just ship a boot.img 
<ogra> processing using the package happens server side
<rtg_> ogra, so rather then having a separate tools package, you'd rather have perf bundled with the kernel ?
<ogra> nah, but a tools packaage that doesnt hard depend on the kernel
<ogra> so that you can install and use it without having to install the kernel package
<rtg_> ogra, that should be possible given that the Nexus kernels really don't change much
<ogra> yeah
<rtg_> jjohansen, sconklin: bouncing tangerine for kernel update
<sconklin> rtg: ok
<rtg_> jjohansen, sconklin: tangerine is back
<rtg_> jsalisbury, henrix, arges: bouncing gomeisa for kernel update
<henrix> rtg_: ack
<arges> rtg_: ok
<rtg_> arges, its back up
 * rtg_ -> lunch
<bjf> bdmurray, bug 1098242 stil an issue?
<ubot2`> Launchpad bug 1098242 in linux (Ubuntu) "[LENOVO 0831CTO] late resume failure" [Medium,Confirmed] https://launchpad.net/bugs/1098242
<bdmurray> bjf: nope
<bjf> bdmurray, thanks
 * rtg_ -> EOD
<shadows> oops on 3.8.x and newer kernels when disconnecting bluetooth DUN
<shadows> how to debug?
<jsalisbury> shadows, its best to open a bug by running the following from a terminal: sudo ubuntu-bug linux
<shadows> jsalisbury: There is an open bug
<shadows> bug #1165433
<ubot2`> Launchpad bug 1165433 in linux (Ubuntu) "Kernel 3.8.x panics on bluetooth DUN disconnect" [High,Confirmed] https://launchpad.net/bugs/1165433
<shadows> jsalisbury: what else is to be done?
<cyphermox> hi
<cyphermox> I'm looking at the maguro (and to a lesser extent mako) devices, and I notice there seems to be the config CONFIG_BT_HCISMD missing
<cyphermox> could someone please add it for maguro on saucy?
#ubuntu-kernel 2013-06-07
<bjf> cyphermox, it's sooo much nicer to make those kinds of requests to the mailing list
<cyphermox> sure
<bjf> cyphermox, just more likely for the right person to see it and less likely that it gets missed or forgotten
<cyphermox> bjf: you're totally right
<cyphermox> I'll send it shortly :)
<bjf> thanks
<cyphermox> bjf: sent it, sorry; I was multitasking -- it should have been my first action :)
<infinity> zequence: World respun, again.  If you want to do a few quick rebases. :/
<infinity> zequence: bug #1188461 bug #1188495 and bug #1188466
<ubot2`> Launchpad bug 1188461 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188461
<ubot2`> Launchpad bug 1188495 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188495
<ubot2`> Launchpad bug 1188466 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188466
<ppisati> did we respin P?
<infinity> ppisati: P, Q, and R, even.
<ppisati> infinity: i mean tonight
<infinity> ppisati: iwlwifi-specific, so it doesn't really affect ARM, but since your branch hasn't been uploaded yet anyway, may as well rebase.
<infinity> ppisati: Yeah, we respun all three today.
<infinity> ppisati: bug #1188464 and bug #1188492
<ubot2`> Launchpad bug 1188464 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188464
<ubot2`> Launchpad bug 1188492 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188492
<ppisati> i see onlyne one respin to be done:
<ppisati> http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
<infinity> ppisati: The quantal bug was just made, the workflow report is behind.  Hence my linking it for you. :)
<ppisati> infinity: can you publish to the ckt ppa the unpubblished Q/omap4 kernel? i need 
<ppisati> infinity: it for kteam-tools ABI script
<apw> cyphermox, yo ... CONFIG_BT_HCISMD do you want =y or =m there?
<apw> cyphermox, also, this option does exist for mako, but never did for maguro
<apw> cyphermox, ok replied in email
<ogra> root@ubuntu-phablet:/# uname -r
<ogra> 3.0.0-1-maguro
<ogra> root@ubuntu-phablet:/# zgrep DEVTMPFS /proc/config.gz 
<ogra> CONFIG_DEVTMPFS=y
<ogra> # CONFIG_DEVTMPFS_MOUNT is not set
<ogra> hmpf 
<ogra> could we fix that for all ubuntu touch kernels ?
<apw> ogra, yep
<ogra> thx 
<apw> ogra, though our standard tooling does cope with it normally
<ogra> i might also have an additional grouper change 
<ogra> yeah, i know but it slows down booting if the script has to kick in
<ogra> (minor but it does)
<apw> yep
 * ogra sighs about grouper ... 
<ogra> while it is so easy for desktops it is a pain with android ... 
<apw> ogra, ok those have already been fixed across the board in rtg's next kernels
<ogra> awesome !
<ogra> rtg_, rocks :)
<rtg_> ogra, um, what did I do ?
<ogra> #
<ogra> CONFIG_DEVTMPFS_MOUNT
<ogra> fixing that 
<ogra> (on the touch kernels)
<rtg_> ogra, now I'm struggling with perf. kind of a PITA to get built.
<ogra> well, i'm fighting with a non booting grouper over here ... it is the only arch having massive probs with the container flip
 * henrix -> lunch
<rtg_> apw, linux_3.10.0-0.2_source.changes rejected, PPA exceeded its size limit (16472.00 of 16384.00 MiB).
<brendand> anyone have details for this respin: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1186271
<ubot2`> Ubuntu bug 1187926 in Kernel SRU Workflow verification-testing "duplicate for #1186271 linux: 3.5.0-34.55 -proposed tracker" [Medium,In progress]
<rtg_> apw, nm. I see you uploaded to a different PPA
<rtg_> brendand, you'll have to wait for sconklin or infinity 
<henrix> brendand: there was a regression in iwlwifi driver
<henrix> brendand: this bug #1186932
<ubot2`> Launchpad bug 1186932 in linux (Ubuntu) "Regression: kernel 3.8.0-24 breaks WPA enterprise auth [iwlwifi]" [High,Confirmed] https://launchpad.net/bugs/1186932
<apw> rtg_, yeah i am waiting for the PPA to register that i have deleted everything in it
<apw> rtg_, then i am going to pocket copy it out of the /ppa PPA when it is built
<brendand> henrix, i wonder can we have a convention to post details of the respin on the tracking bug, to reduce the level of mystery :/
<henrix> brendand: :) that would probably make sense
<henrix> brendand: i believe bjf was discussing something along those lines yesterday, but not sure about the details
<apw> smb, you have a lucid box i think, could you test something for me
<apw> smb, specifically can you see if the following oopses it for me
<apw>   $ cd /sys/kernel/debug/tracing
<apw>   $ echo 1234 | sudo tee -a set_ftrace_pid
<smb> apw, If it does not have to be real hw...
<apw> oh good point i have VMs
 * apw goes boot op something
<apw> p
<apw> up
<apw> erp
<smb> apw, Yeah, I would not be sure whether I still got something bare-metal on L
<apw> smb, no i was thinking of your precise machine ... getting my OLD lts' mixed up
<smb> apw, Oh yeah, I know _that_ feeling. :)
<apw> i suspect i am going senile
<smb> And then there is the whole 2.6.32 vs 3.2 confusion
<apw> heh ... i only have a server install for L thats how old it feels
<apw> must get those isos down and build some L desktops ...
<smb> good point... 
<smb> I think I don't have one of those either
 * apw installs both anyhow
<sconklin> brendand: was that enough of an answer that you got earlier?
<brendand> sconklin, yes
<smb> apw, I seem not to get an oops
<apw> smb, great, me either, that confirms my analysis that that release is not affected
<rtg_> apw, I'll pick up mako CONFIG_BT_HCISMD when I enable perf.
<apw> rtg_, ack
<arges> rtg_: hi
<rtg_> arges, yo
<arges> rtg_: looking at your iptables patch here: http://git.netfilter.org/iptables/commit/?id=79ddbf202a06e6f018e087a328c2ca91e65a8463
<rtg_> arges, don't fear the reaper
<arges> i'm trying to merge 1.4.18, and i noticed that some of the stuff in your debian patch didn't make it into that commit 
<arges> heh
<rtg_> arges, really ? like what ?
<arges> rtg_: these were the changes that were in the 9002- patch but not in that commit: http://pastebin.ubuntu.com/5742113/
<arges> Not sure if they are necessary, or can be dropped. or if there is a good way to test (try --reap with --seconds etc)
<rtg_> arges, that one seems kind of important IIRC
<rtg_> arges, the reaper needs a periodic cycle time
<arges> rtg_: ok well those changs aren't in the lastest iptables git. so maybe it needs to be resubmitted
<rtg_> arges, feel free to hassle him
<arges> ok : )
<rtg_> there doesn't seem to be any obvious reason why that bit would not have been included
 * apw revs up to calling it a day
 * rtg_ -> lunch
<infinity> zequence: You around?
<infinity> zequence: The current respins of P/Q/R are fairly important for x86 users (so, lowlatency counts there), as they fix a nasty regression in iwl wifi.
<infinity> zequence: Should be a dirt simple rebase, it's a 1-line fix.
<zequence> infinity: alright. I'll get right to it
<infinity> zequence: Thanks.  You're a champion.
<zequence> I will be if my bits stay in order :P
<infinity> *cough*
<infinity> debdiff before you upload. :)
<infinity> Ideally against the one from -proposed, not against what's on your hard drive. :P
<zequence> infinity: Oh, so that will error if there's an error?
<infinity> zequence: No, but it'll tell you if some random file you didn't mean to change got changed.
<infinity> debdiff old.dsc new.dsc > foo.diff && lsdiff foo.diff (or just read the diff)
<zequence> infinity: ok, thanks
<ppisati> "omap4 3.2.0-1433.43 failed to build"
<ppisati> WTF?
<bjf> looking
<bjf> still showing "currently building" for me
<ppisati> got an email sayign "failed to build blablabla"
 * rtg_ -> EOW
<zequence> infinity: I can't get the packages built today. Something is not right. I really need to crash, so it'll have to wait until tomorrow
#ubuntu-kernel 2013-06-08
<infinity> zequence: Kay, no rush.
<zequence> infinity: Ok, all uploaded
<infinity> zequence: Looks good.  I'll wait for it to build and copy it over this weekend.
<Guest59966> test
<sulphur16> I have booted Ubuntu 12.04 with i8042.debug kernel option
<sulphur16> from dmesg I get output like
<sulphur16> [  222.291899] i8042: [55420] aa <- i8042 (interrupt, 0, 1)
<sulphur16> can anyone tell me what exactly is 55420 in the above line?
<infinity> zequence: All built and copied to -proposed and ready for regression testing.
#ubuntu-kernel 2014-06-02
<apw> Hauke (N,BFTL), it does not seem like we have any obvious way currently indeed.  i might be persuaded such a thing is reasonable.
<jpds> Could somoene take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1325260 ?
<ubot5> Ubuntu bug 1325260 in linux (Ubuntu) "CompuLab Intense PC2 does not shutdown correctly on 14.04" [Low,Triaged]
<jpds> I've found the one line patch that fixes the issue.
<apw> jpds, ok
<xnox> "E: 10mount: mount: unknown filesystem type 'overlayfs'" hm, wtf.....
<brendand> xnox, can you reproduce that?
<apw> xnox, what kernel
<apw> xnox, cat /proc/version_signature
<mlankhorst> isn't it /proc/version, or uname -a ? :p
<xnox> apw: hm, looks like i'm running your kernel from the kernel ppa. Let me upgrade to 3.15-4
<xnox> Linux version 3.15.0-031500rc5-generic (apw@gomeisa)
<xnox> rc5 sounds old, given that rc8 is out the door.
<brendand> xnox, aren't you using an ideapad yoga 13 too?
<apw> xnox, missing extras perhaps ?
<xnox> brendand: i am!
<brendand> xnox, updating the kernel usually means i have to rebuild wifi drivers
<brendand> xnox, so i avoid it
<xnox> brendand: and i have a bunch of things going wrong with it with 3.15 kernel, but it's slowly getting better.
<xnox> brendand: i have dkms module for that & it's no longer actually needed, as that driver got merged into staging in 3.14 and is enabled in our config
<brendand> xnox, oooh. cool
<xnox> brendand: well, it generates kernel oopses on suspend&resume though =(
<apw> xnox, getting better, thats no good, i need to inject some more "if (xnox) BUG" code clearly
<xnox> apw: michael fry punished me enough for last weeks breakages already
<apw> heh likely true
<apw> xnox, oh you are runing mainline kernels, yeah they do not have anything non-upstream in them
<xnox> apw: 3.15-4 is no good (locks up after graphical login, before compiz/unity get a chance to start)
<apw> xnox, lovely
<xnox> apw: and loads of oopses if i have any usb3 activity
<apw> xnox, what sort of lockup, can you ssh in etc
<xnox> apw: didn't check ssh, but graphics were unresponsive.
<apw> xnox, you bought an absolute turkey of a machine there didn't you, with hindsite buying a lenovo and having it spraypainted yellow sounds a more sensible plan
<xnox> apw: back on 3.13 kernel cause have "work" todo (aka break the archive)
<apw> heh, well have a look aback at syslog and see if it recorded anything before you wacked it with a stick
<xnox> apw: sabdfl liked it =) 
<xnox> apw: yeap http://paste.ubuntu.com/7572245/ search for "cut here" same usb error over and over again.
<xnox> not sure if that's upstream rc4 kernel or 3.15-4 though =(
<xnox> /home/apw -> that's rc4
<xnox> worth reporting at all?
<apw> i'd say not, unless you get it with -4
<brendand> xnox, maybe it's worth noting that i didn't have any problem last week creating an armhf chroot
<brendand> xnox, i wonder was it broken in an update
<apw> jpds, ok test kernels are available in your bug
<jpds> apw: Ah, cool, though I won't have access to the hardware until at least next week..
 * jpds tries to find someone who can turn the machine on.
<manjo> rtg, can you enable trusty arm chroot on tangerine ?
<rtg> manjo, no support for arm chroots anymore. use the cross compiler in the amd64 chroot
<rtg> dpkg-buildpackage -B -aarmhf
<manjo> ah ok
<rtg> actually, dpkg-buildpackage -d -B -aarmhf
<manjo> dpkg-buildpackage -d -B -aarmhf -us -uc
<rtg> yeah, that works too
<manjo> rtg, dpkg-buildpackage -nc is supposed to recompile .. how do I make it not restart config ? 
<manjo> rtg, coz I copied in a .config in build/ 
<manjo> rtg, I don't want dpkg to ask me any config qs .. I want it to skip that ... I thought -nc would do it .. but it still is asking me Qs 
<rtg> manjo, -nc is "do not clean". if you're usinga local .config, then perhaps you want 'make deb-pkg' instead.
<manjo> rtg, how doees that work with arm cross compile ... Ihave not used it 
<rtg> manjo, make deb-pkg ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
<manjo> rtg, sorry got kicked by irc .. how does make deb-pkg work with cross compile ?
<rtg> manjo, make deb-pkg ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
<manjo> ok let me try that 
<sconklin_> arges: I know you're in sprint recovery but I'm willing to discuss the trusty net ns bug any time :-) We're unable to reproduce it anywhere outside our production environment, where we can't get a crash dump
<sconklin_> maybe it's time for "debug by kprint"
<rtg> sconklin_, he's not back until Wednesday IIRC
<sconklin_> ok, nice. Did he tack on some time off?
<rtg> yup
<sconklin_> cool.
<stgraber> sconklin_: I spent half a day or so last week during the sprint to try and trigger this without much success... I've reproduced it a couple of times by accident but even with linux-coredump installed I can't get a core... My attempt at creating hundreds of netns, flooding them with millions of packets all doing round trips through netfilter + killing them at random didn't trigger any panic either...
<sconklin_> stgraber: it's so frustrating that we can trivially reproduce this 100% of the time in our operating environment
<stgraber> sconklin_: what kind of load do you have in that prod environment? here I noticed it'd tend to happen a lot more when my machine was crazy busy than when it was mostly idle (it blew up in my face twice when doing kernel builds while playing with lxc...)
<sconklin_> checking, stand by
<sconklin_> stgraber: very lightly loaded. It's an instance that's only running our supervisory app and a single lxc container
<stgraber> sconklin_: interesting
<sconklin_> stgraber: rsampaio_ just popped in here, he's been doing the testing and is a lot more familiar than I am with how it all works (or doesn't)
<stgraber> sconklin_, rsampaio_: do you also get the panic when killing a container or do you somehow get it during standard operation?
<sconklin_> stgraber: and when I said "production environment" what I meant was "a test environment identical to our production environment"
<rsampaio_> stgraber, sconklin_, the panic happens after we kill the container, few seconds later
<rsampaio_> I was able to get the lockdep files before the panic happens
<stgraber> ok, so that matches what I've been seeing here the rare few times it happened to me
<rsampaio_> I wish I could get a crashdump from the ec2 instance, it is very easy to reproduce in our environment
<rsampaio_> I've tried the kvm image from Chris running for a couple hours but no panic
<stgraber> and I guess your EC2 instance depends on other instances so you can't just copy the fs to a local VM and reproduce the panic there?
<rsampaio_> yeah there are a few other instances involved in the process
<balerion> hi anyone there ??
<balerion> i need help with the kernels which control the display ( as in on screen/monitors )
<balerion> can anyone help ??
#ubuntu-kernel 2014-06-03
<apw> balerion (N,BFTL), you probabally should be more specific as your issue, as that allows someone 4 hours later to work out if they are the right person to reply; plus you should file a bug
<Technetium191> Hi forum, I've had to install an rc Ubuntu Mainline Kernel to overcome a bug with vsftpd in 14.04 - can anyone explain if and how the generic kernel in Trusty will ever be updated to this rc, or am I stuck with using a mainline kernel forever?
<smb> Technetium191, Upstream stable changes will be carried back to the generic kernel. Usually about every three weeks. And if it is the problem of running vsftp in EC2, that is queued for the next updates round
<Technetium191> Thanks smb, yes that's the bug. So I can keep running the mainline rc kernel for a few weeks and when the next generic update comes along change over to it? So if 3.13.0-27-generic is the latest kernel I guess I'm waiting for 3.13.0-28-generic? 
<smb> Technetium191, There has been a bit of riple effect from some "urgent" things. So the next one currently pending is 3.13.0-29.52
<smb> Give me a sec to check whether that patch is in there
<smb> Technetium191, Ok, sorry, that one (-29) is still without that patch. So -30 supposedly contains the fix
<Technetium191> smb, where can I find that kind of information, release schedules, included patches etc?
<smb> http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=summary branches with the queues (the longterm repos we support), otherwise the ubuntu-trusty tree on the same site contains the current version in release in master and master-next is staging. 
<smb> For the schedule... maybe https://wiki.ubuntu.com/Kernel/StableReleaseCadence not sure. I never can find things again in wikis...
<Technetium191> so if Trusty is an LTS release is it correct that there won't a major kernel update for it (eg to 3.15 series), only patches to the 3.13 (3.14 ?) series?
<smb> Technetium191, So not sure there is a real schedule. But things from the longterm queue go into the longterm release and from there into master-next of the release and then into master when the next update is prepared. 
<smb> The upload first goes into -proposed and then to -updates (which maybe can be seen best on https://launchpad.net/ubuntu/+source/linux)
<smb> Technetium191, There will be lts backports of newer kernel as part of hardware enablement, but you have to specifically install those. Except when installing from newer point release isos which may have newer kernels
<smb> Technetium191, That might be helpful: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<Technetium191> smb, many thanks, that explains a lot, much appreciated!
<jpds> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1325260 - verified.
<ubot5> Ubuntu bug 1325260 in linux (Ubuntu Trusty) "CompuLab Intense PC2 does not shutdown correctly on 14.04" [Medium,Triaged]
<apw> jpds, i am impressed at your remote fingers 
<jpds> apw: Got someone in the office to install things.
<apw> jpds, ok that is great, it looks like this has been applied to all the stables but 3.13 and i assume that is just timing
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jhenke> hi folks, out of curiosity: what is the meaning of the "kernel-key" tag? Just asking as it got removed from bug 1315921 I reported.
<ubot5> bug 1315921 in linux (Ubuntu) "Ubuntu Studio does not boot in Hyper-V Generation 2 VM" [High,Confirmed] https://launchpad.net/bugs/1315921
<jsalisbury> jhenke, That key is used for reports that the kernel team views.
<jhenke> jsalisbury thanks for the answer
<jsalisbury> np
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 10th, 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.
<infinity> zequence: Also, while I'm annoying you today, you have new lowlatency tracking bugs again.  At least no more quantal now.
<zequence> infinity: Thanks
<infinity> zequence: I think you might have already jumped the gun and done saucy, but probably worth double-checking that it's still correct and matches their upload (maybe an artificial build version bump and including the right tracking bug would bring some sanity to the situation)
<zequence> infinity: ok
<infinity> zequence: By which I mean, keep the changelog intact, and just edit the second half of the version to increment it, and put in the right tracking bug.
<infinity> zequence: (After making sure the rebase doesn't pull in any new bits, etc)
#ubuntu-kernel 2014-06-04
<tyhicks> hello!
<tyhicks> psivaa pointed me to an SRU kernel test failure in one of the security tests
<tyhicks> after looking into it, it really has nothing to do with the security test and is caused by an ipv4 sysctl change
<tyhicks> psivaa opened a bug and I commented on it with what I found
<tyhicks> see bug #1326473
<ubot5> bug 1326473 in linux (Ubuntu) "No /proc/sys/net/ipv4/tcp_syncookies present with 2.6.32-61-generic #123 in -proposed" [Undecided,Incomplete] https://launchpad.net/bugs/1326473
<tyhicks> I assume that someone on the kernel team will take over from here?
<bjf> kamal, can you jump on ^ ?
<apw> how on earth would we lose tcp_syncookies of all things in a stable update
<tyhicks> apw: because a change to another ipv4 sysctl entry ended up causing problems
<tyhicks> apw: I couldn't resist looking into it a little more and gave some more analysis in the bug
 * tyhicks is really done with it now :)
<henrix> tyhicks: yeah, i took a quick look and your analysis makes perfect sense ;)
<henrix> tyhicks: it may be that the *other* stack trace you see is caused by a similar commit... but i'll take a closer look at it after dinner
<tyhicks> henrix: yeah, I was curious about the 2nd trace but didn't look at it
<henrix> tyhicks: there's a similar commit for that sysctl ;)
<tyhicks> aha :)
 * henrix -> dinner
<apw> heh .. 
<henrix> tyhicks: i confirm that reverting lucid commits 2dc19ed6338a27a78c7a9d47d311ae4ac5302c83 and d77028ffe1a3d6eb5f57c5e5ea87cbfc4ee05eb1 make the 2 stack dumps go away ;)
<henrix> tyhicks: also, i can see the /proc/sys/net/ipv4/tcp_syncookies again
<tyhicks> henrix: good to know :)
<henrix> bjf: tyhicks has proposed a (SAUCE?) patch in bug #1326473.  i can give it a quick try or i can start respinning lucid with the 2 reverts (which is more according to the usual policy, i believe)
<ubot5> bug 1326473 in linux (Ubuntu) "No /proc/sys/net/ipv4/tcp_syncookies present with 2.6.32-61-generic #123 in -proposed" [High,Triaged] https://launchpad.net/bugs/1326473
<bjf> henrix, ogasawara is working on it as well
<henrix> bjf: oh, ok
<bjf> henrix, sounds like you are already able to test
<ogasawara> bjf: I say it sounds like henrix is 2 steps ahead of where I am
<ogasawara> bjf: if he's confirmed the reverts, I'd go with that
<bjf> ogasawara, sounds like it to me also
<henrix> ogasawara: bjf: yep, its easily reproducible :)
<ogasawara> henrix: I'm just standing up a lucid install right now to try and reproduce
<ogasawara> henrix: I'll revert the 2 commits and tests here as well for good measure
<henrix> ogasawara: yeah, i had a kvm install so i just upgraded to -proposed 
<ogasawara> bjf: but don't wait for my 2nd set of ack's, go ahead and proceed
<henrix> bjf: ogasawara: so, do you want me to go ahead and respin?
<henrix> (just to make sure we don't dup) :)
<ogasawara> henrix: I'd vote for you to do the respin, only because you be much faster at doing so than I
<ogasawara> I think the last time I looked at Lucid was literally back in 2010
<henrix> ogasawara: heh, ok.  sure :)
<ogasawara> henrix: anyways, sounds like you and bjf have this sorted.  so I'll leave it in the hands of the professionals.
<henrix> ogasawara: ack
<henrix> and thanks ;)
#ubuntu-kernel 2014-06-05
<psivaa> henrix: hey, I'd like to know how to proceed further on bug  1321646. (Just making sure if it's not waiting on us :))
<ubot5> bug 1321646 in Kernel SRU Workflow certification-testing "linux: 2.6.32-61.123 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1321646
<henrix> psivaa: so, the fix has been committed and we will have a respin of that kernel.  brad was working on the respin yesterday
<henrix> psivaa: basically, we're reverting 2 commits from lucid
<psivaa> henrix: ack, so i'll keep watching the tracking bug :). thanks
<henrix> psivaa: yeah, it will be updated soon, once brad uploads the fixed kernel ;)
<psivaa> henrix: ack
<infinity> The fixed kernel is uploaded.
<infinity> psivaa: Do you need them in the archive to re-run your tests, or can you cherry-pick from the PPA?
<psivaa> infinity: our automated tests pick the kernel from -proposed. cherry picking will be really time consuming
<infinity> psivaa: Kay, I can copy it over right now for you to play with.
<psivaa> infinity: ack, thanks
<henrix> infinity: re. bug #1323980: you attached a new patch.  does that mean the bug is not fixed and you want us to respin T with this patch?
<ubot5> bug 1323980 in debian-installer (Ubuntu Utopic) "Enable AHCI config on powerpc/ppc64el" [Undecided,New] https://launchpad.net/bugs/1323980
<psivaa> infinity: the same case is for the ec2 lucid kernel as well, 
<henrix> infinity: or are we still waiting for the bug verification?
<infinity> henrix: bjf declined putting my patch in the current T kernel, we'll get it in next week's.
<infinity> henrix: So, consider it verified enough to release, but not actually fixed until next cycle.
<henrix> infinity: ah, ok.  thanks
<infinity> psivaa: Right, I'll copy the ec2 one over too.
<psivaa> infinity: ack, thx
<infinity> psivaa: Both should hit the archive over the next 30-60m.
<psivaa> infinity: great. thx. i'll run them in 90m
<infinity> psivaa: How long would it take to retest the rest of the world, if I copy all the current respins and ask you to test them all? :P
<psivaa> infinity: all release kernels? if so it may take a couple of days. but i could try to finish it asap. in some cases one test alone takes 4.5 hrs
<infinity> psivaa: Kay, I might pass on that option then.
<psivaa> infinity: ack
<bjf> infinity, it's got to get to ktml first :-)
<infinity> bjf: Bah, no other packages require patches on bugs to go through extra hoops. :P
<bjf> infinity, we set the standard others try to follow
<jodh> I noticed recently that kernel oops's were not getting reported via apport for me. The reason seems to be https://bugs.launchpad.net/ubuntu/+source/kerneloops/+bug/346303. Do we still not care about WARNING: oopses?
<ubot5> Ubuntu bug 346303 in kerneloops (Ubuntu Lucid) "do not generate apport reports for non-critical kernel messages" [Low,Triaged]
<apw> jodh, i don't think i knew about that ... hmmm
<apw> who knows if that is current given the insertion of whoopsie into the mix
<jodh> apw: yeah, quite! I also don't understand why we (and Debian) have such an old version of kerneloops (2009 - latest is 1 Dec 2011).
<jodh> apw: I'm happy to raise an MP to take out that filter from the ubuntu patch?
<jodh> apw: from a userland perspective it would be rather nice if there was something akin to /proc/sys/kernel/core_pattern for oopses to avoid the need to run yet-another-daemon that gropes in dmesg / /var/log/kern.log. However, I'm guessing that that may be frowned on by upstream since the kernel could be in an unknown state on oops and hence potentially impossible to fork an "oops helper"?
<apw> right, that
<apw> though it is not clear it couldn't try at least
<wilhelm1> Is this expert villiage?
<wilhelm1> What do you want a stool sample?
<wilhelm1> Why does it take so long to respond.
<wilhelm1> As if typing in a little password makes an identity.
<wilhelm1> Hey
<wilhelm1> ping
<wilhelm1> ping
<wilhelm1> ping
<wilhelm1> ping
<wilhelm1> ping
<wilhelm1> ping
<wilhelm1> ping
<wilhelm1> What the fuck are these 80,000 users
<wilhelm1> They just sit and idle.
<wilhelm1> Have to call and talk to a cockaroach to get any interaction?
<cking> wilhelm1, stop spamming this channel with insane nonsense, are you on medication?
<sconklin> it looks like someone got a lot closer to the ns cleanup bug: https://bugzilla.kernel.org/show_bug.cgi?id=65191#c13
<ubot5> bugzilla.kernel.org bug 65191 in Netfilter/Iptables "BUG in nf_nat_cleanup_conntrack" [Normal,New]
<sconklin> stgraber: hallyn: ^^
<stgraber> sconklin: oh nice, yeah, that sure sounds like what we've been suspecting was happening (and what my test cases have been trying to stress test, albeit unsuccesfuly)
<hallyn> stgraber: that's the one that's been crashing your builders?
<stgraber> hallyn: no, that's the one arges and I have been trying to reproduce during the sprint, kernel panic when destroying a netns.
<hallyn> ah
<stgraber> I only ever had that one happen on my laptop and only 2-3 times so far (annoyingly)...
<arges> stgraber: yea, sconklin sent this thread : https://github.com/dotcloud/docker/issues/2960 the last comment seems interesting
#ubuntu-kernel 2014-06-06
<mwhudson> is there a guide somewhere for "how to build an ubuntu kernel with this extra patch i want to test"?
<RAOF> mwhudson: I believe so, let me check...
<RAOF> mwhudson: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is a reasonable simple case.
<mwhudson> RAOF: ta
<RAOF> I see I missed your duplicate in #ubuntu-devel :)
<mwhudson> heh
<mwhudson> sorry for multi posting :)
<mwhudson> RAOF: i am now at the point of having to understand the patch i am interested in a bit
<RAOF> Ba baw!
<mwhudson> RAOF: which is not really an ideal place for a sunday afternoon :)
<RAOF> How about a Friday afternoon? :)
<mwhudson> sigh
<mwhudson> i think this makes my point quite nicely though
<apw> henrix, ok i've added some more notes to the CVE matrix, now says where it has reached when pending
 * henrix looks
<henrix> apw: ah, nice! and the lts-trusty row seems to make more sense now :)
<apw> yeah i rammed in some entries for those
<aryan> anyone knows how can I find the root cause for: http://pastebin.com/MHW0raeM
<apw> unregister_netdevice: waiting for ex-xy to become free. Usage count = 3289
<apw> (for those who care to read the pastebin, the relevant error is ^^)
<apw> smb, ^^ that sounds familiar to something i think we talked about some time ... back
<apw> aryan, i would file a bug against linux in the first instance and include the info and any "how to reproduce" info you have
<wmp> hello, how to i can download deb source of 3.14.5 ?
<aryan> apw, thanks
<aryan> apw, the reproduction is a bit tricky. so, I'm not sure how to avoid any trolls after saying that in the bug report
<aryan> same kernel, and same OVS version on another node doesn't produce this issue
<aryan> and the visible differences are: the faulty node has IPv6 enabled and runs tgt
<apw> aryan, ipv6 that feels familiar
<aryan> apw, thanks IPv6 was the issue
<apw> aryan, yeah, now to remember why it feels familiar
<rtg> rsalveti, there are a bunch of Utopic kernels in https://launchpad.net/~canonical-kernel-team/+archive/ppa for you to feed into CI
<ogra_> rtg, he is off this week 
<ogra_> (better ping on monday again ... he will drown in ping backlog=
<ogra_> )
<rtg> ogra_, is he the only person that can drop those kernels into the CI pit ?
<infinity> Oh, right, Ursula's Facebook has been a non-stop barrage of vacation photos of the two of them.
<ogra_> dunno
<ogra_> i guess any lander could ... but i think he is the only one trained on the kernel process for it 
<rtg> ogra_, infinity was hassling me 'cause they keep showing up on his PPA report.
<infinity> rtg: I can live with them being there, I was just curious. :)
<infinity> rtg: There's no urgency from my POV.
<rtg> nor from mine
<ogra_> great ... let it sit til monday/tuesday then 
<ogra_> i dont think there are urgent fixes in them
<ogra_> at least from what i saw on the ML ... config cleanup etc
<rtg> ogra_, yup, nothing critical
#ubuntu-kernel 2014-06-07
<Hauke> Hi is there some way to detect what ubuntu kernel version I am building my module against?
<Hauke> you backported this commit: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commitdiff;h=f4c342cdce8acfaef2d89a800bb6a10128d802c8 and I want to detect that because this is not in mainline 3.13.11
<Hauke> this is for the linux backports project
<Lazik> Greetings all, I am working toward writing a NIC driver for a new chip. Would like to make the effort collective, where is a good place where I could post info and code? I.e.: forum/mailing list thx
<apw> Hauke, hmmm, second person to ask that recently, i am not sure there is, but maybe there should be really
<apw> Hauke, could you file a bug against linux and let us know here the bug number, so i don't forget to think about that
<Hauke> apw: ok will do  that
<Hauke> I asked the same question some days ago
<Hauke> apw: I created a bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1327619
<ubot5> Ubuntu bug 1327619 in linux (Ubuntu) "kernel version detection in module build" [Undecided,New]
<Hauke> it is more a feature request
<apw> Hauke, thanks, yeah we use bugs for those,
#ubuntu-kernel 2014-06-08
<mwhudson> hm
<mwhudson> anyone want to explain how the config works in ubuntu kernel builds?
<TJ-> which bit?
<mwhudson> TJ-: oops, didn't see your reply!
<mwhudson> i think i figure it out anyway
<mwhudson> TJ-: now i'm onto wondering why some modules aren't in the initrd i have
<TJ-> That depends on the initramfs config
<TJ-> There's a setting in "/etc/initramfs-tools/initramfs.conf" "MODULES=" which can be most|netboot|dep|list
<mwhudson> TJ-: ah, thanks
<mwhudson> TJ-: what determines what 'most' means?
<TJ-> mwhudson: I'd suspect, something in the internals of initramfs-tools!
<mwhudson> heh fair enough
<mwhudson> i hope it's not written in perl
<TJ-> mwhudson: actually, no. see "man 5 initramfs.conf"
<mwhudson> "most adds most file system, all ata, sata, scsi and usb drivers."
<mwhudson> i think the fun part here is that the sata/ahci driver for this platform has an undeclared dependency on the ethernet driver
<TJ-> mwhudson: ... "/usr/share/initramfs-tools/hooks/cryptroot:536: if [ "$MODULES" = "most" ]; then"
<TJ-> mwhudson: "/usr/share/initramfs-tools/hook-functions:427:auto_add_modules()"
<mwhudson> TJ-: thanks, am reading that now
<mwhudson> looks like kernel/drivers/net is included in most
<mwhudson> but the driver i need is in kernel/drivers/phy
<mwhudson> hm
<mwhudson> i guess 2215 on a sunday isn't the ideal time to be thinking about this
<TJ-> regular add to "/etc/initramfs-tools/modules" then
<mwhudson> i want this to work in the archive kernel really
<mwhudson> but i guess that means finding the right person to complain at, not trying to do it myself
<mwhudson> eh, not archive kernel precisely, "ubuntu-built images" is more what i actually mean
<soren> mwhudson: Which sata/ahci driver?
<soreau> kees: I'm attempting a kernel bisect today, that's why I ask
<kees> soreau: exciting! if you can replicate with a stock upstream kernel, it may be easier to track things down.
<soreau> kees: What makes you say that?
<soreau> At this point I'm trying to establish a good commit using the instructions here https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<soreau> but it produces 5 deb packages instead of 3. I'm assuming I should still install all of them
<soreau> any tips to speed things up?
<soreau> ah good, turns out it's not a kernel bug
#ubuntu-kernel 2015-06-01
<lag> Hola
<lag> Anyone remember bug 813000 ?
<ubot5> bug 813000 in linux (Ubuntu) "VT6410 IDE/Raid issues" [Undecided,Invalid] https://launchpad.net/bugs/813000
<lag> My father is having issues with it, as he has this RAID controller
<apw> lag, cirtainly cannot remember it, if there was a patch from someone having it attached might help a little
<apw> lag, but it sounds like it is a device that the vendor didn't get fixed upstream, and that makes life hard
<apw> lag, but then you know that :)
<lag> apw: I'd be happy to port and upstream the patch, but need to get hold of it
<lag> apw: Do you know Matt Darcy?
<lag> apw: ikonia
<apw> lag, name doesn't ring a bell no
<apw> lag, i presume you have confirmed it isn't supported by upstream kernels now
<apw> lag, that is an IDE controller ... what on earth is still working with one of those
<apw> it is cheaper to buy a new card than get a drive which will plug into it now-a-days
<apw> trust me i've had to do so recently
<apw> lag, i see they have given up suporting it in windows too
<apw> lag, http://lkml.iu.edu/hypermail/linux/kernel/0502.0/1870.html
<apw> lag, that looks to be the original patch which was perhaps applied to whatever kernel breezy was
<lag> apw: I've just pulled some old Ubuntu kernels to see
<lag> apw: My Father's computer doesn't have native IDE
<lag> apw: And he still has a 500GB disk and a CD-RW in there that he wishes to use
<apw> lag, and that patch looks to be "in" the vivid kernel, so it is something else
<lag> apw: The upstream kernel looks like it has supported the vt6410 since 2008
<lag> apw: 2bfba3c444fe8b2ab1c38112a89d8f03b61136ca
<lag> apw: I've just pulled Trusty to test it
<apw> lag, and before, indeed.  so ... not lack of support me thinks
<lag> apw: I wonder why it wasn't built-in then
<lag> apw: I guess there's only one way to find out
<apw> lag, file a bug and get some diagnostics me thinks
<lag> apw: Or I could get a kernel engineer to check it out ;)
<ePirat> since it seems that I am too stupidâ¦ can someone help me commit bisecting the kernel?
<ePirat> I already know the working and broken version
<diwic> ePirat, if you have a launchpad bug for Linux then maybe jsalisbury can help out
<ePirat> I have, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1444766
<ubot5> Launchpad bug 1444766 in linux (Ubuntu) "Wifi connection issues" [Medium,Incomplete]
#ubuntu-kernel 2015-06-02
<seyeongkim> Hello. I'm trying to request backporting or SRU https://github.com/torvalds/linux/commit/5ef828c4152726f56751c78ea844f08d2b2a4fa3 to ubuntu-precise and trusty using under kernel 3.17, but there is no libxfs directory on ubuntu-precise.. do i need to cherrypick all commits about creating libxfs & moving files from upstream? or making small patch on existing directory structure is ok? or it's unacceptable?
<smb> seyeongkim, for backports into older releases the change should be as small as possible. So if a upstream change can be made on the existing directory structure this would be preferred.
<seyeongkim> thanks smb
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 9th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
<bjf> sforshee, there are two HID: core: patches from Adam Lee on the ML. you added a comment which i've not seen really addressed. can you ack/nak them?
<sforshee> bjf: yeah I'll send a nack
<bjf> sforshee, thanks
<puffi> Is there much risk in downgrading kernel versions in 12.04
<infinity> puffi: Downgrading them to what?
<infinity> puffi: The obvious risks are always reintroducing bugs, both security and stability.
<puffi> infinity: Say going from the most recent stock patch on 3.2 to a previous one, I'm thinking more general issues than specific issue with a previous kernel
<jamespd> I'd like to run a 3.18+ kernel on trusty.  Will there be a vivid backport kernel or some sort of 3.18+ HWE kernel available at some point?
<jamespd> if so, how can I tell when that is likely to happen?
<infinity> jamespd: apt-get install linux-lts-vivid
<infinity> Err, linux-generic-lts-vivid
<jamespd> infinity: wow... not sure how I missed that package...
<jamespd> thanks.
<infinity> jamespd: linux-tools-generic-lts-vivid if you also need the matching tools (perf, etc)
<jamespd> cheers, infinity.
#ubuntu-kernel 2015-06-03
<thoma> Good morning ;-)
<thoma> Someone familiar with Machine Check Exceptions ?
<apw> thoma, there is bound to be someone, if you have specific question do just ask
<thoma> apw: Maybe you remember that we both had already little brainstorming about kernel issues.
<thoma> Before blaming only the kernel I looked for alternative failure sources, e.g. hardware, since I saw kernel panic 2 or 3 times.
<thoma> So I decided to watch what MCE logs - but it looks as if I were too stupid to analyze the mcelogs :-(
<thoma> I would need some help with that ...
<thoma> ... even too find the logs or to specify where to log ;-)
<amitk> thoma: just install and run mcelog to parse and dump the mce logs in human-readable format (or have you done that already?)
<thoma> mcelog should be up and running - but I don't see any output of it :-(
<thoma> Don't even see how to query its status :-(
<amitk> thoma: so there is no exceptions reported
<thoma> As far as I understood there is a buffer that is written each time an exception is detected ?
<thoma> How can I query this buffer ?
<amitk> thoma: man mcelog
<thoma> Would lead me to something like: mcelog /dev/mcelog ?
<thoma> ... assumed a so called "warm reset" after the panic. What is - technically - a "warm reset" unlike a cold reset ?
<apw> a warm reset is a reset from already running, a cold reset is normally the first reset after power on
<apw> in principle some things can be optimised away on a warm reset, though little is
<thoma> apw: If there was no chance for warm reset (each time the system was really unresponsible, means no more input possible to force reboot), will mcelog ever log anything ???
<kenjo> What is the procedure to get the perf tool for a mainline image ?? 
<kenjo> I need the corresponding linux-tools-3.19.0-18 for the mainline version 4.0.4 but its not on the servers.
<thoma> ps
<ubuntu-kernel978> was looking for linux-image-3.13.0-39-generic-dbgsym
<ubuntu-kernel978> can somebody point me to linux-image-3.13.0-39-generic-dbgsym?
<infinity> ubuntu-kernel978: Long gone by now.  Until very recently, we only kept dbgsyms for current versions, and you're seven months out of date.
<ubuntu-kernel978>  is there a way I can build one?
<Krampus> Does the current Ubuntu kernel have the fix for the Haswell Futex bug baked into it?
<ubuntu-kernel978> infinity: is there a way I can build one for the old version of kernel I am using?
<bjf> Krampus, do you have an upstream commit id for the fix? and which series are you interested in? vivid?
<Krampus> bjf: I don't, but it was part of 3.19.  It looks like it's in there, though unless the linux-source package for 3.19.0 in Vivid isn't the one that corresponds to the kernel. :)
<Krampus> bjf: I'm going to grab 4.0.4 from the mainline ppa and see if that makes the problem go away.  I think I have the patch, but it sounds too much like the behavior i'm seeing.
<bjf> Krampus, it should be there
<infinity> ubuntu-kernel978: Not really, given than rebuilding it wouldn't produce a binary identical to what you're running.
<infinity> ubuntu-kernel978: But the real question is, why are you okay with skipping seven months' worth of bugfixes and security updates?
<infinity> ubuntu-kernel978: If you upgrade to the current kernel, and you still have a crash to debug, there are symbols available for that one.
<infinity> s/given than/given that/
#ubuntu-kernel 2015-06-04
<shadeslayer> yo
<shadeslayer> When enabling a module, do you enable each of it's dependencies by hand?
<shadeslayer> because that sounds mental 
<shadeslayer> ( for eg. you want a module B that depends on module A, do you go and enable A by hand to be able to enable B? )
<infinity> shadeslayer: Do you mean in the configs when building a kernel, or when inserting a module into the running kernel?
<shadeslayer> infinity: the former
<shadeslayer> I want to build a config from a tree, but want to alter some things afterwards, and apparently I can't because it's parent deps haven't been enabled, so on and so forth
<infinity> shadeslayer: Are you using a friendly frontend like menuconfig, or just trying to hammer a CONFIG_ in .config and hope for the best?
<shadeslayer> infinity: I've tried the Qt config gui 
<shadeslayer> and it doesn't let me check the boxes
<infinity> Then I guess you've answered your question. :P
<shadeslayer> heh
<shadeslayer> well, is there a way to automatically enable deps :P
<shadeslayer> via make/
<infinity> make oldconfig tries to clean up messes you've made, but it may disable your mess rather than enabling deps.
<infinity> It's not fool-proof.
<apw> shadeslayer, infinity, right it tends to make the config sane which often involves turning things off again, turning things on often involves figuring out the deps slowly and painfully
<teward> Greetings, kernel team.  Trying to hunt down information to try and wrap my head on something.  Someone on Ask Ubuntu posted that they want to get "USB Charging When Powered Off" working.  From Sony's documentation (their system is Sony), there's a way to enable it via Windows power management.  However, when they follow a provided answer to try and enable it on Linux they don't have any luck.  It's my understanding of hardware that this is 
<teward> something handled at the hardware level, not the software level.
<teward> From -devel, a general discussion with dobey suggested that it may be some Sony proprietary stuff from Windows that edits hardware settings, but i'm just trying to cover the bases on this one.  Is it my understanding that such a feature would be BIOS/Hardware controlled rather than something the kernel in Ubuntu could set?
<teward> (https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1461986 was filed on this too)
<ubot5> Launchpad bug 1461986 in linux-lts-utopic (Ubuntu) "can't change usb_charge attribute in /sys/devices/platform/sony-laptop" [Undecided,New]
<catbus1> Hi, is there anything the reporters should provide in order to move forward this bug: 1438039? 
<ubot5> bug 1438039 in linux (Ubuntu) "Ubuntu14.04.1 kernel panics with enic driver throwing a NULL Pointer exception" [High,Triaged] https://launchpad.net/bugs/1438039
<apw> teward, it is hard to know without someone who knows the bios chiming in to say how it is intended to work, as just interfering with the h/w is dangerous if you don't know what it is gonig to do
<apw> catbus1, that bug report seems pretty complete
<catbus1> apw: ok, there hasn't been any activity on that bug since 3/30. 
<apw> catbus1, we get a lot of bugs, finding the ones which are well specified isn't easy
<catbus1> ok
<jsalisbury> catbus1, I'll take a look at that bug.  Are you sure 4cfe878 is the fix for this bug?  
<apw> catbus1, ok i've marked it up so if that fix comes to us via stable we will notice, it _might_ because it is a dave miller one, and he doesn't allow them to be marked for stable so it is impossible to know which he is intending to
<catbus1> jsalisbury: I am not the reporter. Is there any reason why you need confirmation? 
<catbus1> apw: thanks
<catbus1> jsalisbury: I can ask Srini to double check.
<jsalisbury> catbus1, I tried to perform a cherry-pick of that commit and it looks like it will also need 5 other commits backported.
<jsalisbury> catbus1, that commit is in mainline as of 3.17, so Vivid should have it.  
<jsalisbury> catbus1, is it possible to test the vivid backport kernel for trusty?
<catbus1> jsalisbury: Yes, Srini asked me if there is anything they can help testing with. 
<catbus1> you will provide the kernel version and how to enable the vivid hwe kernel in trusty in the bug, as usual, right? 
<jsalisbury> catbus1, correct.  I'll update the bug
<catbus1> jsalisbury: thank you.
<jsalisbury> catbus1, np
#ubuntu-kernel 2015-06-05
<lockman-mac> Jello
<lockman-mac> apw figure out a fix for the kernel compilation yet?
<apw> lockman-mac, not sure to what you are referring ... remind me
<lockman-mac> apw: The kernel compiling instructions on the ubuntu wiki.
<apw> lockman-mac, did i know there was an issue with them ?
<apw> lockman-mac,and point me to the appropriate wiki url which you are using
<teward> apw: in response to your message yesterday that I missed: yes, I agree, messing with the hardware settings within Kernel is definitely dangerous, and my guess is the asker's system isn't supported Linux from Sony
<teward> apw: so i'm tempted to say "Install Windows with the minimum specs, use the tools they say to", etc. but...
<teward> apw: it's DEFINITELY a bad thing to futz around with hardware when one doesn't know what they're truly doing though, agreed there.
#ubuntu-kernel 2015-06-07
<marcone> hello
<marcone> id have a inux question, is this the right place? 
<marcone> my question: i disabled my hdmi output to my tv on boot by a "video=HDMI-A-1:d" in the kernel command line. but i sometimes want to use it. is there a way of enabling it while the system is running?
<marcone_de> ??
<dsmythies> There is a relatively new kernel configurstion parameter, CONFIG_DEVMEM, which for some reason "is not set" for Ubuntu, and therefore demicode does not work. I found this: https://lists.ubuntu.com/archives/kernel-team/2015-May/057250.html and so had expected it to be set to yes by now, but in Kernel 4.1RC6 it still isn't. Does anybody know why?
<apw> dsmythies, i thought we fixed that in the wily kernel, so it should be fixed for mainline builds, which is what i assume you are running
<apw> dsmythies, could you file a bug against linux please asking about it and pointing all that info out, and assign it to "apw"
<apw> dsmythies, and drop the LP# number here please as well
<dsmythies> apw: O.K.
<dsmythies> Note: for unknown reasons I always say demicode when I mean to say dmidecode.
<dsmythies> apw (or anyone esle that is interested): bug 1462822
<ubot5> bug 1462822 in linux (Ubuntu) "Kernel configuration parameter CONFIG_DEVMEM is not set, it should be" [Undecided,New] https://launchpad.net/bugs/1462822
#ubuntu-kernel 2016-06-06
<rtg> cyphermox, should be all the UEFI kernels you need in ppa:canonical-kernel-team/unstable
<cyphermox> ack
<hallyn> hey - apparently during the previous decade quite a few people were doing kernel modules to help find/blacklist bad memory.  Did anything become 'standard' in the ubuntu kernel?
<hallyn> (i.e. badmem, badram, memmap, etc)
<blue_coon> Q1 - Is there a slack channel for Ubuntu kernel dev?
<hallyn> i hope not
<blue_coon> Q2. I'm having a hard time on the ubuntu pages pulling out the simple change log between 3.19.0-25-generic #26~14.04.1 & 3.19.0-33-generic #38~14.04.1
<blue_coon> We have a kernel feature (tc qdisc) that failed on the 0-25 but work on the -33 and are trying to figure out why
<blue_coon> So my first thought was to see if anything was checked in the kernel between those versions
<blue_coon> but I'm struggling to find summary/announce page with the changes. 
<blue_coon> and patches accepted on here http://patchwork.ozlabs.org/project/ubuntu-kernel/list/? stop at 2011
<apw> blue_coon, you probabally want to look at the git repository respresnting the release
<blue_coon> apw: haven't tried git yet
<apw> blue_coon, otherwise any discussion would be on the kernel-team@ list
<apw> and in its archives, though the git repo is more easily understood relative to release tags
<blue_coon> any pointers to the git that would refer to the kernel with the naming I see? is 3.19.0-25 a branch somewhere?
<blue_coon> Just searched for kernel and came up with a bunch of kernel gits on ubuntu git server
<apw> blue_coon, which release are you looking for kernls for
<blue_coon> 14.04.1
<blue_coon> This is from uname on both of them: 3.19.0-25-generic #26~14.04.1 & 3.19.0-33-generic #38~14.04.1
<blue_coon> So i intepret that as linux kernel 3.19 the generic config  on ubuntu 14.04.1. Not entirely sure what the #26 #38 refer to
<rtg> blue_coon, you can decode a tag from thoe version numbers, e.g., Ubuntu-3.19.0-25.26 and Ubuntu-3.19.0-33.38
<apw> so that then is the lts kernel
<rtg> as well as find them in the commit subject
<apw> and is in the trusty repository
<apw> so ubuntu/ubuntu-trusty.git
<blue_coon> Got it. Thx. 
<hallyn> apw: do you know whatever happened to the 'badram' kernel patch?
<apw> hallyn, i do not recall that patch no
<hallyn> drat
<rtg> hallyn, I have vague memories of that patch. What is the last kernel in which it appeared ?
<hallyn> rtg: sigh it's even older thani was thinking - http://www.linuxjournal.com/article/4489?page=0,1  2001 apparently
<hallyn> i'm just looking for something to lock out the bad ram until a new dimm or laptop magically arrives
<rtg> wow, that is kind of a hack
<hallyn> :)
<hallyn> a useful hack
<apw> hallyn, some arches let you say what regions of ram you do have, rather than just a size, not sure if that applied to i386
<mjg59> hallyn: Nothing ever went mainline, but I believe you can pass a kernel command line that excludes a range
<mjg59> hallyn: Ah yeah you can do it with memmap
<mjg59> hallyn: memmap=1M$0xdeadbeef will reserve a megabyte at that address
<hallyn> mjg59: thanks, yeah, i saw a few mentoins of that, wasn't sure (haven't rebooted yet) whether that was mainline or also old, since all mentions are circa 2008 :)
<hallyn> the constant segvs have my mind a bit rattled, so trying to make sense of the memtester reviews :)
<hallyn> uh, s/reviews/output/
<hallyn> well the values reported by memtester change every time
<cyphermox> rtg: the ppa will be missing the linux-meta-lts* packages too I think, since those probably need updating so upgrades work correctly.
<blue_coon> There is no frustration greater than bad memory
<rtg> cyphermox, you can't just install kernels by hand ? as soon as I upload a meta package they'll be out of date as the SRU cadence rolls forward
<cyphermox> of course we can install by hand, but like I said if you want to make sure everything works, you can't just install by hand, you want to pick from the archive + PPA, upgrade, and see that all is well
<cyphermox> I'll just do my own in my PPA
<rtg> cyphermox, hmm, you'll probably run into linux-signed issues as well. dangit.
<apw> rtg, linux-signed issues ?
<rtg> apw, missing packages in the PPA 
<rtg> guess I'd better do those to
<cyphermox> right, kernel ought to be signed by some key; I can enroll the hash afterwards or something
<rtg> cyphermox, alright, gimme a bit
<apw> cyphermox, when the primary packages publish (linux) a key will be generated for the PPA is there is not yet one
<rtg> cyphermox, you'll likely have to sign the kernels by hand (which is what I had to do for testing)
<cyphermox> apw: indeed.
<cyphermox> yeah, or I can extract the signature and add it in MokManager, I think
<cyphermox> hrm, isn't linux-lts-wily supposed to not allow me to load a dkms module?
<cyphermox> I just double-checked, shim validation is active here on trusty, and I install bbswitch-dkms, which loads fine (mentions tainting in dmesg, but is otherwise fine)
<rtg> cyphermox, 'dmesg|grep Secure'
<cyphermox> nothing
<rtg> then secure boot is not enabled
<cyphermox> I'm running 4.2.0-38-generic
<cyphermox> err, it is
<cyphermox> I trust the BIOS more than the kernel on this matter.
<JanC> hallyn: if the location changes, it can also be a memory controller / motherboard issue... (I hope not!)
<rtg> cyphermox, not so far as the kernel is concerned. lemme get my laptop fired up which has those virt instances installed
<cyphermox> ok
<hallyn> JanC: yeah, that's hwy i haven't bought new ram just yet - i'm thinking it might be that. 
<hallyn> for now i juts booted with mem=8G and actually no crashes yet.  will see how that goes through the day
<hallyn> (i was working in an incredibly dusty environment last week - it's possible i can just blow some compressed air around and get it stable again, but doubt it)
<rtg> cyphermox, in fact, gimme until tomorrow and I'll run through all of these packages again and make sure they are right.
<cyphermox> ok
<cyphermox> that was for trusty
<cyphermox> xenial looked good before, but I'm going to get back to it now to re-check everything
<rtg> cyphermox, ok, all of the Trusty linux-meta and linux-signed variants have been upload to ppa:canonical-kernel-team/unstable
<cyphermox> ack
#ubuntu-kernel 2016-06-07
<ali1234> i'm trying to build a kernel with mainline-build-one
<ali1234> it fails with this error: trusty-amd64: chroot not found (::,)
<rtg> cyphermox, everything appears to be correct in ppa:canonical-kernel-team/unstable 
<rtg> (and built)
<cyphermox> ok
<ali1234> i am trying to bisect from v3.17-utopic to v3.18-rc1-utopic
<ali1234> my build system is running trusty
<apw> ali1234, mainline-build-* all assume you have builder chroots available, they are not very smart
<ali1234> okay. well i am trying to follow this wiki page: https://wiki.ubuntu.com/Kernel/KernelBisection
<ali1234> none of the instructions there seem to work
<ali1234> and indeed the links to other pages don't seem to make any sense
<ali1234> it seems like this page is very very out of date
<ali1234> for example "First, follow the KernelTeam/GitKernelBuild  guide to build a new kernel from git.  The step you will be doing the  most is #9. "--append-to-version=-custom" is very important to change to  help differeniate your kernels."
<apw> ali1234, hrm, that would not supprise me, the problem with documents is you stop using them once you know how to do something
<ali1234> if you follow that link, step 9 is "cd .."
<apw> jsalisbury, ^ this is right in your balywick ... you do a lot of bisections
<ali1234> https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter seems to have instructions to create a builder chroot?
<ali1234> seems a little outdated again... the script has a different name now
<ali1234> Error: /usr3/chroots does not exist.
<ali1234> apparently i have to make it... okay
<rtg> ali1234, just create it. 'sudo mkdir -p /usr3/chroots'
<kilbith> hello, silly question : does the current ubuntu kernel (4.4) has backporting of upstream kernel patches (as both kernels are LTS) ?
<apw> kilbith, i assume you are asking does the ubuntu 16.04 kernel recieve upstream stable updates ... to which the answer is yes
<jsalisbury> ali1234, apw, I'll add it to my list to go through those pages, test and update as nessessarry.  
<kilbith> apw, hmmm ok but then the ubuntu kernel versioning ought not be stuck on 4.4.0, which is misleading
<apw> kilbith, that is a complex thing to answer, but the short answer is that that part has to be 3 digit or userspace gets broken, but if we change that a lot it means we cannot hsare the same .orig blowing up the archive side storage requirements
<apw> kilbith, i have a branch pending for Yakkety to drop that .0 from the versioning
<apw> an LTS was not hte place to play with such things
<kilbith> well changing the minor versioning would inform the users at which point the ubuntu kernel is sync with upstream
<rtg> kilbith, but that would be inaccurate since the Ubuntu kernel is never exactly in sync with upstream
<kilbith> "never exactly" <- by how much usually ?
<rtg> kilbith, feel free to do a comparison between Xenial and vanilla 4.4
<kilbith> that's a bit pain with git
<kilbith> #ubuntu-mesa
<kilbith> oops, sorry
<apw> kilbith, the minor version as reported by uname is that version
<apw> kilbith, sorry in /proc/version_signature
<kilbith> oh right - 4.4.8
<kilbith> while upstream is at 4.4.12 already, fyi
<apw> kilbith, yep, though the next kernel which has been in testing for a couiple of weeks is at least 4.4.11
<rtg> and master-next has 4.4.12 applied
<kilbith> well rushing onto new versions is not necessarily a good thing
<apw> right we stage them in as we cut updates in each sru cycle, so whatever is available as we open the cycle is applied
<apw> then we test that for a couple of weeks and then release it
<kilbith> but i'm also surprised why some past ubuntu releases did not choose LTS kernels for example
<kilbith> that makes no sense
<kilbith> *Ubuntu LTS releases, sorry
<apw> kilbith, because we do not control which kernels upstream are LTS and sometimes we have had to chose a kernel and commit to it before upstream has made a choice
<apw> though this time we managed to have that conversation early enough to get the alignment we would desire
<kilbith> i assume you're mainly constrained by the release schedule and you pick the latest kernel whenever a new release is imminent
<kilbith> on the other hand Debian stable always pick a LTS kernel
<apw> kilbith, not quite true, they are using a kernel we maintained stable on for a long time
<apw> kilbith, for one of their releases
<apw> but in general we are not looking to be doing our own work if we can be aligned, sometimes that is not possible in an LTS, this time it was
<kilbith> hmm, i just checked on distrowatch and indeed all debian stable and oldstable kernels are LTS
<kilbith> http://distrowatch.com/table.php?distribution=debian
<apw> kilbith, jessie is on 3.16 which was not an official LTS kernel, that we in ubuntu supported for several years, and now debian themselves are supporting it
<kilbith> ah ok, i get it
<apw> kilbith, alignement is not always possible for them or us, though that time we were at least aligned between them and us
<kilbith> that's surprising since they have more developers for maintaining
<ali1234> i think i'm getting a bit closer. now i get: trusty-amd64: chroot not found ( chroot:utopic-amd64 ::Available chroots: utopic-amd64,)
<ali1234> hmm... it wants a trusty chroot?
<ali1234> okay... whatevs
<ali1234> now i get: I: You do not have permission to access the schroot service.
<ali1234> am i supposed to run this with sudo or what?
<apw> ali1234, you prolly have to give yourslef permission, likely you got added to the schroot group but have not logged out/in since
<ali1234> i wasn't added
<ali1234> think it will help if i add myself?
<ali1234> schroot isn't even a group
<rtg> ali1234, I think you need to be in the sbuild group
<ali1234> nope, still doesn't work
<ali1234> E: default: Chroot not found
<rtg> ali1234, ah, that is different. what is in /etc/schroot/chroot.d/ ?
<ali1234> a file for each of the chroots i have made using make_chroot
<ali1234> trusty-amd64, trusty-i386 and utopic-amd64
<ali1234> so i tried to run "schroot trusty-amd64" and got that error
<rtg> schroot -c trusty-amd64 ?
<ali1234> ah there we go, it works!
<ali1234> and it's building a kernel finally. thanks :)
#ubuntu-kernel 2016-06-08
<mamarley> apw: I just tried the 4.6.2 mainline kernel and it boots now (yay!), but ACPI CPU frequency scaling doesn't work.  I filed a bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1590371
<ubot5> Launchpad bug 1590371 in linux (Ubuntu) "ACPI CPU frequency scaling does not work with the 4.6.0-7.8 config and up" [Undecided,New]
<rtg> cyphermox, have you encountered any UEFI issues with the kernels in ppa:canonical-kernel-team/unstable ?
<apw> rtg, bug: #1590371 might (though mainline was tested) indicate an issue with your 4.6/7 config
<ubot5> bug 1590371 in linux (Ubuntu) "ACPI CPU frequency scaling does not work with the 4.6.0-7.8 config and up" [Undecided,Incomplete] https://launchpad.net/bugs/1590371
<rtg> apw, there has to be a better way then building in those drivers
<apw> rtg, yeah i know your feeling
<mamarley> Indeed, though the bug report is still valid.  (I was able to work around the issue by modprobing cpufreq_ondemand and then manually changing governors.)
<mamarley> Also, that only affects my one system that is too old to use the intel_pstate driver, which works fine.
<apw> mamarley, yep he wasn't saying the bug was invalid, that reverting the change which likely introduced it might not be the best soln.
<mamarley> Agreed.
<rtg> perhaps /etc/init.d/ondemand could do the modprobe
<apw> rtg, but we only need it if acpi supports it right?  shouldn't it be autoloadable with acpi anyhow ?
<rtg> apw, not sure. these CPU frequency governors are also built for arches that don't have ACPI (like armhf)
<mamarley> I do know that those governors do nothing with intel_pstate.
<rtg> bug #1584124 has interesting info in that regard
<ubot5> bug 1584124 in systemd (Ubuntu) "revisit /etc/init.d/ondemand" [Wishlist,Fix committed] https://launchpad.net/bugs/1584124
<cyphermox> rtg: not done verifying, have you?
<cyphermox> rtg: everything is already in place for xenial, or do you still have something to land as kernel there? there isn't a xenial kernel in the PPA
<rtg> cyphermox, xenial in the archive is feature complete wrt UEFI and MOK
<cyphermox> ack
<mowthegrass> Hi 
<mowthegrass> Anyone out there to help me with boot issues 
<mowthegrass> My Ubuntu 14.04 doesnt boot with 3.16.0-67 Kernel , But the same machine is able to boot from the latest kernel 
<mowthegrass> Booting from 3.16.0-67 kernel freezes with the below error 
<mowthegrass> [    2.402903] random: lvm urandom read with 61 bits of entropy available
<mowthegrass> random: Non blocking pool initialzed 
<mowthegrass> booting to recovery , just drops me to initramfs "Gave up waiting for root device" 
<mowthegrass> I have updated the ramfs of the all the kernels by booting to latest kernel 
<mowthegrass> anyone have any pointers on where the issue could be 
<mowthegrass> appreciate your time and help 
<apw> "latest kernel"?
<mowthegrass> 4.2.0-36
<mowthegrass> issues seem to be strange 
<ali1234> jsalisbury/anyone else: here are my notes on bisection: http://paste.ubuntu.com/17126664/
<mjg59> apw: Any idea what the status of https://launchpadlibrarian.net/149319334/overlayfs_inotify.patch was?
<apw> mjg59, that is a good question ... i've not rebased that for ages, i really should
<mjg59> apw: Was anyone working on pushing that upstream? It's something that seems to be biting a bunch of docker users (and we've got customers complaining, so I do have somewhat selfish reasons to be interested)
<apw> mjg59, i will try and get that rebased 
<mjg59> apw: Sweet. Let me know if I can help in any way
#ubuntu-kernel 2016-06-09
<mcphail> jsalisbury: re https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574102 - I'm away just now but will test this next week. Just to let you know I'm not ignoring it ;)
<ubot5> Launchpad bug 1574102 in linux (Ubuntu Yakkety) "Regression (constant vibration of device) in xpad driver in Ubuntu 16.04" [Medium,In progress]
<jsalisbury> mcphail, ack, thanks.
<mcphail> jsalisbury: thanks for your time to do this
<jsalisbury> mcphail, no problem.
<gpiccoli> I'm not sure if I should ask this here, but maybe somebody can enlight me. Have you ever seen this message on Ubuntu?
<gpiccoli> "System is booting up. See pam_nologin(8)"
<gpiccoli> Ideas on what's going on? Thanks in advance, any pointer would be much appreciated
#ubuntu-kernel 2016-06-10
<tjaalton> 4.4.0-24.43 isn't tagged yet but already in updates?
<apw> tjaalton, that would be an error, it is cirtainly tagged
<apw> tjaalton, and my git repo says it is pushed
<apw> tjaalton, though of course it is "off" the mainline because it is an emergency kernel
<apw> tjaalton, so you need some git fetch --tags action
<smb> apw, though that only gets me to -22
<tjaalton> ah
<tjaalton> yep fetch --tags shows it
<apw> smb, that only gets you master at -22
<apw> smb, it also gets you tags for -24
<smb> apw, right both
<apw> which is the new norm, that master only gets the latest released kerenl
<apw> tjaalton, thats a limitation in the way git fetches tags, they are only automatically offered if a head you fetch points at them
<smb> apw, oh darn. nm I fell victim to rmadisons sort order
<smb> though xenial-updates semms to be -24
<apw> smb, yeah they are actually in sort order
<apw> smb, right, but also kamal has not yet merged back all the security updates, there being 40 odd packages to sort
<apw> smb, so master is behind, but ... i did make sure the tags were pushed
<tjaalton> apw: right, none of the current branches have that tag so it wasn't fetched
<bdrung_work> hi apw. can you "share" launchpad bug #1233466 with your "friends"?
<ubot5> Launchpad bug 1233466 in linux (Ubuntu) "Hot-Add Memory failing for lack of udev rule" [Medium,Triaged] https://launchpad.net/bugs/1233466
<bdrung_work> ;)
<pitti> bdrung_work, apw: so I have some objection to adding a rule like SUBSYSTEM=="cpu", ACTION=="add", DEVPATH=="/devices/system/cpu/cpu[0-9]*", TEST=="online", ATTR{online}="1"
<pitti> this is just plain stupid
<pitti> we woudl unconditinoally change a kernel default in userspace
<pitti> if we actually want this, then this shuold just *be* the default
<bdrung_work> udev upstream has the same opinion: https://bugs.freedesktop.org/show_bug.cgi?id=78478
<ubot5> Freedesktop bug 78478 in general "Please add CPU and memory hotplug udev rules" [Normal,Resolved: notourbug]
<pitti> so IMHO this is a case of "change the kernel default", not "set default A here and B there"
<pitti> (I have no strong objection for doing this as an SRU, just for devel)
<apw> i am going to guess that upstream kernel will say exactly the same thing in inverse
<apw> that adding memeory at the h/w level does not mean it is time to add it to the kernel pool
<pitti> well, that's not a contradictory argument
<apw> that that is a userspace decision, and therefore an administrator decision
<pitti> I wasn't saying that the above behaviour is desirable/right
<pitti> just that an unconditional rule doesn't make sense
<pitti> we currently have this conditionalized only on Hyper-V (or some MS thing)
<apw> i concur completely with that indeed
<apw> this feels like a sprint kind of thing, with a handy sprint
<pitti> so if the kernel's opinion is that hotplugged CPUs should not immediately be used, then we shoudln't add that udev rule either
<pitti> I mean, obviously people stuff CPUs into machines because.. they don't want to use them :)
<pitti> (j/k, there might be good reasons)
<pitti> apw: sprint> so that we can improve our arguing by throwing candy around, clearly!
<apw> yeah, in a real machine i can see you don't want it till you are ready, there might be risk involved
 * pitti is looking forward to next week, I'm starting to get seriously under-hopped
<pitti> ("hop'ed"? "hoped"?)
<pitti> apw: ah, so maybe we might want to limit that to VMs only?
 * bdrung_work nods. Not onlinening CPU and RAM in a virtual machine make no sense.
<pitti> well, for that we'd first need to understand why it wouldn't make sense on a real machine
<apw> in a VM you are almost cirtainely want it now and instantly
<apw> well there is risk that those new cpus are not good, tehy are real and /w
<apw> h/w so ... they may go in without incident but you migt pick a quiet time to online them
<apw> maybe
<pitti> ok
<pitti> so then I like https://launchpadlibrarian.net/264002433/0001-Enable-CPU-and-RAM-hotplug-on-QEMU.patch better than https://launchpadlibrarian.net/264364580/0001-Enable-CPU-and-RAM-hotplug-on-QEMU.patch
<apw> then again opening the box is risky too, so ... its all a bit pants
<bdrung_work> if you risk hotplugging a real CPU, you probably want to risk onlining it at the same time.
<apw> its the probabally part, so it needs to be at least controllable
<xnox> apw, libseccomp is crazy
<apw> xnox, most likley, it _is_ designed by security people
<xnox> apw, so "kernel" fixed the crazy __PNR numbers for x32/i386/x86_64
<xnox> yet libseccomp looses it's mind between name - positive integer - fake numbers
<xnox> doesn't round trip them
<xnox> and expects accept4 & 364 to result in different filtering results... which are the same syscall in new world order
<xnox> https://github.com/seccomp/libseccomp/pull/41 & https://github.com/seccomp/libseccomp/issues/40
<apw> sounds like you ahve a whole heap of fun to deal with
<xnox> i wonder if i'll just backout sync to "v4.5 syscall table"
<xnox> or e.g. i need v4.5 kernel.....
<apw> its not at all clear how that works in the real world, moving calls around the syscall
<apw> table, sounds like an abi violation
<jtaylor> hi, I lost sound with the -24 xenial kernel update, the -22 my old one still works, is this already known?
<apw> jtaylor, not that i am aware of
<jtaylor> hm I'll file a bug then
<jtaylor> I guess ubuntu-bug linux will put in all necessary logs?
<ali1234> there's one specifically for sound
<ali1234> "ubuntu-bug audio"
<jtaylor> k thanks, rebooting back to the broken kernel
<jtaylor> weird now its working again, so nevermind I guess
<apw> jtaylor, oddness
#ubuntu-kernel 2016-06-11
<fossterer> Hi! I have touchpad issues when using Ubuntu 16.04 on  	HP ENVY Notebook - 15t-q400 CTO. Is this the right to place bring up a discussion?
<apw> fossterer, i would file a bug against the kernel "ubuntu-bug linux" and write down all the details there.  do report the bug number here though
<fossterer> Thanks @akw
<fossterer> I'm checking if anyone else too is having the issue
#ubuntu-kernel 2016-06-12
<sonicabt> Hi, I installed ubuntu 16.04 on my Asus Vivobook E200HA, and the kernel does not recognise microsd card slot and sound card. How can I solve this issue?
#ubuntu-kernel 2017-06-05
<apw> hallyn, that is most odd .. it almost implies that we don't ahve a config option so its switching stubs
<apw> which should not happen
<hallyn> apw: not us, centos :)
<luis30> hi 17.04 had a bug that has been effecting it since it came out...https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1691146...it had a project relaase date to come out of proposed to be released for todays date...anyone have any information on it
<ubot5> Ubuntu bug 1691146 in Kernel SRU Workflow "linux: 4.10.0-22.24 -proposed tracker" [Medium,In progress]
#ubuntu-kernel 2017-06-06
<manjo> smb, ping.. there were a couple of iommu related patches that I had submitted for SRU (two separate patch series) .. I think I have satisfied the regression testing requests also.. could you guys please review those? 
<manjo> smb, these are on the critical path for cert .. and feature requests that came from multiple vendors
<smb> manjo, maybe (I don't want to make promises as there were many things and little time)
<manjo> smb, 1680549	[Zesty] QDF2400 ARM64 server - NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s!
<manjo> smb 1688158	[SRU][Zesty] Support SMMU passthrough using the default domain
<manjo> smb, the 1st one is critical for the QDF2400 platfrom to function correctly without softlockups 
<manjo> smb, and the 2nd one is feature that both QDF2400 and thunder-x platform is requesting 
<manjo> smb, and I have a couple more in the pipe line that are cert blockers for QDF2400 that I will submit shortly 
<smb> manjo, I know exactly which ones you are asking about. And both were in a sense risky as they pull in very recent changes which also touch the generic or x86 parts of iommu. And I had not yet time to look back there
<manjo> smb, sure.. just putting it in your ear .. so that it does not fall thro the cracks
<manjo> smb, and I agree the 2nd one has more risks than the 1st one.. I have done testing and posted test results to the bug reports in comments
<smb> manjo, ack, we will give it some consideration. As said, I just don't want to make any promises for things we cannot guarantee
<manjo> smb, ok I get that.. thanks for looking into those 
#ubuntu-kernel 2017-06-07
<mamarley> apw: It looks like all of today's kernel mainline builds have failed.
<apw> mamarley, not all at least
<mamarley> 4.11.4 and 4.9.31 definitely did.
<mamarley> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11.4/
<apw> mamarley, those two are space issues, odd
<apw> mamarley, not sure why that happened as the machine (now) is all happy, so resubmitted the two which look to be space
<mamarley> apw: Cool, thanks!
<apw> mamarley, a few others have broke beacuse they have what look like invalid circular module deps
<mamarley> apw: Looks like it ran out of disk space again. :(
<apw> mamarley, ok that makes literally no sens
<steven> not the right channel I know but #ubuntu is not really helpful :D any of you guys have a hint on how to debug dpkg when its stuck at setting something up? it doesnt have a verbose flag so it just "freezes" until I manually abort it. command dpkg --configure -a that is
<apw> steven, hmmm, what package ??
<steven> apw: already figured it out, fanks for pinging back tho. it was weird. I installed docker-ce (from dockers own repo) and the post install failed because some device mapping
<steven> hence dpkg just froze
<steven> devicemapper: Can't set task name /dev/mapper/docker-... had to run dmsetup mknodes to fix it
<steven> gotta be honest tho, no idea what it does but it worked
<apw> steven, ack, good
#ubuntu-kernel 2017-06-09
<manjo> smb, I had submitted SRU for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1696143 [SRU][Zesty] qcom_emac is unable to get ip address with at803x phy driver. June 6th. Just putting this in your ear.. could someone from ukt review and consider this patch?
<ubot5> Ubuntu bug 1696143 in linux (Ubuntu) "[SRU][Zesty] qcom_emac is unable to get ip address with at803x phy driver." [Critical,Incomplete]
<manjo> smb, patch is pretty straightfwd.. and applicable only to QDF2400 platform
<leftyfb> hi manjo :)
<manjo> leftyfb, hello! 
<leftyfb> how's power doin? :)
<manjo> power is getting there .. going well 
<leftyfb> that's good
<leftyfb> was a bit frustrating leaving behind unfinished business
<manjo> leftyfb, yeah I think there are a lot of hands on deck to handle it now 
<leftyfb> really? that's good. It needed more people
<manjo> and my touch
<leftyfb> oh of course ;)
#ubuntu-kernel 2017-06-10
<zxliu> where is the channel for old versions?
<zxliu> looks like my attorney stole the bootsector 
<zxliu> is there some way to rekey the kernel cryptography?
<zxliu> went to do a backup of the boot part and the thing took the first time writing somewhere unknown so I set it again to write to a known location and it complains wrong client version
<zxliu> so the suspect is whoever wrote the live CD has all network connection running on t13 lines
<zxliu> my guess is it is the quantum attorney 
<zxliu> so now whatever secure boot was written into it has been handed over too the t13 project
<zxliu> and ever since the t13 project they have been coding things against me
<zxliu> death threats
<zxliu> disappearing possessions
<zxliu> I.e. vanishing
<zxliu> then the attorney stopped responding and some military capture me dressed up like cops
<zxliu> and they started sicking clowns from the past on me called "family"
<zxliu> you know those strangers that claim some special attachment as an excuse to get in the way I.e. call police
<zxliu> so the apparent home raids continue after say 10 yeard
<zxliu> is there any way to resexute any boot time cryptography
<zxliu> where is the channel for old versions?
<zxliu> the old zeitgeist is still running presumably
<zxliu> before the attorney started stealing everything 
<zxliu> not to add blame specific only toward attorney
<zxliu> hot means hot
<zxliu> that apex anomoly
<zxliu> where an adversary always fills the shoes 
<zxliu> justification for saying they
<zxliu> any that be ready to fill enemy boots
<zxliu> problem with attorney is the legal responsibility of not being an enemy
<zxliu> in that position the attorney does unique injury when not exceptional
<zxliu> same problem with a wife
<zxliu> unique injury
<zxliu> this is why wrath is held back
<zxliu> meet ADAM
<zxliu> social justice comes only after correcting unique injury
<zxliu> yes _Ruben?
#ubuntu-kernel 2018-06-04
<apw> jeremy32 (N,BFTL), that is a simple addition of an id, so likley it would; it is also marked for stable
#ubuntu-kernel 2018-06-07
<tomreyn> sa_ in #ubuntu may be interested in establishing / strengthening formal contact regarding better qualcomm driver support
<apw> tomreyn, ack thanks
<tomreyn> welcome
<pepsiman> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396654 is closed, but is still an issue in bionic.  Should I open a new bug?
<ubot5> Ubuntu bug 1396654 in linux (Ubuntu Xenial) "C++ demangling support missing from perf" [Medium,Incomplete]
<pepsiman> https://launchpadlibrarian.net/371624784/buildlog_ubuntu-bionic-amd64.linux_4.15.0-23.25_BUILDING.txt.gz says Makefile.config:690: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling
#ubuntu-kernel 2018-06-08
<sylvainc__> Hello, I have errors booting BTRFS rootfs on Ubunut 16.04 LTS system since linux-image-4.4.0-127-generic update linux-image-4.4.0-124-generic boot without problems, the BTRFS rootfs partition is clean (checked with a livecd), the problem appear mainly on sevral laptop computers, I want to know if you have some pointer about this kind of problem befor I fill a bug report.
<sylvainc__> For details I get a kernel panic with error "not syncing: VFS unable to mount root fs on unknown-block(0,0)" when hidden grub boot occurs, but if I enter grub then boot no error occurs.
<sylvainc__> I'have done many test with grub reinstall, but linux-image-4.4.0-124-generic boot well in all cases, but linux-image-4.4.0-127-generic doesn't, Thanks for your pointer or help.
<apw> sylvainc__, it is not at all clear how the kernel would even know if you hit return or grub did it for you
<apw> sylvainc__, i think we need a bug filed, and could you get a 'dpkg -l | grep linux-' output attached to the bug
<sylvainc__> apw, thanks for your answer, I agree, it's pretty disturbing, I will try to do some tests before report the bug (if necessary)
<apw> sylvainc__, the message implies the kernel is not finding the initramfs which would be grub's fault often
<apw> but quite how it does that different for an auto select of 127 as against it picking 127 by default
<apw> it beyond me at the moment
<sylvainc__> apw, thanks no wories, I will try to find more elements by doing more tests about this issue
<cascardo> adding your grub cnfig files to the bug could help
<sylvainc__> cascardo, ok thanks i will add it
<apw> sylvainc__, and let us know the bug number here in case
<sylvainc__> apw, ok, I will continue to work on this issue because I need to understand it, but i must leave now, thanks for your help again
<apw> sylvainc__, np
<jeremy31> Ubuntu 18.04 killed my bluetooth and it seems that the upstream fix from https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/bluetooth?id=803cdb8ce584198cd45825822910cac7de6378cb works for everyone
<jeremy31> Ubuntu bug link https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1764645
<ubot5> Ubuntu bug 1764645 in linux (Ubuntu Bionic) "Bluetooth not working" [Medium,Confirmed]
#ubuntu-kernel 2019-06-04
<ricotz> hello, I am wondering if there are problems regarding rolling out kernel updates? afaics disco kernel is still based on 5.0.8 while the current upstream maintenance release is at 5.0.21
<TJ-> Has anyone heard of invisible memory-leak issues due to PCIE-AER faults? I'm helping a user that has a system that 'eats' 5GB of RAM in a day invisibly, and the only real clue is they need "pci=noaer" to avoid logs being overwhelmed with AER reports. I've asked them to remove noaer to find out what the reports are, but wondering if with it disabled the kernel could be using up memory collecting the
<TJ-> reports even when they're not logged
#ubuntu-kernel 2019-06-05
<derjohn> Hi, is there anyone aldready working on fixing the PPA builds?  "eoan-amd64: chroot not found ( chroot:bionic-amd64" seems to block all architecture kernel builds. Or do I need to report it?
<cjwatson> derjohn: Do you have a link to a failure?
<cjwatson> Not sure from that whether it's an infrastructure-level problem or something specific to kernel builds
<mamarley> cjwatson: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.1.7/
<cjwatson> Oh right, "PPA"
<cjwatson> Not my problem then :-)
<cjwatson> apw: ^- maybe?
<apw> derjohn, you need to report it, to me
<derjohn> apw THX ! The current kernel don't build, see https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.1.7/ (as cjwatson already showed). 
<derjohn> apw, Should I report it on launchpad or so? if so, which package !?!?
<apw> derjohn, count it reported
<TJ-> Has anyone heard of invisible memory-leak issues due to PCIE-AER faults? I'm helping a user that has a system that 'eats' 5GB of RAM in a day invisibly, and the only real clue is they need "pci=noaer" to avoid logs being overwhelmed with AER reports. I've asked them to remove noaer to find out what the reports are, but wondering if with it disabled the kernel could be using up memory collecting the
<TJ-> reports even when they're not logged.
<derjohn> apw, :thumbs: yeah ! Good to know. I has always struggles to find the right place to report .... I am using the kernels in out production relatively early ....
<apw> derjohn, not that using those i production is a very good idead; but hey
<TJ-> Also, I was checking on CONFIG_DEBUG_KMEMLEAK but we seem to have CONFIG_HAVE_DEBUG_KMEMLEAK=y but there is /no/ kernel code relying on that, and the actual setting is: "# CONFIG_DEBUG_KMEMLEAK is not set"
<apw> sforshee, ^
<apw> TJ-, not heard of anything like the aer thing, but if there was going to be a bug in freeing an incoming message like that it would be when turning them off from teh command line which noone would do
<sforshee> TJ-: enabling CONFIG_DEBUG_KMEMLEAK adds overhead to memory allocations, it seems to me that this is the sort of thing a developer turns on to debug memory leaks and not an option for a distro kernel to enable
<TJ-> apw: right, user has pci=noaer but the system is losing memory rapidly (6GB overnight). I'm getitng them to create a bug. Apparently Windows 10 doesn't have this problem, so I think we have a problem in the PCI sub-system somewhere (Windows isn't losing memory or reporting AERs at least)
<apw> TJ-, and not reporting them might involve recieving them and dumping them immediatly
<TJ-> sforshee: I know, my point is that in looking at what we have that set to I found "debian.master/config/config.common.ubuntu:CONFIG_HAVE_DEBUG_KMEMLEAK=y" but there is nothing in-kernel I can find that uses that
<sforshee> TJ-: those HAVE_FOO sorts of options are generally things which are set to make another option available for selection
<sforshee> so if your arch or whatever doesn't set CONFIG_HAVE_DEBUG_KMEMLEAK then you won't be presented with the CONFIG_DEBUG_KMEMLEAK option
<TJ-> apw: That's what I would imagine; it's a weird one here, but the only clue does seem to be these AERs (all measures of memory usage just seem to indicate memory is 'used' but cannot account anywhere for it. I had the user just boot to multi-user.target overnight, and in the morning it had eaten memory :)
<TJ-> sforshee: right, but my point is I cannot find anything but the config file itself testing that value
<apw> testing the HAVE_ version ?
<apw> that would be right
<sforshee> TJ-: that's exactly the point. The architecture selects HAVE_FOO, then if it's set you get prompted whether or not to set the CONFIG_FOO option
<sforshee> only CONFIG_FOO affects the code that's built, HAVE_FOO just controls whether or not you get the chance to select CONFIG_FOO
<TJ-> what I mean is, there's nothing like "drivers/net/dsa/Kconfig:        depends on HAVE_NET_DSA" , no "depends on HAVE_DEBUG_KMEMLEAK" which confused me :)
<TJ-> sorry for going on a tagent; this only came up because it confused me as to the state of KMEMLEAK :)
<sforshee> TJ-: lib/Kconfig.debug
<sforshee> config DEBUG_KMEMLEAK
<sforshee>     depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
<TJ-> sforshee: doh! thank-you, I need to sleep more and work overnight less! I was doing "git grep CONFGI_HAVE_DEBUG_KMEMLEAK" !! Sorry
<sforshee> no worries, happens to all of us
<TJ-> sforshee: anyhow, upshot is, we'll need to build a custom kernel with DEBUG_KMEMLEAK enabled so the user can grab more info on this
<TJ-> I'm having them check the windows event-logs to see if it is receiving AERs as well; if it is it isn't suffering vanishing memory
<derjohn> apw, Thx for fixing the PPA  builds!
<TJ-> Any chance of getting this ACPI ID added to enable a touchpad? Bug #1831710
<ubot5> bug 1831710 in linux-signed-hwe (Ubuntu) "Touchpad not working (Lenevo Ideapad 330 series)" [Undecided,New] https://launchpad.net/bugs/1831710
#ubuntu-kernel 2019-06-06
<apw> derjohn_was_occu: np
<TJ-> what's the best way to make a single CONFIG_ change for a kernel build? add/edit it in debian.master/config/config.common.ubuntu or set the policy in debian.master/config/annotations ?
<dupondje> No reports today of crashes? Since latest kernel update I already had 2 crashes
<nacc> hiya! it seems like the src:linux and src:linux-meta packages in bionic-security and bionic-updates are out of sync
<nacc> 4.15.0-51.55 for src:linux and 4.15.0-51.53 in src:linux-meta
<nacc> vorlon: sorry for the direct poke on this, but not sure who to contact (it seems sil2100 did the updates) for the above, but it's breaking some of our preseeds all of a suddent :)
<apw> nacc, ?
<apw> are you saying that they are in sync in those pockets but out of sync across pockets, or out of sync in a pocket
<apw> nacc, no neither, they are in sync in both directions ... you are incorrectly assuming the linux and linux-meta packages have versions in sync
<apw> nacc, they only match in the first four octets
<nacc> apw: oh! i'm very sorry for the noise then!
<apw> nacc, np ... the meta package mearly defines the abi in use; both packages have indepenent upload numbers after that
<apw> nacc, so we have clearly messed up the main package twice more than the meta
<nacc> apw: lol ok
#ubuntu-kernel 2019-06-07
<dupondje> general protection failt: 0000 [#1] SMP PTI
<dupondje> RIP: 0010:deactivate_slabe.isra.75+0x10d/0x4d0
<dupondje> Nobody else seems this since latest kernel update on disco?
<apw> dupondje, i've not seen any reports of it now, you should report it
<apw> (as if for nothing else, we have 50 kernels now and we have no idea which one you are running)
<dupondje> Linux lt-jeanlouis 5.0.0-16-generic #17-Ubuntu SMP Wed May 15 10:52:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
<dupondje> anyway, I report :)
<dupondje> just my 'screenshot' is a picture :D (was the only way as it was totally frozen)
<TJ-> I'm doing a PPA upload of ubuntu-cosmic and getting build-failures due to missing abi symbols right at the end of the build from the dpkg tooling - I know those ABI symbols need to be there, but *how* is one supposed to create them in the source package that is uploaded to PPA?
<TJ-> could be get this rtlwifi commit cherry-picked into the releases? nasty kernel memory leak uses up all memory inside a day (failing to free a sk_buf) Bug #1831751
<ubot5> bug 1831751 in linux (Ubuntu) "rtlwifi: aggresive memory leak" [Undecided,Confirmed] https://launchpad.net/bugs/1831751
<smb> TJ-, The easy way would be not to start a new section in the changelog (debian.master/) but to modify the existing with a '+mybuild1'. If you do not care seeing all old changes in the changes
<smb> TJ-, or rename debian.master/abi/<someversion> into <theversion which is now the previous version>
<TJ-> smb: thank you, I'll try that :)
#ubuntu-kernel 2019-06-09
<mamarley> apw: It looks like something is hosed with the mainline builds for 5.2.  For -rc4, the build succeeded, but the patch list and patch files are missing: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2-rc4/
