[12:52] fabbione: you around? === dilinger [dilinger@mouth.voxel.net] has joined #ubuntu-kernel [02:05] zul: pong [05:32] morning [05:32] lamont: i am now === crimsun [crimsun@crimsun.silver.supporter.pdpc] has joined #ubuntu-kernel === chmj [~chmj@196.36.161.235] has joined #ubuntu-kernel [10:41] infinity: ping? [10:44] pong? [10:44] infinity: so.. let's talk about flavours :) [10:44] did you get all your hw in place? [10:44] I seem to be much better off hardware-wise than I was a month ago, yes. [10:45] infinity: i think it's time to test the k7 - 686 thingy and possibly other combinations [10:45] One ppc32 (1.0 GHz G3), one amd64 (2.0 GHz Athlon64) and one i386 (2.0GHz Pentium-M) [10:45] i am pretty sure we can [10:45] i am pretty sure we can't drop 686 vs 686-smp or similar [10:46] Assuming we don't run into driver instability issues, yes. [10:46] according to bugzilla some smp kernels are suffering some weird extra bugs [10:46] Given that I'm pretty sure ipw2200 locks up my 686 machine occasionally, I wonder if it'll get worse if I go SMP... [10:46] infinity: ipw2200 is broken for N millions other reasons [10:46] I've noticed. [10:47] At least it mostly works for me right now. === JaneW [~JaneW@196.36.161.235] has joined #ubuntu-kernel [10:47] what we need to see are performance issues :) [10:47] if any [10:47] and imho there are none [10:47] I'm doubting we'll see any worth noting. [10:47] all the other arches are down to N and N-smp [10:48] only i386 is still bloated [10:48] Okay, how many i386 flavours do we have? [10:48] And how many do we ideally want? [10:48] 5 [10:48] with the tendency to increase soon [10:48] if we get 686-xen0 686-xenU [10:49] so i am on the idea of killing k7 completely [10:49] Can we build -i386 with arch=i486 tune=pentium, or something similar? [10:49] hi Janew [10:49] infinity: that's what the 686/k7 selection does at the end [10:49] k7 is hard to test, as I don't have a real k7... I might be able to dig up someone who does. [10:50] my k7 is half broken even with 386 kernels [10:50] ? [10:50] infinity: we still need a clean 386 .. that should be really 486 by now [10:50] infinity: hw problems :) [10:51] Yeah. I don't have a 486 anymore, but I can test on a Pentium-MMX. That's as slow as it gets. [10:51] (Are we carrying the 486 emulation patch in our 386 kernels, BTW?) [10:51] infinity: nope... [10:51] Or do we just not support anything < 486? [10:51] Kay. [10:51] I have k7s just fine. [10:51] we dropped real 386 support a while ago [10:51] hi fabbione [10:51] Mithrandir : Hi, you just signed up to do some 686 vs k7 performance testing, then. :) [10:52] Mithrandir: can you run a 686 kernel on it and tell us if there is any noticable performance issue? [10:52] fabbione: sure. Urgently? (please say no) [10:52] brb i need more coffee [10:52] Mithrandir: well asap.. within yesterday is fine [10:53] Mithrandir: kidding.. sometime within monday or tuesday if possible [10:53] fabbione : Is there actually a reason for the amd64-{generic,k8,xeon} split at well, or just people looking for that 2% performance boost again? [10:53] fabbione: I'll see what I can do. Most of my systems are still boxes on the floor around here. [10:55] I have no xeon to test on, but I can do the opposite thing of testing the xeon kernel on my k8 and see if it sucks. [10:57] I don't think I have any xeons, but I could ask around at hardware.no and see. [10:57] infinity: I think the xeon and k8 kernels won't necessarily work on both kinds of hardware. [10:57] That's a theory I'd like backed up with proof. [10:58] infinity: i have no idea... [10:59] (Keep in mind that we have a "generic" amd64 kernel which apparently works on both, so dropping k8 /and/ xeon would be the sane option if the performance hit isn't terribly noticeable) [10:59] about xeon/k8 [10:59] and generic i *think* works on emt64 too [10:59] Well, that's the point, yes. [10:59] It's the kernel we use in the amd64/em64t installer, so it better work on both. [10:59] even if i saw Debian spawning the usual 24 flavours on svenl's ppc wave [11:00] amd64-k8-smp:CONFIG_SMP=y [11:00] amd64-xeon:CONFIG_SMP=y [11:00] that's the only thing... [11:00] well more or less [11:01] # disable it for opteron optimized builds because it pulls in ACPI_BOOT [11:01] config X86_HT [11:01] bool [11:01] depends on SMP && !MK8 [11:01] default y [11:01] MK8 = k8 [11:01] so there are differences [11:02] I've asked fs who does the amd64 kernels in Debian about the reason too [11:02] No terribly large differences. [11:02] ok [11:02] well HT can make a difference.. and associate to ACPI [11:03] amd64 and amd64-smp would probably cover all our bases if amd64-smp also had HT enabled, and still works fine on k8. [11:03] the latter makes me feel not particularly conmfortable [11:03] you mean generic and generic-smp :) [11:03] Well, no, there'd be no need for the "generic" moniker if there were no non-generic ones. :) [11:03] but yeah i agree 2 flavours should be more than enough [11:04] If you can build an amd64-smp with HT enabled, I can spin it with elmo on a buildd. [11:04] That's the best way to find out if it's broken. [11:04] infinity, Mithrandir: can you 2 focus today and tomorrow to do this research between cpu diffs? [11:04] infinity: i can spin it.. that's no problem, but where is elmo? [11:05] he needs to go to a DC to reboot a buildd... [11:05] s/a/the [11:05] Yes, he and I already have a date to do amd64 kernel testing. [11:05] ok.. and when is that supposed to be? [11:05] We want to make sure breezy's kernels are all capable of running the buildds for breezy+1, so it's something that needs to be done anyway. [11:05] because 2.6.12 on concordia is giving the same problems as 2.6.10 on the buildd... [11:05] Early next week is when I was planning on pinging him back about it. [11:05] concordia's still going down? [11:06] no [11:06] but it's segfault-o-rama [11:06] Not quite the same problems, then. [11:06] The buildds actually crash. [11:06] i can't even build the kernel there [11:06] We'd prefer they didn't. [11:06] same synmptomps of G5 on ppc32 kernels [11:06] Fun. [11:06] just much worst [11:07] and dmesg full of the same crap you pasted to me [11:07] Well, if you want to try to spin a bunch of test images, we can make a play-date. [11:07] but yeah.. it's not going down.. that's true [11:07] i can't spin images without concordia.. [11:07] i can give you a config... [11:07] but you can as well just edir amd64-generic locally [11:07] Very true. [11:08] He and I will play then, and get back to you. [11:08] Do you have changes queued up to linux-source, or is -3.3 still the "best known" version? [11:09] infinity: 4.4 is on the way [11:10] but i was hoping to get amd64 sorted out before [11:10] otehrwise it will be a neat FTBFS [11:11] An FTBFS never killed anyone. === JaneW [~JaneW@196.36.161.235] has left #ubuntu-kernel ["Leaving"] [11:11] it will kill my patience because i need the ABI files out of the build [11:11] If you can roll up what you're planning to release, that's the source elmo and I will play with. [11:12] before be able to upload a fixed version [11:12] infinity: ok.. i will try to do that asap [11:12] i need to finish to cleanup the udeb creation [11:12] Just roll a prerelease and toss it on chinstrap. [11:12] but it is possible to build the debs [11:12] infinity: see /topic :) [11:12] grab the source and apply some baz magic :P [11:13] Yeah, yeah. Will do. [11:13] eheh [11:13] don't worry [11:13] i will give you the diff.gz [11:13] i am still working on staff [11:15] infinity: also.. another question.. are we going to drop gcc-3.3 from breezy? [11:15] doko: can gcc-3.3 actually build ppc64 binaries? [11:15] How are the kernel builds with gcc-3.4 looking? [11:15] not good [11:15] Feh. [11:15] Then I guess we need 3.3 [11:16] they build.. but it seems that some stuff is miscompiled [11:16] Not surprised at all. [11:16] i386/ppc seems to be ok [11:16] but all the other arches are showing regressions [11:16] We don't have time to fix that sort of breakage. [11:16] nope [11:16] Debian does, we don't. [11:16] not at all [11:16] and jumping to 4.0 is no solution [11:16] So we need 3.3 in main, and we should probably use it to compile everything but ppc64. [11:16] fabbione: hmm, I don't know. do you really care? [11:16] doko: yes i do care :) [11:16] read above... [11:16] And compile ppc64 with 3.4 (I assume?) [11:17] infinity: i am more happy to use the same compiler everywhere [11:17] I don't think 3.3 will generate a pcc64 kernel to save its life. But yo ucan try. [11:18] isn't gcc-3.3 still in main? [11:20] gcc-3.3 -m64 -o hello.o -c hello.c [11:20] cc1: error: invalid option `64' [11:20] i guess it doesn't [11:21] 11:20 < fs> Mithrandir: hyperthreading, no IOMMU, and compiled with -march=nocona [11:22] Mithrandir: meaning of? [11:23] the xeons doesn't have an IOMMU [11:23] so we need xeons [11:24] but i think we can kill k8* and make generic and generic-smp [11:24] that will remove one flavour [11:26] i am not even sure it's worth the pain [11:26] but k7* should go [11:27] infinity: we can probably cheat there [11:27] set M486 that is common [11:27] and call it 686 [11:27] that should work on k7 too [11:28] k7 has a different cache shifting level [11:28] so there is a bit of performance impact [11:28] config X86_L1_CACHE_SHIFT [11:28] int [11:28] default "7" if MPENTIUM4 || X86_GENERIC [11:28] default "4" if X86_ELAN || M486 || M386 [11:28] default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 [11:29] || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODEGX1 [11:29] default "6" if MK7 || MK8 || MPENTIUMM [11:30] would that be hard to detect runtime? [11:30] using cpuid or something? [11:30] cflags-$(CONFIG_M686) += -march=i686 [11:30] cflags-$(CONFIG_MK7) += $(call cc-option,-march=athlon,-march=i686 $(align)-functions=4) [11:31] Mithrandir: eh.. it depends. let me check [11:32] these kind of patches are sort of intrusive [11:32] Defaulting to 6 and seeing if it hurts Pentium4 and PentiumII would be my preference. [11:32] But that's cause I own a Pentium-M. :) [11:33] i don't like playing with L1 cache at random [11:34] i am pretty sure who did that stuff knows more than us [11:34] include/asm-i386/cache.h:#define L1_CACHE_SHIFT (CONFIG_X86_L1_CACHE_SHIFT) [11:34] include/asm-x86_64/cache.h:#define L1_CACHE_SHIFT (CONFIG_X86_L1_CACHE_SHIFT) [11:36] arch/ia64/sn/kernel/bte.c: BUG_ON(!(len < ((BTE_LEN_MASK + 1) << L1_CACHE_SHIFT))); [11:36] arch/ia64/sn/kernel/bte.c: transfer_size = ((len >> L1_CACHE_SHIFT) & BTE_LEN_MASK); [11:36] it's stuff like this i have no idea it can be mangled at boot time, early enough to make it working [11:37] Well, given than all those options work on all CPUs, just to varying degrees, it can't be that bad to fiddle with it. === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel [11:38] infinity: i am not completely sure about that... [11:38] the option is to a certain value... [11:38] changing the value at runtime, might require a flush of cache [11:38] i think at least.. [11:39] Oh, yes, changing it at runtime could blow things up. I meant that defaulting to something sane enough for everyone at build time wouldn't kill us. [11:39] not sure... [11:40] Given that 7 is the default for generic, and 4 is the default for 386, and both those options work everywhere... [11:40] let's make it 5.5 [11:40] Rock. [11:41] Then round up to 6, and I win. [11:41] As do all k7 and Pentium-M owners. [11:41] and 686 lose [11:41] And, really, anyone buying a new 686 system that isn't k7 or Pentium-M sucks anyway. :) [11:41] given i have only 686.. you lose [11:41] (But we don't know how much you lose by without testing) [11:42] excactly [11:42] and given the -ENOTIME... [11:42] Right now, our 686 kernels are already slower than they should be on k7 and pentium4, I don't see much difference here, except that we probably improve both those situations. === infinity -> dinner [11:46] ok let see what's the outcome from Mith's tests on k7 [11:57] better kill 686, crappy stuff anyways ;) [11:57] hi fabbione =) [11:57] why the flavour reduction at all? [11:58] the k8 and xeon flavours do different cache aligning, too [11:58] hi fs :) [11:58] fs: -ETOOMANYFLAVOURS [11:58] we are experiencing problems with users not being able to understand what to install [11:58] reducing the set of options will make it simpler [11:59] that drives users in compiling more own kernels, as they want a best fitting kernel for their arch [11:59] well, thats an argument [11:59] but why not just explain what to install instead? [11:59] fs: we do.. and it's a FAQ.. [11:59] still people don't understand :) [11:59] also [11:59] there are some bugs that are coming up only in specific flavours... [12:00] probably due to compilation options? [12:00] I see [12:00] so that would also reduce the amount of things to debug [12:01] so getting to a smaller set of kernels, will reduce a lot of problems [12:01] Ubuntu's target audience is (generally) not the sort of group that would compile their own kernels for optimal performance anyway. [12:01] to a certain degree [12:02] And the few tha treall want to can use make-kpkg and I won't yell at them. [12:02] infinity: tell that to glxgears and daniels :) [12:02] I still build my own kernels in most situations too (though, I use a stock kernel on my laptop) [12:02] i think we should upload a fake glxgears that multiply by 10 automatically [12:02] Or just drop the glxgears binary completely. [12:03] Or include a real OpenGL benchmark for people who seem to think they need one. [12:03] ehhehe [12:03] i prefer to cheat.. it's more fun [12:04] But, really, our target market is a "win32 killer", and I haven't noticed Windows installing a sozen different kernels depending on your CPU. [12:04] (THough they may do on-the-fly cache tuning, depending on CPU) === chmj [~chmj@196.36.161.235] has joined #ubuntu-kernel === jbailey [~jbailey@testhaus.cns.utoronto.ca] has joined #ubuntu-kernel === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [02:12] damn idiots [02:16] hey zul [02:16] sup? [02:28] not much...idiot is taking my nick again [02:41] i think ill drop a huge megaton bomb on his ass [02:41] you could just register your nick and ghost him [02:58] i have and did [03:23] The same guy takes my nick every time I fall offline (which is usually for a very short period, once or twice per month) [03:23] I can't understand the fascination with it, since he always gets punted shortly after. === Hohlraum [~mlenz@commons10k1.mo24.107.47.196.charter-stl.com] has joined #ubuntu-kernel [05:20] Sorry to barge in.. would someone happen to know what version of 2.6 the hoary installer is using? i've got some dell 1850 and 2850 hardware that needs the drivers included with newer versions of 2.6 [05:20] 2.6.10 [05:26] very cool.. i think that might be the magic version that those drivers were included in. excellent. thanks! === Hohlraum [~mlenz@commons10k1.mo24.107.47.196.charter-stl.com] has left #ubuntu-kernel [] === lamont [~lamont@15.238.5.154] has joined #ubuntu-kernel === crimsun [~crimsun@rchp4.rochester.ibm.com] has joined #ubuntu-kernel [08:20] fabbione: I remembered why I was looking for you... [08:21] lamont: ah cool === swarm [~swarm@host116-125.pool80181.interbusiness.it] has joined #ubuntu-kernel === crimsun [~crimsun@rchp4.rochester.ibm.com] has joined #ubuntu-kernel === fabbione goes offline === smurfix [~smurf@smurfix.developer.debian] has joined #ubuntu-kernel === swarm [~swarm@host175-150.pool80181.interbusiness.it] has joined #ubuntu-kernel === doko [~doko___@dsl-084-059-066-007.arcor-ip.net] has joined #ubuntu-kernel