#ubuntu-kernel 2005-05-30
<zul> fabbione: i got some janitoral and gcc4 fixes in my tree sync whenever
<fabbione> zul: yo
<fabbione> ok
<fabbione> probably tomorrow when i will wake up
<fabbione> i am still around because i don't feel very good
<fabbione> and i couldn't sleep
<zul> sure...ill be around by tomorrow is a holiday in ontario so ill be around off and on
<fabbione> ok :)
<zul> started your period? ;)
<fabbione> kinda
<zul> must...go..watch...star wars...tomorrow
<zul> heh
<fabbione> i just come back from it
<fabbione> the movies was good but i didn't enjoy
<fabbione> because i started to feel bad at the cinema
<zul> too much popcorn i bet..
<fabbione> no
<fabbione> i couldn't even touch popcorn that i felt to throw up
<zul> yuck..
<fabbione> getting cramps at the cinema was no fun :(
<zul> meh...episode 2 is on the telly in about 2 minutes
<fabbione> yeah i have the DVD's of all the others
<fabbione> there are already torrents of SW3
<fabbione> but not DVD quality yet
<zul> im downloading asterix conquers america right now ;)
<fabbione> ehhehe
<fabbione> i am getting SW Revelation
<zul> hehe
<zul> bbl
<fabbione> yeah i am off too
<fabbione> i need to try to get some sleep
<fabbione> tomorrow i will start my danish course
<zul> codine helps :)
<zul> i use to know some danish swear words
<fabbione> cya
<fabbione> i don't even know these ones
<fabbione> :)
<fabbione> never cared to learn
<fabbione> ahhaa
<zul> i can swear in 5 different languages ;) its a special talent i have
<fabbione> hehhehe
<fabbione> anyway
<fabbione> cya tomorrow
<fabbione> have fun
<zul> c ya
<fabbione> morning
<fabbione> zul: i can't access your baz repo...
<fabbione> hi chmj 
<chmj> hi fabbione 
<fabbione> chmj: any status update for the automatic external drivers tracking?
<chmj> fabbione: not yet, still have drafty code  
<fabbione> ok
<fabbione> you know that there is already some code written, don't you?
<fabbione> you can reuse a big portion from debian/watch
<chmj> yes, I copied some of it 
<fabbione> ok
* fabbione updates ipw2200 to 1.0.4
<mjg59> fabbione: I need to send you acpi-bk and an ide resume patch
<fabbione> mjg59: and what are you waiting for?
<fabbione> :)
<fabbione> i might be able to upload today if i have the time
<fabbione> no actually
<fabbione> i won't even make it in time for a build orgy today
<mjg59> fabbione: Yeah, depends how busy I am later on
<mjg59> fabbione: BTW, when we get it, the generic ACPI hotkey driver needs to be *off*
<mjg59> It fucks up all the other hotkey drivers
<fabbione> ok.. 
<fabbione> i hope i can remember :)
<mjg59> I'll mention it in the mail
<fabbione> ok
<fabbione> time to get some lunch
<chmj> hmm, me to 
<pitti> Hi
<fabbione> bah
<fabbione> I HATE EXTERNAL DRIVERS
<pitti> btw, did you hear about any problems with the prism2 driver in 2.6.12?
<fabbione> nope
<pitti> they just crash on 2.6.12 for me
<fabbione> fun
<pitti> ok, I'll file a report
<fabbione> are they external?
<pitti> yes
<pitti> linux-wlan-ng
<fabbione> sec...
<fabbione> did you try the hostap drivers instead?
<chmj> fabbione: why is that? :P 
<pitti> fabbione: I need the prism2 USB drivers, they are only provided by l-w-n
<fabbione> pitti: better you go upstream directly
<fabbione> i can only wait for them to release a new version
<fabbione> wlan-ng-prism2-usb | 0.2.1-pre26                | ok     | 12/04/2005   | http://linux-wlan.org/
<pitti> fabbione: ok; they work fine in 2.6.10, so 2.6.12 has a newer version?
<fabbione> that's the version we are using now
<fabbione> probably
<fabbione> yes
<pitti> ok
<fabbione> it has been updated the 12/04/2005
<mjg59> fabbione: Patches mailed
<zul> hey
<zul> fabbione: my internet connection went down last night
<zul> its back up now
<fabbione> mjg59: ok, got them...
<fabbione> zul: ok thanks :)
<fabbione> mjg59: but does it make any sense to push these patches in 2.6.12rc4?
<fabbione> aren't they supposed to go upstream anyway?
<fabbione> bah we can't upload crap anyway
<fabbione> that is kind of sucky
<mjg59> fabbione: They're unlikely to end up in 2.6.12
<fabbione> mjg59: ok
<mjg59> But we need the ide-sleep one for some machines, and that requires the acpi/device binding stuff in the bk patch
<lamont> fabbione: the kernel is a C++ app???
<lamont> say it isn't so...
<fabbione> no, but it needs a working dpkg
<fabbione> and that's not the case since it was still banned from the buildd as 4 hours ago
<fabbione> -> no new dpkg on porting boxes -> me can't test shit
<fabbione> so no upload
<fabbione> zul: where did you steal the msleep patch?
<zul> fabbione: i did that patch
<fabbione> zul: did you send it upstream?
<zul> not yet...i was going to send it to kj 
<zul> i wanted your opinnon first
<fabbione> what's the use case?
<fabbione> do they fix something?
<zul> nah...kj has a big assed list of things to look out for and the patches i did was on the list
<fabbione> zul: btw i did fix the kernel-package problem
<fabbione> it was an inconsistency between k-p and dpkg
<zul> hah...i knew i was not on crack :)
<fabbione> well just upgrade and it should work
<fabbione> at least.. it does here
<zul> i went back to hoary so it works fine here
<zul> right im off to see star wars
<fabbione> zul: enjoy
<fabbione> may the force be with you
<zul> yes my master
<fabbione> eheh
<fabbione> mjg59: how urgents are these 2 patches? can they wait an upload in the middle?
<fabbione> hey thom
<thom> hi
<fabbione> thom: i have some hoary crack for you :)
<thom> i have plenty of my own, thanks
<fabbione> well.. a bit more will keep you more busy :P
* thom throws stuff at fabbione 
<thom> swap you for mozilla/firefox
<fabbione> bah boring
<fabbione> it's only 30MB of source code
<thom> yes, entirely boring
<thom> twice
<fabbione> 46776 -rw-r--r--   1 fabbione src 47845355 2005-05-08 08:12 linux-source-2.6.12_2.6.11.92.orig.tar.gz
<fabbione> oh come on
<fabbione> one kernel is 47MB :)
<thom> yeah, but you only have to fix the vuln once
<thom> moz and ffox are differnet code bases
<fabbione> yeah..
<thom> (and i do mean _different_)
<fabbione> i know.. i have been looking at it once... but i can't remember why
<fabbione> i removed that horror from my mind very fast
<fabbione> s/fast/quickly
<thom> heh
<fabbione> yay for ia64!
<fabbione> it doesn't build OCFS2
<fabbione> speaking of which i should try a build on sparc, even if it is pointless
<zul> so that was an ok movie
<mdz> is there a timeline for moving to 2.6.12 as default in breezy?
<mdz> I'd like for the breezy daily live CDs to be built with 2.6.12 when we start to build them, in order to experiment with unionfs and squashfs
<zul> not sure yet..
<Mithrandir> mdz: I think "soon", but I don't have a definitive date.
<Mithrandir> and fabio is most likely asleep.
<lamont> mdz: we're not doing abi versioning during the RC's right now...  so moving 2.6.12 to main and making it the default now either exposes some abi b0rkage, or makes us start tracking them...
<mdz> don't we have an automated ABI checker now?
<lamont> yeah.
<lamont> do you really want the first version of 2.6.12 to be ABI version number 33?
<mdz> the number is not important to me
<mdz> I just want to know your intentions so that I can plan development accordingly
<lamont> ok.  we've been ignoring abi breakage in the rc's because we don't want to put an RC into main, and that helps discourage things...
<mdz> so you're waiting for 2.6.12 final upstream?
<lamont> that's been my understanding - fabbione would be a better person to ping, truthfully
#ubuntu-kernel 2005-05-31
<zul> fabbione: those video msleep patches have been pushed upstream
<mjg59> fabbione: Not massively urgent, but it would be good to get them tested soon
<mjg59> It can wait a while
<mdz> any reason to keep linux-source-2.6.11 around in breezy?
<zul> i dont see why not imho
* netjoined: irc.freenode.net -> tolkien.freenode.net
<zul> hmmm...there is usb suspend/resume config option
<zul> fabbione: you around?
<zul> hey lamont 
<lamont> howdy
<zul> how goes it?
<fabbione> morning
<fabbione> we can upload the kernel today!
<fabbione> amazing :)
<fabbione> lamont: did you try to build on hppa?
<fabbione> it might need some config tuning
<lamont> fabbione: not yet, but it should be happy
<fabbione> hmm i am not sure about OCFS2
<lamont> the hppa buildds have been busy....
<lamont> you want a test build?
<lamont> is not a big deal
<fabbione> well if you are happy with a possible failure, it's ok with me :)
<fabbione> OCFS2 did fail on ia64
<fabbione> up to you
<lamont> this week I'm not overly concerned with a failure, although it would be nice if it just worked,.
<fabbione> how long does it take to build?
<lamont> linux-source-2.6.12:    03:07:47 (12 entries, sigma 01:42:01)
<fabbione> or better.. will you stay awake long enough to see the results?
<lamont> but gcc-4.0 is ahead of it.. :-(
<fabbione> hmm ok
<lamont> last build was just under 7 hours...  we're 4 hours into that
<lamont> so it's more one of I'll be awake to see the results...
<lamont> just upload without worrying about hppa - if it dies, we'll fix it in the next round
<fabbione> i guess you won't last 6 hours :)
<fabbione> ok
<lamont> I plan to be awake again in about 7 hours.
<fabbione> also because i have another set of patches to push pretty soon in .12
<lamont> so, no.  no plans to last 6 hours.
<fabbione> eheheh
<fabbione> ok
<lamont> it occurs to me that doing a test build in hoary probably doesn't really cut it.
<lamont> hence the gcc-4.0 is first
<fabbione> well i am pretty sure i did catch all the dpkg-ar fuckage
* lamont does a mass-giveback on debian/{hppa,ia64}, just because he can
<fabbione> well yeah we can upload 2 kernels in a raw :)
<fabbione> hahha
<lamont> 149 packages
<fabbione> i will soon need to do that on sparc here
<lamont> many of which have been superseded, I expect
<fabbione> i am letting the buildd to do as much as it can out of main
<fabbione> before giving back half of it
<lamont> I abused my local mirror into having source bolted on the side of the archive, so that I could build all of the cxxlibs, modulo missing build-deps.
<lamont> I'd like to get main/cxxapps building this week, will deal with getting a real buildd running sometime after June 1.  :-)
<lamont> May 23 22:27:32 buildd: breezy: total 251 packages to build. :-(
<fabbione> ahha only 251?
<fabbione> i have like 2250 in the queue :)
<lamont> Total 52 package(s) in state Building.
<lamont> Total 44 package(s) in state Dep-Wait.
<lamont> Total 11 package(s) in state Failed.
<lamont> Total 795 package(s) in state Installed.
<lamont> Total 251 package(s) in state Needs-Build.
<lamont> Total 12 package(s) in state Uploaded.
<lamont> Total 1165 package(s)
<lamont> it's not a full mirror
<fabbione> oh that's only main
<fabbione> i figured that banning a few things from auto build is good
<lamont> and doubtlessly has several hoary packages in there - I'm going to need to fetch the w-b output from p.u.c sometime and see what the actual archive is missing, and force that through
<fabbione> and i just build them manually in parallel
<lamont> that's most of main (minus kde), and all of cxxlibs.txt's packages
<fabbione> that's not too bad
* lamont has 2 machines chunking along at it... one that runs at about 20-25% of the other.
<lamont> several of the failed are 'needs hppa love'
<fabbione> isn't T-bone helping with hppa at all?
<lamont> haven't seen t-bone recently
<fabbione> neither did i
<fabbione> i think i have seen only a few packages that needs real sparc love
<zul> for a kernel debug image you would have to fuck around with kernel-package wouldnt you?
<fabbione> zul: why?
<zul> i was just looking at the roadmap agaim
<zul> i was thinking of having a dbg directory in debian/config and something like linux-image-2.6.12-x-dbg-686 or whatever
<fabbione> zul: we will do something like config/i386/686-dbg or 386-dbg
<zul> that works..
<fabbione> it will be a normal flavour with all the possible debugging options turned on
<zul> i was going through the debug options and have a list kind of
<fabbione> we might want to consider to add some kgdb patch to it, or whatever
<zul> yeah 
<zul> lol....i like instruction number 2 http://www.ready.gov/nuclear_visual.html
<fabbione> Service Unavailable
<zul> stupid americans
<zul> except lamont
<zul> for nuclear blast...
<zul> instruction #2...consider if you can get out of the area
<dilinger> yea, stupid americans
<zul> and everyone else...
<lamont> heh
<zul> oh crap im in soo much trouble now :)
<lamont> they write those for the lowest common denominator
<zul> i know but its funny
<lamont> we still chuckle about the instructions on a catch-allive mouse trap we bought a while back...
<lamont> disposal instructions began "go to a place where mice are needed"
<fabbione> ahahahha
<dilinger> lamont: why they'd want to preserve the health of the lowest common denominator, instead of letting nature take its course...
<lamont> yeah
<lamont> dilinger: they want to give him enough confusion to have him outside debating when the wave hits... who said anything about preserving him
<zul> http://zulinux.homelinux.net/readygov_nuclear.pdf
<lamont> well. sleepybye time
<fabbione> night lamont
<fabbione> that stuff is sick
<fabbione> a nuclear explosion done at ground zero can mechanically destroy everything in a few miles radius
<fabbione> without taking into account the heating generated by the explosion that would melt down basically everything
<fabbione> the fallout will do the rest 
<fabbione> this without taking into account the other 2 options of making an underground explosion (more mechanical destruction, less fallout) or in air detonation (less mechanical - much more fallout)
<zul> of course you have this all planned out dont you :)
<fabbione> no, but the picture gives the feeling that walking a few yards away from the explosion is enough :)
<zul> if you are a cockroach
<fabbione> also.. everybody had a nuclear radiation shield handy :)
<zul> heh
<fabbione> i always have one in my wallet 
<fabbione> just in case :)
<zul> dont leave home without it :)
<fabbione> DON'T PUT CONDOM IN THE WALLET! they get ruined by the temperature! 
<fabbione> PUT YOUR NUCLEAR RADIATION SHIELD INSTEAD!
<zul> heh
<fabbione> it's done in pure anti scratch metal
<zul> my nuclear condom for those special occasions
<fabbione> i found this super hot girl.. almost radioactive...
<zul> heh...i think im going to bed....night dude...i expect kernel built by the time i get up :)
<fabbione> good night
<fabbione> i am going to upload 1.2 today
<zul> pl
<fabbione> we need OCFS2 out for testing
<zul> ok even
<fabbione> hey JaneW 
<fabbione> JaneW: i was just waiting for you :)
<fabbione> we need a release name :)
<JaneW> hi fabbione 
<JaneW> cool
<JaneW> brb
<fabbione> ok
<JaneW> fabbione: Merry Macadamia
<JaneW> ?
<fabbione> works for me :)
<fabbione> done :)
* fabbione does some baz dance
<mjg59> fabbione: Does this one have the acpi crack, or is that next time around?
<fabbione> next round...
<fabbione> i am already merging them
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,3--2.6.11.92
<fabbione> mjg59: i had to take this kernel out ASAP
<fabbione> because i need tests on OCFS2
<mjg59> Sure, that's no problem
<fabbione> and the new version of GFS
<fabbione> me .. must .. find .. time .. package .. userland
<mjg59> Hahaha
<fabbione> the GFS userland is a royal mess
<fabbione> the main issue is that there is part of it already packaged
<fabbione> but kernel and userland need to be in sync
<fabbione> that makes the other set of packages useless
<fabbione> HOLY JESUS!
<fabbione> the acpi patch is HUGE
<mjg59> Yes
<fabbione> when you created the diffs, where they on top of what patch set?
<mjg59> The version in the archive rather than the baz one, I think
<fabbione> ok, did you apply them as last?
<fabbione> or first?
<mjg59> Yes
<mjg59> Last
<fabbione> ok
<fabbione> they both come from the bk acpi tree.. so i can mark them as "external"
<mjg59> The second one isn't from the bk acpi tree yet
<mjg59> It's from the mailing list
<fabbione> ah ok
<fabbione> well i can still mark it as external
<mjg59> I need to hack on it a bit more and submit it for that (need to get the _GTF method supported)
<fabbione> hmm ok
<mjg59> It makes several more machines work at the moment
<fabbione> and how many are going to break?
<mjg59> Haha
<mjg59> It hasn't broken any of the ones I have access to
<fabbione> i start to wonder how many laptops do you have...
<mjg59> 6 with Ubuntu
<fabbione> my best guess is that you have one even in front of the toilet seat
<chmj> morning 
<fabbione> hi chmj 
<mjg59> And another one running the ubuntu kernel
<chmj> thats a lot of laptops mjg59 
<mjg59> chmj: Yup
<mjg59> I tend to collect them...
<Mithrandir> chmj: he's going to build a house of out them when he has enough.
<chmj> Mithrandir: I'd love to see that 
* mjg59 is expecting rather a lot more in the next month or so...
<fabbione> ehhe
<fabbione> Mithrandir: ipw2200 1.0.4 is in
<fabbione> i just uploaded the kernel
<Mithrandir> chmj: either that, or he needs a new house for all the laptops.
<Mithrandir> fabbione: rock on.
<mjg59> fabbione: I need to feed you SATA suspend/resume support at some point
<fabbione> it will take a bit before it's on the mirror
<Mithrandir> fabbione: universe for now?
<chmj> mjg59: do you have any x40's ?
<mjg59> Mithrandir: Odd you should say that...
<mjg59> chmj: Only the one. I'm keeping it.
<fabbione> mjg59: ok
<fabbione> Mithrandir: yes
<mjg59> fabbione: Currently SATA machines will entirely fail
<fabbione> Mithrandir: the next one will go to main
<Mithrandir> fabbione: *bounce*
<Mithrandir> :)
<fabbione> mjg59: SATA is a mess
<chmj> mjg59: aah man, I trying to save for one of those, wish I had one :/
<fabbione> Mithrandir: i had no time to give the kernel some d-i love
<fabbione> given that we can push to main and start swithing to it
<infinity> I heard that mjg59 was joing to mail me a T42, so I don't have to order one from IBM^WLenovo
<infinity> s/joing/going/
<infinity> So, uhh...
<infinity> mjg59 : Thanks!
<fabbione> mjg59: bah 1.2 is FTBFS because dPATCH sucks
<fabbione> i might as well get your patches in
<fabbione> now i understand why it was asking about some options I was sure i did pre-configure
<chmj> fabbione: what was the decision, if any, on dpatch's removal ?
<fabbione> chmj: yeah hopefully soon
<chmj> fabbione: cdbs and I are mortal enemies though 
<fabbione> chmj: i think i am going to add some sanity checks at build time
<fabbione> like lsdiff -H * |grep debian
<fabbione> mjg59: your crack is FTBFS on ia64
<fabbione> (at least..)
<fabbione> the others are still building
<mjg59> fabbione: Oh, cock. Hang on.
<fabbione> mjg59:
<mjg59> fabbione: In drivers/char/agp/hp-agp.c?
<fabbione> In file included from drivers/firmware/pcdp.c:18:
<fabbione> drivers/firmware/pcdp.h:48: error: field `addr' has incomplete type
<fabbione> drivers/firmware/pcdp.c: In function `setup_serial_console':
<fabbione> drivers/firmware/pcdp.c:27: error: `ACPI_ADR_SPACE_SYSTEM_MEMORY' undeclared (first use in this function)
<fabbione> drivers/firmware/pcdp.c:27: error: (Each undeclared identifier is reported only once
<fabbione> drivers/firmware/pcdp.c:27: error: for each function it appears in.)
<mjg59> Waah
<fabbione> mjg59: ok.. no panic.. i will upload 1.3 without the patches
<mjg59> Damnit. Ok, I'll take a look
<fabbione> so we can workout them properly
<fabbione> well if it's not too much work i can wait
<fabbione> the others need to build anyway
* mjg59 had tested x86
<fabbione> yeah i am building amd64 and ppc too
<fabbione> it's probably a missing include or something
<fabbione> it should be simple to fix
<mjg59> Yeah, it's a missing acpi include
<mjg59> Goddamnit. You'd think Intel would actually test on their own hardware.
<mjg59>         struct acpi_generic_address     addr;
<fabbione> include/acpi/actypes.h:#define ACPI_ADR_SPACE_SYSTEM_MEMORY    (acpi_adr_space_type) 0
<fabbione> let see if that helps :)
<fabbione> In file included from drivers/firmware/pcdp.c:15:
<fabbione> include/acpi/actypes.h:95:2: #error ACPI_MACHINE_WIDTH not defined
<fabbione> include/acpi/actypes.h:203:2: #error unknown ACPI_MACHINE_WIDTH
<fabbione> no it doesn't
<mjg59> fabbione: Try just including acpi.h
<mjg59> Uh, acpi/acpi.h
<fabbione> #include <linux/acpi.h>
<fabbione> including....
<mjg59> Ooh, handy, Jeff's just posted a new libata suspend/resume
<mjg59> Ok, yeah, linux/acpi.h should do
<fabbione> oh there
<fabbione> it builded
<mjg59> Hurrah
<mjg59> It's possible that there'll be another couple of them
<fabbione> hmmm
<fabbione> the point is.. why did it break on ia64 and not on the others?
<fabbione> will this fix break other stuff?
<mjg59> That's an IA64-only driver
<fabbione> ah ok
<mjg59> It's likely that they've fixed all x86 stuff
<fabbione> no wonder :)
<mjg59> fabbione: And PPC shouldn't have been touched
<mjg59> (with luck)
<fabbione> mjg59: it's building :)
<fabbione> other than the usual random ppc sigkills....
<mjg59> Heh
<svenl> fabbione: why does breezy's make-kpkg tell me the just unpacked 2.6.11-rc4 tree is not a linux toplevel directory ? 
<fabbione> svenl: i have no idea.. works here
<svenl> it tells me a warning about the cramfs patch.
<svenl> fabbione: on pristine upstream 2.6.11-rc4 ? 
<fabbione> svenl: no idea. i don't even have 11rc4 here
<svenl> err, 2.6.12-rc4 obviously.
<svenl> fabbione: should i fill a bug report ? 
<fabbione> svenl: i am not even sure what you are trying to do.. 
<fabbione> can you at least
<fabbione> 1) show me what you are trying to do
<fabbione> 2) how
<fabbione> 3) the full error
<mjg59> svenl: 2.6.*11*-rc4?
<mjg59> Oh, soryy
<svenl> fabbione: i am trying to compile a kernel without cpufreq to track the sleep bug i and benh have been seeing with the latest ubuntu kernel in breezy.
<svenl> fabbione: the bug is : when waking from sleep, the box shuts down.
<svenl> sven@tael:~/kernel/linux-2.6.12-rc4$ make-kpkg --revision 1 --append-to-version -sven kernel-image
<svenl> You should invoke this command from the top level directory of
<svenl> a linux kernel source directory tree, and as far as I can tell,
<svenl> the current directory:
<svenl>         /home/sven/kernel/linux-2.6.12-rc4
<svenl> is not a top level linux kernel source directory.
<svenl>         (If I am wrong then kernel-packages and the linux kernel
<svenl>          are so out sync that you'd better get the latest versions
<svenl>          of the kernel-package package and the Linux sources)
<svenl> Please change directory to wherever linux kernel sources
<svenl> reside and try again.
<svenl> [Bsven@tael:~/kernel/linux-2.6.12-rc4$ ls
<svenl> arch     CREDITS  Documentation  fs       init  kernel  MAINTAINERS  mm   README          scripts   sound
<svenl> COPYING  crypto   drivers        include  ipc   lib     Makefile     net  REPORTING-BUGS  security  usr
<svenl> There.
<fabbione> hold on a sec
<fabbione>   # See if we are running in a linux kernel directory
<fabbione>   if ((!(-d "drivers" && -d "kernel" && -d "fs" && -d "include/linux"))
<fabbione>       && (!(-d "dev" && -d "kern" && -d "fs" && -d "i386/include"))){
<fabbione>     my @other_targets = grep (! m/^modules/, @ARGV);
<fabbione>     if ($#other_targets != -1 || ! -d "include/linux") {
<svenl> i just untarred the 2.6.12-rc4 tarball from ftp.kernel.org, copied the default ubuntu .config, did make oldconfig, disabled cpufreq.
<fabbione> this is the check
<svenl> fabbione: can you test it on your box or something ? 
<svenl> fabbione: what is the :  && (!(-d "dev" && -d "kern" && -d "fs" && -d "i386/include"))){
<svenl> for ? 
<fabbione> it's like bash
<fabbione> if [ -d foo ] 
<svenl> ok.
<svenl> but the first group is indeed kernel sources.
<svenl> the second line is strange.
<fabbione> svenl: i am checking.. give me a sec.
<fabbione> svenl: works here
<infinity> That check has been there for ages, and works fine.
<fabbione> what version of the kernel package do yo heve?
<svenl> strange.
<svenl> whatever was in breezy yesterday.
<svenl> 8.132ubuntu1
<fabbione> get ubuntu2
<fabbione> i uploaded yesterday
<fabbione> and please svenl, be always sure to have the latest stuff.. always :)
<svenl> I don't get the message on sarge.
<fabbione> svenl: you need to upgrade
<svenl> fabbione: one minute.
<svenl> fabbione: are you making fun of me for running breezy ? 
<svenl> fabbione: bah.
<svenl> fabbione: sucks.
<infinity> No, he wasn't, but he probably should. :)
<infinity> I don't run breezy yet, I just break it merrily.
<infinity> And I know I'm not alone. :)
<svenl> infinity: i just got into that mess because i was trying to build the ppc64 biarch toolchain in the first place, to build ppc64 kernels.
<svenl> infinity: i know i need to reinstall.
<svenl> infinity: and it is worse, since i run beta biarch toolchain.
<infinity> fabbione : Oh, the amd64 machine is up and running, BTW, should you need a testing bitch.
<svenl> so, now apt-get is unhappy because i have libgcc 3.4.3-13ubuntu1 :/
<fabbione> infinity: oh yeah... how many boxes do you have around?
<svenl> fabbione: mmm, do i really need a separate cramfs patch, or did it make it upstream.
<fabbione> svenl: the cramfs patch has been there forever.
<infinity> fabbione : Locally, only two.  The amd64 desktop from hell, and the i386 craptop.
<infinity> fabbione : But I do most of my work on a remote PPC machine.
<fabbione> infinity: hmmmmm
<infinity> (And I can get a button bitch to reboot that one if I break it remotely, should that be necessary)
<fabbione> infinity: you could play a bit with OCFS2
<fabbione> even in a single node cluster
<svenl> fabbione: in that case, kernel-package should be patched to know about it maybe :)
<fabbione> http://udu.wiki.ubuntu.com/ClusterFilesystems
<fabbione> svenl: dude... do you know what cramfs is used for?
<svenl> fabbione: sure.
<fabbione> and in any case you can explain that to Manoj
<svenl> fabbione: to read the initrd :)
<fabbione> since he is upstream
<fabbione> and the ubuntu patch is there only to deal with the new dpkg that is NOT in Debian yet
<fabbione> all the other stuff -> Manoj
<fabbione> mjg59: In file included from drivers/char/agp/hp-agp.c:18:
<fabbione> fails too
<fabbione> like you predicted
<svenl> fabbione: ok.
<svenl> BTW, do you have a packaged git already ?
* fabbione shakes Master ACPI mjg59 
<fabbione> svenl: it's in Debian and Ubuntu already
<fabbione> cogito
<fabbione> mjg59: ?????? come on dude...
<fabbione> WAKE UP
<svenl> fabbione: oh. ok.
<svenl> thanks.
<fabbione> include/asm/acpi-ext.h:15: error: parse error before "hp_acpi_csr_space"
<fabbione> mjg59: i assume that acpi-ext.h is totally borked
<mjg59> fabbione: acpi-ext.h should include acpi/actypes.h
<fabbione> yeah it seems to build
* fabbione updates the patch again
<mjg59> Cool
<fabbione> no
<fabbione> that's not enough
<mjg59> Bah
<mjg59> Same failure?
<fabbione> no much smaller
<fabbione> probably it wants acpi/acpi.h
<mjg59> Yeah
<mjg59> Weird, the fix in -mm is just actypes.h
<fabbione> for the asm...
<fabbione> but the driver still fails to build
<mjg59> Hngk.
<mjg59> What's the error?
<fabbione>   CC [M]   drivers/char/agp/hp-agp.o
<fabbione> yeah with acpi/acpi.h goes on
<mjg59> Ok, cool
<fabbione> do you still want the error?
<mjg59> Nah, if it works then that'll do
<fabbione> mjg59: amd64 is go
<mjg59> fabbione: Excellent
<fabbione> mjg59: kernel uploaded
* fabbione does another baz dance
* chmj laffs 
<fabbione> lamont: 1.3 is on the way to the buildd's
<fabbione> you might want to wait to build hppa
<fabbione> i am tagging it now
<lamont> 1.3?  what happened to 1.2?
<fabbione> FTBFS because DPATCH sucks
<fabbione> not bad... 5 minutes into the buildd and 1.3 still didn't fail :)
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,4--2.6.11.92
<fabbione> lamont: can you be so kind to tell me if 1.3 is building around?
<fabbione> so i can finish for now and come back in a few hours?
<lamont> building *4
<mxpxpod> last night I compiled the 2.6.12 kernel from breezy on hoary (powerpc) and ran into some problems with cpu frequency scaling... /sys/drivers/system/cpu/cpu0/cpufreq/scaling_governor is unable to be opened or catted
<mxpxpod> so powernowd won't start up
<mxpxpod> has this been reported?
<fabbione> lamont: thanks
<fabbione> mxpxpod: no and if you can't test it in breezy is pointless
<fabbione> also.. the kernel is in universe = unsupported (yet)
<mxpxpod> suck
<mxpxpod> the sleep code for powerpc laptops in 2.6.12 is tons better than in 2.6.10 and I'd like to use it :(
<fabbione> mxpxpod: sorry but i really don't have time to spend on half backports and stuff. benh knows it is broken
<mxpxpod> fabbione: oh, he does?
<fabbione> yes
<mxpxpod> ok, that's all I needed to hear :)
* fabbione goes off
<fabbione> bbl
<jbailey> fabbione: When you're back - do you have any thoughts on how to handle source drivers that aren't included in the kernel but would presumably need to be bumped with every release?
<jbailey> fabbione: I have someone asking for the spca5xx driver, which upstream doesn't seem to want to try and get into the kernel.  As long as it's not, I can't see us pulling it into main, but I'm curious what something like that would actually take.
<Mithrandir> it's a fairly easy driver.  I'd love to see it in (since I need it for my webcam :)
<zul> jbailey: * Add USB spca5xx driver:
<zul>     - Add patch external-drivers-usb-media_spca5xx.dpatch.
* jbailey blinks
<jbailey> I missed that one, obviously. =)
<zul> i added it in the last upload
<jbailey> Hmm, I guess I havne't updated.  My box is still running 2.6.11.92-1.1
<jbailey> Err, no.  I updated this morning on anothe rbox and still don't see it...
<jbailey> zul: When was the last upload? =)
<zul> gimme a sec
<zul> 12:25 gmt
<zul> according to the breezy-changes list
<zul> 1.3
<jbailey> *lol*
<mjg59> fabbione: New kernel has those patches?
<fabbione> mjg59: yes
<mjg59> fabbione: You rock. Thanks!
<fabbione> mjg59: no problem dude.
<fabbione> amd64 is in :)
<fabbione> nice nice
<Mithrandir> shiny new crack?
<fabbione> Mithrandir: quite a lot
<zul> fabbione: that gcc4 fix didnt make it?
<fabbione> zul: i didn't merge at all from you sorry
<fabbione> i will for the 1.4
<zul> no problem...ill just add a bunch of stuff to 1,4 :)
<zul> whatever happened to t-bone?
<fabbione> he converted to gentoo
<fabbione> and he is probably porting gentoo to ia64 and hppa
* fabbione ducks
<zul> ewww...
<zul> http://www.mirror.co.uk/news/showbiz/tm_objectid=15552841&method=full&siteid=94762&headline=light-sabre-duel-puts-two-in-hospital-name_page.html%5B/url%5D
<zul> excelent... build-686-dbg
<fabbione> nice
<zul> back to poker..
<zul> there doesnt have to be like kernel-headers-dbg does there
<zul> brb need to test the debug kernel
<zul> dang...so close yet so far away
<zul> dbg kernel paniced on me saying it can mount my root partition
<fabbione> amen
<zul> huh?
<fabbione> for your kernel panic
<fabbione> :)
<zul> :P
<dilinger> a penny for your kernel panic?
<zul> dilinger: i turned on all the debug features in a .config for 2.6.12 and it paniced on me...
<zul> bleh
#ubuntu-kernel 2005-06-01
<zul> *shudder* http://backports.ubuntuforums.org/backports/dists/warty-backports/bleeding/binary-i386/
(fabbione/#ubuntu-kernel) morning
<fabbione> bah
<fabbione> meeeeeh!
<fabbione> doko: ????
<fabbione> dh_link -pgcc-3.4 \
<fabbione>   /lib64/libgcc_s.so.1 /usr/lib/gcc/sparc-linux/3.4.4/libgcc_s_64.so
<fabbione>  /lib64/libgcc_s.so.1 /usr/lib/gcc/sparc-linux/3.4.4/64/libgcc_s_64.so
<fabbione>  /bin/bash: /lib64/libgcc_s.so.1: Permission denied
<fabbione> at least this time it did build all of it :)
<fabbione> one step forward :)
<fabbione> well the fix is easy at least :)
<zul> hmmm...initrd says its too big on boot
<zul> ill figure it out tomorrow...
<fabbione> uh?
<fabbione> what kernel?
<zul> 686-dbg
<zul> :)
<fabbione> ah yeah
<fabbione> i think you will need to increase the ram size
<zul> yeah thats what im thinking
<zul> meh...ill do that tomorrow when i get up...im going to bed its 01:28 in the morning
<fabbione> night :)
<zul> ramdisk in the 686-dbg config?
<fabbione> zul: i think more of ramdisk_size in grub
<zul> ah ok..
<fabbione>     Linux 2.6.12-rc5
<fabbione> yay
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,1--2.6.11.93
<fabbione> dilinger: you around?
<fabbione> unping
<chmj> fabbione: ping 
<fabbione> pong
<chmj> the kernel extenal modules watch program will just work like uscan 
<chmj> so its ok to include it in devscripts ?
<thom> chmj: seems kinda pointless since it's only useful for the kernel
<fabbione> chmj: hold on a sec
<fabbione> chmj: put it somewhere first for testing
<thom> i'd throw it in debian/bin tbh
<chmj> thom: separation means we can have a set tool for kernel maintainance, if not yet any 
<chmj> s/tool/tools/
<chmj> s/set/set of/
<fabbione> chmj: i want to test it for a bit before actually include it anywhere sensible
<thom> chmj: but they're useless without the kernel itself, so why seperate them?
<chmj> thom: I meant separating from devscripts, the script is based on devscripts 
<fabbione> chmj: don't worry about separating
<fabbione> let's see how it works first
<fabbione> and perhaps merge it with options later on
<chmj> yes, will have it up soon 
<zul> so sleepy
<fabbione> zul: morning
<fabbione> 12rc5 is already building everywhere
<fabbione> orig/diff/dsc in the usual place
<fabbione> branch as in /t
<zul> rc5 is out already? wohoo..
<fabbione> and i am off for a shower while it builds
<fabbione> re
<fabbione> i386/amd64 are go.. ppc and ia64 still building
<fabbione> lamont: it would be nice if you can build 2.6.11.93-1.1
<fabbione> on hppa
<fabbione> and update the configs
<fabbione> anybody alive?
<zul> not really i have a splitting migraine
<fabbione> die :)
<fabbione> well i have 12rc5 ready
<fabbione> i guess i am going to upload
<zul> man...i just branched as well...bastard
<fabbione> zul: ahaha
<lamont> fabbione: waiting for rc5-pa1 to happen, although -pa0 has potential
<lamont> and is building
#ubuntu-kernel 2005-06-02
<fabbione> lamont: great
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,2--2.6.11.93
<nemesis> hi
<nemesis> spricht jemand deutsch?
<fabbione> nope
<fabbione> #ubuntu-de
<nemesis> is it possible to install a new kernel with apt-get under ubuntu?
<fabbione> yes
<nemesis> i compiled the kernel 2.6.11.9 but when i'm booting, he's searching for many modules, i have not in my notebook. if i install it via apt-get, will apt-get configure the kernel?
<fabbione> ah not that way
<fabbione> but these are #ubuntu channel questions
<fabbione> here we discuss only kernel development
<nemesis> ok
<nemesis> cya
<fabbione> cya
<zul> after puking for much of the day yesterday i feel much better
<fabbione> ouch
<fabbione> so did you like SW3?
<fabbione> i am watching a few bits and pieces of SW Revelation now
<zul> i thought it was ok...
<zul> i thought some of the acting sucked
<fabbione> well sw2 sucked more for acting
<zul> yeah...the big noooooooooo by darth vader at the end of the movie was kind of over done
<fabbione> yeah i agree
<infinity> s/acting/directing/
<fabbione> infinity: no no.. i meant acting
<infinity> Actors don't just wake up one morning saying "I'm going to scream 'nooo' for 5 minutes, and there's nothing Lucas can do about it!"
<fabbione> anakin in sw2 is a luser
<infinity> Yes.  Yes he is.
<fabbione> infinity: well that's true..
<infinity> But I still say the director is crap.  Can't get actors into character, can't keep them there.
<fabbione> but also some actors were terrible
<infinity> And of course, the writing was shit (same guy to blame there too)
<infinity> And then he insisted on editing it himself too.
<infinity> So, y'know.  I blame Lucas for ruining my childhood.
<zul> i blame jar jar for darth vader
<infinity> Quite possible.
<fabbione> ahha
<fabbione> i blame Qui Gon for not freeing anakin's mother
<fabbione> just a little disagreement and zack
<fabbione> the jedi's are gone
<fabbione> and the empire is there
<fabbione> think about it :)
<zul> anakin has smother issues...er...i mean mother issues...
<zul> so you arent doing any more uploads this week?
<fabbione> zul: mostlikely no
<zul> thank god..
<fabbione> sucker
<zul> eat me
<fabbione> zul: be careful.. i might do it :)
<fabbione> roasted zul in barbecue sauce
<zul> heh i dont swing that way..
<chmj> lol 
<fabbione> did you all read kernel-team or should i add the call for a meeting in the topic?
<zul> yeah i saw your email
<zul> june 1st sounds good to me
<chmj> I didn't 
<fabbione> infinity: ?
<chmj> fabbione: kernel-team wiki page ?
<infinity> I'm incapable of reading.
<fabbione> chmj: mailing list?
<infinity> It's part of my charm.
<fabbione> infinity: oh cool.. so if i write here that you suck, your gf is a bitch and *!#!*?!*.. you won't understand...
* fabbione hides
<infinity> I'm also not subscribed, cause I didn't know there was a list until just now. :0
<fabbione> ahha
<zul> luser :)
* infinity subscribes.
<zul> also have you noticed that lucas doesnt like hands or arms?
<infinity> And feet now, too.
<fabbione> zul: true.. they all tend to be removed
<infinity> Just limbs in general.
<fabbione> it's probably true for penis' since Jedi's can fall in love and have sex....
<fabbione> Anakin was born with no father
<fabbione> and problably Luke and Leia just with a "Force" magic touch
<fabbione> since there are no sex scenes in the movie
<zul> they have a big assed chasity belt on them
<fabbione> tsk...
<chmj> I have just subscribed, didn't know there was a list eigther 
<infinity> chmj : THank you for making me look less stupid.
<chmj> no problem 
<fabbione> zul: probably it's the side effect of having the light saber on the belt.. the first time you turn it on by mistake you lose your genitals
<zul> lol
<infinity> fabbione : Oh, and the previous bit about my girlfriend.  COuld be true.
<fabbione> zzzzzz.. zack!
<fabbione> infinity: oh no.. i was really joking..
<fabbione> no offence
<infinity> She wants to go back and see Star Wars again... less than a day after we just saw it.
<fabbione> i don't know her at all :)
<infinity> Cause she's... Y'know... A freak.
<fabbione> infinity: download REvelation for her :)
<fabbione> there are still no good torrents for sw3
<chmj> hmm, I never download movies :/
<infinity> What exactly is SW:R?
<fabbione> infinity: it's a SW episode not done by Lucas
<fabbione> just google for it
<infinity> chmj : You're missing out.  It sure beats paying 28 dollars to get your feet stuck to the floor of a theatre and feel violated by Lucas.
<fabbione> afaik it has been done only by sw funs
<fabbione> meh
<fabbione> fans
<fabbione> chmj: i usually download only the one that i really really like after watching them at the ciname
<fabbione> cinema
<fabbione> and 99% of the time i buy the original DVD
<fabbione> it's just to be able to see a few more times 
<chmj> I buy dvd's also 
<fabbione> SW R costed like 20K USD
<fabbione> 10K of which for the cameras
<infinity> Yeah, 20K that they didn't really have.  And yet, I can't pay them for it.
<infinity> But I have to pay through the nose for rich people to make movies and get richer.
<infinity> Isn't life fair?
<fabbione> no it's not
<fabbione> my wife isn't blonde...
<fabbione> and i am not rich
<fabbione> i don't drive a ferrari
<infinity> Hrm.
<infinity> Well, I have some Coke in the fridge, so life isn't all bad.
<infinity> I think I'll go have some of said Coke, kidnap my girlfriend, and go relax somewhere less computery.
<fabbione> good idea :)
<Mithrandir> infinity: have fun
<infinity> Word.
<chmj> heh 
<zul> brb need to test something
<zul> meh
<zul> i think i need to play some poker bbl
<zul> is xorg for breezy relatively safe now?
<zul> brb
<zul> yay...
<zul> linux-image-2.6.12-1-686-dbg_2.6.11.93-1.2_i386.deb
<fabbione> does it boot?
<zul> going to test with qemu
<fabbione> btw.. did you see that there is a arch/$arch/Kconfig.debug ?
<fabbione> or did you just craft the config files?
<zul> i just did the config files
<fabbione> ok
<zul> but the arch/$arch/Kconfig.debug is next if this doesnt work
<fabbione> i would take a look how .debug is involved
<fabbione> well you might need a combination...
<zul> true
<zul> is it me or is the wiki slow
<fabbione> the latter probably
<jbailey> zul: Re: xorg.
<jbailey> zul: no.
<zul> goody
<fabbione> does it boot?
<zul> havent tried it yet...still doing some stuff with qemu
<fabbione> zul: qemu is a pain :)
<zul> tell me about it
<zul> thats weird modprobe tun...tun: error fetching interface information: Device not found
<zul> blah...ran out of space
<zul> qemu is so much fun!
<zul> Kconfig.debug doesnt look like it has anything useful
<zul> damn it...didnt boot...*sigh* back to the drawing board
<zul> oh btw kdb-v4.4-2.6.12-rc5-common-1
<dilinger> hm
<dilinger> dilinger@jack:~ $ dmesg|grep -i hyper
<dilinger> CPU: Hyper-Threading is disabled
<dilinger> dilinger@jack:~ $ cat /proc/cmdline
<dilinger> root=/dev/hda1 ro ht=on quiet splash
<dilinger> did the security update break ht altogether?
<Mithrandir> yeah, the fix is to disable HT
<Mithrandir> AII
<Mithrandir> AIUI
<dilinger> Mithrandir: the security fix announcement said it could be manually turned on w/ ht=on
<dilinger> https://www.ubuntulinux.org/support/documentation/usn/usn-131-1
<Mithrandir> dilinger: oh, ok.  Unsure then
<dilinger> fabbione: still around?
<zul> someone missed a __setup or something?
<dilinger> what's the BTS dujour these days for ubuntu?
<dilinger> still bugzilla, or malone?
<zul> bugzilla for kernel stuff until someone tells me different
<zul> uh...how big is the kernel image should be 686
<dilinger> does it take a little while for bugzilla to make the bug available to searches after submitting a bug?
<dilinger> or did bugzilla eat my bug report :)
<dilinger> oh, nm, i didn't pick a component
* dilinger <3 bugzilla
<zul> dont see it
<dilinger> of course, there is nothing named "component" on this page
<zul> heh...i take it you arent a big fan
<dilinger> of bugzilla?  why wouldn't i be a fan?  it's so easy to use (no wonder it's #1)
<dilinger> yea, so putting linux-image-2.6.8.1-5-686-smp for the package doesn't work
<dilinger> it tries to autocomplete the package if you type it in
<dilinger> nothing for linux-kernel
<zul> just try linux
<dilinger> ok
<dilinger> heh
<dilinger> i can't actually choose linux
<dilinger> the pulldown closes if i try to scroll down to it
<zul> gah? i just did so for a buyg
<dilinger> if i just type "linux", it keeps the pulldown open
<dilinger> this is retarded
<dilinger> zul: what browser did you use?
<zul> firefox
<zul> 1.0.2
<dilinger> i'm using 0.9.3
<zul> thats weird
<zul> yeah now i can finally reboot this damn thing
<Mithrandir> hm, 2.6.12 fails to load X here.
#ubuntu-kernel 2005-06-03
<zul> wtf?
<zul> 523: error: bp cannot be used in asm here
<zul> *sigh* acerhk is not supported upstream anymore
<zul> fabbione: i dropped the acerhk support in my arch
<fabbione> morning
<fabbione> zul: ah ok
<fabbione> good to know
<zul> im still working on dbg kernel :)
<zul> i think i almost have it
<fabbione> cool
<zul> meh...ramdisk: image too big! (42136KiB/8192KiB)
<zul> yay...its booting now
<fabbione> neat
<zul> and im going to bed...might be back later
<fabbione> sure
<fabbione> good night
<fabbione> btw
<fabbione>  i am not going to touch the kernel for today
<fabbione> probably monday or tuesday
<zul> ok cool..ill add a bunch of stuff probably
* netjoined: irc.freenode.net -> clarke.freenode.net
* netjoined: irc.freenode.net -> clarke.freenode.net
<svenl> fabbione: I believe kernel-package will need some fixes to be able to build ppc64 stuff.
<svenl> fabbione: but i am going the way of using a ppc64 subarch of powerpc in the kernel-package rules, which seems easier for our biarch case.
* netjoined: irc.freenode.net -> clarke.freenode.net
<zul> hola
<jbailey> Heya chuck
<zul> hey jeff how goes?
<zul> hah...http://chealth.canoe.ca/health_news_details.asp?news_id=14647&news_channel_id=0
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> zul: munging some 32/64 bit crap in preparation of ppc64 :)
<zul> cool...i think i might solved my dbg problems
<fabbione> ah cool
<zul> if it works im going to put the config file into my arch but not add the image and headers to the control file. once i have your blessings ill add it to the control file
<fabbione> zul: just add them.. i can strip them later
<zul> okie dokie
<zul> ill add kdb as well if they boot properly as well
<fabbione> kdb?
<zul> kernel debugger
<fabbione> ah ok
<fabbione> wasn't it called kgdb?
<zul> kdb
<zul> kdb-v4.4-2.6.12-rc5-i386-1
<zul> from sgi
<zul> brb
<zul> damn it..cant get it to boot without the ramdisk_size option
<zul> Linux bazil 2.6.12-1-686-dbg #1 Fri May 27 11:20:18 EDT 2005 i686 GNU/Linux
<fabbione> there is nothing you can do about it :)
<fabbione> you need to mangle the ramsize_disk
<zul> yeah i know..
<fabbione> there is a way to do it.. we need to figure out how
<zul> well at least im getting alot of debug messages about my usb key
<zul> whoa...alot ;)
<zul> There we now have a debug enabled kernel with kdb 
#ubuntu-kernel 2005-06-04
<zul> thom: around?
<lamont> linux-source-2.6.12_2.6.11.93-1.1_hppa.changes
<lamont> interesting.
<zul> what did you break now :)
<zul> or...what did i break :)
<lamont> 1.1 is just the 93-1.x version of the hppa patches...
<lamont> so the fact that it built indicates that the patches were orthogonal to the RC changes
<zul> ah
<lamont> yeah -what's interesting is that it _did_ build
<zul> hehe
* lamont grumbles about --m time not being there for iptables, apparently
<fabbione> morning
<Mithrandir> fabbione: 2.6.12-whatever's-in-universe makes X not load for me.  It seems to boot fine apart from the fact that X doesn't work (and locks up the system)
<Mithrandir> amd64, radeon 9200
<fabbione> Mithrandir: do you get anything in the logs?
<Mithrandir> haven't really looked yet, just wondered if you knew about it.
<fabbione> like from dmesg?
<fabbione> no i don't.... works fine here :/
<Mithrandir> I'll see if I can get something off the system, then
<fabbione> Mithrandir: that would be great.. can you also try to disable DRI?
<Mithrandir> sure, I'll try.
<fabbione> that's the only X <-> kernel interaction
<fabbione> that i know can cause troubles
* #ubuntu-kernel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
<lamont> fabbione: Uploading via ftp linux-source-2.6.12_2.6.11.93-1.1_hppa.changes: done.
#ubuntu-kernel 2005-06-05
<fabbione> morning
<fabbione> lamont: whoo
<mx|gone> fabbione: have there been any reports of problems with 2.6.12 and wlan-ng/prism2?
<mx|gone> using the ubuntu patch for wlan-ng on -rc4 and -rc5 (and also the -rc4 images from ubuntu) when I plug in my usb adapter, ifconfig freezes when run
<fabbione> mx|gone: i heard somebody talking about it but no idea
<fabbione> the driver is the latest from upstream
<mx|gone> hrmm
<mx|gone> ok, at least I'm not the only one :)
<mx|gone> you guys should also check out benh's latest patches for cpufreq on ppc from the linuxppc-dev mailing list
<mx|gone> they update the cpufreq table to work with cpufreq from -rc5
<fabbione> we already have it
<fabbione> he pushed the patches to us before upstream
<mx|gone> ok
<mx|gone> I didn't see them in the latest linux-source-2.6.12
<fabbione> mx|gone: dude. i can't upload the kernel once a day for a patch
<fabbione> i have to queue up things
<mx|gone> ah, gotcha... my bad
<fabbione> and it's not in the archive yet
<mx|gone> sorry, not trying to give you a hard time
<fabbione> it's not hard... it's just not possible to upload a kernel for every patch we get
<fabbione> we need to batch
<mx|gone> right, I understand
<fabbione> and if i say we have it and it's not in the archive, it will be the next release
<fabbione> or soon
<mx|gone> fabbione: one more question and I'll leave you be... have you heard anything about problems with pbbuttonsd and 2.6.12?
<fabbione> nope
<fabbione> but take into account that .12 is not .12 final
<fabbione> so there are glitches and bugs
<fabbione> it's 12rc5 atm
<fabbione> so it's a bit early to get worried about little details
<mx|gone> right, I realize that :)
<mx|gone> I'm just seeing if anyone else sees what I see
<mx|gone> fabbione: btw, I think the ubuntu-kernel team does a great job
<fabbione> mx|gone: clearly the best place to ask is either #ubuntu or ubuntu-user mailing list
<fabbione> i don't get to see all irc logs for everybody
<fabbione> and i much rather prefer to have a detailed bug report on bugzilla
<fabbione> than on irc
<fabbione> simply because i am not always around
<mx|gone> right
<mx|gone> ok, time for bed for me :)
<fabbione> night
<jbailey> fabbione: gcc-3.4 seems to work now for a ppc64 biarch setup.  Your turn! =)
<mjg59> fabbione: Removable IDE is still broken - there was a discussion about this on lkml recently, I'll try to dig it out
<mjg59> The issue is that ide_unregister is being called twice
<mjg59> fabbione: Also, could you apply the patch from http://article.gmane.org/gmane.linux.acpi.devel/12863/match=hotkey ?
<mjg59> (Sorry, no kernel tree here...)
<zul> hey
<fabbione> jbailey: yup... tuesday or wend, i will start working on them
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> mjg59: i think i can.. we need to check what applies where, becuase i saw a big set of acpi patches going upstream right today
<fabbione> zul: not too bad.. i just broke my back to carry my 2 m68k back home
<mjg59> fabbione: Cool, thanks
<zul> nifty have you heard of using a cart
<fabbione> mjg59: does need to go on top of the other? or replace it?
<mjg59> Needs to go on top of the acpi-bk patch
<fabbione> mjg59: ok, but it replace the ide sleep or is on top of that?
<mjg59> No, it's entirely unreated to that
<fabbione> oh ok
<mjg59> This just unbreaks the hotkey drivers
<fabbione> mjg59: ok.. do we need to enable the option you told me to put =n ?
<mjg59> You might as well, but make it m
<fabbione> yeah.. i don't compile anything in that can be modular
<zul> hmmm...it seems that i compiled a kernel with gcc4
<fabbione> zul: it compiles...
<fabbione> but it's miscompiled...
<zul> ok..
<fabbione> so it might not really work as it should
<fabbione> at least that's the last i heard from the toolchain guys
<zul> hmmm..
<zul> well when i was compiling there was asome assembler errors i think
<fabbione> an error would cause a failure
<zul> or warnings dont remember which
<zul> http://lkml.org/lkml/2005/5/26/11/index.html
<zul> hmmm...lets see what i can do with lkcd
<jwwwb> ahoy
<jwwwb> whatever is presently in linux-source-2.6.12 doesn't build on i386
<jwwwb> first it complains about the abiname, then it doesn't find the patchlist (00list)
<mx|gone> how do you guys generate the wlan/prism2 patch?
<zul> grabbed the latest from wlan-ng and created a patch why?
<mx|gone> zul: I was going to try making a patch of the devel stuff to see if it solves some of the problems I've been having with 2.6.12
<mx|gone> but I'm not sure if you guys have a script or not
<zul> okie dokie
<mx|gone> since it looks like a ton of work
<zul> it wasnt that hard to do
<mx|gone> really?
<zul> really..
<mx|gone> hmm
<mx|gone> thanks zul 
<mx|gone> zul: how did you do the p80211metadef.h?
#ubuntu-kernel 2006-05-29
<TheMuso> c
<TheMuso> /c/
<[g2] > mjg59 I'm seeing > 500Mbs throughput via ttcp on a single core from memory with dapper's i386 kernel
<[g2] > however, the sata notebook drive performance appears absymal 1.5MBs
<desrt> BenC; hi
<zul> heyloo
<zul> BenC: hoary is a pain in the ass, i wish i didnt have so many typos
<morgs> Any chance we can get bug 43961 looked at?
<morgs> Malone bug 43961 in linux-source-2.6.15 "Power down after shutdown does not work..." [Major,Confirmed]  http://launchpad.net/bugs/43961
<infinity> morgs: In 3 days?  It seems unlikely.
<infinity> morgs: I think all the kernel bugs we have now are the ones we're shipping dapper with.
<morgs> infinity: Thanks. Oh well... breezy was worse...
<morgs> on my laptop that is...
<BenC> zul: hehe
<zul> *sigh* i need a faster computer
<BenC> zul: do you have ccache setup?
<zul> BenC: yep
<zul> first thing i did i only have a p4 2.4 GHZ
<BenC> ah, yeah, i386 build can be paintful there
<zul> exactly...
<Mithrandir> BenC: have you given any thought to merging xen for eft?
<zul> everything is so much better with a 20 inch wide screen monitor
<tuxmaniac> heh
<tuxmaniac> zul: You have to monitors?
<zul> no just one
<BenC> Mithrandir: it's probably going to be something discussed at the distro sprint in june
<BenC> Good thing is, the edgy kernel is all ready for upload, just need to get lrm building with it
<Mithrandir> BenC: 'k.  It'd be really shiny to have, but I guess you know that already. :-)
<BenC> Mithrandir: it's one of those things I hear about atleast every other week :)
<Mithrandir> BenC: well, my turn this week, then.
<infinity> BenC: Give me a full set of i386 header packages for the new kernel (and maybe a -686 binary to test against), and I'll deliver you LRM on a silver platter on June 2nd.
<zul> Mithrandir: i was thinking about it but then i got side tracked
<Mithrandir> zul: that has never happened to me. ;-)
<zul> hehe..
<zul> I blame mr collins 
<fabbione> i blame mr Short
<zul> sssh..
<BenC> infinity: actually, I've built l-r-m against it on amd64
<BenC> infinity: the only thing bad right now is nvidia-legacy and ati drivers are using some functions that are non-existent in the new kernel, so I'm trying to hack them up myself
<infinity> BenC: I can fix the nvidia-legacy thing.  I already know where it needs fixing.
<infinity> BenC: But if you're having fun, carry on.
<zul> heylo
<BenC> infinity: If you define fun as messing with crappy code to support a driver that....who am I kidding, I am having fun :)
#ubuntu-kernel 2006-05-30
<BenC> infinity: ping
<zul> BenC: ping
<BenC> zul: yo
<zul> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=16f47c675fefd8304d86174f6d4beeebdec6539b;hp=2371b2062c2d812468ad62f4fe19d4360e748f41;hb=ee4bb818ae35f68d1f848eae0a7b150a38eb4168;f=net/ipv4/netfilter/ip_tables.c i dont think this one applies since xt_table_info is not in 2.6.10
<BenC> zul: correct, pitti should have already marked that one from before
<BenC> just mark it in your list and note it in your reply
<zul> ok..
<zul> after pulling out my hair ;)
<[g2] > it'll grow back :)
<zul> no it wont..
<zul> im already balding
* BenC has long since accepted that he is going bald
<zul> yeah i have already
<BenC> infinity: ping
<BenC> Linux emucade 2.6.17-1-686 #1 SMP PREEMPT Mon May 29 17:15:27 UTC 2006 i686 GNU/Linux
<BenC> Linux phoenix 2.6.17-1-amd64-k8 #1 SMP PREEMPT Wed May 24 15:11:00 UTC 2006 x86_64 GNU/Linux
<BenC> Linux zachery 2.6.17-1-sparc64 #1 Mon May 29 12:45:22 EDT 2006 sparc64 GNU/Linux
<BenC> Linux colorless 2.6.17-1-powerpc #1 Mon May 29 12:49:32 EDT 2006 ppc GNU/Linux
<BenC> 2.6.17 is lookin good
<BenC> lrm building on 386 and amd64 too
<BenC> damn right
<BenC> bcm43xx comes right up with 2.7.17-git, instead of me having to play "iwconfig ap any" games with it
<BenC> 2.6.17
<crimsun> slick
<BenC> infinity: FYI, lrm is building on i386 and amd64 with this new kernel, just had to ditch the fritz pcmcia and pcmcia_cs modules because things changed so much
<[g2] > mjg59 the BT driver with Dapper Beta works wells on the macmini, the 2.0 functionality/EDR doesn't seem enabled out-of-the-box
<[g2] > fye
<[g2] > doh... fyi
<chmj> BenC: ping 
<zul> heylo
<BenC> chmj: pong
<zul> build you bitch build!! ahahah...
* zul runs away with manical laughter
<chmj> BenC: the sky2 patch didn't make it to breezy ?
* chmj looks at zul 
<chmj> s/breezy/dapper/
<BenC> chmj: which patch?
<BenC> I updated sky2 to 2.6.16 source + the irq mask patch
<BenC> that's what's in dapper
<chmj> the large MTU one 
<zul> BenC: im going to start keeping a list of trivial things to fix in the next dapper update
<BenC> zul: good plan
<Keybuk> "next dapper update" ?
<BenC> Keybuk: in a security update we sometimes stick in some trivial fixes like adding PCI id's and stuff
<Keybuk> ah
<zul> like the speedstep stuff 
<fabbione> zul: fix my aironet card on ppc 
<zul> yes my master...
<fabbione> it hangs on "heavy traffic"
<fabbione> good
<fabbione> good
<BenC> fabbione: You have to give him treats so he knows he did a good job
* BenC has a bag of candy corn handy for such things
<fabbione> BenC: i was thinking about carots... 
<zul> beer works
<fabbione> carots will do
<fabbione> ;)
* BenC wonders if this french/english dictionary will even get used
<BenC> wife thought I could use it
<Keybuk> "merge"
<Keybuk> "d'encule de ta mere"
<Keybuk> I actually meant to type "merde" in that first one ... I blame lifeles
<fabbione> ahaha
<BenC> hehe
<fabbione> BenC: does your e3k have cdrom?
<BenC> yeah
<fabbione> BenC: ok, i suggest you start rsyncing the images down for testing
<fabbione> i have only netboot from here
<fabbione> there shouldnt be much of a change
<BenC> ok
<zul> whee...building docs...i probably have another couple of hours though
<BenC> zul: just do debian/rules binary-debs
<BenC> that should be good enough for testing
<BenC> builds debs and udebs
<zul> hmm..
<BenC> PROM NOTICE: Overtemp detected on board 1
<BenC> might be time to shut down the e3k
<fabbione> whoops
<fabbione> FANs going banana?
<BenC> or install a vent van of some kind
<BenC> barn loft heat is getting too much for it
<BenC> brb
<BenC> not sure if this fan will do the trick, but it's worth a shot a guess
<BenC> cool, the fan is keeping my sparc happy enough to idle
<BenC> now to see if it can do any real cpu load without frying :)
<jcole> http://pastebin.com/747180
<jcole> can i still install vmware-player with the modules with that?
<jcole> the problem is "vmware-player" tries to install "vmware-player-kernel-modules-2.6.15-23-386" which i'm afraid to install because i have a custom kernel
<BenC> jcole: you'll need to install the linux-headers packages produced by your kernel build
<BenC> and then rebuild the vmware-player package
<BenC> just like you did with linux-restricted-modules
<jcole> ok
<jcole> where did this vmware player come from btw? there is no .deb on the vmware website
<jcole> see here -> http://www.vmware.com/download/player/
<infinity> it was packaged just for us for now.
<jcole> ah
<jcole> i created a vmwareplayer .deb for us by using alien --scripts to convert the .rpm
<BenC> the name of the .deb isn't really as important as getting the modules compiled against your kernel :)
<jcole> lot's of people troubled with fglrx and nvidia drivers in ubuntu+1
<jcole> i'm sometimes glad my main machine is an intel video chipset
#ubuntu-kernel 2006-05-31
<jcole> how do i tell apt to not prompt with the "Are you sure you want to remove running kernel" message
<infinity> That's not apt, that's the linux-image prerm.
<jcole> damn
<BenC> lamont: ping
<zul> heylo
<zul> wohoo...i get to do a cluser at work
<infinity> Is that a loser without a clue?
<infinity> And is she cute?
<zul> cluster even...need more coffee brb
<lamont> BenC: ack
<BenC> lamont: hey
<BenC> lamont: hppa (with it's binutils bug) is the only arch I don't have booting 2.6.17 now
<BenC> lamont: any ideas who I can talk to, or what I can do to help this along?
<BenC> lamont: is there any way to tell from userspace that a module is affected by this problem?
<BenC> is there a relocation I can look for in objdump output or something?
<lamont> it's the PCREL17 (or whatever it is) reloc that occurs more than 2^16 bytes into the section
<BenC> I don't see any PCREL17, but I do see a lot of PCREL22's
<BenC> which is the one mentioned in the kernel mentioned in the kernel output when it tried to load it
<fabbione> BenC: that's hppa64, right?
<BenC> yeah
<fabbione> yeah you get PCREL17 on 32
<BenC> 00000000000002cc R_PARISC_PCREL22F  printk
<lamont> yeah - more bits on 64-bit, same issue
<lamont> the issue is that the fixup location (thanks to ld -r) is more than 22-signedbits of displacement from the start of the section, and doesn't reach the target.
<lamont> possible workarounds include compiling with long branches instead of stubs for all modules (then they fit, but it runs slower)
<BenC> is that a linker option?
<BenC> and can it be a per module option, or is it something that affects the ABI of the whole kernel?
<fabbione> per module is a suicide
<lamont> it's a compile-time option (not linker), which could be tied to all modules - note that there is a performance penalty for it
<lamont> the other option is to quit using ld -r to link in each and every .o one by one into the module.
<BenC> so this is also caused by the way the kernel is linking and the number of object files?
<lamont> pretty much, yes.
<lamont> the short summary of the bug is that "ld -r creates unlinkable sections because it doesn't keep the sections split, or add fixups as needed to be linkable"
<lamont> if there's an option to ld -r to have it leave each .o in its own section, that'd solve the issue too
<lamont> if gcc creates a section that is too large to link, it switches over to long-branches at the critical point.  ld -r doesn't do that.
<BenC> lamont: can you check "man ld" and see if --unique sounds like what you were talking about?
* lamont mans
<lamont> should do it, and shouldn't be that painful if it's just applied to modules.  /me asks in #parsic
<lamont> BenC: it certainly looks close enough to try a test with it 
<lamont> (mind you, just on the ld -r in modules...)
<BenC> ok, I'm going to add it to LDFLAGS_MODULES and see
<BenC>   hppa64-linux-gnu-ld   -r --unique -o fs/jbd/jbd.o fs/jbd/transaction.o fs/jbd/commit.o fs/jbd/recovery.o fs/jbd/checkpoint.o fs/jbd/revoke.o fs/jbd/journal.o
<BenC> well, that's what I got it to do, so let's see if it does the right thing
* lamont crosses digits
<BenC> going to take 30 minutes to do this full build, I'll keep you posted
* lamont tends to kernel-team moderation tasks... oops
<lamont> Subject:  	I don't want the whole world, just your half
<lamont> there... nothing more than 4 weeks old... sigh
<lamont> fabbione: zul: I might have changed the moderator password for kernel-{teams,bugs} - if so, holler and I'll send you both the new one... (since you're listed as moderators...)
<fabbione> lamont: you can remove me please
<fabbione> i don't bash the kernel enough to handle the lists
<lamont> ok
<lamont> fabbione: fired.
<lamont> er, removed
<lamont> (just from moderation)
<fabbione> lamont: ehhehe
<zul> lamont: i dont think i ever had the password
<zul> yay...dpkg-deb: building package `linux-image-2.6.10-6-k7-smp' in `../linux-image-2.6.10-6-k7-smp_2.6.10-34.18_i386.deb'.
<lamont> zul: that's kinda old...
<lamont> zul: you want the moderation passwd?
<zul> sure...send me any email
<lamont> will do in a bit
<zul> okie dokie
<zul> lamont: yeah i know its old but 34.18 is kind of newish
<lamont> heh
* lamont back in a few
<zul> i have to boot it when i get home tonight
<BenC> you probably wont get much functionality out of it, but as long as it boots, that should be a good test
<zul> im just going to install qemu and get it to boot
<zul> it only built the x86 ones though
<BenC> lamont: I see some changes in the relocation tables (references to new .# sections)
<BenC> but this keeps me from being optimistic
<lamont> sounds promising
<BenC> root@hippo:~# hppa64-linux-gnu-objdump -r /lib/modules/2.6.15-23-hppa64-smp/kernel/fs/ocfs2/ocfs2.ko | grep PCREL | wc -l
<BenC> 3521
<BenC> root@hippo:~# hppa64-linux-gnu-objdump -r /org/ubuntu-2.6/debian/build/build-hppa64-smp/fs/ocfs2/ocfs2.ko | wc -l
<BenC> 21781
<BenC> oops
<BenC> last one should read ~3400
<lamont> having the PCREL22 fixups is fine... having them too far from the start of a section is bad
<BenC> 3400 relocations is still > MAX_GOTS
<BenC> but module.c wont allow a module with > 1023 PCREL's
<lamont> oh... we should fix that. :-)
<lamont> 4095 is still reasonable, no?
<BenC> sure :)
<BenC> I'll see if the relocations even got fixed up right in a minute
<BenC> boot in progress
<BenC> zul: Don't worry about dapper security, I'm working on it now
<zul> ok
<zul> ill worry about the next one
<zul> BenC: for the next dapper security should i just send a patch to you or how is that going to work for git?
<BenC> nah, git tree that I can pull from
<zul> ok
<BenC> or use git to create a patch set that I can pull in with git-applymbox like I do with crimsun's sound stuff
<crimsun> (git-format-patch)
<zul> but ill still be collecting little trival patches as well
<zul> build it, upload it and then push patches to you?
<zul> or something like that
<BenC> dapper is so much easier for CVE's
<BenC> git-cherry-pick is my friend
<zul> yeah i know..hoary is a pain in the ass breezy will be a bit better dapper will be easy (in theory)
<zul> oooo...polygamy is legal in canada now
<zul> well not legal recognized..
<BenC> polygamy?
<BenC> poly gambling?
<zul> polygamy...multiple wives
<BenC> oh
<BenC> it sort of legal in the US if you got them all from another country, but not recognized on taxes and such :)
<zul> its recognized for taxes in canada now..
<BenC> there's a minimart owner near hear that has like 3 wives he brought with him from some mideast country
<BenC> s/hear/here/
<BenC> they never speak, they just take care of the 10 kids running around
<zul> mean, *buntu have certainly raised the bar, so more bugs is pretty much a reflection of that
<zul> oops..
<crimsun> (thanks ;-)
<zul> http://cnews.canoe.ca/CNEWS/Politics/2006/05/31/1608364-sun.html
<zul> crimsun: no probs
<zul> heylo
<zul> BenC: ping
<BenC> zul: polongy
<zul> 34.18 boots
<BenC> swee
<zul> er...2.6.10 yay!
<BenC> t
<zul> the 686 image at least
<zul> ill have to modify my changelog and ill do an upload is there anything else i have to do
#ubuntu-kernel 2006-06-01
<BenC> no upload, send me the .diff.gz and .dsc
<BenC> I need to go over it first
<zul> ok will do
<BenC> dapper CVE's are done
<BenC> so that leaves the badger to butcher
<zul> whee..
<zul> ill get it started tonight
<zul> do you have anything you want me to include in breezy?
<jcole> anyone here know how i can make update-grub force a kernel to be a default, instead of doing an "rm -f /boot/vmlinuz-* /boot/initrd.img-*" beforehand?
<infinity> jcole: head -n 13 /boot/grub/menu.lst
<jcole> infinity: i want to automate it
<infinity> jcole: Set the vmlinuz and initrd.img symlinks.
<jcole> infinity: preseed late command chroots into /target and installs a kernel
<jcole> infinity: i can't automatically remove the "running kernel" since it prompts
<infinity> jcole: sed -i -e 's/do_symlinks = no/do_symlinks = yes/' /etc/kernel-img.conf before you install your kernel.
<jcole> infinity: hmm
<infinity> jcole: Then, IIRC, update-grub should order the images with the symlinked default at the top of the list.
<infinity> (though you should test this theory, don't take my word for it)
<jcole> infinity: that's beautiful!
* jcole cries
<jcole> i'll try that
<jcole> infinity: that's already enabled... maybe i just need to put the symlinks in and rerun?
<infinity> Does it create symlinks in / or /boot, or neither?
<infinity> (on your test system..)
<infinity> (the linux-image postinst is what should be creating them)
<jcole> Found kernel: /boot/vmlinuz
<jcole> wohoo!
<infinity> Yeah, cf this code block in update-grub.
<infinity> if test -f "/boot/vmlinuz" ; then
<infinity>         sortedKernels="/boot/vmlinuz $sortedKernels"
<infinity> fi
<infinity> (Which makes sure it's at the top of the list)
<jcole> AWESOME
<jcole> that worked perfectly
<jcole> thanks infinity
<jcole> man, this will save me some asspain
<jcole> infinity: i noticed that ubuntu has 686 kernel sele
<jcole> duh
<jcole> infinity: what i was trying to say was, how does debian installer find the right kernel for the right arch?
<jcole> ie: 686 ...
<jcole> i would like to use that same logic to install the right kernel... for now, i'm selecting the 386 kernel
<jcole> hmm, i guess i could also just dump the debconf db and see what arch was selected
<jcole> debconf-get-selections --installer | grep base-installer/kernel/which-kernel
<jcole> got it
<zul> BenC: sent
<BenC> zul: thanks
<crimsun> (working on sound/ updates atm)
<lamont> someone remind me how to boot a sparc box from CD....;
<cjb> lamont: boot cdrom?
<lamont> boot: boot cdrom
<lamont> Your imagename `boot' and arguments `cdrom' have either wrong syntax,
<lamont> or describe a label which is not present in silo.conf
<lamont> Type `help' at the boot: prompt if you need it and then try again.
<cjb> That's for the ok prompt, not silo.
<lamont> doh... ok.. how do I get to the ok prompt on a serial console?
* lamont is happily sparc illiterate, you see...
<cjb> Depends how you're talking to the serial console; you send a brk.
<cjb> RET ~# works if you're directly on the serial line.
<lamont> {0} ok boot cdrom
<lamont> Resetting ...
<lamont> danke
<cjb> Cool.
<lamont> or not... things aren't so happy
* lamont considers the possibility of a bad burn
<lamont>  Rebooting with command: boot cdrom                                    
<lamont> Boot device: /pci@8,700000/scsi@6/disk@6,0:f  File and args: 
<lamont> SILO Version 1.4.10
<lamont> Fast Data Access MMU Miss
<lamont> {0} ok 
<dilinger> heh
<dilinger> i remember those
* lamont burns more slowly...
<infinity> I had some sparcs that did that consistently...
<lamont> fabbione: either my CDROM or the server iso is borked.  I'm gonna bet on the first one.
<infinity> The only way to get them to boot from CD was to interrupt the firmware checks early, then boot cdrom.
<cjb> lamont: Or your CDROM drive.  :)
<infinity> For whatever messed up reason, that made it happy.
<lamont> cjb: that's what I said.. :-P
<cjb> lamont: Ah, thought you meant your physical CD.
<lamont> nah - I'd have said 'CD' then. :-)
<lamont> but yeah, it's not 100% clear
* lamont glares at the sparc, wondering why it won't turn on
<lamont> well, powercycling and interrupting early didn't make it happy
<lamont> hrm... the first time I tried installing on that machine, it had the same issue (may 12)
<TheMuso> 
<[g2] > congrats to all on the the dapper release!
<zul> heylo
<zul> BenC: ping
<BenC> zul: pong
<zul> BenC: did you have a look at my diff?
<BenC> nah, went to bed shortly after you sent it
<BenC> getting ready to start looking now
<zul> cool
<zul> dont beat me too hard today ;)
<zul> hey lamont did you send the password yet?
<lamont> zul: doh.  gimmea second
* lamont goes to look up zul's email addr
<zul> zulcss@gmail.com
<lamont> zul: how can you have nothing but a self-sig on your key?
<lamont> sigh
<lamont> ah, you have willy too... nm
<zul> hmm?
<lamont> email sent
<zul> coolio
<lamont> was grumbling about the lack of sigs on your gpg key
<zul> heh
<lamont> anyway, must run.. .gone all day
<zul> toodles
<zul> stupid cadence...*smack* *smack*
<dilinger> mm, dapperness
* dilinger installs
<zul> alright cadence you made my list
<tuxmaniac> zul: what for you use cadence softwre?
<zul> BenC: whats up with my hoary diff?
<BenC> zul: checking it now
<zul> okies
<BenC> zul: Ok, send the changelog to pitti and he'll let you know when/if it's ok to upload
<BenC> everything looks great though, nice work on your first one :)
<zul> thanks..
<zul> whats his email address again?
<BenC> martin.pitt@ubuntu.com
<zul> sent
<BenC> I'm not sure what the hell caused it, but it seems that 2.6.17 is a few orders faster on my i2k than 2.6.15 was
<BenC> it's now finishing 2nd on my kernel builds, out of 6, when it used to finish 5th or 6th
<BenC> only thing faster is sparc, and that's because it has 2 (ia64 has 4) kernels to build, and has 6cpus+6gigs-ram
<cjb> How long does it take for a single kernel?
* cjb takes 40m.  Pain.
<BenC> a lot less than that
<BenC> but I have ccache too
<cjb> Me too.  :/
<BenC> lamont: 2.6.17 is being weird on my ia64
<BenC> it boots fine, except that if I reboot, it hangs when it starts the kernel
<BenC> it will only boot from a cold start
<BenC> oh, wow, that time it came up on reboot
#ubuntu-kernel 2006-06-02
<crimsun> BenC: ping, what's the policy on sound/ changes for dapper? Only bug fixes (i.e., no new pci ids)?
<BenC> crimsun: new pci id's are fine
<crimsun> BenC: ok, thanks. I was going to err on the side of caution and only send fixes
<crimsun> BenC: ping, can you check my logic on a free_irq/iounmap fix for sparc please?
<crimsun> -       if (chip->irq[0] )
<crimsun> -               free_irq(chip->irq[0] , chip);
<crimsun> -
<crimsun>         if (chip->port)
<crimsun>                 sbus_iounmap(chip->port, chip->regs_size);
<crimsun> +       if (chip->irq[0] )
<crimsun> +               free_irq(chip->irq[0] , chip);
<crimsun> +
<crimsun>         if (chip->timer)
<crimsun>                 snd_device_free(chip->card, chip->timer);
<[g2] > hey crimsun 
* [g2]  waves hi
<crimsun> hi [g2]  
<BenC> crimsun: what driver is this?
<BenC> looks good either way, just wondering
<crimsun> BenC: sound/sparc/cs4231.c
<crimsun> BenC: I'm running through sound/* fixing "free_irq() before *iounmap()"
<crimsun> if you need context, @@ -1942,12 +1942,12 @@ void sbus_dma_preallocate(cs4231_t *chip
<crimsun> in any case, thanks for eyeballing it :)
<zul> hey
<ajmitch> hi zul :)
<zul> stalking me arent you?
<ajmitch> of course
<ajmitch> how could I not?
<zul> yeah...
<TheMuso> 
<zul> heylo
<zul> BenC: i started breezy last night but it was too damn hot
* ajmitch stalks zul
<zul> again!
<zul> ill let you be the president of my fan club if you stop it
<ajmitch> alright
<zul> wohoo..
<infinity> Waitaminute. *I* want to be the president of your fan club.
<infinity> And a roadie.
<infinity> And a groupie.
<zul> hehe
<ajmitch> lucky zul
<zul> all of the attention...i dont know what to do
<ajmitch> work harder
<zul> get right on that
* ajmitch is looking at newer ipw2200 with 2.6.17
<ajmitch> except rsync & me don't get on
<zul> uh...talk to BenC 
<ajmitch> I will
<ajmitch> but I need to learn the tools properly :)
<zul> heh...i only do oldish kernels
<ajmitch> I'll probably have some sparc kernel stuff to do for work soon
<infinity> Hrm, how do I switch a git checkout from one branch to another?
<zul> git checkout branch name isnt it?
<ajmitch> afaict, it is
<kimo> Guys, I compiled a vanilla kernel, it boots ok, but can't find my / LVM partition (/boot is not on LVM)? any hint ?
<fabbione> you need an initrd
<kimo> ? I have one 
<fabbione> self-compiled kernel -> no supportt
<kimo> yeah I know ... I am looking for a friendly help :)
<fabbione> there might be 23092039 reasons why it can't find it
<zul> hey fabbione 
<kimo> plus, official kernel wont turn off my laptop which is killing me 
<fabbione> missing drivers, ba d initrd and s on..
<fabbione> hi zul
<fabbione> kimo: it's not really a matter of being friendly or not. It's just too much work to debug a custom.
<fabbione> did you make sure that your kernel support initrd?
<fabbione> that is loading the right one?
<fabbione> etc.
<fabbione> check again the config
<fabbione> are lvm tools installed in the initrd? if so are they executed?
<kimo> fabbione: how do I check ?
<fabbione> manually.. one bit at a time
<kimo> no option for mkinitrd, to include lvm tools ?
<kimo> I used the old .config from ubuntu
<infinity> kimo: Don't use mkinird on kernels >> 2.6.12, use mkinitramfs.
<kimo> infinity: ! wow thnx
<kimo> infinity: any special option for lvm support ?
<infinity> kimo: Better yet, make your kernels with make-kpkg, and it'll all be done magically for you in the kernel's postinst.
<kimo> I used make0kpkg
<infinity> kimo: If you have the lvm tools installed, lvm support "Just Works" in an initramfs.
<kimo> I do have lvm tools & the official kernel does see my lvm partition!
* kimo is very low on battery ... I will come back later guys ..... thankssss
<kimo> any tips before my battery dies ?
<zul> yes try reboot=h to your grub parameters or something like that
<infinity> kimo: Just the above.
<zul> and what infinity said
<kimo> infinity: I do have lvm tools, & used make-pkpkg. I will just try to rebuild mkinitramfs manually 
<infinity> kimo: make-kpkg might require "--initrd" on the command line to add the initramfs magic to the package's postinst.
* infinity doesn't really recall.
<infinity> kimo: But calling mkinitramfs manually should do.
<kimo> ok thanks for everything .... :)
<kimo> I remember debian would drop me on busybox if it cant find / ?
<kimo> is this not in ubuntu 
<infinity> It will, IF you use mkinitramfs.
<infinity> mkinitrd makes something ENTIRELY DIFFERENT.
<infinity> And you don't want it anymore.  Purge initrd-tools.  Make it go away.
<kimo> hmm ... it seems somehow I am using mkinitrd
<kimo> thanks will do that 
<kimo> bye everyone ... thanks for the help
<zul> BenC: is there gonig to be an update to sky2 for updates?
<BenC> latest sky2 doesn't fix the problems, so not likely
<zul> okie dokie ill keep a watch on it
<BenC> hmm...it might actually now that I look at the diff
<cjb> infinity: Hm.  Do you know what the deal with Fedora is?  I remember they use mkinitrd.
<cjb> (But I don't remember whether it actually makes an initramfs.)
<BenC> 2.6.17-git sky2 compiles on dapper, so what the heck
<BenC> 45k diff, so hopefully something in there fixes out problems
<BenC> s/out/our/
* BenC will be away, out in the barn
<zul> mmm...barn
<Snake> Hi guys, I know this isnt a support channel, but no one in #ubuntu seems to have an answer, and I would really like to run dapper on this server. It installs fine, but when I reboot it gets to where it says "Uncompressing Linux..... Ok, booting kernel" and freezes :(. Please help..
<Snake> I've reinstalled twice, without results
<Snake> (thats using the Ubuntu Install CD, not the desktop)
<crimsun> BenC: sorry, my logic was reversed yesterday. free_irq() needs to be called before *iounmap().
<BenC> crimsun: Yeah, makes more sense now that I think about it too
<BenC> otherwise there's a race where the irq handler can work on unmapped io
<Snake> Hi guys, I know this isnt a support channel, but no one in #ubuntu seems to have an answer, and I would really like to run dapper on this server. It installs fine, but when I reboot it gets to where it says "Uncompressing Linux..... Ok, booting kernel" and freezes :(. Please help..
<BenC> Snake: so the installer boots, but grub doesn't get to the kernel?
<BenC> Snake: Try removing the "quiet splash" options from the boot command line ('e' to edit the command line in grub)
<BenC> see if you get any more output to work from
<Snake> BenC: okay one second
<Snake> ah crap
* Snake is in the middle of a repartition
<Snake> and its not goin well at all
<Snake> Freezing it seems as well :(
#ubuntu-kernel 2006-06-03
<AnAnt> I am recompiling the kernel is that I am applying a patch for MMC v4 device support , if that works, shall I upload the new source/patch somewhere in MOTU or so ?
<ivoks> no, MOTU doesn't have anything to do with kernel
<ivoks> you should make your patch available somewhere and make a notice on kernel-devel or here...
<AnAnt> btw, it's not my patch, it already exists in 2.6.16
<ajmitch> then it'll be in 2.6.17, which will be in edgy
<AnAnt> ok
<AnAnt> you don't add features to dapper, right ? just security fixes
<ajmitch> correct
<ajmitch> security & critical bug fixes
<AnAnt> can I get the 2.6.17 from dapper-backports when u guys start working on edgy ?
<ajmitch> no, backporting the kernel would be quite a maintenance hassle
<ajmitch> as far as I know, there are no plans to do that
<AnAnt> k
<kimo> Hey, ubuntu official kernel has ipw2200 ver 1.1, which is newer than the one in 2.6.16 ?? (does this make sense) ?
<AnAnt> oh btw, why are there additions in kernel 2.6.15 (by Ubuntu) that aren't in 2.6.16 ? don't the kernel guys trust it ?
<kimo> :)
<kimo> any idea when are we getting a kernel update for dapper 
<kimo> it still doesnt poweroff my laptop :)
<AnAnt> help I get this error when compiling the kernel source: "Error in source file, line 35" , I get this from drivers/usb/net/zd1211/zddevlist.h
<tuxmaniac> Has there been any success stories with BroadCom 4318 802.11 Card?
<alex_joni> hello, I get an error during make-kpkg on a linux-source-2.6.15 (compiler & helper programs from apt-get build-dep linux-source-2.6.15) : Error(/usr/src/linux-source-2.6.15//kernel/printk.c:516): cannot understand prototype: 'ipipe_spinlock_t __ipipe_printk_lock = IPIPE_SPIN_LOCK_UNLOCKED; '
<alex_joni> ok, found the problem (RTAI patch altered the comment inside kernel/printk.c)
<crimsun> ah, I didn't read that you patched it
<crimsun> (this connection is completely buggered)
<alex_joni> crimsun: sorry, might have not been very clear on that :)
<alex_joni> I see the dafault compiler is gcc 4.0, I used to use 3.x for kernel builds.. is the 4.0 ok?
<crimsun> I can't speak for RTAI, but 4.0 is fine in dapper, yes
<alex_joni> ok, thanks
<crimsun> or whichever parts of 4.0.3 are used
<mkrufky> BenC: yt?  I am reading bug # 33096 ... This is a result of your commit: 30fbd96c515f7ad612486dbd94099b0a461e406a ... Your commit message references an UbuntuBug 5773, but I am unable to locate that...  Anyhow, It looks to me as if your changeset is wrong.... If you can somehow confirm bug #5773 (missing on launchpad.net) , then I would be happy to fix this in upstream
<BenC> 5773 is probably a bugzilla bug
<mkrufky> ah, i'll take a look
<mkrufky> not on bugzilla.kernel.org
<mjg59> bugzilla.ubuntu.com
<BenC> bugzilla.ubuntu.com
<mkrufky> lol , silly me
<alex_joni> any of you uses ccache when compiling new kernels?
<mkrufky> ok, i see 5773, and this looks reasonable to me
<mkrufky> one strange thing is that a message dated "2005-08-23" says "This bug has been fixed a long while ago, but for some reasons we forgot to close it." .... but the -git commit is dated "12 Dec 2005"
<mkrufky> anyhow, I'll fix this in upstream for 2.6.18 , and i'll note it on the launchpad.net bug
<zul> meh...stupid typos
<alex_joni> any idea what : drivers/built-in.o: In function `imacfb_probe':imacfb.c:(.init.text+0xc91): undefined reference to `efi' means?
<mjg59> It means you're trying to build a kernel without efi support?
<alex_joni> mjg59: there should be a CONFIG_EFI or similar?
<mjg59> Yes
<zul> mmmm...champisonhip manager
<alex_joni> mjg59: I started with a .config from a 2.6.12, and used make oldconfig.. is that bad?
<mjg59> Yes. Just enable EFI.
<alex_joni> ok, thanks
<alex_joni> anyone knows where the bootsplash is in ubuntu?
<alex_joni> I built a new kernel, which boots alright, but it stay black during the bootphase
<crimsun> that's usplash, which is userspace
<crimsun> bootsplash isn't in the kernel at all
<alex_joni> err, sorry.. that's what I meant.. is there a special .config entry I need to take care of (FB or defaultresolution or something like that?)
<ajmitch> morning crimsun 
<crimsun> 'morning ajmitch 
<alex_joni> crimsun: the stock 2.6.15 works as it should, just my fresh built kernel doesn't
<crimsun> alex_joni: there are a number of CONFIG_FB{,_*} enabled as 'y', yes
<infinity> We build all the FB stuff modular, actually, but having it builtin would work just as well.
<alex_joni> crimsun: checked them (they are similar to the ones in the stock config )
<alex_joni> most of them 'm' some 'y'
<infinity> alex_joni: You need (at this point) either vga16fb or vesafb to make usplash happy.
<alex_joni> I just diffed my config against the stock one, and I only added one line (related to RTAI), the rest is the same
<infinity> vesafb will only work if you're booting with vga=XXX on the command line, otherwise you want vga16fb (which is what we default to)
<crimsun> alex_joni: did you regenerate the initramfs?
<alex_joni> crimsun: I used make-kpkg to make a new kernel deb and installed that. is that enough?
<infinity> CONFIG_FB_VGA16=m
<infinity> CONFIG_FB_VESA=m
<ajmitch> heh, morning infinity 
<alex_joni> infinity: both set
<crimsun> alex_joni: infinity knows this area better than I do. Did you use --initrd ?
<alex_joni> yes
<alex_joni> make-kpkg --initrd --revision=aj1 --stem=linux binary-arch
<crimsun> I believe you need to exec update-initramfs, then
<infinity> crimsun: make-kpkg SHOULD be popping the update-initramfs call in the kernel postinst.
<infinity> Unless we messed that up for custom kernels, and we're only doing it on stock builds.... Which would suck.
<infinity> And would warrant an upload to -updates, IMO.
<alex_joni> infinity: any way to check?
<crimsun> grep initramfs /var/lib/dpkg/info/linux-image-$(uname -r).postinst
<infinity> grep update-initramfs /var/lib/dpkg/info/linux-image-2.6.15-23-686.postinst
<infinity> (replacing with your package name)
<infinity> Which, if you didn't use --stem=linux, is probably "kernel-image-$foo"
<alex_joni> I did use --stem=linux
<infinity> Kay, then linux-image-$foo. :)
<alex_joni> it says: "my $update_initramfs = "/usr/sbin/update-initramfs";"
<alex_joni> so I guess it does get called
<infinity> Should do, yes.
<infinity> You're booting with "splash" on the command line>
<infinity> s/>/?/
<alex_joni> yes
<alex_joni> same grub/menu.lst entry as for the stock 2.6.15-23-386
<infinity> Can you toss me your .config?
<alex_joni> infinity: sure
<infinity> This may be easier to debug if I just see it in action.
<infinity> Or, alternately, toss me your kernel packages.
<alex_joni> http://www.robcon.ro/config-2.6.15-magma
<infinity> I trust that you won't trojan then in the next 5 seconds.
<infinity> s/then/them/
<alex_joni> it might take me more than 5 seconds to upload them ;) hang on
<infinity> Yeah, I see no obvious reason why this config should hate you.
<infinity> update-initramfs -u -k 2.6.15-magma
<infinity> That should regenerate the initramfs (again)
<infinity> But I'm curious about why it's breaking in the first place, so a copy of your package might be nice.
<alex_joni> they are on their way.. 
<alex_joni> http://dsplabs.cs.upt.ro/~juve/tempdebs/ - but it will be a short while till they make it all there
<alex_joni> infinity: need the source too? 
<infinity> Nah.
<alex_joni> doc is finished,  headers & image next
<zul> brb...new kernel
<alex_joni> infinity: done, they are there
<infinity> .ro ... You're not some l33t Romanian script kiddie trying to eat my computer, right? :)
<alex_joni> infinity: I surely hope not ;)
<infinity> (Why are there so many script kiddies in .ro?  I've not yet figured this out)
<alex_joni> neither have I.. too much spare time?
<infinity> Could be.  Someone needs to get them all involved in constructive hacking.
<infinity> Or, show them the outside world.  Wichever.
<alex_joni> I tried.. but failed :)
<infinity> "Look, there's sun and grass and stuff out there!"
<alex_joni> I think option #2 is more appropriate.. (except that right now it's raining cats & dogs)
<infinity> I rather like cats, but I suppose at high velocity they may be painful.
<alex_joni> it does help that they land on their feet each time..
<infinity> Not when that means claws on your head.
<alex_joni> actually I think they extend their claws only afterwards.. on first impact they should be retracted :D
<infinity> Okay, your kernel image is installed.
<infinity> Time to reboot and get my machine hX0red. :)
<alex_joni> infinity: btw, thanks for looking at this..
<alex_joni> mjg59: still around? I seem to have run again into a problem with efi..
<infinity> alex_joni: Okay, that was informative.  Spotted the difference.
<alex_joni> infinity: what is it?
<infinity> From our package build scripts:
<infinity> if [ -f kernel/drivers/video/vesafb.ko ] ; then
<infinity>         ln kernel/drivers/video/vesafb.ko initrd
<infinity> fi
<infinity> make-kpkg doesn't do that.
<alex_joni> oh, I see
<infinity> And initramfs-tools is specificall sanning the initrd directory to see if you have framebuffers there you want to include.
<infinity> Err, with the mkdir even:
<infinity> mkdir initrd
<infinity> if [ -f kernel/drivers/video/vesafb.ko ] ; then
<infinity>         ln kernel/drivers/video/vesafb.ko initrd
<infinity> fi
<alex_joni> ok, so what do you advice?
<infinity> There.  So, you can just do that by hand in /lib/modules/$(uname -r) and regenerate your initramfs, and you'll be golden.
<infinity> Or, stop using vga=XXX on your command line, cause vga16fb will work fine with your kernel.
<alex_joni> infinity: I need to produce debs that will be distributed
<infinity> We should probably fix make-kpkg to do the initrd/ thing for custom kernels, but that's not going to happen in dapper.
<alex_joni> hmm, afaik this worked in breezy
<infinity> Did you ever actually test with "vga=XXX" in  breezy?
<infinity> Without it, this would be working fine.
<alex_joni> but I don't have vga=XXX.. do I?
<infinity> You almost certainly do.
<infinity> Otherwise, you'd not be seeing the black screen.
<alex_joni> any idea where the vga=XXX could come from?
<infinity> cat /proc/cmdline
<infinity> Mine, for example:
<infinity> root=/dev/sda3 ro quiet splash vga=0x343
<infinity> That last bit says "use vesafb, or give me a useless black screen if it's not available!"
<alex_joni> root=/dev/hdb9 ro quiet splash
<infinity> And it's not available, cause initramfs-tools isn't copying it into the initramfs.
<infinity> Okay, that's bizarre...
<alex_joni> no vga here.. :-/
<infinity> Let me reboot again, but I'm pretty sure your kernel should worh with vga16fb...
<alex_joni> another topic, when I remove ACPI support (because RTAI conflicts with it), I get build errors... any ideea about something like this?
<infinity> Oh, I am so awesome, it hurts. ?/
<alex_joni> infinity: don't tell me you nailed it?
<infinity> alex_joni: Because initramfs-tools isn't finding any framebuffers in /initrd/, it's not loading fbcon.
<infinity> No fbcon, no usplash.
<infinity> And yes, this behaviour has changed since breezy, since I'm an idiot.
<infinity> Sort of.
<alex_joni> ok.. so basicly a make-kpkg bug?
<infinity> Well, a me bug.
<alex_joni> infinity: happens to all of us ;)
* alex_joni produces a reasonable number of bugs frequently..
<alex_joni> usually on this: http://www.linuxcnc.org/
<infinity> Now, the trick to fix this in your custom images is to do the following:
<infinity> Take the snippet I pasted above, and stick it in a shell script called "post-install"
<infinity> And then cp post-install your-linux-source-tree/debian/post-install before you do the make-kpkg thing.
<alex_joni> oh, ok
<alex_joni> trying now
<infinity> Give or take.
<infinity> This is untested. :)
<infinity> You probably want this before it:
<infinity> cd "$IMAGE_TOP/lib/modules/$version"
<alex_joni> do I make it a proper shell script? #!/bin/sh on top?
<infinity> If "dpkg-deb -c blah.deb" shows a /lib/modules/`$uname -r`/initrd directory with vesafb.ko in it when you're done, you win.
<infinity> alex_joni: Yes, a proper shell script.
<infinity> Exectuable, too. :)
<alex_joni> done
<alex_joni> now if I could only make it build :(
<infinity> It gets called by make-kpkg after installing all the junk in the image directory, but before generating the .deb
<infinity> Our Ubuntu post-install is a bit more involved, but that's one of the things it does.
<alex_joni> ok, thanks for the fix 
<alex_joni> any idea about how to make it compile with ACPI unset?
<infinity> That, I have no idea about.
<infinity> Or, rather, I can't beging to have a clue given your "I get build errors" synopsis above.
<alex_joni> I can post a better error message
<alex_joni> arch/i386/kernel/built-in.o: In function `setup_arch': undefined reference to `check_acpi_pci'
<alex_joni> drivers/built-in.o: In function `imacfb_probe':imacfb.c:(.init.text+0x1039): undefined reference to `efi'
<infinity> That first one definitely shouldn't be happening...
<alex_joni> I see it still is included by a #define CONFIG_X86_IO_APIC
<infinity> #ifdef CONFIG_X86_IO_APIC
<infinity>         check_acpi_pci();       /* Checks more than just ACPI actually */
<infinity> #endif
<infinity> Yeah.
<alex_joni> there's a comment there "Checks more than just ACPI actually"
<infinity> You beat me there.
<alex_joni> right.. that one
<alex_joni> I tried unsetting the X86_IO_APIC, but make oldconfig probably put it back
<infinity> I'm assuming that should be #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_ACPI)
<infinity> Or the former should depend on the latter.
<alex_joni> I can change that (for a quick fix now)
<alex_joni> any idea about the efi?
<infinity> Haven't played with EFI on x86 at all yet.  Someone needs to send me a MacTel to play with.
<alex_joni> what's efi actually? 
<infinity> Early load firmware for ia64 (and now MacTel) machines.
<alex_joni> ok, the acpi stuff now doesn't complain anymore..
<infinity> Comparable to, say, OpenFirmware on PowerPC, OBP on Sparc, SRM on Alpha, or the godforsaken PC BIOS on traditional x86 kit.
<alex_joni> oh. ok :)
<infinity> (Not really comparable to the PC BIOS at all, but for the purpose of booting, serves the same needs)
<alex_joni> I see the error comes from drivers/video/imacfb
<alex_joni> I'll unset CONFIG_FB_IMAC
<alex_joni> seems to have done the trick..
<alex_joni> brb, getting some dinner while it compiles
<alex_joni> thanks again for all your help & insight
#ubuntu-kernel 2006-06-04
<zul> yay breezy update is almost done
<alex_joni> infinity: still around?
<infinity> Vaguely.
<alex_joni> I managed top build a working kernel, and headers
<alex_joni> but when I try to build some modules off that header package, it seems that some files are missing from it:
<alex_joni> /usr/src/linux-headers-2.6.15-magma/arch/i386/Makefile:38: /usr/src/linux-headers-2.6.15-magma/arch/i386/Makefile.cpu: No such file or directory
<alex_joni> I think I might need some special incantation to build the headers deb ?
<infinity> Did you build it in the same pass (ie: "make-kpkg ... kernel_image kernel_headers"), or seperately?
<infinity> If it was done in the same pass, it SHOULD work.  Not sure what to tell you if it doesn't.
<infinity> (It's 9:30am here, so I'm fading fast)
<alex_joni> I used only one pass (binary-arch)
<alex_joni> it's 2:36am.. so I understand how you feel..
<alex_joni> binary-arch: kernel_image kernel_headers
<alex_joni> I see a changelog entry by Ben Collins (23.Nov.2005): "Include all Makefiles in kernel-headers package (Makefile*). Fixes i386 module builds against linux-headers (missing Makefile.cpu)."
<zul> yay! linux-image-2.6.12-10-686_2.6.12-10.33_i386.deb
<zul> BenC: ping i have breezy built im just installing breezy and then test and send you the diff again with the desc
<BenC> zul: good deal
<zul> yay it boots
<zul> hey..
<zul> BenC: you got new mail
<BenC> zul: thanks
<zul> yeah it just bounced back to me complaining it was too large
<BenC> ok, someplace to download it from will do
<zul> yep...working on it
<zul> meh...xen does patch cleanly to edgy kernel tree
<BenC> yeah, it will likely get integrated for edgy
<BenC> waiting on the sprint so I can make sure I understand everything involved
<zul> i kind of already started 
* zul shrugs
#ubuntu-kernel 2007-05-28
<mjg59> BenC: Any chance you could turn off all the new experimental RTC class stuff?
<mjg59> BenC: Or rtc-cmos, at least - it's impossible to load it because CONFIG_RTC has already claimed the io ports, but by having it enabled /proc/acpi/alarm is broken.
<burzum> hi
<mjg59> BenC: Thanks!
<burzum> im running ubuntu 6.06 kernel 2.6.15-26-server and need to compile dmraid into the kernel, how do i do that? how get i the correct sources?
<crimsun> burzum: apt-get source linux-image-$(uname -r)
<crimsun> burzum: you may find the wiki link in the /topic helpful
<st3> hi everybody, i'm a maintainer of bcm43xx
<st3> some ubuntu users are reporting a broken bcm43xx driver, so i'd like to know what driver version you put into ubuntu kernel "2.6.20-15-generic #2 SMP x86_64"
* netjoined: irc.freenode.net -> kubrick.freenode.net
<manchicken> Was the atiixp fix ubuntu or upstream?
<stiv2k> can someone help me i cannot load this module powernow-k8 on my laptop
<stiv2k> for cpu frequency scalign
<stiv2k> i have a turion64x2
<stiv2k> ubuntu 7.04 amd64 install
<st3> you should paste your dmesg to pastebin.com or such
<stiv2k> i was gonna paste it here its only 3 lines if you dont mind
<st3> (i'm not from ubuntu team)
<st3> yes, please do it
<stiv2k> [ 2256.872227]  powernow-k8: Found 2 AMD Turion(tm) 64 X2 Mobile Technology TL-52 processors (version 2.00.00)
<stiv2k> [ 2256.871759]  powernow-k8: MP systems not supported by PSB BIOS structure
<stiv2k> [ 2256.872478]  powernow-k8: MP systems not supported by PSB BIOS structure
<stiv2k> FATAL: Error inserting powernow_k8 (/lib/modules/2.6.20-16-generic/kernel/arch/x86_64/kernel/cpufreq/powernow-k8.ko): No such device
<st3> so i'd say you can't do power scaling on your processor
<stiv2k> correct
<stiv2k> its stuck at 1.61 ghz
<st3> no, wait
<st3> you probably need the freq_table module
<stiv2k> i loaded that module
<stiv2k> but i still cant load powernow-k8
<stiv2k> ?
<st3> wait...
<st3> try loading the acpi-cpufreq module
<stiv2k> yeah that gives teh same thing here
<stiv2k> FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.20-16-generic/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): No such device
<st3> did you somehow disable ACPI?
<stiv2k> hmm im not sure this is a fairly fresh install
<stiv2k> how can i check?
<st3> ok, so you probably didn't :)
<st3> (maybe you changed something in the BIOS settings, though)
<stiv2k> coolnquiet works fine in windows
<stiv2k> so bios settings should be ok, i haven't tinkered with those
<st3> ok
<st3> do you get "BIOS error - no PSB or ACPI _PSS objects" or still "MP systems not supported by PSB BIOS structure" now?
<stiv2k> in dmesg?
<stiv2k> powernow-k8: MP systems not supported by PSB BIOS structure
<st3> ok...
<st3> please try "modprobe processor"
<stiv2k> done
<st3> what does modprobing powernow-k8 say now?
<stiv2k> same thing
<st3> very strange
<st3> well, off to dinner, bbl
<stiv2k> pfft
<stiv2k> thanks anyway
<st3> (maybe post a bug report to launchpad or blame ubuntu in some way :)
<st3> stiv2k, please see http://bugzilla.kernel.org/show_bug.cgi?id=8075
<stiv2k> ok
<st3> (and http://bugs.gentoo.org/show_bug.cgi?id=178585 , always the same bug)
<stiv2k> st3: anything specific i should be lookign for
<stiv2k> st3: just to double check] 
<stiv2k> how can i make sure acpi is enabled or disabled
<st3> dmesg | grep ACPI
<stiv2k> seeing a LOT of results
<stiv2k> so i guess its enabled
<st3> yep :)
<stiv2k> ok so at these bug trackers
<stiv2k> what am i looking for
<stiv2k> and are there solutions
<st3> if i were you, i'd post a bug report at launchpad.net/+ubuntu
<st3> https://launchpad.net/ubuntu/+filebug
<stiv2k> k
<JanC> stiv2k: if you file a bug, maybe also link it to the upstream bug report
<stiv2k> whats that JanC ?
<JanC> didn't st3 point to someone with the same bug at kernel.org ?
<stiv2k> yeah
<JanC> after you have submitted your bug report, you can link upstream bug reports to it
<JanC> then the Ubuntu developers and everyone else who's subscribed to the report on launchpad will get informed when it gets fixed in upstream
<defendguin> i'm trying to install an updated version of a kernel module but after i install and modprobe the module it is using the old module how can i prevent this?
<st3> how did you check it's using the old module
<st3> ?
<st3> and how did you install the new kernel module?
<defendguin> dmesg output 
<defendguin> it says the version number when i modprobe it
<defendguin> there is a custom written script to build and install the module
<st3> what module is it?
<defendguin> gspca
<st3> ok, what does the script do?
<st3> please try this: move your old module to another location (maybe add a .old to the filename)
<st3> then run your script and issue depmod -a
<st3> and try again
<st3> probably, either ubuntu or the custom script doesn't install the module in the default location, so you get two modules within the same /lib/modules tree
<defendguin> lets see
<defendguin> mkdir -p /lib/modules/`uname -r`/kernel/drivers/usb/media/
<defendguin> rm -f /lib/modules/`uname -r`/kernel/drivers/usb/media/spca5xx.ko
<defendguin> rm -f /lib/modules/`uname -r`/kernel/drivers/media/video/gspca.ko
<defendguin> install -c -m 0644 gspca.ko /lib/modules/`uname -r`/kernel/drivers/usb/media/
<defendguin> /sbin/depmod -ae
<st3> does every command succeed?
<st3> i bet some rm -f doesn't
<defendguin> looks like it
<st3> well, try to manually remove the old modules and see what happens
<st3> either you won't be able to load it or you will load the new one
<st3> (you can check the path where the old module is with modinfo [module name] )
<defendguin> where is the ko file supposed to be kept?
<defendguin> ahhh
<st3> ehhh :)
<st3> (to find the old .ko file, cd /lib/modules; find | grep pca)
<defendguin> perfect
<defendguin> it loaded the right one this time
<defendguin> i just gotta figure out how to keep this from being over written each time there is an update to the kernel
<defendguin> st3:  why would it say this in my dmesg output?
<defendguin> [16338.444000]  /home/supertux/Desktop/gspcav1-20070512/gspca_core.c: [gspca_set_isoc_ep:907]  ISO EndPoint found 0x81 AlternateSet 7
<defendguin> why that path?
<st3> defendguin, because you compiled it on your Desktop
<st3> that's not related at all
<defendguin> i was just wondering why
<defendguin> i thought it might have been looking for that file or something
#ubuntu-kernel 2007-05-29
<defendguin> st3: is fstab still used or is there a better way to make sure that a partition is always mounted at a certain place?
<TheMuso> c
<TheMuso> ugh
<st3> defendguin, well, i don't see any reason for not using fstab
<defendguin> for some reason i kept thinking there were more high level ways i could manage that procedure
<defendguin> i thought it could be handled by the gnome partition editor but i was mistaken
<st3> don't choose high level when low level is human readable and just works :)
<defendguin> st3: well i could add a new user manually but it is better not to because if i do he won't appear in the user picker in gdm and i can't manage his rights with any high level tool
<st3> well, that's a gdm fault
<defendguin> yeah
<st3> i usually don't use X, so no idea :)
<defendguin> you would think gdm and the gdm config tool would know better
<defendguin> must stink to browse the web without x
<defendguin> and your missing out on all the wobbly windows
<st3> i didn't say i never use X, i usually don't
<st3> well, my graphics card isn't as powerful as needed for displaying wobbly windows :)
<holycow> hey guys
<holycow> i'm looking at buying this device and puttinhg ubuntu on it:
<holycow> http://www.dynamism.com/u8240/main.shtml
<holycow> it has a Intel Pentium A110 800MHz
<holycow> can anyone comment on kernel support for the cpu in any regard?
<holycow> i'm willing to be a guinea pig if any kernel devs need that as a testing platform
<holycow> the chipset is right tho so it should be allright
<mjg59> Should be nothing special about the kernel at all
<holycow> just reading more on that cpu as i've never heard about it, just looks like lower clocked pentium m cpus
<holycow> so indeed
<holycow> mjg59, thanks for the heads up, i'll do a writeup when i get the device on the installation process
<defendguin> hey mjg59   this person found a work around for this bug but what needs to be done to fix this for gutsy?   https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86820
<mjg59> defendguin: Should already be fixed in gutsy, I believe
<defendguin> would it work to test that with a liveCD?
<mjg59> Once they exist, yeah
<defendguin> fair enough.  Thanks
<pwnguin> strange question: what's the "right" way to bring a newer kernel into a feisty install?
<crimsun> #ubuntu question.  I'll address it there.
<pwnguin> i already asked it twice in there, but okay
<koresko> I'm looking for a kernel that can see 1 GB of RAM on x86.  Generic sees about 750M.
<koresko> Is it necessary to recompile the kernel? Hopefully not - 1 GB is the memory size of about half the laptops I saw when shopping for this one a few days ago.
<Mithrandir> -generic sees 1.5GB for me on i386
<crimsun> what Mithrandir said.
<Mithrandir> at least the kernel from 7.04
<Mithrandir> I am fairly sure at least 6.10 and 6.06 did the same.
<crimsun> I just verified on 2.6.20-16-generic and 2.6.22-5-generic
<koresko> Hm, I wonder if I have a bad BIOS setting or something.  Should I try mem=1024M on the commandline?
<koresko> This is with the very latest Feisty kernel, running on a Turion64 laptop (Acer Aspire 5100).
<Mithrandir> sounds weird.  Check that the machine sees all the memory in the bios?
<koresko> Hm, good point.  I will have to reboot but will do that.
<koresko> Hang on, rebooting... should be back in 5 minutes.
<koresko> Ah, OK, I made a bonehead mistake!
<koresko> The problem was that the BIOS had allocated 256 MB to the onboard video card.  I reduced it to 64 MB, and now the kernel sees 969 MB.
<koresko> I was confused because when I upgraded my desktop box from 0.5 to 1.0 GB I needed to rebuild the kernel with the high memory option enabled, else it only saw about 750 MB of memory. 
<koresko> That was under Gentoo.
<Mithrandir> makes sense, then
<koresko> I was afraid I was going to have to maintain my own kernel... the reason I'm running Ubuntu instead of Gentoo on this machine is mostly to do with the fact that it doesn't need as much effort to maintain it.
<koresko> Anyway, thanks for confirming that it was *supposed* to work - else I'd probably have built my own kernel and still been stuck.
<koresko> But now I realize that I don't get any benefit from having 3.5 GB of swap, since the virtual is limited to 4 GB, right?
<cbx33> hi guys....
<cbx33> I'm getting this error
<cbx33> runaway loop modprobe binfmt-464c
<cbx33> but not all the time
<cbx33> just occasionally
<cbx33> i saw on some threads it could be because I'm running 32 bit on 64 arch?
<cbx33> but this machine has happily ran through dapper and edgy and normally feisty
<cbx33> I sometimes get an error about pnpbios failing
<cbx33> and that's usually the start of the problems
<cbx33> anyone got any ideaS?
<cbx33> hmmm
<cbx33> could have been a dodgy ram chip
<st3> koresko, no, it's not limited to 4G
<koresko> st3: Really? Even on x86?  
<st3> my kernel configuration:
<st3> CONFIG_HIGHMEM4G=y
<st3> # CONFIG_HIGHMEM64G is not set
<st3> Mem:   1018228k total,   776696k used,   241532k free,        0k buffers
<st3> Swap:  4882724k total,   273164k used,  4609560k free,   280560k cached
<koresko> Hm, interesting point.  But 32 bits can only address 4G, right?
<koresko> Or are you running a 64-bit kernel?
<st3> i'm running a 32 bit kernel on an old 32 bit processor
<crimsun> Pentium Pros and newer support PAE.
<st3> right
<koresko> I see.
<koresko> Can you actually use more than 4G of virtual?
<st3> (no need for PAE to have large swap, though)
<st3> sure
<koresko> I don't understand how it is addressed... Oh, maybe there is a 4G limit per process and the kernel swaps things around to make that work.
<st3> no, that's entirely kernel managed of course
<koresko> OK, but then what is the point of 64 bits?
<mjg59> You can't have more than 4GB of virtual on x86, no
<koresko> mjg59: Hm, so how is is that st3's machine is showing nearly 5G?
<koresko> I am completely confused now.
<st3> bahaha, do you want me to allocate them all?
<koresko> st3: I was wondering what would happen if you tried that.
<st3> wait
<mjg59> PAE lets you have more than 4GB of physical space
<mjg59> But per-process, you're still limited to 4GB
<mjg59> (Well, 3 really)
<koresko> Ah, I thought it might be something like that.
<koresko> Well, the biggest program I run routinely uses about 900M, so I'm covered!
<st3> ok, i'm almost done...
<koresko> I'm going to bed.  Pretty late here.
<st3> i'm allocating 4294967297 bytes (note the final 7)
<koresko> Thanks for your help!
<koresko> Hm, why that specific number of bytes?
<st3> it's 2^32+1
<koresko> Ah, I see!
<koresko> So... any smoke?
<st3> no
<st3> it works ok
<koresko> And you did this in one process?
<st3> no, two ones
<koresko> Ah, OK.
<st3> (a process is limited to 2^30*3-1 or something like that)
<koresko> That makes sense.
<koresko> Some of the address space (1G) is reserved for the kernel, right?
<koresko> There used to be a config option to control where the split went.  I think the default was 2G/2G kernel/user.
<st3> iirc, the default was 1G/3G
<mjg59> Yes, 1:3
<mjg59> Some of the address space is used to refer to the physical address space
<koresko> Hm, I vaguely remember that being the optional setting.
<mjg59> Moving it lets you use more RAM without needing HIGHMEM
<koresko> OK, I think I see.
<koresko> Bedtime!  Thanks again for the info.  It's hard to find this even via Google (I tried).  The kernel docs themselves are a bit terse.
<tepsipakki> hum, I merged ndiswrapper before checking out the version in kernel..
<lifeless> what would cause a drive to flip-flop between sda and hda on boots ? (not every time, but its not consistent)
<shawarma> Didn't there used to be a restricted-modules package that corresponds to the server images?
<Cheka> hey folks... if i wanted to profile the linux networking stack how would i go about it ?
<BenC> Cheka: netperf?
<Cheka> netperf will tell me the throughput, but i'm more interested in the length of packet processing at each stage
<Cheka> i.e. hardware interrupt, ip processing, tcp processing etc
<BenC> that's more like normal kernel perf stuff
<BenC> oprofile I think is what you want
<BenC> I also don't know if you can get the granularity you're expecting, in regards to ip vs. tcp processing time
<Cheka> i've used another profiler and it shows the amount of time spent in the kernel, but as you said not to the granularity that i want :(
<zul> BenC: is there still a meeting today?
<BenC> zul: yep
<zul> okies
<zul> whats on the agenda?
<zul> er never mind
<Mithrandir> hm, the 3ware 9550SX-12MI should be well supported, shouldn't it?
<Mithrandir> and is a decent controller?
<thom> Mithrandir: yeah, works pretty well for us
<thom> just make sure you get BBUs! :-)
<Mithrandir> battery backups, yeah.
<Mithrandir>  do you have any experience with the Areca ARC-1130?
* Mithrandir isn't very familiar with raid controllers costing ~500
<thom> (the 9550 disables write cache utterly and irrevocably with no BBU)
<thom> we had a couple of arecas and they were dreadful
<Mithrandir> ok, good to know.
<thom> but that was on oldish RHEL
<Mithrandir> the 3wares are cheaper, so it's not a hard choice to make.
<Mithrandir> by about the price of the battery
<thom> heh
<kylem> Mithrandir, all 3ware controllers are pretty good.
<kylem> if you can live with their custom ODF.
<Mithrandir> I'm pondering using them as a JBOD and use the swraid layer
<maswan> Mithrandir: we had rather bad experiences with areca too, 3wares are stable for us.
<kylem> Mithrandir, are you sure they don't use their own ODF with JBOD too?
<Mithrandir> kylem: no, but I'd think it less likely
<kylem> hmm.
<Mithrandir> maswan: ok, thanks.  That settles it.
<kylem> Mithrandir, i don't trust areca... their driver people are... perhaps we should talk in private. ;-)
* Mithrandir chuckles.
<Mithrandir> that bad?
<kylem> no comment.
<maswan> I _think_ I've moved between !3ware and 3ware for md raid5 devices
<maswan> yeah, started out a raidset on sata_sil, then changed to 3ware for stability
<kylem> yeah, 3ware are top notch in the prosumer. raid controller business.
<Mithrandir> ok, coolie
<st3> Cheka, iperf?
<Cheka> does that give me detailed statics of the network code or just the network throughput?
<st3> "Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss."
<Cheka> yeh, that's what i thought, i'm more interested in how long the the packet is in each layer, say the ip processing (i.e. the ip_output.c functions or whatever)
<zul> whoops...I brought down the network at work
<fdoving> did anything special change from 2.6.20 to 2.6.22 that would make my trackpoint die? (latitude d620)
<keturn> fdoving: maybe it's the season for trackpoint death?  the thing on my inspirion 4000 died, but booting older software doesn't bring it back, so I'm assuming it was hardware gremlins.
<fdoving> keturn: well, this machine is pretty new. and it works with the feisty kernels :)
<victory747> Hi, I just upgraded feisty to 2.6.20-16.  Previously (2.6.20-15 and earlier) my IDE hard drive always showed up as /dev/sda.  Now, suddenly with this new kernel it shows up as /dev/hda.  Is this a known problem?
#ubuntu-kernel 2007-05-30
<BenC> victory747: it's not a problem, it's just a change (albeit, one that shouldn't have happened)
<victory747> BenC: thanks.  But I'm afraid of average-joe not being able to proceed if they should upgrade the kernel
<BenC> victory747: unless you hard coded usage of /dev/sdaX in /etc/fstab, it shouldn't cause you any problems
<BenC> victory747: unless they did that, it also should not affect them
<victory747> BenC: right - all the non-hard-coded stuff works as well as LVM
<BenC> on a normal install, fstab and similar things should use UUID instead of hardcoded hdX/sdX devices
<victory747> but it seems odd to change something like that after release
<BenC> as I said, it wasn't intentional
<victory747> so will it be reverted?
<BenC> if people experience the issue and have to fix something, then changing it back is pointless
<BenC> either they fixed it right, and they wont even notice us switching it back, or they fixed it wrong (changed hard coding) and we'll be forcing them to change it again
<BenC> 90% of people wont even know it happened
<BenC> the other 10% had to create the situation that caused it, and would know how to resolve it
<victory747> hmm.  I'm an old unix guy, so never really knew about UUID
<victory747> yeah, like me
<BenC> actually I would put it more like 98/2
<victory747> ok, well if you are aware of it, then I'm ok with it
<BenC> so it's not something that would crop up for a real green user who wouldn't know how to resolve it
<victory747> may I ask why IDE was /dev/sdX in the first place?
<he1ix> yep, that seems interesting to me too :)
<BenC> everyone is hooked on this old idiom that says sdX is scsi
<he1ix> was just about to ask that...
<BenC> libata uses the scsi layer as it's backend
<victory747> I'm not worried about me, but I am very concerned about people I support and people I turn onto Ubuntu.
<BenC> libata has a lot of drivers for SATA/PATA, and we are moving to that core since it is more hotplug capable, and also handles errors a lot better
<victory747> ok, that's what I figured - it made sense to me - but this reversion makes things a real mess
<victory747> in my humble opinion
<victory747> because I work with semi-technical people moving over from windows
<BenC> yeah, the reasoning behind it was that ata_piix was causing some problems that the IDE piix driver didn't have
<victory747> changes like this mid-stream are very frustrating to them
<victory747> ok
<BenC> late in feisty release we moved a few PCI ids back to piix, and somehow a larger portion of the move got left in for feisty post release upload
<BenC> and it shouldn't have. I thought it had gotten reverted
<BenC> that's a mistake we usually don't make, and it's definitely at the top of my "don't let it happen again" list
<victory747> yeah, but what now?
<victory747> we are back to /dev/hdX for IDE?
<BenC> for stability reasons, yes
<victory747> ok
<BenC> I actually don't mind that it happened, because I wanted to do it during beta freeze, but it was considered too extensive of a change
<victory747> may I ask the proper way of finding a partition UUID?
<BenC> sudo vol_id /dev/hga1
<he1ix> victory747: have a look into /dev/disk/by-uuid/
<BenC> *hda1 
<victory747> ok
<victory747> so in feisty+1 will we go back to libata?
<BenC> right, the links in by-uuid are a good starting point, but udev, which mounts things and creates those links uses vol_id
<BenC> victory747: very likely
<BenC> ata_piix PATA support seems to be much more stable now, and all the issues that were noticed for feisty are gone
<he1ix> BenC: ok, sounds reasonable :)
<victory747> ok
<victory747> thanks for your time.  i appreciate your response and I'm glad you are aware of the issues.  that was my biggest concern
<BenC> thanks for taking the time to report it
<BenC> hope my answers were satisfactory
<he1ix> the links provide a nice overview, thats why i like them...
<victory747> no, i understand now the issues, your answers were great.  thanks.
<he1ix> (other topic) i was looking around for this for quite a while, but wasn't able to find anything:
<he1ix> the timestamps that precede every kernel-message... where do they come from?
<he1ix> this seems to be a ubuntu-speciality, afaics
<BenC> he1ix: no, it's a kernel config option that enables them
<he1ix> BenC: vanilla-default? haven't found that...
<BenC> we enable them because it helps us to understand dmesg output when debugging problems
<BenC> he1ix: debian/config/i386/config:CONFIG_PRINTK_TIME=y
<sits> Is there an acknowledged problem with Intel SATA in the latest Feisty kernel update?
<BenC> sits: not that I know of...what's the issue?
<sits> Bug #116996
<sits> https://launchpad.net/bugs/116996
<he1ix> BenC: ah, i see. thanks...
<BenC> sits: the change to hdX from sdX was intentional but it's not really a bug unless something stopped working
<pkl_> AFAIK Dapper has problems in that many system files didn't use the UUID.
<sits> BenC: hang on
<sits> BenC: Isn't it going the wrong way?
<sits> e.g. from hda -> sda
<BenC> pkl_: but the upgrade from dapper to edgy would convert fstab and grub's menu.lst to UUID
<sits> BenC: and what about these IRQ timeouts that are occuring?
<BenC> sits: it doesn't matter which way it goes...if your disk is in IDE compatibility mode, it looks like an IDE disk to the kernel
<sits> ok
<BenC> sits: would be nice if I could see them :)
<sits> heh
<BenC> do you have a digital camera?
<sits> I didn't have time to test things out on a work machine today
<pkl_> BenC: in the Feisty pre-release kernels when the libata work was in flux, there were numerous issues related to systems upgraded from Dapper -> Edgy -> Feisty.  So it is clear in some case the upgrades didn't work correctly, or a number of cases, people had heavily customised grub loaders.
<sits> BenC: so if I understand you correctly
<sits> BenC: the change is simply to make disks set in PATA mode actually appear as PATA disks?
<sits> s/PATA mode/PATA emulation mode
<BenC> sits: the hdX/sdX thing should be a non-issue
<BenC> sits: but your IRQ timeouts concern me, and I'm hoping you can work with us to resolve that
<sits> BenC: well as I said I'll try reproducing it on the dells at work tomorrow
<BenC> does reverting to AHCI or native mode work for you?
<sits> (this isn't my bug it just turns up in my "list of bugs I watch")
<sits> BenC: what about the reports of broken CD drives etc?
<sits> (because they no longer appear as sda devices)
<sits> s/sda/sd
<BenC> CD drives being broken with ata_piix (libata) are the reason things were switched back to piix (IDE)
<pkl_> sits: the fstab entries for CD drives don't use UUID entries.
<sits> pkl_: indeed
<BenC> those should point to /dev/cdrom instead
<sits> pkl_: Would it be even possible for them too given they are removable?
<BenC> which is a symlink to whatever cdrom is detected first (scd0 or hdc)
<BenC> sits: the fstab entry is noauto,user so it's hotplug for when media is inserted
<sits> hmm that isn't the case on my system which is a "Fresh" feisty install
<sits> (this is my home system which is not intel)
<sits> /dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0
<sits> That was created by the Ubuntu installer
<pkl_> In my Feisty install, the fstab entry is also /dev/hdb.
<stiv2k> hey
<sits> pkl_: that's not going to be robust against a change like this
<stiv2k> if im on the amd64 arch, and i have the ia32 libs installed and whatnot, how do i go about downloading the 32bit setiathome app?
<sits> stiv2k: this is probably the wrong channel to ask that
<sits> stiv2k: I'd recommend a 32 bit chroot myself...
<stiv2k> ok something for the right channel
<stiv2k> how come i can't load the module powernow-k8 for the life of me
<stiv2k> heres what happens
<stiv2k> (trying to get cpu freq. scaling to work)
<sits> stiv2k: it doesn't support/knokw your hardware?
<stiv2k> sits: it works fine in windows xp
<stiv2k> FATAL: Error inserting powernow_k8 (/lib/modules/2.6.20-16-generic/kernel/arch/x86_64/kernel/cpufreq/powernow-k8.ko): No such device
<sits> stiv2k: ah that's not quite what I meant
<stiv2k> [  222.884968]  powernow-k8: Found 2 AMD Turion(tm) 64 X2 Mobile Technology TL-52 processors (version 2.00.00)
<stiv2k> [  222.884942]  powernow-k8: MP systems not supported by PSB BIOS structure
<sits> stiv2k: I mean the module itself is unaware of how to support your hardware
<stiv2k> [  222.886287]  powernow-k8: MP systems not supported by PSB BIOS structure
<stiv2k> sits: *shrug* it should work, i remember it worked back in edgy
<sits> stiv2k: check whether you can get an updated BIOS I guess
<stiv2k> its a AMD turion 64x2
<sits> pkl_: I guess I'm wondering if some sort of post cleanup is going to be needed to handle that case
<sits> stiv2k: hmm. OK if it used to work and no longer does then that's different. I guess in that case I would guess it was a regression (assuming it was running in the same 32/64 bit mode in edgy)
<stiv2k> well back in the day
<stiv2k> i had the x86 arch installed
<stiv2k> in edgy, and it worked for a while
<stiv2k> then i think it updated the kernel
<stiv2k> and it stopped working
<stiv2k> i forget which version exactly
<sits> BenC: ok lets assume that I manage to reproduce this problem on an Intel machine tomorrow and I wind up using irqpoll to try and workaround it? What's the next step?
<stiv2k> sits: i think it might have something to do with this.... http://bugzilla.kernel.org/show_bug.cgi?id=8075
<pkl_> sits: yeah, it would be a good idea.  I guess the issue is the belief that if the files are installer generated/ugrader generated, there shouldn't be an issue as they should use UUID.  If you've edited your files, you're on your own etc.  But, as you've seen, for some reason the installer/ugrader seems to be making mistakes, not upgrading to UUIDs, or not using /dev/cdrom.  I don't know enough about the installer to know if this is a genu
<pkl_> ine bug, or what can be done about it unfortunately.
<sits> pkl_: ah I see
<sits> pkl_: I was unaware the installer _should_ have been using /dev/cdrom
<sits> pkl_: the uuid problems are just unfortunate
<sits> stiv2k: looks like you answered your own question : )
<sits> pkl_: and yes, if you hand edit you're on your own
<sits> pkl_: that suggests we may need a ubiquity bug to be opened on this too..
<sits> pkl_: what about rumours of uuids changing when switching drivers though?
<stiv2k> sits: right but it doesnt appear like they fixed it yet :(
<sits> and what about SATA CD drives? Will those really work?
<sits> There's a machine at work that has such a drive and it was utterly unable to boot SUSE 10.1 disks because of a lack of SATA drivers...
<pkl_> sits: that's a weird issue, I can't explain it.  The obvious solution is the filesystem has been reformatted in addition to the driver change, even if the user isn't aware of it.
<sits> pkl_: ok I'll chalk that up as a quirk until I see it myself
<sits> pkl_: an fsck wouldn't cause such a change though would it?
<pkl_> sits: no, a new filesystem has to be written AFAIK.
<sits> pkl_: how do uuids differ from FS labels?
<sits> (sorry for the barrage of questions, just trying to build a picture)
<pkl_> sits: my suggestion would be to use disktype (or another user-space program) that prints UUIDs.  Both using both drivers, and see if the user-space program reports a different UUID.
<sits> pkl_: Ah good suggestion
<sits> pkl_/BenC: you may want to say that the change of driver was intentional in one of those bugs (however I predict that will only stir up a barrage of criticism)
<sits> the only other thing that springs to mind is won't this change from SATA to PATA dramatically cut throughput?
<pkl_> sits: the patches were put into the Feisty kernel, I released the security update with the patches in the kernel.  I _thought_ it was intended to have these changes in the security update, but I'm not so sure now :)
<sits> heh
<pkl_> If they were not meant to be there, then it is probably my fault :(
<sits> hey accidents happen
<sits> I'm just working out whether to get the users at work to upgrade now or wait for another kernel release
<sits> pkl_: you might want to steer clear of the forums for a little bit if it does turn out to be accident though ;)
<pkl_> sits: it depends if they're going to experience some of the issues the kernel fixes, tifm driver (Texas Instruments MMC card), and mouse problems on SiS chipsets are the major changes affecting most people beyond the security fixes (and the dev/sdX - /dev/hdX stuff).
<sits> mouse problems on SiS chipsets? Sigh.
<sits> SiS chipsets cause me enough grief given that the framebuffer puts out strange modelines at 1280x1024...
<pkl_> sits: yeah, I'm mainly lurking watching all the complaints. 
<sits> pkl_: ok understood
<pkl_> anyway, it's gone midnight here, and so I'm off....
<sits> ditto
<sits> night
<pkl_> Ok, night.
<NrbelexUbuntu> Are extremely slow boot times and launch times known to be an issue with the most recent kernel?
<NrbelexUbuntu> My laptop has a 2.2GHz P4-M but its running at a ridiculously slow speed...
<n2diy> NrbelexUbuntu: everybody signed off at 1917 hours Eastern US time.
<NrbelexUbuntu> ... why, n2diy?
<n2diy> NrbelexUbuntu: it was after midnight where they live.
<pkl_> n2diy: there are kernel guys in the states working for Ubuntu... In fact most do :)
<n2diy> pkl_: roger that, did you see NrbelexUbuntu message at 2023?
<pkl_> 2023 in what timezone?
<kylem> iz dinner time.
<kylem> "it's slow" isn't exactly debugging information.
<pkl_> iz two hours past midnight for me...
<n2diy> pkl_: Eastern US, about half an hour ago.
<pkl_> kylem: you shock me, not having a clue isn't an excuse :)
<n2diy> pkl_: ok, take a look at this, he rolled back to his previous kernel, and the system returned to normal, note line 114:http://pastebin.ca/520522
<pkl_> kylem: I've been in that postion for 4 months, and look at all the damage I've caused  :)
<kylem> n2diy, system being slow isn't really a symptom of bad irq routing.
<n2diy> pkl_: ok, take a look at this, he rolled back to his previous kernel, and the system returned to normal, note line 114:   http://pastebin.ca/520522
<pkl_> kylem: this is probably a result of the libata reversion patches?  I'm not aware of anything else that went into the kernel to cause this...
<kylem> yes. i'd believe that.
<kylem> NrbelexUbuntu, could you pastebin the output of hdparm -c -d -k /dev/hda?
<n2diy> kylem: roger that, it is the only thing I saw that raised a flag to me. He quit anyway, so it is a moot point now, thanks anyway.
<purpzey> I've heard from some people in #ubuntu that they've had problems with the new kernel update...Is this and update I should avoid until the quirks are worked through? 
<crimsun> not the appropriate channel, but you should inspect your fstab(5) post-update [but pre-reboot] , revert it if necessary and regenerate the initramfs.
<kraut> hi
<kraut> is there a problem with the feisty-kernel and the usage of UUIDs as root-device in grub?
<kraut> when i use UUIDs, it can't map the root-volume.
<maks_> kraut ask on #ubuntu, that's the support channel
<kraut> maks_: i did it hundreds of times and i got never an answer.
<kraut> and i need this information for my own kernel-maintenance.
<maks_> kraut: your question is so general that one would need a crystal ball to start debugging your question ;)
<maks_> what does "i can't map" mean?
<kraut> hmm, thought it would consist of enough details..
<kraut> maks_: it doesn't found / and runs into a timeout and i'll get the busybox.
<maks_> and did you check which devices or uuid are around?
<maks_> (rootdelay=5 or lower comes handy for such boots)
<kraut> hmm, there is a path under /dev where i find those UUID pathes.
<kraut> ah, thanks for the tip
<kraut> the crazy thing is, that i can't find any UUID pathes in the busybox.
<JanC> use 'vol_id'
<kraut> and i must say, that i compiled the feisty-sources in a dapper-chroot, because i am backporting them.
<kraut> JanC: i try it later and give you more details.
<cmvo> Hi! After upgrading the kernel to -11 in edgy I get the strange phenomenon of sticking mouse keys.
<crimsun> is this 11.37 or 11.38?
<cmvo> crimsun: 11.38
<crimsun> I'm still running 11.37 on an older Dell Dimension XPS, so I don't know offhand if I'll be able to trigger said symptoms
<cmvo> Here it is a P965+Core2Duo and a PS/2 trackball, also kubuntu.
<crimsun> yeah, yours is _considerably_ newer (to the tune of a half-decade)
<cmvo> Its rather strange, it most often happens when clicking and dragging between windows. I release the key of the destination and the dragged object is droppen.
<cmvo> Afterwards it seems the other keys not used during the drap are down.
<cmvo> s/drap/drag/
<cmvo> I was about to blame it on X/KDE, but since booting back to -10.34 the effect is gone.
<crimsun> hmm
<crimsun> I wonder if it's the i8042 changes.
<cmvo> crimsun: where there any between 10.34 and 11.38?
<crimsun> cmvo: no, I was looking at the wrong git tree.  Sorry.
<crimsun> (pulled on -feisty, not -edgy)
<cmvo> crimsun: yeah, this system needs an upgrade...
<cmvo> crimsun: I'll try the other -11s on the next reboot.
<maks_> is there already first field experience of nouveau ?
<maks_> latest powertop wants this hpet patch did you add it?
<maks_> hmm not seen in fedora
<maks_> but they have an 2.6.21 patch to disable hpet on some dell notebooks
<maks_> not yet merged http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/linux-2.6-x86-dell-hpet.patch?view=markup
<apt_get> I need some help with ifb kernel module
<bdmurray> hello?
<crimsun> hi
<bdmurray> hey crimsun I was looking a probable kernel bug but the original reporter replaced the hardware so I'm not sure if there is enough info in the bug
<bdmurray> it is bug 115647
<crimsun> erm, yeah, there's not much that can be done if the hardware itself is gone...
* ..[topic/#ubuntu-kernel:crimsun] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-6.12 | Latest news: -rt and -xen kernels removed, failures in patch | linux-meta uploaded for gutsy 2.6.22 kernels. | New Kernel Team machine: http://kernel.ubuntu.com/
<crimsun> (-> 6.12)
<apt_get> Hi
<apt_get> i need some help with ifb....  
<fxc> just a curiosity: did latest kernel (2.6.20-16) disable libata?
<fxc> My ide disk was sda beofre. Since update it's hda
#ubuntu-kernel 2007-05-31
<jmg> hello all
<jmg> what is the reference way to build a -generic kernel from the linux-source package?
<crimsun> apt-get source linux-image-$(uname -r)
<crimsun> then use debian/rules's target
<jmg> is that how the pbuilder does it?
<crimsun> yes
<crimsun> depending whether you're using feisty or gutsy, you'll need to remove the unneeded configs
<crimsun> please see the kernel wiki  (/topic)
<jmg> thanks
<jmg> crimsun: im trying to compile the gutsy 2.6.22 kernel for feisty (to work around my sdhc bug)
<BenC> jmg: here's a better idea, just install the gutsy kernel on feisty
<BenC> doesn't matter where it is compiled
<jmg> orly?
<jmg> it'll work?
<BenC> I wouldn't tell you to do it if it would break :)
<jmg> BenC: thanks! :)
* Starting logfile irclogs/ubuntu-kernel.log
<Lure> any reason we do not enable CONFIG_SND_AC97_POWER_SAVE as suggested by powertop?
<crimsun> it's very, very experimental.
<crimsun> last I used it in the feisty round, it did Interesting Things on several machines running emu10k1- and intel8x0- driven boards.
<crimsun> I can rerun some tests (and more testing is appreciated), but I don't expect things to have changed much.
<crimsun> I suppose we need more hda-intel coverage, too.
<Lure> crimsun: ok, I may try it here next time I build my custom kernel
<mjg59> crimsun: It does nothing with hda-intel
<jmg> BenC: I just realised - i need the nvidia binary drivers
<ph8> hey guys - is anyone aware of a patch/driver/fix for "Atheros Communications Inc." "Unknown device 001c" "Unknown Device 1033" (From Abit Comp. Corp)? - It's an ethernet controller
<ph8> atm i can only boot in recovery mode for some reason and the only difference i can find is that non-recovery tries to start networks
<ph8> i'd like to try networks from recovery but have no idea how to get the OS to 'mount' the network cards
<lfittl> hm, does anybody know what happened to the linux/ip6_tunnel.h header, debian linux-headers package has it, ubuntu doesn't?
<ivoks> we should add DAC960.ko to /lib/modules inside initrd, by default :/
<shawarma> Was there a recent kernel update for Feisty?
<ivoks> yes
<shawarma> Crap. My girlfriend's laptop doesn't boot anymore.
<ivoks> sda<->hda change
<rtg> shawarma: If you turn off 'quiet splash' from the grub menu, do you see USB crashes? Or does it just fail to boot?
<shawarma> rtg: It's using lilo..
<shawarma> rtg: ah, and it boots with the old kernel.
<shawarma> rtg: I'll switch to grub, and grab some debug info.
<ivoks> lots of people reported that with new kernel their disks aren't sdx anymore, but hdx...
<rtg> shawarma: You'll have to ask BenC about that one. I know vanishingly little about lilo.
<shawarma> rtg: Ah, don't worry about that.
<shawarma> rtg: I got it.
<rtg> ivoks: You are talking about the lib-ata transition from edgy to feisty. I think shawarma already had feisty installed.
<ivoks> no, i'm talking about feisty old kernel to feisty new kernel
<ivoks> there are bugs about it
<shawarma> Now, that's odd. "No ACPI support in kernel" with the old kernel. There used to be..
<shawarma> Oh, ffs..
<shawarma> That's odd. It boots just fine with grub.
<shawarma> Does that make any sense at all?
<mjg59> shawarma: Do you have root=/dev/sda set in lilo.conf?
<mjg59> Rather than root=uuid=foo?
<pkl_> shawarma: yup, grub probably uses UUIDs in the meu.lst file, Lilo probably hard codes /dev/sdX
<shawarma> mjg59: It says root=/dev/hda3
<mjg59> shawarma: That's probably wrong
<pkl_> shawarma: where is your root partition now?
<shawarma> mjg59: But lilo shouldn't worry about that, should it? It installed the new kernel while the old one was running.. Looked up /dev/hda3 to be the third partition on the first harddrive and when rebooting it would just use that? Or have I not understood lilo at all?
<shawarma> pkl_: Interestingly, it's the same.
<shawarma> pkl_: So nothing has changed w.r.t. device names.
<mjg59> shawarma: It passes that argument to the kernel
<shawarma> mjg59: Doh.. Of course.
<shawarma> mjg59: Nevertheless: It's the same name.
<pkl_> shawarma: how far does the boot get?  Do you get past the LILO message?
<shawarma> When I came to the machine it was in an initramfs prompt. When I rebooted it, I got impatient, booted the old kernel and fixed it.. It would have been interesting to find out what went wrong.
<shawarma> I suppose I could reinstall lilo just for kicks if you're interested?
<pkl_> reinstalling lilo would probably make the problem go away anyway.
<shawarma> You think? If I do it with the old kernel running?
<pkl_> shawarma: hmm, it may not work with the old kernel no.
<shawarma> Would it be helpful in any way to get some debugging info this way?
<maks_> no you should just use uuid ;)
<shawarma> Yes.. I wonder why it wasn't migrated back in the day.
<shawarma> Did we only do it for grub?
<maks_> afaik lilo is not directly supported
<shawarma> raid doesn't work with grub, so it must be supported to some degree.
<maks_> why shouldn't it work, sure it does with grub
<shawarma> Hm..
<shawarma> I'm *almost* sure the installer falls back to lilo if you're either using xfs or raid (or both).
<maks_> grub has the xfs patch
<maks_> last lilo fallback i know of is when you go all on lvm
<shawarma> That works with grub.
<shawarma> I'm almost sure of it.
<maks_> hehe *almost*
<shawarma> I'll try. I've got a feisty install on the way in a virtualbox
<JanC> grub works with lvm
<JanC> but you need a non-lvm boot partition then  :)
<maks_> sure i was speaking of *all* on lvm
<maks_> ;)
* shawarma sighs
* shawarma puts a bigger machine on his christmas wishlist
<JanC> why wait until christmas?
<shawarma> JanC: Good point.
<JoseMedina> hi averyone
<JoseMedina> problems with kacpid process
<JoseMedina> ??
<JoseMedina> on mi Server it's eating 90% of CPU
<JoseMedina> root@linux:/home/jose# ps aux | grep acpid
<JoseMedina> root        37 81.9  0.0      0     0 ?        R<   12:37  32:29 [kacpid] 
<JoseMedina> help me! please!
<shawarma> maks_: You're right. LVM-only -> lilo
<crimsun> mjg59: right, I'm speaking of upstream's plans for HDA (not AC'97)
<mjg59> Ah, ok
<Sapote> hi all!
<Sapote> have a question about limit of processors of support for ubuntu
<Sapote> how many processor is the limit? 16? 32? 128? 256?
<Sapote> maxcpus parameter
<JanC> Sapote: depends on the kernel you use
<Sapote> smp
<Sapote> default smp amd64 
<JanC> so -generic kernel for amd64?
<JanC> I don't know the exact number, but AFAIK it should be more than enough for any desktop   :)
<Sapote> ;D 
<Sapote> yes.. but i find the magic number
<JanC> isn't that in the kernel config files?
<Sapote> maybe
<JanC> grep for CONFIG_NR_CPUS in the kernel config file of your kernel in /boot/  :)
<JanC> at least, I think that's the setting you need (I'm no kernel dev)
<rtg> Sapote: /boot/config-2.6.20-12-generic:CONFIG_NR_CPUS=8
<Sapote> 8 ok
<Sapote> thanks!
<JanC> I don't think many desktops have more  :)
<JanC> server kernels might have support for more CPUs
<JanC> rtg: you have amd64, or it's always the same for -generic ?
<rtg> Sapote: debian/config/i386/config.server-bigiron:CONFIG_NR_CPUS=64
<JanC> yeah, server-bigiron is for people with deep pockets :)
<Sapote> lol!
<rtg> JanC: generic is the same for i386 and amd64.
<Sapote> :D
<Sapote> maxcups parameter 1-256  is correct?
<JanC> rtg: thanks, good to know, wasn't sure about that  :)
<rtg> Here are all of the CPU configs:
<rtg> debian/config/i386/config.server:CONFIG_NR_CPUS=8
<rtg> debian/config/i386/config.server-bigiron:CONFIG_NR_CPUS=64
<rtg> debian/config/i386/config.generic:CONFIG_NR_CPUS=8
<rtg> debian/config/ia64/config:CONFIG_NR_CPUS=64
<rtg> debian/config/hppa/config:CONFIG_NR_CPUS=32
<rtg> debian/config/amd64/config.server:CONFIG_NR_CPUS=64
<rtg> debian/config/amd64/config.generic:CONFIG_NR_CPUS=8
<rtg> debian/config/sparc/config.sparc64-smp:CONFIG_NR_CPUS=64
<rtg> debian/config/powerpc/config.powerpc-smp:CONFIG_NR_CPUS=4
<rtg> debian/config/powerpc/config.powerpc64-smp:CONFIG_NR_CPUS=32
<Sapote> thanks rtg, JanC
<JanC> well, except for the i386 UP kernel  :)
<rtg> JanC: CONFIG_NR_CPUS depends on CONFIG_SMP
<JanC> so if CONFIG_SMP is not set, NR_CPU == 1
<JanC> :)
#ubuntu-kernel 2007-06-01
<lifeless> hi
<lifeless> whose around ?
<lifeless> CONFIG_BLK_DEV_IO_TRACE is not enabled in Feisty; is it in gutsy, or are there plans to do so? the blktrace program is unusable without it.
<lifeless> (at least, to the best of my knowledge)
<kraut> moin
<kraut> is there no REGPARM support anymore in the feisty-kernel?!
<Mithrandir> grr, obexftp or bluetooth reliably hangs my x40 with the feisty kernel.
<kraut> ah, REGPARM is default now, nice.
<ivoks> is it only me or others are havin problems with git? fatal: unexpected EOF
<ivoks> doh.. never mind
<abogani> it works for me
<ivoks> yeah... my mistake
<shawarma> Any objections to adding DAC960 to the "most" list of modules in initramfs ? ( http://launchpad.net/bugs/31035 )
<maks_> done since long afair
<maks_> initramfs-tools (0.75) unstable; urgency=high
<maks_> and feisty adds all the drivers/block subdir
<maks_> so you can close the bug as resolved shawarma
<maks_> i do wonder why we still hardcode the net drivers list, any reason for that BenC?
<maks_> (there might have been size consideration?)
<fabbione> maks_: mostlikely because root over nfs is not very common and it doesn't make sense to pull in all possible network driver in the initramfs
<fabbione> while you want to be able to boot from any kind of block device.. always
<shawarma> maks_: So it does. My bad. Thanks!
<pinch150g> I was told to ask here by folks in the #edubuntu if you might be able to help me figure out what is going on with my boot up from a CD
<pinch150g> Here is the problem
<pinch150g> I get the following error:
<pinch150g> end_request: I/O error, dev fd0, sector 0 (Multiple Times)
<pinch150g> then
<pinch150g> /bin/sh: cant access tty; job control turned off
<pinch150g> Then it hangs after
<pinch150g> sr1: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
<pinch150g> Do I need to load some other controller drivers before I can boot?
<pinch150g> If you can't help, can you guide me to someone who can?  I have looked on the ubuntu forums and tried everything--no good!
<pinch150g> Anyone?
<pinch150g> Is there anyone here?
<pinch150g> Hello?
<pinch150g> Is anyone available to answer a question?
<pinch150g> Anyone there?
<pinch150g> Hello?
<rtg> pinch150g: Go through the Launchpad process. I suspect your bug is a duplicate. https://bugs.launchpad.net/ubuntu
<pinch150g> I already checked there and saw that it was there multiple times.  I can't seem to get any of the work arounds to work for me.
<pinch150g> I'm checking for updated Intel 82801BA chipset drivers to see if that fixes the problem
<pinch150g> rtg: thanks
<lifeless> morning
<lifeless> BenC: around perchance?
<BenC> lifeless: yeah
<lifeless> CONFIG_BLK_DEV_IO_TRACE is not enabled in Feisty; is it in gutsy, or are there plans to do so? the blktrace program is unusable without it.
<lifeless> I'd like to use blktrace in bzr performance work, it looks like it would be useful.
<BenC> lifeless: it isn't, but if you could file a bug against linux-source-2.6.22 I'll look into it
<lifeless> thanks I'll do that
<lifeless> BenC:  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/118303
<lfittl> BenC: are the patches for Mobile IPv6 in the gutsy kernel? http://www.linux-ipv6.org/umip-0.3-ann.html.en
<BenC> lfittl: if they aren't upstream, then no
<BenC> lifeless: thanks
<lfittl> BenC: any chance that you could take a look at them (not much code), and merge them?
<BenC> lfittl: There's no way I can include a patch that touches that much code
<BenC>  21 files changed, 914 insertions(+), 91 deletions(-)
<BenC> that's way over my "trivial" threshold :)
<lfittl> hm, I see, anything I could do to convince you? (I just want to avoid compiling a custom kernel for multiple machines)
<lfittl> e.g. testing
<BenC> No, there's a strict don't-muck-with-upstream-where-possible guideline for stock kernel
<lfittl> ok, so getting it into mainline is the only way?
<BenC> pretty much
<BenC> these patches are against 2.6.21-rc5...you sure it isn't in 2.6.22-rc3 yet?
<lfittl> not completely, I will check that, thanks
#ubuntu-kernel 2007-06-02
<unhappy> where i can read about Kconfig files
<pmjdebruijn> unhappy, I have no clue, but usually I look for examples in other Kconfig files to suit my needs
<unhappy> ok
<pmjdebruijn> unhappy, sorry, that wasn't extremely helpful I know... but it's the best I can do... maybe wait around for someone else to suggest something
<unhappy> maybe you know, do i have to somethink after editing kconfig file, to see changes in make menuconfig?
<unhappy> *to do
<pmjdebruijn> not that I know of
<pmjdebruijn> unhappy, I should show right away
<pmjdebruijn> unhappy, I could be that you need to add something at a lower level
<cofeineSunshine> thxn
<cofeineSunshine> damn, forgot my nickserv passwd
<cofeineSunshine> trying to build drivers for my wireless card
<VoX> where would i report an ubuntu kernel bug?
<pmjdebruijn> VoX, www.launchpad.net just like all the other bugs, just file it against the kernel package you are currently using
<VoX> nod
<sits> Hi, can someone fill me in on what direction https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116996 is going to take?
<sits> oops wrong bug
<sits> Bug #117314
<sits> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117314
<sits> Is the current thinking that all associated bugs are to be closed when the -17 kernel is released?
<sits> And what's the current advice to be given to people who have yet to upgrade to -16 but are ICH4/ICH5 owners?
<lupo527> hello
<lupo527> got a question about getting into kernel development
<lupo527> anybody there :)
<kraut> no, sorry
<lupo527> heh
<kraut> you should point your question more specific
<lupo527> hey i am wanting to get into kernel dev and i was wondering if there is anything wrong with doing it in vmware
<lupo527> if i just wanted to develop for the x86 arch for example is there any problem with doing kernel dev in a virtual machine as opposed to real hardware?
<kraut> not really, depends if you want to develope hardware-drivers or just other things.
<lupo527> more interested in things like the scheduler and memory management
<lupo527> and i have limited hardware options
<kraut> should be a good possibility to test your stuff, but generally you should do a final test on real-hardware. but anyhow a vmware should be good enough.
<lupo527> excellent thanks
<lupo527> i didn't think it would be a problem but i wanted to ask the more experienced ;)
<kraut> i am stupid
<lupo527> heh but you hand out in kernel dev channels?
<lupo527> :P
<lupo527> hang*
<kraut> i am just spamming stupid stuff around
<JanC> lupo527: it's a good way to prevent breaking your system  ;)
<JanC> after a kernel upgrade, check this channel for 2 hours, and if there is no invasion of lamenting people, it's probably safe  :)
<lupo527> can i ask a kind of more generic question: how did you guys get started in kernel dev, seems the overhead to getting started is kind of high
<JanC> especially when using the development version
<JanC> I didn't & most likely won't  :)
<lupo527> hard to know where to start
<lupo527> heh okay ;)
<kraut> JanC: hrhr, cool idea of quality-management *g*
<sits> lupo527: there's plenty of material out there
<sits> lupo527: I've been trying to crack it for years but haven't gotten to far
<sits> lupo527: you should definitely check out LDD3
<sits> lupo527: http://lwn.net/Kernel/LDD3/
<sits> lupo527: http://kernelnewbies.org/ also has a slew of material
<sits> lupo527: http://kernelnewbies.org/CareerAdvice seems to be on similar lines to what you're asking about here
<sits> lupo527: if you don't mind looking at something other than Linux check out Minix
<sits> lupo527: http://www.minix3.org/
<sits> lupo527: because its meant for teaching a lot of the code is simpler to understand than that of Linux (but it doesn't run as fast or do as much or run on as many platforms)
<sits> (e.g. it's floppy driver doesn't look nearly as ugly as Linux's)
#ubuntu-kernel 2007-06-03
<poningru> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88400
<poningru> my friend is using the current kernel
<poningru> but apparently not fixed for ihim
<crimsun> what isn't fixed?
<crimsun> I can't debug problems utterly lacking in detail
<poningru> sorry
<poningru> finding it from him
<poningru> will post it there
<poningru> in the bug that is
<crimsun> please don't; have him post a separate (new) bug
<crimsun> it really complicates my life to triage reports with twenty different comments, about nineteen of which have utterly similar symptoms but completely different causes
<crimsun> oh, and he's online, we can skip the ping-pong.  Have him attach the output from the http://www.linux-sound.info/alsa/scripts/alsa-info.sh script, please.
<poningru> yes sir
<crimsun> thanks, that will help immensely
* gavinbaker waves @ poningru 
<poningru_> crimsun: http://pastebin.ca/532125
<gavinbaker> crimsun: like many others on the forums, etc. -- i can get sound from speakers with model=3stack, but nothing from headphones/mic
<crimsun> I'm doing an alsa-kernel commit ATM; I'll read scrollback momentarily.
* gavinbaker curses ATI
<gavinbaker> also, no audio on resume from hibernate -- but the jacks (out/in) is the bigger problem :-/
<crimsun> ah
<crimsun> you need to try hg, or gutsy's kernel.
<crimsun> I can help you in #ubuntu+1, since we're not talking kernel devel anymore.
<poningru_> gavinbaker^^
<unfold> cd #ubuntu
<unfold> sorry
<pmjdebruijn> unfold, happens to the best of us :)
<unfold> heh :)
<unfold> is there anyone specially occupied with usb functionality?
<unfold> because of the usb_autosuspend stuff
<BenC> unfold: yeah, the upstream kernel maintainers of linux-usb :)
<BenC> unfold: we can't disable usb-suspend in the kernel, because it penalizes almost all laptop users with poor battery performance
<BenC> so if there are drivers not working well with it, then linux-usb maintainers need to know about it so they can fix it
<unfold> well, my thought was that backporting the additional delay in the newer kernels shouldn't be thaaaat difficult.
<unfold> let's say i did that - is there any chance you would add that patch?
<BenC> Shouldn't be difficult, but regression testing it to make sure that it alone works and doesn't break anything else, is not so simple
<BenC> very doubtful
<unfold> ok
<unfold> though you can see in the bug list that a lot of people are whining for their scanners ;)
<BenC> then maybe someone can rebuild the latest feisty kernel with the patch and put it up for testing by not only the people with scanners, but other people to make sure it doesn't break for them
<BenC> if people with scanners says it fixes things, and other people say it doesn't break things, then we're much more likely to consider it
<unfold> then i'll have a look at it.
<BenC> our biggest fear is breaking existing setups....which is in no way acceptable when trying to fix other bugs
<unfold> i understand this, of course.
<unfold> bye
<thedeviantone> I'm a noob when it comes to recompiling a kernel, but I'm trying to install 6.06 LTS on a SCSI Drive.. the controller I have is a PERC2/SC from a dell PowerEdge 2300.. I keep recieving this error
<thedeviantone> i20: iop0 could not activate controller
<kraut> moin
<thedeviantone> moin ?
<thedeviantone> Can anyone assist me with compiling a kernel for SCSI controller support?
<thedeviantone> Has anyone added SCSI controller support to 6.06 LTS ?
<thedeviantone> Has anyone added SCSI controller support to 6.06 LTS ?
<BenC> thedeviantone: I'm pretty sure we support scsi controllers in 6.06
<thedeviantone> You do, i just can't get my controller to work... I get this error everytime "i20 iop0: could not activate controller
<BenC> check the forums, so of those controllers require one of two drivers
<thedeviantone> k, thanks for your help
#ubuntu-kernel 2008-05-26
<lapo> hi
<tseliot> amitk, rtg, tjaalton: I would like to talk to you about the linux-restricted-modules-common since we'll still need them in the future if we want to be able to load proprietary drivers at boot (see the lrm-video, lrm-manager, etc.). Let me know when you're available.
<foka> Hi!
<guijemont> hi
<guijemont> I have posted a patch that seems to solve #216854 (nvidia modules missing in linux-restricted-modules-2.6.24-16-xen)
<guijemont> with it I can build an nvidia.ko that works with a xen kernel
<guijemont> for hardy
<guijemont> I would love it if someone could review it
<guijemont> I have more or less randomly assigned the bug to tjaalton 
<lamont> May 26 16:29:28 mix kernel: [357575.337219] VMBlock warning: DentryOpRevalidate: invalid args from kernel
<lamont> those are neat warnings... why do I get so many of them?
<guijemont> don't know how (not) clever it is, but he seemed to have handled quite a few nvidia-related things
<guijemont> including atempts to patch for the xen kernel
<justdave> I have what's essentially an embedded Linux device which I wiped off the hard-drive on it and installed Ubuntu Gutsy.  Mostly it works great except for a couple pieces of the hardware, and I'm trying to figure out if I can hack this thing so the rest of the hardware works.
<justdave> since it's driver-level stuff I figured this might be a place to ask for help, but if this is a bad place, feel free to redirect me elsewhere :)
<justdave> I'll probably end up having to hack some drivers I'm sure. :)
<justdave> it's basically a 7" touchscreen that hangs on a wall, and has USB and ethernet on it.
<justdave> The hardware I haven't figured out how to access yet is a button on the front panel and some LEDs on the side
<pwnguin> why gutsy?
<justdave> It has a NatSemi Geode processor in it (Pentium 200 compatible I think, but has GPIO ports on it that I'm pretty sure the button and LEDs are hooked up to)
<pwnguin> hardy's out and might make a more suitable long term hacking project ;)
<justdave> er, I misspoke there, Hardy's what I put on it. :)
#ubuntu-kernel 2008-05-27
<justdave> it was "current release" earlier this week, so I assume Hardy
<pwnguin> yea
<justdave> the thing did have Linux on it as shipped, but all binaries, and no dev toolkit on it
<justdave> and a 2.2.18 kernel
<justdave> so I'm assuming swiping the drivers off the original software probably won't be much use
<justdave> the lack of a dev toolchain is the main reason I reloaded it
<justdave> the software that shipped on it was all java and I hate java anyway (not to mention it was all compiled class files anyway, so not easily hackable)
<pwnguin> im not sure there's a big ubuntu embedded community
<pwnguin> you might seek out embeddian
<justdave> Figured it'd be more fun to do touchscreen stuff in python ;)
<pwnguin> or start an ubuntu embedded community if you like something in particular to ubuntu
<pwnguin> err emdebian
<pwnguin> if you're in germany, emdebian will be at fosdem in brussels
<pwnguin> like tomorrow
<pwnguin> er no
<justdave> heh.  nope, USA.
<pwnguin> thats right, its linuxtag thats in germany soon
<guijemont> isn't there that moblin project ?
<guijemont> based on ubuntu afaik
<guijemont> moblin.org
<pwnguin> there is
<pwnguin> but
<pwnguin> its basically a group for hire working on specific hardware and requirements
<justdave> that looks like it's mostly for modern embedded hardware :)
<justdave> this thing is like 7 years old
<guijemont> yeah, I think they're mainly targetting intel Atom
<guijemont> it's an intel sponsored project if I understand correctly
<justdave> looks like the Geode stuff was manufactured by several folks...  AMD claims all the drivers got upstreamed into the mainline kernel
<justdave> I found 4 kernel modules in Hardy that appear to deal with GPIO ports, but none of them seem to work on this thing
<pwnguin> if you dont like emdebian, there's also the gumstix community
<pwnguin> they also deal with gpio ports
<justdave> emdebian might work, still reading. :)
<justdave> haha, is this timing or what
<justdave> just updated the package list and had a geode video driver show up
<justdave> maybe I can do something better than VESA on this thing after all
<justdave> although vesa isn't exactly working poorly on it, so I'm not too concerned :)
<tseliot> can anyone of the kernel-team approve my subscription to the mailing list, please?
<Swish> I was successful in compiling the kernel with make menuconfig followed by make-kpkg etc, but what's the right way to modify some .config options in the debian/config/i386/config file -then- build it the "ubuntu" way with the syntax:  AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules custom-binary-FLAVOUR  ?
<Swish> i should say, what's "a" right way to do that, considering the config files are split up and later concatenated, and if I just overwrite a config file in debian/config/ARCH, that doesn't work at all and when I initiate a compile, i get asked a ton of questions
<soren> tseliot: You don't need approval to subscribe to the mailing list.
<soren> tseliot: I certainly didn't, so I can't imagine why you would.
<tseliot> soren: is this the right link to the mailing list? https://lists.ubuntu.com/mailman/listinfo/kernel-team
<soren> Looks like it.
<tseliot> soren: I did it yesterday but I didn't receive the email to confirm my subscription
<tseliot> I have just tried it now and it works
<tseliot> o_O
<emgent> morning
<tseliot> ï»¿emgent: moring
<amitk> Swish: you can use the "debian/rules prepare-<flavour>' to do that
<Swish> amitk, oooh, /me googles
<amitk> Swish: e.g. debian/rules prepare-generic
<Swish> okay, so that would create a .config file in debian/build/build-generic/ ... and then... I would edit that .config file in make menuconfig, then run some other script to re-split that new .config file into the multiple files in the debian/config/whatever dirs?
<emgent> heya tseliot 
<amitk> Swish: yes. We did talk about simplifying that a bit by directly allowing an interactive 'make menuconfig' and then split up the result..
<amitk> splitconfig.pl in the scripts directory will help you split up the config now
<Swish> ah ha.  so splitconfig uses as input the debian/build/* dirs, and outputs back into the debian/config/* dirs?
 * Swish edits it
<amitk> Swish: we'll accept patches to do this automagically ;)
<Swish> hee hee ;)
<Swish> this will have to wait until my kernel compile is done.
<Swish> thanks for the info!  :)
<alex_joni> BenC: short question. is 2.6.24-18 going to be pushed soon?
<BenC> how do you mean pushed?
<alex_joni> I mean released
<alex_joni> I saw that git has that ABI number
<BenC> it's still being prepared by the security team I guess
<rtg> BenC: I think the security upload will happen today. or as soon as kees comes online.
<BenC> rtg: sounds good
<BenC> rtg: FYI, current intrepid locks up on my 1420 laptop (using 64-bit kernel) whenever I close the lid
<BenC> getting ready to rebase to -rc4 to see if it fixes the problem
<BenC> it's a strange lockup though.. the entire system locks up, except the screen is still on, and the mouse still moves...everything else is dead (no screen updates other than mouse)
<rtg> BenC: I've been so busy with Hardy SRU's that I haven't even loaded Intrepid in several weeks.
<BenC> rtg: Do you have any systems that duplicate the suspend/resume problem for testing ehci-hcd removal?
<rtg> BenC: At least 2. Both of my XPS laptops
<rtg> I've also fixed some Dell 640's using the same method, though I don't know if they were running -17
<BenC> Do you have a way to test with a USB2.0 device attached to see if it causes some issues?
<rtg> BenC: I think the case that we need to test is when your root device is USB. I have only one external USB drive, and I'm loath to trash it. Maybe I have a flash stick thats big enough.
<rtg> I wonder if the classmate is USB?
<BenC> it is
<BenC> What does removing ehci-hcd do when you have a usb2.0 device connected?
<rtg> BenC: thats what I'm trying to find out. It for sure dumps bluetooth devices correctly.
<BenC> does it revert it to usb1.0 transparently, fail to be removed, or does it remove the devices completely?
<rtg> BenC: I think it removes them, Looking at dmesg implies that for bluetooth.
<BenC> And if the device is in use, I suspect it will fail to unload then (e.g. usb root fs)
<rtg> BenC: right, that was the case I was asking mjg59 about.
<BenC> rtg: shouldn't need to make it rootfs...should be able to test with it mounted, and open files on it
<mjg59> No, there's no locking to prevent you from removing it
<BenC> mjg59: then does it play nice and drop devices to usb1.0?
<mjg59> Not as far as I know
<mjg59> You'd need to trigger the 1.0 controller to power down the port and power it up again to get the handshaking redone
<BenC> so in-use devices just get removed...that's pretty shitty...and makes it dangerous to add to pm-utils for removal
<mjg59> There's no way you can drop from 2.0 to 1.0 without a simulated reconnection
<mjg59> The protocol just doesn't allow it, AFAIK
<rtg> BenC: correct. I think its the reason some file systems have gotten corrupted.
<BenC> Can reconnections be done for in-use devices without loosing state?
<BenC> in-kernel state I mean
<BenC> *losing
<mjg59> You could possibly abuse the USB persist stuff
<mjg59> But I suspect it'd be unhappy about it being on a different controller
 * BenC is totally into abusing things
<amitk> BenC: you want to checkout the USB persist patch that I applied to get classmate suspend working? :)
<rtg> amitk: how does persist work?
<amitk> rtg: by working around the issue of the USB controller powering down on suspend. So the data structures are maintained on suspend. On resume, the kernel checks the persistence flag and prevents 'reset' of the device
<rtg> amitk: does that work for the general case, e.g., for more then just the classmate?
<amitk> or actually does just a port reset..
<amitk> rtg: works across all devices, it is now default in 2.6.26, no kconfig option AFAIK
<rtg> amitk: hmm.
<amitk> rtg: ohh.. and each device has a persist file in sysfs where you tell whether it is persistent or not
<BenC> rtg: I finally re-installed my laptop using 64-bit
<BenC> netscape+flash seems to be working perfectly fine
<BenC> s/netscape/firefox/
 * BenC jumped back about 10 years for a moment there
<amitk> BenC: wait till npviewer.bin starts crashing on you...
<BenC> amitk: youtube+myspace+random-junk for 4 days and no crash yet
<rtg> BenC: I've been running 64 bit for a couple months on both XPS's with no issues.
<rtg> amitk: I think the noviwer stuff must have gotten fixed. I've not had any problems with it sine about alpha 4
<rtg> *npviwer
<BenC> forced push of rebase to -rc4 for intrepid
<amitk> BenC: did you do a sync first?
<BenC> hopefully no one committed anything in the last 20 minutes :)
<amitk> we just cleaned up the tree..
<amitk> BenC: did you pull after friday?
<BenC> I pulled this morning
 * amitk sighs with relief...
<rtg> BenC: yeah, amitk cleaned up all of my Intrepid merge history. made it a lot nicer to look at with gitk. it might have also caught a couple of merge problems.
<BenC> ubuntu-intrepid-ports is also being pushed
<BenC> Hopefully I can get an upload of that today some time
<BenC> and be done with it
<rtg> BenC: I gotta get working on LRM and finish packaging the new broadcom driver.
<BenC> Who's handling the dkms nvidia/fglrx packaging?
<rtg> BenC: mario  and alberto milone.
<rtg> the envy guy
<amitk> rtg: did I tell you alberto volunteered to handle madwifi too..
<rtg> amitk: handle it how?
<amitk> rtg: DKMS'ify it
<rtg> amitk: maybe we wanna get some experience with DKMS before we jump into the deep end.
<rtg> we haven't exactly turned it loose on a million desktop users yet.
<amitk> agreed...
<BenC> When does he think he will have something in the archive?
<rtg> BenC: I think they were shooting for sometime this week.
<rtg> BenC: at least that was Mario's goal. I may distract him with Hardy issues, though.
<soren> If a vendor/device ID combo is listed twice in modules.pcimap, which gets chosen? First match? Last match? Undefined?
<rtg> soren: its sorted in modules.dep.
<BenC> soren: undefined though
<BenC> there's no guarantee which will get loaded
<soren> So the list of modules that support the device is generated, and the one of those to appear first in modules.dep is chosen?
<soren> Or something to the same effect?
<rtg> unless the driver is blacklisted, its the first one in modules.dep that gets loaded.
<BenC> that's generally what happens, but don't depend on it
<rtg> BenC: well, LBM _does_ depend on it.
<BenC> rtg: No, it doesn't
<rtg> then I have an imperfect understanding.
<BenC> rtg: modprobe will prefer things in updates/ before all others
<BenC> modules.*map defines the module name, not the location it is loaded from
<rtg> BenC: depmod  will prefer things in updates/ before all others
<BenC> rtg: But that affects modules.dep, but modules.pcimap
<BenC> *not
<BenC> modules.pcimap is just a listing, modules.dep is where it gets the load location/dependencies from
<rtg> BenC: modules.*map merely defines the module(s) name for a matching ID, right?
<BenC> right
<BenC> which means you cannot rely on the ordering in that file
<BenC> modules.dep is a different story
<rtg> BenC: right, order in modules.*map is unsorted.
<rtg> but, moduels.dep is sorted according to depmod search rules.
<BenC> right
<BenC> but soren was asking about the ordering in modules.pcimap, which is unreliable :)
<rtg> so, modprobe uses a straightforward algorithm to choose which module to load.
<rtg> oh, maybe I misread sorens question.
<rtg> soren: back to my original statement :) Unless blacklisted, the first module in modules.dep that is referenced in a modules.*map is the one to get loaded.
<Xsss4hell> Is the 2.6.25.4 Kernel out jet?
<Xsss4hell> for Ubuntu
<Xsss4hell> I need it, because of ATI gfx cards and Catalys 8.5
<rtg> Xsss4hell: Are you talking abut Intrepid?
<Xsss4hell> no
<Xsss4hell> I have Ubuntu Hardy..
<Xsss4hell> Just wanted to update the kernel..
<rtg> Xsss4hell: Hardy will continue to be based on a 2.6.24 kernel.
<Xsss4hell> WLAN doesn't work either with the 2.6.17 Kernel.. Fritz!Wlan
<Xsss4hell> 2.6.24.17 I mean
<rtg> Xsss4hell: is there a bug report on it somewhere that I can read?
<Xsss4hell> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/225353
<rtg> Xsss4hell: ok, I'll look in a bit. on a conf call for awhile.
<Xsss4hell> But I doesn work with 2.6.24.16-17 as far as I've tested it. WPA works on 2.6.24.16 but only with ndiswrapper and windows drivers.. Think about it, this type of wlan stick is the most common in Germany
<Xsss4hell> WPA2 doesn't work on any of these kernels
<Xsss4hell> rtg thank you ;)
<BenC> rtg: -rc4 seems to have fixed the lockup I had when closing the laptop lid
<rtg> BenC: you must have seen something on LKML that lead you in that direction?
<BenC> rtg: my 1420 works out-of-the-box with stock kernel (no lum/lbm/lrm)
<rtg> BenC: it ought to. I turned on all of ALSA. 
<rtg> in the kernel, that is.
<rtg> BenC: have you tried the microphone?
<BenC> I did have to copy firmware
<BenC> for iwl
<BenC> rtg: Let me check...
<BenC> Hmm, no built-in mic I guess...I'll need to find one to hook up
<BenC> it seems to be working, just recording dead air tho
<rtg> BenC: you should have iwl firmware in LUM. there is a LUM package on the kernel PPA. I'll start an upload with the -rc4 rebase.
<johanbr> The 1420 I have does have a built-in mic.
<johanbr> Maybe it's different depending on your options at purchase time.
<rtg> johanbr: I have one as well, I just have to unearth it. Some are digital mics, some are analog.
<johanbr> What do you mean by "unearth" ?
<rtg> johanbr: I have a bunch of laptops from Dell. the 1420 is somewhere in the pile.
<johanbr> Ahh, okay. I thought you were talking about the mic. :)
<rtg> johanbr: the 1420 built-in mic was difficult to get working. I really hope there is no regression there.
<BenC> johanbr: if you get the webcam option, it has built-in mic
<BenC> I wonder if my other 1420 has the webcam
<BenC> Ah, I have an E1420 that has built-in webcam+mic
<BenC> I can swap my drive to it and test
<rtg> BenC: what a PIA. wouldn't it be faster to just reinstall?
<BenC> two screws vs. reinstall?
 * BenC goes for the 2 screws
<rtg> BenC: oh, much simpler then some I've dealt with.
<BenC> it's too bad the 1420 doesn't have a wwan slot for my verizon card though :/
<rtg> BenC: is that the laptop you're using since you wrecked your XPS1330?
<BenC> yep...I was using the 1535, but that was too bulky
<BenC> low battery life too
<Xsss4hell> hi
<Xsss4hell> To the kernel developers! Why don't you create a dynamic kernel tick rate, that automatically adjusts from 100Hz to >1000Hz if needed?
<mjg59> Xsss4hell: The kernel already has a dynamic tick rate, so really what you're asking for is the default timeslice setting
<Xsss4hell> yes, that what audio production system needs.. I think that's what you said
<Xsss4hell> :)
<Xsss4hell> so?
<mjg59> Xsss4hell: So, the question you want to ask is "Can the default CONFIG_HZ be changed to 1000"
<mjg59> :)
<Xsss4hell> no, not really
<Xsss4hell> my qustion then is
<Xsss4hell> Can the default CONFIG_HZ be dynamically changed to 1000
<mjg59> No
<Xsss4hell> why not?
<BenC> CONFIG_HZ is not a dynamic value
<Xsss4hell> I know ^
<BenC> so we can't dynamically change it
<Xsss4hell> That's why I'm asking you, if you make it dynamic in the next kernel version
<BenC> how do you propose we do that when it isn't a dynamic value?
<Xsss4hell> modify the kernel's source
<BenC> Do you have a patch to do this?
<Xsss4hell> I wished I had one =)
<BenC> You do realize it's not dynamic for a reason?
<BenC> because it's hardcoded in a lot of fast path functions
<Xsss4hell> I don't understand the reason why it is hardcoded.
<BenC> dynticks is about as good as you are going to get
<BenC> and we already have that
<BenC> if you need something better, I would suggest the -rt kernel
<BenC> which is there specifically for hardcore audio work
<BenC> you could also try recompiling the kernel with CONFIG_HZ=1000 and let us know how that works for you
<Xsss4hell> example audio production midi etc.. needs a very high tick. but these producers don't need the high tickrate 24/7 so why not set it dynamically down, to boost non-time cricital applications
<BenC> it can't be done
<BenC> you are saying it like it's a something simple we can just turn on in the kernel, when it would require tons of time to implement, even more time to regression test, and most likely impact performance to a point beyond acceptable limits
<Xsss4hell> you mean, to much work. or technically not possible. because I don't understand the reasone why it doesn't work these way.
<Xsss4hell> I did compile the 2.6.25.4 kernel with  CONFIG_HZ=1000  by the way. it's great but performance is not good a non time-critical apps and 3d somehow.
<BenC> It would take way too long to explain why we can't just do this :)
<Xsss4hell> hehe I see
<Xsss4hell> but can you say if it is technically physically not possible, or it is just too much work?
<BenC> CONFIG_HZ is hardcoded in the kernel, which means replacing it with a variable reference, which means overhead in time critical functions
<BenC> it's possible, just not worth the effort because of the performance loss
<BenC> IOW, you would lose performance by simply replacing CONFIG_HZ with a variable
<Xsss4hell> then maybe running time-critically marked apps with CONFIG_HZ=1000 and all other with the CONFIG_HZ rate. Similar to QoS priority tagging
<BenC> That makes no sense
<BenC> HZ isn't a per process setting
<Xsss4hell> It is just an idea. I know it isn't dynamic.
<BenC> that's not even the point
<BenC> HZ isn't a for applications...it's for the kernel
<stgraber> you can't change the rate for a single app, it's for the whole system
<stgraber> so if you implement something like that, it'd mean you change HZ to 1000 as soon as one of those "tagged" app is started
<BenC> HZ is (basically) the number of times the kernel hits a timer interrupt, in which it can do things like scheduling processes
<BenC> the more times you do a timer interrupt, the more changes per second the kernel can do context switching between processes, but it also means more time the kernel spends doing those things, instead of letting your processes run
<BenC> s/changes/chances/
<Xsss4hell> true
<Xsss4hell> suboptimal
<Xsss4hell> it isn't a generic solution, but a special: like generic user? take generic kernel | hardcore audio user? take rt kernel
<Xsss4hell> like said it was a thought. I hoped that there is no need for a different CONFIG_HZ rate and things could work with one variable CONFIG_HZ rate..sadly it costs to much effort to create such a thing
<BenC> There's lots of ways to adjust the scheduler though...perhaps there's some way to tune things to your liking
<Xsss4hell> ty for your patience and this informative chat session
<Xsss4hell> good bye
<foka> rtg, Hi!  Just a follow-up to the seemingly corrupted dmesg output seen in RTL8102E bug reports:
<foka> BenC, https://bugs.edge.launchpad.net/ubuntu/+source/klibc/+bug/235282
<foka> rtg, It is not memory corruption, but rather a buggy dmesg  :-p
<Tophat> wheee - hey mates ive read over the wiki and all the fun articles i can find.  but im still not quite sure how to get developing on the ubuntu kernel.....you know being a windows developer and all.
<rtg> foka: right, it was the result of memory corruption in video ram because the network driver crashed.
<laga> Tophat: well, what do you want to develop?
<foka> rtg, Apparently not... In my case, it actually looked alright on the scrollback buffer, but not the "dmesg > dmesg.log" output.
<foka> rtg, https://bugs.edge.launchpad.net/ubuntu/+source/klibc/+bug/235282
<rtg> foka: anything after a crash is suspect.
<foka> rtg, You see, we began seeing the same problem on machines that weren't crashed by a kernel oops...
<foka> rtg, Actually, you may do an experiment to see if it is the case.
<foka> rtg, Try /usr/lib/klibc/bin/dmesg
<Tophat> laga - im not to sure, theres tons of things i would like to do.  but im not sure if you use git or cvs.  how you do your pushing (who decides whats good and whats not) and all that fun stuff
<rtg> foka: hm, I didn't realize it occured even when the NIC driver was sane.
<foka> rtg, And compare its output to /bin/dmesg (from util-linux)
<foka> rtg, Let's just say we ran into yet another motherboard which refuses to boot due to SATA timeout, and then we saw the same weird dmesg output... (No kernel oops)
<foka> rtg, I have yet to find time to report the bug about that motherboard though (a new ECS motherboard with nVidia MCP78 chipset)
<rtg> foka: I'll assign the bug to myself so I don't forget it, but I've some other stuff thats gotta get done first.
<laga> Tophat: you can clone the kernel source code for ubuntu using git
<laga> Tophat: if you got patches, you can send them to the ubuntu kernel mailing list.
<foka> rtg, No problem, it is no hurry, just so that you know /bin/dmesg currently included in initrd.gz is buggy.
<laga> for big features, it's probably a good idea to use the vanilla kernel from kernel.org. but i'm not a kernel developer, so someone in here might know better :)
<foka> rtg, I ended up copying a normal /bin/dmesg to a USB stick to get a correct dmesg output.
<Tophat> thanks laga ill do that and play around for a while
#ubuntu-kernel 2008-05-28
<abogani> tjaalton: Are you around? May i disturb you for a minute?
<tjaalton> abogani: shoot
<abogani> tjaalton: Do you have a suggestions about last comment of the Bug #197130?
<tjaalton> abogani: not really, seems that -new is buggy (surprise!)
<tjaalton> maybe test the upstream beta version to see if it's any better
<abogani> tjaalton: I'm very bored by closed video drivers....
<tjaalton> abogani: join the club :)
<abogani> tjaalton: i'm not very interested to join that. :-)
<tjaalton> abogani: can't blame you..
<abogani> tseliot: Do you have a minute for me?
<tseliot> abogani: sure
<abogani> tseliot: Do you have a suggestions about last comment of the Bug #197130?
<tseliot> abogani: let me have a look at it
<abogani> tjaalton: No problem. It isn't urgent :-)
<tseliot> ï»¿abogani: I haven't experienced problems with -rt and the nvidia-new driver. I can install the -rt kernel again and see if I have problems
<tseliot> I'll let you know
<abogani> tseliot: Please no. I don't waste your time. :-)
<tseliot> abogani: I'm the new maintainer of the nvidia driver for Intrepid (together with tjaalton) therefore I will have to deal with it sooner or later ;)
<abogani> tseliot: I already know it ;) a lot of discussion about it in this channel. 
<abogani> tjaalton: I hope that tjaalton is happy too :)
 * tseliot boots into the -rt kernel
<abogani> tjaalton: Just curious, Except you and tseliot are there other nvidia driver maintainer?
<tseliot> abogani: :~$ uname -r
<tseliot> 2.6.24-17-rt
<tseliot> alberto@alberto-desktop:~$ dmesg | grep NVIDIA
<tseliot> [   53.003447] nvidia: module license 'NVIDIA' taints kernel.
<tseliot> [   56.135592] NVRM: loading NVIDIA UNIX x86 Kernel Module  169.12  Thu Feb 14 17:53:07 PST 2008
<tseliot> in other words the driver works well here
<tseliot> abogani: can you try the latest release of envyng-core from proposed and see if it solves the problem?
<abogani> tseliot: Ok. I'll try it asap.
<abogani> tseliot, tjaalton: Thanks you very much!
<tseliot> ï»¿abogani: thanks for reporting ;)
<rtg__> BenC: are you thinking you might upload the Hardy -security kernel today?
<BenC> rtg__: I passed all the uploads to kees...I figured he would do the actual upload
<BenC> I was actually thinking about a linux/linux-ports upload today :)
<rtg__> BenC: ok, didn't know that. I wonder if he was on vacation yesterday?
<rtg__> BenC: I want the -security kernel uploaded so I can get the next -proposed kernel out of my hair. the new LRM with broadcom is dependent on it.
<BenC> rtg__: last I heard, the security uploads were supposed to be done yesterday
<rtg__> BenC: just checked, its still -17.31
<zul> kees was sick yesterday
<guijemont> tjaalton: hi! (are you here?)
<guijemont> I've seen at some point you were trying to have nvidia's proprietary driver working with xen
<guijemont> is that still something you want to do?
<guijemont> because I have a patch for that, posted on the relevant bug
<guijemont> #216854
<BenC> guijemont: I'm sure the xen folks are interested :)
<guijemont> well, the reason why I am mentioning it here, is because there is a bug for linux-restricted-modules regarding that
<guijemont> and seeing the package source, and changelog, there's obviously been an attempt to do that
<guijemont> and the patch is a patch to be applied on nvidia's kernel module
<guijemont> not on xen or on the kernel itself
<tjaalton> guijemont: yes, there's a patch which didn't help much.. failed to build IIRC
<guijemont> yeah, that's what I've seen in your changelog entry
<rtg__> tjaalton: I'm working on incorporating the new Broadcom driver into LRM. I'll probably upload it against the -17 kernel sometime today. OK with you?
<tjaalton> rtg__: sure, I don't have anything for LRM at the moment
<rtg__> tjaalton: cool, just wanted to make I wasn't stepping on toes.
<rtg__> tjaalton: all the more reason to get LRM under source code control.
<tjaalton> rtg__: heh, stomp as much as you like :)
<tjaalton> indeed
<tjaalton> btw, any news on bug 212485?
<tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/212485
<tjaalton> happens pretty frequently here, but we've switched back to nfs3 for now, since .24 seems to make our netapp unhappy (don't know if this bug has anything to do with it..)
<rtg__> BenC, tjaalton: package question, I can't seem to get LRM to use the new orig.tar.gz when building the source package. The new orig.tar.gz is linux-restricted-modules-2.6.24-2.6.24.13.orig.tar.gz, the changelog version is 'linux-restricted-modules-2.6.24 (2.6.24.13-17.38) hardy-proposed; urgency=low'. I can package linux-restricted-modules-2.6.24_2.6.24.12-17.36 just fine.
<rtg__> tjaalton, BenC: never mind. I spotted a '-' where there should be an '_'.
<Ng> is it possible to build LUM just for one flavour? (specifically, generic)
<Ng> for reasons of extreme hilarity, I am building LUM with s/alsa 1.0.16/alsa nightly snapshot/    \o/
<Ng> but I'm guessing that a full build is going to take some time
<laga> i think it's possible, but i don't remember the specifics
<blueyed> rtg__: what do you think about merging http://git.openvz.org/?p=ubuntu-hardy-openvz;a=summary ? - It contains the a whole bunch of bugfix patches from the OpenVZ guys.. but then the upstream linux kernel tree also contains a lot of fixes, but does not get merged "as is"..
<rtg__> blueyed: I'll do whatever you guys want, as long as you've tested the patch set and it works for you. just send pull requests on the kernel team mailing list.
<blueyed> rtg__: sounds too easy.. :D - at least I've asked about the CFS config before many times.. ;)
<blueyed> yes, it works for me. I'll file a bug for it.
<rtg__> blueyed: send an email to the kernel team mailing list as well. i get buried by bug reports and I may not see the LP status change.
<Tophat> what is the latest hardy git resp?
<rtg__> Tophat: https://wiki.ubuntu.com/KernelMaintenance
<Tophat> what git command would i use to update my codewithout having to redownload all of it?]
<emgent> heya people
<LaserJock> where's the best place to report or look for a report of a regression in the 2.6.24-17 Hardy kernel?
<LaserJock> ah, I think I found the right report
<LaserJock> bug ##227029
<LaserJock> anybody about how could direct me to some debugging procedures?
<munckfish> try looking through https://wiki.ubuntu.com/KernelTeam
<munckfish> plus generally google for articles on debugging the linux kernel
<LaserJock> yikes, https://wiki.ubuntu.com/DebuggingKernelSuspend looks rather scary
 * lamont notes that the laptop gets extremely pissy when you hibernate 2.6.24-16 and then resume 2.6.24-17 :-)
<akv> I just tried the 2.6.25 kernel from https://launchpad.net/~kernel-ppa/+archive, but it fails when loading wireless drivers - http://lnxbx.dk/~akv/temp/2.6.25.txt
<soren> lamont: I would have assumed the resume code rejected the hibernation image?
<lamont> soren: dunno... it was pretty annoyed
<soren> lamont: I'm not surprised :)
<soren> lamont: I thought that the very first thing it did was to check some ID string or something.
<lamont> soren: and wifely one was remote with it, so there was lots of uh, attempts before I got my hands on it, and hard power-cycled it and booted the old kernel long enough to reboot into the new
<soren> lamont: Maybe its PRNG wasn't seeded properly, so it reused the one from the -16 kernel...
<lamont> soren: what's the pid of the kernel?? :-D
<soren> iz sekrit.
<lamont> lolz
#ubuntu-kernel 2008-05-29
<osmosis> anyone know what causes high IO wait times with 3ware controllers?
<abogani> cutted from article published by LWN.net: "[...] Any attempt to maintain compatibility with proprietary drivers would, at best, slow that progress down significantly. [...]"
<BenC> linux-ports is being uploaded shortly...
<rtg__> BenC: I posted a test kernel that reverts the scheduler change. it does not look like it has any affect on suspend.
<rtg__> BenC: which kind of makes sense 'cause I'm running -17 and am suspending OK.
<BenC> rtg__: Ok
<amitk> hmm.. rtg__ what would be the 'prepare' target for binary-customs?
<rtg__> amitk: its prepare-custom-lpia, right?
<rtg__> amitk: ah, it custom-prepare-lpia
<rtg__> amitk: see 6-binary-custom.mk
<amitk> rtg__: gotcha. Thanks
<emgent> heya
<LydianKnight> good night to all, could I make a question about the latest kernel upgrade available with ubuntu 8.04 LTS? that's... 2.6.24-17
<LydianKnight> what I would like to know is if the latest kernel update is equal to the 2.6.24.7 kernel or it's a lower version, I keep looking at both cat /proc/version and the Makefile in the /usr/src/ hierarchy, but the only number I get is EXTRAVERSION = .3... what does this mean?
<LydianKnight> I need this piece of information to be able to make ubuntu serve as a compilation host for making a customized version of Linux, but I would like to use --with-kernel=current parameter, but I need to know if 2.6.24.7 and 2.6.24-17 are matching kernels or are different versions...
<LydianKnight> anyone could answer this to me?
<|DuReX|> https://bugs.launchpad.net/ubuntu/+bug/235889
<|DuReX|> if u need help testing out a patch :) feel free
<|DuReX|> :D
#ubuntu-kernel 2008-05-30
<emgent> morning
<|DuReX|> https://bugs.launchpad.net/ubuntu/+bug/235889 could somebody check ? :)
<|DuReX|> can somebody plz take a look @ https://bugs.launchpad.net/ubuntu/+bug/235889
<|DuReX|> its kinda important for me
#ubuntu-kernel 2008-05-31
<|DuReX|> can somebody plz take a look @ https://bugs.launchpad.net/ubuntu/+bug/235889
<|DuReX|> what could cause it ? aka what code/file in the kernel
<jjt009_fuba1> hey guys
<jjt009_fuba1> anyone here?
<jjt009_fuba1> anyone here?
<emgent> heya
<jptet6818> please, someone can help me with a kernel module subject?
<jptet6818> I am using linux-image-2.6.24-17-generic from distro (Hardy 8.04). I managed to make things work at the most in my notebook (Acer 5040) and everything is fine using this kernel.
<jptet6818> Now I have a need to plug some device via usb and after google a lot, I figured out that I need the zaurus kernel module installed. 
<jptet6818> today in my /boot/config-2.6.24-17-generic the module is commented  [# CONFIG_USB_NET_ZAURUS is not set]. 
<jptet6818> The question is: Have I to compile and build the entire kernel because of this module or can I just build the module (alone) and install it?
<jptet6818> I gave it a try (following instructions https://help.ubuntu.com/community/Kernel/Compile) but after hours I had generated just 2 .deb packages (linux-image and linux-headers) with the code  2.6.24.3-zaurus-blah-blah-blah and the linux-ubuntu-modules with the old 2.6.24-17 code. 
<jptet6818> After a reboot with the new kernel internet connection and audio goes away, even if I succeed to start zaurus module after installing my device at usb connector.
<jptet6818> so I would prefer, if it is possible, generate and install just the module I need in my old generic kernel.
#ubuntu-kernel 2008-06-01
<jptet6818> Hi, I have ubuntu hardy kernel 2.6.24-17-generic. I this distro has  line in the /boot/config-2.6.24-17-generic like that "# CONFIG_USB_NET_ZAURUS is not set". I would like to have this module set to =m but I don't want to build an entirely new kernel. It is possible?
<jptet6818> Say ... just to compile and install this module but not to build a entire kernel...
<mdomsch> jptet6818, yes
<mdomsch> jptet6818, in your kernel source tree, do
<mdomsch> make prepare
<mdomsch> make M=drivers/usb/net
<|DuReX|> can somebody plz take a look @ https://bugs.launchpad.net/ubuntu/+bug/235889
<laga> mjg59: i've just seen your "power management, anger" talk. awesome :)
<mjg59> laga: Thanks :)
<laga> mjg59: i've also got an all-intel HP laptop which works great in hardy. i guess i have to thank you for that as well ;)
<mjg59> A cast of thousands
<|DuReX|> nobody ? :(
<mjg59> |DuReX|: It's the weekend
<|DuReX|> been asking for some days :(
#ubuntu-kernel 2009-05-25
* sconklin changed the topic of #ubuntu-kernel to: Ubuntu Developer Summit this week. info on http://summit.ubuntu.com - and in #ubuntu-devel-summit
<sconklin> ogasawara: do you know what % of kernel bugs are filed against linux-meta?
<ogasawara> sconklin: I don't know off the top of my head, but I think I can find out
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138
<ubot3> Kano: Error: Could not parse data returned by Malone: timed out
<Kano> i created that bugreport because nobody listend to me, but the kernel patch you use is critical
<Kano> i definitely prefer a default config that does not lead to data loss on new systems with gigabyte boards in default config
<Kano> your kernel hack leads to that, when the full hd space is allocated
<Kano> of course i have got my own distro, but sometimes i want to try others, but i dislike when my raid fails after testing em
<Kano> bye
<manjo> apw ping 
#ubuntu-kernel 2009-05-26
<garfield_> can somebody with udev/module-auto-loading knowledge look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/372232 ?
<ubot3> Malone bug 372232 in linux "kernel 2.6.28 from 2.6.27 prevents Alcor reader working" [Undecided,New] 
<garfield_> it is basically usb-storage that isn't loaded automatically for 2.6.28-11, while 2.6.27 is fine, see also the executive summary in the last post from me (Simon)
<bryce_> anyone seen apw around?  point him towards me if you see him
<jacksparrow> how can I monitor what a process writes to a file or device (bytewise)?
<Edgar1> hello
<Edgar1> i have got the linux-2.6.29.4 kernel(source code), and i'm going to compile it(want to)
<Edgar1>  I'm using ubuntu, so any help and instruction i will thank you
#ubuntu-kernel 2009-05-27
<Edgar1> it seems no one is available
<akgraner> what's the wiki link?
<pgraner> https://wiki.ubuntu.com/KernelTeam/Specs/KarmicBetterSuspendResume
<akgraner> thank you !
<juliux> hi
<juliux> any chance to get ipmisensors working with ubuntu?
<pkern> Would it be possible to have the mainline PPA be more PPA-like and apt-get'able for releases like 2.6.30.x?
<franczen> Hello
<franczen> Can I check somewhere whether my atheros wlan card is supported by the mac80211 stack?
<franczen> It doesn't work since jaunty
#ubuntu-kernel 2009-05-28
<dandel> i need to ask, when booting with single boot option, is the default tests one does in that supposed to not be logged in case it results in a failure?
<dandel> i've ran in to a few issues when testing my acpi and such where the acpi doesn't return my display to a usable state, and when i reboot to check the kernel and system log files, i find large blocks of missing test sessions, which occurred while booted in to the single user mode.
<sgodsell> hello everyone
<sgodsell> is there a mkinitrd command in ubuntu?
<sgodsell> how do you make the initrd file for ubuntu?
<sgodsell> I know in fedora or redhat it is mkinitrd command
<dandel> yes.
<dandel> it's called minitramfs
<dandel> *mkinitramfs
<sgodsell> dandel but its not the same
<dandel> it does.
<sgodsell> you don't specify the kernel version
<dandel> mkinitramfs -o /boot/initrdfile version
<sgodsell> okay
<sgodsell> I will try that then
<dandel> initrdfile is the target file.
<sgodsell> dandel, if you need to add a module.   How do you add it?
<dandel> like?
<dandel> ubuntu auto detects all modules in the initrd from what i know.
<dandel> only special task on certain modules, like having to blacklist ath5k to use the ath_pci module is really required.
<sgodsell> oh, wait the man page said to use /etc/initramfs-tools/modules
<sgodsell> so I guess I modify that file then
<sgodsell> thank you dandel 
<sgodsell> thanks for your help
<dandel> np, actually i have other issues i'm trying to fix/figure out with that ><;
 * dandel really wonders why when i boot with  the flag, "single" it causes all system, kernel, and etc logs to not be logged happens.
<dandel> i use single and go to the root terminal and the syslog and kern log do not get updated, and it really hampers the acpi testing (nor do i know what to fix to help on this)
<sgodsell> single mode is run level 1
<sgodsell> isn't it
<dandel> possibly
<sgodsell> so nothing is really loaded 
<dandel> i was trying to run tests without xorg up and that's the easiest way to go about that.
<sgodsell> do you want maybe run level 3.  No graphics mode (server mode)
<dandel> if i knew how to boot in to that, i would.
<sgodsell> instead of single use the number 3
<sgodsell> when grub comes up
<sgodsell> press e 
<sgodsell> for edit
<dandel> just tell me the param
<sgodsell> on the end of the kernel line add the number 3
<dandel> i've modified the boot params dozens of time using nano
<sgodsell> you can do it that as well
<mjg59> sgodsell: Ubuntu doesn't distinguish multiuser runlevels by default
<mjg59> 3 is the same as 5
<dandel> well the nasty handling of single mode 1 is a huge issue then.
<sgodsell> mjg59, oh, thats right ubuntu doesn't use sysv
<mjg59> sgodsell: No, that's nothing to do with it
<dandel> especially since when during testing i sometimes can't get the monitor to come back ><;
<dandel> and haft to reboot with the ctrl+alt+delete combination.
<dandel> and at that point, i really need the log to figure out what happened ><:
<dandel> i'm currently doing testing on bug 338701
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Medium,In progress] https://launchpad.net/bugs/338701
<dandel> mjg59, how would i boot in to a mode where the logging daemons would start.
<apw> Kernel UDS session (room 14): Incorporating Andoid into the Ubuntu Kernel: session starting
<apw> gobby doc: karmic-kernel-android
<apw> ... session done
<apparle> hello
<apparle> has this bug been fixed in 9.04 kernel http://bugzilla.kernel.org/show_bug.cgi?id=7467
<ubot3> bugzilla.kernel.org bug 7467 in Sound(ALSA) "snd-atiixp driver does not load on DFI rs482 mainboard" [High,Closed: code_fix] 
<apparle> ..
<Kano> hi, why is lzma support not used for karmic kernel compression
<pkern> There is no KMS support for ATI r500 on Ubuntu yet, right?
<pkern> (I mean I fact I know Fedora already released with support for it, but still.)
#ubuntu-kernel 2009-05-30
<paraneetharanc> Hi all
<Kano> hi apw , what do you think of enabling lzma compression for the karmic kernel image
<Kano> also you could check the kernel config and enable lzma compression for initrd
#ubuntu-kernel 2009-05-31
<cbo> hi
<cbo> I wrote a little patch for 2.6.28 kernel, it has been accepted by the lnux kernel team and is now part of 2.6.30. Is there any chance to have it already applied on Jaunty's kernel ?
<cbo> I just posted a new comment about Bug #181361 ( opened since January 2008 ) affecting the Logitech G25 force feedback wheel.
<ubot3> Malone bug 181361 in linux "Logitech G25 does not fully work with Ubuntu" [Undecided,New] https://launchpad.net/bugs/181361
#ubuntu-kernel 2010-05-31
<smb> Morning to the part of the world without bank holiday
<RAOF> Which part of the world *has* a bank holiday, and how do I apply? :)
<smb> RAOF, US and UK ant least. How you apply I don'T know. :)
<smb> My part of the world has its holiday Thursday
<RAOF> Ah.  That might be why it's been unusually quiet.
<smb> Yep, time to get work done *cough, cough*
 * smb waves to ikepanhc 
<jk-> hey smb & RAOF
<ikepanhc> smb: good morning
<smb> Hi jk- 
 * amitk waves
 * cooloney waves back to amitk, smb, ikepanhc, jk- and RAOF 
<RAOF> o/
<smb> cooloney, \o
 * ikepanhc waves
<stenten> Can someone help me decide the importance of Bug #587136?
<ubot2> Launchpad bug 587136 in linux (Ubuntu) "2nd Resume from Suspend results in reboot on Toshiba Satellite U400. Fixed in 2.6.34 Mainline. (affects: 2) (dups: 1) (heat: 20)" [Undecided,Confirmed] https://launchpad.net/bugs/587136
<stenten> Based off the other linux bugs, I'm thinking High.
<smb> stenten, I would agree
<stenten> smb: Thank you kindly.
<TeTeT> smb: Hi Stefan, any chance to get the Lenovo x201 WWAN module into lbm? seems that mjg59 refactored it, according to the last mail
<smb> TeTeT, Its on the list to look at, now the other things have been done. I am not sure how far I get with all of it today and unfortunately I did not heve time to look at it again, yet
<TeTeT> smb: the roll out for the customer is not before july 18th, so anything that lands for 10.04.1 is good enough. 
<TeTeT> smb: Should I escalate this driver support issue through Zaid, so it get's on your "official" todo list? or is it good enough as is?
<smb> TeTeT, Ok. Let me look at it to decide how much work it might be. I would ping you if I think it needs more work and thus a more official backing.
<TeTeT> smb: thanks a lot, please let me know in any case 
<smb> TeTeT, Sure
<yzhao> cooloney: hi, bryan~
<cooloney> yzhao: welcome, yingying
 * smb waves to yzhao 
<ericm|ubuntu> yzhao, yingying!
<ericm|ubuntu> smb, do you know who's maintaining libusb? I wish I know where to send a relevant patch
<smb> ericm|ubuntu, Not from my head. Would need to ask checkmaintainer.pl too. Theoreticall Greg and Alsan Stern might be suspect. But I would see what the script says.
<smb> s/Alsan/Alan/
<ericm|ubuntu> smb, ah - not drivers/usb/, but a user space libusb library
<ericm|ubuntu> it's in main repo, yet seems to be unmaintained by any of canonical member?
<smb> ericm|ubuntu, oh, user-space... eek. :-P
<ericm|ubuntu> yet the bzr branch is progressing by <archive@ubuntu.com>, .....
<smb> Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<smb> Original-Maintainer: Aurelien Jarno <aurel32@debian.org>
<smb> ericm|ubuntu, So I'd post to both. The second probably is the debian maintainer
<ericm|ubuntu> smb, how did you find this out? I executed dpkg-query -p libusb-0.1-4, only find Aurelien Jarno
<ericm|ubuntu> but yeah, I guess these two mail addresses will work
<smb> apt-cache show libusb-1.0-0 (not on maverick, yet :-P)
<smb> Oh, wait libusb-0.1... ?
<ericm|ubuntu> smb, yes - legacy and unfortunately upower seems to be linked with it
<smb> I guess I am just confused by one thing finding a libusb-1.0 and the other number being a 0.1
<smb> ericm|ubuntu, But luckily the mail addresses are the same for both
<ericm|ubuntu> smb, heh - since 0.1 is crap
<ericm|ubuntu> that's why it's broken on my Mac
<smb> Heh, and somehow I got the impression both are produced by the same source package
<smb> ... no wrong...
<smb> ericm|ubuntu, So there is a libusb and a libusb-1.0
<ericm|ubuntu> smb, they are two separate
<smb> ericm|ubuntu, Which you probably were already saying by legacy lib linked agains upower
<ericm|ubuntu> seems emerald.pgraner is down again
<diwic> Hi there, how do I find out what options are enabled in a standard Lucid kernel?
<ogra> in /boot/config-$(uname -r)
<amitk> diwic: 'less /boot/config-2.6.32-*
<amitk> '
<amitk> heh
<ogra> :)
<diwic> thanks :-)
<diwic> is there also an online list for different kernel versions than the one I have currently installed? 
<lapion> Hello,
<lapion> how can I cross- search for processor-chipset combinations in launchpad
<hrw> hi
<hrw> is it possible to crossbuild linux-libc-dev from linux source package?
<smb> hrw, I am not sure I understand what you mean with crossbuild. Build on another architecture?
<hrw> smb: on amd64 build package with headers for armel
<ericm|ubuntu> smb, do you mind have a look at my git pull request a bit time ago (just forwarded that mail to you)?
<smb> hrw, If you have the toolchain installed (though that is only available for i386 iirc) you could cross compile the whole package. Other I don't know
<hrw> ok
<ericm|ubuntu> hrw, ask in ubuntu-arm, they may possibly know
<hrw> thx for info
<smb> mpoirier, Wouid you know something better?
<hrw> ericm|ubuntu: will
<ericm|ubuntu> hrw, not every package is cross-build-able
<smb> ericm|ubuntu, Ok, will do
<ericm|ubuntu> smb, let me know if it needs a SRU process - it was actually sent before -L release maybe (or happened to be the freeze period maybe)
<mpoirier> smb: what exactly do you want to know ?
<smb> ericm|ubuntu, Everything we now upload needs at least a little more process. Not yet looked into the mail, but one thing good to have would be a lp bug report that tracks/explains things
<ericm|ubuntu> smb, LP bug report already there
<smb> mpoirier, It was about the cross complile question from hrw 
<ericm|ubuntu> and I've updated every commit with that info
<smb> ericm|ubuntu, Sounds good
<ericm|ubuntu> smb, thanks man
<smb> mpoirier, I don't do many arm builds but the standard cross compiles of the whole kernel package. But I don't think there is a way to get the libc-dev package without a complete cross compile env.
<mpoirier> smb: not that I know of...
<smb> mpoirier, Ok, thanks for the confirmation. 
<mpoirier> smb: the cross-compilation environment is changing for maverick - for ARM at least.
<mpoirier> smb: for OMAP4 I should say.
<smb> mpoirier, Something I probably need to inform myself sooner or later
<smb> or saying educate myself
<mpoirier> smb: I wouldn't rush too quicly on that one...
<mpoirier> I think it is still maturing.
<amitk> mpoirier: the cross-build enviroment changing? how?
<mpoirier> Changing is probably not the word I should have used.
<smb> mpoirier, Oh, now worries, I am seldom rushing. :)
<smb> gos no worries
<hrw> amitk: I am working on making 'cross-toolchain' source package possible
 * smb cannot type today
<mpoirier> I was referring to Bryan's sbuild stuff, which differs from what was being done in Lucid.
<hrw> smb: "ARCH=arm make headers_install" does not require cross toolchain
<hrw> mpoirier: ah
<mpoirier> Mind you, I am still plowing through that one.
<amitk> mpoirier: there are two different things (sbuild and cross)
<amitk> *they
<smb> hrw, That can be true. I am just not sure the debian build environment we use allows to produce the lib package without going through the architecture specific parts which also does the kernel image. 
<smb> But then, I cannot say I am an arm guy...
<hrw> smb: s/arm/anyotherarch/ even
<hrw> I recently hacked binutils packaging and built cross binutils for alpha/hppa/etc just to test does it work
<smb> OK, so I should say when I did compile I either completely cross compiled or used native builds.
<hrw> correct me if I'm wrong but does not 'linux' source package has broken builddepends?
<hrw> Build-Depends: dpkg (>= 1.13.19), debhelper (>= 5), gawk
<hrw> kernel-wedge was required to let me start building, then it broke due to lack of libefl-dev...
<amitk> libefl to build a kernel package?
<hrw> Makefile:504: *** No libelf.h/libelf found, please install libelf-dev/elfutils-libelf-devel and glibc-dev[el].  Stop.
<hrw> make[1]: Leaving directory `/home/hrw/devel/canonical/2010/05-cross-compilers/ubuntu/maverick/source/linux-2.6.34/debian/build/tools/tools/perf'
<hrw> make: *** [install-tools] BÅÄd 2
<hrw> dpkg-buildpackage: bÅÄd: fakeroot debian/rules binary zwrÃ³ciÅ status bÅÄdu 2
<amitk> aah, libelf, _not_ libefl
<hrw> argh typos
<amitk> hrw: I am assuming you're cross compiling, what is your exact command?
<hrw> dpkg-buildpackage -b -uc -us -aarmel 
<hrw> with proper 'export CROSS_COMPILE' before it
<smb> Hm, in my lucid tree (master)
<smb> Build-Depends: debhelper (>= 5), cpio, module-init-tools, kernel-wedge (>= 2.24ubuntu1), makedumpfile [amd64 i386 lpia], device-tree-compiler [powerpc], libelf-dev, binutils-dev, rsync
<amitk> hrw: and what kernel are you trying to compile
<hrw> amitk: linux (2.6.34-4.11) maverick; urgency=low
<amitk> hrw: how soon does the build break? I've started one now, no problems
<hrw> amitk: did not checked but took some time - kernel got built first
<amitk> (building modules now)
<amitk> hrw: in any case, it is a problem on your side since we've got work arm kernels built on buildds in the archive
<amitk> *working
<hrw> ok
<hrw> amitk: sure, cross != native so problems can exists
<hrw> and I am fine with it
<amitk> hrw: we'll know soon enough, I'm building cross using your commands above
<mpoirier> smb: https://wiki.ubuntu.com/StableReleaseUpdates
<amitk> hrw: confirmed the problem you are seeing with libelf with cross-compiling
<smb> mpoirier, https://edge.launchpad.net/ubuntu/+source/linux/2.6.34-5.12/+build/1762187
<smb> https://edge.launchpad.net/ubuntu/+source/linux/+publishinghistory
<TeTeT> smb: thanks for your quick answer, I'll see if we need to escalate this or can solve it with the customers repo
<smb> TeTeT, Ok, thanks. I think at least we should be aware of the implications beside the driver module
<hrw> have a nice rest of day
<TeTeT> smb: the customer has a blob from Lenovo for the firmware and they can use that internally. I'll talk to my Lenovo contact and see if there's a chance to ship it
<smb> TeTeT, I would also keep Pete informed as he kind of tracks the legal side
<TeTeT> smb: no worries, if we pursue this, it's going through the proper escalation channels
<smb> Ok, cool
#ubuntu-kernel 2010-06-01
<Kano> hi, it seems aufs2 crashes with 2.6.34, could somebody update it
<Kano> seems like it was updated 10h ago
 * abogani2 waves
<smb> Good $TOD
 * apw waves to smb
 * smb waves back
<ericm|ubuntu> smb, tried a trivial merge of LSP 5.1.1 into mvl-dove, it's OK, so the merge conflict happens when rebasing mvl-dove onto master?
 * ikepanhc waves
<lag> Morning :)
 * ericm|ubuntu waves to all
 * amitk waves east and west
<smb> ericm|ubuntu, It happened when I tried to either merge your branch into my security branch of mvl-dove and the same happened when I tried to export and import the patches
<ericm|ubuntu> smb, where's your security branch of mvl-dove?
<ikepanhc> eh, I remember I do not identify for my nick, why I can speak here?
<smb> ericm|ubuntu, Thats the repo I gave you in my mail
<apw> ikepanhc, we had that fixed
<ericm|ubuntu> smb, OK - let me try again
<ikepanhc> yeah, I think so
<ericm|ubuntu> apw, that possibly means I can use ericm again, let me try
<ericm> haha
<smb> ericm|ubuntu, I have not officially pushed because I always fear last second changes. So I wait until its out
<ericm> as long as that 'ericm' isn't here
<ericm> smb, no problem
<smb> apw, Speaking of changes. Do I need to point you to the important mails I sent you? :)
<apw> smb, always
 * smb tries to remember
<smb> apw,  One was about the sync problem with ext4 (or better block layer in general)
<smb> apw, Oh, one thing was not really as mail to you, but at some point we probably want to virtually sit together with abogani2 to speak about -rt and -preemt
<apw> smb, yeah though i am tooo sleepy at the mo
 * smb knows that feeling
<smb> I was up at 6am today to make an early visit to the tax agency to complete my declaration
<cooloney> apw: i met a question about our kernel module size.
<apw> smb gah that sounds vile
<apw> cooloney, s'up?
<smb> cooloney, Have you greeted it nicely?
<cooloney> apw: the size of module which was generated by 'make modules' is much bigger than the one in kernel package
<cooloney> what's up apw and smb, hehe
<smb> cooloney, You tried to strip it? 
<cooloney> apw and smb good morning
<smb> cooloney, mornin man
<cooloney> smb, no
<cooloney> hold on a sec
<apw> cooloney, yep it has full debugging symbols turned on; we make the debugging version and make -dbgsyms, then strip everything and make the normal .deb
<smb> cooloney, Default options are set to include debug info. which is stripped upon packaging
<cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# ls ./debian/build/build-omap4/fs/nfs/nfs.ko -lh
<cooloney> -rw-r--r-- 1 root root 5.7M 2010-06-01 13:34 ./debian/build/build-omap4/fs/nfs/nfs.ko
<cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# ls -lh ./debian/linux-image-2.6.33-900-omap4/lib/modules/2.6.33-900-omap4/kernel/fs/nfs/nfs.ko
<cooloney> -rw-r--r-- 1 root root 383K 2010-06-01 13:34 ./debian/linux-image-2.6.33-900-omap4/lib/modules/2.6.33-900-omap4/kernel/fs/nfs/nfs.ko
<cooloney> apw and smb, yeah, i guess so. which script in our 'debian' directory is responsible for that?
<smb> cooloney, I'd think the debian/rules.d/2-binary...
<smb> cooloney, You can just say "strip nfs.ko" and should get the same size
<amitk> hrw: the cross-compile fails because when we try to cross-build perf, the perf Makefile tries to test for capabilities (line 495 in http://paste.ubuntu.com/442658/)
<cooloney> smb: i checked that, but failed to find something related to that. 
<apw> cooloney, its in debian/rules/2-*
<apw> cooloney, search for INSTALL_MOD_STRIP
<smb> If the bcf does not censor that word...
<hrw> amitk: thx
<cooloney> apw: oh, sh*t, i missed that. thanks man
<apw> hrw you can skip making the tools package, do_tools=false something like that
<hrw> apw: thx too
<amitk> apw: perhaps we need a flag (CROSS_BUILD?) that skips that so that one can do _almost_ the entire build as a cross before upload?
<cooloney> smb: so interesting. i striped the .ko manually, but got a smaller one than the one in our package
<cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# arm-none-linux-gnueabi-strip ./debian/build/build-omap4/fs/nfs/nfs.ko
<cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# ls ./debian/build/build-omap4/fs/nfs/nfs.ko -lh
<cooloney> -rw-r--r-- 1 root root 249K 2010-06-01 15:37 ./debian/build/build-omap4/fs/nfs/nfs.ko
<cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# ls -lh ./debian/linux-image-2.6.33-900-omap4/lib/modules/2.6.33-900-omap4/kernel/fs/nfs/nfs.ko
<cooloney> -rw-r--r-- 1 root root 383K 2010-06-01 13:34 ./debian/linux-image-2.6.33-900-omap4/lib/modules/2.6.33-900-omap4/kernel/fs/nfs/nfs.ko
<apw> cooloney, so look in the kernel itself and find out what that INSTALL_MOD_STRIP option actuall does
<smb> Or it could be different compile options or optimizations
<apw> amitk, possible, though i tend to use an sbuild environment to do the final upload build tests
<apw> amitk, which can actually do the tools package
<amitk> fair enough
<ericm> apw, is sbuild capable of doing a cross-build on a PC?
<apw> ericm, yes, it uses qemu to do the execution in the chroot
<ericm> apw, ah I see
<apw> ericm, its not very fast, but rather faster than the H/W
<ericm> apw, btw - do you know who is maintaining the package libusb-0.1?
<ericm> or to whom to ask this?
<ericm> it looks like it's not been maintained though it's in main/ repo,
<amitk> no autosync from debian?
<cooloney> apw and smb, you guys are right, INSTALL_MOD_STRIP=1 will call 'strip --strip-debug' instead of 'strip'
<apw> ericm, there does appear to be a libusb-1.0 as well
<cooloney> so it the size is litter bigger than without '--strip-debug'
<ericm> I talked with smb yesterday, and so far got not much response to ubuntu-devel-discuss@lists.ubuntu.com
<ericm> apw, they are two different things, apparently libusb-1.0 is better but a lot apps still linked with libusb-0.1
<smb> The thing is that its likely a package which is only synced with debian
<ericm> smb, but it's in main/ repo, so this is true even for packages maintained in main/ (coming from debian?)
<ericm> there is a LP project page: https://launchpad.net/libusb
<smb> There is probably someone who got that package sort of on his list. But who and when that person looks...
<ericm> just curious if there is a team like us responsible for all the patches related
<ericm> and I've no idea who's maintaining those branches on https://launchpad.net/libusb
<ericm> though it does look like progressing
<apw> ericm, finally found the source package, seems to be being updated from debian
<apw> ericm, so its belongs to 'all coredevs' in ubuntu
<smb> apw, The fun patch is that two similar source packages one for libusb and another for libusb-1.0. Though both reference the same maintainer strings
<cking> morning
<ericm> cking, morning
<apw> moin
<cooloney> cking: morning
<smb> Hello cking 
<lag> Morning cking 
<ericm> smb, yeah that's nasty and there is a bug being discussed to deprecate libusb-0.1 with libusb-1.0 (the latter is believed to be better), but it seems to be a lot work
<smb> cking, I took the liberty of proposing you as my roomie for July. Hope this is ok with you
<cking> smb,  that's good with me - thanks!
 * cking needs to get ear-plugs - the gas pipes outside are being dug up and pneumatic drills are being noisy today
<smb> cking, No mumbling for you today
<kraut> moin
<cking> smb, probably not 
 * apw notes the 2.6.35 merge window is now closed
<hrw> apw: and according to phoronix tests 2.6.35 got performance regressions
<apw> hrw nice, how bad
<smb> Probably not too surprising for an rc1
<cking> http://www.phoronix.com/vr.php?view=14976
<hrw> ericm: most of apps which use libusb 0.1 can be built against libusb 1.0 or libusb-compat
<ericm> hrw, let me do some experiment
<hrw> ericm: we did such transision in openembedded
<ericm> hrw, ok
<ericm> hrw, I don't seem to find libusb-compat in lucid, is this the correct package name?
<ericm> hrw, or do I need to add some repo?
<hrw> ericm: I do not know is it at all in ubuntu
<hrw> ericm: libusb.sf.net basically
<hrw> ericm: http://www.libusb.org/wiki/LibusbCompat0.1 to be exact
<ericm> hrw, not even in universe
<hrw> 167 packages rdepends on libusb0
<ericm> hrw, looks like it's a huge task
<hrw> ericm: libusb-compat is drop-in replacement
<hrw> "As the compatibility layer implements the exact same ABI and API, no modifications to existing libusb-0.1-based applications are needed. You do not even have to recompile them. This compatibility layer is a drop-in replacement. "
<ericm> hrw, en - looks like no debian package existing yet, need to first debianize it first
<hrw> it uses autotools so easy task
<hrw> depends only on libusb-1.0-0, has pkg-config and libusb-config
<abogani2> apw: Is ubuntu/ubuntu-lucid.git the official tree for Abstracted Debian (https://wiki.ubuntu.com/KernelTeam/AbstractedDebian) ?
<abogani2> apw: Is ubuntu-lucid.git the official tree for Abstracted Debian ( wiki.ubuntu.com/KernelTeam/AbstractedDebian ) ?
<apw> abogani2, the current versions in lucid and maverick are basically the same
<abogani2> apw: These instructions (https://wiki.ubuntu.com/KernelTeam/AbstractedDebian section "How to Make a New Branch") said that we need to execute "sed -i -e 's/debian.master/debian.mybranch' debian/rules".
<abogani2> apw: Why not simple replace "debian.master" in debian/rules (at lines 59 and 60) with $(DEBIAN) ?
 * apw looks
 * abogani2 shudder every times see someone using the sed's -i option...
<apw> abogani2, ok that sed is just not needed any more, or wouldn't be if those masters wern't there which is just a bug
<abogani2> apw: Ok. Sorry for disturb.
<apw> abogani2, not at all, i'll get it sorted.
<stenten> Which mainline kernel branch should people use for testing kernel bugs? /current?
<apw> stenten, /current represents the very latest build from linus' tip
<apw> stenten, i might suggest the latest release tag, 2.6.34 first as that is more likely to be stable
<apw> than the first -rc of 35
<stenten> ok, thank you.
 * cking wonders how good Czech airlines are...
<amitk> cking: the planes won't fall out of the sky
<cking> amitk, that's comforting to know
 * cking sees that amitk does his twice yearly blog post yesterday.. ;-)
<amitk> cking: :) I don't get peeved easily, this was one such incident
<cking> i can understand that
<tseliot> apw, smb: hi, do you know how to generate a directory in debian.master/abi/ for my customised kernel?
<tseliot> instead of passing skipabi=true
<apw> tseliot, you can just create echo "1" >debian.master/abi/<version>/<arch>/ignore and ignore.modules
<apw> for each build arch
<tseliot> apw: ah, thanks
<tseliot> apw: it looks like the "clean" target in debian/rules removes that directory
<tseliot> rm -rf debian.master/abi/2.6.32-22.33ppa1
<apw> tseliot, remember you need to fill in the _previous_ version number
<apw> fdr printenv should tell you the version it thinks is previous
<tseliot> apw: where do I fill it in?
<tseliot> debian/rules?
<apw> tseliot, no i meant you need to add the abi information to the previous version not the current version
<apw> the abi comparison is with the previous ABI, so it deletes and recreates the new one as you noted.  but the check is between the generated new one and the previous one
<apw> and its there you need the ignores
<tseliot> apw: aah, ok. Let me try again
<mdz> I've got 50%+ CPU going to the "events/1" kernel thread, and many short periods of unresponsiveness
<mdz> this just started today
<mdz> any advice for how I could track this down?
<mdz> (this is lucid + proposed updates)
<apw> events/1 is a general purpose thread, you might be able to get an idea of what it is doing with sysrq-l
<apw> mdz ^^
<cking> apw, that means any misbehaving driver or H/W could be the culprit?
<apw> or indeed anything yes
<cking> maybe worth looking at /proc/interrupts to see if any H/W is producing spurious interrupts then?
<mdz> apw, thanks. call trace -> http://pastebin.com/6DYtVDpf
<mdz> has e1000e in it
<mdz> which has nothing plugged into it at the moment
<mdz> (and hasn't for over a week)
<mdz> cking, nothing untoward in /proc/interrupts that I see; eth0 is only firing once every 5 seconds or so
<apw> mdz, is it consistantly doing the same thing ?
<mdz> apw, a few sysrq-Ls in a row all show similar call stacks
<cking> maybe also sanity checking this with ftrace function call tracing, http://www.mjmwired.net/kernel/Documentation/trace/ftrace.txt
<cking> echo 1 > /proc/sys/kernel/ftrace_enabled
<cking> echo 'function_graph' > /sys/kernel/debug/tracing/current_tracer
<cking> cat /sys/kernel/debug/tracing/trace > trace.log
<apw> mdz, there does appear to be up to a second long loop in there for h/w interlock, though i might expect some diagnostics in dmesg abuot it
<mdz> cking, that gives me a 2M log that I'm not sure how to interpret
<mdz> apw, dmesg is pretty clean apart from the sysrq spam
<mdz> dmesg |grep e1000 is all normal stuff
<mdz> cking, it's mostly browser and Flash plugin wakeups, i915 activity and the like, though I do see similar e1000 activity in there as well
<mdz> cking, should I send it to you?
<cking> mdz,  I may be able to spot something, so, yes, please send it to me
<mdz> cking, you should have it now
<cking> ok
<vish> hi , i was asked to report a bug upstream , https://bugzilla.kernel.org/show_bug.cgi?id=16077 , not sure if i reported in the right component , could someone check?
<ubot2> bugzilla.kernel.org bug 16077 in webcam "Drop is video frame rate in kernel .34" [Normal,New]
<cking> mdz, I cannot see anything glaringly obvious from that :-(
<cking> just a load of chrome + flash activity really
<abogani2> Is there a way to turn off temporarily the kernel's bugs mail notifications?
<smb> vish, It looks reasonable to me
<vish> smb: thanks
<smb> abogani2, I don't think so. Why? I guess most of them you get automatically though the team subscription...
<hrw> re
<Kano> hi, when will aufs2 refreshed in the .34 kernel? it does not work at all
 * ogra doubts that will happen at all for .34
<apw> i had a look and there doesn't seem to be any big changes from .32 to .34
<ogra> apw, wasnt there a spec to fix that once and for all in .35 ?
<apw> as there are changes for .35 compatibility i don't see it changing before A1
<apw> ogra, union-mounts you mean, that depends on functionality testing
<ogra> ah
<apw> i presume aufs works enough for the live-cds as noone has mentioned them not working
<Kano> i created a live image, it did not boot, but crashed aufs2
<apw> hrm
<apw> Kano, bah, seems that we only made the first one last night, and hit the same issue
<Kano> i created my own yesterday too and therefore i know that it does not work
<ogra> Kano, known, use union-fuse
<Kano> ogra: thats too slow
<ogra> thats what we'll use in A1
<Kano> like your first images without aufs, i patched it back, even modified an u image, was more than twice as fast
<Kano> aufs2 for .34 does not build externally - maybe some changes are needed
<bmf> Cheers everyone. I'm not sure if this is the right place but I've been searching and can't seem to get  to a conclusion... Does anyone know of a known bug with the suspend/resume on Core i7 (arrendale) + intel GMA HD platforms?
<cking> bmf, I've only seen a weird hibernate/resume bug on i7 CPUs, but that's fixed now
<bmf> Well... I have a HP EliteBook 8440p and it seems to suspend just fine... but when I try to resume it just sits there with the fan on and the leds on... but the screen stays all black... I've had more problems with this laptop than I've had in the last 10 years :P
<cking> bmf, have you tried kernel boot parameter acpi_sleep=sci_force_enable?
<bmf> no, I have not... let me try it give me a minute
<mdz> cking, apw, is there anything else I can try to track down this events/1 activity? my palms are sweating from the heat :-)
<bmf> cking: the behaviour is the same... black screen on resume
<cking> mdz, was this just from a kernel update and nothing else?
<mdz> cking, not even a kernel update. it's been two days since I rebooted, and the problem only surfaced this morning.
<mdz> I'm running 2.6.32-22-generic #33-Ubuntu
 * cking is a stumped - apw any ideas?
<apw> hrm, its so hard to be sure, the routines showing up look like a wait is ongoing, which is kinda a cpu spin waiting on the TSC value
<apw> mdz did you try inserting a cable (if thats an option)
<bmf> cking: suspend to hard drive appears to work properly tho... Do you think I should post a bug report?
<cking> bmf, yep, I would
<JFo> bmf, drop me the bug number once you have it
 * cking reflashes a laptop - wish me luck
<bmf> erm... I have to say I have never reported a bug before... what info should I include apart from the problem description?
<apw> bmf use 'ubuntu-bug linux' if its a kernel bug ... it knows the basics to collect
<bmf> I have a patched kernel (for other, known, kernel problems with my hardware... that'll teach me not to buy bleeding edge) is that a problem?
<cking> bmf, makes it possibly harder to diagnose and debug
<bmf> cking: aha! just noticed something
<bmf> if I remove the module ricoh_mmc the resume works "almost" fine
<cking> bmf, what's that?
<bmf> except for the fact that the laptop's screen brightness is 0 after resume
<smb> lag, git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.33.y.git
<smb> lag, That would be the git repo for 2.6.33.y. replace the 33 with 32 or whatnot for the other stable trees
<smb> msg lag That is an example of a random patch in the 2.6.33.y tree: commit 2b5a5d1697b2d4a96428ac6439b1d81660de379c
<smb> Author: Herbert Xu <herbert@gondor.apana.org.au>
<smb> Date:   Mon Apr 26 09:14:05 2010 +0800
<smb>     crypto: authenc - Add EINPROGRESS check
<smb>     
<smb>     commit 180ce7e81030e1ef763d58f97f9ab840ff57d848 upstream.
<bmf> cking: then I have to do an echo 100 > /proc/acpi/video/GFX0/DD02/brightness
<cking> bjf, well, it may be worth adding that module into the MODULES=  list in /etc/default/acpi-support
<cking> bmf, ^^
<bmf> yeah I was just reading about that same file
<bmf> any idea about what I can do about the brightness? =P
<cking> bmf, not from anything I can recall at the moment
<bmf> cking: thanks anyway :) i'm happy just knowing that it DOES resume... setting the brightness seems to be a smaller problem
<tgardner> lag, have a look at Documentation/stable_kernel_rules.txt in the kernel repo.
<manjo> good morning all
<amitk> morning dude
<manjo> how are you amitk 
<bjf> moin
<amitk> hanging there
<manjo> moin bjf
<manjo> network manager icon dissapeared for me after an update 
<ericm_> smb, rebased on top of your security tree, please try repull
<smb> ericm_, will do
<tseliot> does anybody know why I'm getting this error when building a kernel? http://pastebin.ubuntu.com/442829/
<tseliot> I can't find class_attr_version anywhere. Maybe it's something that's created by the preprocessor?
<smb> tseliot, I'd more concentrate on the previous error
 * cnd has to go retrieve a handbag my sister left at a restaurant when she visited yesterday, be back in an hour or so... *sigh*
<smallfoot-> why there is no 2.6.35-rc1 in ppa?
<tseliot> smb: that error makes little sense to me. Here's the full file: http://pastebin.ubuntu.com/442834/
<smallfoot-> hey you assholes
<smallfoot-> why the hell didnt you put 2.6.35-rc1 in the kernel ppa?
<tseliot> Keybuk: troll ^^
<smb> tseliot, Seems like one of these things that make only sense when you make it leave the precompiled versions
<tseliot> smb: what I did is replace drivers/gpu and include/drm with the ones from a more recent git branch
<Keybuk> tseliot: what do you want me to do about it? :)
<tseliot> Keybuk: a kick in the butt? ;)
<Keybuk> tseliot: you want an IRC Op for that
<smb> tseliot, The CLASS_ATTR_STRING likely expands into some struct probably containing the other part it complains about later.
<tseliot> Keybuk: ok
<smb> tseliot, Maybe that did not exist in the older sysfs definitions
<tseliot> smb: ok, I'll check that, thanks
<tseliot> aah, they used CLASS_ATTR instead of CLASS_ATTR_STRING
<tseliot> smb: thanks a lot
<smb> tseliot, No worries, I was just pointing a bit. :)
<JFo> apw, you have ops in here yes?
<bjf> JFo, i do, what you need?
<JFo> please read back comments from smallfoot- 
<bjf> ack
<JFo> thx :)
<apw> he seems to have gone quiet
<apw> hardly worth your energy
<JFo> yes, but there are ways to behave
<JFo> and that isn't it
<cking> 'twas an interesting contribution to the channel
<tseliot> :-D
<cking> it only applied to ***holes, so it got ignored I suppose
<JFo> :) which is of course why I noticed it ;0
<bjf> ##
<bjf> ## Kernel team meeting in two hours
<bjf> ##
<apw> JFo, indeed ...
<JFo> :)
<apw> cking, its an irony that there was a locking problem and builds not occuring
<smallfoot-> kernel meeting in 2 hours?
<smallfoot-> then put 2.6.35-rc1 in ppa
* apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - June-01 - 17:00 UTC
<lag> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=search&h=HEAD&st=commit&s=GYR4101US
<lag> smb -^
<achiang> how does one reset a file in bzr?
<achiang> in git, i just say "git checkout foo.c"
<achiang> ah, bzr revert foo.c seems to work
<cking> yay, my SPAM filters are now behaving themselves after 4 days of training
<Keybuk> someone's been doing spam runs with my e-mail address
<Keybuk> I had thousands of "Undelivered mail" type mails in my INBOX today
<cking> my filters marking 98% of my mail as junk last week - very annoying
<mjg59> Keybuk: As long as you always use the same smarthost, that's a solved problem
<Keybuk> how is it solved?
<mjg59> BATV or similar
<Keybuk> shall have to look into that
<mjg59> You tag each outgoing envelope from with a hash
<mjg59> And then drop any mail with a null envelope from unless it's to a valid hashed address
<Keybuk> *nods*
<Keybuk> I guess it's easy to add to exim?
<mjg59> Yup
<mjg59> There's a couple of tutorials
<mjg59> I've been using it for a couple of years - the only proble is ezmlm, which looks at your envelope from rather than your From: to decide whether you're a list subscriber
<Keybuk> and I guess it doesn't matter that the replies are deliverered via canonical's mail server, whereas mails from me are sent through my own?
<mjg59> Ha. That kind of matters, yes
<Keybuk> :-(
<mjg59> You need the outgoing server and the incoming server to agree on the hash salt, otherwise it won't work
<mjg59> If you have localpart suffixes or prefixes, you could probably put the hash in there and filter locally
<mjg59> The C mailserver should just pass them through in that case
<ogra> amitk, http://paste.ubuntu.com/442850/ so where's my kernel ? 
<ogra> amitk, (we have bootloader packages for XM now)
<kassah> how long does it ussually take for a kernel patch to go from proposed to production? days/weeks/months? ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/511066 )
<ubot2> Launchpad bug 511066 in linux (Ubuntu Lucid) (and 1 other project) "ModemManager: HP ev2210 Sierra MC5725 not detected (affects: 2) (heat: 16)" [Low,In progress]
<kassah> to stable I guess would be the better word for it
<cking> urgh, the gas board have dumped a load of soil on my path/lawn. back in 10
<smb> kassah, Thats still queued to be uploaded after the security release, which unfortunately took longer than expected
<kassah> smb, got an estimate? I'm about to go on a trip... trying to guage if I should wait since it'll be out anyway... or if I need to drop in the proposed kernel on my laptop for the trip.
<kassah> smb, honestly I'm still amazed at how fast the bug has progressed =) I'm not in a rush to push it out... just an information finding mission =)
<kassah> I just need it on the 5th =)
<smb> I *might* get uploaded next week, if this is the patch I am thinking is in. Then likely needs good testing in proposed. But I cannot say for sure
<kassah> sounds like I should just hunt down the proposed kernel and do that =)... thanks
<kassah> this patch is just for adding a usb id
<kassah> so not really sure how much more testing I could give it
<smb> Its not only about that one. You would test that the modem works. But there are a bulkload of other patches pending and it needs some time after uploading that to porposed to get a feeling whether there are probably regressiosn in it
<kassah> ah! =) makes sense =)
<JFo> ogasawara, you around?
<ogasawara> JFo: yep
<JFo> please see pw :)
<bjf> ##
<bjf> ## Kernel team meeting in 55 minutes
<bjf> ##
<mdz> apw, cking, should I give up and reboot it then?
<cking> apw, ^^ any further ideas?
<mdz> apw, oh, missed your earlier message
<mdz> I can try connecting a cable, but it's not trivial and involves installing a battery (and waiting until the end of my work day)
<apw> hrm, that sounds annoying.
<jjohansen> bjf: did I send status to you for the meeting, I won't be there
<bjf> jjohansen, nope (at least i didn't see it)
<jjohansen> bjf: hehe, nope let me rephrase should I send to you :)
<bjf> jjohansen, please do :-)
<jjohansen> alright
<manjo> bjf, meeting in 30mts ? 
<jjohansen> manjo: more like 38
<bjf> manjo, yes, I've already announced it twice this a.m.
 * manjo scrolls back
<manjo> ah
<manjo> I was on my laptop earlier
<lapion> think there is definitively something wrong with the hangcheck timer code of the i915 driver. Seeing as a hangcheck can be provoked by simply overstressing other functions of the chipset, such as the hdd
<lapion> *hdd-controller
<kees> ogasawara: yeah, let me know what I can do to help with bug 587888.
<ubot2> Launchpad bug 587888 in linux (Ubuntu Maverick) (and 1 other project) "aufs oops in au_do_open() on maverick live system boot (affects: 3) (dups: 1) (heat: 24)" [Critical,Triaged] https://launchpad.net/bugs/587888
<apw> ogasawara, i am lookign at that now
<apw> though i suspect we are not not going to be usinf aufs for a1
<ogasawara> apw: ack. thanks for taking ownership of that.  is union mounts looking like a proper alternative?
<apw> ogasawara, too early to say at the moment
<apw> though the effort i am putting in now is teaching me how to do the testing needed for union-mounts
<mpoirier> https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
<jjohansen> bjf: you get my mail
<bjf> yes
<jjohansen-afk> good
<jjohansen-afk> see you tomorrow
<ogasawara> manjo: 796df74 UBUNTU: SAUCE: Added quirk to recognize GE0301 3G modem as an interface.
<ogasawara> Seems this should be submitted upstream
<manjo> ok will send it to stable
<manjo> ogasawara, had not realized I had done that patch :) 
<cking> bjf, I forgot to prefix my bios test weekly report with "Added:" - can you insert that into the report later?
<bjf> cking, email me with the exact text you want
<cking> bjf, will do
<mdz> cking, apw, rmmod e1000e stopped the spinning
<mdz> (that's the good news)
<mdz> the bad news is, a subsequent modprobe e1000e has given me a spinning modprobe
<mdz> which I can't kill
<apw> mdz that sounds bad
<mdz> hey, it stopped
 * mdz rmmods again and leaves it that way
<manjo> JFo, what time is our mumble on bugs ? 
 * cking goes for food after 9 hours debugging suspend/resume issues
<JFo> manjo, nowish
<apw> ogasawara, will be off to make some dinner, if you urgently need me, ping my mobile
<ogasawara> apw: ack
<ogasawara> apw: just going to do a quick test build on i386 and amd64 and then will upload
<apw> ogasawara, i'd be pleased to see some touch testing that i didn't break anything else ... so that sounds ideal
<ogasawara> kees: will you be around for the next hour? wouldn't mind having you do a quick test on the kernels I build
<ogasawara> kees: this is in context to an aufs update we're doing
<kees> ogasawara: yup, should be.
<ogasawara> kees:  you're on amd64?
<kees> ogasawara: yup
 * manjo off to get some lunch
<apw> ogasawara, that branch got to you ok ?
<cnd> kees: I'm curious about the ptrace changes and the fit over changing the behavior for devs
<cnd> what behavior exists today that this would prevent?
<cnd> my naivete says to just prepend sudo to strace and gdb
<kees> cnd: prevent which part?
<kees> cnd: right, that's one solution, but requireseducation
<cnd> kees: I'm just interested in hearing of any behavior that people do today that they wouldn't be able to with the change
<mjg59> Attach strace or gdb to running processes unless they have admin access
<cnd> is it *only* the need to run things as sudo that worries people?
<kees> well, one uncommon scenario would be a shared devel system where devs didn't have sudo
<kees> the concern is surprising people with the change
<elmo> cnd: err, so, I like to be able to attach strace/gdb to existing processes and I don't have root on *all* the boxes I have access to
<kees> in the shared system case the admin could just flip the sysctl, though
<elmo> it's not just a dev thing, it's also an SA thing
<kees> right
<cnd> kees: if I was on a shared system, could I execute a second shell, and use the top level shell to ptrace any processes in the sub shell?
<mjg59> kees: I'm still not clear how your use case isn't adequately dealt with by dropping CAP_PTRACE by default and then restoring it on an app by app basis
<mjg59> I mean, you do have this fine-grained security system and all :)
<kees> mjg59: i wouldn't want to give out arbitrary ptrace to everything
<elmo> blink
<elmo> kees: I thought mjg59 was suggesting the opposite?
<elmo> kees: i.e. give it to strace + gdb but nothing else
<ogasawara> kees: I think I may have dropped, http://people.canonical.com/~ogasawara/lp587888/amd64/  can you give that a quick test
<cnd> elmo: I think the problem is that gdb or strace could be used maliciously
<mjg59> So restrict anything with network access from running strace or gdb
<kees> elmo: giving strace/gdb cap_sys_ptrace means anyone who ran it would be able to ptrace anything on the system
<mjg59> kees: Uh. Anything on the system running as them, surely?
<elmo> kees: err, caps survive process exit and onto the user who spawned them?
<kees> mjg59: that only works when everything starts confined
<mjg59> Pretty sure this would all be trivial under selinux
<kees> mjg59: cap_sys_ptrace gives you the ability to ptrace _anything_
<elmo> oh, I see
<elmo> eww
<cnd> to me, I don't see why I *should* be able to ptrace any given process today
<cnd> so I think this approach makes the most sense
<cnd> but I admittedly no next to nothing about security
<elmo> cnd: ptracing processes is SA-101 
<elmo> even in situations you don't have root
<kiko> cnd, yo
<cnd> elmo: shouldn't you have root if you're doing high level SA though?
<cnd> kiko: hi
<elmo> cnd: depends on the situation; I've used strace and gdb plenty of times without invoking or even having root
<kiko> cnd, what touchpad do the dell latitude's have?
<mjg59> Hm. Yeah, the capabilities model here doesn't seem to map terribly usefully
<mjg59> Is AA really incapable of providing a default policy?
<cnd> elmo: ok, but did you *need* to ptrace in those situations and/or should you have had sudo access in those situations?
<kees> ogasawara: one sec
<cnd> kiko: no clue
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - June-08 - 17:00 UTC
<kees> mjg59: "user" caps would be niice here
<elmo> kiko: 
<elmo> kiko: synaptics ones, by and large, IME
<kiko> heya elmo 
<mjg59> kiko: Depends on the model
<mjg59> Some synaptics, some alps
<elmo> kiko: but I'm working from a very small sampling
<kees> mjg59: and yes, there isn't a concept of "default" for AA
<kiko> erg
<kiko> I meant touchscreen
<mjg59> kees: Huh. No wonder your life sucks :)
<kiko> that was a pretty royal freudian
<elmo> cnd: yes, I 'needed' to ptrace to fix the problems I was having.  as to having sudo access, the people who run those servers would say no :)
<kees> heh. AA is only a small part of my life
<mjg59> kiko: Some Synaptics, some ntrig
<kiko> cnd, I'm asking because ubuntu is known to run on them, and so maybe if the synaptics driver is coming along then it might be worth it
<mjg59> Uh. Actually probably no synaptics. Wacom or ntrig.
<kiko> mjg59, I've seen the n-trig ones, but I wanted to know if any were synaptics
<cnd> kiko: I'm guessing the MT driver you are referring to is the I2C driver
<kiko> cnd, I'm referring to your latest email on the subject ;-)
<cnd> they *may* be using that interface, but I'd like to have proof before we do anything with the driver
<cnd> I would bet that they are actually wacom or ntrig as mjg59 saod
<cnd> said*
<mjg59> synaptics are mostly common in embedded setups right now
<kiko> I know for a fact that there are n-trig models as I have seen and used one
<kiko> hmph
<cnd> kiko: yeah, we have ntrig drivers, and they work
<kiko> okay
<cnd> we have wacom drivers, and they work for single touch
<kiko> cnd, we can investigate what samsung and TI use on their reference hardware if that helps
<cnd> but not for MT
<cnd> kiko: the mobile team would probably be able to get that info faster I bet
<cnd> but I can ask them
<kiko> that doesn't mean that it'll apply to their actual OEMs but at least it's a step
<kiko> cnd, oh, I can ask samsung and TI myself!
<cnd> ok
<kiko> I'm just asking because those are the only companies I've seen that have touch reference hardware
<kiko> well, the only ARM SoCs anyway
<cnd> kiko: it wouldn't surprise me at all if such devices were using synaptics touchscreens
<kiko> we will find out
<cnd> cool
 * bjf will be back in a bit
 * bjf is back
<kees> ogasawara: that kernel fixes the aufs problem for me
<JFo> ogasawara, bug 588069 FYI
<ubot2> Launchpad bug 588069 in linux (Ubuntu) "Lucid kernel is missing a large number of important ext4 bug fixes (affects: 3) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/588069
<JFo> from Ted Ts'o
<apw> kees, that is excellent news, thanks for that
<kees> apw: thanks for the fix!  :)
<apw> kees, i am just glad it worked
<kees> magic! :)
<bjf> JFo, if it's lucid then it's smb
<ogasawara> kees: sweet, thanks for testing.
<apw> JFo, i've passed it through to the list for tommorow
<JFo> cool
<JFo> saw your response apw
<JFo> :)
<apw> it being kernel-fs
<JFo> yup
 * apw calls it a night
<ogasawara> JFo: for bug 288069, probably best to get it on smb's radar as it's for Lucid
<ubot2> Launchpad bug 288069 in evolution (Ubuntu) "Calender seems to follow US DST, not local timezone's DST (dup-of: 281956)" [Low,Invalid] https://launchpad.net/bugs/288069
<ubot2> Launchpad bug 281956 in tzdata (Ubuntu Hardy) (and 3 other projects) "evolution uses wrong date to switch to daylight saving timezone in timezone Europe/Brussels (affects: 3) (dups: 3) (heat: 54)" [Low,Invalid] https://launchpad.net/bugs/281956
<JFo> ogasawara, yep yep
<JFo> errr
<JFo> hmmm
<JFo> you mean 588... ;)
<ogasawara> JFo: oops yep, typo
<JFo> hee hee
<tgardner> ogasawara, I'm getting close on the virtual flavour size shrink.  I'll try to post something later tonight.
<ogasawara> tgardner: cool, thanks
<tgardner> time for a bike ride
<bjf> pgraner, has something happened to voices.canonical.com? I can't seem to add a blog entry
<bjf> ogasawara, I took a quick look at those ext4 patches from the bug JFo mentioned, there are 57 patches in it and some are non-trival :-(, I'll talk to smb about them
<ogasawara> bjf: yuck, sounds messy
 * ogasawara punched launchpad in the face
<ogasawara> s/punched/punches/
#ubuntu-kernel 2010-06-02
<bjf> pgraner, nevermind, seems to have fixed itself
 * apw waves
<amitk> hey apw 
<apw> morning amitk hows it going?
<amitk> fleshing out specs and pushing pending patches upstream
<amitk> you?
 * smb good mornings the channel
 * amitk good mornings smb
<smb> hi amitk 
<amitk> .. and adds "morning" to webster's dictionary as a verb
<cooloney> apw and amitk smb, good morning guys, what's up
<smb> cooloney, I am (more or less) :-P
<apw> amitk, heheh
<apw> smb, moin
<apw> cooloney, just fighting aufs2 and the liveCDs
<cooloney> smb: do we still have the kernel debug package?
<smb> apw, still?
<apw> smb, the fighting is now to ensure i've got and tested the right image
<smb> cooloney, you mean on ddebs.ubuntu.com?
<cooloney> so if we wanna to debug a module, we need a .ko with debug info, right?
<apw> i think its fixed
<apw> cooloney, symbols are often helpful
<smb> The only problem might be I did not upload lately
<amitk> apw: will union-mounts happen?
<smb> They would be there with the next security update
<apw> amitk, too soon to tell, i am waiting on testing of it
<apw> smb, i think lucid is the only one missing isn't it?
<apw> just due to luck
<cooloney> smb: since our kernel package including the module which were --strip-debug, how's the debug kernel package?
<smb> apw, Would need to check. I changed another one to the new format
<smb> apw, Might have been karmic
<smb> cooloney, Its packaged without strip
<apw> smb, yeah but last i looked there was .31 ones there
<smb> cooloney, http://ddebs.ubuntu.com/pool/main/l/linux/
<cooloney> smb: yeah, so that's for debugging. but i never use that before. this question comes from TI guys
<smb> cooloney, But if you need Lucid, it will take one or two more days
<smb> cooloney, The package basically contains the unstrippeped modules and the full vmlinux
<cooloney> smb: thanks a lot. cool, fully understand now
<cooloney> smb: if someone wanna debug the modules, he can install this debug kernel package, right?
<smb> cooloney, right, if they don't vanish again, which should not be the case, hopefully...
 * amitk recovers from hours of reading the "suspend blocker api" thread on LKML
<smb> An api to block suspend or one to find them?
<amitk> smb: an api to block suspend after enabling "automatic aggressive suspend" (called opportunistic suspend by Google)
<cooloney> apw: is there any way to build udebs from a source package?
<cooloney> apw: i can use sbuild to get udebs. is there another way?
<smb> cooloney, skip_dbg=false
<cooloney> i tried 'fdr binary-arch', but no udebs. 
<cooloney> smb: skipdbg=false for udebs?
<smb> err udebs
 * smb clear his glasses
<cooloney> smb: i think that is for debug package, right?
<smb> cooloney, Yeah, forget what I said
<smb> cooloney, I would not thinks so because you need the modules to be build to create packages with the modules referenced
<apw> cooloney, ok udebs are currently only enabled if you have /CurrentlyBuilding
<cooloney> apw: no idea what's /CurrentlyBuilding
<cooloney> apw: a directory which i need to create manually?
<smb> cooloney, Its a file
<apw> its possible that if you build binary-arch binary-udebs it will do it
<apw> but if you make /CurrentlyBuilding in the chroot, it will also build it
<smb> cooloney, sudo touch /CurrentlyBuilding in your chroot
 * cooloney finds using sbuild to native build my ti-omap4 source package is very fast in tyler.mills
 * apw adds _documenting_ and cleaning up the controls for all releases to his TODO
<cooloney> just 1 hr
<apw> cooloney, that sounds acceptable to me
<cooloney> smb and apw, yeah, does that work for cross compiling?
<cooloney> 'fdr binary-arch binary-udebs' works for cross compiling? 
<apw> the problem is if linux-tools is enabled it does not work
<apw> so yuo'll need do_tools=false at least to cross compile i think
<cooloney> apw, ok, no problem, i will try that.
<apw> cking, hey ... when filing bugs on iso testing, is there any special magic for that?
<apw> ie. how do identify the bugs so they can be found
<cking> apw, there is a field in the bug tracker as per test case to enter the bug number - this is all I do
<apw> cking, ok thanks
<cking> but there may be some tags that I don't know about
<cking> All the notes say is: "Please report any bugs you identify in Launchpad and report on the success or failure of the test in the tracker: https://launchpad.net/ubuntu/"
<cking> apw, you biting the QA bullet - cool!
<apw> cking, dipping a toe in the pool
<cking> see how many bugs you can find - I aim for 4 each spin - usually it ends up as stupid ones (e.g. broken eye candy) 
<ericm_> apw, I've added the link bjf mentioned in the reply to https://wiki.ubuntu.com/KernelTeam/MeetingHowTo for easier reference, hope that's OK
<apw> ericm_, ok
 * cking goes to get some H/W from the loft - back in 5
<cooloney> apw: just a quick feedback, 'fdr binary-arch binary-udebs' works fine with cross compile
<cooloney> it will give us all the udebs as well as kernel image and header packages in parent dir
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588643 => if somebody feels checking :)
<ubot2> Launchpad bug 588643 in linux (Ubuntu) "Lockup with stacktrace (native_smp_send_reschedule) (affects: 1) (heat: 6)" [Undecided,New]
<apw> cooloney, good
<dupondje> Some small queryion, could bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588643 be caused by an error in BIOS ?
<ubot2> Launchpad bug 588643 in linux (Ubuntu) "Lockup with stacktrace (native_smp_send_reschedule) (affects: 1) (heat: 8)" [Undecided,New]
 * apw returns 
<kraut> moin
<ogra> hmm
<ogra> looking at https://edge.launchpad.net/ubuntu/+source/linux/2.6.34-5.13/+build/1768097 we dont seem to build any omap udebs at all anymore
<apw> ogra, it seems unlikely we ever did
<ogra> we did with the topic branch in lucid
<ogra> (and we need them for netinst images)
<ogra> there seem to also be issues with the DSS code on a beagle XM
<apw> ogra, yep but omap in maverick is a complete rebuild
<ogra> i know
<apw> ogra, its a shame noone ever tests things when they go in, only the day before the milest
<ogra> i'm just examining the omap3 kernel now and note down issues i find :)
<ogra> i dont test because A1 is due :)
<ogra> we dont build A1 images for arm
<ogra> its just coincidence :)
<ogra> apw, btw, would there be a chance to not have the kernel produce an oops if it doesnt find its rootfs device and instead have it spit out a userfriendly error msg ?
<ogra> http://paste.ubuntu.com/443294/ is what i typically get if there is no rootfs device 
<apw> ogra, i thought it dropped to busybox
<ogra> not if you dont have an initramfs
<ogra> see the bottom of the paste
<apw> then its meant to tell you which things you have
<ogra> i seem to remember (from my pre ubuntu times) that it properly panicked and gave a useful error 
<apw> ogra, given that shows the card appearing the instant before it explodes i suspect this is not cause it doesn't find root
<ogra> i'm only using initramfs since ubuntu :)
<apw> when my root is missing i see a panic which ends with a list of the filesystems and devices available
<ogra> weird
<ogra> i get the panic since i use arm 
<ogra> actually i got used to have it but thinking about it i remember it was not always that way
<apw> from the panic i'd say that a timer is firing to flash the cursor, but the framebuffer didn't initialise
<ogra> yes, there are definately other issues with that kernel on the XM board i'm justy trying
<apw> [    2.365386] Waiting for root device /dev/mmcblk0p2...
<apw> [    2.385223] mmc0: new SD card at address aff7
<apw> [    2.390167] mmcblk0: mmc0:aff7 SU02G 1.89 GiB 
<apw> [    2.395141]  mmcblk0: p1 p2
<ogra> but i see the oops across all arm arches
<apw> from that you can even see that the disk was appearing, so its not at all clear its anything to do with root at all
<ogra> i also saw it on imx51 before or on dove when experimenting with SDs without rootfs and initrd
<apw> notice it dies here:
<apw> [    2.490692] LR is at cursor_timer_handler+0x34/0x38
<apw> that sounds very suspicious
<ogra> hmm
 * ogra unpacks a rootfs to the SD 
<apw> ogra, that callback seems to be the cursor flasher ... every half second
<apw> i think there is a bug in the omap fb which is leaving the cursor running when it fails to init
<ogra> yeah, you are right, i even get the oops with a valid rootfs in place
<ogra> the DSS/frambuffer code is a mess on omap i guess we will need a bunch of patches from the linux-omap tree to make it work
 * apw can't hear you :)
<ogra> (it doesnt work at all on the touchbook or zoom2)
<apw> i am somewhat intriqued who tested the image and what on, cause it was tested
<ogra> and apparently also on the beagle XM
<apw> i suspect just an official beagle is the only one supported
<ogra> it likely works on one of the older beagles
<ogra> XM is official
<ogra> zoom2 is official too but will need patches
<ogra> we agreed to support all these devices 
<apw> XM will be official at release, i am sure up to now we've not even had one
<ogra> AI touchbook would be a nice to have since its an actual ARM netbook out there
<ogra> apw, we have two in the company since about two months :)
<apw> ogra, and who has them ?
<apw> i bet noone who is doing the kernel work
<ogra> amitk had one for kernel, not sure where it went
<ogra> i have one as well
<ogra> and i think there were even more
<ogra> plars and jamiebennet used to have one each iirc but i'm not 100% sure
<ogra> i am sure about the ones amitk and i have though
<apw> shame that its eric doing the kernel work... ho hum
<ogra> heh
<ogra> erm, you mean bryan
<apw> possibly, the disconnect is the same
<ogra> he is doing omap4 atm 
<ogra> and he is doing it awesome :) without having HW at all i got a fully working kernel for my blaze board :)
<apw> then i suspect noone is doing it
<apw> ho hum
<ogra> i know mpoirier and lag are supposed to do omap 
<ogra> under leadership of cooloney and amitk 
<ogra> but cooloney is busy with omap4 for the special 10.07 release
<amitk> apw: ogra: The HW situation should improve soon(ish). We should probably revisit our HW allocations and get unused boards into hands of people that need them
<ogra> yeah
<dupondje> Now that there is some action here, could somebody tell me if http://dupondje.be/DSCF1025.JPG can be caused by a broken BIOS?
<apw> dupondje, hard to say as thats not the first panic
<cking> dupondje, if you could capture more of the first panic then we could say for certain - the trace before the apic timer interrupt would be handy
<apw> dupondje, the panic you do have implies a CPU is offline when we are not expecting it to be so, if its repeating then we are truly confused
<dupondje> I need full hd tv :P
<dupondje> used mainline kernel, and there it gives 'BUG: cpu soft lockup' ... :s
<dupondje> 2.6.34 as mainline kernel btw
<apw> Keybuk, hey ... did you get to do any testing on the init args kernels ??
<dupondje> to bad its not possible to scroll when the stacktrace is displayed 
<Keybuk> apw: not yet
<Keybuk> apw: I will be doing that today
<Keybuk> apw: while I can see items vanishing off my todo list, I feel like I'm not accomplishing much at the moment
<Keybuk> too much catch-up
<lag> http://webcache.googleusercontent.com/search?q=cache:EGSLAZNT6VwJ:www.pubbs.net/kernel/200907/83651/+"no+console+suspend"&cd=1&hl=en&ct=clnk&gl=uk
<apw> kernel/printk.c:__setup("no_console_suspend", console_suspend_disable);
<apw> Keybuk, i can only sympathise.  i had 5 items on mine, i've done 4 of them, but still have 6 to do for alpha-1 ... go figure
<apw> Keybuk, do you  know if you need special mount support for union-mounts ?
<Keybuk> yes
<apw> Keybuk, damn, i'll go look for those then
<Keybuk> I have that ready
<apw> Keybuk, ahh, if you have something i can slurp up i'll get it into the PPA as well
<apw> Keybuk, then i can go do some testing myself
<apw> Keybuk, actually it looks to be only two patches if i am reading Valerie's page correctly ... match your expectations?
<Keybuk> that would require me getting some time to actually sort the package out
<lag> BOOT_IMAGE=<blar> root=<blar> ro console=tty1 no_console_suspend quiet splash
<cking> lag,  it looks ok to me
<cking> remove quiet and splash too
<cking> mumble fail
<lag> It sounded like you were on a CB radio and you were transmitting via a piece of string prior to dampening 
<cking> lag, my audio is screwy after a suspend/resume cycle - dunno why
<cking> lag, console=tty is the normal default.
<ogra> cking, talk to a kernel dev 
<ogra> :)
<cking> "physician, heal thyself"
<JFo> "Hoist by me own petard."
<lag> JFo: Are you a fan of the great WS?
<JFo> I am
<lag> "Man does not live by bread alone"
<bjf> moin yall
<cking> hi bjf
<JFo> moin bjf
<JFo> from bug 571378
<JFo> Jun 1 16:42:23 warthog libvirtd: 16:42:23.833: error : udevStrToLong_ui:73 : Failed to convert '008' to unsigned int#012
<ubot2> Launchpad bug 571378 in linux (Ubuntu) "C-Media USB Headphone fails to enummerate (affects: 2) (heat: 10)" [Medium,Triaged] https://launchpad.net/bugs/571378
<JFo> looks like some udev failure?
<apw> JFo, well that has libvirtd in it as well
<JFo> ah yes
<apw> i'd tend to blame that first, and let them blame udev :)
<JFo> heh
<JFo> who owns that bit?
<bjf> JFo, moin, since we have maverick daily isos now, i'll work on producing daily maverick test isos (shouldn't take more than a minute or two)
<JFo> or rather those bits
<JFo> bjf awesome
<bjf> anyone know if emerald.pgraner is among the living?
 * cking notes that suspend/resume on maverick alpha 1 is very speedy on his old dell 6400
<Keybuk> apw: updating my laptop so I can install your test kernels
<JFo> is the Lucid bacport kernel going to be based on .34 or .35? I was thinking the latter.
<apw> Keybuk, i've run maverick kerenels on lucid no bother
<Keybuk> apw: laptop is at a broken mid-maverick point ;)
<Keybuk> updating to get it to boot again
<apw> Keybuk, ooosp :)
<apw> Keybuk, the 'text only' plymouth like screen (with four dots) is that part of plymouth as a package |?
<Keybuk> plymouth-theme-ubuntu-text iirc
<pgraner> bjf: I'm working on it
<pgraner> bjf: had to bandage a cut finger
 * ogasawara bails to dentist apt, back in an hour
<tgardner> JFo, the LTS backport kernel is tracking Maverick
<JFo> thought so
<manjo> smb, https://wiki.ubuntu.com/Kernel/Tagging
<jmfthevci> Hi all, anyone know the reasons behind the move of autoconf.h and utsrelease from the /usr/src/linux-headers-2.6.34-5-generic/include/linux directory?
<cking> manjo, box is on it's way - probably get to you by Friday
<jmfthevci> It caused VMware's tools script to die - vmware-config.pl
<jmfthevci> Took a bit of digging but found this: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc
<jmfthevci> Any comments?
<sconklin> hi folks, I'm bck from the conference and should be in the normal swing again
<JFo> woo hoo! welcome back sconklin 
<cking> lag: +CONFIG_USB_SERIAL=y
<cking>  +CONFIG_USB_SERIAL_CONSOLE=y
<cking> CONFIG_USB_SERIAL_CH341=y
<cking> CONFIG_USB_SERIAL_PL2303=y
<lag> I'm going to do it via the menu system
 * lag is looking
<cking> lag, I added them to debian.master/config/config.common.ubuntu
<lag> cking: Why CH341? Surely you mean CONFIG_USB_SERIAL_FTDI_SIO?
<cking> lag, you need to chose the appropriate driver ;-)
<lag> I thought there were only two in the UK?
<lag> FTDI and PLxxxx
<cking> lag, well, what ever is appropriate - I've got CH341 and PL2303 for some reason 
<bjf> JFo, something is busted building the maverick test isos (was working fine for lucid), am debugging 
<JFo> k
<manjo> cking, thanks for the box
<cking> manjo, it requires a US power lead - it did not come with one
<manjo> cking, I can get that
<cking> and I formatted it up to boot Karmic, so you can see it will work ;-)
<manjo> apw, you worked on some of the fan cntrl stuff, are we missing any modules for the sensors? (lucid/maverick) ?
<manjo> apw, what sensor modules need to be loaded ? 
<manjo> apw, when I run pwmconfig it says at the end /usr/sbin/pwmconfig: No sensors found! (modprobe sensor modules?)
<manjo> apw, sensors-detect tell me what modules .. never mind 
<apw> manjo, yep sensors-detect ... but even then sometimes there are none still
<dupondje> JFo: thanks for commenting my bug, by the latest upsteam kernel ? you mean the latest daily build on kernel.ubuntu.com? Or compile a fresh one from kernel.org ?
<JFo> dupondje, there is a MainlineKernels page on the wiki
<JFo> we build them so you don't have to :)
 * JFo goes to find the link
<dupondje> well i'll try it when i'm home :)
<manjo> tgardner, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/475641
<ubot2> Launchpad bug 475641 in linux (Ubuntu) "pwmconfig does not work after upgrade to 9.10 on TYAN server (affects: 2) (heat: 12)" [Medium,Triaged]
<dupondje> 2.6.34 gave 'BUG: soft lockup ...' :)
<dupondje> didn't try 2.6.35 yet
<JFo> hmmm
<JFo> dupondje, here is the link to all the info: https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds
<JFo> let me know how it goes :)
<dupondje> i'll do, and take some 'screenshots' ;)
<JFo> cool
<dupondje> its not possible to scroll up right ? cause if the error is to long, can't see everything then :s
<apw> dupondje, right no up scrolly
<dupondje> gotto ask full hd tv then :)
<lag> cking: Are you around?
<cking> yep
<lag> read 2675 modules : new(121)  missing(3)
<lag> EE: Missing modules (start begging for mercy)
<lag> make: *** [module-check-generic] Error 1
<cking> lag, gimme 5 - I've got to sort out the gas men again
<lag> k
<cking> lag, build with skipmodule=true I believe
<cking> lag, fakeroot debian/rules .... skipmodule=true
<lag> cking: Trying
<lag> :)
<cking> yet another rune to remember
<lag> :(
<lag> I already skip the abi test
<lag> Why doesn't it allow you to have any built-ins?
<cking> eh? skipmodule=true should work
<cking> see line 104 of debian/scripts/module-check - this is where it skips the missing modules check
<lag> I mean, why doesn't it allow built-ins by default
<jpds> Would anyone know why kdump wouldn't be working on a HP Z600 workstation?
<jpds> Or how to go about debugging why it isn't working?
<cking> lag, oh, I see. dunno
<akgraner> bjf, are you around
<bjf> akgraner, present
<akgraner> can you take a look at the the Kernel Team Meetings listed on the Fridge and let me know if the series is correct
<akgraner> if it is not can you let me know so I can get it fixed immediately :-)
<bjf> akgraner, is it on the front page?
<bjf> akgraner, give me a URL to what you want me to look at
 * manjo needs food.. goes to look in the kitchen
<akgraner> bjf, oh sorry let me get you the link
<akgraner> bjf, http://fridge.ubuntu.com/calendar
<bjf> akgraner, and from the calendar I do what? the calendar looks fine :-)
<akgraner> bjf, nothing if all the times are correct
<bjf> akgraner, 1700 UTC is the correct time, so that looks good to me
<manjo> apw, smb is balcony open ?
<smb> manjo, only if you have beer
<akgraner> ok noted that Tuesday -1700 UTC is the time for all Kernel Team Meetings unless I am told otherwise - thanks!
<bjf> akgraner, np
 * bjf will brb
<apw> mpoirier_, just to say i am still working on the omap udebs, its being truculant
<mpoirier_> apw: truculant is definitely a new word for me :)
<apw> and likely spelt wrong by me of course
<mpoirier_> no, i just looked it up - it is correct.
<apw> mad as it looks awful spelt that way
<apw> anyhow its being truculant, but i think i've nearly got it licked
<mpoirier_> fabulous.
<mpoirier_> in the mean time sbuild worked for me.
<mpoirier_> I can finally move on.
<mpoirier_> thanks for the tips.
<apw> mpoirier_, awsome
<mpoirier_> it took a bloody long time, even on tyler.mills.
<apw> Keybuk, hey ... how did your testing go ?
<apw> mpoirier_, arround an hour ?
<mpoirier_> is there a way to disable all the udebs except the one you are interesed  in ?
<mpoirier_> no, more than that.  I'll 'time' it next time.
<apw> if you are considering that to make things faster you won't gain anything, as the whole kernel being built is a pre-requisite to generate any udebs
<apw> mpoirier_, once i have this lot fixed I should be able to cross compile only one flavour and generate udebs for it
<apw> which for me here takes about 20 mins
<mpoirier_> ok, it will be even faster on tyler.
<mpoirier_> it's worth the wait.
<apw> if i haven't killed it by then
<Keybuk> apw: it hasn't happened yet
<Keybuk> apw: your initargs kernel didn't build, so there's no deb to try
<apw> Keybuk, crap will sort that out
<Keybuk> did the "was used" patches end up in the maverick kernel?
<apw> Keybuk, nope not yet
 * apw adds to todo
<Keybuk> k, if you want to go via ppa first, that's fine :)
<apw> yeah sounds like a plan
<JFo> kro, off to grab a bit of lunch
<JFo> err ok
<jjohansen-afk> -> lunch
<apw> ogasawara, you abuot ?
<ogasawara> apw: yep
<apw> yo ... are you doing the -rc1 rebase 'next' ?
<apw> as i am reminded it will need an aufs update before it will build right
<ogasawara> apw: was just starting
<apw> so as soon as you have the base rebase, perhaps you can push it somewhere i can get to it
<ogasawara> apw: just squashing debian commits as we speak
<ogasawara> apw: ack
<apw> and i'll do the update for aufs in the morning on top
<apw> wicked :)
<JFo> ogasawara, bug 587444 looks interesting
<ubot2> Launchpad bug 587444 in linux (Ubuntu) "Wrong dependency in linux-headers-2.6.34-x-generic (affects: 4) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/587444
<ogasawara> JFo: will take a look in a sec
<JFo> kro, np
<JFo> sigh*
<ogasawara> JFo: ah, that seems one for tgardner as it's the maverick lts backports
<JFo> ah right you are
<tgardner> I can live with that
<JFo> sorry to interrupt you :)
<tgardner> JFo, wtf is that marked high? its not even a released package
<JFo> heh
<JFo> I apparently hit the wrong one
<JFo> meant for medium
<JFo> second time I have done that today
<JFo> first one I caught as it happened
<tgardner> JFo, nominate for Lucid and assign me so I don't forget
<JFo> kro, will do
<JFo> why does that keep happening
<JFo> ah, it is tab completing
<JFo> yep, automatic nick completion was checked
<JFo> sorry about that kro 
<JFo> tgardner, done
<JFo> cnd, looks like you could get a nice chunk of change to resolve bug 576601
<ubot2> Launchpad bug 576601 in linux (Ubuntu) (and 1 other project) "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected (affects: 79) (heat: 462)" [High,Triaged] https://launchpad.net/bugs/576601
<JFo> http://www.cofundos.org/project.php?id=187
<cnd> JFo: heh, upstream looks like they're getting involved
<JFo> cool
<dupondje> JFo: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588643 => was able to get a dmesg output when it got locked
<ubot2> Launchpad bug 588643 in linux (Ubuntu) "Lockup with stacktrace (native_smp_send_reschedule) (affects: 1) (heat: 8)" [Undecided,Incomplete]
<JFo> excellent!
<dupondje> need to mark the bug as New again ? or you change status ? :)
<smoser> hey all.
<smoser> lets just pretend that i had a hardy xen domU running 2.6.24-24-xen
<smoser> what would be the most reasonable way to get ext4 filesystem support for that pretend guest
<JFo> dupondje, I have changed it
<JFo> I was reading over the bug
<dupondje> any idea what could be causing it ? could it be an instable BIOS version ?
<tgardner> smoser, I don't think you can. ext4 did not exist for 2.6.24 IIRC
<smoser> well, it does exist. its there.
<smoser> at least ./Documentation/filesystems/ext4.txt
<smoser> its just likely old and buggy
<tgardner> smoser, its was probably a preview and marked EXPERIMENTAL
<smoser> yes
<dupondje> JFo: also notice the segfaults, seems like some apps segfault randomly also :s
<JFo> dupondje, not sure what could be causing it. odd that some apps are segfaulting randomly
<dupondje> its totally random also 
<dupondje> happens since I changed CPU and did BIOS upgrade ... but before it was a single core, now quad .. so
<jjohansen> smoser: define support?  You could build the module externally, but no one will provide any kind of support for ext4 on 2.6.24
<smoser> i need it to work.
<smoser> i'm guessing reasonable ext4 support is not backported that far back.
<smoser> the driver in 2.6.24 will probably compile and maybe even work.
<smoser> right now our UEC images build system is running the aforementioned kernel version, and I want to build images with an ext4 filesystem, which requires mounting said filesystem.
<jjohansen> I don't think reasonable ext4 support for 2.6.24 is viable
<jjohansen> you should be able to compile the fs and have it mostly work
<jjohansen> there will be bugs (ext4 still has bugs)
<manjo> smoser, make sure you have latest bug fixes for ext4, lucid kernel is missing those too, Bug #588069 
<ubot2> Launchpad bug 588069 in linux (Ubuntu) "Lucid kernel is missing a large number of important ext4 bug fixes (affects: 4) (heat: 24)" [High,Triaged] https://launchpad.net/bugs/588069
<jjohansen> manjo: I doubt those will even come close to applying to .24 era ext4
<manjo> jjohansen, I assumed smoser was going to backport... never mind then
<smoser> manjo, i was assuming you had volunteered to backport for me
 * manjo ducks and hides
<smoser> make sure that you get those latest patches :)
<smoser> thanks all, i got somewhat what i expected.
<kamal> mjg59: Hi -- A few weeks ago you proposed overriding the often-busted ACPI brightness control with an i915 opregion-based method -- I have implemented such a scheme -- are you available to talk about it?
<stenten> Can someone help me finish triaging Bug #587136?
<ubot2> Launchpad bug 587136 in linux (Ubuntu) "2nd Resume from Suspend results in reboot on Toshiba Satellite U400. Fixed in 2.6.34 Mainline. (affects: 2) (dups: 1) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/587136
<stenten> Since it's a suspend/resume bug, there's absolutely no debugging information in the logs, and I'm at a loss of what else to ask for. What should the Status be in that case?
 * JFo looks
<mjg59> kamal: For a few minutes, sue
<kamal> mjg59: For review:  http://kernel.ubuntu.com/~kamal/i915bri~3e/
<kamal> It works very well on two out of three laptops I've tested, but on the third laptop the i915 method silently fails (its a "GM45" card -- pci-id 0x2a42 ... IS_I915G() and IS_GM45() are true).
<kamal> Perhaps you might have a look at the patch and/or scratch your head about why it doesn't work on that GM45?
<JFo> stenten, he is on server?
<JFo> may not be easy to test, but the mainline kernel testing would be nice
<JFo> if he is willing and this isn't production
<JFo> other than that, it looks almost ready
<stenten> He's on a Toshiba laptop.
<kamal> mjg59: fyi, same patch in a git tree:  http://kernel.ubuntu.com/git?p=kamal/ubuntu-lucid.git;a=shortlog;h=refs/heads/i915bri-3e
<JFo> hmm
<stenten> And he's already tested with the 2.6.34 mainline, and the problem is resolved.
<JFo> stenten, all that is left is proper tagging fos subsystem
<JFo> have you seen https://wiki.ubuntu.com/Kernel/Tagging ?
<JFo> for the subsystem tags?
<stenten> We got all the way to the RTC overwrite part in debugging, but he has questions in Comment #10 that I'm really not qualified to answer.
<JFo> cool
<mjg59> kamal: Mm. Could be that the gm45 case is broken somehow.
<JFo> stenten, so this one needs the kernel-power tag and the kernel-needs-review tag
<mjg59> kamal: That's broadly what I was thinking though, sure
<JFo> stenten, then it will be all set
<stenten> JFo: Just saw that today (in your email actually). Tag it as 'kernel-power' and mark as Triaged?
<JFo> yep
<mjg59> kamal: I think it's worth posting this upstream, if only to try to find out if anyone's got a better idea
<JFo> don't forget the kernel-needs-review tag
<JFo> that way it gets on the radar from monday
<JFo> stenten, ^
<stenten> Is 'kernel-needs-review' the part that tells you it needs a dev to look at it?
<JFo> well, it is the bit that gets it reviewed for inclusion on the 'hot list'
<JFo> :)
<kamal> mjg59: ok, if you consider it decent enough to sign off on it (or ack, or whatever), I'll post it upstream (with a note that its known to fail on this gm45.
<stenten> Is there any difference between the meaning of 'kernel-needs'review' and marking it as triaged?
<JFo> yep
<mjg59> kamal: I think post it to linux-acpi and intel-gfx as an RFC for the moment
<mjg59> And we'll bounce some ideas around
<mjg59> But I suspect that this is probably how it's going to be
<JFo> stenten, triaged simply means it has everything needed to go to a dev, not that it will necessarily get to one
<JFo> given the amount of bugs we have that is
<kamal> mjg59: ah, got it, ok, I'll do that -- thanks much!
<JFo> stenten, are there any particular subsystems of the kernel that interest you?
<JFo> sound, graphics, etc.?
<stenten> JFo: Not particularly. I'm working in xserver-xorg-video-intel with Geir Ove Myhr, and we get a lot of suspend/resume bugs that end up being reassigned to the kernel, so I like to followup on them.
<JFo> good deal
<stenten> JFo: Do you mind changing the Status on that bug to Triaged? I'm only a lowly Bug Squad member :)
<JFo> I don't mind at all :)
<JFo> done
<stenten> Thanks kindly.
<JFo> my pleasure
<kro> JFo: :-)
<JFo> :-)
<JFo> been using your name in vain all day
<kro> hehe, I noticed
#ubuntu-kernel 2010-06-03
<sconklin> inbox zero, seeya tomorrow
 * manjo bad weather rolling in from the north .. heavy thunderstorms in the area... need to shutdown machine.
<achiang> hughhalf: ping
<hughhalf> achiang, ahoy
<boutcher> must be the nautical hughhalf
<hughhalf> boutcher! 
<hughhalf> how goes man ?
<boutcher> goes great...using a lot of ubuntu in production these days ;-)
<boutcher> how are things down under?
<jk--> hughhalf is totally nautical
<hughhalf> boutcher, good man, good, liking Canonical and life overall goes well :)
<hughhalf> but not sure about jk-- nautical references
<boutcher> hughhalf excellent....saw some picks of rachel doing linux presenting a while back....she's looking good
<jk--> hey boutcher
<hughhalf> boutcher, yeah, she's doing well :)  
<boutcher> hey jk....long time no talk. I'd forgotten you're at canonical too
<boutcher> or I guess that's jk--
<jk--> hughhalf: exactly :)
<pgraner> JFo: you around?
<Squideshi> Is everyone on the Ubuntu Kernel Team an employee of Canonical?
<pgraner> Squideshi: no
<JFo> pgraner, I am now
<pgraner> JFo: you got any bits about bug filing down, specifically why we want new bugs, not dog piled ones?
<JFo> I have some stuff drafted, but nothing wikified yet
<JFo> want me to push something to a page?
<pgraner> JFo: just looking for something to point to in egregious bugs
<JFo> I had been planning a Dos and Don'ts section of the Bugs/ page
<pgraner> JFo: yea, no worries
<JFo> plus an expanding of the statuses a bit
 * pgraner nods
<Squideshi> What's the difference between the following two wiki pages?
<Squideshi> https://wiki.ubuntu.com/Kernel/
<Squideshi> https://wiki.ubuntu.com/KernelTeam
<JFo> KernelTeam/ is in the process of being migrated to Kernel/
<JFo> after that the KernelTeam/ pages will be deprecated
<Squideshi> I just put a note to that effect on KernelTeam.
<Squideshi> Thank you.
<stenten> You won't keep KernelTeam/Meeting? That's how most teams manage their meetings and other internal affairs.
<JFo> that is getting moved over as well
<JFo> Squideshi, not necessary
<Squideshi> JFo: Well, it confused me; and it might confuse someone else, but now it won't. :)
<bjf[afk]> JFo, i like helpful people that are worried about other peoples confusion
<kees> is there an existing git short-hand for "git commit -a -m typo && git rebase -i HEAD~2" or should I just alias that?
 * achiang wonders what kees is doing that requires that questionable operation to be an alias. ;)
<kees> achiang: I keep getting minor nit-picks from lkml about the symlink change I'm trying to upstream.
<cooloney> kees: looks like no other choice to me, but if you wanna try guilt, it can do that very easily 
<kees> cooloney: I may go that route eventually, but I want to be fully comfortable with git before I add another layer.  :)
<achiang> yeah, with stg, that would just be: stg refresh ; stg rebase origin
<achiang> kees: i'm wondering why you need to rebase on HEAD~2
<kees> achiang: so that I can mark the "typo" fix as a "fixup" and it gets melded into the first change
<cooloney> kees: yeah, like guilt-fold
<achiang> kees: what is HEAD~1?
<kees> achiang: same as HEAD^?  it's the typo commit.
<achiang> kees: hm, what is HEAD then?
<kees> *make changes*; git commit -a -e; *make tiny fix*; git commit -a -m fix; git rebase -i HEAD~2; *mark the "fix" change as a "fixup" and save*
<kees> rebase needs one past the stuff you're interested in?  I'm losing count, but HEAD~2 works
<cooloney> kees: exactly, that's what i'm doing in pure git
<kees> cool
<achiang> kees: ah. ok, well, i guess you're doing it the git way. but seriously, this is exactly the use case for other porcelains like stg or guilt
<kees> achiang: ah, right, so HEAD is the typo, HEAD~1 is what I want to merge it into, and HEAD~2 is the point I want to list all commits beyond.
<achiang> this is what i was alluding to the other day about where stg is much nicer than git
<kees> achiang: I will likely start using it for my next upstreaming adventure.  :)
<kees> achiang: I don't doubt, but I have a masochistic desire to understand what in the world git is up to first.  :)
<achiang> kees: you could start using it now and save yourself some trouble... ;)
<kees> hehe
<achiang> git format-patch HEAD~2 (or maybe it's HEAD~3)
<achiang> for i in *.patch do ; patch -p1 < $i ; done
<achiang> stg init
<achiang> stg new symlinks.patch
<achiang> stg refresh
<achiang> done
<kees> cool.  yeah, very quilty :)
<achiang> oh, i guess you'd need to revert the patches before applying them...
<achiang> git reset --hard HEAD~2 (or 3 ;)
 * kees nods
<jk--> whoa
<jk--> git rebase -u HEAD^2
<jk--> err, -i
 * kees looks up -u
<kees> oh
<kees> heh
<jk--> then you get an editor that asks you what you want to do with each patch
<kees> what git help page lists all the ~ ^ .. etc stuff?
<kees> jk--: yup, it's delightful
<jk--> kees: man git-rev-parse
<kees> jk--: ah-ha!  that's just what I needed, thanks.  :)
<jk--> kees: np :)
 * cooloney is checking -u as well
<cooloney> jk--: -u is not available to me 
<kees> cooloney: it was a typo
<jk--> -u is a typo :)
<cooloney> OMG,
<jk--> the keys are right next to each other, it's not *that* surprising! :)
<jk--> kees: oh right, you were looking for alternatives to rebase -i :)
<jk--> you're looking to edit the second-to-last patch?
<cooloney> jk--: yeah, i think kees knows -i 
<jk--> brb
 * cooloney imagines that jk- will invent a option to git as --edit-2nd-to-last
<joaopinto> hello, I can consistently reproduce a kernel crash while startinga a specific java app, what is the recommend procedure to collect the crash data ? 
<jk-> joaopinto: `ubuntu-bug linux`
<jk-> - will file a new bug
<joaopinto> right, but does it collect crash data ?
<stenten> you could try enabling Apport to try and get a backtrace.
<joaopinto> I can't find any of the errors showns on during the kernel oops event at /var/log/*
<jk-> joaopinto: hm, what happens when it crashes? machine stops completely?
<joaopinto> it prints a "Kernel bug at blah blah blah" with some information, and stops completely
<joaopinto> right now I am looking to capute that information
<joaopinto> this happens when starting an WebSphere Application Server nodeagent, which is basically a java process
<joaopinto> I didn't have this issue during lucid's development, so it was either introduced with a near final or post final kernel upgrade, or it's triggered by another change not kernel related which triggers the bug
<jk-> joaopinto: if the crash info doesn't reach the disk, then we can't recover it in the next boot, unfortunately
<jk-> soooo
 * jk- thinks
<joaopinto> hum,  I am being dumb, maybe I can  simply ssh trigger the crash and get the error on the console, or maybe not, let me try
<joaopinto> brb
<jk-> erk
<jk-> joaopinto: it'll only output to ttys that have a console running on them
<jk-> (ie, ttyx and maybe ttyS0)
<joaopinto> ah :(
<jk-> if you can get a serial line working, then that will help
 * kees would like to understand how the "netcat console" works for this kind of stuff
<jk-> kees: https://wiki.ubuntu.com/KernelTeam/Netconsole ?
<kees> why yes :)
<kees> lookie there :)
<jk-> woot! :)
<joaopinto> going for netconsole :)
 * kees has never tried netconsole, just fake serial ports via kvm
<joaopinto> hum, I coultd try to reproduce the crash on a VM
<kees> that's what I've always done for weird crashes
<kees> it still needs setup, but virt-manager was pretty helpful in that regard.
<joaopinto> it's a bit strange how a java process which is purely server oriented (no GUI related interaction) triggers a kernel crash
<kees> yeah.  :(
<kees> especially if it's not running as root.
<joaopinto> it's not, the good news is that I believe that WAS is one of the few BM products certified for Ubuntu, I just need to check if that applies to Lucid
<joaopinto> ..IBM...
<jk-> joaopinto: what does your /proc/sys/kernel/panic_on_oops contain?
<joaopinto> jk-, 0, btw, I have installed the kernel-oops package now, but didn't crashed again
<joaopinto> I hope the netconsole works with plymouth :)
<jk-> joaopinto: that's for reporting oopses to kerneloops.org
<apw> joaopinto, you say it 'prints kernel bug blah' i presume that means you can see the output sometimes?
<apw> does it appear on the screen at least?  sometimes a digitial photo is a useful approach
<joaopinto> apw, I can always se the output when locally on the system
<joaopinto> apw, an IT guy does not use photos to collect data :P
<apw> joaopinto, heh i often use photos to collect panics, better than not seeing it
<apw> joaopinto, the very first line that you indicate has some key information which can be extracted from a photo pretty easily
<joaopinto> I will try 1) netconsole, 2) virtualbox.. 3) photo
<joaopinto> it mentioned a specific .c file on the "bug" line
<dupondje> photo's rule: http://dupondje.be/DSCF1025.JPG :P
<joaopinto> grr wait, this a laptop, wifi, the network will not be available for the netconsole module :(
<cking> morning lag
<apw> joaopinto, if you perhaps took a picture people could at least look at the issue with some real information
<joaopinto> apw, ok, I will take a picture
<lag> Morning cking
<lag> :)
 * lag has a fuzzy head!
<joaopinto> grrrr, this time the output was so long that it scrolled and I can't read the initial lines with the helpful info
<cking> lag, too many beers? ;-)
<joaopinto> does NOHZ: local_softirq_pending 242 as the last line on the crash output means anything ?
<lag> cking: Not enough ;)
<cking> heh
 * lag went out and saw people =:-o
<apw> joaopinto, heh just your luck, one of the reasons i take a photo the first time i see the header of the error, just in case i cannot get it again... low tech, slow, even unreable at times ... but often a life saver
<apw> cking, seems someone has gone postal in the UK
<joaopinto> hum, I see a lot of ip_* / network related functions on the output
<apw> unfortunatly without the top its hard to tell if it was those or they are just a victim
<lag> apw: Are you talking about that taxi driver?
<joaopinto> I do have some internal policy firewalls rules
<apw> lag, walked in the news report so no idea who the person is, but likely there is only one killing spree
<joaopinto> I will try to start the process without the firewalls rules
<lag> Yeah
<cking> one every 18 years or so is still too many
<lag> What was the last one? Dunblane? 
<lag> 14 years back that was :(
<cking> Hungerford (1987), Dunblane (1996).. 
<lag> Ah yes, Mr Ryan
<apw> i guess we have to be thankful they are mercifully far appart
<lag> http://en.wikipedia.org/wiki/2010_Cumbria_shootings
<lag> They didn't waste any time!
<cking> bad news always travels at the speed of light
<lag> Who things "Oh, there's been a massacre, let's start a Wiki page?"
<lag> thinks*
<apw> lag, think of it more as thinking it deserves recording, you could equally say, "there has been a massacre, who'd put it all over the news"
<lag> apw: I had every belief that it would be recorded. I wasn't shocked to see the other two Wiki pages. I was more shocked to see it up there so quickly, as if it was the first thing that popped into the author's mind. 
<apw> lag, i think you'll find its 'slop over' from wikinews.org, people put it there, and the editors of that record the significant events from that
<lag> I see
 * abogani2 waves
<joaopinto> apw, jk- , starting in recovery mode and starting the java processes does not kernel panic
<joaopinto> grr, now it just hardlocked without printing any info, the problem is reproducible the way it's reported is not :(
<lag> Jun  3 08:33:05 ThinkPad kernel: [   98.620090] kmemleak: 247 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
<joaopinto> jk-, I got a wired connection and was able to setup a netconsole, now let's hope the panic info is sent before the lockup
<jk-> cool :)
<joaopinto> grrr, I can't believe this, with a wired connection+netconsole I am unable to reproduce the crash, after having done it 10 consecutive times
 * cking needs to attend gas fitter - back in 20
<jk-> joaopinto: are you getting any console messages through netconsole?
<joaopinto> jk-, yes I am, remote dmesg
<joaopinto> this java process is expected to create multiple tcp listeners, and because I see a lot of ip_* functions on the kernel panic info it seems to be network related
<joaopinto> using a wired connection might have changed the bug condition
<joaopinto> jk-, this is getting funny, I have unplug the eth cable, restart the java process, got a kernel panic
<abogani2> apw: Sorry to bother you: Did you have a chance to take a look on my lowlatency kernel flavour? I have just rebased it to latest Maverick release and the build test is in progress on my PPA.
<apw> abogani2, sorry no, am fighting an aufs2 issue right now
<abogani2> apw: No problem. :)
<apw> abogani2, sorry to be so tardy looking at it, its bee a bit mad with A1
<abogani2> apw: I understand.
<joaopinto> jk-, the only unusual requirement from this java app is that on startup it checks that the configured listener IPs are configured in some network interface, and refuses to start if not
<joaopinto> because this is a laptop I am using 127.0.1.1, for the app to start I need to: ifconfig lo 127.0.1.1
<joaopinto> it could be the "IP availability"  validation on eth0 when the connection is not available leading to the kernel panic
<abogani2> smb: Thank you very much Mr. Bader! :-)
<cking> hughhalf, around?
<cooloney> apw: since smb is not here, how do you think we merge omap4 branch into lucid?
<apw> cooloney, whats the issue?
<apw> cooloney, mumber perhaps ?
<cooloney> apw: actually, smb thinks that is a big change through, he does not like to do that.
<cooloney> apw: i did get any feedback from him about this.
<apw> cooloney, he has been very busy with the security updates which shipped today
<apw> cooloney, join us on mumble ?
<cooloney> apw: yeah, understood.
<cooloney> apw: too bad, i have no time to fix my mic. sorry for mumble
 * cooloney needs to fix it
<apw> bah
<apw> so i think his confusion is over the support side, putting it in our repo implies things about support and i thought he was asking about what the support requirements are
<apw> i believe the images will live outside of the archive in a PPA for the purpose, right?
<cooloney> apw: yeah, exactly, 
<apw> so did we get the information on the support requirements ?
<cooloney> apw: davidm told me about this "the OMAP 4 support for the 10.07 release should not be SRU'ed back into Lucid, but kept out in a PPA, "
<ogra> support for the 10.07 release will end in jan 11
<cooloney> in an email, i think you will are in the loop
<ogra> we dont want the source or binary packages in the distro
<ogra> but cooloney needs a place for the tree
<apw> ogra, define 'source in the distro'
<cooloney> ogra: yeah, thanks, 
<apw> as putting the branch in our git tree sounds like being in the distro
<ogra> apw, no source package
<ogra> all packaging will live in a PPA
<ogra> source as well as binary
<apw> well i don't think there is much of an issue pushing the branch into our repo, its who is going to maintain it for the support period that was the outstanding issue as i see it
<ogra> the tree should be maintained on out git server though, since its a merge of the TI and the ubuntu trees
<apw> as its supported for 6 months right ?
<ogra> (bare omap4 upstream git is at omapzoom.org btw)
<ogra> right
<cooloney> apw: i will maintain that branch, but still need smb to pull my patches. hehe
<apw> if you are signing up to maintain the branch 'hwe' style then i think thats going to be ok
<apw> ie we say 'we added security stuff to mainline, have at it for omap4' style emails coming your way
<apw> and you'll ask for a pull when its applied ?
<cooloney> yeah, i think so.
<cooloney> but is it a big trouble to add security stuff into omap4 branch directly?
<apw> cooloney, i don't understand your question
<apw> cooloney, what upstream version is omap4 based on
<cooloney> apw: it is based on .33 for 10.07
<cooloney> it is the same as ti-omap branch
<apw> yeah so we don't have a .33 master branch for .33, so maintenance of .33 is a bigger job
<cooloney> yeah, i understood, that's smb's git concern
<cooloney> my question is also about that. 
<cooloney> so for maintenance of .33, i will get those security updates from mainline instead of our .32 master branch?
<apw> cooloney, i would assume the omap branch will get them and you can get them from there, but that may mean you have to figure out which ones are which
<cooloney> apw: ok, got it. actually, ti-omap4 is also rebased from ti-omap branch
<apw> cooloney, its based on the normal ti-omap tree ?
<apw> in that case you may be able to just keep rebasing onto there
<cooloney> apw: yeah, i rebased all ti-omap stuff on omap4 branch from TI.
<apw> that sounds like the other way round, and a nightmare
<cooloney> so for our stuff such as apparmor, aufs, it is the same as ti-omap configuration
<apw> yep but if the tree is 'upsidedown' then we're not going to be able to just rebase it
<apw> so i think that nails its status as a hwe branch
<ogra> apw, someone handles the omap3 branch in lucid, no ?
<ogra> should be possible to just copy stuff over from there
<ogra> since they are both .33
<apw> ogra, indeed someone does, but the omap4 branch isn't the same process its not shaped the same
<apw> so its much more effort, and bryan has already volunteered to handle it
<ogra> ok
 * cooloney feels in hot water now
<apw> this is why these stupid heaps of arm patches are an unsustainable mess
<ogra> heh
<ogra> well, maverick will make everything better 
<ogra> we'll only have omap4 as a separate branch for arm
<apw> ogra, all i can say there is 'yeah right'
<apw> ogra, we'll only have that branch till we get a heap more, as happened, and is stil happening in lucid
<apw> this omap4 branch is the 9th branch
<ogra> i doubt you will see a heap more 
<ogra> linaro should solve that 
<apw> ogra, you can doubt it all you like, i just don't believe it
<ogra> there is an army of devs working on fixing the situation now :)
<ogra> and devicetree 
<apw> should, in some unspecified timescale, i will be drinking champagne if we have less that 6 branches in maverick
<apw> all of that is at least 3-4 releases way (upstream) which makes it 2 releases away for us
<ogra> i would have said one release (being optimistic) :)
<ogra> (for us)
<apw> heh yeah, but we heard that a release ago, and frankly there is nothing usable there yet is there
<apw> not to take anything away from TI and the fact that we can almost have an omap flavour on the mainline kernel
<cooloney> apw: right, long term story, but we feel short term pain
<ogra> it looked like there is some base stuff during UDS
<ogra> so i would expect a first working arch in m+1
<apw> ogra, yeah so i return to my previous position we'll have 6 branches again in M
 * cooloney need some food to feel better. 
<apw> which is a worlkd of pain
<ogra> yes, M will still suck but i wouldnt expect more arm branches
<ogra> omap3/4 and versatile are the only arm arches we officially support atm
 * apw holds up his "i'll believe that when i see it" banner
<ogra> heh
<ogra> indeed, if $big_vendor comes in with $big_money that could change ... but i doubt it
<cooloney> apw: if i wanna built-in nfs modules, need i change d-i modules? 
<apw> cooloney, depends if the udeb becomes empty
<cooloney> apw: i built-in nfs before, but building from source package in PPA failed
<apw> cooloney, if it was becase of the udebs the error would have told you, what error did you get
<cooloney> apw: oh, don't have the error log now, then i set NFS_FS as module like other arm branch 
<cooloney> the building passed. 
<apw> cooloney, its entirly possible you would cause a udeb to become empty, which means it needs adding to the exclusion list for the flavour
<cooloney> apw: OK, I saw your patch about that, it should be similar i guess. 
<apw> why do you need to buildin NFS of all things
<cooloney> apw: that's a question from TI guys, they are heavily using NFS for boot
<cooloney> so you know, they are asking for building NFS_FS
<cooloney> built-in
<cooloney> find: `debian/nfs-modules-2.6.33-900-omap4-di': No such file or directory
<cooloney> nfs-modules-2.6.33-900-omap4-di will be empty
<cooloney> make[1]: *** [do-binary-udebs] Error 1
<cooloney> make: *** [binary-udebs] Error 2
<cooloney> dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2
<apw> <cooloney> nfs-modules-2.6.33-900-omap4-di will be empty
<cooloney> https://launchpad.net/~canonical-arm-dev/+archive/ppa/+build/1757077/+files/buildlog_ubuntu-lucid-armel.linux-ti-omap4_2.6.33-900.1~build2_FAILEDTOBUILD.txt.gz
<apw> that line tells you that nfs-modules become empty
<apw> so you need to add nfs-modules to the excludes list
<cooloney> yeah, i understood
<cooloney> apw: cool, got it.
<cooloney> will try to fix that
<cooloney> apw: thanks, i have to off line now
<cooloney> have a nice day
<apw> see ya
<apt_get> Hello
<apt_get> for a server (mail, vpn, squid-proxy and firewall), whats the best for Timer frequency in kernel: 100Hz or 1000Hz
<apw> generally we set servers lower as they do not require the same interactivity
<apw> cking, is launchpad down _again_ today?
<apt_get> 100 or 250
<pgraner-afk> tgardner: you have emerald smoking, I have ear plugs and now I have about a 90 deg breeze blowing on me from the fans
<tgardner> pgraner-afk, just burning it in. perhaps you should move it downstairs?
<pgraner-afk> tgardner: I'll put it back in the rack when your done
<tgardner> pgraner-afk, I'm off. did you fix the PXE boot?
<pgraner-afk> tgardner: yep
<pgraner> tgardner: wow it got quiet
<cking> apw, lp is behaving slowly but it is working for me
<apw> pgraner, did it quiet down before or after you turned it of
<apw> off
<pgraner> apw: heh
<apw> Keybuk, yesterday you mentioned u had unionfs patched userspace tools.  where can i find those
<apw> Keybuk, also in my red and green PPAs are the initargs and readahead-tracking patches building, i think they'll make it this time
<lag> When suspending, does USB suspend or just the connected devices?
<apw> lag, we power down the devices don't we
<lag> Yes
<lag> But does USB host need suspending too?
<apw> so we are definatly doing something to the host, i would imagine putting it in D0
<lag> I don't think USB actually needs suspending 
<lag> I have just found an option in the menuconfig to disallow any USB device to suspend anyway 
 * lag is a happy bunny now
<cking> lag, what option is that pray tell
<lag> 2 secs
<lag> CONFIG_USB_SUSPEND surprisingly :)
<JFo> we don't build a specifically -server kernel do we?
<JFo> one of the bug reporters just confused the heck out of me
<tgardner> JFo, um, of course we do
<apw> JFo, there is a -server flavour for amd64
<JFo> I see... oh, I knew that
 * JFo goes to make coffee
<bjf> moin all
<apw> moi
<JFo> moin bjf 
<Squideshi> I'm looking at a commit to the drm-next branch. How do I know if this patch has been incorporated into the mainline kernel, when, and which version?
<Squideshi> http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=f360132626b11d0dc60814033873ca0e3111677c
<JFo> Squideshi, you'd do a git log against the source of the tree you want to know about
<JFo> git log <SHA1>
<JFo> in the example above f360132626b11d0dc60814033873ca0e3111677c is the SHA
<Squideshi> JFo: In other words, I would need to actually download the mainline kernel source?
<JFo> you would need the Ubuntu branches in order to tell, since you'd have to run the git log commands against them
<JFo> or rather whichever release you were interested in
<apw> ogasawara, i did that aufs2 update.  there is a bit of a colission between that an the removal of an arguemtn to fop fsync .. which means we may not be able to fsync directories correctly on aufs2 after this... hoping we get an update from the maintainer shortly
<ogasawara> apw: ack
<JFo> anybody know about kdump?
<JFo> or rather know what is needed when it seemingly fails?
 * JFo listens to the crickets
<Squideshi> JFo: Sorry. If I knew, I would try to help. :)
<JFo> no problem Squideshi 
<JFo> basically just wondered if anyone of the team had experience with it
<JFo> I know next to nothing about it
<Squideshi> I have an Intel 845G on an Dell Inspiron 1100 that seems to have several video problems with Lucid. I first had to uninstall Compiz to get it to work at all; but now I think there are two different problems, possibly both in the kernel... 
<Squideshi> First, there's a flicker problem (I hope that's the right term.)
<Squideshi> It appears to be fixed when I installed the linux-image-2.6.33-997-generic kernel from drm-intel-next.
<JFo> Squideshi, do you have a bug filed we can look at?
<achiang> <timball> so lucid is basically unuseable on ec2 instances
<achiang> <timball> you run chown -R foo:foo somedir/ and on lucid on ec2 the load goes straight to 40
<achiang> <timball> it's like a software simulation of a 300bps modem
<achiang> from #kernel
<manjo> tgardner, CONFIG_DEBUG_KERNEL=y
<manjo> tgardner, http://hildstrom.com/projects/aestest/index.html
<lag> Does anyone know why kgdboc refuses to recognise ttyUSB0?
<lag> I get write error: No such device
<manjo> lag, not sure if this is your problem... http://jdramer.wordpress.com/2010/04/28/linux-kernel-debugging-with-kgdb/
<lag> manjo: Nope. That guy is using USB->Serial on his development machine. I need it on the target.
<JFo> apw, I'm off to grab some lunch. ping me whenever you want to chat about wikis... we can postpone till later too if you like
<apw> JFo, ok
<apw> ogasawara, where shall i push this maverick thing
<apw> shall i just expose it on my zinc one ... seems sensible
<ogasawara> apw: yah, anywhere on zinc should be good and I'll just grab it
<apw> ogasawara, i haven't tested it other than compiling aufs bit, as it then breaks more in ubuntu/
<ogasawara> apw: ack
<apw> ogasawara, i'll be monitoring the aufs tree for a proper fiz
<apw> fix
<apw> ogasawara,   git://kernel.ubuntu.com/apw/ubuntu-maverick aufs2.35rc1
<ogasawara> apw: thanks
<apw> jdstrand, perhaps --cpu 4 for you
<jdstrand> apw: --cpu 4 with testdrive you mean?
<apw> jdstrand, was wrong channe, and you said the same in paralle in the right place
<jdstrand> ok, I wasn't aware of a -cpu' option, so wasn't sure
<sconklin> git remote show origin
<sconklin> -EWRONGWINDOW
<JFo> heh
 * oldkid is listening to 'Subway to Sally - Wolfstraum' from 'Engelskrieger'
<JFo> ...
<oldkid> sorry wrong chan
<JFo> heh
<lool> apw: hey did you see my patch enabling linux-tools in ubuntu-maverick-*meta* as well?
<apw> lool yeah, though ogasawara is owner for maverick and has taken ownership of the patch in patchworks
<lool> apw: Oh ok, how do I see that?
<apw> http://patchwork.ozlabs.org/project/ubuntu-kernel/list/
<lool> Didn't know about this instance, thanks
<lool> apw: are there more arm trees in which to enable too?
<lool> linux-ti-omap and the like
<ogasawara> lool: am in the middle of rebasing to 2.6.35-rc1 so will get everything that's under review applied afterwards
<lool> (and do you need patches for them)
<lool> ogasawara: Ok thanks
<lool> ogasawara, apw; https://wiki.ubuntu.com/Specs/M/ARMKernelVersionAlignment
<lool> ogasawara, apw: feel free to /join #linaro BTW  :-)
<lool> ogasawara, apw: Someone is doing noise next to the phone
<apw> lool, it was someone typing i recon, and not i :)
<amitk> I can see apw and ogasawara swearing under their breath
<apw> amitk, less than you might expect
<jjohansen> ->lunch
<dupondje> JFo: as i'm guessing its a bad BIOS, seems like some other people have crashes with that bios also. Mailed ASUS, but they tell me its PSU, but its not right :s
<JFo> hmmm, that is sad
<JFo> wonder why they think it is the PSU
<dupondje> because they say newer cpu has bigger TDP then old one
<dupondje> but its shit :)
<JFo> hmmm, I seem to recall an issue with a laptop where the vendor said much the same and, to my surprise, the new PSU fixed it
<JFo> not saying that is the case here
<JFo> but it reminded me of that
<jjohansen> rebooting
#ubuntu-kernel 2010-06-04
<nealmcb> How do we find out what changed in the recent kernel update (to 2.6.32-22-generic #35-Ubuntu)?
<nealmcb> The changelog just seems to cover abi changes
<nealmcb>  (I was looking in /usr/share/doc/linux-image-generic/changelog.gz - that may not be the right place....)
<Squideshi> Does the kernel ever get updated before the next version of Ubuntu is released? For example, will there be a kernel update before Maverick?
<jpds> Squideshi: https://wiki.ubuntu.com/KernelFreeze
<ogasawara> nealmcb: https://edge.launchpad.net/ubuntu/+source/linux and click the drop down for 2.6.32-22.35
<ogasawara> nealmcb: although there was a kvm regression, so that patch was backed out and an updated 2.6.32-22.36 kernel is in the process of being uploaded
<nealmcb> ogasawara: thanks!
<Squideshi> Maybe I should just ask the question I really want to know: I'm having a really difficult time troubleshooting the video on my system, because I think I have at least three different problems. First, Compiz doesn't work at all--had to be uninstalled. Second, the stock kernel that ships with Lucid has some problem with my Intel 845G that causes some display glitches and constant GPU lockups....
<Squideshi> ...Third, my screen often goes blank (backlight not lit) with a reboot being the only recovery, which I think is a separate problem from the last.
<Squideshi> Good news is that I installed a drm-intel-next kernel and the second problem appears fixed.
<Squideshi> Although, I wish I knew how to find out WHEN it was fixed (i.e. with what patch) so I could tell you guys.
<Squideshi> All of this isn't very easy to log as a bug because I don't know what's really affecting what.
<Squideshi> I figure that the GPU lockups with the stock Lucid kernel has already been fixed in newer kernels.
<Squideshi> I don't know if there's anything I should do about that.
<ogasawara> Squideshi: you could test the latest 2.6.35-rc1 mainline builds to see if it
<ogasawara> 's resolved
<Squideshi> My guess is that I should start looking at the blank (no backlight) problem.
<kees> nealmcb: to answer your specific question, you can find the changelog in /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz
<ogasawara> Squideshi: https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes might also help
<Squideshi> ogasawara: What's the difference between the drm-intel, drm-intel-next, and mainline kernels?
<ogasawara> Squideshi: drm-intel and drm-intel-next I presume are staging trees for patches which eventually get pushed to mainline assuming no ill effects
<Squideshi> ogasawara: Is blacklisting Intel 8xx hardware for KMS going to work, considering that Intel has removed ALL user mode setting in the newer drivers?
<RAOF> Squideshi: Yes, because you'll get VESA - or, if you install it, an old forked -intel driver from Universe.
<Squideshi> Hmmm... That's a shame because it seems fixed with the newer kernel I installed.
<Squideshi> The glitching and GPU lockups that is.
<nealmcb> kees: ding ding ding - just what I hoped for....  thanks :)
<kees> nealmcb: np :)
<RAOF> Squideshi: I'm surprised.  The GTT incoherency bug is still open upstream, and didn't appear to be being worked on.  You'll still be able to enable KMS and use the new intel drivers if you want - we only change the default, not forcibly disable KMS.
<Squideshi> RAOF: I don't know if "GTT incoherency" is the same thing that I'm experiencing.
<RAOF> Squideshi: You will be, but it's possible that it's sufficiently infrequent for it to appear as background noise.
<Squideshi> RAOF: Like I said, it's difficult to separate everything out. I was so happy when the newer drm-intel-next kernel I installed resolved the flicker and GPU lockups that I thought I might be able to jut focus on the frequent screen blanking (no backlight.)
<Squideshi> RAOF: After those two, I thought only then would it be appropriate to figure out Compiz.
<stenten> Is there a kernel parameter to set the dmesg font during boot? Trying to catch a trace that keep scrolling off the screen.
<lag> http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-67881
 * hughhalf steps away for a bit
<cking> lag, http://kernel.ubuntu.com/git?p=cking/debug-code/.git;a=blob;f=led-flash-user-space/led.c;h=61131fc7caefcebc50326f48b630726e77e402b3;hb=ebb3c4b8e2c5ff1628f8b42076e6b9e969ed5f52
<lag> http://frommel.net/weblog/images/htc-desire.jpg
<rafiyr> what's kzalloc?
<rafiyr> oh, nm, found the desc
<rafiyr> strange though
<jk-> strange?
<rafiyr> there was a comment from dmitry on linux input suggesting kcalloc instead of kzalloc
<rafiyr> seems to me they are pretty damn similar
<rafiyr> only thing I see is the potential to take advantage of the knowledge of array structure in the future if calloc is used
<rafiyr> well that and I guess one extra check for kcalloc against ULONG_MAX
<jk-> just makes it explicit that you're allocating for an array of stuff
<rafiyr> Oh, right there's the whole question of readability too :)
<rafiyr> I was thinking in terms of implementation and possible optimizations.
<rafiyr> For example, if you were to run a kernel on an FPGA, you can actually do something useful knowing that a block of memory is actually an array
 * apw discovers xchat is not running ... hrm ... i thought you lot were very quiet
<amitk> jk-: around? care to join #linaro?
<l3on> Hi all, someone of you can tell me if there is something wrong/missing in bug 589598?
<ubot2> Launchpad bug 589598 in linux (Ubuntu) "B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card does not work anymore (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/589598
<ogra> apw, amitk, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/589624 for your radar
<ubot2> Launchpad bug 589624 in linux (Ubuntu) "omap flavour does not work on beagle XM board (affects: 1) (heat: 8)" [High,New]
<amitk> ogra: ack
<amitk> ogra: I thought you said it worked before
<apw> amitk, i suspect that is a bug in the omapfb driver ... as it failed to init, but the cursor flash timer is running
<ogra> amitk, nope, i was thinking i see the typical "no rootfs found" oops here, but after apw had me verify it with an actual rootfs in place it showed its really a bug
<amitk> I'm not surprised if it is a DSS2 bug
<ogra> yeah, i hope we get that working in time for all these different devices
<apw> amitk, are you still owning omap, or do i need to lean on someone else
 * ogra has to actually try the touchbook and zoom
<amitk> apw: I don't _own_ it. Mathieu and cooloney-afk do. I'll just help them with bits and pieces. In this case I have the HW.
<apw> amitk, ok so i'll hastle them then
<amitk> apw: I am obviously interested though. So what will you hassle them about? ;)
<apw> amitk, it not working obviously :)
<apw> s/hastle/make sure they are aware it is an issue and needs fixing/
<amitk> heh
<apw> ogra, does it work on a regular beagle ?
<ogra> apw, havent tried yet :)
<ogra> will do after the release meeting, but i would expect so
<apw> ogra, is the release meeting on ?  seems to be gone from my cal
<ogra> apw, according to a mail i got from davidm i have to attend
<ogra> apw, but i dont see it on my cal either
<apw> ogra, seems to be gone and i have this email
<apw> From: Robbie Williamson <robbie.williamson@canonical.com>
<apw> To: Andy Whitcroft <andy.whitcroft@canonical.com>
<apw> Subject: Canceled Event: Maverick Weekly Release Meeting @ Weekly from 16:00
<apw> so i think its not there any more ...
<apw> i don't have agenda either
 * apw asks on #ubuntu-release
<apw> ogra, seems not till next week
<ogra> sweet !
<ogra> extra free hours with that wonderful weather !
<apw> yeah indeed so
<apw> JFo, about ?
<JFo> I am indeed apw
<apw> JFo, roomies for sprint ?
<JFo> sounds good to me :)
<apw> cool i'll put you in then ... i note you are missing from the list right now
<JFo> ah yes, still hashing out travel with Atlas
<JFo> ;-/
<apw> come on, you'd love to row all the way
<apw> jjohansen, about?
<dupondje> JFo: commented my bug again, added another dmesg output. Totally other error .. guess my BIOS/Mobo if00bar :)
<JFo> heh, it happens sadly enough :-/
<dupondje> Its a new bios that supports new cpu's, but seems like its quite bad support :(
<dupondje> ah well, I close the bug as 'Invalid' ?
<ogra> apw, so i'm seeing the ARM meeting minutes on the kernel ML, thats not talking about our kernel we ship on the ubuntu images, is it ?
<apw> ogra, thats talking about how the linaro kernels might make it into the archive
<ogra> apw, ok, but in separeated out binaries please
<apw> so that should be 'all' the arm branches but not those in master
<ogra> i dont want to risk image stability for omap3/4 images
<apw> ogra, right this is not fixing the 'one actual binary to rule the world' issue
<apw> its likely the package would produce 5-6 binary image sets
<ogra> thats fine as long as i have a stable version for omap3 and a stable version for omap4
<ogra> i just dont want experimental kernels in my images
<JFo> dupondje, sounds good
<JFo> who could blame you ogra :)
<bjf> moin all
<apw> moin
<JFo> moin bjf
<JFo> apw, did you get the chance to create my testing directory on the kernel PPA?
<JFo> or was it you I was even talking with about it?
 * JFo forgets
<Kano> hi apw 
<Kano> is there a custom enforce file too? that i dont need to change the other one that will override the default enforce?
<apw> JFo, can't remember ... can do it now
<apw> Kano, not currently there is just one per series
<JFo> if you like, was just trying to remember if we had discussed it at all
<apw> JFo, the scripts running as you i assume yes
<Kano> apw: it would be a good idea however, something thats used after the default, so i could put my changes in there
<JFo> I didn't want to blindside you with it if we hadn't
<JFo> apw, think they are running as bjf
<JFo> but I defer to him
<Kano> apw: the n value is for unset or?
<Kano> usually there is no n
<apw> Kano, yes n means #FOO is not set
<bjf> JFo, which scripts?
<JFo> the createiso stuff
<JFo> bjf, was seeing if apw minded setting us up a dir in the PPA
<JFo> for the testing ISOs
<apw> yep seems fine
<apw> 1) what you want to call it ?
<bjf> JFo, apw yes they are running as a personal cronjob on emerald
<apw> 2) who needs to be able to write to it
<Kano> apw: do you know why mantis driver has still no pci ids enabled
<JFo> testing is fine with me, what do you think bjf?
<Kano> apw: echo "MODULE_DEVICE_TABLE(pci, mantis_pci_table);" >> v4l/mantis_cards.c
<Kano> something like that would add those
<JFo> as to who writes to it, hmmm I assume bjf will be copying over.
<apw> Kano, no idea, not something i've run into
<JFo> apw, I think he is generating them on emerald
<apw> JFo, will play a minute thanks
<JFo> so they just need to copy over iirc
<Kano> thats stupid because when you are used to dvb-s2 lip
<JFo> k
<Kano> then there was always a pci-id table
<Kano> just the normal mantis in the kernel does not
<bjf> that's a pretty broad name, as far as who, we can make it anyone, is this something I am going to own or is someone else going to take ownership (doesn't matter to me)
<JFo> I actually prefer not to lock it down to you now that you mention
<JFo> bus test and all, God forbid
<bjf> do we have a non-real user launchpad user that this could run as?
<JFo> kernel-janitor
<achiang> does anyone know if the latest released security kernel has other fixes from -stable?
<JFo> achiang, apw knows... poor man
<apw> achiang, it has only the single revert
 * JFo fixes apw a large beer
 * apw thanks JFo 
<JFo> my pleasure
<achiang> apw: hm, i wasn't paying attention to what was released yesterday. it only had some patch that broke kvm and no -stable updates? and now the most recent kernel reverts that single patch. do i understand that correctly?
<apw> .35 had about 5 security related updates, .36 reverted just one of them
<apw> there was no -stable in either of them
<achiang> apw: ok, thanks
<manjo> JFo, 1/2 day bug day is morning or afternoon? are we just picking bugs at random from the list ? 
<JFo> either morning or afternoon
<JFo> you work through the ones on the Top50
<JFo> to get them moved off if possible
<apw> bjf got a sec ?
<apw> manjo, whenever you want
<manjo> apw, yep I just started looking at some so was not sure 
<manjo> JFo, ^
<JFo> cool
<bjf> apw, what can i do for you? (i cringe at the thought)
 * apw mumbles at you
<JFo> heh
<bjf> apw, give me a sec. mumble non-responsive
<apw> bjf, heh what fun
 * JFo realizes he's not mumble ready... sitting here with the headset on for no reason apparently
<JFo> sad given I've had a pot of coffee already today
<apw> no sleep for you
<apw> JFo, doh
<JFo> didn't get any last night
<JFo> that is the reason for the coffee
<JFo> :(
<JFo> stupid headache
<JFo> ogasawara, are you around yet?
<ogasawara> JFo: yep, here
<JFo> cool
<JFo> I am going through my list of things not to forget...
<JFo> did I tell you that James Westby asked me if we wanted him to turn on kerneloops again?
<JFo> or something like that
<JFo> it is what I have written down from UDS
<apw> we norally have it on for development
<JFo> right
<ogasawara> JFo: we can, it's your call now :) usually we'd crank in on around alpha1
<JFo> ok, I'll ping him on it then :)
<JFo> he made it seem as if it was my call, but I wanted to verify before I made the change
<ogasawara> JFo: go for it
<JFo> cool
<JFo> tgardner, you around?
<tgardner> JFo, yo
<JFo> tgardner,  cjwatson indicates that the bnx2 module was broken in bug 589304
<ubot2> Launchpad bug 589304 in linux (Ubuntu) "Broadcom bcm5708 ethernet not initialized during install (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/589304
<JFo> was just wondering what my next step should be
<JFo> and I wanted to ask you based on your intimate familiarity :)
<cnd> apw: http://kernel.ubuntu.com/git?p=cndougla/hedley.git;a=shortlog
<tgardner> JFo, looking...
<JFo> k, thanks
<tgardner> JFo, its a missing firmware problem. seems like a regression, but I dunno why.
<JFo> he seemed to think it was just broken... and at that point I was lost :)
<JFo> tgardner, looks like fader removed and reinserted the firmware but that didn't help
<JFo> so it looks like it was there, just not functional for some reason
<tgardner> JFo, looks like the maverick driver wants an updated firmware file which we donot yet have.
<JFo> ah, I see
<tgardner> JFo, I've updated the LP report and taken ownership
<JFo> thank you sir
<manjo> apw, http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current this is correct? I get 404
<apw> manjo, i removed one to rebuild it so current may currently not point anywhere while it builds
<manjo> apw, ah so it will come back later ? 
<manjo> what version are you building right now ? so that I can put that in my report 
<apw> so it will come back later yes in theory
<apw> what report ?
<apw> ogasawara, if you see a late build failure related to aliases, let me know (with your new kernel)
<apw> ogasawara, i think i know what it is and am working on it
 * apw pops out
<ogasawara> apw: building cleanly for me on i386 and amd64, just failing on the ports
<jjohansen> apw: whats up?
<cnd> git rebase --onto mvl-dove branchpoint merge
<tgardner> JFo, have you seen any bugs complaining about server consoles selecting the wrong display resolution if there is a KVM in the way? I have a case where the KVM supports up to 1680x1024, but the attached monitor only supports 1024x768.
<tgardner> 1680x2048*
<tgardner> or something....
<JFo> tgardner, not off the top of my head, but I can look
<JFo> actually, I think i have seen some
<tgardner> thanks
<JFo> let me dig a bit
<cnd> when upgrading, 2.6.32-22.21~v1 is seen as later (i.e. newer, should be upgraded to) than 2.6.32-22.21
<cnd> correct?
<tgardner> cnd, yep
<cnd> tgardner: thanks
<Kano> usually ~ is before
<tgardner> cnd, lemme retract, 2.6.32-22.21~v1 is ealier
<Kano> - after
<cnd> wait, so I have it backwards?
<tgardner> yes
<cnd> ok
<tgardner> the tilde is like a minus
<cnd> is the ~ special?
<tgardner> yes
<cnd> ohhhh
<cnd> so I would have been right if I appended 'v1' instead of just '~v1'?
<tgardner> a tilde lexicographically subtracts from the version
<cnd> ok
<JFo> any reason why we haven't built 2.6.31.13 in the mainline PPA or do we stop doing that at a certain point?
<apw> JFo, hrm not sure
<JFo> saw the question in a bug and thought I'd ask... after verifying that there was, in fact, a .13 version :)
<apw> JFo, but there is a 2.6.31.13
<JFo> hmmm
<JFo> .me looks in mainline
<JFo> ah, it is the http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html which doesn't show it
<JFo> only has one image and one header while the others have 2 of each. that sound correct apw?
<JFo> errr in some cases 3 of each
<apw> ahh you meant its there and its broken
<JFo> could be
 * JFo is not sure what he means today
<JFo> been a very bad day
<apw> JFo, ok its not obvious that its not a bad buids, so rebuilding it
<JFo> k, thanks apw
 * bjf[afk] -> lunch
 * kees starts using ccache ...
<jjohansen> -> lunch
<cking> manjo, did you get that PC?
<manjo> cking, was just receiving it 
<manjo> cking, that is fast shipping 
<cking> manjo, note that it's already pre-installed with karmic - so it may be a good idea to see how that's configured 
<kassah_> what does the extra minor version mean on proposed kernels? i.e. 2.6.32.14.5 (The last .5)
<cking> if you have any questions, send me an email, I'm having to finish up for the day now
<cking> ^^ manjo
<manjo> cking, yep will power it up as soon as I get a  power cable
<manjo> cking, play with it over the weekend and ping you on Monday
<cking> manjo, perhaps we can find time next week to walk through it
<manjo> cking, good idea
<cking> cool - have a good weekend!
<manjo> cking, you too
<cking> ta! bye!
<kees> what's the best way to keep my ubuntu-maverick git tree on zinc up to date ?
<sconklin> kees: it depends - do you just want to keep the branches from the origin updated, or do you want to rebase your own branches or anything like that?
<sconklin> kees: I haven't done it on zinc, but I have run cron jobs on my server at home to fetch from upstreams
<kees> sconklin: well, I think I've sorted it with the alternate file
<kees> sconklin: but I'm curious how to push from my local git, in a branch named "maverick-ptrace" to my remote maverick's master.
<sconklin> git push remotename localbranchname:remotebranchname
<sconklin> so git push remotename maverick-ptrace:master
<kees> ah-ha, colon.  more man page fail.
<sconklin> yeah, that one was not obvious at all to me
<kees> okay.
<sconklin> be aware (I think) that this is one of the situations where pushing a blank branch name deletes the remote branch.
<kees> http://kernel.ubuntu.com/git?p=kees/ubuntu-maverick.git;a=summary  <- the tag for 5.14 is missing here, and I don't know why
<sconklin> oh, ask apw but I think unless you push the tag as the identifier or push --tags, they don't all go. But --tags can push a lot of crud you don't want, since tags are across all branches
<kees> hm
<sconklin> I need to reread that chapter in the book, actually
<kees> heh
<apw> sconklin, kees, right you have to push them explicitly which may mean ogasawara didn't push it
<ogasawara> oops, /me check
<kees> no, it's my tree that is missing it
<apw> kees, i have seen tags get lost on fetch
<kees> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=summary vs http://kernel.ubuntu.com/git?p=kees/ubuntu-maverick.git;a=summary
<apw> you only get a tag if the tag points to a commit when you get that commit
<apw> so if ogasawara pushed, you fetch then she pushed the tag you may not get it
<apw> kees, git fetch --tags origin should get you any missing ones
<kees> ah, so I have a single local repo that has both linux-2.6 and ubuntu-maverick as remotes.  How do I get both sets of tags?
<kees> sounds like I just want to add --tags to my "fetch" uses
<apw> kees, normally you should get them automaticall
<apw> it should get any tags pointing to any new commits you get, i've only seen it out of sync once or twice and used --tags to fizx
<apw> fix
<kees> hunh, still can't seem to push the tags.
<kees> if I add --tags to the push, it tries to upload the entire change history.
<JFo> ogasawara, kerneloops re-enabled now per James_w
<apw> JFo, that 31.13 finished ok this time
<JFo> yep, I saw it. Thank you sir :)
<lag> Night all!
 * lag is sleepy!
#ubuntu-kernel 2010-06-05
<kraut> moin
<dob1> hi, i have an acer 5100 and with the new relase of ubuntu this problem https://bugs.launchpad.net/ubuntu/+source/linux/+bug/44627  happen again, with karmic the problem wasn't present, with juanty the problem was present, i know is very difficult to find the cause but there is something in common between the 9.10 and juanty that can generate this problem?
<ubot2> Launchpad bug 44627 in xserver-xorg-video-sis (Ubuntu) "3d support for Sis 760 DRI OpenGL (affects: 7) (dups: 2) (heat: 65)" [Wishlist,Confirmed]
<ripps> Does anybody here know how to build an updated wacom module for kernel 2.6.35? The default doesn't support my bamboo ctl-460 anymore, and rebuilding it using linuxwacom-0.8.6-2/0.8.7-2 fails with errors
<mininessie> help i am getting when i am trying to untar kernel 2.6.34 what i am trying to do is create a custom kernel
<ripps> Okay, I figured it out, there was an api change in the kernel, so I had to change the names of some functionsin wacom_sys.c
<mininessie> help 
<mininessie> help!!!
<mininessie> can someone help me
<mininessie> please
<mininessie> can some one help me please
<ripps> !ask
<ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<anoteng> Hello, I'm git-bisecting a kernel, and all of a sudden the kernel image deb depends on linux-tools-kernelversion which of course does not exist. Is it safe to force the installation? What does the linux-tools packages do?
#ubuntu-kernel 2010-06-06
<wzssyqa> does 10.10's kernel support btrfs as root?
<maco> by release tie, it should. i dont know if it does yet. its still really early in the cycle
<maco> *time
<maco> (at least, that was how i read the "we're gonna support btrfs!" announcement)
<cwillu> wzssyqa, 9.10 supported it as root if you know how to use a /boot partition and handle grub
<cwillu> supported it as in "it worked", not as in "actually supported"
<cwillu> that said, dpkg had corruption bugs in it until 10.04 that btrfs exposed, so ya :p
<wzssyqa> cwillu: sorry i means as boot,or as root without /boot
<cwillu> not sure that the licencing issues are completely sorted out with grub
<Zhenya> hi guys!
<Zhenya> i am having lots of fatal kernel panis
<Zhenya> panics
<Zhenya> lol
<Zhenya> i am total newb but here is the dmesg
<Zhenya> if someone would help it would make my machine much more usable :/
<Zhenya> http://pastebin.org/312742
<Zhenya> anyone here that can help?
<soren> Zhenya: It's Sunday.
<Zhenya> soren: hahha ok i'll try back tomorrow :P
<soren> Zhenya: Do that. The kernel people are mostly UK and US based, so in their business hours is your best bet.
<Zhenya> soren: ah ok I didnt know that. Thanks for the suggestion. :D
<soren> Sure.
<shadeslayer> so i have the latest mainline kernel,Linux kubuntu 2.6.34-020634rc7-generic #020634rc7 SMP Mon May 10 09:08:52 UTC 2010 x86_64 GNU/Linux, but my wifi connection keeps dropping, dmesg output is : http://pastebin.com/7HennmtC and lspci output is http://pastebin.com/DPbq2PEp,also lsusb is http://pastebin.com/C07v6nNy
<shadeslayer> oh.. we have 2.6.35 for lucid...
<shadeslayer> looks like there have been some changes to the intel wifi driver.. maybe this helps...
<Kano> hi, where was the source for the last 2.6.34 packag
<Kano> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/
<Kano> i see .34-5 packages but no linux-2.6.34-5.x.dsc
<Kano> https://launchpad.net/ubuntu/+source/linux/2.6.34-5.14
<Kano> there i guess...
<Kano> when i use enforce, how to use the values?
<Kano> check-config: 26/80 checks passed -- exit 1
<Kano> make: *** [config-prepare-check-generic] Fehler 1
<bjf> JFo, ping
<bjf> pgraner, ping
<pgraner> bjf: pong
<bjf> pgraner, private msg
#ubuntu-kernel 2011-05-30
<ppisati> morning
<smb> morning
<abogani> morning
<ohsix> this can't be right ...
<ohsix> [314951.125601] CPUFREQ: ondemand sampling_rate_max sysfs file is deprecated - used by: md5sum
<ohsix> [317300.986027] process `md5sum' is using deprecated sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use net.ipv6.neigh.default.retrans_time_ms instead.
<ohsix> nm on the first one, it was actually reading /sys ;]
<cjwatson> hmm, so regarding 3.0; the kernel team knows that 3.0.0 < 3.0 as far as dpkg is concerned, right?  we'll need to be careful when uploading the RCs ...
<smb> Probably we would not have thought about that first. I guess there will also be all sorts of hardcoded 2.6 we will find in scripts...
<_ruben> don't even wanna think what kind of packaging hell the 3.0 decision is causing in distro land :)
<broder> wasn't that deliberately supposed to be part of the fun? :)
<_ruben> quite likely ;)
<cjwatson> you can use 3.0~3.0.0-<whatever> or similar, although I don't know what that will do to your scripts :-)
<cjwatson> yeah, I already know of at least one bit of hardcoding in the installer
<broder> wait, aren't they doing 3.0.0 now with the intent of switching to 3.<num>.<stable release> once everybody wakes up?
<smb> cjwatson, I probably should add this in mail form not to forget... There are a lot of not workers today... Actually, isn't that a day off in the UK?
<ppisati> smb: and usa too iirc
<broder> yeah, today's a US holiday
<smb> ppisati, I did know the US, I surprised a bit by the UK part. :)
<ppisati> smb: i think apw told me that
<ppisati> smb: but i could be worng, a lot things happe during a weekend that can help you forget :)
<smb> ppisati, Yep. Me too. When telling me see you on Tuesday on Friday.
 * smb plans to take off this Friday just to pay back... ;-P
<ppisati> :)
<ppisati> in italy we have a national holiday 2th of june
<ppisati> but i'm not sure if i'll take it
<ppisati> too many cve to fix
<smb> ppisati, Have the same in Germany. And there is always many CVEs (and there will be after)
<ppisati> yep
<ppisati> bank holiday in uk
<cjwatson> smb: yes, I'm not really working today
<ppisati> memorial day in usa
<cjwatson> doesn't stop me being on IRC now and then though :)
<smb> ppisati, You know the saying: "nothing is so important that it cannot get more important by delaying a bit"? ;)
<smb> cjwatson, :) Some people are crazy in a worrying way. ;)
<smb> Hm, that probably came out more rude that intended. More tried to express that looking out of my window and if I had a free day, I could imagine so much nicer things than to be on irc...
 * ppisati keeps hitting bugs that are marked as "Fix Released"
<cjwatson> smb: not so much a free day as a housework day, for me
<smb> cjwatson, I guess that changes things a bit (at least the order of appealance)
<cjwatson> quite
<awilkins> Is there some kind of NVRAM marker that the kernel writes to inform the BIOS that a boot occurred successfully? My BIOS keeps claiming that the last boot failed or the POST was interrupted, but only after I shut down Natty - it never did it for Maverick, and doesn't do it for Windows.
<cdbs> Hey, any time frame for a kernel 3.0.0-rc1 release on the mainline ppa?
<cdbs> I have an intel sandy bridge, and performance on 2.6.3x (even .39) is like that of a 2004 computer running Win7
<smb> cdbs, It may need some effort getting that to run. Normally it should be picked up when the tag appears, but I suspect we will see some things breaking by that version change
<soren> I'm having difficulties running the Oneiric kernel as a Xen dom0.
<soren> Looking at http://wiki.xensource.com/xenwiki/XenParavirtOps there's a number of config options that need to be enable that aren't.
<soren> Some of them are listed as =y, so they'll bloat the kernel by some amount.
<soren> Is Xen dom0 something you do want to support, thought?
<soren> -t
<awilkins> Maybe they'd want to enable it on the server builds, or their VM server build (they have a special build for EC2, no?)
<soren> Not dom0.
<ogra_> soren, err, isnt that a mainline feature now anyway ?
<soren> ogra_: The basic dom0 support, yes, but a number of extra options need to be enabled for it to actually *work*.
<ogra_> well, what i read was that ll needed features are mainlined in 3.0
<soren> ogra_: One wonders what the use is of a kernel with dom0 support enabled, but not all the other stuff, but meh.
<ogra_> so why would someone disable them :)
<soren> I don't know. I don't know why Kconfig even allows it.
 * ogra_ thinks the oneiric kernel is just not up to date yet
<soren> 2.6.39 has the relevant stuff, too.
<soren> Just not all the right stuff *enabled*.
<soren> At least that's my current working hypothesis.
<soren> It's not booting, and that page I linked to above says that these things should be enabled, and they're not, so it seems like a good guess that that's why it's not booting for me.
<soren> I'll know more once I get around to building a kernel with those things enabled.
<soren> Oh, darn it, it actually works on this box.
<soren> /ignore me
<lool> smb: Oy
<smb> lool, Sup?
<lool> smb: Would you mind cherry-picking "UBUNTU: Include nls_iso8859-1 for virtual images" to natty and maverick?
<lool> fs/nls/nls_cp437.ko was picked in the natty but not iso8859-1
<smb> lool, Thought we sort of had. But I might confuse it or its just stuck in proposed... 
<apw> cjwatson, thanks for the heads up on 3.0
<lool> smb: looking at tip of natty.git, it's still missing iso8859-1
<lool> I'm still checking maverick
<apw> smb, yes holiday today
<lool> (slooowwwww checkout over ecryptfs)
<smb> apw, And another one who cannot stay without irc. :)
<lool> smb: oh are you on leave too?
<lool> sorry about that
<lool> I saw Thursday is a big leave in Europe
<smb> smb, Nah, /me is Germany. 
<apw> smb yep
<smb> No holiday today. Only UK
<smb> and US
<lool> smb: right, maverick also only has nls_cp437 and not nls_iso8859-1
<smb> lool, for maverick it seems to be in master-next
<lool> smb: also, will there actually be some SRU of linux in maverick and natty still?  I don't know how long the non-LTS releases get kernel SRUs
<lool> smb: ahhh master-next gah
<smb> lool, 79cc10ef1158acc18688a0594a7fcda9921a11ce
<lool> smb: I see it in natty msater-next as well
<lool> and in maverick master-next too
<lool> I had completely forgotten about this master-next branch
<smb> lool, Yup, so just paaaatience. :)
<lool> smb: is there a set cadence for the SRUs in non-LTS as well?
<smb> lool, Yes there is a cadence
<smb> But for Maverick, we just found some problem with that and ec2
<lool> I don't need it urgently, but we have a Linaro engineer who is setting up jenkins to start instances to do builds with a fixed kernel, and it's not trivial to arrange to upgrade the kernel and reboot (new ABI!) before kicking the build
<lool> smb: ah, but not due to these patches I would hope?
<smb> lool, No there was some Xen change that has unexpected results for us
<lool> Ok
<lool> I've told her to build the .ko locally with the old ABI and wget them on boot now
<lool> thanks for confirming the commits are in there!  I thought the fix had fallen through the cracks
<lool> smb: maybe I should reset the bug tasks to work in progress or triaged until there's an upload to -proposed?
<lool> (they are fix committed which is usually the bug state after a -proposed upload happened)
<smb> lool, Well there are uploads to proposed, just not what is in master-next necessarily. And no, fix committed always was just commited to repo. Not necessarily uploaded anywhere
<smb> At least the way we had been using that state
<lil_pete> hey guys i want to boot a custom kernel on 10.10, but during boot it ignores my /boot/grub/menu.lst 's 1st entry (--> custom kernel)... am i missing something here? 
<jk-> lil_pete: I don't think menu.lst is used anymore
<smb> lil_pete, menu.list is only used with grub1, grub2 has grub.cfg
<lool> smb: Ok; I was suspecting that for kernel the state was slightly different; the SRU processing scripts usually set fix committed when the package is accepted into -proposed
<lil_pete> jk-: erm... okay. so i have to edit grub.cfg? 
<lil_pete> "do not edit this file" lol 
<jk-> lil_pete: would be better to add a /etc/grub.d/nn-my-custom-kernel
<smb> Yes, it is completely regenerated, so it might not be very persistent. Depending how "custom" the kernel is (ie not using the debian build scripting) you probably have to do like jk- said
<lil_pete> jk-: examples anywhere? /etc/grub.d/* looks like scripts finding everything... strange it doesnt find my kernel though i copied it to /boot/
<lil_pete> smb: im not sure about the "customness" :) got the sources from kernel.org, did a configure + make
<jk-> lil_pete: I'm no grub expert, but it looks like you just create a shell script that outputs a 'menuentry' stanza
<smb> lil_pete, That probably is custom enough. You would have to look at the existing parts in grub.d, but it may be that is looks for system map or other parts than just a kernel image to detect it as a bootable kernel.
<jk-> the 10_linux script will pick up your kernel if you've named it according to a specific pattern though
<jk-> list=`for i in /boot/vmlinuz-* /boot/vmlinux-* /vmlinuz-* /vmlinux-* ;
<lil_pete> i want my oldschool-grub back :(
<lil_pete> got a "/boot/vmlinuz-2.6.39"
<lil_pete> i _think_ that should be recognized?! 
<jk-> did you do a `sudo update-grub` ?
<lil_pete> jk-: ...
 * lil_pete is the dumbest a$$ in this channel.
<lil_pete> i only did a grub-mkconfig
<jk-> :D
<lil_pete> ill be back in one 2.6.39 boot time :D hopefully... :) 
<smb> hopefully he did not need to run update-initramfs, too
<ppisati> CVE 2010-4655
<ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4655)
<ppisati> looks like there's a duplicare
<ppisati> duplicate
<ppisati> lp#771445 is the right one
<ppisati> lp#771442 is untouched
<ppisati> lp#771445
<ppisati> lp771445
<smb> bug 771445
<ubot2> Launchpad bug 771445 in linux-ti-omap4 "CVE-2010-4655" [Undecided,In progress] https://launchpad.net/bugs/771445
<ppisati> bug 771442
<ubot2> Launchpad bug 771442 in linux-ti-omap4 "CVE-2010-4655" [Undecided,New] https://launchpad.net/bugs/771442
<smb> ppisati, At least the titles look duplicate. Depends a bit what/who opened them. Could it be a slight issue when doing some automatic updates...?
<ppisati> smb: both leann
<lil_pete> well... it does load my kernel, but it doesnt boot. ill figure that out. thx for the advice guys. :) 
<smb> lil_pete, I was wondering whether you had installed all the modules and also run update-initramfs to generate an initrd...
<lil_pete> nope
<lil_pete> im trying make-kpkg now
<smb> ppisati, I would tend to mark the one without anything done to it as duplicate of the other. You may wait till tomorrow to check back with Leann though
<ogasawara> ppisati: I can't remember why I would have opened two bugs, I'd mark the untouched one as a duplicate of the other.
<smb> Argh, yet another holiday zombie. :)
<ogasawara> smb: I actually swapped today's holiday for last friday, so I'm workin today
<ppisati> ogasawara: ok
<ogasawara> bah, be back in a bit, lil guy woke up early
<smb> ogasawara, Ahh. :) I was becoming a bit worried that I don't spend my holidays on irc. :-P
<lil_pete> smb: would make modules-install install all i need? 
<smb> lil_pete, It would install the modules, but not generate any initrd
<lil_pete> hhmmm no rule for modules-install ? 
<smb> was that modules_install 
 * smb has not used it for a while
<qwerty_> hii
<qwerty_> i am trying to compile the latest version of ubuntu kernel
<qwerty_> i've come across some messages "section mismatch "
<lil_pete> smb: hehe ill try
<lil_pete> hitting tab takes forever... :-/ 
<lil_pete> smb: make modules_install it is. :) 
<qwerty_> hii
<lil_pete> smb: update-initramfs --> anything i should be looking out for? 
<smb> lil_pete, Normally "sudo update-initramfs -u <whatever the dir for you modules is named in /lib/modules>
<lil_pete> smb: seemed to work without that dir (that got me an error message), i had to pass -k 2.6.39 though. anyway... ill reboot. this is gonna be really thrilling :D
<smb> lil_pete, Oh, yeah, sorry -k and the version or dir name
<lil_pete> np :) 
<smb> Comes if one does not call things too often by hand
<lil_pete> smb: i got nearly everything in /boot now, except "abi-2.6..." do i need that? 
<smb> lil_pete, I do not believe this is strictly needed
<lil_pete> alright, ill try rebooting... cya in a min. :) 
<lil_pete> smb: im up and running now, thx. :) 
<smb> lil_pete, welcome :)
<ogasawara> whoa, looks like Oneiric will be 3.0
<smb> ogasawara, Yep, surprise! :)
 * ogasawara wonders how many of our scripts will be messed up
 * _ruben feels sorry for you guys... 
<smb> Me too... There will be quite a few I expect...
<smb> And there might be packaging issues. Though maybe not too bad as 3.0.0 seems to be < 3.0 ... but then we have stable/longterm...
<ogra_> lovely, so i will be able to ask the kernel team all my perl questions after this cycle !
<_ruben> haha
<smb> ogra_, We'll rewrite everything in python... ;-P
<ogra_> lol
<ogra_> to speed up the buildtime, right ? :)
<smb> Hehe, of course. 
<vmlinuz> all, I've updated my Lucid to the latest kernel updates and it's now freezing my system. How can I start to troubleshoot and gather information to file a bug?
<Tommeh> Regarding the packages here: http://kernel.ubuntu.com/~kernel-ppa/
<Tommeh> If only some packages appear in a given directory (i.e. some are missing), is it because the kernel failed to build/was pulled/hasn't been done yet, or something else?
<smb> Tommeh, Most likely because a build failed. 
<vmlinuz> how can I start troubleshooting a system freeze on Lucid?
<Tommeh> vmlinuz, is it just a graphical freeze? 
<Tommeh> Or total system
<smb> vmlinuz, probably looking into /var/log/syslog whether there is anything. Trying to ssh into it to see what Tommeh said
<Tommeh> Of course, the most obvious thing to do would be to see if anything was logged up until the point where the system froze.
<vmlinuz> Tommeh: I'm not sure if it's only a graphical freeze, because I'm not able to switch to text/console
<vmlinuz> Tommeh: think this is a total freeze
<vmlinuz> smb: right
<Tommeh> Ok. As said, it's worth checking to see if ports/services are still available over the network. Alternatively it's also worth testing the shutdown button to see if the machine shuts down/suspends when pressed.
<Tommeh> Also vmlinuz, you don't say at what point after boot-up the machine freezes?
<vmlinuz> Tommeh: I don't know exactly.. random freeze
<Tommeh> Before logging in/after ?
<Tommeh> Or both?
<vmlinuz> Tommeh: after loggin
<Tommeh> Ok
<Tommeh> Are you using compositing?
<Tommeh> Compiz/unity, etc.
<vmlinuz> Tommeh: compiz
<Tommeh> I can't remember if there's an option on the lucid login screen to disable effects -- try that.
<Tommeh> If that fixes it, you can be fairly sure it's related to your GPU/mesa in some way.
<vmlinuz> Tommeh: makes sense.. I'll try to login without 3D effects
<vmlinuz> Tommeh: thanks a lot!! Appreciated
<Tommeh> Graphics stack in Lucid isn't particularly up to date, tbh.
<vmlinuz> /var/log/syslog still saves the crash messages even after I reboot?
<vmlinuz> brb :)
<vmlinuz> Tommeh: I'm without composite (selected Failsafe GNOME on GDM screen)
<vmlinuz> Tommeh: let's see if it doesn't freeze anymore :)
<Tommeh> vmlinuz, any luck?
<vmlinuz> Tommeh: yes, you were right... after disabling composite, it's working stable now
<vmlinuz> Tommeh: I need to find a way to start compiz, compositing in debug mode to gather more info to file a bug
<Tommeh> Mmm.. What GPU do you have?
<Tommeh> Or rather, which driver are you using?
<Tommeh> I'd suggest seeing if something like openarea causes the same lockups.
<vmlinuz> Tommeh: 'lspci' says "00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)"
<Tommeh> Weird
<vmlinuz> Tommeh: my '/var/log/Xorg.0.log' says  `LoadModule: "intel"`
<Tommeh> Well, it's Intel-based anyway, so that narrows the potential drivers to 1 :)
<Tommeh> If you find that GL apps consistently crash, you might have more luck in #intel-gfx (I think that's the right channel)
<vmlinuz> Tommeh: thanks, appreciated your help!
<vmlinuz> Tommeh: now, it's confirmed it has nothing to do with kernel update itself, but with composite/driver
<akgraner> apw is there a wiki page that walks someone through updating a kernel
<akgraner> or would someone for the team be willing to pop into #ubuntu-locoteams to answer that question?
<cjwatson> 14:37 <smb> And there might be packaging issues. Though maybe not too bad as 3.0.0 seems to be < 3.0 ... but then we have stable/longterm...
<cjwatson> smb: was that a typo?
<cjwatson> as I mentioned, 3.0.0 > 3.0 :-)
<ogasawara> May 30 05/30/11:00:51:00 <cjwatson>     hmm, so regarding 3.0; the kernel team knows that 3.0.0 < 3.0 as far as dpkg is concerned, right?  we'll need to be careful when uploading the RCs ...
<ogasawara> cjwatson: ^^
<ogasawara> cjwatson: I just want to make sure I have it clear in my head, 3.0.0 > 3.0 
 * ogasawara plans to discuss our versioning with apw tomorrow
<cjwatson> I'm sorry, I did mean > in the line you quoted above
<cjwatson> i.e. that if you upload 3.0.0-1 (say) then you can't subsequently upload 3.0-1
<cjwatson> or 3.0-1000 for that matter
<ogasawara> cjwatson: right, that makes sense to me
<cjwatson> just jumped out at me as a really easy way to shoot oneself in the foot in this situation
<ogasawara> cjwatson: indeed
<dupondje> Hi ! Any plans for an updated kernel on Natty ?
#ubuntu-kernel 2011-05-31
<smb> morning
<smb> cjwatson, I took the quote from irc. So we already start to get really confused. :) Ok, 3.0 < 3.0.0 sounds more matching my string compare mindset.
 * apw yawns
<jk-> hey smb & apw
<apw> jk- morning :)
 * jk- gives smb a handful of spare zeros
<smb> jk-, Heya
<apw> smb, hows the mainline builds
<smb> jk-, apw may need them too
<apw> smb, yeah if leann hasn't fixed everything :)
<smb> apw, I think for the  moment the kernel side of scripts does not like 3.0
<apw> that i can believe ... bah
<smb> smb, I think I got the build-one script in a usable state
<smb> though still exiting early for debug
<smb> but we could enable everything this morning and see
<smb> apw, If you got your toast and more important cup of tea or coffee
<apw> smb, i'll get the kettle on
<apw> smb, do you know if leann was looking at the kernel side or am i clear to poke that nest?
<smb> apw, I don't know for sure but I cannot believe she had not. Wanted to discuss with you later today (or sooner depending on little one :))
<ogasawara> apw: I sent you email, but basically I've rebased Oneiric to v3.0-rc1 and pushed to my personal repo
<ogasawara> apw: git://kernel.ubuntu.com/ogasawara/ubuntu-oneiric.git master-next
<smb> there she is... :)
<ogasawara> apw: it obviously fails to build if I use a version of 3.0-0.1
<smb> ogasawara, yeah, seems the config script messes up
<ogasawara> apw: so I've temporarily used 3.0.0-0.1, ironed out the build failures
<smb> and leaves KERNEL_VERSION emtpy in the .h
<ogasawara> apw: and wanted to chat with you later about how we want to version
<smb> ogasawara, He went for the kettle I guess
<apw> ogasawara, as i understood things he is going to call tings 3.0, 3.1, 3.2 etc and stable will be 3.0.1, 3.0.2, 3.1,1, 3.1,2 etc right ?
<ogasawara> apw: that's what I'd heard also
<smb> Me too
<apw> so presmably the logical naming is to use 3.0 before the -, and never change it for the kernel similar to how we never change the 2.6.38 
<smb> Sounds like the only issue is that when you have to go with 3.0.0 atm due to scripts, it gets a bit messy package version wise
<apw> yeah so it sounds like we want to fix that for the 3.0 branch, i can have a look at that today
 * apw had really hoped he would release just one more 2.6.x ... sigh ... so we could avoid this till PP
<ogasawara> apw: would we wanted to consider adopting 3.0.0, 3.1.0, 3.2.0...?? to make things easier?
<ogasawara> s/wanted/want/
<apw> ogasawara, i guess the right answer is 3.0, so i am thiniking i want to know how bad coping with that would be
<smb> It could be a simple work-around to the problem
<apw> yeah
<apw> yeah i assume that just works (tm) as its the right shape, well once all the references to -2.6 are fixed 
<ogasawara> apw: if you want to take a stab at making 3.0 working that would be cool with me too
<apw> ogasawara, well (assuming sleep is in your future) i will poke the snakes and see if 3.0 can be made to work
<ogasawara> apw: cool.  indeed I'm only temporarily awake right now :)
<smb> apw, It was actually not looking that bad at least for the mainline scripts I looked so far
<apw> and if not then we can compromise on 3.0.0 for now and perhaps firx it for PP
<apw> ok deal, i get snake duty 
<ogasawara> apw: sounds good.  I'll wonder back off to bed :)
<smb> ogasawara, night. :)
<smb> or rest of it
<ogasawara> heh
<apw> night :)
<smb> apw, So up to now I only changed build-one in the kteam-tools subdir
<smb> To make always a 3 digit version
<ogasawara> apw: but as a reminder, if we did use 3.0.0, we really couldn't go back and used 3.0 later as 3.0 < 3.0.0 
<apw> ogasawara, yeah, we'd be commited for oneiric if we use 3.0.0 ...
 * smb thinks a ghost .0 for 3.0 is a lesser evil given the rush big L had with getting the numbers jumping
 * ogasawara really goes to bed now
<apw> yeah, i think its worth spending a little time seeing if it can be fixed, we're on hold for A1 anyhow so we arn't in a rush, and likely we'd not upload an -rc1 in the middle anyhow, so we have another week maybe and a half before we need something to work
<smb> And depending on how things move along maybe we finally release with a 3.0.x level anyway...
<apw> smb, yeah buts that is still a 3.0 version under our scheme
<apw> as our 38.13 version is still 2.6.38-9.42
<smb> yeah right...
<apw> smb now i think about it, i'd almost be more inclinded to use 2.6.41 for a bit till we fix it, in case linus changes his mind
<smb> on the other hand, maybe people would not be too disappointed by seeing the stable release the package is based on in the version number...
<apw> smb, indeed perhaps not, well i'll see how bad things are, and then we can decide more formally
<smb> apw, True, if "he" had heard his voices sooner we could have had a bit of a more interesting uds session on it... :)
<apw> smb, poop he hasn't decided how to represent the version in the tree yet, thats not helpfil
<smb> Thought to have heard rumours about renaming or opening a new one... but as you say, probably nothing really decided yet
<apw> smb, oh i meant in the Makefile, so this kernel reallly calls itself 3.0.0-rc1 but because otherwise the tree won't work
<smb> Ah. Yeah
<alkisg> Package linux-image-generic-lts-backport-natty is missing in Lucid, should I file a bug report for it, or is it being taken care of, or it's not even in the plans to provide such a package?
<apw> alkisg, its in progress, via the kernel stable team
<alkisg> Thank you
 * smb needs more coffee...
 * abogani needs too
 * ppisati goes out to do some grocery (and get some food)
<apw> arggg, depmod assumes a command line arg is a kernel version number if it is x.y.z form ... ARRG
<smb> that is a far dependency indeed...
<apw> ogasawara, so i think i have the kernel bits fixed for 3.0, but am just workign on depmod which is a little brain dammaged ... getting there
<vmlinuz> Tommeh: today, I was running GNOME without 3D effects and it froze again
<vmlinuz> Tommeh: the only option that worked (till now) is 'Failsafe GNOME' in GDM
<Tommeh> It has reduced the frequency of freezing though?
<vmlinuz> Tommeh: yes, disabling 3D effects yes
<Tommeh> Are you sure it's not just coincidence and your GPU is broken?
<Tommeh> Or overheating.
<abogani> vmlinuz: What video driver are you using?
<vmlinuz> abogani: 'intel'
<abogani> vmlinuz: i915?
<vmlinuz> abogani: (II) LoadModule: "intel"
<vmlinuz> abogani: from my /var/log/Xorg.0.log
<vmlinuz> abogani: (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
<vmlinuz> abogani: this 'i810' is the correct answer?
<abogani> vmlinuz: yes
<vmlinuz> Tommeh abogani I've found this doc yesterday: https://wiki.ubuntu.com/X/Troubleshooting/Freeze
<vmlinuz> I'll try to follow that and see if I find anything else
 * apw steps out
<smoser`> smb around ?
<smb> smoser, Yes, whats up?
<smoser> it looks like linux in lucid went proposed -> updates yesterday, but linux-ec2 is languishing
<smb> smoser, hm... usually not that much under my control but we can ask ...
<ogasawara> apw: ack
<JFo> smb, what do you think of bug 790609 ?
<ubot2> Launchpad bug 790609 in linux "EC2: 2.6.39 oneiric kernel only sees 525MB total memory on t1.micro" [Undecided,New] https://launchpad.net/bugs/790609
<smb> JFo, They should be glad it works ... Not much yet. The config limit should have been lifted since natty now...
<JFo> ok cool
<smb> Oh, wait
<JFo> heh
<smb> That might be something to do with the way they change initial mapping
<smb> But I would need to look into that 
<smoser> "they should be glad it works" :) nice.
<smb> smoser, I guess you opened it then. :)
<JFo> ok, no problem, just wasn't sure if there was anything I could do to it. I am assuming not
<smoser> i did not. and its makes me really happy that someone else is using development release prior to alpha.
<smb> smoser, That is probably true... "[ 0.000000] Memory: 521872k/4202496k available" that would look a bit scary if that is true...
 * ogasawara back in 20
<apw> ogasawara, ok i think this can be done, with a fix to module-init-tools, though i am not sure the kernel is 'good' on intel graphics
<apw> ogasawara, have you boot tested this thing anywhere?
<ogasawara> apw: not yet, am hammering out build failures on arm and i386
<apw> ogasawara, ok cool
<cjwatson> apw: depmod> http://fedorapeople.org/~kyle/fix-depmod-for-linux-3.0.diff
<mjg59> Upstream should be fixed
<mjg59> (Assuming you trust jcm)
<apw> cjwatson, right, i want that fix, which does indeed match what i've applied locally to fix things
<apw> mjg59, right i was thinking about pulling in upsteam latest
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<JFo> is Karmic EOL today? :)
<JFo> or was it a bit ago?
<JFo> and I missed it
<smb> JFo, Just by a month iirc
<JFo> hmmm, ok
<smb> Just to avoid my usual ambiguity: I think it was EOL end of this April
<ppisati> not kernel related but: doesn't ubuntu package match 1:1 what we have in bzr?
<ppisati> [flag@newluxor canonical]$ dpkg -l | grep lxc
<ppisati> ii  lxc                                   0.7.4-0ubuntu7.1                           Linux containers userspace tools
<ppisati> [flag@newluxor canonical]$ cd lxc
<ppisati> [flag@newluxor lxc]$ bzr tags | grep 0.7.4-0ubuntu7
<ppisati> 0.7.4-0ubuntu7       15
<ppisati> where the .1 comes from? and what does it contain?
<sconklin> JFo: Dapper server officially dies June 1
<JFo> sweet! ;)
<JFo> smb, I knew what you meant :-P
<sconklin> par-tay
<JFo> oh yeah
<mfilipe> sforshee, thanks again for your effort to fix the problem with two monitors in intel graphic card :)
<smb> bjf, sconklin Do our current SRU policies allow for a slightly stretched use of the term bug (iow something that may not be considered a bug upstream and so won't make it stable there)?
<sforshee> mfilipe, np
<smb> sconklin, We will have to make a celebration in Dublin... :)
<sconklin> smb: best way to find out is to write an SRU request.
<mfilipe> sforshee, do you know if there is a solution in 2.6.39-rc*? 
<smb> JFo, Good, I am just happen to think so often whether I wrote something that could mean something completely different in English
<JFo> the clarification was appreciated. :-)
<sforshee> mfilipe, 2.6.39 final is out and I don't think there's any fix in there, but you could always test it to be sure
<sforshee> I don't have affected hardware to test with
<JFo> but it confirmed my suspicion :)
<smb> :)
<smb> sconklin, Doing a SRU request means to spend time on it... :-P Oh, well ok. :)
<mfilipe> sforshee, ok, I always will update the launchpad and freedesktop with news
<bjf> smb, rule #1: The kernel team uses common sense to determine if a patch should be accepted or not for SRU.
<mfilipe> thanks
<sconklin> smb: yes, but I can't say whether it will meet the two-ack requirement by myself ;-) There's no "dictator" in my title
<smb> bjf, of rule #5 
<smb> or
<bjf> smb, i can't get to that page right now but i think i know the rule your are talking about and I don't believe in invisible boogey men, so i don't hold to rule #5
<smb> bjf, There certainly was one ir two cases of it in the past, but I think this one may be ok. Its just a bit closer to feature than bug from upstream point of view. But I'll prepare patche(s) 
<JFo> you guys are crackin' me up.
 * smb is not very successfully splitting himself up between two channels
<brendand> hi sconklin
<sconklin> brendand: hi
<brendand> sconklin - are the new proposed kernels on track?
<sconklin> yes, but we have not completed the previous cycle yet, so we will not begin a new cycle today as planned.
<sconklin> I expect that we will slip a week
<sconklin> and have kernels in -proposed by next Monday
<brendand> sconklin - all of lucid, maverick and natty?
<sconklin> Next Monday, yes.
<sconklin> We will revert all the USB3.0 patches (3) that were in the last Natty -proposed, and not publish that kernel. Problems have been discovered, but we have not had the cooperation we need from the reporters to isolate it. So I;m going to pull all 3 patches
<sconklin> we will see whether we can isolate the problem separately and resolve that.
<brendand> sconklin - i don't recall hearing about that on the mailing list?
<sconklin> That one is in the tracking bugs.
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/769042
<sconklin> One of the big problems we have is that information is getting split between the mailing list and the tracking bugs, and they don't always track. Starting with this cycle we are using the new workflow tools. Expect email about that on the list.
<brendand> sconklin -  wasn't there an email after that saying it was okay to test that kernel?
<sconklin> which kernel? There was an email saying "Do not publish Lucid" which was ignored.
<sconklin> We weren't certain until last week that there was a real issue with USB3 on Natty, and then decided that it was probably a real problem
<brendand> sconklin - okay. i think there has been some miscommunication here. as you said, hopefully the new workflow can address these things.
<brendand> sconklin - i think i wasn't looking in all the right places for updates
<sconklin> brendand: I agree. The last cycle was a complete wreck
<sconklin> an ongoing train wreck
<brendand> sconklin - my feeling is that if something comes up that would stop a kernel from being published then an email needs to be sent to kernel-SRU
<sconklin> brendand: well, I agree. And I did send email, and the kernel was published anyway
<sconklin> I thought that "Do not publish Lucid or Maverick kernels until further notice." was pretty unambiguous, but I guess not
<brendand> sconklin - yes. and we stopped testing it at that very moment (although we'd already tested lucid the week before)
<brendand> sconklin - and it was very unambigious
<brendand> sconklin - can i ask, when was it confirmed that Natty was a no go as well?
<sconklin> Natty was set to verification-failed on May 4th
<sconklin> and was never set back to anything else. 
<sconklin> There was some debate on the team about overriding that, but it remained so, and will . . .
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/772096
<ubot2> Ubuntu bug 772096 in linux "linux: 2.6.38-9.43 -proposed tracker" [Medium,Fix committed]
<bjf> ##
<bjf> ## Kernel team meeting in 7 minutes
<bjf> ##
<smb> the race is about to begin
 * JFo tightens his laces
<sconklin> and although for Lucid the "don't publish" email was sent on May 25th, on May 27th the QA team marked the tracking bug as "verification-done" and it was subsequently published
<sconklin> brendand: ^^
<sconklin> brendand: I accept responsibility for not updating the tracking bug in addition to sending the email
<ogasawara> apw: I've boot tested on 2 amd64 machines and 1 i386, all intel hw, all booted fine and appear operable
<apw> ogasawara, thanks, could you (1) push me a test binary somewhere (feel free to /msg me where they are) and (2) push your current tip to the same place :)
<ogasawara> apw: yep, will do after the meeting
<JFo> <-lunch
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - June-7 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<bjf> ogasawara, heads-up, looks like someone else will need to run the meeting on June 14. I'll be traveling to Millbank
<ogasawara> bjf: ack, I'll put it on my todo list
<scott-work> hello everyone, which kernel version is planned for oneric?
<vanhoof> ogasawara: off hand do you know if there has ever been any storage related l-b-m work?
<vanhoof> ogasawara: all I've ever came across has been network, or audio
<ogasawara> vanhoof: I can't recall any off the top of my head
<vanhoof> if not, is it even feasible?
<ogasawara> vanhoof: possibly, which driver?
<vanhoof> ogasawara: this beast :) https://lkml.org/lkml/2011/5/13/380
<ogasawara> vanhoof: whoa, 46 files changed, 27172 insertions(+), 0 deletions(-)
<ogasawara> vanhoof: would this be wanted for Natty?
<apw> ogasawara, http://people.canonical.com/~apw/master-next-oneiric/ has the kernels, you need the module-init-tools change installed _before_ you install them too else it breaks ... if you could let me know if they boot on either of your boxed be nice to know :)
<ogasawara> apw: ack, I'll install now and test
<vanhoof> ogasawara: yeah that's what I'm looking at now; couple folks have been doing builds on natty and it works
<vanhoof> ideally I'd like to see this on oneiric, but trying to figure out what options could be put together if any
<vanhoof> short of something frankenstein like :D
<vanhoof> I've only seen one request so far for this controller, so I'm not sure how many others would benefit
<ogasawara> vanhoof: I haven't read through the thread, any mention when this might officially land in mainline?
<ogasawara> vanhoof: Oneiric is going to be v3.0
<vanhoof> ogasawara: last I read .40, I guess 3.0 now :)
<vanhoof> let me double check
<vanhoof> ogasawara: not much beyond just that thread, so not entirely sure if it'll make its way in
<vanhoof> ogasawara: I'll just monitor to see if and when it does land
<vanhoof> really just wanted to see if something like l-b-m would even be do-able for a driver like this
<ogasawara> vanhoof: there indeed has been precedence for something like this via LBM but with other subsystems (eg audio, compat-wireless, etc)
<ogasawara> vanhoof: and as LBM is an elective install and we could give it it's own lbm-scsi package or something so it might be do-able
<vanhoof> yeah I thought about this as we did something similar for e1000e in 10.10 
<ogasawara> vanhoof: but obviously best case scenario is that it'll land and we won't have to do anything
<vanhoof> ogasawara: yeah im guessing by the time oneiric roles around this would be a non-issue provided this driver does merge, just wondering how much of this controller we'll see before oneiric releases
<vanhoof> ogasawara: ill keep tabs on it for it to merge, and then see if we have more demand for this controller
<ogasawara> vanhoof: sounds good
<vanhoof> ogasawara: thank you :)
<ogasawara> apw: your test kernels boot on my test machines here
<ogasawara> apw: I've got a couple more patches for powerpc build failures, but I can wait to push to master-next after you do
<hallyn_> uh, CONFIG_NET_NS got unset in lucid kernel update?
<hallyn_> i thought someone had asked whether that would cause problems and the answer was yes
<hallyn_> smb: ^
<apw> ogasawara, just push your stuff, my changes rebase easy
<ogasawara> apw: cool, pushed to my repo
<Phoenix][> hi there, is there an experimental ppa for natty / 2.6.39 (release version, no rcs) available?
#ubuntu-kernel 2011-06-01
<firewave> Hey folk !
<firewave> Some people here may tell me how to set the version name of the kernel when compiling it from apt source ? Like '0ubuntu2' ?
<firewave> I'm starting a PPA but all my custom kernels had no version string (sad)
 * smb crawls in
<jk-> hey smb
<jk-> any decision on the 3.0.0.0.0.0 ?
<smb> jk-, yep we use 10 0
<smb> no 11 
<jk-> awesome
<smb> or maybe 12
<apw> jk-, yeah we're getting there, 3.0 breaks a module-init-tools
<smb> maybe we encode 11.10 in binary :-P
<jk-> apw: yeah, I heard fedora have recently patched it.
<apw> yeah we have the fix, but we're not keen to update it this close to A1
<ohsix> a1 for oneiric?
<apw> ohsix, yes
<ohsix> interesting
<jussi> Good Morning Kernel Superstars!
<jussi> Is there any other information you would like from me regarding bug 791064?
<ubot2> Launchpad bug 791064 in linux "Total lockup (Hard reset rquired)" [Undecided,New] https://launchpad.net/bugs/791064
<abogani> jussi: Could you try to 1) remove quiet and splash kernel command line options, 2) login remotely on that machine through ssh immediately after boot 3) login in without 3D effects, please?
<jussi> abogani: could you give me a little further instruction? How do I do 1. what information do you want from the ssh login? What information do you want after I login without 3d effects?
<jussi> abogani: please understand, this just happened, when I reboot, things are ok)
<apw> jussi, i think he is assuming it is reproducible
<jussi> apw: ahh, it comes occaisionally, but isnt reproduceaable on demand.
<apw> jussi, it would be helpful if you could describe what you could see when it hangs
<apw> is the screen blank, still has data on it, does the mouse move, does your wireless/lan light still flash
<jussi> apw: ok, Ill do it hwere and add it to the bug if useeful.
<apw> does the machine respond to the network via ssh etc etc
<apw> as 'hangs' is not very meaningful when reading
<jussi> The screen goes blank, with the exception of the mouse pointer (non moveable)
<jussi> I did not try get in with ssh at this time.
<jussi> Using REISUB the machine did not respond
<jussi> Hence I thought it may be a kernel issue
<apw> jussi, yes probabally is, very hard to know what it is from the original report, with the black screen and visible cursor thats more helpful and might indicate a graphics issue
<abogani> REISUB?
<apw> sysrq-X letters
<jk-> heh
<jussi> apw: ahh, thanks for updating the bug, was just getting to it. 
 * ppisati be back in a bit...
<ppisati> ok, sent
<apw> sconklin, what the heck happend to the lucid master branch, it got rebased?  we have lost a version completely according to the changelog, is this what we intended ?
<ppisati> sh*t
<ppisati> i forgot i rewrote the latest UBUNTU commit in fsl-imx51
<ppisati> because i couldn't make fdr printchanges work
<apw> heh
<apw> i don't think its worth worrying about
<ppisati> but it's no more a pull, it's a reset req
<ppisati> wait
<apw> ppisati, thats not really anything to stress anyone
<apw> the Ubuntu- needs fixing for the tooling to work anyhow
<ppisati> apw: too late, sent
<Kano> hi, in the 3rc1 dir is a headers deb too much and 32 bit is missing
<apw> Kano, doesn't supprise me, the switch to 3.0 has cause utter kaos
<Kano> daily only has got the 32 bit deb missing
<apw> Kano, ok i got rid of the original failed header
<Kano> fine
<Kano> i think the same module fails with 3 as it did with .39
<Kano> maybe use the same patch?
<apw> any add-hoc patches would apply if the files were unchanged
<apw> ppisati, ok applied
<ppisati> apw: cool
<ppisati> apw: lunch now, later i'll push the ti-omap4 equivalent
<apw> ppisati, works for me
 * apw steps out
 * smb needs to re-login
 * ogasawara back in 20
<smb> apw, I had been pulling in cve-tracker changes from security (D-DoD) and resolved the few conflicts. Its pushed out again
<cr3> is there a way to identify the form factor of a system programmatically? dmi may provide this information in the chassis section, but this is defined by the hardware vendor so might contain anything like "Netbook PC" or just "Computer" for example
<sconklin> apw: I rebased the lucid tree. We had pushed the next release, which FTBFS because the kernel is proposed (which was not supposed to be published) had been published. This forced an additional ABI bump, and in order to make it properly bisectable with the coorect ABI bump, it needed to be redone. All the tags are still there, except the kernel which never built
<apw> sconklin, well i seem to have a tag for the missing one, which is how i noticed
<sconklin> It's possibly local. In any case that extra tag shouldn't matter, as we'll never deliver that version
<sconklin> I'm not sure how you make sure a local tag is deleted when fetching from a repo in which one has been
<apw> sconklin, not sure you can, deleting tags is not really someone one does i guess
<sconklin> apw: I knew it was not a perfect solution when I did it
<apw> cirtainly caused a heap of confusion here when the cve tracker updater moved all the cves forward a revision
<sconklin> well, at least I also thought to change the tracking bug for it. Next time I do something like this, I'll email the list
<apw> sconklin, so you have deleted the tag for this aborted release ?
<apw> even though it was uploaded?
<sconklin> yes, as it failed to build on the PPA, and has been deleted, and was never copied to -proposed
<sconklin> although it wouldn't bother me to have the tag repushed if you have it, I have no strong feelings either way
<apw> sconklin, i guess if the LP librarian doesn't know the version thats ok
<sconklin> I can only foresee a problem if someone tries to push it again, and it should fail, and I don't care why . . .
<sconklin> it's already been replaced by a higher version
<sconklin> in the PPA
<apw> sconklin, ok ... gone in mine too
<Kano> mjg59: did you look at the reboot code?
<mjg59> Kano: No, I ignored it totally
<jonpry> mjg59, did you ever find anything in those logs from my lenovo y560p? I would like to work on this bug. If you have any ideas on what the problem actually is, that would be helpful
<mjg59> jonpry: Haven't had a proper chance to look. I have some suspicions.
<jonpry> hmm
<jonpry> I'm sure your guesses are better than mine. Care to elaborate?
 * ppisati -> gym
<lamont> 2.6.32-32-generic-pae seems to have horribly regressed wrt actually passing traffic around as a NATting firewall.  this is sadness to me
<bjf> sconklin, ^
<lamont> I trusted you guys so much, and the telco so little, that I spent about 3 hours fighting with it before downreving the kernel and having happiness
<sconklin> lamont: I have a vague memory of smb or jjohansen mentioning something related to this
<sconklin> lamont: are you running it in xen?
<sconklin> ;-)
<smb> That would cause it not to boot
<sconklin> smb, sorry it was a bit of a joke.
<smb> lamont s trouble sounds a bit more networking related... Oh. Doh! :)
<lamont> sconklin: nope.  on hardware, as the firewall between me and the internet
<jjohansen> sconklin, lamont: I don't remember any regression for network natting
<lamont> interestingly, it mostly just works
<lamont> wget from a machine on the internal side, routing out PPPoE to the DSL world hangs at random intervals
<jjohansen> lamont: how many iptable rules?
<smb> sconklin, On the topic of lucid and xen: I am about to push the rebased ec2 branch and upload it to c-k-t ppa
<jjohansen> lamont: scratch that, at random intervals sounds like an interrupt regression
<sconklin> smb: ok.
<sconklin> lamont: have you tried non-pae?
<bjf> smb, did you add a tracking bug?
<lamont> for t in filter nat mangle; do echo $t $(iptables -t $t -nvL | wc -l); done
<lamont> filter 242
<lamont> nat 58
<lamont> mangle 79
<lamont> sconklin: I have not.  and my fellow  users tell me I can play outside of the 9-9 window (-0600)
<smb> bjf, Bah, no
<lamont> watching tcpdump on port 80, I was seeing the 3-way, then traffic to the site, traffic back (with the ack of the sent data), ack going back to the site, and nothing else
<smb> bjf, Then I probably should not upload it but let someone understanding the whole tracking bug stuff mange that tree I pushed...
<sconklin> lamont: ok, Thanks for letting me know. Please open a bug and keep me posted. We have the next kernel in flight, and would like to keep up
<lamont> I'm guessing that 6GB of ram on an i386 machine wants to have pae, yes?
<lamont> sconklin: sure
<bjf> smb, if you've done a test of it and are happy, i'm sure sconklin or herton wouldn't mind doting the Is and crossing the Ts
<lamont> I'll file a bug with what info I have after lunch.  next shot at it will be sometime tomorrow at the earliest - tonight is busy for me.
<sconklin> lamont: yes. I HOPE that the behavior for non-pae is to ignore all above 4G, but I don't know
<lamont> ISTR that being what it did
<sconklin> smb, bjf: yes, I'd be happy to
 * lamont -> lunch
<smb> bjf, Yeah, it booted at least on my test system. Which makes me happy enough right now. There is fiddling around with certain amd cpu features which I am not sure of being needed or not within xen. It did not seem to cause issues here so I let it in
<smb> but it might need a close track of any feedback from cert/qa testing
<bjf> smb, cool! i think that's ready to hand back to the stable team
<smb> works for me... :)
 * smb thinks its time to open that bottle of cider to celebrate DoD
<jjohansen> sconklin: yep the non-pae kernel should just ignore the extra mem
<sconklin> jjohansen: thanks. I thought I remembered that right
<ohsix> do the hugepages stuff still need pae?
<jjohansen> ohsix: no, but it is needed for nx
<ohsix> i see
<ohsix> alsi i might have missed an important part of that conversation :] i just saw ignore all above 4g but i think hugepages still let you use them, up to the bus limits if available
<jjohansen> ohsix: right, pae is needed to do the address magic to switch around the segments of memory to get you past 4G, the 2M and 4M page entry bits are handled by the page tables directly
 * jjohansen runs an errand back in 15
<hallyn_afk> smb: bug 720095, don't suppose you're willing to reconsider?
<ubot2> Launchpad bug 720095 in linux "vsftpd causes a vmalloc space leak in Lucid" [Medium,Fix released] https://launchpad.net/bugs/720095
<hallyn_afk> zul: ^ 
<smb> hallyn_afk, I saw you guys bitching in the bug. But can you be sure vsftp was the *only* user of that net_ns ?
<hallyn_afk> smb: it certainly isn't the only user, we're another :)
 * smb certainly will not decide on that on his own
<smb> After all it was an experimental feature and *I* am not using lxc. :-P
<hallyn_afk> we all know what 'experimental' tag in Kconfigs is good for
<hallyn_afk> pretty sure we discussed nixing it altogether at 2008 ksummit
<hallyn_afk> anyway i've got no say, but I don't see how we can tell users that no LTS release can use containers until 12/04
<smb> hallyn_afk, I know both ways it is evil. And I would say it is nothing we should go one or the other way based on an irc discussion
<smb> So I would propose to bring that up on our mailing list
<hallyn_afk> which m-l?
<smb> kernel-team ml
<hallyn_afk> can we cc: ubuntu-server there too?
<smb> Should be possible and probably a good idea
<hallyn_afk> Did you want me to initiate it?
 * smb had hoped for that
<hallyn_afk> ok, do i need to be approved to join the m-l?
<hallyn_afk> (trying now, in any case)
<smb> dont think so. but even if not worst thing is that you end up with the same fate I had for a while (posting stays in mod queue a bit) until I subcribed the servre list
<hallyn_afk> smb: oh, but is cross-posting to kernel-team and a public list against a rule (to prevent accidental disclosures), that you know of?
<hallyn_afk> all right
 * smb hopes hallyn_afk understands its a time of day where he start caring less 
<smb> no rule I know of
<smb> kernel-team list is public too
<hallyn_afk> oh!  heh, i had assumed not :)  cool.  will post today, otherwise someone else will tomorrow :)  thanks
<sconklin> As soon as it's midnight UTC Dapper is dead to me
<jjohansen> sconklin: I am surprised you are waiting that long, I would have thought you would like to use UTC+11 for Dapper
<jjohansen> :)
<sconklin> jjohansen: in all honesty, we prepped the last Dapper kernel a few weeks ago, and I started partying then
<jjohansen> sconklin: heh, yeah I was aware of what you hoped would be the last Dapper kernel, now you get to make it official :)
<apw> sconklin, wasn't it already UTC midnight on the 1st ?
<lamont> sconklin: bug 791512 filed
<ubot2> Launchpad bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New] https://launchpad.net/bugs/791512
<sconklin> lamont: thanks!
 * jjohansen -> lunch
<skaet> sconklin, bjf - Dapper officially EOL.   Announce is out. 
<sconklin> skaet: woohoo!
<skaet> :)
#ubuntu-kernel 2011-06-02
<sconklin> lamont: I just posted some test kernels for the NAT/filtering issue, there's a link in the bug. If you have a chance to test those, I'll probably follow with further test kernels, Thanks!
<lamont> ok
<lamont> sconklin: ^^
<sconklin> ack
 * apw yawns
<RAOF> More bees!
<jk-> BEES!
<apw> COVERED in bees
<ppisati> apw: are you working today?
<apw> ppisati, yep and here, was that you i heard?
<ppisati> apw: so, i have a cve fix that imo is not needed in a branch
<ppisati> apw: how does it work? shall someone review it?
<ppisati> apw: it's not event in the .y tree
<apw> ppisati, if you believe its not needed, then we do nothing and move on
<ppisati> ok
<apw> for example if the code does not exist which is affected, then we just need to mark the CVE task for that release Invalid
<apw> and let me know so i can make sure the tracker gets updated
<ppisati> actually the code exist, but it's slightly different
<ppisati> and it seems the check is already there
<apw> then thats fine, we trust the triager (you) to work that out
<ppisati> ok
<ppisati> https://bugs.launchpad.net/ubuntu/lucid/+source/linux-fsl-imx51/+bug/737024
<ubot2> Ubuntu bug 737024 in linux-mvl-dove "CVE-2010-4263" [Undecided,In progress]
<ppisati> this one is not needed in fsl-imx51
<ppisati> and launchpad just ate my comment
<ppisati> ...
<ppisati> ok, done
<ppisati> move it to "Not needed" in the tracker
<apw> ppisati, will do
<ppisati> something strange with one cve fix
<ppisati> it's there, so it's not a security problem
<ppisati> but the commit message was inverted between 2 patches
<ppisati> and then one of them was applied again
<apw> ppisati, so we applied it, reverted it and reapplied it ?
<ppisati> apw: nope
<ppisati> wait
<ppisati> CVE-2011-1016
<ubot2> ppisati: The Radeon GPU drivers in the Linux kernel before 2.6.38-rc5 do not properly validate data related to the AA resolve registers, which allows local users to write to arbitrary memory locations associated with (1) Video RAM (aka VRAM) or (2) the Graphics Translation Table (GTT) via crafted values. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1016)
<ppisati> http://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-1016.html
<ubot2> ppisati: The Radeon GPU drivers in the Linux kernel before 2.6.38-rc5 do not properly validate data related to the AA resolve registers, which allows local users to write to arbitrary memory locations associated with (1) Video RAM (aka VRAM) or (2) the Graphics Translation Table (GTT) via crafted values. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1016)
<ppisati> and the twp patches:
<ppisati> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fff1ce4dc6113b6fdc4e3a815ca5fd229408f8ef
<ppisati> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=45e4039c3aea597ede44a264cea322908cdedfe9
<ppisati> now, on lucid:
<ppisati> c0cd753 drm/radeon: fix regression with AA resolve checking
<ppisati> 7548efe drm/radeon/kms: check AA resolve registers on r300
<ppisati> 168a4d2 drm/radeon: fix regression with AA resolve checking, CVE-2011-1016
<ubot2> ppisati: The Radeon GPU drivers in the Linux kernel before 2.6.38-rc5 do not properly validate data related to the AA resolve registers, which allows local users to write to arbitrary memory locations associated with (1) Video RAM (aka VRAM) or (2) the Graphics Translation Table (GTT) via crafted values. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1016)
<ppisati> 90a458e drm/radeon/kms: check AA resolve registers on r300, CVE-2011-1016
<ubot2> ppisati: The Radeon GPU drivers in the Linux kernel before 2.6.38-rc5 do not properly validate data related to the AA resolve registers, which allows local users to write to arbitrary memory locations associated with (1) Video RAM (aka VRAM) or (2) the Graphics Translation Table (GTT) via crafted values. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1016)
<ppisati> uhm, ok
<apw> ppisati, well if you are sure the stuff is applied at the end of the pile then we can porbabally ignore it
<ppisati> got it
<ppisati> instead of reverting
<ppisati> they logicallu reverted the patch using the commit msg
<ppisati> and then reapplied it
<ppisati> ok
<apw> ok so they used a stupid name for the revert, thats fine
<cdbs> I can see kernels on the mainline PPA, but I can't find any -modules-VERSION packages on kernel.ubuntu.com, will new kernels automatically use modules of the older version already installed on Ubuntu?
<cdbs> For example, I'm downloading the 3.0 kernel, so will it re-use the modules debs from the 2.6.39 kernel?
<apw> cdbs, there are no separate modules packages, they are included in the kenel images 
<cdbs> :o
<cdbs> makes sense
<pmatulis> i have many TCP sockets in CLOSE_WAIT states ('till DOS).  i realize this generally means an application bug but is there some quick 'n dirty way to get rid of these states in the meanwhile?
<apw> pmatulis, if they are real i think they have to be maintained to maintain the TCP protocol correctly
<apw> ppisati, hey, this last commit on the ti-omap4 pull request, is that a CVE fix ?
<apw> (looks to be), if so then it should have CVE-NNNN-MMMM added abouve your signed-off-by
<apw> also as this one has not been reviewed before it seems, it likely should be send out to the list for review and ack before application
<pmatulis> apw: i'm sorry, i don't understand you.  are you saying 'no' to my question?  will adjusting other state values (sysctl) help (specifically WAIT_TIME)?
<apw> you may get some help reducing those, but i think those waits are needed for proper operation on lossy links
<apw> so there is no way to remove them en-toto
<ppisati> apw: it's identical to the same fix in all the others branch
<apw> ok will check into that and let you know thanks
<pmatulis> apw: it's not a lossy link (between 2 lan servers)
<ppisati> apw: anyway, what if axe that from my maverick/ti-omap4 so you can uppload the rest?
<apw> ppisati, leave it with me, if i decide not to take it i'll take the rest without you needing to do anything, i'll reply in email
<ppisati> ok
<apw> once i've reviewed the rest
<ogasawara> apw: were you able to get around to disabling the cron for O builds yesterday?  just want to make sure before I push the bits I have.
<apw> i just had a look and actually we don't do pre-proposed for O yet, as there are no O PPAs yet
<apw> ogasawara, ^^
<apw> so you are safe
<ogasawara> apw: cool.  I'm just gonna twiddle the changelog in my startnewrelease commit to version 3.0-0.1 and then push
<apw> ok
<apw> i'll get the bits to make it work on the top pronto
<apw> ogasawara, did you do the abi as well ?
<ogasawara> apw: yep
<ogasawara> apw: I almost forgot
<apw> i made that mistake the first time :(
<ogasawara> apw: should be pushed now
<apw> ppisati, ok all pushed ... thanks :)
<apw> ppisati, i did have to fix a couple of commit texts on the first one, so you may find its a rebase for you to continue
<ppisati> ok
<ppisati> from now, i'm slightly modifying the commit i cherry pick
<ppisati> i'm adding the CVE $id in the commit line
<apw> its most useful on the s-o-b area, as a CVE-NNN-MMM line
<ppisati> so when i do a log --online i can catch the cve <-> commit relationship
<apw> ie on its own line down the bottom, as the tooling finds it
<apw> some people do put it on the end of the subject line too , CVE-NNN-MMM
<ppisati> so i'll add there too
<ppisati> yep, that's what i like
<ppisati> anyway, i'll put in the subject and bottom commit msg too
<apw> ack sounds fine.  the table is looking much better now
<ppisati> btw, yesterday i pushed 2 ti-omap4 tree
<ppisati> maverick and natty
<apw> ppisati, i've applied all three of the pushed you sent i beleieve
<ppisati> did you review both already?
<ppisati> ok
<apw> all reviewed and pushed
<apw> email reply in flight
<ppisati> ooook
 * apw is assuming oooook means a long OK
<apw> rather than the OOOOK (the noise a monkey makes) which often mean something bad has happened
<apw> ppisati, that looks so much better on the matrix :)  excellent
<apw> kees, will be pleased
 * ppisati never heard a monkey acking something :)
<apw> ogasawara, ok my two tiny changes pushed ... see if that builds for you ... note that it will only do so on tangerine
<apw> ogasawara, once i know the version-deps required i will get them added
<ogasawara> apw: ack, will kick on off now
<apw> ogasawara, one of those half days of work which lead to 3 lines of change
<ogasawara> heh
<apw> when you look at the commits you will see what i mean
<ogasawara> apw: I was just thinking about linux-meta now too
<apw> ogasawara, yeah thats going to need some love, you gonna handle that?
<ogasawara> apw: not sure yet what changes are required there ...
<ogasawara> apw: yep, was gonna start tackling that now
<apw> i am guessing we just lose a digit
<bjf> smb, apw, kees, w.r.t. the security test failure on the latest -proposed, the check for CONFIG_DEBUG_RODATA on the virtual flavour is failing
<bjf> smb, apw, kees, it looks like this is not enabled for that flavour on purpose
<bjf> smb, apw, kees, I see code in "enforce" that seems to confirm that
<bjf> smb, apw, kees, is this truly "by design" or not and a question that maybe only qa can answer is "why have we not hit this issue before"?
<kees> bjf: right, I'm curious as well. wasn't it enabled in -virtual prior to natty?
<sconklin> bjf, kees, apw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/772096
<ubot2> Ubuntu bug 772096 in linux "linux: 2.6.38-9.43 -proposed tracker" [Medium,Fix committed]
<sconklin> for reference
<bjf> smb, apw, kees, there is the following commit:
<bjf>     UBUNTU: Temporarily disable RODATA for virtual i386
<bjf>     
<bjf>     Setting to RO was ok, but the whole patchset seems to cause
<bjf>     i386 EC instances to panic on boot when setting the kernel data
<bjf>     to read-only and no-execute. So while there is no proper fix
<bjf>     found disable this in the i386 virtual flavour.
<bjf>     
 * kees notes the "temporarily" bit. :)
<bjf> yes
<kees> afaik, upstream fixed all those problems a while ago while the CONFIG_DEBUG_SET_MODULE_RONX patchset was shaking out
<kees> bjf: so, I would say it's not a regression from release, but it's a regression from maverick and should get fixed (without blocking SRU)
<bjf> hggdh, ^ can you comment on why we had not picked up this issue before?
<kees> bjf: afaik, qa does not test devel kernels.
<bjf> kees, we had been told at different times that qa resources were unavailable for sru testing because they were focused on devel
 * sconklin facepalms
<hggdh> I am getting very confused
<kees> bjf: haha, yeah, good point. :)
<bjf> hggdh, how can i clear up your confusion?
<bjf> hggdh, or add to it?
<hggdh> bjf, we have been running the QRT tests since the beginning; this specific test (test-kernel-security) has run since then. 
<hggdh> bjf, heh
<hggdh> all the results are saved, together with the logs
<bjf> hggdh, why are we only seeing the failure now
<bjf> ogasawara, ^ you probably want to see this
<hggdh> bjf, right now, without looking at the past logs I cannot comment
<bjf> hggdh, ok, well, we know why it is failing, would be good to know how we missed it for so long
<hggdh> bjf, kees, on the 'testing devel kernels': I think we should do it, and not restrict kernel testing to SRU
<sconklin> next question - is this worth holding up the natty update that's in process now? We're already tossing the one that's in proposed, so I'd like to keep moving forward with the replacement for it.
<bjf> hggdh, that statement implies that we do not test devel kernels, is that true?
<bjf> sconklin, seems like this has been an issue for a while, i'd say don't hold it up
<kees> sconklin: I do not think this should hold up this natty update.
<kees> sconklin: from earlier:
<kees> 14:43 < kees> bjf: so, I would say it's not a regression from release, but it's a regression from maverick and should get fixed (without blocking SRU)
<hggdh> bjf, the above statement means we -- QA -- never ran the kernel tests we have for SRU on the devel kernels
<sconklin> ack thanks
<bjf> hggdh, good to know, thanks
<sconklin> double facepalm
 * sconklin weeps
<hggdh> sconklin, a question -- the fix to disable RODATA on i386 is one of the fixes for maverick kernel that failed?
<sconklin> If you mean are we respinning this kernel anyway for another cycle, the answer is yes. But - we've already done most of the prep and would have to toss some work to go back and incorporate the fix
<hggdh> sconklin, no, the point is this fix was _introduced_ on this kernel spin, am I correct?
<sconklin> No, I don't think so.
<sconklin> one sec while brad finds it ;)
<pgraner> bjf, sconklin, while qa was focusing on devel testing it was not kernel... qa has never tested dev kernels, now that will be changing in the future.
<ogasawara> apw: amd64 test build (all flavours) passes on tangerine
 * ogasawara has to bail for dentist, back in a bit
<hggdh> sconklin, bjf: at least at 2.6.35-27.48 CONFIG_RODATA was still enabled
<apw> ogasawara, nice thanks
 * ppisati is the arm meeting - back in a bit
<bjf> sconklin, this change came in  2.6.38.0 
<bjf> hggdh, ^
<bjf> sconklin, hggdh, i misread git, that should be 2.6.38.1.27
<hggdh> bjf, only on the 2.6.38 kernel?
<bjf> hggdh, well, that means that it came in during the natty dev cycle when we picked up the .38 kernel
<hggdh> bjf, OK, this is why we never saw it 
<hggdh> bjf, and this is another reason why the QRT tests must be kept up-to-date
<hggdh> the QRT cannot be looked as usual QA tests, they must try to keep up-to-date
<bjf> hggdh, i still disagree with you and this is not a case of needing to stay up-to-date
<bjf> hggdh, this is a perfect case of everyone not being on the same page w.r.t. knowing what kernel tests are actually run during development
<hggdh> bjf, OK. I will not get back to this
<ppisati> the usb regression we had in oneiric, was it strictly usb3 related or did it screw usb in general?
<ppisati> uhm xhci only seems...
<herton> ppisati: yep, only xhci/usb3
<ppisati> it seems we lost usb on omap3 with 2.6.39...
<herton> ppisati: ah sorry, on natty we had a report xhci/usb3 regression on latest stable, on oneiric dunno
 * ppisati is trying it out... now...
<lamont> sconklin: you'll be happy to know that the non-pae kernel is just as broken
<sconklin> lamont: I;m not sure happy is the operative word
<lamont> consistency.  for my next trick, I'll fetch your test kernels
 * lamont reboots his router again
<lamont> well, in a couple minutes
<sconklin> lamont: based on the results from those two I hope we can bisect this within about 4 tries
<lamont> nice
<sconklin> if they both pass or both fail, it's going to take longer
<lamont> heh
 * ppisati -> out for a walk...
<sconklin> smb: still here?
<ppisati> sconklin: IIRC he was off today (and tomorrow)
<sconklin> ppisati: ok, thanks!
#ubuntu-kernel 2011-06-03
<ppisati> morning
<jjohansen> morning ppisati
<ppisati> hey
<ppisati> cooloney: ping
<cooloney> ppisati: hey, man
<ppisati> cooloney: you have an imx51, right? care to see if a kernel boots?
<cooloney> ppisati: oh, sorry, i don't
<cooloney> ppisati: ericm|ubuntu has one, he can helep
<ppisati> cooloney: ah, perhaps was eric then...
<ppisati> ericm|ubuntu: ping
<ericm|ubuntu> ppisati, pong
<cooloney> cooloney: yeah
<ppisati> cooloney: ok, 5min, it's still compiling
 * ppisati gets a barrel of coffee...
<ppisati> ericm|ubuntu: cooloney: btw, did you go to computex?
<ericm|ubuntu> ppisati, nope
<cooloney> ppisati: no chance for us
<ppisati> too bad
<ppisati> is it so difficult to go there?
<cooloney> ppisati: heh, yeah, it's not easy for us to visit TW
<ppisati> i tought you could get a visa, somehow
<cooloney> ppisati: yeah, visa issu
<cooloney> issue
<ppisati> ouch
<ppisati> what a pity
<ppisati> ericm|ubuntu: http://people.canonical.com/~ppisati/imx51/linux-image-2.6.31-608-imx51_2.6.31-608.26_armel.deb
<ppisati> ericm|ubuntu: give it a boot test
<ericm|ubuntu> ppisati, could you make a uImage/uInitrd?
<ppisati> ericm|ubuntu: i'm cross compiling
<ppisati> ericm|ubuntu: why do you need a uImage?
<ericm|ubuntu> ppisati, cuz that's easier for me to test
<ericm|ubuntu> ppisati, I'm downloading - I'll let you know if I need a uImage
 * apw yawns
<cooloney> apw: morning, man
<ericm|ubuntu> ppisati, installing ....
<ericm|ubuntu> ppisati, I need uImage
<ericm|ubuntu> ppisati, you just want to test boot or?
<ericm|ubuntu> ppisati, kernel boot or boot into a full system?
<ppisati> well, boot it and see if the system work
<ericm|ubuntu> ppisati, so you want a boot into full system
<ericm|ubuntu> ppisati, that means I need to setup ubuntu
<ericm|ubuntu> ppisati, it's almost bare metal here - with u-boot
<ericm|ubuntu> ppisati, it's going to take time to install a full system here :-/, is it lucid/maverick/natty/onerick?
<ppisati> ericm|ubuntu: ah, i didn't know
<ppisati> ericm|ubuntu: no ok, give it a boot them
<ppisati> then
<ericm|ubuntu> ppisati, wait
<jjohansen> apw: have you played with https://github.com/termie/git-bzr-ng?  its quite interesting
<apw> jjohansen, no i've not, sounds interesting thought
<apw> jjohansen, any idea if its packaged 
<jjohansen> apw: not that I found
 * jjohansen is playing with it to do some bzr to git mirroring atm
<jjohansen> haven't gotten as far as trying to do dev with it
<apw> i see we have the opposite packaged
<jjohansen> yeah
<apw> it seems to be a single file, did you drop it into your git lib directory for testing ?
<ericm|ubuntu> ppisati, http://paste.ubuntu.com/617335/
<ericm|ubuntu> ppisati, seems to be an old known issue - the parport
<ericm|ubuntu> ppisati, ain't this been fixed already?
<ppisati> ericm|ubuntu: dunno, never had an imx51 before
<apw> yeah that rings a bell, something like we had that parport module disabled on the imx51 configuration
<ppisati> but i didn't enable it
<apw> ericm|ubuntu, i think you can disable it via a bad argument right, parport.broken=1
<ppisati> CONFIG_PARPORT_PC=m
<apw> lag, was it you who originally hit the parport loading blew up ARM ?
<ppisati> i guess it has always been there, and people blakclisted it
<apw> ericm|ubuntu, we may have been lucky before, life is like that sometimes
<jjohansen> apw: yeah I dropped it in /usr/lib/git-core/
<cooloney> apw: yeah, i remember lag send an patch to upstream about parport
<cooloney> apw: but RMK has some very old ARM machine with parport
 * apw struggles to find the commit somewhere
<apw> i am sure we have something applied to do ti
<apw> somehwere
<ppisati> actually the previous kernel was tested by GrueMaster, but i don't think he's around now
<ppisati> perhaps he disabled it on boot
<apw> ppisati, maybe so, seems unfortuanate though
<apw> manybe the regualr install does it
<ppisati> could be
<ppisati> i pull req
<apw> <apw> ericm|ubuntu, i think you can disable it via a bad argument right, parport.broken=1
<apw> seems it was CUPS starting which triggers this
<ppisati> apw: so it has always been there'
<apw> ppisati, still trying to work out what we did
<apw> i remember there was a patch, which was NAKd upstream, and then we did something
<apw> eit
<apw> either applied the patch locally or just changed the config to turn it off on our build
<apw> on one of the 5 arm branches
<apw> commit abbbcd0c482d0fb3b2d39501f4debc956bea2506
<apw> Author: Lee Jones <lee.jones@canonical.com>
<apw> Date:   Fri Jul 16 09:37:31 2010 +0100
<apw>     UBUNTU: Stop ARM boards crashing when CUPS is loaded
<apw> we have that applied on the _maverick_ master branch
<apw> so i think this was an omap3 fix, not one which was o
<apw> on fsl-imx51, so i am a little confused as to how its ever worked if its breaking now
<apw> ppisati, but the effect is just to turn off PARPORT_PC on omap, so you could try just turning PARPORT_PC off and see if that fixes things
<apw> for eric ... if so i can't see why we wouldn't have that switched over
<ppisati> uhm
<ppisati> ok
<ppisati> i'll do
<apw> and no i cannot see why we haven't seen this before at all
<apw> it could be a consequence of tightening something up in one of the security fixes though
<ppisati> but the crash is happening in drivers/parport/parport_pc.c, and that has always been =m
<ppisati> and the cve didn't touch that part
<ppisati> well, anyway, it's not a big deal
<apw> no did any affect io remapping or anything, i agree it is somewhat unexpected
<ppisati> i'll turn off the partport and ask ericm|ubuntu to test another one
<apw> sounds good
<ppisati> btw, besides ericm|ubuntu and GrueMaster, who has an imx51 board?
<apw> i don't think i know the answer, ask ogra they have a list somewhere
<ppisati> ok
 * apw suspects we should get you one
<ppisati> apw: it's scarcer than an albin tiger
<ppisati> i already aksed around, and besides them it seems no one has one
<apw> hrm
<ppisati> apw: what do i have to change to rename the kernel? i.e. i would like to add a postfix "parport-off"
<apw> if you edit the debian.imx51/changelog, and add it in the version field
<apw> so if its UNRELEASED you can add like ~parportoff1 to the version number
<apw> note that a - is not permitted
<apw> the ~ makes the version "older" than the offiicial version we release later
<ppisati> you mean i change the numbering in parentheses, right?
 * ericm|ubuntu network sucks here much
<apw> ppisati, yep add it at the end there,  2.6.31-200.10 -> 2.6.31-200.10~parportoff1
<ericm|ubuntu> apw, let me try the command line
<ppisati> building...
<ericm|ubuntu> apw, parport: Unknown parameter `broken'
<ericm|ubuntu> apw, but interestingly - the oops didn't come
<apw> ericm|ubuntu, yep, thats whats meant to happen, it breaks the module init so it doesn't load
<ericm|ubuntu> apw, clever :-)
<apw> ericm|ubuntu, now you can tell if everything else is working
<ericm|ubuntu> apw, it hanged - I'll boot again
<apw> ericm|ubuntu, not sounding so good
<ericm|ubuntu> apw, hanged again - stopped somewhere
<apw> ppisati, ^^ doesn't sound good
<ericm|ubuntu> apw, ppisati, I'm using Linaro's natty ubuntu image - it could be rootfs issue
<ericm|ubuntu> apw, ppisati, after a long long long hang - now it dropped me into the shell
<ericm|ubuntu> Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox [ok]
<apw> ericm|ubuntu, can you test the kernel which is in the -updates pocket on that userspace to see if thats a new issue or 'expected'
<ericm|ubuntu> system hanged for a long time before the above showed
<ericm|ubuntu> apw, ok
<ppisati> yep, try the shipped kernel
<lag> apw: ericm|ubuntu: ppisati: http://paste.ubuntu.com/617351/
<lag> It was CUPS, trying to speak to ALL of the serial ports
<lag> Naturally, you need to change it to ARCH_<YOUR_ARCH>
<ericm|ubuntu> apw, which release? lucid/maverick/natty/onerick?
<ppisati> ericm|ubuntu: lucid
<ericm|ubuntu> apw, it's in ports.ubuntu.com already? or somewhere else? the -update one
<apw> ericm|ubuntu, yeah whatever the latest official one is, as that is tested already
<ppisati> ericm|ubuntu: http://people.canonical.com/~ppisati/imx51/linux-image-2.6.31-608-imx51_2.6.31-608.26~parportoff_armel.deb
<ppisati> ericm|ubuntu: that's the parport off version
 * ericm|ubuntu finally get on again
<ericm|ubuntu> ppisati, downloading
<ppisati> ericm|ubuntu: but i think it's better if you try first the -update version
<apw> ppisati, reviewed and pulled
<ppisati> ericm|ubuntu: since it's pretty obvious turning off parport will fix it
<ppisati> oooook
<ppisati> :)
<ericm|ubuntu> ppisati, 'k - save me a few boots
<apw> ppisati, now lets hope there isn't a problem for you to find in the heap :)
<ppisati> apw: that would be fun :)
<apw> fun for ericm|ubuntu doing the boots for the bisect :)
<ppisati> yep :)
<ericm|ubuntu> apw, ppisati, I'll pretend to be having network issue then
<ericm|ubuntu> :-)
<apw> ericm|ubuntu, :)
<apw> ppisati, is it mvl-dove which is still rebasable ?
<ericm|ubuntu> apw, same - 608.25 paused a long time before dropping me into the shell
<ericm|ubuntu> apw, so it's not a regression
<ericm|ubuntu> ppisati, I'll test your kernel next
<apw> ericm|ubuntu, ok cool, so ppisati we are likely good with whats on the branch, phew
<ppisati> ericm|ubuntu: but did you get the parport trace?
<ppisati> apw: yes, i'll wait till next week and the do a rebase
<ericm|ubuntu> ppisati, yes - same
<apw> ppisati, and i think mvl-dove is programatically copied over into maverick from lucid right
<ppisati> apw: yep, exactly
<apw> excellent, so those two should look better soon too ... great
<ppisati> the other branch that need work is maverick/ti-omap4
<apw> yeah she is the worst looking at the moment
<ppisati> but first i've this:
<ppisati> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791552
<ubot2> Ubuntu bug 791552 in linux "No USB support on beagle/beagleXM" [Undecided,New]
<apw> ppisati, but you have a mountain to climb here, and the rock is heavy .... progress is good, we've applied more cves to the arm branches in the last week than in the last two months
<ppisati> we totally lost usb on beagle*
<apw> ppisati, that sounds like a more interesting problem indeed
<ppisati> alpha1 image has that problem
<apw> ppisati, if it was me, i'd be doing like a CVE (maybe 2) for each branch every day and doing interesting stuff the rest of the time
<apw> pushing out the accumulation weekly
<ppisati> but when i tried an oneiric kernel on a maverick userland it worked
<apw> (not that i am complaining to have 20 in a week or anything)
<apw> interesting ...
<apw> ppisati, i assume you have a beagle, so you can bisect using the kernels in launchpad
<ppisati> actually version_signature are the same
<ppisati> i suspect it's something else
<apw> ppisati, huh ...
<ppisati> but yes, i'have 2 beagles
<apw> the version in oneiric is the _same_ version number?  then its a literal copy from natty to there
<apw> and if thats the case it may be the act of reinstalling which fixed you
<ogra_> ppisati, ggez, why do you care, i promise you there will never be an imx51 board with a parallel port, just disable parport and be done :)
<apw> ogra_, well we do wonder why he is suddenly hitting it, yes disabling it is sane anyhow, but why did this kernel suddenly exhibit the issue!
<ppisati> ogra_: i'll push a config change then
<ppisati> apw: actually it's the omap3 kernel, so get it from mainline
<ppisati> apw: and the version on the alpha1 image and my own compiled kernel are the same
<ppisati> i'll try some kernel/bootloader swapping
<apw> ppisati, i'd accept a config change for sure, its clearly not needed on the boards we care about there not being one
<ogra_> wht do yopu hit exactly ?  bug 603062 or bug 601226 ? 
<ubot2> Launchpad bug 603062 in linux-ti-omap4 "oops in parport_pc_probe_port function of parport_pc module (dup-of: 601226)" [Medium,New] https://launchpad.net/bugs/603062
<ubot2> Launchpad bug 601226 in linux-ti-omap4 "Unable to handle kernel NULL pointer dereference in ppdev module" [Medium,Fix released] https://launchpad.net/bugs/601226
<ppisati> do i disable parport_pc or the entire parport driver?
<ogra_> i'm Ã¼pretty sure we disabled at least the loading of the module in the past 
<apw> ogra_, probabally an image issue then, as in your image has blacklist and the one ericm|ubuntu is using does not
<ogra_> iirc there is a cups udev rule or the upstart job that have a modprobe parport hardcoded 
<apw> if it blows chunks on loading, it likely should be removed
<ogra_> one of the bugs above should have info for it 
<apw> ppisati, i think its just the PC part which is bust
<ogra_> but fixing it is really not worth the effort given the usefullness of the fix (beyond the fact of having it fixed there is no other advantage anywhere)
<apw> ogra_, who in your team has one of these boards ?
<ogra_> oh, and i have an imx51 board but that sits on the shelf and preparing it would take me half the day 
<ogra_> tobin too 
<ogra_> i think the rest went back to london 
<apw> ogra_, did those all become buildds or is there spares there we could get to ppisati 
<ogra_> hmm, i can ask around
<apw> ogra_, thanks
<ogra_> the panda buidcluster should be up within the next two weeks or so
<ogra_> then we have all buildds spare 
<ogra_> so you can definitely get one i think
<apw> ogra_, who do i poke to make sure ppisati is at the top of the list to receieve one
<ogra_> i will take care, no worries
<ericm|ubuntu> ppisati, apw, confirmed the ~parportoff kernel works
<apw> ericm|ubuntu, nice thanks
<ericm|ubuntu> apw, np
<ppisati> https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/601226
<ubot2> Ubuntu bug 601226 in linux-ti-omap4 "Unable to handle kernel NULL pointer dereference in ppdev module" [Medium,Fix released]
<ppisati> apw: i nominated it for lucid/fsl-imx51, ack it
<apw> ppisati, done
<jussi> So, just wanted to follow up on a bug from a colleague in the office here, had a similar issue to me, on very different hardware. bug 792291
<ubot2> Launchpad bug 792291 in linux "Machine hung, display frozen" [Undecided,New] https://launchpad.net/bugs/792291
<jussi> (my bug was bug 791064 - although it maybe quite different, Im not sure).
<ubot2> Launchpad bug 791064 in linux "Machine Hang, black screen with immobile mouse cursor only" [Undecided,Confirmed] https://launchpad.net/bugs/791064
<lool> Since I upgraded to .39, I get regular wifi disconnects/reconnects; is this known?
<lool> Intel(R) WiMAX/WiFi Link 5350 AGN, REV=0x24
 * apw lunches
<sconklin> apw: there's a failed build of lts-backport-natty for Lucid in the PPA, what nneds to be done with that? and - does it need to go into this cycle?
<apw> sconklin, is that on powerpc ? 
<sconklin> looking
<apw> sconklin, if so it is not meant to build on there, and that is has is an artifiact of the fact its a new package i beleive, and nothing to worry about, it should be ignored
<sconklin> looks like armel, PPC, ia64 and sparc failed
<sconklin> only i386 and amd64 succeeded
<apw> yeah, its only meant to build on i386 and amd64, its an lts backport kernel
<apw> and as far as we know the packaging only says build there, but its thought to be a side effect of not being in the main archive already
<apw> so just ignore those failures for now
<apw> and only copy the amd64/i386 over
<sconklin> ok. Did you add a tracking bug?
<sconklin> lazyweb
<apw> no as originally it wasn't aimed to be a copy in in your team, it was for MIR, but then they decided we didn't need one
<apw> so its ended up half baked, you could rebuild it if thats easier
<sconklin> ok, we'll manually track it this time and catch it in th enext cycle
<sconklin> thanks!
<apw> yeah my stupidity for not putting the MIR bug number in there, then you could have bastardised that for the job
<apw> ogasawara, do you know if we have oneiric capable PPAs yet ?
<ogasawara> apw: not that I'm aware
<apw> hrm, it would be nice to test these changes in PPA first ... bah
<ogasawara> apw: indeed it would
<ogasawara> apw: also just fyi, I pushed linux-meta version fix to a master-next branch
<apw> ogasawara, sweet
<apw> i am hopeful of getting this poo reviewed very early next week, if not then i'll plan on uploading just a simply tweak for versions to m-i-t moday
<apw> monday and get the resync in separatly
<ogasawara> ack
<apw> ogasawara, i guess i could upload these both to a PPA but for natty and see happens
<apw> ogasawara, also did you say that you'd installed the m-i-t and kernel on a machine it booted ?
<apw> pwd
<ogasawara> apw: yep, installed mit and the test kernel and all booted fine
<GrueMaster> Morning kernel peoples.  
<GrueMaster> ppetraki: The bug on the parport-pc was mainly filed on dove, and iirc, the module was configed out.
<GrueMaster> Oops. I meant ppisati.
<vmlinuz> Tommeh: I've found a doc about i915 GPU lockups: https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes
<vmlinuz> Tommeh: I tried re-enabling KMS in driver options, tried disabling DRI in xorg.conf - None of them worked
<vmlinuz> Tommeh: seems this is a known issue already been tracked by upstream
<sconklin> apw: in there a natty ports meta?
<sconklin> s/in/is/
<apw> sconklin, nope there is no ports meta in natty
<sconklin> thx
<Tommeh> vmlinuz: bad times for you, but at least it's known.
<Tommeh> You might wish to try xorg-edgers for the latest versions.. I'd say it's not for the feint of heart, but it's been relatively stable for me. The only thing I will say is that make sure you're VERY comfortable with resolving dependency issues with aptitude, before installing it (as removing it  can be tricky)
<Tommeh> I say 'latest' .. I'm fairly sure even Lucid/Maverick don't get the absolute latest changes from 'edgers, due to broken ABI stuff.
<Tommeh> Most likely newer than what you have, however.
<apw> this is utterly hopeless, the upstream bzr branches we are merging also have the .pc stuff in them so there is no clean way to actually merge at all
 * apw becomes vague ...
<ogasawara> bjf: I've got a script that dumps the following for our weekly meetings - http://reports.qa.ubuntu.com/reports/ogasawara/kt-meeting.txt
<bjf> ogasawara, looks good
<ronin__> hi, apologize in advance 
<ronin__> I want change my gcc version from 4.5 to 3.4 
<ogasawara> bjf: I figure I'll just run it weekly in a cron. I wonder if I should copy it to kernel.ubuntu.com/~kernel-ppa/reports/ so then anyone could pull the data and paste it in the meeting should one of us be unavailable
<ronin__> could you help me?
<bjf> ogasawara, is your script in kteam-tools?
<ogasawara> bjf: it's not, it's just an Arsenal hack so I wasn't sure if we'd want it in Arsenal of kteam-tools, I'm indifferent either way as long as I can put it somewhere
<ogasawara> s/of/or/
<bjf> ogasawara, i'd like to eventually be in kteam-tools, but can live with it somewhere else for now
<ogasawara> bjf: I'd prefer for it to be in kteam-tools too, for some reason that's where I'd look for it if I were wanting to find it
<bjf> ogasawara, ~kernel-ppa would probably be fine
<ogasawara> bjf: I'll throw a note at the top of the script that it expects to be run within Arsenal
<bjf> ogasawara, wfm
 * jjohansen heads to lunch
<bjf> bryceh, what's a valid LP version other than 'devel'?
<vanhoof_> bjf: like edge, staging, production?
<bjf> vanhoof_, no, those are "services"
<vanhoof_> ah nm then :)
<bjf> bryceh, nm, not the problem
<bryceh> ok
<broder> bjf: "beta" and "1.0"
<bjf> broder, many thanks
<broder> (beta matched karmic's lifecycle, so it's dead now; 1.0 will match lucid's lifecycle)
<broder> bjf: https://launchpad.net/+apidoc/
<bjf> broder, and 'devel' is current development
<bjf> broder, thanks, that's so obvious
<broder> np
<sforshee> sconklin, I'm guessing it's too late to get a patch into the next proposed kernel for natty ?
<sconklin> sforshee: yes, it's already built in the PPA
<sforshee> sconklin, then it will be another 3 weeks before the next one, right ?
<sconklin> yes
<sforshee> thanks
<sconklin> unless it's like this train wreck of a cycle and then who knows.
 * jjohansen steps away for a bit
#ubuntu-kernel 2011-06-04
<leao> hi guys
<leao> can someone explain to me how to write kernel modules
<jj-afk> leao: that is asking a lot
<jj-afk> leao: the best way to start out is with some basic code and running through some tutorials
<jj-afk> leao: http://tldp.org/guides.html
<jj-afk> has some tutorials and documentation
<jj-afk> leao: its going to take, the source, a C compiler, and patience, there is a lot to learn, the basics aren't hard but there is a large set of apis and design patterns with in the kernel to learn
<LLStarks> ogasawara, raw1394 seems to be absent from the natty and oneiric kernels for legacy firewire stack usage.
<LLStarks> is this intentional?
<sconklin> ogasawara, apw: either of you around?
#ubuntu-kernel 2011-06-05
<CarlFK> how do I tell what modules are included in a kernel?   
<ohsix> dpkg -L <thepackagename>
<ohsix> there's also /lib/modules
<CarlFK> never mind.. found it
<CarlFK> CONFIG_HOTPLUG_PCI_PCIE=y
<CarlFK> at least I am guessing that includes pciehp
<ohsix> oic, zgrep '=m' /boot/config* might do that then
<CarlFK> im looking for included, not built as a module.  (so maybe it isn't a module in that case?
<kaushal> Hi
<kaushal> I have been using Ubuntu since 2008 and have been able to almost migrate 50% of Desktop to Ubuntu
<kaushal> How do i start learning kernel and later program it
<eagles0513875> hey apw
<eagles0513875> what is the link to the ppa that has the 2.6.38-9 kernel
<jpiche> would anyone mind taking a look at bug 775950? I've been struggling with it for a while, and I'm not quite sure how to debug it. thanks
<ubot2> Launchpad bug 775950 in linux "fixing recursive fault but reboot is needed! upon boot without AC (only battery)" [Undecided,Confirmed] https://launchpad.net/bugs/775950
#ubuntu-kernel 2012-05-28
<ppisati> moin
 * apw yawns at everyone
<apw> man its hot today
<Eimann> indeed
<cking> sweltering
<apw> cking, 22 already here, in the shade
<cking> it's hot in my offices, 3 laptops running + 1 desktop
<cking> *office
 * apw notes he has just gottent a small breeze ... much appreciated
<cking> must be dietary
<apw> *slap*
 * apw notes it is World IPv6 Launch Day on June 6th
<cking> shudder
<apw> google and facebook will go ipv6 permenantly so that should be a good test
<cking> hrm, from the results from last year, it may just happen and nobody will notice
 * cking getting impatient with spinny media
<apw> cking, heres hoping
<jMCg> jodh: ping - I have a bash in that 10.04 kernel that boot on the KVM, as left on Friday. What can I do to find out why it's not getting past that point?
<ppisati> i hate when i issue "sudo reboot" in the wrong terminal...
<cking> me too
<jMCg> I really hate it when I do `sudo init 0` on a remote server..
 * cking needs to kick his AP again
<tjaalton> ideas why 3.4 doesn't initialize drm at all on intel? falls back to vesa which probably is the cause of a hard hang after maybe 10s of idling
<apw> herton, successfully booted and running 3.2.0-25.40 on my main dev box
<herton> apw, cool, henrix ^
<apw> herton, dunno if such reports help any, or indeed if there is somewhere better to report them
<henrix> apw: herton: maybe on the sru tracking bug...?
<tgardner> cking, henrix: rebooting tangerine, OK ?
<herton> apw, good to know nothing breaks, we don't have any way currently to see better who tested it
<henrix> tgardner: ack
<cking> tgardner, sure, no problem for me
<herton> henrix, yeah, it doesn't hurt if people report success on tracking bugs
<tjaalton> ok so the drm-next build doesn't actually contain the dri drivers.. maybe the build should fail harder when there are issues?
<jMCg> Are there backports of current kernels to past LTS?
<tgardner> jMCg, https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<jMCg> tgardner: I meant for 10.04..
<tgardner> jMCg, the last backport kernel is Oneiric
<jMCg> So, a precise kernel in Lucid.
 * ppisati -> gym (before the entire world goes there...)
 * apw watches his network do summersaults
<cking> apw, how entertaining
 * cking --> food
<cking> grr, my daughter has been asked to do some homework on a microsoft .pub publisher file.  time to educate the teachers (again) on "open" standards
<apw> cking, and lo won't read it ?
<cking> she needs to "edit it and print it out"
<cking> I'm sending a well crafted letter to the school. 
<apw> how can they possibly assume you have any of this ... 
<cking> Â£299 for office
<cking> mad
<cking> so much for free education in lame UK
<apw> cking, actually for education you can get one which is *only* 80 quid
<apw> but thats still not right
<cking> apw, Â£299 is the cheapest version that does publisher.
<apw> cking, oh ... crap
<cking> the student version doesn't do this
<apw> that utterly unreasonable then, how can half the people afford it
<cking> indeed. that's why poor families fail.
<apw> without using a torrent
<cking> she will get a detention  if she can't get it done.
<cking> the system is broken and wrong
<apw> that ought to be illegal
<cking> the IT teacher is stupid, she calls it all "softwares"
<apw> the teacher should get fired, for being stupid
<apw> open lettter: "Do you think it is reasonable to require a 299 GBP expenditure to answer one assignment"
<cking> if my daughter uses the computer at school she has to pay to do so.
<apw> cking, sick L on the teacher that should fix it
<apw> cking, how much do they charge
<cking> too much to print each page.  They can't export it and let me print it at home.
<cking> nuts
 * apw hands cking a fully automatic, time to go postal on the "softwares" users
 * apw pops out to the s/m
<apw> bah full of _people_
 * ppisati feels like a corpse...
 * jussi hands ppisati a coffin to lie in...
<JanC> cking: MS Publisher still exists?
<cking> JanC, I converted it using the zamzar website and munged the resulting output into something printable using gimp
<JanC> At one point MS talked about stopping its development, apparently they didn't
<JanC> nobody uses it for "real" DTP anyway
<JanC> cking: can't they bring their own laptop with real "softwares" instead of paying?  ;)
<cking> JanC, if only the world was perfect and we all used "open" document standards... *sigh*
 * cking calls it a day
 * tgardner -> EOD
<pac1> what is the upstream kernel tag I should use for working with the 3.2, 3.3 and 3.4 kernels?  do I need a separate upstream kernel for 3.2, 3.3 and 3.4 or will just one work for all three clones?
#ubuntu-kernel 2012-05-29
<pac1> pac1 reads the irclog.
<ppisati> moin
<tjaalton> hmm, the 3.4 kernel in quantal/precise backport doesn't have any drm modules?
<tjaalton> mainline build is fine, drm-next is broken as well
<ppisati> wow... we just had another earthquake...
<bryceh> o_O
<soren> ppisati: Where?
<smb> quite a few of them lately
<soren> smb: Where?
<smb> soren, I meant over there in Italy
<ppisati> Italy
<soren> O_o
<smb> morning, btw
<tjaalton> ok, so drm drivers are now in -extra..
 * apw yawns ...
<apw> tjaalton, for the normal flavours (in quantal) we are experimenting with a split packge; the idea is for the regular flavours you need both, then they can be shared with -virtual
<apw> (which only uses the first one)
<tjaalton> apw: yeah, only noticed it now :)
<tjaalton> so that was the reason why ivb was hanging, it doesn't like vesafb that much
<apw> tjaalton, ahh ... yes we more expect people to be using the meta packages
<apw> which if they are right pull in both
<tjaalton> right, I'm used to installing mainline kernels directly, so tried the same with the quantal one. lesson learned :)
<apw> oh interesting, are we generating the extras from mainline, thats lucky :)
<tjaalton> no mainline kernels are still fine
<tjaalton> aka. monolithic
<apw> hmmm that supprises me :)
<tjaalton> well, drm-next wasnt' :)
<tjaalton> it's split the same way
<tjaalton> oh, quantal mainline is split
<apw> oh yeah they have split haven't they ... i had better document that :)
<apw> done
<smb> apw, I think that also causes the cloud images to fail boot on ec2 (well, not the split but the merging of virtual into generic)
<apw> smb, ok ... any idea why ?
<smb> They used to only add -virtual kernels to the pvgrub. Which now leaves them with... none
<apw> oh that is so very ... something
<apw> special
<smb> heh, yeah, usual fallout
<apw> smb, is that something we manage, the -virtual adding thing
<smb> apw, Yes, need to talk to scott or ben about it
<smb> There is a bug, to which I added a comment
<apw> ok cool, sounds under control
<smb> yeah should be
<smb> saw that bug just yesterday but then did not look closer that to wonder why on earth they tried to boot memtest on a pv guest
<apw> its a mystery how that could be any use at alll indeed
<smb> apw, he cannot hear us
<smb> la la la
<apw> i know ... *screams*
<smb> apw, killing pulseaudio softly...
<jMCg> softly?
<smb> Just making it into a reference to a song... normally you then have to kill it harder (pulseaudio -k, killall pulsaudio,...)
<jMCg> Please don't use killall, you'll shoot yourself in the foot if you ever move away from Linux ;)
<ppisati> brb
<pgraner> apw, can you look into this for me: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005832
<ubot2> Launchpad bug 1005832 in linux "Intel wifi frequent disconnects" [Undecided,Confirmed]
<apw> pgraner, if we have to kill and restart wpa-supplicant to fix it i'd be suspicious of that in the first instance
<apw> cyphermox, any insight on the above ^^ 
<apw> pgraner, i note that they other reporter has different wifi h/w, so i guess if its kernel its generic
<apw> pgraner, what channel are these APs on
<apw> pgraner, and have you told your machine you are in .hk ?
<apw> pgraner, try "iw reg set HK" .. you may have to remove your iwl driver before it will let you of course
<apw> pgraner, added informaion to the bug
<pgraner> apw, not seeing anything in the bug
<Daviey> Hey, do we know why kexec doesn't work on arm?
<ogra_> Daviey, it works at times 
<ogra_> an on some arches ... but it always broke after some rebases, version changes etc ... its not completely broken but not very reliable 
<apw> pgraner, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005832/comments/3
<ubot2> Launchpad bug 1005832 in linux "Intel wifi frequent disconnects" [Undecided,Confirmed]
<ppisati> Daviey: it works UP, broken SMP (last time i tried)
<Daviey> ogra_: doesn't seem to work for Panda for me?
<ppisati> Daviey: upstream had patches for it, but they just fixed part of it
<ppisati> Daviey: didn't try with latest 3.4.x BTW
<ogra_> Daviey, eah that underlines what i said :) i know it worked in one (or even more) past releases
<Daviey> ogra_ / ppisati : What can be done to make it reliable ?  (nothing at this stage, is OK :
<ogra_> Daviey, well, someone would have to constantly test it, someone else would have to constantly fix it if its broken 
<ogra_> read: maintenance and testing 
<ogra_> :)
<ppisati> Daviey: which kernel are you testing?
 * ppisati -> run to the kebab...
<Daviey> ppisati: tried 3.0 (oneiric), linaro's Oneric and Precise.
<ogra_> Daviey, how about the ubuntu precise ?
<ppisati> ogra_: up = ok, smp = broken
<ppisati> ogra_: they started fixing it in... 3.3? iirc
<ppisati> ogra_: i don't know if it's sound in 3.4 either
<ogra_> yeah
<ogra_> well, UP is at least something :)
 * ppisati -> goes to recompile all kernels/flavours UP-only! :)
<ppisati> Daviey: do you need O for some particular reason?
<smb> apw, Just out of curiosity, when you upgraded your router from lucid to precise, did you also have to use -d with do-release-upgrade? Oh I guess that is part of the "wait a bit until gently pushing people towards the next lts" thing...
<apw> smb, yeah you have to override with -d as its not 'ready' yet ... and indeed it isn't :)
<smb> apw, Meh, those small issues with dhcp...
<ogra_> that will only be switcvhed for the .1 release 
<ogra_> (as with all LTS'es)
<apw> ogra_, right ... and me doing mine now early is to find the kind of dhcp issue i hit, before the masses do it 
<smb> ogra_, That kind of occurred to me the second I typed in the question... :)
<ogra_> apw, yeah ++ for that :) 
<Benkinooby> hi, here is my story in short: want to turn off laptop backlight for use in bright sun; asked in ubunut, debian, xorg, gentoo, ubunut-devel and now here (in that order); tried the commands 'xset dpms ...'; read https://wiki.kubuntu.org/Kernel/Debugging/Backlight ; inspected file /proc/acpi/video/GFX0/DD04/brightness and found out that my lowest level is 20 (but i guess i want 0); read on at http://powersave.sourceforge.net/powersave/
<Benkinooby> DSDT.html ; link th "find a DSDT for your laptop" return 404; now asking here;
<Benkinooby> th -> to
<Benkinooby> any ideas, help or useful RTFMs?
<Daviey> ppisati: no, don't need O.. it was just referencing that i tried it on that.
<Benkinooby> ok found "how to fix a buggy DSDT file" http://ubuntuforums.org/showthread.php?t=1036051 ; is it possible to just add a "0" to the supported levels?
<ppisati> Daviey: btw, is broken all the way up to 3.4, included
<Daviey> nice.
<soren> Benkinooby: Turn off backtop for use in bright sun? Seriously?
<soren> Er.r..
<soren> *backlight
<soren> Benkinooby: In your experience, does the screen become easier to read as the brightness increases or as it decreases?
<Benkinooby> soren, what i want to do is to use the reflection of the sun as my "backlight"
<ogra_> and that works for you ?
<apw> Benkinooby, that never worked for me
<ogra_> same here 
<Benkinooby> ogra_, apw as i understood it some laptops actively employ that mechanism... i don't know if it will work for me, but i'd like to try
<apw> Benkinooby, well it should work nearly as well witht eh backlight at its lowest setting
<ogra_> yeah
<ogra_> 20 should already work then
<Benkinooby> ogra_, hm
<apw> Benkinooby, and i have never seen one actually made which does that, people have claimed it would be a good idea, and they would do it, but i've never seen one, else i'd own one
<ogra_> it might work if you could split the lid in two, so that the back of the LCD gets transparent and light could actually get through
<Benkinooby> apw, afaik the OLPC-laptop are capable of doing that... googling for proof on that right now
<apw> Benkinooby, i think they said they would do it for the next version, not sure if they did it in any you can get
<Benkinooby> http://laptop.org/en/laptop/hardware/specs.shtml
<apw> Benkinooby, but even so, even if they did, i know of nothing big enough for my fingers which does it
<ogra_> "reflective sunlight-readable monochrome mode"
<ogra_> that means it comes with a special black/white mode for use in bright sunlight
<ogra_> like an old calculator or LCD wrist watch
<ogra_> i doubt there are any normal displays with such a mode on the parket 
<ogra_> *market
<Benkinooby> ogra_, yeah might be...
<Benkinooby> but i was wondering how it would work out for my display
<apw> indeed, the co behind the olpc were going to commercialise them, i assume making large ones is too expensice
<Benkinooby> to turn off the backlight and see if it will be usable in sunlight
<ogra_> it wont, but try yourself with the 20 setting 
<apw> Benkinooby, its a differnet technology, the backlight doesn't reduce the displays abilit to use reflected light
<ogra_> getting it to 0 will only make it worse
<apw> indeed
<Benkinooby> ok
<Benkinooby> then i'll stick with that
<Benkinooby> but for the record:
<ogra_> (or get an OLPC) ;)
<Benkinooby> do you know if i could disassmebly the DSDT, add "0" to the suported levels and then use the modified one? 
<Benkinooby> or hast there to be done further work?
<Benkinooby> or maybe for getting it to a lower brightness like 10
<Benkinooby> (don't worry i'll stick with the 20 as lowest level - i'm just nosey
<Benkinooby> apw
<Benkinooby> Benkinooby> do you know if i could disassmebly the DSDT, add "0" to the suported levels and then use the modified one? 
<Benkinooby> <Benkinooby> or hast there to be done further work?
<Benkinooby> <Benkinooby> or maybe for getting it to a lower brightness like 10
<Benkinooby> <Benkinooby> (don't worry i'll stick with the 20 as lowest level - i'm just nosey
<Benkinooby> after you left
<apw> no changing the DSDT is such a high risk strategy that we do not enable any support for that
<apw> you can fry your machine fiddling with it
<Benkinooby> ouh... i don't want taht
<Benkinooby> *that
<ogra_> apw, tsk, you take all the excitement out of computing !
<Benkinooby> ogra_, i'm also for excitement in computing... but not on my only productive system :D
<ogra_> pffft, no risk, no fun 
<Benkinooby> WARNING: This might mess up your operating system. Even if you have zero errors after fixing the DSDT, it may still cause you to not be able to boot your OS. It will not harm your PC or hardware.
<Benkinooby> says http://ubuntuforums.org/showthread.php?t=1036051
<Benkinooby> it's from 2009 though...
<Benkinooby> anyway
<Benkinooby> thank you all for your input
<Benkinooby> appreciate that
<Benkinooby> and say you saved me some "excitement"
<apw> heh yeah
<Benkinooby> so thanks for that too :D
<ogra_> yeah, that warning apparently didnt help so it was disabled in the code 
<Benkinooby> what code?
<ogra_> whatever was used in the past to upgrade the DSDT
<ogra_> iirc there was some code in the initrd
<apw> yep, but its been gone since i think before dapper
<Benkinooby> UPDATE: The kernel dev's will no longer use the patch to enable custom DSDT files for Karmic 9.10 and beyond. Jaunty 9.04 is the last version this will work on. You are urged to file a bug report for DSDT errors.
<Benkinooby> just saw that now
<cking> Benkinooby, if you really want to do it (and take the risk if it goes wrong), consult Documentation/acpi/dsdt-override.txt and also http://www.lesswatts.org/projects/acpi/overridingDSDT.php
<cking> but we don't support this ;-)
<Benkinooby> cking, thank you but i don't think i'll take the risk...
<Benkinooby> cking, but sending me these links is like giving a lolly-pop to a child telling it not to eat it XD - maybe i'll find myself an old laptop for toying around with that... so that i can proudly say "i managed to turn off the backlight!"
<Benkinooby> cking, thanks for the links :)
 * cking still wonders why turning *off* the backlight to work in the sunshine is going to help...
<ogra_> cking, wrong assumptions 
<Benkinooby> cking, i was already told that it is not of much use ('cept for power save)
<ogra_> the referred LCD has an actual monochrome LCD mode that seems to get activated 
<Benkinooby> ah, there we go :D
<cking> ogra_, first rule of anything with computers is "assume nothing" ;-)
<ogra_> indeed :) 
<Benkinooby> ogra_, defender of the backlight, destroyer of all excitement
<Benkinooby> hehe
<ogra_> heh
<Benkinooby> ogra_, did you actually do it?
<ogra_> did what ?
<Benkinooby> turn off the backlight
<mjg59> What hardware is this?
<ogra_> mjg59, OLPC
<Benkinooby> mjg59, http://laptop.org/en/laptop/hardware/specs.shtml
<ogra_> http://laptop.org/en/laptop/hardware/specs.shtml talks about "reflective sunlight-readable monochrome mode"
<mjg59> The OLPC backlight interface already lets you turn off the screen, doesn't it?
<ogra_> so it switches modes to old style backlight-less LCD it seems
<Benkinooby> probably
<mjg59> Sigh now you've made me actually plug mine in
<ogra_> heh
<Benkinooby> but i guess in the OLPC case they use that stuff merely for powersave than working in sunlight (although that)
 * apw hands mjg59 a pencil sharpener for his fingers
<Benkinooby> * that's a nnice sideffect
<mjg59> Benkinooby: Both
<mjg59> Benkinooby: So you're saying that you have an OLPC that won't let you turn off the backlight?
<ogra_> no
<ogra_> he has a laptop where he wanted the LCD monochrome mode by setting backlight to 0
<ogra_> as i said above, assumptions :) 
<mjg59> Oh, I see
<Benkinooby> mjg59, just wanted to see the effect... thought it might be something cool (and not dangerous) to do
<mjg59> Yeah unless it actually has transflective support, that's not going to work
<mjg59> Front lighting will give you nothing on a display that's only designed to be backlit
<ogra_> its surely not dangerous to set your backlight to 0 
<ogra_> having to hack your DSDT to get from 20 to 0 is dangerous though :) 
<cking> well, it's a do-able experiment
<Benkinooby> cking, on a non-productive system - which i don't have for now
<Benkinooby> also at the moment i lack the sunshine :(
<ogra_> why waste time on experiments where you know the outcome in advance ?
<cking> ogra_, because you learn 5 other things en-route to discovering it was pointless in the first place
<ogra_> heh
<Benkinooby> first thing would be possible: listen to those folks on irc
<Benkinooby> :P
<Benkinooby> second: dammm... my backup is older than 2 months?
<Benkinooby> anyway, i'd say case closed
<Benkinooby> thank you all (for the third time or so :P )
<noOtherOne> Hello, I'm trying to build a 3.4 kernel from vanilla sources (downloaded on kernel.org) and I'm searching for the patches that are applied on the sources for the official Ubuntu kernel (quantal). I searched in the git, but couldn't find any debian/patches directory or something like that. I guess there must be some patches involved, but where can I find them ? thanks in advance for any help !
<bjf> noOtherOne: if you just clone our Quantal tree you would get the upstream 3.4 kernel with our patches and our debian directory
<cyphermox> apw: pgraner: I'd love to see wpasupplicant debug logs... with what I see in the logs right now, the microcode error and all, I'd be tempted to say it's indeed something with the driver, but the fact that there are many high-signal APs around to roam through probably doesn't help
<apw> cyphermox, yeah we always have trouble in these environements
<apw> s/these/such
 * cyphermox still looking at the syslog
<noOtherOne> thanks bjf. I did clone the quantal tree and the debian and debian.master directory are there, but no patches subdirectory. Sorry if I'm stupid here, but does this mean the patches already are applied ?
<bjf> noOtherOne: yes the patches are already applied
<cyphermox> I should check all the disconnect reason codes there, maybe there's something, but the timeouts sending auth and associating are unusual and not really NM or wpasupplicant so much, I think
<noOtherOne> okay, sorry to have bother you with such a silly question ;o) I'm kindy new to this. I guess I'll play with some diff to checkout what has been changed. Thanks again !
<cyphermox> apw: I wonder if there aren't too few APs for the number of people, and if this is really showing up a lot more in say, plenaries :)
<apw> cyphermox, dunno hard to be sure, i am worried as they are in HK which has differnet and more channels than they can normally use those US peeps
<cyphermox> apw: I don't think so, and anyway you won't have much control over it, since this is iwlwifi
<cyphermox> the channels used are listed in the bug too
<cyphermox> hmm. looks like I'll need to look things up in the standard again :P
 * ogasawara back in 20
<apw> cyphermox, the channels allowed are listed yes, they are in world domain arn't they?  and i'd expect more channels to be avilable over there
<cyphermox> err, I haven't checked if the channels matched the world domain, but I expect they do
<sforshee> apw, according to crda the range for HK is slightly broader than that for US
<sforshee> but iwlwifi uses it's own internal world domain that seems to cover everything in the HK domain, for 2GHz at least
<cyphermox> but if more channels are available, if they're not used it doesn't affect this particular issue
<apw> sforshee, right ... thats my worry.  i have the smae problem with one of my laptops which thinks its a US model even though it isn't and we have more channels than the US in the UK
<apw> cyphermox, yeah and thats the bit i wasn't sure of, what channels are they using for their APs
<sforshee> yeah but that was brcmsmac which has a totally flubbed up regulatory implementation
<sforshee> apw, ^
<apw> sforshee, yeah there is that, but hey ... who is to say these all have not similar issues
<sforshee> if there are APs on frequencies not used by the driver though then the machine just won't see them anyway
<sforshee> so the only issue might be overcrowding on those on the other frequencies
<sforshee> apw, brcmsmac is special in this regard
<apw> "special" :)
<sforshee> I'm working on fixing it, so I'm intimately familiar with the details
<apw> yeah
<sforshee> apw, in dmesg there are "world regulatory domain updated" messages and what follows is a dump of the rules actually being used
<sforshee> what I see overlaps nicely with what crda defines for HK
<cyphermox> apw: sforshee: I updated pgraner's but with my observations
<cyphermox> and if we want even more debug output, maybe NM's wifi debug info could help too; it would say when it's trying to roam and "why"
<sforshee> cyphermox, what I've been wondering about is why preauth isn't happening/working
<cyphermox> sforshee: re: disconnect reason 2? :)
<sforshee> cyphermox, yep. I wonder why that's happening
<cyphermox> I wonder if it's not just how WPA works -- you pass it a preshared key, but in reality there has to be some kind of handshaking being done to decide what the real key would be, and changing it every once in a while
<cyphermox> if in roaming wpasupplicant tries to pass this key again (since it's the same ESSID), then that will explode.
<sforshee> I was thinking though that a STA could remain associated with one AP but go off-channel and get authorized with a different one before disconnecting
<cyphermox> maybe it's not wpasupplicant but NM, but AFAIK all NM does is write a config for wpasupplicant with the preshared key
<cyphermox> sforshee: I guess it could, but it's not being done?
<cyphermox> I'm not familiar enough with the wpasupplicant code to be able to say whether that's implemented without looking
<sforshee> cyphermox, me neither. I need to make sure my understanding of preauth is correct, then look at the code to see what it does
<cyphermox> sforshee: maybe try with just wpasupplicant to see how well that works
<cyphermox> (obviously, that will require moving around more)
<sforshee> cyphermox, I don't have an ESS set up in my house though. I may try to reconfigure my equipment later to set one up
<cyphermox> ah, I thought you were at linaroconnect
<sforshee> but I may not see the same problem since I don't have hundreds of people trying to use my wireless :)
<sforshee> cyphermox, nope
<apw> tgardner, after a bunch of poking at the pciids it turns out that actually after an upstream merge we will be in sync with debian and the latest ids
<tgardner> apw, you're talking about pci-utils ?
<apw> pciutils yes
<tgardner> ok
<tgardner> apw, I usually update it periodically throughout the dev cycle 'cause we stop syncing with upstream
<tgardner> about once a month
<apw> tgardner, yeah and we'll gain a delta again as soon as we do
<tgardner> apw, which is no big deal
<apw> indeed
 * cking wades through a pile of powertop C++
<apw> tgardner, well that was great experience, an hour doing a merge which proved i should do a syncpackage, at least I know how now
<tgardner> apw, more lore for the kdev wiki ?
<apw> its all so unstructured right now, i am slightly unsure whnat to call it
<tgardner> apw, +1 maintenance notes ?
<apw> tgardner, hmmm perhaps
<cking> packing futzing
<cking> oops. packaging
<vanhoof> bjf: apw: couple weeks back you mentioned having a smaller team being used for hwe kernels, armadaxp, highbank, at present
<vanhoof> bjf: apw: working through a few things release process wise (a checklist
<vanhoof> would you prefer a trimmed down team with ike and others who are dealing w/ maintenance on our end?
<apw> vanhoof, i don't think we care who is on it, we just want a team as that team will get tasks assigned to them
<apw> bjf, ^^
<bjf> vanhoof: what apw said
<vanhoof> bjf: apw: what team do you guys use now
<bjf> vanhoof: looking
<vanhoof> i'll make one and keep it tied to the same naming convention (if there is one)
<bjf> vanhoof: looks like "ubuntu-armel-kernel" team
<bjf> https://launchpad.net/~ubuntu-armel-kernel
<vanhoof> bjf: how about ~hwe-arm-kernel
<bjf> vanhoof: don't really care
<vanhoof> suppose I could use ~canonical-hwe-arm-kernel to keep it tied to our usual names
<vanhoof> bjf: ok ~assign-all-work-to-bjf
 * vanhoof makes team
<vanhoof> bjf: apw: done https://launchpad.net/~canonical-hwe-arm-kernel
<bjf> vanhoof, bug 1004556
<ubot2> Launchpad bug 1004556 in linux-armadaxp "linux-armadaxp: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004556
 * cking grabs some food
<vanhoof> bjf: kick ass, thanks!
<smb> ogasawara, tgardner Do you remember whether we announced the going away of -virtual as a kernel binary package somewhere else than the blueprint/spec or maybe our mailing list?
<tgardner> smb, are we pissing off the server dudes ?
<smb> tgardner, just mildly :)
<ogasawara> smb: there were discussions on the kt-ml but no official announcement, no
<smb> ok, I guess then I write up something to spread a bit more
<ogasawara> smb: however, assuming they were properly using the meta packages, they shouldn't have noticed
<apw> smb, and clearly they would send someone to the kernel sessiosn cause they care ... right?
<smb> ogasawara, They noticed because preparing the cloud-images involves creating a pvgrub config
<smb> apw, Actually I believe I told them, but you know the thing about the two weeks boundary... ;)
<smb> ogasawara, and for the pvgrub config only -virtual kernels in /boot were used
<ogasawara> smb: I can write up something more official if it'll help and spam it to ubuntu-devel
<ogasawara> smb: I'll need to write up a blurb anyways for the Alpha-1 tech overview anyways
<smb> ogasawara, Ah, well that works for me too. I was about to write it and send it to you and tgardner for fixing my incoherent thoughts anyway
<ogasawara> smb: any other lists you want me to CC?
<smb> ogasawara, ubuntu-devel and ubuntu-server probably
<ogasawara> smb: ack
 * apw moves to his laptop
 * henrix will be back in ~30mins
<bryceh> tgardner, ogasawara, apw X lts+ pkgs are up
<tgardner> bryceh, yep, saw that. ned to do some testing I guess.
<apw> bryceh, expect screaming shortly then :)
<ogasawara> bryceh: yep, saw it.  am planning to test here shortly.
<tgardner> I've got a fungible laptop
 * herton -> errand, back in 1h-2h
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 5th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * tgardner -> EOD
<kees> okay, how do I do a git bisect and retain a portion of the tree (like debian or debian.master)?
<sforshee> kees, the only thing I see that *might* help is --no-checkout, then I assume you could manually checkout everything else at each step
<sforshee> cumbersome, but it might work
<kees> sforshee: yeah, hm. I think I might just manually blow away and restore what I need.
<sforshee> that's another option :)
<kees> the "git bisect run" docs seem to think that's not a totally crazy way to do it
<kees> I was wondering if there was a general "pin" mechanism in git, but I can't find it.
<sforshee> I'm not aware of anything
<ogasawara> kees: maybe git reset <sha1> -- <path> ?
<kees> ogasawara: hrm, yeah, I'll try that.
<ogasawara> kees: I don't think it'll work, or rather needs some additional options maybe.  I just tried it here and it didn't do what I expected.
<kees> ogasawara: okay, noted.
<kees> I think I'm going to try to try some kind of hybrid bisect
<kees> or just do it by hand. do de do
<ogasawara> kees:  what are you bisecting, the mainline kernel but want the debian bits?
<kees> ogasawara: I'm bisecting a chromeos kernel, which is almost identical to the ubuntu build system.
<kees> the chromeos kernel guys are being slow to respond to my questions. ;)
<ogasawara> ah
<kees> worst-case, I think I need to identify where the split of mainline happened, keep that series and incrementally apply it to a mainline bisection. trouble is... it'll be like porting the patch sets 50 times. wheee
#ubuntu-kernel 2012-05-30
 * smb mornings
<ppisati> moin
<cooloney> ppisati: moin,
<smb> ppisati, cooloney morning guys
<smb> (or whatever time)
<cooloney> smb: hey, man
<tgardner> apw, so, are you reworking 'UBUNTU: [Config] linux-image-extras needs full postinst' ?
<apw> tgardner, yep, have it here, forgot to send it out :/
<tgardner> apw, http://tech.surveypoint.com/make-grub2-boot-the-last-operating-system-you-used.html
<apw> tgardner, thats not quite the same ... hmm
<tgardner> apw, not quite, but there are some clues there
<apw> tgardner, i am sure its a doable indeed.
<apw> ogasawara, ok i've enhanced the config checker so it basically has teh same predicate language for configuration settings ... i've made a preliminary alpha1 review page for comparison: https://wiki.ubuntu.com/KernelTeam/Specs/QKernelConfigReview/Alpha1
<ogasawara> apw: thanks, /me will review
<ppisati> apw: can you send the script used to generate the matrix?
<ppisati> *send me
<apw> ppisati, its all in kteam tools, you need the before release and after release git repos, both checked out at the branch tip you want to compare
<ppisati> apw: ack, what's the name of the script?
<apw> then you do like .../kteam-tools/devel/devel-config-summary ubuntu-precise ubuntu-quantal >SUMMARY
<apw> ppisati, but let me push the latest
<apw> ppisati, ok pushed
<ppisati> apw: so in my case, to do a comparison between master and omap4 branchesi need two dirs with Q/master and Q/omap4, right?
<apw> ppisati, to compare a non-standard branch with a standard b
<apw> branch, you can checkout the say ti-omap4 at the tip you want, and then fdr genconfigs, then checkout master-next again and regenerate
<apw> and you will get the configs mixed together
<ppisati> uhm, ok
<ppisati> let me try
<hallyn> So I've got this lenovo s10-3.  since start of maverick, it hasn't resumed from suspend, and Len Brown basically threw his hands in the air saying the bios is doing something wrong.  Now, as of a few weeks ago, the precise kernel seems to leave the wireless NIC in a bad state (broadcom) iwth phy0 rfkill hard off
<hallyn> i have to boot into lucid, suspend, resume, and then it's back up (until i boot precise)
<hallyn> anyone heard of such a thing?
<hallyn> i'm about to resign myself to running lucid on it... (or holding down paper with it)
<tgardner> cking, didn't you work on this one ^^
<cking> tgardner, I can't recall any fix I worked on for that machine
<apw> ppisati, success ??
<tgardner> cking, the s10 sounds like a model the hwe worked on.
<apw> vanhoof, ^^
<cking> bah, laptop just died
<apw> cking, you need to fix that
<cking> apw, it's called get a new one
<cking> apw, henrix, shall I check for flights for the sprint then?
<henrix> cking: hmm... actually, not sure yet as i may be flying from lisbon
<cking> henrix, ack
<henrix> cking: anyway, i'll let you know later today (or most probably tomorrow)
<henrix> cking: and thanks for asking
<cking> hallyn, I've see another S10-3 which only  suspend/resume on worked on natty
<apw> cking, yeah i may want to go out earlier will find out tonight
<hallyn> cking: for awhile in maverick/natty you could make suspend/resume work (not 100% reliably) by not using intel_idle.  but that stopped.
<hallyn> still, not resuming was a pain but not a showstopper.  no wireless is more of a showstopper.
<cking> hallyn,  apparently using kernel parameter "nohpet" seemed to have helped that particular user
<hallyn> i just don't understand why suspend/resume unblocks wireless
<hallyn> right.  nohpet never worked for me, but i've seen that.
<apw> hallyn, bios is run during those two
<hallyn> why isn't bios run during boot?  :)
<apw> hallyn, literally _anything_ can happen
<hallyn> oh, the kernel driver must muck it up?
<apw> hallyn, some bits of it are, but who knows if its working right
<apw> hallyn, likely the kernle is doing what the bios asks, and that is not working
<cking> you did say it was broadcom wireless- I suspect that's the binary blob wl driver 
<apw> hallyn, which chipset is it?  perhaps brcmsmac will work better for you
<hallyn> cking: i could try blacklisting that (thought about it( but the brcmsmac driver hangs my laptop completely
<hallyn> interesting!
<hallyn> in lucid it reports a different model # :)  Broadcom Corporation Device 4727 (rev 01)
<hallyn> pretty sure in precise kernel it said 43xx (not sure what the xx were )
<hallyn> i'm upgrading the precise partition under chroot right now, hoping for a hail mary
<apw> hallyn, that prolly means its a pciid 4727 and lucid doesn't know it
<tgardner> hallyn, have you tried the Q kernel ? sforshee has done good stuff for brcmsmac. https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
 * cking notes it could be a collection of issues, wifi, firmware, etc, so teasing it out with a Q kernel may be a good starting place
<hallyn> ok, i'll try the q kernel (if i can successfully upgrade under chroot)
<hallyn> thanks
<cking> hallyn, if you are feeling adventurous and can bear to download 650M of .ddeb, you can also try: https://wiki.ubuntu.com/Kernel/Reference/S3SystemTapDebug
<ppisati> apw: cut&pasting all the config diff is such a PITA...
<apw> ?
<apw> ppisati, from where to where ?
<hallyn> cking: probably worth it, will try, once wifi is up
<ppisati> apw: after config generation into a wiki page
<apw> ppisati, editmoin ?
<ppisati> apw: do you have any smarter way to get the data there?
<ppisati> apw: never used
<apw> thats the smarter way 
 * ogasawara back in 20
<apw> ogasawara, where are we with alpha1 kernel, i am doing some config review goop, and wondering if you'd want that in or out of a1
<tgardner> apw, I've been pushing config review related changes
<apw> tgardner, ok ta
<ogasawara> apw: push it, I'm gonna upload our Alpha-1 kernel first thing Monday
<apw> ogasawara, will do, a _few_ more do to sign
<apw> sigh
<apw> smb, CONFIG_XEN_ACPI_PROCESSOR ... any idea why that is on for amd64 and off i386
<smb> apw, I think it was changed because we don't really support a dom0 on i386
<smb> hrmpf
<smb> which was true last release at least but I just did apt-cache search...
<tgardner> apw, smb: I don't think we want to support an i386 dom0
<hallyn> cking: well i've got deb http://ppa.launchpad.net/ubuntu-x-swat/q-lts-backport/ubuntu precise main, but i'm not getting the kernel from that
<apw> hallyn, you'd have to opt in ... tgardner whats todays meta packag for the lts kernel ?
<hallyn> d'oh
<tgardner> hallyn, apw: one of the packages in  linux-meta-lts-backport-quantal
<tgardner> linux-image-generic-lts-backport-quantal
<hallyn> thanks.  i'd tried just 'linux-lts-backport-quantal' but tha didn't help
<tgardner> hallyn, it didn't help because its not a package ?
<tgardner> hallyn, p.s. the name of the meta package is going to change. rick doesn't like 'backport' in the name
<hallyn> right i guess it's the source pkg name?  anyway i'm now tethered over my phone to wifi so have a wider pipe. installing, thanks :)
<tgardner> hallyn, do you normally live at the end of a 19K baud serial line ?
<hallyn> how i wish for 19K!  300, acoustically coupled
<tgardner> what a dinosaur
<smb> tgardner, apw Somehow I would think at least the options should be right if there is a i386 hypervisor around. Which I thought was not but seem to be wrong
<hallyn> all right not really.
<tgardner> smb, -ENOPARSE, huh?
<apw> tgardner, he is saying even if we don't support it its there and the options should be right in it
<smb> *sigh* yeah, what he said
<tgardner> apw, agreed. I just don't wanna support it regardless.
<tgardner> some crazy outfit will bet their business on 32 bit dom0 using 10 year old Dell servers.
<smb> zul, Can you refresh my memory why the xen source package is in main but the binaries seem all to be in universe...
<zul> smb: the hypervisor?
<smb> tgardner, There probably already are them doing it with kvm and openstack
<smb> zul, that and the utils too
<smb> zul, at least
<zul> smb: because libxen is in main since its a dep for libvirt the rest isnt in main
<tgardner> smb, perhaps, but we don't have to give them more ways to hang themselves.
<smb> tgardner, if I am not just going mad (more than the usual) we already have the config in a way to enable it on i386 (at least precise)
<tgardner> smb, I'm sure we do, but I want it dropped by the time 14.04 is released. no better time to cut those ties then right now.
<hallyn> sigh, that didn't give me a nic at all.  fraid i need to put it aside for a bit.
<tgardner> hallyn, wtf kind of nic do you have ?
<smb> tgardner, apw I would not want to make that decision just factually. Right now a different setting for the acpi processor in quantal sure does not make sense with the other options being what they are
<apw> smb, yeah i would say i'll harmonise them to stop the errors i am seeing
<apw> and you can argue with server and get it gone
<hallyn> tgardner: broadcom somesort
<tgardner> hallyn, you're gonna have to get a dmesg before we can figure out whats happening
<smb> apw, Right, if that makes sense. Just that this is sort of a new decision/new target.
<hallyn> yeah, if i don't throw it out the window first, i'll open a bug with dmesg output and such next time i turn the thing on
<hallyn> really would be nice to have it working, but since i still have no hope for resume anyway, it'll never be what it once was :)
<apw> hallyn, if you are going to throw it out send it to sforshee
<rtg_> smb, there is no CONFIG_XEN_ACPI_PROCESSOR in precise.
<smb> rtg_, There should be. At least it is in what I got in master. And what I have been testing in -proposed
<apw> ppisati, do omap boards have 8250 serial ?
<hallyn> apw: is he building a beowulf cluster of netbooks?
<apw> hallyn, no but he has a fine hammer
<smb> rtg_, 15ca7f9c2a2dd8fdf263963c57504d0da6fbd84e
<hallyn> apw: it's my best laptop to use in the car, so i'm all talk - would more likely pick up a $15 wireless-n usb stick
<rtg_> smb, ok, it would help if I was looking at the _tip_ of master-next.
<smb> rtg_, or tip of master now
<apw> hallyn, i was thinking he could try and fix it, is easier with the device in your hand
<smb> (its the change that is currently under verification)
 * apw pokes ppisati
<ppisati> apw: there's an omap serial config, dunno if it exploits 8250
<ppisati> apw: let me check
<rtg_> smb, so I don't understand your objection to dropping this in quantal 32 bit. 
<smb> rtg_, The objection is that it does not make sense to drop that single bit from 32bit then
<rtg_> smb, thats circular.
<apw> rtg_, i think he means you have to turn off all of XEN host in 32bit or this option should be harmonised even if we offer no support
<smb> rtg_, Not when it is set y in common config
<smb> in precise
<apw> ogasawara, do yo u have a list of options you dinged for build failures on arm back in the day ?
<rtg_> apw, so what we _shold_ do for quantal is CONFIG_XEN_DOM0=n
<smb> rtg_, But that is actually a new decision
<ogasawara> apw: I'd have to grep the logs, just a sec.  I did give them all similar commit subjects so I could find them again.
<rtg_> smb, so? we make new decisions about config options all the time.
<smb> Which has not been discussed, asked for, yada, yada
<ogasawara> apw: 1bd2e66f5ab6063b153e7638453d0bcf719f842f UBUNTU: [Config] Temporarily disable CONFIG_AX88796 on arm
<ogasawara> df954481918bae6b7f93320b1be5fc0b6db42192 UBUNTU: [Config] Temporarily disable CONFIG_TI_CPSW on arm
<ogasawara> be637dbbc9c3cf51f91efec7236bef1f054c4a2f UBUNTU: [Config] Temporarily disable CONFIG_USB_EHCI_HCD_PLATFORM on arm
<ogasawara> 32e2f0b7eef1c46494ef4244646bccaa34d3b0e8 UBUNTU: [Config] Temporarily disable CONFIG_LIS3L02DQ on arm
<ogasawara> 37962f948cb20ee7fc1def0a3a8bff40abddc524 UBUNTU: [Config] Temporarily disable CONFIG_MFD_OMAP_USB_HOST on arm
<ogasawara> b1dad7778d5965bd81499ad7f44214453e5a94d6 UBUNTU: [Config] Temporarily disable CONFIG_EZX_PCAP on arm
<ogasawara> 59e1b9557ddc329e6181891ef4716ec4f2c6e1b2 UBUNTU: [Config] Temporarily disable CONFIG_TOUCHSCREEN_EGALAX on arm
<ogasawara> b45ba114bef30fbdd10c57309963f8774e8f01a9 UBUNTU: [Config] Temporarily disable CONFIG_TOUCHSCREEN_EETI on arm
<apw> rtg_, that is cirtainly an option indeed.  for me i would just leave it on and docuemnt it unsupported ...
<smb> rtg_, What I want to say is that we should bring this topic to next uds and then move forward and not just do it in q
<apw> if we are going to change it, we should at least start a thread about it
<smb> I guess at least that. Otherwise (or even with it) it ends up as the we drop non-pae
<ppisati> apw: totally different stuff (omap_serial vs 8250)
<ppisati> drivers/tty/serial/omap-serial.c
 * smb goes off to have a pint of fermented apple juice...
<apw> ppisati, ok so that doesn't need to be builtin for arm* then yes?  8250 serial drivers ?
<ppisati> apw: nope
<ppisati> apw: actually i'm talking about omap here
<apw> ppisati, as am i, omap only
<ppisati> apw: if you are doping another arm soc, it's a totally different thing
<ppisati> ok
<apw> omap3 only indeed
<apw> master branch only
<ppisati> ack
<apw> ppisati, thanks
<ogra_> do we have an equivalent to the linux-version tool from debian ? (from linux-base)
<apw> ogra_, no but that one should be installable now after tgardner fixed it
<apw> ogra_, as to whether it works ... is another question, if not poke me
<ogra_> ah, great, seems the new flash-kernel uses it 
<ogra_> yeah, i got f-k on my TODO for tomorrow to fix the rough edges
<apw> ogra_, ok let me know, i need some u-space to play with
<ogra_> k
<hallyn> tgardner: http://paste.ubuntu.com/1015033/ has dmesg and lspci -v output fwiw (with q-backport kernel)
<rtg_> ogra_, all I dropped from linux-base was /usr/bin/perf. /usr/bin/linux-version should still be intact.
<apw> rtg_, my memory is it may need ubuntuisation, but ogra_ can test that, and if it does we can fix it
<ogra_> rtg_, awesome 
<ogra_> yeah, i will work through the bits and pieces tomorrow and let you guys know if i stumble
<rtg_> apw, possibly, but thats a different problem.
<hallyn> oh that's before i modprobe brcmsmac
<rtg_> hallyn, why do you have to modprobe it? do you have black lists ?
<apw> hallyn, do yo have wl installed, that blacklists brcmsmac by default, and bcma which it needs
<rtg_> hallyn, what apw said. plus you may need linux-firmware-nonfree
<hallyn> oh riht that might have happened, i can't check right now bc after i tried to soft-unblock phy0 (with fn-f5) it hung
<hallyn> do i need linux-firmware-nonfree only to use wl, or also for brcmsmac?
<rtg_> hallyn, just for brcmsmac
<hallyn> these names just kill me.  is brcmsmac supposed to replace b43?
<apw> hallyn, i believe so yes
<hallyn> actually bcma-pci-bridge is what has started auto-modprobing
<hallyn> heh, but no change.  when i unblock phy0, the thing hangs
<hallyn> cking: d'oh, i assume ddebs.ubuntu.com won' thelp me when i'm running the q-backports kernel
<rtg_> hallyn, correct
<cking> hallyn, yep
<dileks> http://packages.ubuntu.com/precise/all/linux-firmware/filelist
<dileks> http://packages.ubuntu.com/quantal/all/linux-firmware/filelist
<dileks> are there missing fws for ath6k?
<bjf> rtg_: when you get some free time, gomeisa could use htop
<rtg_> bjf, done
<apw> dileks, there appear to be fewer in quantal, presumably we don't need them there as we only have 3.4 kernels ... rtg_ ^
<cking> bjf just wants to see how hard he is driving it
 * bjf likes to make her squeal
<rtg_> dileks, right, I removed some older firmware files. did I get overzealous ?
<dileks> cant test as I have no ath6k wificard. I was asking bwh whuzzup on debian as ath6k was activated recently for trunk.
<dileks> is linux-firmware the correct place or should it be in -nonefree pkg?
<dileks> I mean whats the criteria to put fws in the one or other pkg?
<rtg_> dileks, its must be redistributable
<jwi> rtg_: oh, that's a nice surprise for folks bisecting through older kernels...
<dileks> if its in linux-firmware.git its "freely redistributable"?
<rtg_> jwi, we don't support kernels older then 3.2 on precise.
<rtg_> dileks, yep.
<jwi> rtg_: i think the ar9170* are no longer used (replaced by carl9170); ar7010 looks fairly old too (htc_7010 now?)
<dileks> rtg_: thank you for enlightenment
<rtg_> jwi, I mostly went by the MODULE_FIRMWARE statements in the kernel. there may well be some old cruft that I missed. 
<rtg_> I should get back and finish up a more thorough review
<rtg_> I was just looking to save some space on the LiveCD
<apw> ogasawara, ok i've updated the summary a few more times, added a 'BUILD FAILURES' section for the ones you t
<apw> turned off
<ogasawara> apw: ah nice
<ogasawara> apw:  so did you just hardcode the build failure ones?  or should I stick with the same commit subject so it can be auto extracted?
<rtg_> apw, when using quilt in a  debian package it appears you cannot patch anything under the debian directory. Is that your experience ?
<apw> rtg_, right you can just edit those is my understanding
<apw> ogasawara, they are listed in the overrides right now
<rtg_> apw, thats what I've done after struggling a a bit
<jwi> rtg_: dropping support is fine; but missing firmware is gonna make it a little harder to even *run* an older kernel (for testing purposes, to investigate a regression, ...).
<jwi> but i guess those folks know where to get the files manually
 * ppisati is off
<dileks> is that apt-pinning really necessary?
<dileks> https://wiki.ubuntu.com/Testing/EnableProposed
<dileks> especially -security and -updates
<dileks> if there is a higher ubuntu-version, this will be taken
<apw> dileks, i beleive that lets you not get proposed items you didn't specificially ask for
<dileks> giving -proposed 400 will not automatically update pkgs
<dileks> not using a preferences file will give -proposed 500
<apw> dileks, i believe the intent of those is to let you make -proposed optin like -backports now is, i have no idea if that will work as written
<dileks> /etc/apt/sources.list.d/ubuntu-precise.list: http://paste.ubuntu.com/1015170/
<dileks> I put that extra and partner repo stuff into /etc/apt/sources.list.d/ubuntu-precise-partner-and-extras.list
<dileks> http://paste.ubuntu.com/1015175/
<dileks> dunno why /etc/apt/sources.list.d/$file is not used
<dileks> its much nicer than a big fat sources.list
<apw> dileks, presumably cause all the code which fiddles with it from the UI would have to change
<apw> even if ti could be cleaner and simpler now
<apw> ogasawara, am just buildtesting my config changes on x86 and then will push
<ogasawara> apw: ack
<apw> ogasawara, not bad for an afternoons effort, some 20 or so purples gone
<ogasawara> apw: nice
<apw> the new predicate based matching is helping get rid of 'em
<apw> ogasawara, more tommorrow :/
<dileks> apw: what do you mean by "UI"?
<tgardner> ogasawara, you won't send out the LTS kernel email  soon, will you ? I'm futzing with meta package names still.
<ogasawara> tgardner: am coordinating with nick skaggs, we're thinking of sending out some sort of announcement next Thurs to align with Alpha-1
<ogasawara> tgardner: that enough time?
<tgardner> ogasawara, thats plenty of time. thanks.
<apw> dileks, the config manager thing for sources
<tgardner> ogasawara, uploaded new LTS kernel and meta packages to Q-series LTS Backport with -backport removed from all names. they should appear in awhile.
<ogasawara> tgardner: ack
<ogasawara> balloons: ^^
<tgardner> ogasawara, gotta keep rick happy :)
<balloons> ack, thanks
<ogasawara> tgardner: heh, yah I informed nick we should strip all uses of the word "backport" from the announcement
<tgardner> ogasawara, cool. I'll confirm everything looks good in the morning. I'm EOD.
<ogasawara> tgardner: ack, I can test here too
 * tgardner -> EOD
#ubuntu-kernel 2012-05-31
 * apw yawns
<ppisati> moin
<smb> morning
<patc> hello!
<patc> how to know wich kernel versions are available for each ubuntu version? Is it usefull to update to the newest stable release?
<patc> kernel release*
<patc> can I use a 2.6.35 kernel with ubuntu 10.04 for example?
<patc> ?
<patc> sorry i leftz too quickly
<apw> patc, there is a version page for each package in the archive: https://launchpad.net/ubuntu/+source/linux
<patc> apw: thank you :)
<patc> can you perhaps tell me why the atests stable versions are not pushed by default for ubuntu? I mean : I saw that 2.6.35 was available for ubuntu 10.04, why isn't it proposed in the regular upgrades?
<patc> i am quite new to linux so perhaps don't I understand everything... ;)
<apw> patc, ubuntu is pretty conservative within a release, so you will get the upstream stable releases for that base version by default
<apw> patc, for 10.04 (lucid) there are LTS backports kernels but those you need to opt-in to, and really for most home type users just upgrading to the next release makes more sernse anyhow
<apw> patc, as you want the rest of your packages to be nice and new and shiney too
<patc> apw: so if I understand, upgrading to a newer kernel release is a good idea, correct?
<patc> apw: how to know until wich version you can upgrade without taking the risk to break things down?
<apw> patc, no i am saying that generally people who want a newer kernel in a home context probabally want really to upgrade everything
<apw> patc, as those are a well tested combination.  normally you can download a live CD to test if the new version is ok for your system
<patc> apw: for my understanding : does upgrading the kernel imply upgrading other packages too?
<apw> upgrading the kernel does not imply the necessarily if you use the LTS backport kernels in an LTS but yes
<apw> i am suggesting that upgrading to the later release is normally more what a normal user wants
<apw> cause shiney new things are always good
<patc> apw: ok, I see. Hm... My question's origin is a post somewhere that explained howto upgrade the GC drivers. I could use the : deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu lucid main #xorg-edgers PPA
<apw> yep you can get lots of fine crack from that PPA
<patc> apw: but the poster also explained that another step was to update the kernel to a newer version :$ sudo apt-get install linux-image-2.6.35-6-generic linux-headers-2.6.35-6-generic
<apw> well thats a non-supported kerenl now from an unsupported release, so that'd be a bad thing to install
<patc> apw: that's why I asked about all these versions... to be sure what I'm trying to do isn't going to break things down
<patc> apw: as far as I understood, it's alwas possible to boot using one of the older kernels installed in case of a proble, right?
<apw> but probabally everything in xorg-edgers is in the later releases
<patc> ! oh yes? in the later releases... you mean : 12.04 and so on? But for the moment I need to stay with my 10.04... so how to use the latest video driver without using the ppa?
<ubot2> patc: Error: I am only a bot, please don't think I'm intelligent :)
<apw> what holds you on 10.04?  though the ppa is likely your best bet and you could investigate the linux-lts-backport-oneiric kernel as an option
<patc> apw: 2.6.35-6-generic is NOT supported? how can I find wich versions are or are not suported?
<apw> patc, pretty much the only supported versions are latest versions in each relesase
<apw> which are on that page i sent you, but only the ones in a specific release are support in that release, plus the backpotr kernels in the 10.04
<apw> and you should instlal those via the linux-lts-backport-<release> packages so you get security updates for your kerneles
<apw> so for the 2.6.35 series that was maverick, and maverick is completely off support, so there are no 2.6.25 kernels which have support in the LTS
<patc> apw: I'm going to change for 12.04 in a while, but as I'm still learning alot, I would like to test things under my "old" install instead of just using without knowing (with a newer distro with everything working fine). Having to investigate into kernels updates, drivers installation makes me learn! :)
<patc> 2.6.35, not 25
<apw> ny error i intended to type 2.6.35, just missed
<patc> :)
<apw> but the 2.6.35-6 kernel would have probabally not even have been a released version but one in the pre-release phase of the cyle, we normally release with about a -12 or more package
<apw> and cirtainly -6 was not the last maverick kernel so that specific kernel would be a bad plan security wise
<patc> understood
<patc> lots of things to learn here...  :D
<patc> hm... I need to check all this more in details, thanks for your answers apw
<apw> yeah the latest kernel in maverick was 2.6.25-32.68 ... so a lot newer than the one that forum post (or whatever) is suggesting
<patc> yes, that's one of the things that awoke my curiousity
<apw> s/25/35/ ... damn keyboard
<patc> 2.6.32.59 is the latest kernel available in the 2.6.32 serie, correct?
<patc> ;)
<apw> i assume thats a stable update version number
<patc> http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ChangeLog-2.6.32.59
<patc> so my question is : why is that one not pushed to my system? because of the conservative view thing?
<patc> mine is 2.6.32-41-generic
<apw> 2.6.32-41.902.6.32.59+drm33.24
<apw> 2.6.32-41.90   2.6.32.59+drm33.24
<patc> euh...?
<apw> ok so the kernel version you have is likely -41.90 which is based on upstream 32.59 and smb's drm tree
<apw> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html
<smb> (which is because our 2.6.32 kernels have the drm subsystem of 2.6.33)
<apw> that URL gives you the mapping ... from your running kernel "cat /proc/version_signature" that gives you the real versions
<patc> oooh ok i see
<apw> the package version is an ubuntu version number, so a 2.6.32 base -41'st ABI revision, 90th upload
<patc> not easy to understand for a beginner lol
<apw> https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2BAC8-FAQ.2BAC8-GeneralVersionMeaning.What_does_a_specific_Ubuntu_kernel_version_number_mean.3F
<apw> much of it is in the FAQ if you know what to ask for 
<patc> YES! you told the right words : IF ou KNOW WHAT you're looking for! ;)
<apw> indeed, which is why i am not just saying "read the faq" :)
<patc> that's the problem when starting somewhere.... you don't always know what you don't know! :D
<patc> yes, that's nice of you
<patc> as I said, I'll check all this mor in details... thank you for your answers
<patc> more*
<apw> good luck
<patc> oh and another thing, I left too quickly just before, but how can I check
<patc> when I let the chat open, and go afk... that someone has answered my question... can I parse the dial for tag with my name ( i mean after 10000 messages have been written)
<patc> I think this is the way to do it...
<patc> do you have another suggestion?
<apw> yeah in my client i can hit alt-P and it searches for things sent to me
<patc> apw: oh ok : what client?
<apw> patc, i use weechat, but i suspect its a common feature
<patc> OK... for sure... I discover all that.... I rarely use irc... as you perhaps noticed ;)
<patc> apw: OK... for sure... I discover all that.... I rarely use irc... as you perhaps noticed ;)
<ppisati> cooloney: do you know if ming is around?
<cooloney> ppisati: yeah, he is also in linaro connect
<cooloney> ppisati: i asked him to chat with you
<ppisati> cooloney: no prob, i sent you (you + ming) an email
<ppisati> cooloney: how is the connect going?
<ppisati> cooloney: anything interesting?
<apw> smb, CONFIG_USB_MON for some reason i think this needs to be builtin to be useful, but i have the feeling this info came from you t/f ?
<cooloney> ppisati: yeah, nice event, lots of discussion about big.LITTLE, power management, Android/Ubuntu, etc
<cooloney> ppisati: i didn't get the email. weird.
<cooloney> apw: USB_MON is quite useful for USB debugging in kernel, i think
<apw> cooloney, yeah trying to remember if =y is necessary or of =m is more appropriate
<apw> tjaalton, CONFIG_STUB_POULSBO we have that off right, to use DKMS packages ...
<tjaalton> apw: probably so, though i haven't played with that crap
<apw> tjaalton, ahh who is in the frame for that
<tjaalton> tseliot or Sarvatt should know
<apw> tseliot, ^^
<jwi> apw: I'd assume it's no longer needed - the kernel now has a proper driver for those devices, gma500
<apw> jwi makes sense
<tjaalton> and it's off staging?
<apw> i think all of them are off actually
<smb> apw, This is quite some time ago to remember (USB_MON). Might be ok with =m but not sure
<apw> smb, i know :)
<smb> If unsure, say Y, if allowed, otherwise M... 
 * smb shrugs
<apw> what use is that
<smb> Not much. From the doc it rather seems that it works as good when done as module
<smb> You just then need to remember to probe the module
<smb> Since it only adds something to the debugfs it won't autoprobe
<apw> then that can go =m thanks
<Caribou> apw: ping
<apw> Caribou, hi
<Caribou> do you still have the 2.6.38-8-server dbgsym package that you had me test recently ?
<apw> Caribou, you are in luck: http://people.canonical.com/~apw/ddeb/
<tseliot> apw: what's the question, exactly?
<apw> tseliot, trying to confirm which poulsbo kernel options should be on/off, seems we have CONFIG_STUB_POULSBO and CONFIG_DRM_GMA500, and i know we have binary stuff too
<tseliot> apw: I think CONFIG_STUB_POULSBO is just to catch some pci ids
<tseliot> I'll let you know about the other option
<apw> tseliot, CONFIG_STUB_POULSBO is off right now
 * ppisati -> vanilla ice cream + Baileys
<smb> ppisati <- bad idea, but tasty
<ppisati> smb: bad idea? is good! :)
<ppisati> smb: my only grief is: shall i store the Baileys in the fridge after i opened it or not? after all it contains milk/cream...
<smb> ppisati, As good as coffe+Baileys was back as students. Not much learning done after that... I thought open bottles would not survive long enough to matter...
 * dileks asks himself why eric dumazet is not working for canonical
<ppisati> smb: my gosh, how much bailyes did you put in the coffee to be ouf of order? :)
<smb> ppisati, Not so broken, but the desire on work being diminished. :-P
<apw> ppisati, it really doesn't go off in my experience, its got so much booze in it
<apw> ppisati, but we may have to throw you off the team if you can't drink it before it does :)
<ppisati> ahhh... it was good! :)
<ppisati> apw: i'll do, it's one of my goals for the next cycle :)
<apw> damn i hope the bottle doesn't last a whole cycle
<ppisati> i'll do my best to kill it sooner :)
<tgardner> ppisati, armhf is "skipabi= true" and "skipmodule=true" for both Precise and Quantal, but armel is not. Does that seem like an oversight ?
<ppisati> tgardner: Q has no armel
<ppisati> tgardner: but yes, arch shdouln't matter
<tgardner> ppisati, ok
<apw> git show debian.master/configs >P
<apw> git apply -R --index <P
<apw> git commit --ame
<apw> # above gets rid of the config portion
<apw> fdr genconfigs
<apw> will give you CONFIGS/*highbank*
<apw> which you can keep and apply again later
<apw> git commit -a --fix HEAD
<apw> git rebase -i --autosquash
<apw> ppisati, i've just dropped you a list of configuration options which are purple for ARM and wonder if you could reply when you have time
<tseliot> apw: that's good
<apw> tseliot, heh ok
<ppisati> apw: saw it, i'll check them
<apw> ppisati, thanks
<ppisati> ppisati@tangerine:~/ubuntu-quantal$ ls -la debian.ti-omap4/config/
<ppisati> drwxr-xr-x 2 ppisati ppisati   4096 May 31 14:17 armhf
<ppisati> -rw-r--r-- 1 ppisati ppisati 103053 May 31 14:17 config.common.ubuntu
<ppisati> here is where the arch agnostic stuff should go, ok?
<ppisati> ppisati@tangerine:~/ubuntu-quantal$ ls -la debian.ti-omap4/config/armhf/
<ppisati> -rw-r--r-- 1 ppisati ppisati   87 May 31 14:17 config.common.armhf
<ppisati> -rw-r--r-- 1 ppisati ppisati   88 May 31 14:17 config.flavour.omap4
<ppisati> and these are actually empy
<ppisati> so the entire config is the "commong" config gile
<ppisati> file
 * ppisati -> coffee, brb
<apw> well more correctly all of the options are common to all flavours in the tree, therefore all the options move up to the top yes
<ppisati> yes
<ppisati> that was my point
<apw> well indeed, and what you want is a different thing
<apw> you want a list of options we expect to have specific values
<apw> and we don't have that, other than in the config-checker
<ppisati> and we overwrite the arch/machine specific bits one one directory below
<apw> and though that is the names, the config system doesn't work the way they sound
<apw> it is showing your what _is_ common, not what you want common
<apw> and i can definatly see how the latter is useful
<apw> tgardner, yell when it is pushed
<cking> apw, I've fwd'd you the flight details. Are you planning different travel arrangements?
<apw> cking, will check and let you know
<apw> cking, and we are tlaking to you
<cking> aah.. /me kicks mumble
<tgardner> apw, just pushed the skipabi/skipmodules patch to quantal
<apw> tgardner, perfect
<ppisati> is powerpc an arch or a flavour in the enforce world?
<ppisati> apw: i was just recompiling a Q/master armhf kernel for the config review
<ppisati> with some options adjusted, when enforce complaiend about some stuff
<ogra_> hmm, does anyone know where the perl module for "DebianKernel::BootloaderConfig" lives ?
<ogra_> seems linux-base makes use of that in its postinst but i dont see a dep on something containing it 
<ppisati> apw: http://paste.ubuntu.com/1016362/
<ppisati> apw: but the config diff is arm only, and enforce complains about ppc
<ppisati> apw: moreover, genconfigs doesn't complain
<apw> genconfigs should complain hrmmm ... brokenness
<apw> ppisati, will fix
<apw> ppisati, actually in the tip of my tree it is =y
<ppisati> apw: what's =y?
<apw> CONFIG_THERM_ADT746X
<ppisati> let me check
<apw> ppisati, or did i just ask you to make it =m
<apw> apw@dm:~/archive/git2/ubuntu-quantal$ git grep CONFIG_THERM_ADT746X debian.master/config/
<apw> debian.master/config/config.common.ubuntu:CONFIG_THERM_ADT746X=y
<ppisati> ppisati@tangerine:~/ubuntu-quantal$ git co debian.master/config/armhf/config.flavour.omap
<ppisati> ppisati@tangerine:~/ubuntu-quantal$ git rhard origin/master
<ppisati> HEAD is now at de7bd18 UBUNTU: Ubuntu-3.4.0-3.8
<ppisati> ppisati@tangerine:~/ubuntu-quantal$ git diff
<ppisati> ppisati@tangerine:~/ubuntu-quantal$ schroot -c quantal-amd64
<ppisati> (quantal-amd64)ppisati@tangerine:~/ubuntu-quantal$ export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-
<ppisati> dpkg-architecture: warning: Specified GNU system type arm-linux-gnueabihf does not match gcc system type x86_64-linux-gnu.
<ppisati> (quantal-amd64)ppisati@tangerine:~/ubuntu-quantal$ fakeroot debian/rules clean editconfigs
<ppisati> change any options, and enforce will complain
<ppisati> about that THERM_ADT746X stuff
<apw> tgardner, we are missing an empty abi on highbank, you wanna add that to your d-i unfook update?
<tgardner> apw, yep, working on it. also fixing udeb cruft
<tgardner> apw, repushed master-next with some squashes. shold fix ABI/modules check and udeb build failures.
<tgardner> apw, you should just bump the ABI so there is a clean break before all of this config change carnage.
 * ppisati -> brb
<apw> tgardner, yeah i was assiming that when it gets uploaded, the whole thing would be an ABI bump and we'd just shove it at the bottom
<apw> (before everything)
<apw> tgardner, if you are rebasing anyhow you may wish to do that
<tgardner> apw, go ahead and get your stuff done, then we can add the ABI bump whenever
<ogasawara> tgardner, apw: Tandy Whitner, can you dudes do your +1 maint rotation in June?
<tgardner> ogasawara, sure, since I'm gone a good part of the month :)
<ogasawara> tgardner: well that would in theory work, ie apw does it for the half of the month you're away
<ogasawara> tgardner, apw: I'm giving slangasek my ack to take you guys that month
<tgardner> ogasawara, ack
<apw> ogasawara, the june which starts tommorrow ?
<tgardner> apw, yeah, we're all done with Quantal kernel development aren't we ?
<slangasek> tgardner, apw: \o/  so there's a #ubuntu+1-maint channel; we probably won't really kick things off until next Monday (rather than June 1) because Adam Conrad is out at LinaroConnect right now
<tgardner> slangasek, it'll take him a day or 2 to get un-lagged. thats a long trip.
 * ogasawara back in 20
<henrix> just lost connection both to zinc and to mumble... is it only me?
<tgardner> henrix, I've still got mumble
<henrix> tgardner: interesting... email and canonical irc are also gone
<tgardner> henrix, perhaps your ISP is having some route issues
<henrix> tgardner: yeah, probably
<henrix> ok, i'm back online
<apw> ppisati, CONFIG_SENSORS_* ... i assume that most of these never can exist on arm?  do you know which ones can ?
<ppisati> apw: it all depends on the board...
<ppisati> btw, Q/master doesn't boot on beagle...
<ppisati> Error: unrecognized/unsupported processor variant (0x413fc082).
<apw> ppisati, yay
<cking> that's an informative magic number
<apw> ppisati, fun for poalo
<ppisati> strange that noone shouted about it on the arm ml
<apw> ppisati, that might be quite an urgent problem with a1 right round the corner
<cking> isn't that a Cortex A8 identification register value?
<apw> cking, can you decode it ?
<cking> apw, http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/ch01s09s13.html
<ppisati> cking: yep, should be processor id or stuff like that
<ppisati> but the point is that this chip is supported, so it must something else
<ppisati> *must be
<tgardner> apw, all the sensors are I2C aren't they? the options should be harmless.
<apw> tgardner, they should be harmless i think yes, just wondering if actually its worth building them at all, we could not bother if they can't exist
<tgardner> apw, I was just think in interest of commonizing the configs...
<tgardner> thinking*
<apw> yeah though we could comonise x86 etc on, and arm off and be in a better place than here if not ideal
 * apw likely will commonise them anyhow
<apw> tgardner, https://wiki.ubuntu.com/KernelTeam/Specs/QKernelConfigReview/Alpha1
<apw> is the progress i have made so far, and this kernel still boots :)
<tgardner> apw, does the pink go away if the config option is annotated ?
<apw> yes, though the right column has the text of the annotation
 * jsalisbury keeps bouncing, grr
<apw> see the top of the netfilter matches for an example
<tgardner> apw, so I'm looking at 'Inconsistent BUILD FAILURE' for CONFIG_TI_CPSW. Why is it still pink since its been annotated ?
<apw> ahh cause i have only marked it as a BUILD FAILURE and not allowed it to be off long term
<apw> as for me i want build failures to show up so that we don't forget them
<apw> so that is deliberate
<ogasawara> apw: I like the new build failures section
<tgardner> apw, maybe a different color so there are easily ignored for now ?
<apw> CONFIG_APM_EMULATION for example is one with an anotation which is clean
<apw> tgardner, will think about that then
<tgardner> apw, right, that looks good
<apw> so if i had said we are never going to fix those i could mark them non-red
<apw> but i think they are something till release we should remember and worry about
<apw> plus if you fix them they will stop being pink and we can see we have fixed them
<tgardner> apw, ok. there is still so much pink that its hard to see the forest for the trees
<apw> and remove the build failure flag
<apw> tgardner, yep am working on it ... i had it down to like 8 pink in the whole file till you added highbacnk
<apw> i was hoping to get to 0, but ... you scuppered that
<tgardner> apw, thank ikepanhc for that :)
 * apw looks up the word thank in the dictionary ... hmm nothing about sharp object under the fingernails ?
<tgardner> apw, note that Rob Herring is giving him some grief as well about precise configs
<apw> about missing things ?
<tgardner> apw, indeed
<tgardner> forwarded to the kteam list
<apw> we should be able to apply the same changes back in theory, i am documenting them at least in part
<apw> tgardner, should i be doing this on precise at the same time ?
<tgardner> apw, thats the kernel thats most important to hew right at the moment. I think it will go out in the 12.04.1 release.
<tgardner> hwe*
<apw> tgardner, ok ... then i'll replicate my changes there ... sigh ...
 * cking grabs some food
 * ppisati -> gym
<tgardner> bjf, were you just checking to see if I was paying attention ?  :)
<bjf> tgardner: rectal-cranial inversion
<tgardner> bjf, what is the bug number for CVE-2012-2375 ?
<ubot2`> tgardner: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2375)
<bjf> tgardner: did i leave that off as well ....
<tgardner> bjf, yep, I checked the original patches as well
<bjf> tgardner: bug 1002505
<ubot2`> Launchpad bug 1002505 in linux "CVE-2012-2375" [Medium,In progress] https://launchpad.net/bugs/1002505
<herton> ppisati, oneiric ti-omap4 in your repo has an enormous changelog (3.0.0-1211.23)
 * cking just realises there are two UK holidays next week, *sigh*
<apw> cking, which days do we get ?
<cking> apw, mon + tue (apparently)
<cking> so if you can ack or nack the flight info tomorrow I can get these booked before the prices get mad
<orated> Hello! What is the boot sequence followed in booting linux?
<apw> orated, that all depends on the h/w
<orated> Ok, then Ubuntu running on x86?
<cking> orated, http://duartes.org/gustavo/blog/post/how-computers-boot-up is quite handy
<cking> bit old, but it is a start
<cking> orated, and also http://duartes.org/gustavo/blog/post/kernel-boot-process
 * cking --> EOD
<mozmck> what might cause my sound to stop working and the speakers to pop every few seconds this morning?  I did an update but don't remember any sound related packages.
<mozmck> xubuntu 12.04
 * ogasawara lunch
<ppisati> herton: because size does matter! :)
<ppisati> herton: no ok, let me check...
<herton> ok :)
 * ppisati just came back from gym and had some food... i like like an entire truck passed over me...
<ppisati> herton: fixed, go ahead
<herton> ppisati, fetching, thanks
<herton> ppisati, the changelog still includes everything until Ubuntu: 3.0.0-15.26
<herton> ppisati, it comes from the rebase
<ppisati> wtf?!?!
<ppisati> wait...
<ppisati> herton: i was 100% sure that i fixed it...
<ppisati> bah...
 * tgardner -> EOD
<ppisati> herton: ok, try now...
<herton> ppisati, looks good now
<bjf> CVE-2012-2663
<ubot2`> bjf: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2663)
<bjf> jjohansen: ^ you have a bug # for this CVE yet?
<jjohansen> bjf: https://launchpad.net/bugs/1007091
<ubot2`> Launchpad bug 1007091 in linux-ti-omap4 "CVE-2012-2663" [Low,Fix committed]
<bjf> jjohansen: thanks
<bjf> ogasawara: bug 1007159
<ubot2`> Launchpad bug 1007159 in linux "ecryptfs test on btrfs failing on "no space left on device"" [Undecided,Confirmed] https://launchpad.net/bugs/1007159
#ubuntu-kernel 2012-06-01
<ppisati> moin
<cking> morning ppisati
<smb> morning
<brendand> hi - where do i get the so called 'precise+' packages from?
<cking> brendand, sorry, I have no idea what precise+ means
<ohsix> precise-proposed?
<cking> who knows
<brendand> cking, i've heard it used as shorthand for the Q -> P backports
<brendand> cking, not widely used yet i guess
<brendand> anyway i found the ppa
<brendand> https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<cking> brendand, well, it sounds reasonable, but personally I am not sure about this
<brendand> cking, maybe some management speak ;)
<brendand> cking, i didn't make it up, but maybe whoever i heard it from did. anyway Q series LTS backport is a bit long for many purposes so i hope there's some shorthand for this construct
<ohsix> i've seen that in git, from the generated versions; if you've modified a tree at a certain tag it will be 'tag+whatever'
<brendand> cking, on other news we're about to start weekly testing so hoping to see some new fwts bugs opened soon
<brendand> cking, can you remind me what was agreed?
<brendand> cking, where do they need to be raised?
<cking> brendand, I think that's a vanhoof question
<brendand> cking, sure thing
<cking> brendand, but I'm OK also to view any bugs found
 * apw is out for a bit to handle a flat handover
<sss> hello :) I have a strange question and I Hope that sombody will be able to help me :) How can I calculate the number of pthread_mutexes in running kernel? All mutexex, not only holded.
<janimo> is maint-startnewrelease applicable to all ubuntu kernel packaging processes (i.e. SRU) and where can I find this script?
<janimo> nm, found kteam-tools
<tjaalton> sbuild/schroot is broken with 3.4 kernel, I get "Use of uninitialized value $chroot_arch in chomp at /usr/share/perl5/Sbuild/Build.pm line 2020."
 * apw enjoys a panini
<tjaalton> schroot fails due to pam_loginuid failing (from auditd)
<tjaalton> wonder what that has to do with the newer kernel
<apw> tjaalton, hmmm, that i've not heard of
<tjaalton> Jun  1 15:08:10 eldon sudo: pam_loginuid(sudo:session): set_loginuid failed
<apw> jjohansen, any idea if we have changed semantics of set_loginuid() or if AA could be involved there?
<apw> tjaalton, looks like a kernel change ... and a deliberate one
<tjaalton> apw: alright
<apw> +#ifdef CONFIG_AUDIT_LOGINUID_IMMUTABLE
<tjaalton> so userspace should adjust?
<apw> +       if (task->loginuid != -1)
<apw> +               return -EPERM;
<apw> +#else /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */
<apw> +       if (!capable(CAP_AUDIT_CONTROL))
<apw> +               return -EPERM;
<apw> +#endif  /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */
<apw> +
<apw> tjaalton, specifically that added ...
<apw> tjaalton, we have LOGINUID_IMMUTABLE enabled ... i think we need to refer this to security for their advice
<tjaalton> apw: ok, thanks for digging this up
<apw> tjaalton, we may be able to just turn it off, but even so it might be something we want on by release and something we need to cope with somehow
<tjaalton> I'm using the backport kernel on precise ;)
<apw> tjaalton, i could make you a kernel with it off and see if that helps for testing?
<tjaalton> sure
<apw> oh erp
<tjaalton> I've got a laptop to break
<apw> tjaalton, can you file a bug so we have somewhere to track this ... 
<tjaalton> but on the desktop i'm using 3.4 until the gpu hang fix is found and backported to 3.2..
<tjaalton> sure
<tjaalton> the kernel?
<apw> excellent thanks, yes against the kernel
<tjaalton> ok on it
<apw> title it with the schroot symptoms for now
<tjaalton> yeah
<tjaalton> note that uninstalling auditd makes it work again, since pam_loginuid doesn't barf
<tjaalton> or just commenting it out from common-session
<tjaalton> might break something but meh
<tjaalton> at least I have a workaround for building packages..
<apw> yeah thats something
<tjaalton> apw: bug 1007396
<ubot2`> Launchpad bug 1007396 in linux "sbuild/schroot broken with 3.4 kernel if auditd installed and pam_loginuid in common-session" [Undecided,New] https://launchpad.net/bugs/1007396
<ppisati> and even the nic is dead.. f$*$*(#@...
<apw> ppisati, ?
<ppisati> omap3
<ppisati> the network card is not working
<ppisati> the module is built
<ppisati> but it doesn't get loaded
<ppisati> and even if i manually load it
<ppisati> the nic is dead
<apw> yay
<ppisati> for some uknown reason
<apw> ppisati, has a long week ahead of him
<ppisati> right
<ogra_> ppisati, is USb working at all ?
 * ogra_ heard about USb issues with recent kernels in #beagle but i didnt pay very much attention to it
<ppisati> ogra_: Q kernel didn't even boot on omap3 so i dout they tested usb
<ppisati> doubt
<ogra_> well, i only heard that from a certain mainline version on USb broke ... ask in #beagle for more info ...
<ppisati> ack
 * ogasawara back in 20
<apw> ogasawara, i have a heap more highbank config in my tree, please say no to anything in debian.master/configs :)
<ogasawara> apw: go ahead and push em.  I was going to do some test builds and boots today and possibly upload
<ogasawara> apw: I can wait to upload on Monday if there's more you want in
<apw> ogasawara, will do shortly want to make sure it boots for highbank before i do
<apw> ogasawara, expect some powerpc fallout, so doing a power build is worth the effort
<ogasawara> apw: ack
<apw> (not from the highbank merge, but the previous cleanups already in)
<ogasawara> apw: I think I might wait till Monday anyways to upload in case anything else comes in we need for Alpha-1
<apw> ogasawara, but yeah doing some test builds would be worthy
<apw> ogasawara, i have done basics but its easy to bust things
<ogasawara> apw: ack, will definitely do test builds and boots regardless today
<apw> ogasawara, ok will get what i have tested by hwe, and push this snapshot
<ogasawara> apw: ack
<diwic> ogasawara, it looks like the kernel team stopped providing l-b-m for alsa, huh?
<diwic> ogasawara, not saying you have to provide it - now is the first time I noticed it - but just wondering if that was concious
<ogasawara> diwic: it indeed has been a while since we provided an updated alsa in lbm
<ogasawara> diwic: I can't remember an exact reasoning for why though
<apw> ogasawara, ok a heap of config boot tested on highbank and pushed to quantal master-next
<apw> ogasawara, will continue on for a bit, but thats a good baseline
<ogasawara> apw: ack thanks
<apw> ogasawara, hows the testing going ?  did powerpc build ?
<ogasawara> apw: I haven't yet kicked it off, got sidetracked and just coming back around to it now
<apw> ogasawara, ahh np
<ogasawara> apw: will keep you posted though
<apw> ogasawara, thanks ... i have a couple of changes pending so let me know if it breaks
<ogasawara> apw: ack
<jjohansen> bjf, sconklin: CVE-2012-2663 has had a clarification, and its been assigned to the userspace components of iptables, a different CVE will likely be assigned to the kernel bug. The cve has been updated in the tracker, and I have invalided all the tasks on bug 1007091. I am not sure how this is going to affect your tracker so watch for it
<ubot2`> Launchpad bug 1007091 in linux-ti-omap4 "CVE-2012-2663" [Low,Invalid] https://launchpad.net/bugs/1007091
<ubot2`> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2663)
<sconklin> jjohansen: ack
<bjf> jjohansen: i guess we won't apply that patch i submitted yesterday
<jjohansen> bjf: yeah hold off on that for a bit :)
<jjohansen> apw: hrmm, I am unaware of any changes to the semantics of set_loginuid(), and I doubt AA is involved because of the limited way in which it is being used
<apw> jjohansen, no there is indeed a strictification of that interface, that i think you may need to be aware of
<apw> jjohansen, it is turned on in our Q kernel, and makes it immutible
<jjohansen> oh!
<apw> jjohansen, and we'd like to know what to do :)  should it be on or off debian.master/config/config.common.ubuntu:CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
<jjohansen> apw: got it, I'll poke
<apw> jjohansen, cirtainly if it is on then we have issues in userspace which is all confused so we may even need a _plan_ (god forbid)
<jjohansen> apw: a first poke at this seems to be systemd driven. It breaks directly launching login utilities, so they must all go through init
<jjohansen> apw: anyways will get back to you
<apw> jjohansen, ahh ok, then i suspect we want if off by default till we think about it
<jjohansen> apw: yes turn it off, we will look at it more but I don't think this option is viable with how upstart currently works
<apw> jjohansen, ok thank
<apw> s
<jjohansen> apw: if an admin ever directly restarts a daemon it will break
<apw> jjohansen, ack
<apw> ogasawara, i am turning off CONFIG_AUDIT_LOGINUID_IMMUTABLE as per jj's initial analysis
<apw> ogasawara, will be in my next push
<ogasawara> apw: ack
<ogasawara> apw: feel free to push whenever you're ready
<apw> ogasawara, actually ... pushed now ... thats more tested highbank and that jjohansen fix
<apw> ogasawara, one sec
<apw> ogasawara, ok i've just pushed over it adding an enforcer rule for it
<ogasawara> apw: thanks
 * ogasawara lunch
<greearb> Hello!  Anyone know if there is an easy way to get the /lib/modules/*/ files that go on the initrd?  It does not seem to be the full set of modules that comes with the normal kernel...
<apw> greearb, they are chosen by the initramfs-tools scripting
<apw> that package will tell you how it decides
<greearb> thanks, looking now
<greearb> hrm, seems you have to tell it what to do....happen to know if there are instructions on how the ramdisk is initially build for Ubuntu?
<greearb> (I know how to re-spin it...but hopefully the original-build instructions show how it calls initramfs-tools)
<apw> greearb, update-initramfs know how to incant at it
<greearb> ok, I'm a bit leery of messing with that now, but will try that for my next respin attempt.
<dileks> greearb: put specific modules (not in MODULES=most) into /etc/initramfs-tools/modules and do update-initramfs 
 * cking --> EOD
<greearb> dileks, my problem is that I don't know what modules are needed or not, and I didn't want to think to hard about it.  I could probably just copy over every module that is in the upstream initrd...
<dileks> dunno where "most" is defined
<dileks> /etc/initramfs-tools/initramfs.conf says... most - Add most filesystem and all harddrive drivers.
<greearb> ok, that sounds about right
<dileks> you can inspect an upstream initrd.img
<greearb> nod
<dileks> to see what modules are already shipped
<greearb> dileks, btw, would you happen to be someone who could push casper patches upstream?
<greearb> I have some fixes that I think are worth considering..makes persistent-usb work a lot better.
<greearb> I posted stuff to ubuntu bug trackers and such, but mostly to silence.
<dileks> dunno much about casper... I checked sidux/fll and debian/debian-live but thats a while ago
<greearb> it's discouraging to have trouble even figuring out where to send patches...just putting them in the bug trackers for Ubuntu projects doesn't get much response.
<greearb> anyway, google can find it, so maybe next person to have troubles will have slightly better luck that I did :P
<dileks> whats casper - a ubuntu product?
<greearb> it's the initial boot-up logic for live-cds..and it *seems* to be headed by Ubuntu, but I'm not certain of that.
<greearb> I think Debian might use it too
<greearb> deals with 'aufs' mounts and so forth
<dileks> hmm, in ancient times for debian, maybe :-)
<greearb> debian-live is the modern equivalent?
<dileks> yeah
<greearb> Might have to try it out sometime..but I have very good notes on how to re-spin Ubuntu, so hesitant to change :)
<dileks> btw, I forgot grml-live (sort of debian-live plus fai)
<dileks> grml project*
<dileks> as the team decided to switch to debian/testing as base - and me wants sid :-)
<JanC> you could try the ubuntu-devel-discuss mailing list
<dileks> greearb: isnt ubuntu now using overlayfs for live-medium?
<greearb> I did, and CC'd the maintainer, and no response to the patches.
<greearb> it isn't in 12.04
<greearb> but supposedly it will use overlayfs for the next release
<greearb> well, maybe didn't CC them on that post..but tried elsewhere :P
<apw> greearb, we have used overlayfs in our live media for at least the last two releases
<greearb> I can promise you that aufs is used by default in 12.04
<greearb> maybe overlayfs is supported too..there is code related to it in casper, but it's not used by default.
<apw> greearb, if it is it is a bug, the default in the code _i_ added should be overlayfs
<greearb> I saw a mention on some list where at the last moment they switched back to aufs because of overlayfs bugs...
<apw> greearb, well all i can say to that is why didn't they tell me
<greearb> I'm on the outside looking in....I really have no idea of who is doing what with that stuff
<greearb> is there even a git (or svn or whatever) tree for that code somewhere?
 * apw ensures aufs is disabled in the next release so they can't do that to him again
<apw> greearb, well i just booted a stick here with the release day image, and its using overlayfs
<greearb> ummm, 12.04?
<apw> the overlayfs code is in the ubuntu kernel repo
<apw> greearb, yes 12.04 LTS indeed
<apw> which matches my expectation
<apw> you may be thinking of lxc
<greearb> no..I spent weeks on this..I'm sure I was dealing with aufs
<greearb> and I took a virgin 12.04 image as my baseline
<greearb> For git repo, I was thinking of the casper initrd scripts..that is what chooses aufs or other and sets things up.
<greearb> apw, do you happen to have an md5sum for the cdimage you used?
<greearb> well, that's interesting..it *is* using overlayfs
<greearb> I wonder what I did!
<greearb> anyone reporting problems with Radeon in the latest Ubuntu 12.04 kernel? 
<greearb> my persistent USB image is definately using aufs...I created it with the Universal USB Installer...wonder if it somehow twiddles something that makes it use aufs?
<vanhoof> ogasawara: hi
<greearb> gah, looks like this bug came to Ubuntu:  https://bugzilla.redhat.com/show_bug.cgi?id=785375
<ubot2`> greearb: Error: Could not parse XML returned by bugzilla.redhat.com: HTTP Error 404: Not Found (https://bugzilla.redhat.com/xml.cgi?id=785375)
<greearb> ok, created new usb image from virgin 12.04 cd and that doesn't use aufs either.  So, I must have done something that caused it to switch to aufs...gah!
<greearb> ahh, I bet I know..I probably didn't upgrade the modules properly, so overlayfs failed to load, and it defaults to aufs :P
#ubuntu-kernel 2012-06-02
<ogasawara> vanhoof: hey, I'll catch you monday for a quick chat
<dileks> hi
<dileks> do you have all kernel-config files at a browsable url?
<dileks> arch and flavours*
<dileks> especially I wanted to know CONFIG_ACPI_PROCFS_POWER
<dileks> [    0.720279] ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
<dileks> [    0.732691] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
<dileks> here I am on... upstream Linus tree + acpi-git-pull
<dileks> http://nopaste.snit.ch/143018
<dileks> CONFIG_ACPI_PROCFS_POWER feature removal - scheduled for v2.6.39
<dileks> didnt happen?
<dileks> grep CONFIG_ACPI_PROCFS /boot/config-3.2.0-25-generic 
<dileks> # CONFIG_ACPI_PROCFS is not set
<dileks> CONFIG_ACPI_PROCFS_POWER=y
<dileks> http://nopaste.snit.ch/143019
<dileks> config ACPI_PROCFS_POWER
<dileks> This option, together with the proc directories, will be
<dileks>  deleted in 2.6.39.
<dileks> seems not to be happened
<deffrag> Hello! I'm using a usb-ethernet adapter conected to an externally powered usb hub and a RJ45 cable is connected to the usb-ethernet adapter. When the adapter is connected directly to a USB2/3 port of the laptop, there is no networking interface detected but when its connected to the USB hub, it gets connected directly with name eth1 using driver dm9601. I would like to find why it couldn't work directly without the need of hub...
<deffrag> How to find which kernel driver is in use for connected USB hub?
<dileks> check dmesg or try lsusb
<deffrag> lsusb detects it as  - Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
<deffrag> And I cannot find device driver with lsusb -vv
<deffrag> dmesg doesn't list driver in use, its only giving usb hub detected
<mjg59> deffrag: There's no separate driver, it's part of the USB core
<deffrag> mjg59: So its driver=ehci_hcd ?
<deffrag> it's not seeing an actual usb device so it doesn't have to install any particular driver for it, if I get it right
<mjg59> deffrag: usbcore.ko, but I think we link it into the kernel
<deffrag> Ah-ok, kernel module
<deffrag> Thanks
<deffrag> Ok, then I'm not able to understand why usb-ethernet adapter isn't working directly and requires a usb-hub to get detected
#ubuntu-kernel 2012-06-03
<alkisg> Hi, I'm PXE-booting some machines and I want to make 3 lists of filenames, one for each of {64bit, pae, 32bit} clients that ubuntu supports.
<alkisg> E.g. LIST_KERNELS_64="generic-pae lowlatency-pae generic lowlatency"
<alkisg> LIST_KERNELS_PAE="generic-pae lowlatency-pae generic lowlatency"
<alkisg> LIST_KERNELS_32="generic lowlatency"
<alkisg> I.e. for each client, I want to generate a pxemenu with the kernels that it can boot with (using syslinux ifcpu64).
<alkisg> What I'm missing are the suffixes of /boot/vmlinuz-version-suffix, how can I find those? Or could someone fill the blanks for me? What other kernel suffixes exist, -server?
<alkisg> Ah there's also "-virtual", ...
<alkisg> Can linux-image-virtual be installed in 32bit (non-pae) systems?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/901410 fix commited for Precise, it means it should be in proposed no?
<ubot2`> Launchpad bug 901410 in linux "[Dell XPS L502X] Applying soft block to bluetooth hard blocks wlan" [Undecided,Fix committed]
<bjf> dupondje: "Fix committed" means the patch is in the git repo. "Fix Released" means it is at least in -proposed
#ubuntu-kernel 2013-05-27
<ppisati> moin
<smb> morning
 * henrix -> lunch
<ppisati> guys, do you have problem with R and cracking audio?
<smb> no... though admittedly my workplace still is P
<ppisati> while i'm playing a song, whenever skype/mumble/whatever emits a 'beep', i get a cracking noise coming out of my speakers
<ppisati> :(
<henrix> struggling with mumble
<henrix> smb: ^^
<diwic> ppisati, actually there was just a thread on pulseaudio-discuss labeled "skype sound effects create a buzzing noise"
<diwic> ppisati, according to thread, Arun thinks I've fixed it in a patch which is in 4.0-rc1 (3.99.1). I'm not so sure, but feel free to try ( ppa:ubuntu-audio-dev/pulse-testing )
<ppisati> diwic: pulseaudio 4.0-rc1?
<diwic> ppisati, or 3.99.*
<ppisati> diwic: weid
<ppisati> *weird
<diwic> ppisati, how come?
<ppisati> [flag@luxor ~]$ dpkg -l | grep pulseaudio
<ppisati> ii  gstreamer0.10-pulseaudio:amd64                0.10.31-3+nmu1ubuntu2                             amd64        GStreamer plugin for PulseAudio
<ppisati> ii  gstreamer1.0-pulseaudio:amd64                 1.0.6-1ubuntu1                                    amd64        GStreamer plugin for PulseAudio
<ppisati> ii  pulseaudio                                    1:3.0-0ubuntu6                                    amd64        PulseAudio sound server
<ppisati> ii  pulseaudio-module-bluetooth                   1:3.0-0ubuntu6                                    amd64        Bluetooth module for PulseAudio sound server
<ppisati> ii  pulseaudio-module-gconf                       1:3.0-0ubuntu6                                    amd64        GConf module for PulseAudio sound server
<ppisati> ii  pulseaudio-module-x11                         1:3.0-0ubuntu6                                    amd64        X11 module for PulseAudio sound server
<ppisati> ii  pulseaudio-utils                              1:3.0-0ubuntu6                                    amd64        Command line tools for the PulseAudio sound server
<diwic> ppisati, that's 3.0
<ppisati> diwic: ^
<diwic> ppisati, we're currently testing 3.99 in ppa:ubuntu-audio-dev/pulse-testing
<ppisati> diwic: ah... actually i read '1.3.0-0' instead of 3.0.0
<ppisati> diwic: ok, lemme try the ppa
<diwic> ppisati, ok, let me know how it goes.
 * diwic bbl
<ShapeShifter499> hi
<ShapeShifter499> is zcache enabled in the default 13.04 kernel?
<ShapeShifter499> I'd like to enable zcache but I'm not finding a lot of information
<ShapeShifter499> I'm guessing no one knows about zcache
<ogra_> isnt it claching with zram ?
<ogra_> we do have a bunch of images that rely on zram being available
<ogra_> (so thats definitely enabled in the kernels)
<ShapeShifter499> ogra_, after my googling, I added zcache to grub.conf and got this to happen --> http://pastebin.com/p5yF4zRm
<ShapeShifter499> ogra_, am I using this wrong?
<ogra_> looks ok i think 
<ogra_> i never used zcache ... but it doesnt seem to error 
<ShapeShifter499> I would have kept zram only but I ran across a thread that had an idea of using both zram and zcache together 
<ShapeShifter499> ogra_, that is why I'm not just sticking to using zram only
<ShapeShifter499> ogra_, http://comments.gmane.org/gmane.linux.kernel.mm/91769
<ogra_> iirc zcache requires that you have swap already 
<ShapeShifter499> I do
<ogra_> that doesnt work in many contexts where we use zram in ubuntu 
<ogra_> (if you use zram its often because you dont have a disk to use swap on)
<ShapeShifter499> I was just trying to speed up things
<ShapeShifter499> after enabling zram my system does not hang anymore
<ogra_> zram definitely helps with that .... i doubt zcache is any faster than zram
<ShapeShifter499> well if what I did with enabling zcache was right, then enabling both didn't seem to hurt or help any from  what I see so far
<ogra_> yeah
<ogra_> it wont change much 
<ogra_> (if you already use zram)
<ShapeShifter499> ogra_, let me get this straight,   zram is a faster swap replacement, zcache speeds up the use of swap
<ogra_> zram grabs parts of yout ram, compresses it and provides it as swap space
<ogra_> if it speeds up your system the actual thing you want is to buy more ram :)
<ShapeShifter499> so zram or zcache? or just stay where I have it now, both enabled
<ShapeShifter499> ?
<ogra_> i dont think it matters much 
<ShapeShifter499> mmk
<ogra_> the conclusion is that yoou dont have enough physical ram
<ShapeShifter499> yea
<ogra_> if any possible you should get more
<ShapeShifter499> can't I have a netbook
<ShapeShifter499> 1.5 is my limit
<ShapeShifter499> 1.5 gigs
<ogra_> zram and zcache will only help a little until you hit the ram barrier again
<ShapeShifter499> seems to have solved my issues
<ogra_> right, if you keep your habits .... 
<alexbligh> is the init=/bin/sh kernel command line parameter read by upstart or by the kernel? I thought it used to be the kernel. Is there a way to persuade Ubuntu /not/ to run upstart first (I want to run a pivot_root an a debootstrapped initramfs)
<ogra_> people tend to open more borwser tabs once it works better 
<ogra_> and at some point you are back at the point where it gets slow
<ShapeShifter499> ogra_, I think I'll be upgrading to a i3 or better laptop by this fall for college
<ogra_> alexbligh, it works fine here 
<ShapeShifter499> ogra_, well thank you for the info and help, google wasn't that much of help
<alexbligh> ogra_, even if you aren't using an autogenerated initramfs? I mean in the normal case, it must be the initramfs which runs the pivot root then /sbin/init, yes?
<alexbligh> ie it must be userspace that looks at it
<ogra_> as long as /bin/sh exists both, the kernel as well as the initramfs respect init=
<ogra_> (teh kernel only comes into play without initrd indeed, but it uses the parameter)
<alexbligh> Aaah, well I do have an initrd - it contains my full root filing system. Is the kernel ignoring init= because it thinks it's up to my initrd to do that?
<ogra_> ti shouldnt
<alexbligh> I can cat /proc/cmdline and init=/bin/sh appears there
<ogra_> it should just hand over the parameter to your userspace
<alexbligh> but it runs upstart
<ogra_> indeed that requires that something in your userspace handles it
<alexbligh> it does hand the parameter to userspace. I'm wondering if the kernel ALWAYS runs /sbin/init (whatever init= says) if initrd= is specified.
<ogra_> it might 
<ogra_> ubuntus initramfs definitely has a handler for it 
<alexbligh> Yeah I am using debootstrap to make an initramfs of my own
<ogra_> i know if you boot without initrd the kernel hands it over properly 
<alexbligh> I want it to run a different program
<alexbligh> I think I need go read the source
<ogra_> that might help :)
<alexbligh> Aha, rdinit=
#ubuntu-kernel 2013-05-28
 * smb hails cking 
 * cking requires more coffee
 * apw yawns
<ppisati_> diwic: so, the pulseaudio in the ppa:audio-dev fixed the cracking noise i head wrt skype
<ppisati_> diwic: but i had to rip it off this morning cause after a bit
<ppisati_> diwic: i got a loud 'beeeeepp' coming out of my speakers
<ppisati_> diwic: and the noise didn't stop until some other audio samples was played
<diwic> ppisati_, hmm, that sounds strange
 * ppisati_ prepares some more coffee
<ppisati_> diwic: if you want i can reinstall everything
<diwic> ppisati_, nah, but I wonder what that beeeepp came from, really
<ppisati_> diwic: and do some more debugging for you
<ppisati_> diwic: is there a way i can find it out?
<diwic> ppisati_, hard to tell without a verbose log, and examining the state when it's present
<ppisati_> diwic: pulseaudio log?
<diwic> ppisati_, https://wiki.ubuntu.com/PulseAudio/Log
<diwic> ppisati_, but you need to reproduce the beep while the logging is active
<ppisati_> diwic: yep, no prob
<ppisati_> diwic: it happened two times in a row
<diwic> ppisati_, do you know how to reproduce it?
<ppisati_> diwic: login, play a couple of songs on you tune and that's it :)
<ppisati_> *youtube
<diwic> ppisati_, ok, while the beep is present also take a "pacmd list"
<ppisati_> diwic: cool, will do
<smb> infinity, Am I right in assuming you have not looked at any of the Xen packages, yet?
 * apw bets on good old flash for pp's issue
<alexbligh1> Is there a reason why module-init-tools is built with --disable-zlib? I've tried rebuilding with --enable-zlib, it adds no library dependencies, and allows for modules to be compressed with gzip. The saving of even one module's compression will outweigh the extra size of a static zlib I'd have thought. And compressing all the modules in Ubuntu running from RAM saves 100MB (150MB down to 50MB). I think cjwatson added the --disable-zl
<alexbligh1> ib stuff (or just did the packaging). Any reason not to change this? (will supply patches)
<cjwatson> module-init-tools is removed as of raring
<cjwatson> And I have made one change to module-init-tools ever, according to the changelog, and it wasn't that
<alexbligh1> cjwatson, ah I'm looking at Precise. Where do they live now?
<cjwatson> For current releases, please look at kmod, not module-init-tools; for stable releases, I suspect such a change wouldn't be appropriate
<alexbligh1> cjwatson, I have no idea where I got your name from :-)
<alexbligh1> would it be appropriate to use zlib in kmod?
<alexbligh1> For Precise I'll just build a custom package. I was just checking there was nothing deathly about module compression.
<cjwatson> No idea
<cjwatson> Would probably need benchmarking to make sure it doesn't regress boot performance for some reason (yes, intuitively the I/O gain should outweigh that, but it still needs benchmarking)
<alexbligh1> thanks
 * ppisati goes out for a bit, brb
 * henrix -> back in 15
 * rtg pushes v3.10-rc3 rebase to Saucy unstable
<ogra_> vs Saucy stable ?
<rtg> ogra_, vs Saucy master-next (which is likely to be much more stable then -rc3)
<ogra_> ah :)
<rtg> ogra_, I'm gonna do some testing on -rc3 today. if it looks OK, then perhaps I'll make it the new stable.
<rtg> or master-next I mean
<smb> Hm... seems today's netboot saucy images go straight into a panic (at least on Xen)
<rtg> smb, I don't think the kernel has changed in awhile.
<rtg> yeah, uploaded on the 20th
<smb> rtg, I thought that did work last week but who know. Dumping now to see the more useful parts of dmesg... At least with today I seem to run into a bit of lvm trouble, too. Only some LVs of my 30 or so get their symlinks created in /dev/<vgname> or /dev/mapper/...
<rtg> smb, wouldn't that be a udev problem ?
<smb> rtg, Right, those are likely unrelated. Just an indication that it might just be one of those days
<bjf> apw, i think bug 1098378 should be on your radar
<ubot2> Launchpad bug 1098378 in linux (Ubuntu Raring) "chroot+overlayfs seems to cause umount mis-behavior" [High,Confirmed] https://launchpad.net/bugs/1098378
<smb> Oh, maybe the failure inside the guest actually is related to udev, too... "cannot open /dev/null" (twice) and "mounting none on /dev/pts failed"...
<apw> bjf, ta
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<bjf> apw, you are most welcome
<rtg> apw, rtg@gomeisa:~/r/kern$ git clone git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
<rtg> Cloning into 'ubuntu-raring'...
<rtg> remote: error: Could not read bce134d73d6d2bc23aeea1d32e559f11e61b8958
<rtg> remote: fatal: bad tree object bce134d73d6d2bc23aeea1d32e559f11e61b8958
<rtg> remote: aborting due to possible repository corruption on the remote side.
<rtg> fatal: early EOF
<rtg> fatal: index-pack failed
<apw> rtg, eep
<rtg> apw, yeah. I think my local repo is up to date.
<smb> have we recently moved some other repo to archive?
<smb> (iow could it be that weird --reference badness again)
<apw> smb, no i think this is actually because we started using linux.git on there as a rewind tree, a nono with this setup
<apw> rtg, i think i have it repaired, you might want to try recloning, i am letting fsck finish again, if it is clean then i will repack the repo without an alternative
<rtg> apw, ack
<apw> bjf, sconklin, henrix, your raring master repo is unhappy, i am working on it
<sconklin> apw: ack
<bjf> ack
<smb> apw, Hm, and I thought Linus repo as alternative would always be safe
<apw> smb, it would be _if_ we weren't putting stable in it, which has 'pending' branches which are rebased; bad
<smb> apw, eew
<apw> smb, yeah, and that expalins the objects which have gone, they are blobs and trees which would have been common on patches in another branch
<smb> Sounds like we should give up --reference as long as git allows us
<bjf> apw, i'm totaly confused why we would be using the "stable" tree (linux.git) as a reference to _any_ of our repos
<bjf> apw, that just seems so wrong
<rtg> bjf, I don't think it started out being the stable tree
<bjf> rtg, ack
<rtg> hmm, 'Failed to execute /init' is a real problem. v3.10-rc3 is kind of a fail.
<rtg> apw, is your git fsync done ?
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 10 minutes
<jsalisbury> ##
<infinity> smb: You might be right.
<smb> infinity, Looking at the changelog, Daviey thinks I need to get TechBoarded anyway
<apw> rtg, bjf,  sconklin, ubuntu-raring looks to be in good shape now; i have separated it from the linux.git repo now so we should be safe going forward
<apw> rtg, i am just checking saucy which has the same linkage
<sconklin> ack, thanks
<rtg> apw, yep, cloned it a bit ago with no problems
<bjf> apw, ack, thanks
<apw> smb, did i see that the issue with devtmpfs was a systemd/udevd issue?
<smb> apw, for the installer part yes
<rtg> apw, ok to push saucy master-next ?
<smb> some script from debian rather using tmpfs not devtmpfs
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 4th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<sconklin> apw:  do I need to clone raring fresh?
 * rtg -> lunch
<apw> sconklin, nope, it should be fine if you have a copy
<sconklin> ok, too late :-)
<apw> sconklin, it was the central copy which was missing an object or two; now restored
 * rtg -> EOD
#ubuntu-kernel 2013-05-29
 * ppisati -> reboot
<diwic> ppisati, hi, how did the pulseaudio beep go?
<ppisati> diwic: using puleaudio from ppa:pulseaudio-testing i couldn't reproduce it anymore
<ppisati> diwic: any plans to backport it to R?
<diwic> ppisati, but I thought it was with 3.99 you got the beep?
<ppisati> diwic: i got two different problems
<ppisati> diwic: one was with the stock pulseaudio + e.g. skype, and the ppa stuf xied it
<ppisati> *fixed it
<ppisati> diwic: but then, two times, it happened that while i was playing some music
<ppisati> diwic: the audio got stuck and i heard this noisy 'beeeeeeeeeeep'
<ppisati> diwic: but i can't reproduce it anymore
<diwic> ppisati, okay
<diwic> ppisati, there are no plans to backport 3.99 into raring. I could possibly try to backport the actual minreq patch once we have 3.99/4.0 in saucy
<diwic> ppisati, but then if 3.99 causes beeeeeeeeep, I want to fix that before releasing it into saucy
<ppisati> diwic: :)
<ppisati> diwic: i think you better release it, and let some more people try it out
<ppisati> diwic: it happened to me two times in a row
<ppisati> diwic: and then, after a day of usage, i didn't it anymore
<ppisati> *hit it
<diwic> ppisati, hmm, was there a reboot in between?
<ppisati> diwic: a lot
<diwic> ppisati, maybe the system was in some inconsistent state after installation but before reboot
<ppisati> diwic: could be
<ppisati> diwic: but the second time, it was after a reboot
<diwic> ppisati, ah ok, then we rule that out
<apw> ppisati, try reboots with and without power, i have seen inconsistent behaviour with those
<apw> at times
 * henrix -> lunch
<ppisati> lp 1173073
<ubot2> Launchpad bug 1173073 in skype (Ubuntu) "Broken sounds in Skype" [Undecided,Confirmed] https://launchpad.net/bugs/1173073
<ppisati> diwic: FYI ^
<diwic> ppisati, six users affected
<diwic> ppisati, maybe worth the effort to try to backport to raring then
<ppisati> diwic: i think there are more than 6 skype users running ubuntu :)
<diwic> ppisati, I wonder if it really is the minreq patch that fixes it...
<ppisati> diwic: another variable is that we got a new version of skype lately
<diwic> ppisati, ok
<diwic> ppisati, do you think I should package 3.0 plus the minreq patch up and ask people to test?
<ppisati> diwic: let's first see which version of skype they were running
<ppisati> diwic: if it's the latest, you can try packaging the fix
<diwic> ppisati, is the current version 4.2 ?
<ppisati> diwic: yes
<diwic> ppisati, that's what's reported upstream
<diwic> http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-May/017414.html
<slangasek> smb: hi, around?
<smb> slangasek, somewhat. whats up?
<slangasek> smb: I have a very serious problem with kernel caches here which is just murdering my productivity; I've filed a bug but haven't made any headway on getting to the bottom of it.  I was wondering if you could help
<smb> slangasek, Its rather the end of a day here and I would be off to a long weekend. But why don't you post the bug number here? Maybe someone has ideas
<slangasek> smb: bug #1152736
<ubot2> Launchpad bug 1152736 in linux (Ubuntu) "system swapping itself to death in raring for no good reason" [High,Confirmed] https://launchpad.net/bugs/1152736
<slangasek> this first started affecting me in raring /that I'm aware of/; but I'm not sure if it was actually a regression in the raring kernel or if raring userspace was just the first one that started hitting the memory limit for me
<smb> bjf, sconklin ^ at least I guess you wanna know about this
<bjf> smb, i see it :-(
<sconklin> ack
<slangasek> currently updating the bug with comments based on my latest explorations
<slangasek> can anyone tell me what the expected behavior of /proc/sys/vm/drop_caches is?
<slangasek> bjf, sconklin: ok, added a note there
<bjf> slangasek, i've read your latest comment. i have no good suggestions to make at this time.
<slangasek> bjf, sconklin: FYI this issue is so bad in saucy that I had to SAK my desktop several times yesterday, and it's become virtually impossible for me to run a Google Hangout on this machine.  It could be getting worse due to regressions in the desktop footprint (e.g., firefox), but it's definitely not because of any changes in my usage patterns.  As I said above, this is destroying my productivity, so I would really appreciate any support
<bjf> slangasek, i hear you
<smb> I don't know the dm-crypt target internals to be able to say whether it does eat up those amounts of mem. Some targets (if they have to extend or rewrite io) can create an additional cache pool with some pre-allocated minimum
<slangasek> smb: right... except the size of the cache changes depending on what apps are running, so it doesn't seem to be a fixed pool
<smb> It would not be, just a minimum lower reserve 
 * slangasek nods
<slangasek> so the 'drop_cache' bit looks very suspicious to me... I would expect this to reset to 0 once the caches had been dropped
<slangasek> and the fact that it never does smells funny
<smb> slangasek, So that does not say anything but dm-crypt does create some mempools 
<slangasek> I guess my next step is to try downgrading to precise/quantal kernels to see if it's reproducible
<smb> Or manually install previous raring kernels (before you think it regressed)
<smb> If it is something that slipped through stable it may affect current older releases too...
<smb> slangasek, Also maybe /proc/slabinfo or /proc/meminfo may give some hints
<slangasek> I think it regressed when I first upgraded to raring, fwiw
<slangasek> I'll attach /proc/meminfo - nothing looked suspicious to me, but maybe one of you has better eyes
<apw> i am not sure i would expect drop_caches to ever be able to make things go to 0
<smb> slangasek, slabinfo might be more useful (but both dont hurt)
<slangasek> smb: attached both
<smb> slangasek, ta
<slangasek> apw: you wouldn't expect 'cat /proc/sys/vm/drop_caches' to at some point return to 0 after it's decided it's done all it can?
 * apw wonders what slangasek is doing different as he has not seen raring 'swap itself to death'
<apw> slangasek, nope
<slangasek> ok
<slangasek> so what does it mean when it sticks at 3 - that it will forever after try and fail to drop all the caches? :)
<apw> slangasek, hmm, i may be miss understanding your question
<slangasek> apw: ok - I'm not saying I would expect the cache to drop to 0 after drop_caches, but that I would expect echo 3 > drop_caches to be a one-time instruction to the kernel to dump everything it can... after which I would expect things to reset to 0
<apw> slangasek, i know why don't i look :)
<apw> slangasek, i would it expect to dump things yes, i am supprised you can read it at all
<slangasek> whereas what I'm seeing is that whatever value I echo there, persists... and it rejects an 'echo 0'
<apw> slangasek, i see the same semantics indeed
<slangasek> apw: I'm doing a *lot* of things different, but I've ruled out a lot of them as the cause. 1) using nfs mounts with krb5 authentication, 2) using LVM (for main filesystem, and also with snapshots), 3) using LUKS encryption for / and /home, 4) pretending that 4GB is enough RAM for a 64-bit desktop? :)
<apw> slangasek, the behaviour is triggered on 'write' so what the value shows at is not particularly relevant
<slangasek> NFS - I see the problem even if I unmount all NFS and shut down all the nfs-common services.  LVM snapshots - I see the problem even when no snapshots are active, or have been created since boot. LVM - lots of other people using LVM.
<slangasek> apw: ok.
<apw> slangasek, and yes as it is really a sysctl, it will only take 1 to 3 as a value, and so once you use it it is stuck at whatever value you used
<slangasek> ok
<apw> slangasek, but the kernel action is not taken on the value of the sysctl, but on the value at the time you write to it
<apw> (which is vile and confusing, but at least safe)
<apw> so you have 'swapping like a pig' as your symptom, and trigger is unknown
<apw> and this is raring, i have a VM machine which runs raring with lots of vms and lvm things etc
<apw> and don't see this, and a number of other raring boxes, nothing similar
<apw> hmm
<smb> slangasek, Hmm, at least in the attached meminfo Swaptotal and Swapfree are the same. Which somewhat is confusing...
<slangasek> smb: it's a fresh boot, a) nothing's been swapped out yet because I haven't started to get memory pressure, b) I may have swappiness set to 0 right now :P
<slangasek> apw: not just "swapping like a pig" - "failing to release 1.5GB of cache for a more appropriate use"
<smb> slangasek, Well, when looking for a memory hog, the output of those _when_ it is swapping to death might be more useful. :-)
 * rtg -> lunch
<slangasek> smb: ok
<apw> slangasek, but as your machine has 200MB of free ram, it can't be swapping anyhow, it doesn't make sense
<slangasek> apw: it's not /currently/ swapping...
<slangasek> apw: and when it does start to swap, it becomes difficult to capture useful snapshots of the state :P
<apw> slangasek, yep so i would say, take the latest Q kernel and slam that on and see if that is any better
<apw> as you are in a big hole right now
<slangasek> yep
 * apw doesn't expect drop_caches to make Cached go to 0, on my machine it dropped some 300MB though
<apw> slangasek, drop_caches is just iterating the filesystem caches and dropping things not in actual use
<slangasek> right
<apw> slangasek, and putting pressure on the slab caches to try and make them shring, no guarentee that will do anything
<slangasek> so on my machine, it will drop *some* cache, but it still bottoms out at 1.4GB in the pathological case
<apw> if you are using your pages cause they are mapped, they are still mapped and drop_caches won't drop them
<apw> so .. what has a big rss, which is holding them in
<slangasek> hmmm, ok
<apw> its not a 'remove pages i could not be using' option, it is 'remove pages i am not using'
<slangasek> I guess I should check that too - I checked mappings for the LUKS-backed filesystems, but not for all of them
<apw> which is why swapping might help as it were as it moves things to being 'not used'
<apw> now what is the rsstop thing called
<slangasek> smem?
<slangasek> # smem -s rss -r | head -n2
<slangasek>   PID User     Command                         Swap      USS      PSS      RSS 
<slangasek>  4320 vorlon   /usr/lib/firefox/firefox --        0   702624   709561   729028 
<slangasek> not really surprising
<slangasek> except for the bit where that's a grotesque footprint
<slangasek> (why are icon theme caches so big?)
<apw> is that the best part of a 1G ?
<apw> 24050 apw      chromium-browser               30988    97560   100071   114064 
<slangasek> ayup
<apw> even if i add all the chromium's together it is more like 200M
<apw> with 20 odd tabs
<cking> browsing ain't cheap
<nsfx> Ahoy, I'm attempting to apply a patch to and re-install the kernel. I've followed https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel but I only end up with 1 deb instead of 3 as stated in the instructions
<nsfx> Are there more up to date instructions somewhere?
<apw> nsfx, i would expect those to be pretty close, which .deb did you end up with
<nsfx> apw: I ended up with linux-headers-3.8.0-22_3.8.0-22.33_all.deb
<nsfx> The double version scares me a bit, aheh
<apw> that would be binary-headers, binary-generic did you include that ?
<apw> the double version is deliberate
<apw> so you can install more than one kernel
<nsfx> apw: Yeah I ran: fakeroot debian/rules clean binary-headers binary-generic
<nsfx> Actually the last step of that failed trying to stat a directory
<apw> nsfx, then you probabally need to capture the output and pastebin it
<apw> as it clearly failed
<nsfx> apw: https://gist.github.com/adsr/7071d8f94e444525c926
<nsfx> I'd named the kernel differently in menuconfig
<nsfx> The directory it tried to stat did not include the label I appended
<apw> the kernel packaging will not cope with that
<nsfx> Ack, ok
<apw> add something to debian.master/changelog, to the last version there
<apw> like ~mine1
<nsfx> apw: Cool, something like https://gist.github.com/adsr/ad558a541e9dbd29b0eb then ?
<nsfx> Will that make it to the package name / allow me to differentiate between kernels in boot after installing?
<apw> nsfx, not really no, that only shows up to the ABI number
<nsfx> apw: Ah ok. If I make no modifications at all (besides applying the kernel patch) will it replace the current kernel or install alongside?
<apw> it will replace the kernel of the same ABI number, whether you add ~foo or not
<nsfx> Adding ~foo in changelog will change the ABI number? Sorry if I'm being thick :)
<apw> no it will not
<apw> there is no easy way to do that, and maintain any semblance of 'being based on' an ubuntu version
<apw> we don't have a good derivative story there
<nsfx> Maybe I should just wait for a bleeding edge release
<nsfx> The patch is from 2010 actually and applies to quirks-table in ALSA for getting a USB MIDI device to work
<nsfx> apw: Do you suggest filing a bug on launchpad?
<nsfx> Not sure if that is the appropriate channel
 * rtg -> EOD
#ubuntu-kernel 2013-05-30
<apw> nsfx, i would file a bug indeed, maybe this can be upstreamed so it goes away forever
 * apw hates debugging filesystems, it is so hard to know what is going to do what
<apw> there is so much reference counted poo in here
<ohsix> cking: on an oooold blog post you were wondering about other uses for the fibmap ioctl. i just had another drive failure and i use debugfs to see which files were damaged, it directly looks at fs structures, but you could check every file on the disk with fibmap and try and find it too
<ohsix> cking: old = circa 2009
<ohsix> found the post when i was looking to see if the vfs or ext4 had an ioctl or method to do it directly, from the bad block to an inode
<cking> ohsix, i'm glad it was helpful, these ioctl's are not well documented
<ohsix> from the vfs .txt in <kernel>/Documentation it says it's used internally to find out which blocks are used in a file if it's going to be used for swap, since the swapper accesses the disk directly
<ohsix> before there were special vfs calls for it, it was used to read the sparse areas of a file in xfs
<ohsix> and that's about all i know about it
 * ppisati -> out for lunch
 * cking has to confess he's forgotten most of the details, the blog is an aide-mÃ©moire 
<rtg> apw, ogasawara: I uploaded grouper yesterday. turned out to be gcc as well as some config options (most likely LOCKD). Gonna sync with distro config today.
 * henrix -> lunch
<apw> rtg, great stuff, so 4.7 or 4.6 needed
<rtg> apw, 4.6, I didn't try 4.7 since I ran out of interest
<apw> yep
 * apw goes back to debugging his overlayfs loop lockup
<rtg> apw, now I have to figure out how to enable lttng again and clean up compile issues
<rtg> biab
<maxb> I seem to be having a new problem since upgrading to raring - every so often my mouse pointer becomes corrupt / disappears. The GPU is radeon, and this is a dual screen setup. Is there anything specific I should bear in mind in filing a useful bug?
<maxb> https://bugs.freedesktop.org/show_bug.cgi?id=55819 is the sort of thing I mean
<ubot2> Freedesktop bug 55819 in DRM/Radeon "Mouse cursor corruption when moving between monitors" [Normal,New]
<rsalveti> compilers fun
<rsalveti> amazing that it only works with 4.6
<rtg> rsalveti, it stands to reason since we encountered the same issu on all the other Nexus kernels.
<apw> rsalveti, it is most  liklely a bug in the kernel asm which is exposed by later compilers doing things right
<rsalveti> apw: right
<Guest14125> hummm I see some familiar faces here, hi dannf and lamont, this is eddie quinteros
<dannf> hey Guest14125! good to see you - you might wanna /nick eddie or similar :)
<lamont> hi eddie
<eddieq> eddie was taken
<eddieq> hi guys, I'm sorry to bother you, but I have been looking all over the Ubuntu pages and can not find answers to 2 problems I have with crash, they are simple can you guys help?
<dannf> eddieq: possible, but most likely not - though feel free to ask
<eddieq> ok I have 10.04 installed kernel 3.5.0-23-generic and i forced a vmcore
<eddieq> go the dbg package for it
<eddieq> running crash vmlinux-3.5.0-23-generic /var/crash/vmcore /boot/System.map-3.5.0-23-generic gives me crash: cannot resolve: "xtime"
<eddieq> there is a BZ https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1075745 but it says it was fixed
<ubot2> Ubuntu bug 1075745 in crash (Ubuntu) "crash fails cannot resolve xtime" [Medium,Fix released]
<eddieq> Now, I run the same command on a RH system and it runs fine, but bt -l does not gives me line numbers
<zequence> apw: so, did you come up with a solution on how I could take over dev release as well?
<zequence> apw: since updates don't need to be as frequent, perhaps it is not as big of a project?
<eddieq> I am at the latest crash release and still get the xtime error
<rtg> caribou, ^^ you've used crashdump extensively IIRC
<eddieq> humm I know caribou too, hello
<apw> zequence, thanks for the reminder, i'll put that in large on my todo
<eddieq> ls
 * rtg -> lunch
<BenC> rtg: I'm going to be working on linux-ppc for saucy today and tomorrow
<BenC> rtg: any caveats I should be aware of?
<rtg> BenC, 3.9 or 3.10 ? I've got an unstable branch for 3.10. we'll likely have time to adopt 3.11 before release.
<BenC> rtg: Where do you suggest I start? 3.10 branch?
<BenC> If 3.10 holds me off from uploading, I'll start with 3.9
<rtg> BenC, yeah, its in pretty good shape (though it won't boot on my laptop)
<BenC> Ok, I'll work from there and see what I'm in for
<cking> rtg, i'm getting "Error: Unable to list kernel events" with the lttng enabled grouper kernel when I invoke "lttng list -k"
<rtg> cking, ok, I'll have a look tomorrow. 
<cking> rtg, I'll poke around with it a bit more and see what's up
<rtg> cking, its late. it can wait until your tomorrow :)
<cking> yup, that's true 
<cking> also I just get a blank screen, not sure if that's intended :-(
<rtg> cking, using the raring daily ?
<cking> yep, daily image + the saucy kernel, I did roll in some updates, so who knows what's causing it
<rtg> hmm
<cking> indeed hmm, most curious
<cking> rtg, which version of lttng was added into grouper?
<rtg> cking, should be tip of git://git.lttng.org/lttng-modules.git (or close to it)
<cking> ta
<cking> rtg, my fail, I installed the zImage manually but didn't install the kernel image .deb which has the lttng modules - doh, anyhow, got it to work: http://paste.ubuntu.com/5717758/
<rtg> cking, oh cool. I didn't think about it being a module
<cking> rtg, do you have a Nexus 7 then?
<rtg> cking, yep
<rtg> cking, but I've only installed the zimage
<cking> rtg, ok, well, can you install the kernel .debs and sanity check that they look fine - I had to pull in wireless-crda, not sure if that makes sense to me
<rtg> cking, ah, unnecessary package dep. I'll fix that.
<cking> rtg, ok, cool, maybe worth you looking at what else dpkg says, I lost my scrollback so I can't recall all the output it spewed out
<rtg> cking, no problem. its on my todo list for tomorrow.
<cking> cool, me -> EOD
<rtg> I'm close to EOD myself
 * rtg -> EOD
<houkouonchi-work> anyone know why installing a linux-image package would not update the symlinks?  http://pastebin.com/raw.php?i=cyiaYFbF
<houkouonchi-work> damn its dead in here =(
#ubuntu-kernel 2013-05-31
<diwic> uhm, after today's update of 12.04, I'm left with a broken apt
<diwic> ah, no space left on devices
 * diwic goes to clean up old kernels
 * apw watched X lock up .. sigh
<caribou> eddieq: crash versions in Lucid (and even Precise) archives are *notoriously* old (5.1.6 for precise)
<caribou> eddieq: you can use the version in the quantal archives (6.1.0) which works correctly with 3.5.0-23-generic; I just tested it on Precise
 * ppisati -> out for lunch
<rtg> apw, ok, I think I'm about done normalizing grouper configs with mainline. kind of tedious. one last full build just to be sure.
<apw> rtg, nice ... 
<rtg> apw, just pushed a few seconds ago
<apw> great
<rtg> apw, I'll start having a look at the rest to make sure we're somewhat normalized
<apw> rtg, great indeed
<apw> rtg, i applied the iscsi fix to saucy master-next so it doesn't get forgotten
<rtg> apw, that wasn't upstream ?
<apw> rtg, not yet, cordinated release jobbie, so linus' won't have got it till we released
<rtg> damned embargoed patches
<rtg> apw, I suppose that should be SAUCE until we get it from upstream
<apw> rtg, doh, they all should have been, i copied it over without a thought
<apw> rtg, i'll slam it right for saucy at least
<rtg> apw, I don't care about the others, but I'll be rebasing saucy one of these days
<rtg> apw, go for it
<apw> rtg, done
<rtg> ppisati, need to reboot tangerine for kernel update
<rtg> jsalisbury, cking: bouncing gomeisa for kernel update
<cking> ack
<rtg> cking, pushed CONFIG_KEYS=y for grouper which turned on a bunch of other stuff, including ecryptfs
<cking> rtg, thanks
 * apw wanders out into the garden ...
 * rtg -> lunch
 * henrix -> EOD
 * cking -> EOW
 * rtg -> EOW
<rsalveti> apw: http://blog.accuvantlabs.com/blog/jdryan/building-nexus-4-uart-debug-cable
<sforshee> rsalveti: that's awesome. I saw the code for that in the kernel but didn't bother trying to rig something up.
<rsalveti> sforshee: yeah!
<rsalveti> might make our life easier later on
#ubuntu-kernel 2013-06-01
<apw> rsalveti, heh nice
<wmp> hello, i want make package with my own kernel, but my server need firmware to ethernet card. In generic all works good, i have /lib/firmware/bnx2/bnx2-mips-09-6.2.1a.fw
<wmp> what i should do in my kernel to have this file?
<infinity> BenC: You have a new SRU tracking bug: https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1186432
<ubot2> Ubuntu bug 1186432 in Kernel SRU Workflow "linux-ppc: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> New SRU cadence for you, BTW.  Poke me when you have uploads to sponsor.
<alexbligh> Is there an obvious way to PREVENT the kernel packages running update-initramfs when installed (I'm not using one, and its creating issues inside a fakechroot due to multiarch bizarreness)
<BenC> infinity: thanks
#ubuntu-kernel 2013-06-02
<desty> hi, does anyone know why using the mmiotrace logger would prevent my keyboard from working and cause the hard disk to throw DMA read exceptions?
<desty> as soon as I echo mmiotrace to /sys/kernel/debug/tracing/current_tracer, normal I/O goes out the window and I eventually have to hard-poweroff
<desty> ...and apparently it's practically impossible to debug nouveau without mmiotrace
<ajnr> Hi I am facing problem while shutdown my ubuntu 12.04 system, it just hang. and while booting also it took so much time , plz help me out 
<infinity> zequence: I realised I completely failed to nick highlight you when I pointed out you had a new SRU cadence to rebase to.  Oops.  Here's your highlight. :)
<zequence> infinity: That's alright. I'm notified by mail, and I have an alert on anything with "lowlatency", so I always get them through #ubuntu-bugs-announce
<zequence> I'll prepare the packages before Monday
<zequence> I usually try to prepare the packages within a couple of days after the bug is reported, but I've been kind of not including weekends into that period
<infinity> zequence: Heh, s'all good.  There's an incoming respin of 3.2/precise, BTW, so just Q and R for now.
<zequence> infinity: Ah, thanks for the heads up
<infinity> Hrm, where did my scaling governors go in the latest saucy kernel?
<infinity> I don't have ondemand anymore, and my CPU is pegged at full speed.
<infinity> apw: ^^?
<shadeslayer> I'm curious, how do mainline builds happen?
<shadeslayer> and how can I send one to a PPA
<zequence> infinity: uploaded -lowlatency 3.5 and 3.8 to the ppa ppa:ubuntustudio-kernel/linux-lowlatency-sru
<zequence> infinity: I had the idea of why not add a new tag that notifies packages have been uploaded to PPA. Me changing <version to be filled> is an indication of that though
<zequence> ah, my connection sucks today
<zequence> 15:35 < zequence> infinity: uploaded -lowlatency 3.5 and 3.8 to the ppa ppa:ubuntustudio-kernel/linux-lowlatency-sru
<shadeslayer> is there a PPA where 3.9 is available for Raring?
<shadeslayer> or just the mainline PPA?
<shadeslayer> which is not really a PPA
<zequence> infinity: Seems like 3.8 had a build error
<apw> shadeslayer, they are triggered by a cronjob which is looking at various tips and tags; they are not in a PPA because we want them for testing and therefore we want all of them at the same time
<apw> infinity, .... hmmm sounds bad ... will check my box in the morning
<Sarvatt> that'd be http://linux-kernel.2935.n7.nabble.com/CONFIG-X86-INTEL-PSTATE-disables-CPU-frequency-transition-stats-many-governors-and-other-standard-fes-td641074.html and https://bugzilla.kernel.org/show_bug.cgi?id=57141
<ubot2> bugzilla.kernel.org bug 57141 in Power-Processor "CONFIG_X86_INTEL_PSTATE disables CPU frequency transition stats and many governors" [High,Resolved: invalid]
<Sarvatt> aka http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=93f0822dff5dae2f0a2645f16300c14af41ca777 , ivybridge just got supported in 3.10
<infinity> Hrm.  I'm not sure it's achieving its desired goal.  My fans seem to be on a lot more now.
<infinity> But I'll experiment.
<Sarvatt> could be a bug not fixed in 3.9 yet, https://bugzilla.redhat.com/show_bug.cgi?id=923942 seems to only be fixed in 3.10
<ubot2> bugzilla.redhat.com bug 923942 in kernel "Thinkpad T420s overheating and showing wrong [or overclocked?] freq in /proc/cpuinfo with kernel-3.9.0-0.rc3.git0.5.fc20.x86_64" [Unspecified,Closed: rawhide]
<Sarvatt> ah nope bad cgit search :P
<Sarvatt> https://plus.google.com/117091380454742934025/posts/2vEekAsG2QT was a good thread on it
<Sarvatt> i wonder if they actually expect you to use https://01.org/linux-thermal-daemon with it noe
<Sarvatt> now rather
<Sarvatt> really looks like they are tied closely together and CONFIG_X86_INTEL_PSTATE needs to be disabled until thats all working (or even packaged)
#ubuntu-kernel 2014-05-27
<rsalveti> apw: mind checking bug 1318070?
<rsalveti> apw: might be qemu related as well, and doesn't happen all the time
<apw> rsalveti, sure
#ubuntu-kernel 2014-05-28
<BinnyHill> How is it that a kernel module that was not there priorly just appears on a system?
<infinity> zequence_: You around?
<infinity> zequence_: Will pay big money for you to quickly smoketest your kernels from the last cycle.
<slangasek> apw: bug #1324028
<bullgard4> Is there a difference between Â»kernel configuration optionÂ« and Â»kernel command line optionÂ«?
<apw> bullgard4, yes ... "kernel configuration option" == CONFIG_FOO type options which are options we set when we build a kernel from source; a kernel command line option is something you supply to the kernel on boot and can change on each boot
<bullgard4> apw: Ah! Thank you very much for explaining and your help.
<lamont> every 2 seconds, I get this on my trusty box:
<lamont> May 28 10:33:35 kailan kernel: [503122.916681] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPC_.SMBR] (Node ffff88007c352f28), AE_AML_INFINITE_LOOP (20131115/psparse-536)
<lamont> May 28 10:33:35 kailan kernel: [503122.916712] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPC_.INIT] (Node ffff88007c352f00), AE_AML_INFINITE_LOOP (20131115/psparse-536)
<lamont> May 28 10:33:35 kailan kernel: [503122.916730] ACPI Error: Method parse/execution failed [\_GPE._L00] (Node ffff88007c34c2d0), AE_AML_INFINITE_LOOP (20131115/psparse-536)
<lamont> May 28 10:33:35 kailan kernel: [503122.916750] ACPI Exception: AE_AML_INFINITE_LOOP, while evaluating GPE method [_L00] (20131115/evgpe-580)
<lamont> thoughts on how to make it shut up?
<mjg59> Are you passing any strange kernel options?
<lamont> stock boot, atom 330 on an Intel D945GCLF2D MB
<lamont> BOOT_IMAGE=/vmlinuz-3.13.0-24-generic root=/dev/mapper/KAILAN-root ro BOOTIF=01-00-1c-c0-c9-33-a2 quiet splash nomdmonddf nomdmonisw vt.handoff=7
<mjg59> Ok
<mjg59> I have a vague recollection of this
<mjg59> With the conclusion being "This firmware is broken"
<TJ-> lamont: see workaround (custom DSDT) https://communities.intel.com/thread/11742?start=0&tstart=0
<lamont> TJ ta
<lamont> mjg59: somehow, this does not surprise me at all
<lamont> the good news is that I'll get incredibly good compression on syslog
<lamont> :/
<lamont> and lunch.  bbl
#ubuntu-kernel 2014-05-29
<awe_> rtg, can we re-open https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1267570
<ubot5> Ubuntu bug 1267570 in linux-mako (Ubuntu) "Mako not always entering suspend (msm_hsic_host wakelock)" [High,Won't fix]
<cyphermox> anyone here currently has an armhf laptop would like to help testing something for bluetooth? I get these weird issues only on armhf, trying to get the hsp profile to work
<brendand> cyphermox, what's wrong with mako for that purpose?
<RAOF> cyphermox: I don't have an armhf laptop, but man it'd be awesome if hsp worked!
<cyphermox> RAOF: works on my laptop
<cyphermox> I want to test specifically HSP on armhf, on a desktop install rather than an ubuntu-touch install
<RAOF> cyphermox: Huh. I've got a device that doesn't work with HSP on desktop; how should that be debugged?
<cyphermox> that's going to need looking at both the device and the desktop
<cyphermox> like, what is the bluetooth adapter used, etc.
<cyphermox> what does syslog say
<cyphermox> and whether a2dp works
<RAOF> cyphermox: a2dp works fine.
<RAOF> cyphermox: I've got it here if you want to look at it :)
<mjg59> Hm. Where did ixgbe go?
<mjg59> Is it subsumed into ixgbevf?
<mjg59> Oh, it's in -extra now
<mjg59> Ok
#ubuntu-kernel 2014-05-30
<apw> mjg59, :) glad we could help
<hallyn> apw: hey, do you remember the details of your patch for overlayfs unprivileged whiteouts?  
<hallyn> we're finding that if you mount / as underlay, you can't whiteout files you don't own
<manjo> hallyn, do you know of any other build servers (other than tangerine) that can build trusty armhf ? 
<jpds> Can someone take a look at this bug? https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1300739
<ubot5> Ubuntu bug 1300739 in linux (Ubuntu) "keepalived doesn't load any ipv6 virtual servers" [Undecided,Confirmed]
<hallyn> manjo: uh, perhaps gomeissa...  by "that can build" do you mean that are fast enough to do it in reasonable time?
<manjo> hallyn, that will work 
<Jef91> Anyone know what this build error means? /usr/bin/ld: cannot find -liberty
<Jef91> tail end of my failed compile -> http://paste.debian.net/102611/
#ubuntu-kernel 2014-05-31
<zequence> infinity: Been away for a while. All kernels tested.
<Hauke> Hi I am working on backports and want to detect the ubuntu kernel because we need some special ifdef for the kernel used in 14.04 for a backport included in this kernel and not in 3.13.X
<Hauke> the best would be if there is something similar to include/generated/uapi/linux/version.h
<Hauke> RHEL extended this file and added some RHEL version number to it so we can detect that this is a special RHEL kernel and compile different code
<Hauke> currently I have trubble with this commit: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commitdiff;h=f4c342cdce8acfaef2d89a800bb6a10128d802c8
#ubuntu-kernel 2015-05-25
<Hauke> hi
<Hauke> this commit has a merge error: http://kernel.ubuntu.com/git/acelan/ubuntu-trusty.git/commit/include/linux/netdevice.h?id=2da204a8f67fbe25816cbce8cc8551f03d5b951a
<Hauke> "struct pcpu_sw_netstats" was not added in the upstream commit which was backported and is unrelated
<cyking> fprietog, https://help.ubuntu.com/community/ReportingBugs
<cyking> oops
#ubuntu-kernel 2015-05-26
<henrix> Hauke: yeah, you're right: that struct shouldn't have been included in that backport.  anyway, that seems harmless and probably not worth the trouble fixing it
<leitao> ogasawara, hi there. 
<leitao> ogasawara, is it possible to backport https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1439562 to 14.04.2 in SRU?
<ubot5> Launchpad bug 1439562 in linux (Ubuntu Vivid) "backport request: include support for OpenPower hardware" [Medium,Fix released]
<leitao> arges, ^
<arges> leitao: looking
<ogasawara> leitao: heh, was just about to throw that at arges too :)
<arges> leitao: so when you say 14.04.2, you mean the 3.16 kernel right?
<leitao> arges, right.
<arges> leitao: sure i'll target that and assign myself
<leitao> arges, cool. This is going to be a big help.
<leitao> Do you have an ETA on when we would have that for 3.16 kernel?
<mnaser> i might have a 3.16 SRU soon too :X -- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1458045 -- this is close to being solved / patched upstream
<ubot5> Launchpad bug 1458045 in linux (Ubuntu) "KVM and CFS bandwidth control causes kernel crashes (oops)" [Undecided,Confirmed]
<arges> leitao: next sru cycle so probably jul 04
<leitao> arges, good
<arges> mnaser: that's an interesting bug, i'll put it on my radar
<mnaser> arges: right now there's a proposed fix by someone .. http://lkml.iu.edu/hypermail/linux/kernel/1505.3/01029.html and http://lkml.iu.edu/hypermail/linux/kernel/1505.3/01030.html
<arges> mnaser: oh excellent, make sure that link is in the bug. Once that fix lands in linus' tree we can backport it into affected Ubuntu kernels. Thanks for debugging this!
<mnaser> no problem arges, ill post it there
<mnaser> arges: updated and i'll update the bug once it (and hopefully if) it lands
<arges> mnaser: great. thanks
<arges> leitao: hey i see https://github.com/open-power/linux/commits/ubuntu/utopic , are there specific commits in that branch that are needed for the ubuntu 3.16 kernel?
<leitao>  arges: I will check later, quite busy atm
<arges> leitao: i'll post in the bug
<arges> thanks
<leitao> arges, good
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<cristian_c> jsalisbury, hi
<jsalisbury> cristian_c, hello
<cristian_c> jsalisbury, are there any news about build of that kernel you told me?
<jsalisbury> cristian_c, not yet.  I hope to have some time to investigate further this week.
<cristian_c> ok
<genkgo> jsalisbury: thank you for the build you finished the other day (the one that should solve the problems with the hyperv platform). however, the patches are not working in our case. since we do not even see the slightest change, i wonder it might be the build that does not contain the required patches. is there anyway i confirm the build does actually contain the patches?
<jsalisbury> genkgo, can you post the output of uname-a, that way I can confirm you are running the correct kernel?  I'll then review my git repo for that kernel to confirm all the patches are there.
<genkgo> jsalisbury: Linux VPS-Web-Produc2-Genkgo 3.19.0-18-generic #18 SMP Wed May 20 17:57:26 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<infinity> That was actually not the most helpful indicator. ;)
<jsalisbury> genkgo, hmm, that doesn't seem right.  The test for the kernel version: "3.19.0-18-generic" should have something like "~lp1445195" on the end of it
<infinity> cat /proc/version might be more helpful.
<genkgo> Linux version 3.19.0-18-generic (root@gloin) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) ) #18 SMP Wed May 20 17:57:26 UTC 2015
<jsalisbury> although it was built on gloin
<genkgo> jsalisbury: i used these http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
<genkgo> they say -0.18
<genkgo> without the dot of course
<apw> it is an unoffiial build at least, as its not got -Ubuntu in there, as you would expect coming from gloin
<apw> not sure how the heck that is root@gloin, some fakeroot leakage perhaps
<infinity> apw: He built with "fakeroot debian/rules foo", so yeah, it's all "as root".
<infinity> apw: As opposed to a proper dpkg build, which does it all as $user, except for the deb-building bits.
<apw> ahh a lack of binary-foo as yourself first then
<apw> performance of that sucks if you don't remember to do the binary-foo ... sigh
<genkgo> infinity: but does it matter regarding my testing?
<jsalisbury> genkgo, so it does look like the right kernel.  I just didn't add the ~lp1445195 onto it
<jsalisbury> genkgo, I'll confirm it has all the commits that were requested in the bug.
<infinity> apw: No real harm in fakerooting the whole thing, except that it's WAAAAAY slower, especially on a multicore box like gloin.
<apw> so slow, ugg
<infinity> (Cause sysvipc sucketh)
<genkgo> jsalisbury: thank you for looking up, i'll wait for that then
<infinity> apw: Just remember, any time you feel the need to curse how awful sysvipc (especially in the fakeroot context) is, Hurd doesn't have sysvipc, and fakeroot uses a TCP IPC imlpementation there.
<jsalisbury> genkgo, np, I'll let you know
<infinity> apw: That performs exactly as well as you'd expect. :/
<apw> infinity, just don't, i may remeber if you say it again
<infinity> apw: TCP IPC!
<infinity> apw: TCP IPC!
<apw> swine
<jsalisbury> genkgo, I just updated the bug.  Your test kernel is missing one commit.  I added an explanation in the bug.  I'll have another test kernel for you shortly.
<genkgo> aight, wonderful :)
<genkgo> jsalisbury: we do not have a confirmation however that someone actually used the new builds succesfully
<genkgo> whether it is vivid, utopic or trusty
<cyking> jsalisbury, hi! any luck with the bisect for my bug?
<awreece> Has someone here used the userstacktrace funtionality in ftrace before?
<jsalisbury> cyking, the next test kernel for your bisect failed, so I need to figure out why.  That can happen ofter with bisects because your going back to a point in time in the mainline tree.  At that time there can be other bugs that caused a kernel build failure.  So the trick is to find what fixed the build fail.  Then apply it before any kernel builds that fail because of it.
<jsalisbury> ##    
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<cyking> jsalisbury, its too bad "they" don't save every build for each git commit. Disk space isn't that expensive anymore. ^_^ 
<jsalisbury> ##  
<jsalisbury> ## Meeting starting now 
<jsalisbury> ##  
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 2nd, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
<cyking> jsalisbury, i'm running into a problem where i cant use lxc containers on my system when using .13.0-031300-generic.  would you have a suggestion to which 3.13 kernel i could use in the mean time that would let my nic fuction and lxc containers work ?   reference: https://github.com/lxc/lxc/issues/472
<cyking> *when using 3.13.0-031300-generic.
<cyking> never mind: changing the config to lxc.aa_allow_incomplete = 1  seems to work.  sorry
<jsalisbury> genkgo, I have a new vivid test kernel here: http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
<genkgo> jsalisbury: wonderful, will work on this tomorrow (dutch time), will let you know my results
<jsalisbury> genkgo, great.  Thanks for testing!
<genkgo> jsalisbury: just installed everything. it was without trouble, now i will start backups tomorrow.
<genkgo> jsalisbury: only had to --ignore-depends=binutils just like before
<jsalisbury> genkgo, ack.  thanks again.
<awreece> what diagnostic tool do people here use for digging into performance issues? Is it exclusively perf, or some ftrace or systemtap, etc?
#ubuntu-kernel 2015-05-27
<apw> awreece, perf for sure, sometimes we do do ftrace type gathering as wel, depends on the problem
<henrix> apw: question about commit c097877319ab ("ARM: 8307/1: psci: move psci firmware calls out of line") since i see your 'Reported-by:' :)
<henrix> apw: would you say that commit is applicable for the 3.16 stable kernel?
<henrix> apw: it has been applied in 4.0 and 3.18, and it seems to apply cleanly in 3.16 as well
<tomp> Something is wrong and I do not know where to start :-(((
<tomp> I have specific symptoms but not like those at the "Kernel/Debugging/Symptom"-site
<tomp> What could be my most simple debugging strategy ?
<tomp> I'm well nigh sure I have a kernel problem :-/ 
<tomp> What it's not:
<tomp> backlight brightness control 
<tomp> thermal
<tomp> hotkeys
<tomp> suspend/resume problem
<tomp> What it could be:
<tomp> sometimes it seems as if the module for wireless via USB can't be loaade (see the machine modprobing ad infinitum)
<tomp> First appearance after updating/upgrading from Ubuntu-3.2.0-80.116 to Ubuntu-3.2.0-83.120 and still subsisting in Ubuntu-3.2.0-84.121
<tomp> BTW: What is "scheduling while atomic" ? I've seen some CPU hard lockups while investigating my problem
<tomp> How can I investigate it's not a BIOS issue ?
<tomp> Once a sound problem occured :-/ 
<tomp> Could it be an interrupt related issue ? In a log I saw that IRQ18 was disabled (by what???)
<tomp> BTW: It's nit EFI
<tomp> On https://wiki.ubuntu.com/Kernel/Debugging there's a lot of Debugging Tools/Information - regrettably it's too many, I don't see where to start from and what to start with :-(
<tomp> But headache NÂ°1: The whole thing isn't reproducible - at the moment, the machine is up 8,5 hours without any issue ...
<tomp> Where should I start when the issues appear  ?
<apw> henrix, ok the issue there is only triggered by the compiler combinations, but yes if it applies i would think it is safe and prolly snesible to have
<henrix> apw: ack, thanks.  just wanted to confirm, as it was not tagged for stable
<apw> tomp, well you have a believed good kernel, and one you know is bad so i would try the ones in between
<apw> tomp, if it isn't very easy to reproduce this will take some time to confirm/deny each of the interviening ones is good/bad
<apw> but once we have two consequtive kernels good/bad then we can look at the differences there
<tomp> apw: What I can say so far: I first noticed it with 3.2.0-83.120. But next day I saw a kernel update and was in "good hope" that someone had found the issues and fixed them. So I'm on 3.2.0-84.121 now - but sadly the issues reappear from time to time :-(
<apw> so whatever 119 is would be a good one to try
<tomp> So, the question is: No more experiments and go back to 3.2.0-80.116 or go forward to some other available 3.5 kernel ?
<apw> well if you are on the LTS you can try the linux-lts-trusty kernels
<tomp> OK, but I'd like to have some informative basis about the problem before trying (and not knowing what I'm looking for) ...
<apw> tomp, yep, you need to know how to say the problem exhibited itself for sure, what the primaty symptom is
<tomp> Curiously 81.117 and 82.118 weren't installed by update manager. Maybe it was on 14 day frequency then an the kernel versions came in that time slot.
<tomp> If it's reappearing the next days, can I get some help here ?
<apw> tomp, there were a lot of small uploads for security and the like, may have been those
<apw> tomp, yep
<tomp> What's the best time to disturb you with new problems ;-) ?
<apw> there are lots of people in and around at all sorts of time, just ask and you are likely to find someone
<tomp> apw: Our daylight time seems to be the same. I'm CEST=UTC+2
<tomp> Have a nice day
<attente> apw: hi, how does one propose changes to the ubuntu kernel?
<apw> attente, if you have specific fixes in mind then you can email kernel-team@lists.ubuntu.com and starts a thread there
<apw> you can also start talking about it here
<attente> apw: sure, it's just a small patch that will permit the addition of a new apparmor rule type for dconf settings confinement
<jjohansen> attente: uh, sending to kt is premature
<attente> jjohansen: oh ok. sorry, i didn't know the process
<jjohansen> attente: I would say send it to the apparmor list for review
<attente> jjohansen: sure. thanks
<jjohansen> attente: apparmor@lists.ubuntu.com
<apw> attente, yeah if its apparmor, then i would refer you to jjohansen who has already answered all my followup questions
<attente> apw: great, thanks
<cheburan> Hey, another try: PATCH 3.16.y-ckt 033/129 d2dc317 ext4 data corruptions - is it going to make to 3.13 LTS?
<apw> kamal, henrix, ^
<henrix> i'm not sure 3.13 is affected by that, let me have alook
<kamal> cheburan, henrix, it looks relevant to me.  test-building it now.  :-)
<henrix> yeah, it looks like it's applicable.  and since it's tagged for stable, it should hit 3.13 soon
<kamal> cheburan, henrix: assuming that it builds okay, I'll queue it up for 3.13-stable immediately
<cheburan> kamal, thanks. from the post on lwn (https://lwn.net/Articles/645723/), it seems that the bug was in the kernel for long time
<henrix> cheburan: yep, true
<kamal> cheburan, yes thanks for the heads-up ... I certainly prefer to get this into 3.13 sooner rather than later :-)
#ubuntu-kernel 2015-05-28
<genkgo> jsalisbury: I just read the remark of Joshua that we should not take that hyperv test kernel into production. What was the base of your build? To which kernel did you apply the commits/patches?
<genkgo> jsalisbury: btw, our machine is still doing very well. we are creating backups every half an hour and there were no problems so far.
<genkgo> jsalisbury: thank you for providing the kernels so quickly!
<jsalisbury> genkgo, np.  I'm glad to hear testing is going well
<genkgo> jsalisbury: could you also tell me what kernel you used as base (before applying the patches)?
<genkgo> jsalisbury: because joshua advices not to use the kernels in production. well, i feel there should be no problem because only patches to fix a problem were applied.
<jsalisbury> genkgo, I used the master-next branch for the Trusty, Utopic and Vivid repos, so the -proposed kernels
<genkgo> jsalisbury: ok, that means there were more patches applied then just the hyperv ones
<genkgo> jsalisbury: what is the next release of a kernel that might contain the hyperv patches? i am in a doubt if i should take the kernels in production. what would you say?
<genkgo> jsalisbury: my situation now is far from perfect either, creating backups is quite important to us
<jsalisbury> genkgo, You could start with one machine and test for a while.  There is always a risk of putting a kernel in production that has not been thoroughly tested
<genkgo> jsalisbury: ok, i am doing that already, i will convert other machines slowly then, thanks again!
<jsalisbury> apw, fyi, testing is going well for bug 1445195
<ubot5> bug 1445195 in linux (Ubuntu Wily) "[Hyper-V] Kernel patches for storvsc" [High,Triaged] https://launchpad.net/bugs/1445195
<apw> jsalisbury, nice .. good work on that
#ubuntu-kernel 2015-05-29
<owlman> Hi, is there a git branch with only the packaging patches for the mainline kernels (e.g. http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-rc5-unstable/) publically available?
<owlman> i.e. the 3 patch files 000?*
<apw> owlman, no they are not in a public git tree, just in the directory
<thoma> Someone knows a SIMPLE way to collect MCE information ?
<genkgo> jsalisbury: unfortunately, the hyperv is still there. could we collect more information somehow? i am not very experienced with kernel. e.g. a backtrace. i now only use dmesg.
<apw> genkgo, do you mean the "going offline on backup issue is still there" ?
<genkgo> apw: yes
<genkgo> apw: but it took a while to trigger
<genkgo> apw: much longer than before
<trippeh> Hm. wireless-regdb is still way out of date
<apw> trippeh, yep we are working on that right now
<trippeh> wohoo :)
<trippeh> had to disable VHT80 on the network here, or else iwl keeps downgrading to 802.11n.
<genkgo> apw: is there any method to do some sort of trace? e.g. to see where an error is coming, to exactly see why the system goes into read-only. i would like to add more information than just my dmesg, because that one is always the same.
<apw> genkgo, i suspect that that contains the real info ... and thaat implies the fix just made the window smaller not removed it
<genkgo> apw: i guess so
<genkgo> apw: maybe it also proves why testing with a development machine is so hard with this problem. the io pattern of a testing machine does not match a production machine and therefore the window is too small on a testing machine. hence, it is likely the bug to manifest faster on a production.
<owlman> apw: thanks.
<owlman> I found the git://kernel.ubuntu.com/ubuntu/unstable.git repository. Where is the wily master-next repo?
<apw> git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily
<owlman> awesome, thanks
<jsalisbury> genkgo, thanks for updated the bug.  We'll see what the response is from jrp and see if other commits are needed.
<genkgo> jsalisbury: yes, let's see. i am also wondering how they have done their tests
<genkgo> jsalisbury: we are pushing limits of course by creating snapshots every half an hour
<jsalisbury> genkgo, right
#ubuntu-kernel 2015-05-30
<melodie> hi
<melodie> can someone help me to help someone who has trouble with USB 3 and usb_xhci_platform on a Trusty Ubuntu official install (appearantly up to date) ?
<melodie> I also have a vm with a Trusty 14.04.2 install runnning and have done a research on the XHCI drivers in the config of the kernel and in the system and seeing the results I thought I'd come here for more insights.
<melodie> funny, the kernel has USB_XHCI_PLATFORM enabled as "module" in the config-`uname -r` kernel, but not available in the /lib/modules/* directory
<melodie> the default stock kernel 
<melodie> I can provide the thread on the forum, if someone here reads French
<apw> melodie, what module name are you looking for for that config item, on vivid at least i have xhci-plat-hcd.ko
<melodie> apw I have seen it in vivid too
<melodie> I am testing in vbox trusty installing vivid-lts kernel packages
<melodie> I will reboot the vm very soon
<apw> but do you have that module name in /lib/module, as that is the module that is made by that config item
<melodie> it is not me who has usb 3 trouble, it's a buddy on a forum
<melodie> in trusty /lib/module does not have ANY xhci module
<melodie> whatsoever
<melodie> of any kind
<apw> what packages do they have installed
<apw> for the kernel, linux-image ?  linux-image-extra?
<melodie> http://forum.malekal.com/probleme-reconnaissance-cle-usb-32go-t51085.html
<melodie>  yes I got him to install linux-image-extra-virtual
<melodie> he has 3.13.0-52-generic x86_64
<melodie> he said in Ubuntu 14.04 32 bits not problem and in Ubuntu 14.04 64bits he can't have USB3 32 GB stick work in the USB3 hub
<melodie> but he can use it in usb2 hub
<melodie> I think perhaps he did have linux-image-extra in 32bits, but not sure really.
<melodie> he met with other issues meanwhile which we try to fix
<apw> -rw-r--r-- root/root     11204 2015-05-20 11:41 ./lib/modules/3.19.0-18-generic/kernel/drivers/usb/host/xhci-plat-hcd.ko
<apw> the module is in th linux-lts-vivid -extras package
<apw> on 64bit packages
<melodie> yes same here in Vivid, but in Trusty with some kernels 3.13.0-52-generic x86_64 and other 3.13.0* previously installed, none
<melodie> apw so is that only in 64bits packages that it happens and in 32bits packages the stock kernel would provide the xhci modules?
<melodie> (so I would understand the situation clearly)
<apw> no they would be in the same split
<melodie> but there is none at all
<melodie> no xhci in Trusty with the default kernel
<melodie> if they are compiled with the "y" option in the config-* file, it should still appear under /lib/modules/* but no *xhci* at all appears
<apw> no it seems there is a special for that option on trusty
<melodie> also: are we sure that xhci-plat-hcd.ko stands for USB_XHCI_PLATFORM ?
<apw> ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
<apw>         xhci-hcd-y              += xhci-plat.o
<apw> endif
<apw> so it is part of xhci-hcd and builtin
<melodie> which means what exactly? (in current words?)
<apw> even if =m
<melodie> =m but so far modprobe on the name returns "no such file"
<melodie> I felt concerned about this issue because Trusty is a LTS, and because nowadays USB3 comes more and more used by the people 
<apw> right, its a frig, =m does not make a module there
<melodie> excuse me, English is not my native language. What does the word "frig" mean?
<apw> bodge
<melodie> a bug?
<apw> not normal behavior
<melodie> ok
<melodie> so did we lift a bug here?
<apw> not bug, just unexpected meaning of the option i think
<melodie> do you have the possibility to talk about that to some people in charge with the kernels in Ubuntu Trusty LTS?
<apw> i am saying that it is built, and builtin i believe even though =m
<melodie> how is that possible? I have built some of my kernels in the paste times, and "y" is builtin and "m" needs to be loaded at boot
<apw> yes that is what it means normally
<apw> and in vivid, it does
<melodie> and when checking with command lines, to have it loaded we can check either by a grep on the chain in the config file or by a find in the /lib/modules directory. Else, the module isn't available : which explains that this guy keeps hitting his bottom on the floor: the usb3 sticks (32gb) are detected only when plugged in a USB2 hub or direct connector. No USB3 hub or direct connector could see it so far (dmidecode, lshw and lspci checked)
<apw> obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
<melodie> something must have gone wrong on the way
<apw> is vivid, so it has normal behavior
<melodie> I'll advice him to try with the vivid kernels
<apw> but trusty has different code
<apw> yep, do
<melodie> kernel kernel headers and linux-image-extra from vivid
<melodie> anyway it might be interesting to let the people in charge know about that, they might want to have a look into it
<melodie> ?
<apw> file a bug about it, it might be related to
<apw> obj-$(CONFIG_USB_XHCI_HCD)      += xhci-hcd.o
<apw> if that is =m as well
<melodie> I can't file a but about it, I would need to have a similar usb3 32gb stick as this guy has which I don't have.
<melodie> if I file a bug I need to be able to test what needs to be tested 
<melodie> or it serves no purpose
<melodie> this is why the persons in charge of those kernels should be called in so they can check.
<melodie> if supposedly they do have usb sticks needing xhci_* modules
<melodie> apw thanks for your help
#ubuntu-kernel 2015-05-31
<trippeh> [7341824.537568] ifquery[183]: segfault at 1 ip 00000000004031c8 sp 00007ffc76037c10 error 4 in ifup[400000+d000]
<trippeh> oops ? :-)
<trippeh> every boot. interesting.
<apw> trippeh, looks like a bug in ifquery/ifup to me worth a bug i am sure
 * ogra_ sighs ... when did we silently switch to intel_pstate ?
<ogra_> totally trashed my update to vivid (cores switching to 133 MHz while the system is under full load, core temps constantly between 85 and 90Â°C )
 * ogra_ files bug 1460399
<ubot5> bug 1460399 in linux (Ubuntu) "ivybridge system gets completely unusable after upgrade to vivid thanks to defaulting to immature intel_pstate driver" [Undecided,New] https://launchpad.net/bugs/1460399
<apw> ogra_, do you have thermald installed as i believe that is meant to be programming those behaviours
<ogra_> apw, dumping to 166 ot 133MHz is a thermald thing ? 
<ogra_> *or
<ogra_> (under full load)
<ogra_> it stopped doing that when i switched back to ondemand ... 
<trippeh> probably pstate enables the turbo states, making it run too hot for your cooling and crashing into thermal throttling
<ogra_> well, the point is that it didnt manage to get the heat low enough and the BIOS emergency shutdown kicked in every 10-15min
<ogra_> the system behaves properly after switching back to cpufreq
<ogra_> (without making any other changes)
<apw> trippeh, thermald does indeed allow turbo and other things, it should of course also not make your machine explode too
<apw> ogra_, using pstat_idle is the recommneded option on these pieces of h/w so i am supprised of your experience
<apw> ogra_, anyhow i've added cking to the thing becuase he did all the work on that back in the day
<apw> (recommended by Intel, ...)
<trippeh> inte_pstate has been working fine on my hardware, fwiw :)
<ogra_> well, it diidnt help that i wasted 3h into trying to find out why X was so slow ... debugging graphics stuff :P the system really felt like i'm running something even sub-vesa ... 
<trippeh> even the tiny cooling challenged ultrabooks
<ogra_> currently i'm fine ... once someone wants to debug it during the week i'm happy to collect data 
<ogra_> after all it got me to clean up 100 of my 150 constantly open firefox tabs ... so it had it's good sides ;) 
<apw> ogra_, yeah i'll poke cking monday and see what he thinks
<ogra_> i only found an older bug from infinity who seemed to have the same issue but in another release 
<apw> trippeh, yeah same here, i have a shitey ulrabook [sic] and it is also fine
<ogra_> bug 1188647
<ubot5> bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,Fix released] https://launchpad.net/bugs/1188647
<apw> ogra_, yeah and that was before we had thermald paired with it, the kernel bits are useless without hte daemon, and it wasnt packaged then
<ogra_> ah
<ogra_> thermald is quite noisy in syslog btw 
<apw> which is why i was trying to find out if you have thermald installed and if when in pstate it was running because that is mean to be "the way it works"
<apw> yeah we ought to look at that, much of that thermal stuff is whiney
<ogra_> yeah, i noticed :)
<apw> if you could add your thermald logs for the bad period (if you cna identify them) they may be valuable
<ogra_> i'll look them up 
<apw> thanks
<bigdissaved>  Morning, I am wondering what how I can recomend a kernel driver be added to the dist? It is for the rtl8812AU AC 1200 wireless chip. I have it working on my system, but it is very anoying that I have to recompile and install it every kernel/system update. It is in my garage, and wifi is the only connection that it has.
<bigdissaved> https://github.com/abperiasamy/rtl8812AU_8821AU_linux  this is the source code tree that I am using, and it works flawlesly for my self with 15.04 and 14.04.2
#ubuntu-kernel 2016-05-30
<mcphail> Hi. Can I poke someone to request a fix be backported from upstream? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574102
<ubot5> Launchpad bug 1574102 in linux (Ubuntu) "Regression (constant vibration of device) in xpad driver in Ubuntu 16.04" [Medium,Confirmed]
<djs> apw: I'm still confused by the lack of a 4.6-wily kernel, I'm currently running the lts wily hwe on 14.04 but looking for a later kernel
<djs> why were all the 4.6-rcX kernels built but not the final release kernel?
<djs> if I can just use the 4.6 yakkety kernel I guess that's fine too
#ubuntu-kernel 2016-05-31
<apw> djs, the -<series> extension only tells you the configs used ... using -wily for the -rcN kernels was wrong
<apw> djs, it was a bug related to new series opening
<mcphail> Hi. Can I poke someone to request a fix be backported from upstream? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574102
<ubot5> Launchpad bug 1574102 in linux (Ubuntu) "Regression (constant vibration of device) in xpad driver in Ubuntu 16.04" [Medium,Confirmed]
<apw> jsalisbury, seems there is another proposed fix in the above bug ... perhaps you could do the do and make a test kernel
<apw> djs, also ... have you tried the lts-xenial kernel on 14.04
<djs> apw: thanks, that's a good explanation... I'll try the lts-xenial kernel and see how that goes
<jsalisbury> djs, I'll backport the fix if lts-xenial isn't a good fix for you.
<jsalisbury> djs, The commit mentioned in the bug is in mainline as of 4.7-rc1, so it's probably not in xenial yet, but it was cc'd to stable.  It should be in all the stable Ubuntu kernels via the regular stable update process: 
<jsalisbury> git describe --contains 4efc693
<jsalisbury> v4.7-rc1~14^2~4
<jsalisbury> y
<djs> jsalisbury: thx :) 
<jsalisbury> commit 4efc6939a83c54fb3417541be48991afd0290ba3
<jsalisbury> Author: Pavel Rojtberg <rojtberg@gmail.com>
<jsalisbury> Date:   Fri May 27 16:22:25 2016 -0700
<jsalisbury>     Input: xpad - move pending clear to the correct location
<jsalisbury>     
<jsalisbury>     otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27
<jsalisbury>     
<jsalisbury>     Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
<jsalisbury>     Cc: stable@vger.kernel.org
<jsalisbury>     Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
<hallyn> jjj/win 27
<smb> hallyn, your are a /win'er :-P
<hallyn> aw shucks
<apw> smb, oh dear, you clearly need a beer
<smb> apw, It would be the time at least
<apw> gawd, yes, where did the day go
<Odd_Bloke> s/ea/a/
<smb> Odd_Bloke, or that... :)
<smb> Guess that is one of the things where the German shows...
#ubuntu-kernel 2016-06-01
<mamarley> apw: It looks like the amd64 lowlatency kernel for v4.6.1-yakkety is busted and won't boot.  Here is the output I get: https://i.imgur.com/U9XvJEl.jpg.
<mamarley> By grepping dmesg, it appears that the "ahci" driver is not loading, which would explain the lack of root device.
<mamarley> The ahci.ko file is included in the initramfs and loads properly if I modprobe it.
<mamarley> It looks like udev isn't working correctly, first because the module doesn't load to begin with and then if I load the module manually, the device files don't get created.
<mamarley> I am doing my own build of 4.6.1 now to see if that acts any differently.
#ubuntu-kernel 2016-06-02
<zzarr> hello!
<zzarr> I get this message booting an ARM based device "[!!!!!!] Failed to mount API filesystems, freezing."
<zzarr> what could be wrong?
<zzarr> I'll pastebin
<zzarr> http://pastebin.com/5yz1WgXt
<zzarr> the fstab is completely empty
<apw> zzarr, are those pseudo filesystems enabled in the kernle configuration ?
<zzarr> apw, I realized that I'm booting the wrong kernel
<zzarr> I'll be back if the new kernel don't solve the problem
<zzarr> I derped ;)
<mamarley> apw: Did you see what I posted last night about the busted 4.6.1 mainline build?
<apw> mamarley, and does the -generci version of that work ?
<mamarley> apw: I will try that right now, one secâ¦
<apw> mamarley, i am going to assume not, as they are basically the same
<mamarley> That's what I would guess too, but I am still trying it.
<apw> mamarley, it looks like something useful is turned off, not the error initialiseing the udev socket
<mamarley> I can tell you that 4.6.1 compiled myself from the linux-stable tree (on Xenial, using the configuration from the 4.6.0 mainline build) does work, but I can't actually run it because I am getting weird DKMS build failures.
<mamarley> Yeah, that's what I figured too.
<apw> not thati have a 4.6.1 stable tag here, wtf
<apw> in the stable tree
<mamarley> apw: The -generic kernel has exactly the same problem.
<apw> which prolly means the main configuration on unstable is broken
<mamarley> I am going to diff the config between 4.6 and 4.6.1 and see if anything pops out at me.
<mamarley> apw: Aha, CONFIG_UNIX switched from "y" to "m".  That looks fishy.
<apw> mamarley, yep
<mamarley> Actually, a bunch of stuff switched from y to m.
<apw> and that is expected, we're pulling things out and seeing what breaks
<apw> AF_UNIX though may well be a step too far :)
<apw> i'll poke the player in the game
<mamarley> That's the only thing I see that would obviously break the system.
<mamarley> It also looks like something is screwed up with "make deb-pkg".  When I follow the first set of instructions on https://wiki.ubuntu.com/KernelTeam/GitKernelBuild, DKMS fails to build the NVIDIA module against that kernel.  From the build log, it looks like it skips compiling and goes straight to linking, which of course fails due to files not found.
<mamarley> The second set of instructions on that page produce a package that allows DKMS to compile stuff just fine though.
<apw> mamarley, that would not supprise me, its not a method of building "we" in the team use often if at all, so if it gets broke we prolly won't notice
<mamarley> I will file a bug report on that later.  Right now I have to go to work, and after work I have an brand-new NVMe SSD to install in my computer!
<mamarley> apw: Is there any way I can simulate the mainline kernel build on my own computer?
<apw> mamarley, its pretty simple, it just applies config from the nearest ubuntu release
<apw> mamarley, then does fakeroot debian/rules clean binary-<flavour>
<mamarley> OK, I shall try that.
<mamarley> apw: Where does the debian directory come from?  Is it just copied out of the nearest Ubuntu kernel release too?
<apw> mamarley, yep exactly that
<mamarley> Cool, thanks!
<mamarley> apw: You might be interested in https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1585587 too (regarding CONFIG_UNIX).
<ubot5> Launchpad bug 1585587 in lvm2 (Ubuntu) "Missing unix.ko in 4.6 initrd prevents LVM boot" [Undecided,New]
#ubuntu-kernel 2016-06-03
<xnox> apw, any plans to do mainline builds for s390x?
<xnox> e.g. http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/
<apw> xnox, hmmm, i wonder how we decide
<xnox> we are way ahead of everyone else and quite often bugs like "works everywhere but ubuntu" is actually "broke in mainline since X.Y"
<xnox> there is ppc64el builds....
<xnox> *are
<apw> xnox, seem we have a nice non-maintable list ... yay ... so presumably for X+ right ?
<xnox> apw, yes please.
<apw> xnox, ok added, deployed, and a v4.6 rebuild requested
<apw> xnox, we'll see what happens
<xnox> cool
<rtg> cyphermox, UEFI test kernels at ppa:canonical-kernel-team/unstable
<apw> rtg, there was a lot of failure messages in my inbox, was that intentional "don't waste cycled build" failures ?
<rtg> apw, I had trouble getting 3.13 to build. It wasn't parsing the ABI number correctly when I added a '~uefi' into the version. I prolly forgot to cancel one of the failing builds before uploading again.
<apw> rtg, ahh ok
<rtg> it still doesn't build arm64, but I think we can just turn off UEFI on that arch
<apw> rtg, sounds like we are missing some packaging back there
<apw> rtg, in older releases likely yes we can, but newer ones it may well exist i think
<rtg> apw, yeah, I was too tired to figure it out, so I just dropped the '~uefi'
<rtg> vivid and wily built OK
<rtg> apw, did you change CONFIG_UNIX=m in the mainline build ?
<apw> rtg, no, that comes directly from the unstable configs
<apw> rtg, so bugger, that means i will ahve to rebuild that _again_ when you fix it
<rtg> apw, one of the bug reporters suggested the correct fix was in udev or initrd, though I suppose I could revert the config change for now
<apw> xnox, ok s390x builds are now in there anyhow
<apw> rtg, it is a trick chicken and egg issue as module loading is handled on demand by udev
<rtg> apw, reverted and pushed
<apw> rtg, i'll respin that 4.6 so it gets the update
<apw> and whoever was testing and failing, can retest
<cyphermox> rtg: great. so does that mean there hasn't really been much testing for all of it?
<cyphermox> rtg: apw: how far are we from a kernel SRU cycle so we can SRU $everything $everywhere ? ;)
<rtg> cyphermox, I've done my own local testing to make sure it does what I think it should. I'm sure these patches could use a bit more exposure.
<apw> cyphermox, we start a new cycle next week, so nominally patches need to be avilable today to hit this cycle
<rtg> cyphermox, next SRU cycle starts Monday
<cyphermox> right, I'm trying to decide if we want to SRU everything now and test there if we're confident enough that things are good, or wait another three weeks or whatever to give us time to test everything in a PPA, on all releases, upgrades, etc.
<apw> cyphermox, if we wait 3 weeks can we still hit the point release ?
<rtg> cyphermox, given the difficulties consumers of DKMS may face, I'd advise testing, testing, testing
<cyphermox> it definitely wouldn't be better to fail to validate and block other things though
<cyphermox> 16.04.1 would be July 21st, we'd start to cut it close
<cyphermox> I said three weeks, but I really means next one of your SRU cycles
<rtg> cyphermox, are all of the user space bits well on their way to -updates ?
<apw> cyphermox, will all the rest of the bits be out before then, and do they have to be, i assume they do
<cyphermox> rtg: no, things will land along with the kernel, in proposed at the same time
<apw> rtg, in theory all of this new code is rendered sterile of we turn off enforcement by default right ?
<apw> rtg, so we could consider applying all but that (assuming there is a kernel command line to turn it on for testers)
<rtg> apw, its a CONFIG option only right now
<rtg> otherwise it kinda defeats the purpose
<cyphermox> yeah, I think we shouldn't mess with that especially since it's pretty much what we want to test
<apw> mamarley, the v4.6 mainline kernel has been rebuilt with the AF_UNIX thing reverted (in theory)
<mamarley> apw: Cool, thanks!
<cyphermox> rtg: what about a precise kernel? that seems to be missing from the PPA (or I'm not looking at the right place)
<rtg> cyphermox, the Precise kernel did not support signed modules, so we'll have to make do with the LTS Trusty kernel
<cyphermox> that's not in the PPA though?
<rtg> cyphermox, nope, but you can install the Trusty kernel by hand into a Precise user space
<cyphermox> this is a cutoff point at which we won't be making any more of any kernels that can't do signed modules, otherwise we'd be diminishing the value of having a new key (although we haven't got a new key just yet, that will go later)
<rtg> cyphermox, personally I think we should just leave Precise as is.
<rtg> that, or you'll have to make the new shim dependent on LTS Trusty kernel.
<cyphermox> as long as we're supporting precise, I think we can't discount the fact that there may be kernel or other updates -- there's just one key for signing Secure Boot stuff, so I think we need to care about it
<cyphermox> afaict that's 10 more months of support, seems unlikely that there won't be some security issue to fix within that time, but I won't pretend I pay much attention to how often kernel SRUs happen on precise :)
<rtg> cyphermox, I really don't know either, but I'm sure there will be at least one.
<cyphermox> ok
<cyphermox> so we should start validating 16.04 since 16.04.1 what's coming up fastest; then trusty (point release in august), and as time permits wily and precise
<rtg> cyphermox, ack
<cyphermox> rtg: do you have time to do testing on your own with everything? I mean including the userland bits and enabling dkms packages, upgrading to a new release, etc. ?
<rtg> cyphermox, we also support LTS Utopic and Vivid for awhile yet.
<cyphermox> I have the userland pieces at ppa:cyphermox/efi
<cyphermox> ok
<rtg> cyphermox, as long as a QEMU instance is OK for testing
<cyphermox> needless to say this all means it can't land in the SRU cycle this coming Monday
<cyphermox> rtg: should be
<cyphermox> you'll want to insert certificates to enable secureboot with the right signature checking
<rtg> cyphermox, that is how I tested these kernels thus far, i.e., enrolled my own keys
<cyphermox> https://wiki.ubuntu.com/SecurityTeam/SecureBoot
<cyphermox> right
<rtg> cyphermox, yep, I used jdstrand's script to enroll keys. worked like a charm
<cyphermox> I have an unbroken system that can do hardware SB with the MS keys now, so I'll reinstall 16.04 there now and start it
<cyphermox> rtg: cool; I haven't had as much luck, but I was able to enroll keys otherwise
<rtg> cyphermox, I don't have a bare metal box that will allow me to enroll keys, so I've had to use QEMU.
<cyphermox> well
<cyphermox> the only keys you ever need enrolled are the Microsoft ones
<cyphermox> we're not changing shim itself, so past this it can be done programmatically in MokManager
<cyphermox> I think the wiki is missing the relevant info for this; I'll see about adding it
<rtg> ok, good point
<cyphermox> MS> at the firmware level
<cyphermox> Canonical> at the MokManager level
<cyphermox> this means your signing keys for the PPA also need to happen at the MokManager level
<rtg> I guess that is a change from what I understood needed to happen.
<cyphermox> sudo mokutil --import $cert
<cyphermox> what did you understand?
<rtg> I thought we had to update shim with a new key.
<cyphermox> we will
<cyphermox> but we're not there yet
<rtg> ok
<cyphermox> that will be the very last piece, along with an updated grub that disables loading unsigned
<rtg> cyphermox, lemme know when the wiki is updated and I'll get started testing.
<cyphermox> rtg: ok, but you got the jist of it -- you want to re-sign stuff with your own key since we don't have the PPAs certificate, and then import that cert with the mokutil command above
<rtg> yup
<cyphermox> on reboot that will get you a blue screen that will have you confirm adding the key
<rtg> makes sense
<rtg> cyphermox, that reminds me, you don't expect older kernels to read that key from MOK, right ? Only Xenial+ knows how to do that.
<rtg> the only recourse for DKMS users on anything prior to Xenial is to disable secure boot.
 * rtg pops out for some lunch
<cyphermox> well, we at least expect that sudo mokutil --disable-validation will DTRT, and let people boot and load unsigned kernels.
<cyphermox> and load unsigned modules
<rtg> cyphermox, yes. I have tested that functionality.
<cyphermox> rtg: right
<cyphermox> well, I'm writing a trusty image to USB now to give this a shot ; I need to test something else to at the same time anyway
<cyphermox> rtg: will you add linux-lts-wily and others to the ppa?
<rtg> cyphermox, not unless you really want me to. The non-LTS Wily kernel is functionally identical, just built with a newer toolchain.
<cyphermox> rtg: it's kind of easier to just dist-upgrade the system with the PPAs enabled rather than mucking around to install various extra packages
<cyphermox> we want to make sure upgrades between distros and package upgrades will work, so it's good to be able to pick things up as if they were from the official archive.
<rtg> cyphermox, alright, but it'll likely be Monday before they are ready.
<rtg> cyphermox, I assume you want all 4 LTS kernels in Trusty ? e.g., Utopic, Vivid, Wily, Xenial
<cyphermox> ideally, yes. we want to test everything very carefully and then do the uploads to proposed
<rtg> cyphermox, ok
#ubuntu-kernel 2017-05-30
<manjo> sforshee, bug #1689980 is an extension of bug #1668726 that you had previously worked on.. any chance that you might be able to look at 1689980 and add your thouhts there ? 
<ubot5> bug 1689980 in linux (Ubuntu Zesty) "AACRAID for power9 platform" [Medium,Triaged] https://launchpad.net/bugs/1689980
<ubot5> bug 1668726 in linux (Ubuntu) "Ubuntu17.04: Need more patches for aacraid to bring up Boston System" [High,Fix released] https://launchpad.net/bugs/1668726
<manjo> sforshee, narainder gupta is trying to make a case for this bug as a candidate for 16.04.3 
<sforshee> manjo: done
<manjo> sforshee, thanks sir .. that should work 
#ubuntu-kernel 2017-06-01
<hwpplayer1> Hi friends
<hwpplayer1> Could you please explain me more about https://apps.ubuntu.com/cat/applications/sysprof/
<hwpplayer1> Okay thanks
#ubuntu-kernel 2017-06-02
<hallyn> so is kabi broken only if an exported fn's args change, or even when the length of the fn changes?
<hallyn> noob q
<apw> hallyn, when a function signature changes yes, an arg or the type of that arg or the consituents of that arg (in the case of a struct)
<apw> or its return value of course
<MAbeeTT> hello, I Was trying to install ubnutu server 16.04 as KVM guest of Proxmox 4.4-13. In the VM settings I choosed "automatically allocate memory" with a maximum memory and minimum memory acceptable values in mbytes (512 and 4096)
<MAbeeTT> but I get kernel panics, ther kernel starts tu kill proccesses and simetimes kills systemd.
<MAbeeTT> AFAIR proxmox pve uses kvm ballooning and the guest, unbutu 16.04 should have drivers for kvm ballooning.
<MAbeeTT> Is memory ballooming supported un unbuntu server?
<MAbeeTT> https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_memory
<MAbeeTT> ^ reference doc
<hallyn> apw: but just changing the length of the fn shouldn't do it right?
<hallyn> i'm confused by https://bugs.centos.org/view.php?id=13265    the patch therein 
<hallyn> does not seem capable of changing the kabi ..    i guess i may have to look at their kabichecker
<hallyn> groan
<apw> hallyn, can you point me to the patch ?
<hallyn> apw: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e52365f279564cef0ddd41db5237f0471381093
<apw> hallyn, it is hard to see how the heck that changes the kabi, you could confirm by reverting it on our tree and seeing it if breaks our abi
<hallyn> just by building without doing the skipabi=true in debian/rules should suffice?
<apw> hallyn, yeah something like that
<apw> hallyn, our abi checks function signatures, which includes any structures used as parameters
#ubuntu-kernel 2017-06-03
<hallyn> apw: ...  so, just doing a 'fakeroot debian/rules binary-generic'  should make the abi check run ?
<hallyn> i can't tell if it passed, or just didn't run
#ubuntu-kernel 2017-06-04
<apw> hallyn: yes should
<hallyn> hm.  then reverting the patch on ubuntu doesn't trigger, adding it to centos does.  wtf.  something else must be going on.  maybe i need to look at their other patches
<apw> hallyn, yeah you will probably find they get that much changed without your patch
<hallyn> apw: with no patch, it reports no change.  with a patch which only adds #include <linux/pid_namespace.h> to include/linux/ptrace.h, it breaks all the same fns as the full patch does
<hallyn> messed up
#ubuntu-kernel 2018-05-29
<ali1234> are dkms backports available anywhere?
<ali1234> i mean the actual dkms package itself
<apw> ali1234, what are you looking for exactly ?
<ali1234> dkms 2.6?
<ali1234> the problem i have is https://github.com/dell/dkms/issues/32
<apw> oh i have not see any of those now
<apw> no
<ali1234> but this isn't even fixed in master yet
<ali1234> although it was fixed once before 8 years ago, they have broken it again
<ali1234> if it gets fixed again, i need the fix on 18.04
<ali1234> it doesn't seem SRU worthy as it's just really slow
<ali1234> i made a dkms package of some drivers: https://launchpad.net/~a-j-buxton/+archive/ubuntu/tbs-dkms
<ali1234> and it literally takes 1 hour to uninstall or upgrade it
<apw> ali1234, you could just apply that to the source and upload it to your own PPA
<ali1234> yes, that will be my last resort though, as i like getting updates :)
<apw> in older series you are unlikley to get them, though if you name it right you would get the update
<apw> and then get the slow performance back so you would know
<ali1234> yes, but without the fix...
<apw> or propsoe the fix for SRU
<ali1234> happy to do that if you think there's any chance it will be accepted
<apw> it _is_ a bug i guess, so you have some hope
<apw> it would be easier if upstream had taken the fix for the future
<ali1234> yes, i wouldn't propose a patch for it myself, i dont know dkms or perl well enough
<ali1234> also, it's a bug that only affects dkms packages that install hundreds of modules... of which mine is currently the only one available for 18.04
<s10gopal> apw, jsalisbury when bug 1745646 will be fixed ?  testing for SRU is also done
<ubot5> bug 1745646 in linux (Ubuntu Cosmic) "Battery drains when laptop is off (shutdown)" [Medium,In progress] https://launchpad.net/bugs/1745646
<jsalisbury> s10gopal, The fix will be in the next set of updates that are available.
<jsalisbury> s10gopal, It will be kernel version Ubuntu-4.15.0-23
<apw> which is in -proposed already
<s10gopal> release date ?
<jsalisbury> s10gopal, June 02, I believe.
<jsalisbury> err , June 04
<apw> that seems rather sooner than i would expect
<apw> i think we are in week 2 because of the weeks slip in teh last cycle
<jsalisbury> what apw said :-)
<apw> i beleive 12th is more likley
<jac_cplane> bug https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1773165 for kernel 4.4.0-127
<ubot5> Ubuntu bug 1773165 in linux-lts-xenial (Ubuntu) "openvswitch-datapath-dkms kernel module is not getting loaded" [Undecided,Confirmed]
#ubuntu-kernel 2018-05-30
<jackpot51> jsalisbury apw: There are numerous hardware support fixes in the proposed kernel, and it has been in proposed for 7 days now. What decides the schedule for release?
<jackpot51> For System76, the important ones are "Intel WiFi driver update for ETSI 5GHz adaptivity requirement" and "Clevo P950ER ALC1220 Fixup"
<jsalisbury> jackpot51, It depends if there are going to be re-spins to include critical fixes.  I think the tenative date is now June 12th.
<jackpot51> Ok, understood
#ubuntu-kernel 2018-05-31
<xandey> Hi Kernel Team, I'm trying to bisect a bug which is in ubuntu releases, but doesn't show up in mainline builds. Is there some way to get the git history back to a mainline build? I can't seem to find this history in ubuntu-bionic.git
<cascardo> xandey: you can use the 4.15 tag, and the Ubuntu-4.15.0-* tags
<xandey> cassardo: ah, i was looking for v4.15.17. Also, I wasn't able to build commits which have labels like "UBUNTU: Ubuntu-4.15.0-4.5" but aren't actually tagged... is it possible this is some sort of rebase or toolchain change?
<xandey> cassardo: some of them ask me to change config options when following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<cascardo> xandey: yes, very likely a rebase
<cascardo> during development, those kernels are based on rc releases
<cascardo> further down the stable pipeline, you will more likely see kernels all based on v4.15
<cascardo> and fast-forward, all of those reachable from the master branch, at least after the GA kernel
<cascardo> but as we are so close to GA, the oldest one you will find is Ubuntu-4.15.0-9.10
<xandey> caascardo: right, I confirmed that I get the issue with 4.15.0-9.10 (building myself and downloading prebuilt from launchpad). However, I don't see the issue in any of the mainline built kernels 4.15.0-rc1, 4.15.17, 4.17.0-rc6.
<xandey> cascardo: I guess i'm looking to see if there's any more narrowing I can do at this point. But perhaps this is as good as I can do here, and it's time to try and debug directly.
<cascardo> what's the issue? did you report a bug already?
<xandey> yeah: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1768139
<ubot5> Ubuntu bug 1768139 in linux (Ubuntu) "Kernel crash when booting laptop with hdmi monitor connected" [Low,Triaged]
<xandey> it's a kernel crash when a dell laptop is connected to hdmi and boots up, but only with ubuntu kernel
<xandey> i was trying to do the rebase for the bug report
<xandey> sorry, *bisect*
<xandey> although I didn't see that last comment yet
<cascardo> xandey: you don't happen to have a Thinkpad X1, do you?
<xandey> nope, dell insprion 15
<xandey> cascardo: Dell Inspiron 7559
<cascardo> ok, i915 change in 4.15.0-9 was related to X1 only
<xandey> well, it's not that I narrowed it down to 4.15.0-9, it's only that that's as far back as I was able to build.
<xandey> Oh, looking back at my notes, it looks like I also managed to test 4.15.0-1_4.15.0-1.2 which asked me to change some cofig options, but also displayed the issue.
<xandey> I could try reverting dc0f16f9b5084e6be2b8c79f8c6cd499a3451791 which appears to be the only change between 4.15 and  4.15.0-1_4.15.0-1.2 in drivers/gpu/drm/i915
<xandey> but I don't see that as a difference between the 4.15.17 from linux-stable and 4.15.0-24 
<xandey> anyway, I don't mean to take up your time with a low priority bug, I just thought perhaps I was missing something with the build setup.
<cascardo> looking at the stack trace and the diff, it's hard to think this would be specific to ubuntu kernels
<cascardo> did you try our mainline builds?
<xandey> yes, I tried the ones from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D I also built the mainline myself
<xandey> maybe some sort of module packaging difference?
<cascardo> well, enabling some drm debug could help
<xandey> could you direct me a bit there?
<xandey> drm.debug=0xe on kernel command line?
<cascardo> something like that, let me look at the interesting bits of i915 and see which flag would trigger them
<cascardo> =0x4
<cascardo> KMS seems to have most of it
<xandey> okay, i'll try that
<xandey> cascardo: I grabbed two traces of the log, I think it will take me a while to puzzle out them. I posted them to the bug.
<cascardo> xandey: thanks
<xandey> cascardo: no problem
#ubuntu-kernel 2018-06-02
<jeremy31> Can https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/drivers/bluetooth?id=544a591668813583021474fa5c7ff4942244d654 be used on the 4.15 kernel as it fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1764645
<ubot5> Ubuntu bug 1764645 in linux (Ubuntu Bionic) "Bluetooth not working" [Medium,Confirmed]
#ubuntu-kernel 2019-05-28
<kbingham> Would it be possible to get vimc (CONFIG_MEDIA_VIMC) added as a kernel module to build? I assume that's more of a feature request, or blueprint rather than bug-report....
<LeoB> Hello
<LeoB> During Linux 5.0 development cycle, CFQ I/O scheduler was removed, and on bionic it (looks like) it was the default I/O scheduler.
<LeoB> What is Ubuntu's default I/O scheduler for newer Linux versions ?
<LeoB> is it mq-deadline?
