#ubuntu-kernel 2005-12-05
<lamont> now we just need a working klibc, and we can go to initramfs
<BenC> i got a WARN_ON() in free_initmem(), but it looks harmless
<lamont> yeah - that's um, expected
<BenC> well, it calls smp_call_function during a point when I belive irqs aren't enabled yet, so it makes sense :)
<BenC> going to do a full binary-arch build now to make sure udeb creation works and all
<infinity> How many arches are still building the kernel with gcc-3.4?
<infinity> Just hppa?
<BenC> yeah
<infinity> So dangeoursly close to LRM working right now...
<infinity> OTOH, after all this effort, the thing may well maintain itself for the rest of the release cycle without me touching it.
<infinity> Which would be nice.
<ispiked> mjg59: did you ever play with the stick and buttons not working on resume from hibernate on your laptop?
<mjg59> ispiked: Works fine on mine
<ispiked> mjg59: it's in and out on mine.
<ispiked> mjg59: you wouldn't know anything about messing with the wireless on/off light, would you?
<mjg59> Yeah, there's a kernel option to enable it
<mjg59> In the Intel case, it's driven by the card
<ispiked> hrm...
<ispiked> if it's enabled does it work?
<mjg59> Yes
<mjg59> But it's an experimental option, so it's not enabled yet
<ispiked> where is the code and what's the option?
* ispiked wants to see the sexy bluetooth icon even if bluetooth doesn't work.
<mjg59> Oh, it might actually be built in
<mjg59> Check modinfo -p ipw2200
<ispiked> yeah, it's there. the question is how to get it on.
* ispiked googles.
<ispiked> ooh. lemme try the readme.
<ispiked> mjg59: got it working. now for the bluetooth light.
<CataEnry> hi all
<CataEnry> bbl
<CataEnry> hi all
<BenC> jbailey: ping
<jbailey> BenC: pong
<BenC> jbailey: get my email regarding ac880 for that customer?
<jbailey> BenC: I did, thanks.  Do they need the new kernel that you're about to upload, or do they need the next one that will go in?
<BenC> -6.8, which will be my next upload
<BenC> jbailey: I got to thinking that maybe, if I fix the crash in breezy, the sound will work, but the hda driver is so different between the two that I have no idea if that's a correct assumption or not
<jbailey> And I need to test a ppc64 kernel for you.
* jbailey fetches
<BenC> jbailey: I may do a test kernel build with the fix for 2.6.12-10, and we can let them test that in the meantime, if you'd like
<BenC> yes, that would be nice, thanks :)
<jbailey> It seems like the best thing to do is get them to test the next dapper kernel, first.
<jbailey> That way we know that the problem is actually completely solved in the development branch.
<BenC> I'm almost 100% sure that it is fixed in dapper now, but a test would be a good idea
<crimsun> which codec for hda-intel?
<BenC> ac880
<crimsun> if it's alc, it should be.
<crimsun> yeah.
<BenC> alc880, yeah
<BenC> I added the one-liner fix from l-k, so that should fix it
<crimsun> great :)
<jbailey> rebooting for 2.6.15 test, bbias
<jbailey> 'kay, I'm on 2.6.15.
<jbailey> BenC: You wanted my dmesg if the fan staarts speeding up?  It sounds like it might, but I can't tell yet.
<BenC> just full dmesg
<BenC> just so I can see if there's anything weird
<jbailey> 'kay, /me emails /var/log/dmesg
<jbailey> Yup, it's speeidng up.
<BenC> and then "cat /proc/driver/rtc"
<BenC> and the full part of that (including any "BENC: ..." lines
<BenC> it will oops, just so you know :)
<BenC> I didn't fix anything
<jbailey> You asked about whether the command succeeded, I appear to get a bus error.
<jbailey> I've emailed /var/log/dmesg and the oops to you.
<jbailey> Anything else you need? If not, I'll reboot to the older kernel so that the fans can shut off. =)
<BenC> did any BENC lines get printed in the oops?
<jbailey> Two, at the top
<BenC> sweet, thanks
<BenC> that should be it
<jbailey> [  260.287465]  BENC: Obtaining rtc_lock in rtc_proc_show
<jbailey> [  260.287474]  BENC: at 1157
<jbailey> Cool
<BenC> just as I suspected
<BenC> jbailey: can you do "dmesg | grep BogoMIPS" on your breezy kernel?
<BenC> and also, just to be sure, can you do "cat /proc/driver/rtc"
<BenC> no need to send me any output, just need to know the bogomips
<BenC> and if the cat worked ok
<jbailey> root@starshine:~# dmesg | grep BogoMIPS
<jbailey> [   27.452696]  Calibrating delay loop... 66.56 BogoMIPS (lpj=33280)
<jbailey> BenC: And the cat works fine.
<BenC> guess bogomips is just supposed to be that low for ppc
<BenC> thanks
<jbailey> BenC: I think this box has cpu scaling.
<BenC> even my G4 only shows ~45, and I don't think it has scaling
<BenC> my i386 shows 4000 :)
<infinity> Your G4 shows 45 bogomips?
<infinity> That's weird that they use a different loop for G3 and G4, since they're virtually identical.
<infinity> (My G3 is ~2000 bogomips..)
<jbailey> G3's were clearly 'leeter.
<fabbione> your G3 cheats to look cooler
<infinity> Well, they were.
<infinity> Full speed cache.
<infinity> (And who needsa altivec anyway?)
<infinity> Still, odd.  Something to ask benh about some day, and he'll say "Like I remember why I did that", and I'll go "oh.."
<BenC> is benh ever on linuxnet?
<BenC> jbailey: as of right now, I only have two possible reasons for this crash...1) GCC-4 related, may need to try a gcc-3.4 compile
<BenC> the crash is happening in either out_8() or in_8(), which are assembly
<BenC> 2) it might be caused by the fact that breezy ppc64 was using discontiguous memory model and dapper is flatmem
<BenC> I'm leaning toward the first
<BenC> the code for CMOS_READ(), where it is crashing is the same in 2.6.12 and 2.6.15, so it's not a bug from that code directly
<fabbione> BenC: yes he is, but not 24h
<infinity> I'm scared to death of this switch to gcc-4.0 for the kernel, personally.
<BenC> I had already heard that ppc64 may need gcc-3.4, so this wouldn't be a surprise
<BenC> but everything else should be fine, and so far I haven't seen, nor heard of any problems from it
<infinity> I have a lovely OOPS from fglrx, but my hardware has never liked fglrx, so I'm unwilling to commit to it being the driver, kernel, or compiler's fault until I get more bug reports from this upload.
<zul> heylo
<BenC> looks like ppc and hppa may be the only ones left still using gcc-3.4
<infinity> Other than that, my kernel has been solid.  (Well, buggy in neat ways, like my lack of CD drive, but nothing crashy)
<BenC> hey zul
<infinity> And yes, I still have no CD drive in -5.7... I need to corner you tomorrow and talk to you about it.
<BenC> yeah, we need to pin that down
<BenC> jbailey: will you be able to test another kernel in about 15 minutes or so?
<jbailey> BenC: About 5m from now?
<BenC> 5-10
<BenC> build is almost done
<jbailey> Cool.
<jbailey> No ccache? =)
<BenC> compiler switch, so it wouldn't help anyway :)
<jbailey> Ah, dropping back to 3.4?
<BenC> yeah, about the only thing I can think of right now that might cause this
<BenC> it's getting some sort of sigbus trap on a byte sized read/write from IO memory...it's very odd for it to do that
<BenC> for all I know the trap is expected, and the trap to fix it up just isn't set :/
* infinity stares at BenC
<infinity> include/linux/highmem.h:12:25: error: asm/highmem.h: No such file or directory
<infinity> (building LRM on powerpc)
<BenC> ARCH=powerpc, not ARCH=ppc
<BenC> make sure it's not something like that
<BenC> plus, there's no such thing as highmem on ppc :)
<infinity> Erm, but it used to be ARCH=ppc.
<fabbione> "used" exactly
<infinity> (Must have been, since I didn't touch anything ppc-specific)
<jbailey> BenC: I thought there was.  My ppc64 box only generally sees 4gb of the 6 in it, IIRC.
<infinity> ifeq "$(DEB_HOST_ARCH)" "powerpc"
<infinity> export karch=ppc
<infinity> So, this needs to be "powerpc" now?
<fabbione> yes
* infinity tries it locally.
<jbailey> BenC: How's the build?
* fabbione takes a long break while mirror is syncing
<BenC> jbailey: done
<BenC> jbailey: same location, same file, just updated
<jbailey> BenC: We're looking for both the fan fix and the rtc fix here?
<BenC> I'm hoping atleast rtc, but the fan would be a nice bonus
<BenC> jbailey: your 4-6gig mem problem is likely memory layout and not highmem related
<jbailey> Paramtrage de linux-image-2.6.15-5-powerpc64-smp (2.6.15-5.7) ...
<BenC> ppc32 has highmem.h, but ppc64 doesn't
* BenC hopes for the best
<jbailey> Suspect fan issue is still there, will know in a couple of minutes.
<jbailey> rtc issue is still there.
<jbailey> [  121.941299]  BENC: Obtaining rtc_lock in rtc_proc_show
<jbailey> [  121.941305]  BENC: at 1157
<jbailey> [  121.941314]  Oops: Machine check, sig: 7 [#1] 
<jbailey> [  121.941915]  SMP NR_CPUS=4 POWERMAC
<BenC> damn, thanks for testing
<BenC> cat /proc/version please
<BenC> see if it shows the 3.4 compiler
<jbailey> jbailey@starshine:~$ cat /proc/version
<jbailey> Linux version 2.6.15-5-powerpc64-smp (root@davis) (gcc version 3.4.5 20051015 (prerelease) (Ubuntu 3.4.4-9)) #1 SMP Wed Nov 30 14:27:17 UTC 2005
<jbailey> I was just looking for that.  Tried uname -a and dmesg first. =)
<BenC> ok, and also, do a "free" for me
<BenC> see if it shows your memory
<jbailey> jbailey@starshine:~$ free
<jbailey>              total       used       free     shared    buffers     cached
<jbailey> Mem:       4008868     310692    3698176          0       9820     134340
<jbailey> -/+ buffers/cache:     166532    3842336
<jbailey> Swap:     19531232          0   19531232
<BenC> so you have 6gigs, huh?
<jbailey> FWIW, the cat still results in a bus error.
<jbailey> According to t-bone when I read him the serial number of the machine.
<jbailey> I don't know Mac hardware enough to say for sure.
<jbailey> Fan issue definetly not fixed.
<jbailey> Although it occurs to me that it might be a side effect of the oops.
<jbailey> I haven't tried *not* oops'ing the kernel to see if it happen.s
<infinity> BenC : Feh, both variants used to have highmem.h, or lrm-2.6.12 wouldn't have built.  (or something else is goofy)... So, WTF do I do now? :)
<BenC> infinity: breezy kernel doesn't have asm-ppc64/highmem.h
<jbailey> BenC: Lemme reboot and see if the fan issue is a side effect.
<BenC> ok
<infinity> BenC : Actually, wait, this isn't in ppc64 anyway, this is in ppc..
<infinity> (And yes, I just switched to ARCH=powerpc, same problem)
<BenC> hmm
<infinity> BenC : /usr/src/linux-headers-2.6.15-5-powerpc/include/linux/highmem.h tries to include asm/highmem.h
<infinity> BenC : Clearly, something is in the wrong here. :)
<BenC> infinity: you're correct, I need to fix that for -6.8
<infinity> Feh.  Alright, well LRM is stalled on that, then.  As is linux-meta and udev and friends.  Your turn to be the blocker. :)
<infinity> ETA on -6.8?
<infinity> BenC : And can you do a test build of LRM against -6.8's headers on PPC before you upload?
<BenC> is lrm uploaded now?
<infinity> Yup.
<infinity> I uploaded it before testing on powerpc.  Stupid me.
<BenC> sweet, I'll have -6.8 out tonight then
<infinity> So it's built on i386, amd64, and ia64.
<BenC> I can get a rebuild for ppc
<infinity> Oddly enough, so can I.
<infinity> I happen to know the buildd guy personally.
<BenC> well, we'll really need an ABI bump anyway
<infinity> (But it'll need an ABI... yeah)
<BenC> two words....smart and ass... :)
<jbailey> BenC: Fan issue definetly not side effect.  Going strong and no oops in dmesg.
<jbailey> Need anything else from this kernel?
<BenC> jbailey: nah, we're good, thanks
<infinity> BenC : Define "tonight"... 6-8 hours?
<BenC> closer to 8
<infinity> BenC : If so, I'll go to bed now, and re-do LRM in the morning.  I kinda want to babysit it for paranoia's sake.
<BenC> sure thing
<infinity> So don't bother doing the ABI bump yourself this time.
<infinity> Next time, it's all yours. :)
<BenC> check topic in AM, and if you see -6.8 uploaded, kick lrm for me :)
<infinity> It shall be done.
<infinity> Thanks, dude.
<BenC> no problem
<CataEnry> bye all
* BenC cranks up 6 concurrent builds and smokes a cig
<zul> doh...my cron script doesnt want to work..aiiee
<mjg59> BenC: Current softmac+bcm43xx should be able to scan
<BenC> I have current softmac fairly recent bcm
<BenC> mjg59: I pulled rtl8180 and rtl8187, since they are both unable to load (missing symbols)
<mjg59> BenC: Ok
<BenC> just did a compile out of CVS and it doesn't work
<mjg59> What are the missing symbols?
<BenC> ieee80211_wx_read_name and some such
<mjg59> Oh, right
<mjg59> Fun
<BenC> doesn't show up as a function in ieee80211 or ieee80211_softmac
<mjg59> How about in -netdev?
<BenC> possible, but I haven't pulled a netdev
<BenC> I'll ask jgarzik and davem and see if it's safe to pull from there
<mjg59> Ok
<jbailey> BenC: For ppc64, should I just continue to use 2.6.12, or are we hoping that -6.8 has more love for ppc64?
<BenC> hold off till I can talk to benh about what might be the problem
<BenC> I can easily "fix" the rtc issue by not compiling the module, but the fan issue is more of a problem
<jbailey> Makes sense. thanks.
<mkrufky> hey guys, i know this is off topic, but it's an easy question --
<mkrufky> last year i had some ubuntu installation cd's sent to me, i think i had ordered them from a web site, i dont remember
<mkrufky> anyhow, we're thinking of switching a whole bunch of boxes in the office here over to ubuntu
<mkrufky> does anyone know where i can find that web site for the cd mailers?
<mkrufky> not easily found on ubuntu.org
<fabbione> shipit.ubuntu.com
<mkrufky> awesome
<mkrufky> thanks
<fabbione> np
<mjg59> BenC: Is there a list of which 2.6.12 patches are included in our 2.6.15, and which have been dropped?
<mjg59> BenC: It looks like we're still missing the Toshiba acpi hotkeys patch
<BenC> mjg59: the large acpi patch sets I didn't include, but I was pretty sure I got most of the smaller ones (especially machine specific ones)
<mjg59> I get errors on boot about an invalid option on the Toshiba hotkeys
<BenC> I didn't add the old patch names to the git log, but I wish I had of
<mjg59> BenC: Looks like we haven't had anything applied to toshiba_acpi
<BenC> ok, I'll find the patch from breezy and apply it
<mkrufky> i just noticed em8300 in the ubuntu kernel tree
<mkrufky> is that fair game for us in v4l to play with?
<mkrufky> i mean, it is GPL and everything?  is there any reason it hasnt been included in vanilla kernel?
<mjg59> It's GPL, yeah
<mjg59> I've no idea why it's not upstream
<mjg59> Possibly the developers have just never pushed it
<mkrufky> okay... i'll see what i can do
<mkrufky> i see it has some brooktree encoders also in the same dir
<mkrufky> hmm
<mkrufky> is there a list anywhere of the drivers in the ubuntu tree that are NOT in the vanilla tree?
<mkrufky> i saw a small list on kernelgitguide
<mkrufky> but doesnt look to be complete
<zul> mkrufky: pretty much things like ndiswrapper is not in the vanilla tree..previous versions have a list of external-drivers
<mkrufky> okay, i'll have to take a closer look
<mjg59> mkrufky: Yeah, there's drivers for a couple of TV encoders in there
<mkrufky> but something like em8300 ... would probably be nice for us to import
<mkrufky> i see it also has bt865, em9010, adv717x 
<mkrufky> adv717x ... someone was asking for that the other day
<mjg59> http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fbcollins%2Fubuntu-2.6.git&a=search&h=0235c9b32a0f66e94da2d6bd8edf7f55224ce1c2&s=external+driver should give you all of them
<mkrufky> nic
<mkrufky> nice
<mjg59> But the commit title doesn't always give the driver name
<mkrufky> hmm i see
<mjg59> BenC: Is at76c50x still dropped?
<BenC> if it isn't in there, it'e because it's broken
<mjg59> Ok
<mkrufky> does anybody here know where you got em8300 from?
<mkrufky> there is something in linuxtv cvs .... not sure if it's the same
<mkrufky> oops, i found it in the commit msg
<mkrufky> thanx
<mkrufky> ok, the em8300 driver in  DVB cvs (not dvb-kernel) has also em8300 dvb driver, but it is completely different code
<mjg59> Weird
<mkrufky> ya... my interest has been sparked....... i ordered an em8300 card from ebay by accident last month.... so now i have a use for it
<mkrufky> i bet the dvb driver does the same thing, but using a dvb interface instead of a v4l interface ..... 
<zul> later
<CataEnry> hi all
<mkrufky> bye all
#ubuntu-kernel 2005-12-06
<BenC> it's sad that the 2x550Mhz A500 can compile faster than the 2x800Mhz i2k
<BenC> the A500 is on it's third kernel while the i2k is still working on the first
<BenC> jbailey: ping
<jbailey> BenC: pong
<BenC> jbailey: talked to benh, and got some things squared away...so I expect 2.6.15-6.8 to work for you
<BenC> rtc and fan problem
<jbailey> Ooo!
<jbailey> What was it?
<BenC> CONFIG_RTC => CONFIG_GEN_RTC (change in ppc for 2.6.15), since we are using the wrong rtc module
<BenC> and for the cpu, therm_pm72 needs to be loaded
<jbailey> Is that the generic timekeeping patch I saw on lkml a couple weeks ago?
<jbailey> 'k.  Should therm_pm72 be loaded in the initramfs then, I guess, sam as fan.ko is on acpi systems?
<BenC> nah
<BenC> well, in breezy it was built-in
<BenC> so I am going to do that for least-surprise reasons
<jbailey> Hmm.
<BenC> almost every G5 needs it
<jbailey> I'm a strong fan of get-it-out-of-the-kernel.
<BenC> without it, you get the "vaccum cleaner mode" as benh put it :)
<jbailey> The initramfs has to handle it for laptops anyway.  Keybuk's laptop gets about 20 seconds before it overheats otherwise.
<BenC> so in this case, since 99% of the users of this kernel will need it, I think it's best to put it in
<BenC> yeah, but every laptop is different in someway, isn't it?
<jbailey> Soudns like a trick question. =)
<BenC> or is that general acpi?
<BenC> yeah, it was a little tricky :)
<jbailey> General acpi.
<jbailey> In the init-premount hook, we have a scrip that just does:
<jbailey> modprobe -q fan
<jbailey> modprobe -q thermal
<jbailey> It's be simple enough to just add therm_pm72 into there, too.
<jbailey> FWIW, should I also test reboot and try to load the fan module to be sure on that one? =)
<jbailey> My glibc build is almost done.
<BenC> yeah, that would be good
* jbailey tries that  therm test now.
<jbailey> BenC: I'm giving it a moment for the fans to get going so that I can clearly hear tht they've stopped after.
<BenC> ok
<BenC> therm_p72 should be the module
<jbailey> They're usually doing pretty good by about 4 minutes.
<jbailey> yup, that does it. =)
<BenC> fixed it?
<jbailey> Yup
<BenC> sweet, thanks!
<jbailey> Are you going to build it in, or should I upload initramfs-tools with a fix?
<jbailey> The other option is that you can link it in /lib/modules/${VER}/initrd
<jbailey> initramfs honours those too.
<jbailey> But I'd rather see those go away.
<infinity> BENC LIED TO ME.
<BenC> infinity: I'm about 30 minutes from an upload
<infinity> (h is fair, given the number of times I've lied to him..)
<infinity> s/(h/(Which/
<BenC> jbailey: if you could upload it, it would give me more time to get -6.8 out :)
<jbailey> Sure, but since infinity's here..
<BenC> I didn't expect to take this long, had to back out and redo some patches for parisc at the last moment
<jbailey> infinity: You planning an upload in the  next couple of minutes for initramfs-tools anyway?
<BenC> yeah, infinity, initramfs-tools needs to load therm_pm72 for powerpc fans :)
<jbailey> infinity: I was thinking of just stuffing it in scripts/init-premount/acpi =)
<BenC> it's strictly a ppc64 thing
<jbailey> Maybe rename it to heat
<jbailey> We can have ikeaesque names.
* jbailey does Yet Another Build of glibc.
<jbailey> BenC: Are you still using all the space on concordia?
<jbailey> It would probably be handy for me to try this build there, although the changes  are sufficiently non-invasive that I'm not worried about a multi-arch test right now.
<BenC> I should be empty on there...let me do a clean
<jbailey> Thanks/
<BenC> ok, 6.6G free
<infinity> If we want IKEA names, I should make it nonsensical, like scripts/init-premount/jerker or something.
<infinity> "jerker is the name of my desk... I may have purchased it just for that reason)
<infinity> s/"/(/
<mkrufky> BenC: are you 1394 maintainer?
<jbailey> Didn't Jody take that over?
<infinity> Okay, I see two names in scrollback.  Is the module therm_pm72 or therm_p72
<infinity> ?
<jbailey> $ lsmod |grep therm
<jbailey> therm_pm72             36856  0
<infinity> I just uploaded.
<jbailey> infinity: Hey, in terms of testsuites..  Right now I only test the glibc that I absoluely know can be run on every class of machine that might build it.  (Like I run ppc tests, but not ppc64.  However, all our buildds are i686 at least, so I run i386 and i686 tests).  Is it worth putting a hack in there to try and detect if the buildd is actually capable of running a particular test and enabling it?
<jbailey> infinity: Or would you rather that builds be more deterministic than that?
<infinity> Well, the more tests, the merrier.
<infinity> Our buildds are all ppc64, fwiw.
<infinity> I want deterministic BUILDS, but deterministic testsuites don't seem quite as crucial.  Testing based on detection of the metal you're currently running on doesn't seem so horrible.
<jbailey> 'k.  I'll think about that for the next round of retooling, then.
<jbailey> I'm going to actually start checking for regression in the testsuite instead of merely logging what failed, so it's a good time to think about this. =)
<BenC> mkrufky: technically, but I don't really do much with it anymore
<mkrufky> BenC: gotcha.... i only ask because stoth described an obscure 1394 problem to me, i thought u might be interested
<mkrufky> i directed him to #linux1394
<BenC> ok
<jbailey> BenC: I'm afk for about 1h for dinner and hanging out with Angie.  I'll be back after to finish my glibc upload and stuff.  If there's anything you need me to do (test reboots, etc.) I can do them then.
<BenC> ok
* infinity updates madwifi while he waits for the new kernel.
<infinity> I wonder if I should be a do-gooder and make ltmodem build again, too.
<jbailey> woohoo, all the testsuites passed.
<jbailey> Is it expected that the new udev HW detection doesn't seem to find my nic?
<jbailey> BenC: I think that the kernel should fail the install if update-initramfs fails.  When replacing current modules, there's a reasonable risk that if it fails that you have an unbootble system.
<BenC> right now, it fails in postinst if update-initramfs returns an error
<jbailey> Hmm.
<jbailey> So update-initramfs needs to return an error then, I guess. =)
<jbailey> I ha to revert to an old kernel and do a takeover.
<BenC> it does already
<jbailey> It did not as of about 10 minutes ago.
<BenC> atleast it did when I tried installing with an existing initrd there
<jbailey> The -5.7 that's in the archive.
<BenC> hmm
<BenC> the -5.7 you got from me wont
<BenC> the one in the archive _should_
<jbailey> It gave me the message saying that couldn't overwrite it, and then appeared to continue succesfully.
<BenC> oh, weird
<jbailey> I was replacing the -5.7 I got from you with the one in the archive.
<jbailey> So maybe some sort of weird issue with replacing the current version?
* jbailey goes hunting why the new initramfs didn't load therm_pm72 correctly.
<jbailey> Dear infinity:  It's lovely that you've modprobed the thermal module, please also actually include it in the initramfs, kthxbye.
<infinity> Dear jbailey: stop making requests before I've woken up.
<jbailey> I've seen no evidence that you sleep.
<jbailey> infinity: Would you like me to upload an actually tested version? =)
<infinity> A version tested by someone with a ppc64 machine?... That's a novel idea.
<jbailey> glibc is now officially in the "worksforme" category, up she goes.
<BenC> infinity: -6.8 in T-Minus 1 minute
<jbailey> Ahaha, sweet.  glibc and the kernel on the buildds.
<jbailey> QUICK!  SOMEONE UPLOAD X!
<BenC> and gcc :)
<BenC> done
<BenC> jbailey: did I beat your glibc upload?
<BenC> well, the cron will run at the same time, guess linux-source-2.6.15 will become victim to glibc only because of the silly alphabet
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-6.8 uploaded (The "Can it get much better?" release)
<BenC> infinity: *pomp* the ball's in your court now :)
<infinity> No one will be anyone's victim, there's more than one buildd per arch. :)
<jbailey> Well.  Here's hoping that particular crash was random and not my fault.
<jbailey> Xorg spun out.
* BenC is off to bed
<jbailey> g'n Ben.
<BenC> jbailey: any chance you got glibc tested on sparc?
<BenC> did you do any major updates to it?
<jbailey> BenC: I tested it before the last round of changes, but those worked on ppc, i386 and amd64 so I'm expecting it to build everywhere.
<BenC> debian's glibc just got broken for the 64-bit build, and I want to make sure we don't do the same :)
<jbailey> I didn't get nptl on sparc64 working
<jbailey> Nah, I actually test my changes.
<jbailey> The NMU was poorly timed and lartable there.
<jbailey> Although if I could still have access to your machine at some point.  Backporting on a sparc5 is really sucking rocks. =)
<BenC> is TLS enabled for sparc?
<BenC> lol, yeah, after this weekend, I can give out accounts for usage
<jbailey> TLS and NPTL are on sparcv9 and sparcv9b
<BenC> what about 64-bit?
<jbailey> I gave it compiling on sparc64, but segfaulting in the linker. =)
<jbailey> So I stuck with LT for this upload and did the minimal fix to get it building again.
<BenC> cool
<BenC> keep 64-bit the same until fabbione or I hear different from davem, he says TLS is broken on 64-bit
<jb770> Roar
<jb770> This machine seems to crash out x now
<jb770> No idea yet which change is doing it. :(
* jb770 tries the old kernel first
<jbailey_> BenC: So far no X hang when I revert to 2.6.12.  Dunno if that's the new udev or the new kernel though.
<jbailey_> (-5.7)
<infinity> BenC : Any plans to resurrect acx_pci?
<fabbione> hey jbailey_ 
<infinity> jbailey_ : Hahah.  Was that meant to be a subtle joke, or were you having editor woes? :)
<infinity> jbailey_ : (initramfs...ubuntu3 has a debian/changelog.dch.save with a different changelog entry than debian/changelog..)
<CataEnry> hi all
<CataEnry> bye :)
<jbailey__> infinity: *Lol*  I had been originally going to use that as the quote, and decided that I didn't feel that antagonistic.  Then X crashed on me. =)
<BenC> jbailey__: are you running -6.8 now?
<BenC> fabbione: ping
<fabbione> BenC: pong
<BenC> fabbione: -6.8 build on sparc yet?
<fabbione> it's in the queue after perl and glibc
<fabbione> it will take sometime to get there
<jbailey> BenC: No, still -5.7
<jbailey> Actually.
<jbailey> Hmm
<jbailey> No, I'm running 2.6.12 so that my session will stay running.
<jbailey> I'll try -6.8 in a moment. 
<BenC> damnit, I knew glibc would slow me down :)
<fabbione> BenC: glibc will also unleash modular X on sparc, for which we don't have sparc specific drivers
<fabbione> later guys
<BenC> fabbione: later
<jbailey> BenC: Should I try -6.8 and see if it eats my machine?
<BenC> yes, please
<BenC> and reenable hwclock too, if you could
<BenC> wow, I have malone bugs
<jbailey> Yeah, the upshot of having two bug tracking systems is that people use both of them.  *sigh*
<infinity> Most of my Malone bugs have been pretty simple wishlists so far, so I haven't minded.
<infinity> Which is good, cause Malone and I don't get alone yet.
<infinity> a/alone/along/
* infinity gets alone with Malone and shows it a good time.
<BenC> infinity: I think Malone will show _you_ a good time, since you're the one that has to "Submit" :)
<infinity> BenC : I'm off to bed, lrm is waiting in binary NEW.  When elmo gets around to processing it, feel free to do the linux-meta ABI bump again (perhaps confirm with Kamion first that it won't screw his d-i mangling/testing)
<BenC> ok
<infinity> Though at this point in the game, where d-i gets screwed every 5 minutes by some random uploa,d he'll probably say "just do it".
<BenC> is udev done?
<infinity> Define "done".
<BenC> uploaded
<infinity> It's been uploaded several times.  It half works, and is half broken.
<infinity> Yeah, it was uploaded ages ago, and linut-meta was already uploaded for 2.6.15-5... YOu missed that? :)
<infinity> (mdz made the order, despite powerpc being broken)
<BenC> no, I saw that
<BenC> oh, I had missed that
<infinity> So, yeah.  -meta just needs another bump for -6... When LRM gets out of NEW.
<BenC> ok
<infinity> I probably have 2 or 3 more "real" LRM uploads to do this cycle, but the rest I'm going to leave to you.
<infinity> If you want to grab the source and look at the top of debian/rules, you'll see where it automagically figures out kernel versions and such.  ABI dumps are now a matter of changing one integer in debian/rules and adding a changelog entry.  Same as with linux-meta.
<BenC> linux-meta needs a dh compat bump
<infinity> And this concludes me signing off on "make sure Ben's up to speed on being able to update LRM"
<BenC> sweet
<BenC> later :)
<CataEnry> hi all
<jbailey> BenC: I'm on the new kernel, cat'ing that file works, hwclock works.
<jbailey> My fans are behaving with the new initramfs-tools
<jbailey> Now just need to see if X dies on me again. =)
<BenC> nice
<jbailey> Well, 10 minutes of idle didn't kill it.
<jbailey> 'nother 10 minutes under steady usage, no prob.
* jbailey fires up a make -j5 ccache'd glibc build in a visible terminal.
<jbailey> The only other thing I can think of it to surf a couple dozen pr0n pages to test the image cache.
<CataEnry> bye
<BenC> beat it into submission
<BenC> let it know who's boss :)
<jbailey> Right
<jbailey> pr0n it is then. =)
<zul> heylo
<BenC> hey zul
<jbailey> Zool!
<jbailey> BenC: I just passed an hour of uptime.  glibc build going in a window, lots of email, web surfing, openning/closing terminals, etc.
<jbailey> It didn't make it 10 minutes before like this, so I think that -6.8 also solves that.  I think we can stamp ppc64 as gold.
<BenC> excellent! thanks
<zul> must...do...kernel...work...tonight
<jbailey770> Benc: x just died on me.  Anything  i can check before i reboot ?
<CataEnry> hi all
<BenC> jbailey: not sure
<BenC> jbailey: any processes in D state?
<BenC> jbailey: dmesg, "ps axuwww", send me those if you can
<BenC> if any processes are in d-state, send me "cat /proc/<pid>/wchan" aswell
<jbailey770> K
<jbailey770> BenC: i think i narrowed it down a bitmto when im typing alot.
<jbailey770> I don't see anything  in d state.
<jbailey770> Ok to reboot  now?
<BenC> yeah
<BenC> X freezing, mouse still works, I'm wondering if this is a hal problem
<BenC> sounds like some bug reports I've heard about concerning hal
<jbailey770> Well mouse is usually hwcursor isn't it?
<jbailey770> Kill -9 of x gets the rest of the system happy again .
<jbailey> BenC: Fired off the email.
<BenC> thanks
<jbailey> New udev, I'll load that.
<jbailey> BenC: When I look at when it's failed, it's been when I was editting a long changelog entry, doing lots of typing, writing emails, or writing things in RT.
<jbailey> All primarily kbd based.
<BenC> nothing in the process list sticks out, so I can only assume that it's the kernel that starts killing the load
<BenC> all the processes are in sleep except X, so it something in the xserver directly
<BenC> X definitely isn't waiting on something (else it would be in sleep too)
<BenC> hard to say who is at fault
<BenC> wish I had asked you to kill X, and try restarting it, but you can try that later when you have some time
<BenC> oh, nm
<BenC> I see you did that :)
<jbailey> I'm still in 2.6.15, so it's going to recur at some point. =)
<jbailey> Well, I didn't try restarting X.
<jbailey> I typed, reboot, realised that it was going to take forever to do that, and did a kill -9 of X.
<jbailey> It rebooted a moment or two after. =)
<BenC> try "ctrl+alt+backspace" next time if you can, to see if it will restart X by itself
<jbailey> I'd tried that before, it doesn't work.
<jbailey> No keyboard input seems to have any effect, I cannot change VTs.
<jbailey> Although, I could try a chvt from the ssh session.
<BenC> ok
<infinity> Everyone ignore the linux-meta upload I just did.  It wasn't me.  I'm asleep.
<infinity> That is all.
<infinity> Oh, also.
<infinity> BenC : Misdirected complaint...
<infinity> <Keybuk> infinity: linux-doc-2.6.15 conflict/overwrites linux-doc-2.6.12
<BenC> yeah, got a bug report already
<fs> fabbione: ping
<trevilor> hi guys
<jbailey_> Hmm, actually had a real kernel crash that time.
<jbailey_> BenC: No idea what from, nothing in the logs.  I got out of the shower to a machine with the fans going full tilt and not answering pings or ssh
<jbailey_> BenC: Do you have a -6.8 kernel done with gcc-3.4 at all?  I wonder if that would make a difference.
<fabbione> fs: pong?
<fs> fabbione: hi =)
<fabbione> fs: hey dude
<fabbione> i don't have much time now.. we have a meeting in 3 minutes or so
<fabbione> what can i do for you my friend?
<fs> fabbione: do you remember by chance what the amd64-int3-fix.patch in linux-2.6 was for?
<fs> it was added in 2.6.10 along with another couple of patches which where all merged upstream, just this one not
<fabbione> fs: hmm i think i saw it in the Debian kernel, but i did never look at it
<fabbione> or was it in our kernel?
<fs> ok thanks =)
<fs> I think it was in both
<fs> thus the question
<fabbione> i am checking
<fabbione> as soon as my raid will resume from sleep
<fabbione> and somebody will explain me why my disks went to sleep
<fs> btw, do you have a current rediffed version of drivers-scsi-megaraid_splitup.patch or was it dropped from ubuntu kernel too?
<fabbione> fs: it's in git
<fs> heh, asleep raid disks? 
<fabbione> on my workstation
<fabbione> scary
<fs> indeed :)
<fabbione> i just upgraded to 15-rc3
<fabbione> fs: what does the patch patch?
<fabbione> i don't see anything like that in my patch list
<fabbione> perhaps a different name?
<fs> the megaraid one? it lists you as the author =)
<fs> it splits pci ids from newgen and legacy megaraid drivers, so both can be compiled
<fabbione> no sorry i am talking about the amd64 one
<fs> the legacy supports a few old cards the newgen one does not
<fabbione> i know about the megaraid
<CataEnry> bye all
<fs> oh, it adds 2 lines to a case DIE_INT3 in arch/x86_64/kernel/kprobes.c
<fabbione> it's debian specific
<fs> I dropped it for 2.6.14, and it caused no harm so far
<fabbione> lsdiff -H * |grep kprobes
<fs> I just wonder
<fabbione> null
<fs> ok, then I'll remove it
<fabbione> eheh
<fs> thanks man =)
<fabbione> no problem dude
<fabbione> any time
<makx> fs: should be fixed since 2.6.12
<makx> -> http://www.ussg.iu.edu/hypermail/linux/kernel/0503.3/1974.html
<mdz> BenC: #ubuntu-meeting
<fs> makx: looks good, thank you =)
<makx> fs: no thank you dude for going 2.6.15.
<BenC> mdz: already there
<fabbione> BenC: we might not even need or want to merge them, if the packages we have work fine
<BenC> I was thinking that too
<fabbione> we probably want to look at possible kernel-wedge bug fixes
<fabbione> but kernel-package has been taking a direction that we might have problems with
<BenC> yeah, it's been broken up into "module" scripts
<fabbione> yes
<fabbione> we can for sure give it a shot
<fs> interesting how the ubuntu kernel build infrastructure has grown completely different than the debian one
<BenC> fs: git pushed us into a different direction
<fs> fabbione: I searched around in git, you don't have a debian/patches dir anymore? is the megaraid driver split implemented directly in drivers/scsi/megaraid?
<fabbione> fs: what ben sais :)
<fabbione> fs: yes. it's in a git commit
<fs> yeah, looks pretty interesting =)
<BenC> fs: yes, "git-whatchanged <file>"
<fs> especially building the udebs from the same source 
<fabbione> fs: that will never be accepted in Debian
<fabbione> i had that discussion already on debian-boot
<fabbione> when the 2 build systems were closer
<fs> well then, I guess I have to checkout the whole thing
<fabbione> fs: yes...
<fs> fabbione: we had the discussion again a week ago, it soon went a highly emotional way
<fabbione> fs: i am not surprised :)
<fs> maybe if someone makes a decent proposal with some working code, it will be accepted
<fabbione> fs: the code was working... and it still does
<fabbione> it kinda needs to be updated to your new build system
<fabbione> we still use it :)
<fabbione> fs: in regards of keeping 2 different build system i think it's good
<fabbione> fs: we keep developing different bits merging/splitting/remerging and so on
<fabbione> fs: if you look at the history..
<fabbione> we started with the same build system done by herbert
<fabbione> we landed in 2 different places
<fs> yeah
<fabbione> debian did push later (after sarge) in a similar directions that we did already explore here
<fabbione> (build all from one source)
<fabbione> using a different and probably more clean implementation
<fabbione> on my suggestion and discussion with others
<fabbione> Debian did the config. file split/allignement
<fabbione> that now we are partially pulling back
<fabbione> so even if the code is not exactly the same
<fabbione> we rely on the same concepts
<fabbione> and we are both improving by a bit of competition
<zul> who is doing what now?
<fabbione> that imho is very good
<fabbione> zul: what?
<zul> what are you guys on about?
<fabbione> Debian <-> Ubuntu kernel build system sync
<zul> ah ok..
<fabbione> fs: personally i believe we did achieve a lot working this way.. probably more than sharing the same code
<makx> fs: not convinced. ;)
* fabbione takes a smoking break
<makx> ehh upps fabbione. :)
<fs> I guess I need to track your development much closer ;)
<zul> you can start with our git tree ;)
<lamont__> BenC: linux-source-2.6.15 needs to Depend: gcc-3.4 on architectures using 3.4... 
<lamont__> more to the point, linux-source-2.6.12 has this issue, and causes some ftbfs pain
<BenC> only one I know of is hppa
<BenC> which is does
<BenC> *it
<lamont__> see http://buildd.mmjgroup.com/buildLogs/c/cpqarrayd/2.2-1/cpqarrayd_2.2-1_20051129-1652-hppa-failed.gz  
<lamont__> and the last (sparc) build in the same directory
<BenC> linux-source-2.6.15 the .deb, you mean?
<lamont__> --> linux-source-2.6.12 has a bug
<lamont__> yes.
<lamont__> the deb
<lamont__> needs to Depends: $THERIGHTGCC
<BenC> ok, that should only affect hppa
<lamont__> uh... sparc cpqarrayd has the same failure....
<lamont__> gcc-3.4: command not found
<lamont__> ISTR 2.6.12 was all built with gcc-3.4
<BenC> sparc builds with gcc-4, unless fabbione is forcing something
<fabbione> no i don't force anything
<lamont__> cpqarrayd build-depends: linux-source-2.6.12
<lamont__> so that probably needs to change to -2.6.15
<BenC> yeah
<BenC> crappy, I can't do build-dep like arch depends :)
<fabbione> mjg59: ping?
<lamont__> BenC: nope... have to gen them into existance
<dilinger> fabbione: have you got anyone using amd64-k8-smp on dual opterons?
<dilinger> er, for breezy that is
<fabbione> dilinger: no idea, why?
<fabbione> are you going to send me for testing?
<fabbione> actually
<dilinger> hehe
<fabbione> Mithrandir does run that stuff
<dilinger> my machine blows up spectacularly w/ smp
<fabbione> Linux rho 2.6.12-9-amd64-k8-smp #1 SMP Mon Oct 10 13:18:18 BST 2005 x86_64 GNU/Linux
<fabbione> there
<fabbione> it works great here
<fabbione> up to make -j1000 on the kernel
<fabbione> no OOPS or anything
<fabbione> tested on heavy load for about 3 days
<fabbione> it's a 2xdual core amd64...
<fabbione> dilinger: fix your hw :)
<Mithrandir> dilinger: I do, why?
<Mithrandir> on like five different boxes.
<Mithrandir> some dualcore, some just SMP
<dilinger> fabbione: haha, thanks!
<dilinger> it looks like it oops when it switches into framebuffer
<dilinger> so maybe it's a video card thing
<Mithrandir> blacklist the fb module?
<dilinger> is the fb module actually in the initramfs?
<Mithrandir> no idea
<Mithrandir> it probably is
<Mithrandir> remove "splash"?
<dilinger> i already removed splash and quiet
<Mithrandir> but, I'm off to bed.
<dilinger> 'night
<dilinger> oh man
* dilinger gives jbailey a cookie
<dilinger> the initramfs stuff is *so* much easier to understand..
* makx adds an "sacher rote" :)
<makx> s/rote/torte/ # local cake
<dilinger> meh
<dilinger> i can't actually tell what's going on here
<dilinger> and my serial cable is in nyc
<dilinger> damnit
<dilinger> oh well, guess i'll go UP for now
<dilinger> i give 2.6.15 a try, if i get bored
#ubuntu-kernel 2005-12-07
<CataEnry> hi all
<fabbione> Log for successful build of linux-source-2.6.15_2.6.15-6.8 (dist=dapper)
<fabbione> morning
<minghua> my 2.6.15-6.8 kernel finally boots (although with PCMCIA failure), thank you guys for the hard work!
<dilinger> the lustre people are no longer making the free software community wait 6-12 months for a gpl'd lustre
<dilinger> the latest release is gpl'd and available to everyone
* dilinger may need to package that up for debian and ubuntu
<fabbione> hmmm
<fabbione> impressive
<fabbione> against what kernel did they released now?
<fabbione> 2.4.1 ?
<fabbione> ;)
<dilinger> they claim to support 2.6
<fabbione> last i checked it was 2.6.8
<fabbione> and the patches are a real mess
<fabbione> but if you can come up with a decent solution we can for sure look at it
<dilinger> http://www.clusterfs.com/download.html
<dilinger> there's a beta, too
<dilinger> that might support newer stuff
<CataEnry> hi all
<fabbione> mjg59: ping?
<mjg59> fabbione: Hi
<fabbione> mjg59: sorry.. having lunch right.. is it normal that .15 spin down disks that are part of a RAID?
<fabbione> like it's putting all of them to sleep
<fabbione> it does work to access them
<fabbione> they get woken up
<fabbione> but hell
<fabbione> it's slow!
<mjg59> No idea
<mjg59> I'm afraid I haven't looked at the disk code at all
<fabbione> hmm ok
<fabbione> is there a way i can check these events somewhere?
<jbailey> BenC: More interesting randomness on the ppc64.  When a screensaver kicks in, it also hangs X and (it seems) every application running in it).
<jbailey> The apps seems to work well enough that they still run (so my IRC session stayed live), however, all the timestamps in x-chat all say 7:54, when I unfroze it.
<jbailey> To unfreeze, all I had to do was kill the screensaver.
<jbailey> Mmm, no.  The applications really are locked.  OFTC does an irc ping, and it lost its connection.  Freenode doesn't seem to, and it stayed live.
<jbailey> So I'm guessing kernel TCP handling works, applications just buffer.
<BenC> jbailey: I've experienced that with my G4, even on breezy, especially GL screen savers
<jbailey> Interesting.
<jbailey> It's new here for me.
<jbailey> Are you using hardware accelleration on your G4?
<jbailey> It's not supported on this video card.
<BenC> stock install, so whatever it decided to activate
<BenC> the GL is really slow, so I don't think it has any accel
<infinity> It won't.
<zul> morning
<BenC> hey zul
<infinity> Well, if it's a really old ATI (Radeon 9000ish), it will have a bit of accel, but not enough make you care or go "wow".
<fabbione> hey BenC 
<fabbione> 6.8 is in the archive
<jbailey> fabbione: Wow, glibc, kernel.  All you need is X and you're playing with the big kids again..
* jbailey hides
<jbailey> =)
<BenC> yo fabbione
<BenC> it's a Rage 128 Pro
<BenC> so it's even older :)
<infinity> I don't think we have accel on Rage128, but I can't be positive.
<infinity> Pretty sure not, though.
<fabbione> jbailey: i am choaking gcc-3.4 and 4.0 now.. it will take a while to get there
<infinity> (3D, that is, we have plenty of 2D accel on the whole 64/128 family)
<infinity> fabbione : Did you NFU LRM again, or is it just down in the queue?
<fabbione> infinity: no, it's in the queue.. it took a while to get the binaries NEW'ed for the b-d
<infinity> Ahh, right.
<BenC> so lrm/linux-meta/udev is all good now, right?
<infinity> For everything but sparc and hppa, yes.
<infinity> Of course, you'll break it with your next upload again, Captain ABI-bump-on-every-upload.
<infinity> (We're going to ship dapper with 2.6.15-37 or something, aren't we?) :)
<jbailey> RH does.
<jbailey> We're just catching up with them. =)
<BenC> yes we are :)
<BenC> actually, I was hoping to pull in all the abi's this time and start actually checking for when we need an abi bump
<BenC> but I accidentally disabled the script that copies the ABI's into the .deb's
<fabbione> LOl
* fabbione scratches BenC's head with a spoon
<BenC> I even wrote a nice little script to download all the abi's and put them into the git tree, but it kept saying "NO ABI FILE"
* infinity claps.
* BenC takes a bow
<infinity> So, who feels like some online poker?
<fabbione> hmmm
<BenC> ooh ooh, I do, I do :)
<fabbione> not a bad idea :)
<fabbione> BenC: is your client/server ready for testing?
<infinity> fabbione : Good, play with BenC, it'll make him feel better. :)
<fabbione> infinity: ahahah like if i don't know Ben is a player
<BenC> fabbione: I stopped working on it when I started with canonical
<BenC> I still have all the code, maybe one day I'll finish it
<fabbione> make it a kernel network protocol
<fabbione> poker.ko
<BenC> modprobe texas-holdem
<fabbione> ehehe
<infinity> Oh, it's still Friday for you guys, I should stop being offtopic.
* infinity gets out of weekend mode for the greater good.
<BenC> lol, yeah, I just work up :)
<BenC> woke up
<BenC> and haven't had any coffee yet, as if my typing isn't a good sign of that
* BenC is finally upgrading all his machines to dapper
<jbailey> I wanted my brother-in-law play texas-holdem online at pokerroom.com for for like 8 days.
<jbailey> It's how he wanted to spend his vacation time in Montral.
<fabbione> infinity: you know... i have already done 7 hours today.. i could stop just 40 minutes ago
<jbailey> fabbione: You get 6 hour days under .dk law, too?
<fabbione> 7
<fabbione> i started at 6
<jbailey> Bastard.
<fabbione> 6 + 7 = 13
<fabbione> it's 14:40
<fabbione> considering i did jerk a bit around + lunch..
<fabbione> i am done
<infinity> .dk law allows you to "jerk around" at work?
<infinity> I'm moving.
<fabbione> infinity: no.. that's why it's 8:40 that i am around
<BenC> jbailey: while unemplyed, I turned $100 into $9400 in 8 days on doylesroom.com
<BenC> too $9000 out and lost the $400 playing tournaments
<infinity> (And the lost it a week later)
<infinity> s/the/then/
<BenC> ...and then put the $9000 back in and lost it, yes :P
<BenC> haven't taken the time to play high stakes like that again
<jbailey> *lol*
<jbailey> I so wanted to convince him to stay for the conference.  I was pretty certain there'd be poker players there.
* BenC has a trip planned for Atlantic City in February for the World Series of Poker Circuit events
<jbailey> He never found a poker room here in Montral.
<infinity> BenC : Planning on being on TV?
<BenC> jbailey: me either, I went to Casino De Montreal, and they had nothing
<BenC> infinity: I'm only playing the $500 tournament, but if I can win enough there, I will play the televised $10,000 tournament
<zul> BenC: the nearest legal poker rooms you are going to find are in cornwall
<jbailey> Is the $500 tourney prize a free invite to the higher level one?
<BenC> last $500 tournament I played back in August, there were 1180 people, and I lasted for 12.5 hours and went out 97th
<jbailey> zul: Is poken Illegal in Montral?
<zul> i dont think so...but the casinos are government run 
<BenC> jbailey: $500, first place is usually like $75,000 - $200,000 depending on how many people sign up
<zul> and its like a franchise ;)
<BenC> I was told they weren't legal in MOntreal _yet_
<BenC> poker that is
<BenC> which is odd, because all the games that are legal in the casinos are just gambling, poker atleast has some skill involved
<jbailey> Right.
<jbailey> They have video slot terminals here.
<jbailey> What gets worse than that?
<zul> its legal in cornwall apparently ;)
<BenC> I saw a thing on discovery about how terrible the RNG's are in those computerized slots
<BenC> a guy that worked for the gamin commission figured out how to get 33-1 odds to win kino (which is like the lottery)
<jbailey> Kino is that thing where the numbers just appear on the board.
<jbailey> Like a Lotto game every 6 minutes?
<BenC> yeah
<jbailey> I played that for an hour once.
<BenC> but they don't use balls, just a computer
<jbailey> A byunch of coworkers and I went.
<jbailey> Sure, they have terminals all over in Vancouver.
<jbailey> They're all centrally done, so like any corner store will have them.
<BenC> crazy
<jbailey> We were bored, it was wet out, had $20 burning a hole in my pocket, so we decided to go burn it. =)
<BenC> and burned it you did, I bet :)
<jbailey> Yup!
<jbailey> But that's how I always gamble.
<jbailey> I start out with an amount of money I want to lose.
<jbailey> And then I play until it's gone.
<jbailey> I'm not generally satisfied if I walk out of the casino with it in hand.
<jbailey> It also means that I never have thoughts of "one more pull", or anything like that.
<jbailey> If I have the money, of *course* it's one more pull.
<jbailey> If I had gone out to a bar or a movie or whatever, I wouldn't have any left, so sitting around a blackjack table with friends is just another night out.
<BenC> yeah, that's a good way to look at it
<zul> they had slot machines at the hotel in montreal
<jbailey> Slot machines aren't social.
<jbailey> That's why the kino was at least fun.  We all sat around the machine picking numbers and talking about probability distributions, stats and game theory.
<jbailey> A perfect geek lunch. =)
<Mithrandir> BenC: linux-doc-2.6.15 needs to conflict with linux-doc-2.6.12.
<BenC> yes, already done in git
<Mithrandir> coolie
* ..[topic/#ubuntu-kernel:jbailey] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-6.8 uploaded (The "Can it get much better?" release) | MOSTFREQ reported bug: linux-doc-2.6.15 needs to conflict with linux-doc-2.6.12.
<BenC> actually now, it c/p/r linux-doc-2.6
* BenC loves satsifying a bug report without actually doing what everyone says he needs to do
<Mithrandir> haha
<infinity> BenC : Hrm, I thought the linux-doc packages were supposed to install everything to /usr/share/doc/package-version?
<infinity> Why should they need to conflict?
<infinity> (Not that there's much value in having multiple cversions installed anyway)
<Mithrandir> infinity: man pages.
<infinity> Ahh, right.
<CataEnry> bye all
<BenC> can anyone see a reason for enabling USB network devices for our server class kernel?
<BenC> IMO, I can't think of anything we need USB for servers other than HID/kbd/mouse and mass-storage
<jbailey> BenC: Mmm..  What do you define as a server?
<jbailey> BenC: I know of a number of places that use laptops for their servers.
<jbailey> gives the nice advantage that you can take it home at the end of the day and there's no risk of it getting stolen.
<BenC> jbailey: servers being things that you install and never move again :)
<BenC> like NUMA systems and such, 8-way xeon, 32GIgs ram, etc.
<jbailey> Also, it's not unreasonable to start thinking of just doing wireless on the whole network.  USB wireless is better than PCI wireless because you can move the antenna around.
<jbailey> Hmm.
<jbailey> We should be clear that server doesn't mean "file server" or "print server", then.
<CataEnry> hi :)
<BenC> I'm talking about servers where you generally have GigE to the data warehouse for your content management system
<BenC> jbailey: this kernel probably wont boot on a P4, because of the kernel config it is using
<jbailey> Right, but SMEs still have things that they call servers.  We need to make sure that they don't install the server edition then.
<BenC> this kernel is mainly going to be for our server certification program, where we are supporting known macines from known vendors
<jbailey> Sure.  But we shouldn't call it our server release.
<jbailey> It should be high end computing or something like that.
<BenC> well, I'm using the names in the specs :)
<jbailey> Which spec?
<BenC> ...
<jbailey> I just want to make sure that we don't forget that there's a whole class of SME folks who need to be functional and may install these if they look tempting.
<BenC> ubuntu-server-kernel and testing-server-hardware
<jbailey> Ah, KernelServerRoadmap
<jbailey> Ah, you're registrant, assignee, and drafter, with fabbione approving.
<jbailey> When he's back, maybe I can pitch my thoughts to both of you. =)
<BenC> ok :)
<BenC> since you're the one that handles a lot of these type customers, then your input is very much needed
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-6.8 uploaded (The "Can it get much better?" release) | MOSTFREQ reported bug: linux-doc-2.6.15 needs to conflict with linux-doc-2.6.12 | MOSTFREQ response, "so?"
<BenC> jbailey: any word for the customer with the acl880?
<jbailey> BenC: None yet.
<BenC> are they going to test -6.8
<BenC> ?
<jbailey> I've asked them to.
<BenC> ok
<jbailey> They're an email-based customer, and in .nl, so there's a bit of a lag in the conversations.
<BenC> ah
<jbailey> I can see some screensavers fine, it's just after a while that they die.
<jbailey> I wonder if it's when it's trying to do a DPMS shutdown.
<jbailey> I should try your suggestion and drop the use of the FB.
<jbailey> I'll do that next reboot.
<jbailey> BenC: Fabio can do 20UTC on Monday for talking about it.  Will you be around then?
<BenC> yeah
<mkrufky> in which chatroom is it appropriate to ask about ubuntu .deb packages?
<mkrufky> (i dont want to bother u guys)
<BenC> depends on the question, either #ubuntu-user, or #ubuntu-devel
<mkrufky> ah, ok thanks
<mkrufky> #ubuntu-user[s]  empty
<zul_> jbailey: ill be around as well so i can listen in
<jbailey> zul_: Cool!
<CataEnry> bye
<zul_> blah
<BenC> dpkg-deb: building package `linux-image-2.6.15-7-server-generic' in `../linux-image-2.6.15-7-server-generic_2.6.15-7.9_i386.deb'.
<BenC> yummy
* BenC wonders if it will boot on his P4
<BenC> lamont__: ping
<BenC> lamont-away: ping aswell
<lamont__> heh
<lamont__> sup?
<BenC> lamont: hey, what was the issue booting initramfs on ia64?
<BenC> because I just booted my i2k with an initrd generated with update-initramfs
<BenC> or maybe I didn't...you have to rerun elilo even when changing the initrd...
<BenC> let me try again
<BenC> lamont: that elilo thing is going to be an issue when ia64 switches to update-initramfs
* BenC wonders if we are going to need to break out the kernel-package boot-loader update stuff into another script
<BenC> like update-bootloader
<chuck> BenC: question for you...was there any talk about having kernels in universe. i was reading an old meeting agenda on the wiki
<BenC> a little, but nothing has come of it that I know
<zul> okie dokie
<zul> because i need to get involved again since this project at work is coming to an end, thank god
<BenC> hehe
<zul> anyways im going home...toodles
#ubuntu-kernel 2005-12-08
<makx> BenC: reading through udev diffs i see your modular udev usage
<makx> any reason why your keeping that modular?
<lamont> BenC: elilo is broken.  sub-problem: elilo is ftbfs with current binutils
<lamont> I'm working on that thing
<makx> there also seems races mentioned in autoloading 'unix'..
<BenC> makx: I don't do udev
<BenC> Kamion does udev
<makx> yeah but you do .config CONFIG_UNIX=m
<BenC> yes, we always have
<BenC> lamont: so newer elilo will get initramfs working?
<makx> cache line bounces..
<BenC> is there an actual problem, or just theory? :)
<makx> we'll see ;-)
<lamont> BenC: new elilo and a few other kernel fixes that already went into 2.6.15 (iirc), yes.
<BenC> breezy's unix.ko is modular, and I'd be willing to bet hoary is too
<lamont> new elilo may require new gnuefi as well, but that's where I'm currently floundering
<BenC> lamont: is the elilo source in the archive?
<lamont> yes
<lamont> but ftbfs
<lamont> binutils got more pedantic.
<BenC> what exactly is gnuefi?
<BenC> lamont-away: ?
<jbailey_> BenC: I've got the UseFB turned off now, I'll let oyu know how it goes.
<jbailey_> I did a strace chvt, and it hangs in the middle of an ioctl.
<jbailey_> I did an strace -p on the running X server, and it's not making any syscalls at all.
<jbailey_> Even though I did see two signals sent to it.
<BenC> ok, next time "cat /proc/<pid>/wchan of the X process
<jbailey> 'k
<jbailey> What's that file?
<jbailey> When I look at the current one, I don't understand the contents.  It looks like the start of the data segment.
<BenC> it's the function in the kernel where the process is
<jbailey> Ah, cool.
<jbailey> BenC: It was either in ,__start or .drm_compat_ioctl
<jbailey> It flipped between the two.  I did about a dozen cats.
<jbailey> This time I tried just kill -9'ing the X server after that.
<jbailey> gdm restarted.
<BenC> did everything work after that?
<jbailey> I'm on that session now.
<BenC> drm_compat, huh
<jbailey> It's wroking well enough to x-chat, anyway.
<BenC> sounds like drm compat ioctl's might be behind the actual drm ioctl's
<BenC> the compat is for conversion between 32-bit userland and 64-bit kernel ioctl's
<jbailey> Ah, so it's basically a thunk?
<jbailey> JaneW: Aren't you supposed to be asleep?
<BenC> and if something in the kernel/userland changed, and the compat doesn't know about it, then it might cause problems
<BenC> yeah
<jbailey> Anything for me to look at next time around? =)
<jbailey> I guess for kicks, I could try a 32 bit kernel.
<jbailey> BenC: Is this still an -rc1 kernel, or are you tracking upstream?
<jbailey> Hmm,. and my sparc box was hung.
<jbailey> Maybe it's just a bad day to be in my computer room
<BenC> jbailey: no, it's -rc3+some
<jbailey> linux-meta points to 2.6.16-5 on sparc instead of -6.
<BenC> weird
<BenC> sparc needs to build it still I guess
<BenC> lamont-away: ping
<jbailey> I didn't think linux-meta had ever pointed to -5.
<BenC> yeah, infinity uploaded prior to -6 at mdz's urging
* jbailey fires up -6 on the sparc to see if it fixes the gdb hangs that he had on 2.6.12
<jbailey> rtc_init: no PC rtc found
<jbailey> Kenel panic.
<BenC> panic?
<jbailey> That would be a 'no', I guess. =)
<BenC> the RTC thng I get too, but it still boots
<jbailey> Hmm, unable t mount root.
<BenC> do you have it on quiet?
<jbailey> Maybe it's a different thing.
<jbailey> Yeah.
<jbailey> Lemme see if I can get the old kernel running. =)
<BenC> "old" should work
<jbailey> bah, stop-a isn't working.
<jbailey> It should, assumingI got my silo.conf right.
<BenC> you're lucky, it doesn't take 2 minutes to soft-boot and 6 minutes to hard-boot your ultra :)
<jbailey> I did this install by hand froma debootsrap off of an old rescue CD. =)
<jbailey> Bah, I did make a typo.
<jbailey> *sigh*
* jbailey tries to recover anyway.
<BenC> nah, just do "/boot/vmlinuz.old initrd=/boot/initrd.old root=/dev/xxx"
<jbailey> Ah, I didn't know you could pass initrd on the cmmand line there.
<BenC> yeah, silo parses it out and loads it
<jbailey> I wonder if my sparc is just broken now.  I've gotten two data access errors and it just hung during Uncompressing Image.
<jbailey> Or if power's bad here in the winter.
* jbailey uses the rescue CD.
<jbailey> There we go, silo changed to say vmlinuz instead of vmlinux
<jbailey> And it's booting on old.
<jbailey> BenC: Why does your box take so long, SCSI arrays?
* jbailey wants to find a nice little sunfire workstation.
<jbailey> Interesting, this kernel just hung with a TRAPLOG message.
* jbailey reboots again.
<jbailey> Hmm.  When I run silo, it doesn't actually check to see if the files exist, doe sit?
<jbailey> BenC: Looks like it was my bad.  I screwed up the link to initrd.img
<BenC> jbailey: the UltraEnterprise systems have a hell of a POST
<BenC> jbailey: ok, so it boots and all?
<jbailey> Yup
<jbailey> I'm in 2.6.15-6 now
<jbailey> Oh, hmm.
<jbailey> This new kernel doesn't seem to pick the network card on the scan.
<jbailey> I have two nics in here.
<jbailey> It's seeing the 3c59x fine
<jbailey> Not the onboard.
<jbailey> And apparnetly hitting ctrl-alt-delete hung it.
<jbailey> Perhaps I should just throw it out the window now? =(
<jbailey> Is there an easy wya to see which driver is associated with with eth interface?
<jbailey> It looks like the bus scan is seeing both a tulip and a 3c59x
<jbailey> (in both 2.6.15 and 2.6.12)
<jbailey> But one of them isn't producing an interface in 2.6.15
<jbailey> Ah, dmesg - looks like sunhme
<jbailey> Hmm, no it's showing up as eth2.
<jbailey> Ah, I see.  It didn't see it before beacuse I was using ifup, which needs configury in /etc/network/interfaces
<jbailey> So the detection order has changed.
<BenC> ah
<BenC> yeah, iftab problem
<BenC> plus, if you upgraded udev so that hotplug is gone, the hotplug thing in /etc/network/interfaces appears to not work anymore
<jbailey> Yeah, did that.
<jbailey> BenC: Anyhow, thanks.  Anything else you want tried on the ppc box?  sparc is now building gdb for me to do my hacking there.  I'll let you know if I still get full hangs when debugging. =)
<jbailey> Otherwise I'm starting to look at biarch gdb for sparc.
<BenC> ok
<BenC> nothing I can think of right now
<BenC> if you have problems with 64-bit gdb on sparc, let davem know (or me and I can relay)
<jbailey> 32 bit gdb was hanging my box solid before.
<jbailey> But I'm hoping 2.6.15 will make that go away.
<jbailey> If you're just going to relay, I can catch him on irc - are you interested, though / do you want to be cc:'d?
<BenC> interested, but you don't need to keep me in the loop
<BenC> just the outcome is all that's important :)
<jbailey> BenC: Killing the Xorg daemon a second time works, so whatever it is, it doesn't seem to be chewing up all the resources in the kernel in a hurry.
<BenC> strange bug
<jbailey> I've tried to take a picture of the kernel message to the screen where the sparc box hung.  I suspect this box is just fubar, maybe.
<BenC> usually I would expect a bug in the kernel that affected X like that, to atleast put the X process into D state
<jbailey> It looks like line noise, follow by a struct dump
<BenC> can you get a serial console on it?
<jbailey> Assuming my laplink cable isn't dead, yet.  I bought one before UBZ, but when we tried to use it there, it didn't seem to work.
<jbailey> But the a500 we were testing was also dead, so it's hard to tell which parts weren't working. =)
<jbailey> I've also taken 'quiet' off of the kernel command line now, so next time I might get a better dump
<BenC> the a500 has a screwy serial port (it's actually 3-in-1), hopefully the sparc is ok with it
<jbailey> The a500 wasn' posting at all.  The SCSI card wasn't even init'ing the drives.
<jbailey> Bah, the sparc didn't make it long enoug to finish my gdb package.
<jbailey> Mmm, nice the testsuite resumed.
<BenC> weird, the GSP console should work even when power is off (it's a completelt seperate system
<jbailey> Yeah.  Grant suggested that it might have been the power supply itself that went.
<jbailey> There seem to be a whole pile of dejagnu failures.  Do you know if anyone actively looks at sparc-linux gdb, or is it just something davem and a few people do in their spare time?
<jbailey> Wow, long scroll.
<jbailey> The oops went on for 6 or 7 pages.  I will need to hook a serial console up to catch it.
<jbailey> Nice to see it out of quiet mode though.
<jbailey> I'll wire that up tomorrow.
<BenC> lamont: hey
<lamont> yo
<fabbione>  hey BenC 
<BenC> hey fabbione
<BenC> lamont: The version of elilo on ports.u.c seems to be the same version as the .deb
<lamont> right
<BenC> lamont: how is rebuilding it going to get initramfs working?
<lamont> binutils was upgraded after it built
<BenC> so initramfs not working is bintutils related?
<lamont> it won't - it needs a new upstream.  upstream is working with me on getting it to compile again
<BenC> I got it to compile
<lamont> no.  initramfs not working is an elilo bug.  elilo not building is related to binutils being more pedantic now
<lamont> on current dapper?
<BenC> new yes
<lamont> woot
<lamont> with current gnuefi?
<BenC> I fixed some assembly bugs (.endp and such), and then copied the linker script from the newer gnu-efi (to DISCARD IA_64.unwind symbols)
<lamont> send me your patch please
<BenC> newer gnu-efi is probably a 20 linue diff
<BenC> ok
<lamont> I'll push it to upstream on monday (he sits across the building from me..)
<lamont> and then he'll upload to debian, and we'll sync, and all will be love.
<fabbione> mafia :)
<BenC> any chance I can get his patch for elilo+initramfs to test?
<lamont> monday
<lamont> I don't have iut
* lamont pings him in the work channel just in case he shows up today
<lamont> back in a while
<BenC> ok, I'll send you a patch for gnu-efi 3.0a's linker script, and then a patch for elilo's ia64/{set,long}jmp.S assembly
<trevilor> hi guys
<lamont> BenC: thanks.  (although I had the assembly stuff done - was working on time to hack gnu-efi)
<jb-home> BenC: Around?
<BenC> yeah
<BenC> lamont: booting with the rebuilt elilo doesn't work
<BenC> lamont: it shows "Starting Ubuntu" and goes back to the efi menu
<BenC> jb-home: yeah
<jb-home> BenC: I'm playing more on the sparc box - I've got the serial console wired up.
<jb-home> When rebuilding gdb, it seemed to hang it, no output to the serial port at all.
<jb-home> When I rebooted, I had a whole pile of bus errors.
<BenC> break signal doesn't get it out to OBP?
<jb-home> Is there any chance this is something other than hardawre?
<BenC> bus errors?
<jb-home> Nope, no response on the keyboard at all.
<jb-home> Lemme fetch the log off of the laptop.
<BenC> are you running latest things like libc6 and such?
<jb-home> Yup, up to date dapper
<jb-home> [   10.201895]  SABRE0: PCI SERR signal asserted.
<jb-home> [   10.412781]  SABRE0: PCI bus error, PCI_STATUS[83a0] 
<jb-home> repeat until
<jb-home> [   16.953369]  SABRE0: PCI bus error, PCI_STATUS[83a0] 
<jb-home> [   17.178580]  SABRE0: PCI SERR signal asserted.
<jb-home> Then the timer reset to 0
<jb-home> It got up to 16 a second time, reset to 0
<jb-home> Then then went for another 2.5  seconds.
<jb-home> http://people.ubuntu.com/~jbailey/minicom.cap
<mjg59> Can I shove some more drivers in l-r-m?
<jb-home> mjg59: I may pout if they really suck to support.
<BenC> jb-home: that really looks like hardware
<jb-home> I've been wondering if we need to have two l-r-m's.  One for restricted, one for multiverse.
<mjg59> jb-home: Modem drivers
<BenC> sabre, what type of ultrasparc is that
<jb-home> BenC: How do I tell?  It says Ultra 5 on the front, and has the usual compaq grey casing.
<BenC> that's all I needed to know
<BenC> Ultra IIi
<mjg59> Wow. That one actually built against 2.6.12.
<BenC> IIi has PCI built into the CPU
<jb-home> mjg59: Modem drivers probably should go in there.
<jb-home> Especially if they're for an iBook.
<jb-home> *sigh*
<mjg59> jb-home: I can't remember what the iBook has, but I have a feeling it's weird conexant shit
<mjg59> jb-home: We have two choices there:
<BenC> jb-home: at the OBP prompt try "probe-pci-all" and "test-pci"
<BenC> or "test pci" can't remember which it is, but "help test" might tell you for sure
<jb-home> ok probe-pci-all
<jb-home> probe-pci-all ?
<mjg59> 1) We ship the Linuxant drivers which are limited to 14.4bps unless you pay them
<mjg59> 2) We ship the older versions of their drivers, which are GPLed (except for the closed bits). The license allows redistribution. We have to forward-port to 2.6.
<BenC> lamont: I'm trying to setup my i2k so that EFI is on the serial console, and I get output, but I can't seem to find the right baud rate
<jb-home> test pci, Device pci not found, help test, No help available for test.
<BenC> EFI says 115k, and I have my serial setup at 115k, but it isn't working (shows garbage)
<jb-home> BenC: IIRC, It's 19200 on my ia64.
<jb-home> And E71 or something like that.
<BenC> E71? weird, EFI says 115xxx,8N1
<jb-home> Might have just been the way mine was setup.
<jb-home> It took me a couple goes to get it right, though.
<BenC> it wont let me change it, so I guess it's hardcoded
<jb-home> mjg59: Are the closed bits actually just loaded firmware, or are they things that might need updating?
<mjg59> jb-home: They're basically chunks of the Windows driver
<mjg59> Hang on, let me find you a URL
<BenC> that got me garbage too
<mjg59> There's a more recent version of the ltmodem driver, too
<jb-home> mjg59: What do you suggest?  I don't really know anythign about it.
<jb-home> Just that I've had two people ask me about whether we support modems on iBook.  Not even a statistic. =)
<mjg59> Ah, hmm.
<mjg59> The iBook (it seems) has USB Conexant stuff
<BenC> this serial console is pissing me off
<BenC> the EFI says it is 115384 (not 115200) and 8N1
<BenC> 115200 8N1 shows me garbage, even tried switching on/off the hw and sw flow control
<BenC> time for google I guess
<BenC> jb-home: did you have to use a null modem connector for your i2k?
<BenC> there's a good reason
<BenC> my e3k's serial port cannot be set to 115200
<jb-home> BenC: I don't thin so.  Besids, if you needed a null, you wouldn't get any garbage at all from connecting tx to tx, rx to rx.
<BenC> you're right, just grabbing at straws, but now I'm sure it's just a matter of not being able to set my ultrasparc port to 115200 (where I'm running minicom)
<lamont> 9600 or 19200 is pretty normal - that or autosensing
<zul> heylo
<zul> BenC: sata and ata cdroms broke in 2.6.15?
<BenC> I've seen one report saying such
<zul> yeah looks there is a module param called atapi_enabled now
<BenC> the one report I saw looked more like a resource conflict, possibly with ide-generic
<zul> looks like the behaviour changed in 2.6.13
<BenC> did you test this param?
<zul> no i dont have sata at home, ill test it at work when i get into work tomorrow
<zul> http://www.ussg.iu.edu/hypermail/linux/kernel/0508.3/1620.html
<zul> there isnt a #define ATA_ENABLE_ATAPI anymore
<zul> ill upgrade my computer tomorrow and see what breaks...yeehaww :)
<BenC> ah
<BenC> does PATA handle things where atapi_enabled was needed?
<zul> not sure...still looking
<BenC> the libata-dev merge I just did included 4 or 5 new PATA drivers
<zul> accroding to this wiki page im looking at configure the sata system as built-in and add libata.atapi_enabled=1 to the kernel command line
<zul> uh...wait..
<zul> modprobe libata apatpi_enabled=1 should work as well
<BenC> yeah, for our kernel, you need the modprobe
<BenC> so I'd add it in /etc/mkinitramfs somewhere
<zul> get the guy on the kernel mailing list to do it
<BenC> the atapi_enabled=1 param that is
<BenC> ok
<zul> stupid xchat
<zul> im emailling the list right now
<BenC> just did
<BenC> I wonder if the ATAPI support is stable enough for us now
<BenC> to be enabled by default I mean
<zul> i can test it
<zul> ill be back later
* jb-home catched up on backscroll.
<jb-home> BenC: So s the idea that ide-generic finally goes away and we get libata instead?
<calc> does sata/libata finally support smart yet?
<BenC> yeah, the sata passthrough supports smart now
<BenC> jb-home: legacy IDE needs ide-generic, IIRC
* BenC is happy yo get his 19" lcd panel back
<BenC> that 15" was getting old
<fabbione> i am happy with my 3x21" ;)
<fabbione> CRT tho...
<fabbione> have a nice day guys
<fabbione> cya around
* BenC hugs 1280x1024, my long lost friend
<CataEnry> hi *
<CataEnry> good night all :)
<dilinger> hm
<dilinger> libata finally supports smart ioctls?  as of when?
<dilinger> 2.6.12 certainly doesn't :(
#ubuntu-kernel 2005-12-09
<dilinger> BenC: libata supports smart ioctls?  as of when?
<dilinger> also, has anyone done any reverse engineering of win32 drivers?  what do people recommend for disassembly (and if something exists, decompilation to something resembling C)
<BenC> dilinger: libata passthrough patch went in during last month of breezy
<infinity> BenC : I'll fiddle with initramfs and the above-mentioned libata modprobe argument, since I'm one of the people who whined about his disappearing CDROM.
<infinity> (The resource conflict with ide-generic thing is a red herring, BTW, 2.6.12 gave the same output.  It's the 5 or 6 lines BEFORE that that went missing that are important)
<infinity> Of course, given our focus as a desktop OS, it may be in our best interest to just hack our kernels to always turn that flag on in the driver, and not mess with it in initramfs.
<infinity> (We can revisit that the day someone complains that ATAPI is always on)
<dilinger> BenC: oh
<dilinger> BenC: you mean went into breezy or upstream?
* dilinger is using a backported debian 2.6.12 at work, no libata smart ioctl passthrough there
<dilinger> but i haven't tested the amd64 breezy machine i just installed
<BenC> infinity: that's what I'm thinking too
<BenC> dilinger: breezy, it's in 2.6.15
<infinity> BenC : Well, I'll do some quick reboot testing and verify that this really does bring my drive back from the dead, and if so, we can decide which direction to go with it.
<infinity> I assume it'll work, though.
<BenC> infinity: worked for a guy on kernel-team list
<BenC> I'm trying to catch jgarzik to see how stable the sata atapi code is right now
<infinity> Oh, you've already pinged him with the fix?  I only saw his message with dmesg output, etc... Nothing else.
<infinity> The only danger seems to be in having libata drive really old PATA ATAPI devices over an SATA->PATA bridge, which seems a pretty unlikely combination to me.
<BenC> yeah, I redid my email client, and got moderated to the list
<BenC> but he got my email and replied
<infinity> Ahh, cool.
<BenC> jgarzik says sata_promise and sata_sx4 are known to not work with atapi
<BenC> the drivers that is
<infinity> Well, that sort of leaves us at an impasse.
<BenC> I'm going to blacklist those two drivers and set atapi_enabled=1 by default
<infinity> Those two drivers are kinda popular. :/
<infinity> (not as popular as piix or via but still)
<mjg59> infinity: I've found various drivers that probably ought to be in l-r-m
<infinity> You mean stuff that should be removed from the kernel, or stuff we don't yet ship?
<infinity> (speaking of the latter, I need to make ltmodem build again)
<mjg59> infinity: Stuff we don't yet ship
<mjg59> Modem drivers (hahaha)
<infinity> Mmkay.
<infinity> More ltmodem-like crap?
<mjg59> Intel ones for a start
<infinity> Why can't we just finance a worldwide effort to get broadband to everyone's house?
<mjg59> There's one for the 536 and one for the 537
<mjg59> The 537 one looks like it needs light hacking to get it to work on recent 2.6, the 536 one looks ok
<mjg59> But they're both 2.6 compatible
<infinity> You do the light hacking required, and I'll happily include them.
<mjg59> I'm also looking at the old (GPLed) Conexant drivers
<mjg59> They involve rather more pain
<infinity> I want, bsically, upstream tarball, + your patches in a diff.
<mjg59> Oh, when I say GPLed, I mean "GPL + closed shit"
<infinity> The conexant stuff looked scary.
<mjg59> The conexant stuff scares the shit out of me
<mjg59> I'm trying to forward port the last release of it to 2.6
<mjg59> Sorry, the last free release
<mjg59> It still looks scary, but, well
<infinity> We don't even attempt to support modems/ppp in d-i as a network method, right?
<mjg59> Nope
<infinity> So these don't need to hit a udeb, just the main LRM deb...
<infinity> Good.
<infinity> Well, if you make the intel stuff work and I make the ltmodem stuff work, we've suddenly got coverage of a crapload of softmodems.  The conexant stuff would be a nice bonus, though.
<infinity> Personal anecdotal statistical analysis, and some really bad math would lead me to eblieve that 8 out of 5 people have an LT-based softmodem somewhere in their house.
<mjg59> Yeah
<mjg59> I've got at least one
<mjg59> Most of them are slmodem-compatible now, though
<infinity> Of course, I haven't actually used a modem in Linux since, like, 1995.
<infinity> Perhaps this makes me an ideal candidate to test this stuff and see if it's foolproof.
<mjg59> Modern hardware is almost all AC97. Of that, pretty much everything uses a smartlink-compatible codec except for ones which use Conexants
<mjg59> Oh, and Apples, which use some horrid USB conexant thing
<infinity> Well, enough people have complained about ltmodem going away that I assume someone still needs it.
<infinity> Anyhow, a fork that builds on moden kernels has been pointed out to me, so I'll re-enable it and close the bugs, and not care much about the particulars. :)
<infinity> Whatever you want in LRM, though, just get me upstreamish source (with an upstream URL of sorts), plus your patches to make it function, and I'll integrate it.
<infinity> And make sure we can distribute it, of course.
<mjg59> Oh, sure
<infinity> BenC : Kay, just tested with "break=premount && modprobe libata atapi_enabled=1 && exit", and the resulting boot had my CD/DVD drive too.  Yay.
<infinity> Of course, I still don't have a /dev/dvd, but that's probably something I can blame on Keybuk.
<infinity> Hrm.
<infinity> WEEKEND OFFTOPIC QUESTION:
<infinity> Does anyone know how to force my DVD drive (or software player) to pretend to be in a specific region?
<infinity> (Rather than doing auto-region, region-guessing, which breaks on Star Wars DVDs which try multiple regions and bomb out if more than 1 is found to be "valid")
<mjg59> infinity: Your player should have an option to force the region
<mjg59> Then it can just lie to the DVD
<infinity> Don't see one in mplayer's manpage, and xine's doesn't appear to actually do anything.  Yay.
<mjg59> Hm. Getting the hcfusbmodem driver working ought to be practical
<mjg59> Which ought to mean working Apple modems. Yay.
<infinity> Oo, more stuff for powerpc LRM users?... Fun.
<mjg59> The hacking in most of it is fairly easy, but it'll need a bit of reconstructive work in the serial layer
<mjg59> And then, with luck, that'll be applicable to the hsf code as well
<mjg59> Only real problem is that we'll be running with older Conexant code
<mjg59> Oh, and all these drivers want to spew huge gobs of stuff across /
<mjg59> Need to look into minimising that
<infinity> Ahh, well, hard-setting the region on the drive helped at any rate.
<BenC> infinity: cool
<infinity> BenC : Around?
<AcidPils1> good morning
<AcidPils1> is there a reason for not having the acx module in the 2.6.15-6-k7 kernel?
<CataEnry> hi *
<AcidPils1> hi
<CataEnry> bye
<siretart> AcidPils1: I'd say, file a bug in bugzilla about this
<CataEnry> hi all
<CataEnry> bye
<mjg59> BenC: If we're switching on the PATA libata stuff, should we switch on ata_piix's PATA support?
<BenC> I'll check it, it may be on from the merge I did with libata-dev.git
<BenC> infinity: pong
<mjg59> BenC: It's a single #define in ata_piix.c, IIRC
<BenC> yeah, I see it
<AcidPils1> ah, BenC siretart told me to ask you about the missing acx module in the 1.6.15 kernel
<AcidPils1> bug or feature?
<BenC> I'm not really enabling PATA except where there are PATA drivers
<AcidPils1> 1.6.15? 2.6.15 i mean ;)
<BenC> acid: what is the acx module?
<AcidPils1> drivers for acx100/acx111 wlan cards
<AcidPils1> in 2.6.12 they were included, but in 2.6.15 they are not
<BenC> acidpils: uh, it is enabled
<BenC> check the config, CONFIG_ACX100=m
<BenC> mjg59: let me talk to jgarzik about how safe PATA is in that driver (atiix and one other, are the only ones that need the define to enable PATA)
<BenC> everything else is just on
<mjg59> BenC: If we could get that and the SATA hotswap patches, then I can whip up support for swapping bay devices on laptops
<mjg59> It's a small amount of acpi-integration code
<BenC> what exactly is PATA anyway (how's it different from SATA)?
<mjg59> Parallel ATA
<mjg59> Or legacy stuff
<mjg59> The ones with 40 or 80-wire cables
<BenC> ah
<Yagisan> the "though cables must be shorter then ~80cm or it won't work" version
<AcidPils1> BenC: i must have been blind or something like that 
<AcidPils1> *reboot and try*
<siretart> oh nice.. my r50e is Oopsing on power down.. grml..
<BenC> 80cm? Who runs > 80cm cables to their drives?
<BenC> or did you mean 8cm? :)
<mjg59> 18"
<mjg59> So 50cm
<mjg59> On x86 boards, it's quite common
<BenC> ok, 18" makes more sense
<Yagisan> BenC: I have a full tower case here, and due to design error, the PATA cable and drives are on opposite sides of the case
<Yagisan> BenC: funnily enough there are a lot of pcs with pata cables up to 1m long in them (and I wonder how they still work)
<Yagisan> any chance of the swap prefetch patch from http://ck.kolivas.org/patches/swap-prefetch/mm-swap_prefetch-18.patch ?
<BenC> I'll let that stuff simmer in -mm first
<Yagisan> OK, couldn't hurt asking. Thanks BenC
<BenC> np
<Yagisan> night all
<CataEnry> hi :)
<mjg59> BenC: Current git doesn't build
<mjg59> drivers/scsi/libata-scsi.c: At top level:
<mjg59> drivers/scsi/libata-scsi.c:2194: error: syntax error before return
<BenC> yeah, just pushed fixes for that
<BenC> one typo for me, and another for jgarzik, both fixed
<mjg59> Ok, pulling
<AcidPils1> BenC: am i stupid? http://paste.ubuntulinux.nl/5378
<siretart> BenC: I checked the build logs, and AcidPils seems to have a point somewhere. Despite of being enabled in the kernel config, it seems that the kernel module acx_pci.ko is not built any longer.
<siretart> so either it has moved to another kernel module, or it vanished somehow..
<mjg59> drivers/scsi/sata_sil.c:339: error: ATA_FLAG_NOINTR undeclared (first use in this function)
<mjg59> drivers/scsi/sata_sil.c:339: error: (Each undeclared identifier is reported only once
<mjg59> drivers/scsi/sata_sil.c:339: error: for each function it appears in.)
<mjg59> Hmm.
<mjg59> BenC: ZD1211 seems broken, too
<mjg59>   DEVLIST drivers/usb/net/zd1211/zddevlist.h
<mjg59> make[6] : *** [drivers/usb/net/zd1211/zddevlist.h]  Error 1
<mjg59> Or is that me needing a different awk?
<BenC> gawk
<BenC> siretart: you're correct, the acx100/Makefile is broken
<siretart> ah
#ubuntu-kernel 2005-12-10
<mjg59> BenC: bcm430x people just announced working transmit/receive
<mjg59> BenC: With gawk, I get "Error in source file"
<BenC> mjg59: you have to delete the bad file
<BenC> then one that was attempted by mawk
<mjg59> BenC: Ah
<mjg59> BenC: Is there any way of enforcing this in the build?
<BenC> would be better if we can fix up the awk script to work more compatibly
<mjg59> Yeah
<mjg59> I've managed to get the bcm43xx driver to associate, but not yet to bring up an interface
<BenC> will we be able to put some bcm43xx firmware in l-r-m?
<mjg59> Nf.
<mjg59> That's awkward.
<mjg59> Currently, I'd say "no"
<BenC> any ideas on the ability to distribute bcm4xxx firmware at all? :)
<BenC> I know we have some bcm firmware already in our kernel tree
<mjg59> The bcm ethernet stuff is fine - they've given us permission
<infinity> We can put firmware in LRM if we have the driver in the kernel.
<infinity> (if we can distribute the firmmware, that is)
<infinity> We do that for acx100 firmware.
<mjg59> The firmware is ripped out of the Windows driver right now
<BenC> yeah, there's a tool to extract it
<infinity> Same story with the acx100 firmware.
<BenC> infinity: why do we do that for acx100 and no others?
<infinity> The tool actually goes and downloads a bunch of random drivers and extracts the firmware.
<BenC> we will need that same functionality for bcm43xx
<mjg59> The Broadcom one extracts stuff from the Windows or MacOS drivers
<infinity> BenC : Perhaps because of the extreme sketchiness of how we obtain the firmware? :)
<mjg59> But we still need permission to distribute it
<infinity> (And the fact that it's obviously not Free)
<BenC> yeah, wonder if the bcm43xx folks have visited this issue yet
<infinity> Some firmware is kindly licesnsed in a way that pretends ot be Free, and we look the other way, I think.
<BenC> yeah, like the ones that are in "source code, binhex style"
<BenC> "This binhex-to-C-array dump is GPL'd" :)
<mjg59> I'd be surprised if Broadcom would let us ship the firmware for a device that we've reverse engineered a driver for
<BenC> it's not really reverse engineered, is it?
<BenC> or is the spec reverse engineered?
<mjg59> The driver? Well, it's based on reverse engineered specs
<infinity> The latter, i think.
<mjg59> So it's probably legal, but I can't see them being keen
<BenC> broadcom isn't keen on too many things
<BenC> I used to have access to their docbase
<BenC> wonder if that login still works
<infinity> ARGH.
<infinity> BenC : Still around?
<infinity> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=1e737e269db99fbf01a5436910ae1aef99e9e075;hp=0631074954f75b6351a6c13769e03be5ce87139a;hb=b135c4815051bad6b2472e4ad0152f205918d2c5;f=include/linux/pci_ids.h
<infinity> -#define PCI_DEVICE_ID_ATT_L56XMF 0x0440
<infinity> Apparently, I need that for ltmodem to build.
<mjg59> infinity: You could define it locally
<mjg59> infinity: Also, see http://www.livejournal.com/users/mjg59/55488.html
<mjg59> That's the sort of fucking shit I'm dealing with
<infinity> mjg59 : Oh, I will define it locally, but it still seems a bit wrong that it got removed.
<mjg59> infinity: I'm really unconvinced by that title. There's stuff removed there that isn't duplicated by anything else in the file.
<mjg59> I wish I knew why people keep removing stuff from the kernel
<mjg59> You'd think they could write a useful patch instead
<infinity> Yeah, I did a quick grep and came to the same conclusion as you.
<infinity> It may as well have read "Remove PCI IDs for devices I don't like" or something.
<mjg59> It's probably "Remove PCI IDs that aren't referenced in the kernel"
<mjg59> Someone should bitch
<mjg59> Preferably not me, this time
<mjg59> I did it for the last bit of useful stuff that got ripped out
<infinity> Meh.  That seems braindead to me, but what do I know?
<infinity> I like the ("Open Source" code) bit in your license.
<infinity> Just in case we weren't sure.
<mjg59> I hate Linuxant
<mjg59> Deep, visceral hate
<calc> so what does vbetool 0.5 do for amd64 over i386?
<calc> er i meant over 0.4
<calc> i brainoed ;)
<mjg59> It builds properly
<calc> something that would have made 0.4 not work right on amd64 or just build time issues?
<mjg59> Basically just build time issues
<calc> ah ok
* calc needs to find time to reinstall his laptop with i386 ubuntu to test the acpi stuff
<infinity> mjg59 : Any drivers to shove at me for LRM yet?... I'm rolling a new release.
<TheMuso> 
<TheMuso> 
<TheMuso> 
<infinity> Can someone buy me an OS that makes sense for Christmas?  kthx.
<infinity> I rebooted, initramfs claimed that /dev/sda3 (my root device) didn't exist.  Sure enough, it had been created as /dev/hda[*]  instead.
<infinity> Another reboot, and it's back to /dev/sda[*] , and I'm rocking myself to sleep in the foetal position in the corner.
<fabbione> infinity: is that machine SATA?
<infinity> Yes.
<fabbione> it's a load module order problem
<infinity> I blame udev.
<fabbione> sometime the ide driver (hda*) is loaded before the sata (sda*)
<infinity> Note that I didn't touch anything between reboots.
<fabbione> yeah
<fabbione> it still can happen
<fabbione> 2 drivers handling the same device
<fabbione> BAD BAD BAD
<infinity> Yeah.  Just wonder why I've never seen it until today.
<infinity> Moon phase, I guess.
<fabbione> possibly
<makx> infinity i had that frequently with udev = 0.74
<makx> it was solved that time with a nasty timeout.
<makx> that was prior udev with /dev/.udev/udevqueue you can test against
<infinity> Well, this is with the shiney new udev here.
* makx still envies you for that shiney new udev your debian dir is so much cleaner :-P
* makx needs push Md into alioth.
<infinity> Our systems and packages may be cleaner, but they only boot every second try, so don't be TOO envious. :)
<makx> infinity you seem to use udevplug, which is not even in our udev package.
<makx> we need to use udevsynthesize.
<fabbione> BenC: please pull from my archive when you wake up (RedHat cluster kernel modules update)
<CataEnry> hi all
<chmj> is stuff like fixing FTBFS becouse of missing headers worth pushing to kernel  upstream ?
<fabbione> chmj: where do you get that?
<chmj> fabbione: linux-2.6/kernel/irq/handle.o 
<chmj> include/asm/acpi.h:67: error: boot_cpu_data undeclared (first use in this function)
<fabbione> from which tree?
<fabbione> and on what arch are you building?
<chmj> i386 
<fabbione> from which tree?
<chmj> upstream tree with some test patches 
<fabbione> probably worth a shot, but check if the patch hasn't been submitted already
<fabbione> acpi is common enough to trigger an alarm when it doesn't build
<chmj> fabbione: hmm, thanks 
<BenC> fabbione: ok
<fabbione> BenC: thanks dude.. test builded on amd64 and it's fine
<fabbione> jbailey, BenC: should we have the meeting now?
<fabbione> or do you prefer to wait?
<fabbione> both ways work for me
<jbailey> fabbione: I'm fine now.  I jjust need to remember what it was about.
<fabbione> something about specs?
* jbailey checks his IRC logs.
<jbailey> I need logrotate for these things.
<jbailey> ah, here we are.
<jbailey> KernelServerRoadmap
<jbailey> The idea being that the spec currently defines servers are pretty exclusively things that high end admins would need (clusters, fibber channel raid arrays, etc).
<jbailey> What came up was that Ben asked if he thougt anyone would notice if USB network cards weren't compiled for that kernel.
* fabbione preemptively fires up metallica
<jbailey> My comment was that if setup up an office for SME/SoHo, it's very reasonable to do servers with wireless USB.
<fabbione> jbailey: it really depends what you consider a "server"
<jbailey> So the discussion is really, (I think), how are we defining server
<jbailey> Right! =)
<fabbione> and at the end the result was: hw drivers all
<jbailey> So it needs to be clear, match what actual end user expectations are.
<fabbione> we finetune the server for other properties
<fabbione> like highmem and premptviness 
<jbailey> Well, the definition is less important than what a person will install in their office.
<fabbione> and stuff along that line
<fabbione> well it is somehow
<jbailey> Is it correct for a person in a 5 person office to install the server edition on their fileserver?
<jbailey> If it's not, then I think it's misnamed.
<fabbione> we might want to support the kernel server only on certified hw
<jbailey> And should be "Enterprise computing edition" or something like that, with a note on the side saying what that means.
<jbailey> There's no serious chance of that for dapper.
<jbailey> Possibly after that, though.
<fabbione> i think that what ben and I decided at UBZ was full hw
<fabbione> but just tune for server/desktop
<fabbione> for example
<fabbione> redhat cluster suite doesn't like preempt
<fabbione> now..
<BenC> ok, here, we can do the meeting now if you like
<fabbione> you stick redhat cluster suite module on the server kernel
<fabbione> but not on the workstation one
<fabbione> given also that desktop prefers preempt generally 
<fabbione> BenC: cool
<fabbione> it will save me to run this evening
<fabbione> i *think* the biggest mistake is that we keep trying to code in a spec the kernel
<jbailey> Eh?  If we don't code it into a spec, how are we supposed to do it with enough community feedback?
<fabbione> jbailey: keeping an eye on bugzilla? ;)
<fabbione> jbailey: seriously i think that the kernel world is too unpreditable to be specced the same way we do for other stuff, imho
<fabbione> but does my answer satisfy your curiosity?
<fabbione> (in regards of the hw support)
<jbailey> It does, but it doesn't answer the real question yet for me - Is the server kernel going to be suitable for a 5 person office running a fileserver?
<BenC> fabbione: one thing we weren't sure of, is this going to be server as in "any machine I decide to run as a server" or server a in "expensive NUMA/Summit type systems"?
<jbailey> I think it's a yes.
<fabbione> BenC: iirc we did agree to fine tune the server flavour to suck in as much server coolness as possible
<BenC> but our normal 686 kernel can do that
<fabbione> jbailey: it should yes.. 
<BenC> and our desktop kernel, currently, isn't full preempt, so it should be suitable for SOHO server situations
<fabbione> BenC: i think we should rever that for desktop
<BenC> so my opinion was that the "server kernel" would be geared toward the higher end stuff
<fabbione> and disable the RH stuff on it
<fabbione> BenC: the main problem is that it means shipping even more kernels on -server CD
<BenC> and disable NFS server, and other things like that?
<fabbione> that's confusing for the user
<fabbione> BenC: no, the rh cluster and premept simply conflicts.. it was an example
<fabbione> also.. you can't make clustered workstation
<BenC> just the line is getting fuzzy
<fabbione> it just doesn't work :)
<BenC> I'm not really sure what the target of our server kernel is, which is making it hard to decide what should and should not be there
<fabbione> hmmmmm
<fabbione> i thought we did agree on full hw support
<fabbione> and just tune highmem and preempt
<fabbione> to start
<BenC> but that's the minor issue
<BenC> are we not going to do numa/summit/bigsmp right now?
<fabbione> do they need to be different flavour?
<fabbione> or can they exist in the same kernel?
<BenC> there's a generic one that covers all three
<BenC> but I don't know if it will run on a normal 686, or if you even want to
<fabbione> we can test the former
<BenC> the generic one is what I have now
<BenC> maybe I can do a server and a enterprise kernel?
<fabbione> or server-lowend and server-highend
<BenC> server being our 686 tuned for server, and enterprise being the one that supports the big systems?
<fabbione> i would avoid enterprise word
<BenC> ok
<fabbione> that would make sense yes
<fabbione> if we stick the word enterprise anywhere we will be classified as RH
<BenC> will we need udeb's for those?
<fabbione> and we do not want that
<fabbione> only for the -686
<fabbione> so we could:
<fabbione> install the -server CD with the 686-server tuned
<fabbione> who needs the big mofo can install it from CD
<BenC> ok
<fabbione> how should we call them?
<fabbione> 686-server and highend-server?
<fabbione> we will need to keep a very detailed documentation on the differences
<fabbione> for sure people are going to ask
<infinity> "highend" is one of those things people will install for "highend features", invariably installing the wrong thing.
<infinity> Is there any short word one can think of that unambiguously means "really big hardware you don't own, dumbass"
<fabbione> and note that we will need the same counterparts for the other arches
<fabbione> 686-forbigfathwyoucanteffordunderyourstinckydesk
<infinity> (Also, where is the cutoff between server and fatserver?.. With commodoty hardware as it is these days, I assume server will still support a fair number of CPUs (4, 8?) and a mess of RAM (16G, 32G?) out of the box.
<infinity> Just not crazy configs like 512 CPUs and NUMA... Right?
<fabbione> infinity: i think that's more or less what i had in mine and didn't say
<BenC> yeah, that's basically it
<BenC> 8-way, 32Gig is the limit for our normal server
<mjg59> Hmm. Dyntick seems to be a bit over-enthusiastic
<mjg59> As in, I'm only getting ticks if I actually do something that generates interrupts
<infinity> BenC : Oh, hate to take your mind off the pressing business of naming your next baby...
<fabbione> we could call it 686-bigmofo
<mjg59> And it doesn't actually seem to be saving me any power, either
<infinity> BenC : What should we do with "linux-tree" and "linux-patch-ubuntu" from linux-meta?
<fabbione> i wonder if they will get it?
<fabbione> infinity: kill them
<fabbione> linux-patch doesn't exist anymore
<infinity> BenC : Are you intending to keep the kernel debian-native from here on in, and we should just drop those?
<fabbione> and neither -tree- afair
<BenC> infinity: I had them deleted, we just need linux-source now
<infinity> Well, -tree = source+patch-ubuntu, so if there's no patch, there's no tree.  Right.
<infinity> Kay.
<BenC> brb, rebooting to -7.9
<cliebow_> could someone elaborate on tagging a vmlinux kernel with initramfs?suggestions were adding initrams.gz to the data section?
<Yagisan> reading the scrollback, what about servers that need high interactivity eg edubuntu or other ltsp servers ?
<Yagisan> do they have to have a "desktop" kernel ?
<fabbione> Yagisan: ltsp servers are workstations
<fabbione> so they get the desktop kernel
<BenC> yay, my cdrom is working!
<BenC> jbailey: I have an interesting tidbit for you, my G4 stopped locking up from the screen-saver after I switched LCD panels
<jbailey> BenC: It's an Apple Cinema Display.  No chance of me swapping it out. =)
<BenC> hehe
<mjg59> BenC: Did you have a chance to ask jgarzik about the ata_piix pata support?
<BenC> mjg59: he never came back around
<mjg59> Ah, ok
<Yagisan> fabbione: Ok, but that would still have the driver support of say "server" versions ?
<fabbione> Yagisan: please read all the scroll back
<fabbione> Yagisan: the hw support will be the same in terms of drivers
<fabbione> and no ltsp does NOT need a server kernel
<BenC> fabbione: so on i386 (the only server kernel atm) I will disable all the cluster stuff except in the server kernels, correct?
<BenC> should I disable gfs aswell?
<fabbione> BenC: yes correct.
<fabbione> gfs/clustering can go away from the desktop
<fabbione> and you could reenable pre-empt
<fabbione> but that's up to you
<fabbione> gfs depends on CMAN iirc
<BenC> ok
<fabbione> do it should autodisable
<Yagisan> fabbione: ok. I just thought I read that nfs was proposed to be disabled in desktop kernels, and that's needed for ltsp/edubuntu
<fabbione> s/^d/s
<fabbione> Yagisan: read carefully ;)
<fabbione> BenC: when do you plan to upload 7.9 ?
<Yagisan> fabbione: I know, I need more coffee (and sleep - my babies won't let me do that).
<BenC> hopefully today
<fabbione> BenC: perfect
<BenC> maybe tomorrow since I want to get the server kernel building aswell
<fabbione> i am waiting for the new rh modules to test the new userland
<fabbione> too lazy to build it myself on 3 arches
<fabbione> did you remember to enable the ABI script?
<CataEnry> hi all 
<BenC> yeah, abi is working again
<fabbione> cool
<mjg59> BenC: Hm. The ata_piix driver doesn't provide PCI IDs for a lot of the devices that piix.c will drive
<mjg59> I'm playing with it a bit now
<lamont__> BenC: either I deleted it, or something else caused your patch email to not reach me... could you send it to lamont.jones@hp.com?
<lamont__> (elilo/gnuefi)
<BenC> I didn't send it
<BenC> it's not booting
<BenC> the fix is simple enough, just use the linker scripts from gnu-efi 3.0b
<BenC> it's like a two line change
<BenC> I even tried building with gcc-3.4, and it still doesn't work (as soon as it tries to run elilo, it drops back to the EFI menu, almost instantly)
<jbailey> BenC: Amusingly enough, I switched back to sparc/2.6.12-9 and started a gdb build earlier.  I just checked and it has not crashed yet.
<BenC> yeah, that is odd
<BenC> I've been doing some fairly frequent builds of the kernel on my e3k (-j20)
<BenC> maybe I should try a gdb build :)
<jbailey> BenC: It's in the testsuite that it's dying.
<jbailey> So the two thoughts I have are memory pressure, or some syscall exercising.
<BenC> I have 6 gigs, so memory pressure is difficult for me
<BenC> I need to get my U2 out for testing some of this
<jbailey> I understand.  I have the same problem with my ppc64 box. =)
<BenC> poor us :)
<jbailey> Isn't our life hard? =)
<lamont__> BenC: so we just need a newer gnu-efi, and then figure out why it doesn't boot, eh?
<lamont__> and pulling ram is painful, too.
<lamont__> BenC: does it play a pretty tune first, or just exit?
* lamont__ bets exit
<BenC> tune?
<BenC> I hadn't noticed any tunes coming from my i2k :)
<BenC> I see "Loading Ubuntu", then "Starting Ubuntu", and then back to EFI, the "Starting Ubuntu" goes so fast I somtimes don't even see it
<BenC> so it's like exiting pretty damn early
<BenC> lamont: is there any debugging I can put in elilo?
<BenC> I'm almost thinking it is exiting in crt0 or something
<BenC> ah, it has verbose and debug  options
<BenC> I'll try enabling that
<mdz> BenC: I get a BUG on 2.6.15-5 triggered by the pcmciautils init script
<mdz> is pcmciautils not doing the same checks that pcmcia-cs did, to avoid loading the drivers on systems which don't have pcmcia?
<BenC> fixed in -6
<mdz> (this is on my desktop)
<mdz> ok, am doing that upgrade now
<BenC> you got a softlock, correct?
<mdz> correct
<mdz> init_i82365 ... _spin_lock_irqsave
<BenC> yeah, fixed
<mdz> thanks
<BenC> patch from breezy causing that
<BenC> just removed it
<mdz> BenC: any guesses as to my via/irqpoll problem? (#5234)
<mdz> that's the real issue with 2.6.15 on my desktop currently
<BenC> same problem from breezy, right?
<BenC> I left out your patch to see if you'd complain, so I guess I'll still need it :)
<BenC> I'll put it in -7.9
<mdz> not exactly; irqpoll no longer works around it now
<BenC> maybe irqpoll is broken
<BenC> x86 or amd64?
<mdz> x86
<BenC> I was going to upload -7.9 today, but it got put off because a driver is failing to build
<BenC> since I have to put it off anyway, I can get your via patch in and check irqpoll
<BenC> when is flight 2 supposed to be done?
<CataEnry> hi
<jbailey> BenC: I asked Colin for a not-sooner-than this morning and he said Thursday.
<BenC> cool, so tomorrow shoudl be ok for a -7.9 upload
<BenC> thanks
<mdz> BenC: flight 2 is tentatively later this week
<mdz> thurs or fri
<fabbione> mjg59: are you aware of any problem with the ipw2x00 driver in the latest breezy kernel?
<fabbione> (or if you heard something about it)
<mjg59> What sort of problem?
<fabbione> basically it happens only to cvd
<fabbione> when there are 3 or 4 APs around
<fabbione> the card becomes unstable to death
<fabbione> do you happen to have one of them around to test in a similar situation?
<fabbione> the problem happens with breezy kernels
<mjg59> I've seen vaguely similar stuff
<fabbione> workarounds?
<mjg59> Nope
<fabbione> ok thanks :/
<dilinger> breezy's kernel keeps crashing on my opteron machine :/
<mjg59> Fucking ay
<jbailey> dilinger: Your opteron and my sparc can go cuddle.
<fabbione> dilinger: your opteron is crap.. :)
<dilinger> fabbione: my opteron rocks :p
* mjg59 is now happily IRCing from the AMD64 laptop with a Broadcom chipset
<dilinger> fabbione: i'm not even using SMP, since that crashes on bootup
<trevilor> hi guys
<dilinger> it may very well be the 3ware driver
<dilinger> since it's been doing a lot of i/o when it hangs
<fabbione> dilinger: what about trying to see if it is something else?
<dilinger> fabbione: well, the machine's in boston right now, and i'm not
<dilinger> so trying stuff is kind of hard
<fabbione> dilinger: sucks to be you
<dilinger> :P
<dilinger> not really.  it's a 2TB machine :)
<dilinger> once it's stable, i will be very very happy
<BenC> mjg59: just did a sync for bcm43xx and softmac for -7.9, so let me know if it works stock
<dilinger> the sunfire should be going out to davem today
<dilinger> assuming that the UPS pickup happens correctly
<fabbione> dilinger: cool
<mjg59> BenC: I needed to add a PCI ID
<fabbione> BenC: dunno if you are reading #u-d but we might not need udeb for -server at all
<mjg59> But other than that, it seems good
<fabbione> softmac as in the Airport Extreme support?
<BenC> fabbione: ok, I have them enabled, so it's easy to turn off (or ignore them)
<mjg59> Softmac provides 802.11 management stuff in software
<BenC> mjg59: email me the id's
<mjg59> Which the Broadcom driver needs
<fabbione> ok
<fabbione> BenC: ok, if they don't build, just disable them
<BenC> bcm43xx as in airport extreme though
<fabbione> BenC: i totally forgot to ask to Kamion before saying yes
<mjg59> BenC: 4318 with VENDOR_HP, ID_ANY in the subvendor/device fields
<BenC> mjg59: ok, they'll be there
<mjg59> Rock
<dilinger> jbailey: what kind of sparc, btw?
<jbailey> dilinger: U5
<dilinger> ah
<mdz> BenC: kernel-wedge and kernel-package merges seem to still be pending; if there's something blocking them, please note in the status whiteboard, otherwise please get them merged soonest
<jbailey> Is it expected that there's no linux-headers-2.6.15-# package yet?
#ubuntu-kernel 2005-12-11
<BenC> jbailey: there are already
<BenC> linux-headers-2.6.15-6-386, for example
<ispiked> mjg59: ping
<mjg59> ispiked: Hi
<ispiked> mjg59: I hate to bug you, but I'm wondering why fn+f1 doesn't put my laptop to sleep. the keycode appears to be registered, and I could've sworn this used to work.
<mjg59> ispiked: What hardware?
<ispiked> mjg59: the same as you.
<ispiked> mjg59: dell d610.
<mjg59> Have you got the latest acpi-support ?
<ispiked> yeah. did that break it?
<ispiked> I'm pretty sure I can suspend using logout > suspend with the latest acpi-support package.
<ispiked> I'm headed out now. be back later.
<mjg59> Hm. Not sure, then.
<mjg59> BenC: So, is the idea to switch to the libata PATA drivers where possible?
<ispiked> mjg59: where is that button's action configured?
<mjg59> ispiked: /etc/acpi/events
<ispiked> mjg59: same deal with the logout action?
<ispiked> http://rafb.net/paste/results/lcTK1z80.html
<mjg59> ispiked: Uhm. Which logout action?
<ispiked> "suspend the computer"
<mjg59> Oh, the Gnome one? No, that triggers gdm to execute pmi 
<ispiked> mjg59: what is that?
<mjg59> It's a script that ends up executing /etc/acpi/sleep.sh, so it's broadly the same
<ispiked> it'd be nice if scroll lock would work (with the light, too).
<ispiked> might file a bug for that.
<mjg59> BenC: ata_piix + added PCI ID drives my Thinkpad fine
<fabbione> morning
<infinity> mjg59 : Who do I complain to that my 'screen close' button no longer triggers a screen lock?
<dhpeterson> hi ... breezy install fails for me ... it's a uhci_hcd issue ... can anyone here help?
<dhpeterson> i have checked ubuntu bugzilla and debian BTS and it's not a dupe
<dhpeterson> i want to raise a bug report but i don't know which package and where to do so, etc
<crimsun> file it on bugzilla.ubuntu.com against 'linux'
<dhpeterson> okay
<dhpeterson> what severity ... both hoary and breezy installers don't complete. is that a critical?
<dhpeterson> btw same for the debian sarge installer
<dhpeterson> interestingly, knoppix 2.6 _does_ boot successfully
<infinity> Does our livecd boot?
<dhpeterson> neither live nor install works
<infinity> Saying "a livecd boots" and "the installer fails" don't relate much.
<dhpeterson> live cd and install cd fail in the same place
<infinity> Okay, if the livecd doesn't work either, then please, file a bug, lots of fun debug output, blah blah.
<dhpeterson> sorry if i was ambiguous
<infinity> Severity is normal.
<dhpeterson> okay i will prepare a bug report, thanks 
<fabbione> BenC: 
<fabbione> [ 1067.366233]  bcm43xx: Invalid PHY Revision 7
<fabbione> [ 1199.264579]  bcm43xx: FIXME: Possibly broken code in bcm43xx_phy_setupg() at drivers/net/wireless/bcm43xx/bcm43xx_phy.c:346
<fabbione> the driver loads and the board is initialized
<fabbione> but i can't get it to associate with my AP
<fabbione> i think i am getting that error when trying to force to use 11M
<fabbione> it's probably the model that's not fully supported for my understanding of the code
<jbailey> fabbione, BenC: Next time one of you are twiddling the kernel configs, CONFIG_CRAMFS=y can probably go away now.
<jbailey> Need to double check with Colin, but I don't think d-i uses it at all.
<BenC> ok
<fabbione> hey BenC 
<fabbione> i was just talking with Kamion
<fabbione> i did fix a couple of kernel d-i things for him
<fabbione> mind to pull from my repo?
<BenC> doing that now
<fabbione> thanks
<fabbione> hmmm
<fabbione> if you have time it would be a good idea to fire up a full build on sparc
<fabbione> mine is chaoking on OOo2, gcc-3.4 and gcj-4.1
<fabbione> these d-i changes are always hairy without a build
<fabbione> the other arches are ok
<BenC> I do full builds on all 6 arches before release
<fabbione> ah cool
<fabbione> even better
<BenC> sparc64 is done in 12 minutes, so it's easiest :)
<fabbione> BenC: i was wondering.. can i get access to your sparc somehow that doesn't distrurb you?
<fabbione> disturb
<BenC> yeah, I can try setting that up today
<fabbione> since you use the box for testing
<fabbione> i could just use it while you sleep to push some big pkgs to a fine tuned buildd there
<fabbione> and skip stuff like gcc-* here
<fabbione> i will send you my ssh key
<fabbione> no need to run TODAY
<fabbione> sometimes, when you have time
<BenC> sure thing, I'll setup dchroot for you and sudo access inside that chroot
<fabbione> nah
<fabbione> i will send you a chroot :)
<BenC> ok, just send a url, and I'll unpack the chroot :)
<fabbione> BenC: sure.. i just need to pack it first ;)
<BenC> don't forget your rootkit :)
<fabbione> of course :)
<fabbione> it's funny when people tell us: "no you can't get access to my machine to debug this kernel problem.."
<fabbione> they really make me laugh
<fabbione> they don't realize we do actually build that kernel for them :)
<fabbione> we have kernel privileges!
<fabbione> and they don't see it :P
<BenC> yeah, lol
<BenC> "if I wanted your machine, it'd already be DoS'ing the whitehouse by now"
<fabbione> https://wiki.ubuntu.com/FabioMassimoDiNitto <-
<fabbione> that was like: zul meets fabbione, fabbione meets zul
* BenC lol
<zul> hey sorry i havent been around.
<fabbione> BenC: chinstrap:/home/fabbione/sparc-chroot-dapper.tar.bz2
<fabbione> BenC: and i am off for a nap :)
<fabbione> hey zul
<fabbione> later fellas
<crimsun> cya fabbione 
<BenC> bye fabbione
<zul> hey fabbione, bye fabbione 
<mjg59> infinity: Oh, yeah, that one's my fault
<mjg59> BenC: About?
<BenC> yeah
<BenC> mjg59: pong
<mjg59> BenC: What's the long-term plan with all these libata PATA drivers?
<BenC> see how they go, and if they start breaking shit, back them out
<BenC> unless I can fix them (or jgarzik can help me)
<mjg59> The obvious breakage is that drives will move from hda to sda
<BenC> I don't think he's keen on me using them in the dist
<BenC> hmm
<mjg59> On the other hand, it means we can do hotswap properly
<BenC> upgrades will get messy though
<BenC> maybe I can default the combined_mode to IDE
<BenC> until lately I hadn't realized how much of a mess things were between ide and ata/sata/pata
<BenC> what do you suggest?
<jbailey> mjg59: re: s/hda/sda/ - I wonder if there's any reasonable way to move systems to by-uuid for booting and mounting?
<BenC> I've always liked that method
<jbailey> Part of udevroadmap is to do that for new installs in d-i anyway, so it's just transitioning people to the New World Order.
<BenC> same thing with iftab for network interfaces
<jbailey> I don't know iftab
<mjg59> BenC: The libata drivers are pretty untested, but /ought/ to work
<BenC> iftab gives network interfaces their names based on mac address
<mjg59> But when we upload a kernel with them in, there's going to be breakage
<BenC> I think I'll disable them for now, until we get this sorted out
<infinity> mjg59 : Is this new behaviour intentional, or a bug? :)
<infinity> mjg59 : (I've always used my "screen close" button as a quick shortcut to "I'm walking away from the laptop for 5 minutes, lock the screen")
<mjg59> infinity: bug
<mjg59> I fucked up the environment variable check
<jbailey_> BenC: Just had my X hang on ppc64 again.  Interesting that this time a kill -9 of Xorg doesn't make it go away.
<jbailey_> BenC: Anything I can usefully collect for you for a bug report before I hit the shiny switch?
<BenC> check dmesg
<BenC> and "cat /proc/<pid>/wchan" if the X pid
<jbailey_> no oops in dmesg
<BenC> I have a feeling you are hitting a drm issue
<jbailey_> I did the cat a dozen times, each in .__start 
<BenC> hmm, that's an odd place
<BenC> is the process in D state this time?
<jbailey_>  5603 root      25   0     0    0    0 R  100  0.0  11:06.14 Xorg
<jbailey_> (from top)
<jbailey_> It was taking up a bunch of ram before I kill -9'd it.
<BenC> is that 100% CPU usage?
<jbailey_> Yes.
<BenC> all the memory usage is gone, and it's hanging
<BenC> that's an odd one :)
<jbailey_> Shall I strace it?
<BenC> yeah
<jbailey_> # strace -p 5603
<jbailey_> attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
<jbailey_> Should I try the ppc32 kernel to see if it recurs there?
<BenC> infinity: ping
<infinity> pong... ish.
<infinity> 3:30am and heading to bed.
<infinity> So, uhh.... make it quick. :)
<infinity> BenC : Alright, whatever you were pinging for, you missed your chance.  ail me, or catch me tomorrow.
* infinity -> bed, finally.
<BenC> hey
<BenC> sorry
<dilinger> will dapper kernels work on breezy?
<infinity> Oh.  You are here.
<dilinger> i'm gonna try getting this smp opteron box stable w/ some 2.6.15 love
<infinity> On breezy servers or desktops?
<BenC> infinity: next time prepend "BenC" to the pong so I actually get an audio feedback :)
<infinity> udev will probably blow up on desktops.
<dilinger> infinity: both
<dilinger> infinity: so i'd just need to backport udev?
<BenC> dilinger: you'll have to sync a few packages to dapper aswell
<BenC> mainly udev, and ditch hotplug
<infinity> BenC : Well?.. :)
<dilinger> ok
<dilinger> thanks
<dilinger> i'll give it a shot on my laptop, first
<dilinger> and once i'm locked out of a usable system, i'll try the opteron server ;)
<BenC> infinity: should/could I add server-{low,high}end to lrm?
<infinity> Hrm.
<infinity> Are we building wireless drivers for -server targets?
<BenC> dilinger: you should be able to add dapper to sources.list, and install the kernel, and then remove it
<BenC> infinity: right now, -server is just a tuned version of the normal targets (HZ, disable-preempt)
<BenC> same hw support
<infinity> I assume that might change?
<infinity> For now, I wouldn't bother.  We'll discuss it later.
<BenC> highend supports numa/bigsmp/summit/es7000 targets
<BenC> ok
<infinity> If we want atheros and acx_pci support, we'll have to do it.
<infinity> I may want to tweak things to not bother including the video crap on -server targets.
<BenC> well, all the kernel video crap is in there too
<infinity> I hope that will go away.
<BenC> me too
<infinity> But, yeah.  Let's discuss it tomorrow.
<infinity> If you're doing an LRM/linux-meta ABI bump tonight, just leave restricted out of the server stuff in linux-meta for now.
<infinity> We'll sort it later when we're sure what we want.
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-7.9 uploaded (The "My momma made me do it" release)
<BenC> ok
<fabbione> ehhehe
<fabbione> cool
<fabbione> new crack :)
<fabbione> BenC: btw.. it's GO on ppc.. or at least it was last pull i did
<fabbione> dunno if you read the scrollback
<fabbione> i did also test the Airport Extreme2 driver
<fabbione> but it fails on me
<BenC> mjg59 got it working
<mdz_> BenC: are you getting any feedback on CD-ROM/DMA issues since we switched to 2.6.15?
<BenC> you have to do some manual shit
<mjg59> fabbione: I had to do:
<BenC> mdz: zero
<mdz_> interesting
<BenC> only thing I've heard about cdrom was the atapi stuff with sata controllers
<BenC> and that was a seperate issue
<mdz_> I thought we'd fixed that long ago
<mjg59> iwconfig foo essid bar; iwconfig foo channel baz; ifconfig foo up; iwlist scan; iwconfig foo essid bang
<infinity> BenC : Keybuk fed you a patch for ide stuff that fixed mdz's DMA issues, no?
<BenC> infinity: yes
<infinity> (And the CDROM on sata thing should be fixed in this upload too, right?)
<mdz_> BenC: is that in -7.9?
<fabbione> mjg59: trying now.. but i have no idea what chan i am using
<BenC> it wasn't dma directly, it was ide-generic/modular-ide crack
<fabbione> mjg59: how can i figure that out?
<mdz_> BenC: is modular ide a bad idea?  why isn't it upstream?
<fabbione> mdz_: IDE maintainer is a pain
<infinity> BenC : For LRM's ABI bump, you should be able to just bump "abi_version" in debian/rules, add a new changelog entry, and build the source package.  (make sure you have kernel-wedge installed)
<infinity> BenC : Should be smooth sailing.
<BenC> breezy's ide was that it loaded all the ide controller drivers, and then ide-generic, and let them fight it out, then removed any that didn't win
<BenC> that doesn't work for dapper
<BenC> infinity: yeah, I have it ready to upload once I see a success report for atleast one arch :)
<infinity> BenC : Rock.
<infinity> Kay, I'm off to bed, then.  We'll revisit the LRM-on-server-kernels thing later.
<BenC> mdz: the way breezy handled drivers grabbing devices was bad
<mdz_> mjg59: my T42 with 2.6.15-6 failed to come back from STR today
<BenC> dapper will low the correct drivers instead of doing a free-for-all
<BenC> s/low/load/
<mjg59> mdz_: When suspended, did it have the hard drive LED on?
<mdz_> (previously /sys/power/state was empty, but that's fixed now)
<mdz_> mjg59: it wasn't on when I tried to resume at least
<BenC> if anything doesn't get loaded, or is loaded incorrectly, Keybuk assures me he will correct it in initramfs :)
<mdz_> the moon light was on, though the fan was still running
<mjg59> mdz_: If the fan was still running, it hadn't suspended
<mdz_> or maybe it was just radiating heat
<mdz_> anyway it was hot
<mjg59> Right
<mjg59> Sounds like it froze on the way down
<mjg59> I've had my Thinkpad do something like that. I'll look into it.
<mdz_> any testing I can do?
<fabbione> mjg59: do you get this in your dmesg: [26120.102096]  bcm43xx: FIXME: Possibly broken code in bcm43xx_phy_setupg() at drivers/net/wireless/bcm43xx/bcm43xx_phy.c:346
<BenC> mdz: btw, I don't think we are going to do kernel-wedge and kernel-package merging for dapper
<mjg59> See if it's reproducible?
<mjg59> fabbione: Yeah
<fabbione> mjg59: hmmmm
<mdz_> BenC: something scary there?
<fabbione> what channel should i use?
<BenC> things work for us now, and kernel-package 10 in debian is way way way different
<mjg59> fabbione: Whatever channel your AP is on
<fabbione> mjg59: i have no clue...
<BenC> we have patches in wedge and package for powerpc stuff, and custom update-initramfs usage
<mjg59> fabbione: iwlist scan should tell you
* fabbione tries again from scratch
<BenC> mdz: it's not impossible to merge those into the new packages, just that there's no pressing need to do so, that I can see
<mdz_> BenC: bugfixes?
<mdz_> that's the usual reason
<BenC> most of the bugs fixes between our version and 10 in debian, is fixing things that broke when they split the debian/rules file up
<BenC> mdz: -7.9 has -server kernels for i386, btw
<mdz_> BenC: so it'll need queue/new processing on i386?
<BenC> yes
<BenC> it's an abi bump anyway
<mdz_> ah, right
<mdz_> BenC: what's new and cool in the server flavour?
<makx> Keybuk: could you take a look at debian #342057, BusLogic not loaded because !sysfs (seems needed for vmware testing of initramfs-tools).
<BenC> abi tracking will start with this upload too
<BenC> mdz: HZ is down to 100 (suggested for server), and preempt is disables (enabled for desktop)
<BenC> that's for low/high end server
<BenC> highend also has generic bigsmp/numa/summit/es7000 support
<BenC> 64CPU max, and 64Gig max
<mdz_> BenC: sounds like material for https://wiki.ubuntu.com/DapperReleaseNotes
<mdz_> BenC: please add an entry there under the server section
<BenC> ok
<fabbione> mdz_: the -server kernels will land only on the -server CD
<fabbione> we will install by default the low end, with high end available
<BenC> would be nice if we could detect highend
<fabbione> mjg59: do you have a 54M net at home?
<mjg59> fabbione: No
<fabbione> did you force the speed?
<mjg59> Yup
<mjg59> Sorry, forgot to mention that
* fabbione hits mjg59 
<fabbione> ;)
<mjg59> It doesn't do speed autonegotiation properly yet
<fabbione> where in that process?
<fabbione> or just after
<fabbione> my ap doesn't feel the mac at all
<fabbione> actually
<fabbione> did you use dhcp on top?
<fabbione> or just static
* fabbione mumbles a bit
<mjg59> Either
<mjg59> dmesg should show that it's authenticated if it's been successful
<BenC> mdz: added
<fabbione> [  450.499743]  SoftMAC: Sending Authentication Request to 00:04:e2:d9:0a:dc.
<fabbione> it doesn't when i am in 11MB
<mjg59> fabbione: I think it ought to get a response, too
<fabbione> that's my neibourgh AP
<mjg59> 802.11g speeds currently don't work
<fabbione> that's at 54MB
<mjg59> Set it to 11 and then set the essid again?
<fabbione> o
<BenC> maybe the AP is configured for g-only?
<fabbione> nope
<fabbione> i don't see any outgoing request to/from my AP
<fabbione> not even in dmesg
<fabbione> BenC: my ap is 11 only
<fabbione> it definetely can't do more than that
<BenC> ah
<mjg59> fabbione: Does iwconfig show the correct essid and frequency?
<fabbione> i was trying my neighbour only becuase it's 54MB :)
<fabbione> i can see the frequency keep changing
<fabbione> otherwise the essid is fine
<mjg59> Uhm.
<fabbione> i wonder if the fact that i am not broadcasting the essid might confuse the driver
<mjg59> Have you explicitly set the channel?
<fabbione> yes
<mjg59> Yes, that might currently break it, I guess
* fabbione changes
<fabbione> *cough*fuck cisco*cough*
<fabbione> i can't even find how to do it again
<fabbione> woo
<fabbione> mjg59: i got the AP to see the interface and viceversa
<mjg59> Any joy?
<fabbione> but no IP joy
<mjg59> Cool
<fabbione> [  557.190722]  SoftMAC: Sending Authentication Request to 00:02:8a:21:18:59.
<mjg59> Try configuring it manually rather than using dhcp?
<fabbione> yes
<fabbione> that's what i am doing right now
<fabbione> no joy either
<fabbione> it complains about authentication
<fabbione> but i have no authentication config on my AP
<fabbione> only filters by mac-address
<BenC> so it's open, no wep/wap?
<fabbione> nope
<fabbione> if i run iwscan list a few times in a raw i see the AP at intervals..
<fabbione> but that might be normal
<mjg59> How does it complain?
<makx> BenC: getting bugreports on debian initramfs-tools of !sysfs drivers that are fixed in your tree?
<fabbione> SoftMAC: Rates not sorted!
<fabbione> SoftMAC: Authentication timed out with 00:02:8a:21:18:59
<makx> BenC: could you push those to linus, are they already in mm?
<BenC> makx: uh, say that again? :)
<BenC> I'm not sure what you mean
<makx> buslogic has sysfs support in your tree for example. :)
<fabbione> mjg59: i will fight with it tomorrow again.. gotta cook dinner
<BenC> s/sysfs/module-device-table/ you mean?
<makx> indeed magic keyword.
<BenC> it's not proper support, it's just a hack to get udev/hotplug to load the driver
<BenC> for linus to take it, the driver(s) would also need to be converted over to the PCI callbacks for hotplug support
<BenC> right now they only probe when loaded, if you insert a new device, the module has to be unloaded/loaded again to probe it
<BenC> these are the same things we had in breezy
<jbailey> BenC: Is he being all prissy now about correctness?  Sheesh. ;)
<BenC> it's a convenience, but IMO, it's lying to have a module-device-table and not be able to support the hotplug callbacks for which is was designed for :)
<BenC> makx: what are the chances that debian would want to clone ubuntu's git tree, and sync non debian/* changes?
<BenC> the major thing would be some of the non-free stuff that debian would want to ignore (and purge from it's branch)
<dilinger> BenC: i assume the git tree includes all the external drivers and patches?
<dilinger> debian doesn't really want to maintain that stuff, they'd only be interested in bugfixes
<CataEnry> Hi
<fabbione> BenC: you didn't pull the last changes to d-i?
<fabbione> they are not in the changelog
* fabbione goes for dinner
<fabbione> BenC: if you can do that Kamion will love you
<fabbione> perhpas fire up a 7.10 right away?
<fabbione> bbl
<BenC> I did a pull and saw two changes from you in git-log
<fabbione> yes 
<fabbione> but the changelog in the archive doesn't have them
<fabbione>   * Stop providing ext2-modules and ship it for all arches.
<BenC> not sure why, did you commit it?
<fabbione> it's missing
<fabbione> oh crap
<BenC> ext2-modules is not listed in debian/control, so I assume all is well
<fabbione> i didn't commit the changelog
<BenC> heh, shame on you :)
<fabbione> if you check debian/d-i/i386/package-list
<fabbione> # This file is used to build up the control file. The kernel version and
<fabbione> # "-di" are appended to the package names. Section can be left out. So can
<fabbione> # architecture, which is derived from the files in the modules directory.
<fabbione> # It overwrites specifications from /usr/share/kernel-wedge/package-list.
<fabbione> #
<fabbione> Package: kernel-image
<fabbione> Package: fat-modules
<fabbione> Priority: standard
<fabbione> it should look like that
<BenC> yeah, it does
<fabbione> ok
<fabbione> do you have d-i/sparc/modules/sparc64/ext2-modules ?
<BenC> yep
<fabbione> great
<fabbione> than it's missing only the changelog entry
* fabbione goes and sits in a corner
<fabbione> thanks dude
<fabbione> sorry for the panix
<fabbione> panic
<BenC> no problem :)
<fabbione> i did add the changelog entry and committed it for the sake of completness
<fabbione> it should be in my archive if you want to pull it
<fabbione> and i must run to cook now :)
<fabbione> later
<BenC> later
<makx> BenC: zero.
<dilinger> heh
<makx> you tree went in completly different direction.
<dilinger> unless ubuntu kept feature additions in a separate tree..
<mdke> hi all. my laptop doesn't get very far into the boot process due to (i think) the hard drive getting a new device name under the new dapper system, I wondered if anyone fancied some debugging with me?
<makx> hmm what's your root on?
<mdke> it is on /dev/sda7
<mdke> or rather, it was
<mdke> i rather think that now it is on /dev/hda7
<makx> timing trouble with udev picking up ide-generic before your sata driver.
<makx> do you have latest udev installed?
<mdke> updated yesterday
<makx> what does dpkg -l udev show?
<mdke> today I can't get close enough to boot
<makx> you don't have an old kernel to boot into???
<mdke> oh yeah i could do that
<mdke> brb
<makx> if your initramfs got update too you need to pass some boot param to break at some point.
<makx> and then there is some manual stuff to load your right driver and kick off init.
<mdke> makx, ok i can boot with the old kernel, but I had to reboot back into breezy again cos the network card isn't working
<mdke> most of the initscripts didn't seem to start
<mdke> anyhow, it is version 076 of udev
<mdke> weird because I could boot yesterday, with the new kernel
<makx> which revision
<mdke> ubuntu5
<mdke> is that right?
<makx> should be
<mdke> oh well, no worky
<makx> fabbione on #ubuntu-boot had the same trouble as you.
<mdke> maybe we have similar laptops
<mdke> fabbione, did you resolve?
<mdke> this hard drive is weird, it is sda for warty, hda for hoary, and sda again for breezy :)
<makx> well hda for hoary is because of the old kernel.
<mdke> makx, ok so any ideas? shall i just file a bug?
<makx> ooh changed from warty to hoary, then no idea..
<makx> well i'm debian initramfs-tools maintainer i could you get booted, but i've some work atm
<mdke> i don't need to boot, but i'd like it to get fixed
<mdke> so I'll file a bug
<makx> then check if there is not already a bug around against udev/initramfs-tools?
<makx> and add your lspci output info.
<mdke> will do
<mdke> will lspci from breezy be ok?
<makx> yes.
<mdke> makx, thanks for your help
<makx> mdke: np, Keybuk on #ubuntu-boot is your udev dude.
<mdke> yeah i will bother him
<makx> he is not around atm.
<mdke> no he isn't
<mdke> he'll get my bug :)
<lamont> BenC: elilo tested and working
<BenC> with initramfs?
<lamont> not yet
<BenC> well good that you could get it to work, because I was not having any luck even with initrd :)
<lamont> BenC: http://people.debian.org/~lamont/elilo.efi
<lamont> drop that in your efi directory and see how things go
<lamont> mind you, you may want to rename the existing one to something else first,
<lamont> so you can rename it back from efi-shell to get a working system afterwards... :)
* lamont goes to a place where bluetooth is absent, so he can get his phone and headset happy again
#ubuntu-kernel 2006-12-04
<tepsipakki> a regression in feisty-kernel: it accepts only 256 characters on the commandline
<tepsipakki> where ->edgy accepted 1024
<fabbione> tepsipakki: file a bug. 
<fabbione> you should know that by now
<tepsipakki> ok, I'll reopen the one from a year back ;)
<tepsipakki> in fact, pxelinux accepts "only" 512 chars so that needs fixing as well, in another bug
<Mithrandir> it hasn't occured to you that if you need to pass in half a k of text you might be doing something wrong?
<tepsipakki> no :)
<tepsipakki> netcfg is slightly broken
<tepsipakki> and we need to use static settings
<Mithrandir> use a preseed file
<Mithrandir> or fix netcfg
<tepsipakki> preseeding doesn't work
<tepsipakki> actually, this is preseeding..
<tepsipakki> but it can't fetch the file before net is up
<lkolbe> Hi, I have a problem with make-kpkg, see http://paste.ubuntu-nl.org/35277/
<lkolbe> is this the right place to ask?
<BenC> lkolbe: Old version of kernel-package I suspect
<lkolbe> Well, I tried with both 9.001ubuntu15 from ubuntu dapper, as well as a rebuilt 10.065 from debian sid
<lkolbe> and it always things the version is "kernel-image-.." instead of "kernel-image-2.6.19"
<lkolbe> and then it fails ...
<lkolbe> thanks for listening so far :)
<lkolbe> Oh. I just saw that make-kpkg is not the recommended way to rebuild a kernel on ubuntu?
<fabbione> BenC: ping?
<BenC> fabbione: pong
<fabbione> BenC: did you talk with cjwatson about the kernel upload?
<fabbione> I had to push a 7.11 on his behalf to fix missing isofs
<fabbione> but my git here still doesn't frigging work
<fabbione> it's a one line change for debian/d-i/....
<BenC> fabbione: That's ok, because ubuntu-2.6 git is at 2.6.20-git now
<fabbione> the rest is only to workaround the ABI checker because i couldn't fetch all the ABI's
<BenC> fabbione: If you can send me a diff, I'll include it for git
<fabbione> doing
<Mithrandir> BenC: how come that it didn't ftbfs?  Isn't isofs required for any udebs?
<BenC> Mithrandir: I redid the udeb's for feisty to clean things up
<Mithrandir> ok.
<BenC> guessing I missed that module
<fabbione> Mithrandir: the kernel module is in the deb but not copied in the isofs.. that's not FTBFS
<fabbione> hem
<fabbione> isofs/udeb
<Mithrandir> fabbione: ok, so it was just missing from the correct udeb package list
<BenC> right
<fabbione> Mithrandir: yeps
<fabbione> BenC: http://people.ubuntu.com/~fabbione/cocktastic.diff
<fabbione> out of the entire diff you need a one liner :)
<fabbione> and the debian/control is still due to LC_ALL=C thingy
* BenC worries about that URL being in his browser history
<BenC> fabbione: Should isofs really be "?"
<fabbione> BenC: i was not sure if it was module on all kernels.. so i just made it a failsafe
<fabbione> BenC: you are welcome to remove ? if you are sure it's not required
<fabbione> i didn't have all the images handy due to port being out of sync and blablabla
<BenC> pretty sure it is required
<fabbione> so i couldn't verify
<fabbione> oh and btw.. we need to update the getabis script to cope with the new lowlatency kernels
<Mithrandir> BenC: also, can you make the kernel build faster?  > 4 hours is getting excessive..
<Mithrandir> (or our i386 buildd is shit and should be taken out and shot)
<fabbione> Mithrandir: the latter :)
<fabbione> i so totally blame our buildd
<BenC> yeah, it only takes about 40 minutes for me
<kylem> let's just disable all the drivers for Mithrandir's hardware
<fabbione> Mithrandir: kernel build can fork... ask James to add CPU's.. many many CPU's with tons of sweet ram
<Mithrandir> kylem: I think "some" people might complain if X40s suddenly stopped working.
<fabbione> kylem: no, you really don't want to do that
<kylem> fabbione, no shit.
<fabbione> kylem: he has more hw than anybody else
<fabbione> kylem: it mean basically # CONFIG_BUILD_KERNEL is not set
* kylem should take a pic of his office sometime
<Mithrandir> kylem: if you have space for all your hardware in your office, you have too little hardware. :-P
<kylem> Mithrandir, heh, i don't
<kylem> BenC, how'd we want to go about uploading the security kernels? if you're ok with what's in git, pitti said he would upload the other day.
<BenC> kylem: I can upload if you want
<kylem> i've done testbuilds of both dapper and edgy -security, and they seem fine
<zul> hey
<zul> just got back from the ultrasound again baby's heart looks better but still inconclusive
<jbailey> BenC, kylem: There?
<zul> hey jeff
<jbailey> Heya Chck
<jbailey> +u
<kylem> jbailey, no.
<jbailey> kylem: ?
<kylem> jbailey, whaddaya want ;-)
<jbailey> When we come up with certification bugs on supported hardware.
<jbailey> Regressions specifically.
<jbailey> What's the best way to get those into the Kernel Team so that it gets prioritised appropriately?
<jbailey> We have an escalation process already for the support team into distro for customer things.
<jbailey> But curious about the cert side of it now.
<BenC> jbailey: that's a good question
<jbailey> Keybuk: Heya Scott
<jbailey> BenC: It's something to think abotu.
<jbailey> I want to make sure we give you the stuff in the most useful way possible.
<Keybuk> jbailey: heya
<BenC> jbailey: for regressions (like with qla2xxx), then the current way you guys have been doing things seems to be working
<BenC> jbailey: I don't know if we need anything more formal than an lp bug, and support pinging the kernel team till they wake up and get on it :)
<BenC> jbailey: Maybe you, I and Matt need to formalize how much priority we put on this stuff in comparison to our normal work though
<jbailey> Yeah.
<jbailey> I'll write something up and send it off.
<BenC> Keybuk: ping
<BenC> kylem: We have our private dir now...I'll let you know when it's ready
<Keybuk> BenC: sorry, on a conf call, can't talk right now
<Keybuk> what's the ping about?
<BenC> Keybuk: I want to take some of your time to talk about modprobe/udev
<BenC> Keybuk: When you get a few minutes can you ping me back?
<zul> BenC: still no sign of paravirt in linus' tree yet?
<BenC> zul: No, but the merge fest is still on-going
<zul> yeah
* BenC wonders how some files mode 444 from fabbione for into his tree on rookery
<zul> oh yeah when are we suppose to be doing the security uploads?
<BenC> zul: If you have breezy caught up, talk to pitti
<zul> ok
<Keybuk> BenC: IRC conversation or voip call?
<BenC> I don't have canonical voip setup, but my vonage let's me call uk for free
<BenC> Keybuk: /msg me a number on that other server? :)
<Keybuk> BenC: is this time tomorrow ok?
<BenC> yeah, sure
<Keybuk> I'm still on the "binary driver" call, and then will be having an evening and decorating the tree :p
<BenC> 19:30 GMT tomorrow?
<Keybuk> yup
<Keybuk> actually, can we make it 1900 ?
<Keybuk> TB at 2000 ?
<Keybuk> s/ ?$//
<BenC> Keybuk: ok
<Keybuk> BenC: do you have an ordinary (non-canonical) voip setup?
<BenC> it's vonage
<Keybuk> because you can just do a SIP call to scott@netsplit.com, if you didn't want to dial a phone number
<Keybuk> makes no real difference, except the phone number you'll be dialing is also a SIP gateway :P
<Keybuk> (so will get analogued along the way)
<dade`> BenC: do you have any news about macbook sleep ? 
<BenC> not sure how to setup this phone/voip gw to do SIP
<Keybuk> ok, no worries
<tepsipakki> kylem: do you have the fix for #72696 in your dapper tree?
<kylem> no. will get to that.
<kylem> tepsipakki, thanks for pointing it out
<kylem> BenC, backporting sky2 wasn't horribly difficult, i assume tg3 will likely be similar and can reuse the same compatibility code. shall i do that?
<tepsipakki> kylem: cool :)
<zul> kylem: fyi i had some problem with sky2 compiling with the xen crack when i was doing an update for the xen kernel but i got around it
<BenC> kylem: Sure
<BenC> superm1: I recall looking at lirc before, but I think it was too crappy to include or something
<BenC> superm1: I also remember ivtv
<superm1> well i know that there was a lot of breakage for it in edgy
<superm1> i2dc and gpio wouldnt build
<BenC> can you send me URL's to both so I can take a quick look?
<superm1> newest ivtv should have no trouble and uses module-assistant. http://packages.ubuntu.com/edgy/x11/ivtv-source
<BenC> module assistant means nothing when including it in the proper kernel
<superm1> and actually that version won't go against 2.6.19 - its intended for 2.6.17, i can get a package in that will though
<superm1> oh i see
<BenC> I want upstream source tarballs
<superm1> k, let me find the 2.6.19 tarball then.
<BenC> 2.6.19+
<BenC> we are going to have 2.6.20 in feisty
<superm1> http://dl.ivtvdriver.org/ivtv/archive/0.9.x/ivtv-0.9.0.tar.gz
<superm1> as of now 0.9.0 is intended for 2.6.19, i'm not sure what their take will be on 2.6.20
<superm1> and as for lirc, the CVS snapshots should build against 2.6.19 with less trouble on gpio and i2c, but it would probably be better to get the newer lirc in feisty before adding a snapshot of just the modules
<superm1> so probably hold off on the lirc until I can settle that with -motu
<BenC> superm1: ivtv seems to build ok
<BenC> I'll try to get it included in the next upload
<superm1> okay cool
<superm1> how soon will the pre2.6.20 kernels start popping up though?
<BenC> this week
<superm1> and this built fine against the pre 2.6.20 or the 2.6.19 currently there though?
<BenC> pre-2.6.20
<BenC> my local tree
<superm1> okay great then.  dont need to do too much digging to watch out for breakage :)
<BenC> I'll depend on you to test if it actually works, I just compile it :)
<superm1> hehe okay
<superm1> okay i'll see if i can't sort out the lirc mess to make sure we have something that would compile cleanly with all the modules.  i'll ping you again once i sort that with -motu
<superm1> thanks for getting this in :)
<jbailey> BenC: So it'll be interesting to see if my assertions that the Feisty kernel is fabulous and amazing continue to be true ;)
<BenC> jbailey: I hope so...2.6.20 merge fest is breaking all sorts of stuff in the ubuntu/ driver directory
<jbailey> Joy.
<jbailey> I haven't tried reading any of the git logs so far.
<jbailey> I figured I'd catch up at -rc1 =)
<jbailey> pre1,  Whatever Linus calls them now. =)
<dimach> Hi. Can someone point me to how compile a kernel module? Ubuntu wiki page says it can be done using kernel headers, but I can't find a guide for this.
<Bluhd> I've got a question about the timing resolution about the kernel
<Bluhd> whenever I run Rosegarden, it complains that the kernel's timing resolution is too low
<Bluhd> is this related to the fact that if you use sleep(1); in C++ that it sleeps for one second instead of one millisecond?
#ubuntu-kernel 2006-12-05
<jbailey> sleep is supposed to be one second...
<jbailey> You're thinking usleep.
<Bluhd> aha
<Bluhd> strangely enough, sleep under different OS's takes milliseconds
<Bluhd> I had no idea there was another sleep method
<jbailey> It really shouldn't.  I think POSIX.1-2001 says seconds..
<Bluhd> hmm
<jbailey> apt-get install susv3 for reference. =)
<Bluhd> what is the susv3 package?
<jbailey> Posix reference.
<Bluhd> ok
<jbailey> Single Unix Specification version 3
<Bluhd> ah
<dimach> Can I recompile driver/usb/serial only? I need support for keyspan HW.
<BenC> dimach: is that just a module?
<dimach> It is part of the kernel. .config can be set to CONFIG_USB_SERIAL_KEYSPAN=m . This means it is a loadable module, right? Can I build it as a module?
<dimach> I actually need this guy CONFIG_USB_SERIAL_KEYSPAN_USA19QI
<BenC> dimach: Odd, I should enable all those
<dimach> You mean I have to build whole kernel to enable support for this?
<dimach> I'll be back
<BenC> dimach: No, just those modules
<BenC> make SUBDIRS=drivers/usb/serial
<BenC> err
<BenC> make SUBDIRS=drivers/usb/serial modules
<dimach> BenC, thanks! I'll try
<zul> hey
<ajmitch> hi zul 
<BenC> whew...ubuntu-2.6.git is buildable again
<zul> cool
<zul> is it bootable?
<BenC> so far so good on all my machines
<zul> cool
<BenC> speaking of which, need to reboot
<blufox> how can i contribute to the ubuntu kernel as a developer? 
<dade`> blufox: https://wiki.ubuntu.com/KernelGitGuide
<blufox> dade`, thanks ... i am going through it :)
<zul> BenC, ping did it work?
<BenC> $ debian/rules printchanges | wc -l
<BenC> 1057
<BenC> maybe I should disable the upstream changes for the first 2.6.20 :)
<zul> hey
<kylem> BenC, wow, that's a big changelog :)
<zul> :q!
<zul> mmm...peanut butter
<zul> ummm...yeah https://wiki.ubuntu.com/MultimediaProductionKernel
<kjetilk_> In https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418 it was said that a fix might make it to an edgy update
* kjetilk_ is bitten,
<kjetilk_> so I wondered if there are news about that?
* Starting logfile irclogs/ubuntu-kernel.log
* Starting logfile irclogs/ubuntu-kernel.log
* kylem thinks turning off softlockup detection is a good idea.
<BenC> kylem: but wont that just make the lockup happen without notification?
<BenC> kylem: I show 8 changes from you in my latest pull from your k.o tree...that correct?
<BenC> HEAD SHA: 80b8e66e4b7ed12b8918c4440e37fd0bc898bd15
<BenC> that's edgy, btw
<kylem> hmm.
<kylem> 985f5bda111baef06fb69cbf2943d879c4a98227
<kylem> that's the top sha1.
<kylem> there's 10 commits
<mjg59> BenC: You never seem to have committed the patch I sent that adds support for the Apple webcam
<BenC> mjg59: It will go into edgy-updates, I didn't have time to add it before release because of kernel freeze
<mjg59> BenC: Sorry, to feisty
<mjg59> Or am I just missing it in the log?
<BenC> mjg59: nope, it's missing...it wasn't in the mactel patches, is it separate?
<mjg59> Yeah
<BenC> ok, I'll find it
<mjg59> Should really try to push that one upstream
<BenC> kylem: Well, I pulled from yours on k.o and got no more updates, so hopefully it's all good :)
<mjg59> I added the code for the firmware loading
<kylem> BenC, what's the top commit?
<kylem> the Subject line
<BenC> [UBUNTU:netfilter]  Fix thinko in CVE-2006-4572 fix
<BenC> that's your top commit
<kylem> that's the one.
<BenC> ok
<kylem> weird.
<mjg59> BenC: Oh, I like what you've done with the ubuntu directory
<mjg59> BenC: That's for external drivers?
<BenC> mj59: Yep...I no touchy touchy the stock code, except in rare cases
<mjg59> Nifty
* BenC just noticed today that up-apic-off-by-default was not enabled in edgy
<BenC> which only affects the -386 kernel, so probably not important
<mjg59> apic basically works nowadays
<kjetilk_> BTW, I had this backport wish the other day: https://bugs.launchpad.net/products/edgy-backports/+bug/73977
<BenC> yeah, I'm going to back out the patch I have been carrying for that
<kjetilk_> where I was referred to the kernel maintainers
<kjetilk_> I could have sworn I just heard sound from the box, but I'm not sure :-)
<BenC> kjetilk_: Don't think backporting alsa for edgy will ever happen
<BenC> kjetilk_: we're little more than 4 months away from feisty release, people can wait :)
<BenC> too much work just to save a couple months of waiting
<kjetilk_> hehe, right :-)
<kylem> kjetilk_, support for that is in edgy-updates.
<kylem> it's already been backported.
<kjetilk_> kylem: oh, cool
<kjetilk_> hmmm, so I need to have both that backport and the ipw3945 fix...
<kjetilk_> uhm, I couldn't find kernel packages on http://packages.ubuntu.com/edgy-backports/allpackages
* kjetilk_ <-n00b
<kjetilk_> isn't that where I was supposed to go...?
<BenC> zul: ping
<zul> BenC: pong
<zul> whats up
<BenC> zul: Have you uploaded breezy yet? If not, you can do so whenever you're ready
<zul> BenC: will do it tonight when i get home
<BenC> zul: cool, thanks
<BenC> Sony PS3 (PPC_PS3) [N/y/?]  (NEW)
<mjg59> Haha
<kylem> yesplease
<kylem> ;-)
<mjg59> Does it run a standard userland?
<mjg59> If so, yeah
<BenC> it should run standard userland
<BenC> I need to get a PS3 so I can get an ISO for it to run Ubuntu
<Mithrandir> BenC: sure, that's the only reason. :-P
<BenC> yes, purely technical reasons ;)
<zul> riiiight....
<BenC> Xbox 360 (X86_XBOX_360) (Exprimental) [M/n/?]  (OLD)
<zul> no...out of principal ;)
<Mithrandir> it's spelt "experimental"
<BenC> it's microsoft, what do you expect :P
<BenC> the paper clip guy told me I spelt it right
<BenC> not to mention, 360 is PPC too
<thom> an X86_XBOX_360
<thom> interesting :P
<Mithrandir> thom: not to mention the 360 being a module..
<BenC> that's the part I was hoping people would notice :)
<_MMA_> BenC: joejaxx is starting to look at making his Fluxbuntu project work on a PS3 if your interested maybe I should have him talk to you? I was gonna pitch in some cash to help buy the PS3.
<BenC> buying one is no biggie, if I could just find one
<BenC> and I don't mean a $2000 one from ebay :)
<_MMA_> true.
<Mithrandir> they're going to be closer to the .9kUSD mark or so, aren't they?
<_MMA_> Im gettin a Wii for the kids and am waiting till the fix the resolution issues on the PS3 before I get one.
<_MMA_> Mithrandir: Last I saw one went for 10k (US) On ebay.
<_MMA_> sad.
<BenC> Mithrandir: like $600 USD retail price, but demand is too high right now
<kylem> bloody TSO.
<_MMA_> Yea. I dont feel like gettin shot commin out of Best Buy.
<zul> damn you americans are crazy..
<_MMA_> BenC: I posted to -devel about the -lowlatency kernel. Hopefully I get some help with the spec.
<zul> wheee..must kill someone
<zul> is the git trees on kernel.org up to date?
<tiagoboldt> I'm running in a Intel(R) Pentium(R) M processor 2.00GHz(centrino). What kernel version should I use (386, 686, generic)?
<dade`> generic
<thom> tiagoboldt: user questions in #ubuntu please
<tiagoboldt> ohh, sorry:) Though of it as a kernel specific question, sorry:)
<Keybuk> BenC: ping
<kylem> zul, where is your git tree that you keep talking about in bugs hiding.
<zul> kylem: i sent the patches through the kernel-mailing list
<zul> you had the patches in your ubuntu-proposed trees
<kylem> no. not all of them.
<zul> gimme a sec.
<kylem> the ones on laptop.org are not up to date..
<zul> http://zulinux.homelinux.net/ubuntu/patches/
* kylem bookmarks.
<zul> you might not want to do that its just tempoary for now
<zul> ill have something more permanent shortly
<BenC> kylem: There's a tech-board meeting in 30-minutes...if you show up, they may get around to approving your upload-privs
<zul> heh..
<kylem> BenC, ok.
<BenC> kylem: For a carton of smokes, you may persuade me to speak on your behalf :)
<kylem> lol. done.
<kylem> there. tg3 is my bitch.
<infinity> kylem: For another carton of same, you also get my vote.
<zul> for some beer you get mine as well
<kylem> heh
<zul> kylem: i think we are expecting the beer and cigarettes soon or when its most convient..
<zul> and yes i have way too much sugar in my system right now
<zul> right later..
<BenC> this is great...I have two machines that 2.6.20 doesn't boot on
<BenC> and unfortunately that includes a P4 and the Xeon box, so it's not like their ignorable
<lifeless> doh
#ubuntu-kernel 2006-12-06
<zul> BenC: ping got a couple of minutes
<zul> ?
<BenC> zul: Just a little
<zul> sure so what should we do for the xen kernel?
<zul> since there isnt going to be paravirt-ops
<BenC> zul: I'm thinking unless something amazing happens, you should probably keep linux-source-2.6.17 around to build xen with
<zul> yeah thats going to be a problem since udev doesnt like 2.6.17 under fiesty
<BenC> we want to keep it in sync with one of our tarballs, but it looks like that wont be 2.6.20
<BenC> maybe we can talk to Keybuk about some edgy compatibility in udev
<zul> sure..
<zul> i can try with 2.6.20 as well
<Keybuk> BenC: ?
<zul> BenC, well let me try with 2.6.20 before we pull the trigger 
<BenC> Keybuk: Some people are saying that feisty udev + edgy kernel == badness
<Keybuk> BenC: should work fine, unless they need ide-generic
<zul> more like udev initramfs-tools badness
<BenC> edgy initramfs-tools?
<BenC> maybe explains the problem
<zul> yeah spits out a warning
<Keybuk> ah, hmm
<Keybuk> actually udev requires 2.6.19
<Keybuk> in feisty
<Keybuk> so initramfs-tools will refuse to make the initramfs
<zul> meh..
<zul> ok ill try to head to 2.6.20 then
<ajmitch> Keybuk: yeah, I've already had issues with trying to test xen updates, a bit of a pain
<zul> bald is what ill be then ;)
<Keybuk> ajmitch: the pain is outweighed against the pain of trying to guess anything that could break in 2.6.17
<ajmitch> kids will do that to you :)
<kylem> pfft, just buy more hardwar.
<kylem> to hell with this virtualization stuff.
<Keybuk> kylem: ENOMONEY
<zul> kylem: ditto ENOMONEY
<kylem> just stop buying food
<zul> well redhat looks like its doing 2.6.19 maybe that could be a happy medium
<kylem> GAH
<kylem> 6391 N Jeannette Mcgra Jeannette check this.
<zul> kylem: yeah im fat enough
<kylem> everytime i add to my .procmailrc, they change the damn thing
<Keybuk> tbh, I'd be really unhappy supporting divergent kernels
<Keybuk> e.g. if we go ahead and do the user-space binding in feisty
<Keybuk> then udev will be relying on that
<Keybuk> which won't work if you ran 2.6.19+xen
* ajmitch would like to keep his system booting
<ajmitch> I've already had enough issues with mdadm in feisty
* netjoined: irc.freenode.net -> anthony.freenode.net
<Keybuk> ajmitch: don't run feisty
<Keybuk> your system will be failing to boot for most of the development process
<ajmitch> I just don't reboot it very often
<zul> i wouldnt mind kvm but that eleminates alot of people from using virtualization
<zul> including me
<ajmitch> and I sort of need to test some of these things on hardware, which means running feisty
<ajmitch> xen in vmware doesn't go so fast
<zul> BenC: what about backporting paravirt?
<zul> breezy kernel uploaded and accepted
<kylem> zul, cool, thanks.
<zul> sweet...a twisted sister christmas
<xhaker> current feisty-alternate image presented odd behavior. I point my finger not only to debian-installer and the kernel until proof of the contrary.
<xhaker> If someone is still there and willing to hear say so
<BenC> describe it
<lifeless> xhaker: I think BenC wants to know what was odd
<xhaker> BenC, sorry I was filling a bug report about it. You can read it here. I assigned it to Colin Watson. But you should see it. since it is kernel related also
<xhaker> https://bugs.launchpad.net/distros/ubuntu/+bug/74592
<xhaker> lifeless, ;)
<BenC> you shouldn't assign it till it's confirmed
<xhaker> BenC, I didn't realize. I was trying to get colin's attention though.
<BenC> ok, none of that is a kernel bug
<BenC> the hda->sda thing is because we are switching from ide to ata modules..ata uses the scsi subsystem
<BenC> xhaker: Some of those issues may be know, so you may want to search debian-installer reports
<xhaker> BenC, my hard drive isn't scsi? :( joke
<xhaker> I don't think there are reports of these.
<AnAnt> BenC: ping
<BenC> AnAnt: yo
<AnAnt> BenC: I am using Edgy, and I found out that it doesn't support SD cards
<BenC> AnAnt: That's correct
<AnAnt> BenC: although in dapper it did
<BenC> are you sure?
<AnAnt> BenC: well, let me correct this
<AnAnt> while Edgy was still beta, I used Dapper's kernel
<AnAnt> but I applied a 2 line patch to support > 1GB cards
<AnAnt> and some colleage lent me his SD and I used it with that kernel (which was only patched to support >1GB cards) and it worked
<AnAnt> I will try it again later today to make sure though
<AnAnt> as I still have that kernel here
<lifeless> BenC: I have a SD card - or at least its ~ that form factor :) and it worked on dapper, edgy and fisty
<AnAnt> what's ~ ?
<BenC> around/about
<lifeless> its a sdcard slot, but it may be a less-proprietary card is what I mean
<AnAnt> oh
<AnAnt> BenC: btw, the SD card was a Transcend SD card
<BenC> AnAnt: Are you using it in the same type hardware slot?
<BenC> the card isn't as important as the hardware you are reading it with
<AnAnt> BenC: yeah, that TI slot
<AnAnt> BenC: in my laptop
<BenC> using the mmc driver?
<lifeless> BenC: is mine relevant, I can give details
<AnAnt> Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
<AnAnt> BenC: well, dunno which driver I use, it auto-detected 
<BenC> lifeless: Is it usb, or mmc?
<AnAnt> BenC: I recall there was another module with mmc that is loaded
<BenC> AnAnt: Yeah, check in /lib/modules/`uname -r`/kernel/drivers/mmc/
<AnAnt> BenC: there's sdhci there (in the dapper's kernel)
<lifeless> BenC: mmc
<lifeless> 02:01.2 Generic system peripheral [0805] : Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)  0805: 1180:0822
<AnAnt> lifeless: I think sdhci was loaded too, anyways, I'll try again when I go to work today
<lifeless> AnAnt: it neds to be if its going to work ;)
<AnAnt> BenC: btw, is there any simple article about the difference between CONFIG_PREEMPT, and CONFIG_PREEMPT_VOLUNTARY ?
<AnAnt> BenC: also sometimes I get a message saying something about "underrun", what's that ?
<BenC> AnAnt: voluntary is where preempt is done when the kernel calls yield()
<BenC> PREEMPT is real preemptibility
<AnAnt> BenC: well, I followed the thread about PREEMPT in devel, I don't care about sound, but I run simulations, and CONFIG_PREEMPT in dapper made them fast indeed
<AnAnt> BenC: but I'm not sure if VOLUNTARY in edgy made it slower
<BenC> AnAnt: Then the lowlatency kernel is what you'll want
<AnAnt> seems I got to test it
<AnAnt> BenC: ok, thanks
<AnAnt> does the "underrun" have to do with the voluntary thing ?
<AnAnt> ?
<AnAnt> BenC: does the "underrun" have to do with the voluntary thing ?
<BenC> probably
<AnAnt> thanks
<AnAnt> oh, what's the sky2 bug? is it skype related?
<AnAnt> "sky2 hardware hung" ?
<BenC> Subject: More ARM binutils fuckage
<BenC> I love it
* Starting logfile irclogs/ubuntu-kernel.log
<AnAnt> BenC: ok, I just tested it
<AnAnt> BenC: ping
<AnAnt> BenC: 2.6.15 kernel does support SD card
<AnAnt> BenC: I got this from dmesg:  mmcblk0: mmc2:b368 SDC   975360KiB <NULL>
<AnAnt> BenC: I'm using 2.6.17 kernel, now, it did detect the SD card too
<AnAnt> BenC: but it gave some errors in dmes
<AnAnt> BenC: but it gave some errors in dmesg
<zul_> heylo
<gnomefreak> is there no more ppc kernels?
<zul> BenC: ping when you get a second can i bounce an idea off you?
<BenC> zul: Sure
<zul> its xen related so it might drive you crazy
<ajmitch> run now
<BenC> someone needs to rename xen, it's pronunciation is a misnomer
<kylem> lol.
<zul> like you-are-going-to-make-me-pull-my-hair-out-and-shoot-myself-with-a-gun?
<Mithrandir> BenC: you clearly don't understand it, then. :-P
* Mithrandir hides.
<BenC> zul: We can call it crap for short
<zul> heh..
<BenC> Mithrandir: I must not be in the correct state of mind then :)
<zul> or yagtmepmyhoasmwag
<zul> kylem: ping
<kylem> yo
<kylem> just making some coffee, be back in a sec
<kylem> k
<zul> do you have the patch for CVE-2006-4572 for dapper?
<kylem> no, not without an abi change, i'm working on a better fix now.
<zul> ok can you pass it along when you are done for breezy?
<kylem> sure.
<zul> thanks, you are the best!
<zul> ill owe you a beer
* kylem remembers those giant beers at the black angus and shudder.s
<BenC> mmm...black angus
<zul> yeah more than enough to get my tipsey
<BenC> glad I checked that...I didn't hit the 'g' key well enough and almost typed it as "mmm...black anus"
<zul> lol
<BenC> zul: Oh, i meant to tell you, akpm said Andi still plans a 2.6.20 merge for paravirt-ops
<zul> thank god
<zul> so we should be ok?
<AnAnt> BenC: ping
<BenC> AnAnt: pong
<AnAnt> BenC: yeah, you got what I said about SD ?
<BenC> AnAnt: yeah
<AnAnt> BenC: I forgot to tell you that I tried a 2 GB SD but it didn't work
<AnAnt> will try again some day I hope
<AnAnt> one day I'll mail you the details (the errors from dmesg, and the 2GB SD & so)
<kylem> sigh. having a testcase for some of these CVEs would really be nice.
<BenC> kylem: Sucks when most of them are "in theory"
<BenC> but that one you are working seems like it could be tested with proper packets
<BenC> I don't know enough about ipv6 packets to write one up for you though :)
<kylem> me either
<Mithrandir> kylem: take a look at packit?
<zul> kylem: ping got the patch yet?
<kylem> sort of, i've sent it to patrick for reviwew.
<zul> ok cool
<BenC> bcollins@huffy:~$ uptime
<BenC>  17:32:22 up 1 min,  1 user,  load average: 0.36, 0.17, 0.06
<BenC> bcollins@huffy:~$ grep ata /proc/modules 
<BenC> bcollins@huffy:~$ grep ata /proc/ioports 
<BenC>   01f0-01f7 : libata
<BenC> bcollins@huffy:~$ dmesg | grep libata
<BenC> bcollins@huffy:~$
<BenC> I'd like to know how the fuck that can happen
<BenC> Hmm...the problem seems to come from a PCI quirk, but I'm not sure why it is triggering
<BenC> still doesn't make sense because that quirk should grab 0x170 too, and it doesn't
<BenC> oh wait, I see it
#ubuntu-kernel 2006-12-07
<holycow> hello
<holycow> would anyone be able to comment on whether or not backporting nforce drivers to dapper would make sense
<holycow> the 405 nforce chipset doesn't seem to be supported until the 2.6.18 kernel (still testing via feisty)
<holycow> and it would be nice to have that chipset supported under 2.6.15 if possible
<holycow> any comments?
<holycow> i would be willing to pay for the work
<BenC> holycow: How much? :)
<holycow> lol hi BenC 
<kylem> did you go to space too?
<kylem> :P
<BenC> holycow: Actually it does make sense, it's just a matter of time and testing
<holycow> well i don't know, i guess the question would be if its a reasonable idea and then if someone could kinda go okay it will take x many hours or so we can see if i can afford it
<BenC> if it's an easy backport, we can get it into dapper-proposed, and after some testing, move it into dapper proper
<holycow> okay reasonable idea taken care of i guess
<holycow> i would be willing to test of course
<holycow> i have 5 boxen here with that damned chipset ... i didn't do enough research before buying
<kylem> holycow, which parts of the chipset? you want forcedeth, intel8x0?
<kylem> i can't think of anything else that would be needed...
<BenC> yeah, I was going to ask that
<kylem> updating forcedeth is a reasonable request.
<holycow> kylem, the problem is nothing actually works on it ... not sound, not network card
<BenC> kylem: Want to look into the doing the dapper/edgy backport of that?
<holycow> nv drivers either but i can get away with vesa
<kylem> BenC, yeah, sure.
<kylem> i was doing tg3 for edgy-proposed (and then to dapper-proposed) for enablement.
<kylem> (and i've already done sky2, so forcedeth should be able to use the same compatibility wrappers i wrote for those two)
<holycow> well if you could tell me how many hours of work it is we can see if i can afford it i guess
<BenC> holycow: Best bet is to file a bug, target linux-source-2.6.15(dapper-updates) and linux-source-2.6.17(edgy-updates), and provide lspci -vv, lspci -vvn output for the board
<holycow> k
<BenC> holycow: We can't accept payment for doing work that we are already getting paid to do :)
<holycow> oh
<holycow> >_>
<holycow> thats not a bad proposition :)
<holycow> lol
<kylem> beer is good if you're ever in the same city though. :)
<BenC> you can make a donation to your favorite charity in Kyle's name though
<BenC> I think he likes the Good Bear Foundation
<holycow> only thing is i kinda need it soonish so was hoping to find out like what the work is like and if anyone can help out i can reciprocate of course
<kylem> www.childsplay.org :)
<holycow> i can donate indeedy :)
<kylem> oh. that's not it.
<holycow> i love charities
<kylem> www.childsplaycharity.org
<kylem> :)
<holycow> i work for a company that runs social service programs for the govt here ... i get what that whole thing is about
<holycow> i know others are buying this damned board so a lot of good will be solved for them
<holycow> lots and lots of posts on the boards about this chipset too
<holycow> http://www.asrock.com/product/AM2NF6G-VSTA.htm
<holycow> that would be the board
<BenC> holycow: Cool, then it is in our best interest to help support it
<holycow> NVIDIA NF6100-405 Chipset
<kylem> wow. they're on nforce6 already? :)
<holycow> BenC, ultimately yeah, i wouldn't expect anyone to really jump on this tho, hence my willingness to help out as well
<holycow> kylem, asrock boards arent bad, great for the super cheapies out there
<holycow> but i'm thinking of switching to the intel chipset
<kylem> oh. the audio should be supported in dapper-updates when it gets uploaded.
<BenC> holycow: One thing we support for sure, is Intel chipsets
<kylem> daniel chen already supplied backproted patches for that.
<holycow> BenC, so you guys would say go with intel chipsets? least headaches?
<holycow> is intel good to you guys? supportive or jerks?
<holycow> kylem, so i guess you are in the drivers seat here, i'm at your mercy :)
<holycow> lol
<holycow> getting sound and network card support is really all we need at the moment.  what sort of timeframes/time commitments might this look like?
<holycow> i'm not thinking you can have the answer right now :)
<kylem> soonish. :)
<holycow> okay, how do i keep in touch?
<kylem> best way is to do what benc asked, file a bug, target linux-source-2.6.15 and -2.6.17, and provide the lspci -vv and lspci -vvn (in seperate plain-text attachments preferably)
<BenC> holycow: This channel is where we dwell
<holycow> and let me know what you think is a fair donation to the charity, it should reflect something in the way of fairness for the work
<holycow> kylem, oh okay
<holycow> in other words not in the  next few days of course but probably couple of weeks is typical way of dealing with this?
<kylem> well, for an official fix it might be a while, but i can give you a test kernel in a day or so.
<BenC> holycow: If you really want to do that (and it's not required) then wait till the work is done, and base the donation on work performed
<holycow> that would be fine too, i will install separate supported network cards in the mean time.
<holycow> kylem, test kernel would be fine :)
<holycow> kylem, i didn't realize you had to make a new kernel, isn't everything modular?  no matter just curious
<holycow> BenC, cool i'll be here
<holycow> submitting bug now
<holycow> haveto make sure i have current dapper updates to give the correct lspci info
<BenC> holycow: lspci shouldn't change with whatever system you are running
<holycow> okay. right makes sense
<kylem> BenC, well, pci.ids would for decoding it.
<BenC> eh, we go by the -n output for driver matching anyway :)
<kylem> right.
<holycow> okay logged in ... forgot my launchpad pass for a bit
<holycow> :)
<holycow> am i posting a bug for a specific package?
<holycow> oh nm
<holycow> linux-source-2.6.15 and -2.6.17,
<holycow> got it
<holycow> #74745
<holycow> #7476
<holycow> oops
<holycow> #74746
<holycow> allrighty, i hope that is helpfull
<holycow> i'm greatfull you guys are willing to look into this
<holycow> kylem, thanks again
<BenC> holycow: You only need one bug report
<holycow> :/ sorry
<holycow> lets see if i can delete/close one
<kylem> we can merge them, it's fine.
<holycow> coolness
<holycow> thanks guys, greatly appreciate it
<holycow> i'm gonna get some sleep, if you need me feel free to msg me to test or whatever
<kylem> git is so much more pleasant when you give it its own u320 15krpm spindle to play on.
<infinity> And sex is more pleasant when you're not covered in paper cuts and dipped in lemon juice.
<infinity> Tell us something we don't know. :)
<kylem> unless you're into that sort of thing.
<infinity> If you are, you've crossed the line from "fetish" to "need your head checked".
<BenC> kylem: I've found that a raid5 with 4 10k drives works well too
<BenC> sucks when min hw req for a command line program exceeds that of vista :)
<infinity> Stop it.  You guys are upsetting my poor little laptop drive.
<kylem> 714M    ../nfs-shite.diff
<infinity> It has feelings, you know.
<kylem> ok. git whatchanged -p ${sha} >../foo.diff didn't do what i hoped ;-)
<BenC> infinity: atleast it can say it doesn't need a small nuclear plant to power itself
<BenC> kylem: git-diff-tree -p <sha>
<kylem> BenC, diff sha^..sha works too.
<BenC> I'm about to shoot 2.6.20
<BenC> in 2.6.17+ there's a pci quirk that reserves 0x1f0 ioport for libata
<BenC> and when ata_piix loads, it assumes this pre-reserved space, and pci_request_regions() plays nicely
<BenC> in 2.6.20 however, pci_request_regions() is now complaining that it's EBUSY
<BenC> even though the code from pci_request_regions() on down to __request_resource() hasn't changed
<BenC> and ata_init_one() hasn't changed either
<BenC> I'm going to need to do full bisect to figure this shit out
<kylem> ick.
<lifeless> meep
<Catshrimp> I realize this is a developement area (not support), but I was hoping someone could point me to a better place to ask this question.  I'm thinking maybe it's because the vga or vesa modules might not have been compiled into the kernel, but upon setting the vga= flag to my boot options, the screen remains blank throughout most of the boot process and I was wondering why.  No one in #ubuntu seems to know.
<infinity> Catshrimp: Which release?
<infinity> Catshrimp: And do you have any virtual consoles once the machine is done booting? (Ctrl-Alt-F1)
<infinity> Catshrimp: For the record, #ubuntu is the right place to ask this sort of thing, but whatever.  I'm feeling generous today.
<Catshrimp> infinity: Thanks.  The 6.06 release.  And It does show that I have multiple virtual consoles (I believe up to 6)
<Catshrimp> I only see the end of the boot process (starting at networking)
<infinity> Catshrimp: Okay, that has nothing to do with the kernel or the modules not being present/loaded, then, since clearly they work to drive the console.
<infinity> Catshrimp: Anything beyond that (like why you feel you're not seeing as much as you should) can head to #ubuntu to be argued. :)
<Catshrimp> infinity: no problem. I'll take it back to #ubuntu.  Though I just want you to know that I wasn't debating the modules weren't there.  I was wondering if maybe them being installed as loadable modules rather than being compiled into the kernel would cause them to be loaded late, and thus provide no output until loaded.
<infinity> Catshrimp: They certainly won't provide output until loaded, this is true.
<infinity> Catshrimp: Oh, wait.  You're not using usplash (or any splash).
<infinity> Catshrimp: That's a dapper bug.
<infinity> Catshrimp: vga= is meant to load vesafb in the initramfs, but in dapper, it only does so if you also have "splash" on the command line.
<infinity> Catshrimp: There.  Mystery solved.
<infinity> Catshrimp: I've never bothered to propose a fix to dapper-updates, since the bug is purely cosmetic, and not the sort of thing most people would ever care about (most people who use "vga=" tend to also be the sorts of users who would have usplash installed... places without usplash, like servers, tend to not use framebuffers at all, to avoid possible instability issues)
<Catshrimp> infinity: Not quite.  Splash present.  Tell you what, I'll check out .config and then compile a custom kernel.  Then if it's fixed, I'll let you know so that you guys can take whatever course of action you deem desirable.
<infinity> Catshrimp: Err, but if the splash is present, I'm heartily confused about the issue, since it sounded like you were referring to textual feedback.
<infinity> (And there's no way usplash would even run without some sort of framebuffer being enabled)
<Catshrimp> infinity: yep, textual.  it'll be a server, just want to be able to see what I'm doing without HUGE font :).
<Catshrimp> The only thing I edited in the original menu.lst was to add vga=792 to the kernel line.
<Catshrimp> infinity: let me do what I said and see if the problem is corrected.  I'll get back to you guys :)
<infinity> Catshrimp: This still sounds like the bug I was referring to.
<infinity> Catshrimp: Recompiling the kernel is serious overkill.
<infinity> Oh, wait.  I misremembered the bug, though.
<infinity> Catshrimp: Are you using a custom kernel, or one of ours, currently?
<Catshrimp> The VESA and VGA modules are both compiled as loadable as I thought.  Now, what is the name of the splash that you are talking of?  I don't get any feedback when I query SPLASH or USPLASH in the config
<Catshrimp> infinity: no, this is a basic install, nothing extra yet
<infinity> Catshrimp: Kay, if it's one of our kernels, then it's not the bug I was thinking of.
<infinity> Catshrimp: Anyhow, feel free to hash it out with others on #ubuntu, and if you find a real bug, file it.
<Catshrimp> infinity: no problem.  i'll hopefully be able to contribute more to the project than minor bugs here in a couple months :)
<BenC> kylem: Ping, #ubuntu-meeting
<Keybuk> oh, cool, .20 does away with struct class_device
<thom> Keybuk: will this crack udev stuff mean that udev handles setting sysctls also?
<Keybuk> thom: crack udev stuff? :p
<thom> the devices/drivers stuff
<Keybuk> it's been the plan for a while to move sysctl setting to a udev rule
<Keybuk> but needs the fix to the uevent ordering as well
<thom> right
<thom> cool
<gebruiker> what modules are still missing?
<gnomefreak> is there any reason why there is no safe mode kernels listed anymore? and would pcmcia be kernel issue or upstart or somethng else?
<zul> morning
<kylem> it is indeed morning.
<kylem> for the second time today.
<zul> heh oh yeah you had the meeting this morning how was it?
<gebruiker> i want the 2.6.19 latency kernel for edgy
<gebruiker> how can I build it on my system?
<gebruiker> I assume just modifying stuff in control? (i.e the libc6..)
<gebruiker> what further?
<gebruiker> s/latency/lowlatency
<zul> kylem: flu shots are fun..
<kylem> tired.
<zul> go have a knap then no one will notice ;)
<BenC> kylem: I got 3 hours of sleep, how about you?
<zul> hey ben
<kylem> heh. pretty much the same.
<BenC> hey zul
<BenC> kylem: for future reference, it's ok if you sleep in the morning following a meeting like that :)
<BenC> 4 revs left on the ata_piix debacle
<dade`> haha
<kylem> :)
<dade`> BenC: is the ata_piix stuff about sleep support ?
<BenC> no, it's about not working on my box in 2.6.20pre :)
<dade`> /o\
<zul> still funny: http://geekz.co.uk/blog/2006/08/26/gpl-nuances
<Keybuk> BenC: heh, oh, you're a *nice* manager then? :p
<Keybuk> I had the 8am meeting, and have a 10pm phone call
<Keybuk> *stretch that body clock*
<BenC> lol
<BenC> Keybuk: btw, your email on the plan was dead on
<Keybuk> good-o
<BenC> I finally got ata_piix working, so after I make my P4 stop softlocking, I'll start the kernel implementation
<Keybuk> sweet
<Keybuk> I'm happy to do lots of testing of your implementation
<Keybuk> making sure all the uevents are nice
<Keybuk> I assume you'll be basing it on .20 ?
<kylem> BenC, which commit ended up breaking it?
<BenC> kylem: Unfortunately I wasted my time finding a bug that was already known
<BenC> it was an Alan Cox patch to "cleanup legacy PCI quirks"
<zul> hah
<zul> i say cut AC out
<BenC> the fix was just posted yesterday, so I just missed it
<BenC> zul: Yeah, who needs those long-haired hippies
<zul> damn straight...oh wait...
<zul> you are a long haired hippie
<kylem> BenC, ah, ouch.
<zul> like those hairy beard hippies?
<gebruiker> hi guys
<gebruiker> how do I just build kernel-headers for lowlatency?
<pmjdebruijn> heh?
<pmjdebruijn> dat heeft geen zin zeg maar
<pmjdebruijn> hoezo?
<pmjdebruijn> oh sorry
<pmjdebruijn> gebruiker, that has no use? why would you want to do that?
<pmjdebruijn> gebruiker, ?
<pmjdebruijn> gebruiker, https://wiki.kubuntu.org/KernelCustomBuild
<gebruiker> i installed 2.6.19 fine 
<pmjdebruijn> huh?
<gebruiker> now I just want the kernel headers
<pmjdebruijn> how did you install it?
<pmjdebruijn> did you package 2.6.19?
<pmjdebruijn> anyway, you should
<gebruiker> added feisty to sources.list apt-get isntall lowlatency...
<gebruiker> it just isntalled the kernel en restricted modules
<gebruiker> it boots and works fine
<pmjdebruijn> oh
<pmjdebruijn> feisty
<gebruiker> now I need just the headers so I can build some wifi modules for my card
<pmjdebruijn> gebruiker, you need to build your own debs
<zul> BenC: you have a wiki page now apparently
<gebruiker> i don't want to upgrade my libc6
<pmjdebruijn> or just feisty's own debs
<pmjdebruijn> gebruiker, you're either running edgy or feisty
<gebruiker> i still want to run edgy but just not the 2.6.17
<pmjdebruijn> gebruiker, nothing in between, that'll give you a boatload of problems
<gebruiker> in debian I always had the possiblity to apt-pin
<BenC> zul: I thought I always had one...with a few lines about the DPL
<pmjdebruijn> gebruiker, that's not really on option
<gebruiker> pmjdebruijn, can i just build headers now?
<zul> BenC: https://wiki.ubuntu.com/BenCollins
<gebruiker> i have inovked apt-get source headers 
<pmjdebruijn> gebruiker, not as far as I know... but I'm not an expert
<pmjdebruijn> gebruiker, you're basically breaking your system now, though...
<zul> whoever okaratas is
<BenC> zul: Just my luck, bad english wiki entry :)
<gebruiker> well actually linux-headers doesn't contain any binaries right?
<pmjdebruijn> right
<gebruiker> and 2.6.19 runs fine all programs work fine etc.. etc..
<pmjdebruijn> gebruiker, if you package your custom kernel, the appropriate headers will be generated automatically
<pmjdebruijn> gebruiker, sigh... but installing stuff breaks!
<gebruiker> yes I know i did that with 2.6.18
<zul> BenC: heh its a little shrine :)
<gebruiker> but 2.6.18 with usb devices made my kernel panic
<kylem> BenC, apparently you're the developer of ubuntu. enjoy.
<gebruiker> and i choose ubuntu for a reason
<kylem> :)
<gebruiker> so i don't have to waste so much time compiling stuff
<pmjdebruijn> gebruiker, file bugs
<pmjdebruijn> gebruiker, anyway, you can make your own debs of 2.6.19 also
<gebruiker> so I can't just make-kpkg kernel-headers?
<pmjdebruijn> installing a feisty kernel on edgy is a bad idea
<pmjdebruijn> gebruiker, no
<gebruiker> or can I just invoke dpkg-rebuildpackage -fakeroot -us -uc ?
<pmjdebruijn> gebruiker, you need to build your kernel and headers, to do it properly
<gebruiker> so it would build against my edgy libc?
<BenC> kylem: I so rock
<kylem> hehe.
<pmjdebruijn> gebruiker, what does your libc have to do with it?
<kylem> and/or roll?
<gebruiker> with headers? nothing
<pmjdebruijn> gebruiker, anyway, remove the 2.6.19 and your feisty sources/packages@
<pmjdebruijn> then roll your own 2.6.19+headers for edgy 
<gebruiker> pmjdebruijn, what about the patches that are applied for 2.6.19?
<pmjdebruijn> gebruiker, if you read the wiki, you can apply them too
* kylem decides lasagna for breakfast is perfectly acceptable.
<BenC> linux-source-2.6.20-2.6.20$ rgrep INIT_WORK ubuntu/ | wc -l
<BenC> 72
* BenC cries
<kylem> most of them shouldn't be too hard to fix.
<kylem> i'm still dubious whether that patchset will remain.
<kylem> it's broken by design on a bunch of platforms... (it uses cmpxchg)
<kylem> BenC, i'm willing to bet that a whole whack of those are in ipw*.c
<holycow> hello
<kylem> paravirt is in.
<zul> sweet!!
<zul> buh bye hair pulling
<kylem> damn, this is one big ass pull. it's been 4 minutes and i'm still generating a pack file.
<zul> are we going to get ext4 for feisty? ;)
<kylem> die.
<zul> hehe
<kylem> * refs/heads/linus: fast forward to branch 'master' of hera.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
<kylem> it works so much better when you cut the mirrors out of the equation.
<kylem> where by "better" i mean "at all"
<dade`> ext4 is already in .19
<holycow> malone is pretty darned cool
<joefso> does the kernel-source from feitsy already contain the patches?
<joefso> how can I view the changelog of the kernel that is in git a.t.m?
<dade`> look in the debian/ dir
<dade`> and yes, there are patches too
<dade`> if you pulled the git source
<joefso> does kernel-source contain them? Are they already applied?
<zul> no
<joefso> git has?
<joefso> so I don't see anywhere on the wikipedia how to get the git linux from ubuntu tree
<zul> no it doesnt have the new ext4 patches
<dade`> https://wiki.ubuntu.com/KernelGitGuide
<dade`> https://wiki.ubuntu.com/KernelCustomBuild read this too
<joefso> what is so special about the lowlatency kernel? I.e what patches are applied?
<dade`> zul i have a .19 vanilla with ext4, why ?
<dade`> joefso: i only know that uses HZ=1000 and real preemption
<zul> dade`: im talking about the patches from today for ext4
<joefso> real preemption? -rt patch?
<dade`> no, RT are real time patches
<joefso> you consider -rt ready for production?
<joefso> does nobody consider real time patches ready for production?
<dade`> boh
<joefso> ?
<dade`> don't know, I'll try those 'cause I'm a musician. But now I don't know
<joefso> what's your opinon on -ck patchset?
<dade`> what are you a bot ?
<joefso> could it made into ubuntu repository?
<bronson> joefso: most people wouldn't even notice if RT is enabled on their system.  Unless it crashes.
<joefso1> i mean
<joefso1> it would be nice if it would
<joefso1> unless you would say there is no bennifit for community
<bronson> I've just merged linux-vserver into BenC's Edgy git tree.  It looks great except my kernel is named linux-image-2.6.17-10-ref-generic_2.6.17.1-10.34_i386.deb
<bronson> How can I change that -ref- to -vserver-2.2.0- ?
<bronson> (kernel *packages* are named...)
<bronson> I followed the instructions in https://wiki.ubuntu.com/KernelCustomBuild of course.
<kylem> bronson, which set of insns?
<kylem> the "building the kernel"?
<bronson> kylem: yes, AUTOBUILD=1 fakeroot debian/rules binary-debs
<zul> BenC: ping http://lists.osdl.org/pipermail/virtualization/2006-December/001828.html
<bronson> No word on how to change "-ref-" in custom-compiled kernel packages?
<bronson> When I build the kernel, I don't get a .changes file.
<bronson> That makes it harder to use dput.  Am I missing something obvious here...?
<BenC> bronson: AUTOBUILD=1 dpkg-buildpackage ...
<zul> BenC: when you get a chance can you pull from linus
<BenC> zul: So hopefully the only thing you'll be building is a dom0 xen kernel?
<zul> yep
<zul> probably going to be linux-image-2.6.20-xen or soemthing like that
<kylem> BenC, i started fixing up the INIT_WORK stuff
<zul> the vmware stuff can probably go into -generic
<BenC> kylem: Ok, I'm taking care of ipw3945 since it's the biggest (ab)user
<kylem> er. he.
<kylem> that's what i was doing, ok. will hit something else.
<BenC> no no, keep doing 3945 :)
<BenC> have you started?
<kylem> (i was looking at ipw3945 anyways, because i want to make it print something more useful when ipw3945d isn't running)
<kylem> yeah
<BenC> I've done everything except convert the = data to container_of
<kylem> oh. might as well continue then.
<zul> for ipw3945 can you check to see if the firmware is loaded and if not tell the user to install linux-restricted?
<BenC> zul: The firmwar is in the main kernel
<kylem> right.
<BenC> it's ipw3945d that needs to be checked
<kylem> it's a pity we can't get it built against uclibc or something.
<kylem> so we could put it in initramfs and just run it from a thread
<BenC> kylem: Thing is the module loads before ipw3945d...are you adding a timer to check if it gets started?
<kylem> BenC, i'm not sure yet, the thing doesn't register_netdev until ipw3945d is running (because they, for some reason, don't want the WEXT ioctls to fail)
<BenC> kylem: I've heard Intel plans on releasing a new driver where all of ipw3945d is in firmware
<kylem> yeah, keithp has told me similar.
<BenC> the time frame is here things start to get sketchy :)
<BenC> s/here/where/
<kylem> indeed.
* BenC just woke back up
<kylem> lol.
<kylem> nice nap.
<zul_> damn it kicked the powerswitch
<zul> i was just thinking of way to cut down on the bugs in launchpad
<kylem> oh jesus.
<joefso> i got the kernel from git, and I have read both wiki pages(how to get from git, how to build customize kernel) however, where does it say, how to apply all i386 patches for ubuntu on the git tree? Like speakup etc.. etc..
* kylem pukes at wlan_compat.h
* joefso reaches out with bucket
<mjg59> joefso: They're applied already
<mjg59> If you've got the ubuntu kernel
<joefso> I got ubuntu-2.6.git ubuntu-2.6
<mjg59> Right
<mjg59> The patches aren't available separately
<mjg59> They're already integrated into the tree
<joefso> So all patches are already applied?
<joefso> :)
<joefso> No need, if they are applied them I'm fine with it
<joefso> great :)
<zul> later
<bronson> BenC: thanks, I'll give it a shot.
<kylem> BenC, oh god, some of these drivers make me cry.
<BenC> kylem: They are horrible ugly
<kylem> should measure vendor submissions in approximate viro-curses.
<BenC> kylem: Have you started on rt2x00?
<BenC> if not, I'll move on to that
<kylem> no
<kylem> i've got everything but that and ipw3945 now
<kylem> going through what i've changed and making sure i've caught all the prototypes. :/
<gnomefreak> is ther ea reason we dropped the safe mode kernel in feisty?
<gnomefreak> s/ther ea/there a
<BenC>         INIT_WORK(&master->toggle_work, &rfkill_toggle_radio, NULL);
<BenC>         INIT_WORK(&master->poll_work, &rfkill_list_poll, NULL);
* BenC gets a few easy ones
<kylem> there's some doozies in rt2x00.
<kylem> http://people.ubuntu.com/~kyle/workqueue-ubuntu.diff
<BenC> kylem: Thanks
<kylem> i didn't build test though, you get to keep both pieces of anything breaks. ;-)
<BenC> hehe
<BenC> son of a bitch
<BenC> yeah, I see what you mean about rt2x00
<bronson> I just got a warning that my git tree is in a directory of the wrong name.  Scrolled by before I could copy it.
<bronson> Is this important?
<bronson> Should I keep BenC's git tree in "linux-source-2.6.17-XX" instead of my current "ubuntu-2.6.17"?
<BenC> it's just a warning, ignor eit
<bronson> cool, thanks.
#ubuntu-kernel 2006-12-08
<shwag> what kernel does  dapper server  install by default ?
<BenC> the -server kernel
<shwag> what is the difference between  linux-image-686  and  linux-686-smp  ?  they both actually appear to be SMP
<joefso23jh> with and wihtout preempt?
<JanC> -smp is a meta-package 
<joefso23jh> I pulled 2.6.19 from git today
<joefso23jh> and I got: http://pastebin.ca/270903
<JanC> to make sure those who had an smp kernel in previous versions of Ubuntu didn't get stuck with an old useless kernel after an upgrade
<joefso23jh> (while building the same config from 2.6.19 feitsy)
<joefso23jh> s/the/with the/g
<JanC> shwag: almost all kernels are smp-ready since dapper 
<kylem> joefso23jh, so?
<joefso23jh> is there any fix?
<shwag> Yah it looks like, linux-686-smp   is preemt ... while  linux-image-server   is not preemt.
<kylem> it's in git. not uploaded.
<joefso23jh> so it's known?
<kylem> why don't you go get the source from feisty.
<joefso23jh> cause packages.ubuntu doesn't seem to be uptodate
<shwag> uhh...how do I safely remove  linux-686-smp from my system ?
<joefso23jh> apt-get remove --purge ?
<shwag> joefso23jh: will that put grub back properly ?
<gnomefreak> i use synaptic its much neater for kernel removal i have found
<qhartman> Intel has released a security advisory about a buffer overflow in their e100/e1000 nic drivers at http://support.intel.com/support/network/sb/CS-023726.htm
<qhartman> this seems to affect Ubuntu, given the versions they mention.
<shwag> so I installed a kernel image and now I regret it. How do I put grub back to the old kernel ?
<shwag> common team...that should be an easy question.
<shwag> <soundray> shwag: you can select a kernel for the next boot with grub-reboot (check man grub-reboot).
<shwag> <soundray> shwag: reboot and select the older kernel to boot. Then remove the new kernel with 'sudo apt-get --purge remove linux-kernel-(version of the new one)'. The grub entry will be removed automagically
<JanC> shwag: this is not a support channel...
<shwag> my bad
<JanC> and tehre is no kernel in the -smp package
<BenC> Paravirtualization support (EXPERIMENTAL) (PARAVIRT) [N/y/?]  (NEW)
<BenC> yummy
<BenC>   10. Core 2/newer Xeon (MCORE2) (NEW)
<BenC> hmm...wonder if it's worth it to do a Core2 kernel
<mjg59> Doubt it
<bronson> BenC: building with dpkg-buildpackage did indeed get rid of the -rel- like you said.
<bronson> But now it has the identical name to Ubuntu's package.
<bronson> Is there any easy way to insert my version in the package name?
<bronson> Something like EXTRAVERSION = .14-ubuntu1-vs2.0.2.1
<bronson> ...  actually, I think I know the answer.  I need to add a changelog entry?
<bronson> Is there any way with dpkg-buildpackage to only build 386?  These 5 hour compile cycles are killing me!
<BenC> bronson: rm configs you don't want from debian/config/i386
<bronson> BenC: thanks.
<Game_Ender> Is this the proper channel to discuss compiling a kernel module from upstream?
<Game_Ender> I am looking at the Attansic L1 Ethernet driver
<lifeless> yes, I think so
<Game_Ender> Can someone point me the right direction of what I would do with patch set once I get it?
<Game_Ender> The driver is being worked on as a patch for 2.6.19
<Game_Ender> So I could remove my current kernel module (compiled from the source on my motherboard CD)
<Game_Ender> then try to apply the patch to ubuntu kernel module
<Game_Ender> I would then have to configure the entire kernel to build that one module correct?
<Game_Ender> well its off to sleep
<Game_Ender> I should probably try when its not 11PM - 1AM in the US
<joefso>   CC [M]   ubuntu/misc/dm-bbr.o
<joefso> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
<joefso> ubuntu/misc/dm-bbr.c: In function 'bbr_alloc_private':
<joefso> ubuntu/misc/dm-bbr.c:102: error: 'INIT_WORK' undeclared (first use in this function)
<joefso> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
<joefso> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
<joefso> make[3] : *** [ubuntu/misc/dm-bbr.o]  Error 1
<joefso> make[2] : *** [ubuntu/misc]  Error 2
<joefso> make[1] : *** [ubuntu]  Error 2
<joefso> i'm trying to compiles 2.6.19 on edgy
<joefso> using make oldconfig
<joefso> however, it fails as we see
<gebruiker> 2.6.19 doesn't build on edgy
<dade`> I think it does
<gebruiker> YOU THINK?
<gebruiker> jeejz
<dade`> yes I can think
<gebruiker> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
<gebruiker> ubuntu/misc/dm-bbr.c: In function bbr_alloc_private:
<gebruiker> ubuntu/misc/dm-bbr.c:102: error: INIT_WORK undeclared (first use in this function)
<gebruiker> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
<gebruiker> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
<dade`> how  do you compile it ?
<gebruiker> sudo make-kpkg --rootcmd fakeroot --initrd --append-to-version=-1 kernel-image kernel-headers
<dade`> is this a git kernel ?
<gebruiker> yes
<dade`> ok wait
<dade`> https://wiki.ubuntu.com/KernelCustomBuild
<dade`> read this
<gebruiker> yes I did?
<dade`> no you didn'y
<dade`> t
<gebruiker> dude
<gebruiker> even if the code is *not* from git
<gebruiker> the code fails with the same error when using linux-source-2.6.19_2.6.19-7.11.tar.gz
<dade`> well, I don't know, but compiling a git kernel with that command is wrong.
<gebruiker> there is no guide on compiling git kernels the proper way
<dade`> I just gave you
<gebruiker> kernelcostumbuild?
<gebruiker> have you read it?
<dade`> yes
<gebruiker> what a bunch of crap dade` even invoke just 'make' makes the build fail
<dade`> ..
<gebruiker> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
<gebruiker> ubuntu/misc/dm-bbr.c: In function bbr_alloc_private:
<gebruiker> ubuntu/misc/dm-bbr.c:102: error: INIT_WORK undeclared (first use in this function)
<gebruiker> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
<gebruiker> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
<gebruiker> make[2] : *** [ubuntu/misc/dm-bbr.o]  Fout 1
<gebruiker> make[1] : *** [ubuntu/misc]  Fout 2
<gebruiker> make: *** [ubuntu]  Fout 2
<gebruiker> BenC broke the tree ;\
<lifeless> gebruiker: sounds like you are building against an upstream kernel, not an ubuntu one
<gebruiker> no
<gebruiker> it's pulled from git
<gebruiker> according to the kernelGitGuide
<gebruiker> i don't thing dm-bbr.c is in vanilla
<lifeless> its not
<lifeless> its part of the evms patchset
<dade`> have you tried using 'AUTOBUILD=1 fakeroot debian/rules binary-debs ...' on a clean git source ?
<gebruiker> how does one let it build it's own config without affecting the debian tree/
<gebruiker> ?
<gebruiker> UTOBUILD=1 fakeroot debian/rules binary-debs flavours=386 doesnt' even work
<gebruiker> +a
<zul> BenC: ping
<BenC> zul: yo
<zul> i was thinking that the vmi (vmware stuff) can go straight into the generic kernel but the xen bits of paravirt would need its own flavour...of course i would have to test tis
<zul> *this
<zul> damn i need more coffee
* kylem obtains coffeee.
<zul> hey kylem 
<BenC> yay, ubuntu-2.6 is building again
<zul> workqueues fixed?
<BenC> workqueue, freezer, crypto API's, SLAB_* crap
<zul> cool
<BenC> 2.6.20 is a bigger leap than 2.6.19, which scares me
<zul> heh ill break it again for you dont worry..:)
<BenC> $ debian/rules printchanges | wc -l
<BenC> 2423
<kylem> jesus.
<zul> ouch..
<BenC> zul: upstream is doing a fine job of it already :)
<dade`> now git is .20 ?
<BenC> dade`: 2.6.20-pre
<BenC> Keybuk: ping
<Keybuk> BenC: yo
<BenC> Keybuk: I think I figured out the missing bit for "the plan"
<dade`> maybee this one will sleep WITH macbook
<BenC> Keybuk: I was wondering how all this would work when udev didn't have a "rule" for device->driver, and we wanted binding to just work...udev had no info on this
<dade`> (wow sexy)
<Keybuk> go on?
<BenC> Keybuk: So what I am going to do is make the kernel send a "match" event for when it would normally bind with a device, so that udev can send that bind to the driver
<Keybuk> how do you mean?  over the netlink socket?
<Keybuk> how would you know udev was on the other end?
<BenC> if auto-bind is disabled, the kernel would send an event of some kind saying "this driver and device match, do something", and whatever is on the other end would do that thing
<BenC> Keybuk: unless I'm missing something, in the plan you have now, if udev disables auto-bind in the kernel, there's nothing that says to actually do the binding on devices that don't have a specific driver rule
<BenC> kylem: I don't see CVE-2006-4572 listed in your dapper changelog
<kylem> BenC, i still haven't heard back from patrick, i pinged him again last night.
<Keybuk> BenC: the plan was that there'd be a generic rule
<BenC> kylem: So are we uploading dapper without 4572 fix?
<Keybuk> make DRIVER= work like NAME=, so the first one sticks
<Keybuk> then just do specific stuff early
<kylem> BenC, yes, pitti wanted it uploaded because of a local root hole, iirc
<Keybuk> and as a final rule, just have a general ENV{MODALIAS}=="?*", DRIVER="modprobe $env{MODALIAS}"
<Keybuk> (where modprobe is the udev builtin thing)
<zul> so breezy is ok as well since it doesnt have CVE-2006-4572 and its already been uploaded previously
<Keybuk> BenC: the one thing I was thinking; bind and unbind override the usual device tables, yes?
<BenC> Keybuk: Sure, that will load the driver, but I mean what will cause the bind?
<kylem> BenC, 4572 isn't exactly what i'd call a critical hole...
<BenC> kylem: Ok, just making sure I had everything
<Keybuk> BenC: I was thinking we just make udev always do it
<Keybuk> so as well as making /dev nodes, one of its other primary functions is to bind devices and drivers
<Keybuk> so after processing a rule, if there's any DRIVER set, it binds it
<BenC> Keybuk: but what if there's no driver set? :)
<Keybuk> we'd set one from the alias tables?
<Keybuk> as a default rule
<BenC> ok
<zul> i so much dislike rpm
<joefso> where can I get a list of patches that are applied to ubuntu kernel tree?
<zul> git
<joefso> yes git can pull them in
<joefso> howveer I want a _list_ of patches
<joefso> that are applied to the src tree
<BenC> joefso: Is this ubuntu-2.6?
<bronson> Can anyone suggest a version number for my linux-vserver enabled kernel?  I'm basing it off kernel 2.6.17.1-10.35 and adding vserver 2.0.2.1
<bronson> Would that be 2.6.17.1.vserver2.0.2.1-10.35?
<bronson> Or should I change something else?
<BenC> bronson: I actually suggest just making a new flavour
<bronson> BenC: sounds good.  How do I do that?
<BenC> bronson: Copy debian/config/i386/*.generic to *.vserver-2.0.2.1
<BenC> and edit was needed
<BenC> then do : debian/rules debian/control.stub
<bronson> Ah, OK.
<BenC> and do the normal build
<bronson> Would it make sense to have generic-vserver2.0.2.1, server-bigiron-vserver2.0.2.1, etc?
<bronson> That would make sense to me, anyway.  :)  I'll try it.
<bronson> BenC: I also need to change the files in debian/abi/2.6.17-10.34/i386 right?
<BenC> no
<BenC> ignore those
<BenC> bronson: Edit debian/rules and set skipabi=true
<bronson> ah, ok.  Will do.
<bronson> I notice that the kernel is .34 but the abi is still .33 in the 2.6.17 git tree.
<BenC> .33 is not the ABI
<BenC> the ABI is 10
<BenC> .33 and .34, those are the release revs
<BenC> it increments everytime we do an upload...the 10 is only incremented when the ABI changes
<bronson> I mean, the directory is named debian/abi/2.6.17-10.33
<BenC> right, we keep the previous abi's to compare with the current build
<bronson> cool.
<BenC> current ABI's are only known after the build, so we can't very well keep those in the upload
<bronson> :)  got it.
<bronson> thanks.
<bronson> BenC: skipabi was true because I'm using AUTOBUILD=1.
<bronson> I think there's a missing skipabi check at line 238?
<bronson> That exit 1 always fires regardless of the value of skipabi.
<bronson> Yes, adding '-a "$(skipabi)" != "true"' to debian/rules line 238 appears to work.
<joefso> Benc Yes.
<BenC> joefso: debian/rules diffupstream > ubuntu.diff
<joefso> BenC, however i want to apply -rt but acpi problems
<bronson> BenC: I just thought of something.  My packages are built from a different source tree than the ubuntu kernel.  But if I only change the flavor, then my packages will claim to be built from the regular Ubuntu kernel source.
<bronson> I need to change the package name too?
<joefso> BenC, would it beneift community if we would package -ck kernels ontop of the -generic patched kernels?
<BenC> joefso: No
<joefso> or s/lowlatency/ck
<joefso> BenC, could you eleborate a bit?
<BenC> lowlatency is just a config option change
<joefso> i noticed hz change
<BenC> I'm adding any any very obtrusive patches to our tree
<joefso> but wha'ts the reason that -ck tree wouldn't benefit community?
<BenC> it wont benefit our users
<BenC> 1) Creating too many kernel package options confuses users
<bronson> joefso: what -ck feature do you want?
<BenC> 2) Adding huge patches to our tree makes it hard to maintain
<joefso> well 1) we already have lowlatency in feitsy 2) ck isn't that dificult to main, most of the time it applies clieanly ontop of the git tree 
<BenC> joefso: You are more than welcome to provide such kernel packages yourself though
<BenC> joefso: You've no idea what it takes to maintain the kernel once you've added patches that modify stock kernel code
<BenC> security, updates, changes from upstream, all these things break it
<BenC> I just spent the past two days getting our ubuntu/* drivers to build under 2.6.20-pre git
<BenC> that's easy because it didn't touch stock kernel code
<joefso> well, most of the time con just takes vanilla and then inclues latest stable into his patchset. However just applying them from broken-out is not much work until now, atleast those a re my experiences. And I have used it for quite some time now. The only thing I havn't really done is benchmark them to ubuntu kernels.
<joefso> well perhaps I should take it for testing through ubuntuforums?
<joefso> and see where it gets me
<joefso> and how the community reacts
<BenC> joefso: What is in -ck that would be so beneficial?
<joefso> mm-*prio
<joefso> *-ionice
<BenC> why are those patches not in mainline kernel?
<BenC> that's not really a question, it's more of a statement
<joefso> yes I noticed
<BenC> they aren't in there because they aren't stable yet
<joefso> did you ever had time to take a look at it?
<BenC> give me a URL?
<joefso> and I remember some time where andrew morton would put ck code into -mm
<joefso> http://members.optusnet.com.au/ckolivas/kernel/
<BenC> -mm isn't a stable tree by any means :)
<BenC> eh, it already gets a big NO
<BenC> latest is against .18, and we are doing .20pre
<joefso> take a look at the patches dir
<joefso> perhaps i(havn't looked yet) there are patches for .20pre in testing patches
<BenC> even .19 is not good enough
<joefso> and if it's worth con kolivas could even provide it, if we would just ask, or else fix up the broken diffs our selves. Form the point I have seen it all he does until now is keepon syncing code with current stable.
<BenC> joefso: 33 changes files, and 125k diff
<BenC> that's more than our current delta against the mainline kernel
<BenC> by almost double
<bronson> BenC: Instead of creating different flavors, I need to create packages with an entirely different base name?  Does that sound right or am I missing something?
<BenC> bronson: Why?
<bronson> Because if I only change the flavor, my package will still claim to be built from Ubuntu's source package.
<bronson> It's not though...  I've applied the linux-vserver patch.
<BenC> it will be linux-image-2.6.17-10-vserver package name though
<bronson> But it still claims to be built from linux-source-2.6.17-10 right?
<BenC> if you want that much differentiation from our source, I can't help you...way too much involved
<bronson> Well, the source issues are solved.  It's the packaging issues that are stumping me.  :)
<BenC> you're getting into common packaging questions that are probably best solved in #ubuntu
<bronson> Am I?  Not many people there have dealt with control.stub...
<bronson> Or kernel flavors.
<BenC> but you want to change the source package
<BenC> which actually is as simple as editing the changelog
<bronson> Or building with -sa.
<bronson> I guess you're right -- it's not a problem.  I must have screwed up reprepro somehow.
<bronson> My package's source package: linux-source-2.6.17_2.6.17.1-10.34.vserver2.0.2.1.tar.gz  :)
<bronson> I don't think there's quite enough version numbers in there...  maybe I could add grsecurity.
<low_> hi
<bronson> hi low
<joefso23> hello
<joefso23> I'm unable to use "!" when invoking dialog --yesno "tekst" 5 80
<kylem> and?
<joefso23> when i add a ! to the "tekst" I get: rror: Expected no more than 3 tokens for --yesno, have 5
<kylem> how is this a kernel problem.
<joefso23> damn wrong channel
<joefso23> excuse me
<kylem> ps: add a \
<joefso23> no won't do, but anyway excuse me
<kylem> works in zsh. ;-) try single quotes instead of double in bash.
<bronson> BenC: When I run debian/rules debian/control.stub, a bunch of packages get "-ref" added to their names.
<bronson> Is there an easy way to make -ref not appear?
<BenC> bronson: no
<bronson> So just live with it?  :)
<bronson> OK.
<BenC> you're trying to do stuff that the build system there wasn't designed to do
<BenC> you're sort of on your own :)
<bronson> True.  I can live with that.  Hope you don't mind if I ask you easy questions though.
<BenC> joefso23: I wrote this up real quick, since your question about including patches comes up quite often
<BenC> joefso23: It explains things in more detail
<BenC> https://wiki.ubuntu.com/KernelPatches
<bronson> BenC, can you tell me briefly where -ref comes from?
<BenC> what do you mean by -ref?
<bronson> linux-headers-2.6.17-10-ref
<BenC> I don't know what -ref is
<bronson> (from the debian/control file)
<BenC> is that what it actually says?
<bronson> Yes, it showed up when I ran debian/rules debian/control.stub.
<bronson> I'll dig deeper.
<BenC> if you actually see "-ref" then you likely buggered something to make it do that
<BenC> head -1 debian/changelog
<BenC> let me see that
<bronson> The full line is "Package: linux-headers-2.6.17-10-ref"
<bronson> not all names have -ref, just some.
<bronson> here you go: linux-source-2.6.17 (2.6.17.1-10.34.vserver2.0.2.1) edgy; urgency=low
<bronson> No, it didn't show up when I ran debian/rules debian/control.stub .  That went OK.
<bronson> I'll dig into this further before asking more.  And start with a fresh git tree.
<BenC> that's the problem
<BenC> do not add the .vserver2.0.2.1 in the versioning
<bronson> Ah, good.
<bronson> Is there a place I can maintain a rev number?  I don't expect to get this package right the first time.  :)
<bronson> Or do I just need to bump the .34 to .35 and diverge from your upstream package?
<BenC> that's the idea
<bronson> OK, will do.
<bronson> Thanks.
<cassidy> guys, i'll pay you a beer at next FOSDEM or GUADEC if you package the fix for this bug ASAP https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418  :)
<cassidy> i just received my new laptop and it's very frustrating to not be able to use it ;)
<BenC> cassidy: is this the ipw3945 softlockup when rfkill is on?
#ubuntu-kernel 2006-12-09
<BenC> if so, isn't it "fixed" by not disabling the wireless?
<cassidy> BenC: yes it is
<cassidy> but i like my wireless ;)
<BenC> I don't get it, I thought the bug only occureed when wireless was disabled on boot
<bronson> cassidy: so don't disable it...?
<kylem> BenC, we can take this patch, it looks sane.
<cassidy> it's strange in fact. I had this bug booting Herd 1 CD. Try to disable it and still have the problem. But retry after and then work
<kylem> http://bughost.org/bugzilla/attachment.cgi?id=956
<BenC> "I have been booting daily with wireless switch on two weeks and the problem has not occured. Today I booted with the Wireless switched off and had soft lockup on CPU0"
<BenC> kylem: My main question was why Intel hasn't taken it
<BenC> could be because they are moving on to that new driver
<BenC> kylem: But yeah, for edgy it looks sane
<kylem> i don't think ketrenos has done much recently.
<kylem> the problem with this softlockup stuff is noone ever seems to post their dumps, so we have no idea if it's the same bug...
<kylem> BenC, the bug is in ipw3945 1.1.3
<kylem> er
<kylem> the bug fix
<BenC> is there a 1.1.3?!
<BenC> there wasn't when I checked just YESTERDAY
<BenC> kylem: Does it have better fixes for the INIT_WORK crud?
<kylem> was released today
<kylem> INIT_WORK() is still muckered in it.
<BenC> we can probably do a diff between 1.1.2 and 1.1.3 and apply it
<kylem> they all take priv though, so the fix when they do take it is going to be the same as what you or i did
<kylem> hm, i'll do it, shouldn't be too much pain.
<BenC> kylem: I think ipw3945 was one of the ones where there was more to it than that
<BenC> I have to check
<BenC> some of them were using work and delayed work interchangeably, which is totally broken now
<BenC> yep, it is
<kylem> eh, i was just going to pull out your diffs and reapply on top of 1.1.3
<kylem> <- lazy... ;)
<BenC> probably easier to get 1.1.2 and 1.1.3 and diff them, and apply to ours
<BenC> kylem: Looks like either way is going to be a pain
<kylem> it's not big a deal
<zul> BenC: i like the new kernelpatches page and the gratitious use of xen as an example ;)
<BenC> zul: You noticed that, huh? :)
<zul> yeah..
<zul> you should rename it whyihatexen
<kylem> BenC, you weren't kidding.
<BenC> kylem: have fun :)
<kylem> heh. i'm amazed this built for you.
<kylem> ipw3945 was still missing some delayed stuff.
<kylem> but would still work b/c struct work_struct is the first member of the delayed_work struct.
<BenC> There's actually a bit of stuff in ubuntu/ that still needs delayed work help
<BenC> mostly some of the many (I hate them) ieee80211 stacks
<kylem> yeah.
<kylem> i'm fixing those up now.
<kylem> i hate david howells. :)
<kylem> ugh.
<zul> night folks
<kylem> jesus. that took way longer than i'd expected.
<kylem> BenC, fixes for wireless/ and updated ipw1.1.3 pushed out to my ubuntu-2.6 kernel.org tree.
<BenC> kylem: Thanks
<BenC> kylem: pulled and pushed, and compile tested
<BenC> looks good
<kylem> btw, in your rt2x00 i'm not sure about the nested container_of
<kylem> i think it might need to be: container_of( &container_of( ... ), ...)
<BenC> the container_of returns a pointer, so it should be ok
<BenC> plus it doesn't give a warning either :)
<kylem> ah, ok
<BenC> kylem: I'm doing some build/boot testing tomorrow...if things look ok, I might do an upload, but without lrm and linux-meta
<kylem> alrighty.
<BenC> 2.6.20 scares me
<kylem> churn churn churn :)
<BenC> between the workqueue changes, paravirt, and now a brand new HID layer, I'm frightened
<kylem> so feisty is totally vetoed from being LTS, k? :)
<BenC> definitely
<zul> paravirt shouldnt matter if you dont enable it
<zul> ..couldnt sleep
<BenC> it's not enabled, but I doubt that it's a noop code wise even disabled
<zul> true
<bronson> Anyone in today?  Is there an easy way to create a new ABI?
<bronson> I'm getting the "ABI has changed!" message and I'd just like to tell it, THIS is the new ABI...
<bronson> Can't find any docs on how to do that though.
<kylem> increase the major version # in debian/changelog
<kylem> ie the xx part of 2.6.17-xx.yy
<bronson> ah, good.  Thanks kylem.
<bronson> I hope I'm getting close to having a good kernel.  What's the best way to show it to you guys to see if it could become a part of Ubuntu proper?
<bronson> (not as a patch, as a set of kernels that live beside the main kernels)
<bronson> Just publish my git tree?
<kylem> probably easiest for you, yes
<bluefoxicy> how do I rebuild 2.6.19-7-generic from source... I can't find the right debian/Config stuff
<bluefoxicy> oh.. downloaded the source wrong
<bluefoxicy> ls
<bronson> Seems a little silly to publish hundreds of megabytes of git archive so you can pull a few K of patches but so be it.  :)
<kylem> just extract the patches and post them then :)
<bronson> what would be the easiest for you?
<kylem> git format-patch -k ${commit before you changed anything}
<kylem> i'm happy either way, it's ben you need to make happy :)
<bronson> good point.  :)  I'll ask again on Monday.
<BenC> bronson: Post patches using format-patch to kernel-team@l.u.c
<BenC> that's easy
<bronson> BenC: the linux-vserver patch is huge though...
<bronson> My changes are like a few hundred bytes of patch...  upstream though is, ah, invasive.  
<bronson> I think it'll be ~200K...  think that's OK?
<bronson> Why am I even asking...?  I'll post both the patch and the git tree and let the reader decide.
<bronson> Duh.  Time for me to get outside.
<bronson> WARNING: sound/oss/cs4232.o - Section mismatch: reference to .init.text: from .text between 'cs4232_pnp_probe' (at offset 0x7c) and 'unload_cs4232'
<bronson> I can ignore all these warnings, yes?
<kylem> yeah.
<bronson> thank goodness.  :)
<BenC> bronson: Are you posting it to be included in our tree?
<bronson> No way.
<bronson> Just hoping, perhaps, to include it with Feisty.
<bronson> But first I'm doing the easier task of getting it solid in Edgy.
<bronson> So, I'm very interested in your input.
<bronson> I mean, compile separate packages in a separate tree that would be included in Feisty's Universe or Multiverse.
#ubuntu-kernel 2006-12-10
<BenC> bronson: Ok, sounds good
<BenC> bronson: You may want to look at how the xen package in edgy is done
<bronson> Good call, will do.
<zul> hey
<AnAnt> BenC: ping
<crimsun> AnAnt: it's 6:37a in his timezone, surely you don't expect him to be awake?
<AnAnt> crimsun: err, I wake up before 6:37 sometimes
<AnAnt> crimsun: I mean it depends on each one's habit
<crimsun> 6:37a on a Sunday is a bit of a stretch.
<crimsun> -maybe- in 8 hours.
<AnAnt> oh
<AnAnt> it is sunday
<AnAnt> ok
<arvind_> I grabbed: linux-source-2.6.19-2.6.19 but my build (invoking fails with make-kpkg --initrd --append-to-version=-0.2 kernel_image kernel_headers
<arvind_> dh_installdirs: Compatibility levels before 4 are deprecated.
<arvind_> grep: ../../../config/archmap: No such file or directory
<arvind_> Use of uninitialized value in string eq at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 655.
<arvind_> dh_installdocs: Compatibility levels before 4 are deprecated.
<arvind_> Use of uninitialized value in string eq at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 655.
<arvind_> dh_installchangelogs: Compatibility levels before 4 are deprecated.
<arvind_> dh_compress: Compatibility levels before 4 are deprecated.
<arvind_> dh_fixperms: Compatibility levels before 4 are deprecated.
<arvind_> dh_shlibdeps: Compatibility levels before 4 are deprecated.
<arvind_> Use of uninitialized value in string eq at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 655.
<arvind_> dh_installdeb: Compatibility levels before 4 are deprecated.
<arvind_> Use of uninitialized value in string eq at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 655.
<arvind_> Use of uninitialized value in string eq at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 655.
<arvind_> dh_gencontrol: Compatibility levels before 4 are deprecated.
<arvind_> Use of uninitialized value in string eq at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 655.
<arvind_> dpkg-gencontrol: error: package linux-headers-2.6.19-rc6-ubuntu1-0.2 not in control info
<arvind_> dh_gencontrol: command returned error code 65280
<pmjdebruijn> arvind_, please use a pastebin next time.
<arvind_> ok==
<arvind_> how2 does one fix that pmjdebruijn 
<pmjdebruijn> no clue, sorry
<arvind_> what the correct way to build linux-source-2.6.19-2.6.19=
<arvind_> pmjdebruijn?
<pmjdebruijn> arvind_, you can find that one the wiki I think
<pmjdebruijn> arvind_, anyway, I'm not an expert
<arvind_> i followed wiki custom kernel building
<AnAnt> BenC: ping
<okaratas> [BenC PING reply] : 0secs
<okaratas> -
<okaratas> [BenC PING reply] : 1sec
<AnAnt> errr, I mean is he awake or not
<BenC> AnAnt: yo
<AnAnt> BenC: hello, remember the SD problem that I told you about ?
<BenC> yeah
<AnAnt> BenC: I just installed feisty yesterday
<AnAnt> BenC: I tried the SD with it, it works, but dmesg gives out some errors
<AnAnt> BenC: shall I send you those errors in email ?
<BenC> sure
<AnAnt> BenC: btw, I had to modprobe tifm_sd
<AnAnt> ok
<mjg59> BenC: I was chatting to Kyle about wireless support
<mjg59> BenC: I think we probably want to be regularly pulling from wireless-2.6
<mjg59> BenC: But probably getting bcm43xx and p54 from dscape instead
<mjg59> (possibly one or two other drivers as well)
<mjg59> By dscape, I mean drivers/net/wireless/d80211/ from wireless-dev
<mjg59> Which also means pulling in net/d80211 from there
<BenC> mjg59: I'd have to look into that...last time I started doing that, the ieee80211 changes started breaking some of our third-party drivers, and I ended up having several (more) versions of the 80211 stack in the tree
<mjg59> That gives us the option of pulling madwifi as well
<mjg59> BenC: The wireless-2.6 changes, or the wireless-dev ones?
<mjg59> The -2.6 ones are likely to land during the 2.6.20 timeframe, so we'd probably be screwed anyway
<BenC> mjg59: I think in dapper, the wireless changes we pulled in for bcm43xx and some other stuff was breaking even in-tree wireless drivers
<mjg59> Right, that was because there was a fairly large delta between upstream and us
<mjg59> That's not true at the moment
<BenC> mjg59: If it comes in during 2.6.20, then the third-party drivers usually get fixed up before release by their upstream
<mjg59> I'll take a look into it, anyway
<BenC> or we can fix them easily (I had to do a lot of ESSID-1 fixes for 2.6.19 at first)
<BenC> mjg59: I'm not against it...I'd have to check the trees to see what were getting into
<mjg59> -2.6 just gets us fixes that are based off the current stack
<mjg59> -dev gets us much more crack, but it's also where all the bcm43xx development is happening
<BenC> hopefully -2.6 will get into 2.6.20...if not, we can probably pull it anyway
<BenC> -dev would probably be best as added to ubuntu/ for whatever drivers we want to take in
<mjg59> Yeah
<BenC> and dscape
<mjg59> I wasn't planning on pulling that directly
<BenC> dscape was broken last I checked...wouldn't even compile against 2.6.20
<mjg59> My main machine's drive died last night, so I'm going to have to get another dev machine together
<BenC> I still need to see how much shit is going to break in LRM against 2.6.20 :/
<mjg59> Heh
<mjg59> That's one reason for being interested in dadwifi
<kylem> dadwifi?
<BenC> does dadwifi have a free hal?
<siretart> is it usable yet?
<mjg59> wireless-dev still seems to be 2.6.19-rc6
<mjg59> kylem: madwifi but on dscape rather than net80211
<mjg59> BenC: Yes
<mjg59> siretart: No clue. Easy to find out.
<BenC> hmm...I should test it on my friends laptop, he has a madwifi chipset that even madwifi CVS doesn't work with
<BenC> had to use ndiswrapper
<mjg59> It might not work
<mjg59> But you stand a better chance of bodging it into doing so
<kylem> BenC, https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.19/+bug/75107
<kylem> *blink*
<BenC> kylem: Yeah, that's a nice one :)
<mjg59> NR_CPUS is 1?
<kylem> it's not though.
<kylem> it's 8... in /ALL/ the configs since ubuntu-2.6.git was created.
<BenC> of course it isn't enabled
<BenC> he is running the -386 kernel, not -generic
<kylem> oh.
<kylem> HAH.
<BenC> grub seems to prefer -386 over -generic when both of the same version are installed
<JanC> grub orders kernels alphabetically AFAIK?
<JanC> or more precise: in ASCII order  :)
<BenC> I think there's a little more to it
<_MMA_> Hi BenC. I just wanted to let you know Im still getting that spec together.
<_MMA_> I met with crimsun yesterday and he gave me some things to think about.
<lehaid> hi, i'm using baseline ubuntu kernel, compiling, doing make modules_install, and it doesn't updat ethem, why ?
<lehaid> it updates to a diff /lib/modules, why is that ?
<mjg59> Because you haven't passed EXTRAVERSION
<lehaid> passed it where?
<lehaid> i used the .config from /boot
<mjg59> make EXTRAVERSION=-10-386 or whatever
<lehaid> where is that defined ?
<mjg59> It's generated by the buildsystem under debian/rules
<lehaid> if i manually compile the kernel?
<lehaid> can i cp the /lib/modules to the correct one
<mjg59> No
<lehaid> or will it bork up ?
<lehaid> so can you tell me what needs to be done ?
<lehaid> in manual compiling
<mjg59> I did
<mjg59> make EXTRAVERSION=-10-386 or whatever
<lehaid> ahh, and what should be in 6.06 something like
<mjg59> No
<lehaid> make EXTRAVERSION=-27-386 ?
<mjg59> Whatever comes after the base kernel version
<mjg59> Oh, right
<mjg59> Yes
<lehaid> k
<lehaid> blah
<mjg59> Then the same for modules_install
<lehaid> so now it will RECOMPILE ALL THE KERNEL ?
<mjg59> Yes
<lehaid> ARGGGGGGGG
<lehaid> just finished 1 hour compile of it
<lehaid> where is this documented?
<lehaid> https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28CategoryKernel%29 <-- is that for 6.10 only ? since i dont have "debian/config/ARCH" anywhere on the HD
<lehaid> mjg59 ?
<bronson> Anyone know where the Xen Edgy git tree is?
<bronson> Been googling for a bit...  can't find it.
<bronson> Maybe this hand-assembled URL...?   git clone git://dev.laptop.org/projects/ubuntu-xen-2.6.17
#ubuntu-kernel 2007-12-03
<kraut> moin
<imbrandon> ok i have kinda a strange issue i'm not sure how to debug enough to even file a meaningfull bug or fix myself, but if someone helps me figure it out i'll be more than happy to do so ...
<imbrandon> i installed hardy alpha-1 on a ppc iMac rev1
<imbrandon> install went fine ( alternate installer )
<imbrandon> nothing special, all defualt options
<imbrandon> anyhow on reboot i get droped to a initramfs busybox shell
<imbrandon> and i need to "modprobe ide-disk;^C-d" to successfully boot
<imbrandon> i tried dpkg-reconfigure linux-image-`uname -r` and updateinitramfs -u after adding ide-disk to /etc/modules
<imbrandon> neither worked
 * imbrandon goes back to idleing unless someone poke him with ideas
 * abogani would like update KernelTeam/Contacts wiki page. Who is contact for 2.6.24 component?
<maks_> imbrandon: /etc/initramfs-tools/modules as workaround
<maks_> but your trouble sounds like something that got solved long time ago
<maks_> don't know why it reappears in ubuntu
<imbrandon> yea this is a brand new hardy fresh install, no dual booting etc
<imbrandon> should be streight forward
<imbrandon> if there is any system specific info i can give lemme know
<imbrandon> and i'll try that work arround
<imbrandon> maks_: ^^
<gaspa> imbrandon: did you just try to select another kernel on grub menu?
<imbrandon> gaspa: it never gets that far, fresh alpha-1 install anyhow, no other kernels
<imbrandon> gaspa: sides ppc uses yaboot, but i know what ya mean :)
<gaspa> ok, i want to know only if you are sure of booting without the 'single' kernel option
<imbrandon> yes, positive
<imbrandon> image=/boot/vmlinux label=Linux read-only initrd=/boot/initrd.img append="quiet splash"
<imbrandon> gaspa: ^^
<imbrandon> thats the default ( that gets booted into ) yaboot.conf entry
<imbrandon> fyi
<gaspa> imbrandon: i know it's not a solution, but you could use the break=... option to take a look in initrd booting phases... for trying to understand what's the problem.
<imbrandon> gaspa: ok i'll try that
<maks_> imbrandon: changelog helps, yes it was 2.6.15, where udev did not load ide-disk
<maks_> so file a bug report against udev
<maks_> don't know why it regressed in that aspect, also i thought ubuntu was using pata everywhere
<maks_> (i'm debian only :)
<imbrandon> maks_: fwiw i just got this system and havent tried any other OS / Version on it other than the pre-loaded OSX 10.2 I got when i purchased it
<imbrandon> but i might try older versions and debian etch/sid also just to see where else it happens
<imbrandon> i think i have an sid ppc netinstall disk here somewhere :)
<imbrandon> err etch
<gaspa> imbrandon,tell us the results. :)
<imbrandon> definately
<gaspa> maks_: hardy doens't seem to have changes for udev.
<mark> hi, are people seeing regressions in gutsy's (server) kernel compared to feisty's?
<mark> I'm seeing it being 2-3x slower for certain things, and various other weirdness
<mark> I wonder if it has to do with the SLAB allocator changes
<mark> servers suddenly under socket memory pressure, LVS forwarding being slower
<zul> I HATE SNOW!!
<ivoks> i love it
<zul> ivoks: we are suppose to get 45cm of snow today. 
<ivoks> luck you
<ivoks> we have just this ugly rain
<thegodfather> hey ivoks 
<thegodfather> ivoks: looks like we did it also on dapper :)
<ivoks> he fabio
<thegodfather> ivoks: kees has everything in his inbox.. should be in the next kernel update
<ivoks> the fix? yeah, i've seen it
<ivoks> thegodfather: i hope that will happen very soon :)
<thegodfather> ivoks: yeps
<thegodfather> ivoks: should be.. 
<thegodfather> i have no control over it
<thegodfather> sorry
<ivoks> i know :)
<ivoks> hopefully, none of my servers will die before kernel upgrade :)
<thegodfather> :)
<soren> Do we have lvs in our kernels?
<mark> yes
<ivoks> yes, we have cluster stuff very well covered
<ivoks> i would say drbd is only missing piece :)
<mark> drbd would be nice
<ivoks> mark: plan is to have it in main in 8.04, at least as a additional module source
<mark> nice
<soren> It's already there? drbd8-source
<ivoks> is't not in main
<soren> If it were in main it wouldn't be as a separate source packages.
<soren> s/packages/package/
<mark> anyway, 2.6.22-server in gutsy doesn't look too great here
<mark> but I need to do more testing
<_stranger_> hi everyone! Is there any way i can get help here regarding kernel compillation?
<_stranger_> anyone here?
<rtg> _stranger_: https://wiki.ubuntu.com/KernelMaintenance
<tsmithe> BenC, poke re the alsa-firmware issue (i think I pm'd you earlier)
<BenC> tsmithe: yes, what about it?
<tsmithe> i was wondering how to get the firmwares included into l-r-m
<tsmithe> i'm not familiar with the build system, so would need a little coaching. i sent a message to the kernel-team list about this a couple of weeks ago
<BenC> tsmithe: just duplicate what was done for the dvb firmware
<tsmithe> ok, i will check that out. thank you :)
<el_cubano> Hello.  Could someone explain this error: "Checking ABI for 386...previous or current ABI file missing" ?
<el_cubano> It does not come up anyhere in Google.
<el_cubano> I am trying to build packages from linux-source-2.6.22 on Dapper using dpkg-buildpackage.
#ubuntu-kernel 2007-12-04
<Kano> hi pkl_ 
<Kano> pkl_: how about adding aufs to lum?
<Kano> many live cds have already switched from unionfs to aufs
<Kano> pkl_: btw. ndiswrapper is still 1.45.. not a tiny bit outdated?
<Kano> pkl_: btw. unionfs does NOT work
<mdomsch> rtg ping
<Kano> mdomsch: ?
<kraut> moin
<cathyal> moin
<TheMuso> c
<TheMuso> argh
<Keybuk> BenC: that reminds me, my kernel config changes didn't get made for the current 2.6.24 images?
<Keybuk> rtg: ^
<rtg> Keybuk: which changes?
<rtg> Keybuk: I think I did them once, but they might have gotten lost.
<Keybuk> #
<Keybuk> CONFIG_USB_DEVICE_CLASS=n: This drops /sys/class/usb_device/ which is subject to race conditions when using libusb. With 'n' they get replaced by additional attributes to the actual USB device.
<Keybuk> #
<Keybuk> CONFIG_SYSFS_DEPRECATED=n: Get rid of the /class hierarchy so that all data will be under /devices where it should be.
<Keybuk> #
<Keybuk> CONFIG_TMPFS_POSIX_ACL=y: Required for hal's ConsoleKit integration to set ACLs on device nodes.
<Keybuk> #
<rtg> Keybuk: ok
<bdmurray> BenC: The new Malone package for the kernel is just 'linux' - is that right?
<BenC> bdmurray: yeah
<bdmurray> BenC: why not linux-source-2.6.24 ?
<BenC> bdmurray: to consolidate bugs better
<bdmurray> BenC: I'm not sure I understand.  How will we know which kernel is affected by a bug?
<BenC> bdmurray: affects -> hardy, affects -> hardy+1, etc.
<bdmurray> BenC: okay, so going forward this will make more sense
<BenC> bdmurray: yeah, it's a move we should have made a long time ago, but we never weighed the pros/cons until this UDS
<bdmurray> BenC: I think the word 'linux' is open to a lot of confusion though.  You might get a lot of erroneous bug reports in their.
<BenC> bdmurray: we might catch some we've been missing too :)
<bdmurray> BenC: My money is on more wrong
<bdmurray> I think linux-kernel would be more descriptive and less error prone
<BenC> bdmurray: probably, but we followed upstream naming...and it is more correct
<maks_> right linux-2.6 is the upstream name, but no 2.7 in sight
<rtg> Keybuk: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=451938883144978c531ee97cd35587d04d5229ac
<Keybuk> thanks
#ubuntu-kernel 2007-12-05
<Le-Chuck_ITA> Hi all, I want to draw your attention to the following bug, which has been "quickfixed" by a clever guy who found out a line to comment out, but requires kernel developers attention to be sure it's a good fix. It's a regression from feisty, and since in gutsy for the first time suspend to disk and to ram work flawlessly on toshiba laptops with dual core enabled, I supppose it is worth a look. Bug is:
<Le-Chuck_ITA> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/152187/
<ubotu> Launchpad bug 152187 in linux-source-2.6.22 "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Undecided,Confirmed] 
<Le-Chuck_ITA> I hope somebody sees this, and thanks a lot.
<tjaalton> I've got frequent crashes with dapper on a HP DL380G5, and I've got a call trace that starts from bnx2_poll
<tjaalton> that would suggest that there's a bug in the broadcom driver?
<tjaalton> (I took a photo of the trace)
<tjaalton> I found this while searching for similar issues http://bugs.centos.org/view.php?id=2103
<tjaalton> please see bug 75767, I've confirmed that one. seems similar enough to mine
<ubotu> Launchpad bug 75767 in linux-source-2.6.15 "kernel panic: killing interrupt handler" [High,Confirmed] https://launchpad.net/bugs/75767
<andres> If I have made a kernel bugreport including a patch which is accepted upstream which fixes crashes and datacorruption, is there anything more I can do? (2.6.22 xen)
<andres> (#164904 btw)
<Kano> could some add a little patch for aufs?
<Kano> patch/sec_perm-2.6.24.patch from aufs cvs
<Kano> +EXPORT_SYMBOL(security_inode_permission);
<Kano> mainly
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-future-pure/source/sec_perm-2.6.24.patch
<Kano> also i need one file more in the headers: 
<Kano> fs/aufs/Makefile:tmpfs = $(shell grep '\#.*define.*TMPFS_MAGIC' ${srctree}/mm/shmem.c | \
<Kano> so i need mm/shmem.c
<abogani> Kano: Please use the right way: Clone hardy git repo, apply the patch, test resultant kernel, formatting patch as reported at https://wiki.ubuntu.com/KernelGitGuide  and send a patch to kernel-team ml. 
<Kano> thats the original patch from aufs cvs
<Kano> i would suggest to switch to aufs - unionfs is not working from lum
<Kano> maybe the same issue,dont know
<Kano> [ 4814.465576] aufs: Unknown symbol security_inode_permission
<Kano> [ 5954.937595] unionfs: Unknown symbol security_file_ioctl
<Kano> [ 5954.937662] unionfs: Unknown symbol security_inode_permission
<Kano> it seems it is the same issue, just that unionfs needs even a 2nd export
<abogani> andres: Depend from intrusive level of the patch and from type of bug which it resolve. Generally if the bug not meet https://wiki.ubuntu.com/StableReleaseUpdates requirements is very difficult that the patch will be accepted.
<Kano> so you need to add even 2 export statements...
<Kano> i do not need to send anything, if you want a working unionfs...
<andres> abogani: As I said, it causes, sometimes silent, data corruption. Has very little impact, is accepted upstream, only affects xen kernels.
<andres> Its the xfs not using vunmap() issue.
<andres> And is very hard to diagnose as the backtraces are quite random, as it can happen at every place where vmap's are used.
<andres> abogani: so I dont see why it shouldnt adhere to the stable release guidelines.
<andres> abogani: May I nominate it for some release, or should that only be done by ubuntu devs?
<abogani> andres: You should send email to kernel-team ml.
<andres> Ok.
<Kano> what file to patch for the headers?
<Kano> i dont get it currently where to write the extra files
<andres_f> abogani: done
<andres_f> Ugh. The mailing list is moderated.
<andres_f> Do you moderate the lists regulary, or should I subscribe and repost?
<Kano> !24
<ubotu> Sorry, I don't know anything about 24 - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<Kano> updated
<andres> Is it planned to activate paravirt_ops in 2.6.24-generic by default?
<andres> I think some distros are planning that and it is quite convienient.
<andres> (and afaik the overhead is marginal)
<sommer> hey, all I'm documenting the differences between the server and desktop editions and I just wanted to confirm this article is accurate?
<sommer> http://www.enterprisenetworkingplanet.com/netos/article.php/3710641
<sommer> basically just comaring /boot/config-version between a server and desktop install
<sommer> comparing rather
<ivoks> right, those are the differences
<sommer> ivoks: cool I figured, but thought I'd double check
#ubuntu-kernel 2007-12-06
<johanbr> According to the topic, the latest kernel upload seems to have been in progress for about a month now. :)
<pwnguin> seems true
<pwnguin> at the moment, the package "linux" holds the 2.6.24 kernel
<pwnguin> but im missing a few restricted drivers and iwl
<johanbr> It does? My mirror doesn't have a 2.6.24 kernel at least.
<pwnguin> in hardy?
<pwnguin> apt-cache show linux
<pwnguin> oh
<johanbr> Right. No 2.6.24 kernel.
<pwnguin> good point
<pwnguin> apt-cache show 2.6.24 does show up though
<johanbr> Oh, never mind. I'm stupid. Found it.
<pwnguin> but i dont think its finished uploading / building / something
<johanbr> No, it's done: https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-1.1
<pwnguin> hmm. well i guess once im done updating, i'll go back and see why wireless isnt working
<imbrandon> BenC: ping, how much trubble ( or what do you need from me to make is easier/faster ) to get "omfs-source" from the archives into l-u-m
<kraut> moin
<Kano> hi pkl_ 
<Kano> could someone tell me how to check for the kernelversion used in a rules.modules file?
<Kano> i have got KVER in there as var...
<Kano> ok, found a solution for that, but that only fixes things for 2.6.23 (avm drivers)
<gaspa> there's someone with slub/slab experience? i want to understand when to use the first, when the latter...
<andres> gaspa: Except for bugs in slab I dont think there are many valid reasons using slab.
<andres> Replace first slab with slub.
<gaspa> andres: there are no cases in which slab if more efficient?
<andres> Maybe there are some, but not out of architectural reasons.
<andres> And be aware that there were some bugs making slub way much slower in 24-rc? releases.
<pitti> BenC: so, maybe I'm confused
<pitti> But https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/57233/comments/12
<ubotu> Launchpad bug 57233 in linux-source-2.6.15 "Minor revision 2.6.15-26 doesn't detect attached SCSI disks to LSI 1030ST" [High,In progress] 
<pitti> seems to indicate that this bit was a regression:
<pitti> linux-source-2.6.15 (2.6.15-51.63) dapper-proposed; urgency=low
<pitti>  * megaraid: Move AMI/Megaraid3 IDs from megaraid_mbox.ko to megaraid.ko
<pitti>  * megaraid: Move AMI/Megaraid3 IDs from megaraid_mbox.ko to megaraid.ko
<pitti>     - LP: #57233
<pitti> (oops, sorry for the double line)
<pitti> BenC: ah, so you do plan to back out that change to get back to the current dapper-security behaviour, and fix the bug in lbm instead?
<BenC> pitti: right
<pitti> ok, then I just misunderstood you
<pitti> BenC: ok, so the backing out of this bit should be easy and do little harm, right?
<BenC> pitti: right, now we're on track :)
<pitti> let's hope that Vide tests the new lbm then
<pitti> BenC: but unless you have some other showstoppers, shall we get this uploaded and new CDs built for testing?
<BenC> pitti: I think that's a good idea, ppl can test in the meantime
<BenC> pitti: I'll get the uploads done once I've had a cup of coffee
<pitti> BenC: enjoy, and thanks
<BenC> pitti: lbm-2.6.15 is in dapper-proposed awaiting approval
<pitti> BenC: nudged, thanks
<BenC> pitti: I'm checking if this megaraid change breaks ABI, after that I'll upload
<pitti> BenC: *crossing fingers that it won't* :)
<BenC> pitti: good news, no change in ABI
<pitti> phew
<pitti> BenC: so, dapper.2 meeting in 5?
<BenC> pitti: yeah
<pitti> BenC: ah, I know why I didn't notice the mpt symbol error in my existing dapper install
<pitti> BenC: in d-i, it prefers the driver from lbm, but in an installed system it prefers the one from linux-image
<pitti> BenC: at least I get 3.03.04 loaded
<pitti> BenC: that's both in my permanent dapper vmware as well as the one I just test-installed
<pitti> BenC: modules.dep does not have any "/updates/" in it; after a depmod -a it has
<pitti> BenC: might the reason be that the one in /updates had the faulty symbols?
<BenC> pitti: make sure depmod -a is run, and update-initramfs -u afterwards
<pitti> BenC: right, after depmod -a I get the new version
<pitti> BenC: my concern is, if in a fresh install the old version is used, then that sounds like a bug?
<pitti> (i. e. the default modules.dep is wrong)
<BenC> pitti: lbm should be running depmod, and update-initramfs, at least it did on my system
 * pitti upgrades to the new lbm in -proposed and tests further
<maks_> BenC: initramfs-tools in unstable has pretty stabilized
<maks_> so if you wana go for long term support a merge would be cool
<maks_> can lend my eyes to the resulting diff
<maks_> :)
<pitti> BenC: ah, after upgrading to new lbm I get 3.03.09 by default on boot, so that looks good
<pitti> BenC: I'll test it again tomorrow when it's on the CD (the modules.dep issue)
<pitti> BenC: hmm: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/56885/comments/6 :(
<ubotu> Launchpad bug 56885 in linux-source-2.6.15 "e1000 driver not working properly on x86_64?" [Medium,Fix committed] 
#ubuntu-kernel 2007-12-07
<Nafallo> hmm.
<Nafallo> which git tree should I use to have an up-to-date with dapper-security + cobalt raq 4 patch git? :-)
<Nafallo> or feisty maybe...
<kraut> moin
<TheMuso> /c
<TheMuso> ugh
<Kano> hi, how about adding drivers/md/dm.h to headers package?
<Kano> it is only include/config/blk/dev/dm.h there,but that is a different one
<Kano> that file is needed for truecrypt
<kaur_> Hi
<kaur_> Is this the right place to speak about an issue with ubuntu kernel?
<kaur_> Anyway...
<kaur_> Gutsy's kernel causes my hdd to make constant quiet beep sound... That can't be good. I'd use feisty's kernel instead, but it has some other problems
<LimCore> Hello devels
<LimCore> loopaes do not work on recent amd64 kernel (2.6.22-14)
<LimCore> whoops never mind... just not pooled in cryptoloop while modprobing aes... shouldnt cryptoloop be automatcailly used?
<tormod> hi now with the "linux" package for 2.6.24 (and up, I guess) should old 2.6.22 (and down) bugs in that package be reassigned to their "linux-source-2.6.xx" package?
<IntuitiveNipple> the package is now "linux" - just to confuse you :)
<IntuitiveNipple> ahh, sorry, for Gutsy? then linux-source-2.6.22 yes :)
<fs> where can I find the patch for linux-2.6.22 to build gfs1 in LUM?
<fs> never mind, found it in your git-web
<tormod> maybe I was not clear: there are many old bugs filed on "linux" (by mistake I guess). Should they be reassigned?
<IntuitiveNipple> I think the rationale is, if they're still open they probably still affect the current kernel
<tormod> right
#ubuntu-kernel 2007-12-08
<Kano> hi, just tested p54pci on 64bit (2.6.24 kernel), there it is really unstable, 32bit is ok
<Kano> also i need a blacklist option to do things like: blacklist=prism54 in live mode...
<Kano> because the other module would be loaded instead then
<sivang> howdy all
<sivang> does anybody know how to make xconfig on gutsy? it wants qt3 dev libs but only 4 is available to install
<sivang> oops, sorry wrong channel, I want debian-kernel :)
<chan23j> exit
<bullgard4> What is the reason that s2ram is not provided in a Gutsy DEB program package?
<Nafallo> bullgard4: I bet it is because no one has packaged it? :-)
<bullgard4> I do not bet.
<mjg59`> bullgard4: Because it's inappropriate for Ubuntu
<mjg59`> There's no reason to provide multiple ways to do the same thing
<mjg59`> We use the acpi-support scripts in gutsy and pm-utils in hardy
<bullgard4> mjg59`: Thank you for informing. I will try to take that into account.
<johanbr> Are the Gutsy patches mentioned at https://wiki.ubuntu.com/KernelTeam/FAQ scheduled to go into Hardy as well?
<Chorus> Ã
<Nafallo> johanbr: wouldn't dropping patches be a regression? :-)
<johanbr> I would think so, yes. Depends on what the patches are I guess...
<Nafallo> exactly :-)
#ubuntu-kernel 2007-12-09
<clever> ive got a problem with the rtl818x kernel driver
<clever> it started a few releases ago but still exists in 7.10
<clever> it spews errors to dmesg when droping the wifi link
<clever> rtl8180: WW:Phy writing 3 26 failed!
<clever> has happened 33 times and a few other similar ones have happened(different numbers)
<clever> ive found what line of source is actualy causing that dmesg output but havent figured out why its running
<clever> it looks like its trying to do the same thing 70 times and returns when  it works
<clever> and that error im getting is after the 70 passes fails
<maxlo> hello
<maxlo> I am trying to contact the kernel hackers of Ubuntu
<maxlo> is this the right place?
<JanC> maxlo: it could be, but I'm not sure anyone is around at this time & day
<maxlo> I see... what would be the appropirate date? monday-friday?
<JanC> I think most of the main (paid) kernel developers are in the US, so probably mon-fri US working hours 
<JanC> but you could also hang around until you see someone moving   ;)
<JanC> there is also a kernel mailing list, but it's moderated AFAIK
<maxlo> I see. thanks
<soren> Anyone can subscribe and post to it, afaik.
<maxlo> I was looking for some casual contact method, such as IRC :)
<maxlo> I will try US working hours
<yuhong> May I suggest adding a generic-pae kernel to the next version of Ubuntu?
<yuhong> Currently it requires a recompile.
<yuhong> How about making it the default if NX support or RAM mapped over 4G boundary is detected and if installing the desktop version of Ubuntu.
<crimsun> (seriously, use the mailing list, too.  Backscroll is lost easily, and not everyone reads the logs or lastlog.)
<yuhong> Also how about a non-PAE server kernel?
<yuhong> Make that the default if the processor does not support PAE and if installing a server version of Ubuntu.
<JanC> yuhong: I guess systems with more than 4 GiB RAM have support for 64-bit anyway?
<yuhong> Most of them.
<JanC> on the desktop at least
<yuhong> But NX support cannot be enabled without PAE.
<zdzichu_> is wasting time on PAE worthful? Even Microsoft removed support for 32bit+PAE from recent OS versions
<JanC> so, it doesn't work on 64-bit, or what?
<yuhong> No, they didn't
<zdzichu_> However, Microsoft has essentially abandoned PAE in the 32-bit versions of Windows XP SP2 and Windows Vista.[5] This is to avoid compatibility problems with the wide variety of third-party device drivers.
<zdzichu_> 5. http://support.microsoft.com/kb/929605/en-us
<yuhong> Here is the real story.
<yuhong> When NX is enabled, PAE is enabled with a hack that restricts the physical address space to the lower 4G.
<yuhong> When PAE is enabled, PAE is enabled without this hack.
#ubuntu-kernel 2008-12-01
<crimsun> TheMuso: in jaunty's new PM world, we should investigate handling legacy (non-PM-enabled) sound modules for suspend (& resume) by unloading+alsactl store (& loading+alsactl restore) as per Takashi's recent e-mail on alsa-devel.  (Yes, the drivers should be updated, really...)
<crimsun> there's some elbow grease involved, but I'm happy to look into it this cycle
<TheMuso> crimsun: Ok, I'm happy to help where necessary.,
<TheMuso> crimsun: I've also been attempting to play with a managable source package for alsa modules in a separate package. Haven't really come up with anything yet, short of using the script in alsa-driver to copy the files into alsa-kernel from a git tree.
<TheMuso> crimsun: In that case, I'll subscribe to any pm related specs.
<zoopster> If a kernel bug affecting ubuntu has been fixed upstream how can I get my hands on a compiled kernel with the patch to test?
<TheMuso> zoopster: It depends on what version of the kernel the bug was fixed in. If its part of 2.6.27, then likely enough it may be included in a future kernel update for intrepid.
<zoopster> TheMuso: thanks. the patches were put upstream for 2.6.27 and launchpad shows fix released from upstream...was unsure how that trickled down and how long that took. I didn't want to recompile a kernel with the patches if that was already done somewhere else
<tseliot> amitk: I forgot to send a message (which reports a problem with the headers of kernel 2.6.28) with my @ubuntu.com alias and therefore it's waiting for moderation
<amitk> tseliot: I don't have moderator access of the list. You might have to wait for BenC or rtg.
<tseliot> amitk: ah, ok, thanks
<snowblink> hi - can I ask why dapper's latest kernel package appears to be 2.6.15.54, but contains 2.6.15.53?
<smb_tp> snowblink, where did you find 2.6.15.54?
<snowblink> smb_tp, http://archive.ubuntu.com/ubuntu/dists/dapper-updates/main/binary-i386/Packages.gz
<smb_tp> snowblink, This is the version number of the linux-meta package. The upload counter is just incidentally one above the counter of the kernel image itself
<snowblink> smb_tp, ah ok. Thanks - it was a little confusing.
<smb_tp> Yes, normally this number is much smaller than that of the kernel itself, but for some odd reason it jumped to this area some time ago. Now both are quite close which is a bit confusing
<tseliot> rtg, amitk: is what I reported in the mailing list a known problem?
<rtg> tseliot: I'm just looking at it. I think its likely a packaging problem.
<tseliot> rtg: ok, that would be good news
<_ruben> from what i've seen the asm/ dir got butchered in .28 (or .27 already perhaps) .. seen its implications in various out of tree modules
<_ruben> which isnt an ubuntu specific thing, but upstream change
<tseliot> _ruben: if this is true then other files should not include headers from asm
<_ruben> well, its not completely gone, but lots of stuff has been (re)moved (to other places) .. i dont know any details, just an observation :)
<tseliot> ah, ok
<rtg> tseliot: I think I have to agree with _ruben. it looks like stuff has really moved around.
<tseliot> rtg: shall I file a bug report then?
<rtg> tseliot: its not really a bug per se, its more of a third party module problem. don't you think?
<rtg> I guess you could file a bug against nVidia
<tseliot> rtg: but the compilation test only includes this:
<tseliot> #include <linux/version.h> #include <linux/utsname.h>
<tseliot> and this fails
<tseliot> I don't think it's nvidia specific
<tseliot> rtg: example: /lib/modules/2.6.28-1-ub-generic/build/include/linux/sched.h:48:36: error: asm/param.h: No such file or directory
<rtg> tseliot: hmm, that does seem straightforward. I wonder if BenC knows 'cause I haven't followed the .28 development cycle very closely.
<tseliot> ok
<BenC> tseliot: are you sure you are using standard build procedures?
<BenC> tseliot: are there broken symlinks in there?
<tseliot> BenC: I'm using Nvidia's makefile as usual. Nvidia's conftest.sh tries to build the test file with cc -D__KERNEL__ -DKBUILD_BASENAME="#conftest12386" -DKBUILD_MODNAME="#conftest12386" -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.3.2/include -I/lib/modules/2.6.28-1-ub-generic/build/include/asm/mach-default  -I/lib/modules/2.6.28-1-ub-generic/build/include -o conftest12386 conftest12386.c
<BenC> tseliot: looks like an nvidia bug
<BenC> tseliot: it's missing -I/.../arch/x86/include
<BenC> tseliot: note, fglrx built fine with latest header packages...I didn't test nvidia
<tseliot> BenC: ok, let me try again
<rtg> BenC: apw and I were wondering why the build number isn't exposed in /proc/version ?
<rtg> if it were, then we could drop /proc/version_signature
<apw> i presume its not in the main version number to maintain the location of the modules through a complete abi cycle
<tseliot> BenC: I get this error: http://pastebin.com/m7302cc4b
<tseliot> BenC: nevermind, I had to add .../arch/x86/include/asm/mach-default too
<tseliot> I'll report the problem to NVIDIA
<tseliot> thanks for your time
<lamont> how do I get a cli kvm host to keep running when the window is iconified or on a diff workspace???
<rtg> soren: ^^^
<cjb> Hi, something between intrepid 2.6.27-2 (which works fine) and 2.6.27-7 gives me two-second lag on my ssh connections on an otherwise fast (500KB/sec) cable line.  Anyone know anything about that?
<cjb> HTTP seems unaffected.  It's quite odd.
<rtg> cjb: 'GSSAPIAuthentication no' ?
<cjb>  /etc/ssh/ssh_config says GSSAPIAuthentication yes
<rtg> cjb: try setting it in ~/.ssh/config
<cjb> So I guess not.  Does that have some recently-regressed kernel interaction, then?
<rtg> cjb: not to my knowledge
<cjb> oh, ok.
<rtg> apw: I noticed actual activity in Linus' repo this morning, so he must be back from scuba diving.
<apw> rtg wondered why he was so quiet, having a holiday, outrageous
<lamont> damn fiordland
<laga> lamont: he was in maui apparently
#ubuntu-kernel 2008-12-02
<lamont> soren: you around>?
<pitti> hi
<pitti> rtg, BenC: argh, after hal the serial.h header bug now struck cups
<pitti> would you guys consider bug 302888 as something which needs to be fixed, or something which is intended and needs to be changed in hal/cups/etc.?
<pitti> ah, I checked upstream, it's not a bug there
<pitti> seems to be an Ubuntu-introduced bug
<rtg> pitti: hi, its on my todo list. I'll check it first thing in the morning.
<pitti> rtg: great, thanks; so I 
<pitti> 'll just let the FTBFS sit there
<soren> lamont: What's up?
<tjaalton> are there plans to build multipath-modules for the installer?
<Kano> hi BenC , are you working on 2.6.28-rc7?
<NCommander> hey BenC, do we have any plans to move madwifi from LRM to the ubuntu folder now that its HAL is open?
<Kano> NCommander: i dont think the madwifi code changed
<NCommander> Kano, no, they released the HAL for it
<Kano> there the blob still exists
<NCommander> aka, the closed source blob
<amitk> it would probably make more sense to get rid of madwifi completely if ath5k and ath9k work for a majority of the users.
<NCommander> As long as madwifi is maintained, it should still be an option
<NCommander> People get kinda pissed when their hardware stops working all of a sudden
<NCommander> i.e. Windows Vista
<Kano> well kanotix users have got no complains against ath5k, i enabled it - as little diff to your config
<Kano> so eee pc and co works out of the box
<rtg> apw: I responded re LP 302888 and 303711.
<apw> rtg cool
<Kano> hi rtg , how about 2.6.28-rc7
<rtg> Kano: I take it from your question that it must be out :)
<apw> rtg, will sort it out now
<BenC> Kano: As usual we are working on it as quickly as possible, without concern for outside questining
<BenC> questioning
 * apw had something to ask benc ... what was it ... oh yeah, did you do the roll forward from Hardy to Intrepid?
<Kano> BenC: well i did not see any new commits ;)
<Kano> i want nfs working, did anybody else that that
<BenC> apw: Hmm....I think so, but that was awhile ago :)
<apw> benc, we lost an unbutu driver, specifically 
<apw> benc, we lost an ubuntu driver, specifically the snd-aloop one, and wondered if you remebered the history
<smb_tp> apw, are you sure we lost it or is that just a rename?
<rtg> apw: was it in the ALSA directory?
<rtg> sound, rather
<smb_tp> That clue with dummy seemed good
<BenC> apw: we had an ubuntu driver called snd-aloop?
<BenC> apw: if it was in alsa proper, best bet is to check alsa history
<apw> BenC, no it was in l-u-m
<BenC> apw: but the sound drivers in lum were just a tarball of upstream
<smb_tp> apw, It was in lum but under sound which is alsa
<BenC> apw: so we didn't really pay attention to individual drivers in it
<apw> hmmm ... ok then will go look at it from that point of view
<BenC> except maybe snd-hda-intel
<smb_tp> well that should be upstream as well. maybe even more upstream than the rest
<apw> rtg, that header file fix is pushed up to jaunty
<BenC> rtg: Can you get me a cup of coffee too :)
<smb_tp> oh you referred to paying attention
 * apw salivates ... and has to go make one
<BenC> My brain is only at about 70% right now...need that extra caffeine kick to get to 71%
<smb_tp> apw, snd-dummy really looks alike snd-aloop beside of having everything renamed from loopback to dummy...
<rtg> BenC: I've got time to rebase and test build Jaunty this morning. OK?
<apw> smb_tp, interesting ... i did see one commit which talked about dummy which sounded like it do something
<apw> will do compare them
<BenC> rtg: Have at it :)
<rtg> BenC: will do. coffee is almost ready. bought a new 5lb bag of Italian roast just yesterday.
<BenC> mmmm...italian
<smb_tp> rtg, Need COIP ;-)
<amitk> Anybody working on LRM/meta for Jaunty?
<BenC> amitk: I was going to do that since rtg had the rebase, but if you are already started, it's yours
<amitk> BenC: not started. I'll be busy this week with ARM.
<BenC> amitk: do you have the linux-meta armel portion?
<BenC> amitk: Ok, I'll get lrm forward ported then
<amitk> BenC: not yet. Since I was waiting for the fallout from the -ub- version_signature discussion
<BenC> rtg: When you do the rebase, can you remember to remove the via chrome9 drivers from ubuntu/?
<rtg> BenC: can do. amitk - you promised a discussion for why you added -ub to package names.
<BenC> rtg: basically to help identify ubuntu machines with upstream bug reporting and oops reporting
<apw> rtg, while we are on the subject of version, i got that patch to put the ubuntu upload+changelog into the /proc/version #N field
<amitk> rtg: yes. As soon as I am done with the spec here.
<BenC> apw: that would be nice
<apw> Linux version 2.6.27-10-generic (root@dm) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #21~lp276943apw1 SMP Mon Dec 1 17:56:07 GMT 2008
<apw> note the 
<apw> note the #21~... in there where we always have #1
<apw> also note that in theory this would also be in the oops output
<BenC> what is the ~lp... ?
<apw> that is a local change tree i have installed, and i added that to the changelog
<amitk> BenC: with apw's patch to /proc/version and in the oops patch, we should be able to revert the -ub change
<BenC> apw: can you paste "head -1 " of changelog so I can see what it is parsing into it?
<apw> ie. what i put in there is everything after the abi number
<BenC> ok
<rtg> BenC: adding -ub to the package name does't have anything to do with kerneloops, does it? I thought it was all in /proc/signature
<apw> linux (2.6.27-10.21~lp276943apw1) UNRELEASED; urgency=low
<apw> so normally we would expect it to be #21 or maybe #21ubuntu1 
<BenC> rtg: well changing the package name made things easier in the build scripts, since it is assumed that the package name matches the kernel version name
<apw> this is a local build for testing so i bung that into the changelog too
<apw> yeah you don't have much choice but to change the name if you add it to the real version
<apw> the other options were to just change the ooops output, to add a marker
<apw> though logically it would be better for mainline to add a CONFIG_DISTRO
<apw> and default that to mainline
<BenC> amitk: so how does kerneloops tell that it is an ubuntu proper kernel and not just a kernel built on an ubuntu machine?
<apw> so all oopses had mainline <version>, or Ubuntu <version>
<BenC> apw: that was kind of the idea behind version_signature, but I wasn't prepared to push it hard enough to send it to linux-kernel@
<apw> well it would be sensible enough, we just need it in the oops output
<rtg> BenC: why am I ripping out via_chrome9  (which appears to be enabled) ? Is there an LP report?
<amitk> BenC: it scans dmesg for oopses
<amitk> BenC: here is a sample first line from Fedora
<amitk> Linux version 2.6.24-0.77.rc4.git4.fc9 (kojibuilder@) (gcc version 4.1.2 2007112
<amitk> 4 (Red Hat 4.1.2-35)) #1 SMP Thu Dec 6 16:50:13 EST 2007
<BenC> rtg: because it is in mainline now
<rtg> uh, I guess that makes sense :)
<BenC> amitk: right, but how is our kernel going to look different than a kernel a user built, or do they not care about that?
<amitk> BenC: they don't care unless it is tainted
<BenC> amitk: that sucks, because I care :)
<amitk> BenC: you want to differentiate official kernels from user-compiled ones?
<BenC> amitk: then why couldn't they just check for Ubuntu in the kernel oops already...that's always been there
<BenC> amitk: it's always been in oops and /proc/version
<amitk> BenC: our /proc/version in intrepid is
<amitk> Linux version 2.6.27-10-generic (buildd@crested) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Fri Nov 21 19:19:18 UTC 2008
<amitk> The first part has no mention of ubuntu
<amitk> The only Ubuntu in there is related to the gcc toolchain use
<amitk> *used
<apw> and oopsen only use that first version field
 * amitk nods
<apw> well thats not quite true, they also include the #1 field
<apw> one of my alternative patches put -Ubuntu in there,  #1-Ubuntu
<apw> we could combine that with my other patch to make it like #12-Ubuntu
<BenC> apw: for our official kernels, that would be sweet
<BenC> apw: where can I find the patch?
<apw> we can probabally even key that off the whether we are under an autobuilder
<apw> BenC, want me to send it out?
<BenC> apw: that's easy to do, see debian/rules.d/0-*, there's a check for CurrentlyBuilding or something similar
<BenC> apw: that means we are under a build daemon
<BenC> apw: yes, please
<apw> i'll poke it so it adds the -Ubuntu on autobuilder and send it to the kernel team list
<rtg> BenC: have you ever considered removing debian/control, debian/control.stub, and debian/d-i/kernel-versions from git ? All of these files are generated and often cause rebase conflicts.
<apw> i often wonder why we have the abi files in there either
<apw> other than the getabi thing being very slow cause it gets the whole kernel package
<rtg> apw: well, the ABI for the previous version really needs to be there.
<BenC> rtg: odd, I've never had a rebase conflict with them
<apw> we need to know it for the build right, but not necessary in the source tree itself?
<BenC> apw: it needs to be there so we can easily go back through history
<apw> are they not in the pacakges we released too tho?
<BenC> apw: they are pertinent to the state of the tree
<rtg> BenC: I'm having a rebase conflict with the -ub additions in debian/d-i/kernel-versions.in, and I'm not quite sure why.
<BenC> apw: they packages we released will disappear sooner then the end of the development cycle :)
<apw> fair point
<BenC> rtg: easy enough to just ignore those...I've never had issue with that before
<BenC> regen at the end of the rebase
<rtg> BenC: well, I can't exactly ignore kernel-versions.in, that one I have to resolve. the rest are no problem.
<amitk> rtg: just delete those files before you start the rebase and regen them at the end
<BenC> rtg: I suspect that it more to do with armel and -ub- clashes rather than just normal stuff
<amitk> rtg: .in versions for the generated versions?
<apw> BenC, actually the given the abi cannot change within an -N abi stream and given the each abi is a differnt package, then all the abis should be available always
<rtg> BenC: isn't that what I said?
<amitk> s/for/or
<BenC> apw: as I said though, the abi files are very pertinent to the state of the tree, so they should be there
<BenC> apw: we shouldn't have to download the abi files to go back through history...easier to just use git
<apw> fair enough, just usual to have generated stuff in there
<BenC> rtg: oh, I thought you just said -ub-....I was just remembering a bit of merging I had to do with amitk's -armel stuff and -ub- changes
<BenC> apw: abi files aren't generated in the tree though...we have to fetch them
<BenC> you can probably make the case for control,control.stub,kernel-versions though
<BenC> as long as they get added to .git-ignore, I wont complain :)
<apw> BenC, i cannot argue with that
<BenC> It might be best to keep them though...we've always assumed that git tags hold the exact source we uploaded
<amitk> BenC: until we rebase, that is.. Then the tags are meaningless
<apw> well no the old tags are still there, they don't move
<amitk> BenC has a retag script :)
<apw> he is a bad bad man
<BenC> I keep the original tags though
<BenC> like Ubuntu-2.6.28-1.1.orig
<apw> why would we move them ever?  don't they correspond to something specific?
<BenC> and they never get overwritten after they are created
<BenC> apw: we move them so they correspond to git history
<BenC> apw: it's good to have the original and the retag
<apw> why do we need the new ones?  the old ones tell you how to get the source as it was for that release
<BenC> apw: because if they don't correspond to the new line of history, we can't git-bisect
<apw> what do the new ones on the rebase tell us
 * apw mulls that over
<BenC> if you rebase, you can't bisect from HEAD back to 2.6.28-1.1
<BenC> unless you use the updated tag that corresponds to the new line of history
<BenC> and the old tags make it so we can keep a link back to the actual upload
<rtg> BenC: debian/scripts/misc/retag before you startnewrelease, right?
<apw> although the fact it worked in 2.6.28-1.1 means nothing in the new kernel
<BenC> rtg: you can run it at any time
<apw> as the new kernel has new stuff 'older than' 2.6.28-1.1
<apw> so its not obvious a known good point on an older branch means anything int eh new tree
<BenC> apw: it's very subtle, but I did write the script because our process demanded it at a few points during development :)
<amitk> these tags are useful for bisecting only inside Ubuntu's patches
 * BenC doesn't add scripts for no particular purpose
<apw> heh, not doubting there is a use case for them
<apw> just my 'perfection' beeper is going off at the thought of ever changing the tags
<BenC> apw: the reason we rebase here instead of merge is because when we bisect, we want to be sure we are bisecting ubuntu patches and not upstream
<BenC> apw: when we bisect upstream, we don't want to be bisecting ubuntu patches in the middle of it
<BenC> apw: if you want, rtg and I can rehash our old arguments for and against this at UDS :)
<apw> yeah am happy we rebase, that helps keep our delta contained and minimised, even if it is painful
<apw> i had not expected the tags to move, and i can see why they might, not sure they are entirly valid given a good result on a kernel with an older version of the tag, but i can see how it does help to have the split on the current set too
 * apw adds 'if there is a .orig for a tag, its the master' to his mental model
<BenC> apw: after the kernel goes stable, we don't rebase anymore, so the moving target is usually only during development cycle
<apw> BenC, i can see i would have done something similar (now i have all the facts) though i would probabally have kept the original tags unchanges and made like a Ubuntu-2.6.27-10-2, -3 etc for each of their new positions, but the effect is the same
<apw> BenC, patch for the #NN -> #21-Ubuntu is in the pipe
<rtg> apw: you didn't push it, right? 'cause I'm gonna clobber stuff when I push Jaunty.
<apw> rtg, it ?
<rtg> apw: ' patch for the #NN -> #21-Ubuntu is in the pipe'
<apw> nope, that means 'on the way to the mailing list'
<apw> i did push the other fix, but i assume you have done your thing since then
<apw> if not i'll do it again
<rtg> apw: I have the __u32 fix, and my chrome9 patch is still top of the gitweb.
<apw> rtg all sounds good to me
<rtg> hmm, looks like the biking season has come to an abrupt end. in the last 2 hours 2 inches of snow has accumulated.
<rtg> amitk: iop32xx FTBS'd on the last upload. do you expect that it will succeed this time? 
<amitk> rtg: 2.6.28-1.1?
<rtg> amitk: yes
<amitk> rtg: I see it successfully built
<amitk> https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-1.1/+build/798103
<rtg> amitk: getabi failed, so I assumed.... lemme go look closer
<lamont> OH HAI.  I CAN HAZ MY ETHERNET BACK PLS?
<rtg> lamont: ARE YOU DEEF?
<lamont> I did a dist-upgrade, intrepid-security kernel, and *poof* no BCM4401-B0 agaiin
<rtg> lamont: you have LBM installed, right?
<lamont> linux-backports-modules-2.6.27-9-generic is already the newest version.
<rtg> lamont: you'll likely have to pull from -propsed
<rtg> -proposed, even
<lamont> so when does intrepid release then?
<rtg> early Q1 probably
<lamont> yeah - please to quit breaking
<lamont> kthx
<rtg> lamont: bitch and moan
<lamont> I realize it's not like anyone is actually using it or anything.... :-(
<rtg> amitk: the problem is the package name, e.g., iop32x v.s. iop32xx
<lamont> rtg: 2.6.27-10?
<rtg> lamont: that should be the version in -proposed
<lamont> yeah, but no way in hell I'm dist-upgrading from -proposed --> cherrypick
<rtg> lamont: why not? its your laptop. ots not like its a production server
<lamont> my laptop
<lamont> == production lifeblood
<rtg> lamont: what model?
<lamont> inspiron 1520
<rtg> lamont: I think I have one of those. I'll test it, but I think -proposed is working pretty good.
<rtg> I know for sure the b44 issue is resolved.
<lamont> which still brings up the question of how -updates got the b0rked one.  again.
<Kano> maybe remove the backport modules
<rtg> 'cause we has a -security kernel update which necessitated an ABI bump.
<rtg> LBM has not been promoted to -updates in awhile
<rtg> Intrepid LBM, that is.
<lamont> rtg: one would expect that we'd rev lbm at the same time...
<lamont> and the currently running kernel is -9
<rtg> lamont: I did, but only the ABI number. I'll bug pitti, its probably time to push LBM to -updates
<amitk> rtg: it should've been iop32x
<BenC> sweet, lrm builds without problems under 2.6.28
<BenC> rtg: let me know when you get -2.2 uploaded and I'll follow with an lrm to match it
<rtg> BenC: still test building. I ran into a problem getting ABI files, etc. also had some background distractions with Intrepid LBM.
<rtg> fabbione: I've been meaning to ask you if we still need gfs? Is fs/gfs2 sufficient?
<fabbione> rtg: you still need gfs for at least another 3/4 years I guess
<fabbione> rtg: you can drop gnbd
<fabbione> rtg: gnbd has been deprecated upstream
<rtg> fabbione: thanks, consider it gone.
<fabbione> rtg: do you need a newer gfs for .28?
<rtg> fabbione: yep
<fabbione> rtg: remember that now gfs doesn't need any extra patches to kernel like it used to
<rtg> fabbione: I think BenC just forward ported Intrepid gfs to Jaunty
<fabbione> rtg: old versions of gfs required some exported symbols from gfs2. This is not the case anymore since .27
<fabbione> rtg: I dunno.. I'd like to see the patches tho so we can actually apply them upstream
<fabbione> rtg: also.. you guys should really stop doing that forward port without upstream..
<fabbione> or at least talk to us
<fabbione> it's bad for you as you lack tons of bug fixes
<fabbione> and your gfs doesn't go through QA
<fabbione> so if it breaks you keep the pieces :)
<rtg> fabbione: I agree with everything you're saying. its a matter of resources.
<fabbione> rtg: if you have the time to port gfs, you have the time to send me an email, same as you can ping me on IRC :)
<rtg> fabbione: well, I was still busy with Intrepid while BenC was doing Jaunty, so the stink is on him.
<fabbione> rtg: i didn't blame you.. just that the resource thing doesn't hold with me as I have been there before :P
<apw> fabbione, i suspect he did a git rebase, and it 'worked' so its wasn't any effort
<apw> (other for the computer)
<BenC> fabbione: gfs didn't build right away, so I just disabled it for the first upload
<BenC> fabbione: intentions were to download the newer version for next upload
<fabbione> BenC: ok. we don't have a version for .28 yet
<BenC> fabbione: I did no porting to gfs at all
<fabbione> BenC: ok :)
<fabbione> BenC: i'll ping you as usual to do a pull when it's ready
<fabbione> no panic
<BenC> s/GFS=m/GFS is not enabled/
 * apw senses an effort shift to fabbione ... excellent for us :)
<fabbione> Juanty barely started
<fabbione> apw: you have no idea who I am, do you?
<BenC> fabbione: sure thing...I can do the pull whenever it's ready
<BenC> apw: fabbione is the godfather that brought me into canonical as the "kernel team"
<fabbione> BenC: absolutely.. usual stuff, or I'll make sure that your shrink will be rich out of your money for the next 100 sessions
<apw> heh nope no clue ...
<fabbione> apw: I used to be the kernel team alone for about 2 releases
<fabbione> apw: :)
<BenC> fabbione: My shrink is named beer, and he's pretty cheap
<apw> that i don't envy you :)
<fabbione> and at the time there were more arches to support than you do
<fabbione> BenC: should I really really remind you about me trying to grab your ass at night??
<apw> yeah that must have been at best 'mad' ... 
<BenC> fabbione: but you weren't the OEM's little mistress back then :)
<BenC> fabbione: it took several weeks of beer and jaegar bombs to get over that night
 * BenC shivers
<fabbione> BenC: ehheeh true that...
<fabbione> haha
<fabbione> anyway.. kill gnbd
<fabbione> I'll make userland disappear soonish
<BenC> fabbione: I think clan now has a 3 foot minimum spacing between beds in shared rooms requirement because of my complaints about that
<fabbione> apw: and btw.. now I am release manager for gfs :)
<fabbione> BenC: ROFL
<fabbione> apw: for me it's a no brain to do it for ubuntu
<BenC> fabbione: especially because I don't think jono is any safer than you are even though he is married now
<BenC> fabbione: when do you think a gfs pull will be ready?
<fabbione> BenC: end of next week maybe
<fabbione> BenC: I am rebuildnig the whole datacenter here
<fabbione> BenC: and I had too many issues before I could start reinstalling the community clusters (fedora, ubuntu etc)
<fabbione> BenC: i need to show you pictures of what I have done here :)
<apw> fabbione, nice to know :)  i am a lowly pleb
<fabbione> BenC: a 8 heads workstation ;)
<fabbione> BenC: 5000x2300 resolution.. given or taken :)
 * amitk thinks of forwarding the irc log to clan to push for separate rooms
<fabbione> amitk: ahah you have my blessing!
<fabbione> HI CLAN!
<fabbione> :)
<BenC> amitk: either that, or we should have a mental anxiety reimbursement :)
<amitk> fabbione: sweet... played flight simulator on that?
<fabbione> amitk: not yet.. i just installed it 2 days ago :)
<fabbione> amitk: but the CPU is not a gaming one
 * BenC imagines fabbione playing frets of fire and having the biggest video crowd ever!
<fabbione> BenC: try to imagine something more useful than gaming
<fabbione> this is the best Porn machine ever
<BenC> hehe
<fabbione> 8 porn movies at the same time!
<fabbione> (welcome to quote me ;))
<BenC> 2girls1cup, mr hands, pain olympics, and all their glory
<Nafallo> AltGr+e ftw? ;-)
<zul> fabbione: nice
<apw> rtg did you push the tags for this new jaunty?
<apw> i have a -2.2 tag, but the 1.1 and 0.0 are missing
<rtg> apw: I did
<rtg> apw: it says everything is up to date
<apw> hmmm ... they are still in their originals on my fetch
<apw> you have to explicitly push tags
<apw> iirc
<rtg> 'git push --tags origin master' is what I just did
<apw> oh hmmm i had to explicitly fetch the tags ... oddness
<rtg> I've run into that before
<BenC> rtg: git-push --tags
<apw> i am pretty sure its not meant to do that... 
<BenC> err, nm
<BenC> rtg: you shouldn't really explicitly push origin, fyi :)
<rtg> BenC: why not? I _always_ check to make sure I know what origin is first.
<rtg> BenC: also, you do your LRM thing now.
<rtg> s/you/you can/
<BenC> rtg: just the nature of origin is local to the repo...I don't think it will hurt anything, just that master is the one that matters
<BenC> rtg: ack on lrm, thanks
<apw> BenC, how do i figure out what head you started from when you rebased to .28 for the first time?
<BenC> apw: hard to tell, but you can get an idea from the changelog as to where it was when I cloned it
<BenC> the entry before 2.6.28-1.1 is the last upload before I cloned, so that + maybe-some-other-commits
<apw> we should probabally tag that in future
<apw> and i'll try and figure it out too
<mnemo> is there any 2.6.28-rcX kernel packaed for jaunty yet?
<amitk> mnemo: 2.6.28-1.1 available from https://edge.launchpad.net/ubuntu/jaunty/+source/linux/2.6.28-1.1
<amitk> and if you wait a day you might get a -2.2 that based on the latest -rc
<BUGabundo> can some on help me debug my system ?
<BUGabundo> I'm getting kernel locks on shutdown (halt)
<BUGabundo> and suspend stop working last week
<BUGabundo> I'm on jaunty
<mnemo> amitk: when I did "update-manager -d" it left me with 2.6.27-something, is that normal? do I need to do something explicit to switch over to the new kernel?
<BUGabundo> mnemo: I got stuck on the .27 kernel until I manually installed it via synaptics
<amitk> mnemo: 2.6.28 is not installable through update-manager yet. Some meta packages are missing
<amitk> best wait a day or so if you need update-manager support
<BUGabundo> yeah amitk... it looks like it
<BenC> lrm on its way up
 * fabbione larts BenC for not building usb-serial in sparc hardy kernel!
<BenC> fabbione: was hardy sparc still built from linux proper source?
<fabbione> yeps
<BenC> fabbione: I claim lack of need for usb-serial
<fabbione> i claim I need it :)
<fabbione> i just plugged my backup adsl line in my new (sparc) firewall and zack
<fabbione> <- owner
<fabbione> owned
<BenC> fabbione: become a sparc community kernel maintainer :)
 * fabbione larts BenC with a pci2usb card ;)
<fabbione> BenC: i am going to test it.. if it works, can you just flip it on the next build?
<fabbione> it's sparc only, doesn't affect main arches yada yada
<BenC> fabbione: bug report, SRU request, kernel-team@
<fabbione> SRU?
<fabbione> for a config option on a non supported arch?
<BenC> Stable Release Update
<fabbione> yeah i know what SRU is.. i mean all the paper work for non supported arch?
<BenC> fabbione: I don't handle stable, best to talk to smb_tp
<fabbione> ok.......
 * smb_tp comes over
<fabbione> smb_tp: ^^^
<fabbione> brb
<smb_tp> fabbione, ok, so I have some time to read context :)
<smb_tp> fabbione, Ah ok, well if it works, at least write a mail asking and explaining why to kernel-team@. You will help greatly if you could do a simple bug report as well, but since it is so simple I can do it this time. ;-)  It is hard but it helps remembring why things were done. Especially since team now is >1
<fabbione> smb_tp: ok.. but remember a good git entry in the log and debian/changelog is also as useful :)
<fabbione> smb_tp: anyway first testing... then everything else
<fabbione> smb_tp: if i am bored iÂ´ll just give you a tree to pull :)
<smb_tp> fabbione, Heh, for sure
<bdmurray> apw: Is the fix for bug 193970 only for the iwl4965 driver?
<smb_tp> fabbione, Even better. :)
<apw> bug #193970
<apw> bah stupid ubotto
<rtg> ubotto sleeps with the fishes
<apw> bdmurray, yes the fix ascribed to that bug seems to only help the higher level iwl4965 driver
<apw> its on my list to find out if there is another fix out there for the older driver
<rtg> apw: it applies to both iwl 4K and 5K drivers.
<apw> yeah, will investigate further tommorrow
#ubuntu-kernel 2008-12-03
<x86> i'm having a hell of a time finding the source tree for the EXACT kernel I'm running
<x86> i'm running 2.6.27-9-server, and every package I try to get installs source for 2.6.27, 2.6.27.2, or some variant thereof
<x86> none of them are -9
<x86> I'm running 8.10-server
<x86> can anyone help me?
<x86> i've tried apt-get install linux-source, apt-get source linux-image-2.6.27-9-server, and I even tried the .deb package directly i found on ubuntu's software repository that claimed -9
<x86> none of which compile as -9 though
<BenC> x86: apt-get source linux
<mjg59> x86: If you just compile with make, you won't get -9. That's passed as EXTRAVERSION in the package build scripts.
<x86> mjg59: well I need -9 appended and .2 taken off
<mjg59> x86: Then use the package build scripts
<x86> mjg59: when I compile my Digium hardware drivers, it puts them into /lib/modules/2.6.27.2, instead of /lib/modules/2.6.27-9-server like everything else
<x86> mjg59: got a tutorial?
<mjg59> Wait. Why are you building against the kernel source rather than the kernel headers?
<mjg59> Don't do that
<x86> it requires the kernel source tree
<x86> (it needs /usr/src/linux)
<mjg59> Then it's broken
<x86> it uses genksyms and such
<mjg59> Unless it's actually sourcing C files into the build, all it needs is the linux-headers-2.6.whatever-foo package
<x86> stuff in /usr/src/linux/scripts
<mjg59> Which includes everything needed to build modules
<mjg59> Including genksyms
<x86> ok, so I can ln -sf /usr/src/linux-headers-2.6.27-9-server /usr/src/linux ?
<x86> hmm, looks like! :)
<mjg59> Well, or make the drivers build against /lib/modules/`uname -r`/build rather than /usr/src/linux, but yeah
<x86> excellent
<x86> you're a lifesaver thanks so much :)
<mjg59> No problem
<BenC1> amitk: do you have the need for madwifi on armel?
<drguildo> hi
<drguildo> does stuff like
<drguildo> [  770.458139] end_request: I/O error, dev sr0, sector 16679280
<drguildo> [  770.458158] Buffer I/O error on device sr0, logical block 2084910
<drguildo> mean my dvd drive is screwed?
<drguildo> i get it every time i insert a disc
<drguildo> but e.g. a dvd movie seems to play fine in mplayer
<drguildo> it seems to be only when i insert a disc
<drguildo> it happens with 2 drives i've tried
<amitk> BenC: no
<zul> BenC: what do you think about moving drbd to dkms?
<BenC> zul: for what purpose?
<zul> so the kernel and userspace matches up if there is a need to change in the release cycle
<rtg> zul: what is drbd?
<BenC> zul: we do a lot of uploads through the development cycle...not sure how much more control you would need
<BenC> zul: separating it would require you to add some dependency to make sure upgrades work
<zul> rtg: its cluster program which allows you to share disks
<zul> true...which version did you port to 2.6.28?
<BenC> zul: the same as in intrepid....we can pull whatever updates you want though
<zul> BenC: ok thanks..
<zul> that makes life easier
<rtg> apw: I see that Jaunty has EDAC_AMD76 enabled. Does it have the same issue with AGP apertures as Intrepid?
<rtg> BenC: are you working on Jaunty linux-meta? I got pitti to flush the kernel, so LRM ought to complete sometime today.
<BenC> rtg: Yeah
<BenC> rtg: thought you were leaving today?
<rtg> BenC: in awhile.
<rtg> gotta produce a blueprint first
<rtg> BenC: pgraner is bored and listless in an airport with his CPU running full on. Maybe you could look over his shoulder and figure out why his update to -proposed isn't working.
<apw> rtg, i am unsure if .28 is affected by the agp thing, i wonder if we have any h/w which might demonstrate that
<rtg> it seems like a very northbridge specific problem.
<rtg> or is it southbridge, I forget.
<apw> the reporter says nothrbridge specific
<rtg> apw: how about bugging the maintainer to see if it sounds like a familiar problem?
<apw> yeah ... that is a good suggestion
<lod__> hello, I have a Q.; I'm maintaining custom kernel with IMQ patch for QoS, and using the guide at wiki.ubuntu.com for building custom kernel, but can't find where to change revision numbers for builded kernel, I've looked at debian/rules but can't find it..
<apw> lod__, the version number comes from the debian/changelog
<lod__> from the first line or?
<alex_joni> lod__: use dch or dch -i to manipulate it
<lod__> it opens changelog for editing? what should I change?
<lod__> i think i've got it
<lod__> 10x
<alex_joni> it might take 1-2 iterations to get it fully right, there are certain numer/name combinations the kernel buildscript won't like
<lod__> if I inc. the last number, and made no change to ubuntu-modules, will It compile?
<lod__> Is there a reason to add jaunty? linux (2.6.24-22.45ubuntu1.1) jaunty; urgency=low
<alex_joni> it will compile, but you'll get problems
<alex_joni> when there's a new ubuntu kernel it will overwrite yours
<alex_joni> I suggest naming it differently
<lod__> when there is new kernel I'll recompile it with the patch
<alex_joni> depends how big your audience is.. if it's only for you it's surely ok whatever you do
<lod__> I just don't wan't to override mine even If there's no change, like now..
<lod__> It's for personal use.. Not that I'll forbid someone to use It..
<lod__> 10x again..
<lod__> have a great day..
<apw> rtg you acked one of my threads on the email list (the CONFIG_EDAC_AMD76X bug), are you acking the patch option or the blacklisting option?
<rtg> apw: um, I thought I only saw one, i.e., disabling the config option.
<apw> in the leader i also suggested we can blacklist the module, though i know not where those come from!
<apw> (blacklisting as an alternative)
<rtg> I wonder how many users are afflicted with this problem?
<apw> not a huge number i'd guess from the bug
<apw> i am guessing we have a fair number of AMD based systems in our team alone and noone there had the combination of h/w which triggered it
<rtg> apw: you've suggested blacklisting to them?
<apw> they found blacklisting worked yes
<apw> (the submitter)
<rtg> what is the downside for folks that have this northbridge, but don't have the radeon GPU?
<rtg> the downside of blacklisting by default, I meant
<apw> well its not just radeon, the apature is not setup correctly so no AGP graphics will work in DRI mode
<apw> the edac module for them is supposed to report on correctable errors that occur on the system
<apw> and they obviously didn't have it in hardy
<rtg> I assume you have to have ECC RAM before EDAC makes sense?
<apw> that is my expectation yes, i don't know a lot of the details sadly
<rtg> so, that likely means the effects are primarily in the server community.
<apw> yes that was my take
<apw> i wonder if it would 
<apw> be better to leave it built, but mark it blacklisted by default
<rtg> I think in that case that blacklisting makes the most sense. It leaves the module available for installation if its really needed, and afftects the smallest number of platforms.
<apw> ok, can do that ... where are our blacklists ?  i assume they are in some other package?
<rtg> modules-init-tools
<apw> actually lets restate that ... do we default it blacklisted or just leave it as is
<rtg> you add a blacklist file in module-init-tools, leave the config option enabled.
<apw> ok ... so i'll look at that then.  a good excuse to figure out how one updates m-i-t
<apw> how does one even find the owner of a package
<rtg> Ubuntu owns the local modifications to the package. this isn't something upstream is likely gonna want.
<smb_tp> apw, A quick question. Just saw your mail about the audio patch. I want to make sure I understand: you booted an unpatched hardy kernel and that worked ?
<apw> smb_tp, yes that is correct.  i booted the latest .24 that was installed before i updated and that the sound is routed correctly.  it appears the specific system is not recognised back there, and the default is much closer to useful than that in intrepid
<smb_tp> Interesting. 
<rtg> smb_tp, apw: its not surprising. I think there were a number of ALSA regressions between Hardy and Intrepid.
<smb_tp> Ok, but this way. BTW, the STAC_DELL_M6 is defined there... Not sure this matters
<apw> apw@dm:~/git2/ubuntu-hardy$ git grep DELL_M6
<apw> apw@dm:~/git2/ubuntu-hardy$ 
<apw> i don't see it in my tree?
<smb_tp> lum?
<apw> ahh point
<rtg> yeah, hardy LUM
<smb_tp> possibly it defaults there to something sensible and less sensible in intrepid.
<apw> so when i updated to intrepid would hardy-lum have been deinstalled
<smb_tp> no, all is in the modules dir for the kernel. the co-exist
<smb_tp> s/the/they/
<apw> ie. i no longer have a full modules install for my hardy kernel
<rtg> apw: yep, it likely did an autoremove when you dist-upgraded - furthermore, we're using ALSA straight from the kernel in Intrepid.
<apw> oh yeah there they are, ok so this testing is with lum installed, so i guess its safe to say that the default was better in hardy, so any backport there seems unessary risk
<smb_tp> right
<apw> ok so i think i've done the right thing and done nothing there, and marked the nomination invalid with a reason it works there
<apw> rtg is it correct to say that the kernel team owns module-init-tools?
<smb_tp> Right, yes. I actually just wondered about the fact it worked without changes (and that the model would be missing). 
<apw> smb_tp, they have definatly added support for the whole family of dells to the kernel, so i am not supprised that this one got broken
<apw> they added a general 'reference' implementation for ICH9
<apw> which was not there before, and the refereence is wired dfferent to the dell i have
<apw> so it needs a model quirk to fix that ... 
<smb_tp> Ah, ok. Well it seems everything is wired differently nearly everywhere
<apw> its mad as mr mad jack mc mad, basically you need 20 binary words for every machine in existance in the kernel
<apw> soooo scalable
<apw> rtg so i have gotten the module-init-tools source package and modified it to add the blacklist entry -- debdiff seems to show something sensible
<apw> what does one do next?
<apw> i guess i should upload them to my PPA and see what happens, if they build ok
<smb_tp> apw, right, and if you are happe you need to find someone with upload rights.
<smb_tp> s/happe/happy/
 * smb_tp curses his fingers
<apw> smb_tp, thanks ... like a sponsor i guess
<smb_tp> Well in this case rtg might be a good choice. ;-)
<smb_tp> And after that it goes the usual way through archive admins. This package might be special since so closely related to kernel. In the past I tried to look at the changelog and find out who did previous uploads for Ubuntu
<apw> smb_tp, yeah rtg and ben are the people who did it before so i'll go to them
<apw> _once_ i have figured out how to put it in my PPA
<apw> smb_tp, got any how to's for PPA's ?
<fabbione> smb_tp: [   52.835985] usb 1-1: airprime converter now attached to ttyUSB0
<smb_tp> should be quite simple. change changelog to something with an extension to recognize. release should be something without -proposed or so. then there was a wiki how to configure dput or dupload.
<fabbione> ^^ the sparc thingy.. I'll prepare a tree for you tomorrow or so
<fabbione> smb_tp: based on what .git tree do you want that? (hardy)
<apw> struggling to find any docs at all, which is unlike us
<smb_tp> fabbione, Ok, sure. I remember. Was that missing in the hardy tree? Oh well, I figure out somehow. :)
<smb_tp> apw, Jus a sec. I try to find it...
<fabbione> smb_tp: when you enable the usbserial, it asks tons of config options. there are 3 needs to be set. I'd prefer to send you a diff or something but I need to know on top of git tree you want it
<fabbione> smb_tp: -updates? -security? whatever?
<smb_tp> fabbione, -master is fine
<fabbione> smb_tp: ok
<fabbione> if then you want to propagate the change forward, it's up to you. I only care about hardy for this machine :)
<fabbione> because I don't plan to reinstall it anytime soon
<smb_tp> Sure. :) NTARS
<fabbione> NTARS?
<smb_tp> Never Touch A Running System
<fabbione> ah ok
<fabbione> yeah indeed
<apw> smb_tp, found it ... finally
<smb_tp> apw, Ah, beat me. I also could just send you my config, if you like
<fabbione> smb_tp: this same machine was the "one" that did bootstrap all of ubuntu sparc alone.. a single cpu (old as hell) with 512Mb of RAM.. it's undestroiable
 * fabbione can still hear elmo's screaming :)
<smb_tp> LOL, I can imagine. How long did that take?
<fabbione> it took about 3 weeks to catch up with the archive
<fabbione> and then it was just keeping up
<apw> nasty
<fabbione> it did miss hoary release for one package because of my mistake.
<smb_tp> The machine or the PPA upload?
<apw> smb_tp, please do send my your archive if you don't mind
<apw> the machine, is nasty :)
<fabbione> apw: it's a very small Netra T105.. google for it :)
<fabbione> it was doing OOo builds over nds
<fabbione> nfs
<fabbione> it doesn't have enough disks for that :)
 * apw feels for the machine facing that life
<smb_tp> apw, sent you the config
<smb_tp> which is probably most that is special
<smb_tp> You either use dupload (simpler since this is a config for that) or dput
<smb_tp> Since you used debdiff, you already have a source package for it
<apw> i seem to have dupload installed and your config is for that, so ... seems ok
<apw> yep learned that side of things when trying to follow along with the linux-meta update
<smb_tp> just change the name ;-)
<apw> smb_tp, yep .. thanks ... i've hit upload and it did something reasonable looking -- how long does it take from there to appear in your ppa?
<smb_tp> apw, You will see it quite fast. Then it takes some time to build (well the kernel at least) mit should be better
<apw> ahh there it is .. cool
<apw> last i looked there were no PPA builds on the buildd's, of course _now_ they are all rammed.  typicial!
<smb_tp> dum di dum...
<smb_tp> one could be me
<apw> yeah one is you!
 * smb_tp sneaks away
<apw> rtg ok ... i have and updated module-init-tools which seems to work.  i have built and uploaded it to my PPA and installed it from there locally and good things happened.  you available to talk me through the next step?
<fabbione> smb_tp: works fine .. all of it
<fabbione> smb_tp: i am on ppp over cdma over usbserial on sparc... wanna check? :P
<apw> fabbione, that sounds like some kind of mental torture
<fabbione> apw: i never claimed NOT to be in some kind of BDSM games with my computers
<apw> heheh, and who is the masters and who the slave?
<fabbione> i rule the world and you? ;)
<apw> i like to think so, but suspect i am also deluded
<fabbione> ehhee
<rtg> apw: I'll catch up to you tomorrow wrt to module-init-tools. 
#ubuntu-kernel 2008-12-04
<apw> smb_tp, i presume the launchpad bug robot only closes bugs listed in the changelog
<smb_tp> Only those that have a matching But: # entry there
<smb_tp> s/But/Bug/
<apw> so any bugs which arn't duplicates bug fixed by the same fixes basically have to be manually handled
<smb_tp> yes, that is correct.
<apw> cool thanks
<smb_tp> We might try for future ones whether comma separated lists work. Never had that before
<mne> Hi. Where can I see which patches have been applied to the ubuntu kernel ? Also, is there a way to see the memory segments the kernel is using ?
<amitk> mne: in the kernel git tree on kernel.ubuntu.com
<mne> thanks
<apw> mne what do you mean by 'the memory segments the kernel is using' ?
<apw> the kernel generally uses all memory for something
<apw> you can see the memory segments for each process in /proc/<pid>/maps, but that isn't the kernels use
<mne> well, I'm just playing a bit with kernel runtime patching. And as soon as I write to a valid address, the kernel crashes. I just write one single byte and the byte value is the same than the value that's already on that memory position
<apw> crashes with what error?
<mne> With the vanilla kernel it works
<apw> from what context are you trying to write, what sort of place are you trying to write
<mne> it's in entry_32. I'm trying to patch an instruction byte. I'm just rebooting the image so that I can give you the exact error message
<amitk> mne: what interface are you using? /dev/kmem ?
<mne> My code is inside a kernel module. I'm getting the address through an exported kernel symbol
<apw> its entirly possible those code pages are r/o in the MMU, as there is no good reason for them to be writable
<mne> is that a difference between the ubuntu and the vanilla kernel ?
<apw> by preventing them being writable a vector for attack is made more difficult
<apw> i am supprised its not the same in vanilla, but it could be app armour
<apw> anyhow, let us know the actual error
<mne>  BUG: unable to handle kernel paging request at c0104010
<mne> I'm pasting the whole message on pastebin
<mne> if you want
<apw> yep
<mne> I'm playing with an old kernel rootkit for security research (I want to know how it works)
<mne> http://pastebin.com/m1138ecfb
<apw> i assume that that is the write, so it does look like you have written somewhere early in the kernel image and been told NO
<mne> so the address is just not writeable ?
<mne> The address itself is correct, i have verified that
<apw> you have cirtainly hit a protection fault
<apw> and if you are writing to the right place, and the address is believeable for the kernel code
<apw> then it looks to be protected, which would be my expectation actually
<mne> hmm, ok. thanks for helping
<mne> Where would I have to look to see which memory regions are protected ?
<mne> you said it's inside mmu ?
<apw> i would guess app armor has changed the way the kernel protects itself if vanilla is not
<apw> the page tables hold the protection information for everything including the kernel
<mne> good, I'll have a look there then. thanks
<mne> I have to leave for work now, I'll look at it afterwards
<tim> hi ... got a slightly off-topic question ... is there an ubuntu package providing the man pages for the kernel routines?
<apw> tim manpages-dev perhaps?
<tim> apw, unfortunately not ... the only manpages for kernel routines i found, are part of `freebsd-manpages', describing freebsd kernel functions :/
<apw> which manpage are you after
<tim> kfree ... i found a man page on the net, but would prefer to be able to read them offline
<cking> as far as I know there are no kernel API man pages available
 * amitk nods
<tim> ah, that would explain, why i don't find them ... thanks ...
<amitk> the Documentation directory, Linux Device Drivers, and such books are your best bed
<amitk> *bet
 * apw agrees
<cking> or the kernel source :-)
<feroz> hello!
<GCF> hello feroz (anti vent :p)
<feroz> :D
<feroz> Anyone is familiar with hid devices here?
<fabbione> smb_tp: please pull from here http://kernel.ubuntu.com/git?p=fabbione/ubuntu-hardy.git;a=summary
<fabbione> smb_tp: the only thing is that i was not able to verify if there was an ABI change. It will probably tell you that there is a module or two more
<fabbione> smb_tp: let me know if you need anything else
<smb_tp> fabbione, ok. That should be ok. More symbols are accepted. Just changes would be bad
<fabbione> smb_tp: yeah i know the story... but i don't know if you made your checks stricter than when I first wrote them :)
<fabbione> anyway.. only one change in that tree
<fabbione> it's on your latest hardy tree as of 10 minutes ago checkout
<smb_tp> fabbione, no not stricter. :) Just Ben got annoyed enough with the diff type approach that he changed it to an enhanced perl compare.
<fabbione> i can't say on public IRC what's passing through my mind :)
<fabbione> Ben is a ***** developer :P
<fabbione> just because I have been friend with ben for way too long ;)
<smb_tp> heh. :) Guess I have to ask him next week :)
<fabbione> ahah sure
<fabbione> i am off
<fabbione> have fun
<smb_tp> thanks, u2
<mne_> Hi, how can I change a kernel page protection entry ? there is change_protection, but the symbol is not exported
<apw> they are probabally hinting that should shouldn't be doing that
<sconklin> is there anything I should know before I dive into several quickcam driver bugs? 
<cking> sconklin: I suspect you will find out
<sconklin> haha. yeah.
<sconklin> there are some comments in some bugs that make me think maybe we're already carrying some patches that aren't upstream, that's the first thing I'll go investigate
<cking> sconklin: what's the probs with the quickcam driver?  The issues I've seen are usually weird frame offset / geometry problems which need tweaking for different variants of the hardware
<sconklin> there are various problems, differing slightly with model number. One "doesn't work" when plugged in, but some workarounds get it to work with funky video. Another doesn't have hal detect it as v4l capable.
<sconklin> The bug numbers I'm looking at are:
<sconklin> bug 196811 bug 22070 bug 134285
<cking> the slightly different model number can be subtle - sometimes the chipset is completely different - the pressure for cost reduction means that chipsets can radically change between model numbers
<sconklin> yeah, I was aware of that, thanks. I've dealt with wireless adapters that are packaged identically but have different chipsets and identifiers.
<cking> ..yeah - these kind of fun issues just to keep us on our toes!
 * cking wonders if he can fit one more build in before the day is done
 * sconklin knows he can't
<cking> depends on how long one's day is really :-)
<sconklin> tonight we have a band parents supper, so no working late for me
<cking> good plan.
 * cking bailing out - build done, test failed, respin another day
#ubuntu-kernel 2008-12-05
<apw> does anyone understand the relationship between in kernel alsa, and the stuff released at http://www.alsa-project.org/main/index.php/Main_Page
#ubuntu-kernel 2008-12-06
<ziroday> Hi, I am getting this https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116752 and wondering what more info is needed
<jgoguen> I'm getting random kernel panics on Ubuntu Intrepid, 2.6.27-9, caps lock blinks, nothing in the logs, not even Alt+SysRq keys have any effect...how else can I get enough information to either add to or create a bug report for this?
#ubuntu-kernel 2008-12-07
<psusi> why does linux-meta only contain debian/ and debian/rules does not even look like it builds anything?
<jgoguen> I'm getting random kernel panics on Ubuntu Intrepid, 2.6.27-9, caps lock blinks, nothing in the logs, not even Alt+SysRq keys have any effect...how else can I get enough information to either add to or create a bug report for this?
<jgoguen> I'm getting random kernel panics on Ubuntu Intrepid, 2.6.27-9, caps lock blinks, nothing in the logs, not even Alt+SysRq keys have any effect...how else can I get enough information to either add to or create a bug report for this?
<jgoguen> I'm getting random kernel panics on Ubuntu Intrepid, 2.6.27-9, caps lock blinks, nothing in the logs, not even Alt+SysRq keys have any effect...how else can I get enough information to either add to or create a bug report for this?
<stgraber> 4th time you're pasting this one. Most developers are at UDS or going to UDS at the moment, I wouldn't expect an answer and asking once an hour won't help.
<stgraber> I would suggest looking at the wiki pages for Kernel debuging, then file a bug report with all the required information (dmesg, lspci, ...)
<jgoguen> stgraber: oh, I didn't know UDS was now...I have been on the kernel page, but all the other bugs without obvious problems in the requested files seem to be inactive, but I'll go ahead and file another one
<glick> hello
<glick> excuse me im following along on the community Kernel/Compile docs and im running into some problems/inconsistencies
<glick> for example when in the kernel source directory i issue this command:
<glick> CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic
<glick> i get the following error:
<glick> /usr/bin/fakeroot: line 164: debian/rules: No such file or directory
<glick> it appears that the debian subfolder is empty
<alex_joni> glick: depends how you got the sources
<ahmad1> I have "Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)"
<ahmad1> it is working correctly but the mic is not
<ahmad1> can anyone guide me?
<andersk> The first thing to check would be the capture volume: http://linux.dell.com/wiki/index.php/Ubuntu_7.10/Issues/External_Microphone_Capture_Volume_Low 
<ahmad1> andersk: thanks for ur interest, I am checking that
<ahmad1> andersk: I don't have these tracks (Front, MUX, Digital)
<andersk> The exact tracks vary by hardware.  I dunno; play around with whatever tracks you have. 
<ahmad1> andersk: the Capture track has a small icon "Toggle audio recording from capture", it is off
<ahmad1> andersk: every time i toggle it and close the window, it returns off again
<andersk> Interesting.  You could also try `alsamixer -Dhw:0 -Vcapture` (see man alsamixer)?  I'm running out of ideas, though. 
<ahmad1> andersk: the capture line is set to 100 and is written by red (the man ensures that this is the on mode)
<ahmad1> but still nothing is recorded
<andersk> You also have to select the appropriate capture device (for example, I have Mic, Mix, and Internal Mic) by highlighting it and pressing space. 
<andersk> I also have a Mic Boost slider that controls the volume of the mic. 
<ahmad1> andersk: I don't have boxes over these tracks and pressing space toggles one and disable the others (written in man also)
<ahmad1> how can i save in alsamixer (i press "esc" to exit)
<andersk> Changes don't need to be saved; they're applied immediately. 
<ahmad1> andersk: so is it kernel problem?
<andersk> I don't know. 
<ahmad1> :-D it worked
<ahmad1> i increses the bars over "IEC958 P"
<ahmad1> I don't know what is that but it works
<andersk> Great. 
<ahmad1> andersk, thnx for ur help :)
<damianc> hello
<damianc> anyone awake
<damianc> hello
<damianc> where is everyone
#ubuntu-kernel 2009-11-30
<Kano> hi, how to disable acpi-thermal when it is builtin?
<apw> Kano, it has a module param 'off' so you should be able to do that from the kernel command line
<Kano> acpi-thermal=off?
<apw> more likely acpi-thermal.off=1 by the look of it, the prefix is a bit of a guessing game
<Kano> hmm maybe even without
<bencer> hi all, i'm building a custom flavour of hardy kernel, but i get an error on abi-check. abi-check-* target is looking for an old build: http://launchpadlibrarian.net/36256913/buildlog_ubuntu-hardy-amd64.linux_2.6.24-25.63~ebox1_FAILEDTOBUILD.txt.gz
<bencer> any clue on how to fix this ?
<Kano> disable all checks
<bencer> custom-binary.d/README doesn't say anything about this
<Kano> skipabi=true skipmodule=true
<Kano> add that
<bencer> Kano: where ? rules.d/ARCH.mk ?
<Kano> apw: btw. since .32 the virtual build is broken when i compile generic-pae. i do not need it anyway but i dont get why
<bencer> Kano: i think binary-custom.d/myfalvour/rules is the right place to do so, isn't it ?
<Kano> bencer: i usually compile it manually
<bencer> Kano: i need to build it on my ppa ... local builds are easier to workarround, yes :)
<Kano> i think it is another file, apw should know it
<apw> for a PPA build putting it in the .mk will work just fine
<smb> bencer, The "normal" way to get around this is to download the abi files from the last build "./debian/scripts/misc/getabis 2.6.24 <rel.nr>"
<apw> often those files are also available in the git report, if there is a startnewrelease commit
<bencer> smb: i see, but to get this build on launchpad ?
<apw> of course you would also need to have not made any abi sensitive changes to prevent the checks still triggering
<smb> bencer, The last one in your case would be the latest that was build and released.
<smb> If you are using the latest repo, this would be 25.63
<smb> (for which no startnewrelease has been done, yet"
<bencer> i'm patching this kernel with l7filter ...
<smb> Its a bit of download as it pulls the binary packages of all kernels and arch
<smb> Can't say I know from my head how much this changes
<apw> thats likely to be an abi bumper anyhow, so you'd want to just turn it off
<smb> There could be a bumper as apw says
<ghostcube> hi peoples 
<bencer> ok, going to switch off all these abi checks
<ghostcube> i have a question about my nerdy webcam bug 
<ghostcube> does the upstart do at anytime again an slow boot to ctch things changed ?
<ghostcube> catch
<ghostcube> this would explain why my cam works one day and a few days later it doesnt
<apw> whenever you install new packages, you will find it does a ureadahead rescan which is slower
<bencer> btw, i want the same config than the -server one, so i generated my binary-custom.d/myflavour/ARCH.config from config/ARCH/config + config/ARCH/config.server, is that right ?
<ghostcube> ok that would explain why it worked yesterday again
<apw> iirc we did suggest this was possible
<apw> and i thought you were going to watch updates to confirm the pattern
<ghostcube> apw: yeah but iam still confused
<ghostcube> :D
<ghostcube> apw: i cant exact tell you when it happpens
<ghostcube> thats my problem iam watching it but cant get into the problem
<apw> ghostcube, but it is you that applies the updates, so you know if you did or not between each reboot
<ghostcube> is it needed to install complete new files or is an update enough ?
<smb> bencer, For the ppa build it would recreate those again and actually build a server flavour too
<apw> by tracking that you can work out if its related to the update
<ghostcube> so this would be the same if i update an package already installed ?
<smb> bencer, If you really want to force it to use server for both, you'd copy config.server to config.generic in the arch dir
<ghostcube> or only a complete new one
<apw> any package install which includes updates to packages
<ghostcube> ok i will check this today
<ghostcube> and this week long
<ghostcube> after the week i tell you again 
<ghostcube> havent got the time to last week
<ghostcube> i have daily updates from an ppa so it should work 
<ghostcube> :)
<smb> bencer, Oh, actually sorry I missed that. Yeah, you would use the two to get that config for a custom flaour
<bencer> ok :)
<bencer> thanks dude, trying to build now with checks off on binary-custom.d/flavour/rules
 * smb wonders... abi checks were done on custom flavours...
<apw> one presumes its failing on the main flavours cause the source is changed and those are not disabled?
<apw> bencer, are you disabling the main flavour builds?
<bencer> apw: nope
<smb> ah ok
<bencer> but i should, because i don't need them
<smb> yeah, then thats the reason
<apw> so if you are building the main ones and the custom the mains will fail if you don't disable abi there too
<apw> or drop tehm
<smb> usually the way custom binaries were done is to add a patch to modify the main code in there
<apw> then he may be ok 
<smb> yep, but still compile time sucks with having all the other stuff in
<smb> and space as well
<bencer> yes, ~3h
<apw> closer to 4 these days
<bencer> and i don't need lpia builds neither ... i'll try to disable all these stuff once it builds
<lamont> Nov 30 05:56:59 mmjgroup kernel: [218942.819621] IPv6: sending pkt_too_big to self <-- something to do with karmic on the same v6 network, or a recent hardy kernel update... why does hardy hate on the v6 so much?
<apw> lamont, not something i've heard of, smb?
<lamont> first occurred Nov  1 23:43:57 local (-0800)
<lamont> er, -0700
<smb> not that I could give a good answer to that. beside ipv6 being sort of the bastard child of protocols and hardy sort of old
<lamont> meh.  lying.
<lamont> smb: hardy has just short of 4 years of support.
<lamont> and v6 is like 12 years old.
<lamont> and yeah, definitely the bastard child
<lamont> though everywhere not .us is caring about it more these days
<smb> so rather to do with karmic on same network, I would be guessing, that they might have increased some packet sizes. I know, not that we forsee all the interactions
 * soren still doesn't care, fwiw :)
<apw> i am constantly amazed we've not been forced over to v6
<lamont> (nov 1 is as far back as syslog goes atm, even though there are older names - those are from june... go me)
<smb> Hm, that would speak against Karmic
<lamont> apw: .us doesn't care about v6 for the same reasons that the rest of the world cares - 80% or so of the routable v4 IP space belongs to .us (wag statistics for the win)
<apw> heh a good chunk to ibm and mit
<smb> and from the efforts they put into making internet more "controllable" it does not seem they really spend much time on ipv6
<lamont> mine is a small chunk.  tiny, even.
<lamont> hrm... not quite lying - backups tell me that the messages began sometime between 01:14 and 23:43 on nov 1
<lamont> smb: the funny part is the 'to self' in that message...
<smb> lamont, yeah, sounds like something passing on to an internal if... ok, lets look what prints that
<lamont> apw: I know of one company that owns an effective /7
<apw>  /7 wow
<lamont> apw: well.. historical class A, then they merged with another class-A owner, and well...
<lamont> but the blocks don't aggregate
<apw> still an allocation of epic proportions in this day and age
<apw> ibm has 9.x and uses one class C out of it for external addresses
<lamont> hp has expanded beyond the /16 they used to use from their class A
<lamont> hrm... given what I was doing then.... um, NFC what changed on nov 1.  highly unlikely that I would have done a remote kernel upgrade
<apw> are they spamming the logs or sparse these new messages?
<smb> lamont, Hm, so the likely way to get there is trying to xmit a packet bigger than the mtu and the text seems to want to tell you that it also sends a pkt_too_big message to itself...
<lamont> 4-6 per day
<smb> actually the message level is debug...
<lamont> this AM: x6 @05:56:59, *4 at 05:57:00
<lamont> yesterday, *10 @04:44:25-26
<lamont> and 27Nov: *10 at 20:28:44-45
<lamont> it seems to like that 10-tap
<lamont> Nov 30 05:56:59 mmjgroup kernel: [218942.819600] printk: 8 messages suppressed.
<lamont> or maybe "more than 10-tap"
<smb> It might also happen for packets that are not allowed to be fragmented...
<apw> yeah 10 at a time is interestng, the text of the message implies we are telling ourselves off as we send
<smb> The whole good case is "if ((skb->len <= mtu) || ipfragok || skb_is_gso(skb))" (no idea what gso is)
<smb> apw, yep, so whatever is trying this should notice and back of in theory
<lamont> so... consistent bit (across my sampled size of ... 2): postfix with a slew of v6 outbound traffic on the box in question
<lamont> maybe pmtu discovery?
<lamont> though "to self" kinda speaks against that
<smb> might be a logical explanation
<lamont> there is a tunnel involved, so MTU is shortened
<smb> well, trying something huge, gets told off
<smb> then trying smaller, told off again
<smb> ...
<smb> until fits
<lamont> heh.  how much smaller,I wonder?
<lamont> mtu on the tunnel (which does not exist on the machine that's bitching) is 1480
<lamont> it could also be once-each for the smtp daemons, too
<apw> the message definatly implies local tried to send a packet that won't fit in the mtu if the channel and is not fragmentable, a real response is sent to itself ... so an error should be generated
<apw> there is also a stat generated so we should be able to see the real counts
<smb> It compares against mtu... That would need something bigger than that and then it makes no sense again to try bigger on the same machine...
<apw>         IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_FRAGFAILS);
<lamont> where does that show up in /proc?
<apw> possibly in /sys/class/net/<device>
<smb> maybe /proc as well if one would find the tree in the forest 
<lamont> {t,r}x_{packets,bytes} are the only non-zero things in /sys/class/net/*/statistics/*
<lamont>  /proc/sys/net/ipv6/ip6frag_secret_interval:600
<lamont> ^^ sure doesn't look all that secret...
<apw> lamont, :) heh no
<apw> lets hope the interval is not the secret
<lamont> heh
<smb> not anymore
<lamont> every box I look at, == 600
<lamont> so it must be the interval for regenerating the secret
<apw> heres hoping .. else kees will be hopping up and down
<lamont> 14%, 12%, 13%... maybe cloning hardy, karmic, _and_ lucid kernels at the same time was not-so-smart
<apw> lamont, do you have a master linus tree?  if you get one of those and git clone --reference linus ubuntu-foo
<apw> you will download _much_ less
<lamont> oh!
<apw> they can share the objects in common that way ... but do not delete the linus tree :)
<lamont> right
 * lamont freshens his linus tree
<lamont> would referencing ubuntu-jaunty speed up ubuntu-karmic?
<lamont> (curious only - I plan to nuke -jaunty, so not gonna actually do it)
<smb> better never reference anything other than Linus
<lamont> smb: point.
<smb> thats the only tree only going forward
<lamont> afk for a few while the kernel fetches
<smb> (or better is never rebased)
<akheron> smb: hey, thanks for the kernel building help
<akheron> I was able to bisect the problem
<akheron> and this is the result: http://bugzilla.kernel.org/show_bug.cgi?id=14700
<ubot3> bugzilla.kernel.org bug 14700 in Power-Processor "Broken system because of a bad ACPI commit" [Normal,New] 
<smb> akheron, Ah, you're welcome. And upstream already knows of that too. Perfect. :)
<apw> akheron, so which patch did i you add to confirm the fix,  just the last one?
<akheron> apw: originally I just reverted the commit mentioned in the bug report
<smb> hm, that looks strikingly like something I've seen before
<akheron> I'll try the patch in bugzilla later today
<smb> have you ever tried a ubuntu 2.6.31-16 kernel?
<akheron> no
<smb> let me quickly check
<apw> smb in our stable updates perhaps?
<smb> I got the impression this might be in there...
<akheron> the bisecting took so long that I think it was -14 with which I found out that my machine doesn't boot
<smb> yep, seems like its there
<smb> akheron, https://launchpad.net/~stefan-bader-canonical/+archive/karmic
<smb> try that kernel
<smb> akheron, Do you have a lp bug open as well?
<akheron> yes
<akheron> https://bugs.launchpad.net/linux/+bug/481765
<ubot3> Malone bug 481765 in linux "ACPI: After an upgrade to Karmic, the system hangs on boot" [Unknown,Confirmed] 
<apw> smb, excellent we can tie the tat to the stable update
<smb> yup
<akheron> smb: I'll try -16
<smb> apw, but let akheron confirm that kernel does help him
<smb> akheron, thanks
<akheron> but I don't have the machine in my hands right now
<apw> smb, indeed so
<akheron> which commit in ubuntu-karmic fixes this?
<akheron> or you think fixes it
<smb> ACPI: fix Compaq Evo N800c (Pentium 4m) boot hang regression
<akheron> cannot find that one, has it been pushed out?
<smb> Its in the git repo on the master branch
<akheron> i'm using git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git
<akheron> still cannot find it
<smb> Hm, its in mine and it claims to be in sync with the remote one
<smb> apw, You find it?
<apw> commit 24b73c5eac1aa8cdee7271dcba9d2fb7fea488be
<apw> yep
<apw> don't search with the (...) bit of the title though
<smb> akheron, are you still on a checkout of your bisect?
<apw> else less doesn't find it
<apw> git log origin/mater
<apw> master
<smb> ah right
<akheron> ok I found it
<akheron> it's already there in -14.46
<akheron> my cpu family      : 6
<akheron> so that fix shouldn't help with my problem
<smb> akheron, what model?
<apw> apw@dm$ git describe --contains 24b73c5eac1aa8cdee7271dcba9d2fb7fea488be
<apw> Ubuntu-2.6.31-14.46~18
<akheron> cpu family      : 6
<akheron> model           : 14
<akheron> the whole cpuinfo is attached in http://bugzilla.kernel.org/show_bug.cgi?id=14700
<ubot3> bugzilla.kernel.org bug 14700 in Power-Processor "Broken system because of a bad ACPI commit" [Normal,New] 
<smb> the patch seems to change behaviour for family = 6 and lowers the limit from 14 to 0f
<smb> for model
<smb> hm...
<akheron> yes
<akheron> and I guess it should change from 6/15 and upwards
<akheron> err
<smb> ok, it would be the same in your case. probably even if you 14 is dec and those numbers are hex
<akheron> it changes the behavior for 16/* and 6/14 and upwards
<akheron> urgh, now I'll have to fly
<apw> smb, ok the patch you point to is _not_ the one in the upstream bug
<apw> its yet a further refinement
<lamont> heh.  my linus tree was ancient... now at 27%
<akheron> are we talking about a different patch?
<akheron> :)
<akheron> I'll test -16 and the proposed fix in kernel bug 14700 later
<ubot3> Malone bug 14700 in vnc "xvncviewer -listen X Error" [Medium,Fix released] https://launchpad.net/bugs/14700
<akheron> see ya
<apw> smb http://bugzilla.kernel.org/attachment.cgi?id=23973
<smb> apw, I looked at http://bugzilla.kernel.org/show_bug.cgi?id=14700
<ubot3> bugzilla.kernel.org bug 14700 in Power-Processor "Broken system because of a bad ACPI commit" [Normal,New] 
<apw> yep, but the last patch therre he tested is not in our tree even in origin/master
<apw> +	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
<apw> the patch you pointed out changes the first 0xf
<apw> the last one in the bug, the attachment i pointed out 
<apw> changes the second 0xf
<smb> right i see
<smb> but actually then, the patch we have could have more impact
<smb> hm no
<apw> different impact
<smb> well actually in both cases it seems to be the same
<apw> the second looks like a refinement on the first
 * apw doesn't see that
<apw> the patch we have:
<apw> -           (c->x86 > 0x6 || (c->x86 == 6 && c->x86_model >= 14)))
<apw> +           (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 14)))
<apw> the tested patch:
<apw> -	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 14)))
<apw> +	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
<smb> with the version as it was before the one we have, it would go into the if as model >= 14 and x86 = 6
<apw> he is testing with the first patch, and with both
<smb> its always the second part of the || that applies, isn't it
<apw> and there we move from >=14 which he has to >=16 which he does not
<apw> <akheron> model           : 14
<smb> oh, heck
<smb> moving from dec to hex in that patch
<smb> so yes
<smb> somehow my brain made both into hex
<apw> heh
<smoser> apw, jjohansen or anyone ... according to man kernel-img.conf do_initrd only disables a warning that the ramdisk is being created.
<smoser> is there a way to say "do not create ramdisk"  in /etc/kernel-img.conf ?
<apw> smoser, i don't think i am aware of it
<apw> as in i don't think i know
<smoser> reading the postinst, it doesn't look like it. seems like the kernel package itself defines that:
<smoser> y $initrd            = "YES";        # initrd kernel
<smoser> thanks though.
<apw> i'd not be supprised if we don't have support for no initramfs, as its needed for so much of our boot stuff
<bryce> sconklin, we're discussing -nouveau/kms on #ubuntu-x if you're interested
<sconklin> bryce: thanks, joining
<dtchen> bjf: I've been CCing you on these conversations; let me know if you'd like me to stop
#ubuntu-kernel 2009-12-01
<bjf> dtchen, I've only seen one (just received about 30 minutes ago) , have there been more?
<dtchen> bjf: prior to UDS, I think
<bjf> dtchen, will seach my email box, feel free to CC me on anything you feel relevant
<dtchen> bjf: thanks
 * bjf will be back on later...
<bjf-afk> dtchen, just went through my email again, I have today's CC and "Reporting for duty!", were there others?
<dtchen> bjf-afk: I think that's all
<dtchen> also, I wasn't able to follow the codec session during UDS-L, but snd-hda-intel does accept a codec "patch"
<dtchen> parm:           patch:Patch file for Intel HD audio interface. (array of charp)
<dtchen> so, between passing a patch via /lib/firmware{,/$(uname -r)} and hda-verb, hw enablement shouldn't be a blocker
<bjf-afk> dtchen, sounds good, I'll go back and review those emails, between UDS and out all last week I don't remember much
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
<bjf> ##
<akheron> is there a way to re-create mainline kernel builds?
<akheron> I can't find source packages for them, so I don't know where to get debian/
<phferrel> Noticed an IGMP v3 report issue on several machines running 9.04/avahi-daemon 0.6.23 and one machine running 9.10/avahi-daemon 0.6.25.  Affected PCs are transmitting two IGMP joins for the same group (224.0.0.251).  One packet is destined to the correct MAC/IP (0100.5e00.0016 / 224.0.0.22) and the other is incorrect (0100.5e00.00fb / 224.0.0.22).  Is there a bug open on this issue?
<Keybuk> apw: looks like your kernel works for me too
<Keybuk> # readlink /sys/class/graphics/fb0/device/driver
<Keybuk> ../../../bus/platform/drivers/vga16fb
<apw> Keybuk, cool.  i'll clean it up, and maybe make it optional, and get it into lucid
<apw> Keybuk, i assume thats all you needed from the kernel to get your 'non-wait fbcon' boot speedup ?
<Keybuk> no, still need whatever it is that moblin are patching i915 to make that come up faster
<Keybuk> the vga16fb stuff was for plymouth on non-kms
<apw> Keybuk, yeah the speed stuff is separate
<apw> i mean thats all you needed so you didn't need 'wait 5s and then assume there isn't one' mode for non-kms
<Keybuk> no, still need that
<apw> tseliot and sconklin are looking at the performance patches, they seem good patches performance wise, crap attribution etc wise
 * apw tries again
<Keybuk> still need to force a wait for a framebuffer in the initramfs
<Keybuk> because the next initramfs script starts plymouth
<apw> but this change is enough to mean you can always wait for one and it'll always appear?
<Keybuk> eys
<Keybuk> means the wait won't be that long
<Keybuk> we know we'll always have a framebuffer
<apw> good stuff.  i am watching the other patches, there seem to be several seconds overall for the stack tseliot has ... just need intel to admit they are their patches
<Keybuk> yeah
<uukev> hi, Is the file "linux_2.6.31.orig.tar.gz" here: https://launchpad.net/ubuntu/+source/linux/2.6.31-15.50 the source of my karmic kernel or are there any patchs applied to this?
<ukev> How can I find out if a kernel patch is in the ubuntu kernel?
<dtchen> ukev: the source is retrievable in a number of ways. If you have a corresponding deb-src line, apt-get source linux-image-$(uname -r). You could also dget https://edge.launchpad.net/ubuntu/+archive/primary/+files/linux_2.6.31-15.50.dsc . Patches are applied; see the diff.gz for raw and https://wiki.ubuntu.com/KernelTeam/UbuntuDelta/Karmic for an overview of the delta. Finally, the source is browseable at http://kernel.ub
#ubuntu-kernel 2009-12-02
<Cytotoxic> !OPS
<Cytotoxic> !ops
<Cytotoxic> !ops
<Cytotoxic> !ops
<Meow234> !ops
<Meow234> !help
<Meow234> !ops
<dtchen> seriously, your hostmask gives you away entirely.
<Meow234> i was adapting
<Meow234> magic of lymphocytes
<yodgo> i adapted
<yodgo> !ops
<dtchen> RAOF: FWIW, I'd favour a linux-backport-modules-nouveau approach
<dtchen> backports*
<RAOF> dtchen: What benefits does that have?
<dtchen> RAOF: you leave the existing stack alone
<dtchen> people opt in for any possible regressions
<maco> just like l-b-m-alsa
<RAOF> Is this the benefits over "nouveau-kernel-source" or over trying to backport nouveau to our existing drm?
<dtchen> the latter
<RAOF> Right.  I don't think that backporting nouveau to our drm is a great idea, either, although I haven't looked closely at precisely what it would require.
<StevenK> RAOF: Nouveau also requires it's own DRM stack?
<maco> StevenK: i think its more to do with the backporting part...
<RAOF> StevenK: No, but it requires a _newer_ drm stack than we've got.
<maco> old drm + new nouveau
<RAOF> drm-next is regularly merged into the nouveau tree; that's not going to be in Lucid's kernel.
<RAOF> (Or, rather, it's not going to be in 2.6.32, and we're not going to have 2.6.33)
<dtchen> yeah, that makes some of my powerdown work rather interesting
<StevenK> RAOF: Right, a newer DRM stack is okay, but it does mean some interesting integration work
<RAOF> The actual drm-next patch against our kernel is 2.9MB; that's been thrown out as a non-option.
<yodgo> How sexy is my ride?
<yodgo> http://www.youtube.com/watch?v=uEO2eRw4y5Y
<RAOF> That includes all the work in the intel driver and ati driver, and apparently the ati driver will want _some_ of it for Lucid, too, so it might be possible to have a substantially smaller patch.
<yodgo> How sexy is my F40PH?
<yodgo> http://www.youtube.com/watch?v=uEO2eRw4y5Y
<MBCR> !ops
<RAOF> Again?
<MBCR> fuck ubuntu
<apw> Keybuk, what was the magic to get the initcalls stuff into a piccy?
<apw> smb, rtg, Keybuk, http://people.canonical.com/~apw/boot-speed/
<apw> comparisons with the initial initramfs parallel thingy
<apw> csurbhi1, ^^
<csurbhi1> populate_rootfs is not parallel here
<smb> look below
<apw> those are _two_ graphs without and with your patch
<apw> saves about .4s by the looks of it
<smb> looks so for me as well
<rtg> apw, makes my neck hurt
<smb> or rather .40s ?
<apw> heh :)
<smb> which is the same
<apw> heh yea
<smb> but looks more impressive
<rtg> smb, how about .40000s ?
<apw> wow thats a lot
<smb> even more impressive :-D
<smb> apw, your second graph seems to start later without any action...
<smb> Oh, they probably both start at .18 but the second graph's axis starts at .15...
<apw> smb, i don't see that, they are labedlled in differnt things
<smb> apw, funny, now that I made the window longer I see the 0.08 starting points...
<apw> they are very big images
<smb> apw, definitely. /me is jojoing up and down
<apw> its acutally looks more like .3 of a second actually
<smb> might be. hard to say without a number at the end (after)
<apw> still not to be sneezed at
<apw> 2% of the total to be found for the whole boot to go from 25->10s
<smb> Surely agreed. 
<smb> Not too much left to be optimized by parallelizing. piix_init might give a fract but might be required to be where it is. Can't read the scribbely small things before
<smb> Though it might depend on isapnp in some cases...
<apw> csurbhi, rtg, smb, ok updated charts with a third graph ...
<apw> http://people.canonical.com/~apw/boot-speed/
<apw> the third one is just parallelising the initramfs start
<apw> about identicle to the second one in overall time
<apw> we may save .3 of a second turning of ISA ... its a lot of cost considering almost noone has it!
<smb> apw, Thats good. So even with the more minimal change the same gain is done
<rtg> apw, are you booting this on a quad-core ?
<apw> rtg nope this is on the reference dell 10v with SSD
<csurbhi> basically moving the rootfs call before does not gain so much 
<csurbhi> ?
<csurbhi> right 
<apw> ie a challenged machine
<smb> apw, I recently read somewhere that they start to have sort of ISA buses for certain internal functions...
<apw> csurbhi, knowing we can move it earlier for the same cost is good to know
<apw> right now its not helping any bug if isa pnp was quicker it might be useful... now we know
<apw> and we know its not _slower_ overlapping the earlier boot too which we didn't before
<apw> DOH
<apw> ^^ to smb's comment
<smb> apw, Heh, yeah. More guessing at that part but it might be an alternative compared to i2c things...
<mjg59> You need ISA
<apw> mjg59, for?
<mjg59> What the kernel calls CONFIG_ISA is actually support for non-PCI onboard devices
<mjg59> And also PCMCIA
<mjg59> You might be able to lose ISAPNP, which is what would probably take time
<mjg59> PCMCIA has its own enumeration, and onboard devices will be in PNPBIOS or ACPIPNP tables
<mjg59> So you'd lose support for autoloading modules for ISAPNP network cards and sound cards, but I don't think that works anyway
<apw> i was just wondering about changing the default for enable noisapnp
<apw> if its going to cost me .4s during boot!
<smb> apw, question would be if anything later really depends on that
<apw> yeah well my dell boots without :)
<mjg59> You'd want to check with Scott, but I don't think isapnp modaliases work with udev module loading
<apw> yeah i doubt its a viable option, but booting with it turned off saves .3s
<apw> just as a kernel option off
<apw> its very expensive
<dandel> hmm further testing on bug 484943 reveals that it's  fixed in latest git, at least on kernel 2.6.32-rc8.
<smb> apw, Though if that could be done async and nothing really waits on it early you still could safe
<apw> yep ... testing the effects of asyncing that thing now
<apw> moblin never needed to fix it cause they turn it off i suspect
<apw> Keybuk, i think i foudn the rest of the time moblin saves... no isa and no initramfs -> .8 of a second total start time
<akheron> smb, apw: I was finally able to test the upstream patch in http://bugzilla.kernel.org/show_bug.cgi?id=14700 and it seems to work
<akheron> my wife gave birth to my second son yesterday morning, so I got delayed a bit :)
<smb> akheron, heh, congrats. Thanks for the testing. I would think this now will go upstream+stable and then back. But it probably takes a bit
<jjohansen> akheron: congrats
<akheron> thanks
<akheron> it doesn't matter for me if it takes a bit
<akheron> at least I have a bootable system now, using my own patched 2.6.31-15
<akheron> as long as lucid works when I eventually upgrade :)
<smb> Yeah, there should be enough time for that :)
<apw> Keybuk, about ?
<ukev> hi
<ukev> how can I check if this patch is integrated into ubuntu? http://patchwork.kernel.org/patch/60322/
#ubuntu-kernel 2009-12-03
<dtchen> jk-: after reading Grant's LWN article, I thought I'd mention (in its comments) that you should check out the patch format expected by snd-hda-intel if you don't already know of it.
<whatchasay> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<whatchasay> k-line me
<Kano> hi apw , 2.6.32 final is out, when will it be rebased?
 * apw notes that he has a robot which tells him when its out
<apw> rebase is planned for today, likely tested and availble tomorrow
<Kano> i only need git
<Kano> hi tormod 
<tormod> hi
<Kano> do you have got a gt220 to test?
<Kano> just thinking of a kernel patch
<Kano> i just dont know if it is a 2ch or 8ch device
<Kano> for the hdmi port
<tormod> I even don't know what a gt220 is :)
<Kano> nvidia
<tormod> oh I have close to zero experience with nvidia
<tormod> they are a bad OSS player
<Kano> well i only have got ssh access to it, but after rebase of .32 i will compile a kernel with experimental support
<Kano> 2ch i try first...
<tormod> I have one lab computer with it, running happily with nv and I don't touch it
<Kano> only the dx10.1 cards have got integrated hdmi soundcard just like ati
<Kano> there is a simple patch in one board, but not against .32 as there you have to select 2ch or 8ch
<Kano> http://www.vdrportal.de/board/thread.php?postid=853558
<Kano> the rest is the same
<Kano> well will take break and hope then the git is up2date ;)
<Kano> bbl
<abhinav> how do I find out if a particular commit in the kernel has made it into the one being used in karmic ? I am interested in knowing whether this is solved in my current karmic installation : http://lkml.org/lkml/2009/5/3/141
<rtg> abhinav, git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git ?
<abhinav> rtg: do I just copy paste the above in a browser ? 
<rtg> abhinav, for that use http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=summary
<apw> jjohansen, any changes to -ec2 pending, am about to rebase it
<jjohansen> apw: nope
<apw> good stuff
<jjohansen> with .32 going final I expect there will be some updates with in the next week or so
<apw> i am just abuot to rebase it to there, and we'll seee if it builds
<tormod> apw: [drm] radeon defaulting to kernel modesetting.
<apw> tormod, ?
<tormod> when did this happen? I think a post to ubuntu-x would have been appropriate? Or mention in changelog?
<tormod> apw, you know that our user-space does not support it yet?
<apw> i was told the opposite
<tormod> hmm
<apw> at the UDS session which discussed it
<tormod> there are a few quirks, see https://wiki.ubuntu.com/X/RadeonKMS
<apw> thats not helpful ... can you confirm its not going to work, as i am about to upload and can turn it back off
<tormod> I guess whoever told you at UDS, meant "should be generally supported"
<apw> that page doens't say its not supported in userspace, it just says to use a lucid kernel to enable it
<tormod> what happens now is that X start, causes loading of radeon, but checks for KMS support before it is there
<tormod> read on
<tormod> so X goes on to think there is no KMS and does its own modesetting as well...
<apw> hrm, what a mess.  
<tormod> should not be a big problem to fix it, but now with KMS on by default it will become so much more urgent
<apw> so do i leave it enabled to encourage you x-types to fix it :)  or do i turn it off again
<tormod> upstream/fedora admitted they gave up to make it switchable by user
<tormod> you see my upstream hack on that wiki page, we could do something like that for now
 * apw is unimpressed.  i was getting messages that radeon kms was  ready
<apw> i am uploading a rebase kernel shortly which will be whats in alpha1 most likely
<tormod> the radeon part yes, lucid no
<apw> so i need a decision on whether its on or off for alpha-1 i guess
<tormod> how much time do we have on that decision?
<apw> i was planning the upload in a couple of hours, but i can hold it a while
<apw> but we're unlikely to get another upload in after that before alpha-1 
<tormod> I have been forcing KMS on manually for so long, so I missed the change in kernel configuration
<tormod> which, again, was not mentioned in the changelog AFAICS
<tormod> apw, I wonder how this works so effortlessly with intel, any clue?
<apw> intel put a lot of effort into it?
<apw>   * Revert "SAUCE: default ATI Radeon KMS to off until userspace catches up"
<apw> that was the first changelog entry on 2.632-6.7
<apw> ok the freeze is tuesady ... the kernel takes about 2 days to get into the archive, so i need to get it up tommorrow at the very latest to hit the deadline
<tormod> apw, wow that was 2.6.31-2.15 so long back I did not even look
<apw> ?  no we defautled it off back then
<apw> i undid the off so it defaults to the default of on, for the previous lucid upload
<tormod> apw, oh yes sorry
<tormod> apw, and the un-SAUCE did not get mentioned
<apw> ?
<apw> whats an un-sacue
<tormod> that revert, I don't see it
<apw> i cut that from the published changelog
<apw> https://edge.launchpad.net/ubuntu/+source/linux/2.6.32-6.7
<apw> but yes, i should have put more info in the annoucenment
<apw> i thoought bryce was aware and ready for it
<tormod> I am reading /usr/share/doc/linux-image-2.6.32-5-generic/changelog.Debian.gz
<apw> thats -5 ?
 * tormod hides
<tormod> so I understand it just happened
<tjaalton> tormod: what exactly are we missing from userspace?
<apw> yep, we had a UDS discussion on it and it was an action on the kernel team to turn it on
<tormod> something that makes sure kms is initialized before starting X
<apw> so i turned it on :)
<tormod> apw, ok good boy :)
<apw> seems that the action should have been 'wait for userspace to be ready, and turn it on'
<tjaalton> so we just need to fix it before tuesday? :)
<tjaalton> userspace that is
<tormod> tjaalton, yes, and make sure we know we can fix it by then, today
<apw> you need to decide if you can fix it by tuesday, by tommorrow am
<tjaalton> ah, right
<tjaalton> ok
<tjaalton> plenty of time
<tormod> yes I would say it should not be a problem
<apw> the sooner the better, as if i have to respin all the kernels i've just done, i have a days work to do
<apw> and its has to be done by tommorrow end
<tjaalton> tormod: so it's the ddx that needs to be taught about kms if it's enabled?
<tjaalton> tormod: maybe we should move this to #ubuntu-x
<tormod> tjaalton, yes the ddx checks the sys tree, but does it too fast
<rtg> apw, I wouldn't hold up everyone else for Radeon KMS issues. I suggest going with what is enabled in user space right now, and we'll get to it after A1.
<apw> so i'll re-disable it then ...
<tormod> rtg, we have known user-space workarounds though
<rtg> apw, Bryce should be online in an hour or so. This is a config issue, so should not affect your rebase against 2.6.32, right? You can consult with him as well.
<apw> rtg the rebase is done and ready for upload, pending this change ... so yep will wait on bryce
<apw> Keybuk, about?
<Keybuk> apw: yes :p
<apw> Keybuk, i have a patch which makes kms init async whcih is one of the boot performance patches that have been suggested
<Keybuk> we have the drm stuff as modules
<Keybuk> does it make much a difference there?
<Keybuk> I would have thought that's the kind of patch that'd only make a difference if you compiled the driver in
<apw> Keybuk, to be honest i have no idea, tseliot claimed so ... but the issue i was seeing with it
<apw> was that the intereaction with the probe of vga16b ...
<apw> i was getting that loading before the fbcon0 and losing kms as a result
<apw> and i hear radeon may already be async
<apw> so just wanted to make you aware
<mjg59> You're seriously falling back to vga16fb?
<Keybuk> mjg59: can you think of a better *fb to fall back to?
<mjg59> Well, if falling back to an fb is a design requirement, vga16fb is the best choice
<Keybuk> apw: yeah, that's the kind of issue I would have expected
<mjg59> There are some machines we never got it working on, though
<Keybuk> as long as the module init claims the device, it's fine
<Keybuk> mjg59: right, it's the best fallback that avoids text mode
<Keybuk> 16 colours is enough for a little B&W ubuntu logo in the middle
<mjg59> Yeah
<Keybuk> and that was enough for me to persuade Mark that we really should kill usplash now
<mjg59> Using Plymouth?
<Keybuk> the "text mode if you don't have KMS" was always the big issue with plymouth
<Keybuk> right
<mjg59> You've taught it to use vga16?
<Keybuk> mjg59: didn't take much teaching
<Keybuk> plymouth already had a frame-buffer backend
<Keybuk> (as well as the DRM one it uses for KMS)
<mjg59> Yeah, it's just a matter of writing the right kind of packed stuff
<mjg59> Unless you want to do scrolling
<mjg59> Adding extra things to bogl's vga16fb backend wasn't fun
<Keybuk> yeah I stole some code form bogl to that
<Keybuk> but tbh, we literally just paint a logo etc.
<Keybuk> so it wasn't hard
<mjg59> Yeah, it shouldn't be too much of a problem
<mjg59> I just wish I knew why it failed on the VIA craptop
<Keybuk> I have it using a special plugin rather than the default, etc.
<Keybuk> apw: so, on the whole ISA thing I missed
<Keybuk> mjg59's memory matches my own
<Keybuk> we use PNPACPI on ACPI-based systems, which have acpi:PNP* module aliases
<Keybuk> and we use PNPBIOS on non-ACPI systems, which *you* patched to have the pnp:PNP* module aliases :p
<Keybuk> so I'm not sure if we even use ISAPNP for anything
<Keybuk> like mjg59 says, no module would get auto-loaded as a result of having it
<Keybuk> do you need it if you force-load a sound card module? 
<mjg59> Yes, if you want automatic resource allocation to work
<Keybuk> will they not use the PNPACPI or PNPBIOS code?
<mjg59> Not if it's an ISAPNP device
<mjg59> Ie, plugged into an ISA slot, not just an on-board ISA device
<Keybuk> right
<Keybuk> old sound blaster stuff
<mjg59> Yeah
<mjg59> Which, well
<Keybuk> would there be a problem with doing isapnp_init as an async thing?
<mjg59> I was going to say "You'd need to do it before any ISA drivers tried to allocate resources", then realised that those drivers won't bind unless (a) isapnp_init has run, or (b) the user has supplied module options, in which case you don't need the pnp code
<Keybuk> so the question there would be, would the module load fail?
<Keybuk> or would the module load, and leave the driver unbound
 * Keybuk suspects the former
<mjg59> What would trigger the module load?
<mjg59> Are you ever going to load a module before the async calls have finished?
<Keybuk> one assumes /etc/modules
<Keybuk> so no
<Keybuk> the only issue would be if someone compiles in a driver
<Keybuk> and if they're doing that, they'll probably fail to base it off the ubuntu kernel source anyway
<mjg59> If it's compiled in, it won't be bound until isapnp discovery is complete
<mjg59> Because otherwise it's got no way of knowing that there's hardware for it to bind to
<Keybuk> good point
<Keybuk> so there shouldn't be any risk then
<mjg59> Right
<apw> i cna say i tried to make the call async and got a big fat hang
<apw> Keybuk, ^^
<Keybuk> what was the hang?
<apw> didn't investigate yet, it was a hard hang under usplash
<Keybuk> huh
<Keybuk> that's odd
<Keybuk> usplash doesn't tend to run until after the kernel
<apw> Keybuk, yeah that doesn't make sense now does it
<apw> i'll need to redo that test 
<Keybuk> are you sure you didn't just trip into one of our other bugs that happens from time to time? :p
<apw> no not at all sure
<Keybuk> like the gdm-not-starting one? :p
<apw> Keybuk, heh perhaps
<apw> Keybuk, i will go for a repeat test
 * BenC1 is unimpressed that so many pata/sata drivers are built in to the kernel now
<BenC1> especially considering I am getting conflicts between two drivers that I cannot resolve because I cannot blacklist/unload a module
<rtg> BenC1, you've been sacrificed on the alter of boot speed.
<BenC1> rtg: libata+ahci is good for boot speed
<BenC1> rtg: pata-acpi built-in is not :-/
<BenC1> in fact, pata-acpi is a failsafe, why it's built-in is not even clear to me
<rtg> could be it just got peanut buttered into the general effort to improve boot performance by building inn boot essential devices.
<BenC> rtg: there's like bcollins@maclara:rce/stuff/ubuntu-karmic$ grep 'CONFIG_SATA_.*=y' /boot/config-2.6.31-15-generic  | wc -l
<BenC> 12
<BenC> bcollins@maclara:rce/stuff/ubuntu-karmic$ grep 'CONFIG_SATA_.*=m' /boot/config-2.6.31-15-generic  | wc -l
<BenC> 3
<BenC> rtg: I mean really, why not just build them all in at that point?
<rtg> BenCis nVidia one of them? I think it  was a problem driver
<BenC> rtg: nv is built-in, but I am not running that
<rtg> nope, VIA, MV, and SVW
<BenC> rtg: my problem is I have a promise card that pata-acpi is stepping all over
<rtg> BenC: send a patch, maybe Stefan will SRU it.
<BenC> $ grep 'CONFIG_PATA_.*=y' /boot/config-2.6.31-15-generic | wc -l
<BenC> 33
<BenC> that one just scares me
<BenC> rtg: well, I haven't even verified that removing pata-acpi will fix it, but finding out will take a kernel recompile
<rtg> BenC: I assume you remember how :)
<johanbr> Do the mainline kernel builds have as much stuff built-in?
<BenC> lol
<rtg> johanbr, likely, though I haven't looked too close. I'm pretty sure Andy started with an Ubuntu config to build the mainstream kernel.
<smb> Yeah he does
<smb> Base is the current ubuntu config + anything new used with default values
<BenC> rtg: I really hope you guys revisit this idea...I was pretty sure when we discussed this initially that the idea was to only include actual hardware drivers that would benefit the large majority of users
<BenC> tossing in random things doesn't seem helpful at all
<smb> BenC, help us to remember with mails to the list. Its less volatile than irc
<BenC> smb: this was all discussed at UDS/jaunty, IIRC
<rtg> BenC: I got no problem with that. Its likely I didn't understand the ramifications of building in the PATA stuff.
<smb> Me neither. It just better to have somewhere a written down explanation to ourselves as we tend to forget things
<BenC> smb, rtg: Filed a general bug on the subject of built-in storage drivers
<BenC> Bug #492078
<ubot3> Malone bug 492078 in linux "Building in random drivers hurts the majority" [Undecided,New] https://launchpad.net/bugs/492078
<rtg> BenC ack
<smb> ok, ta
<dyek> Hi! I want to run Ubuntu 9.10 as Xen guest on top of Fedora 12's Xen VM (considering 64-bit Xen host or alternatively 32-bit). Does anybody know if standard Ubuntu desktop kernel support Xen guest? If not, is it easy to accomplish what I want?
<rwt> hello
<jjohansen> dyek: it should run fine as a pvops guest
<dyek> jjohansen: Thanks! It sounded like I can just use Cento5's Dom0 (recent Fedora release is still missing Dom0 support) and run Ubuntu desktop as one Xen guest. I'll try it out. 
<jjohansen> dyek: yeah it should work, I have booted as a guest under Centos5
<dyek> Cool! Thanks!
#ubuntu-kernel 2009-12-04
<RAOF> Is anyone here more aware what's happening wrt nouveau?  I'm looking at updating the DDX for Lucid at the moment, but it's untestable without the kernel modules.  Should I upload an update nouveau-kernel-source as an interim measure?  The current package FTBFS against 2.6.32 kernels.
<dtchen> holy cow, I hate ad1988. That is all.
<maco> haha
<maco> dtchen: wait....the year?
<dtchen> no, the HDA codec with a (seeming) billion different versions
<maco> ok just checking...that was what i thought at first but then i re-tried the parsing
<jk-> dtchen: thanks for the pointer earlier
<dtchen> jk-: yw
<tseliot> apw, sconklin: I've just sent you an email with the details on the origin of the patches that I recommended for fast boot
<tseliot> origins
<tseliot> heh, I sent the email to myself too
<pgraner> amitk: I see you've been busy on LKML :-0
<amitk> pgraner: it took one last late-nighter to get them out the door. Should be easier now...
<Keybuk> apw: I did just notice something odd
<Keybuk> lrwxrwxrwx 1 root root 0 2009-12-04 09:41 fb0 -> ../../devices/pci0000:00/0000:00:02.0/graphics/fb0/
<Keybuk> lrwxrwxrwx 1 root root 0 2009-12-04 09:41 fb1 -> ../../devices/platform/vga16fb.0/graphics/fb1/
<apw> Keybuk, not expecting to see that?
<Keybuk> no, I would have thought it would have gone "oh, no device"
<Keybuk> if you write to that framebuffer, where does it go? :p
<apw> yeah oddness
<MTecknology> oh - also develop a tool to audit the logs
<apw> jk about/
<apw> ?
<lamont> how well does a jaunty kernel deal with a hardy userspace?
<pgraner> lamont: ask rtg he's run it
<lamont> rtg?
<rtg> lamont, works OK  in server space except for AppArmor
<lamont> cool
<rtg> lamont, https://edge.launchpad.net/~timg-tpi/+archive/ppa?field.series_filter=hardy
<lamont> does it need a backported kernel?
<rtg> lamont, that is, or was, the backported kernel
<lamont> right
 * lamont needs a diff arch, so I guess I get to build that source
<rtg> lamont, lemme guess, powerpc or sparc?
<lamont> ppc
<lamont> the hardy kernel hated on a few machines... 
<rtg> lamont, you might be better off starting with the ports kernel from Jaunty.
<ghostcube> hmm ureadhead keeps crashing here some times
<apw> ghostcube, dropping a core?
<apw> if so get the core onto a bug
<ghostcube> at boot it gets signal 4
<ghostcube> and exit
<ghostcube> must check how to file a bug about this
<scroll> how should i allocate mem for task_struct? 
<mcgrof> how many drivers are known to exist on the delta ?
<mcgrof> any reason they can't go to staging?
<dandel> i'm needing a bit of help figuring out what else to check against on bug 484943. (checked against latest git revision of kernel,)
<ubot3> Malone bug 484943 in linux "resume crashes with ext3 error with wubi based install" [Undecided,New] https://launchpad.net/bugs/484943
<dandel> interestly enough, it's not an ext3 only bug... it even effects ext4 installs on the same machine.
<apw> mcgrof, about 10, mostly they are the sorts of things that staging rejected
<apw> for instance aufs which is too big for them to cope with, and not the 'approved' way to do union mount
<apw> though the approved way does not yet exist, and likely won't for 3 more releases
<mcgrof> apw: is there any link to the discussion for aufs rejection for staging ?
<mcgrof> apw: this would be the first time I hear of a driver being rejected for staging
<apw> the inital load of drivers in staging were hoovered up from ubuntu
<apw> and htat one was not taken.  normally things in staging have to have a chance of getting into the kernel
<apw> aufs does not as it stands, the objections are too great
<dandel> apw, bug 484943 is involed with bug 338701 (same machine)
<ubot3> Malone bug 484943 in linux "resume crashes with ext3 error with wubi based install" [Undecided,New] https://launchpad.net/bugs/484943
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Medium,In progress] https://launchpad.net/bugs/338701
<jjohansen> mcgrof: basically upstream objects to the whole idea of a union filesystem, the blessed way in union mounts but they have had their own issues and haven't made it up either
#ubuntu-kernel 2009-12-05
<Black_Phantom> hi all how do I install the latest linux kernel using apt ?
<mattsh> hey all
<mattsh> what is a good environment to test a kernel module during development?
<Wellark> morning!
<Wellark> any change getting this applied to next karmic kernel update: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dcfcb256cc23c4436691b0fe677275306699d6a1
<Wellark> I have a Nokia Booklet and I'm running karmic on it and without the patch the booklet soft-lockups every time I insert a SIM card
<Wellark> I'm the author of the patch, btw
<alex_joni> Wellark: best thing to do is file a bug at LP
<Wellark> alex_joni: thanks! I'll do that on monday.
#ubuntu-kernel 2009-12-06
<TheGreatToilet> I dont understand why you ops are being mean you ops are big meenies.
<syn-ack> Is it possible to get just the ubnntu patchset from git and which branch would I have to get it from?
<syn-ack> I'm looking to patch against a vanilla .32 sourcetree
<hyperon> Hello, all!
<skande> hi , need the names of the files witch #include <linux/input.h> (linux kernel --> kernel.org) ; thanks :D hi , need the names of the files witch #include <linux/input.h> (linux kernel --> kernel.org) ; thanks :D 
<skande> sorry
<skande> hi , need the names of the files witch #include <linux/input.h> (linux kernel --> kernel.org) ; thanks :D 
#ubuntu-kernel 2010-12-06
<greg_> greetings all
<greg_> anybody home?
<jk-> some are :)
<greg_> hi  - quick question if anyone has a second, if I want to be more informed about future direction of the kernel and maybe even have my thoughts heard about it, where would I look/watch/join? 
<RAOF> greg_: The kernel mailing list would probably be the best place overall, but various subsystems have their own mailing lists.
<RAOF> greg_: Note that the kernel mailing list is unlikely to be receptive to general thoughts not backed up by the possibility of a code submission.  Reviewing specific patches will likely be welcomed, though.
<greg_> thanks RAOF.  When I first installed lucid server and discovered there was no x86 server kernel, but the package was essentially a pointer to the generic-pae kernel, it was suggested that the change was announced via some community mechanism that I now don't remember, shamefully, and no one objected.  I'd like to make sure I don't get that kind of surprise in the future without wading through every mail and patch....  
<greg_> the not remembering is the shameful part
<greg_> :-)
<RAOF> Ah.  You're more interested in the Ubuntu kernel configuration, then.
<RAOF> In that case, kernel-team@lists.ubuntu.com :)
<crimsun> sometimes the info comes across sooner on ubuntu-devel@.
<RAOF> For bigger changes, yeah.
<greg_> ok, thanks very much RAOF and crimsun
<Omega> < trap15> does anyone know the reason that usbfs was removed from the ubuntu kernels?
<crimsun> other than it's deprecated, or at this point, obsolete?
<jk-> RAOF: regarding https://blueprints.launchpad.net/ubuntu/+spec/hardware-desktop-n-xorg-configuration-the-final-ten-percent, where would be the best place to put my device-tree proposal?
<RAOF> jk-: If it's small, in the whiteboard.  If it's big or needs discussion, on the wiki.
<jk-> ROAF, yep, was thinking the wiki is more suitable, somewhere like X/Dev/DeviceTreeDetection ?
<RAOF> I was thinking of linking it to the blueprint.
<jk-> X/Dev/hardware-desktop-n-xorg-configuration-the-final-ten-percent ?
<RAOF> Ah.  I haven't set a URL for that blueprint yet.
<jk-> yep :)
<RAOF> In that case, X/Dev/DeviceTreeDetection sounds like a good name.
 * jk- discovers X/Blueprints
<jk-> apw: ping?
<cking> apw, any sign of manjo today?
<apw> cking, yep he is my left-hand man, wassup
<cking> apw, just wondering if he made it through to London OK - I didn't seem him on IRC today
<jjohansen> ah that explains apw's silence
<cking> indeedy
 * apw is always quiet, i am very very introverted
<cking> cough, splutter,
<cking> what?!
<smb> Rather the most extrovert introvert we met
<cking> if apw is introverted then I'm basically so introverted that one would class me as clinically dead
<didrocks> hey guys
<didrocks> since grub 1.99~2010112, with nvidia proprietary driver, I can't get a working X/gdm
<didrocks> cjwatson pointed me to the framebuffer spec and I saw that gfxpayload=keep is activated
<didrocks> I remember having issues with it in maverick, so it's maybe linked
<didrocks> how can I help getting the relevant info to you?
<lag> apw: Have all the delta patches been deleted now?
<apw> lag ?
<lag> apw: https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyUbuntuDeltaReview
<lag> apw: I can't find my patches for looking
<apw> lag in the wiki page or in the ubuntu delta ?
<lag> I can find the entries on the Wiki
<lag> But they're missing from git log etc
<apw> lag, then perhaps they got dropped, are they in the dropped section below 
 * lag checks
<lag> apw: They don't appear to be
<lag> apw: Maybe they were dropped when ARM support was removed?
<apw> lag hmmm, ok well mark them as missing and i'll try and find out
<lag> Okay
<JFo> <-lunch
<JFo> back
<cking> JFo, dude, how's it going?
<JFo> cking, not too bad despite being overwhelmed by everything :)
<JFo> cking, how about you?
<cking> JFo, ditto :-)
<JFo> heh
<cking> Those bug reports keep in coming it. I understand it can be most overwhelming.
<JFo> I'd be on mumble, but I stupidly forgot to charge my headset over the weekend
<charlie-tca> JFo: We got a bug day tomorrow for you, right?
<JFo> oh yes, the bug reports are never ending
<JFo> charlie-tca, yessir
<JFo> bugs with patches
<charlie-tca> Great!
 * JFo plans to remind folks via e-mail and blog today
<charlie-tca> I can try to do some, at least.
<JFo> excellent! I welcome anyone interested in helping
<JFo> especially if that person is you charlie-tca :)
<charlie-tca> thanks
<cking> bjf, thanks for helping me out with the fwts over the weekend
<bjf> cking, glad to, i'll do some further testing sometime this week i think
<cking> bjf, cool, I'm still unable to trip that lucid bug, but I've not had much change since Saturday to reproduce.
<_Groo_> hi/2 all
<_Groo_> found a very ugly bug with reiserfs + ecryptfs in maverick/natty thats wasnt there in previous kernels
<_Groo_> if my machine crashes via a hardware freeze (damn you nvidia), reiserfs runs its log file, so far so good
<_Groo_> unfortunatelly ecryptfs is not yet mounted or a bug lies at that lvl, and reiserfs is writing the raw data in the ecryptfs inodes, borking all the data
<_Groo_> or something like that for what i could test.
<_Groo_> anyway when reiserfs kicks the log write, the file affected gets borked if you use a eccryptfs layer
<_Groo_> anyone ever seen this behaviour before?
<sconklin> back in a couple of hours
 * tgardner --> lunch
<ppetraki> quick question, is the -server kernel using CFS be default, and how do I find out which scheduler were using at runtime?
<soren> ppetraki: /sys/block/<name of block device>/queue/scheduler
<ppetraki> soren, I got that one, and it's deadline
<ppetraki> soren, now what about processes? it a mess in proc somewhere
<soren> ppetraki: What about processes?
<ppetraki> soren, the config says http://pastebin.com/CQWTBS8q
<ppetraki> soren, which appears to be deadline for process scheduling too
<soren> ppetraki: I'm not sure what you're saying. CONFIG_DEFAULT_DEADLINE=y means the the deadline scheduler is the default i/o scheduler.
<ppetraki> soren, there's one for io and one for process. I'm just trying to verify at runtime which one we're using
<ppetraki> soren, the io one is easy enough as you pointed out
<ppetraki> soren, with the CFS, am I using it? how do I find out. the docs aren't exactly clear
 * soren is not aware that there's much of an option when it comes to process scheduling (other than preempt and HZ settings)
<ppetraki> fair enough
<ppetraki> thanks
<soren> That is not to say that there isn't. I just don't know about it.
<ppetraki> that's what I'm trying to determine
<GrueMaster> Can someone tell me when linux-ti-omap4 2.6.35-903.19 will move from proposed to release?  I busted my butt to get it tested during US holiday, and need it for natty testing.
 * jjohansen -> lunch
<tgardner> GrueMaster, we have no plans to produce a natty ti-omap4 kernel. I thought Linaro was doing it?
<GrueMaster> That is for omap, not omap4 as far as I know.
<GrueMaster> And you guys asked me to test this kernel two weeks ago for Maverick.
<tgardner> hmm, then I'm waiting on Bryan Wu as he is the omap4 dude.
<GrueMaster> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/673504
<ubot2> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (heat: 192)" [High,Fix committed]
<GrueMaster> That has all the info for 2.6.35-903.19
<tgardner> GrueMaster, checking...
<GrueMaster> Until then, natty is currently pulling 2.6.35-903.17
<tgardner> GrueMaster, re: maverick, I think we're waiting on the SRU team to promote it to -updates
<GrueMaster> Well, lets hope it gets released before the next security patch cycle.  I really don't want to keep spinning loops around these bugs because of flawed release processes.
<jjohansen> bjf, sconklin: do the lts-backport kernels get security updates
<sconklin> jjohansen: good question. rtg? ^^
<jjohansen> sconklin: tgardner isn't around currently
<bjf> jjohansen, i believe that they do though we have left the updating of them to rtg
<bjf> jjohansen, it's on our list of thing to find out how exactly he is maintaining them
<sconklin> jjohansen: I think that they do by virue of being backported from kernels which have security applied, but I don't think it's simultaneous with the security releases
<jjohansen> right, thanks
<sbeattie> bjf, sconklin, jjohansen: I think the question is, will the lts-backports get security updates that come through the lucid-security pocket?
<sbeattie> or will they just be part of the periodic updates that roll into -proposed/-updates?
<bjf> sbeattie, heh, that's a good question
<sconklin> yeah, I agree. That's the question
<sconklin> we don't have an answer
#ubuntu-kernel 2010-12-07
<sacarlson> what path in git should I use to be able to pull the latiest at all time?  like git clone git://kernel.ubuntu.com/ubuntu/?
<CarlFK> sacarlson: "latest" isn't well defined.  do you want stable or dev?  if dev, then mainline or some experimantal branch.  if main, then ubuntu or linus's?  I think I can go on...  so what do you want?
<sacarlson> I guess dev
<sacarlson> I want the top master
<sacarlson> or at least a path to it I can alway go back
<sacarlson> I want to compare what I now run in a webcam driver ibmcam with all that ubuntu has or will have.   I already have the master from kernel.org I would like to compare ubuntu to that also
<CarlFK> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-intrepid.git ubuntu-intrepid
<CarlFK> that's what I have from when I was doing something... sounds like what you want.. maybe.
<sacarlson> I thought we already have like maverick or something and beyond that
<CarlFK> "...from when I was doing something"
<sacarlson> and if new comes is I pull will that move from intrepid to maverik?
<CarlFK> no.  but maverick is stable. dev is natty
<sacarlson> but I thought releases were in alpha order  like abcd   intrepid is like I J K L M   maybe maverick dev would be above that?
<CarlFK> what comes after M? :)
<sacarlson> N?
<CarlFK> yes.
<CarlFK> and what does *N*atty begin with...
<sacarlson> n
<CarlFK> or are you still not understaning my git line?  
<CarlFK> I was trying to debug a kernel crash back in intrepid time.  so that was what I was pulling back then.
<sacarlson> I don't see the N in your git line 
<CarlFK> dev is natty
<CarlFK> today.
<sacarlson> clone git://kernel.ubuntu.com/ubuntu/dev  ?
<jk-> git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
<jk-> ^ sacarlson 
<sacarlson> ok good enuf
<CarlFK> jk-: thanks.
<sacarlson> jk-: CarlFK:  that was perfect just what I was looking for thanks you guys
<CarlFK> cool.  sorry my help was confusing 
<crimsun> bjf[afk]: hmm, 2.6.35.9, presumably?
<crimsun> ^ RE: [Applied] Maverick update to 2.6.35.0 upstream stable release
<bjf[afk]> crimsun, heh, yup
<jjohansen> smb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/684875
<ubot2> Launchpad bug 684875 in linux (Ubuntu) (and 1 other project) "Patch to Natty 2.6.37-virtual breaks non-EC2 users (affects: 1) (heat: 14)" [High,Confirmed]
<rsajdok> Is there any guide, wiki page for kernel bug triage? https://wiki.ubuntu.com/Kernel/BugTriage/BugDay
<Kano> hi apw , do you know when 37rc5 will be available in mainline
<hrw> morning
<hrw> can kernel maintainers give me opinion on bug 682681?
<ubot2> Launchpad bug 682681 in linux (Ubuntu) "allow to build linux-source package only (affects: 1) (heat: 10)" [Undecided,In progress] https://launchpad.net/bugs/682681
<Kano> hrw: which arm system do you use?
<hrw> Kano: now only pandaboard, have also beagleboard b7/c3 and several <armv7a ones
<hrw> Kano: why you ask?
<Kano> well tegra 2 would be interesting
<ogra_ac> there is work going on in the #ac100 channel for porting it to at least .36
<ogra_ac> and google has a branch too for chromeos on tegra2
<ogra_ac> someone would have to make either of these upstreamable ;)
<Kano> i am more interested in xbmc on a small system
<ogra_ac> then i'd rather suggest a pandaboard
<Kano> but of course a webbrowser + flash would be cool
<ogra_ac> it has all codecs and 3D drivers available
<hrw> panda also has unstable memory and slow usb bus
<hrw> you get 1GB chip where <700MB works
<ogra_ac> tegra 2 is a pain because nvidia pulled all important functions into a binary daemon
<Kano> and those do not work?
<ogra_ac> and the 3D driver only works with certain kernels (same goes for the X server, only for certain X releases)
<Kano> i thought it had full openmax accelleration and there must be a xbmc branch for that
<ogra_ac> panda comes with full oÃ¼penmax support by default in ubuntu
<ogra_ac> and is way way cheaper 
<Kano> did you try the openmax xbmc branch?
<ogra_ac> beyond that tegra2 doesnt have any NEON support
<ogra_ac> not yet, but we have a spec for a mediacenter edition on the panda for natty
<ogra_ac> so it will be tested
<Kano> nice, boxee, a xbmc clone will not use tegra 2 as they wanted first, they now use atom
<ogra_ac> yep
<cking> wonder what changed their mind?
<ogra_ac> which is silly ... they should have taken omap4 from the beginning ;)
<ogra_ac> cking, i would guess missing NEON and flash issues
<cking> shame
<hrw> ogra_ac: atom+ion gives you codecs and ability to run any OS
<ogra_ac> hrw, yeah, and eats about 10x the power
<ogra_ac> and needs a fan etc etc
<cking> who want's a noisy box to watch video?
<ogra_ac> atom users ;)
<cking> it's 'cos they are used to a whirring sound back in the good old VHS and Betamax days
<ogra_ac> hehe
<Kano> Atom CE4100 is no ion
<hrw> tomboy arghhhhh... looks like I will have to run internal wiki or something...
 * ogra_ac recommends tiddlywiki 
<hrw> ogra_ac: save does not work in chromium
<ogra_ac> ah, bad
 * hrw -> strace tomboy
 * cking wishes jimmy wales would stop nagging me every time I use wikipedia
<JFo> or his cronies
<JFo> their pleas are deafening in their silence
<cking> yep
<pgraner> JFo, where is your Ubuntu Kernel Hot Bugs by Team script located
<JFo> pgraner, here: http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
<JFo> oh the script
<JFo> one sec
<JFo> here: https://code.edge.launchpad.net/canonical-qa-tracking
<JFo> pgraner, ^
<pgraner> JFo, bzr?
<JFo> yessir
<JFo> it is in the misc-scripts directory
 * pgraner felt a little piece of him die with that statement
<JFo> but I plan to move all of that over to our kteam-tools git branch
<JFo> heh
<pgraner> JFo, ok so you get manually generate the bug file list and feed it to the script?
<JFo> yessir
<JFo> currently
<pgraner> JFo, ok
<jdstrand> JFo: hi! so I just upgraded to the latest natty kernel and things are slightly strange. for one, music playback over the network (daap) is choppy and imap in evolution is slow. have you seen any network performance issues with 2.6.37-8.21?
<jdstrand> JFo: in terms of bugs
<JFo> jdstrand, I have not noticed any, but that doesn't mean there isn't any
<JFo> let me have a look at the bugs
<jdstrand> JFo: let me move one that I just filed with evolution over
<jdstrand> JFo: rebooting into the maverick kernel 'fixed' it
<JFo> excellent! thank you :)
<jdstrand> JFo: bug #686584
<ubot2> Launchpad bug 686584 in linux (Ubuntu) "IMAP message list regeneration is slow after deleting an email (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/686584
<jdstrand> JFo: now, I had initially ubuntu-bug'd evolution, so it doesn't have the kernel bits attached. shall I do that?
<JFo> jdstrand, yes, please :)
<JFo> and thank you
<jdstrand> JFo: ok, I apport-collected the bug and adjust the title and description to be more 'kernely'
<jdstrand> s/adjust/adjusted/
<JFo> jdstrand, thank you very much
<jdstrand> sure thing
<jdstrand> JFo: just so you don't waste time-- I invalidated that bug. I don't know what went wrong and need to investigate more
<jdstrand> JFo: sorry for the noise
<JFo> jdstrand, no worries
<JFo> thanks for letting me know
 * jdstrand nods
<JFo> I'd be interested still in what you find
<cking> bjf, wanna do the 1 hour kt meeting warning?
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<Sarvatt> anyone have any recommendations on which commits to start reverting from https://lists.ubuntu.com/archives/natty-changes/2010-November/001282.html that might make grub stop loading after a reboot (but works on a cold boot)? 2.6.37-2.10 and earlier work fine, everything later hangs at the grub loading screen after rebooting on my i386 netbook. mainline kernels all work fine
<tgardner> Sarvatt, its been busted since -2.10 ? thats a lot of kernels.
<tgardner> the i386 specific patches seem like a good candidate for revert
<Sarvatt> yeah, haven't been able to warm boot that thing in a long time and finally got around to looking at it
 * Sarvatt nods
<tgardner> likely anything with nx in the commit log
<tgardner> fortunately, it looks like -2.10 to -3.11  wasn't an upstream rebase
<cking> bjf, BTW, I think I fixed that fwts hang, it's in the PPA for testing.
<Sarvatt> I manually edited the efi setup variables on this aspire one to enable NX since it didn't have the option in bios so might be my fault :) I just saw people also mentioning grub hanging early like I'm getting on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/683775
<bjf> cking, cool
<ubot2> Launchpad bug 683775 in linux (Ubuntu) (and 1 other project) "Natty Alpha 1, i915 has blank screen after boot (affects: 12) (dups: 5) (heat: 92)" [High,Fix released]
<tgardner> Sarvatt, you could try bisecting. there aren't that many patches between Ubuntu-2.6.37-2.10..Ubuntu-2.6.37-3.11
<Sarvatt> doing that now, will file a bug on it
<Sarvatt> thanks for the help
<bjf> ##
<bjf> ## Kernel team meeting in 20 minutes
<bjf> ##
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
<bjf> apw, about?
<apw> bjf, am indeed now
 * JFo goes for some lunch
<sconklin> this is really interesting, probably required reading for any network geek https://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/
<GrueMaster> Someone please tell me an automated script misfired and I don't have to retest Bug #673504 yet again.
<ubot2> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (heat: 20)" [High,Fix committed] https://launchpad.net/bugs/673504
<GrueMaster> This fix has been in proposed since Nov 17.  I tested it on Nov 23.  It should have been released to maverick-updates.
<Sarvatt> tgardner: yep you were right, ed6f363a412661f45a1db9c3456db2f9d5057612 i386: NX emulation is the commit that broke warm boots on this netbook
<tgardner> Sarvatt, hmm, kees might be interested in this
<Sarvatt> updating the machine now and i'll file a bug on it
 * kees scratches his head
<JFo> GrueMaster, it fired because there is an open task (the main one which is normally meant for development)
<JFo> if it isn't needed in Natty, I'd say you are ok
<Sarvatt> it hangs on "GRUB loading..." unless I cold boot, kernel selection menu doesn't even pop up
<GrueMaster> This is a separate kernel.
<kees> Sarvatt: please subscribe me; NX emu hasn't changed in a few releases.
<GrueMaster> I have already tested this in Maverick (and yes, it is needed in Natty).
<JFo> looks like pitti wants verification for the one he built
<JFo> per the last comment
<GrueMaster> Natty is currently running 2.6.35-903.17 because 2.6.35-903.19 (with the fix) has been rotting in proposed.
<JFo> hmmm
<GrueMaster> IT HAS BEEN TESTED!
<JFo> I'd defer to pitti on the what, where and why
<JFo> as I am not in on his thought process
<JFo> :)
<GrueMaster> JFo: Not trying to yell at you directly.  Just pissed at the overall inefficiency of the release process.
<kees> Sarvatt: which kernel are you talking about for ed6f363a412661f45a1db9c3456db2f9d5057612 ?
<GrueMaster> I had to retest a couple of networking fixes in Lucid on other platforms 5 times before they were released.  Each retest was because they sat in -proposed until a security patch clobbered them before they were mainlined.
<Sarvatt> kees: 2.6.37-2.10 is fine, everything after 2.6.37-3.11 hangs on a warm boot and it doesn't happen in the mainline kernels, I bisected between those two kernels and that was the bad commit
<kees> Sarvatt: and this netbook can warmboot maverick's kernel?
<kees> Sarvatt: also, I see that as a5f82c0456fa4f0bf55779c055006dfc18314615 not ed6f363a412661f45a1db9c3456db2f9d5057612
<Sarvatt> yeah maverick's kernel is fine
<JFo> GrueMaster, I understand :)
<Sarvatt> http://paste.ubuntu.com/540721/ is the bisect log
<kees> so strange. that whole patch just pokes at userspace limits.
<JFo> <-errand bbiab
<kees> Sarvatt: ah, and you started with Ubuntu-2.6.37-3.11
<kees> and due to rebasing the commit SHAs are different. got it.
<bjf> GrueMaster, I've fixed the tag on that bug and added a comment, that's all that needed to be done.
<GrueMaster> Thanks, bjf. 
<bjf> Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - December-14 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - December-14 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<tgardner> bjf, methinks pitti's update scripts have run amok
<GrueMaster> Great.  All we need is more mok's in the system.  :P
<bjf> tgardner, thanks for the heads up, we'll get it straightened out
<GrueMaster> While I understand that these scripts are designed to improve the kernel team's productivity, they can greatly increase the workload on others.  Maybe a review is in order?
<bjf> sconklin-lunch, ^
<bjf> GrueMaster, there are many scripts being run against LP not just kernel scripts
<bjf> GrueMaster, these in particular belong to pitti and the SRU team
<GrueMaster> ok.  Didn't know what team he was on.
<GrueMaster> But I have been hit by other kernel team scripts in the past.
<sbeattie> bjf: does the linux (not the ti-omap4) changelog reference 673504 for some reason? And why does the ti-omap4 changelog reference 673509?
<bjf> GrueMaster, noted
<sbeattie> (the reason I ask is because the changelog's what the SRU team's scripts look at)
<sbeattie> the reason I ask is because, when pitti peruses http://people.canonical.com/~ubuntu-archive/pending-sru.html to see what's been verified and is safe to move from -proposed to -updates, unless 673509 gets verified, he'll hold off on promoting the ti-omap4 kernel.
<bjf> sbeattie, i understand
<sbeattie> when it seems that the only issue that affects 2.6.35-903.19 has been verified already, and it's sat for longer than 20 days, and so should probably be approved.
<sbeattie> err, s/20 days/7 days/ 
<bjf> sbeattie, it referenced those two bugs because the patch against the ti-omap4 branch referenced them as BugLinks
<sbeattie> bjf: anyway, I'd approach pitti and point it out to him that the ti-omap4 kernel in -proposed can be promoted.
<kees> Sarvatt: what hardware is the warmboot failure happening on? (or is that already in the bug report?)
<Sarvatt> kees: it's an acer aspire one AOA150, just finished upgrading the 300something packages to file the bug
<Sarvatt> it's a little special because the NX enable/disable options aren't exposed in the bios but I enabled the option manually via efi setup vars, can't disable it again without reflashing
<Sarvatt> but I see people reporting a similar problem that might be related on other bugs (hangs at the GRUB loading screen in natty) so might not be isolated to this one
<kees> Sarvatt: but you isolated this to the NX-emu code. It hasn't changed. :(
<kees> Sarvatt: if you're booting 32bit -3.11, you shouldn't have my forced NX on fixes, so we should only be dealing with the nx-emu patch
<kees> Sarvatt: then the variables are the NX bit itself, really.
<kees> Sarvatt: are you booting -generic or -generic-pae ?
 * tgardner --> lunch
<Sarvatt> kees: -generic only, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/686705
<ubot2> Launchpad bug 686705 in linux (Ubuntu) "System hangs at GRUB loading screen every warm boot since 2.6.37-3.11 (affects: 1) (heat: 8)" [Undecided,New]
<JFo> entirely wrong menu option selected :)
<GrueMaster> JFo: Pie wasn't on the menu.  :P
<JFo> unfortunately no :-(
<JFo> and I looked everywhere
<JFo> :)
<Sarvatt> kees: would seeing if it happens on generic-pae be a useful data point?
<kees> Sarvatt: for -3.11, it would, yes.
<Sarvatt> kees: 2.6.37-3.11 generic-pae works
<Sarvatt> so does 2.6.37-8-generic-pae
<kees> Sarvatt: okay, well, that supports the idea that the NX-emu patch is bad. I still don't understand how it's different from maverick yet.
<kees> Sarvatt: I added another comment to the bug; can you verify the "nx-test" behavior for -3.11 -generic and -generic-pae ?
<Sarvatt> sure thing, on it now
<kees> Sarvatt: I'm suspecting the fastsyscall use, but again, that didn't change from maverick, and I don't see how that would stop a warmboot. *scratch head*
<ilmari> how do i compile just a single module (i915) for my current kernel from a patched ubuntu kernel tree?
<ilmari>  I've checked out the tag corresponding to my currently running kernel, copied /boot/config-$(uname -r) to .config and run make LOCALVERSION= EXTRAVERSION=-23-generic drivers/gpu/drm/i915/i915.ko
<ilmari> then I copied that to /lib/modules/$(uname -r)/... and did update-initramfs, but on reboot it refuses to load, complaining "i915: no symbol version for module_layout"
<kees> tgardner: so, I'm at a loss on bug 686705. the only other thing I can think of is to build a kernel with natty's nx-emu reverted and put in maverick's nx-emu back in. the only thing that changed was the use of disable_nx, but I don't see anything wrong with it on visual inspecition between the two patches.
<ubot2> Launchpad bug 686705 in linux (Ubuntu) "System hangs at GRUB loading screen every warm boot since 2.6.37-3.11 seemingly due to nx-emu patch (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/686705
<tgardner> kees, I'll look in a bit. 
 * ilmari resorts to building the entire kernel
<ilmari> eek: temp1:       +96.0Â°C  (crit = +100.0Â°C)                  
<ilmari> ah, at 97Â°C the fan sped up and promptly got it down to 90Â°C
<ilmari> also, the CPU got throttled from "turbo mode" to 1.2GHz (it's nominally 2GHz)
 * jjohansen -> lunch
<tgardner> kees, doesn't seem like there is anything in that NX patch that would be affected by a warm boot.
<kees> tgardner: my thoughts exactly. :(
<tgardner> kees, its likely some BIOS issue. Sarvatt did say he'd been hacking on it to get NX enabled. I wonder if we could get anything info by booting with earlyprintk=vga ?
<tgardner> anything-->anymore
<kees> tgardner: ironically, he didn't need to do anything to get hw NX enabled since my NX unmasking patch is in the later natty kernels.
<kees> (and other people with similar ASUSes reported success with it)
<tgardner> kees, huh.
<Sarvatt> I was going to live with that but ran across comments like this one in another bug making me think it might be more widespread so I put what I found out there  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/683775/comments/21 (this person has the opposite experience that I do though)
<ubot2> Launchpad bug 683775 in linux (Ubuntu) (and 1 other project) "Natty Alpha 1, i915 has blank screen after boot (affects: 12) (dups: 5) (heat: 92)" [High,Fix released]
<apw> kees, do we 'undo' the nx-emu protection?  restore the segments before calling reboot?  perhaps they are surviving the warmboot on this system ... we do use a variety of reboot methods on different h/w for warmboot
<kees> apw: there's nothing really to undo, iiuc -- it's just the cs limit. but no, there's nothing that undoes it before reboot.
<apw> kees, and the grub behaviour is different on natty as it is trying to go into graphics mode so we may need to call an option rom we do not on maverick
<kees> oh... well that's interesting.
<kees> would cs limit affect that?
<apw> kees, so if the warmboot on this machine doesn't restore them it may leave us with much of memory not executable in ring0 or somethign right?
<kees> apw: well, dunno about ring0, I thought the cs limit would just trigger in ring3.
<kees> apw: where is the common "rebooting now" function? we could add something there maybe...
<apw> kees, may be worth finding out if Sarvatt is fixed by using gfxmode=text (or whatever it is) as that reverts us more to the maverick boot sequence
<apw> (thats a grub option)
<kees> I will add that to the bug, excellent.
<kees> hm, not sure it's gfxmode=text, still looking
<apw> kees, its set gfxpayload=text in grub
<kees> oh, not  set linux_gfx_mode=text
<apw> that variable ends up in the otehr onem, so i think either
<kees> okay, will add
<apw> kees, he'll prolly need to do that in the /etc/grub/default somehow
<apw> kees, likely he will know how, its a common debug technique right now
 * apw wanders off to watch some DS9
<Sarvatt> this is with gfxpayload=text
<kees> Sarvatt: ah, where do you use that? all I could find was /etc/default/grub GRUB_TERMINAL=console
<Sarvatt> GRUB_GFXPAYLOAD_LINUX=text
<Sarvatt> it's in my grub.cfg with that in /etc/default/grub
<kees> okay. well... dang. that rules that out.
<ilmari> if anyone can point me in the right direction regarding how to build individual patched drivers for a specific ubuntu kernel I'd love to write up a wiki page about it
<ilmari> even just rm debian/stamps/stamp-build-generic && fakeroot debian/rules binary-generic takes far too long when only one driver is changed
<ilmari> ignoring the initial build which takes yonks and gigabytes
#ubuntu-kernel 2010-12-08
<hallyn_> ikepanhc: hey, dave hansen and i are interested in your ideapad-laptop kernel tree :)
<ikepanhc> hallyn_: thanks
<hallyn_> ikepanhc: do you by chance have suspend/resume working in yours?
<ikepanhc> hallyn_: for s10-3 s3/s4 works fine
<hallyn_> cool - do you have it built in a ppa?
<hallyn_> if not i'll try one
<ikepanhc> hallyn_: no, the patch is for upstream kernel
<hallyn_> excellent
<ikepanhc> hallyn_: I will consider to maintain a dkms package in my ppa, so that everyone can easily use it :)
<hallyn_> ikepanhc: when i get some time i'll have to see why your patches woudl make a difference with resume
<ikepanhc> hallyn_: ahhh? you mean my patches let your laptop can not resume?
<hallyn_> no, i mean maverick kernel does that.
<hallyn_> if you say your kernel resumes, then either something in your patches fixes it, or your config
<hallyn_> (dhansen has a x86-64 config for maverick that lets resume work on his s10-3)
<ikepanhc> hallyn_: I use maverick kernel with ideapad-laptop and bcmwl as external module
<ikepanhc> hallyn_: I just test again on B550 and it works fine
<hallyn_> what does 'with ideapad-laptop' mean/
<hallyn_> with your patches?
<hallyn_> or some package?
<ikepanhc> hallyn_: I compile the driver as a external module
<ikepanhc> hallyn_: use a hello-world Makefile
<hallyn_> i'm using wl.ko as came with the default install
<ikepanhc> hallyn_: me too
<hallyn_> shucks
<hallyn_> all right, fwiw first glance your patches looked quite nice.  anyway, i'm out - ttyl
<ikepanhc> :)
<torgny_j_> apw: ping
 * apw yawns
<jk-> hey apw
<apw> mornign
<smb> morning
<jk-> heya smb
<smb> j/me waves to jk- 
 * smb cannot type correctly this morning
<apw> heheh
<jk-> apw: just looking through Arjan's patches as per delta review spec
<apw> jk-, ta
<jk-> the 'cache EDID...' one has gone upstream, as you probably already know
<jk-> and that appears to have been dropped in master-next
<apw> mark it so in the page and i'll make sure its gone, i think it has
<jk-> which is good
<apw> yep, we've moved somewhat forward since the top list was originally generated for UDS
<jk-> so that still needs updating, or does the change in master-next mean that it's already taken care of?
<apw> well just mark it as needing dropping and i'll spin through and say its already gone when i apply your recommendations
<jk-> ok
<jk-> ah, it's in the dropped section already
<tgardner> cking, hallyn_, AceLan: I'm bouncing tangerine in 10 minutes for openssl update
<cking> ok - I will log off
<JFo> apw, I had a thought earlier... did pete say he wanted to move the stuff I have running off of the qa machine and onto one of ours?
<JFo> I seem to recall some conversation surrounding that
<JFo> I think it had to do with us having more control of what version of things were on there
<JFo> like LPlib
<JFo> etc.
<apw> i don't recall that specifically, i do know he was keen for it to just run, if its helpful for us i to move i don't think anyone cares where it is
<apw> as long as it is on somethign which is not going missing any time soon
<JFo> yeah
<JFo> dunno what made me think of it
<JFo> apw, second question: Do you think it is worthwhile to have the gfxpayload bugs on our list? I think we should.
<apw> JFo, unsure if they should be on the main list, I could do with a list though as i care about them directly
<JFo> good idea
 * JFo works that up
<apw> JFo, sounds good thanks
<apw> JFo, is that anything other than a launchpad search actually?  if we are tagging them ?
<JFo> not much more
<JFo> but would you rather there be a report or just do the search yourself?
<JFo> well, not more at all really
<apw> i think we should have a page with the lists referenced
<apw> so there can be a Key Bugs link to your report, and a 'gfxpayload bugs' which is just a link to the search
<JFo> ok
 * JFo adds that to the TODO
<JFo> <-so this guy doesn't forget it
<apw> hows the tag based list automation going
<JFo> pretty good
<JFo> I was going about getting the tags the wrong way earlier
<JFo> I'm trying to see if/how that has changed since I was doing it way back earlier in the year
<JFo> could be that I was trying to do it wrong then
<JFo> but I should have that bit worked out in a bit
<apw> if you have a working way i'd just be happy
<JFo> hopefully have something rough by EOD today
<JFo> that was the problem :) it didn't work 
<apw> JFo, where i can see the current mock up
<JFo> but I think I know what I was doing wrong
<JFo> I don't have it pushed yet
<JFo> didn't want to put it up there until it was at least doing something
 * apw talks at you
 * JFo puts his headset on :)
<bjf> moin
<JFo> moin bjf
<apw> JFo, blocks-hwcert this one ?
<vanhoof> bjf: this one went out in the previous SRU, right? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/613381
<ubot2> Launchpad bug 613381 in linux (Ubuntu Maverick) (and 2 other projects) "S3 resume hang when PCI Express wakeups don't clear the PM1 PCI_WAKE_DISABLE bit (affects: 1) (heat: 12)" [Undecided,Fix released]
<vanhoof> bjf: /me wondering why its listed on pending sru list
<bjf> vanhoof, looking, these are auto-generated by what's in the changelog
<tgardner> vanhoof, it looks like its been released in both Lucid and Maverick
<vanhoof> yeah i thought it was, just going through each one by one today and that one looked off
<bjf> vanhoof, it is because it was "(pre-stable)" then came in from stable so it was reverted and reapplied, i'll just mark it verification done, we have stopped reverting "(pre-stable)"
<bjf> vanhoof, i've marked it as verification-done
<cking> bjf, I've verified that one, don't want to keep on re-doing it :-)
<bjf> cking, as i said, i've handled it :-)
 * apw screams about C crashing
<apw> X
<cking> should be called XXXX
<vanhoof> bjf: gotcha, thanks for the info
<vanhoof> cking: we've got the wmi fix to verify, I have other paths to hardware should it not get to you in time :)
<cking> vanhoof, I'll do that tomorrow
 * apw pops out to run an errand
<cking> if that's not too late
<vanhoof> cking: did it arrive?
<cking> not yet
<bjf> cking, vanhoof, we have a week to do the verifications
<vanhoof> cking: we have till friday
<vanhoof> cking: theres one in lex though
<bjf> vanhoof, cking, since the kernels weren't available until today, the clock starts today
<vanhoof> bjf: i like pressure
<tgardner> JFo, looking at your top bug list. why haven't some of these been expired? e.g., bug #190492 
<ubot2> Launchpad bug 190492 in linux (Ubuntu) "Kernel hangs on boot (SATA, AMD64/i386) (affects: 3) (dups: 7) (heat: 15)" [High,Triaged] https://launchpad.net/bugs/190492
 * bjf running son to school, will be right back
<JFo> tgardner, good question
<tgardner> JFo, I thought all bugs with no activity were expired at some point
<JFo> well, they have to meet a certain set of criteria
 * JFo looks to see why this one didn't meet it
 * apw finally makes it out the door
<tgardner> apw, out of the closet door?
<JFo> :-/
<tgardner> bjf, there is a Lucid AA patch from jj-afk on the k-t list that could use your review.
<JFo> tgardner, just from a quick look, I'd have to say it was the duplicates that probably kept this one from expiring
<JFo> but I don't see much other than that
<tgardner> JFo, I wonder if any of them have rolled forward to Maverick, etc. It ain't gonna get fixed in Hardy
<tgardner> or Lucid even
<JFo> I can look if you want me to
<tgardner> JFo, I'm gonna mark it 'won't fix'
<JFo> tgardner, works for me
<JFo> something is chewing up my network... brb
<bjf> tgardner-afk, i saw it, wasn't sure your discussion with jj was finished
 * dannf points manjo at #687400
<didrocks> JFo: do you need the output of uname -a for bug #686070 ?
<ubot2> Launchpad bug 686070 in linux (Ubuntu) "black screen (no more gdm/X server) with nvidia propriatery after gfxpayload=keep activation (affects: 2) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/686070
 * JFo looks
<JFo> didrocks, shouldn't need
<JFo> I was running an old script that had not been updated for natty
<didrocks> oh ok :)
<JFo> apologies for the confusion :)
<didrocks> no worry :)
<JFo> was entirely my fault
<didrocks> I got it and dholbach too
<JFo> heh
<didrocks> so for now I workarounded it
<didrocks> but you can poke me if you need further info/testing
<JFo> indeed I will, thanks :)
<JFo> <-lunch 
<didrocks> enjoy :)
<apw> didrocks, its the prop-drivers so there is little chance of a fix for those
<didrocks> apw: right, so we should maybe workaround on some pci?
<apw> i suspect we should just turn off that feature when you install those
<didrocks> yep
<didrocks> because we will require the prop-driver for unity
<didrocks> and engage people installing it
<apw> didrocks, have fun with that given we cannot put it on the CD
<didrocks> apw: already planned, ubiquity will offer that as an option
<didrocks> like the mp3 support
<apw> didrocks, so is the lve CD  going to use classic desktop mode for nvidia, guess it'll have to
<didrocks> and pitti will slightely change the driver wording on install to tell "hey, that can change your graphical interface"
<didrocks> apw: right, that's the drawback :/
<apw> didrocks, does 3d work well enough on the normal ati drivers?
<didrocks> apw: for now, on unity at least, we don't as many issue in compiz than we had with mutter
<didrocks> so, quite positive :)
<didrocks> (the prop one seems to have more issues, weirdâ¦)
<apw> well thats something at least, starting to think intel was it
<didrocks> yeah, the issue is really nvidia-focused
<didrocks> so, for that particular bug, which is quite annoying
<didrocks> I can only say that daniel and I got this
<didrocks> and we don't have the same card
<didrocks> not sure if it's the driver making that for everyone or if we are just unlucky
<apw> the issues on intel with that combination was that the driver is initialising from vga mode, regardless of actual mode so can sometimes leave thngs not initialised
<apw> its probabally the same for nvidia
<didrocks> hum, ok, make sense then
<didrocks> well, just to keep that in mind so that we don't release in that state, or we will hear from it :)
<apw> didrocks, likely its a grub thing we'll have to change, i'll open a task there
<didrocks> apw: sure, just ensure that colin is ok with it, he told me to open a kernel task to first get feedback from your team :)
<apw> didrocks, yep but as its prop-drivers they arn't in the kernel and we have exactly zero control over them
<apw> our recommendation would be not to install them
<didrocks> sure, but as we need 3D now :)
<didrocks> and our nouveau doesn't support it well yet
<apw> didrocks, not obvious why we need 3d but there you go
<apw> given everything on my screen is basically 2d even with unity
<didrocks> you need acceleration for the opengl effect
<apw> didrocks, but there is the rub isn't it.  nothing in the interface needs 3d, the clever and inovative bits are not the fact its 3d, but that its touch ready and simple, and whatever else we claim
<apw> didrocks, any idea what the prop-drivers are called source package wise
<didrocks> apw: well, I think it's more something to talk with the dx team (compiz and unity guys) but they ensure that it's not possible to get the same effects with a 2D library like cairo and such, so they need acceleration
<didrocks> apw: hum, one sec
<apw> didrocks, <personal opinion> they are conflating the two things, being wizzy and doing things don't have to be the same </p.o>
<didrocks> apw: nvidia-graphics-drivers
<apw> but its not my call, and as noone will give me anything but intel h/w i am not affected anyhow :)
<didrocks> :)
<tgardner> apw, what do you think about CONFIG_CRYPTO_CRC32C=y for Natty to solve the lib/libcrc32c shash registration race (as well as an initramfs modprobe issue) ?
<apw> if its tested to work it doesn't seem like a bad solution, we build in all of AGP for similar reasons
<tgardner> see bug #681819
<ubot2> Launchpad bug 681819 in linux (Ubuntu) "libcrc32c.ko does not declare dependancy on crc32c.ko (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/681819
<tgardner> apw, do we have a boot speed profile? 
<tgardner> 'cause I think building it in may have an impact
<apw> tgardner, positive or negative ?
<apw> we can make one both sides pretty easy to check
<tgardner> apw, registering an shash algorithm performs some run time testing. dunno how much.
<apw> tgardner, i wonder if we can hack that out, seems odd to test it every time you insert the module
<apw> tgardner, bug i'll put it on my todo list to go and measure it
<tgardner> apw, well, I'll turn it on for now and we can just measure it
<apw> tgardner, ok
 * JFo goes to dose up some more Vitamin C, brb
<apw> JFo, ping
<GrueMaster> Who can move linux-image-2.6.35-24.42-omap from New to maverick-proposed so I can properly test it?  It has been sitting for 3 hours and I have deadlines to get it tested.
<JFo> apw, pong
<apw> JFo, hows the list generation going
<JFo> working out some kinks now
<JFo> should have the list soon
<JFo> well, the final list
<apw> i am assuming we can have the tag oriented bits auto generating hourly or something today
<JFo> should do
<apw> did you fix up the script to add the tags ?
<apw> s/tags/summary information/
<apw> would it help to sit down with that script and talk through what all the bits mean
<apw> JFo, ^^
<JFo> yeah, I have that worked out
 * GrueMaster has an ominous feeling that JFo's scripts will start spamming him...again.  :P
<apw> GrueMaster, heh, no these are reporting scripts not spamming scripts :)
 * apw finds its generally bjf who spams him
<GrueMaster> Ah.  
 * GrueMaster would like to see a report of how many scripts currently spam him.
<GrueMaster> :P
 * tgardner --> lunch
 * cking --> calling it a day
<bjf> tgardner, is bug #684448 just a tracking bug (looks like it is to me)?
<ubot2> Launchpad bug 684448 in linux-lts-backport-maverick (Ubuntu Lucid) (and 1 other project) "Lucid LTS Maverick backport, security update to 2.6.35-23.41 (affects: 1) (heat: 10)" [Medium,Fix committed] https://launchpad.net/bugs/684448
<JFo> IT's ALIVE!!!!
 * JFo passes cigars out in celebration of the birth of a new script
 * JFo puts it into a server labor camp immediately
<JFo> :)
<GrueMaster> Still need someone to publish linux-image-2.6.35-24-omap-2.6.35-24.42.
<bjf> GrueMaster, there are no archive-admins on the kernel team
<tgardner> bjf, yeah, that kind of looks like  a tracking bug
<bjf> tgardner, cool, i'll tag it as such
<smoser> stupid question. I just did a 'fakeroot debian/rules binary-virtual'. then a 'fakeroot debian/rules clean' and then binary-virtual again.
<smoser> i had ccache first in my path, and i can see that ccache --show-stats is getting misses.
<smoser> but i'm only getting misses even the second time. 
<smoser> any idea what woudl be changing ?
<tgardner> smoser, no idea. maybe time stamps or something are changing the object output.
<smoser> yeah, thats what i'd have to suspec too, but that sucks.
<tgardner> smoser, what is your cache hit percentage?
<smoser> cache hit                              4
<smoser> cache miss                         13000
<smoser> what percent is that ? :)
<tgardner> its bad...
<tgardner> smoser, its so bad you might as well not bother.
<smoser> yes, in fact almost certainly the ccache overhead is worse.
<tgardner> smoser, I've used it for kernel builds with better results then that.
<smoser> but it really "should work".  ccache is an awesome speed up for those of us withouth access to 64 way machines
<tgardner> smoser, I'll run one of my builds twice to see what kind of hit rate I get
 * jjohansen lunch
<kees> apw: there were 2 problems with module NX. one was solved and I forwarded an email about it. but I think you'd mentioned something else? I want to track that down and see if it's been fixed yet.
<kees> apw: ah-ha, found it. http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=691513f70d3957939a318da970987b876c720861
<djalterego> I'm trying to isolate an nfs client issue to an Ubuntu component.  When testing using mainline kernels, should I use http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ or http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/ since I'm using Lucid?
#ubuntu-kernel 2010-12-09
<djalterego> Anyone know?
<jk-> smb: none	/srv/media/music	aufs	ro,br:/srv/media/music=rw:/home/jessica/music=ro:/home/jk/music=ro	0 0
<manjo> apw, ping 
<manjo> apw, interested in having lunch outside ?
<manjo> apw, tired of sandwitches 
<jjohansen> manjo: ugh, not the sandwiches again
<manjo> apw, was wondering if I can drag you to coriander for lunch
<manjo> jjohansen, yeah! now is 4 days in a row
<apw> manjo, not hungry enough for such a large lunch
 * jjohansen thinks starving is better than that
<apw> specially as we get free food tonight
<apw> (i assume)
<manjo> apw, hmm... was not thinking of large meal... 
<apw> going to a curry house is not likely to be a small meal
<manjo> apw, ah 
<manjo> apw, is there a cafeteria downstairs ?
<manjo> or outside ?
<apw> manjo, no cafeteria that i know of
<manjo> ah crap 
<apw> and bear in mind if the students are here, then we may not get in and out easily
<manjo> s**t
<manjo> apw, http://sourceforge.net/apps/mediawiki/omnibook/index.php?title=Main_Page
<manjo> apw, http://sourceforge.net/projects/omnibook/files/ is what I am pointing to
<cking> http://www.visualcomplexity.com/vc/project_details.cfm?id=392&index=392&domain= - why Windows + IIS is more complex than Linux + apache
<amitk> manjo: where are you guys?
<amitk> manjo: london?
<manjo> amitk, yep
<manjo> amitk, are you in london for some reason as well ? 
<amitk> manjo: about to start vacations from next week in india
<manjo> amitk, ah yes ... me too :) 
<cking> manjo, I'd like to take vacation, but I'm stacked up with work :-(
 * manjo cracks the whip on cking 
<manjo> cking, I need to take vacation and visit my mom, she had a lot of surgery this year 
<manjo> cking, so my vacation will feel more like work :) 
<hrw> hi
<hrw> does someone here uses ftdi usb serial adapters with natty?
<hrw> Linux home 2.6.37-7-generic #18-Ubuntu SMP Fri Nov 26 19:23:37 UTC 2010 x86_64 GNU/Linux
<hrw> [692402.488921] usb 2-6.1: FTDI USB Serial Device converter now attached to ttyUSB0
<hrw> but picocom says: FATAL: cannot open /dev/ttyUSB0: Resource temporarily unavailable
<hrw> even as root
<cking> sigh
<hrw> cking: ?
<cking> just lots of issues to sort out today...
<hrw> ah, happens
<hrw> I am now wondering about 'will I boot 3 times to check kernel bug' or rather ignore it and resolder serial cable to not use usb-serial adapter
<cking> serious hardware issues then?
<hrw> no, kernel bug
<hrw> my desktop has 7 normal serial ports but I lack 1-to-1 cables requred by newer boards
 * cking reboots
<jeremyA> with kernel 2.6.32-26-server and kernel 2.6.34-020634-generic (installed from mainline ppa), I am experiencing frequent system hard hangs.  This machine is a server without X installed.  RAM has been verified good with memtest86+.  kvm is running.  nothing unusual shows up in the logfiles around the crashes.  I'm absolutely stumped on this problem.  Any tips for troubleshooting what I suspect is a kernel flaw?  It ran for month
<jeremyA> s on LTS 8.04.01 w/o any issues at all (no KVM under 8.04.01, but I was running vmware-server 1.0.6 and VirtualBox simultaenously).  the 6 SATA disks report no errors via SMART.
<jeremyA> (and when I say "ran for months" I mean "months of uptime" -- it actually ran 8.04 for a couple of years, rebooting only for kernel upgrades and power outages and such)
<tgardner> jeremyA, thats not much to go on. Have you started a bug so we can at least have a look at your HW specifics? Use 'ubuntu-bug linux'
<jeremyA> will do, thanks
<jeremyA> would this bug best be categorized as "kernel config" "other" or "I don't know" ?  I'm hesitant to use the last, since I'm betting that bucket fills with lots of poorly defined issues...
<JFo> morning apw 
<tgardner> jeremyA, I haven't the faintest idea. What you _should_ put in the summary is a description of your workload, etc
<jeremyA> will do, thanks
<apw> JFo, moin
<apw> JFo, hows the automatic generation of the page going
<JFo> good, I fixed an oversight on my part in the statuses to search for
<JFo> it wasn't getting the Triaged status
<JFo> so I have a test run going now and then it should be done
<JFo> I have a bash script written that runs all the possibilities then cats the results together for processing by the hot list script
<JFo> and I tested the hot list script itself and it works well with the generated file
<JFo> now the only bit to add is the manual portion
<JFo> which just got a whole lot more non-trivial
<JFo> :-/
<smoser> tgardner, what would you want to do about comment 16 at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/659084 ?
<ubot2> Launchpad bug 659084 in linux (Ubuntu Maverick) (and 1 other project) "2.6.35-22-virtual is missing nfs modules (affects: 14) (dups: 1) (heat: 94)" [High,Fix committed]
<smoser> you want me to open a new bug requesting nfsd module also ?
<tgardner> smoser, _still_ missing a module?
<smoser> yeah. nfs client works, server no
<tgardner> smoser, drat. yes, open a new bug and assign me to it
<smoser> i hvaen't verified that, just trusting the comment
<smoser> actually... your grep verifies no nfsd.ko
<tgardner> smoser, well, I was focused on client
<smoser> right.
<jeremyA> tgardner:  thank you for your advice.  I have filed bug 688068 :)
<ubot2> Launchpad bug 688068 in linux (Ubuntu) "lucid system randomly locks up, does not recover (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/688068
<JFo> apw, doing a manual run of the report now to verify the results
<JFo> after this, the cron job is set so it should run regularly
<tgardner> jeremyA, hmm, vintage hardware. there are a couple of possibilities. I'd start by booting with nomsi, then try noacpi.
<smoser> tgardner, bug 688070
<ubot2> Launchpad bug 688070 in linux (Ubuntu) "-virtual kernel missing nfsd module (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/688070
<tgardner> jeremyA, just saw that you've already tried noacpi.
<jeremyA> what does nomsi do?
<jeremyA> an athlon64 X2 5400+ is vintage hardware?  I'm getting old...
<tgardner> jeremyA, it changes the way interrupts are serviced on your e1000e NIC. It might also affect the r8169 (but I can't remember for sure)
<tgardner> jeremyA, if you were running Hardy, then its vintage :)
<tgardner> smoser, I just verified that ccache isn't working worth a dang under natty.
<tgardner> cache hit (direct)                    37
<tgardner> cache hit (preprocessed)              42
<tgardner> cache miss                         66188
<tgardner> after 2 identical passes
<smoser> tgardner, i did a complile with gcc -E (taking a line from the log)
<jeremyA> tgardner do you want me to boot on the mainline kernel with nomsi or the 2.6.32-26-server kernel?  And should I include noacpi with the nomsi, or is that unnecessary since noacpi by itself has not been helpful?
<smoser> and didn't see any thing in the output that was an obvious time stamp
<tgardner> jeremyA, boot 2.6.32-26-server with just nomsi
<jeremyA> roger.
<tgardner> jeremyA, please report your results in the bug as I'm not always around on IRC
<jeremyA> tgardner do you have a preferred clocksource?  I've been avoiding tsc since I got "clocksource unstable" logged a few times?
<jeremyA> tgardner will do
<tgardner> jeremyA, let it choose the clocksource. we'll try to keep the minimum number of variables.
<jeremyA> tgardner:  I will boot with just nomsi then, thanks
<tgardner> jeremyA, as smb just pointed out to me, its 'pci=nomsi'
<jeremyA> tgardner: thanks for the catch :)
<hrw> jeremyA: check also 'nolapic noapic' args
<jeremyA> hrw:  won't that disable SMP?
<hrw> jeremyA: check does it works - it could help to limit possible sources of bug
<hrw> jeremyA: I would also check maverick and maybe karmic kernels
<jeremyA> hrw:  can I install the maverick kernels w/o updating the rest of the OS, or should I just do a dist-upgrade?
<hrw> jeremyA: grab just kernels
<jeremyA> hrw:  from the mainline repos?  or elsewhere?
<hrw> jeremyA: and also worth maybe bios update
<hrw> jeremyA: mailine repos
<jeremyA> hrw:  I have a flash drive with the latest BIOS waiting for use here...if it crashes with nomsi enabled, I'll flash the BIOS and try nomsi again
<hrw> jeremyA: you have 02/05/2008 bios and there were few releases in meantime
<jeremyA> hrw:  only 2, and the most recent is marked "beta"
<tgardner> jeremyA, you can install a Maverick kernel as a backport, e.g., 'apt-get install linux-image-server-lts-backport-maverick'
<jeremyA> tgardner:  thank you!
<tgardner> jeremyA, you can also get Natty kernels from https://launchpad.net/~kernel-ppa/+archive/ppa
<\sh> guys, the drbd module should be somewhere in the kernel packages of lucid, right?
<tgardner> \sh, I think thats an external driver
<\sh> tgardner: just discussing the mess with ivoks ;)
<hrw> bye
<vish> hi, for bug #652934 , seems everything is OK for Uploading to maverick-proposed. the upstream commits were tested on both the bugs and no one has a problem with the commits on ap-w's kernel, how can we get this scheduled for the next -proposed upload and then to -updates?
<ubot2> Launchpad bug 652934 in linux (Ubuntu) "[RV515] Guest session causes screen to flicker violently and session is unusable (affects: 2) (heat: 73)" [Medium,Confirmed] https://launchpad.net/bugs/652934
<vish> ..we can revert the earlier patch too.
<tgardner> vish, you should hassle apw to release his SRU patch
<apw> tgardner, huh
<vish> :)
<apw> tgardner, i see you pushed that NX fix  ... but NX is currently reverted anyhow
<tgardner> apw, this is the new tip fix
<apw> right, but the fix won't do anything in the sense that the NX module code is not in the kernel anyhow
<apw> as the whole thing was causing all sorts of issues
<apw> we did that just before A1#
<tgardner> apw, hmm, how did it apply? I didn't look at it very closely
<smb> Thats why there are reverts of reverts
<smb> (I mean in the pull request)
<apw> tgardner, it applies in existing code, not in the NX code itself
<apw> well reverts of reverts make no sense
<apw> we should just re-cherry the patches
<tgardner> alright, lemme take a close look
 * apw goes back to updating the delta
<apw> tgardner, i am planning to upload today is there anything other than the NX you think is pending
<tgardner> apw, nfsd in -virtual, and smb's mount fix
<smb> not exactly mine. just being the messenger ;)
<tgardner> smb, well, you spent a lot of time finding it
<apw> tgardner, if you sort out the NX bits i'll do the other two
<tgardner> apw, k
<smb> tgardner, I spent a lot of time looking for that. But annoyingly upstream took just half a day to actually spot it and have a patch. *gah*
<apw> smb finding it is the hard bit, almost always
<JFo> <-lunch
<smb> Yeah, at least I was able to have it relatively well isolated to the umount call. Just was looking for a race when the was a access out of bounds
<apw> tgardner, ok i've pulled both of those in and pushed out master-next
<apw> tgardner, you doing the NX patches or shall i
<tgardner> apw, I'm a bit confused about how the NX emulation patches are related to making modules RONX?
<apw> tgardner, want me to look at the pull then ?  i am conflating some amount of NX wording ... there is module NX and NX emulation and they don't really overlap
<tgardner> apw, sure, go ahead
<tgardner> AFAICT it looks right
<apw> ack
<bjf> apw, are you at the sprint today?
<apw> bjf
<apw> yep
<apw> i brought up persistant results, and they recon they can do that
<apw> need to ask about security testing though
<tgardner> GrueMaster, did you notice that linux-ti-omap4 2.6.35-903.19 was promoted to -updates ? I won't be able to get Natty into the archive until I figure out a tools issue (binutils)
<GrueMaster> ok, thanks.  I was worried that it had been dropped.
<tgardner> GrueMaster, "it" being Natty?
<GrueMaster> no, maverick.
<GrueMaster> TI wanted that fixed a while ago.
<GrueMaster> And after the BeagleXM DVI patch issue, I was concerned.  But thanks for making sure the patch made it through the gauntlet.
<tgardner> GrueMaster, np
<\sh> hmmm...could someone verify something for me? http://paste.ubuntu.com/541527/ <- this looks wrong, when I have a running -server kernel
<bjf> smb, have you seen anything about a 2.6.35 stable tree from Andi Kleen?
<\sh> (on lucid that is)
<smb> bjf, I seen him announce it and today some question of him about a patch. But I have not looked to where to find it.
<tgardner> \sh, it looks like open-vm-dkms might have some incorrect package dependencies.
<smb> It seems to pull in the headers from -rt
<\sh> Depends: dkms, gcc, make, linux-headers | linux-headers-virtual
<apw> smb, i had assumed the trees would remain in stable user... perhaps not
<\sh> apt-get install linux-headers -> gives me a list of header flavours
<\sh> apt-get install linux-headers-virtual give me the right headers for -server 
<smb> apw, I was not sure from the announcement. Could be both
<apw> smb, yeah as i say 'i assumed' but ... nothing is actually said is it
<smb> apw, There is a lot left for assumption, yes. :)
<\sh> tgardner: I checked now every dependency...and everything which pulls in linux-headers is correct with its assumption that I have a -server kernel..only open-vm-dkms is incorrect
<tgardner> \sh, talk to the package maintainer? 
<\sh> tgardner: use the source, \sh is much better first, before I'm writing any bugreports ;)
<tgardner> bjf, gimme a review on the nfsd patch for Maverick so I can get it into the pipeline for tomorrows pre-proposed build
<bjf> tgardner, i did, it's in my sent folder but not on the mailing list yet, i acked it
<tgardner> bjf, thanks
<bjf> tgardner, how do you update your master-next branch in your personal "bare" git repo? i've just switched to using bare repos and fetching from origin I can handle but how do you "reset" a branch with what you fetched?
<tgardner> bjf, not exactly sure what you're asking. I usually add a remote, e.g., rtg, so taht I can do a 'git push rtg +master-next', etc
<hallyn_> bjf: if you mean set the current branch, i just edit HEAD  :)
<bjf> tgardner, git://kernel.ubuntu.com/rtg/ubuntu-maverick.git is a bare repo, how do you update the master-next branch in it from the master repo?
<bdmurray> JFo: you might want to look at rewriting titles for bugs like bug 654287 - there are quite a few like that
<ubot2> Launchpad bug 654287 in linux (Ubuntu) "[STAGING] (affects: 1) (heat: 54)" [Undecided,New] https://launchpad.net/bugs/654287
<tgardner> bjf, git fetch origin;git fetch origin master-next;git push rtg +master-next
 * smb wonders where his replies on the ml are. Seems to be unwilling atm
<tgardner> bjf, umm, git fetch origin master-next; git reset --hard FETCH_HEAD, git push rtg +master-next
<tgardner> smb, yeah, the list seems to be stalled
 * bjf thinks his are the same wherever smb's are
<bjf> tgardner that doesn't work in a bare repo
<tgardner> bjf, is your local working repo bare?
<tgardner> the only bare repos that I have are on zinc
<bjf> tgardner, no, but mine on zinc is, i think the first bit you mentioned "git fetch origin master-next" is right
<tgardner> bjf, so I'm not sure what your problem is. maybe you could pastebin it?
<bjf> tgardner, that's ok, i think i'm good for now
<hallyn_> is there a package i can ask a bug submitter to install which provides the debug symbols for the kernel so they can run 'crash'?
<tgardner> hallyn_, linux-crashdump ?
<hallyn_> tgardner: cool, thanks.  
<tgardner> the debug packages might have to be manually installed. there is no meta package to track kernel versions
<bjf> apw, is the sprint done for today?
<tgardner> bjf, am using your 'Acked-by' in vain for 'Add nfsd to -virtual flavour' since it has yet to come through on the list, and I'm tired of waiting.
<bjf> tgardner, please do
 * tgardner --> lunch
<jj-afk> rebooting
<plaur> i'm getting "BUG:soft lockup CPU#0 for 61s (kswapd)" continuously, after 10-30 minutes on an older Athlon64 system with 2.6.35 from Ubuntu 10.10; the older 2.6.32 works fine on the same system... any ideas?
<plaur> the same 2.6.35 works fine on the netbook, though
<pmatulis> anyone familiar with "NMI errors" upon bootup?  Getting some strange results with this and the lucid lts-backport kernel
<tgardner> pmatulis, you mean the backported maverick kernel?
<pmatulis> tgardner: yeah
<tgardner> pmatulis, do you see these errors with the native maverick kernel?
<tgardner> I wanna make sure its not the toolset
<pmatulis> tgardner: strange stuff.  every second boot results in an unbootable system on HP Proliant G360 (12 boots tried)
<pmatulis> tgardner: i haven't been able to test the native one (customer systems)
<pmatulis> tgardner: and when downgraded to native lucid, another NMI error, but a reboot fixes it
<pmatulis> tgardner: and then it's good for another 20 boots
<tgardner> pmatulis, is the NMI fatal?
<pmatulis> tgardner: indeed
<tgardner> pmatulis, can you get them to run ubuntu-bug in order to collect some HW info ?
<pmatulis> tgardner: yes, i am heading in that direction
<pmatulis> tgardner: i don't think his system has internet yet (for some reason)
<tgardner> pmatulis, do we have any of these in cert ?
 * pmatulis checking
 * jjohansen lunch
#ubuntu-kernel 2010-12-10
 * cking waves to manjo
<manjo> cking, hello
<cking> how was the party?
<manjo> it was a blast
<manjo> we drove under the london bridge a couple of times so got to see the bridge from a diff angle
<cking> cool
<manjo> also some of the buildings were lit 
<cking> good old london town
<manjo> saw the london eye up close 
<manjo> lit bright blue
<manjo> kept my drink count to 4... so not feeling terrible this morning 
<manjo> although I was super super hungry at the end coz the food was not all  that edible
<cking> was it made of rubber?
<manjo> heh some fish and duck
<manjo> it was ok
<cking> nice
<cking> pity I was stuck at home fixing bugs
<manjo> cking, you cannot make us feel guilty... sorry :) 
<manjo> cking, but on the downside ... I think its going to be sandwiches again for lunch ... 
<cking> least you get a free lunch. 
<cking> I didn't get one yesterday, sorting out S3 issues
 * apw wonders where the morning has gone already so soon
<manjo> apw, cking sounds a little sad that he could not join us for the parteeee
 * manjo going down for a reboot after upgrade
<manjo> apw, hmmm sandwiches again ... 
<manjo> yummy
<apw> never, really?
<manjo> apw, I am going to Tamarind (curry place) this evening with my cousin 
<apw> nice you managed to overlap with him
<manjo> apw, my cus says this place is good ... http://www.tamarindrestaurant.com/ but it looks too classy 
<nirvana> older 2.6 kernels link the asm -> asm_<arch>
<nirvana> I dont see that happening with a new 2.6.31+ kernels
<nirvana> why is that
<nirvana> where I am supported to look for headers 
<nirvana> Why is it not happening now???
<apw> smb, i have just dropped that update for the meeting into your inbox, also copied to kate for completeness
 * apw runs, smb call me on my mobile if there are issues
<jMCg> Hello happy people!
<jMCg> I was forwarded here from #ubuntu+1
<jMCg> I would like to know if there will be utrace support in the Natty kernels.
<JFo> brb, rebooting from updates
<manjo> jMCg, any reason why? can't you use ptrace ?
<jMCg> 15:56 < fche> utrace & ptrace are not substitutes for each other.  utrace is an intra-kernel API to make things like ptrace and systemtap and other future debugging technologies share control over processes
<jMCg> I couldn't have put it better, I guess.
<jeremyA> tgardner:  I saw your note, and wanted to make sure I understand the issue.  If I'm in an NFS-mounted directory, I can't copy a file to that same directory?
<jeremyA> tgardner:  bug 688068, by the way :)
<ubot2> Launchpad bug 688068 in linux (Ubuntu) "lucid system randomly locks up, does not recover (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/688068
<tgardner> jeremyA, is this on the same machine as the NFS server?
<jeremyA> it was a KVM image doing the work
<tgardner> but its on the same physical HW, right?
<jeremyA> yep, KVM guest on a physical host which is also sharing NFS
<tgardner> that is the configuration that upstream says is not supported. it causes memory exhaustion because there is no throttle (like a network connection) in between the consumer and the producer
<jeremyA> oh, interesting.
<jeremyA> well, that's an edge case, for sure
<jeremyA> so 2.6.32-26 may be working great with pci=nomsi
<tgardner> jeremyA, you should try rsync using ssh instead
<jeremyA> hrm.  
<jeremyA> I'll look into that... do you have any good docs to recommend off the top of your head?
<tgardner> docs for what?
<jeremyA> (may I add our IRC conversation to the bug report, for the next sod who does this?)
<tgardner> of course
<jeremyA> well, I'd like a remotely-mounted filesystem....
<jeremyA> Is samba safer?
<tgardner> samba might suffer from the same issue, but I don't know for sure
<jeremyA> Is there a preferred solution for doing this sort of thing?  I can de-virtualize my pytivo instance, which is the primary user of this, but I'd rather not :)
<tgardner> jeremyA, I'd try rsync through an ssh session.
<jeremyA> okay, I can do that for some of my cases...a read-only NFS filesystem is still safe?
<tgardner> jeremyA, likely. you'll only have problems when your platform is under extreme memory pressure. Hence the network suggestion since the socket interface actsas a throttle.
<jeremyA> tgardner that makes sense, definitely.  I would imagine sshfs would work similarly.
<alex_mayorga> Hi! I'm getting plenty of kernel panics on 2.6.37.8 and 2.6.37.7 can someone help me?
<jeremyA> Alternate solutions would be to move the NFS server off to another machine, or to move the kvm guest to another piece of hardware.  Mr. Gardner wasn't sure if Samba would also be affected by this, so I have settled moving the one guest which needs r/w NFS access to a separate physical server.
<jeremyA> oops
<alex_mayorga> how do I report the problems?
<jeremyA> alex_mayorga:  try running "ubuntu-bug kernel" at the command line.  I believe you have to be root
<jeremyA> alex_mayorga:  that will let you enter a bug report initially, then you can finish filling it out via a browser :)
<alex_mayorga> jeremyA: do I have to be running the kernel that's panicking?
<jeremyA> I honestly do not know.
<alex_mayorga> "package kernel does not exist"
<jeremyA> sorry
<jeremyA> ubuntu-bug linux
<jeremyA> =)
<doko> apw: do you what kind of build failure rtg fixed with the last upload?
<doko> know even
<alex_mayorga> "The problem cannot be reported: This is not a genuine Ubuntu package"
<alex_mayorga> :S
<alex_mayorga> I guess natty is not genuine Ubuntu
<tgardner> doko, are you referring to ti-omap4 and binutils ?
<doko> tgardner: yes (was looking for your rtg nick ;)
<tgardner> doko, I got it fixed with some help from the Linaro guys.
<doko> ok
<jeremyA> alex_mayorga:  how odd.  I'm afraid I'm just here getting help with my own issue, so I've exhausted my knowledge on the subject.  Perhaps one of the regulars can help...
<alex_mayorga> jeremyA: no worries, thanks on the help anyway
<JFo> <-lunch
<JFo> ok NOW, I am finally going to lunch :)
<JFo> bbiab
<tgardner> jjohansen, how is ecryptfs coming? bug #344878 has an A2 delivery, and I'm not seeing much activity on it.
<ubot2> Launchpad bug 344878 in linux (Ubuntu) (and 2 other projects) "file name to long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry) (affects: 48) (dups: 5) (heat: 282)" [Undecided,In progress] https://launchpad.net/bugs/344878
<jjohansen> tgardner: I am working on the first pass of it
<tgardner> jjohansen, how about some updates in the bug so the rest of us can enjoy your progress?
<jjohansen> tgardner: sure
 * tgardner wonders why the tracking bug for 2.6.32.27+drm33.12 created by bjf mentions 'The following 126 patches are in the 2.6.32.19 stable release'
<bjf> tgardner, copy-paste error
<tgardner> yeah, I made one of those once :)
<bjf> tgardner, heh, fixed, thanks for the catch
<bjf> tgardner, didn't think anyone was actually anal enough to read those
<tgardner> you've already forgotten my middle name?
<bjf> LOL
 * tgardner --> lunch
 * cking ---> calling it a day
 * vanhoof waves to cking 
<cking> :-)
<tgardner> cking, have a good weekend
<vanhoof> cking: oh before you leave
<cking> ..?
<vanhoof> cking: what shipping company do you prefer for international next-day type stuff
<vanhoof> cking: does one suck less?
<cking> FedEx or DHL, they all seem  the same to me
 * vanhoof has UPS and FedEx in close proximity
<vanhoof> ok
<tgardner> vanhoof, just get Blythe to make the arrangements
<vanhoof> tgardner: not that easy
<tgardner> vanhoof, she makes it erally easy
<tgardner> really*
<cking> it's never easy when one requires a special bespoke delivery to the UK late in the day.
 * bjf is heading out to luch today
<pmatulis> any reason why a network driver supported by the Lucid 10.04 ISO is not recognized during a netboot install? see [1]
<pmatulis> [1] https://bugs.launchpad.net/ubuntu/+source/pxe/+bug/607411
<ubot2> Launchpad bug 607411 in pxe (Ubuntu) "10.04 Atheros AR8131 network install no network device found (affects: 1) (heat: 25)" [Undecided,New]
<cking> vanhoof, I sent you an email of my home address, just in case you don't have it already.
<vanhoof> cking: yeah i have it memorized
<cking> heh :-)
<vanhoof> :)
 * cking seriously has to sort out the kids now.
<tgardner> pmatulis, missing firmware?
<tgardner> or its not in a udeb
<pmatulis> tgardner: no idea
<tgardner> pmatulis, you need to start a bug report and attach the usual stuff.
<pmatulis> tgardner: well the bug is above.  will ask for apport info
<tgardner> pmatulis, doh! so it is
<tgardner> pmatulis, yeah, looks like its a udeb issue. it would still help to have the apport info
<pmatulis> tgardner: fixable for .2 release?
<tgardner> pmatulis, the timing will be tight, but perhaps
 * pmatulis leans a little closer to his computer
<tgardner> pmatulis, actually, since its a netboot problem it'll get fixed sooner then the point release
<tgardner> the CDROM already supports the driver, which is why I'm sure its a udeb issue
<pmatulis> tgardner: re apport, if it won't install via PXE then i must install via media and run apport or easier route?
<vanhoof> tgardner: hey you're right ;)
<vanhoof> tgardner: blythe did make it easier
 * vanhoof lulz
<tgardner> pmatulis, if you'vve a hard ware network you can just boot the Live CD and run apport from there
<tgardner> vanhoof, I love that girl :)
<pmatulis> tgardner: gotcha
<pmatulis> tgardner: curious, is it possible to "insert" a working driver during install time in such a case?
<tgardner> pmatulis, you'll have to consult someone more PXE savvy then me. ogra or cjwatson could likely tell you.
<pmatulis> tgardner: thx
<tgardner> pmatulis, also you could try the guys in cert. ara, cr3, etc
<ogra> pmatulis, could be that nobody from the kernel team added the driver to the inird 
<ogra> *initrd
<ogra> when it was enabled
<ogra> NIC drivers need to be added manually
<pmatulis> ogra: interesting, sounds like a manual process
<ogra> yes
<tgardner> ogra, but they generally go into a NIC udeb
<pmatulis> ogra: how to add one during PXE install time?
<ogra> tgardner, ah, right, i missed the netinstall bit above
<tgardner> ogra, in any event, the kernel team neglected to add it :)
<ogra> i'm just checking hook-functions in initramfs-tools, seems the bit where you needed to manually add NIC drivers is gone in maverick
<ogra> so that probably changed
<pmatulis> ogra: k, using lucid here
<ogra> lucid still has it http://paste.ubuntu.com/542012/
<tgardner> ogra, NICs aren't generally boot essential which is why (I think) that stuff was removed from the initrd. Especially since they can be added to a udeb for little cost.
<ogra> (in /usr/share/initramfs-tools/hook-functions)
<ogra> tgardner, ugh, that would break netbooting 
<tgardner> ogra, I thought udebs were pulled across the net during boot
<ogra>        net)
<ogra>                 copy_modules_dir kernel/drivers/net \
<ogra> maverick just copies the dir
<ogra> instead of looping over a manually maintained list of modules
<ogra> tgardner, not on an installed system
<ogra> udebs are only used by the installer
<tgardner> ogra, how are PXE images prepared?
<ogra> for an installed system the NIC drivers need to be in the initrd for netboot
<ogra> PXE pulls kernel and initrd and executes them
<ogra> the initrd reads the server data from DHCP and mounts the rootfs after bringing up the NIC
<tgardner> ogra, ah. how can we prepare PXE initrd's without polluting the normal initrd ?
<ogra> we cant
<ogra> you can either netboot without initrd and need to have the driver compiled in monolithic or use an initrd and have the driver in the initrd
<tgardner> adding drivers impacts boot times for the general user.
<ogra> you could make adding the kernel/drivers/net subdir optional and only copy it into netboot initrds
<ogra> seems since maverick we copy the whole dir
<ogra> up to lucid the lisz from http://paste.ubuntu.com/542012/ was used
<ogra> *list
<ogra> maintaining the list was massively error prone
<tgardner> ogra, indeed.
<ogra> so i think that was the reason for just copying the dir
 * jjohansen lunches
<tgardner> pmatulis, adding to that list is probably the way to go for Lucid.
<ogra> but that will likely add a lot of unused additional cruft and bloat your initrd
<pmatulis> tgardner: so basically i edit the file and rebuild the initrd?
<ogra> yes
<tgardner> pmatulis, yep
<pmatulis> tgardner, ogra: thanks.  i guess the module itself is just 'ar8131'?
 * ogra doesnt know
<tgardner> pmatulis, I don't think so. I thought it was ath1c or something. whats the PCI ID ?
<ogra> well, for the installer you will need it in a udeb too
<ogra> the initrd change only helps for installed systems
<pmatulis> ogra: whoops
<tgardner> ogra, if its atl1c then its already in a udeb
<ogra> (and for the live image, but you would need to recreate the casper initrd for that)
<ogra> the bugs isnt really clear what the user did
<ogra> one comment talks about a PXE netinstall, the other about booting a live image from USB
<ogra> for alternate you definitely need a udeb, for live and for installed netbooting systems you need the hook-functions change and a new initrd
<pmatulis> ogra: just pxe is what i'm interested in
<ogra> PXE is the underlying boot protocol ;)
<ogra> it loads an initrd in all cases, in the case of the alternate installer the initrd needs to contain the right udeb
<ogra> in case of an installed netbooting system the driver needs to be listed in the "net" section of the auto_add_modules function in hook-functions
<pmatulis> ogra: not sure why you're talking about 'installed netbooting'.  i'm just trying to install *by* netboot.  i'm prolly missing something
<ogra> pmatulis, then you want the udeb 
<ogra> if you want to install a system that uses an nfsroot you want the other solution
<pmatulis> ogra: where can i find it and what do i do with it?  :)
<ogra> PXE is just used to boot either of them ;) 
<ogra> talk to 
<ogra> #ubuntu-installer 
<ogra> tgardner said the modules is already in an udeb so it might be that this udeb isnt included in the installer initrd
<tgardner> well, we haven't established which driver its actually using.
<pmatulis> ogra: ok, so a udeb and the change to initrd (the net list)?
<ogra> for a proper fix we should do both, yeah
<pmatulis> ogra: just looking the necessary bit for my case
<ogra> for your installer fix you only need the udeb and need to make sure the udeb is included
<pmatulis> ogra: alright
 * pmatulis goes to hunt for a udeb and what to do with the bugger when he finds it
<ogra> make sure to know the actual .ko name first 
<ogra> then ask in the installer channel
 * ogra is officially on vacation, you just catched me while checking mail ;)
<JFo> well, have a great weekend folks
#ubuntu-kernel 2010-12-11
<kakashi_> can anyone help me to patch a 2.6.35 kernel with RTlinux patch??
<jeremyA> I just upgraded linux-image-server-lts-backport-natty to 2.6.37-9.9~lucid1
<jeremyA> grub won't recognize it -- it swears its a xen kernel
<jeremyA> nevermind, I read the docs, filing a bug
<m4t> anyone know what changes to kernel linker scripts are as mentioned in: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/673236 ?
<ubot2> Launchpad bug 673236 in linux (Ubuntu) (and 2 other projects) "maverick toolchain producing unbootable (hanging) kernels (affects: 2) (heat: 118)" [Undecided,New]
#ubuntu-kernel 2011-12-05
<ppisati> morning *
 * smb drags himself in...
<smb> morning .+
 * smb hopes the second cup of coffee does help more than the first one...
 * apw looks about bleariliy
<smb> apw, Feel any better than Friday?
<apw> yep in one piece today
<brendand> apw - were there any significant changes to wireless in this -proposed kernel?
<brendand> for oneiric
<smb> brendand, there is a changelog for that... ;)
<apw> brendand, i would be supprised if there was any big changes at all
<apw> brendand, i guess it is a bigger question what is your new problem
<brendand> apw - both of the laptops we're testing that have a 'BCM4312 802.11b/g LP-PHY', the wireless card is acting up
<apw> are they using wl ?
<brendand> apw - lspci -vv
<brendand> http://paste.ubuntu.com/760260/
<apw> so what is the symptom ?
<apw> brendand, so does the machine have wl binary direvers installed ?
<brendand> apw - ok. i think it's likely we need to account for the case where a system has to have the binary drivers installed
<brendand> apw - i'm guessing this is one
<apw> brendand, so we don't know the machine worked in the current configuration on the old kernel?
<brendand> apw - oh, it's certified so it worked. it seems that you're saying this card requires for binary drivers to be installed though? that would have been done during certification but not necessarily during the automated run
<brendand> apw - actually, i'm quite sure it wouldn't have been done during the automated run since we don't have anything in our install scripts to do that
<apw> brendand, well actually what i though you were telling me was that it worked in this test rig before this -proposed kernel and does not with only the kernle changed
<brendand> apw - that's what i was thinking until you mentioned about the binary drivers
<apw> brendand, i was asking about the wl driver as i would expect wl installed on that card, but some broadcom stuff does work without
<apw> brendand, so its a question not a statement from my point of view
<brendand> apw - ok. so the wl driver is not installed for the automated test run, but it was when the system was certified
<apw> brendand, ahh then that may well make sense then
<brendand> apw - i'll get the lab engineer to rerun the tests with the wl driver installed. it should probably work then
<apw> sounds good
<ledzgio> hi all
<apw> hi
<ledzgio> anyone can help me with a net card atheros AR8151 on ubuntu 11.10?
<apw> whats the issue?
<ledzgio> yes
<ledzgio> this card gets disconnected when I download with torrent for example at high speed
<ledzgio> and I have to rmmod module (that is atl1c) and modprobe it again
<ledzgio> i have kernel 3.0.14
<ledzgio> with ubuntu 11.10
<ledzgio> i have googled a lot
<ledzgio> but no luck
<ledzgio> toughts?
<apw> i've cirtainly not heard of specific issues with atl1c recently, other than issues i had on natty with it failing to detect carrier at all
<apw> since then i'd not had issues with the atl1c i have.  that said i primarily use that machine on wireless
<ledzgio> I cannot understand because if I surf on internet it works normally
<ledzgio> when I donwload with deluge at high speed it gets disconnected
<ledzgio> mine is ethernet
<ledzgio> I dont have wireless on my desktop
<apw> that isn't entirly unexpected, high load is likely to trigger any latent issues
<ledzgio> and ythe wireless module is disabled by default in blacklist
<apw> indeed, i was saying i don't use the ethernet on that machine much and not under high load
<ledzgio> ok..may I try some workaround?
<ledzgio> it happens even if I reduce the speed of deluge
<ledzgio> after a while it disconnects 
<ledzgio> i can send you the dmesg log of the error
<apw> well it would make more sense to file a bug with the information
<apw> as for debugging it, you could try running a later kernel, that may be fixed
 * apw checks if cw has ethernet too
<ledzgio> I have tried the 3.0.14
<ledzgio> how can I try an experimental kernel?
<apw> yeah i am more thinking a 3.2 based kernel
<ledzgio> how can i try a 3.2 kernel?
<ledzgio> should I compile it or just add some ppa?
<apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
<apw> those are just for testing, but if it is fixed later we have more hope of finding the fix
<ledzgio> ok so just download the deb files and install them with apk?
<apw> with dpkg
<ledzgio> yes sorry dpkg
<ledzgio> ok
<ledzgio> I'll give it a try
<apw> i'd suggest a 3.2-rc4 for example
<apw> as if its not fixed there, its not fixed upstream
<ledzgio> ok..is there a way to check some changelog to verify that 3.2 kernel has some change on my card?
<apw> the upstream git repository has every commit made, and we are talking from v3.0 -> v3.2-rc4
<ledzgio> url?
<apw> there doesn't seem to be much if i am honest so your chances are low
<ledzgio> ok...I may think to buy a new net card
<apw> lucky you, mine is builtin
<ledzgio> mine too, I have never had luck with builtin cards
<ledzgio> :)
<ledzgio> thank you anyway dude
<apw> good luck
<ledzgio> sorry last question
<ledzgio> the most supported lan cards are those with realtech chipset?
<ledzgio> cause if I have to buy a new one...I want to buy one well supported
<apw> i think a better answer is _older_ cards are best supported, i have had good luck with older RTL lan devices, and with intel cards
<apw> i have a BCM in my dell box, and that works ok on ethernet
 * apw notes that all the worst wifi stuff is made by the people who make some of the least problematic ethernet cards, how odd
<ledzgio> ok thank you
<apw> Sarvatt, ok in theory at least on the incident of lp losing its mind we should just move the upload files aside for manual handling
<ogasawara> apw: just curious how you went about doing your test builds for armhf?
<apw> ogasawara, heh you don't want to know ... 
<ogasawara> apw: I'm assuming it's a bit of a hack?
<apw> ogasawara, i symlinked the armel compiler crosscompiler binaries to the armhf binaries in one of our chroots
<ogra_> you can use an armhf chroot inside an armel setup
<apw> ogasawara, and then cross compiled it there
<apw> ogra_, yeah, but you can't make one :)
<ogra_> or use the hf cross toolchain
<ogra_> apw, thats what we have ubuntu-core for ;)
<ogra_> it is one :)
<apw> ogra_, so are there armhf cross compilers now ?  in the arhive?
<ogra_> ask hrw, i think there is since oneiric
<apw> ogra_, ta
<apw> ogasawara, before i pollute you with my shit i'll figure out if there are official builds
<ogasawara> apw: ack
<apw> ogasawara, but in principle if it works for armel, and you do the same thing to hf as el it should be ok
<ogra_> yeah, especially on the kernel level the naming is plain for the package name
<ogra_> we could even just cp *armel.deb to *armhf.deb if the archive would allow that
<apw> tgardner, i see there are official armhf cross compilers for precise, could we get those installed in the i386 chroot
<apw> ogra_, it is annoying that we can't do that at times given the cost of makeing it
<tgardner> apw, yeah, I'll work on  that today
<apw> tgthanks
<apw> tgardner, ^^
<ogra_> apw, agreed, though in the end armel will be gone anyway
<ogra_> its only a temporary thing 
<apw> ogra_, "temporary" as in supported for 5 years |
<apw> ?
<ogra_> apw, heh, probably 
<ogra_> i hope not though ... hf looks pretty good already 
<apw> ogra_, do you think armel may go for precise?
<ogra_> if until feature freeze no disasters show up hf will be the 5 yearer
<ogra_> it wont go
<ogra_> but it wont be the supported arch
<ppisati> ah no?
<apw> so we pay the pain, which is no help really
<ogra_> we'll decide at FF based on how hf looks like
<ogra_> we all do, yes
<ppisati> when is feature freeze?
<ogra_> initially hf was expected to be brought up by linaro before oneiric is done
<ogra_> ppisati, iirc some time in feb
<ogra_> we currently all pay for the delay 
<ogasawara> ppisati: feb 16
<ppisati> ok
 * apw idly wonders what the heck software centre spends all its time doing when updating it sw catalogue
<ogra_> running apt-update-xapian-index i bet 
<apw> well it s
<apw> should be doing it quicker
 * ogra_ always has fun with it on his SD card driven machines :)
<ogra_> can easily steal you 1h of your day :)
<apw> man that sucks
<infinity> apw: Can I pick your brain?
<smb> sounds somewhat cruel...
 * ogasawara back in 20
<apw> infinity, yo go ahead ...
 * apw notes that OSDs appear on his right monitor regardless of whether that is connected to the display ... sigh
<infinity> apw: Hey.  So.  Trying to think about future-proofing lp-buildd for when we upgrade the buildds to precise.
<infinity> apw: And we almost certainly want to use the uname26 personality, since they need to be building sources all the way back to hardy that we won't want to fix.
<infinity> apw: But, in local testing, linux32 and uname26 seem to be mutually exclusive.
<infinity> apw: Is there a sane reason for that, or is it just because of the way they're setting the personality mask (ie: could it be rewritten to set both?)
<infinity> apw: I know nothing about personalities, and haven't looked much.  Thought I'd ask someone who I suspected might know.
<apw> infinity, i don't know off the top of my head, i have not really looked at the uname26 one.  i suspect it must be possible to make both active somehow
<infinity> http://mirror.linux.org.au/linux/kernel/people/ak/uname26/
<infinity> ^-- dirt simple.
<apw> infinity, well assuming 32bit comes from the personality bit limiting address space, they appear to be independant
<infinity> apw: So it might just be that linux32 is rewriting the entire mask and blatting uname26, or some such?
<apw> where do i find the source for linux32
<infinity> (Though I couldn't mix/match them regardles of the order I called them in)
<infinity> apw: linux32 is from util-linux.
<ohsix> doesn't it just change the personality the invoked program runs with
<infinity> ohsix: Yes.
<apw> infinity, so i suspect its because both just change the personality
<infinity> apw: Rather than masking it?
<infinity> apw: ie: they're overwriting each other's hard work?
<apw> infinity, ok in that sample uname26.c try changing the PER_LINUX to PER_LINUX32
<apw> and see if that on its own the does both
<infinity> adconrad@cthulhu:~/uname26$ ./uname26 uname -a
<infinity> Linux cthulhu 2.6.40-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 i686 i686 i386 GNU/Linux
<infinity> Lookie there!
<infinity> apw: Snazzy.
<apw> infinity, so yeah they are overwriting each other
<infinity> Kay.  Well, I don't necesarily even have to daisy-chain them for the buildd case.  I can just use this dead-simple uname26-32 deal and package it up.
<apw> so i presume we can inject our own version of linux32 when building against maverick and older
<infinity> But fixing linux32 to not override uname26 would be nice.
<apw> infinity, yeah i guess it'd have to look up the curent one and or in its stuff
<infinity> Or we could patch linux32 to take a -2 switch.
<infinity> apw: Anyhow, I just wanted to make sure it was possible, which you just proved.
<infinity> apw: I'm the util-linux maintainer, I can hack up linux32 to have more options.  Probably the sane way.
<apw> infinity, and that does sound like something we are going to need for what maverick and older i guess
<infinity> apw: Yeah, I'm going to land this all in lp-buildd and precise's util-linux sometime this week, so we don't forget and panic later.
<apw> yeah a good plan indeed
<tgardner> apw, armhf Precise chroot on gomeisa. still working on gcc-arm-linux-gnueabihf; deps are broken.
<apw> tgardner, oh as in a qemu emulator one is working ?
<tgardner> apw, seems to be
<apw> tgardner, most unexpected
<tgardner> apw, dunno why not. armel has been working for a bit
<apw> tgardner, and it should be identicle, so clearly there is no hope of it working
<infinity> Oh, there's an armhf chroot on scheat now too, if you need a porter box.
<infinity> Except that lamont hasn't install rapt...
<infinity> So, no apt-get fun.
<infinity> I'll chase that up. :P
<lamont> meh
<lamont> I'll do that once I hit town
<apw> jibel, ok i think there is a significant portion of needing lots of CPU up the guest for this problem, i remained unable to reproduce it, moved to a much bigger test box, and couldn't not reproduce it making it hard to install a test VM
<apw> jibel, anyhow, making progress slowly now
<tgardner> ogra_, whats the story on the armhf cross tools? it looks like it was uploaded 8 weeks ago and FTBS'd. https://launchpad.net/ubuntu/+source/gcc-4.6-armhf-cross - what are you using ?
<jibel> apw, I can give you access to the box if you need
<apw> jibel, now i've switched hosts i seem to have a good reproduce by using a VM image i copied over from the slow box, and with your copy scrip
<ogra_> tgardner, i always build natively, thats why i pointed for questions to hrw
<tgardner> ogra_, who is hrw ?
<ogra_> marcin juskiewicz
<infinity> tgardner: I guarantee that cross toolchain will be vaguely wrong even if it does build.
<infinity> tgardner: I'll have to have a poke at it when I find some free time from doing the native stuff.
<tgardner> infinity, we mostly use it for build testing.
<infinity> (Though vaguely wrong might not matter for kernels, I guess)
<infinity> The tools it generates won't run, but the kernel will.
<apw> tgardner, i found that symlinking the binaries for the armel one to armhf's abi name worked, see the precise-i386 chroot on tangerine, /usr/bin
<tgardner> apw, the king of ugly hacks :)
<apw> at least let me fake builds, not sure you'd want to use the result, but at least i could check the packaging
<tgardner> apw, well, now you've got native armhf, so go slowly...
<apw> for anything other than the kernel it'd not actually be armhf of course :)
<apw> tgardner, yeah i'll punt a build at that chroot and see how long it takes
<apw> tgardner, fun vv
<apw> util/hist.c: In function 'hists__fprintf':
<apw> util/hist.c:1223:1: internal compiler error: Segmentation fault
<tgardner> apw, gotta love that
<apw> (building the tools, not that i care about those one iota)
<bjf> tgardner: which version of arm do we support for the buildds ?
<apw> bjf, do you mean which h/w are used as buildds?
<tgardner> bjf, imx51 I think
<bjf> tgardner: which ubuntu series ? lucid ?
<tgardner> bjf, lamont is the ultimate source
<apw> bjf, if so that is fsl-imx51 running the lucid/fsl-imx51, and pandas running various releases from natty up i believe running ti-omap4
<apw> infinity, we are running a mess of versions on the pandas arn't we
<brendand> tgardner - just got your note about the wireless_scanning test. just to let you know, this isn't a new one, we've been using the same test in certification for a while
<brendand> tgardner - i mixed up my tools. it's using iwconfig to find the interface name and iwlist to scan
<brendand> tgardner - should we not be using that?
<tgardner> brendand, iwconfig/iwlist are about to be deprecated. I think Precise is likely the last release. kernels subsequent to 3.2 will likely _not_ wotk with iwconfig/iwlist since the ioctl interface is getting deprecated.
<brendand> tgardner - probably from our point of view it's best to use NetworkManager, isn't it (i assume NetworkManager will use whatever is correct at the back end)?
<infinity> apw: I'm not sure.  You'd have to ask lamont.
<tgardner> brendand, NM uses the same interfaces as iw, e.g., netlink socket AFAIK
<brendand> tgardner - we'll look into updating it for this release. i'll file a bug in checkbox for it. for now the older releases are using iwconfig/iwlist though
<tgardner> brendand, tahts fine.
<brendand> tgardner - now that i've got your attention, i was hoping to get your input on one test that i've written, which monitors the state of the connection over a period of time (i think we agreed 5 minutes at UDS)
<tgardner> brendand, OK
<brendand> tgardner - what sort of bad behaviour do you usually see when there are regressions of this kind? does the connection actually go down?
<tgardner> brendand, either that, or the connection rate drops to 1Mbit or slower
<brendand> tgardner - and does it usually only happen under a high load?
<tgardner> brendand, high loads or noise on the channel
<tgardner> which is hard for you to reproduce.
<tgardner> I would just test a high load and set a floor for the expected throughput.
<brendand> tgardner - ok
<tgardner> brendand, remember that each phy setting (b,g,n) have different throughput expectations.
<brendand> tgardner - any tips on tools to measure throughput?
<tgardner> brendand, I use iperf
<vanhoof> brendand: had the same q last week
<vanhoof> brendand: ended up with" iperf --client 172.31.1.1 --time 300 --interval 30
<vanhoof> --format M"
<vanhoof> brendand: http://paste.ubuntu.com/760626/
<brendand> does anyone know if this bug was hardware specific? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/899165
<ubot2> Launchpad bug 899165 in linux "uvcvideo: Failed to submit URB 0 (-28)." [Medium,In progress]
<tgardner> brendand, looks like it is a generic EHCI bug
<tgardner> of course, you only see it with isochronous connections
<cking> mjg59, we've been  crowd-source testing your PCIe ASPM patch ( https://wiki.ubuntu.com/Kernel/PowerManagement ) and we're wondering if you know of any devices that may misbehave with this fix?  From the limited tests we've got so far it looks like a win 
<sforshee> tgardner, wondering if you know the answer to this question. If a wireless card indicates that rfkill is applied, is that due to assertion of an external signal?
<sforshee> i found a mini PCIe pinout that shows a "wireless disable" input signal
<mjg59> cking: Nope, by the looks of it the machine responsible for the original patch should still work with this
<tgardner> sforshee, its been awhile,. but I think its typically because the wifi driver has registered with the RFKILL API and is told by the platform rfkill driver that its been disconnected.
<cking> mjg59, OK, we were worried it may enabled PCIe ASPM on some devices which may be problematic, but I suppose the new behaviour is more Windows like and hence will be less problematic in a sense
<sforshee> tgardner, I'm not asking about the kernel support for rfkill, but what causes a generic wireless card to tell the driver to disable wireless. As an example, iwlagn has an interrupt status bit that will cause it to apply a block to the device (see iwl_irq_tasklet). I'm wondering what triggers the card to tell the driver that it should disable wirless.
<tgardner> sforshee, dunno, but it seems like there must be some kind of HW support if its in the interrupt handler.
<sforshee> tgardner, yeah, obviously. I'm just wanting enough evidence to conclude that something external to the card causes it to happen, as I suspect is the case. Thanks.
<tgardner> sforshee, http://madwifi-project.org/wiki/UserDocs/MiniPCI
<tgardner> seems pin 13 might be dedicated to this function
<sforshee> tgardner, that's helpful, thanks. Now if I could only reproduce the problem so I could play with it ...
<tgardner> sforshee, you could "Sellotape over pin 13" as suggested.
<sforshee> tgardner, right, but since I can't reproduce the problem I wouldn't be able to tell whether or not it helps
<tgardner> sforshee, ah, I thought you were having trouble getting the radio tuned on
<sforshee> tgardner, no, this is pgraner's netbook. I can't reproduce his sudden disconnections no matter how hard I try
<tgardner> sforshee, he was doing a bunch of disk copying over USB. have you tried that ?
<sforshee> tgardner, not with USB. I generated a bunch of disk, network, and cpu activity (and got the temperature pretty high), but wireless remained stable
<sforshee> i'll try that after i get back from lunch
 * sforshee -> lunch
<manjo> I have a 3TB disk that has 512 logical / 4096 physical sector size, when I use disk partition utility in 11.10 I get a warning that my partition is misaligned by 3072bytes and will impact performance ... any one have any suggestions on how I can fix that ? 
<manjo> this is on a uefi 2.3.1 system 
 * tgardner -> lunch
<lamont> apw et al: armel builders are running (generally.. don't hold me to it): lucid (bbg3), maverick (beaglexm), natty (panda)
<lamont> ppc is lucid
<lamont> or maybe "lucid with maverick kernel" - don't remember.
<lamont> everything else: hardy
<lamont> given the slew in the armel family, I would be willing to entertain rolling all of arm to natty, if that makes people's life happier
<lamont> the roll after this will be to precise, post-release, assuming that the kernel/distro folks are willing to support building hardy on precise for a little while
<apw> lamont, that is an interesting issue indeed, infinity and i were talking about some of the issue the kernel version bump will trigger
<apw> lamont, i wonder if there is value in getting something setup to allow us to test teh combinations
<lamont> part of the reason they're still on hardy is because of dapper (now moot).
<apw> lamont, particularly the xen side of things, as thats all shiney and new and may be broken
<lamont> apw: the general rule is "most recent LTS, unless there's a really good reason otherwise"... hence maverick/natty for hw support
<lamont> xen is the other reason
<apw> lamont, any word on when the old beagles will die?  as they are not on a supported release now
<lamont> apw: beagles are fine (*aceae.buildd) - bbg3 are the dead ones that infinity won't let me bury
<lamont> seems there's a huge backlog of armhf builds to finish first
<apw> :)  one or two i am sure, is there a plan to rip'em'out after thats caught up ?
<herton> hggdh, do you know what is the status about linux-lts-backport-oneiric: 3.0.0-13.22~lucid1? (bug 885468). It's in QA for some time
<ubot2> Launchpad bug 885468 in kernel-sru-workflow/regression-testing "linux-lts-backport-oneiric: 3.0.0-13.22~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/885468
<hggdh> herton: finishing it now
<TheLynx> hi
<TheLynx> just a very short question... Does Thin provisioning is supported by dm-crypt? Or in other words is Thin provisioning a real virtualisation von every block of a device?
<apw> TheLynx, not sure i know what thin provisioning means here, got a pointer to the meaning?
<apw> though as it is virtualisation, #ubuntu-server may know better
<TheLynx> http://en.wikipedia.org/wiki/Thin_provisioning it is used for iSCSI in my case
<apw> i am unsure if you can have copy-on-write disks in device-mapper directly but non-fully populated disks and copy-on-write disks are common features of xen and kvm virtualisation at least
<TheLynx> hmm this sounds good
<TheLynx> at least, thank you for your help maybe someone from the open-iscsi team can answer this
<Eimann> morning
<Eimann> is there a reason why iwlwifi doesn't get build as a module in the daily/3.2 builds?
 * herton -> eod
<hallyn> any good suggestions for debugging acpi_wakeup_address?  (apart from printk, which I'll resort to if i have to)
#ubuntu-kernel 2011-12-06
<slangasek> bjf[afk]: so bug #900522 is a fun bot corner case.  If I reboot to the new kernel, it's possible I won't be able to reproduce the bug at all because I don't know how the kernel routing table has gotten into this state to begin with ;)
<ubot2> Launchpad bug 900522 in linux "cached route that can't be removed with 'ip route flush cache'" [Low,Incomplete] https://launchpad.net/bugs/900522
<slangasek> bjf[afk]: do you know who might be interested / able to help debug the kernel side of this?  If not, I guess I'll just reboot at some point and probably close the bug
<bjf> slangasek: tgardner would probably be the best but i'm not sure 
<bjf> slangasek: you can add the "bot-stop-nagging" tag if you want
<slangasek> I know... I'm just not sure that's a useful thing to do in this case :)
<bjf[afk]> slangasek: agreed
<smb> morning .+
<ppisati> morning
 * apw yawns
 * abogani waves all
<abogani> BenC: ping
<apw> ppisati, when you have ti-omap4 'fixed' i can probabally test it, so push it up somewhere i an grab it
<ppisati> yep
<ppisati> it's baking...
<apw> chocolate cake ?
 * smb gets hungry
<ppisati> uhmm... i should make tiramisu one of this day... :)
<apw> bring it to rally
<ppisati> uhm...
 * apw likes tiramisu
<smb> Guess it would count as "liquid"
 * smb +1
<ppisati> actually if i froze it but then it will turn crap i guess...
<apw> heh yeah i bet it would, sigh
<apw> i know we can just have a sprint at paolo's place
<smb> Right, have a look at his new flat
<apw> he can sleep on the floor
<ppisati> but before the sprint i'll have to disassemlbe all the boxes... way too hard... :)
<apw> we can use the boxes as desks, no problem
<smb> No problem we are good at disassembling...
<smb> ...assembling is another problem
<cking> especially when the pieces have been lost and the manuals are wrong
<smb> the what?
 * apw swings his hammer widly "this screw will go in this square hole I am sure"
 * cking notes that when ever he reassembles furniture there is always one critical bolt or screw missing 
<apw> cking, though that is probabally triggered by offspring
<smb> cking, Can't be critical if things still hold together
 * apw notes wobbly is ok
<smb> Remembers a shelf that survived quite a bit of time after moving and having a handful of pieces of unknown destination in my hands
<cking> DIY kernel team style sounds a bit hacky to me
<apw> cking, we could do your extension if you like
<smb> back to the essentials
<cking> back to rubble more like
<apw> always need rubble
<cking> not when I need to live in it
<smb> hey , things usually do work and hold together
<cking> not with kids about
<smb> Though in that case those few screws don't help much either
<apw> na just more sharps for them to find
<cking> "..but daddy you made it and it's your fault" is what I expect to hear
<smb> cking, It is your fault anyway
<cking> yeah, that's very true
<apw> you should not buy anything, so there is nothing to break
<cking> I can imagine being a hermit...
<apw> cking, it'd be cheaper
<cking> no beer though
<apw> those hermit types are the ones who invented beer
<ppisati> beer was invented by monks AFAIK
<ppisati> apw: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap4
<ppisati> apw: last commit, the kernel compiled here
<apw> ppisati, ok ta, will test
<ppisati> back in 10mins
<apw> ppisati, where are we with bug #861296 ?
<ubot2> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
<ogra_> apw, i think we missed the two weeks SRU window (at least thats what i gathered from GrueMaster's complaints yesterday)
<ppisati> should be in every omap4 and imx51 branch
<ogra_> (ask him for more detail)
<ppisati> except for P/omap4
<ppisati> which is based off O/omap4
<apw> ppisati, ok so it should be available, and it is with stable to roll out
<ppisati> so, next sync with will get it
<ppisati> yep
<apw> ogra_, as its for the buildds we could get them a kernel potentially out of band i guess ?
<ppisati> we did it indeed
<ogra_> i guess lamont already runs it (not sure though, second hand info)
<ppisati> i handed custom kernels to #is with that fix way back
<apw> ok then we are good
<ogra_> apw, but GrueMaster needs to test them again 
<ogra_> to have them in the next SRU batch 
<apw> yep, there is always new batches to test
<ogra_> (which is quite annoying for him)
<ppisati> apw: with the armhf i'll sync with O so P will get that fix too
<ogra_> apw, well, he tested them two weeks ago already
<apw> ogra_, well there would be a new kernel to test next two weeks whether that is in or not
<apw> as there will be security fixes in those kernels every cycle as well
<ogra_> sure
<apw> so i don't think there is any more or less testing to do
<apw> ppisati, ok good news, my full build of your branch looks good
<ogra_> well, its just bad if he is told to test something that doesnt get uploaded in time and then he has to start over
<ogra_> the test means to build java stuff which is really time consuming
<apw> ahh i see, sorry about that then
<ogra_> yeah, not to me :) ...
 * ogra_ is just the cassandra here :)
<apw> ppisati, is this branch 'good' ... do we want it pushed and uploaded?
<ppisati> apw: not yet, let me sync it with O first
<ppisati> apw: then i'll send the entire batch of changes
<apw> ppisati, ok, back to you :)
<apw> ogra_, are you waiting on armhf ti-omap4 at all ?
<ogra_> yep
<apw> how much is it holding you up
<ogra_> omap4 and ac100 kernels are the last nits missing before we can start armhf images
<ogra_> *bits
<ogra_> everything else is ready 
<apw> ppisati, how long i the resync going to take ?
 * apw is considering whether to upload the unresynced version
<ppisati> half an hour, one hour max
<apw> oh then... that is an easy decision
<apw> if it is going to be today then cool
<apw> ogra_, are you on the hook for ac100
<ogra_> apw, infinity is just testbuilding a changed package 
<ogra_> should be uploaded once he gets up again
<apw> ok cool, ppisati poke me when you are done so we can expedite this thing into the queue
<ogra_> my expectation is that we can build hf images weekendish ...
<apw> ppisati, have we uploaded ti-omap4 to P at all yet ?
<ogra_> once i think
<ogra_> yup, on nov 21
<apw> oh now i see why i am confused
<apw> infinity, did you just invent a linux-meta for ti-omap4 ?
<ogra_> apw, he uploaded it ahead of the kernel it seems, yep
<apw> but where the heck did he get it from
<ogra_> (there was a conversation in #ubuntu-arm about it )
<ogra_> <infinity> ppisati: I uploaded meta that assumes 1401 will build on armhf.  So, now I just need a kernel. ;)
<apw> ogra_, great, that just throws all the kernel team process into a cocked hat
<apw> ogra_, and is liable to bollox anyone who is an upgrader from oneiric
<ogra_> yup
<ogra_> dont blame me :)
<apw> infinity, *slap*
 * apw just has no idead what infinity has been doing to ti-omap4 meta, this is an utter mess
 * apw stomps off to sulk in the corner
<infinity> apw: Invent it?  It's always been there.
<apw> infinity, you didn't use one of our source trees to make it
<infinity> apw: All I did was add armhf to it (and rev it to the correct ABI)
<infinity> apw: Uhh.
<infinity> apw: It was apt-get source linux-omap4. :P
<apw> so now i have to unf*ck all our trees
<infinity> apw: It's been in the archive for eons.
<apw> yeah the package is fine, its that we nolonger have a tree we can build meta from
<infinity> apw: And I based it on what was in the archive, not much to "unfuck".  debdiff, apply, done.
<apw> so if i naievly uploaded the top of ours, your changes would go poof
<infinity> apw: See above, then?
<apw> infinity, but the bigger issue is you shouldn't upload meta before the binaries are built
<apw> as now anyone with the thing installed is liable to end up with no kernel and in a heap of trouble
<infinity> apw: I uploaded it for armel, where the binaries have been built for weeks but no one updated the meta.
<infinity> apw: No one has armhf installed with a kernel, cause there are none.
<infinity> apw: (-meta was out-of-date on armel, and has been for a long time)
<apw> ok then we are ok
 * apw whines
<infinity> apw: Whine less?
<apw> na bad for me
<apw> maybe i could be andy whine-house
<ogra_> want to join the arm team ?
<ogra_> :P
<apw> ogra_, heh no you are all mad, i'd not fit in
<infinity> apw: Is it really that tough to apply my delta to git?  Cause, I can provide you with a branch to merge, if you want.
<infinity> apw: I just have no zinc access anymore to actually commit it.
<apw> infinity, nope its not hard, i am moaning about not knowing as i nearly broke things
<infinity> apw: Meh, if you broke things, I'd just whine right back. ;)
<apw> :)
<apw> i would hope so too
<ogra_> whiners 
<ogra_> all you !
<infinity> (And, for the record, anyone who uploads anything without checking the current state of the archive, and diffing current:new should probably rethink their workflow)
<apw> infinity, that'd be us for sure :)
<infinity> I figured. ;)
<apw> infinity, i have also taken a note to slap tim for uploading the kernel and never uploading -meta to match
<apw> well actually, i clearly do check cause i just noticed :)
<apw> infinity, aside of that, meta looks good
<infinity> S'ok.  I'll go back to mangling unsupported kernels now. ;)
<apw> ac100 i assume
<infinity> Yeah.
<apw> if you have a tip somewhere i can test build it before you upload it, takes about 10mins
<apw> (test building the packaging as it were)
<ppisati> ok, pull req sent to the kernel ml
<infinity> Oh, it's already building on my Panda.
<apw> ppisati, ok will do
 * ppisati goes to find some food (aka lunch)
<apw> infinity, well it takes a lot less time my way
<infinity> I don't do kernel iterations often enough to have a cross environment set up for it.  Don't care.
<infinity> It's an excuse to get caught up on Dexter.
<ogra_> heh
<apw> heh ok, i found building udebs painful as it takes sooo long to fail
<ogra_> we dont ahve udebs for ac100 
<apw> ahh then you are likely to work then
<ogra_> (i think ... unless jani recently added them)
<infinity> Also, you're assuming it will fail.
<infinity> You should know me better than that. ;)
<ogra_> it cant fail, its maintained by the arm team :D
<infinity> ogra_: We have udebs for ac100, yes.
<ogra_> ah, thats new then
<ogra_> i explicitly didnt build them when i maintained it
<ogra_> but jani moved to git and all ... using the ubuntu sauce etc 
<infinity> Well, sort of.
<ogra_> so i guess we inherit udeb building 
<infinity> It's more linaroish than ubuntuish.
<ogra_> yeah
<apw> ick :)
<ogra_> i originally based on n900 ... he moved to some generic linaro ways from that
<ogra_> but added the sauce
<apw> ogra_, i have often felt the right thing is to take linaro tip and merge our master into it each time to make the new version
<infinity> I miss being a lot less confused by kernels.  When that all built from the same source package, and x86-centric people whined that merging patches with Sparc was "too hard", so they just didn't, and then they whined when it would FTBFS.
<infinity> Good times.
<ogra_> apw, well the prob is that linaro refuses to maintain tehir kernels after a release ... and they release monthly
<apw> infinity, its cirtainly different now, i think i've lived through it all, quite a ride
<apw> ogra_, oh i know, you'd be merging their original tip into our tip with cves and hoping that the result worked
<ogra_> we could go from snapshot to snapshot ... but as soon as *we* release there isnt a way to get SRUs or security fixes
<apw> ogra_, the one thing i am fully aware of is the amount of work their cause me and my arm peeps
<ogra_> yep
<apw> we essentially maintain > 2x the kernel revisions we want to cause of this crap
<infinity> apw: I think we still need some clever way to keep the packaging more centralised and sane than it currently is.  And the secret sauce.  And all that jazz.  Even if we don't want one massive source package that takes forever to build and has (potentially) conflicting patches.
<infinity> apw: Like, some shiny tool that will essentially roll a proper source package from git, with grafted branches as needed.
<apw> infinity, care to be part of a discussion at rally about ideas on how we can improve things
<infinity> apw: So they all look and act the same.
<infinity> apw: Yeah, perhaps.
<apw> that has been suggested and the AAs went mad that the source should be the source
<ogra_> hard to do if you have as many different versions as linaro has though
<ogra_> (read: BSP kernels)
<apw> and we arn't allowed to backport the packaging changes to older releases
<ogra_> iirc there are still boards they run with .35
<apw> and .. 200 other complaints against anything we have suggested
<infinity> apw: I mean, for Linaro-maintained kernels, we can't do as much, and that's fine, but anything that's theoretically maintained by the Ubuntu kernel team should all match with packaging, enforce, etc.
<apw> infinity, and we'd do that in an instant if the sru team would take the harmonised packaging
<infinity> apw: The source is never the source.  I wonder if maybe some wires got crossed in describing how to do such a thing.
<apw> but we did try and they said flat no
<infinity> apw: I mean, heck, nothing that uses autoconf is "pristine source", upstream always generates configure, etc.
<apw> infinity, yeah, its the debian packaging changing in old releases they won't let us do
<infinity> apw: I don't see how SRUs relate.  That's just different (and stagnant) branches.  You always have to branch at a stable release.
<infinity> apw: Anything "auto-generating" packaging in a stable release should be deterministic anyway.
<ogra_> the past is whats creating the workload ...
<apw> well if we commonise, we want to commonise everywhere no?
<apw> else the old stuff is different and the world is more of a pain than now
<ogra_> while we can change it for the future, kernel team is stuck with the past stuff
<infinity> apw: (ie: if I rerun autotools across a source package with the same versions of autoconf, libtool, etc, it won't change the output)
<apw> right
<infinity> apw: No, changing the past is a no-go.  But that doesn't perclude improving the future. ;)
<apw> a ripe discussion for rally
<apw> infinity, well except where the new differs from the old in semantics as that creates mantenance burden
<infinity> apw: But let's have an informal beer on Sunday night at the Rally and see if it comes to fisticuffs and/or agreement before you care about my opinions on the matter. :)
<apw> and right now most of the burden is on people making new branches
<apw> infinity, sounds good to me
<infinity> I'll go work out.
<abogani> BenC: About "Reviving Ubuntu PowerPC"...
<abogani> BenC: What systems will be used as reference in this effort?
<infinity> abogani: My PowerStation, for one. ;)
<smb> herton, I discovered this morning that I had missed one change in the upstream patches which has a related bug in the ec2 deviated files (had been missing two files in the deviations file). I suppose the correct way forward is a completely new tracking bug and to invalidate/mark duplicate the old one. Or is there another option?
 * cking grabs some food
<herton> smb, yes, doing a new tracking bug, duplicating the old against the new is ok, no other way
<smb> herton, ok, will follow-up with that then. thanks
<bullgard6> How is a Â»kernel updateÂ« defined? Is the term Â»kernel updateÂ« a technical term meaning something else than just any change in the kernel code to reflect a newer development?  So far I did not find a definition when googling. How can one write: "The package linux-generic is a kernel update"? 
<apw> generally when we talke about a 'kernel update' we are talking about an updated package containing the kernel
<apw> i don't think i would ever write "the package linux-generic is a kernel update"
<bullgard6> Ah!
<apw> the package linux-generic trigers your kernel to be updated
<apw> by always depending on the latest kernel package available
<bullgard6> apw: Thank you very much for explaining.
<apw> np
<apw> ppisati, did you get an email in response to my upload
<ppisati> apw: i got the "applied" email
<apw> ppisati, did you get anything from launchpad about it
<ppisati> nope
<apw> bloody lp
<infinity> apw: The librarian's down.
<apw> infinity, does that break uploads?  presume so
<infinity> apw: Since they have to be stored in the librarian, yeah.
<infinity> apw: They should be tucked away in queues, waiting to flush when it's fixed, though.  In theory.
<apw> infinity, yeah heres hoping ...
<tgardner> jsalisbury, do you have a way to search for bugs against linux-meta ? In almost all cases they should be changed to linux (unless they really are meta package bugs)
<ppisati> apw: P/omap4 is in and it's building
<jsalisbury> tgardner, yes, I can do a search on them.  I'll do that and move them over linux
<ppisati> apw: but the armhf version says "need building"
<ppisati> seems it's queued
<ppisati> gut
<apw> ppisati, yep all good, given the state of the librarian its amazing its building at all
<ppisati> apw: but since we don't have any armhf builder, how does it build?
<jsalisbury> herton, bjf, Request for a patch backport to oneiric:  bug 899598
<ubot2> Launchpad bug 899598 in linux "[Patch] The resolution of Display Port for intel cards is limited" [Medium,Triaged] https://launchpad.net/bugs/899598
<herton> jsalisbury, we will take a look
 * herton -> lunch
<apw> ppisati, yep we do, we have about 10
<ppisati> ah cool
<apw> ppisati, we actually have more than we have armel right now, but then we have 1000s of packages to build
<ppisati> i see
<jsalisbury> herton, thanks
<ogra_> ppisati, apw, infinity can raise the priority for the armhf build
<ogra_> (or any other archive admin)
<apw> ogra_, yep, its already started building too
<ogra_> ah, k
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
 * apw wimpers
 * ogasawara back in 20
<GrueMaster> ogra_, apw: My issue on kernel SRU yesterday was that a much needed feature that was tested in various kernels a couple of weeks ago didn't get included with this SRU cycle, meaning that people that need these fixes need to wait until almost EOY for them.  Or they run with a test kernel and not get any of the SRU updates in this release. 
<GrueMaster> Just to clarify.
<ogra_> yeah, i think i got that across to apw and he even apologized
<apw> yep and i suspect that is because the submitter was on holiday when he results came in, and appoligies for the testing effort that is wasted as a result
<apw> separate to the inconvienience, it sounds like we need some updated test kerenls as well
<apw> i am assured the fix is applied now though i can't say i have checked
<ogra_> well, the important part (buildds) is fixed anyway already ... essentially getting it into the archive is rather the formal afterwork :)
<GrueMaster> For the record, I'm not trying to stir up that argument again, just clarifying where I stood.
<apw> GrueMaster, nope and i am not seeing it as a moan either
<GrueMaster> Good.  :)
<apw> and had i realised that it was a 2 day effort to test it i'd have been more careful to shepherd the fix
<apw> i tend to assume its boot and run for a couple of minutes and know, whcih isn't at all the case for this puppy
<GrueMaster> I do have some qrt tests that magically work with that fix, but since i have had to manually run them anyways until now, it isn't too much effort to monitor them again.
<ogra_> well, we could just ask lamont to set the verification-done tag on the bug 
<apw> topdown mmap support
<ogra_> gievn he already runs the fix on the buildds
<apw> its that set isn't it we are talking about
<ogra_> without having GrueMaster to runn a full test ...
<GrueMaster> Part of the test process is that I am struggling to automate SRU testing.  Largely due to script issues and the lack of any automated installation capabilities prior to Oneiric on omap4.
<GrueMaster> But those are almost resolved.
<apw> ppisati, where do i expect to find 'topdown mmap support' applied?
<apw> ppisati, fsl-imx51 and natty and oneiric ti-omap4 right?  (which it is)
<ppisati> apw: M/N/O/P/omap4 and L/imx51
<apw> so it looks like it is applied everywhere i am expecting it to be, so i assume it'll be in teh next roll up
<apw> ppisati, ok cool, just checking they got applied right
<ppisati> i posted the testing kernels the day X, but i got the ack about all of them the day _after_ the SRU process started
<GrueMaster> ppisati: In the future, when you go on vacation to get away from it all, make sure to take your laptop so you can still work.  :P
<ppisati> so i couldn't pull
<ppisati> i did it before my internet disconnection
<ogra_> lol
<ogra_> ppisati, dont listen to him !
<apw> ppisati, yep that is likely our fault
<cking> hrm, still more workitems to plough through...
<ppisati> IMO it was just an unfortunate timing
<ppisati> the problerm is that i can't pull in fixes if they aren't tested
<GrueMaster> Agreed.  Actually, I was on a national holiday that week as well.
<infinity> ogra_: Err, reading backscroll, I don't think the buildds are fixed.
<infinity> ogra_: lamont tested a kernel on a machine, he didn't do any sort of mass roll-out.
<ogra_> infinity, i thought lamont was using the fixed kernels since a while
<ogra_> oh
<ogra_> ok
<ogra_> but after all he did the testing and could just comment on the bug ... leaving tobin off the hook
<GrueMaster> I tested it too.  Thought I had commented on the bug.
 * GrueMaster goes to check.
 * ogra_ hasnt looked at the bug 
<infinity> ogra_: He tested one kernel on one machine type.  That's not quite the scope of tobin's testing.
<ogra_> oh
 * ogra_ leaves that topic alone then
 * ppisati goes back to 3.2/omap4...
<ogra_> i somewhat had a different impression 
<GrueMaster> I tested it on babbage3 (Lucid) and panda (natty & oneiric).  Not sure if we had a test kernel for maverick.
<GrueMaster> Does the patch need to be retested on top of this new SRU kernel or can it just float into the next SRU cycle and get tested there?
<GrueMaster> (I may have missed this answer due to lack of caffeine).
<apw> GrueMaster, for me, just when it gets applied to teh next SRU, i am not expecting it to break
<ogra_> ++
<GrueMaster> Ok, great.  Means I can focus on other things until next SRU cycle without a special testcase getting thrown into the mix.
<infinity> apw: Looks like I win, my kernel will get built first.
<apw> heh
<infinity> (not that it matters, cause neither one can be published to the archive for a few hours)
<amb__> We have a bug (LP #886521) which is marked "Fix Committed" in Oneiric. What is the process / timescale that a new kernel gets released to incorporate such fixes (and presumably changes it to "Fix Released")?
<ubot2> Launchpad bug 886521 in linux "CONFIG_XEN_PLATFORM_PCI should be "y" when building 3.1 kernel" [Medium,Fix committed] https://launchpad.net/bugs/886521
<apw> amb__, it is likely the fix if already rolled up in the -proposed kernel for testing
<smb> Could be in the pending round of getting into proposed
<amb__> apw, so is that an automatic process? 
<smb> But normally you find an update in the bug that is automatically generated which tells you to test the proposed kernel
<amb__> (and/or how do we get at the .debs to test such kernels)
<amb__> ah, it's not there yet
<amb__> then
<apw> amb__, ok its only just been commited, so it missed the current sru round, so i'd say you'll see it in a kernel in about 3 weeks
<smb> No, I think its is on the way. The auto entry has some instructions about enabling proposed
<smb> but one also can get the debs from launchpad history of the linux package
<smb> https://launchpad.net/ubuntu/+source/linux/+publishinghistory
<smb> ^ if lp is willing
<bjf> amb__: we will be building the next oneiric kernel next week, as apw said it will hit -updates three weeks after that, it will be available via -proposed earlier
<apw> amb__, and expect testing requests for it around then
<smb> gah! lp timeout
<amb__> bjf, thanks
<bjf> amb__: np
<ppisati> don't we have the meeting in 1 hour?
<ppisati> sorry
<ppisati> 8mins
<jsalisbury> ppisati, yes
<tgardner> jsalisbury, we've been screwed by going off of daylight savings time. there are 2 entries in the calendar
<jsalisbury> tgardner, ahh, ok.  Should one of the entries be removed?
<tgardner> jsalisbury, yeah, but which one ?
<tgardner> I'll nuke the later one
<apw> the meeting is at 17:00 UTC right
<bjf> apw, yes, the meeting is now
<jsalisbury> apw, yes, in about 3 minutes
<tgardner> hmm, I can't delete the bogus entry. I'll send a note to Pete
<apw> stupid google
<ppisati> brb
<lamont> ogra_: I was given to understand that some post-my-testing kernel had the fix, which was great, since that was what I was waiting for - the rollout of a fixed SRU is semi-automatic, manually rolling out a non-standard kernel is a royal pain
<ogra_> aha
<ogra_> thanks for clearifying :)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Dec 13 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * tgardner -> lunch
<bjf> jsalisbury: i believe bug 793367 can be "Fix Released"
<ubot2> Launchpad bug 793367 in linux "ecryptfs corruption during make -j" [Medium,Fix committed] https://launchpad.net/bugs/793367
<jsalisbury> bjf, Ok, thanks.  I'll update it.
<jsalisbury> bjf, I'll keep an eye on and to ensure it falls off the hot list automatically as expected.
<jsalisbury> bjf
<jsalisbury> bjf, herton, possible Lucid update regression: bug 900943
<ubot2> Launchpad bug 900943 in linux "System clock runs fast in kernel 2.6.32-36" [Medium,Confirmed] https://launchpad.net/bugs/900943
 * tgardner -> EOD for now
<bjf> jsalisbury: thanks for the pointer, have added comment, am monitoring it
<jsalisbury> bjf, great, thanks.
#ubuntu-kernel 2011-12-07
<abogani> BenC: ping
<abogani> BenC: About "Reviving Ubuntu PowerPC"...
<abogani> BenC: What systems will be used as reference in this effort?
<abogani> BenC: Thanks!
<ppisati> infinity: how is the armhf image going?
 * smb steps in
<jjohansen> ppisati: last I heard well
<ppisati> cool
<ppisati> uhm, nice
<ppisati> if you switch kernel release, it breaks princhanges&c
<hrw> hi
<BenC__> abogani: I'm more interested in server platforms (as opposed to legacy mac systems)
<BenC> abogani: personally, I'm using a freescale e500mc based system (8-core, 32-bit)
<Stratisphere> Morning, i'm running xbmc with PVR on oneiric but there is a bug with the 3.0 kernel that prevents me from using my TV card. There is a patch available but hasnt made it upstream I believe. Whats the best way I can go around compiling the patch in to my kernel on my machine?
<Stratisphere> or whats the risk with downgrading to a 2.6 kernel?
<abogani> BenC: Interesting. Is there a roadmap already?
<smb> Stratisphere, Mostly the risk is that it is not tested at all. So some stuff may break or it works. And probably it will be a hassle to always keep track of updates to those older kernel... 
<smb> Stratisphere, But as a work-around... Since it is a different version, at least you can boot back into other kernels with grub
<Stratisphere> yeh true. What about downloading the 3.0 source and patching the fix in, if I just grab the source from https://github.com/torvalds/linux/tags is that suitable?
<Stratisphere> sorry, what i'm getting at is, does ubuntu have any specific bits in it?
<smb> Stratisphere, Rather go to git://kernel.ubuntu.com/ubuntu/ubuntu-oneiric.git
<Stratisphere> ah ha, thats what I was after :)
<smb> That also has all the build stuff to make debs
<Stratisphere> oky cool
<Stratisphere> is it somewhat stable?
<smb> The master branch is what is the current kernel in proposed which goes into updates
<smb> So fairly stable
<Stratisphere> oky cheers
<Stratisphere> thanks for your help :)
<smb> np :)
<Stratisphere> sucks, had to upgrade from lucid to fix the IR remote, but upgrading meant it broke the Tv card :P
<smb> I know the pain. Though for me it will be the other way round (at least I intend to go to oneric lts backport kernel to enable mine)
<Stratisphere> ahh, the struggles of an awesome HTPC :D
 * Stratisphere hopes the wife appreciates it when he's done
<smb> Stratisphere, hehe, depends on the media you put onto it, me thinks. :)
<Stratisphere> lol ruhoh. Mostly my scifi stuff! I keep telling her to tell me what to download but she never does lol
<Stratisphere> still. She can now play her iphone things on the TV which is kind cool 
<smb> You know how it works, you're supposed to know without asking. ;) But having the other thing may help, too. :)
<Stratisphere> hmm, lol the changesets are already in that repo
<Stratisphere> wow it takes a while to compile the kernel!
<smb> Depends on how powerful the build machine is... But "normal" ones... yes
<Stratisphere> out of curiosity, say you were to compile the kernel and then change one .c file... does it just compile that one file and then relink them or does it have to compile everything from scratch? (sorry, c noob here :P)
 * Stratisphere should have started the compile in a screen :(
<smb> Using the normal packaging without tricks, everything. At least when you use dpkg-buildpackage. There is work-arounds
<smb> by only running "fakeroot debian/rules binary-xxx" and removing the build stamp file under debian...
<smb> (xxx = the flavor like generic or generic-pae)
<Stratisphere> gotta say, you guys deserve top credits. i'm sure i've just seen the top of the pile but how you guys manage such a massive and complex project is amazing
<Stratisphere> btw, whats -pae?
<tgardner> sconklin, have you been running any of your tests on an ecryptfs mounted FS ?
<smb> The PAE feature enabled (which is physical address extenstion, I believe). This allows to use more than 4G of RAM in i386
<Stratisphere> ahh
<Stratisphere> knew I had heard/seen it before
<ledzgio> hi all
<ledzgio> I have a patch for an ethernet driver and I have to compile the kernel and apply that patch
<ledzgio> could someone help me in that?
<smb> Will this help? https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<ledzgio> yes, I have to apply this patch
<ledzgio>  http://patchwork.ozlabs.org/patch/125198/
<ledzgio> how can I do that following the document you linked before?
<smb> ledzgio, I would propose to get the source the git way. Then you can save the raw patch and try "git am <patch>"
<ledzgio> could you please explain better whats mean " Then you can save the raw patch and try "git am <patch>""
<ledzgio> ??
<smb> ledzgio, There is a patch link on that page that will let you download the complete patch. Then you go into the directory containing the source git tree and run the command "git am" with the file as argument
<smb> Or without git you run "patch -p1 < xxx" where xxx is again the patchfile
<ledzgio> ok you mean the patch in the link I have sent to you correct?
<smb> yes
<ledzgio> the command git am will apply the patch to the kernel?
<ledzgio> at that time I only need to build the patched kernel correct?
<Stratisphere> im off. Thanks again for your help smb :)
<smb> Stratisphere, welcome
<smb> ledzgio, yes. git am does a bit more if the file is in a special format which is to make it a commit in the repo
<smb> The link you sent looked like it would be the right format. But anyways if either way of applying succeeds you build that source
<smb> I suggest you change debian.master/changelog to add something like +myversion to the version number in the first line
<smb> That way the package and the running kernel have a specific version where you can see that you are really running your kernel
<ledzgio> ok perfect
<ledzgio> thabk you, I'll give it a try later
<ledzgio> if you will be here I'll contact you again if I have problem
<smb> I may or may not be
<smb> But there are always some people that can help around
<ledzgio> ok thank you very much
<ledzgio> your help is really appreciated
<ledzgio> the last thing
<smb> np
<ledzgio> I think that patch is good with kernel 3.0 or 3.1 also
<ledzgio> correct?
<sconklin> tgardner: no, but there's no reason not to. The ltp lite that's currently being used doesn't do much file system testing. I'll (eventually) try running tests against ecryptfs 
<sconklin> tgardner: I've pretty much completed the inventory of what's in ltp: https://wiki.canonical.com/SteveConklin/LtpTestList
<smb> That depends. I did not read all the details. If its just going upstream the chances are higher. But it was some wireless driver and there could be more change in that area of code
<ledzgio> I told you that because on top of that page are specified the versions and architectures supported(?)
<tyhicks> sconklin: Sync up with me before you do start running tests against eCryptfs. I hope to have a nice way to set up various types of eCryptfs mounts and run the typical filesystems tests against those mounts.
<sconklin> tyhicks: sweet, OK
<smb> ledzgio, Well that is the usual thing with backports. You may find that the compile breaks because some defines are not present (meaning support was neither) and then you have to tweak things. Also note that on that page the status has been set to superseded. Could mean there is something newer or different
<tgardner> sconklin, tyhicks: I'd like to get a full suite of ecryptfs tests running well before Beta 1. I'm still getting plenty of hate mail over corrupted disks.
<sconklin> tgardner: I can walk you through a manual install of ltp and tell you how to run the tests. In a few days, I may have that automated
<sconklin> (running of ltp in general, not ecryptfs)
<tgardner> sconklin, I'll wait. I've got other things on my plate right now.
<tyhicks> tgardner: agreed - before Beta 1 would be great
<ledzgio> smb, when you say "you have to tweak things", which kind of tweaks?
<smb> ledzgio, Decide how to modify the code, so it does compile in a way that still does work the same for the remaining code...
<ledzgio> ok I have some basics of C, I think i can do that if those tweaks are not too complicated
<ledzgio> thank you
<ledzgio> smb
<ledzgio> your help is really appreciated
<smb> you're welcome. no worries
<ledzgio> bye
 * ogasawara back in 20
<smoser> smb, around ?
<smb> smoser, at the moment, yes
<smoser> http://paste.ubuntu.com/762860/
<smoser> that is get-console-output of a precise hvm instance.
<smoser> i'll point out that there is no 'idle=halt'.
<smoser> the instance was not reachable.
<smb> smoser, right. Hard to say. Usually we know things get missing. Hm, also let me do a quick version check...
<smoser> i dont know if idle=halt would help or not. i tried a quick start, stop, attach, modify /boot/grub/grub.cfg, re-attach, start,
<smoser> but then got *no* console output
<smb> smoser, I did not see a using mwait in that one... so probably not...
<smb> smoser, But maybe it was before the k(u)nmap patch, though that normally hit only on higher load...
<smoser> smb, that is just the latest precise daily... but i have unfortunately no recollection of if this has worked at all in precise.
<smb> smoser, I think I got precise booting in my environment (I also think in the ec2 alike) but having booted too many variations I get confused 
<smb> and I got amd 
<smoser> smb, i suppose i should open a bug, eh?
<smb> smoser, Can you reproduce it at will? ;-P But ok, we need to have an eye on it...
<smoser> it reproduced 2 times out of 2
<smoser> but maybe i'm lucky
<smb> At least you might be lucky with the xen version
<smb> So this one at least is 3.4...
<smoser> smb,  bug 901305
<ubot2> Launchpad bug 901305 in linux "precise fails boot on ec2 hvm" [High,Confirmed] https://launchpad.net/bugs/901305
<smb> Oh HVM, right... Hm... That one I clearly have been running at least with my Oneiric dom0... at least
<bjf> tgardner: is the lts-backport-natty kernel on the 10.04.3 CD/DVD ?
<smb> smoser, The only difference is that I usually go for the "normal" kernels when doing hvm installs...
<tgardner> nope, only maverick thus far
<tgardner> bjf, ^^
<bjf> tgardner: thansk
<tgardner> bjf, the next point release should pick up natty and oneiric
<tgardner> bjf, I wonder if there is a bug for that yet.
<bjf> tgardner: i doubt it but skaet would probably know
<tgardner> I'm creating one
<tgardner> bjf, skaet: bug #901317
<ubot2> Launchpad bug 901317 in debian-installer "10.04.4 DVD must include Natty and Oneiric kernels" [Undecided,New] https://launchpad.net/bugs/901317
 * smb ends the day
<ledzgio> hi
<ledzgio> smb are you there?
<ledzgio> I'm going to build my own kernel with a patch for my ethernet card
<ledzgio> is there a way to enable pae support?
<ledzgio> for ram > 4GB
<ledzgio> ?
<ledzgio> i'm going to patch my kernel, but when I type git am patch_file it says "patch format detection failed"
<ledzgio> this is the patch http://patchwork.ozlabs.org/patch/125198/
<ledzgio> guys
 * ppisati -> eod
<tgardner> ogasawara, I think apw's ext4 patch is worthy of an upload
<ogasawara> tgardner: ack
<vanhoof> sforshee: yo
<vanhoof> sforshee: just to be certain, "[PATCH] dell-wmi: Change debug statements from pr_info to pr_debug"
<sforshee> vanhoof, hey
<vanhoof> sforshee: right thread?
<sforshee> vanhoof, yep. I was just typing a reply to your email
<vanhoof> sforshee: ok, i'm gonna go ahead and bounce it and send him a mail if that's cool with you
<sforshee> vanhoof, that would be great, thank you
<vanhoof> sforshee: done, let's see what we turn up :)
<ledzgio> how can I enable pae support when building my own kernel?
<vanhoof> sforshee: also sent him something with a bit of context
<sforshee> vanhoof, good deal. I hope we can get a response on the thread, but I have no problem with sending the information myself either
<ledzgio> with git
<tgardner> ledzgio, there is already a flavour with PAE enabled, e.g., generic-pae
 * cking has nearly finished with his wrestling with powertop
 * tgardner -> lunch
<ledzgio> how can I change the kernel name when I try to build my own?
<ledzgio> thank you guys
<ledzgio> really
<arges> hey, looking at https://bugs.launchpad.net/ubuntu/+source/udev/+bug/842560 . Looks like the bnx2 binary blob is having issues. Does it make sense to suggest upgrading the firmware? and where/how is that done?
<ubot2> Launchpad bug 842560 in linux "bnx2 firmware missing" [High,Confirmed]
<tgardner> arges, its not a firmware problem. its a udev race.
<arges> tgardner, ok been trying to understand it reading through the bug. so the fix is in udev?
<arges> or should be
<tgardner> arges, yep, the driver is working fine. its in the transition from initrd udev to rootfs udev
<tgardner> arges, apw is more familiar with the details
<arges> tgardner, ok, https://bugs.launchpad.net/ubuntu/+source/udev/+bug/842560/comments/43  made me think it was a kernel issue
<ubot2> Launchpad bug 842560 in linux "bnx2 firmware missing" [High,Confirmed]
<arges> ok i'll sync up with apw then when he's around
<tgardner> arges, we had a number of chats with slangasek at UDS about this issue. I'm pretty sure apw found the root of the problem.
<apw> arges, yep we are pretty sure the issue is that firmware loads are not restartable
<arges> tgardner, ok awesome.
<apw> arges, but that only matters because we don't drain waht is in progress when we restart udev
<arges> apw, ok, anything I can help you with on this bug?
<apw> arges, essentially we need to clean up the hand over, probally using the systemd handover
<apw> arges, it near the top of my todo, i need to re-review it in the morning perhaps we can chat tommorrow then after that
<arges> apw, yea sounds good
<apw> arges, you might investigate who has the reproduing machine and see if we have access to it for testing
<dupondje> somebody alive that takes care of the daily builds ? :)
<arges> apw, volon can reproduce the bug
<bjf> dupondje: what is the issue you'd like someone to address ?
<apw> arges, vorlon ?  
<dupondje> Well, the .config needs to be changed a bit
<arges> apw, steve langasek
<apw> arges, indeed
<dupondje> cause the CONFIG for intel wireless changed.
<apw> dupondje, whats wrong with the dailies ?
<dupondje> which makes no more intel wireless driver is build :)
<dupondje> and thats annoying :)
<tgardner> apw, I think he means mainline
<bjf> dupondje: we are kind of detail oriented, not good at guessing
<slangasek> apw: do you need me to get you access to the reproducing box?
<apw> dupondje, whats the config name change from and to, and i'll get it fixed
<dupondje> -CONFIG_IWLAGN=m
<dupondje> +CONFIG_IWLWIFI=m
<apw> slangasek, that may well make sense, i don't think i need it immeidiatly but yes
 * apw adds it to tommorrows todo
<slangasek> ok, let me see if I can get that sorted
<dupondje> http://comments.gmane.org/gmane.linux.kernel.wireless.general/81036 FYI
<bjf> dupondje: thanks, we'll take a look at that
<dupondje> thanks :)
 * dupondje was looking why his wireless didn't work in the daily builds :P
<skaet> bjf, tgardner - ack. 
<tgardner> skaet, its been so long I've forgotten what this is about.
<cking> slangasek, I've completed the journal-commit test (+readahead) with various applications running and updated bug 900923. Just some more data points to consider
<ubot2> Launchpad bug 900923 in pm-utils "pm-utils: readahead and journal-commit waste power" [Medium,New] https://launchpad.net/bugs/900923
<skaet> tgardner, backports on DVD
<tgardner> skaet, ah, right
<slangasek> cking: thanks :)
<cking> I'm very happy to test different scenarios if you deem it necessary
<slangasek> cking: I don't imagine so; I'll have a look at the data today
<cking> cool - thanks
 * ogasawara wonders what's bringing zinc to a crawl.  taking forever to upload.
<cking> jsalisbury is doing a git merge which is sucking cycles
<cking> nope, it's something else too
<jsalisbury> cking, hmm, let me take a look
<tgardner> ogasawara, prolly gitweb
<cking> reckon so
<jsalisbury> cking, on zinc, I'm not doing a git merge that I know of?  Maybe I have something that ran away
<cking> jsalisbury, it was busy for some tens of seconds and then popped away..
<jsalisbury> cking, ok
<vanhoof> sforshee: looks like the mail just landed -- hopefully that's helpful
<dupondje> sforshee: seems your quite active in the platform mailing list. Any chance you can have a look @ my email from some days ago?
<dupondje> aka 'dell-laptop: bug in rfkill'
<sforshee> vanhoof, that's great. Thanks for your help.
<sforshee> dupondje, I found your message. Let me look at it.
<vanhoof> sforshee: np, let me know if you need any other info :)
<sforshee> dupondje, have you filed a bug?
<sforshee> in launchpad that is
<dupondje> sforshee: not yet
<sforshee> dupondje, please do so. If you use 'ubuntu-bug linux' to file the bug it will attach a bunch of useful information
<vanhoof> dupondje: only thing that comes to mind is this: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/887834
<ubot2> Launchpad bug 887834 in network-manager "Unable to find wireless networks after toggling wireless" [Undecided,Fix committed]
<vanhoof> dupondje: but that's a total guess
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/901410
<ubot2> Launchpad bug 901410 in linux "dell-laptop: rfkill bug" [Undecided,New]
<dupondje> When I block the dell-bluetooth, my Wireless LAN gets hard blocked
<dupondje> which ofc shouldn't happen :)
<sforshee> dupondje, thanks. I'll set aside some time a little later to take a look, and then I'll comment on the bug.
 * ogasawara lunch
<dupondje> sforshee: thanks alot :)
 * tgardner -> EOD
#ubuntu-kernel 2011-12-08
<smb> morning
<lynxman> smb: moin moin
<smb> lynxman, hey :)
<lynxman> smb: :)
<brendand> can anyone think of a good reason why iwlist wouldn't be able to scan properly where network manager can? wouldn't they use the same interfaces? (in Oneiric)
<brendand> http://paste.ubuntu.com/763594/
<brendand> apw - this is another Broadcom system, but this time the wl driver is installed
<brendand> (from jockey-text -l) kmod:wl - Broadcom STA wireless driver (Proprietary, Enabled, In use) [auto-install]
<apw> brendand, often the act of connecting to and aquiring a channel affects the ability of the card to scan
<apw> so you find with some cards that if you run ilist constantly it will show the selected channel sometimes and a fuller listing others
<apw> as nm cycles the card through the two modes
<brendand> apw - no connections created on this system (/etc/NetworkManager/system-connections is empty)
 * smb wonders whether that actually mean nm cannot scan either...
<brendand> smb - i thought i got a scan out of nmcli a few minutes ago, but now that's not happening either
<smb> is by chance some rfkill actiuve?
<apw> on my brcm based systems i see the list come and go a lot from the command line
<apw> and nm always has a list, i suspect nm i simply caching the result for some time
<brendand> http://paste.ubuntu.com/763601/
<brendand> apw - i'll just check, i certainly didn't activate it myself
<brendand> crap, yes there is a hard block (i don't have physical access so no idea if the switch is actually flicked)
<smb> There also was once a problem of two laptop drivers fighting over rfkill on Lenovo's
<brendand> http://paste.ubuntu.com/763604/
<smb> (somehow it went away for me and I think there has been a propoer fix too)
<brendand> dell-wifi and brcmwl-0?
<smb> one for what the hw thinks and the other often showing bios setting
<brendand> i guess i'll have to wait for the lab engineer to confirm the state of the switch
<smb> could be physical switch or hotkey
<brendand> heh, i rebooted and now it's not hardblocked. not according to rfkill
<caribou> morning; Do we provide a kernel module for the Realtek 8190 wireless adapter ?
<brendand> but still iwlist doesn't work
<apw> caribou, what are the PCI ids for it
<caribou> apw: hold on ...
<brendand> and nmcli now does
<brendand> (i have no idea how dell-wifi got hardblocked before)
<caribou> apw: 0a:02.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. Device [10ec:8190]
<caribou> apw: Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:8190] 
<apw> caribou, sounding like it may be in a staging driver, at least in precise, no idea if it works, being realtek your milage may vary
<apw> seems to have some support in oneiric too, but ... quality, from a realtek driver ... erm
<apw> yet to be proven, you would need to test for sure
<caribou> apw: yes, this is what I read from a few LP bugs.
<caribou> apw: ok, thanks for checking
<caribou> apw: may I ask what is a "staging driver" ?
<caribou> and expect an answer ;-)
<apw> new drivers which are too crap to be accepted into the kernel as they are
<caribou> apw: ok, thanks. That's how I understood it
<apw> that may be functionally, stylistically, structually
<ogra_> philosophically :)
<brendand> apw - so if iwlist isn't working and network-manager is, does anyone care?
<apw> brendand, i think i heard yesterday that iwlist was using an old interface which was going to be deprecated
<apw> and that we should demote the iw* commands
<brendand> apw - i didn't expect it to be the case in Oneiric though. and that too on only one system
<apw> brendand, on O am not sure 
<brendand> or one network card as it were (BCM4322 802.11a/b/g/n)
<brendand> tgardner said it could break in P anytime soon
<brendand> is network manager the only authoritative tool, or what's replacing iw tools?
 * apw would have to defer to tim, he mentioned it yesterday for the first tim to my ears
<brendand> one last question before i go. who do i talk to about getting an item on the agenda for the kernel team meeting?
<smb> brendand, joe (the one that sends out the meeting notes) or you just raise your hand when there is the question about open discussion
<dupondje_> sforshee: thanks for replying to the bug.
<apw> ppisati, fyi that 3.2 ti-omap4 kernel is in the archive now, it'd better work :)
<ogra_> apw, yeah, else the masses of pand users will start compleining 
 * apw prepares for both of them to complain at once
<ogra_> i'll just give them paolos address ;)
<apw> ogra_, heh good plan
<ppisati> it boots here :)
<ppisati> and it drives my lcd, so it's good
<ppisati> release it! :)
<apw> ppisati, oh i already did ... :) ... meta will be in the archive shortly, and the screaming will begin
<apw> ppisati, ok all published, let the fun begine
<ppisati> apw: cool, just found a problem
<apw> ppisati, bad ?
<ogra_> campfire on the SoC surface ? :)
<ppisati> :)
<ppisati> nope
<ppisati> hangs on reboot in there's a usb hdd mounted (musb problem)
<ppisati> didn't notice cause i was running off the sd card
<ppisati> i'm testing a workaround now
<ppisati> and perhaps i found the guilty commit
<smb> crashtime...
 * ppisati -> lunch
 * ogasawara back in 20
<cking> it's getting really stormy here, if I dropoff line it's 'cos my power has gone
<ppisati> cking: i've 14C here, do you want some? :)
<ppisati> seems the winter is really late this year...
<cking> ppisati, I will swap you the warmth with the UK wind + rain
<herton> GrueMaster, about bug 893190, it's needing verification. I think you will want to verify it while doing qa of current maverick ti-omap4? In this case we can mark that as verification-done
<ubot2> Launchpad bug 893190 in linux-ti-omap4 "Qa-testing failures for 2.6.35-903.27" [Undecided,Fix committed] https://launchpad.net/bugs/893190
<GrueMaster> herton, yes I plan on it.  I have been working with the security team to get the QRT suite working on arm.  That came up as a "needs kernel fix", hence the bug report.
<GrueMaster> And actually, I will test it as part of the "Regression-testing".
<herton> GrueMaster, ok, I'll mark that bug as verified then, so the tracking bug of current maverick ti-omap4 can go to Testing
<GrueMaster> ok
<tgardner> arges, mumble ?
<arges> tgardner, ahh was just about to call 
<arges> let me unmute
<arges> tgardner, ok hold on getting mic
<arges> tgardner, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250
<ubot2> Launchpad bug 836250 in linux "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [Critical,In progress]
<arges> https://bugs.launchpad.net/bugs/876147
<ubot2> Launchpad bug 876147 in ubuntu "Intel Corporation Centrino Wireless-N + WiMAX 6150 (rev 67) not working after upgrade to 11.10 (dup-of: 836250)" [Critical,Confirmed]
<ogasawara> arges: just fyi, I've pinged our intel contact about bug 836250.  they were unfortunately unable to reproduce.  I've got jsalisbury working with the original bug reporter to narrow down the regression window.
<ubot2> Launchpad bug 836250 in linux "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [Critical,In progress] https://launchpad.net/bugs/836250
<arges> ogasawara, yea i've been speaking with him too
<brendand> rtg_ - hi
<rtg_> brendand, dude
<brendand> rtg_ - quick question, how reliable is iperf going to be in a high noise environment?
<brendand> rtg_ - say i have 3-4 systems hitting the iperf server simultaneously?
<rtg_> brendand, its as reliable as the underlying TCP connection.
<rtg_> I presume the iperf server is at the end of an ethernet cable ?
<brendand> rtg_ - it will be. right now it's not because i'm testing it in my home office
<rtg_> brendand, so I'm not sure what you mean by reliable.
<brendand> rtg_-  in terms of the bandwidth figures given by iperf
<brendand> rtg_-  in my current setup i get a figure of between 5 and 8 Mbits/sec
<rtg_> brendand, with multiple simultaneous wifi clients?
<brendand> rtg_-  would that go down significantly given a few systems trying to hit the same server?
<brendand> rtg_-  this is with just one
<rtg_> brendand, try it with an ethernet client
<brendand> rtg_-  the client is always going to be wireless in these tests though
<brendand> rtg_-  the server could well be wired to the router
<brendand> so the scenario would be 1+ clients connected to a router with a server wired to that router
<rtg_> brendand, _first_ establish the stability of iperf wrt consistent bandwidth measurements.
<brendand> rtg_-  are you suggesting to wire both systems to the router?
<Awsoonn> Hi all, Can I get some feedback on my line of thought in bug 901770 plase? Thank you~
<ubot2> Launchpad bug 901770 in linux "Kernel Bug in bluetoothd?" [Undecided,New] https://launchpad.net/bugs/901770
<rtg_> brendand, not to the router, but to the switch so that both are in the same subnet and have not extraneous HW between them.
<rtg_> s/not/no/
<brendand> rtg_-  right, i'll try that if i can
<brendand> rtg_-  are there any other ways we could detect these wireless issues?
<rtg_> brendand, there will be connect/disconnect messages in dmesg if you've a troubled connection.
<brendand> rtg_- i only wish i had access to a system troubled by problems like this
<brendand> rtg_-  what phrases might i look for?
<rtg_> brendand, yank the plug on your AP and look in your dmesg
<brendand> rtg_-  ok. i was wondering if that would be a realistic test. i'll try it
<rtg_> brendand, there is also prolly some dbus traffic that goes to NM when a connection fails.
<brendand> i'll see if i can try both those things. thanks
<smoser> smb, ping
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/876956
<ubot2> Launchpad bug 876956 in linux "starting interactive atop causes kernel alignment check" [Undecided,Incomplete]
<Awsoonn> another newb question, If I'm tracking down a kernel bug, which version of the kernel source shoudl I be making modifications to? The latest Linus release, or the latest ubuntu release, or something else altogether?
<bjf> Awsoonn: if you intend to submit a patch to upstream, you should be moding Linus' tree
<Awsoonn> bjf: Thanks! Will I be able to use the latest kernel with 11.10 without much issue? Or is it luck of the draw?
<bjf> Awsoonn: you should be able to use it
<bjf> Awsoonn: note, the current upstream kernel is currently at rc4 meaning it could be problematic
<bjf> Awsoonn: it's probably safest to start with our Oniric sources, determine your patch then port it to Linus' tree (which shouldn't be much of a port depending on what you are doing)
<Awsoonn> I'll be working in the bluetooth stack, do you think it would be reasonable to use the latest release rather than -RCx?
<bjf> Awsoonn: i don't know how much churn that area of the kernel is getting
<Awsoonn> not much by the looks of it, last modification was on Oct 24 if I'm reading things correctly...
<bjf> Awsoonn: then i'd do as i suggested and hack on the oneiric sources and then work with the upstream maintainer to get it upstream (they'll want patches against linus' tree)
<Awsoonn> ok, that's great! :) Now I've got someplace to start.
<Awsoonn> ok, I just did a little bit more digging and found that upstream has already changed the function I was about to modify. I'm wondering if my bug is already fixed, so is there a prefered method for installing a more recent kernel?
<vanhoof> herton: looks like lts-backport-oneiric should be released soon, yeah?
<vanhoof> herton: (based on the tracking bug)
<herton> vanhoof, it's released on updates
<herton> -updates/-security
<herton> at least rmadison already shows it
<bjf> Awsoonn: just download the appropriate .deb for Precise and install it
<bjf> Awsoonn: are you running amd64 or i386 on a desktop ?
<Awsoonn> bjf: fair enough, I wondered if that would work or not, thanks! AMD64
<Awsoonn> and it's on a laptop if that matters at all to you
<bjf> Awsoonn: https://launchpad.net/ubuntu/precise/amd64/linux-image-3.2.0-3-generic/3.2.0-3.9
<Awsoonn> does the version string 3.2.0-3 and no '-ubuntuX' indicate that this is RC3 and there is no Ubuntu sause added yet?
 * rtg_ -> lunch
<apw> Awsoonn, https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2BAC8-FAQ.2BAC8-GeneralVersionMeaning.What_does_a_specific_Ubuntu_kernel_version_number_mean.3F
<Awsoonn> that's quite the URL, thanks!
<apw> yeah the wiki is a bit pants
<bjf> Awsoonn: our kernels always come with sauce :-)
<brendand> rtg_-  all i get in dmesg that looks useful is:
<brendand> [ 1295.068497] cfg80211: All devices are disconnected, going to restore regulatory settings
<jsalisbury> bjf, I'll be updating bug 836250 shortly.
<ubot2> Launchpad bug 836250 in linux "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [Critical,In progress] https://launchpad.net/bugs/836250
<vanhoof> herton: perfect, thanks!
<bjf> jsalisbury: thanks, sorry to bother you
<jsalisbury> bjf, heh, no problem.  Thanks for keeping up with the bug ;-)
<brendand> rtg_-  it looks like that bug above should affect a few systems we have. i can test my test on that
<awsoonn> well, the percise kernel still contains my bluetooth bug, onward to vanila-RC4 I suppose.
<rtg_> apw, I keep getting Mainline Build v3.2-rc4 messages
 * cking kicks off an overnight soak test and calls it a day...
<chrisccoulson> i've just updated my precise machine for the first time since i switched to precise, and i can't boot the current precise kernel
<chrisccoulson> i just get a whole bunch of these messages flashing rapidly by on screen:
<chrisccoulson> http://paste.ubuntu.com/764247/
<chrisccoulson> it doesn't even get as far as plymouth
<chrisccoulson> i left it for a few minutes, but had to switch it off when my laptop felt like it was going to burst in to flames
<Awsoonn> chrisccoulson: I'm no expert, but it looks like you have a HDD that is failing. :( (I could be very wrong but that's what it looks like to me)
<chrisccoulson> Awsoonn, how come it only fails with the latest kernel? i can boot and use 3.1 without any problems
<rtg_> chrisccoulson, start a bug and attach your apport info. I guess you'll have to use 3.1 to do it.
<rtg_> what device is 03:00.0 ? Is that the display ?
 * ogasawara lunch
<ogasawara> chrisccoulson: bug 894070
<ubot2> Launchpad bug 894070 in linux "IOMMU error loop early in boot" [High,Triaged] https://launchpad.net/bugs/894070
<chrisccoulson> rtg_, 03:00.0 CardBus bridge: Ricoh Co Ltd Device e476 (rev 02)
<chrisccoulson> ogasawara, thanks!
<ogasawara> chrisccoulson: there's a test kernel there, or alternatively just try booting with "intel_iommu=off"
<ogasawara> chrisccoulson: it's on my list of bugs to get to
<chrisccoulson> excellent, thanks
<rtg_> ogasawara, good eye. I knew I'd seen something like that
 * ogasawara really goes to eat really quick
 * rtg_ -> EOD
<Awsoonn> I followed the instructions on https://wiki.ubuntu.com/Kernel/CrashdumpRecipe but my /var/crash dir is still empty, even after the sysrq test. Why might this be happening?
<Awsoonn_> How can I get a crash dump or a stack trace if wiki:Kernel/CrashDumpRecipe leaves me with an empty /var/crash dir?
<hggdh> should installation of linux-image-extra-virtual kick update-initramfs?
#ubuntu-kernel 2011-12-09
<Awsoonn> bug 901770 I attached a pic of a KP stack trace, there is a function in the trace called "string.isra.3" I've found the 'string' fuction it's referencing but what does the  .isra.3 mean?
<ubot2> Launchpad bug 901770 in linux "Kernel Bug in bluetoothd?" [Medium,Confirmed] https://launchpad.net/bugs/901770
<apw> hggdh, yes it should, there is cirtianly postinst for it in later versions
<apw> hggdh, it was a known issue with the initial versions that it did not
<apw> ppisati, next time we do a ti-omap4 rebase we should include the changelog fragment from->to from the original tree.  there is a helper in the tree for this called insert-ubuntu-changes, which adds changlog information to your changelog if you have a startnewrelease already
<apw> ppisati, ./debian/scripts/misc/insert-ubuntu-changes debian.ti-omap4 Ubuntu-3.2.0-3.8 Ubuntu-3.2.0-3.9
<apw> ppisati, in theory that puts the right stuff in, its broken it seems, will fix
<apw> ppisati, ahh me being dense.  So it takes a changelog of course ...
<apw> ./debian/scripts/misc/insert-ubuntu-changes debian.ti-omap4/changelog Ubuntu-3.2.0-3.7 Ubuntu-3.2.0-3.8
<apw> +  [ Ubuntu: 3.2.0-3.8 ]
<apw> +
<apw> +  * armhf -- add d-i configuration
<apw> +  * armhf -- disable ABI checks for armhf
<apw> +  * armhf -- add arch to getabis config
<apw> ppisati, so it does something like that, which you then can commit as 'UBUNTU: rebase to Ubuntu-3.2.0-3.8' or whatever
<apw> that way the derivative branch contains hints as to the real changes coming over
<apw> and also any bug numbers that were fixed in the master branch too
<apw> ppisati, make sense ?
<ppisati> uhm, nice, didn't know about it
<apw> ppisati, yeah my fault should have mentioned it before, we use it on like -ec2
<apw> ppisati, and it copes with more than one version, so if you rebase forward 4 versions just put the old and new base versions and it will insert multiple sections
<apw> smb, any idea if the use of ubuntu-insert-revisions is documented anywhere?
<ppisati> friday off, he is not here i think
<apw> ahh good point
<vanhoof> oooh
<vanhoof> new kernel fun :)
 * vanhoof installs 3.2.0-1402.2
<vanhoof> ppisati: apw: that's published now right?
<ppisati> yep
<vanhoof> ppisati: \o/
<vanhoof> vanhoof@panda:~$ cat /proc/version_signature 
<vanhoof> Ubuntu 3.2.0-1402.2-omap4 3.2.0-rc4
<vanhoof> heyoooo
<vanhoof> it booted :D
<ogra_> why wouldnt it :)
<ogra_> we are professionals, you know *g*
<vanhoof> i have serious paranoia problems with this board :)
<ogra_> now try armhf :)
<vanhoof> it's been through a lot :)
<vanhoof> ogra_: it was broken for 6 months :)
<ogra_> huh ? what was the bug ?
<vanhoof> ogra_: haha
<vanhoof> ogra_: tornado
<vanhoof> http://ubuntuone.com/3I34mVXLaXZDUEGUeN9l1P
<ogra_> oh indeed :)
<vanhoof> hdmi is hosed on it (no signal)
<vanhoof> but serial works
<vanhoof> and jk- recommended putting it in the dish washer
<ogra_> ah, then you are one of our server image users :)
<vanhoof> and what'dya know
<vanhoof> it works again :)
<vanhoof> yup
<ogra_> haha
<vanhoof> figured i'd make some use of it
<ogra_> awesome 
<apw> vanhoof, the hdmi works now?  or the board boots now
<vanhoof> apw: board boots
<vanhoof> still no hdmi
<apw> heh that is something i guess
<vanhoof> yeah :)
<vanhoof> better than a cool looking paper weight 
<alkisg> Hi, does this screenshot look like it can be caused by a corrupted ext4 filesystem? http://alkisg.mysch.gr/steki/index.php?action=dlattach;topic=4145.0;attach=2676;image
<alkisg> It does that when the teacher runs "mksquashfs"
<vanhoof> ogra_: n00b in this space 
<vanhoof> ogra_: but a quick q
<vanhoof> ogra_: would like to add a bit more disk space, any recommendations on what's the best fit, short of a usb device?
<vanhoof> (if you have a sec)
<ogra_> well, a bigger SD then ... 
<ogra_> you only have these two options
<vanhoof> ogra_: best route then?
 * vanhoof has a 4gb sdhc card presently
<ogra_> Sd is indeed slower than USB
<ogra_> i would keep the 4G and have a build chroot on a USB disk (for speed)
<ogra_> beyond that 4G should suffice for smaller stuff indeed, especially if you use the server image
<vanhoof> yeah server image, but have abused a bit of the free space with some local builds :)
<ogra_> (you can delete the package pool on the server image (see sources.list.d) that will give you a lot extra space)
<ogra_> we shipe quite a big archive inside the image (so you can install server packages without needing network)
<ogra_> *ship
<vanhoof> oh yeah
<vanhoof> root@panda:/var/lib/preinstalled-pool# du -shc /var/lib/preinstalled-pool/
<vanhoof> 441M    /var/lib/preinstalled-pool/
<vanhoof> 441M    total
<vanhoof> ogra++ thanks for the tip
<ogra_> :)
 * ogasawara back in 20
<Wipster> I have found that if I disable dma with the boot option libata.dma=0 I cant access my harddrive and get READ MULTIPLE errors in dmesg, this relates to bug #897777
<ubot2> Launchpad bug 897777 in linux "DMA bug with ICH7-M" [High,Confirmed] https://launchpad.net/bugs/897777
<Wipster> Unless thats not how to disable dma, looks like the problem is somewhere else?
<brendand> jsalisbury - hi
<jsalisbury> brendand, hello
<mfisch> is there a way to tell if a what parts of kernel firmware are being used at runtime?  something like lsmod for kernel-firmware...?
<tgardner> mfisch, there is generally something in dmesg, though it may be driver specific. You can also look in the udev logs
<mfisch> tgardner: yeah I knew about the logs.  sounds like that's the only option
<tgardner> mfisch, what device ?
<mfisch> tgardner: this is a general purpose question, no specific device problems
 * ppisati -> eod
<sbeattie> bjf: you should have new mail.
<bjf> sbeattie: thanks, i signed yours, you won't get email :-) (not using caff yet)
<sbeattie> bjf: no worries, thanks.
<arges> tgardner, are there flags I can pass to the kernel to provide more verbose wifi/iwlagn messages? 
<tgardner> arges, dunno, I haven't been at that level in awhile.
<tgardner> have you created the bug report yet ?
<arges> tgardner, trying to make sure it isn't user error first
<wamty> has 'CONFIG_SECURITY_CAPABILITIES' been removed from recent (3.0.x) kernels?
<tgardner> wamty, its not in 3.0.x
<wamty> hmmmm
 * tgardner -> lunch
<wamty> BenC
<wamty> has 'CONFIG_SECURITY_CAPABILITIES' been removed from recent (3.0.x) kernels?
<infinity> wamty: Someone else already answered.
<kees> wamty: yup
<wamty> but why removed?
<wamty> caps are the default module i think
<kees> wamty: correct. it's no longer optional. :)
<kees> i.e. no config, because it's always there.
<arges> tgardner, wow so not only does it disconnect me in n-mode wifi in 3.0.0-12 , but the router goes into a bad state that requires a reset (even wired connection to it doesn't work). For some reason 3.0.0-14, 3.2 seem to work for me in n-mode. now i want to make sure this isn't a router issue, I'm going to check for firmware upgrades.
<wamty> i can log -p security/Kconfig to get the IDs of interesting pieces
<wamty> i guess
<tgardner> arges, thats a good trick borking your AP
<arges> tgardner, yea there is a firmware upgrade so i'm trying that first
 * ogasawara lunch
<arges> tgardner, https://bugzilla.redhat.com/show_bug.cgi?id=708747 this could be related to my issue
<ubot2> bugzilla.redhat.com bug 708747 in kernel "Extremely slow network with Intel "Ultimate N WiFi Link 5300" (iwlagn) after upgrade from Fedora 14" [High,Closed: errata]
<arges> trying to figure out why it was marked errata
<tgardner> arges, its possibly related
<tgardner> arges, you gonna try https://bugzilla.redhat.com/attachment.cgi?id=519535&action=diff ?
<wamty> Reversed (or previously applied) patch detected!  Assume -R? [n]
<arges> tgardner, i can
<wamty> what do i do?
 * herton -> eow
<arges> tgardner, ok, been looking at this further. I only see this weird n-wireless router behavior in 3.0.0-12 and not  in 3.0.0-13.15 or 3.2.0 or even 2.6.38/natty. 
<tgardner> arges, glp Ubuntu-3.0.0-12.20..HEAD -- drivers/net/wireless/iwlwifi/
<tgardner> 0a443e57caa1e18b16136e75ce0dc44b14c4c967 iwlagn: do not use interruptible waits
<tgardner> 5b483fbe23b7264976c5db37e74cca3fd33ed3b0 iwlagn: fix dangling scan request
<tgardner> 59f53ce22e0166ac046b63f73193f233b1d3a1b0 iwlagn: workaround bug crashing some APs
<tgardner> 2d8483fafb989e81b1084476110499a8611b0ca6 iwlagn: fix command queue timeout
<arges> tgardner, ok thanks. looks like im not reproducing the original issue I was trying to reproduce then!
 * tgardner -> EOW
#ubuntu-kernel 2011-12-10
<mes0r> ive got an old version of the kernel on my vendor provided lucid image, why wouldnt this be at least the default 2.6.32 kernel?
<mes0r> got my answer in #ubuntu
<mdeslaur> The kernel updates for oneiric are uninstallable, it seems linux-meta needs to get release from -proposed to -security
<mdeslaur> ok, it got taken care of
<synapse> I opened a bug, how long until I can turn back on updare-processs? :)
<synapse> Can someone merge this request into the upstream kernel?
<synapse> https://bugs.launchpad.net/bugs/902497
<ubot2> Launchpad bug 902497 in linux "ALSA Support for Roland GAIA SH-01 Synthesizer" [Undecided,Confirmed]
#ubuntu-kernel 2011-12-11
<melkor> I have tried a couple of the mailine kernels and my hdmi sound doesn't work for any kernel after 2.6.38
<ohsix> how can i build the .deb for the kernel without stripping the debuginfo? trying to save myself a 700mb download on the .ddeb
<Awsoonn> Hi all, I'm trying my best to debug a KP, and I've got so far as to get a copy of the core dump of the system, and I found a null pointer that's being deref'd but now I'm stuck. :*(
<Awsoonn> this week is my first dabble at kernel hacking, so any spare advice would be helpful. :)
<Awsoonn> alright, a more specific question, is there an existing LXR site for the 3.2.0-RC4 kernel?
<Awsoonn> or how do you guys navigate the tree when debugging KP's?
<ohsix> lxr.linux.no doesn't?
<Awsoonn> only released versions... :(
<Awsoonn> ohsix: unless, of course, I missed it somewhere?
<ohsix> hm, the vmlinux from the -dbgsym package isn't in a place that perf will find it
<ohsix> some reason it wont use kallsyms either, and if you force it at report time it segfaults
<ohsix> redhat puts it in /lib/modules/<ver>/vmlinux instead of /boot, or /build/vmlinux, oprofile systemtap and perf look at those paths
<wamty> what is the equivalent of atol in the kernel?
#ubuntu-kernel 2012-12-03
<tyf> linux-generic-lts-quantal package is really not a PAE kernel?
<infinity> tyf: It's PAE, what makes you think it's not?
<infinity> tyf: We don't have non-pae in quantal and above.
<tyf> after i installed it in precice, i do uname -r, the name doesn't show "pae". so i went to the packages.ubuntu.com, browse through the quantal's kernel packages, found some kernels named with -pae
<infinity> tyf: The name has nothing to do with it.
<infinity> tyf: From quantal forward, we don't have a non-pae kernel.  Hence, generic is now pae.
<tyf> ok, thanks for the info, btw, is there a definite way to check whether the kernel is compiled with PAE enabled?
<infinity> (precise-i386)root@cthulhu:~# grep PAE /boot/config-3.5.0-19-generic 
<infinity> CONFIG_X86_PAE=y
<infinity> Of course, there's also the simple "does your computer have a ton of RAM, and does the kernel see it?" :P
<infinity> You'd know pretty quickly if you booted a non-pae kernel.
<tyf> ok, that's understandable, but here I have exactly 4GB of RAM but i don't know how much video RAM is in the intel hd4000 and the nvidia gt630M. 
<tyf> When i booted up with a non-pae kernel, which RAM will be "truncated" first? or the kernel will refuse to boot?
<tyf> The Ethernet controller "AR8162 Fast Ethernet" is still not supported by any kernel modules in the quantal kernel 3.5...
<tyf> Very weird, the wlan is properly detected and used, but  still have to compile the "alx" module myself in order to use the ethernet port, as occured to me when using kernel 3.2 and 3.4 too
<tyf> maybe I should blame myself for buying this laptop :(
<infinity> tyf_: Looks like you're going to need compat-wireless, see: http://ubuntuforums.org/showthread.php?t=2050126
<infinity> tyf_: Oh, actually, if you go back to using the precise kernel, there are claims that linux-backports-modules-3.2.0 has the driver you need.
<infinity> tyf_: See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/927782 for more details.
<ubot2> Launchpad bug 927782 in linux (Ubuntu Raring) "integrate the Atheros AR8131/AR8151/AR8152/AR8161/AR8162 Ethernet driver with Jockey" [Medium,Confirmed]
<tyf_> fyi, i have uninstalled the jockey since i first installed the OS in this laptop...it always crashes and very annoying during startup
<tyf_> and, the recent updates of the kernel 3.2 has caused very random complete lockup in my computer
<tyf_> so i decided not to use the kernel 3.2 for some time
<tyf_> btw, i heard that the quantal kernel is going to be included in the 12.04.2 release...hence, I will just wait for that...:P
<infinity> tyf_: The quantal kernel that will be included in 12.04.2 is the one I already had you install.
<infinity> tyf_: (linux-generic-lts-quantal)
<infinity> apw: Do we need to be doing lbm-lts-quantal as well for the backport stack?  Without it, people who need cw for obscure/new hardware support kinda get shafted.
<infinity> apw: Specifically thinking of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/927782 which is fixed in lbm, but not in the quantal kernel itself (hence, not in lts-quantal).
<ubot2> Launchpad bug 927782 in linux (Ubuntu Raring) "integrate the Atheros AR8131/AR8151/AR8152/AR8161/AR8162 Ethernet driver with Jockey" [Medium,Confirmed]
<apw> infinity, i think we were hoping not to, but you may well raise an important point
<ppisati> apw: why do you keep the low latency branch in a separate tree instead of being a topic branch (like ti-omap4) of our main tree?
<apw> ppisati, because in theory it is maintained by people outside of the kernel-team who cannot write there
<ppisati> apw: ok
<apw> ppisati, though i cannot deny it would make sense to have it mirrored into there, same for ppc
<ppisati> apw: and do you plan to backport the fix for lp1029730 back to P/Q?
<ppisati> bug 1029730
<ubot2> Launchpad bug 1029730 in linux-ti-omap4 (Ubuntu) "linux-image-$(uname -r) should suggest linux-headers-$(uname -r)" [Medium,Confirmed] https://launchpad.net/bugs/1029730
<apw> i believe the fixes for dpkg are planned for backport so we would have to indeed
<ppisati> ok
<jamesh20000> hello
<jamesh20000> Hi, I'm about to install a linux based OS for the first time ... a shop is going to do this for me
<jamesh20000> Someone told me not to get a kernel that's much higher than 2.6.27
<jamesh20000> do I have a selection of kernels when I install Ubuntu ?
<jamesh20000> I don't know how Ubuntu works
<tyf_> it is hard to answer what kernel is best for you, but generally if you have newer hardware, go for a higher-versioned kernel
<tyf_> you don't have to worry about the kernel version first, just install a version that you like to use....I recommend the LTS versions, i.e. the 10.04 and 12.04
<tyf_> somehow i still love to use 10.04 for its stability
<jamesh20000> I'm going to install Ubuntu next to win7 -- How much space is reasonable for the Ubuntu partition?
 * henrix -> lunch
<jamesh20000> I'm going to install Ubuntu next to win7 -- How much space is reasonable for the Ubuntu partition?
<xnox> jamesh20000: support at -> #ubuntu channel.
<xnox> bug 1085958
<ubot2> Launchpad bug 1085958 in linux (Ubuntu Raring) "FTBFS linux-libc-dev fails to compile iptables" [High,Confirmed] https://launchpad.net/bugs/1085958
<tyf_> Guess the linux-backports-modules-cw will not be available for the linux-generic-lts-quantal kernels?
<ppisati> brb
<arges> apw: https://wiki.ubuntu.com/KernelTeam/BuildKernelWithChroot
 * ogasawara back in 20
<jsalisbury> bjf, herton, henrix Seems like allot of people are affected by bug 1080530
<ubot2> Launchpad bug 1080530 in v86d (Ubuntu) "v86d prevents suspend from completing" [Medium,Confirmed] https://launchpad.net/bugs/1080530
<bjf> jsalisbury, ack
 * ppisati -> gym
<rtg> jsalisbury, maybe 'freezer: exec should clear PF_NOFREEZE along with PF_KTHREAD' ?
<rtg> otherwise you're gonna have to bisect. there are a boatload of patches twixt those 2 releases
<jsalisbury> rtg, looks like an easy thing to revert.  I'll build a test kernel and request that they test.
<shnatsel> Hello
<shnatsel> I see Precise seeds have been converted to using 3.5 kernel backported from Quantal by default for x86 architectures. I wonder if I should use 3.2 or 3.5 for a derivative distro? I'm primarily concerned by two things: 1) for how long will it be supported and 2) will hardware support patches be backported to 3.5 like they are being backported to 3.2?
<xnox> shnatsel: the support path from quantal-lts kernels will be the raring-lts kernels.
<xnox> shnatsel: so the quantal-lts kernel will have the support timeframe of quantal release.
<xnox> shnatsel: so there is an option of getting newer kernels throughout precise release.
<shnatsel> xnox: I see. It seems there's no metapackage that points to the latest backported kernel, so anybody who had their system shipped with the Quantal-backported one will automatically have the support time of Quantal itself, not the LTS 5 years? Or raring-lts will provide a dummy transitional package for quantal-lts?
<xnox> shnatsel: I don't know how this will be done when the raring kernels will come around.
<xnox> shnatsel: but do note that we do not auto-upgrade people to quantal-lts kernel, the install images for 12.04.2 will switch to quantal-lts.
<xnox> shnatsel: note that raring-lts kernels will be available only well after raring release.
<shnatsel> xnox: yes, I'm aware of that. I'm wondering what will happen to people who will use 12.04.2, because the Quantal kernel will be supported for a much shorter period than the rest of the Precise system
<xnox> hopefully somebody else can answer that.
<shnatsel> okay, I'll try asking in #ubuntu-devel :)
<shnatsel> but I take it 3.2 is going to be supported for 5 years?
<shnatsel> also, is hardware support really being backported to it or it's just me? (e.g. does it work with Ivy Bridge?)
<bjf> shnatsel, yes, it is supported for 5 years
<bjf> shnatsel, the purpose of the lts-hwe kernels is specifically for supporting newer HW
<shnatsel> bjf: but the lts-backports are not supported for 5 years? If not, is there an upgrade path?
<shnatsel> okay, I trust you won't abandon the people who installed 12.04.2 XD
<shnatsel> final question:
<bjf> shnatsel, you are correct that they are not supported for 5 years. if you are on lts-hwe-quantal, you will be automatically upgraded to the 14.04 (T) lts-hwe kernel when that releases
 * rtg -> lunch
<shnatsel> bjf: oh, good to know. Thanks!
<shnatsel> Final question: bug 1034099 is a stable release regression that leads to a kernel panic, but it's been unattended for some time. Happens in Precise and Quantal. Is there anything I can do to help get it fixed?
<ubot2> Launchpad bug 1034099 in ulatencyd (Ubuntu) "Kernel panic with ulatencyd on kernel 3.2.0-29-generic" [Undecided,Confirmed] https://launchpad.net/bugs/1034099
<shnatsel> I'm not a 1337 haxx0r myself, just a script kitty and an architect for an Ubuntu-derived distro
<bjf> shnatsel, all i can tell you at this point is it will need further investigation and probably some bisect work to see if we can find the regression
<shnatsel> so bisecting the exact patch should help?
<bjf> shnatsel, absolutely
<shnatsel> the bug appeared after an update and there were 3 or 4 patches in it; getting someone to bisect it shouldn't be too hard :)
<bjf> shnatsel, there are 109 commits between 3.2.0-28.45 and 3.2.0-29.46
<shnatsel> I see the debian changelog wasn't that precise
<shnatsel> where can I find that branch?
<shnatsel> also, is "debuild" enough for building the packages? or should I use something else?
<bjf> shnatsel, i'm looking at the git repo at: git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
<bjf> shnatsel, these are the instructions i normally point folks at: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel 
<shnatsel> bjf: thanks! I'll try to get somebody on bisecting it :)
<bjf> shnatsel, debuild does alsow work :-)
<shnatsel> bjf: is there a way to list all the commits between those two tags, for ease of bisecting?
<shnatsel> I can't obtain it (I'm a noob at git)
<bjf> shnatsel, have you ever used git to help do a bisect?
<shnatsel> no
<bjf> jsalisbury, can I hand this off to you ? ^
<bjf> shnatsel, we have a wiki page that will help
<shnatsel> oh, great!
<jsalisbury> bjf, sure
<shnatsel> and I'm instructing another person instead of doing it myself, so I'll invite them here
<jsalisbury> shnatsel, I can perform the bisect for you, and post test kernels.
<jsalisbury> shnatsel, is this for bug 1034099 ?
<ubot2> Launchpad bug 1034099 in linux (Ubuntu) "Kernel panic with ulatencyd on kernel 3.2.0-29-generic" [High,Confirmed] https://launchpad.net/bugs/1034099
<bjf> jsalisbury, between 3.2.0-28.45 and 3.2.0-29.46
<jsalisbury> bjf, ack
<shnatsel> jsalisbury: to clarify, I have no skills to fix the bug, I just tried to help getting it fixed by bisecting the exact commit that causes the regression. But that'd be great anyway :)
<jsalisbury> shnatsel, I'd be more than happy to do the bisect.  I'll start a bisect between  3.2.0-28.45 and 3.2.0-29.46 and post a link to a test kernel in bug 1034099
<ubot2> Launchpad bug 1034099 in linux (Ubuntu) "Kernel panic with ulatencyd on kernel 3.2.0-29-generic" [High,Confirmed] https://launchpad.net/bugs/1034099
<shnatsel> jsalisbury: oh, that'd be great! Thanks a lot!
<jsalisbury> shnatsel, np.  It sounds like this is pretty easy to reproduce.  It just requires ulatencyd installed on Precise?
<shnatsel> jsalisbury: yes. The kernel panics on every boot.
<shnatsel> In Quantal, too
<shnatsel> and in Precise
<shnatsel> I have no data about Raring yet
<jsalisbury> shnatsel, ok.  Let me see if I can also reproduce it.  If I can, that will greatly speed up the bisect process.
<shnatsel> It should be easily reproducible. It was the most reported bug in our distro, ever :)
<shnatsel> All the machines I've seen were bricked by this update.
 * henrix -> EOD
<jsalisbury> shnatsel, I'll try to reproduce the bug.  If I can, I'll perform a bisect to find the bad commit.  If I can't reproduce the bug, I'll post an update the bug and ask for help testing.
<shnatsel> jsalisbury: thanks!
<shnatsel> I've found the wiki page on bisecting and arranged bisecting with a guy who experiences it, just in case
<jsalisbury> shnatsel, great, thanks.
 * apw calls it a day ... no ... more ... config ... review
<rtg> hallyn, did you ever get any traction on your patch at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065589/comments/15 ?
<ubot2> Launchpad bug 1065589 in lxc (Ubuntu) ""initctl list" shows 11974 instances of network-interface-security after two days of uptime" [Medium,Triaged]
<rtg> bjf, linux-generic-lts-quantal
<rtg> herton, do you think bc78c57388e7f447f58e30d60b1505ddaaaf3a7d is a candidate for stable? 3.2+
<herton> rtg, looking
<herton> rtg, yeah, looks something that can go in 3.2
<rtg> herton, looks like it applied to all stables through 3.6
<herton> rtg, hmm, can't find it here applied on other stables
<rtg> I meant to say that it _should_ be applied to other stables as well
<herton> true
 * rtg has had enough fun for one day
<hallyn> rtg: hm, no, it got an ack from dlezcano, and died there
<hallyn> rtgso an ack from Eric and Daniel - I'll resend with those
<bjf> bryce, i just pinged sconklin about the video switch gadget he developed and he's indicating that he'll send one to you
<sconklin> bryce: I just pulled one (the last assembled one) and I'll have it out to you ASAP
<bryce> sconklin, bjf oh great, thanks!
<strcrzy_> does anyone know of issues with SSDs and I/O errors on 3.2.0?
<strcrzy_> we just upgraded from 11.10 to 12.04.1 and now about 10 of our 50 machines started vomiting up disk I/O errors
<arges> strcrzy_, I would recommend filing a bug, so we can see logs and what error messages there are
<infinity> henrix_: Another shankbot request.  Currently, I think 'promote-to-security' keys off of jjo's 'security-signoff', but for rebase/derivative/community kernels, I'd like this to also intersect with "is/was the master being/been promoted to security?"
<infinity> henrix_: (Security team already gave me the go-ahead to promote derivative kernels that cover CVEs, but it's a bit of a pain to manually cross-reference every time).
<herton> infinity, ok, me or henrix_ will do
#ubuntu-kernel 2012-12-04
<infinity> herton: Oh, you could do it too, sure. :)
<infinity> herton: How often does shankbot poll the PPA?
<bjf> infinity, once an hr.
<infinity> bjf: Thanks.
<infinity> bjf: Hrm, I'm missing some subtle nuance then, cause linux/hardy has been built and published for well over an hour, but the bug has no promote-to-proposed confirmed.  Weird.
<infinity> bjf: And it finally got around to it.  Maybe I'm just impatient.
<tyf> if I am using the linux-generic-lts-quantal kernel in Precise, am I able to use any of the lbm-cw packages in the repository? are the kernel modules compiled specifically only for other kernel versions?
<Sarvatt> tyr: no you can't, are you using linux-backports-modules-cw-3.6-precise-generic? that's the only one newer than the lts backports kernel
<Sarvatt> the lbm-cw packages are compiled against 3.2 kernel updates each time
<tyf> so there's none that are compiled against kernel 3.5?
 * apw yawns
<apw> smb, there is no good reason to not build the DM delay and flakey personalities is there?
<smb> apw, Hm, don't think really. They become modules I suspect and then will only be used if someone actually builds a target with them. Which pretty much is another painful and manual process.
<apw> smb, that fits my thinking too, thanks
<smb> tjaalton, Not sure how/where/what exactly to report but I noticed on my sdp that using the quantal X stack and kernel on Precise running from a SSD is booting pretty fast and comes up ok but when rebooting or shutting down I see a dialogue telling me the system would only run in low-graphics mode (and it definitely was not doing that)
<apw> smb, so you see a new X server with "you are in low graphics mode", doe that have to be acknowledged or does the reboot/shutdown complete
<tjaalton> smb: I guess it's plymouth's fault
<smb> apw, It does go on but if you are quick you could confirm the first screen
<apw> smb, and do you get the 'dots' if you confirm it ?
<tjaalton> it has some hardcoded checks for 'i915'..
<smb> apw, No, I get the second dialogue asking me what "other" config to use. And I was not quick enough to click before that was shot down
<apw> smb, ok :)
<smb> tjaalton, We had been wondering whether X may go away too quickly because other people with that combo but slower disks do not see that
<smb> tjaalton, Or I did something wrong when pulling the new stacks...
<apw> smb, i think file a bug against plymouth and see what happens
<apw> smb, and mention it to slangasek
 * smb thinks what happens will be a response saying "you are running crack"
<smb> But anyway, I will try
<apw> smb, it is going to be a supported combination ...
<tjaalton> right, and I haven't seen that bug with quantal
<tjaalton> though I sometimes get the same dialog when it boots up
<apw> smb, any idea whether it makes sense to have CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES turned on
<smb> apw, Err, not really have an idea what that would be...
<smb> apw, Sounds very useful for crashing your system when unaware but interesting create unusual setups...
<apw> smb, yeah, i think as it is on i will leave it alone ... even if it is a bit scarey
<smb> apw, True and probably there are more evil things that you can do when you can modify the kernel command-line...
<smb> slangasek, tjaalton I filed bug 1086345 for the x-lts-quantal oddity I see. If there is more I should do, please let me know
<ubot2> Launchpad bug 1086345 in plymouth (Ubuntu) "Quantal-LTS-stack: Showing low-resolution screen on shutdown/reboot" [Undecided,New] https://launchpad.net/bugs/1086345
<apw> cking, i assume we have SLUB_DEBUG turned on for a reason ... 
<cking> apw, hrm, can't recall exactly when we enabled that
<rtg> apw, ogasawara: pushed -rc8. build testing.
<cking> apw I would be more concerned if SLUB_DEBUG_ON was enabled, that turns it on by default
<apw> cking, SLUB_DEBUG on, i believe _ON is off
<cking> apw, if we are concerned about the performance penalty of SLUB_DEBUG I can look at that
<apw> cking, i was more interested to know it was a concious decision
<cking> apw, it wasn't a conscious decision that I can recall
<apw> then ... low low on your list, perhaps test it
<cking> apw, if it's not on for previous releases we should disable it for the moment I reckon
<herton> cking, apw, I believe it has been always enabled on our config (SLUB_DEBUG), it's helpful to debug some memory corruption cases passing slub_debug on commandline, like double frees, I recall it being useful once to me
<herton> but not sure about the performance impact, if it has some then probably should be disabled
<cking> in which case, let me assess the overhead, if its is unnoticeable then it's a useful to have feature
<apw> cking, herton, works for me
<xnox> what is the procedure to get an account on kernel.ubuntu.com ?
<rtg> xnox, beg #is via an RT ticket.
<xnox> rtg: sounds like a good plan =)
<xnox> thanks.
<herton> rtg, that commit you mentioned yesterday (bc78c57), do you saw a problem it fixes? I can forward to stable
<rtg> herton, no specific problem. I was looking at backporting TRIM support for md arrays and noticed that its likely a good bug fix.
<herton> rtg, ok, will ask for inclusion
 * henrix -> lunch
 * apw wanders out to get some fresh air
<Konstigt> is there any ppa with 3.7 for 12.10? or are rarings kernels OK on 12.10 perhaps?
<tjaalton> smb: thanks, subscribed
<rtg> Konstigt, there are raring kernels for 12.04 at https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport
<ogasawara> rtg: I was thinking we should upload today.  lemme know if your test build was successful and I can test on some kit here and then prep the upload.
<rtg> ogasawara, I've got x86en built on tangerine. lemme stash it on zinc in a sec and I'll give you an URL
<henrix> kees: i'm getting a build error on arm platforms for precise regarding your "seccomp: forcing auditing of kill condition" commit
<henrix> kees: https://pastebin.canonical.com/79684/
<henrix> kees: any suggestion?
<rtg> henrix, you might be a bit early in the day for him
<henrix> rtg: ah, right :)
<rtg> ogasawara, cking, apw: http://kernel.ubuntu.com/~rtg/3.7-rc8.1/
<ogasawara> rtg: ack
<cking> rtg, want me to exercise this on a bunch of machines?
<rtg> cking, please
 * cking rummages around for some H/W
<henrix> does anyone know the rational for not having CONFIG_AUDITSYSCALL on arm configs?
<henrix> i believe this is what is causing the build failure
<rtg> ppisati, ^^
<ppisati> henrix: hold on
<henrix> ppisati: thanks
<ppisati> henrix: config AUDITSYSCALL bool "Enable system-call auditing support" depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH)
<ppisati> henrix: ARM was not supported back then
<henrix> ppisati: heh, ok. i should have checked that myself :)
<henrix> ppisati: thanks.
<cking> rtg, kernel seems good on atom n450, ivybridge + sandybridge H/W, will exercise it on some AMD kit now
<rtg> cking, ack. thanks
<rtg> ogasawara, cking,apw: I'm gonna have to respin Raring with arges ticket_spinlock (fsnotify) patches.
<cking> rtg, tested on a bunch of older kit too (AMD, etc) works fine, boots, S3, S4, audio, network
<cking> ah, more to test :-)
<ogasawara> rtg: ack
<ogasawara> rtg: previous build tested fine on my kit here
<apw> rtg ack
<rtg> cking, yeah, the ticket_spinlock tests might require more manula USB plugging, etc
<cking> ack
<arges> rtg, there is a script that reproduces the issue easily. I've tested this set of patches with that but would like to do more testing
<arges> rtg,  cking : in addition do some performance tests if we can.
<cking> arges, such as?
<arges> cking, not really sure : ) have to think of something fs notify related
<janimo> rtg, I am removing the ubuntu nexus tree from its former location in hwe/ , no objections right?
 * janimo goes to update the wiki as well
<rtg> janimo, go ahead
<apw> arges, the point is that fsnotify is in the way of _all_ operations if its enabled
<apw> arges, so if you ask for "read/write" notification for instance
<apw> which isn't common but is possible
<arges> apw, yea I think I can look at the test case, and try to write something
<arges> apw, start time, inotify_add_watch , access file/directory, inotify_rm_watch
<apw> yeah
<apw> arges, with multiple read/writers in there
<rtg> ogasawara, cking, arges, apw: http://kernel.ubuntu.com/~rtg/3.7-rc8.2/ for the fanotify version
<arges> rtg, downloading
<ogasawara> rtg: ack
<ppisati> brb
 * rtg relocates...
<Konstigt> rtg: thanks but I have 12.10/Quantal
<rtg> Konstigt, you can still install the kernel debs from either archive, but you won't get automagic updates via meta packages.
 * ogasawara back in 20
<Konstigt> rtg: aha, so the kernel isn't really bound to the release and vice versa. so then just downloading the needed files from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc8-raring/ should work.
<rtg> Konstigt, yep
<rtg> the 'raring' part simply means that it was built using the raring config. I think all mainline are built using the Precise toolchain.
<apw> they are built using the previous LTS' tool chain
<rtg> so, either Lucid or precise
<apw> yes
<Konstigt> thanks
<apw> (in theory it would also use hardy, but ... i don't think we every make things that old)
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> its tuesday _again_ ?
<jsalisbury> heh
<smb> apw, Its _that_ late again, too
<apw> seemingly indeed
<jsalisbury> bjf, smb, it looks like bug 1034099 is due to commit ffaf6a1e73719e0250fce7b52015187180a77fe9 
<ubot2> Launchpad bug 1034099 in linux (Ubuntu Quantal) "Kernel panic with ulatencyd on kernel 3.2.0-29-generic" [High,In progress] https://launchpad.net/bugs/1034099
<smb> jsalisbury, Yeah, somehow I stopped worrying when I saw that...
<jsalisbury> smb, is that commit something we can revert ?  If so, I can submit an SRU request.
<smb> jsalisbury, Gosh I should read better (commit != comment)...
<jsalisbury> smb, its this SAUCE:
<jsalisbury> commit ffaf6a1e73719e0250fce7b52015187180a77fe9
<jsalisbury> Author: Stefan Bader <stefan.bader@canonical.com>
<jsalisbury> Date:   Tue Jul 3 15:01:58 2012 +0200
<jsalisbury>     UBUNTU: SAUCE: sched: Fix race in task_group()
<smb> Oh f**k, I would not want that reverted but there was something messed up by it and I really cannot say right now what exactly it was
<cking> rtg, that kernel works OK on a bunch of laptops, atom, sandybridge, ivybridge, amd64.  however my sharkbay desktop gets video corruption and seems to lock up (tried it now 4 times)
<rtg> cking, does the kernel in .1 have teh same issue ?
<cking> rtg, yep
<rtg> cking, ok, so at least it wasn't introduced by the fanotify patches
<cking> I didn't get around to test it until just now 'cos I was exercising it on a bunch of other tests
<bjf> cking, sharkbay is haswell?
<rtg> cking, does the sharkbay work with ogasawara's Oneiric haswell pile ?
<bjf> cking, i don't think all of ogasawara's haswell patches are in raring
<jsalisbury> smb, the bug affects precise and quantal.  I'll find out if it also affects raring.
<ogasawara> rtg: all the haswell patches I pulled won't land until 3.8 opens
<cking> bjf yes, rtg no, but it used to work on earlier raring kernels
<bjf> huh
<rtg> indeed, huh.
<rtg> I'm gonna ignore it for now
<cking> sorry, that was not clear
<cking> no, as in I never sucessfully tested this box last week, so no, I am not sure, but it was booting fine on earlier 3.7 kernels
<smb> jsalisbury, I thought I had someone with a boot oops because of that and thought at that point some additional upstream change was found... 
 * cking wonders if this is going to be the last -rc for 3.7
<rtg> cking, mebbe
<smb> jsalisbury, Do we have this one pulled: commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12
<smb> Author: Mike Galbraith <efault@gmx.de>
<smb> Date:   Mon Dec 3 06:25:25 2012 +0100
<smb>     Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
<smb> ... stupid question as that was in the precise tree..
<bjf> smb, nope
<smb> Hm, ok seems something from 3.7-rc8...
<smb> jsalisbury, So can we instead try the other revert which should be queued for stable afaics
 * smb curses and rushes over to the other irc meeting
<jsalisbury> smb, so put your patch back and then apply fd8ef11730f1d03d5d6555aa53126e9e34f52f12
<smb> jsalisbury, Yeah, which reverts the other thing actually
<jsalisbury> smb, got it.  thanks
<jsalisbury> smb, I ran into an issue when cherry-picking commit: fd8ef11730f1d03d5d6555aa53126e9e34f52f12
<jsalisbury> smb, git diff says:
<jsalisbury> * Unmerged path kernel/sched/auto_group.c
<jsalisbury> * Unmerged path kernel/sched/auto_group.h
<jsalisbury> smb, I can manually revert commit 800d4d3 without an issue
<rtg> jsalisbury, clean your tree first ?
<jsalisbury> rtg, I did a fresh clone
<jsalisbury> of the precise tree on tangerine
<smb> jsalisbury, Oh well, could be because Peter was bored and renamed most of the files about 3.5
<smb> so things moved from kernel into kernel/sched
<jsalisbury> smb, ahh.  Can I just do the revert of commit 800d4d3 myself, and have that tested?
<jsalisbury> smb, Or I can just fix things up after the cherry pick
<smb> wonder whether the lazy fixup of git format-patch <revert>, git am <upstream> -> fail , patch < <export> works
<smb> jsalisbury, just reverting the change would work as well for testing. Mainly its to have the upstream changelog (but that could be done later)
<jsalisbury> smb, ack
<apw> rtg, remind me the nature of the USB_OTG badness when enabled on x86
<rtg> apw, I think its because there _isn't_ an OTG on x86 platforms.
<infinity> Oh hey, do I get to drop my UAPI hacks from glibc after the next linux upload?  Did that land?
<rtg> apw, this must be for you? ^^
<infinity> Either of you. :P
<infinity> rtg: I expect you to know every line of the every kernel rc.  Sheesh.
<apw> UAPI: strip the _UAPI prefix from header guards during header installation
<apw> infinity, thats what you are hoping for i believe 
<apw> v3.7-rc8~27^2~6
<apw> which is in ^^ .... ie in -rc8 and our next upload
<infinity> apw: That'd be the one.
<smb> bjf, sconklin <arosales> smb: is kernel team going to be using UTAH in their testing?  (perhaps smb can provide some more context)
<ogasawara> rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084640
<ubot2> Launchpad bug 1084640 in linux (Ubuntu Raring) "linux: 3.7.0-5.13 -proposed tracker" [Medium,In progress]
<ogasawara> rtg: in the future, you'd just run create-tracking-bug or whatever it's called and it'll shove the changelog entry for you
<sconklin> smb: not in our team testing environment for the foreseeable future. the QA team does theirs differently, and may use it for their kernel tests
<apw> sconklin, i thought we had like a shim between utah and our tests so we use the same tests in both environments; right?
<apw> (but not using it indeed)
<sconklin> apw: the same tests can be run in both environments, all the kernel tests are under autotest client. Different ways of calling them are used in QU and out team
<bjf> smb, in a word, no
<smb> bjf, Ok, I can pass this on next week. :)
<smb> Or... hggdh ^
<bjf> smb, is there some feature of utah that would make me want to do so ?
<smb> bjf, I am merely the messenger here. No personal interest really in doing one or the other
<bjf> smb, should i talkto arosales directly?
<smb> bjf, Actually it was hggdh asking through arosales
<smb> bjf, Or I ping you before the next server-team meeting to join the fun on irc. :)
<bjf> well, that's just damn odd
<bjf> smb, not sure i can handle that much fun .. but sure
<smb> bjf, Maybe it brings a bit of the scary happy face back. :)
<bjf> lol
<rtg> apw, both raring branches pushed. I'm just gonna wait to upload until my armhf test build is done.
<rtg> about 30 minutes I expect
<apw> rtg, ack
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 11th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati goes out for a bit
<hallyn> rtg: is raring master-next supposed to build right now?
<hallyn> (from last night actually) 
<rtg> hallyn, yep. are you having issues ?
<rtg> hallyn, just pushed -rc8 this AM
<hallyn> yeah seemed to complain about a missing file,
<hallyn> ok i'll merge that, thanks
<hallyn> far prefereable anyway
<rtg> hallyn, hmm, I've been building it pretty regular
<hallyn> rtg: I got gcc: error: lib/oid_registry.c: No such file or directory
<rtg> hallyn, in a PPA, right ?
<rtg> apw and I have encountered that same error. restarting the build makes it go away.
<hallyn> rtg: yeah ppa..  huh.  ok thanks :)
<apw> hallyn, has to be a missing dep in the kernel makefiles somewhere
<rtg> apw, the PPA's are -j1 aren't they ?
 * apw would have thought not, we check the number of CPUs don't we in the packaging
<rtg> apw, ifeq ($(wildcard /CurrentlyBuilding),)....
<rtg> oh, that has changed
<rtg> apw, indeed, you are correct.
<apw> rtg, am pretty sure you did that :)
<rtg> apw, you're prolly right.
<apw> rtg, actually that /CurrentlyBuilding is about whether we make udebs and the like, and i added that to speend up normal builds
<apw> rtg, but its years old
<rtg> apw, we _used_ to use it to determine parallelsim. it likely is still that way in hardy
<apw> ahh ... :)
<rtg> apw, Iv'e been playing with parallel builds in lib, but can't get it to break.
<apw> wierd
<apw> i wonder if it is also used from outside of lib without deps
<apw> they do that kind of thing sometimes ... #include ../xxx/foo.c
<apw> and the like
<rtg> apw, perhaps during the headers install phase ?
<apw> seems odd, but ...
<rtg> apw, you'd think it would complain about not being able to find oid_registry_data.c (which is generated)
<apw> i need to see a full log which has this in
<apw> rtg/hallyn if you get one again do download the log before restarting it
<rtg> apw, there isn't a lot of info in it
<apw> i want to see the order things occured
<apw> if you have one
<hallyn> apw: i haven't restarted the one so you can get the log from this morning,
<hallyn> apw: https://launchpadlibrarian.net/124867223/buildlog_ubuntu-raring-amd64.linux_3.7.0-5.13ubuntu1userns2_FAILEDTOBUILD.txt.gz
<apw> $(obj)/oid_registry.c: $(obj)/oid_registry_data.c
<apw> rtg, that is wrong isn't it ?
<apw> note the $(obj)/oid_registry.c ... that file is in $(src)/
<rtg> apw, I was just trying to figure that out. gonna build with V=1
<apw> so i think that apparent dependancy is non-effective
<rtg> apw, seems reasonable. why would it _ever_ work ?
<apw> they are likely started in the right order by luck
<apw> so as long as we are doing things in the stack which take a while it will finish
<apw> as the execution engine in make is limiting self to 10 builds or whatever
<apw> yeah i think that line should be:
<apw> $(src)/oid_registry.c: $(obj)/oid_registry_data.c
<apw> and i think that should fix it, if you can reproduce it
<rtg> yeah, just changed it. gonne give it awhirl
<rtg> apw, well, it didn't break 'make M=lib -j'
<apw> heh
<apw> rtg, though i am slightly unsure if it should be $(obj)/oid_registry.o: in reality
<rtg> that actually makes more sense rule wise
<apw> as you do not remake the oid_registry.c, it is the same, but you do remake the .o
<apw> rtg, no
<apw> rtg, the .c does depend on it, cause you need it made before the other .c is usable
<apw> rtg, so .c is right
<rtg> apw, I think either is correct
 * apw gets a headache
<apw> yeah cause you write
<apw> foo.o: foo.c bar.h
<apw> and that is what we are trying to write here
<apw> you don't write
<apw> foo.o: foo.c
<apw> foo.c: foo.h
<rtg> apw, '$(obj)/oid_registry.o: $(obj)/oid_registry_data.c $(src)/oid_registry.c' ?
<apw> there is an implicit rule for the first oid_registry.c
<apw> so you don't need that i don't believe
<apw> $(obj)/oid_registry.o: $(obj)/oid_registry_data.c
<rtg> apw, on;y if the rule is '::'. right ?
<apw> that sounds reasonable
<rtg> $(obj)/oid_registry.o:: $(obj)/oid_registry_data.c
<rtg> that seems to work.
<apw> rtg, there are no examples of :: in the kernel Makefiles, so i susspect they are avoiding them
<apw> so if your '$(obj)/oid_registry.o: $(obj)/oid_registry_data.c $(src)/oid_registry.c' works i would use that
<hggdh> bjf, smb: I have no problems with the kernel tests being out of UTAH. This was a question arosales asked me and smb
<rtg> apw, maybe I'll have lunch first and then send something upstream.
<apw> rtg ack
 * rtg -> lunch
<hallyn> rtg: apw: weird, I just fetched raring master-next, but it does not have 3.8...
<hallyn> rtg: the dev_change_net_namespace patch was just applied by dmiller to the netdev tree, fwiw
<apw> hallyn, 3.8 ?  v3.7-rc8 you mean ?
<apw> bjf, w
<apw> bjf, am i reading this right that this week is prep week for SRUs ?
<bjf> apw, saved
<bjf> apw, yup!
<apw> bjf, is slightly confusing because it is listed as the 'week of the 6th' ... thanks
<bjf> apw, where do you see it? on the interlock schedule?
<apw> yeah on the interlock schedule RR/ReleaseInterlock on the wiki
<hallyn> apw: oh, i misread then.  i was thinking it was going to be 3.8
<hallyn> thanks
<hallyn> silly me :)
<bjf> apw, yes, that's because releases happen on thursdays so the calendar goes from thursday to thursday
<bjf> apw, it was/is a release manager thing
<apw> bjf, my head is made to hurt by it ... thanks
<apw> bjf, is henrix on the hook for kernel prep this week ?
<henrix> apw: i am
<bjf> apw, yes, something in particular you are interested in?
<apw> i may have something urgent for precise
<apw> can we spin that one last ?
<henrix> apw: well, too late now :) but we can respin it if required
<henrix> apw: do you have any idea about when you may have something? i can ping you on thursday about this
<apw> henrix, i hope to have it out for review in the AM, and should know the testing is confirmed (we have tested but waiting on the reporter) by EOD tommorrow i hope
<henrix> apw: ok, cool. let me know about it.
<apw> henrix, will do, and thanks
<henrix> np
<apw> henrix, and do remember to ping me :/
<henrix> apw: heh, i will
<apw> ogasawara, rtg, ok i have just pushed the first slab of 3.7 config review updates to raring
<rtg> apw, ack
<apw> it builds to udebs for me on x86 and armhf, ymmv
<ogasawara> apw: ack, thanks
<rtg> apw, 'PATCH 3.7-rc8] lib/Makefile: Fix oid_registry build dependency' fired upstream
<apw> rtg nice
<rtg> apw, the double colon rule was wrong by the way.
<apw> rtg, heh good to know
<apw> what did you go with in the end
<rtg> apw, just the simplest change, e.g., .o
<rtg> pushed it to raring master-next
<apw> ahh great
<rtg> apw, Howell introduced it in -rc1 with the signed modules patch set (I think)
<apw> rtg hence it feels like a new issue
<rtg> yep
 * rtg bugs out for the day
 * apw wanders off too
<apw> BenC, i am doing some config cleanup work on master, i also have the equivalent in the works for PPC for once you are rebased to -5.  i'll get a pull request to you, so feel free to ignore the config fixes on master i'll do them
<BenC> apw: rebased and uploaded on -5 already
<apw> BenC, sweet, then i'll get the config fixes done tommorrow and out to you
<BenC> apw: thanks
#ubuntu-kernel 2012-12-05
<rbasak> apw: hello! I see that you've dropped the highbank kernel, but I don't see a generic replacement. What's the plan with this?
<apw> rbasak, morning, thats a conundrum indeed.  something that is under discussions of a sort
<rbasak> apw: I thought we could just turn on a generic armhf flavour?
<apw> rbasak, in theory indeed, and someone is investigating it
<rtg> ogra_, are you gonna send your config patch to the kteam list ?
 * henrix -> SIGFOOD
<ogra_> rtg, will do
<ogra_> rtg, sent (as you might have seen) ... dont ask why i didnt make it a module ... 
<rtg> ogra_, ack
<robher> ogra_: when do expect the flash-kernel fix to go in for quantal?
<ogra_> robher, end of the week latest, i have some other SRU bits i want to pull in as well
<robher> ogra_: great. Thanks.
<apw> henrix, i think rtg has commited that patch i was talking about for precise
<henrix> apw: yep, i've seen it. i'm already on that. thanks
<apw> henrix, thanks indeed
<henrix> apw: btw, is there an easy way for me to cancel a build? i've just realised i'm using the ppc builders for precise kernels, which will be dropped later
<apw> i think they may well have a cancel button actually
 * henrix looks again...
<apw> if you get me the link which looks like this one
<apw> https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035989
<apw> i'll find someone to wack it
<henrix> apw: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035989
<apw> heh ..
<henrix> and also https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035994
<apw> both of those, ok
<henrix> thanks. its just that there's not point keeping them building :)
<apw> henrix, there is not indeed
<apw> and we are short some computrons in powerpc right now
<henrix> apw: yeah, i'm currently blocking a ppc. a 'cancel' would be a nice thing to have..
<apw> yeah i concur
<henrix> apw: ah, but someone did something, right? because the build failed
<henrix> or was that a genuine failure...?
<apw> rtg, whats the cross build tools called for arm on x86 ?
<rtg> gnuabi something...
<apw> henrix, no that was 'me' i got them to 'terminate' it... basically they rm -rf /build on the builder
<ogra_> arm-linux-gnueabihf-
<henrix> apw: ah! cool :)
<henrix> thanks
<apw> ogra_, is that the package ?
<ogra_> gcc-arm-linux-gnueabihf is the package
<ogra_> arm-linux-gnueabihf- is the CROSS_COMPILE prefix
<apw> b infinity 
<smb> apw, That is a big wish
<apw> heh indeed
<rtg> apw, https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport
<apw> ahh great
<ppisati> brb
<rtg> cking, drivers/acpi/acpica/dsmethod.c acpi_ds_create_method_mutex() looks like it could orphan memory
<rtg> I've got a patch if you agree with my assessment
 * cking has a look
<rtg> diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
<rtg> index aa9a5d4..fe89ea9 100644
<rtg> --- a/drivers/acpi/acpica/dsmethod.c
<rtg> +++ b/drivers/acpi/acpica/dsmethod.c
<rtg> @@ -151,6 +151,7 @@ acpi_ds_create_method_mutex(union acpi_operand_object *method_desc)
<rtg>  
<rtg>         status = acpi_os_create_mutex(&mutex_desc->mutex.os_mutex);
<rtg>         if (ACPI_FAILURE(status)) {
<rtg> +               acpi_ut_delete_object_desc(mutex_desc);
<rtg>                 return_ACPI_STATUS(status);
<rtg>         }
<rtg> cking, raring (by the way)
<cking> that looks sane to me
<cking> the patch
<rtg> cking, k, I'll send it upstream
 * ppisati -> gym
<henrix> apw: just fyi, the precise kernel is now building
<apw> henrix, great thanks
<henrix> np
<stgraber> hey there
<stgraber> I just found a weird kernel bug, introduced by 3.7 (AFAICT, wasn't there in 3.5 at least)
<stgraber> http://paste.ubuntu.com/1412921/
<stgraber> I tried to reproduce this outside of arkose but can't seem to hit it. arkose does quite a bunch of mounts including some bind mounts, loop mounts and overlayfs mounts, then spawns an lxc container, exits and unmounts everything and cleans up
<stgraber> AFAICT nothing is failing, it just appears that the umount triggered against the loop device doesn't actually free it
<stgraber> and there's apparently no way of ever freeing it short of rebooting the machine
<rtg> stgraber, perhaps hallyn or apw have some thoughts.
<stgraber> which is a bit of a problem for me considering we have a default of 7 loop devices and I tend to use dozen of those containers a day ;)
<apw> no not seen any issues with loops on raring getting stuck so far anyhow
<apw> stgraber, what is arkose ?
<apw> stgraber, and does fuser -c say anything about /dev/loop0 in that case
<stgraber> root@lantea:~# fuser -c /dev/loop0 
<stgraber> root@lantea:~# 
<stgraber> apw: arkose is basically a python wrapper setting up an lxc container sharing the rootfs with your machine using overlayfs so that anything you do in it won't affect your machine
<stgraber> so basically a simple lxc based sandbox
<stgraber> my current guess is that something goes wrong when the rootfs of an lxc container is on overlayfs with the upperdir stored on a loop device but I need to write some script to reproduce this outside of arkose
<apw> stgraber, be interested in what you find
<stgraber> (running the same test using arkose but without the overlayfs or without the loop mounted ext4 doesn't trigger the bug)
<hallyn> stgraber: interesting
<hallyn> how is the overlayfs delta 3.5..3.7?
<stgraber> alright, got a reproducer outside of arkose, it's really weird though :)
<stgraber> hallyn, apw: http://paste.ubuntu.com/1412975/
<stgraber> hallyn: the really weird thing is that if you replace my 'su nobody -c "hostname"' by just 'hostname', the bug won't happen :)
<hallyn> stgraber: does the umount mount/test actually succeed?  
<stgraber> hallyn: would be great if you could try to reproduce on your side as it's clearly happening on all my machines here, but the fact that calling "su" seems to make a difference makes me think it could be sssd related (which I assume you don't have)
<stgraber> yep, everything succeeds
<hallyn> stgraber: that's on raring right?
<stgraber> yep, raring with latest 3.7 kernel
<hallyn> ok
<stgraber> I don't get this on 3.5
 * hallyn doth protest to authenticating to download text version of script
<hallyn> hm, can't seem to launch an instance...
<hallyn> stgraber: well, definately confirmed...
<stgraber> yay!
<hallyn> not yay :)
<stgraber> well, I like to have reproducable bugs that don't depend on my really weird setup
<hallyn> :)
 * rtg -> lunch
<jsalisbury> herton, bjf, reverting commit a4e4c2b5 fixes bug 1080530 . 
<ubot2> Launchpad bug 1080530 in linux (Ubuntu Precise) "v86d prevents suspend from completing" [Medium,Triaged] https://launchpad.net/bugs/1080530
<jsalisbury> herton, bjf, Do you want me to submit an SRU request for Precise, or I could also request a revert upstream?  Or both?
<herton> jsalisbury, looking, I think it's worth to do both
<bjf> jsalisbury, that's a stable patch, so both for sure
<bjf> jsalisbury, possibly an email with the original patch submitter pointing them at the bug
<jsalisbury> bjf, email the patch submitter first to get feedback, then request a revert if that is what they think is best?
<bjf> jsalisbury, yup, you've missed this cycle so you have a little time before the next
<jsalisbury> bjf, ack
<bjf> herton, that work for you?
<herton> bjf, sure, no problem
<bjf> jsalisbury, you might want to CC ben h.
<jsalisbury> bjf, will do.
<jsalisbury> bjf, herton, thanks!
<ogasawara> rtg: fyi, herton is still working on shank bot for our automated upload announcements, so I'm just gonna craft and send an announcement for yesterday's upload.
<rtg> ogasawara, ok. I guess 'cause it wasn't an ABI bump I didn't ..., or wait . was it ?
<ogasawara> rtg: it was, I thought
<rtg> oh, huess it was.
<rtg> guess*
<rtg> dang, I get used to infinity just noticing with me pestering him.
<rtg> without*
<rtg> ogasawara, so the bot is supposed to send out email when the packages transition from -proposed if the tracking bug is in the changelog ?
<ogasawara> rtg: it's my understanding it'll send it once it detects the package has successfully built in proposed
<bjf> ogasawara, correct
<rtg> ack
<rtg> bjf, which might be premature if it takes awhile to get promoted. won't some folks wanna use it immediately upon announcing ?
<herton> rtg, we might do the announcement when it hits the release pocket instead, for the devel kernel, is that ok?
<rtg> herton, I think that would be better. nobody should be updating from -proposed in the devel release.
<herton> rtg, hmm, that may defeat bjf automatic testing, that we want to start when it hits -proposed I guess. But that's fixable sending the special email to the bot, and an additional to QA.
<rtg> herton, I suspect the bot is becoming somewhat complex.
<bjf> herton, i'd like to do the testing while it's in the -proposed pocket
<bjf> rtg, lol, you have no idea
<bjf> rtg, right now we are announcing when we do the upload, before it even hits -proposed in some cases
<bjf> rtg, we do that to give the installer folks a heads-up. the purpose of doing it with shanky is to kick off automatic testing while also giving installer and other interested parties a heads-up
<rtg> bjf, I don't have a real strong case to delay the announcement, so I guess go ahead and do it when its done building.
<bjf> rtg, ack, when it is available in -proposed
<herton> ack
<rtg> yep
 * rtg -> EOD
<bizhanMona> HI I am using ubuntu 12.04. To DMA large raw video frames from capture device (PCIe device) to host memory, I may need large contiguous phyiscal memory area large than 4MB(page size). How is this possible?
<arges> bizhanMona, i'm assuming this is for a device driver?
<arges> might want to check out free-electrons.com/doc/books/ldd3.pdf
<bizhanMona> arges: yes it is for device driver. I did not find it in any references including ldd3.pdf, but will check again to make sure. Thanks
#ubuntu-kernel 2012-12-06
 * henrix -> lunch
<ppisati> brb
<arges> rtg, hi. I noticed that those 9 fsnotify patches landed in raring, when does the state of bug 922906 change to reflect Fix Commited/Released ?
<ubot2> Launchpad bug 922906 in linux (Ubuntu) "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [High,In progress] https://launchpad.net/bugs/922906
<rtg> arges, thy'll go to fix released when the kernel is promoted out of -proposed. apw tells me we are frozen for kubuntu/edubuntu betas right now.
<rtg> should get relaxed today I think
<arges> rtg, ok cool. should I wait for that to get those SRUed for precise/quantal?
<rtg> arges, it wouldn't hurt to get a little testing, but you might as well start the SRU process.
<arges> ok thanks
 * ppisati back in 20
<rtg> ogasawara, so what is the advantage of dropping beta milestones if kubuntu/edubuntu can put a freeze on the archive? I uploaded on _Monday_ . That kernel is still stalled in -proposed. wtf ?
<ogasawara> rtg: in theory, we are not supposed to be bottlenecked by the flavors choosing to freeze for the optional alpha/beta milestones
<rtg> sounds more like a hypothesis then a theory.
<rtg> and a weak one at that
<rtg> bjf, seen this ? http://ltsi.linuxfoundation.org/what-is-ltsi
 * ogasawara back in 20
<infinity> rtg: It didn't actually prevent you from doing anything, did it?  The kernel built, and was just in proposed, s'all.
<rtg> infinity, but it wasn't getting any test time
<infinity> (Except in the rare case when your new kernel is fixing something that's specifically an ISO-image-only problem, I'm not sure I see the issue)
<rtg> infinity, nobody has -proposed enabled for the devel release
<infinity> Granted, I'd also prefer to see flavours not do alphas, but we'll revisit this again (and again) as time goes on.
<infinity> rtg: Sure, it gets less exposure while it's in proposed, not arguing that it doesn't.
<infinity> Anyhow, it'll move right shortly, the matching d-i is just publishing now.
<rtg> infinity, I saw that in the release channel
<rtg> thanks
<bjf> rtg, at uds wasn't it decided that there would be monthly milestones which flavours could opt in/out of?
<rtg> bjf, right. but opting in has the knockon effect of holding up the show for the other flavours.
<bjf> rtg, right, so aren't we going to have this issue every month?
<rtg> bjf, well, every alpha/beta milestone for sure
<bjf> rtg, i had seen the LTSI thing. it's something gregkh was initiating 
<rtg> cking, just wrote a patch for this: 'drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts 500 bytes on stack'. Do you agree 500 bytes is a bit much ?
<cking> rtg, it depends if we're in a leaf and so we won't push anything else onto the stack, and how short term the space is going to be used  I suppose
<cking> rtg, it is a hard one to call really, perhaps it's worth punting this patch as the data structures may grow over time rather than shrink, so it's not going to get better over time
<rtg> cking, yep, I'm gonna punt it upstream. they worst they can say is no. 
<cking> indeed
<cking> bah, oom'd my machine 
 * ppisati -> EOD
<rtg> sforshee, cking: please give me a quick review on 'UBUNTU: SAUCE: iwlwifi: iwlagn_request_scan: Fix check for priv->scan_request' which is tip of Raring master-next
 * rtg -> lunch
<cking> rtg, looks good to me
<rtg> cking, thanks
<sforshee> rtg, looking at the rest of the driver I get the idea that it might be attempting to support scan_request == NULL if scan_type != IWL_SCAN_NORMAL
<sforshee> the checking in that function is definitely broken though
<rtg> sforshee, it looked to me like that function would oops if scan_request were NULL
<sforshee> rtg, afaict only cases where scan_type == IWL_SCAN_NORMAL dereference the pointer, but I'm not 100% certain
<sforshee> but it also looks like scan_request is only set when a scan is invoked by mac80211
<sforshee> sometimes the driver starts scans internally, and I don't see those setting scan_request
<sforshee> I haven't had time to grok the whole thing yet though
<rtg> sforshee, ok, I'll look a little closer
<sforshee> rtg, I suspect maybe the condition should be (priv->scan_type == IWL_SCAN_NORMAL && (!priv->scan_request || priv->scan_request->n_channels > MAX_SCAN_CHANNEL))
<sforshee> rtg, probably worth running by Johannes & co. in any case
<rtg> sforshee, I think you're right about priv->scan_type == IWL_SCAN_NORMAL
<rtg> sforshee, repushed master-next if you'd have a look again. 
<EntropyWorks> so what is the process of adding network drivers to the nic-modules.udeb for the netboot install initrd.gz 
<rtg> EntropyWorks, start a bug report, then email the kteam list
<rtg> EntropyWorks, is it for a released kernel ?
<EntropyWorks> its for quantal 12.10. I originally have this bug which was precise https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1015339
<ubot2> Launchpad bug 1015339 in debian-installer (Ubuntu) "Missing kernel modules for Mellanox ConnectX HCA Ethernet " [Medium,Confirmed]
<rtg> EntropyWorks, so it requires SRU justification which means you have to have a bug report....
<EntropyWorks> in quantal besides not having the network driver it also wasn't able to find the local disk without me adding more kernel modules to the initrd.gz http://goo.gl/PfOZd. 
<EntropyWorks> point me to the URL and I will write one up :)
<rtg> EntropyWorks, start a bug by entering 'ubuntu-bug linux' from a command line
<EntropyWorks> gotcha
<rtg> EntropyWorks, preferably from the machine that requires these drivers.
<sforshee> rtg, that looks right to me
<rtg> sforshee, ack
<rtg> thanks
 * rtg -> EOD
<hallyn> stgraber: apw: I haven't had time to look deeper (hoping to tonight) but last night i was having a funky problem where a lot of stat+chown+chmod(stat.st_mode) ended up not retaining setuid/setgid on files in raring.
<hallyn> it was *probably* my fault, something stupid in userspace, but i'm nto convinced
* You're now known as ubuntulog
<apw> hallyn, chown would drop setid bits ... but
<arges> apw, hey.  still around
<hallyn> apw: right, and so i stat it before hand and, if i've chowned, then i chmod back to the original st_mode
<hallyn> works one file at a time, and used to work in a loop over a whole rootfs
<hallyn> only started failing yesterday <shrug>
<arges> apw, i have a 3 line cherry-pick that doesn't apply cause the file was moved, if I just apply it to the correct file it works. Is this still considered a cherry-pick or is it a 'backport'  (just trying to figure out how to format the commit)
<arges> apw, n/m i see (backported from commit XXXXX)
<bjf> arges, yeh, it's black or white. if it doesn't cherry-pick it's a backport
<arges> bjf, ok that makes sense.  so I should keep the original author?
<bjf> yup
<bjf> actually ...
<bjf> arges, in ones that i've done, i think i generally try to keep the original author
<bjf> arges, however, now that you ask that question, i'm not sure
<arges> bjf, ok well for now i'll build and test, tomorow i can clear it up before posting
<bjf> arges, i'm looking in the tree for an example
<apw> bjf, i tend to keep the original author, and sign it off and put the [apw@xxx: did this to it] stuff in
<bjf> apw, that's what i normally do as well
<bjf> arges, ^
<arges> apw, bjf ok thanks
#ubuntu-kernel 2012-12-07
<bjf> ogasawara, do you have the link to the driver testing kees was talking about at the knitting session?
<ogasawara> bjf: http://research.cs.wisc.edu/sonar/projects/symdrive/index.shtml
<doko> [42812.608959] do_general_protection: 51 callbacks suppressed
<doko> [42812.608961] runcheck[10709] general protection ip:5556bfcd sp:fff116e8 error:0 in ld-2.16.so[55555000+21000]
<doko> [43192.209887] runcheck[12370] general protection ip:5556bfcd sp:ffd0de78 error:0 in ld-2.16.so[55555000+21000]
<doko> apw: ^^^ I'm getting these dmesg's every few days, with high loads on the machine, if I don't reboot then, the machine locks up. Is there a way to nail that down? I did run a memory test overnight, so I hope to exclude bad ram
<apw> doko we'd want to find out what runcheck it, as that error implies something bad happend in userspace only, as far as the kernel is concerned --- though if you exprience a lockup after we may have handled it wrong indeed
<apw> doko, basically we would need to work out what the reproduce by is i think so we can do hunting as there is almost no clues there
<doko> apw, the runcheck is trying to run a x32 binary on a kernel which doesn't support it. but it's not always this, somtimes, I'll have a bunch of unreproducible compiler ICEs
 * cking out to lunch, back later
 * henrix -> (late) lunch
<ppisati> it's snowiiiiiiiinnnnggggggg.... :)
<ppisati> (sorry couldn't resisst...)
<tassadar_> we'll see about that after several weeks of ass-freezing cold)
<henrix> ppisati: 20 degrees around here!
<ppisati> henrix: it's really an event when it snows here... :)
<henrix> ppisati: yeah, i guess so.  good for a change. if you're not planning to travel, of course :)
<ppisati> henrix: fridge is full, water supplies are ok and i've a stable internet connection - i can survive :)
<henrix> heh true!
<rtg> sounds like the snowpocalypse is approaching.
 * ogra_ grins about south europe and snow
<rtg> ogra_, we got 19" in one day in mid November
<ogra_> we didnt have much yet, but the world is covered in white  since two weeks around here
<bambee> Hi, any solutions for random freezes on ivry bridge with the kernel 3.2 on ubuntu 12.04 ? It's just unusable at work
<rtg> bambee, have you treid the 3.5 LTS kernel ?
<rtg> tried*
<bambee> where can I find it ?
<ppisati> ogra_: you lucky guys...
<ppisati> ogra_: we'll get half day of snow and that's it, for the entire winter
<rtg> bambee, apt-get install linux-generic-lts-quantal
 * ppisati should move to north europe again...
 * ogra_ hates snow
<BluesKaj> Hi folks , I'd like to report the 3.7 kernel hangs my system immediately after the "Install Kubuntu" option on the Kubuntu 13.04 alpha AMD64 live cd, same goes for the mini.iso version, and I added myself to this bug in launchpad https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1081245
<ubot2> Launchpad bug 1081245 in ubiquity (Ubuntu) "Ubuntu 13.04 Live-CD Installer hangs" [Undecided,Confirmed]
<bambee> rtg: I will install it now, thanks.
<ogra_> having to get up early to shovel the sideway really sucks
 * ogasawara back in 20
<jsalisbury> smb, re bug 1034099 .  Commit fd8ef117 fixes the bug, so I don't think we will need to revert commit ffaf6a1e .
<ubot2> Launchpad bug 1034099 in linux (Ubuntu Quantal) "Kernel panic with ulatencyd on kernel 3.2.0-29-generic" [High,In progress] https://launchpad.net/bugs/1034099
<bipul> Hellow
<bipul> any one around?
<apw> rtg, sbuild-update -ug <chrootname>
 * henrix -> EOD
 * rtg -> lunch
 * cking -> EOD
<caribou> were the Hyper-V drivers present in kernel/staging officially 'supported' back in Lucid ?
<apw> i am unsure if they were even enabled
 * ogasawara lunch
 * rtg -> EOD
<slangasek> sforshee: macs arrived today
<bjf> slangasek, almost like xmas :-)
<slangasek> bjf: I told Santa I wanted a Carbon X1, instead I got a lump of coal ;(
#ubuntu-kernel 2012-12-08
<penguin42> There seems to be a triplet of people reporting the recent 3.5.0-20 update on Quantal is giving them odd oops in  ftrace/trace
<penguin42> bug 1087967, bug 1087622, bug 1087584   a bit worrying really
<ubot2> Launchpad bug 1087967 in linux (Ubuntu) "Kernel OOPS on intel 5 series/3400 leads to non working mouse" [Undecided,Confirmed] https://launchpad.net/bugs/1087967
<ubot2> Launchpad bug 1087622 in linux (Ubuntu) "Linux kernel 3.5.0-20 won't boot [unable to handle kernel paging request at f91fe4fc in trace_event_raw_init+0xb/0x20]" [Undecided,Confirmed] https://launchpad.net/bugs/1087622
<ubot2> Launchpad bug 1087584 in linux (Ubuntu) "linux-image-3.5.0-20-generic boot oops " [Undecided,Confirmed] https://launchpad.net/bugs/1087584
<bjf> henrix_`, ^ it does seem to be a pattern
#ubuntu-kernel 2013-12-02
 * apw yawns
 * apw curses "not actully suspending" machines
<smb> apw, Keeps your house warm
<smb> apw, Morning
<apw> it annoys one when it won't wake up and carry on, thats for sure
<apw> smb, moin
<apw> especially as this machine has a droppy keybaord when the battery is low
<smb> Yeah, even more annoying is apparently waking up but then showing all kinds of trouble. Like write errors to the disk... Ok last time that was the ssd imploded for some reason
<apw> ouch, noo  i do not need that in my morning, and don't thankfully have that at least
<smb> Who really needs that anytime. :-P
<apw> oh but think how much worse it is when you really need coffee, and you cant even login
<smb> Ok, minus my data which was luckily redundant, I got a bigger and faster replacement for free. :)
<smb> coffee... hm...
 * smb goes downstairs
<apw> oh they replaced it in the end, i'd forgotten about that day ... yeah sucky
<apw> particularly so without coffee
<smb> apw, You should have some... well or tea
<apw> having that indeed, mucho same
<dholbach> hiya
<apw> dh ... oh
<rtg> jsalisbury, I think all of these 'module verification failed' bugs can be marked 'fix committed' for saucy/trusty. (or marked as duplicate)
<jsalisbury> rtg, great, will do.
<rtg> jsalisbury, in fact, trusty has been uploaded with the fix in 3.12.0-4.12
<jsalisbury> rtg, even better :-)
<apw> rtg, all home safe ?
<rtg> yep, came home to a non-functional furnace. it was pretty chilly for awhile.
<apw> oh nasty ... been off too long and went off to sulk
<rtg> apw, pretty much
<apw> hopefully it was something simple and cheap to repair
<rtg> apw, mostly it was just recharging the pipes with water. found a small leak that I need to get fixed.
<apw> oh one of those, "oh
<apw> "oh yeah i have been represurising quite often"
 * apw relocates somewhere more comfortable
 * rtg -> lunch
 * smb -> gone
 * rtg -> EOD
<lfaraone> slangasek: so, 1.6.1 to 1.6.5 is effectively an upstream microrelease; the changes made are well-tested, and are actively in use on 12.04 LTS.
<lfaraone> slangasek: the reason my test case did not include testing every posible function of the new packages is because I was validating that the module worked on each **kernel version**, we already have lots of users running 1.6.5 on 12.04 in a variety of environments. 
<lfaraone> slangasek: our problem has been primarilly people getting the HWE stack without knowing it; I don't think many of our deployed users have hardware that requires it, but there's no obvious way for end-users to easily opt out of it.
#ubuntu-kernel 2013-12-03
<slangasek> lfaraone: opting out of the HWE stack == use 12.04.1 (or 12.04.0) media for install
<geofft> slangasek: these are nontechnical end users, they click the thing that says "Ubuntu", we don't get to tell them what to install until after they installed :-( 
<geofft> we put up a warning on our home page, but people will still go and install Ubuntu and then say "oh hm I want AFS" later 
<geofft> and they get the default obvious CD image from ubuntu.com 
<geofft> ... actually _I_ can't figure out how to get 12.04.x for x<3 from http://www.ubuntu.com/download/desktop 
<geofft> alternative downloads | past releases takes me to releases.ubuntu.com, and that just give sme 12.04.3 
<infinity> geofft: Bottom of the page, "Take a look at a full list of our previous versions and alternative downloads".  And agreed, that's not even remotely intuitive.
<geofft> infinity: I don't think it's there! 
<infinity> geofft: It is, bottom of THAT page, "past releases..."
<geofft> keep clicking. it's not there. 
<infinity> Which... Then goes to releases.u.c, which remains unhelpful, you're right.
<infinity> *sigh*
<geofft> Oh! I go to "unsupported Ubuntu images". 
<infinity> For the record, it's on old-releases.
<geofft> That gets me 12.04.0 for ... powerpc, nevermind 
<infinity> The link right under the one you clicked. :P
<infinity> Anyhow, we need to make this experience far less crap.  I have a todo item for that.
<geofft> Yeah, I am going to politely disagree with the claim that it's possible for an end user to figure this out. We're in the position of downgrading kernels post-install 
<geofft> Or, really, just having people install OpenAFS from an alternative source, which is what we're doing now. (I think our installer shell script sets up the PPA) 
<infinity> Well, it's *possible*, but I'll agree that it's not *plausible* that most will figure this out.
<geofft> And yes, afaik (which is not very rigorously, to be fair), our users tend not to have hardware that requires the HWE stack 
 * apw whines
<xnox> slangasek: the fact that ubiquity installer doesn't show anywhere which version of ubuntu is installed, is not helpful either =)
<pkern> Hey. https://help.ubuntu.com/community/Kernel/Compile#Modify_the_source_for_your_needs seems a bit outdated. If I have a linux-lts-raring apt-get source'd, how would I modify the kernel config? Somehow all files I find have a splitconfig.pl header.
<apw> pkern, add the option you want to change to the apporpriate leaf file in the config, and then run 'fakeroot debian/rules updateconfigs'
<apw> which will sort out making the configs consistant
<ppisati> bug 1250495
<ubot2> Launchpad bug 1250495 in flash-kernel (Ubuntu Trusty) "armhf: highbank: relocate initrd to make room for a bigger kernel" [Undecided,New] https://launchpad.net/bugs/1250495
<ppisati> infinity: ^
<ppisati> infinity: i just met the same problem with a T kernel on midway, any chance you can give it a look?
<infinity> ppisati: Yeahp, remind me again in ~4h, I'm running out to an airport (picking someone else up for once, not flying anywhere myself).
<infinity> Assuming I survive the trip there and back... The snow here is insane today.
<ppisati> infinity: ack, i'll do
 * ppisati is envious of your snow :P
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 30 minutes
<jsalisbury> ##
<olli> hey, I am looking for a pointer how to catch a "swivel" event on a Dell XPS 12 (where the screen flips horizontally and turns it into a "tablet")
<olli> I have tried to listen to /dev/input/event* and also looked in /proc/bus/input/devices for pointers
<olli> is there another common place to look at?
<sforshee> olli: I'd expect dell-wmi to be receiving the events. If it's an event dell-wmi understands it will probably show up on the input device it creates.
<sforshee> olli: otherwise it would need to be taught about the event
<sforshee> olli: but you might also try running acpi_listen and see if it spits out anything
<olli> sforshee, ah, forgot to mention that acpi_listen didn't produce anything
<olli> sforshee, is it a valid approach to just cat /dev/input/event* and see if something happens or would cat miss something?
<olli> event* = a single event dev, e.g. event10
<sforshee> olli: that might not work. X grabs the input devices so that nothing else sees the events.
<sforshee> olli: what I usually do is install input-utils, swtich to a vt, use lsinput to identify the device I'm interested in, then use input-events to watch the events from that device
<olli> sforshee, awesome, thanks, I will try that
<sforshee> olli: the other thing I'd suggest is seeing if anything appears in dmesg when you rotate the screen
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
<sforshee> olli: one of the relevant messages is debug-level and won't appear in dmesg by default. Let me dig up the command that will enable it.
<sforshee> olli: echo "module dell-wmi +p" | sudo tee /sys/kernel/debug/dynamic_debug/control
<sforshee> that should do it
<olli> sforshee, that doesn't seem to trigger any additional messages, and using input-events on the dell-wmi device on a vt doesn't show anything either
<olli> is this the case you mentioned earlier where dell-wmi needs to be taught about it
<sforshee> olli: no, if it received events that it didn't know what to do with you should have seen something in dmesg
<olli> hm
<sforshee> I'm not coming up with anywhere else to look off the top of my head
<olli> sforshee, then there is still a big chance of pebkac on my side, will keep trying
<olli> sforshee, thx for now, might bug you later
<sforshee> olli: are you absolutely sure it's generating an event? I.e. is there some observable behavior in Windows which leads you to that conclusion?
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 10th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<olli> sforshee, http://www.youtube.com/watch?v=nU9Pa3nF6y4 at 0:50 you can see windows switching modes when swiveling, I of course nuked my win partition, but will install to verify
 * rtg -> lunch
 * rtg -> EOD
<pkern> apw: So debian.master and it will do the appropriate change to debian.raring? Or are LTS backports even more special?
<apw> pkern, lts-backports are even more special
<pkern> apw: Ok, so I guess I'll try to modify debian.raring tomorrow. I need DYNAMIC_DEBUG for some e1000e suspend issue. |:
#ubuntu-kernel 2013-12-04
<hallyn> wait, what?  I hadn't heard of 'trusty unstable' branch before - is that built in a ppa somewhere?
<infinity> hallyn: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages
<hallyn> infinity: ah, thanks.  (i was looking for something with unstable in the name :)
<infinity> zequence: It's that time of month again.
 * smb yawns (before apw does)
 * cking offers apw a coffee
<smb> A big one
<apw> oh how did you know that was what i just got handed
<smb> Its the most likely thing happening :)
<apw> heh, that i cannot deny at all
<apw> so we have had another netsplit i assume, from my random change to my nick
<smb> Maybe at some point
<smb> But before I woke, so I cannot tell when
<apw> yeah
<jjohansen1> apw: are we using the saucy goldfish kernel at all?
<apw> jjohansen1, that is a good question, i don't think we would be, i think trusty is probabally they one they are playing with
<apw> jjohansen1, deciding whether it needs cves ?
<jjohansen1> apw: not a CVE just a patch for bug#1253707
<ogra_> we dont ... as long as there is a trusty branch all is fine 
<jjohansen1> ogra_: great
<jjohansen1> apw: this bug still affects people who self compile a no-smp kernel, but I don't think thats worth pushing the patch into saucy for
<apw> bug #125707
<ubot2> Launchpad bug 125707 in Jokosher "Track playback while recording only works from the begining of the track" [Undecided,New] https://launchpad.net/bugs/125707
<apw> bug #1253707
<ubot2> Launchpad bug 1253707 in linux-goldfish (Ubuntu Trusty) "apparmor backtraces for goldfish kernel" [Undecided,Confirmed] https://launchpad.net/bugs/1253707
<apw> jjohansen1, yeah i think we may not yet have trusty branches but we should have, and that one would be something we are going to be using, so i say send it up and that will make us sort that out
<jjohansen1> apw: I sent the patch for trusty, its the same for saucy if we want to apply it
<apw> jjohansen1, ok you are ahead of me :)
<slab_allocator> Hi. I know it is a wide topic. But what is RCU read-copy-update mechanism?
<slab_allocator> I way to free CPU time?
<rtg> http://en.wikipedia.org/wiki/Read-copy-update
<slab_allocator> I was on that URL ... anyway a little bit obscufated for me...
<slab_allocator> I was looking for an abstract explanation.
 * henrix suspects the number of people that actually understand RCUs can be store in 2 bits
<pkern> Apparently editing a file below debian.raring was the right thing to do, despite the splitconfig.pl headers.
<TooLmaN> Not directly a kernel question, but I'm trying to put Ubuntu Core on an old 1GB Wyse thin client.  I have the partitions, rootfs, and kernel files all installed and in place.  My problem is with syslinux.  I have a basic config file pointing out the kernel and initrd files as well as the root partition, but on boot I get boot error.  What else should I check?  Thanks in advance
<slab_allocator> ..mmm i suspect the number of people that actually can explain plain simply whata RCU is can be store in 1 bit
<pkern> One'd think that OS lessons at university would include RCU.
<bjf> ppisati, it's crank turing week here at the ranch
<ppisati> bjf: oh right
<ppisati> bjf: everything should be done
<bjf> ppisati, your the man!
<ppisati> bjf: oh thank you, you're so fluffy and tender :)
<bjf> :-)
<pkern> And the compilation of the kernel is reasonably broken as a result. Great.
 * rtg -> EOD
<hallyn> stgraber: apw: the good news is the 3.13 trusty-unstable kernel lets me create/start containers as non-root beautifully
<stgraber> hallyn: nice! do we have a PPA for that kernel?
<stgraber> I'll need it to test my config rework branch
<hallyn> stgraber: http://ppa.launchpad.net/canonical-kernel-team/ppa/ubuntu
<stgraber> cool, will try that one in a bit
<hallyn> stgraber: the bad news is...  i can't seem to send SCM_CREDENTIALS 
<stgraber> hallyn: is that only happening from a userns?
<hallyn> yeah
<hallyn> i end up getting: sendmsg: Bad file descriptor
<hallyn> i have a bad feeling this is dbus-related
<hallyn> it *is* also a rather weird kernel.  things sseem to keep just hanging for a few seconds for no good reason
<hallyn> ok yeah, just doing pidns|mountns works fine, just the userns messes it up
<hallyn> see noreason for it in net/core/scm.c
<hallyn> stgraber: aha.  it's -EBADF bc for some reason in that case the socket has gotten closed (by dbus) before i got to sendmsg.  may still be my fault :)
#ubuntu-kernel 2013-12-05
<apb1963> ubuntu 12.04.3  3.2.0-57-generic-pae #87-Ubuntu SMP Tue Nov 12 21:57:43 UTC 2013 i686 i686 i386 GNU/Linux   CRASH.  FREEZE....reboot.... FREEZE....reboot... FREEZE....reboot.... FREEZE
<apb1963> :(
<apb1963> I get about 30 minutes of uptime now... then it freezes.
<apb1963> I don't see anything exciting in the logs.... but then I don't know what to look for.
<apb1963> started happening yesterday
<apb1963> or perhaps this morning... something came down in an update, I don't know what.
<apb1963> AFAIK everything is current.
<apb1963> And we have another freeze... and reboot.
<apb1963> And another freeze.... and reboot
<apw> apb1963, if this is sudden, then you want to try and oldre kernel and see if it does it there
<smb> apw, Or gfx, whatever or whichever he got
<apw> moin
<smb> apw, moin
<cking> yawn
<smb> fwiw I was running that kernel for a bit but now moved on as I got proposed enabled
<apb1963> apw Would the update manager have downloaded and installed a new kernel?
<apb1963> The date here....3.2.0-57-generic-pae #87-Ubuntu SMP Tue Nov 12 21:57:43 UTC 2013 i686 i686 i386  isn't that the date the kernel was compiled?
<smb> yes that is the compile date, but also yes update manager also does download and install kernel packages just like any other
<apb1963> ok, so .... did something force a download within the last 24 hours?  Wouldn't I have gotten that kernel 3 weeks ago?
<apw> you can tell what has ben downloaded in the last 24 hours in your apt logs
<apb1963> cool.  let me check that.
<smb> Even longer in /var/log/apt/history.log* 
<apb1963> yeah that's what I was looking at... not a lot in there.  However, notice the time of my last comment before you guys woke up.
<apb1963> it's been over 2 hours
<apb1963> The only thing that really happened in that time is I updated sflphone - an application I use.  A softphone.  I went into that channel several hours ago... and noticed that the developer mentioned to me he thought he had fixed a bug I reported.  I told him of this freeze problem - he didn't respond, but another updated came down shortly after... I installed that and now it's been 2 hours since the last freeze.
<apb1963> That's the same app that was tickling a DBUS bug I reported not too long ago.
<apb1963> It was crashing my system... so he changed his code... to accommodate.
<apb1963> So many changes going on it's hard to know what's causing what.
 * apw nods
<apb1963> And... as best as I can remember...  I thought I updated to the -57 version a few weeks ago... but i'm not 100% sure... hell, it could have been -56
<apb1963> I can post the apt log if you wouldn't mind having a look.  I'm sure you're more familiar with the various things than I am.
<smb> apb1963, Usually you have at least 2 (usually even more if you don't manually delete them) of the previous kernels
<apb1963> I haven't deleted anything 
<apb1963> although I'm not sure where to look for them
<smb> If you hit left shift during boot (or modify grub to always show up for a few seconds) you can select them
<smb> ls /boot
<apb1963> Yeah....  I tried hitting both left & right shift... it just ignores it.
<smb> The timing is... trick
<smb> tricky
<apb1963> I held it down for the entire boot sequence... it ignored me
<smb> I prefer to modify /etc/default/grub to comment out the two *HIDDEN* lines
<smb> set the other timeout to 10 and run "sudo update-grub"
<apb1963> heh.  I've got the last 10 kernels.
<apb1963> I wlil do that
<apb1963> so... this one...#GRUB_HIDDEN_TIMEOUT=0
<smb> right and there is another one
<smb> #GRUB_HIDDEN_TIMEOUT=0
<smb> #GRUB_HIDDEN_TIMEOUT_QUIET=true
<smb> GRUB_TIMEOUT=10
<apb1963> GRUB_HIDDEN_TIMEOUT_QUIET=true
<apb1963> so that was already uncommented
<smb> apb1963, They have to be like I posted above
<smb> Both HIDDEN commented out and the GRUB_TIMEOUT set to whatever wait time you want
<smb> If hidden timeout is true, the hidden timeout value is used (which is 0 by default), which gives you no delay and you have to press shift exactly at the right time between BIOS screen after keyboard is active and before grub starts.
<smb> Not really much time
<apb1963> go it
<apb1963> got it
<apb1963> Yeah, I've been experiencing all kinds of weird stuff
<apb1963> My network takes like 2 minutes to come up
<apb1963> the network manager can't even see my network - not that I use network manager but still
<apb1963> I have an approximate 7 second delay on SIP calls.  Nobody has a clue what that's all about.
<apb1963> Stuff crashes randomly
<apb1963> Various applications
<apb1963> I get loads over 7 for no apparent reason
<apb1963> Normal operation is like less than .5
<apb1963> I've been reporting bugs left & right in various apps.
<apb1963> I'm frustrated :/
<apb1963> well, at least my machine stopped freezing up for now.
<apw> you should try running development where that kind of experience is the norm
<apb1963> Yeah well...... this is my "production" machine.  And I only have the one. 
<apb1963> This machine was supposed to an asterisk server.... then my only other machine died of hardware failure... and I was forced to install a desktop on this one...
<apb1963> So I'm waiting for a hand-me-down from my brother for 3 weeks now, and I don't konw if he's ever going to send it.
<apb1963> In the meantime, I'm trying to get by on just this one machine running everything... 
<apb1963> Don't ever be poor if you can avoid it.
<apb1963> I can't decide if I should start some of the stuff I had running earlier to see if it triggers the freeze
<apb1963> About 35 chrome windows, libreoffice with a half dozen or so files open, skype, Kontact, firefox....
<smb> Well doing one at a time and wait some time in between at least would give some hints
<apb1963> yeah
<apb1963> I have a strong suspicion it was sflphone
<apb1963> how an app could cause a kernel freeze though.... I don't know.
<smb> Is it really a kernel freeze? Sometimes X locking up hard just looks the same
<apb1963> I was afraid it might be bad RAM... is there a way to test RAM while the machine is booted?
<apb1963> I couldn't switch to a VT
<apb1963> When X locks up I can generally switch to a VT
<smb> I had those too in the past. if X takes all the keypresses and ignores them. Hard to say then
<apb1963> I mean my system gets a  high load and brings it to a crawl... but eventually I can get a terminal and run top... shows me a rediculous load I start killing a few chrome windows and it bounces back.
<apb1963> I think flash is causing the load
<apb1963> but this was different
<smb> Only chance would be a second computer on the network and trying to ping or ssh... If you get top running, I think 'c' sorts by cpu usage, so you would see which process is doing that
<apb1963> Oh and the very first time this happend I got some kernel messages
<apb1963> yeah
<apb1963> I got like a "cut here" message
<apb1963> I couldn't find it in the log
<apb1963> but it was a definite kernel crash
<apw> photos are you main plan when that happens in case it isn't in the log
<apb1963> after the crash it just kept freezing
<apb1963> photos?
<apw> if you can see it, so can your camera
<apb1963> oh.  yeah well...  let me use the "poor" key word again
<apb1963> sucks to be me
<apb1963> oh well :)
<smb> Pen and paper? Yeah it is tedious. ;)
<apb1963> well...  I just assumed it would be in the log
<apb1963> so I didn't even consider that
<smb> Yeah, problem with crashes is that the kernel grinds to a halt. So is the part that writes to disk. 
<apb1963> I don't know why, but I figured if it had time to write to the screen it had time to write to disk.  What can I say, I wasn't thinking.
<apb1963> ok i'll startup skype
<apb1963> hmmm... might have already been running.... came up too fast
<apb1963> and now we call libreoffice to the stand....
<smb> apb1963, If you can afford the time it would be good to wait about those 30m it took to freeze between additional applications
<smb> ok skype was running for that I suppose
<apb1963> well, I can afford the time - but only because it's 2am and I need sleep
<apb1963> so if it crashes or freezes, so be it.
<apb1963> But lets say it does... then what do I do?
<smb> If you see crash messages on the screen, write them down. Then probably repeat with just the last app started 
<smb> if you find a suspect, you could slowly go back to older kernel versions to see whether they are the same
<smb> If it looks to be the kernel start filing a bug by running "ubuntu-bug linux" from that machine.
<smb> If it keeps crashing even with older kernels and you find its a certain application started, you probably have to make the bug report manually. Hm, well try to replace linux with the appname. Not sure this works though
<apb1963> hmm
<apb1963> there's also the further complication that I'm using 6 different virtual desktops
<apb1963> so who knows if that's interacting
<apb1963> earlier I was sorting my apps into VD's... this last time I didn't bother.
<apb1963> Would be nice if apps returned to their assigned VD's, but that's another story.
<smb> I could not guarantee that but which VD an app is should not matter for crashing. And no, we cannot help you with that placement problem here. ;)
<apb1963> k
<apb1963> KDE thing I guess
<apb1963> well, thank you for the  help!  I'm gonna hit the hay before my head hits the keyboard :)
<apb1963> 'night
<smb> That may help a lot. Good night. :)
<rtg> henrix, hmm, v3.12.3 broke e1000e. have you heard anything about that ? I'll check that it really works on 3.12.2 first
<henrix> rtg: no, i haven't found any e1000e patch but usually network patches aren't tagged for stable
<henrix> rtg: davem queues them and sends them in a batch
<henrix> rtg: let me check his queue...
<henrix> rtg: a quick look here http://patchwork.ozlabs.org/bundle/davem/stable/?state=* doesn't show anything
<henrix> and there's nothing obvious on 3.12.3 that would break this driver
<bjf> rtg, how does the issue manifest itself? does it just not recognize the nic or does it spew chunks?
<rtg> bjf, henrix: actually, this looks like AA denying dhclient. 3.12 kernel in a precise user space
<rtg> I'll try booting with it disabled.
<rtg> that was it.
<rtg> jjohansen1, can you think of a reason that a 3.12 kernel wouldn't work with a precise apparmor ? its blocking dhclient.
<smb> Its a bit weird my VM guest was ok with dhcp and a ... oh 3.11 kernel ... 
<rtg> smb, try a mailine 3.12.3
<rtg> mainline
<apw> that sounds familiar, it blocking dhclient i mean
<smb> rtg, Yeah maybe later. Right now I use that for fiddling with some lts-s dkms
<apw> wasn't that the error we had on the phones when part of apparmor3 was missing ?
<rtg> apw, maybe
<apw> or if userspace was out of sync with kernel, something like that
<apw> smb, test the 3.13 kernel if that works we can hide from it perhaps
<rtg> apw,  a newer kernel should always work on an older user space
<smb> apw, can do in a bit. but I suspect I might be too late then
<apw> rtg, oh of course it should, i mean when the aa3 bits went in there was an order that was bad, i think kernel had to hit before userspace
<apw> so we could have lost something in the kernel and break outselves with newer userspace
<rtg> apw, that shouldn't be the case for precise, right ?
<apw> oohhhh, this is lts-backport, erm, it just might, as in the new kernel is enforcing something which was specified but broken in older kernels
<apw> so lets think... i thnk we had to have updated user profiles _first_ then the new kernel bits for aa3, which might explain this
<rtg> apw, well, its not rally the LTS, its just the trusty kernel (though it shouldn't make a difference)
<apw> but ... we need jjohansen1 rather than my rather unreliable memeory
<apw> right, this is the kernel with aa3 on precise ie old profiles, that might be an issue
<apw> we might have to update the profiles, which will work same on older kernels.  but jj would be the one to confirm for sure
<rtg> apw, so I'm running a 3.13 kernel on a precise server
<apw> and it works or does not work
<rtg> works fine
<apw> using dhcp or static network config
<apw> i think it was dbus mediation which was the issue
<rtg> apw, uses dhcp. lemme go get the bit of log where AA was denying the socket request.
<apw> ie nothing wrong with networking, just unable to request networking
<apw> something odd like that, so ehternet might work, and wireless not or ... something
<rtg> Dec  5 23:58:24 gbyte kernel: [  644.311454] type=1400 audit(1386251904.862:93): apparmor="DENIED" operation="connect" parent=2101 profile="/usr/lib/NetworkManager/nm-dhcp-client.action" name="/run/dbus/system_bus_socket" pid=2103 comm="nm-dhcp-client." requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<rtg> De
<rtg> apw, yep, the network driver seems fine
<apw> yeah that'd be my memory of the issue, that the dbus bits get mediated and prevented
<apw> because the profiles specifity it wrongly, but the older kernles don't implement it either
<rtg> apw, yeah, its also denying cupsd
<apw> so it all works, and then we fix the kernel and it applies them and crunch
<apw> so i think we will need a profile update for precise before this can work, but as i say
<apw> jjohansen1, is the man to confirm my madness
<apw> or we might decide to switch that bit off for the backport only
<rtg> apw, just pushed Ubuntu-3.12.0-6.14 which we should smoke test just to be ure
<apw> ack
<apw> rtg, i take it you didn't tag it
<apw> (as yet)
<rtg> nope, not until I'm done making changes
<rtg> I generally tag things just before uploading
<apw> makes sense, jsut confriming i'd not gotten an old one
<apw> rtg, i've just responded to your linux-tools thing, i don't think its quite there ...
<rtg> apw, good, I wondered if I missed anything. I had a splitting headache whilst I was doing that
<apw> rtg, you know, i wonder if we should be offering them the linux-tools-version[-flavour] and also offering them something based on the linux-image- meta package they have installed perhaps
<rtg> apw, well, the meta package naming isn't totally consistent. I think this at least will give folks an idea that they might have to hunt down the _right_ meta package.
<apw> yeah, i think we should get the -flavour bit right, shall i have a poke and see if i can improve
<rtg> apw, have at it. Frankly, my attitude is that if someone is installing tools, then they likely know what they are doing (given a little nudging)
<apw> rtg, it would be nice to not need that to have versions in there, i wonder if we could fix that somehow
<rtg> apw, do you mean you wish perf was not ABI specific ?
<apw> rtg, hey i also wish that.  i meant i wish i could incant at like dpkg to get the list of versions and packages
<apw> so it would work on all releases for ever
<rtg> apw, well, we've only got to worry about one more LTS kernel for 12.04
<rtg> and we can probably predict the meta package name
<apw> yeah
 * rtg -> lunch
<hallyn> apw: could you kick off a new build of the trusty -unstable kernel in ppa?
<jjohansen1> apw, rtg: nothing new in 3.12 over 3.11 that I am aware of, however the aa3 bits in both of those do require some policy updates or dhclient etc will break
<rtg> jjohansen1, which is exactly what is happening
<jjohansen1> yep
<jjohansen1> sorry just working through the backscroll
<bjf> cking, i see this every once and a while in testing: "Timed out after 30 seconds doing mkdir() - possible eCryptfs hang" but if i just retry the test it doesn't happen again. do you want to see these?
<tyhicks> bjf: looking at the test, that may be caused by a race condition which would explain why you don't always see it
<bjf> tyhicks, do you want to look at the system when it gets into that state?
<tyhicks> bjf: yeah, that would be helpful
<bjf> tyhicks, ok, next time it happens and your around i'll let you know. do you have your QA lab vpn creds?
<tyhicks> bjf: I think so, but it has been a while so I'm not 100% sure
<bjf> tyhicks, ack
<tyhicks> bjf: yep, I see it in my network manager menus
<tyhicks> and it connects, so I should be ready when it happens again
<tyhicks> bjf: what kernel version is this happening on? do you know what lower filesystem ecryptfs is mounted on when it happens?
 * rtg -> EOD
#ubuntu-kernel 2013-12-06
<kees> say, will saucy be 3.11 or 3.12 do you think?
<elmo> kees: you mean trusty?
<elmo> kees: because saucy is already 3.11 ;-)
<kees> elmo: argh, off-by-one error. _trusty_, yes :)
<kees> aaah, never mind.
<kees> linux | 3.12.0-5.13 | trusty/main
<Sarvatt> kees: its going to be 3.13
<kees> Sarvatt: okay, cool, thanks :)
<apw> kees, yeah 3.13 is sitting in our PPA waiting on the dkms packages etc to catch up
<smoser> hey.
<smoser> do we have any sort of benchmarks that are done and recorded for kernel releases ?
<smb> smoser, sconklin has been working on some storage/fs ones
<smoser> i'm wondering because i have extremely unscientific data in my head that recent trusty is not performing as well as previous releases on my laptop.
<smoser> that unscientific data "feels" like IO to me.
<smb> smoser, iirc there _was_ a regression in ext4 which cking found but that was saucy, I think
<smoser> smb, as in fixed ?
<smb> smoser, Yes, also going to S 
<smoser> are the benchmarks sconklin has available ?
<cking> smoser, it was address in bug 1242812
<ubot2`> Launchpad bug 1242812 in linux (Ubuntu) "ext4 random block I/O write performance regression with 3.11 Saucy Kernel" [Medium,Fix released] https://launchpad.net/bugs/1242812
<cking> it appeared in one of the power regression tests, but those tests are now busted, pending QA to plug in the H/W again
<apw> smoser, and remember we're on 3.12 in trusty atm
<tseliot> apw: what kernel version are we going to use in 14.04?
<bjf> tseliot, 3.13
<tseliot> bjf: thanks
<apw> that ;)
<tseliot> :)
<hallyn_> apw: http://lkml.org/lkml/2013/12/4/156   i'm going to review this patchset asap, we may need it in trusty for userns containers to work nicely
<hallyn_> (to allow writing to /proc/self/loginuid)
<apw> hallyn_, 0/20 ... really
<apw> sigh
<hallyn_> apw: :(
<hallyn_> apw: i'll take a look this afternoon to see if it's actually complicated, or just long-winded or very broken up
<apw> how did we get so far from having the patches we needed as we were at vUDS
<apw> we so do not want to be introducing a new heap of abi if they anr't sure this is the way upstream either, gah
<apw> also it seems to claim to be incomplete
<apw> >> This patchset still need some work, such as allow changing
<apw> >> audit_enabled in audit namespace, auditd wants this feature.
<apw> >>
<apw> and it doesn't sound like upstream will even start looking at it for weeks yet
<apw> hallyn_, plus this calls itself 'part1' and the previous version was 00/48 ... are we sure this is even all of it ?
<hallyn_> 18:17 < apw> how did we get so far from having the patches we needed as we were at vUDS
<hallyn_> well all *we* need is /proc/$$/loginuid writeable.  there maybe a shorter way to do it, i simply haven't looked.
<hallyn_> i only know that fedora has the same issue and they claimed to be waitin go this patchset
<hallyn_> apw: we *can* work around it in userspace if there's not a clean patchset we can use
<ohsix> isn't it immutable for the purpose of auditing?
<apw> ohsix, it is less immutable, as 'change able once able'
<apw> and i assume hallyn_ wants to make the init in a container be able to set it once again
<ohsix> ah
<ohsix> i wonder why someone hasn't proposed just adding another one, maybe one that keeps a list of ones that have been set or something
<apw> i guess it makes sense if you have a uidns that you might want to have audit be reset in there, hrm
<hallyn_> apw: well tbh none of it makes sense to me - i thought loginuid should be only for LSPP cred tracking for audit, but it seemingly is now being abused
<apw> hallyn_, it does look like it is doing more than making that writable for sure, it is splitting auditd as well
<apw> blimey this is tensy changes
 * apw notes it is well past beer-o-clock and goes and does somwething abou tit
<cking> yeah, well into beer time now
#ubuntu-kernel 2014-12-01
<infinity> zequence: Friendly reminder about https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1396193
<ubot5> Launchpad bug 1396193 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<zequence> infinity: Thanks. Had a busy weekend. All waiting to build in the ppa.
<NikTh> apw: Hello, if you have time check this : https://bugs.launchpad.net/linux/+bug/1386695 . Thanks
<ubot5> Launchpad bug 1386695 in Linux "[3.16.0-23] Resume from suspend/hibernation, GPU lock - possible regression" [Medium,Confirmed]
<apw> NikTh, wassup?  the end of that implies you are testing a -25 kernel, but the one in proposed with the fixes applied claims to be a -26, did you get a test with -26 at all ?
<NikTh> apw: No. I didn't test with -26. I didn't get the -26 update when I updated the system today. Weird. Proposed are enabled, that's for sure. 
<NikTh> apw: I just get the -26 update, tested it and unfortunately it does not work. 
<NikTh> s/get/got
<apw> NikTh, well say that, and they will rip out the fixes for this update
<apw> NikTh, not really sure what one is supposed to do if a bios update changes things
<NikTh> apw: This is the latest version of BIOS available. I would update it either way, someday. The thing is your first kernel now works. But not the second. In comment #33 I have listed the kernels I tested.
<apw> NikTh, right which is the opposite of what you reported before the update, which is confusing at best
<NikTh> apw: correct. Although I didn't see any reference to ACPI or similar at release notes of BIOS. Here you can read the latest update (http://www.msi.com/support/mb/880GMAE45.html#down-bios_
<apw> NikTh, well teh right thing to do is mark it verification-failed, and we'll have to start again
<NikTh> apw: start again ? all over ? with this kernel bisecting thing ? Haha, I don't have the time. I have the time to test any kernel you (or anyone else) produce, but to follow this procedure all over again..hmm, a bit difficult. 
<apw> NikTh, well i think it is likely the patches we found before will do the trick, but we need this fix removed, as it does not work, then start again on top of the new release
<NikTh> apw:  OK, but your first kernel Works ( I have the links in comment #33). Should I remove the #verification-needed-utopic and replace it with the #verification-failed tag ?
<apw> NikTh, verification-failed-utopic probabally but yes
<apw> bjf, ^ looks like we have a verification failure on utopic
<NikTh> verification-failed is a ready tag as I can see. But should I remove the other one or leave it as it is ? (both)
<bjf> apw, bug #?
<apw> https://bugs.launchpad.net/linux/+bug/1386695
<ubot5> Launchpad bug 1386695 in linux (Ubuntu Vivid) "[3.16.0-23] Resume from suspend/hibernation, GPU lock - possible regression" [Medium,Triaged]
<apw> seems a bios update has changed the bug to not need the fixes found by the preceeding testing
<apw> but to need different ones
<NikTh> I'll leave @penalver to handle the tags because it seems we edit them at the same time.. a bit confusing. :-)
<NikTh> apw: right. But I still believe for such bugs the latest BIOS update should be tested. Not an "outdated" one. 
<apw> NikTh, oh indeed, just that it wasn't and has had an effect on update, makes all the work we did before, wrong and moot
<NikTh> apw : Indeed  
<apw> and indeed will create a crap-load of work for stable to remove those broken fixes, and then we have to start again once we have a new base, sigh
<NikTh> apw: I thought it was easier to merge the patches from the first kernel, the one that now works (with the new BIOS) rather to start all over again. 
<NikTh> This one works : http://people.canonical.com/~apw/lp1386695-utopic/
<apw> yes, it likely is, but those are on the wrong base so i have to wait for stable to revert and respin their tree, and for that to make it out, then i can start retesting those again on top of that base, as that is where it will need to be
<NikTh> Ah, so you will probably release the fix when ? With the happy new year ? :P 
<NikTh> apw: I have to go. Sorry for the extra work, but this time we (you) will fix it once and for all. There is other BIOS update available :-) 
<bjf> apw, i'm looking at those two commits. do you feel like we should revert them. i'm leaning that way
<apw> bjf, as they don't clearly fix the bug, i don't see how we can not revert them
<apw> much as i hate to do it
<bjf> apw, ack, i'm dealing with it. henrix, looks like i'm respinning utopic and lts-utopic
<henrix> bjf: fun!  /me goes read backlog
<binBASH> tinoco arges present?
<arges> hi
<binBASH> hi
<binBASH> I'm trying to help with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1318551
<ubot5> Launchpad bug 1318551 in linux (Ubuntu) "Kernel Panic - not syncing: An NMI occurred, please see the Integrated Management Log for details." [High,Confirmed]
<binBASH> So I've read now at https://wiki.ubuntu.com/Kernel/CrashdumpRecipe how to produce dump
<arges> yea I've just started to look at the bug, tinoco has done the most research at this point
<binBASH> cat /sys/kernel/kexec_crash_loaded 
<binBASH> 1
<binBASH> the question now would be how to reproduce that bug :)
<tinoco> binBASH: keeping machine idle
<binBASH> as it occurs for me mostly at boot
<tinoco> :(
<tinoco> binBASH: if you are using intel_idle (and you are, by default probably)
<tinoco> and HP proliant servers
<tinoco> having CPU idle will trigger the problem
<tinoco> binBASH: if you are trying to reproduce this
<binBASH> does governor matter?
<tinoco> binBASH: make sure to test kdump tool before
<binBASH> Because I'm using powersave currently
<tinoco> binBASH: keeping CPU idle will trigger C-states to go lower and lower
<tinoco> P-states will go lower on C1E state.. 
<tinoco> (frequency governor)
<tinoco> C-states will shutdown parts of the core
<tinoco> and that is where the problem is 
<binBASH> Ok, so I should probably test this without running X :)
<binBASH> tinoco: thing is I saw at also at running servers in my datacenter. But mostly directly during bootup :)
<tinoco> binBASH: we might be facing 2 separate things 
<tinoco> on the same case.. iÂ´ll split them if thats the case
<tinoco> now im focused on proliant 360/380 panics due to NMI being triggered 
<binBASH> Probably, but the question for me is, how to get crashdump when it crash at boot. Dunno if this is possible :)
<tinoco> (original case description)
<tinoco> binBASH: canÂ´t u even boot ? 
<binBASH> yup
<arges> binBASH: it depends on when at 'boot' it crashes. I think if you can use serial consoles and add 'debug' to the grub options it may give us more information
<tinoco> binBASH: curious though.. this bug is intermittent and usually does not happen @ boot
<tinoco> since all cpus are going to be powered on and on C0 or C1E state
<tinoco> binBASH: you can use the workaround i provided . to be started as a init script
<tinoco> (keeping all cpus under C1E max state)
<tinoco> and then.. turn the workaround off
<tinoco> and wait for the dump
<binBASH> Ok, I will look into this the next days. If I can manage to get a trace/dump :)
<binBASH> The funny thing is tinoco, if it occurs after boot, probably after some days. There is message output to screen every few seconds
<binBASH> with some stacktrace :)
<binBASH> The boot crashs are more like russian roulette. But with only one bullet taken out :)
<tinoco> binBASH: thats what NMI are all about
<tinoco> and CPU general faults
<tinoco> if you have a double/triple fault
<tinoco> you have a panic
<tinoco> binBASH: do you have a stack trace example
<tinoco> to show me ?
<tinoco> binBASH: id like to make sure you are not suffering from x2apic bug also
<tinoco> similar stack trace.. 
<binBASH> Not yet, because I don't know how to get it :)
<binBASH> I could take camera and make pic :D
<tinoco> if you get the beginning of stack trace
<tinoco> works for me :)
<tinoco> if the stack trace is huge.. you are getting the first lines.. not the latest frames (the one i need)
<binBASH> Could make movie as well :)
<tinoco> binBASH: lol
<binBASH> If you have better idea...
<tinoco> binBASH: are u having this on a proliant ?
<tinoco> OR on a gigabyte based motherboard ?
<tinoco> cause i really think you case is different
<tinoco> (we talked before, right ?)
<binBASH> I have it on multiple boards
<binBASH> not only Gigabyte
<binBASH> Wait, I look what is the other
<tinoco> binBASH: ALL your machines are workaround by the use of Â¨noautogroupÂ¨ ?
<tinoco> binBASH: can i ask you to open a different bug (if not proliant servers)
<tinoco> and tell me the bug #
<tinoco> ?
<binBASH> Intel S2600CP
<tinoco> binBASH: i really think we are dealing with different cases on this bug
<binBASH> is the other one
<tinoco> binBASH: this way you can open a new bug and attach the core file on it
<tinoco> for me to investigate in parallel
<arges> binBASH: you can use from the Ubuntu machine 'ubuntu-bug linux' to gather relevant information
<binBASH> tinoco: the problem is, I don't know how to get the core file :D
<tinoco> binBASH: just a sec
<tinoco> ill paste it to you
<tinoco> just made an example
<tinoco> binBASH: http://paste.ubuntu.com/9336310/
<tinoco> an example for precise.. 
<tinoco> but its pretty similar if not the same for trusty
<tinoco> binBASH: could you open a new bug
<tinoco> keep a good description on whats happening
<tinoco> and attach the /var/crash/* after the dump was created ?
<binBASH> sure
<tinoco> then iÂ´ll assign myself to it 
<tinoco> just so i can keep cases separate 
<binBASH> the problem will be probably, that it occurs before file systems are mounted :)
<binBASH> but we'll see...
<binBASH> because tinoco I have /var/crash/* stuff
<binBASH> but not from that boot crashs
<tinoco> binBASH: checking if noautogroup can be changed online somehow
<tinoco> inaddy@workstation:~$ sudo sysctl -a | grep autogrou
<tinoco> kernel.sched_autogroup_enabled = 1
<tinoco> you can boot with Â¨noautogroupÂ¨
<tinoco> and enable it online
<tinoco> so cores are generated (for your cause)
<tinoco> it might work
<tinoco> this commit: https://lkml.org/lkml/2011/2/20/10 enabled it to be a runtime flag
<binBASH> ok, I've enabled it now
<binBASH> though no crash yet :)
<tinoco> while true; do ps -ef; sleep 1; done
<tinoco> :o) to create some work
<binBASH> let's hope it will trigger anything
<tinoco> binBASH: iÂ´m leaving now. please let me know when you open the new bug
<tinoco> and when/if you could provide core dumps.. 
<tinoco> in your case i think core dumps are going to be needed (not only pictures :()
<tinoco> tks ;)
<binBASH> :-)
<binBASH> I really would like to, but I think no way when it crashs during boot and no fs initialized :)
<tinoco> lets see if enabling this runtime works
<tinoco> we might trigger some Â¨logicÂ¨ after sometime
<tinoco> and for some reason it is being triggered @ the boot
<binBASH> Yeah, I've atted it now to sysctl.conf so it will be enabled by default here
<tinoco> lets see..
<binBASH> added
<tinoco> good
<tinoco> iÂ´ll be back tomorrow 
<tinoco> let me know when youÂ´ve opened the other bug
<tinoco> so i can assign myself to it
<tinoco> ;)
<binBASH> Yup, I will
<tinoco> cya guys .. bb tomorrow
<binBASH> tinoco: I mean, I'm fine with that noautogroup
<binBASH> if it has no negative result.
<tinoco> binBASH: yep.. i would like to investigate this
<tinoco> if you can help us on reproducing/opening the bug
<tinoco> it would be awesome
<tinoco> since others can be facing this also
<tinoco> and we donÂ´t know the deep of this
<tinoco> ;)
<binBASH> and the question is, why it appeared suddenly at 3.8 kernel :D
<binBASH> anyways, sleep well tinoco and thx for additional hints
<tinoco> binBASH: yep.. this is even better in case i have to bisect something for you
<tinoco> if you have a Â¨goodÂ¨ vs Â¨no goodÂ¨
<tinoco> i can provide bisection for you to test
<tinoco> and give me feedback
<tinoco> (maybe 10 kernels to be tested ? :o)
<binBASH> would be np
<tinoco> great, lets do this then.. if you canÂ´t get a core
<tinoco> fill the bug and let me know
<tinoco> i can start a bisection for you
<tinoco> and you test the kernels i generate
<binBASH> Ok, will do it tomorrow evening
<tinoco> great ;) 
<tinoco> tks binBASH, talk to you tomorrow then
<binBASH> sleep well, bye
#ubuntu-kernel 2014-12-02
<xnox> apw: ogasawara: yo, ms wants some kernel patches for trusty ideally to enable ext2 freezing https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1297012/comments/15
<ubot5> Launchpad bug 1297012 in partman-auto (Ubuntu) "hyper-v: Manual partitioning formats /boot with ext2 file-system" [High,Confirmed]
<xnox> apw: ogasawara: otherwise hyperv (well azure) cannot freeze/migrate default installs off ubuntu (as it uses ext2 for /boot =( )
<xnox> apw: ogasawara: are those ext2 patches in 14.10 or 15.04 kernel yet, or will be? and will they make it into hwe kernel?
<apw> xnox, i know they have asked before, so we may well have done so.  though it also depends if we are using ext2 or ext4 to mount ext2 in that context
<apw> xnox, oh these are very new bits, so no they won't be currently
<xnox> apw: we are using ext2 file format for /boot & we do have CONFIG_EXT4_USE_FOR_EXT23=y, however i don't think that makes ext2 freezable without those patches.
<apw> xnox, right, but as you point out they could select something else, rather than a lot of backporting
<xnox> apw: i'd rather have kernel changed with those patches, than changing installer default partitioning filesystems in the default configuration in a trusty point release.
<apw> as they know it does not work
<apw> xnox, it is not clear why they can't preseed it
<xnox> apw: it's not up to them to select. but for the guest-os / any client workload on azure.
<xnox> apw: it seems that telling all users to do something else doesn't work.
<xnox> (well ubuntu based client custom images)
<apw> xnox, right but the only reason this is a problem is because they believe they can make a consistant snapshot of the machine if they freeze it, which btw, i think is flawed thinking
<apw> xnox, the images most people use on azure are supplied by us, this would be hyper-v on a local install only prety much
<xnox> apw: i do hope they are not exposing that to people, when they clearly see a given VM is not freezable.... i hope they only do so when they think they actually can do it.
<xnox> apw: right, ENOCLUE.
<xnox> apw: i haven't looked into partman-auto enough, hopefully we can make /boot ext4 without journaling / extents / etc. (e.g. more like an ext2 thing)
<xnox> such that it becomes freezable, but we don't need to increase it's disk space.
<apw> the unfreezability looks to be related to not having a journal
<xnox> also we should finally make grub2 not require /boot for just lvm2 based installs, as it can parse things off it.
<xnox> =(
 * xnox does not want /boot with a journal.....
<apw> xnox, on my boxes i have no /boot on my lvm installs, no idea why we need it
<apw> xnox, it is not clear whether this second fix would stand alone, it might well do
<xnox> apw: hm, maybe cjwatson fixed that already....
<xnox> apw: i'll make a note to self to retest that.
<apw> cirtainly i have what i think is a P install using it, you need a 2048 block aligned first cylinder sort of thing else there isn't room in the gap for grub
<apw> xnox, so this is for .2 right?  so will be with an lts-u kernel ?
<apw> we'd not care for anything older i presume
<xnox> apw: well if those ext2 patches are in u's kernel, then yeah lts-u-hwe / .2 target is good.
<xnox> apw: if those patches are only in v's kernel, then we are looking at .3 target.
<xnox> apw: and i don't have ubuntu kernels cloned here to confirm which kernel those patches are in, if at all, and/or need cherry-picking.
<apw> they are 3.18-rc3 so very new, not in anything at all right now
<xnox> apw: cherrypick!!!! what could possibly go wrong?! =)
<apw> xnox, heh, we shall see if they even build, let alone work
<xnox> apw: cause 3.17/3.18 are so wonderful with all the regressions since 3.16..... =))))
<apw> xnox, 3.18 isn't feeling toooo bad to me
<xnox> apw: i'm on 3.17.4 on my dev hardware and "i don't like it" (big brother quote)
<xnox> apw: using stock 14.04 LTS otherwise everywhere as it's the release i can trust =) after all the things i broke for 14.10 ;-)
 * xnox wishes for my SRUs to be accepted.....
<cking> amitk, i just tried to send some idlestat patches to sched-tools@linaro.org and my mailer complained it did not exist
<amitk> cking: I see the patches....
<cking> amitk, yep, I cc'd you on them ;-)
<cking> amitk, do you have access to the coverity scan for idlestat? there are a bunch more issues that need fixing that I wasn't so sure about the best way to fix them
<amitk> cking: I think you subscribed me to the report, I saw it today
<amitk> cking: I'll look at the sched-tools alias later today, thanks for reporting. And thanks for the patches.
<cking> ok, cool, just wanted to keep you in the loop about the outstanding issues ;-)
<amitk> cking: much appreciated
<cking> amitk, BTW, idlestat still could do with a man page ;-)
<amitk> cking: honestly speaking it will probably happen only when we stop changing the options so much. Every few patches we change the behaviour a little. Lack of a spec, I guess
<amitk> cking: but if you file a bug on bugs.linaro.org, atleast it'll stay on the radar
<cking> okay will do
<jsalisbury> ##
<jsalisbury> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 9th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<kgunn> ogasawara: hey curious, we've recently been discussing how to automate some testing for rotation
<kgunn> curious if there is some known kernel tool/trick that could be used to 
<kgunn> inject sensor events, e.g. mock rotation/orientation sensor firing
<ogasawara> kgunn: I don't know anything off the top of my head, but let me sync with my guys and get back to you
 * xnox finally realised that brad-figgs bot is launchpad's equivalent of "please hold the line, your call is very important to us"
<xnox> and then the call center closes and unanswered calls are just left playing that message =))))
#ubuntu-kernel 2014-12-03
<apw> b xnox 
<xnox> apw: oj!
<apw> missing / and all that
<apw> xnox,  on Bug #1396383 ... we have to run update-grub as the filename grub will see and use changes when there is a signed kernel in place
<ubot5> bug 1396383 in linux (Ubuntu) "why signed kernels call update-grub?" [Medium,Confirmed] https://launchpad.net/bugs/1396383
<apw> and we cannot modify the existing kernel in place, because that is a file in another package, and you don't do that
<apw> it is possible we could divert the original vmlinux in that case
<apw> we don't user /etc/kernel/* because that would make it rebuild the initrd even more times on install
<apw> though that would be fixed if i uploaded my triggers fixes
<apw> but that is waiting on initramfs-tools and that is waiting on console-setup
<apw> hallyn, hey ... it seems your qemu update has dropped a symlink kvm-spice -> kvm, is this to be expected?  it stops all my libvirt VMs from working
 * apw pokes hallyn
<clopez> have the patches for VT mode KD_TRANSPARENT and vt_handoff  tried to be merged either upstream or in the debian kernel?
<clopez> http://patchwork.ozlabs.org/patch/60271/  and http://patchwork.ozlabs.org/patch/60272/
<clopez> seems that ubuntu 14.04 not longer has this patches, neither i see them on upstream... what happened?
<apw> clopez, not exactly
<clopez> apw: is another patch implemeting a feature like this one?
<apw> clopez, vt handoff et al are still in our kernels, cirtainly is there in vivid
<RAOF> Hm. Whatever happened to those hot data tracking patches...
<clopez> apw: "grep -ri vt_handoff" returns only changelog entries on Ubuntu 14.04 kernel sources (http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_3.13.0-40.69.dsc)
<clopez> what i'm missing?
<apw> clopez, no it may be missingin 3.13, it is there still in general in our kernels
<clopez> i see, so support for this feature is broken on 14.04 ?
<apw> clopez, it does sound like it.
<apw> RAOF, ?
<RAOF> apw: Oh, I just remember there being VFS patches for hot-data tracking and migration some time ago, but can't find any recent work on them.
<clopez> ok, thanks for the clarification
<apw> clopez, you have a use case for those patches ...? 
<clopez> yes, avoiding the black screen meanwhile the kernel is loading (between grub and the load of the initramfs)
<apw> clopez, if you do, you might file a bug about it so we don't forget to look, and dump the bug number in here.
#ubuntu-kernel 2014-12-04
<clopez> apw: I'm interested in having this feature also on debian, not sure if there were already any upstreaming attempts
<apw> clopez, ahh.  well file a bug on ubuntu, on trusty, and i'll look when awake
<clopez> ok, thanks
<amitk> cking: hey, which repo does coverity look at for idlestat?
<cking> amitk, I use  https://git.linaro.org/power/idlestat
<cking> plus any fixes I shove in to test them out too
<amitk> cking: ok, my engineer couldn't find the code being referred to
<cking> I can kick off a clean check against the repo head if you want, it's no problem to do
<amitk> cking: yes, a clean check against our repo head would be nice
<cking> amitk, OK, against head at commit 73b0121e97a604ee0d97c66c41b239dc76739ae7
<amitk> cking: looks right
<cking> scan in progess
<cking> done
<cking> email should be in you inbox from coverity scan
<amitk> cking: got it
<cking> if you add the engineer to the project he can do the scanning and uploading to coverity if he wishes, you have access rights to add others to the project
<amitk> cking: aah, I didn't know that
<amitk> or rather, I forgot you mentioned that
<cking> amitk, I think I even sent my script to do the build and auto-uplaod to, but I can re-send it to you if you require it
<amitk> cking: found that email
<cking> amitk, beware that one can only do a few spins per day on the scanner though :-(
<amitk> cking: one a week should be enough ;)
 * cking nods
<cking> anyhow, I use it on all my projects, it's really useful for finding thinkos and the like
#ubuntu-kernel 2014-12-05
<manjo> kamal__, looks like you backported ARM: fix alignment of keystone page table fixup do you recall what issue this fixed ?
<apw> manjo, from the description i'd say it makes sure the end of the kernel data space is mapped properly, which i would to mean random builds working and randoms ones not
<manjo> apw, ok I have a similar situation ... so was trying to understand that patch
<manjo> apw, was looking for any bug report so that I can compare the trace 
<manjo> apw, the bug that it ref to is of no help 
<apw> the bug would be a stable being applied en-toto bug i assume
<apw> the original is no more verbose, and has no bug associated
<manjo> bah
<apw> but as it is random end of data space alignment issues, it woud literally be anything that happens to be linked there which would be missing
<kamal__> manjo, yeah, that commit was just "cc: stable", hence I merged it...  there is/was no bug reference for it.
<apw> i doubt it is constrained to any particular thing
<manjo> apw, so in my case a dkms module does a get_user_pages() but it is unable to pin it because *pmd = 00000000
<manjo> kamal__, ack I feard that might be the case
<manjo> but the code worked in a previous build but no in the current build 
<apw> manjo, have you a crash stack for it?
<manjo> pmed you the bug 
<apw> that stack could just be saying you asked it to map something from userspace which does not exist
<manjo> right so it seems like there is nothing wrong kernel wise ... but the user tells me that they did not see failures like this before 
<apw> that tells you nothing other than they used to be luckier, in reality.  code which should and indeed seems impossible to have worked ever
<apw> often works for years before exploding and showing you they are passing the wrong thing
<manjo> did you see my comment #2 ? that is what I was trying to understand as to why their module is trying to pin invalid page table
<apw> well that is simply defined by the address you pass in, it is saying "you asked me to pin a page in this range, but there isn't even a pmd for it, so there is no page EFAULT"
<manjo> I want to completely rule out that any merge from ubuntu to this flavor kernel did not intro any regressions
<apw> from that trace, i would say the driver reported that the get_user_pages failed, and then went on to use the address anyhow as if it did not
<manjo> :) yeah it looks messed up ... trying to untangle the spaghetti so that I can put the ball on their court 
#ubuntu-kernel 2014-12-07
<Madkiss> hi folks
<Madkiss> if I want to recompile the ubuntu kernel with a different gccc variant than the one behind "gcc", what files do I need to change, or how would I generally achieve that goal?
<apw> Madkiss, HOSTCC and COMPILER define the compilers in use for the various parts
<apw> in Makefile
<Madkiss> okay.
<apw> i presume you could change kmake in our packaging to pass those if you are using that
<Madkiss> i am using whatever linux_3.13.0.orig.tar.gz comes with.
<soren> Madkiss: I thought you got the problem fixed properly? (I.e. in ways that don't require another compiler)
<Madkiss> the one problem.
<soren> Madkiss: Ah :(
<Madkiss> i suspect there are at least three other problems caused by compiler madness, and I simply want to check.
<soren> apw: Do modules generally have to be built with the same compiler as the kernel?
<apw> soren, yes, as you are relying on the calling conventions on internal functions be exactly the same
<soren> apw: Ok. I wasn't sure how well defined the ABI was. Thanks.
<Madkiss> where does the Build-Depends line come from for christs sake?
<Madkiss> I edited debian.master/control.stub to add stuff there, and in the .dsc file, my changes are gone
<apw> debian/control is built from debian.master/control.stub.in 
<Madkiss> wait.
<Madkiss> so you are having a control.stub.in that creates a control.stub
<Madkiss> and that creates a control file?
<apw> yes
<Madkiss> are you kidding me?
<apw> no
<Madkiss> who on earth would do that?!
<apw> who would guess how it works instead of reading debian/rules to find out
<Madkiss> people following the, err, debian policy, I guess.
<apw> the stub.in has variable subs to .stub, stub is combined with the other stubs per flavour to make control
<apw> seems to make sense to me
<soren> Debian policy doesn't specify how those things are created.
<soren> fwiw
 * soren wanders off again
<Madkiss> apw: and what'S the rationale for copying the changelog around ?
<apw> Madkiss, it is part of the package meta data which is derivative specific, allowing rebased derivatives to use the same master unpinnings without collission
<apw> allowing both us and non-official kernels to base of our maintained base in a simple manner
<Madkiss> aha.
<apw>  /b #is
<Madkiss> apw: any idea what is causing the problem at the end in https://launchpadlibrarian.net/192033308/buildlog_ubuntu-trusty-amd64.linux_3.13.0-40.69%2Bsyseleven2_FAILEDTOBUILD.txt.gz ?
<Madkiss> apw: any chance you could help me out? :\
#ubuntu-kernel 2015-11-30
<marga> infinity, hey there. The installer is still not matching the latest kernel, I thought it was going to be updated soon... Is there an ETA on that?
<caribou> apw: smb: I have just realised that /etc/default/grub.d/kexec-tools.cfg is the script responsible for setting up crashkernel= as a boot argument
<caribou> apw: smb: any reason for that ? this is a requirement for kdump-tools, not kexec itself
<caribou> thank god we are doing good QA on our flagship software
<apw> caribou, sounds like it is missplaced at best
<caribou> apw: kdump-tools is not the only reverse depends of kexec-tools so that variable may be defined for things that have nothing to do with crashkernel
<caribou> (petitboot & pxe-kexec)
<apw> caribou, i suppose... all it does is "make a hole in ram" so it could be used by other things for the same side-effect
<caribou> apw: yes, it has minimal impact
<caribou> apw: maybe it is worth moving it to kdump-tools package
<caribou> apw: plus this is Ubuntu specific
<smb> Yeah, guess a misnomer from times when all was mushed together
<apw> caribou, presumably debian has to have handling for that cmdline thing as well tho ?
<apw> where do they do it?
<caribou> apw: nope, it is a manual addition to /etc/default/grub documented in the README
<apw> caribou, oh right, so we can move it to whever it makes most sense and then upstream it to debian :)
<caribou> apw: there is on linux-crashdump metapackage on debian
<caribou> iep
<caribou> yep
<apw> anyhow very likely we put it in kexec tools because it _is_ related to kexec tools ...
<apw> so it might make sense there really, because you have kexec --crash or whatever to use it don't you
<caribou> apw: true
<caribou> apw: I was looking at LP: #1318111
<ubot5> Launchpad bug 1318111 in kexec-tools (Ubuntu) "Adds more and more copies of âcrashkernel=384M-:128Mâ in /etc/default/grub when upgrading or reinstalling grub-pc" [Medium,Confirmed] https://launchpad.net/bugs/1318111
<smb> apw, thats what I meant with mushed together...
<apw> oh that is very broken, sigh
<xnox> caribou, i think there is a fix for that in mdadm package where Laney fixed a "similar" bug.
<caribou> xnox: mdadm ??? oh, maybe a more generic fix
<caribou> xnox: that would explain why I can no longer reproduce it
<caribou> I'll fetch the source
<xnox> caribou, well, it's a bit tricky. grub.d hooks can readd things over and over and over again. there was a bug in the way mdadm was doing it.
<xnox> there was a feedback loop and it depended on how many kernels one was generating the initramfs for....
<xnox> so try to have multiple kernels installed and have update-grub run across them all or some such.
<caribou> xnox: yeah, that's what I'm testing atm
<caribou> xnox: lp: #1465567
<ubot5> Launchpad bug 1465567 in mdadm (Ubuntu Vivid) "Kernel panic - not syncing: Too many boot init vars at `nomdmonddf'" [Undecided,Fix released] https://launchpad.net/bugs/1465567
<smoser> http://paste.ubuntu.com/13576380/
<smoser>  does that stack trace look important ?
<smoser> root fs got remounted read only  and i'm just going to reboot.
<smoser> the reason i ask if it looks important is that its quite possible that the underlying disk in this vmware system is foobarred.
<smoser> (the provider has done that before, so if it smells like that I wont open a bug).
<xnox> [700872.486476] sd 2:0:0:0: [sda] task abort on host 2, ffff88001e469000
<xnox> [700882.773096] sd 2:0:0:0: [sda] Failed to get completion for aborted cmd ffff88001e469000
<xnox> hardware problem =)
<smoser> xnox, thanks.
<jderose> Any insight into why 4.2.0-19 wasn't released last week, if it will be released this week?
<apw> we do try and avoid releasing on friday so we acoid breaking people at the weekend
<jderose> apw: was the reason 4.2.0-19 wasn't released due to regressions found, or because of the holidays? just eager for 4.2.0-19 as it fixes as critical NVMe + suspend issue :)
<jderose> apw: BTW, this is the specific fix we're waiting for - http://kernel.ubuntu.com/git/ubuntu/ubuntu-wily.git/commit/?h=master-next&id=babbf7db6d39d809ae132394f1196463ef118ca0
<jderose> without it, suspend/resume is broken on UEFI systems with NVMe drives (and UEFI is, AFAIK, required to work with NVMe drives at all)
<stgraber> sdeziel: bjf is looking for someone who can test fixes
<sdeziel> bjf: I'm ready to test when you are
<bjf> sdeziel, thanks, jsalisbury ^
<bjf> sdeziel, are we talking Trusty?
<sdeziel> bjf: yes, I can test both 3.13 and 3.16 on trusty
<bjf> sdeziel, thanks
<bjf> sdeziel, we've duplicated it here. i don't think we'll need you
<sdeziel> bjf: OK, I'm still available if you think I can help
<sdeziel> thanks for looking into this
<bjf> sdeziel, we'll probably want you to test as soon as we've identified the bad commit but that might take a bit
<sdeziel> bjf: OK, no problem
<sdeziel> bjf: I didn't bisect it myself but looking at the changelog, "fib_rules: fix fib rule dumps across multiple skbs" seems like a potential culprit
#ubuntu-kernel 2015-12-01
<bjf> sdeziel, try 3.16.0-54 ... i think it's fixed in that kernel
<bjf> sdeziel, found: fib_rules: Fix dump_rules() not to exit early       which is supposed to have addressed that exact problem
<sdeziel> bjf: OK, giving it a try
<bjf> sdeziel, amd64 ?
<sdeziel> yes
<sdeziel> bjf: 3.16.0-55-generic x86_64:  works well
<bjf> sdeziel, cool ... we are cherry-picking that fix into trusty for a test
<sdeziel> bjf: I couldn't easily get 3.16.0-54 because -55 is in -security I guess
<bjf> sdeziel, if that works then i'll upload that fix. it will take a bit to build and go through review. should pop out tomorrow
<sdeziel> bjf: OK, so I'll pop in here tomorrow. Unless you'd also want me to test your test build as well?
<bjf> sdeziel, since we can repo it here, if it fixes it here we'll go with it
<bjf> sdeziel, thanks for the help
<sdeziel> bjf: perfect, thanks for getting to this so quickly
<bjf> sdeziel, we're really sorry it went out like that
<sdeziel> bjf: I'm partly responsible for the lack of visibility because I had it reported on 3.13 (LP: #1516052) but then marked it as a dup on the linux-lts-utopic bug (LP: #1514785) /without/ making sure it was also affecting the 3.13 branch...
<ubot5> Launchpad bug 1514785 in linux (Ubuntu Vivid) "duplicate for #1516052 kernel 3.16.0.52+53 - ip rule repeats all default rules (messing up rule table)" [High,In progress] https://launchpad.net/bugs/1514785
<ubot5> Launchpad bug 1514785 in linux (Ubuntu Vivid) "kernel 3.16.0.52+53 - ip rule repeats all default rules (messing up rule table)" [High,In progress] https://launchpad.net/bugs/1514785
<bjf> sdeziel, we're looking at how we review bugs, i think we should have picked it up  ...  however, you should always feel free to come in here and get someone to look at a bug if it happens again
<sdeziel> bjf: indeed. I'll come here next time
<catbus1> Hi, when 14.04.4 is out in Feb, what will be the kernel in the installer? 
<catbus1> kernel version
<sdeziel> catbus1: https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BAC8-Support.A14.04.x_Ubuntu_Kernel_Support says 4.2
<catbus1> sdeziel: that's the kernel in the base os, so it will be the same kernel version in the image installer, too? 
<sdeziel> catbus1: the 14.04.4 iso/installer will ship a 4.2 kernel. Not sure what you mean by the base OS.
<apw> catbus1, the installer generally has the newest kernel for h/w enablement
<catbus1> great, thanks!
#ubuntu-kernel 2015-12-02
<Beret> 4.3 hasn't landed in xenial yet right? (at least according to packages.u.c)
<apw> Beret, it is in -proposed
<Beret> ok
<Beret> apw, thanks
<apw> Beret, waiting on testing, and a bug fix or 3 which will require it to be re-uploaded, before it will get out to -release
<Beret> ok
<Beret> I'm gating my upgrade to xenial on that :)
<rtg> apw, what bugs are blocking ?
<apw> rtg, the move you did for ppc64el, the scsi drivers from =y -> =m needs some support fixes else the images won't boot -- udebs and the like
<apw> rtg, they are sittng on master-next waiting on confirmatory testing by infinity
<rtg> apw, ah, ok
<rtg> apw, I can prolly reroll that without an ABI bump.
<apw> rtg, there a re a bunch of cves on there too, and we don't do non-abi bumpers any more
<rtg> well, how much fun is that
<mjeanson> apw: a while ago we spoke about the build failures of lttng-modules-dkms on trusty's lts backport kernels, I had made a custom branch that builds against all current kernels and someone on the kernel team was suppose to have a look and see if it could be uploaded
<mjeanson> all that to say, any news?
<mjeanson> the branch was https://github.com/mjeanson/lttng-modules/tree/stable-2.4-trusty
<mjeanson> it builds daily against all latest trusty kernels : https://ci.lttng.org/view/Packaging/job/package-trusty-x86-64/
<mjeanson> and here's a test package https://launchpad.net/~mjeanson/+archive/ubuntu/ppa/+sourcepub/5320274/+listing-archive-extra
#ubuntu-kernel 2015-12-04
<wgrant> apw: Could you be convinced to include "s390/kernel: fix ptrace peek/poke for floating point registers" (55a423b) in the next xenial kernel? Fixes a panic we ran into on the buildds today.
<wgrant> (tested by building gdb; the panic was first seen in its test suite)
<apw> wgrant, yep, i see from your ppa that that is a backport?  do you have the one you have tested, oculd you email it to me and i'll apply it
<apw> wgrant, and if there is a bug number wang it in here
<wgrant> apw: I haven't filed a bug, can do so in a bit if you need. The backport is trivial, but will find a patch.
<wgrant> apw: http://paste.ubuntu.com/13665866/ is the diff.
<wgrant> Looks identical to the git diff for me, but it didn't apply directly. Possibly line numbers too far off or something.
<wgrant> Except they're the same.
<wgrant> Weird.
<apw> ack thanks
<apw> wgrant, ok it cherry-picked for me, so ... wierd
<apw> and that ... i recon ... is a cve if "overwrites the task structure"
<apw> is correct
<wgrant> apw: Oh yeah, it's totally exploitable.
<wgrant> I probably just misapplied it, I was rushing.
<apw> given we have a bad s390x package split as well pending on tip
<apw> i think we should get that uploaded sooner rather than later
<apw> though i would like this 4.3 to go out at least
<apw> i assume this is affecting the bootstrap of main though .. right ?
<wgrant> I have it installed on one buildd (z13-008), and it's only affected gdb so far.
<wgrant> main is built, apart from various unrelated FTBFSes.
<wgrant> I just manually threw gdb at the one with the fixed kernel.
<apw> so you goosed gdb thorught hte fixed one, right
<apw> ok then i will let this one migrate, i should have the final testing ok in about 2 hours
<wgrant> Yep.
<wgrant> Not super urgent.
<apw> then i'll get this one uploaded
<xnox> apw, yo =)
<apw> xnox, hi
<xnox> totally forgot, could you please cherrypick a patch that prevents buildds blowing up, on funny PIE builds? =)
<xnox> apw, unless one of the other engineers already talked to you about it
<apw> "s390/kernel: fix ptrace peek/poke for floating point registers"
<apw> xnox, ^^ that ?
<xnox> apw, yes that.
<apw> xnox, is picked and will be in the next upload, i was under the impression only gdb had hit it thus far and had been handled ?
<xnox> apw, yeah, wgrant quickly built a kernel and upgraded buildd8, so buildd 8 is a good one =)
<xnox> but having that in the next kernel would be dandy. thank you =)
<apw> heh is that why she is offline, held for special projects
<apw> xnox, that and your split to make linux-virtual work are on deck for the next upload
<xnox> apw, brilliant.
<rtg> apw, I could turn the crank on that as soon as -1.10 is promoted
<apw> yep, i've dropped the tag, just waiting
<rtg> otherwise it might be a few days
<apw> should be done within the hour in theory
<apw> because you know friday is a classy day to release a kernel
<rtg> apw, I'll check back in a bit
<rtg> especially a new kernel release
<apw> perhaps we should have waited till monday
<rtg> apw, this way we'll have plenty of email to deal with first thing Monday morning
<apw> rtg, i might be able to catch it before it copies out
<rtg> apw, oh, let it go. I think its pretty stable
<rtg> apw, after all, its got the cking stamp of approval
<apw> yeah :
<apw> :)
<apw> who upgrades over teh weekend anyhow, thats a silly idea
<cking> release often I say
<apw> yeah i'd like it to be a lot cheaper to update but its really not
<cristian_c> jsalisbury: hello
<jsalisbury> cristian_c, hello.  I haven't had much time to look into the new issues yet.  It sounds like the regression is now fixed for you?
<cristian_c> jsalisbury: yes, as I've stated in launchpad report
<jsalisbury> cristian_c, ok.  I'll make some time to look at the other issue
<cristian_c> jsalisbury: I've got a question
<jsalisbury> cristian_c, sure
<cristian_c> jsalisbury: last time, I've read fix went in 4.3-rc2
<jsalisbury> cristian_c, the fix for the regression? or the fix for the new issue?
<cristian_c> jsalisbury: but I've noticed that regression is disappeared already in 4.2.0-18
<cristian_c> jsalisbury: about regression
<jsalisbury> cristian_c, the fix was cc'd to upstream stable, so it's eventually going to make it's way into all the stable kernels
<cristian_c> 4.2.0-16 is default kernel in 15.10
<cristian_c> after first updates, kernel goes to 4.2.0-18 version number
<cristian_c> jsalisbury: so, where can I find the commit (if it's public)
<cristian_c> ?
<jsalisbury> cristian_c, this is the commit:
<jsalisbury> commit 8a1513b49321e503fd6c8b6793e3b1f9a8a3285b
<jsalisbury> Author: Kyle Evans <kvans32@gmail.com>
<jsalisbury> Date:   Fri Sep 11 10:40:17 2015 -0500
<jsalisbury>     hp-wmi: limit hotkey enable
<cristian_c> ok, thank you very much
<jsalisbury> cristian_c, you can get it out of linus' tree or any of the stable trees, but it will have a different SHA1
<jsalisbury> in the stable trees
<cristian_c> ok
<ccope> when do updates from the upstream kernel get backported to LTS kernel backport packages?
<ccope> specifically, I need https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0480334 in linux-image-generic-lts-utopic for trusty
<henrix> ccope: hmm... i see.  so, that commit is meant to be applied to stable kernels >= v3.18, thus it will never be applied to the corresponding stable kernel (3.16.7-ckt)
<henrix> ccope: however, the utopic kernel actually backported overlayfs so that commit may actually be applicable to that kernel
<henrix> ccope: my suggestion would be to open a bug against that kernel, requesting that specific commit to be included
<henrix> (feel free to assign that bug to me ;-) )
<ccope> henrix, ok cool, thanks!
<ccope> henrix, i'm unable to assign you but the bug is here: https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1523000
<ubot5> Ubuntu bug 1523000 in linux-lts-utopic (Ubuntu) "writing files larger than 2GB to overlayfs fails" [Undecided,New]
<henrix> ccope: ack, thanks.  i'll assign it to myself later
#ubuntu-kernel 2015-12-06
<garrettr> What is the difference between kernels compiled with "make deb-pkg" (using the makefile that comes with a vanilla kernel) and kernels compiled with "make-kpkg"?
<emiliano_> linux-imagehi
<emiliano_> hi
<emiliano_> i have a question about linux-image-4.2.0-..-generic
<emiliano_> i upgraded my workstation to 15.10 from 15.04 and then the workstation freeze on lightgm without keyboard and mouse
<emiliano_> so i searched for the cause of the bugs
#ubuntu-kernel 2016-12-05
<zyga> ogasawara: hey! :)
<zyga> ogasawara: I have an idea I wanted to ask you about
<zyga> ogasawara: so someone showed me the snapcraft tree for the core kernel snaps: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/snapcraft.yaml?h=pc
<zyga> ogasawara: and since we recently moved gadget snaps to github (through a launchpad mirror and auto-build pipeline) to github.com/snapcore/snapd I was wondering if we could to the same to the kernel snap so that people can find the snap definition more easily and it's all under one hood
<ogasawara> zyga: let me chat up bjf and team about it
<zyga> ogasawara: thanks!
<zyga> ogasawara: I wrote a small blog post about what's happened to gadget snaps http://www.zygoon.pl/2016/12/ubuntu-core-gadget-snaps.html -- there are plenty of links from that post to repositories both on github and launchpad
<ogasawara> zyga: ack, thanks.
 * ogasawara will go read
<hallyn> anyone have a absolute-minimal-working kernel config sitting around for bisect purposes?
<smb> hallyn, the mainline builds do come with config patches (http://kernel.ubuntu.com/~kernel-ppa/mainline/). Would those work for you? (down the page in a certain version directory)
<hallyn> smb: maybe - my guess would be those are for full fledged kernels :)  i just want quick builds, don't need most filesystems etc.
<hallyn> (just enough to boot)
<hallyn> i'll just make my own again - thx
<smb> hallyn, ok. sorry would not have any minimal configs aywhere
<hallyn> make localmodconfig is new to me
<hallyn> anyone still using ccache these days for kernel builds?  
<rtg> hallyn, I found that ccache took longer, at least on the servers that I build on
<rtg> too many files and an inefficient hash algorithm methinks
<hallyn> hm, makes sense
<hallyn> (haven't used it in like 10 years)
<hallyn> thanks
<kees> what is "linux-hwe-edge" ?
<kees> looks like for "latest supported kernel on Xenial" I should install linux-image-generic-hwe-16.04-edge linux-headers-generic-hwe-16.04-edge ?
<rtg> kees, there is an email about it on the ubuntu-announce list
<kees> rtg: ah, thanks!
<rtg> subject "16.04.2 - Rolling HWE Kernel"
<kees> Looks like https://lists.ubuntu.com/archives/ubuntu-announce/2016-November/000215.html
<rtg> yup
<kees> oh, and remember our chat about intel iommu? finally tested on a non-modern machine and any graphics access broke the system. "intel_iommu=on,igfx_off" seems to fix it, though. I still don't think it's sane enough for even that to be the default, based on things like the audio stack failure bug reports. :(
<rtg> kees, I'll leave it off then for sure.
<kees> yeah :(
<kees> in related news, I need to send a quirk for my chipset so I won't need the igfx_off in the future. ;)
<rtg> good luck
<kees> hehe
 * rtg has to run
<kees> cya
<hallyn> hm, why do all of the 3.x kernels, when built with make deb-pkg, hang at loading initrd?
<hallyn> (on a xenial host)
<hallyn> some systemd thing?  maybe i should install upstart?
<hallyn> guess i'll try upstart
<hallyn> nah
#ubuntu-kernel 2016-12-06
<ivan> hmm, shouldn't 4.4.0-53 be in linux-xenial/master?
<ivan> and master-next is only up to -52
<ivan> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git I mean
<ivan> OK -53 is in the repo now :-)
<stoatwblr> I have a bug with mptsas - ata erase (and secure) erase are failing. (The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.) - works fine if the disk is plugged into the server's onboard sata ports, but that means having to go onsite to do this stuff.
<stoatwblr> mpt3sas actually... :)
<stoatwblr> hmmm. already fixed upstream.
<stoatwblr> has the mpt3sas "Fix secure erase premature termination" (Nov 30th) been rolled into ubuntu-kernel yet?
<stoatwblr>  commit 18f6084a989ba1b38702f9af37a2e4049a924be6 and 7ff723ad0f87
<stoatwblr> it would appear not. How can I request it. Doesn't seem to be a way of filing a bug in launchpad.
<rtg> stoatwblr, https://bugs.launchpad.net/ubuntu/+filebug
<stoatwblr> thanks
<stoatwblr> just checking whether 4.8.0-30-generic might have had it added (Don't think so but always worth looking)
<rtg> BenC, I've been meaning to ask you about powerpc64-emb. I had to temporarily disable that flavor in Zesty (v.9) because arch/powerpc/kernel/head_64.S fails to assemble within the CONFIG_PPC_BOOK3E blocks.
<BenC> rtg: What kernel version is zesty at?
<rtg> BenC, 4.9-rc8
<BenC> Are you still adding any patches from E500/BOOK3E?
<BenC> All of the patches that I once had added are no longer needed, so if there are any remnants, you can remove them.
<BenC> If something still isnât compiling, Iâll take a look at it now.
<rtg> BenC, looks like that file at least is vanilla
<dmj_s76> sforshee: So I've identified another issue relating to linux-firmware and (this time) kernel 4.8.  Bug incoming.  
<ogra_> bjf, hmm, i wonder if you cant copy to the PPA because it is owned by snappy-dev and you are not a member ... want me to try the command to verify ?
<dmj_s76> sforshee: It seems iwlwifi on kernel 4.8 doesn't work with the latest microcode (/lib/firmware/iwlwifi-8000C-22.ucode) under some circumstances.
<bjf> ogra_, yes, please try
<bjf> ogra_, henrix just pointed out to me that that ppa is over 100% full
<dmj_s76> Now my guess is that a) -22 microcode is buggy or b) 4.8 requires patches to work correctly with it.
<ogra_> bjf, hmm, doesnt work for me either 
<ogra_> oh
<ogra_> then the error is weird though 
<ogra_> it shoould still find it 
<bjf> ogra_, indeed
<dmj_s76> This has been reported online by users of many different distros.  In our case, the microcode causes kernel crashes when 64GB of RAM (4x16GB) is installed in a certain laptop model, but not 48GB (3x16GB) or other less populated configurations.
<dmj_s76> renaming the -22 ucode so things fallback to the -21 fixes things.
<ogra_> bjf, oh man ... 
<ogra_> bjf, "--to=~snappy-dev/ubuntu/snappy-devices" ... works 
<bjf> oh
<ogra_> do you want to try yourself or should i just confirm (it is sitting at y/N )
<bjf> ogra_, yes, let me try
<henrix> ogra_: ah, i actually tried with "--to=~snappy-dev/snappy-devices" and it failed too... i guess i was close :)
<ogra_> probably best if you try 
<ogra_> henrix, yeah :)
<bjf> ogra_, "./copy-package --from ubuntu --from-suite vivid-updates --to=~ppa:snappy-dev/ubuntu/snappy-devices --to-suite vivid -b linux linux-meta linux-signed" fails for me
<ogra_> whats the error ? 
<bjf> AssertionError: No such archive: ~ppa:snappy-dev/ubuntu/snappy-devices
<ogra_> no
<ogra_> no tilde in front of ppa 
<bjf> oh! i see what i did
<ogra_> its either tilde or ppa:
<ogra_> iirc they are kind of equivalent 
<bjf> ogra_, it's working
<ogra_> \o/
<bjf> ogra_, done! no errors
<ogra_> yay
<henrix> bjf: what? with a ppa at 100%?  that's odd
<bjf> henrix, what can i say .. i think it worked
<ogra_> i definitely see the packages 
<sforshee> dmj_s76: that's nice. Please file a bug, we need one for any SRU.
<sforshee> dmj_s76: once you've filed the bug I'll spin another linux-firmware with that reverted.
<dmj_s76> sforshee: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1647826
<ubot5> Ubuntu bug 1647826 in linux-firmware (Ubuntu) "intel 8260 doesn't work with linux kernel 4.8 when using ucode version 22" [Undecided,New]
<sforshee> dmj_s76: sounds like we'll need this in yakkety and xenial, right? Do you know if the problems go away with a 4.9 kernel?
<dmj_s76> sforshee: I haven't tested 4.9 yet
<dmj_s76> Yakkety should be the priority for now, but xenial will need it by the next point release.
<sforshee> dmj_s76: if you get a chance it would be nice to know about 4.9. We've got a 4.9 build in zesty-proposed.
<sforshee> dmj_s76: do you have any idea whether or not there are similar issues with the other -22 firmwares?
<dmj_s76> sforshee: I don't know how the other -22 firmwares behave.  We only ship a limited subset of wifi cards known to work well (except when bugs like this happen)
<sforshee> dmj_s76: do you have links to the other reports of this problem? I'm trying to determine if we need to revert the -22 ucode completely or just the one
<dmj_s76> sforshee: 
<dmj_s76> https://bugs.launchpad.net/hplip/+bug/1635898
<dmj_s76> https://bugs.archlinux.org/task/51271
<dmj_s76> http://askubuntu.com/questions/856028/how-to-get-wifi-working-on-ubuntu-16-10
<dmj_s76> https://www.danernielsen.com/getting-intel-wireless-8260-to-work-on-ubuntu-16-10/
<ubot5> Ubuntu bug 1635898 in HPLIP "16.10 wireless off" [Undecided,Invalid]
<dmj_s76> The reporter of that ubuntu bug is clearly hitting this same issue but doesn't know how to categorize it.
<sforshee> dmj_s76: thanks. Between that and my own searching all the cases I see where the -22 ucode was clearly to blame were with 8260, so I guess I'll only remove that one.
<dmj_s76> sforshee: still an issue on 4.9
<sforshee> dmj_s76: thanks
<sforshee> dmj_s76: posted a test build to the bug
#ubuntu-kernel 2016-12-07
<stoatwblr> does anyone know when 4.8.12 will find its way into the yakkety kernel stream?
<rtg> BenC, any more thoughts on powerpc64-emb ?
<BenC> rtg: I kicked off a build to get the error so I can fix it. My system is slow soâ¦
<rtg> BenC, ack
<rtg> BenC, you might be able to shortcut the full build by doing 'make M=arch/powerpc'
#ubuntu-kernel 2016-12-08
<rtg> BenC, this is your daily nag about powerpc64-emb
<BenC> rtg: ack
<rtg> BenC, I would be less persistent except that disabling that flavour is preventing migration out of -proposed.
<BenC> rtg: Am I supposed to be testing the ubuntu-zesty master build of powerpc64-emb?
<rtg> BenC, master-next
<BenC> Iâm guessing not, because it built just fine.
<BenC> ubuntu/ubuntu-zesty repo or your ubuntu-zesty repo?
<BenC> Kicking off a build of ubuntu/ubuntu-zesty#master-next
<BenC> Luckily, I remembered I have a 24-core ppc64 system to do builds onâ¦speeding things up
<rtg> BenC, git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/zesty master-next with the Zesty toolchain
<BenC> Ughâ¦now I gotta dist-upgrade
<BenC> Or maybe just build a chroot
<rtg> BenC, well, I'm assuming it is toolchain related 'cause this code used to assemble.
<BenC> Iâll try it on my current setup and if it succeeds then Iâll build a chroot for zesty toolchain.
<rtg> BenC, I can tell you which instruction it hates.
<BenC> A file:line would be helpful, thanks.
<rtg> BenC, arch/powerpc/kernel/head_64.S:  224
<rtg> cmpwi   r3, 0
<BenC> Build started from what repo. This will be a good test to see if itâs toolchain or not, at least.
<rtg> BenC, cool, thanks.
<rtg> BenC, here is a more complete error message: zesty/powerpc/master-next/ubuntu-zesty/arch/powerpc/kernel/head_64.S:217: Error: operand out of range (3 is not between 0 and 1)
<BenC> rtg: CONFIG_FSL_FMAN, CONFIG_FSL_BMAN and CONFIG_FSL_QMAN all need to be =y
<BenC> They donât work well as modules.
<rtg> BenC, just for that flavor, or all powerpc flavors ?
<BenC> for powerpc64-emb and powerpc-e500mc
<BenC> It can be turned off for all other flavours, even ppc ones.
<rtg> BenC, will do
<BenC> ARM may be able to use it as well, but I donât know of anyone producing consumer grade QorIQ ARM systems.
<rtg> BenC, FSL_BMAN/FSL_QMAN do not exist in v4.9 though there is FSL_BMAN_TEST/FSL_QMAN_TEST
<amitk> BenC: who knows if it'll every happen (QorIQ consumer grade) after the Qualcomm acquisition
<amitk> *ever
<BenC> rtg: Right, those can stay as modules
<rtg> BenC, I pushed 'UBUNTU: [Config] CONFIG_FSL_FMAN=y for powerpc' to Zesty
<BenC> amitk: For ARM, youâre very right. But there is consumer grade (or at least servers) for PPC QorIQ
<BenC> rtg: Build passed on trustyâ¦time to build a zesty chroot and retry.
<BenC> Toolchain issues are a bit more time consuming.
<amitk> BenC: right, I meant for ARM only
<rtg> BenC, I was sure it would be :) I'd have tackled this sooner but I don't know PPC assembler
<BenC> Seems like some new constraint that cropped upâ¦starting the deeper dive now
<BenC> rtg: zesty toolchain based build started...
<theravenproject> hellp
<theravenproject> hello
#ubuntu-kernel 2016-12-09
<tjaalton> smb: hi, does the mainline repo have space for some more builds?-) thinking of the tip of amdgpu driver, but the problem with that repo (https://cgit.freedesktop.org/~agd5f/linux/) is that there's no static branch name to use
<dnssoul> there is a kernel bug where the untaring of a file matches a hex address at sector offset 0x00 which causes a file to upon extraction grow upwards to 100GB.   the patch to this is using a G65 compiler for a header that is used for aliasing ln -s and hardlinking -- varies per kernel, using the G65 compiler to compile that header and its other systematic linux binary execution functions must terminate in a .g0409804-1 address sector which
<dnssoul>  can be verified by a hex dump of that specific kernel h header, and should apply to all kernels this effects.  in order for it to terminate into a .g0409804-1 address sector, use gcc for the kernel and standard c libraries that do not violiate linux standards for things always compiled under G65.  thank you.  have a nice day.  
<smb> tjaalton, I cannot answer that right away. And since I am on a sprint this week it would be best to send me an email, so I won't forget
<tjaalton> smb: ok
#ubuntu-kernel 2016-12-10
<_ami_> Hi.
<_ami_> any framebuffer driver expert here?
<_ami_> i am trying to write a fb driver for 1.8" ST7735 display on raspberry pi2. (https://raw.githubusercontent.com/amitesh-singh/ldd/master/tfts/fbsimple/fbsimple.c)
<_ami_> my code works and i can able to see X display on the screen. but the colors do seem correct.
<_ami_> https://pbs.twimg.com/media/CzUeXR9UsAw2a7f.jpg:large
<_ami_> the background image is actually RED but it seems Violet 
<_ami_>  but the colors do seem incorrect**.
#ubuntu-kernel 2016-12-11
<bingel> I have doubts concerning the management of the trim on SSDs Samsung 8* series.
<bingel> With regard to "queued trim", these discs were put on the blacklist (in "libata-core.c" library) for each version of firmware and as a result, the queued trim should be disabled for them.
<bingel> I own a Samsung 840 PRO with fw "5B0Q" (not the latest), and by mounting the partitions on that disk using the "discard" option (in fstab), this option, instead of being ignored (as it should), is taken into account (the "mount" command output is in the partitions options).
<bingel> I wonder if, despite this, the queued trim is in any case disabled or if there is some sort of bug or, most likely something that I did not understand.
<bingel> Thanks to those who want me to come in handy explaining this behaviour.
<bingel> Excuse me for my poor English
<bingel> ...hello to everyone
<bingel> Errata corrige: (the "mount" command output show "discard" in the partitions options).
<bingel> My Ubuntu is 16.04 up to date.
<bingel> Kernel is 4.4.0-53-generic
<trippeh_> the kernel only disables queued TRIM, it can still use the older style non-queued TRIMs
<trippeh_> which works fine on the samsungs
<bingel> Thanks for your reply.
<bingel> Yes, I know but the option "discard" should enable "queued trim" therefore if I put "discard" in "fstab" and remount partitions then i check output of "mount" command I should not see "discard" because this options should be ignored ...or am I wrong?
<bingel> .
<bingel> discard is just for queued trim
<bingel> not for old-style (or am I wrong?)
<trippeh_> discard should use whatever variant is available, it pre-dates queued trim
<bingel> Are you sure? Because I think you are wrong, discard should be only for queued trim.
<ivan> "discard 
<ivan> Enables discard/TRIM on freed blocks. This can decrease performance on devices that do not support queued TRIM command, like SATA prior to revision 3.1. Alternatively, you can run fstrim command periodically."
#ubuntu-kernel 2017-12-06
<amitk> cking: hiya! How do I prevent stress-ng from running any memory stress tests (since I only have a Gig) but run everything else?
<amitk> cking: I tried 'stress-ng -r 4 -x vm --minimize' but I still get several OOMs
<cking> amitk, the only easy way is to exclude all the ones that OOM by the -x option, so that's a a pain
<cking> however, there are quite a few stressors that can trigger OOMs. However, the OOMs won't affect stress-ng, it can respawn the stressors if they get OOM'd
<cking> one can specify per-stressor memory sizes in terms of memory size too (in bytes or % memory available)
<amitk> cking: aah, ok. The list of stressors is quite long and there seems to be no easy way to eliminate an entire class of stressors
<cking> amitk, yep, that is a currently a pain point
<amitk> cking: doesn't the --minimize flag avoid OOMs be being conservative?
<amitk> *by
<cking> amitk, --minimize just selects the lower bounds settings
<amitk> that is the opposite of what I thought it does :-)
<amitk> I guess I'm looking for max bounds on my memory and IO constrained systems
<cking> but this is a per-test specific setting; some stressors just require a few tens of MB to run effectively
<cking> and that's the lower bounds
<cking> amitk, i suggest running each stressor one by one with a specific memory bound set for the stressors you are interested in
<cking> e.g stress-ng --vm 0 --vm-bytes 80%
<amitk> cking: I really want random to catch unexpected errors but was hoping to find a way to say "don't commit beyond 60% of memory"
<cking> amitk, OK, I think one needs to just select the subset of stressors you are interested in and specify the memory size according to your desired constraints on a per-stressor basis
<cking> yep, it's a pain
<amitk> cking: ok, thanks. Its been very useful so far to test cpufreq and thermal :-)
<cking> amitk, that's good to know. it can make CPUs run quite hot :-)
#ubuntu-kernel 2017-12-07
<lamont> has anyone ran into the ipv6 stack _NOT_ accepting router advertisements despite being told to? (trusty with both 3.13.0-135 and 4.4.0-101)
<lamont> apw: ^^
<apw> lamont, i have not seen that, i am pretty sure i have a 4.4 but it might be out of date
<apw> is this new behaviour
<lamont> it's been something that I run into every reboot of this firewall, and then scratch my head for a few minutes, and manually add the router that I SEE ADVERTISING IN TCPDUMP, and then everything is fine unti lthe next reboot
<lamont> tbf, it's eth0.55 that the RA is coming in on
<lamont> and ip6tables are involved.
<lamont> http://paste.ubuntu.com/26133655/ <-- trace of the packets coming in, INPUT:10 is an ACCEPT on router-advertisement
<lamont> the upgrade of the kernel to 4.4 was today in a hail-mary attempt -- the box is still running trusty beacuse of other reasons
<lamont> tbf, that 33:33 dest MAC feels funny to me.
<lamont> The "all nodes" address ff02::1 is converted to 33:33:00:00:00:01. <-- I suspect that comcast is to blame.
<lamont> nm - I'm just failing at reading.  it has the right 33:33:0:0:0:1 mac
<lamont> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1683911 is also somewhat annoying
<ubot5> Launchpad bug 1683911 in ifupdown (Ubuntu) "ifup places illegally named variables into the environment" [Undecided,New]
#ubuntu-kernel 2017-12-08
<zkanda> Hello, there is a fix in mainline linux-firmware that I want to apply to 17.10 linux-firmware, I'm following the wiki from here: https://wiki.ubuntu.com/Kernel/Dev/LinuxFirmwareMaintenance
<zkanda> However there's no instruction on how to compile and get a .deb, anyone here who can point me to the right direction?
<apw> zkanda: either amke a source package with dpkg-buildpackage -S and throw that in a ppa, or dpkg-buildpackage -b in a chroot
<jainy> Hey, I have a bug in kernel module related to locks. So I enabled lockdep and tried to compile it; however, it is throwing me this error. Is there any way I can fix go around this and to use LOCKDEP?  
<jainy> Kernel built with CONFIG_DEBUG_LOCK_ALLOC which is incompatible     *** with the CDDL license and will prevent the module linking stage     *** from succeeding.  You must rebuild your kernel without this     *** option enabled.
<jainy> any help is appreciated, thank you..
<jainy> also what modules in ubuntu kernel uses CDDL licence?
<apw> jainy, that sounds more like somethign outside the kernel
<apw> jainy, oh unless it is the vbox drivers
<apw> jainy, or indeed zfs ... so it is zfs, so you would have to build with do_zfs=false
<apw> assuming you don't need zfs
<jainy> zfs makes sense. okay, I will try to compile with do_zfs=false
<jainy> @apw, "fakeroot debian/rules DEB_BUILD_OPTIONS="debug nostrip noopt parallel=12"  binary-headers binary-generic do_zfs=false" is the command line, right?
<apw> you might have to put that before binary-headers, but i think that is right
<apw> git grep do_zfs debian
<apw> to confirm
<jainy> okay, thank you
<jainy> @apw, Now I an getting "I: Checking modules for generic...    reading new modules...read 4614 modules.    reading old modules...       MISS: spl       MISS: splat       MISS: zavl       MISS: zcommon       MISS: zfs       MISS: znvpair       MISS: zpios       MISS: zunicode"
<jainy> how do I specify to skip zfs without failing there? 
<alexzzz> Hi all! I want to check hybrid polling on 4.10.0-40-generic and have some problems. I have ubuntu 16.04 with linux-generic-hwe-16.04 package installed. I've set scsi_mod.use_blk_mq=y and rebooted. After that i see that for my ssd drive scheduler is set to "none". I'm trying to change io_poll_delay to 0, but "echo" command fails with error: -bash: echo: write error: Invalid argument. Hope for help 
<apw> jainy, is it erroring there?  i thought rules marked those ok when you disable
<apw> it will still report them as missing, just not die
<jainy> find /home/vuzzer/zless4.4/4.4/linux-4.4.0/debian/build/build-generic/ -name \*.ko | \ 	sed -e 's/.*\/\([^\/]*\)\.ko/\1/' | sort > /home/vuzzer/zless4.4/4.4/linux-4.4.0/debian.master/abi/4.4.0-97.120/amd64/generic.modules II: Checking modules for generic...    reading new modules...read 4614 modules.    reading old modules...       MISS: spl       MISS: splat       MISS: zavl       MISS: zcommon       MISS: zfs       MISS: znv
<apw> no i don't see it saying (ignored)
<jainy> EE: Missing modules (start begging for mercy) debian/rules.d/4-checks.mk:12: recipe for target 'module-check-generic' failed make: *** [module-check-generic] Error 1
<jainy> so make failed 
<apw> hrm, ok so that is broken
<apw>         do_zfs_disable:=$(shell cat $(DROOT)/zfs-modules.ignore >>$(prev_abidir)/../modules.ignore)
<apw> there is al ine like that in debian/rules, you wanna make that not conditional 
<apw> and that should not be there in the makefile
<apw> hrm
<jainy> in which can I find that line ? 
<apw> grep is your friend
<apw> but i think it is debian/rules
<jainy> yes, 
<jainy> let me check
<apw> jainy, http://paste.ubuntu.com/26139268/ something like that might do the trick
<apw> if it works likely that needs applying across the board
<jainy> it should be this -> ifeq ($(do_zfs),false), right?  a small typo.. I am testing it now
<apw> indeed it sh
<apw> jainy, indeed it should be that
<apw> we only normally disable zfs for cross builds, so i hadn't realised it was broke
<jainy> the compilation is successfully completed  
<apw> great, i will test the other use cases
<apw> jainy, bug #1737176
<ubot5> bug 1737176 in linux (Ubuntu) "Disabling zfs does not always disable module checks for the zfs modules" [Low,In progress] https://launchpad.net/bugs/1737176
<jainy> Hi, I am trying to lockdep feature provided by kernel. When the deadlock occurs what I see in the kernel log is "INFO: lockdep is turned off." Even though I have provided "CONFIG_DEBUG_LOCK_ALLOC=y" I see a warning message as following:
<jainy> scripts/kconfig/conf  --silentoldconfig Kconfig
<jainy> .config:4268:warning: override: M686 changes choice state
<jainy> .config:9596:warning: override: reassigning to symbol DEBUG_LOCK_ALLOC
<jainy> .config:9599:warning: override: reassigning to symbol DEBUG_SPINLOCK
<jainy>  Restart config...
<jainy> could this be the problem? if so, how do I stop overriding these changes?
<jainy> Any help is appreciated..
#ubuntu-kernel 2019-12-02
<kantlivelong> is there list of kernel command line options to disable security mitigation for recent cpu exploits?
<gpiccoli> kantlivelong, I think "mitigations=off" will do the job, by disabling all of them
<kantlivelong> thats 5.2+ kernel though right?
<kantlivelong> suppose i could update
<gpiccoli> It's backported to older kernels in our releases, let me check for you kantlivelong 
<kantlivelong> ah
<gpiccoli> kantlivelong, for Bionic (4.15): https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/tree/Documentation/admin-guide/kernel-parameters.txt#n2452
<kantlivelong> ah cool
<kantlivelong> thats what i was lookin for
<gpiccoli> This file explain the fine tunnings to the mitigations, like to disable a mitigation for a single issue (Spectre only for example)
<gpiccoli> Great =)
<gpiccoli> This is on Disco (5.0): https://kernel.ubuntu.com/git/ubuntu/ubuntu-disco.git/tree/Documentation/admin-guide/kernel-parameters.txt#n2567
<gpiccoli> SAme thing basically heheh
<gpiccoli> You may be using 5.0 as Bionic HWE for example
<kantlivelong> gonna give this a shot
<gpiccoli> cool, hope it helps you
<kantlivelong> only real concern is js but think firefox mitigated that 
<gpiccoli> Hmm..not sure about that. The advise is usually to keep mitigations enabled, although I can see how it may affect some workloads' performance heheh
<kantlivelong> otherwise its all trusted code running
<gpiccoli> It's a per-case decision I guess
<kantlivelong> desktop gaming/dev pc
<kantlivelong> older
<kantlivelong> tyty
<gpiccoli> yw =)
<JanC> maybe don't do banking on it
<JanC> or similar
<kantlivelong> or just close ff and open w/ bank alone
<JanC> and development might depend on what sort; if it's all open source there are probably easier ways to "steal" your code, like using git...  ;)
<kantlivelong> no real concern other than ff
<tyhicks> kantlivelong: firefox reduced their timer precision which makes it more difficult to carry out speculative attacks using JS
<JanC> which means an attack would probably take a lot longer
<tyhicks> https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/
<tyhicks> they call it a partial, short-term mitigation (which is a fair description)
<tyhicks> I don't know if they've done anything in addition to that initial change
<JanC> probably not much else they can do without removing functionality
<shibboleth> for some reason the verbose boot text, desktop, picture on the screen is "more grey" (dunno how to put it) wheen booting kernel 5.3 vs 4.15
<shibboleth> no such issue in 5.0
<shibboleth> in short, my displays look at lot cheaper when booting 5.3 :)
<shibboleth> displays connected by displayport, intel skylake graphics
<shibboleth> imagine looking at a cheap-ass LCD vs a decent one at best buy. one has excellent black, the other will be tainted by a grey hue
<shibboleth> booting debian testing kernel 5.3=no issue
<shibboleth> ubuntu 18.04-hwe-edge was affected both before and after todys update
#ubuntu-kernel 2019-12-03
<lotuspsychje> good morning to all
<lotuspsychje> in #ubuntu-bugs-announce im seeing bus related to mint, now this arises a question to me, does the ubuntu kernel team handle mint bugs too?
<lotuspsychje> *bugs
<apw> lotuspsychje, if they are our actual kernel binaries we are interested in bug found; though we may not be able to tell if it is a 'different userspace' interaction in some cases to be sure
<lotuspsychje> apw: but if ubuntu's kernel suffers a bug, does that mean that mint also suffers that bug?
<apw> lotuspsychje_, i could not say for sure; if they have the same kernel likley yes
<apw> but i know little to nothing about mint to be honest
<lotuspsychje_> same here apw hence why it made me wonder...here's an example of what we saw bug #1854896
<ubot5> bug 1854896 in linux (Ubuntu) "Synaptics TM3336-004 Touchpad Stopped working after update to the latest kernel 4.15.0-72 generic" [Undecided,Incomplete] https://launchpad.net/bugs/1854896
<apw> lotuspsychje_, yeah it looks like one of the hardward related folk has asked for information and had none; jolly them into answering perhaps
#ubuntu-kernel 2019-12-04
<sdeziel> hello, in LP: #1844186,  jjohansen  was kind enough to provide test kernel builds addressing the issue for various releases/kernels. Most patches ended up in official kernels but not those for 4.4.0 and 4.15.0
<ubot5> Launchpad bug 1844186 in linux (Ubuntu Bionic) "[regression] NoNewPrivileges incompatible with Apparmor" [Undecided,Confirmed] https://launchpad.net/bugs/1844186
<sdeziel> yet, those were tested to be working and fixing the problem so I'd appreciate if someone could integrate them, please
<sarnold> sdeziel: any chance you recall if those fixes broke snapd or similar? my memory is too fuzzy
<sdeziel> sarnold: definitely not in a user visible way for the 5.0+ kernels as I test them with lxd's snap
<sdeziel> sarnold: but for the older kernels, I didn't specifically tested snapd
<sdeziel> sarnold: I could test 4.15.0 with lxd's snap if that can make that bug progress, should I do that?
<sarnold> sdeziel: I can't promise anything, I just have a vague memory that an apparmor security fix broke something in snapd so we had to revert it.. it's possible that a comment "this patch didn't break these snapd use cases for me..." would help, but I'm not on the decision path thtere..
<sdeziel> sarnold: OK, I'll try to do that test and report back. Ultimately I would have like if jjohansen could comment on why only 3 of his 5 patches were integrated ;)
<sdeziel> he's worked on those patches so it be too bad to not see them integrated ;)
<sarnold> a sadly all too common fate :(
#ubuntu-kernel 2019-12-05
<zx2c4> apw: hey
<zx2c4> so wireguard is approaching upstreaming pretty soon
<zx2c4> will try to get the transition as smooth as possible for packaging
<zx2c4> know which kernel 20.04 plans to ship with?
<sixwheeledbeast> It's too early to say but I imagine the next 5.x long term. 
<apw> zx2c4, most likel 5.4
<zx2c4> apw: oh 5.4 is easy peasy, cool
<zx2c4> Latest snapshot supports that
<zx2c4> (0.0.20191205)
<apw> zx2c4, when is it likely to merge, 5.5 ?
<sixwheeledbeast> 5.4 is currently listed as EOL in 2021. I would expect with 20.04 being an LTS they would want a LTS kernel.
<apw> sixwheeledbeast, we are told it will be the upstream LTS
<sixwheeledbeast> Oh np
<zx2c4> apw: 5.6, unless linus steps in for a 5.5 miracle
<apw> zx2c4, nice; pretty quick by upstream standards
<apw> and not sooo far away that we couldn't backport it most likely
<zx2c4> apw: indeed, ive already done the work :)
<zx2c4> I can have a patch ready for any kernel you need
<zx2c4> apw: actually, the current patch set that's going to LKML for 5.6 actually applies over 5.5
<zx2c4> (since there's no 5.6 yet)
<zx2c4> https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/patch/?id=790fb3caff5cbe57f5cacc51e9736e0cdc6261c2
<zx2c4> and then ive backported from there to 5.4-->3.10
<zx2c4> so whenever you guys settle on a version for 20.04, let me know and ill prepare a clean patch for that
<apw> zx2c4, nice, if you have a 5.4 lying about you could point me at it
<apw> zx2c4, or that; there is a version coming based on 5.4 final, would be in our unstable repo right now
<zx2c4> https://git.zx2c4.com/WireGuard/tree/ that's this repo
<zx2c4> it uses a "compat.h" horror show to dynamically patch based on the version
<zx2c4> _however_,
<zx2c4> for the ubuntu kernel, i'm happy to make a single coherent patch that inlines all the compat hacks
<zx2c4> kerneltoast is pretty familiar with the compat.h stuff, iirc
<apw> zx2c4, we'll have a think about what makes most sense
<apw> as to some degree it is sensiuble to have what you are supporting
<zx2c4> apw: in other words, what im proposing is thta i give you a 5.4 patch that looks identical to the 5.5 patch above in that it's a single straight forward thing that doesnt touch much
<apw> that sounds appealing indeed
<zx2c4> apw: cool well, just send me a link to whatever tree when you're ready and ill do that
