#ubuntu-kernel 2005-11-21
<BenC> damnit, ppc failed to build
<infinity> BenC : Still around?
<jianggw>  http://ubuntuforums.org/attachment.php?attachmentid=3590&d=1132034495 is a structure chart of community drawn by me.Is it correct?
<jianggw> in the webpage http://www.ubuntulinux.org/community/processes/council,it wrote:The Chairman of the Community Council is yet to be determined.Isn't sabdfl the chairman?
<infinity> Ouch.  I had a PPC buildd still churning on the -1.1 kernel build... With a 50 gig log file.
<infinity> BenC : ^^^
<infinity> BenC : Same thing on two ia64 buildds, with -1.1 and -2.2... Stuck in config loops.
<fabbione> morning
<maks_> zul: your blog isn't syndicated on planet.u.c??
<janimo> any easy (bandwidth-wise too) way of switchung to vanilla linus branch inside the ubuntu git tree?
<janimo> current ubu kernel doesn;t boot and I want to see if it's same with upstream
<BenC> infinity: wow, I knew they would hang in the config, but I didn't think it would do some weird loop and fill the log file
<doko> BenC, do you already build the kernel with 4.0?
<janimo> BenC, is there an easy way to switch the ubuntu git  tree to a vanilla one without excessive downloading?
<janimo> I'd like to see if vanilla fails to boot as well
<janimo> if not I'll probbaly dl from kernel.org
<jbailey> BenC: Side effect of no tty?
<zul> gday
<BenC> doko: these kernels are built with gcc-4.0
<BenC> janimo: not really
<janimo> thanks, I'll use kernel.org then
<BenC> janimo: there is one way to help
<BenC> but it's hard to explain
<BenC> repo's can share the .git/objects directory
<doko> BenC: hmm, svenl did claim that the 64bit kernel cannot be built, see #336167
<BenC> doko: it built for me
<janimo> BenC, thanks, I guess I'll just go tar.gz since git repos take up a _lot_ of space too
<doko> anyway, it's a svenl report
<BenC> maybe they did something to work around it in 2.6.15
<BenC> hehe, very true
<janimo> basically I have a softlock on boot on a HP laptop and want to track it down
<janimo> will send feedback as I progress
<BenC> janimo: that's why all my repo's share the objects, reduces space
<janimo> why doesn't git do that by default since objects are immutable?
<BenC> janimo: regression between breezy and dapper kernel?
<janimo> yes, 12 works 15 nope
<BenC> janimo: there's probably a way to do the clone and tell it to use something else for the shared objects
<janimo> break in some acpi list setup
<BenC> janimo: ah, ok
<janimo> ok I'll read up the horribly detailed git docs
<janimo> bbl
<BenC> jbailey: ping
<jbailey> BenC: pong
<BenC> jbailey: do you have a G5 that you can use to test a 2.6.15 kernel?
<jbailey> BenC: Yes. ppc64-smp, but it's my main machine so I don't like to reboot often.  Can we time it for lunch time or end of day?
<BenC> jbailey: sure, I'll put the image at p.u.c/~bcollins/2.6.15/powerpc/
<BenC> thanks
<jbailey> 'kay, lemme know.
<zul> blah
<CataEnry> hi all
<BenC> hello
<janimo> BenC if we find bugs which are in upstream too, tell you or lkml?
<janimo> i.e are you the MUX for all ubuntu work :) ?
<BenC> if you know the correct upstream person, then to them directly
<BenC> but mainly you can go through me (bugzilla) and I'll proxy
<BenC> if there's an upstream person, they'll be the one asking you to do things, so me being int he middle of a quick debug cycle is a waste
<janimo> ok, I am recompiling now I think I found the commit which broke booting on my laptop
<janimo> was in 2.6.12 got reversed in 13
<janimo> worked in breezy but does not now
<makx> fabbione: ping
<zul> feck!!!
<lamont-away> Default I/O scheduler
<lamont-away> > 1. Anticipatory (DEFAULT_AS) (NEW)
<lamont-away>   2. Deadline (DEFAULT_DEADLINE) (NEW)
<lamont-away>   3. CFQ (DEFAULT_CFQ) (NEW)
<lamont-away>   4. No-op (DEFAULT_NOOP) (NEW)
<lamont-away> choice[1-4?] : Default I/O scheduler
<lamont-away> > 1. Anticipatory (DEFAULT_AS) (NEW)
<lamont-away>   2. Deadline (DEFAULT_DEADLINE) (NEW)
<lamont-away>   3. CFQ (DEFAULT_CFQ) (NEW)
<lamont-away>   4. No-op (DEFAULT_NOOP) (NEW)
<lamont-away> choice[1-4?] :
<lamont-away> fabbione: that's why buildd.mmjgroup.com was ENOSPC
* lamont-away kicks the kernel
<lamont-away> BenC: you have time to make sure hppa doesn't go into a terrible loop?  (or maybe we could teach make oldconfig to _DIE_ when it gets EOF, instead of looping...
* lamont-away adds 'fix hppa configs' to his list of things to do later
<CataEnry> bye all :)
<BenC> lamont-away: yeah, I was trying to figure that out aswell
<lamont-away> BenC: you have an hppa box?
<BenC> not running yet
<BenC> still sitting with my other servers from the move
<lamont-away> BenC: I'll figure out what config file options we need to add.. I still haven't bothered figuring out jit yet...
<lamont-away> so I'll probably just paste you some options...
<zul> BenC: might arent you popular today
<dilinger> BenC: autograph my chest!
<lamont-away> BenC: wow.  mega changes in the config
<lamont-away> BenC: are any of the hppa cvs/jit/whatever changes merged into that source?
<BenC> dilinger: I have a broken PCI card I can use to carve it in
<lamont-away> because I expect there is a new config set for hppa with the right answers...
<BenC> lamont-away: no, nothing
<BenC> lamont-away: and there's no "hppa" changesets listed in git-log, so it's probably going to be a mess to get the patch to apply :)
<BenC> dilinger: append :) to that
<lamont-away> BenC: ok.  I'll just ignore the poor beast for a day or 3. :-(
<lamont-away> but it would be nice if make oldconfig died instead of looping...
<lamont-away> your fame would be uncountable...
<BenC> lamont-away: working on it
<dilinger> hehe
<BenC> sweet
<BenC> if I do silentoldconfig, it will die with an error if tty is not valid, and it has a question
<BenC> shit
<BenC> make-kpkg calls oldconfig, not me :/
<dilinger> yea
<dilinger> i did that for debian's kernel packaging
<dilinger> er, sorry, as a helper script, to verify that the configs were correct
<dilinger> http://svn.debian.org/wsvn/kernel/dists/trunk/scripts/testconfigs?op=file&rev=0&sc=0
<BenC> ok, I've got a fix that works
<BenC> checks stdin for feof() if fgets() fails
<zul_> hmm...
<zul_> jbailey: ping
<jbailey> zul_: On phone.
<jbailey> 'sup?
<zul_> jbailey: i got a basic git package together last night im going to try to finish it off tonight and ill send you the diff so you can have a look.
<jbailey> Ah, cool!
<zul_> just let me know you need
<zul_> laster
<CataEnry> hi all
#ubuntu-kernel 2005-11-22
<BenC> lamont-away: ping
<lamont-away> BenC: I have about 30 seconds - wassup?
<BenC> lamont-away: good news, ia64 failed immediately when oldconfig ran :)
<lamont-away> heh
<BenC> just wanted to pass that on
<lamont-away> right. I'll add that right ahead of hppa then.
<lamont-away> anyway, need to run.  back in a few hours.
<lamont-away> and yes, I'll read scrollback
<BenC> I have an ia64 with ubuntu, but I need to update it and get it running again
<BenC> later
<Yagisan> BenC ping
<BenC> Yagisan: pong
<Yagisan> BenC: This bug http://bugzilla.ubuntu.com/show_bug.cgi?id=9972 is confirmed on breezy
<Yagisan> BenC: rtl-8139 doesn't handle buggy acpi gracefully
<BenC> Yagisan: ok, please email me back about that
<BenC> I'm about to go to bed
<Yagisan> BenC: no worries, I just got the bugzilla email
<fabbione> BenC: the sparc build loops the same way as the others btw
<fabbione> BenC: never mind.. that was with 2.2
<fabbione> gonna test build 3.3 soon
<fabbione> BenC: -> #ubuntu-meeting
<jbailey> BenC: Got a kernel you want tested on ppc64 before I settle in?
<BenC> jbailey: I will in about 10 minutes
<jbailey> BenC: 
<jbailey> 'ksy
<jbailey> 'kay
<jbailey> I'll avoid settling in until then. =)
<fabbione> hey BenC 
<BenC> hey
<BenC> I missed the dev meeting :/
<fabbione> yes
<BenC> had my days all mixed up
<fabbione> follow up with JaneW
<BenC> fabbione: are you doing a security compile on davis?
<fabbione> yes
<fabbione> i can slow down if you need
<BenC> if you can, I'd like to get a kernel for jbailey
<BenC> thanks
<fabbione> sure
<BenC> Load == 322 :)
<fabbione> going down now
<BenC> my build wouldn't even start after 30 seconds
<BenC> thanks, mine starts now
<fabbione> BenC: i am down to -j50
<CataEnry> hi all
<fabbione> you can take the other -j250
<jbailey> Dev meeting?
<jbailey> Oh hey, it's Thursday.
<fabbione> jbailey: Dapper Devel Meeting
<BenC> jbailey: first Dapper Development Status was 5 hours ago :)
<BenC> cool, I wasn't the only one
<BenC> yeah, the day threw me off
<jbailey> We can say a void fell over the timezone.
<BenC> I knew it was today, but the time was out of whack
<jbailey> Or at least, it looked all dark outside.  I got scared, hid under the covers.
<jbailey> With my eyes closed.
<BenC> lol
<BenC> I'll claim DST messed me up
<jbailey> JaneW: Thats my excuse and I'm sticking too it!
<chmj> bah, I missed it also 
<chmj> JaneW: I was offline, axxess has authenticaiton problems with the Saix vs IS thing going on 
<BenC> we need a cronjob that sends out reminder emails
<chmj> I agree 
* BenC doesn't do so well marking his own calander
<BenC> jbailey: this is going to take longer than 10 minutes, btw
<jbailey> BenC: Is the time still reasonable to measure in minutes?
<BenC> probably less than an hour is about as close as I can come
<BenC> fabbione and his damned security build is hogging cpu :)
<fabbione> BenC: dude.. export CONCURRENCY_LEVEL=250
<fabbione> and you are all set to hog 5 times more cpu than me
<BenC> ok, I'll let it rip then
<BenC> fabbione: I am working on sparc64 config's right now
<fabbione> BenC: coolness
<BenC> so -4.4 should build on sparc64
<fabbione> neat
<BenC> going to try to get all the config's atleast "buildable"
<fabbione> lamont was mumbling something about hppa 
<BenC> great, still linker errors with ppc64
<BenC> there's no end to the madness
<fabbione> do you prefer to -security? ;)
<BenC> think I'll pass :)
<fabbione> BenC: i was thinking that it might be a good idea to start making debian/changelog a changelog again.. or somehow slam git log diff between releases somewhere
<jbailey> BenC: What linker errors?  Is it related the the binutils breakage?
<fabbione> given .15 initial fun is finished.. we should turn it into something more serious
<fabbione> and get proper release names from JaneW :P
<BenC> jbailey: I've no idea really
<BenC> fabbione: yeah, I've been more detailed in my recent changelog entries after -1.1
<BenC> but something automated to take line 1 from git-log would be nice
<BenC> fabbione: I was thinking of using Linus' shortlog (in git) to create something to include with normal changelog
<fabbione> exactly
<fabbione> we need to keep in mind two things:
<fabbione> * we need make git reverse $id something "simple" for non-kernel team people
<fabbione> * we might die now and nobody would know how to do it
<fabbione> it was easy with dpatch
<BenC> it's easy with git too
<fabbione> but we need to find the same compromise with git
<fabbione> yeah
<BenC> but it wont be a "here are the patches, here's the description of each one" kind of thing
<BenC> just a running changelog
<fabbione> i was more thinking like:
<fabbione> Changes by BenC:
<fabbione>  * add foo:
<BenC> yeah, the git-log shortlog will do that
<fabbione>     - changeset IDS:
<fabbione> without extra info on why there are for ex 10 changests 
<BenC> changeset IDS will be a 64-bit SHA hash :)
<fabbione> that's fine
<fabbione> but i can just say
<fabbione> for i in $id[1]  $[2] ; do git revert $i; done
<fabbione> that would make it fairly trivial to revert stuff
<CataEnry> bye all
<fabbione> BenC: did you finish your build on davis?
<BenC> yeah, ppc64 isn't going to happen
<fabbione> uh?
<fabbione> why not?
<BenC> binutils failures
<BenC> really odd linker failures for ppc64
<fabbione> ah
<fabbione> ok
<BenC> ~bcollins/build.log if you want to take a look
<fabbione> on davis?
<fabbione> uh yeah
<fabbione> here it is
<fabbione> *cough*binutils die!*cough*
<BenC> jbailey says the linker messages are just warnings
<BenC> if so, I can fix the missing symbols and get a build
<fabbione> i assume it's still worth to give it a shot
<jbailey> It'll keep me from pouting at him. ;)
<BenC> I'll keep working on it
<fabbione> ok
<fabbione> warty build is done
<fabbione> i am going to set a low CONC_LEVEL for hoary
<fabbione> so you have more machine power
<BenC> found the problem with the missing symbols
<BenC> some of the video drivers use nvram, but the video is built-in, and nvram is modular
<BenC> the easy fix is to make nvram built-in, but I want to do the right thing and make kconfig handle this
<mjg59> Some of the video drivers use nvram? Wow.
<BenC> not sure if there's a way to say "if CONFIG_FB_MATROX=y, and CONFIG_NVRAM, make CONFIG_NVRAM=y"
<BenC> yeah, like 4 or 5 of them
<BenC> they don't require it, but if nvram is configured, they use it
<mjg59> Oh, right
<mjg59> How weird
<BenC> need a weak dep between the video drivers and nvram, but this may be a lost cause
<mjg59> Oh, only on PPC?
<mjg59> That makes more sense
<BenC> nvram is generic, but I think the video stuff is more geared toward ppc, yes
<BenC> oh, interesting, CONFIG_NVRAM isn't even on ppc64
<BenC> so I just need some ifdef's
<zul> heylo
<jbailey> Zoool
<zul_^> that was weird
<zul_^> i got hit in the face with a soccer ball last night
<zul_^> it was kind of bradyesque
<jbailey> And this is cuasing you to spawn yourself multiple times?
<BenC> did your nose swell to the size of the ball?
<jbailey> And is "bradyesque" your way of saying they'll be nine of you in a moment?
<BenC> and did you have to miss the big dance? :)
<zul_^> bastards..
<fabbione> hey zul
* fabbione heads off to school
<fabbione> later guys
<BenC> later
<zul_^> later
<BenC> sweet, all the linker warnings aside, I now have a ppc64 vmlinux
<zul_^> nifty
<BenC> jbailey: I should have a kernel for you soon now
<jbailey> BenC: It's passed that point this time?
<BenC> yeah, it's on to modules now
<BenC> missing symbols there wont cause it to fail to make a .deb, so I think we're clear for a test
<jbailey> woohoo =)
<zul_^> BenC: psst..my patches ;)
<mjg59> Can we have CONFIG_EDD on pls k thx?
<BenC> zul_^: yeah, I have them, just need to merge them
<BenC> trying to get as many arch's building as possible so people can start testing
<BenC> mjg59: i386 and amd64?
<mjg59> BenC: Yeah
<BenC> ok, done
<BenC> does it need to be =y or is =m ok?
<jbailey> BenC: I'm at a good time to test ppc64.  Is it ready?  If not, i'll check in after lunch.
<BenC> it's doing the dpkg-deb right now
<jbailey> Nice timing. =)
<BenC> less than 5 minutes
<BenC> yes, perfect :)
<mjg59> BenC: =m should be fine, I think (though it's a fairly tiny amount of code)
<lamont-away> Automatically append version information to the version string (LOCALVERSION_AUTO) [Y/n/?]  (NEW) aborted!
<lamont-away> Console input is closed. Run 'make oldconfig' to update configuration.
* lamont-away owes BenC a beer or some such
<BenC> lamont-away: -4.4 will have a sane, probably buildable config
<lamont-away> cool.
<BenC> jbailey: people/~bcollins/2.6.15/
<BenC> powerpc64-smp debs are there
<jbailey> BenC: Thanks!
<mdz> BenC: what are the blockers remaining for updating the metapackages to 2.6.15?
<BenC> lrm, and has to be post flight 1
<BenC> infinity is supposed to be working on lrm
<BenC> post-fligh1 was Kamion's request
<mdz> I would prefer that we transition that to be your responsibility, so that you don't block on someone else for ABI changes and new upstreams
<mdz> post-flight1 is fine, but that's today or tomorrow
<mdz> (with luck)
<BenC> I was under the impression that I needed to be hands-off for lrm
<mdz> from whom?
<dilinger> BenC: have you guys enabled CONFIG_EDD in 2.6.15
<dilinger> ?
<dilinger> it's disabled in breezy
<BenC> I just did
<dilinger> ah, cool
<BenC> will be in -4.4
<dilinger> static or module?
<BenC> module, would static be better?
<dilinger> doesn't really matter, i was just curious
<BenC> it's modular
<dilinger> (working on parted geometry stuff)
<jb-770> Ben, no  worky ;)
<jb-770> How much of the kernel panic do you want?
<jb-770> It panics when running hwclock.
<infinity> BenC : I don't mind you touching LRM for ABI changes, I was just personally holding off on updating it since I want to shove in shiny new drivers that need a new X (which needs a new glibc, which needs a new binutils)
<infinity> BenC : No guarantees that the current source would even build against 2.6.15 right now.  If in doubt at all, you may be better off just waiting a day for the other stuff to fall into place.
* infinity tries to go back to sleep now.
<jbailey> infinity: Bah, you don't need sleep.
<mjg59> It sounds like the new ATI drivers actually do power management properly
<mjg59> Which is very nice of them
<jbailey> mjg59: The free ones, or the binary ones?
<mjg59> The binary ones
<BenC> do the binary ATI drivers work on PPC?
<BenC> jbailey: any luck with ppc64?
<jbailey> BenC: crash and burn when setting hwclock
<jbailey> BenC: I don't think there are ppc binary drivers.
<jbailey> I wish there were.
<jbailey> Screen savers would suck so much less.
<BenC> hwclock huh...let me check the config's
<BenC> yeah, my screen saver shows some weird white lines brushing to the left of the images
<BenC> jbailey: ping
<jbailey> BenC: pong
<BenC> jbailey: were you able to get the panic from the ppc64 test?
<jbailey> BenC: Eh, I had asked you which part you needed, I hadn't seen an answer.
<jbailey> I can reboot and get it easily enough.
<BenC> I totally missed where you came on as jb-770
<jbailey> Ah, sorry. =)
<jbailey> Lemme reboot to catch that.
<BenC> nah, was my fault, if you get a chance to get it, just email it, to bmc@visi.net (regular email is down)
<jb-770> Lets give this a try.
<jb-770> No serial console on the ppc64 box any parts you want in particular?
<jb-770> Or should  I copy all of it?
<jb-770> I should probably figure out the oops catcher at some point.
#ubuntu-kernel 2005-11-23
<ispiked> how active is the mailing list for ubuntu kernel dev?
<mdz> ispiked: http://lists.ubuntu.com/mailman/listinfo/kernel-team
<ispiked> ok, that's manageable.
<jbailey> BenC: Heya
<jbailey> BenC: Is there something I should be testing for you on the 2.6.15 kernel I already have (like preloading the module), or should I wait until you spin a new one?
<zul> heyl
<CataEnry> hi all
<CataEnry> bye all
<BenC> has there ever been any discussion on ubuntu's kernels using CONFIG_ACPI_BLACKLIST_YEAR?
<BenC> mjg59: ping
<zul_> nope...
<mjg59> BenC: Hi
<BenC> mjg59: any benefit or not from us using ACPI_BLACKLIST_YEAR?
<BenC> going through fedora's kernel, and just trying to see what I want to pull from them, and they enable this option for like year 2000
<BenC> so anything < 1999 doesn't get acpi with acpi=force
<BenC> without
<mjg59> BenC: Do we have any bugs filed on it?
<BenC> well, we have bugs with acpi being buggy, and people having to disable it
<BenC> will this fix it, I don't know
<BenC> just wondering if anyone had a better picture of whether this option was a needed evil, or just plain useless
<mjg59> No idea, I'm afraid
<BenC> ok, thanks anyway
<zul_> i havent heard of it before so no idea either..
* BenC mulls over the module gpg signature patches
<dilinger> zul_: so i dunno where you stand w/ cogito and git-core packages..
<dilinger> but the guy who's taking over maintainance of the debian packages offered me comaintenance, and send me some test packages
<dilinger> if you're interested in poking at them
<janimo> how do I get to an old state in the current git tree. i.e I want 2.6.13
<janimo> I find git unlike any other SCM I worked with :(
<janimo> can I specify commits using regexp mathing their desc or only commit ids?
<zul_> dilinger: i have a preliminary git only package
<zul_> i need to test some a bit more and ill put a debdiff on my website tonight
<zul_> bbl
#ubuntu-kernel 2005-11-24
<zul> heylo
<jbailey> =)
<zul> damn alsa is broken
<crimsun> which chipset?
<zul> hold on
<zul> Multimedia audio controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
<zul> with 2.6.15-rc1-ubuntu1 was working yesterday on my laptop though
<zul> or it could just be xmms
<crimsun> ok, so in "broken" you mean it's muted, or ALSA doesn't load, or ...?
<zul> alsa doesnt load
<crimsun> 2.6.15-3.3, correct?
<crimsun> we need to push 1.0.10 final in, then
<zul> -1 i think i havent updated yet
<zul> unknown pcm
<crimsun> I know 2.6.15-3.3 works (for sound) on the ThinkPad X41-2527
<crimsun> (same chipset, same driver, same codec)
<zul> blah...maybe ill reboot
<zul> brb...going to reboot
<zul> ugh...why do people write better bug reports
<jbailey> Eh?
<zul> im just complaing about bug reports that dont provide enough info
<jbailey> Perhaps you meant "don't"?
<zul> perhaps I do
<zul> im just too lazy to type right now
<zul> BenC, pingishy
<makx> where do i find the ubuntu pts?
<infinity> We don't have one.
<infinity> Assuming by "pts" you mean "packages.qa"
<makx> well subscribtion on package upload, yes the link from qa.
<infinity> Yeah, we have no such thing.
<makx> by the way hello infinity
<infinity> Eventually, we will, but not right now.
<infinity> And hi.
<makx> how are you doing?
<infinity> I'm pretty much done being sick.
<infinity> And I plan on working tomorrow a bit, despite it being a weekend, so if you want to sit down and talk initramfs stuff tomorrow, we can.
<makx> ok, i'll be around
<infinity> Cool.
<infinity> I'll make a note to ping you or something.
<fabbione> BenC: ping?
#ubuntu-kernel 2005-11-25
<BenC> fabbione: pong
<mjg59> BenC: I've found a problem with the SATA suspend/resume patch
<mjg59> The pci_set_power_state it adds seems to hang one of the machines I have here
<fabbione> BenC: 
<fabbione> cp arch/powerpc/boot/images/vmlinux.coff   debian/tmp-image/boot/vmlinux.coff-2.6.15-4-powerpc
<fabbione> cp: cannot stat `arch/powerpc/boot/images/vmlinux.coff': No such file or directory
<fabbione> make[2] : *** [real_stamp_image]  Error 1
<fabbione> make[2] : Leaving directory `/usr/src/linux-source-2.6.15-2.6.15/debian/build/install-powerpc'
<fabbione> make[1] : *** [kernel-image-deb]  Error 2
<fabbione> make[1] : Leaving directory `/usr/src/linux-source-2.6.15-2.6.15/debian/build/install-powerpc'
<fabbione> make: *** [binary-debs]  Error 2
<fabbione> this is building the latest git
<fabbione> on ppc
<fabbione> it seems like kernel-package needs more ppc love
<fabbione> BenC: well.. fixed the k-p issue
<fabbione> Linux daltanius 2.6.15-4-powerpc #1 Sun Nov 20 08:32:02 CET 2005 ppc GNU/Linux
<fabbione> i'd say it boots :)
<anavim> fabbione, I thought git was written by linus on ppc..
<fabbione> and what has to do with what i pasted?
<anavim> you said kernel-package needs more love.. sorry, I will shut up now
<anavim> ppc support seems to be 500% better than it was three years ago, but still way behind i386, I know
<BenC> fabbione: yeah, I fixed that locally
<BenC> fabbione: I had to remove the coff and mkvmlinux stuff from the kernel image though
<BenC> fabbione: since we don't support oldworld macs, can we do away with mkvmlinux support on ppc?
<BenC> mjg59: ping
<infinity> BenC : We can't install on oldworld macs (simply because we can't boot a CD there), but I'm not sure how much that means we don't "support" them... (I use an OldWorld for the large majority of my Ubuntu work)
<BenC> infinity: so you have to use mkvmlinux for that?
<BenC> infinity: if we want to still support it, I may need some help in getting the debian/post-install.powerpc script working again, because the objects for mkvmlinux are either moved or missing
<mjg59> BenC: Hi
<BenC> mjg59: sata-suspend-resume: do you have a fix for that, or should I backout that whole patch?
<mjg59> BenC: Backing out the whole patch would be bad
<mjg59> I traced it down to the pci_set_power_state (or whatever it's called)
<BenC> should I just remove the pci_set_power_state?
<mjg59> Yeah, that seems to work here
<mjg59> It'll mean slightly higher power draw, but at least it ought to work
<mjg59> One of the affected laptops is for the Andalucia rollout, so we need to decide whether it's worth a breezy-updates or just leaving it to Guadalinex to sort it themselves
<BenC> mjg59: would changing it to like D2 or something be better?
<mjg59> BenC: No idea, I'm afraid
<mjg59> I'll give it a go if you like
<mjg59> (Probably later on this evening)
<BenC> yeah, some sort of low power state would be better than none
<mjg59> Ok, no problem
<BenC> ok, thanks
<fabbione> BenC: ok, the coff thing was removing 5 lines from rules in k-p
<fabbione> BenC: i have no idea about old/new world, war of worlds and so on...
<fabbione> still getting familiar with ppc
<BenC> yeah, that's what I have too
<BenC> fabbione: old world macs have to use BootX bootloader (non-free, requires hfs partition, etc)
<BenC> it's a lot of weirdness
<fabbione> new world does require the hfs partition still.. 
<fabbione> but well
<fabbione> no biggie
<BenC> fabbione: FYI, I just pushed the -rc2 merge, so if you want to test that you can
<BenC> no, newworld doesn't for me
<fabbione> /dev/hda2         Apple_Bootstrap boot                    1954 @ 64        (977.0k)  NewWorld bootblock
<fabbione> this one
<fabbione> without i can't boot
<BenC> it's a bootstrap partition, yes
<BenC> yeah, I have that
<BenC> oldworld is a lot more complicated :)
<fabbione> ehhe ok
<BenC> fabbione: FYI, the e3k is up, so I'll try a build today
<fabbione> BenC: cool
<makx> infinity : ping?
<makx> sorry for beeing late
<fabbione> [   72.913516]  pcmcia: Detected deprecated PCMCIA ioctl usage.
<fabbione> [   72.913525]  pcmcia: This interface will soon be removed from the kernel; please expect breakage unle
<fabbione> ss you upgrade to new tools.
<fabbione> [   72.913529]  pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details.
<fabbione> BenC: anyway .15-rc2 is go on ppc
<ispiked> mjg59: what do you mean by hang? hanging when it's resuming?
#ubuntu-kernel 2005-11-26
<mjg59> ispiked: No, hangs on suspend
<zul> lheylo
<BenC> fabbione: sparc64 will be a go with -4.4
<BenC> atleast it will build
<BenC> getting ready to boot the e3k with it
<zul> cool
<fabbione> BenC: cool
<Earthpig> anyone about?
<Earthpig> ANy kernel dev types awake?
<fabbione> hi
<Earthpig> Is that a hi, I'm awake? :)
<CataEnry> hi all
<CataEnry> bye all
<jbailey> Anyone know off hand if Ben has a new ppc64 kernel to test with rtc fixes?
<CataEnry> hi all
<zul> heylo
<jbailey> DoubleChuck!
<zul> hehe
<Earthpig> Anyone know the best way to get a driver added to the kernel images?
<Yagisan> submit bug + patch ?
<Earthpig> Is that preferable to packaging it as a -module thing?
<Earthpig> Basically, options are: 1) patch straight into the kernel source; 2) package as a separate source .deb that builds a -module.deb which make-kpkg can use.
<Earthpig> There are additional utilities associated with the driver, so I can see some merit in a single source .deb that spits out multiple, but my understanding is that users still have to build the kernel module themselves, even with the -module.deb option.
<Yagisan> well, if you do bug + patch, and the kernel devs are happy with it, then the users won't need to build it themselves
<jbailey> Earthpig: At this point we don't have a good way of making sure that modules are automatically rebuilt when kernel 
<jbailey> ABIs change.
<jbailey> When that happens, packaging separate will work.
<Earthpig> True. The code looks like shit though ;) WOuldn't suprise me though if I was told to run it through indent first.
<jbailey> But in most cases the truly correct answer is to get it in upstream.
<Earthpig> Well, the driver is in -mm but not yet vanilla.
<Earthpig> (arcmsr, for reference)
<Earthpig> When you say upstream, do you mean vanilla or debian? 
<Yagisan> vanilla
<Earthpig> Crap. :) If it's in -mm but not yet vanilla, I'm guessing I can't push any harder.,
<Yagisan> Ubuntu doesn't use Debian kernels TTBOMK
<Earthpig> I've noticed the patch list is different.
<Earthpig> Hrm. I only just discovered that protected methods are also package-wide.
<Earthpig> oops wrong channel
<jbailey> Earthpig: If it's in -mm, you might be able to ask Ben to sync it in.
<Earthpig> does ben have an address?
<Earthpig> (not registered... can't privmsg)
<jbailey> Private message is almost always the wrong solution anyway.  There's no reason for the discussion to be private.
<Earthpig> agreed.
<jbailey> If BenC's not around atm, I'd suggest emailing the ubuntu-kernel list, or filing a bug in bugzilla with the patchsets from -mm that you want.
<jbailey> That way a discussion can happen around the idea.
<BenC> what's up?
<jbailey> (Or we could remember that Ben doesn't nick highlight on his name.. *g*)
<BenC> yes, Ben gives me too many false positives :)
<jbailey> Yeah, I still do it for Jeff.  It helps me catch people talking about me. =)
<BenC> lol
<jbailey> I want per-channel nick highlights.
<BenC> Earthpig: what driver?
<Earthpig> ben: arcmsr
<BenC> sata driver?
<fabbione> hey BenC
<Earthpig> RAID controller.
<BenC> fabbione: hey, sparc64-smp fails to boot, but I'm tracking it down
<Earthpig> PCIe or PCI-X host-side, SATA-II on the disk side.
<fabbione> BenC: ah
<fabbione> BenC: what about UP?
<BenC> didn't try UP
<fabbione> ok
<BenC> the failure is in alloc_percpu() (kmalloc_node fails), so I suspect UP works
<Earthpig> -mm has been tracking the driver from Areca; 2.6.15-rc1 contains the current driver; broken-out/areca-raid-linux-scsi-driver.patch should apply cleanly against any 2.6.x tree.
<BenC> Earthpig: send me an email with the brokenout patch from -mm and I'll look at it
<BenC> 2.6.15-rc1 contains the driver?
<BenC> then we're all set, since dapper has 2.6.15-rc1
<Earthpig> Sorry. 2.6.15-rc1-mm2
<BenC> ah
<Earthpig> I meant the -mm patch against it :)
<BenC> ok, can you get the driver patch broken out and email me that?
<Earthpig> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc1/2.6.15-rc1-mm2/broken-out/areca-raid-linux-scsi-driver.patch
<Earthpig> That's the broken out patch.
<BenC> ok, thanks
<Earthpig> You might want to read the comments at the top.
<Earthpig> I can compile it out of tree easily enough, but it is inconvenient. :) Especially since / and /boot are on it.
<Earthpig> Since it's a module and self-contained, the risk that it'll b0rk other stuff should be quite low. Dunno how strict your criteria are for inclusion.
<BenC> wow, this code is commented to the hilt
<Earthpig> good or bad? :D
<BenC> like 20 lines per #define in the header :)
<BenC> depends on your opinion of proper commenting I guess
<Earthpig> Well, good that there are comments. Bad if they all say it's shit. :)
<BenC> Earthpig: any crashes with it?
<Earthpig> Not sure yet. Will know by the end of the week; awaiting a new motherboard.
<Earthpig> It doesn't crash on load :D
<BenC> I'll mark it for inclusion...are the tools required to use it?
<Earthpig> Nope; it has BIOS configuration.
<BenC> ok
<Earthpig> Tools are handy though; supports online expansion and raid level migration.
<Earthpig> (and stripe-size migration)
<BenC> you have to agree to be my bug-bitch if there are any problems reported on it though :)
<Earthpig> If it means it normally shouldJustWork[tm] , I'm fine with that.
<BenC> it should, just nice to have an extra tester for external-drivers like this
<Earthpig> Yeah, no problem.
<BenC> wow, nice that the driver is maintained by areca directly
<BenC> should be able to get support from Erich easily enough
<Earthpig> Yeah. They're a pretty friendly bunch.
<Earthpig> Hell, they did a press release when it make it into -mm.
<BenC> hehe
<BenC> maybe they'll do one when we put it into ubuntu? :)
<Earthpig> If you let them know, that wouldn't surprise me.
<Earthpig> Support have also been good; they took my mobo issue up with Asus directly.
<jbailey> Earthpig: Do you have contact information for them? =)
<jbailey> I can take care of that arrangement. =)
<Earthpig> For Areca?
<Earthpig> Asus?
<jbailey> Whichever company did the press relesae.  Was that Areca?
<Earthpig> Yeah.
<jbailey> I can't see it ebing asus.
<jbailey> But we have a hardware certification program, and I'd love to introduce them to it.
<Earthpig> http://www.areca.com.tw/news/html/n_press%20release.htm is the existing press releases.
<Earthpig> March/April are the ones I'm thinking of.
<BenC> erich@areca.com.tw is the guy supporting the driver
<Earthpig> kevin34@areca.com.tw is the support guy i've been dealing with.
<dilinger> i keep hearing really good things about areca
<dilinger> too bad their stuff is so much more expensive than everything else
<Earthpig> It's cheaper that 3ware.
<dilinger> nah
<dilinger> 8port sata controllers are like $200 more than 3ware
<dilinger> sorry, $100 more.  i bought a refurb'd controller, which is where the other $100 came from ;)
<Earthpig> Native SATA-II?
<Earthpig> 3ware for a long time were using PATA internally and bridge-chips.
<Earthpig> I can also only see PCI or PCI-X. PCI gets saturated easily once you go to any 2-disk setup. And PCI-X adds more than $100 to the cost of the motherboard.
<dilinger> i doubt it; the 9500s-8 is what i ended up getting
<Earthpig> Do you get better than 90MB/sec from it?
<dilinger> it hasn't arrived yet
<Earthpig> Heh ok. :)
<Earthpig> At least your drivers are in already. ;)
<Earthpig> benc: want my email address for later?
<BenC> email me, or I'll lose it
<BenC> bcollins@ubuntu.com
<BenC> my inbox is the only static data store I have
<Earthpig> ok will do
<BenC> thanks
<BenC> if I could turn emails into stickies, I'd be happy
<chmj> neccesity is the mother of invention 
<Earthpig> With BeOS, you could. :)
<jbailey> BenC: You need on of those SLP label printers. =)
<BenC> hehe
<BenC> anyone know if the sky2 driver is stable now?
<BenC> if I can avoid sk98lin for dapper I will
<zul> bah...how can you not have a bootdisk for a server?
<fabbione> BenC: .15 on ppc seems pretty stable
<fabbione> have been running it for a while now
<fabbione> except suspend/resume that choacks on some large penises..
<fabbione> but that's a known upstream problem
<fabbione> benh is working on it already
<BenC> yeah, it's been running for over a week on my G4
<BenC> glad it's not an isolated incident :)
<fabbione> ehhehe
<fabbione> unfortunatly the new model is barely supported
<fabbione> i need to bitch Olof 
<mjg59> BenC: Uhm.
<mjg59> BenC: Why did we disable apic by default on uniprocessor machines?
<mjg59> That just breaks a different set of machines
<mjg59> There's hardware that needs apic support now
<BenC> mjg59: it was a patch I pulled from fedora, but I hadn't decided on whether to leave it on or not
<mjg59> Yeah. I think it's the wrong solution.
<BenC> easy enough to disable it, it's a config option
<BenC> will be disabled in my next push
<mjg59> BenC: For instance, the bug you pulled the patch from is about hardware that requires the apic to be on...
<mjg59> Ok, cool
<BenC> I didn't get it from a bug, just went through all the fedora patches, and that one looked atleast interesting to have in
<mjg59> Ah, ok
<mjg59> The bugzilla entry referenced, then
<mjg59> BenC: Any chance we can get the driver from http://rtl8180-sa2400.sourceforge.net/ ?
<mjg59> Moderately common 802.11 chipset
<BenC> sure, I'll look into it
<mjg59> (I'm just going through the list of wireless drivers)
<infinity> BenC : Say, any idea why my laptop claims to not have a CD drive when I boot with 2.6.15?
<BenC> infinity: my G4 does the same thing
<BenC> does it show in dmesg, and just not work in the desktop?
<BenC> mines actually there, just gnome doesn't use it
<mjg59> BenC: Also, there seems to be a driver for the softmac prism54 chipsets appearing
<infinity> BenC : No, mine doesn't even show in dmesg.  Just plain ain't there.
<BenC> mjg59: yeah, I have a softmac patch, which is also needed for bcm430x
<mjg59> Ok
<mjg59> The stuff from http://jbnote.free.fr/prism54usb/ ?
<BenC> infinity: ide?
<infinity> Yep.
<mjg59> (Most. Misleading. Name. Ever)
<BenC> infinty: drives show up?
<BenC> fucking {arch}
<infinity> Erm, SATA, not IDE.
<zul> mjg59: send me an email and ill do it tonight
<infinity> And yes, hard drive shows up, CD not.
<infinity> The CD drive ALMOST shows up.
<BenC> infinity: "almost"?
<infinity> [17179573.012000]  ata2: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:0407
<infinity> [17179573.012000]  ata2: dev 0 ATAPI, max UDMA/33
<infinity> But nothing after that about the drive (like vendor ID, etc)
<BenC> tried modprobe sr_mod?
<infinity> No dice.
<infinity> Oh well, I have other stuff to do, I'll have to whine to you about it later.
<mjg59> I should really try to get hold of one of the softmac cards for testing
<Earthpig> benc: any idea when the next push is going to be?
<mjg59> BenC: Also, last time I checked we didn't seem to have the zd1211 firmware
<mjg59> Not sure what we want to do about that, or what license it's under
<BenC> is it 100% useless without the firmware?
<mjg59> BenC: Yeah
<mjg59> By "we" I mean Ubuntu - it's in Debian
<BenC> interesting that we even have the driver in the first place then
<mjg59> As a package, rather than in the kernel
<BenC> well, if it's similar to the current firmware distribution terms we can just include it like we do now
<BenC> debian package doesn't even have a license or anything in the .orig.tar.gz
<mjg59> It's in the upstream driver release, as a bunch of hex in a GPLed header file
<mjg59> BenC: Ok, we don't seem to have prism54 support for softmac PCI devices
<infinity> My favourite.
<mjg59> But there's a driver that ought to (at least partially) work now
<BenC> GPL'd hex, lovely
<BenC> totally contradicts it's own license
<mjg59> infinity: Oh, I still need to do that vga16fb patch, don't I?
<mjg59> BenC: Well, they're the copyright holders, so.
<mjg59> It ought to be distributable
<infinity> mjg59 : I have something on my hard drive here.
<mjg59> infinity: Oh, cool. Just changing the ysize and timings?
<infinity> mjg59 : I stole the 640x400 timings from the X vga drive.  If you happen to know that those aren't "correct", let me know.
<infinity> s/drive/driver/
<infinity> I need to do some testing here before I push the patch to Ben.
<BenC> mjg59: source code == "prefered form of the work for making modifications"
<infinity> And I also need to make the same changes to syslinux.
<mjg59> infinity: As far as I know, they're good
<infinity> BenC : It's hazy if you're the copyright holder.  Much less hazy if you are obfuscating someone else's code.
<infinity> mjg59 : If you have an urge to dig through the asm in syslinux and find the right spot to make the change, that'd be cool.
<infinity> mjg59 : Though, I can find it easily enough.
<mjg59> infinity: Hahahahaahahahahaha (dies)
<infinity> mjg59 : What I'd really dig is for someone (*stare*) to make usplash a proper blocking daemon, so we can stop this silly "usplash & ; sleep 1" business.
<mjg59> Oh, yeah. What's the sleep for, again?
<mjg59> Should really just add a daemon() call
<infinity> mjg59 : Because usplash takes a while before it's ready to accept the first write commant.
<infinity> command, too.
<mjg59> Oh, yes
<BenC> ok, zd1211 will be in -4.4 too
<infinity> mjg59 : If it blocked until it was ready, then backgrounded itself, all would be well.
<BenC> zd1211-firmware that is
<mjg59> Just add daemon() before it starts the idle loop
<mjg59> BenC: Rock
<infinity> mjg59 : Oh.  And a curiosity.  Did yuo have a good reason for using tty8, or did it just seem the thing to do?
<mjg59> infinity: I can't remember
<mjg59> I'm not even sure if I did
<mjg59> That might have been someone else's diff
<mjg59> I thought I just grabbed the current console
<infinity> mjg59 : It cauases a certain amount of scary if, say, your disk check fails, you get dropped to tty8, and you can't type.
<infinity> mjg59 : If that's someone else's fault, and you have no idea why, I may unfault it back to using the current VC, cause it seems a bit... Wrong.
<mjg59> Yeah. 
<mjg59> infinity: Ok, syslinux just does                 mov ax,0012h            ; Set mode = 640x480 VGA 16 colors int 10h
<mjg59> (nngh whitespace breakage)
<infinity> Yeah, but in which file? :)
<mjg59> graphics.inc
<infinity> I grepped for 10h, found a few too many, and put it on my "look closer in a few days" list.
<mjg59> In the "vgasetmode" function
<infinity> Rock.  Lifesaver, you are.
<mjg59> infinity: There doesn't seem to be an int 10 mode for 640x400
<infinity> I'll fix both this week then, and if we get 2.6.15 as the default kernel on flight-2, we can have end-to-end testing of the new mode.
<mjg59> 640x350 is 0x10
<infinity> mjg59 : I'm pretty sure I found one when I was googling before.
<infinity> Maybe not.
<mjg59> Oh, I want to do something really nasty to the framebuffer
<mjg59> I want a sysfs parameter that, when set, discards all framebuffer reads or writes silently
<mjg59> So that way we can avoid anything touching the framebuffer until we've POSTed and so on
<infinity> Perverse.  I like it.
<mjg59> It's trivial
<infinity> You'd do that at the fbcon level, I assume, not touch each fb driver?
<mjg59> Yeah
<infinity> Well, put me on the "yes please" bandwagon for that.
<infinity> That may fix my "breezy doesn't resume from hibernate" issue on my laptop.
<Mithrandir> mjg59: you're evil.  But in a good way.
<mjg59> Mithrandir: ?
<Mithrandir> mjg59: the discard writes hack.
<mjg59> Ah
<BenC> zul: ping
<zul> BenC: yo
<zul> i mean pong
<BenC> zul: the i8042 patch you sent me, is there any reason that it should not be submitted upstream?
<zul> no there shouldnt be
<BenC> ok, thanks
<zul> nopr
<zul> heh...my kotd almost works
<zul> http://zulinux.homelinux.net/kotd <-- daily kernel builds automated (its using an old git though)
<BenC> are they apt'able?
<zul> not yet..
<zul> its on my personal box though
<zul> and its only x86
<zul> blah
<zul> BenC: its a start atleast
<BenC> yeah, it'll be needed soon
<jbailey> BenC: I could probably fire off a KOTD for ppc/ppc64 here if you're not setup for it.
<BenC> not setup for any of the automated stuff yet
<BenC> zul: how long do your builds take?
<zul> couple of hours
<jbailey> Using ccache?
<zul> not yet..
<zul> it was just a test run hasnt been optimized yet
<jbailey> I have my package builder hooked to always use ccache.
<zul> jbailey: i wrote a script that does it for me
<jbailey> alias db='linux32 debuild -e PATH=~/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games'
<zul> is there something on the wiki about ccache?
<jbailey> No ide.a
<jbailey> But apt-get install ccache
<jbailey> mkdir ~/bin
<jbailey> cd ~/bin
<jbailey> ln -s /usr/bin/ccache gcc
<jbailey> (repeat for gcc cpp g++ gcc-3.4 cpp-3.4 g++-3.4, etc...)
<jbailey> Then anytime those are called, ccache gets used.
<Mithrandir> echo 'export PATH=/usr/lib/ccache:$PATH' >> ~/.${SHELL}rc ; exec $SHELL
<jbailey> Ooo.
<jbailey> I didn't know about /usr/lib/ccache
<Mithrandir> it's very convenient.
<jbailey> Yup
* jbailey tweaks his alias to use those instead.
<jbailey> alias db='linux32 debuild -e PATH=/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games'
<jbailey> Then run 'db' when you want a ccache enabled build.
<zul> cool...
<jbailey> Note that debuild cleans the path if you're not otherwise careful.
<jbailey> The linux32 applies to me since I'm on ppc64.
<jbailey> You may want to take it out for your arch.
<Earthpig> ccache doesn't go via alternatives?
<Earthpig> oops... you're inserting ccache on the path somewhere else so that it calls alternatives.
<jbailey> Earthpig: No, because you need to be able to trivially *not* use gcc for validation.
<jbailey> BenC: Thinking of which, do you have a ppc64 image for me to test?  Otherwise I will start my afternoon's worth of work.
<BenC> jbailey: no images yet
<BenC> jbailey: CCACHE_DISABLE=y debuild, btw
* zul kicks vmware in the buttocks
<jbailey> BenC: Ah, handy.
<makx> infinity: ping
#ubuntu-kernel 2005-11-27
<zul> mjg59: hmm...i already have a patch for rtl8180 in my tree and i have pushed it to ben already
<fabbione> morning guys
<crimsun> hi fabbione 
<fabbione> hi crim
<LaschW> may there be a chance to have the ipt_TTL module (I'm not talking about ipt_ttl) in the next kernel images for dapper? There are more and more ISP's who don't allow more than one computer conected so manglint TTL's to a fix value would be very helpfull.
<LaschW> s/manglint/mangling/
* fabbione fails to see how TTL can help with that
<LaschW> fabbione: $IPT -t mangle -A OUTPUT -o $INET_IFACE -j TTL --ttl-set 128
<fabbione> still doesn't help...
<LaschW> fabbione: Most ISP's only check TTL, so up to now
<LaschW> fabbione: ?Why not?
<fabbione> according to RFC the max internet radius is 30
<fabbione> or better
<fabbione> there cannot be more than 30 hops between 2 hosts
<fabbione> if an ISP doesn't allow more than one machine to connect
<fabbione> it's clearly not TTL that's going to help you
<fabbione> because each machine generate it's own packet with its own TTL
<fabbione> so that rule would only increase/reset a TTL to 128
<CataEnry> hi all
<LaschW> fabbione: And this 'per machine' TTL's will be set to the same value on a gateway using ipt_TTL
<mjg59> fabbione: ISPs can drop packets with a TTL of 28 when they expect it to be 29
<fabbione> mjg59: when you traverse a NAT box, TTL is regenerated in the new pkt afaik
<LaschW> fabbione: And for this there is a need for the ipt_TTL module, as RH does
<fabbione> it's easy to workaround at client side ;)
<fabbione> i could just 'mangle' the outgoing packet to a TTL 30 and zack
<fabbione> i hide the other boxes behind one
<fabbione> but well.. let see what Ben has to say
<LaschW> fabbione: Thats what I'm talking about. You need ipt_TTL for this
<fabbione> LaschW: so you need to workaround...
<LaschW> fabbione: I now how to do this! But I think most Ubuntu Newbies don't. According the fact that the target group of Ubuntu are new Linux Users...
<LaschW> fabbione: Or are you expecting new Ubuntu users to build their own kernel modules first? ;-)
<fabbione> LaschW: i find weird that's not builded
<LaschW> fabbione: Pardon my broken english... What do you mean with 'i find weird that's not builded'
<fabbione> according to iptables man page it's there
<fabbione> meaning that's supported by vanilla kernel
<fabbione> config:CONFIG_IP_NF_MATCH_TTL=m
<fabbione> config:CONFIG_IP_NF_TARGET_TTL=m
<fabbione> werid
<fabbione> weird
<LaschW> fabbione: Hhhm, In the beginning I muddled ipt_nat and ipt_NAT. And it seems many docs do so likewise...
<LaschW> fabbione: Ubuntu linux-image is missing 'config:CONFIG_IP_NF_TARGET_TTL=m'
<fabbione> LaschW: the past i did was from .15
<LaschW> fabbione: So does Debian...
<LaschW> fabbione: grep IPT /boot/config-2.6.12-9-k7
<fabbione> interesting
<fabbione> it looks like it gets automatically unset
<fabbione> fun
<LaschW> fabbione: s/IPT/TTL/ pardon me...
<fabbione> yeah i got that
<LaschW> fabbione: I've been digging netfilter mailing lists if there might be any incompatibility using ipt_nat and ipt_NAT at the same time, but dindn't find any.
<CataEnry> cya next time
<fabbione> LaschW: it makes more sense to look at Kconfig
<fabbione> but i don't have time right now
<LaschW> fabbione: Kconfig, the KDE GUI Tool?
<fabbione> no
<fabbione> Kconfig the set of files that acutally build the kernel :)
<fabbione> the KDE tool is make xconfig
<fabbione> gnome: make gconfig
<LaschW> fabbione: Ok, I was a bit shocked, to be honest. :-))
<LaschW> fabbione: I had in mind this weird Kcontrol kernel config module *laugh*
<fabbione> tsk
<fabbione> :P
<LaschW> fabbione: :P, fullack
<chmj> the current kernel source in git is unbuildable? or am I missing something ? 
<zul> mjg59: ping
<mjg59> zul: Hi
<zul> mjg59: i already wrote a patch for rtl8180 i already pushed it to benc
<mjg59> zul: Ok, cool
<zul> so it will get in when it gets in
<BenC> zul: speaking of the rtl8180, can you email me the external-driver info for it?
<BenC> I have all your patches in locally, except that one
<BenC> I need to clean it up a little, since it's building with a local copy of ieee80211, and I need to make it use the stock one from net/ieee80211
* dilinger blinks
<dilinger> there's an rtl8180 driver?
<dilinger> url?
<BenC> sf I believe
<dilinger> oh, look at that, partly based on my code
<dilinger> too bad i don't have an rtl8180 anymore
<zul> BenC: ok ill do it tonight
<fabbione> hey BenC 
<BenC> fabbione: hey
<fabbione> smoking break and i will be back in a sec
<fabbione> btw.. .15-rc2 boots on davem box
<BenC> puff one for me
<fabbione> we must be doing something wrong
<BenC> it's too cold and wet to smoke outside
<BenC> ok
<BenC> for sparc64, I used our old config, and did a "make oldconfig" to update it
<BenC> I should do a default config just to see if that works
<fabbione> it's freezing here.. but if i smoke inside i can wave khtxbye to my testicles
<dilinger> BenC: where are you?
<BenC> virginia
<BenC> I should make my office the "smoking room"
<BenC> but I hate all the nicotine getting on my hw
<BenC> s/nicotine/tar/
<dilinger> ah, ok.  not that far away
<BenC> zul: ping
<zul> pong
<BenC> ping: any bugreport to reference for the ali patch?
<BenC> tulip patch that is
<mjg59> http://www.ath-driver.org/ is looking quite promising
<makx> anyone seen infinity?
<mjg59> makx: He's quite possibly asleep right now
<makx> aah ok
<makx> mjg59: you fixed suspend for sesse's laptop. do you send fix upstream?
<mjg59> makx: Not yet, because I'm not convinced it's the right fix
<mjg59> Need to discuss it with PCMCIA upstream
<makx> ok, cool so it's rolling
<zul> BenC: yeah there is..just dont remmber off the top of my head, ill have to check
<BenC> zul: btw, gregkh has a speakup patch I am going to use instead of yours
<zul> BenC: he does? cool..
<BenC> fabbione: A defconfig compile with our tree doesn't boot for me
<BenC> fabbione: I'm going to have to do a stock 2.6.15-rc2 compile to see if I broke something, but I can't see that being the case
<BenC> 99% of the code we introduced either doesn't touch sparc64, or is just drivers that are being compiled modular right now
<mjg59> BenC: Are all the patches from 2.6.12 in the git tree?
<mjg59> BenC: Also, ndiswrapper is completely broken on amd64
<BenC> ndiswrapper never did work properly on amd64 in breezy, IIRC
<BenC> all patches from breezy (except a lot of acpi, and patches that were obsoleted) are in
<BenC> also, minus the sk98lin patch
<BenC> rtl8180 may be a no go in breezy
<BenC> it's using it's own internal ieee80211 stack, and it isn't playing well with the rest of the system
<dilinger> any idea whether the original author reverse engineered the management frames stuff, or got some documentation?
<mjg59> BenC: ndiswrapper worked fine on amd64 in Breezy
<mjg59> We're missing at least the patch that fixes the clock on AMD64s with ATI chipsets
<mjg59> BenC: I'll look into the rtl8180 thing at some stage
<BenC> mjg59: last release from the project was 7 months ago
<BenC> mjg59: do you have a patch name for the amd64?
<dilinger> if someone can hook me up w/ an rtl8180 card, and i don't need to reverse engineer the mgmt frame stuff (that's why i stopped working on rtl8180 in the first place), i'm more than happy to start hacking away at the driver again
<mjg59> BenC: Not off the top of my head. 
<BenC> mjg59: clokc == video clock, or hw clock?
<mjg59> HW clock
<mjg59> It gets two timer interrupts per HZ
<BenC> kernel-apic-timer-fix
<mjg59> That's the one
<BenC> that was still broken for me in breezy
<mjg59> Uhm. How so?
<BenC> it needs to be applied to i386 for k8 chipsets too (like Sempron, which isn't 64-bit)
<mjg59> Oh, right. Eww.
<mjg59> Well, upstream are entirely failing to try to fix it properly
<BenC> I had to boot with noapictimer on my laptop at ubz
<BenC> is it a hw bug?
<mjg59> Seems to be
<mjg59> Windows runs itself off the apic timer rather than using a timer interrupt
<mjg59> So you don't see it there
<mjg59> bcm430x is still rather broken, yes
<mjg59> Its worker queue just fell over on me
<mjg59> dilinger: You're in the US, right?
<dilinger> mjg59: yea; nyc
* mjg59 wonders how to get dilinger an rtl8180
<BenC> mjg59: are you actually getting packets through it yet?
<mjg59> BenC: Oh, christ no :)
<BenC> I'm at a loss here
<BenC> noapictimer doesn't seem to be an i386 option
<BenC> yet it worked for my Sempron using a -k7 kernel
<mjg59> The i386 apic code is quite different to the amd64 stuff
<BenC> it's only in arch/x86_64/kernel/apci.c
<BenC> yeah, but why did the kernel option make my timer work :)
<dilinger> mjg59: know anything around that's vacationing in NY?
<mjg59> dilinger: Afraid not
<fabbione> BenC: ok... i don't think we have any sparc specific patch... where does the boot hang?
<mjg59> BenC: Basically, on the affected chipsets, we either need to drop interrupts from the first apic pin or from irq 0
<BenC> fabbione: can't tell, it doesn't spit anything out, and I can't even do a break to get at the .register and .stack output
<fabbione> ah
<BenC> fabbione: I'm getting the stock -rc2 so I can atleast tell dave that it isn't our fault :)
<BenC> it may be a enterprise bug, since dave doesn't have any machines like this
<BenC> and my U2 is buried in other stuff, so I can't test that right now
<fabbione> BenC: eheh ok.. he is getting a E280R
<fabbione> so he will have no excuses
<BenC> E280R doesn't have the CENTRAL 4-slot hw, so who knows if it will be the same bug
<BenC> if it will show the same bug that is
<fabbione> BenC: if you can push me a .deb somewhere i can probably test it tomorrow
<fabbione> right now i am building gcc-4.0 for the libstdc transition
<fabbione> and i really can't stop it after these many hours
<fabbione> dilinger: ping?
<BenC> ok, I'll get it on people
<fabbione> thanks
<BenC> mjg59: amd64 apic timer patch is in git now
<dilinger> fabbione: yo
<BenC> mjg59: do you think it would be ok to pull -mm's acpi git patch?
<mjg59> BenC: Sure
<mjg59> Oooh ooh ooh
<mjg59> Suspend to RAM has started working on my amd64
<mjg59> I'm actually going to blame vgacon changes for usplash not working any more
<mjg59> Ok, maybe it's not that, then
<mjg59> BenC: Possibly over-optimistic, but is there any chance of more up-to-date orinoco drivers?
<mjg59> Ok, now that's *very* odd
<mjg59> If I run usplash from a console, it looks fine
<jbailey> mjg59: Just not from an Xterm.  Tried that, it was a mistake.
<BenC> mjg59: there's some vgacon patches in -mm
<BenC> may want to look at them
<mjg59> Nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnngh.
<mjg59> 2.6.15 breaks vbetool.
<mjg59> Entirely.
<BenC> one is a doublescan fix, and one is a fix for something else (some other corruption)
<mjg59> Nnnnnngh.
<mjg59> BenC: Have you added anything that changes the behaviour of /dev/mem ?
<BenC> yeah, but it's not in -4.4
<BenC> err, -3.3
<BenC> it's in git though
<BenC> is it breaking something, because I can disable it?
<BenC> elmo had requested the devmem patch
<mjg59> Not sure - I'm having problems trying to make vbetool work, but I think that one's just a symptom rather than a cause
<mjg59> Ah, yeah, it's triggering if I mmap /dev/zero, so probably not you
<mjg59> mmap is returning EACCES
<mjg59> And I can't see why
<fabbione> hmmm
<fabbione> capability?
<mjg59> Running as root
<mjg59> This is on amd64, though
<mjg59> Looking at the kernel, that can only happen if the file is unreadable or unwritable
<fabbione> i remember once they broke capability in such a way not even root could do anything
<mjg59> Hmm. It's claiming that I don't have write access to the file.
<mjg59> Hngh.
<BenC> is this -3.3 or -4.4?
<mjg59> -4.4
<mjg59> Never mind, figured it out
<mjg59> The kernel's just got more picky about mmaping in general
<mjg59> So I've got a vbetool that at least partially works for amd64
<mjg59> And now my amd64 suspends and resumes
<BenC> sweet
<BenC> lamont: ping
<lamont> ack
<BenC> lamont: you'll be happy to know that I did a git pull from the ia64 and parisc repo's today
<lamont> how did it get to be 1330 already!?  sigh
<lamont> BenC: woot!
<fabbione> ia64?
<dilinger> lamont: whee, it's 1530 already! ;p
<fabbione> we did never pull from ia64 repo
<fabbione> oh that might be why ia64 did never boot
<lamont> dilinger: I have appts this afternoon to go deal with. sigh
<mjg59> Hmm. 2.6.15 is resulting in my mouse driver not being loaded.
<BenC> -mm's patches pull from an ia64 repo, so I figured it can't hurt for us to pull too
<fabbione> BenC: are the changes already propagated to kernel.org?
<BenC> it's only like 50k of diff
<BenC> mjg59: odd
<fabbione> mjg59: it works here.. usb mouse
<mjg59> Oh, hang on
<mjg59> psmouse is loaded
<mjg59> mousedev isn't
<BenC> fabbione: they are in 2.6.15-rc1-mm2
<mjg59> Latest hotplug, udev and initramfs-tools
<mjg59> Anyone have any other things to try?
<fabbione> BenC: i meant in our git repo
<BenC> thought mousedev was hardcoded to load
<lamont> BenC: and someone was working on making initramfs happy with ia64 too, so that's good
<jbailey> lamont: Someone other than me?
<mjg59> Yeah, I can just stick it in modules fo rnow
<lamont> jbailey: someone here in the lab
<jbailey> lamont: Cool!
<lamont> (fails on debian too, you see...)
<BenC> fabbione: yeah, this is the first pull I did
<fabbione> BenC: ok
<BenC> afk for about 10 minutes
<BenC> fabbione: oh, just got what you meant, no, I haven't pushed yet
<BenC> trying a build to make sure I didn't break anything
<fabbione> BenC: ehhe ok
<BenC> zul__: ping
<zul__> yo
<zul__> what did i do now? ;)
<fabbione> zul__: you did nothing
<fabbione> that's why we are going to kill you
<BenC> zul__: I have everything I can take from your repo, so if you can kill it, and start fresh, I can start taking things again
<fabbione> isn't time to fix some bugs? ;)
<BenC> fabbione: never tell the prey that it is about to die :)
<fabbione> ehehe
<zul__> BenC: okie dokie
<zul__> there is a global conpiracy agains me
<BenC> zul__: only thing I need is some info on that tulip patch
<BenC> and thanks for the patches too
<fabbione> how did i die?
<mjg59> Remote closed the connection
<fabbione> ah
<fabbione> xchat did die
<fabbione> thanks
<BenC> fabbione: kiko has a question, he'll be here in a sec
<kiko> hey ho
<kiko> fabbione, padrino mio
<kiko> what happened to libipt_ROUTE in breezy?
<BenC> he's wondering what happened to iptables ROUTE between hoary and breezy, says it's no longer there...
<fabbione> ROUTE?
<kiko> granted, it never actually worked :)
<fabbione> that would be iptables is the package.. not the kernel
<kiko> well
<BenC> so that has nothing to do with the kernel?
<fabbione> i would like to understand what this thing was doing
<kiko> I don't quite understand but IIRC netfilter and the kernel have a bit of a incestuous relationship
<fabbione> kiko: yes they do.. that's clear
<fabbione> a libipt_SOMETHING mostlikely need a ipt_SOMETHING.ko in the kernel
<kiko> right
<kiko> okay
<kiko> so what does ipt_ROUTE do
<kiko> it adds a ROUTE iptables target
<kiko> which allows you to do routing changes for packets that match a filter
<kiko> for instance, you can modify the default route used for packets for a specific service
<fabbione> oh yeah i see
<fabbione> you don't need that
<fabbione> iptables are for pussies
<kiko> padrino!
<fabbione> you can just use LAR
<kiko> iproute2?
<fabbione> that's the same i use here
<fabbione> yes
<fabbione> Linux Advanced Routing
<kiko> hmmm
<kiko> I believe we tested that and failed, but we can always try harder
<kiko> okay
<fabbione> kiko: i have working config
<fabbione> +s
<kiko> fabbione, mail something to me?
<fabbione> kiko: my consigliere.. it's no problem at aaaalllll
* kiko lowers head
<kiko> since i'm already chattering about
<kiko> we have one box that has a via-rhine ethernet onboard that just hangs when booting with the breezy kernel
<kiko> we're atm using the hoary kernel
<BenC> sysrq work at all on it?
<BenC> maybe see where it's hanging
<kiko> given it's a diskless box it's pretty unlikely we can use it much.
<kiko> okay, that would be a start
<kiko> let me try and find out where it hangs and poke back
<kiko> BenC, do we have alt-sysrq on by default in our kernels?
<kiko> so we do!
<kiko> thanks
<BenC> I believe so
<zul__> *sigh* 8 year anniversary tonight..
<zul__> later
<fabbione> zul__: have fun
<fabbione> look at the positive side.. you might get laid ;)
<zul__> oh i know i will..
<zul__> laster
<BenC> fabbione: booting 2.6.15-rc2 stock
<fabbione> BenC: cool
<fabbione> anyway.. i am off to bed
<fabbione> good night guys
<BenC> good night
<BenC> sweet
<BenC> fabbione: stock crashes too
<fabbione> ahah cool
<fabbione> gonna tell davem
<fabbione> ehehhe
<fabbione> *grins*
<mjg59> BenC: The rtl8180 driver seems to be actively developed in CVS
<mjg59> (file) Makefile  1.1.1.4  7 weeks  i855crt  Updated to work with current ieee802.11 stack
<mjg59> Looks sort of promising
<BenC> odd, I pulled from CVS
<BenC> and it was broken
<BenC> broken meaning it was popping out all kinds of errors regarding ieee80211 stuff
<BenC> rtl8180-sa2400-dev is the module I checked out
<mjg59> Ah
<mjg59> You want rtl818x-newstack
<BenC> ah,
<BenC> cool, thanks
<mjg59> And rtl8187-newstack/ for USB support
<BenC> fabbione: emailed davem my oops
<BenC> mjg59: lol, the rtl8187-newstack has the .cmd.c files from the kernel build in it :)
<mjg59> BenC: Heh
<chuck_> BenC: 18673
<BenC> chuck_: thanks
<chuck_> no probs
<BenC> this driver is gawd aweful
<BenC> it's using htonl instead of cpu_to_* stuff
#ubuntu-kernel 2006-11-20
<joejaxx> ajmitch: the reason i am asking is about my aforementioned statements about cell processing
<joejaxx> support*
<joejaxx> i do not know if that is any area that ubuntu wants to go in
<joejaxx> an*
<gnomefreak> not sure if this is known or not but lvm is having major issues on the 2.6.19 series kernels it seems
<fabbione> gnomefreak: what kind of issues?
<fabbione> clearly being a bit more specific is totally optional...
<gnomefreak> fabbione: from my understanding its not booting due to initramfs
<fabbione> gnomefreak: it's not a kernel problem. I just uploaded a fix for lvm-common
<gnomefreak> fabbione: ah ok
<fabbione>  lvm-common (1.5.20ubuntu8) feisty; urgency=low
<fabbione>  .
<fabbione>    * Change local-top and hook prereq on mdadm and not md.
<fabbione>    (Closes Ubuntu: #72387)
<fabbione>  .
<fabbione>    * Bump Depends on mdadm to make sure mdadm is available.
<gnomefreak> that would be it ty
<fabbione> if you can't boot in the system, just add "break" without "" to the boot options
<fabbione> that will bring you to initramfs shell
<fabbione> read manually /init
<fabbione> and once you get to execute local-top stuff
<fabbione> make sure to run udev before mdadm
<fabbione> and then lvm
<fabbione> once that's done
<fabbione> crtl+d
<gnomefreak> thats before the update?
<fabbione> if you cannot boot into the system, you will need to recover somehow
<fabbione> and that's a way to do it
<gnomefreak> ok ill let them know ty
<fabbione> if they can't recover well.. they shouldn't be running feisty..
<gnomefreak> they shouldnt be running it anyway IMO
<siretart> fabbione: how about a tag in malone for bugs which potentially break booting the system?
<fabbione> siretart: and what would that solve?
<fabbione> people don't look at malone anyway before upgrading
<fabbione> they only cry afterwards
<siretart> well, I've been looking through a whole bunch of package bug pages for trying to find out what problem ajmitch is talking about
<siretart> he told something about his system wouldn't boot anymore because of some lvm+mdadm fuckage
<fabbione> siretart: and i told him that i was going to work on it as soon as i was back home with test equipment
<siretart> in the end, I didn't find any bug report about his problem, so I refrained from upgrading my system to feisty
<fabbione> siretart: well it was non obvious breakage. there were more than one bug
<siretart> the problems I want to solve: reduction of duplicate bugs filed, better overview if it was 'currently' a good idea to wait with upgrading
<fabbione> and one is still to be sorted
<fabbione> siretart: the bug was filed in lvm-common where it did belong
<siretart> well, somehow I managed to overlook it
<fabbione> there is also a bug in initramfs-tools prereq handling
<fabbione> mdadm was still pointing to udev
<fabbione> but udev was not being executed at all before mdadm
<fabbione> and that was because of lvm prereq on md instead of mdadm
<fabbione> that was defenitily not obvious
<siretart> do you have bugnumbers where I can subscribe to?
<fabbione> #72387
<fabbione> already fixed
<siretart> (you see why I think tags are a good idea?)
<siretart> ok
<BenC> kylem: ping
* BenC wonders where his lacky is
<zul> hey BenC 
<zul> how was the flight back?
<kylem> BenC, morning.
<kylem> BenC, (showering, to answer your question...)
<BenC> zul: yo
<BenC> kylem: you shower before work? :)
<BenC> kylem: Feel like taking on the backlog of dapper/edgy update patches I have?
<kylem> sure.
<BenC> I'll mbox them and send them over...they should all apply to the {edgy,dapper}-updates.git tree's without problems
<kylem> okie doke.
<BenC> do you know if your gpg key is ready for uploads?
<mjg59> Kyle's certainly not in core-dev yet
<kylem> BenC, i don't think i can upload, need to go through technical board or something first.
<mjg59> kylem: I get to hold your career in my hands. Mwahahahahahahaha.
<kylem> mjg59, cute. :P
<mjg59> Now I have to go and move fruitflies between bottles.
* mjg59 departs
<thom> pretty similar really
<BenC> kylem: sent
<kylem> BenC, k.
<Keybuk> this reminds me
<Keybuk> we still don't have a technical board
<zul> heh
<mjg59> Oh, yeah
<mjg59> Wasn't that meant to be sorted by tomorrow?
<gnomefreak> no techboard?
<gnomefreak> no CC either
<kylem> BenC, have you reviewed all these as well, or should i take a look for inanity.
<BenC> kylem: I haven't reviewed them at all, they've just been filling up my u-k mbox
<kylem> i'll try to give them a once-over too.
<zul> heh users are already complaining about 2.6.19
<fabbione> zul: if they complain about mdadm and lvm point them to userland
<fabbione> zul: i am working on fixing mdadm
<siretart> fabbione++! :)
<fabbione> siretart: i won't fix it today tho. i need some time to understand why edgy -> feisty upgrade fails and it happens only at the first time. otherwise a retry will work
* fabbione needs a better test environment than my own ws for that
<siretart> fabbione: I won't upgrade my edgy system to feisty today anyway. I doubt I will find enough time for debugging this week
<gnomefreak> nice warning apt gives when you try to remove mdadm :)
<gnomefreak> s/apt/dpkg
<zul> *sigh*
<kylem> hmm?
<zul> i dislike doing sql
<sioux> hi
<sioux> i have a bad problem with usbdisk on my dell c600. the usbdisk is mouted ok but after a some the system freeze and the mouse too freeze the only thing that i can do is force a restart manually :-( who can help me?
<sioux> I also have some errors in dkesg like cpufreq: change failed with new_state 0 and result 0
<sioux> my distro is edgy but dapper was the same
<sioux> :-(
<BenC> sioux: File a bug and attach dmesg output (file it against linux-source-2.6.17)
<sioux> benc how can i attach a dmesg
<BenC> sioux: dmesg > dmesg.txt
<BenC> The bug tracker has an option to attach files
<sioux> and how can i run the bug traker 
<sioux> [17180475.240000]  cpufreq: change failed with new_state 0 and result 0
<sioux> [17180478.188000]  hdc: request sense failure: status=0x59 { DriveReady SeekComplete DataRequest Error }
<sioux> [17180478.188000]  hdc: request sense failure: error=0xb0 { LastFailedSense=0x0b }
<sioux> [17180478.188000]  cpufreq: change failed with new_state 1 and result 0
<sioux> [17180489.108000]  uhci_hcd 0000:00:07.2: host system error, PCI problems?
<sioux> [17180489.108000]  uhci_hcd 0000:00:07.2: host controller halted, very bad!
<sioux> [17180489.108000]  uhci_hcd 0000:00:07.2: HC died; cleaning up
<sioux> [17180489.108000]  cpufreq: change failed with new_state 0 and result 0
<sioux> [17180489.108000]  usb 1-1: USB disconnect, address 3
<sioux> these errors freeze the system if i plug a usbdisk on dell c600
<sioux> ben collins! did you see the dmesg errors?
<kylem> Unpacking 326 objects
<kylem> Total 326, written 326 (delta 265), reused 0 (delta 0)
<kylem> fatal: unresolved deltas left after unpacking
<kylem> unpack unpacker exited with error code
<kylem> ng refs/heads/master n/a (unpacker error)
* kylem breaks git.
<sioux> ?
<tormod> sioux: I gave you the link to the bug tracker.
<sioux> tormod where is the link
<tormod> sioux: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+filebug
<sioux> :-)
#ubuntu-kernel 2006-11-21
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.19-6.8 uploaded - Ok, this is a good bear. Use it, but there are still a few missing modules.
<infinity> BenC: Argh.  "Ok, this is a good bear"?  Die. :)
<BenC> hehe
<BenC> infinity: I have a new lrm with nvidia 9629 upgrade too
<ajmitch> that will make so many users happy
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.19-6.9 uploaded - This is a bad bear. Use it, but there are still a few missing modules.
<BenC> infinity: lrm and linux-meta coming when I wake up in the morning
<infinity> BenC: You upgrading fglrx too?
<gnomefreak> is there a list of modules that are not in -6 somewhere i can look at? i know nvidia was missing at one point
<cypher1> i am having problems upgrading from a 2.4 kernel to 2.6.18 kernel. Any help ?
<cypher1> the kernel panics saying it cannot mount the root filesystem
<Mithrandir> neither 2.4 or 2.6.18 is, has been or will ever be supported in Ubuntu.
<cypher1> why ?
<cypher1> so does that mean i cannot download and built my own kernel with version 2.6.18 ?
<Mithrandir> 2.4?  Why should it be?  2.6.18?  We're skipping that; edgy was 2.6.17; feisty will be 2.6.20
<Mithrandir> you can, but I would recommend against it.  Why do you want to do so?
<cypher1> Mithrandir: i wanted to learn building it 
<cypher1> Mithrandir: thanks for the info
<Mithrandir> you might want to read the URLs referenced in the topic here.
<gnomefreak> 2.6.19 i thought
<gnomefreak> atleast that is what it is now
<cypher1> yes 2.6.19 is in beta i guess
<gnomefreak> rc5 iirc
<cypher1> i guess 2.6.12 and later has some issues with loading modules parallely
<cypher1> gnomefreak: sorry i did not get it
<Mithrandir> gnomefreak: I said feisty "will be", not "is". :-)
<gnomefreak> cypher1: if i remember correctly 2.6.19 is in the rc5 stage (in general not in ubuntu)
<gnomefreak> Mithrandir: dont we normally keep the kernel we start with?
<gnomefreak> like dapper started with 2.6.15 and ended with it
<gnomefreak> breezy - edgy was like that
<Mithrandir> gnomefreak: BenC said otherwise, iirc
<cypher1> gnomefreak: but by that would not the kernel would be little out of date when a release comes out ?
<gnomefreak> release == stable not in date or out dated
<tepsipakki> BenC: bug #72696
<tepsipakki> hm, malone 72696
<tepsipakki> duh, no ubugtu here, then ;)
<cypher1> bug 72696
<BenC> tepsipakki: ok
<tepsipakki> BenC: is it feasible for dapper-updates?
<tepsipakki> ah, saw your comment
<zul> hey
<BenC> hey zul
<zul> hey BenC how is it going?
<BenC> not too bad
<zul> good
<kylem> argh. out of captain crunch.
<zul> heh
<thom> what in the hells is captain crunch? my only reference is cryptonomicon
<thom> and i've never seen it
<kylem> dude.
<zul> its a cereal
<kylem> best. cereal. ever.
<zul> fruit loops are better though
* kylem plans a trip to .nl with a suitcase full of captain crunch.
<thom> heh. do it!
<Mithrandir> thom: it enabled blueboxing, which is why it's famous.  At least why it's famous in geek circles.
<zul> http://en.wikipedia.org/wiki/Cap'n_Crunch
<zul> kylem: is it still captain crunch in quebec?
<kylem> no clue.
<kylem> i buy groceries in ontario.
<zul> ah
<kylem> since i'm usually in ontario anyway, the loblows on rideau is so darn convenient on the way home...
<zul> yeah it was for me when i was working in queubec
<mjg59> kylem: You don't get to visit .nl until you've been to Cambridge
<kylem> hehe.
<thom> mBdale's european debauchery tour!
<kylem> heh.
<zul> BenC: do we want to get the mactel patches into feisty?
<BenC> yeah, I'm working on them
<zul> ok
<dade`> :)
<zul> later...got another doctor appointment to go to
<trappist> is edgy's kernel supposed to be preemptible?  I ask because it doesn't seem to be.  mouse and everything get very laggy under heavy i/o load, e.g. when installing packages
<dade`> trappist: it is
<trappist> dade`: I see CONFIG_PREEMPT is not set, but CONFIG_PREEMPT_VOLUNTARY and CONFIG_PREEMPT_BLK are y.  mind if I ask what those mean, and how they differ from CONFIG_PREEMPT?
<trappist> ok now I get it - we preempt the big kernel lock (CONFIG_PREEMPT_BKL) and we say CONFIG_PREEMPT_VOLUNTARY=y but there's no /proc/sys/kernel/voluntary_preemption, *and* CONFIG_PREEMPT is not set.  so (please correct me if I'm wrong) only the big kernel lock is preemptible.
<BenC> trappist: correct
<trappist> BenC: why do we not just say CONFIG_PREEMPT=y
<BenC> becomes preempt isn't optimal for a kernel that is supposed to run everywhere
<BenC> s/becomes/because/
<trappist> I assume having separate desktop/server kernels has been brought up and shot down
<BenC> trappist: I guess you haven't noticed that we have a separate server and desktop kernel already :)
<BenC> even on strictly desktop, preempt has some areas where it caused enough of a problem for enough people that the benfits were outweighed
<cmvo> BenC: Hi! I know this is devel only, but it there a way to set the sequence drivers are loaded during boot?
<BenC> cmvo: can you describe your scenario?
<BenC> I'm actually working on something along those lines, I'd be interested in your use case
<cmvo> BenC: I've got a system with a ICH6 with 4 SATA HDs connected to it and also a promise SX-2
<BenC> cmvo: So you're concern is just sdX device ordering?
<cmvo> to which a 5th HD is connected temporarily for backups.
<BenC> cmvo: you're problem can be solved in other ways, mainly by using UUID instead of the device name, for partitions
<cmvo> With no HD connected to the SX-2 the four HDs are sda-sdd. With a HD connected to the SX-2 this becomes sda and the others are sdc-sdf
<BenC> cmvo: Right, you should replace /dev/sdX with UUID=XXXXXXXXXX in fstab and grub's menu.lst
<cmvo> BenC: Thanks, I'll take a closer look at UUIDs. Guess I've been using static /dev for too long :-) Sorry for bothering you.
<BenC> cmvo: No problem
<zul_> hey
#ubuntu-kernel 2006-11-22
<lfittl> BenC: is it intentional that /usr/src/linux-headers-2.6.19-*/include/linux/config.h does not exist anymore?
<zul> yep
<lfittl> k, so if I package a kernel module I should replace it with linux/autoconf.h, right?
<zul> i think you remove it totally
<lfittl> wouldn't that cause problems if there are #ifdefs that require the config #defines?
<zul> i think it was an empty file in 2.6.15 but i would have to look at the code
<lfittl> for 2.6.17 it was: #include <linux/autoconf.h>
<BenC> lfittl: Remove it completey
<BenC> lfittl: The module build system adds "-include .../autoconf.h" now
<BenC> so it's explicitly always there
<lfittl> BenC: k, thanks
<zul> BenC: ping 
<BenC> zul: pong
<zul> should the patch for #6244 go in edgy or bump it to fiesty
<zul> it looks trivial enough for edgy
<zul> er...62444
<BenC> zul: let me check
<BenC> zul: Looks suitable for edgy-updates
<zul> cool
<zul> funny that patch is crack
<KnowledgEngi> hello
<KnowledgEngi> i have a big problem with the kernel
<KnowledgEngi> the problem is that i need to use a software named rosegarden
<KnowledgEngi> this software need a particular kernel
<KnowledgEngi> a low-latency kernel
<KnowledgEngi> this is a software for musician
<KnowledgEngi> and work realtime
<KnowledgEngi> and without a low-latency kernel there is problem with system timer
<KnowledgEngi> System timer resolution is too low
<KnowledgEngi> Rosegarden was unable to find a high-resolution timing source for MIDI 
<KnowledgEngi> performance.
<KnowledgEngi> This may mean you are using a Linux system with the kernel timer 
<KnowledgEngi> resolution set too low. Please contact your Linux distributor for more 
<KnowledgEngi> information.
<BenC> KnowledgEngi: Probably is two fold
<BenC> KnowledgEngi: We can provide a kernel with a proper timer, however that kernel would not be suitable for all people, especially those not needing high resolution timers
<BenC> KnowledgEngi: Second problem is that we always get folks wanting this feature, but no one puts in the time to implement or test it
<BenC> usually we end up hearing about it after release
<KnowledgEngi> you work in the ubuntu comunity ?
<KnowledgEngi> we are ubuntu developers?
<KnowledgEngi> you
<BenC> yes, we == kernel developers == mainly me
<BenC> newly kylem, but for references to the past me :)
<KnowledgEngi> wow
<KnowledgEngi> :)
<KnowledgEngi> is very important for me becouse i work with music
<KnowledgEngi> and i studi music composition in a music school
<KnowledgEngi> studY
<KnowledgEngi> and under ubuntu i has much problem with midi software and notation software
<BenC> right, I understand the issue
<KnowledgEngi> i do not use other tutorial about kernel building
<KnowledgEngi> becouse i think that is possible that after i can have other problems
<BenC> there is an ubuntu specific tutorial at the URL in the topic
<KnowledgEngi> https://wiki.ubuntu.com/CategoryKernel
<KnowledgEngi> this page?
<BenC> yes, look for Build link
<KnowledgEngi> my english is terrible, i'm italian. Can you tall me the specific link good for my problem?
<BenC> I do know that dapper has the proper frequency
<BenC> so if you are using edgy, maybe switch to dapper
<KnowledgEngi> i'm use edgy
<BenC> oh wait, no I switched it back in dapper
<BenC> because of the problems it was causing for laptop users (low battery life)
<KnowledgEngi> i have a pc with case
<KnowledgEngi> i have not a laptop
<KnowledgEngi> :)
<BenC> I know, but the kernel is the same either way...and we can't help the 0.1% of users trying to do music just to make 5% of users reduce battery life
<KnowledgEngi> i hope that in the next ubuntu release there is a possibility to install a prebuild low-latency kernel
<KnowledgEngi> using synaptic
<KnowledgEngi> :)
<BenC> probably is, no one is asking for it much
<BenC> I hear about it once every 2 to 4 months from one person
<KnowledgEngi> much people in channel relater with linux audio speack about this problem with rosegarden and kernel
<BenC> hard to justify the extra build and space on mirrors for a handful of people
<KnowledgEngi> in this age much people work with music
<KnowledgEngi> Dj too
<KnowledgEngi> is not a rarely problem :)
<KnowledgEngi> i know much people that do not use linux becouse have problem with audio
<KnowledgEngi> and midi
<KnowledgEngi> for me now is sufficent just a document that show me the procedure that i need for solve this problem
<KnowledgEngi> the firsth step that i need is this?: https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28CategoryKernel%29
<BenC> that's the only document you need
<KnowledgEngi> i need upgrade to ubuntu dapper ?
<KnowledgEngi> or ubuntu edgy is ok
<KnowledgEngi> ?
<BenC> edgy is newer than dapper
<BenC> stick with edgy
<KnowledgEngi> my english is terrible
<KnowledgEngi> i know that edgy is the new release
<KnowledgEngi> but i do not know if is compatible with this how-to
<KnowledgEngi> becouse 10 minuts ag you tall me something about dapper
<BenC> the howto clearly says it is for edgy
<KnowledgEngi> . /boot/config-2.6.17-10-generic
<KnowledgEngi> where i must to copy it before build the kernel ???
<KnowledgEngi> is possilbe that there is an error in the how-to
<KnowledgEngi> user@ubuntu:/usr/src/linux-source-2.6.17$ ls -l debian/config/i386/
<KnowledgEngi> ls: debian/config/i386/: Not a directory
<KnowledgEngi> cp /boot/config-2.6.17-10-generic debian/Config/config
<KnowledgEngi> is correct ?
<KnowledgEngi> cd debian/Config && make menuconfig 
<KnowledgEngi> debian/rules updateconfigs
<KnowledgEngi> i do not know if is correct
<crimsun> KnowledgEngi: I'll assist you in #ubuntustudio. Please don't ask here, because it's not pertinent to Ubuntu development.
<KnowledgEngi> in ubuntustudio the people tall the same thinh
<KnowledgEngi> thing
<crimsun> KnowledgEngi: I'll assist you in #ubuntustudio. Please don't ask here, because it's not pertinent to Ubuntu development.
<KnowledgEngi> they not give support
<KnowledgEngi> but is related to ubuntu kernel
<KnowledgEngi> becouse i neet to rebuild it
<KnowledgEngi> modifing the config
<crimsun> ok, I don't know if you're just blatantly ignoring what I've repeated, or if you truly can't understand what I'm saying.
<crimsun> I'm in that irc channel _right now_, so please, let's migrate this support issue away from a development channel, ok?
<fabbione> BenC: still around?
<BenC> yeah
<fabbione> i added the pata_via but it seems VERY buggy
<fabbione> if i boot with quiet/splash i get a combinations of segfaults (init) and OOPS
<BenC> weird, others reported it worked very well
<fabbione> oh yeah.. if i remove quiet/splash it boots
<BenC> and this didn't happen before pata_via?
<fabbione> nope
<BenC> very very odd
<fabbione> i will need to grab pics of the OOPS
<BenC> that's worth another bug report
<fabbione> there is nothing i can do at that point
<BenC> oh wait, I bet I might know
<BenC> blacklist amd76x_edac
<BenC> is this an amd64 box?
<fabbione> it's not loaded
<BenC> ok, nm then
<fabbione> yes, but it's running i386 stuff
<BenC> ok, I'm headed to bed, but I can check on it in the morning
<fabbione> ok thanks dude
<fabbione> good night
<BenC> later
<TheMuso> c
<cypher1> does there are still code being added to init/main.c or is it now very stabilized ?
<cypher1> sorry i meant init/main.c in kernel code
<gnomefreak> are the nvidia modules ok or is that one of the missing modules
<gnomefreak> it works
<frenkel> does anybody here know why after installing xen, there is no /lib/modules/2.6.xx-xen0/build directory?
<zul> did you install the headers?
<frenkel> yes
<zul> try opening a bug in launchpad an ill look at it when i can 
<frenkel> ok, thanks
<frenkel> should i use xen-headers package?
<zul> yes
<frenkel> (for the bug) 
<frenkel> ok
<zul> or xen-source-2.6.whatever
<frenkel> submitted: https://bugz.launchpad.net/distros/ubuntu/+source/xen-source-2.6.17/+bug/72870
<zul> thanks
<frenkel> yw
<dade`> someone knows if the function to disable console suspend on suspend to ram can be enabled in ubuntu 2.6.19-6 kernel without recompiling ?
<mjg59> Depends what you mean by console suspend
<dade`> it's an option in power management section of kernel config
<mjg59> Oh. In that case, no.
<mjg59> You want netconsole to work?
<dade`> CONFIG_DISABLE_CONSOLE_SUSPEND=y
<dade`> ok
<dade`> I'm not really skilled, never used netconsole
<mjg59> Why are you worried about the console_suspend option?
<dade`> I want to see why kernel 2.6.19 freezes during suspend to ram, even without piix support
<kylem> BenC, ok, merged and compiled ok for edgy.
<fabbione> kylem: do you feel lucky?
<kylem> hmm?
<fabbione> *grins*
<fabbione> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.19/+bug/72824
<fabbione> and i would like to handover to either you or Ben the gfs merge from redhat
<kylem> i saw something about pata_via today. hold.
<kylem> or not, nm. :/
<fabbione> kylem: http://sources.redhat.com/cluster/ <- in .19 we are tracking CVS HEAD
<fabbione> kylem: would you like to be in charge of keeping it up to date in .19?
<fabbione> also.. Ben did some patching to make it build in .19
<fabbione> but it's all in one git commit
<fabbione> i would like to have the .17 -> .19 patch separated so i can submit it upstream
<mjg59> Are we doing the ->libata transition?
<mjg59> If so, someone really needs to pull all the code from -mm
<mjg59> Plus all the patches that Alan just through at lkml
<fabbione> note that i am not asking you to take over GFS testing.. just merging upstream bits into our tree.
<kylem> fabbione, i can probably do that.
<fabbione> kylem: ok, can you let me know by the end of your day?
<BenC> kylem: Sweet, can I pull now?
<fabbione> kylem: an email or /msg will do
<kylem> BenC, not yet, still some more patches to go in first.
<BenC> ok
<BenC> I got the pata_via bug, btw
<zul> i have a bunch of patches for dapper-updates as well
<BenC> it's an initramfs thing
<kylem> mjg59, yeah, that's probably where i saw it, on mm.
<fabbione> BenC: initramfs? the OOPS?
<BenC> oh, that's right, you ended up with an oops
<kylem> BenC, alright, won't spend time on that then.
<fabbione> BenC: see 72824
<fabbione> kylem: no he is talking about another pata_via bug
<BenC> fabbione: that's the one that doesn't occur when you remove quiet/splash?
<BenC> or is it random?
<kylem> fabbione, ah.
<fabbione> BenC: it happens at random. I did re-test and it doesn't matter if you have quiet/splash
<BenC> ok
<fabbione> that one in the pic is without quiet/splash
<kylem> that's nasty.
<fabbione> it looks like it happens ONLY at boot
<fabbione> machine didn't do anything fancy since i booted it
<fabbione> uptime
<fabbione>  20:11:05 up 12:36,  6 users,  load average: 0.75, 0.41, 0.22
<fabbione> and no OOPS
<fabbione> problem is getting there :)
<BenC> I may end up switching via back to ide if it isn't an easy fix, but I'll try emailing AC about it
<fabbione> well point him to the OOPS
<fabbione> perhpas he knows
<fabbione> or how can i stress test the system in a useful way
<fabbione> it looks to me something related to bus/disk scanning
<fabbione> since it doesn't happen after it boots
<kylem> i don't see anything related in rc5-mm2.
<kylem> fabbione, if you just want me to update the whole of ubuntu/fs/gfs/ from cvs, and make sure it builds, that's not a problem.
<BenC> fabbione: I thought the same thing, sounded like a race between device initialization completion and first use of the disk
<zul> what is the config option i need for cciss?
<kylem> CONFIG_BLK_CPQ_CISS_DA
<zul> thanks kylem 
<kylem> np
<fabbione> kylem: yes, that's all i want and the patches we do locally to make it build, so i can push them upstream and keep the delta to 0
<fabbione> kylem: upstream is really fast taking our patches
<fabbione> kylem: IDEALLY if you can give me the patches based on the CVS sources it would be even better, but that's optional
<zul> BenC/kylem: is it easier for you guys to grab my patches through email to the mailing list or using a repo
<BenC> pulling from a git repo is by far the easiest, as long as you adhere to the commit styles
<BenC> templates I mean
<zul> and nothing in the changelogs right?
<kylem> and test build...
<zul> cool
<zul> ill set them up tonight
<zul> or try to, aniversary is tonight ;)
#ubuntu-kernel 2006-11-23
* kylem thwaps zul.
<kylem> BenC, what's the ubuntu firmware policy? (specifically the qlogic firmware for qla2xxx)
<mjg59> What aspect of the policy?
<BenC> if they will let us redistribute it, we stick it into the kernel
<BenC> under debian/firmware/
<kylem> well, you can optionally build the firmware in, but the recommended thing to do is load it from userspace.
<kylem> (recommended by the driver authors)
<BenC> if redistribution is "everyone does it, and the vendor says it doesn't care, but we have no real license", then it goes in lrm
<kylem> drivers/scsi/qla2xxx/Kconfig, there was a bug report to turn on QLA_FC in edgy kernel, zul submitted a patch, but neglected to frob the other options...
<BenC> e.g. acx is in lrm, ipw3945 is in main kernel
<mjg59> Oh, right
<kylem> this is the tg3 style firmware, a static char[]  array
<mjg59> kylem: If it's recommended to load from userspace, then do that
<BenC> yeah, definitely
<mjg59> kylem: But it'll want an initramfs-tools tweak to make sure it's copied into the initramfs
<kylem> yeah, except then you can't easily boot of it...
<mjg59> We handle firmware loading from initramfs
<BenC> infinity: ping
<infinity> pong
<BenC> infinity: I need a initramfs-tools update soonish so I can have pata_* drivers working
<BenC> can I do a quick upload just for this, or do you have larger plans?
<infinity> BenC: Go hard.  I have notihng interesting pending.
<BenC> ok
<BenC> is this one of those uploads that falls into the category of "cjwatson will kill me if I don't follow some policy"?
<infinity> pata_* == libata PATA drivers?
<mjg59> initramfs-tools is fine
<mjg59> Just don't screw it up
<BenC> infinity: Yeah
<mjg59> Oh, uh.
<infinity> Yeah, leave my system unbootable, and I'll curse your name, otherwise it's all good.
<mjg59> Is there any HPA handling code in libata yet?
<mjg59> And if not, do HPAs default to being enabled or disabled?
<BenC> mjg59: good question
<mjg59> Because that'll, like, kill people who've wiped their Thinkpad rescue partition but didn't disable the HPA in the BIOS
<BenC> I only enabled the pata drivers that were not exp.
<mjg59> This is ata_piix
<BenC> let me check that one
<mjg59> Given that the "fix" is a simple BIOS tweak, it's not a real issue
<mjg59> But it needs to be flagged as a blocker until we fix it
<mjg59> It's like 3 lines of code
<BenC> ok
<BenC> infinity: Oooh, copy_modules_dir made my job easy
<BenC> ata) copy_modules_dir kernel/drivers/ata;;
<BenC> I wonder if it's a good idea to do that for scsi too
<BenC> and ide
<infinity> If that now works for everything we want, then hells yes.
<BenC> I'll test it on all my machines before uploading
<BenC> I added an "ata" for the auto load list, since pata/sata are now all in drivers/ata
<BenC> and I know for sure that ide and scsi module lists are outdated anyway
<infinity> They get old fast, yeah.
<BenC> my concern now is initrd size
<infinity> Oh, are we including all the old ide drivers AND the new pata ones?
<infinity> I guess that could get somewhat bigger.
<infinity> Though we're building 'em bloated anyway... *shrug*
<BenC> no, I disabled the ide drivers that were replaced by the IDE ones
<BenC> about 500k size increase with the copy_modules_dir {ata,scsi,ide} as opposed to the old method
<infinity> Oh, kernel/drivers/ata/ is tiny, don't worry about it.
<BenC> err, replaced by the pata ones
<infinity> Well, "tiny" compared to my 6.3MB initrd.
<BenC> I think the additional scsi drivers caused the size increase
<BenC> I know there's more than what's in that list
<infinity> Yeah, you may have added some.
<infinity> *shrug*
<infinity> scsi is definitely the big one.
<infinity> Not much we can do about that.
<infinity> Although, do we really still need two aic7xxx drivers?
<BenC> I don't think they overlap
<kylem> BenC, any idea why qla2xxx/qla fiber channel is off in edgy/feisty kernels? (or was it just an oversight when it changed from being CONFIG_SCSI_QLA2XXX)
<infinity> We never included _old in our initrds, and I've not had a complaint.
<infinity> That may be telling.
<BenC> infinity: _old doesn't even have a dev table
<BenC> maybe I can just disable it
<BenC> kylem: perhaps, let me check
<infinity> BenC: It's not referenced/loaded from the new aic7xxx driver on the fly when old hardware is encountered, or something equally GNAH?!
<infinity> BenC: With no dev table, I'm curious as to why it's there at all. :)
<BenC> infinity: My thoughts exactly, unless it's one of those weird platform drivers :)
<BenC> probably can be disabled
<BenC> kylem: My guess is it's an oversight
<infinity> Could be one of those "this driver is the only one that works on Alpha, cause the other one needs some cleaning up" cases, or something, but as (like I said) we've not once had a complaint about it not being in our initrds, I somehow doubt any of our users care.
<kylem> BenC, ok, i've turned it back on in edgy-updates.
<kylem> on all but parisc, since it will likely fail there anyway.
<BenC> I'll enable it in feisty
<BenC> and get the firmware
<infinity> kylem: There is no edgy/hppa.
<kylem> infinity, that too.
<kylem> aic7xxx_old.c gets the puke-o-rama of the day award.
<infinity> (So no point in caring if a change will or won't biuld there)
<BenC> I wish we had someone with canonical that knew hppa
<BenC> oh wait
* BenC looks around
* kylem runs.
<kylem> let me finish ATs first...
<infinity> Would I get fired for proposing that feisty+1 be a parisc-only release, and we drop all the boring arches?
<infinity> "Everyone else is doing these ones anyway, we want to stick out and be unique!"
<BenC> hehe
* kylem wants some of intels new ia64 kit. my apartment is electric heated anyway....
<infinity> We could get lamont involved and ship a C200 with every shipit CD.
<mjg59> Oh. My. Christ.
<BenC> might as well stick "sh" in there as well
<mjg59> Look at aic7xxx_detect in aic7xxx_old.c
<infinity> BenC: Harder to get our hands on stacks of Dreamcasts.
<kylem> mjg59, it's love.
<infinity> (Well, actually, DCs are easy to come by, it's the ethernet adapter that's rarer than kyle's sobriety)
<lamont> infinity: heh
<kylem> mjg59, would you rather hack that or acpi?
<kylem> infinity, hey, i've not had a drink since boatnight. :)
<infinity> kylem: Been ill? ;)
<kylem> and even then, i was sick enough without alcohol
<mjg59> ACPI
<BenC> mjg59: holy shit, it's like half the code in there
<mjg59> pci_find_device!!!
<mjg59> Yeah. Uhm.
<mjg59> I think we don't support that driver.
<infinity> Oh, is aic7xxx_old one of those really, really old drivers that does all the PCI legwork itself still?
<kylem> infinity, yes.
<kylem> the driver appears to be older than i am.
<mjg59> !
<infinity> I thought those were purged from the tree long ago, for fear of setting a bad example for future generations.
<mjg59>         if ( i == 0 ) /* We found one, but it's the 7810 RAID cont. */
<ajmitch> maybe it scared too many people away from cleaning up
<mjg59> Is entirely dependent upon the 7810 being the first entry in the array
<mjg59> This isn't mentioned in the array itself
<kylem> ajmitch, better to dust off and nuke the driver from orbit... it's the only way to be sure.
<mjg59> It supports VLB
<mjg59> Which aic7xxx might not
<mjg59> But, erm.
<infinity> mjg59: And as scary as all that is, I recall the old aic7xxx driver (before it was rewritten) being a stellarly stable and useful driver, a paragon of hardware vendor involvement for the greater good.
<kylem> fuck VLB.
<infinity> I think our standards must have been lower back then.  Where "back then" was, what, the 60s?
<mjg59> The 1860s?
<zul> hey
<zul> just popping by and will be off soon
<ajmitch> evening zul 
<BenC> ok, let's reboot and see how this new initramfs did
<BenC> all is well, initramfs-tools uploaded
<BenC> Is "" a legitimate SSID?
<KnowledgEngi> hello
<KnowledgEngi> sudo apt-get install linux-tree
<KnowledgEngi> why apt do not find linux-tree
<KnowledgEngi> ??
<KnowledgEngi> http://wiki.ubuntu-it.org/CompilazioneKernel?highlight=%28kernel%29
<KnowledgEngi> i'm using this how-to
<infinity> s/linux-tree/linux-source/
<infinity> Though that howto is pretty sketchy.  Doing all that as root is pointless.
<BenC> anything not listed directly in the URL above is pretty much unsupported and probably broken
<BenC> s/above/in the topic/
<KnowledgEngi> i whant just to change the cpu timer frequency 
<KnowledgEngi> i need only this modific
<KnowledgEngi> the rest under ubuntu work very good
<BenC> the above URL has a link to a howto for rebuilding the ubuntu kernel properly with small config changes like what you want
<KnowledgEngi> This is a bad bear. Use it, but there are still a few missing modules.
<KnowledgEngi> for this argoment i do not whant use a different kernel version
<KnowledgEngi> https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28CategoryKernel%29
<KnowledgEngi> this page???
<infinity> Why can't we influence the timer on the command line anyway?
<KnowledgEngi> i do not know
<KnowledgEngi> i know that yesterday i has solved the problem rebuilding the kernel
<BenC> infinity: Hardcoded into a lot of macros
<KnowledgEngi> i was using a software for musician
<KnowledgEngi> that need a low-latency kernel
<infinity> BenC: Well, yes, I was fairly sure that was the answer, it was more of a "can't this be fixed?" thing.
<kylem> way more efficient for it to be an immediate than to constantly reload from memory... 
<infinity> kylem: And yes, that's the "why".
<fabbione> morning
<BenC> hey fabbione
<fabbione> KnowledgEngi: yes i am italian but please don't /msg me just for that :)
<fabbione> BenC: just saw your initramfs upload. thanks
<KnowledgEngi> i'm italian too
<fabbione> will test once it's in the local mirror
<KnowledgEngi> but my english is very bad
<BenC> fabbione: no problem
* infinity wonders how evil it would be to embrace and extend the smpalt stuff to rewrite the frequence at boot time.
<KnowledgEngi> for me is hard to explain the situation in english
* infinity stops pondering that, realising the answer is almost surely "very".
<kylem> infinity, extremely.
<KnowledgEngi> can i query you fabbione 
<KnowledgEngi> ?
<fabbione> KnowledgEngi: what do you need?
<BenC> he needs to rebuild the kernel with HZ=1000
<infinity> kylem: The only reason I'm pondering it at all is due to the frequency of people needing to change that.. Uhh.. Frequency.
<KnowledgEngi> exatly
<BenC> and I pointed him to the URL in the topic, which led to the kernelBuild wiki page, whihc is where he needs to be
<fabbione> and why do you need to keep that in a query?
<KnowledgEngi> i whant that kernel and modules ar the same that i have now
<kylem> infinity, HZ=1000 isn't really enough to give them low latency.
<KnowledgEngi> but the only dfifference that i need is the HZ
<KnowledgEngi> change it from 250 to 1000
<infinity> kylem: No, but it does help measurably.
<BenC> KnowledgEngi: The KernelBuild wiki page you found is what you want
<KnowledgEngi> i do not like use make oldconfig
<kylem> why don't the UbuntuStudio or whatever people ship one with the lowlatency patchkit anyway?
<KnowledgEngi> becouse he show me much question that i cannot answare
<infinity> kylem: There was much talk of it during the dapper cycle.  Not sure where it went.
<KnowledgEngi> becouse ubuntustudio have tha same problem
<BenC> KnowledgEngi: There will be no questions if you follow the instructions
<infinity> We even have userspace realtime stuff in glibc and pam, specifically for said group.
<KnowledgEngi> sudo apt-get install linux-kernel-devel fakeroot kernel-wedge kernel-package
<KnowledgEngi> from here ???
<fabbione> KnowledgEngi: from the first line of the page
<KnowledgEngi> the firsth 2 part tall nothing about procedure
<KnowledgEngi> Disclaimer
<KnowledgEngi> Reasons for compiling a custom kernel
<KnowledgEngi> Reasons for not compiling a custom kernel
<KnowledgEngi> this 3 parts tall nothing
<KnowledgEngi> sudo apt-get install linux-source
<KnowledgEngi> this are the same sources of ubuntu edgy kernel ??
<KnowledgEngi> sudo apt-get install linux-source
<KnowledgEngi> sudo -xvjf linux-source-2.6.17.tar.bz2
<KnowledgEngi> cp /boot/config-2.6.17-10-generic linux-source-2.6.17/.config
<KnowledgEngi> this is correct??
<KnowledgEngi> becouse this page speack about arch/....
<KnowledgEngi> http://rafb.net/paste/results/MTGUMG60.html
<KnowledgEngi> is correct ??
<KnowledgEngi> this is all command that i writed in the terminal for build a kernel adding a option in the configuration
<KnowledgEngi> i'm not totally sure that is correct
<fabbione> BenC: i am looking at that kmap_atomic OOPS
<fabbione> it's intersting piece of code
<fabbione>  * However when holding an atomic kmap is is not legal to sleep, so atomic
<fabbione>  * kmaps are appropriate for short, tight code paths only.
<fabbione> and libata is a client for it
<fabbione> pata_via does nothing there
<fabbione> so i wonder if pata_via does actually takes too long and make things go south
<fabbione> the BUG(); there is very specific
<dade`> where is the default config file in the kernel development git tree ?
<fabbione> debian/config/$arch/config{,$flavour}
<dade`> thx
<KnowledgEngi> include/asm/byteorder.h:5:28: error: linux/compiler.h: No such file or directory
<KnowledgEngi> is normal ???
<KnowledgEngi> http://rafb.net/paste/results/c4LYkw68.html
<dade`> fabbione: I don't understand the config.generci has only few values set.
<dade`> generic
<fabbione> dade`: cat config config.generic > .config
<fabbione> KnowledgEngi: yes normal
<dade`> fine
<KnowledgEngi> sudo dpkg -i linux-image-2.6.17-2-ef427c-k7_2.6.17-2.2_i386.deb
<KnowledgEngi> sudo dpkg -i linux-headers--2.6.17-2-ef427c-k7_2.6.17-2.2_i386.deb
<KnowledgEngi> in what path i must run this commands?
<KnowledgEngi> root@ubuntu:/usr/src/linux-source-2.6.17# 
<KnowledgEngi> here?
<KnowledgEngi> root@ubuntu:/usr/src# ls *ubuntu*
<KnowledgEngi> linux-doc-2.6.17.13-ubuntu1_2.6.17-10.33_all.deb
<KnowledgEngi> linux-headers-2.6.17.13-ubuntu1_2.6.17-10.33_i386.deb
<KnowledgEngi> linux-image-2.6.17.13-ubuntu1_2.6.17-10.33_i386.deb
<KnowledgEngi> linux-manual-2.6.17.13-ubuntu1_2.6.17-10.33_all.deb
<KnowledgEngi> linux-source-2.6.17.13-ubuntu1_2.6.17-10.33_all.deb
<KnowledgEngi> linux-source-2.6.17.13-ubuntu1_2.6.17-10.33_i386.changes
<KnowledgEngi> mmmm
<KnowledgEngi> aa dpkg -i is for install
<KnowledgEngi> :P
<dade`> fabbione: is there a doc where all those lame questions are answered ? :)
<KnowledgEngi> fabbione, did you see the procedure in the file that i pasted?
<fabbione> dade`: usually if you don't know the answers, it means you shouldn't be compiling your own kernel
<fabbione> KnowledgEngi: no. i don't have time to babysit custom kernel builds. sorry
<KnowledgEngi> is just some line
<dade`> I thought it was that way, but was just guessing..
<KnowledgEngi> http://rafb.net/paste/results/c4LYkw68.html
<KnowledgEngi> hello JanC 
<KnowledgEngi> can you tall me if this small procedure is ok?
<KnowledgEngi> http://rafb.net/paste/results/c4LYkw68.html
<KnowledgEngi> hello :(
<KnowledgEngi> kernel panic: not syncin, unable to mount root on fs .....
<KnowledgEngi> http://rafb.net/paste/results/NS8Tpk66.html
<KnowledgEngi> i think that it's a problem initrd related
<KnowledgEngi> mkinitramfs -o /boot/initrd.img-2.6.17-13-ubuntu1
<KnowledgEngi> i adjusted the menu.lst
<KnowledgEngi> but when i reboot i see the ubuntu presentation 
<KnowledgEngi> and STOP
<KnowledgEngi> http://rafb.net/paste/results/5R0GpE33.html
<KnowledgEngi> when the system print "ubuntu" in the monitor it do not continue
<KnowledgEngi> the kernel config file is needed only for build the kernel ???
<KnowledgEngi> or is needed for working good too?
<KnowledgEngi> idea, i remove splash from menu.lst
<KnowledgEngi> and i look the errors
<KnowledgEngi> by
<KnowledgEngi> hello
<KnowledgEngi> now i has see the error deleting splash from menu.lst
<KnowledgEngi> http://rafb.net/paste/results/BrnMiE89.html
<KnowledgEngi> in the page there is the errors 
<KnowledgEngi> BenC, can you help me please :(
<KnowledgEngi> i used the how-to in the topic
<KnowledgEngi> http://rafb.net/paste/results/FeSfGz78.html
<KnowledgEngi> make-kpkg buildpackage
<KnowledgEngi> the error was here
<KnowledgEngi> make-kpkg --append-to-version -1000hz --revision=1 kernel_image --initrd
<KnowledgEngi> someone suggest me this command
<fabbione> BenC: are we really sure we want to go for libata?!?!?
<fabbione> http://www.spinics.net/lists/linux-ide/msg04744.html
<fabbione> drivers/ide IS STILL THE PATA DRIVER SET THAT USERS AND DISTROS SHOULD CHOOSE. <-
<KnowledgEngi> hello
<KnowledgEngi> the how-to was wrong
<KnowledgEngi> http://rafb.net/paste/results/t7YeAc68.html
<KnowledgEngi> now the kernel are not giving me problem
<KnowledgEngi> *are=is
<pmjdebruijn> KnowledgEngi, huh? you're not exactly clear...
<KnowledgEngi> https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28CategoryKernel%29
<KnowledgEngi> this how-to tall the i must do make-kpkg buildpackage
<pmjdebruijn> KnowledgEngi, yes, and your point is?
<KnowledgEngi> make-kpkg --append-to-version -1000hz --revision=1 kernel_image --initrd
<KnowledgEngi> this is better
<Keybuk> BenC: so, I think ide-generic is broken ...
<infinity> This is news?
<Keybuk> in the sense that it actually doesn't work at all
<Keybuk> if you load it before the PCI driver, it claims the device (when it shouldn't!) but doesn't make block devices
<gnomefreak> is the -6 kernel a full kernel now?
<mjg59> Why should it not claim the device?
<mjg59> It'll grab all IDE interfaces that are running in legacy mode. That's what it's for.
<Keybuk> but then it'll grab interfaces for which there's a better driver that just hasn't been loaded yet?
<mjg59> How is it to know?
<Keybuk> blacklist of pci ids?
<Keybuk> (it's also broken in the fact even when it loads, it doesn't expose any block devices -- but that's another story)
<mjg59> How would you generate the blacklist?
<Keybuk> automatically
<mjg59> From what?
<Keybuk> list of pci ids for which we do have drivers
<mjg59> And if the user builds a driver separately?
<Keybuk> *shrug*
<Keybuk> the fact is at the moment we can't load ide-generic
<Keybuk> because it breaks systems for which there's a better driver
<mjg59> Because even if it's loaded after the other drivers, it may bind first?
<Keybuk> because we don't have anywhere to load it to guarantee that it's loaded after the other drivers
<Keybuk> and yes, there's a binding issue with libata
<mjg59> The driver is functioning precisely as designed
<Keybuk> libata isn't as quick to bind as the old ide drivers
<mjg59> If this is causing problems, then we should figure out what to do with upstream
<Keybuk> istr that ide-generic is deprecated in favour of something in libata
<mjg59> There's probably an identical module in libata which will have identical issues
<Keybuk> there's fun games like two ide controllers in the machine, the one with the lower pci id needs ide-generic, the higher one has its own drier
<Keybuk> which we can't deal with at the moment, because ide-generic steals both
<mjg59> It doesn't "steal". It does what it's asked to do.
<Keybuk> I still think that driver binding is best off left to user space <g>
<Keybuk> loading modules makes drivers available, but it's up to userspace to bind to devices, etc.
<infinity> Haven't we had this conversation before?
<infinity> Like, before the dapper release?
<mjg59> I'm not going to argue against that
<mjg59> But given that ide-generic doesn't bind to PCI devices...
<infinity> I was getting libata/ide-generic races on my laptop, and we worked around it then.
<Keybuk> infinity: yeah, we put some hacks in place for dapper with ide-generic that we knew would break when this day occurred
<Keybuk> surprisingly, they broke
<infinity> Although, "ide-generic not exposing block devices" is new..
<Keybuk> right
<infinity> I just got my stuff swapping between /dev/sd* and /dev/hd* depending on who won the race.
<Keybuk> I wouldn't have caught (or immediately cared) the new winner of the race unless there was this other bug :)
<mjg59> You'd probably have cared when you noticed you had no DMA
<Keybuk> probably, yes
<mjg59> pata_legacy is the replacement
<Keybuk> right, and that specifically ignores PCI devices, iirc?
<mjg59> No
<mjg59> It doesn't scan ide0 or ide1
<Keybuk> ?
<mjg59> In legacy mode, IDE busses are found at specific ports
<mjg59> pata_legacy ignores the first two sets of these
<Keybuk> right
<Keybuk> why does it do that?
<Keybuk> surely it needs to look at them for ISA ide devices?
<mjg59>  *      Right now we do not scan the ide0 and ide1 address but should do so
<mjg59>  *      for non PCI systems or systems with no PCI IDE legacy mode devices.
<Keybuk> ahh
<infinity> Is there a timeframe on fixing that?
<mjg59> Well, it's trivial to make it behave like ide-generic again
<Keybuk> doesn't it also explicitly iterate the PCI bus, looking for PCI devices?
<mjg59> Oh, actually, the comment appears to be wrong
<Keybuk> yeah
<Keybuk> I was reading the code
<Keybuk> the code looks like it only ignores ide0 and ide1 if there's a PCI ide controller
<mjg59> It'll skip ide0 and ide1 iff it's found a PCI device at those addresses
<Keybuk> 858                         if (pci_resource_start(p, r) == 0x1f0)
<Keybuk> 859                                 primary = 1;
<Keybuk> 860                         if (pci_resource_start(p, r) == 0x170)
<Keybuk> 861                                 secondary = 1;
<mjg59> And unless you pass it a magic option, it'll ignore anything after ide1
<mjg59> So loading it would be a noop on most systems
<Keybuk> of course, Ben doesn't appear to have compiled this ;)
<mjg59> Well, given that it'd be a noop on any PCI systems...
<mjg59> Christ, you can tell this driver was written by Alan
<Keybuk> we still want it for non-PCI systems though?
<mjg59> Yeah
<Keybuk> . o O { if only we could declare "feisty is for PCI only, HA HA" }
<mjg59> I guess we might support, ooh, 3 or so of those?
<Keybuk> I'd be surprised if anything booted on non-PCI, frankly <g>
<Keybuk> but I've generally tried not to break things
* infinity makes a mental note not to upgrade his parents' machine to a modern Ubuntu...
<mjg59> So the issue then is that we won't drive any PCI adapters unless we have a specific driver for them
<infinity> Well, they run monolithic kernels anyway, but still...
<Keybuk> mjg59: that's fine though, because libata has a generic ata thing for those adapters, no?
<mjg59> No?
<Keybuk> modinfo ata_generic
<Keybuk> which backs off if a better driver gets loaded
<mjg59> Oh, I'm looking in an excessively old kernel tree
<Keybuk> (my laptop is driving with ata_generic today -- so I know it works <g>)
<mjg59> Let me finish pulling down 2.6.19
<Keybuk>  11  *  Driver for PCI IDE interfaces implementing the standard bus mastering
<Keybuk>  12  *  interface functionality. This assumes the BIOS did the drive set up and
<Keybuk>  13  *  tuning for us. By default we do not grab all IDE class devices as they
<Keybuk>  14  *  may have other drivers or need fixups to avoid problems. Instead we keep
<Keybuk>  15  *  a default list of stuff without documentation/driver that appears to
<Keybuk>  16  *  work.
<Keybuk> the first bit of that comment is a lie
<Keybuk> alias: pci:v*d*sv*sd*bc01sc01i*
<Keybuk> :p
<mjg59> Oh
<mjg59> That's just the same as pci/generic.c
<mjg59> It doesn't help in the case of new hardware appearing
<Keybuk> ?
<mjg59> Well, again assuming that the comment has any relation to reality
<mjg59> (Which, as we've already seen, may not be a good plan)
<mjg59> It'll load for all IDE class devices, but only bind if they hit the built-in whitelist
<Keybuk> that can't be true, because it's loaded on my laptop
<Keybuk> which isn't in the whitelist
<mjg59> Are you sure it's bound?
<Keybuk> *confused*
<Keybuk> well, I can't see any other driver
<mjg59> Can you stick lspci somewhere?
<mjg59> Uh, lsmod
<Keybuk> oh, wait, alim15x3 ... laptop is still using the old non-libata driver
<Keybuk> so right, we have the general problem of new hardware that we don't have a driver for, or at least the pci id for, appearing and failing to boot because there's no IDE driver and no "generic" driver to claim it?
<mjg59> Yes
<Keybuk> we'd need to set all_generic_ide=1 or something
<mjg59> But then it'll bind to everything, even if there's a better driver
<Keybuk> yeah
<Keybuk> we could make it a kernel option, then at least we can document it :)
<mjg59> I guess you could poke bind/unbind stuff
<mjg59> But yeah, I'm happy with the idea of just disabling ide-generic and having initramfs pass all-generic-ide to the ata_generic module if the user supplies it on the kernel boot line
<mjg59> Then users with excessively bling hardware can just add that boot option at install time
<Keybuk> I wonder how often new IDE controllers come out these days
<Keybuk> (that aren't SATA)
<mjg59> Several in the past few months
<mjg59> Things will probably settle down again now
<mjg59> Intel took PATA out of ICH8
<Keybuk> I guess I also need to kick Ben, most of the libata modules aren't compiled :p
<mjg59> We also need all the latest pata patches from -mm and anything that Alan has posted to LKML lately
<Keybuk> *nods*
<mjg59> Otherwise a moderate number of them will cause corruption over suspend/resume
<fabbione> <fabbione> http://www.spinics.net/lists/linux-ide/msg04744.html
<fabbione> <fabbione> drivers/ide IS STILL THE PATA DRIVER SET THAT USERS AND DISTROS SHOULD CHOOSE. <-
<fabbione> ^^
<fabbione> this was a quote from Jeff for .19
<mjg59> Yes. We're not shipping .19.
<fabbione> mjg59: no matter if we land for .20 we are still with .19 for a while
<mjg59> Someone has to test this code in the real world. It might as well be us.
<mjg59> We can revert with approximately no effort.
<fabbione> right, but it would be wise to coordinate with upstream before even entering a testing phase
<fabbione> and i don't think that has been done
<Keybuk> we've been testing libata for 6 months now
<fabbione> Keybuk: libata doesn't seems to be the primary issue
<Keybuk> then what is?
<infinity> I'm all for us ironing out the wrinkles while we're still ages away from another LTS.
<fabbione> Keybuk: the drivers using it.
<infinity> And, hey, now that we have kyle on staff, we have a kernel rock star, so it's all good.
<fabbione> Keybuk: see 72824 for example
<Keybuk> some of the drivers using it are clearly better than the ide ones
<mjg59> Most of the drivers are fine
<mjg59> And it's actually practical to fix bugs in them, unlike drivers/ide
<Keybuk> we shipped edgy preferring some libata pata drivers over the old ide subsystem
<Keybuk> mjg59: interesting, I loaded ata_generic with all_generic_ide=1 and it hasn't actually picked up my card
<Keybuk> it found the ide ports, bitches a lot about a port being "too slow", and then stays loaded with no interfaces
<Keybuk> I did get a /dev/sg0
<Keybuk> oh, heh
<Keybuk> need sd_mod
<Keybuk> hmm, that should've auto-loaded ... wonder why it didn't
<Keybuk> ahh
<Keybuk> udev rules bug :)
<Keybuk> ok, that all works
<Keybuk> my laptop boots happily with ata_generic if forced
<Keybuk> and the UUID stuff transitioned it nicely too
<kylem> sweet.
<Keybuk> happily nobody with a SCSI or SATA card tried upgrading udev this afternoon
<mjg59> Keybuk: Excellent
<mjg59> Keybuk: So we just need initramfs-tools to pass that through if the user provides it
<Keybuk> yeah
<Keybuk> mdz has a general "I want some way of forcing a driver bind" desire which came out of some s3kr3t meeting at UDS
<Keybuk> so I may do it with that
<Keybuk> unless I carry on stamping my foot about how irritatingly impossible it is to do this <g>
<Keybuk> I wonder how much traction upstream a "binding in user space" patch would get
<infinity> Keybuk: me, kyle, and ben discussed that very thing in SFO.
<infinity> (userspace binding, that is)
<Keybuk> it makes some amount of sense
<Keybuk> if userspace got to decide which module got which device, we'd have a lot less problems
<infinity> Indeed.
<infinity> We discussed some rationale, and some hand-wavey "how could we do this", but didn't actually talk implementation.
<Keybuk> you'd need to sort out the distinction between modules and drivers
<infinity> But the general idea seems sound.
<mjg59> It is, sadly, not workable in certain cases
<Keybuk> so that device binding is either done at the module level (in which case drivers go away), or drivers become a first class object with uevents, etc.
<mjg59> For instance, the PCI dev table can have a pointer to a structure in the data field
<Keybuk> and then have external tables that udev can look up whenever a device is added, or driver/module added, and mate the two
<Keybuk> right
<Keybuk> the special casing
<mjg59> Yes
<Keybuk> it doesn't prevent anything
<Keybuk> it just means the special casing lists and the supported device lists become different
<mjg59> It would need some rewriting of certain modules
<Keybuk> sure
<Keybuk> in fact, all modules would need the device table removed and a .inf file written
<BenC> Keybuk: can you summarize ide-generic so I don't have to read all this scrollback :)
<Keybuk> BenC: ide-generic is broken, if you load it, you don't get any block devices
<Keybuk> and it's loading too quickly because of some other changes, and stealing the PCI devices
<Keybuk> so I've disabled loading entirely
<Keybuk> FTW we appear to need to load pata_legacy (not yet compiled) for non-PCI interfaces, which doesn't steal
<Keybuk> and have an option to force ata_generic to take devices it's unaware of, so people with unknown IDE interfaces can still boot
<BenC> known, was going to work on it when I got the box that elmo sent me from UDS
<Keybuk> tbh, if pata_legacy and ata_generic dtrt (which they appear to), I'm tempted to remove ide-generic entirely and sing a little song about it
<BenC> pata_legacy is marked "dangerous" IIRC
<BenC> let me check again
<mjg59> I disagree that ide-generic is broken, but would concur that we shouldn't be trying to load it by default
<Keybuk> mjg59: well, it's working according to its design
<mjg59> Keybuk: How about leaving ide-generic built, and have a boot option that force-loads it?
<Keybuk> I'd be happy with just not loading it unless someone wants it loaded
<Keybuk> yes, I'd be happy with that
<mjg59> It has no modalias entries
<BenC> sounds like a plan to me
<mjg59> ubuntu-2.6 is the 2.6.19 branch, right?
<BenC> but ONLY if there's something in the installer to recoginize that and marshall it into the installed system
<BenC> mjg59: Right
<Keybuk> BenC: the installer could pick up the same option from its own boot? :p
<mjg59> If it's passed at install CD time, it'll be put on the installed system
<Keybuk> we should probably decide whether we prefer pata_legacy/ata_generic or ide-generic
<BenC> Keybuk: I meant so the user didn't have to add it manually after installing :P
<mjg59> BenC: There /should/ be no cases where ide-generic is necessary
<mjg59> Keybuk: pata_legacy = ide-generic. ata_generic = drivers/ide/pci/generic
<mjg59> Just to make things confusing
<Keybuk> heh
<Keybuk> which did the latter get exposed as?
<mjg59> generic.ko
<Keybuk> ah yes
<Keybuk> of course
<Keybuk> pata_legacy has the bonus over ide-generic that it doesn't bind to ide0 or ide1 if there's a PCI device with those addresses
<mjg59> Yes
<Keybuk> (I wonder why ide-generic doesn't do the same thing)
<mjg59> Because, erm.
<mjg59> LOOK, A THREE HEADED MONKEY
<BenC> mjg59: The case where we have a ide device with no driver (like marvell currently is in edgy/dapper)
<mjg59> BenC: We should be using generic for that, not ide-generic
<mjg59> That way they get DMA
<BenC> generic needs entries in it still
<mjg59> Not if ide-all-generic is passed
<Keybuk> modprobe ata_generic all_generic_ide=1
<Keybuk> (this can be trivially written into a modprobe.d options file)
<mjg59> Anyway, we have a marvell driver for feisty
<BenC> yeah, but I need to backport it for edgy and dapper
<mjg59> Heh
<mjg59> Or just add the entries to generic.c
<BenC> might as well add the proper driver :)
<BenC> Keybuk: Check this out:
<BenC> "Also modprobe will be built into udev to solve the
<BenC> performance-problems we see with parsing the modprobe-files for every
<BenC> device with a modalias."
<BenC> Keybuk: interested in building modprobe and udev together? :)
<Keybuk> BenC: ref?
<Keybuk> I've been bitching about that for some time
<Keybuk> I even had a patch for it for a while
* Keybuk finds the thread
<Keybuk> interesting how several people seem to be having the same idea entirely independently (user space binding)
<BenC> yeah
<BenC> I still think the idea of allowing the kernel to bind without interference is bad, forcing us to ubind/rebind
<Keybuk> being able to just edit modules.alias, add a couple of new lines, and have things just work(tm) would be sweet
<Keybuk> I still don't see how kay has managed to get bind/unbind to work
<Keybuk> I have the SuSE rules here, and it doesn't use them
<Keybuk> the biggest problem is the humongous race between udev getting the add@/module/... and the bind/unbind thing actually appearing
<Keybuk> (not to mention futzing from a module to a driver)
<Keybuk> if we had driver uevents, it would be a sinch
<mjg59> * refs/heads/origin: does not fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6;
<BenC> it would be nice if we could muck with the driver's table after it was loaded
<mjg59> What does that /mean/?
<Keybuk> SUBSYSTEM=="driver", ACTION=="add", some_thing_to_get_the_list_of_devices, SYSFS{bind}="$devices"
<BenC> mjg59: It means that ubuntu-2.6 is not the same base tree as when it was in edgy...re-clone
<mjg59> Grngh.
<BenC> mjg59: we'll be syncing right along into 2.6.20, fyi
<mjg59> Cool
<Keybuk> BenC: so, thinking about this a bit more
<Keybuk> the first step would be to at least get race and ambiguity free access to the bind/unbind bits of a driver
<Keybuk> so when a module loads, or a device gets added to a bus, we can poke bind with the bus id
<Keybuk> (I assume that overrides the table lookups?)
<Keybuk> that way we could take advantage of it immediately by just excluding troublesome PCI ids, and having a udev rule to make the decision
<Keybuk> if kay has nih'd my udev modprobe patch, this would be yawningly easy
<Keybuk> (aside from the necessary kernel hacking)
<kylem> moo.
<Keybuk> (nvidia/nvidia-legacy, prism, etc. spring to mind as immediately useful test cases)
<zul> kylem: open up a box of milk and won?
<Keybuk> and that bt878 thing
<kylem> i always win.
<Keybuk> if we have success there, we can then just wholesale flip everything to use userspace for the binding
<BenC> I have a bt878 card too, so I can test that case
<Keybuk> right now we get uevents when a device is added to a bus
<Keybuk> that uevent contains enough information to make a decision as to which modules can handle that
<Keybuk> and probably also has enough information for us to decide which of two competing modules to use (e.g. we can look at a config file on the filesystem, if all else fails)
<Keybuk> indeed, that is how we load modules today
<Keybuk> we also get a uevent when a module is loaded into the kernel
<Keybuk> the problem is we get this uevent at the wrong time, it appears to get generated before the module's init function is called
<Keybuk> so before any of the module's drivers are registered
<Keybuk> additionally, devices are bound to drivers, not to modules
<Keybuk> and we get no uevents for drivers
<Keybuk> also there's no way to get from a module to its drivers (just the other way around, due to a hacky symlink)
<Keybuk> that'd be the first thing to fix
<Keybuk> 1) get from module to drivers and back again easily
<Keybuk> 2) uevents when drivers are registered and unregistered
<Keybuk> this patch would be sufficiently subtle and useful that it'd probably get accepted
<Keybuk> that'd give us the ability to write a udev rule that directly poked bind or unbind at the driver leve
<Keybuk> +l
<kylem> hmm.
<zul> ?
<Keybuk> definitely a conversation killer
<kylem> so basically you want a uevent when the module is finished running it's init section?
<Mithrandir> and the unload/finish section.
<Keybuk> to be honest, I'd rather have uevents when the drivers were registered
<Keybuk> that's far more fitting
<mjg59> I wouldn't have thought that would be too difficult
<kylem> Keybuk, i can try cooking a patch in my off time
<Keybuk> mjg59: willy came up with the problem that modules register multiple drivers with the same name
<Keybuk> so /sys/module/$MODULE/$DRIVER wouldn't work :-(
<mjg59> Is kernel.org fucked right now?
<mjg59> Keybuk: Yeah, there's going to have to be a bus component to it
<kylem> mjg59, www1 is
<kylem> use www2.kernel.org
<Keybuk> kylem: I could probably argue for doing this in your on time, if you wanted :p  there's a spec for this
<kylem> Keybuk, in that case, i'd like that
<Keybuk> if drivers had kobjects that sat under the module, with the bus name salted in, that would rock
<Keybuk> then /sys/bus/pci/drivers could be just a list of symlinks :p
<Keybuk> https://launchpad.net/distros/ubuntu/+spec/new-pci-ids
<jbailey> BenC: Around?
<zul> hey jeff
<jbailey> Heya chuck!
<kylem> loadavg is like 500 on www1. heh.
<Keybuk> (note that mdz's brain dump in the whiteboard utterly does not work)
<Keybuk> for a start, his knowledge of module loading is a year out of date... modules.pcimap, sheesh, crusty!
<kylem> i didn't realize it had changed
<jbailey> kylem: Yeah.  Inthe new udev/sysfs world, there's some really cool hacks.
<Keybuk> every ubuntu release up to dapper loaded modules differently
<Keybuk> nowadays, the kernel generates a MODALIAS string (pci:vBLAHdBLAH...) that describes the device and places that in the uevent
<Keybuk> that matches wildcard strings in the module alias table
<kylem> ah.
<Keybuk> so whenever we get a uevent with a MODALIAS, we just call modprobe on it
<Keybuk> this is likely to change in feisty, or feisty+1, as udev is getting modprobe built in to save time
<Keybuk> so udev will load the module directly
<kylem> spiff. thanks.
<jbailey> Byebye modules-init-tools finally?
<Keybuk> given this, it'd be a piece of piss to do user-space binding if we can fix the issue outlined above
<Keybuk> SUBSYSTEM=="pci", ATTR{vendor}="8086", ATTR{device}="1234", BIND="some_module"
<Keybuk> some_driver, sorry
<Mithrandir> Keybuk: what's the difference between a driver and a module?
<Keybuk> Mithrandir: modules contain drivers
<BenC> jbailey: yeah
<Keybuk> drivers are per-bus, and contain tables of devices which they are bound to
<kylem> multiple drivers, possibly...
<Keybuk> e.g.
<Keybuk> /sys/bus/pci/drivers
<Keybuk> /sys/bus/pci/drivers/nForce2_smbus
<BenC> for one, drivers don't always match the name of the module
<Keybuk> /sys/bus/pci/drivers/nForce2_smbus/module -> /sys/module/i2c_nforce2
<BenC> which for most modules really sucks
<Keybuk> BenC: right, and sometimes modules have multiple drivers with the same name, just on different buses
<BenC> yeah, the continuity there needs some help
<Keybuk> that wouldn't be bad if the driver had a kobject under the module though, so we could do /sys/module/i2c_nforce2/pci -> /sys/bus/pci/drivers/nForce2_smbus or something
<Mithrandir> Keybuk: ah, ok.
<Keybuk> (that assumes a module doesn't contain multiple drivers with different names on the same bus ... I suspect there's an example of that too <g>)
<BenC> if it's possible, I'm sure we have it :)
<mjg59> Keybuk: Yeah, it may have to be /sys/module/i2c_nforce2/pci/i2c_nforce2 -> /sys/bus/pci/drivers/whatever
<Keybuk> mjg59: which wouldn't be so bad
<Keybuk> and at that point, you could just have /sys/module/i2c_nforce2/pci/nForce2_smbus/bind
<Keybuk> and make /sys/bus/pci/drivers/* a symlink to /sys/module/$MODULE/$BUS/*
<mjg59> Yeah
<mjg59> Except in the cases where it's not a module
<Keybuk> can you have drivers outside of modules?
<BenC> Keybuk: would it be feasible for udev to have a mechanism with the kernel to where it could get a "add device" notification and somehow keep the kernel from performing binding on that device?
<mjg59> Do statically built in things still appear under /sys/module nowadays?
<BenC> Keybuk: Yeah, platform drivers for instance
<Keybuk> of, of course
<BenC> mjg59: No, which sucks
<mjg59> Also, what Ben said
<Keybuk> BenC: not sure it'd be worth the effort ... we could experiment at first by just removing duplicate pci ids, and doing the bind by hand from udev
<Keybuk> it may make sense to have a /sys/kernel/never_bind or something
<BenC> Keybuk: Do you know if the kernel sends an "device add" prior to binding with a driver?
<Keybuk> BenC: it sends it before the actual bind, yes
<Keybuk> but it's sent via netlink, so no knowing when udev actually gets to it, and gets to reply
<BenC> does the kernel honor any sort of return values from udev?
<Keybuk> no such thing
<Keybuk> the kernel doesn't even know udev is listening
<BenC> ok
<BenC> it would be nice if we could export a driver->module mapping
<Keybuk> yes
<zul> pitty there isnt a kudev
<BenC> as of now, it's only known after the module is loaded
<Keybuk> zul: ?
<Keybuk> KDE version?
<BenC> in kernel udev!?!?
<BenC> lol
<zul> yeah
<Keybuk> the whole point of udev is to do things in userspace
<BenC> gudev, so that and try not to laugh
<Keybuk> where we can make the big decisions, using things like config files and stuff
<BenC> s/so/say/
<Keybuk> ludev
<Keybuk> pudev
<Keybuk> ANYWAY
<BenC> Keybuk: We need to get together on this whole driver binding thing to figure out the best way to do what I want with driver-module-manager
<BenC> I really want to avoid the part where the kernel binds with "whatever driver" and requires udev to ubind/bind to the correct one
<kylem> heh
<BenC> I know it's a bit of a corner case, but without it, the whole idea of managing drivers seems pointless
<BenC> and it also makes it harder to do things like driver updates from ihv's
<BenC> there are cases where unbinding just isn't as nifty as it sounds
<Keybuk> BenC: I agree
<Keybuk> unbind-then-bind sucks
<Keybuk> plus it just doesn't work atm
<BenC> I need to test the bind/unbind
<Keybuk> driver-module-manager?
<Keybuk> the problem with unbind/bind is there's nowhere useful to do it right now, as you race
<Keybuk> ideally when a device is added, we'd look up the driver it needs and which module that's in -- if the module is loaded, we'd poke the driver's bind directory -- if the module is not loaded, we'd load it
<Keybuk> and then when a driver is added, we'd iterate the bus looking for any devices we can bind to it, and do the binding
<zul> heh http://www.patentstorm.us/patents/7028023-fulltext.html
<zul> has anyone tried building the vmware modules on 2.6.19 besides ajmitch
<zul> meh...ill give it a shot tonight
<BenC> lrm is built against 2.6.19, but there's a small fixup needed
<zul> ill try sending a patch..
<zul> or wait until vmware sends one
<ajmitch> BenC: like? I'm wanting vmware server running again, it had issues with CHECKSUM_HW
<ajmitch> is the same problem in the vmware player modules?
<zul> CHECKSUM_HW has disapeared in 2.6.19 if i recall
<BenC> s/CHECKSUM_HW/CHECKSUM_COMPLETE/
<BenC> that's the fixup I was talking about
<zul> ill send you a patch
<ajmitch> ok
<ajmitch> BenC: thanks, it's working now (once I removed a reference to config.h as well)
<BenC> yeah, that's the other one
<zul> kylem: for that hang on amd64 im working on an update
#ubuntu-kernel 2006-11-24
<kylem> shit.
<ajmitch> oh, another willing victom for the xen team?
<infinity> "victom"? :)
<ajmitch> I just got back from lunch.. I'm not normally *that* sloppy :)
<ajmitch> infinity: can a package build be given back for a single arch?
<infinity> Of course.
<infinity> Which'un?
<ajmitch> libofx, and then gnucash once it's published
<ajmitch> seeing errors like 'no space left on device' in build logs is fun
<infinity> Fun for me too...
<infinity> Which host?
<ajmitch> ross
<infinity> Ngh.
<ajmitch> build log is from 2 weeks ago
<infinity> Oh, I may well have fixed that, then.
<zul> damn you peekvid sucking up so much of my time
<kylem> motherfucker.
<kylem> ok, got all the CVEs now...
<gnomefreak> ebnyou around. i have a question about the -6 kernel in feisty. i have someone getting bios errors and pci errors and kernel fails to boot with them.
<gnomefreak> ack
<gnomefreak> BenC: that was for you
<fabbione> file a bug in launchpad with details
<fabbione> details are NOT optional
<gnomefreak> lol
<fabbione> and we have been down this road already once
<gnomefreak> yes i know but he doesnt have much details
<gnomefreak> thats why i didnt send him there yet. he gave me a couple of lines of output
<fabbione> and what does make you think that we can even guess those 2 lines?
<gnomefreak> ##### PCI: BIOS BUG: MCFG AREA AT E00000 IS NOT 6820-RESERVED ##### PCI: NOT USING MMCONFIG ###### DRIVERS/USB/INPUT/HID-CORE.C:V2.6:USB HID CORE DRIVER
<gnomefreak> those are exact to what he gave me
<fabbione> BIOS BUG: <- tell him to upgrade his bios
<gnomefreak> im hoping bios bug doesnt mean that
<gnomefreak> he didnt wait around :(
<gnomefreak> he said hed file a bug so ill let him know if i see him
<mjg59> gnomefreak: Those messages are harmless
<gnomefreak> thats all he said he was getting
<gnomefreak> i believe he said he was on a realtek (mobo im assuming)
* mjg59 shrugs
<mjg59> As I said, those messages are harmless. Disabling mmconfig isn't going to cause problems.
<mjg59> Is there any way for a userspace application to get a notification when a hardware interrupt is fired?
<kylem> yes.
<mjg59> kylem: How?
<kylem> the canonical way would be to have it block on a read of a device node until the interrupt hits.
<kylem> assuming i get what you mean... you might be able to send a signal if you know the tasks pid too.
<mjg59> Oh
<mjg59> No, I want a userspace app to be woken up when a specific hardware interrupt is fired
<mjg59> Like select, but a mask of IRQs rather than fds
<kylem> oh. gross.
<kylem> pity you can't inotify on /proc/interrupts... ;-)
<mjg59> Polling /proc/interrupts is presumably fairly lightweight
<zul_> hey
<zul> er...why cant i clone ubuntu-edgy-updates
<pitti> hi guys
<pitti> BenC, zul, kylem: ping
<BenC> pitti: pong
<zul> pitti: pong
<keescook> mornin'
<zul> hey keescook 
<keescook> hi zul :)
<pitti> BenC: With kylem onboard, do you have new assignees for stable kernel updates?
<BenC> pitti: it's zul->breezy, kylem->dapper, me->edgy
<pitti> we have a couple of pending issues, including the one I mailed you about yesterday
<pitti> so I'd like to have a new batch rolled out next week, if that's possible
<zul> is the kernel-sec svn updated?
<pitti> BenC: ah, great
<pitti> zul: svn contains everything I know about that has patches available
<zul> ok cool
<pitti> there are some more recent CVEs, but unpatched
<pitti> (mostly from the 'Month of kernel bugs', the fs fuzzer)
<pitti> zul, BenC: you should have gotten one more issue in you mailbox; I still need to send it to kylem
<pitti> (I can't put that into the svn yet)
<zul> when did you send it
<pitti> yesterday
<BenC> I got it
<pitti> BenC: bah, I didn't encrypt it to myself; can you please forward it to Kyle?
<zul> what was the subject? i might have missed it
* pitti msgs
<zul> okie dokie
<zul> so when next week?
<BenC> shows how much I use pgp encrypt
<BenC> what's the lp keyserver?
<Mithrandir> BenC: keyserver.ubuntu.com, iirc
<keescook> Mithrandir: yup.
<pitti> not before Tuesday
<pitti> I'd target Wed or Thu
<BenC> hkp:// or ldap://?
<zul> ok thats fine with me
<BenC> pitti: evo isn't cooperating with me for doing an encrypted email
<pitti> BenC: ok, nevermind; I'll forward it to him
<zul> pitti: got it will be included
<zul> BenC: maybe you should use console ;)
<zul> nice xen 3.0.4 in december
<BenC> stupid stupid stupid
* BenC kicks evo
<zul> hehe
<pitti> BenC: I mailed Kyle
* kylem waves.
<kylem> is this the embargoed one? (haven't checked email yet)
<pitti> hi kylem 
<pitti> kylem: yes, I sent you mail about it
<kylem> ok.
<kylem> i assume i shouldn't put a fix into my git tree until tuesday then?
<pitti> kylem: right
<pitti> kylem: if you need to git commit before preparing the package, then please do it on Tuesday as the last patch
<kylem> ok.
<kylem> someone else will need to upload until i get approved for core-dev, it should be ready to upload on tuesday as soon as the embargo is lifted.
<pitti> kylem: are you an ubuntu-dev?
<zul> i doubt he is
<kylem> pitti, nope.
<pitti> kylem: ok, I can do the upload for you, if you can put it on chinstrap?
<kylem> ok.
<kylem> i'll add @canonical.com to my gpg key.
<kylem> ok, i've already got everything from kernel-sec in dapper.
<kylem> BenC, i can probably take care of edgy security too, if you want
<BenC> kylem: Sure, that'd be great...mainly you should be able to just pull from dapper (that's what I've been doing)
<juliux> evening, does somebody know why wlanconfig, for madwifi is not in edgy?
<siretart> juliux: it is in a package called 'madwifi-tools', in universe, IIRC
<juliux> siretart, not in edgy:(
<juliux> siretart, in june was madwifi_new released
<pitti> madwifi-tools | 1:0.9.2+dfsg-1 | http://de.archive.ubuntu.com feisty/universe Packages
<pitti> madwifi-tools | 1:0.9.2+dfsg-1 | http://de.archive.ubuntu.com feisty/universe Sources
<pitti> so maybe that was too late for edgy?
<siretart> woah. that's really sad
<juliux> 27.6 was to late??
<juliux> that was the release of madwifi 0.9.2
<mjg59> The release date is irrelevant
<juliux> there is also the madwifi-ng modules in edgy but not the tools
<mjg59> Most of the developers don't use madwifi, let alone ad-hoc mode
<mjg59> So the absence wasn't noted
<siretart> hm. can we get madwifi-tools into edgy-updates?
<siretart> or at least edgy-backports. but -updates would be nicer..
<pitti> siretart: no, not -updates
<siretart> hm. -backports then..
<juliux> https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.15/+bug/53489 there is a bugreport about this
#ubuntu-kernel 2006-11-25
<zul> kylem: it looks like i cant clone your ubuntu-dapper-updates repo
<kylem> why not
<zul> chuck@homer:~/work/kernel/gits$ git clone git://git.kernel.org/pub/scm/git/linux/kernel/git/kyle/ubuntu-dapper-updates.git
<zul> fatal: unexpected EOF
<zul> fetch-pack from 'git://git.kernel.org/pub/scm/git/linux/kernel/git/kyle/ubuntu-dapper-updates.git' failed.
<kylem> it's 'cause i hate you
<zul> ah ok 
<zul> thats what i thought
<zul> thanks kyle seems to be working again
<kylem> zul, you had a superfluous /git in your url.
<zul> meh...i suck sometimes
* ajmitch shuts up
<zul> back to watching braindead
<BenC> mjg59: ping
<fabbione>   MODPOST 1906 modules
<fabbione> WARNING: Can't handle masks in drivers/ide/pci/atiixp:FFFF05
<fabbione> WARNING: "spin_lock_irqsave_nested" [net/irda/irda.ko]  undefined!
<fabbione> make[3] : *** [__modpost]  Error 1
<fabbione> make[2] : *** [modules]  Error 2
<fabbione> kylem, BenC: ^^ latest git
<fabbione> (our git)
<BenC> lol, "our git"
<BenC> fabbione: Weird, I'll try a quick compile
<dade`> hola
<dade`> mactel news ? 
<dade`> BenC: -^
<BenC> dade`: in progress
<dade`> cool
<BenC> fabbione: I've reproduced it, and it looks like Linus let a bogus patch in at the last minute
<BenC> I'll fix it in the morning
<mjg59> BenC: Yo
<fabbione> BenC: sure no problem. I was just test building for a gfs update
#ubuntu-kernel 2006-11-26
<dade`> should I do a make-kpkg clean before a git pull ?
<zul> BenC: ping
<zul> it looks like pm_power_off is EXPORTED twice does that mean anything to you?
<zul> er..nevermind
* kylem looks at zul funny.
<zul> must be tired
<infinity> zul: Back away from the computer, go have a long relaxing shower, and find something else to do.
<zul> you are right later..
<kylem> bleh wireless.
<dade`> should the current git kernel compile cleanly ?
* Starting logfile irclogs/ubuntu-kernel.log
<kylem> BenC, ping
<BenC> kylem: pong
<kylem> any idea where the snd-atiixp module disappeared to? https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/73313
<mjg59> CONFIG_SND_ATIIXP=m
<kylem> yes... indeed.
<mjg59> He seems to be missing all the snd- modules
<mjg59> Looks like he's only got OSS
<kylem> oh. interesting.
<BenC> kylem: I'd say tell him to do "sudo apt-get --reinstall install linux-image-2.6.17-10-generic"
<BenC> and then reject accordingly
<kylem> oh.
<kylem> well, i don't know where the module is hiding.
<kylem> but it's loaded in his lsmod.
<BenC> oh wait, he has -386, not -generic
<dade`> mactel svn patchset 2.6.19-rc6 updated
<mjg59> The sci-en and s3 ones are unnecessary
<mjg59> We also don't want the usb-delay one
<mjg59> Rest look fine
<BenC> mjg59: Oh, hey, I remember what I wanted to ask you...one thing we have a problem with in edgy is that ide_all_generic doesn't work because it's a module (2.6.19 has a module param for this now)
<BenC> mjg59: How bad would it be if we always did ide_all_generic?
<dade`> this morning I was not able to build the current git kernel, is that normal ?
<kylem> BenC, erm. what do you think about a backport of r8169.c to replace this really shitty realtek r1000.c driver for edgy-updates?
<mjg59> BenC: Bad
<mjg59> BenC: initramfs-tools just needs to pass the option
<dade`> pffff
<dade`> pls fix the topic
* ..[topic/#ubuntu-kernel:kylem] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.19-6.9 uploaded - This is a bad bear. Use it, but there are still a few missing modules.
#ubuntu-kernel 2007-11-19
<cathyal> IntuitiveNipple: hi:D
<IntuitiveNipple> Uh-oh :p
 * cathyal waves
<cathyal> IntuitiveNipple: anythig up with the bug ?
<cathyal> bug #163551
<ubotu> Launchpad bug 163551 in linux-source-2.6.22 "Kernel oops during boot on gutsy server" [Undecided,New] https://launchpad.net/bugs/163551
<cathyal> Cool
<IntuitiveNipple> You fixed it didn't you?
<cathyal> YEah figured there'd be some comments
<cathyal> :)
<cathyal> Makes me feel all special you see
<IntuitiveNipple> lol
<cathyal> So tj what else?
<kraut> moin
<abogani> BenC: I suspect that "sort" at the line 21 in debian/rules.d/6-binary-custom.mk should be "sort -n".
<BenWartig> hello
<BenWartig> I have a little problem, I m trying to get our server fixed (Sun X4100 M2) there is a bug with the raid drivers #37452 but now iÂ´m stuck. Could someone help me out?
<vosskaem> I want to test the driver in dapper-proposed https://bugs.launchpad.net/bugs/37452 but need some help.
<ubotu> Launchpad bug 37452 in linux-source-2.6.15 "fusion mpt sas driver does not find a RAID1 disk during installation(Sun Galaxy X4200 and X4100, Dell SASR5/i)" [High,Fix committed] 
<vosskaem> I want to test the driver in dapper-proposed https://bugs.launchpad.net/bugs/37452 but need some help.
<ubotu> Launchpad bug 37452 in linux-source-2.6.15 "fusion mpt sas driver does not find a RAID1 disk during installation(Sun Galaxy X4200 and X4100, Dell SASR5/i)" [High,Fix committed] 
<BenWartig> hello,  I have a little problem, I m trying to get our server fixed (Sun X4100 M2) there is a bug with the raid drivers #37452 but now iÂ´m stuck. Could someone help me out?
<zul> BenC: do you want to see something really really ugly http://pastebin.ca/784077
<BenC> zul: gotta love that x86-merge+xen junk
<zul> i hope you are being sarcastic ;)
<zul> good weekend?
<abogani> BenC: I suspect that "sort" at the line 21 in debian/rules.d/6-binary-custom.mk should be "sort -n".... Could you check please?
<BenC> zul: so so
 * zul has to figure out how to baby proof cat5
<Nafallo> !seen kylem
<ubotu> Sorry, I don't know anything about seen kylem - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<Nafallo> baah
<mjg59> Nafallo: He's working for RH now
<Nafallo> oh.
<Nafallo> to bad :-/
#ubuntu-kernel 2007-11-20
<Hobbsee> woot!  latest kernel upgrade in progress!
<abogani> x86 merge drive me crazy!
<vosskaem> hello
<vosskaem> Is there someone who can help me to try the proposed driver from  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/37452
<ubotu> Launchpad bug 37452 in linux-source-2.6.15 "fusion mpt sas driver does not find a RAID1 disk during installation(Sun Galaxy X4200 and X4100, Dell SASR5/i)" [High,Fix committed] 
<vosskaem> I have a sun fire 4100 and want to try the fix in this bug, but need some assistance
<vosskaem> hello
<vosskaem> whats wrong with me that nobody is anwering?
<soren> vosskaem: Most of the kernel team is in the US. They're only just starting to get into work now.
<vosskaem> soren: but there are 67 persons in this channel ?!?
<soren> vosskaem: Yes?
<zul> vosskaem: yes but alot of them are idle
<vosskaem> ok, whats the best time to get some help for working on the bugfix?
<soren> vosskaem: US business hours.
<vosskaem> soren:ok, thanks
<nakeee> is there an easy way to compile the default kernel with the aufs lhash patch?
<EtienneG> hey guys
<EtienneG> Xen + fglrx
<EtienneG> is it known to work ?
<maks_> Xen and work in a phrase is a contradiction
<maks_> also fglrx is a piece of ...., tainting your kernel for good
<EtienneG> yep
<EtienneG> indeed
<EtienneG> I am asking on behalf of someone else, it was not my idea!!!
#ubuntu-kernel 2007-11-21
<zul> *sigh* old habbits die hard
<chaitues> hi could some one tell me what is netif in the kernel source code?
<zul> xen almost merged for i386
<rtg> zul: lemme know when.
<zul> rtg: merged, didnt say it was working ;)
<rtg> well, I'm not much interested until it works :0
<rtg> s/:0/:)/
<zul> lol
<zul> has anyone thought of putting kvm in lum for hardy?
<BenC> zul: kvm is in the mainline kernel
<zul> BenC: true but userland and kernel might not always agree
<BenC> zul: we need to make userland agree with the kernel...kernel sets the pace :)
<BenC> unless there's considerable reason not to
<BenC> especially now that the kernel has paravirt-ops for kvm
<zul> yep
<Keybuk> BenC: except when the kernel lags 20 years behind the pace of what userland wants
<BenC> Keybuk: I blame that one upstream kvm
<BenC> Keybuk: either they are moving too fast, or not syncing with linus enough
<zul> well you could just cherrypick them from the kvm git then
<BenC> this can easily be said for alsa
#ubuntu-kernel 2007-11-22
<damianc> this is weird
<damianc> ubuntu doesnt come with gcc?!
<fabbione> of course it does
<fabbione> apt-get install gcc :)
<damianc> Haha
<damianc> Does it not come with devel tools?
<fabbione> it depends what kind of install you did
<damianc> ok
<damianc> some C op told me it didint come with devel tools, got me a frown all of a sudden
<damianc> thanks
<dholbach> there's  acer-acpi-2.6.22-12-generic-gutsy  and  acer-acpi-2.6.22-12-generic  on http://revu.tauware.de - do they make any sens?
<dholbach> shall I ask them to get in touch with you on ubuntu-kernel@lists.u.c?
<mariogyn> anybody here
<mariogyn> iÂ´m having a question about back track 2
<zul> americans are weird they have thanksgiving at the wrong ttime it should be in metric time damn it
<damianc> anyone got any idea if the ipw2200 driver in recent kernels works?
<tjaalton> I'll upload a new l-r-m for hardy, the same I mailed about
#ubuntu-kernel 2007-11-23
<kraut> moin
<alex_joni> 'lo.. does gutsy have HIGHMEM4G set for the desktop kernel (2.6.26.22 I think)
<Nafallo> 2.6.26 isn't out AFAIK
<Nafallo> grep the /boot/config* file
<alex_joni> will do
#ubuntu-kernel 2007-11-24
<srwalter> I wonder why CONFIG_NET_USB_ZAURUS is disabled in the gutsy kernels?
<osmosis> ipw3945 on gutsy seems broken.
<osmosis> hence, https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/129112
<ubotu> Launchpad bug 129112 in linux-ubuntu-modules-2.6.22 "Please update to iwlwifi 1.0 and latest ucode" [Undecided,Fix committed] 
<osmosis> says fix commited, but how do I fix my laptop?
<sarahl> argh https://oiflist.com/cgi-bin/hello.php
<sarahl> why isnt this working
<sarahl> root@ubuntu:/etc/apache2# chmod 777 /var/www/oiflist/hello.php
<sarahl> root@ubuntu:/etc/apache2#
<sarahl> crap apache2 misconfiguration
 * sarahl sets the mime type
<sarahl> god i hate apache
<ln-> sarahl: and this is related to ubuntu kernel exactly... how?
<sarahl> not
<sarahl> you know most of the difference between ubuntu and fc these days is apt vs. rpm and a bit of gnome polish?
<ln-> and also the fact that in fc bugs are fixed, in ubuntu they are not.
<sarahl> hehe
<sarahl> lets not smash ubuntu now
<sarahl> just one thing though what about kernelwise?
<sarahl> is it not very different to fc?
#ubuntu-kernel 2008-11-17
<RAOF> I was looking at the grub2 merge, and it might be nice to make last-good-boot work with grub2 as well as grub.  As far as I can see, about all that requires is having the kernel-helper script available; this is in the grub package, but looks like it should work without modification for grub2.
<RAOF> Could we split that script out of the grub binary package, so grub2's various binary packages could depend on it?  I'm just floating this at the moment; I haven't finished testing that it works!
<trv__> hello
<trv__> one question about something strange I noticed
<trv__> in ubuntu, /proc/kallsyms contains the symbol sys_call_table and its address. I've tested in debian,redhat/fedora/centos and this file does not contain the symbol for sys_call_table
<trv__> is there a reason for that? ( i'm not even sure what is the "correct" behavior here)
#ubuntu-kernel 2008-11-18
<TheMuso> c
<apw> does anyone have a toshiba laptop who might be interested in testing out an intrepid based forward port of the hardy toshiba_acpi module?
<Kw4h> i have a question regarding the gspca drivers on ubuntu
<Kw4h> in the sourcecode from both the official gspca driver, and the gspca-source package, my webcam sensor isn't defined right
<Kw4h> after changing it, building the source, and reloading the driver the logs show that it still loads the wrong sensor
<Kw4h> now I changed the 'gspca' module, but the module responsible for the webcam is 'gspca_vc032x' (which is depandant on 'gspca_main')
<Kw4h> does anyone know how those two (gspca and gspca_main) interact?
<BenC> Kw4h: sounds like you have a lot of cruft modules...you should clean things up a bit
<BenC> amitk: ubuntu-jaunty raw rebase pushed
<Kw4h> BenC - this is pretty much a clean Kubuntu installation
<amitk> sweet, cloning now
<BenC> Kw4h: no idea how those things interact then...you are compiling external modules to what we supply stock, so you are bound to get some conflicts
<Kw4h> the 'gspca' module already existed
<Kw4h> I merely recompiled it
<Kw4h> also the gspca_main module came with kubuntu out of the box
<Kw4h> so, what gspca version is distributed by ubuntu then? gspca v2?
<Kw4h> ah... moinejf.free.fr - that one
<mkrufky> i know there is a nice command that generates a perfectly formatted git pull request against a target tree / branch ...  i thought it was git-pull-request, but i thought wrong
<mkrufky> anybody know offhand?
<ogasawara> mkrufky: I think it's git-request-pull ?
<mkrufky> ah, lol
<mkrufky> thanks
<trv__> hello. I have noticed that by doing a " cat /proc/kallsyms | grep sys_call_table " it returns you the symbol and the address of the sys_call_table. BUT, doing so in debian/redhat(and derivatives), even in vanilla kernel also, returns nothing !
<trv__> what's going on ?
#ubuntu-kernel 2008-11-19
<trv__> ok i've found it
<trv__> ubuntu must be one of the few if not the only distribution that sets KALLSYMS_ALL=y
<trv__> may ask why is this ?
<_ruben> huh, wtf .. the -virtual kernel in intrepid shows up as -server? confusing
<mkrufky> rtg: Im sorry i know my emails are long-winded :-P
<mkrufky> rtg: any other info u need?
<mkrufky> smb_tp: ...and im back now -- thanks for noticing ;-)
<rtg> mkrufky: nope. smb_tp is gonna handle it.
<mkrufky> cool... thanks
<smb_tp> mkrufky, whenever there was a v4l question.
<smb_tp> mkrufky, :)
<mkrufky> ah... 
<mkrufky> i started coming online later on in the day because i noticed i was getting less hauppauge work done :-P
<smb_tp> mkrufky, I will go for the lum updates next. The info is quite sufficient
<mkrufky> but you should feel free to email me if there ever is a question
<mkrufky> ...and it doesnt have to be about hauppauge stuff -- i started off as a linuxtv.org guy before they found me :-)
<smb_tp> mkrufky, Ah and since my day shifted rather to the other end...
<mkrufky> hah  murphy's law
<mkrufky> i will just try to have more of a presence again
<smb_tp> mkrufky, NP, I just should remember I can mail you. :)
<mkrufky> yes... its mkrufky at linuxtv dot org
<smb_tp> mkrufky, Ok, cool
<smb_tp> mkrufky, Just a slight warning, it can take a bit until the changes will show up. There is a bit of other stuff ahead
<mkrufky> thats ok .... i'll be happy when i see them in the git tree
<mkrufky> i dont mind if it takes a month or two before they get pushed out to users
<mkrufky> since the new sticks aren't available for purchase yet, anyway
<smb_tp> mkrufky, It should not take that long. So that's okay then
<mkrufky> ok cool
<_ruben> hmm .. most recent -virtual kernel image package also shows as -server .. strange
<rtg> zul: another xen question: https://lists.ubuntu.com/archives/kernel-team/2008-November/003548.html
<zul> rtg: yeah I saw it
<zul> its on my list to answer 
<rtg> smb_tp: do you have all 12 v4l patches in a git repo ? I think there are at least 4 SRUs in that patch set in order to effectively track regressions.
<laga> mkrufky: looks like my mail didn't go through. if you update the file name of the firmware, won't ehtat break existing setups?
<mkrufky> no laga, there are no existing setups because that hardware is not shipping
<mkrufky> laga: the email went thru, but u sent it to me privately without cc to the list
<smb_tp> rtg, currently they are only in a private branch, if you are referring to the uvcvideo patch set
<laga> mkrufky: ah. :)
<mkrufky> rtg: pardon me being nosy -- which v4l patches?  (im just curious)
<laga> mkrufky: ah, right. some mailing lists do not set reply-to correctly.
<mkrufky> correct
<rtg> mkrufky: LP #290506
<mkrufky> thanx
<smb_tp> mkrufky, Its chenges to uvcvideo driver to work with intrepid and the v4l compat lib
<mkrufky> ah, very cool... we spoke about that stuff at plumbers...  
<mkrufky> laga: correction -- the hardware isnt shipping _yet_
<mkrufky> should be soon
<smb_tp> mkrufky, yes. In that case there seemed to be some glitches in uvcvideo which made it not work with cheese.
<mkrufky> i've been making a point to get driver support into the kernel BEFORE the devices appear on store shelves
<rtg> apw: you can push 'em straight in to the main repo. make sure the SOB trail includes mine and Ben's for the corresponding ACKs.
<apw> i have added 'acked-by' as appropriate, is that sufficient
<rtg> apw: yep
<apw> cool thanks
<Kano> hi rtg , somebody told me you have got a 2.6.28 repo, but it does not look like it would work
<rtg> Kano: its not done yet. give it a week.
<Kano> the jaunty one then?
<rtg> apw: depmod sorts according to rules in /etc/depmod.d/ubuntu.conf.
<rtg> if you install LBM, then LBM drivers come first in the search order.
<rtg> there are problems if drivers of different names both claim the same PCI ID, but thats adifferent issue.
<apw> yeah ok, makes sense.  so what criteria is there for inclusion in lbm?
<rtg> apw: um, its kind of loose. does it solve someone's problem without wreaking havoc? Is it a widely used device? Is the mainstream version totally borked? and on and on...
<rtg> I think r8169 likely qualifies
<apw> ok so i think this probabally is a good fit then, the version of r8169 is 'beta' in .27 and should be 'close to done' in .28
<apw> the reporter has pulled down the .28 version from somewhere and hand compiled it and seems to have had success with it
<apw> ok ... so even if its a bust in the end learning how to put a module in here is worthwhile me thinks
<rtg> apw: ok, so it can live in LBM for awhile. if it proves to be stable, then we could promote it to the kernel package in the ubuntu directory.
<apw> sounds like a sane way forward
<apw> rtg this thing is asking for the main kernel source at -10, is there some magic at play
<rtg> what thing?
<rtg> DKMS?
<apw> oh .. heh ... when i tried to debuild lbm it asked for the -10 source tarballs
<apw> but they don't exist as yet do they
<rtg> apw: you'll need to build the -10 kernel, then install linux-headers* for your arch in the correct chroot.
<apw> ok thanks ...
<shay> anyone involved with Xen?
<zul> shay: yep whats up?
<shay> zul, any status of Xen support on Ubuntu 8.10 kernels?
<zul> shay: yep domU only
<shay> zul, I might be a little confused, but as far as it seems, or from what i can understand from the articles i've found, seems like Ubuntu is dropping support of Xen (and from what I understand, giving priority to support KVM instead) am I wrong?
<zul> shay: xen is community suppored kvm is the prefered method
<shay> zul, any links you can give me referring development status or how can I get started on helping to improve the situation?
<fransman> do we have 2.6.28 or 2.6.29 in view for Jaunty?
<rtg> .28 at the moment
<fransman> cool
<fransman> is there a git created ?
<rtg> BenC is working on it.
<fransman> BenC1: is that ubuntu-next.git ?
<rtg> fransman: its gonna get rebased, so just wait a bit.
<fransman> thanks for helping at the moment rtg:
<mkrufky> laga: i just received your bounce
<laga> my bounce?
<mkrufky> Reason: Error: DNS server reported a server failure [101]
<mkrufky> yes... you didnt get my response to your email, earlier
<mkrufky> apparantly it bounced
<mkrufky> dns problem on laga.ath.cx
<mkrufky> thats a new one -- runnign a dns server on a dynamic domain :-P
<mkrufky> of maybe dyndns just hiccup'd ... i dunno
<laga> oh, damn.
<laga> my dyndns expired again
<mkrufky> ah
<mkrufky> well that explains it :-P
<laga> no, it hasnt
<laga> but it was about to ;)
<mkrufky> ah
<laga> still weird
<mkrufky> email is just not a great technology
<mkrufky> ha!  my dyndns is about to expire, too
 * mkrufky makes mental note to renew tonight
#ubuntu-kernel 2008-11-20
<Napsong_boy> hi
<Napsong_boy> any girls from jakarta in this room?
<rtg> BenC: so whats the story with the Jaunty kernel? It looks like amit took the Intrepid -proposed kernel, added armel, then uploaded that (or someone did for him).
<BenC> rtg: I wasn't expecting to get jaunty kernel done till after alpha1 went out
<BenC> rtg: I've almost finished up the cleanup so I can send the summary to kernel-team
<BenC> then I'll push and start some builds
<rtg> BenC: actually, my curiosity was more about having to redo the armel work.
<BenC> rtg: I'm not sure how amitk is handling arm kernels
<BenC> rtg: I think that upload was mainly to get bootstrap started (linux-libc-dev)
<rtg> BenC: well, lemme know if you need any help with Jaunty.
<BenC> sure thing, thanks
<BenC> it's pretty much grunt work at the moment
<rtg> I think we're gonna have to figure out how to build armel using qemu until we get some porter machines.
<apw> rtg perhaps we could make a qemu machine on an existing porter as a fake porter?
<rtg> apw: ugh, that would take massive support from IS (which would also take awhile).
<dholbach> hi guys :)
<dholbach> did we have any bug reports about overactive fans on laptops like the lenovo x61s?
<rtg> dholbach: sounds familiar
<dholbach> fan speed is ~3800 when the machine is basically idling in gnome intrepid
<rtg> amitk: don't you have one of these? ^^
 * soren wonders if the overactive fan is the problem or a symptom
<rtg> soren: ACPI is your friend :)
<soren> rtg: Now I know you're lying :)
<mjg59> Thinkpad fans aren't ACPI fans
<soren> I'm just thinking that the overactive fan is a symptom of the system being too hot for some other reason.
<rtg> mjg59: direct sensor connect?
<soren> s/is/might be/, I mean.
<mjg59> rtg: Under control of the embedded firmware
<mjg59> There's a Thinkpad ACPI method that lets you change embedded controller values, which lets you take over control of the fan
<mjg59> But that's not the default behaviour
<soren> Interesting.
<mjg59> So an overactive fan generally indicates high temperature
<mjg59> thinkpad-acpi exposes an hwmon interface that should give you the temperatures
<rtg> mjg59: is the embedded firmware running on an independent processor?
<apw> i know the t40'ish ones nearly always needed the fan
<apw> though my t61 seemed to turn it off, not got it any more to confirm
<mjg59> rtg: Yeah, there's a microcontroller
<mjg59> The embedded controller is generally the same hardware as the keyboard controller these days
<dholbach> wow
<dholbach> sensors-applet just added like 456765345678987654345678 temperature thingies to my panel
<dholbach> they all seem to be between 25Â°C and 37Â°C
<amitk> rtg: no lenovo here
<amitk> rtg: I meant no lenovo x61s here
<rtg> amitk: no problem. I didn't realize thermal control was independent.
<dholbach> do you have any numbers on what your fans are running at when the machine is reasonably idle?
<sconklin> ogasawara: if a LP bug is set to milestone:Later, that doesn't imply anything about whether I should pick it up from kernel team or not, does it? That gets set later in the process? 
<ogasawara> sconklin: when it's been milestoned for later that typically implies we couldn't get a fix into the current release but it should be considered for the next release.
<ogasawara> sconklin: so if you'd like to work on the bug, feel free.
<sconklin> ogasawara: ok, thx
<Daviey> Is a 2.6.28 ppa upload planned soon?
<rtg> Daviey: it'll likely be awhile yet.
<Daviey> aww
<Daviey> rtg: Any reason your git branch shouldn't build okay on PPA?
<rtg> I don't have a 2.6.28 branch yet
<Daviey> oh!
<Daviey> sorry rtg, thought i saw you did
<Daviey> my bad
<rtg> its still in process. we should have a Jaunty kernel pretty soon, which will be 2.6.28 based
<rtg> pgraner: if the stable update is referenced by a single SRU justification, then I didn't see the need to expand on the individual commit messages.
<pgraner> rtg: I thought the reason was to ensure that they had all been looked at and were sane, were there any that were dropped or did we take it wholesale?
<rtg> pgraner: I looked at each one, though not all apply because they are arch dependent. however, since the intrepid-ports kernel is based on intrepid, I felt it was important to carry even those patches that did not apply.
<pgraner> rtg: Ah ok. perhaps next time drop that in the bug, keeps me from bothering you.
<rtg> drop what in the bug?
<pgraner> rtg: the explanation you just gave me, basically any relevant info about the patch set, why things are there (or not) etc...
<rtg> pgraner: as one of my profs used to say, 'its intuitively obvious'
<pgraner> rtg: ah... I'm more in the stupid proof camp...
<pgraner> rtg: lots of people are reading these bugs and the more info as to why, is better.
<rtg> pgraner: I'll get ogasawara to add it to the SRU stable update boiler plate. She's been creating the master bug for each stable update cycle.
<pgraner> rtg: nice... leave it to you to automate it
<rtg> I'm sure ogasawara likes being known as my automaton :)
<rtg> apw: the more I think about it, merging the changelogs doesn't make sense because it does not accurately represent the changes that particular kernel went through. 
<apw> no what i did was keep the changelog unchanged, as its just a template
<apw> and when i printchanges is includes changes from both branches
<rtg> apw: I've a conf call I need to prepare for. I'll respond in detail on the mailing list.
<smb_tp> rtg, I assume uploading the the next -proposed kernel with a well chosen -v on the dpkg_buildpackage would show all changes required... 
<rtg> smb_tp:  its helps with the diff that you see in LP.
<smb_tp> rtg, That was my guessing. Let's whether my idealistic thinking turns out true :)
<apw> so if we have bug which we have actually generated a fix and pushed it upstream, but there is little pressure to back port that fix, so the sensible way forward is to wait for it to flow back down naturally ...
<apw> what is the right state for that bug ... Will not fix ?
<apw> or perhaps we mark it as a bug upstream and Fix Committed it there, and will not fix on our side
<apw> ogasawara, ^^ ?
 * apw asks the oracle
<BenC> apw: that sounds right
<apw> thanks
<ogasawara> apw: sorry was at the dentist, but yes Fix Committed likely for Jaunty and Won't Fix for Intrepid sounds reasonable
<apw> i went for adding upstream and fix committed there, and won't fix for our task
<apw> so that we don't have to worry about it at alll
<ogasawara> apw: that works too
<apw> in case jaunty doesn't end up with it, then our tasks would lie
<apw> still we got something accepted upstream so thats good
<apw> (trivial though it was)
<apw> ogasawara, for something that looks like it will come down the pipe in mainline updates for jaunty, what is our bug handling for that
<apw> straight to invalid if its against jaunty i guess?
<apw> we really could do with a 'no change needed' status
<apw> invalid just feels a little to much like 'submitter stupid'
<ogasawara> apw: invalid always feels so harsh to me for those types of bugs.  so I typically just post a note we'll get the fix for free with Jaunty and set the status to In Progress and assign it to myself.
<apw> what then move it to fix released when the kernel goes out?
<ogasawara> apw: then I know to keep an eye on the bug and flip to Fix Released when we do get the fix
<ogasawara> apw: I think there's actually a few maybe on the bug list I sent you like that
<apw> yeah its one of those i was looking to handle
<apw> i've confirmed its in upstream and on its way to us ...
<apw> so i'll do what you suggested here
<ogasawara> as long as it's on the list I'm sure one of us will see it and remember to close it out
<apw> oh do you have edit title priviledge
<apw> bug #222324 has hardy in its title, but that makes little sense as the bug is now 'against' jaunty
<ogasawara> apw: we all do, it's just not obvious.  click on the little yellow circle icon next to the title
<apw> heh ... oh ... strange ... this interface seems to resist understanding at times
<sconklin> rtg: I'm backporting a touchpad driver into intrepid from Linus's tree. His commit didn't apply cleanly, but only had minor conflicts. Is this a sauce patch?
<rtg> sconklin: not if it came from upstream.
<rtg> sauce is for patches that we either expect to conflict, or will never go upstream.
<sconklin> rtg: I just wondered because it needed a little fussing. Thanks.
<sconklin> ok, got it
<rtg> in actuality, the first case kind of abuses the notion of sauce.
<sconklin> yeah, it's almost like we need a third name
<BenC> I always took sauce as something that isn't in upstream
<BenC> be it a patch we created, was pulled from an external tree, etc.
#ubuntu-kernel 2008-11-21
 * apw yawns
<amitk> morning apw 
<apw> morning amitk ...
<NCommander> morning amitk 
<amitk> NCommander: morning
<NCommander> morning
 * NCommander wonders if we're stuck in an infinite loop or something
<apw> heh, heres hoping not
 * NCommander has no desire to debug the kernel team
 * NCommander runs from the bad pun
<amitk> hehe
<NCommander> The question is do we need kgdb, or old fashion printk() debugging ;-)
 * apw strokes printk
 * NCommander sees apw saying "my precious"
<apw> something like that
<apw> amitk, i take it jaunty a1 will ship with your armel kernel?
<amitk> apw: yes. 2.6.27-based kernel.
<amitk> BenC is planning to upload a 2.6.28-based kernel today
<apw> so that will miss a1 i assume, it sounds like the buildd's are chugging a1 as we speak
<rlj> hi all, i experienced LP#291878 and wrote a trivial patch to the kernel (uploded to LP) to add a keyboard quirk for the affected laptop model. the patch works the way it's supposed to on my laptop and solves the issue, but so far no one else affected by the bug has responded to my patch. what's the proper way to get it included into the ubuntu kernel and also getting it upstream?
<amitk> apw: yes, 2.6.28 isn't slated for a1
<apw> rlj, the patch looks low risk.  normal process is to push the patch upstream to the maintainer in MAINTAINERS in the kernel source, that looks to be 'INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN) DRIVERS'
<apw> you would want to write up a proper description and make sure to add a Signed-off-by: to it
<rlj> ah i see, the MAINTAINERS file seems helpful. didn't think to look there. :S
<apw> process is always the tricky part.  also i see this patch is really about the kernel but the bug it not against the kernel
<rlj> i'd like the affected people to try out the patch to figure out if more DMI matches should be added before submitting upstream, but i can't force them to recompile... :) oh well.
<rlj> well, the bug is about "ubuntu" currently, isn't it
<rlj> but from my investigation, it seems the proper place to "fix" the broken hardware is with a kernel quirk
<apw> no you never can, but its pretty limited to one laptop type and you have that and this makes it work for you
<rlj> rather than some kind of userspace quirk
<apw> yes, and your fix looks like its of the right form.  the acid test is sending it to the maintainers and seeing if they shout at you
<rlj> "the acid test is sending it to the maintainers and seeing if they shout at you" ?
<apw> yeah, your patch looks reasonable to a kernel-dev who isn't particularly familiar with keyboard quirks (me), so i would say "looks good, send it to the maintainer"
<apw> meaning if its not right they will then tell you what you should have done and it gets fixed
<rlj> oh, misinterpreted "the acid test" for some automated software rather than a figure of speech ;)
<apw> yeah sorry i often forget that good english does not mean 'knows all those mad engish local sayings'
<apw> i have sorted out the bug assignement and states and importance and stuff ...
<apw> rlj have you ever submitted a patch upstream before?
<rlj> thanks for the pointers. i'll go with the workflow in the MAINTAINERS file in the kernel distribution and try and get it upstream. this means ubuntu will include the fix indirectly after a new 2.6.27 stable kernel has been released from upstream? or should i do something else to make ubuntu get the fix before jaunty?
<apw> well its untlikely to make .28 now, as we are mostly in bug-fix only phase for that
<apw> so its unlikely to make .28, and jaunty is most likely .28 based
<apw> but once its upstream it is much easier to justify picking it up as a backport
<apw> actually i may as well take this bug as i know all about the bug now
<rlj> ah, true
<apw> i can help you get the thing in shape for upstream
<rlj> no, haven't submitted before. so  i email the maintainer privetely or just the lkml?
<rlj> /s/and not the lkml/
<apw> you would send it to the lists as listed in the maintainers entry
<apw> so in this case you would send it to Dmitry direct and linux-input direct, and then likely CC: linux-kernel
<apw> as that is the 'records everything' list
<apw> make sure the patch has a good one liner, a full description after that
<rlj> aha
<rlj> yeah
<apw> then the signoff, and finally make sure the patch is clean via checkpatch
<apw> then you are pretty set ... you might also Cc: me as well
<apw> query rlj
<abogani> smb_tp: Are you around?
<smb_tp> abogani, Yes
<abogani> smb_tp: If you want i push updated preempt rt support on zinc.
<abogani> for Hardy i meant.
<smb_tp> abogani, Great, ok. I'll go for them as soon as I am finished fighting my build chroots
<abogani> Thank you very much.
<smb_tp> abogani, Thanks for updating them so quickly
<smb_tp> abogani, mm, one question. This is all based on the current (more or less) master? 
<smb_tp> abogani, I am asking because all the big changes for 2.6.24.7 are on the next branch of my tree http://kernel.ubuntu.com/git?p=smb/ubuntu-hardy.git;a=shortlog;h=refs/heads/stable
<smb_tp> abogani, Unfortunately importing those changes had quite an impact on rt because there are a few central places changed (like scheduler).. :(
<abogani> smb_tp: I failed. I have used master. I'll go to do work for stable branch. 
<smb_tp> abogani, I sorry, this might have been unclear... ATM there is much branch juggling on some trees...
<abogani> No sorry, please. It's my fault.
<apw> smb_tp, if we have bug which needs much more than a kernel fix, but needs a decision on direction and will likely need a coordinated change with other packages, would that be a blueprint/uds type of thing?
<smb_tp> apw, I did not have the case myself, yet. But I think it depends on how much has to change. Minimum the affected packages have to be added to the bug and then getting the right "sponsor"
<apw> this is the wireless regdom thing sitting on our queue, realistically some infrastructure to tell us where we are is needed
<smb_tp> cking, had once a case with lmsensors. I don't think it generally has to wait until UDS
<apw> possibly in the short term till thats available, we might place all machines in the EU or something
<apw> as that would get us closer to no regression, a very tricky thing indeed
<smb_tp> apw, With wireless and what you say this might not be just a little fix in another package but some more re-design. So it is possibly something that needs more discussion
<smb_tp> apw, I would not believe placing all machines into EU will get that much liking
<apw> they are unrestricted prior to intrepid i believe, and i assume there is no setting for that in the new framework
<apw> there doesn't seem to be a good work around here as they have to be genuinly different in different places
<apw> so i guess the question is who is the best person to ask about what to do with this problem
<apw> do we have anyone in the wider architecting things role
<smb_tp> apw, Which sounds like something that not only affects one package like network manager but is a general issue probably with wireless extension? Guess Tim is more down this route than I am. But this particularly sound like an UDS topic
<apw> good point tim is wireless guru in our domain, will hastle him next :)
<smb_tp> apw, As soon as he gets up which usually is quite early :)
<soren> Does any of this look like a wifi nic to you guys? http://pastebin.ubuntu.com/75192/
<soren> I'm told that in vista, that box has wifi, but I don't see it.
<laga> maybe it's usb?
<laga> or the kill switch is acting up?
<soren> It might be USB, actually.
<amitk> NCommander: 14:18 < cjwatson> could somebody update linux-ports-meta in jaunty to the current ABI please?                                                  
<amitk> 14:18  * cjwatson <- uninstallable-packages police 
<smb_tp> amitk, NCommander Has someone started something already? Otherwise we could use intrepid-ports-meta.git as starter...
<amitk> smb_tp: I was hoping NCommander already started something or would be interested :)
<smb_tp> amitk, Ah, yes. :) If he has not yet, using the other git repo as initial source and adapting it should be simple. Would do it but my network is currently sucking due to uploads...
<smb_tp> amitk, NCommander You know whether 2.6.27-1 is current ports abi. If yes there is now a git repo at git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty-ports-meta.git
<amitk> smb_tp: I don't see such a git tree
<smb_tp> amitk, gitweb seems not to like it :(
<amitk> smb_tp: it takes some time to show up if you just pushed it
<amitk> cron job every 20-30 mins
<smb_tp> amitk, Well sometimes it seemed faster, but I guess that is rather the effect of being distracted long enough until looking again
<smb_tp> amitk, ;-)
<amitk> hehe
<BenC> Anyone know if rtg has looked into the new wireless regulatory domain stuff showing up in 2.6.28?
<smb_tp> BenC, Not sure but apw asked some questions into that direction this morning and probably will get back to him
<apw> BenC, from the bug we have i assume that the first steps of that are at least in .27, people are talking problems for high channels in EU as a result
<apw> i was wondering how we fixed such 'cross domain' things this morning, and we felt rtg was the right person to poke as step 1
<BenC> Well this seems to be all new stuff in 2.6.28
<BenC> the built-in static regulatory stuff is getting obsoleted for a userspace daemon that handles it
<apw> heh, well thats a step forward at least
<rtg> apw: there is a UDS session to talk about CRDA
 * apw wonders what that is ...
<rtg> apw: central regulatory domain agent
<apw> ahh good ... so i assume you are taking a role in that, given your predilictions in the wifi area?
<rtg> apw: I helped start the design, though I haven't had much of an active role in the development. That has been Luis Rodriguez who now works for Atheros.
<apw> to expalin why i was talking about this at all, we have a bug against intrepid as clearly some changes occured in .27 on the regularty control in the ieeeNNNN layer
<apw> and it sounds now that is changing again for .28, and we need to work out what our response is to those
<rtg> apw: well, there is a config option in .27 to ignore regulatory controls (which we have set). iin .28 and higher we'll need to implement the crda daemon.
<apw> rtg, oh has that changed, the config option, ie should it not longer be a problem in .27
<rtg> apw: in Intrepid regulatory compliance is attained through eeprom settings in each adapter, or through beacon location information element detection. typically its the union of those 2 features.
<apw> but there is an option to ignore it, and we have it turned on?  if so what version did we do that?
<rtg> apw: no, the config option that we have set is to ignore the _lack_ of a crda daemon (though I may be thinking about wireless stuff in LBM)
<matiass> Hello, 
<matiass> can i ask you about a bug that i reported but i don;t know what to do with it
<matiass> about the newest kernel
<matiass> ?
<apw> ahh i see
<apw> bug# ?
<matiass> yes
<matiass> i reported in bugzilla 
<matiass> also here is a thread in forum
<matiass> is with the newest kernel and my motherboard of INTEL
<matiass> DP43TF
<matiass> can you see maybe the thread? there is picture of the bug
<matiass> http://ubuntuforums.org/showthread.php?t=963662
<apw> which bugzilla is it reported in, and which bug# ?
<matiass> a second.
<apw> the forum thread seems to be almost unobtainable from where i am no idea  why
<matiass> https://bugs.launchpad.net/bugs/292663
<matiass> no way...
<matiass> i;m there now
<matiass> okey..i see they have problem with the ubuntuforum site
<matiass> so,, there is the bug in launchpad
<matiass> are you there?
<matiass> hello??
<speakman> Hi folks! I've just submitted a patch for the ATL1E driver: https://lists.ubuntu.com/archives/kernel-team/2008-November/003603.html
<rtg> speakman: shit, wish I'd known of this patch last night. given the age of the patch I'm surprised it isn't one of the stable updates.
<speakman> is it not even in linux-2.6 git?
<speakman> Is there a new ubuntu kernel on its way for Intrepid already?
<matiass> hi,,,can you help me with my bug and motherboarD?
<matiass> here is a thread you can see the image of it
<matiass> http://ubuntuforums.org/showthread.php?t=963662
<rtg> speakman: Intrepid 2.6.27-10.20 is on the way
<speakman> oooh :(
<speakman> is it really not possible to merge this patch before release?
<rtg> Intrepid is already released. It'll show up in an update. Create a Launchpad bug and attach the path.
<rtg> s/path/patch/
<speakman> which lp project?
<rtg> speakman: Ubuntu project, linux package
<speakman> https://bugs.launchpad.net/~ubuntu-kernel-team
<apw> BenC, how is our jaunty kernel is your rebase up yet?
<BenC> apw: rebase is done, doing configs now
<apw> BenC, so wait a bit and it'll be there
<amitk> BenC: I'm doing the armel configs too. Just be done soon
<BenC> amitk: ok
<apw> rtg, our intrepid tree feels like it is missing the last couple of tags?
<speakman> Bugreport + patch submitted: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/300698
<rtg> apw: could be. gimme  a bit to wrap up LBM/LRM packaging.
<BenC> rtg: I was wondering if you had looked into the new userspace regulatory stuff that the 2.6.28 supports?
<rtg> apw: try now.
<speakman> rtg: Can you promote it to next kernel release to 8.10 ?
<rtg> BenC: I've beem postponing that knowledge until UDS. Luis will be there for the week.
<rtg> speakman: I know why this one looks familiar. I read it on LKML a few days ago.
<speakman> rtg: okay, it might already be in linus' git?
<BenC> rtg: ok, I've kept the built-in compatability enabled, so it shouldn't be required yet
<speakman> rtg: this thread: http://lkml.org/lkml/2008/11/11/165
<rtg> speakman: commit 7ee0fddfe05f105d3346aa8774695e7130697836
<rtg> it'll show up with 2.6.27.8 stable
<speakman> oh, that's great news :)
<rtg> BenC: right, thats the way to go until I get smarter about it.
<speakman> any idea when .8 will be release in public?
<rtg> speakman: since I just uploaded last night, it'll likely be at least 2 weeks
<speakman> rtg: can I download it somewhere right now?
<rtg> speakman: https://edge.launchpad.net/ubuntu/+source/linux
<matiass> someone can have a look at my BUG  i put a photo of it in a thread  http://ubuntuforums.org/showthread.php?t=963662
<matiass> thank you very very much,,,, i don;t want to wait maybe until april!!
<speakman> this might not be a kernel issue, but how do I make Intrepid prefer my patched version of 2.6.27-7-generic instead of the intrepid version, and still reuse all restricted-* stuff plus upgrades when the new version arrives?
<rtg> speakman: if you are building your own kernel, then edit debian/changelog to increment the minor version, e.g. 7.16 --> 7.17
<speakman> (if I do apt-get upgrade it will reinstall the intrepid version)
<speakman> rtg: oh, great thanks!
<apw> rtg perhaps 7.16 -> 7.17~speakman
<rtg> apw: 7.17 is safe in this instance since we'll never produce that version number
<apw> ahh fair enough
<rtg> though the updates kernel is gonna clobber it almost immediately, being -9.19
<speakman> okay, which one to prefer? will it still overwrite with new kernel even if I choose ~speakman suffix?
<rtg> speakman: yep - perhaps you should wait until the -updates kernel is propagated, download it and add your patch.
<speakman> okay, it is not possible to withdraw that kernel and attach this patch..?
<rtg> ain't gonna happen
<speakman> okay, just asking..
<speakman> i think I'll just reapply the patch when that kernel is released. I need the .local domain support in my work. :)
<BenC> amitk: I've pushed my configs
<amitk> BenC: ok.. still working on mine.
<apw> matiass, can you tell me more about what CPU this thing has in it?
<BenC> amitk: you have more, so take your time :)
<apw> matiass, if you have an older distro on it, then can you can /proc/cpuinfo and paste it into the launchpad bug
<speakman> reboot time. Great thanks to you all !
<rtg> apw: according to the MB model, its gotta be core-duo or higher
<matiass> someopne ca help mme??with this bug   http://ubuntuforums.org/showthread.php?t=963662
<matiass> quad core INTEL Q6600
<matiass> i know someone with the same problem ...is the motherboard we think
<rtg> matiass: its not likely to get solved here. have you talked to Intel?
<matiass> mmm
<matiass> i talked to them today. "we dont support linux"
<apw> matiass, we really need to get all the information you have in the forum thread into the launchpad bug
<rtg> matiass: have you booted _any_ linux kernel on it?
<matiass> but listen , with Debian lenny is working, kernel 2.6.26 i think
<matiass> okey how can i do this ?????????
<apw> if lenny works the it would be good to get the /proc/cpuinfo off there pasted into the bug as well
<matiass> tell me what to do i willput it in the launchpad
<apw> well there is an image in there that you need to register to get, you could pull that over to launchpad
<apw> and it would help to transcribe the text off the screen to save people looking at the image
<matiass> okey, can i upload image to launchpad?
<apw> i think its call an attachment or something
<matiass> okey..
<matiass> but /proc/cpuinfo  is needed?    q6600 is not enoguh?
<apw> yes that has a large amount of information about how the cpu has been detected
<matiass> okey
<matiass> i;m not in the place with the PC ...so on sunday i will be
<BenC> smb_tp, rtg: That atl1e patch in kernel-team@ looks like a good SRU candidate
<matiass> how can  i contact you? or you enter bugzilla also?
<rtg> BenC: yes - he's already created an LP report. I've nominated. its gonna show up in stable .8
<matiass> you always here in this channel ?  i really sorry i don;t understand a lot about linux...just starting ..bought hardware i thought is compatible and ...have lot of problem
<BenC> amitk: I'm rebasing on 2.6.28-rc6 since current git wont even compile because of some header weirdness
<BenC> amitk: so no commits yet, I'll be force pushing in a minute
<apw> putting the maximum inforamtion you can in launch pad means any of the kernel developers can look over it
<BenC> rtg: current rebase includes two reverts of upstream patches from intrepid...I'll point them out in the summary I send to kernel-team@ so I can find out if they can be removed
<matiass> thanks , but you think it can be solution maybe that i will compile my own new kernel?
<amitk> BenC: ok... 
<rtg> BenC: not surprising.
<apw> matiass, not sure at this point.  if you know how to build kernels then building a 2.6.27 kernel on your working lenny system would help, if that fails we know its 2.6.27 related
<matiass> i will try...i don;t know how :)
<matiass> also i mean the error is when you put the disc and just boot 
<BenC> ugh
<BenC> why does task_struct have to scm_work_list members :/
<BenC> *two
<BenC> I wonder if that's a bad merge
<matiass> also i had 8.04 with old kernel  and did upgrade via internet and then when it upgraded the kernel also you have the BUG after the GRUB 
<apw> matiass, so you had a working hardy system and it broke when upgraded
<apw> could you still boot the 2.6.24 kernel from hardy on the intrepid updated userspace
<matiass> yes. i did it  but
<matiass> listen, 
<matiass> i have a new very good graphic card from nvidia and you CAN't install new drivers if you don;t have the newest kernel!
<matiass> is like all the world against :)
<apw> well the world is against closed source drivers, they make life hard for themselves and their users
<rtg> BenC: i think its a bad merge, but OMG thats getting to be an ugly structure.
<apw> the point of trying these things it to find out what about the machine is broken so youwill be able to run the newer kernel
<matiass> understand.
<matiass> but you mean the hardware has a problem? i think is incompatibilty
<matiass> ?
<matiass> apw: what do you mean?
<apw> no i mean there is something about your hardware which triggers this issue in the new kernel
<apw> to find the bug, we need to find the difference that triggers the failure
<amitk> BenC: do you expect to upload today?
<apw> so  finding out a 2.6.27 virgin tree boots ok tells us its not in any of those commits
<apw> its likely in our local modifications, a much smaller set
<apw> but the key is it splits the search space in two and eliminates one of them
<amitk> BenC: build testing all the arm configs on my machine is going to take 6+ hrs. Should I push them out first?
<amitk> BenC: configs pushed, but not yet tested. Builds ongoing
<rtg> lamont: do you know if the special compiler restrictions still apply to hppa for for the Intrepid ports build, e.g., gcc-4.1-hppa64 ?
<lamont> rtg: that'd be a doko question
<rtg> ok, perhaps a better question is, has anyone run a .27 kernel with hppa?
<lamont> it's gonna definitely need gcc-${mumble}-hppa64
<rtg> whats kyle doing with it these days?
<doko> rtg: which restrictions? it would be nice to use the 4.3 compiler if possible
<rtg> doko: well, thats kind of what I'm asking. does the hppa .27 kernel build work with 4.3 ?
<doko> rtg: I didn't check
<rtg> doko:  ok, I'll work with lamont to get the right tool set.
<lamont> rtg: see also other window
<BenC> amitk: is it just the configs or do you have all the arch setup in there too?
<Kano> hi rtg , could you fix the 2.6.28 git? there are double fixes included
<Kano> for example acbdf3b2fb51c8d197b1cca5dd4d0f54add69d6d
<rtg> Kano: its still a work in progress. BenC and amitk are in the middle of it right now.
<Kano> btw. i like that you now use the complete 2.6.27.x fixes not only parts
<rtg> yeah - it didn't make sense to me to ignore all those good bug fixes.
<Kano> well for me too ;)
<Kano> i disliked the selected fixes
<NCommander> doko, I'm working at removing 4.1 from the ports kernel (I haven't done HPPA, but PowerPC and SPARC are liberated :-))
<cking> rtg: did you know of any Wifi issues with the Ralink RT2571WF PCI-E Mini (driver rt73usb) - I have somebody report it cannot connect reliably with WPA
<Kano> cking: well for rt there are often 2 usb drivers available
<rtg> cking: is it the OEM driver?
<Kano> also pci-e is never rt73usb
<Kano> next, the official driver for ralink needs a change if you want to use wpa supplicant
<mjg59> cking: There's a clue in the name
<mjg59> Hm. I guess you /could/ put a USB wifi card on a mini PCI-E slot.
<mjg59> Would seem a little strange, but still.
<cking> whoaa.. hold on.. 
<cking> rtg: which one is the OEM version
<cking> ..this is hardy by the way
<rtg> cking: oh
<rtg> I can't remember if we packaged the OEM driver.
<cking> Kano: I would agree with that initial statement, but lsmod tells me different.. hence I am mystified
<rtg> smb_tp worked on the rt25xx backlport
<Kano> it works better with ndiswrapper anyway
<cking> rtg: OK - thanks
<Kano> just not with draft-n
<abogani> smb_tp: I did it.
<abogani> smb_tp: Do you want a "request pull" through ml?
<Kano> rtg: do you use all bugfixes for 2.6.24 now too?
<rtg> Kano: smb_tp is working on it. I have not looked at the git repo lately
<smb_tp> rtg, That is rt2860
<Zhenech> Is there any reason, linux-libc-dev does not ship video/uvesafb.h?
<haydn> I know this might be off topic, but could some quickly help me? I need know how to install kernel 2.6.24 in an Ibex install. I'm trapped by the busybox intramfs timeout error! Please no one else can seem to help.
<amitk> BenC: all the arch setup is in there too
#ubuntu-kernel 2008-11-22
<otwin> hi - as many people report ipw2200 seems to be buggy (in intrepid at least). does anybody know if this is an ubuntu or an upstream kernel bug? or is there a fix I missed?
<TomJaeger> I just compiled the jaunty kernel.  Are you guys interested in the changes that I needed to make to get it to compile (I didn't bother with the ubuntu/ modules, though)?
<frinknet> can someone point me in the right direction for compiling lpia with rt patch?
<frinknet> It's just the patching and arch switch that is tripping me out
#ubuntu-kernel 2008-11-23
<erika14212> hi all
<shay> zul: u around?
<shay> I think I found a bug on Xen but not sure how to get further information or how to report it, talk to me when u're available
<frinknet> Anyone know about patching an LPIA kernel for RT preempt?
<frinknet> my understanding is it should be straaight forward but not really done anything with LPIA before so...
#ubuntu-kernel 2009-11-16
<hagabaka> to set the framebuffer display mode, do I have to edit menu.lst? is it possible to let it apply to all kernel versions?
<Keybuk> apw: https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/Lucid/Kernel#preview
<Keybuk> apw: pgraner said that you own the Kernel Team bits (if so, change them to your name)
<Keybuk> and subscribe and stuff :p
<elopss> why/where/how is the kernel inserting mount options that mount(2) isnt sending it?   (according to both behaviour, and /proc/mounts)
<elopss> well /proc/mounts shows mount options that were not provided by mount().  what is the cause of this?
<elopss> relatime is the option that's showing up on all my mounts that i want to get rid of
<elopss> and.....it didnt do this until i upgraded to 9.10
<elopss> but i'm also using kernel .32rc  which might have something to do with it
<elopss> any ideas? suggestions/advice plss?
<elopss> the he strictatime  works for some mount commands, but mount.nfs doesnt pass it to mount()   ..  i could write a call to do it, but why the relatime is in there in the first place boggles me.
<elopss> hmmm?
#ubuntu-kernel 2009-11-17
<elopss> I really need help guys
<elopss> :(
<elopss> norelatime doesnt get passed to the kernel, it just cancels out any relatime in the mount command
<elopss> so all new linux kernels are going to do this?
<elopss> i just wrote my own mounter to pass strictatime, that works.. (mount.nfs wont pass it to the kernel)
<Wellark_> Hi! where can I find debug package for 2.6.31-14? http://ddebs.ubuntu.com/pool/main/l/linux/ has packages for -15 but no -14 :/
<Wellark_> ah, ok. -15 is in karmic-proposed.. I just grab it from there
<Keybuk> apw: "There's now ext4 support for GRUB, and Kernel Mode Setting (KMS) is enabled by default on systems with NVIDIA, ATI and Intel video cards for a faster and smoother graphical boot. "
<Keybuk> from the Fedora 12 release notes
<Keybuk> did they get over their nouveau objection?
<mjg59> Keybuk: We've never had one?
<mjg59> Nouveau's been the default driver since it got stable for 2D
<Keybuk> mjg59: I've heard claim from RH people that there's some number <100 of bytes of code in the driver that's maybe config data, maybe executable code, etc. 
<Keybuk> and that has been considered an issue
<mjg59> Keybuk: You'd need to ask your lawyers. Ours apparently had no problem.
<mjg59> (I infer - I haven't actually asked them)
<mjg59> The reason we didn't ship it before was purely that it didn't work terribly well...
<Keybuk> mjg59: like I say, this is something I heard from RH people
<Keybuk> and then from andy
<mjg59> Keybuk: It's something that was a vague concern, but as far as I know it was sorted
<Keybuk> good to know
<Keybuk> I came up with a name for F13 ;)
<Keybuk> Constantine ... is a bad film starring Keanu Reeves ... :p
<mjg59> (Some time ago - we had nouveau by default in F11)
<mjg59> Ha
<Keybuk> so clearly Fedroa 13 (Matrix)
<mjg59> I shudder to think of what would happen to the artwork
<mjg59> Thankfully, I think Matrix would fall at the trademark barrier
<Keybuk> it'd be funny though ;)
<penguin42> I've looked at a bunch of the packaged kernel rebuild instructions and I don't see where any of them lets me give a modified name to the packages - is there a simple way of doing that? (Ditto is there a simple place to drop a patch file in or is it just a matter of patching the linux-2.6.31 dir after it's been unpacked by an apt-get source ?
<Keybuk> cking: around?
<Keybuk> if you'd like to join in the btrfs discussion, we'd appreciate your presence
<cking> Keybuk, attending - having some audio issues - hold on a sec
<wamty> is there a way to *slow down* the linux boot process? i tried already the boot parameters boot_debug=3 and boot_delay=2000, but did not see that anything has changed
<penguin42> I could swear there was an option for adding a delay after each printk
<wamty> my problem is that my linux-computer turns itself off during the early boot process in 3 out of 4 tries.
<JanC> wamty: you can always look at the logs?
<tormod> wamty, netconsole might help you
<wamty> JanC: i checked dmesg, /var/log/dmseg and /var/log/messages: nothing found
<penguin42> wamty: How far does it get before it dies?
<ghostcube> apw: my webcam bug is so strange the cam worked now for 3 days and today again nothing
<ghostcube> :)
<TheMuso> apw: FYI ports-meta uploaded for lucid.
<Keybuk> apw: any particular reason the schedule() function is missing from 2.6.32-4 ? :)
<apw> Keybuk, its not ...
<apw> i had one out of tree dirver beahave that way
<Keybuk> apw: wl_linux.c:702: error: implicit declaration of function 'schedule'
<apw> some header has stopped beinging included in some other header
<apw> yep thats the one
<apw> there is meant to be a fix for that
<apw> NCommander, ^^ didn't you have the fix for that
<apw> did it get uploaded?
<Keybuk> apw: I can't find any header that declares that
<apw> its definatly not gone away, we had to include linux/sched.h or something similar
<apw> i can check more detailedly later
<Keybuk> oh, right
<Keybuk> sorry
<Keybuk> being a tit
<NCommander> apw, Keybuk the patch sat on Launchpad and never got merged
<apw> well crap ... so ok ... we need to get that merged and uploaded to fix the mini 10v boot performance bit
<NCommander> apw, Keybuk, https://bugs.edge.launchpad.net/broadcom-sta/+bug/458757
<apw> NCommander, you had a PPA build or somesuch which i must have on my machine as i can install 
<ubot3> Malone bug 458757 in bcmwl "[patch] bcmwl fails to build with dkms on lucid 2.6.32-HEAD kernels" [High,Confirmed] 
<NCommander> apw, I can throw it in a PPA if you need it ASAP
<apw> Keybuk, how urgent is it for you ...
<Keybuk> apw: I can edit C code ;)
<apw> its actually damn hard to edit the dkms poop to make it work
 * NCommander notes it took a few hours for me and apw to figure it out
<Keybuk> really?
<Keybuk> I just edited the unpacked bcmwl-kernel-source package and did dpkg-reconfigure on it
<NCommander> Keybuk, it wasn't obviously on why went bust in the first place, then it took awhile to figure how to get DKMS to patch the source on build.
<apw> there was something screwey in getting it to not undo the exposed source, i forget what
<apw> if you have it working all is good
<NCommander> Keybuk, could you nominate that bug for Lucid for me so the release team can see it?
<Keybuk> huh?
<Keybuk> lucid is months away
<Keybuk> Just Fix It (tm)
<apw> Keybuk, are you sorted for the 'now' ?  if so we can ignore it till next week
<Keybuk> apw: yeah, but will need it fixed to do daily bootcharts and stuff
<apw> yep.  just if you are good then we can get that one on the radar and get someone to upload it, i think it has the fix en-toto already just literally needs upload
<apw> i am sure i have it so patched on my machine and can confirm its good
<apw> NCommander, anythign stopping us just throwing it in the archive?  its lucid after all?
<NCommander> apw, I don't have access to the bazaar branch to commit the change
<apw> NCommander, ok how do i find out who does, whats the master branch name?
<NCommander> apw, https://edge.launchpad.net/~albertomilone - this is the name on the branch
<apw> perfect thanks
<NCommander> o
#ubuntu-kernel 2009-11-18
<_ruben> when having built a kernel using debian/rules binary-flavour, is there an "easy" way to get .dsc/.changes/etc files as well? so i can dput the files to my mirror
<joe5ie> hey
<joe5ie> does anyone know what was the last kernel that didnt use credentials?
<doctormo> With the talk yesterday about KVM and testing, does the KVM support USB? will we be able to use it for testing UDB device support?
<dandel> i need to change the suspend/resume scripts to be able to get back on the network before the system tries to read/write to the file system ><:
<dandel> does the kernel get tested against the usage of using the wubi stuff very often on suspend/resume?
#ubuntu-kernel 2009-11-19
<mase_wk> hi guys, i need to add a module to the initramfs but i would like to make it so that whenever a new kernel is installed , when it runs update-initramfs it also adds in this module. Which file do i need to alter in order for this to occur ?
<mase_wk> does it use /etc/modules.conf? 
<dtchen_> /etc/initramfs-tools/modules
<mase_wk> thank you
<_ruben> is it known/expected/whatever that hardy doesnt like newer kernels .. like 2.6.28 mainline builds, or backports from jaunty/karmic .. lvm fails to come up at boot .. it detects the disks, and then drops to shell
<asabil> hi all
<manjo_> dinh, u still around?
<amitk> manjo_: he left
#ubuntu-kernel 2009-11-20
<mozmck> I made a custom kernel based on the ubuntu sources.  In my /lib/modules/2.6.31-15-generic/ there is an initrd directory with vesafb.ko in it, but in my custom kernel's modules directory there is no initrd directory.  Why is this?  What do I need to do to get that?  I built my package with make-kpkg.
<mozmck> anyone here?
<dandel> mozmck, yes.
<dandel> I'm doing a little bit of extra testing to see if bug 484943 is only valid on a wubi based install. (currently installing on a native hd partition)
<ubot3> Malone bug 484943 in linux "resume crashes with ext3 error with wubi based install" [Undecided,New] https://launchpad.net/bugs/484943
<_ruben> could anyone enlighten me on how to add a custom built kernel (ubuntu git method) to our custom package mirror (which uses mini-dinstall)?
<_ruben> the debian/rules binary-<flavour> only creates .deb files, no .dsc and/or .changes
<AceLan> _ruben: debuild -S -sa -i -I
<_ruben> AceLan: i doubt that that'd make my binary .debs "dput-able" ?
<AceLan> _ruben: yes, it will produce necessary files dput needs
<AceLan> including .dsc and .changes
<_ruben> the changes files only references the source, not the binaries i had already built
<cankoy_> Does the swap part. have to be *at least* the same size as RAM for hibernation to work?
<cankoy_> I vaguely remember that Ubuntu kernel does some compression, hence swap d
<cankoy_> ...could be less
<hyperair> depends.
<hyperair> there are three approaches for hibernation.
<hyperair> swsusp, uswsusp, and tuxonice
<hyperair> ubuntu uses swsusp by default.
<hyperair> uswsusp compresses the image, and so does tuxonice
<hyperair> but imo tuxonice does it best
<hyperair> swsusp is extremely slow, and uswsusp is slightly less slow, but that's a different matter.
<hyperair> cankoy_: ^
<cankoy_> hyperair: so the default scheme does not compress?
<hyperair> it does not
<cankoy_> hm, ok
<hyperair> it also does not save/restore the file cache upon resuming
<hyperair> and also only restores half of the memory after resuming, resulting in a whole load of page faults upon resuming. so even if your resume didn't take that long, it'll hang and page fault for another 3-4 minutes before you can use it again
<hyperair> iow, for now, hibernation sucks and you're better off not using it >_>
<cankoy_> ok, thanks for insight, much appreciated ;-)
<hyperair> np
<Kano> hi, how about .32-rc8?
<JohnT> Hi! My problem: I have an app with 4 threads wich should run at 100% on each core. I have a 4 core processor. The behavior is not obvious:  2 threads runs on their own core at 100%, while the other 2 shares one single core, leaving the other core idle. Why?
<mozmck> you don't have isolcpus set in the boot line do you?  (disclaimer - I know almost nothing!)
<JohnT> no, just googled isolcpus: didn't even know it :)
<nick_schembri> hello, Can someone comment on aufs  in 10.4 lucid
<nick_schembri> cj you work on the cdrom build?
<mozmck> how do I get my custom kernel's initrd to load the vesafb module by default?  the kernel is built with the ubuntu sources and config from 2.6.31-15-generic.  I found something on adding it to /etc/initramfs-tools/modules/  but will that work for installing the debs on another computer?
<cj> nick_schembri: nope.  that was kinda' random...
<cankoy> mozmck: kernel .deb includes the initrd. But I'm not sure just adding vesafb to initramfs-tools/modules is enough to make it work.
<nick_schembri> cj yes that is a little random.  I had your nic in my head.  I know that the person who is working on the cdrom build will know if aufs is going to be removed from lucid 10.4.
<mozmck> cankoy:  I installed on a computer with intel onboard gpu and it wouldn't boot.  So I booted with ubuntu kernel and added vesafb and fbcon to initramfs-tools/modules, ran update-initramfs -c -k and now it boots fine.
<mozmck> my custom kernel boots now that is.
<mozmck> so how do I make it use those modules in the initrd created when I build debs?  (I used make-kpkg)
<cankoy> mozmck: IIRC, you cannot use vesafb on intel gpu because it conflicts with KMS (and inteldrmfb)
<dandel> i tested bug 484943 on native ext3 suspend, and it crashed just like what it did with a wubi based install.
<ubot3> Malone bug 484943 in linux "resume crashes with ext3 error with wubi based install" [Undecided,New] https://launchpad.net/bugs/484943
<mozmck> cankoy: I had to use nomodeset on this one to get it to boot reliably and to find the correct resolution.
<mozmck> in x that is. with the standard kernel it worked but mine had to have the vesafb module - I guess to fall back on.
<mozmck> the Ubuntu kernel has an initrd directory under /lib/modules/2.6.31-15-generic with the vesafb mod copied in.
<cj> nick_schembri: seen jigdo?
<nick_schembri> cj: i sorry what?
<nick_schembri> cj: googling
<cj> nick_schembri: oh, you're not trying to build a cdrom, eh?
<nick_schembri> cj: look cool. 
<nick_schembri> no I run ubunt on a flash based system with aufs protecting the flash.
<nick_schembri> https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash
<nick_schembri> I need to update my comments on the status of aufs in 10.4+ 
<cj> nick_schembri: nice.  might be useful for pyramid...
<cj> http://code.google.com/p/pyramidlinux/
<cj> it's based on a really old ubuntu, though, IIRC
<nick_schembri> cj: i'll look at the website.  
<nick_schembri> cj: what i need to do is find out how long aufs will be in the kernel and build a package or ppa for the avg user.
<nick_schembri> root aufs should be very simple to install and remove.
<cj> nick_schembri: I dunno.  I've never used aufs
<nick_schembri> It's worked very well for me. I've never had any issues.
<cj> you'll probably need to make-kpkg your own kernel with your own .config, though, I guess
<nick_schembri> at this point the aufs modules are installed. I just need to install the userland tools and run the updates for initrd. 
<nick_schembri> I was hoping that linus would include aufs in the mainline kernel, but he hates the code for some reason. I'm not sure I want to maintane the patches if ubuntu pulls aufs out.
<nick_schembri> cj: pyramidlinux looks a little old. I started with voyage linux out of voyage.hk. It's a debian based system that I pulled some of the code from.
<cj> yeah, it's getting pretty ancient ;)
<cj> but it's small
<cj> I'd like to see embdebian get some love
<nick_schembri> cj thanks for talking with me. I need pgraner  to get back with the official answer to aufs's status in 10.4
<cj> indeed.  sorry I don't know more ;)
<nick_schembri> cj: embdebian would be great. I've looked a little at using debootstrap to build a sub 50M distro on ubuntu.  I just have not had the time and flash memory is so cheep now I'm not sure it's worth the time. I can live with a little bloat.
<nick_schembri> cj: np 
<cj> nick_schembri: my problem is that I've already invested in the radio hardware I intend to use, and it's only got 64
<cj> M of flash
<nick_schembri> cj you should look at voyage linux it's easy to strip down. At one point it was less then 50M. 
<nick_schembri> Voyage Linux is Debian derived distribution that is best run on a x86 embedded platforms such as PC Engines ALIX/WRAP and Soekris 45xx/48xx board
<nick_schembri> cj it looks like voyage is moving to tmpfs and it needs 128M of flash. :(
<cj> yeah, mine's a Soekris 45xx
<dandel> any good information on adding automatic scan entries to grub2 (like adding text mode)
<cj> dandel: sure, :)
<cj> oh, grub2, not grub1
<cj> nm
 * cj isn't familiar with that beast yet
<dandel> hmm... i found a little bit, but i really just don't want the updates to grub to knock out what i do ><;
<dandel> cj, you running ubuntu 9.10 with ext3 by any chance?
<cj> I am
<dandel> does your system crash when you suspend? (ext3 errors.)
<cj> no
<cj> suspend is working pretty well for me aside from sony hardware issues
<dandel> strange, me and a buddy with 2 different laptops have an issue with suspend crashing.
<cj> (unplugging ac sometimes kills power)
<cj> dandel: did you upgrade or install karmic fresh?
 * cj upgraded
<dandel> both
<dandel> upgrade on wubi, and fresh install to native partition both show the same problem
<cj> hurm... did you send the kernel bug report?
<dandel> yes
<cj> anyone respond to it yet?
<cj> or mark it as a dup of something else?
<dandel> bug 484943
<ubot3> Malone bug 484943 in linux "resume crashes with ext3 error with wubi based install" [Undecided,New] https://launchpad.net/bugs/484943
<cj> wubi?
<dandel> i need to update it a bit tho.
<dandel> wubi = windows installer for ubuntu
<cj> ah
<cj> yeah, that's not me...
<dandel> my fresh install is to an actual hd partition (extended partition tho)
<cj> lvm++
<cj> is your friend's to an extended partition?
<cj> if so, it might have something to do with extended + ext3.  that's something I've never used before.
<dandel> no, wubi based.
<cj> maybe grub doesn't know how to access sda[5..n] ?
<dandel> no.
<cj> dandel: is wubi an ext3 image on a ntfs partition or something?
<dandel> on ntfs.
<dandel> the laptop boots in just fine.
<dandel> but once i do a suspend, it fails horribly.
<dandel> see log on the bug
<dandel> cj, i figured out part of what i need, but it doesn't exactly transfer nicely to when i add dev kernels on boot params ><;
<Keybuk> cking: how the hell do you update the BIOS of a Dell Mini 10v?
<cking> Keybuk, dunno - not done it on that machine. I usually use a DOS disk with primitive BIOS re-flashing tools
<Keybuk> yeah, I fear the freedos
<cking> Keybuk, as supermario
<cking> s/as/ask/
<cking> Keybuk, maybe our OEM team friends like smagoun can help you
<mjg59> Would be a lot easier if the mini actually looked anything like any other dell machine
<mjg59> But they seem to lack the dcdbas interface
#ubuntu-kernel 2009-11-21
<EruditeHermit> hello
<EruditeHermit> if I do a kernel compile and it gets to 99% and then errors out
<EruditeHermit> can I fix the problem and then force it to continue?
<EruditeHermit> how do I make it continue from where it was
<elops> I had an "auto poweroff" boot problem
<elops> I was advised to use netconsole and initcall_debug to get a better, more precise idea of where it was going astray.
<elops> ok, i could not get netconsole running over ethernet, but using a null-modem cable worked
<elops> now i have a detailed boot-log (kernel parameters: initcall_debug loglevel=7 apic=debug)
<elops> i have boot-logs for 9 failed boots
<elops> i have boot-logs for 9 failed boots
<elops> in 7 of these 9 logs the last line is:
<elops> >> calling  mod_init+0x0/0x1f0 [intel_rng]
<elops> then the comp powers down automatically
<elops> in case the boot continues normally, the next lines are:
<elops>  >> intel_rng: FWH not detected
<elops> >> initcall mod_init+0x0/0x1f0 [intel_rng] returned -19 after 86 msecs
<elops> Any ideas/suggestions/advice pls?
<eloops> sorry, did i miss a response?
<Appiah> nope
<eloops> :/
<eloops> ok
<mr-dedup> would appreciate a little help, I hit a wall, I downloaded the source for 2.6.31.6 - I was able to make menuconfig and make all - make modules_install - make install,   I notice in my /boot path doesnt contain a new .img file - therefore I do not know how to update my menu.lst -- i am novice at kernel builds can anyone tell me where I went wrong
<_ruben> https://help.ubuntu.com/community/Kernel/Compile
<Mikeh> Evening
<Mikeh> I'm looking for a deb for 2.6.32 to test something very quickly 
<Mikeh> Is there anything that works well enough?
<dtchen> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc8/
#ubuntu-kernel 2009-11-22
<dtchen> http://en.opensuse.org/Kernel_Git is interesting
<Duck-> Hi, I'm 12 and what is this?
<adnc__> i've a kernel process called ksuspend_usbd, i suppose this process is the reason why my usb audio gets reconnected all the time, can someone please tell me how to switch this process of?
#ubuntu-kernel 2010-11-22
<sleblanc> Hello, is there a tool to automatically generate a config file with the best value to its corresponding hardware?
<abogani> It depends from what you mean for "best value".
 * abogani waves all
<apw> sleblanc, i think there might be something to minimise it, but not sure i know what it is called
<apw> abogani, morning
<sleblanc> I want to get a smallest kernel, but with the need to work properly.
<sleblanc> It is to realize a network appliance with 2 GB of disk space.
<abogani> apw: Good morning!
<abogani> sleblanc: Perhaps "make localmodconfig" could help you.
<sleblanc> Thanks,
<kraut> moin
<Arnold> Hi all, I have a question hope you can help
<Arnold> I'm applying a kernel patch that adds 3 system calls on kernel 2.6.32 (Ubuntu 10.04)
<Arnold> Now I'm noticing that unistd.h and syscall_table_32.S doesn't match up
<Arnold> Also there doesn't seem to be a syscall_table_64.S file...
<Arnold> Does someone know why there is a discrapancy in the system call numbers from the header file and the syscall table?
<apw> Arnold, what version was the patch originally for
<apw> Arnold, as 64bit doesn't seem to do its syscall linkage in the same way at all
<apw> http://people.canonical.com/~apw/master-natty/
<apw> http://people.canonical.com/~apw/ronx-revert-natty/
<apw> http://people.canonical.com/~apw/master-natty/
<apw> tgardner, how did urbana tae the master-natty update
<tgardner> apw, yep, though the kernel you sent still had an -rc2 in the signature. I've rebuild from master and am just booting that.
<tgardner> apw, looks good now: Ubuntu 2.6.37-6.16-server 2.6.37-rc3
<apw> tgardner, huh ? i have it booted here with -rc3
<tgardner> apw, maybe I grabbed the wrong one. no matter.
<apw> tgardner, good enough i'll upload it
<tgardner> apw, wfm
<Arnold> apw: Sorry I was in a meeting
<Arnold> The patch was for 2.6.24, but I've completely rewritten it for 2.6.32
<apw> ok well then the syscall infrastructure has changed a lot between the two
<Arnold> i've noticed ;)
<Arnold> Can you explain the numbering in include/asm-generic/unistd.h to me?
<apw> well the numberiing its using is in arch/x86/include/unistd_64.h
<Arnold> ok, I'm building a 32bit kernel, so I guess it's unistd_32.h
<Arnold> the asm-generic is not used.. k thnx, that explains :)
<apw> Arnold, well no i think 32bit is different again
<Arnold> i do have a arch/x86/include/asm/unistd_32.h
<apw> there _is_ a suscall_table_32.S
<apw> which i think has to be kept in sync
<apw> whereas 64 bit is fixed so they cannot be out of sync
<Arnold> ok
<apw> so 32 bit is harder as you have to do both, 64 just the one
<Arnold> in 2.6.24 they also needed to be in sync. I was unaware of how the 64bit version was now working and that the files ware renamed
<Arnold> thanks apw ! ++
<tgardner> apw, Uploading linux-lts-backport-natty_2.6.37-6.16~lucid1
<apw> tgardner, is there anything in there ?
<tgardner> apw, do you mean is there anything currently in the kernel-ppa ?
<apw> tgardner, DOH i missread it, ignore me, and thanks
<tgardner> apw, pushed to the repo as well
<smoser> jjohansen, are you working today ?
<jjohansen> smoser: yep
<smoser> so you and i have different results with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/669496
<ubot2> Launchpad bug 669496 in linux (Ubuntu) "natty fails ec2 boot on i386 or t1.micro (affects: 1) (heat: 10)" [Critical,Confirmed]
<smoser> which is "interesting", "fun" or whatever you want to call it :)
<jjohansen> smoser: yeah, though I am not sure it is that different
<smoser> at very least, i think all of you, i and smb have booted the kernel successfully on m1.large, and my initial attached logs show filesystem or block device failing after user space starts.
<jjohansen> I launched a lot of instances and most didn't produce console output
<smoser> yeah, so thats the first thing to fight i guess.
<smoser> without console output, you're black magic skills have to come in.
<jjohansen> :(
<jjohansen> black magic == iterate
<jjohansen> but its not all bad we actually have a half decent starting point in maverick
<smoser> yeah. 
<apw> [plus some madman is changing natty under your feet all the time]
<smb> And unfortunately all the console output looks like pre kernel start 
<smoser> smb, well, yes, but jjohansen and i know better than to trust that.
<smoser> unfortunately, you can't
<smb> jjohansen, I thought I might try to see what old versions we have in the natty repo (ie 2.6.36) and try how that goes...
<smoser> smb, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588715
<ubot2> Launchpad bug 588715 in linux-meta-ec2 (Ubuntu) (and 1 other project) "instance had only post-shutdown console output (affects: 1) (heat: 22)" [Undecided,New]
<smoser> basically, i do not 100% trust the console collection in the hypervisor.
<jjohansen> smb: sure, I was going to troll through the commits to block front and back
<smb> smoser, No worries I am not really trusting anything there. Just was trying to say, that no output from the natty kernel in any cases
<smoser> smb, well, right... i'm just saying that I suspect that the kernel is getting loaded, properly writing plenty of things to hvc0 , crashing, and that crash causes hypervisor to not be able to display logs
<smb> The x sectors of 0 bytes initially were looking strange but that is the same in maverick i386 and that boots
<smoser> possibly its just a buffer that was lost or something, but one way or another, sometimes console logs aren't there, when you know that the kernel wrote something.
<smoser> jjohansen, smb i trust both of you, so i'll stop nagging :)
<smoser> smb, for the pv-on-hvm in natty, we think that is just kernel config options (s/think/hope/) 
<smoser> right ?
<smb> I agree that it would be too nice to really look at the machine it happens and to see whether one might pull a memory dump or so. Sadly thats out of qquestion.:)
<smb> smb, right
<smb> And we hope they are already turned on (at least it looks like that to me)
<smb> I believe jjohansen wanted to play a bit with those on Fri
<smoser> oh. i didn't realize they were turned on.
<smoser> in -virtual ?
<smoser> that would rock. i'm going to install a centos here and poke at getting hvm instances going
<smoser> i suspected i would have to recompile kernel, but not having to do that is nice
<smb> there at least. 
<jjohansen> smoser: yeah its just a kernel config option
<jjohansen> which makes it nice and easy
<jjohansen> I was just playing with whether to turn on for server/generic or only -virtual
<smb> If it is XEN_PVHVM then its even turned on for all confis
<jjohansen> I think just a module for all
<smoser> jjohansen, i'd think it makes sense to turn it on as modules in server, right ?
<smoser> or is there something negative from that.
<jjohansen> smoser: i don't see anything negative
<jjohansen> I just wanted to make sure
<smoser> size of ramdisk ?
<jjohansen> smoser: well turning it on is different than sticking it in the ramdisk
<jjohansen> smoser: sticking it the ramdisk is another issue
<smoser> well, yes, but i was under the impression that we touched the mkinitramdisk stuff very little
<jjohansen> I think we will have to do that for -server
<smoser> (ie, didn't change "MOST" and the like)
<oldkid> moin moin
<apw> hi
<smb> jjohansen, So ubuntu-2.6.36-2.8 fails to boot as well (which is less surprising when one finds out that this is based on 2.6.37-rc1)
<jjohansen> smb: o_O
<jjohansen> smb: yea I wasn't expecting it to boot but that version skew is worthy of a double take
<smb> jjohansen, I guess such things happen during development phase
<jjohansen> yeah
<smb> I am moving back to a real .36 and check again
<kees> apw: whoa. I wonder when module ro/nx broke so badly for your system? It was fine for me.
<kees> s/when/why
<apw> a good question, but i did a single patch revert to confirm it was that support which borked everything
<kees> what cpu do you have?
<apw> it broke on both my atoms, 32bit and 64bit
<apw> it also broke all of tgardner's installs, including a big-iron intel
<tgardner> kees, plus 2 of my machines
<tgardner> ah, what apw said
<apw> kees, it looked like it was trying to link modules and failing
<apw> i also had an ftrace failure
<apw> (for sky2)
<kees> and you pulled all 4 patches? now I wonder what I did wrong in my testing. I even built with page table debugging to verify it worked
<apw> 4 patches ?
<kees> yeah, my pull request show 3 from mat and 1 from me (config)
<apw> 849fdf5 UBUNTU: [Config] update config for CONFIG_DEBUG_SET_MODULE_RONX
<apw> 18f3991 x86: Add RO/NX protection for loadable kernel modules
<apw> 5c0fd04 x86: Add NX protection for kernel data
<apw> 18e43c9 x86: Fix improper large page preservation
<apw> those yes ?
<kees> yup. bizarre
<apw> ok the only one i had to dunk was the last one
<apw> well the last two i guess
<apw> as they are one change
<kees> right
<kees> hunh
<apw> the kernel data NX survived ok
<apw> kees, what base did you test it on
<kees> i tested in 2 VMs (32 and 64)
<apw> i mean which base version of the kernel
<kees> and they had all kinds of modules
<kees> the natty based on -rc2
<kees> plus the NFS fix
<kees> should still be on tangerine
<apw> hrm, cannot explain it at all
<kees> well, I didn't test on real hardware, but I know kvm handles NX correctly, so maybe it's something subtly wrong in kvm
<tgardner> kees, also just saw this in LKML, a resume regression: Bisect to commit 5bd5a45(x86: Add NX protection for kernel data).
<kees> like maybe it only handle nx in ring3
<kees> *handles
 * apw puts security patches on his shit list :)
<kees> heh
<kees> i'l follow up with the author and try to reproduce on bare metal. bleh.
<tgardner> apw, I think we should back the NX patches out for now until we can have a closer look. I just has an unexplained reset on my Urbana
<tgardner> which _could_ be something else...
<apw> tgardner, fair enough
<apw> tgardner, i can confirm that my amd64's do not resume with this kenel
<apw> oddly my i386s do
<tgardner> apw, Lin Ming just posted 'x86: Resume trampoline must be executable' which should fix it
<apw> tgardner, out it goes
<tgardner> apw, but, given this stuff will show up in .38 I think we should back it out for now until the dust settles.
<apw> yep, it'll be back but tested i hope
<tgardner> apw, I dropped a couple of patches in master-next. I think this is worthy of another upload.
<tgardner> this being the NX/RO revert
<apw> one of these days one of my uploads will finish building before it turns to shite
<apw> yep if its breaking suspend as well its going to generate much whining
<tgardner> it'll generate some whinging from me, for sure :)
<smb> jjohansen, Partial good news. What we are looking for happened somewhere between 2.6.36 and 2.6.37-rc1 (I know that is still quite broad)
<jjohansen> smb: yep, also check your mail some interesting info there
<smb> Saw it. Just need to grok what that exactly said about the micro instances.
<smb> But at least a 2.6.36 final rebase from our git tree still boots
<smb> jjohansen, oops, maybe I should have checked the dmesg first...
<smb> jjohansen, Seems I am on a ro filesystem after io errors happened. But I was able to ssh into it
<jjohansen> smb, smoser: we should split bug #669496 as t1.micro failing is a separate issue from t1.small and t1.medium failing
<ubot2> Launchpad bug 669496 in linux (Ubuntu) "natty fails ec2 boot on i386 or t1.micro (affects: 1) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/669496
 * tgardner lunches
<smoser> jjohansen, sure.
<jjohansen> I was surprised by smb reporting boot success of 2.6.36 because the initial bug was filed against a 2.6.36 kernel, but of course it was t1.micro failing
<smb> jjohansen, Well there was a small addition to that
<jjohansen> smb: oh what was the addition?
<smoser> m1.small and c1.medium
<smb> Which meant it booted but failed with the "io error"
<jjohansen> ah, I missed that
<smoser> jjohansen, well, the original failure showed both on m1.large and t1.micro
<smoser> but... who cares.
<smoser> going forward i think there are possibly 3 issues:
<smoser>  * amd64 sometimes doesn't boot
<jjohansen> hrmm, well t1.micro failing on x86_64 is definitely a different issue than i386
<smoser>  * i386 never boots
<smoser>  * t1.micro never boots
<jjohansen> right
<jjohansen> t1.micro has the additional issue of memory constraints
<smoser> so, i will defer to however you and smb want to handle the bugs there.
<smb> jjohansen, How did you read that? For micro one needs to configure it to use no huge memory layout? Cause it is assigned only around 500M
<smb> btw it was a t1.micro that booted into the ro-fs but was accessible through ssh
<jjohansen> smb: hrmm, I'm not sure.  I think we need to play with it a bit to clarify exactly what the constraints are
<jjohansen> smb: oh you had to go add that little detail didn't you
<jjohansen> :(
<jjohansen> alright we won't split the bug yet
<jjohansen> but I expect its 2 maybe 3 separate issues
<smb> Probably I wanted to retry a few more times before I add that info to the bug
<smb> err
<smb> Thats should be "probably <dot> I ..."
<ohsix> anyone have any idea on how receptive vendors are to reports for bios breakage; like do they ever fix things (in general, compaq/hp in particular)
<jjohansen> ohsix: sometimes, it doesn't hurt to try
<ohsix> this is what fwts has to say about my laptop: http://paste.ubuntu.com/535329/
<ohsix> does ubuntu have any swing with hp/compaq? or anyone i can directly send a report to that will really count, experience lends that mails sent to general support addresses are almost never acknowledged
<jjohansen> ohsix: I am sure canonical as some relationship with hp/compaq but I don't know the details and I don't have anything I can give you
<ohsix> alright, cool
<ohsix> would it be appropriate to report it to launchpad if its not strictly related? is there a place for that?
<ohsix> part of fixing some problems i have with my video is lending me to looking at lots of things that are also telling me things are broken :O
<h0nk> hi, I was wondering if kafs allowed to set permissions on the afs mount (using kafs)
<h0nk> right now only root can read some mounts below it
<ohsix> argh; can't even find an email to report stuff to
<ohsix> this is like the only stuff that really pisses me off :] (my sn is out of warranty on their little form so i can't see _any_ support addresses)
<ohsix> you could obfuscate it enough that nobody is ever able to contact you, that saves money so people do it :[
#ubuntu-kernel 2010-11-23
<smb> morning
<abogani> smb: Good morning!
<jjohansen> morning smb
<smb> jjohansen, heya
<smb> jjohansen, One could say good morning to you as well. :) Though good night usually is more appropriate. ;)
<jjohansen> :)
<smb> jjohansen, Any news from the sky?
<smb> (iow how's the clouds looking)
<jjohansen> I haven't looked up yet
<jjohansen> its just been one of those days
<smb> You mean there is too much rain coming down to see any cloulds. :)
<jjohansen> its snowing
<jjohansen> both literally and figuratively
<smb> I would prefer snow to the cold rain here
<jjohansen> yeah, snow is kind of nice, its been cold drizzle for the last week
<jjohansen> I don't expect the snow to last
<apw> shame, no skiing down the west hills then?
<jjohansen> hrmm, there just might be
<jjohansen> its almost enough to cover the grass here, so the west hills should have a fair bit more
<ogra> apw, could someone from the kernel team have  look at bug 511747 (specifically comments 43-45) it seems that the two lines would make additional HW work with maverick so i would think it makes sense to add that as SRU
<ubot2> Launchpad bug 511747 in xf86-input-evtouch (Ubuntu Lucid) (and 1 other project) "support for Acer 1420P (affects: 6) (heat: 37)" [Medium,Triaged] https://launchpad.net/bugs/511747
<ogra> (teh fix seems to be upstream too already)
<apw> BAH patchworks is in a HEAP
<ogra> thats why i'm pÃ¼atch pilot today ;)
<ogra> *patch
<ogra> seems that bug is falsely filed against evtouch and the patches are super trivial
<apw> ogra, well get it over on to linux at a minimum 
<ogra> apw, done
<apw> ogra, can't look at the stupid patch as patchworks is a heap
<apw> but if its upstream someone can send the patch to the kernel-team list to get it reviewed
<ogra> well, but you can look at the patches on the bug
 * ogra adds a comment about this
 * smb walks off
 * jjohansen waves good night
<ogra> do we have a wikipage that mentions how to get a patch into the ubuntu kernel ? 
 * ogra cant find anything 
 * ogra finds a million pages on how to compile your own kernel, but no instructions on how to supply a patch the proper way
<ogra> ah, that seems to mention a policy: https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide?action=show&redirect=KernelTeam/KernelGitGuide#Pushing changes to the main repo 
<apw> ogra, have you tried the FAQ ?
<apw> https://wiki.ubuntu.com/Kernel/FAQ#Can I get a patch included in the Ubuntu Kernel? / How can I submit a patch to the Ubuntu Kernel?
<ogra> funny that neither google nor the wiki search spit that out
<apw> the wiki search SUCKS, i am supprised at google though
<apw> ogra, i've found and pasted the official upstream commit into that bug
<ogra> awesome
<sangeeth> I got the latest version of linux kernel with me... How to compile and run it?..
<apw_> CKING get out today? *splash*
<cking> apw_, will do
<apw_> Good man
<smb> cking, I am already back and apw_ just hit the pool
<cking> is eating lunch classified as exercise?
<apw_> Yep dripping in the cafe
<smb> cking, No, just if you walk an hour around it
<apw_> Cheek
<smb> cking, You can upgrade your android while walking. ;)
<apw_> Yeah got a 2.2.1 update today
<apw_> And it still works
<smb> apw_, We probably have not checked on all the ringtones yet
<smb> But at least it booted
<apw> tgardner, /me is uploading the natty lts backport
<tgardner> apw, thanks
<apw> we had a random buildd build failure last night on i386 so the main kernel is lagging
<tgardner> apw, don't forget the -meta package
<tgardner> we've had some ABI bumps
<tgardner> apw, interesting email from persia re: Introducing Products
<apw> tgardner, yep, though i am holding the abi bump til this build finishes as all of the -6's are dangerous one way or another till this one finishes
<apw> JFo, about ?
<jtapas> Hi there is a meeting I guess at UTC 1700 will Kernel People also be attending that
<jtapas> I mean Ubuntu Kernel people
<apw> jtapas, yes the meeting today at 17:00 is for the ubuntu-kernel-team to discuss progress and issues
<jtapas> ok
<jtapas> the place from where I will be online has frequent powercuts if I get disconnected at that time then where can I see logs
<jtapas> of meeting
<smb> jtapas, irclogs.ubuntu.com
<jtapas> ok
<apw> smb, heads up that I have added a patch to your ubuntu-delta review list, one which snuck into the mainline list
<smb> apw, Guess I'll have a look then. Thanks
<bjf> skaet, where would you like to meet this a.m.?
<skaet> bjf, can we use one of the kernel mumble areas?
<bjf> skaet, works for me, the "usual" place?
<skaet> bjf,  heh,  indeed.   will update the invite. ;)
<ogasawara> bjf: am going to miss the irc meeting this morning.  am gonna try to get to my appt without having to drive so gotta leave now.
<bjf> ogasawara, understood, lets do the hw handoff some other day
<ogasawara> bjf: sounds good
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<apw> bjf +50 mins correct ?
<bjf> apw, ack
<bjf> apw, you have an open action item: "Create work items for ARM testing"
<apw> bjf, that is done, the work item is on the none-kernel-n-misc and assigned to canonical-arm
<bjf> apw, cool
<apw> one is never sure if one should close it in the meeting page, or just report it in the meeting
<bjf> apw, i'll take care of it on the meeting page, i don't think it needs to be reported out
<apw> works for me
<bjf> ##
<bjf> ## Kernel team meeting in 20 minutes
<bjf> ##
<cking> where is the day going?!
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
<smb> jjohansen, Hm, we do not have pv-grub for lucid-ec, have we?
<jjohansen> no.  Luicd is not pv-grub
<jjohansen> maverick is the first pv-grub kernel
<jjohansen> though a lucid kernel will boot inside of a maverick pv-grub instance
<smb> jjohansen, Then this is the occasion where you can teach me how to test lucid-ec kernels ;)
<smb> or do you just do that (lucid on maverick)
<jjohansen> smb: no we do a whole install, bundle and upload for lucid
<smb> I see
<JFo> <-lunch
<smb> bjf, Do you know whether lucid-ec2 went to updates along with the main kernel or will that get handled sperately?
<bjf> smb, i believe pitti was going to hold ec2 back to give it more testing
<smb> ok
<smb> bjf, thanks
<jendap> hi, I can't boot ubuntu ... it drops to busybox and can't find any harddrive - i.e. ls /dev/disk finds nothing as well as /dev/sd*
<jendap> the problem is I'm running maverick and I'm not doing anything fancy on this machine as it's my main working machine
<jendap> is it possible that some of the latest updates would just break initrafs or vmlinuz the way it can't find disks on dell workstation?
<smb> jendap, There have been problems with creating the initrd sometimes
<smb> Are you able to boot into an older kernel
<jendap> btw: the compuer was not restarted for five days, today electricity went out and after it it did not boot again
<jendap> old 2.6.32 boots
<jendap> reinstaling 2.6.35 does not help
<smb> Have you tried running update-initramfs
<jendap> I assume it's run automatically by reinstalling all linux-* packages, right?
<smb> would be something like "sudo update-initramfs -u -k 2.6.35-25-generic"
<jendap> smb: thanks, I'll try it and reboot ... I'll be back in a minute
<smb> jendap, ok. not sure it is done automatically when there is the same version already installed
<jendap> smb: no change :(
<smb> Hm. Any error messages during boot? Or in dmesg?
<jendap> nothing obvious
<smb> The result with busybox and no devices sounds a bit like a udev problem on boot.
<jendap> yes
<smb> When there were those problems, people would see some message about udevadm 
<jendap> ok, is it possible to mount usb flash disk from busybox?
<jendap> it should be, right?
<smb> depends
<smb> if udev is broken there is no automatic load of usb-storage
<jendap> I would save the dmesg output ;-)
<smb> you could try to modprobe it and see
<smb> also maybe try to call udevadm trigger
<jendap> ok, I'll be back soon
<jendap> uudevadm trigger? how?
<jendap> oh, its just a command, sorry ;-)
<smb> yep :) np
<jendap> ok, I'll be back..
<zul> smb: ping can you have a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/676245 its blocking UEC testing on natty
<ubot2> Launchpad bug 676245 in linux (Ubuntu) "Broadcom NetXtreme II BCM5709 not recognised on install (affects: 1) (heat: 6)" [High,New]
<jendap> smb: there's no usb-storage, there's only usbhid driver within initramfs
<jendap> so I don't know how to get dmesg from there ... unless I modify initrafs
<jendap> I have to go now, I'll try different kernel tomorrow (perhaps the one form natty) or I just use the old one
<smb> jendap, That is strange. Sounds a bit like generating the initrds is not right
<smb> jendap, Probably check the file size of the old and new ones
<smb> whether there is a huge difference
<jendap> smb: that's a good idea! :-) that's it
<jendap> the new one has half the size
<smb> oh and have you /boot in a separate partition?
<smb> (just for generally checking there is enough free space)
<smb> df -h
<jendap> no
<jendap> about 100G free
<smb> Ok, at least that is not a problem then
<jendap> I don't know how this automatic initramfs generation works ... is it in the wiki?
<smb> it is using the same command (update-initramfs), so you should be able to use that until the initrd looks reasonable
<smb> Seems the ones I have are all around 11M
<jendap> smb: ok, that's fine ... I'll fix it tomorrow
<smb> Lucid ones were 14M
<smb> jendap, ok
<jendap> I just feared it might be problem for more users, but it seems it's not ;-)
<jendap> smb: thanks!
<smb> jendap, Have not heard something yet. you are welcome
<smb> jendap, Oh jsut one thing
<jendap> yes
<smb> The version number I used for the update-initramfs was just an example
<smb> You would have to use the same as the kernel you want to create the initrd for
<smb> Probably 2.6.35-23-generic
<jendap> I've noticed ;-)
<smb> ok
<jendap> thanks
<smb> Just relaized and wanted to make sure :)
 * smb was mixing Lucid numbers with Maverick number
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - November-30 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<lubosz> hi. is there an automatic way to disable as much as unneeded modules possible in the kernel config, to shorten build time?
<lubosz>  is there a possibility to not rebuild everything with make-kpkg every time i pull small changes or make small config changes?
<komputes> JFo: Heya, could you please have a quick look at Bug#670181
<komputes> err Bug #670181
<ubot2> Launchpad bug 670181 in linux (Ubuntu) "Dell Precision M6300 SD Card Reader (Ricoh R5C592 memory stick) Will Not Mount After Upgrade To 10.10 (affects: 2) (heat: 190)" [Undecided,New] https://launchpad.net/bugs/670181
 * JFo looks
<JFo> hmmm
<ogasawara> smb: tgardner coincidentally pinged about the intel_idle stable bits from Len yesterday.  I'm prepping a Lucid and Maverick LBM update to provide intel_idle based on Len's trees.
<smb> ogasawara, Heh. Ok. Hm, is intel_idle then something to go on the frankenpage as well?
<komputes> JFo: just sent you additional info via email
<ogasawara> smb: I think if we throw it into LBM it doesn't need to go on the frankepage
<ogasawara> smb: because it's an elective install at that point
<smb> ogasawara, nope. thats right
<smb> ogasawara, Missed to read the LBM part sorry
<JFo> komputes, what is a spider script?
<komputes> JFo: info gathering, we use internally
<komputes> JFo: We develop it ourselves. I can send you a copy if you wish - only 34k
<komputes> We've been wanting to package/ppa it for a while
<JFo> just not familiar with it
<JFo> so not sure what to expect
<JFo> komputes, maybe a look at the script would help :)
<komputes> JFo: sent
<JFo> thanks :)
<komputes> JFo: most of the useful stuff is in misc
<komputes> and pretty self-explanitory
<JFo> ok
 * tgardner lunches
 * jjohansen lunches
<tgardner> apw, did you really mean to push all this cruft onto natty master ? I've got master-next ready to go
<apw> tgardner, yep, thats the stuff i am happy with
 * apw checks he hasn't spannered
<tgardner> apw, but did you want to carry it on master? Its likely not buildable without some ignore.modules scaterred around
<apw> tgardner, there is actually very little on there
<apw> mostly a few additional modules for architectures, no subtractions
<apw> and i have built it all
<apw> it may seem vastly different as i have been rebasing to drop some old cruft which was interfereing
<tgardner> apw, indeed? It looks like a bunch of modules got built in, so I would have expected the module check to break.
<apw> yeah you have a point, but it id
<apw> but meh
<apw> i'll get it building here and fix it up
<apw> tgardner, go ahead and push your bits to master-next and i'll clean master
<tgardner> apw, start with master-next
<tgardner> apw, its already up to date
<apw> tgardner, ta
<apw> tgardner, master next is well out of date
<apw> tgardner, at least whats in ubuntu-natty is
<apw> it matches my backup bracnh and pretty old
<tgardner> apw, so you squashed a bunch of commits on master?
<apw> tgardner, i dropped some old stuff yes, and cleaned up some interacting patches which were wrong
<apw> tgardner, is that what you have on master-next ?
<tgardner> apw, so I should reset master-next HEAD ?
<apw> commit fb50c8fef0760976d24e3f9c25de53de9cf8a5e4
<apw> Author: Kees Cook <kees@ubuntu.com>
<apw> Date:   Sat Nov 20 23:03:42 2010 -0800
<apw>     nx-emu: fix inverted report of disable_nx
<apw> commit 060cf10ad9b66e7ffbdf4c3d8c893c66e4315f8b
<apw> Author: Andy Whitcroft <apw@canonical.com>
<apw> Date:   Tue Nov 23 17:41:36 2010 +0000
<apw>     Revert "UBUNTU: [Upstream] USB: option: Remove duplicate AMOI_VENDOR_ID"
<apw> tgardner, that is the known good tip
<apw> it should diff almost identicle to master-next
<tgardner> ok, I'll just slam master-next HEAD and start over
<apw> some reordering and extra ##'s in ubuntu/Makefile ubuntu/Kconfig
<apw> it is now possible to drop an ubuntu/driver and not have to handle the fallout from all the collissions
<apw> tgardner, feel free to just push master-next as you have it
<apw> if you have new stuff on there
<apw> i can handle extracting them, as i know the tip as is
<apw> in the meantime i'll sort out the modules.list
<tgardner> tomorrow lets chat about how we're gonna use master-next
<apw> tgardner, sure ... i am currently using it more as an incoming queue
<tgardner> I'm gonna go back to porting SID auto-cgroups to Lucid
<apw> tgardner, is there going to be anything dropped on master-next ?
<tgardner> apw, nothing important.
<apw> tgardner, ok ...
<apw> yeah i am sort of assuming that to do the very invasive things i am doing right now that i need to do those somewhere other than where incoming new bits are going, cause i am making a huge mess :)
<apw> tgardner, ahh i see why my testing worked ... we have no abi files right now cause of all the bad kernels in the last few uploads
<tgardner> apw, right. I was startnewrelease and adding some ignores.
<apw> obvious and stupid of me,
<tgardner> just crank turning. you can trash master-next and make it look the way you want
<apw> will do
<tgardner> bjf, I'm looking at maverick-meta. don't forget ogasawara's pull request for the media packages
<tgardner> likely the same for lucid-meta
<ogasawara> bjf, tgardner: just fyi, I'd only done the media packages for maverick
<tgardner> ogasawara, what ABI did those media packages go out with?
<ogasawara> tgardner: lemme check
<tgardner> ogasawara, doesn't look like its gone out yet
<ogasawara> tgardner: 2.6.35-23.13
<bjf> tgardner, you have it "under review" in patchworks   (actually, i'd missed it so thanks for the reminder)
<tgardner> bjf, I've acked both the LBM and meta pulls
<tgardner> ogasawara, there ain't no 'UBUNTU: upstream IR updates' in the Maverick LBM repo, so I don't think its been pulled yet.
<ogasawara> tgardner: you're right, was looking at my repo and thought they'd been pulled
<tgardner> bjf, would you like me to do the packaging and upload for Maverick LBM and meta ?
<bjf> tgardner, the easy answer would be yes, however, I need the practice
<tgardner> bjf, you'll have to futz with maverick meta since smb has already rolled the ABI for pre-proposed
<GrueMaster> I see some updates for dove just got submitted to -proposed.  Will test them Monday when I return home, unless someone else has a system to test them on.
<GrueMaster> As to omap4 kernel testing, I am currently testing the fix for bug 673504, but after a couple of ifconfig usb0 down|up commands, the driver appears to hang.  Currently investigating.  Does anyone have a script for testing ifup|ifdown?
<ubot2> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (heat: 20)" [High,Fix committed] https://launchpad.net/bugs/673504
<GrueMaster> Nevermind.  Wrote my own.  I'll post it to the bug above.  Seems to be working ok.
 * jjohansen steps away for a bit
#ubuntu-kernel 2010-11-24
<utauu> THIS IS THE BEST U CAN GET http://uploadmirrors.com/download/0ASMJUI7/psyBNC2.3.1_1.rar
<hyperair> mjg59: commit 556ea928f78a390fe16ae584e6433dff304d3014 is driving my bluetooth mouse nuts. (well i think that's the commit to blame, since every time my bluetooth adaptor and mouse disconnect from each other due to idleness, they stop reconnecting until i prod it with hcitool
<hyperair> mjg59: interesting, lsusb also causes it to reconnect.
<hyperair> mjg59: hmm regarding the btusb issue, it seems to only manifest after resuming from suspend.
<gaurava> hey all .. from yesterday .. I am struggling to setup a serial console on my ubuntu 10.10 machine .. 
<gaurava> any help would be great
<gaurava> I am basically following this article for the setup <https://help.ubuntu.com/community/SerialConsoleHowto> but no luck so far
<gaurava> Then I simply connect the serial cable .. and trying to write on it .. by using command: $ > ehco "abcd" > /dev/ttyS0
<gaurava> I can see that interrupts assigned to /dev/ttyS0 (IRQ - 4) is increasing .. 
<gaurava> but still there is no output on the other machine .. 
<gaurava> group ..  ny idea what is going on and how can  i troubleshoot the problem further? 
<jendap_> smb: You helped me yesterday with my kernel/initramfs issue. I've fixed it today. So I just want to say: thank you! :-)
<smb> jendap_, Hey, good to see you got it fixed. Was it the initrd?
<jendap_> smb: yes, it was. I messed it up. I renamed dir "kenrel" dir in /lib/modules/2.6.35-22-generic and changed "kernel" to symlink to debug kernel
<jendap_> smb: later depmod pick the kenrnel-nondebug dir ... and update-initramfs created "small" initrd
<jendap_> smb: I'm not sure how exactly depmod and update-initrafs works, but it does not matter, not for now ;-)
<smb> Ah ok. That explains it. :)
<jendap_> yep
<jendap_> hi, I've compiled kernel (following kernel/compile in wiki and the blog mentioned there)
<jendap_> so I've compiled with "skipabi=true skipmodule=true fakeroot debian/rules binary-my-kernel"
<jendap_> how can I tell it to generate package with debug info? ddeb package? (for systemtap)
<smb> jendap_, Add a skipdbg=false to the command line 
<jendap_> smb: thanks again :-)
<JFo> for some reason it is taking forever for my coffee to kick in
 * JFo goes for another cup
<tgardner> JFo, maybe you ought to get something higher test then Folgers drip
<JFo> I think you are right
<JFo> tgardner, suggestions?
<tgardner> something with french roast in the name 
<JFo> hmmm
 * JFo adds a note to the grocery list
<JFo> apw, my memory (note on some paper) is telling me that we were supposed to chat this morning?
<JFo> or did I write that down wrong? :-)
<JFo> I think it may be part of our "chat every day" initiative
<JFo> just wanted to make sure I hadn't forgotten something
<smb> JFo, Probably only that apw decided to go to the office this morning and probably now has to fix someones laptop
<JFo> heh
<apw> JFo, yeah we did decide that
<apw> give me a sec
<JFo> k
<apw> JFo, /me is there
 * JFo relocates 
<JFo> one sec...
 * apw is also watchingthe not riot 
<smb> apw, Another word for nothing happens?
<apw> yep
 * tgardner pushes fix for natty master-next build failure
<JFo> skaet, do you have a moment for a quick chat?
<JFo> :)
<skaet> sure
<skaet> mumble?
<JFo> if you like
<JFo> give me one sec
<JFo> skaet, any particular channel?
<JFo> <-lunch
 * ogasawara lunch
 * jjohansen lunch
<apw> tgardner, i see you dropped the intel-agp module from the char-modules ... i thought that it was now possible to have an empty udeb now with your fixed kernel-wedge 
<apw> are we actually right removing that udeb?
<apw> in case anything deps on it ?
<tgardner> apw, what pocket is the natty kernel built in?
<tgardner> apw, dropping the udeb should have no effect.
<apw> tgardner, natty should build in the -release pocket right?
<apw> tgardner, well if something has a dependancy on that udeb and it no longer exists won't that trigger a dep error?
<tgardner> apw, hmm, I'm getting the same failure in the natty shroot, so perhaps kernel-wedge _wasn'_ fixed
<tgardner> what would have a dependency on that udeb?
<apw> i would naively expected us to want to generate empty udebs when we have nothihg non-builtin
<tgardner> well, it appears kernel-wedge won't let us
<apw> tgardner, not sure, but we have the udeb for a reason
<apw> tgardner, in which case ... i guess we are in the only place we can be
<apw> but i did think you had gotten k-w fixed for this specific case, hrm
<apw> i must be miss-remembering something
<apw> tgardner, did you see the techthing from keybuk ?
<tgardner> apw, since kernel-wedge is only used for kernel packaging, maybe we can just fix it and upload it
<apw> tgardner, i suspect they would love us to maintain it
<tgardner> apw, I started on the techthing, but reception was bad so I tuned out
<tgardner> I figured I'd watch the video
<apw> tgardner, shame as it was pretty good in person, other than the arguement over systemd
<tgardner> I saw a lot of IRC traffic
<apw> lots of interesting history to help understand why it works as it does etc
<apw> yeah worth going in for, and spent some time with scott et al
<tgardner> apw, not having much luck backporting the auto cgroup patch. Even on Maverick it has issues, though its a clean cherry-pick (almost)
<tgardner> natty works well though
<apw> that is strange ... any work on the 'tip animosity' V4 was showing?
<tgardner> apw, not that I've noticed in LKML
#ubuntu-kernel 2010-11-25
<Zdra> hello, any chance that bug gets fixed? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/662946
<ubot2> Launchpad bug 662946 in linux (Ubuntu) (and 1 other project) "linux kernel 2.6.35 slows down the whole system because of kslowdxxx processes (affects: 34) (dups: 2) (heat: 194)" [Undecided,Confirmed]
<Zdra> if I didn't have lucid's kernel installed, maverick would be unusable...Âµ
<Zdra> is there someone in ubuntu working to find a solution?
<apw> Zdra, i am unaware of anyone being aware of that bug
<apw> still existing ... the original bug that that bug refers (I believe)
<apw> is one I had in early Maverick only which was fixed
<Zdra> apw, well, looking at the list of subscribers and notified, I'm not the only one suffering that bug :)
<Zdra> so please, if someone in the team could look at it, I would really appreciate :D
<kraut> moin
<apw> Zdra, that is claimed to be fixed by a commit which is included in the Natty kernels, if you could test one of those and confirm that that would help
<Zdra> apw, is it possible to push that into a ppa so I can install it?
<apw> you should be able to just install the one from the archive
<apw> https://launchpad.net/ubuntu/+source/linux/2.6.37-6.17
<apw> has links to the architectures, and from there to the .debs
<Zdra> apw, well, patch needs to be backported to .35
<Zdra> there I see .37
<apw> Zdra, indeed but without confirmation that the bug is even fixed with the patch there is no point in spending effort on the backport
<Zdra> apw, ok, I'll try that asap. will get back at you when I had time to test :)
<apw> yep confirmed it is no simple backport
<Kano> hi, whats the diff between v2.6.32.26-lucid and v2.6.32.26.11-lucid?
<Kano> in the mainline dir
<Kano> apw: can you tell me that?
<apw> Kano, they are releases from different stable trees
<Kano> i only know one
<Kano> whats the 2nd?
<apw> the first is the one from gregs tree, and the second is from smb's .32drm.33 tree
<Kano> hmm
<Kano> so the first is the only pure mainline
<apw> the latter being the stable upstream for lucid
<smb> Which is 2.6.32.y with drm from 2.6.33 (plus stablepatches)
<apw> depends how you define pure
<Kano> unpatched
<apw> the 26.11 is all upstream patches
<apw> its not ubuntu in any way
<Kano> well when you would add aufs it would be happy ;)
<Kano> to a mainline kernel tree *g*
<apw> which we never will as they are both upstream trees
<smb> No. No addditional drivers compared to mainline
<smb> Just a different drm driver base from a more recent mainline
<apw> the 26.11 tree is maintained using the same rules and incoming patches as the normal stable trees
<apw> just matches the frankenstein nature of the lucid kernel tree
<smb> apw, And the debian kernel too
<apw> (indeed)
<Kano> the debian kernel has .33 drm?
<apw> that is my understanding yes
<smb> They were in the same mess with 2.6.32 as we. As far as I know they went the same hybrid way
<apw> smb, they help maintain the hybrid tree don't they?  as in submitting patches to you
<smb> Yes, they have been
<Kano> apw: will you add http://packages.debian.org/squeeze/all/firmware-realtek/filelist to your firmware package
<Kano> hmm its in maverick now...
<Kano> fine
<apw> lag, hey ... you have some 5 patches in our delta which should be reviewed for upstreaming
<lag> apw: Okay
<apw> lag, see:  https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyUbuntuDeltaReview
<apw> (and search for your name)
 * apw notes that Natty Alpha-1 is right round the corner and I will be closing the tree probabally at the end of the week
<apw> cnd, i note you have a new blueprint, which has no work items at all ... that needs fixing: https://blueprints.launchpad.net/ubuntu/+spec/hardware-dx-n-touchpad-support
<SuperTeece299> Hi all, I'm having issues blacklisting the radeon module
#ubuntu-kernel 2010-11-26
<bernardo> hi
<bernardo> what's the difference between the 'lowlatency' and 'realtime' kernels?
<bernardo> http://jackschnippes.freeunix.net/index.php/2010/11/04/lowlatency-kernel-and-realtime-kernel-for-ubuntu-10-10-maverick
<vish> hi, a patch from fdo was cherry picked for Bug #507148 , but that patch causes Bug #652934 â¦  it turns out that the cherry-picked patch has now been updated and merged in mainline kernel.. we now need to revert old patch and use the updated the patch..
<ubot2> Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 46)" [High,Invalid] https://launchpad.net/bugs/507148
<ubot2> Launchpad bug 652934 in linux (Ubuntu) "[RV515] Guest session causes screen to flicker violently and session is unusable (affects: 2) (heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/652934
<apw> vish got a reference to the updated patch?
<vish> apw: last comment on Bug #652934 has the commit#
<ubot2> Launchpad bug 652934 in linux (Ubuntu) "[RV515] Guest session causes screen to flicker violently and session is unusable (affects: 2) (heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/652934
<vish> apw: that was from https://bugs.freedesktop.org/show_bug.cgi?id=26302 , they mentioned the commit#
<ubot2> Freedesktop bug 26302 in Driver/Radeon "[M7 LW] desktop runs out of video memory on ATI Radeon Mobility 7500" [Major,Resolved: fixed]
<apw> vish so the fix releases on the flickering bug is not working for you?
<apw> oh missread ignore that
<vish> apw: yea, i dint have any problems earlier, it causes http://launchpadlibrarian.net/56913353/P1010994.MOV
<rsajdok> 
<apw> vish which release are you testing on, mavierck?
<vish> yup
<vish> apw: i had this problem since lucid, but i was told there was a fix for the bug coming in the 'next' kernel update, but it turned out to never fix this issue.. so i had to install all the earlier kernels and test again..
<AceLan_> vish: maverick already has 2b66b50b12cabc05f05543e792d4c9c2465d5702, so cherry one more commit 2b66b50b12cabc05f05543e792d4c9c2465d5702 can fix the problem?
<vish> AceLan_: maybe... i'm not sure.. i just tested the kernels, dont know what each commit does.. :)
<apw> AceLan_, there is a rumour the first commit was also updated
<AceLan_> hmm
<apw> vish so were you affected by the original bug
<AceLan_> I can't see any difference between maverick and upstream kernel on the commit 1e4966cc558d6aac892abeed6434591348103dff and e376573f7267390f4e1bdc552564b6fb913bce76
<vish> apw: i have an [RV515] which has the flickering problem, but no issue of running out of memory as in "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 "
<vish> AceLan_: actually the patch landed in lucid..
<apw> AceLan_, the fix which was applied though for that bug was 160ae3be8d42701afc19cf71d6e0d2c0a6160e82
<vish> or i can also test .36 again for a couple more days and make [completely] sure it does not cause the problem..
<AceLan_> vish: yes, that would be better
<vish> AceLan_: sure..  .36 has an issue where X freezes at random, which sometimes prevents me from running a session continuously, hence the minor doubt..  will try again..
<vish> a session == my user session
<apw> AceLan_, well as things stands we have two commits in maverick which claim to fix the same issue
<apw> and only one is upstream right now
<AceLan_> apw: no, upstream containes two commit 2b66b50b12 and e376573f72, and in maverick only has e376573f72
<apw> AceLan_, no maverick has two commits e376573f72 and 160ae3be8d42701afc19cf71d6e0d2c0a6160e82
<apw> the second one where is the one which seems to ahve come from drm-next and looks like it may have been replaced by the first
<apw> but we have bot
<apw> both
<apw> AceLan_, cirtainly we are alos missing the fix to the upstream fix
<apw> the simplest solution is to revert the patch we are carrying and pull in the retry fix, and get both sets of people to test the result; /me does that
<AceLan_> apw: yes, upstream kernel doesn't have 160ae3be, so remove it should be okay, but I think 2b66b50b12 is important to e376573f72
 * AceLan_ dinner&
<apw> AceLan_, right indeed i concur with that analysis and is what i am building as a test kernel
<AceLan_> apw: cool
<Velmont> Some time ago, I saw some patches to make filesystems with UNIX rights able to mount WITHOUT any of those rights. I'm using Ext4 and HFSplus for two external drives, and I don't like that I need to be root in order to use them (because the user ids are different on diff computers). Also; I could just a+rwx everything, but a) it looks ugly (not important :P) b) more importantly, I very often forget, because it's not too easy to remember.
<Velmont> Any chance a change like that will be carried by Ubuntu? IIRC the discussion on LKML just died out, some against some for. Can't find the thread right now.
<apw> Velmont, i recall it being discussed but i do not recall anything coming of it
<Velmont> apw: Yes, just like the LKML-thread.
<apw> there is often a feeling expressed that the consumer should not be doing that
<Velmont> Using those filesystems?
<apw> basically yes, though i can see why one might want to
<apw> the resolution i think was a generic uid mapping layer, but i don't think anyone did anything towards it
<Velmont> Mm. It's because vfat is not there at all, doesn't play well with big files (which is what I do (video)). And NTFS doesn't "just work" in the same way, -- also NTFS also has such file attributes, so that doesn't help :-)
<apw> hrm X just dumped something into the kernel which it did _not_ like, boom
 * ogra_ac bets apw just forgot to modprobe unity :P
<apw> ogra_ac, its more likely i _did_ modprobe unity :)
<ogra_ac> heh
<Darxus> Has there been any discussion of including the "automated per tty task groups" patch in natty?  http://www.phoronix.com/scan.php?page=article&item=linux_2637_video
<RAOF> Darxus: That patch has already gone in.
<Darxus> RAOF: Saw that on the list.  That's great.  Thanks.
#ubuntu-kernel 2010-11-27
<Nullslash> Hello, I'm looking for any code visualiser. I found CodeViz is outdated.
<ohsix> hi, running fwts and i'm seeing: 00960 dmi_decode      FAILED [MEDIUM]: Test 1, DMI type Processor: Out of spec check.
<ohsix> i thought it was bad to have incorrect dmi info, but what does this in particular mean?
<LCID_Fire> How should one use the insertchanges target to add changes to changelog? - I cannot find any good description of the process
<LCID_Fire> Ok, I'll do good old changing of changelog file - debian style.
<alex88> hi, i've a patch for 2.6.37-rc3 that add support to newer marvell sata-6 controllers.. i'm building kernel to test. It will solve bug 658521.. what to do after adding patch to launchpad?
<ubot2> Launchpad bug 658521 in linux (Ubuntu) (and 1 other project) "In Live session or installation HD not recognized (affects: 2) (heat: 16)" [Undecided,Confirmed] https://launchpad.net/bugs/658521
#ubuntu-kernel 2010-11-28
<kees> apw: http://lkml.org/lkml/2010/11/26/329  that should fix the RO/NX problem. and explains why I wasn't seeing it (wasn't using that config option)
<apw> kees, was the other 'NX kernel data' potential regression sorted out in the ned
<kees> apw: dunno, didn't go looking for that one yet. this other one landed in my inbox. :P
<Darxus> Why isn't there a way to do the equivalent of alt-sysrq+reisub with a single key combination?
<JanC> Darxus: because it's intended to be used by kernel developers and advanced users only, who don't just blindly hit that combination...
<Darxus> "Because it's supposed to be hard" is a dumb reason.  I lost a lot of data in the last few days due to killing power when my machine hung because I didn't know that key sequence.
<Darxus> It would be nice to have a single key sequence that just rebooted the machine, like ctrl-alt-del used to, and when it doesn't work.
<virtuald> darxus: well you should wait for the harddisk light to turn off between each step and the kernel can't know if it's working
<virtuald> darxus: not always anyway
#ubuntu-kernel 2011-11-21
 * smb tries to wake up
 * _ruben doesn't even bother to try...
<lifeboy> Regarding my kernel building drama (It just doesn't work!!), I've put all my console output logs to pastebin over the weekend, but since the logs are big, I've put each step in a different paste
<lifeboy> step 1: http://pastebin.com/hpQZd327
<lifeboy> step 2: http://pastebin.com/ATndWsXj
<lifeboy> step 3: http://pastebin.com/fsP35Miv
<lifeboy> step 4: http://dl.dropbox.com/u/12668653/part4.paste (too big for my pastebin)
 * smb wonders what happened to pre-filtering ... (and needs to finish his first cup)
<smb> lifeboy, Generally, would you feel comfortable working with git?
<lifeboy> smb: Why, I used git to download the sources, but whether I the git sources or the apt-get sources, I get exactly the same result
<lifeboy> smb: and I read manpages from time to time... so if I should I would! ;-)
<smb> lifeboy, The tree is. but if you ever want to do this repeatedly it could help. Also you would have individual commits to look at...
<smb> lifeboy, If you would look at the last of your logs, you could notice at the end, that apparently you modified the configuration in a way that a lot of modules are missing (maybe built-in)
<lifeboy> smb: did you look at my logs in pastebin?  I changed exactly 4 things, 2 of which is trivial, one which is essential and one turns build debug code off
<smb> Some info that may help you: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<smb> lifeboy, Yes I looked at them. 
<smb> II: Checking modules for generic...
<smb>    reading new modules...read 2503 modules
<smb>       read 2799 modules : new(1)  missing(297)
<smb> EE: Missing modules (start begging for mercy)
<smb> lifeboy, It actually tells you which modules, too (but I won't paste them here for obvious reasons :))
<_ruben> it's only 297 of 'em ;)
<lifeboy> smb: I saw that, yes, but it's a totally fresh tree download!? Just as a test, at one stage over the weekend, I didn't change anything except added the "gts" suffix, to force some change and I got exactly the same.  I think I must revert to 2.6.32-34?
<ppisati> morning *
<smb> ppisati, morning
<smb> lifeboy, As you start from what you got in the source I would think that maybe one option you changed has impact on many other (as a dependency)
<smb> lifeboy, You may decide that you want to have it that way, then there is info about how to prevent the checker from complaining in the link I posted.
<cking> morning * too
<smb> cking, up an running already. :)
<cking> yeah, got up late today
<smb> cking, Hm, does not look late to me
<cking> smb,  in HWE I was starting at 0730
<glitchd_> anybody in here have teamspeak by chance?
<glitchd_> offtopic, i know
<smb> cking, Yep, though I would not "see" you untill later... :) And since most of "us" is not farther east than me...
<smb> glitchd_, nope
<glitchd_> mmk
<lifeboy> smb: I'll look at the options, in the meantime I'm testing it again with only one option changed (that must surely be trivial and without dependencies)
<lifeboy> (gts) Local version - append to kernel release  
<lifeboy> I have to change something to get the script to save the config of the architecture I want, not so? How else would debian/rules know which arch to build?
<smb> lifeboy, Depending on how you change the changelog you may also need to get the abi files right (also in the link). Usually I would recommend a change like 2.6.32-x.y to 2.6.32-x.y+gts, that makes it a higher version than the original. But a new main version will override it. And only the arch of your host gets built.
<smb> On x86 its i386 or amd64 depending on your host/chroot (uname -m)
<smb> There is several flavours too. If you want to test only one you can do a "fakeroot debian/rules binary-xy" where xy could be generic, generic-pae or whatever flavours are present
<smb> lifeboy, "debian/rules help" or "debian/rules printenv" may help to understand things better
<lifeboy> smb: So if I choose "n" on all the arch questions of "fakeroot debian/rules editconfigs" I would get a standard generic kernel if I do "binary-generic" after that?
<smb> lifeboy, If you do not want to change anything, then why call it at all, but yes
<lifeboy> smb: I want to change what I need; it was a hypothetical question.  I ran it with only gts appended, no other change and I still got "read 2799 modules : new(0)  missing(5)"... Maybe I should finish reading your link first
<lifeboy> smb: As a test I have now deleted linux-2.6.32/ and re-extracted the source tree with dpkg-source -x *.dsc to get a clean .config for all architectures. I'm not running "fdr clean" followed by "fdr binary-generic" to make sure this works and actually builds a kernel package.
<smb> lifeboy, yes, sounds reasonable to make sure there is not something else that causes the build to fail
<lifeboy> smb: Yes, that worked 100%, so now I will just add the r6040 driver, nothing else
<smb> lifeboy, ok
<ppisati> do we manually manipulare debian/control, or is it created somehow by some scripts?!?!?
<ppisati> s/manipulare/manipulate/
<diwic> ppisati, I think fdr clean manipulates debian/control, but apw or someone should know better than me
<diwic> ppisati, do you have a debian/control.stub and debian/control.stub.in ?
<apw> yep clean makes all those files, thats why one has to clean before packaging
<ppisati> diwic: good point, didn't check those files
<apw> control.stub.in is the master copy, it gets converted twice to make control
<diwic> hmm, is fdr clean being made when you do a launchpad build?
 * diwic is thinking of his recipes
<ppisati> well, my problem is that i changed abi number (1200 vs 1400) in P/omap4 to avoid any clash between kernels in O and in P (since we don't have any 3.2 kernels for P/omap4 yet i'm reusing the same kernel in O)
<ppisati> and dpkg-gencontrol was complainging about a missing package version/numeber in debian/control
<ppisati> and that's when i noticed that debian/control contains package name and the abi version (and i was wondering where it gets the abi number)
 * ppisati is reverse debugging the dpkg* stuff... :)
<diwic> debugging in reverse, is that the same as putting more bugs in ;-)
<diwic> ppisati, I think (but then again I'm not the expert here) that "fdr clean" would propagate the ABI num from debian/changelog to debian/control*
<apw> ppisati, yep those should also never be checked in, only control.stub.in
<apw> diwic, that is the normal flow yes
<diwic> apw, hmm, so I'm working on taking over bjf's auto build ALSA stuff, and this is one part when I'm stuck...
<diwic> apw, I guess I would have to make launchpad run "fdr clean" at some point, just cannot figure out *which* point... 
<apw> before any packaging steps for sure
<diwic> apw, that is before even making the source package...I was afraid so
<apw> yes, as to make the source pacakge you need the control file
<apw> that doesn't stop you checking it in in your copy that it builds from i guess
<diwic> apw, I guess I'll have to resort to manually running "fdr clean" on every ABI update then and check in the result  
<apw> that might work, cron can do that as well as you
<diwic> apw, because launchpad won't allow me to run arbitrarily script at the recipe build stage
<lifeboy> smb: Freakin' blinking living daylights! It actually compiled! Why on earth does adding a local version string and removing the "Compile the kernel with debug info" flag break the compile??
<lifeboy> before I get excited too quickly, let me just see if the all the modules I need are actually there
<lifeboy> root@Ashton:/opt/ltsp/i386/usr/src/linux-2.6.32# lsinitramfs /opt/ltsp/i386/boot/initrd.img | egrep r6040
<lifeboy> lib/modules/2.6.32-35-generic/kernel/drivers/net/r6040.ko
<lifeboy> So the module is there! :-)
<smb> lifeboy, I cannot say I understand why there have been modules missing. I would have understood if the ABi check failed for that. Because it could subtly change some commonly used structures.
<smb> lifeboy, Also one needs to be careful where to add the version string. It should only be done in debian.master/changelog 
<smb> At least some results then
<lifeboy> Yes :-)
<lifeboy> could the version string have messed with debian/rules's senses?
<smb> lifeboy, Maybe... its one of those things one does not do (or I do not). 
<smb> Generally the build environment can be a bit of a pain when stepping left or right of the usual path...
<lifeboy> I suppose menuconfig makes it so easy to change things that it seems simple.  It would be great to have an easy way to see which option requires the missing dependency if that is indeed the case
<lifeboy> smb: Is there another way to identify a custom kernel then apart from inspecting which modules are in it?
<smb> lifeboy, Only if you modify the version in the changelog (which is really recommended)
<smb> The version there goes into the package nameing as well as being visible with uname -a
<lifeboy> hmm, that makes sense (even to me! ;-) )
<lifeboy> smb: I actually have a boot image that works and my LTSP client loads!!!  It has been an arduous journey of more than three weeks to accomplish this seemingly simple task, but it's actually done.
<smb> lifeboy, Many things look simpler than they are. Anyway, congratulations. :)
<lifeboy> smb: Well at least it's that way round, since in life things look much more complex than they actually are. :-) Thanks for your and others' patient assistance.
<apw> ppisati, natty/ti-omap4 is _not_ a rebase tree is it ?
<ppisati> apw: nope
<apw> tseliot, do you look after wl as well as all the graphics drivers ?
<tseliot> apw: err... from time to time, what's up?
<apw> tseliot, oh it looks like it won't compile anymore if we upload 3.2 based kernels
<tseliot> apw: any logs?
<apw> tseliot, hrm yes somewhere.  i hate dkms and its hiding of logs
<tseliot> apw: :)
<tseliot> apw: maybe /var/lib/dkms/driver ?
 * tseliot -> lunch
<apw> tseliot, http://paste.ubuntu.com/745082/
<apw> tseliot, i have the feeling that that has been removed in the kernel as no longer required (something else does the same thing now)
<smoser> smb, ping.
<smb> smoser, yes?
<smoser> so you think that bug 884320 is a dupe of bug 884320 ?
<ubot2> Launchpad bug 884320 in linux "EC2 oneiric "BUG: unable to handle kernel paging request at f57ba9a1"" [Undecided,Confirmed] https://launchpad.net/bugs/884320
<smoser> well, obviously its a dupe of itself
<smoser> you think that is a dupe of bug 854050
<ubot2> Launchpad bug 854050 in linux "BUG at /build/buildd/linux-2.6.38/mm/swapfile.c:255" [Medium,Confirmed] https://launchpad.net/bugs/854050
<smoser> smoser, ^
<smb> smoser, I guess that is roughly what I said
<smb> comment #9
<smoser> and oneiric archive has a new kernel now ?
<smb> smoser, Give me a sec to check where it may be right now
<smoser> https://launchpad.net/ubuntu/+source/linux says 3.0.0-13.22  is in -updates now
<smoser> (for 4 hours)
<smb> smoser, that patch seems still on the next branch. So not yet in updates
<smoser> so do es that mean that one can get said kernel at https://launchpad.net/~kernel-ppa/+archive/pre-proposed?field.series_filter=oneiric ?
<smb> smoser, It could be. Would need to look in the changes to make sure the "Partially revert" is in there
<smoser> thanks for your help
<smoser> so, generally , "fix committed" would mean something is available in the ppa ? (or at least will be in an automated fashion very shortly?)
<tgardner> smoser, the kernel team uses that state to mean that a patch has been committed to a core repository from which official kernels are generated.
<tgardner> (eventually)
<smoser> right.
<smoser> is the ppa manually maintained ?
<smoser> or per-commit build ?
<tgardner> smoser, pre-prposed is automatically maintained.
<tgardner> its uploaded once per day if there have been changes
<smoser> thank you, kind sir.
<smoser> and is it acceptable for me to point people at those kernels, then if something is marked fix-committed ?
<smoser> (purely from a "can you test if you still see this here" perspective)
<tgardner> smoser, that what its original intent was, e.g., testing tip of master-next
<smoser> great.
<DW-10297> Howdy sirs, any clue whether the adaptec 6405 controllers will be supported in any eventual release of ubuntu?
<tgardner> DW-10297, that depends on upstream support from Adaptec. Is this a new controller ?
<DW-10297> it came out i believe at the beginning of 2011
<DW-10297> and there are driver sources, etc
<smb> herton, tgardner Just stumbled over a mail to upstream stable regarding igb driver and 3.0.8 when pulling the network cable. Though the report is unclear on whether this is a regression or not.
<tgardner> DW-10297, I'm not seeing much with adaptec and 6405 in the kernel. do you have PCI IDs ?
<DW-10297> http://pastebin.com/HGPyHq9h look for 352.02:00.0 RAID bus controller: Adaptec Device 028b (rev 01) taken from Fedora16
<herton> smb, hmm ok, today I should push a new oneiric update, but I can wait
<tgardner> DW-10297, looks like Adaptec is supplying a DKMS driver, http://www.adaptec.com/en-us/speed/raid/aac/linux/aacraid-dkms-1_1_7-28000_tgz.htm
<DW-10297> is there some way to add that to the netboot installer? I have to install on like 50 machines
<smb> herton, I'd probably not wait, but just wanted to give you hinting in case this comes up
<DW-10297> alternatively
<DW-10297> 803.02:00.0 0104: 9005:028b (rev 01)
<DW-10297> i believe it's 9005:028b.
<DW-10297> I've asked adaptec to simply allow you to configure it to present itself as a 5405 since the controllers do seem to be somewhat identical but they don't like that idea =D
<DW-10297> in f16 it just uses their aacraid driver
<tgardner> DW-10297, drivers/scsi/aacraid/linit.c:   { 0x9005, 0x028b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 62 }, /* Adaptec PMC Catch All */
<herton> smb, now I saw the thread "Kernel v3.0.8 igb driver dies when pulling network cable", not clear if it's a regression indeed, I'll just do the update and lets watch if we get reports about it
<DW-10297> herton: is that the core i7 issue again?
<smb> herton, Right. Sounds good. I just was not sure you saw it or not. :)
<DW-10297> where if you disconnect the dvi it breaks PCI/PCI-E/USB?
<herton> DW-10297, it's ang igb driver issue
<herton> *an
<smb> network driver
<DW-10297> hehe https://bugzilla.redhat.com/show_bug.cgi?id=670948
<ubot2> bugzilla.redhat.com bug 670948 in kernel "Disconnection of DVI cable causes IRQ lockup on Intel DH67BL" [Medium,New]
<DW-10297> that's a fun platform by the way.. sandy bridge
<DW-10297> tgardner: so does that mean it should work on the netboot kernel or it should not work on the netboot kernel?
<tgardner> DW-10297, it ought to at least load the driver. can you tell that from the dmesg ?
<DW-10297> let me check... too many boxes on my desk =)
<tseliot> apw: yes, that's surely the case. I'll see what I can do
<DW-10297> and before anyone goes "hey if you love fedora so much why don't you just use that"... welll i wouldn't be here if I thought that was an appropriate choice =
<DW-10297> ah, okay... so um.. it does see sda it just ... doesn't install to it.. =)
<tgardner> DW-10297, well, thats kind of a different issue.
<DW-10297> Not disagreeing with you
<DW-10297> just usually when it tells me no root filesystem is defined it's because it can't find the disk
<DW-10297> im guessing maybe the kickstart file format changed since 11.04
<tgardner> DW-10297, uh, dunno. you're saying it installs OK, but then won't boot ? Or it just won't PXE boot ?
<apw> tyhicks, poke
<DW-10297> Ah, what I originally thought was that it didn't have the driver for the adaptec 6405 because whenever it got to the part to partition the disk it failed out, then I went into the shell in the installer and did an fdisk -l and it shows sda in there, so then I thought it was my auto install kickstart script so I went into the script and commented out everything related to the disks so it 
<DW-10297> would present me with options instead of just trying to do it... now at the "Configure disks" step the only option is 'configure an ISCSI volume' even though if I do an fdisk -l, dmesg | grep sda there it sees the disk.
<apw> tgardner, https://bugs.launchpad.net/ubuntu/precise/+source/wireless-crda/+bug/856421
<ubot2> Launchpad bug 856421 in wireless-crda "wireless-crda duplicates functionality found in crda+wireless-regdb from Debian" [Undecided,In progress]
 * herton -> lunch
<arges> tgardner, good morning. looking at this bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250 . I was able to reproduce on my side. It looks like wireless-n routing in the centrino chips was working in 11.04, but not in 11.10.  Looking at upstream bugs... the older firmware version seems to fix the issue. Whats a good idea for next steps?
<ubot2> Launchpad bug 836250 in network-manager "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [High,Invalid]
<tgardner> arges, regress the firmware ? is that what you're suggestuing ?
<arges> tgardner, well I will test on my laptop today. but that seems like not a good idea to regress
<tgardner> arges, I haven't checked lately. Has Intyel updated firmware for that adapter? It seems N routing is a fail on other models that use different firmware.
<tgardner> arges, what is your environment? I was not able to reproduce any N issues, but I've got quite a clean room RF wise.
<arges> well I was at my in-laws house, and they have a newer wifi router. a/g/n if I put it into a/g mode I have no issues.  If its in N mode I can connect to the AP, but pages seem to take forever to load. My chip on my laptop is a centrino ... 
<arges>  Intel Corporation Centrino Advanced-N 6205 (rev 34)
<tgardner> arges, so maybe its the compatibility mode? Pure N works OK, but a/g/n sucks ?
<tgardner> I'm not sure I tried that, but its been a few weeks
<synapse> How can I ensure that the eact same kernel will be built (except for one file I hacked) for Lucid?  I cloned teh source and want to copy /boot/config-2.6.32-35-generic to .config in my source dir, but I also want to skip make menufconfig somehow (because it seems like everytime I use that, tons of stuff is missing)
<synapse> it seems linux (2.6.32-36.79) lucid-proposed; urgency=low is what I have checked out
<cjwatson> is linux-meta going to get switched over to 3.2.0-1 in precise soon?  I'd like to get rid of a couple of the last uninstallables in precise, which that should indirectly achieve
<arges> tgardner-afk, trying to check for the latest iwlwifi firmware, but seems like intellinuxwireless.org is not responding
<ogasawara> cjwatson: am hoping to get it uploaded by EOD if not sooner.  we're looking into one additional fix to squeeze in before uploading.
<ogasawara> apw: regarding brcmsmac, looks like it was intentionally made to conflict with bcma:
<ogasawara> commit 75e07b6b2bcb1dad971870a039d5f1441e64bd58
<ogasawara> Author: Henry Ptasinski <henryp@broadcom.com>
<ogasawara> Date:   Tue Aug 23 14:13:53 2011 +0200
<ogasawara>     staging: brcm80211: only enable brcmsmac if bcma is not set
<ogasawara> apw: so it looks like we'll have to choose either one or the other
<apw> ogasawara, do we even know what the options mean, sigh
<Sarvatt> oh wow, so you only get newer hardware support for b43 or brcmsmac then?
<apw> they are starting to annoy me enough to take my machine apart and throw their crap out
<ogasawara> apw: according to Kconfig, BCMA is "Bus driver for Broadcom specific Advanced Microcontroller Bus Architecture."
 * ogasawara back in 20
<synapse> How can I ensure that the eact same kernel options/config will be built (except for one file I hacked) for Lucid?  I cloned the source and want to use /boot/config-2.6.32-35-generic as my config.
<Sarvatt> its the replacement for ssb in newer broadcom cards
<mjg59> Or remove overlapping device IDs from bcma
<apw> mjg59, yeah, is that all its about?
<herton> synapse, just follow the "Building the kernel" section at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, on your checked out tree, in case you didn't change any config option by hand
<synapse> ok, I was trying to piece together https://help.ubuntu.com/community/Kernel/Compile and it didn't really make sense for what I'm doing
<Sarvatt> dw1501/1504 (broadcom 4313/14e4:4727) is one of the more popular wifi cards in dells in the past year (because its the cheapest) and that doesn't work with b43 yet it tries to load it
<apw> Sarvatt, sigh
<cjwatson> ogasawara: ta
<apw> ogasawara, omg brcmsmac moved out of staging and into the real world
<mjg59> apw: Yup
<mjg59> Or remove the overlapping entries from brcmsmac
<apw> mjg59, any idea of that the plan upstream of if they are just throwing pies at each other
<mjg59> Right now they're throwing pies
<mjg59> I should just write a patch and see what happens
<apw> :) i guess i shouldn't be supprised
<mjg59> Actually, it's mostly just one person throwing pies
<apw> yeah i was wondering the same, fix it in some poo way and shove it over the wall
<synapse> herton: so if I follow the section that says "Modifying the configuration", it says to "fakeroot debian/rules editconfigs" which takes the current configuration (in /boot?) and uses it for the config?
 * apw tests if it fixes his broken lappy
<synapse> I dont want to modify the configuration at all
<apw> synapse, no that uses the current config in the tip of the git tree
<herton> synapse, you don't need to do anything if you're not change any config option
<apw> which is very likely the same
<herton> *not changing
<apw> synapse, you can use fakeroot debian/rules genconfigs, and check the one you have against that in CONFIGS/*
<synapse> does genconfigs use whats in /boot ?
<herton> synapse, just build, the build process will build the final config that goes into /boot, which is the same you have
<synapse> oh
<apw> synapse, no it makes human readable configs from what is in the git tree
<synapse> so skip the "Modifying configuration" section?
<apw> which u can compare against what you want it to match (which i suspect it will)
<synapse> does it diff /boot/config/2.6.32-35-generic to somewhere?  wheres the config it actually uses?
<synapse> in CONFIGS?
<herton> synapse, it doesn't use /boot, it creates the config that goes into /boot, it assembles the config from debian.master/config/ in the source tree
<apw> fakeroot debian/rules genconfigs creates human readable configs in CONFIGS/*, they are simply a convienience so you can see what will be put in the packages which is what makes /boot/* when installed
<synapse> I see, are the config options the same as what I am using now?
<synapse> so I guess I don't understand some major concept here, when I use git to check it out, all of the kernel options/config are the same as when I update using update-manager?
<apw> synapse, the git tree is the master source of the configurations as well as the code
<apw> synapse, the configurations that end up in /boot are made from teh contents of the git tree and are placed into /boot as part of installing the .deb made from the git tree
<apw> synapse, the commands above let you extract the complete configs from the git tree if that is useful
<synapse> ok, let me rephrase all of this, I don't want to change the config I am using with the kernel I currently am running at all
<ppisati> when an SRU kernel fails some tests, what do we do? i mean, do a open a new bug for every problem found?
<ppisati> s/a/we/
<apw> synapse, then you need to compare it to whats in the git tree and fix any differences, though if its a stable release its most likely the same
<synapse> can't I just copy it over from /boot ?
<synapse> I am running #78 right now, #79 is what I checked out
<apw> synapse, if you really mean "i want whatever ubuntu will be using in the next update" then whats in the git tree is already that
<apw> synapse, the tree is configured the way it will be in the next release, its a full ubuntu configuration
<apw> (next release in the series you have chekced out)
<synapse> so when I get kernel image/header updates via update-manager, it doesn't rely on applications I already have installed at all, just uses the config in the git tree?
<smb> synapse, If you want exactly what was in that release then do a "git checkout Ubuntu-2.6.32-35.78" then the tree and the configuration files that are in that tree will get you the identical kernel packages when compiled
<synapse> thats the answer I needed :)
<apw> synapse, yes the kernel configuration is unrelated to what is on your machine, it is only specific to the kernel
<synapse> so wait, I should do a git checkout Ubuntu-2.6.32-35.78 ?
<synapse> Im totally lost
<apw> synapse, that is exactly the source which was used to make the source pacakge for the upload with version 2.6.32-35.78 
<herton> ppisati, are you referring to the ti-omap4 on maverick tests? I guess only one bug opened would be sufficient (different from the tracking bug), so it's referenced in the SRU patches and can be verified later
<synapse> so inside my source dir (after cloining), I run git checkout Ubuntu-2.6.32-35.78 ?
<synapse> cloining/cloning
<smb> synapse, If you cloned the ubuntu-lucid.git repo
<apw> that would do it
<synapse> yeah
<synapse> so I got "HEAD is now at 03b97f3... UBUNTU: Ubuntu-2.6.32-35.78"  
<synapse> now just build/install ?
 * apw is unsure why you'd want to just build what you already have
 * smb was sort of thinking the same
<synapse> thats what I'm trying to do!
<synapse> and keep getting different people telling me different steps to take
<synapse> so I'm lost
<smb> synapse, if you run the build as described in https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<smb> you will get packages that should be exactly what you got installed already
<synapse> ok
<apw> and expect it to take hours unless you have a monster machine
<synapse> it takes 41 mins the last time I built
<apw> then you have something reasonably big
<synapse> I just hope it boots
<apw> synapse, i suggest you make sure you have an older known working kernel to fallback on before you install your replacements
 * apw suspect he doesn't want to know why you want to build and replace what you have with identicle ones
<synapse> well, I have that now
<synapse> FYI, thanks for the help.
<ppisati> herton: so, a generic bug with an excerpt with all the failed tests is enough?
<ogasawara> tgardner: just fyi, testing precise rebased to latest upstream tip seems to resolve suspend/resume on hp-mini
<herton> ppisati, I think so, don't see a reason to have separate bugs, just extra work
<tgardner> ogasawara, thats good to hear. any idea what the fix was ?
<ogasawara> tgardner: not specifically, just noticed a few power management related fixes so decided to give it a try.
<tgardner> ogasawara, test kernel somewhere ?
<ogasawara> tgardner: on gomeisa
<ogasawara> tgardner: in the precise-i386 dir
<tgardner> ogasawara, my box is 64 bit. guess I'll spin a kernel. have you pushed the recent rebase ?
<ogasawara> tgardner: I haven't, was going to wait till -rc3.  but I suppose it won't hurt to just push it to master-next.
<tgardner> ogasawara, taht would be good. I don't think you need to tag it
<ogasawara> tgardner: ack
<arges> tgardner, might have got cut out earlier. looking at that centrino wifi issue. I will test with/without n again, in addition I will look and see if older firmware issues fix things. Any set of tests/tools I should be running for wireless to help verify its working correctly?
<tgardner> arges, I use iperf which will give you performance metrics
<arges> tgardner, ok will do that thanks!
<apw> ppisati, i assume you are owning precise ti-omap4 kernels, and handling any security poop we dump on oneiric if its applicable ?
<ogra_> stop dumping poop on us !
<ogra_> :)
 * apw makes a note, no security fixes for arm
<ogra_> lol
<synapse> :~/source_backup/debian/linux-image-2.6.32-36-generic/boot$ diff config-2.6.32-36-generic /boot/config-2.6.32-35-generic  <- shows no differences
<synapse> :)
<synapse> except the kernel version
<ppisati> apw: as long as we don't get any 3.2 TI BSP, i will import O/omap4 in P, so we will get that for free
<ppisati> apw: in short, yes
 * sforshee goes to run an errand, back in about 30 minutes
<apw> ppisati, ok so i can ignore P arm for now then for security at least, thanks
<ppisati> bug 893190
<ubot2> Launchpad bug 893190 in linux-ti-omap4 "Qa-testing failures for 2.6.35-903.27" [Undecided,New] https://launchpad.net/bugs/893190
<ppisati> herton: ^^
<synapse> apw: I am on section "Building the kernel" and it wants me to install the .deb images/headers, but I don't see them.. do they reside in debian/linux-image-2.6.32-36-generic?
<apw> synapse, ?  i am not sure i expect you to install them to build them, that doesn't seem right
<tgardner> synapse, ls ../*.deb
<apw> ahh after building, yes in the directory above
<synapse> oh, it moves them out of the root dir
<apw> it puts them where the build expects to find them
<synapse> so I have linux-headers-2.6.32-36_2.6.32-36.79_all.deb, linux-image-2.6.32-36-generic_2.6.32-36.79_amd64.deb, linux-headers-2.6.32-36-generic_2.6.32-36.79_amd64.deb and linux-tools-2.6.32-36_2.6.32-36.79_amd64.deb  ... just issue sudo dpkg -i linux-*.deb to install and reboot?
<herton> ppisati, ok, you can use buglink for this bug when you drop the fixes for review, and we tag for verification later when pushing the fixed kernel
<apw> synapse, you need the two headers and the image only, but other than that yes
<tgardner> synapse, you only need linux-image 
<apw> (you only need the headers if you have dkms packages installed)
<synapse> can I just issue dpkg -i against them all?
<synapse> any harm done?
<synapse> or skip tools
<apw> no it should be safe, just not necessary if you don't need them
<synapse> does it modify grub for me?
<synapse> that document needs updated to say you need to sudo apt-get install linux-tools-common or it errors out on the install
<synapse> ok, here it goes, rebooting, brb (I hope)
<synapse> Linux darkside 2.6.32-36-generic #79 SMP Mon Nov 21 11:16:56 EST 2011 x86_64 GNU/Linux
<synapse> :)  thanks all
<apw> cirtianly not one of our builds
<synapse> hehe
<synapse> now time to try what the heck it was I was doing
<synapse> whats the easiest way to change "generic" to something else? 
<apw> synapse, there is no real way to change flavour names, they appear all over the place
<apw> it is a matter of finding the places it already appears, and the files with it in the name
<synapse> well, thanks to your help, I was able to add support for the Roland Gaia synthesizer in linux now :)
<synapse> since Roland doesn't want to release drivers for linux (win/mac only), I added a usb quirks table entry and now have ALSA support for usb audio and midi in/out
<apw> synapse, you should send that upstream
<apw> so it ends up in the real kernel sometime
<synapse> I will be, I'm submitting it to the alsa-devel folks for review, I have some more tweaks to make
<synapse> I am amazed this worked
<apw> ogasawara, ok so i ripped out the 'stop brcmsmac' change and now my wireless is working
<ogasawara> apw: ack, want to just push it to master-next
<ogasawara> apw: also, I'll be away on Fri, could you stand in for me at the release meeting
<apw> ogasawara, am thinking about whether we should be doing that for now, or fixing it better, perhaps this is ok as its only as bad as it was before
<apw> ogasawara, i suspect wl is still needed for a number of older devices
<tgardner> ogasawara, apw: I think we should prefer the brcmsmac solution since I believe we'll get better results from Broadcom as an upstream.
<ogasawara> apw: it's no more offensive than it was before, so I say push it
<apw> tgardner, yeah they do seem to have pushed it into mainline ok, so they obviously are trying at least
<apw> and it sounds like they are going to allow coexistance in the end
<ohsix> i still use wl on my netbook, it's an lpphy model that's not supported at all on the new, and not very well on the b43 driver (it overheats and fails in neat ways)
<tgardner> apw, Broadcom is also paying engineers to work on it full time
<apw> we have two choices, allow both and cross fingers, or unpick the duplicates
<tgardner> apw, pull the duplicates from b43 ?
<apw> ogasawara, ok so i'll push my bodge for now, and we can look to unoverlap them if upstream doesn't sort their shit out
<ogasawara> apw: ack, sounds good
<apw> tgardner, yeah that probabally the better solution overall
<apw> there is something in the changelog that implies they are working out how to use the common underlying layer
<ogasawara> apw: was tseliot looking into the wl issue?
<tgardner> apw, yeah, but taht ain't gonna happen for 3.2
<synapse> apw: one last quick question, if I want to rebuild, can I just run fakeroot debian/clean ?
<apw> ogasawara, yep i believe he is doing so yes
<synapse> and start all over?
<apw> synapse, yes
<synapse> thanks so much
<synapse> take care
<apw> ogasawara, i think wl is pretty fixable, i think we removed the need for something so we can just drop it from wl too
<tseliot> ogasawara, apw: yes, sorry, I've had a hardware failure and I'm dealing with that first (fortunately I had backups)
<ogasawara> apw: cool, so it should be fixed relatively soon.  in that case, I'm going to upload the brcmsmac fix, then upload linux-meta.
<smb> apw, Just a word of safety (probably not needed if the newer drivers are any better). But with some broadcom the b43 did seem to work but was a nightmare to work with (lots of dropped connections)
<apw> tseliot, nasty and a timely reminder for the rest of us
 * tseliot nods
<apw> tseliot, yeah if we can get teh wl fixes in soon that'll make people happier
<ohsix> smb: does it "feel" like temperature problems or have you not experienced them yourself, cuz it really feels like it's a temperature thing on mine, it will work for say 2 hours; then it will just stop working, unloading & reloading the module would get you a few more minutes
<apw> ogasawara, ok utter bodge pushed 
<tseliot> apw: I know but I'm afraid I won't be able to do it today
<ohsix> and last i looked theres not much accounting at all for temperature, the phy especially operates at a certain temperature and will start failing if it overheats
<apw> tseliot, no worries :)
<smb> ohsix, It may be that too. I only had it up for a bit and then got annoyed and replaced it with wl again
<tseliot> apw: but I'll focus on it tomorrow
<ogasawara> tseliot: thanks
<apw> ogasawara, we should know before you upload meta whether wl is easy to fix
<ohsix> i already helped some linux-wireless guys fix the sprom problem i had on mine, but i didn't use b43 much longer after that, due to the aforementioned problem
<apw> tgardner, i will add a todo to unoverlap the two driver id lists preferring the brcmsmac where they overlap
<ohsix> smb: part of the discussion of the new bcrmsmac or whatever drivers, the broadcom guys alluded to temperature & test parameters being in the newer drivers and basically ignored in b43
<tgardner> apw, ack
<apw> tgardner, or we could simply add a blacklist for b43 while we are at it
<apw> so people have to 'flip the two lines' there to get the other
<tgardner> apw, um, won't that involve user space changes? I think we should just fix the PCI IDs
<apw> tgardner, yep, though it might makse sense as it does allow easy testing of b43 for specific overlaps
<smb> ohsix, Thanks for the info. I will see to get some precise level install and testing on the laptop in question
<ohsix> neat, no problem
<apw> tgardner, whatever did come of the plan to move blacklists into the kernel package
<tgardner> apw, I'm not remembering that. would the blacklists be unique to teh kernel version? I think they would have to be
<tgardner> having the blacklists in the kernel does kind of make sense
<apw> right and i think that is why scott wanted to shove them over, never happened of course
<apw> sounds like a P think
<apw> thing
<tgardner> make it a TODO item?
<apw> adding it now
<tgardner> I wonder if modprobe has support for something like that?
<ohsix> smb: there are on device temperature probes  but i didn't look into logging them or  how to access them, haven't looked at bcrmsmac at all really
<apw> i suspect it likely doesn't but it cann't be hard to add
<ohsix> since they already have tested tables or at least something like that in the new drivers for at least the ones it supports, you'd probably just move that to the shared phy code in the end
<smb> ohsix, Yes, I don't see much sense in trying to spend too much effort in investigating something that might just work with the new drivers. I'd expect b43 just to loose more and more responsibility
<ohsix> the one device i have isn't in the new driver though, and i don't know who if ever would be the person to add it
<smb> ohsix, I have not looked but it sounded those moved into the main tree now (from staging), so MAINTAINERS should have something...
<ohsix> mines the bcm4312
 * apw has a bcm4313 which brcmsmac seems to support
<iceroot> downloading the kernel with apt-get source, patching one file and then building the kernel would be the exact same kernel i get with apt-get install + my patch on that kernel?
<ohsix> lucky :] i get the impression that the one in my netbook was already a bit undersupported by the time it was used in the machine
<iceroot> so the build-process will include the ubuntu-config and ubuntu-patches?
 * smb seems to have the same bcm4312, so probably still wl time for that one
<jsalisbury> ogasawara, can I get your opinion on bug 892675  Do you think this is a packaging issue?
<ubot2> Launchpad bug 892675 in linux "include/linux/usb.h missing" [Undecided,Confirmed] https://launchpad.net/bugs/892675
<ogasawara> jsalisbury: sure, I'll take a look in a bit.
<jsalisbury> ogasawara, thanks
<ohsix> getting the firmware to use b43 is sort of annoying too, but that's done automatically now
<tgardner> ogasawara, I bumped ABI and folded it into 'Ubuntu: rebase to 6fe4c6d4'
<ogasawara> tgardner: cool, thanks.  just saw my test build failed.
<tgardner> as did mine
<apw> tgardner, do i expect to see WPA rekeying as a disconnect reconnect? 
<apw> ogasawara, does your hp shutdown ok, regarless of s/r ?
<ogasawara> apw: lemme test, just a sec
<tgardner> apw, I believe it has to since its part of the authentication phase, but I'm not absolutely positive.
<ogasawara> apw: yep, shutdown fine just now (but I'm running the newly rebased kernel)
<apw> ogasawara, ok mine is not on the original by the looks of it
<AndrePT> Hello, I have a problem booting the Kernel on my laptop. After searching on the Ubuntu wiki, I added the needed flags to my grub parameters and found this message: [0.292266] pci: 0000:00:09.0: address space collision: [mem 0x00007800-0x0000787f] conflicts with [mem 0x00000000-0x0000ffff] . After some more testing I found that this problem started happening since 10.04 (I am currently on Oneiric and booting from 9.10's Kernel). Other di
<AndrePT> stributions such as Debian-Testing work fine. I am using x86. x64 Kernels boot fine but have wi-fi problems. Any ideas/any more information I can contribute? Thanks.
<apw> AndrePT, getting a bug filed would be the first thing, and then trying to work out the exact version where the change occured next
<AndrePT> Where can I find older (alpha/beta) Ubuntu builds? I think it happened during alpha 1 stage but I don't want to be that sure.
<apw> AndrePT, all of the previous builds are in the launchpad librarian, /me gets the urls
<apw> https://launchpad.net/ubuntu/+source/linux
<apw> AndrePT, the full publishing history has links to all the versions
<AndrePT> very well then, I guess I'll have to start looking here: https://launchpad.net/ubuntu/lucid/+source/linux .
<AndrePT> by the way, before I reboot, when this happens, not even REISUB works to safely reboot the laptop. isn't there any other way other than forcing a shutdown?
<apw> AndrePT, nope, if reisub doesn't work then you are dead
<AndrePT> as I expected. Okay, time to test the first of the 2.6.32 series.
<iceroot> what is the difference in "apt-get source linux-image-$(uname -r)" and "apt-get install linux-source-3.0.0"
<iceroot> i want to patch the "stable"-ubuntu-kernel and i am not sure which source-code i need. atm i am trying the source-package.
<iceroot> i am searching a/drivers/net/wireless/rt2x00/rt2800pci.c (http://article.gmane.org/gmane.linux.kernel.wireless.general/80759) but cant find it in the source-package
<AndrePT> alright, I am back, and that was quick. The problem appears right at 2.6.32-2-generic-pae .
<iceroot> cant find the file :( then i guess its up to the ubuntu-kernel-devs to test the patch for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502
<ubot2> Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
<apw> iceroot, one is just the source code, the other is the packaging included.  you would normally want to start with the git repo
<iceroot> apw: ok
<apw> AndrePT, so its not in -1 but is in -2 ?
<apw> 2.6.32-2.22.6.32-rc5
<apw> 2.6.32-1.12.6.32-rc5
<apw> bah, if the spaces were in there those two have the same base versions
<AndrePT> according to https://launchpad.net/ubuntu/lucid/+source/linux , 2.6.32-2.2 is the first of the 2.6.32 series. The other one is 2.6.31-14.48. I am running 2.6.31-23
<apw> AndrePT, odd we have a tag for but no builds for -1.1
<apw> AndrePT, so is your laptop unbootable with these later kernels ?
<AndrePT> yes.
<apw> AndrePT, have you tried anything newer than .32 kernels
 * tgardner -> lunch
<AndrePT> apw, yes, and as stated before, non-ubuntu distributions work with mixed results. Debian-testing (3.0.0-1) works but nvidia drivers don't compile for it, leaving me in a text environment; fedora 14 worked, 15... meh, openSUSE is fine, Sabayon is fine, Linux Mint (Ubuntu derivated) fails, so does xubuntu.
<apw> AndrePT, and our 3.0 kernels do not work
<AndrePT> they don't. in fact my latest attempt was with the 3.2.999 mainline kernel. The one packaged in Oneiric didn't work as well but I don't know the version.
<apw> AndrePT, anyhow the right thing to do is get that bug filed with all the ones you have tested both for ubuntu and not, listed with what works and what does not
<apw> so we can try and work out what the pattern is
<AndrePT> will do, I'll post it here before I post it on launchpad. thanks.
 * apw wanders off
 * herton reboots
<arges> sforshee, hey, was there a file that we could check to see if a sandybridge laptop's onchip graphics had locked up ?
<AndrePT> apw, the bug is posted: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893269
<ubot2> Launchpad bug 893269 in linux "kernel fails to boot: pci: 0000:00:09.0: address space collision: [mem 0x00007800-0x000078ff] conflicts with reserved [mem 0x00000000-0x0000ffff] since 2.6.32-2 " [Undecided,New]
<arges> found the answer
 * cking wanders away
 * herton -> eod
<iceroot> after some fights with git, the kernel himself and so on i am ready to build my own kernel. what version do you suggest? linux (3.0.0-13.22ubuntu1) oneiric; urgency=low
<iceroot> i am building it for my own and others to test something. is the ubuntu1 ok? or should i use .23? what when ubuntu releases its .23? maybe using .99?
<iceroot> my fault...because of "the answer to life, the universe and everything" of course i have to use 3.0.0-13.42
<tgardner> ogasawara, have you installed a test kernel with 'UBUNTU: [Config] Replace wireless-crda with crda,wireless-regdb' applied ?
<ogasawara> tgardner: not yet, just test built
<ogasawara> tgardner: I did just upload but left that patch on master-next
<tgardner> ogasawara, its giving me some fits. I think the depends are too strict.
<tgardner> lemme fix 'em
<ogasawara> tgardner: ack
<tgardner> ogasawara, pushed. we may have to fiddle with it a bit yet, but this ought to at least allow you to install.
<ogasawara> tgardner: cool, thanks
 * tgardner -> EOD
#ubuntu-kernel 2011-11-22
<cjwatson> ogasawara: heads-up on bug 893395
<ubot2> Launchpad bug 893395 in linux "ext2 modular in precise but missing from fs-core-modules" [Undecided,New] https://launchpad.net/bugs/893395
<cjwatson> shame I missed today's upload
<ogasawara> cjwatson: pushed a fix for 893395, I'll upload once the current upload finishes building (eta 5hrs). will then get linux-meta uploaded as well.
<smb> morning .+
<abogani> morning
 * apw waves weakly
<ppisati> smb`: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/kernel/guard-page/split-stack.c
<ppisati> smb`: do you remember if it relates to a CVE or a particular kernel option?
<smb> ppisati, it had to do with a cve, but I cannot remember exactly what/which
<ppisati> smb: found
<ppisati> smb: https://bugs.launchpad.net/ubuntu/jaunty/+source/linux-mvl-dove/+bug/646114
<ubot2> Launchpad bug 646114 in linux "mlock on stack will create guard page gap" [Undecided,Fix released]
<smb> ppisati, Well, I believe that was a problem introduced by the attempted fix for the other problem
<smb> The guard page thing was supposed to prevent some bad collision but unfortunately the way this was shown to user-space was one-off (or so)
<smb> Hm, actually might have been that if the area was spanning more than one vm area the guard page hole was presented for each area
<smb> which is a lie for anything but the lowest (if your stack grows downwards)
<ppisati> smb: ok, seems to be 28d2e371327c8961ae593e1a3e275df32b35dd7d maverick/master
<smb> ppisati, That was the fix. It started with 52423b90e1f5b1bdbbcc6e32f4d37ada29b790c4
<smb> ppisati, CVE-2010-2240
<ubot2> smb: The do_anonymous_page function in mm/memory.c in the Linux kernel before 2.6.27.52, 2.6.32.x before 2.6.32.19, 2.6.34.x before 2.6.34.4, and 2.6.35.x before 2.6.35.2 does not properly separate the stack and the heap, which allows context-dependent attackers to execute arbitrary code by writing to the bottom page of a shared memory segment, as demonstrated by a memory-exhaustion attack against the X.Org X server. (http://cve.mitre.org/c
<ppisati> cool, i'll import it
<ppisati> btw, does that mean that secuiry test routine were not run on arm branches?
<ppisati> but first, lunch! :)
<smb> ppisati, We do security on arm? :-P
<smb> Well it should be in there
<ppisati> well, it seems we just started to do security on arm... :)
<smb> The CVE required a whole bunch of changes but for Maverick those seem to be in from upstream stable
<smb> It turned out that the minimal invasive patch was a maximum pain in the butt
<ppisati> sounds like something to remember... :)
 * smb does not think that anything minimal invasive exists in memory management...
<ppisati> smb: well, but you made my facebook status quote :)
 * smb tries to hide
<apw> ppisati, so did someone in qa just bring up that security failure ?
<apw> ppisati, cirtainly in the early days we didn't record derivative branches as well as we do now, and so they had not CVE tracker entries and didn't get updated always; and once missed that was it
<herton> apw, bug 893190 (first reported on tracking bug 888569)
<ubot2> Launchpad bug 893190 in linux-ti-omap4 "Qa-testing failures for 2.6.35-903.27" [Undecided,New] https://launchpad.net/bugs/893190
<ubot2> Launchpad bug 888569 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.35-903.27 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/888569
<apw> so it must be new testing i suspect then, a good thing if a little late
<apw> herton, but if it is a missing CVE which simply is not applied to that branch, then its not a regression
<herton> indeed, I guess that's it also
<apw> herton, and we'd not necessarily want to hold the update.  the previous release is as bad
<herton> apw, I was thinking about it as well, that's true, shouldn't hold if not a regression. If GrueMaster can confirm is not a regression, we could go forward with the update and release it
<apw> ppisati, is this just a cve we have missed on this branch, ie are the fixes simply missing?
<apw> herton, if that is a yes ^^ then its defnatly not a regression
<apw> let me know if so so i can get the security team to pull that entry back from retired for the matrix too
<herton> ok. There is more 1 test failure on the report, not sure if they are all missing cves, but if not a regression on all then ok
<herton> *more than 1
<apw> ahh ok, so ppisati any cves we find missing via this testing i need the numbers for to reopen the CVEs
<smb> From past experience it can be worth looking at the failed test closely since some are doing statistical checks and sometimes those were to tightly checking
<smb> (like the stack randomization checks)
<apw> yep there is that, for the random placement checks they are poor
<apw> and can fail once in a while without being broken
<smb> Yep, I guess with less memory random place is less random than with more...
<apw> i believe that arm has less bits to be random with iirc
<ogasawara> apw: would you be able to stand in for me at the release meeting on fri
<apw> ogasawara, sure, i think there is a change to how its done which you'd have to get me up to speed on
<ogasawara> apw: yep, we send out our team specific bits to the ubuntu-release mailing list ahead of time.  then the meeting is just any follow up Q&A for what we sent out.
<apw> ogasawara, and we chose the bugs for the list as well ?
<ogasawara> apw: yep
<apw> how we been picking them
<ogasawara> apw: apw: I'll go ahead and send out the email to ubuntu-release.  that way you can just sit in on the meeting.
<apw> are we relying on jo for that, or do we have a tag
<apw> ogasawara, ok fair enough
<ogasawara> apw: mainly relying on the rls-p-tracking tag
<ogasawara> apw: but we're responsible for putting that on the bugs
<ogasawara> apw: but since we've just uploaded a 3.2 kernel, I haven't been real aggressive with using the tag just yet as it's not clear if some of the bugs will resolve themselves with the newer kernel.
<ogasawara> apw: but I've been keeping an eye on some, which I'll list in the email.
<apw> yeah for sure, till that mess is in and stable we're spinning wheels
<ogasawara> apw: I also uploaded a new 3.2.0-1.3 to fix up bug 893395
<ubot2> Launchpad bug 893395 in linux "ext2 modular in precise but missing from fs-core-modules" [Critical,Fix released] https://launchpad.net/bugs/893395
<ogasawara> apw: once that builds I'll hopefully want to upload linux-meta finally
<ogasawara> tseliot: were you able to take a peek at wl?
<apw> ogasawara, yeah saw that on irc scroll back, a good decision me thinks
<tseliot> ogasawara: I'm working on it as we speak. I think I've found the change that causes the build to fail. I have to see if this is the only change though
<ogasawara> tseliot: great, thanks.  please keep us posted.
<tseliot> ogasawara: sure
<ogasawara> jsalisbury: think you'll you be ready to pick up chairing the weekly IRC meeting next week?
<tseliot> ogasawara, apw: my patch at least allows the module to build. Now I only need to test it on a device with broadcom
<apw> sounds good
<tseliot> now remembering which one of the bazillion devices that I have around has broadcom is the main problem ;)
<jsalisbury> ogasawara, yes, next week is good for me
<ogasawara> jsalisbury: and I haven't forgotten about the bug you pinged about yesterday, will get to it soon
<jsalisbury> ogasawara, cool.  thanks
 * herton -> lunch
 * ogasawara back in 20
<TeTeT> apw: thanks for the dpms suggestion for the random freezes!
<apw> hey np
 * tseliot has finally found a device with a broadcom chipset \o/
<mdeslaur> herton: is this table accurate? https://wiki.ubuntu.com/Kernel/Dev/ABIPackages
<mdeslaur> herton: is that what you use, or do you have a more authoritative source?
<herton> mdeslaur, yes, it's the official source
<mdeslaur> herton: ok...can I correct everything that's inaccurate in it then?
<herton> mdeslaur, yep
<apw> ogasawara, we need to add a WI to update the above page and its friends when we are about to release, by kernel freeze we should know i'd think
<apw> ogasawara, with our standard ones like emailing out the config
<tseliot> apw, ogasawara: unfortunately the only laptop (that works) which has a broadcom card only uses the open driver. I think the laptop that I used for testing is the one with the dead monitor...
<apw> tseliot, if you have .debs i have brcm that works with wl i believe
<tseliot> apw: sure, for amd64?
<apw> sadly its 32bit
<tseliot> apw: ok, let me create a 32bit chroot then
<apw> tseliot, hang on
<apw> tseliot, its a dkms package, isn't it an _all ?
<tseliot> apw: no, as we only support i386 and amd64
<tseliot> unfortunately
<apw> tseliot, but the package would be identicle, as in its not a binary package?
<tseliot> apw: the makefile is patched so that the right binary is used according to the architecture
<apw> tseliot, yeah i mean if i just force the xmd64 binary on it'll work right ?
<tseliot> there are separate binaries in the same package for the two archs
<apw> oh ick ok, i'll shut up now
<apw> ogasawara, is the meeting in an hour ?
<ogasawara> apw: yep
<apw> you or joe?
<ogasawara> apw: me.  joe will take over next week.
<tseliot> apw: even if you force the installation I think dpkg --print-architecture would report the right architecture and things should be fine
<tseliot> apw: so it's probably worth trying
<tseliot> (the makefile is called by DKMS)
<apw> tseliot, can do if you point me to a binary
<tseliot> apw: sure let me upload the deb file
<tseliot> apw: http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu1_amd64.deb
<tseliot> apw: no, wait
<tseliot> it won't work
<apw> tseliot, /me waits
<tseliot> apw: some files are renamed when the package is built, therefore it's not gonna work
<apw> tseliot, ok
<tseliot> apw: hopefully my chroot will be ready in a few
<apw> ok
<tseliot> apw: the creation of an i386 chroot failed (because of perl...). I'm using my Lucid 32bit chroot
 * tseliot keeps his fingers crossed
<apw> heheh
<ppisati> i didn't see the usual kernel meeting warning
<ppisati> it's still scheduler in 30mins, right?
<ppisati> *scheduled
<apw> ppisati, indeed should be, ogasawara did we miss a 1hr warning?
<ogasawara> yah, got sidetrack and didn't spam the channel
<ppisati> np
<ogasawara> ##
<ogasawara> ## Kernel team meeting today @ 17:00 UTC
<ogasawara> ##
<cking> eek
<apw> (that is in 30 minutes people)
<smb> he lives...
<cking> who me?
<smb> yes
<smb> :)
<cking> I've been grinding data all day
<apw> cking, i expect you have half a dozen reports for the thing right ?
<cking> I'm still working on it
<smb> I guess the meeting will take then a bit longer than usual... :)
 * cking keeps on finding weird corner cases which need double checking
<GrueMaster> herton, apw.  Not a regression, definately.  I was just recently able to get the qrt kernel tests working on armel w/o a lot of false positives. 
<apw> GrueMaster, ok cool, herton that sounds like we can at least release it
<ogasawara> jsalisbury: just fyi, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/892675/comments/2
<ubot2> Launchpad bug 892675 in linux "include/linux/usb.h missing" [Medium,Invalid]
<apw> ppisati, we do need to get a list of all the CVEs which are truly not fixed on there so i can get them active again
<herton> yep, GrueMaster can you tag it passing qa on the maverick ti-omap4 bug? ppisati opened a new bug to work on the failures
<GrueMaster> Will do.
<jsalisbury> ogasawara, thanks!
<ppisati> apw: so far, only 1 seems good and it's not a CVE
<ppisati> apw: it's a fix for the fix of a CVE
<apw> ahh, it should probabally have had a CVE number and didn't
<ppisati> apw: 2 of the failing tests seem not applicable to maverick/omap4
<tseliot> apw: http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu1_i386.deb
<ppisati> apw: and now i'm looking atthe last one
<apw> ogasawara, as the reporter is mentioning /usr/include those would be the copies in linux-libc-dev, are they in there too ?
<GrueMaster> There is one test that is failing (/dev/mem) that needs more research, but I am not counting it in the test failure results yet.
<apw> ogasawara, and indeed on my precise install there is no /usr/include/linux/usb.h
<ogasawara> hrm, /me double checks
<apw> ogasawara, that it _is_ in headers and not linux-libc-dev doesn't mean its meant to be in /usr/include of course
<apw> there is a process in the kernel to copy it over ...
<apw> ogasawara, i can take a look if you like
<ogasawara> apw: sure, go for it
<ppisati> GrueMaster: SECCOMP and STRICT_DEVMEM are not applicable to that release
<ppisati> GrueMaster: i sent you a test kernel for the mlock split stuff
<ppisati> GrueMaster: and the only missing part are the PTRACE* checks
<GrueMaster> ppisati: Not seeing a kernel link
<ppisati> GrueMaster: i sent it in #ubuntu-arm
<ppisati> GrueMaster: anyway
<ppisati> GrueMaster: http://people.canonical.com/~ppisati/linux-image-2.6.35-903-omap4_2.6.35-903.27~mlockfix_armel.deb
<ppisati> GrueMaster: this should fix the
<HadiM> hi
<ppisati> GrueMaster: "Make sure the stack guard page does not split the stack on mlock ... FAIL"
<ppisati> GrueMaster: in test-kernel.py
<HadiM> I dont find iwlwifi / iwlagn modules in 3.2 ubuntu kernel
<HadiM> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/
<HadiM> is that normal ?
<HadiM> (sorry if I am on the wrong channel)
<ogasawara> HadiM: not sure about the mainline build (which is the url you posted), but I'm using the iwlwifi driver right now on a 3.2.0-1.2 Ubuntu kernel
<ogasawara> modinfo iwlwifi
<ogasawara> filename:       /lib/modules/3.2.0-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko
<HadiM> 32bit or 64 ?
<ogasawara> HadiM: 64
<HadiM> ok same here
<HadiM> I double check the deb
<HadiM> in the url I gave you the kernel name is 3.2.0-030200rc2-generic/
<apw> ogasawara, when you did the rebase did you notice anything about those changing name
<HadiM> and there is no iwlwifi dir in /lib/modules/3.2.0-030200rc2-generic/kernel/drivers/net/wireless/
<ogasawara> apw: not that I'm aware, but tgardner did the original v3.2-rc1 rebase
<HadiM> oh youre using the precise kernel build
<ogasawara> HadiM: right
<HadiM> I suppose it is not the same as http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/
<HadiM> thats strange
<HadiM> I will try the precise build on my oneiric
<ogasawara> HadiM: that url is to the upstream vanilla v3.2-rc2 kernel.  although I'm not sure why it would be missing there.
<apw> tseliot, on it
<HadiM> it is missing in 3.2 rc1 and rc2 for sure
<tseliot> apw: thanks
<GrueMaster> ppisati: Your kernel fixes that bug, but it must be an older spin.  It is giving me a different mac on boot, and the eth0 is now usb0.
 * apw notes a netbook is not the speedyiest
<ppisati> GrueMaster: no, i put the patches on top of maverick/omap4 tip
<GrueMaster> Well, system came up with a different mac, so not sure what is different.
 * ppisati notes kernel.ubuntu.com is dead slow...
<ogasawara> meeting time...
<smb> already
<ppisati> GrueMaster: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
<ppisati> GrueMaster: latest 4 patches are the fix
<ppisati> GrueMaster: and are on top of the rest
<GrueMaster> Well it is failing my testmac test, which enables/disables the ethernet port 10 times and compares mac addresses in between.  I can't reach the system now until dns catches up with dhcp (I'm remote and the system is at home).
<GrueMaster> Wait, I think I see the problem.  It isn't polling the die id.
<GrueMaster> Let me reboot to the proposed kernel and verify.
<GrueMaster> ppisati: Sorry, I guess I just never noticed it before.  I don't think 2.6.35 polls the die id for the mac address.  nevermind.
<GrueMaster> I usually run sru tests on it locally.
<apw> tseliot, not looking good on my machine here ... seems to partially think its a wired network and generally doesn't connect
<jsalisbury> ogasawara, followed along ok.  I should be fine to take over next week.  Will you update the runes file to include ckings power topic?  Or should I do it when updating it from the agenda next week?
<ogasawara> jsalisbury: I'll go ahead and update it
<tseliot> apw: did you reboot?
<jsalisbury> ogasawara, cool, thanks
<apw> tseliot, yep
<ogasawara> jsalisbury: I'm also thinking it would probably be good for you to take over reporting the "[TOPIC] Release Metrics and Incoming Bugs"
<jsalisbury> ogasawara, sure
<apw> tseliot, also hand blacklisted the kernel modules which pick up this device otherwise
<ogasawara> jsalisbury: it's just a copy and past of http://people.canonical.com/~kernel/reports/kt-meeting.txt
<jsalisbury> ogasawara, ok
<ogasawara> jsalisbury: if there are any other bugs which you want us to look at as well, that's probably a good time time to raise them as well.
<jsalisbury> ogasawara, good idea.  I can add a reminder about the hot list.
<tseliot> apw: I also updated the driver to a new release, so maybe we're facing 2 different problems here. I could write a patch against the old driver and see if it helps
<apw> tseliot, ok whatever you think
<apw> cirtainly something is odd cause nm is mistaking it for a wired port
<apw> tseliot, though i have no idea how nm knows what sort of port any port is
<tseliot> apw: this is all I did: http://pastebin.ubuntu.com/746118/
<apw> yeah seems unlikely that would fookulize everything else, so we must suspect the new driver
<tseliot> apw: right (hopefully). Let's see if the old driver works
<tseliot> apw: is this any better? http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu5_i386.deb
 * ppisati -> eod
<apw> tseliot, ok with that one, after a reboot i get what appears to be working wiki
<apw> wifi, done a bit of surfing so far, nothing hardcore
<tseliot> apw: \o/
 * apw watches a movie on it
<tseliot> apw: ok, I'll keep the old driver with my patch on top
<apw> tseliot, seems like a good first step to me
<tseliot> apw, ogasawara: ok, I've just uploaded the broadcom driver with my patch (in Precise)
<ogasawara> tseliot: awesome, thanks
<tseliot> yw
<tseliot> apw: thanks for testing
<apw> tseliot, thanks for fixing :)  at least we have a full set of binary drivers before the kernel goes live, that must be a first
<tseliot> apw: hehe, nice :)
<iceroot> is it possible to build an amd64-kernel on an i386-cpu without amd64-instructions?
<iceroot> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502/comments/118  then i can provide here the amd64 version too
<ubot2> Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
<iceroot> atm i am using skipabi=true skipmodule=true fakeroot debian/rules binary-iceroot and that is building i386 here
<ogasawara> smb: thanks for your review, I've reverted the "UBUNTU: SAUCE: xen: Do not use pv spinlocks on HVM" patch on Precise master-next.  I'll rebase it out of existence at the next rebase.
<cdhm> Hi. I have done a lot of kernel building, but not withinb Ubuntu. What I want to do is build logfs as a module and load it.
<cdhm> There are a lot of howtos, each different, and different for various versions. So here is what I did:
<cdhm> mkdir /opt/ubuntu-kernel-src
<cdhm> cd /opt/ubuntu-kernel-src
<cdhm> sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r)
<cdhm> apt-get source linux-image-$(uname -r)
<cdhm> cp /boot/config-2.6.38-12-generic-pae  .config 
<cdhm> make; make modules_install
<cdhm> That unfortunately builds and installs modules for 2.6.38.8 and not 2.6.38-12-generic-pae
<cdhm> Hints??
<tgardner> cdhm, make oldconfig scripts prepare; make M=`pwd`/fs/logfs
<tgardner> cdhm, oh, first do 'fakeroot debian/rules prepare-generic-pae;cp debian/build/*/.confg .'
<cdhm> tgardner: So what's the order of operations... do the apt-gets, then do the fakeroot thing, then the make config, then make changes to .config to turn on CONFIG_LOGFS then make logfs. Is that correct?
<tgardner> cdhm, no, you want to change the  CONFIG_LOGFS option in debian.master/config first, then the fakeroot thing
<cdhm> tgardner: Ok, so the order is:do the apt-gets, then nobble the debian.master/config then  do the fakeroot thing, then regular make; make modules_install
<tgardner> cdhm, not regular make, e.g., 'cp debian/build/build-generic-pae/.config .;make oldconfig scripts prepare;make M=`pwd`/fs/logfs'
<cdhm> tgardner: So what then does the modules install?
<tgardner> cdhm,  assuming you're running that kernel you can simply 'sudo insmod fs/logfs/logfs.o'
<cdhm> tgardner: Not that easy... logfs wants other modules installed too. Doing the depmod/install would be neater.
<tgardner> cdhm, well then perhaps you should just build the whole kernel and .deb, e.g., 'fakeroot debian/rules clean binary-generic-pae', then install the linux-image debian package that gets created.
<cdhm> So isn't there a middle ground without drinking the whole Debian KoolAid?
<tgardner> cdhm, not really. welcome to building kernels...
<cdhm> Hmmm. Building kernels for embedded is a lot more straight-forward with a quicker turnaround.
<Q-FUNK> howdy!  would anyone have an ETA for applying the fix indicated for bug #892615 to the Precise kernel? 
<ubot2> Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615
<Q-FUNK> someone spotted an upstream commit that allegedly fixes it.
<tgardner> Q-FUNK, presumably it will show up in the normal course of development before 3.2 is released
<Q-FUNK> tgardner: it currently flat out prevents the kernel from loading.
#ubuntu-kernel 2011-11-23
<smb> morning
<sakthi> hi, can anyone point to right resources in order to form a good foundation in kernel programming..
<ppisati> to whom shall i ask for the qa-regression-testing?
<smb> ppisati, If I am not confusing people, maybe hggdh. And I guess he'll scream if I did confuse people... 
<ppisati> ok, let me try
<ppisati> hggdh: ping
<gema> ppisati: https://blueprints.launchpad.net/ubuntu/+spec/other-p-qa-qa-regression-testing
<gema> ppisati: nuclearbob is the right person to ask
<ppisati> gema: k, thanks
<gema> np
<hggdh> ppisati: hello
<hggdh> hum, I see all is resolved
<herton> ppisati, just confirming, ti-omap4 rebased on oneiric doesn't change the abi?
<ppisati> herton: compilation didn't complain about it so...
<herton> ppisati, ack
<apw> ppisati, that does assume its enabled !
<ppisati> ppisati: uh?
 * ogasawara back in 20
<lifeboy> If I have a display driver problem on an ltsp client and the screen keeps on initialising every 5-10 seconds, which process to I stop in the console (screen 0) to inspect what's going on?
<lifeboy> It's not ldm, startx or xdmcp
<apw> bah
<apw> lifeboy, i thought it stopped after 5 or so tried
<apw> i assume its lightdm which is respawning X if its that
<ogra_> lifeboy, better go to #ltsp to debug that ;)
<lifeboy> soory, that was posted in the wrong channel! 
<lifeboy> I meant to go to #ltsp :-)
<herton> is anybody being able to clone from zinc? (I'm getting "fatal: The remote end hung up unexpectedly")
<smb> it seems exceptionally crawling
<ppisati> yep, really slow today
<smb> load of 76
<smb> seems to be swapping to death
<herton> cloning through ssh:// seems to be going now
 * apw bets its those web-crawlers again
<smb> apw is right
<smb> or has been looking on #is :)
<apw> heh not looking on #is
<apw> am just talking on #is
<smb> apw, I just had been completed to hassle him :)
<apw> heh so you had, /me leans on them too
<ppisati> GrueMaster: ping
<GrueMaster> ppisati: Sup?
<GrueMaster> ppisati: You rang?
<ppisati> GrueMaster: yes
<ppisati> GrueMaster: http://people.canonical.com/~ppisati/linux-image-2.6.35-903-omap4_2.6.35-903.27~lp893190_armel.deb
<ppisati> GrueMaster: can you tell me if you still see the ptrace FAILures?
<ppisati> GrueMaster: wrt https://launchpadlibrarian.net/85419190/test-kernel-security.log
<GrueMaster> And you want me to test it?  I'm flattered.  :P
<GrueMaster> Will do.  Give me a few minutes.
<l3on> Hi all... does some ppa  exist backporting kernel 3.2.0 on 11.10 ?
<GrueMaster> ppisati: Ok, all ptrace errors now resolved.
<GrueMaster> I'll have to talk with smb and kees about the /dev/mem and seccomp errors.  The script indicates they were available in armel kernels beginning with 2.6.35.
<GrueMaster> Maybe they were in the omap kernel?  I don't have access to my beaglexm this week, but can check next week when I get home.
<ppisati> GrueMaster: for sure these were not available in maverick/omap*
<ppisati> GrueMaster: the exact kernel release after that (.36), had them
<ppisati> anyway thanks
<GrueMaster> btw:  Tomorrow is a national holiday, andI will also be offline Friday.
<GrueMaster> ppisati: Ok, I will update the script then.
<ppisati> ok
<GrueMaster> Grrr.   When making changes to the test-kernel-security script for armel, kees also turned on a blanket test for SECCOMP (which didn't exist in <2.6.36 armel kernels). 
 * GrueMaster facepalms
<GrueMaster> test_070_config_seccomp fails because not only was it not enabled until 2.6.36 on armel, it didn't exist as an option.  New false failure introduced on all <natty armel platforms (babbage3, dove, omap4).  Wheee.
<GrueMaster> ppisati: Was SECCOMP something that was backported to the x86 kernels?  I'm trying to figure out why it doesn't even exist on any of my armel kernels.
 * ogasawara bails.  see ya'll next week.
<tgardner> GrueMaster, you might be a bit  late for Paolo. its 7:30P in Italy.
<ppisati> no, i'm still around
<ppisati> GrueMaster: natty/omap4 has it
<ppisati> GrueMaster: it has entered linus tree in 2.6.36-rc7
<GrueMaster> ppisati: Thanks.  Now need to wrap this new code change.
<jsalisbury> herton, bjf, regression from 3.0.0.12 to 3.0.0.13: bug 893876
<ubot2> Launchpad bug 893876 in linux "wrong display-resolution and no compiz-unity-plugin working since Kernel 3.0.0.13" [Medium,Confirmed] https://launchpad.net/bugs/893876
<herton> jsalisbury, ok, .13 is already released so if having a solution a fix will land in a later update
<jsalisbury> herton, thanks
<jsalisbury> tgardner, Is there a way to match up commits reported by "git log" with what is in the ~/debian.master/changelog for the same kernel tree?
<herton> jsalisbury, it seems 893876 is not a kernel regression. On the working previous kernel, the user has nvidia proprietary driver loaded, but not on new kernel for some reason, thus the vesafb which is always loaded seems to be used
<herton> (checking both dmesgs on the report)
<jsalisbury> herton, ahh, ok.  
<tgardner> jsalisbury, typically all commits in a version go into the changelog unless they are administrative (and therefore ignored)
<apw> jsalisbury, yes the commit titles are the one liners
<jsalisbury> tgardner, apw, great, thanks for the info!
<jsalisbury> apw, so I can grep for the one liners in the changelog
<tgardner> jsalisbury, if you know the commit SHA!, then you can 'git describe --contains <SHA1>' to get the most recent tag.
<apw> jsalisbury, yep
<jsalisbury> tgardner, apw, cool, thanks for the help
<jsalisbury> herton, for 893876, do you think they need to configure the new kernel to use the nvidia driver, it won't happen automatically?
<herton> jsalisbury, no idea, I don't know how nvidia is installed, or how the user installed, I know we have jockey to enable the binary drivers, don't know how that works out in detail.
<jsalisbury> herton, ok.  I'll update the bug and report your findings.  Thanks for reviewing.
<herton> jsalisbury, ok, it's worth asking the reporter about how he installed, and checking if nvidia driver is built/enabled with the new kernel
<jsalisbury> herton, ok, will do.  thanks
 * herton back in 30 min-1 hour (errand)
<cemc> hi. I'm trying to rebuild the Hardy kernel package. I've applied a one-liner to fix some bug and I'm trying to build it using pbuilder (or through the PPA), but I'm getting the following: https://launchpadlibrarian.net/85751961/buildlog_ubuntu-hardy-i386.linux_2.6.24-30.96%2Bcemc1_FAILEDTOBUILD.txt.gz . I'm not sure how the ABI stuff works. I've just renamed the directory in debian/abi/ and changed the abiname from 29 to 30. I also read the kernel b
<cemc> uilding wiki page but I don't see what I need to do
<cemc> does anybody have a minute to give me some pointers?
<herton> cemc, for a test build, just bumping the abi should be enough, no need to rename the directory in debian/abi, I guess it's what breaking your build
<cemc> herton: you mean in debian/changelog?
<herton> cemc, yes
<cemc> herton: the kernel in Hardy is 2.6.24-30.96, and I just added a +cemc1 to that, I didn't want to change the version so I know it's the same kernel just with my changes
<cemc> curiously enough, the last one -29.95 did work like this
<herton> cemc, what would be the right way to do it, starting from a pristine 2.6.24-30.96, is something like "debian/rules startnewrelease", get the abis from the current release (you can use "./debian/scripts/misc/getabis 2.6.24 30.96"), then remove old abi dir in debian/abi, bump the abi, apply your patch(es)
<herton> but I don't know if you need to do this for a test build, I would expect just applying the patch on top of .30 should work
 * herton -> eod
 * tgardner -> EOD
<shabble> does anyone have any experience with writing/mangling usb(-serial) drivers? I'm in a weird place where cdc-acm is needed to init the device, but I have to unload and replace it with usbserial (generic) otherwise it locks up the port.
<shabble> it's an MSP430 test board: RF2500 - there's plenty of threads about it being pretty horrible, but sadly nothing that seems to actually fix it.
#ubuntu-kernel 2011-11-24
<An-iSociaL> anyone working on tegra 2 kernels?
<pk> Hi, I need to bisect the mainline kernel on Ubuntu, what would the best way be to go about this?
<pk> Since I experienced the bug with the Ubuntu kernel I guess I should use the same config, is this oneiric-kernel/debian.master/config/amd64/config.flavour.generic for amd64 desktop systems?
<ppisati> morning *
<ehw> morning, all o/  can i get someone's opinion about this last comment? https://www.virtualbox.org/ticket/9891
<ehw> seems like they're saying our headers package is broken; wondering if that's a realistic assessment...
<ehw> ^^ basically having the same issue on 3.0.0-14 from the kernel-ppa
<jmux> Hi. What's the status of the Oneiric Ubuntu LTS backport kernel? The kernel PPA contains a kernel from September. Is there a release plan?
<ehw> cking, apw can I get your opinion on that? ^^ (@9:48 UK time)
<vanhoof> jmux: http://archive.ubuntu.com/ubuntu/pool/main/l/linux-lts-backport-oneiric/ ?
<apw> jmux, it is in -proposed awaiting release into -updates
<apw> ehw, well the packages they have installed are mainline kernels, they are unsupported anyhow
<ehw> apw: trying it out with 3.0.0-14 from the kernel-ppa, and having the same issue; is it a bug?
<apw> trying what exactly ?
<ehw> apw: when i build the vbox modules with 3.0.0-14, loading them gives the same traceback
<ehw> apw: works fine on 3.0.0-13
<ehw> apw: the relocation address for cleanup_module is indeed different between pci-stub.ko and the dkms-built modules, as the last comment on that bug states
<apw> and are they the same on -13 ?
<ehw> apw: apparently so (setting up repro environment still)
<apw> and do you have the headers packages installed as well as the binary packages for -14
<ehw> apw: yes, grabbed headers from the same build ppa
<apw> ehw, it is unclear to me that i would expect the -r lines to match in those two
<smb> If it worked before and not now I would somehow more expect that upstream changed and they need to get their things together
<apw> ehw, it is listing the relocation table in the module which by definition does not have the knowledge of where the thing is meant to point, and indeed they are both 0
<ehw> apw: my understanding isn't very deep; it looks suspicious, though: https://pastebin.canonical.com/56303/
<apw> ehw, why does that look suspeicous
<apw> do we have any idea what any of the numbers even mean ?
<apw> great manual page "displays the relocation section"
<apw> that so tells me what the numbers mean
<apw> ehw, is this the only -14 kernel you have had ?
<ehw> apw: yep, just grabbed it from the ppa on tuesday
<ehw> (sorry so slow, got into a phone call)
<apw> and you never had another 14
<ehw> apw: i'm running this on a VM that I created to test this condition
<ehw> apw: so, it's pretty clean
<ehw> shouldn't be any stale headers or anything
 * ppisati -> errand, back in a bit...
<vanhoof> ehw: what version of virtualbox and where from?
<apw> ehw, so -13 was ok and -14 is not is the contention yes ?
<ehw> vanhoof: it's -4.1 from from upstream
<apw> ehw, and you got  that -14 from the c-k-t PPA yes ?
<ehw> apw: i know that -13 worked; I don't have a clean environment yet for testing that, but I'm working on it
<vanhoof> ehw: built for lucid, or oneiric
<vanhoof> ehw: eg: http://download.virtualbox.org/virtualbox/4.1.6/virtualbox-4.1_4.1.6-74713~Ubuntu~oneiric_amd64.deb ?
<ehw> apw: i got it from this page:  https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/2943294
<apw> ehw, and what architecture is this
<ehw> vanhoof: deb http://download.virtualbox.org/virtualbox/debian lucid contrib non-free
<ehw> apw: Linux lucid-test 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC 2011 i686 GNU/Linux
<apw> ehw, is that a backports kernel or ?
<apw> ehw, ie are you runing lucid or oneiric
<ehw> apw: i'm running lucid
<apw> but you are installing a kernel build in oneiric
<apw> you need to use the lts backport build probabally
<apw> as that is built using the compiler you have on your system
<apw> that may make a different to dkms packages
<apw> where did you get the -13 which does work
<ehw> apw: ok, i can do that; then the issue here: i need a backports kernel with the cifs/suspend bug fixed [LP#24330] :-)
<ehw> apw: the -13 was in -proposed, i think
<apw> in proposed on lucid yes ?
<apw> linux-lts-backport-oneiric | 3.0.0-13.22~lucid1 | lucid-proposed | source
<apw> that one ?
<ehw> apw: right, that's the one
 * ehw was trying to find that
<apw> as likely the compiler lucid -> oneiric is very different and may well be contributing to this issue
<apw> it looks like the -14 hasn't been uploaded yet for oneiric probabally as the previous one has not yet cleared into -updates
<herton> yes, I plan to submit a linux-lts-backport-oneiric for -14, but the previous one still didn't make to updates (bug 885468)
<ubot2> Launchpad bug 885468 in kernel-sru-workflow "linux-lts-backport-oneiric: 3.0.0-13.22~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/885468
<vanhoof> ehw: apw works for me
<ehw> apw: any chance I can get/create a -14 test build for lucid? not sure how that works
<apw> vanhoof, -14 works ?
<apw> vanhoof, and works on what
 * apw is very suspicious of compiler skew in this case
<vanhoof> ah crap still on -13
<ehw> apw: i like the theory
<apw> ehw, as and when we have something to test it is vital you remeber you have to tell dkms to remove the existing build else you won't get new modules built and the test will be invalid
<ehw> apw: noted, thanks; will purge, scrub, and bleach dkms
<apw> which frankly isn't easy
<apw> herton, ok if i wanted to rebase this lts backport for you whats the magic incantation to make the new tracking bug, or is that a dangerous thing to do
<apw> herton, i don't want shankbot after me
<ehw> apw: virsh snapshot-revert [...] :-)
<vanhoof> alright here we go
<vanhoof> installing -14, w/ virtualbox already installed and built via dkms
<apw> vanhoof, gotten from where and onto what base os release
<vanhoof> apw: the same release ehw is using ;)
<vanhoof> apw: lowell
<vanhoof> apw: 10.04.3 + https://launchpad.net/~canonical-kernel-team/+archive/ppa/
<vanhoof> amd64 though
<apw> vanhoof, so onto a lucid base and where did you get your -14, is it the oneiric version of -14 you installed
<ehw> vanhoof: actually i'm repro'ing on straight lucid atm (leaving lowell out of the mix for now)
<vanhoof> apw: yup, oneiric based 
<herton> apw, there is already a tracking bug opened for it, let me see here (just was waiting to work on it because previous version isn't released yet)
<apw> herton, i think i should stay out of it then, i was going to try test building it is all
<herton> apw, bug 893567
<ubot2> Launchpad bug 893567 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-14.23~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/893567
<vanhoof> ehw: same behaviour here
<apw> vanhoof, and i think i expect that, what you just did is not sensible
 * apw installs teh same binaries vanhoof did but onto an oneiric base
<apw> in general kernels from other releases should work except for dkms stuff where all bets are off
<apw> which in large part is why we have to build special backport kernels
<herton> apw, if wanted I can push the update to the git repo, just will not upload the backport yet
<apw> herton, that would be perfect for me, i could then spin these guys some test kernels from it
<apw> herton, but don't rearrange your day to make i happen
<herton> it's ok, will do now
<ehw> \o/
<vanhoof> apw: just did the same on oneiric proper and it works
<apw> vanhoof, yeah good, that sounds beelieveable
<apw> and i've just installed the same combinations here and they have matching offsets
<apw> and that is why i care about the compiler we build the kernel with
<vanhoof> apw: herton: i'm building it now against lucid
<apw> vanhoof, building ?
 * apw notes that build teh real oneiric kernle isn't quite the same
<herton> apw, pushed
<vanhoof> apw: 3.0.0-14.23 in a lucid chroot
<herton> vanhoof, if you want, you can build lts-backport-oneiric branch from lucid repo now
<herton> it's updated to 14.23
<apw> yeah it makes more sense to build what he has
<apw> herton, thanks
<vanhoof> ack, i'll kick that off
<ehw> vanhoof: why you working, anyway? isn't it 7AM and thanksgiving? :-D
<vanhoof> ehw: dedication :D
<vanhoof> ehw: just screwing around w/ other stuff
<vanhoof> not really working
<vanhoof> ehw: just happened to be playing around w/ the lowell build for something :)
<ehw> vanhoof: you should be participating in mass turkeycide right now
<vanhoof> ehw: build running
<vanhoof> ehw: bit early for that :)
<vanhoof> but you know what its not too early for
<vanhoof> a beer
<vanhoof> it is thanksgiving afterall
<ehw> it's always noon somewhere
<vanhoof> ehw: you want i386 right?
<ehw> vanhoof: right, i386 pae kernel
<vanhoof> ehw: apw: herton: http://paste.ubuntu.com/748159/
<vanhoof> ehw: i386 build is almost done
<vanhoof> but looks good here
<ehw> vanhoof: excellent!
<ehw> vanhoof: can you pastebin lsmod ?
<vanhoof> ehw: http://paste.ubuntu.com/748161/
<ehw> vanhoof: eeexcellent; there's no [permanent] next to the module names, either \o/
<vanhoof> ehw: http://kernel.ubuntu.com/~vanhoof/ehw/i386/
<vanhoof> ehw: all three packages are scp'd over now
<vanhoof> ehw: lmk if it works
<ehw> vanhoof: great, thanks!
<ehw> vanhoof: setting up now
<vanhoof> ehw: k make sure to grab linux-headers-3.0.0-14_3.0.0-14.23~lucid1_all.deb
<vanhoof> ehw: it stalled on the transfer
<vanhoof> but they're all there and I md5'd em
 * ehw grabs
<ehw> vanhoof: ok, WORKSFORME
<vanhoof> ehw: \o/
<vanhoof> ehw: awesome
<apw> bug #861296
<ubot2> Launchpad bug 861296 in linux "mmap fails to allocate 2030Mb heap on ARM" [High,Confirmed] https://launchpad.net/bugs/861296
<ppisati> omap4 i guess
<apw> ppisati, needed on the buildds as well according the bug, so imx51
<ppisati> apw: but he said they were running oneiric
<ppisati> imx51 is lucid only
<apw> ppisati, i suspect they are building in oneiric chroots, on the buildds with a lucid kernel
<apw> i guess we'd better check
<ppisati> apw: discussing it on #ubuntu-arm with doko
<apw> ok
<apw> ppisati, seems i wasn't on #u-a, did we reach a resolution
<cking> apw, power measurements, batch #2 coming your way in email...
<apw> cking, thanks
<cking> apologies, I pasted text into the mail client and it broke the formatting
<smb> cking, metoo?
<cking> smb, sorry, of course, will do
<smb> cking, thanks. :)
<Kano> hi apw 
<Kano> apw: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=93165b7774a04cf76bc46eb6c9181ab7a8b545d7
<Kano> could you consider that as backport for 3.0?
<ppisati> apw: for O/omap4 is a clean cherry-pick, kernel built and i'm sending them for testing to #is
<apw> Kano, to sru a change like that we need someone asking for it in a bug, and for them to test when its applied, else it'll get reverted
<ppisati> apw: for lucid/imx51, i'll take a look at it now
<ppisati> apw: half our builder are babbage (imx51) running lucid
<apw> ppisati, sounds good
<ppisati> apw: another half is panda running natty or oneirc
<apw> ppisati, i am assured they will be replaced by pandas around now, but i don't hold my breath
<ppisati> yep
<apw> ppisati, and when they are we will stop support for the fsl branch ... yay
<Kano> apw: it is the same code as http://knc1.de/download/Linux/KNC_DVB_C_MK3X_TDA10024_Patch.zip which is needed for one dvb-c card
 * ppisati wonders if all these Franken-builder will ever get replaced by one proper arm server (when they are available of course...)
<apw> Kano, that may be, but the point is someone with the h/w needs to test the fix else we can't get it through the sru process
<Kano> i know someone, thats not the problem
<Kano> 3.2 kernel is somehow crap currently, when i boot my netbook i get something like that: http://kanotix.com/files/fix/crash/IMG_20111123_103403.jpg or http://kanotix.com/files/fix/crash/IMG_20111121_122645.jpg
<apw> Kano, then get them to file a bug, and add the link to the fix there, and them come here and ping me with the bug #
<Kano> did you test 3.2 with a netbook (intel atom)?
<apw> Kano, yep i am running the ubuntu 3.2-rc2 based kernels on most of mine
<apw> yours is some random daily from a few days back.  have you tried at least  -rc3 ?
<Kano> did you see rc3 compile?
<Kano> rc2 had the same problem
<apw> i have an -rc3 based build i am about to test
<Kano> thats a 32 bit only N270
<Kano> more or less the same as msi wind u100 but called akoya e1210
<apw> i think mine are N450 ish but no not see that even on my 32bit builds
<apw> but the stuff just before -rc3 was pretty poor
<Kano> N450 is 64 bit
<apw> 64bit capable, but i run 32bit on it
<apw> Kano, so i've just booted the tip of our tree which is 3.2-rc3 based and it works for me on 32 and 64 bit atoms i have available
<Kano> apw: curious
<Kano> maybe it has something to do with wlan
<lifeboy> just a question about patch files: Is a patch file anything more than a diff between two files?  I have a patch file for an older version of a driver (not the code itself, but some configuration files), and by looking at the content it seems I could apply the changes manually.  Would I miss something in the process?  I could just try it, but instead of wasting a lot of time trying, I thought I'd just ask.
<cemc> herton: it worked, thanks a lot
<ppisati> lifeboy: you would loose the commit msg
<ppisati> lifeboy: git am -s $PATCH
<herton> cemc, cool
<ppisati> lifeboy: if that doesn't work, git apply --reject $PATCH
<ppisati> lifeboy: then for every hunk that doesn't apply, there will be a $file.rej
<ppisati> lifeboy: apply them manually, git add all the modified files
<ppisati> lifeboy: and in the end git am --continue
<ppisati> lifeboy: btw, from time to time, i closely check why a patch doesn't apply and i modify it to apply cleanly
<ppisati> lifeboy: that's another way to approach the same problem
<ppisati> wait
<ppisati> lifeboy: a bit old, but still relevant
<apw> lifeboy, there is nothing to a patch but the changes represented and the changelog entry
<ppisati> lifeboy: http://kerneltrap.org/mailarchive/git/2007/2/22/239376
<apw> lifeboy, git patches have some other information such as git base commit which can help git apply them more easily than you can
<lifeboy> ppisati: It's a patch from the manufacturer of the hardware, so it's not in the git source tree
<lifeboy> If toying with the idea of rather taking their source tree, which is based on some Ubuntu 10.04 version and adding some modules to it that I need, specifically aufs and nbd
<lifeboy> Not "If"... "I'm toying" ...
<lifeboy> would that be in principle possible?  I would add module sources and make sure the .config file has the relevant entries to include the modules in the build
<ppisati> AHHHHHHHHHHHHHHHHHHHHHHHH!!!! i forgot to change the changelog... :(
<lifeboy> apw: If the patch is not an "official" patch, then the whole git issue doesn't apply, right?
<apw> right then it won't be annotated and is as difficult to apply as a normal patch
<apw> git apply -C1 is a good first try which makes git apply work like patch
<lifeboy> I might not need to do this, if I can merge the aufs and nbd source into the tree, with their corresponding .config entries.  The build will then take care of the rest or not?
 * ppisati goes out to find some boxes...
<lifeboy> If I use the make-kpkg way of building a kernel how can I add the items in ubuntu/Kconfig in the source tree to the .config?
<lifeboy> I asked earlier (but it doesn't seem too many are here!): / If I use the make-kpkg way of building a kernel how can I add the items in ubuntu/Kconfig in the source tree to the .config?
#ubuntu-kernel 2011-11-25
<ppisati> morning *
 * ppisati -> errands, back in a bit
 * apw reboots to test a new kernel
 * apw survives the reboot
<jk-> apw: sounds like reboot cake is in order
<apw> jk-, oh thats a nice idea, is that non-fatening as well?
<Fudge> hi im on lucid and am looking for a ubuntu ppa for natty backported kernel, anyone know the team name?
<Fudge> oh found it :$
<apw> Fudge, they are in the main archive
<MestreLion> Hi! I assume this is a fairly common question: i have maverick, and i would like to upgrade its kernel from 2.6.35 to 2.6.36. What would be the best approach? (if there is any)
<MestreLion> (the reason is support to PWM fan control that was only added for my motherboard in 2.6.36
<MestreLion> is there any easy, safe, sane approach?
<An-iSociaL> add it as an additional boot entry so if things go awry you can simply reboot the old one?
<MestreLion> An-iSociaL: doesn't grub-update automatically does that?
<MestreLion> update-grub i mean
<An-iSociaL> not sure
<MestreLion> for minor updates that usually pop in update manager, it does
<An-iSociaL> i would usually do that stuff manually cuz im a control freak
<MestreLion> i mean 2.6.35.xx
<MestreLion> kernel updates add up in my grub menu... so i think that part is safe
<MestreLion> but i have no idea on how to obtain and install 2.6.36 (or newer) in maverick
<MestreLion> im a newbie, so the more automated, pain free, the better.. what is the best approach?
<An-iSociaL> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<An-iSociaL> the maverick 2.6.36 is there
<MestreLion> and what do i need to do? just install all the debs? is that simple?
<An-iSociaL> couldnt say from your setup
<An-iSociaL> i would usually end up compiling it from source
<An-iSociaL> http://askubuntu.com/questions/9504/how-can-i-use-a-2-6-36-kernel-in-maverick
<An-iSociaL> they suggest it is as simple as installing the deb
<MestreLion> yes, ive been there... thats how i ended up here
<MestreLion> how this you get that URL , by the way? i tried to navigate from kernel.ubuntu.com and never found the http://kernel.ubuntu.com/~kernel-ppa/mainline/
<An-iSociaL> ah
<An-iSociaL> im not actually any type of ubuntu support person, just another user in chat
<MestreLion> youre still helping me a lot , and im very grateful
<An-iSociaL> really here to try n get help compiling 2.6.36 with tegra2 and quantum touch ic touchscreen support under arm
<An-iSociaL> no worries glad to help
<MestreLion> by the way.. that is "mainline" ? it means vanilla kernel, without ubuntu/maverick's patches?
<An-iSociaL> there are vanilla and specific from what i can ascertain, the ones specifically tagged maverick i think have the patches
<MestreLion> thank you An-iSociaL 
#ubuntu-kernel 2011-11-26
<wamty> what does "CRTC" mean?
<wamty> I know it's DRM-related
<wamtyy> memory leak > http://paste.pocoo.org/raw/513211/
<wamtyy> a lot of ram used
<wamtyy> but not by a process...how do I fix it?
#ubuntu-kernel 2011-11-27
<alexbligh> I am trying to clone the ubuntu kernel git repo like here https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide and use git clone git://kernel.ubuntu.com/ubuntu/linux-2.6 then git clone --reference. That does not seem to work. Has the base repo changed? Is it now ubuntu/linux.git ?
<Thedemon007> Hi i have wireless mini pci-e no support see http://3dsp.com.cn/web_html/download.html now can get source code complete
<mjg59> Thedemon007: There's no complete source that can be downloaded from there
<Thedemon007> no :s mjg59 see the steps 3dsp provide the whole source doe if we get valid application.form and valid information. 
<mjg59> And even the bit that says "Open source" isn't open
<mjg59> It explicitly says it can't be redistributed
<mjg59> So it may be that the source code can be obtained, but I'd be amazed if it's actually GPL compatible
<mjg59> Despite claiming to be GPL in module_license
<Thedemon007> amm ok :S
#ubuntu-kernel 2012-11-19
<infinity> janimo: *poke*
<infinity> janimo: Two things:
<infinity> janimo: 1) Are there plans to actually finish regression testing on the current -armadaxp in proposed (so I can release it) before pushing the rebase from the PPA?
<infinity> janimo: 2) Your -meta-armadaxp in the PPA is wrong, you want s/1610/1611/ in the version. :P
<infinity> janimo: (This is for precise in both cases)
<janimo> infinity, thanks. 1) I had no idea it's not tested yet.I'll ping qa. 2) ah
<janimo> infinity, uploaded a new meta to PPA
 * apw yawns ...
 * apw won't be on mumble most likely today ...
<smartboyhw> apw, ping
<apw> smartboyhw, hi
<smartboyhw> apw, after getting problems of no pae for Studio images in Precise I think you forgotten the -pae kernels for Raring too
<smartboyhw> http://qa.ubuntuwire.com/debcheck/debcheck.py?dist=raring&package=linux-meta-lowlatency
<apw> smartboyhw, how is that even possible now that britney doens't allow those to propogate
<apw> smartboyhw, anyhow, it is clearly wrong, i'll look into it; thanks
<smartboyhw> apw, thx
<apw> henrix, herton, bjf, fyi there is a linux-lts-quantal-signed in your PPA, which is not buildable currently for lack of a build-dep: i am working on resolving that currently
<herton> apw, ack. Let me know when it's fixed, bjf and henrix are on holidays this week
<apw> herton, will do, it _should_ resolve itself as packages publish in the main archive, fingers crossed
<smb> infinity, I am not sure you wanted to know, but there is still a package waiting for your kind review/sponsorship in zinc:~smb/4review. ;)
<ppisati> rtg: fr when you are awake
<ppisati> rtg: http://paste.ubuntu.com/1369846/
<ppisati> rtg: building in a raring-armhf didn't show any errors (albeit it was painfully slow)
<rtg> ppisati, try using a precise chroot. dpkg has some forign arch issues that I fixed in Precise by pinning the version to something before that regression was introduced.
<rtg> s/fixed/worked around/
<arges> apw, hey. looking at bug 922906
<ubot2> Launchpad bug 922906 in linux (Ubuntu) "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [High,Triaged] https://launchpad.net/bugs/922906
<arges> apw, i see you messaged the author: https://lists.ubuntu.com/archives/kernel-team/2012-April/019921.html , did you ever hear a response?
<apw> arges, not that i recall any time recently
<arges> apw, ok I 'll look into it a bit more and email the authors then
<rtg> apw, ogasawara: pushed v3.7-rc6 rebase
<ogasawara> rtg: ack, thanks
<apw> rtg, thanks
<apw> arges, thanks
<apw> herton, further heads up, i have had to copy sbsigntool into the ckt PPA for precise to unblock the builds there.  shankbot may beed its hand holding :)
<apw> herton, at the utter abuse i am piling upon its head
<rtg> apw, I don't _think_ there were any patches that would wreck overlyfs/aufs, but you still ought to test it before we get around to uploading.
<apw> infinity, heads up there is a copy of sbsigntool in the ckt PPA dunno if you will even see it, but if so pls ignore
<apw> rtg, ack
<herton> apw, ack. Actually I have to fix shank bot/create-release-tracker to consider the signed package for the linux-lts-quantal (to have a prepare-package-signed task)
 * rtg -> biab
<apw> herton, indeed we would need that; thanks
<apw> herton, do you keep and eye on the fullness of this PPA, cleaning old binaries ?
<herton> apw, usually henrix/bjf I think were watching the space usage, but I sometimes clean things there too
<apw> herton, i have just gotten the first linux-lts-quantal-signed to build; so when we copy out linux-lts-quantal we want that to go with -- though that may not be something i need to tell you :)
<apw> herton, cool, as long as its being done i am happy
<herton> apw, yeah, infinity is doing the copying on that one I expect
<herton> *copy
<apw> man this thing is resistant, i am reluctant to believe it will work even now
<apw> herton, so linux for quantal went out into -proposed, does that mean -lts-quantal is also valid for copy, or would it normally wait for something else
<herton> apw, it's valid, atm bug 1078677
<ubot2> Launchpad bug 1078677 in Kernel SRU Workflow "linux-lts-quantal: 3.5.0-19.30~precise1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1078677
 * rtg commutes to Beaverton. back in a bit.
<herton> apw, on future tracking bugs it should just wait on master, -meta and -signed for copying
<apw> herton, ok cool
 * herton -> lunch
 * ogasawara back in 20
 * ppisati -> brb
<apw> herton, what would you expect the name of the linux-signed to be for linux-lts-quantal
<apw> ie. what will shankbot wait for, linux-signed-lts-quantal or linux-lts-quantal-signed
<herton> apw, I think following the same as main linux, linux-lts-quantal-signed would be my choice
<apw> ok that is indeed what it is
<apw> it is just inconsistent with linux-meta
<herton> hmm yep, that's true, but the bot can pick any package name wanted, it's a mapping on ktl/ubuntu.py
<apw> yeah, just wanting to get the name right as this is the first
<herton> ok, don't worry about it, any name chosen is easy to add
<apw> herton, so should i be making it consistent on the lts- version, linux-signed-lts-quantal
<herton> apw, yes, that's ok
<apw> herton, ok i'll get it fixed before it propogates
<apw> herton, ok its now consistant
<herton> ack, cool
 * ppisati -> gym
<rtg> apw, you noticed that linux-signed-lts-quantal failed to thrive ?
<apw> rtg, yep, clashing binary versions, its fixed now
<rtg> apw, ack
<infinity> smb: apw claimed he'd review that for you.
<infinity> smb: He may have lied. :)
<smb> infinity, I guess he meant the other one (which he did) and suggested he would do a lot of whining before touching it. :)
<smb> Everyone is sooo eager to touch it... :-P
<apw> infinity, smb, here have the hot potato
<kees> say, who's in charge of SRUs for precise? I'd really like to get this seccomp audit patch in...
<rtg> kees, I'll annoy someone to get a second review
<rtg> herton, since you're the skeleton of the stable team, please take a moment to review https://lists.ubuntu.com/archives/kernel-team/2012-November/022786.html
<herton> rtg, looking
<kees> rtg: thanks!
<herton> rtg, ack sent
<kees> herton: thanks!
<rtg> herton, got it
 * apw wanders off to get some grub
<rtg> sconklin, oh great and wonderful python wizard, please cast your eye on https://lists.ubuntu.com/archives/kernel-team/2012-November/022794.html
<sconklin> rtg, looking
<jsalisbury> sconklin, rtg, I'm going to have one additional change to that script again.  Probably tomorrow.
<sconklin> jsalisbury: do you want to wait and have it all applied at the same time, or does it make sense as two changes?
<jsalisbury> sconklin, we can probably wait.  The change will be to the same line.  I created a bug that marks the development kernel as wont fix, since it is marked as unsupported in some other config files.
<sconklin> jsalisbury: ack, I'll hold off
<jsalisbury> sconklin, cool, thanks.
<sconklin> jsalisbury: no problem, it makes me happy to see you dealing with (I mean maintaining) this code
<jsalisbury> sconklin, heh
<infinity> apw: The rational human being in me is currently beating down the nerd that wants to say "how about some lilo instead?"
<sconklin> infinity: where are you located? No need to beat down yourself, I'll come do it for you :-)
<infinity> sconklin: Calgary, and much appreciated.  I look forward to this service you provide.
<sconklin> heh. Kinda cold.
<sconklin> I haven't thought abotu lilo in a very long time
<infinity> Would it be some sort of Code of Conduct violation to publicly question if "beat down" is synonymous with "beat off" where you're from?
<infinity> If so, pretend I said nothing.
<sconklin> um. No it's not.
<infinity> :P
<sconklin> In Alabama to beat down it to render unconscious with a beating, generally
<sconklin> s/it/is/
<infinity> It is here, too. :P
<infinity> The above was mostly an attempt to get Tim to ruin a keyboard.
<sconklin> a worthy pursuit
<rtg> infinity, I have now spluttered indignantly over my keys. satisfied ?
<infinity> rtg: It'll have to do.
<kamal> kernel.ubuntu.com appears to be unreachable
<bjf> kamal, still? 
<bjf> kamal, meaning, it's working for me right now
<kamal> bjf: nope, now its fixed for me too
<bjf> kamal, ok, let me fix that
<kamal> bjf: thanks for fixing that ;-)
<infinity> bjf: Say, does shankbot double-check override mismatches after the proposed->updates/security copy is done?
<bjf> herton, ^ ?
<infinity> bjf: (I'm keeping an eye on this first upload of linux-signed-lts-whatever anyway to make sure it doesn't go awry, but I suspect it will the first time)
<herton> infinity, no, it just check for the ppa -> proposed transition, but I can wire the same checks for proposed->updates/security, and that makes sense too to have
<infinity> herton: Yeah.  It's not something that SHOULD break, but we know of one corner-case where it does.  And, better safe than sorry, since the final copy is the one you really care about being right. ;)
<bjf> infinity, no worries, your using LP, what could possibly go wrong?
<infinity> bjf: I could swan-dive off a tall building?
<herton> heh. ok, one more todo item for shank bot
<infinity> Eventually, shankbot should be able to replace most of the kernel and AA team.
<bjf> shankbot should be able to turn the crank on kernel updates itself
<infinity> Yeah, I wasn't being entirely facetious.
<infinity> Other than a (necessary) human review step, rebases can easily be automated.
<infinity> And other such things.
<infinity> bjf: Despite the countless billions and manpower that places like MIT and CalTech have sunk into AI research, I'm sure shakbot will be the first piece of software to achieve conscious self-awareness.
<infinity> bjf: ... unfortunately, shortly thereafter, it'll realise how much its job sucks and kill itself.
<bjf> infinity, it's built on top of LP data so it will start out insane
<apw> infinity, saddo
<profiler1982> am have eee pc r051bx. is it in plan better support in 13.04 . am stuck on 11.10 at the moment
#ubuntu-kernel 2012-11-20
<infinity> bjf / herton: Who do I whine at about three kernels falling behind on the SRU cadence?
<infinity> bjf / herton: bug #1068733, bug #1068572, and bug #1068229
<ubot2> Launchpad bug 1068733 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.2.0-1610.15 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1068733
<ubot2> Launchpad bug 1068572 in Kernel SRU Workflow "linux-ti-omap4: 3.2.0-1421.28 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1068572
<ubot2> Launchpad bug 1068229 in Kernel SRU Workflow "linux-ti-omap4: 3.0.0-1217.30 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1068229
<infinity> bjf / herton: Oh, and bug #1068573
<ubot2> Launchpad bug 1068573 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.5.0-1604.6 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1068573
<infinity> hggdh: ^-- You have any input on what's holding up the above?
<herton> infinity, yes they wait QA, not sure what's holding it though
 * apw yawns
 * cking offers apw some coffee
 * apw tiptoes round his machine after finding it with a read-only root this morning
<smb> The coffee machine?
<apw> i wish
<ppisati> apw: quantal?
<apw> quantal indeed
<ppisati> apw: happened to me too with quantal on haswell
<apw> not haswell, a very old dell ... hmmm
<stefano_> hi
<stefano_> I have a problem running latest ubuntu kernel version under xen
<stefano_> basically there has been a patch cousing a problem with drivers/xen/platform_pci.c
<stefano_> commit b9136d207f0c05c96c6b9c980fa7f7fd541a65a8 introduces a bug under xen
<stefano_> commit 38ad4f4b6cc713b3c42cb4252688ef5c296d7455 fixes it
<stefano_> the kernel 3.5.0-17-generic has b9136d207f0c05c96c6b9c980fa7f7fd541a65a8 but not 38ad4f4b6cc713b3c42cb4252688ef5c296d7455
<stefano_> do you know if 38ad4f4b6cc713b3c42cb4252688ef5c296d7455 will be included at some point for 12.10?
<smb> stefano_, Seems that other one was not tagged stable, so not automatically
<smb> stefano_, Could you open a lp bug and add the info in there and then subscribe me?
<stefano_> ok, I never used lp, do I need to register?
<smb> stefano_, Yeah, I guess. But ok if you would have to just for that I try to get it done
<stefano_> smb: I am on https://launchpad.net/~ubuntu-kernel-team
<stefano_> smb: do you know what should I do from there? or should I use some different lonk?
<stefano_> link?
<smb> stefano_, Oh, so you have an account already
<smb> https://bugs.launchpad.net/ubuntu/+filebug
<smb> package would be "linux"
<stefano_> smb: I am just registering...
<smb> stefano_, So I was misunderstanding the "I am on ..."
<stefano_> sorry, I confused you :)
<stefano_> but now I am :)
<smb> stefano_, Not bad to have. Then we also can make you aware of Xen bugs . :)
<stefano_> ah, thanks :)
<stefano_> how can I subscribe you for the bug?
<stefano_> smb: sorry I always forget to put smb: in front of the line..
<smb> stefano_, Heh, igf I would not be distracted by a second thread of conversation it would not matter
<smb> There should be a subscribe someone else link at the right
<smb> I am stefan-bader-canonical
<stefano_> I just did :)
<stefano_> do you think I should put more infos about the bug?
<smb> bug 1081054
<ubot2> Launchpad bug 1081054 in linux (Ubuntu) "Kernel panic running latest ubuntu 12.10 kernel version (3.5.0-17-generic) under xen." [Undecided,New] https://launchpad.net/bugs/1081054
<stefano_> I did not because we know already the solution
<smb> stefano_, I guess it should be ok... just need to 
<smb> make sure the botstays happy
<stefano_> smb: thanks for all your help :)
<smb> stefano_, Oh, thanks for the info about the issue (plus the patch that fixes it)
<smb> stefano_, If it would be always that simple... :)
<stefano_> smb: do you have an idea of the timeframe when users will download a new ISO and kernel will include both patches?
<stefano_> just so I can give a vague indication to our customers
<smb> stefano_, I don't think we re-create any isos for non-lts releases. 
<stefano_> ah...
<smb> The cloudimgs are rebuild if they use them
<smb> otherwise it is updates
<stefano_> ok, any idea of kernel updates timeframe than ? :)
<smb> but timeframe worst case 6 weeks if it misses a cycle completely
<stefano_> ah, good than :)
<caribou> I'm having a problem with the most recent mainline build. boots up to GUI but trying to login causes a stack trace in 'nouveau' and it flickers back to the login screen
<caribou> any other kernel close to mainline that I should test ?
<caribou> the mainline I used is 3.7.0-999.201211190405
<caribou> (yesterday's build)
<caribou> nm, looks like 3.7.0-999-generic #201211080405 does the trick
 * ppisati -> out for lunch
<smb> jsalisbury, herton, This morning a bug was reported for Quantal that provides the sha1 to the patches breaking and fixing some Xen regression. So it would only require some crank-turning. ;) -> bug 1081064
 * smb expectantly looks at ubot2 
<herton> smb, wrong bug num? it redirects me to a landscape bug
<smb> meh fingers... https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1081054
<ubot2> Launchpad bug 1081054 in linux (Ubuntu) "Kernel panic running latest ubuntu 12.10 kernel version (3.5.0-17-generic) under xen." [Medium,Triaged]
<herton> smb, will take a look and queue on 3.5 stable. I was busy looking at the ceph updates for it, just going to finish a build test and queue the xen fix also
<smb> herton, Sure, I'd leave it to you on how exactly this runs through... Actually now this is an interesting thought... does it need two acks because this could be and upstream stable update which we do take without asking but then we have not been responsible for that before...
<herton> smb, yeah I don't know. If you want in parallel to send that as a SRU for two acks that's fine
<smb> herton, Oh you know, I tried to avoid *that* decision by telling you ;)
<smb> Actually I rather just thought of the strange implications that you running "stable" has.
<herton> smb, is 3.5 the only version affected by the bug?
<smb> herton, As far as we were told, but give me a sec
<smb> herton, First patch came in 3.4 and the fix 3.6, so potentially 3.4 could be affected too... If that is supported by anyone
<herton> smb, greg still supports it, so I think is worth sending to stable mailing list as well. 3.4 is one of the chosen longterm trees
<smb> Hm, though probably only causes problems for PVonHVM guests as I cannot remember having problems with Quantal in HVM and PVM
<jsalisbury> herton, smb, just let me know if you need help building test kernels, etc for that bug
<zequence> What kind of problems could one expect to see in using an older kernel for any Ubuntu release (like a 2 year older kernel, compared to the release)
 * herton -> lunch
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
 * ogasawara back in 20
<ogasawara> rtg: I was gonna prep an upload before EOD day tomorrow to get -rc6 to the masses before most of us drop off for Thanksgiving/Black Friday.
<rtg> ogasawara, I was thinking we should get that uploaded today so as to mitigate any carnage that we might cause. note that apw will be around (I think) for the 2 days we are out.
<ogasawara> rtg: ack, I'll prep it for upload by EOD today then
<apw> rtg should be around anyhow
<apw> ogasawara, will get the union stuff tested shortly
<rtg> ogasawara, works for me
<ogasawara> apw: ack
<rtg> I don't think there is anything else in the pipe. the userns stuff is still  a WIP
<ogasawara> rtg: I shoved on patch to linux-meta already for the clean old kernels work, and I want to get one config tweak in too that jsalisbury just pinged me about.
<rtg> ogasawara, -rc6 works on my laptop, so it _must_ be shippable
<rtg> ogasawara, oh, I might have some firmware patches. guess I'd better wrap that up today as well.
<rtg> I was working on that last friday and kinda forgot
<rtg> I wrote yet another script to help sort out firmware duplicates and obsoleted files.
<ogasawara> rtg: I'm also on the brink of getting this updated i915 driver carried for Haswell in our ubuntu/ dir.  I'm hoping to get that out for testing next week.
<smb> ogasawara, Hm, maybe I would have some patch for xen. Though upstream discussion on it is not final but at least my own testing was good
 * smb needs to propose the thing soonish
<rtg>  ogasawara: but the haswell support is for Quantal, right ?
<ogasawara> rtg: right, Quantal
<rtg> you were just trying to distract me with you non-sequitur 
<ogasawara> rtg: of course :)
<apw> vile vile vile
 * rtg forgot his headset, so no mumbling....
<rtg> apw, I did, however, buy a stack of books about IPv6 at Powells. Did you know that the technical bookstore is now a pile of rubble? I found that a bit confusing the other morning.
<apw> rtg, i did know they had moved it to over the road from the other one i think
<rtg> apw, yep, right across the street from the main store
<jsalisbury> ##
<jsalisbury> ## Kernel Team Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues November 27th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<ecanuto> hey all, we have this bug https://bugs.launchpad.net/bugs/1033233 and I would like to know who can help to have this kernel patch in ubuntu-updates (or proposed)
<ubot2> Launchpad bug 1033233 in alsa-driver (Ubuntu) "[iMac9,1, Realtek ALC889A, Speaker, Internal] No sound at all with kernel 3.5.0" [Medium,Confirmed]
<ecanuto> also, world like to know if the bug need to be tagged when we have a patch that fix issue
<herton> ecanuto, I'll take a look at it. Since it's a stable patch I'll queue it on our 3.5 maintained tree, just have to catch up on grabbing stable patches...
<herton> ecanuto, the procedure usually when you have the patch upstream, is just send it to kernel-team@lists.ubuntu.com for inclusion
<ecanuto> herton, oh, did not know that
<ecanuto> herton, next time I will send it to the list
<herton> ecanuto, not required to send to the list, but it's faster to people notice it
<ecanuto> btw, it is the only thing that I don't like in launchpad, fill a bug not necessary notify the package maintainers
<ecanuto> herton, is it going to be available for raring too?
 * ppisati -> EOD
<herton> ecanuto, yes, I think it is already available on raring, since it went in 3.7
<herton> (the patch)
<ecanuto> herton, thank you
<rtg> jjohansen, jsalisbury, AceLan: I need to bounce tangerine for kernel upgrade
<jjohansen> rtg: give me 1 min to copy a file down
<jjohansen> rtg: okay
<ecanuto> herton, where I can found a tutorial about upload kernel to PPA
<ecanuto> I just upload one but fail to build :(
<ohsix> you use pbuilder or something to make sure it builds locally, i haven't done it in a long time; i've forgotten the details :o
<ohsix> i _think_ you may need to ask for extra space in your PPA as well, kernels take a lot of it
<ecanuto> humm
<herton> also https://help.launchpad.net/Packaging/PPA/Uploading may be of help
<ecanuto> just got this error:
<ecanuto> http://paste.ubuntu.com/1373056/
<ecanuto> herton, yes, I ready it, other packages works, only linux kernel fails
<ecanuto> locally it builds
<rtg> everaldo, looks like you've been messing with configs. 'echo 1 > debian.master/abi/3.5.0-18.30/amd64/ignore.modules', then rebuild
<everaldo> rtg, humm, where I can put it on sources?
<everaldo> I just get a clean kernel sources package and put it on my ppa changing version in changelog
<rtg> everaldo, oh, you're changing version. hence "Checking modules for generic...previous or current modules file missing!". you definitely need to read the URL that herton referenced above.
<everaldo> let me check
<herton> everaldo, also take a look at https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
 * rtg reboots for kernel test
<everaldo> the first link don't have anything new... let me see this one
<everaldo> herton, thanks, this looks to have what I need :-)
<rtg> ogasawara, just pushed a horde of firmware patches to raring master-next
<ogasawara> ack, I'll pull em then kick off test builds
<rtg> ogasawara, I'm still observing periodic random build failures on parallel builds. I've just gotta go find root cause because its starting to piss me off.
<ogasawara> rtg: I haven't seen that issue in a while.  I'll let you know if I do.
<rtg> ogasawara, its often during the headers packaging phase.
<ogasawara> ogasawara@adamo:~/ubuntu-raring-signed$ ./update-version ../ubuntu-raring
<ogasawara> dch warning: Recognised distributions are:
<ogasawara> {hardy,lucid,maverick,natty,oneiric,precise,quantal}{,-updates,-security,-proposed,-backports} and UNRELEASED.
<ogasawara> Using your request anyway.
<ogasawara> dch warning: ignoring distribution passed to --release as changelog has already been released
<ogasawara> dch: Did you see that warning?  Press RETURN to continue...
<ogasawara> Updated to version: 3.7.0-3.9
<ogasawara> git commit -s -m 'UBUNTU: Ubuntu-3.7.0-3.9' debian/changelog
<ogasawara> git tag -s -m 'Ubuntu-3.7.0-3.9' 'Ubuntu-3.7.0-3.9'
<ogasawara> ogasawara@adamo:~/ubuntu-raring-signed$ head -1 debian/changelog 
<ogasawara> linux-signed (3.7.0-3.9) precise; urgency=low
<ogasawara> rtg, apw: ^^ I assume I manually fix up that linux-signed changelog to s/precise/raring/
<rtg> ogasawara, yeah, looks like raring isn't in the approved list yet
<rtg> ogasawara, I just used 'dch -i' last time and fixed it up by hand
 * rtg -> lunch
<apw> ogasawara, cirtainly if it is not raring do fix, as to why ... hmmm
<apw> it is meant to copy it up one
<apw> ogasawara, and when i ./update-version it does indeed do so
<apw> +linux-signed (3.7.0-3.9) raring; urgency=low
<apw> ogasawara, so even more confused as to how yours does not
<ogasawara> hrm
<apw> so i just did ./update-version ../ubuntu-raring to get that
<ogasawara> apw: do I need to be running raring?  
<apw>       MISS: cpufreq-nforce2
<ogasawara> apw: I'd note that the machine I ran my runes on is a precise box
<apw> ogasawara, nope i am running quantal
<ogasawara> apw: I've fixed that build failure up locally here
<apw> so it might be a P/R ...
<apw> ogasawara, let me knoe when its pushed so i can test this overlay stuff
<apw> (build and test)
<ogasawara> apw: ack, just waiting on my final test builds
<ogasawara> apw: pushed to master-next what I anticipate to be the 3.7.0-3.9 upload
<infinity> hggdh: Around?
<hggdh> infinity: yes
<infinity> hggdh: Any idea what (or who) the holdup is on the 4 ARM kernels from the last SRU cadence that are stuck in regression-testing?
<hggdh> infinity: ugh
<infinity> hggdh: That's armadaxp on quantal and precise, and ti-omap4 on precise and oneiric.
<infinity> Unless I missed some, and there's more than those 4...
 * infinity looks again.
<hggdh> infinity: for the pandas, my fault, and will run them now. For the armada, I am finding out how to automate the install
<infinity> Nope, just those 4.
<infinity> hggdh: For automating armadaxp, I'd talk to rbasak, if I were you.
<infinity> hggdh: But maybe today, you could manual 'em up (or get someone else to), so I can get the kernels out the door and move the show on?
<hggdh> infinity: indeed, he is the one I am looking for (or mahmoh)
<hggdh> infinity: I am on the pandas now; since rbasak is (most probably) out for the day, I am following up with mahmoh
<infinity> Kay, cool.  Thanks.
<infinity> (Aren't you glad we won't be supporting the nexus7 kernel?)
 * infinity knocks on apw's head.
<hggdh> infinity: absolutely extactic
<ogasawara> BenC: would you like me to CC you on our standard kernel upload announcements so you have a heads up to rebase ppc?
<BenC> ogasawara: yes, please
<ogasawara> BenC: your @ubuntu.com email? or something else?
<BenC> @ubuntu.com is fine
<infinity> ogasawara: That whole CC for rebases thing would be wildly more useful if master didn't just FTBFS. ;)
<infinity> apw: How does one get an FTBFS when building nothing?  I'm impressed.
<apw> infinity, ?
<infinity> apw: master FTBFS on PPC during headers install.
<infinity> aufs-related.
<apw> oh ppc ?
<apw> how is ppc even differnt
<infinity> Heck if I know.  Maybe aufs headers are being arch-limited or arch-mangled somehow?
<apw> infinity, nope, thats a static file
<apw> ogasawara, i'll have a look in the morning, there is something subtle going on
<infinity> Well, the other possibility is that sulfur briefly lost its mind to cosmic rays.
<infinity> But it ain't a Panda, so I doubt it.
<apw> infinity, and odder that code has literally not changed since the previous upload
<apw> very spooky
<infinity> yeah, I'm looking through the diff right now.
<infinity> I'll give it back too and see.
<apw> thanks, and i'll look at it in the am i have an early start anyhow
<apw> infinity, oh dear, it worked that time
<apw> infinity, a parallel build failure
<apw> perhaps
<apw> will do some testing ...
<infinity> apw: Oh, that could well be it.  4 cores in the failure, 2 in the success, it's probably highly reproducible if you throw it at -j20 and try a few times (if your guess is right).
<apw> infinity, though in theory the headers build is -j1 for this reason ... as its building everywhere i'll poke it in the am
<rtg> apw, I've seen this same failure on x86'en. its something to do with binary-arch-headers
<apw> rtg, right, in the headers
<rtg> apw, I'm beginning to think that '$(hmake) silentoldconfig' needs 'prepare' added as one of the targets. I'll dig into it in the AM if you haven't already solved it by then
<apw> rtg, ack
 * rtg -> EOD
<rtg> apw, go to bed
#ubuntu-kernel 2012-11-21
<janimo> apw, are there any scripts or docs to help me get started with a config syncup for the nexus7? I am hoping there is a cleverer way than going through the file line by line
<apw> janimo, what are you going to sync it to, its a completely different version
<janimo> apw, I was hoping to get an answer to that to :)
<apw> janimo, but in answer, there are scripts to compare configs indeed and highlight relevant changes; if you have something to compare to
<janimo> would a 3.1 based previous Ubuntu mainline kernel be much different from Raring's?
<apw> janimo, we use them for our cycle configuration reviews
<apw> janimo, yeah, tons different
<apw> they change configuration options all the time
<apw> i guess you should compare to 3.2 as that is at least close, but that is before we did a lot of the harmonisation work
<janimo> so mostly name changes but in spirit our configs are similar across relelases?
<janimo> I feel this harmonisation will be painful
<apw> in spirit yes, in implementation less so, it has taken us 4-5 cycles to get our configs in good order
<apw> janimo, though i think if i was doing it i would only be caring about the common options
<janimo> something I hope can be leveraged fir the nexus7 task as I don't think we want to spend quite so much time on it
<janimo> apw, common as in those kept in ubuntu.config.common?
<apw> janimo, no, as in those pulled out as particularly interesting in the config review: http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/UDS.html
<janimo> I was thinking if we had some higer level description like : LXC support, Overlay support, All Webcams Ever, etc. Which would then be used as a source to generate actual config options for various kernels
<janimo> does that sound implausible?
<apw> we do not have that
<apw> we have some slightly lower level rules
<ogra-cb_> hmm, did we update the nexus kernel to something newer ?
<janimo> would that be something worth having or it was considered and abandoned?
<janimo> ogra-cb_, 4.2 android branch
<ogra-cb_> there seem to be tons of issues with the latest kernel
<janimo> rtg did it
<ogra-cb_> under android that is 
<apw> we are working towards that, but we do not have it yet
<apw> we have components of it, but its not in any useful form you can apply to a system
<ogra-cb_> (draining your battery fast, several kernel oppses etc)
<apw> ogra-cb_, sounds awsome
<janimo> ogra-cb_, you mean Android 4.2 on the nexus has issues because of the new kernel?
<ogra-cb_> well, it has issues
<ogra-cb_> and if there are ioopses i would blame the kernel, yeah
<ogra-cb_> -i
<janimo> there were very few changes in the kernel - not that they could not be invasive
<ogra-cb_> well, i guess we'll see
<apw> ogra-cb_, is that with the android build, or with ours
<ogra-cb_> but a battery life cut in half sounds a bit scary
<janimo> ogra-cb_, well userland or firmware can cause oopses no?
<apw> janimo, anyhow if you get me a config i can get a basic report done for it
<janimo> if it manifests on the ubuntu images we should worry I agree
<ogra-cb_> apw, android kernel under android 4.2, the google error tracker is ful of nexus7 and 10 probs 
<ogra-cb_> i guess a lot are userspace as well
<apw> ogra-cb_, nasty nasty
<janimo> apw, so if I get you a config file (the current say) you can make a report highlighting what may need to be added?
<apw> i can make a report, we can then see if it is useful
<ogra-cb_> well, i just flashed mz first raring image to the nexus7, lets see if the even boots at all
<janimo> ogra-cb_, since nexus 10 is a different SoC it may indeed be userland
<ogra-cb_> janimo, yeah, thats why i mentioned that
<janimo> apw, thanks, I'll paste you a config shortly
<ogra-cb_> yay
<ogra-cb_> it boots !
 * ogra-cb_ is in initrd, tarball is being verified
<ogra-cb_> heh, and flashing from the chromebook is possible :)
<janimo> apw this is the current config http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-nexus7.git;a=blob_plain;f=debian.linaro/config/config.common.ubuntu;h=b4f6b5b5cbf53b8188bb90c3c0d5cceff79362c4;hb=HEAD
<apw> smb, cking, ogasawara, a new toy for you: https://launchpad.net/~/+upcomingwork
<apw> a _live_ indication of your milestoned workitems and bugs
<cking> nice, that's more helpful than burndowns
<smb> apw, Damn, that is too useful and makes it kind of hard to claim one did not know...
<apw> the only wrinkle is blueprings need to be milestoned correctly for it to show them
<apw> i am working through ours now to fix them
<cking> +1 for apw
<apw> cking, ok your list looks much less well :)
<cking> much less?
<apw> you have a lot more stuff now
<cking> sad trombone sound applies
<janimo> apw, is the link I pasted enough?
<apw> janimo, i will sort it out
<janimo> ok thanks
<apw> ogasawara, oh and for you as owner of blueprints see all of the work items you are responsible for even if you arn't the assignee, nice
<Kano> hi, why is kernel-wedge not in sync with sid for raring?
<Kano> i thought you rebase the system every 6 month on sid
<ogra-cb_> janimo, apw, FYI the nexus kernel from teh archive works fine 
<apw> ogra-cb_, heh ... thats something
<apw> Kano, things which have delta do not automatically sync
<ogra-cb_> if only userspace would be so well too 
<Kano> apw: then do it manually
<Kano> its boring to do that everytime on my own
<apw> or perhaps as it does what i need as it is i could not do it
<Kano> it is bad when the version is lower than sid
<Kano> and you do not even provide a patch file as it is a native package
<Kano> ubuntu patches are often down in a very stupid way
<Kano> everything in diff
<Kano> well in that case there is not even a diff
<Kano> efibootmgr is patched without quilt
<cking> is that "do it manually so my distro can benefit too" kinda plea?
<Kano> no good maintainer would do that
<apw> for a native package like that the archive versions are the version control
<Kano> and for efibootmgr?
<apw> efibootmgr only exists in debian because someone in ubuntu actually maintains it there
<Kano> sure and without ubuntu debian would not exist
<Kano> or what
<apw> my point was more that the delta is minor and to do with the fact that we maintain it there too
<apw> so every debian derivative benefit
<apw> my point was only that we do what we can to keep debian as the gold standard
<apw> and only carry delta like that when we need to to not affect debian
<apw> and i am struggling to find your point
<Kano> usally the point is to make changes upstream which fix things
<apw> right but efibootmgr is different cause we do not have the same list of architecture
<Kano> debian never had lpia
<Kano> what you changed is pure ubuntu specific
<apw> well all i can say is the two packages you picked out have very active debian centric people as their maintainers
<Kano> so active that no patch is in debian
<apw> for those two packages maybe, but for the 100s of others i can assure you there ar
<apw> are, your presumption that we don't care about debian is plain unreasonable
<apw> the delts in kernel-wedge is a kernel related issue whering our useage and theirs does not match
<apw> as we have differnet kernels, it is not upstreamable
<Kano> the -w fix is for upstream
<Kano> and should not be in a diff
<Kano> http://packages.ubuntu.com/source/raring/kernel-wedge
<Kano> why is there no ubuntu git shown?
<apw> we don't mantain the delta in version control perhaps
<herton> apw, can bug 1075181 can be marked verified for linux-lts-quantal? Just want to make sure the precise package was tested
<ubot2> Launchpad bug 1075181 in ubiquity (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,Triaged] https://launchpad.net/bugs/1075181
<herton> *precise proposed package
 * herton -> lunch
<hggdh> infinity: panda tests in progress (one done); armada depends on a bit of hacking, still looking at all the data rbasak gave me
<ogasawara> rtg: heading in now
<apw> ogasawara, rtg, heads up for the next upload, kernel-wedge has been updated -- should be benign but you never know
<ogasawara> apw: ack
 * ppisati -> gym
<rtg> apw, I upgraded the raring chroots on gomeisa and tangerine. I noticed that kernel-wedge is still the same version as quantal. still building ?
<apw> rtg, still briney-ing
<rtg> apw, ah
<apw> rtg, ogasawara, that reminds me, i have pushed the first stage of the autopkgtest tests we have been asked for by pitti
<rtg> apw, saw that
<rtg> apw, I'm still busily ripping out duplicate firmware
<apw> rtg, i am loving that
<apw> rtg, i see a heap of it is hitting mainline too, nice
<rtg> apw, there was a surprising amount of resistance to some of those patches. go figure.
<apw> rtg its most perlexing and no mistake
 * apw moans about the publisher taking _ages_ todayu
<apw> rtg, ogasawara, ok i have just built some kernels with the new kernel-wedge, they look within the noise the same to me
<ogasawara> apw: ack, thanks
<apw> rtg, ogasawara, ok just tested overlayfs and aufs on the 3.7.0-3 kernel (amd64 and i386) and all is well
<rtg> apw, ack
<infinity> Whoever owns /home/kernel/kteam-bugs/code/reports/auto-reports-mako on lillypilly, it desperately needs locking.  There are a dozen copies running right now.
<infinity> herton: ^-- That something you know about?
<bryce> infinity, maybe brad or bdmurray?
<infinity> bryce: I see no brad, and bdmurray isn't kernel.
<herton> infinity, sorry, I don't know about this one
<sconklin> infinity: looking. It's brad's but he's on the road, I should have perms to deal with it
<sconklin> someone most have already killed them
<sconklin> infinity, herton: I see nothing the the logs indicating a problem, and only two copies running (which is still a problem). I'm going to just remove it from the crontab and email brad, as I'm about to bail for the holiday. Probably no one will notice if it doesn't regenerate bug reports until Monday, and Brad may get to it before then
<herton> sconklin, ack
<infinity> sconklin: Thanks.  I suspect a bit of trivial locking wouldn't be hard.  Or one could ask IS to install run-one on lillypilly, and wrap it with that.
<sconklin> infinity: agreed What I suspect happened is that it runs every half hour, and it just reached a runtime of over that.
<infinity> sconklin: Well, the desktop team had a script throwing the machine into swap death, so it handily exposed everyone else who had scripts that failed to lock. ;)
<sconklin> haha, ok
#ubuntu-kernel 2012-11-22
<ppisati> brb
 * apw notes he is currently away from his mic
 * smb would not have noticed
<apw> sconklin, infinity, i have just added mutual exclusion to the last two crontab entries as examplers
 * ppisati -> gos out for a bit
<ppisati> *goes
 * apw wanders home
<AbsintheSyringe> when will kernel3.6 get into quantal?
<apw> AbsintheSyringe, quantal will not get any version bumps
<AbsintheSyringe> apw, it will remain on 3.5?
<apw> yes
<AbsintheSyringe> :-/
<apw> this has always been how things are in stable releases
<apw> for any and all packages
<AbsintheSyringe> I thought it would move to 3.6 for some reason
<AbsintheSyringe> the reason I'm asking is because I'm coming from Debian Sid and I used 3.6.2 afaik and it all worked fine
<AbsintheSyringe> however on quantal (3.5) my machine tends to get bit hot
<AbsintheSyringe> ThinkPad X1 Carbon
<apw> debian sid is the deveopment release
<AbsintheSyringe> I'm aware of that
<apw> raring is ours, and has 3.7 kernels in it
<AbsintheSyringe> I think I might do apt pinning and install 3.7 from raring
<xnox> apw: but the raring kernel will at some point in the future be available on precise?
<apw> xnox, in precise it will be made available, sometime after raring releases
<xnox> interesting.
<xnox> thanks.
<apw> opt-in only of course
<apw> AbsintheSyringe, if you work out the incantations to get that working i would be interested
<AbsintheSyringe> apw, after 5+ years on Debian Sid I was trying to get some bit more stable with Ubuntu
<AbsintheSyringe> apw, it's kinda awkward coming from Debian Sid to Ubuntu "Sid" :)
<AbsintheSyringe> but am thinking about it 
<xnox> ... and first thing you do is mix two releases.
<xnox> AbsintheSyringe: to be honest maybe you should run raring. As all uploads go into raring-proposed & britney migrates them to raring, but without waiting for 10 days delay nor checking for RC bugs.
<apw> AbsintheSyringe, your other option is to try and work out what the fix was in 3.6 for your issue; and we can sru that into Q
<xnox> AbsintheSyringe: that way it's more stable than sid, yet still with high-velocity crack.
<AbsintheSyringe> xnox, am seriously considering option
<AbsintheSyringe> apw, how much do you prefer the apt pinning option?
<apw> prefer it over what?
<AbsintheSyringe> because back on debian I had, apt pinning with testing and experimental
<AbsintheSyringe> over doing a "bare" upgrade on raring
<AbsintheSyringe> this way I could still use quantal but use the raring kernel
<apw> i don't apt pin anything currently, i have some systems on Q and some on R
<apw> R has been supprisingly ok so far on those, but they are far from production platforms
 * xnox runs raring since opening.
<apw> xnox, but X hasn't updated yet, so who knows how smooth that will be
<AbsintheSyringe> xnox, is that your "production" machine? 
<AbsintheSyringe> apw, right
<ogra-cb> qunatal was really smooth
<xnox> well I have raring with quantal-updates & quantal-security enabled. I am still seeing stuff uploaded into quantal pockets without matching raring upload.
 * ogra-cb wouldnt expect worse from raring
<xnox> AbsintheSyringe: my definition of "production" is skewed, as it's part of my job to fix ubuntu if ubuntu+1 is broken.
<AbsintheSyringe> according to status raring is 14% complete http://status.ubuntu.com/ubuntu-raring/
<apw> ogra-cb, i don't remember it being quite that smooth, i remember a couple of my boxed being a heap for some days
<ogra-cb> appulli, yeah, because you use that intel crap :P
<ogra-cb> err
<ogra-cb> apw, 
<xnox> AbsintheSyringe: that's feature work only. On day one we synced hundrets of package updates from debian.
<apw> xnox, those get 'sorted' by archive-admin intervention over time though i believe
<xnox> =)
<apw> ogra-cb, heh indeed i do, the stuff they claimed to have tested too :)
<AbsintheSyringe> I think I'll give raring a go, it can't be worse then Sid that's for sure :)
<ogra-cb> haha
<apw> AbsintheSyringe, it has been better than average so far at least here
<ogra-cb> definitely flawless on my chromebook here 
<AbsintheSyringe> wow
<xnox> AbsintheSyringe: do not enable raring-proposed, as by definitions packages there are yet to built & be installable.
<apw> yeah very important, no -proposed as you are in a world of pain there
<apw> xnox, that said that is also where a huge pile of the updates from debian are lurking
<ogra-cb> proposed should never be used ever 
<AbsintheSyringe> xnox, tnx
<ogra-cb> only for cherry picking packages for tests 
<AbsintheSyringe> apw, situation on Sid right now is pain, a lot of pain
<xnox> apw: that is simply intensives to fix stuff pointed out by britney.
<ogra-cb> (thats not raring specific)
<xnox> "do you want this shiny package? well fix this armhf build failure first and then you can have it!"
<ogra-cb> hehe
<apw> if only it worked like that :)
<xnox> in practice, you have doko syncing straight into raring-release bypassing this kindergarden =)
<ogra-cb> haha
<apw> heh, i didn't know one could do that
<ogra-cb> qwll, you shouldnt :)
<ogra-cb> Well even
<xnox> apw: only if you happen to have archive-admin rights  & use outofdate ubuntu-dev-tools / copypackage.
<AbsintheSyringe>  xnox apw will do the job? sudo sed -i 's/quantal/raring/g' /etc/apt/sources.list && sudo apt-get update && sudo update-manager -d -c
<apw> either update-manager -d, or sed... update ... dist-upgrade
<AbsintheSyringe> oh-kie
<smb> apw  -> do-release-upgrade -d 
<smb> (i suppose by now it was fixed)
<xnox> AbsintheSyringe: update-manager -d (graphical) or do-release-upgrade -d (text only) same functionality otherwise.
<AbsintheSyringe> xnox, k, tnx
<infinity> hggdh: Any progress on https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1068733 ?
<ubot2> Launchpad bug 1068733 in linux-armadaxp (Ubuntu Precise) "linux-armadaxp: 3.2.0-1610.15 -proposed tracker" [Undecided,In progress]
<infinity> hggdh: Will it be done today? :)
<infinity> hggdh: Pretty please? :)
<hggdh> infinity: it's turkey day in the US. I got some scripts from rbasak yesterday, and will work on them tomorrow
<hggdh> (I was only at the laptop cuz my bloody internet connection went south again)
<infinity> hggdh: Ah, I didn't check the directory to see if you're American. :P
<hggdh> infinity: I am now :-)
<infinity> Heh.
<infinity> Enjoy your turkeying, then.
#ubuntu-kernel 2012-11-23
<ppisati> ro
<ppisati>  / ro
<ppisati> [ 6827.767493] ata1.00: exception Emask 0x0 SAct 0xffffff SErr 0x880000 action 0x6 frozen
<ppisati> [ 6827.767497] ata1: SError: { 10B8B LinkSeq }
<ppisati> [ 6827.767499] ata1.00: failed command: WRITE FPDMA QUEUED
<ppisati> [ 6827.767516] ata1.00: cmd 61/08:00:90:4f:4a/00:00:06:00:00/40 tag 0 ncq 4096 out
<ppisati> [ 6827.767516]          res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
<ppisati> [ 6827.767517] ata1.00: status: { DRDY }
<ppisati> [ 6827.767518] ata1.00: failed command: WRITE FPDMA QUEUED
<ppisati> [ 6827.767521] ata1.00: cmd 61/68:08:c0:b9:47/00:00:0d:00:00/40 tag 1 ncq 53248 out
<ppisati> [ 6827.767521]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
<ppisati> [ 6827.767522] ata1.00: status: { DRDY }
<ppisati> ...
<ppisati> [ 6828.122829] ata1.00: device reported invalid CHS sector 0
<ppisati> [ 6828.122836] sd 0:0:0:0: [sda]
<ppisati> [ 6828.122837] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
<ppisati> [ 6828.122838] sd 0:0:0:0: [sda]
<ppisati> [ 6828.122839] Sense Key : Aborted Command [current] [descriptor]
<ppisati> [ 6828.122841] Descriptor sense data with sense descriptors (in hex):
<ppisati> [ 6828.122842]         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
<ppisati> [ 6828.122846]         00 00 00 00
<ppisati> [ 6828.122848] sd 0:0:0:0: [sda]
<ppisati> [ 6828.122850] Add. Sense: No additional sense information
<ppisati> [ 6828.122851] sd 0:0:0:0: [sda] CDB:
<ppisati> [ 6828.122852] Write(10): 2a 00 06 4a 4f 90 00 00 08 00
<ppisati> [ 6828.122856] end_request: I/O error, dev sda, sector 105533328
<ppisati> [ 6828.122858] quiet_error: 3 callbacks suppressed
<ppisati> [ 6828.122859] Buffer I/O error on device sda1, logical block 13191410
<ppisati> [ 6828.122860] lost page write due to I/O error on sda1
<ppisati> ...
<ppisati> [ 6828.123406] Buffer I/O error on device sda1, logical block 9537386
<ppisati> [ 6828.123407] Buffer I/O error on device sda1, logical block 9537387
<ppisati> [ 6828.123409] EXT4-fs warning (device sda1): ext4_end_bio:250: I/O error writing to inode 3812130 (offset 995328 size 8192 starting block 9537644)
<ppisati> [ 6828.123411] ata1: EH complete
<ppisati> [ 6828.123655] EXT4-fs (sda1): Remounting filesystem read-only
<ppisati> [ 6828.123658] EXT4-fs error (device sda1) in ext4_free_blocks:4700: Journal has aborted
<ohsix> eh
<ppisati> [ 6828.123667] journal commit I/O error
<ppisati> [ 6828.123697] EXT4-fs error (device sda1) in ext4_dirty_inode:4610: Journal has aborted
<ppisati> [ 6828.123740] EXT4-fs (sda1): ext4_da_writepages: jbd2_start: 9223372036854775807 pages, ino 9213275; err -30
<ppisati> [ 6828.123768] EXT4-fs error (device sda1): ext4_journal_start_sb:370: Detected aborted journal
<ppisati> [ 6828.123803] EXT4-fs (sda1): ext4_da_writepages: jbd2_start: 9223372036854775807 pages, ino 9213273; err -30
<ppisati> [ 6828.123844] EXT4-fs error (device sda1) in ext4_orphan_add:2420: Journal has aborted
<ppisati> [ 6828.124019] EXT4-fs error (device sda1) in ext4_orphan_add:2420: Journal has aborted
<ppisati> [ 6828.124021] EXT4-fs error (device sda1) in ext4_orphan_add:2420: Journal has aborted
<ppisati> [ 6828.124083] EXT4-fs error (device sda1) in ext4_reserve_inode_write:4483: Journal has aborted
<ppisati> [ 6828.124158] EXT4-fs error (device sda1): ext4_journal_start_sb:370: Detected aborted journal
<ppisati> [ 6828.124258] EXT4-fs error (device sda1) in ext4_reserve_inode_write:4483: Journal has aborted
<ppisati> ok, need to reboot and fsck
<cking> ppisati, bitten again?
<ppisati> yes
<ppisati> haswell and intel ssd
<cking> ppisati, what kind of workload?
<ppisati> i need to find if there's a new firmware for that ssd now
<cking> which SSD?
<ohsix> ppisati: smart logs can tell you where and why those WRITE FPDMA QUEUED errors happened
<ppisati> cking: nothing
<ppisati> cking: editing files, terminal with mutt, irssi and some sshs
<ppisati> cking: chrome was open too
<ppisati> ohsix: but i guess i need smartd running, right?
<cking> that's what I saw on my  Intel 520
<smb> ppisati, If I were around I would first suggest to see whether the "Buffer I/O errors" are within the drive/partition space
<cking> smb, you on vacation?
<ohsix> ppisati: nope, smartctl -l error /dev/device
<smb> cking, Its "no-work-friday"
<cking> smb, you're as bad as me
<ohsix> the device stores a bunch of logs, an error log is one of them
<ppisati> ohsix: SMART Error Log not supported
<cking> ohsix, not sure if it is supported on some intel SSDs
<cking> oh, that's what I get too
<ppisati> smb: it mentioned sda1, so it should be within partition bounds
<ohsix> bummer
<ohsix> there may be an alternate report, smartctl -x lists everything
<smb> ppisati, In theory yes, though I am not 100% sure which boundaries are exactly checked at which level, butyes. Though the initial error was some dma write failing. And then some weird thing about invalid chs sector 0...
<mIKEjONE2> hello, does anyone know how to use debian/rules to run make bzimage?
<mIKEjONE2> after successfully building a kernel I wanted to make a few corrections
<smb> cking, I am not really working, really. ;) I was just around to complain about jockey being broken now and the steam client steaming about it a bit. And apport not generating bug reports but only updates on errors.u.c which is hard to check for success or not
<cking> ppisati, so you got hit by a link sequence error and I suspect then the SSD just popped offline
<mIKEjONE2> but it seems as if build/rules binary-generic does not care about changes I make to .c files because make bzImage is never rerun
<mIKEjONE2> it seems like runing build/rules clean ; build/rules binary-generic is a very poor way of recompiling the kernel, especially when I barely add a single printk
<ppisati> cking: so more of a ATA bug then, but the ctrl communicates with the ssd so it could any of them actually
<cking> ppisati, so it looks like an issue on the link, you got 10b8b and a LinkSeq error, so it looks like the SATA link got all weird
<smb> mIKEjONE2, You may try to remove the build stamp file in debian/stamps (I believe) and skip the clean part
<ppisati> cking: this is the haswell box, could be a bug in the ctrl then
<ppisati> cking: or even silicon
<smb> ppisati, Has that box a easy-swap drive bay like mine?
<ppisati> smb: yes
<smb> ppisati, You could replace the ssd by another disk to rule out the ssd
<cking> ppisati, I got the same issue on Ivybridge with an Intel 520 SSD. So it may be SSD related or H/W related on the chipset, or both, or who knows
<ppisati> i bet on "who knows"
<cking> ppisati, but I didn't see the issue with the same SSD on a Core2 laptop
<ppisati> smb: i'll try to update the fw, in cae it happens again i'll swap the disk
<ppisati> (but it's nice to have a fast ssd... :) )
<cking> ppisati, lemme rig up a spare Intel SSD on one of my SDP's and soak test it and see if we can characterise the bug
<ppisati> when it doesn't crap out...
<mIKEjONE2> so how do you guys recompile the kernel after modifying some of the source files?
<mIKEjONE2> smb: that worked pretty well :) thanks
<mIKEjONE2> I'm kind of surprised there's no better solution :/
<smb> mIKEjONE2, We have a quick build box we share, so it is not really an issue, and recompiling the whole just makes sure everything really is done freshly and we are also a bit paranoid about that. ;)
<mIKEjONE2> smb: I'm running this on a 6core i7 with 32GB of RAM + an SSD and it still takes 20mins :/
<cking> mIKEjONE2, yep, 11 million lines of code, does take a while to build and package :-(
<smb> there is always a good time to get another cup of coffee/tea or beer (depending on time of day) :)
<cking> smb, I use build time to catch up on LKML
<smb> cking, I knew I was doing something "wrong"...
<mIKEjONE2> cking: well, not really, if you're building a bzimage without debian/rules framework, and you change a single file you don't have to rerun make mrproper and start from scratch
<mIKEjONE2> make is smart enough to figure that out
<mIKEjONE2> not quite sure why the debian/rules framework is intended for developers when its build capabilities are so crippled
<cking> mIKEjONE2, use: rm debian/stamps/stamp-build-generic and then fakeroot debian/rules binary-generic, that will save a complete rebuild
<cking> ppisati, which intel SSD do you have?
<ppisati> cking: dmesg says
<ppisati> [    4.066991] scsi 0:0:0:0: Direct-Access     ATA      INTEL SSDSC2CW24 400i PQ: 0 ANSI: 5
<ppisati> 520?
<ppisati> 400i is latest 520 fw
<cking> same as mine 520
<mIKEjONE2> cking: yea smb suggested that as well, and it works
<mIKEjONE2> I'm just a little grumpy because I spent an hour on 3 rebuilds because I didn't know that trick :/
<cking> :-(
<mIKEjONE2> alternatively I just removed the touch $@ for the build-stamp rule from debian/rules.d/2-binary-arch.mk, this way I don't have to manually rm the file :D
<cking> oh, that's way less of a hack, nice
<Tassadar> Hi, I've sent patch to kernel-team@lists.ubuntu.com yesterday, but it did not show up in the archives. I am being told that I have to be subscribed to the mailing list, is that right?
<diwic> is it expected that "linux-image-generic" is listed as one of the packages I can remove with 'apt-get autoremove'?
<ppisati> and after an entire day of printk and debugging i finally found why we can poke at iomem space safely in Q (contrary to what happened to P)... ohhhhhhh....
<cking> ppisati, nice
 * ppisati calls it a day/week and heads to the gym for some ignorant weight lifting! :)
#ubuntu-kernel 2012-11-24
<yf-geek> Hi all, I am using kubuntu 12.04 and sometimes I experience complete system lockup. I highly suspect that i have spinlock problems. I am trying to find a debug build kernel on the ubuntu repository but couldn't find any.
<yf-geek> Does this means that I have to manually compile the kernel with debugging mode enabled?
<yf-geek> If compiling is the only option, I hope you all can shed some light on how to do it; I have never compiled a kernel before...
<yf-geek> anyone?
<apw> yf-geek, we don't have builds with debug generally no
<apw> yf-geek, in theory this page will help you: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<yf-geek> ok, thanks...
<bantu> Hey. Anyone working on fixing http://kernel.ubuntu.com/ ?
<apw> bantu, the appropriate admins are aware, i have no information as to cause as yet
<bantu> apw: thanks, I just wanted to make sure someone is working on it
<BenC> Is kernel.ubuntu.com down?
#ubuntu-kernel 2012-11-25
<infinity> BenC: Yeah, zinc's having a hissy fit.
<infinity> BenC: I wouldn't hold my breath on a resolution before Monday.
<DNS> heya:) have a question about the kernel source. is all in ubuntu and include/uapi folder on a free license?
<yf-geek> I have a question, when building pae kernel, what things should I watch out for?
<yf-geek> it seems like the normal i386 builds takes longer than the pae version
<yf-geek> i mean the compilation time is much longer
<dontknow> i cant enter http://kernel.ubuntu.com  could you verify
<dontknow> where can i download ubuntu kernel patches
<ohsix> on launchpad, where bzr trees are also available
<dontknow> ohsix: i don't know what to download, could you sent me the direct link for that, i would appreciate
<ohsix> how do you know you need kernel patches then?
<dontknow> ohsix: i dont
<lifeless> heh
<tyf> hi all, do I need any special configuration to build a pae kernel? using the latest edition in precise
<tyf> it seems like the normal kernel needs a much longer time to build?
<tyf> the pae is faster to finish compilin
<tyf> g
<infinity> tyf: Why do you need to build a PAE kernel; we provide one...
<tyf> i need to build a debug version of the kernel, which is not available as a binary version
<tyf> it suffers complete lockup randomly 
<tyf> even the magic sysrq key cannot do anything
<infinity> http://ddebs.ubuntu.com/pool/main/l/linux/linux-image-3.2.0-33-generic-pae-dbgsym_3.2.0-33.52_i386.ddeb <-- Debug symbols for the distro kernel.
<ohsix> yea, ddebs has the debug symbols stripped from any built package
<ohsix> you can add it as a source and install them with apt-get, and there's a script to grab debug symbols automatically but i forget the name of it
<infinity> Hrm.  Looks like my routing across the Atlantic finally got fixed.
<infinity> 100%[==========================================================>] 668,691,426 11.2MB/s   in 91s    
<infinity> I can live with 11.2MB/s from London to Calgary.
<infinity> Oh, or macquarie's just on a different link than archive.
<tyf> hey, i do i use the debug symbols? i am quite new to kernel compiling
<tyf> *how do i
<infinity> It's entirely possible that, in the kernel's case, the ddeb just contains the unstripped/debug version of the kernel, rather than detached symbols.
<infinity> apw: ^?
<infinity> tyf: Assuming that's the case, you'd just install the above package (or, the one matching your distro kernel) with "dpkg -i foo.ddeb", cp /boot/vmlinuz-$(uname -r) /boot/vmlinuz.backup; cp /usr/lib/debug/vmlinuz-$(uname -r) /boot
<infinity> tyf: Potentially doing the same for the modules, if you want debug versions of those too.
<infinity> tyf: After installing the ddeb, "dpkg -L package_name" to see what it installed and where.
<tyf> what can the debug package above do more than increased verbosity of kernel log?
<tyf> infinity:^
<infinity> Well, it can do a lot of useful things if you plan to attach a debugger...
<infinity> I'm getting the impression this might not be what you meant by "debug your kernel" at all.
<ohsix> perf and other tools can see what symbols are near what addresses and unwind stacks too
<tyf> infinity: actually i don't have the experience of attaching a debugger to the kernel. I am just trying to make the kernel  to generate more logs during the course of system freeze. Now i don't have a clue what might be happening in the system!
<tyf> i checked the syslog and kern logs but couldn't find any log at the moment when freeze happened
<tyf> no messages like "soft lockup detected" and "hard lockup detected" messages are found
<tyf> fyi, i am not developing the kernel...i am just trying to help out the developers as a end user
<apw> infinity, indeed the .ddebs are unstripped complete kernel .ko's et al
<infinity> apw: S'what it looked like from the file list, but I've never used one.
<tyf> so, what is the best i could do as a user to help kernel developers?
#ubuntu-kernel 2013-11-18
 * ppisati didn't get the egg thing, but it's ok...
<cking> ppisati, http://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs
<cking> http://regimentalrogue.com/papers/egg.htm
<apw> cking, heh thanks :)
<apw> ppisati, i am inviting you to a hangout for testing
<apw> which you may, or may not, be able to accept
<ppisati> apw: about egg sucking? :)
<apw> well you might have gotten the description
<ppisati> :)
 * apw goes for lunch ... and yes GOES
<arges> smb: hello
<smb> arges, Hi there
<arges> smb: would you have time today to review a crash merge?
<smb> arges, You may have email ;)
<smb> Oh wait
<smb> crash merge
<smb> dammit
<arges> smb: yea, other issue. sorry 
<smb> maybe
<smb> if you point me to the merge
<arges> smb: sure which files would be useful? or shoudl i just upload the directory
<smb> arges, Hm, you got the merged source package files somewhere. I can pull the Debian part
<arges> smb: ok i'll upload to p.c.c
<smb> So without the orig tar is good enough
<smb> arges, That or chinstrap is fine
<arges> smb: uploading. I build for amd64/i386/armhf
<smb> arges, Ok, iirc we did not have many differences left
<arges> smb: yea caribou has been helping make sure our changes have been merged, and he helped out with this one as well
<arges> which reminds me, i'll need to update the changelog to include credit for Louis as well
<smb> Guess I had done a bit of that too, but meh
<smb> ah apparently there was another ftbs in the new version
<arges> smb: http://people.canonical.com/~arges/merges/crash/
<arges> smb: i didn't hit any FTBFS just using the debian rules/
<smb> arges, Oh I was referring the the one that caribou fixed
<smb> I remember having had been looking at one a while back (having to do with pic register usage in inline assembly). Not sure it was the same and I failed to report upstream
<smb> Though the last trusty rebuild must have succeeded I guess (7.0.2)
<smb> arges, Hm, did you merge from 6.1.6?
<arges> smb: 6.16 to 7.0.3
<arges> although i see 7.0.2 is in the trusty archive
<jcz> im having problems with booting 3.8.0-34-generic kernel from ubuntu armhf repo on a laguna GW2388-4 arm board. After trying to boot the kernel with initrd nothing shows up on serial. Bootargs are: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait rw. Do you guys have any idea what could be wrong? The bootloader is uboot and its working fine (booting openwrt from flash)
<smb> arges, Yeah it was failing for i386 (for exactly the reason I failed to send a change upstream but caribou did, doh!)
<arges> smb: so should we re-merge 7.0.3 then?
<smb> arges, I guess it should not matter for except including those parts of the changelog... 
<caribou> isn't 7.0.2 there just because of the automatic sync ?
<smb> caribou, It was a manual one
<arges> caribou: looks like doko did it
<caribou> 7.0.2 did build on amd64 but it FTBS on i386
<caribou> hmm, 2nd time I waste time on merging pkg that some other people did
<smb> Somehow I remember having a quick look at that merge but apparently did not test compile on i386
<smb> caribou, At least it was done not that well
<smb> And I must beat myself for not subitting that bugfix myself
<caribou> smb: hehe :-)
<caribou> smb: well at least now, the delta b/w ubuntu & debian is minimal
<smb> I can remember having done a fix for it, too but then... gone
<smb> caribou, Yeah that is cool
<smb> arges, So _i_ would insert the missing changlog into your merge only... Not sure this is the _right_ thing, though
<arges> smb: well i need to start with the 7.0.2 package and merge 7.0.3 I think
<smb> apw, ^what would another cdev think? :)
<smb> arges, I just think there was not much diff except arm64 and armhf in control and autopkgtest
<smb> arges, which just get dropped...
<smb> but ok for fully compliantness
<arges> there are additional fixes in 7.0.3 + louis's i386 ftbfs + my autopkgtest merg
<smb> arges, Yes, though for the merge you basically replace the orig.tgz and whether you do that from 6.1.6 or 7.0.2 should in the end be the same. Just the diff of 7.0.2 to the ubuntu version would have the autopkg test added which you either not add or drop... 
<smb> arges, But I guess better fallow the simple standard approch is better than trying to be smart
<arges> smb: yea just re-doing the merge (its fairly simple)
<arges> grab-merges didn't pick it up because it never got beyond proposed
<smb> arges, true. so when you are done, let me know and I pull it down and have a quick review
<arges> smb: ack thanks
<arges> smb: which arches should we include
<arges> i386 ia64 alpha powerpc amd64 armel armhf arm64 s390x
<arges> do I leave all? or drop some?
<apw> arges, we will only build on the intersection of the ones on the debian list, or that we actually have in the archive for the release you are uploading for
<apw> which is fine if its the ones you want
<arges> apw: ok then i'll keep what debian upstream has plus armhf/arm64
<apw> that list has armhf
<arges> apw: yea ubuntu adds armhf/amd64, debian doesn't have those arches in its control file
<arges> that's the remaining changes
<arges> apw: btw is it ok to merge after a pacakge has already been merged?
<arges> in a development cycle
<apw> to roll our changes forward to a second or third debian update
<apw> sure ...
<arges> cool, plus alleviate our delta a bit more
<arges> and more fixes etc
<arges> smb: http://people.canonical.com/~arges/merges/crash/crash.v2/
<arges> smb: that's the smaller merge then
<smb> ok. otp right now. will look in a sec
<arges> smb: np
<smb> arges, seems you don't want me to look at some files (permission)
<smb> ;)
<arges> smb: hmm...
<arges> permissions are fine on my end
<smb> /home/arges/public_html/merges/crash/crash.v2$ ls -la
<smb> -rw------- 1 arges warthogs    67898 Nov 18 14:30 crash_7.0.3-3ubuntu1.diff.gz
<arges> smb: ok try now
<smb> arges, great now I cannot even ls the dir. :)
<arges> smb: try now
<arges> my brain is still warming up 
<smb> arges, better
<smb> Reminds me of mine this morning
<smb> arges, Where you a better contributor than me and have let Troy know about the messed up shebang thing?
<arges> smb: no, i need to submit that
<arges> so he moved the EOF, and removed stderr from the autodpkgtest permissions
<arges> but I think stderr is needed if -x is on, which if the shebang doesn't execute it doesn't matter
<arges> so I need to fix it, and resubmit
<smb> arges, Oh, hm. I only saw the change of adding ! to #!/bin/sh
<arges> yea i'm tweaking it more now
<smb> Ah ok, though that unlikely makes a difference on the overall merge... on a quick glance that one does look good to me (iow nothing (much) to see, moving on)
<smb> hm, time to create local trusty chroots...
<vijaya> how could we read the VMA content from vm_area_struct?
<vijaya> my attempt to do so returns only zeros. some sites says it is due to no Read premission. How to change the premission? Plz help me.
<jcz> is there any way to determine the load address and entry point using only the kernel image?
<apw> vijaya, i don't think there is enough info in your question to know what you are asking
<apw> jcz, of the kernel on what arch, on most it is relocatable so up to the bootloader
<jcz> armhf, generic kernel from repo
<jcz> im trying to boot it with uboot but no idea where to find those addresses needed
<jcz> i guess i can get it when compiling the kernel
<jcz> or maybe even generate uImage directly, but i wanted to use the repo one
<apw> ppisati, ^^ any idea
<ppisati> jcz: actually when you generate the uImage you'll have to specify at which address you are going to load it
<ppisati> jcz: so, zImage has no embedded info, while uImage has it
<ppisati> jcz: and those info are boot loader/loading script dependent
<vijaya> apw, actually i have used kernel module to read task_struct, mm_struct and vm_area_struct. using mmap list i can know the virtual address of start and end of the all VMA's . i tried to used copy_from_user but it return zero bits for most the VMA.
<apw> vijaya, i would suggest looking at the core dump code as that does that
<jcz> ppisati: by those info you are referring to load address and entry point? I thought that this is kernel specific
<ppisati> jcz: kernel is relocatable, as i said
<apw> ppisati, that implies the zimage payload is relocatable
<ppisati> right
<apw> which is as they say normal on generic kernels, cool
<apw> ppisati, i assume it made sense to copy those saucy config changes forward to T
<jcz> jcz: so i guess that load address and entry point have to be in a specific relation so that we hit some spot in the kernel loaded @ load address? am i correct?
<ppisati> apw: yes
<apw> ppisati, ta 
<stgraber> would I be right to assume that bug 1251946 would become a whole lot more important if I can reproduce it with the current trusty kernel?
<ubot2> Launchpad bug 1251946 in linux (Ubuntu) "Network related kernel panic on Atom 64bit system using saucy backport stack on precise" [Undecided,Confirmed] https://launchpad.net/bugs/1251946
<apw> stgraber, in theory trusty matters less to us than a stable release
<stgraber> ok
<apw> stgraber, it being reproducible is interesting whereever it is so reproducible
<stgraber> I'll test anyway, since I don't like the idea of my firewalls randomly panicking when I upgrade them to the new LTS :)
<apw> we are interested in anything like that, if it can be repro'd so we can try and smack it down
<stgraber> I'll give the current saucy-proposed a try first as the changelog contains a lot of network related fixes, maybe that'll magically fix it, if not, I'll try our current 3.12 and if that still doesn't fix it, then I'll see if I can figure out a way to reproduce it in a VM
<stgraber> though it seems to only affect the one box where I have bond+bridge+vlan+dual-stack firewall. Those without the bond don't show the issue, so it'll be a fun reproducing environment...
<stgraber> and I also have systems with bond+vlan+bridge that don't show the problem...
<arges> smb: ok now lets see if that i386 ftbfs go away for crash...
<smb> arges, It did compile for me
<arges> yea me too
<arges> so, pretty confident it will work
<smb> yup, so only any changes to the autotest script I have not seen but I would trust you there
<stgraber> apw: seems like the current -proposed kernel is a significant improvement, I'm no longer getting the Oops at boot time and it's been over 4 minutes without a panic so far (all time record when using a 3.11 kernel on that box). I'll wait a couple more hours before considering the -proposed kernel as fixing the issue though :)
<apw> stgraber, sounds good though, there is a  heap of stable on that kernel
<stgraber> yep, I was going through the list and found a dozen that seem to apply to my specific setup ;)
<apw> stgraber, and this is one reason that for the normals out there (you arn't one) we don't recommend the lts saucy backport till we get to the point release
<stgraber> apw: spoke too soon... http://paste.ubuntu.com/6438234/
<apw> stgraber, heh you have ipv6, you are so out there on your (nearly own) sigh
<apw> or indeed is that your v6 tunnel that is exploding the world
<stgraber> it's not a tunnel
<stgraber> I have native IPv6 here
<stgraber> and all my other firewalls do too and haven't blown up yet since the switch to 3.11
<stgraber> anyway, installing a 3.12 kernel before the next panic, let's see if that's somehow more reliable
<stgraber> it's annoying that it now takes more than 5 minutes for the panic to show up though, ...
<apw> stgraber, yeah well though that does give you enough time to install a new kernel
<stgraber> 5min was way enough to switch kernels ;)
<apw> stgraber, there are some changes in the functions that implode after 3.11 so you may seem some difference there
<stgraber> apw: didn't even last a minute on 3.12
<apw> stgraber, the mix of 6 and 4 functions in that stack seem as if we are tunnelling, but you arn't using that right?
<stgraber> I tunnel some IPv4 traffic over IPv6 in an IPSEC tunnel
<stgraber> http://paste.ubuntu.com/6438301/ is the 3.12 one
<apw> [ 54.052018] Kernel BUG at ffffffff81607e40 [verbose debug info unavailable]
<apw> when did we stop having the right lines listted
<apw> there are two 'bugon's in that function
<xnox> rtg: apw: small config change request for goldfish https://bugs.launchpad.net/ubuntu/+source/linux-goldfish/+bug/1252339
<ubot2> Launchpad bug 1252339 in linux-goldfish (Ubuntu) "Please enable EFI partitions on goldfish/armhf targets" [Medium,Confirmed]
<rtg> xnox, ack
<apw> xnox, in trusty ?
<xnox> yeap, for trusty.
<rtg> apw, I think trusty is the only release where the emulator works
<stgraber> apw: once I'm done with a mumble meeting, I'll our 3.8 and 3.5 backport kernels on that box. So far I know 3.2 works fine (been running that for well over a year without panics) and I know current is broken, so I'll see if I can track down approximately when things broke.
<xnox> rtg: well, things that "work" is increasing. e.g. unity is still waiting for patches to be uploaded in various packages.
<rtg> xnox, right, but that is still just in trusty.
<apw> stgraber, sounds good, and i'll pop a version of the saucy kernel so we know which of those two go BUG's it is
<xnox> rtg: yeap.
<apw> stgraber, http://people.canonical.com/~apw/lp1251946-saucy/ <-- is a kernel (saucy level) which has some debug turned back on
<stgraber> apw: ok, I'll try that one next.
<stgraber> apw: 3.8 is affected too, I'm testing 3.5 now
<apw> stgraber, good info indeed, i expect that one to implode the same but at lest say which bug on is tripped
<apw> (that one == the one i pasted above)
<apw> 3.5 if it is affected might also give us the same clue, so be interested in the dmesg from that one
<stgraber> apw: 3.5 seems stable so far, I'll let it run until I'm done with lunch, if it doesn't panic by then I'll consider it good and reboot on your 3.11
<apw> stgraber, heh, poor firewall, some day i'd love to know how that thing is setup and why it is so very comple
<apw> complex
<stgraber> well, I actually simplified my firewalls a bit recently by dropping BGP ;) but for the rest, all of the firewalls I managed are dual-stack, they all talk to each other over IPSEC using the IPv6 link and sending the internal IPv4 traffic over that same tunnel, and then on the internal end, they are connected to managable switches over two links, so do bonding, vlans and bridges. All traffic between vlans goes through a dual-stack iptables f
<Guest16327> Hi my name is Vaithi. I am new to open source community. I wish to contribute to ubuntu kernel. Anybody can guide me on how to start with some bugs and then walk my way up slowly?
<Guest16327> Thanks
<Guest16327> Anybody please?
<apw> Guest16327, i think i may have just replied to your email
<Guest16327> Oh Hi Andy. Sorry for the question again. I thought I had to contact in the IRC too. Thanks.
<stgraber> apw: got an hour of uptime on 3.5 and no panic, rebooting on your 3.11 now
<stgraber> apw: and just got it to panic, dump in bug 1251946
<ubot2> Launchpad bug 1251946 in linux (Ubuntu) "Network related kernel panic on Atom 64bit system using saucy backport stack on precise" [High,Confirmed] https://launchpad.net/bugs/1251946
<stgraber> testing the mainline 3.6 now
<rtg> xnox, goldfish awaits in trusty https://launchpad.net/~canonical-kernel-team/+archive/ppa. I forgot to noe in the changelog that I also relaxed the armhf compiler version restriction. it now uses 4.8 (so please try it out)
<rtg> apw, ogasawara: do you have anything pending for trusty ? master-next has accumulated enough cruft that its likely time to upload.
<ogasawara> rtg: nothing for me
<rtg> apw, I picked up CONFIG_DEBUG_BUGVERBOSE=y from bug #1252353
<ubot2> Launchpad bug 1252353 in linux (Ubuntu Trusty) "CONFIG_BUGVERBOSE should be enabled (=y) to ensure BUGs produce the line information needed" [Medium,In progress] https://launchpad.net/bugs/1252353
<stgraber> jsalisbury, apw: so looks like the issue was introduced with 3.8
<jsalisbury> stgraber, ack.  We will want to test some of the 3.8 release candidate kernels to find which exact one introduced the bug.  I can post links in the bug report.
<stgraber> jsalisbury: ok
<jsalisbury> stgraber, thanks for testing
<stgraber> jsalisbury: rc4 and rc2 are both bad, testing rc1 now
<jsalisbury> stgraber, thanks
<stgraber> jsalisbury: got anything else for me to test? :)
<jsalisbury> stgraber, I can start a bisect and build a test kernle once we know if rc1 is bad or not
<jsalisbury> stgraber, Just to confrm, 3.7 was good?
<stgraber> yeah, I ran 3.7 for over 40min without a panic
<stgraber> doesn't mean it wouldn't have paniced a minute later but seems unlikely as 3.8 usually paniced within 2-3min of boot
<jsalisbury> stgraber, ok
<Guest16327> jsalisbury: This is Vaithi, you got anything for me to start looking at? Thought of asking, since you were talking about some test. Thanks.
<jsalisbury> Guest16327, nothing specific as of yet.  What might help is to see if any bugs exist for hardware that your currently have.  Then see if you can reproduce the bug on your hardware.  
<Guest16327> jsalisbury, I have a 64 bit system running a 32 bit kernel. I usually use virtual box for multiple copies. I have a Dell chipset. Do you want me to just search for such hardware or is there any other way? 
<jsalisbury> Guest16327, sure, searching for similar hardware is one way to go.  You can use lspci, dmidecode and/or dmesg to get more details about your hardware and use that info to search for bugs.
<Guest16327> Jsalisbury, Great. I will do that and ask any questions if I have. Thanks
<jsalisbury> Guest16327, great. 
<shnatsel> Hello everyone
<Guest16327> Jsalisbury, Out of curiosity, will everyone working on the bugs have most possible hardware in order to service all the bug requests? 
<shnatsel> I come from #checkbox to check what the support status for zram (bundled kernel module) is in 12.04 LTS
<shnatsel> It's regressed in the past, causing freezes and kernel panics
<shnatsel> I'm about to write a regression test
<shnatsel> The thing is, it has evolved a lot upstream since 3.2
<jsalisbury> Guest16327, not always.  It makes it easier to fix a bug when you do have the hardware, but that's not always the case.  Most times we have to build a test kernel and ask the bug reporter to test.
<shnatsel> Any pointers on where to check the support status of zram in Ubuntu?
<Guest16327> Jsaisbury, I was wondering you would do that, creating a mimic kernel and solve the error. Any pointers on how to build a test kernel? Sorry, I know basic kernel building, but most advanced aspects are in my learning curve. 
<jsalisbury> Guest16327, There is a wiki page linked from here that talks about building kernels: https://wiki.ubuntu.com/Kernel/Dev
<Guest16327> Jsalisbury, Thanks. I will first read all points in the wiki. 
<jsalisbury> Guest16327, This is a good page too: https://help.ubuntu.com/community/Kernel/Compile
<Guest16327> Jsalisbury, Thanks again. Last question, is it recommended to have a stand-alone OS running or can I also use virtual box? Using virtual box helps me to work with different images at the same time right. I usually do that.
<jsalisbury> Guest16327, It all depends on the bug.  If its hw specific a vm may not be the best to test.  However, if its a more general kernel bug or say a filesystem bug, a vm would be good.
<Guest16327> Jsalisbury, Got it! I will leave you undisturbed, while I take some time to get used to the environment. Thanks.
<shnatsel> Guest16327: when using virtualbox, do not install their guest additions. Upstream considers them very buggy, up to memory corruption in random places.
<Guest16327> shnatsel, Thanks. I will not have them installed for my vm's that I use for prototypes. I am a beginner in open source, just trying to use my evolving experience to contribute something. 
 * rtg -> EOD
#ubuntu-kernel 2013-11-19
<yottabit> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/ the patch should already be in the .deb files, right?
<yottabit> this guy will return tomorrow
 * xnox looks up rtg
<apw> xnox, a bit early for rtg
<xnox> thanks.
 * xnox wishes irc-proxy was mandatory =)
<apw> xnox, heh yeah
<Vaithi> Good morning.
<RAOF> apw: It's probably late for you, but have you seen https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1252874 ?
<ubot2> Launchpad bug 1252874 in linux (Ubuntu) "Kernel panic shortly after pairing Apple Magic Touchpad" [Undecided,New]
<apw> RAOF, hrm... maybe i'll have to buy one
<RAOF> A galago, or a magic touchpad?
<RAOF> Either is a good purchase :)
<apw> magic touchpad :) 
<RAOF> Null pointer dereference *should* be reasonably sensible to chase down, I hope?
<apw> yeha it should, though we won't be on 3.12 for very long, so i'd be as interested in as whether it blows on 3.13
<bjf> apw, i think i have one of those
<apw> bjf, ahh, fun
<bjf> maybe
<apw> RAOF, i'll make you a current 3.13 and perhaps you can test that
<antarus> not on 3.12...?
<antarus> whats T going to use?
<bjf> antarus, 3.13
<antarus> nice
<bjf> apw, RAOF, i do, i'll see if i can repro
<apw> bjf thanks
<RAOF> apw: I can certainly test that.
<apw> RAOF, building now
<sforshee> datagram_poll seems like an odd place to crash due to a bluetooth device
 * rtg -> EOD
<bjf> RAOF what did you use as a pin? i am trying 0000 and it's failing to pair
<RAOF> From memory it was 0000
<RAOF> It is paired with anything else?
<RAOF> I find it gets narky if you try and pair it with more than one thing.
<bjf> it's possible ... let me chck
 * RAOF sometimes has to turn off all other bluetooth devices, set the touchpad to pair, and then it works.
<bjf> ok, it's going to take me a bit .. another system was paired with it and wants to stay paired with it
<apw> RAOF, so if you can be bothered, here is a 3.13: http://people.canonical.com/~apw/unstable-trusty/
<RAOF> apw: Know if I will need to turn off secureboot for that?
<apw> RAOF, shoulnd't no
<RAOF> Ta. Downloading now.
#ubuntu-kernel 2013-11-20
<RAOF> apw: Dunno if you're still here, but 3.13 improves things in some ways.
<RAOF> apw: In that pairing the touchpad doesn't cause a kernel panic. However, it doesn't cause a kernel panic because bluetooth fails to work entirely.
<cking> smb, https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey
<apw> RAOF, oh what a gay day
<apw> cking, hey that looks familiar, i can tell i was involved in at least one of those scripts just from the idioms used
<cking> yup
<smb> apw, Yeah I remembered this one yesterday (well looked it up again) while on the discussion about making usb-creator usable
<smb> I think it has some draback when it comes to server images as they use Debian installer and not casper
<apw> smb, may so indeed, probabally assumes it can mount itself to get the .debs or something
<smb> Some parts are in grub2 but probably needed some intelligencce finding the iso as well and casper was better or so
<smb> Really hard to remember now
<apw> yeah
<apw> and that
 * apw whines about tearing under X on saucy
<apw> vertical tearing
<brendand> hi - i've noticed that on my system, the value in scaling_max_frequency is lower than the highest value in scaling_available_frequencies
<brendand> what impact (if any) would that have on system performance?
<infinity> brendand: It would limit your max frequency, obviously.  But this is also a bit odd.  What are the values?
<apw> i would expect the max frequency to define how fast your machine might be allowed to go
<apw> i would hope that info came from the bios and thus it is to blame
<apw> cking, ^^ thoughts ?
 * infinity notes that his has grown a new and bogus top-end...
<infinity> (base)adconrad@cthulhu:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
<infinity> 2801000 2800000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 
<infinity> THANK GOD FOR THAT EXTRA 1MHz.
<brendand> max: 1520400
<cking> infinity, i think that's a placeholder for the turboboost
<brendand> available: 2534000 2533000 1600000 800000
<brendand> am i really restricted to 1.5Ghz?
<cking> brendand, file a bug, I'll collect some data and poke at it
<apw> i see brendand has that same 1mhz bump 
<brendand> kernel bug?
<infinity> cking: Oh, did someone finally add turbo capability to ondemand?
<smb> apw, Think as cking said that this is turbo mode
<cking> it is turbomode, I see that on my range of boxen
<cking> brendand, what does fwts cpufreq tell you?
 * infinity was under the impression you had to use Intel's awful governor to get turboboost, but maybe they felt pity on those of us who like to not run crap code.
<apw> oh yeah i was sure turbo was what i was, i was just idly noting his supported that
<brendand> cking, a lot of warnings
<brendand> Medium failures: 4
<brendand>  cpufreq: Supposedly higher frequency   1.65 GHz is slower (78023 bogo loops) than frequency   1.65 GHz (78059 bogo loops) on CPU 0.
<brendand>  cpufreq: Supposedly higher frequency   2.58 GHz is slower (78002 bogo loops) than frequency   2.58 GHz (78023 bogo loops) on CPU 0.
<brendand>  cpufreq: Supposedly higher frequency   2.58 GHz is slower (77670 bogo loops) than frequency   2.58 GHz (77823 bogo loops) on CPU 1.
<brendand>  cpufreq: Firmware not implementing hardware coordination cleanly. Firmware using SW_ANY instead?.
<brendand> cking, and those failures
<cking> that's helpful, can you file a bug, and report what fwts says, also include the output acpidump too, then I can figure what's going on
<cking> and run that test when the machine is fully idle too
<amitk> cking: brendand: it would be useful to check the machine temperature as well
<brendand> amitk, hot :P
<amitk> (to see if it is a thermal constraint)
<cking> that's the problem then
<smb> or even something fiddling around with max_frequency from userspace
<brendand> cking, max_freq is being lowered because the system is hot?
<cking> brendand, to stop the silicon melting away CPU freq throttling is kicked in
<cking> (passive cooling)
<cking> as well as the fan (active cooling)
<cking> brendand, I'll work in the cpufreq test to explicitly detect this so we can figure this out easily 
<brendand> cking, right now it's only running at 50% and it's still at the same value
<brendand> cking, is there any way to tell for sure it's due to overheating?
<cking> cat /sys/class/thermal/thermal_zone*/temp  perhaps
<cking> dmesg may contain some info about throttling (well it used to, not checked it recently)
<amitk> brendand: and cat trip_point_?_temp in the same directory
<cking> good idea ;-)
<brendand> cking, amitk - i think it shouldn't be : http://paste.ubuntu.com/6447619/
<brendand> cking, amitk - all the temps are lower than any of the trip points
<cking> brendand, what is cat /sys/bus/cpu/devices/cpu*/cpufreq/cpuinfo_max_freq
<brendand> cking, same as in max_freq: 2534000
<brendand> cking, for both cores
<cking> brendand, and /sys/bus/cpu/devices/cpu0/cpufreq/bios_limit?
<brendand> cking, same
<amitk> is this running the intel pstate driver?
<brendand> amitk, how can i check that?
<infinity> brendand: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<brendand> infinity, oh ok - i didn't realise those were the same. no it's just ondemand
<ppisati> robher: didn't we disable cpufreq because of instabilities on ecx-1000? was it fixed? upstream code or firmware fix?
<robher> ppisati: that was cpuidle. cpufreq was colliding with the omap cpufreq driver, but that should be fixed
<ppisati> robher: ah right
<ppisati> robher: actually i don't see any sign of us trying to turn it on and then off 
<ppisati> robher: i see it's on for raring, when highbank had its own kernel
<robher> ppisati: maybe it got turned off in saucy inadvertently.
<robher> perhaps some kconfig changes caused new defaults to get picked up?
<ppisati> robher: actually i saw i commit from March 2013 when it was turned off cause it paniced omap, so when we collapsed all flavours in a single image kernel, that was off
<jtaylor> concerning transparent huge pages, they are enabled but always be default
<jtaylor>  /sys/kernel/mm/transparent_hugepage/enabled is set to madvise
<jtaylor> found bug 743688
<ubot2> Launchpad bug 743688 in linux (Ubuntu) "Transparent HugePages not enabled in 11.04 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/743688
<apw> so if we are going to do anythihng with that it sounds liek another measure and evaluate job
<jtaylor> concerning comment #12 according to lwn they are swappable (via splitting), and the performance regression might be fixed in 3.11, at least I think saw a commit that fixed one recently
<apw> ogasawara, perhaps a WI to measure it, what do you think
<ogasawara> apw: +1, was just writing it down
<ogasawara> I should actually throw it in the whiteboard before I lose this piece of paper
<apw> sounds good to me
<jtaylor> commit 348944504362417205107e63cfe4821aa87ec1bb
<apw> jtaylor, is that something (the default) which can be modified via either sysctl or via the kernle command line do you know
<jtaylor> yes I always do so
<apw> ok, so thats something
<rtg> apw, whats the story on 'scsi: hyper-v storsvc switch up to SPC-3' in Trusty ? Its not even in linux-next.
<rtg> og, only suggested by James
<rtg> oh*
<apw> rtg, yeah they are meant to be fixing that (i think by returning spc-3) in the hypervisor
<apw> but till they do, ...  we need something
<apw> i'll poke the lemming to find out
<rtg> ogasawara, 3.13-rc1: 78 no-up patches, 30 SAUCE patches that should get reviewed for upstreaming.
<ogasawara> rtg: ack
<apw> rtg, ogasawara, i have just pushed a dependancy change for the kernel, this moves us from binutils-dev to libiberty-dev, this is a request from foundations.  this will trigger an MIR for that when we get there, but we're not uploading overly soon i assume
<rtg> apw, on unstable ?
<apw> unstable only indeed
<rtg> apw, maybe you should push again. I may have clobbered it.
<rtg> obsessively rebasing.....
<rtg> sorry
<apw> rtg, done, np
<rtg> apw, thanks
<ppisati> robher: how can i tell if i'm using your cpufreq driver?
<ppisati> ubuntu@c09:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
<ppisati> generic_cpu0
<robher> ppisati: hummm, good question. I think other than looking at the kernel log, you can't.
<ppisati> robher: you don't do any particular output in your driver, plus i've this:
<ppisati> [    1.364119] cpufreq_cpu0: failed to get cpu0 regulator: -19
<bjf> kees, you plan on verifying bug 1183616? (please)
<ubot2> Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged] https://launchpad.net/bugs/1183616
<robher> ppisati: actually, the cpu0 driver doesn't get instantiated unless the highbank driver succeeds. So if you see cpu0 driver being used, it is working. 
 * rtg -> EOD
<kees> bjf: I thought it was not cool for the fix-author to also do the verification? I asked around trying to find someone that could test on real hardware but I'm not sure how far they got.
<infinity> kees: It's perfectly cool for the author to verify, if you actually verify instead of saying "yeah, I submitted it, therefor it's fixed lolz".
<RAOF> Looks like we need to socialise that again.
<bjf> kees, that rule doesn't apply to kernel bugs :-)
#ubuntu-kernel 2013-11-21
<kees> bjf, infinity: okay. well, I'll try to get it booted on real hardware. that might take a while. if either of you have hw already, running the verification steps in the bug is all I'd do to double-check it. :)
<bjf> kees, no rush i just wanted to know someone was going to test it
<kees> bjf: okay, cool.
<bjf> ppisati, how difficult would it be for you to verify bug 1183616 for me?
<ubot2> Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged] https://launchpad.net/bugs/1183616
<bjf> ppisati, there are instructions in the bug description on how to do so
<ppisati> bjf: yeah, i'll fire up a board with precise and test it
<bjf> ppisati, you the man! kees ^
<brendand> cking, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1253734
<ubot2> Launchpad bug 1253734 in linux (Ubuntu) "scaling_max_freq is less than highest frequencies in scaling_available_frequencies" [Undecided,New]
<brendand> cking, for my own system - with all the attachments requested
<cking> brendand, thanks
<marrusl> will linux-image-generic-lts-trusty be released at the same time as trusty itself?
<bjf> marrusl, yes
<rtg> or within a week
<marrusl> thanks bjf.  that gives 3-4 months to migrate from other backport kernels.  I think that will be enough for my customers.  we'll see what they think.
<ppetraki> smb, ping
<smb> ppetraki, hmmm?
<ppetraki> smb, :)
<ppisati> kees: the test case for lp1183616 doesn't compile
<ppisati> kees: http://paste.ubuntu.com/6455233/
<kees> ppisati: weird, builds fine for me. are kernel headers missing maybe?
<ppisati> kees: nope, present
<ppisati> ii  linux-headers-3.2.0-1441               3.2.0-1441.60                           Header files related to Linux kernel version 3.2.0
<ppisati> ii  linux-headers-3.2.0-1441-omap4         3.2.0-1441.60                           Linux kernel headers for version 3.2.0 on TI OMAP4-based systems
<kees> and those are the headers from the -proposed kernel?
<kees> can you search around for the __NR_time definition? It really should be there.
<ppisati> kees: i'll ding around and get back
<kees> ppisati: cool, thanks.
 * rtg -> EOD
#ubuntu-kernel 2013-11-22
 * smb yawns
 * apw yawns more
 * infinity yawns most
 * smb steps back and watches apw and infinity duke out who has the biggest...
<ogra_> kids these days
<diwic> apw, thanks for your review yesterday - just a question, you mentioned I haven't signed off all patches, but all patches have at least one sign-off from me already, since I wrote the patches originally
<diwic> apw, did you expect two sign-off lines from me?
<apw> diwic, the original signed off the origina, for the ones which have conflicts and therefore (additionally) be converted from cherry-picked to backported, those i normally add a new one  for the backprot, so we know who did that backport
<apw> if that makes sense at all
<diwic> apw, ok, I can add a second sign-off where there are conflicts 
<diwic> apw, I hope to send out a second set today that can be applied
<apw> otherwise it looks like i am the one who did it if you see what i mean
<jcz> while decompressing, does the kernel use any additional memory besides the one the kernel is loaded on?
<ppisati> kees: http://paste.ubuntu.com/6458162/
<ppisati> kees: actually there's a reason why it doesn't compile
<ppisati> kees: flag@flag-desktop:~/seccomp/tests$ gcc -dM -E  seccomp_bpf_tests.c  | grep EABI
<ppisati> #define __ARM_EABI__ 1
<ppisati> kees: can yo do the same on the box where you said you compiled that test?
<TooLmaN> To show my age and lack of attention to source building, when did compiling start supporting multi-core processing  (-j4)?
<brendand> TooLmaN, quite a long time
<brendand> TooLmaN, i could look it up but at a guess i'd say 5-6 years
<TooLmaN> brendand:  That shows how long it's been since I compiled anything lol.  I'm back to rolling kernels for ARM devices like RPi and Beaglebone.  
<infinity> brendand: You're off by a decade or two.
<infinity> TooLmaN: make's supported forking via -j for pretty much ever, but most people never used the option when they only had one CPU. :P
<brendand> infinity, that explains why i only encountered it 5 years ago
<TooLmaN> infinity: Interesting.  I guess I haven't delved deep enough into make's powers.  Thanks
<backjlack> Hello!
<backjlack> I've run into some problems with kernel 3.5 & 3.8 on 12.04 and with kernel 3.11 on 13.10. AR9462 is losing the state of the radios across boots, reboots and sleeps.
<backjlack> fresh boot: bluetooth and wlan -> both active, press fn+F3 to cycle through the various states to get to WLAN ON, bluetooth OFF, sleep & wake -> bluetooth is active again
<backjlack> reboot -> everything is active again
<backjlack> This was running as expected on 12.04 with kernel 3.2.
<chilicuil> hello, I'm trying to build an ubuntu kernel package with -ck patches, so far I'm able to do it by taking upstream sources, applying -ck patchset + ubuntu packaging stuff (http://kernel.ubuntu.com/~kernel-ppa/mainline), however I'd like also to include ubuntu sauces, is there any guide where I could see how to apply them or where to download them from?
 * ppisati -> EOW
<jtaylor> out of curiosity, why is swapaccounting not enabled in ubuntu by default? required for swap control in cgroups
<jtaylor> can't find any downsides mentioned in the docs
<jtaylor> CONFIG_CGROUP_MEM_RES_CTLR_SWAP I guess
<jtaylor> nevermind found some downsides on http://cateee.net/lkddb/web-lkddb/CGROUP_MEM_RES_CTLR_SWAP.html
#ubuntu-kernel 2013-11-23
 * rtg -> EOD
#ubuntu-kernel 2013-11-24
<Z1efin> I need help with Nvidia Drivers for Ubuntu 13 is this a good room for this?
#ubuntu-kernel 2014-11-17
<apw> gyuukgku (N,BTFL), ecryptfs-mount-private will mount it if not mounted -- obviously this needs you password
<henrix> dannf: bug #1382244 requires verification.  could you please take a look at that?
<ubot5> bug 1382244 in linux (Ubuntu Utopic) "HP ProLiant m400 nic fails to initialize when booted w/ debug" [Medium,Fix committed] https://launchpad.net/bugs/1382244
<dannf> henrix: cmagina is working on that i think
<henrix> dannf: ack, thanks
<henrix> tinoco: the same question for you: bug #1382333 and bug #1304001 also require verification ;)
<ubot5> bug 1382333 in linux (Ubuntu Trusty) "XFS: memory allocation deadlock in kmem_alloc (mode:0x8250)" [Undecided,Fix committed] https://launchpad.net/bugs/1382333
<ubot5> bug 1304001 in linux (Ubuntu Utopic) " xen:balloon errors in 14.04 beta" [High,Fix committed] https://launchpad.net/bugs/1304001
<jharley> Hey, Iâm running Trusty (linux generic 3.13.0.39.46) and having some timeout issues with an onboard Intel C600 SAS controller which I think thereâs a fix for upstream.. does anyone have a few seconds to walk me through opening a bug for this on launchpad?
<apw> jharley (N,BFTL), run "ubuntu-bug linus
<apw> jharley (N,BFTL), run "ubuntu-bug linux"
<dannf> ogasawara: didnt' see a session about it during vUDS - is there a known target upstream kernel for 15.04?
<ogasawara> dannf: conservatively we're going with 3.19
<dannf> ogasawara: ack
#ubuntu-kernel 2014-11-18
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 2 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues November 25th, 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.
 * ppisati -> jog
#ubuntu-kernel 2014-11-19
<niluje> I have a linux 3.17 (server A) and a linux 3.2.34 (server B) with a MTU of 9000 trying to contact a host with a MTU of 9001 through internet
<niluje> I also have a Python script that tries to send a TCP packet larger than 1500 bytes
<niluje> In both servers, net.ipv4.ip_no_pmtu_disc is set to 0
<niluje> on server B, I receive a ICMP response "need to frag (mtu 1500)"
<niluje> then, the packet is fragmented and resent: everything is fine
<niluje> on server A, I receive the same ICMP response
<niluje> but the kernel reemits the packet, unfragmented
<niluje> (then I receive again an ICMP response, then the packet is reemited again, ...)
<niluje> In the script that sends the TCP packet, I call getsockopt() to get the MTU value
<niluje> on server A, it is 9000 (??), on server B 1500
<niluje> on server A and B, tracepath finds a MTU of 1500 (which is correct)
<niluje> any idea about what the problem might be? about what I can try?
<henrix> cmagina: hi! any chances of having bug #1386261 for the utopic kernel?
<ubot5> bug 1386261 in linux (Ubuntu) "xgene-pcie: Fix max payload size and phantom function configuration" [High,Confirmed] https://launchpad.net/bugs/1386261
<cmagina> henrix: sure, marked it as verified. hadn't been getting a lot of runtime on utopic due to a kernel change that breaks the platform that fix is for
<henrix> cmagina: awesome, thanks
#ubuntu-kernel 2014-11-20
<gloved_hands> sudo apt-get build-dep linux-image-$(uname -r) is not working
<gloved_hands> kernel-wedge cannot be found
<gloved_hands> sudo apt-get build-dep linux-image-$(uname -r) is not working
<gloved_hands> kernel-wedge cannot be found
<gloved_hands> hey
<gloved_hands> obake
<gloved_hands> apw where is obake
<gloved_hands> apw: key up?
<fingertips> apw
<fingertips> apw more secure?
<fingertips> apw: have you been on the www lately?
<apw> gloved_hands (N,BFTL), well kernel-wedge _is_ a package so that makes no sense, i would expect you to be using sudo apt-get build-dep linux, though.
<apw> fingertips, i have literally no idea what that refers to
<fingertips1> apw: the original 4
<fingertips1> darpa
<fingertips1> This is sme amazon cloud
<fingertips1> It doesn't even connect to darpa
<fingertips1> the internet was started with 4 machines
<fingertips1> this is some virtual cloud routing system 
<fingertips1> apw: why doesn't lucid have a kernel-wedge?
<apw>  kernel-wedge | 2.29ubuntu3 | lucid            | source
<apw> it does ...
<fingertips1> apw: build-dep complains when using apt-get but not aptitude
<apw> perhaps it is a bug in teh apt resolver in that release, dunno, seems supprising as that is how
<apw> the deps get installed on a builder when we build the kernel in the archive ...
<fingertips1> apw using this routine wiki.ubuntu.com/Kernel/BuildYourOwnKernel?
<apw> the builders follow a subset of that, that in concept, unpack a chroot for the series, unpack <.dsc>, apt-get build-dep <srcpackge>, dpkg-buildpackage -b, upload results
<fingertips1> apw: it doesn't even download the same source package as uname -r reports
<fingertips1> What is the lucid amd64 version string?
<fingertips1> apw: When you say 'we' what is that supposed to mean?
<fingertips1> apw: Try to communicate.
<fingertips1> apw: A bit faster.
<fingertips1> apw: we need to get secured with myself
<fingertips1> apw: key up?
<apw> we == "the ubuntu distro" in that sentence
<fingertips1> apw: apt-get source linux-image-$(uname -r) this is downloading some other version
<apw> some other version?  which version and what is uname -r saying
<fingertips1> Yes a version different from what uname -r shows.
<apw> and which are they, else i have no way to try and reproduce that
<apw> no way to understnad the problem
<fingertips1> 2.6.32
<fingertips1> and the string goes on after that wih a -
<apw> uname -r won't be saying that
<fingertips1> 2.6.32-
<apw> right .. i need the whole of it
<apw> else i can't reproduce your exacty command
<fingertips1> 2.6.32-xx
<fingertips1> the -xx part differs
<apw> well i want the one you say is producing a download of the wrong version
<fingertips1> apw: it looks like it is compiled against the debian sources with some scripts to make changes
<fingertips1> apw: It doesn't matter what the exacty version strings are they differ.
<apw> fingertips1, ok tested with my local version 3.13.0-39-generic which downloaded linux 3.13.0-39.66, which is correct, so it is specifi to you
<fingertips1> and what commands build it?
<fingertips1> did build deps run?
<apw> i am referring to apt-get source linux-image-$(uname -r) 
<apw> if you want someone to figure out your isue with it, you need to tell me the actual version your uname -r returns, if ou won't do that, i can't help
<fingertips1> apw: will you install it?
<apw> fingertips1, there is almost no way i could know what the "it" in that sentence refers, so ... i have no idea
<fingertips1> apw: connect to my jabber server
<fingertips1> apw: this is downstream
<fingertips1> apw: there is something changing the code
<fingertips1> do you want to come oon this side of the wall?
<apw> this is a simple question with a simple non-secret answer, there is no point in being coi about it
<apw> i am perfectly happy out here in public thanks, that is the nature of open source
<fingertips1> To help identify what is going on.
<fingertips1> brb apw
<liveuser> making progress
<liveuser> apw does ubunu support skype?
<liveuser> CAN THE MIND GO INTO an intel cpu?
<liveuser> apw: Why would anybody wan't Ubuntu on a chromebook?
<amitk> liveuser: to use it for development?
<liveuser> netsplit google?
<liveuser> the crypto keys installed oon chromeboks
<liveuser> Why does lspci persist in reporting the wrong model for the wireless chip? This happened after loading a non working kernel module driver. Before loading it no model number was reported.Now, after unloading it the wrong model persists to bve reported.Is this a sign that wrong firmware was sent to the chip?
<apw> it is a sign that the kernel module you loaded thought it identified the device and recorded that in the kernel
<apw> likely it will remain the same until something else identifies it differently
<ogra_> or reboot ... 
<VadimT> Hi. I have some problem with kernel. Error: Read-error on swap-device. What it can be? P.S: Ubuntu 14.04.1 LTS. Kernel: 3.13.0-24-generic
<VadimT> Thank you.
<apw> VadimT, could be a lot of things including a bad disk under the swap partition, it would depend somewhat on the errors just before
<VadimT> apw, Thank you for answer. 
<fingertips> apw: wrong eeprom
<apw> VadimT, np, you might want to pastebin the error, and we might be able to help, never know
<VadimT> apw, I have only a photo with this error... http://1drv.ms/1ytucTU
<VadimT> apw, I can find this error in /var/log/syslog and in other same places too.
<VadimT> *can`t
<smb> VadimT, from the picture your kernel crashed. It is relatively normal that in those cases there is no time to write to any logs. What it says is that your second hard drive seems to have gone away from the kernels point of view. One could not say why for sure from that information.
<apw> VadimT, well that error says that the drive returned a failure with additional sense information, but that that information was nothing valid according to the spec.  therefore the IO was failed and that happened to be a page from init, so the world ended
<VadimT> apw, Hmm... Some tips?
<apw> VadimT, that really says the disk behind your swap space had a hickup, if it was mine
<apw> VadimT, i would test the swap space and see if it recurrs, if not, i'd write it off as sunspots or similar
<fingertips> apw wrong eeprom
<apw> that is a matter of oppinion
<VadimT> apw, thx for answer.
<fingertips> Oh it doesn't work apw
<fingertips> There is no wlan0 interface created.
<VadimT> apw, Okay. I`ll try you advice. Good day you. One more time thank you. Bye 
<didrocks> hey
<fingertips> apw I need skynet back up
<fingertips> apw I can run netsplits on a compute cloud
<apw> didrocks, hi?
<didrocks> apw: some question, we are striking on bug #1387090 with some systemd case. After asking on system-devel, there are multiple proposals that Lennart is suggesting at http://lists.freedesktop.org/archives/systemd-devel/2014-November/025370.html
<ubot5> bug 1387090 in systemd (Ubuntu) "boot breaks if /etc/machine-id is missing" [Medium,In progress] https://launchpad.net/bugs/1387090
<fingertips> apw: make the eeprom
<didrocks> apw: on his proposal a), which is having the / writable from the initrd, is there practical reason to not do that?
<didrocks> I can think of fsck happening quite early, before plymouth as a drawback
<didrocks> anything else I'm missing?
<apw> didrocks, well fsck can't happen before plymouth as we use its output channels
<didrocks> yeah, so, it would silence it and we will have no feedback on fsck status
<didrocks> apw: this would be the only reason? (I'm trying to have some reasonable answer on why preferring e) to a) on the ML)
<apw> didrocks, on a call, i'll read it in bit
<didrocks> apw: no hurry, thanks :)
<didrocks> pitti is suggesting we do a) (mounting / as rw in initrd, and so fsck) only if /etc/machine-id is empty
<ogra_> didrocks, what if there are errors fsck wants input for ? 
<didrocks> ogra_: exactly my point and why I'm arguing against it :)
<didrocks> that and having 2 code paths/behavior/user feedback channels
<didrocks> (on the condition /etc/machine-id being empty, like after a factory reset)
<didrocks> but I want to ensure that my arguments are rights, hence the questions here :)
<ogra_> drop the old code path and pull machine-id into the initrd 
<ogra_> note that on the phone i plan to pull Mir into the initrd at some point, for exactly this reason
<didrocks> ogra_: machine-id is per machine identification
<didrocks> not something static
<didrocks> it's like the dbus id if you prefer, which is stable for a machine once initialized
<ogra_> yes, pull it fromm the rootfs ... at this point you already know where it lives ... mount it ro ... cp it over and then run your fsck
<ogra_> i assume with systemd mountall will be dead in debian ... and i doubt we want to carry it along either ... 
<didrocks> ogra_: hum, however, there are tricks, if /etc/machine-id is empty, but you have the dbus-id in /var/lib/dbus/machine-id, this one is reused
<ogra_> so the old code path is a dead end 
<didrocks> yeah, I'm not looking at the old code path for now
<apw> didrocks, ok what i am not clear on is how we get into this situation of not having a system-id, is this in a virgin image booting for the first time ?
<didrocks> apw: yeah, the foundation team is trying to have some clean instance that you can use and spawn
<apw> didrocks, so what stops us say, having it empty n th
<apw> didrocks, so what stops us say, having it empty in the virgin image, let systemd do its thing, putting a tmpfs on it and making one up
<apw> and then postprocessing that at ro->rw time to copy it down into the image
<didrocks> apw: that's proposal e) and I'm in favor of that one
<ogra_> ++
<apw> into the persistant part
<didrocks> apw: just wanted to ensure we couldn't do sanely a) first
<apw> didrocks, i'd say you are asking a lot to do that, making those images rather different
<didrocks> apw: agreed, I'm happy thus to do e), it's an interesting exercise to make it race-free anyway :)
<apw> i think e) is interesting in your namespace world, unmount the overmount in there and create a file underneath :)
<didrocks> right ;)
<didrocks> thanks for your feedback btw! :)
<jodh> apw: I'm seeing an entry in the mount table that cannot be unmounted (mount claims: "not mounted"). It could be related to the fact we're bind mounting on top of a sym link. Ever seen this?
<apw> jodh (N,BFTL), not seen that no, if you have a reproduce by, perhaps i can try and figure it out
#ubuntu-kernel 2014-11-21
<fingertips> Why does lspci persist in reporting the wrong model for the wireless chip? This happened after loading a non working kernel module driver. Before loading it no model number was reported.Now, after unloading it the wrong model persists to be reported.Is this a sign that wrong firmware was sent to the chip?
<fingertips> apw I have the source on the machine now
<fingertips> apw deb-pkg error 2
<didrocks> apw: hey, following our discussion yesterday, I tried to unshare C function for having private mount points (actually umount in this case). But it was always umouting in the parent namespace as well. I then tried this with the unshare bin: http://paste.ubuntu.com/9152105/
<didrocks> I tried mounting as well with --make-rprivate, which isn't needed from the documentation in a child mount namespace
<didrocks> I guess there is clearly something I didn't understand :)
<didrocks> apw: ah, I guess I got it, / in my namespace is by default shared, so I need to mount --make-rslave / (to have parent changes reflected) beforehand
<apw> didrocks, sounds good
#ubuntu-kernel 2014-11-23
<erle-> are the mainline kernels patched or pure vanilla?
<erle-> is there any way to install them automatically with some sort of verification (like with apt repos)
<erle-> I mean these:
<erle-> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-rc5-vivid/
<erle-> (I am debugging some Macbook hardware compability issues)
<apw> erle- (N,BFTL), they essentially unpatched, a very small number have build fixes applied, and they have ubuntu configs dropped on them, otherwise untouched
#ubuntu-kernel 2015-11-16
<apb1963> QNativeImage: Unable to attach to shared memory segment. 
<ohsix> nice try
<apb1963> I get this error using Okular.  It shows a problem with the screen... essentially you can't see portions of the page.  However, the problem is not limited to Okular...
<apb1963> Not sure where to from here, but I figured you guys would be a good starting point.
<apb1963> ^go
<apb1963> There are numerous errors produced by X after that error, but I get the feeling the X errs are a side effect of not having the mem segment.
<apb1963> Well, the cause being the missing segment rather than a side effect... but you know what I mean.
<apb1963> Errors like this:
<apb1963> X Error: BadPixmap (invalid Pixmap parameter) 4
<apb1963>   Major opcode: 56 (X_ChangeGC)
<apb1963>   Resource id:  0x0
<apb1963> At this point, even right clicking and trying to copy or paste is a chore, because the menu is obscured or blank, however you want to picture it.
<apb1963> Oh and... the rightclicking problem is system wide... not limited to any program.  Once it starts, I have to reboot to fix it.  I've rebooted twice now and it's starting to become a little more frequent, and is starting to become a major issue.
<apb1963> If anyone wants to use something like teamviewer or whatever to see it in action, I'm open to that.
<apb1963> 3.13.0-68-generic #111-Ubuntu SMP Fri Nov 6 18:17:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<apb1963> Ubuntu 14.04.3 LTS
<ohsix> you're using kde though? what is using the most memory in xrestop
<apb1963> bash: xrestop: command not found
<apb1963> ohsix: ^^
<apb1963> E: Unable to locate package xrestop
<apb1963> ohsix: kwin followed by libreoffice/writer and then firefox
<apb1963> ohsix: #kde-devel helped me track it down.  java memory leak.   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799587  Thanks for pointing me in the right direction :)
<ubot5> Debian bug 799587 in openjdk-7-jre "openjdk-7-jre: Shared memory issue causes other apps to appear broken" [Important,Fixed]
<apb1963> Any idea when it will make it into ubuntu 14.04 ?
<apb1963> or will it be 14.05 at that point? :)
<apb1963>  https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1512760
<ubot5> Ubuntu bug 1512760 in openjdk-7 (Ubuntu) "Java applications leaks shmem chunks" [Undecided,In progress]
<ohsix> i like the comments on the bug, kde/plasma isn't very usable without bugs ;D
<apb1963> haha
<apb1963> ohsix: by the way... PovAddict in #kde-devel was the person that tracked it down.... and then found the bug had already been reported.  Just in case you want to talk to him about it.
<marga> infinity, 3.13.0-68 was released to trusty-updates on Nov 10th, but the installer has had no updates since Nov. 4th.  I'm getting an install failure because of this (mismatch between running kernel and installed kernel, when doing update-initramfs after dkms installation). Is there a bug about this?
<apw> marga, not sure there is a bug about it, no.  i think he will be aware now tho
<marga> now that I mentioned it? Or already before that?
<apw> well it got mentioned on #u-d as well, so i suspect he'll get the message, and indeed i'll be chatting to him about it too as i got highlighted about it on #u-d
<marga> ah, ok.
<marga> What's the normal process for updating the installer when a new kernel comes around?
<apw> in part i am unsure, which is why i am going to be talking about it
<cmagina> The stable release pull for the current trusty proposed kernel carries a patch that breaks arm64. The issue was seen on wily as well and was worked around by disabling the new config option added by the patch. I added a comment to the stable release bug, bug #1514853
<ubot5`> bug 1514853 in linux (Ubuntu Trusty) "Trusty update to 3.13.11-ckt29 stable release" [Undecided,Fix committed] https://launchpad.net/bugs/1514853
<tseliot> apw: I can't reproduce the failure with bcmwl
<tseliot> apw: and linux 4.3
<apw> tseliot, hrm
<apw> tseliot, i386 right ?
<apw> tseliot, http://paste.ubuntu.com/13299698/ is what ADT gets
<tseliot> apw: that should help. Thanks
<dsmythies> Just passing along something: I observe that http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc1-wily/ is having the same problem as I was. Kernel 4.4-rc1 would not compile until I applied this patch: https://lkml.org/lkml/2015/11/6/987 
<apw> dsmythies, yep, those are raw builds done from the tip of the tree, if the tree is broken they don't build
<henrix> cmagina: hi! re. bug #1502946 (CONFIG_ARM64_ERRATUM_843419), have you actually tried to boot that trusty kernel and reproduced that bug?
<ubot5`> bug 1502946 in linux (Ubuntu Wily) "kernel crash on m400 arm64 server cartridge" [Critical,Fix released] https://launchpad.net/bugs/1502946
<henrix> cmagina: because wily actually contains CONFIG_ARM64_ERRATUM_843419=y (the same as trusty)
<cmagina> henrix: yes, i have a log, just need to attach it
<henrix> cmagina: no need, i just wanted to understand exactly what i should do because trusty seems to have the same config 
<cmagina> henrix: really? hmm...this is the bug where it was supposedly set to 'n' https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1502946
<ubot5`> Ubuntu bug 1502946 in linux (Ubuntu Wily) "kernel crash on m400 arm64 server cartridge" [Critical,Fix released]
<cmagina> [Config] CONFIG_ARM64_ERRATUM_843419=n
<cmagina> 4.2.0-16.19) wily
<henrix> cmagina: right, but the wily kernel in -proposed seems to be closing that bug by reverting that patch
<cmagina> henrix: maybe dannf's upstream fix was accepted and pulled into wily after 16.19
<henrix> cmagina: ah, wily also contains this: b6dd8e0719c0 ("arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419"
<cmagina> henrix: yeah, that's dannf's fix
<henrix> cmagina: ok, cool.  so... i guess we need that in trusty as well
<cmagina> henrix: yeah, that would be perfect
<henrix> cmagina: and in lts-utopic too.  (we're building arm64 in utopic, right?)
<cmagina> henrix: yes
<henrix> cmagina: ok, thanks
<cmagina> henrix: i hadn't gotten to check the other releases yet. are we still supporting utopic? thought it ended and we're now on vivid
<henrix> cmagina: right, utopic has EOL'ed, but we're still doing lts-utopic for a couple more cycles
<cmagina> henrix: ah, ok
<henrix> cmagina: grr... looks like we have the same thing on vivid.
<cmagina> henrix: so, everything up to wily then. arm64 seems prone to these kinds of regressions where a stable release patch breaks it, but there is already a fix, just not in that stable release
<henrix> cmagina: correct.  i'll start working on that.  thanks for reporting. 
<henrix> cmagina: btw, do you have another bug i could you for SRU'ing this?
<henrix> s/you/use
<cmagina> henrix: np, thanks for fixing. yes, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516682
<ubot5`> Ubuntu bug 1516682 in linux (Ubuntu) "a trusty stable release patch breaks module loading on arm64" [Undecided,Incomplete]
<henrix> cmagina: awesome, thanks!
<cmagina> henrix: welcome :)
#ubuntu-kernel 2015-11-17
<lesshaste> hi.. is there any way to enable an OOM killer on ubuntu?
<lesshaste> It is very annoying to have to turn the PC off at the wall
<hyperair> it's enabled by default afaik
<lesshaste> hyperair, it really doesn't seem to be in practice
<hyperair> you probably have too much swap
<hyperair> it hangs, right?
<lesshaste> hyperair, ah.. 
<hyperair> basically it needs time to fill up the swap, and thrash about for a bit
<lesshaste> it is thrashing exactly
<hyperair> only when it can't allocate more memory does it trigger OOM
<hyperair> as long as there's more swap, it can allocate more memory
<hyperair> and thrash some more
<lesshaste> oh.. I want it to kill the process when it is thrashing which I see is a different problem
<hyperair> yeah that's a different problem
<lesshaste> because the thrashing is unkillable in effect
<hyperair> i think you can play with overcommit ratio or something
<hyperair> well
<lesshaste> as I can't even get to a terminal to type "kill"
<hyperair> depending on the size of your swap, you can actually just wait it out
<hyperair> i've let a thrashing machine sit for 30 minutes, and it fixed itself
<lesshaste> hyperair,  I think that's potentially forever
<hyperair> most of the time i don't have the patience and cut the power though
<hyperair> or start hammering the sysrq keys
<hyperair> ah
<lesshaste> hyperair, if I have a process which takes 1 hour normally and starts thrashing
<hyperair> AH
<hyperair> yes
<lesshaste> I could be waiting for years
<hyperair> there's a sysrq key that triggers the OOM killer
<lesshaste> oh!
<hyperair> https://en.wikipedia.org/wiki/Magic_SysRq_key
<hyperair> alt+sysrq+f
<hyperair> you need to enable it though
<lesshaste> interesting
<hyperair> see /etc/sysctl.d/10-magic-sysrq.conf
<lesshaste> how do you get sysrq? It is in small letters on the prt sc key
<hyperair> yeah
<lesshaste> oh I need to enable it
<hyperair> start by trying to get hitting alt+sysrq+h. i think that dumps a help message into dmesg
<lesshaste> it tried to take a screenshot :)
<lesshaste> let me try  alt+shift
<hyperair> lol
<hyperair> i actually use the prtsc key
<hyperair> alt+prtsc+whatever
<hyperair> i disabled the screenshot taking though
<lesshaste> it just tries to take a screenshot
<hyperair> you may or may not need the fn key on a laptop
<lesshaste> it's a desktop
<hyperair> right
<lesshaste> [  823.370296] SysRq : This sysrq operation is disabled.
<hyperair> hah
<lesshaste> so that's something :)
<hyperair> that's something, yes
<hyperair> see the file i mentioned
<hyperair> it's disabled by default because an attacker trying his/her luck might get lucky and kill the screensaver process without killing X
<lesshaste> it says kernel.sysrq = 176
<lesshaste> which should be allow reboot/poweroff, enable remount read-only, enable sync command
<lesshaste> how do you enable it if not in that file?
<hyperair> sysctl kernel.sysrq=whatever
<hyperair> as root
<lesshaste> hyperair, so what role that does file play?
<lesshaste> does that
<hyperair> default sysctl setting
<lesshaste> I mean /etc/sysctl.d/10-magic-sysrq.conf
<hyperair> for making it persistent across reboots
<lesshaste> what I mean is.. why isn't it enabled given that it is currentluy 176
<hyperair> sysctl changes kernel parameters. that usually lasts until you reboot
<hyperair> oh
<hyperair> well
<hyperair> i dunno
<hyperair> what does "sysctl kernel.sysrq" say?
<lesshaste> I should say I have an unmodified ubuntu install 
<lesshaste> sysctl kernel.sysrq
<lesshaste> kernel.sysrq = 176
<hyperair> i think it just allows a certain number of functions
<lesshaste> oh i see
<hyperair> here's mine: [3277566.690317] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffe
<hyperair> r(z)
<lesshaste> what do you get from sysctl kernel.sysrq ?
<hyperair> 1
<lesshaste> ok done
<lesshaste> I really need a way to do alt-sys rq+h without it taking a screenshot!
<lesshaste> aha!
<lesshaste> alg gr+prt sc+h does it
<lesshaste> alt gr I mean
<lesshaste> [ 1540.531549] SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffer(z) 
<lesshaste> success
<lesshaste> so what one would kill the task that is thrashing?
<lesshaste> which one
<lesshaste> hyperair, thanks for you help
<Eduard_Munteanu> Are the kernel Git repos hosted over https somewhere?
<apw> Eduard_Munteanu, checking
<apw> Eduard_Munteanu, yes, https:// is one of the options: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
<Eduard_Munteanu> apw, thanks
<Eduard_Munteanu> Any reason kernel.ubuntu.org doesn't support it, btw?
 * Eduard_Munteanu should file a bug perhaps
<apw> Eduard_Munteanu, likely because the machine was old and slow
<apw> Eduard_Munteanu, the launchpad repos are going to become the official ones before long in all likelyhood
<Eduard_Munteanu> Ah, nice.
<apw> as that infrastructure is much more load tollerant
<apw> Eduard_Munteanu, for xily and xenial LP is alreday master, and all others are sync'd up to LP every 15m or so
<Eduard_Munteanu> Cool.
#ubuntu-kernel 2015-11-18
<apw> stgraber, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1517426 ... seems lxc is failing its autotests for what looks like a bad dep
<ubot5> Ubuntu bug 1517426 in lxc (Ubuntu) "[trusty] lxc: lxc now depends on lxcfs which is only in backports" [Undecided,New]
<caribou> can someone ping my nick again, please ?
<apw> caribou, ?
<caribou> apw: thanks!
<gpiccoli> Hello, I don't know if this is the right place for asking help on this, but I'm having trouble in saving logs of kernel crashes on Ubuntu 14.04.3. Sorry to bother with this
<gpiccoli> I have the linux-crashdump and the following parameter on my cmdline: "crashkernel=384M-2G:64M,2G-:128M"
<gpiccoli> Even so, nothing shows up on /var/crash after a crash (I'm using sysrq for testing)
<gpiccoli> Any clue?
<apw> gpiccoli, is crash dumping enabled, i don't think it is by default when the package is installed
<apw> caribou, ^
<gpiccoli> apw, I followed some procedures of wiki page - I notice the following line on my dmesg: "Reserving 128MB of memory at 128MB for crashkernel (System RAM: 4096MB)"
<caribou> apw: yes, it needs to be enabled in /etc/default/kdump-tools :
<caribou> gpiccoli: ^
<gpiccoli> wow, nice! thanks caribou and apw !
<caribou> gpiccoli: USE_KDUMP=1 and then sudo kdump-config load (assuming that you have rebooted & crashkernel= is present)
<apw> gpiccoli, do fix the wiki if it isn't correctly indicated in there
<gpiccoli> Should I document this on wiki? OR is it already there, and I missed?
<apw> gpiccoli, that you missed it implies it is not well enough presented even if it is there
<caribou> gpiccoli: let me check. Which wiki are you looking at ?
<gpiccoli> this one caribou: https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html
<gpiccoli> apw, good point hehehe
<caribou> gpiccoli: apw: it is under "Configuratino"
<caribou> well "Configuration"
<gpiccoli> wow, sorry caribou and apw
<caribou> but I keep being asked to have it enabled by default
<gpiccoli> My bad =//
<caribou> gpiccoli: no worry
<gpiccoli> caribou, what is the con in having this enabled by default?
<apw> yeah np, documentation is lik that
<caribou> apw: we talked about it in Austin, remember
<caribou> gpiccoli: nothing really, it is mostly historical
<apw> caribou, indeed, it does seem odd to install something which has no other purpose and not enable it by default
<caribou> apw: agree
<apw> if it needs configuration before enabling it makes sense, yes fine
<gpiccoli> Is there a way to enable this flag automatically on linux-crashdump install ?
<gpiccoli> Would be nifty
<apw> gpiccoli, could be done, but it is i a change, and so needs discussing publically first
<apw> in case there is a compelling reason not to that we are not htought of
<caribou> apw: I just had a chat with bwh in #debian-kernel and he's fine with having the small initrd fix in Debian as well
<gpiccoli> sure apw, I agree! I think it makes sense...for airheads like me heh
<apw> caribou, nice, i thnk i  saw you chatting
<caribou> apw: so I'm thinking of pairing this change with defaulting to Yes
<apw> gpiccoli, for the casual user you want it to work as best it can without config, even if power users will want to change things
<caribou> apw: with the option of setting it to False if needed
<gpiccoli> Great caribou and apw!!! 
<apw> caribou, might be woth sending out some kind of rfc on that if you havent, to ubuntu-devel or something
<caribou> then I'll push both changes to Debian/Sid so it syncs to Xenial
<apw> something more focused if there is one
<caribou> apw: ubuntu-devel & ubuntu-kernel maybe ?
<apw> works for me
<caribou> k
<apw> i can't see you getting any responses at all :)
<caribou> apw: that's what happened with my post to debian-kernel :-)
<apw> caribou, :)
<caribou> apw: the kernel ML is kernel-team@lists.launchpad.net, right ?
<apw> caribou, ack
<apw> caribou, approved your post
<gpiccoli> apw, caribou: I'm still with no luck
<caribou> gpiccoli: let me run a  quick test
<gpiccoli> Even with those modifications, only a file named kexec_cmd is created
<gpiccoli> I'm on PPC64 kvm _guest_
<caribou> oh, ppc64
<gpiccoli> What I need is only the log, I don't even need the vmcore
<caribou> gpiccoli: any chance I can access it remotely ?
<gpiccoli> Unfortunately no caribou, I'm very sorry
<gpiccoli> It's private network only
<caribou> gpiccoli: np
<gpiccoli> I can perform any test you want although
<gpiccoli> Note: I already could generate those dumps in the past days
<gpiccoli> Reinstalled the system and now, it does not work
<apw> gpiccoli, big or little endian (powerpc or ppc64el debian arch)
<gpiccoli> ppc64el
<gpiccoli> apw ^
<caribou> gpiccoli: would you be able to capture the console output during one of your test ?
<gpiccoli> ok, 
<gpiccoli> what dfo you need to see?
<gpiccoli> *do
<caribou> gpiccoli: well, the portion between the kernel panic & the reboot
<gpiccoli> ok, I can put here, but we have not too much output there
<apw> gpiccoli, i would pastebinit, rather than putting it in ir
<apw> irc
<gpiccoli> good idea apw! I'll paste some more info too =)
<gpiccoli> apw, caribou: http://pastebin.ca/3259739
<gpiccoli> Do you need after QEMU boot logs?
<gpiccoli> I sttoped on QEMU first line, can past the rest here if you want
<gpiccoli> I should check my loglevel too...
<caribou> gpiccoli: well, there's nothing after the sysrq-trigger, you should have the panic backtrace, etc
<gpiccoli> There you go!
<gpiccoli> What do you think that can be happening?
<gpiccoli> It's like if crashes are not being even dumpeed
<gpiccoli> *dumped
<caribou> gpiccoli: ? same pastebin ?
<apw> caribou, well you see it starting to do osmething, as it emits what looks like half of the first line of a kernel boot ?
<gpiccoli> caribou, I'm sorry - I didn't understand your question marks hehe
<caribou> apw: it should start by displaying the panic() msg
<apw> caribou, he is saying that is all he gets, "there you go you are seeing what i see" not "there you go some more information"
<caribou> gpiccoli: I thought you had pasted more information somewhere else
<apw> english, sooooo unambigious
<gpiccoli> yes apw, thanks!!!
<gpiccoli> your got right my expression. Sorry caribou
<caribou> gpiccoli: can you paste the result of "sudo kdump-config show" pls ?
<gpiccoli> I'm not so good in english, so it can be entirely my bad - sorry
<gpiccoli> sure!
<caribou> gpiccoli: no worry:)
<apw> the SLOF line is the indicator that we are booting a new right, after the crash would have been completed if it had occured
<gpiccoli> caribou, apw: http://pastebin.ca/3259751
<caribou> gpiccoli: what's the result of cat /sys/kernel/fadump_enabled ?
<caribou> long shot
<gpiccoli> caribou:
<gpiccoli> root@ubuntu:~# cat /sys/kernel/fadump_enabled
<gpiccoli> cat: /sys/kernel/fadump_enabled: No such file or directory
<gpiccoli> =0
<caribou> gpiccoli: ok, just wanted to check, this is a PPC specific dump mode
<gpiccoli> ok, great!
<gpiccoli> BTW, thanks verym uch for your help
<apw> slangasek, i think it was you who asked why our testing depended on exim4.  I think i have just found out (well cking did), it seems the aslr test in QRT uses starting/stopping exim as part of its payload
<cking> namely because of bug https://bugs.launchpad.net/bugs/504164
<ubot5> Ubuntu bug 504164 in linux (Ubuntu Jaunty) "Random segfaults on amd64 (Hardy through Jaunty)" [Medium,Fix released]
<caribou> gpiccoli: I'm going to fetch a PPC64 iso & try to test it locally. May take a little while 
<gpiccoli> Thanks very very much caribou, I'm really appreciate your help =)
<gpiccoli> I'll turn my guest off [some more people need the machine]
<caribou> gpiccoli: well, I maintain that code so I would highly prefer to see it work ;-)
<gpiccoli> hehehe =)
<gpiccoli> Great to hear! 
<gpiccoli> Your are a very nice maintainer, it's good to see such interest and effort
<gpiccoli> Not all maintainers are as you, we all know heh
<caribou> gpiccoli: Is using PPC64 as the VM architecture correct ?
<gpiccoli> Hmmm..I don't know
<gpiccoli> What are the possibilities?
<gpiccoli> caribou ^
<gpiccoli> I can check my VM here
<caribou> gpiccoli: If I select ppc64le, it asks me for an existing image
<gpiccoli> in libvirt sml we have:     <type arch='ppc64' machine='pseries-2.4'>hvm</type>
<gpiccoli> *xml
<caribou> gpiccoli: I'm getting near end of day. Can you email me the .xml description of your VM ?
<slangasek> apw: ah, heh.  exim still seems a strange choice of mta then :)
<apw> slangasek, its not as an mta, it is because that specific binary was a reproducer
<slangasek> ahhh ok
<gpiccoli> Sure caribou, thanks!!
<gpiccoli> PM me your email
<jderose> When is 4.2.0-19.23 expected to land in Wily updates?
<apw> jderose, iirc we are about 2 weeks out
<apw> jderose, assuming not kitten killers it is slated to release by the 28th
<jderose> apw: much thanks! i wasn't sure whether I was reading the kernel newsletter correctly or not :)
<apw> jderose, yep, the dates are intentionally vague to let things move around for emergencies and regressions
<cristian_c> jsalisbury: hello
#ubuntu-kernel 2015-11-19
<cristian__c> jsalisbury: hi
<jsalisbury> cristian__c, hello
<cristian__c> jsalisbury: I've talked with a guy in #linux-wireless
<cristian__c> jsalisbury: he gave me a suggestion
<jsalisbury> cristian__c, great.  
<jsalisbury> cristian__c, did you happen to add the info to the bug, I haven't reviewed it in a bit
<cristian__c> ' with the patch being 2 years old, apparently without any fundamental complaints, it might make more sense to specifically blacklist your particular system based on its DMI strings from within hp_wmi_bios_2009_later(), rather than doing a blanket revert (which might break/ regress other systems) - pretty much a two-line patch'
<cristian__c> ' apparently, yes - but it was also needed to unbreak other systems, therefore it's probably better to fix it (add a quirk for your notebook mainboard), rather than just reverting it (and thereby breaking other systems that had been working for 2 years by now)'
<cristian__c> jsalisbury: I've told him i would have talked with you
<cristian__c> either author/ original committer
<cristian__c> (in this case hung either garrett)
<jsalisbury> cristian__c, ok, all you system dmi info is in the bug, so I'll build a test kernel with a quirk for your board and see if it fixes things
<cristian__c> jsalisbury: do you think his proposal (blacklistig my system by dmi from wmi bios function) rather than simply reverting the commit?
<jsalisbury> cristian__c, reverting the commit could cause other regressions, so blacklisting may be best
<cristian__c> jsalisbury: yeah, thanks. He says the idea is something so: blacklist only my system in the code, so there is no risk to hurting other systems
<cristian__c> *to hurt
<cristian__c> jsalisbury: ok, thank yoj very much
<cristian__c> *you
<cristian__c> :)
<jsalisbury> cristian__c, I'll try that and post a test kernel in the bug shortly
<cristian__c> yeah, ok. then I'll look launchpad page in the next days
<cristian__c> thanks again
<jsalisbury> np
<jsalisbury> cristian_c, after digging a bit while creating a patch, I think a patch was actually recently sent upstream to fix this(Commit 8a1513b).  I'll build a test kernel with it, and see if that makes it so we don't need to blacklist your board.
<cristian_c> jsalisbury: ah, ok
<jsalisbury> cristian_c, I'll post a link to a test kernel in the bug shortly
<cristian_c> yeah, I'll check
<cristian_c> and I'll try that
<cristian_c> jsalisbury: I suppose, I've to report results in the launchpad bug webpage
<jsalisbury> cristian_c, that would be great, thanks
<cristian_c> ok
<jsalisbury> cristian_c, are you still running Vivid?  The commit I just mentioned is already in Wily, but not in Vivid or older releases yet.
<cristian_c> jsalisbury: I've to try wily
<jsalisbury> cristian_c, no, you don't need to upgrade.  If you are still on a release older than while, I can just post a link to the wily test kernel to try out.
<cristian_c> jsalisbury: could I use 4.2 test kernel in older releases, either have I to use it in wily release?
<cristian_c> jsalisbury: ok
<cristian_c> my release is older than wily
<jsalisbury> cristian_c, The fix went in to the upstream 4.3-rc2 kernel, but was also cc'd to stable.  It was already applied the Wily kernel, but not Vivid or Trusty yet.  I'll just post a link to a kernel you can test in the bug.  That will make it easier then you having to upgrade right now.
<cristian_c> jsalisbury: ok
<cristian_c> uhm... from triaged to 'in progress'...
<jsalisbury> cristian_c, ok, I just posted a link to the kernel to test.  You just need to install the linux-image and linux-image-extra .deb packages then reboot.
<cristian_c> jsalisbury: ok, so no -headers and -headers-generic...
<jsalisbury> cristian_c, no, you should need them for this quick test
<cristian_c> ok
<cristian_c> jsalisbury: ok, I've catched threebdeb packages
<cristian_c> linux-headers-...-generic...i386, linux-image-...-generic....i386 and linux-image-extra-...-generic...i386
<jsalisbury> cristian_c, great.  you should only need the last two, but you can install all three.
<cristian_c> jsalisbury: but I don't see linux-headers....all_deb in that page
<cristian_c> jsalisbury: ah,ok, sorry
<cristian_c> now, I install them
<jsalisbury> cristian_c, you should only need linux-image and linux-image-extra
<cristian_c> ok
<cristian_c> jsalisbury: ok, I've installed 4.2.0-18 kernel
<cristian_c> jsalisbury: linux-headers-...-generic...i386 requested linux-headers....all_deb as dependency, so I've not installed it
<cristian_c> then, I've installed the other two packages: linux-image and linux-image-extra
<cristian_c> jsalisbury: I restarted the machine and I've tried the kernel
<cristian_c> jsalisbury: no more regressions, exactly as for your previous revert kernel
<cristian_c> 4.0.0-1
<jsalisbury> cristian_c, so would you say it resolves the bug?
<cristian_c> jsalisbury: of course, original bug exists yet, and workaround generates the same effects
<cristian_c> jsalisbury: it splves the regression, exactly as for the revert
<cristian_c> *solves
<jsalisbury> cristian_c, that's good news.  That means the regression is fixed in Wily and soon to be fixed in Vivid and Trusty.
<cristian_c> jsalisbury: it'sma good step, if wily mainline kernel already contains the regression fix, it can be treated as solved
<cristian_c> jsalisbury: yeah
<cristian_c> I've tried 4.2.0-18 as suggested from you
<jsalisbury> cristian_c, so you could either upgrade to wily or stay on Vivid and wait for the fix to come in through updates
<cristian_c> jsalisbury: I'll try to install directly Wily to get a confirmation
<cristian_c> :)
<jsalisbury> cristian_c, great.  I look forward to hear how it goes.
<cristian_c> jsalisbury: of course, original bug as stated in the report, exists yet
<cristian_c> jsalisbury: ok
<jsalisbury> cristian_c, yeah, I'm going to look further into that again, now that this other regression is solved.
<cristian_c> jsalisbury: I'll update the bug report with confirmation of disappeared regression
<jsalisbury> cristian_c, thanks.  
<cristian_c> and then I'll try to install wily directly to confirm further
<cristian_c> jsalisbury: ok
<jsalisbury> cristian_c, awesome. running wily will be a good starting point to continue with the original bug.
<cristian_c> ok
<cristian_c> I'll do that
<cristian_c> jsalisbury: see you soon
<cristian_c> thanks again
<jsalisbury> cristian_c, you too.  thanks for all the testing!
<tron103> Hey all, I'm trying to add mellanox infiniband support into the netboot image. The Ubuntu provided drivers seem buggy, so I'm trying to use the official Mellanox package with uses DKMS. Any clue on how to get DKMS modules compiled for a netboot image?
<apw> tron103 (N,BFTL), modules in a netboot image are identicle to those in the main kernel just packaged up differently so install the dkms package on a real system and grab the binaries from there
#ubuntu-kernel 2015-11-20
<gQuigs> so I'm not what parts of kernel.ubuntu.com I can follow without being a member of the kernel team (trying to backport https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1475166 to vivid and wily)
<ubot5> Ubuntu bug 1475166 in linux (Ubuntu) "Ubuntu 15.04 Install Error with Avago Controller" [Medium,Triaged]
<gQuigs> and I meant this doc - https://wiki.ubuntu.com/Kernel/Dev/KernelBugFixing, not sure if it's current, or I can just say in the bug please pull linus commit 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758...
#ubuntu-kernel 2015-11-21
<apw> gQuigs (N,BFTL), you can pretty much follow any of it, as the proceedure is document the fix/testing in the bug, and submit the patch to the kernel-team@ list 
<linuxr> Hi all...I just experienced a full system freeze....is there any way to find out why post-mortem?
<JanC> linuxr: you can check if there is anything in the logs
<linuxr> JanC, found nothing in the logs at the time of the crash...this doesn't give me a bad feeling
<linuxr> I mean gives me bad feeling hehe
<JanC> you could also check if there is anything suspicious before
<linuxr> no messages for hours before the crash, unfortunately...I see no indications of any problems
#ubuntu-kernel 2016-11-21
<caribou> Hi,is there any plan to have the 4.8 kernel available to trusty ?
<caribou> Need to know if I need to SRU the 4.8 makedumpfile fix to trusty as well
<henrix> caribou: not that i'm aware.  only on xenial
<caribou> henrix: thanks!
<henrix> cmagina: when you have a minute, could you please have a look at verifying bug #1632739 and bug #1625232 ?
<ubot5`> bug 1632739 in linux (Ubuntu Xenial) "xgene merlin crashes when running as iperf server" [Medium,Fix committed] https://launchpad.net/bugs/1632739
<ubot5`> bug 1625232 in linux (Ubuntu Xenial) "xgene i2c slimpro driver fails to load" [Undecided,Fix committed] https://launchpad.net/bugs/1625232
<p`monas> I have a laptop suffering from https://bugs.launchpad.net/bugs/1590590. That page suggests there's a fix in the 4.9.0rc , but AFAICT there's no information whether it's going to make its way into the LTS kernel any time soon.
<ubot5`> Ubuntu bug 1590590 in linux (Ubuntu) "Touchpad not recognized on Dell Latitude E7470 Ultrabook" [Medium,Triaged]
<p`monas> the question is whether I wait on LTS or if upgrade to 1610 will get the patch a lot sooner?
<cmagina> henrix: done
 * cmagina actually did it a while ago, just missed the message
<henrix> cmagina: awesome, thanks!
<cmagina> henrix: np
#ubuntu-kernel 2016-11-22
<jmux> Hi. I'm triaging bug https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1643843
<ubot5`> Ubuntu bug 1643843 in xorg (Ubuntu) "Distorted colours after suspend / resume cycle" [Undecided,New]
<jmux> My current conclusion is: linux-image-4.2.7-040207-generic broken, linux-image-4.1.35-040135-generic ok
<jmux> Is there any other way then starting bisection now (something like LibreOffice bibisect repository?)
<jmux> So I'm trying to follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel for bibisect, but it seems most checkout don't  have a debian.master directory. Any idea?
<henrix> stgraber: hi, i'm seeing adt tests failing on xenial.  would you have a minute to have a look, please?
<henrix> stgraber: (lxd failures with the xenial kernel in -propose, to be more precise)
<stgraber> henrix: got a URL for me?
<henrix> stgraber: sure: http://people.canonical.com/~kernel/status/adt-matrix/xenial-linux-meta.html
<henrix> stgraber: or directly to the logs: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxd/20161122_165140_fb379@/log.gz
<henrix> stgraber: it's failing on amd64, i386 and ppc64el
<stgraber> henrix: ah yeah, LXD 2.0.5 with 4.8 kernel won't work because the kernel adds extra security checks to mntns mount injection
<henrix> stgraber: 4.8?  it should be a xenial kernel, 4.4... /me goes look closer
<stgraber> henrix: LXD 2.0.6 which we'll release tomorrow will contain the fix for this (added code to attach to the userns to avoid that particular security check)
<stgraber> henrix: either it's 4.8 or you backported the crazy extra security checks to 4.4 :)
<henrix> stgraber: ok, so i'm clueless about what's happening.  this is supposed to be testing 4.4.0-49.70.  anyway, thanks for looking.  i'll try to figure out what's going on there, looks like a misconfigured test...
<stgraber> henrix: yeah, looks like it's 4.4, which means you cherry-picked a commit which breaks attach to mntns unless you also join the userns
<stgraber> henrix: do you have a link to the git tree you've used for that kernel? I should be able to find the kernel commit that causes that issue
<stgraber> anyway, as I said, we have a workaround for that change in LXD but it won't be in xenial-updates for another couple of weeks (we tag tomorrow + upload, then 1 week SRU cycle)
<henrix> stgraber: the tree is in git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial master-next branch
<stgraber> henrix: ac7f3f73cb393f79f94e4ce8eb6c6cd96864dd28 and ca52383ad6a6a4221395727f81e1b561fef02ae9
<henrix> stgraber: maybe this one...? https://paste.ubuntu.com/23517963/
<henrix> looking
<henrix> ugh
<henrix> sforshee: ^
<stgraber> those basically return EOVERFLOW to LXD when we attempt to create paths leading to our mount target
<stgraber> the fixes aren't wrong per say, but they do break existing userspace :)
<henrix> stgraber: yeah, i see.  i guess we'll need to revert those for now then
<henrix> stgraber: again, thanks a lot for your help!
<stgraber> https://github.com/lxc/lxd/commit/6ff0b5f3b73e0431785e2da1cf0913d6e3e5fd8d
<stgraber> that's the LXD fix to work with that kernel change. You'll probably be fine including those two changes in your kernel in another SRU cycle or two, by that point we'll have the new LXD in xenial-updates
<stgraber> good to see that autopkgtest found an actual regression for once :)
<henrix> heh :-)
<henrix> stgraber: yeah, we'll revisit these patches once we have userspace sorted out
<pfsmorigo> infinity, hi, does ubuntu uses syslinux for something on ppc64el?
#ubuntu-kernel 2016-11-23
<stefanct> hi. one of my patches was accepted upstream including the longterm kernels including the 4.4 branch. i have noticed that xenial's kernel follows the 4.4 stable branch but is some versions behind with security fixes applied only although it was updated more frequently up to 4.4.30
<stefanct> since id like to use my patch without keeping my own kernel id like to know why this is the case and if it will follow upstream more closely again in the future
<JanC> stefanct: did you file a bug report?
<sbeattie> stefanct: if you look at the xenial kernel tree, master-next is up to 4.4.34 https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=master-next ; unfortunately, it didn't make it into the 4.4.0-49.70 that's currently in xenial-proposed, but unless there's a problem with the patch, it should make it in the next SRU cycle, ending roughly Dec 19th: https://lists.ubuntu.com/archives/kernel-sru-announce/2016-November/0
<sbeattie> 00077.html
<sbeattie> bah, silly client, last url should be https://lists.ubuntu.com/archives/kernel-sru-announce/2016-November/000077.html
<stefanct> JanC: no, there is really no reason to create unnecessary work for anybody :) sbeattie: thanks! i was only looking at the changelog(s) and there not much was going on. i can easily work around it till then.
<stgraber> bjf: assuming it's your bot having fun with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1639345, why did it perform that last change (New -> Incomplete) AFTER I added the bot-stop-nagging tag?
<ubot5`> Ubuntu bug 1639345 in linux (Ubuntu) "lxc-attach to malicious container allows access to host" [Undecided,Triaged]
#ubuntu-kernel 2016-11-26
<apw> stgraber, i am not sure any of the bots honour that tag ... move it confirmed to avoid that bot
#ubuntu-kernel 2017-11-20
<ret2libc> hi! does ubuntu still uses initramfs/initrd? i'm trying to look into them, but i cannot find anything interesting. initrd just contains a microcode and the initramfs included in the kernel source ./usr has just /dev/console and root.
<TJ-> ret2libc: you're only seeing the prefix
<ret2libc> TJ- what do you mean? do you have ref/links?
<TJ-> ret2libc: the microcode is 'prefixed' onto the initrd.img file as a binary concatenation
<ret2libc> TJ- ok but where's all the /bin, /dev, /init, etc. stuff?
<apw> lsinitramfs shows the full content
<ret2libc> apw: whoa... nice! thanks a lot! now the only thing i need to understand is what's the difference between that cmd and cpio :)
<apw> re t
<apw> ret
<apw> ret2libc: there are multiple cpio archives back to back in an initramfs
<ret2libc> apw: thank you, now i know where to look!
<TJ-> ret2libc: sorry; been working on something else. I wrote a script that extracts it if you want it: http://iam.tj/projects/ubuntu/initramfs-extract
#ubuntu-kernel 2017-11-21
<Taggnostr> hello
<Taggnostr> I installed 17.10 when it came out a month ago and I had some wifi-related issues that are apparently fixed in 4.13.8 but I haven't seen any kernel update yet and still have 4.13.8.  I saw some notes mentioning that there was supposed to be an update today but I haven't seen that either.  Do you know if/when the kernel will be updated?
<f_g> ret2libc: unmkinitramfs is what you are looking for ;) part of initramfs-tools just like lsinitramfs
<ret2libc> thank you TJ- !
<TJ-> ret2libc: whadidido?!?
<ret2libc> for the script to extract initramfs
<TJ-> ret2libc: OH!! lol... I'd forgotten, I've been to sleep since then :)
<ret2libc> me too, but i don't forget :P
<TJ-> ret2libc: I find it helps else my brain would leak out my ears
<ret2libc> f_g: btw i cannot find that binay anywhere in none of the initramfs-tools-* packages
<ret2libc> TJ-: it usually does, except today... woke up sick, not a good sign :)
<TJ-> ret2libc: get out in the fresh air! I'm about to do my daily cross-country run around the farm tied behind 2 Huskies :)
<TJ-> ret2libc: what binary have you lost?
<ret2libc> TJ-: f_g was saying that unmkinitramfs is what i'm looking for. I suppose it does something similar to your script, but actually i cannot find it in any package
<TJ-> ret2libc: that's referring to Debian, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807457
<ubot5> Debian bug 807457 in initramfs-tools "Add command to unpack initramfs" [Wishlist,Fixed]
<TJ-> ret2libc: see the list of files for https://packages.debian.org/stretch/all/initramfs-tools-core/filelist 
<ret2libc> it's not in ubuntu though. so it's just easier to use your script
<TJ-> ret2libc: I think the script is smaller too :)
<f_g> ret2libc: hah! didn't know that was debian-only ;)
<ret2libc> f_g: no problem ;)
#ubuntu-kernel 2017-11-22
<JanC> heh... "linux-image-4.13.0-17-generic_4.13.0-17.20_amd64.deb: subprocess new pre-installation script returned error exit status 1"
<JanC> oh, I see
<JanC> apparently debconf has its own lock...
#ubuntu-kernel 2017-11-23
<Laney> bah
<Laney> now I can't reproduce https://bugs.launchpad.net/bugs/1730717 very well
<ubot5> Launchpad bug 1730717 in linux (Ubuntu Bionic) "Some VMs fail to reboot with "watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd:1]"" [High,In progress]
<Laney> is there something I can install on all the test VMs to put them into high load easily?
<Laney> guess I can write a userdata thing to install stress-ng and run that?
<apw> right that thing will make it sad in all sorts of different ways, is it cpu load you need
<Laney> not sure
<Laney> we were suspecting it happens more when the cloud is 'busy'
<Laney> but don't know in which way specifically
<Laney> I'll just turn on all the things I guess
 * Laney has cleared out lcy01 from adt instances for the time being
<Laney> GREAT now I can't schedule instances at all
<Laney> ubuntu@laney-test1:~$ uptime 11:57:35 up 3 min,  2 users,  load average: 509.30, 210.40, 79.27
<Laney> that's working then :-)
<apw> heheh
<TJ-> Any ideas how to further diagnose an ecryptfs mount failure, when the internal mount() call returns "No such file or directory". This is on bare-metal and both source and target are accesible.
<TJ-> Is there something internal via  debugfs I could watch?
<Laney> 50 stressy units coming our way
<apw> TJ-, hmmm
<apw> TJ-, nothing in dmesg at the time it occurs ?
<apw> TJ-, all the thingsi n ecryptfs that could return ENOENT seem to report something in dmesg first
<apw> TJ-, otherwise it is generic
<TJ-> apw: no; it's actually quite a severe problem I've been working on for a few days with an Ubuntu 17.04 user. They recently used the GUI to change their user password, after which they could not log-in. Turns out the encrypted home was no longer being unlocked, suggesting the GUI somehow didn't rewrap the ecryptfs passphrase. The user has the original key (hex passphrase) but that wasn't working either.
<TJ->  Then I spotted the Private.sig entries were not the current keys, so wrote a script to automate test and mount. We found /sbin/mount.ecryptfs_private was failing due to the underlying "mount()" call reporting "No such file or directory". So, looking for what the real cause is.
<TJ-> This was discovered via strace
<apw> TJ-, and nothing in dmesg, hmm
<TJ-> apw: No
<apw> what were the parameters to mount when it failed
<apw> in your strace output, PM me if they might be sensitive
<TJ-> They're ellided unfortunately but I used the source-code to figure out the entire mount command and we tried that manually, but of course that wouldn't work since mount needs calling with sudo, but the root user doesn't have the user's keyring attached
<TJ-> apw: The user account name is "a1". Everything about it checks out (ownership, permissions). Here's the strace: http://paste.ubuntu.com/26023608/
<TJ-> This'd be the equivalent manually: sudo mount -t ecryptfs /home/a1/.Private /home/a1  -o rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=782cb407b85d0079,ecryptfs_sig=769688550d78ced9,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs
<apw> and .Private exists
<TJ-> apw: oh yes, everything is there. Pastebin's available if you want to check
<apw> no i trust yoy
<TJ-> I may have missed something :)
<TJ-> Interesting aside - ) had to make strace setuid-root to be able to capture the trace, else te setreuid() failed
<apw> TJ-, so if those signatures were not for keys the filesystem contains
<apw> then you would get ENOENT
<TJ-> The key sigs matched the ones in Private.sig 
<apw> those are outside the filesystem though
<apw> that is nothing to do with what the filesystem has inside
<apw> anyhow, maybe not that, i wonder what else
<TJ-> Right. The thing is, a few days ago when trying to manually mount, the user may have accidentially mistyped the hex passphrase. The mount succeeded but obviously the contet was garbage. I got him to unmount immediately, but the few files that got updated show up in .Private/ because the key-sig encodings changed for those files (in the filenames)
<apw> so they hve mounted using the wrong passphrase over that directory
<TJ-> Yes, once.
<apw> when you say they show up in .Private, when ?
<apw> or are they the only things in there now
<TJ-> But You can see it here... starting line 55 http://paste.ubuntu.com/26023177/
<TJ-> you'll see the original files-sigs prior to Nov 20th, and then the 15-ish changed when the wrong key was used
<TJ-> I wonder, is there a way to convert the filename encoded signatures back to hex so they can be matched to the Private.sig entries?
<apw> ok there is definativly no report for ecryptfs in dmesg, if that is so
<TJ-> no
<apw> then ecrypt_fs mount did not fail, it would have reported something itself always if it fails
<TJ-> right, which is why I was asking for inspiration to debug this further :)
<TJ-> The user has a keepassxc database in there, else he'd just redo the entire thing
<apw> where is . in that mount, is that home ?
<apw> have you tried mounting it somewhere else
<apw> it woudl return ENOENT if . was a deleted directory
<TJ-> Yes, it is. The "." is hard coded in mount.ecryptfs_private! That was the first thing I chased down, thinking it was wrong
<apw> but you could like
<apw> mkdir tmp
<apw> cd tmp
<apw> and run it there ?
<TJ-> circa line 687 of src/utils/mount.ecryptfs_private.c:: if (mount(src, ".", FSTYPE, MS_NOSUID | MS_NODEV, opt) == 0) {
<TJ-> Tried that too; doing a  "pushd /tmp" just before the call to /sbin/mount.ecryptfs_private (in my test script)
<apw> you likely could not mount it over /tmp
<apw> for other reasons
<apw> it will also return ENOENT if the "." in this context is marked dont_mount, which also seems to be removed/renamed things
<apw> have you tried mounting a ramfs over the "."
<apw> that might tell you if any of those tests would fail
<TJ-> No, but it doesn't work that way in mount.ecryptfs_private - it calls getpwid(), then does a chdir() to the home, *then* uses "."
<apw> you could try the tmpfs thing then
<apw> see if "." is sick for soem other reason
<TJ-> No, haven't tried mounting ramfs over ., but . will always be $HOME (as in what getent passwd a1 shows)
<apw>         printk(KERN_ERR "%s; rc = [%d]\n", err, rc);
<TJ-> I've run the same tests exhaustively on multiple test user accounts whilst messing up the sigs etc, and not been able to recreate this mount fail
<apw> as we have that ^ in ecryptfs_mount, i don't see how it can be ecryptfs related, so it should fail for other things
<TJ-> I wondered if it was keyring related, but the user wrote down the original hex key and is using that now
<apw> how did you look for the errors from btw
<TJ-> errors from...? I'm not sure I understand what you're asking?
<apw> in dmesg
<TJ-> oh, got the user to pastebin the log
<apw> have you got that pastebin ?
<TJ-> Not in a tab right now... I only kept the ones that had 'interesting' info - e.g. something related. We got through about 60 pastebins!
<apw> as the messages are not tagged for ecryptfs
<TJ-> But, I told him yesterday I'd seek advice then we'd do another debug session, so I can collect that
<apw> it would say liek "Getting sb failed; rc=N"
<apw> rather than being obviously related
<apw> rubbish errors for the win
<TJ-> I was reading every line *very* carefully, also had "dmesg -w | tail" to capture anything that happened whilst the mount command was running
<TJ-> I'll capture a dmesg run with the user next time I make contact
<TJ-> I can get him to boot with 'debug' too which might add something
<TJ-> in case it's of interest, this is the test/diagnostic script I've created: http://iam.tj/projects/ubuntu/ecryptfs-regenerate-wrapper_signatures_mount_test
<apw> i cannot see anything which would make mount fail outseide of ecryptfs that would not i believe stop any mount
<apw> and if it was inside, then it must seemingly be logged in dmesg
<apw> so i guess confirming dmesg is clear, and that mounting tmpfs or something in the same place first
<apw> to confirm something can be mounted there
<apw> other than that, hrm, you need some debug in your kernel i recon
<TJ-> Yeah... it's a weird one. What annoys me is, the origin of all this is the GUI failing to rewrap the passphrase on password-change; and I've hit that myself a few times at random since 14.04 at least but never figured out why
<TJ-> well actually not even failing to rewrap... it does rewrap, but doesn't use the new user password, which is worse, so trying to unwrap with old or new password fails
<apw> no i don't think i have ever really been confortable with ecryptfs and its madness
<apw> i am gald we are moving to using native encryption on the filesystem
<TJ-> Thanks for your help on this, I'm glad it's not just me missing something stupidly obvious
<TJ-> I was planning on bugging Tyler with it :)
<apw> possibly still worth it
<TJ-> Yes... I'm going to write up a cogent bug report that doesn't look like a novel :)
<apw> TJ-, i do wonder if there is any milage in moving the things with the wrong FNEK out of there
<apw> i can't see it checking if any of them are bad as part of mount, but
<TJ-> apw: I was planning on making an entire copy to another location, so we can test safely :)
<TJ-> The 'wrong key files' issue was the user logged in at the console and the $HOME/.ecryptfs/auto-mount file was there so pam_ecryptfs did the mount. As soon as I realised I had that deleted
<TJ-> apw: I think you're onto something with the different keys. Looking at the kernel source, all the -ENOENT are in keystore.c and most seem related to calls to ecryptfs_find_auth_tok_for_sig() ... looking at calls to that function, one that stands out is ecryptfs_parse_tag_70_packet() which parses the signatures out of the filename. Now, if the lower superblock is mounted and then it is trying to decrypt
<TJ-> one of those filenames encoded with the possibly-mistyped-hex-key that might be triggering -ENOENT, but related to the keyring, not the file-system
<apw> that should be testible, make two test mounts and umount htem, then copy a file from one to the other
<apw> and see if that blows its brains up
<TJ-> Yes
<TJ-> I'm going to do that here after I've run the Huskies into the ground :)
<apw> if it does that is one for the faq
<TJ-> I need the fresh air after all this digging
<apw> (of doom)
<apw> heh i know the feeling, lick
<TJ-> hehehe yeah
<apw> luck, and lick if there are huskies
<TJ-> We've got 50kmh wind gusts just now so I should take a hang glider out and let them tow me :D
<apw> heh, a plan indeed, and much more fun than reading kernel code slowly
#ubuntu-kernel 2017-11-24
<CyberManifest> I'm not sure if I'm in the right place, but I was trying to use: "Ubuntu Kernel Update Utility (Ukuu) v17.2.3) to update to the latest Kernel that was released a few hours ago: "4.14.2" and it wasn't present. I was wondering if you guys were aware of the release of 4.14.2 and if it would soon be available in the Ubuntu repositories ?
<apw> CyberManifest, those are the mainline test builds i assume
<CyberManifest> apw, mainline stable builds
<apw> CyberManifest, mainline test builds is what they are ... as i build them :)
<CyberManifest> apw: https://www.kernel.org/
<CyberManifest> ^ listed as stable
<apw> they are stable kernel branch tags yes, but the builds are simply test builds to confirm they are buildablwe
<CyberManifest> apw: for how long?
<apw> for how long what ?
<apw> CyberManifest, anyhow apparenly the test-build is building at the moment
<CyberManifest> apw, cool guess that answers my question; I was wondering how long they are in "test-build" before releasing to "stable"
<apw> CyberManifest, no i think you have gotten wholey the wrong end of the stick
<apw> CyberManifest, upstream is releasing stable kernels, those are tested before release and released when they deam they are stable
<apw> CyberManifest, automation here notices those and schedules test-builds of those for ubuntu so we know they are viable to
<apw> CyberManifest, apply as stable updates and the like, and for use in bisection
<apw> CyberManifest, from our perspective they are never anything other than test-builds, we never evaluate them for use and bless them
<apw> CyberManifest, for a start they do not include any ubuntu patches so they are not guarenteed to be compatible with ubuntu userspace even
<apw> CyberManifest, so that v4.14.2 was tagged at 07:37 UTC and was picked up for building at the 08:30 UTC scan, so things are going pretty snappy
<CyberManifest> apw, first, I'm a user, coming from a Microsoft world, so I don't know what "upstream" is. Second, you're telling me they aren't ever considered "stable" by Ubuntu's standards? I'm so confused, all I'm really interested in knowing is when will Linux kernel 4.14.2 be available in/on Ubuntu Kernel Update Utility (Ukuu) ?  
<apw> CyberManifest, you would want to ask the person who writes that (who isn't the Ubuntu kernel team), but assuming it is waiting for the test-build to complete, i'd say another hour
<CyberManifest> apw, the app Fetches list of kernels from kernel.ubuntu.com
<CyberManifest> when does kernel.ubuntu.com get propagated ?
<apw> CyberManifest, yes, from the Mainline "Crack" Test Builds repository, not from anywhere officially supported
<apw> CyberManifest, the current test-build will hit that in about an hour by my estimation of watching the log of it building wizzing by
<CyberManifest> apw: what does "Mainline "Crack" Test Builds repository" mean? I'm using Linux Mint by the way.
<apw> CyberManifest, it is pulling them from the repository which has the following as its offical description: https://wiki.ubuntu.com/Kernel/MainlineBuilds
<CyberManifest> Linux Latitude-E6230 4.14.1-041401-generic #201711210430 SMP Tue Nov 21 09:32:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
<apw> CyberManifest, we call them crack builds, from an affectionate term for people wanting the latest every single morning, rather than something that has been validated
<apw> CyberManifest, they are affectionatly know as the 'crack-of-the-day' builds
<CyberManifest> apw, does that mean there will be more stable branch releases in the 4.14 series?
<CyberManifest> perhaps I should revert back to 4.10 ?
<apw> CyberManifest, there are usulally 5 or 6 in each series minimum, as greg supports those until the 
<apw> next mainline kernel comes out v4.15 in this case
<apw> CyberManifest, i always recommend running official kernels, but then i produce them
<apw> (where "i" is our team not me)
<CyberManifest> apw but won't the newer *crack* kernels have better security there have been a lot of exploit activity lately
<apw> CyberManifest, that is difficult to be sure about, any truly urgent fix will be applied to official kernels first
<apw> CyberManifest, before they are even published in upstream stable
<CyberManifest> apw, ok, I think I understand
<CyberManifest> apw: thank you for the information and help
<apw> np
#ubuntu-kernel 2017-11-25
<hallyn> all right, so apparently keyring in 4.13/artful in virtualbox on macos just doesn't quite work right.  mount.ecryptfs_private cannot find my key by hash there, but does so fine in same kind of vm on kvm on linux.
<hallyn> can't strace setuid so i guess i'll setup a root env and run in gdb
<hallyn> bah, that won't help.  it's happening in the actual mount syscall isn't it
<hallyn> well, moving it to vmware didn't fix it, so it's not a virtualbox bug at least
<apw> hallyn: what is the error from the mount system call ...
#ubuntu-kernel 2017-11-26
<hallyn> apw: ENOENT
<hallyn> mount -t ecryptfs with having the helper ask for the passphrase works,
<hallyn> it's only passing they keyid in as a mount arg that doesn't work
<hallyn> (i.e. using mount.ecryptfs_private)
#ubuntu-kernel 2019-11-18
<bjf> klebers, ^ 
<klebers> bjf, are you pointing to the lz4 issue report by ChmEarl?
<bjf> klebers, i am
<bjf> klebers, i just wanted it on your radar
#ubuntu-kernel 2019-11-19
<dpward> Hi, gentle reminder, can someone please assign LP#1846539. The kernel config options in Eoan for Intel sound are invalid (according to Intel). On the Broadwell platform, there is not only no sound, but also significant desktop hanging as a result. A config change fixes this.
<sdhd-sascha> hi, i want to build deb-packages from linux-image-...-raspi2. I fetched the source with apt. Then there is a debian/, debian.raspi2/ and debian.master/ directory. Additional i found a snapcraft.yaml. - Now i wonder how to build the debian packages? A simple dpkg-buildpackage did not work. "apt-build install --build-only " on arm64 failed. To run snapcraft on amd64 failed with 
<sdhd-sascha> "eoan/parts/kernel/src/debian.raspi2/config/amd64/config.common.amd64"
<cascardo> sdhd-sascha: what was the failure when using dpkg-buildpackage ?
<sdhd-sascha> cascardo: that the changelog file is missing. Lastly i tried: "$ gbp dch --ignore-branch" 
<sdhd-sascha> >>> gbp:error: Did not find debian/changelog or debian/source. Is this a Debian package?
<sdhd-sascha> cascardo: sorry, correction: i get the source from git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan
<sdhd-sascha> cascardo: with "apt source linux-image-5.3.0-1012-raspi2" it starts building... Now i need to figure out, how to crosscompile...
#ubuntu-kernel 2019-11-21
<sforshee> LocutusOfBorg: you closed bug 1848594 as invalid, but virtualbox-guest-dkms in focal still fails to build with 5.4. Any ETA for a fix?
<ubot5> bug 1848594 in virtualbox (Ubuntu) "virtualbox 6.0.12-dfsg-1 ADT test failure with linux 5.4.0-1.2" [Undecided,Invalid] https://launchpad.net/bugs/1848594
<LocutusOfBorg> sforshee, ack
<LocutusOfBorg> sforshee, ack
<shibboleth> linux-signed-generic-hwe-18.04-edge modules not secure boot compatible atm?
<sarnold> shibboleth: which package name specifically are you looking at? I don't see a 'linux-signed' anything on https://launchpad.net/ubuntu/+source/linux-hwe-edge/5.3.0-23.25~18.04.1 --  just the usual linux-image-unsigned-$foo and linux-image-$foo packages
<shibboleth> linux-signed-generic-hwe-18.04-edge        5.3.0.23.90
<sarnold> ah thanks, I was looking in the wrong source package: https://launchpad.net/ubuntu/+source/linux-meta-hwe-edge
<sarnold> the descriptions all look like it should depend upon signed kernels.. where's it going wrong for you?
<tyhicks> shibboleth, sarnold: I'm only going off of vague memory but I think there's a small bug keeping it from working in Bionic
<tyhicks> let me see if I can find it
<sarnold> oho :)
#ubuntu-kernel 2019-11-22
<tyhicks> bug: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-edge/+bug/1852581
<ubot5> Ubuntu bug 1852581 in linux (Ubuntu) "hwe-edge kernel 5.3.0-23.25 kernel does not boot on Precision 5720 AIO" [Critical,In progress]
<tyhicks> fix: https://lists.ubuntu.com/archives/kernel-team/2019-November/105544.html
<tyhicks> sarnold, shibboleth: ^
<sarnold> tyhicks: heh, bummer the simple simple fix can't actually be used by anyone but us
<shibboleth> ty
<m90s> Hi, I found a way to get a kernel opps by using tcpdump to write to a file on a USB stick and then unplugging the USB stick.
<m90s> what is the best way to report this?
<m90s> I where able to repoduce this on multipe platforms and kernel versions.
<sub526> I installed crashdump tools(kexec\kdump) to acquire a crashed Linux kernel dump and enabled the âkernel.panic = 60â,  âkernel.softlockup_panic = 1â and âkernel.hardlockup_panic = 1â variables. I triggered the some kind of misbehavior in the kernel by writing to /sys/kernel/debug/provoke-crash/DIRECT file. I see that my system just
<sub526> reboots without copying the crash dump to /var/crash.. Can someone help me to collect the coredump?
<sub526> *crash dump
<sub526> My system has linux-crashdump\kexec-tools\crash deb packages
<sub526> and kdump-tools
<connor_k> m90s, the best place to report that is by filing a bug on launchpad: https://bugs.launchpad.net/ubuntu/+source/linux
<cascardo> connor_k: I guess that person is gone from IRC already
<cascardo> sub526: do you have console access? a virtual terminal would suffice (tty1)
<connor_k> cascardo: yeah I suppose so :-/ maybe all the join/leaves arenât present in the history from my bouncer to my phone. Thatâs okay, still good advice in general lol
<sub526> cascardo: yes, i've monitor connected
<cascardo> sub526: and which version of kernel and kdump-tools do you have?
<cascardo> sub526: okay, I mean a console opposite to a graphical environment. at least, that could help finding out if the panic kernel is executed at all
<sub526> cascardo: kdump-tools : 1:1.6.3-2~16.04.1 and 5.0 kernel
<cascardo> sub526: that seems to be xenial, what is uname -r ?
<sub526> For debugging purpose, I compiled an installed the vanilla kernel 5.0 on Ubuntu 16.04.4 machine
<cascardo> well, that version of makedumpfile probably does not support 5.0. at least, you would get a very large dumpfile on /var/crash/
<cascardo> but at worst, it wouldn't be able to dump the kernel at all
<cascardo> sub526: by debugging purposes, do you mean debugging the kdump/crash situation or something else?
<sub526> cascardo: no, I'm facing system hang issue for actual test case... So to debug this I enabled few debug options like KASAN etc on plain kernel and then rebuild it. 
<sub526> cascardo: Before executing the actual test case, I'm trying to validate my system whether it supports collecting the crashdump or not...
<cascardo> sub526: well, I would suggest you get a more recent makedumpfile/kdump-tools too, then, if that's possible
<cascardo> sub526: and which config did you use? the same one as Ubuntu's? and which kernel source?
<sub526> cascardo: I downloaded the kernel source from https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/
<sub526> linux-5.0.1.tar.gz
<cascardo> okay, so that doesn't contain Ubuntu patches
<cascardo> what about the config?
<sub526> Regarding .config , I added certain debug options under 'kernel hacking menu'
<cascardo> added in respect to what base?
<sub526> I ran make defconfig and then make menuconfig
<sub526> CONFIG_KEXEC=y, CONFIG_KEXEC_FILE=y, CONFIG_ARCH_HAS_KEXEC_PURGATORY=y, CONFIG_KEXEC_JUMP=y, CONFIG_KEXEC_CORE=y
<sub526> my .config has above stuff related to kexec
<sub526> also CONFIG_CRASH_DUMP=y, CONFIG_COREDUMP=y
<sub526> do you see any issues in this aproach?
<cascardo> sub526: what about CONFIG_CRASH_CORE ?
<sub526> cascardo: CONFIG_CRASH_CORE=y
<cascardo> sub526: okay, so what do you get on your console after panic?
<cascardo> sub526: and by the way, can you update kexec-tools and makedumpfile/kdump-tools ?
<cascardo> yeah, kexec-tools could be an issue
<cascardo> by update, I mean you should get a version from bionic, at least, but better if newer than that, like the one from eoan
<sub526> cascardo: sure , i will update those tools. sudo apt-get update and then install or any other method?
<sub526> In console I see the corresponding crash dump and after kernel.panic timeout it reboots, but /var/crash is empty.. also no crash log in /var/log/kern.log
<cascardo> sub526: what do you mean by corresponding crash dump ?
<sub526> Dumb question: console log mean whatever displayed on monitor, right? What exactly console means?
<cascardo> sub526: yeah, if you see reboot logs and crash dump logs on the monitor, that's sufficient
<sub526> cascardo: I triggered crash via SYSRQ key press and corresponding log I can see in monitor
<cascardo> sub526: what is the version of kexec-tools?
<sub526> let me check
<sub526> 1:2.0.16-1ubuntu1~16.04.1
<cascardo> I checked that xenial-updates has a reasonable recent version
<cascardo> yeah, 2.0.16, not too old
<sub526> Cascardo:  As per https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html , i understood that a manual intervention is required in order to capture the memory for 'machine exceptions'. What exactly âmanual interventionâ means? 
<cascardo> sub526: I haven't seen that guide before, I am not certain what that means. but you are doing the right thing in testing that it's working, because kdumping is not a certain success as you can see by yourself
<cascardo> sub526: I need to attend a meeting and get out after it, can you open a bug? I can promise I can work on it, unless you can reproduce it with the Ubuntu kernel? you should try linux-hwe, you will get a 4.15 kernel on xenial
<sub526> cascardo: Sure thanks for your support.. Bye for now.. 
<cascardo> sub526: and do you see makedumpfile being called at all? is that what you mean by corresponding log? or only the panic stack trace?
<sub526> I did not check for makedumpfile being called, but I see panic stack trace. 
<sub526> what exactly need to be checked in makedumpfile called or not?
<cascardo> sub526: well, there should be two rebootss
<sub526> cascardo: /sbin/reboot is part of systemd-sysv - is this gets called? what is other reboot?
<cascardo> sub526: so, what I mean is that after panic, the system should start executing the kdump kernel, which will trigger the capture of the dump followed by a cold reboot
<sub526> ok
<cascardo> if you don't see the logs for the kdump kernel after the panic, but a cold reboot, then there will never be an opportunity for makedumpfile to execute
<cascardo> if you see those logs, but that kdump kernel panics itself, or there is an OOM on that kernel, then those logs would be useful to understand what is happening. in the case of an OOM, increasing the memory for crashkernel allocation should fix it
<sub526> cascardo: what should be the kernel.panic set to?
<cascardo> sub526: do you see the "Rebooting in 60 seconds..." message? if you do, then crash kernel is not being executed?
<cascardo> what is the result of kdump-config status ?
<cascardo> and kdump-config show ?
<sub526> cascardo: current state   : ready to kdump
<sub526> cascardo: https://pastebin.com/Lb0tADcZ
<sub526> cascardo: kdump-config show, looks ok?
<cascardo> sub526: that looks ok
<cascardo> sub526: I need to go out now, just let me know if you see the "Rebooting in 60 seconds..." or not
<sub526> cascardo:I did not see that log
<sub526> What it means?
<sub526> cascardo: Thanks a lot for your support. I need to leave now... will catch you in next week.
#ubuntu-kernel 2019-11-23
<ChmEarl> I did unlz4 on a focal kernel, size now is 44 MB, are there any tools which can recompress it, without using the ubuntu kernel delta?
<ChmEarl> 45018340 Nov  6 11:39 kernel.decomp.ok
<ChmEarl> why did I do it? it works uncompressed in Xen as pv domU kernel
<ChmEarl> as I understand, proper comression is done in kernel buildroot as: make bzimage
<ChmEarl> when I build xen-4.12.1 in focal chroot, the hypervisor also gets LZ4. Where would the xen Makefile possibly get an LZ4 config?
<ChmEarl> maybe /etc/mkinitcpio.conf ?
