[04:39] <fabbione> BenC: pong?
[04:50] <BenC> ?
[05:18] <fabbione> BenC fabbione: ping
[05:18] <fabbione> you did ping me a few hours back..
[05:18] <fabbione> but i was asleep :)
[05:25] <BenC> oh, hmm
[05:25] <BenC> I forgot :)
[05:40] <fabbione> ehehe ok
[02:39] <mjg59> Hrm.
[02:39] <mjg59> Looks like we may have to bump the ACPI code.
[02:39] <mjg59> http://bugzilla.kernel.org/show_bug.cgi?id=5162
[02:41] <jbailey> Why are there 'of course' less entires in his /porc/acpi?
[02:41] <mjg59> Dunno
[02:42] <mjg59> Oh arrrrrrrrrrrrgh.
[02:42] <mjg59> It's part of the core ACPICA code, so there's no way to get the individual patch out of it
[02:42] <mjg59> And they've lindented the entire ACPI tree
[02:42] <mjg59> Fuckfuckfuck.
[02:42] <mjg59> This is going to be a nightmare.
[02:43] <mjg59> This probably means rediffing most of our acpi patches
[02:43] <Mithrandir> mjg59: diff -w ?
[02:43] <Mithrandir> or -b
[02:44] <mjg59> Oh, no, hang on. This may be tractable.
[02:45] <mjg59> Argh, no.
[02:47] <mjg59> HNNNGH.
[02:48] <zul> heh...dont worry be happy
[02:48] <mjg59> Are carriage returns counted as white space?
[02:53] <BenC> mjg59: should I hold off my upload?
[02:55] <mjg59> BenC: This may take me a couple of days to sort - if you're going to do another pre-Breezy, I wouldn't bother
[02:57] <BenC> mjg59: is this a problem that's already in 2.6.12-8.12?
[02:57] <mjg59> Yes
[02:57] <BenC> oh, ok
[02:57] <mjg59> This is being made excrutiatingly painful by the current patch being against 2.6.13
[02:57] <mjg59> And there having been a pile of acpi diffs since then
[02:58] <BenC> "get git"
[02:58] <BenC> hehe
[03:00] <zul> the arch for preX,14 is coming out soon right?
[03:02] <BenC> should be in the next 12-24 hours
[03:03] <zul> sweet...then i get stuff in again
[03:36] <mjg59> Ah, no, I might be able to sort this
[03:40] <mjg59> BenC: Ok, I'll have a patch for you in a minute
[03:40] <BenC> sweet
[03:45] <mjg59> BenC: http://www.codon.org.uk/~mjg59/tmp/acpi_noexecute.diff
[03:45] <mjg59> BenC: I've got some other patches for you, too. Want me to batch them?
[03:53] <BenC> yeah, get them all together
[03:54] <mjg59> BenC: With that acpi one?
[03:54] <BenC> mjg59: what's the noexecute patch for?
[03:54] <mjg59> BenC: 14652
[03:55] <BenC> any idea if it changes the abi?
[03:55] <mjg59> I believe not
[03:57] <mjg59> BenC: Did you apply my swsusp.diff ?
[03:58] <BenC> yeah
[03:59] <mjg59> Cool
[03:59] <mjg59> Right, patches mailed
[04:01] <BenC> thanks
[04:02] <jbailey> BenC: Are you guys planning an ABI change soon?
[04:02] <BenC> I don't think we ever "plan" an ABI change :)
[04:02] <BenC> but no, there are none expected
[04:03] <jbailey> I should integrate update-initramfs this week or early next, I guess.
[04:03] <jbailey> So that usplash can be updated on its own.
[04:08] <mjg59> BenC: When are you hoping to do the upload?
[04:23] <BenC> in a few hours
[04:24] <mjg59> Cool
[04:55] <zul> jbailey: gcj cannnot load gnu.java.awt.peer.gtk.Gtktookit means anything to you?
[04:57] <jbailey> zul: Do you have libgcj6-dev installed?
[04:58] <jbailey> Or if you're no tdoing dev work, make sure you have libgcj6-awt
[05:01] <zul> okie dokie.. ill try that thanks
[05:01] <jbailey> zul: Whacha doin'?
[05:03] <zul> jbailey: trying to install aqua data studio under breezyu
[05:06] <jbailey> Ah, so not a packaged thing.
[05:08] <zul> nah
[05:11] <BenC> mjg59: the noexecute didn't cause an abi change, so I'll include it in 8.13
[05:12] <mjg59> BenC: Thanks
[07:19] <zul> blah
[07:46] <zul> meh...gave the same hostname on my work pc and my laptop..
[08:10] <dilinger> fabbione: *poke*
[08:29] <zul> hey dilinger how is it going?
[08:44] <dilinger> hey, pretty good
[08:45] <dilinger> one of the proposals for breezy was to do some benchmarks on the various smp/nonsmp images, and drop the ones where the optimizations didn't help much
[08:45] <dilinger> anyone know the results of that?
[08:57] <zul> it didnt happen
[09:22] <fabbione> dilinger: pong
[09:52] <dilinger> fabbione: my question about benchmakrs
[09:54] <fabbione> dilinger: what question?
[09:54] <fabbione> ah yeah
[09:55] <fabbione> sorry i am totally trashed in
[09:55] <fabbione> dilinger: the are no results,  because no real benchmark have been done
[09:56] <fabbione> from readin the code there is already impact running 686 kernels on k7 due to L1 cache allignement
[09:56] <fabbione> between snmo/nosnom Herbet told us that locking at networking layer sucks 
[09:56] <fabbione> so basically you have impact in running smp kernel on UP machines
[09:57] <fabbione> the last but not the least, some subsystems like USB are utterly bugged in SMP
[10:01] <BenC> from what I've read the major impact for an SMP kernel on UP is the cache flush when doing locks, not to mention that lock itself, which can (in total) consume 12 cycles
[10:01] <BenC> but, I do have a nice patch I found that uses a binary patch on kernel startup to turn all lock's into nop's
[10:02] <BenC> would even work when booting an SMP kernel with nosmp
[10:02] <BenC> so it would be easier to prove/disprove a bug is related to SMP
[10:02] <BenC> or related to locking in general
[10:08] <dilinger> BenC: how does that work?  just loop through the kernel image, replacing locks w/ noops?  is it i386 only?
[10:12] <BenC> it redefines LOCK so that it places the .lock op in a linker section, so there's a simple lookup table
[10:12] <BenC> then it goes through that table and replaces the lock's with nop's
[10:12] <BenC> so it's a precise and quick rewrite
[10:12] <BenC> not just a broad search and replace
[10:13] <BenC> and it does it at runtime
[10:13] <BenC> it can be done on non-i386 aswell
[10:14] <BenC> I think I'll be testing it when I start a 2.6.13 tree
[10:34] <BenC> 2.6.12-8.13 uploaded
[10:44] <chmj> so the bug flood begins