#ubuntu-kernel 2005-07-04
<fabbione> morning
<chmj> morning 
<fabbione> hey chmj 
<chmj> fabbione: any crack ? 
<fabbione> chmj: ?
<chmj> fabbione: non-userland todo, that I can handle ? 
<fabbione> chmj: fix all the bugs in bugzilla
<chmj> fabbione: heh, ok 
<fabbione> there is stuff but it's not easy and it needs you to build on all arches
<fabbione> if you can do some bug triage it would be very good
<chmj> ok 
<chmj> I'll have a look 
<fabbione> cool
<fabbione> GO DPATCH !
<fabbione> IT'S YOUR BIRTHDAY!
<chmj> fabbione: ?
<fabbione> chmj: they changed dpatch-edit in the last version
<fabbione> it can't be used for kernel anymore
<chmj> oh 
<fabbione> OMFG!
<fabbione> 3 copies of the same source to make a PATCH!
<chmj> oh my 
<fabbione> dpatch-edit-patch: * Copying /usr/src/wartydevel/kernel/breezy/linux-source-2.6.12-2.6.12 to reference directory.
<fabbione> dpatch-edit-patch: * Copying reference directory /usr/src/dpatchtemp/dpep-ref.8xrjTj/linux-source-2.6.12-2.6.12 to work directory.
<fabbione> + the original
<fabbione> for one patch
<fabbione> hmmm there is a solution...
<fabbione> that's cleaning how we handle 00list
* fabbione thinks
<fabbione> this debian/rules is a mess
<fabbione> thom: ping?
<thom> fabbione: hi
<fabbione> hey thom
<fabbione> thom: 34.3 release.. do you mind to commit to baz the work you have done?
<fabbione> both in pre34.3 and tags..
<thom> ack, sorry
<fabbione> thom: no problem :)
<fabbione> i need to look at the patches.. since somebody is claiming regressions on i386?
<thom> don't see how, since they both only touch code under arch/x86_64
<fabbione> i know :)
<thom> * committed kernel-team@ubuntu.com--2005/kernel-debian--pre34,3--2.6.10--patch-2
<fabbione> danke
<thom> oh, and:
<thom> * creating version kernel-team@ubuntu.com--2005/kernel-debian--mainline-2,6,10-34,3--0
<fabbione> cool
<fabbione> did you also merge in mainline?
<thom> eh? i branched the pre to the mainline
<fabbione>       kernel-debian--mainline--2.6.10
<fabbione> yes lamont did an extra branch were we merge the releases...
<fabbione> basically the flow is:
<fabbione> pre merge's into kernel-debian--mainline--2.6.10
<fabbione> kernel-debian--mainline--2.6.10 branch to tag and to new pre
<fabbione> but any combination of the above is valid :)
<fabbione> don't ask me why lamont did it this way :)
<fabbione> i was VAC when they started using baz :P
<thom> how amazingly fucking weird
<fabbione> probably it helps baz to find the best merge point
<fabbione> not sure tho
<fabbione> i had that kind of issues before
<zul> heylo
<jbailey> zul: Slacking off at the new job already?
* jbailey hides.
* zul smacks jbailey
<zul> god this connection sucks
<zul> they are suppose to be putting fiber in the building this week
<jbailey> fiber gives you the runs.
<jbailey> err..
<jbailey> makes you run faster.
<zul> meh..
<zul> b.c boy...how was the drive back to toronto
<jbailey> uneventful.
<jbailey> We detoured through the diefenbunked, back to Ottawa for food and then drove here.
<zul> cool...ill be gong to diefenbunker one day
<jbailey> The drive was pretty even the whole way.  Carlos and Kristine were geocaching, so we stopped pretty frequently.
<jbailey> It's a hella-cool trip.
<jbailey> If I come up to OLS with Angie, perhaps you can join us.
<Lathiat> hehe geocaching
<zul> sure..i dont think that would be a problem..
* jbailey blinks
<jbailey> Ingen slik fil eller filkatalog
<jbailey> I'm guessing that's norweigian.
* jbailey sets his LANG variable.
<Mithrandir> jbailey: yeah, it is.
<Mithrandir> "No such file or directory"
<zul> hey lamont
<lamont> morning zul 
<fabbione> hey zul
<zul> hey fabbione how goes it/
<fabbione> zul: good.. i am relaxing..
<fabbione> tomorrow I need to do a lot of cleanup in the kernel
<zul> good...did you finish your gardening?
<fabbione> our debian/rules isn't exatly happy with the latest dpatch
<fabbione> zul: no...
<fabbione> that will never end ;)
<zul> heh...i know
<zul> what did you break now? ;)
<fabbione> i didn't break anything
<zul> sure sure :)
<fabbione> it's the way dpatch-edit works that is changed
<fabbione> and it makes problem with the patch order
<zul> frig
#ubuntu-kernel 2005-07-05
<fabbione> morning
<lamont> g'night
<jbailey> g'm all
<fabbione> hey jbailey 
<JaneW> hi jbailey
<fabbione> we found the sparc kernel problem!
<fabbione> look at your inbox ;)
<jbailey> Nice catch.  That's... not where I would've expected the problem to be. =)
<jbailey> JaneW: Doing some kernel hacking today? =)
<JaneW> jbailey: yeah ;)
<jbailey> Excellent!
<JaneW> heh
<fabbione> jbailey: i think i started tickling BenC again :)
<fabbione> this time it was him searching for me ;)
<jbailey> Cool.
<jbailey> I'm trying to figure out if I'm brave enough to ask him for decent sparc hardware.
<jbailey> He mentioned before he knew some people at sun who might sponsor such things.
<fabbione> just do it
<fabbione> if so ask for me too :)
<fabbione> or i can ask for both of us
<fabbione> (he is idle now)
<jbailey> Sure. =)
<jbailey> Oy, Fabio.  Is 2.6.13 goes gold in the next week, are you bumping, or are you sticking with 2.6.12 for sure?
<fabbione> we still have a few days for UVF
<fabbione> but i doubt it will go gold that fast
<fabbione> i saw too many patches going in -git for .13 to be gold in less than a month
<jbailey> Hmm, getting the new udev in before UVF will be fun.  *sigh*
<jbailey> Heya Chuck.
<zul> Hey Jeff how goes it?
<jbailey> I'm doing very well.
<zul> good
<jbailey> Et tu?
<zul> good...kind of hot though
<jbailey> Yeah, I suspect we'll need to add A/C to our list of appliances to buy in Montral.
<jbailey> This move is getting expensive.
<zul> hehe..
<jbailey> What's it like in the big O?
<zul> the stadium? never been there..;)
<zul> right now...since its canada day tomorrow its pretty quiet
<jbailey> I should get to Ottawa for Canada day one time.  Maybe next year.
<jbailey> I imagine the train from Montral to Ottawa should be cheap.
<zul> tomorrow downtown its going to be crazy so most naturalized residents avoid it :)
<jbailey> A wild outgoing guy like you?  I'd have expected to see you swinging naked from the trees...
* jbailey hides.
<zul> hmmm...yeah...bastard
<zul> i done all the wild stuff when i was a kid
<fabbione> hey zul
<zul> hey fabbione 
<zul> grrr
<zul> hmmm...gentoo has a speakup patch for 2.6.12
* TheMuso must check out CVS.
<TheMuso> I believe someone at Gentoo was helping the primary author of Speakup work on it.
<zul> yeah he was
<TheMuso> Last I checked, the new code wasn't in CVS yet.
<TheMuso> And it looks like CVS access is down atm.
<TheMuso> Argh. Stuff that.
* TheMuso goes hunting for the speakup patch in his local Gentoo Portage mirror.
<TheMuso> s/local/nearest/
<TheMuso> zul: Where did you find it?
<zul> dev.gentoo.org/~dsd
<TheMuso> Tah.
* TheMuso seems to be going round in circles.
<TheMuso> zul: Have you tried it yet?
<zul> nope...going to try this weekend when im not working
<TheMuso> Fair enough. Downloading vanilla kernel now to see if they patch against it. Then I will try a breezy kernel.
<TheMuso> BTW I have written a modules file to go in the d-i/$arch subdirs for creating a speakup-modules udeb if you are interested.
<jbailey> fabbione: Did Ben ever reply?
<jbailey> Or did my name sink it into a black hole? =)
<fabbione> jbailey: the latter...
<zul> mental note...mozilla sucks
<dilinger> always has, always will
<jbailey> ANyone object if my summer of code student does his firewall work in this channel?
<chmj> firewall work ?
<jbailey> Yeah, he's tackling the firewall bounty.
<jbailey> I find ubuntu-devel too noisy to get much done in, so if the kernel folks here find it relevent enough, I'd like him to work in here.
<chmj> I don't object :)
<Mithrandir> can we throw mentos at him (or her)?
<jbailey> (or trans)
<jbailey> I assume so.
<jbailey> Wouldn't it be discrimination not to?
<jbailey> I was told to make the student feel part of the community. =)
<Mithrandir> yay!
* Mithrandir loads up a big mentos cluster
<jbailey> (s)he*'s in .de, so you won't even have to correct that much for accurate use of a trebuchet.
<chmj> hehehe
<zul> i prefer cricket bats
<zul> anyone know of a good oog vorbis player?
<jbailey> xmms?
<zul> it can do oog?
<dilinger> oog?
<dilinger> you mean ogg?
<zul> yeah
<zul> php is blowing my brain
<jbailey> Yes, xmms does ogg
<dilinger> you might find better results if you apt-cache search for ogg instead of oog :P
<zul> :P
<dilinger> xmms, totem, xine, gstreamer, muine, rhythmbox..
<zul> im on suse
<Mithrandir> you might want to switch the type of crack you're smoking too, since it appears to affect your brain so much.
<dilinger> i'd recommend anything gst or xine based
* jbailey wishes gst would either work or die.
<jbailey> This half baked state on !i386 just kills me. 
<Mithrandir> I wish concordia had a -fullturbo switch.
<dilinger> jbailey: you should start hacking it for !i386
<dilinger> when i had my tibook, i used to fix endian issues in gst
<dilinger> but now i don't have any !i386 desktop hardware
<dilinger> if only someone would send me some ppc64 stuff..
* dilinger coughs
<Mithrandir> amd64s are cheap
<dilinger> Mithrandir: i suppose
<jbailey> Mithrandir: They're still ~500CAD
<Mithrandir> jbailey: I just love it when people throw their random currency-of-the-day at me.  :P
<Mithrandir> what's that in some sensible currency?
<jbailey> About the same as AUD. =)
<jbailey> A little higher than the number would be in EUR, about twice would it would be in GBP
<Mithrandir> for a full system?
* dilinger showers Mithrandir with sucres
<Mithrandir> heh
<Mithrandir> I wish the dualcores would become a tad less expensive.
<jbailey> No, that's for mobo, cpu and ram.
* jbailey shuts down for a scheduled power outage.
<Mithrandir> it's more like 350-ish AUD here.
<jbailey> fabbione: I need to figure out which modules to load into the initrd.
<jbailey> err, initramfs
<jbailey> the best heuristic that I've seen so far gives me 30 megs of modules, which seems a bit excessive.
<fabbione> eh?
<jbailey> Do you have a recommendation?  Should I just make a list of the modules that are there in 2.6.12 and add more if people bitch that some are missing?
<fabbione> jbailey: can you send me this list so we can look at it together?
<fabbione> adding 13MB of modules is like adding all the kernel or almost
<jbailey> The kernel includes 67 megs of modules.
<fabbione> brb... i need a nature break and we can look at it :)
<fabbione> re
<jbailey> Should I /msg you the list of the directories I'm copying now, or paste it here for general consumption?
<fabbione> jbailey: past in here the main dirs..
<fabbione> no need of the single module detail
<jbailey>         copy_modules_dir kernel/drivers/net
<jbailey>         copy_modules_dir kernel/drivers/scsi
<jbailey>         copy_modules_dir kernel/drivers/ide
<jbailey>         copy_modules_dir kernel/drivers/md
<jbailey>         copy_modules_dir kernel/drivers/usb
<jbailey>         copy_modules_dir kernel/drivers/block
<jbailey>         copy_modules_dir kernel/drivers/input
<jbailey>         copy_modules_dir kernel/fs/ext2
<jbailey>         copy_modules_dir kernel/fs/ext3
<jbailey>         copy_modules_dir kernel/fs/isofs
<jbailey>         copy_modules_dir kernel/fs/jbd
<jbailey>         copy_modules_dir kernel/fs/jfs
<jbailey>         copy_modules_dir kernel/fs/nfs
<jbailey>         copy_modules_dir kernel/fs/reiserfs
<jbailey>         copy_modules_dir kernel/fs/xfs
<jbailey> Because that doesn't catch all of the dependancies, I then do a further check to make sure I get all the dependancies of the following modules:
<jbailey>         for x in mbcache nfs af_packet raid1 ide-cd ide-disk ide-generic; do
<fabbione> mbcache is used only by ext2/ext3
<zul> meh...i think im going to knock off early today
<jbailey> zul: slacker.
<zul> shut it
<zul> later
* jbailey ties zul down so that his 'it' can be shut..
<jbailey> Doh, missed him.
<jbailey> fabbione: What I'm wondering is if the whole lot of it should be a list of drivers that get included by default in the initramfs rather than this method.
<jbailey> This brings in all the ARCnet crap, slip, etc, etc...
<jbailey> Just piles of stuff that I"m failure convinced aren't needed.
<fabbione> yes.. we need a more fine graned list
<jbailey> Shall I make a wiki page with a list that we can prune down or add to?
<fabbione> and we can look at kernel-wedge algo to calculate dependencies and pull in modules as required
<fabbione> jbailey: iirc you asked me to create the initramfs directly from the kernel package
<fabbione> i suggest we start to work out directly how to do it and add the list in baz
<jbailey> Yup, I'd like that eventually.
<jbailey> For now I thought we could start the list here since I already have module deps taken care of.
<jbailey> THen transfer the magic over to the kernel.
<jbailey> My package has the nice side effect so far that it's not in heavy use.
<fabbione> well let's do it directly into the kernel.. there is only a month or so for feature freeze
<fabbione> and these kind of changes are expensive to do
<fabbione> jbailey: just remember to set your umask properly on rookery if you commit to baz directly :)
<fabbione> (and i don't mind you to do so)
#ubuntu-kernel 2005-07-06
<fabbione> morning
<lamont> morning fabbione 
<lamont> 2.6.12 kernel from breezy is trying to build on hppa, btw.
<lamont> I figure another 2 hours or so and it'll have an answer
<fabbione> lamont: cool
<fabbione> it might fail creating udebs
<fabbione> all the last changes i did to it were quite complex
<fabbione> if it fails can you please put the log somewhere?
<lamont> it's actually on a machine that I won't have access to until later... (at the office)
<fabbione> oh sure.. i am not going to play with the kernel until monday anyway
<fabbione> i really need to do something different once in a while
<fabbione> and i am working on partman-auto-lvm
<fabbione> the sparc buildd's are idling :)
* fabbione does the universe give-back of death
<fabbione> most of the FTBFS are due to stuff that needs X love or bootstrapping..
<fabbione> lamont: did you finish to setup logs@ with elmo?
<fabbione> uh let's fix OO2 FTBFS
<lamont> fabbione: it looks like logs@is pretty close - I'll try to be up early tomorrow morning to finish it with him.
<fabbione> why is it so complex?
<fabbione> it tought it was a couple of .procmail rules to change
<lamont> fwiw, I'm on holiday tomorrow, have someone delivering furniture sometime (which I need to prepare for), and heading off for friday/sat to colsprings
<fabbione> oh net :)
<fabbione> nea
<fabbione> ARGH
<fabbione> neat
<karlheg> jbailey, Hello.
<karlheg> jbailey, About to pull the update.
<karlheg> bzr error message: error: docs/example_hook is already versioned
<karlheg> I wonder if I sent everything, or what?
<karlheg> I don't understand what the .moved files are.
<lamont> fabbione: either I have line-length issues (shouldn't) - but may well, or something lin hppa's linux-source-2.6.12 upload is new.
<lamont> (it built successfully)
<lamont> hrm... I'm betting I have line length issues on that machine...
<fabbione> no
<fabbione> it's mostlikely one of the new udebs
<fabbione> i am pretty sure it's in the big changelog of death
<fabbione> but i need to go out now.. 
<fabbione> if you can't find it i will look at it
<lamont> fabbione: actually, I'm 99% certain I didn't fix take the steps needed to prevent the line-length issues there...  so there may be new udebs, but I doubt it ever got uploaded
* lamont tries to decide if he cares about linux-source-2.6.10 for hppa...
#ubuntu-kernel 2005-07-07
<desrt> fabbione; more linux-headers issues
<fabbione> desrt: i am sure as soon as i will fix the first issue, all the others will be in a chain 
<desrt> fabbione; ya.  i imagine so :)
#ubuntu-kernel 2005-07-08
<zul> heylo
<crimsun> yes?
#ubuntu-kernel 2005-07-09
<fabbione> hey crimsun 
<fabbione> hey chmj 
<fabbione> crimsun: happy with alsa 1.0.9 in the kernel?
<crimsun> hey fabbione :)
<chmj> hey fabbione 
<chmj> hey crimsun 
<crimsun> hi chmj!
<crimsun> fabbione, it's loads better than 1.0.6 =)
<fabbione> good :)
<crimsun> :) Thanks for updating.
<fabbione> no problem.. hopefully :)
<crimsun> :)
<zul> hey
<fabbione> hey zul
<fabbione> your server is down?
<fabbione> i couldn't sync from baz
<zul> dont worry about it..nothing in there, i didnt do anything this week
<fabbione> yeah, but i can't merge nothing if the server is down
<fabbione> not even l-n-s-m
<zul> gimme a sec..
<fabbione> take your time...
<fabbione> i am going to merge tomorrow anyway... i burned the morning now :/
<zul> hehe
<zul> should be good now
<zul> back to php...yay!
<fabbione> ahha
<fabbione> thx
<zul> noprobs i been slacking off this week but ill be back for preX,4
<fabbione> no rush dude
<fabbione> hey JaneW 
<fabbione> i was just thinking about you
<fabbione> i need a name ;)
<fabbione>   The "Jane's flying back home" release.
<fabbione> was going in very soon ;)
<JaneW> fabbione: heh
<chmj> hey JaneW 
<JaneW> hey chmj
* JaneW is here with kids ;)
<JaneW> fabbione: Obtuse Oats
<fabbione> JaneW: thanks.. done :)
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,3--2.6.12 | 3.3 uploaded. no new branches until tomorrow.
<zul> yay...i made my first commit to the product at work...
<fabbione> eheh
<fabbione> how much did you break?
<zul> at first? a couple of things..:)
<chmj> and then ?
<zul> and then...a couple of more things  until i beated it into submission
<fabbione> ehehhe
<zul> kind of like what i do for ubuntu stuff
<fabbione> ok.. i am off for today
<fabbione> cya tomorrow guys
<zul> toodles
<HiddenWolf> Does anyone here know if the lirc modules are inside the ubuntu kernel?
<HiddenWolf> crimsun, do you know?
<`crimsun> erm, I have no context, so forgive me if I don't know what you're asking
<HiddenWolf> I was asking if the lirc modules should be in the ubuntu kernel.
<`crimsun> for Warty, Hoary, or Breezy?
<HiddenWolf> Hoary
<HiddenWolf> I'll upgrade to Breezy if they're there tho. :)
<`crimsun> I see nothing in amd64's generic config on Hoary that leads me to believe they're included
<HiddenWolf> Would it be a problem to include them?
<HiddenWolf> at least in breezy?
<`crimsun> well, they won't go into Hoary since it's frozen
* HiddenWolf just got a remote, and isn't a big fan of kernel recompiles
<`crimsun> what version are you looking at?
<`crimsun> note that there's version 0.7.0.1-1ubuntu1 of lirc-modules-source in hoary/universe
<HiddenWolf> I haven't installed those yet.
<`crimsun> you should be able to compile it if you have build-essential, module-assistant, and linux-headers-$(uname -r) installed
<`crimsun> you don't need to recompile the kernel to add lirc support. Just compile the kernel modules externally using the above method.
<HiddenWolf> yeah, that's my piont. I don't enjoy installing all that build-etc stuff. :(
<`crimsun> if you have additional questions, let's move this to #ubuntu
<HiddenWolf> my question was, would it be possible to consider it to build them by default?
<`crimsun> if you can verify they'll build using just those config changes in the current one, I think it's possible. It's not my call, however.
<`crimsun> make sure you read the topic here.
<HiddenWolf> crimsun, so if I decide to build them, can you give me a step by step rundown? haven't done a build in years...
* HiddenWolf switches to #ubuntu
<HiddenWolf> Can I beg anyone's help here? :S
#ubuntu-kernel 2005-07-10
<fabbione> morning
<ogra> fabbione, ping
<fabbione> ogra: pong?
<ogra> looks like i have to run a firewall on the ltsp server for edubuntu :-/ do we have any uml capable kernel image ?
<fabbione> no
<ogra> or do you think xen will be alternatively ready for breezy 
<fabbione> probably...
<ogra> i thought about a chroot jail, but that wont help for a firewall
<fabbione> xen is up for google atm
<ogra> s i'll need a extra vm...
<ogra> s/s/so
<fabbione> and how do you think xen/uml will help you?
<fabbione> what is exactly the problem
<ogra> dont i run a independent kernel instance with them ?
<fabbione> yes, but what is the problem you need to address exactly
<ogra> i dont want to run the FW on the server directly.... if i set netfilter option in a chroot they will affect the host too, or am i wrong ?
<fabbione> wrong
<fabbione> xen or uml won't help you at all
<ogra> oh... i though it would...
<fabbione> i don't understand why do you want to run netfilter in a chroot...
<fabbione> netfilter or iptables is kernel stuff
<fabbione> you want to run it as soon as possible
<ogra> to have it separated from the server.... its a school environment.. so if someone hacks the FW he shouldnt have any access to the server processes....
<fabbione> does need to run on the same machine?
<ogra> but mark requires me to run both on one machine
<ogra> yes
<ogra> :/
<fabbione> amen
<fabbione> let me think one second
<fabbione> how many network cards do you have?
<ogra> two i guess
<ogra> i could make 3 a requirement if that helps...
<fabbione> i am thinking :)
<ogra> :)
<fabbione> 2 are enough....
<fabbione> and you can use xen
<ogra> great :) 
<fabbione> but the setup is NOT tricky
<ogra> you mentor it, right ? 
<fabbione> i am mentoring xen, but only for the packaging
<fabbione> not for these kind of weird setups :)
<ogra> i have to make only one default setup... its unlikely that anybody will touch it... the firts edubuntu shall be a out of the box solution
<ogra> but additional HW is a "no go" :/
<fabbione> i am not 100% sure 2 cards are enough tho
<ogra> can you use aliases across the kernel/xen envionments ?
<ogra> (alias interfaces that is)
<fabbione> the problem i think is:
<fabbione> (or are)
<fabbione> - FW needs 2 interfaces
<ogra> yep
<fabbione> - Server needs one interface
* fabbione attempts to think...
<fabbione> are there any users allowed to login on the server other than the admin?
<ogra> nope...
<fabbione> probably.. what you can do is:
<ogra> all users are locked in the ltsp envionment... only the NFS roots are accessible
<fabbione> btw.. do you know how xen works?
<ogra> nope
<fabbione> or do i need to explain?
<fabbione> ok
<fabbione> basically it works this way..
<ogra> its a additional VM as far as i understood it
<fabbione> - you boot the real machine with a kernel called dom0
<fabbione> such a kernel is the one that access the real hw
<fabbione> and it exports it via an internal backplane to the guests
<fabbione> - each guest boots its own kernel called domU
<fabbione> that access virtual disks/net interfaces via the backplane
<ogra> ok, so i'll need two guests then.. 1. ltsp server 2. firewall...
<fabbione> yes.. but the problem is how to share the hw
<fabbione> because a FW needs 2 interfaces
<ogra> i'm fine with a 3 netcard requirement...
<fabbione> the server needs one (real to run dhcp)
<fabbione> the FW needs at least one real
<fabbione> probably...
<fabbione> what you can do is:
<fabbione> run the host without real cards
<fabbione> configure the guests to run a dom0 kernel and use one virtual interface towards the host and one real card towards the world
<fabbione> at that point...
<fabbione> the FW real card goes towards internet
<fabbione> the FW virtual interface towards the host
<fabbione> the host will bridge with the Server 
<fabbione> (they will feel like on the same LAN
<fabbione> s/feel/look)
<fabbione> the Server uses the virtual interface towards the host to talk with the firewall
<ogra> hmm, so i could even build a little DMZ ? sounds cool
<fabbione> ogra: exactly
<ogra> wow, xen is cool
<fabbione> the DMZ will be a virtual lan running inside the host
<fabbione> the real interface of the server will go towards the internal lan
<fabbione> now what i am afraid of is:
<fabbione> - how to partition the hw so that iface X is associate with xen guest X
<fabbione> (i know it can be done, but i never tried it)
<fabbione> - you will need a spectacular amount of netfilters running on FW, host and Server
<ogra> its my job to find hat out... :)
<fabbione> - access to the host for admin purpose might be a problem if server goes down
<fabbione> ogra: in any case.. do you realize that with this setup:
<fabbione> a) you are going to lose performance on each single "machine"
<fabbione> b) you triplicate the amount of maintainance (if not more)
<ogra> hum.... thats not good
<fabbione> c) you will still need to run netfilter/iptables on all 3 the machines?
<ogra> thats no problem
<fabbione> xen adds overhead.. in many directions
<fabbione> i can't think of anything simpler with that requirements
<ogra> performance loss is very bad for ltsp....
<fabbione> but imho... if you just use something like:
<fabbione> iptables -t filter -F INPUT
<fabbione> iptables -t filter -P INPUT DROP
<fabbione> iptables -t filter -A INPUT -j ACCEPT -d 192.168.2.6 -m state --state ESTABLISHE
<fabbione> D,RELATED
<fabbione> you basically closed the machine from the outside
<fabbione> and you can still navigate from the inside
<fabbione> that rule (or a similar one) will just close *
<ogra> yep
<fabbione> imho all the xen mess is not worth...
<fabbione> but well...
<ogra> my main concern is to run both on one HW... since the FW has to do transparent proxying....
<fabbione> you will also need to test the above setup...
<fabbione> yeah but transparent proxy is not an issue
<fabbione> you still don't need to listen with services on the outside interface
<ogra> yep...
<ogra> but from the inside i need a GW to put the content filter on... having both on one machine hurts my stomach
<fabbione> ok.. but my question is.. is it only your stomach or a specific requirement for the specs?
<ogra> but your explanation shows that xen/uml seems not to be a good way around if i loose performance
<fabbione> you lose performance..
<fabbione> you are adding:
<ogra> the requirement is to have transparent proxing for parental control without having additional HW
<fabbione> - vm overhead
<fabbione> - 2 extra hops in the network
<ogra> i dont care about extra hops
<fabbione> - removing memory (due to partitioning) from one server
<ogra> thats the worst
<fabbione> - using the internal backplane to share hw
<fabbione> i mean.. the backplane is fast
<fabbione> but it is still overhead
<fabbione> and the main issue is the RAM really
<ogra> loosing memory in a ltsp environment is a vry bad thing
<ogra> every byte is speed there
<fabbione> the issue is that xen needs to know how much ram you assign to each domain
<fabbione> (including the host)
<fabbione> the host doesn't need much
<ogra> a FW probably doesnt need mor the 64MB either
<ogra> more then
<fabbione> like 256MB would do
<fabbione> the FW at least 128MB
<fabbione> the Server all the rest
<ogra> heh... the server will be somewhere in the GB area..... 4GB are common
<fabbione> + an extra 64Mb hidden by xen management
<ogra> (for a 20-30 client setup)
<fabbione> you know that our kernel needs to be recompiled on x86 machines with more than 4GB?
<fabbione> anyway..
<fabbione> you will still need to test that all the above will ever work
<ogra> i think we dont have mainboards yet that support moe then 4GB on single x86, do we ?
<fabbione> probably not on home pc
<ogra> yes, i know ...
<fabbione> i am pretty sure they do on servers
<ogra> hmm, 32bit on a single CPU can handle more then 4GB ?
<ogra> i didnt know that
<fabbione> in terms of disk space.. the FW/HOST don't need more than 1G each
<fabbione> the rest can go to server
<ogra> disk space is cheap and not an issue 
<fabbione> ogra: there is an option to extend that to 64GB
<ogra> woah...
<fabbione> but it's disabled because it adds overhead
<fabbione> the limit for a single process is still 4GB
<ogra> might becoman an option for edubuntu.... 
<ogra> become an
<fabbione> yes, that means an extra edubuntu kernel :)
<fabbione> ( i need a smoke.. brb )
<ogra> it could be that i need a own kernel anyway... finally you got me in the kernel usiness then :)
<fabbione> ahah welcome to pleasure of pain
<ogra> heh
<chmj> and suffering 
<zul> hola
<chmj> fabbione: do you know if concordia is down ?
<fabbione> chmj: nope.. i didn't login since yesterday
<fabbione> hey zul
<chmj> seems to be 
<fabbione> concordia.ubuntu.com [82.211.81.168]  22 (ssh) : No route to host
<fabbione> it is
<fabbione> hey jbailey 
<fabbione> hey JaneW 
<JaneW> hi fabbione
<jbailey> Heya Fabio
<jbailey> I guess this means the move was successful.
<jbailey> 'net just got installed.
<jbailey> Now I just need to buy a fridge and stove..
<fabbione> cool
<fabbione> congratulation
<fabbione> see i have an extra fridge here....
<fabbione> and an extra stove
<fabbione> jbailey: you moved to the wrong place
* ogra sees JaneW around... does this meen we get a new nutty kernel again ?
<ogra> mean even
<JaneW> ogra: hi - I am at a conf, but just found wireless access, so I couldn;t resist hopping on...
<ogra> hehe
<ogra> addicted
<zul> welcome to waa...wirleess addicts annoymous
<ogra> heh
<JaneW> zul: thanks ;)
<fabbione> ehhe
<jbailey> fabbione: Well, whether it's right or it's wrong, I'm sure as hell not doing that again soon.
<fabbione> ahhaha
<fabbione> jbailey: i did it so many times that i don't even want to think to move
<fabbione> if not for the tax rates :)
<jbailey> This is the first time that I've moved a whole house to another province.
<jbailey> When we moved to Toronto we got rid of all of our stuff first.
<fabbione> eh...
<fabbione> i still have some stuff in italy
<fabbione> sooner or later i will need to rent a little truck and do the ride again
<fabbione> 2400KM brrrr....
<fabbione> actually a bit more..
<fabbione> but well
<jbailey> Ouch.
<fabbione> around that line
<jbailey> This was at least only like 600-700km
<fabbione> jbailey: when i moved to dk, i loaded my father's car and drove alone for 2 days....
<jbailey> And sais hi. =)
<fabbione> jbailey: basically the passenger seat had 4 bags with all the normal life stuff
<jbailey> Angie, rather.
<fabbione> the rest was computer equipment :)
<fabbione> hi Angie!
<jbailey> *lol*
<fabbione> it took me around 24 hours of pure driving
<jbailey> I have to go back to Toronto this month to pick up my SGI, my Alpha and my Itanium.
<jbailey> There just wasn't room.
<fabbione> + i got lost on the german motorway
<fabbione> that added another good hour
* jbailey blinks
<jbailey> Is Germany between Italy and Denmark?
<fabbione> yeah as well as swiss/austria
<fabbione> italy -> {swiss,austria} -> germany -> dk
<fabbione> i got lost after the austria's border line
<fabbione> because the indication sucked
<fabbione> and ended up in the wrong direction
<ogra> fabbione, you cant get lost on german motorways, thats a rumor ;)
<ogra> *g*
<fabbione> ogra: not when you pretend to have a city called "Aschufart" that's not on any of the maps
<ogra> lol
* ogra wipes the laughing tears from his eyes....
<fabbione> ogra: only in germany you write "exit" at the motorway exit, instead of the name of the place it takes you
<ogra> Ausfahrt is german for exit.... :)
<fabbione> so it took me a little while to realize that there can't be a city called "exit" longer than 50km
<ogra> heh
<ogra> but at least you saw something of germany despite the motorway :)
<fabbione> yeah an extra gas station
<chmj> fabbione: ping 
<fabbione> chmj: yes?
<chmj> problems 
<chmj> hold on, I'm uploading dmesg output
<chmj> fabbione: ipw2100 failed after I dist-upgraded 
<chmj> http://people.ubuntu.com/~charles/dmesglog
<chmj> erm, I can't execute anything from bash, just hangs the kernel 
<fabbione> chmj: known bug..
<fabbione> fix upstream.. kthxbye
<chmj> hmmm 
<zul> jbailey: if you want you can leave your SGI, Alpha, and Itanium in ottawa ;)
<fabbione> but given that you have an ipw2100, you can test a kernel for me
<fabbione> when i will have the time to do a test build :)
<chmj> ok, for some reason, every process ends with this : Killed by signal 1.
<chmj> on this kernel : Linux darklord 2.6.10-5-386 #1 Tue Apr 5 12:12:40 UTC 2005 i686 GNU/Linux
<chmj> this is all after dist-upgrade 
<fabbione> that's only ssh
<fabbione> not every process
<fabbione> known bug that one too
<fabbione> oh
<fabbione> no
<fabbione> hmmmm
<fabbione> i am not sure you can actually use .10 in breezy anymore
<chmj> oh yes, scp + ssh 
<fabbione> are you sure it's all processes?
<fabbione> ah ok
<fabbione> tsk
<fabbione> as above.. ssh problem
<chmj> I use .10 on breezy, works better than .12 :( 
<chmj> .12 just hangs :( 
<fabbione> chmj: you are part of the kernel-team.. testing/patches/bugfixes are welcome ;)
<fabbione> chmj: it hangs only on ipw2100...
<fabbione> that is yet another piece of external crap that apparently lusers can't live without
<fabbione> thansk god it's going upstream
<fabbione> so it will break less
<fabbione> and be more obsoleted faster
<fabbione> but at least i have an excuse for not updating it
<chmj> hmm, problem with tesing/patching is that I have very limited resources 
<chmj> will do some triage though 
<fabbione> chmj: we know what the problem is
<fabbione> and if upstream doesn't fix it, i can only workaround it
<fabbione> basically the ipw2100 and ipw2200 drivers share a set of common modules
<fabbione> the ieee8something
<fabbione> and the code is maintained duplicated! in both repos
<fabbione> with the last upgrade of the drivers they went out of sync
<fabbione> so the ieee code that's from the ipw2200 works for the latter
<fabbione> but not for the ipw2100
<zul> muhahaha
<fabbione> if i take the code from the ipw2100 it will break ipw2200
<fabbione> so there is only one untested solution
<chmj> oh my 
<fabbione> remove this common code
<fabbione> and compile it all static into the respective ipw2x00 modules
<fabbione> in the hope that it works
<fabbione> and you will test that kernel for me :)
<chmj> ok :) 
<chmj> eta ?
<fabbione> but it's not very high priority...
<fabbione> probably one or two days
<fabbione> i have userland work to finish
<chmj> noted 
<chmj> http://bugzilla.ubuntu.com/show_bug.cgi?id=12417 this just came in 
<fabbione> tought luck... it's still the same ieee layer causing problems
<fabbione> i am off for today
<fabbione> cya tomorrow guys
<chmj> enjoy 
<zul> arrgh!!!
<fabbione> hey lamont
<lamont__> howdy
<zul> meh...dont know what to do
<fabbione> zul: are you bored?
<fabbione> fix some more bugs :)
<zul> still debating
<zul> fabbione: ill fix some tonight
<fabbione> don't trash too much :P
<zul> ill try not to :P
<fabbione> so lamont__ how is going with the new job?
<fabbione> you almost disappeared.. so i guess it keeps you busy ;)
<lamont__> a bt
<lamont__> a bit, even
<jbailey> He's working at a site with a better 'net connection now, he can go back to surfing pr0n.
<zul> they are suppose to be getting fiber here at work
<lamont__> jbailey: feh
<lamont__> besides - they monitor.
<lamont__> which is a great waste of time and money, truthfully
<lamont__> and a significant liability in the making.
<fabbione> + nobody really checks the logs..
<jbailey> Yeah.  I spent ages arguing at my last job that as long as someone was consistantly performing, who cares what they did, and if they weren't, then to deal with them directly and solve the issue without the over application of technology.
<lamont__> HP lives in fear of RIAA
<lamont__> hence BT is disallowed, unless you have a business need for a particular IP to be allowed to participate.
<lamont__> as a client only, of course.
<lamont__> since everyone knows that the only use for BT is to exchange copyrighted material in violation of copyright
<fabbione> BT?
<zul> british telecom? :)
<lamont__> bittorrent
<fabbione> ahh
<zul> ooooh..
<lamont__> I mean, who would use it to release large tarballs/isos of free stuff???
<fabbione> http://dva.gbrit.com/~dougadams/Jokes/index.php?s=3.jpg
<fabbione> AHHA
<fabbione> (the rest of the site is NOT safe)
<fabbione> so don't go one dir up :)
* lamont__ has seen that one before
<lamont__> iz good
<fabbione> the joke or the site?
<lamont__> fabbione: is that a gtk bug, I wonder???
<lamont__> joke
<fabbione> ahah
<lamont__> will have to see what other jokes are there tonight
<fabbione> lamont__: mostlikely
<fabbione> nah the others aren't that funny
<lamont__> ah, ok.  thanks
<fabbione> mostlikely naked stuff
<lamont__> feh
<jbailey> Yeah, I'll read the BDSM stuff some time when my mother in law isn't wandering around my house. =)
<fabbione> jbailey: exactly :) my wife is wathing TV.. i need to entertrain myself somehow :)
<zul> why dont you watch tv with her...
<fabbione> because there is a special about bush visiting dk
<fabbione> and houneslty i can't care less
<zul> heh...you said bush
<fabbione> american people did pay his nice AirForce one travel
<jbailey> Right, instead you can read about tying her up and spanking her instead.
<fabbione> on a 3 day visit, one was half drunk
<jbailey> "It's research, dear."
<fabbione> the ohter has been playing golf
<fabbione> and of 5 things he said on danish tv one was: "... you swallow. LISTEN TO YOUR MOTHER!"
<fabbione> now.. i wonder .. what job did this porro mother do?!
<fabbione> s/porro/poor
<fabbione> jbailey: ahhaa
<fabbione> jbailey: i am not reading all of it yet.. but it seems a pretty hounest author
<jbailey> Cool
#ubuntu-kernel 2006-07-04
<zul> bleah...I hate being sick
<[eXr] > ?
<crimsun> sorry to hear, zul. Feel better soon.
<zul> yeah specailly i had the day off today :(
<zul> BenC: ping
<renewip> hi, can I write on ntfs partition if I rebuild ubuntu kernel ???
<zul> hey
<tseng> all the .17 kernels will boot and then hang Waiting for root filesystem...
<tseng> did I miss some important annoucement?
<zul> yeah known bug
<tseng> ok.
<zul> its got to do with base-files
<thuglife> is anyone here who is actually a member of the kernel team?
<zul> yes several people mostly idling though
<thuglife> ok. because i want to help with the ia64 port but it hard to do it w/o them
<thuglife> :)
<zul> yes it is
<makx> thuglife: klibc needs ia64, atm we build it static on this port
<makx> s/ia64/ia64 love/
<thuglife> how comes that klibc does not have ia64 support?
<makx> it has but works only static
<makx> i thought you were a porter eager of work :-P
<thuglife> if there is something to work on yes
<makx> yeah fix it for shared lib :)
<thuglife> hehe
<zul> BenC: ping when you wake up
<ogra> meep
<zul> ogra: i think BenC might be on holiday today...4th of july
<ogra> apparently 2.6.17-4-powerpc has no modular i2c_keywest driver anymore ...
<ogra> seems thats the cause of my keyboard not working
<zul> hmmm..
<ogra> at least thats the only difference i see in both lsmod outputs 
<ogra> (both = 2.6.15-25powerpc vs the recent edgy one)
<zul> ill see if i can submit a patch tonight if i have time
* BenC is here
<BenC> ogra: i2c-keywest is gone
<ogra> BenC, any idea why i can try about my keyboard ?
<BenC> there's only i2c-powermac now, and it is built-in
<ogra> yeah, i noticed that the HW was recognized in dmesg
<BenC> try the adb modules
<ogra> ok
<makx> why is i2c-powermac built-in?
<zul> BenC: are you going to merge the new kernel-package? because there is some crack that i might find useful...ie the xen-subarch from debian
<ogra> hmm, how should that module be named ?
<ogra> there is no trace of andthing with adb in the name on my disk
<BenC> makx: because ppl upgrading from dapper wont get it loaded by default when they need it
<BenC> zul: I have a xen patch for kernel-package if it want it
<zul> yes please :)
<BenC> ogra: find /lib/modules/2.6.17-4-powerpc/ -name '*adb*' doesn't produce anything?
<ogra> if i only could copy/paste without my keyboard
<BenC> zul: sent...if you want to do a kernel-package upload with it, then have at it :)
<cypher_> BenC, i see a bug in hibernation
<ogra> BenC, nope, neither does locate
<zul> ok i will ;)
<BenC> ogra: Hmm...give me a minute
<ogra> dont put to much time into it, youre supposed to be drunk and burn crackers
<BenC> it's 11am :P
<zul> you are late ;)
<BenC> although I have a beer, I wont get drunk till much later :)
<BenC> plus we can't buy decent firecrackers in my nazi state
<tseng> BenC: you live in PA too?
<ogra> lol
<BenC> we get "fountains"
<BenC> heh, no VA
<makx> BenC: the previous i2c-keywest would be loaded by initramfs-tools
<tseng> in Spain people were seating off fireworks all week
<tseng> right off the beach
<BenC> we can't buy anything that leaves the ground under it's own power, or creates compression in order to produce a loud bang
<BenC> makx: almost 100% of powermac systems want that module loaded
<BenC> makx: On my system i2c-keywest was only loaded because the installer had put it in /etc/modules
<BenC> if that's changed, I wasn't aware of it
<makx> BenC: yes initramfs-tools took charge to load it early
<makx> did the same for i2c-powermac on Debian
<BenC> ogra:
<BenC> linux-source-2.6.17 (2.6.17-4.6) edgy; urgency=low
<BenC>   * Update to 2.6.17.3
<BenC>   * Updates from dapper.
<BenC>   * powerpc: Re-enable ADB (not sure how that got turned off).
<BenC>     - Malone #50976
<BenC> my mistake, it is enabled in today's upload :)
<ogra> yay, thanks !
<BenC> ogra: is sound working for you?
<zul> BenC: should i bump it from dapper to edgy
<ogra> BenC, yep
<ogra> the default volume changed apparently, but  else it works fine
<BenC> zul: yes
<BenC> ogra: can you do "lsmod | grep aoa" to make sure you are using snd_aoa (that's what I'm most interested in)?
<jbailey> BenC: g'm!
<ogra> BenC, aoa all over :)
<BenC> jbailey: hey!
<BenC> ogra: sweet...snd_aoa should make a lot of ppc users happy
<ogra> works flawless here
<ogra> oh, did i mention my suspend light is used as HDD light here ?
<zul> BenC: new kernel package uploaded
<jbailey> zul: Sans null pointer dereferences? =)
<zul> jbailey: frig..
<zul> then wtf?
<jbailey> I haven't tried it since this morning with the -4 upload.
<jbailey> But the ppc64 crashed on it, I think in the same place.
<jbailey> I won't be able to try i386 until I get a new power cord.
<zul> oh i thought you were talking about grub...
<zul> i just uploaded kernel-package ;)
<zul> avec xen support
<jbailey> Ah, no. I tought you meant you uploaded a new linux-image. =)
<zul> nope..
<zul> i would be slaugherted if i did
<BenC> jbailey: guess It's time for me to update my G5 and see how it works
<jbailey> BenC: Sure.  What's annoying is that usplash hides oopses.
<jbailey> I wonder if there's a way of doing a last-effort chvt in there.
<zul> it would be cool if you could do like an alt-f6 and see the boot messages there
<mjg59> alt+f1 is supposed to work
<jbailey> mjg59: Even after an oops?/
<mjg59> Depends how wedged it is
<mjg59> If userspace has been killed, then there's no way to do anything
<jbailey> <dwmw2_gone> Linus just took the hdrinstall stuff
<jbailey> BenC: ^^
<jbailey> Can you pull that from linus' git tree into ours next time you'r'e doing backports?
#ubuntu-kernel 2006-07-05
<BenC> jbailey: hey, are you sure your G5 hangs, or does it drop to busy box after 3 minutes?
<BenC> jbailey: No way to pull from Linus's tree now, he's on to 2.6.18
<crimsun> we may have a fix for bug 34831; just waiting for more feedback before pushing
<BenC> excellent
<BenC> zul: ping
<BenC> crimsun: I'm assuming that any patches I get from you for dapper sound can be merged into edgy now?
<crimsun> BenC: yes, with the caveat that since I target dapper, there may be some backported typedefs, etc. I can attach a note for Edgy to each dapper patch if you'd like.
<BenC> yeah, that'd be nice
<crimsun> all right, will do.
<BenC> zul, crimsun: all patches from you guys are in dapper, will pull to edgy soon
<crimsun> BenC: many thanks.
<BenC> crimsun: no, thank you :)
<Keybuk> zul: ping
<zul> Keybuk: pong
<Keybuk> zul: you did an upload of kernel-package today
<Keybuk> but didn't take the opportunity to merge it
<Keybuk> do you want to do that?
<zul> yes i did..
<zul> i only added the xen stuff i dont know what will break in edgy if i merge it
<zul> i think that might be up to benC
<Keybuk> ok, I ask because now you've uploaded, you've cleared the "outstanding merge" flag :p
<Keybuk> and you've put your name against it for nagging
<zul> meh...
<zul> ill take a crack at it after i do the kernel security stuff on my todo list 
<crimsun> Keybuk: question about effects of Edgy's udev if you have a few moments
<Keybuk> crimsun: sure
<crimsun> Keybuk: I'm looking at the Edgy alsa-utils merge, and there's a udev rule from Debian Sid, "KERNEL=="controlC[0-7] ", ACTION=="add", RUN+="/lib/udev/alsa-utils".  Do you prefer the older (Dapper's) [..] RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/alsa/bogus --startas /etc/init.d/alsa-utils -- start %n"? The question is whether /lib/udev/ is the Right place to have alsa-utils versus /etc/init.d/ .
<Keybuk> so I prefer the Debian way of having it in /lib/udev
<Keybuk> though that rule should be fixed to just RUN+="alsa-utils"
<Keybuk> there's a potential bug though ... does alsa-utils still use stuff in /usr ?
<crimsun> not that I can see.
<Keybuk> ok, then go with the Debian stuff
<crimsun> all right, and thanks for your time.
<BenC> zul, Keybuk: I'll do kernel-package merging
<BenC> it's a hell of a lot of work, because we have some special cases that need to be handled (auto run of boot loaders, update-initramfs, etc)
<Keybuk> *nods*
<Keybuk> just as long as it's not forgotten :p
<zul> BenC, thats what i thought
<Keybuk>    * ata_piix: Disable PATA support for now.
<Keybuk> BenC: ? ^
<BenC> Keybuk: there's no way to blacklist it and have sata_piix work
<BenC> ata_piix handles both pata and sata in Alan's patched up stuff
<BenC> it broked my ia64
<BenC> probably break others as well
<Keybuk> ah, I see
<Keybuk> by "broke" I assume you mean the migration stuff wasn't in place
<Keybuk> rather than flat-out-didn't-work?
<BenC> that would have been the case, but the reality was the pata part crashed on boot
<BenC> zul: !!!!!
<BenC> /usr/share/kernel-package/rules:2198: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
<BenC> kernel-package is causing FTBFS on latest kernel upload :/
<BenC> zul: please fix ASAP, and reupload
<BenC> zul: nm I got it
<zul> frig...sorry
<BenC> np, just gotta find someone to redo the kernel upload after this gets through
<BenC> get it out of failed state that is
<crimsun> awesome, confirmed fix for 34831
<zul> hiho..
<jbailey> BenC: 'kay.  I'll try and twiddle that change so that it applies against our tree and send it to you.
<jbailey> BenC: I'm not sure if it'll drop to busybox or not.  yaboot sucks enough that I haven't thought to remove 'splash' from the bootup so I can see what's going on.
<makx> BenC: concerning kernel-package you could use mkinitramfs-kpkg too
<makx> it's the default in Debian and does basically the same than update-initramfs -c -k <kernelversion> but with old style compat mkinitrd calling option..
<makx> although that would need an initramfs-tools merge first *hint*
<makx> and there you have special cases as we don't do the fb stuff right now
<jbailey> makx: Adam's most likely to do the initramfs-tools merge, and he's not around this week.
<BenC> jbailey: If it drops to busybox, usplash will disappear...you have to give it like 3-5 minutes though
<BenC> jbailey: does your G5 use sata_svw for the rootfs?
<jbailey> BenC: Is there any easy way to get a /proc/mounts to /proc/modules mapping? =)
<BenC> wish there was
<BenC> lsmod | grep sata_
<BenC> if it's in the module list, then you are likely using it
<jbailey> It's not.
<jbailey> Lemme check dmesg
<jbailey> Meh
<jbailey> ntpd(23977): floating-point assist fault at ip 4000000000030e11, isr 0000020000000008
<jbailey> filled up my logs.
* jbailey looks in syslog
<BenC> it's weird on my G5, it hangs waiting for the rootfs, and finally drops to busy box after the timeout
<BenC> it hasn't even tried to load sata_svw, and when I modprobe it from busybox shell, it just hangs further
<BenC> I need a way to do a dmesg
<jbailey> BAHa
<jbailey> that was myia64.
<jbailey> Lemme check the right box.
<BenC> rofl
<jbailey> sata_svw               14852  12
<BenC> yeppers
<fabbione> hey BenC 
<fabbione> BenC: Keybuk did punch back the kernels
<BenC> fabbione: cool, thanks
<fabbione> BenC: yoo
<fabbione> BenC: bzr merge -r somerev foobranch <- what's the git equivalent for that?
<BenC> cherry pick?
<fabbione> yeah but if i need to cherry pick from another branch that's not local
<BenC> git-cherry-pick <sha of commit>
<BenC> it will still grab it
<BenC> ah, hold on
<zul> is there a way to save the chatlog on irssi?
<fabbione> BenC: non local?
<BenC> do you have the branch in your local git?
<fabbione> BenC: nope
<BenC> git-fetch <remote>
<BenC> then use git-cherry-pick for the sha
<fabbione> <remote> is the remote repo i guess
<BenC> yeah
<fabbione> ok thanks a lot
<BenC> something like : git-fetch rsync.kernel.org:/pub/.../linux-2.6 upstream-linux
<BenC> the "upstream-linux" will create a branch with that name refering to the remote, but wont merge/pull it into your local HEAD
<fabbione> thanks
<BenC> You can also create a file to make it easier
<BenC> $ cat .git/remotes/upstream-linux
<BenC> URL: ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
<BenC> Pull: master:upstream-linux
<BenC> then I just do "git-fetch upstream-linux" whenever I want to grab Linus's stuff
<fabbione> ah nice
<fabbione> BenC: thanks for the explanation
<fabbione> BenC: the overall was for thombot that's trying to test a patch for #37452
<fabbione> BenC: it seems pretty straightforward
<fabbione> thom can probably test the fix for you
<thom> i have ~15 4100s sat next to me that i'd quite like to use, so yeah
<BenC> *   edgy sparc   Successfully built 
<BenC> fabbione: sparc builds again :)
<fabbione> BenC: neat :)
<BenC> fabbione: also, sparc is now included in the kernel daily builds
<fabbione> ehhe
<fabbione> faure?
<fabbione> or some other fancy toys
<thom> BenC: the interesting patch is http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=816aa907b909177bdf6e6e6b0d00c5e5a6e2be8c FWIW
<fabbione> thom: i guess you need kernel and installer to test, right?
<fabbione> thom: is a netboot image an acceptable solution?
<fabbione> or do you need a cdrom based install?
<thom> well, given an updated git tree i have the rest of the stuff i need to blow updated cds
<fabbione> (at least to test)
<fabbione> oh it's because it's easier for me to build you a netboot image :)
<thom> i have lots of idle cpu cycles round here that i can happily use
<BenC> thom: if it works, shoot me an email and I'll pull that into dapper's next upload
<BenC> which will likely be very soon
<fabbione> BenC: he needs a git tree :)
<BenC> shit, I can probably build you a kernel with that patch very quickly :)
<thom> BenC: i suspect it'll take me some hours to get my head round exactly which patches i need, so if you have any spare cycles to do a backport that'd be lovely :-)
<thom> (that patch doesn't apply cleanly fwict)
<fabbione> it's probably faster to backport the driver, but be aware that's the same on the T1000/T200
<fabbione> i won't be happy if it breaks :D
<thom> fabbione: but presumably you have the same problem - that you can't use raid on the controller?
<fabbione> thom: i wish i could tell you because the firmware doesn't allow you to setup raid yeet
<fabbione> yet
<thom> heh, ok
<fabbione> but yes. it's supposed to support RAID 
<BenC> wow, there's been at least 20 commits against drivers/message/fusion/ since dapper
<BenC> the diff against that directory is > 300k :/
<BenC> you may just be SOL
<thom> ok, no worries if that's the case
<BenC> if you can narrow down the patch you need to something more manageable, I'd take it for dapper
<thom> sure, i'll give it a go
<BenC> pointless for me to guess
<fabbione> BenC: i guess looking at the commit above isn't enough
<fabbione> tho it's pretty simple commit
<BenC> not sure if it depends on any of the 20 other commits that came before it though
<BenC> that's the guessing part :)
<BenC> it should be easy to manually merge that code in
<BenC> give it a whirl and see what happens
<BenC> FYI, mutex_unlock() == up() in dapper
<BenC> fuck it, let me just get you a working diff to build with
<fabbione> go ben!
<thom> BenC: cheers!
<BenC> email?
<thom> thom@ubuntu.com 
<BenC> this is a down and dirty simple merge, it's missing the topology locks (something that isn't present in dapper) so I'm a little leary about it actually working
<BenC> sent
<thom> thanks, we'll see how it goes
<BenC> if you need help getting the ubuntu git tree, see topic...there's a nice wiki that walks you through it
<BenC> or just grab linux-source-2.6.15 from the archive
<thom> yeah, was just gonna grab l-s
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: I have a fix for nsc-ircc
<BenC> it was using pnp_register_wrong...expecting non-zero to mean success, when in reality it returned the number of devices that matched
<BenC> err, pnp_register_driver wrong
<BenC> so it wasn't calling pnp_unregister_driver on unload because it thought the reg failed
<mjg59> Ah
<mjg59> Cunning
<thom> BenC: unsurprisingly that patch went bang, i'll see if i can cook a reasonable one up a bit later
<zul> BenC: i applied the ppc fix for breezy
<BenC> zul: how's breezy look otherwise?
<BenC> I'm updating the vuln page
<zul> builds, havent run it yet...will do when i get home
<BenC> did the ppc fix apply to hoary at all?
<BenC> so breezy has all the patches?
<zul> havent gotten to it yet..still at work
<zul> yes
<BenC> IPC: access to unmapped vmalloc area in grow_ary()
<BenC> what about that one?
<BenC> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9a5cd5d2a57fb76dbae2115450f777b69beccf7
<zul> no i didnt see it
<zul> ill do the patch when i get home
<BenC> was sent under a seperate email
<BenC> ok
<zul> hmmm...when was it sent?
<BenC> couple of days after the initial list
<zul> i dont think i got it
<zul> arggh...this is riduculus 128 people on an adsl connection
<crimsun> Keybuk: ping (regarding alsa-utils's /lib/udev/ usage)
<Keybuk> crimsun: hello
<crimsun> Keybuk: yesterday you mentioned there may be a bug if /usr is still used, and having inspected the alsa-utils initscript, I see /usr/bin/amixer is called. Does this have anything to do with said bug?
<Keybuk> yup
<Keybuk> people with /usr on a separate partition wouldn't get their sound card initialised
<Keybuk> which is why we have the evil start-stop-daemon while/sleep hack
<crimsun> ok, so we'll still need that in udev.rules in addition to the sleep in the initscript
<Keybuk> for now, yes
<Keybuk> this may be fixable within edgy by using an upstart event instead
<crimsun> ok, I'll read that spec after I finish this merge
<crimsun> thanks
<Keybuk> basically udev would trigger a "sound card found" event at that point
<Keybuk> and we'd start the "restore alsa mixer levels" service
<Keybuk> that service would define that it needs writable filesystems (/usr) to function
<Keybuk> so would inherently wait for that to happen
#ubuntu-kernel 2006-07-06
<Keybuk> "Even though D-BUS is relatively new, it has been adopted very quickly. As I mentioned earlier, udev can be built with D-BUS support so that it sends a signal when a device is hot-plugged."
<Keybuk> that's the second place I've read that
<Keybuk> and it's complete bullshit
<Keybuk> udev sends events to HAL using the "dump an envbuf to a named UNIX socket" trick
<Keybuk> and it's HAL that does dbus
<crimsun> where?
<Keybuk> http://www-128.ibm.com/developerworks/linux/library/l-dbus.html?ca=dgr-lnxw95D-BUS
<crimsun> heh.
<Keybuk> I've yet to find any decent docs on dbus services though
<Keybuk> I'm trying to learn enough to
<Keybuk> a) shoot down all the people who think init should be dbus
<Keybuk> b) consider whether there should be a upstart/dbus bridge
<jbailey> Keybuk: b) Probably.
<jbailey> Keybuk: Notifying user space that a service is now available could be really handy.
<Keybuk> indeed
<Keybuk> it's part of the spec that the equivalent of initctl can be used to read events, etc.
<Keybuk> having a little shim to read from that, and generate dbus signals
<Keybuk> as well as turn dbus methods into initctl messages
<Keybuk> would be kinda cute
<Keybuk> http://raphael.slinckx.net/blog/documents/dbus-tutorial/
<Keybuk> woo
<Keybuk> the tutorial is nice
<Keybuk> but goddamn that hackergotchi scared the crap out of me
<zul> almost psycho killer like
<zul> BenC_: ping
<crimsun> BenC_: There's a patch awaiting moderation. Both (the one waiting moderation and the timer fix) apply cleanly to Dapper. The URL for applying to Edgy is given in the Status.
<crimsun> (out for a bit)
<zul> hey
<fabbione> hey zul
<fabbione> zul: something for  you and Ben to check. the kernel postinstall is broken
<fabbione> that comes from kernel-package
<fabbione> or some reasons -4- build doesn't create an initramfs nor update symlinks (for ppc) or update grub menu entries
<fabbione> for the matter i also had to run depmod -a manually
<zul> grrr...ok..
<zul> pdate grub is dont through kernel-package as well correct?
<fabbione> uh?
<fabbione> kernel-package provides the postinstall for each kernel image
<fabbione> i didn't check the details but something it has been done that makes that non working
<zul> ok
<ogra> ENOBENC ?
<ogra> he kindly enabled adb support in the powerpc kernel, but forgot ybout the mouse emulation 
<ogra> *about
<fabbione> * BenC_ has quit (Read error: 104 (Connection reset by peer))
<fabbione> ogra: i expect his satellite connection to be shaky
<ogra> yep
<ogra> BenC, !
<fabbione> BenC: something is hutterly broken in edgy
<fabbione> i think it's due to kernel-package
<fabbione> but the last 2/3 machines i updated are all landing without initrd or symlink updated
<fabbione> and stuff like that
<fabbione> tho the postinst doesn't seem to fail
<AnAnt> there is a problem that I want to report
<AnAnt> the kernel 2.6.15-25 does not boot on laptops
<fabbione> AnAnt: use launchpad-net
<AnAnt> I tried it on an HP and a  Toshiba laptop
<fabbione> .net
<ogra> https://launchpad.net/distros/ubuntu/+filebug
<ogra> ;)
<ogra> BenC, keyboard works fine now, but you forgot to enable the right/middle mousekey emulation 
<ogra> (or its broken for me if you didnt)
<BenC> I thought I did
<BenC> I'll check it though
<BenC> fabbione: Hmm, I'll check on that
<fabbione> BenC: ok thanks. I also have the feeling that ppc is overheating
<fabbione> BenC: is there a way to check fans and stuff? i have the same pb as your
<zul> later..
<ogra> fabbione, mine isnt getting hotter than usual ... (if i kill the panel menu which eats 65% CPU load constantly)
<fabbione> some of my panel notification thingy don't work on ppc  but i have a strange thing with the cpu
<fabbione> load is high as in 2
<fabbione> but cpu usage is very low
<fabbione> like 20%
<ogra> does your app menu in the panel work ? 
<ogra> mine is constantly flickering (opening/closing in nanoseconds)
<jouni__m> 2.6.17-4 kernel thinks my /dev/hdb6 is /dev/sdb6 and doesn't boot. Is this known issue? Could I help somehow?
<jouni__m> it boots with root=/dev/sdb6 option in grub
<BenC> jouni__m: What IDE controller do you have?
<jouni__m> BenC sorry how did I find it out?
<jouni__m> hal-device|grep ide gives 82801AA IDE
<BenC> jouni__m: lsmod output from 2.6.17 and 2.6.15 to compare would be helpful
<jouni__m> BenC ok I boot to 2.6.15.
<jbailey> BenC: Heya - I tested my ppc64 this morning, and yes - after a few minutes it dropped to busybox.
<jbailey> (bounce for ip address change)
<jouni__m> BenC opened bug #52123
<jouni__m> malone 52123
<jouni__m> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/52123/+index
<BenC> jouni__m: cat /proc/version for me please
<BenC> err, actually, dpkg -l | grep linux-image
<BenC> jbailey: Yeah, I can reproduce your ppc64 problem, so it's not just you this time :)
<BenC> jbailey: It's weird, sata_svw is supposed to get loaded, and doesn't, but if you try to manually load it, it locks up
<jouni__m> BenC 2.6.15-21.32 and 2.6.17-4.6
<BenC> ok
<Ng> BenC: hey, you said you'd applied a patch from bug 50593 - does that mean it'll make it into the next dapper kernel update?
<BenC> Ng: if it's "Fix commited" against 2.6.15, then yes
<jbailey> BenC: rE: kdump.  The guy really wanted to work with us when I spoke to him at OLS last year.  It was just too much to do that late in the breezy cycle, and dapper wasn't supposed to get sexy features.
<jbailey> BenC: But he'd probably still be happy to see a distro take it up.
<BenC> jbailey: ok
<brainsik> Is there a page which explains the differences between the -server kernel image and the regular one?
<crimsun> how comfortable are you reading .configs?
<brainsik> crimsun: i can probably read the .config files, but was trying to avoid it :)
<Ng> BenC: outstanding, thanks very much :)
#ubuntu-kernel 2006-07-07
<zul> hey
<zul> yay...2.6.12 boots
<BenC> 2.6.15 is going to require an ABI bump
<zul> doh..
<BenC> did 2.6.12/2.6.10 pass ABI tests?
<zul> yep it did
<BenC> did you rename the ABI directory and everything?
<zul> i renamed the abi directory from 34 to 35
<BenC> ok, then you're good
<zul> it built the debs :)
<BenC> man, this xeon box rips through dual amd64/i386 kernel builds like nothing
<zul> it wouldnt have built them would they not?
<BenC> I found that the edgy build didn't fail of the previous ABI's didn't exist to compare to
<BenC> wasn't sure if it was a bug in recent build stuff, or something that's always been there
<zul> whoops..
<zul> ill be back in about half hour going to watch the rest of friends
<BenC> ok
<crimsun> BenC: what's the ETA on next 2.6.15?
<crimsun> (upload)
<BenC> tonight or tomorrow morning
<kylem> BenC, feel free to poke me about hppa things whenever you need.
<crimsun> BenC: ok, please apply the fix for #34831 (posted to the list)
<BenC> kylem: hey!
<BenC> crimsun: will do
<crimsun> BenC: great, thanks
<BenC> kylem: my A500 still isn't booting 2.6.17
<kylem> BenC, hmm. got a console log?
<BenC> no console output, and I just reused the .config from 2.6.15 which works great
<kylem> hm, can you post the .config?
<BenC> email?
<kylem> kyle@parisc-linux.org
<BenC> kylem: sent
<kylem> thanks.
<BenC> I applied the pa6 patch to the tree too
<mdz> BenC: urgh, my irqpoll problem has returned with 2.6.17
<mdz> the one which was fixed ages ago
<kylem> BenC, so there's absolutely no output after palo?
<mdz> BenC: bug 11671
<BenC> kylem: It shows a "Console reset" and "Disk reset" message
<kylem> hmm. can you paste it? that's pretty much totally unexpected.
<BenC> yeah, let me reboot to capture it
<kylem> thanks
<BenC> mdz: Ok, I let the patch revert in 2.6.17 to see if it came back...I'll re-add it
<BenC> Branching to kernel entry point 0x00100000.  If this is the last
<BenC> message you see, you may need to switch your console.  This is
<BenC> a common symptom -- search the FAQ and mailing list at parisc-linux.org
<BenC> Console reset done.
<BenC> Boot device reset done.
<kylem> woah.
<BenC> kylem: You can't see it in the paste, but there's about 4 blank lines before the Console reset and one more after it before the boot device reset
<zul> oh hey kylem 
<kylem> hi.
<kylem> BenC, i assume this config is for your edgy kernel? i'll try building/booting your git tree.
<BenC> ok
<zul> BenC, do you want to have a quick look at the diff for breezy?
<zul> or ill just upload it
<BenC> yeah, that's good
<zul> upload it?
<BenC> zul: yeah
<BenC> I'm getting errors from automake
<BenC> Makefile.am:24: BUILD_LINUXDOC does not appear in AM_CONDITIONAL
<BenC> configure.ac: 39: required file `./[config.h] .in' not found
<BenC> src/Makefile.am:37: invalid unused variable name: `ATIMISC_CPIO_SOURCES'
<BenC> src/Makefile.am:45: invalid unused variable name: `RADEON_EXA_SOURCES'
<BenC> src/Makefile.am:41: invalid unused variable name: `ATIMISC_DGA_SOURCES'
<BenC> src/Makefile.am:36: invalid unused variable name: `ATI_CPIO_SOURCES'
<BenC> autoreconf2.50: automake failed with exit status: 1
<BenC> [22466.357915]  [drm]  Initialized drm 1.0.1 20051102
<BenC> [22466.368099]  ACPI: PCI Interrupt 0000:0b:01.0[A]  -> GSI 18 (level, low) -> IRQ 177
<BenC> [22466.368139]  [drm]  Initialized radeon 1.24.0 20060225 on minor 0
<BenC> [22468.850731]  [drm]  Setting GART location based on new memory map
<BenC> [22468.851572]  [drm]  writeback test succeeded in 2 usecs
<BenC> new driver uses drm just fine
<mdz> BenC: sneaky
<BenC> let me go check if glx and everything looks ok
<zul> coool...it got accepted
<BenC> mdz: Current ati xorg driver crashes on this xeon box
<BenC> so we'll need a dapper update from airlied that I just tested
<mdz> BenC: as long as we're fixing ati bugs, can we get one for that display corruption bug too?
<BenC> hopefully this new release fixes that
<BenC> do you have a bug number I can point airlied to?
<mdz> looking
<mdz> BenC: https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-ati/+bug/38198
<BenC> mdz: spoke too soon, ati with drm enabled still crashes on this xeon box
<BenC> drm/dri has to be disabled to use ati...but you can boot with safe graphics and that works
<BenC> fglrx doesn't even work with it
<mdz> what kind of card?
<mdz> works fine for me with all of my ATI devices
<BenC> it's an rn50 chip
<BenC> airlied that rn50 chip is dodgy they are just m7s with the 3d engine broken..
<BenC> might just have to choke that down as an errata
<airlied> mdz: disable redner accel..
<mdz> airlied: for all Ubuntu users?
<airlied> mdz: well for that bug to test if it is the problem..
<mdz> need to reboot due to 11671
<airlied> I'm not sure if turning it off for everyone is the answer..
<airlied> BenC: I'm not even sure the drm should bind to those cards at all..
<airlied> ah the reported already turned render accel off.. 
<airlied> damn then someone jumps in with an unrelated google earth bug..
<BenC> airlied: Can you suggest a patch that would disable render-accel and/or drm for rn50's?
<airlied> well just removing the rn50 pci id from the kernel would stop it, but that branch should also do it in the driver...
<airlied> have you a log from when it crashes?
<BenC> can't see anything when it crashes
<BenC> screen goes sync, and then deadlock
<airlied> if you mount / sync then get the Xorg.0.log from it..
<BenC> (**) RADEON(0): RADEONDRIStop
<BenC> (**) RADEON(0): Disposing accel...
<BenC> (**) RADEON(0): Disposing cusor info
<BenC> (**) RADEON(0): Disposing DGA
<BenC> (**) RADEON(0): Unmapping memory
<BenC> that's the last part of the Xorg.0.log
<BenC> nope, that's not the one
<zul> freenet has dsl now? cool..
<zul> uploaded for both hoary and breezy
<kylem> zul, yeah. $29.99/month no contract.
<kylem> zul, 5Mbit with 40G/month too.
<zul> not bad...wish i had a phone line..
<zul> BenC: why the change in the control files for edgy?
<BenC> zul: makes it easier to keep all the -image and -headers package descriptions consistent
<zul> ah ok..
<BenC> mdz: sparc FTBFS on breezy is know, but no one has bothered to fix it...thanks for the forward though
<BenC> s/know/known/
<BenC> crimsun: applied your last four patches, so just need to do some test builds and boots
<crimsun> BenC: great, thanks much
<zul> hi
<zul> brb
<AZzKikR> `uname -r` prints out 2.6.15-25-386, and i need to apt-get the source and headers of this kernel version. Anyone has any idea which package that might be?
<zul> BenC: eh...you are assigning me things now? 
<BenC> zul: I've made you the "breezy hoary kernel maintainer" :)
<BenC> I figure you'll be doing the next breezy upload, so might as well get that patch in
<zul> ok...cool..thanks...i think ;)
<mdz> BenC: have you already merged the patch in https://wiki.ubuntu.com/QuietenGrub ?
<BenC> mdz: doubt it
<mdz> BenC: please do
<mdz> zul: are you going to upload the grub bits?
<BenC> mdz: done
<mdz> BenC: thansk
<zul> mdz: yes i was going to work on it tonight
<zul> i have updated the patch according just have to update grub
<mdz> zul: cool, thanks
<zul> later
<zul> time to go home
#ubuntu-kernel 2006-07-08
<nigel_c> BenC: ping
<nigel_c> Guess not. I'm away for a while. Just wanting to find out what the status is with Suspend2, and whether I can do anything to help get it in.
<nigel_c> I have changes coming to remove the page_alloc.c modifications, and will be shifting /proc/suspend2 to /sys/power if that makes any diff.
<BenC> kylem: ping
<nigel_c> BenC: ping
<BenC> nigel_c: hey, suspend2 is looking a little iffy for edgy...I'm talking to some people that handle suspend things more than I do in userspace to see if it really is right for us
<BenC> there's a lot of infrastructure changes that I'm not sure we can do
<nigel_c> What can I do to help it be less iffy?
<nigel_c> (If anything)
<BenC> get me an all encompassing userspace solution to convert to suspend2 :)
<BenC> the kernel side is easy, it's the userspace that is hard
<BenC> initramfs-tools, gnome-power-manager, etc...
<nigel_c> ack. I thought one of them was going to add suspend2 support.
<nigel_c> You've heard of Bernard's hibernate script? But I guess you want a gui.
<nigel_c> I'll go hassle the gnome-power-manager guys then, shall I? :)
<nigel_c> Hmm. The gnome-power-manager faq makes it sound like they have suspend2 support.
<nigel_c> (Looking at http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/docs/faq.html)
<BenC> that's the stuff that I don't know about
<BenC> I don't want to upload it and then have a few hundred bug reports about it not working with "UI foo"
<nigel_c> That makes sense.
<BenC> plus I've heard varying degrees of "it's great" to "it's crack", so I'm a little leary about it still
<nigel_c> Yeah. We could do with a good gui that makes setting everything suspend2 related really easy.
<nigel_c> In your last comment, it = suspend2, the hibernate script or something else?
<BenC> suspend2's kernel code
<nigel_c> k
#ubuntu-kernel 2006-07-09
<zul> BenC: ping 
<BenC> zul: pong
<zul> BenC, im trying to generate the xen configs using the debian/bin/* from .config how would i go about doing that?
<BenC> you generate them seperate
<BenC> config.xen, etc.
<zul> generate how?
<BenC> make menuconfig or whatever you like to use
<zul> ah ok..
<zul> BenC: is there something that deletes the debian directory that when you a clean?
<BenC> zul: check the scripts/Makefile diff's in our kernel tree's
<BenC> debian/official is an important file too I believe
<BenC> keeps make-kpkg from deleting debian/
<fabbione> hey BenC
<fabbione> you are up late today :)
<zul> BenC,: grr...still the same
* fabbione -> off
<fabbione> have a nice sunday guys
<zul> c ya later fabbione 
<crimsun> bye fabbione 
<zul> never mind got it
<zul> night folks..
<crimsun> night zul
<howe0001> is there an "apt-get" kernel 2.6.17 anywhere yet? 
<rada> PARA SBER OQUE OS OUTROS ESTO FALANDO EM SIGILO  S APERTAR CTRL+W
<zul> fabbione: going nuts yet?
<fabbione> UHAUHAUHAUHAUHAUHAUHAUHAUHA
<zul> y3p
<fabbione> night
#ubuntu-kernel 2007-07-02
* Starting logfile irclogs/ubuntu-kernel.log
<kraut> moin
<xivulon> mjg59: any luck with wubi?
<mjg59> xivulon: The kernel is stupid
<mjg59> Not convinced we can fix it for gutsy, but I'll see
<xivulon> ?
<mjg59> The process freezer is used for suspend to RAM, but syslog is still trying to write when fuse is frozen
<mjg59> So the writing never completes
<mjg59> And suspend fails
<xivulon> I see
<xivulon> what about stopping syslog beforhand?
<mjg59> Syslog is just what fails in the trivial case
<mjg59> It could be any application
<xivulon> I understand
<xivulon> Note that in hibernation there is an added problem
<xivulon> Swap is inside a mounted fs
<mjg59> Yes, hibernation is impossible
<xivulon> So for instance we have lubi (the wubi version working on linux/ext3) where suspend works (since there is no fuse involved) but hibernation does not (I assume because the swap is not in a dedicated partition)
<xivulon> mjg59 what would be an elegant way to turn off suspend/hibernation for the time being?
<mjg59> For gnome, there's a couple of gconf keys that you can set
<Mithrandir> look at what casper does.
<xivulon> The issue that wubi is not really gnome specific
<xivulon> Also suspend might work in some cases (non-fuse host fs)
<mjg59> Policy is managed by individual applications
<xivulon> Do they read "capabilities" from somewhere?
<mjg59> No
<xivulon> What about acpi=off? 
<mjg59> Ouch. No.
<mjg59> acpi is much more than power management
<xivulon> I was expecting the ouch
<mjg59> (And it'll do nothing to influence hibernation)
<xivulon> What about having a script in suspend.d that kills sleep.sh
<xivulon> That will not take care of disabling the suspend/download buttons though...
<xivulon> mjg59 as a side question. Any chance of having ntfs-3g as a kernel module? That would solve lots of issues
<mjg59> No
<xivulon> I asked szaka (ntfs-3g) and he was not so inclined either...
<mjg59> It's not easy to port a fuse application to the kernel
<xivulon> Last question (other than the suspend.d hack above):
<xivulon> Users do tend to hard reboot quite a lot
<xivulon> Because often they come from windows and do not know what to do when they get stacked
<xivulon> A nested fs is not the best environment for that
<xivulon> What can be done to minimize damage?
<mjg59> Nothing
<xivulon> I changed /etc/sysctl.conf on szaka suggestion
<xivulon> vm.dirty_background_ratio=0 , vm.dirty_ratio=0 , vm.dirty_expire_centisecs=1  , vm.dirty_writeback_centisecs=1  
<mjg59> What sort of corruption are you actually seeing?
<xivulon> Sometimes the hosted fs (ext3) might become unrecoverable, since data loss in the hosting fs might compromise the journal
<xivulon> Alos hosting fs corruption has been reported (but chckfs normally can fix that)
<xivulon> Using the above things seem to have improved
<xivulon> Based on bug reports
<mjg59> Right. ext3 makes the assumption that writes to the journal actually end up in the journal
<mjg59> I'm not sure there's a good way around that
<xivulon> According to szaka the sysctl parameters above should improve things but to be honest I have not looked up what they do exactly
<xivulon> mjg59 any reason not to use the sysctl parameters above?
<mjg59> xivulon: Reduced performance, but I guess you'll have to take that hit
<xivulon> so far it does not look to bad, so I guess I'll leave them there
<xivulon> mjg59 last thing: is the idea of using a suspend.d script that makes sleep.sh exit so bad?
<mjg59> Yes
<xivulon> ok 
<xivulon> That's all I had to ask, thank you very much for all your help
<xivulon> very useful
<johanbr> Is there are reason /dev/input/eventX would not be available immediately on resume? Sometimes my touchpad dies when I resume, and I think it's related to log entries like
<johanbr> :0.log.4:Synaptics Touchpad no synaptics event device found (checked 17 nodes)
<johanbr> :0.log.4:(EE) xf86OpenSerial: Cannot open device /dev/input/event3
<mjg59> Yeah, synaptics seems a bit dumb.
<johanbr> So it's the fault of the synaptics driver rather than the kernel?
<mjg59> Yes
<johanbr> Alright. Well, you seem to be aware of the problem, so I'll just hope for a fix at some point in the future. :) Thank you.
#ubuntu-kernel 2007-07-03
<calc> anyone know if the 3945 wireless is fixed in gutsy yet?
<BenC> fixed?
<BenC> it's worked throughout gutsy for me
<calc> BenC: oh ok
<calc> well afaik it has never worked for me, feisty's works fine though
<calc> i'm not sure where to start looking to determine why it doesn't work though
<calc> it is going from 2.6.20 -> 2.6.22 though so its possible it is something else breaking it besides the driver itself
<mjg59> BenC: I'm still entirely unable to pull from the gutsy git tree in any sane way
<kylem> it keeps getting rebased.
<mjg59> So what do I do?
<kylem> fetch into a new branch and reset to the new head
<mjg59> (Other than blow away my tree)
<mjg59> kylem: Ouch.
<mjg59> Can't we just avoid rebasing?
<kylem> git fetch origin master:tmp; git reset --hard $(git-show-ref master | awk '{print $1}') or something
<kylem> er, s/master/tmp/ in the second bit
<lifeless> mjg59: git is not bzr :)
<kraut> moin
<ogra> hi, can anyone tell me if dropping of the oss headers was our decision or upstreams ?
<ogra> (things like soundcore.h and ac97.h are missing from the recent headers/source)
<zul> morning
<jeromeg> hello
<jeromeg> could someone tell me if bug 52846
<jeromeg> is really a bug ?
<jeromeg> it's about kernel headers and a possible missing file from the kernel tree
<kylem> well, they're explicitly not exported, so what userland code needs it?
<jeromeg> dunno, 'im just triaging old bugs
<kylem> likely he's missing build-depends and assumes that's where it should come from
<kylem> (but in reality, there's probably a library providing a sanitized header.)
<jeromeg> kylem : so I can close this ?
<kylem> i marked it as incomplete for now.
<jeromeg> kylem : thx
<kylem> np.
<kylem> thanks for bringing it up.
<jeromeg> np
<zul> BenC: ping
<holycow> hi guys
<holycow> can anyone comment on whether or not the intel 945 gu chipset is supported by any kernel yet? particularly say the feisty kernel?
<JanC> what do you mean by "gu" ?
<holycow> http://www.dynamism.com/u8240/specs.shtml
<holycow> i was curious about that too
<holycow> never heard of a 945gu express chipset
<kylem> i have no idea what that is.
<JanC> it's probably just a variation of the normal 945
<holycow> *nod*
<JanC> with a new name invented for marketing purposes  :)
<kylem> i've heard of 945GM and 945GT...
<holycow> i'm probably going to buy that device anyway and give it a go ... but thought to ask first
<kylem> feisty probably needs pci id updates for it.
<holycow> when i get it in, i would be a willing guinea pig :)
<holycow> but they are short ordered so that will take a while
<kylem> yeah, feel free to poke me about it if it does give you trouble
<holycow> danke :)
<JanC> seems like it's the "ultra mobile" version
<kylem> it seems tobe a new part.
<holycow> yeah
<holycow> appearently the a110 cpu is a chopped down dothan with a tiny cache
<holycow> the cpu is supposed to be a stop gap until they get a true low power cpu out next year
<JanC> the PDF linked from http://www.intel.com/design/mobile/specupdt/309220.htm says some things about "April 2007 - Added information for the Ultra Mobile 945GU Express Chipset GMCH 82945GU."
<kylem> indeed: http://www.intel.com/products/mid/ultramobile2007.htm
<holycow> i presume they did the same thing with the chipset to match the sliced up cpu
<kylem> not quite as much to change there.. it's likely just a refresh to cope with a slower fsb.
<holycow> thanks guys 
<holycow> later
#ubuntu-kernel 2007-07-04
<calc> i guess its about time for me to figure out what is wrong with gutsy 3945 for my laptop
<Nafallo> kylem: ping Intel GMA X3100 :-)
<kylem> Nafallo, oi
<Nafallo> kylem: hi :-). do you know if gutsy support that chipset? I saw you uploaded the intel xorg-thingies :-)
<kylem> yeah.
<kylem> i uploaded -intel and -mesa yesterday with support for it
<zul> hey kylem 
<kylem> moin
<zul> how is everything?
<kylem> tiring. took today off instead of canada day so i could run to the store and get things before i go to london.
<zul> nitfy
<Nafallo> kylem: thanks! I should buy that laptop I want then ;-)
<kylem> Nafallo, er, wait, which one is x3100? :)
<Nafallo> kylem: a new one :-P
<kylem> oh, you meant the 945U?
<Nafallo> I have no idea. I think it belongs to the architecture of some 945* :-)
<Nafallo> Dell Latitude D630 have them for instance ;-)
<Mithrandir> x3100, isn't that the G33/G965 one?
<kylem> Nafallo, we support everything upstream does atm, i've asked keith to let me know.
<kylem> G33 != 965G
<Nafallo> kylem: thanks :-)
<kylem> G33/Q33/Q35 are 945-based
<Nafallo> all those numbers are confusing me :-)
* Nafallo checks ZDnet review of the laptop
<Mithrandir> kylem: I thought G35 was X3500, BICBW
<kylem> Mithrandir, intel's model numbers are retarded.
<kylem> Mithrandir, i'll explain why at the sprint :)
<Keybuk> are anybody's model numbers *not* retarded?
<Keybuk> the minute you break away from 1, 2, 3, 4, et. al. you get goofyness
<Mithrandir> G35 is X3500, and G33 is X3100.
<kylem> there is no G35, just Q35.
<kylem> anyway, we support both those.
<Nafallo> The chipset, codenamed Crestline and officially called the Mobile Intel 965 Express
<Nafallo> The graphics themselves are provided by the GMA X3100 graphics core
<kylem> we support that too.
<Mithrandir> oh, and G965 is X3000
<Nafallo> about Intel Santa Rosa-platform... :-)
<kylem> if it's 965 based, that's the rox0r.
<Nafallo> Chipset: Mobile Intel GM965 Express <-- there we have it! :-)
<kylem> 965 is their new gen gpu, basically performs as well as a geforce6600, which is pretty darn impressive
<kylem> Nafallo, yeah, we support it
<Mithrandir> kylem: oh, so 965 != G965?
<Mithrandir> ah, ok.
<Mithrandir> and G35 exists, at least on paper
<kylem> Mithrandir, they are. but the Xxxxx is all confused.
<kylem> Mithrandir, well, we don't have pci ids for it.
<Nafallo> yay! then I think this monster should be Ubuntu compatible then :-)
<Keybuk> kylem: it could be worse
<Keybuk> "the 925 is an evolution of the 915, and not related to the faster 920; the 910 is a cut-down version of the 920 aimed for the mass market"
<Keybuk> It's all, fundamentally, Psion's fault
<Keybuk> "we can't call it the 3b, because that sounds worse than 3a, so it's the 3c"
<Keybuk> followed by
<Keybuk> "we can't call it the 4, because that's an unlucky number in some of our biggest markets, so it's the 5"
<Nafallo> haha
<kylem> haha
<Nutubuntu> I don't want to be off topic, so can anyone tell me whether it's appropriate to ask about a kernel Oops here? or where I ought to go? I'm a n00b with no understanding of the kernel :)
<JanC> Nutubuntu: this channel is (mostly) for kernel development
<Nutubuntu> t/y JanC - where should I ask? I don't want to disrupt.
<johanbr> Nutubuntu: If it's reproducible, I'd suggest you file a bug on launchpad.
<JanC> if not, maybe ask on answers.launchpad.net or #ubuntu
<JanC> (if not reproducible)
<Nutubuntu> johanbr,  JanC, thank you
<xxxxx1> heya people
<xxxxx1> bug #122852
<xxxxx1> can someone give a look at this bug?
<xxxxx1> is related to Gutsy Linux kernel version
<xxxxx1> 2.6.22-rc7
<xxxxx1> if someone have a suggestion... i'll appreciate
<xxxxx1> :)
<JanC> xxxxx1: I guess this uses FUSE ?
<xxxxx1> JanC, nope
<JanC> eh, what then?
<xxxxx1> is a native Linux filesystem
#ubuntu-kernel 2007-07-05
<calc> BenC: looks like tribe2 doesn't work for me for 3945 but i think it might be network manager at fault, can't really tell for certain
<calc> BenC: it can see both wireless ap's at my house but can't connect properly to either
<calc> BenC: guess i'll have to stick to feisty until the sprint and get someone to take a look at the gutsy on my box
<crimsun> I'd try the interfaces(5) mode of wpasupplicant.
<crimsun> /usr/share/doc/wpasupplicant/README.modes.gz
<crimsun> iface eth0 inet dhcp
<crimsun>     wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
<crimsun> etc.
<crimsun> then scrap NM temporarily, and test the "normal" if{up,down} methods.
<calc> crimsun: whats really odd is it sees the network can tell one is protected and one is not, tries to connect brings up the iface (seen in ifconfig) but doesn't get an address
<calc> i'll see if i can do all that via the boot cd, i dont really want to do an install then have to reinstall feisty again
<calc> bbiab, laptop is in other room
<calc> crimsun: ok
<calc> crimsun: i set wpa-driver wext and wpa-ssid myssid
<calc> eg:
<calc> iface eth3 inet dhcp
<calc>   wpa-driver wext
<calc>   wpa-ssid foo
<calc> then ifup eth3
<calc> and it tries to get a dhcp address but can't
<calc> works perfect with network manager on feisty
<crimsun> you'd have to use wpa_cli to set the PSK or whatnot, then.
<crimsun> I prefer to use /etc/wpa_supplicant/wpa_supplicant.conf
<calc> i have no security on the AP
<calc> its wide open
<crimsun> oh, wide open?  Hmm.  What's in dmesg?
<calc> not much
<calc> iwconfig can see the ap from what i can tell
<calc> i ran iwconfig eth3 ssid foo and it associated with it
<calc> i haven't tried running the dhclient against the eth3 directly bypassing ifup yet
<crimsun> worth a try
<calc> bbiab
<calc> ok i got it to work
<calc> so WTF?
<calc> ifupdown is broken or something?
<calc> that is insane
<calc> if i ifup eth3 it can't get an address with dhclient
<calc> or dhclient3 not sure which it is running on the cd
<calc> if i run dhclient eth3 it works
<calc> at least i know how to get by making it work for now
<calc> but what could be wrong with ifup that causes it not to get an address using the same dhclient
<calc> dhclient and dhclient3 on the cd both worked fine so it can't be a bad binary (afaict anyway)
<calc> crimsun: any ideas?
<crimsun> (sorry, switching buffers)
<crimsun> if it's an open AP, you could just skip wpasupplicant completely.  I was under the impression you're on a "secured" net.
<crimsun> (/usr/share/doc/wireless-tools/README.Debian)
<calc> crimsun: ah so i am skipping wpa i forgot about that
<calc> so it could be wpa that is broken for my machine
<calc> and that was a new upload of wpa in mid june
<calc> so i should try downgrading if i can once i install gutsy and see if that fixes the issue
<calc> well and a new kernel as well
<calc> so it could either be the kernel and wpa no longer get along or something in wpa is just off vs the old version
<kraut> moin
<BFTS> hi
<BenC> mjg59: anything new in 2.6.22 libata (compared to 2.6.20) that would start making my hd spin down more aggressively while on battery?
<Nafallo> that sounds like a good thing though :-P
<mjg59> BenC: I'd noticed that, but I'm not sure why
<jeromeg> hello
<jeromeg> i'm triaging and I wanted to know if bug 123559 is really a kernel issue
<jeromeg> can someone help me ?
<zul> which version?
<jeromeg> 2.6.22 I think
<jeromeg> 2.6.22-7 to be precise
<zul> i tink it might be a udev bug but im not 100% sure
<jeromeg> happens for at least two persons
<jeromeg> ok
<jeromeg> I should report this upstream ? or ubuntu guys will deal with this problem ?
<kylem> jeromeg, do you have an /etc/mactab?
<kylem> jeromeg, it's not a kernel issue.
<jeromeg> kylem : I'm only triaging so I can't help you with this
<kylem> oh.
<kylem> well. not very useful then.
<jeromeg> but I can ask the question nothe bug report
<jeromeg> *on the
<jeromeg> I have another question, who deals with pcmcia, the kernel team ?
<kylem> jeromeg, yes.
<jeromeg> so bug #52510 should be for you ?
<jeromeg> there seems to be a missing file in pcmcia-utils
<jeromeg> I'm triaging old bugs and a lot of them are kernel one's, so sorry if I mess with old stuff
<kylem> it's fine. thanks for doing it.
<jeromeg> most of them are fixed, but some remain :)
<mjg59> BenC: You seem to have dropped the hotkeys over acpi patch from toshiba_acpi
<mjg59> BenC: And the lack of history makes it kind of difficult to work out when
#ubuntu-kernel 2007-07-06
<BenC> mjg59: it's part of a patchset I sent kyle for inclusion
<kylem> yeah, clearly it's all my fault.
<pkl_> kylem: makes a change from being my fault :)
<mjg59> BenC: Is there any way to determine which patches were in feisty and aren't currently in gutsy?
<BenC> kylem: wasn't pointing fingers, just letting him know that the patch wasn't lost
<BenC> mjg59: yeah, it's basically the file I sent to kyle
<BenC> mjg59: forwarded to you
<mjg59> Thanks
<BenC> mjg59: when is toshiba_acpi stuff going to get into mainline? :)
<mjg59> 23
<Nafallo> kylem: I've bought the laptop earlier this evening. will let you know how the Intel-stuff works out :-)
<kylem> Nafallo, if it doesn't work, it's my job to make it, so feel free to ping me
<Nafallo> kylem: I know, and I will :-)
<BenC> mjg59: cool, thanks
<zul_> BenC: ping
<BenC> zul_: yo
* Nafallo holds both thumbs that zul will say something about openvz :-)
<zul_> BenC: there is problem in the i386 config PAE is not enabled the hypervisor needs that or it will a kernel mismatch when booting
<BenC> pkl_: ^^
<zul_> freaking nickserv
<mjg59> Haven't we been over the PAE on i386 thing many, many times before?
<BenC> mjg59: this is a xen specific config/flavour
<BenC> at least I hope that's what zul meant
<zul_> yep it is
<zul_> besides its the generic flavour renamed i386
<BenC> sure you wouldn't rather use -server redone for -xen?
<BenC> -server already has PAE
<zul_> arent there drivers missing from -server?
<BenC> no, right now it's basically -generic with HZ=100 and no preempt
<BenC> plus a little bump is cpu target (686 as opposed to 586)
<zul_> doesnt matter to me then
<zul_> oh when are those policies going to be on the wiki?
<Nafallo> zul_: are you doing openvz btw? :-)
<zul_> Nafallo: no
<Nafallo> zul_: you got any idea if someone is? :-)
<zul_> Nafallo: probably the openvz guys, i really dont have time for it 2 virtualizations are enough for me
<Nafallo> zul_: sounds sensible enough :-)
<Nafallo> I might need it for work, but I hope I can avoid maintaining a patchset :-P
<pkl_> zul_ bummer
<pkl_> zul_: the config.generic flavour has HIGHMEM4G and not CONFIG_X86_PAE.  I made sure the config matched that.  Why isn't that appropriate?
<kylem> xen only supports pae, afaik.
<pkl_> kylem/zul_: so the xen flavour with PAE will only run on the server kernel?
<zul_> pkl_: you CONFIG_HIGHMEM64G enabled
<zul_> pae is default you can build it without pae but it would suck
<pkl_> zul_: sorry, just checked, I had CONFIG_HIGHMEM4G
<zul_> pkl_: yep no probs
<BenC> pkl_: xen guest kernels only run under a xen dom0 kernel, and I think it's dom0 that needs pae
<zul_> yep
<kylem> anyway, bob dylan. l8rs.
<zul_> oh yes bluesfest have fun
<BenC> but since the xen/config.i386 is both dom0 and domU, just make that config PAE and we're good
<BenC> kylem: later
<pkl_> zul_: adding HIGHMEM64G/X86_PAE is no problem.
<zul_> pkl_: thanks
<pkl_> zul_: in your patch you had both -pae and non pae i386.configs, and so I figured no-pae configs worked on xen.
<zul_> they do if the dom0 is built without pae 
<zul_> we had both in feisty 
<pkl_> zul_: the xen/config.i386 config is both dom0 and domU?  And so it would work with no pae?
<zul_> its bit dom0 and domU but dom0 needs PAE in order to boot
<pkl_> Seems like non PAE support in xen was scheduled to go away in 3.1.
<zul> pkl_: correct but distros such as fedora and opensuse still supports it
<pkl_> zul: yeah, but I couldn't remember having to use a PAE enabled dom0.   You were saying dom0 had to be PAE enabled. 
<zul> which kernel did you use?
<zul> sorry crabby baby
<zul> dom0 is pae enabled by default under 3.1
<pkl_> zul: I haven't played about with xen for many years.  2004/2005?  When was it first released?  It seemed something interesting when it got first released, but I never got time to play around with it afterwards.
<zul> ah well you probably used the defaults but anyways..
<pkl_> zul: maybe, but a google brings up many instances of non PAE dom0/domU usage.
<zul> pkl_: try it out and see :)
<zul> brb
<zul> pkl_: ie: https://bugs.launchpad.net/ubuntu/+source/xen-source-2.6.17/+bug/65096
<pkl_> zul: yeah, but that's because there was a mismatch between dom0 and domU, dom0 was PAE, and domU wasn't.  He was using the server flavour.
<zul> you can use the dom0 kernel as a domU kernel, thats the way we do it and debian does the same way now
<zul> thats the way weve done it since edgy as well
<pkl_> zul: I can't see where this pissing contest is going to be honest.  I said I'd update the config to use PAE.  My comments afterwards was just to try and prove I'n not a complete idiot.  Idiot maybe, but not a complete one.
<calc> BenC: here still?
<calc> BenC: i have the oops
<calc> BenC: i emailed you the oops output
<calc> BenC: going to fsck my disk now
<calc> BenC: showed as clean and oops the same after reboot and apt-get dist-upgrade attempt again
<yulin> Question: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/    differences between 2.6.20-mm1 and 2.6.20-mm2, maybe the difference between -mm1 and -mm2?
<crimsun> come again?
<yulin> 2.6.20-mm1 and 2.6.20-mm2 are directory in the http: directory
<crimsun> what are you attempting?
<crimsun> if you simply want to see a diff between the two, just grab http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/2.6.20-mm1.bz2 and http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/2.6.20-mm2.bz2 and use interdiff(1)
<yulin> sorry, my xchat has some problem in show text, wait for a moment, i change to weechat.
<yulin> i am back
<yulin> can you resend you msg?
<crimsun> if you simply want to see a diff between the two, just grab http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/2.6.20-mm1.bz2 and http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/2.6.20-mm2.bz2 and use interdiff(1)
<yulin> ok
<yulin> the patches in the two packages organized by what? time? effect? branch?
<yulin> our product will use 2.6.20 kernel for several monthes, but we often faced new hardwares such as southbridge, chipset, should i use the patches in -mm?
<yulin> Now i used the kernel source from feisty, where i can get the patch of ubuntu-kernel?
<crimsun> we don't carry broken-out patches.  Please see http://kernel.ubuntu.com/git/
<yulin> ok, i will git.
<yulin> q
<yulin> quit
<Kano> hi
<Kano> how about adding aufs, thats more stable then unionfs
<Kano> also 2 little kernel packages that only add new pci ids would be nice to have, now i always need to patch the source
<Kano> http://kanotix.com/files/kernel/kernel-update-pack/source/2.6.20-via-quirks.patch
<Kano> http://kanotix.com/files/kernel/kernel-update-pack/source/t-sinus_111card-2.6.16.diff
<mjg59> Kano: What does the first patch do?
<Kano> well thats the intel pci id of the via southboard fix
<Kano> in the kernel right now are only the amd boards, but the problem happens on the intel version too.
<Kano> the fix works fine, just needs to be enabled
<mjg59> Kano: Do you have a reference for the requirement?
<Kano> a similar thing for the 2nd patch. it only adds another pcmcia card
<Kano> ask locsmif
<Kano> on oftc.net
<Kano> he needed it
<mjg59> Kano: It would be helpful to have a complete description of the issue
<Kano> it is just the same issue like the well known via southbrigde bug
<Kano> just for the via chipset for intel cpus
<Kano> it is needed just for those board without bios update
<Kano> the 2nd patch is confirmed too by Adapter45 (online on this server)
#ubuntu-kernel 2007-07-07
* Starting logfile irclogs/ubuntu-kernel.log
<Layer8> hi all
<Layer8> i'd like to use an old edgy kernel-image unter feisty...would that work?
<Nafallo> hmm. anyone knows if there is support for the WWAN in Dell D630? :-)
#ubuntu-kernel 2007-07-08
<kraut> moin
<sacater> how do I find out if my hardware supports DMA
<sacater> its an old laptop
<sacater> Compaq Armada M700
<sacater> Im compiling my own kernel
<sacater> also, is lm_sensors in the kernel by default. A website says I need "Linux requires lm_sensors modules, sysfs sensors for kernels >= 2.6.0 or a running mbmon daemon"
<sacater> heelloo?
<pmjdebruijn> sacater, someone will answer you when they have time...
<Nafallo> I would say this is a development channel. maybe try #ubuntu? :-)
<Nafallo> "Ubuntu kernel development discussion ONLY" <-- that's pretty clear
<sacater> well
<sacater> it sort of concerns that
<sacater> I figured if anyone knew it would be you guys :D
<Nafallo> have you tried #ubuntu?
#ubuntu-kernel 2008-06-30
<mkrufky> oops, I asked this in the wrong channel before
<mkrufky>  can we merge the fix for bug #244005 (pull request included in bug report) ...  or do I have to send it to kernel team?
<mkrufky> ubotu is missing..... so....   " sms1xxx OOPS on 64 bit kernels "  https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/244005  
<rtg> mkrufky: just send the merge request to the kernel team mailling list.
<mkrufky> ok
<mkrufky> sent
<smb> pulling...
<Kano> hi BenC , rtg , did you get the pm lately?
<Kano> about the problems with xpress 1150/1200 chipset laptops
<BenC> Kano: I saw your photo, but I can't see what problem you're talking about
<Kano> it does not boot
<Kano> only using acpi=off
<BenC> Is the picture you sent of the boot when it fails, and by fail do you mean it freezes?
<BenC> these are all details needed
<BenC> "does not boot" is way too vague to properly diagnose anything
<Kano> BenC: the pic was done when the boot stopped, you saw that in the video link i gave you too
<mkrufky> (12:12:48 PM) smb: pulling...   <-- was this directed at me?  (it was right after I posted to kernel-team)  I haven't seen any commits to that tree since the early AM.  (sorry if i am nagging)
<smb> mkrufky, that was targetted generally at the channel to let all know I am doing something
<mkrufky> pulling, in general... ok cool... so i AM nagging, lol
<smb> mkrufky, but before pushing I want to run a test build, which takes a bit
<mkrufky> no problem.  
<mkrufky> my bad for not catching that OOPS before initial submission
<smb> mkrufky, sh.. happens. :)
<mkrufky> hehe
<BenC> Kano: no, I didn't see that because I didn't want the video
<Kano> well the pic is done when it stopped
<Kano> i guess the hd controller has lost interrupts
<mkrufky> uvcvideo merged into v4l-dvb devel branch 11 minutes ago!
<mkrufky> mauro asked Linus to pull it for 2.6.26 .... this late in the game?  ehhe..  anyway, no more external uvcvideo -- hurray!
<mkrufky> thanks, smb :-)
<smb> mkrufky, np :)
<Kano> btw. do you know that there is a madwifi branch which would support eeepc?
<Kano> just asked in madwifi channel
<mkrufky> ur askign the wrong question
<Kano> svn co http://svn.madwifi.org/madwifi/branches/madwifi-hal-0.10.5.6/ madwifi-ar5007
<Kano> one tester says it works
<Kano> but you have to backlist ath5k of course
<Kano> btw. here are 2 missing firmware files:
<Kano> http://www.linuxtv.org/downloads/firmware/dvb-usb-dtt200u-01.fw
<Kano> http://machts.net/Cinergy_HT_USB_XE/xc3028-v27.fw
#ubuntu-kernel 2008-07-01
<pd_> Hello, I've got a kernel packaging problem. I created a new  kernel source package and tried to compile it, but I'm getting a "Checking ABI for [arch]...previous or current ABI file missing!" error. I think that this occures 'cause I changed the ubuntu version, but I'm not sure how to fix the problem properly.
<pd_> I hope this question fits in the topic of this channel ;-)
<amitk> pd_: you can use 'skipabi=1' in the fakeroot command to bypass the abi check
<amitk> pd_: https://wiki.ubuntu.com/KernelMaintenance for details
<pd_> amitk: okay... thanks for the hint to the wiki page! I'll try to use the "Development cycle" section of the page to create own packages because I'd like to publish them in my launchpad ppa-
<xivulon> cking
<cking> xivulon: hi
<xivulon> hi there 
<xivulon> on 204133, I did ask slangasek and pitti
<xivulon> pitti agreed to update it, but steve decided to wait after .1
<cking> xivulon: OK. 
<xivulon> so we after the 3rd I will chase up steve and pitti again for an SRU
<cking> my concern was that it would not get into Intrepid
<xivulon> I wouldn't think that should be a major issue, also becase it is an important fix
<xivulon> On the other hand, I sent an email to szaka to move the patch upstream, but had no reply so far
<xivulon> I will nag him as well
<cking> xivulon: OK. Thanks for this. It will be interesting to see if szaka takes the patch into his code
<xivulon> as mentioned, I was planning to resume all that after point release
<cking> xivulon: if it's not too much to ask, can you keep me informed of the progress of the patch?
<xivulon> I will certainly do so!
<cking> xivulon: Many thanks!
<cking> xivulon: there was one more issue - that was the ntfs mount on with a dirty flag set  - was there a launch pad bug for this?
<xivulon> sort-of... there is 226622, it ended up being mostly an ex-post sweetener rather than a fix
<xivulon> the bug should probably be split into problem and solutions: 1 give a better error message 2 fix the problem at the root
<cking> xivulon: I suspect the dirty flag and ntfs mount can only be addressed by someone with deep knowledge of ntfs
<xivulon> cking I would guess so.
<xivulon> But it would be nice to be able to address/fix common cases. I assume that in many circumstances it is just the flag, while the underlying filesystem is in fact ok. So a consistency check might be enough.
<cking> xivulon: Interesting this as it's a userspace filesystem issue, so it's kind of a kernel bug but also an ntfs tools issue
<Monkey77> Hello, I hope my question is not off topic, I am looking to test a new driver which I asked GregKH to include in the kernel, he has put it in his staging kernel ( its the mimio whiteboard driver: http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=summary). To test that I really need a guide on how to do that in ubuntu.  Are there any walkthroughs so I can test it with the hardware?  I have only done custom 
<amitk> Monkey77: you could add the driver in linux-ubuntu-modules, compile it and install the .deb package to test it
<amitk> Our git trees are at http://kernel.ubuntu.com/git
<amitk> you want hardy-lum.git
<amitk> Monkey77: https://wiki.ubuntu.com/KernelMaintenanceStarter should get you started on building LUM
<BenC> I wish makedumpfile would get MIRd so the new kernel would build :/
<Monkey77> I assume that he has made the patch 2.6.26 or 2.6.27 ready.  Would you expect the patch to work on hardy kernels?
<amitk> Monkey77: if the driver is already in 2.6.26 we will get it when we do periodic syncs with Linus' tree. But if it isn't going to make 2.6.26, then we need to add it separtately to the Intrepid tree.
<amitk> Monkey77: Hardy is not compulsory, a patch against 2.6.26/27 will do fine.
<Monkey77> Its not in 2.6.26, its waiting for me to test it before it gets accepted further.  Thanks for your support
<amitk> Monkey77: do you run Ubuntu?
<Monkey77> amitk: yes
<amitk> Monkey77: Hardy? If so, you could consider installing the Intrepid kernel and providing a patch against it.
<Monkey77> The PC I have attached to the whiteboard is purely for getting this driver to work.  I will switch it to Intrepid (from hardy) and do as you suggest.
<amitk> Monkey77: You don't have to switch completely, just installing the intrepid kernel ought to be enough.
<Monkey77> Ok
<Monkey77> One further question, I also need to get a udev rule for the device (once the driver is working), where would I submit a patch for that?
<BenC> cking: emailed you the grub+last-good-boot description
<cking> BenC: Many thanks
<cking> BenC: There must be something screwy with the Email - I haven't received it yet.
<BenC> cking: Ooops, I sent it to your .co.uk
<cking> BenC: Ah.. and I don't pop the old account anymore.
<cking> probably went to /dev/null
 * lamont wonders wth "wlan0: RX deauthentication from 00:09:5b:67:48:e6 (reason=6)" is all about, and why he sees it several times an hour
<rtg> lamont: reason 6 - Class 2 frame received from nonauthenticated station. probably means the AP has deauthenticated your station for lack of activity.
<lamont> rtg: sadly, that makes all too much sense
 * lamont will consider adding a keepalive or some such
<rtg> lamont: it can hardly be a perceptible pause while it reauthenticates.
<lamont> it's clutter in my logfiles
<rtg> though I supose NM goes through DHCP again.
<lamont> OTOH, the heart of the issue is that, uh, it's plugged into the wired LAN
<lamont> NM doesn't do squat in this situation
<lamont> and so we play bouncy-bounce
<rtg> lamont: rf-kill switch?
<lamont> rtg: spoilsport. :-)
<lamont> how about an NM that'll DTRT (and let me teach it what that is) when both wired and wireless are available? :-)
<rtg> lamont: I think there is an outstanding bug wherein NM does not down the interface if its not in use.
<lamont> ah
 * lamont downs wlan0
<lamont> and then in a bit, we'll see if NM auto-ups it when the wired is gone on unsuspend
<rtg> it likely will.
<mkrufky> is lpia 32bit?
<amitk> mkrufky: yes it is
<mkrufky> thanks, amitk
<lamont> BenC: (or rtg? or...) does intrepid want to merge git-core 1.5.6-1 ish?  or are we happier with 1.5.4.3-1ubuntu2?
<lamont> 'cause I think that requires paperwork now
#ubuntu-kernel 2008-07-02
<BenC> lamont: newer == better, IMO
<BenC> No idea what is in the ubuntu changes though
<lamont> the current changes are using tcl8.4 instead of 8.5 (could proabbly chnage for intrepid??) and dropping the cvsps depends (universe)
<lamont> I was curious so I looked
<lamont> if I get bored tonight, maybe I'll prepare a merge to pester folks with
<lamont> just wanted you to have a chance to say "nonono" if you wanted to, before i worked.
<qense> I've got a bug with a patch for ubuntu-modules inside a comment: https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/196811
<qense> Do you think you can use it?
<qense> The patch comment: https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/196811/comments/16
<gnomefreak> what are the general rules for backporting kernels? AFAIK its a big no but would like it confirmed for someone here
<BenC> gnomefreak: yeah, big NO
<BenC> gnomefreak: we've considered it, but never justified the time and testing it would take
<BenC> gnomefreak: that may change for hardy (LTS) if we find it is warranted at some later point
<gnomefreak> BenC: thanks if i see the bug again ill let them know that its not gonna happen :)
<gnomefreak> its a driver IIRC that the bug is about but it requires kernel backport someone added but ill be back later and look at it
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-3.7 |  Latest news: 2.6.26 kernel is in Intrepid | Next meeting: July 8, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-3.8 |  Latest news: 2.6.26 kernel is in Intrepid | Next meeting: July 8, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<soren> mjg59: You're probably most likely to know this: Is the wattage reported by powertop reliable? I can get my laptop to report under 10W, which is only around twice that of my NSLU2, which sort of brings its usefulness/wattage ratio into question.
<soren> ...or does it not actually represent the "real" power consumption (i.e. what I will be billed by the power company)?
<mpetersen> Can anyone tell me the best way to build a kernel module package that will replace a linux-ubuntu-module (specifically drbd 0.8 to 0.8.2)  I built the package no problem, but I have to either --force-overwrite to install or end up with 2 drbd.ko modules?  
<BenC> mpetersen: put the other module in /lib/modules/`uname -r`/updates/ and it will override the one in lum
<mkrufky> !
<mkrufky> i wish i knew that 
<mkrufky> BenC: i can tell the v4l/dvb build system to install modules to THAT location if it detects an ubuntu dir
<mkrufky> ...that might help users that want bleeding edge driver support without worrying about trashing LUM or whatever's in-tree
<BenC> mkrufky: it's default for module-init-tools to handle that (IOW, not ubuntu/debian specific)
<mkrufky> thats very good to know -- i was previously not aware of that
<mkrufky> perhaps v4l/dvb should install to that location for everybody
<mkrufky> ....that would have avoided all the cx88 / saa7134 complaints after that alsa issue was addressed
<BenC> mkrufky: just remember, that's where lbm installs them too (which is how we can override drivers ourselves)
<mkrufky> hmm... "lbm" ?
<mkrufky> apparantly thats a popular acronym
<BenC> linux-backports-modules
<mkrufky> i should have known
<mkrufky> lol
<mkrufky> i will leave v4l/dvb as it is 
<mpetersen> BenC: so 'install -m644 -b -D drbd/drbd.$(KO)o $(CURDIR)/debian/$(PKGNAME)/lib/modules/$(KVERS)/updates/drbd.$(KO)o' instead of 'install -m644 -b -D drbd/drbd.$(KO)o $(CURDIR)/debian/$(PKGNAME)/lib/modules/$(KVERS)/ubuntu/block/drbd/drbd.$(KO)o' should work?  nifty, I'll try that.
#ubuntu-kernel 2008-07-03
<mjg59> soren: It's a function of your hardware. Some is accurate, some isn't. 10W sounds entirely plausible for an idle laptop (I can get mine to 8W with the screen on...)
<soren> mjg59: Cool. Thanks.
<mjg59> soren: It's difficult to accurate measure, too. Several systems will (at the firmware level) enable deeper power saving states on battery, so you can't compare the results with an external power meter.
<soren> Well, the thing is... I stumbled upon some numbers about the power consumption of NSLU2's, and I came to thinking about the usefulness/wattage ratio of it compared to my laptop... I bought the NSLU2 before powertop came around, so I didn't really have any idea how much power a laptop used.
<soren> I guess I just expected it to use enough less power to justify the lack of computing power, but now I'm not so sure.
<mjg59> Is that just the NSLU2, or is that with a disk as well?
<mjg59> Bear in mind that the NSLU2 will probably top out at around 6W, while the laptop will easily draw another 10W at load
<soren> mjg59: That was with a disk as well, allegedly.
<mjg59> soren: 3.5" disks are going to draw much more power than 2.5" ones
<soren> True. The 5W was indeed with a laptop disk.
<mjg59> That's probably one of the larger differences
<mjg59> But once you're above 2W, there's much less incentive to be low power
<mjg59> It's going to be plugged into AC the whole time, so...
<soren> About them laptop using more power under load: That's perfectly alright. It'll be idle 95% of the time.
<mjg59> Yeah
<mjg59> Old laptops are often better than high-end embedded hardware
<mjg59> From a PM point of view, at least
<soren> Oh, really? That's a very interesting data point. I have a few old Fujity Lifebooks collecting dust on a shelf.
<soren> Fujity means Fujitsu.
<mjg59> Heh
<soren> At least a 2:30 AM.
<soren> Gah..
<soren> At least *at* 2:30 AM.
<soren> Those things even have a touch screen. They're begging to be put to some sort of use somewhere. So many projects, so little time :(
<nightwish> hi! i'd like to know wether and when bug #199934 will be fixed in 8.04. a working patch is already attached, and i think the icp vortex support is still critical for many people running ubuntu on servers. at least it is for us (a german isp), as we're running all our internal and quite a lot of customer machines on ubuntu (currently 6.06 but would prefer to switch to 8.04 somewhen)
<ln-> i wouldn't hold my breath...
<ln-> nightwish: look at bug 65631, which is a somewhat similar case, and see how long did it take to get it fixed, despite the trivial patch being attached since the begin.
<nightwish> :o/
<cking> nightwish: am I right to assume the patch mentioned in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/199934/comments/4 fixes this issue?
<nightwish> cking: i used the diff attached to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/199934/comments/8 to patch the ubuntu sources, this one is working fine
<nightwish> the other one is only a fix for the scsi scan, which was a problem of 2.6.24.2 vanilla
<nightwish> ah no sorry i'm wrong
<nightwish> sec.
<cking> nightwish: Not sure why the bug has not been looked at. 
<nightwish> ok i checked both the one in comment 4 and in comment 8. the latter includes more code changes, but as i am not a developer i can't say if that's relevant for the fix. i just know that the diff in comment 8 definately works
<cking> nightwish: OK. - I will see what I can do to get this patch in - I will probably ask you to do some testing before it's accepted though.
<cking> it may need some thought to why it this patch is required and what it's trying to do though.
<nightwish> cking: ok. i've subscribed to the bug, so if you need my help, feel free to contact me (guido nickels) at any time.
<cking> nightwish: Thanks. I will see what I can do.
<amitk> BenC: who is going to do maintenance of the intrepid-ports tree - stuff like rebasing, prepping for uploads, uploading, etc.
<BenC> amitk: whoever cares about the ports
<BenC> amitk: so far, we've only had interest from a ps3 guy (and he has an account on zinc now)
<amitk> BenC: so there is no explicit assumption that the ports tree will be rebased on top of the Ubuntu tree?
<BenC> amitk: there's an explicit exception that it will never be rebased on our main tree :)
<amitk> I am trying to figure out the best way to establish a mobile tree...
<amitk> BenC: ah. So that is not the example I want to follow for the lpia tree. I want a way to keep in sync with the Ubuntu tree but still have ability to do separate uploads when needed.
<amitk> BenC: any thoughts?
<BenC> amitk: sounds like you want what we planned for the binary-custom flavors
<BenC> amitk: basically like xen was in edgy...a package that build-dep'd on linux-source, applied patches and built
<amitk> BenC: there is a desire to 'apply' the patches to the git tree rather than have them as a stack of patches applied at build time
<BenC> amitk: then the other alternative is a separate source package/git-tree that we will eventually merge back into our main tree
<BenC> Then you can rebase on the main tree whenever you want, and upload whenever you want
<BenC> So sort of like linux-ports but cloned from the main tree instead of being it's own unique tree
<amitk> BenC: true. The only problem being that this tree would contain patches to disable flavours in the main tree (the debian/ dir) and the debian dir will constantly change, making it impossible to rebase. It would be like generating a new patch everytime.
<amitk> this tree = lpia tree
<BenC> amitk: yeah, it wouldn't be pretty
<amitk> BenC: is it possible to have an alternate debian directory inside a package?
<amitk> so I can let debian/ from the main tree be and create a debian2/ for all lpia stuff... or am I on crack?
<BenC> amitk: git-mv debian debian2
<BenC> amitk: then rebasing will work
<mikkoc> hello, i need a favour
<mikkoc> can someone running ubuntu amd64 paste the default kernel config to some pastebin?
<mikkoc> i'd like to compile ubuntu's kernel on another distro
<mkrufky> mikkoc: on YOUR ubuntu box, take a look at /boot/config-`uname -r`
<mikkoc> mkrufky: i dont have an ubuntu box
<mikkoc> nor a live cd
<mikkoc> it doesnt take much time to "cat .config | nopaste" :)
<mkrufky> so, im logged on to an i386 right now, and i have an lpia next to me for testing
<mikkoc> or as an alternative, is there any place where i can find it on the web?
<mkrufky> i recommend you download the livecd and boot it
<mkrufky> btw, im not an ubuntu maintainer -- im a user just like you
<mkrufky> so my answers do not reflect ubuntu as a whole
<mkrufky> there is probably a place to find that info, but i dont know
<mkrufky> the easier answer is to download the cd and find out yourself...  unless somebody else has an answer
<mkrufky> im sorry if that isnt helpful enough -- i tried :-/
<mikkoc> np i appreciate it
<mkrufky> :-)
<smb> mikkoc, If you have the ubuntu sources from git, look at debian/config/amd64/config{,.generic}
<mikkoc> where do i find that?
<smb> mikkoc, you got the kernel sources from ubuntu?
<mikkoc> smb: nope
<mkrufky> http://kernel.ubuntu.com
<mkrufky> just surf gitweb
<mkrufky> you'll find the answer there
<smb> mikkoc, thought you wanted to compile ubuntu's kernel. but mkrufky is right. Either with gitweb or a complete git clone.
<smb> mikkoc, you need to paste together config and config.generic from the debian/config/amd64 directory
<mikkoc_> thx guys
#ubuntu-kernel 2008-07-05
<DanaG> Hmm, in the latest kernel changelog:    * ubuntu: Add some media drivers    * config: Enable misc media drivers    ---- any more specific info on what drivers?
<DanaG> Oh, and the packaged kernel now uses uvesafb... but v86d is not present in any packages.
<noelferreira> does anyone can give me some information about the 'keys getting stuck' bug: https://bugs.launchpad.net/ubuntu/+bug/124406 In my case disable ACPI workaroun resolves my problem. however it is not very good doesn't have ACPI. any help?
<noelferreira> does anyone can give me some information about the 'keys getting stuck' bug: https://bugs.launchpad.net/ubuntu/+bug/124406 In my case disable ACPI workaroun resolves my problem. however it is not very good doesn't have ACPI. any help?
<noelferreira> does anyone can give me some information about the 'keys getting stuck' bug: https://bugs.launchpad.net/ubuntu/+bug/124406 In my case disable ACPI workaroun resolves my problem. however it is not very good doesn't have ACPI. any help?
<poningru> allo allo
<poningru> need halp
<poningru> http://forums.msiwind.net/default-msiwind/have-the-wireless-drivers-but-t840.html
<poningru> its the driver for a new realtek chipset was wondering if anyone can take a look at it
<poningru> and offer comments?
<Kano> hi, anyone interested in a patch for uvcvideo/lum?
<Kano> to support medion e1210
<Kano> basically it is a trivial patch, similar to some acer hacks, just for 5986:0141
<Kano> http://kanotix.com/files/kernel/unused-patches/linux-ubuntu-modules-2.6.24-2.6.24.uvcvideo.medion-e1210.patch
#ubuntu-kernel 2008-07-06
<ion_> I uploaded a compcache-utils package to REVU, <http://revu.tauware.de/details.py?package=compcache>. It contains an init script to start compcache early and a debconf script to configure the size.
<bullgard4> [Hardy] What program causes the startup message "Starting kernel event manager"?
<crimsun> specifically, /sbin/udevd
<crimsun> although technically, it's the udev initscript
<crimsun> (log_begin_msg from /lib/lsb/init-functions)
<bullgard4> Thank you.
<crimsun> np
<Kano> hi
<Kano> rc9 is out...
<Kano> BenC: you can drop uvcvideo ubuntu patch, but you need to patch one id
<Kano> hi BenC , you fixed the trivial lrm issue :) do you want to sync with kernel rc9?
<Kano> will give you as soon as you do so my current patch for uvcvideo
<mkrufky> Kano: why not instead submit your uvcvideo patch to v4l-dvb and uvcvideo project, itself, so that everybody can have your patch?
<Kano> i dont like to ;)
<mkrufky> why?
<mkrufky> its just a device support patch -- it is just extra work to ask each distro to support small differences -- something like that is best to be merged upstream
<Kano> thats the reason
<Kano> http://kanotix.com/files/kernel/unused-patches/linux-ubuntu-modules-2.6.24-2.6.24.uvcvideo.medion-e1210.patch
<Kano> with correct option this will do with 2.6.26 for uvcvideo - you know that you can drop that one in ubuntu dir
<Kano> thats the patch for hardy
<Kano> absolutely trivial
<Kano> tested by 2 users already
<mkrufky> its silly that you dont just send the patch to the uvcvideo guys
<Kano> then i have to wait till you adopt it anyway, as i base my kernels on yours
<Kano> what other distros do does not matter for me
<mkrufky> so instead, just keep it in your kernel and dont share it with them, so you have to remember to apply that patch on every new kernel release
<mkrufky> that is the spirit of this open source
<mkrufky> (sarcasm)
<Kano> i dislike mailinglists
<Kano> gotcha
<noelferreira> any solutions for the keys geting stuck bug?
<noelferreira> pleaaaaaaaaaaase
#ubuntu-kernel 2009-06-29
<eshaase> hyperair: yes, the default ubuntu kernel supports it
<eshaase> i'm testing out one of the ubuntu kernel team's 2.6.30 kernels and it works great except I don't have any audio, can someone steer me in the right direction please? Perhaps I need to compile in another module or something? I have a "Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller"
<AceLan> eshaase: maybe it just be muted, have you run alsamixer to check it?
<eshaase> AceLan: yeah, i've checked and its not muted
<TheMuso> eshaase: Have you tried with kernel 2.6.31, or a recent alsa-driver snapshot?
<eshaase> TheMuso: i'll try with 2.6.31
<eshaase> TheMuso: i know what alsa is but what is alsa-driver?
<TheMuso> eshaase: Its the component of alsa that deals with the kernel drivers.
<TheMuso> eshaase: Anyway try 2.6.31 as that should pretty much have the latest alsa code.
<TheMuso> bar a few bits that are not in the mainline kernel yet, but I don't think they will matter.
<eshaase> ok, i'll give that a shot, brb
<lesshaste> hi
<lesshaste> can anyone tell me when jaunty uses kexec to boot ?  I am trying to debug a problem where grub is skipped after a poweroff and it looks suspiciously like kexec is being used by jaunty
<lesshaste> but I could be wrong
<andersk> Is the kexec-tools package installed? 
<lesshaste> andersk: no
<andersk> Is there an /etc/init.d/kexec-load? 
<lesshaste> no
<andersk> Wait--it's skipped after a _poweroff_, not after a reboot?  That isn't kexec, then. 
<lesshaste> that's right
<lesshaste> it's very odd
<lesshaste> restart works as normal
<lesshaste> but after shutdown -P or -h grub is skipped
<lesshaste> and I/we have no idea how to start debugging it
<andersk> Maybe this is some kind of grub savedefault thing?  I don't remember how that works. 
<lesshaste> interesting.. it does take 15 seconds to boot as well which just generally seemed fast to me
<lesshaste> according to dmesg that is
<lesshaste> andersk: I don't think it's that... my menu.1st is quite boring and has timeout 10 ,  http://pastebin.com/f607db10f
<andersk> Your `default 8` is out of range; you have 7 entries (0-6). 
<lesshaste> andersk: aargh.. I just gave you the wrong file sorry
<lesshaste> let me fix that
<lesshaste> andersk: ok  http://launchpadlibrarian.net/28500841/menu.lst
<lesshaste> andersk: all the info is in the bug report https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/389930
<ubot3> Malone bug 389930 in grub "grub menu skipped after shutdown" [Low,New] 
<lesshaste> andersk: sorry for the delay
<lesshaste> hi tgpraveen 
<tgpraveen> hi lesshaste
<lesshaste> tgpraveen: do you happen to know anything about the kernel? :) Everyone I ask turns out to be a newbie
<tgpraveen> lol i am sorry i too am a newbie
<tgpraveen> anyways ask what u want to and i see a lot of expereienced ppl in the chat list
<tgpraveen> so someone will answer
<lesshaste> tgpraveen: they don't reply :(
<tgpraveen> lesshaste: hmm they might be busy. my advice try the mailing list
<lesshaste> is there a ubuntu kernel mailing list?
<lesshaste> ah yes.. I just found it
<lesshaste> maybe a non newbie will arrive ...
<lesshaste> tgpraveen: out of interest.. are you here to ask a question too?
<tgpraveen> not really just to browse around
<tgpraveen> u know see what others are talking abt
<tgpraveen> and out of  intrest what is your question
<lesshaste> well..  after a poweroff (shutdown -h or shutdown -P) my laptop skips grub when it restarts
<lesshaste> but after a restart (shutdown -r) it doesn't
<tgpraveen> hmm i am not sure but that doesnt really sound like a kernel issue though i might be wrong
<tgpraveen> maybe u should try #ubuntu-devel
<lesshaste> ok
<lesshaste> tgpraveen: the problem is that there are just facts I am missing
<lesshaste> tgpraveen: does ubuntu have some mechanism for kick starting the kernel extra quick that could be causing this
<lesshaste> tgpraveen: I also notice the boot time is very fast
<tgpraveen> lesshaste: karmic or jaunty?
<lesshaste> jaunty
<tgpraveen> hmm dont really know. dont ask in #ubuntu-devel for jaunty
<tgpraveen> i guess u should file a bug report on launchpad
<lesshaste> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/389930
<tgpraveen> and wait for somebody to answer here
<ubot3> Malone bug 389930 in grub "grub menu skipped after shutdown" [Low,New] 
<lesshaste> :)
<lesshaste> it got assigned to the wrong place I think
<tgpraveen> yes gnome power mgr isnot the right package
<lesshaste> nor is grub
<lesshaste> where it is assigned now
<apw> smb, we expect compat-wireless to be newer than the kernel in general right?
<apw> newer but still compatible
<smb> apw, a) yes (I would) and b) hopefully (as in compat).
<smb> apw, why?
<apw> am trying to update lbm, but it seems behind mainline for one accessor
<apw> so i suspect its not been updates since the merge window closed
<apw> so i guess fixing it (i think its gonna be easy) is worth it else we cannot upload it, nor linux-meta
<smb> apw, Have you checked with the compat-wireless sources or just with what we have in lbm?
<apw> this is after using the update script to get the latest version from the repo
<smb> Ok, which driver do we talk of?
<apw> updates/compat-wireless-2.6/drivers/net/wireless/mac80211_hwsim.c
<smb> Probably the other approach would be to go with the slightly outdated driver in lbm until the sources get updated. After all lbm is only best-effort and opt-in
<apw> is the file with the error, sounds like a simulator too
<smb> Oh, it actually fails to build
<apw> well i think the problem is that _all_ versions would not compile, cause its out of date wtf to the mainline kernel
<apw> yeah fails to build right now
<apw> i may have fixed it, but i am just trying to gauge if it is correct to fix it in this context, i think it likely is
<smb> I would say yes. Better to have a compiling package at that stage
<smb> We would likely pick up an updated upstream as soon as there is one
<smb> (upstream being the compat-wireless sourcE)
<apw> right ... it working is the bit that i see as best effort.  we need something in the package which builds and installs at least
<apw> ok .. good then i think i am going the right way :)  thanks
<smb> Yes, that sounds much sensible. I guess so. :) NP
<lesshaste> hi all
<lesshaste> I have sort of fixed my weird grub error but ... what part of linux is running when the grub menu is showing?
<lesshaste> presumably not the kernel yet
<_ruben> grub is
<_ruben> bios -> grub -> linux
<lesshaste> _ruben: ok... so my problem is that grub doesn't display on the screen after a poweroff
<lesshaste> _ruben: so you can't see the menu
<lesshaste> _ruben: it does display after a restart (shutdown -r now) 
<_ruben> sounds like a bios issue
<lesshaste> _ruben: it is running in both cases I now realise
<lesshaste> is there anything grub could do in theory to initialise whatever the BIOS has failed to?
<lesshaste> actually.. is it worth trying grub2?
<_ruben> well .. if grub doesnt show up at all, there's nothign grub can do .. unless grub breaks after getting started but prior to outputing anything
<apw> lesshaste, the kernel is definatly not involved in the loading the kernel, all that is grub code
<apw> i assume this behaviour is not affected by kexec being installed/not install.  ie. if you remove kexec nothing changes
<apw> (it cannot be related of course as kexec only executed once the kernel is up)
 * kdub is having a hard time finding a bug to be useful with :(
<hyperair> could i persuade someone here to compile acpi-cpufreq as a module?
<hyperair> as opposed to compiled into the kernel
<hyperair> bug #355232
<ubot3> Malone bug 355232 in linux "acpi-cpufreq/powernow-k8 should not be built-in into the kernel image" [Low,Triaged] https://launchpad.net/bugs/355232
<smb> kdub, what feels like the main problem? Too unspecific data or unknown areas?
<kdub> smb: unknown areas in working with all the tools, i suppose
<lesshaste> apw: thanks...it's all a little mysterious to me
<kdub> and managing the configurations, and ways to test
<kdub> smb: it feels like the headache that always happens from going from theory to practice, if you know what i mean
<apw> kdub ... heh don't be dissheartened, its a steep curve getting into the kernel for sure
<smb> kdub, I guess so. Probably the way to go is pick one and ask for things on how to proceed here
<apw> therre are few packages the same size ... ooffice, X server, little else
<apw> smb, perhaps have a sneak look and see if there is something simple on there, a nice cherry-pick or something
<smb> lesshaste, Mysteriously I think grub just uses the simple text mode that should be initialized by the BIOS. Do you get any visual feedback (like bios screen)?
<lesshaste> smb: I can enter the bios setup by pressing esc or f1... but after a poweroff I just see the Toshiba logo and actually there is a slight change to the screeen when I assume grub is loaded
<smb> apw, Maybe. I have not looked into the community section but probably a lot there are old ones without much feedback...
<lesshaste> smb: little bits of the top of the lettering become blacked out :)
<lesshaste> smb: did I misunderstand the question?
<apw> lesshaste, normally there is a shift of font, to my eye the font gets 'shorter' vertically when the kernel loads the console fonts up
<smb> lesshaste, No, that was what I meant. Is there any control in the BIOS about which gfx should get initialized. Not sure this is a dead lead, but on some laptops I could select at least whether lcp or crt should be primary. On some destops there was a selection about agp or pci sometimes...
<apw> smb, sometimes they allow disabling the 'onboard' graphics so that if you stick in a second card it uses that ... perhaps thats got turned on when there is not one installed
<lesshaste> the only "display" options I see are "power on display = auto-selected" which can be changed to LCD+Analog RGB
<lesshaste> there is a mysterious "execute-disable bit capability" ?! :)
<lesshaste> everything else is fairly clear
<apw> lesshaste, that enabled NX support in the processor
<apw> or more specifically prevents disabling of the NX support in the processor
<apw> to allow buggy OSs to boot in the face of the new support
<apw> NX allows us to mark the stack non-executable to prevent overflows being so useful
<lesshaste> thanks
<lesshaste> there is also an option for virtualisation technology I see :)
<apw> yep same thing, turns off support for vmx extensions to prevent OSs which don't expect it from blue-screening, erm, i mean crashing :)
<lesshaste> :)
<lesshaste> bioses should really come with man pages
<lesshaste> :)
<apw> what make of machine is this?
<lesshaste> toshiba tecra a9
<apw> nnng.  what is toshiba up to
<lesshaste> I was going to post to the grub mailing list
<lesshaste> but I see they don't support anything before grub2 anymore
<smb> lesshaste, One desperate thing to try might be to uncomment the default line in the grub menu.lst that does some colouring. Not that Toshiba did something nice as setting default colours to black on black...
<smb> But I cannot remember anything in grub to enable a specific video mode... apw or cking do you?
<apw> there is a terminal command i think, never seen it required tho
<cking> do you need to change colours in grub 0.97?
<smb> cking, It is unclear whether colours are enough. Just brought up that and there would be a default line in the standard grub menu
<smb> The general symptom is that grub menu does not display after cold start but after reboot
<lesshaste> smb: interesting!
<lesshaste> I'm just checking if there is a bios upgrade too
<smb> kdub, We will try to find one bug to start of tomorrow, if that i ok with you...
<lesshaste> smb: well... it turns out it has been reported before https://bugs.launchpad.net/ubuntu/+source/grub/+bug/374823
<ubot3> Malone bug 374823 in grub "GRUB menu not showing up at cold boot" [Undecided,New] 
<cking> lesshaste: from what I can recall, grub does not twiddle with BIOS video modes at all, so this is part of the problem.
<lesshaste> cking: yes I think the solution may be to try grub2
<lesshaste> cking: as no one at grub will fix a legacy bug in any case
<cking> unless there is a really compelling reason to put the effort into addressing this for legacy grub
<lesshaste> cking: just another annoying bug :)  You can always just memorise the order of entries in menu.1st :)
<lesshaste> or boot and then restart
<cking> yeah, but that's unpleasant.
<lesshaste> right
<lesshaste> but I somehow suspect it won't come under "compelling" for the developers
<Unggnu> hi all
<Unggnu> Is it possible that the 2.6.30-10 initramfs script has changed? I always got the wrong keyboard layout with it while 2.6.30-9 works fine. The keyboard layout entry in console-setup seems to be the same in both initrds. Any idea?
<Unggnu> I need the correct keyboard layout for dm-crypt
<cjwatson> Unggnu: known bug, if you want to figure out what's going wrong feel free as I haven't had a chance yet. bug 392218
<ubot3> Malone bug 392218 in console-setup "Console font not accepted after boot up" [High,Triaged] https://launchpad.net/bugs/392218
<cjwatson> (the description is a bit too specific, don't worry about that ...)
<cjwatson> lesshaste: I rather suspect grub2 *will* work better, as it initialises a graphical mode by default and therefore is bound to twiddle the video mode
<Unggnu> cjwatson: thx
<Unggnu> Btw. I got around 10 seconds boot time with the 2.6.30-8 in Karmic I guess
<Unggnu> with fastboot
<masterkernel> can someone tell me what the stable-review patches on kernel.org are
<Unggnu> but after -9 I got around 14
<masterkernel> and what is fastboot?
<Unggnu> a boot option
<Unggnu> Around 2 seconds faster in my case
<masterkernel> can it be used in jaunty?
<Unggnu> no
<Unggnu> Since 2.6.29
<masterkernel> even with a new kernel?
<Unggnu> If it is >=2.6.29 yes
<masterkernel> cool. i'll have to try that
<Unggnu> Isn't much anyway. I just wondered why there is a difference of four seconds or around 40% between this two kernel releases
<Unggnu> masterkernel: http://lwn.net/Articles/314808/
<masterkernel> thanks Unggnu
<_ruben> hrm .. just did a dist-upgrade (including kernel) on my jaunty system .. now it fails to boot because it cant find my lvm
<apw> <apw> smb, do you know if it is safe to upload -lbm when the kernel's packages are not yet accepted?
<apw> <apw> the only mention of fastboot is the BSDism, meaning do not check the disks on reboot
<smb> apw, As far as I know it is save as it will depwait for the kernel
<apw> ok cool then ... smb i have a karmic -lbm for upload ;)
<smb> apw, I suspected that much. Will have a look
<apw> in the normal place :)
 * smb thinks that sound like conspiracy :)
<apw> smb, ok the git tree is pushed too
<apw> iit is also built in my ppa: https://edge.launchpad.net/~apw/+archive/daily/
<apw> heh yeah, i am out to confuse you with all the changing about
<smb> Well I can see in debdiff that is a little scary
 * apw has a look
<apw> smb, you got a link to the debdiff or doing that locally?
 * apw feels he is missing a trick somewhere
<smb> apw, I did it locally but slightly wrong. So it is probably not as scary as the diff between that and Jaunty ;-) Doing it right in a sec
<apw> heheh
 * apw does the same, the diff looks ok i think
<smb> apw, Mostly yes. I am a bit confused by that strange change of compat-wireless master fom 2009-06-12 to 2009-06-10...
<apw> that was an error in my previous version, a missunderstanding of how thye were named
<apw> it should always have been -10
<apw> i did it on the 12th but the tree i took was the 10th tree, and i miss recorded that
<smb> apw, And your changeslog in the package might be different from the tree ?
<apw> how so?
<smb> I just pulled and in git 1-7 has two lines, while in the package diff it looks like 5
<apw>   [ Andy Whitcroft ]
<apw>   * Update compat-wireless to master-2009-06-19
<apw>   * Bump ABI
<apw>   * update compat-wireless to track changes to skb dst accessors
<apw>   * update compat-wireless to track changes to ALIGN(foo, NETDEV_ALIGN)
<apw>   * update compat-wireless to track removal of FIRMWARE_NAME_MAX
<_ruben> hmm .. booting the -11 kernel does work .. must be something flakey with -13 or its initrd
<lesshaste> smb, hi again
<lesshaste> smb, I fixed the grub problem in the end
<smb> lesshaste, So what did you change?
<lesshaste> smb, I upgraded to grub2, in short
<lesshaste> smb, which has completely different display routines it seems
<lesshaste> smb, upgrading to grub 2 is not exactly user friendly at present, at least on jaunty
<lesshaste> but with a little editing it worked
<smb> lesshaste, Hm, guess that counts as a work-around. I wonder what the heck is then worng with the grub1-yourbios interaction...
<lesshaste> smb, it's a good question.. did I show you the duplicate bug with the people talking about workarounds?
<lesshaste> smb, I feel I fixed this bug more or less on my own.. I hope someone at ubuntu will at least read https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/389930 now!
<cjwatson> smb: grub1 doesn't reinitialise the video mode itself *shrug*
<ubot3> Malone bug 389930 in grub "grub menu does not display after cold boot" [Low,New] 
<lesshaste> cjwatson, the sudo apt-get install grub-pc command made a real mess of menu.lst
<cjwatson> lesshaste: huh? several people have read it. It now sounds like updating to grub2 is sufficient, and since grub2 will be the default in karmic, it sounds as though there's effectively nothing to do
<cjwatson> lesshaste: made a real mess how?
<lesshaste> cjwatson, there is a point where it says it has used "kopt" to find a command line and asks you to check it
<lesshaste> cjwatson, it presented a blank line 
<lesshaste> cjwatson, then when I just pushed on it added several lines with 80 or so copies of some ansi character that looks like an A
<lesshaste> to menu.lst
<cjwatson> nothing wrong with that
<lesshaste> this apart from it still using root instead of uuid
<cjwatson> it's a divider
<cjwatson> the uuid thing was broken in jaunty but is fixed in karmic
<lesshaste> cjwatson, well someone could close the bug I suppose :)
<lesshaste> and the duplicate
<_ruben> ouch .. i found out why my -13 kernel wouldnt boot .. i used tasksel to remove "virtual machine host" .. which removed lvm2 !!
<lesshaste> _ruben, eek!
<_ruben> reinstalled lvm2 .. it updated initrd .. et voila .. it boots
<lesshaste> cjwatson, the blank line is correct? It's quite confusing for a poor unsuspecting user
<cjwatson> lesshaste: looks like it means you have no special parameters beyond the defaults
<lesshaste> cjwatson, sort of... it also added back in default parameters
<lesshaste> cjwatson, I had removed quiet and splash
<lesshaste> cjwatson, and it added them back it seems
<cjwatson> feel free to file a bug. hardly qualifies as making a real mess though.
<cjwatson> the only thing that seems like a real problem is the root/uuid stuff, which like I say is fixed in karmic.
<lesshaste> ok
<cjwatson> (real problem: by which I mean that otherwise it should still have booted fine)
<lesshaste> cjwatson, no I thought the A characters were the mess. I didn't realise they would be harmless and was too scared to test it
<cjwatson> they're a horizontal line when interpreted in the relevant character encoding
<lesshaste> also, I see that it was expecting kopt= lines now
<cjwatson> title           `echo âââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ | iconv -f utf-8 -t cp437`
<cjwatson> ... is where that divider comes from
<lesshaste> as opposed to parameters after the kernel name
<cjwatson> CP437 being one of the old DOS code pages
<cjwatson> lesshaste: yes, that's how you were supposed to edit the grub1 menu.lst file
<lesshaste> yes
<lesshaste> well sort of.. :)
<lesshaste> the default isn't like that
<lesshaste> so you can't blame the user for copying the default
<cjwatson> if you just edit the bit after the kernel name and not kopt=, then the next update-grub will overwrite your changes
<lesshaste> right
<cjwatson> I don't blame the user, I blame the incredibly dreadful old menu.lst format.
<lesshaste> :)
<cjwatson> but there's only a limited amount we can do about that
<cjwatson> I'd rather focus effort on making the new world better
<lesshaste> cjwatson, oh about your comment in the other channel, having just edited menu.lst by hand I was a little nervous it wouldn't boot at all :)
<lesshaste> in any case, grub 2 works so all is great... I assume the docs will be tidied up by the time karmic comes out...
<lesshaste> now onto the next bug :)
<cjwatson> we probably ought to do something with defoptions= in menu.lst
<lesshaste> cjwatson, more important would be to fix the upgrade script for jaunty
<lesshaste> cjwatson, is it much more work than just copying the karmic fix?
<cjwatson> I'm not interested in fixing the upgrade script for jaunty, really
<cjwatson> it was a proof of concept so that we could get some degree of testing
<lesshaste> would you mind if someone else fixed it?
<cjwatson> we aren't really intending the majority of people to upgrade to grub2 in jaunty, just a few intrepid (ahem) souls
<cjwatson> not especially
<lesshaste> :)
<cjwatson> but I'm not sure it would meet the stable update guidelines
<cjwatson> karmic and beyond is what we're actually interested in for grub2
<cjwatson> it's unlikely that you'll be able to do a really good job of jaunty without a much more sweeping update, which would definitely not meet the stable update guidelines
<lesshaste> ok..maybe it should just be removed for jaunty
<lesshaste> as it is broken
<cjwatson> it's not broken
<lesshaste> and added in some super flaky repository
<cjwatson> it's just not as good as it could be
<cjwatson> but that applies to lots of software
<cjwatson> we can't remove packages once they land in a release anyway
<lesshaste> well broken in the sense that a normal user might not be able to boot their computer after using it
<cjwatson> we used the jaunty package for a systematic test on lots of hardware
<cjwatson> the results were actually very good
<cjwatson> so I'm not all that worried
<lesshaste> ok.. I know when I am defeated :)
<cjwatson> I'd be fine with us fixing the root/uuid thing in a jaunty update
<cjwatson> that's fairly obvious and self-contained
<cjwatson> but I don't think we should commit to really extensive work on jaunty's grub2
<lesshaste> I think that's what I was saying!
<lesshaste> what did you think I meant?
<cjwatson> you could have been talking about any of the things you were commenting on in the grub2 upgrade, such as the kopt/defoptions thing
<lesshaste> ah no
<lesshaste> just the root/uuid thing
<cjwatson> or the fact that jaunty's installer doesn't know that grub2 can boot of LVM
<cjwatson> off
<cjwatson> or any of the other things we know are broken in jaunty
<lesshaste> well in any case, thanks for the help
<lesshaste> and good luck with the grub work in general
<cjwatson> there is actually a bug open on jaunty for the root/uuid thing
<cjwatson> so if somebody wants to have at that, they should go right ahead :-)
<lesshaste> :)
<lesshaste> I have a lot more serious bugs to report now :)
<cjwatson> bug 376879
<ubot3> Malone bug 376879 in grub2 "grub2 installer modifies grub 0.97 menu.lst incorrectly and fails to chainload grub2" [Medium,In progress] https://launchpad.net/bugs/376879
<lesshaste> like the one that stops my dvd player working at all
<lesshaste> bye for now
<lesshaste> and thanks again
<cjwatson> apw: actually, ^- that's still assigned to you. fancy producing a diff against jaunty?
<apw> cjwatson, will check it out thanks for the prod
<manjo> smb, I want to update stuff under ubuntu tree in karmic.. what is the usual procedure ? can you point me to a wiki ? 
<smb> manjo, The current procedure would be ask apw 
<apw> heh ... manjo yep i saw that mentioned in our 'whats next' email
<apw> let me get this damn package uploaded then we can talk about it
<manjo> ok
<apw> as i have started looking at ndiswrapper
<manjo> yeah I am doing the same 
<manjo> probably we are duplicating effort
<apw> manjo, i think i have it done already ndiswrapper 
<apw> am uploading a test kernel now
<manjo> ah cool... so I can take that process and rinse repeat
<apw> we obviously need to coordinate :)
<manjo> ok will wait for you ping 
<apw> cool as
 * manjo breaks for coffee
<lesshaste> I am sorry this is probably a faq but can I install jaunty kernel on hardy?
<lesshaste> my dvd drive doesn't work
<lesshaste> apw: have you got a repository for newer kernels for hardy by any chance?
<apw> lesshaste, jaunrty kernel will need other deps you don't have so ... unlikely to work
<apw> intrepid might work
<lesshaste> apw: I was looking at https://launchpad.net/~apw/+archive/ppa and thinking that might be you
<apw> yeah that is me
<apw> nothing new in there for hardy tho
<lesshaste> ah
<lesshaste> I am trying to work out why my dvd drive doesn't work
<lesshaste> I thought testing a new kernel might help
<lesshaste> I get lots of lovely errors :)
<lesshaste> I assume trying to install a jaunty kernel and just letting it resolve dependencies is a bad plan
<lesshaste> the problems look similar to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/223780 but I can show you dmesg if you like as it is full of juicy information and errors :)
<ubot3> Malone bug 223780 in linux "hdc: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }" [High,Fix released] 
<lesshaste> rebooting...
<lesshaste> this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/223780 is pretty fatal for me.. my system completely locks if i try to use brasero for example
<ubot3> Malone bug 223780 in linux "hdc: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }" [High,Fix released] 
<lesshaste> hard locks I should say
<lesshaste> is hardy too old for anyone to worry about?
<lesshaste> upgrading to jaunty looks somewhat painful :(
<apw> hardy is supported still.
<smb> What worries me a little bit is "As a result cable detection
<smb> becomes less reliable when compared with 2.6.24 but the affected drives are
<smb> useable again."
<Keybuk> hmm
<Keybuk> Linux had another one of those "oh noes! no memory!" fits
<Keybuk> when there was plenty
<apw> Keybuk, did we use to record the dmidecode output somewhere, or did i imagine that
<apw> Keybuk, running i386?  ZONE_NORMAL exhausted, or KVA ?
<Keybuk> apw: I've seen it on i386 and amd64
<Keybuk> not sure what the latter bit means
<Keybuk> apw: the kernel exports dmi information under /sys
<apw> kernel virtual address space
<apw> Keybuk, in hardy?
<Keybuk> jaunty and karmic
<apw> yeah thats my memory too
<apw> just thought i remembered something early boot slurping it up for something, hal perhaps to use
<Keybuk> /sys/devices/virtual/dmi/id/
<apw> on older releases
#ubuntu-kernel 2009-06-30
<vi390> hi, how can I get openVZ kernels with jaunty
<slytherin> Is ATI KMS configured/enabled in karmic kernels? The kernel upstream changelog says it is enabled for non-x86.
<mdz> slytherin, the config used is in /boot/config-`uname -r`
<mdz> slytherin, I believe the relevant option is CONFIG_DRM_RADEON_KMS
<mdz> it doesn't seem to be set at the moment in Karmic
<mdz> though I believe apw has a kernel build with it enabled
<apw> that code comes in the 2.6.31-rc1 update, which is the next kernel for karmic.  where it is enabled by default
<slytherin> mdz: I haven't installed karmic yet. I plan to upgrade my ibook (powerpc) once the KMS is enabled.
<slytherin> apw: thanks for info.
<apw> there is an older KMS enabled kernel available in one of my PPAs
<slytherin> apw: my machine is powerpc arch, hence PPAs are not useful to me.
<apw> the powerpc kernels in karmic are lagging somewhat right now
<slytherin> apw: by the way, the changelog for linux package in karmic says that it is rebased on 2.6.31-rc1. So I believe once it builds properly it will have KMS.
<apw> right, it does have the code but the ports architectures don't seem to be building right now
<slytherin> apw: anyway I can help to fix it?
<apw> to be honest i've not even looked yet at why they arn't building.  the ports maintainers normally sort that out
<slytherin> which means I have to bug NCommander
<apw> yeah there are a couple of them i think
<apw> Keybuk, hey ... the moving from 486 to 586 discussion for i386 architecture, where has that gotten to?  i am trying to work out if i need to re-integrate the 386 kernel flavour
<Keybuk> apw: still waiting on a 586 build to test with
<apw> thanks for the info
<bullgard4> Since upgrading from 2.6.24-24-generic to 2.6.28-13-generic the number of loaded kernel modules almost cut in half. Why?
<smb> bullgard4, because most drivers are built-in
<bullgard4> smb: Thank you.
<vi390> can somebody tell me if there is any openVZ kernels for jaunty ?
 * hyperair doesn't think so
<hyperair> you could dig around the PPAs and see, though
<smb> manjo, look at the makefile of dmraid as it is before. you only get one .ko
<manjo> smb, I did not change the makefile ... and it produced many kos
<apw> yeah i think he is right, its makeing a .ko per .c there
<manjo> dm-raid45.ko  dm-message.ko dm-region-hash.ko 
<smb> after importing the new version or before?
<apw> before for sure
<apw> obj-$(CONFIG_DM_RAID45) += dm-raid4-5.o dm-mem-cache.o dm-region_hash.o dm-message.o
<smb> obj-$(CONFIG_DM_RAID45) += dm-raid4-5.o dm-mem-cache.o dm-region_hash.o dm-message.o
<apw> that is adding them raw, so each is a separate module
<smb> that is one .ko
<apw> smb, nope
<apw> you see
<apw> dmraid-obj = foo.o bar .o
<apw> if you merge .o's to make a .ko
<smb> so?
<apw> obj-$(CONFIG_TLSUP) := tlsup.o
<apw> tlsup-objs := tlsup_mod.o tlsup_acpi.o tlsup_backlight.o tlsup_hotkeys.o tlsup_radios.o
<apw> that construction makes one .ko out of a bunch of .o's
<apw> obj-$(CONFIG_DM_RAID45) += dm-raid4-5.o dm-mem-cache.o dm-region_hash.o dm-message.o
<apw> that form makes one .ko per .o
<smb> Hm, ok , you are right here. Not sure we actually wanted that
<apw> yeah if it worked using the first form, then things seem less worrying
<manjo> apw, I thought we changed it to be that way... so that was a mistake you say ? 
<apw> i don't know for sure one way or the other right now
<manjo> ok how about this ? 
<manjo> I use the makefile that came with the patch
<manjo> and build the ko in ubuntu ? 
<manjo> throw away the old make file 
<apw> what does that one look like
<manjo> I wanted to do that originally
<smb> The problem to me seems that drivers/md also produces similar modules.
<manjo> yes it does 
<smb> I guess the renaming is the critical part here
<apw> yes they have been renamed there may be some other renames in the code we cannot see
<smb> But probably it would make much more sense to use the form to produce only the dm-raid module including all the code
<apw> manjo, can you pastebin the new Makefile
<manjo> yes
<apw> so we can see what its like, its likely an external module build job, whjich is not usable without mod in the kernel
<manjo> apw, heh the new Makefile does the same thing 
<manjo> +obj-$(CONFIG_DM_RAID45)                += dm-raid45.o dm-log.o dm-memcache.o \
<manjo> +                                  dm-region-hash.o dm-message.o
<smb> I believe it produced modules differently named
<smb> dm-region-hash.o in drivers
<smb> and dm-region_hash.o in ubuntu
<apw> manjo, can you pint me at the original patch
<manjo>  http://people.redhat.com/~heinzm/sw/dm/dm-raid45/
<manjo> smb, when you apply the patch it no longer produces dm-region_hash.c 
<manjo> but produces  dm-region-hash.c
<smb> apw, I guess what happened was exactly that. Take the patch and the files. And to avoid duplicated rename on
<smb> but that still leaves the risk of duplicate symbols
<apw> yeah ... is a little worrying
<smb> So IMO the simples solution is to import it the other way
<smb> replace the makefile to build one module
<manjo> also does not produce dm-mem-cache.c but it produces dm-memcache.c 
<apw> which one?  the old?
<manjo> I think this is what we need to do .. throw away the old ones 
<manjo> use the new patch to produce one module 
<smb> Neither dm-mem-cache nor dm-message are in drivers/md, but this might be preparations to get it merged upstream
<manjo> right ... apw smb  are you in agreement with throwing away the old stuff in /ubuntu/ and makeing dmraid as one module ? 
<apw> dmraid4-5 as one module
<smb> yep
<apw> if so, thats the thing to try yes
<manjo> so we will not have many kos under dmraid4-5
<apw> apply the patch, copy the changed/new files over
<apw> and then use the -objs form to make one .ko
<smb> manjo, one more second, let me check something
<apw> then see if it will build/boot/load
<manjo> yeah actually I have done all that ... just need to make one module ..
<apw> the tlsup module is a good example of how to do that
<smb> dm-raid45-objs :=       dm-raid4-5.o dm-log.o dm-mem-cache.o \
<smb>                         dm-region_hash.o dm-message.o
<smb> obj-m                   += dm-raid45.o
<smb> that is the makefile in Hardy lum for it
<apw> heh
<apw> so we know that that works then ... good
<manjo> ok one module it is ... one line change in makefile 
<apw> the second entry should be obj-$(CONFIG_...) += dm-raid45.o
<smb> I laso renamed it from dm-raid4-5 to dm-raid45 because at that time the module registered itself with that name and
<smb> there is some dm rules that normally load a module if you request a function's name
<manjo> yeah I like to call it dm-raid45 instead of 4-5
<smb> manjo, check the module code for the name it registers, to be on the safe side
<smb> static struct target_type raid_target = {
<smb>         .name = "raid45",
<smb> At least the version in Jaunty did still name itself like this
<apw> manjo, so you have a plan?
<manjo> .name = "raid45",
<manjo> yeah
<manjo> smb, apw ok now built as one module ... 
 * smb pats manjo on the shoulder
<manjo> a simple boot & load module test will be ok ? 
<smb> manjo, I would say for the first step. But be prepared for the Inquisition as soon as apw uploads it. ;-)
<manjo> heh
<manjo> yeah I figured that is bound to happen
<manjo> apw, smb, btw there are no changes to iscsitarget
<manjo> no new version out there 
<manjo> and looks like the same case with compcache
<manjo> although in the case of compcache there is some effort going on to get it upstream
<smb> manjo, Well ok, so there is nothing to do. Except maybe, get in touch with some server guys and ask them whether they would prefer to have it as dkms module
<manjo> for iscsi ? 
 * smb nods
 * manjo nods twice 
 * smb goes to fill another cup with dark liquid
<hyperair> does anyone know why acpi-cpufreq has been built into the kernel rather than as a module since jaunty?
<hyperair> i mean, does it make much difference in loading time?
<smb> hyperair, That was the intention then. We are aware of the issues you got and we will think about it. Just cannot tell any outcome.
<hyperair> smb: the phc-linux issue? okay then, thanks =)
<hyperair> as long as it is given attention
<smb> hyperair, Yes, it is. It is correct that this is a different gouvernor/driver which cannot get active as the built-in acpi-cpufreq is always there before.
<hyperair> smb: in actuality, the phc linux module is just a patch on the acpi-cpufreq module. some implementations of the install turn it into a differently named module, but it's essentially acpi-cpufreq that's patched
<hyperair> smb: or the amd one, which i can't remember the name of
<smb> likely powernow-k8
<smb> Hm, ok. So it would not help you, just to have an option to prevent acpi-cpufeq from getting active.
<mjg59> Use ksplice
<smb> mjg59, Don't let the security people hear ;-)
<amitk> hyperair: is this code unlikely to go upstream?
<smb> But in general I am a bit against this approach of having patched external modules replacing kernel modules...
<hyperair> amitk: unlikely. it's been rejected before, because "it allows users to shoot themselves in the foot"
<smb> amitk, It makes use of non-standard voltages and frequencies. What would you think=
<smb> ?
<mjg59> cpufreq upstream have rejected it, yes
<amitk> fair enough.
<hyperair> smb: well, if acpi-cpufreq is prevented from getting active, i think it's possible to inject the patched acpi-cpufreq module into the kernel via insmod
<hyperair> smb: no, only non-standard voltages.
<mjg59> It's not so much that it allows users to shoot themselves in the foot, it means that you're operating the kernel outside normal parameters and could cause all kinds of subtle failures which may appear to be kernel or app bugs
<hyperair> smb: and it doesn't allow you to overvolt, only undervolt
<mjg59> So you also get to shoot other people in the foot
<bjf_afk> NOTICE: There will be a kernel team meeting on #ubuntu-meeting today at 17:00 UTC
<mjg59> Tainting would deal with the kernel side, but it's like overclocking - it may be fine for everything except a very specific set of instructions, so it may seem like an application issue
<smb> Yes, and being a replacement module also add to the maintenance nightmare
<hyperair> perhaps a nice large warning by the phc guides =p
<hyperair> or a huge warning in the dmesg log when the phc values are changed
<amitk> hyperair: not good enough. We don't want to deal with such bugs _at all_ - whether kernel or app space. And app-space reports don't always ask for dmesg
<smb> hyperair, The second sounds like a minimum. 
<hyperair> smb: what second?
<smb> hyperair, A big dmesg warning. But as amitk says, that would not help if strange things happen in app space
<hyperair> amitk: yeah it's true. well either way, it was rejected by upstream, and is probably not going in, so let's not worry about that issue. what i'm more concerned with is the ability to just recompile the module with the headers installed instead of having to recompile the whole kernel.
<hyperair> in my case, my cpu + fan was going haywire so a kernel compile would cause it to overheat and shutdown
<hyperair> undervolting the cpu did a great job at reducing the temperature though, and now i can deal with kernel compiles without having to go through a ^Z + fg cycle
<mjg59> It's debatable whether it's actually an OS's job to make it easy for you to deal with broken hardware
<smb> I can understand it to a degree from the user side, but as a distro that sort of thing sounds slightly scary
<smb> I run one of my laptops with a upper frequency limit due to the fact that the fan cannot cope with it running full speed
<hyperair> mjg59: a lot of hardware is broken, especially those with particularly stupid BIOSes. are you saying that we shouldn't support those because their hardware is stupid?
<hyperair> smb: acpi-cpufreq compiled as a module; that's all i'm asking.
<hyperair> smb: that's all is required to make it that much easier to set up phc-linux
<hyperair> +that
<mjg59> Compiling acpi-cpufreq as a module means compiling all of cpufreq as modules
<hyperair> is that so?
<smb> yes
<hyperair> the tarball only contains a acpi-cpufreq.c
<hyperair> and it can be compiled on the spot with just the kernel headers installed, if acpi-cpufreq is compiled as a module
<hyperair> but either way, compiling all of cpufreq can't take more than a few minutes; maybe ~5 minutes or less on some decent hardware
<hyperair> compare that to taking nearly an hour, or more to compile the kernel
<smb> The sequence of probing can change the used driver. If you want to have control over that you have to compile them either all as modules or in
<hyperair> the *entire* kernel, just because you want changes in that tiny part
 * hyperair fires up menuconfig
<hyperair> menuconfig doesn't seem to agree
<smb> menuconfig does not care about policy
<smb> If you want to prefer acpi-cpufreq over powernow-k7 for example, you cannot have powernow-k7 built in and acpi-cpufrq as a module
<hyperair> what about both of them as modules?
<hyperair> it's one or the other, isn't it?
<hyperair> if you use acpi-cpufreq, you won't use powernow, and vice versa?
<mjg59> No
<hyperair> don't tell me you use both?
<mjg59> No
<hyperair> then?!
<mjg59> But there are other drivers that may bind
<hyperair> bind?
<mjg59> To the processor
<hyperair> blargh
<mjg59> And if they're built into the kernel, you'll end up with that driver instead
<mjg59> Hence, all built in or all modular
<hyperair> let's look at it this way: intrepid and previous versions of ubuntu had acpi-cpufreq/powernowwhatever compiled as a module. why can't we revert the cpu freq scaling part back to that stage?
<smb> As the decision was made in favour of boot time (and module loads at least had a bad impact on that), this depends on whether there might be less or no such penalty now.
<hyperair> okay, so the deciding factor is now basically how much delay there is, am i right?
<bjf> amitk, the other differences between my tree and yours is that I also rebased to the 2.6.31 karmic changes over the weekend
<bjf> amitk, but I think those changes are in the same files (fewer of them)
<bjf> amitk, any additional fixups were done as separate commits (which I was going  to squash before submitting)
<smb> More or less. And probably too how the common feeling is to change a configuration for a, maybe not uncommon, corner case.
<amitk> bjf: sure, I'm not worried about the state of the patches right now. I have a kernel the compiles from your tree currently. We can rework the patches later. 
<smb> hyperair, But the main part is the boot delay, yes
<bjf> amitk, was just letting you know my thinking
<hyperair> smb: so all i have to do is benchmark?
<amitk> bjf: did you get your pegatron or b2 board booting with anything apart from your kernel?
<hyperair> smb: in that case, which kernel version would you prefer me benchmark?
<amitk> bjf: ack.
<bjf> amitk, I got the b2 board booting with files from Freescale, The "P" board got shipped out and I never tried booting it.
<bjf> amitk, don't have a "P" board now
<smb> hyperair, At the moment, let us do a bit of research. There might be changes to user space that improve things too. So it is not only the kernel
<amitk> bjf: ok, so we have different boards now.
<bjf> amitk, you don't have a b2? (right, I remember now)
<amitk> bjf: nope. And it took me all day today to chase down the right redboot image for my board.
<hyperair> smb: alright, keep me updated then? =)
<smb> hyperair, sure, I got the bug number and you are usually around ;-)
<amitk> bjf: I am working towards a SD image where I can change kernels on the fly
<bjf> amitk, I'd like that as well
 * smb has them (sd cards) nearly all for i386 series
<hyperair> smb: thanks =)
<manjo> smb, zul from server is ok with dkm on iscsitarget... so I am going to go ahead and do it 
<manjo> currently testing dm-raid45 
<smb> manjo, I won't hold you back then. :)
<manjo> smb, as you suspected ... building it as one module wont work... due to duplicate symbols
<manjo> dm-raid45 wont load 
<manjo> smb, apw revert back to separate kos ? 
<smb> manjo, You might want to look at the hardy-lum
<manjo> ok
<smb> You can remove exports from those other modules
<manjo> yeah that is what I was just thinkig 
<apw> yeah worth a try, we really only want that one loading that code for the raid45 versions
<smb> And that got it linked, so it won't need the exports
<Keybuk> apw: around?
<apw> hello
<Keybuk> could you cook me up a custom kernel with http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob;f=driver-core/driver-core-devtmpfs-driver-core-maintained-dev-tmpfs.patch;h=22e58d1616d256d7fdd6c2c6365eea11de0123be;hb=6fcc499f41d83b8870b74f024aa906b85b700cb4 applied?
<apw> Keybuk, looks interesting ... will do
 * hyperair scratches his head regarding inotify issues in the current git kernel
<hyperair> inotify_init()                          = -1 EMFILE (Too many open files)
<hyperair> damn strange
<Keybuk> hyperair: checked the available watches?
<Keybuk> there are per-user limits on such things
<hyperair> Keybuk: how do i check?
<hyperair> Keybuk: i noticed it happened after restarting nautilus a few times
<hyperair> i was testing nautilus-share, see
<Keybuk> see if inotify_init() returns -EMFILE ;)
<Keybuk>        EMFILE The user limit on the total number of inotify instances has been
<Keybuk>               reached.
<Keybuk> cat /proc/sys/fs/inotify/max_user_instances
<Keybuk> then try poking a larger number than 128 into it
<Keybuk> echo -n 1024 > /proc/sys/fs/inotify/max_user_instances
<Keybuk> is a good start
<Keybuk> you may want to increase /proc/sys/fs/inotify/max_user_watches at the same time (number of directories you can watch)
<hyperair> hmmm
<hyperair> well i do know that inotify_init definitely returned EMFILE
<hyperair> strace of conky showed it
<Keybuk> increase the maximum then
<hyperair> too late. i already rebooted
<Keybuk> :p
<hyperair> logging out and logging back in didnt help for some reason =\
<Keybuk> yeah, something was holding onto them
<Keybuk> usually it's something like tracker, beagle, banshee, etc.
<hyperair> banshee has no inotify support just yet
<Keybuk> a session-bus activated service most likely
<Keybuk> since they won't go necessarily away when you log out
<hyperair> tracker and beagle don't run on my notebook
<hyperair> i'm pretty sure banshee goes away though
<hyperair> i should have done a killall -u hyperair then
<hyperair> is there any way to check which processes are holding which inotify handles?
<Keybuk> I tend to do kill -TERM -1
<Keybuk> then kill -KILL -1
<Keybuk> after logging in as me
<hyperair> what's -1?
<Keybuk> lsof will tell you
<Keybuk> hyperair: "all"
<hyperair> ah
<Keybuk> if you don't do it as root, it just kills all yours
<hyperair> yeah i know
<hyperair> never thought of doing that
<apw> Keybuk, the kernel  you wanted is uploading to: http://people.ubuntu.com/~apw/tmpfsdev-karmic/ ... should be complete shortly
<manjo> smb, apw dm-raid45 loads as a module 
<manjo> single module 
<manjo> tested on karmic 
<manjo> 64 bit
<apw> excellent, is that after removing the exports?
<manjo> well had to remove the file entirely coz its already building in /drivers/md 
<manjo> and nothing was using it in ubuntu/ 
<smb> which one
<apw> which file?
<manjo> dm-region-hash.c
<smb> sorry I lost my crystal ball
<smb> but the patch makes changes to region hash
<apw> manjo, but the only reason thats there is cause it got changed ... what smb said
<manjo> I left the changes in /drivers/md... are you guys thinking of having 2 copies of the same ? 
<apw> no the changes should have been moved over
<apw> and the original restored
<manjo> the changes cannot be moved over coz there are dependcies
<apw> i mean apply the changes, copy the 
<apw> whole of the changes file
<apw> changed file
<apw> and then restore the original?
<manjo> ah yes then you will have 2 copies of the same file 
<manjo> coz the patch changes the header file as well
<apw> yes, we will but at least the original is unchanged, and cannot regress
<apw> bring the .h file over to the same place too
<manjo> ok I see what you mean... heh that is hack 
<apw> yes, but it is the safe hack
<manjo> okies
<apw> the normal people with the original dm get the original code
<manjo> will do that now 
<apw> and 0 chance of a regression, the people who opt in to the new driver get the risk
<apw> we are risk averse
<manjo> hmm some how its botched way of doing it ... but less risky ofcourse 
<apw> yes it is indeed botched, but that is the risk averse way
<manjo> k I am on it 
<mahfouz> I had a problem today with 2.6.30-10-generic in jaunty
<mahfouz> talked to the people in #kernel but they only started a distro flame war
<mahfouz> starting up with 2.6.30-10-generic, I get the splash screen all the way to the end but then an unresponsive black screen
<mahfouz> it worked yesterday, but today it didn't anymore, even though there were no updates afaik
<maxb> mahfouz: Well the obvious response is "If a karmic kernel doesn't work in jaunty, how about trying *Jaunty's* kernel with Jaunty?
<mahfouz> because it screws up my intel video
<mahfouz> I downloaded 2.6.30-10-generic from jaunty repo, you know?
<maxb> No, you didn't.
<mahfouz> It was in there temporarily, but now seems to be removed
<mahfouz> I did
<mahfouz> maybe it was xorg-edgers
<mahfouz> yes, I downloaded 2.6.30-10-generic from the xorg-edgers ppa
<mahfouz> but it worked at first and today it didn't boot anymore
<amitk> bjf_afk: did you solve your xmodem problem?
<bjf_afk> amitk, yes I did, user error
<pgraner> dtchen: ping... when your around :-)
<amitk> bjf_afk: http://pastebin.ubuntu.com/207169/ this is bad right? (size of uploaded kernel vs. size of default kernel partition in redboot)
<bjf> amitk, yes, that looks wrong
<bjf> amitk, got to look at my notes
<bjf> amitk, no 
 * amitk is not too familiar with redboot
<bjf> amitk, the size you uploaded is 0x1C5463 which fits
<amitk> bjf: duh, I was forgetting the '1' in the start address
<bjf> amitk, :-) 
#ubuntu-kernel 2009-07-01
<apw> smb, ok the kernel packages are in, so meta can be uploaded, would you do the honours
<smb> apw, sure
<apw> smb, in the normal place (i hope)
<smb> apw, yes it is
<smb> apw, From the debdiff it seems to add new suggest/recommend entries to control.common but not in control. Unfortunately that gets easily lost in the git tree. It will fix itself on build, but it would confuse a bit. Sorry, just saw that now.
<apw> smb, s'ok will have a look, rather get it right
<smb> apw, Right, actually that would probably be also something to go into the changelog as that change fixes a bug
<apw> smb, which bit fixes the bug?  the removal of the delta control -> control.common or the adding of the recommends?
<smb> apw, The addition of recommends
<smb> Recommend apport for linux-crashdump
<smb>     
<smb>     Bug: #391026
<apw> yeah will make sure thats in the changelog
<apw> somehow it got lost that must be my erorr
<apw> this is why you are a good check for my packages :)
<smb> apw, Yeah, its always good to have the stupid/innocent second glance on it :)
<apw> i have learned a useful way to do a last ditch check this time round ... thanks
<apw> smb, ok ... updated the packages
<smb> apw, Looks fine to me now. Then I start upload. You will push?
<apw> smb, is pushed now (based on your ack there :)
<smb> apw, Got it :)
<apw> most excellent
<smb> apw, ubuntu installer san says "accepted"
<apw> hehe sounds good
<TheMuso> apw: Speaking of the metapackage, I am happy to maintain a separate linux-ports metapackage, as the binary packages built from the meta won't be changing, and it means we update the kernels when the ports kernels are ready, separate from main arches. The metapackage is somewhat easier to maintain separately. :)
<apw> i assume we are still doing that :)  as i don't see any ports arches in my lnux-meta upload 
<apw> and yes that cirtainly sounds reasonable to me
<TheMuso> I know that, and since I wasn't asked about that... But thought I'd double check
<apw> as they are likely to lag a little at least, cirtainly during this phase
<TheMuso> yep
<apw> i don't see how that package hurts the admins either as its a single package and has a constant name, no newing required
<TheMuso> yep
 * apw calls that a decision and a plan
<apw> smb, ok i built something usnig the build tools .. .and its gone idle(last build failed)
<apw> is there a toy for finding the logs?
<smb> apw, There will be a build.log in the <series>-<arch> dir
<smb> apw, the tool is ssh into the porter, I am afraid
<apw> heh ok thanks :)
<apw> smb, ok so how do i teach this thing about a group of machiens?
<smb> apw, You add a file in .ubuild/groups that contains the short names (or archs) you want to have in that group. Then you can use than (file-)name instead of a machine
<apw> nice
<smb> If you use the name of an arch, it would take just the first host it can find doing that arch
<apw> smb, does it know which ones are busy?
<smb> apw, It will check for status files, yes
<apw> so if i say build amd64 and my local builder is busy it will use ronne, sort of thign?
<apw> how does it define the order?
<smb> Err, no. not that intelligent
<smb> It will just tell you I am busy 
<apw> damn 
<smb> I was thinking of that feature but bacame distracted
<kdub> hello everyone
<apw> kdub, hello there
<pgraner> apw: ping
<apw> pgraner, hi
<pgraner> apw: i saw your were working on the noveau kernel code... it blew up on me while it was trying to dkms-ify, known issue?
<apw> the nouveau stuff isn't in dkms?
<pgraner> apw: no it was but when I installed the ppa it tried to compile the dkms code and it shit itself
<pgraner> apw: I suspect the reason is cuz the code int he ppa was for .30 and the kernel I'm running is .31
<apw> which ppa you using
<pgraner> apw: https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
<apw> hrm so you are using the DKMS stuff for nouveau from there, not seen that even, in there is also my .30 nouveau kernel.  most confusing
<apw> but yes, the chances of that dkms carrying forward with the level of drm change which occured is low
<apw> i'll have a look in a bit for the latest nouveau bits
<pgraner> apw: do you have a .31 nouveau kernel by chance?
<apw> not yet
<pgraner> apw: no worries, I have a card that is supposed to work with it and was trying to test kms
<apw> yep.  and a good test it would be
<pgraner> apw: from now on when you update let me know and i'll run it thru its paces
<apw> sure
<NCommander> apw, I have a patch to fix the ia64 build (it got left out of Luke's tree because I accidently included config changes that were irreveleant to it). I sent a mail to the list but its stuck in a moderation queue
<apw> heh ... sounds pretty normal ... annoying list
<apw> ok so should i merge whats there, and wait for more, or just wait for more
<NCommander> apw, its a single patch, I think you merge what's there, then pop on my patch (I'm uploading it now)
<apw> NCommander, can do that
<NCommander> apw, I plan to work on sparc this weekend, I have the hardware, just a hosed install ATM
<apw> any idea what the sparc chroot issue is?
<NCommander> glibc isn't too happy on the porting boxes
<NCommander> Dunno why
<NCommander> WOrks fine on mine
<NCommander> (and my sparcs are two models earlier than whats in the DC)
<NCommander> apw, anyway, I hope to simply the ports tree down to one sparc kernel, and two powerpc kernels
<apw> hrm.  is anyone looking at it?  and i assume that affects the buildds too?
<NCommander> Which should make life much much easier for touching ports (although I need to fire an email, we accidently dropped support for Itanium1 machines w/ intrepid, not sure if we care enough to readd it)
<NCommander> apw, it only seems to affect dchroot, I'm not fully sure what's going on except it hangs hard
<apw> don't we use dchroot for the buildd builds also?
<NCommander> apw, sbuild
<NCommander> apw, http://people.ubuntu.com/~mcasadevall/0002-UBUNTU-Upstream-Patch-to-fix-iommu-on-ia64-architect.patch
<NCommander> apw, if you want, I can kick the kernel tree after its merged into a devirtualized PPA
<apw> how do i get one of those setup i wonder, i could do with one which builds on all architectures for this very use
<NCommander> apw, talk to IS, but devirtualized PPAs build on the normal distro machines so they can block things building ina rchive
<apw> yeah ... but its the only way to do a proper test so someone in kernel should have one
<NCommander> apw, indeed. I've had one for ages, but it was never an issue for the kernel team before because the ports tree and the mainline trees were separate
<NCommander> Of course, now its an issue ;-)
<apw> does yours have just one machine in it?
<apw> as in one architecture?:
<NCommander> apw, its an all or nothing thing
<NCommander> Basically you get PPA only arches, or all of them
<apw> ahh i see
<NCommander> Yeah
<NCommander> apw, hopefully with this upload, this will fix ia64 d-i, and get CD images building again (which is nice because I have an ia64 desktop ;-))
<apw> yeah there is some hope
<NCommander> apw, so everything except sparc should build now (sparc's config files need to be reworked, and the exclude modules updated, which is an annoying amount of drudge work)
<NCommander> but once done, it should just keep on going
<mdz> apw, it looks like the linux-doc patch didn't make it into 2.6.31, is it still pending?
<apw> yes its still pending ... not forgotten, we should have no docs now is my understanding
<SEJeff> Is there any sort of backport or whatnot of the creative x-fi modules for existing distros? Or should users wanting to use that soundcard with a release such as hardy just install their own kernels or manually build the modules?
<Kmos> hi
<Kmos> could someone have a look at https://bugs.launchpad.net/bugs/390292 ?
<ubot3> Malone bug 390292 in console-setup "undefined kernel key code  ( in karmic a2)" [Undecided,Confirmed] 
<Kmos> i can't boot my home machine because of the same problem
<Kmos> i've upgraded from jaunty to karmic
<apw> Kmos, that doesn't look like a kernel issue, they seem to be blaming some userspace code there.  i am supprised its stopping you booting
<Kmos> apw: I tried to chmod -x console-setup and setupcon as cjwatson suggested but no luck
<apw> you still get the messages?
<Kmos> when I do dpkg-reconfigure console-setup it always show these warnings.
<Kmos> yes, i'm not at home right now, but there aren't no updates that fix it, i can boot in recovery, but not in normal mode
<Kmos> it hangs at setting console and font
<apw> you could try putting an exit 0 at the top of the console-setup script to ensure it does not execute
<apw> but its not obvious how setupcon could run if its -x
<apw> you might need to do the same to console-screen.sh (add an exit 0 to the top there too)
<apw> that also does stuff with the console if setupcon is not avaialble
<cjwatson> Kmos: for the avoidance of doubt, I did *not* advise you to chmod -x /etc/init.d/console-setup and /bin/setupcon
<cjwatson> Kmos: I advised you to use 'set -x', which is a command you put in a shell script to turn on execution tracing
<cjwatson> Kmos: but, if you did 'chmod -x', then that pretty much proves that it isn't actually console-setup causing a problem after all, but rather whatever runs directly after console-setup, I'd have thought ...
<Kmos> cjwatson: I didn't know about the 'set -x' command. sorry.. I made the -x and it also breaks. but the problem of dpkg-reconfigure console-setup giving that warning messages?
<Kmos> apw: I need to try that at home
<cjwatson> is entirely unrelated to your boot trouble, and not a high priority
<Kmos> I don't know what's breaking it, because setting debug=vc and remove quiet and splash didn't show anything
<Kmos> and dont know how to debug it better
<Kmos> maybe the only solution is to reinstall :-(
<cjwatson> find the thing after console-setup and debug that with set -x
<cjwatson> (you'll need debug=vc and remove quiet/splash to get useful output there)
<cjwatson> or debug /etc/init.d/rc with set -x to make absolutely sure of which script is being executed at the point of the hang
<Kmos> I need to -x the script at rcS.d after the console-setup
<Kmos> right?
<manjo> apw, compcache source comes with scripts to load and unload the modules, do we need to ship these userspace scripts somehow ? 
<apw> i am sure we don't in the kernel
<apw> i am sure whatever uses it knows how
<apw> ubuiquity or whatever
<cjwatson> manjo: it's already integrated in initramfs-tools and casper
<manjo> k
<pgraner> apw: ping, that audio bug from yesterday is 394014 FYI
<mjg59> cking: Where does the source for the hpmini kerneld driver live? I'm sure I'd found it at some point, but now I can't
<cking> mjg59: gimme 5...
<mjg59> Ah, I've found a tarball with it
<cking> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=shortlog;h=refs/heads/netbook-lpia-dennis
<mjg59> Ah, wonderful
<mjg59> Thanks!
<cking> no probs
<mjg59> Didn't catch that it was under a different branch
<cking> yeah. What are you gonna do with it?
<mjg59> Was planning on adapting it to rfkill
<mjg59> Huh. git will give me the pretty version, but asking it for the raw blob gives me a 0 length file
<cking> great!
<cking> ?
<mjg59> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=blob;f=ubuntu/misc/hpmini.c;h=03b24dd7f18093bdae155b4df04d38616ffc1b62;hb=refs/heads/netbook-lpia-dennis
<mjg59> Clicking on "raw" gives me nothing back
<mjg59> And clicking on "HEAD" gives me 403
<smb> mjg59, HEAD has the same results for me. But raw pops up a save window...
<mjg59> smb: Does it actually save anything, or is it just sending headers and no content?
<smb> mjg59, Ah, ok. I see
<mjg59> Oh, hang on
<mjg59> It's the same GUID as hp-wmi
<mjg59> Heh. It's an entirely unnecessary driver :)
<mmerlone> Hi all, I have a question regarding a mac address flip flop reported by arpwatch, is this a rigth place to ask?
<james_w> could someone with the power please fish my mail from the kernel-team moderation queue?
<robbiew> apw: you around?
#ubuntu-kernel 2009-07-02
<dtchen> pgraner: pong, around until this horrible 'net connection dies (again)
<pgraner> dtchen: no worries, fixed the issue (sound as usual....)
<TheMuso> 8/c
<TheMuso> c
 * hyperair scratches his head and wonders why his usb thumbdrive isn't detected
<mdz> apw, did you and robbiew talk about his intel graphics issue with .31?
<mdz> apw, I've upgraded but haven't booted into .31 yet, wondering if it's wise
<lesshaste> hi all
<levonshe> hello all,  I have ubuntu kernel source v2-6.27.7  , and I tried to build kernel like kernels frem kernel.org,  (make xconfig, make) , but I got an compilation error  ubuntu/misc/wireless/p80211/p80211netdev.c:968: error: ânetdevice_tâ has no member named âwireless_handlersâ
<levonshe> sorry for a long line - is it correct to buill ubuntu kernel the same way as vanilla kernels?
<hyperair> rather, you should be using make-kpkg
<levonshe> but I do not need package, I need ti for other system where I can copy only vmlinux, initrd and /lib/modules
<hyperair> then i don't know =\
<hyperair> rather, i think that if you're going to do something like that, you might as well compile from one of the kernels in kernel.org
<hyperair> the linux-source-* packages have ubuntu-specific changes included
<levonshe> Let us return to the compilation error - I do not have wireless defined in .config, why it got active ?
<levonshe> Correction - wireless was defined as ubuntu includes
<hyperair> so disable it
 * hyperair stares at kernel compilation incredulously -- it's taking 3GB D=
<smb> hyperair, We have some help at https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<hyperair> hmm?
<smb> But in general, you do not do it as with a vanilla kernel but like debian packages
 * hyperair clicks
<smb> fakeroot debian/rules binary-generic
<hyperair> ah
<smb> for a generic kernel build
<smb> That gives packages, but you also can find the objects in debian/build/build-generic
<hyperair> how do you prepare the debian/ directory?
<hyperair> ugh i'm going to run out of disk space at this rate X_X
<smb> Hm, did you not say you got the source? via apt-get source linux-image...
<hyperair> not me =\
<smb> But I would have thoght
<hyperair> i was make-kpkg'ing a git kernel
<smb> any way would include the debian dir
<hyperair> using config-2.6.31-1-generic
<smb> except you did the evil mrproper
<hyperair> evil mrproper?
<smb> make mrproper just dumps the debian dir into nothingness
<hyperair> i see
<smb> just one of the pitfalls when coming from vanilla builds :)
<hyperair> by the way, does make-kpkg typically result in a kernel image nearly 1G in size?
<smb> the vmlinux is big
<amitk> sounds like your kernel wasn't stripped
<hyperair> grr X_X
<hyperair> wait, stripped?
<hyperair> hmm it hasn't been stripped yet
<hyperair> i ^Z'd it
<hyperair> had to purge my apt cache to make space for it
<hyperair> and my pbuilder cache
<smb> vmlinux in the build dir is always big. It won't get packaged
<smb> But it is part of the build
<hyperair> i see
<smb> Doing kernel builds == buy large disk drive from my experinece :)
<hyperair> ouch X_x
<hyperair> it's a small partition
<hyperair> i should have done it in my home directory, but i did it in /usr/src instead because my home directory has even less free space
<smb> Karmic amd64 full build (with ccache) == 12G
<hyperair> woohoo X_X
<hyperair> thank god i'm not doing a full build
<hyperair> i'd trim down the config, but the last round ended up killing my usb drive support
<hyperair> O_o
<hyperair> for some reason or other
<hyperair> it just wouldn't mount
<hyperair> as in mount hung
<hyperair> and for another stick, the device didnt' even appear
<hyperair> damn weird =\
<hyperair> dmesg showed it though
<smb> Once tried to unbind the ehci driver?
<hyperair> unbind?
<smb> echo the usb id into /module/uhci_hcd/drivers/pci:uhci_hcd/unbind ... or so
<smb> err actually, which kernel are we talking about?
<hyperair> .31
<hyperair> from git rather
<hyperair> few days ago
<smb> Ah, ok. Not some older Jaunty which might have the problem with detection then
<smb> I thought I saw some older version number above
<smb> 2.6.27
<hyperair> that wasn't me =p
<hyperair> that was levonshe
<smb> Ah, :-P all green and blurry
<smb> Well, same advice in general for him
<hyperair> irssi? =p
<hyperair> get nickcolor
<smb> xchat, which does some but I do not want to paint everyone differently. too much effort :P
<hyperair> heheh right
<hyperair> hmmmm
<hyperair> 1.2G    /usr/src/debian/linux/linux-2.6/debian/linux-image-2.6.31-rc1-hyper3/
<hyperair> something is seriously wrong about that ._.
<hyperair> it's not about an unstrippped vmlinux now is it?
<smb> after the build my build-generic is 4.9G alone
<hyperair> ._.
<hyperair> okay, but how did i end up wtih a linux-image deb 352M big?
<smb> That is slightly odd. The normal config ends up being around 30M
<hyperair> ._.
<hyperair> see
<hyperair> that's what i meant T_T
<hyperair> it's huge =(
<smb> and that is amd64, guess i384 might be a bit less
<hyperair> this is amd64.
<hyperair> the /lib/modules/`uname -r`/kernel/drivers directory is the largest
<hyperair> 773M
<smb> and you used "debian/rules editconfigs" to adapt configurations and the "fakeroot debian/rules binary-generic" to compile
<smb> ?
<hyperair> er no
<hyperair> i used make-kpkg clean
<hyperair> followed by make-kpkg kernel_image kernel_headers =\
<hyperair> this is a git kernel
<smb> Would work with a git kernel, too
<hyperair> =\
<hyperair> make that the upstream git tree
<smb> I am not sure about the make-kpkg. I know it was used once, but I never used it for anything after Hardy
<smb> including hardy
<smb> Ah, ok. the vanilla git tree..
<smb> hyperair, maybe you would be interested in that http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-07-02/ ?
<hyperair> ooh i never knew that existed
<hyperair> i'd have to recompile it due to the whole acpi-cpufreq issue though
<smb> There are packages for all rc releases. Unfortunately broken for i386 currently. Hm, thought that was fixed...
<smb> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc1-fix1/
<smb> maybe that is better
<hyperair> the rc release is broken for me as well
<hyperair> on amd64.
<hyperair> it panics
<hyperair> or otherwise blanks out my screen so i can't see the panic
<hyperair> oopses
<smb> Ah, no. Compile broken in that case
<hyperair> ?
<smb> The dailys do not seem to produce i386 packages
<smb> There was a incorrect div which cause a build failure on a hardy chroot (which is where the builds are done)
<smb> But that probably does not help you. Can you investigate which of the modules is so big?
<hyperair> the network modules
<smb> Any chance you compiled with or have all objects unstripped? With debugging and symbol information?
<smb> 2.8M	cfg80211.ko
<smb> 88K	cfg80211.ko.s
<smb> That is in the build directory (so not prepared for install) and the .s is after strip
<smb> you can do a "file <file>" to see whether it is stripped, too
<hyperair> smb: i don't appear to have any .s files
<hyperair> smb: and none of the modules are stripped
<hyperair> hmm
<smb> hyperair, the .s was me
<smb> as a save file
<hyperair> oh
<hyperair> aha i see
<hyperair> hmmm
<hyperair> pkg-create-dbgsym at work perhaps?
<smb> I can't say. As I said, I actively do not use make-kpkg, so I can't say what things are at work. With our build the modules are unstripped before and will get striped on preparation for the packaging
<smb> make modules_install I expect does the same
<smb> INSTALL_MOD_STRIP controls that
<hyperair> i see
<hyperair> wiki.kubuntu.org says CONFIG_DEBUG_INFO=n works around the issue
<smb> Yeah, right. Without adding them those won't have to be stripped
<smb> And the default of y is useful to only need one go to get modules and vmlinux with debugging info, which can be stripped later. Some things tend to get forgotten when you just use the usual build command. :/
<hyperair> heh i see =\
<hyperair> ccache doesn't seem to like removing the debugging option
<smb> sounds a bit weird. that should care the least...
<hyperair> no i meant ccache is missing the cache completely =\
<smb> Oh that. :) Well naturally
<hyperair> =(
<MacSlow> Greetings everybody!
<MacSlow> I've problems getting a ath9k-based PCMCIA wifi-nic working with kernel 2.6.30-10 under Karmic
<MacSlow> I can't use 2.6.31 as that causes by i965-based laptop not to boot at all... probably due to currently broken KMS
<hyperair> rc1 is broken for i965.
<hyperair> compiling from git helps
<smb> I would believe apw rather sooner than later syncs up with it...
<hyperair> ?
<smb> MacSlow, Is there anywhere more info about the problem?
<smb> hyperair, sync from upstream git into the karmic tree
<MacSlow> smb, well I can provide some info (dmesg, syslog... what ever you need.)
<hyperair> ah.
<MacSlow> smb, the ath9k modules is loaded and shows up in dmesg without any hints to errors 
<MacSlow> smb, and the device is listed as wlan1
<smb> Ok
<MacSlow> smb, but iwlist scan only says "No scan results"
<smb> you read minds...
<MacSlow> smb, I get a scan result only shortly after I plugged the ath9k PCMCIA-card in
<MacSlow> smb, also nm-applet/NetworkManager lists the device, but has it's entries in the nm-applet's menu greyed out
<smb> Ok, was there a karmic kernel working?
<MacSlow> I've no clue what that actually means
<MacSlow> smb, briefly about 3 weeks ago when I asked asac for help
<smb> MacSlow, and just to rule out absolutely everythign. Any killswitch to twiddle?
<MacSlow> smb, yes... either booting with it enabled or disabled does not change a thing
<MacSlow> smb, btw... just wondering... does the kill-switch apply to all wifi-devices or just built-in ones?
<smb> It should only to the built in...
<MacSlow> smb, since the built-in card is likely to be broken (that's why I use the ath9k-based PCMCIA one) I guess I can ignore the killswitch then
<smb> Oh, ok. Then I understood the "I get a scan result only shortly after I plugged the ath9k PCMCIA-card in" before wrongly
<smb> I assumed th internal one is broken but the external works...
<smb> But I should read the beginning :/
<smb> So you get scan results for a short period of time and after that it stops...
<smb> hm
<MacSlow> smb, yes
<MacSlow> smb, when I pull the card out and back in
<MacSlow> I can get scan results from "iwlist scan" for about 5 seconds
<MacSlow> smb, by repeatedly issuing "iwlist scan"
<MacSlow> smb, one thing I recognize in the output of "iwlist scan" is that the time for "Extra: Last beacon: XXXXms ago"
<smb> sound quite strange. especially without any hint of messages...
<smb> MacSlow, It gets bigger?
<MacSlow> smb, continuesly grows until about 9000 ms
<MacSlow> then it stops
<MacSlow> yes
<MacSlow> if that's any hint
<smb> A bit like something went down and it does not  receive anything, then goes into sort of sleep. And the results received at the beginning are at some point invalidated
<MacSlow> smb, any idea how to fix it
<MacSlow> ?
<MacSlow> or what I could try to make it "stay up"
<smb> Heh, no. First I would need an idea what is going on
<MacSlow> smb, could you guess if it's a driver-issue of a NetworkManager issue?
<smb> Just checked whether there where recent changes in the module. Nothing from -8.9 to -10.12. Now how long is that in real time...
<cjwatson> is somebody looking at pulling in the commit referenced in bug 392709?
<ubot3> Malone bug 392709 in linux "[karmic] linux-image 2.6.31-1.13 crashes on boot" [Undecided,Confirmed] https://launchpad.net/bugs/392709
<levonshe> hello all. can you comment why i get via_chrome9: disagrees about version of symbol struct_module (I have kernel build fot Ubuntu 2-6.27.7, this driver is also 2.6.27-7) ??
<smb> cjwatson, I look in a second
<smb> levonshe, Maybe external build pulling in the wrong headers...
<smb> MacSlow, 2.6.30-8.9 was done Jun-12
<smb> MacSlow, So between then and -10.12 there were at least no changes to the module itself
<smb> cjwatson, I remember apw knowing of it and he was looking at some other things freshly commited this morning
<cjwatson> ok, thanks
<cjwatson> I put it on the release meeting agenda
<amitk> hmm.. was .31 known to be booting?
<tjaalton> boots but takes an eternity here
<amitk> its oopsing all over the place
<smb> MacSlow, maybe you could go into the /sys/class/net/<?> directory (? name of the interface) and do a grep . * there
<amitk> tjaalton: oopses on acpi_get_pci_dev for me in the find_video routine
<smb> amitk, That is the patch that was asked for by Colin
<tjaalton> amitk: yep, same here
<mjg59> Fixed upstream
<smb> 412af978 ("ACPI: video: prevent NULL deref in acpi_get_pci_dev()"
<amitk> nice
 * hyperair wonders if anybody would be nice enough to help me get usb-storage working in 2.6.31 =\
<levonshe> smb, I got full linux_source.tar, so the headers are consistent with the kernel, the module In question was taken from different place (VIA AREA), but it was said it  prepared for Intrepid 
<smb> levonshe, There would be several releases of Intrepid, the kernel version you had 2.6.27-7 is quite old the current one is 2.6.27-14 and the module might be prepared against that
<levonshe> smb, thanks. I will try patch to 2.6.27.14
<levonshe> smb, sorry I was wrong, the module has vermagic=2.6.27-7-generic SMP mod_unload modversions 586
<smb> levonshe, Do you compile parts of the module or do you only get the .ko?
<smb> You need to have the correct target kernel running and the matching headers installed for compiling
<smb> what does /proc/version_signature say?
<levonshe> smb, no I have development machine with different ubuntu versioin and kernel version, Unortunatel VIA does not provide source for module, so I have only binary .ko
<smb> levonshe, If the module is pre-compiled already and says 2.6.27-7-generic then it should in theory work if the machine you want to load the module is running the 2.6.27-7-generic kernel. If it is another Intrepid version you can try insmod -f, but without any guarantees
<smb> levonshe, No, it is 586 iirc, it means config options rather tuned for desktop, as opposed to -server
<hyperair> is anyone here using a .31 kernel who has a usb-storage device working? as in mounted and all?
<maco> hey guys, http://www.gossamer-threads.com/lists/engine?do=post_view_printable;post=1097001;list=linux affects 2.6.31-1 in karmic
<maco> tun interfaces dont work
<maco> its already merged in linus's tree, so does that mean just wait for the next build?
<smb> maco, basically. though it might be the one after the next
<smb> because the next is just prepared for the acpi_video null pointer 
<smb> problem
<maco> ok
<nixternal> yo yo kernel nutjobs :p
<nixternal> seeing an issue with the 31 kernel
<nixternal> udevadm settle - timeout of 30 seconds reached,t he event queue contains:
<nixternal> and then it lists 2 devices under /syst/devices/pci0000:*
<nixternal> then I enter my encryption password
<nixternal> then I see device-mapper messages about "target device sda5 is misaligned"
<nixternal> I can only get this in recovery mode after adding "nomodeset" to the kernel line, otherwise it just black screens on me
<maco> you're using lvm?
<maco> (for the encryption i mean...as opposed to one of the other methods)
<maco> nixternal, ^
<nixternal> not on the machine with issues
<nixternal> this machine, which is my ubuntu machine, is LVM and doesn't have those issues
<maco> given the "misaligned" error on the disk, i'd guess it's something to do with whatever encryption mechanism you're using
<nixternal> the one you use when installing from cd :)
<maco> i thought that was lvm *shrug*
<hyperair> has anyone seen something like this: http://pastebin.com/f535cca55 ?
<AnAnt> Hello, I'm maintaining sl-modem package, I have a question about class_device_register, I understand that it's GPL: EXPORT_SYMBOL_GPL(class_device_register)
<AnAnt> the code of sl-modem module has this license:MODULE_LICENSE("Dual BSD/GPL");
<AnAnt> will that be able to register a sysfs object to create the device automatically ?
<lesshaste> hyperair: eek!
<lesshaste> I tried to restore debconf and now something has gone wrong when trying to install the kernels?  See http://pastebin.ca/1481697
<hyperair> heh i got something similar to that once
<hyperair> i removed nvidia-common
<lesshaste> hyperair: interesting!
<hyperair> =p
<lesshaste> I'll do the same
<lesshaste> assuming that it's only needed for nvidia :)
<lesshaste> so.. sorry this is dumb but how do I go back and get those kernels reinstalled
<lesshaste> now that I have removed nvidia-common
<dtchen> nixternal: which kernel specifically?
<nixternal> -13
<lesshaste> hyperair: grr http://pastebin.ca/1482194
<dtchen> nixternal: -13?
<dtchen> unless i'm severely misparsing something, i have no idea what -13 refers to
 * hyperair whistles
<lesshaste> help! :)
 * hyperair doesn't know anything about fglrx
<lesshaste> is it really a fglrx problem?
<lesshaste> I think it all came because I screwed debconf
<lesshaste> by deleting one of its directories
<hyperair> ...you're on your own
<hyperair> =p
 * hyperair is off to reboot
<lesshaste> eek
<lesshaste> anyone help??
<dtchen> nixternal: if you're referring to karmic's 2.6.31-1-generic, your bug is already fixed (though it hasn't been merged into ubuntu-karmic.git)
<dtchen> nixternal: see drivers/md/dm-table.c:498, where the condition is incorrect
<dtchen> nixternal: changeset ea9df47cc92573b159ef3b4fda516c32cba9c4fd in linux-2.6.git if you're tracking it
<nixternal> dtchen: ya, I found that earlier when digging around. I saw where the guy fixed it upstream so I knew it was only a matter of time...it was found on the 25th and fixed the same day I think
<lesshaste> can anyone help with this ? http://pastebin.ca/1482194
#ubuntu-kernel 2009-07-03
<james_w> could someone with the power please let my mail out of the kernel-team moderation queue?
<Sarvatt> http://patchwork.kernel.org/patch/33044/
 * Sarvatt cheers
<apw> TheMuso, i see the latest upload actually one of the ports kernels built!
<smb> I actually only saw powerpc fail
<smb> err no, sparc as well
<amitk> smb: regarding the ipw3945 patches. I have a question regarding the first one
<amitk> smb: if there is a running worker, it will first unregister the device by calling ieee80211_unregister_hw(priv->hw)
<amitk> but it doesn't call iwl3945_down() 
<amitk> is the call to down() not needed any more?
<smb> amitk, As I understood the change the down is done when there is no interface registered. I assume it is part of the unregister
<amitk> ok
<smb> amitk, I did not follow that so closely as that change come around 2.6.29 and still looks the same, so I think it should make sense
<TheMuso> apw: Yeah, but I see you missed my pull request with a powerpc config fix.
<Laney> Hi ho, how can I get you guys some useful debugging info? If I try to boot with .31 then my system reboots after about 5 seconds...
<apw> TheMuso, i'll get it in the next one
<Keybuk> apw: the tmpdevfs kernel worls
<Lascax> Hi all
<Lascax> Question: there is a way to convert a patch for an older kernel to make it compatible with a new one?
<amitk> Lascax: you apply the patch to the new kernel and if it fails, fix the 'rejects'
<amitk> then create a new patch
<Lascax> amitk: well, I am new to ubuntu. There is a guide on how to fix the rejects?
<amitk> Lascax: this isn't specific to Ubuntu. It is a feature of the 'patch' program.
<Lascax> Yeah, my mistake.
<amitk> patch will tell you what parts of the old patch did not apply (because that part of the code might have changed)
<amitk> then you fire up a text editor, open the file and hand apply the changes until it does the right thing
<Lascax> OK, I hope there aren't a lot of changes between 2.6.22 kernel and 2.6.28 (for example Inoticed that one fo the files changed from .c to .h)
<amitk> Lascax: just look at any of the patch examples from Google
<amitk> Lascax: depends on the code you are trying to port.
<Lascax> amitk: this is the link fo the patch that I want to port. A lot of code is changed, I already noticed in the new files. ( http://drp.id.au/linux-2.6.16-joydev.patch )
<amitk> Lascax: is it known to not work on 2.6.28?
<Lascax> amitk: already tried to force compiling with it redirecting to the files, but no new command in the makemenuconfig
<Lascax> amitk: this patch adds a command in the menuconfig
<amitk> Lascax: I meant, does the HW not work on 2.6.28 already?
<Lascax> amitk: it works, but there is still the axis problem (this is a patch to make directional buttons of the joypad to be digital input instead analogic)
<Lascax> amitk: no recognization of up+down and right+left, for example
<amitk> Lascax: I'd suggest first understanding how 'patch' works. A few simple examples might make it clearer how to port this code
<amitk> but I've got to go now...
<Lascax> amitk: ok, hope to see you later. Nobody helped me with this until now, nor at #ubuntu-it nor at #ubuntu
<Lascax> amitk: last question. I found the same patch for 2.6.22 ( http://drp.id.au/linux-2.6.22-joydev.patch ) Can it be easier to convert than the one for 2.6.16?
<amitk> Lascax: good luck.
<amitk> Lascax: yes, it will be easier to convert from later kernel
<Lascax> amitk: OK, thx for helping. I still have an hope :-)
<amitk> Lascax: np
<bdmurray> smb: Where was bug 330824 Fix Committed?
<ubot3> Malone bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Medium,Fix committed] https://launchpad.net/bugs/330824
<broonie> Does anyone have any info on how the process of upstreaming the ARM changes you guys are carriying is progressing?
<smb> bdmurray, It was always part of the 2.6.28.y stable impart iirc
<bdmurray> smb: okay, there was a follow up question regarding it in the bug
<smb> bdmurray, Oh. I would have to look a it close. I just went over all the bugs that had references in the next proposed i am preparing
<james_w> hi all, I've sent a mail to kernel-team and it's stuck in the moderation queue, could someone fish it out for me please?
<Sarvatt> so is hardy the last release that has the ide-scsi module on powerpc thats needed to install from an alternate disk for ibooks? just burnt off karmic and jaunty but neither can detect the cd drive on my ibook (and fail during the install because of it) and i cant figure out what module to manually load it if it isnt ide-scsi
<Sarvatt> heyo, just want to suggest maybe disabling radeon KMS by default but perhaps leaving it enabled in staging so its still possible to use. perhaps in drivers/gpu/drm/radeon/radeon_drv.c changing line 85 int radeon_modeset = -1; to int radeon_modeset = 0;? things work fine in the current userspace with radeon.modeset=0 but the default radeon.modeset=1 doesn't have the userspace to support it yet in karmic.
<Sarvatt> disabling it completely from staging would preclude the nescessary headers from getting into linux-libc-dev to build the userspace to support it on xorg-edgers to work out the kinks supporting it is why I was suggesting that instead of disabling it completely. booting with radeon.modeset=0 works fine how it is currently
#ubuntu-kernel 2009-07-04
<ryanakca> What do I need to do to get http://patchwork.kernel.org/patch/32434/ applied to the Karmic kernel? (History: http://forum.soft32.com/linux/31-rc1-device-mapper-target-device-sda6-misaligned-ftopict487711.html ). If it happens to be the same issue I'm experiencing with 2.6.31-1 (same error in the syslog, different device), a side effect is that it isn't possible to use sbuild + schroot + lvm to build packages.
#ubuntu-kernel 2009-07-05
<ryanakca> What do I need to do to get http://patchwork.kernel.org/patch/32434/ applied to the Karmic kernel? (History: http://forum.soft32.com/linux/31-rc1-device-mapper-target-device-sda6-misaligned-ftopict487711.html ). If it happens to be the same issue I'm experiencing with 2.6.31-1 (same error in the syslog, different device), a side effect is that it isn't possible to use sbuild + schroot + lvm to build packages.
<CarlFK> ryanakca: post the same request to the u-kernel list (i forget the exact name)
<CarlFK> ryanakca: and I can't tell.. but get it accepted into mainline helps 
<ryanakca> CarlFK: Thanks, I think it's been accepted, not sure though. And I'll send an email out in the morning :)
<billybigrigger> hey all, anyone here having problems with .31 rc2 not detecting a webcam?
<billybigrigger> seems to be just started with .31
<billybigrigger> i think the gspca module was mainlined into the kernel...and ever since, i have not webcam
<billybigrigger> is there any fixes planned for gspca and webcams in .31?
<Sarvatt> im sure there will be hundreds of gspca fixes in .31 as it progresses, there were like 50+ already since rc1
<billybigrigger> oh, well .31 broke my webcam, so thats what im wondering...i
<billybigrigger> where should i be looking for help Sarvatt ?
<Sarvatt> try .31-rc2
<billybigrigger> i am
<billybigrigger> rc2 doesn't even find my camera now
<billybigrigger> rc1 found it, but with green garbage in cheese, the webcam light went on though
<billybigrigger> nothing with rc2 i see it listed in lsusb...but don't really know where to trouble shoot from there
<Sarvatt> kernel.org bugzilla would be the place to look
<billybigrigger> gspca is now built into the kernel correct?
<billybigrigger> since .31?
<Sarvatt> has been for a long time
<billybigrigger> oh really
<billybigrigger> what changed in the .31 then that it broke?
<billybigrigger> .30 works flawlessly
<billybigrigger> i thought there was a major change in .31 with gspca, i wish i remembered where i read the change and what it was
<Sarvatt> http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=gspca
<billybigrigger> wish any of that meant something to me
<billybigrigger> haha
<billybigrigger> ok well where can i go from here Sarvatt ? any change i can get my cam working? or should i just sit and wait?
<Sarvatt> billybigrigger: webcams arent working here on either machine i have with one on any kernel so i'm not sure its .31 specific.. they are both uvcvideo though. its probably just a udev problem or something
<Sarvatt> modules arent getting loaded anymore, thats new in the past 3-4 days
<billybigrigger> Sarvatt, using the .31 rc2 kernel from mainline ppa
<billybigrigger> would i have to manually load the gspca driver?
<Sarvatt> still doesnt work for me manually loading v4l1_compat videodev and uvcvideo
<billybigrigger> how do i find what module my cam uses?
<billybigrigger> lsusb -vv spits out some info, but gives me this error
<billybigrigger> cannot read device status, Operation not permitted (1)
<billybigrigger> and i can't find anything about a module
<billybigrigger> its a microsoft lifecam vx-1000 if that helps
#ubuntu-kernel 2010-07-05
<warewolf> wow
<warewolf> er
<rocky_IITM> Hi all...Can anyone let know what is the maximum memory that can be allocated for a kernel module in x86_64????
<rocky_IITM> What is the maximum memory that can be allocated to a kernel module in x86_64 bit system??
<lifeless> -1 I presume
<rocky_IITM> I didnot get  -1??
<RAOF> Is there any reason to expect that a kernel module should be limited in the amount of memory it can allocate on an x86_64 system?
<ikepanhc> I did not aware of any limitation for single module, but I know there are limits for kmalloc
<ikepanhc> IIRC for x86 it is 128k, if you need memory more then 128k
<ikepanhc> you need to use get_free_page
<rocky_IITM> I need to allocate static memory... need to create queues of total size 2 GB...but memory allocation failing...
<ikepanhc> what kernel API you use?
<rocky_IITM> I m using rvmalloc().
<ikepanhc> for 2G buffer, you need to use get_free_pages() and manage them.
<ikepanhc> its almost impossible to ask kernel to arrange 2G not-fragment-dram for you
<rocky_IITM> ok i will try that...
<rocky_IITM> I was able to do for 1 GB... after that it was failing..
<lifeless> the idea of 2GB in-kernel terrifies me.
<lifeless> Just saying.
<rocky_IITM> yah its true... actually trying to write a kernel module for high speed packet processing..
<rocky_IITM> lots of processing required in kernel and need to buffer the packets...
<RAOF> That's a seriously huge buffer!  Is processing so slow?
<rocky_IITM> yah but traffic rate is also high... 5gbps..
<lifeless> that doesn't mean you have to be inkernel
<lifeless> you just have to pass out sensible regions to userspace - lots of work on efficient userspace drivers/processing has been done
<rocky_IITM> yah I am trying to do that also... but getting drop in the card level... userspace copying also is a bottleneck
<rocky_IITM> I am getting drop in nw driver level..
<ikepanhc> IIRC the bottom neck for 5gbps data flow is not usually on content switch, its usually on processor frequency
<lifeless> rocky_IITM: hand out entire pages, no copying involved surely.
<rocky_IITM> yah true... what we are trying is to create a multi-threaded driver and process it in different cores...
<lifeless> you will make things a lot more robust if you're only privileged when you *need to be*.
<rocky_IITM> Is there any maximum limit to vmalloc_32()??
<rocky_IITM> lifeless: Is there any maximum limit to vmalloc_32()??
<RAOF> rocky_IITM: I don't know, but haven't you already been pointed at get_free_page?
<RAOF> And isn't asking for 2GB of contiguous memory asking for your code to fail in all but the most controlled of situations?
<rocky_IITM> hmm ic... but my system is having 64 GB of RAM... so why its not possible to do contiguous memory allocation??
<lifeless> fragmentation
<lifeless> only takes 33 widely separated pages and you can't do any single 2G allocation
<rocky_IITM> see ours is not a single allocation... we are trying to create queue... each node is of 16KB and the total size of the queue is 2GB
<lifeless> then why are you asking if there is a limit to the allocation facility of a single call?
<rocky_IITM> lifeless: see when we are crossing 1 GB the allocation is failing...and we are not quite sure where is the problem
<RAOF> So, after you've allocated 134217728 separate 16KB memory blocks it then starts to fail?
<rocky_IITM> when I have allocated 16KB * 65536 nodes then further allocation fails
<rocky_IITM> RAOF: when I allocate 65536 seperate 16KB blocks then it starts to fail
<TeTeT> smb: sorry, but I could not test the gobi loader patch last week - the hardware was already sent back
<smb> TeTeT, Well, as long as there is no testing the changes will be simply on hold.
<TeTeT> smb: understood
 * apw yawns
 * smb lazily waves
<cooloney> apw and smb morning
<apw> hiya  cooloney 
 * smb moans. Ok, children in the kindergarten sing songs, but why does that need amplifying?
<amitk> smb: you're running a kindergarten at home?
<smb> amitk, No, there is just one close by. And today they seemed to have "escaped"
<amitk> open windows, nice weather and all that, then
<smb> yup
<kraut> moin
<smb> moin
<salvarane> hello 
<salvarane> I compiled a kernel 2.6.29 patched rtai for lucid but when I reboot the mouse and keybourd not work
<salvarane> hello
<salvarane> <salvarane> I compiled a kernel 2.6.29 patched rtai for lucid but when I reboot the mouse and keybourd not work
<apw> salvarane, what is rtai
<salvarane> <apw> realtime for linux + emc2 cnc control
<apw> salvarane, where did you get the kernel configuration you used to build it?
<salvarane> <apw> /boot/config-2.6.32-23-generic-pae ; make oldconfig 
<apw> salvarane, you might try the config from a version of ubuntu before 2.6.29, jaunty for example ... as the config may have changed between versions of the upstream kernel
<apw> salvarane, you might also want to try a 2.6.29 kernel from the mainline builds, and see if the keyboard works there
<salvarane> <apm> thanks , how can I download in synaptics a kernel 2.6.29 ?
<salvarane> for ubuntu 
<salvarane> in this manner I copy config file for my kernel rtai
<salvarane> if all function's very well
<ddd_> anyone knows : /usr/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6 ,  how to fix?
 * abogani waves
<abogani> apw, May i disturb you for a minute? :-)
<lag> Question:
<lag> I am trying to populate the platform_driver struct
<lag> i.e.
<lag> .probe
<lag> .release
<lag> I am doing so from arch code
<lag> How do I 'see' the module's symbol?
<lag> I've tried to EXPORT_SYMBOL it and in the arch prototype I have declared it as an extern
<lag> Ideas on a postcard
<tseliot> apw: does Maverick's kernel have a known I/O eating CPU issue?
<ogra> shoudl we add one if there isnt one ? :)
<tseliot> heh
<tseliot> my icore 7 feels like an old 386 when extracting packages, etc.
<tjaalton> that's a dpkg issue
<tjaalton> aiui
<tjaalton> it's syncing the disk all the time
<tjaalton> i'm more fed up with the gnome-help taking 45 seconds to start..
<tjaalton> and that's not a kernel problem, so I'll leave it there ;)
<tjaalton> or, I don't think it is..
<tseliot> tjaalton: ah, I know who I can bug about dpkg :-D thanks
<tjaalton> it was a deliberate decision iirc..
<ogra> i think it only happens with ext4
<tjaalton> yeah
<ogra> and is an issue with fsync calls
<tseliot> do you know what's the relevant bug report?
<ogra> must be in the lucid release notes somewhere 
<tjaalton> probably
<tseliot> I've never had this problem in lucid with ext4
<ogra> https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Performance regressions with ext4 under certain workloads
<ogra> bug 570805 it seems
<ubot2> Launchpad bug 570805 in dpkg (Ubuntu Lucid) (and 3 other projects) "[regression] dpkg's fsync causes massive regression in Ubuntu Server and Alternate installation times (affects: 16) (dups: 1) (heat: 125)" [High,Fix committed] https://launchpad.net/bugs/570805
<ogra> https://bugzilla.kernel.org/show_bug.cgi?id=15910
<ubot2> bugzilla.kernel.org bug 15910 in ext4 "zero-length files and performance degradation" [Normal,New]
<tjaalton> whee, seems like a fix is coming
<tseliot> maybe I/O is worse in maverick and this is why I'm noticing the problem now
<kaushal> hi
<apw> hi
<kaushal> apw, hi
<kaushal> Please guide me about my post on https://lists.ubuntu.com/archives/ubuntu-server/2010-July/004402.html
<apw> hi
<apw> kaushal, did you try the preseed change recommended in the email you are replying to there?
<kaushal> apw, I am using ks.cfg kickstart file
<apw> kaushal, and did you try the > d-i base-installer/kernel/override-image string linux-server
<kaushal> apw, as i said i dont use the preseed method at all
<kaushal> I use kickstart method
<apw> hrm, you have already left my area of expertise :/ ... you probabally need to ask if that file can change the kernel, i would ask on #ubuntu-devel, the installer folk mostly hang out there
<kaushal> ah ok
<kaushal> Thanks apw 
<apw> np
<kaushal> apw, is there a mailing list for ubuntu-devel ?
<apw> i think if you are emailing them there is an ubuntu-installer list
<apw> i would ask on #ubuntu-devel first
<apw> kaushal, you give very few hints as to what your problem is from your irc request, which makes it hard for the right person to know what you need
<apw> kaushal, looks like you got your answer on #ubuntu-devel ...
<kaushal> apw, sure
<tseliot> it turns out that my partition was busted. No I/O issues with the kernel
<apw> tseliot, thats good news
 * tseliot nods
#ubuntu-kernel 2010-07-06
<m4tr1x> hi
 * warewolf pokes Sarvatt 
<warewolf> Sarvatt: happy 4th
<Sarvatt> hey Richard, ya caught me in the middle of setting up a 150 package upload script getting ready for xserver 1.9 :) come over to #ubuntu-x?
<warewolf> sure
<rocky_IITM> RAOF, lifeless: yesterday I was telling .... I was doing memory allocation of  16KB (each block) and total of 65536 blocks. If the total blocks is increased more then 65536 the memory allocation fails... Please help me to find out the problem...
 * abogani waves
<abogani> Are there anyone interested to review and eventually upload -lowlatency and -realtime kernels?
<kraut> moin
<ogra> on both omap flavours i get oopses in parport_pc_probe_port
<apw> abogani, where are those again ?
<apw> will try and have a look at them today
<repete> Hi all
<repete> looking for some good troubleshooting steps for Bug #595047
<ubot2> Launchpad bug 595047 in linux (Ubuntu) (and 1 other project) "massive i/o renders the system unusable (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/595047
<repete> title should actually be changed.  I think it is a problem with how maverick swaps.
<bullgard4> I have installed the DEB program package Â»linux-sourceÂ«. Am I right in believing that installing the package Â»linux-docÂ« is thus dispensable?
<amitk> pgraner: heya!
<amitk> pgraner: didn't you create a table projecting future kernel releases somewhere?
<Keybuk> hmm, I'm confused by the kernel tree
<Keybuk> I have ssh://zinc/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-maverick.git
<Keybuk> but the latest commit seems to be Jun 2?
<Keybuk> ah no, maybe this is git being silly, since it's based on my upstream kernel tree
 * apw notes its beautiful out here
<abogani> apw: Git trees are on http://kernel.ubuntu.com/git. Prebuilt deb packages are available on my PPA https://launchpad.net/~abogani/+archive/ppa/+packages
<abogani> apw, Thanks a lot!
<apw> abogani, cool ... will try and get a second to look them over today before i sleep
<abogani> apw, You can take a look also tomorrow. I'm not in hurry I would want to have included those before Maverick release ;-)\
<abogani> apw, Thanks in advance and a lot!
<apw> abogani, if i keep putting it off till tomorrow, it never gets done.  its on my radar but keeps slipping
<bguthro> I'm not sure if this is the proper place for this, or not - but I've been working with the intel-gfx list to get a particular Dell laptop working (E6410) - I had posted about this here a week ago or so. The guys over at RedHat found a fix, and applied against the lucid 2.6.32 kernel, it works great for this machine. I think it might be worth cherry-picking into the LTS kernel, for these Ironlake chips
<bguthro> My original bug was https://bugs.freedesktop.org/show_bug.cgi?id=28746 - but this was marked as a dup of https://bugs.freedesktop.org/show_bug.cgi?id=28070
<ubot2> Freedesktop bug 28746 in DRM/Intel "[Ironlake LVDS] Dell E6410 boots to black screen" [Normal,Resolved: duplicate]
<bguthro> Ultimately, the patch worth cherry picking can be found here: http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html
<apw> bguthro, i would post the patch to the kernel-team@lists.ubuntu.com and suggest it for lucid in that case
<apw> mention the bug number in the email too
<bguthro> ok, will do
<apw> bguthro, actually give me a sec, just want to check thats not in stable
<apw> bguthro, ok i don't see it yet, so yeah send it on
<bguthro> ok, I'll send it out shortly
<apw> cool thanks
<jk-> bguthro: just a sec
<jk-> bguthro: Dave Airlie has done an update to that, IIRC
<bguthro> jk - was just about to hit 'send' - what's up?
<bguthro> I think this was the updated version
<jk-> nope
<bguthro> at least - the most up-to date posted to the bug
<jk-> https://patchwork.kernel.org/patch/108727/
<jk-> .. which has gone upstream
<jk-> we have a bug for this already, just a sec..
<jk-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554569
<ubot2> Launchpad bug 554569 in linux (Fedora) (and 3 other projects) "[lucid] Blank screen with KMS on Thinkpad X201 with Arrandale (i915) (affects: 29) (heat: 212)" [Undecided,Invalid]
<bguthro> jk - OK, I'll keep an eye on that patch as well. Thanks for the update.
<bguthro> jk, apw - I won't bother sending the bug in then, if there's already a launchpad bug
<ogra> tgardner, can i have an ompa4 upload in a forseeable future, there are so many fixes since the last upload and i have hangs on the pandaboard that i would like to see going away
<ogra> hrm
<ogra> *ompa
<ogra> bah !
<ogra> omap lompa ...
<ogra> i mean omap4 indeed
<tgardner> ogra, doing a test build right now, I'll upload if it is successful
<ogra> sweet, you rock !
<tgardner> I've just pushed some updates from TI
 * ogra hopes the hangs go away with it 
<tgardner> ogra, Sebastien reports that they have
<ogra> sadly i dont get any oppses or anthing it just hangs 
<ogra> great
 * ogra suspects the MMC driver 
<repete> Hi all
<repete> can anyone give me a pointer to troubleshooting for swap issues?
<astinus> repete: What kind of swap issues are you experiencing?
<tgardner> repete, I don't know that we have a page for that, other then 'make it big enough' when hibernating.
<repete> afaict, maverick on my device is over aggressive in swapping and I need to understand why and what is triggering the swapping.
<repete> I filed Bug #595047, which is not very well named
<ubot2> Launchpad bug 595047 in linux (Ubuntu) (and 1 other project) "massive i/o renders the system unusable (affects: 1) (heat: 161)" [Undecided,New] https://launchpad.net/bugs/595047
<repete> In the bug is a description of how I determined to concentrate on swap
<astinus> repete: How much memory do you have?
<astinus> repete: Output from 'free -m' would be helpful, as would graphing it over time with sysstat or similar
<cking> tgardner,  tseliot cannot get access to push to   git://kernel.ubuntu.com/mfrey/maverick-light.git - can you help us set the permissions correctly?
<astinus> repete: I guess that 'top -b -n 1' during problems would be helpful too
<tgardner> cking, well, you can't push using git:// protocol, and he also cannot push to mfrey's tree
<astinus> repete: Equally some output from 'vmstat' showing what your sytem is up to would help, perhaps try 'vmstat 1 60' to gather one minute of data
<repete> astinus, this is great stuff, thx
<repete> astinus, will try to trigger it (shouldn't be hard) and will add that to the bug
<apw> https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux/+bug/458299
<ubot2> Launchpad bug 458299 in linux (Ubuntu Karmic) (and 2 other projects) "apparmor_parser: page allocation failure. order:5 (affects: 4) (heat: 24)" [Undecided,Fix released]
<apw> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/602261
<ubot2> Launchpad bug 602261 in linux (Ubuntu) "apparmor causes thrashing and OOM during upgrade (affects: 1) (heat: 8)" [Undecided,New]
<pgraner> smb: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/602261
<apw> https://wiki.ubuntu.com/Kernel/Dev/KernelTesting
<tgardner> ogra, uploaded linux-ti-omap4_2.6.34-901.4
 * ogra hugs tgardner 
<smb> apw, commit d87815cb2090e07b0b0b2d73dc9740706e92c80c
<smb> writeback: limit write_cache_pages integrity scanning to current EOF
<apw> smb, bah ... just ticked something vile on the lucid kernel ... hard locked when i tried to quit a chroot
<smb> apw, All just complaining about poor Lucid kernels. :-P
<apw> yeah she is being a contancerous beastie today
<apw> and getting on my nerves
 * astinus has Lucid kernel issues
<cking> lucid bite back?
<astinus> :'( cantankerous beastie indeed, lots of regressions from Karmic
<mpoirier> apw: got time for a mumble ?
<apw> mpoirier, sure, drag me smoewhere
<bjf> moin all
<lag> Morning' bjf
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 1 hour 55 minutes - #ubuntu-meeting
<bjf> ##
<sconklin> apw: You may want to just be aware of this bug which exists upstream as well for Maverick https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/574733
<ubot2> Launchpad bug 574733 in linux (Ubuntu) "serve Xorg performance penalty due to [u]vesafb creating wrong PAT entries (affects: 1) (heat: 8)" [Medium,Triaged]
<apw> sconklin, ta
<mdz> pgraner, hmm, I just remembered something significant about bug 602261
<ubot2> Launchpad bug 602261 in linux (Ubuntu) "apparmor causes thrashing and OOM during upgrade (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/602261
<mdz> I was running the upgrader with ionice -c3, i.e. the idle I/O scheduler
<mdz> apw, ^
<apw> smb ^^  .... mdz interesting ... cirtainly not something the average joe would have done
<mdz> I tend to do that often when I'm going to continue using the machine
<mdz> my standard command-line upgrade script does it too
<mdz> sudo ionice -c3 apt-get dist-upgrade
<apw> yeah i wish i'd done that often with other commands
<pgraner> mdz: cool let me try that as well
<smb> Hm, have not used that much. Don't think it should cause jbd2 to lock so long, though
<smb> pgraner, You have the proposed kernel?
<smb> or do you want to try once before and after
<mdz> apw, it doesn't seem to work as well in 10.04 as it did in earlier releases for some reason
<pgraner> smb: I'm just trying to get it to repro first
<omry> hi, I bumped into 571422 with my new laptop. trying to do the workaround suggested in the first comment). how do I get grub2 to accept a boot flag for a kernel?
<apw> mdz, there are some changes in the stable pipe which may be related ... writeback is borked en-toto as far as i can see
<mdz> the idle scheduler used to do a really good job of preserving interactive responsiveness, but in 10.04+ it seems to be less effective
<mdz> dd if=/dev/zero of=bigfile bs=1M count=1024 makes my system pretty useless whether I run it with ionice -c3 or not
<apw> smb, are the writeback patches applied to anything yet?  that mdz could test ?
<smb> apw, I have a test kernel for the sync issue but that does not include that patch about extending faster that writeback is
<apw> smb, perhaps we should shove them both in a test kernel ...seeming this is getting to be a much complained of issue
<JFo> congrats cnd 
<smb> apw, Might be possible. Need to check which bug the rest is and see how well the other one applies.
<smb> apw, mdz Test kernels with only the other 12 patches are in http://people.canonical.com/lp585092
<smb> err http://people.canonical.com/~smb/lp585092
<mdz> smb, what would be the most helpful thing I could do with them?
<mdz> given that I haven't been able to reproduce the bug yet?
<smb> mdz, Given that, maybe just generically run with the ionice and see whether that feels swifter
<mdz> smb, OK
<tgardner> apw, what is that arcane git command that identifies in which branch a SHA1 exists?
<apw> git describe --contains perhaps
<tgardner> apw, nope, no joy
<apw> tgardner, i think i've done it via git merge-base
<apw> though thats iterative
<apw> if [ `git merge-base "$sha1" "$branch"`  = "$sha1" ]; then
<apw>   echo found
<apw> fi
<apw> sort of thing
<tgardner> apw, ick
<apw> yep
<jjohansen> JFo: server team wants us to prioritize Bug #576066
<ubot2> Launchpad bug 576066 in linux (Ubuntu) (and 1 other project) "ums_cypress missing from lucid server cd (affects: 1) (heat: 53)" [Undecided,Confirmed] https://launchpad.net/bugs/576066
<apw> jjohansen, is that the right bug # ?
<jjohansen> yep
<apw> well thats a bug about stuff missing from a cd, why is that our concern?
<apw> or is that a module name ?
<jjohansen> it seems to be a kernel packaging issue
<jjohansen> yeah ums_cypress.ko
<apw> jjohansen, is it even built for server ?
<JFo> jjohansen, looking
<jjohansen> apw: I have just started looking
<apw> jjohansen, and they are intreested in lucid ??
<jjohansen> so not there yet
<jjohansen> apw: yes
<apw> jjohansen, which CD is this, live or alternates ?
<jjohansen> both it seems
<jjohansen> reported for live and also on alternate
<apw> alternate is completely different from live 
<jjohansen> alternate is comment #6
<jjohansen> right
<apw> as in that is a sub-set
<apw> jjohansen, ok the built package contains that modules
<apw> -rw-r--r-- root/root      8736 2010-04-16 13:04 ./lib/modules/2.6.32-21-server/kernel/drivers/usb/storage/ums-cypress.ko
<apw> so the module is there at least on the live-cd's ... i can totally beleive the alternates do not
<apw> as that modules is not mentioened in d-i configuration so its clearly not on the alternate cd's
<tgardner> apw, it would have to be in a udeb module description somewhere
<apw> tgardner, right for the alternate cd's it would, and it is not, but for the live-cd that is the complete kernel package
<apw> and its in the kernel package
<tgardner> apw, so why do they think its missing from t he live CD?
<apw> they are not very clear in the bug, its possible it is all alternate 
<jjohansen> apw: I'll ask, I just started looking
<apw> jjohansen, ok if its just the alternate cd, then its a simple case of it being missing frmo the d-i configuration and yes its not in there now
<jjohansen> right
<apw> jjohansen, as they talka bout blades i am suspecting they are netbooting, which uses the alternates i think
<jjohansen> apw: indeed, thanks
<apw> jjohansen, if thats for lucid, its not going to make it out in a hurry ... 
<apw> smb, can a fix make the point release cd's still ?
<smb> apw, For Lucid only with much effort. Or rather unlikely
<apw> smb, yeah for lucid ...
<apw> jjohansen <--> smb
<jjohansen> apw: right, I'll let them know
<apw> jjohansen, waht do server want us to priortise it for ...
<smb> The current proposed will need two weeks to go updates, then there is a security update scheduled
<smb> jjohansen,  ^
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting
<bjf> ##
<smb> jjohansen, Not to forget there is a sprint before Jul-28, too
<jjohansen> smb: okay, thanks
<simar> Hi Please help me regarding how to forward kernel bug reports upstream ie to ubuntu kernel team or whosoever that take kernel bugs ...
<maco2> you can file a kernel bug wtih "ubuntu-bug linux" in your terminal
<sconklin> simar: Are you asking about bugs for which there are upstream bug reports but not Ubuntu bug reports?
<simar> You mean should i check some upstream like bugzilla for duplicate bugs .. By the i'm reffering to launchpad bugs in ubuntu bug #565543
<ubot2> Ubuntu bug 565543 in linux (Ubuntu) "Alps touchpad detected as ImPS/2 Generic Wheel Mouse(in VAIO E series) after the kernel upgrade (affects: 12) (dups: 1) (heat: 66)" [Undecided,Confirmed] https://launchpad.net/bugs/565543
<simar> sconklin, 
<omry> hi, I am trying to get ubuntu to work with my dell inspiron 17 laptop. 2.6.32 had a problem with suspend/resume. I upgraded to 2.6.34 (based on tip from 571422) and it solved that problem but now the broadcom wireless driver is not working.
<omry> found some info about that as well, but I need some help in applying the patch and getting the driver to build. (I am not familiar with the ubuntu method of doing this).
<apw> omry, is that using bcmwl ?  if so you may need the version from maverick
<omry> apw, yes - that's bcmwl
<omry> what's maverick, the next ubuntu?
<apw> i installed the version out of the maverick (next ubuntu yes) archive, i did this by hand i think
<apw> (everyone is in a meeting over on #ubuntu-meeting curerntly so you are likely to have poor response)
<omry> apw, so you just took the maverick bcmwl deb and installed it?
<apw> omry, pretty sure i did yes
<omry> cool. where can I get it?
<omry> (new to ubuntu as I said)
<apw> https://edge.launchpad.net/ubuntu/+source/bcmwl has links to all the releases and in those tabs should be the .deb links
<apw> omry, ^^
<JFo> simar, that is already a kernel bug on my radar
<JFo> linux(ubuntu) package is the ubuntu kernel package
<omry> will try to debuild the source package
<JFo> <-lunch
<simar> JFo, ya I have changed that but how to send the bug upstream. I mean according to my knowledge it contains necessary information that it could be traiged. What should i do to set it triaged .... just change the status..
<sconklin> simar: if you are asking how to make the Ubuntu kernel team aware of that bug - they already are, since it is filed against the kernel.
<simar> sconklin, Then can I set the status of the bug as Triaged ..
<omry> apw, I installed bcmwl-modaliases_5.60.48.36+bdcom-0ubuntu5_amd64.deb and  bcmwl-kernel-source_5.60.48.36+bdcom-0ubuntu5_amd64.deb
<omry> anything else I should do? modprob wl still wont find the module
<apw> <<Include(Kernel/Action/InstallGit)>>
<apw> <<Include(Kernel/Action/GitTheSource)>>
<omry> apw ?
<apw> omry, was for someone else
<omry> ah
<omry> what's the procedure to build the bcmwl kernel source package?
<apw> it should install by default when you upgrade it
<omry> hmm, I`ll try to remove and reinstall it
<omry> aha : kernel source for this kernel does not seem to be installed.
<omry> during installation. I think it should have failed on this
<omry> apw, don't you think it's a minor bug in the package?
<apw> omry, oh you need to install the headers package for the kernle too 
<apw> else the bwcml doesn't build
<omry> doing it just now
<omry> the bug I am claiming is that it did not fail the deb installation
<omry> (when the headers were not installed)
<apw> thats actually how its meant to work
<apw> but you normally get both together via the meta packages
<omry> I see
<omry> so I guess it's okay. anyway, looks like it's working
<omry> going to reboot just to be sure it continue to work. 
<omry> thanks for your help.
<apw> omry, cool
<omry> apw, yup. all is well now (including the sleep/resume thing that started this mess)
<apw> omry, thats good news
<omry> yeah. it means this laptop will probably work almost out of the box on the next ubuntu (almost because users still need to install the bcmwl driver)
<omry> one possible problem is that I don't have the battery icon now (I had it before the kernel upgrade).   but since I get a popup when I disconnect the ac, I think it's a cosmetic issue.
<mrjazzcat> A customer has asked me to poke around and see if anyone has played with ext3 on an SD.  Have you?  Got anything good or bad to say about it?
<lifeless> morning
<lifeless> so I'm running the lucid ppa backport at manjo's suggestion, to see if it helped my wifi - as of yesterday or thereabouts, I can't start VM's now.
<tgardner> lifeless, its a known problem.
<lifeless> tgardner: ok thanks
<lifeless> I'll just stop apparmor for now then :)
<lifeless> also on the 2.6.35-6 kernels, my machine reboots every now and then; I don't have any diagnostic data yet - is that known too 
<lifeless> ?
<apw> bjf, is the any other business section missing from the meeting minutes ?
<bjf> apw, have i missed something?
<tgardner> lifeless, dunno about that, I'm about to upload an -rc4 based kernel pretty soon which ought to fix it. 
<tgardner> ought --> might
<lifeless> cool
<jjohansen> -> lunch
<bjf> apw, i have no clue what you are referring to
<apw> bjf the minutes you sent out stop at jfo's last entry, the AOB discussions are missing
<apw> at least to my reading
<bjf> apw, you are correct, that is very odd, will resend
<apw> bjf, as long as the wiki is right i'd probabally not bother
<apw> i have assumed it is also short
<apw> but not checked
<bjf> apw, it gets picked up by ubuntu-news
<apw> ahh
#ubuntu-kernel 2010-07-07
<hallyn> well bug 602060 does seem to be a kernel bug, fixed in maverick.  haven't found an obvious commit responsible for fixing it...
<ubot2> Launchpad bug 602060 in libvirt (Ubuntu) (and 1 other project) "Virtio network stops working after dynamic virtio disk attachment (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/602060
<jjohansen> hallyn: thanks, looks like we will need to do some bisecting
<hallyn> jjohansen: the painful part is bisecting in a guest :)  reckon there are ways around that.
<jjohansen> heh, yeah bisecting in a guest would be painful :)
<hallyn> jjohansen: anyway i wasn't quite sure whether i should be marking this as 'affects kernel', in case someone on kernel team recognizes the source of the bug
<jjohansen> hallyn: yeah that is the best way to make sure it gets looked at
<hallyn> i was spared having to decide by launchpad going down (hence my piping up here)  :)
<jjohansen> :)
<hallyn> jjohansen: but thx, i'll do that tonight or tomorrow
 * hallyn out
<jjohansen> night hallyn
<apw> morning
<lag> Morning
<ogra> apw, could i get an updated omap4 meta ? the new kernel built and is in the archive (so i can roll images with the new kernel)
<apw> ogra, they look to match to me ?
<apw> moduleo the .35 hack in meta
 * smb waves to apw
<apw> morning smb
<apw> ogra, ?
<ogra> apw, meta has a versioned dep on the linux-image package, no ?
<ogra> so i need a new meta to build images with the new kernel
<ogra> (tim uploaded a new omap4 kernel yesterday)
<apw> ogra, the linux-meta is dependant only on the abi number, they are both at 901 so i think we are good
<ogra> oh, ok
<ogra> i wonder what i have on my images then
<ogra> since if the meta depended on 901 and we only had 900 in the archive i dont get how the images could have a kernel image
 * ogra checks versions
<ogra> 2.6.34-900.1 was the old image
<apw> no the last upload was from 901.4 to 901.5 or whatever
<ogra> then the changes list lies
<ogra> i only see two uploads of linux-ti-omap4 ... one was 2.6.34-900.1 the next was yesterday and 2.6.34-901.4
<ogra> between the two you made the change to meta
<ogra> and livecd-rootfs only installs meta 
<ogra> i dont get how i got the kernel then
<apw> ogra, there was a 901.2 as well
<ogra> weird, i dont see it on maverick-changes
<apw> i did the meta update after the 901.2 was in
<ogra> hrm, LP agrees with you https://edge.launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.34-901.2
 * ogra doesnt get why that was swallowed on changes then
 * abogani waves
<abogani> apw, Do you have some news for me? :-)
<apw> not as yet, but you are very close to the top of my list ...
<abogani> apw, Ok. Sorry to bother you so frequently.
<apw> nope you are fine, i need reminding, i have a lot of people doing the same and sometimes it is a case of he who whines loudest :
<abogani> apw, I understand but however I don't like doing it although Italians are famous for that.
<apw> abogani, can you explain why this would need the getsource change, i cannot see why it would as we are in a full source tree ?
<abogani> apw, Sorry?
<apw> you have added a getsource clause, and i am wondering why
<abogani> apw, Ah sorry. Because -lowlatency (it change only configuration not code) don't need to have a full copy of sources. It uses linux-source-2.6.3x. It should do archive admin happy (save a lot of space).
<apw> abogani, if we upload it with an orig it would share the source anyhow
<apw> which exists after we hit 2.6.35
<jpds> Hey, could someone tell me what might be the cause of http://people.canonical.com/~jpds/pic2.jpg ?
<apw> and from what i can see you commit doesn't remove the source from the tree so it would be in there anyhow
<apw> jpds, what were you doing when it occurred ?
<jpds> apw: Booting the device.
<apw> jpds, also what kernel version is this, on what release
<jpds> apw: Lucid, 2.6.32-22-generic-pae kernel on an Acer Revo.
<apw> jpds, the key information is off the top of the scree
<apw> screen, so its not easy to be 100% sure what happened, but it looks like the allocator exploded
<apw> is it kernel specific, ie can you move back a kernel?
<gnosek> hi all, is there an archive of the repo at http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-intrepid.git ?
<abogani> apw, Should I remove getsource so?
<smb> gnosek, http://kernel.ubuntu.com/git-repos/ubuntu-archive/ubuntu-intrepid.git
<apw> abogani, i'll spend a bit of time looking over things and give you a proper response in email, its looking pretty good overall, some oddies which i think need cleanup, but much due to our stuff, ie things we should make configurable so you don't have to hack the rules
<abogani> apw, Ok. Thanks again for all.
<apw> smb, remind me how to make the font small on boot ...
<smb> apw, must be in cking blog somewhere
<apw> heheh must be
 * apw waits on his-holiness
<smb> apw, Maybe something in /etc/default/term...?
<apw> yeah if its a boot issue?  i am sure you used to be able to do foo=ask, though ask stopped working i think
<smb> err no /etc/default/console-setup
<smb> apw, Would vga=6 still work? at least until kms kicks in
<apw> smb, might do yeah ... gnosek ^^
 * cking checks
<cking> http://smackerelofopinion.blogspot.com/2009/06/getting-more-out-of-your-kernel-oops.html
<cking> probably out of date now
<lag> jpds: Did you try using Ctrl+Page up? to see the top of the trace log?
<gnosek> smb: thanks a lot
<apw> gnosek, checkout that cking link
<gnosek> apw: ? smb already gave me the link to .../ubuntu-archive/...
<apw> gnosek, ok
<mdz> apw,smb: I'm getting ready to upgrade another system to Maverick, where I've seen the memory starvation issue before
<mdz> it's currently running 2.6.32-23.37
<apw> mdz ok
<mdz> what do you think I should try?
<mdz> I wonder if I should try using mvo's rollbackable upgrader so I can test it more than once
<mdz> apw: should I try with ionice or without? should I update to -24 first?
<apw> mdz, its a tricky one, as its not generally reproducible its hard to know what any specific positive means
<apw> i guess we want to know if the version you were on is generally at fault for your method
<mdz> apw: I guess my goal should be to try to reproduce it, so I should match the conditions from my previous upgrade as far as I can
<apw> so i'd be inclined not to upgrade and to use ionice
<mdz> right
<mdz> agreed
<htorque> hello, is the latest mainline kernel from the PPA known to cause problems with input devices?
<htorque> PC: keyboard not working (PS/2), notebook: keyboard and touchpad not wokring. with a tailord custom kernel config, -rc4 seems to work fine on the notebook, though.
<apw> htorque, i think there was a suspect patch which broke the keyboard controller but i thought that was fixed in -rc4
<mdz> apw: remember how I was saying that even with ionice -c3, heavy I/O was very disruptive on my laptop? this system is *much* more well-behaved under high I/O regardless of the scheduler used
<apw> mdz i386 can only use somewhat less than 1GB for the kernel direct mapped data, so that has an effect on allocation balance, though quite why that would trigger this result is unclear
<mdz> it seems like perhaps I have a general I/O misbehavior on the other system which I don't have here
<mdz> I'm going to go ahead and upgrade this one to maverick anyway and see what happens
<Omahn> Quickie.. Is https://help.ubuntu.com/community/Kernel/Compile the official guide to compiling a kernel on Lucid?
<tgardner> Omahn, start here: https://wiki.ubuntu.com/Kernel
<Omahn> tgardner: I did, spent quite a while looking and then gave in.
<Omahn> The background. I have a problem that I believe can be worked around by disabling a single option in the kernel so I would like to compile a fresh kernel that matches the Lucid kernel as close as possible, albeit with that option disabled. But that Kernel/Compile link I mentioned above doesn't appear to include information on Lucid. 
<apw> Omahn, that is one of the bits of documentation thats a bit thing
<apw> thin, and indeed on manjo's todo for the next couple of days
<apw> the idea will be to have a 'how to change one option only and build a personal kernel' guide
<apw> but right now we do not really have that in a simple form
<apw> Omahn, which option is it
<Omahn> apw: CONFIG_CIFS_XATTR - related to bug #557890
<ubot2> Launchpad bug 557890 in linux (Ubuntu) "transfer lockup connecting to a NetApp/CIFS share (affects: 3) (heat: 53)" [Medium,Confirmed] https://launchpad.net/bugs/557890
<htorque> awp: i see "CONFIG_SERIO_I8042=y" in 2.6.35-6-generic and my custom config, but not in the PPA's kernel
<htorque> apw: ^^^ (sorry, typo)
<tgardner> ogra, have you had a chance to try the ti-omap4 kernel?
<ogra> tgardner, yeah, its awesome
<tgardner> ogra, cool. no hangs?
<ogra> it still locks up at some point but i currently blame the framebuffer driver 
<ogra> and its random after like 1-2h of use 
<ogra> (before you could only use the system for a few mins if it came up at all)
<tgardner> ogra, sounds like memory corruption or exhaustion
<ogra> right
<apw> JFo, about ?
<ogra> but its related to video, it only happens if i use X
<bjf> manjo, https://wiki.ubuntu.com/Kernel/kteam-tools
<JFo> apw, yep
<apw> JFo, you mentioned you had a bunch of FAQ entries you wanted to add, and wondered if there was a list somewhere
<manjo> bjf, thanks
<JFo> I have a rough one written in some of my notes
<JFo> let me see if I can find it
<JFo> if not I will make you up some off the top of my head and we can discuss them
<JFo> I need to take another look at what is there already as my notes were written in something of a vacuum
<tgardner> manjo, when was the last time you checked out kteam-tools ? Your page on https://wiki.ubuntu.com/Kernel/Action/Scriptbuildmkschroot is not accurate
<manjo> tgardner, I just got pinged by bjf about that.. thanks
<bjf> manjo, i was pointing out we were starting to duplicate our wiki pages
<manjo> bjf, I am working on removing dups & putting them in correct places 
<htorque> apw: 'CONFIG_SERIO_I8042' was set to 'no' due to 'CONFIG_X86_MRST=y', which got set to 'n' with the latest update (the PPA will follow I guess?) - so, everything's fine :)
<apw> htorque, thought so, yep, thats a mess and needs someone upstream to fix it
<apw> JFo, yeah figured if we had the 'questions we should but do not have' people could fill them in as they had time
<JFo> yep
<JFo> I'll add the ones I have to the page so they can be answered as we go
<JFo> some of them... well ok most, I don't have the answers for :)
<apw> JFo, i suggest you add a == Needed Questions == section to the FAQEdit page
<apw> and put the raw questions there, then we know where to look for them
<JFo> sounds good. Will do
<JFo> apw, want it after the existing questions?
<apw> jfo before i recon
<JFo> ok
<apw> JFo, hrm did you add those questions, seems to only be a * now
<JFo> not yet, I'm reviewing what we have already versus what I thought was missing back when I took my notes
<JFo> plus I am digging through bank statements and receipts for petra
<bjf> manjo, i'm confused why we need both https://wiki.ubuntu.com/Kernel/Action/GetKernelToolsScripts and https://wiki.ubuntu.com/Kernel/kteam-tools
<manjo> bjf, don't worry about it now, it will be all dealt with at the sprint 
<bjf> manjo, just seems like wasted effort doing them both
<apw> bjf, i suspect they will end up sharing the contents
<bjf> pgraner, any thoughts on apport symptoms?
 * smb prepares for watching tv
 * tgardner lunches
<omry> is there a known issue with 2.6.34 that can cause lockups with dell laptops (inspiron 17) ?
<omry> I am running lucid, and had to upgrade due to a suspend/resume issue with 2.6.32, but then my box started to freeze up randomly. issue was resolved when I booted 2.6.32 again.
<apw> omry, not many people are runnig .34 it not being a kernel we are based on.  does it appear with the maverick kernels
<omry> didn't try yet actually.
<omry> got the 2.6.34 deb here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-rc5-lucid/linux-image-2.6.34-020634rc5-generic_2.6.34-020634rc5_amd64.deb , if it matters
<tgardner> omry, subscribe to the Maverick LTS backport kernel at http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu
<omry> tgardner, NO_PUBKEY A8267963484B044F , where do I get the key?
<tgardner> omry, go to the page at http://launchpad.net/~kernel-ppa/+archive/ppa
<tgardner> omry, click on 'What is this?" next to the signing key.
 * cking_ shifts gear to zzz mode
<omry> tgardner, thanks. that all apt-add-repository thing confused me but it's good now.
<omry> installing 2.6.35-7-generic, hopefully this one will work for me.
<tgardner> omry, that kernel will be updated until Maverick is released at which time it will appear as a component in Lucid (i.e., you won't have to do anything)
<omry> you mean my system will keep upgrading it till maverick is released, right?
<tgardner> actually, it'll keep upgrading it until Maverick is no longer maintained
<omry> right
<apw> manjo, were you looking for me ?
<jjohansen> -> Lunch
<manjo> apw, looks like olivia won some money 
 * bjf is taking a break, will be back later
<ripps> what's taking so long to get linux-2.6.35-7.11 out of maverick queue. Getting some aptitude errors because linux-meta was pushed to repo before it.
<kees> ripps: looks like it's still in the binary-NEW queue.
#ubuntu-kernel 2010-07-08
<omry> I want to play with systemtap, my current kernel is 2.6.35-7-generic #10~lucid1-Ubuntu, will this ddeb work? : 	linux-image-2.6.35-7-generic-dbgsym_2.6.35-7.10_amd64.ddeb
<TeTeT> apw: morning, we have an escalated case from corp services that is now in the kernel teams hands, see bug 586325
<ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 14)" [Medium,Confirmed] https://launchpad.net/bugs/586325
<apw> RAOF, about?  t
<apw> RAOF, t
<RAOF> apw: Yo!
<apw> RAOF, the patch on bug 586325 ... where is it upstream ?
<ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 14)" [Medium,Confirmed] https://launchpad.net/bugs/586325
<apw> morning, or evening :)
<RAOF> It's just attached to the upstream bug at the moment.
<RAOF> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/586325
<ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 14)" [Medium,Confirmed]
<RAOF> Ahem.  Wrong window.
<RAOF> And a good morning to you too :)
<apw> RAOF, good work finding that patch
<RAOF> I didn't end up writing it.  Once I had hardware to test on the problem was much more obvious.
<smb> RAOF, morning, as well. Any chance to let people try my test kernels? (nag)
<ikepanhc1> good morning .eu :)
 * smb waves towards asia
<ikepanhc1> I can hear you on mumble, but in public area of office, so have better to keep quiet :P
<RAOF> smb: I still haven't run into anyone appropriate to send to that kernel.
<smb> RAOF, Bah, and I thought there were quite a few of the inconsistent checksum messages
<apw> RAOF, i see that there is a final comment in the ipstream bug that its not fixed for krandrtray if its in the bottom right
<apw> ikepanhc1, heh morning
<smb> ikepanhc1, You should do. Maybe you get a nice isolated space then ;-)
<ikepanhc1> smb: sure, moving
<RAOF> apw: I hadn't seen that, no.  Let's see if I can check that.
<apw> you may find like 'sleep 10; xrandr ....' in a window and shoving the cursor in the bottom right might do the same
<RAOF> Yeah, looks like it.
<smb> ikepanhc1, I actually meant if you speak up while on your normal pace you might get moved to a place where you cannot disturb anybody. Hope would be that this place would be nicer too. Though reality shows its rather the janitor's closet
<RAOF> Hm.  I waved the cursor around, but obviously not all the way down in the bottom right.
<ikepanhc1> ah? anyone hear me?
<jk-> 'git bisect run' <3
<ikepanhc1> apw: the bad wiki I wrote: https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide
<kraut> moin
<RAOF> apw: Hm.  I've managed to make that happen exactly once, but I'm not sure how.  I have noticed another problem, though, which might resolve it - the pointer is hidden in some situations when it shouldn't be.  It looks like the bounds checking is off a bit.
<smb> kraut, moin
<kraut> howdy smb
<apw> RAOF, ahh ok
<apw> can't we just zap the cursor to the top left on change
<RAOF> We could, perhaps.
<RAOF> The hardware docs however say âat least one pixel of the pointer must be on the active displayâ, so enforcing this constraint in the kernel seems reasonable.
<RAOF> You know what would be useful in the docs?  Which point of the 64x64 image the GPU considers to be the âpositionâ of the cursor :/
<RAOF> Oh, no.  There it is.
<apw> RAOF, right, but could we not enforce that by moving it, rather than unmapping it ?
<hrw> hi
<hrw> can you look at bug 603087 and tell me does my patch has any chance to be accepted?
<ubot2> Launchpad bug 603087 in linux (Ubuntu) "Allow to build just linux-libc-dev (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/603087
 * apw talked to hrw about thsi over on #linaro
<RAOF> apw: We could move it, but then the cursor displayed position wouldn't match the position X thinks the cursor is.
<apw> RAOF, hrm, ok
<hrw> is there a way to not generate linux-headers-VER package? rules.d/2-binary-arch.mk makes them if do_common_headers_indep != true but  rules.d/3-binary-indep.mk makes them if do_common_headers_indep == true
 * RAOF is somewhat freaked out about the behaviour of the cursor.
<apw> hrw, no by default no as you would never want to do that
<hrw> apw: unless my case
<apw> hrw, you need to find the 5 bits and put them all in stage1 or stage2
<apw> as you have for the headers ... right ?
<apw> you have 'headers' and everything you didn't make then needs to be made in 'rest' or whaever you called it
<hrw> apw: http://pastebin.com/Xy5cCt8b does what I want but is rather ugly
<apw> binary-debs doesn't look to need to change, as you turn it off in the if part
<apw> we should probabally make a build-arch-deps and build that the same way to clean it up
<smb> tgardner, Hi Tim, I was thinking on Karmic stuck in accept and in the end I think if we don't have it accepted by next Monday, I need to sit together with apw and get all changes reverted
<tgardner> smb, what is the rush? Do you have CVEs pending for it?
<smb> tgardner, yes
<hrw> apw: http://pastebin.com/bNE1d6PB is a bit more clean
<apw> hrw i really don't think you shoul dneed to change any of the configuration here
<apw> for example changing the icommon headers to indep, might have an effect on other things
<apw> we should just make both adds to _deps conditional
<hrw> do_common_headers_indep:=false is just to not build it at all
<apw> but you want to buld the headers
<hrw> I want linux-libc-dev not linux-headers
<apw> thats the point of the header stage
<apw> then calling the stage headers is a bit mad
<hrw> thats just name - will rename it to stage1
<apw> ok i think the way i would do it is to make an enable_stage1 and enable_stage2
<apw> with something like
<apw> if ($(DEB_STAGE), stage1)
<apw> enable_stage1=true
<apw> elif ($(DEB_STAGE), stage2)
<apw> enable_stage2=true
<apw> else
<apw> enable_stage1=true
<apw> enable_stage2=true
<apw> fi
<apw> and for each element put it in one or the other
<apw> if (enable_stage1, true)
<apw> endif
<apw> and make sure each element 'headers' 'tools' 'libc' etc are added to an _dep
<apw> in that manner
<hrw> where stage1 is what I want and stage2 is normal build?
<apw> no where stage1 is what you need in stage1, and stage2 is the rest
<hrw> ok
<apw> and a normal build just enabled both
<apw> i am sure you will want to build the rest, not everything in the second phase, as you have the headers already
<apw> hrw, _or_ i guess we do already have a bunch of do_ variables for some things
<apw> to allow those to be suppressed, you could also add one of those for each
<apw> of the things you want to but cannot yet control
<apw> and then do
<apw> if $(DEB_STAGE, stage1)
<apw> do_xxx = false
<apw> do_yyy=false
<apw> endif
<apw> that might be the cleaner form
<tgardner> apw,smb, remind me of the 2 mailing lists that get notified of an ABI bump
<apw> given we have a few of the do_foo = true/flase already
<hrw> ok, will adapt
<smb> one is mobile
<apw> kernel-team, debian-installer, ubuntu-mobile
<apw> To: kernel-team <kernel-team@lists.ubuntu.com>,
<apw>         ubuntu-installer <ubuntu-installer@lists.ubuntu.com>,
<apw>         ubuntu-mobile <ubuntu-mobile@lists.ubuntu.com>
<smb> right
<tgardner> apw, that stuff used to be in the wiki
 * apw will go and add it
<apw> i will add a maintainer quiestion section
 * abogani waves
<abogani> apw, I'm your personal nuisancer! :-)
<apw> yeah i know :)  you are on my mind and indeed in this window over -->
<phil42> what changed in 2.6.24-28.71-generic ?
<tgardner> phil42, http://launchpad.net/ubuntu/+source/linux/2.6.24-28.71
<hrw> apw: http://pastebin.com/cmpBJqEN should be better
<apw> hrw that does look much cleaner
<tgardner> apw, what is the goal of these patches?
<apw> tgardner, linaro need to be able to bootstrap in a cross-compile env
<apw> that means they need to build the compiler to build the kernel, but the kernel headers are needed to build libc to build the compiler
<apw> so they need to be able to build a subset of the kernel package
<apw> they are applying similar DEB_STAGE changes as a policy
<tgardner> apw, ok, I guess that makes sense
<apw> i suspect these will go round a couple of times more yet, but they are clearer now in intent
<hrw> gcc and eglibc are next in queue
<tgardner> apw, looks like the i8042/Moorestown stuff is shaking out upstream
<apw> tgardner, good to hear ... was worried it'd get forgotten
<tgardner> apw, what is the tip-bot ? I've been meaning to ask that for awhile
<apw> tgardner, its a litterally a bot which is associated with the tip tree which is used to hoover
<apw> up lots of littl changes as little topic branches
<tgardner> so, just specific trees?
<apw> there are hundreds of branches in the tip tree
<tgardner> apw, ok, I see now. one tree with lots of branches.
<apw> yeah lots and lots of little branches
<tgardner> apw, who commits to tip? just Ingo?
<apw> tgardner, yeah as far as i know its all ingo
<lacostej> Hei, I am trying to compile my own ubuntu kernel (to apply a patch I want to test). I want to make sure I use the exact same config. Should I copy /boot/config-`uname -r` into debian.master/config or is the source I got from git tag already properly configured ?
<tgardner> lacostej, the configs that are generated for your kernel live in debian.master/config and are properly configured during the prepare build step.
<lacostej> is there a simple way to make sure my generated kernel won't conflict with the existing one ?  e.g. by bumping the version number somewhere ?
<tgardner> lacostej, thats more involved. apw might be able to point at a wiki page since he's been the most recent gardener
<tgardner> lacostej, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance describes bumping the ABI
<lacostej> thanks a lot
<apw> yeah htats probabally the simplest we have at the moment
<apw> we have it on our list as one which we need to write
<hrw> apw: any suggestions what I should change to get it accepted?
<apw> hrw once you know it does what you want send it up and i'll have a re-look at it fresh
<hrw> ok
<hrw> doing native full build now with this patch attached
<apw> hrw got a link to the current patch ?
<hrw> apw: http://launchpadlibrarian.net/51576134/linux-add-stage1-support.patch
<apw> hrw, thanks
<tgardner> gnarl, note sent to SRU team requesting Karmic acceptance
<gnarl> tgardner, Ok, thanks. I guess I will see what happens  soon
<gnarl> apw, Oh, I forgot to get back to you and nag you to try new tooling. :-P
<tgardner> gnarl, did you already bang this out on a different list?
<gnarl> tgardner, I have not done more than arguing with Colin and Martin
<gnarl> tgardner, But that was on irc or the phone
<tgardner> gnok, then this'll drag it out into the public
<apw> heheh
<tgardner> gnarl, ^^
<apw> gnok gnok, who's there
<gnarl> tgardner, ack
<gnarl> apw, gnobody
<apw> gnarl, we need an incantation for your maint scripts so they can find each other without needing path
<apw> i use the same a lot in my shell scripts
<apw> gnarl, t
<gnarl> apw, Hm, I dont need that as they are in my path
<tgardner> apw, CDIR=`dirname $0` sort of thing?
<apw> yeah that sort fo thing, there is some subtlty for ./ i think
<apw> gnarl, its not quick
<apw> apw@dm$ maint-startnewreleaseII: linux-image-2.6.35-7-generic_2.6.35-7.11_i386.deb
<apw> II: Downloading to kernel.ubuntu.com ...
<bjf> moin all
<cking_> pgraner, /sys/kernel/debug/tracing/buffer_size_kb
<lag> pgraner: cat /sys/kernel/debug/tracing/current_tracer
<pgraner> apw: http://pastebin.ubuntu.com/460671/
<tgardner> sconklin, we're looking at a bug that might affect your living room laptop
<sconklin> awesome. Only it's not in the living room any more. Susan practically threw it at me
<tgardner> sconklin, bug #501715
<ubot2> Launchpad bug 501715 in ureadahead (Ubuntu) "Kernel trace buffer should be cleared and size restored after profiling (affects: 52) (heat: 280)" [High,Triaged] https://launchpad.net/bugs/501715
<sconklin> tgardner: that's evil
<sconklin> It would also explain why it shows up on this laptop with only 1G of RAM in it
<cking_> sconklin, echo 1 >/sys/kernel/debug/tracing/buffer_size_kb and see if the bug goes away
<sconklin> cking_: well, it hasn't reproduced yet this boot, but I can do that and see if memory use changed significantly
<tgardner> cnd, are you around?
<cnd3> tgardner: yep
<cnd3> what's up?
<tgardner> cnd: mumble about tracing
<cnd3> ahh, can't mumble
<cnd3> I'm in the car
<cnd3> is irc ok/
<tgardner> cnd: drive, quit talking to me!
<cnd3> ?
<cnd3> heh, I'm a passenger
<cnd3> I'm working
<cnd3> I can skype if you want
<cnd3> there's just no mumble iphone client afaik
<apw> cnd3, how do i confirm that ftrace is off 100%
<cnd3> apw, let me check
<tgardner> cnd: thats OK, we just had some general questions about the tracing mechanism. it can wait
<sconklin> cking_: that made no detectable difference in anything, including current memory use
<cnd3> apw: echo 0 > /sys/kernel/debug/tracing/tracing_enabled
<cnd3> there's also tracing_on
<cnd3> I'm not sure of the semantics of the two
<apw> cnd3, and if it is on, can i tell what if anything is enabled to be recorded?
<gnarl> cnd3, If tracer us nop does it use up some resources?
<gnarl> is
<cnd3> apw: let me check
<cnd3> gnarl: the tracer buffer can record function tracing and trace events
<cnd3> so if current_tracer is no
<cnd3> nop
<cnd3> you won't get function traces, but you could still get trace events
<gnarl> ok
<cnd3> you can disable all trace events by:
<apw> yeah thats my worry, so what events are on
<apw> i need to know which ones
<cnd3> echo 0 > /sys/kernel/debug/tracing/events/enable
<cnd3> you can see which events are enabled:
 * apw pokes cnd3
<cnd3> yeah, I was trying to figure it out
<cnd3> I thought there was an easy way
<cnd3> you can look inside /sys/kernel/debug/tracing/events
<cnd3> it's a hierarchy of events
<cnd3> each folder has an enable file
<cnd3> and enabling or disabling affects all children of the folder
<cnd3> and each event (leaf nodes in the tree) has an individual enable
<cnd3> but I'm not sure if there's any easier way to be sure
<cnd3> now, I am guessing that if you disable the ftrace buffer then you probably don't have to worry either
<cnd3> I think that's what /sys/kernel/debug/tracing/tracing_on does?
<cnd3> let me check the docs
<apw> cnd3, yeah we think we are ending up leaving ureadahead with its items turned on, and its putting tracing back to the previous value which may be on ... with a huge buffer configured ... and eating all your memory over time
<tgardner> apw, tracing gets restored, but the buffer size is left large
<cnd3> ahhh!
<cnd3> let me play for a second
<cnd3> tgardner, you mean the events get turned off?
<cnd3> but they're already in the buffer?
<apw> tgardner, so if it was on by default, with nothing enabled, then ureadahead  adds some trace points to record, then 'restores' the on off state to on, and quits
<tgardner> cnd: the events _do_ get restored to their original values, dunno what the starting state was though
<apw> it'll leave the events on
<apw> hrm ok
<cnd3> what are the events caallled?
<apw> i'd think they'd be off by defualt, if it works
<tgardner> apw, it sets events/fs/do_sys_open/enable, events/fs/open_exec/enable, events/fs/uselib/enable, and tracing_enabled after first reading their current values.
<cnd3> apw, tgardner: is one of the events do_sys_open?
<tgardner> cnd: events/fs/do_sys_open/enable
<cnd3> tgardner: so it sets them to 0 after it's done?
<sconklin> cking_, tgardner: I applied the startup script workaround and rebooted, and base memory usage dropped by about 100M.
<tgardner> cnd: no, it restores them to their original values
<cnd3> tgardner: what does that mean?
<cnd3> this is at boot up
<cnd3> so I'd assume 0?
<tgardner> cnd: we could assume taht, but I don't know for sure.
<cnd3> I guess you can turn them on at the command line
<cnd3> so what we really need is just a way to clear out the ftrace buffer after use?
<tgardner> cnd: the only parameter that ureadahead doesn't restore is buffer_size_kb
<apw> tgardner, i think for this behaviour to be the cause it would have to be failing to restore them then
<apw> and we should get pgraner to run: cat `find /sys/kernel/debug/tracing/events/ -name enable` | grep -v 0
<cnd3> also, I think the buffers are preallocated
<apw> on the system which he cleaned up
<cnd3> I guess maybe ureadahead is setting the buffer size too large and we need to reset it back to a reasonable default
<cnd3> but it wouldn't show an increase in usage over time
<tgardner> apw, well, the restore code looks right. 
<apw> i was more thinking some case in which it doesn't do it at all
<apw> if not pete simply has a little time to wait for the issue to return
<tgardner> apw, about the only place I can see that would happen is if the daemonize fails
<sconklin> well, I've applied the workaround, and I'm still running a kernel with kmemleak debugging turned on - so if it happens again maybe I'll have a clue
<cnd3> sconklin: what's the work around?
<cnd3> hrm, one bar of signal, I may be lost soon
<cnd3> oh at&t...
<sconklin> cnd3: http://ubuntuforums.org/showthread.php?p=9271524#post9271524
<cnd3> wth, why is the buffer size being set to 128 MB!
<cnd3> that's per cpu!
 * cnd3 thinks the param used to be in bytes, meaning 128 kb, so maybe this was overlooked?
<cnd3> ureadahead really need to be resetting that to the defaults after it changes them
<tgardner> cnd: I'm working on that.
<cnd3> k
<cking_> if it's per CPU that explains why i7 machines are suffering
<cnd3> is this something new in maverick?
<cnd3> or in lucid and earlier?
<jjohansen> cnd3: I don't think it was ever supposed to be kb, the server team hit problems last cycle with this keeping small vms from booting
<tgardner> cnd: same code in Lucid at least
<jjohansen> cnd3: definitely in lucid
<tgardner> have not checked earlier
<cking_> yep, we are seeing it hit hibernate on Lucid
<apw> cnd3, per CPU, now that would explain a fwe things
<cnd3> yes, I'm 99% sure it's per cpu
<cking_> cnd3, it looks like it in the code
<cnd3> I'm not as sure that it preallocates though
<cnd3> I just thought so
<apw> i suspect not as mine say 'reallocated' and lots of coutns on it
<apw> but it could get full up over time for sure ... and that'd be 1GB on petes machine
<cnd3> I may have been thinking of the profiling buffers
<cnd3> I know the profiling statistics are kept in preallocated buffers
<cnd3> but those buffers are different from the ftrace event buffer
<apw> cnd3, if you have a chance to investigate could you look at whether the buffer size is simply a minimum
<apw> ie the preallocated size, as i am seeing this in my siz
<apw> 7 (expanded: 1408)
<cnd3> sure
<cnd3> I'll look right now
<cnd3> what's this "7 (expanded: 1408)"?
<apw> that is whats in my size
<apw> apw@dm$ cat buffer_size_kb
<apw> 7 (expanded: 1408)
<cnd3> I only have the maverick kernel right now though
<apw> so i am wondering if it can expand or not
<cnd3> yeah, in maverick the semantics changed
<cnd3> cat buffer_size_kb:
<cnd3> 128000
<gnarl> cnd3, I got both outputs for lucid on two machines... odd
<apw> i think its different if you set it and not, or something
<cnd3> hmmm
<apw> or the setting is the minimum and it can expand, or, hence the question
<cnd3> yeah
<mdz> apw, hi
<apw> mdz, hi
<mdz> apw, pgraner was just telling me that this may be related to tracing being enabled
<tgardner> apw, just emailed a ureadahead patch that you should experiment with. I have to take off.
<apw> mdz we have found a couple of scenarios where machine are very unhappy if ureadahead has left the tracing buffers expanded
<mdz> apw, how can I check if that's the case on my system?
<apw> tgardner, ta will look tommorrow
<mdz> perseus:[/sys/kernel/debug/tracing] cat current_tracer 
<mdz> nop
<mdz> perseus:[/sys/kernel/debug/tracing] cat tracing_enabled 
<mdz> 1
<apw> mdz cat the buffer size one
<mdz> apw, perseus:[/sys/kernel/debug/tracing] cat current_tracer 
<mdz> nop
<mdz> perseus:[/sys/kernel/debug/tracing] cat tracing_enabled 
<mdz> 1
<mdz> er
<mdz> 128000
<apw> it will only be big if you had a ureadahead rebuild last time
<apw> yeah like that... the current thought is that this is 128MB per cpu
<apw> cnd3, is confirming what the size means currently
<apw> but ... we suspect this isn't a good thing generally and may be triggering OOM situations for pete doing CD reads
<mdz> apw, the system has been feeling memory-starved lately indeed
<mdz> I thought it was chromium
<apw> so you can set that to 0 i believe to free it up
<apw> see if it feels any better then
<mdz> apw, EINVAL
<apw> hrm
<mdz> apw, write 0 to tracing_enabled instead?
<apw> mdz one sec, just want to confirm how pete did it
<cnd3> apw, mdz: it is per-cpu, and it is preallocated
<apw> <cking_> sconklin, echo 1 >/sys/kernel/debug/tracing/buffer_size_kb and see if the bug goes away
<apw> mdz so apparently 1
<cnd3> apw, I think it won't matter
<mdz> before:
<cnd3> it will always set it to be at least 2 pages in size
<mdz> Mem:          2993       2425        568          0         13        380
<mdz> after:
<mdz> Mem:          2993       2003        990          0         16        411
<mdz> i.e. ~400MB freed
<apw> a fair chunk then
<sconklin> apw: already tried that and saw no change. But it was not exhibiting the problem when I did it, and the problem has not happened in the last few days. It typically takes 2-4 days of use before it gets into swapping
<apw> sconklin, sorry was repeating that for mdz not for you :)
<cnd3> mdz, looks like you got 422 MB back ;0
<cnd3> :)
<mdz> yep
<apw> 3.29*128 MB ... erm thats an odd number
<cnd3> mdz, how many processors do you have?
<cnd3> including HT
<mdz> apw, I'm logged into a desktop session with gwibber, chromium and openoffice.org running, so who knows what sort of other allocations were made during that time ;-)
<mdz> cnd3: Core 2 Duo T7500
<mdz> so 2 cores, both HT
<cnd3> ok, so linux sees 4
<apw> i wonder if you have to read the resst
<apw> cnd3, how do you find out whats in the buffer and dump it ?
<cnd3> cat /sys/kernel/debug/tracing/trace
<cnd3> you can use trace_pipe if you want to get rid of everything in it
<apw> mdz could you see if there is anything in there
<mdz> apw, empty
<cnd3> I gotta jump off for a bit
<cnd3> I'll be back after lunch
 * apw wanders out to see what the sun looks like
<cking_> it's shiny and bright apparently
<manjo> apw, I dragged you out to the balcony
<osmosis> if i look at the changelog for  linux-image-server ...all it says is  * Lucid ABI 23
<awe> pong
<JFo> manjo, I'm about to send out the CFT for firewire in a bit. Is the new stack enabled in the latest released kernel or do they need to pick it up from a PPA?
<manjo> JFo, all the changes should be now avaiable without any ppa
<JFo> ok, cool
<JFo> manjo, in Lucid and Maverick yes?
<manjo> JFo, we are only focusing on Maverick
<manjo> JFo, no lucid
<JFo> cool, thanks :)
<JFo> Firewire CFT sent to everybody
<manjo> JFo, also there were a few audio mailing list iirc 
<JFo> you only told me about the mythtv one
<JFo> so I sent to them and a ton of others
<abhi_nav> what is firewirestack?
<manjo> abhi_nav, https://ieee1394.wiki.kernel.org/
<abhi_nav> manjo, ok
<abhi_nav> manjo, can I ask you something ? you are free to talk?
<manjo> abhi_nav, sure
<abhi_nav> manjo, got email from bugsquag that firewire need to test. and on that wiki page it is writen that nothing to instal. i am on lucid. so how to test?
<manjo> abhi_nav, the call for testing went out for maverick
<manjo> not for lucid
<abhi_nav> manjo, so i need to have maverick installed?
<manjo> you can boot from a maveric usb stick 
<manjo> ie live image and test 
<manjo> abhi_nav, do you have a firewire port on your system ?
<abhi_nav> manjo, i dont know. i still dont knwo what firewire is. is it software or hardware. on the link give i cant find defition of firewire
<abhi_nav> :(
<manjo> abhi_nav, google is your friend :)
<osmosis> if i look at the changelog for  linux-image-server ...all it says is  * Lucid ABI 23   What does that mean?
<abhi_nav> manjo, I googled
<manjo> abhi_nav, http://computer.howstuffworks.com/firewire1.htm
<manjo> for example 
<abhi_nav> manjo, ok thanks I wll look at it
<manjo> drivers are need to make that device work in linux 
<manjo> and we just switched from the old drivers to new driver model
<manjo> modules
<manjo> we would like to make sure that there are no regressions etc and the new modules work just as well or better 
<abhi_nav> manjo, ok
<abhi_nav> manjo, i understool.
<abhi_nav> understood.
<abhi_nav> manjo, and also I come to know that I dont have it in my lappy. :)
<manjo> abhi_nav, thanks for trying 
<abhi_nav> manjo, yah
<JFo> abhi_nav, thanks for asking though :)
<JFo> we are thankful that you were willing to test :)
<abhi_nav> JFo, :)
<JFo> :D
<jjohansen> -> Lunch
<manjo> JFo, modified that wiki page 
<JFo> thanks manjo 
 * manjo heading out for Dr appt
#ubuntu-kernel 2010-07-09
<apw> yawn
<smb> Coffee!
<smb> Reminds me there is some in the Kitchen I forgot to bring with me
<RAOF> I *always* do that!
<smb> Must be some natures law... :)
<jk-> that's to tell you that you need a coffee :)
<cooloney> kengyu: around? my FISH man
<kengyu> cooloney, anything can I help, guess we move to hwe?
<kraut> moin
<apw> https://edge.launchpad.net/ubuntu/+source/linux
<lag> apw: https://edge.launchpad.net/ubuntu/lucid/+package/linux-image-2.6.32-22-generic
<apw> https://edge.launchpad.net/~ubuntu-security/+archive/ppa/+build/1770776/+files/linux-image-2.6.32-22-generic-pae_2.6.32-22.36_i386.deb
<pgraner> apw: http://pastebin.ubuntu.com/461105/
<lag> ubuntu-2.6$ addr2line -f -e debian/build/build-omap/vmlinux bf1baad0
<lag> ??
<lag> ??:0
<lag> apw --^
<Flek74> Hello Ubuntu-Developers!
<Flek74> I have a problem on my Ubuntu 10.04
<JFo> Flek74, is it kernel related and have you opened a bug?
<Flek74> I already opened an issue on launchpad
<JFo> ok, what is the bug number?
<Flek74> maybe it is kernel related, maybe not
<Flek74> ok it's bug 581847
<ubot2> Launchpad bug 581847 in linux (Ubuntu) "system crash after changing power supply (affects: 1) (heat: 69)" [Undecided,Incomplete] https://launchpad.net/bugs/581847
<Flek74> with my probook 6545b
<Flek74> I already tried to install the ubuntu mainline kernel
<Flek74> It's running, with the restriction, that W-LAN isn't working anymore because it's a Broadcom device
<Flek74> I know how to develop in C/C++, therefore I already tried to locate the bug.
<Flek74> But it is very difficult if you didn't do anything on the kernel so far.
<JFo> this looks like something in the power control area of the kernel perhaps.
<marco74> I also thought about this
<JFo> I've tagged it as such and will ask about it when manoj gets in to see what he thinks
<marco74> i already tried to compile some kernel.org-kernles
<marco74> thank you
<JFo> no problem
<JFo> did you try the mainline builds?
<marco74> 2.6.31, 2.6.32. 2.6.33
<marco74> also 2.6.34 from the website you meantioned
<JFo> any difference in behavior?
<marco74> yes
<marco74> 2.6.31 work, with problems in graphics and sound
<JFo> would you mind describing the difference and which kernel it was in on the bug?
<JFo> that way all who look at it can see what progression there is
<marco74> you mean on lauchpad?
<JFo> yes, please :)
<marco74> ok I'll do that
<JFo> thank you
<marco74> the tests with the kernel.org kernel result was that all 2.6.32 kernels do not work
<marco74> Therefore I also tried 2.6.31 and 2.6.32-rc*
<JFo> I suspect that may be due to missing ubuntu configs that are in the mainline builds
<marco74> I used make localmodconfig
<marco74> then i set the option with the SATA-Driver from module to an asterisk * that I was able to boot from it
<marco74> because the initrd option on make-kpkg doesn't work
<JFo> add that information to the bug as well please, that is good to know.
<jcrigby> apw: ping?
<apw> hi
<jcrigby> apw: I've been reading the AbstractedDebian wiki page and have some questions
<jcrigby> apw:I'm doing the packaging for the linaro kernel
<jcrigby> and one possibility would be to follow the directions for creating my own branch, but I really want my debian.linaro to track debian.master so copying seems like it will create more work in the long run
<bjf> pgraner, http://kernel.ubuntu.com/~bradf/table.html (still needs work and data specific to 'linux')
<tgardner> jcrigby, the point of the abstracted debian is that your debian.linaro branch should contain nothing more then configs, control.d flavour files, and ABIs
<tgardner> everything else should be in debian
<pgraner> bjf: looking good very interesting results
<jcrigby> tgardner:yes, I realize that
<tgardner> jcrigby, so, what is it in debian.master that you wish to track?
<jcrigby> tgardner:as I look at the branch history it seems like the debian.master changes as often as the actual content so it seems a shame to redo that for debian.linaro
<tgardner> jcrigby, mostly config changes I assume ?
<jcrigby> tgardner:I think my actual problem is having no experience with the actual release process
<jcrigby> tgarder:and the abi changes
<tgardner> jcrigby, there are likely a lot of changelog and ABI noise that don't really have any relevance to Linaro
<tgardner> the only stuff that might be relevant are config changes 
<jcrigby> tgarder:yes, so I will stop over thinking this and go ahead and make my branch and go from there
<tgardner> jcrigby, we'd be happy to review one you have something in place
<tgardner> once*
<jcrigby> tgardner:great, thanks
<smoser> hey all. I'm wondering what the suggested way of avoiding building a ramdisk would be.
<smoser> It appears that setting 'ramdisk = /bin/true' in kernel-img.conf will work.
<BenC> smoser: I'm pretty sure do_initrd = false in that same file will do it
<smoser> and, building on that, my guess is I can specify something that would wrap /usr/sbin/update-initramfs , not invoking it if the version based on some criteria.
<apw> jcrigby, ok am in a meeting now for a bit
<jcrigby> apw:tgardner stepped in and helped me
<jcrigby> no more questions for now
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - July-13 - 17:00 UTC
<smoser> BenC, no. it has no effect.  neither that, nor ramdisk is documented in man pages installed by kernel-package
<smoser> but going based on http://www.tin.org/bin/man.cgi?section=5&topic=kernel-img.conf
<BenC> smoser: interesting...the kernel postinst checks that do_initrd value but never uses it :-/
<BenC> sounds like a bug
<smoser> yeah. i think its just old.
<smoser> but that link, the documentation doesn't even suggest that this indicates whether or not a ramdiks will be built. but rather only about silencing a warning.
<BenC> smoser: do_initrd is supposed to do this
<smoser> well, even then, i'd like to do it based on criteria. and a global boolean wouldn't suffice.
<BenC> smoser: you can also do something like: 
<BenC> sudo dpkg-divert --local --divert /usr/sbin/update-initramfs.orig --add /usr/sbin/update-initramfs
<BenC> sudo ln -s /bin/true /usr/sbin/update-initramfs
<BenC> but that's pretty hard core
<smoser> with the update-initramfs wrapper, i can check kernel characteristics of the specific kernel
<maks_> we don't support !initramfs, as going down that road lots of things break
<smoser> maks_, thats not true.
<maks_> no UUID, fun with latest md
<maks_> smoser: you  know nothing.
<BenC> maks_: it should be supported on VM's and chroots
<smoser> well, i know that a.) no initrd does function b.) things that break it are considered bugs and are fixed c.) we have supported images without ramdisks.
<maks_> no Ubuntu has never supported that.
<maks_> it happened to work.
<BenC> maks_: regardless of ubuntu supporting it, he wants to do it, and that's his choice
<maks_> sure if he wants to shoot in his foot I won't give him a gun for that
<BenC> There's tons of reasons outside of your limited scope that could warrant disabling ramdisk generation
<smoser> as for "supported", it was a feature added to lucid EC2 and UEC images.  they ship without a ramdisk.
<BenC> maks_: then shut it, and let me talk to him
<jpds> Is there another around who can help me with an ACPI issue on a Toshiba laptop? (http://ubuntuforums.org/showthread.php?t=1473317)
<BenC> smoser: exactly...I use EC2 that doesn't have ramdisk support as well
<smoser> (well, it does have ramdisk support, but we chose not to use ramdisks there for both speed and maintainance reasons)
<maks_> lol
<maks_> BenC: good.
 * BenC is anti gun control
<BenC> let 'em all have guns
<warewolf> guns don't kill people, apes with guns kill people
<TeTeT> how do I get a current or past ABI file for my kernel to be compiled in a PPA? See http://launchpadlibrarian.net/51628419/buildlog_ubuntu-lucid-i386.linux_2.6.32-24.38~lvm0_FAILEDTOBUILD.txt.gz for details
<BenC> TeTeT: you should just always bump the ABI in a PPA build
<BenC> TeTeT: and maybe set the var that disables ABI checking
<TeTeT> BenC: how to do that?
<BenC> abi_check=false?
<smoser> BenC, well, it looks to me like the only functional way to do this is via 'ramdisk ='.  i went looking once before (possibly lucid time frame) and saw the 'do_initrd', and believe that then it still had no affect.
<BenC> Can't remember, but it's in debian/rules.d/0-* IIRC
<BenC> smoser: I'd file a bug...kernel-img.conf should either honor do_initrd or remove it from existence
<smoser> well, its not documented in the man page
<smoser> and ignored in the post install scripts
<smoser> so, other than a useless variable name in a post install script, its gone from existance.
<maks_> kernel-img.conf is disappearing
<maks_> it is a vestige from kernel-package times as you'd know BenC 
<smoser> maks_, would you care to share what it is being replaced with ?
<maks_> why would I as you know everything smoser 
<smoser> well, for others in the room of course.  maybe if I admit to my non-omnipotence
<jjohansen> apw: you doing the status meeting?
<apw> jjohansen, have already done kernel yes
<apw> jjohansen, though you could talk me through where we are with AA and EC2 plan wise
<smoser> seriously, i'm not intending to be rude, but would like to know what the best solution to this.
<jjohansen> apw: already :(
<BenC> smoser: sounds like a hack is in order since kernel-img.conf is broken and doesn't seem to have a plan to be fixed
<smoser> well, even if it were functioning properly, it wouldn't get me what i'm interested in.
<smoser> i'd like to disable ramdisk creation, and then consumption by grub, on a per-kernel basis.
<smoser> but ideally, i'd like to do so in a way that will continue to work in the future.
<jjohansen> apw: AA just pulling together patches and updates, I have some test kernels for Bug #599450, Bug #581525 that I am testing and will push out for verification, I also need to test the userside component for Bug #581525, basically I am trying to pull together my next submission today
<ubot2> Launchpad bug 599450 in linux (Ubuntu Maverick) (and 1 other project) "[apparmor] getattr handled incorrectly in 2.6.35-6.7 (affects: 3) (dups: 2) (heat: 457)" [High,New] https://launchpad.net/bugs/599450
<ubot2> Launchpad bug 581525 in apparmor (Ubuntu) "Lucid: system becomes unstable randomly, seems related with apparmor (affects: 4) (heat: 89)" [Undecided,New] https://launchpad.net/bugs/581525
<jjohansen> apw: EC2, I got a nive little email from amazon about pv-ops and hope to kick off a test build of a new pv-ops kernel this morning
<apw> jjohansen, sounds about what i wrote :)  excellent
<apw> hows the upstreaming looking?
<apw> any sign of it getting into security tree?
<jjohansen> apw: well I am hopeful
<jjohansen> it should be soon
<jjohansen> basically I am hoping before sprint, quick turn around next week if needed type of thing
<BenC> smoser: sounds like you will have to divert update-initramfs and replace it with a wrapper that checks your own config file...put that in a package, and you have something that works pretty well for your usage
<pgraner> jjohansen: sooner is better
<jjohansen> pgraner: ack
<kees> apw: did you get a chance to look at my i915 fix?  it's really trivial, but would let me actually boot a maverick kernel again...
<apw> sorry no that i recall
<tgardner> kees, you got some heat about the constant. did you ever reconcile that with upstream?
<kees> tgardner: upstream wants a perfect fix; but it _was_ a constant in all versions prior.
<kees> tgardner: this just unbreaks it without re-breaking the piece they fixed for other hardware
<tgardner> kees, well, you're so good at windmill tilting lately, why don't you have a go at them about it ?
<kees> tgardner: I have for weeks, they're just ignoring me.
<tgardner> kees, ok, I'll have a look at it.
<kees> tgardner: but as it stands, it's a regression, and the fix is insanely trivial.
<tgardner> kees, I agree, but wanted to make it did not in turn introduce a regression
<tgardner> make sure*
<kees> tgardner: right, understood.  if you look at the patch, it replaces two sets of constants (for G33 and non-G33) with autodetection magic.  the intent was to fix this for the non-G33 case, which is nice and all, but they _added_ autodetection for G33 that is not needed and is wrong.  So by making the G33 case static again, it fixes the regression they introduced without re-breaking the non-G33 case they fixed.
<kees> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f1befe71fa7a79ab733011b045639d8d809924ad
<kees> it was this:
<kees> int gtt_map_size = 256 * 1024;
<kees> if (IS_G33)
<kees>     gtt_map_size = 1024 * 1024; /* 1M on G33 */
<kees> now it's:
<kees> gtt_map_size = intel_i915_get_gtt_size();
<kees> and if you look in that new function, the G33 case is what's regressed.
<apw> kess, the only thing thats odd is you leave in the autodetect login
<kees> apw: I'm happy to remove it.
<kees> I just want to boot maverick again.  :P
<tgardner> kees, refresh my memory on where your patch is?
<tgardner> its on the k-t list, right?
<kees> yup
<kees> https://lists.ubuntu.com/archives/kernel-team/2010-July/011457.html
<tgardner> kees, well, that just slams the previous calculation of size. what is your gmch_ctrl for that device? It looks like there is a missing case.
<kees> tgardner: mine reports 2M, which is wrong because half is a shadow gtt.  upstream said, "yeah 1M is correct.  gee, we should find someone that knows the hardware better"
<kees> tgardner: see https://bugzilla.kernel.org/show_bug.cgi?id=16294
<ubot2> bugzilla.kernel.org bug 16294 in Video(DRI - Intel) "[Q35 bisected] hang at init of i915 driver" [High,New]
<tgardner> ah, I remember taht now.
<kees> tgardner, apw: here's a new patch that throws the entire auto-detect section out: https://lists.ubuntu.com/archives/kernel-team/2010-July/011575.html
<tgardner> kees, how old is this laptop? it must be approaching 3 years
<tgardner> I wonder if there is a way to quirk this on sub-vendor ID ?
<kees> tgardner: this is not my laptop; it's my all-Intel primary desktop.  A very common Q35 motherboard.
<kees> tgardner: my Dell laptop with the ATI issues I gave up on.
<kees> http://www.google.com/search?client=ubuntu&channel=fs&q=intel+q35
<tgardner> well, I thought the i810 was dead. little did I know...
<kees> it's not i810.  I wish it was -- then I'd have a built-in RNG.
<kees> tgardner: anyway, the issue isn't trying to do the calculation correctly (I'll leave that to upstream to figure out), it's to get rid of a regression.
<tgardner> kees, well, lemme study it. I might be able to do both.
<kees> tgardner: could you maybe study it after fixing the regression?  I can't test any maverick kernels without rebuilding them first.  :P
<kees> the gtt size for G33 has been 1M since the beginning of time.
<tgardner> I promise I'll either find a solution or implement your patch today. OK?
 * kees hugs tgardner
<kees> tgardner: thanks!  I've literally spent days tracking this down and trying to get it fixed.
<tgardner> apw, does ureadahead run on every boot cycle?
<apw> tgardner, yes only recording when the pack is missing
<apw> which is cleaned up by any updated to 'main' or somethign in dpkg
<tgardner> apw, I guess I'm not clear on if it even loads if the pack is not missing.
<apw> if the pack is missing then it runs in learn about the system mode and and uses ftrace
<apw> otherwise it just uses the pack to load things
<tgardner> apw, so it loads in either casem which means tracing gets enabled.
<apw> hrm, ok ... not so hot
 * bjf running an errand, biab
<tgardner> kees, you running amd64 I assume?
<kees> tgardner: yeah
<tgardner> kees, k, I'll have a test kernel in a bit. the dope that coded this used the wrong macros
<tgardner> I think.
<kees> tgardner: wrong macros?
<tgardner> I'll reply to the m-l with my patch.
<JFo> <-lunch
 * apw cracks a cold one ... its tooo hot to concentrate here
<tgardner> kees, tangerine.buildd:kern/maverick/kern-64/linux-image-2.6.35-7-generic_2.6.35-7.12_amd64.deb
<tgardner> server will be up soon
 * bjf is back
<cking> apw, you are making me drool
 * cking has things to attend to. Have a good weekend
 * gnarl makes final uploads while reaching half of his cold one
<tgardner-lunch> kees, tangerine.buildd:kern/maverick/kern-64/linux-image-2.6.35-7-server_2.6.35-7.12_amd64.deb
<jjohansen> -> Lunch
<mpoirier> git bisect start
<mpoirier> git bisect good v2.6.35-rc4
<mpoirier> git bisect bad v2.6.35-rc3
<tgardner> mpoirier, git log v2.6.35-rc3.. -- arch/arm/
<kees> tgardner: booting it now...
<kees> tgardner: \o/ it worked!  :)
<tgardner> kees, cool
<tgardner> kees, can I add your tested-by ?
 * jjohansen heads for a walk, back on in a bit
#ubuntu-kernel 2010-07-10
<osmosis> anyone know if this bug was fixed in the Lucid ABI 23 kernel that was pushed to lucid-updates?   https://bugs.launchpad.net/ubuntu/+bug/603799
<ubot2> Launchpad bug 603799 in ubuntu "BUG: soft lockup - CPU#1 stuck for 61s! [kdmflush:275] (affects: 1) (heat: 6)" [Undecided,New]
<osmosis> is there a Lucid ABI changelog somewhere??
<Michel> test
<osmosis> anyone know if this bug was fixed in the Lucid ABI 23 kernel that was pushed to lucid-updates?   https://bugs.launchpad.net/ubuntu/+bug/603799
<osmosis> is there a Lucid ABI changelog somewhere??
<ubot2> Launchpad bug 603799 in ubuntu "BUG: soft lockup - CPU#1 stuck for 61s! [kdmflush:275] (affects: 1) (heat: 6)" [Undecided,New]
<dupondje> seems like there are some issues with mmc in maverick ?
<dupondje> [  370.259834] mmc0: Got command interrupt 0x00030000 even though no command operation was in progress.
<dupondje> etc :s
<dupondje> [  305.110100] No NAND device found.
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/604122
<ubot2> Launchpad bug 604122 in linux (Ubuntu) "mmc0: Got command interrupt 0x00030000 even though no command operation was in progress. (affects: 1) (heat: 6)" [Undecided,New]
<dupondje> is there a (good) way to find the actual diff that causing the bug ? mainline works, current maverick kernel not
#ubuntu-kernel 2010-07-11
<devildante> hi
<devildante> I don't know if I'm on the correct channel, but can someone help me debug bug 604090?
<ubot2> Launchpad bug 604090 in linux (Ubuntu) "Packard Bell Easynote doesn't boot with Ubuntu 10.04 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/604090
<dupondje> somebody here that can give me hints on debugging https://bugs.launchpad.net/ubuntu/+source/linux/+bug/604122 ?
<ubot2> Launchpad bug 604122 in linux (Ubuntu) "mmc0: Got command interrupt 0x00030000 even though no command operation was in progress. (affects: 1) (heat: 6)" [Undecided,New]
#ubuntu-kernel 2011-07-04
 * apw looks out blearily on the world
<ppisati> apw: nothing see, you better going back :)
<smb> apw, Need some matches?
<apw> ppisati: heh a quiet day is always pleasant
<apw> smb: something stronger me thinks
<smb> apw, Hmmm, planks won't fit. Well at least noone from the other side of the pond will likely bug you today.
<apw> smb: heh no indeed.  just need to make sure we are ready for tommorrow, other than that we are quiet i am sure
 * smb thinks ppisati is a machine, though the numbering sometimes is confusing...
<ppisati> smb: i had all of them queued from dublin but since i dind
<ppisati> 't have smtp properly configured on my laptop, i waited since i got home
<smb> Heh, that explains a bit. Will try to have a look at them, though it seems the first half of the day has zipped past and its time for me to get my lunch
<ppisati> no prob
<Laibsch>  managed to break my initramfs (https://answers.launchpad.net/ubuntu/+source/initramfs-tools/+question/154973) for an encrypted lvm.  On reboot, I'm now being dropped to a busybox shell every time.  Is there somebody around who can help me fix this?
<Laibsch> ohsix recommended "update-initramfs -c -k all" yesterday but that actually made things worse.  initramfs file shrunk in size from 12 MB to 8.  I was still being dropped to busybox, but then even the cryptsetup would fail (something about missing support for some kind of aes256 encryption)
<ohsix> nice
<Laibsch> not really ;-)
<ohsix> do you have a distro kernel package installed?
<Laibsch> yes
<ohsix> then the modules should be in the ramfs
<Laibsch> http://paste.debian.net/121820/
<Laibsch> how can I verify what modules are needed and whether they are indeed in the initramfs?
<ohsix> by looking at the scripts that load them in /usr/share/initramfs-tools/
<ohsix> like the cryptsetup package puts stuff in /usr/share/initramfs-tools/conf-hooks.d/ for example
<ohsix> a verbose boot should say when modules are requested but not found for mounting root, if the script that does it is even included
<Laibsch> how can I get a verbose boot?
<Laibsch> http://paste.debian.net/121821/ is the file list of one of the initramfs (a working copy IIRC)
<ohsix> does it ask for a passphrase at boot, or did it before? /usr/share/initramfs-tools/hooks/cryptpassdev is probably important
<ohsix> honestly if none of the files are missing or broken in all the components that do it, i don't know how it could break
<ohsix> from that file list it looks like the aes stuff is in there
<Laibsch> that is the list of an initramfs that I think is working
<Laibsch> oh wait
<Laibsch> of course it's not working automatically
<Laibsch> but working with the workaround
<Laibsch> of manual entry at boot
<ohsix> i'd have to pretty much do what you'd have to do to figure out what's going on step by step, by looking at ehs cripts that generate stuff and run the boot
<Laibsch> http://paste.debian.net/121823/ is the filelist of one of the initramfs created yesterday that won't work even with "cryptsetup luksOpen /dev/sda1 sda1_crypt".  File size is actually 32MB vs 8 MB
<Laibsch> to answer your question.  When things were still working, I got prompted graphically for the passphrase at boot (very early on).
<ohsix> do you remember installing anything just before it broke? like watershed or something
<Laibsch> I'll have another look at what was installed and removed
<Laibsch> things did not break immediately or all at once
<Laibsch> but only after the respective initramfs were updated after the removal
 * apw idly wonders what release Laibsch is running
<Laibsch> lucid
<ohsix> yar 32 is a classic
<ohsix> well fwiw, and i've got to run anyways; theres nothing too insane installed that hooks initramfs here, and here's a listing from a working one http://paste.ubuntu.com/637870/
<ohsix> only thing out of the ordinary in there is some compcache stuff that is enabled but doesn't work in natty :] so the tools are there and idling
<apw> compcache should only trigger when you have <256M of ram ish
 * Laibsch has 2G RAM
<apw> Laibsch, i don't have any scrollback and so no context whatsoever of your problem
<Laibsch> apw: I managed to break my initramfs (https://answers.launchpad.net/ubuntu/+source/initramfs-tools/+question/154973) for an encrypted lvm.  On reboot, I'm now being dropped to a busybox shell every time.  Is there somebody around who can help me fix this?
<Laibsch> I have to enter "cryptsetup luksOpen /dev/sda1 sda1_crypt;vgchange -ay;exit" in that busybox shell to continue
<apw> Laibsch, do any of your older kernels boot ok ?
<apw> Laibsch, and does your initramfs contains an /conf/conf.d/cryptroot file ?
<apw> conf/conf.d
<apw> conf/conf.d/uswsusp
<apw> conf/conf.d/driver-policy
<apw> it seems likely it does not, which i suspect is wrong ...
<Laibsch> apw: I have a scripts/local-top/cryptroot file but otherwise only conf/conf.d/{uswsusp, driver-policy} as you can see in http://paste.debian.net/121821/ and http://paste.debian.net/121823/
<Laibsch> On the booted system, I have two cryptroot files (under /usr/share/initramfs-tools).  They both belong to cryptsetup package.
<apw> Laibsch, what directories are they in
<Laibsch> apw: http://paste.debian.net/121827/
<apw> Laibsch, so if you rebuild your current kernels initramfs update-initramfs -u -k `uname -r` ... the replacement does not contain /conf/conf.d/cryptroot
<apw> (if so then that implies we are not detecting your encrypted root when building it
 * apw waits for confirmation
<Laibsch> apw: it looks like that is the case.  the result of "sudo update-initramfs -u -k `uname -r` && cp /boot/initrd.img-2.6.32-31-generic /tmp/initrd.img-2.6.32-31-generic.gz -v && gunzip initrd.img-2.6.32-31-generic.gz && cpio -it -F initrd.img-2.6.32-31-generic" is http://paste.debian.net/121829/ and there is no such file.
<Laibsch> I also get a bunch of lines like http://paste.debian.net/121830/ in /var/log/syslog
 * Laibsch goes to google a bit
<apw> Laibsch, ok, so what is in your /etc/cryptab, that seems to be where it is looked up
<Laibsch> sda1_crypt UUID=6b7021eb-b178-449d-ac4c-40dd2592b778 none luks
<apw> Laibsch, and your /etc/fstab ?
<Laibsch> UUID="ecbd7524-29ea-47d6-b8aa-755c9677194c" /               ext4    errors=remount-ro 0       1
<Laibsch> different uuid
<apw> Laibsch, no information to know if that is right or not at this point, as one may be the crypted container and one the fs inside
<Laibsch> I'm trying to find out how to read the uuid value of a partition
<Laibsch> blkid?
<apw> Laibsch, right, i suspect that blkid on the raw will match one, and the crypt the other
<Laibsch> apw: http://paste.debian.net/121831/ there's the two uuid
<apw> Laibsch, you didn't flush any lvm tools off the machine as well did you ?
<apw> or indeed any dmraid tools
<apw> as the disk detector seems to use such tools to work out what your root is called underneath
<Laibsch> grep the aptitude logs for dm and lvm does not return anything
<Laibsch> lvm2 is installed as well as dmsetup.  dmraid is not
<apw> Laibsch, whats your shell scripting like?  the next step is to debug the script cryptroot-hook in your /usr/share/initramfs*
<Laibsch> you mean how strong is my shell foo?
<Laibsch> average
<apw> particularly the add_device function which is meant to be finding the disk
<Laibsch> low to average
<apw> you only really need to be adding like echo "blah" >>/tmp/LOG into it in place
<apw> places so we can work out why its not finding your root and making cryptroot config file
<apw> so checking that add_device is called and with what node opts lastopts etc
<apw> and later there is a loop, for node in $nodes
<apw> be nice to know what if any nodes it sees there
<Laibsch> brb
<Laibsch> will look through it in  
<Laibsch> a minute
<apw> Laibsch, np
<apw> Laibsch, and indeed in that loop there is a direct echo into the config file in question
<apw> so the if stanza before it is also interesting to see if it is causing us to loop
 * ppisati -> goes to hunt some food...
 * apw sees ppisati packing up his bow and arrow and daubing on camoflauge paint
 * Daviey After experiencing multiple kernel panics on his phone he has realised that he cannot remember the last time he had a kernel panic under Ubuntu.. how things have changed!
<apw> Daviey, i suspect you are just no longer able to see them :)
<Daviey> apw: hah.
<apw> Daviey, they are hidden by the lovely GPU hangs
 * Daviey spots apw whying away from a complement.
<Daviey> shying*
<apw> Daviey, who me, shy, seems unlikely :)  i suspect we have the advantage of using a kernel released this year
<Daviey> ah
<apw> then again with that you'd have a lot less holes to root your phone
<Daviey> heh
<Laibsch> apw: forgive me ignorancy, but what do I do with /usr/share/initramfs-tools/hooks/cryptroot? I had a look through it and understood only the general idea.  I tried calling it as "sudo sh /usr/share/initramfs-tools/hooks/cryptroot" but I guess that's not how it's done.  I assume line 391 is the key, but how do I find the infromation to understand what's wrong with the output?
<apw> Laibsch, that script is run when you are doing the update-initramfs -u <blah> stuff
<Laibsch> OK
<apw> Laibsch, so you can add debug which records information in a file in tmp
<apw> and then run the update to see what it says
<apw> Laibsch, remember to cp the file before so you can repair it
<Laibsch> "set -x" and "set -v"?
<CarlFK> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git; cd ...; fakeroot debian/rules clean; fakeroot debian/rules binary-headers binary-generic
<CarlFK> WARNING: drivers/built-in.o(.data+0x1bc38): Section mismatch in reference from the variable ab3550_driver to the function .init.text:ab3550_probe()
<CarlFK> would that be why the build to failed? 
<apw> Laibsch, if that doesn't affect behaviour then perhaps so ... remember to run this inside 'script' so we get all the output then
<apw> CarlFK, i'd be supprised if that warning caused a compile failure
<apw> CarlFK, what did the bottom of the build say
<CarlFK> tail of the build log: http://dpaste.de/Zh3L/
<Laibsch> apw: "run inside 'script'"?  what does that mean?
<apw> Laibsch, run 'script' that starts a new shell in which all output is recorded into file called typescript
<apw> run the update-initramfs ... inside there, then exit to get back to normal
<smb> Laibsch, apw You could also place "set -x" debug on and "set +x" debug off inside the script around blocks of interest
<apw> smb, yep much of the script is of interest sadly
<apw> CarlFK, the error is earlier, search backward for Error, note we are building in parallel so it can be a long way up
<CarlFK> apw: building in parallel - got it.
<CarlFK> gcc: error: /lib/modules/3.0-3-generic/build/include/linux/autoconf.h: No such file or directory
<Laibsch> apw, smb: I'm only marginally smarter after http://paste.debian.net/121843/.  But it seems that only /dev/mapper/1001P-root (mounted as /) is being taken into account.  The lvm itself at /dev/sda1 with uuid 6b7021eb-b178-449d-ac4c-40dd2592b778 is not.
<smb>  CarlFK Hm, are you building something out of tree?
 * Laibsch is off for some sleep
<smb> Sounds a bit like something erased parts of the headers. Maybe you can fix it by forcing a reinstall of the linux-headers package
<Laibsch> good night and thank you very much smb, ohsix and apw
<Laibsch> smb: I'll do that, thank you
<Laibsch> oh, I suppose that comment was not directed at me
<apw> smb, those are in the builds directory, so they sound like something missing from the prepare phase
<smb> Laibsch, No sorry
<apw> CarlFK, how are you triggering the build
<smb> apw, Thats what made me think of out of tree. Cause those usually head for /lib/modules/$(uname -r)/...
<apw> smb, right but the missing file is expected in a build directory, which implies its the early internal conf phase which was meant to make it, and has not
<smb> apw, hm build is also a soft link pointing to /usr/src in you libs
<CarlFK> apw: fakeroot debian/rules binary-headers binary-generic
<apw> smb, ok now its me who isn't reading the filename in full ...
<smb> apw, Though the call rather suggest normal kernel build from git tree
<apw> smb, but if its building that way it really should not be referencing anything outside the tree
<smb> Agreed
<CarlFK> apw: i think i see the problem...
<smb> Maybe its as simple as doing a fdr clean before to avoid any cruft interfering...
<CarlFK> btw: running oneiric, so brokeness isn't surprising  (just noticed that, thought it was natty)
<CarlFK> apt-get build-dep linux-meta; should that include linux-headers?
<CarlFK> I think i got it: building 3.0.3, but have linux-headers-3.0-2
<apw> CarlFK, you shouldn't need headers installed to build a kernel, it is the thing which makes them
<CarlFK> oh right. 
 * apw wonders if the binary-headers is missing a dependancy
<apw> does fdr binary-generic binary-headers work any better
<apw> failing that, could you use script to get the whole output of the build and pastebin it
<CarlFK> apw: what is fdr?
<smb> CarlFK, We have an alias for fakeroot debian/rules
<smb> (lazy to type)
<CarlFK> heh
<CarlFK> wc typescript;   2681   7377 124877 - what's a light pastebin?
<CarlFK> http://paste.ubuntu.com/637946/
<smb> Hrrm, why is it looking for 3.0 headers while you seem to be building 2.6.38...
<smb> CarlFK, Just to confirm, are you building in a Oneiric environment?
<CarlFK> smb: correct
<smb> Just wondering whether we accidentally broke something while fixing all the 3.0.0 -> 3.0 fallout...
<apw> smb, if we couldn't build an oneiric kernel in oneiric we couldn't upload kernels full stop
<apw> oh i wonder if this is that stupid rtl drivers
<apw> driver which uses uname -r
<apw> make[3]: *** [ubuntu/rtl8192se] Error 2
<apw> yeah its that STUPID STUPID STUPID rtl driver
<apw> so ... two things
<mjg59> Do you still need that one?
<mjg59> The rtlwifi driver seems to support most of the se varients now
<apw> mjg59, no i think in 3.0 kernels it has been stripped but it is still in the natty build he is doing
<mjg59> Ah, sorry, I see
<apw> and the makefiles for it use uname -r ... which is mad
<mjg59> Well at least it's not calling uname at runtime
<apw> mjg59, heh i suppose
<mjg59> Which I wouldn't put past them
<apw> CarlFK, there is a line which looks like this:
<apw> ifeq ($(shell uname -r|cut -d. -f1,2), 2.6)
<apw> in ubuntu/rtl*/Makefile ...
<apw> remove it and replace it with ifeq (1,1)
<apw> and life will stop hurting
<apw> i'll get that pulled back to natty ... BAH HATE HATE HATE
<apw> CarlFK, do you have a LP bug filed for this problem
<CarlFK> apw: no, guess I should?
<apw> CarlFK, just let me know your launchpad id and i'll sub you to the one i am making now
<CarlFK> carlfk
<apw> CarlFK, bug #805494
<ubot2> Launchpad bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,In progress] https://launchpad.net/bugs/805494
<apw> ubot2, !sru
<ubot2> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<apw> git checkout -b lp805494 origin/master-next
<apw> oh thanks paste buffer, thats SO helpful
<apw> perhaps you could contains my password for my bank account next time
<smb> apw, Are you starting to blog your git foo too? :-P
 * apw takes smb outside for an education session
 * smb tries to run faster
<apw> git checkout smb-face; git reset --hard HEAD^1
<smb> error: no such branch
<apw> and the pause was about the right length ... COME ON GIT
 * apw really needs to turn off atime updates ... or read every file at 6am every day
<vish> Hi, I'm trying to kernel bisect and while building, apart from the bisect, I change only the changelog with numbers ~bgo1234vish0 , ~bgo1234vish1  and so on.. but after booting into the newly build kernel when I check using $uname -a  , it only shows as ~bgo1234vish0 , the first version number while the package number is the right one...  is that OK or am I not building the right version? how do I fix that version number displayed in $uname -a ?
<apw> vish, the version number reported was the one in the source when it was built.  If you are changing debian.master/changelog then it only takes effect on the next fakeroot debian/rules clean
<vish> apw: so I should clean every time I build?
<apw> vish really yes
<vish> k..
<vish> apw: so, was I building the wrong version? and I should start bisect again?
<apw> vish i would say its hard to tell as you discovered, you may be able to tell from what it built as to whether it was valid or not
<apw> if it took close to a full build time, then likely it has the right contents, but its hard to be sure
<vish> hmm..
<vish> bah! need to start again :p
<apw> vish where you bisecting between ?
<vish> between .35 and .34
<apw> (wonder if you can use the mainline builds to narrow the search any)
<vish> the error started in .35, and still exists in Mainline current.. atleast till .39
<apw> vish have you tries the mainline 34-rc builds?
<vish> yea, tried in mainline versions too
<vish> https://bugzilla.kernel.org/show_bug.cgi?id=33912 Â« thats my bug..
<apw> vish, and doesn't that help eliminate some of the range
<ubot2> bugzilla.kernel.org bug 33912 in Video(DRI - non Intel) "[RV515] Kernel .35 onwards, Random X freezes while scrolling" [High,New]
<vish> i tried the most closest versions I could find.. and the issue being random doesnt help either :s
<apw> no i bet
<apw> you are in a world of pain and no mistake
<vish> apw: how do I reset the bisect ?
<vish> hmm, /me looks in --help and RTFM's :D
<apw> there is a way to abort it, a sub-command of bisect, you can also get out the log and it contains the incantions too
<apw> so you can run forward to when you were unhappy
<vish> k..
<CarlFK> apw: apparently i think you need more frustration today, cuz I went and dug up more instances of that bug, just for you: http://paste.ubuntu.com/637972/     find Makefile grep "shell.*2\.6"
<apw> CarlFK, most of those are either explicit against a specific version or just copes of the orignals
<apw> copies
<CarlFK> or maybe I did it because the build still broke and I want it fixed :)
<CarlFK> copies?
<apw> all the ones in debian are build output
<apw> the others are all explicit matches against a fully formed version number
<apw> and so are fine as they never have matched and never will whatever the version number is
<smb> copies was the correction of copes in the previous sentence (probably wondered about that)
<apw> right
<CarlFK> apw: what about line 5: ./ubuntu/rtl8192se/Makefile:ifeq ($(shell uname -r|cut -d. -f1,2), 2.6) 
<apw> CarlFK, what line is it on
<CarlFK> 7
 * smb wonders whether that was the makefile with many repeats of the same but ifndefed most of the time. So only one actually survived
<apw> CarlFK, thats the one which the patch changes
<CarlFK> hmm, yeah, but I fixed it... so something is bringing it back
<apw> that must be outside the build system
<CarlFK> oh, no... i fixed the copy
<CarlFK> my mistake
<Aquina> hello!
<Aquina> I asked the following question in #ubuntu-devel already: "Can someone point me to some config or thelike within the repo to get an impression on server and desktop kernel differences?"
<Aquina> Can you provide me with some information? I know there are differences but I'd like to see the comple flags and such in comparison.
<CarlFK> I think I can find that.. .give me a sec to dig
<apw> Aquina, that is all in the kernle git report
<apw> git repo even
<Daviey> Aquina: Just out of interest, what are you hoping to determine?
<CarlFK> can someone confirm this is the desktop config:
<CarlFK> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=blob;f=arch/x86/configs/x86_64_defconfig;h=ee01a9d5d4f0a7b8e3bd9f6e4f86fb28e7fe2b68;hb=HEAD
<CarlFK> I am not seeing where the server config lives.  which I think is the only difference between the desktop and sever kernels, right?  (same base and patches, different config) 
<apw> CarlFK, nope that is a default config
<apw> the easiest way it to checkout the kernel source and run fakeroot debian/rules genconfigs
<apw> and look in CONFIGS/*
<CarlFK> k - I'll stop spelunking.  Aquina, do that ^^^
<CarlFK> huzzah!  dpkg-deb: building package `linux-headers-2.6.38-10-generic
<apw> ppisati, about ?
<ppisati> apw: what?
<apw> ppisati, s'ok i've resolved what i needed to ask and am happy
<ppisati> ok :)
<ppisati> that was quick
<apw> ppisati, just to say -NNN3 is now -4243, it merged with that CVE
<ppisati> ah ok, saw that
<ppisati> i'll send-email again (perhaps just that patch now...)
<ogasawara> apw: thanks for uploading linux-meta
<apw> ogasawara, np, i thought you were off all week ...
<apw> ogasawara, i did have to push over it, as there was a change for versatile which was missing
<ogasawara> apw: yep, saw that.  thanks.
 * ogasawara goes back to being on vacation
<apw> ogasawara, good, have a nice time
 * ppisati -> gym
<Aquina> Daviey I'd like to verify that there is more diference between those Kernels than someone told me. I'd like to prove that person wrong.
<TREllis> Hi, I'm doing a kernel bisect in http://bugs.launchpad.net/bugs/805209 and on one of the iterations I'm left with a kernel that doesn't compile (but is unrelated to the bug), do I just mark that bisect as bad and carry on?
<ubot2> Ubuntu bug 805209 in linux "System locks up after upgrading to linux-image-2.6.32-32-generic-pae" [Undecided,New]
<TREllis> Aquina: reminds me of http://xkcd.com/386/
<Aquina> :-)
<Aquina> I know that. The most lovely one is the one with "angular miomentum".
<Aquina> http://xkcd.com/162/
<TREllis> anyone have an idea for above?
<apw> TREllis, nope, you normally just reset head to a nearby commit which can compile and test that
<apw> TREllis, and bisect will use the commit as it was at the time you say good/bad
<TREllis> apw: hmmm not sure how I'd do that
<apw> TREllis, normally the easiest is to strip a commit off the top and see if that one is better
<apw> TREllis, as in git reset --hard HEAD^
<apw> git bisect only cares about which ones you did test it doesn't care if its the one it suggests
<TREllis> ah ok
<apw> if its not possible to find one nearby you can do other things like try both good and bad and test both of the results; but you'd need to take a git bisect log before so you can reset the bisect
<TREllis> apw: ok thanks, added the log to the bug
<apw> TREllis, that log is a direct set of executable commands to get you back to the same place
<Sarvatt> i really miss having a large amount of mainline daily kernels available to make bisecting muuch easier by narrowing it down to a day first
<cking> is that not working?
<apw> Sarvatt, why do you not have them>
<apw> oh i suppose we clean them up now ... hmm as they are vast
<apw> Sarvatt, i guess the problem is that the -rcs are weekly
<Sarvatt> yeah thinking about it more it's always one huge merge that introduced the problem I run into and no more changes to that subsystem go in between rc's so I guess it isn't any different (it's always i915 i'm bisecting)
<TREllis> apw: woot! after 5 resets I'm back on something that'll compile
<lifeless> hi
<lifeless> if I wanted to experiment with some changes to dmraid on my natty box; whats the best way to get the source (apt-get source; bzr branch lp:ubuntu/linux; git ?)
<lifeless> I'd like to be building the kernel with the same options the deb I have uses, but probably not build all the different flavours; then eventually take my patch and offer it for inclusion
<herton> lifeless: I would say to use git, git clone git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
<lifeless> kk; whats the best way to build the kernel + initramfs to match the deb ?
<herton> lifeless, it depends, if you want only the generic kernel, "fdr binary-generic" should do it
<lifeless> yeah, the box is running -generic
<lifeless> thank you!
<herton> about changing options, you can use "fdr editconfigs" for example
<lifeless> I've not heard of fdr
<herton> or edit manually configs at debian.master/config, and run fdr updateconfigs
<lifeless> I guess its new (== in the last 7 years since I did regular kernel changes)
<herton> fdr == fakeroot debian/rules
<herton> just easier to alias it instead of typing entirely
<lifeless> doh, ok :)
#ubuntu-kernel 2011-07-05
<lifeless> nice, it uses all cpu's by default.
<lifeless> should I worry about things lik WARNING: drivers/char/ipmi/ipmi_si.o(.devinit.text+0xe12): Section mismatch in reference from the function init_module() to the function .exit.text:cleanup_ipmi_si()
<lifeless> The function __devinit init_module() references
<lifeless> a function __exit cleanup_ipmi_si().
<lifeless> This is often seen when error handling in the init function
<lifeless> ...
<lifeless> herton: hi, if you're still around -
<lifeless> II: Done
<lifeless> install -d /home/robertc/source/linux/ubuntu-natty/debian.master/abi/2.6.38-10.46/amd64
<lifeless> find /home/robertc/source/linux/ubuntu-natty/debian/build/build-generic/ -name \*.ko | \
<lifeless>                 sed -e 's/.*\/\([^\/]*\)\.ko/\1/' | sort > /home/robertc/source/linux/ubuntu-natty/debian.master/abi/2.6.38-10.46/amd64/generic.modules
<lifeless> II: Checking modules for generic...explicitly ignoring modules
<lifeless> dh_testdir
<lifeless> dh_testdir: cannot read debian/control: No such file or directory
<lifeless> that was from fakeroot debian/rules binary-generic
<herton> lifeless: ah, you must run fdr clean before building
<lifeless> ah well, at least this box can build it in 15 minutes :)
<lifeless> herton: /bin/bash: kernel-wedge: command not found
<lifeless> make: *** [debian/control] Error 127
<herton> lifeless: install the kernel-wedge package
<lifeless> herton: sure; why isn't it in the build-deps from linux-meta ?
<herton> lifeless: no reason that I know, file a bug for it
<herton> the fdr clean is just needed if you are building the first time or changed something in debian.master which affects debian dir
<herton> it just populates debian/* directory properly for the building
<lifeless> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/805737
<ubot2> Ubuntu bug 805737 in linux-meta "kernel-wedge not in build-dep for linux-meta" [Undecided,New]
<lifeless> and its off building again, 34MB/s writes... wheee
<lifeless> herton: now it wants makedumpfile :)
<lifeless> herton: I presume I keep following the bouncing ball ?
<herton> lifeless: hmm just report it on the same bug should be ok, one more dep to add
<lifeless> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/805737
<ubot2> Ubuntu bug 805737 in linux-meta "kernel-wedge not in build-dep for linux-meta" [Undecided,New]
<herton> lifeless: this errors are on ubuntu-natty tree? I see here kernel-wedge and makedump
<lifeless> herton: I did 'apt-get build-dep linux'
<lifeless> herton: and it installed neither of them
<lifeless> y$ uname -a
<lifeless> Linux lifelessdesktop 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
<lifeless> robertc@lifelessdesktop:~/source/linux/ubuntu-natty$ lsb_release -a
<lifeless> No LSB modules are available.
<lifeless> Distributor ID: Ubuntu
<lifeless> Description:    Ubuntu 11.04
<herton> debian.master/control.stub.in:Build-Depends: debhelper (>= 5), cpio, module-init-tools, kernel-wedge (>= 2.24ubuntu1), makedumpfile [amd64 i386], device-tree-compiler [powerpc], libelf-dev, binutils-dev, rsync, libdw-dev, dpkg (>= 1.16.0~ubuntu4)
<herton> so probably else is going on, may be related to the first build
<herton> *something else
<herton> hmm now I see, apt-get build-deb chooses linux-meta
<herton> *build-dep
<herton> lifeless: I don't know if the apt behaviour, not used to all the debian related packaging stuff, just put on the bug report this detail about the apt-get build-dep
<herton> *don't know about, damn how hard can it be typing properly...
<herton> "apt-get build-dep linux-source-2.6.38" gets things right here
<lifeless> herton: yeah
<herton> the thing is, linux-meta creates a linux package, while the source name of main package is linux too, so may be apt is looking at built packages, not source names of control file
<lifeless> yeah
<lifeless> so I realise this is just teething issues for a new person
<lifeless> I don't mind if yo uclose the bug won'tfix if its too hard to get a sensible glue-together of all the bits
<lifeless> but I suspect other folk will run into traps too
<herton> well I don't know enough to say if apt behaviour is ok, it seems to be if it doesn't look to source names, but only built package names. But the naming indeed induces to this confusion
<herton> lifeless: oh, I think you wanted "apt-get build-dep --only-source linux" in your case
<herton> apt is trying to be smart and does the wrong thing...
<lifeless> herton: ahha!
<lifeless> OTOH 500MB of deps. wtf?!
<herton> docbook-utils seems to be pulling all the bloat (texlive and friends)
<herton> I think if you're not going to build linux-doc, don't need to install that
<lifeless> cool
<lifeless> herton: any particular advice on maintaining the patch - can I just run it in a git branch and sort it out later ?
<herton> yes, you can keep in a branch and rebasing when needed
<lifeless> is there someway to do incremental builds with the fdr binary-generic approach ?
<RAOF> lifeless: It should do incremental builds already?
<lifeless> RAOF: I edited drivers/dm/dm-raid1.c
<lifeless> RAOF: and ran fdr binary-generic again
<lifeless> RAOF: and it did not recompile that file
<RAOF> Hm.
<lifeless> OTOH it builds crazy fast, so I can deal.
<lifeless> (it just finished)
<RAOF> Hm.  Is there a staging tree that things get copied to?  It's entirely possible; then you'd need to edit debian/builds/whateveritis/drivers/dm/dm-raid1.c
<lifeless> no
<lifeless> y$ find . -name "dm-raid1*"
<lifeless> ./drivers/md/dm-raid1.c
<lifeless> ./debian/build/build-generic/drivers/md/dm-raid1.o
<lifeless> its probably a stamp file of some sort
<RAOF> Oh, yeah.  That thing.
<apw> lifeless, to do an incremental build you need to remove the debian/stamps/ file with build in its name, then fdr binary-generic should just build the changed files and repackage
 * smb mornings
 * apw waves to smb
<lifeless> apw: thanks!
 * abogani waves all
<abogani> Anyone have tested Oneiric with closed video drivers? 
<apw> i have heard rumours, but nothing concrete
<apw> i would be supprised if they even compile
 * abogani is trying to know if thirdy-part modules still working with 3.0
<abogani> apw: Thanks anyway! :)
<apw> tseliot, ^^ any idea if prop drivers are working on oneiric ?
<tseliot> apw, abogani: nvidia and fglrx work fine
<tseliot> I had to patch fglrx though
<apw> tseliot, cool, and unexpected
<apw> tseliot, lock kernel ?
<tseliot> apw: yep
<apw> tseliot, did you make it its own private mutex ?
<tseliot> apw: yes, and it seems to work well
<apw> tseliot, nice
<tseliot> :)
<abogani> tseliot: Thank you very much!
<tseliot> np
<apw> tseliot, the design team owe you some beer me thinks
<tseliot> hehe
<seif> hey guys
<lifeless> success:
<lifeless> sda              88.60  1025.40   54.80   20.80   578.40  3812.00   116.15     1.10   15.79    5.80   42.12   4.50  34.00
<lifeless> sdb              45.40  1024.80   28.60   21.40   300.00  3876.00   167.04     1.41   31.32    3.99   67.85   3.56  17.80
<lifeless> sdc              52.80  1018.60   36.80   27.80   363.20  3382.40   115.96     1.02   14.43    8.75   21.94   5.33  34.40
<lifeless> sdd              37.20  1014.60   29.40   33.80   268.00  4194.40   141.22     0.78   14.15    2.93   23.91   1.84  11.60
<seif> hey guys
<lifeless> (load balanced dm-raid raid 1+0 config)
<lifeless> seif: hi
<seif> for some reason my volume buttons on the thinkpad dont work anymore on oneirick
<seif> hwoever i can capture their events being pressed in the keyboard configuration
<apw> seif, it is always best to just ask what you want to ask, as then the people who know things know whether to pay attention
<seif> but they dont really lower or raise the volume
<seif> is this a kernel issue
<apw> seif, which thinkpad model
<seif> or a de issue
<seif> x201
<apw> hmm, well if you can see the key presses in input-events somewhere and they are marked as volume up down events then its not the kernel
<apw> https://wiki.ubuntu.com/Hotkeys/Troubleshooting
<apw> seems to be the place for how to figure this out
<seif> yeah
<seif> apw, thanks
<lifeless> apw: how much overhead is a printk(KERN_DEBUG
<apw> lifeless, all depends on whether loglevel is high enough to emit it
<lifeless> apw: so nearly-free when loglevel is low ?
<apw> if its not then pretty low, though you still have a subroutine jump and an if
<apw> so it depends if those are large compared to your code or not
 * apw looks smugly at the open cve bugs which are now closed correctly against invalid releases
<lifeless> ok, well I think I'll leave them in my patch and the reviewer can tear em out if needed
<apw> lifeless, i guess they are still being recorded in the dmesg, and potentially in syslog as a result
<apw> just not polled out to the real console.  so it depends really on how much they produce
<lifeless> apw: presumably not if the level is disabled ?
<apw> are they just making dmesg lose meaning by their quantity
<apw> lifeless, i am pretty sure they are in dmesg now i think abou tit
<lifeless> I'll double check
<lifeless> apw: I've implemented a load balance routine for dm-raid1 - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361733
<ubot2> Ubuntu bug 361733 in linux "dmraid(fakeRAID) raid1 driver doesn't loadbalance reads" [Undecided,New]
<lifeless> apw: I have the printks in the mapping logic, which is called once per unmerged I/O
<lifeless> my first version caused no IO merging to go on
<lifeless> which is why I did a more complex version and started printking
<apw> i suspect they are going to be recorded, i also suspect you can confirm they are merged using blktrace
<lifeless> iostat shows merging happening :)
<lifeless> what I was doing in the first version was round-robin
<lifeless> on sequential IO this lead to a small read (e.g. 8 sectors) from target 1, then from target 2, then target 1
<apw> heh ouch and thats going to hurt indeed
<lifeless> it performed terribly :)
<lifeless> now I keep track of the last sector a read was dispatched to from the mirror set per target, and prefer the closest 
<lifeless> I get pretty good balancing doing the incremental kernel build on each reboot
<lifeless> and sequential IO is unaffected - 100M sustained comes from just one target
<lifeless> apw: patch attached FWIW; whats the normal process to get them looked at ?
<apw> well normally you'd be asked to send them to the driver maintainer, but if you want a review before then we can help
<apw> (unless its for an ubuntu only driver)
<lifeless> AIUI upstream fakeraid list is totally dead
<lifeless> this may have changed
<apw> someone must know who is owning it now, even if maintainers is out of date
<apw> and if its not it likely falls back to the io maintainer etc
<lifeless> ok
<lifeless> well, I'm happy to do a modicum
<lifeless> my primary itch scratching is now complete however
<lifeless> hmm, that came out wrong
<lifeless> what I mean is, if the upstream want lots of changes, I can't commit to doing that in a short term time frame
<apw> yep
<apw> well if you are unsure of quality and want some instant feedback you could send it to the ubuntu kernel-team list saying you are planning to upstream this and would people review it 
<ohsix> fakeraid or "ataraid" ?
<lifeless> ohsix: dm-raid1 specifically
<ohsix> since the userspace tools assemble them with plain dm methods
<lifeless> ohsix: which is 'fakeraid' for the folk that don't like it :)
<lifeless> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361733/+attachment/2192144/+files/raid1-loadbalance.patch
<ubot2> Ubuntu bug 361733 in linux "dmraid(fakeRAID) raid1 driver doesn't loadbalance reads" [Undecided,New]
<ohsix> i missed the rest of the chat, but the stuff still works
<lifeless> apw: whats the list address to send to?
<ohsix> you can do that with lvm and i don't see the utility in not just doing that, unless you want the volumes acessible on windows or something
<lifeless> ohsix: thats an entirely different discussion
<smb> lifeless, dm-devel@redhat.com might be a generic ujpstream for that. Not sure how much they do atm as the last thing I heard was them wanting to have dm-raid replace dm-raid45 and not much had happened
<lifeless> apw: mail sent; I'm sure it will go into moderation.
<lifeless> smb: looks like they are, yes.
<apw> herton, do you know how to produce the summary for the weekly meeting for stable ?
<herton> apw: nope
<apw> ok
<smb> one less topic on the meeting which is maybe ( not) happing
<apw> smb, interestingly i may have worked out how to make it
<apw> though hardy is missing
<apw> oh no, it is there, so perhaps
<smb> hm, if its only pending ones maybe there is just nothing there atm
<apw> i _think_ i have it generated, so i will document it very badly and let bjf et al fix it
<herton> apw: I was looking here, may be sru-report + generate-meeting-status ?
<apw> herton, i am suspicious that that is the incantation myself
<apw> herton, the output of the second one seems right ish
<smb> apw, herton http://reports.qa.ubuntu.com/reports/ogasawara/kt-meeting.txt may be the thing
<smb> though http://kernel.ubuntu.com/~kernel-ppa/reports/kt-meeting.html is the documented link
<apw> smb, good spot
<smb> apw, Was in the README in kteam-tools/irc-meeting
<apw> herton, perhaps you could update that README to include how to generate the stable update
<herton> apw: ok, will take a look here, also I have to write a status update I think
<herton> the "=== Status: Stable Kernel Team  ===" topic in the meeting
<apw> herton, well do what you can and don't sweat it if you don't know something
<apw> herton, the key thing is to know we don't know this time and then you can ask bjf/sconklin for next time
<herton> ok
<apw> ie. don't worry if you only have 'no update' for any section
<apw> it seems like we have the bug stats and the overall stats
<apw> smb, shall we decide we'll muddle the meeting and learn from the missing bits 
<apw> herton, so if all you have is the output that we've just found for the stable team thats fine, we'll live
<smb> apw, Its probably a oportunity to find out what we do not know
<apw> smb, if we go for the meeting can i let you paste in the bugs info 
<smb> apw, ok, sure
<apw> right i'll send out the late annoucnement it is still on
<apw> **
<apw> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<apw> **
<ogra_> rtg_, yo !
<tgardner> ogra_, yo
<ogra_> could we get an omap4 meta upload ? 
<apw> bouncy tgardner 
<ogra_> you uploaded a new image but no meta apparently
<tgardner> ogra_, for natty or oneiric ?
<ogra_> oneiric
<tgardner> ogasawara, ok, gimme a bit
<apw> ogra_, you should have mentioned it yesterday 
<ogra_> apw, i didnrt notice it yesterday
<ogra_> sorry for that, there was another build failure hiding it
<ppisati> it's still based on natty kernel, isn't it?
<ogra_> sure, still, the image builder uses the meta pacdkage to roll images
<ppisati> ok
<ogra_> that currently depends on an older version
<ogra_> so image builds fail
<tgardner> apw, there isn't a branch for ti-omap4 in ubuntu-oneiric-meta. have I just not had enough coffee yet ?
<apw> tgardner, that is very likely, my bad i suspect as it was me who updated oneiric ti-omap4
<tgardner> apw, maybe you can fix that ?
<apw> tgardner, sure 
<apw> ogra_, tgardner pushed and uploaded
<ogra_> awesome, thanks !
<tgardner> apw, thanks
<herton> apw, smb: I think this summarizes everything on the stable side for the meeting: http://pastebin.ubuntu.com/638415/
<apw> herton, that looks very good, are you good to paste that in for the team status and the table in for the 'Security and bugfix kernels' sections of the meeting
<herton> apw: yep, can do that
<smb> +1 (and /me is looking at the hardy srus right now)
<apw> awsome, sounds like we are covered then ...
<herton> apw: the statistics, I think you already got the same as this: http://pastebin.ubuntu.com/638418/
<herton> should I care about it or you will handle it?
<herton> *will you
<apw> herton, as i will be running things its easier to get you to shove that it in if thats ok, prevents me getting rate limited by floodbot
<herton> ok, will paste that as well then
<apw> herton, excellent thanks
 * apw lunches
<tgardner> oneiric unity seems to be ill this AM. lots of notifiers crashing
<herton> apw: when you're back, if you happy with this:  http://pastebin.ubuntu.com/638419/ then I send the patch to you to apply on kteam-tools (for the irc-meeting readme)
<tgardner> ogasawara, updating tangerine chroots with new binutils and gcc. 
<smb> tgardner, Are you talking to ogasawara or just suffer from nick-completion rot and want ogra_ ?
<tgardner> smb, no, I just forgot she was on vacation this week
<smb> ah :)
<apw> tgardner, heh
<apw> herton, looks like a good start indeed, zap it over
<bjf> apw, so you've decided to have the meeting?
<apw> bjf, yep, seems we have foudn the stable data we need so seemed fine to continue
<bjf> apw, i'm sending you my runes
<apw> bjf, we decided that we'd work out what was missing, find what we need, and leave anything we don't know out with an action to document how its gotten for next time
<apw> bjf, though i think we found everything in the end
<apw> bjf, thanks
<apw> bjf, i may have to leave pushing the output to the blog until you gtet back as when i login to WP it dies in a heap, #is is on the case but i am not hopeful
<herton> apw: ok
<bjf> apw, not a problem
<apw> but that i couldn't do it was highlighted by wanting to for this (well and the onieirc upload announcement)
<bjf> apw, when you logged in did you happen to end up and an "Array" page?
<bjf> apw, http://voices.canonical.com/kernelteam/Array  ?
<apw> bjf, no i get a whole different "Internal Server Error" explosion, which seems to be triggered by some script exploding at the other end
<bjf> apw, sweet!
<apw> had them rather dazed and confused at the other end, smb i think is also affected
<smb> Though I get a blank page (or got)
<apw> different fun for everyone, though no way to do anything here.  seemed that they could see it breaking at the server
<tgardner> apw, I think its time to extend the oneiric version to 3 digits prior to the next upload, and before the first beta.
<smb> apw, Oh today I seem to be at the 404 error too
<smb> apw, bah no. just mistyped the login page
<apw> tgardner, its likely the time to do it if one is going to i agree.  and i can't really think of a good reason not to, i do wonder if we should be using the full stable version when we get to having those
<apw> though we have an alpha-3 right ?
<tgardner> apw, can't remember if we have an A3
<tgardner> I'm just noticing what carnage oneiric is causing on older user spaces.
<apw> tgardner, yeah, can't fault the logic there, and i think debian already did it wrong and committed themselves to 3.0.0
<tgardner> apw, I expect the full stable version will be 3.0.1, 3.0.2, etc.
<apw> tgardner, right thats what he implied, i mean should we be 3.0.0-1 and then 3.0.1-2 when we have stable, or is that still 3.0.0-2
<tgardner> apw, I think we can wait to see what greg k-h does 'cause either case will work for us.
<apw> i mean in the case that greg does use 3.0.1 do we change our prefix to that or remain at 3.0.0 regardless
<apw> in the past we have not changed the prefix for stable, but that mattered not as we were not saying anything about the stable version number
<apw> but now we will be, we'll be implying its 0 if we don't bump our prefix
<apw> but it implies an abi bump when there may not be one
<tgardner> apw, I guess we should stick with 3.0.0 since we don't always adopt _all_ of the stable patch set.
<apw> tgardner, that at least may save some of the tools from death
<tgardner> apw, plus its more aligned with our usual version processing
<apw> tgardner, i cannot fault the logic of using 3.0.0 and i suspect even if we might want to use 3.0 its probabally better to switch for PP rather than oneiric
<tgardner> apw, hmm, whatever we do for oneiric is going to establish the precedent. I don't see us changing the version scheme for an LTS.
<tgardner> e.g., lets just adopt the 3 digit version scheme and be done with it.
<apw> tgardner, ok ... i'll put that together then shall i
<tgardner> apw, wfm
<herton> bjf: I sent apw some notes, I think apw can replace that with your notes then. Here is what I sent: http://pastebin.ubuntu.com/638415/
<Lekensteyn> Hi all, how do I debug a defunct Fn key? I've already tried https://wiki.ubuntu.com/Hotkeys/Troubleshooting but it seems that the kernel does not recognise the shortcut. I've a Clevo B7130 laptop
<bjf> herton, looks good to me, he should use yours
<herton> ok, I'll paste that in the meeting
<herton> the statistics we saw that sru-report + generate-meeting-status created them, irc-meeting/README has some notes about it now (kteam-tools)
<apw> it all sounds sorted, and bjf should go back to being on vacaction and let us fail :)
<apw> Lekensteyn, so you've confirmed its not producing any events under input-events and nothign in acpi ?
<Lekensteyn> @apw: I used `acpi_listen`, `xev` and `/lib/udev/keymap` and `udevadm monitor`, but none of them generates output from Fn+F8 or Fn+F9 (change brightness) Fn+F5 (change volume) works however
<apw> Lekensteyn, i think the one thing left to try is input-events, run that on each of the channels listed in ls-inputs and see if any producs anything for those keys
<apw> sometimes they are on the most illogical channel, like on the graphics card or somewhere stupid
<Lekensteyn> @apw: I tried all of them, (0-8), but none of them responded to the fn+f8/9 shortcut
<apw> Lekensteyn, then its a kernel driver thats needed to make them work probabally, though without someone who knows the h/w telling us how they work we are in the dark.
<apw> Lekensteyn, thats assuming they haven't worked in the past
<Lekensteyn> @apw: I'm willing to help getting it to work, what information do you need? Fn F[89] has never worked here
<Lekensteyn> Should I file a new bug report about it?
<apw> Lekensteyn, well thats the problem if they have never worked and nothing is obviously coming out of anywhere its very hard to know where we should be looking for an indication they have been pressed
<apw> Lekensteyn, sure, its not obvious if anyone can fix it who doesn't work for the manufacturer though
<Lekensteyn> @apw: would a keylogger described at http://www.phrack.com/issues.html?issue=59&id=14#article help to get the required information? If I contact the manufacturer, what should I ask from them?
<apw> Lekensteyn, its not obvious how that keylogger would help
<apw> Lekensteyn, how their hot keys are exposed
<apw> Lekensteyn, do any hotkeys work on this thing?
<Lekensteyn> Yes, the fn hotkeys for LCD/touchpad/screen/wifi/webcam/bluetooth toggle, volume adjustment, sleep and mute all work, it's just the brightness thing that is broken
<apw> Lekensteyn, then there is some hope, put all that in the bug, also try and find one of the working keys and report where that comes through
<smb> tgardner, Hm, contrary to my belief I do not seem to have any hardware with Intel e1000e other than 82574L in my place. Would you happen to have something on your side?
<tgardner> smb, not any more.
<smb> herton, all hardy srus are verified, though I left one in needed state to give the original reporters a chance
<herton> smb: nice, thanks
<tgardner> smb, I think the regression risk is likely pretty low.
<smb> tgardner, I would guess so as well as it directly comes from Intel as their supported driver.
<smb> plus LBM is opt-in / best-effort...
<tgardner> smb, applying...
<apw> **
<apw> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<apw> **
<apw> ** that is in approximatly 50 minutes
<apw> **
<Lekensteyn> @apw: I've reported the bug at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/806032
<ubot2> Ubuntu bug 806032 in linux "Fn + F[89] does not work for controlling brightness" [Undecided,New]
 * herton --> lunch, back in 30min
<smb> jjohansen, Hi just since there is another alpha coming up. Is there anything new in seccomp patch world?
<jjohansen> smb: its progressing but hasn't made it to a point that upstream has accepted it
<smb> jjohansen, Hm, though that sounds as if we could set the work-item at least to inprogress...
<jjohansen> smb: so we are watching it but its getting to the point that for natty we may do nothing
<jjohansen> smb: yeah
<smb> jjohansen, done. :)
<jjohansen> smb: thanks
<smb> apw, Actually, do you remember what we decided about using only links for some of the longer lists in the irc meeting?
<apw> i think we decided we didn't care if it was long people wanted to see something in it
<smb> Ok, just cannot remember. There past is somewhat hazy before last Saturday... 
<apw> ok i have managed to fix editmoin (with some help from james_w) and have pushed a fixed version here: http://people.canonical.com/~apw/misc/editmoin
<apw> you will still need to update your cookies as they have changed, and the names of those cookies are different from before and different for wiki.ubuntu.com and wiki.canonical.com
<apw> smb, ^^
<smb> apw, not sure I got any as I never had a successful login
<apw> smb, you can no longer login to the wiki ?
<smb> err forget it I confused it with voices
<smb> Not using editmoin though
<apw> ahh yes that heap is broken
<apw> oh then you don't care :)
<smb> only little. :)
<apw> ** team meeting starting over on #ubuntu-meeting
<smb> -2
<skaet> ogasawara, https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview has been restored.
<skaet> apw, ^
<apw> does anyone have the Ireport which is needed for irc2moin ??
<apw> in which case .... bjf gets to handle it
<cking> you'd think it would be documented somewhere..
<apw> cking, it is, it says run irc2moin, which dies in a heap as Ireport is missing
<apw> cking, fail ... i've punted the input data to him hopefully it'll get checked in
<cking> doh
 * cking crunches another several thousand LP bugs in fwts and watches his CPU catch fire
<apw> cking, that sounds like fun
<cking> apw, did you see my email today concerning the automagically generated output from all those bugs?
<apw> cking, which bugs ?
<cking> apw, the kernel related bugs in LP
<apw> i see something about BIOS bugs ?  that or something else ?
<cking> yep that one
<cking> ~7K of bugs analysed by fwts
<apw> it looks horriffic for some bios makers
<cking> a lot of it is stupid low-level mistakes
<apw> stupid mistakes makes stupid explosions
<cking> more like subtle weirdnesses
<cking> I think I can summarise: a lot of BIOS vendors produce crack
 * tgardner --> lunch
<jjohansen1> ->lunch
<cking> tgardner, ping
<tgardner> cking, dude
<cking> tgardner, I'm being a bit dense today, I cannot find the committed patches for bug 755066
<ubot2> Launchpad bug 755066 in oem-priority "Heavy I/O on Sandybridge systems with small memory footprints causes system hangs" [Critical,Fix committed] https://launchpad.net/bugs/755066
<cking> ..they are marked 'fix committed' by you - where are they in the repo?
<tgardner> cking, was that natty?
<cking> yep
<tgardner> cking, 2e5b4f6c66b664844dde76534dfc5078acab4e12 and a8ead4fb194c86fac770c706dcf5b8a8fd3b2939
 * cking double checks - thanks
<tgardner> cking, I searched for the BugLink number
<cking> that's a darn easy way of finding it. doh
 * cking forgot it's in master-next
<cking> double doh
<tgardner> cking, yep, those haven't been built for -proposed yet
<cking> I'm ahead of myself 
<sforshee> tgardner, will you accept nominations on bug 771758 ?
<ubot2> Launchpad bug 771758 in linux "acer-wmi prevents wifi (bcmwl/brcm80211) from working" [Medium,In progress] https://launchpad.net/bugs/771758
<tgardner> sforshee, done
<sforshee> thanks tgardner 
<cking> yawn
<apw> cking-afk: go home
<cking-afk> i am home
<apw> go further away from the keyboard
<cking-afk> ..and I was having so much fun too
<neuro_sys> it is not possible to read/write 0xa0000 by mmap'ing /dev/mem right?
<neuro_sys> unless it's CONFIG_STRICT_DEVMEM=n for kernel config?
<ohsix> yep
<neuro_sys> I just couldn't find what range of memory is exactly forbidden in /dev/mem.
<neuro_sys> other than my dmesg reporting: [100842.511642] Program cat tried to access /dev/mem between 100000->108000.
<ohsix> it's all of it but pci or something, been a while since i looked
<mjg59> neuro_sys: Depends on the architecture
<mjg59> On X86 you can read anything that is either the first 1MB or that isn't RAM
<neuro_sys> on x86, speaking of 0xa0000 for video ram.
<mjg59> neuro_sys: arch/x86/mm/init.c
<mjg59> devmem_is_allowed()
<mjg59> You have to be able to read/write video RAM there because X
<ohsix> yar the help text says it only allows access to memory mapped peripherals
<ohsix> mjg59: thanks
<ohsix> http://lxr.linux.no/linux+*/arch/x86/Kconfig.debug#L8
<neuro_sys> the part that says "If this option is switched on, the /dev/mem file only allows userspace access to PCI space and the BIOS code and data regions." makes me still wonder 0xa0000 is permitted.
<neuro_sys> apparently not, anyway.
<neuro_sys> because the option is yes here, and I still get segfault when trying to write there.
<neuro_sys> gotta siwtch it off. not worth recompiling the kernel though :P
<mjg59> That's mmap_min
<ohsix> that's not assigned to my video card here, i used to know the relationship with those legacy addresses D: it should be accessible as a bios area though
<mjg59> Put something smaller in /proc/sys/vm/mmap_min_addr
<ohsix> wasn't the 0xa address for a hercules addin card ;]
<ohsix> what are you trying to do anyways
<neuro_sys> it's the video ram for vga mode (mode 13h).
<neuro_sys> http://en.wikipedia.org/wiki/Mode_13h
<neuro_sys> :D
<neuro_sys> actually was playing around with libx86 
<neuro_sys> it switches to vga mode using bios interrupts, but you just can't write pixels to 0xa0000 
<ohsix> you've got an extra 0 too
<neuro_sys> umm, that I guess has to do with real mode segmentation? it's 0:a000 normally if I'm not mistaken.
<neuro_sys> hence the extra 0.
<ohsix> maybe with libx86, i dunno
<neuro_sys> yeah better check that as well
<ohsix> or you could ask mjg59
<ohsix> since http://www.codon.org.uk/~mjg59/libx86/
<neuro_sys> LOL
<neuro_sys> geez
<xiackok1> aahha mjg59 is online
<mjg59> Oh yeah sorry about libx86
<mjg59> That one's my fault
<mjg59> I really ought to fix it so it doesn't try to map the zero page
<mjg59> There's no reason for it to
<neuro_sys> :D heh it's okay, lol didn't know you were the author
<xiackok1> ahah its very nice
<mjg59> But if you just clear mmap_min_addr things should work for you for now
<xiackok1> ok its done
<xiackok1> but i didnt anything about
<xiackok1> mmap_min
<xiackok1> its just writes on 0xa0000
<xiackok1> its my mistake i just write wrong mem address
<neuro_sys> oh cool then
#ubuntu-kernel 2011-07-06
<neuro_sys> mjg59: when using this bios call, r.flags should contain the correct values? http://www.ctyme.com/intr/rb-1755.htm
<neuro_sys> with libx86.
<mjg59> neuro_sys: No
<mjg59> neuro_sys: libx86 is in no way guaranteed to actually let you make arbitrary BISO calls
<mjg59> The only things you should expect to work are graphics calls
<neuro_sys> does it emulate or something? Actually I need to have a look at vm86 first I guess.
<mjg59> The rest of the BIOS isn't hooked up at all
<neuro_sys> okay
<xiackok> ok there is kernel system calls
<lifeless> apw: I mailed the kernel list; I presume it went to moderation
<lifeless> apw: I also forgot to say that I'm not subscribed ... so I won't see replies
<smb> lifeless, I forwarded you my reply which only went to the list accidentally
<lifeless> smb: thanks!
<smb> lifeless, Actually a request based mapping might be more desirable than a merge function for bios. Cause for the latter you would have to find out the common max of all mirrors if I understood correctly. Which sounds much more complicated. While for rq mapping the elevators just should be able to merge.
<smb> After all multipath had the same problem there.
<lifeless> smb: common max?
<lifeless> smb: is request a larger unit of work ?
<smb> I mean the maximum size of a bio all the mirror paths/drives can handle. Yes, request is a set of bios
<smb> Normally for a request queue the elevators can merge bios into an existing request if it is adjacent. But for the bio based mapping there is no such thing
<lifeless> smb: I've replied; I appreciate the feedback; I guess I think further fiddling isn't likely to have much impact - the kernel is merging the bios on the targets post mapping
<lifeless> smb: hmm, they are definitely being merged
<lifeless> Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
<lifeless> sda            3854.60     0.80  270.00    5.40 16498.40    21.60   119.97     0.14    0.50    0.43    4.07   0.43  11.80
<lifeless> 3854 -> 270
<smb> Did you see that? Cause iirc going through the device-mapper bio mapping was past the queues and so no merging was done
<lifeless> dm-1              0.00     0.00 4124.60    6.20 16498.40    21.60     8.00     1.34    0.33    0.32    3.23   0.03  11.80
<lifeless> is the raid1 device
<lifeless> so it got 4K reads, which all got mapped, then 3.8K were merged into the other 270
<lifeless> bbiab, cooking dinner
<smb> Hm seems like. Yeah. 
<smb> At least dm does no queue here, so merging is not done before sending it down a path
<lifeless> smb: its pretty efficient on sequential IO:
<lifeless> sda           25616.80     0.00 1816.60    1.80 109734.40     6.40   120.70     1.06    0.59    0.57   17.78   0.41  74.20
<lifeless> dm-1              0.00     0.00 27368.00    1.80 109472.00     6.40     8.00    14.99    0.55    0.55   17.78   0.03  74.00
<lifeless> 100MB/sec out of the drive
<smb> Well yes, just thought in the past the bios would just get passed on behind a dm device. But it could have changed. Your sda is also only used for that raid, right?
<lifeless> dd from the drive gets:
<lifeless> 131072000 bytes (131 MB) copied, 1.07633 s, 122 MB/s
<lifeless> yeah, its a raid 1+0 ICH10R
<lifeless> so sda and sdb are raid1 together
<lifeless> sdc and sdd are raid1 together
<lifeless> and dm1 and dm3 are striped together into dm5
<lifeless> dm5 is what gets partitioned etc
<lifeless> so without the patch, sequential IO + interactive IO is a bit poor
<smb> Ok, so merging at least happens on the backing devices. Just not for the mirror target which then can pass bios to both sides without caring whether they are mergeable
<lifeless> with it deals better
<lifeless> smb: yeah, thats my observation
<smb> Isn't the current code doing no read balance at all?
<lifeless> correct
<smb> Ok, so I read the old one correctly. :)
<lifeless> which is why sequential IO + interactive IO is bad :)
<lifeless> because you die from seeks
<smb> Right, it works around not merging but misses the oportunity of using a second source
<lifeless> my patch avoids that some of the time - when the IO distance is reasonable
<lifeless> smb: I did try two sources for sequential IO
<lifeless> smb: if you get it wrong, its way worse ;)
<smb> I can believe that
<smb> Would basically break up the chance for merging
<lifeless> exactly
<lifeless> so I think the heuristic I'm add is valuable even if we add a merge method
<lifeless> or request handling
<lifeless> IMBW :)
<smb> Just my gut feeling is that, when asking upstream, they will point at how multipath went to request based mapping and that avoids the need for heuristics
<smb> In the simplest form (before having the rq_map) they just used the same path x times and then switched in a round-robin balancer
<smb> Was not bad but had exactly the same issue of being dumb about possible merges
<smb> lifeless, But that is my personal feeling. You certainly can get more accurate feedback from dm-devel. My knowledge there has become a bit rusty from not looking all the time
<lifeless> smb: ok, thats good to know
<lifeless> smb: I think I'll wait for them to say that; if multipath knew that writes had to go to all devices, we could just have multipath layered in the mix
<smb> lifeless, Yeah, though for multipath it is actually the other way. Writes do go to all devices as it is really only one. Just there are multiple way to reach. The problem there is more that on the other end there may be a stupid handler or transport is more efficient in bulk
<lifeless> right, I meant 'transmit on all paths
<lifeless> '
<lifeless> because raid1 is 'write to all read from one + a bitmap for region synchronisation'
<smb> Right, different use cases. For mpath transmit to all paths is futile or stupid so it is not intended for that. But there is one patch in the past which introduces the rq_map stuff in the past and it did not look too terrible. It might be a source to look at.
<smb> f40c67f0f7e2767f80f7cbcbc1ab86c4113c202e
<apw> ppisati: have you created bugs for the two new CVEs yet?  i would like to test some scripting on them if not
<apw> (ie. i want to make them)
<apw> but i don't trust launchpad to find them
<ppisati> apw: which one?
<ppisati> ah
<apw> 2011-1770
<ppisati> nope
<apw> and 2011-2484
<ppisati> nope
<apw> cool, i'll sort them out then thanks
<ppisati> din't notiche them (yet)
<apw> ppisati: has anyone pointed you at the new page with the open CVEs on it, the bug view: http://people.canonical.com/~kernel/reports/kernel-cves.html
<apw> this is the first proto-type of an incoming queue for us, once kees starts making the bugs
<smb> Yet another one... But I guess that one goes with the bugs and will get us rid of supertracker
<apw> smb, yeah its about getting rid of the tracker, and about the fack stupid launchpad searches do NOT work
<apw> ppisati, you must teach me how you find a CVE bug in launchpad.  even when i have just opened one and i know its number i cannot find it using traditional searches ... it makes NO sense
<apw> smb, can you find the bug for CVE-2011-1070 ?
<ubot2> apw: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1070)
<apw> bug #806375
<ubot2> Launchpad bug 806375 in linux-ti-omap4 "CVE-2011-1770" [Undecided,Invalid] https://launchpad.net/bugs/806375
<apw> that bug is New in linux but i cannot get a search on linux bugs to find it
<smb> hm
<apw> i am being told its "the hyphens"
<smb> So you are trying to search the number and they fail ... bah
<smb> how useful is that...
<smb> No don't know how to do it. Stripping of the CVE part and only using numbers gives you completely unrelated bugs
<aroth> hi, i found the following kernel bug: http://paste.ubuntu.com/638832/
<aroth> how should i proceed?
<bliss> that's a fairly short list of CVE bugs
<bliss> not complete, i suppose?
<bliss> i'd expect CVE-2011-2497 and CVE-2011-2213 to be unfixed so far
<ubot2> bliss: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2497)
<ubot2> bliss: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2213)
<bliss> very helpful ubot2, thanks :p
<apw> bliss, nope its likely incomplete currently
<bliss> i'll have to give you guys some more to work on ;-)
<bliss> can't have the ubuntu kernel team getting bored
<bliss> off to work, later
<neuro_sys> jeroen tel vs. piper fawn
 * apw wanders out for a bit, some fresh air is required
 * apw notes it is windy out
 * tgardner steps out for an appt. back in a couple hours
<brendand> bjf - is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/802554 really still being verified? i thought i saw an email from sconklin last week saying it could be tested?
<ubot2> Ubuntu bug 802554 in linux "linux: 2.6.32-33.69 -proposed tracker" [Medium,In progress]
<bjf> herton, ^
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - July-12 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<herton> brendand: yes, everything on lucid seems verified, I'll check and set it to fix released
<brendand> herton - thanks,
<bjf> apw, irc meeting scripts updated and pushed
<apw> bjf were we missing a bit ?
<bjf> apw, yup, fixed
<apw> other than the little hickup everything else went well, we found all the reports in the end and added to the README
<herton> brendand: done, you can assign yourself on the bug and start working etc.
<bjf> apw, all pages have been updated and email sent, i think it's a wrap
<apw> bjf, thanks for that
<bjf> np
<apw> everytime you are away we get closer to it working :)
<bjf> apw, as "punishment" for getting my upload rights, it looks like I now get to do "patch pilot", i've been assigned dates
<apw> bjf, indeed so :/
<apw> bjf, we ussually use that to review the incomng bugs in linux with patches
<bjf> apw, ack, that was my plan
<bjf> apw, i believe that is what we agreed to in dallas
<apw> bjf, indeed so, and its actually been pretty good at finding real patches to apply
<herton> bjf: do you know/remember if someone from kernel team must verify tracking bugs, or can we set verification -> fix released for bug 795153
<ubot2> Launchpad bug 795153 in linux-mvl-dove "linux-mvl-dove: 2.6.32-417.34 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/795153
<herton> I mean, verify *arm* tracking bugs
 * tgardner --> lunch
<cking> when tgardner goes to lunch it reminds me I should be finishing up for the day
<apw> bjf, could you remind me where the documentaiton on how to upload one of these puppies is?  i need the switch to make it use lucid
<bjf> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
<bjf> apw, ^ bottom of the page
#ubuntu-kernel 2011-07-07
 * apw yawns
 * smb waves to apw 
<apw> ppisati, are you doing the hardy port for https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/801473 ?  if not i'll look at it now
<ubot2> Ubuntu bug 801473 in linux-ti-omap4 "CVE-2011-2534" [Undecided,In progress]
<apw> ppisati, you also seem to be using the wrong tag for the cve-trackers,
<ppisati> apw: 2010-2534, go ahead
<ppisati> apw: what you mean ENOPATCH?
<apw> there is no patch to ack in the email
<apw> you sent just the diffstat information nothing else
<ppisati> apw: yes, it's there
<ppisati> tim ackaed and applied it even
<ppisati> it was in a subsequent msg in the same thread
<ppisati> btw, i'm doing 2010-4251 for every release now
<apw> ignore me then, must be a fookage in my email client
<apw> why arn't you using the create-cve-tracker script?  that would make sure the tagging was right
<ppisati> apw: to create the cve tracker bug? because i forgot of it's existance :)
<ronin___> Hi 
<ronin___> How can i get ubuntu-kernel and try to fix a bug?
<apw> ppisati, the tag should be kernel-cve-tracking-bug (stupid or not)
<apw> ronin___, https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2BAC8-FAQ.2BAC8-DevKernelSource.Where_can_I_find_the_Ubuntu_Kernel_source_code.3F
<ronin___> apw: thx
<apw> ppisati, there is now a script which closes out the tasks on those CVE bugs which don't make sense so you can just ignore them
<apw> ppisati, and save yourself 10s of minutes of clicking
<ppisati> apw: cool, i'll try it out now
<apw> ARRG everything is breaking in launchpad, everything i want to do just times out
<ppisati> ^^ sounds like a funny facebook status :)
<apw> heh i should put it on there shouldn't i
<ppisati> apw: i think it would be funny to have you on rotation in the launchpad team :)
<ppisati> apw: btw, how about the omap* kernels?
<ppisati> apw: did they go in in the end?
<apw> ppisati, for oneiric?  that was uploaded
<apw> ppisati, and seems to have built at least, no idea if it works of course
<apw> ppisati, i would kill myself on a rotation there i suspect
<apw> ubot2, help
<ubot2> apw: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
<ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<apw> https://bugs.launchpad.net/bugs/cve/2011-2484
<apw> ppisati, i am looking at CVE-2011-2484
<ubot2> apw: The add_del_listener function in kernel/taskstats.c in the Linux kernel 2.6.39.1 and earlier does not prevent multiple registrations of exit handlers, which allows local users to cause a denial of service (memory and CPU consumption), and bypass the OOM Killer, via a crafted application. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2484)
<ppisati> apw: still on 4251, feel free
 * ppisati -> out for lunch
<apw> ppisati, already done ...
<ppisati> apw: across all kernels?
<apw> ppisati, yep, all 7 branches which need patching
<ppisati> cool
<apw> its a simple cherry-pick for most releases
<apw> last build just finished so looking good
<ppisati> nice
<ppisati> leaving...
<herton> smb: bug 794420 is stuck in verification for some time, do you think it needs a respin against 2.6.32-33.69 or can we set verification to fix released on that?
<ubot2> Launchpad bug 794420 in kernel-sru-workflow/verification-testing "linux-ec2: 2.6.32-317.34 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/794420
<smb> herton, May that be the wrong bug? looks like the tracker
<herton> smb: yep, that's the question, ok to set verification to fix released on it? this ec2 release is based on 33.66 though, before the lucid respins, does ec2 is affected by the lucid regressions, or can we continue and release it?
<smb> herton, Let me make sure of it. But I thought the master regressions were in an area not important for ec2
<smb> herton, Oh, hm the af_unix revert could in theory have an effect. So probably I should respin for that. The firmware problem would have been no problem
<smb> If that boots, I think it would be ok to release it together with master even without waiting a week
<herton> smb: hmm ok, feel free to respin and set that tracking bug duplicate of a new one, I just noticed that the current one is waiting for some time
<smb> herton, I probably should have respun when you did the master. But I somehow missed any notification that it is done and I should go (if there was one)
<herton> smb: hmm yep, may be we could invalidate the ec2 bugs when a new master is respinned
<herton> or just tell you to check if needs a respin again
<herton> s/again/too
<smb> herton, As long as that makes me see it (eg bugmail) ;) Yeah, something that assumes I am not necessarily paying attention
 * smb -> biab
<ppisati> apw: can you create the tracker bug for CVE-2010-4251? thanks
<ubot2> ppisati: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.34 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service (memory consumption) by sending a large amount of network traffic, as demonstrated by netperf UDP tests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4251)
 * smb <- back
 * apw slopes off for the afternoon, planning on checking in later
<ppisati> k
 * smb tries new magic...
<smb> !kernel-source
<ubot2> You can access all the kernels for previous and current development releases at http://kernel.ubuntu.com/git. There are repositories for each supported release under ubuntu/ubuntu-<release>.git - For more details see: https://wiki.ubuntu.com/Kernel/SourceCode
<smb> works. :)
<sforshee> smb, were you planning to ack my i915 patches for lucid or just let them filter in via your .32+drm33 tree ?
<sforshee> my only concern about the latter is that I'd like to get them in the next proposed kernel, if possible
<smb> sforshee, Planned to do the latter. So I sent them out last week which I could turn into a release end of this week. We could pick them up then. Would that be sufficiently early?
<sforshee> smb, I suppose it depends on where that ends up in relation to the SRU cycle
<smb> sforshee, herton may know more but assuming that Steve is away the next cycle gets probably prepared next week earliest
<sforshee> smb, if that's the case then we should be in good shape
<tgardner> smb, I believe sconklin is back today (according to the calendar)
<smb> tgardner, hm right.
<smb> Though calendar says verification phase this week. But I am not sure whether this is accurate
<smb> herton, ^ Do you know more?
<herton> if current lucid ends this week in sru cycle (bug 802554), likely a new proposed will be next week
<ubot2> Launchpad bug 802554 in linux "linux: 2.6.32-33.69 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/802554
<herton> smb: hmm nope, in fact I think the calendar doesn't reflect current state of things
<herton> because of the several respins it got out of sync
<smb> Ok, though proposed packaged up next week would be ok
<smb> I can apply the changes tomorrow (or tgardner does after the announcement)
<tgardner> smb, have you had _any_ response from the DRM dudes?
<sforshee> smb, great, thanks
<smb> tgardner, No, though in that case I work like stable
<smb> iow, no complain. must be ok
<tgardner> smb, or they are just ignoring you
<smb> tgardner, Yeah, as some even do with Greg
<smb> But we tested at least the part coming from sforshee 
<smb> And I had the same issue which was gone with the changes
<tgardner> smb, I guess my point is that we're gonna have to do some extra special testing since cert and Q/A don't cover graphics very well.
<smb> tgardner, Indeed.
<smb> May be a point to add in next weeks irc meeting
<lag> Where is the delta review?
<lag> I found this: https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview
<lag> ... but I don't see my name
<lag> Wait, ignore me - I was searching for lag, but you've used my real name
<smb> https://blueprints.launchpad.net/ubuntu/+spec/other-kernel-o-ubuntu-delta-review
<lag> smb: Thanks! :)
<smb> lag, Yore welcome. That one even uses lag. :)
<lag> smb: It does and I saw that one, but it doesn't tell me which patches
<lag> smb: The first one is the one I was looking for, but I was searching for the wrong name :)
<cking> anyone recommend a USB based wifi stick?
<sconklin> cking: although I haven't used it since Lucid, I have a D-Link WUA-1340 that has worked well for me
<sconklin> it's b/g, not N
<cking> that's fine with me
<cking> sconklin, are you able to verify it works with more recent kernels?
<sconklin> cking: I will, but not this minute
<cking> sure, no rush, just curious before I splash out on one
<sconklin> wow, ubuntu forums are utter crap on this device
<herton> manjo: about?
<manjo> yes
<herton> manjo: can you verify bug 790754 on maverick?
<ubot2> Launchpad bug 790754 in linux "[NATTY] RICOH [1180:e823] unable to read MMC cards" [Undecided,Fix committed] https://launchpad.net/bugs/790754
<herton> (the kernel in -proposed)
<manjo> herton, I don't have the HW, but I can ping someone who has it and will get it verified.
<herton> manjo: ok, please do it, otherwise that will get reverted on maverick
<manjo> herton, I have time till fri ? 
<herton> yes
<manjo> herton, you are cced on the request to Alex/James who have the HW 
<smb> herton, sconklin I just pushed and uploaded (ckt ppa) a rebased lucid-ec2 kernel. It is boot tested and only differs from the previous upload by importing the revert of that af_unix patch.
<sconklin> smb: ack, did you give it a tracking bug?
<smb> https://bugs.launchpad.net/kernel-sru-workflow/prepare-package/+bug/806968
<ubot2> Ubuntu bug 806968 in linux-ec2 "linux-ec2: 2.6.32-317.35 -proposed tracker" [Medium,In progress]
<technikfreak> hello guys i have kernel rpoblems http://pastebin.com/qT5q30m4
<technikfreak> how i coudl get to the 3.xxx kernel?
 * tgardner --> lunch
<apw> tgardner: i see you applied -2484, but i don't see it on lucid/fsl-imx51, did you push?
<tgardner> apw, checking
<tgardner> apw, doh! pushed now
<apw> tgardner: its so easy to do with 7 branches to apply
<tgardner> apw, I was trying to be methodical, but I must have gotten distracted.
<apw> tgardner: is one of the best parts of having the matrix built from reality, not what we think we did, it spots our errors
<tgardner> apw, absolutely
 * tgardner --> EOD
<manjo> herton, https://bugs.launchpad.net/linux/+bug/790754 added verification comments 
<ubot2> Ubuntu bug 790754 in linux "[NATTY] RICOH [1180:e823] unable to read MMC cards" [Undecided,Fix committed]
<manjo> herton, I got a Transcend MMC 2gb card to test with
<herton> manjo: ok thanks
#ubuntu-kernel 2011-07-08
 * smb --> BOD
<cking> BOD?
<smb> cking, Beginning Of Day
<cking> ah
 * apw notes cking is so last year
<cking> why?
<cking> 'cos I don't comprehend an arbitary TLA
<apw> not knowing BOD ... i bet you can't understand your kids either :)
<smb> apw is quite harsh this morning. :)
<apw> smb, its my job
<cking> ignorance is not an excuse I see
<apw> cking, there are no excuses
<cking> shame
<apw> smb, http://people.canonical.com/~apw/CVE-2011-1090-hardy/
<ubot2> apw: The __nfs4_proc_set_acl function in fs/nfs/nfs4proc.c in the Linux kernel before 2.6.38 stores NFSv4 ACL data in memory that is allocated by kmalloc but not properly freed, which allows local users to cause a denial of service (panic) via a crafted attempt to set an ACL. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1090)
<apw> !kernel-src
<ubot2> Factoid 'kernel-src' not found
<apw> !kernel-source
<ubot2> You can access all the kernels for previous and current development releases at http://kernel.ubuntu.com/git. There are repositories for each supported release under ubuntu/ubuntu-<release>.git - For more details see: https://wiki.ubuntu.com/Kernel/SourceCode
<apw> !faq
<ubot2> A list of common questions and answers about Ubuntu: http://help.ubuntu.com/community/CommonQuestions - Official documentation: http://help.ubuntu.com
<smb> !kernel-faq
<ubot2> Factoid 'kernel-faq' not found
<apw> !kernel-faq is A list of common questions about the Ubuntu Kernel: http://wiki.ubuntu.com/Kernel/FAQ
<apw> !kernel-mainline is Information and binaries of the upstream mainline kernels are found here: https://wiki.ubuntu.com/Kernel/MainlineBuilds
<ubot2> apw: Error: I am only a bot, please don't think I'm intelligent :)
<apw> !kernel-mainline
<ubot2> Factoid 'kernel-mainline' not found
 * apw tires of ubot2
<smb> !kernel-mainline is <reply> Information and binaries of the upstream mainline kernels are found here: https://wiki.ubuntu.com/Kernel/MainlineBuilds
<ubot2> smb: Error: I am only a bot, please don't think I'm intelligent :)
<smb> hm, does not like that either...
<apw> no odd indeed
<apw> !kernel-mainline
<ubot2> Factoid 'kernel-mainline' not found
<smb> !kernel-faq
<ubot2> Factoid 'kernel-faq' not found
<apw> !kernel-faq
<ubot2> Factoid 'kernel-faq' not found
<apw> hmmm
<apw> !kernel-faq
<ubot2> Factoid 'kernel-faq' not found
<hemin>  Hi, I compiled my kernel from the source code.. after make, make_modules and make install and update_grub, I rebooted.. Now when I choose the new entry from the list, It gives me this error "Kernel panic- not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" .. any suggestions ??
<smb> Doing the install that way you likely missed to build an initrd. If "the source code" is our git repos, you should better follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel which gives you .deb packages that will do that all when you install
<hemin> I downloaded from kernel.org, 2.6.38.8 .. how do I know if I have missed to build initrd?
<smb> You have no initrd.img-... with that version in /boot. Btw, if that is a vanilla 2.6.38.8 build, did you know those are already built?
<smb> !kernel-mainline
<ubot2> The kernel team supply continuous mainline kernel builds which can be useful for tracking down issues or testing recent changes in the Linux kernel. More information is available at https://wiki.ubuntu.com/Kernel/MainlineBuilds
<apw> !kernel-faq
<ubot2> A list of common questions about the Ubuntu Kernel can be found in http://wiki.ubuntu.com/Kernel/FAQ
<apw> nice
<cking> !kernel-oops
<ubot2> Factoid 'kernel-oops' not found
<cking> !kernel-dev
<ubot2> Factoid 'kernel-dev' not found
<cking> yawn
<smb> cking, she does not like you. :)
<hemin> smb: I tried to compile the same version installed on my machine through source which is 2.6.38.8 .. does it cause any problem?
<smb> hemin, Apparently it does. But seriously, it would just save you the compile time and some of the worries when using the mainline builds. As your build now there are a few special drivers/modules missing but usually that does not cause problems. And installation is much simpler when using a .deb
<hemin> smb, ok.. My motive to compile through sourcecode was to learn rather than just installing it
<hemin> smb, i would try the .deb package too
<smb> hemin, Then I would actually start with the build your own kernel link. Which uses the exact same sources as are used for the releases (and have the ./debian infrastructure). And when being familiar with that look at mainline kernels as a secondary step
<hemin> smb, ok.. would go through that document and try out
<hemin> smb, I would like to remove the kernel I installed from the source.. how to do that safely as my current working kernel and the installed one has the same version?
<smb> hemin, While they are based on the same version, they should have slightly different names. You probably have a vmlinuz-2.6.38 and a vmlinuz-2.6.38-x-generic or so in /boot and likewise a directory with -gerneric (or whatever flavour you got) in /lib/modules
<smb> But as you installed them without a package the way to remove them is to remove the file / directory in /lib/modules and then run update-grub to clean up your grub menu
<smb> Note those files with -generic in them are the original ones and you should _not_ remove them
<hemin> smb, yes.. vmlinuz-2.6.38.8, vmlinuz-2.6.38.8-generic both are there.. ok.. so the generic ones are not to be touched
<ppisati> apw: when you want, can you open an lp tracker for CVE-2010-4251? thanks
<ubot2> ppisati: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.34 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service (memory consumption) by sending a large amount of network traffic, as demonstrated by netperf UDP tests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4251)
<bliss> hmm, haven't noticed that one
<apw> ppisati, should be done: bug #807462
<ubot2> Launchpad bug 807462 in linux-ti-omap4 "CVE-2010-4251" [Undecided,Invalid] https://launchpad.net/bugs/807462
<ppisati> cool, 10
<ppisati> x
<tgardner> apw, are you happy with 3.0.0-4.5 in kernel-ppa ?
<smb> herton, sconklin It looks like I need to do yet another respin of lucid-ec2. This time it even needs an aditional revert for ec2 (as I had made changes to follow the reverted patch)
<herton> smb: hmm ok, just invalidate the current tracking bug. In fact we should be doing the rebases now, you can just have the branch ready and we do the packages
<smb> herton, ok. I will be pinging you when I have pushed the tree. Want to get it test built before
<herton> ok
<euroford> è¿http://lists.debian.org/é½è¢«å¢äºï¼
<euroford> http://lists.debian.org/
<smb> herton, new lucid-ec2 branch pushed out. proceed at your leisure
<herton> smb: ok
<herton> smb: the repo misses the tag for 2.6.32-317.35, the previous release, not sure this matters much
<smb> herton, I did put it. Maybe you need to try git fetch --tags?
<smb> push I mean
<herton> smb: yes, --tags brought it. I found strange as I had here the 317.36 tag but not the .35...
 * smb thinks it may happen when the tag in question is not part of any named branch anymore...
<brendand> sconklin - what's up with lucid SRU?
<brendand> sconklin - 33.69 not getting released?
<ricotz> sconklin, hello :), i saw a lot of ubuntu kernel updates lately, but is there a reason that the natty kernel is still base on 2.6.38.7 instead of 2.6.38.8?
<apw> ricotz, its pending the current round of updates making it through testing and out
<smb> and lucid seems to have found one more regression
<herton> brendand: sorry, we had to resping lucid again because of another regression
<smb> so -33.70 got mode
<smb> made
<apw> herton, yep smb is correct, only things on the linear history are downloaded without --tags
<brendand> skaet mentioned another fix going in?
<apw> herton, what the hec was this one
<brendand> and this is the one that will be used in 10.04.3?
<herton> brendand: yep, steve talket to her
<herton> *talked
<herton> apw: let me see here the bug number
<ricotz> apw, i see, it has been quite some time and the last update missed it by one day ;)
<ppisati> do i need to put BugLink and "commit upstream" even on commits upon which other CVE commits depend?
<herton> apw: bug 805209
<ubot2> Launchpad bug 805209 in linux "System locks up after upgrading to linux-image-2.6.32-32-generic-pae" [Undecided,New] https://launchpad.net/bugs/805209
<herton> brendand: correct, this one should end in .3 point release from what I got
<apw> ppisati, all upstream commits should be recorded if they are pulled in in case we ever care to know where they came from
<brendand> ok, good to know
<apw> ppisati, and anything we commit for a specific fix should mention the bug number 
<apw> so i think thats yes and yes
<herton> brendand: so just watch the 33.70 tracking bug when you got the task to confirmed
<ppisati> ok
<brendand> herton - certainly
<kees> I'm nervous about the fix for 791019 -- this ends up mixing spinlock_bh() with spinlock(). I don't think this is safe...
<tgardner> kees, for natty ?
<kees> tgardner: oneiric
<kees> I don't know if mixing _bh with non-_bh is safe
<tgardner> kees, its not. what did we miss?
<kees> let me look, I haven't seen the commit yet. fetching it now
<tgardner> kees, looks like all uses of ptracer_relations_lock use _bh lock/unlock functions
<kees> tgardner: ah, so they all got replaced? is that sensible? i.e. it's only to use _bh everywhere?
<tgardner> kees, yes, its quite sensible.
<kees> okay, cool. reading commit now
<tgardner> kees, if any of the list manipulation functions can be called from soft IRQ context, then you must use _bh functions for protection.
<kees> tgardner: right, that's cool. I wasn't sure if it was okay to use _bh in non-soft-IRQ context.
<tgardner> kees, well, in fact you have to in order to prevent a soft IRQ context from getting control. Thats the whole point.
 * kees nods
<ppisati> besides rolling an image and testing it with qemu, is there any quick way to test a lucid amd64 kernel?
<ppisati> or if anyone wants to try it...
<ppisati> i just need a "it boots!"
<bjf> ppisati, there are a few of us that are running lucid 64, put the kernel up somewhere and we will boot test it for you
<ppisati> bjf: i'm almosto done rolling my image
<sconklin> manjo: https://bugs.launchpad.net/linux/+bug/790754 is going to be reverted
<ubot2> Ubuntu bug 790754 in linux "[NATTY] RICOH [1180:e823] unable to read MMC cards" [Undecided,Confirmed]
<manjo> sconklin, agreed ...
<manjo> sconklin, why revert for natty ? 
<sconklin> For Maverick
<manjo> ok
 * smb -> EOW
 * tgardner --> lunch
 * cking --> EOD
<lamont> 15811424        build/buildd/linux-3.0.0/
<lamont> um... guys?  that's a tad bit huge, don't you think?  I'll put cash on it failing to build on most of the ppa buidlers
<lifeless> what target builds linux-header-x.y.x package? 
<Sarvatt> binary-headers
<lifeless> Sarvatt: thanks! I should have nvidia going again on my custom build :)
#ubuntu-kernel 2011-07-09
<amitava> i am trying to extract the embedded initramfs within /boot/vmlinuz-2.6.32-32-server - here's the log http://pastie.org/2189620
<amitava> it seems to be encrypted - is that right?
<amitava> is there a way to extract the built-in initramfs? or does ubuntu use another fs like squash-fs?
#ubuntu-kernel 2011-07-10
<scott> any devs awake in here?
<scott> or support?
<scott> I'm trying to get my Ubuntu 10.10 system to recognize hard drives hooked up to my vt6410 pci ide card
<scott> Does anyone know how to get a Via VT 6410 pci ide card to 'see' ide drives in ubuntu 10.10?
<scott__> Does anyone know how to get a Via VT 6410 pci ide card to 'see' ide drives in ubuntu 10.10?
<psusi> can anyone help me understand the state of a device that has been removed, but not yet released?  if I echo 1 > delete in the sysfs node for sda, it goes away, but if a device-mapper still holds sda as a slave, it is still in use and thus not released, so if I rescan the disk, it is assigned another identifier, like sde.
<psusi> this seems messed up and I'm not sure how udev should properly deal with sda being removed since it can no longer look up its holders in /sys and try to remove the device mapper devices layered on top
#ubuntu-kernel 2012-07-02
<bullgard6> '~$ sudo modinfo snd; ...;  parm:  slots:Module names assigned to the slots. (array of charp)'. What does  Â»charpÂ« stand for? '[array of] character parameters?
 * smb guess char pointers
<bullgard6> Ah!
<ppisati> moin
<apw> ppisati, moin, bad 
<apw> head ?
<ppisati> no, i'm ok
<smb> ppisati, Surprising after having received so much beating... ;-P
<ppisati> i didn't receive any beating, they did... :)
<smb> Hehe, yeah, I know. Could not resist, though. :)
<cooloney> morning, apw, smb and ppisati, EU folks
<smb> Morning cooloney 
<apw> cooloney, moin
<ppisati> brb
<cooloney> cking: morning
<cking> cooloney, hiya
<cooloney> cking: i'm just wandering are you still working on some benchmark for CFQ and deadline stuff?
<cking> cooloney, not recently
<cooloney> cking: ok, got it.
<cooloney> cking: i'm just think how to reproduce the issue like this https://lkml.org/lkml/2011/6/9/167
<cooloney> cking: apologize for the delay response.
 * cking looks
<cking> bah, need to kick my AP again
<cooloney> cking: thx
 * ppisati starts the airco
<apw> henrix, you need a much bigger mic :)
<henrix> apw: yeah, i'm using my internal mic atm :-/
<apw> that'd be your problem, they suck
<brendand> does anyone know why there might be a disparity between the amount of RAM you think you have installed, and the amount reported by /proc/meminfo (MemTotal). Let's assume it's a 64 bit install
<apw> brendand, by how much ?
<apw> brendand, i believe memtotal is how much memory was 'available' when the kernel freed unused ram into the pool.  ie the kernel itself is not included and nothing reserved is included
<brendand> apw - what kind of things reserve memory?
<apw> acpi tables, memory to hold information about the memory pages themselves, the kernel binary itself etc
<apw> those things which you need to already have to be able to "visualise" the memory you have
<brendand> is there anywhere that tells me how much each of those things uses?
<apw> brendand, in a digestible form not that i know of, you get hints probabally in the dmesg output at boot about the sizes of various things
<apw> how much are we missing that you'd care
<brendand> so, let's say the memory installed is 1GB and MemTotal is 758076 kB
<apw> that sounds unexpectedly low to me
<apw> with 4GB or RAM i am missing 186100
<brendand> i have another system which has 8Gb installed and is missing 2Gb
<brendand> although that's i386 PAE
<brendand> not sure if that explains it
<apw> if its as much as 2GB thats more likely a h/w limitation and the e820 dump can help figure that out
<apw> not all machines cna express all the RAM they will let you put in them
<apw> for that 1GB machine a dmesg may be instructive
<ohsix> you still need pci regions for devices that can't do DAC and bios' that won't let you tell it that you want that :]
<apw> yep all depends how much ability to non-linearise the BIOS/hardware has in placing various ram components
<apw> i suspect with 8GB you have two 4GB sticks, so it probabally cannot avoid dropping the ACPI and PCI spaces over the RAM and hiding some of it
<brendand> http://paste.ubuntu.com/1071081/
<apw> if it has 4 2GB sticks it might be able to do something more appropriate
<brendand> for the 1GB system
<brendand> oh i see the e820 stuff at the beginning
<brendand> 759MB LOWMEM available.
<brendand> right on the button. have no idea how it works that out though
<apw> [    0.000000]  BIOS-e820: 0000000000100000 - 000000002f780000 (usable)
<apw> and that is what the BIOS says it has
<apw> 2f780000 is 759M
<apw> brendand, and i can see nothing that even looks like the rest of any ram this machine is meant to have even marked as something else
<apw> brendand, are we sure this has 1GB in it?  if i add this up its pretty much saying there is 768MB, which would be a 512MB+258MB 
<ohsix> dmidecode to the rescue
<apw> brendand, or is it being reserved for video ram, a low-end video sharing main memory for its vram, though 256MB seem excessive
<apw> brendand, yeah as ohsix says can we have a full dmidecode output
<brendand> apw - the video is onboard intel
<apw> [    1.034945] agpgart-intel 0000:00:00.0: detected 131072K stolen memory
<apw> so 128M is likely used by video
<apw> i would also check in teh bios to see how much it thinks its allocating
<brendand> apw - the figure is from dmidecode (i don't have physical access to these systems). so it's either 1GB stick or two 512MB
<brendand> http://paste.ubuntu.com/1071094/
<brendand> one gigabyte stick
<brendand> right, i had heard/read that video cards can take ram for vram
<brendand> and we just need to look in dmesg or is there somewhere in sys/proc where that can be looked up?
<apw> brendand, yep so i would be suspicious to know if the bios has allocated 128 or 256 given the GART size is 256
<apw> as for your 8gb machine again we'd need a dmesg
<ohsix> what was the problem anyways, suspect that a more than neccessary amount of ram is being shadowed?
<apw> symptom as reported was 1gb machine showing 759MB of ram
 * ppisati -> lunch
<apw> and yes suspecting that the shadowing in the BIOS is wrong
<ohsix> hm, i forget if pci=nocrs is worth trying
<ohsix> the bios can be dumb about placing devices and theres a way to get linux to try again for you
<apw> i think in this case the machine has plenty of space to play with, as it only has 1G
<brendand> 8GB DMI - http://paste.ubuntu.com/1071099/
<ohsix> right, assuming the bios isn't super silly :p
<brendand> 8GB dmesg - http://paste.ubuntu.com/1071103/
<ohsix> it can't move all the devices anyways, so it could still leave the problem one in a bad place :\
<brendand> apw - ok, scratch the 8GB one
<brendand> apw - i was reading a system rom as a ram stick
<Kalidarn> hi, i'm currently getting a kernel panic with the ATI fglrx driver, when i shut down what's the current doc for debugging kernel panics
<Kalidarn> https://wiki.ubuntu.com/Kernel/CrashdumpRecipe i had a look at that, not sure if those 9.04 instructions are relevant
<Kalidarn> or if there's a better way now
<Kalidarn> hmm wel not really any need to debug it further the screen error is exactly the same as comment #4 of bug 750437
<ubot2> Launchpad bug 750437 in fglrx-installer "fglrx hard lockup on shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/750437
<alexbligh1> Are there any plans to build a precise-backport kernel for Lucid, like there is oneric backport & natty-backport?
<cking> apw, http://www.entropykey.co.uk/res/device.jpeg
<apw> alexbligh1, i believe not currently
<apw> thats what precise is for
<Insyte> I have a Lucid -virtual VM that is crashing every few days.  It crashes hard and fast enough that no crash info escapes via syslog or local log files.  Any recommendations on trying to capture some decent data to start tracking down the cause?
<ppisati> ogra_: http://people.canonical.com/~ppisati/linux-image-3.4.0-202-omap4_3.4.0-202.8_armhf.deb
<ppisati> ogra_: give it a test if you can
<apw> Insyte, what virtualisation are you using to run it
<Insyte> KVM
<Insyte> Under ganeti.
<apw> Insyte, a quick chat round here, noone seems to know of a way, but noone is willing to say there isn't one ... you might get a better answer on #ubuntu-server however
<Insyte> I'll check there.  Thanks.
 * ppisati -> gym
<ogra_> ppisati, will do, thanks
<Eimann> Insyte: I guess you already tried kdump?
<Insyte> Eimann: I've been reading up on it.  Haven't tried it yet.  Is that generally the best approach?
<Eimann> Insyte: if you can force it to hang without a reboot, you can also try virsh dump <vmname> crashdump
<Eimann> I would try kdump first and see if this already give you a coredump you can analyze
<Insyte> OK, thanks.  Unfortunately the second option isn't available to me as Ganeti doesn't use libvirt.
<Eimann> hmm yes indeed
<Insyte> If I'm not running a -debug kernel, am I going to get any useful information out of a kdump dump file?
<apw> Insyte, you should, as most crashes the basic information is what one needs to have any clue as to caus
<Insyte> apw, excellent.  Thanks.
<argu_halfabrain> Hi
<argu_halfabrain> any clues why only 2 cores would be enabled on a quad core system? running latest 12.04, was fine on 10.04
<alexbligh1> apw, indeed, but we have binaries that won't run under precise due to library issues (libdbi1/libdbi0, openssl1.0.0 vs 0.98.x etc.) - and I'm trying to avoid having 2 different software versions just to run on different hardware. The long term answer is 'move everything to precise' which is what we are doing for a next major release but it's a PITA for a minor release.
<apw> argu_halfabrain, pastebin the output of cat /proc/cpuinfo
<argu_halfabrain> from lshw -class cpu "cores=4 enabledcores=2 threads=4"
<apw> alexbligh1, i can see how yet another lts backport would be handy, but you'd be just asking for Q then R for it, and we have to stop somewhere
<argu_halfabrain> http://pastebin.com/EgzucL66
<apw> argu_halfabrain, nothing obvious in there, it appears to have brought up the hyper threads on the first cpu if i am reading it right, pastebin a dmesg perhaps
<alexbligh1> apw, well, the place I'd suggest stopping is 'nothing beyond the next LTS'. Our launch date was within a week of Precise so was no chance of using that. If we don't move to the next LTS by the time LTS+1 is out, that's our issue.
<alexbligh1> apw, I can't believe other people who are "LTS only" for userspace would not have similar issues.
<apw> alexbligh1, and that has been argued, that there is utility in lts+1 to lts backports, but that was not planned for L
<apw> alexbligh1, the plan with the lts backports was to give you h/w enablement for the previous lts until the next lts came out, which it has
<apw> that goal doesn't need P on L, and so its not been in plan
<argu_halfabrain> also lshw -class cpu http://pastebin.com/1js0aCcu
<argu_halfabrain> rebooting that machine, will pastebin dmesg in a minute
<alexbligh1> apw, grumble grumble :-)
<apw> alexbligh1, i am not ruling it out as every happening, but right now its not the plan.  we review the plans often however for impact.  it might be appropriate to ask on the kernel-team list stating your use case
<alexbligh1> apw, thx - I might just do that :-)
<argu_halfabrain> dmesg output http://pastebin.com/1LLQC4gw
<apw> argu_halfabrain, whats in /sys/devices/cpu, how many cpuN directories
<apw> cat same directory online and offline
<argu_halfabrain> apw: cpu0, cpu1
<argu_halfabrain> online 0-1, offline 2-31
<apw> argu_halfabrain, ok nothing there is any help at all, i think the next step is file a bug and we'll want a dmesg and /proc/cpuinfo for the work and non-working cases
<argu_halfabrain> apw, ok thanks
<argu_halfabrain> gonna try a custom kernel
<bryceh> jsalisbury, bug #918769 looks ripe.  Patch is now in 3.5-rc4.
<ubot2> Launchpad bug 918769 in xserver-xorg-video-intel "X blink with Vostro 360 and Ubuntu Oneiric and Precise" [Medium,Fix released] https://launchpad.net/bugs/918769
<jsalisbury> bryceh, thanks!
 * ogasawara lunch
<bobo37773> Anyone know which kernel patches are included in the ubuntu kernel related to copying to and from a usb device?
<bobo37773> Yeah alright. Guess I'll just have to hack it apart until I can figure it out. Thanks anyways
 * bjf -> giving blood
 * bjf[blood] is back
#ubuntu-kernel 2012-07-03
<ppisati> moin
 * apw yawns
 * smb waits for his coffee to be ready...
 * apw watches the kettle boil
 * ppisati -> laundry + out for lunch
<apw> henrix, did you get your packages signed ?
<henrix> apw: yeah, sorry... forgot to give you an update
<apw> good enough
<henrix> apw: since natty was urgent, bjf took a look at it, signed and i uploaded it
<apw> thats great
<henrix> apw: anyway, we may need to re-start the cycle...
<henrix> with the leap-sec patches
<henrix> sru cycle is kind of stalled atm
<smb> Perfect time then to slip in even more "stuff" :-P
<apw> bjf, it seems there is a v3 of the leap patches: https://lkml.org/lkml/2012/7/2/530
<apw> henrix, its nor clear why we would restart the cycle for them, there won't be another leap second for 6m minimum
<henrix> apw: yeah, i know. its just that were some discussions about this yesterday 
<henrix> apw: and it wasn't clear if we wanted to have this in in this cycle
<henrix> apw: we still have time for that, but i guess it's not urgent :)
<henrix> anyway, we have a few kernels already on the ppa, and some more pkgs ready for signing
<ogasawara> henrix, apw: I'd agree it's not urgent at this point since the leapsecond has already passed and won't happen in the immediate future.  However I think there is a bit of a fire drill going on with some of our customer facing groups who would like to be able to communicate a fix is being applied in and available in the next cadence.
<henrix> yeah, i understood that. the only issue at this point is that the fix seems to be still under discussion. 
<ogasawara> henrix:  at this point, if a final version of the patch set emerges in time to hit this SRU window, let's land it.  but if it's still being discussed, it would seem reasonable to me to wait for the next cadence cycle.
<henrix> ogasawara: makes sense
<smb> ogasawara, How much beating (or are we allowed at all) would it cost to get rid of some deprecated acpi procfs files in quantal (to catch the fallout) that potentially were scheduled to be removed long ago...?
<ogasawara> smb: if we want to yank anything, I think now would be the time
<ogasawara> smb: if you have a patch, I'll likely take it
<smb> Then maybe to turn ACPI_PROCFS_POWER off would be a good opportuinity
<cking> ..and see what breaks :-)
<smb> Ok, can whip up a patch quickly... Though I probably want to make sure it still builds... before I send it
<ogasawara> smb: ack
<bjf> apw, sweet, will look at that in a bit when i'm more awake
<apw> bjf, np, no idea if its a final of course
 * ogasawara back in 20
<bjf> apw, reading that mail thread it seem a little premature to be rushing any set of patches out the door at this point
<apw> bjf, i tend to agree; the next leap is also at least 6m away
<ppisati> brb
<ppisati> do we have any official where we are going to stay for the kernel sprint?
<ogasawara> ppisati: yes, I'll send a quick email to everyone right now
<ogra_> you guys get travel approval for sprints ?!?
<ogra_> lucky you
<ogasawara> ogra_: your team should too
<ogra_> well, our sprints are virtual and many nowadays :)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 10th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ogasawara lunch
<cking> bjf, so I won't be needing waldorf, I've managed to reproduce the issue on my local boxes now
<bjf> cking, nice
<cking> bjf, actually, it's two issues compounded into one bizarre characteristic :-/
 * cking --> EOD
<nhm> Can a linux-tools package be produced with make-kpkg?
#ubuntu-kernel 2012-07-04
 * cking goes on a systemtap adventure
<apw> cking, to anywhere fun ?
<cking> apw, the path of torment
<apw> heh depending on ones predilictions that could be fun i guess
<cking> nope, it's never fun
 * apw goes splish
<apw> *splash*
<jamespage> apw, are you aware of any problems with the latest kernel in quantal?  I upgraded this morning and 0 peripherals - no USB, network, HDMI etc. etc...
<apw> jamespage, not heard of anything like that no
<jamespage> apw, well reverting to the previous one fixed me up
<jamespage> I'll report a bug then
<nhm> Can linux-tools-common be created with make-kpkg?
<apw> jamespage, did you get that via normal updates?  and do you have the extras pacakge
<apw> nhm, no idea 
<apw> nhm, no idea never tried
<jamespage> apw, no extras - just straight linux-image-3.5.0-3-generic
<nhm> apw: ok, thanks.  I'm trying to figure out how to make it for 3.4/3.5.  There was a patch on lkml a while back for deb-pkg that I tried, but it seems like it'll need work to function correctly.  
<nhm> apw: any idea how it's done "normally"?
<apw> nhm, for what the mainline builds ?
<nhm> apw: yeah.  I saw some examples for debian, but no idea if Ubuntu does the same thing.
<apw> nhm, our tools packages differ i am sure, we currently generate ours manually in the ubuntu packaging
<nhm> Ok.  I guess I'll have to disect them.  We create custom kernels for ceph from github and I want to start packaging perf with it, but so far there doesn't seem to be any real easy/standard way to get debs for it.
<apw> no userspace integration in the kernel sucks
<nhm> apw: Any ideas if there are any docs or examples I should follow regarding following the mainline build procedure?
<apw> how we build our debs is documented vaguly in the wiki
<nhm> ok, I'll look there then.  Thanks for all the help. :)
<jamespage> apw, think I must have had some sort of upgrade issue - had a right mix of packages installed with reference to kernel
<apw> oh hmmm, apt-get install -f (or whatever it is?)
<jamespage> yep
 * henrix will be back in ~20min
<cking> made me laugh: http://havewefoundthehiggsbosonyet.org/
<stack_> Hi, I am compiling linux kernel 2.6.36-4, but while performing make I get this error: No rule to make target `net/ipv4/netfilter/ipt_ecn.c', needed by `net/ipv4/netfilter/ipt_ecn.o
<stack_> How can I overcome this ?
 * herton -> lunch
 * ppisati -> gym
 * cking thinks he's figured out a reliably workaround to reading the fluke meter reliably event when it gets screwed up during a sessone of sample readings. 
#ubuntu-kernel 2012-07-05
<mendalon> anybody know if the new rc-core-based kernel modules can be used to do serial blaster stuff? i'm trying to transmit ir codes via a serial port and i'd like to avoid using lirc if possible.
<genii-around> They might know more in someplace more mythbuntu oriented
<ppisati> moin
<apw> moin
<smb> moin
<geeky_bitsian> does kmalloc return a physical address or a logical address ?
<brendand> i seem to have a problem running virtualbox when using the backports kernel on precise
<brendand> something about running /etc/init.d/vboxdrv setup
<brendand> but it's not installed (vboxdrv)
<brendand> hmm, do i have to install -headers and reinstall vbox?
<brendand> ERROR (dkms apport): kernel package linux-headers-3.5.0-2-generic is not supported
<ppisati> brb
 * ppisati should think about lunch...
<pgraner> apw, ping
<apw> pgraner, hi
<pgraner> apw, seeing some unusual stuff with the 3.5 kernels
<apw> brendand, anything which uses dkms needs the headers installed as well yes
<apw> pgraner, such as ?
<pgraner> apw, I keep getting tons of these in my log messages:
<pgraner> [   56.337779] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.342158] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.346286] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.350411] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.354529] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.358656] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.363038] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.367170] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.371296] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.375416] 5:-1:3: cannot set freq 32000 to ep 0x86
<pgraner> [   56.379552] 5:-1:3: cannot set freq 32000 to ep 0x86
<apw> 3 would have done :)
<apw> pgraner, its a usb message, perhaps your headset ?
<pgraner> apw, nope not plugged in, but my webcam stopped working
<apw> pgraner, then thats likely related to that then
<pgraner> apw, just filing a bug now, it works with 3.4.0-5 but fails with any of the 3.5 series
<apw> its deffo a usb device and something to do with speed
<pgraner> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1021261
<ubot2> Ubuntu bug 1021261 in linux "Web Cam No Longer works with 3.5.0-3-generic" [Undecided,New]
<cking> apw, possibly sound/usb/usx2y/us122l.c
<brendand> apw, i get ERROR (dkms apport): kernel package linux-headers-3.5.0-2-generic is not supported when reinstalling virtualbox
<apw> brendand, hmmm, never see that which package said it
<apw> initial reaction is that virtualbox is saying it doesn't support 3.5
<ricotz> apw, hi, maybe you are interested in bug 1021267
<ubot2> Launchpad bug 1021267 in linux "Brightness control keys not working on HP 2510p" [Undecided,New] https://launchpad.net/bugs/1021267
<apw> cking, that form only has one %d: in it, the reported message has %:%:% form
<brendand> apw, http://paste.ubuntu.com/1076305/
<ricotz> brendand, you need vbox 4.1.18
<ricotz> for 3.5
<apw> brendand, yep that output implies 3.5 is not a supported platform
<brendand> ricotz, right, so is that somewhere available for precise?
<ricotz> brendand, debfx has his backports ppa
<ricotz> https://launchpad.net/~debfx/+archive/virtualbox
<apw> ricotz, sounds like you have some idea of which commit is at issue from your bug perhaps you could include that ino
<apw> info
<ricotz> apw, i dont have a checkout here, but there are only two commits afair
 * henrix brb
<ricotz> apw, but this is just an idea
<ricotz> apw, there was some kind of transition to a newer structure
<brendand> ricotz, thanks. looks like i'm on my way to working vbox again
<mehdi> I want to join your team 
<apw> mehdi, you want to help with the ubuntu kernel ?
<mehdi> yes 
<apw> mehdi, ok, well there is lots of information on what we do and where we discuss things etc in the wiki, wiki.ubuntu.com/Kernel, particularly the development section.  That might be a good place to start
<apw> mehdi, ok, well there is lots of information on what we do and where we discuss things etc in the wiki, wiki.ubuntu.com/Kernel, particularly the development section.  That might be a good place to start
<mehdi> great 
<mehdi> I'll go through this 
<mehdi> all ready did, but I'll do it again to refresh things up 
<cking> bjf, can you power cycle waldorf for me?
<brendand> how do i get ubuntu-bug to work with the backports kernel package?
<apw> give it the name of the binary package perhaps ?
<brendand> 'not an official ubuntu package'
<apw> brendand, not sure waht to say to that, it is damn you apport
<brendand> so anyway to rip the logs and store them locally for uploading later
<brendand> ?
<brendand> i.e. what do i do if the bug is *no frickin network*!
<apw> you can say --save <filename> in that case
<apw> and submit it later
<brendand> actually wrong question. how are you guys going to be triaging quantal backports bugs if no-one can give you logs?
<brendand> assuming everyone will be met with the error above?
<apw> well i guess as its not released its not official yet
<brendand> apw - do i need to advise my team then that they need to get logs manually? it would be good to know if there's any way apport can be enabled for the quantal backports package
<apw> brendand, see privmsg
<rtg> apw, bug #1021174 - doh! what an oversight.
<ubot2> Launchpad bug 1021174 in linux "include all binary packages in module checks" [Medium,In progress] https://launchpad.net/bugs/1021174
<apw> rtg ... no comment :)
<apw> smb, do you still use squid-deb-proxy ?
<smb> apw, Yes, the one got pulled in by orchestra. (though I think its the normal one). Why?
<apw> smb, have some bits to try using ipv6 (including link locals) for squid-deb-proxy
<smb> apw, That would require actually using ipv6 and that I don't do
<apw> smb, i bet you have link-locals
<apw> and you only having link-locals is one of the test cases
<smb> apw, Yes I would have those probably... if those are used... 
<apw> smb, can you paste me the output of: avahi-browse -kprt _apt_proxy._tcp
<smb> apw, I can try, but you would better mail me what I should do cause I first want to finish my current task which needs a bit of thingking.. that output is nil
<apw> smb, then you arn't using squid-deb-proxy
<smb> apw, Ok, could be. Don't have a package like that installed. Its just squid3 and some special config to proxy deb
<apw> smb, yeah you have a hybrid
<herton> apw, not sure if I misread here, just quick checking,  package_prefixes() function doesn't seem to be called anywhere in debian/scripts/misc/getabis, on getabis patch
<cking> bah, gotta kick my AP again
<herton> apw, nevermind :P, saw next patch
<apw> herton, heh ...
<bjf> cking, you still need waldorf power cycled?
<cking> bjf, yep, I locked it up well and good
<bjf> cking: done
<cking> bjf, ta
<apw> herton, bah, seems zinc cannot get to ppa.l.n ... so although i can configure it, it won't work
<herton> apw, indeed, I had this problem before, I always had to use --local with maint-startnewrelease because of it
<apw> we should get rtg on the case
<apw> herton, but adding "http://ppa.launchpad.net/canonical-kernel-team/ppa/ubuntu/pool/main/l/linux" to repo_list in debian.master/etc/getabis should do the trick in the local case i believe
<herton> yep, should work just with the extra url I believe too
<apw> herton, perhaps you could test that and let us know, when you next need to
<apw> and in the mean time we can get zinc sorted out
<herton> ok
<rtg> apw, can't you run that from gomeisa or tangerine ?
<apw> rtg might be able to hmmm
<rtg> that would be my prference
<ericm|ubuntu> sforshee, around?
<sforshee> ericm|ubuntu, yep
<herton> apw, may be we should not enable always the ppa on the script, perhaps adding a switch/option, if we also assume that we could have some "dirt" in the ppa
<ericm|ubuntu> sforshee, found glided in glidepoint is waking up every 10ms
<ericm|ubuntu> sforshee, that seems to affect much the power consumption on this Dell machine,
<sforshee> ericm|ubuntu, quality stuff it sounds like
<apw> herton, you specifiy the exact version you want, so wherever it is it will be the right one
<apw> if its not there it will move on to the real archive
<ericm|ubuntu> sforshee, saw several of your reply regarding ALPS touch, thought you may have some ideas
<sforshee> ericm|ubuntu, I did some reverse engineering for some ALPS touchpads a while back, but I had access to the hardware
<herton> apw, yeah, almost impossible we will get same version but differing contents from the ppa and what is on official repo.
<ericm|ubuntu> sforshee, so do you know where's that glidepoint project and if it's open sourced?
<sforshee> ericm|ubuntu, this is what I did: http://swapspace.forshee.me/2011/11/touchpad-protocol-reverse-engineering.html
<sforshee> ericm|ubuntu, drivers/input/mouse/alps.c ?
<ericm|ubuntu> sforshee, nope - it's using glided which is packaged in glidepoint
<ericm|ubuntu> sforshee, that could be a FISH package though
<sforshee> ericm|ubuntu, I'm pretty sure that's binary blob stuff that ALPS provided
<sforshee> not open source
<ericm|ubuntu> sforshee, yeah seems alike
<ericm|ubuntu> sforshee, that's good to know, at least we know who to blame then
<ericm|ubuntu> sforshee, thanks dude :-)
<apw> herton, ok on gomeisa that works just fine, goes to the PPA first etc
<sforshee> ericm|ubuntu, if it's what I'm thinking of it also doesn't use the native touchpad protocol
<herton> cool
<sforshee> ericm|ubuntu, it's something more like the IMPS2 emulation like we used to have
<apw> herton, you happy adding them or shall i produce some patches
<ericm|ubuntu> sforshee, btw - there seems to be many touchpad issues recently, most of which are related to the abnormal behavior after resuming back
<rtg> apw, why is debian/scripts/misc/getabis different on Quantal vs Oneiric/Precise ? Shouldn't they all be identical ?
<herton> apw, feel free to go on, I'm right now working on ppisati ti-omap4 update
<herton> for precise
<sforshee> ericm|ubuntu, I recall an issue on synaptics a while back, but it should have been fixed
<ericm|ubuntu> sforshee, which one specifically?
<apw> rtg, no they differ because pae is gone
<sforshee> ericm|ubuntu, don't know. I just saw some discussion on linux-input. I thought someone from canonical reported the issue though.
<apw> -getall amd64 generic virtual
<apw> -getall i386 generic generic-pae virtual
<apw> +getall amd64 generic
<apw> +getall i386 generic
<apw> and virtual is gone too
<rtg> apw, thats a flavour. I'm talking about the generic script
<apw> they should be the same after patches ... /me checks
<ericm|ubuntu> sforshee, that was me?
<sforshee> ericm|ubuntu, I think so, just found the thread :)
<ericm|ubuntu> sforshee, LoL
<apw> apw@dm:~/git2$ diff -u ubuntu-{precise,quantal}/debian/scripts/misc/getabis 
<apw> apw@dm:~/git2$ 
<apw> rtg, ^^ yes after patching they will be the same
<ericm|ubuntu> sforshee, that's a weird issue - bad EC behavior I guess, but very specific, ayan's having a bunch of other weird issues
<apw> rtg, they differ currently cause you added the firmware tracking in P and not Q
<sforshee> ericm|ubuntu, I haven't heard anything about them, but if it's a regression we can always bisect
<rtg> apw, ok, thats what I'm seeing as well
<apw> and after these patches O,P and Q will be the same
<rtg> apw, you duidn't send the firmware tracking patch for Q, thought, right ?
<rtg> though*
<ericm|ubuntu> sforshee, I don't think they are regressions, I'll talk w/ ayan a bit more on them, and could possibly bother you for some thoughts
<sforshee> ericm|ubuntu, sounds good
<rtg> apw, ok, I added the firmware tracking patch to Q and now its identical to P
<apw> rtg though i already pushed those to Q didn't i?
<rtg> nope, I had no conflict
<apw> bah
<rtg> apw, hence my confusion
<apw> rtg, which now makes sense ... /me will sort
<apw> rtg, ok done
<rtg> apw, yeah, Q is still missing the 'UBUNTU: [Config] getabis -- series uses linux-image-extra' patch
<rtg> apw, nm, looks good now
<apw> rtg there now
<apw> rtg, i reset them back off earlier cause while i sorted the bug numbers, clearly forgot to push them again
<rtg> apw, so, do we also have to fix any of the topic branches? Perhaps only Oneiric/Precise ?
<apw> rtg, i don't think so cause none of them have a split ?
<apw> it was only virtual in O and P anyhow that has a split
<rtg> apw, but they are rebase branches and will pickup the new getabis which now requires an input parameter
<apw> rtg, nope i very specifically made it default to 'linux-image'
<rtg> apw, ok, didn't notice that.
<apw> __package_prefixes="linux-image"
<apw> so that we'd not have to bother on older releases if it went there
<rtg> apw, ok, I see where you did that now
<rtg> apw, where do you annotate why a config option is inconsistent ?
<rtg> for example, ppisati wnats to make CONFIG_SND=y for omap, but its gonne be =m for everything else
<apw> rtg, when its going to show up in the kernel configuration review, that in kteam-tools/devel/OVERRIDES
<apw> rtg, in a similar but subtly different format to the enforcer
<rtg> apw, ah. didn't think to look there.
<apw> rtg, note that now has cut support using the /, see other examples
<apw> CONFIG_SND p policy<(flavour omap &/ value y) | value m> note<REASON>
<apw> rtg, something like that
<rtg> apw, blech!
<apw> rtg, indeed not pretty, its a work in progress, the p bits on its way out but not yet complete
<rtg> apw, I'm wondering why we don't carry this info in the kernel tree ?
<apw> rtg, i was just wondering the same thing myself ... i will add that to the agenda, i think its likely we do want to do that
<rtg> agreed. after all, the config options are kernel specific
<apw> rtg, indeed and in places i have wanted to have different answers per release ... so clearly they should be in the tree now we have a maximal set
 * ppisati goes out for a bit
<apw> rtg, added
<rtg> apw, thanks
<apw> ppisati, what are these manditory builtin modules for omap sound, got a simple list
<apw> rtg, is that what you are doing to OVERRIDES or ... ?
<rtg> apw, they should be listed in the Precise patch description
<rtg> SND_OMAP_SOC, SND_OMAP_SOC_MCBSP and  SND_OMAP_SOC_OMAP3_BEAGLE =y
<apw> ahh ok, rtg and are you adding them to the OVERRIDES or shall I
<rtg> apw, go ahead. I'm still fixing the Q patch (abi stuff)
<apw> ok will do
 * herton -> lunch
<ogra_> sigh ... omap sound ... such a mess
 * balloons just found out again that sysrq is disabled on ubuntu :-(
<balloons> if I have a random kernel hardlock, what's the best way to get good information about what happened?
<stgraber> could anyone with aufs/overlayfs knowledge look at bug 959352? it's causing some problems in containers (>= 12.04) and when used with aufs leaks information that the container shouldn't know
<ubot2> Launchpad bug 959352 in lxc "Ephemeral containers have "/rootfs" prefix in /proc/self/maps entries" [High,Confirmed] https://launchpad.net/bugs/959352
<smb> balloons, sysrq is not disabled really. Sometimes the key combo is hard to find or things a locked up so hard that even that is not handled anymore.
<balloons> smb, I see it's set to 0 in a sysrq conf file, with a note, most users shouldn't need this. Should I not use it?
<smb> Hm... which file is that exactly? I don't seem to have that...
<balloons> smb, /etc/sysctl.d/10-magic-sysrq.conf
<balloons> I put a '1' back in the file to enable it again via sysctl at boot
<smb> balloons, Funny, not present in my installation (Precise)
<balloons> hmm.. I'm on quantal.. I wouldn't think this would be new
<balloons> interesting
<smb> Hm, maybe was added. It is sometimes a bit of a struggle as some keyboards have sysrq on print and then the desktop feels it should do something when you actually not want to...
<balloons> yes, I have the printscreen and sysreq key as the "same" key
<balloons> smb, your right. others on precise don't seem to have it
<smb> balloons, You may find out what brought it to you with dpkg -S /etc/sysctl.d/10-magic-sysrq.conf
<balloons> procps: /etc/sysctl.d/10-magic-sysrq.conf
 * henrix will be back in 15 mins
 * cking --> EOD
 * smb -> EOD
 * henrix ->EOD
<herton> rtg, I think "retrieve ABIs from PPA as a last attempt" could be commited on oneiric as well
<herton> actually on all relevant trees. I'm not sure changing maint-startnewrelease or drop its usage, anyway one of the two choices must be done
<rtg> herton, I like having the PPA path in the getabis script since it appears that the use of the non-virt PPA is permamnent.
<rtg> herton, I actually didn't know about maint-startnewrelease,  but I think adding the ckt PPA URL serves the same purpose.
<herton> rtg, yes. well we always used it doing the stable updates, it automatically fetches the packages, removes the old abi/copies the new one, and does the commit, just automate things a bit more.
<rtg> herton, yeah, after looking at the script it automates a bunch of what I've always done by hand.
<rtg> plus some other checking
<herton> I think we could just modify it to use the getabis from the in kernel tree, or just add same functionality to the in tree scripts
<rtg> herton, that seems like a good idea. it minimizes duplication of code
 * rtg -> EOD
<marsfligth> Hi to all. Hi made a disaster on my Ubuntu 12.04 64-bit. I managed the passwd to add users on my samba server following a guide on the net and after the reboot it don't accept the right password. In more, I have the home directory encrypted (EFS) only this '/home/myusername'. Have you idea how to get access to my account? Thanks
#ubuntu-kernel 2012-07-06
<genii-around> marsfligth: Ubuntu support is in #ubuntu
<marsfligth> genii-around: Thanks for the information ...
<smb> morning
<infinity> bjf: So, someone turned on ddeb support for your PPA, and that blew up the world for your precise builds when we tried to copy them to primary.
<infinity> bjf: I've had webops turn that back off again, but the only solution is going to be to reupload linux and linux-ti-omap4 for precise (no-change upload, just rev the build number/changelog), so we get fresh builds without ddebs.
<infinity> bjf: In related news, I copied all your pending kernels (except the two above that broke), but it's sleepy time, so if no one beats me to it, I'll fix all the overrides in the morning.
 * smb certainly won't
<smb> infinity, Good morning/night :)
<infinity> smb: Oh hey, a kernel team dude.  Feel free to do the above two no-change reuploads to the PPA, so they build overnight! ;)
<infinity> smb: Then I can clean up the mess in the morning.
<infinity> smb: (If you do, make sure to -v the dpkg-buildpackage, so it includes the previous changelog entry).
<smb> infinity, I will have a look. Yup. 
<infinity> smb: Cheers.  If you do 'em, tell bjf about it, so he doesn't wake up to my pings and think he has to fix the world. ;)
<smb> infinity, He probably will , err well he hopefully ready on to above and realizes he has not to (or at least checks), right bjf ? :)
<smb> Now, if my fingers would start to type what I am thinking, maybe my sentences will start to make sense...
<infinity> smb: Oh, and to be clear, -meta and -backports-modules and all that jazz is already fine and copied, so it's just linux/precise and linux-ti-omap4/precise that need the rebuilds.
<smb> infinity, Ok, ack. I may consult with henrix if he comes up as I am not sure I always know what the formal requirements beside the brute git change and package are...
<infinity> Mmkay.
<infinity> (If I had git commit, I'd just commit the changelog and upload directly to -proposed at this point, since the whole point of the PPA test/copy cycle has kinda gone out the window right now anyway, but I can't commit, so... You're safe from my meddling)
<infinity> For you, you're better off uploading to the PPA, since it bypassed archive admin approval. :)
<smb> Heh, yeah. I mostly will do that, though the decision would be between opening a new rev in changelog with a bt of tweaking or just replace the old one
<smb> And of course I had the problem with the archive admin approval which oyu don't :)
<brendand> does anyone know what tigon/tg3_tso.bin is?
<ppisati> btw, moin
<smb> ppisati, moin
<smb> brendand, what would the fact that it resides under /lib/firmware tell you? 
<infinity> smb: That it's tasy, tasy candy?
<infinity> tasty*
<smb> infinity, Still not in bed? :) Yeah, well maybe rather 100% cacao chocolate... :-P
<infinity> smb: I'm not very good at this sleeping thing.  I'll try harder.
 * smb remembers old comic books suggesting a mix of hypnosis and a rubber hammer... Hm, probably owning those is illegal nowadays...
<infinity> smb: They still haven't outlawed comic books here.
<infinity> Anyhow, I see your henrix has shown up.  I'll go try to sleep more. :P
<smb> infinity, hehe, see you then
<henrix> infinity: hmm?
<smb> henrix, Good morning :)
<henrix> smb: hey!
 * ppisati heards that vodka helps with sleep...
<smb> henrix, Just was talking with he who tries to sleep that we need to re-upload precise linux and linux/ti-omap4 to the ppa
<smb> Just /me is pondering about how to tweak the changelog
<brendand> smb, yes i know it's firmware. for what kind of hardware?
<henrix> smb: and what's the reason for that?
<henrix> smb: any urgent patch?
<smb> brendand, modinfo tg3
<smb> henrix, No just PPA running full and somehow those probably went bad on build
<smb> henrix, And now you cannot upload the same number again
<brendand> smb, right so it's for ethernet, but despite that we don't install it the ethernet works fine
<henrix> smb: yep, we would need to re-spin the kernels incrementing the minor number
<smb> henrix, I think I convinced myself that the best way will be to just increment the version line without starting a new version (otherwise all the pain with abi change will hit)
<smb> henrix, Maybe an additional comment in the "old" changelog about no-change upload is ok... Though I am not sure there may be formal processing rules requireing a different approach
<smb> brendand, You sure you don't isntall them? Because here they come (precise) with the kernel.
<brendand> smb - hmmm, why does the installer ask me to install them from removable media?
<henrix> smb: how did you know about these kernels being damaged?
<smb> henrix, He who sleeps told brad while I was in this channel too
<smb> brendand, I do not know
<henrix> ah, ok
 * henrix goes check email
<smb> henrix, irc 
<brendand> smb, do you think it's worth a bug?
<apw> infinity, turned off our ddebs?  we need those ...?
<apw> (clearly i have missed some subtlety)
<smb> brendand, Well maybe, if that is repeatable and if that is new and whatever release we are talking anyway?
<brendand> smb, well it's been the whole time with precise
<brendand> smb, very repeatable on one IBM server we have
<brendand> smb, in linux-firmware? or d-i?
<apw> which install media you using live or alternate
<smb> brendand, since its linux package I put it into linux. What type of install ist that alternates, server, or desktop?
<brendand> smb, server
<infinity> apw: Do you?  Cause you never had them in the PPA before. :P
<infinity> apw: So, define need, exactly...
<apw> infinity, support need ddebs for every kernel, but they have been collecting them from ddebs.ubuntu.com and archiving them so they must have existed
<infinity> Hrm.
<infinity> smb: Don't go reuploading yet.  I need to dig deeper.
<smb> infinity, Yeah, I was already holding as soon as while talking to apw this came into mention
<apw> u
<apw> infinity, if you look at ddeb.uubuntu.com we have -26.36 ddebs across the board (precise -updates kernel)
<apw> infinity, perhaps that one didn't build right cause the PPA got full up, and the bug is with ddeb handling there
<apw> infinity, oh ... hang on ...
<apw> infinity, could this be we had ddeb's turned off on the PPA, but cause they are de-virtualised
<infinity> apw: No, all ddeb-enabled PPA builds *can't* be copied to primary.
<apw> infinity, they get left on the buildds as normal and found the normal backdoor, all by accident ?
<infinity> apw: But with devirt PPAs, pitti's scripts copy them out when you do the backdoor trick.
<infinity> apw: Right.
<apw> jinx
<infinity> apw: So, my disabling ddebs on the PPA fixes it back to how it was.
<infinity> (ie: working)
<apw> infinity, ok then that all makes sense ... and explains why we had to make it 2x as big yesterday :)
<infinity> bjf / smb: Bad news, queuebot lied to me.  Looks like EVERYTHING except for hardy failed to copy, because they all had ddebs.
<infinity> So, if you guys want to sort out no-change uploads of, well, everything that had ddebs. :/
<apw> infinity, of course ... hardy does the old debug handling ... ie not using .ddeb
 * infinity nods.
<infinity> apw: If you want to help hammer these out, I'll love you forever.
<apw> infinity, ok will get those sorted out ...
<infinity> http://people.canonical.com/~ubuntu-archive/pending-sru.html
<infinity> ^-- The kernel PPA section at the very bottom should be a good indicator of what needs reuploading.
<infinity> (Except for the metas)
<infinity> And that lum, that someone forgot to copy...
<infinity> (I'll do that now)
<apw> infinity, ack
<apw> infinity, oh gawd this is going to blow poor shankbots mind
<infinity> Shankbot, schmankbot, you're going to cripple the buildds for a day.
<infinity> Enjoy.
<infinity> Apparently, we get to blame james_w.
<infinity> He thought you guys needed this turned on. :P
<apw> infinity, heh ... always they way ... will get this sorted with herton shortly
<infinity> apw: Danke.  I expect to see it all fixed when I wake up. ;)
<apw> infinity, we are going to have utter chaos here until then, all our process monitoring will be in the grinder
<infinity> apw: Bah. Change the titles of a few tracking bugs for the new version, commit some "oh god, rebuild, lolz" changelogs to git, reupload, profit?
<infinity> apw: You people and your processes. ;)
<infinity> (I'll leave you to it)
<apw> its the damn abis which get me
<infinity> You have the ABI files in the previous builds in the PPA.
<infinity> You can just fetch 'em all and you're set.
<apw> right ...
<infinity> Shame that fetch-abis only scans the archive by default, so you get to download all the debs from the PPA by hand!
<infinity> That's not the sound of me giggling like a schoolgirl.
<infinity> No sir.
<apw> infinity, no we fixed that yesterday :)
<infinity> Oh, shiny.
<smb> ther e is one for that
<infinity> Good timing.
<infinity> Almost like you knew you'd need it today!
<apw> infinity, completely random or what
<brendand> smb - btw, the issue also happens with quantal
<brendand> smb, i would have to go back and check oneiric
<henrix> manjo: ping
<smb> brendand, sure likely the same tweak there (quantal) though oneric could be affected the same it is less likely that installer disks are re-spun...
 * henrix reboots
<brendand> cking, i think i probably mentioned this before, but nearly all our systems have a 'DMIInvalidHardwareEntry: Test 1, Unmatched Chassis Type SMBIOS Type 3 reports 11 ACPI
<brendand> FACP reports 0' type of error
<brendand> the numbers vary
<cking> brendand, yes, can you report that in a bug report against fwts
<brendand> cking, against fwts? so just one catch all bug then?
<brendand> cking, i don't need to trudge through creating one for each system?
<brendand> cking - there's one HP server with: http://paste.ubuntu.com/1077885/
<cking> brendand, can your file a bug against fwts saying that this is happening an a wide range of machines, and an example of the log produced by fwts.  Then we can see if it is being too pedantic, or if it's a real firmware issue that needs attention
<cking> brendand, yep, that last one is an issue with the firmware, the string index falls off the end, causing this error
<brendand> cking, i'll file it seperately
<cking> great
<brendand> https://bugs.launchpad.net/fwts/+bug/1021674
<ubot2> Ubuntu bug 1021674 in fwts "DMIInvalidHardwareEntry - Unmatched Chassis Type" [Undecided,New]
 * ppisati -> out for lunch
<cking> brendand, so ignore the DMIInvalidHardwareEntry - the check  wrong and we need to fix that in fwts
<cking> s/check wrong/check is buggy/
<brendand> cking, apport for fwts isn't very verbose
<cking> brendand, apologies, but for that dmi test there has been a screw-up, I'm figuring out why it got that way and trying to work on a fix
 * cking --> lunch
<cooloney> apw: hey, man still around?
<apw> cooloney, hi
<cooloney> apw: i'm looking the configs, found CONFIG_DM_RAID45 is not existed in kernel
<apw> cooloney, in which kernel
<cooloney> apw: and we are using CONFIG_DM_RAID for a RAID 4/5/6, I think
<smb> That is a ubuntu driver btw
<cooloney> apw: in quantal
<apw> debian.master/config/amd64/config.common.amd64:CONFIG_DM_RAID45=m
<apw> seems to exist to me
<cooloney> smb: oh, i forgot that
<apw> its obviously only meaningful on x86 anyhow as its a BIOS bodge for there
<smb> In a very loose meaning of BIOS bodge but yes
<cooloney> apw: yeah, but looks like omap4 enabled it as module
<cooloney> i will sent patch to disable it. 
<apw> cooloney, i don't think it makes sense to be enabled indeed
 * smb agrees
<cooloney> apw: hmmm, so we can completely disable it for all flavours, right?
<apw> cooloney, no, it makes sense on i386 and amd64
<apw> cooloney, as it is only a BIOS on those machines which can need it
<apw> smb, ^^ right?
<cooloney> apw: sure, right now, only ti-omap4 enable it as module.
<cooloney> apw: so i will send out patch to disable it, since no BIOS stuff on omap4 i believe
<apw> right, any non-PC platform which has it enabled is silly
<smb> apw, At least no bioses which define some raids and then would need dmraid. And other RAID container formats might be handled by mdadm, yso yes
<cooloney> so what about the CONFIG_DM_RAID in upstream kernel tree
<cooloney> from the description it supports the same thing as RAID45 from my quick review
<apw> smb, you are my dmdraid45 expert :)
<smb> cooloney, that is sort of a wrapper to use md from within dm
<smb> You could use dm-raid45 as well on arm (manually) but without really an urgent need one does not want it
<smb> cooloney, I would not disable those
<smb> You still may want to define/create your software RAIDs on arm
<smb> Not sure how many disks arm boards would have but for something like arm server one would think there will be more than one...
<cooloney> smb: so we should make this as module for all flavours?
<cooloney> smb: right, as ARM server is coming, software RADIs might be useful. 
<smb> cooloney, I should not hurt to have those available as modules
<cooloney> currently we enabled this in ti-omap4 and x86
<smb> It
<cooloney> actually the policy is (arch i386 amd64 &/ value m) | value n
<cooloney> i don't think ti-omap4 will have many disks, since it has not SATA/PATA interface at all. but for highbank or armadaxp it should be useful
<smb> Stuff in drivers/md is not really depending on SATA/PATA. You can as well mirror usb storage devices. Whether is makes sense or not... But at least those drivers are just taking block devices to create some "other" block devices
<cooloney> smb: ok, i will leave it as =m for ti-omap4, maybe it will be useful sometime.
<rtg> apw, ppisati: can one of you build 'git://kernel.ubuntu.com/rtg/ubuntu-quantal.git ti-omap4' and boot test it? Its a stable update to v3.4.4.
<ppisati> rtg: why this update? anyway, i'll do as soon as i finish another omap3 installation
<rtg> ppisati, why not this update ? lots of good USB stuff in there as well as some arm patches
<apw> rtg, am un-f*ing our stable builds right now after someone in webops decided to enable ddebs in our ppa
<cooloney> ppisati: after the commit 'UBUNTU: [Config] SND_OMAP_SOC, SND_OMAP_SOC_MCBSP and SND_OMAP_SOC_OMAP3_BEAGLE =y', if i run 'fdr updateconfigs', our script will revert your setting in config
<cooloney> ppisati: is that an issue?
<rtg> cooloney, hmm, I thought I _did_ do that.
<cooloney> ppisati: i just update some other configs by 'fdr editconfigs' and it turns out got some changes about SND_OMAP_SOC every time 
<cooloney> rtg: you mean you fixed that in master-next already?
<rtg> cooloney, no, I meant that I thought I ran updateconfigs, but perhaps I didn't.
<cooloney> rtg: i got this after running updateconfigs, http://pastebin.ubuntu.com/1077999/
<rtg> cooloney, looks like it ends up doing the right thing, just sorted a bit different.
<ppisati> do we need to run it twice to get it right?
<rtg> ppisati, shouldn't have to
<rtg> cooloney, ppisati: I'll just fold those changes back into that commit and repush.
<cooloney> rtg: yeah, thanks
<rtg> cooloney, ppisati: done (on master-next)
 * rtg makes sure it still builds....
<cooloney> rtg: yeah, got it. just pulled
<cking> brendand, OK, I've got a fix for that fwts dmi table issue, I'll send it to the fwts-devel list and it should be incorporated into the next release sometime in the next few weeks
 * cking --> pop out to pick son up from school, back shortly
<apw> herton, ok i have pushed all the tags and masters, am about to rebase all the master-next branches, ok ?
<herton> apw, ok
<brendand> cking, thanks
<ppisati> rtg: did anyone changed chroot in tangerine?
 * cking <-- back again
<ppisati> dpkg-checkbuilddeps: Unmet build dependencies: cpio libelf-dev libnewt-dev binutils-dev libdw-dev transfig sharutils
<ppisati> (quantal-amd64)ppisati@tangerine:~/ubuntu-quantal$
<ppisati> dpkg-buildpackage -us -uc -aarmhf
<ppisati> brb
<herton> apw, hmm, didn't noticed that the new lucid package had the new abi directory as debian.master/abi/2.6.32-41.912.6.32-41.92
<rtg> ppisati, hmm, checking
<herton> apw, ouch, natty has the same issue
<apw> herton, how the hell
<apw> herton, oh both have the same error because they are the same base package
 * apw will had better fix his errorn
<herton> apw, did you use an script to do them?
<apw> herton, nope, somehow that is a manual error
<apw> herton, well so much for me saving anyone any time
<apw> herton, anyhow leave the disaster recovery disaster with me
<herton> heh happens... ok. I also failed to see it, I did a diff of contents etc but didn't paid attention to the directory name
 * apw is suspicious its his mouse actually stuttering on paste .... HMMM, time for a new mouse
<smb> herton, apw, Speaking of those things... I think I saw an old abi dir dangling in precise...
<herton> smb, yep, saw the same here
<smb> But those were even before doing anything
<herton> yep
<herton> we can fix later
<smb> right
<rtg> jsalisbury, henrix, ppisati: lemme know when I can reboot tangerine. 
<jsalisbury> rtg, now's ok with me
<henrix> rtg: same here
<rtg> arges, tangerine needs a reboot
<arges> rtg, ok
<arges> rtg, i'll rebuild on another machine
<rtg> arges, ok, bouncing....
<herton> apw, kteam-tools/maintscripts/verify-release-ready would catch the problem on lucid/natty, but you have to run it inside the ready git repo
<apw> herton, yeah, if i'd done my job properly it'd have been right too.  as i said earlier its just not my day
<herton> apw, np, not sure if you rememberd about the script. btw, we could have some documentation for the ddeb stuff and the ppa, what is involved, how it works (none of us knew about it), could be something for the sprint may be
<apw> herton, yeah why not, add it to the agenda me thinks
 * ppisati goes to pick my shirts from the laundry, brb
<herton> ok, added a topic there. our agenda is pretty huge right now
<jsalisbury> rtg, I just added bug 1018020 to the hot list, it's a webcam bug, but it seems like it might be affecting the Quantal A2 installer.
<ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,Confirmed] https://launchpad.net/bugs/1018020
<jsalisbury> rtg, I can reproduce it here, so I'll try to bisect it.  I just wanted to get some extra eyes on it, in case it heats up
<rtg> jsalisbury, ack, looks like you've got it well in hand.
<jsalisbury> rtg, cool, just wanted to give a heads up
<rtg> jsalisbury, gotta keep all those manager types happy. they wouldn't know how to act without their video crack.
<jsalisbury> rtg, lol, exactly
<jsalisbury> rtg, there just this USB bug that making it a pain to bisect, so I need to bisect that first to be able to properly test rc1 and rc2
 * cking wonders where the week has gone
<herton> smb, are you uploading ec2 or just making the branch ready? I saw you set the upload task as fix released
<smb> herton, Yes, its in the ppa already
<apw> i expect it will break too sigh, my fault
<smb> apw, Nah, got my own abi version ;)
<apw> thats something :)
<herton> smb, ok, it should be in progress, the bot will set the upload task to fix released when build is done
<smb> herton, Ah ok, sorry for that then
<herton> smb, if there is no meta pacakge, the prepare pacakge meta task should be set to invalid though
<herton> np
<smb> herton, There is one this time
<smb> I can prepare that, too if you want to
<herton> smb, ok I'll do it. if prepare-package-meta stays new, the bot will just wait on that indefinitely. so either it is in progress (building in the ppa), or invalid (not needed) as well
<smb> herton, So since you gonna do it I leave my fingers of that. This is time is a bit special since only ec2 bumps the abi due to that special change
<rtg> cking, do you install the intel-microcode package on SandyBridge machines?
<cking> rtg, I've not done so, but I have kit I can try it on
<rtg> from the most recent changelog:   * Fixes precise-event based sampling (PEBS) on Sandy Bridge processors
<rtg>     (http://lkml.org/lkml/2012/6/7/145)
<rtg> I think I have some kit as well
<ppisati> rtg: gomeisa chroots are screwed too
<ppisati> rtg: trying precisse-amd64
<ppisati> rtg: and it works
<ppisati> (precise-amd64)ppisati@gomeisa:~/ubuntu-quantal$ dpkg-buildpackage -us -uc -aarmhf
<ppisati> is ok
<ppisati> quantal-amd64 -> http://paste.ubuntu.com/1078205/
<ppisati> Unmet build dependencies: cpio libelf-dev binutils-dev libdw-dev transfig sharutils
<ppisati> quantal-armhf is good too
<rtg> herton, apw: Is this a result of the ddeb carnage ?
<rtg> The following packages have been kept back:
<rtg>   linux-headers-server linux-image-server linux-server linux-tools
<herton> rtg, if you have proposed enabled, probably yes
<herton> I noticed meta packages were copied, but mains failed
<rtg> herton, I do, just like a good kernel developer should.
<herton> sure :)
<apw> rtg, this was triggered by the disaster, both were built so he hit copy both
<apw> rtg and it only copied one of them
<rtg> ppisati, so, it appears that only the cross compile is busted. its likely something to do with a dpkg update.
<henrix> manjo: ping
 * herton -> lunch
<cking> rtg, the microcode-20120606.tgz works fine on my i3 x220i and i5 x230
<cking> ..Sandybridge + Ivybridge
<rtg> cking, I think the errata that it was attempting to address involved ptrace
<rtg> something to do with high precision measurements ?
<cking> ah, /me looks at that
<rtg> I didn't read the whole thread....
<apw> herton, ok i've pushed the two i broke, and will monitor the builds ... 
<jsalisbury> rtg, is it Ok to use tangerine, or are there further reboots needed?
<rtg> jsalisbury, I'm still working on it. use gomeisa for now
<jsalisbury> rtg, ack
 * ppisati -> gym, back later
<herton> apw, ack
<apw> herton, i updated the titles of the two bugs to match, i believe the lts backport natty is ok, but if not will sort it when it goes bang
<apw> (but as i386 has gone TICK i assume we are ok)
<herton> apw, ok, if we notice anything we can fix the bug too, np
<apw> herton, what a disaster :)  still a good reminder than anyone can screw the pooch
<apw> that vigilance and even getting someone to check, you can still screw it up
<herton> yep, happens sometimes
<apw> yeah and its most annoying when it happens cause you are in a hurry and want to help people get ahead :/
<manjo> henrix, pong
<henrix> manjo: hi! just to let you know i've the output of usb-devices for your BT patch
<henrix> manjo: take a look at bug #1010281
<ubot2> Launchpad bug 1010281 in linux "[12.04] Broadcom Bluetooth device (Vendor=0a5c ProdID=21f4) not supported" [Medium,Confirmed] https://launchpad.net/bugs/1010281
<manjo> henrix, do you want to respond to lkml with that info ? 
<henrix> manjo: sure, i can do that. but maybe its easier just to resubmit the patch?
<henrix> manjo: just let me know if you're planning to re-submit the patch or if you want me to just send this info in reply to your initial patch
<manjo> henrix, I just sent a reply to Gustavo with the info that is on the bug, and also asked him if he wants me to resubmit ... 
<henrix> manjo: cool, thanks!
<manjo> henrix, thank you 
<cking> rtg-lunch, I'm having little luck in exercising the PEBS via perf on my machine, must be missing something but I can't figure it out and my day is nearly over :-/
<rtg> cking, no problem, go have a beer
 * cking just sent my wife out to buy some actually ;-)
 * cking --> EOD
 * henrix --> EOD
 * rtg --> EOW
<hggdh> herton: the arm bug has been retagged qa-testing-passed
<herton> hggdh, ok, thanks
#ubuntu-kernel 2012-07-07
<deffrag> Hello! I've been noticing abnormal behavior in Ubuntu 12.04. My system's GUI and keyboard suddenly freezes but it doesn't freezes movement of mouse, audio playback and ssh access. I cannot click on anything, change to tty0-6, caps lock on/off gives no indication. I'm not able to understand this type of behavior. Can anyone help me identify the problems and fix them please?
<deffrag> I'm faced with the problem again and currently I'm connected to the problem system from netbook via ssh. I can see top/htop giving an also increase/decrease volume using alsamixer. I don't know how it sounds or what I'm missing here ...
<deffrag> ..I can see top/htop listing processes and can also increase/decrease... *
<deffrag> But not able to get anything working directly on the problem system
<JanC> deffrag: does the screen still update (e.g. the clock)?
<deffrag> JanC: No, nothing really update.
<deffrag> s
<deffrag> Clock is 40 minutes behind
<JanC> no heavy swapping going on?
<deffrag> Sec, let me give you mem info
<JanC> although 40 minutes is long
<deffrag> System is still running as per top from ssh and I can only have cursor movement on the problem system
<JanC> and most likely that would cause audio to stutter too
<JanC> could be a graphics driver issue...
<deffrag> No, no distortion at all. The music is playing as if nothing happened
<JanC> or in theory also a compositor (compiz) issue, I suppose
<deffrag> And the graphics card is disabled using bumblebee, as I'm using gfx with optimus
<JanC> if this has anything to do with graphics, you probably better ask in #ubuntu-x (or on their mailing list)
<deffrag> I forgot how to fetch MemInfo and SwapInfo parameters form commandline, somewhere in /sys/proc if I;m right
<deffrag> $ cat /proc/meminfo 
<deffrag> MemTotal:        6005648 kB
<deffrag> MemFree:          215700 kB
<deffrag> SwapTotal:       5235708 kB
<deffrag> SwapFree:        4849064 kB
<deffrag> .. in reply to what you asked initially about swapping
<deffrag> If that help. Thanks, I'll try asking in #ubuntu-x
<deffrag> JanC: With help from #bumblebee identified the issue to be very close to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1015015
<ubot2> Ubuntu bug 1015015 in xserver-xorg-video-intel "Xorg freezes once a day, mouse and SSH still works" [High,Incomplete]
<JanC> deffrag: certainly sounds like an issue for the X team then
<deffrag> Yes, thank you
#ubuntu-kernel 2012-07-08
<infinity> bjf: *poke*
<infinity> bjf: OH GOD YOUR SCRIPT MAKE IT STOP.
#ubuntu-kernel 2013-07-01
 * apw yawns
<apw> jxself, i would assume that 3.8.7 was based off the config for the 3.9.x series kernels in saucy, and 3.8.8 was based off the config fo ther 3.10.x series kernels in saucy (which we just switched to)
<apw> jxself, and as i don't see that option in the current kernel it would likely default off
<apw> one assumes they have gotten rid of the option there because it is always on
<apw> a limitation on how the configs are made up for mainline builds
<apw> jxself, i have put together a hack to use a slightly closer config (in theory) and the build from that should be popping out in the next hour; if you could see if that works any better
 * henrix -> lunch
 * ppisati goes out for a bit
<Trevinho> Hello, since the upgrade to kernel 3.10 in saucy, I can't boot anymore using the radeon.audio=1 cmdline... 
<Trevinho> What can help for debugging?
<Trevinho> See bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1195687
<ubot2`> Ubuntu bug 1195687 in linux (Ubuntu) "Init crashes with kernel 3.10.0 when using radeon.audio=1" [Undecided,New]
<jxself> apw: Thank you for your work on 3.9.8. It appears that everything is back.
<apachelogger> what would be the best way to get bug 1196556 fixed in raring?
<ubot2`> Launchpad bug 1196556 in linux (Ubuntu Saucy) "Hot plug events not detected in i965" [Low,Triaged] https://launchpad.net/bugs/1196556
<xnox> apachelogger: first needs to be fixed in saucy, then can be SRUed into raring.
<apachelogger> I am not sure I'd want to do a kernel upload ^^
<apw> apachelogger, has the fix even hit linus' tree yet ?
<apw> i don't see it
<apw> jsalisbury, perhaps one for monitoring ^^
<jsalisbury> apw, ack
<jsalisbury> apachelogger, I'll keep an eye out for that fix in Linus' tree.  I'll submit and SRU for Raring if it does'nt have the CC to stable
<apw> jsalisbury, a star as always
<jsalisbury> apw :-)
<jsalisbury> apachelogger, If you have a chance, can you test the kernel from: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2013-07-01-saucy/
<geekatcmu> Is there an "easy" way for me to find out if/when a particular patch (in this case, the 3.4 XFS accounting patch) was backported into the Precise kernels?
<henrix> geekatcmu: option 1: look at precise git tree; option 2: you can try to use this fancy tool: http://o.cs.uvic.ca:20810/perl/cid.pl
<geekatcmu> Thanks.
 * geekatcmu makes a sad face
<geekatcmu> http://o.cs.uvic.ca:20810/perl/cid.pl?cid=3948659e30808fbaa7673bbe89de2ae9769e20a7 doesn't seem to have been back-ported to the Precise kernel.
<geekatcmu> Thanks, anyway!
<geekatcmu> (it's part of the 3.4 series)
<jxself> apw: That makes me wonder: How is the config generated? Is there some program or[D[D[D[D[D[D[D script or something I can reference?
<jxself> Hmmm. Not sure why that came out like that.
<apw> jxself, we take the config from the release we are targetting and 'make oldconfig' on it with the tree we are building
<apw> jxself, though since the changes i make today it now use the nearest ubuntu version within that release
<jxself> Ah, that's it? OK.
<apachelogger> jsalisbury: will try thanks :)
<geofft> Hm, can I bug people with enablement stack questions here? Or is #ubuntu-devel or something more appropriate? 
<bjf> it's late in the day but it never hurts to ask
<geofft> Basically, I think, 1) when are we expecting to see the -lts-raring graphics stack? (Is it intentional that the -lts-raring kernel exists already?) 
<bjf> yes, it's intentional that the -lts-raring kernel exists already. as soon as raring released, the lts-raring kernel was ready
<geofft> 2) Is there/will there be a corresponding -eol-upgrade package for the graphics stack as well as the kernel? 
<geofft> 3) Is there a metapackage for the latest -lts-whatever? 
<bjf> i'm not sure why there isn't a lts-raring graphics stack yet (i think there will be one). i'd expect a similar -eol-upgrade for graphics as kernel
<geofft> Well, I don't see an xserver-xorg-lts-quantal-eol-upgrade, either, I think? 
<bjf> all the graphics stack folks are in earlier timezones
<geofft> OK, guess the end of the day in California is a poor time to ask questions :) 
<bjf> are you PST timezone?
<bjf> i should know the answers to all of that but i just don't, sorry
<geofft> Yes, and also not a morning person unfortunately 
<bjf> ack
<bjf> so yes, the morning is a better time to reach folks or an email to the ubuntu kernel team mailing list
<bjf> geofft, your PDX ?
<bjf> slangasek, ^ you know the answers for the graphics stack?
<slangasek> mmm, not precisely, sorry
<bjf> s'ok, thought maybe
<slangasek> I do expect the lts-raring graphics stack before 12.04.3, but I don't know if mlaankhorst has started work on it yet
<bjf> ack
<bjf> it's coming up quickly
<slangasek> but what's eol-upgrade?  is that part of the revised plan ogasawara came up with after sabdfl pushed back on the "automatically upgrade users to the supported stack" question?
 * slangasek doesn't know the details on that or where it's documented
<bjf> i think it's so we don't leave people hanging on unsupported lts-hwe installs
<bjf> "in the wiki"
<slangasek> well, in fact the current plan is that people *will* be allowed by default to hang on them
<slangasek> because sabdfl objected quite strongly to having them auto-upgraded to a kernel that might regress hardware support
<slangasek> so instead they'll be notified when their kernel goes eol
<bjf> yes but i thought we were going to provide a "automagic upgrade package" for folks that did want that (but i could have just made that up)
<slangasek> but I don't know if there are meant to be additional metapackages in support of this
<slangasek> maybe so, I don't know :)
<geofft> bjf: SF/Bay Area, actually 
<bjf> geofft, ack
<geofft> slangasek: Yeah, there appear to be no docs about -eol-upgrade other than its own package description. 
<slangasek> right... so you probably want to hit up the person who uploaded it :)
<geofft> Hm, can you use the lts-raring kernel with an older graphics stack? Or is the use case overly-new headless servers or something? 
 * bjf puts money down on who that was
<bjf> geofft, you should be able to use it with an older graphics stack
<slangasek> geofft: can you... yes.  Is it supported/validated... no.  The lts-raring kernel is meant to be used in conjunction with an lts-raring graphics stack, which may just not be packaged yet
<geofft> sconklin, looks like. "* UBUNTU: Provide an EOL upgrade meta package" 
<geofft> https://launchpad.net/ubuntu/+source/linux-meta-lts-quantal/3.5.0.32.39 
<bjf> geofft, that's just the regular lts-quantal meta package
<bjf> geofft, let me see who added that commit
<bjf> geofft, rtg did the commit, he's out this week
<bjf> geofft, in the a.m. ogasawara can give all the details
<bjf> geofft, you missed her by about 2.5 hrs.
<geofft> OK, I'll re-ask tomorrow morning. Thanks! 
<bjf> but email is a "fine" thing for this
#ubuntu-kernel 2013-07-02
<brendand> could it be considered a bug that an invalid character has ended up in sysctl.conf?
<brendand> or does it not really matter?
<brendand> sorry, to clarify - the character is not ascii
<apw> brendand, it would depend on how it got there, which character is it
<brendand> apw, it's a fancy one of these: '
<apw> brendand, when it is the kernel's fault it tends to be larger blocks of characters whcih get added and they tend to be aligned to filessytem block size
<apw> single characters are much less likely to have been the kernel
<brendand> apw, i can only imagine someone copy and pasted text from another document, since you can't (easily) type that character
<apw> yeah probabally an example if it has words open and close ' the slightly angled ones
<brendand> it looks awful when opening the file in any normal text editor:
<brendand> #    0 - don<E2><80><99>t use privacy extensions.
<apw> so is that in each and every version of the file
<apw> brendand, which sysctl file exactly is this in
<apw> brendand, anyhow if it is in the file as packaged, then it could be a bug, though it looks just fine in vi
<apw> brendand, and that file is in procps
<brendand> apw, it's probably not actually. i came across this just now on some ARM hardware (Calxeda)
<brendand> apw, although i see it here on my system too
<brendand> strange
<brendand> i'm just wondering why i'm not seeing the same bug triggered by this as i did on the calxeda
<apw> you are connecting differently and do not have an 8 bit clean utf-8 connection
<brendand> apw, what do you mean by 'connecting differently'?
<apw> something is different about how you are accessing that system such that
<apw> it does not think you are on a UTF-8 terminal, and that character needs one
<apw> if it bothers you then just file a bug and patch against procps and be happy
<brendand> alright, thanks
 * ppisati goes out for a bit
 * henrix wonders why would anyone send 29M emails!
<ogra_> henrix, because 30M might be the send quota at his provider 
<henrix> ogra_: heh, may i should ask IS :)
 * henrix -> lunch
<apw> jjohansen, about ?  your pull-request for maguro seems to have a >>>>> in it
<rsalveti> jjohansen: apw: ogra_: I'm getting http://paste.ubuntu.com/5836282/ with maguro, is that fine or expected?
<ogra_> rsalveti, already fixed
<ogra_> (not uploaded)
<rsalveti> ogra_: is that causing us any harm?
<ogra_> nope
<ogra_> just noise apparently 
<rsalveti> hm, don't see any new commit at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=shortlog;h=refs/heads/maguro
<rsalveti> right, in the ml
<rsalveti> should be in after review, cool
<apw> rsalveti, i think that is the one with a merge conflict in the pull request
<rsalveti> apw: yeah
<apw> ogra_, was the manta aa issue sorted in userspace, ie can i reenable it
<apw> (i ahv the feeling it was ... but i would like to be 100% sure)
<ogra_> apw,, yes, lxc apparmor usage was disabled across the board afaik so it shouldnt interfere anymore
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<hallyn> drat.  deleted $HOME/ubuntu-quantal.git on zinc.  not realizing i was using that as objects alternates in an exported tree.
<hallyn> well, it was getting crufty anyways i suppose.  
<srwarren> If I wanted to build kernel udebs for debian-installer to run on Tegra (NVIDIA ARM SoC), I need to add some drivers into the udebs...
<srwarren> Should I just add them to the "generic" ARM flavor, or create a new flavor (just like OMAP) has?
<srwarren> I assume building all the drivers as modules rather than built-in would be best.
<apw> srwarren, if generic works for that device, then i would enhance that rather than making a new flavour
<apw> i don't think we make any di images for any arm platform at the moment so we would not have tried to get
<apw> the config right there
<srwarren> OK, sounds good.
<apw> hallyn, doh
<srwarren> FWIW, there are generic and omap4 images on the Ubuntu d/l site, and I booted one with a custom kernel and it even installed OK on my Toshiba AC100!
<srwarren> So, if I start fixing up the udeb packaging etc., and send patches, is it likely you'd take the patches into the official sources even though Tegra presumably isn't an officially supported platform?
<apw> srwarren, if we haven't disabled them all together it seems reasonable
<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 July 9th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<srwarren> So, I imagine I might add sdhci-tegra.ko to block-modules. What about modules for core system infra-structure like I2C (for communication with PMICs) and PMIC (Power-Management IC) drivers themselves. Should I create e.g. a new arm-soc-modules/soc-modules/soc-infrastructure-modules/...? There doesn't seem a good existing location for these.  << apw
<srwarren> Another option would be to make them builtin, but by the time N SoCs are supported, that'd be a fair bit of bloat in the core zImage
<apw> srwarren, the d-i stuff has 'fixed' names for things, so i would expect you would want to put them in one of the existing ones
<infinity> BenC: Did you test the raring-proposed kernel on any of your kit?
<infinity> BenC: I'd be happy enough to release it, knowing it works on mine, but since you have an interest in 2/4 flavours, it would be nice to know you've tested those. :P
<infinity> psivaa: Is ti-omap4/quantal running into problems, or is the regression test still ongoing?
<infinity> psivaa: Err, s/quantal/precise/
<smb> infinity, Is there any chance of you finding time to look at crash backports or shall I wait till I can get more personal. :)
<infinity> smb: I'm pretty swamped right now, but I can try. :/
<infinity> smb: Or you can hit me in person in London (and put it on the sprint agenda)
<smb> infinity, Yeah, that was my thinking. You cannot escape then ... and I can try to persuade with beers... though not sure this helps on getting results. :)
<infinity> Beer can produce stellar results.
<infinity> Red wine, moreso.
<smb> results probably... the intended ones, maybe not. But the conversations are... "interesting"
<infinity> I've done some of my best work under the influence of Penfolds.
<infinity> And Belgian Blondes.  I leave it to you to interpret that noun phrase however you prefer.
<smb> Heh, yeah its those where you come back later and admire that genius developer that wrote that shit which incidentally has the same name as you
<infinity> Most of that has more to do with age than innebriation, I think.  I look at stuff I did from 20-25, and wonder where that really smart dude went.
<smb> Yeah, there is that too. :/
<infinity> smb: Anyhow, please do put it on the sprint agenda, and if we get to it before then, we can take it off again.
<infinity> smb: But I think that even if I get to the reviews and we get it all uploaded, we'll want to discuss what we *should* be doing with crash, going forward, since it seems to be vaguely tied to kernel versions, so gets messed up with HWE stacks.
<smb> infinity, sure, yeah
<smb> to both
<smb> One reason to to say heck we just backport latest shit and close eyes
<infinity> Possibly, yeah.
<psivaa> infinity: i once had an issue of corrupted mmc with that, running it for the second time now. will update asap
<infinity> psivaa: Sure, not a massive rush, just noted the task had been running for a while, so prodded to make sure it hadn't been forgotten. :)
<psivaa> infinity: ack :)
<BenC> infinity: works on mine
 * bjf -> lunch
<infinity> BenC: Shiny.
<hallyn> i'm trying to build a kernel with userns fixes for xfs.  it uses inode_capable(), which is defined in kernel/capability.c, in xfs_ioctl.c  xfs is compiled as a module, and capability.o apparently not included, so i get:
<hallyn> ERROR: "inode_capable" [fs/xfs/xfs.ko] undefined!
<hallyn> I don't see any other non-xfs files mentioned in fs/xfs/Makefile...  is there a way to specify that capability.o needs to be built in?
<bguthro> hallyn, you'll need to do EXPORT_SYMBOL(inode_capable) in order to be able to use that in the other module
<hallyn> I thought surely that was already done, but i bet you're right
<hallyn> bguthro: indeed it's not.  thanks!
<srwarren> apw, it looks like d-i can be persuaded to pick up a new modules udeb by editing build/pkg-lists/*, right?
<infinity> srwarren: Yes, though this should generally not be necessary.
<srwarren> In general yes, although I can't see a good fit in the existing -modules.udeb for general SoC infra-structure modules
<infinity> srwarren: Possibly just in the kernel-image udeb itself.
<srwarren> OK, that would make sense. I didn't realize it was OK to dump modules there. Thanks.
<hallyn> jsalisbury: hey, i know you've been involved in the older versions of this, so bug https://bugs.launchpad.net/bugs/1196295 which i'ma bout to mark as affectinglinux may interesting you
<ubot2`> Ubuntu bug 1196295 in lxc (Ubuntu) "lxc-start enters uninterruptible sleep" [High,Incomplete]
#ubuntu-kernel 2013-07-03
<jsalisbury> hallyn, ack.  thanks for the heads up
 * apw yawns
<tjaalton> I guess we don't have debugsym builds for the lts backport kernels?
<tjaalton> *dbgsym
<infinity> tjaalton: We should do.
<infinity> tjaalton: http://ddebs.ubuntu.com/pool/main/l/linux-lts-raring/
<infinity> tjaalton: http://ddebs.ubuntu.com/pool/main/l/linux-lts-quantal/
<tjaalton> infinity: oh of course..
<tjaalton> different source package
<tjaalton> just to clarify, should this work when a dbgsym package is installed? http://stackoverflow.com/questions/6151538/addr2line-on-kernel-module
<tjaalton> what I'm trying is to get the line of code that matches an oops trace
<tjaalton> the gdb approach just says 'no debugging symbols'
<tjaalton> nevermind, used the wrong argument.. needed the one in /usr/lib/debug/lib/modules/..
 * henrix -> lunch
<tjaalton> guess there are no dbgsym packages for mainline kernels?
<tjaalton> would be awesome to have those
<hallyn> hey - is there a signalfd+epoll wizard here?
<hallyn> If I run http://people.canonical.com/~serge/signalfd.c 10 times very quickly, one of the runs will end up hanging because main never gets an epoll event for the sigchild from the first cloned child
<hallyn> the clone is done after the signalfd is set up, so I would expect epoll to fire for that child's sigchld
<hallyn> (when it hangs, the cloned child and its own child both are <defunct>, waiting for parent to reap them...)
<apw> hallyn, you know you cannot do IO in a signal handler right ?
<apw> hallyn, or indeed very little else
<hallyn> apw: but this isn't a real signal handler...
<hallyn> despite the name :)
<hallyn> it runs from main() in the epoll loop
<apw> oh heh
<hallyn> but i'm hoping someone can point out what i'm doing wrong there, before i go to lkml to present it as a possible bug...  somewher ein that stack...
<apw> hallyn, so you clone the children the make the epoll thingy, why is that not racy
<apw> oh i see you make the signalfd first
<hallyn> oh yeah, lemme change that order,
<apw> though i would expect that to behave right i think :)
<hallyn> yeah, but maybe i need to make the epollfd and attach the signalfd first.  Mind you, that *is* being done right int he code I'm trying to reproduce :)
<hallyn> I also apparently inserted the clone block twice
<apw> heh
<apw> post up the fixed version when you have it :)
<hallyn> well, the double clone seems to be the trigger
<hallyn> updated http://people.canonical.com/~serge/signalfd.c
<apw> hallyn, what the heck is the code trying to even do at the bottom
<apw> it seems to be using the number of live fds reported to loop over the signal handler
<hallyn> apw: it's waiting on an epoll event for the signalfd fd, and calling 'signal_handler' on the fd when it arrives.
<apw> yeah but looping over 0 -> nfds and reading for each doesn't make sense
<apw> as only one of them is a signafs
<hallyn> apw: admittedly since i only have one fd the loop seems silly - the more generalized case is in src/lxc/mainloop.c
<apw> signalfd anyhow, and the number returned is not related to the number of signals ... is it ?
<hallyn> right, the number returned is # available fds,
<hallyn> and yes that can only ever be 1
<apw> so for you yes, but for them?
<apw> if this code you have is cut down from theirs i mean
<hallyn> right, there they also add console fds and such
<apw> it seems to be reading the signalfd once per the number of fds they have awake
<apw> that doesn't make sense really does it?
<hallyn> no they call a different handler for each fd type
<hallyn> (one sec, ...)
<hallyn> apw: see mainloop.c in https://github.com/lxc/lxc/blob/staging/src/lxc/mainloop.c
<apw> ahh that makes more sense
<hallyn> apw: if you lxc-start a container with a init which just does exit(0), the mainloop handler often hangs, while init sits around defunct.  i'm trying to reproduce that... 
<hallyn> i'll pull out the inner loop since it only obfuscates the problem
<apw> hallyn, well the original code does have a case (i think) where it can hide an event coming in
<apw> if the handler return non-zero it will silently go back to sleep, it might be worth instrumenting when it does things like that
<hallyn> apw: right, the handler returns 1 if the container init's sigchild was received, 0 otherwise
<hallyn> apw: by 'to sleep' you mean wiating on an epoll event right?
<apw> hallyn, yes to sleep == called epoll_wait and blocks again
<hallyn> apw: I was wondering last night whether the epoll event came in for two siganls, and i was only reading one - but trying another read doesn't seem to help,
<hallyn> and near as I can tell epoll_wait should return again if i haven't consumed all the data
<apw> well in theory if there was two, and you read one and poll again, it should wait again ... yes that
<hallyn> right - unless i was doing edge triggered, but i'm not (EPOLL_ET or whatever)
<apw> hallyn, so the differnce in your code is you should really be doing
<apw> you should be running 'all' the ones it returns and doing
<apw> if (event[N].data == signal_handler)
<apw>   signal_handler()
<apw> just in case it is returning something else
<apw> if there was a bug in which it returned the wrong data, you wouldn't see it with your code as is
<hallyn> wella ctually epoll-wait(0 seems to be always returning 0, even when it has data.  (huh?)
<apw> well if it returned 0 ther should be no data
<apw> you might want to seed the events with poison to confirm
<hallyn> easy enough, when it hangs, just hit ctrl-c :)
<apw> for me this code does behave odd
<apw> oh this is the old old code
<hallyn> hm, i see, 0 means don't wait, that's why i'm getting 0 often.
 * hallyn tries with timeout -1
<apw> yeah thats non-blocking
<hallyn> apw: verifying data ... actually may fix this!  haven't reproduced so far
<hallyn> updated http://people.canonical.com/~serge/signalfd.c
<hallyn> nope, here we go
<apw> how often do you run it to get a hang
<hallyn> with the updated code, 100 times
<apw> for me i got one where it say 'got an event' a lot over and over
<apw> got an event (nfds 1)
<apw> bad epoll event!
<hallyn> right
<hallyn> so why is there a bad epoll event.  weird
<hallyn> am i not initializing something before setting up?
 * apw pokes, at least this would explain the hang
<apw> i think
<apw> anyhow, poking away, as i can repro it as well
<hallyn> doh
<hallyn> apw: nm, that's a bogus one.  i is never set :)
<hallyn> before we check events[i].data.ptr
<apw> hallyn, heh indeed, doh
<apw> and i just got it to hang witht hat fixed
<hallyn> double-doh, though - fixing it (new http://people.canonical.com/~serge/signalfd.c )
<hallyn> yeah
<hallyn> hangs immediately
<hallyn> what's an ascii emoticon for tortured agonizing troll?
<hallyn> apw: well, to my surprise, even replacing clone with fork eventually reproduces it.  that's good i guess.
<apw> hallyn, what are you testing on
<apw> which release
<apw> hallyn, as it seems reproducible on 3.8 (whatever this is)
<hallyn> apw: yeah, raring.  oh, snap, i thought my other vm was saucy, but no i've only tested on raring
<hallyn> wait a sec, i'm marking nonblock wrongly, perhaps
<apw> hallyn, same here
<apw> are you marking anything noblock at all?
<hallyn> apw: yeah (refresh http://people.canonical.com/~serge/signalfd.c  :)
<hallyn> apw: i was doing it with fcntl for awhile, but then saw that signalfd takes a SFD_NONBLOCK flag
<hallyn> anyway, doesn't fix it
<hallyn> so the signal really really does seem to just get lost
<hallyn> ok lemme try on saucy
<hallyn> or, uh, precise
<hallyn> happens same way on precise
<apw> hallyn, so it always hangs when it gets the other exit first right?
<hallyn> yeah
<hallyn> apw: no
<hallyn> sometimes it gets the other exit first and still succeeds
<hallyn> but every time it fails it does first get the other exit
 * apw isn't seeing that, but it is hanging very quick for me
<hallyn> apw: http://paste.ubuntu.com/5840986/  here is an example
<apw> it does feel like it is behaving like it is ET
<apw> yeah
<hallyn> apw: but then i'd expect my looping of the read to fix it
<apw> yep that we would
<hallyn> apw: d'oh.  
<apw> hallyn, ?
<hallyn> signalfd() does not do flags.
<hallyn> wonder if signalfd() library call uses signalfd4(0 syscall
<apw> oh
<hallyn> yeah strace says it uses signalfd4
<apw> and mine is seemingly non-b
<apw> blocking
<apw> so doesn't that mean it does work
<apw> waiting ...
<apw> got an event (nfds 1)
<apw> got sig for 20171, init was 20173
<apw> failed to read signal info errno=11
<apw> failed to read signal info errno=11
<apw> waiting ...
<apw> for me it does that, on a hang, so it saw the wrong pid, read 3 times (two failed cause nothing there) and then we went back
<hallyn> but why 2 in a row failures?
<hallyn> it should only fail once, then return to the epoll-wait loop
<hallyn> apw: that printf looks differnet from mine
<hallyn>                 perror("read");
<hallyn>                 printf("errno is %d\n", errno);
<hallyn>                 if (errno == EAGAIN || errno == EWOULDBLOCK)
<hallyn>                         return 0;
<hallyn>                 printf("failed to read signal info");
<apw> yeah it is mine indeed
<hallyn> ok
<hallyn> i'm tempted to ping mkerrisk
<hallyn> mind you the corresponding lxc bug has been somewhat low priority for me, but i thought we were doing something more wrong than this...  if it's a kernel or libc bug i think it's a bigger deal
<apw> hallyn, i'll keep poking for a bit too
<apw> hallyn, of course it might be a bug in signalfd not epoll, hmm
<hallyn> apw: yup
<hallyn> apw: that's why i was happy that fork could reproduce it - at least it doesn't involve CLONE_NEWPID as well :)
<apw> hallyn, and it might be an alignment issue, as it is random and we have address psace randomisation on
<apw> as SIGCLD is one of the large ones in that structure
<apw> so if the structure was too small, and aligned bad or something
<apw> or too big or something
<apw>         struct signalfd_siginfo __user *siginfo;
<apw> if that isn't the same size as the one in the kernel ... we might fail
<apw> as if we dequeue it and then fail to return it ... we just lose it
<apw> hallyn, what makes you think (i assume you have docs somewhere) that just because you are using this interface that you can guarentee to see all signals ?
<apw> hallyn, as you say when it hangs you can see that you have pending children events
<apw> hallyn, are you sure you can expect to see both signals as separate events with separate children ?
<apw> hallyn, would i not expect you to actuall ignore the siginfo and use wait to get the childre
<apw> hallyn, and there i htink i would expect you to get both as they are there waiting to be waited for
<apw> hallyn, ie reading signalfd is _not_ waiting for them nor reporting them
<apw> hallyn, and you need to wait to clean them up regardless
<hallyn> interesting
<hallyn> so i have to waitpid() on the first to clear it up before i can get a sigfd for the second sigchld?
<hallyn> lemme try
<hallyn> it makes sense
<hallyn> (and it briefly came to mind last night, but i figured "nah!" :)
<apw> hallyn, no i am not saying you have to waitpid to clear it
<apw> hallyn, i am saying that signalfd is reporting pending signals
<apw> and pending signals with their 'latest' siginfo
<apw> but if you get two signals of the same type only the last one will be reported
<apw> that is normal for signals and siginfo
<apw> i am syaing when you get a signal, you should be looking on wait (with NOWAIT) and using
<hallyn> i see
<apw> the data it returns
<apw> as the pids not anything int he siginfo.
<hallyn> so i (and the original author) am (is) completely misunderstanding sigchld delivery
<apw> as we see both as zombies i bet money that you will find two waits
<hallyn> i did indeed assume i'd get N sigchlds
<apw> that is not normal with signals at the process level for sure
<apw> now signalfd could have either semantic and it does not say which
<apw> but if we conjecture it has the smae semantics as signals
<apw> and the way POLLIN is calculated i suspect it is
<apw> then you may not indeed, but a looping wait should always be sage
<apw> safe, and i think you need to be waiting anyhow to clean up the carcasses
<apw> so if i am right, a wait loop will repair things, if it is broken
<apw> then it will only ever have one and make no differende
<hallyn> apw: thanks - final signalfd.c testcase uploaded - this one doesn't seem to reproduce.  seems you were right!
<hallyn> now i can fix lxc :)
<hallyn> \o/
<hallyn> thanks apw
<apw> hallyn, heh... there is point in having a kernel team after all :)
<apw> hallyn, and i am glad we got to the bottom of it
 * hallyn goes to take a walk outside before writing the actual patches
<apw> hallyn, i know the feeling, i think i need a beer after thinking that hard
<hallyn> that sounds.  good.
<apw> hallyn, ok .. you need to break that loop for == 0 i think
<apw> as it spins in there till they exit otherwise
<apw> hallyn, and waitid() may be a more natural fit for your code base maybe
<apw> hallyn, switching your loop from >= 0 to > 0 still seems to work
<apw> and removes the repeated looping returning 0
<apw> got sig for 2791, init was 2793
<apw> waitpid ret=2791
<apw> waitpid ret=2793
<apw> got init's sigchld: done
<apw> hallyn, and we see the pattern there which i conjectured .. coool
<apw> beer it is
<hallyn> apw: (drat, no beer for me) do you have a copy of your final one you can post?
<hallyn> curious which loop you ended up going with
<hallyn> apw: oh, right, i misread the == 0 return value case!  lol
<hallyn> "... in any state" well that does me no good :)
<hallyn> waitid is too foreign to me :)  i'll muck it up somehow
<apw> hallyn, that version of yours looked ok once it was >= 0 :)
<apw> > 0 even
<hallyn> getting ready to test the lxc ase
<hallyn> lxc case
<hallyn> hm, not a slam dunk fix.
<hallyn> odd 
<apw> hallyn, ?
<hallyn> apw: added the waitpid loop into signal_handler in lxc, but lxc-start still ends up with defunct init 
<hallyn> so i'm missing something else that's going wrong there
<apw> sounds like a tommorrow fun
<hallyn> tomorrow's a holiday here - but ttyl
<apw> hallyn, drop me a line if you have any other examples to play with and i can look at it tommorrow
<hallyn> thx
<seb128> hey
<seb128> is there any issue with the saucy 3.10 kernel and screen light?
<seb128> changing it using the multimedia keys hangs my latitude laptop for a second
<seb128> where it works fine with 3.9
<apw> seb128, noting i have seen reported
<seb128> apw, hum, ok
<seb128> apw, is there any special info that would be useful in a bug report?
<apw> seb128, h/w info which ubuntu-bug will collect
<seb128> ok
<seb128> that's a latitude e6410
<hallyn> apw: well huh - particularly interesting in the lxc case is that after i call the parent task, the [init] task remains defunct, while parented by 1
<hallyn> *that* probably shouldn't happen
<apw> hallyn, if you reap a parent before its child then its children go to init don't they ?
<apw> you could test that
<apw> with a basic fork test
<hallyn> apw: (not sure i was clear)  i'm saying:  root      1878     1  0 21:32 pts/2    00:00:00 [init] <defunct>                                   
<hallyn> '[init]'is the container init, which has exited;  it's now parented by the host init, but is still rockin' the zombie life
<apw> right so noone has waited for it
<apw> have you waited for its parent
<hallyn> bc it's not sending a new sigchld?
<apw> that is not what i mean
<hallyn> i figured init would reap zombies regardless of whether it got a sigchld
<apw> oh i see
<hallyn> i killed its parent, and the parent is gone.
<apw> right so yes it should jump to real init, and that should be reaping it 
<apw> that is its job
<hallyn> all right i'd better step away a few hours.  sorry if i pulled you away from that beer :)
<apw> hallyn, that seems wrong, and in the first place i would be blaming init itself, which we cannot trace easily hmmm, i wonder if --verbose would give us any info
<hallyn> apw: but as i say if the exiting task has already sent its sigchld, then gets reparented to init, then init won't get a sigchld - 
<hallyn> i'd actually expect the kernel at that point, instead of reparenting, to just reap ...  
<hallyn> (i guess that's nonsense-talk)
<hallyn> so upstart would need to walk its pid list and check for zombies... which is not efficient.  still, yeah, cleaning up after bad users is its job...
<hallyn> this should be trivial to write a test case for :)  will do so later
#ubuntu-kernel 2013-07-04
<ppisati> brb
<apw> hallyn, i assume you rocked on it and things are good
<tjaalton> trying to build a useful dbgsym package from a custom branch, but I always end up with stripped modules
<apw> tjaalton, as in you don't get a .ddeb package at all ?
<tjaalton> I do, but the .ko's are stripped
<apw> as ddebs are disabled by defualt when not building on a buildd, full_build=true to get the buildd experience
<tjaalton> ok, I tried AUTOBUILD=1
<apw> tjaalton, which release are you testing
<tjaalton> building on raring, drm-intel-nightly
<tjaalton> plus the packaging from.. dunno
<tjaalton> "fresh"
<tjaalton> got it from Sarvatt :)
<apw> is that you trying to rebuild the mainline builds ... oh ok
<tjaalton> yeah
<apw> well i'd try full_build in case, and in parallel i'll build saucy tip and check
<apw> make sure it is not systemic, people tend to not notice the ddebs have gone to hell until months after release
<tjaalton> those should end up in the parent dir
<apw> i mean if the contents have gone to hell
<apw> we had totally empty ones for some months :)
<apw> back in lucid
<tjaalton> ah
<apw> i'll ask gomeisa to do the do on it and have a peek inside for a change :)
<tjaalton> would it be possible to create ddebs for mainline builds too?
<tjaalton> I know they are huge..
<apw> they are massive, they are 10x the size of the originals
<tjaalton> yup
<apw> technically it is possible i am sure, but ... woh, i am not sure we have the space to keep them
<apw> very long, and we keep the mainline builds 'in perpetuity' in theory
<tjaalton> well, if I can get this working probably not needed
<tjaalton> i mean, if it's easy to recreate one
<apw> it should be, i recreated a lost one from the archive and it worked with the binaries from that release
<tjaalton> alright
<apw> tjaalton, i'll get back to you when i have built this one
<apw> tjaalton, also if it works i might be able to checkout the actual tree used for that build and make a ddeb for it, if it is a mainline you are testing
<apw> tjaalton, in principle if you are only caring for the dirty upstream trees, the ones which are frankly likely to blow up and eat your lunch, we might be able to enable them for those only
<apw> anyhow ... build is in progress so i'll let you know what i find
<tjaalton> heh, right
<tjaalton> I'm building too, race you to it :)
<apw> tjaalton, hopefully my builder is bigger than your builder, else i will hjave to sulk
<apw> tjaalton, though obviouly you are building what you wnat, and mine is only a build for the master tip to make sure we haven't knobbed it
<tjaalton> just my ivb desktop
<tjaalton> but full build, maybe I'm missing some bdeps for the tools or such
 * apw curses henrix who is wrecking my race :)
<henrix> apw: ?
<apw> nothing, just joshing you
<henrix> heh
<apw> henrix, making gomeisa go slow
<henrix> apw: ah! i can cancel my job if you have something urgent ;)
<henrix> apw: just doing routine builds on 3.5
<apw> henrix, nothing urgent at all ...
<henrix> apw: :)
<apw> henrix, and i have like 4 other machines if it was
<apw> and 'slow' means 12m instead of 8m not life ending
 * henrix goes back to UEFI backports fun
<apw> henrix, yeah it looks like you have some real untestable backports to do there, good luck with that crap
<henrix> apw: i have the backport already... i'm just trying to make sure i won't have people hitting me with bricks in a few weeks :)
<apw> henrix, literally :)
<apw> tjaalton, ok my .ddeb has come out at 47M so i suspect something has broke
<tjaalton> ha :)
 * apw will poke it and let you know
<tjaalton> thx
<tjaalton> tried a full build and it failed, also on sbuild:
<tjaalton> make[1]: Leaving directory `/Â«PKGBUILDDIRÂ»/debian/build/tools-perarch/tools/power/x86/turbostat'
<tjaalton> make[1]: *** No targets specified and no makefile found.  Stop.
<tjaalton> although it might be result of the way I run clean
<tjaalton> so nevermind
<apw> tjaalton, hmmm no that is tools which needs a couple of patches against mainline to even have a makefile
<tjaalton> ah, ok
<apw> tjaalton, i probabally should suck that stuff up into the main debian packaging ... arse
<tjaalton> heh
<apw> do_tools=false will drop them
<tjaalton> yeah
<stgraber> apw: I've just been told by the lttng guys that their code now builds fine against 3.10 (I noticed it got disabled with the switch to 3.10 in Ubuntu)
<cyphermox> sforshee: hey
<cyphermox> sforshee: I seem to be missing a device for bluetooth on mako -- ttyHS0.
<cyphermox> ttyHSL0 shows up, but for some reason although CONFIG_SERIAL_MSM_HS=y, it still doesn't get brought up, would you be able to help me figure out why?
<cyphermox> quickly looking I wonder if it couldn't be because some other piece is missing, like perhaps that CONFIG_SERIAL_MSM_SMD
<cyphermox> nevermind that
#ubuntu-kernel 2013-07-05
<hallyn> apw: no, yesterday (today still i guess) was a holiday.  i'm thinking tomorrow ill compile a kernel to figure out where sigchld is going and maybe figure out why I'm losing it
<ppisati> brb
<infinity> apw: Is there a master upload in the pipe today?
<apw> infinity, i don't think we have anything, we are in merge window anyhow
<apw> infinity, but i will check
<infinity> apw: Kay.  I need to do a d-i upload for other kernels, but was holding off until I knew if master was landing too.
<apw> infinity, would you like there to be :)  there is an INTEL_MEI fix pendgin which might be worth having
<infinity> apw: I don't care one way or the other, but if you have pending stuff, go to town.
<apw> infinity, ok will do
<infinity> apw: Oh, not sure if it was intentional, but the flipped state of intel_pstate got reverted between 3.9 and 3.10.  My laptop seems to be behaving a bit better with it this time around, but I'll keep an eye on it.
<apw> infinity, the kernel autoremove stuff, it only removes things which leaves them configured, is there any nice way out of that
<infinity> apw: "Which leaves them configured"?  I'm not sure what you mean.
<apw> infinity, i don't think i applied it to 3.10 to allow us to find out, but yes
<apw> infinity, as in after autoremove all the old kernels remain 'rc' in the dpkg listing
<infinity> apw: Because you're not purging.  Same as any package removal.
<infinity> apw: apt-get --purge autoremove
<apw> infinity, my machine is too much of a mess to prove to myself whether that worked or not (as i just tried it), so i'll clean it up now by hand and watch for the next one
<infinity> apw: And, in your case, "dpkg -l | awk '/^rc/ {print $2}' | xargs dpkg -P" to purge old stuff you've only removed.
 * apw tries that ... well the machine stil there :)
<apw> man these machines build up some cruft and no mistake
 * apw watches dpkg free 3G of space :)
<cking> apw, especially when one has a load of chroots installed
<apw> cking, all true
<cking> henrix, just completed a 4 machine soak test on your patches, seems OK to me
<henrix> cking: \o/
<henrix> cking: thanks a lot for testing
<cking> henrix, see my email for more details and caveats :-)
<henrix> cking: great, i'll take a look
<cking> henrix, i've had 4 machines grinding away since 6.30am today :-)
<henrix> cking: wow! and no bricks at the end! :)
<cking> well, I did kill my intel developer box last night because I was manually faffing with some EFI vars.. so .. well, not 100%
<henrix> cking: heh, cool! :)
<henrix> cking: anyway, i'll be sleeping better now knowing my patches survived your testing ;)
 * ppisati -> out for lunch
 * henrix -> EOW
 * rtg_ -> lunch
 * rtg_ -> EOW
#ubuntu-kernel 2013-07-06
<zio-bernie> hello! I hope this is the right channel: I have a question, is it safe to upgrade to linux-generic-lts-raring without the xserver-xorg-lts-raring (I don't see this in the repos)? I'm using a 12.04 release with kernel version 3.2  and proprietary nvidia driver version 310
#ubuntu-kernel 2014-06-30
<mork> anyone here?
<apw> yes ... not you, but yes
<davmor2> mork This is Awson 
<apw> heh
<apw> smb, so i think the ip6_hold locking there is still ok, but you seem to have a point about RCU on the second existing caller.
<apw> smb, i've replied on the mail thread with my reasoning
<smb> apw, Hm, I just read one reply which seemed to concern only the locking
<smb> Ah here comes number 2
<apw> smb, yeah that was to tim's query.
<rtg> I've kind of lost the thread on that patch. On the other hand. the author has not replied in 2 weeks, so maybe nobody really cares ?
<smb> apw, Yeah ok looking at it that way it should be safe through holding that reference in the timer case. But the unlocked function is also called from those two changing functions now
<smb> rtg, it could be that ipv6 is still rather rarely cared about (except by apw maybe... ;)) 
<apw> i don't really know why anyone would bother to switch that option, let alone care about it admittedly incorrectly dropping the addresses and putting them back
<apw> i also will note that in the current kerenel it doesn't drop the addresses at all as you might be using them, and ismply lets them expire naturally
<rtg> apw, I'm inclined to just let it die unless someone who cares appears.
<apw> rtg, tend to agree.  i suspect that the fix is safe, for non-lowlatency kernels just because rcu lock is baslically a noop
<smb> I would agree especially since I have the feeling the locking / ref-counting is not right
<rtg> alright, consider it ignored
<smb> apw, Should we care to add a note abotu that in the bug report?
<apw> smb, i think you just volunteered
<smb> apw, And with we I mean you, so the comment is parsable and not accidentally rude
<apw> damn you
<apw> ok done, though i was terse :)
<smb> apw, at least not _accidentally_ rude. :D
<tseliot> rtg: I've just uploaded a fixed nvidia 173. I think all my packages should ready now
<rtg> tseliot, thanks
<arges> If I do this: echo '<2>testing' | sudo tee /dev/kmsg  ... I should expect a priority 2 message exposed via 'dmesg -r' right?
<arges> rtg: bug 1274444
<ubot5> bug 1274444 in linux (Ubuntu) "echo string to /dev/kmsg fails to appear on /var/log/syslog" [Medium,In progress] https://launchpad.net/bugs/1274444
<pkern> The ABI guarantee is that an old version of the module works with a new kernel of the same ABI. Is that actually true with precise w/ lts-trusty -> trusty upgrade? Does the newly built kernel (higher version) share the same ABI?
<rtg> pkern, nope, different toolchain
<infinity> Changing toolchain shouldn't (usually) change ABI, though.
<infinity> But I guess we also don't attempt to test/verify that lts == master.
<sforshee> smb: since you're an skb expert now would you mind giving http://paste.ubuntu.com/7727065/ a review?
<sforshee> I think you looked at it once before, but I made a couple of changes
<smb> sforshee, Sure (though I would never dare to call me anything near an expert when it comes to that skb stuff)
<sforshee> smb: well, more expert than me at least
<smb> sforshee, Huh, I am not the one that writes patches for it. :)
<pkern> rtg, infinity: So that breaks the upgrade assumption and does not trigger dkms rebuilds?
<infinity> pkern: Quite possibly, yeah.  I'd be willing to bet the ABI doesn't actually change, but we definitely don't test for the truth of that.
<infinity> pkern: For in-archive dkms modules, they'd tend to be upgraded too, so it might just be self-solving, depending on apt ordering, but local modules wouldn't be so lucky.
<infinity> pkern: Possibly too late to think about clever hacks and workaround for precise->trusty, but perhaps worth a long, hard think for trusty->16.04
<pkern> infinity: Yeah, it's a local module that had some trouble.
<mjg59> Anyone know when overlayfs got xattr support in Ubuntu?
<rtg> apw, ^
<apw> mjg59, at least precise
<mjg59> apw: Ok. So it's some other layer that's giving me EOPNOTSUPP on lsetxattr().
<mjg59> (sigh selinux)
<hans109h> Just a reminder that it would be nice if the fix in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981 was packaged into a commit....please...
<ubot5> Ubuntu bug 1313981 in linux (Ubuntu) "Kernel disabling serial port ttyS0 on boot" [Medium,Confirmed]
<infinity> apw: ^-- Looks like you have the most recent context on this.
#ubuntu-kernel 2014-07-01
<simplify> (I'm new to using IRC chat, btw.) Hello, I get an error while building the Precise 12.04.4 kernel in a VM, and also on the host system (a laptop). The same error has occurred at a different (I think) file each time during the compile process. I need help, and I haven't found any solution on the web. (and I found only one person asking about an issue with these symptoms on the web.) On the laptop I am building linux-lts-
<simplify> raring-3.8.0, and in the VM I'm building linux-lts-saucy-3.11.0. The only change I have made in the amd64 kernel configuration is specifying the location of the dsdt.aml file. Here are the applicable lines of (error) output:
<simplify>   CC [M]  fs/xfs/xfs_ioctl32.oâ¤
<simplify>   LD [M]  fs/xfs/xfs.oâ¤
<simplify>   LD      fs/built-in.oâ¤
<simplify> make[1]: *** [sub-make] Error 2â¤
<simplify> make[1]: Leaving directory `/home/luc/linux-lts-saucy-3.11.0'â¤
<simplify> make: *** [/home/luc/linux-lts-saucy-3.11.0/debian/stamps/stamp-build-generic] Error 2â¤
<simplify> luc@ubuntukernel:~/linux-lts-saucy-3.11.0$â¤
<simplify> Linux ubuntukernel 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linuxâ¤
<simplify> By the way, I followed these instructions: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<apw> simplify (N,BFTL), there would likely have been an error before that one ... look back for eror
<apw> Bharat (N,BFTL), yes you should file a bug and try and describe "not responsive" in more detail
<diwic> oookay... so I used the --no-signed-off-by-cc switch and yet git sends cc to Intel and tiwai...?!
<rtg> diwic, --suppress-cc=all
<diwic> rtg, right
<diwic> rtg, I'll remember that for next time
<rtg> I've done it a couple of times
<diwic> the thing is, with this switch it didn't even ask. It just sent the emails
<diwic> but actually maybe there was some sense to it after all
<diwic> maybe tiwai didn't get htem
<diwic> just the patch author
<rtg> it is kind of the default workflow
<lpwrobin> test irc
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<arges> rtg: how do we verify intel-microcode updates? just install and reboot?
<arges> iff you have intel hardware
<rtg> arges, lemme check on a SNB server that I have
<arges> rtg: no hurry. just wondering how its done 
<rtg> arges, I just load the package and look in dmesg
<rtg> arges, there isn't anything in -proposed ?
<arges> rtg: well i just accepted it.. so may take a bit
<rtg> ah, well I'll just have to be patient
<arges> : )
<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 July 8th, 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.
<rtg> rsalveti, all of the touch kernels have been refreshed with CVE updates, etc. You can find them at https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=utopic
<amitk> rtg: just curious, how many touch kernels do you have?
<rtg> amitk, flo, goldfish, manta, and mako
<amitk> rtg: these are google devices?
<rtg> amitk, all except goldfish which is the Android emulator kernel
<amitk> *google device codenames?
<rtg> Nexus, Nexus 7, and Nexus 10
<amitk> rtg: anything that is newer than 3.4?
<rtg> nope, all are 3.4
<amitk> rtg: any plans to support nexus 5?
<rtg> amitk, not to my knowledge, but then I'm not really driving the platform selection either.
<rtg> amitk, ogra_ probably has better info then I do
<ogra_> amitk, we have a nexus5 build but dont support it officially 
<amitk> ogra_: thx, will check it out one of these days
<ogra_> amitk, http://2buntu.com/articles/1489/installing-ubuntu-touch-on-a-nexus-5/
#ubuntu-kernel 2014-07-02
<jdesfossez> Hi, when compiling external modules for a Ubuntu kernel, is it possible to detect that the target kernel is a Ubuntu kernel ?
<jdesfossez> some kind of version include or something like that
<apw> jdesfossez, we have reently added a version thing for that, and UBUNTU_ABI in a header
<apw> not sure how far back it was applied
<apw> UBUNTU_RELEASE_ABI
<jdesfossez> apw: oh nice, is it in trusty ?
<jdesfossez> apparently not
<apw> jdesfossez, it will be in the next update in trusty
<jdesfossez> ah great !
<apw> jdesfossez, also i don't know if you can see CONFIG_VERSION_SIGNATURE in your module, that is ubuntu specifici
<apw> and that has "always" been in there
<jdesfossez> nice, I wasn't sure if it was Ubuntu specific
<jdesfossez> I should be able to include this file, I'll give it a try
<jdesfossez> I hope it will fix a bug we are having right now with LTTng kernel modules since this patch has been backported to Ubuntu 3.13.0-x http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=f131dbbef24a58bb43bbd54119d9b2dad478f21f
<jdesfossez> apw: CONFIG_VERSION_SIGNATURE is in .conf file, it seems tricky to import inside our macros, we will have to wait for UBUNTU_RELEASE_ABI to fix this
<apw> jdesfossez, i don't th
<apw> jdesfossez, i don't think you have to include anything do you?  as yu can #ifdef CONFIG_SMP and stuff in modules without direct action
<apw> it is a config just the same, #ifdef ought to work on it no ?
<jdesfossez> ah maybe, I'll try that
<jdesfossez> ok, I can use it, I'll try to cook a patch for that
<jdesfossez> thanks !
<apw> sadly its not in a form you can check numerically, which is why the ABI was added
<jdesfossez> do you think UBUNTU_RELEASE_ABI will be backported to 12.04 also ?
<apw> bjf, ^ ??
<bjf> apw, i can't think of any reason it can't be
<apw> bjf, i guess if it is in 12.04 and 14.04 kernels soon that will be all of them
<jw12000> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981  Just looking for an update?
<ubot5> Ubuntu bug 1313981 in linux (Ubuntu) "Kernel disabling serial port ttyS0 on boot" [Medium,Confirmed]
<apw> jw12000, i've not had a chance to chase up on my chain today
<apw> it is on my todo list, and is already red from inaction
<jw12000> apw:  Thanks much.  I'll stop bugging you for a while.
#ubuntu-kernel 2014-07-03
<Kano> Hi, could somebody add aufs to 3.16 git?
<Kano> And maybe disable pstate by default
<ali1234> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305522
<ubot5> Ubuntu bug 1305522 in linux (Ubuntu Trusty) "Backport Synaptics HID touchpad driver for 14.04" [Medium,Fix released]
<ali1234> i noticed that those changes caused an issue with some touchpads
<ali1234> i suspect they are causing an issue with oculus rift too
<ali1234> qoute from their dev forums: "If you are also running Ubuntu 14.04, you are probably on kernel version  3.13.0-29 as well. For me the oldest available kernel is 3.13.0-24. By  using this kernel, the drifting issue disappears"
<ali1234> the only changes to HID during that period were related to this bug
<ali1234> specifically i think this commit broke it: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=aa6c390c4d59c9ff4fffd887e15783b2b793951b
<hallyn> gah.  utopic kernel still hangs (complete hang, no working sysrq-b) every few hours for me, requring fsck;  nothing in syslog, ever.  wish i could file a meaningful bug
<apw> hallyn, try the 3.16 kernel in the ckt PPA
<ProfessorKaos64> is this bug ever going to be assigned for kernel fixes? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1326725
<ubot5> Ubuntu bug 1326725 in linux (Ubuntu) "PS3 Sixaxis controller/joystick usb stopped working, regression in linux-image-extra-3.13.0-27-generic" [Medium,Confirmed]
<hallyn> apw: ok, will do
<apw> ProfessorKaos64, looks like jsaulisbury is helping on that one
<ProfessorKaos64> I don't see his name on there. Just checking since this is a decent regression it seems
<ProfessorKaos64> Ah, nevermind I see him now. I'm sorry
<hallyn> ok, booted into 3.16
<hallyn> now let's poke it with a stick
#ubuntu-kernel 2014-07-04
<ali1234> bug 1337641
<ubot5> bug 1337641 in linux (Ubuntu) "Oculus Rift "drifts" on recent kernels" [Undecided,Confirmed] https://launchpad.net/bugs/1337641
#ubuntu-kernel 2014-07-05
<trippeh> Hm. Something something module autoloading during initramfs seems to be borked with kernel 3.16-git (upstream)
<trippeh> On 14.04
<apw> trippeh, any specific module?
<trippeh> ahci.ko didnt get loaded, but loads fine on modprobe after dropping to initramfs-shell. I still cant get it to finish boot though, seems like something related to dm-crypt is failing too.
<trippeh> so I'm guessing something is just rong with autoloading in general
<trippeh> 3.15.4-rc with similar config works fine.
<trippeh> Hm. udev is supposed to start during initramfs right?
<trippeh> hmm. starts ok if I start it manually within the initramfs shell
<trippeh> odd.
<trippeh> udev didnt start by itself, but only with 3.16
<trippeh> onto something
<trippeh> oh. /sys/kernel/uevent_helper seems to be gone, making the udev initramfs script fail before starting udev.
<trippeh> -CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
<trippeh> +# CONFIG_UEVENT_HELPER is not set
<trippeh> heh :)
<trippeh> silly me
<trippeh> kernel says "should not be used today"
<trippeh> I'm thinking maybe the echo > /sys/kernel/uevent_helper is a relic of the past
<trippeh> udev started and worked fine without it.
<trippeh> ah yes. the echo is to disable it.
<trippeh> but when disabled in the kernel build anyway, it doesnt exist anymore.
<trippeh> so I guess it should have a if it exists, then try disabling it.
 * trippeh rambles on
<trippeh> wrapped it in a if and now it boots cleanly
<phillw> scary things, these kernels!
<trippeh> will re-enable the legacy kernel option and file a minor bug on initramfs-tools
<phillw> trippeh: are we sticking with 3.15 for 14.10 release?
<trippeh> not sure, I'm just an observer who breaks things :)
<phillw> trippeh: ahh, I'm similar... I have a non-pae 3.13 kernel which I've added the aufs patches to :)
<trippeh> err, its udev that should get the bug
<trippeh> $ dpkg -S /usr/share/initramfs-tools/scripts/init-top/udev 
<trippeh> udev: /usr/share/initramfs-tools/scripts/init-top/udev
<trippeh> probably not worth fixing in 12.04/14.04, as its a non-ubuntu-standard configuration
#ubuntu-kernel 2015-06-29
<melodie> hi
<melodie> I need to report a bug which is in the Ubuntu kernel and affects the behavior of the zram-config script. I hope this one will be a lucky #bug:
<melodie> https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/1449678/comments/13
<ubot5> Launchpad bug 1449678 in zram-config (Ubuntu Vivid) "(Vivid) zram-config 0.3 Job for zram-config.service failed" [High,Fix committed]
<melodie> I'll be around
<melodie> any one having the right method to advice me about reporting the issue linked to kernel is welcome to tell me how
<apw> melodie, if there is a kernel component, then the bug should be "Also affects Distribution/package" linux
<melodie> apw let me see...
<melodie> apw and think : this does not affect the behavior or usability of the kernel. It's the way the compiling options have been treated which generates the bug
<apw> melodie, i am not sure what the bug even is really from the report
<melodie> zram_lz4_compress=y and config_zram=m
<melodie> the original bug:
<melodie> the zram-config script (vivid hence with systemd) was not working right
<melodie> after a debug I did, Didier Roche was able to correct it, but I still had only one zram block created and having 100 as priority, instead of 2 block devices (I have a dual-core) and 5 priority. 
<melodie> it appeared when seeking for the source of the issue that I could not even unload it: it was used by config_zram_lz4. 
<apw> why does the number of cpu's you have have any relevance to the number created ?
<melodie> apw it has
<apw> why ?
<apw> they are ram compressed disks, how does that relate to how many cpus i have
<melodie> believe me or check with the compcache original project and the zram-config script
<melodie> this is how it is supposed to work
<apw> /* Module params (documentation at end) */
<apw> static unsigned int num_devices = 1;
<apw> well the source code defines it to be 1, always
<apw> unless it is overridden, so they don't take number of cpus into account
<apw> not indeed do i understand why the defaults would
<ogra_> it used to 
<ogra_> not sure it still does though 
<melodie> anyway the scripts I use have always stated one block device per cpu and the present script has not changed that part
<ogra_> and comparing todays zram with the ancient compcache wont give you much valid info i fear 
<melodie> and this is how I suspected that the zram module was loaded at boot instead of letting the zram-config script do it's job
<melodie> ogra_ hi 
<ogra_> well, but probably the code in-kernel changd
<ogra_> *changed
<melodie> ogra_ I have followed your advice and went to Didier Roche directly.
<ogra_> :)
<apw> ogra_, well the default in P was 1, and the default in vivid is ... 1
<apw> so its not changed as far as i can see
<melodie> now his script works for me, but only as long as I blacklist zram in the blacklist.conf file
<apw> "his" ?
<ogra_> apw, hmm, in precise it definitely created one per core 
<melodie> so you devs do what you want with the information : if you want to get all Lubuntu users come and yell later, it's up to you
<melodie> apw yes, Didier Roche version which switches the former script to systemd method
<apw> ogra_, its not clear how it could do that, from the code in precise
<melodie> ogra_ apw I summarized here: <melodie> https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/1449678/comments/13
<ubot5> Launchpad bug 1449678 in zram-config (Ubuntu Vivid) "(Vivid) zram-config 0.3 Job for zram-config.service failed" [High,Fix committed]
<melodie> this is what I see and this is what you  get :D
<melodie> I don't have your skills at reading the source code from the zram module, I just do my best as a tester. :)
<melodie> and I have been using compcache/zram since 2006. :)
<apw> yep, and i am simpy trying to understand what is going on
<apw> as clearly the code does not do what is claimed, so as you clearly see the behaviour something else must be doing it
<apw> does not internally do what is claimed
<melodie> apw simple: if zram is not blacklisted, the zram-config script, which allows loading it with some well thought options, and allows choosing wether or not use zram does not work;
<melodie> so the actual setup of the kernel configuration file makes the existence of the zram-config pointless.
<melodie> and does not leave the choice to the administrator : with or without? with or without custom choices? no choice !
<melodie> just take it or blacklist it.
<apw> melodie, yes sounds broken, so ... why did it work before, or more specifially
<melodie> apw I can try to help you with that if you are one of the persons taking care of it?
<apw> i assume the scripts assume the module is not loaded, and for "reasons" it is loaded
<apw> what the heck is loading it
<apw> it doesn't sound like it should be really unless you need it
<melodie> I try to extract an information lost in my messages, wait a sec please
<melodie> apw compare the result on the cat /proc/swaps in #13 with what I got when zram was default loaded:
<melodie> $ cat /proc/swaps
<melodie> Filename Type Size Used Priority
<melodie> /dev/zram0 partition 947216 0 5
<melodie> $
<apw> ok cirtianly the scripting just makes the assumption it is not attached
<melodie> and I now try to find another key information I posted
<melodie> ok, got it:
<melodie> when zram was default loaded (not with the script):
<melodie> $ lsmod | grep zram
<melodie> zram                   24576  1 
<melodie> lz4_compress           16384  1 zram
<melodie> $
<melodie> this is in the mail I sent to Didier Roche 2 weeks ago
<melodie> now with the script working while zram is blacklisted:
<melodie> # lsmod | grep zram
<melodie> zram                   24576  2 
<melodie> lz4_compress           16384  1 zram
<melodie> #
<melodie> when I saw that first, my thought was that lz4_compress was calling it while the boot occurred. I may be wrong, I have very little experience of fiddling with the kernel (compiled twice only and that was long ago, just to say... )
<apw> could be
<melodie> what change occurred which is very important and I didn't even see it coming until I realized last month:
<melodie> very important
<melodie> zram is no longer in the staging directory! that is new for me !
<apw> melodie, which kernel is this, which version
<melodie> 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<ogra_> apw, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/zram-config/precise/view/head:/debian/zram-config.upstart
<melodie> and the former ones from the same series had the same problem with zram
<ogra_> it was the upstart script that did bump the number of devices
<ogra_> via modprobe options
<melodie> ok ogra_ and apw I hope my findings will help improve it. if you need me for some tests, please just ping me on the bug report?
<melodie> hopefully we can continue using the script to keep control on it.
<ogra_> no, we cant, since the init system it was written for does not exist anymore
<ogra_> someone needs to port it to systemd ... (which i thought didrocks had done)
<melodie> ogra_ sorry? why would Didier Roche adapt it for systemd?
<melodie> didrocks has adapted it for systemd: this is my point
<ogra_> no idea, but he did that 
<melodie> and as the #13 of my bug report shows : once ZRAM blacklisted in blacklist.conf his scripts works perfect!
<melodie> now I can "systemctl start/restart/stop" it 
<melodie> it works!
<ogra_> did anyone bother to check if systemd has some internal own handling of zram ? 
<ogra_> (i.e. something that kicks in if the module is not blacklisted) 
<melodie> ogra_ I have been using in in Archlinux during the last years with systemd, and I have never heard about such a "internal" feature : it would not have been added anyway as long as zram was in the staging directory, which is a situation which lasted during several years.
<ogra_> perhaps it needs to be managed completely different in systemd world ... and "just porting" the old way doesnt work at all 
<melodie> ogra_ oh that
<melodie> can someone ask to a redhad dev?
<ogra_> melodie, http://lists.freedesktop.org/archives/systemd-devel/2012-November/007437.html something to read for you :)) 
<apw> ogra_, the module doesn't have any aliases, so it would have to be deliberatly mounted
<ogra_> apw, sure ... but it seems there are multiple userspace ways ... there is systemd-swap ... then there seems to be a udev rule for zram ... 
<ogra_> i suspect there is some integrated way in systemd that needs to be used for it ... and adding a systemd unit with our old upstart script might be the completely wrong approach
<apw> ogra_, right but as zram is a virtual thing, someone needs to ask for it, for udev to even see it
<melodie> ogra_ I'll try to read
<melodie> ogra_ well at least he has the same references as I do
<melodie> compache project and mystillef script
<apw> systemd-swap might be to blame for sure
<ogra_> apw, hmm, perhaps fstab ? 
<apw> i don't think fstab can instantiate zram as it is not a  filesystem
<ogra_> systemd parses fstab ... 
<apw> and mount generally only triggers probes for filesystems
<ogra_> i could imagine it tries to ask for the module when finding a zram device
<melodie> it looks like a very clean solution
<melodie> I'm talking about ogra_ 's link 
<apw> ogra_, could be, which would be a mess maker
<ogra_> i just think simply forward-porting the upstart way was wrong
<apw> i can say on a vivid/wily system i do not see zram loaded at all by default
<ogra_> ... and that there is some existing systemd way already
<ogra_> why would you see it loaded at all ? 
<melodie> ideally for user experience, ultimately, we wout like to get a gui with options that write in a zram.conf file, saying how many block devices we want, how large, or what %age of the ram we want them to be, along with advice for the best / recommanded practice. 
<apw> ogra_, well if i did then it would be something else
<ogra_> in upstart it wasnt loaded either until you explicitly asked for it by installing zram-config 
<melodie> Just a wish... ^^
<apw> ogra_, there was a contention it was the lx4 bits which triggered it, which it is not
<apw> else i would have it
<ogra_> ah
<melodie> apw you mean lz4?
<apw> yep that
<melodie> as in lzma ... 
<apw> so this must be an interaction with osmething else ... and you are likely right it is systemd
<apw> which likley means the way this is integrated isn't going to work so well
<apw> with systemd, i wonder if we could get it to write a modprobe.conf with the appropraite options for zram
<ogra_> apw, http://lists.freedesktop.org/archives/systemd-devel/2012-November/007444.html
<ogra_> ..."we can just add to the fstab lines, which sets up everything as needed"...
<ogra_> lennart ...
<apw> then again, if you are using zram-config why would you have /etc/fstab bits listing it
<ogra_> so seems my assumption was right ... systemd-swap sets it up ... and you have to define each and every device in fstab ... so if you want more than one it wont be dynamic at all
<ogra_> if you are using zram-config you are using the old upstart script wrapped by a systemd unity 
<ogra_> *unit
<melodie> ogra_ I am not sure about that:
<ogra_> no need for fstab in this case
<melodie> the mystillef method existed before Ubuntu makes use of zram
<ogra_> if you want to use the "new" systemd way you likely have to put a line for each zram device into fstab
<melodie> and his script was used with the systemV init way
<melodie> for instance, the former zram config script using systemV was adapted directly to systemd
<melodie> no upstart method there
<ogra_> melodie, could you try uninstalling zram-config and then create fstab lines like in http://lists.freedesktop.org/archives/systemd-devel/2012-November/007444.html ?
<ogra_> if my theory is right you would then get zram devices as defined in there 
<melodie> ogra_ in a virtual machine, yes. Not right away though but within a few days possibly.
<melodie> I could also ask the geeks of my tribe to test it
<melodie> I mean : the most advanced users of the small linuxvillage.org community. :)
<ogra_> heh
<melodie> I thought fstab was less used these days?
<ogra_> tell that to systemd :P 
<melodie> ogra_ my fstab is quite lite, one line per partition
<melodie> and one line for proc
<melodie> not sure it's even still needed: is it?
 * ogra_ has systems completely without fstab
<melodie> I mean the line for proc
<melodie> ogra_ o_o how do you do that?
<ogra_> but i doubt that works in the age of systemd
<ogra_> mountall ships a default one 
<melodie> oh you don't have systemd.
<melodie> ok
<ogra_> i do 
<ogra_> but not on all machines
<melodie> I meant in the one where you don't have a fstab (I sound obvious?)
<melodie> I keep your two links and will summarize this interesting zram matter on the linuxvillage forum asap
<ogra_> right, there the default one just kicks in ... but not even that would be needed
<melodie> sorry I have to leave the discussion now, I'm in the middle of another task 
<ogra_> our initrd mounts / based on the kernel commandline ... 
<melodie> i'll bbl
<ogra_> so no need for an entry for / ... (unless you want explicit fsck)
<ogra_>  /proc and /sys get mounted by the initrd too ... no need to have an entry for them ... 
<ogra_> and /dev nowadays gets populated by devtmpfs
<apw> i am still somewhat confused why you would get zram loaded if you don't have fstab entries
<apw> even if systemd thinks it knows better, and i am sure it does
<melodie> apw http://citrotux.org/Downloads/plot.svg
<melodie> don't know if that can help
<apw> melodie, well it cirtainly happens pretty damn early in systemds startup, much before udev even starts if i read this right
<apw> melodie, and can you pastebin the fstab on that for me
<apw> melodie, do i recon put a link to that plot in the bug, as it is pretty indicative that somehow systemd is involved, though i cannot find zram in it by default
<apw> melodie, that there is a unit called .swap, implies we have actual configuration for the swap on zram somewhere
<apw> melodie, perhaps in /etc/systemd/system/*.swap
<apw> melodie, perhaps in /etc/systemd/system/*.swap*
<melodie> I'll do that later, now I need to run out (dentist appointment) 
<manjo> bjf, is there an invite for the kernel team meeting ? or a schedule for  when the next one is ? 
<bjf> manjo, you mean the irc meeting?
<manjo> bjf, yes
<bjf> manjo, it's every Tue @ 1700 utc ... correct, jsalisbury ?
<bjf> manjo, it generally runs for no longer than 5 minutes so you need to be there on time
<bjf> manjo, do you have something you want to discuss?
<manjo> bjf, yeah related to ARM64 + UEFI + ACPI
<bjf> manjo, any reason to not just bring it up here tomorrow a.m. when cking is around? no need to wait for the meeting.
<manjo> bjf, plus get a general direction on where we are headed with ARM 8.1 support and smmuv3 support for 15.10
<manjo> sure I can do that 
<bjf> manjo, i think that's a better plan
<manjo> bjf, I think that is a better idea 
<manjo> bjf, just curious .. thought cking was helping out with git support with launchpad ... or it could be the other colin 
<bjf> manjo, other colin
<manjo> ok
<manjo> bjf, I also need to know how often do you guys rebase leg onto ubuntu dev trees stable & unstable 
<manjo> bjf, so I will come with a list of agenda items tomorrow am
<jsalisbury> bjf, manjo correct.  1700 UTC
<infinity> apw: I'm super confused by melodie's zram issues, and by everyone blaming systemd, since zram-config and systemd are working great here...
<infinity> melodie: ^
<melodie> infinity ?
<melodie> we can check that now if you want to?
<melodie> infinity when you want : we can check which Ubuntu edition and  version you have, and the results when you check status, start restart then stop and start ?
<infinity> melodie: Not sure what there is to check.  I'm using zram-config and systemd, and I get 4 swaps, as I should.  ie: it's working correctly.
<melodie> versions and editions?
<infinity> melodie: zram-config 0.5 (which is effectively the same as the one in vivid-proposed) on wily, kernel 3.19.0-22
<infinity> Oh.  No.  kernel 4.0.0-3 right now, but I could reboot into 3.19.0-22 again to prove the point.
<melodie> I have a kernel x86_64 3.19.0-22-generic systemd  219-7ubuntu6 
<melodie> how can you get that one kernel? 
<melodie> I'd like to give it a try too
<infinity> It's in the kernel team's PPA.
<melodie> aha
<melodie> ok, I won't do that right now
<infinity> But I can't see this being a kernel bug.
<melodie> I have two other tests to do first
<infinity> The part where the SRU works for Didier on vivid, and 0.5 works for me on wily, though, leads me to believe there's something weird in your test setup, not ours.
<melodie> what are your block devices priorities? 5 or 100 ?
<infinity> Or maybe something weird in your flavour.  Is this pure Ubuntu, or Lubuntu, or...?
<infinity> root@nosferatu:~# cat /proc/swaps 
<infinity> Filename				Type		Size	Used	Priority
<infinity> /dev/sda7                               partition	4070396	0	-1
<infinity> /dev/zram0                              partition	2557524	0	5
<infinity> /dev/zram1                              partition	2557524	0	5
<infinity> /dev/zram2                              partition	2557524	0	5
<infinity> /dev/zram3                              partition	2557524	0	5
<infinity> (5)
<melodie> yes, it looks perfect
<melodie> this is pure ubuntu core with openbox as main component
<melodie> core : I mean base system
<infinity> melodie: No mention of zram at all in /usr/lib or /etc ?
<infinity> Or /lib
<melodie> such as what?
<melodie> do I need to invoke find there?
<infinity> Literally the string "zram".  rgrep for it.  We can figure out why things mention it if it's mentioned. :P
<melodie> wait wait: right now it's working right since I have blacklisted the zram module, so this test would not be helping
<infinity> melodie: The grep will still be enlightening.
<melodie> I have to undo the zram blacklisting, then remove zram-config 
<melodie> ok, if you say so
<infinity> rgrep zram /etc/ /usr/lib/ /lib/
<melodie> can chain them?
<infinity> Yeahp.
<infinity> It'll grind a lot and take a while. :P
<melodie> yes, I started it as root to avoid the "forbidden" list
<infinity> This is what I get: http://paste.ubuntu.com/11795400/
<melodie> I'll pastebin once finished
<infinity> ie: no mention of it, except for the upstart/systemd jobs.
<melodie> ah wait
<melodie> I have to restart it with LANG=C
<infinity> Doesn't really matter, I can divine what "Das binary containen der stringen" means. :P
<infinity> (Or whatever)
<melodie> :)
<melodie> this one was done before I had the idea of blacklisting zram, http://citrotux.org/Downloads/plot.svg
<melodie> does it "talk" to you?
<melodie> humm it seems this one you don't have? "lib/udev/rules.d/60-persistent-storage.rules:KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*|mmcblk[0-9]*rpmb", GOTO="persistent_storage_end"
<melodie> "
<melodie> full output:
<melodie> http://pastebin.fr/40331
<infinity> I wouldn't expect that to cause an issue, but I suppose anything's possible.  Maybe I should test this in a vivid VM.
<melodie> also you say you have zram-config 0.5 proposed in Vivid, but I have zram-config:
<melodie>   InstallÃ©Â : 0.3.1
<melodie>  which is what I get as proposed in Vivid
<infinity> No, no.  I have 0.5 in wily, but it's basically identical to 0.3.1 in vivid-proposed.
<melodie> what differs from 0.5 and where have you seen it proposed in Vivid?
<melodie> oh ok
<infinity> ie: the same fixes, just a different version number.
<melodie> ok
 * infinity grabs a vivid ISO...
<melodie> infinity do you want my last test version? 
<melodie> very small
<infinity> melodie: I'd rather see if I can reproduce it in a stock install first, but then, sure, yours might be useful.
<melodie> http://linuxvillage.org/en/2015/05/bento-openbox-vivid-rc1-and-rc2/
<melodie> well here
<melodie> just my home version is one I upgraded from the Bento 12.04 done previously to the 14.04 then from there to the 15.04. I was happy to see that it didn't break at any moment. 
<melodie> direct upgrades can be tricky sometimes
<infinity> I want sushi-rc2?
<infinity> http://downloads.linuxvillage.org/sushi-vivid-rc2-with-openresolv-x86_64.iso ?
<infinity> melodie: Oh, hrm.  Can you give me a pastebin of "update-initramfs -u -v" on the affected system?
<melodie> yes infinity you want sushi, it is a Vivid with almost no appas
<melodie> apps
<melodie> rc1 or rc2 as you want, they are the same except for the resolver
<infinity> melodie: Yeah, I installed a fresh sushi and can't reproduce your issue, but I have a hunch, hence the above request.
<melodie> still don't mind that I have zram blacklisted and zram-config working fine?
<infinity> Noe.
<infinity> Nope*
<melodie> infinity http://pastebin.fr/40332
<infinity> Ah-ha.
<infinity> melodie: rgrep COMPCACHE /etc/
<melodie> in the way
<infinity> melodie: My bet is that /etc/initramfs-tools/initramfs.conf:COMPCACHE_SIZE= is set to something other than an empty string.
<infinity> melodie: If you set that to "" and re-run update-initramfs -u, everything would be happy.
<infinity> And I should probably cripple initramfs-tools to ignore COMPCACHE_SIZE is zram-config is installed (and eventually tear that code out entirely...)
<infinity> s/is/if/
<melodie> infinity let me check the output now, I was working on a SVG in the meantime, having a course with a buddy on another chan
<melodie> # rgrep COMPCACHE /etc/
<melodie> /etc/initramfs-tools/initramfs.conf:# COMPCACHE_SIZE: [ "x K" | "x M" | "x G" | "x %" ]
<melodie> /etc/initramfs-tools/initramfs.conf:COMPCACHE_SIZE="25%"
<infinity> melodie: That would be the issue.  The default for that is "" (ie: empty).
<melodie> this is my fault then
<melodie> let me fix it here
<infinity> melodie: And if it's set, initramfs-tools will set up a zram swap before you ever get to init.
<melodie> and I'll retry all of this tomorrow
<melodie> o_o
<infinity> melodie: So, yeah, change that to "", and then run "update-initramfs -u", and it should be happy even with your blacklist removed.
<melodie> what I would like at the end, would be a nice /etc/default/zram.conf that is tweakable 
<melodie> do you think that could be possible?
<infinity> melodie: A config file is a possibility, yeah.  With it defaulting to what it does now (50% RAM, a swap per CPU thread).
<melodie> a swap per cpu thread is what I am used to, the 50% ram does not match the observations done for use in desktops by nitin gupta, the creator of the compcache project, and I always used 25% as per his advice (which was working well enough for my greedy habbits)
<melodie> what I also know since I had lots of discussions around the zram topic with other users, they like to do experiments and try 20/33 % or even fixed values
<melodie> according to what their hardware are
<infinity> melodie: Sure.  We can definitely extend it to allow a config file, though that's not something I'd SRU back to older releases, we'd only see it in 15.10 and beyond.
<melodie> this is fine with me
<melodie> as long as it's a work in progress as we say :D
<melodie> and after the 15.10 I'll come back and eventually as for a GUI (started with admin priviledge)
<melodie> or better: 
<melodie> a tool as they have in Fedora and co!
<melodie> let me see if I still have this pic somewhere
<infinity> Given our usual urge for GUI simplicity, this isn't the sort of thing we'd usually want exposed in a settings UI.
<infinity> Normal users should have zero need to tweak this sort of thing, IMO.
<melodie> yes!
<melodie> http://phillw.net/isos/bento-ubuntu-remix/misc/Downloads/Screenshots/Jobs/
<melodie> infinity Ubuntu is more used by advanced users than normal users now and I have installed Ubuntu (several flavors) to end users machines and I can tell you : when they don't know what a menu does they just don't touch it
<melodie> so what we need this for, is for average and advanced users who are tired of having to remember every command line because the init systems have changed in time 
<infinity> melodie: None of that is about configuring things (ie: tweaking config files), that's just a tool to enable/disable/start/stop services.  ie: it's a GUI systemctl.
<melodie> and having to check the internet and wiki and docs is a bit time greedy too, and time is a good that is very precious nowadays
<melodie> infinity yes, I am a bit mixing the topics, sorry :D
<infinity> And I agree that shipping that would probably be a good idea.
<melodie> but this is really what I meant in fact
<melodie> the ability to start and stop services, including zram-config of course, would be good.
<melodie> and "jobs" is still in the repos: I forgot to write a bug report!
<melodie> to have it removed because it's been years since it's not working
<melodie> last time I checked, Archlinux version of the tool was not working anymore either, and was not in the official repos, but the Fedoran version of the tool that I tried and used was really wonderful.
<melodie> very detailed, very easy to use
<melodie> if it can be adapted for all deb distros that would be wonderful.
<infinity> melodie: I've updated LP: #1449678 with our findings above, BTW.
<ubot5> Launchpad bug 1449678 in zram-config (Ubuntu Vivid) "(Vivid) zram-config 0.3 Job for zram-config.service failed" [High,Fix committed] https://launchpad.net/bugs/1449678
<infinity> melodie: If you can reset that config variable, remove your blacklist, regen your initramfs, and verify that bug, it would be lovely.
<infinity> (I can verify it here, but I'd prefer you do...)
<melodie> infinity thanks for the update!
<melodie> I'll be notified and will confirm accordingly. 
<melodie> next time I will have rebooted
<melodie> (just not now)
 * infinity nods.
<melodie> :)
<melodie> you had a very fine hunch. what is your skill exactly? what do you do in Ubuntu?
<infinity> melodie: Everything.
<melodie> o_o
<melodie> would you have some time for some mentorship once a while?
<infinity> melodie: I'd love to say yes, but the more honest answer is probably no.  I tend to work a little too much as it is.  But I'm always around to answer the occasional question, as long as you don't get offended if I sometimes don't reply or don't have time. :P
<melodie> ok
<melodie> on what other chans are you also? Here is for kernel and my questions might not be kernel related.
<melodie> mostly about XDG_* variables, and later about packaging config files for ppa 
<infinity> melodie: Most generic development stuff belongs on #ubuntu-devel, unless it's newbie questions, which should usually be on #ubuntu-motu.
<melodie> what is a newbie? XD
<melodie> I consider myself still a newbie as I'm still climbing the learning curve, started 11 years ago :D
<melodie> well never mind... one way or other I'll find how to do things the right way. Up to now, Bento Openbox is a proof of concept
<melodie> it works
<infinity> melodie: Well, "newbie" questions don't necessarily come from new users/developers.  But if the question could be phrased as "help, I have no idea what I'm doing here" rather than "I know how this works, but it seems broken", then it belongs on -motu.  The latter belongs on -devel.
<melodie> technically it needs lots of improvements
<melodie> nothing in between?
<infinity> melodie: You have an installer bug on sushi, BTW.  Doesn't remove all the installer deps before reboot.
<infinity> melodie: But I'm sure you'll sort that one out. :)
<melodie> infinity I know about it, it comes from the tool I use to remix
<melodie> I didn't think of a way to use the filesystem manifest remove (or desktop, don't remember which one) and not sure the program allows tweaking it.
<melodie> it's an issue but not the only one, I need to adress more than one issue.
<melodie> not issues that the end user can detect, for him all works nicely.
<melodie> infinity I have an idea of a test I could do
<melodie> a fast one
<melodie> a diff -aur on the one file I have and the one that exists in the lubuntu live iso
<melodie> and tweak the file I use..
<melodie> thanks for saying!
<melodie> good night
#ubuntu-kernel 2015-06-30
<cyphermox> arges: hello! any news about multipath-modules?
<arges> cyphermox: patch is on the ML, smb acked the patch. So it might be applied at some point soon
<cyphermox> cool, thanks
<smb> arges, of course we may have added dm-queue-length along with dm-service-time ;-P
<cyphermox> do you mean you added it as well, or that it should have been done? :)
<smb> cyphermox, we could have done but did not
<cyphermox> ok
<cyphermox> well, either is fine
<arges> so for this case, it really just matters at install time right? since this is what gets put into the udeb
<cyphermox> yeah, it's just for the installer
<smb> yeah as long as the other does not get default one day (which probably is not happening)
<arges> so if the package default changes we just need to accomidate that
<cyphermox> you could easily install with X and then update to Y after the install
<arges> yea and in that case the module is already there
<cyphermox> yup
<Teduardo> does anyone know what causes cmci storm detected and cmci storm subsided messages during an install of ubuntu 14.04?
<Teduardo> i'm testing a server from a new vendor and i've never ever seen that before
<arges> Teduardo: sounds like a hardware issue. https://lkml.org/lkml/2012/8/7/916
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<bjf> manjo, didn't you want to discuss something this a.m.?
<manjo> bjf, yes I did .. stuck on calls 
<manjo> bjf, so starts in 40mts ? 
<bjf> manjo, starts here in this channel whenever you want :-)
<manjo> bjf, yes sir 
<arges> bjf: 81848
<manjo> cking, bjf, I have 3 question related to ARM64 ... I am not looking for info on specific patches etc... but just to get an idea about where we are at with these 3 things for 15.10. 
<manjo> 1. What is the timeline for merging ARM64 + ACPI patches from upstream and linar
<manjo> o in 15.10? is ppsati doing that work, can we work with him if our friends find
<manjo> some missing patches that we might have to cherry pick from upstream?
<manjo> jsalisbury, ^
<cking> manjo, which specific ACPI features do you require?
<manjo> cking, so I know that a lot of the platform code are already upstream, but some of the driver work is ongoing ... I just want to get a feel for who is tracking those patches 
<manjo> cking, if not I can track those and send pull reqs
<cking> manjo, not me personally
<cking> again, "which patches"?
<bjf> manjo, we don't have any, one, person specifically tasked with "track linaro ACPI patches that are not upstream"
<manjo> cking, like I said at the beginning I am not looking at specific patches ... I just want to get a general idea from you guys 
<bjf> manjo, if you are tracking things like that you are welcome to submit patch requests to the ML like anyone is
<manjo> so that I could send in pull reqs
<cking> manjo, the default is that you get what lands in the wily kernel when is released, e.g. 4.1
<manjo> cking, cool. I will track the deta and send you any pulls reqs then 
<cking> or 4.2 pehaps
<manjo> cking, will you pull from linaro ?
<manjo> cking, coz that leads into my Q2
<manjo> What is the delta like between LEG and 15.10 dev kernel? Some of our friends want to drop using LEG and start using 15.10 dev tree as the base tree for arm64 servers. How quickly can we sync dev 15.10 with LEG ? 
<manjo> s/quicly/frequently 
<bjf> manjo, upstream in Linus' tree
<cking> what's LEG?
<bjf> s/in/is/
<manjo> linaro engg 
<cking> manjo, i really can't tell what the delta is, that's a homework question isn't it?
<manjo> cking, linaro enterprize group ... ie linaro kernel 
<bjf> manjo, we don't track everyone's kernel git repo
<cking> not in my head, anyway
<cking> manjo, i think if you need to know the delta, one can work that out yourself, you have access to the git repos
<manjo> ok I was under the assumption that you guys track and pull linaro patches ... that is why I asked 
<cking> ack
<manjo> so I thought you might be able to tell me if there is a 6 month worth of delta or couple of weeks 
<bjf> manjo, sorry, we just don't know. there are too many kernel git repos for us to track very many. that's certainly not one we do.
<manjo> one more question ... but I think I know the ans already ... do you guys plan to pull in 8.1 arch support & smmuv3 support in 15.10 ? 
<manjo> those patches are still int he works and might not have hit stable ... but from what I hear those might be upstream by october ish
<manjo> if not .. do you see any issues with pulling those in for 16.04 dev ? 
<bjf> manjo, if they hit Linus' tree then we'll likely pull them automatically for 16.04. if they don't reach upstream until oct. then they likely won't make it into 15.10
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 7th, 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/
#ubuntu-kernel 2015-07-01
<pgregor2> hi
<pgregor2> is this apropriate place (channel) to ask a question about kernel development?
<pgregor2> my question is described here: http://stackoverflow.com/questions/31162843/debug-linux-kernel-running-on-intel-target-from-amd-host-how-to-return-control
<pgregor2> and here: http://stackoverflow.com/questions/31164163/ubuntu-echo-g-sysrq-trigger-halts-but-doesnt-return-control-to-gdb
#ubuntu-kernel 2015-07-02
<caribou> cking: Hi, can you suggest a quick & dirty way to exercise HDD to identify potential disk failures ?
<caribou> I got some reported I/O error on writes & the vendor claims that it is a driver issue
<cking> caribou, try tiobench or fio
<caribou> but only on 2 out of 80 disks :-/
<cking> or stress-ng --hdd
<caribou> cking: thanks, will try that !
<caribou> (and interesting reading about CFS) :-)
<cking> indeed it is
 * ogra_ would just have started with smartmontools :P
<dgmurdockiii> hey why dont you guys support the Mad Catz R.A.T. 9 yet 
<dgmurdockiii> still hav e to do this http://ubuntuforums.org/showthread.php?t=1661126
<PhoenixSTF> hello I have ubuntu 14.04 with kernel 3.16 amd64, it seems that is does not come with the ipsec modules
#ubuntu-kernel 2015-07-03
<Zythyr> Has anyone used Systrace, atrace, ftrace or any other kernel tracing. Can you please help me with this http://stackoverflow.com/questions/31192104/how-do-i-use-async-start-and-async-stop-in-systrace-atrace-for-android
<ontoillo1ical>  9
<ontoillo1ical> Hi all. This *might* be the wrong channel for this, so please tell me if it is. I have a question about how ubuntu security team handles things. I'm building tools to monitor USNs, and I see that there are two databases https://usn.ubuntu.com/usn-db/database.pickel and https://usn.ubuntu.com/usn-db/database-all.pickle . Obviously, database is bigger then database-all. Is database-all always a superset? When do USNs leave database and stay in
<ontoillo1ical> Thanks!
#ubuntu-kernel 2015-07-04
<JanC> ontoillogical: ubuntu-hardened is the proper place/team to ask  :)
<ontoillogical> JanC: Thanks! I was confused because there was no "ubuntu-security"
<JanC> historical reasons IIRC
#ubuntu-kernel 2016-07-05
<mowthegrass> can anyone help me understand linux-image-generic-lts-trusty
<mowthegrass> does this kernel package always points to the latest 12.04 LS kernel 
<mowthegrass> LTS*
<pkern> linux-generic-lts-trusty points to the latest HWE kernel in 12.04 because there won't be any newer one.
<apw> mowthegrass, that technically points to the latest version of the lts-trusty kernel in 12.04, if there was a later LTS backport for that release it would not update you to it and there would be a corresponding -lts-<series> package for that one
<apw> mowthegrass, though as pkern correctly states, there is not going to be a later kernel for 12.04 than the trusty kernel
<apw> b
<manjo> apw, around ?
#ubuntu-kernel 2016-07-06
<rtg> cyphermox, I think a Yakkety shim/mok update in my locally keyed VM broke the boot, i.e., shim and mok no longer have the correct signature.
<rtg> that seems like a bad thing to me.
<apw> rtg, a new version would always be signed by canonical, so you'd have to resign them no ?
<rtg> apw, agreed, but how would you know to do that with an automated update ?
<apw> rtg, indeed, but it is a limitation of self-signing
<rtg> seems a bit harsh
<pkern> A Dpkg::Post-Invoke hook?
<apw> rtg, i would guess we should be telling people that pinning the version they signed or something
<apw> is a good idea ...
<rtg> hmm, I think I'll get back to it tomorrow and file a bug so that this deficiency at least gets considered.
<cyphermox> err, wtf
<cyphermox> there is no point in self-signing if you're testing from proposed.
<apw> cyphermox, i think the point was say you had a self-signed setup, and you get an update, it gets unsigned
<cyphermox> well, if you have a self-signed setup, you'd still have microsoft keys in your BIOS -- things should still validate, just signed by Microsoft
<apw> cyphermox, a fair point indeed
<cyphermox> those who do not have keys just usually don't have secureboot (ie. no keys setup at all) or their own PKI (in which case they already know what to do)
<cyphermox> if you have your own PKI with your own keys in, I expect you would already know you should re-sign shim with your key, that's nothing particularly new
#ubuntu-kernel 2016-07-07
<teward> does thermald fall under the purview of the kernel team in terms of triage of bugs for it?
#ubuntu-kernel 2016-07-08
<memeka> hi, my system hangs on reboot (but not on shutdown) and i need to plug off/plug back the power to make it respond - what's the best way to debug the kernel - find out exactly where the reboot code is?
<apw> teward, yep thermald is one of ours ...
<apw> memeka (N,BFTL), there are a number of ways to skin the reboot cat, and normally you would try them all to see which works and add a quirk to select that one
<teward> apw: still around?  (sorry i wasn't around at 03:52 local)
<teward> apw: or kernel team, before I poke hggdh or the quality list admins to silence something that should probably be squished, https://lists.ubuntu.com/archives/ubuntu-quality/2016-July/006585.html may be of interest, regarding why something was fix released for wily but didn't fix things (and possibly didn't fix for Trusty)
<teward> wrt bug #1543046
<ubot5> bug 1543046 in thermald (Ubuntu Wily) "thermald spamming kernel log when updating powercap RAPL powerlimit" [High,Fix released] https://launchpad.net/bugs/1543046
<apw> cking, ^ this is a thermald thing that is marked fixed but seemingly not so
<teward> apw: no confirmation of still existing for Trusty
<teward> and i need guidance for the Wily side
<teward> i.e. "Would it be fixed before EOL and would it do any good to change the bug status for wily"
<teward> asking as bugcontrol not QA :P
<teward> s/bugcontrol/bug triage/
<cking> apw, ok, I'll look at it on monday, although I'm surprised by this :-/
<teward> cking: without taking a look at it, can you give me a best guess as to whether this close to Wily EOL we actually care about getting this fixed before it EOLs?
<teward> I can understand it needs poked for Trusty if it still exists, I don't see justification for Wily which dies off in 20 days
<teward> (as a bug triager, not a kernel guy)
<rtg> cking, plus we're aren't gonna updatethe kernel anymore
<cking> teward, well, I know the code well, so it's trivial for me to eyeball and I can turn it around on monday quite easily as long as nothing higher priority hits me over the weekend
<teward> ack
<cking> when is wily EOL now?
<teward> 28th
<teward> message went out from infinity yesterday
<teward> over the announce lists
<cking> ok, I'll see what I can to monday, I was pretty sure I tested this on my x220, but oh well, I screwed it up I guess
<teward> cking: i'll reply saying it's in the Kernel Team's hands now, and to stop the bickering on the QA list
<teward> is there a kernel ML you want me to CC on with that reply?
<cking> teward, I'd prefer for me to just update the bug report 
<teward> ack
<teward> cking: i'll leave it be and say it's back in the Kernel team's hands, and to leave it be until such time one of the team's members reply to the bug.
<teward> it's still needing an anti-drama squish.
<teward> (on the quality ml)
<cking> it's not going to kill anyone, it's been like tyhat for a while without much drama
<teward> indeed.  there's drama between two people on the ML
<cking> they need more beer
<teward> and *that* needs squished (it's no longer just a report of 'marked fixed but not fixed')
<rtg> they need to upgrade to xenial
<cking> +1 rtg
<teward> rtg: that's what i said in my reply to the thread heh
<teward> but, alas, end users will be end users, so... ::
<teward> :P *
<hggdh> teward: OTOH, php4fan has just earned moderation on the ML.
<teward> hggdh: oh joy
<hggdh> I still think php4fan and Teo Teo to be one and the same
<teward> hggdh: this wouldn't be the same guy from before would it?  (I recently pruned all my mailing list messages from my main inbox, CBA to pull up the archive)
<teward> ahh that's the one I was thinking about
<teward> hggdh: funny story, I was going to ping you on it privately, too, and ask for some higher power to be called forth, but lunch was calling first :P
<teward> thanks for the FYI
<hggdh> yw. Pity, though. This person uses Wily for his "production", and still does not understand the difference between LTS and interim
<teward> hggdh: hey, that's 50% of the Ask Ubuntu people, it's why I started posting the EOL notices.
<teward> so people aren't all "WHY THE [censored] DID MY POST GET CLOSED WHAT IS EOL WHAT IS THIS ..." 
<teward> *rolls eyes*
<hggdh> good idea.
<cking> teward, I've prepared a fix, I'll get the user to test it from a PPA and upload it once they verify it works
<teward> cking: ack
<memguy> curious does anybody know what db000000-db7fffff : RAM buffer i have tried to read from it and i cann't do that i just curious on what it is used for some kind of buffer cache or something but don't understand it (how it is used,why , and what is using it)
<mjg59> memguy: If a region of RAM doesn't end on a 64MB boundary and there's nothing else allocated there, the kernel reserves the space to reduce the probability that there's actual RAM there being used by the firmware
<mjg59> Otherwise you might map an mmio device on top of it
<memguy> wait so what happens if the region ends on 64MB boundry
<memguy> i guess i don't see the point of it and why they named if ram buffer
<memguy> curious is there a cpu feature or flag that has something to do with cpu temperature because i have seen /dev/temperature or other devices and read into it a little bit. Can processors detect there temperature there running at like they can with voltage and frequency settings thru power management
<memguy> i am curious if there is a /proc/cpuinfo flag name for this which would control the setting range of what the cpu  temperature range it will run at before halting to resume that range . would be a cool feature to beable to turn off and on
<memguy> in conjunction with p-state and t-state and c-state
<memguy> I guess alot of this can be obtained from ACPI but was curious on if there is a flag and dedicated cpu feature for all this processor temperature,freq, cpu voltage/current
<memguy> spped
#ubuntu-kernel 2016-07-09
<memeka> hi, any tips on how can i debug the reboot process? my machine hangs after the "Starting Reboot..." message
<mikkel> hi - /etc/grub.d/06_OVHkernel No such file or directory - can anyone advise on this error? i'm trying to change the kernel but hitting this issue.. any help would good :)
<mikkel> i have searched the web and checked various forums but can't seem to find the issue.
#ubuntu-kernel 2017-07-03
<oSoMoN> hey kernel team! is bug #1699772 supposed to be fully fixed with 4.4.0-83.106 ?
<ubot5> bug 1699772 in scilab (Ubuntu) "linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic Regression: many user-space apps crashing" [Undecided,Confirmed] https://launchpad.net/bugs/1699772
<oSoMoN> Iâm asking because Iâm still seeing build failures for libreoffice 5.3.3 and 5.3.4 on i386 (bug #1700692)
<ubot5> bug 1700692 in libreoffice (Ubuntu) "FTBFS on i386: dbaccess_RowSetClones unit test segfaults" [Critical,Triaged] https://launchpad.net/bugs/1700692
<smb> oSoMoN, That kernel version replaced the fix with the current upstream approach. That should fix the currently known real use-cases but showed some failures with some test cases. However upstream decided that they want to see real use-cases. So behavior is probably not back to how it was before but might need convincing arguments for upstream that something breaking is a legit use.
<oSoMoN> smb, ack, so where should I forward that use-case for upstream to consider it?
<apw> oSoMoN, the first step is to look at what is it doing in that unit test and confirm it is actually sensible, and was not getting lucky beforehand
<apw> oSoMoN, do you have a reference to the test ?
<oSoMoN> apw, there's a full stack trace here:Â https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1700692/comments/3
<ubot5> Ubuntu bug 1700692 in libreoffice (Ubuntu) "FTBFS on i386: dbaccess_RowSetClones unit test segfaults" [Critical,Triaged]
#ubuntu-kernel 2017-07-04
<zyga> which of the kernel trees on kernel.ubuntu.com/git contains the official 16.04 LTS kernel?
<apw> zyga, t
<apw> zyga, the xenial GA kernel ?
<zyga> t?
<apw> typeo
<zyga> the 4.8 kernel that one can get on xenial
<zyga> (or if there is one big repo, not sure, for all of ubuntu kernels
<apw> zyga, there is one for each series yes
 * zyga thinks about editing the description fields to cleary differentiate *personal* development repositories from official ubuntu kernel repositories
<zyga> apw: and which one should I track?
<apw> https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
<zyga> oh, so kernel is now on launchpad?
<apw> zyga, there is no branch (now) for the 4.8 kernel as that is about to die, but there are tags for the versions we have published
<apw> zyga, was the very first thing ever pushed to git.launchpad.net which was not for testing
<zyga> apw: how does it releat to k.u.c/git?
<apw> zyga, the kernel.u.c repos are mirrors of launchpad for those with old links
<zyga> ahh
<zyga> thanks
<LocutusOfBorg> hello, do you have any ETA for kernel 4.12 in artful?
<LocutusOfBorg> just to understand when I can send you the virtualbox updated kernel modules
<apw> LocutusOfBorg, just get the bits uploaded to artful, they would be backwards compatible right ?
<apw> LocutusOfBorg, we sync with your packages periodically
<apw> LocutusOfBorg, or to look at it another way, the 4.12 kernel is evolving in our unstable PPA so you could give us what we need for that
<LocutusOfBorg> the problem is that virtualbox should be released soon(TM), but I don't know when
<LocutusOfBorg> and I prefer to give you the updated modules when it comes out
<LocutusOfBorg> usually this is a matter of some days after the new kernel is released
<apw> LocutusOfBorg, we are pusihng to get 4.11 in the archive, so iw oudl not expect to be trying to reupdate that in the next week
<apw> but as soon as you have bits we can consume them in our ppa builds
<LocutusOfBorg> ack
<LocutusOfBorg> seems a good plan, thanks
<oSoMoN> smb, apw: following up on the conversation we had yesterday about bug #1700692, what would be the best way to make a case for it upstream?
<ubot5> bug 1700692 in libreoffice (Ubuntu) "FTBFS on i386: dbaccess_RowSetClones unit test segfaults" [Critical,Triaged] https://launchpad.net/bugs/1700692
<cascardo> funny, that expand_stack code is basically what we tried to fix with 4.4.0-83
<apw> cascardo, does that imply we know what that expand_stack code looks like ?
<apw> oSoMoN, upstream wnat to know what that expand_stack code thinks it is trying to do
<apw> so they can decide if it is sensible or not
<smb> apw, roughly I would think that one would need the test that fails in a isolated way (described so one can run things without hunting for missing pieces). And then they surely want some prove that the actual application suffers from the problem, too
<cascardo> apw: it's almost the same as the test code I sent on our discussion
<cascardo> the one sbeattie wanted to include in the testing
<cascardo> the thing is: the reproducer works fine on the fixed kernel
<apw> cascardo, where they were assuming they could expand down two pages or something right, when the stack pointer is not in the page
<cascardo> no, not that one
<cascardo> the code just uses /proc/self/maps to look for the stack start and touch it
<apw> hmm
<apw> and you know this test does that ?
<oSoMoN> isolating the test case is not gonna be an easy task, as it involves the libreoffice launcher, which is quite a beast (and my knowledge of that codebase is inexistent)
<cascardo> apw: that's what jvm does when creating the main thread stack
<oSoMoN> the good news is that the failure is 100% reproducible on launchpad builders
<cascardo> so it affected any jvm... now, that's something else in this libreoffice build test, if it really fails with 4.4.0-83
<smb> cascardo, just to point out that these are i386/32bit builds. 32bit is often fragile and nowadays less well looked after
<oSoMoN> one potentially interesting data point is that the same test was failing on amd64 when I built a snap with kernel 4.4.0-81.104, and it passed with 4.4.0-83.106
<oSoMoN> so 4.4.0-83.106 appears to have reliably fixed the issue for amd64, but not for i386
<cascardo> ah...
<cascardo> worth taking a look at that
<cascardo> hum... reproducer works on i686 kernel 4.4.0-79, breaks in 4.4.0-81 and works again in 4.4.0-83
<cascardo> same thing with the jsvc reproducer
#ubuntu-kernel 2017-07-05
<Mehul>   I am following https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html to enable kernel crash dump for Ubuntu-16.04. I want to automate entire configuration process through shell script, but as mentioned in the above doc, when "apt install kdump-tools" is run, it prompts a dialog asking "Should kdump-tools be enabled by default?". Is there any way to answer any prompted question in "YES" through script?
<apw> Mehul (N,BFTL), I am sure you can, that is a debconf prompt, and i believe you can pre-answer them as you feel fit.  you might ask on #ubuntu-devel they might well know better than me.
<oSoMoN> re- that libreoffice unit test failure: itâs not just the build that fails, the actual application crashes on x86, see bug #1702165 (and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865303)
<ubot5> Debian bug 865303 in src:linux "libreoffice: Libreoffice Java features crash with Linux 3.16.43-2+deb8u1" [Serious,Open]
<ubot5> bug 1702165 in libreoffice (Ubuntu) "Libreoffice writter crashes when JDK is enabled" [High,Confirmed] https://launchpad.net/bugs/1702165
<smb> The problem is that the tests we got so far include one that does a simple jsvc run. And I checked this morning on a Xenial 32bit installed VM with the 4.4.0-83 kernel and at least that does work ok. Which puts us back at: what are exactly these java incantations/tests trying to do.
<LocutusOfBorg> but since the regression seems to be in the kernel, can't we forcebad tests for it?
<LocutusOfBorg> a lot of stuff will migrate if we exclude that bad test
<cascardo> I can try running a libreoffice install... that should take less time than the build itself
<apw> LocutusOfBorg, as we are saying it is likely the kernel is now "right" and anythign which does not work is broken, this might be the wrong approach
<oSoMoN> smb: that libreoffice crash is happening there: https://cgit.freedesktop.org/libreoffice/core/tree/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx?h=libreoffice-5-3-1#n831. The way LO instantiates a JVM is clearly much more complex than the simple jsvc run
<smb> oSoMoN, Been watching the Debian side and they found a suspicious piece of code in jdk which might end up trying to use exactly that bigger area of code which is now forbidden (specifically for 32bit)
<smb> I mean that bigger guard area
<smb> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os_cpu/linux_x86/vm/os_linux_x86.cpp#l881
<oSoMoN> aha
<smb> cascardo, were you looking deeper into that? I was kinda distracted by trying to cope with netplan and my not that simple network setup
<cascardo> smb: yes, I am looking at that, trying to write a reproducer that would help us understand what is happening
<cascardo> if not, I have managed to run libreoffice on i386 and get a segfault
<apw> bwh has produced some more proposed patches: https://marc.info/?l=linux-kernel&m=149927397912305&w=2
#ubuntu-kernel 2017-07-06
<qeni_> Hello guys. Where can I find RS-485 support in Linux 4.x? I don't see that option while doing 'make nconfig'
<mjg59> rs-485 is an electrical standard, not an OS-level thing
<mjg59> rs-485 devices are typically connected to a serial UART of some sort
<mjg59> So it depends what hardware you're building on
<mjg59> Wait sorry I'm thinking of RS-422
<mjg59> Think the answer's the same, though
<mjg59> https://github.com/torvalds/linux/blob/master/Documentation/serial/serial-rs485.txt suggests that it's just up to userspace to set the appropriate flag
<apw> mjg59, it _is_ a serial standard
<mjg59> Too much time spent on SGI systems
<qeni_> apw: So do you have any ideas where I can find this? :<
<apw> qeni_, sorry no experience of that, as mjg suggests there looks to be support, but if doesn't Just Work(tm) i am less sure
<qeni_> ok, thanks
<mjg59> qeni_: Yeah there's no option to enable it. If your UART supports it then userspace should be able to just use it by doing the appropriate setup as described in that doc.
<qeni_> mjg59_: thank you so much, so I have to to compile this code and run it to set rs-485?
<qeni_> of course with my configuration
<mjg59> qeni_: You need to incorporate that into your application
<melodie> hello
<melodie> I would like to try the very latest kernel available on my computer, because I meet with issues with the current one. 
<melodie> can someone point me to the page where I can get the deb files?
<sforshee> melodie: http://kernel.ubuntu.com/~kernel-ppa/mainline/, with the latest being 4.12. However you should note those kernels are only for testing and are unsupported. If you find 4.12 fixes your issues you should file a bug so that we can try to backport the fixes.
<melodie> sforshee, ok, thank you
<sforshee> np
<melodie> sforshee, 
<melodie> my kernel is 4.4.0-83-generic  with Ubuntu 16.04.2 LTS
<melodie> I need 3 packages, right?
<sforshee> melodie: if you aren't using any dkms drivers (things like the nvidia binary driver) you can probably get by with only the linux-image-*-generic package
<melodie> the amd generic headers and image and the all deb: right?
<melodie> I do use dkms drivers with nvidia binary driver
<sforshee> otherwise you will also need those header packages
<sforshee> yeah, so you'll need them
<melodie> I have no choice because nouveau would not handle the resolution
<melodie> ok thank you very much
<sforshee> melodie: however it's highly likely that the nvidia driver will fail to compile against 4.12
<sforshee> almost certain in fact
<melodie> would nouveau handle properly the GPU with this new driver, or is it not related?
<sforshee> it's possible nouveau could handle it, I can't say for sure
<melodie> well I can try and if it's not ok, I can reboot to the former kernel
<sforshee> yes
<melodie> and reinstall nvidia after
<melodie> I'll just prepare a script to make it easier to switch back in case of need
<melodie> also the machine is behaving right now so I'll do the tests later, when the current jobs are done ^^
<sforshee> melodie: note that we also have a linux-generic-hwe-16.04 package which will get you a somewhat newer kernel (currently 4.8, switching to 4.10 soon) where we should at least be keeping the nvidia binary drivers working
<melodie> why not?
<melodie> ok I will try that
<melodie> what does hwe stand for?
<sforshee> hardware enablement
<melodie> sforshee, what does hardware enablement bring which current generic kernels don't?
<melodie> I am very much interested in this part
<melodie> being hardware aware interests me highly
<sforshee> melodie: it's really just letting you get kernel version from our interim releases in the lts kernel. 4.8 -> yakkety, 4.10 -> zesty
<sforshee> newer kernel versions bring new and updated hardware support
<melodie> ok
<sforshee> sorry, should have read "kernel version from our interim releases in the lts release"
<melodie> thinking of
<melodie> yes, I got it
<melodie> I'm used to switch things back and fro from English, my native language is French and we are often saying things upside down
<melodie> so 
<melodie> thinking of, where can I have insights about a specific printer I want to get next? I've heard lots of good things about Epson EcoTank models, for they are economic with ink and so and so
<melodie> I will next seek for the feedback from the Ubuntu communty
<melodie> community
<melodie> maybe at Ask Ubuntu?
<sforshee> melodie: that would be my suggestion
<melodie> ok
<melodie> very good
<melodie> sforshee, I have to reboot, thanks and see you!
<shyamrajendran> Hi Guys
<shyamrajendran> I just noticed an issue with pre-4.11 linux kernels. We have skb_warn_offload() noise in special cases like this when a GSO skb has skb->ip_summed != CHECKSUM_PARTIAL. This could be set due to multiple external factors during virtualization such as optimization of checksum computation on the host.  https://access.redhat.com/solutions/654283 The change to avoid this warning dmesg has been put in kernel 4.11 onwards http:
<shyamrajendran> http://elixir.free-electrons.com/linux/v4.10/source/net/core/dev.c#L2675 http://elixir.free-electrons.com/linux/v4.11/source/net/core/dev.c#L2688. I know Ubuntu LTS might not get 4.11 any time soon so is there a way we could request back porting this change to previous Ubuntu releases? 
<apw> shyamrajendran, file an ubuntu bug against linux (ubuntu-bug linux) and fill in the info and references to the patch etc
<apw> then drop the bug number in here so we can find it.
<shyamrajendran> Thanks @apw
#ubuntu-kernel 2017-07-07
<wilei> Hi! Should there be (in the mainline-crack GIT repository) tags for 4.11.8 and 4.11.9 kernels? I'm trying to build custom kernel from mainline-crack and after "git fetch" the command "git checkout -b `cat COMMIT`" I get error: 'fatal: reference is not a tree: f82a53b87594f460f2dd9983eeb851a5840e8df8' and that's for 4.11.9. And the command "git tag" doesn't return 4.11.9 nor 4.11.8...
<apw> wilei, what does COMMIT contain ?
<apw> wilei, the master repo for that has 4.11.9 in it
<wilei> apw, COMMIT is copy of http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11.9/COMMIT
<apw> does the instructions tell you to git checkout -b `cat COMMIT`
<apw> that sounds wrong to me
<apw> git checkout -b test `head -1 COMMIT`
<apw> wilei, does that work ?
<wilei> I'll try that
<apw> wilei, where are the instructions you are following
<wilei> that worked. but wierdly that `cat COMMITÂ´ worked for v.4.10.17... :) 
<apw> as i suspect we have enhanced the content of COMMIT at some point, perhaps our instructions are wrong
<wilei> apw, I'm mixing these instructions: https://wiki.ubuntu.com/Kernel/MainlineBuilds and https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<apw> (and if they say that command they are)
<apw> wilei, ok the only reference on that page to COMMIT is not related to the contents of the COMMIT file in a mainline build
<wilei> files http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10.17/COMMIT and http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11.9/COMMIT doesn't differ that much 
<apw> wilei, perhaps so but you are asking it to interpolate those two lines on the end
<apw> of the git ceckout -b
<apw> so you get:
<wilei> yeah
<apw> git checkout -b v4.10.17 17a4d48033813f2ba893d6918fa2931afcd9af02
<apw> which is asking ot make a local branch under the name of a likely existing tag
<apw> that is just asking for trouble
<apw> the first line is the tag name in that repo which you want, the second line is a check
<apw> so we can tell if the tag changes, which it never should
<wilei> true :) thanks!
<apw> git checkout -b <useful branch name> `head -1 COMMIT`
<apw> makes sense
<wilei> but actually not :) 
<wilei> git checkout -b v4.11.9 `head -1 ../v4.11.9/COMMIT` returns fatal: Cannot update paths and switch to branch 'v4.11.9' at the same time.
<wilei> and if I run command "git checkout -b dev f82a53b87594f460f2dd9983eeb851a5840e8df8" I still get error "fatal: reference is not a tree: f82a53b87594f460f2dd9983eeb851a5840e8df8"
<wilei> the f82a53b87594f460f2dd9983eeb851a5840e8df8 is reference for tag v4.11.9 which is missing from mainline-crack
<wilei> mainline-crack as git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack
<wilei> but it exists in git://kernel.ubuntu.com/virgin/testing/crack.git
<wilei> "git tag | grep v4.11" doesn't return v4.11.8 nor v4.11.9 when done in clone of mainline-crack, so the tags are missing :)  
<apw> wilei, no you already have a branch
<apw> you made it when it went wrong before
<apw> don't use tag names for your branch
<apw> and use a "new" branch name with using -b
<wilei> only branches I've in my clone are master and v4.10.17
<wilei> and v4.10.17 is checkouted just like I was trying to checkout v4.11.9 
<apw> wilei | git checkout -b v4.11.9 `head -1 ../v4.11.9/COMMIT` returns fatal: Cannot update paths and switch to branch 'v4.11.9' at the 
<apw> if it is saying that, you already have a v4.11.9 _thing_ in your repo
<wilei> and I tried this too: "git checkout -b wdev f82a53b87594f460f2dd9983eeb851a5840e8df8" resulting "fatal: reference is not a tree: f82a53b87594f460f2dd9983eeb851a5840e8df8"
<apw> you cannot trivially name a branch the same as a tag
<apw> yeah use the tag name
<apw> git checkout -b wdev v4.11.9
<wilei> apw, that gives: "fatal: Cannot update paths and switch to branch 'wdev' at the same time."
<wilei> now I got it working, there was some problem with git fetch so I had to clone repo again
<apw> wilei, sounds odd, as that error is nothing to do with fetching, but hey, if it is working life is good
<lucasrangit> What is the reason for having debian.master and debian.hwe-edge in https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/?h=hwe-edge ?
#ubuntu-kernel 2017-07-08
<apw> lucasrangit (N,BFTL), becaus hwe-edge is a derivative of another branch which is represented in the debian.master contents
#ubuntu-kernel 2017-07-09
<NickTux> Hello, I think the failure is due to mainline Kernel and not Ubuntu or Launchpad specific. Please read the log: https://launchpadlibrarian.net/327891117/buildlog_ubuntu-xenial-amd64.linux_4.9.0-360.201707092056_BUILDING.txt.gz
<NickTux> Similar to this ?  https://lkml.org/lkml/2016/8/23/577
#ubuntu-kernel 2018-07-02
<averono> How can i build kernel version 4.15.0 in ubuntu? There is a problem...
#ubuntu-kernel 2018-07-03
<bdmurray> jsalisbury: Have you seen anything like bug 1779827?
<ubot5> bug 1779827 in Ubuntu "Started gnome display manager. dispatcher service" [Undecided,Confirmed] https://launchpad.net/bugs/1779827
<jsalisbury> bdmurray, I haven't seen a pattern yet, but I'll dig into that bug
<bdmurray> jsalisbury: thanks, its rather incomplete but could be serious
<jsalisbury> bdmurray, Yeah, I'll ask for screen shots, etc.  I'll see if I can reproduce it too.  Thanks for the heads up!
<m0x90> Hello, I noticed that the amd64 package linux-image-4.15.0-24-generic-dbgsym is not in http://ddebs.ubuntu.com/pool/main/l/linux-hwe/. Instead only an unsigned one is present.
<sforshee> m0x90: that's correct. The kernel in linux-image is identical to the one in linux-image-unsigned, except that it is signed, so the debug symbols from the -unsigned package will work.
#ubuntu-kernel 2018-07-05
<ad-n770> hi, we saw some back and forth for between kernel 4.13 and for 4.15 for linux-generic-hwe-16.04 package earlier this week
<ad-n770> please could you tell me what are the plans with respect updating the kernel?
<tomreyn> ad-n770: back and forth how? do you mean hwe vs hwe-edge?
<ad-n770> we saw linux-generic-hwe-16.04 pull a 4.15 kernel earlier this week
<ad-n770> but today it's referring to a 4.13 kernel again
<tomreyn> ok, that's news to me. i'm not part of the kernel team (nor an ubuntu developer), so can't confirm this observation nor reliably answer your question.
<corn13read> Anyone know why kernel.ubuntu.com is down?
<corn13read> or how long it will be down?
<corn13read> port 80 is closed
<corn13read> possibly just a FW issue
<tomreyn> this was since solved by #canonical-sysadmin
<corn13read> appreciate it
<tomreyn> so do i
#ubuntu-kernel 2018-07-06
<klebers> ad-n770, we had to revert the meta packages for the 4.15.0-24 kernel and derivatives because of an issue found by users after the promotion to -updates
<klebers> ad-n770, we will be releasing the fix along with all the changes that were pulled sometime in the next couple of weeks
<tomreyn> is there an existing script extract current (from systemd times) initrd's like this? https://paste.ubuntu.com/p/MQ296gq7RQ/
<tomreyn> * TO extract
<tomreyn> i know i can cut it with dd or whatever, but don't plan to reinvent a possibly existing wheel
<cjwatson> tomreyn: unmkinitramfs(8) is what you want, I think
<tomreyn> thanks cjwatson. this seems to be missing from (or rather not yet be present in the version of) xenial's initramfs-tools, but i see that bionics' has it.
<tomreyn> right, xenial has 0.122ubuntu8.12, the command was added in debian's 0.126
#ubuntu-kernel 2019-07-01
<cjwatson> Spads: Could I get "juju status" from the new bionic/juju2 production LP git environment?  I'd like to work out where I can rsync logs from :-)
<cjwatson> Err, no idea why I asked that here, sorry, must have got my windows confused somehow
<apw> cjwatson, heheh that is what happens when you have 250 channels
#ubuntu-kernel 2019-07-02
<kbingham> Hi all, I raised a launchpad bug a month ago requesting CONFIG_VIDEO_VIMC be added as a module to the ubuntu kernel configs. (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831482) but it's seen no updates since I created it on the 3rd of June. Is there anything I can do to progress this topic?
<ubot5> Ubuntu bug 1831482 in linux (Ubuntu) "VIMC module not available (CONFIG_VIDEO_VIMC not set)" [Undecided,Confirmed]
<apw> klebers, ^
<klebers> kbingham, hi! I have added it to our list of bugs to investigate, thanks.
<kbingham> klebers, Thanks :) Not really much to investigate. It's just a kernel module that doesn't currently get built.
<kbingham> And secure-boot makes compiling my own modules such a pain now adays (just registered my own key, and done a self sign)
<apw> and it might be a heap of insecure code which is off for a reason, or it might be an oversight
<apw> hense it needs investigating to understand how it happened
 * kbingham works in linux-media so if you have any concerns about the quality of that code please do report it
#ubuntu-kernel 2019-07-06
<aiena> Hi I am just starting to learn kernel driver development.
<aiena> I built a 5.0 kernel from kernel.org with the ubuntu .config file and the modules along with a test module I made.
<aiena> I was following a talk from 2005 at the linux australia conference where one Rusty talks about driver development. There he uses a debian image file without drivers and kernel for QEMU but with the rest of the basic linux system in it.
<aiena> I had resized this debian image file system so that I can install the built modules into it to run with the compiled kernel 
<aiena> when I do `make INSTALL_MOD_PATH=/mnt/qemu modules_install` it seems to install modules from previous kernels too into the image
<aiena> is this normal my image is 1GB but runs out of space because of this
#ubuntu-kernel 2019-07-07
<aiena> I was trying to build my own kernel for ubuntu. I followed https://wiki.ubuntu.com/KernelTeam/GitKernelBuild instructions. When I get to the ` make deb_pkg` command I get errors.  https://paste.ubuntu.com/p/jYSKNH23sW/ is the log. What is the cause?
<aiena> Is there a way to do incremental makes if I use the deb-pkg system
<aiena> ?
#ubuntu-kernel 2020-06-29
<dsmythies> Any chance that file naming in the kernel mainline PPA can be fixed? They have been broken, missing the release candidate postfix for kernel 5.8-rc1, -rc2, and -rc3. Reference: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8-rc3/
<apw> dsmythies: which file naming
<tomreyn> supposedly the .deb's?
<rafaeldtinoco> #detach #ubuntu-kernel
<dsmythies> Yes the .deb files. For example: this: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8-rc3/amd64/linux-headers-5.8.0-050800-lowlatency_5.8.0-050800.202006282330_amd64.deb should be this:https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8-rc3/amd64/linux-headers-5.8.0-050800rc3-lowlatency_5.8.0-050800rc3.202006282330_amd64.deb. Myself, I don't care becuase I compile the kernel myself, but others use the PPA compiled version.
#ubuntu-kernel 2020-07-01
<slanck> i got a kernel crash dump and would like to analyze it with GDB but the .crash file on /var/crash doesn't seem to have a CoreDump file when I unpack it using apport-unpack
<slanck> and using the .crash file or the file generated on /var/crash/DATE/dump.XYZ with GDB gives incorrect file format
<slanck> I would like to have the CoreDump file to analyze it using GDB, apport-retrace gives the error of missing files
<slanck> it's working now
<gpiccoli> slanck, you need to use the crash tool in order to analyze kernel dumps
<gpiccoli> need was a strong statement...it's recomended that you use the crash tool, it's meant to that heheh
<gpiccoli> for userspace core dumps, gdb is usually the proper tool =)
<slanck> gpiccoli: hi
<slanck> yes, I was using the crash command. The issue was that, i don't know yet why, but the dump.XYZ file generated on /var/crash/ was kind of incomplete
<slanck> i regenerated the crash using echo c > /proc/sysrq... and now the dump.XYZ file worked as expected using crash
<slanck> the first dump is not detected as a kdump file
<slanck> sudo file 202007010222/dump.202007010222 
<slanck> 202007010222/dump.202007010222: data
<slanck> sudo file 202007011558/dump.202007011558 
<slanck> 202007011558/dump.202007011558: Kdump compressed dump v6, system Linux,
<slanck> i don't know what happened, when the first dump file was generated, i didn't have the linux-crashdump package installed even though there was a crash command available on my system
<slanck> i then installed the linux-crashdump and generated a new crash and got the result shown above, i guess is that, without linux-crashdump, it generates a dump but kind of incomplete
<slanck> when i installed linux-crashdump, it didn't replace the crash tool i had already on my system, i checked the version and it's the same 
<slanck> crash 7.2.8
<slanck> gpiccoli: thank you anyways
<gpiccoli> slanck, interesting, so you got a bad dump on the first time. The package linux-crashdump is a meta pkg that maps to all usually required packages to have kdump working
<gpiccoli> the real packages you need to collect the dump properly (and they all come with linux-crashdump) are kexec-tools, kdump-tools and makedumpfile
<gpiccoli> The crash package (also included on the metapkg) brings the crash binary to analyze the vmcore =)
<slanck> @gpiccoli thank you very much, the bad dump was generated triggering a kernel bug and the good dump shown above was generated using echo c > /proc/sysrq, it's worth to mention I am working on a custom kernel
<slanck> i will trigger the bug again later today and see if it generates a "good" dump now that I've installed linux-crashdump
<gpiccoli> awesome, hope it works!
<gpiccoli> What version of Ubuntu are you suing ?
<gpiccoli> *using
<gpiccoli> I suggest to increase a bit the crashkernel memory if it's not working reliably, also worth trying to capture the console output during the kdump kernel boot
<slanck> Ubuntu 20.04, it's a custom kernel based on vmlinuz-5.4.0-37-generic
<slanck> i had some issues with crashkernel I guess because I am using a KASAN-enabled kernel
<slanck> initially the system was only able to boot properly when I configured the VM with more or equal 6GB of RAM, less than that and I got a crash during boot
<slanck> with 6GB of RAM, i had to increase crashkernel memory up to the point I got kdump properly configured and working
<slanck> with working I mean being able to load the kexec kernel and creating a dump file on /var/crash but I didn't need to investigate the dump file until today
<slanck> I had to set crashkernel=2048M to get to that point
<slanck> oh, sorry, the VM has 12GB of RAM and crashkernel=2048M
<slanck> i triggered the kernel bug again and now it seems it working fine, the issue seems to be that the package linux-crashdump was missing
<slanck> it kind of works, i don't have the registers when the system crashed
<slanck> crash> i r
<slanck> The program has no registers now.
<slanck> gdb: gdb request failed: i r
<slanck> crash> 
<slanck> sudo crash vmlinux_symbols dump.202007011645
<gpiccoli> is "i r" a command on crash? I'm not sure
<gpiccoli> try checking some structure or some pointer you know the address, like linux_banner or something like this
<weskrasko> Hi, #nm sent me here. I followed some instructions on a site to fix my Nvidia drivers, ran "sudo ubuntu-drivers autoinstall", fixed Nvidia but then after reboot, all my network interfaces are gone!
<weskrasko> So I ran ip link show as recommended in other channel. Shows only lo.
<weskrasko> Ran lspci, shows Ethernet and Wireless cards, but dmesg doesn't seem to show any of that.
<weskrasko> They said maybe my kernel is now not loading the firmware/driver/module's needed? I don't know what happened, my wifi was working "out of the box" before this.
<jeremy31> weskrasko: was there a recent kernel update?  You might want to see if the linux-modules-extra was also installed for that kernel version
<weskrasko> Thanks, how would I do that?
<weskrasko> And yes, right after I ran the command above I did a normal update as I always do, I saw kernel and firmware stuff. NEver had an issue with udpating so thought nothing of it.
<jeremy31> weskrasko: check in terminal>  dpkg -l | grep linux-modules-extra-$(uname -r)
<weskrasko> Nope, no limux-modules-extra for current kernel
<weskrasko> How can I fix with NO connection? Download deb?
<jeremy31> weskrasko: you can use grub menu to boot into older kernel, then install the linux-modules-extra for the newer kernel
<weskrasko> OMG thank you it worked!! Never had that happen before, but at least it's back up. :)
<sarnold> jeremy31: nice :D
#ubuntu-kernel 2020-07-02
<ogra> apw, before someone writes a clickbait article about it ... mind taking a look (or someone else from the kernel team) at https://discourse.ubuntu.com/t/possible-gpl-violation-in-kernel-mainline-ppa/17073 ?
<apw> ogra, the link they complain about lists the URL of the patches on like line 4
<ogra> apw, but not the v5.7.2 and onwards builds ... thats what he complains about i think
<ogra> (not sure ... it is just that the topic header makes wonderful clickbait for some blogger to pick up so i think it deserves some words)
<amitk> ogra: if there wasn't going to be a click-bait article, now there is likely to be one ;-)
<ogra> lol
<ogra> yeah, i should probably have PMed
<apw> ogra, but it points directly to the git repository in which the patches are commited now
<amitk> the jump from missing links to packaging scripts to a GPL violation is stretch in any case
<apw> we've changed how the source is presented
<ogra> ah
 * apw responds on discourse
<slanck> @gpiccoli thank you very much for the help yesterday, i've solved the issue
<gpiccoli> That's great slanck =)
<gpiccoli> What it was?
<slanck> i don't know exactly, i have just installed linux-crashdump and regenerated the crash dump
<gpiccoli> great then! 
