[12:04] <[g2-dapper] > well actually this:
[12:04] <[g2-dapper] > drivers/net/wireless/airo.c:7538: error: static declaration of flashpchar follows non-static declaration
[12:04] <[g2-dapper] > drivers/net/wireless/airo.c:7458: error: previous implicit declaration of flashpchar was here
[12:04] <[g2-dapper] > make[3] : *** [drivers/net/wireless/airo.o]  Error 1
[12:04] <crimsun> with current git?
[12:04] <[g2-dapper] > yeah
[12:04] <[g2-dapper] > I'm all up-to-date on the 6.06 and git pull
[12:05] <crimsun> yeah, that's unfortunate.
[12:05] <[g2-dapper] > isn't there a sha1sum for the whole tree somewhere ?
[12:05] <[g2-dapper] > and one just types make from kernel dir right ?
[12:06] <crimsun> apt-get build-dep linux-image-$(uname -r), then you debuild binary after pruning debian/config/
[12:11] <[g2-dapper] > crimsun: I'm off to a meeting bbl thx
[12:11] <[g2-dapper] > I'd like to get the right recipie and I'll update the wiki
[12:11] <[g2-dapper] > cheers
[12:14] <BenC> desrt: none that I can recall
[12:16] <desrt> BenC; can you toss it back in for the next release, please?
[12:17] <desrt> huge pages and the hugetlbfs support to go with...
[12:22] <BenC> desrt: I'll build it and test to make sure it runs on my G5
[12:22] <desrt> awesome.  thanks.
[08:40] <infinity> BenC: It's running sid right now, and can't boot from CD (It's OldWorld), so I can't test a LiveCD on it..
[08:41] <infinity> BenC: How far into said kernel do you need it to boot?  I could boot the intstaller from BootX, I guess.
[08:41] <infinity> (If I put a head on it)
[02:17] <zul> heylo
[02:18] <BenC> infinity: I'm interested in if it has the same really slow X problems mine does
[02:18] <zul> fabbione+BenC: are you guys going to be at the tech board meeting today?
[02:18] <BenC> zul: I should be
[02:18] <zul> nifty
[02:30] <infinity> BenC: Is yours a rage128?
[02:30] <infinity> BenC: If so, then I can try to test later, but it'll mean doing a hacked-up install at some point.
[02:38] <BenC> yeah, it is r128
[02:38] <BenC> it's slow to the point of being unusable
[02:38] <BenC> even trying to switch back to a console takes about 3 minutes
[02:39] <BenC> console is perfectly fine though
[02:44] <infinity> Harsh.
[02:44] <infinity> Kay, I'll poke it between now and the weekend, if that's fast enough for you.
[02:44] <infinity> I can't guarantee "EEK, RIGHT NOW", since the machine is a pain to fiddle with, and I have a pretty nasty TODO list.
[02:44] <BenC> no hurry
[02:44] <infinity> You and I may be the only G3 users anyway. :)
[02:45] <infinity> Is yours a Beige G3 (like mine), or Blue?
[02:46] <infinity> Also, if it's something sketchily CPU-specific, I may not catch it, since I'm running an upgraded 1GHz 750GX, not the original 233MHz whatever-the-heck-it-was that it shipped with.
[02:47] <infinity> But I'd assume it's chipset/bus or video card, not CPU.
[02:57] <BenC> It's like smoke
[02:58] <BenC> it's a 600Mhz with slot load, and aiport capable
[02:58] <BenC> infinity: BTW, would you happen to have an airport adapter for an iMac laying around?
[03:00] <infinity> Nope.  I never touched the candy-coloured hardware.
[03:00] <infinity> (Nothing newer than the Beige G3 here)
[03:00] <BenC> from what I've read the adapter used to come with most airport cards when you bought it, but I've thrown away all the stuff that came with the two cards I bought for the G4's a few years ago
[03:15] <fabbione> hey BenC 
[03:15] <fabbione> zul: at what time is it?
[03:15] <fabbione> BenC: i am preparing a couple of bug fixes for you
[03:16] <BenC> ok
[03:17] <crimsun> fabbione: 20:00 UTC
[03:17] <fabbione> unlikely...
[03:21] <fabbione> BenC: done, can you please pull from me?
[03:21] <fabbione> it's 3 one liners in the cluster suite
[03:22] <mjg59> BenC: Can you pull the patch from http://lkml.org/lkml/2006/5/9/11 ?
[03:23] <BenC> mjg59: I dunno...I'm kind of bored with this whole patching thing...was thinking about just deleting any files that have bugs :)
[03:24] <BenC> I'll get it in today
[03:24] <fabbione> ROFL
[03:24] <fabbione> BenC: when do you  plan to open the kernel for edgy? (at least in git)
[03:24] <BenC> fabbione: Hopefully aftet the next kernel upload I'll start doing the merge to latest git
[03:25] <BenC> create an ubuntu-edgy tree
[03:25] <BenC> I really should have done ubuntu-dapper instead of ubuntu-2.6, but oh well
[03:25] <fabbione> BenC: cool thanks
[03:26] <crimsun> BenC: ok, for the most part the sound/* portions can be dropped, then
[03:26] <fabbione> BenC: i think you could just push an ubuntu-dapper-2.6 from this tree
[03:26] <fabbione> BenC: to maintain stable and use ubuntu-2.6 for development
[03:26] <BenC> crimsun: Hopefully git-pull will not barf too much on the sound tree when I do all that :)
[03:27] <BenC> fabbione: that might be wise too
[03:27] <fabbione> BenC: i think it's easier that way
[03:27] <fabbione> imho
[03:27] <crimsun> BenC: (it probably will due to the xxx_t typedefs having disappeared)
[03:29] <BenC> yeah, that will likely get ugly
[03:30] <fabbione> BenC: it's probably easier if you ask davem for his "suck" script
[03:30] <fabbione> BenC: get .17 git and resuck all the changes from our tree into iot
[03:30] <fabbione> it
[03:30] <fabbione> instead of sucking from upstream
[03:31] <fabbione> that should reduce the noise a lot
[03:31] <BenC> mjg59: done
[03:31] <mjg59> BenC: Ta
[03:31] <BenC> fabbione: I think that will be just as ugly
[03:31] <fabbione> BenC: i don't think so
[03:31] <fabbione> specially for all taht stuff that's already upstream
[03:32] <BenC> you have no idea the layers of crap over crap I've done to some portions of code :)
[03:32] <BenC> patch + fix crap + fix crap + fix crap
[03:32] <fabbione> hmmm
[03:33] <BenC> then there's the whole ieee80211 stuff that is going to be morbid
[03:33] <BenC> probably just ditch most of what I have for pristine upstream code there
[03:33] <fabbione> i am NOT sure i want to know
[03:35] <BenC> good thing is that _most_ of the patches to stock code are already upstream, bad part is some of it had to be munged because of slight differences
[03:35] <BenC> so it most cases, I'll just revert to stock code
[03:35] <crimsun> that's the preferred resolution for sound/* at least
[03:59] <BenC> crimsun: have you seen https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/34831 ?
[03:59] <crimsun> BenC: yes.
[03:59] <crimsun> I've been tracking that, and it's horribly complicated.
[04:00] <crimsun> apparently it has nothing to do with synth and everything to do with rtc?
[04:00] <crimsun> since I now have two test cases where, using snd_intel8x0 without snd_seq loaded or timidity running, invoking rosegarden4 will _not_ freeze the machine at all
[04:01] <crimsun> (speaking of which, I need to push out a couple patches)
[04:01] <BenC> ok, I'll leave it in your capable hands :)
[04:02] <crimsun> it's a really nasty bug, since even upstream is vulnerable
[06:54] <purpleidea> hey BenC or others had a little kernel question as per the ubuntu kernel. perhaps it's just me, but the second cpu (CPU1) on a dual core 2.00ghz doesn't "throttle" while the 1st one does. the 2nd either stays at 2.00ghz or 1.00ghz. is this a bug?
[07:00] <BenC> purpleidea: I believe that's already in the bug tracker, check launchpad.net/malone for it (against linux-source-2.6.15)
[07:04] <purpleidea> BenC: i'm not 100% pro with finding these things but here: https://launchpad.net/distros/ubuntu/+bugs and sorting by package name of linux-source-2.6.15 i don't see anything related.
[07:06] <purpleidea> wait still looking./...
[07:08] <purpleidea> there is 31291 if thats what you mean
[07:10] <BenC> Nah, there is one more specific
[07:10] <BenC> and if I remember correctly, the issue is not that it is actually at that rate, just that it isn't being reported correctly
[07:11] <purpleidea> any ideas where the bug is? ... i'm not awesome with mykernel yet, but i've been learning... any idea how i can help figure this out?
[07:13] <BenC> If I knew for sure, it'd be fixed :)
[07:14] <purpleidea> yeah naturally :) okay what i mean is, maybe fewer people have the appropriate hardware, so if there's something useful  i can do, what might it be? ps: any idea what the appropriate bug # is /
[08:21] <infinity> Wasn't the "dual-core CPUs don't frequency scale" bug a powernowd bug, which was fixed with the last upload?
[08:21] <infinity> Or is there ALSO a kernel bug? :)
[08:21] <zul> there is no bugs...*jedi mind trick*
[08:23] <infinity> There's also no grammar.
[08:23] <zul> exactly
[08:24] <zul> really i havent checked about the dual-core stuff
[09:26] <Keybuk> infinity: I wonder whether there are hard-cores which let you scale each core separately :p
[09:27] <mjg59> Powernowd bug, yes
[09:27] <Keybuk> and if not, what would happen if you wrote different values to each /sys/.../cpuN attribute
[09:27] <Keybuk> given they appear as two CPUs in Linux
[09:27] <mjg59> Keybuk: What do you mean by "hard-cores"?
[09:28] <mjg59> Intel's stuff lets you independently scale cores
[09:28] <Keybuk> mjg59: "Solo" is clearly soft core :)  "Dual" is clearly hard core :)
[09:28] <Keybuk> Duo, even
[09:28] <zul> heh
[09:28] <mjg59> Hence the bug...
[09:28] <mjg59> Not sure about the Turions
[09:28] <Keybuk> what about the AMDs?
[09:28] <mjg59> I don't have an X2
[09:29] <Keybuk> this thing doesn't have any attributes in /sys/devices/system/cpu/cpu{0,1} except "online"
[09:29] <Keybuk> I have an X2 if you want to fiddle
[09:29] <mjg59> Anyway. I'm going to catch a few minutes sleep before TB
[09:58] <infinity> Keybuk: Does udev actually autoload them at all?
[09:58] <Keybuk> yes
[09:59] <Keybuk> autoloads both
[09:59] <infinity> Keybuk: On my machine, if I install nvidia-glx-legacy, the right thing happens (I get the legacy module loaded when X loads)... If the right thing didn't happen, the module and X driver would mismatch.
[09:59] <infinity> Keybuk: And on a system with a recent adapter, both modules support the adapter.
[10:00] <zul> BenC: ping..meeting
[10:00] <Keybuk> quest scott% modprobe -n -v pci:v000010DEd00000090sv000010DEsd00000090bc03sc00i00
[10:00] <Keybuk> WARNING: Not loading blacklisted module nvidiafb
[10:00] <Keybuk> insmod /lib/modules/2.6.15-22-amd64-k8/volatile/nvidia_legacy.ko
[10:00] <Keybuk> is what I get
[10:00] <Keybuk> uh
[10:00] <Keybuk> insmod /lib/modules/2.6.15-22-amd64-k8/volatile/nvidia.ko
[10:00] <Keybuk> :)
[10:01] <Keybuk> so it tries to load nvidiafb, nvidia_legacy AND nvidia
[10:01] <infinity> And one of them stays loaded?
[10:01] <Keybuk> yes
[10:01] <infinity> That's.. Bizarre.
[10:01] <infinity> How on earth does this actually appear to work, then? :)
[10:01] <Keybuk> I don't know
[10:01] <Keybuk> how does it work? :p
[10:02] <infinity> Hell if I know, I just know it does.
[10:02] <Keybuk> actually, it may not work
[10:02] <Keybuk> we may just be lucky
[10:02] <infinity> But I'd never noticed the modules being loaded on boot at all ANYWAY, only when nvidia-glx calls "modprobe nvidia" on initialisation.
[10:02] <mdz> infinity: loaded when X loads?
[10:02] <mdz> rather than during coldplugging?
[10:02] <infinity> mdz: Yes, that's when it's meant to  be loaded (and IME, is when it happens)
[10:02] <Keybuk> no reason why they wouldn't be loaded on boot
[10:03] <Keybuk> infinity: you have an nvidia?
[10:03] <infinity> Hence why I'm confused about the udev case, since I'd not seen it ever actually loading anything here.
[10:03] <infinity> Keybuk: In my girlfriend's machine.  I test both drivers on it when I do any LRM stuff.
[10:03] <mdz> infinity: what's your take on how we should best reduce memory usage due to lrm on the live CD?
[10:03] <mdz> it would be nice to be able to ditch it, or parts of it, after a certain point
[10:04] <infinity> Delete the bits not loaded in S99freeupspace?
[10:04] <Keybuk> why wouldn't you expect it to get loaded?
[10:04] <Keybuk> it's in modules.alias
[10:05] <infinity> Keybuk: Yes, so I would expect it to get loaded.  It just never seemed to actually do so, so I never thought to ask "why".
[10:05] <Keybuk> quest scott% sudo udevplug /devices/pci0000:00/0000:00:0e.0/0000:01:00.0
[10:05] <Keybuk> May  9 21:05:14 quest udevd-event[14696] : run_program: '/sbin/modprobe -Q pci:v000010DEd00000090sv000010DEsd00000350bc03sc00i00'
[10:05] <infinity> Keybuk: However, it may be perfectly sane for me to stop the modalias entirely so it definitely doesn't get loaded until X loads.
[10:05] <Keybuk> quest scott% /sbin/modprobe --first-time -n -v pci:v000010DEd00000090sv000010DEsd00000350bc03sc00i00
[10:05] <Keybuk> WARNING: Not loading blacklisted module nvidiafb
[10:05] <Keybuk> WARNING: Module nvidia already in kernel.
[10:05] <Keybuk> insmod /lib/modules/2.6.15-22-amd64-k8/volatile/nvidia_legacy.ko
[10:05] <infinity> s/stop/strip/
[10:05] <Keybuk> -- 
[10:05] <Keybuk> etc.
[10:06] <Keybuk> maybe you tested this before lrm happened before udev? :p
[10:07] <infinity> I tested it not that long ago, IIRC.  But I can test again when I attack some other odd LRM bugs later in the week.
[10:07] <infinity> Worst case scenario, it's now goofy, and I should just remove the modalias, since the X driver loads the kernel driver ANYWAY, which is perfectly sane to me.
[10:09] <Keybuk> seeing as my graphics card still isn't supported by the free driver
[10:09] <infinity> mdz: Once X has loaded, you should be able to unlink any of fglrx/nvidia/nvidia_legacy that doesn't have a refcount (once we've worked out what's up with this goofiness)
[10:09] <mdz> infinity: do you have an early-and-often initramfs-tools to upload?
[10:09] <infinity> mdz: Of course, that prevents the user from switching drivers and restarting GDM (which I've done on the livecd)
[10:09] <Keybuk> UEVENT[1147189650.067289]  add@/module/nvidia
[10:09] <Keybuk> ACTION=add
[10:09] <Keybuk> DEVPATH=/module/nvidia
[10:09] <Keybuk> SUBSYSTEM=module
[10:09] <Keybuk> SEQNUM=2413
[10:10] <Keybuk> yup
[10:10] <Keybuk> definitely loaded by udev
[10:10] <infinity> mdz: I'm halfway through some intrusive breakage, so no, but tomorrow (my tomorrow, meaning in a few hours, cause I should be asleep), yeah.
[10:10] <mdz> infinity: we should be able to unlink them even if they are loaded; unloading and reloading them on the live CD is a fairly odd corner case
[10:10] <mdz> infinity: intrusive breakage?
[10:11] <infinity> mdz: Oh, just the minkernel stuff.  Not horribly intrusive, just needs changing in more than one spot before it doesn't break itself.
[10:11] <infinity> mdz: Basically, I'll upload today with everything fixed except the ENOSPACE issue, then tackle that one in a second upload.
[10:11] <infinity> (Since that one requires more fiddling to make sure it's right, and I'd like the other bugfixes tested while I'm working on it)
[10:12] <infinity> mdz: As for the LRM unlinking thing, if I remove the modalias from nvidia* (which seems sane), it will be in the same boat as fglrx (which has no modalias and is only loaded from X)
[10:13] <infinity> mdz: So, any user wanting fglrx or nvidia on the livecd would generally "apt-get install whatever", reconfigure X, then reload X.  If the modules are no longer there, they lose.
[10:14] <infinity> Anyhow, I need to run off to the girlfriend who woke up at 6am and realised my insomniac butt wasn't in bed and started panicking. :/
[10:14] <infinity> We'll pick this up in a couple of hours, if you're still lurking.
[10:14] <mdz> infinity: I'm more worried about the 'needing' case than the 'wanting'
[10:15] <infinity> The "needing" case is a bit tougher, since they won't get X loading at all, then.  Not sure we have any contingency plan for that.
[10:15] <infinity> mdz: I'll ping back in ~2 hours to continue this.
[10:16] <mdz> infinity: ok, tech board calls anyway
[10:26] <mdz> BenC: ping
[10:28] <makx> blaeh
[10:28] <makx> stupid breezy with the klibc that confuses ext3 with minix
[10:31] <Keybuk> hmm?
[10:32] <BenC> mdz: pong
[10:56] <purpleidea> Keybuk: back to the core issue, on my "duo" 2.00ghz, it seems that cpu0 scales from 50% --> 100% depending on what is needed. but the cpu1 either stays permanently at 100% or sometimes for no particular reason it switches to 50% and gets stuck there
[10:57] <mjg59> purpleidea: powernowd bug, should be fixed
[10:57] <purpleidea> mjg59: and both will scale then.. ?
[10:57] <mjg59> purpleidea: Yes
[10:57] <purpleidea> mjg59: any idea what the bug# is or something?
[10:58] <mjg59> purpleidea: It's been uploaded
[10:58] <purpleidea> mjg59: cool, nice to know... so if it's still happening by _____? (when) i should make another bug report?
[11:01] <zul> yeehaw
[11:48] <BenC> let me know when everyone is here and ready
[11:49] <mdz> I'm here and ready
[11:50] <zul> heylo
[11:50] <mdz> pinged sfllaw
[11:52] <BenC> I'll go ahead and paste what I have
[11:52] <BenC> Issue: Lots and lots of kernel bugs. Even initial response to the bugs is extrememly time consuming. Most do not have all the initial information needed. A great many others are either not bugs, or require a great deal of knowledge in order to debug them. There are only a small number of people who know what information to request, and and even smaller number than actually can take it to the final steps of fixing it (if no fix is available
[11:52] <BenC> ackported patch).
[11:52] <BenC> Suggested solution: Tiered bugs. All bugs would be processed from the bottom up. Incoming bugs would appear as tier-X. Once the bug has been confirmed and contains all needed information, it would be pushed to tier-Y. From there, the kernel team would attempt to find an existing solution, or determine if a solution is possible. If this is the case, the bug is either fixed immediately (if possible), or pushed to tier-Z. From there the core 
[11:52] <BenC> s would attempt to actually fix the problem from homegrown fixes, or defer the bug to the next release.
[11:52] <BenC> Reasoning: I use a lot of time perusing bugs at their initial stages. My time would be better spent if I knew that the bugs I was reading were 1) Ready to be debugged, and 2) Pertinent to our current release cycle.
[11:53] <mdz> my impression is that the current kernel team is focused on development, and don't have bandwidth to keep up with the bug volume on top of that. we need more people to help respond to bugs and participate in the triage effort
[11:53] <Keybuk> I assume one part would also be finding git commits (gimmits? :p) that match the problem?
[11:54] <BenC> mdz: mostly correct, yes
[11:54] <mdz> BenC: Simon is here to help with the first stage of your proposed solution, but on a distribution-wide scale
[11:55] <mdz> I think it would be beneficial to organize an effort specifically focused on the kernel's bug queue
[11:55] <BenC> is there a way to integrate with him so that I can get someone to do most of the "test latest" and "send foo, bar, blah"
[11:55] <BenC> ?
[11:55] <zul> ill help where I can as well but there is alot of stale bugs as well I find.
[11:56] <mdz> BenC: I suggested that, and you two scheduled a meeting to talk about it, as I recall
[11:56] <mdz> did that happen?
[11:56] <BenC> the other big problem is that I had finally gotten bugzilla kernel bugs to a point where everything was in the correct state, but when we switched to malone, the learning curve, and the intense development on the kernel let things slide terribly to the way they were before
[11:56] <BenC> mdz: I think we missed eached other twice
[11:56] <BenC> I'll get on that asap
[11:57] <BenC> finishing last statement: Most of the kernel bugs are not in the correct state (severity, target, status)
[11:58] <mdz> BenC: please give him a call today; you guys should have no trouble connecting given your time zones (I'm jealous!)
[11:58] <BenC> hehe
[11:58] <mdz> BenC: I agree; in particular there are a huge fraction which need to go from unconfirmed->needinfo with a question
[11:58] <BenC> sfllaw is the correct nick?
[11:58] <mdz> yes
[11:58] <BenC> right
[11:59] <mdz> the trouble is, we can't effectively tell which bugs are pertinent to the release until they've been through an initial round of triage
[12:00] <zul> sorry got disconnected
[12:00] <mdz> perhaps it would help to formulate an advanced search in Malone which targets these bugs, and send a call for help to -devel-announce with the URL
[12:00] <mdz> it can go a long way to provide a clear and measurable target
[12:00] <mdz> "we need to shrink this list here"
[12:00] <BenC> right
[12:00] <mdz> I think we talked about a short wiki writeup for how to handle kernel bugs; do we have that?
[12:01] <BenC> good thing is, I've wound down kernel devel right now, so next week I am ready to just triage the bug list
[12:01] <zul> basically its send this infomration if you have this problem
[12:01] <BenC> yes, we have that
[12:01] <mdz> great, that can be included in the announcement too
[12:01] <BenC> it's a list of the "always send this info" type stuff
[12:01] <zul> what would be good for edgy is have something like kgdb or something like that
[12:01] <BenC> dholbach did the page up
[12:02] <BenC> zul: honestly, I haven't come across too many bugs that would benefit from that without me being able to reproduce it
[12:02] <mdz> BenC: that's good, but a) I don't think you have a chance of getting through that list alone in the time we have, and 2) your time may be better spent working on the bugs which turn out to be serious once they're confirmed
[12:02] <lifeless> it would be great if the bug filing page for the kernel linked in that wiki page
[12:02] <mdz> so we need to parallelize regardless
[12:02] <BenC> nor do we have a great deal of people capable of using it who experience the bugs
[12:03] <BenC> yeah, is there a way to force a message when filing a bug on a certain source/package in malone?
[12:03] <lifeless> BenC: I'm filing a bug on this
[12:03] <mdz> not to my knowledge, but it'd make a good wishlist
[12:03] <BenC> "Hey stupid, dmesg would be nice"
[12:03] <lifeless> we'll need a spec for this, but I'll start with a wishlist bug :0
[12:03] <zul> also a printk at the end of the oops as well ;)