[12:45] anyone know which driver provides rtc on amd64? === horms [~horms@YahooBB219184134048.bbtec.net] has joined #ubuntu-kernel [02:52] there...quickcam and spca5xx playing together like two peas in a pod === horms [~horms@vagw.valinux.co.jp] has joined #ubuntu-kernel [05:17] bleah...i cant sleep [05:26] morning [05:26] hey fabbione [05:29] zul: 7808 is d-i related. we still need todo thed-i cleanup in the kernel [05:29] see debian/TODO [05:29] updated? [05:29] Verify debdiff with previous kernel and add new drivers to d-i. [05:32] okie dokie printk stuff...what do you want to cut down? [05:33] there are a couple of printk during the boot that are marked as _ERRO or _CRIT [05:33] the audit thing [05:34] and the swsup wrong partition id [05:34] ok i can look into that [05:34] they should be changed to _INFO [05:34] we don't want to lose them [05:34] just make them less noisy [05:36] so the audit: [05:38] yes [05:38] and the swsups one [05:39] okie dokie [05:55] so something like this? http://zulinux.homelinux.net/kernel-power-swsusp_shutup.dpatch [05:57] except you diffed it the wrong way yes [05:57] but not all of the messages [05:57] only the one that shows at startup [05:57] ok...then it might be time get some sleep then [05:57] ok [05:57] some of them are important to have [05:59] ill see you guys tomorrow [06:00] night zul [06:00] i added some more external drivers from the list but ill put them in my baz archive when i get up tomorrow [06:01] late [06:01] later even [06:04] ok [06:59] lamont: ping me when you are around again [07:00] ack [07:01] lamont: i was wondering if we can integrate sparc build logs on people [07:01] yeah - that's on my list of things to ponder. [07:01] specifically, now to integrate them. [07:02] i guess you have somekind of script that scp them from the buildd's to people [07:02] we might just adapt it [07:02] you probably have to change the permissions on the tree so that i can write there [07:03] actually, the copy on rookery is a mirror of the master, that lives elsewhere [07:03] ah [07:03] hmmm [07:03] that makes it more complicate [07:33] mmm the ipw2200 driver has gone from crashing requiring a module reload to crashing requiring a reboot :\ [07:33] Lathiat: complain with upstream [07:33] it's the latest version of the driver [07:34] yeh i know was just saying [07:34] is it hard to debug kernel drivers? [07:37] pretty much yes [07:46] how much do we care about the abi in 2.6.11.9* serie? [08:03] there.... rh cluster suite updated [08:04] lamont: i am still checking out linux-ipv6 [08:04] unbelievable [08:04] more than 24 hours co [08:04] ouch, which project is that from? [08:04] linux-ipv6/usagi [08:04] fabbione: I don't think we care about the abi version until 2.6.12-1.1 [08:04] ipv6 statefull firewall [08:04] yeh usagi [08:05] lamont: yeah [08:05] esp since if we did, we'd be something like 2.6.12-22.1 [08:05] lamont: exactly :) [08:25] lamont: btw.. why the kernel did build 3 times on ppc buildds??? [08:26] at least... there are 3 logs reported [08:27] fabbione: most likely situation was those wonderful SIGILL's that ppc likes to throw on big builds [08:27] it's also possible that I gave it back in the middle of a build [08:27] ah ok === doko [~doko___@dsl-084-059-052-160.arcor-ip.net] has joined #ubuntu-kernel [08:37] hey [08:37] doko, svenl: can we take a look to PPC64 kernel? [08:37] i need to understand a few things [08:38] right now we have 6 ppc flavours [08:38] power3{,-smp} [08:38] power4{,-smp} [08:38] powerpc{,-smp} [08:39] which one of these need to become 64bit? [08:39] or do we need to add a complete new set of flavours? [08:40] for me all this ppc magic is kinda unknow [08:40] and i need to understand what needs to be done [08:41] hmm, don't know, if I can help ... [08:41] doko: well you were asking for a ppc64 kernel [08:42] so where can i build a ppc64 kernel in the first plave [08:42] place [08:43] davis, breezy-ppc64 chroot [08:43] ok.. [08:44] using gcc-3.4 -m64 [08:45] ok we are already using gcc-3.4 [08:45] i think the -m64 is added by the kernel automatically when exporting ARCH=ppc64 === fabbione checks [08:46] yes [08:46] that is done automatically... [08:46] so now.. i need to understand what flavours need to be built that way [08:48] GCC_BROKEN_VEC := $(shell if [ $(GCC_VERSION) -lt 0400 ] ; then echo "y"; fi ;) [08:48] interesting :) [09:23] fabbione: basically, the only thing you need to do is to add ARCH=ppc64 when building. [09:24] fabbione: i guess for symetry purpose, you would need to do : [09:24] svenl: yes.. i know that, but i am more interested to know what flavours i need to build [09:24] ARCH=ppc for powerpc flavour, and ARCH=ppc64 for the ppc64 flavours. [09:24] well. [09:24] yeah i get that :) [09:24] both power3 and power4 are now called pseries. [09:24] so i would have pseries and iseries. [09:25] that is : powerpc/ppc, pseries/ppc64, iseries/ppc64 [09:25] ok from the actual mapping: [09:25] but it is also possible to build a power4 and beyond optimized pseries version, so i would add a : [09:25] powerpc{,-smp} -> ARCH=ppc, no name change [09:25] pseries-power4/ppc64. [09:25] fabbione: ok. [09:26] how do i map power3 and power4? [09:26] fabbione: for power3/power4, just add new versions. [09:26] so something like: [09:26] ppc64-power3 [09:26] ppc64-power6 [09:26] meh [09:26] ppc64-power4 <- [09:26] and of course build them with ARCH=ppc64 [09:27] one moment. [09:27] sure [09:27] fabbione: forget the old mappings. === fabbione scraps the notes === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel [09:31] Ok, am back. [09:31] no rush.... [09:32] fabbione: i don't have it in my mind right now, but basically, for all ppc/ppc32, the configs should be almost similar. [09:32] with a little modifications. [09:32] svenl: right now i need only the name schema [09:32] fabbione: ok. [09:32] forget about the contents of the configs [09:32] so, i would do : [09:32] ARCH=ppc -> powerpc{-smp} [09:32] ARCH=ppc64 -> pseries{-smp} [09:32] ARCH=ppc64 -> pseries-power4{-smp} [09:33] ARCH=ppc64 -> iseries{-smp} [09:33] where is power3 in this schema? [09:33] as for the actual difference between the 3, iseries is the iseries variant, and pseries is the pseries one. [09:33] and pseries-power4 is the power4 optimized version of pseries. [09:34] fabbione: pseries now support both power3 and power4. [09:34] fabbione: but you can enable power4 and beyond only optimization, which bring a performance gain, but drop support of the power3. [09:34] This is pseries-power4. [09:35] so what is the iseries? [09:36] i am sorry if these questions are lame [09:36] but i am trying to understand the best i can [09:36] AS/400. I didn't think they were shipping with different CPUs than the pseries, just different gear under the hood... [09:40] fabbione: iseries are IBM/power big iron, not previous supported by the ppc32 kernels. [09:41] oh [09:41] so that means generating heaps load of images [09:41] fabbione: not really. [09:41] of the old power3/power4 images.. is there something we can actually drop safely? [09:41] For the installer, we should be able to cut back to two images. [09:41] A very generic ppc32 and a very generic ppc64. [09:41] it will only be 8 images compared to 6 previously. [09:42] fabbione: we can indeed only keep powerpc and pseries for the installer. [09:42] Unless the ppc64 generic images wont boot on AS/400 kit for some reason, and that would be silly. [09:42] or maybe powerpc and pseries-smp [09:42] ok [09:42] fabbione: i would build iseries as netboot only. [09:42] let me try to summarize [09:42] svenl: netboot will still require an image [09:42] but this means enabling the mkvmlinuz build. [09:43] powerpc stays as it is [09:43] fabbione: sure, but you don't need to put it on the CD. [09:43] power4{,-smp} -> pseries-power4 [09:43] power3 -> vanish [09:43] mmm, come to think of it, mkvmlinuz needs fixing for ppc64. [09:43] fabbione: nope. [09:43] we introduce iseries and pseries [09:43] power[34] {-smp} -> pseries{-smp} [09:44] ok [09:44] roger that [09:44] pseries-power4{-smp} is an optimized version of the pseries for power4 and beyond. [09:44] how big is the performance gain? [09:44] like you have normal -386 and -k7 and such. [09:44] fabbione: not sure. [09:44] fabbione: 20-40 % maybe ? [09:44] I'd question that 40.. :) [09:45] 20 would be generous. [09:45] need to ask the IBM guys. [09:45] infinity: i don't know. [09:45] i think no more than 5% [09:45] but it is an important gain. [09:45] fabbione: how much would be the gain from -i386 to -k7 ? [09:45] It's a measurable gain, but it's not massive. [09:45] anyway. [09:45] svenl: minimal :) [09:45] Especially not from the point of view of userspace. [09:46] infinity: the ppc64 guys told me : please don't cripple the ppc64 kernels. [09:46] but well. [09:46] fabbione: if you want to gain space, you can drop the non-smp power3 variant. [09:46] Can't we pull tricks to optimise for power4, without using new ops? [09:46] why that? [09:46] (This can be done in intel systems, slowing down older CPUs, but allowing them to still work) [09:47] Also, I question the value of any non-smp kernels, but that's something we still need to test more, I suppose. [09:47] power3 boxes are few indeed, and the majority of those are smp variants, and the smp kernel should work on up. [09:47] so i would do : [09:47] powerpc, powerpc-smp, pseries-smp, pseries-power4, pseries-power4-smp, iseries [09:47] (i guess it makes no sense to have non-smp iseries :) [09:48] so it would be: [09:48] which leaves us at exact the same amount of kernels as today. [09:48] powerpc, powerpc-smp, pseries-smp, pseries-power4, pseries-power4-smp, iseries-smp [09:48] just to keep the name schema coherent [09:48] fabbione: yep. [09:48] There are single CPU iseries machines, but the only people who use them are hackers writing software for the big iron, generally. === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-kernel [09:49] infinity: so they can live with the 5% or whatever performance drop, or use their own stuff. [09:49] hackers don't use precompiled kernels [09:50] infinity: do you know what those iseries machine use for booting ? [09:50] Not sure. I've only seen one, and it was running AIX. [09:50] AndErm, OS/400. [09:50] Brain fart. [09:51] But, yeah. I didn't ever hit the little white switch to reboot it. [09:51] It was happy on its own. [09:51] infinity: do you think yaboot will work on them ? [09:51] It's possible. I'd like to get my hands on one for testing. [09:51] And those are the ones which don't do funny partitioned computing stuff. [09:52] A single CPUU iSeries can still run VM, but I'm not sure why one would want to. :) [09:52] (It's a possible use case, though) [09:52] But unless we have some people at IBM who want to help out, this is all "I played with one a couple of years ago" experience. [09:57] i will investigate about this. [10:01] fabbione: will you build an 2.6.12-rc4 kernel packages ? Or still go with 2.6.11 ? [10:01] 09:58 < mpee_> svenl, a non SMP kernel won't boot on iSeries so don't bother [10:02] Oh, they actually market single CPU iSeries stuff to end-users now. [10:02] And yes, they're running VM by default. [10:02] svenl: 2.6.12rc4 [10:02] so i guess that solves it. I would drop the -smp name of it though. [10:02] fabbione: cool. [10:02] i am not spending time on .11 [10:02] (Which allows them to ship them with Linux and OS/400 installed, in two seperate partitions) [10:02] do you have something i can try on my powerbook already ? benh said that 2.6.12-rc4 will solve all power management and sleep issues. [10:02] Which would also explain why the non-smp kernels won't work, cause I think all the VM magic is tied to SMP. [10:02] svenl: not for ppc64 [10:03] svenl: the 32 bit images are in the archive already [10:03] universe -> linux-source-2.6.12/ [10:03] 10:01 < benh> svenl: pmac/pseries/everybody else can be a single image [10:04] fabbione: no prebuilt kernel though. [10:04] fabbione: you think my powerbook G4 will like ppc64 kernels ? [10:04] yes.. they are in that dir [10:04] svenl: no idea.. i am not a ppc guy :) [10:04] that's why i keep asking ppc stuff around [10:04] fabbione: :) [10:05] svenl: what does benh mean? [10:05] fabbione: the G4 is ppc32. [10:05] 10:01 < benh> svenl: drop UP kernels on ppc64 [10:05] 10:01 < svenl> benh: :) [10:05] 10:01 < benh> svenl: I don't think they make any sense [10:05] 10:01 < benh> svenl: iseries ... oh well, yes, they still need a specific kernel [10:05] 10:01 < benh> svenl: pmac/pseries/everybody else can be a single image [10:05] 10:01 < benh> svenl: I'm not sure about the performance impact of doing the CONFIG_POWER4 option there [10:05] 10:01 < svenl> benh: even on pseries-power4 ? There are a bunch of single CPU G5 pmac about, don't they would lose in [10:05] performance. [10:05] 10:02 < svenl> benh: do you know who might know ? [10:05] 10:02 < benh> svenl: maybe they would ... [10:05] 10:02 < benh> dunno [10:05] 10:03 < svenl> ok, so i guess we should keep them in the first run, and then drop them after a bit of experimentation. [10:05] fabbione: basically, he is advocating having only 2 ppc64 kernels, pseries and iseries, both of the smp variant. [10:06] ok [10:06] and one ppc32 kernel [10:06] but 1) no idea what the performance drop will be for single cpu powermac G5s. [10:06] and 2) no idea if the power4 optimization is worth it. [10:06] ok we can start with the minimum [10:06] and see if people will request other kernels [10:06] Shame about iseries needing its own kernel. [10:07] so we will still have 6 kernels :( [10:07] fabbione: i would do : [10:07] no.. actually less [10:07] 3? [10:07] 32bit : powerpc, powerpc-smp [10:07] powepc{,-smp} [10:07] Oh. [10:07] pseries-smp [10:07] 64bit : pseries, iseries [10:07] iseries-smp [10:08] optional 64bit optimized kernels : [10:08] pseries-power4 [10:08] pseries-power4-up [10:08] I'd scrap those two, but whatever. [10:08] me too [10:08] we need to reduce the amount of images [10:08] so, we keep 4 and put them on CD, and build the two others, and keep them on the net. [10:08] fabbione: well. [10:09] fabbione: i would like them to be present in the first round, so we can do performance tests, and then decide. [10:09] fabbione: but as said, you don't need to put them on the CDs. [10:09] svenl: i prefer the other way around :) [10:09] Has anyone done recent tests to see how much it hurts to run smp on up? [10:09] fabbione: not build them, and then make performance tests ? [10:09] infinity: i think not. [10:09] fabbione: maybe we could inverse the situation : [10:09] powerpc-smp should be the only powerpc kernel, if we can help it. [10:10] powerpc, powerpc-up, pseries, iseries. [10:10] (And I'm saying this as aman who owns a ppc32 up machine) [10:10] We can then drop to 3 : powerpc, pseries, iseries. [10:10] svenl: no that would be confusing to death [10:10] and then 3 set of optimized kernels : powerpc-up, pseries-power4 and pseries-power4-up. [10:10] fabbione: why ? [10:11] because the actual schema is -smp [10:11] change it to -up and users will get confused [10:12] fabbione: so what ? [10:12] fabbione: users should not know about this. [10:12] fabbione: have the powerpc/pseries/iseries provide the -smp version and everyone will be happy. [10:12] svenl: they do and they ask questions about stuff like that [10:13] fabbione: so what ? That is what the long description is all about. [10:13] + it breaks coherency with the other arches [10:13] fabbione: so what ? [10:13] fabbione: if we are gonna default to smp versions, let's make it logical. The users will thank you in the long run. [10:13] svenl: i want to be able to keep things coherent even across arches [10:14] infinity: BTW, how do you make up vs smp kernel performance tests ? I could do those on my powerbook. [10:15] svenl : ... Pick a benchmark you like, compile two kernels, identical except for CONFIG_SMP, see how it performs? [10:15] svenl : Benchmarking isn't an exact science, since everyone will want to test different things. Just pick something that should give reasonably consistent numbers. [10:16] I should do this on my amd64 machine when I get it back up, too. [10:16] infinity: ok, my question would be of the kind : what kind of benchmark stress the kernel and not userland ? [10:17] svenl : SOmething that shoves a lot of RAM around for no good reason?.. Filesystem tests... Make something up? :) [10:17] svenl : The real answer is "who cares?.. It's userland performance people see" [10:17] infinity: ok, i will look around. [10:17] infinity: :) [10:17] If a different kernel doesn't appear to affect userland by more than 5%, I say it's "good enough" [10:17] svenl: can a pseriers kernel boot on g5? [10:18] Yes. [10:18] Same CPU. [10:18] infinity: Xu said that the main issue with SMP on UP is the locking mechanism at net layer [10:18] Well, sort of. [10:18] but that's due to: [10:18] fabbione: sure. [10:18] a) crappy code [10:18] b) very very high load on cpu and net (~1GB) [10:18] so it is for sure NOT the common case [10:18] fabbione: notice that the power3 sym53c8xx driver did lock in up mode, and worked fine in smp mode on a dual power3 machine. [10:19] Which brings us to: Thee are shitty Mac-specific drivers for older macs (like my Beige G3) that may suck on SMP, because that hardware just doesn't get used with more than one CPU. [10:20] But it's not hard to put out a call for testers for that sort of thing. [10:20] Most of those driver bugs would surface immediately as oopses or panics, nothing subtle. [10:21] infinity: you default to smp early in the release cycle, and wait for bug reports :) [10:22] People doing constant updates of breezy don't think to upgrade kernels. [10:22] You call for testers, or risk the wrath of a broken installer at release time. :) [10:24] 10:21 < olaf> svenl: running 64bit smp vs. 32bit up on single cpu systems cost 2% [10:27] fabbione : Any objections to dropping the product names (powerpc, pseries) completely from the generic kernels, and just naming them like the hppa kernels? [10:27] 10:23 < olaf> I did not benchmark that. but noone cares. large enterprise thingies run with power4=n and they dont care [10:27] nope [10:27] (2.6.12-32{,-smp}, 2.6.12-64{,-smp}) [10:27] 10:24 < olaf> I did that 64bit smp vs 32bit up on a G5 [10:27] Then for the iseries flavour, you'd have 2.6.12-64-iseries [10:27] Still pretty clear. [10:27] it is just important for me to keep -smp in [10:28] to be coherent with the other arches [10:28] Right. Well, I always found the hppa kernels to be nice and intuitive.. And clean. [10:28] It was obvious what kernel I actually wanted. :) [10:28] exactly [10:28] And Kamion's point about "who would install a kernel called 'pseries' ona G5 Mac?" is a good one. [10:29] yup [10:29] chmj, thom: you around? [10:29] Mac users aren't known for being able to extend their thought processes terribly far. [10:29] yep [10:29] chmj, thom: please start to get familiar with git/cogito [10:29] yep [10:29] there are deb packages around announced on debian-devel mailing list [10:29] or install it from http://www.kernel.org/git/ [10:30] checkout the relevant trees [10:30] linux/kernel/git/torvalds/linux-2.6.git linux/kernel/git/gregkh/stable-queue.git linux/kernel/git/gregkh/linux-2.6.11.y.git [10:30] we have some crack to deal with [10:31] get used on how to grab a single patch out of the tree [10:31] it's pretty simple [10:31] fabbione : Oh, BTW, I sign a lease tomorrow and move my amd64 somewhere where I can actually plug it in, so I will become more useful at that point. [10:31] you use a combination of cg-log and cg-mkpatch [10:31] infinity: rocking :) [10:32] fabbione: i disagree with the -smp part of it. [10:33] fabbione: you will only get questions from people asking where the -up version went. [10:33] fabbione: did you see the info from olaf ? [10:33] fabbione: i would guess just keeping the smp version of powerpc, pseries, iseries would do it. [10:33] as -32, -64 and -64-iseries. [10:34] infinity: you could even do -32 -64 -iseries, as i guess anyone with an iserie machine will know he needs a 64 bit kernel. [10:34] svenl: yes i saw the msgs from olaf [10:36] fabbione: so we are down to 3 (4 if we keep the up 32bit kernels) and add one full subarch. [10:36] infinity: the only problem with your naming scheme would be if you where to support stuff like apus or nubus, which are not yet integrated in the main kernel, as debian will do. [10:37] but then you could have -32, -64, -iseries, -nubus, -apus. [10:37] Would also work fine. [10:48] the only thing i need basically is to be able to recognize a 64bit kernel from a 32bit one from the name, without hardencoding anything in debian/rules [10:48] so something like -64- or ppc64 has to be there [10:48] for the sake of simplicity [10:48] so that given a regexp match i can set the proper arch [10:49] fabbione: just have a flavour file, which gives you the right arch for a given flavour, and parse it from debian/rules. [10:49] fabbione: see how i do it in the 2.4.27 debian powerpc package. [10:52] there is no kernel-image-2.4.7-ppc [10:52] 27 even [10:52] kernel-patch-powerpc-2.4.27 [10:53] fabbione: well, it is overkill for your needs, but the basic format is : [10:53] arch: [10:53] subarch : [10:54] flavour : [10:54] yeah i see [10:54] so you could either have two subarches, ppc and ppc64, and a couple of flavours for each. [10:54] or have only subarch, and use a field to get it. [10:55] something like subarch-arch : ppc64 [10:55] i extract them by grep/sed, which may not be the more astute way of doing it. [10:55] but i believe it is better to have a explicit list, than to try to do some implicit detection like you plan to do. [10:56] and you could even have : [10:56] arch : powerpc [10:56] subarch powerpc : apus nubus ppc32 ppc64 [10:56]